FormBook | Yet Another Banking Trojan

FormBook is yet another banking trojan. Like most financial malware, it performs many operations to evade AV vendors when deploying itself on a victim’s machine. And of course as we see with Ursnif, Hancitor, Dridex and other banking trojans, there are many variants with more than one way to receive the payload.

In the past year the threat actor’s favorite method of distributing FormBook has been via malspam and the use of CVE-2017-8570, using an .RTF file format with malicious code to exploit this vulnerability.

In this article, I will focus on the payload and elaborate on the behavior and IOCs of the malware.

FormBook Anti-Analysis Techniques

Let’s start with FormBook’s attempts to prevent malware researchers from debugging and analysing the malware. From research done by others, we know that FormBook starts by enumerating the running processes on the victim’s machine. If any of the blacklisted processes exist, the payload will cease from infecting the machine.

There are more anti-analysis techniques such as blacklisted processes, VM detection, and obfuscated strings in memory both to avoid memdumps with configuration and to prevent relevant strings from being observed by security researchers.

Here are some of the blacklisted processes, as mentioned in this article. Notice that among other things it looks for VMWare and Parallels virtual machine instances, both of which might be used by researchers:

Vmtoolsd.exe, vmwareservice.exe, vmwareuser.exe, vboxservice.exe, vboxtray.exe, netmon.exe,
Sandboxiedcomlaunch.exe, Sandboxierpcss.exe, procmon.exe, filemon.exe, wireshark.exe,
prl_tools_service.exe, vmsrvc.exe, Vmusrvc.exe, python.exe, perl.exe, regmon.exe

In order to use procmon for event capture, I chose the “Enable boot logging”, which will create a service and a driver entry for procmon until the next boot. This allows procmon to capture system events on the next boot

C:\Windows\System32\drivers\PROCMON24.SYS

Running the FormBook Payload

Now that we are able to execute the payload and analyse its run, I chose one arbitrary sample from VT.

Sha1: ecb7b646b21e4940b9e68b55722f7755057c933c

Once the the payload is deployed on the machine, we can view its process tree:

image of process tree

Here’s how it looks after boot:

image of process tree after boot

Note the use of legitimate processes through the entire infection chain; this is accomplished with process_hollowing and code injection.

The process tree varies and will look different every run (that also includes the reboot). These processes are injected with code and perform malware functionality.

Here is a partial list of the legitimate processes being used by Formbook to evade detection:

taskhost.exe, explorer.exe, svchost.exe, dwm.exe, cscript.exe, netstat.exe, raserver.exe, wscript.exe, wuapp.exe, cmd.exe, ipconfig.exe, lsass.exe, rundll32.exe, msdt.exe, mstsc.exe, msiexec.exe, systray.exe, audiodg.exe, wininit.exe, services.exe, autochk.exe, autoconv.exe, autofmt.exe, cmstp.exe, wuauclt.exe, napstat.exe, lsm.exe, netsh.exe, chkdsk.exe, msg.exe, nbtstat.exe, spoolsv.exe, rdpclip.exe, control.exe

FormBook Deployment Flow and IOCs

I ran the sample payload as an Admin user.

In its first stage, the payload drops explorer.vbs script and another MZ called explorer.exe in a folder in %appdata%\local\temp\subfolder. Of course, this is not the actual authentic explorer, as we can see from the file hash:

Sha1: dbaf9e4fc18d8744d5ee9d80bf7f4ef6e2d18bf7

Here we see the content of the .vbs file, and the commands to add a registry value.

image of malicious file adding registry entry

Then, the vbs script runs the explorer.exe, and the original payload process is terminated.

image of terminating the process

At this point, the legitimate explorer.exe:1320 is also injected, which spawns msiexec.exe. It is then injected with code to run.

image of injecting explorer exe

Then the legitimate injected explorer.exe drops a similar payload as another persistence method, and it’s the same file as the malicious explorer.exe.

It spawns DllHost to write most of the file, but we see it also writes to that file. The file name and folder seem to be changing per machine installed upon.

image of spawning DLL host

At this point the machine is infected, while other related operations are being performed.

In this instance, msiexec.exe is kept alive and injects to the browser, performing a re-infection in case the persistence was deleted.

IOC summary:

    • A file and a folder in program files in the following convention

(From my tests the folder name and file name varies per machine)
C:\Program Files\Rwpj8mp\mpxpsj78jvx8ftbp.exe

    • A folder and a file in the following convention (identical for all machines)

C:\Users\Test_PC\AppData\Local\Temp\subfolder\explorer.vbs
C:\Users\Test_PC\AppData\Local\Temp\subfolder\explorer.exe

    • Persistence has 2 entries, one for each of the mentioned above


image of Formbook malware persistence

More FormBook Indicators of Compromise

After the infection chain is complete, we can see the processes the malware utilizes for its use. We could also use some tools to see internally what makes these processes work on behalf of the malware.

For example, the memory region of the cmd.exe:2524 contains a memory region with read-write-execute (RWX) permissions and an MZ in that section, so this is indeed malicious for most cases.

image of read write execute permissions

image of hexdump of cmd exe

Because we know FormBook is financial malware, we also know that the malware will probably try to inject code to the browsers and then set hooks on the relevant functions to exfiltrate data from the browser.

We could see it in the memory regions of the browsers with RWX permissions, in Internet Explorer. We can also see hooks into notepad, which was opened as well and for the same reason of exfiltrating user information.

image of hooks into notepad

This info was acquired with GMER tool.

What we see is that these functions are hooked in the above memory addresses, and we can tell the opcode used, which is usually either CALL or JMP.

You can see the address where this section starts, and its protection level, which is our biggest indicator that something is wrong (RWX is not not necessarily malicious on its own, of course).

During the malware run either on a new infection or just the boot of an infected machine, it will trigger a print screen to be sent to the C&C for reconnaissance purposes.

On my tests it resides at C:\Users\Test_PC\AppData\Roaming\3Q5P0RE0\3Q5logim.jpeg

image of malicious jpeg file

The folder C:\Users\Test_PC\AppData\Roaming\ also temporarily contains a few more files which are deleted later.

Here, the final process msiexec.exe:3052 writes these files to disk:

C:\Users\Test_PC\AppData\Roaming\3Q5P0RE0\3Q5log.ini
C:\Users\Test_PC\AppData\Roaming\3Q5P0RE0\3Q5logri.ini
C:\Users\Test_PC\AppData\Roaming\3Q5P0RE0\3Q5logrv.ini

Conclusion

SentinelOne customers are protected from all versions of FormBook banking trojan. The SentinelOne agent’s behavioral AI engine detects and blocks the FormBook malware without needing to be updated or rely on cloud connection. If you haven’t tried out the SentinelOne offering yet, click the Free Demo button above and see the difference our easy-to-deploy solution can make to the security of your business.


Like this article? Follow us on LinkedIn, Twitter, YouTube or Facebook to see the content we post.

Read more about Cyber Security

*** This is a Security Bloggers Network syndicated blog from SentinelOne authored by Matan Meir. Read the original post at: https://www.sentinelone.com/blog/formbook-yet-another-banking-trojan/