Hunting for Long-Dwell Intruders in Cloud and Hybrid Environments

Retrospective: this article looks back at events from November 2018, written in 2026 with the benefit of hindsight.

Marriott's attackers stayed inside Starwood's network for about four years. Long-dwell intruders are quiet by design. Hunting for them means looking for subtle persistence and access patterns rather than loud alerts.

Where long-dwell attackers hide

• Identities: dormant admin accounts, service accounts with old passwords, unfamiliar app registrations or service principals with credentials.
• Email: inbox rules forwarding mail externally, mailbox delegation, OAuth apps with mail access.
• Cloud infrastructure: IAM users and access keys nobody recognizes, roles trusted by external accounts, unusual Lambda functions or automation.
• Endpoints and servers: web shells, scheduled tasks, remote access tools.

Hunting questions

1. Which privileged accounts haven't been used interactively by a known person in 90 days but still authenticate?
2. Which applications have credentials added in the last year, and by whom?
3. Which mailboxes forward to external domains?
4. Which IAM users or roles were created outside your infrastructure-as-code pipeline?
5. Which hosts connect regularly to the same external IP at fixed intervals (beaconing)?

Example: app credentials added recently

AuditLogs
| where OperationName has "Update application – Certificates and secrets management"
   or OperationName has "Add service principal credentials"
| project TimeGenerated, OperationName, InitiatedBy, TargetResources

Example: AWS access keys created outside automation

Query CloudTrail for CreateAccessKey and CreateUser events and compare the creators against your known automation roles.

Make it routine

Run these hunts quarterly and after acquisitions. Record results, even when nothing is found — that becomes your baseline.