Reported September 25, 2026.
Microsoft’s security researchers described cloud activity linked to a threat actor they track as Storm-3168. The activity involved compromised Azure service principals and destructive operations across cloud resources.
The same service principal later made more than 30 successful ListKeys requests against storage accounts, collecting access keys after the destructive activity.
Microsoft said exposed credentials had previously appeared in a public GitHub issue. Editing the issue did not invalidate the secret, which illustrates why exposed credentials must be revoked rather than merely removed from visible text.
Microsoft observed more than 150 destructive or credential-related operations in one sequence. More than 100 storage-account deletion attempts were made, with several succeeding.
One compromised identity spent roughly 15 hours and 30 minutes enumerating virtual machines, subscriptions, resource groups and other resources. A second identity performed rapid discovery before beginning destructive actions.
The attackers also targeted Key Vault, Function App, App Service and recovery-related resources. Attempts were made against Azure SQL databases as well, although those operations failed because of an unsupported API version.
Why the change matters
Cloud permissions also need to be separated by function. An identity used to read a dataset should not automatically be able to delete the storage account containing it. Recovery systems should be protected from the same administrative identity used for ordinary operations.
Discovery is often the quiet part of a cloud intrusion. An attacker can spend hours learning the shape of an environment before making a visible change. That means security monitoring has to treat unusual enumeration as meaningful activity rather than harmless background noise.
The engineering problem
Agentic attacks make this more important because automated systems can perform discovery and action at a speed that is difficult for a human operator to match. The defensive answer is not simply another AI tool. It is strong identity design, segmentation, logging and recovery controls.
The incident is a strong example of why cloud security has moved beyond protecting a login page. Service principals are identities used by applications and automation, and they can have powerful permissions without a human sitting behind each action.
Credential exposure in public repositories remains a simple but persistent cause of compromise. A secret that has appeared in public history should be considered compromised even if the visible file has been corrected.
The destructive phase was much faster than the discovery phase. Once the attacker had enough information, deletion attempts were made at high speed across multiple resource types. This is exactly where independent controls such as resource locks and backup protection become valuable.
Cloud environments make identity a central security boundary. A service principal, workload identity or API token can have more effective power than a human account because it may be allowed to operate continuously and automatically.
Least privilege therefore has to be applied to applications as carefully as it is applied to employees. Roles should be narrow, credentials should expire or rotate, and high-impact operations should require additional controls.
Recovery resources deserve special treatment. Backups that can be deleted by the same identity that deletes production storage are not independent backups in the security sense.
Cloud security also benefits from speed. When a suspicious identity begins enumerating hundreds of resources, automated detection can stop it before a destructive sequence begins.
The practical takeaway
The announcement is important because it changes a real part of the technology stack rather than simply adding another specification. The next few months will show how the technology performs outside controlled demonstrations and how quickly the surrounding ecosystem adapts.
One of the most useful lessons is that recovery controls must be independent. If the same identity can delete production data and its backup locks, the organization has a single point of failure. Separate accounts, separate roles and protected recovery paths make a cloud environment much harder to destroy completely.
The numbers behind the announcement
The headline number is useful, but it needs context. Product specifications and incident counts describe a specific test, deployment or reported event. They should not automatically be treated as universal performance figures. Conditions, availability and implementation details can materially change the result.
For readers following the technology closely, the useful signal is what changes after the announcement. New software will be tested by users, hardware will face real workloads, and security claims will be challenged by real deployments. That follow-through will determine whether today’s announcement becomes a durable technology shift or simply another short-lived product cycle.
Another detail worth watching is the gap between availability and capability. Companies frequently announce a feature before every user can access it, and early versions may be limited by geography, hardware, account type or preview status. That distinction matters because a capability shown in a demonstration is not necessarily a capability that an ordinary customer can use today.
There is also a maintenance cost behind the announcement. Software needs updates, hardware needs replacement and cloud services need monitoring. For enterprise deployments, those costs include security reviews and access management. For consumers, they include battery life, subscriptions and the reliability of updates. The long-term experience is shaped by these ordinary details more than by the launch presentation.
The competitive effect is broader than the company making the announcement. Rivals now have a reference point, suppliers have a new target and customers have another option to compare. That can accelerate development across the category, but it can also create pressure to ship features before the surrounding infrastructure is mature.
The technology is also arriving at a moment when users are becoming more selective about automation. People want systems that save time, but they do not want to lose control of important decisions or data. That makes transparency, confirmation and recovery increasingly important product features rather than secondary settings buried in an advanced menu.
For developers, the announcement creates a more practical question than whether the technology is impressive: where does it fit? The strongest products usually remove an existing bottleneck rather than adding another dashboard. If a feature reduces a repeated task, improves a slow stage in a workflow or makes an expensive resource more efficient, adoption has a clear reason to follow.
The headline feature is only one part of the story. The surrounding infrastructure often determines whether a technology is useful in practice. That includes the software layer, the hardware it runs on, the permissions around it and the systems it has to communicate with. A product can look impressive in a controlled demonstration and still behave very differently once it is exposed to real users and unpredictable inputs.
One practical consideration is verification. Early reports often combine company statements, tests, customer observations and independent analysis. Those pieces answer different questions. A company can establish what it built, while independent users reveal how it behaves under normal conditions. Keeping those distinctions clear makes a technology story more useful than simply repeating the launch claim.
The same distinction applies to numbers. A capacity figure, charging time, funding amount or incident count can be accurate while still being easy to misunderstand without context. Test conditions, timing and definitions matter. Readers should be able to tell whether a number describes a controlled demonstration, a planned capability or an observed production event.
The next few weeks should provide better evidence than the announcement itself. Products will move from preview to broader availability, security teams will publish more technical details, and customers will discover edge cases. Those follow-up signals are often where the real story becomes clear because they show whether the underlying technology survives contact with everyday use.
That makes this development worth watching without treating the launch as the final word. Technology markets move quickly, but the infrastructure around a new product moves more slowly. Adoption, interoperability, reliability and operational cost will decide how much of the announced capability becomes part of normal computing rather than remaining a demonstration.
The bigger picture
The announcement sits inside a wider technology shift in which infrastructure and software are becoming tightly connected. The result will be determined by what happens after launch: adoption, reliability, security and the ability to operate the system at scale.