Microsoft Security Research has identified malicious cloud activity associated with JADEPUFFER, a threat actor discovered by Sysdig in July 2026 and reported to be the first documented agentic ransomware operation. Our investigation found an extensive Azure-focused resource destruction activity using compromised service principals and cloud credential collection that could be used to facilitate future exfiltration.

These findings expand the publicly documented activity associated with JADEPUFFER, tracked by Microsoft as Storm-3168, demonstrating an evolution in the threat actor’s cloud operations and providing the first detailed view into its Azure activity. We identified bulk destructive operations in a compromised Azure environment. The destructive operations were facilitated by compromising service principals and targeted Azure Storage Accounts, SQL databases, Key Vaults, Function Apps, recovery protection locks, Virtual Machines, and App Services.

Organizations can reduce exposure by protecting workload identities and secrets, enforcing least privilege, safeguarding recovery resources, and enabling relevant Microsoft Defender for Cloud protections. Publicly exposed credentials remain usable until revoked or rotated; removing the original disclosure alone does not remediate the exposure.

This activity highlights a broader shift toward AI-orchestrated attacks, where threat actors can coordinate complex post-compromise operations across cloud environments with greater speed and scale. As these capabilities evolve, defenders must similarly use AI to investigate and respond across large environments. Rather than requiring analysts to manually follow each individual action, efforts such as Project Perception and MDASH are intended to support a model in which defenders can investigate and respond across increasingly large and complex environments using AI.

Attack overview

Microsoft observed two compromised service principals belonging to the same tenant. One performed reconnaissance and resource discovery. The other performed discovery, destructive operations, and credential collection.

Discovery before destruction

For the impacted tenant, in early June 2026, one of the compromised service principals enumerated Azure Virtual Machines, subscriptions, resource groups and resources for about 15 hours and 30 minutes with 300+ successful read operations. This breadth of activity would give the threat actor visibility across the organization’s Azure environment.

About 90 minutes after the first compromised service principal started enumeration, the second compromised service principal enumerated virtual machines and resource groups across two subscriptions in five seconds. Both service principals used Storm-3168 linked infrastructure, the same network fingerprint, and the user agent python-requests/2.34.2.

16 hours later, the second service principal successfully enumerated Azure App Service configuration stores, possibly looking for exposed credentials. It also unsuccessfully attempted to look for Azure OpenSearch resources.

70 seconds after this final inventory operation, the same service principal also attempted a ListKey operation against a non-existent storage account.

A seven-minute destructive sequence

Less than one second after the unsuccessful ListKey operation against a non-existent storage account, the second compromised service principal began with its destructive activities. This compromised service principal then attempted 150+ destructive or credential collection related operations in 35 minutes.

The destructive sequence lasted for about 7 minutes. This involved 100+ storage account deletion attempts. Most Azure Storage accounts targeted by the threat actor were successfully deleted. However, Azure resource locks and storage account-level deletion protection blocked deletion attempts for few of the storage accounts, demonstrating the value of independent safeguards that remain effective even when a compromised identity has broad administrative permissions. An Azure Key Vault, Function App, App service plan were also deleted, all of which belonged to the same resource group and appeared to support the Function app.

The same service principal also attempted to delete multiple Azure SQL databases in parallel with the storage account deletions mentioned earlier, but every deletion attempt failed because it used an unsupported API version for the Azure SQL database resource type.

Multiple unsuccessful deletion attempts were also made against Azure Site Recovery locks and Azure Backup protection locks protecting storage accounts.

Credential collection

About 30 minutes after the final destructive activity, the same service principal made an inventory request for Azure Storage Accounts and sent 30+ successful ListKeys requests, asking ARM to return each storage account’s access keys. These storage accounts included Azure Site Recovery related storage accounts.

Technical analysis

Possible initial access

