Fake OneDrive Phish Cloaks Its Link in Google Translate

The credential-harvesting link in this fake OneDrive notice never once touched a domain the attacker owned. Every hop a defender would eyeball in the visible chain resolved to Google. The single call-to-action loaded the phishing page behind translate[.]goog, Google's own Translate proxy, wrapped in a valid Google-issued TLS certificate.

That is the whole trick, and it is a good one. Most credential-theft campaigns still lean on a lookalike domain: a homoglyph swap, a fresh registration, a subdomain stuffed with brand words. Those leave fingerprints that domain-reputation engines and analysts know how to read. This attacker skipped all of it and borrowed someone else's reputation instead.

A OneDrive lure aimed at an insurance claims team

The target was an insurance claims and adjustment services firm. The email arrived as a generic Microsoft document notification: a file was waiting, review it now, one button to open it. The display name read "Microsoft." Standard OneDrive and Microsoft branding, the usual urgency, and a couple of template defects that a careful reader would catch on a second pass.

The actual sender told a different story. The From domain was not Microsoft. It was an unrelated third-party organization's compromised mailbox, a legitimate business account that had been taken over and repurposed as a sending platform. This is the first and cleanest tell in the whole message: the brand claim says Microsoft, the sending domain says something else entirely. Brand-versus-domain mismatch is one of the oldest signals in email security, and it still works because attackers keep betting that recipients read the display name and stop there.

How the message actually got delivered

The delivery path is worth walking, because it is what made the authentication results misleading.

The message was submitted via authenticated SMTP from an Amazon EC2 host to the compromised sending domain's own mail server. From there it passed through a legitimate Barracuda Email Security Gateway before reaching Microsoft 365. That routing matters. By the time the message hit the final Microsoft 365 hop, SPF and DKIM both failed.

Here is the part that trips people up. Those failures were not proof of forgery. The Barracuda gateway in the path modifies the message body and rewrites links while it scans, and that modification breaks the DKIM body hash. So the DKIM failure at Microsoft 365 is a rewrite artifact from a legitimate security tool, not a spoofing signal. Treat that authentication failure as your smoking gun and you learn the wrong lesson: you tune a rule that fires on gateway-rewritten mail and drown in false positives, while the real attacks with clean auth sail through.

The 2024 Verizon Data Breach Investigations Report found stolen credentials involved in 38 percent of breaches, the single most common initial action, which is exactly what a page like this one is built to feed. The report also clocked the median time to click a phishing link at 21 seconds and to submit data at 28 seconds. A believable OneDrive prompt does not need much of a window.

The redirect that hides in plain sight

The email carried one call-to-action, a "View in Browser" link. Follow it and you land on a translate[.]goog subdomain.

Google Translate, like many translation and proxy services, will fetch an arbitrary web page and re-serve it from its own infrastructure so the content appears translated. Point that service at a credential-harvesting page and the resulting URL inherits three things the attacker could never buy cheaply: a Google-owned parent domain, a trusted Google TLS certificate, and a clean reputation. This is a textbook proxy technique, mapped in MITRE ATT&CK as T1090 (Proxy), combined with Spearphishing Link (T1566.002) and Masquerading (T1036.005).

Notice what is absent from the entire chain: no onedrive.com, no sharepoint.com, no login.microsoftonline.com. A message claiming to deliver a OneDrive document never once routes through a real Microsoft endpoint. That absence is louder than anything in the headers.

Indicators of Compromise

Where the gateway lost and the model won

A secure email gateway (SEG) evaluates this message and finds a link that stays on a Google-owned domain with a valid certificate. Domain reputation passes. Certificate validation passes. There is no attacker domain to blocklist, because the attacker never registered one. IRONSCALES platform data shows SEGs miss an average of 67.5 phishing emails per 100 mailboxes each month, and this is the shape of the miss: a message engineered so that every atomic check comes back green.

Themis, our Adaptive AI analyst, does not score the domain in isolation. It reads the message the way an experienced analyst would: a Microsoft brand claim from a non-Microsoft sender, a document-delivery pretext with no Microsoft endpoint anywhere in the redirect chain, a lone call-to-action resolving through a translation proxy, and template defects inconsistent with genuine OneDrive mail. The credential harvesting intent surfaces from the combination, not from any single indicator, which is why the auth failure never enters the verdict as evidence of forgery.

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

For teams running Microsoft 365, this is the argument for defense in depth over any one control. The CISA guidance on stopping the phishing attack cycle makes the same point: layered detection catches what single-signal filters cannot. IRONSCALES pairs its behavioral analysis with Microsoft 365 augmentation precisely so that content and intent are judged even when the plumbing looks clean. The NIST definition of phishing still centers on deception, and deception is a content property, not a DNS record.

The takeaway: follow the redirect, not the hostname

Stop treating a trusted parent domain as a trusted destination. A translate[.]goog, google.com, or any proxy URL can front an attacker-controlled page while carrying a legitimate certificate. Build detection that resolves every redirect to its true landing page and evaluates the brand claim against the actual sending domain, and treat authentication failures from known in-path gateways as noise to be explained, not evidence to be trusted. The insurance firm here was protected by 36,000+ security professionals across 18,000+ organizations feeding the same detection model. The attacker's best idea was to borrow Google's reputation. The defense was to refuse to lend it back.