SRP streams in Microsoft Office documents can reveal older versions of VBA macro code used by the adversary in earlier attacks. After the attacker modifies the malicious document for a new attack, Microsoft Office sometimes retains a cache of the earlier macro inside these streams, allowing analysts to expand their understanding of the incident and derive valuable threat intelligence. In other words, SRP streams can help investigators travel back in time.
Malicious VBA Macros inside a Word Document
Consider the real-world malicious Microsoft Word document named DIAN_caso-5415.doc. When the victim opens the file, Word informs the person that the embedded macros have been disabled. The document is crafted to social-engineer the victim into allowing the macros to run. (To learn how such macros work, see How Malicious Code Can Run in Microsoft Office Documents.)
One approach to extracting the embedded VBA macros is to use OfficeMalScanner, a free command-line tool designed for analyzing suspicious Office files. (For more on this tool, see Extracting VB Macro Code from Malicious MS Office Documents.)
OfficeMalScanner automatically locates and extracts the embedded VBA macro code. We can examine it using a regular text editor now:
After the victim allows macros to run, then Microsoft Word will automatically execute the AutoOpen() function. In the specimen above, this will lead to the execution of Auto_Open(), which will execute SNVJYQ(), which will call OGEXYR(), which will download test.exe, save it and silently run it as "sfjozjero.exe" from the "%TMP% folder". The malicious macro will also download counter.php from the same host, saving it as the file "lkjljlljk" into "%TMP%". (Don't visit those URLs; they are malicious.)
After infecting the system, the macro will present the victim with a pop-up, stating in Spanish that "contents of this document are not compatible with this system." Then Microsoft Word will exit, leaving malware running in the background.
So far, we followed a classic approach to examining suspicious Microsoft Office documents with embedded VBA macros. I'd like to propose looking at other aspects of this file to obtain additional details about the attack or the attacker.
Additional URLs inside an SRP Stream
To take a closer look at the internals of the malicious Office document, we can load it into Structured Storage Viewer (SSView), a free tool for examining and modifying internal aspects of binary OLE Structured Storage files. The Summary Information area displays meta information embedded into the file. For instance, an analyst might look at the "Author" or "Last saved by" properties to associate multiple files with a single adversary, while recognizing that these values could be faked. But wait, there is more...
Perhaps more interestingly, SSView allows analysts to navigate through the structure of the binary Office file and examine contents of the embedded streams. Of particular interest to this article are the streams with names that start with the __SRP_ prefix. In our specimen, take a look at the text embedded into the __SRP_0 stream:
We seem to be looking at VBA code similar to the macro that we extracted using OfficeMalScanner. Yet, the version of the code concealed inside the __SRP_0 stream is using a different URL (linksur) for downloading the malicious executable! Also, this "shadow" macro is saving the downloaded program using a different local file name. It also includes another URL:
These URLs are stored inside the __SRP_0 stream as Unicode strings. You would see them when extracting strings from the malicious file the traditional way, as long as your tool is able to extract Unicode content. Keep in mind that if you only look at strings, you don't get as many details regarding the use or nature of the string. In contrast, a specialized tool such as SSView tells as the roles that these strings might play.
You might assume that "linksur" and Bitly URLs in the __SRO_0 stream are being used against the current victim; in reality, these strings are cached artifacts of an earlier version of the malicious macro, probably used to attack someone else.
We can obtain information about the Bitly-shortened link above by appending "+" to the end of the URL and visiting the resulting URL with a web browser. (It's best to do this from a lab system, just to be safe.) The Bitly website reveals statistics about the shortened link, indicating that it was visited over 4,000 times. The majority of the visitors were in Chile.
When discussing the DIAN_caso-5415.doc file Dmitry Bestuzhev wrote that the document was emailed to victims in Colombia. Based on the data embedded in the __SRO_0 stream, we can form a theory that the adversary initially targeted people in Chile using an earlier version of this file. We can also derive additional indicators of compromise at the network level (URLs) and at the host level (file names), which might help us spot multiple versions of the malicious document, should it be used against our environment.
The Nature of SRP Streams in Office Documents
How does such information end up in SRP streams? Microsoft Office often includes streams with names that start with __SRP_ inside documents that contain VBA macros. However, Microsoft doesn't clearly explain the nature of these streams beyond saying the following:
"[SRP Streams] specify an implementation-specific and version-dependent performance cache. MUST be ignored on read. MUST NOT be present on write."
An article on VBA Project Storage suggests that SRP streams store the compiled version of VBA macros and are automatically created by Microsoft Office it runs the macros. Could such streams give us a peak at the earlier versions of the malicious document? I think so.
To test this theory, I used Microsoft Word 2013 to create a benign .docm document with the following macro:
Sub AutoOpen() Set WshShell = CreateObject("WScript.Shell") WshShell.Run "notepad.exe", 1, False End Sub
It instructs Word to automatically run Notepad when the user opens the document and enables macros. To understand how macros are stored in this file, I first used the OfficeMalScanner "inflate" command to expand the document's contents and extract the vbaProject.bin file.
If document was saved using newer non-binary formats (e.g, .docm, xlsm, pptm), then Microsoft Office embeds VBA macros inside the binary OLE Structured Storage file named vbaProject.bin. Analysts can examine the structure and contents of the file with the help of SSView. SSview showed that my initial test document didn't have any SRP streams.
Next, I attempted to mimic the actions of an attacker who wishes to modify the macros in the original malicious document. To do this, I revised my .docm file to launch Calculator instead of Notepad. To do this, I opened the original file in Microsoft Word, allowed macros to run (which launched Notepad), then clicked on View > Macros.
Sub AutoOpen() Set WshShell = CreateObject("WScript.Shell") WshShell.Run "calc.exe", 1, False End Sub
Not surprisingly, OfficeMalScanner was able to extract the Calculator macro and didn't show any mention of Notepad that was present in the macro's original code. However, SSView showed that vbaProject.bin file inside the modified document had several SRP streams:
Most interestingly, the __SRP_0 stream contained the "shadow" of my initial Notepad macro:
If you'd like to experiment with my non-malicious Microsoft Word macros, you are welcome to download the documents that contain them.
Keep an Eye on SRP Streams
It appears that Microsoft Office automatically embeds a cached version of the earlier VBA macro inside SRP streams even after the attacker modifies the malicious code. Though these old contents of SRP streams don't execute when the victim opens the document and allows macros to run, they are available to analysts for investigation. VBA code in SRP streams can reveal the adversary's earlier attack mechanics, helping expand the understanding of the incident's context. It would be very interesting to automate the extraction and parsing of SRP stream contents.
For another example of a malicious Microsoft Office document that includes a cache of earlier macros in SRP streams, see my post on attacker's use of social engineering to persuade victims to enable macros.