JADEPUFFER heeft zich laten zien als een dreiging die Microsoft Azure niet alleen aanvalt, maar ook gericht capaciteit vernietigt. In de waarnemingen van Microsoft—onder de naam Storm-3168—wordt een reeks destructieve acties uitgevoerd met behulp van gestolen service principals. De activiteit vond plaats begin juni 2026 en duurde ongeveer achttien uur, met een kort maar intens destructief eindstuk.
Wat het extra zorgwekkend maakt, is dat de aanpak past in een bredere trend: aanvallen die met AI-achtige agenten geautomatiseerd worden, zodat een aanvaller sneller kan schakelen tussen verkenning, credential-vergaring en verwoestende acties in de cloud.
Wat Microsoft over JADEPUFFER meldt
Microsoft beschrijft de aanval als een evolutie in de werkwijze van de actor. Volgens onderzoekers Yossi Weizman en Tushar Mudi—met ondersteuning van het Microsoft Security Research-team—werden verschillende Azure-onderdelen geraakt nadat service principals waren gecompromitteerd.
De destructieve acties richtten zich op onder meer Azure Storage accounts, SQL-databases, Azure Key Vaults, Function Apps, recovery protection locks, Virtual Machines en App Services. Daarmee lijkt de aanval niet op een “stand-alone” incident, maar op een poging om zowel productie als herstelmogelijkheden te ondermijnen.
De rol van gestolen JADEPUFFER service principals
De kern van het verhaal draait om JADEPUFFER service principals: Microsoft stelt dat er twee gecompromitteerde service principals zijn waargenomen die aan dezelfde tenant waren gekoppeld. Eén daarvan werd vooral ingezet voor reconnaissance en het vinden van resources, terwijl de tweede service principal werd gebruikt voor de acties richting vernietiging en het verzamelen van credentials.
Het enumereren—het systematisch in kaart brengen—nam veel tijd in beslag: gedurende ongeveer zestien uur werden meer dan 300 read-operaties uitgevoerd. Daarbij werden onder andere virtuele machines, subscriptions, resource groups en gerelateerde resources bevraagd.
De tweede service principal voerde later nog aanvullende ontdekking uit, inclusief het enumereren van virtuele machines en resource groups over twee subscriptions, en dat binnen enkele seconden.
Van binnenkomst naar destructie: een kort, heftig eindstuk
Na de verkenningsfase volgde een fase waarin ook configuraties werden benaderd. Microsoft meldt dat de tweede service principal rond die tijd App Service configuration stores heeft opgespoord—waarschijnlijk om mogelijke blootgestelde credentials te vinden. Kort daarna werden meer dan 150 operaties uitgevoerd binnen 35 minuten, variërend van destructieve acties tot credential-gerelateerde activiteiten.
De destructieve sequentie duurde uiteindelijk ongeveer zeven minuten. In die periode werden meer dan 100 pogingen gedaan om storage account resources te verwijderen.
Opvallend is dat niet alles lukte. Sommige acties mislukten doordat een niet-ondersteunde API-versie werd gebruikt bij het verwijderen van een Azure SQL database resource type. Dat laat zien dat zelfs bij brede privileges niet elke stap zonder meer tot effect leidt—maar het geheel blijft schadelijk.
Welke Azure onderdelen zijn getroffen
Microsoft noemt meerdere typen doelen. Hieronder de meest relevante categorieën uit het incidentbeeld:
- Azure Storage accounts (met veel verwijderpogingen; meerdere accounts werden uiteindelijk verwijderd)
- Azure resource locks en storage account-level deletion protection (zorgden bij een deel van de accounts voor blokkades)
- Azure Key Vault (gericht benaderd)
- Function App en App Service plan (ook geraakt)
- Meerdere Azure SQL databases (de verwijderpogingen faalden vaak door API-versieproblematiek)
- Recovery protection locks (belangrijke onderdelen in herstelketens)
Dat niet alle storage accounts werden gewist, is een belangrijk leerpunt. Volgens Microsoft toont dit de waarde van onafhankelijke beveiligingen die blijven werken, zelfs wanneer een aanvaller beschikt over brede administratieve permissions via een gecompromitteerde identiteit.
Link met LLM-gestuurde ransomware-aanpak
De bredere context rond JADEPUFFER gaat terug naar eerdere observaties. Sysdig beschreef JADEPUFFER als een vroege ransomware-activiteit die “end-to-end” met ondersteuning van een large language model zou zijn uitgevoerd. In die eerdere beschrijving werd een bekende kwetsbaarheid in Langflow (CVE-2025-3248) benut om binnen te komen, waarna credentials werden verzameld en de aanvaller zich verder in het netwerk “doorboorde”.
Ook werden Nacos service configuration bestanden versleuteld, originele database tabellen verwijderd en een losgeldbrief gevraagd—met een Bitcoin-eis. Daarnaast werd genoemd dat dezelfde Langflow-instantie later opnieuw werd geraakt met een tweede ransomwarevariant, gecodeerd als ENCFORGE.
ENCFORGE is volgens de beschikbare informatie specifiek ontworpen voor AI-infrastructuur. Het systeem zou zoeken naar bestanden met ongeveer 180 extensies, waaronder model checkpoints, vector databases, trainingsdatasets en embedding indices. Daarnaast werden ook macOS-gerelateerde bestanden genoemd, zoals Keychain stores en Xcode-projectbestanden, maar ook documenten uit Apple Pages en Numbers.
Microsoft en Sysdig leggen daarbij de nadruk op de manier waarop AI-gedreven agenten meerdere technieken combineren. Niet elk onderdeel hoeft op zichzelf nieuw te zijn, maar het samenstellen tot een volledige operatie—van zoeken tot impact—maakt de aanpak lastig te bestrijden.
Hoe kon de service principal gecompromitteerd raken?
Microsoft geeft aan dat het nog onduidelijk is hoe de service principal precies is gecompromitteerd. Wel meldt Microsoft dat de client ID, client secret en tenant ID eerder in platte tekst zichtbaar waren in een openbaar GitHub issue van een medewerker van de getroffen organisatie. Hoewel het secret later is verwijderd, bleef het volgens Microsoft toegankelijk via de openbare editgeschiedenis.
Voor organisaties is dit een herkenbaar risico: zelfs wanneer een kwetsbare waarde wordt “weggehaald”, kan deze via historische versies opnieuw tevoorschijn komen. Daarmee wordt de kans groter dat een aanvaller credentials alsnog kan hergebruiken voor toegang tot cloudresources.
Storm-3168 en automatische probing
Microsoft zegt ook herhaaldelijk probing te hebben gezien vanuit aan Storm-3168 gekoppelde infrastructuur tegen meerdere Azure App services bij verschillende klanten. De timing en verdeling van werkzaamheden over meerdere service principals wijzen erop dat de aanval mogelijk geautomatiseerd of gescript is uitgevoerd.
In het eindbeeld was de intentie volgens Microsoft in lijn met ransomware: door het wissen van talloze Azure resources, gecombineerd met het raken van backup- en recovery-gerelateerde onderdelen, werd het herstellen van de getroffen omgeving bemoeilijkt.
Wel geeft Microsoft aan dat er geen succesvolle data-exfiltratie is waargenomen en dat geen losgeldbrief is gezien in verband met deze specifieke intrusie.
Wat je nu kunt doen: concrete verdedigingsstappen
Op basis van het patroon dat Microsoft beschrijft, is de belangrijkste les dat identiteitsbeveiliging en harde grenzen veel kunnen betekenen—zelf wanneer een aanvaller al een sleutel in handen heeft.
1) Controleer service principals en secrets
Inventariseer welke service principals actief zijn en beoordeel of secrets (client secrets, sleutels of tokens) mogelijk in publieke systemen terecht zijn gekomen. Bekijk ook of je repo’s en issues adequate revisiebeheermaatregelen hebben, zodat gevoelige informatie niet via geschiedenissen terugvindbaar is.
2) Zet deletion protection en resource locks proactief in
Het incident laat zien dat resource locks en deletion protection het verschil kunnen maken. Zorg dat kritieke onderdelen—zoals storage accounts en herstelcomponenten—over extra beschermingslagen beschikken die blijven werken wanneer een identiteit gecompromitteerd raakt.
3) Monitor vroeg voor reconnaissance en configuratieprobing
Aangezien de verkenningsfase lang duurde (met honderden read-operaties) en later snel omsloeg naar destructie, loont vroeg detectie. Let op afwijkende patroonherkenningen: ongebruikelijke enumeraties over subscriptions, resource groups en App Service configuraties.
4) Denk in scenario’s voor cloud-ransomware
Bereid incidentrespons voor op een scenario waarin niet alleen data, maar ook infrastructuurcomponenten worden geraakt. Dat helpt teams om snel te handelen zodra de destructieve fase inzet.
Wil je breder kijken naar hoe aanvallen zich in identity-gedreven omgevingen kunnen verplaatsen en wat je kunt doen bij compromis van cloud-achtige pipelines? Lees dan ook eens wat je moet doen bij gecompromitteerde GitHub Actions.
Conclusie
JADEPUFFER service principals vormden in dit incident het fundament onder een aanval die eindigde in het wissen van grote delen van een Azure-omgeving. Microsoft ziet dit als een verschuiving naar AI-gestuurde, gecoördineerde post-compromise operaties die sneller en op grotere schaal kunnen toeslaan.
Voor defenders ligt de nadruk daarom op drie pijlers: voorkom blootstelling van identiteitsgegevens, zet harde beschermingslagen zoals locks en deletion protection in, en detecteer vroege verkenning en configuratieprobing voordat de destructieve fase begint.
Bron: https://thehackernews.com/2026/09/jadepuffer-linked-attackers-used.html
