The scheduled job that owns your subscription
An Azure Automation runbook runs your code as a managed identity with standing rights in the subscription. Edit it, trigger it, and the attacker is operating as that identity. Here is the path, and how to close it.
The least-watched identity in your subscription is often the one a scheduled job runs as.
What it is
Azure Automation runbooks execute PowerShell or Python as the Automation account’s managed identity (or a legacy Run As account), which frequently holds Contributor or more over a subscription or its resources. An attacker who can edit a runbook or trigger one runs arbitrary code as that identity, then reaches Key Vault, storage, and role assignments, or plants persistence as a scheduled runbook. This is T1059 (command execution) with T1098 (account manipulation) and T1078 (valid accounts).
Why it works
The Automation identity is production-privileged, but runbook edit and run rights are often guarded far less carefully than the production they touch. A scheduled runbook is also durable persistence that survives a password reset.
How to detect it
In the Activity log, look for a runbook created or edited, or a job started, by a principal that does not normally manage Automation, followed by the Automation identity assigning roles, reading Key Vault, or touching resources unusually.
The fix that holds
Least-privilege the Automation managed identity (not subscription Contributor), restrict who can edit and run runbooks, require source control and review for runbook content, and alert on runbook changes and new schedules. Retire legacy Run As accounts.
Practice it
We built an Automation runbook abuse scenario in GraphLattice Range so teams learn to treat the Automation identity as production-privileged and contain it like it.