{ "id": "c7513615-6f1a-455d-a636-7e3e9ad1b83a", "created_at": "2026-04-06T00:14:46.311022Z", "updated_at": "2026-04-10T13:12:36.41813Z", "deleted_at": null, "sha1_hash": "8d69e0feb1a3aaf8821b6497d8df8f59b33885ee", "title": "oleObject1.bin – OLe10nATive – shellcode", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 199716, "plain_text": "oleObject1.bin – OLe10nATive – shellcode\r\nBy Published by Jamie\r\nPublished: 2021-03-06 · Archived: 2026-04-05 21:16:45 UTC\r\nI came across a GuLoader .xlsx document the other day. It didn’t have any VBA or XLM macros, locked or\r\nhidden or protected sheets, or anything obvious like that. Instead, this is the only thing I saw in oledump.\r\nIt was a bit odd. So let’s see what it takes to tear apart a document such as this. If you’d like to play along, here’s\r\nthe specimen: https://app.any.run/tasks/706a2ec9-c993-40e0-811a-b18358531b24\r\nA special shout out to @ddash_ct! He helped point me in the right direction for extracting the shellcode.\r\nUpon unzipping the file, we can find oleobject1.bin inside the XL/EMBEDDINGS folder.\r\nIf you will recall, OLE stands for Object Linking and Embedding. Microsoft documents allow a user to link or\r\nembed objects into a document. An object that is linked to a document will store that data outside of the document.\r\nIf you update the data outside of the document, the link will update the data inside of your new document.\r\nAn embedded object becomes a part of the new file. It does not retain any sort of connection to the source file.\r\nThis is perfect way for attackers to hide or obfuscate code inside a malicious document.\r\nOLe10nATive stream\r\noledump.py showed that the oleObject1.bin contained a stream called OLe10nATive. These are the storage objects\r\nthat correspond to the linked or embedded objects. That stream is present when data from the embedded object in\r\nthe container document in OLE1.0 is converted to the OLE2.0 format.\r\nhttps://clickallthethings.wordpress.com/2021/03/06/oleobject1-bin-ole10native-shellcode/\r\nPage 1 of 5\n\nWe can extract this stream by using oledump to select object A1 and dump it to a file.\r\nLooking for shellcode\r\nNow that we’ve extracted the stream, how are we going to find anything useful in here?\r\nThis is where the advice from @ddash_ct came in handy. He searched this stream output for a hex string like E8\r\n00 00 00 00 and was able to extract the shellcode from there.\r\nWhy is this the case? And why that pattern?\r\nShellcode cannot assume it will be executed in any particular memory location. It cannot use any hard-coded\r\naddresses for either its code or data. This means it must be position-independent. A hex string such as E8 00 00 00\r\n00 can be an indicator of where position-independent code may start. While the example below is not from our\r\nsample, the opcode E8 00 00 00 00 is translated into the instruction call $+5. This is used to push the current\r\naddress in memory onto the stack. This can serve as a sort of anchor point for the rest of the code execution.\r\nThis is just an example and is not from the ole10native stream in our sample.\r\nWe will not find the exact E8 00 00 00 00 pattern in our file. Instead, we can search for a pattern like 00 00 and\r\nsomething interesting pops up at 0x00265D41.\r\nhttps://clickallthethings.wordpress.com/2021/03/06/oleobject1-bin-ole10native-shellcode/\r\nPage 2 of 5\n\nWhile we do see a similar pattern, there is a significant difference. The opcode E8 is making a call and will be\r\ntransferring control to location 0x000000AF. However, the location of AF is relative to E8’s position in memory at\r\nrun-time. It seems we may have an instance of position-independent code and it might be where some shellcode is\r\nhiding. Got that?\r\nAll this is to say that hex location 0x265D41 is a likely candidate for our purposes.\r\nExtracting the shellcode\r\nFrom here on out, this will be a very similar process to getting shellcode from .rtf documents. We can load up\r\nole10native.bin in scDbg with a start offset of 0x265D41. We know we’re on the right track because we can see\r\nthe unhooked call to ExpandEnvironmentStringsW.\r\nEarlier blog posts showed that scDbg doesn’t work very well with ExpandEnvironmentStringsW. Instead, we can\r\noverwrite that with ExpandEnvironmentStringsA. To do so, we will need to unpack ole10native.bin. We do that by\r\nchecking the box in scDbg for “Create Dump” and re-launch ole10native.bin using the same start offset of\r\n0x265D41. scDbg will then save the dumped and unpacked file. In my case, it was called OLE10N~1.unpack.\r\nOpen up the newly unpacked dump file and scroll to the bottom. You will see a variety of commands in plaintext.\r\nOffset 0x002660D9 begins the command for ExpandEnvironmentStringsW. Overwrite the appropriate location\r\nwith an A and save the changes.\r\nhttps://clickallthethings.wordpress.com/2021/03/06/oleobject1-bin-ole10native-shellcode/\r\nPage 3 of 5\n\nBefore we toss this into scDbg again, we are going to need a new start offset. This can be found at the beginning\r\nof this part of the shell code. Notice the pattern right before k.e.r.n.e.l.3.2. It also follows the E8 00 00 00 00\r\npattern.\r\nToss our unpacked and edited binary into scDbg and enter 0x00266080 as the start offset. And when we do, the\r\nshellcode commands are revealed.\r\nhttps://clickallthethings.wordpress.com/2021/03/06/oleobject1-bin-ole10native-shellcode/\r\nPage 4 of 5\n\nThanks for reading!\r\nReferences\r\nhttps://support.microsoft.com/en-us/office/linked-objects-and-embedded-objects-0bf81db2-8aa3-4148-be4a-c8b6e55e0d7c\r\nhttps://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-oleds/2677fcf2-ad48-4386-ba8f-b1b7baf4c02f\r\nhttps://www.forcepoint.com/blog/x-labs/assessing-risk-office-documents-part-2-hide-my-code-or-download-it\r\nPractical Malware Analysis (the book)\r\nJust a Security Engineer that loves ripping apart malicious documents. View all posts by Jamie\r\nPost navigation\r\nSource: https://clickallthethings.wordpress.com/2021/03/06/oleobject1-bin-ole10native-shellcode/\r\nhttps://clickallthethings.wordpress.com/2021/03/06/oleobject1-bin-ole10native-shellcode/\r\nPage 5 of 5", "extraction_quality": 1, "language": "EN", "sources": [ "Malpedia" ], "origins": [ "web" ], "references": [ "https://clickallthethings.wordpress.com/2021/03/06/oleobject1-bin-ole10native-shellcode/" ], "report_names": [ "oleobject1-bin-ole10native-shellcode" ], "threat_actors": [ { "id": "75108fc1-7f6a-450e-b024-10284f3f62bb", "created_at": "2024-11-01T02:00:52.756877Z", "updated_at": "2026-04-10T02:00:05.273746Z", "deleted_at": null, "main_name": "Play", "aliases": null, "source_name": "MITRE:Play", "tools": [ "Nltest", "AdFind", "PsExec", "Wevtutil", "Cobalt Strike", "Playcrypt", "Mimikatz" ], "source_id": "MITRE", "reports": null } ], "ts_created_at": 1775434486, "ts_updated_at": 1775826756, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/8d69e0feb1a3aaf8821b6497d8df8f59b33885ee.pdf", "text": "https://archive.orkl.eu/8d69e0feb1a3aaf8821b6497d8df8f59b33885ee.txt", "img": "https://archive.orkl.eu/8d69e0feb1a3aaf8821b6497d8df8f59b33885ee.jpg" } }