1. Basic Information Article Title: Attackers Use Multi-Hop Google Redirects for Phishing Publisher: Dark Reading Publication Date: 2026-09-08 Original Source: Dark Reading Related Sources: KnowBe4: Bypassing the Gatekeepers Related Malware, Groups, CVEs, and Products: Google Meet, Google DoubleClick, Google Custom Search, Google Image Search, Google Tag Manager, Google Analytics, ScreenConnect, Telegram Bot API Priority: High 2. Executive Summary A phishing campaign uses Google Meet, DoubleClick, Custom Search, Image Search, Tag Manager, and Analytics in multi-hop redirects, disguises landing pages with screenshots of the victim organization’s actual website, and branches into credential theft or ScreenConnect installation. 3. Attack Flow Separate paths for credential theft and remote-access tool installation An attacker sends a phishing link containing the target’s email address. The link passes through multiple legitimate redirects involving Google Meet, DoubleClick, Search, Tag Manager, Analytics, and related services. The landing page dynamically impersonates a corporate portal using screenshots of the victim domain’s real website, its logo, and language settings. The credential path captures the password twice and sends it to Telegram. The remote-access path uses a fake identity check to persuade the user to install ScreenConnect. Credentials are sent to Telegram. In a separate branch, ScreenConnect enables persistent endpoint access. Individual successful authentications and victim counts have not been disclosed. 4. Attacker Position and Execution Environment An external attacker able to send personalized links by email or messaging. An attacker combining Google redirect functionality with attacker-owned or compromised infrastructure. 5. What Users and Administrators May See Users A chain of Google domains followed by screenshots of the organization’s own website can make the link and login page appear legitimate. Administrators Inference: Redirect history through Google URLs and unauthorized ScreenConnect installation may appear in separate log sources. 6. Success Conditions and Risk Reduction Success Conditions The user trusts the legitimate Google domains and opens the link. Scanners do not fully follow the redirect chain or client-side fragment handling. The user enters credentials or installs ScreenConnect. Failure Conditions and Risk Reduction Do not allow links solely because they use Google domains; resolve the redirect chain and final destination in email gateways or sandboxes. Detect email addresses in URL fragments, retrieval of corporate website screenshots, newly observed domains, and Telegram Bot API activity. Allowlist RMM tools such as ScreenConnect by approved instances, certificates, and server URLs, and block unauthorized installations. 7. Potential Impact Theft of credentials, including Microsoft 365 credentials, and immediate exfiltration to Telegram. Persistent endpoint access through ScreenConnect that is less affected by password resets or MFA. Collection of browser, IP, location, and organization information for target selection. 8. Observable Logs Inference: These are investigation sources and their collection requirements. Email: Where relevant emails exist, preserve the original messages, complete URLs, and delivery records. Proxy/SWG/DNS: Where TLS inspection is available, inspect redirect destinations, image-retrieval APIs, Google DNS API calls, and Telegram API communications. The portion of a URL after # is not sent in ordinary HTTP requests. Endpoint/EDR: Preserve complete URLs from original emails or available browser history. Investigate ScreenConnect installation, service startup, and connections on the endpoint. Identity/IdP: Check related accounts for suspicious authentication and session use. Assess successful authentication separately from data retrieval. SaaS/Cloud: For cloud deployments, review audit records for workloads, IAM, and API operations. Network: Check ScreenConnect destinations and connection times. Track the credential-theft and RMM-installation branches separately. 9. Assessing Attack Success The following are evidence criteria for an individual investigation. See Facts and Unknowns for the scope of actual observations. Attempt observed (success unconfirmed): Evidence criterion: Confirm the phishing email and a click on a URL that passes through Google. User interaction confirmed: Evidence criterion: Confirm credential entry or ScreenConnect installation by the user. Initial execution confirmed: Evidence criterion: For the RMM branch, confirm execution of the suspicious ScreenConnect installer. In the credential-theft branch, distinguish page display or MX queries from endpoint malware execution. Malware execution or authentication success confirmed: Evidence criterion: Confirm a successful login using stolen credentials or establishment of a ScreenConnect session. Data theft or session compromise confirmed: Evidence criterion: Confirm transmission of credentials or endpoint/user information to Telegram. Follow-on compromise confirmed: Evidence criterion: Confirm mailbox access, session abuse, remote commands, or additional compromise. 10. Investigation Playbook Inference: Operational recommendations based on publicly described behavior. Trigger: A user-reported phishing email or an unauthorized ScreenConnect installation. Initial Checks: Identify the affected host, user, and time, and preserve relevant logs and configuration. For vulnerability incidents, verify the actual version and exposure. Endpoint: Preserve complete URLs from original emails or available browser history. Investigate ScreenConnect installation, service startup, and connections on the endpoint. Identity and Cloud: Check related accounts for suspicious authentication and session use. Assess successful authentication separately from data retrieval. For cloud deployments, review audit records for workloads, IAM, and API operations. Follow-on Activity: Check ScreenConnect destinations and connection times. Track the credential-theft and RMM-installation branches separately. Containment: Reset passwords and revoke sessions for users who entered credentials. Isolate endpoints that ran unauthorized RMM software and preserve remote-access history. Classification: These success criteria are for investigations. Distinguish evidence confirmed in the individual environment from publicly reported observations. 11. Defense and Detection Ideas Inference: Operational recommendations based on publicly described behavior. Single Event: A user-reported phishing email or an unauthorized ScreenConnect installation. Time-Series Correlation: For credential theft, correlate clicks, credential entry, and suspicious authentication. For RMM installation, separately correlate download, execution, and remote connection. Threat Hunting: Where TLS inspection is available, inspect redirect destinations, image-retrieval APIs, Google DNS API calls, and Telegram API communications. The portion of a URL after # is not sent in ordinary HTTP requests. Check ScreenConnect destinations and connection times. Track the credential-theft and RMM-installation branches separately. Logging Gaps: Check retention periods and collection settings. DNS alone does not reveal URL paths, and ordinary network logs do not reveal endpoint-local activity. Missing records do not prove an absence of compromise. Priority Controls: Do not allow links solely because they use Google domains; resolve the redirect chain and final destination in email gateways or sandboxes. 12. Facts / Inference / Hypothesis Facts On September 8, 2026, Dark Reading reported a global phishing campaign that KnowBe4 had been investigating. The primary analysis describes six Google services used across multiple redirect paths. The links chain legitimate Google domains to hide the final destination from scanners and reputation checks. Some paths carry the victim’s email address in a URL fragment, passing it client-side without sending the fragment to the server. The landing page identifies the victim organization from the email domain and impersonates its login page using screenshots of its actual website and a localized interface. The credential path asks for the password twice and immediately sends it to a Telegram bot along with IP, location, browser, and MX-record information. A separate path uses a fake identity check to induce ScreenConnect installation, providing interactive endpoint access that remains after password resets or MFA. Inference The investigation, detection, and mitigation recommendations are based on publicly described behavior. Their applicability depends on each environment’s collection settings, privileges, and traffic visibility. Hypothesis No additional hypotheses. Unresolved points are listed under Unknowns and Further Investigation. 13. MITRE ATT&CK Mapping T1566.002 Phishing: Spearphishing Link (high confidence): The attacker sends links chaining legitimate Google redirects. T1056.003 Input Capture: Web Portal Capture (high confidence): A dynamically impersonated corporate portal captures credentials. T1219 Remote Access Software (high confidence): ScreenConnect provides persistent remote access. 14. Unknowns and Further Investigation Total victim count, cases of credential abuse, and ScreenConnect installations across the campaign. For each path, whether Google accounts or services were compromised or only public functionality was abused. Operator identity and ultimate monetization. 15. Impact on SOCs and Organizations Organizations should not treat all Google domains as safe. Record redirect chains, URL fragments, and final destinations. To counter impersonation using screenshots of the organization’s own website, direct users to sign in through bookmarks or managed browsers, and block unauthorized RMM software with application control. 16. Audience Summaries SOC: For credential theft, correlate clicks, credential entry, and suspicious authentication. For RMM installation, separately correlate download, execution, and remote connection. Administrators: Do not allow links solely because they use Google domains; resolve the redirect chain and final destination in email gateways or sandboxes. Users: A chain of Google domains followed by screenshots of the organization’s own website can make the link and login page appear legitimate.