Storm-3168: service principals compromise în Azure
Microsoft a publicat pe 25 septembrie 2026 analiza unui atac asupra unui tenant Azure, atribuit grupului pe care îl urmărește ca Storm-3168. Atacatorul a folosit două service principals compromise: a cartografiat resursele timp de peste 15 ore, apoi a încercat, în circa șapte minute, să șteargă peste 100 de conturi de stocare, alături de Key Vault, aplicații și protecțiile pentru backup.
Punctul de intrare nu a fost o vulnerabilitate, ci un secret: datele de autentificare ale unui service principal publicate într-un issue public pe GitHub și rămase vizibile în istoricul de editare după ce textul a fost corectat. Articolul arată ce trebuie verificat în Entra ID și Azure pentru ca același scenariu să nu funcționeze la voi.
Ce raportează Microsoft
La începutul lui iunie 2026, două service principals din același tenant au fost compromise. Primul a făcut recunoaștere, cu peste 300 de operații de citire reușite asupra abonamentelor, grupurilor de resurse și mașinilor virtuale. Al doilea a combinat descoperirea cu distrugerea și colectarea de credențiale. Rolurile atribuite includeau Storage Account Contributor, Contributor și SQL DB Contributor.
În fereastra distructivă au existat peste 100 de încercări de ștergere a conturilor de stocare, majoritatea reușite; unele au fost blocate de resource locks. Ștergerile bazelor de date Azure SQL au eșuat. Au fost șterse un Key Vault, un Function App și un App Service Plan, iar atacatorul a vizat lock-urile de protecție pentru Azure Backup și Site Recovery. În următoarea jumătate de oră a urmat colectarea cheilor, cu peste 30 de cereri ListKeys reușite pe conturile de stocare.
Microsoft nu a observat o notă de răscumpărare și nu a confirmat exfiltrarea datelor. Organizația afectată nu este numită. Compania consideră operațiunea „agentică”, adică automatizată cu un agent AI, pe baza ritmului, a împărțirii sarcinilor între identități și a tokenurilor folosite în paralel. Este o evaluare a Microsoft, nu un fapt verificabil din exterior.
Legătura cu JADEPUFFER
Microsoft leagă Storm-3168 de JADEPUFFER, grup descris în iulie 2026 de Sysdig ca primul caz documentat de ransomware agentic. Sysdig a observat atunci acces inițial printr-o instanță Langflow expusă (CVE-2025-3248) și un scenariu automatizat de extorcare pe baze de date. Noua analiză arată aceeași orientare spre distrugere, dar într-un mediu cloud și pornind de la o identitate compromisă, nu de la o vulnerabilitate.
Caută secretele expuse și tratează-le ca fiind compromise
- ▸Scanează codul, issue-urile, wiki-urile, pipeline-urile și istoricul lor pentru ID-uri de client, secrete și ID-uri de tenant. Un secret șters sau editat rămâne în istoricul Git și în istoricul de editare al issue-urilor.
- ▸Orice secret găsit într-un loc public se revocă și se înlocuiește, chiar dacă a fost deja eliminat din text. Microsoft subliniază că eliminarea unui secret expus nu îl invalidează.
- ▸Inventariază secretele și certificatele fiecărui service principal: data expirării, ultima folosire, responsabilul. Secretele fără expirare apropiată și fără responsabil sunt primele de eliminat.
- ▸Acolo unde e posibil, înlocuiește secretele cu identități gestionate sau cu federarea identității pentru workload-uri (Workload ID), de exemplu pentru GitHub Actions, ca să nu mai existe un secret de lungă durată care poate fi publicat.
Limitează ce poate face o identitate compromisă
- ▸Revizuiește atribuirile RBAC ale service principals. Un rol Contributor la nivel de abonament transformă o scurgere de secret într-o capacitate de ștergere a întregului mediu.
- ▸Aplică politici de Conditional Access pentru identitățile de tip workload, de exemplu restricții pe locații sau intervale IP, acolo unde licențele permit.
- ▸Pune resource locks de tip CanNotDelete pe resursele critice și pe cele de backup. În acest atac, lock-urile au blocat o parte din ștergeri.
- ▸Activează soft delete pentru conturile de stocare și Key Vault și imutabilitatea pentru Azure Backup, astfel încât ștergerea să nu fie definitivă, iar recuperarea să nu depindă de aceleași drepturi pe care le are atacatorul.
Detectează tiparul înainte de faza distructivă
Recunoașterea a durat peste 15 ore; ștergerea, câteva minute. Detecția utilă este cea din prima fază. Microsoft indică drept surse tabelele AzureActivity, pentru operațiunile Azure Resource Manager, și AADServicePrincipalSignInLogs, pentru autentificările service principals.
- ▸Autentificări ale unui service principal de la adrese IP sau din țări nefolosite anterior.
- ▸Un număr neobișnuit de operații de citire și enumerare pe abonamente și grupuri de resurse, venite de la aceeași identitate.
- ▸Operații de ștergere în rafală sau cereri ListKeys pe mai multe conturi de stocare.
- ▸Modificări sau ștergeri ale lock-urilor, ale politicilor de backup și ale resurselor Site Recovery.
- ▸Alerte Defender for Cloud precum operațiuni Azure Resource Manager dintr-o adresă proxy suspectă sau tipar neobișnuit de operațiuni într-un Key Vault.
Ce dovezi păstrezi
Awarely Monitor urmărește vulnerabilitățile, responsabilii și dovezile de remediere pentru activele voastre. Inventarul identităților, rotirea secretelor și regulile de detecție rămân în Entra ID, Azure și SIEM.
- ▸Inventarul service principals, rolurile lor, secretele active și data ultimei rotiri.
- ▸Rezultatul scanării de secrete și acțiunile luate pentru fiecare secret găsit.
- ▸Resursele protejate cu lock, soft delete și imutabilitate, verificate după configurare.
- ▸Regulile de detecție active pentru AzureActivity și AADServicePrincipalSignInLogs.
Păstrează dovezile controalelor cloud
Urmărește în Awarely Monitor responsabilii, deciziile și dovezile de remediere. Inventarul identităților, rotirea secretelor și detecția rămân în Entra ID, Azure și SIEM.