Attackers use living off trusted sites by hosting lure pages, redirects or payload delivery on reputable cloud and collaboration services that users and filters are more likely to trust. This helps them blend in and resist simple blocking. Defenders should inspect suspicious use of trusted platforms, apply conditional access and watch for abnormal sharing, redirects and file hosting.
How attackers make trusted platforms do the work
LOTS works by borrowing the reputation of a legitimate service. Instead of standing up obviously malicious infrastructure, attackers place lure pages, redirect chains, or hosted files on cloud drives, collaboration tools, code repositories, or document-sharing platforms that defenders and users are less likely to block on sight. That makes the traffic look ordinary until you inspect the exact share, redirect, or download path.
Because the platform itself is trusted, simple reputation filters often see a benign domain, a familiar brand, or a permitted SaaS tenant rather than a known-bad server. The abuse is usually in the content, path, or sharing settings, not in the hosting provider’s core service. This is why trusted-platform abuse often survives generic allowlists and broad domain-based blocking.
Attackers also use trusted services to fragment the kill chain. One service may host the lure, another may handle the redirect, and a third may deliver the payload or capture credentials. That separation makes takedown harder, complicates attribution, and gives defenders less useful signal than a single hostile domain would.
What makes LOTS effective against users and filters
LOTS is effective because it exploits assumptions of legitimacy. Users are more likely to click a link that appears to live on a known platform, and mail or web filters may give more tolerance to reputable services than to freshly registered domains. The result is a higher chance that the lure reaches the target and a lower chance that it is blocked before first contact.
The technique also benefits from the fact that many trusted platforms support easy publishing, sharing, forwarding, and embedding. Those features are legitimate by design, but they can be abused to create short-lived infrastructure that appears and disappears faster than manual review can keep up with. In practice, the attacker is using the service’s normal collaboration or hosting model as camouflage.
For a related view of how attackers abuse trusted delivery paths and lookalike trust cues, NHIMG’s Phishing Guide covers lure construction, redirects, and detection patterns, while the Living off the Land Guide shows the broader tactic of using legitimate services and utilities to blend into normal activity.
How defenders should respond to LOTS abuse
The practical response is to look beyond the reputation of the hosting domain and inspect the actual behavior of the link, file, or redirect chain. Treat unusual sharing permissions, suspicious embed links, anonymous file hosting, and redirects from reputable services as events to investigate, not as automatically safe traffic.
Good controls focus on where the service is being abused: tenant restrictions, conditional access, sharing policy limits, URL rewriting and detonation where appropriate, and alerting on abnormal creation of public links or external shares. If the platform is used for payload delivery, you also want to correlate the hosted object with surrounding authentication, download, and consent activity to see whether the abuse is part of a wider campaign.
Defenders should also preserve evidence quickly, because these artifacts can be deleted or re-shared through a different account with little warning. That makes rapid triage important: capture the URL, the tenant or share context, the redirect chain, and any associated account activity before the trail disappears.
Risk and Threat Considerations
LOTS raises both exposure and trust risk, because the attacker is not relying on a clearly malicious host. The main danger is that a reputable platform becomes the delivery mechanism for phishing, malware, or credential capture, which can bypass simple domain reputation checks and reduce the time defenders have to intervene.
Failure mechanism: Attackers exploit permissive sharing and hosting features on trusted services to hide malicious content inside legitimate-looking links, redirects, or files, then rotate to fresh objects or accounts when detection starts to catch up.
Impact: The result is higher lure success, weaker block-list effectiveness, and greater difficulty in tracing, removing, or attributing the malicious content before users interact with it.
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 CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1566 — Phishing | LOTS commonly delivers phishing lures through trusted hosting and redirect paths. |
| Recommendation — Map trusted-site lure activity to T1566 and hunt for hosted phishing infrastructure. | ||
| CIS Controls v8 | CIS-9 — Email and Web Browser Protections | LOTS abuses web delivery paths that browser and mail defenses should inspect. |
| Recommendation — Harden browser and mail controls to inspect suspicious trusted-platform links and redirects. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions and Authorizations | Abuse of trusted sites often depends on overbroad sharing and access permissions. |
| Recommendation — Restrict external sharing and public access to trusted-hosted content. | ||
| OWASP API Security Top 10 | API10 — Unsafe Consumption of APIs | LOTS can use trusted service APIs and redirects as an unsafe delivery path. |
| Recommendation — Validate externally supplied links and redirect targets before consuming them. | ||
Practitioner Guidance
What to verify: Treat the trust signal as incomplete unless you can confirm the tenant, share scope, and destination are expected. A benign parent domain does not mean the hosted object, link target, or redirect chain is safe.
Decision rule: If a trusted platform is being used for public sharing, anonymous access, or cross-tenant redirects outside normal business use, investigate it as potential LOTS abuse even when the brand looks reputable.
Practitioner takeaway: The defensive mistake is trusting the platform more than the specific object or action. LOTS succeeds when teams validate the brand but not the path, permissions, and sharing behavior behind it.
Related resources from NHI Mgmt Group
- What breaks when defenders rely on EDR alone against attackers who use living off the land or safe mode evasion?
- How should security teams reduce the risk of HTTPS phishing when attackers use trusted certificates to create believable fake sites?
- What breaks when attackers gain administrator access on an endpoint and can use living-off-the-land tools for discovery and lateral movement?
- Living-Off-Trusted-Sites Phishing