Cloud penetration tests still find open storage buckets and overly broad IAM policies. Those findings remain useful. What has changed is the speed and automation with which a valid non-human identity can turn privilege into availability loss. You do not need a novel remote-code exploit when the attacker already holds a service principal, managed identity or long-lived access key that the control plane trusts.
This research note summarises the publicly documented Storm-3168 pattern, connects it to the wider credential-to-cloud kill chain, and turns both into a practical testing and hardening checklist for organisations running multi-tenant SaaS, API platforms and AI-adjacent workloads in India and internationally. It does not invent CVEs, breach counts or client outcomes. Where numbers or sequences appear, they come from named public sources.
1. The public pattern: identity first, destruction next
Microsoft’s write-up of Storm-3168 describes two compromised service principals in the same Azure tenant. One focused on discovery; the other on discovery, destructive operations and credential collection. Enumeration ran for many hours with hundreds of successful read operations across subscriptions, resource groups and virtual machines. Destructive activity then compressed into a short window: more than a hundred storage-account deletion attempts (most succeeding), deletion of a Key Vault, Function App and App Service plan in the same resource group, and parallel attempts against Azure SQL that failed because of an unsupported API version—not because authorisation blocked them.
Two defensive signals from the same report deserve emphasis for any cloud assessment:
- Independent recovery controls worked when present. Azure resource locks and storage-level deletion protection blocked some deletions even when the identity held broad delete rights.
- Existing role assignments were enough. Group-granted Storage Account Contributor and direct Contributor / SQL DB Contributor assignments authorised the observed actions. The actor did not need a separate privilege-escalation exploit after the service principal was compromised.
Microsoft also notes that the principal’s client ID, client secret and tenant ID had previously appeared in plaintext in a public GitHub issue. Editing the issue did not invalidate the secret; copies and edit history can keep exposure alive until the credential is rotated or revoked. Microsoft could not confirm that this exact secret powered the activity, but the operational lesson stands: treat any public secret disclosure as compromise until proven otherwise.
- Secret / CI credential exposure
- Workload identity (service principal) abuse
- Contributor-class privileges
- Data stores and key material
- Agentic destruction / recovery interference
Drag or swipe to orbit. Click or tap a node (or use Prev / Next / dots) for the info panel. Play auto-advances stages. Explode spreads the chain and zooms out. Keyboard: ← →, Space, P, E. WebGL required; text fallback if unavailable. No audio. Respects reduced-motion.
2. Upstream of the control plane: how secrets arrive
Storm-3168 shows what happens after a powerful workload identity is available. The path that delivers those credentials is often quieter. Qualys’ September 2026 analysis of supply-chain campaigns (including install-time npm/PyPI/Ruby/Go malware such as Shai-Hulud variants and related tooling compromises) describes a recurring sequence: trusted package or tool execution on a developer workstation or CI runner → harvest of cloud keys, PATs, kubeconfigs and vault tokens → legitimate cloud API use for discovery, theft or persistence.
For product teams in India’s SaaS, fintech and AI stack, that sequence maps cleanly onto daily practice: npm/pip installs in CI, shared runner secrets, long-lived Azure AD application secrets, AWS access keys in ~/.aws/credentials, and AI provider API keys in .env files. Infostealer and supply-chain reporting from vendors such as Wiz similarly highlights cloud and AI credentials as high-value yields from developer endpoints.
PocForge’s related methodology pieces on cloud IAM attack paths and identity-before-configuration already argue that reviews should start from real principals. Agentic destruction campaigns simply raise the severity of “valid identity + delete/key permissions + weak recovery controls” from theoretical to operationally urgent.
| Stage | What public reporting shows | What to test in an engagement |
|---|---|---|
| Credential exposure | GitHub issues/history, package install hooks, CI memory/env harvest | Secret scanning scope, history redaction myths, CI OIDC vs static keys |
| Workload identity abuse | Service principals with Contributor-class roles | Least privilege, role assignment graphs, group-inherited delete rights |
| Automated recon | Hundreds of ARM list/read calls over hours | Anomaly detection on control-plane enumeration; unusual user-agents |
| Destructive impact | Bulk storage/app deletion in minutes | Resource locks, immutability, backup isolation, delete protection |
| Credential collection | ListKeys / secret retrieval after destruction | Who can mint storage keys; dual-control for key rotation |
3. Why this hits India SaaS, API and AI estates hard
Indian product companies often ship API-first multi-tenant SaaS on a small set of cloud subscriptions with shared CI, Terraform state in cloud storage, and application identities granted “enough to ship” during early growth. That layout concentrates blast radius.
Recurring pressure points in scoped assessments (patterns, not named clients):
- App registrations / service principals for workers or AI tool-runners that also hold Contributor on resource groups with customer data stores.
- CI OIDC or static cloud keys on shared runners that can plan and apply infrastructure, or read production Key Vaults “for integration tests”.
- Recovery controls owned by the same identity family that can delete the workloads those controls should restore.
- AI/LLM features that add API keys and agent credentials to the same secret sprawl—see PocForge’s agentic AI security research.
For compliance evidence framing (SOC 2, ISO 27001, India buyer diligence), see VAPT for SOC 2 / ISO 27001 and when CERT-In empanelment matters. This article stays on the technical path.
4. Offensive test plan: from secret to impact (safely)
A cloud security assessment or cloud-focused penetration test should not attempt production destruction. It should prove whether the path exists, using read-only evidence, role simulation, policy review and—where authorised—controlled validation against non-production resources.
4.1 Inventory non-human identities
Enumerate service principals, managed identities, workload federation subjects, access keys and CI roles. For each, record: owner, last rotation, secret type (password vs certificate vs federated), and every role assignment including group inheritance. Map which identities can delete, listKeys, modify locks/backup policies or assign roles.
4.2 Trace credential exposure paths
Sample recent repositories, CI logs (metadata only), issue trackers and package install policies. Confirm whether long-lived secrets still exist after “we deleted the file.” Check whether Git history, ticket edit history or artefact caches could retain secrets. Prefer demonstrating exposure with synthetic canary secrets where possible.
4.3 Simulate the Storm-3168-shaped path
- Assume or analyse a low-glamour app identity (worker, exporter, agent tool runner).
- List reachable subscriptions, resource groups and data stores as that identity would (via policy simulation or authorised read).
- Identify whether delete, lock-removal or key-listing rights exist on storage, databases, vaults and recovery resources.
- Document blast radius in plain language: what customer data availability, secrets and rebuild time would be affected if that identity were automated against.
4.4 Validate recovery independence
Ask whether backup, immutability and resource locks are enforceable by a different identity boundary than production deployers. If the same Contributor can remove Site Recovery locks and delete the storage those backups live on, the recovery story is brittle under ransomware-aligned objectives—even without a encrypting malware payload on VMs.
Engagement scope prompt (copy for RFQs)
Include: (1) inventory of workload identities and CI cloud principals; (2) proof of excessive delete/key/lock permissions on data and recovery resources; (3) secret-exposure review for app registrations and static keys; (4) recommended least-privilege and lock/immutability changes with retest. Exclude: production destructive testing. See also how to write a VAPT RFQ.
5. Defensive priorities that survive automation
- Rotate and revoke on disclosure. Public paste, issue history or package incident = immediate invalidate, not “edit the post.”
- Prefer short-lived federation (OIDC to cloud roles, managed identities, workload identity federation) over multi-year client secrets.
- Least privilege with delete as a scarce right. Split deploy/read from destroy; require break-glass for bulk delete.
- Resource locks and deletion protection on storage, vaults and backup vaults—owned outside the application identity set.
- Immutable / isolated backups with monitoring on lock removal and backup-policy changes.
- Control-plane detection for unusual ARM/AWS/GCP enumeration volume, atypical user-agents and parallel token use from the same principal.
- CI install-time trust reduction: private registries, lockfiles, restricted lifecycle scripts, secret-less runners where feasible (as emphasised in recent supply-chain-to-cloud reporting).
Storm-3168 and supply-chain-to-cloud guidance converge on three choke points: reduce secret lifetime and exposure, constrain what stolen identities can destroy, and detect machine-speed control-plane abuse.
6. Related PocForge services and research
- Cloud security assessment · India
- External infrastructure penetration testing
- API security testing · AI / LLM security testing
- Research: Cloud IAM attack paths, When AI agents become the attack surface
- Case studies: SaaS tenant isolation, External perimeter hardening
FAQ
Is agentic cloud ransomware the same as encrypting ransomware on servers?
Not necessarily. Public Storm-3168 reporting describes control-plane destruction, recovery interference and key collection consistent with ransomware objectives, without documenting a classic on-host encryptor or ransom note in that case. Defenders should still treat availability and recovery attacks as ransomware-class risk.
Does rotating a secret after editing a GitHub issue fix the exposure?
Editing or deleting the disclosure does not invalidate the credential. Public reporting stresses revoke/rotate and investigate historical use. Assume copies exist in caches, forks and scrapers.
Should our annual VAPT include service-principal abuse paths?
If you run SaaS or cloud-native products, yes—at least as part of cloud assessment scope. Traditional web scans will not map Contributor-class delete rights on storage and backup locks. Clarify this in the RFQ.
How does this relate to AI/LLM testing?
Agentic AI features add tools and API keys that expand credential sprawl; agentic attackers automate post-compromise cloud actions. Test both the product’s agent boundaries and the cloud identities those systems (and your CI) rely on.
What should we ask vendors to prove in a cloud assessment report?
Evidence of identity→permission→resource paths, explicit notes on delete/key/lock rights, recovery-control independence, and retest after least-privilege and lock changes—not only a CSPM export.
Sources (public)
- Microsoft Security Blog — Storm-3168: Agentic-driven cloud attacks using compromised service principals (25 Sep 2026): microsoft.com/…/storm-3168-…
- Sysdig — JADEPUFFER / agentic ransomware research (referenced by Microsoft; Jul 2026 discovery)
- Qualys — The Developer is the New Perimeter: How Supply Chain Attacks Are Becoming Cloud Breaches (28 Sep 2026): blog.qualys.com/…
PocForge publishes offensive-security research to explain attack paths and defensive controls. This article is not a claim of CERT-In empanelment and does not describe a named client engagement.