As reported by Dark Reading, threat actors have been caught conducting a sophisticated phishing campaign that abuses multiple Google services through chained redirect hops, ultimately harvesting credentials or deploying ScreenConnect remote access tooling on victim endpoints. The campaign is notable not for its payload but for its delivery mechanism: each redirect traverses a legitimate Google-owned domain, meaning traditional URL reputation systems see only "google.com" at every hop.
What makes this campaign worth dissecting isn't the ingenuity of the technique — open redirect abuse has been documented for well over a decade. It's the composition that matters. By stacking multiple Google redirect endpoints in sequence, the attacker forces every intermediate hop through infrastructure that security tools have been trained since day one to trust implicitly. Email gateways flag the initial link as safe. Browser warnings never fire. The user sees familiar Google branding at each stage. Only the final destination — often a credential capture page or a dropper payload — is hostile, and by then the victim has already been conditioned through three or four legitimate-looking redirects to trust the experience.
Why This Pattern Works Against Modern Defenses
Most email security and web filtering technologies operate on a simple heuristic: if the destination is a top-tier trusted domain, allow it. This is fundamentally at odds with how redirect chains work. The problem compounds when multiple high-reputation services are used in sequence — the intermediate URLs all resolve to known-good domains, so behavioral analysis engines that evaluate URL reputation at each hop find nothing actionable until the final transition to attacker-controlled infrastructure.
ScreenConnect as the payload endpoint is also worth examining. ConnectWise's ScreenConnect is legitimate remote support software — exactly the type of dual-use tool that blends into normal IT operations. Once installed, an attacker operating through ScreenConnect looks indistinguishable from a helpdesk technician remoting in for a ticket. EDR tools may not flag it. Security teams performing user behavior analytics may not notice it if the activity occurs during business hours and follows plausible support patterns.
The core issue isn't that Google has an open redirect problem — it's that the security ecosystem has built its trust model around domain reputation, and attackers have learned to route through enough trusted domains to exhaust that model's usefulness.
Who Is Most Exposed
- Organizations with email security gateways heavily reliant on URL reputation scoring — if your filtering decision is primarily "is this a known-good domain," multi-hop redirects through Google defeat it.
- Environments where remote access tools are broadly deployed — if ScreenConnect, TeamViewer, AnyDesk, or similar tools are already in use for legitimate support, an attacker-installed instance may not trigger anomaly detection.
- Sectors with high-volume helpdesk operations — IT service providers, MSPs, healthcare IT, and financial services where remote support sessions are routine and numerous.
- Users who have been conditioned to trust Google authentication flows — which is essentially everyone who uses Google Workspace.
What Defenders Should Actually Do
The response to this campaign cannot be "block Google redirects" — that would break an enormous volume of legitimate traffic. Instead, defenders need to shift toward destination-aware analysis rather than hop-by-hop reputation scoring.
For email security teams: Configure your gateway to perform full redirect chain resolution — follow every redirect to its final destination before making a allow/deny decision. If your current tool cannot do this, it is a capability gap that needs to be addressed at the vendor level or through a supplementary reanalysis layer. Sandbox any URL that uses a known redirect service (Google, Microsoft, LinkedIn, etc.) and evaluate only the terminal URL against your threat intelligence.
For endpoint and identity teams: ScreenConnect and similar remote access tools should be inventory-controlled. Know every legitimate instance in your environment. Deploy detection rules for ScreenConnect installations outside your sanctioned deployment path — unexpected executable paths, services created outside change windows, or instances running from user-profile directories. If you use ScreenConnect legitimately, baseline its normal process tree and alert on deviations.
For security awareness programs: This campaign exploits a trust assumption that's difficult to train away — users genuinely cannot distinguish between a real Google redirect and an abusive one. Focus training on the final destination: before entering credentials, users should verify the actual URL in the browser address bar matches the expected authentication domain. Multi-factor authentication enrollment and enforcement remains the single most effective control against credential harvesting, regardless of how the phishing link was delivered.
Shield53 Recommendations
- Audit redirect handling in your email security stack — confirm your gateway resolves full redirect chains to terminal URLs before reputation scoring. Test with known multi-hop redirect test URLs.
- Inventory all remote access tools — identify legitimate instances of ScreenConnect, TeamViewer, AnyDesk, ConnectWise Control, and similar tools. Create allowlists for expected installation paths and service accounts.
- Deploy detection for unsanctioned remote access software — alert on any installation of remote access tooling outside your approved deployment process or change management windows.
- Enforce phishing-resistant MFA — FIDO2/WebAuthn hardware keys or platform authenticators. TOTP-based MFA is vulnerable to real-time relay attacks from credential harvesting pages; phishing-resistant methods are not.
- Engage your email security vendor — if you use a cloud email filtering service, open a support case specifically asking how they handle multi-hop redirects through trusted infrastructure. If the answer is unsatisfactory, it's time to evaluate alternatives.
- Consider DNS-level monitoring — endpoint DNS logging that correlates user clicks with subsequent DNS resolutions can catch the final destination domain even when the email-layer redirect chain is trusted.
The broader lesson here applies beyond Google. Every major platform — Microsoft, LinkedIn, Adobe, Atlassian, any service that issues authenticated redirect URLs — represents a potential link in a multi-hop chain. The attack surface isn't any single vendor's redirect implementation; it's the collective assumption across the security industry that traffic passing through a trusted domain is trustworthy. Attackers have been mapping those assumptions for years. It's time defenders started mapping them too.
