FormBook Malware Distributed via Horus Protector Using Word Docs

In a recent email-based malware campaign, the X-Labs team observed threat actors delivering the well-known information stealer FormBook using Horus Protector, a malware distribution service designed to evade detection.

First identified by SonicWall last year, Horus Protector is a relatively new service for distributing malware. The attack chain begins with phishing emails containing malicious Microsoft Word documents as attachments. Upon execution, these documents initiate the deployment of FormBook, leveraging Horus Protector’s obfuscation capabilities to bypass security defences. This campaign highlights the ongoing evolution of commodity malware delivery systems and the continued reliance on social engineering via document-based lures.
 

FormBook Attack Chain

FormBook Attack Chain

Analysing the email sample:

Fig. 1  - Email sample

The email contains an attached Microsoft Word document, structured as a compressed file. After extracting its contents, we find the targeted file, Panama.rtf, located within the _rels directory.

Fig. 2 - Extracted Word document content

Fig. 3 - OpenXML relation to RTF file

Upon examining the RTF file, we find an embedded object, Client.vbe, along with a potential exploit for a remote code execution vulnerability in the Equation Editor of Microsoft Office (CVE-2017-11882). However, this vulnerability is not exploited during the execution of the file.

Fig.4 - Extracting the VBE file 

Analysing the VBE file

 The VBE is a Visual Basic Encoded script file that can be decoded into a readable Visual Basic Script (VBS) format. Upon decoding, we observed a series of obfuscated code blocks and variable declarations.

Fig. 5 - Obfuscations in VBS snippet

The decoded Visual Basic Script is organized into several components, originally labelled in French, which have been translated as follows:

• Constants and Configuration
• Management of Scripts Files
• Registry Management
• Managing Scheduled Tasks
• Utility Functions
• Payload Execution
• Security Detection
• Main Logic

Overview of Visual Basic script functionality:

The Constants and Configuration component includes an embedded VBS which is obfuscated by being hex encoded four times. During runtime it will be written to disk under the user’s AppData directory as lJlpBAHduOhBIlJ.vbs. This is later executed by a scheduled task. lJlpBAHduOhBIlJ.vbs creates a loop that will iterate 10,000 times checking via WMI queries whether PowerShell is running. If PowerShell is not detected, it is launched in minimized mode and executes commands stored in the registry.

Fig. 6 - Extract from deobfuscated embedded VBS

The Management of Scripts Files component is responsible for writing lJlpBAHduOhBIlJ.vbs to disk.

The Registry Management component consists of two sub procedures, EBD and MOX.

EBD creates multiple entries used to store key values. These include a reference to RegAsm.exe, a command to forcefully terminate the process conhost, a PowerShell command to dynamically load a .NET assembly, and registry keys to store two .NET compiled binaries. These entries are obfuscated through hex and base64 encoding. 

MOX adds registry entries to store the FormBook PE file (which is embedded under the ‘Main Logic’ component). It splits the binary into 20,000-character segments, reverses each segment as a string, and stores them across multiple registry keys. This technique enables the script to store data larger than typical registry value limits by fragmenting it across multiple keys.

The registry entries created by these two subroutines are used to check for running processes, retrieving payload components, and executing commands.

Fig. 7 - Deobfuscated sub procedure for creating registry entries

For persistence the Managing Scheduled Tasks component creates a scheduled task to execute the dropped lJlpBAHduOhBIlJ.vbs every minute.

The Utility Functions component provides routines to decode hex-encoded strings and determines the path where lJlpBAHduOhBIlJ.vbs is written.

The Payload Execution module executes a hex-encoded PowerShell command that loads an executable (retrieved from the registry) directly into memory.

The Security Detection module checks for the presence of Windows Defender using WMI queries. The execution flow of the attack will be altered depending on the result of this check.

Finally, the Main Logic subroutine ties together all the components of the script: it initializes paths, modifies the registry, writes the secondary VBS file to disk, creates a scheduled task, and ensures the malicious payload - the embedded FormBook PE file, is either scheduled for later execution or launched immediately if certain conditions are met.

Fig. 8 - Sub procedure Main

Word Document Execution and Observation:

During dynamic analysis of the Word document we observed the following behaviour: 
1- The initial Word document attachment targets the embedded RTF file.

2- The RTF file has an embedded object Client.vbe which is executed.

3- Registry values are created and modified.

4- VBS file is created in the %AppData% directory.

5- A scheduled task is created to run PowerShell and execute the dropped VBS file.

Figures demonstrating system changes:

Fig. 9 - Dropped lJlpBAHduOhBIlJ.vbs

Fig. 10 - Scheduled task
 

Fig. 11 - Registry keys created

Fig. 12 - Sub registry keys storing FormBook payload
 

Deploying FormBook

PowerShell is launched with a command which initiates a multi-stage in-memory deployment of FormBook. It first accesses a .NET assembly stored in the registry under the value “s”, and invokes method b of class b.b, which functions as the primary loader. This loader then executes a secondary DLL retrieved from the registry value “r,” functioning as the injector. The injector reassembles the final FormBook payload from the values stored under the “donn” sub registry keys - segment1 to segment29 as illustrated in Figure 12. A legitimate Windows executable, defined in the registry under the value “i”, is the target for process hollowing. In this sample, the payload is injected into a suspended RegAsm.exe process, allowing FormBook to execute under the context of a trusted system binary. 

Fig. 13 - PowerShell script to initiate multi-stage deployment in memory
 

Fig. 14 - Loader calling injector
 

Fig. 15 - Injector reassembling payload from registry values
 

By executing the payload within the memory space of RegAsm.exe, FormBook effectively conceals its malicious activities, making detection more challenging. Once active, it can harvest sensitive data from the victim’s system and exfiltrate it to its designated command-and-control (C2) servers.

Conclusion:

The Horus Protector distribution service leverages Visual Basic Scripts to stealthily deliver malware. The campaign detailed in this blog focuses on how users are lured to click on weaponised Word Document attachments. Opening the document triggers malicious activity through the execution of an embedded object within the RTF file. The embedded object, a VBE file, invokes PowerShell to perform several actions: it drops a VBS file into the %AppData% directory, modifies registry values, performs system checks and schedules a task to run the PowerShell command every minute. By utilizing PowerShell as a Living-off-the-Land (LotL) technique, the script ultimately injects the malicious FormBook payload directly into memory, masquerading as a legitimate native process. This approach significantly hinders detection by conventional security solutions.

Protection Statement:

Forcepoint customers are protected against this threat at the following stages of attack:

• Stage 2 (Lure) – Emails and malicious attachments are identified and blocked by Forcepoint Email Security.
• Stage 6 (Call Home) – C2 servers are blocked. 

NGFW Protection Statement:

• The malicious attachments are blocked by the GTI file reputation service if it is enabled.

IOCs: