Nothing to Block: A Phish With Perfect Authentication

A document signature request arrived one morning in the shared information alias of a pharmaceutical contract development and manufacturing organization. The From display name read as the recipient's own company. The body wore a DocuSign wordmark. And every authentication control the receiving tenant could apply came back clean: SPF pass, DKIM pass, DMARC pass, and Microsoft composite authentication at a perfect score of 100.

None of that was forged. That is the entire problem with this case. The message really was signed by the domain in its From header, really did leave an IP that domain authorizes, and really did travel through that domain's own transactional email service provider account. The domain belonged to a European telecommunications provider that had been operating for roughly nine years. There was no lookalike, no typosquat, no domain registered days earlier, and therefore nothing in the sender identity that a blocklist could usefully act on.

The Sender Was Real, and That Was the Point

The authentication picture is worth reading in full, because it is the cleanest you will see on a phishing message. SPF passed against a bulk-mail subdomain of the sending domain, with a Received-SPF header independently recording the same pass. DKIM passed with a verified RSA signature whose signing domain matched the header From, so DMARC aligned and passed as well. Microsoft's composite authentication, which exists precisely to catch cases where the individual protocols are satisfied but the message still smells wrong, returned pass with reason 100.

The explanation for that spotless record sits in the transport metadata. The Message-ID pointed at smtp-relay[.]mailin[.]fr, and a vendor-specific tracking header sat alongside it. Both are markers of Brevo, formerly Sendinblue. The mail was relayed through a genuine transactional sending account belonging to a genuine operating business, and the body's images and click tracking were served from that same account's own tracking subdomain.

This is the failure mode that authentication was never designed to cover. DMARC and its underlying specification in RFC 7489 answer exactly one question: was this message authorized by the domain claiming to have sent it. Here the honest answer was yes. The 2024 Verizon Data Breach Investigations Report puts stolen credentials in 38 percent of breaches as the single most common initial action, and credentials are exactly what buy an attacker this kind of channel. Once a sending account is in hand, every reputation signal attached to it keeps working on the attacker's behalf.

Microsoft's own first-contact banner did fire, noting that the recipient does not often receive mail from this sender. It was not enough to stop delivery.

The Recipient's Own Identity as the Trust Anchor

Most brand-impersonation mail borrows a vendor's credibility. This message borrowed the target's. The display name was the recipient's own company name set against an unrelated sending domain, and the fake task list inside the body named a pending agreement PDF after that same company. One of the two payload links was displayed literally as the recipient's own corporate domain while resolving somewhere else entirely. Both payload links were then rewritten by the recipient's own link-protection service, which changed how they looked without changing where they went.

The DocuSign layer sat on top of that, and it carried its own small tell. The wordmark in the body was not a clean brand string. An invisible soft-hyphen character had been inserted inside it, which renders identically to a human eye while defeating any rule that matches the brand name exactly. Below it, a task list invited the recipient to view and complete two items on a document supposedly waiting for signature.

There was no such document. The message carried no attachments at all. The pending PDF existed only as a filename in body text, which is a common shape for credential-harvesting lures that need a reason for you to click rather than a file to open. The body also contained one genuine link to the real corporate website, which scanned clean with a captured screenshot, so real and verifiable navigation sat a few pixels away from the deceptive kind.

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

The Template Fragments Nobody Proofread

The evidence that this was a repurposed account rather than purpose-built infrastructure was sitting in the HTML, unread. A hidden preview-text line, the copy that renders in an inbox list view before the body loads, advertised a full year of something for the price of nine euros. It has no relationship whatsoever to a document pending signature. A second, unrelated promotional content block for a media business survived in the same body. And the footer stitched the pharmaceutical company's name directly onto a mortgage-industry licensing registry number, a piece of United States consumer-lending boilerplate with no conceivable relevance to a contract manufacturer of pharmaceutical ingredients.

Nobody assembles that from scratch. Those fragments are residue from the sending account's real commercial mail stream, and that is what justifies treating the telecommunications company as a bystander rather than a participant. What the record does not establish is how the account came to be used this way. An external takeover, a bad actor with legitimate access, and an abusive reseller all leave the same artifacts, and there is no forensic timeline here to separate them. Repurposed is the defensible word. Compromised is a claim this evidence does not close.

Two Links, One Destination

Unwrapping the protective rewrite on both deceptive links produced the same answer: a long tracking path on 2dc1e2e6[.]map[.]travelicious[.]com[.]pk, a host on a Pakistani country-code domain with no relationship to the impersonated e-signature brand or to the recipient. No screenshot was captured for any of those links, so what the destination rendered is unknown and will stay that way. The finding is the mismatch itself, between a link presented as the recipient's own domain and a redirect host on the other side of the world. WHOIS for that country-code domain was not retrievable, so its age and its registrant remain unestablished in either direction.

What actually closed the case was behavior, not infrastructure. Themis returned 90 percent confidence with a label of credential theft, drawing on content-pattern analysis, including the message's odd non-English structural fragments that the leftover marketing residue neatly explains, and on community reputation from similar reports elsewhere. The message was automatically resolved as phishing and permanently deleted from the single affected mailbox. No user action was recorded against it.

What This Leaves You to Defend

There is no sender to block here without harming an innocent business, so the controls have to live elsewhere. Alert when an external message's display name matches your own organization's name, which is a condition with almost no legitimate use. Judge a link by where it resolves rather than by the text it displays, and remember that a protective rewrite is a wrapper, not a verdict. Treat email-service-provider relay traffic as a channel whose reputation belongs to whoever currently controls the account, not permanently to the business named on the domain. And route every signature request back through the e-signature platform directly rather than through the link in the notification, which is where the CISA phishing guidance and the NIST definition of phishing both point.

Perfect authentication is a statement about custody. It has never been a statement about intent.

Indicators of Compromise

MITRE ATT&CK Mapping