FormBook Malware Returns: New Variant Uses Steganography and In-Memory Loading of multiple stages to steal data

Quick Heal Security Lab has seen a sudden increase in dotnet samples which are using steganography. Initially, in the static analysis, not much information is available. It resembles some simple application going by the method name. On the dynamic side, some show the activity but another check for sandboxing environment. Apart from this, even on execution, it loads multiple memory stages that contain numerous long periods of sleep.  One such file received in our lab was of Formbook malware. Formbook stealer has been sold on hacking forms since 2016 as-a-service.

In this blog, we will go through those multiple stages and analysis of the final payload. The final payload is also complicated due to various threads creation and sleeps in between.

Technical Analysis

SSO.exe

In the resource of sso.exe, there is an image that indicates the use of Steganography. However, this resource is not used at this level. There is one more resource present which initially is difficult to find. While going through the code of decryption, this 2nd resource was identified as stage 1.

Figure 1 GregorianCalendar in Resource, contains stage 2 file

Figure 2 Another Resource naming Tree, just below the blue line there are some red dots visible, contains stage 1 file

At the entry point, there is a single line code to execute the form.

Figure 3 Main function, calls the constructor of Form1 which decrypts stage 1 file

If we go to the Form1 code, there isn’t much information present. But when we check the Form1 class, we can see in its constructor a call to method ISectionEntry.

Figure 4 Constructor Code, call to decryption routine of stage 1 file

ISectionEntry contains the code to get Pixels(Fig 5), convert to integer and save it in an array(Fig 6) and then call to MessageSurrogateFilter(array) with the buffer passed as a parameter.

Figure 5 Decryption Routine from Image, decrypting stage 1 PE file

Figure 6 Buffer Containing stage 1 PE file

MessageSurrogateFilter() method then loads the decrypted assembly (SimpleUI.dll) into the memory and invokes its SeclectorX() method with some arguments, which will be explained later in Stage 1.

Figure 7 Assembling Loading of stage 1 in Memory and invoking its member SelectorX with resource name, decryption key and assembly name

Figure 8 SimpleUI.dll loaded in memory

Stage 1:

Figure 9 SimpleUI.dll

• Since there are not many methods present in this file, we directly go through the code of the SelectorX method. As we can see in Figure 7, there are three values passed to this function which are:
• RestrictedError = 477265676F7269616E43616C656E646172 = GregorianCalendar (Name of resource in Main file, resource shown in Fig 1)
• ValueEnumerator = 72584C4F594D6D556D = rXLOYMmUm (Key for decryption)
• Project Name= Agent.Common (Main File)
• cba() method contains the code to get the Pixels from the image and convert to Integer and save it in an array, and XeH contains code to convert the hex value into a string.

Figure 10 SelectorX method accesses the GregorianCalendar resource from main assembly and decrypts it using the key passed under fgh() method

Figure 11 Size of Buffer to be initialized for stage 2

fgh() method’s decryption routine is a simple XOR with 2 values in which the “bytes” array contains a Unicode version of the Key (mentioned as ValueEnumerator above).

Figure 12 fgh() method code for decryption, normal xoring

After decryption, the assembly is again loaded in Memory.

Figure 13 Stage 2 assembly loaded in memory

Stage 2:

Figure 14 Stage 2 Assembly

It becomes difficult to analyze with these unicoded function name.

Figure 15 Stage2 Unicode method names

In this stage 2 assembly, a method named Fedree() is called, whose constructor contains the code to decrypt and inject the final payload.

In the decryption routine first, the name of the resource is decrypted to s2pCN (resource in stage 2), Loads the resource and passes it to the XOR_DEC along with a KEY. Decrypted buffer is then passed to Unscramble function where it brings another dotnet file.

Figure 16 Decryption routine in Stage 2 which brings final payload

XOR_DEC contain simple xor with obfuscated code.

Figure 17 Xor_Dec method decrypts the final payload

