How Phishing Beats URL Scanners via Google Translate

The link in the email said usps.com. The URL scanner agreed it was clean. Both were wrong.

Buried under a Google Translate proxy and a gateway link-protection wrapper sat a credential harvesting page on a throwaway dynamic-DNS domain, hidden behind Cloudflare. The message reached the inbox of a senior operations executive at a mid-size U.S. insurance claims management firm. The reputation check that was supposed to catch it waved it through, because the only host it could see belonged to Google.

This is reputation laundering, and it is one of the cleaner ways to walk a phishing link past a Secure Email Gateway (SEG) today.

The USPS Alert That Google Vouched For

The lure was ordinary. A parcel notification claiming a delivery problem, a tracking number, and an instruction to update the delivery address before the package was returned. The kind of message most people process on autopilot from their phone.

The anchor text displayed what looked like a legitimate postal URL. Look closer and it was stuffed with zero-width characters, invisible Unicode bytes wedged between nearly every letter of the visible address. To a human, the link read as usps.com/Update_Address. To a naive text-matching filter, the string was fragmented into noise that no longer matched a known-bad pattern.

That is only the surface trick. The real evasion was in where the link actually went.

How the Redirect Chain Laundered the Page

Clicking the link started a three-hop journey, and each hop was designed to hand the next one someone else's trust.

Hop one: the organization's own gateway link-protection service, which rewrites inbound URLs so they can be re-scanned at click time. Legitimate infrastructure, doing its job.

Hop two: a Google Translate proxy URL on the translate.goog domain. Google Translate can render any webpage through Google servers, and the resulting address looks like [target-site].translate.goog/?_x_tr_sl=auto&_x_tr_tl=.... The attacker fed it the malicious site, so Google's translation proxy served attacker content over a Google-owned domain with a Google TLS certificate.

Hop three: the true origin, a subdomain on the free dynamic-DNS service dpdns.org, fronted by Cloudflare so the real host IP stayed hidden. The landing page reproduced the USPS interface and asked for personal and payment details. Classic credential and data harvesting.

Every layer in that chain except the last one is a service a security team already trusts.

Why Reputation-Based Scanning Returned Clean

URL reputation works by asking a simple question: do we trust the domain this link points to? When the link points to translate.goog, the answer is yes. Google is one of the most trusted domains on the internet. The scanner evaluated the visible intermediary, inherited Google's reputation, and returned a clean verdict. The dynamic-DNS origin behind the proxy was never scored, because reputation scoring stops at the first host it recognizes.

Dynamic-DNS abuse makes the origin even harder to pin down. Services like dpdns.org hand out free subdomains that attackers spin up and abandon within hours, and Cloudflare fronting means the domain resolves to shared infrastructure rather than a blockable attacker IP. By the time a reputation feed learns the origin is malicious, the campaign has moved.

This is not a Google problem or a Cloudflare problem. It is a design assumption problem. Reputation treats a domain as a proxy for intent, and a proxy for intent breaks the moment a legitimate service can be pointed at a malicious destination.

MITRE ATT&CK classifies this as Phishing: Spearphishing Link (T1566.002), paired with brand impersonation. The 2024 Verizon Data Breach Investigations Report found phishing present in 15% of breaches, and that the median user clicks a phishing link within 21 seconds of opening the message. Link-only lures like this one are the majority case, not the edge case, and 39% of breaches involve credentials somewhere in the kill chain.

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

Where Behavior Beat Reputation

Reputation checking asked the wrong question. Behavioral analysis asked better ones.

The sender was a first-time contact using a consumer Outlook mailbox with a random, vowel-starved local part, while the display name impersonated a courier. The envelope had been rewritten through a forwarding service, and authentication told the real story: SPF soft-failed, there was no DKIM signature, and DMARC failed outright for the header-from domain. Most decisive, the anchor text (a postal address) did not match the destination (a Google Translate proxy). A message does not need a reputation lookup to know that a package alert should not resolve to a translation gateway.

Themis, the IRONSCALES agentic AI analyst, scored the message a 90% phishing probability on these signals and labeled it both credential theft and a VIP-targeted attempt. The Adaptive AI engine resolved and reverted the message across the affected mailboxes within seconds of delivery, well before a click. When two more waves followed under new subject lines over the next 48 hours, the same behavioral fingerprint caught them too. Reputation would have had to wait for the origin to burn; behavior did not.

Locking Down Reputation-Laundered Links

The takeaway is not "block Google Translate." Plenty of legitimate mail contains translate.goog links, and blanket blocking trades one problem for a flood of false positives. The fix is to stop treating a trusted intermediary as proof of a trusted destination.

• Weigh sender and message behavior, not just the endpoint domain. First-time sender, display-name mismatch, and failed authentication are context that reputation ignores. Layer credential-harvesting protection that scores intent, not just the URL.
• Flag anchor-versus-destination mismatches. When visible link text claims one brand and the href resolves somewhere else, that gap is a signal on its own, zero-width character tricks included.
• Follow the chain to the true origin. Advanced URL protection that unwraps proxies and redirects to evaluate the final landing page defeats intermediary laundering. Scan the destination, not the doorway.
• Treat dynamic-DNS and newly observed hosts as elevated risk. Free subdomain services and Cloudflare-fronted origins are cheap and disposable for a reason.

Authentication protocols like SPF, DKIM, and DMARC still matter, and here all three failed, yet the message landed anyway. Reputation still matters too. But neither is a substitute for asking whether this specific sender, sending this specific message, is behaving like a threat. The CISA phishing guidance and the Microsoft Digital Defense Report 2024 both make the same point: attackers increasingly hide inside legitimate services, and the FBI IC3 2023 report counts billions in losses that started with exactly this kind of trusted-looking link.

When the doorway is Google and the destination is disposable, the domain is not the threat. The behavior is.

Indicators of Compromise