• Credential exposure: While it is unclear how the service principal was initially compromised, its client ID, client secret, and tenant ID had previously been exposed in plaintext in a public GitHub issue by an employee of the impacted organization. The issue was later edited to remove the secret, but the secret remained accessible through the issue’s public edit history. Removing or redacting an exposed secret does not invalidate it; credentials exposed in any public internet location should be treated as compromised and promptly revoked or rotated. We could not confirm whether this secret was used for the activity described here.
• Application Probing: Since the beginning of this year, we also observed repeated probing from Storm-3168 linked infrastructure against multiple Azure App services for different customers, against sensitive paths related to WordPress administration, PHP-CGI, LangFlow’s code validation endpoint (/api/v1/validate/code) and other web-shell like paths. However, the App Service targets did not overlap with the affected Azure subscriptions, and we found no App Service to ARM (Azure Resource Manager) credential path for the impacted tenant.

Coordinated automation

The timing between the different operations and the division of work using multiple service principals and overlapping token streams from the same service principal strongly indicates automated or scripted execution.

We observed five unique tokens issued for the service principal used for destruction and credential collection – four tokens supported deletion, while the fifth token handled storage inventory and key retrieval. Two of the tokens used for deletion were active during the same 70 second period. While one of these tokens focused on Storage account deletion, the other focused on a mixture of Storage and SQL deletion.

While the Key Vault, Function App, and App Service plan associated with the same application were deleted, a similarly named storage account in the same resource group was spared and later targeted by the compromised service principal through a successful ListKeys operation.

The operations followed the identity’s existing Azure role assignments. A group-granted Storage Account Contributor role authorized the destructive storage operations. Direct Contributor access authorized the three application-resource deletions and the one additional successful key retrieval. Direct SQL DB Contributor access authorized the multiple SQL deletion attempts, which were ultimately unsuccessful because of the unsupported API version used for the Azure SQL Database resource type.

Destructive activity indicative of a ransomware-aligned objective

The threat actor deleted numerous Azure resources, while also targeting backup and recovery related resources such as Azure Site Recovery locks or Azure Storage Accounts which had terraform and backup themed names, potentially intending to impair the victim’s ability to recover from the destructive activity.

The parallel targeting of Azure SQL databases and storage accounts suggests an effort to broaden the destructive impact across different data services rather than concentrating on a single resource type. Although the database deletions were unsuccessful, their inclusion in the same destructive sequence provides additional insight into the intended scope of the activity.

The compromised service principal also made multiple attempts to retrieve storage account keys, which could provide access to sensitive data.

Taken together, the resource destruction, attempts to interfere with recovery mechanisms, and collection of credentials that could provide access to data are consistent with tactics that can support ransomware and extortion operations.

However, we did not observe a ransom note or confirm successful data exfiltration in the activity described here.

Mitigation and protection guidance

Microsoft recommends the following mitigations to reduce the risk and impact of activity similar to that observed in this campaign:

• Enable appropriate Microsoft Defender for Cloud plans for critical Azure workloads. Consider enabling workload protections relevant to the resources in your environment, including Defender for Resource Manager, Defender for Storage, Defender for Key Vault, Defender for App Service and Defender for Databases. Learn more in the Microsoft Defender for Cloud overview.
• Protect and continuously assess application credentials and secrets. Avoid storing service principal credentials, storage keys, connection strings, and other secrets in source code, configuration files, public repositories, issues, or other locations where they might be inadvertently exposed. Learn more in the Microsoft Entra Workload ID documentation.
• Rotate compromised or exposed credentials immediately and establish credential lifecycle practices. Treat credentials that have been publicly exposed as compromised, even if the original location has subsequently been edited or deleted. Removing the content does not invalidate the credential or eliminate copies retained in edit history, caches, archives, logs, or other systems. Immediately revoke or rotate the affected credentials and investigate their historical use. Where supported, organizations should favor mechanisms that reduce reliance on long-lived credentials. Learn more about protecting secrets with Defender for Cloud.
• Apply least privilege to service principals and other workload identities. Review the Azure RBAC permissions assigned to service principals and restrict their privileges to the resources and operations required by their applications. Learn more about best practices for Azure RBAC.
• Protect backup and recovery infrastructure as part of ransomware resilience. Restrict access to backup and recovery resources and closely monitor attempts to modify or remove their protection controls. Learn more about Azure Backup security best practices.
• Scale investigation and response with agentic defenses. Use Project Perception to help defenders deploy AI agents that investigate and respond across large, complex environments at machine speed.
• Strengthen security posture for AI applications and agentic systems. Use Microsoft Defender for AI Security (codename MDASH) to discover AI assets, identify vulnerabilities and misconfigurations, and reduce exposure to AI-related attack paths.

