A 64-Bit Password, Handed Over in the Same Email

Three mailboxes at a farm and ranch equipment manufacturer received the same message within moments of each other. It read as an internal HR announcement: a performance recognition package waiting for review, a list of awarded perks, and a PDF attached. The PDF was password protected. The password was printed in a box directly beneath the line telling the recipient to open it.

The password was 9683A8005D06D71A. Sixteen hexadecimal characters, sixty-four bits of keyspace, no dictionary word, no company name, no appended year. Nobody guesses that, and no inspection layer recovers it in the milliseconds a message spends in transit. Someone generated a genuinely strong key, applied it to the payload, and then published it in the same email as the file it unlocked.

That is the whole case, and it closes a question that usually stays open. When an encrypted attachment arrives with a lazy, derivable passcode, you can argue the attacker was sloppy. Here there is nothing to argue. The lock was strong enough to defeat every automated content check in the path, and the key went in plaintext to the one reader the attacker wanted inside the file.

The sender was eight days old

The message came from a benefits-themed address on a subdomain built to read like transactional mail, benefits@notification[.]benefitsmsg[.]com. WHOIS puts the registration of benefitsmsg[.]com eight days before this email was sent, through a low-cost registrar, with a privacy-shielded registrant behind an Arizona proxy address and nameservers pointed at a large CDN provider.

The display name was not a person but simply the target company's own name, the cheapest way to make an external message read as internal. Nothing here required a compromised account, a stolen mailbox, or a lookalike of a real corporate domain. It required a registration fee and a week of aging, which is what MITRE ATT&CK describes as T1583.001, Acquire Infrastructure: Domains. Eight days clears the crude age heuristics and leaves no reputation history to contradict the send.

The passing authentication described other domains

The authentication verdicts all came back green, and none were about the domain the recipients read.

SPF passed, but on the envelope sender, which belonged to an unrelated third-party sending platform routed through a commercial email provider. DKIM passed, but the signature verified against that provider's shared signing domain, spmailtechno[.]com. The relay chain was an ordinary provider outbound host handing off to cloud mail protection frontends. Composite authentication resolved to pass.

The only mechanism that connects those results back to the visible From domain is DMARC, which exists to require alignment between what was authenticated and what the reader sees, as specified in RFC 7489. The attacker domain published no DMARC record. With no policy there was no alignment requirement, no enforcement, and nothing to fail, so a domain barely a week old inherited the reputation of an established sending platform and arrived looking authenticated.

This is the routine failure mode that makes DMARC policy management and monitoring an inbound problem, not just an outbound one. A green SPF result and a valid DKIM signature are statements about infrastructure, not identity.

The encryption was pointed at the scanner

The attachment was 9,440 bytes of PDF, named to reference the recipient personally, and the antivirus verdict on it was Clean.

That verdict was accurate and useless. The file was encrypted, so the scanner could not walk its object structure, extract text, resolve an embedded action, or render a page. It reported nothing because it had nothing to report. On an encrypted container, Clean does not mean inspected and cleared. It means unopened.

Attachment-borne delivery like this maps to MITRE ATT&CK T1566.001, Spearphishing Attachment, and NIST's definition of phishing covers the social half. What this variant adds is a deliberate split between two audiences. One of them can read the payload. It is not the one performing the security check.

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

There was nothing else to inspect

This message contained no malicious link at all. The only URLs anywhere in it pointed at generic vendor help pages explaining how to identify unfamiliar senders, which is a nice touch given the circumstances.

Every control that works by evaluating a destination had no input: URL reputation, link rewriting, and landing-page detonation had nothing to act on, and static analysis had an encrypted blob. That leaves the body, the sender, and the shape of the request as the entire detection surface.

The body was built for exactly that surface and no deeper. The subject carried the recipient's own name, in the form [Recipient Name], your performance recognition package is ready, and each mailbox got the identical template with its own name substituted. The perk list was specific enough to feel administrative and vague enough to require the document: bonus days off, a wellness credit, a learning budget, a remote-work equipment upgrade, a performance bonus. Then a mid-month enrollment deadline, which supplies urgency without threatening anyone. 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. A benefits document with the reader's name on it is designed for that window.

What actually closed it

What was inside the file is not something we can tell you, because the automated record stops at the encryption boundary.

What we can say is how it ended. A recipient recognized that a benefits announcement had arrived from a domain with no relationship to their employer, and reported it. The case was resolved as phishing and all three copies were permanently deleted, with no automated mitigation action recorded on any affected mailbox. The control that closed this one was a person, and it worked because reporting was easy and the reflex was already there. The human element is not a consolation prize when file inspection has been engineered out of the picture. Here it was the only layer holding usable evidence.

That is also where the weighting has to sit. When the payload is unreadable and there are no links, the remaining signal is behavioral, which is what Adaptive AI is built to reason over: a first-contact domain, a display name matching the recipient's own employer, authentication that passes for somebody else, an encrypted attachment, and its full decryption code in the same body. That combination does not occur in honest correspondence.

Make the code in the body the condition

The actionable version is narrow. Treat an encrypted attachment paired with its decryption code as a detection condition in its own right, evaluated before any file verdict. Senders with a real confidentiality requirement do not defeat their own encryption in the covering note. They exchange keys by phone or through a portal agreed on beforehand.

Then check the strength of the code, because it tells you what the encryption was for. A weak passcode might be habit. A random sixteen-character key means the sender wanted the file opened by precisely one class of reader and closed to the other. CISA's phishing guidance makes the same argument from the other direction: the controls that hold are the ones that do not depend on recognizing a specific malicious artifact.

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