Four PE Executables Hidden Inside an OLE Container Disguised as a CAD Drawing, Sent From Inside the Organization

"I can't open this file. Can someone else try?" That forwarded message, sent from inside a manufacturing company's own M365 tenant, carried a 310 KB attachment with a .exb extension and a Chinese-language filename. The file was not a drawing. It was an OLE Compound Document containing four embedded Windows PE executables, packed with enough obfuscation to produce only 56 printable strings across the entire binary. Because the email originated internally, no external sender warning ever fired.

The .exb extension belongs to CAXA CAD, a drafting application widely used in Chinese manufacturing, aerospace, and automotive industries. In context, everything about this email made sense on the surface: a manufacturing company, a subject line reading "Fw: Drawing," a Chinese-language filename, and a file extension associated with engineering drawings. The sender had apparently received the file from an external source and, unable to open it (because it was not actually a CAD file), forwarded it to colleagues asking them to try.

The Extension That No Policy Covers

This is where the attack design becomes interesting. Most phishing defense policies block attachments based on extension: .exe, .scr, .bat, .js, .vbs, and other known executable formats get quarantined. Some policies extend coverage to Office macro containers (.docm, .xlsm). But .exb? It does not appear on any standard block list. It is not a recognized Office format. It is not a known executable extension. From a policy perspective, it is invisible.

The 2024 Verizon Data Breach Investigations Report found that malware-laden attachments remain a persistent initial access vector alongside credential phishing. The malware-laden 10% disproportionately relies on file-type manipulation to reach inboxes, and this case demonstrates why: if your detection model starts with the extension, a non-standard extension means the model never starts.

What the File Header Actually Revealed

The file's first four bytes were D0CF11E0, the magic signature for an OLE (Object Linking and Embedding) Compound File. This is the binary container format underlying older Microsoft Office documents (.doc, .xls, .ppt). An OLE container can hold multiple named streams, embedded objects, and arbitrary binary data. It is not a CAXA CAD drawing.

This maps directly to MITRE ATT&CK T1036.008 (Masquerade File Type): the declared extension (.exb) does not match the actual file format (OLE Compound Document). Any security tool that selects its parser based on the extension would never invoke OLE-specific analysis.

Binary inspection went deeper. Four distinct MZ headers (the 4D 5A magic bytes that begin every Windows PE executable) were found embedded within the OLE container. Four separate executables packed inside a single file, none of them visible from the file's external metadata. No VBA macros were extracted. No JavaScript was present. The OLE container was being used purely as a transport mechanism for packed binaries.

The file's Shannon entropy measured approximately 6.78 on the 8.0 scale, consistent with compressed or packed content. More telling: only 56 printable ASCII strings existed across 310,272 bytes. A legitimate document of that size would contain hundreds or thousands of readable strings (text content, XML markup, metadata fields). Fifty-six strings across 300 KB points to payloads that have been deliberately obfuscated to defeat static string analysis, a characteristic of software packing where executable content is compressed or encrypted to evade signature-based detection.

See Your Risk: Calculate how many threats your SEG is missing

Internal Routing as a Trust Exploit

The email was sent from [Sender]@steelmetalsystems[.]com, a domain registered in 2004 through GoDaddy with two decades of legitimate sending history. The M365 authentication chain shows AuthAs=Internal, meaning the message was processed as internal organizational mail. SPF, DKIM, and DMARC all aligned against the legitimate tenant.

Internal routing changes the recipient's threat calculus in three ways. First, the external sender banner that M365 displays for messages originating outside the organization did not appear. Second, the sender's email address matched a known colleague. Third, the conversational context ("I can't open this, can you try?") created a plausible reason to interact with an unfamiliar file.

Whether the sending account was compromised or the sender was an unwitting relay (having received the file externally and forwarding it internally) is an open question. The effect is identical either way: a file that no external delivery path would have successfully delivered reached internal mailboxes with full organizational trust. The Microsoft Digital Defense Report 2024 highlights compromised cloud identities as a primary vector for internal propagation of threats, and this case illustrates the mechanism. Once inside the tenant, the attacker's payload inherits every trust signal the organization has built.

The Detonation Lure

The forward itself is worth examining as a social engineering technique. "I can't open this file" is not just context. It is an invitation. The sender is explicitly asking recipients to attempt to open an attachment that failed to execute on one machine. If the file contains packed executables, the sender's inability to open it may mean their system lacked the right extraction chain or their endpoint protection intervened. Forwarding it to colleagues effectively crowd-sources detonation attempts across multiple endpoints with potentially different security configurations.

The IRONSCALES platform flagged this email through behavioral signals that static file analysis missed: the anomalous attachment format, the mismatch between the declared file type and the actual binary structure, and cross-tenant intelligence showing OLE containers with non-standard extensions appearing in multiple organizations. Affected mailboxes were mitigated.

For security teams, the defensive takeaway is straightforward. Extension-based policies are necessary but insufficient. Advanced malware and URL protection must include content inspection that compares declared extensions against actual file headers. Any mismatch between a file's extension and its magic bytes should trigger quarantine, regardless of whether the extension appears on a known-bad list. And internal mail deserves the same depth of attachment inspection as external mail, because the trust boundary that separates them is exactly what attackers target.

Indicators of Compromise

MITRE ATT&CK Mapping