FAUST Ransomware: Exploring the new variant of Phobos Ransomware found in an Office document

February 28, 2024

Posted By: Research Team

FAUST Ransomware: Exploring the new variant of Phobos Ransomware found in an Office document containing a VBA script

A new variant of the Phobos ransomware, known as FAUST, has been discovered by FortiGuard Labs. This variant is delivered via an Office document containing a VBA script, utilizing the Gitea service to store and retrieve malicious files encoded in Base64. FAUST exhibits complex behavior, including injecting shellcode into a legitimate process and deploying multiple threads for efficient execution. It maintains persistence on infected systems by adding registry entries and copying itself to startup folders. The ransomware encrypts files with a “.faust” extension and instructs victims to contact the attackers for ransom negotiations.

The Attack Chain

Initial Contact

The victim encounters a malicious Office document embedded with a VBA script designed to initiate the attack process. The attackers leverage the Gitea service, a platform commonly used for version control, to store and retrieve encoded files, ensuring a covert transfer of malicious payloads.

Execution

Upon opening the document, the VBA script executes, invoking PowerShell through the “Workbook_Open()” function. The PowerShell script executes commands to fetch Base64-encoded data from Gitea, which is decoded into a clean XLSX file. The XLSX file, now cleansed of its encoded disguise, is saved in the TEMP folder.

Downloader Deployment

Afterward, the attacker creates a new folder in the system and saves an executable called “AVG update.exe.” The downloader allocates Read-Write-Execute (RWE) memory and leverages APIs to inject the shellcode into a legitimate process, masquerading its presence within the system.

Persistence

The injected shellcode serves as a conduit for the FAUST ransomware payload, paving the way for its infiltration into the victim’s system. FAUST enacts persistence mechanisms, adding registry entries and copying itself to startup folders, guaranteeing its persistence with each system reboot.

Encryption

FAUST ransomware begins encrypting files across the victim’s system, appending the “.faust” extension to each encrypted file and leaving behind info.txt and info.hta files as ominous indicators of its presence.

Ransom Demand

The ransom note is delivered through info.txt and info.hta files instructing victims to reach out to the attackers via email or TOX message, setting the stage for potential ransom negotiations.

Recommendations

Here are recommendations to significantly reduce the risk of falling victim to the FAUST ransomware variant or similar threats.

Enhance the detection capabilities for VBA scripts and disable or restrict unnecessary VB components.

Implement comprehensive monitoring and detection capabilities to identify and respond to suspicious VB-related activities. Monitor executed commands, module loads associated with VB languages, process creation events, and script execution attempts. Leverage security tools like Sysmon to generate alerts on loading DLL modules associated with Visual Basic and tune the configuration to minimize false positives. Also, examine, disable, or limit access to any non-essential Visual Basic components in the organization’s environment.

Restrict web-based content and use script-blocking extensions.

Deploy script-blocking extensions and adblockers to prevent the execution of Visual Basic scripts and HTML Application (HTA) files commonly used during exploitation. By blocking malicious code served through ads and preventing script execution in web browsers, the risk of VB-based attacks originating from web-based sources will be reduced.

Use application control and exercise caution when opening unsolicited Microsoft documents.

Use application control mechanisms to limit how VB scripts downloaded from unreliable sources can be executed. Use the Mark of the Web (MOTW) property to prevent VBA macros from running in Office programs like Word, Excel, PowerPoint, Visio, and Access.

Implement robust monitoring for PowerShell process creation and module loading events to detect anomalous behavior indicative of malicious activity. Monitor Windows event logs for PowerShell-related events.

Monitor for abnormal command execution and script activities associated with PowerShell usage. Enable PowerShell logging to capture detailed execution events and gain increased visibility into PowerShell activities, including script invocations and .NET invocations.

Look for process creation (Event ID 4688) and PowerShell session start and end times (Event ID 400 and 403). Analyze process metadata to identify potential downgrade attacks and distinguish between local and remote PowerShell sessions.

Monitor for any attempts to enable script execution on systems, particularly if scripts are not commonly used or run outside of scheduled patching or administrative functions. Capture and analyze scripts from the file system to determine their intended actions and assess their legitimacy.

Follow macro security best practices suitable for your environment, and configure and update regularly.

Mitigate the risk of malicious code execution through Office applications by disabling Office VBA macros from executing to prevent potential exploitation by malicious actors. Additionally, disable unnecessary Office add-ins, and if they are required, ensure they are securely signed and configured to minimize risks.
Implement appropriate software configurations to enhance security. For the Office Test method, create the Registry key used to execute it and set permissions to “Read Control” to prevent unauthorized access without administrator permissions or requiring Privilege Escalation.
Keep Office applications and associated components up to date with the latest security patches and updates. Apply patches such as KB3191938 to block Outlook Visual Basic and display a malicious code warning, KB4011091 to disable custom forms by default, and KB4011162 to remove the legacy Home Page feature. Regularly check for and apply relevant security updates to mitigate known vulnerabilities.

To mitigate process-based process injection, enable Attack Surface Reduction (ASR) rules, and use Yama. Look for and identify efforts at process injection, like file metadata.

Configure these solutions to recognize and prevent suspicious behavior associated with process injection, such as code injection attempts by Office applications. Leverage features like Attack Surface Reduction (ASR) rules on Windows 10 to enhance endpoint security against process injection techniques.

Employ Yama (e.g., /proc/sys/kernel/yama/ptrace_scope) to mitigate ptrace-based process injection by restricting the use of ptrace to privileged users only. Deploy security kernel modules such as SELinux, grsecurity, and AppArmor to enforce advanced access control and process restrictions, further limiting the effectiveness of process injection attacks.
Monitor file metadata for contextual data related to files, including changes indicative of code injection attempts or privilege escalation. Pay attention to module load events, particularly the creation and loading of DLLs into processes, and identify DLLs that are not recognized or normally loaded. Monitor OS API executions for known sequences of API calls associated with process injection methods, such as CreateRemoteThread, SuspendThread/SetThreadContext/ResumeThread, QueueUserAPC/NtQueueApcThread, VirtualAllocEx, and WriteProcessMemory. Additionally, monitor process access and metadata for anomalies and inconsistencies that may indicate code injection or process modification.