On September 4, 2026, the KnowBe4 Threat Lab detailed an active phishing campaign that sends victims through several Google services before redirecting them to a credential harvester or to remote-access software installation. The first visible domain can therefore look familiar even though the final destination is controlled by the attacker.
The issue is bigger than clicking the wrong domain: the chain is designed to mislead filters, personalise the page with the targeted organisation, and choose between secret theft and persistent access to the machine.
What the campaign shows
KnowBe4 describes a campaign using several Google properties as relays, including Google Meet, Search, Custom Search, Google Images, Tag Manager, and Analytics. According to the published analysis, the services are used separately or in sequence so that successive controls encounter reputable domains before the browser leaves for attacker infrastructure.
Dark Reading reports the same multi-step redirect mechanism. The reputation of the first domain is therefore not enough to classify the link. The campaign is not evidence that every Google redirect is malicious; it shows that domain trust must be combined with behavioural inspection.
Why filters can be bypassed
In the documented scenario, the final address appears only after several redirect parameters. The fragment after # is especially relevant: browsers normally do not send it to the server, but page JavaScript can read it. KnowBe4 says the victim’s address is encoded there, hiding the targeting from logs and some URL scanners.
The final page can then check the mail domain, display the organisation’s logo and a screenshot of its website, and adapt its content. A control that checks only the message domain, the first link, or one hop can therefore incorrectly conclude that the journey is clean.
Two possible outcomes after the redirect
The first path leads to a fake Microsoft or OneDrive sign-in page intended to collect credentials; some variants also try to intercept a device-pairing code. The interface may show an error after the first submission and ask for a second entry. A password or MFA code entered on that page remains stolen data even if the user sees no further warning.
The second path installs ScreenConnect under the cover of an identity check. KnowBe4 describes ScreenConnect as legitimate RMM software abused in this context; an established remote session on the endpoint does not necessarily disappear when a password is changed. Detecting execution and outbound connections is therefore as important as rotating secrets.
Practical steps for users
Do not approve a link because it starts with google.com or another known domain. Open the expected site from a bookmark or a manually entered address, especially for account expiry, invoices, shared documents, or an “identity verification” request.
After clicking, stop before entering anything. Report the message, record the time, and notify IT. If you entered a password, change it from a clean device everywhere it was reused; if a code or session may have been exposed, revoke sessions and tokens at the service. Do not download or run a tool requested by an unexpected page.
Controls organisations should add
Teams should analyse redirects through to the final destination, log suspicious parameters, and monitor unusual paths in DNS, the proxy, and the SIEM. URL fragments containing an address or identifier can be a useful signal, but are not proof by themselves.
The RMM inventory should distinguish approved ScreenConnect or equivalent deployments from portable, temporary, or procedure-less executions. CISA recommends controlling remote-access tools, their accounts, logs, and network flows. MFA should also be enabled first for email, remote access, and privileged accounts; a security key or other phishing-resistant MFA reduces the impact of a stolen password.
How Soclyde fits
Soclyde does not block a malicious redirect and does not replace email filtering or endpoint monitoring. Its role is narrower: help generate a unique secret for each service, keep it in a local-first encrypted vault, and make rotation practical when a user has entered a password on a suspicious page.
This separation limits reuse across accounts. It does not protect a compromised device or revoke a remote session: after a suspicious click, endpoint, session, and RMM controls remain the priority.
Key takeaways
The campaign described in September 2026 shows that a link can pass through several legitimate services before reaching a fake form or remote-access tool. The starting domain is only one signal; the complete chain, final destination, and endpoint behaviour must be checked.
Users should avoid entering information on unexpected pages and then revoke potentially exposed access. Organisations should prioritise DNS and proxy visibility, phishing-resistant MFA, and an inventory of RMM software. To reduce secret reuse, read the secure password generator guide or contact Soclyde.
