A Clinical-Trial 'New Role' Notice From a Lookalike Domain

A senior executive at a clinical research organization opened what looked like the most routine kind of trial-operations housekeeping: an automated message announcing that a new role had been assigned to their account on a clinical-trial Interactive Response Technology (IRT) platform. IRT systems are the backbone of how modern trials handle patient randomization and drug supply, so an account and role notice is exactly the sort of thing a CRO leader would expect to see. This one was personalized. It cited a real, active trial protocol identifier and named a global pharmaceutical company as the study sponsor. The same notice reached four mailboxes at the organization.

Everything about it was designed to read as legitimate, and by the two measures most gateways lean on, it was. The message authenticated cleanly, and every link in it pointed somewhere real. The only thing wrong with it was the domain it came from, and that single fact was the entire attack.

Authenticated, but from the wrong domain

The notice arrived from a sender presented as the IRT vendor, using a noreply address on a domain that sounded like the vendor's own. SPF passed: the sending IP was designated for that domain. DMARC passed under relaxed alignment because the header From matched the authenticated domain. Microsoft's composite authentication returned a pass, reason code 100, and the message landed with a spam confidence level of 1, effectively "not spam."

There was one gap in the authentication picture. The message carried no DKIM signature at all. On its own, a missing DKIM record is not proof of anything, and plenty of legitimate senders still under-sign their mail. But it becomes meaningful in context, and the context here was the domain itself.

The sending domain was not the vendor's genuine corporate domain. It was a separate, unofficial lookalike, one that sounds like it belongs to the brand but is not the address the vendor actually uses for platform notifications. It is worth being precise about what kind of lookalike this was. It was not a one-character typosquat, and it was not a freshly registered throwaway. WHOIS showed a well-aged domain, registered well over a decade earlier and privacy-shielded, with no registrant organization listed. That age is precisely what makes this variant dangerous. Reputation and domain-age heuristics, the shortcuts many filters use to sort the plausible from the suspicious, all read "old and established" and gave it the benefit of the doubt.

Real infrastructure doing the vouching

If the sender domain was the weak point, the attacker compensated by making everything downstream of it genuine. The call-to-action links in the body did not resolve to some attacker-controlled staging server. They resolved to authentic, well-known pharmaceutical-industry sign-on infrastructure, including genuine IQVIA IRT and DrugDev single-sign-on endpoints. Those destinations scanned clean, because they really were legitimate services.

This is the part of the pattern that defeats a link-scanning gateway. A URL reputation engine evaluates where a link goes, and when the answer is "a real, reputable clinical-trial SSO portal," there is nothing for it to block. The links were never the payload. They were credibility. Pairing an authenticated, plausible-sounding sender with real backend infrastructure lets an attacker assemble a message where every individual component checks out while the combination is the trap. A recipient who clicks through to a familiar-looking login is being conditioned to trust a channel the attacker controls, setting up whatever request comes next.

Why a gateway waved it through

Line up the checks a traditional secure email gateway runs, and this message passes nearly all of them. SPF: pass. DMARC: pass, aligned. Composite auth: pass. Spam score: clean. Link destinations: legitimate and reputable. No attachment to detonate. No malformed headers. The DMARC standard itself, defined in RFC 7489, is doing exactly what it was designed to do here, which is to confirm that the message is authorized by and aligned to the domain in the From header. It was. The uncomfortable truth is that authentication verifies the domain sent the mail. It does not verify that the domain is one you should trust.

That gap is not a rare edge case. The 2024 Verizon Data Breach Investigations Report found phishing present in 15 percent of breaches, with the human element a factor in 68 percent of them. The same report clocked the median time to click a phishing link at 21 seconds. An email that survives every automated check and lands in the inbox looking like vendor housekeeping is competing for those 21 seconds with a real head start. This is the mechanism MITRE catalogs as Spearphishing Link, layered on top of Masquerading through domain impersonation. CISA's guidance on stopping the phishing attack cycle makes the same point from the defender's side: technical controls alone leave a residual gap that has to be closed at the point of human decision.

The signal clean authentication could not provide

What flagged this message was not any single failed check, because there weren't any of consequence. It was the shape of the sender. IRONSCALES Adaptive AI email security read the message against what the organization actually knows about its correspondents, and the sender was a first-time contact carrying a high-risk reputation signal. An unfamiliar-but-plausible vendor domain, arriving with no DKIM signature and no prior relationship, is a very different object than the same content from the address the organization has genuinely transacted with before. Themis weighed the identity of the sender, not just the syntax of its authentication, and surfaced the risk that SPF and DMARC had quietly endorsed.

That distinction is the whole game against modern impersonation. The lookalike domain, the real protocol number, the genuine SSO links: each was engineered to satisfy a control that inspects one attribute in isolation. Only a model that evaluates the sender as an identity, in the context of the organization's real communication graph, had anything to react to.

What security teams should take away

Treat "authenticated" and "trusted" as separate questions. A message can pass SPF and DMARC because the attacker legitimately controls the lookalike domain in the From header. Age and reputation heuristics will not save you either, since a lookalike can be a real, decade-old domain rather than a fresh typosquat. Watch for the tell that this case turned on: a plausible vendor domain that is not the vendor's actual corporate domain, especially when it arrives as a first-time sender with an incomplete authentication profile such as a missing DKIM signature. And do not let genuine downstream links reassure you, because pointing at real infrastructure is now a standard way to borrow credibility.

Defensively, that means pairing authentication enforcement with identity-aware detection. A domain that would sail past an auth-only gateway needs a control that asks whether the organization has ever actually heard from this sender before. And because the endgame of a trust-building notice like this is usually account access, layered account takeover protection turns a single flagged message into a durable defense.

Indicators of Compromise

MITRE ATT&CK Mapping

See You Next Friday

Authentication answers "did this domain send the mail." It never answers "should I trust this domain." When an attacker owns a plausible, well-aged lookalike and links to real infrastructure, the only anomaly left is the sender's identity, and that is precisely the question an auth-only gateway never asks.