.png)
Last week, Microsoft Security Research published its analysis of Storm-3168, where attackers used two compromised service principals to spend hours mapping an Azure environment. They then moved into a destructive sequence that included more than 100 storage account deletion attempts in about seven minutes. The Azure activity is linked to JADEPUFFER, the threat actor behind what Sysdig described earlier this year as the first documented agentic ransomware operation.
The speed was striking, but the conditions behind the attack were familiar. No zero-day sat at the center of the incident. The attackers benefited from an exposed secret. They moved on the path of an overprivileged identity with a credential that remained valid after its exposure was removed. And, the identity's behavior strayed from the workload's normal job.
These are common weaknesses in how organizations manage non-human identities (NHIs). Today, those weaknesses persist in some of the largest and most innovative organizations. I know because every week I see the looks of surprise and concern when identity leaders and CISOs hear they have dozens of 30-year-old privileged credentials that Cyera Identity uncovered and remediated.
Let’s break down what went wrong in this attack step by step.
1. The secret leaked
A client ID, client secret, and tenant ID associated with a production service principal had been pasted in plaintext into a public GitHub issue by an employee. Microsoft could not confirm that this was how the attacker gained access, but the incident reflects a problem security teams see every day: secrets find their way into issues, tickets, config files, chat threads, and other places they were never meant to live.
Telling people to be more careful will not solve this. Long-lived credentials inevitably pass through systems and workflows where people can copy, share, or expose them.
The more important question is whether you know that credential exists, who owns it, which identity it belongs to, and what that identity can reach. A service principal with access to production storage, SQL, and Key Vault should not look like just another secret in an inventory. Its blast radius should be clear from the start and should raise a flag and prompt remediation before something goes wrong.
2. The company removed the exposure but never rotated the secret.
The GitHub issue was eventually edited to remove the secret, but the value remained visible in the issue's public edit history. More importantly, editing the issue did nothing to invalidate the credential.
Removing a credential from the place where it was exposed does not remove its access. Copies may already exist in histories, caches, logs, archives, or an attacker's hands. Microsoft recommends treating publicly exposed credentials as compromised and revoking or rotating them promptly.
This is where remediation often gets difficult. Rotating a credential sounds simple until nobody can confidently answer what depends on it. When ownership and dependencies are mapped ahead of time, rotation becomes a routine lifecycle action instead of an emergency change with an unknown blast radius.
When a credential is exposed, the response should invalidate it, not simply erase the evidence of the exposure.
3. The identity had more access than it needed
Every destructive action Microsoft observed used permissions the compromised identity already had.
A group-granted Storage Account Contributor role authorized the storage deletions. Direct Contributor access enabled deletion of a Key Vault, Function App, and App Service plan, along with key retrieval. SQL DB Contributor access allowed database deletion attempts as well. Those attempts failed because the attacker used an unsupported API version, not because the identity lacked permission.
That is what compromise means for a non-human identity: the attacker inherits the identity's legitimate access.
A one-time least privilege review is not enough. Teams need to compare granted access with actual use and continually remove standing permissions that no longer serve the workload. Inherited group permissions make that especially important because excessive access is not always obvious from the identity itself.
4. The behavior changed dramatically
One compromised service principal performed more than 300 successful read operations over roughly 15 hours, enumerating virtual machines, subscriptions, resource groups, and other resources. A second enumerated two subscriptions in five seconds, probed configuration stores, and moved from a failed ListKeys request into destructive activity less than a second later.
Microsoft also observed five unique tokens associated with the destructive service principal, including overlapping token activity that supported parallel deletion. Roughly 30 minutes after the destructive activity ended, the same identity successfully requested access keys for more than 30 storage accounts.
Whatever that workload was supposed to do, this was not it.
Knowing an identity exists is only the starting point. Teams also need a baseline for normal use and a way to respond when behavior no longer matches the identity's purpose. If a service principal is compromised, revoking the identity and rotating its credential should close the paths the attacker is using instead of forcing teams to chase individual actions.
Microsoft recommends Defender protections to help detect this kind of activity, but that is only one part of its guidance. Microsoft also calls for rotating exposed credentials, applying least privilege, and strengthening lifecycle management for workload identities. Detection can tell a team that something is wrong. Acting safely still depends on knowing who owns the identity, what relies on it, and what access the workload actually needs.
The same identity problem moving at machine speed
Storm-3168 shows why detecting machine-speed attacks is not enough. Organizations also need the identity context and lifecycle controls to act on what they detect.
Reconnaissance, destructive activity, and credential collection were distributed across compromised service principals and overlapping token streams. Microsoft says the timing and coordination strongly indicate automated or scripted execution. The destructive sequence lasted about seven minutes.
Some independent safeguards still worked. Azure resource locks and storage account deletion protection blocked attempts against several resources even though the compromised identity held broad permissions. Controls that do not depend on trusting the identity can limit the damage when that identity is compromised.
The incident also shows why non-human identities cannot be treated as infrastructure plumbing. Teams need to know they exist, who owns them, what they are for, which credentials they use, what they can reach, and whether that access still makes sense. When something changes, teams need a way to act without spending hours reconstructing dependencies first.
Explore Cyera Identity
Storm-3168 did not call for better redaction. It called for control over the identity behind the secret, from initial discovery through remediation.
Cyera Identity helps organizations reduce the attack surface created by service accounts, service principals, credentials, and other NHIs that applications and AI agents rely on. It does this by continuously discovering NHIs across the enterprise, connecting credentials to the identities behind them, and mapping each identity to its owner, consumers, dependencies, effective permissions, actual usage, and the data and resources it can reach. This makes it easier to find exposed credentials, excessive access, unknown owners, and other risks before they become an incident.
Cyera Identity then turns that context into action. Teams can right-size permissions based on actual use, rotate exposed credentials with a clear understanding of what depends on them, revoke compromised access, and decommission identities that are no longer needed. By combining identity context with Cyera’s data intelligence, organizations can prioritize remediation based on what is truly at risk and act without spending critical time reconstructing the identity’s blast radius.
Get your AI Security Assessment
.svg)