Unscramble function forms the final payload.

Figure18 Unscramble Method code brings final payload PE file

After decryption, it does process hollowing by creating sso.exe’s process in suspended mode.

Figure 19 Process Hollowing Code to inject the final payload

Figure 20 Flag to CreateProcess in Suspended Mode

Final Payload:

The injected file is the final Payload of Formbook, which has around 1500 methods with random names.

This contains 2 different Base64 encoded strings.

Figure 21 Encoded String 1 contains CnC information and configuration

2^nd base64 string contains 5 modules which are later loaded in memory and executed.

Figure 22 Encoded String 2

The strings are converted from base64, then reversed and replaced by specified characters and again base64 decoded.

Figure 23 Decryption Routine to decrypt CnC details in string 1 and different modules present in string 2

The resultant data for 1^st  decoded string is CnC servers, mutex name and some configurations.

Figure 24 Decoded string 1 data

It also creates a bat file to check for network connection and again start the process and delete the bat file.

Figure 25 Content of Bat file

After decrypting the data it checks for the mutex if already present it exits. In configuration the value of “AUR” tag is true, it takes 2 running process’s names, from 1 it takes the name of the process, from the other it takes any folder name from the parent directory and copies itself to this location with first’s process name. Along with this, it keeps a file with a name as a hash of process name and some randomly generated garbage data.

Figure 26 Copies itself to various locations obtained from running processes path and also obtains the name from the same

It also schedules tasks for these copied files.

Figure 27  Creates Schedule task for the copied files

Next, it loads different modules which it has decoded initially and loads them into memory and invokes different methods.

Figure 28 code to Load different modules and call to different methods based on their availability

Then it tries to steal browser information like cookies, passwords, forms, history, autofill, credit card information also takes screenshots, clipboard data, discord tokens, FileZilla, telegram data, discord tokens, steam data.

There was also a module that will compile the code for DCRat at runtime on receiving commands from CnC.

Figure 29 Code to compile DCRat code at runtime

Other different modules present are:

1. AntiAnalysis Module

It has kept all strings in encrypted form under a list of various techniques.

Figure 30 Encoded Values for Strings used in anti-analysis module

Contains various techniques to identify if it’s running under VM or Sandboxing environment if there are any monitoring processes running. Also, a way to identify VM/Sandboxing is by checking physical Memory.

Figure 31 Anti Analysis Module

2. USBSpreadDCLIB Module

Contains code to spread to USB drives by creating an autorun.

Figure 32 USBSPreadDCLIB module

3. MiscellaneousInfoGraber module

Contains code to collect a List of installed software’s, running processes, time zone information, active TCP connections, local network connections available, list of connected USB drives.

Figure 33 Collects registry for uninstalling entries

Figure 34 List of Running processes

Figure 35 TimeZone information

4. FileGrabber module

Collects all the files

Figure 36 File Grabber Modules collects files

5. BSODProtection Module

At this point, this module is not in a complete state. This shows that it is still under development.

Conclusion:

This seems to be malware that is still being developed. We haven’t received Initial Vector yet, but it appears to be downloaded by a malicious doc/Xls file, which is spread through emails. Users should avoid opening emails, documents sent by unknown senders and keep the AV updated. We detect all the modules and stages with Trojan. Formbook and Trojan.YakbeexMSIL.ZZ4

MITRE ATT&CK TTPs:

IOC:

• 1D13A84AA671B75F66F4C7FCE8339619291D4A43 exe
• 6C73DC53F1AF57E1B2B404F2E20A9AECBAA80051 dll
• DC7CF9544AA5B4928697B4C49C94A60211F025A1 dll
• 9577B2B5C4FBA6B2AFA65C5161FCE75F48E75D5D dll
• 7E314AE69FC9A613A4A5356556F73E027B540141 dll
• 32D97D1729D9A5919CBE1AE76F46BCDB9620153C dll

Rumana Siddiqui