The Password Was in the Email, Highlighted in Yellow

Four mailboxes at a specialty flavors and fragrances manufacturer received the same message within seconds of each other. It was a revised purchase order from a long-standing supplier, sent from that supplier's own real corporate domain, with a PDF attached. The PDF was password protected. The password was printed in the email body a few lines down, highlighted in yellow.

That last detail is the whole case. Encryption on an attachment is normally a control that keeps contents away from everyone who is not supposed to read them. Here it kept the contents away from exactly one party, the automated inspection layer, and from nobody else. The person being targeted was handed the key before they had any reason to ask for it.

Nothing in the envelope was faked

The authentication verdict on this message was not mixed, not marginal, and not interesting. SPF passed. DKIM verified and the signature aligned to the supplier's own Microsoft 365 tenant signing domain. DMARC passed under a published policy set to no enforcement. Composite authentication resolved to pass with reason code 100, the strongest result available. The relay path was an ordinary Microsoft 365 outbound chain with no injected hops and no odd geography.

The sending domain was no help either. It was not a freshly minted lookalike or a homoglyph of the supplier's brand. It was the supplier's actual domain, registered roughly two decades before this email was sent, WHOIS privacy-shielded in the way most corporate registrations are, with a real business website behind it that scanned clean. The signature block pointed at that same site.

Read together, the signals describe an attacker sending mail from inside a legitimate supplier mailbox rather than imitating one from outside. That is vendor email compromise, and MITRE ATT&CK tracks the underlying tradecraft as T1586.002, Compromise Accounts: Email Accounts. The revision framing in the subject line, a "REVISED purchase order [number] from [vendor name]" construction, is what a compromised procurement mailbox gives an attacker for free. It justifies a brand new attachment on a thread the recipient already trusts, and it applies mild pressure without ever sounding urgent.

The encryption was aimed at the inspection layer

The attachment was 57,720 bytes of PDF, named for the supplier with a "-protected" suffix appended. The automated scan verdict came back as Clean.

That verdict was technically accurate and analytically worthless. The file was encrypted, so the scanner could not parse its object structure, could not extract a single string of text, could not resolve an embedded action, and could not render a page to look at. It reported nothing malicious because it had nothing at all to report. On an encrypted container, Clean does not mean inspected and safe. It means unopened.

The passcode itself tells you how little the attacker cared about actual confidentiality. It followed a trivially derivable pattern, the supplier's own company name concatenated with a four-digit year. Any analyst who wanted to guess it would land it in a handful of attempts. But nobody needed to guess, because it was sitting in the body in highlighter yellow, formatted for a human eye scanning quickly on a Friday afternoon. Attachment-borne delivery like this maps to MITRE ATT&CK T1566.001, Spearphishing Attachment, and NIST's definition of phishing covers the social half of it neatly enough. What the technique adds is a deliberate split between the two audiences: one of them can read the payload, and it is not the one doing the security checking.

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

Where the automated evidence stops

We can tell you precisely what the scanner saw and precisely why it saw nothing. We are not going to tell you what was inside that file, because the honest answer is that the automated record ends at the encryption boundary and we do not invent the rest.

That gap is worth sitting with, because it is the actual cost of this technique. Every downstream control that depends on reading the file inherits the same blindness. Static analysis has no objects to walk. URL extraction has no URLs to extract, since the only link anywhere in the message pointed at the supplier's genuine website in the signature. A sandbox that opens the document without the passcode watches an encrypted file refuse to open. The one entity guaranteed to reach the contents is the human the passcode was printed for, and the 2024 Verizon Data Breach Investigations Report puts the median time from opening a phishing message to clicking at 21 seconds, and to submitting data at 28 seconds. That is the window this design buys, and it opens on the recipient's side of the wall.

What closed it here was not file inspection. IRONSCALES Adaptive AI scored the message at 88% confidence and tagged it as a risk to a high-value recipient, reasoning from the shape of the message rather than from the contents of the attachment. A trusted supplier thread, a revised procurement document, an encrypted file, and its passcode helpfully supplied in the same body is a combination that does not occur in honest correspondence. The message was automatically resolved as phishing and all four affected mailboxes, a customer service representative and three colleagues on the same distribution, were quarantined within seconds of delivery.

Make the passcode itself the signal

The practical takeaway is narrow and immediately usable. Treat "encrypted attachment plus its passcode in the same message" as a detection condition in its own right, independent of anything else in the mail. Senders with a genuine confidentiality requirement do not defeat their own encryption in the covering note. They exchange keys out of band, by phone, through a portal, or in a separate channel established beforehand. A passcode in the body is not a convenience. It is a statement that the encryption was never meant to protect the file from anyone the sender expected to open it.

That means your malware and URL inspection layer should be escalating unreadable containers rather than clearing them, and your triage should weigh the requested action and the sender relationship rather than the scan verdict. CISA's phishing guidance makes the same argument from the other end: the controls that hold up are the ones that do not depend on recognizing a specific malicious artifact.

A supplier you have worked with for years can send you a hostile message tomorrow without a single header changing. When that happens, the attachment nobody can open is the part to look at hardest.

See you next time

Attack of the Day is our daily teardown of the real phishing our SOC intercepts. The details are anonymized, the tradecraft is not. Come back tomorrow for the next one.

Indicators of Compromise

MITRE ATT&CK Mapping