Emotet (2020-07-21): Still Making Use of Userforms

DISCLAIMER: Today’s sample is not overly complicated at all. Making use of Userforms is nothing new. Also, anyone can toss an Emotet document into Any.run in order to grab the base64 encoded Powershell string being executed.

Yet, malicious documents are hiding commands that must be run on the system in some way. Finding those locations and understanding how they work can help us better understand the techniques, tactics, and procedures (TTPs) of attackers.

Sample: https://app.any.run/tasks/475e4427-efd3-40c6-a19f-8703552d0194
MD5: 6f6987737db0575b978f60be457cd374
SHA256: 12A9D51F23B64A1C6DC2146C8325AD73C6810CCDA73586EEF181C4CDDB309A99

Where We’ve Been

If you are familiar with the typical behavior of an Emotet document at all, you expect WINWORD.exe or WmiPrvSE.exe to spawn powershell.exe and pass it a big string of base64 encoded text. That base64 string decodes to a variety of commands that attempt to download an .exe from one of five URLs.

Yet, where does that string live in the malicious document? Sometimes it is scattered all over the the macro before it gets concatenated. Here’s an emotet sample from February 2019. It is quite easy to see how the powershell command and the base64 string get assembled.

At other times, the macro references and grabs strings from a Userform. In this example from May 2019, we see two Userforms named F82063 and N9_9818.

Can someone ask Microsoft to give Snip & Sketch the ability to draw straight lines?

Notice how the macro references components within that Userform. While we can see only one empty box within the Userform above, there are really a stack of them on top of each other. They each have their own name and contain some sort of text. Again, it is not too difficult to see how they will get rearranged into the familiar “powershell -e JAB…”

Where We Are Today

Emotet documents are still making use of Userforms, but with a minor twist. In this sample, the long string is brought back into the macro, split apart, and then joined to create the “powershell -e JAB…” string.

These are all of the components in the Userform named woicroib. It contains a variety of ComboBoxes, Frames, and even a MultiPage.

This macro line below references the Userform containing the the encoded text. woicroib is the name of the Userform. raopfeukchaup is a MultiPage component within the Userform. raopfeukchaup contains two pages. The ControlTipText is then grabbed from the second page. However, it looks like that box is empty.

But this is not the case. If we put a cursor in there, select all of it (ctrl + A) and then copy (ctrl + C) and paste it in notepad, we get this giant string. How is it going to be used in the macro?

Returning back to the macro, the above string is tossed into variable io (line 66). This becomes the parameter used in function chiexbeachjeuhkiam (lines 69 and 49). The entire string above is split (line 53) on another string of characters and then joined back together in line 59.

We can emulate this behavior quite easily. Within our notepad document, we can do a simple search for the string in line 53 above and when we replace all of them with nothing…

… we get the powershell string!

And as my calculus teacher in college used to say, we’ve reduced this to a previously solved problem.

Thanks for reading!

AgentTesla: .rtf and Equation Editor

While extracting Equation Editor shellcode is nothing new on this blog, it never hurts to practice the skills necessary to do this. To that end, we will be working on this document right here: https://app.any.run/tasks/0a1096aa-339e-4602-a3e0-2496a07efea4

.rtf document?

Using rtfdump.py against the document, we see that item 8 contains objdata. This is a good place to start.

We can select item 8 (-s) and decode it as hexadecimal data (-H) in order to take an initial look at that object. We can see that this object contains a call to Equation Editor (EQNEDT32.exe).

To extract this as a file, we will decode it as hexadecimal (-H), dump it (-d), and then send the output to another file which we will call output.bin.

We can use XORSearch.exe to search that binary file for various signatures of 32-bit shellcode. We see that GetEIP was found in two locations. This indicates that shellcode might start at 0xF2. This information will be useful in the next step.


scDbg.exe is a shellcode emulator. If we load up our .bin file and start with the offset of 0xF2, decoded shellcode may appear.

Based on the output, it looks like we had a good offset address. We can tell because we see some decoded lines… but not too many decoded lines. However, we’ve seen ExpandEnvironmentStringsW before and we know how to deal with that. Notice also where it says “Change found at 706…” and that it dumped to a new file called output.unpack.

The change was found at position 706. This means that there are a bunch of extraneous characters before our useful shellcode. While there are a variety of ways to get rid of them, cut-bytes.py will also do the trick.

We can see a variety of useful strings by opening output-cut.unpack in a hex editor.

One of the reasons we didn’t get this output before was that the shellcode used ExpandEnvironmentStringsW. scDbg.exe doesn’t hook into that function. Instead, it will hook into ExpandEnvironmentStringsA. If we overwrite the W in our file with an A, we ought to be able to get some much cleaner output.

Save your changes and toss it back into scDbg.exe. Note, there is no need to include an offset address or create a dump.

We now have the decoded shellcode!

Thanks for reading!