Formbook is a data stealer and a form-grabber malware that is being distributed as a MaaS (Malware-as-a-Service) in many hacking forums since early 2016 and has been very active since then. This malware can be used by even script-kiddies to exploit the victim’s system as this is very simple to set up and use. The malware authors have also been constantly improving and changing their component delivery modules to escape AV detections. This has also resulted in a higher infection rate which is evident from the number of unique submissions every week to various online scan engines. Anyrun updates its malware tracker page based on the number of unique malware submissions uploaded to their platform and Formbook is among the top 10 most prevalent threats.

This blog talks about the new tricks that have been implemented for delivering the Formbook malware. The kill chain starts with a spam document as depicted in Figure 1 which is delivered via email, typical in many malware campaigns. The document contains a macro to download a binary from ‘hxxp[:]//lulu[.]breful[.]us/talent/kachi.exe’ that gets saved and executed as ‘%temp%\hotrpdxweqqlnzk.exe’ as depicted in Figure 2.

Figure 1: Spam document requesting for a product quotation
Figure 2: Macro that downloads the 1st stage binary

The downloaded binary appears to be a VB file which allocates some virtual memory and decrypts some code as depicted in Figure 3. It also contains many junk instructions.

Figure 3: Decryption routine of 1st stage binary

This decrypted code does some pretty interesting stuff which is given below.

  • Debugger Anti-attach technique
    Why bother to implement the ubiquitous anti-debugging technique when you can detach the file itself from the debugger. The malware uses ntdll.ZwSetInformationThread with the 2nd parameter as 0x11 which actually translates to ThreadHideFromDebugger. Due to this, the debugger will not be able to receive any notification and the thread will be hidden and detached from the debugger. To circumvent it, one can manually change the 2nd parameter to 0x0 which translates to ThreadBasicInformation.
Figure 4: Detaches the debugger using ZwSetInfomationThread
  • Patching ntdll.DbgBreakPoint and ntdll.DbgUiRemoteBreakin
    When we attach a debugger to a running process it calls DebugActiveProcess API which will in turn call RtlCreateUserThread function to create a new remote thread into the targeted process with DbgUiRemoteBreakin function as its new thread’s starting point. Therefore, a malware can easily hook ntdll.DbgBreakPoint and ntdll.DbgUiRemoteBreakin API and patch them to the point that will cause the process to exit or NOP (no operation) or to a point where it will call an unknown or non-readable location. In our case, it modified DbgBreakPoint to NOP (no operation) and DbgUiRemoteBreakin to call the address 0x00000000 and exit as depicted in Figure 5.
Figure 5: Patching ntdll.DbgBreakPoint and ntdll.DbgUiRemoteBreakin
  • Unhooking user mode hook
    For behavior-based detection most of the Anti-Virus products implement a user mode hook for some of the most common APIs used by malware. To do that, they simply modify the 1st 5 bytes (0xb8 ????????) of the API function with an unconditional (0xe9 ????????) jump to their hook handler. So the malware tries to rewrite the 1st 5 bytes to its original state even if the hook is not in place. The patching routine is depicted in Figure 6.
Figure 6: Routine for unhooking user mode hook

Once these checks are over, it proceeds to download the 2nd stage payload from a Google Drive link as depicted in Figure 7. The downloaded file is an encrypted binary file which is decrypted to receive a PE file (Formbook) as depicted in Figure 8. The decrypted 2nd stage file (Formbook) does not touch the disk as it will be injected to a newly created process.

Figure 7: Establishing connection to download encrypted binary from Google Drive
Figure 8: Decryption routine

We also took a closer look at the Google Drive link to see if we can extract some information about the threat actors. Like we suspected, the encrypted binary hosted on the Google Drive was shared in such a way that anyone can view and download the content if they have the link. The owner of the link is “cloud eye” as depicted in Figure 9.

Figure 9: Owner’s details for the Google Drive link

Attribution

We dumped the decrypted PE file (Formbook) from memory for further analysis. The dumped file is an encoded binary which includes junk values between the actual code. Figure 10 is an example of junk codes inserted in the “Current Version” string.

Figure 10: Junk values between strings

Having said that, we have seen a similar URL pattern and encoding method in the Formbook binary delivered during Gorgon APT campaign in the second half of 2019. The code/function flow of the dumped file is also similar to the previous campaign’s Formbook module. Further research work on confirming this attribution will be posted in the next blog.

As we always say, ignore emails from unknown sources and that you have not been expecting, thus avoiding becoming a victim of such malicious attacks. Use a reputed security product such as K7 Total Security to stay safe from any cyber threats.

Indicators of Compromise (IoCs)

Hash Description    Detection Name
FB502EF7014DA47F7E0BC158C5B7BE50 Doc file Trojan ( 0001140e1 )
A15C916577715300276BF4C060CFBFB7 VB file Riskware ( 0040eff71 )
3984B0A0BA7EFDA948BC63D9CD4C0192 Formbook binary Trojan ( 00536d121 )

URLs

hxxp[:]//lulu[.]breful[.]us/talent/kachi.exe

hxxps[:]//drive[.]google[.]com/uc?export=download&id=19sVk-ZTWHVl3_ITBst1x51qX2L28yNlw

Like what you're reading? Subscribe to our top stories.

If you want to subscribe to our monthly newsletter, please submit the form below.

    Leave a comment

    Your email address will not be published. Required fields are marked *