Momeli passkey: persistența MFA și investigația cloud
În raportul din 9 septembrie 2026, Microsoft descrie intruziuni cloud observate din mai: momeli despre passkey, acces prin AiTM sau device code, metode MFA adăugate de atacator și activitate Microsoft Graph urmată de colectare de date. Acestea sunt observațiile Microsoft, nu dovada compromiterii unui anumit tenant.
Pentru echipele de identitate și SOC, întrebarea practică este ce acces rămâne după prima alertă. Propunem un mod de lucru care separă autentificarea, persistența și accesul la date, cu responsabil și dovadă pentru fiecare. Pașii operaționali de mai jos sunt recomandări editoriale, de adaptat la mediul organizației.
Ce susțin sursele și ce rămâne necunoscut
În cercetarea proprie publicată pe 10 iulie, Okta documentează aprobarea înșelătoare a înrolării MFA și a recuperării contului, inclusiv momeli despre passkey. Este context independent pentru mecanism; nu confirmă aceleași victime sau aceeași campanie investigată de Microsoft.
Nu atribuim cele două rapoarte unui singur grup și nu deducem un număr de organizații afectate. Folosirea cuvântului „passkey” într-o momeală nu demonstrează compromiterea criptografiei passkey. Un login reușit nu dovedește singur descărcarea documentelor.
Construiește un caz în jurul identității
Alege identificatorul stabil al contului ca punct de legătură între sistemele de investigație. Adaugă tenantul, rolurile, aplicațiile accesibile și perioada verificată. Pentru fiecare export, notează fusul orar, intervalul și sursa. O cronologie cu ore comparabile este mai utilă decât capturi izolate din console diferite.
Împarte cazul între administratorul identității, echipa care gestionează auditul aplicațiilor și coordonatorul incidentului. Stabilește cine poate restricționa contul, cine conservă datele și cine decide revenirea în serviciu. Evită situația în care fiecare echipă presupune că alta a verificat accesul rămas.
Trei verificări care trebuie citite împreună
- ▸Autentificare: compară logările cu activitatea obișnuită a utilizatorului, dispozitivul și rezultatul politicilor. Confirmă cu persoana vizată, printr-un canal cunoscut, dacă a inițiat acțiunea.
- ▸Metode de autentificare: compară starea curentă cu schimbările din audit. Cere o explicație pentru fiecare metodă nouă și verifică dacă momentul coincide cu un tichet legitim.
- ▸Acces la date: stabilește ce operații sunt efectiv înregistrate de aplicații. Separă simpla solicitare de acces de deschiderea, descărcarea sau exportul confirmat. Notează explicit unde lipsește telemetria.
Închide căile de acces, apoi validează recuperarea
Pentru un compromis confirmat, coordonează restricționarea accesului, revocarea sesiunilor și eliminarea metodelor neautorizate cu echipa de răspuns. Verifică separat necesitatea schimbării parolei și a recuperării contului pe un dispozitiv de încredere. Păstrează momentul fiecărei acțiuni și rezultatul obținut.
Revenirea utilizatorului în serviciu trebuie să aibă criterii explicite: metode recunoscute, acces legitim testat și lipsa accesului neautorizat în verificările ulterioare disponibile. Nu declara incidentul rezolvat doar fiindcă parola a fost schimbată. Dacă lipsesc loguri, păstrează limita în concluzie și atribuie o acțiune pentru îmbunătățirea colectării.
Verifică politicile înaintea următorului incident
Microsoft documentează restricționarea device code flow prin Conditional Access. Înainte de aplicare, identifică utilizările legitime, evaluează impactul în modul report-only și definește excepții înguste. Păstrează accesul de urgență controlat și verifică dispozitivele care depind de acest flux.
Pentru înrolarea autentificatoarelor și recuperarea conturilor, revizuiește ce dovadă de identitate este cerută efectiv. Alege un cont de test și un scenariu aprobat cu echipa IT. Înregistrează politica evaluată, rezultatul așteptat și rezultatul observat; diferența dintre ele devine o acțiune cu termen, nu o presupunere de protecție.
Un raport de închidere care poate fi verificat
Păstrează un rezumat cu identitatea afectată, intervalul investigat, metodele eliminate, sesiunile revocate, aplicațiile verificate și limitele de vizibilitate. Pentru date, folosește doar concluzia susținută de audit: acces posibil, acces observat sau descărcare confirmată. Evită includerea conținutului sensibil în tichete generale.
Awarely Monitor oferă context pentru gestionarea vulnerabilităților și evidența deciziilor. Investigația de identitate descrisă aici se execută în Entra, instrumentele de audit și soluțiile de răspuns ale organizației. Păstrează legătura dintre riscul identificat, schimbarea de control și dovada retestării, astfel încât următoarea revizuire să verifice un rezultat concret.
Leagă riscul de control și retestare
Păstrează dovezile deciziilor în fluxul de remediere și folosește instrumentele de identitate și răspuns pentru verificările tehnice.