FormBook is yet another Stealer malware. Like most stealer 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 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:WindowsSystem32driversPROCMON24.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:

Here’s how it looks 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%localtempsubfolder. 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.
Then, the vbs script runs the explorer.exe, and the original payload process is terminated.
At this point, the legitimate explorer.exe:1320 is also injected, which spawns msiexec.exe. It is then injected with code to run.
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.
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 FilesRwpj8mpmpxpsj78jvx8ftbp.exe
-
- A folder and a file in the following convention (identical for all machines)
C:UsersTest_PCAppDataLocalTempsubfolderexplorer.vbs
C:UsersTest_PCAppDataLocalTempsubfolderexplorer.exe
-
- Persistence has 2 entries, one for each of the mentioned above
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.

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.
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:UsersTest_PCAppDataRoaming3Q5P0RE03Q5logim.jpeg
The folder C:UsersTest_PCAppDataRoaming also temporarily contains a few more files which are deleted later.
Here, the final process msiexec.exe:3052 writes these files to disk:
C:UsersTest_PCAppDataRoaming3Q5P0RE03Q5log.ini
C:UsersTest_PCAppDataRoaming3Q5P0RE03Q5logri.ini
C:UsersTest_PCAppDataRoaming3Q5P0RE03Q5logrv.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.
