Two Google Redirects, One Credential Harvest: How Nested google.gr Laundering Beat Link Scanners

The link pointed to Google. Not a lookalike. Not a typosquat. The actual google.gr domain, which redirected to google.com, which redirected to a credential harvest page on a compromised photography studio's subdomain. Two of the three link scanners returned clean verdicts. They saw Google and stopped looking.

This campaign targeted a mid-size professional services firm with a DocuSign-branded email carrying a "REVIEW DOCUMENT" call to action and a fabricated 33-character security code in the footer. The social engineering was competent but unremarkable. The redirect architecture was the real weapon.

Four mailboxes received the email. Three were quarantined at staggered intervals over five days. One was never mitigated by the legacy security stack. The email failed SPF, DKIM, and DMARC. It reached every inbox anyway.

Google's Own Infrastructure as a Laundering Chain

The CTA button resolved to hxxps://www[.]google[.]gr/url?q=..., a Google redirect service on the Greek country-code domain. That URL contained a second redirect through hxxps://www[.]google[.]com/url?q=..., with the final destination triple-encoded in the query parameter. The terminal URL pointed to offxin.sbanhe.agustinmartinezfotografo[.]es, a subdomain on a compromised Spanish photography studio domain.

This is MITRE ATT&CK T1027 (Obfuscated Files or Information) applied to URL structure. The nesting is deliberate. Each Google redirect layer absorbs one round of automated inspection:

1. Layer 1: Scanner sees google.gr. Trusted domain. Clean verdict.
2. Layer 2: Scanner follows redirect to google.com. Still trusted. Clean verdict.
3. Layer 3: The actual credential harvest at agustinmartinezfotografo[.]es. Flagged as malicious, but only when evaluated in isolation without the Google wrapper.

The distinction matters. In the email body, all three links shared the same final destination, but two were wrapped in the nested Google redirect chain and one was the naked malicious URL. The wrapped versions passed inspection. The naked one was caught. Same payload, different packaging, different outcomes.

The landing page presented a Microsoft-branded login interface fronted by a Cloudflare-style "verify you are human" interstitial widget. That bot gate exists to filter automated security sandboxes. If a scanner follows the full chain but cannot solve the challenge, it never sees the credential form behind it. The domain was returning NXDOMAIN at the time of investigation, consistent with transient infrastructure that attackers spin up and tear down within days.

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

Every Authentication Check Failed (and It Didn't Matter)

The email arrived from dse@docusign[.]net with the display name "Docusign Via Docusign." The authentication results tell a clear story:

• SPF: FAIL. The sending IP 209[.]222[.]82[.]130 belongs to Barracuda ESS (outbound-ip121a.ess.barracuda[.]com), which is not authorized by docusign.net.
• DKIM: None. The message carried no DKIM signature at all.
• DMARC: FAIL with a policy of oreject, meaning DocuSign has explicitly instructed receiving servers to reject unauthenticated mail.
• compauth: None, reason 451 (generic failure).

Under normal conditions, a DMARC oreject policy should have stopped this email at the gateway. It did not. The spam confidence level (SCL) was set to -1, which tells Microsoft 365 to skip spam filtering entirely. An SCL of -1 typically results from an allow-list entry, a transport rule, or a Barracuda ESS gateway configuration that overrides Microsoft's native evaluation.

The relay chain confirms the path: the message originated from IP 173[.]195[.]100[.]164, passed through Barracuda ESS infrastructure, and entered the Microsoft protection front-end. Barracuda's presence in the relay chain as both the sender IP's reverse DNS and the gateway suggests the recipient organization uses Barracuda ESS as their secure email gateway. The missing DKIM signature is consistent with either a message that was never signed or one modified in transit by the gateway.

This pattern is worth highlighting. According to the Microsoft Digital Defense Report 2024, email-based attacks remain the dominant initial access vector, with credential phishing accounting for a growing share of incidents. When a gateway override neutralizes DMARC enforcement, the organization loses its strongest sender-verification signal and falls back on content analysis alone. Content analysis that, in this case, saw Google links and called them clean.

The Brand Impersonation Template

The email used MITRE ATT&CK T1036 (Masquerading) with a standard DocuSign document-review template. The "REVIEW DOCUMENT" button was styled to match legitimate DocuSign notification emails. A fabricated security code (A623E038255D4941AB92E735A1253DD83) appeared in the footer, mimicking the format DocuSign uses in real notifications to help recipients verify authenticity.

The delivery mechanism was T1566.002 (Spearphishing Link). The subject line itself was a tell. "Review Document: Kindly sign : fllename PaymentNotice-EFT" contains two red flags: "fllename" (missing an 'i') and the colon-heavy syntax that deviates from DocuSign's actual notification format. The mail client surfaced an "Unusual link" warning banner, but with an SCL of -1, the message bypassed spam filtering regardless.

This was a first-time sender flagged as high risk. Themis, our Adaptive AI, classified the incident at 81% confidence on credential theft with a VIP recipient flag, correlating the authentication failures, first-time sender status, and community intelligence signals from similar campaigns across the IRONSCALES platform. The email was automatically resolved as phishing.

The Allow-List Override and What It Cost

The Verizon 2024 Data Breach Investigations Report documents that credential theft remains one of the most common initial access methods, with phishing as the primary delivery vector. This campaign shows why: the combination of trusted redirect infrastructure, brand impersonation, and policy overrides creates a gap that no single control can close.

Three actions this case supports:

Audit your allow-lists and transport rules. An SCL of -1 on an email that failed SPF, DKIM, and DMARC means something in the mail flow explicitly told Microsoft to trust it. Gateway configurations that broadly allow-list upstream appliances (like Barracuda ESS connector IPs) can inadvertently neutralize DMARC enforcement. Review these rules quarterly.

Require full-chain link resolution. URL reputation on the first hop is not a security control when the first hop is Google. Your link inspection must follow every redirect to the terminal URL, resolve it, and evaluate the landing page independently. Two-thirds of the links in this email were marked clean because the scanner stopped at Google.

Layer behavioral detection on top of authentication. DMARC is a necessary control, not a sufficient one. When it fails and the message still lands (as it did here), behavioral AI that evaluates sender history, brand consistency, and community signals is the detection surface that remains. That is exactly what caught this campaign.

The IBM 2024 Cost of a Data Breach report puts the average breach at $4.88 million, with phishing-initiated breaches carrying above-average costs due to credential reuse and dwell time. The cost of resolving this email before any credentials were entered: zero.

---

Indicators of Compromise