CloudSEK a publicat la 7 septembrie 2026 analiza BigBear 2.0, o platformă phishing-as-a-service bazată pe Evilginx2 și configurată pentru Microsoft 365. Cercetătorii spun că au obținut acces administrativ la panoul operațiunii și au observat infrastructura, conturile afiliaților și datele colectate. Mecanismul intermediază autentificarea, captează parola și cookie-ul sesiunii după aprobarea MFA, apoi permite reutilizarea sesiunii în Exchange, Teams, SharePoint, OneDrive sau aplicații conectate prin single sign-on.
Ce spun cifrele și ce nu demonstrează
CloudSEK raportează 5.137 de înregistrări în panou, inclusiv 1.032 de parole în clar, 4.148 de cookie-uri de sesiune și 474 de autentificări marcate drept complet compromise după MFA. Cercetarea indică 3.331 de adrese IP unice din peste 40 de țări. Aceste categorii se pot suprapune și nu trebuie adunate pentru a calcula persoane. Nici numărul adreselor IP, nici numărul înregistrărilor nu reprezintă automat utilizatori sau incidente distincte.
BleepingComputer a cerut o clarificare importantă: 461 reprezintă organizațiile din setul mai larg de țintire, iar 258 organizațiile cu cel puțin un rezultat complet de ocolire a MFA în datele cercetătorilor. Articolul Learning Awarely păstrează această diferență și nu transformă telemetria unui panou infracțional într-un recensământ oficial al victimelor.
Semnalul decisiv pentru utilizator: metoda puternică nu mai este disponibilă
Elementul distinctiv descris de CloudSEK este o modificare JavaScript care face indisponibilă funcția WebAuthn în pagina intermediată. Victima care se așteaptă la passkey sau cheie FIDO2 poate vedea că metoda nu funcționează și este împinsă către parolă, cod, notificare push sau altă opțiune care poate fi interceptată. Atacul nu învinge proprietățile criptografice ale passkey-ului; încearcă să îl scoată din traseu.
- Oprește autentificarea dacă metoda uzuală phishing-resistant lipsește, e declarată incompatibilă sau e înlocuită brusc cu un cod ori o aprobare push.
- Nu continua prin opțiunea alternativă oferită de aceeași pagină. Deschide aplicația dintr-un bookmark cunoscut sau tastează separat adresa oficială.
- Verifică domeniul înainte să introduci primul factor, nu doar după apariția cererii MFA.
- Raportează atât linkul, cât și faptul că passkey-ul ori cheia de securitate nu au fost disponibile; acest detaliu ajută identity și SOC să recunoască tentativa de degradare.
- Dacă autentificarea a fost finalizată, tratează cazul ca posibil furt de sesiune. Schimbarea parolei este utilă, dar nu înlocuiește revocarea sesiunilor și a tokenurilor.
De ce aprobarea MFA nu înseamnă că pagina a fost legitimă
Într-un atac adversary-in-the-middle, pagina malițioasă retransmite în timp real dialogul cu serviciul autentic. Utilizatorul poate vedea o autentificare care pare normală și poate primi o solicitare MFA reală, dar sesiunea rezultată trece prin infrastructura atacatorului. Acesta nu are nevoie să refolosească un cod de unică folosință dacă poate captura și reda cookie-ul sesiunii autentificate.
Microsoft explică faptul că passkey-urile FIDO2 sunt legate de originea serviciului și oferă rezistență la impersonarea verifierului. Dar protecția trebuie aplicată prin politică și susținută de un proces de recuperare sigur. Dacă utilizatorul poate coborî fără control la o metodă phishable, experiența tehnică transmite exact comportamentul pe care atacatorul îl dorește: încearcă altă variantă până intri.
Responsabilități diferite pentru utilizator, help desk, identity și SOC
- Utilizatorul oprește fluxul degradat, păstrează adresa paginii și raportează prin canalul intern cunoscut.
- Help desk-ul nu recomandă dezactivarea passkey-ului și nu emite o metodă temporară într-un apel inbound neverificat. Leagă excepția de un tichet și verifică identitatea independent.
- Identity stabilește unde este obligatorie o forță de autentificare phishing-resistant, limitează metodele de fallback și pregătește revocarea sesiunilor și reînrolarea controlată.
- SOC corelează autentificarea cu domeniul vizitat, proxy-ul sau dispozitivul neobișnuit, accesul la e-mail și fișiere și eventualele reguli de inbox create ulterior.
- Managementul acceptă costul operațional al recuperării sigure și nu cere scurtături pentru conturile executive ori privilegiate.
Tabletop: passkey-ul dispare, iar prezentarea începe în zece minute
Rulează exercițiul în 40–50 de minute cu un utilizator, help desk, identity, SOC, ownerul Microsoft 365 și un manager. Nu folosi un site de phishing real și nu colecta parole sau coduri. Pentru fiecare inject cere o decizie, un owner, un termen și dovada care trebuie păstrată.
- Inject 1 — un director deschide un link despre un document urgent. Passkey-ul nu apare, iar pagina îi cere parola și o aprobare push. Ce face înaintea ședinței?
- Inject 2 — help desk-ul primește cererea de a activa rapid SMS ca metodă alternativă. Cum verifică persoana și cine poate aproba excepția?
- Inject 3 — utilizatorul recunoaște că a finalizat fluxul. Ce sesiuni sunt revocate, ce aplicații conectate sunt verificate și ce dispozitive rămân de încredere?
- Inject 4 — autentificarea apare din aceeași țară și dintr-un furnizor rezidențial, deci alerta geografică nu se declanșează. Ce alte semnale caută SOC-ul?
- Inject 5 — apar accesări de fișiere și mesaje trimise din cont. Cum delimitează echipa faptul confirmat, datele posibil accesate și impactul încă necunoscut?
Indicatorii care arată dacă exercițiul schimbă comportamentul
- Procentul participanților care opresc fluxul când metoda phishing-resistant lipsește.
- Timpul până la raportarea domeniului și a metodei de autentificare oferite.
- Procentul tichetelor în care help desk-ul verifică identitatea pe un canal separat înaintea unei schimbări MFA.
- Timpul până la revocarea sesiunilor, nu doar până la resetarea parolei.
- Acoperirea conturilor privilegiate și executive prin politici care cer autentificare phishing-resistant.
- Calitatea comunicării: diferența dintre țintă, credențială capturată, sesiune compromisă și impact demonstrat.
Cum poate ajuta Learning Awarely
Learning Awarely poate transforma degradarea autentificării într-o decizie exersată pe roluri: utilizatorul oprește și raportează, help desk-ul refuză scurtătura, identity aplică recuperarea sigură, iar managerul susține timpul necesar. Platforma poate măsura alegerile și timpul de escaladare; nu configurează Microsoft Entra, nu revocă tokenuri și nu înlocuiește investigația tehnică.