Microsoft a publicat pe 25 septembrie 2026 analiza unui incident în care un mediu Azure a fost devastat: ștergeri în masă de conturi de stocare, baze de date SQL, Key Vault, Function Apps, mașini virtuale și App Services. Punctul de plecare nu a fost o vulnerabilitate. A fost un identificator de client, un secret de client și un identificator de tenant, lăsate în text clar într-un issue public pe GitHub de către un angajat.
Cronologia: 15 ore de privit, 7 minute de distrus
- Începutul lui iunie 2026 — recunoaștere: peste 300 de operațiuni de citire reușite, pe abonamente, grupuri de resurse și mașini virtuale, desfășurate pe parcursul a aproximativ 15 ore și jumătate.
- Faza de distrugere — aproximativ șapte minute, cu peste 100 de tentative de ștergere. Majoritatea ștergerilor de conturi de stocare au reușit. Au fost vizate și un Key Vault, o Function App și un plan de App Service.
- Ștergerile de baze de date SQL au eșuat, din cauza unor versiuni de API nesuportate. Un accident, nu un control.
- La aproximativ 30 de minute după distrugere — peste 30 de operațiuni de listare a cheilor pe conturile de stocare, inclusiv pe resurse de Site Recovery.
Ultimul punct este cel care doare. Recuperarea după ștergere depinde de infrastructura de backup, iar atacatorul s-a uitat exact acolo. Iar raportul de 15 ore de recunoaștere față de 7 minute de execuție spune tot despre fereastra reală de detecție: nu ai de reacționat în timpul distrugerii, ci în ziua în care cineva citește liniștit tot ce ai.
Ce este o identitate care nu aparține nimănui
În Azure, un service principal este identitatea unei aplicații. Nu are un om în spate, nu primește email, nu apare pe lista de angajați și nu pleacă niciodată din companie. În incidentul descris au fost folosite două: una pentru descoperire, alta pentru ștergeri și colectarea de chei.
Aici se leagă cu o discuție pe care am avut-o recent despre accesul rămas deschis după plecarea unui angajat. Diferența este că un cont de om are cel puțin un moment natural în care cineva își amintește de el: ziua în care omul pleacă. O identitate de aplicație nu are acel moment. Este creată de un dezvoltator, într-o seară, ca să funcționeze o integrare, și rămâne acolo cu permisiunile pe care i le-a dat atunci — de obicei mai multe decât ar fi nevoie.
Despre „agentic", cu precizia necesară
Microsoft numește activitatea condusă agentic, dar merită citit exact pe ce se bazează: analiza momentelor și a tokenurilor — cinci tokenuri emise pentru service principal, două active în aceeași fereastră de 70 de secunde, concentrate pe tipuri diferite de resurse. Compania spune că sincronizarea și împărțirea muncii indică puternic o execuție automatizată sau scriptată.
Pentru context, raportul Sysdig din 1 iulie 2026 descrie o operațiune separată a aceleiași grupări: acces inițial într-o instanță Langflow expusă la internet prin CVE-2025-3248, apoi un lanț complet — recunoaștere, escaladare de privilegii, mișcare laterală, furt de credențiale, exfiltrare și extorcare asupra unei baze de date de producție. Sysdig afirmă că agentul a căutat în paralel chei de API pentru modele de limbaj, credențiale de cloud, portofele de criptomonede și fișiere de configurare. Este cercetarea Sysdig, nu a Microsoft, și se referă la un alt incident.
Ce nu se știe
- Ce organizație a fost afectată — Microsoft nu numește victima.
- Ce sectoare au fost vizate — sursa nu identifică niciunul.
- Dacă datele au fost și exfiltrate, nu doar șterse.
- Dacă angajatul care a publicat valorile știa ce sunt. Probabil a văzut un fragment de configurație, nu o cheie de la casă.
Comportamentul pe care îl antrenezi la oameni
- Un identificator de client plus un secret de client plus un tenant nu sunt „configurație". Sunt credențiale. Regula simplă de predat: dacă un set de valori permite cuiva să se autentifice, nu se lipește nicăieri public — nici în issue, nici în ticket, nici într-o captură de ecran.
- Când ceri ajutor public, anonimizează înainte, nu după. Un exemplu minimal reprodus cu valori false rezolvă aceeași problemă tehnică.
- Dacă ai publicat deja ceva, raportează imediat și nu te limita la a șterge postarea. Ștergerea nu invalidează secretul — asta este exact fraza din analiza Microsoft.
- Nu există „e doar un mediu de test". Un tenant de test are adesea aceleași chei de stocare și aceleași permisiuni ca producția.
- Raportarea trebuie să fie fără consecințe pentru cel care raportează. Cineva care se teme că va fi certat va spera că nimeni nu observă.
Controalele pe care le cere Microsoft
- Activarea protecțiilor Defender for Cloud pentru Resource Manager, stocare, Key Vault, App Service și baze de date.
- Evitarea stocării credențialelor de service principal, a cheilor de stocare și a șirurilor de conexiune în depozite de cod sau în locații publice.
- Rotirea imediată a credențialelor compromise sau expuse.
- Principiul privilegiului minim aplicat identităților de aplicație.
- Protejarea infrastructurii de backup și de recuperare — partea către care s-a îndreptat atacatorul după ștergeri.
Exercițiul: 40 de minute
Cu dezvoltare, IT, securitate și cineva din conducere. Pentru fiecare etapă: decizia, responsabilul, termenul și dovada.
- Injectul 1 — un dezvoltator realizează că a inclus un secret într-un issue public, acum trei luni. Ce faceți în prima oră și ce anume nu rezolvă ștergerea postării?
- Injectul 2 — trebuie să rotiți acel secret. Cine știe ce se strică atunci când îl rotiți, și cât durează să aflați?
- Injectul 3 — observați citiri neobișnuite, dar nimic distrus. Cine decide că este un incident și nu un job de inventariere?
- Injectul 4 — s-au șters conturi de stocare. Cine confirmă că backupul este într-un loc pe care identitatea compromisă nu îl putea atinge?
Injectul 2 este de obicei cel care blochează sala. Multe organizații nu rotesc niciodată secretele de aplicație tocmai fiindcă nimeni nu știe ce depinde de ele — iar asta transformă fiecare secret într-o piesă pe care nu o mai atinge nimeni.
Ce măsori
- Numărul de identități de aplicație existente și câte au un proprietar nominal.
- Câte dintre ele au permisiuni de ștergere pe resurse de producție și dacă au nevoie de ele.
- Vechimea celui mai vechi secret nerotit, în zile.
- Timpul necesar pentru a roti un secret de aplicație, de la decizie la finalizare — măsurat.
- Dacă backupurile pot fi șterse folosind aceleași credențiale cu care se accesează datele.
- Numărul de raportări interne de secrete expuse pe lună și dacă vreuna a fost sancționată — a doua cifră ar trebui să fie zero.
Concluzia nu este despre Azure. Este că într-un mediu de cloud cele mai puternice identități nu aparțin nimănui, iar cea mai banală decizie umană — a lipi un fragment de configurație într-un loc public — le pune la dispoziția altcuiva. Cincisprezece ore mai târziu, cineva știe deja tot. Șapte minute după aceea, nu mai e mult de salvat.