Assessing risk in Office documents - Part 1: Introduction
Forcepoint Innovation Labs conducted a research project to see if we can evaluate risk associated with Microsoft Office documents without focusing on specific malware families. Anti-virus-engines need to be able to classify a document as malicious to block it, while we want to evaluate the level of risk a document carry without those constraints. Code, or the possibility of getting any code in any form, adds risk. If the level of risk is unacceptable we can then block/quarantine the document on our gateways.
We use a home-built setup of known tools to accomplish this as we will show in this series of blogs. We have used this experience to write our own in-house research-tool that will help us to automatically assess the risk posed by any document.
This blog is a tutorial that starts with the basics of malicious Office documents and hopefully will give you the knowledge we’ve built up during this research project to assess risk instead of depending on a clear AV engine conviction.
Understanding the Limitations of Microsoft Office 365 Security
Watch the WebcastThis 4 part blog series will contain the following blogs:
Part 1: Introduction to Office malware
The first part of this blog will cover some background for this project and do some introductions to risk found inside office documents. We will also manually analyse a simple PDF that contains macros and also showcase a tool we’ve developed to do this automatically. We will also see how an Office document in XML format can be used to store macros.
Part 2: Hide my code or download it?
In part 2 we will examine how various office documents use embedding and linking. We will provide different examples on how binary data gets embedded into Office documents and how malware use various forms of linking to download malicious content.
Part 3: Exploited “weaponized” RTFs
In part 3 we will focus heavily on obfuscated RTFs and how their obfuscation can hide the true nature of the documents. This is a complex area of exploit detection in Office documents, we’ll walk through a CVE-2017-12882 exploitation starting from an RTF file.
Part 4: Commonly used CVEs and general exploit detection
In part 4 we will cover a few more exploits for commonly used vulnerabilities in Office and close the series with some general exploit detection rules and insights we’ve gathered during this project.
And so to begin...
Part 1: Introduction to Office malware
People must share Office documents as a part of their daily job. Either done via email or other collaboration portals, due to security reasons inspection gateways nowadays need to deeply examine incoming documents before a user can access them. An email gateway these days strips attachments of any kind of executables (e.g. Windows portable executables) by default. As a result attackers have their best chance of getting their malware inside the targeted organization if they can blend their malware with the targeted organization’s document-stream. No organization can block all means of documents from flowing in or out.
Documents can be rather dangerous as we all know, as they can contain:
- malicious macro code
- embedded malware (i.e. executable code stored within the document)
- links to malicious content which will be downloaded on activation
- exploits of vulnerabilities that might run code on the system if it hasn’t been patched (considering a patch even exists)
Office documents
When we talk about Office documents, we focus on:
- Word Documents
- Excel Spreadsheets
- PowerPoint presentations
The content of these files can be saved in many different file-formats, however we’ll focus on the most prevalent ones used by malware.
Office macros
Malicious macros have been around since the birth of WM/Concept which ran under Microsoft Word. Macros are usually small pieces of code that are run when certain global conditions are met, like “AutoOpen” will be executed when you open a document. This means an attacker can run the macro code once the document gets loaded into your Office environment. Microsoft has added protection to let users control the execution of macros (enable or disable) if they are present, but 20+ years later it’s still an ongoing problem. We will discuss malicious macros later on in part 1.
Document formats
Microsoft documents can be stored in quite different forms. Older ones, like Compound File Binary Format (from this point on references to as the OLE2 file format) are still widely used, even though newer Office documents uses basically a ZIP archive with various files included in them. You can also save your office document in the RTF (Rich-Text-Format) file-format as well - as many other. All these formats have the ability to embed other files or objects such as executable code or scripts. Also there are objects that can link to external content. We will discuss embedding and linking in part 2.
Exploitation
Every program has bugs, some are more serious than others. If your application is receiving data you don’t control or has privileges that are attractive, attackers will try to find bugs in the code that will enable them to run their own code once the bug is exploited. A patch is simply a bugfix coming from the software vendor. Zero-day (0day) exploits are usually rare, as they take advantage of previously-unknown vulnerabilities that nobody has seen before. For example Stuxnet was known for using 4 zero-day exploits when it first arrived.
Adversaries are targeting well-known vulnerabilities that can apply to a broad audience. We will discuss exploits in more details, especially focusing on the Rich Text Format (RTF) in part 3.
An easy example in PDF format (Sample 1)
In this case we’ll start with a PDF that contains Office macros. Doesn’t that sound strange? A PDF is basically a “text-file” broken into sections/objects. You start looking into the structure of it by looking at the end of the file (startxref):
This tells us that the start of the xref table is located at offset 61489 (decimal). At this offset we’ll find the following data:
This tells us that there are 11 objects embedded into this PDF (+ the header). The first starts at offset 15 while the last start at offset 61325. If we have a look at object 2 (start 6006), we’ll see this statement declared:
This means that the data attached to this stream is compressed (FlateDecode). Once we use zlib to decompress this, we find this data underneath:
This structure tells us it’s a ZIP archive hidden within this object and that the first filename within the archive is [Content_Types].xml. If we run any unzip tool to list the files inside the archive we get the following:
Now we know this is a Word Document and it contains an interesting file called “word/vbaProject.bin”. This file is of the type OLE2, which is a legacy office document-structure still around – even in newer Word Documents as you can see. OLE2 files can be treated as archives. There are several tools you can use to look at the content within this OLE2 file, for instance oletools from Decalage. If you run their tool “vbadir” against this file “word/vbaProject.bin” you get the following output:
----+------+-------+----------------------+-----+-----+-----+--------+----- id |Status|Type |Name |Left |Right|Child|1st Sect|Size ----+------+-------+----------------------+-----+-----+-----+--------+----- 0 |<Used>|Root |Root Entry |- |- |1 |3 |9728 1 |<Used>|Storage|VBA |12 |17 |3 |0 |0 2 |<Used>|Stream |ThisDocument |- |10 |- |0 |2788 3 |<Used>|Stream |Module1 |5 |4 |- |F |16506 4 |<Used>|Stream |BounceCastle |8 |2 |- |32 |4515 5 |<Used>|Stream |Asck |6 |7 |- |2C |1867 6 |<Used>|Stream |F3 |- |11 |- |4A |1152 7 |<Used>|Stream |Class1 |- |- |- |42 |17019 8 |<Used>|Stream |Module3 |9 |- |- |65 |16088 9 |<Used>|Stream |Module2 |- |- |- |85 |18370 10 |<Used>|Stream |_VBA_PROJECT |- |- |- |A9 |9704 11 |<Used>|Stream |dir |- |- |- |5C |1030 12 |<Used>|Storage|F3 |- |- |14 |0 |0 13 |<Used>|Stream |f |- |- |- |6D |627 14 |<Used>|Stream |o |13 |15 |- |6F |620 15 |<Used>|Stream |\x01CompObj |- |16 |- |81 |97 16 |<Used>|Stream |\x03VBFrame |- |- |- |83 |287 17 |<Used>|Stream |PROJECTwm |18 |- |- |88 |197 18 |<Used>|Stream |PROJECT |- |- |- |8C |738 19 |unused|Empty | |- |- |- |0 |0 ----+----------------------------+------+----------------------------------
This tells us there are Visual Basic macros present (files present in the “Root Entry/VBA/” folder) which amongst others data contains the LZNT1 compressed source-code of the macros. You can use the olevba tool (also from Decalage) to show the source code and their heuristics:
+------------+----------------+-----------------------------------------+ | Type | Keyword | Description | +------------+----------------+-----------------------------------------+ | AutoExec | Document_Open | Runs when the Word or Publisher | | | | document is opened | | Suspicious | Chr | May attempt to obfuscate specific | | | | strings (use option --deobf to | | | | deobfuscate) | | Suspicious | Open | May open a file | | Suspicious | Binary | May read or write a binary file (if | | | | combined with Open) | | Suspicious | CreateObject | May create an OLE object | | Suspicious | Write | May write to a file (if combined with | | | | Open) | | Suspicious | Put | May write to a file (if combined with | | | | Open) | | Suspicious | User-Agent | May download files from the Internet | | Suspicious | CallByName | May attempt to obfuscate malicious | | | | function calls | | Suspicious | Hex Strings | Hex-encoded strings were detected, may | | | | be used to obfuscate strings (option | | | | --decode to see all) | | Suspicious | Base64 Strings | Base64-encoded strings were detected, | | | | may be used to obfuscate strings | | | | (option --decode to see all) | | IOC | rundll32.exe | Executable file name | +------------+----------------+-----------------------------------------+
Clearly the macros embedded into this PDF are up to no good and manual inspection on this sample wasn’t difficult at all. You can see the detection results from VirusTotal here.
Imagine doing this on thousands of PDFs every day? Surely there must be more effective ways of doing this type of analysis.
Automation of PDF processing
At Forcepoint, we use a home-grown research tool to do all this analysis automatically. When we run the tool against this PDF it will automatically:
- Identify the file as PDF
- Identify all the embedded objects within the PDF and deflates (decompress) them if necessary
- Handle any archives so it can inspect each file
- Handle the OLE2 file structure as an archive
- Give us physically extracted objects from all layers, should we want to do deeper analysis
- Find the VBA macros & extract the LZNT1 decompressed source code
- Check all objects for any code, known exploits or signs of exploits
The default output of the sample we have manually analysed will be as Sample 1 in Appendix B, but here is a shorter output:
-ScanObject("OLE2_FS" (16:"VBAx_MACRO",16506,"10b245bf1c6ec8702b30dcd556bdc1c6fc1f6bc4.file|object_2|word/vbaProject.bin|Root Entry/VBA/Module1")
-ScanObject("OLE2_FS" (16:"VBAx_MACRO",1867,"10b245bf1c6ec8702b30dcd556bdc1c6fc1f6bc4.file|object_2|word/vbaProject.bin|Root Entry/VBA/Asck")
-ScanObject("OLE2_FS" (16:"VBAx_MACRO",1152,"10b245bf1c6ec8702b30dcd556bdc1c6fc1f6bc4.file|object_2|word/vbaProject.bin|Root Entry/VBA/F3")
-ScanObject("OLE2_FS" (0:"UNKNOWN",1030,"10b245bf1c6ec8702b30dcd556bdc1c6fc1f6bc4.file|object_2|word/vbaProject.bin|Root Entry/VBA/dir")
-ScanObject("OLE2_FS" (16:"VBAx_MACRO",17019,"10b245bf1c6ec8702b30dcd556bdc1c6fc1f6bc4.file|object_2|word/vbaProject.bin|Root Entry/VBA/Class1")
-ScanObject("OLE2_FS" (16:"VBAx_MACRO",4515,"10b245bf1c6ec8702b30dcd556bdc1c6fc1f6bc4.file|object_2|word/vbaProject.bin|Root Entry/VBA/BounceCastle")
-ScanObject("OLE2_FS" (16:"VBAx_MACRO",16088,"10b245bf1c6ec8702b30dcd556bdc1c6fc1f6bc4.file|object_2|word/vbaProject.bin|Root Entry/VBA/Module3")
-ScanObject("OLE2_FS" (16:"VBAx_MACRO",18370,"10b245bf1c6ec8702b30dcd556bdc1c6fc1f6bc4.file|object_2|word/vbaProject.bin|Root Entry/VBA/Module2")
-ScanObject("OLE2_FS" (16:"VBAx_MACRO",2788,"10b245bf1c6ec8702b30dcd556bdc1c6fc1f6bc4.file|object_2|word/vbaProject.bin|Root Entry/VBA/ThisDocument")
Let me briefly explain the output format:
-ScanObject(“FILESYSTEM_NAME”, FILETYPE_ID, FILETYPE_NAME, size, Display-name-of-object)
The Display-name-of-object should be read like this (tokenized with |):
“10b245bf1c6ec8702b30dcd556bdc1c6fc1f6bc4.file|object_2|word/vbaProject.bin|Root Entry/VBA/ThisDocument"
Means the object “ThisDocument” has the following path within the structure of the original file:
10b245bf1c6ec8702b30dcd556bdc1c6fc1f6bc4.file
- object_2
- word/vbaProject.bin
- Root Entry
- VBA
- ThisDocument
- VBA
- Root Entry
- word/vbaProject.bin
An easy example in XML format (Sample 2)
As we mentioned in the beginning, Word Documents can be saved in many formats. One such format is XML. Let’s examine a XML document containing macros. XML is also a text-based file-format that can embed nearly anything.
The file we are about to analyze start with the current text:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <?mso-application progid="Word.Document"?>
This gives us some info that the file is UTF-8 encoded, and it’s meant as an MSO-application. If we search down the file we find something interesting:
This tag is called binData, and it looks like some base64 encoded data is embedded. If we extract this text and run it through a base64 decoder, we will get the following data:
echo QWN0aXZlTWltZQAAAfAEAAAA/////wAAB/D1EgEABAAAAAQAAAAAAAAAAAAAAADmAQB4nOycCVic1fX/76wZliQTsggkIRNCkgkJZFgCA2aZGbYhG5B1EkkYloEhYZkAAZJqOklcqLVKrVXUNMW4YZqJ | base64 -d | hexdump -v -C 00000000 41 63 74 69 76 65 4d 69 6d 65 00 00 01 f0 04 00 |ActiveMime......| 00000010 00 00 ff ff ff ff 00 00 07 f0 f5 12 01 00 04 00 |................| 00000020 00 00 04 00 00 00 00 00 00 00 00 00 00 00 00 e6 |................| 00000030 01 00 78 9c ec 9c 09 58 9c d5 f5 ff ef ac 19 96 |..x....X........| 00000040 24 13 b2 08 24 21 13 42 92 09 09 64 58 02 03 66 |$...$!.B...dX..f| 00000050 99 19 b6 21 1b 90 75 12 49 18 96 81 21 61 99 00 |...!..u.I...!a..| 00000060 01 92 6a 3a 49 5c a8 b5 4a ad 55 d4 34 c5 b8 61 |..j:I\..J.U.4..a| 00000070 9a 89 |..|
This looks interesting. The file within the base64 encoded blob starts with an ActiveMime header. At offset 0x32 you find a 0x78 which is a good sign that the data is compressed using zlib. If you want to know more about spotting compression algorithms using your eyes, read this. Let’s decompress the file to see what it hides:
00000000 d0 cf 11 e0 a1 b1 1a e1 00 00 00 00 00 00 00 00 |................| 00000010 00 00 00 00 00 00 00 00 3e 00 03 00 fe ff 09 00 |........>.......| 00000020 06 00 00 00 00 00 00 00 00 00 00 00 02 00 00 00 |................| 00000030 01 00 00 00 00 00 00 00 00 10 00 00 02 00 00 00 |................| 00000040 01 00 00 00 fe ff ff ff 00 00 00 00 00 00 00 00 |................|
As you can see, we now have an OLE2 archive again, and from the OLE2 file the same method as we used in the first example with the PDF can be applied again. The full output of our research tool is as Sample 2 in Appendix B. Below we’ve taken the most important lines:
-ScanObject("OLE2_FS" (16:"VBAx_MACRO",1105,"46bf76d348e6e778c5bc696fd33ba065518e75c6545d0205e9a6dc59b9f7d891|xmlObject21860|oleObject|Root Entry/VBA/b_58162")
-ScanObject("OLE2_FS" (16:"VBAx_MACRO",77269,"46bf76d348e6e778c5bc696fd33ba065518e75c6545d0205e9a6dc59b9f7d891|xmlObject21860|oleObject|Root Entry/VBA/R9_83__3")
-ScanObject("OLE2_FS" (16:"VBAx_MACRO",1105,"46bf76d348e6e778c5bc696fd33ba065518e75c6545d0205e9a6dc59b9f7d891|xmlObject21860|oleObject|Root Entry/VBA/b_58162")
-ScanObject("OLE2_FS" (16:"VBAx_MACRO",77269,"46bf76d348e6e778c5bc696fd33ba065518e75c6545d0205e9a6dc59b9f7d891|xmlObject21860|oleObject|Root Entry/VBA/R9_83__3")
As you can see it finds the embedded objects automatically and processes them. It also dumps the source-code of the LZNT1 decompressed source code of the macros. This is actually a downloader for the Emotet family.
As documents are often used to get their entry-code into a targeted organization, it’s very important to block or neutralize malicious code entering via e.g. e-mail – no matter who is sending them. Our gateways do analyse any documents for malicious content and block/quarantine suspicious entries.
What is next in Part 2?
You’ll get familiar with our research tool and how we use it in part 2 where we look at more complex malware in office documents, especially how they use linking and/or embedding.
[UPDATE] 21 May 2019: Part 2 is now available.
Appendix A - hashes
Sample 1 -10b245bf1c6ec8702b30dcd556bdc1c6fc1f6bc4 Sample 2 -46bf76d348e6e778c5bc696fd33ba065518e75c6545d0205e9a6dc59b9f7d891
Appendix B - tool output
Full output of Sample 1:
-ScanObject("GENERIC_FS" (4:"PDF",61894,"10b245bf1c6ec8702b30dcd556bdc1c6fc1f6bc4.file")
-ScanObject("PDF_FS" (0:"UNKNOWN",135837,"10b245bf1c6ec8702b30dcd556bdc1c6fc1f6bc4.file|object_1")
-ScanObject("PDF_FS" (7:"ZIP",57091,"10b245bf1c6ec8702b30dcd556bdc1c6fc1f6bc4.file|object_2")
-CouldNotScanObject("ARCHIVE_FS","[Content_Types].xml")
-ScanObject("ARCHIVE_FS" (5:"XML",590,"10b245bf1c6ec8702b30dcd556bdc1c6fc1f6bc4.file|object_2|_rels/.rels")
-ScanObject("ARCHIVE_FS" (5:"XML",939,"10b245bf1c6ec8702b30dcd556bdc1c6fc1f6bc4.file|object_2|word/_rels/document.xml.rels")
-ScanObject("ARCHIVE_FS" (5:"XML",1794,"10b245bf1c6ec8702b30dcd556bdc1c6fc1f6bc4.file|object_2|word/document.xml")
-ScanObject("ARCHIVE_FS" (1:"OLE2",98304,"10b245bf1c6ec8702b30dcd556bdc1c6fc1f6bc4.file|object_2|word/vbaProject.bin")
-ScanObject("OLE2_FS" (16:"VBAx_MACRO",16506,"10b245bf1c6ec8702b30dcd556bdc1c6fc1f6bc4.file|object_2|word/vbaProject.bin|Root Entry/VBA/Module1")
-ScanObject("OLE2_FS" (16:"VBAx_MACRO",1867,"10b245bf1c6ec8702b30dcd556bdc1c6fc1f6bc4.file|object_2|word/vbaProject.bin|Root Entry/VBA/Asck")
-ScanObject("OLE2_FS" (16:"VBAx_MACRO",1152,"10b245bf1c6ec8702b30dcd556bdc1c6fc1f6bc4.file|object_2|word/vbaProject.bin|Root Entry/VBA/F3")
-ScanObject("OLE2_FS" (0:"UNKNOWN",1030,"10b245bf1c6ec8702b30dcd556bdc1c6fc1f6bc4.file|object_2|word/vbaProject.bin|Root Entry/VBA/dir")
-ScanObject("OLE2_FS" (16:"VBAx_MACRO",17019,"10b245bf1c6ec8702b30dcd556bdc1c6fc1f6bc4.file|object_2|word/vbaProject.bin|Root Entry/VBA/Class1")
-ScanObject("OLE2_FS" (16:"VBAx_MACRO",4515,"10b245bf1c6ec8702b30dcd556bdc1c6fc1f6bc4.file|object_2|word/vbaProject.bin|Root Entry/VBA/BounceCastle")
-ScanObject("OLE2_FS" (16:"VBAx_MACRO",16088,"10b245bf1c6ec8702b30dcd556bdc1c6fc1f6bc4.file|object_2|word/vbaProject.bin|Root Entry/VBA/Module3")
-ScanObject("OLE2_FS" (16:"VBAx_MACRO",18370,"10b245bf1c6ec8702b30dcd556bdc1c6fc1f6bc4.file|object_2|word/vbaProject.bin|Root Entry/VBA/Module2")
-ScanObject("OLE2_FS" (16:"VBAx_MACRO",2788,"10b245bf1c6ec8702b30dcd556bdc1c6fc1f6bc4.file|object_2|word/vbaProject.bin|Root Entry/VBA/ThisDocument")
-ScanObject("OLE2_FS" (0:"UNKNOWN",9704,"10b245bf1c6ec8702b30dcd556bdc1c6fc1f6bc4.file|object_2|word/vbaProject.bin|Root Entry/VBA/_VBA_PROJECT")
-ScanObject("OLE2_FS" (0:"UNKNOWN",620,"10b245bf1c6ec8702b30dcd556bdc1c6fc1f6bc4.file|object_2|word/vbaProject.bin|Root Entry/F3/o")
-ScanObject("OLE2_FS" (0:"UNKNOWN",627,"10b245bf1c6ec8702b30dcd556bdc1c6fc1f6bc4.file|object_2|word/vbaProject.bin|Root Entry/F3/f")
-ScanObject("OLE2_FS" (0:"UNKNOWN",97,"10b245bf1c6ec8702b30dcd556bdc1c6fc1f6bc4.file|object_2|word/vbaProject.bin|Root Entry/F3/.CompObj")
-ScanObject("OLE2_FS" (21:"TEXT",287,"10b245bf1c6ec8702b30dcd556bdc1c6fc1f6bc4.file|object_2|word/vbaProject.bin|Root Entry/F3/.VBFrame")
-ScanObject("OLE2_FS" (0:"UNKNOWN",197,"10b245bf1c6ec8702b30dcd556bdc1c6fc1f6bc4.file|object_2|word/vbaProject.bin|Root Entry/PROJECTwm")
-ScanObject("OLE2_FS" (21:"TEXT",738,"10b245bf1c6ec8702b30dcd556bdc1c6fc1f6bc4.file|object_2|word/vbaProject.bin|Root Entry/PROJECT")
-ScanObject("ARCHIVE_FS" (5:"XML",277,"10b245bf1c6ec8702b30dcd556bdc1c6fc1f6bc4.file|object_2|word/_rels/vbaProject.bin.rels")
-ScanObject("ARCHIVE_FS" (5:"XML",6850,"10b245bf1c6ec8702b30dcd556bdc1c6fc1f6bc4.file|object_2|word/theme/theme1.xml")
-ScanObject("ARCHIVE_FS" (5:"XML",2172,"10b245bf1c6ec8702b30dcd556bdc1c6fc1f6bc4.file|object_2|word/vbaData.xml")
-ScanObject("ARCHIVE_FS" (5:"XML",6872,"10b245bf1c6ec8702b30dcd556bdc1c6fc1f6bc4.file|object_2|word/settings.xml")
-ScanObject("ARCHIVE_FS" (5:"XML",993,"10b245bf1c6ec8702b30dcd556bdc1c6fc1f6bc4.file|object_2|docProps/app.xml")
-ScanObject("ARCHIVE_FS" (5:"XML",28725,"10b245bf1c6ec8702b30dcd556bdc1c6fc1f6bc4.file|object_2|word/styles.xml")
-ScanObject("ARCHIVE_FS" (5:"XML",958,"10b245bf1c6ec8702b30dcd556bdc1c6fc1f6bc4.file|object_2|docProps/core.xml")
-ScanObject("ARCHIVE_FS" (5:"XML",1299,"10b245bf1c6ec8702b30dcd556bdc1c6fc1f6bc4.file|object_2|word/fontTable.xml")
-ScanObject("ARCHIVE_FS" (5:"XML",576,"10b245bf1c6ec8702b30dcd556bdc1c6fc1f6bc4.file|object_2|word/webSettings.xml")
-ScanObject("PDF_FS" (0:"UNKNOWN",102,"10b245bf1c6ec8702b30dcd556bdc1c6fc1f6bc4.file|object_3")
-ScanObject("PDF_FS" (21:"TEXT",110,"10b245bf1c6ec8702b30dcd556bdc1c6fc1f6bc4.file|object_4")
-ScanObject("PDF_FS" (21:"TEXT",87,"10b245bf1c6ec8702b30dcd556bdc1c6fc1f6bc4.file|object_5")
-ScanObject("PDF_FS" (0:"UNKNOWN",0,"10b245bf1c6ec8702b30dcd556bdc1c6fc1f6bc4.file|object_7")
-ScanObject("PDF_FS" (0:"UNKNOWN",0,"10b245bf1c6ec8702b30dcd556bdc1c6fc1f6bc4.file|object_6")
-ScanObject("PDF_FS" (0:"UNKNOWN",0,"10b245bf1c6ec8702b30dcd556bdc1c6fc1f6bc4.file|object_8")
-ScanObject("PDF_FS" (0:"UNKNOWN",0,"10b245bf1c6ec8702b30dcd556bdc1c6fc1f6bc4.file|object_9")
-ScanObject("PDF_FS" (0:"UNKNOWN",0,"10b245bf1c6ec8702b30dcd556bdc1c6fc1f6bc4.file|object_10")
-ScanObject("PDF_FS" (0:"UNKNOWN",0,"10b245bf1c6ec8702b30dcd556bdc1c6fc1f6bc4.file|object_11")
Full output of Sample 2:
-ScanObject("GENERIC_FS" (5:"XML",301443,"46bf76d348e6e778c5bc696fd33ba065518e75c6545d0205e9a6dc59b9f7d891")
-ScanObject("MEM_FS" (12:"ACTIVEMIME",122703,"46bf76d348e6e778c5bc696fd33ba065518e75c6545d0205e9a6dc59b9f7d891|xmlObject21860")
-ScanObject("MEM_FS" (1:"OLE2",124416,"46bf76d348e6e778c5bc696fd33ba065518e75c6545d0205e9a6dc59b9f7d891|xmlObject21860|oleObject")
-ScanObject("OLE2_FS" (21:"TEXT",415,"46bf76d348e6e778c5bc696fd33ba065518e75c6545d0205e9a6dc59b9f7d891|xmlObject21860|oleObject|Root Entry/PROJECT")
-ScanObject("OLE2_FS" (0:"UNKNOWN",106,"46bf76d348e6e778c5bc696fd33ba065518e75c6545d0205e9a6dc59b9f7d891|xmlObject21860|oleObject|Root Entry/VBA/__SRP_1")
-ScanObject("OLE2_FS" (16:"VBAx_MACRO",1105,"46bf76d348e6e778c5bc696fd33ba065518e75c6545d0205e9a6dc59b9f7d891|xmlObject21860|oleObject|Root Entry/VBA/b_58162")
-ScanObject("OLE2_FS" (0:"UNKNOWN",559,"46bf76d348e6e778c5bc696fd33ba065518e75c6545d0205e9a6dc59b9f7d891|xmlObject21860|oleObject|Root Entry/VBA/dir")
-ScanObject("OLE2_FS" (0:"UNKNOWN",1223,"46bf76d348e6e778c5bc696fd33ba065518e75c6545d0205e9a6dc59b9f7d891|xmlObject21860|oleObject|Root Entry/VBA/__SRP_0")
-ScanObject("OLE2_FS" (0:"UNKNOWN",66,"46bf76d348e6e778c5bc696fd33ba065518e75c6545d0205e9a6dc59b9f7d891|xmlObject21860|oleObject|Root Entry/VBA/__SRP_3")
-ScanObject("OLE2_FS" (0:"UNKNOWN",220,"46bf76d348e6e778c5bc696fd33ba065518e75c6545d0205e9a6dc59b9f7d891|xmlObject21860|oleObject|Root Entry/VBA/__SRP_2")
-ScanObject("OLE2_FS" (16:"VBAx_MACRO",77269,"46bf76d348e6e778c5bc696fd33ba065518e75c6545d0205e9a6dc59b9f7d891|xmlObject21860|oleObject|Root Entry/VBA/R9_83__3")
-ScanObject("OLE2_FS" (0:"UNKNOWN",39281,"46bf76d348e6e778c5bc696fd33ba065518e75c6545d0205e9a6dc59b9f7d891|xmlObject21860|oleObject|Root Entry/VBA/_VBA_PROJECT")
-ScanObject("OLE2_FS" (0:"UNKNOWN",53,"46bf76d348e6e778c5bc696fd33ba065518e75c6545d0205e9a6dc59b9f7d891|xmlObject21860|oleObject|Root Entry/PROJECTwm")
-ScanObject("MEM_FS" (12:"ACTIVEMIME",122688,"46bf76d348e6e778c5bc696fd33ba065518e75c6545d0205e9a6dc59b9f7d891|xmlObject21860")
-ScanObject("MEM_FS" (1:"OLE2",124416,"46bf76d348e6e778c5bc696fd33ba065518e75c6545d0205e9a6dc59b9f7d891|xmlObject21860|oleObject")
-ScanObject("OLE2_FS" (21:"TEXT",415,"46bf76d348e6e778c5bc696fd33ba065518e75c6545d0205e9a6dc59b9f7d891|xmlObject21860|oleObject|Root Entry/PROJECT")
-ScanObject("OLE2_FS" (0:"UNKNOWN",106,"46bf76d348e6e778c5bc696fd33ba065518e75c6545d0205e9a6dc59b9f7d891|xmlObject21860|oleObject|Root Entry/VBA/__SRP_1")
-ScanObject("OLE2_FS" (16:"VBAx_MACRO",1105,"46bf76d348e6e778c5bc696fd33ba065518e75c6545d0205e9a6dc59b9f7d891|xmlObject21860|oleObject|Root Entry/VBA/b_58162")
-ScanObject("OLE2_FS" (0:"UNKNOWN",559,"46bf76d348e6e778c5bc696fd33ba065518e75c6545d0205e9a6dc59b9f7d891|xmlObject21860|oleObject|Root Entry/VBA/dir")
-ScanObject("OLE2_FS" (0:"UNKNOWN",1223,"46bf76d348e6e778c5bc696fd33ba065518e75c6545d0205e9a6dc59b9f7d891|xmlObject21860|oleObject|Root Entry/VBA/__SRP_0")
-ScanObject("OLE2_FS" (0:"UNKNOWN",66,"46bf76d348e6e778c5bc696fd33ba065518e75c6545d0205e9a6dc59b9f7d891|xmlObject21860|oleObject|Root Entry/VBA/__SRP_3")
-ScanObject("OLE2_FS" (0:"UNKNOWN",220,"46bf76d348e6e778c5bc696fd33ba065518e75c6545d0205e9a6dc59b9f7d891|xmlObject21860|oleObject|Root Entry/VBA/__SRP_2")
-ScanObject("OLE2_FS" (16:"VBAx_MACRO",77269,"46bf76d348e6e778c5bc696fd33ba065518e75c6545d0205e9a6dc59b9f7d891|xmlObject21860|oleObject|Root Entry/VBA/R9_83__3")
-ScanObject("OLE2_FS" (0:"UNKNOWN",39281,"46bf76d348e6e778c5bc696fd33ba065518e75c6545d0205e9a6dc59b9f7d891|xmlObject21860|oleObject|Root Entry/VBA/_VBA_PROJECT")
-ScanObject("OLE2_FS" (0:"UNKNOWN",53,"46bf76d348e6e778c5bc696fd33ba065518e75c6545d0205e9a6dc59b9f7d891|xmlObject21860|oleObject|Root Entry/PROJECTwm")