PENTESTY · EDITORIAL ANALYSIS · · 4 min read
JadePuffer in Azure: who can delete what recovery depends on?
A copy helps only when the business can preserve and use it. Connect the power to delete resources with the access required to recover a service.
By Pentesty
What the published investigation confirms
On September 25, 2026, Microsoft described Azure activity associated with JadePuffer, tracked as Storm-3168, using two compromised service principals. The investigation observed resource deletion and credential collection; some controls blocked deletions. Initial compromise remained uncertain. The account did not confirm successful exfiltration or a ransom note. The analysis below proposes authorization tests without reconstructing the victim’s environment.
Inventory the power to delete
Choose one application and connect its identities with the resources used. For each deletion permission, record its purpose, owner and assignment path. Include groups and inherited scopes: an application account’s name alone does not establish its effective reach.
Compare that reach with the business task. Does an automation publishing a release need to delete the project’s entire storage? Who can approve permanent cleanup? Distinguish expected maintenance from a capability retained merely for convenience or through an exception that nobody reviewed.
Treat recovery as its own trust relationship
Map who administers copies, changes their protection and restores them. Compare those functions with the identities operating the application. If one access path reaches both operation and recovery, document that reach and the required control decision instead of assuming independence because resources have different names.
Define what each protection intends to prevent. Assess a resource lock against the specific operation it covers; alone, it does not demonstrate protection of all content or dependencies. Retain the applied configuration, the people allowed to change it and a way to verify its effect.
Demonstrate rejection before discussing restoration
Use an isolated environment, disposable resources and synthetic data. Agree one legitimate operation that should succeed and a deletion the test identity should not perform. Record the hypothesis and boundaries beforehand, without deleting real data or removing production protection to demonstrate risk.
Compare declared authorization with the observed response and resource state. A rejected operation and one failing because of an API-version error do not demonstrate the same control. If a result is inconclusive, preserve that limitation and identify the next check instead of counting the failure as protection success.
- Identify the identity, scope and source of permission.
- Record the permitted action and deletion that must be denied.
- Keep the response, timestamp and final state without secrets.
- Define who accepts the result and ends exercise access.
Check whether the copy restores the function
Then assess an authorized restoration using synthetic material. Select a small application function and confirm the data, configuration and access needed to run it. A completed-backup announcement alone does not establish that another team can obtain the copy and operate the restored service.
The cloud-zone loss analysis helps test dependencies and operational acceptance. Add a question here: does the recovery path remain available when the application identity is revoked? Record the observed answer and any dependencies still shared.
Connect credential lifecycle with closure
Connect each credential with integrations requiring a change when its use ends. The GitHub Actions secrets review complements that inventory. Content removal and revocation are different actions; the handover should establish which occurred and how its effect was verified.
Close with owners responsible for correcting permissions, reviewing protection and accepting recovery. Repeat the scenario after relevant changes and preserve the test conditions. The useful outcome is a decision about observed reach, without extending a sample to every resource in the subscription.
Frequently asked questions
Did Microsoft confirm the public credential as initial access?
The report notes earlier exposure but does not confirm that the secret was used in the described activity. Preserve that uncertainty when explaining the case.
Does a failed deletion prove protection worked?
Check the cause and final state. An authorization denial and a failure caused by an incompatible request are different evidence supporting different conclusions.
Does having a backup demonstrate recoverability?
Test restoration of the selected function with synthetic data and authorized access. Record dependencies, permissions, limitations and the person accepting the observed result.
Where should the accountable team begin?
Choose one application and connect identities, resources and deletion permissions. Define the legitimate operation, expected denial and the people responsible for recovery.
Sources and references
- Microsoft: Storm-3168 investigation, September 25, 2026
- Microsoft Learn: storage account resource locks
- Microsoft Learn: Azure Backup data-protection practices
- Cyber Security Brazil: editorial news reference
Original Pentesty analysis, published October 16, 2026. The proposed scenarios are editorial guidance, with scope and validation to be defined for each environment.