Security teams detect Living off Trusted Sites (LOTS) by watching for abuse of reputable cloud and collaboration services to host payloads, redirects or credential collection pages. Look for unusual sharing links, newly created files, anonymous access, strange login prompts and mail or web traffic that reaches trusted domains but ends at suspicious destinations.
How LOTS detection differs from ordinary phishing detection
LOTS is harder to spot because the malicious content sits behind infrastructure that users and security tools already trust. Detection therefore starts with context, not just URLs: compare the destination domain, the hosting service, the sharing pattern and the page behaviour. A reputable platform can still be used as the delivery layer, so the question is whether the activity fits normal business use.
One useful anchor is to separate the trusted service from the suspicious outcome. For example, a file-sharing link may be legitimate, but the page can still redirect users to a credential prompt or a secondary payload hosted elsewhere. That is why analysts should correlate link creation, file creation, access patterns and downstream web requests rather than treating the trusted domain as evidence of safety.
For a broader detection playbook, the Phishing Guide is useful because LOTS often overlaps with credential theft, brand abuse and redirect chains that are common in phishing campaigns.
What telemetry is most valuable for catching LOTS abuse
The most useful signals are those that expose unusual use of otherwise normal cloud and collaboration workflows. Watch for newly created public files, anonymous or externally shared documents, sudden sharing permission changes, strange login prompts from trusted domains, and mail or web traffic that begins on a reputable service but ends on a different destination. Those patterns often indicate a trusted site is being used as a staging point rather than as a legitimate business resource.
Network and identity logs should be read together. A trusted domain in the URL is not enough, because the real signal may be in the sequence: new account, new share, first-time external access, redirect, prompt for credentials, then a request to a separate infrastructure path. If your tooling can enrich events with tenant, file, sender and recipient context, do it, because LOTS campaigns often look benign until those fields are connected.
For SOC teams that want to tune collection and triage around this pattern, the Email Security Buyer’s Guide helps frame how to evaluate mail-layer controls that surface suspicious links and delivery paths, which is often where LOTS activity first appears.
How to investigate and confirm suspicious trusted-site activity
When a trusted service is implicated, confirm whether the activity matches normal user behaviour before you jump to containment. Review who created the content, when it was created, whether it was shared outside expected groups, and whether the page or file has been modified to include redirects, embedded scripts or credential collection forms. The key investigative question is whether the trusted service is merely hosting content or acting as a bridge to something malicious.
Also check whether the activity is part of a wider campaign. Multiple users receiving similar links, repeated use of the same service brand, or a rapid change from benign-looking content to login prompts can indicate coordinated abuse rather than isolated misuse. If you find evidence of credential capture, session theft or follow-on access, treat the event as an identity incident, not just a web-filtering issue.
The Living off the Land Guide is a strong companion here because the detection logic is similar: adversaries are abusing trusted infrastructure, so defenders need to look for abnormal use of normal services.
Risk and Threat Considerations
LOTS is attractive because it reduces the friction that usually exposes malicious infrastructure. A trusted domain can bypass user suspicion, weaken email and web filtering, and blur the line between legitimate sharing and malicious staging. That creates a real risk of missed initial access, especially when the campaign uses a trusted site only long enough to collect credentials or deliver a payload.
Failure mechanism: The attacker abuses a reputable service as a trust wrapper, then pivots the victim to a malicious destination, credential form or payload after the initial trust decision has already been made.
Impact: Security teams may miss the true landing point, lose visibility into the attack chain, and respond too late to prevent credential compromise, malware delivery or broader account abuse.
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, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1566 — Phishing | LOTS often uses trusted services as the lure and delivery path for phishing or credential capture. |
| Recommendation — Map trusted-site abuse to phishing tradecraft and hunt for redirect and credential-collection patterns. | ||
| OWASP API Security Top 10 | API10 — Unsafe Consumption of APIs | LOTS can abuse service integrations and trusted platform interactions to deliver malicious content. |
| Recommendation — Review trusted-service integrations for unsafe downstream consumption and redirect handling. | ||
| CIS Controls v8 | CIS-9 — Email and Web Browser Protections | LOTS is frequently delivered through email and web links that bypass user trust and filtering. |
| Recommendation — Tune email and browser protections to inspect trusted-domain links and suspicious redirects. | ||
| NIST CSF 2.0 | DE.CM-08 — Monitor for unauthorized personnel, connections, devices, and software | LOTS detection depends on monitoring abnormal access paths and suspicious service use. |
| Recommendation — Monitor cloud sharing, redirects, and login events for deviations from normal trusted-service use. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Record Review, Analysis, and Reporting | Investigating LOTS requires correlating sharing, login, and web activity across systems. |
| Recommendation — Correlate audit logs to link trusted-service activity with credential prompts and downstream requests. | ||
Practitioner Guidance
What to verify: Build detections around the whole path, not only the first domain. A trusted host, an unusual share, an anonymous access event and a suspicious redirect are stronger together than any one indicator alone.
Decision rule: If the trusted site is only a delivery layer and the activity terminates in credential collection, treat it as phishing or account compromise work, not as a benign cloud-sharing event.
Practitioner takeaway: The fastest way to miss LOTS is to trust the front door; the right analytic question is whether a reputable service is being used to hide an unsafe destination or action.
Related resources from NHI Mgmt Group
- How should security teams detect living-off-the-land attacks in hybrid environments?
- How should security teams detect living off the land abuse of CertUtil in Windows environments?
- How should security teams detect and block living off the land malware that abuses signed Windows utilities to load payloads?
- How do attackers use living off trusted sites (LOTS)?