Persistence is now an API problem
Long-lived access often comes from tokens, app registrations, and automation—not implants. Your true “agent footprint” is every entity that can act as a human or a system in M365, Workspace, and SaaS.
Attackers no longer need to drop custom malware to maintain leverage in an organization. In a cloud-first world, they can live entirely inside Microsoft 365, Google Workspace, and key SaaS platforms—using OAuth consent, automation, and misdesigned identity to stay resident long after “the incident” is considered closed.
This note is written for security leaders and engineers who want a realistic model of how attackers live off the cloud—and what to do about it.
“Living off the cloud” is the modern counterpart to “living off the land.” Instead of abusing built-in Windows binaries, attackers abuse built-in cloud capabilities: OAuth apps, automation, shared mailboxes, service accounts, and sprawling permissions. The result is persistence and leverage without obviously malicious binaries.
Long-lived access often comes from tokens, app registrations, and automation—not implants. Your true “agent footprint” is every entity that can act as a human or a system in M365, Workspace, and SaaS.
Many impactful intrusions never deploy traditional malware. Investigations that stop at “we saw no malicious binaries” are dangerously incomplete in a cloud-first environment.
Instead of only scanning endpoints, you need a clear picture of which identities, apps, and automations can impersonate users, move data, or reconfigure security controls.
Most relevant stories still begin with something familiar: phishing, password reuse, or token theft. What’s different is what happens after that first foothold, especially in M365 and Workspace.
None of this requires custom tooling. Built-in search, audit trails, and directory views give attackers the reconnaissance they need, while blending into real user behavior.
Once attackers understand who matters and which systems are critical, they shift from “do we have access?” to “how do we keep access if someone changes a password?”
If your incident review ends with “passwords rotated, endpoints scanned, tickets closed,” you are probably leaving cloud-native persistence paths untouched. Remediation must now include identity, automation, and app-layer analysis.
Many organizations don’t have the capacity to rebuild everything at once. The goal is not perfection—it’s eliminating the easiest, most reusable persistence paths.
Create and maintain a list of all entities that can act as a user or system: human identities, service accounts, OAuth apps, automations, and privileged devices. Review who owns them, and what they can touch.
Tighten who can approve new apps and flows. For business-critical automations, document their purpose and owners, and ensure there’s a clear change and review process.
Focus on OAuth, mailbox rule abuse, and unusual admin behavior in M365/Workspace first. Even a small set of solid signals dramatically improves your ability to spot cloud-native persistence.
Simulate an intrusion where no malware is found, but business email and SaaS are compromised. See how leadership and responders react when the usual “reimage the host” playbook doesn’t apply.