Update Manager as a weapon: one config edit, code on the whole fleet

Azure Update Manager exists to push updates across a whole VM fleet on a schedule, which makes it a single point that can run code everywhere at once. That is also what makes it a Tier-0 target.

How the attack works

An attacker with the RBAC to manage Update Manager edits a maintenance configuration and adds a pre-script step that pulls attacker code from an external source. The configuration is assigned to a dynamic scope covering the production fleet, so the change applies fleet-wide. When the maintenance window opens, Update Manager begins running the pre-script across in-scope VMs, and guest deployment logs show it executing on hundreds of machines nearly simultaneously. In ATT&CK terms this is T1072, Software Deployment Tools, with T1195, Supply Chain Compromise, and T1059, Command and Scripting Interpreter.

Why it works

Update Manager RBAC was broad, and maintenance configs could include arbitrary scripts with fleet-wide scope. A fleet-deployment surface with broad write rights turns one out-of-band config edit into staged code execution everywhere.

How to fix it

You cannot isolate hundreds of VMs faster than a simultaneous fan-out, and reboots do not stop a scheduled run. The decisive move is to stop the deployment at the chokepoint: pause or cancel the scheduled run and remove the malicious config and assignment before the window opens, then scope the RBAC that allowed the edit. Treat Update Manager as Tier-0 with change approval and alerting on every config write and deployment run. Scope what executed from deployment run history plus per-VM guest extension logs, since targeted is not the same as executed.

Practice it

We built this as a GraphLattice Range scenario so responders can rehearse the fleet-wide threat, the cancel-at-the-chokepoint containment, and the Tier-0 governance fix.