Microsoft Details JADEPUFFER's Destructive Azure Attacks
Microsoft Details Destructive Cloud Tactics of JADEPUFFER
Related Entities
Threat Actors
Organizations
Products & Tech
Other
Full Report
Executive Summary
Microsoft Security Research has released a detailed analysis of a highly destructive cloud attack campaign targeting Microsoft Azure environments. The campaign is attributed to Storm-3168, a threat actor also known as JADEPUFFER, which has been described as the first "agentic ransomware" group due to its use of automation. The attack leveraged compromised Azure service principals to conduct rapid, automated reconnaissance and destruction. In a destructive phase lasting only seven minutes, the actor wiped numerous cloud resources, including storage accounts and an Azure Key Vault, and critically, attempted to delete Azure backups to prevent recovery. This incident signifies a dangerous evolution in cloud attacks, where automated scripts can cause catastrophic damage in minutes, leaving little time for human-led intervention.
Threat Overview
The threat actor, Storm-3168/JADEPUFFER, gained initial access by compromising at least two service principals within a single Azure tenant. Microsoft notes one of these may have been compromised via credentials accidentally exposed in a public GitHub issue. This highlights the critical risk of secret leakage in public code repositories.
The attack proceeded in two distinct phases:
- Reconnaissance (15 hours): Using a compromised identity, the actor performed over 300 successful read operations. This slow, low-profile activity was designed to map the victim's entire cloud environment, enumerating virtual machines, subscriptions, resource groups, and storage accounts (
T1526 - Cloud Service Discovery). - Destruction (7 minutes): The attack then switched to a high-speed, automated destructive phase. In just seven minutes, the attacker used scripted commands to issue over 100 deletion requests for storage accounts, successfully deleting most of them. They also deleted an Azure Key Vault, a Function App, and an App Service plan. This rapid deletion of resources is a form of
T1485 - Data Destruction.
Crucially, the attackers' actions aligned with a ransomware objective. They specifically targeted and attempted to delete Azure Site Recovery locks and Azure Backup protection (T1561 - Disk Wipe). This shows a clear intent to not only destroy data but also to eliminate the victim's ability to recover, thereby increasing leverage for a ransom demand.
Technical Analysis
The attack's effectiveness stemmed from the abuse of legitimate, high-privilege cloud identities—service principals.
Key TTPs:
- Initial Access: The attack began with
T1078.004 - Cloud Accounts, specifically compromised service principals. This is a shift from user-centric attacks to machine-identity-centric attacks. - Automated Reconnaissance: The long reconnaissance phase using read-only operations was likely scripted to avoid detection thresholds while building a complete picture of the target environment.
- Automated Destruction: The speed and parallelism of the destructive phase (100+ deletion attempts in 7 minutes) strongly indicate the use of an automated script or tool—an "agentic" attack. The script likely iterated through the list of resources gathered during reconnaissance and issued deletion commands for each.
- Impairing Defenses: The targeting of Azure Key Vault (
T1552.005 - Cloud-based Password Stores) and Azure Backup protection demonstrates a sophisticated understanding of cloud environments and a focus on maximizing damage and preventing recovery.
MITRE ATT&CK Techniques Observed:
T1078.004 - Cloud AccountsT1526 - Cloud Service DiscoveryT1485 - Data DestructionT1561 - Disk WipeT1552.005 - Cloud-based Password StoresT1114.002 - Remote Data Staging(implied by retrieving storage account keys)
Impact Assessment
The impact of such an attack is catastrophic and immediate. The destruction of primary storage accounts and backups can lead to irreversible data loss and prolonged business outage. For a cloud-native organization, this is an extinction-level event. The speed of the attack makes manual response nearly impossible. By the time an alert is triaged, the damage is already done. This incident serves as a stark warning for all organizations using public cloud services: the security of machine identities (like service principals) is as critical, if not more so, than the security of user identities. The financial and reputational damage from such an attack would be immense.
IOCs — Directly from Articles
No specific IOCs were provided in the public reports.
Cyber Observables — Hunting Hints
Security teams may want to hunt for the following patterns which could indicate related activity:
Azure Activity Logsaz storage account deleteMicrosoft.RecoveryServices/vaults/backupFabrics/protectionContainers/protectedItemsGet Storage Account KeysDetection & Response
- Identity-Based Anomaly Detection: Implement user and entity behavior analytics (UEBA) for cloud identities. Baseline the normal activity of service principals and alert on deviations, such as a dormant account becoming active or an application identity suddenly performing broad reconnaissance. This aligns with D3FEND's
D3-RAPA - Resource Access Pattern Analysis. - Automated Response: The speed of this attack necessitates automated responses. For example, an alert for a service principal attempting to delete a backup could automatically trigger a temporary suspension of that identity's permissions pending review.
- Log Monitoring: Ingest Azure Activity Logs, Azure AD sign-in logs, and other cloud logs into a SIEM. Create high-severity alerts for deletion events on critical resources (storage accounts, databases, backups, key vaults).
Mitigation
- Secure Service Principals: Treat service principals like privileged user accounts. Apply the principle of least privilege, granting them only the specific permissions needed for their function. Regularly audit their permissions. This aligns with D3FEND's
D3-UAP - User Account Permissions. - Implement MFA for Service Principals: Where possible, use certificate-based authentication for service principals instead of client secrets, as secrets are more easily leaked. Use Azure AD Conditional Access policies to restrict their use to trusted locations.
- Protect Backups: Use Azure's built-in features like resource locks (
CanNotDelete) and soft delete for backups and critical resources. This can prevent accidental or malicious deletion and provide a recovery window. - Secrets Management: Do not hardcode credentials or secrets in code. Use a secure secrets management solution like Azure Key Vault and scan code repositories for exposed secrets.
Timeline of Events
MITRE ATT&CK Mitigations
Privileged Account Management
Apply strict lifecycle and permissions management to service principals, treating them as highly privileged accounts.
Active Directory Configuration
Harden Azure AD by implementing least-privilege access for service principals and using Conditional Access policies to restrict their usage.
Implement comprehensive auditing of Azure Activity Logs and Azure AD sign-in logs to detect anomalous behavior from service principals.
Data Backup
Use immutable storage for backups and resource locks to prevent malicious or accidental deletion of recovery data.
D3FEND Defensive Countermeasures
The core of this attack was the abuse of over-privileged service principals. The most critical countermeasure is to enforce the principle of least privilege on all non-human identities in Azure. Do not grant service principals broad roles like 'Contributor' or 'Owner' at the subscription level. Instead, assign them custom roles with the absolute minimum permissions required for their specific task, scoped to a specific resource or resource group. For example, if a service principal only needs to write to a single storage account, its role should only contain the Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write permission for that specific resource. Regularly audit these permissions using Azure PIM (Privileged Identity Management) or third-party Cloud Security Posture Management (CSPM) tools. This granular control dramatically limits the blast radius if a service principal's credential is compromised.
The attacker's behavior had two distinct phases: slow reconnaissance and rapid destruction. Both can be detected with robust behavioral analytics. Configure your cloud security tools (like Microsoft Defender for Cloud or a UEBA solution) to baseline the normal behavior of each service principal. An alert should be triggered if a service principal that is normally dormant or has a very narrow activity pattern suddenly begins performing hundreds of read operations across the entire environment. This is the reconnaissance phase. For the destruction phase, create high-severity, non-suppressible alerts for any deletion attempts on critical resource types (e.g., Microsoft.Storage/storageAccounts/delete, Microsoft.RecoveryServices/vaults/delete). Chaining these alerts—reconnaissance followed by deletion from the same identity—should trigger an automated response, such as disabling the account.
To detect the reconnaissance phase earlier, seed your environment with decoy resources and identities. Create a decoy service principal with a name like prod-backup-admin-spn and credentials that are placed in a plausible but monitored location (e.g., a 'private' but misconfigured GitHub repo or a developer's Confluence page). This decoy identity should have no actual permissions but should be heavily monitored. Any attempt to use this credential is a high-fidelity indicator of an attacker in your environment. Similarly, create decoy storage accounts or key vaults named legacy-financials-do-not-touch. Any access to these decoy resources provides an early warning that an attacker is enumerating your assets, giving you time to respond before they reach your real production systems.
Timeline of Events
Sysdig first documents JADEPUFFER as an 'agentic ransomware' operation (approximate date).
Microsoft publishes its detailed analysis of Storm-3168's destructive Azure campaign.
Sources & References
Article Author
Jason Gomes
• Cybersecurity PractitionerCybersecurity professional with over 10 years of specialized experience in security operations, threat intelligence, incident response, and security automation. Expertise spans SOAR/XSOAR orchestration, threat intelligence platforms, SIEM/UEBA analytics, and building cyber fusion centers. Background includes technical enablement, solution architecture for enterprise and government clients, and implementing security automation workflows across IR, TIP, and SOC use cases.
Editorial Standards & Analyst Review
CyberNetSec.io uses automation to assist source monitoring, deduplication, observable extraction, and structured intelligence generation. Published analysis follows human-defined editorial standards and adds defensive context including MITRE ATT&CK, D3FEND, STIX, and Sigma where applicable. Read our editorial policy.
Tags
📢 Share This Article
Help others stay informed about cybersecurity threats
🎯 MITRE ATT&CK Mapped
Every tactic, technique, and sub-technique used in this threat has been identified and mapped to the MITRE ATT&CK framework for consistent, actionable threat language.
🧠 Enriched & Analyzed
Observables and indicators of compromise (IOCs) have been extracted and cataloged. Risk has been assessed and correlated with known threat actors and historical campaigns.
🛡️ Actionable Guidance
Detection rules, incident response steps, and D3FEND-aligned mitigation strategies are included so your team can act on this intelligence immediately.
🔗 STIX Visualizer
Structured threat data is packaged as a STIX 2.1 bundle and can be visualized as an interactive graph — relationships between actors, malware, techniques, and indicators.
⚡ Sigma Generator
Sigma detection rules are derived from the threat techniques in this article and can be converted for deployment across any major SIEM or EDR platform.