Sari la conținut
Braincap
← Toate articolele

Furt de 3,6 milioane de înregistrări „din Azure": nu e o breșă Microsoft, e furt de credențiale pe tenant

de Claudiu Hulea · IT Management Consultant

Ilustrație: cloud-ul Azure rămâne intact, cu bifă, în timp ce lacătul unui tenant de client e deschis cu o cheie furată din exterior — nu o spargere a platformei, ci credențiale compromise

Un atacator care își spune „TheHatman“ a scos la vânzare, pe un forum de criminalitate informatică, ce descrie drept 3,64 milioane de înregistrări de angajați „furate din Azure“ de la companii mari: McDonald’s, Vodafone, Tata Consultancy Services, HCL, Gap, InterContinental Hotels, Kyndryl. Titlurile sugerează o breșă Microsoft. Nu e. Iar Microsoft, până acum, nu a spus niciun cuvânt — și are un motiv.

Pe scurt

  • Revendicarea: ~3,64 milioane de înregistrări de angajați (nume, e-mail, ID de angajat, funcție, telefon, adresă, conturi de serviciu), scoase la vânzare de „TheHatman“ între 31 iulie și mijlocul lui august 2026.
  • Companii numite: McDonald’s (~1,7M), TCS (~800K), Vodafone (~425K), HCL (~250K), plus Gap, IHG, Kyndryl ș.a.
  • Vectorul, potrivit atacatorului: credențiale compromise — password spray + MFA fatigue, probabil și infostealers. Nicio vulnerabilitate de platformă Microsoft identificată.
  • Nu e o breșă Azure: e furt de credențiale pe tenant-urile clienților, adică responsabilitate partajată.
  • Microsoft: nicio poziție oficială la data relatării.
  • Neverificat: BleepingComputer nu a confirmat revendicarea; Hudson Rock spune că mostrele au structură de directory autentică, dar datele par vechi.

De ce nu e o „breșă Azure“

Formularea „furate din Azure“ face un serviciu prost cititorului. Sugerează că cineva a spart infrastructura Microsoft. Toate sursele converg spre altceva: nu s-a găsit nicio gaură în platformă. Atacatorul spune că a folosit credențiale valide ca să se autentifice în tenant-urile Azure/Entra ale companiilor și să exporte directorul de angajați.

Diferența e fundamentală în modelul responsabilității partajate al cloud-ului. Microsoft răspunde de securitatea platformei. Clientul răspunde de identitățile și accesul din propriul tenant — parole, MFA, politici de acces. Când cineva intră cu un user și o parolă valide (fie ghicite, fie furate cu un infostealer) și trece de un MFA slab, platforma funcționează exact cum trebuie. N-a fost spartă; a fost folosită cu o cheie legitimă, dar furată.

Tăcerea Microsoft, explicată

De aici și absența Microsoft din poveste. La 17 august 2026 nu există niciun comunicat Microsoft sau MSRC pe subiect — nici confirmare, nici dezmințire. Nu e o scăpare de PR, e consecința logică: dacă platforma nu a fost compromisă, nu e incidentul Microsoft de raportat. Microsoft ar comenta doar dacă ar apărea dovada unei vulnerabilități de platformă — ceea ce nimeni nu a arătat.

Cei care au vorbit sunt companiile vizate, și au minimalizat: Gap a spus că nu are dovezi de breșă și că datele par vechi și nesensibile; TCS a spus că datele par vechi de peste patru ani, fără dovezi credibile de compromitere a sistemelor sale. Prudent, dat fiind că revendicarea e neverificată — dar și convenabil. Adevărul e probabil pe la mijloc: date reale, dar vechi, adunate din tenant-uri prin credențiale, nu dintr-o spargere spectaculoasă.

Veriga slabă: MFA fatigue

Partea utilă pentru un apărător nu e scandalul, ci cum se intră. Doi vectori fac aproape toată munca:

  • Password spray. În loc să atace un cont cu mii de parole (și să-l blocheze), atacatorul încearcă câteva parole comune pe mii de conturi, lent, ca să rămână sub pragul de blocare și de alertă. Îi trebuie un singur cont cu o parolă slabă sau reutilizată.
  • MFA fatigue (push bombing). Odată ce are parola, dacă al doilea factor e o notificare push simplă („Aprobi?“), atacatorul o spamează până când utilizatorul, obosit sau confuz, apasă Aprobă. Al doilea factor devine inutil exact când conta cel mai mult.

Ambele exploatează același lucru: un MFA care se bazează pe un secret ce poate fi ghicit, furat sau aprobat din greșeală. De aici și direcția apărării.

Recomandările noastre

Dacă rulezi identități în Entra/Azure (sau în orice IdP), incidentul ăsta nu cere un patch — cere igiena de identitate care contează oricum:

  • MFA rezistent la phishing: FIDO2 / passkeys, nu push simplu. O passkey nu poate fi nici spray-uită, nici „aprobată din greșeală“ — nu există prompt de apăsat. E răspunsul direct la MFA fatigue. Number matching pe push e un plasture util, nu soluția. Vezi și Entra: passkeys peste SMS și voce.
  • Conditional access. Condiționează accesul de dispozitiv conform, locație și scor de risc. Un login „reușit“ din altă țară, la 3 dimineața, de pe un dispozitiv necunoscut, ar trebui blocat sau provocat, nu acceptat.
  • Detecție de password spray. Autentificări eșuate puține dar constante, pe multe conturi, din aceeași sursă — un tipar pe care monitorizarea centralizată îl prinde, dacă are jurnalele de identitate și retenție.
  • Igienă anti-infostealer. Furtul de sesiuni și token-uri ocolește complet MFA. EDR pe endpoint-uri, invalidarea sesiunilor la risc, și instruire pe cracked software / extensii ostile.
  • Nu confunda responsabilitatea. Platforma e a Microsoft; identitatea, credențialele și politicile de acces sunt ale tale. Aici se câștigă sau se pierde.

Vrei să vezi cât de expus e tenant-ul tău la password spray și MFA fatigue, și dacă ai trecut la MFA rezistent la phishing? Scrie-ne și pornim de la un audit de identitate și acces.

Surse

Întrebări frecvente

E o breșă a Microsoft sau a Azure?

Nu. Nicio sursă nu a identificat o vulnerabilitate în platforma Microsoft. Atacatorul revendică folosirea de credențiale compromise (password spray, MFA fatigue, infostealers) ca să extragă date din tenant-urile Azure/Entra ale clienților. E o problemă de responsabilitate partajată — identitatea clientului, nu platforma Microsoft.

A confirmat sau dezmințit Microsoft?

La data relatării (17 august 2026), Microsoft nu a emis nicio poziție oficială — nici confirmare, nici dezmințire, nici „investigăm". E de așteptat: din perspectiva Microsoft, platforma nu a fost spartă, deci nu e incidentul lor de raportat. Doar companiile vizate au reacționat, contestând (date vechi, fără dovezi de breșă).

Cum au intrat atacatorii?

Prin credențiale valide, nu printr-un exploit de platformă: password spray (parole comune încercate low-and-slow ca să evite blocarea), MFA fatigue (spam de notificări push până cineva aprobă) și, probabil, infostealers care fură sesiuni și token-uri. Autentificarea trece fără să declanșeze alerte de login eșuat.

Cum mă apăr?

MFA rezistent la phishing (FIDO2/passkeys), nu push simplu — push-ul cade la MFA fatigue. Adaugă conditional access (dispozitiv conform, geo, risc), detecție de password spray și igienă anti-infostealer pe endpoint-uri. Platforma e a Microsoft; identitatea și credențialele sunt răspunderea ta.

Articole similare