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.
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
Now that we are able to execute the payload and analyse its run, I chose one arbitrary sample from VT.
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
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:
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
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.
(From my tests the folder name and file name varies per machine)
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_PCAppDataRoaming also temporarily contains a few more files which are deleted later.
Here, the final process
msiexec.exe:3052 writes these files to disk:
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.