The Fake Auditor Was CC'd on Its Own Phishing Email

A message reached an internal finance distribution list at a boutique investment firm carrying a request routine in that industry. Outside auditors, it said, needed written confirmation of an investment position to close out interim financial statements for the half year that had just ended, and the form was due back within days. The sender presented as an investment partner at a venture capital firm. A second address sat in the CC line, presenting as the auditor, on a domain built to read as one of the Big Four accounting practices. The subject line named the recipient's own firm.

Both of those sending domains belonged to the attacker. One was twelve days old. The other was forty eight days old. Both had been bought through the same registrar.

Two Identities, One Registrar, Five Weeks Apart

Registration lookups are the whole case here. The sending domain had been created twelve days before the message went out. The CC'd auditor domain, the one shaped to read as a Big Four accounting practice, had been created thirty six days before that. Both records named the same registrar. That provider serves an enormous legitimate customer base and nothing in this record suggests otherwise, so the registrar is not the finding. The pairing is.

A single cold email from a single fresh domain is a shape every triage queue already knows. This was not that. The attacker registered the durable asset first, the fake accounting practice, let it sit for over a month, then registered the investor identity closer to the send date and put both of them on the same message. Two sides of a professional relationship were manufactured so each could vouch for the other, and the recipient was invited to read the CC line as corroboration.

The Link Said Google Drive and the Anchor Said Otherwise

The request pointed to an audit confirmation form. The visible link text read as an ordinary Google Drive download URL, and so did the anchor's own display attribute, which is the value a hovering recipient sees in the status bar. The real destination was neither.

The href resolved first to a click tracking endpoint operated by a legitimate email marketing platform. Click trackers of that kind are ordinary commercial infrastructure, and this one was not compromised, simply chosen as the first hop because its reputation is clean and its redirect behaviour is public. From there the browser was forwarded to a plugin path on a third domain, several directories deep, terminating in a CAPTCHA component.

That third domain was not attacker infrastructure either. It had been registered more than five years earlier through a mainstream registrar, ran on managed cloud DNS, and belonged to a business with no connection to venture capital or audit services. A deep path inside a content management plugin directory on a site like that is the signature of a compromised web host being used as free space, not of a domain someone bought in order to phish. Credential harvesting pages parked on genuinely aged third party sites inherit that site's reputation rather than carrying their own, which is why reputation based filtering has so little to work with here.

The terminal page sat behind the CAPTCHA. A scanner cannot solve one, so it follows the chain, arrives at a challenge, and reports a challenge. That verdict describes how far the scanner travelled, not what waited behind the gate, and every blocking decision downstream inherits the ambiguity.

The query string on that final URL also carried the recipient's own address, base64 encoded, as a per recipient tracking token. A plaintext search for the address does not match its encoded form, so any leak check that greps for the literal string is blind to it. Neither the tracker URL nor the landing URL is reproduced in full below, for exactly that reason.

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

Why the Authentication Trace Reads Two Different Ways

At origin, the message authenticated cleanly. SPF passed on the envelope sender, DKIM passed with a signature aligned to the sending domain, and DMARC passed. None of that is surprising. The attacker owned the domain, and publishing correct records on a domain registered less than two weeks earlier is form filling, not compromise.

The last recorded hop tells a different story. The targeted address was itself an internal mailing list, and the message was relayed onward through that list before it reached the individual mailbox that eventually reported it. The relay changed the effective envelope, so the final hop shows a DMARC failure against the original sending domain under a policy set to none. That failure is a mailing list alignment artifact, a limitation acknowledged in RFC 7489 itself, not evidence that the original send failed anything.

The operational consequence is real. An analyst reading only the final hop sees a DMARC failure and concludes spoofing, which points at the wrong control. An analyst reading the origin hop sees a fully authenticated message from a twelve day old domain, which is a different attack requiring a different response. Alignment monitoring only helps if the hop being read is the one that matters, and for list relayed mail that is the origin.

Filed as Bulk Mail, Not Credential Theft

The outcome was right and the label was wrong, and that is worth stating plainly. Adaptive AI triage scored the message at 84 percent confidence and typed all three of its signal categories as spam: promotional and attention seeking language in the content, similarity to previously reported bulk mail across the community, and sender analysis. It was automatically resolved as spam and moved to the junk folder on the affected mailbox. No credential phishing verdict was applied.

The reason is almost circular. The recipient organisation's own distribution list added the headers that mailing lists add, including an unsubscribe header and a bulk precedence marker. A targeted request built around a fabricated auditor arrived wearing the header signature of a newsletter, and the classifier weighted what it could see. The message never reached an inbox, and an employee reported it anyway. But a spam auto resolution does not trigger the same hunt, the same cross tenant indicator push, or the same urgency as a credential theft verdict, and this campaign's infrastructure deserved all three. Internal relay is a laundering step nobody deliberately built.

Stolen credentials remained the single most common initial action in breaches in the 2024 Verizon Data Breach Investigations Report, present in 38 percent, with phishing in 15 percent and a median time from delivery to click measured in seconds rather than hours. Pretexting, an invented business context rather than a malicious attachment, is the dominant social engineering pattern in that data, and the FBI's 2023 Internet Crime Report put reported business email compromise losses near 2.9 billion dollars. Neither figure depends on the payload being sophisticated. This one was a link.

The practical discriminators are cheap. Correlate registrar and creation date across every address on a message, not just the sender. Compare the anchor href against both the link text and the display attribute, because this attacker set all three. Treat a scan that terminates at a CAPTCHA as unknown rather than clean. And read authentication at the origin hop for anything relayed through an internal list. CISA phishing guidance and the NIST definition both frame the problem as pretext plus delivery, which is precisely where this one lived.

Indicators of Compromise

MITRE ATT&CK Mapping