Reversing A Malicious Office Document — Part 01
So as I mentioned, I was going to tear apart a document for fun and go over it on here. I like looking at malicious Office documents, for one, they still play a large part in infections mostly as droppers, as it was reported 43% of infections in 2020 were due to malicious Office documents, and a large amount come from Google Drive. And secondly, I feel they are less tedious to stare at compared to malicious binaries and they more often include an aspect of social engineering to get the victim to play along and enable macros which is interesting to me as well.
Anyways, lets get to it.
I should start off by mentioning that this is a real malware sample, this is not a toy sample, execution of this on your Windows system will trigger a real piece of malware to execute, so if you download the sample to follow along make sure you have an environment setup so you don’t cause any real damage.
— — — — — — — — — — — — — — — — -
Sample Details:
SHA256–6fa01dcf027dcdc6d59d16e4ebc4a5b29a9ab3672039a8292c9b3f8086f0cf9d
Family — Emotet
File Type — XLSM
— — — — — — — — — — — — — — — — -
For today, we will be going over the initial analysis of the sample, as I have not seen this sample ever, I just went out and downloaded the first Emotet sample I could find online to keep it interesting. The first thing I do is make sure my internet is off on my sandbox so I don’t have any accidental comms going out and talking to C2 in case the sample’s C2 is still alive.
Upon opening the sample, the first thing that pops out is the warning of needing to move this sample to different directory and to enable macros; typical malicious Office document stuff.
The next thing I decided to do was check all of the sheets for VBA Macros, and unfortunately none of them had macros, so you know what that means… Either there is a very hidden sheet with macros, or this will all purely be DDE macros for Excel. The next thing to do was to check for where this document tries to start its execution, this can generally be found by looking at the Auto Open tab in the top left of the sheet.
Once selecting Auto Open it will move us to the cell that is the first to be execute, however, this shows nothing… because they shrank the column down to make it not initially obvious.
Upon expanding the cell and looking at the macro inside, we see the following
Yep, this screams malicious with the obvious form of obfuscation occurring here. So lets figure out what it does by copying it to notepad and manually deobfuscating it.
Yeah… I got about 10 cells in and said nope… Lets use OLEVBA to do some of the work for us.
After running OLEVBA we get a much better idea of whats going on here, we can also see at the bottom some static properties it deems suspicious, which is nice when trying to get a better idea of what we have here. It should be noted though, a file download or a call to a DLL does not mean a macro is malicious, it just should be considered a red flag during analysis to investigate more. This is great and all, but its not exactly clean so lets copy and paste it into VSCode so we can read it better.
Now that we have that cleaned up, we can see this macro is using urlmon.dll to call URLDownloadToFileA a few different times, this indicates this is either multiple payloads for execution, or this may be a method to increase chances of infection if one or multiple of those URLs are blocked. Once this payload is downloaded, it then calls regsvr32.exe to register the payload as a command.
Here is some additional information from MITRE on this technique.
So that’s the extent of this Emotet variant, it can be expected that next the registered components will handle the next stages of infection, whatever the may entail. In the next blog post, lets try to get those payloads and crack them open to see whats going on!
