The Trade Lead Whose Own Website Did Not Resolve

The message that reached a sales manager in the connector division of a US electronics connector manufacturer was a reply, and it was a reply to something real. Weeks earlier, someone had filled out the company's public website contact form, describing themselves as a purchasing specialist at an industrial buying group and asking about component availability. The form generated a routine notification, the notification was forwarded to the right team internally, and the sales manager did exactly what any sales organization would want an employee to do: answered in good faith and asked for a phone number.

The answer to that answer is the attack.

Nothing in the thread had been stolen. There was no compromised mailbox, no quoted message lifted out of somebody else's inbox, no correspondence taken over midstream. The attacker assembled the thread from scratch, used the manufacturer's own lead-capture form as the opening move, and then waited to be answered. By the time the malicious message arrived it was the third turn in a conversation the recipient distinctly remembered participating in, which is a far stronger form of credibility than any spoofed header could manufacture.

Twelve Weeks Old and Authenticated Without a Flaw

The reply came from a domain that authenticated cleanly in every respect. SPF passed. DKIM passed with a signature aligned to the sending domain itself, using a selector published by the mail platform the attacker had signed up for. DMARC passed. ARC passed across the relay.

WHOIS is where the picture changed. The sending domain had been registered roughly twelve weeks before the message went out, through a large commercial registrar, with no public registrant data of any kind and mail service pointed at a commodity hosting provider. That combination is the shape of a domain bought to run an operation, not the shape of a purchasing department that has existed for years.

Authentication was never designed to distinguish between those two things. RFC 7489 describes a mechanism for proving that a message really did leave an authorized source for the domain in the From header. When the attacker owns the domain, satisfying that proof is trivial and entirely honest. A perfect pass here established custody, and custody is not identity.

The Label Said Microsoft, the Destination Said Otherwise

The body described a purchase requirement and pointed the recipient to a shared file. The link text rendered as a complete, well-formed Microsoft address: the real apex domain, a plausible product path through the OneDrive file service, and a terminal path segment reading as an authentication step. Read left to right, it looks copied out of a browser.

The href underneath pointed at a live application hosted on a general-purpose deployment platform, on a subdomain whose own name borrowed the OneDrive brand. Appended to it as a query parameter was the recipient's own email address, in plaintext.

That parameter is the tell that matters most. A file-sharing link does not need to be told who is opening it. A credential-harvest page does, because that is how it renders a sign-in prompt already addressed to the visitor, and how the operator learns which mailbox engaged. The 2024 Verizon Data Breach Investigations Report puts the median time from opening a phishing message to clicking its link at 21 seconds, and to submitting data at 28 seconds. Prevention has to happen upstream of that window, which is the whole premise of credential harvesting protection that reasons about a link rather than trusting its label.

A Signature Block Citing a Website That Does Not Resolve

Under the request sat a signature block: a name, the title of purchasing specialist, a company name, and a corporate website. That website is the cheapest thing in the entire message to test, and it fails. The address printed there does not resolve. There is no DNS answer at all, which was confirmed directly rather than taken on the strength of anyone's narrative.

Set that against the domain the mail actually came from and the two are not even the same string. The sending domain spells the company name with a doubled consonant that the signature does not, close enough to pass a glance and different enough to be a separate registration. One domain existed and had been bought recently. The other was cited as the company's public identity and had never existed at all.

This is what infrastructure acquisition looks like when it is done on a budget. Acquire Infrastructure: Domains covers the registration side, and the fabricated corporate identity is stitched on top of it with nothing behind it but text in a signature block.

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

Why One Button Produced Two Different Verdicts

The link analysis on this message returned two results, and both were correct.

The Microsoft address that served as the visible label was itself catalogued as a link and scanned clean, because it is a clean address on a real and reputable domain. Nothing about that verdict is a scanner failure: the string was evaluated accurately and the answer was benign.

The href scanned separately and came back ambiguous rather than clean: live, reachable, screenshot captured, verdict partial. So the same button carried a benign result and an unresolved one at the same time, and any workflow that reports the friendlier of the two, or that summarizes a message by its best link, hands back a clean bill of health. Resolution rather than reputation is the discriminator, and URL attack protection is only useful to the extent it evaluates where a link goes instead of what it says.

What Actually Stopped It

The platform's content analysis flagged the disguised address as a malicious link match and scored the message at 90 percent confidence. Worth stating plainly: the stored classification on the underlying case record was bulk mail rather than phishing, so the automated label undercalled the message even while the link analysis on that same message did not. Human review is what settled it. An analyst approved the finding manually, and the message was quarantined and mitigated, never released.

That split is the useful part of this case. A single categorical label is a lossy summary of everything a system observed, and the signal that mattered here, one anchor whose text and destination disagreed, survived in the link analysis after the label had smoothed it over. Keeping that reasoning visible rather than collapsing it to a verdict is what Adaptive AI with a human review loop is for.

What an Inbound Lead Can and Cannot Vouch For

A thread proves that messages were exchanged. It does not prove who opened it. If the counterparty wrote the first turn, every subsequent turn they receive is corroboration they engineered, and the internal reply sitting above their message is genuine in a way no forgery could match.

Three checks cost almost nothing against this pattern. Resolve the website in the signature block, because a claimed corporate identity with no DNS presence is finished as a claim. Compare every link's label to its destination, because the label is authored content and the destination is not. Treat a recipient's own address appearing in a query string as a decision point rather than a curiosity. CISA's phishing guidance and NIST's definition of phishing both frame the problem as misrepresented identity rather than malicious payload, and the 2023 FBI IC3 Internet Crime Report attributes roughly 2.9 billion dollars in reported losses to business email compromise, most of it built on exactly this kind of borrowed plausibility.

Indicators of Compromise

MITRE ATT&CK Mapping