JadePuffer vernietigt Azure‑resources in zeven minuten met proxy‑aanval
Microsoft onthulde in juni 2026 dat de aanvaller met de codenaam JadePuffer een gestolen service‑principal gebruikte om in slechts zeven minuten meer dan honderd verwijderingspogingen uit te voeren op verschillende Azure‑resources, waarbij sommige resources dankzij vergrendelings‑ en beschermingsmechanismen werden gered.

Gebeurtenisoverzicht
In juni 2026 publiceerde het Microsoft‑beveiligingsteam een bericht op de officiële Microsoft Security Blog waarin twee afzonderlijke incidenten werden beschreven waarbij Azure‑resources werden aangevallen met behulp van een gecompromitteerde service‑principal. De aanvaller, intern aangeduid met de codenaam JadePuffer en gelabeld onder de interne tracking‑naam Storm‑3168, voerde beide aanvallen uit in verschillende tenants. In beide gevallen verkregen de aanvallers eerst toegang tot de inloggegevens van een service‑principal, waarna zij via een proxy‑mechanisme een groot aantal lees‑ en schrijfbewerkingen én vernietigende commando’s op de cloud‑infrastructuur uitvoerden. Deze aanpak maakte het mogelijk om op afstand en met hoge snelheid acties te ondernemen die normaal gesproken alleen door geautoriseerde entiteiten zouden worden uitgevoerd.
Aanvalsmethode en tijdlijn
In het eerste van de twee beschreven incidenten bleef de gecompromitteerde service‑principal gedurende ongeveer vijftien uur en dertig minuten actief en voerde continu verkenningsacties uit. Tijdens deze periode werden meer dan driehonderd lees‑ en inspectieverzoeken uitgevoerd, waarmee de aanvaller een gedetailleerd beeld kreeg van de aanwezige resources en hun configuraties. Het tweede incident was veel korter, maar desondanks bijzonder intensief: binnen een tijdsbestek van vijfendertig minuten werden meer dan honderd vijftig vernietigings‑ of credential‑verzamelingsacties gestart. De kern van de vernietigingsfase, waarin de daadwerkelijke verwijderingspogingen plaatsvonden, duurde slechts ongeveer zeven minuten. In die korte, maar kritieke periode probeerde de aanvaller meer dan honderd opslagaccounts te verwijderen, wat aantoont hoe snel en grootschalig een geautomatiseerde aanval kan escaleren wanneer een service‑principal is gecompromitteerd.
Gedurende die zeven minuten van actieve vernietiging volgde de aanvaller een duidelijk gedefinieerde reeks stappen. Eerst werden de doel‑resources opgesomd en geïdentificeerd via enumerate‑calls, waarna de Delete‑API werd aangeroepen met het doel om opslagaccounts en andere gekoppelde services te verwijderen. Hoewel een deel van de getroffen resources reeds was beschermd met resource‑locks of delete‑protection, waardoor de daadwerkelijke verwijderingsverzoeken werden geblokkeerd, werden er desondanks talloze pogingen ondernomen. Deze massale hoeveelheid verzoeken wijst erop dat de gebruikte scripts sterk geautomatiseerd waren en in staat waren om met een zeer hoge frequentie API‑calls te genereren, waardoor de kans op succesvolle vernietiging toenam ondanks de aanwezige beveiligingsmaatregelen.
- Meer dan 100 verwijderingspogingen op opslagaccounts
- Meer dan 150 vernietigings‑ of credential‑verzamelingsacties
- Meer dan 300 lees‑ en verkenningsverzoeken (eerste incident)
- Meer dan 30 ListKeys‑aanroepen (ongeveer 30 minuten later)
Bewijs en bronnen
Microsoft classificeert dit type aanval onder de interne aanduiding Storm‑3168 en heeft bevestigd dat de aanvaller de verkregen service‑principal‑credentials heeft gebruikt om proxy‑acties uit te voeren tegen Azure‑resources. In een gelijktijdig rapport van iThome werd vermeld dat sommige van de gecompromitteerde service‑principal‑credentials eerder waren verschenen in een openbaar GitHub‑issue. Microsoft heeft echter expliciet aangegeven dat zij niet hebben bevestigd dat die specifieke credential de directe bron van de inbraak was, waardoor er nog enige onzekerheid bestaat over de exacte oorsprong van de gelekte inloggegevens.
Tijdens het forensisch onderzoek heeft Microsoft geen aanwijzingen gevonden van een ransomware‑e-mail of andere vormen van afpersingscommunicatie. Evenmin werden duidelijke tekenen van datalekken of exfiltratie van gevoelige gegevens waargenomen. Het enige vervolggedrag dat werd gedetecteerd, bestond uit een reeks van meer dan dertig ListKeys‑verzoeken die ongeveer dertig minuten na de initiële vernietigingsfase werden uitgevoerd. Deze verzoeken duiden erop dat de aanvaller nog steeds probeerde extra sleutelinformatie te verkrijgen, mogelijk om later verdere toegang of schade te kunnen veroorzaken.
Impact en verdedigingsresultaten
De aanwezigheid van resource‑locks en delete‑protection speelde een cruciale rol in het beperken van de daadwerkelijke schade. Dankzij deze beveiligingsmechanismen werden de meeste van de meer dan honderd opslagaccounts die werden aangevallen, niet daadwerkelijk verwijderd. Daarnaast faalde een poging tot het verwijderen van Azure‑SQL‑instellingen omdat de gebruikte API‑versie die specifieke bewerking niet ondersteunde, waardoor een potentieel grootschalig verlies van database‑resources werd voorkomen. Deze combinatie van beschermingslagen toonde aan hoe belangrijk het is om zowel resource‑level als API‑level beveiligingen te implementeren.
Ondanks de effectiviteit van de vergrendelings‑ en beschermingsmechanismen, slaagde de aanvaller er toch in om resources te enumereren en een aantal sleutels te bemachtigen. Dit onderstreept dat alleen resource‑locks niet voldoende zijn om een proxy‑aanval volledig te neutraliseren. Microsoft heeft daarom aanbevolen dat getroffen tenants onmiddellijk een grondige controle uitvoeren op het gebruik van alle service‑principal‑credentials, en dat zij conditionele toegang en het principe van minimale rechten (least‑privilege) activeren om de aanvalsvectoren verder te verkleinen.
Voor de toekomst heeft Microsoft aangekondigd dat er nieuwe realtime‑waarschuwingen zullen worden toegevoegd aan Azure Monitor die abnormaal gedrag van service‑principals detecteren. Daarnaast zal er extra aandacht worden besteed aan de compatibiliteit van API‑versies, zodat verouderde of niet‑ondersteunde API‑calls sneller worden geblokkeerd en zo het aanvalsvlak wordt verkleind. Organisaties worden tevens geadviseerd om regelmatig de sleutels van service‑principals te roteren en om gevoelige resources onder strengere delete‑protection‑beleid te plaatsen, zodat zelfs in het geval van een compromittering de potentiële impact beperkt blijft.
Bronnen
- JadePuffer借助AI代理攻擊Azure,微軟揭露兩起雲端資料破壞事件iThome · 30 september 2026
- Storm-3168: Agentic-driven cloud attacks using compromised service principalsMicrosoft Security Blog · 25 september 2026



