Phishing Campaign Hides Behind Multi-Hop Google Redirects to Steal Credentials

Trusted Google services form a three-hop attack chain

An ongoing phishing campaign is routing victims through several legitimate Google services before delivering credential-harvesting pages or remote-access software.

KnowBe4 researchers Prabhakaran Ravichandhiran and Jeewan Singh Jalal described the activity on September 4. The operation uses a three-hop redirect chain intended to frustrate email security gateways, URL scanners, and automated inspection systems.

Instead of placing an attacker-controlled address directly inside a malicious email, the operators incorporate services including Google Meet, DoubleClick advertising infrastructure, Google Custom Search, Google Image Search, Google Tag Manager, and Google Analytics.

Each redirection exposes security products to another reputable Google-operated domain. A gateway that assigns substantial weight to domain reputation may therefore treat the link as benign, particularly if it does not follow the entire chain or analyze the final page in a real browser.

The technique is more deliberate than simply shortening or concealing a malicious URL. The infrastructure is designed to remain plausible throughout successive inspection stages, while the destination can delay or modify its behavior until automated checks have finished.

Google had not commented on the reported campaign at the time of publication.

URL fragments conceal victim-specific targeting data

One of the operation’s clearest detection signals is the placement of the recipient’s email address in the URL fragment—the portion following the # character. The address is encoded with Base64 and used to personalize the destination.

A simplified structure might resemble:

https://legitimate-service.example/path#BASE64_ENCODED_EMAIL

The fragment has a useful property for attackers: browsers generally do not include it in the HTTP request sent to a web server. It remains available to client-side JavaScript, but may be absent from server access logs and from security tools that record only the requested resource.

Once the final page loads, its JavaScript can read the fragment, decode the email address, and build a tailored phishing experience. The page can prepopulate the victim’s identity and display an image of the organization’s genuine website behind a counterfeit login interface.

This produces two advantages. First, the victim sees a page that appears connected to their employer rather than a generic credential prompt. Second, some network and server-side telemetry may record the redirect destination without preserving the targeted email address.

Base64 is encoding, not encryption. A security product that captures the complete URL can readily decode it. The problem is whether that product retains and analyzes the fragment at all.

The presence of an encoded email address after #, especially in a message linking through Google infrastructure, should consequently be treated as a high-value detection clue. It does not prove that every such URL is malicious, but it gives defenders a narrow pattern to investigate.

The destination adapts to the victim and the inspection environment

The malicious emails use several business-oriented pretexts rather than one consistent template. Observed themes include document reviews, expiring credentials, package deliveries, payments, government benefits, and voicemail notifications.

After the recipient clicks, the redirects eventually lead to one of two principal outcomes. The first is a counterfeit corporate authentication page built to collect usernames and passwords. The second is a fraudulent identity-verification workflow that attempts to install ScreenConnect.

ScreenConnect is used here as a remote-access tool rather than as the underlying redirection mechanism. The specific ScreenConnect versions involved have not been disclosed, and the campaign is not described as exploiting a software vulnerability. Its danger comes from persuading a user to install or run unauthorized remote-administration software.

The phishing framework can adjust content according to the victim’s geographic location and supports multiple languages. It also collects contextual information that can help the operators evaluate both the target and the compromised session.

Reportedly exposed data includes:

• Corporate login credentials
• Public IP addresses
• Geolocation information
• Browser user-agent strings
• Verified mail-exchange records associated with the victim’s organization
• Organizational targeting and session metadata

Stolen credentials and collected metadata are delivered to the operators through a Telegram channel, reportedly within seconds. Telegram provides a convenient communications layer that may blend with other encrypted messaging traffic unless defenders specifically monitor bot and API activity.

The campaign therefore combines personalization, evasion, and rapid exfiltration. A successful interaction can lead to account takeover, while an unauthorized ScreenConnect installation can provide a path to direct remote administration.

Why domain reputation alone fails against this technique

Many email and web controls inspect a link’s visible hostname, query reputation services, and follow a limited number of redirects. That model becomes weaker when attackers can assemble a chain from legitimate cloud and advertising components.

Blocking Google domains broadly would create substantial operational disruption. The attackers benefit from that constraint: defenders must distinguish malicious use from large volumes of ordinary business traffic rather than denying the infrastructure outright.

A scanner may also observe different behavior from a human visitor. The final harvester can wait for inspection to conclude, evaluate environmental signals, or alter its response according to location and session characteristics. A clean result from one automated request does not guarantee that a user will receive the same page.

Controls should therefore evaluate the complete navigation path, including:

1. The original URL embedded in the email
2. Every intermediate redirect and its parameters
3. The final registered domain and hosting location
4. Client-side scripts executed after the page loads
5. URL fragments preserved in the original message
6. Follow-on downloads, login forms, or remote-access prompts
7. Outbound communications initiated after user interaction

This campaign does not depend on a single compromised Google product or a disclosed vulnerable version. It exploits the trust relationships surrounding several services and gaps between email, proxy, browser, endpoint, and identity telemetry.

Defenders should hunt for Telegram traffic and ScreenConnect activity

Organizations should apply the published indicators of compromise across DNS filtering, secure web gateways, proxies, endpoints, and SIEM platforms. Blocking at only one layer may miss later stages of the redirect chain.

Security teams should also search for outbound connections to the Telegram Bot API and other unusual Telegram-related communications. Such traffic deserves additional scrutiny when it follows a suspicious email click, a visit to an unfamiliar authentication page, or the execution of a new process.

Endpoint hunting should focus on unauthorized ScreenConnect installations and activity. Relevant checks include unexpected installation events, newly created services, executions from user-writable directories, and remote-access sessions that do not correspond to an approved support workflow. Legitimate organizational deployments must be separated from unapproved instances.

Potentially affected users should have their passwords reset. Defenders should also review authentication records for unusual locations, devices, session creation, multifactor-authentication changes, and access occurring shortly after the phishing message was delivered.

Useful defensive actions include:

• Preserve full URLs, including content after the # character, in email-analysis telemetry.
• Decode Base64 fragments during message and URL inspection.
• Follow all redirects instead of evaluating only the first Google hostname.
• Correlate Google-service redirects with newly displayed login forms.
• Hunt for subsequent ScreenConnect downloads, installation, or execution.
• Monitor Telegram Bot API traffic as a possible exfiltration channel.
• Warn users that familiar cloud domains do not guarantee a safe destination.
• Investigate messages using document, delivery, payment, voicemail, benefits, or credential-expiration themes.

User awareness should focus on behavior rather than branding. A link may begin on a legitimate Google service and still terminate at an attacker-controlled page. Unexpected authentication requests and identity checks that require remote-access software should be reported rather than completed.

The defining feature of this campaign is not any single phishing lure. It is the coordinated use of trusted redirect infrastructure, hidden targeting data, adaptive web content, and near-real-time exfiltration to make a customized attack look routine.