A broad phishing campaign is abusing legitimate Google services as stepping stones to credential-harvesting pages and, in some cases, malicious remote-access installations. By placing trusted domains at the beginning and middle of the link chain, operators make deceptive messages harder for recipients and reputation-based security controls to recognize.

Researchers at KnowBe4 Threat Lab observed lures aimed at manufacturing, government, financial and nonprofit organizations. The emails impersonate common business workflows, including document reviews, mailbox expiration warnings, delivery updates, payment notices, voicemail alerts and government benefits.

Trusted infrastructure becomes a redirect layer

Instead of linking directly to an obviously suspicious host, the messages route users through combinations of Google Meet, Search, DoubleClick, Custom Search, Image Search, Tag Manager and Analytics. Some paths cross several Google-owned endpoints before reaching infrastructure controlled by the attackers.

A security product that assigns trust mainly from the first domain may treat the URL as benign. Users may make the same assumption after recognizing Google in the address. Yet a legitimate intermediate service says nothing about the safety of the final destination or the action requested there.

The operators also place the recipient’s email address after the hash symbol in a URL, sometimes encoding it with base64. Browsers use this fragment locally and generally do not include it in requests to web servers. That behavior lets the destination personalize its page while keeping the target identifier out of much of the server-side redirect trail and some automated scans.

Personalization makes fake sign-ins convincing

Before showing a credential form, the phishing kit evaluates the visitor. It can collect browser and location details, check whether the email domain has valid mail records, and display imitation human-verification challenges. These filters help exclude analysis systems and reserve the finished page for likely victims.

The final login screen can retrieve the target organization’s logo, place a current image of its website in the background, prefill the user’s address and adapt text to the browser language. These touches turn a generic credential trap into something that resembles an internal corporate sign-in page.

Submitted credentials are sent to a Telegram bot with technical information about the victim. The page then deliberately rejects the password and requests another entry. That tactic may capture a second password if a person assumes the first attempt was mistyped, after which the browser is redirected to the real company site to reduce suspicion.

ScreenConnect creates a more persistent risk

One branch replaces the login theft with a false identity-verification flow that installs ScreenConnect. The software is a legitimate remote-management product, but an unauthorized deployment can give an intruder durable interactive access to the workstation. This expands the danger from one stolen account to hands-on control that can support discovery, data theft and movement into other systems.

Defenders should therefore investigate both identity and endpoint signals when a user interacts with a lure. Resetting a password will not remove remote-control software, while deleting the software will not invalidate credentials already transmitted to the attacker.

How organizations can disrupt the chain

• Inspect the complete redirect path and final destination rather than trusting the first recognizable domain.
• Reset exposed credentials, revoke active sessions and review cloud sign-in activity.
• Search endpoints for unauthorized ScreenConnect installation or execution.
• Monitor for unexpected Telegram Bot API traffic and suspicious browser-to-remote-tool sequences.
• Block confirmed indicators at DNS and proxy layers and report abusive links to Google Safe Browsing.

Security awareness guidance should emphasize intent and context: an unexpected sign-in, download or verification request deserves scrutiny even when the link begins on a famous platform. Email and web controls also need to follow redirects safely, analyze fragment-based personalization, and correlate endpoint events with identity telemetry.

The campaign demonstrates how attackers increasingly borrow the credibility and availability of mainstream cloud services. Defenses based on simple allowlists cannot account for that reality. Trust should attach to the full transaction—sender, route, final site and requested behavior—not to a familiar domain viewed in isolation.

Incident-response playbooks should capture the original email and complete browsing chain. Those artifacts help defenders identify other recipients, find related redirect patterns and distinguish an isolated password reset from a workstation compromise requiring containment.