A Fake Secure Message From Your Own IT Security Team

Five employees at a regional hospital system each received the same notification inside a four-minute window. Each copy carried that employee's own first name in the subject line, prefixed by the external-sender tag their tenant appends, followed by the phrase "you have a secure message." The body was clean, corporate, and unremarkable. There was one button, labelled to open the secure message. There were no attachments.

The body copy said the notice came from the hospital's internal security team, and it helpfully added that anyone who was not expecting a secure message should reach out to that same internal team to confirm.

Nothing about the envelope claimed to be the hospital. That is the part worth slowing down on.

The impersonation never touched a header

Most impersonation cases in this series turn on the envelope. A forged From domain, a lookalike registration a few characters off the real one, a display name pasted over a stranger's mailbox. All of those leave a measurable artifact in the headers, which is exactly why authentication and header analysis catch a meaningful share of them.

This message left the headers completely honest. The From address was notifications@tealiummail[.]com, the display name was a generic security label, and no part of the routing or signing pretended to belong to the hospital. A filter comparing the header From against the recipient's own domain would find no collision to report.

The false identity lived one layer up, in the rendered text a human reads. The signature block asserted an internal security team, and the reassurance line pointed at an internal-looking security alias on the hospital's own domain. Recipients were not asked to trust a domain. They were asked to trust a sentence. MITRE ATT&CK tracks that shape as impersonation, and it is a genuinely awkward variant for envelope-centric controls, because the thing being faked is never asserted in a field any protocol validates.

A twelve-day-old domain with borrowed reputation

The sending domain was registered twelve days before the wave went out, behind a privacy-protected registrant, and its name sits deliberately close to that of a well-known customer-data-platform vendor. Domain age like that is normally the single strongest reason a message gets held, and the registration itself maps cleanly to acquiring infrastructure.

A domain that new has no sending history, no accumulated reputation, and, in this case, no usable published DMARC policy. On paper it should have struggled to reach an inbox at all.

It did not struggle, because the campaign was not sent from infrastructure the attacker stood up. It was relayed through Adobe Marketo, a legitimate marketing-automation platform, from a real account on that platform. The connecting host was one of Marketo's own shared senders at potomac2142[.]mktomail[.]com, on IP 192[.]28[.]152[.]142. The return path referenced a benefits-platform vendor's marketing-sending domain, an uninvolved third party whose configuration happens to designate that shared range.

The result is a set of authentication outcomes that look like a well-run mail program. SPF passed, because the connecting IP is a designated sender for that configured sending domain. DKIM passed twice, once under the attacker-registered domain and once under Marketo's shared signing domain. DMARC returned a best-guess pass with no policy action, the outcome a receiver produces when there is no real published policy to enforce. Composite authentication passed as well.

None of those results are wrong. They are answers to narrow questions about whether the mail came from somewhere allowed to send it, and it did. What they cannot express is that a twelve-day-old domain rented a mature pipeline for the afternoon.

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

Passing authentication and being tagged as phishing at the same time

Worth noting for calibration, the receiving platform did not fully believe its own passes. Microsoft's antispam layer independently classified the message as phishing and assigned it a spam confidence level of five, in the same header block where composite authentication reported a pass.

That combination is the honest picture of what authentication is for. Cryptographic checks confirmed provenance. Content analysis disagreed about intent. Both were correct, and only one of them was answering the question that mattered to the five people staring at a button.

The button and the second link both resolved to a tracking subdomain of the attacker's own domain, one bare and one carrying a long opaque token unique to the recipient. Automated analysis returned a clean verdict on both, unsurprising for a redirect host with nothing hostile parked on it at scan time, and no further hop was captured in the record. Treated as spearphishing via link, the per-recipient token is the interesting detail: it makes every click individually attributable, which is how a credential funnel confirms which mailboxes are live and worth a second attempt. Our credential harvesting protection is built for exactly this gap, where the link is technically clean and the pretext is the payload.

The spray pattern was the tell

Automated threat detection opened the incident, and the strongest signal was structural rather than cryptographic. Five individually personalized copies, five different recipients, roughly four minutes end to end. Legitimate secure-message notifications do not arrive as a synchronized burst addressed to unrelated staff by first name.

Our Adaptive AI, Themis, returned a 56 percent confidence with a recipient-targeting label, citing sender signals, body content, and community insight as contributing indicators. That is a moderate score, not a decisive one, and it reflects the underlying difficulty. The sending infrastructure was reputable, the authentication was clean, and the only firm anomalies were the age of the domain, the shape of the wave, and the wording of the pretext. The incident was closed as approved manually across five affected mailboxes.

The 2024 Verizon Data Breach Investigations Report puts stolen credentials at the top of the initial-action list, present in 38 percent of breaches, with phishing itself in 15 percent. It also measured the median time to click a phishing link at 21 seconds. A four-minute delivery window against five mailboxes is engineered around that reality.

Why healthcare inboxes reward this pretext

A hospital system runs on internal notification traffic. Credentialing reminders, secure clinical correspondence, benefits notices, portal alerts. Staff are trained to expect messages from internal security and IT functions, which makes a claimed internal identity the least interesting thing in an inbox and therefore the cheapest costume available. Healthcare email security has to account for that baseline, because the volume of legitimate internal-looking mail is what gives the fake version its cover.

The countermeasure is procedural before it is technical, and it is the point CISA's phishing guidance keeps returning to. If a message can tell a recipient how to verify it, the verification is worthless. One published reporting path, used regardless of what any individual message instructs, removes the self-referential loop this attack depended on. As NIST's definition of phishing frames it, the mechanism is deception of a person, and this message deceived a person without deceiving a single protocol.

Indicators of Compromise

MITRE ATT&CK mapping

See you next time

The useful question after a case like this is not how the mail authenticated. It is why a sentence in the body was allowed to establish identity at all. Envelope controls did their job and reported accurately. The claim they could not evaluate, that this came from inside the building, was the only claim the attacker actually needed.