Extracting Encoded Shellcode Out Of OLEStream

So I recently came across an interesting XLSX sample in the wild. After looking at the sample it seems like an innocent empty XLSX file roaming around. Digging it deeper reveals some interesting things about it. This sample is being propagated (using malware spam) with the name: RFQ-PO220523-supply order.xlsx

7ed0586b68a24bbe7cb29852beb48f2c6a625af46d2fbc3c652d552aa1b1bb5b

Straightforward opening the XLSX gives you 3 sheets (all empty) as seen in the below screenshot, with no activity.

(Fig. Empty Sheets)

Anyways, let us go directly with the well-known oletools and get a much quicker view of what's going on behind the scenes. Using oledump on the file directly gives us some interesting results seen below.

(Fig. oledump results)

We can see that there is an OLEStream (\1Ole10Native) at A1 (or index 1) that we should definitely have a look at considering that's where the juicy stuff is all the times in such files. Let's dump this stream using the following command:

oledump -s 1 -d 7ed0586b68a24bbe7cb29852beb48f2c6a625af46d2fbc3c652d552aa1b1bb5b.xlsx > olenative.bin

Opening the dump in the hex editor (HxD) give us nothing and we couldn't get anything out of it that we could directly make a meaning out of.

(Fig. Hex Dump - OLE Stream)

Now, where do we go from here? In a typical scenario where suspect the presence of shellcode in the OLE stream, we directly go with the tool called scdbg that finds the possible shellcode entry points and executes them. Doing the same with this dump gives us nothing useful as seen in the below screenshot.

(Fig. scdbg)

This means that the shellcode entry point clearly is not at the start of the dump. Using other options that allows us to emulate the possible offsets also fail.

(Fig. All these offsets fail)

This is a clear indication of the shellcode being encoded in some way. The easiest way to figure out is to use the tool called xorsearch. This tool has well-known methods used to encode the shellcode, specifically XOR, ROL, ROT or SHIFT encoded with a list of pre-defined key.

(Fig. xorsearch to find shellcode entrypoint)

Now, we can see that the tool has successfully found shellcode entry point using XOR method at the offset: 000C18C8. That's it, let's get back to scdbg and feed this offset as an entry point to execute and extract the shellcode from the dump.

(Fig. Extracted Shellcode)

Boom! We now have the extracted shellcode in front of us. We can see that the shellcode is trying to download an executable payload from the compromised domain. It tries to download from hxxp://zpec[.]ru/bitrix/admin/bebbn[.]exe and saves it at %APPDATA%\batterysaver[.]exe using a typical Windows API - URLDownloadToFileW.

Note: This URL throws 404 (Not Found) error as of writing this blog post. I couldn't find traces of this payload on VT either. Seems like the domain owner has cleaned-up this malicious executable.

Indicators of Compromise

• 7ed0586b68a24bbe7cb29852beb48f2c6a625af46d2fbc3c652d552aa1b1bb5b
• hxxp://zpec[.]ru/bitrix/admin/bebbn[.]exe