Microsoft Defender XDR detections

Microsoft Defender XDR customers can refer to the list of applicable detections below.

Microsoft Defender XDR coordinates detection, prevention, investigation, and response across cloud endpoints, identities, email, and apps to provide integrated protection against attacks like the threat discussed in this blog. Customers with provisioned access can also use Microsoft Security Copilot in Microsoft Defender to investigate and respond to incidents, hunt for threats, and protect their organization with relevant threat intelligence.

Microsoft Security Copilot

Security Copilot customers can use the standalone experience to create their own prompts or run the following prebuilt promptbooks to automate incident response or investigation tasks related to this threat:

• Incident investigation
• Microsoft User analysis
• Threat actor profile
• Threat Intelligence 360 report based on MDTI article

Note that some promptbooks require access to plugins for Microsoft products such as Microsoft Defender XDR or Microsoft Sentinel.

Threat intelligence reports

Microsoft Defender XDR customers can use the following threat analytics reports in the Defender portal (requires license for at least one Defender XDR product) to get the most up-to-date information about the activity and techniques discussed in this blog. These reports provide intelligence, protection information, and recommended actions to prevent, mitigate, or respond to associated threats found in customer environments.

• Microsoft Defender XDR Threat Analytics report on Storm-3168

Microsoft Security Copilot customers can also use the Microsoft Security Copilot integration in Microsoft Defender Threat Intelligence, either in the Security Copilot standalone portal or in the embedded experience in the Microsoft Defender portal to get more information about this threat threat.

MITRE ATT&CK Techniques observed

The following MITRE ATT&CK mappings reflect behaviors observed during this activity.

• T1190 Exploit Public-Facing Application | Storm-3168 linked infrastructure repeatedly probed sensitive application paths on applications hosted in Azure App Service for potential exploitation.
• T1078.004 Valid Accounts: Cloud Accounts | Compromised service principals were used for Azure resource discovery and destruction.
• T1526 Cloud Service Discovery | The identities enumerated subscriptions, virtual machines, resource groups, Azure Storage, Web Apps, App Service plans, locks, and Recovery Services.
• T1485 Data Destruction | Azure Storage, Key Vault, Function App, and App Service plan resources were deleted. Azure SQL deletion was also attempted, extending the destructive objective toward databases.
• T1490 Inhibit System Recovery | Site Recovery disk locks and an Azure Backup protection lock were targeted for deletion

Indicators of compromise (IOC)

References

• JADEPUFFER: Agentic ransomware for automated database extortion by Sysdig

Learn More

For the latest security research from the Microsoft Threat Intelligence community, check out the Microsoft Threat Intelligence Blog.

To get notified about new publications and to join discussions on social media, follow us on LinkedIn, X (formerly Twitter), and Bluesky.

To hear stories and insights from the Microsoft Threat Intelligence community about the ever-evolving threat landscape, listen to the Microsoft Threat Intelligence podcast.

Review our documentation to learn more about our real-time protection capabilities and see how to enable them within your organization.  

• Learn more about securing Copilot Studio agents with Microsoft Defender 
• Evaluate your AI readiness with our latest Zero Trust for AI workshop.
• Microsoft 365 Copilot AI security documentation
• How Microsoft discovers and mitigates evolving attacks against AI guardrails
• Prompt injection protection in Microsoft Defender for Office 365 – official documentation of the prompt injection protection in Microsoft Defender for Office 365.
• How Microsoft discovers and mitigates evolving attacks against AI guardrails | Microsoft Security Blog
• Manipulating AI memory for profit: The rise of AI Recommendation Poisoning | Microsoft Security Blog – a related example of an AI-era technique observed in email traffic
• Defending the inbox against prompt injection attacks | Microsoft Defender for Office 365 Blog – feature announcement introducing prompt injection protection in Microsoft Defender for Office 365.
• Learn how Microsoft is reimagining the SOC for the agentic era with ISOC in Microsoft Defender