On occasion I go hunting in various sandboxes by scrolling down the list of submissions to look for something interesting to look at.
I don’t normally see that many PowerPoint samples So I took an interest in this one that was marked as suspicious at the time.
This file Here on InQuest Labs.
We see some vba code and bitly[.]com link so defiantly suspicious.
We also see there is a distinctive file path in the code but it gets picked up as a domain name.
So as of this post there are now 58 hits for the path string.
So I chose a file the was listed as malicious to see what it looked like.
This file Here on InQuest Labs.
Scrolling this file we now see it has an autopen function so why the difference.
Normally I will use 7Zip to decompress the document and then navigate to the ppt folder.
Generally you would see a filename similar to VBAProject.bin but in this case we see it as “dsjhfsfhsjfh.c”
If we open this with a hex editor we can see it has the header bytes of “D0 CF 11 E0” telling us we are in the right place.
Now 7Zip does not like this file extension so if we change it to “.bin” we can use it to decompress this data further.
Now this is the file marked as “suspicious”.
We notice something is defiantly different here.
This is the malicious one we can see it has a different file extension also.
We see the same filenames and sizes as the other one.
We can see there is more information here.
My next step is usually to copy paste the bytes into my decompress tool.
This tool uses the decompression function from oledump that decompresses the macro code.
I converted the python to vb dot net.
As you see here with the malicious version we have no problem extracting the vba.
There is nothing to extract from the suspicious one.
Lets look at the suspicious project data again.
We can see here that there is an auto open function but it is not showing up in the decompressed file.
I next looked at the 2 files in oledump.
As you would expect both vba macros are listed as upper case “M” that usually tells us that they contain Macro Code.
Now looking at the suspicious version we see that one of the macrocode is listed as a small “m”.
This tool works by searching from the “Attribut” string and then getting the start to ending of this section.
To be honest even though I got it to work doing the conversion I’m still not 100 % sure how it works.
I can read thru the compression and see what it is doing but it is not the same as decompressing it for possible odd code segments.
So my next step was to ping Didier Stevens @DidierStevens with some screenshots and a questions about the small “m” in this case giving a false sense.
After some time her released a brilliant ISC Diary on this type of sample Here .
So Armed with this information about the file format I can better extract the data.
Here is the entire “Stream” from that vba code.
We lean from the diary that byte 2 and 3 contain the length parameter and a flag for the data after the null byte.
So from the diary we need to read bytes 2 and 3 in little Endian.
So it would be B0 20 and the B is a flag and the length would be 0x020 but that is much shorter than what we see here so we need to modify this value to B1 59 which when we do a replacement would be 59 B1.
So now that we fixed that length we can decompress it .
Now that we answered the question of what the difference is let’s look at the question of why I/We should care.
Even though these files get “Cleaned” we still need to know that they exist and may get overlooked as an IOC because they are no longer able to be malicious.
What if the file did it’s “Bad” first before it got “Cleaned”?
We would still need to extract some information that may give us further IOC’s.
That is for this one I hope you learned something too.
ICS Diary Here