Expert Briefing: Cloud Attack Paths and Control-Plane Risk

Briefing overview

Most cloud intrusions that reach the news do not begin with a clever exploit against a workload. They begin with an identity. They end with someone using the management plane the way an administrator would: creating compute, registering authenticators, granting application permissions, reading mail and storage.

This briefing follows that path one step at a time. It shows where a single control change would have broken the chain, and where a pile of individually minor findings quietly adds up to a route to administrator.

What you will take away

• A way to describe cloud risk as an attack path, meaning a chain of permissions and trust, instead of a list of findings.

• Three public cases, each mapped to the control-plane step that made it work.

• Six questions to take back to your own accounts and tenants.

• A fix order based on how many paths each change removes.

Agenda

The path is the unit of risk

A finding such as “MFA is not enforced on one account” or “an application holds broad permissions” looks minor on its own. Attackers chain them. The useful question is not how many findings you have. It is how short the shortest route is from a weak entry point to a position that can change identity, trust or data access.

By control plane we mean the identity provider, the management APIs and consoles, and the permission and trust objects they control. Whoever can write to these can reshape the environment. Many of the actions also look like ordinary administration in the logs, which is why they go unnoticed.

Three public cases

These are reported cases, summarized from the sources listed at the end. Nothing beyond what those sources state is assumed here.

Six questions to take back

1. Which identities can create or change roles, policies, application registrations, federation settings and keys? How many of them are non-human?

2. Which non-production, legacy or “temporary” tenants, accounts and applications still hold permissions into production?

3. Can your help desk reset a credential or move an MFA method on a phone call alone? What verification stands in the way?

4. Where do control-plane logs go, who can delete them, and is the logging tier you pay for the one you would need in an investigation?

5. What alerts fire when a new application, credential, federation trust or compute instance is created outside a change window?

6. When did you last test an attack path from start to finish, instead of testing one control at a time?

What should change

The order below follows how many paths each change removes. It is practice-based analysis, not a requirement drawn from the cited sources, apart from phishing-resistant MFA, which the Scattered Spider advisory recommends.

1. Cut standing write access to identity and trust objects. Replace it with time-bound elevation and approval. Count the identities that hold it, and watch that number.

2. Remove production reach from legacy and non-production identities. Review application-level permissions in particular, since they work without a signed-in user. Retire registrations nobody owns.

3. Move privileged and recoverable accounts to phishing-resistant MFA, and rebuild account recovery. A strong authenticator protects little if a phone call can replace it.

4. Send control-plane logs to a store outside the account or tenant they describe. Confirm retention. Alert on new credentials, applications, federation trusts and compute.

5. Test paths, not findings. Run exercises that chain weak points, and track how long the shortest path is over time.

Each step has a cost. Elevation workflows slow engineers down, and removing legacy access breaks things nobody documented. Work through the shortest paths first and stage the rest.

Next step

Apply the six questions to your own environment. Start with the identities that can change trust, because every other path runs through them.

Sources

Scattered Spider (joint cybersecurity advisory) — CISA and partner agencies

Midnight Blizzard attack on Microsoft corporate environment: analysis, detections and recommendations — Wiz. Summarizes Microsoft’s disclosure; the analysts’ own inferences are not treated as Microsoft findings

CSRB lashes Microsoft’s cascade of security failures — Lawfare. Coverage of the Cyber Safety Review Board review of the Storm-0558 intrusion