Microsoft published new research on September 25, 2026 describing Azure resource destruction and credential collection involving compromised service principals. It associates the activity with Storm-3168, its name for the actor also known as JADEPUFFER. Read Microsoft's investigation.
For cloud engineers, the practical question is what an application's identity can do after someone else obtains its credentials. That question belongs in architecture and operations reviews, not only in an incident-response meeting.
My recommendation: use this report to review one important workload end to end, connecting identity permissions, sensitive operations, and recovery responsibilities.
What Microsoft Observed
Microsoft describes two compromised service principals performing discovery, resource destruction, and storage-key retrieval. Some protective controls blocked deletion attempts. Observed Azure activity.
The limits of that evidence matter. Microsoft did not observe a ransom note or confirm successful data exfiltration. It also could not confirm that a previously exposed service-principal secret was the credential used for this activity. Investigation findings and uncertainties.
I would keep those distinctions intact when briefing an engineering team. A report can justify reviewing a control without proving that every possible consequence occurred or that the same activity exists in your tenant.
Review Permissions as an Application Contract
Microsoft's Azure RBAC guidance recommends limiting both the permitted actions and their scope, and avoiding unnecessarily broad roles. It also recommends explicit permissions rather than wildcards in custom roles. Azure RBAC best practices.
My proposed review starts with a simple statement: this identity exists to perform these operations against these resources. Compare that statement with its effective access, including assignments inherited from broader scopes and access obtained through groups.
Then ask what the identity must never do. An application that reads a dataset should not gain unrelated infrastructure-management permissions merely because that made an early deployment easier.
Do not remove permissions blindly from production. Build an evidence-backed change, test the required application paths in a safe environment, and coordinate the rollout with the workload owner. The goal is a smaller permission set that still supports the documented job.
Removing a Leaked Secret Is Not Credential Recovery
Microsoft warns that editing or deleting a public disclosure does not invalidate a credential. Exposed credentials need prompt revocation or rotation and investigation of their use. Credential exposure guidance in the report.
My practical recommendation is to make the response procedure easy to find before it is needed. Record who owns the identity, where the credential is consumed, how replacements are distributed, and which team can coordinate urgent containment.
A rotation exercise should verify both sides: the intended application works with the replacement, and the old credential no longer succeeds. Keep credential values out of tickets, screenshots, and test output.
For a suspected compromise, involve the security-response team rather than treating the event as a routine configuration change. Preserve relevant evidence while containment proceeds under the organization's incident process.
Locks Are One Layer, Not Complete Data Protection
Azure resource locks apply to control-plane operations, not data-plane operations. Microsoft's documentation explicitly notes that a lock on a storage account does not prevent data-plane deletion or modification of the blobs, queues, tables, or files inside it. Resource lock scope and limitations.
That boundary is important when reviewing recovery. I would separately examine who can change infrastructure, who can access or modify data, and who can alter the controls intended to preserve recovery options.
Test those boundaries only in an approved, disposable environment. An intentionally denied action is useful evidence; performing destructive experiments against live customer data is not a valid way to establish the control's behavior.
Also identify who owns each safeguard. A protection setting without an operational owner can become an exception that nobody revisits after a deployment change.
Turn the Review into an Observable Exercise
My suggested exercise uses a known test identity and harmless, preapproved operations. Confirm that defenders can connect the identity, target resource, operation, timestamp, and outcome in the available records.
Have the application owner and security team review the same evidence. They should be able to distinguish expected automation from activity that requires investigation without relying on one person's memory of a deployment.
Write down missing visibility as a finding, not as proof that no suspicious activity occurred. Likewise, a failed operation deserves context: a useful protection, a configuration error, and an attacker mistake are different explanations.
Finally, rehearse the handoff. Who can approve containment, who restores the application, and who verifies that the recovered service is using the intended identity and permissions?
Practical Cloud Engineer Takeaway
My proposed checklist is:
Identify the owner and purpose of each high-impact workload identity.
Compare effective permissions with the operations the application actually needs.
Test credential replacement and failure of the retired credential safely.
Review infrastructure protection separately from data access.
Check who can change recovery safeguards and investigate those changes.
Exercise detection and response with approved test activity.
Record evidence, unresolved gaps, and named owners for follow-up.
These are defensive review recommendations, not a claim that your environment is compromised or that these checks have been performed there.
Who Should Care?
Azure platform engineers, application owners, identity teams, and security responders responsible for automation identities and recovery readiness.
Bottom Line
The useful response to this research is a concrete review of permissions, credentials, visibility, and recovery responsibilities. Keep the confirmed findings separate from assumptions, and turn the lessons into controls your team can demonstrate.
Sources
Stay radical, stay curious, and keep pushing the boundaries of what is possible in the cloud.
Chriz
Beyond Cloud with Chriz
Comments