A new technique to analyze FormBook malware infections

FormBook is a well known malware family of data-stealers and form-grabbers. Sold on hacking forums as ‘malware-as-a-service’ it  has previously been used to target the aerospace, defense, and financial sectors, and thoroughly researched. However, in this article we will use a new technique, developed by Avira researchers, to analyse the infection process, breaking it down individual steps.

Overview

By: Malina Rosu, specialist virus analyst, Avira Protection Labs

FormBook malware is typically spread through web browsers, mail, FTP clients and instant messaging applications via malicious attachments such as Office documents and PDF files. The malware can inject itself into processes and install function hooks through manual execution of phishing emails and  opening malicious attachments. Its capabilities include capturing screenshots, stealing credentials, keystroke logging, and clearing browser cookies. Data thefts are most effective when the victims use a virtual keyboard, auto-fill, or if they copy and paste information to fill a form.

The FormBook infection takes place in multiple stages. In our example the infection begins when a user receives an email with a malicious Office .docx file attachment presented as a purchase order. Other files included are a Rich Text Format file with seven other embedded Excel files, two script files (one VBS file, one image file which is actually a obfuscated script file) and some Powershell commands.

There are six different steps in the process, not all of which are immediately obvious, but can be understood when the entire process is completed. For example, the malware deletes the notepad.exe from System32 because the malware will  ultimately execute under this name.

Infection Analysis

The infection vector in our example is an email. It apparently contains a valid purchase order (PO20200217.docx) that appears to have been sent to the wrong email address.

Stage 1: Analyzing the attachment – the docx documents

We execute the document in a virtual environment allowing us to check its malware capabilities. The document connects to a URL, and attempts to download the payload  via a connected URL – a Rich Text Format file.

It is a docx file with Open Office XML format. In settings.xml.rels resides an xml file with an external relationship of type attachedTemplate embedded in the document that redirects to an external resource.

After the payload is successfully downloaded, a PowerShell command is used to delete the notepad.exe from the System32 folder

Stage 2: Analyzing the first payload – the rtf document

Analyzing the .rtf file document with RTFScan, reveals eight OLE embedded objects. Seven out of the eight objects were similar Excel files, all being executed as seen in the Process Monitor capture:

Stage 3: Analyzing the second payload – the xls documents

We show the analysis flow for one of the Excel documents below, because they are all similar. The file name ‘payload_1.exe’ together with a low number of  detections from VirusTotal make them suspicious.

Execution of the Excel documents results in warning pop-ups for Enable Content, requesting the user to enable macros. Enabling macros have no effect on the document, it appears damaged.

At this point, many users would close the file and move on. However, before executing the file, we analyzed the file behaviour on Process Monitor. The files were not damaged at all, as shown below:

The attackers have hidden the document file on purpose, making it appear blank when opened. Now the obvious question is; how does the file manage to execute the PowerShell script? Well, remember the Enable Content warning? This points to the fact that there may be macro code:

The macro code is executed before the document is closed, and it appears that it executes the text it finds in the TextBox 1. But it’s hidden as it contains a Powershell command.

The command, hidden in the textbox, downloads and executes a Visual Basic script. As shown in the below image:

The script file also had only a few detections from AV scanners in VirusTotal.

Stage 4: Analyzing the first payload – the Visual Basic Script

To avoid detection the Visual Basic script is obfuscated using string manipulation functions such as reverse, split, replace, concatenation and hex encoding.

We hex-decoded the Fly subroutine. The malicious script that executed in the global namespace overwrites the initial Fly subroutine. This is shown by the two Fly subroutine calls at the very beginning of the malicious script.

The new Fly subroutine makes use of the Windows Management Instrumentation to execute the PowerShell script received as parameter. This is done with hidden property enabled to hide its presence from the user.

The PowerShell makes a GET request to the website. It manipulates the response to download the fifth stage payload.

The script achieves persistence by copying itself to “\Appdata\Roaming\” folder and adding itself to the current user registry Run key.

Stage 5: Analyzing the second payload – the att.jpg image

To establish if the jpg file was indeed an image, we use the Hex editor. The .jpg file had the first four bytes FF D8 FF EO, so it is unlikely to be what it claims. The character “-” linking the bytes also indicates that the file is not legitimate:

To examine the malicious file, and figure out what the file hides, we need to understand how the script manipulates the file after downloading it. It performs a split action by “-“, and then a hex to ascii decoding.  The below image shows two very long hex encoded strings – Cli1 and Cli2, and a function – UNpack.

The UNpack function performs a Gzip decompression of the Cli string. Since the magic number for a GZIP archive file is 1F 8B 08  (as seen in the first part of the string) it seems likely that it is a GZIP. We get the payload (a dynamic library file) after decompressing the Gzip byte array, and replacing “$%” in the Cli string. The dynamic library file – Pineapple.dll – is loaded in the following line of  script.

Following similar steps, we conclude that the second string is an executable file – attack2_cli2.exe_, part of the FormBook malware family.  Avira detects it as TR/Crypt.ZPACK.Gen. The file is executed under the name notepad.exe.

This is the main reason why the first document deleted the legitimate notepad executable file from System32 folder.

Conclusion

FormBook malware is very agile in its behavior and effective in hiding malicious intent. It can easily trick users into executing it. Despite not being broadly used, FormBook represents a real threat: It is stealthier and more powerful than other malware.

You can learn more about new and novel malware in the research section of the Avira Insights blog, or find out how you can improve your own detection rates by using Avira’s Anti-malware SDKs or cloud sandbox API.

IOCs