Today we’re gonna look at a sample of FormBook Malware, which contains AgentTesla within it. It features things such as hiding an EXE within an EXE, and installing a persistent backdoor within the system.

Source: https://bazaar.abuse.ch/sample/35147128936c2e79548e5c0a2bbd70cd5a29c1b01dfa1ac2515fa5becb7efa6d/#intel

First DNSpy Analysis

When we run the exe file through DNSpy, it looks to be building a simple form. But then we spot this few lines of code that pieces together an EXE file

What it’s doing is appending several strings together to “text”, converting them into bytes, before calling AppContextSwtiches to trigger the program.

Looking at the strings that were returned, we see that the first few bytes are the magic MZ characters, therefore we can deduce that this is another EXE file.

We set a break point to after the string has been pieced together, and extract the file embedded within it. What we see is one exe file, and one ico file.

The initial program has thus context switched from it’s initial flow to execute this embedded file, which we will analyze later. For now, when we let the current executable finish, it renders a simple UI with nothing to it.

Embedded File Analysis

We now turn our analysis to the embedded file that was extracted. Putting it under PEStudio and VirusTotal, we get information that it’s related to AgentTesla, which is a well known RAT and information swiper.

Dynamic Analysis

We use a combination of ProcMon and ProcDot to visualize the malware activity.

We run the executable as administrator, in my case it’s named 35147….exe, so we add that into the filter for ProcMon

We save the output to a CSV file, and upload it to ProcMDot to plot the activities of the malware. We observe plenty of Red lines, which according to the legend, are file writes.

Zooming into more interesting ones, we see that it creates a copy of itself under “C:/Users/<currentUser>/AppData/Roaming/<randomName>”. We know its exactly the same because the two binaries have identical MD5 hashes when we

We also observe plenty registry changes occurring, which are Red Lines to Yellow Boxes.

To get a clearer picture of what’s happening, we use RegShot to take a picture of the registry before and after the malware was executed.

It’s here that we see where the persistence is set, when it writes to “Schedule…\Logon…” which triggers the job upon every login, and the file to run would be the copy of the original file we saw created earlier.

Using DirWatch, we’re able to download all files that was transiently created, so that we can analyze them before the malware deletes it. We do this by checking the option “Save Files That Were Modified”

We’re able to pull out the XML file that was created for setting the persistence.

Furthermore, we have PowerShell Transcripts enabled, so we can see what commands were executed using PowerShell. We see that the malware add itself to the exclusion path

Deeper Dynamic Analysis

Upon stepping through the code and into the threads that were created, we observe that it only calls the module for persistence setting, but does not trigger any other features, and no flow exists to other portions of the code.

Perhaps this sample was for testing of persistence setting, and it does not do anything malicious yet, as there are several blocks of code that are not triggered.

In fact when we look at the code, nothing happens after setting persistence, and there is an empty switch case.

Conclusion

The embedded file was heavily obfuscated in terms of useless programming, for example, there were plenty of such stub code that did nothing but returns a boolean:

Also, many of the API calls were wrapped around gibberish function names. For example, these were the functions to convert values to different bases:

I would say therefore it’s almost impossible to rely purely on static analysis to deduce what the executable is doing. Other steps I could have done was to run it through a Cuckoo Sandbox to automate some of the findings.