A Real Vendor RFQ, a Fake Google Login Page

The malicious link in this attack carried a verdict of "clean" from a per-URL reputation scan. It was also the credential-harvest vector. That gap is the whole story.

The message looked like routine procurement traffic: a request for quote and contract terms from a real industrial-equipment vendor, addressed to a VP who fields exactly this kind of vendor correspondence. It authenticated cleanly. SPF passed, DKIM passed, and DMARC passed, with a Microsoft compauth score of 100. There was no forged header to catch, no spoofed display name to flag, because the email genuinely came from the vendor's own mailbox. The vendor's account had been compromised, which makes the vendor a victim here too. This is the defining trait of vendor email compromise: the sender is real, the trust is inherited, and the payload rides in on a relationship the recipient already values.

The filename that never matched the href

The body offered a single actionable item, an attachment styled as a spreadsheet with the display text "Agreement Terms.xlsx." The subject even claimed the file was delivered "from SharePoint," lending it the veneer of a corporate document workflow. Only the underlying link told the truth. The href pointed to jinqyemetals[.]com/home, a domain with no relationship to the vendor, the recipient, or SharePoint.

That mismatch between a link's display text and its destination is textbook masquerading, MITRE ATT&CK T1036.005, and it is the pivot the entire attack turns on. A recipient scanning for legitimacy sees a plausible filename attached to a plausible vendor email. Nothing in the visible layer contradicts the story. The deception lives entirely in the anchor, which is exactly where hurried readers do not look. This is spearphishing via link, T1566.002, dressed as a document handoff.

A month-old domain as a disposable doorway

The jinqyemetals[.]com domain was registered on October 31, 2025, roughly a month before this message went out. It carried minimal DNS records and no mature email-authentication posture. It was not built to host a business. It was built to point somewhere else, and then to be thrown away.

Fresh domains like this exist to break the reputation model. Blocklists and threat feeds need time and telemetry to catch up to a new domain, and a month is often not enough. During that window the domain is effectively invisible to reputation-based filtering, which is why a per-URL scan returned "clean" on it. The scanner judged the first hop in isolation and found nothing to condemn. It did not follow where the hop led.

The harvest surface was Google's own front door

Following the link, the domain fired three consecutive 302 redirects. The chain terminated at a Google Sites page and a Google sign-in flow on accounts.google.com, staged to harvest credentials. This is the second half of the trust-laundering play, and the sharper one.

Staging the final page on Google infrastructure does two things at once. It borrows Google's reputation, since sites.google.com and accounts.google.com are among the most allowlisted destinations on the internet and rarely trip reputation filters. And it borrows Google's familiarity, presenting a login prompt on a domain the victim signs into every day. The attacker never had to build convincing infrastructure. They pointed at Google's, which is why the endpoint reads as trustworthy to both the filter and the human. Microsoft's researchers have documented this migration toward abusing legitimate cloud and collaboration services as a delivery and hosting layer in the Microsoft Digital Defense Report 2024, precisely because trusted domains defeat trust-based defenses.

Credentials remain the prize. The Verizon 2026 Data Breach Investigations Report attributes 39 percent of breaches to credentials somewhere in the kill chain and finds phishing serving as the initial access vector in 16 percent of them. Credential harvesting is the quiet engine behind account takeover, and a page that mimics a Google login is engineered to feed it. The FBI's 2024 Internet Crime Report continues to rank phishing as the most-reported cybercrime by complaint volume, and impersonation, T1656, sits underneath most of it.

Why the confidence score stopped at 59 percent

Themis flagged this message at 59 percent, labeled Credential Theft against a VIP Recipient. That is a moderate score, and the moderation is instructive rather than a miss. Genuine SPF, DKIM, and DMARC passes, a first-time sender for a known vendor, and a real business domain all pull the reputational read toward benign. A well-laundered attack is supposed to look ambiguous. It is the whole point.

What tipped the balance was behavior, not headers. Our Adaptive AI followed the link the scanner trusted, resolved the redirect chain, and weighed the filename-versus-destination mismatch, the newly registered intermediary, the first-time-sender signal, and a login page as the terminal state. Detection that reads intent catches what authentication cannot, because authentication only proves the vendor was authorized to send, per CISA's phishing guidance, not that the message deserved trust. The email was quarantined before any password was entered. This was attempted credential harvest that never landed. Getting the user to click a malicious link, T1204.001, was the plan, and the plan was interrupted.

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

Indicators of compromise

The takeaway

Authentication answers one question: was this sender allowed to send? It never answers the one that matters: should the recipient trust what they sent? When the sending account is a compromised but genuine vendor and the landing page lives on Google's own infrastructure, both ends of the attack are laundered through trust the defender already extended. Reputation scoring, run on either end in isolation, comes back clean. SEGs miss roughly 67.5 phishing emails per 100 mailboxes each month for exactly this reason, according to IRONSCALES platform data drawn from more than 35,000 security professionals.

The durable defense is to read the whole story, not the header. A link whose filename does not match its destination, a redirect chain that ends at a login prompt, a fresh intermediary domain, and a first-time sender wearing a familiar vendor's face are all signals that survive a passing authentication check. Trust the behavior. The headers will lie to you politely.