The 'Clean' .docx That Was an Encrypted Office Package

The first eight bytes of the attachment were D0 CF 11 E0 A1 B1 1A E1. That is an OLE2 compound file header, the container Microsoft used for Office documents before 2007.

The detection record for that same attachment reported a .docx filename, a MIME type of application/vnd.openxmlformats-officedocument.wordprocessingml.document, and an attachment status of Clean.

A .docx is a ZIP archive. It begins with the bytes PK. This file did not. Before anything else was decided about the message, the record was wrong about what kind of file it held, and container type is the decision every parser and policy downstream inherits.

The container held two streams, and neither one was a document

The file was 76,800 bytes total, 512-byte sectors, CFB major version 3. Its directory held exactly two payload streams: EncryptionInfo at 224 bytes and EncryptedPackage at 73,672 bytes.

That pair is the MS-OFFCRYPTO signature. Not a malformed file, not a polyglot. A standards-conformant, password-encrypted Office package, the thing Word itself produces when a user sets an open password.

The absences are as informative as the streams. No WordDocument stream. No VBA or Macros stream. No DataSpaces or StrongEncryption stream. Nothing in the outer container was readable as prose or as code, because the document sat inside EncryptedPackage as ciphertext.

What it contained was never established. The password was not attempted during analysis, so no claim about a macro or a payload inside it is supportable. That uncertainty is the point of the technique.

The key was printed in the message, in red

The HTML body told the recipient the attachment was encrypted and supplied an initial view code of 8523, set in red bold.

That inverts what encryption is for. A protected file shipped alongside its own password withholds the file from anything automated and hands the key to the one reader who can be persuaded to use it.

MITRE catalogs the delivery as Spearphishing Attachment (T1566.001). The 2026 Verizon Data Breach Investigations Report still puts phishing at 16% of breaches as an initial access vector and the human element in 62%. The control cannot read the file. The person can.

We have taken this apart before in its PDF form, and in a case where an OLE container used an odd extension to carry embedded executables. This one differs narrowly: the crypto is legitimate Office crypto, and the misdeclaration is not in the attacker's file naming. It is in the security record.

What a Clean attachment status means when the bytes cannot be read

The message-level outcome was not Clean at all.

Microsoft stamped the X-Forefront-Antispam-Report with CAT:PHISH, SFV:SPM, SCL:5 and BCL:4, and routed the mail to Junk. Both sends were quarantined with real mitigation timestamps, and the IRONSCALES state is Automatically Resolved as Phishing, with zero human votes. That is automated classification, not analyst confirmation.

The Clean sat one level down, on the attachment. A Clean status over 73,672 bytes of ciphertext cannot mean the contents were examined and found harmless. The defensible reading is that nothing was found, which is what an examination of undecryptable data always returns. In a log, a genuinely empty file and an unreadable one look identical.

That is inference, not a recorded fact. It is also the inference a triage analyst has to make, because a pipeline that rolls an attachment-level Clean up into file-is-safe will get it wrong.

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

Cheap kit, borrowed relay

The rest of the message reads as inexpensive tooling. The X-Mailer header was Wjwpoheg Ixqpmgdsbw 2.42, and the external peer that injected the message presented a HELO of gbapfqdpx[.]nl. Both are machine-generated consonant gibberish from what looks like one generator.

Three read-receipt request headers were set, all pointing at a single free consumer QQ mailbox: Return-Receipt-To, Disposition-Notification-To, and the legacy X-Confirm-Reading-To variant from the Pegasus and Netscape era. Three client generations covered in one message. A secondary act next to the attachment.

The routing matters. The message entered a Chinese manufacturer's on-premises Exchange from an external peer at a Chinese IP presenting that nonsense HELO, then left it, so Microsoft recorded spf=pass for the sending domain at the final hop. Whether that server is a true open relay or whether a credential there was compromised was not established. That manufacturer is a bystander, and its infrastructure being borrowed is the laundering dynamic the Microsoft Digital Defense Report 2024 describes. Microsoft logged compauth=pass and dmarc=bestguesspass on the very message it called phishing.

The link proves less than it looks like it does

The one link in the captured copy was the recipient's own Microsoft Safe Links rewrite, which is recipient-side infrastructure rather than attacker infrastructure. The attacker host lives in the originalsrc parameter: hxxps://qybtsersf[.]shop/. Its anchor text was Chinese for "online processing mini-program", a WeChat pretext, and the URL verdict was also Clean, so it was never independently adjudicated malicious.

The stored screenshot for that host is a Chrome error page reading ERR_HTTP2_PROTOCOL_ERROR. The site was already unreachable when scanned, so nothing is known about what it did and no credential-harvest claim can be made. That is why attachment and URL analysis has to reach a decision from the message itself. MITRE tracks the link half as Spearphishing Link (T1566.002).

The lure was plain: a Chinese-language notice about employee benefits, from a display name meaning Finance Department, closing with a line saying it came from the administration system and needed no reply.

It arrived on 2025-12-04 and again on 2025-12-05 with a slightly altered subject referencing in-service benefits for 2025. First-time sender, no correspondence in either direction, zero release requests, no human SAFE verdict for that sender domain at this tenant. The addressed mailbox was flagged inactive, so the targeted director had already left or been deactivated. The campaign re-sent anyway.

Indicators

Read the container, not the label

Assert file type from magic bytes, never from the filename or the declared MIME type, and treat a disagreement as a signal rather than a cosmetic inconsistency. A record that says OOXML about a compound file misleads every analyst who reads it afterward.

Treat an encrypted attachment carrying its own password in the body as a detection condition by itself. Neither half is suspicious alone. Together they describe a file placed beyond automated reach, which is why CISA phishing guidance and the NIST definition of phishing both put the social step, not the file format, at the center of the technique.

And stop letting a file-level verdict outrank message-level context. A secure email gateway (SEG) built on file and URL reputation has nothing to score here: the file will not decrypt and the destination is dead. Correlating a first-time sender, no prior correspondence, two machine-generated gibberish strings and a domain with no DMARC record is what Adaptive AI exists to do.

IRONSCALES platform data across 36,000+ security professionals in 18,000+ organizations points the same way. The messages that survive triage rarely carry a bad file verdict. They are the ones where nothing could be read, and something scored that as nothing to worry about.