The Formbook malware is Stealer/Loader type malware that was first discovered in 2016. It operates as a Malware as a Service (Maas), meaning low level threat actors can simply just buy the malware and use it.

Summary

The Formbook malware utilizes a single buffer space, approximately 3200 bytes in size, for storing information like function addresses, decoded strings and API address’s. To evade detection, it employs techniques such as NTDll manual mapping to eliminate hooks and the malware also conducts additional checks for debuggers and blacklisted processes.

Formbook, categorized as a Stealer/Loader type malware, was initially identified in 2016. Operating as a Malware as a Service (MaaS), it enables low-level threat actors to easily acquire and employ the malware for malicious purposes.

Stage 1

Config Cleanup

Formbook stores a special set of bytes that are used to determine the information the malware needs to run. The issue with this is that these bytes are also filled with junk. The malware will clean up the junk bytes by following this set of instructions.

1) Ensure The first two bytes are correct, ensuring the data isnt corrupted, in my case, these bytes were (0x55 & 0x8b).
2) Read the first byte after the first two ID bytes, that byte will determine how many bytes before the ID byte will be removed.
3) Write Non junk into return buffer.

<IDByte><IDBYTE><NJ><ID+4><J><J><J><NJ><ID+3><J><J><C>
J = JunkByte
NJ = Non Junk
ID+<num> = IDByte + Number of bytes including self which will be removed

LdrLoadDll

Once the junk has been cleaned up, the malware will then start searching for the NtDLL function, “LdrLoadDll.”

This is achieved by traversing the module list and brute-forcing every function until it matches a preset hash.

NTDLL Manual Mapping

The malware utilizes Manual Mapping to eliminate any hooks that might be attached to the preloaded ntdll module.

Anti Analysis Checks

The malware performs multiple malware anti-analysis checks. Any checks which fail are stored either as 0x01 or 0x00 within the original storage buffer, and to ensure the malware doesn’t get debugged.

The malware will then check against these flags and ensure the correct flag is set before continuing, else the process will terminate.

The malware will perform the following checks:

1) RDSTC Time check
2) Process Checks
- Check for Sandbox Processes - Check if machine has VM guest tools - Check for Blacklisted Modules Loaded 3) Current Process Extension Check
- Ensure Extension ends in “.exe” 4) System Username Check

Stage 2

Prepare Malicious Memory Section

The malware writes itself into its own memory using ZwCreateSection & NtMapViewOfSection.

Process Migration

The malware uses APC Thread Hijacking to migrate itself into Explorer.exe.

The Injection Process Follows these steps:

1) Find Explorer.exe’s PID through API hashing & Create a handle on the process
2) Call OpenThread & Suspend Thread to suspend the main Explorer Thread
3) Use NtMapViewOfSection to write the malicious memory section into Explorer.exe’s memory
4) Modify Thread context to execute malicious memory section
5) Have QueueApcThread start a new thread to execute said malicious section
6) Call ResumeThread to execute the malicious Section

C2 Communication

Having a quick look at the C&C Communications, it looks like the malware uses Window’s WinHttp Protocol to communicate back to the server.

References

• ThisisSecurity’s Hash Index
• Sample
• Unpacked Sample
• Rémi Jullian’s Talk on Formbook