What are the signs that a phishing campaign is using a trusted platform as a first hop?

Common signs include a benign-looking email with a trusted link, a second click hidden behind a file or page on SharePoint, Google Sites, or a similar service, and a final redirect to a credential-harvesting page. Security teams should watch for unusual redirect chains, short-lived hosting pages, and user journeys that shift off email into web content.

How a trusted first hop shows up in the delivery chain

When a phishing campaign uses SharePoint, Google Sites, or a similar trusted platform as the first hop, the email often looks ordinary at a glance because the visible link points to a legitimate domain. The real tell is that the trusted page is only a staging point. It exists to route the user through additional clicks, conditional redirects, or embedded content before the final credential theft page appears.

That staging pattern matters because it changes where defenders have to look: the initial message may pass simple domain reputation checks, while the malicious behavior is deferred into the browser journey. In practice, the campaign is trying to borrow trust from a well-known service long enough to defeat user suspicion and some email-layer controls.

What the redirect chain reveals to defenders

The clearest indicators are in the path, not just the inbox artifact. Security teams should look for unusual redirect chains, short-lived landing pages, and rapid transitions from email to hosted web content. A benign first page that exists only to trigger a second click, load external content, or present a login prompt is often a sign that the operator is trying to separate the lure from the credential-harvesting step.

That separation is also why URL inspection alone can be misleading. A trusted platform may host a harmless-looking file, form, or page while the actual payload is delivered later through JavaScript, embedded links, or a chained redirect. The more the user journey departs from a single destination and starts behaving like a relay, the more likely the campaign is hiding its real objective.

Why trusted platforms make the campaign harder to spot

Attackers use trusted platforms because they are already allowed in many environments and their domains are less likely to be blocked than newly registered infrastructure. That makes the campaign look more legitimate to users and can delay automated detection. It also lets the attacker rotate pages quickly, retire them after delivery, and rehost the same lure with minimal effort.

The practical consequence is that defenders need to treat trust as conditional, not absolute. A platform being trusted for normal collaboration does not mean every page, document, or redirect path on it is safe. The important question is whether the content behaves like a transient delivery step in a phishing workflow rather than a normal business use case.

Risk and Threat Considerations

Trusted-platform first hops increase the chance that phishing will slip past initial filtering and user skepticism, especially when the malicious step is delayed until after the first click. The risk is not just a single bad link, but a chain that hides the true destination until the user has already accepted the first trust decision.

Failure mechanism: The attacker leverages a legitimate service to host a benign-looking intermediate page, then uses redirects, hidden second clicks, or embedded content to move the victim to a credential-harvesting page.

Impact: Security teams may miss the campaign until users start submitting credentials, and the platform’s legitimacy can slow incident triage because the first hop appears normal even though the overall journey is malicious.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK and OWASP API Security Top 10 address the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
MITRE ATT&CK	T1187 — Forced Authentication	Phishing chains often end in credential capture via lured logins.
	T1204 — User Execution	The campaign depends on a user clicking through staged web content.
Recommendation — Map the redirect chain to credential-access activity and hunt for follow-on authentication abuse. Trace user-execution steps across the full click path and flag unexpected browser transitions.
NIST CSF 2.0	DE.CM-01 — Networks and system monitoring	Redirect chains and short-lived landing pages are monitorable anomalous behaviors.
	PR.AA-05 — Identity management and access control is enforced for authorized users and systems	Phishing aims to bypass normal authentication trust boundaries and steal credentials.
Recommendation — Monitor browser and web traffic for unusual redirect patterns and transient hosting behavior. Enforce phishing-resistant authentication to reduce the value of harvested credentials.
OWASP API Security Top 10	API2 — Broken Authentication	Credential-harvesting pages exploit authentication flow weaknesses.
Recommendation — Validate authentication flows for phishing resistance and reject lookalike sign-in paths.

Practitioner Guidance

What to verify: Review the full click path, not only the final URL. If the first hop is on a trusted platform, validate whether the page contains an unnecessary redirect, a file whose only purpose is to lead to another site, or a login prompt that is out of character for the service.

What to prioritise: Focus detections on link chains, page age, hosting churn, and suspicious transitions from sanctioned collaboration domains to external credential pages. The strongest signal is often a mismatch between a legitimate first hop and an obviously credential-seeking final destination.

Practitioner takeaway: Treat trusted-platform staging pages as part of the attack, not as proof of legitimacy; the campaign’s intent is usually exposed by the sequence of hops, not by the first domain alone.