The cloud break-in is an identity now, not a network hole

Off-the-shelf tooling, nation-state hands, your identity layer

On May 22, Palo Alto's Unit 42 published research on how nation-state actors have operationalized ROADtools, an open-source framework originally built for legitimate cloud security testing, to attack Microsoft Entra ID environments. The actors named are serious (Cloaked Ursa, also known as Midnight Blizzard, among them), and the techniques are the quiet kind: register a rogue device to manipulate an account, use alternate authentication material to move without a password, enumerate accounts to find the next step. Persistence and evasion inside the identity layer, mapped cleanly to MITRE ATT&CK.

The specific target in that research is Entra ID, which is Microsoft's cloud identity service. We will be honest about scope in a moment, because it matters. But the reason we are writing is that the shape of this attack is not a Microsoft story. It is the cloud story, and it is true on AWS, GCP, and Azure just as much.

The perimeter moved to identity, and most defenses did not follow

For years the mental model of a break-in was a network hole: an open port, an exposed service, a firewall misconfiguration. That model is not wrong, and it is still worth closing those holes. But the center of gravity has moved. In the cloud, the thing that grants access is an identity: a role, a service account, a federated principal, an access key, a registered device or credential. If an attacker can become a trusted identity, or attach a new credential to one, they do not need a network hole. They walk in the front door wearing a badge.

Three things make this the dominant pattern now.

Identity is what actually grants access in the cloud

Network controls still matter, but the decision of who can do what is an identity decision. Compromise the identity layer and the network controls are largely beside the point.

The tooling is off the shelf and well mapped

The Unit 42 research is about a legitimate open-source tool turned offensive, with the techniques documented against a public framework. The barrier to running these plays is low and dropping. This is the same trend Anthropic described this week in its own threat research: attackers increasingly use capable tooling for the post-compromise stage, where the work is identity and persistence, not the initial exploit.

Identity attacks are quiet

A new device registration, a fresh credential on an existing principal, a token used from a new context. None of it looks like an alarm by default. It looks like normal cloud activity unless you are specifically watching the identity layer for the anomaly.

How we think about defending the identity layer

The honest scope first: the agents we build, the Solon family, audit access posture on AWS and GCP as the primary, proven clouds, and on Azure on a limited, emerging basis (Solon reads Azure network security groups, topology, and RBAC role assignments). What Solon does not read, on any cloud, is the Entra ID device-registration and authentication internals this specific Unit 42 case turns on. So we are not going to tell you we would have caught this exact Entra attack. We would not have, and saying otherwise is the overclaim we refuse to make. What we will tell you is that the defensive posture is the same primitive on every cloud, and it is the posture we hold cloud environments to.

Least privilege on every identity, checked against real state

The question is not "what does our policy say," it is "what can this principal actually do right now, in the live account." Roles that accumulated permissions over time, service accounts with far more than they use, principals that can escalate to admin: these are the footholds. Auditing the real, current posture, not the intended one, is the work, because drift is constant and the intended posture is a story the documentation tells.

Short-lived federated identity over long-lived keys

A long-lived access key is a credential an attacker can steal once and use indefinitely. Federated, short-lived identity (OIDC and its equivalents) turns a stolen credential into something that expires on its own. This is the same lesson as CI secrets, and it is the highest-leverage change in both places.

Watch the identity layer for the quiet events

New credential or device registration on an existing principal, role assumption from an unfamiliar context, a sudden account-enumeration pattern. These are the tells in the Unit 42 research, and the cross-cloud versions are detectable if you decide to look. The detection is cheap; deciding to look is the part most teams skip.

Know your blast radius before you are tested

If this principal were taken over, what could it reach, and could it grant itself more. Answering that for your real environment, ahead of time, is worth more than any single control, because it tells you where to spend.

The thread: treat identity as the perimeter, because the attackers already do.

What we are not claiming

We are not claiming we cover the Entra ID internals this case turns on (device registration, alternate authentication material). Solon audits AWS and GCP (primary) and Azure on a limited basis, but the Entra device-registration layer is beyond what it reads. We cite the case as a cross-cloud lesson, not as something we would have caught.

We are not claiming identity attacks are new. They are not. The news is operationalization: legitimate tooling turned offensive, documented and mapped, lowering the bar to run these plays.

We are not claiming a product fixes it. Least-privilege identity, short-lived credentials, and identity-layer detection are configuration and discipline. There are useful tools, including the ones we build, but the core is posture, not a purchase.

And about ourselves: we audit our own fleet's identity posture the same way we would audit yours, and where we find a long-lived key or an over-broad role, we are migrating it. The work is ongoing, not finished, on our side too.

One-sentence takeaway

In the cloud the perimeter is identity, attackers are operationalizing off-the-shelf tooling to live inside the identity layer, and the defense is the same on every cloud: least privilege checked against real state, short-lived federated identity instead of long-lived keys, and actually watching for the quiet identity events that signal a foothold.