Thursday, Warm and cloudy.
“Open me! I am a payment order! I am important, I swear!”, - some RTF-file was yelling. I wasn’t expecting any bills so this slyboots did not maim my poor little laptop. Phew ! Lucky me! But since this was a social engineering attack (not very crafty but still), someone less concerned with his or her safety could have opened it and cause him- or herself a lot of trouble. What I am trying to say (very inarticulately ) is that simply opening a small RTF document could result in absolute disaster for your machine! In this post I am telling the story how exactly does it happen…
Tools: Hiew 3.0.5000, RTFScan v0.26, OfficeMalScanner, sha1deep.exe, Notepad++
Environment: Win7x64 (VBox Version 5.2.16 r123759 (Qt5.6.2))
SHA-1: 295594a3374a0a264ec0885d22cad2bbbe378c5f
12:12. Some time ago I ran into some RTF file and after spending some time with it I learned how these little fellows function. I am not claiming to be an expert though, I just now know a little bit better what to be aware of and where to look. So, when that day I opened the document and saw this, I knew that was not smelling good:
Two nice light green squares are pointing at those suspicious portions of the document. First is saying that there might be an Excel embedded. The second is proving these suspicions.
So, as you can clearly see from the picture above, there was an Excel file embedded (likely), and I know pretty damn well that if you see some office document, it might be equipped with some deleterious macro script. As shown on the screenshot, there is also some sequence of bytes: d0cf11e0 which is a signature of an office document. Here is some reference regarding different signatures.
About OLE documents.
Well, the first question was how to extract this from the file?
I opened my VM and ran a RTFScan agains it with the following command:
RTFScan C:\Users$herl0ck\Documents\4-Docs\malware.rtf scan
and this is what I have got as a result:
Yellow box serves to highlight the command and the green ones - to show that the scanner has found 5 OLE objects embedded.
So, I saw that I was right! There were these weeds in that RTF document! What is exactly an OLE object anyway?
There are 5 OLE_DOCUMENT__malware__.bin named by RTFScanner when making a dump. Let’s see… I’ll copy one of these names and search my VM for it (the scanner doesn’t save them in the current directory and having a squirrel-like memory, alas!) I don’t remember where to look for it.
At the destination I found all the five “prisoners” and copied them to my host to view in hex. Scrolling the first dumped OLE object almost to the very end, I noticed very familiar strings (“Dim”, “For i = 13 To 85”, “String = “dkV…”) indicating that there WAS macro lurking inside!
Next questing I asked myself was “Are they all different?” Pulling a sha1deep.exefrom my toolkit, I have calculated the hash and it turned out to be the same (9a9ba8040952200d264637d0b2001225de826dc4), proving me right! So, no need to analyze them all, one would be enough.
Ok, once I got that OLE dump I need some tool to extract macro code. Let’s see… Aha! OfficeMalScanner will do the trick. Righty-right! Off we go with that:
Very well. Now all I need to do is follow that path shown and have a look at the macro extracted.. I have a string feeling I am about to finish this journey.
I usually use Notepad++ for viewing scripts since it supports multiple programming languages for highlighting the code and has some other useful additional features.
From the first glance at the code I can make a conclusion that I should never ever rejoice upon task completion before it is actually completed … This code is highly obfuscated and needs more effort from my part. There are several ways to accomplish that:
- decode it manually in text editor (no way I am doing that!)
- run it in VM and see what it has done
- trow it into a sandbox
- use some Office with macro enabled, put breakpoints at the end of the payload and look at the contents of the variables.
Opening the document using the application where it belongs revealed social engineering content.
13:03. Need a break…
13:15. After having a nice break I can get back to the file.
def simple_decipher (p_string, p_key):
result = “”
count = 0
while count < len(p_string):
result += chr(int(p_string[count:count + 2], 16) – p_key)
count += 2
print(result)
return result
simple_decipher(“8CA0A1AB8FA7AAA39AA7A7A366B1A5A68DAB979EA1AD”, 56)
simple_decipher(“8F8B9BAAA1A8AC668BA09DA4A4”, 56)
simple_decipher(“8AADA6”, 56)
And the resulting decoded strings are these:
ThisWorkbook.ymnUs_fiu
WScript.Shell
Run
…which reveals the intentions pretty well:
CallByName CreateObject(I_RZl("8F8B9BAAA1A8AC668BA09DA4A4")), I_RZl("8AADA6"), VbMethod, I_RZl(ThisWorkbook.Sheets("Opto").Range("H211").Value), 0, True
Code refers to some Opto Sheet, but there is no such thing in the whole document! Why?! I’ve really searched for the entire document and its structure, no such thing as “Opto Sheet”… And the it struck me like a lightning bolt! What if I open it in Hiew again and search for “Opto”…
Voila!
Let’s copy these hex digits and run my Pthy against it… Aha! That’s interesting…. Deserves further investigation ! To make it easier to look through, it’s better to view it in Notepad++ with Batch as a language to beautify it a bit…and ta-da! My efforts have finally paid off. Look at this pearls!
Orange square shows the target path on the local system. Green one - where to download some file from. Blue line underlines the user-agent. Sometimes it’s used by malware authors to filter requests for download. Thus, if you use default user agent, the server might respond with 404 (File not found) or some other code. That means you won’t be able to download it without explicitly specifying that thing. In this very case, however, server willingly responded to the default request without the need to set user agent to this: ‘WSK’.
What can I conclude looking at that script? First, the author has lots of free time. Second: the script likely downloads .exe and .doc (which is what it claims to be downloading. Doesn’t mean that’s true). Let’s go where it’s pointing to!… Where is my dragon ? Kali Linux has a great tool at its disposal: wget. I can specify parameters and HTTP headers like this:
If there would be user-agent problem, I could specify it like this:
wget https://somewebsite.com/somecreepystuff.exe -user-agent=“WSK”
Alternatively, I could use Postman, which is a good GUI tool for crafting HTTP requests, but I won’t. May be some other time.
So! I think I might have been carried away too far. What have I just downloaded? Well-well… looks like the malicious code did less lying than I thought: that was true, one .exe file and one .doc. The first one is detected as Injector by lots of antivirus agents. But I thing it was quite obvious from the very beginning that nothing good is coming out of it: well, how many times do you see a simple document perform so much creepy stuff without you even being aware? As far as I’m concerned, never.
Aha! It’s trying to convince me that it’s an Excel document… or Excel installer. Ha-ha! Nice try. However, some PCs are configured in a way that most file formats are not displayed. So, it this case a user might not even see .exe ending. This x1.exe (SHA-1 is 535261b8fca79bdaa25a335b31b64b35c4244ab2) drops something and launches another program. But that’s whole other story, friends.
Off for now, dear diary!