Înapoi la toate articolele
Awarely Learning
9 min3 surse

BigBear 2.0: cum sunt furate sesiunile Microsoft 365 după autentificarea MFA

CloudSEK afirmă că BigBear 2.0 a folosit phishing de tip adversary-in-the-middle pentru a captura sesiuni Microsoft 365 după finalizarea MFA. Cazul arată de ce apărarea identității trebuie să depășească parola și codul unic.

CloudSEK a publicat o investigație despre BigBear 2.0, o operațiune phishing-as-a-service bazată pe Evilginx2 și orientată către Microsoft 365. Cercetătorii spun că au obținut acces la panoul operatorului și au observat un flux care intermedia autentificarea legitimă, colecta credențiale și captura sesiunea emisă după ce utilizatorul finaliza autentificarea multifactor.

Aceasta este dovadă primară de cercetare, nu un comunicat Microsoft și nici confirmarea fiecărei organizații din set. CloudSEK a raportat 5.137 de înregistrări, 4.148 de cookie-uri de sesiune, 1.032 de parole în clar și 474 de autentificări finalizate cu ocolirea practică a MFA, în peste 40 de țări. Setul de targeting cuprindea 461 de organizații; separat, CloudSEK a precizat pentru BleepingComputer că 258 aveau cel puțin o compromitere finalizată. Categoriile nu trebuie transformate într-un singur număr universal de victime.

02

MFA a fost finalizat, dar sesiunea a fost preluată

Un proxy adversary-in-the-middle nu trebuie să spargă criptografia unui cod unic. El se așază între utilizator și serviciul legitim, retransmite fluxul și așteaptă ca Microsoft să emită sesiunea autentificată. Dacă acel cookie este capturat și reutilizat, atacatorul poate moșteni autorizarea deja acordată browserului.

CloudSEK a raportat și cod personalizat care făcea FIDO2/WebAuthn să pară indisponibil, împingând utilizatorul spre un fallback mai slab. Autentificarea rezistentă la phishing este utilă mai ales când este impusă, nu doar oferită lângă metode phishable. Nici politicile bazate numai pe locație nu sunt suficiente dacă operatorul folosește proxy-uri rezidențiale apropiate geografic.

03

Ce este confirmat, raportat și încă necunoscut

  • Confirmat de CloudSEK din accesul la panou: înregistrările observate, colectarea sesiunilor, infrastructura multi-operator și ținta Microsoft 365
  • Raportat de CloudSEK și clarificat pentru BleepingComputer: cel puțin 258 de organizații aveau o compromitere finalizată în datele analizate
  • Neconfirmat independent pentru fiecare caz: identitatea, impactul final și activitatea ulterioară la fiecare organizație
  • Nestabilit public: cronologia completă, prejudiciul total și dacă fiecare sesiune capturată a rămas utilizabilă
  • Nu susținem că MFA Microsoft a fost spart criptografic; atacul a vizat autentificarea intermediată și sesiunea rezultată
04

Izolează identitatea, apoi investighează sesiunea

  • Revocă sesiunile și refresh token-urile, forțează reautentificarea și resetează credențialele expuse
  • Verifică autentificările Entra ID, starea dispozitivelor, metode MFA necunoscute și rezultatele Conditional Access din intervalul suspect
  • Inspectează reguli de inbox și forwarding, granturi OAuth, activitate Teams, acces SharePoint/OneDrive și schimbări administrative
  • Prioritizează conturile privilegiate și cele ale furnizorilor, mai ales identitățile MSP cu acces la clienți
  • Păstrează logurile, timpii și deciziile înainte ca remedierea obișnuită să șteargă dovezile utile
  • Impune autentificarea rezistentă la phishing și guvernează explicit orice metodă de rezervă
05

Transformă momeala într-un exercițiu organizațional

Trainingul trebuie să exerseze deciziile care rezistă imitației vizuale: verificarea originii înainte de introducerea datelor, oprirea când metoda cu security key dispare și raportarea imediată a unui fallback neașteptat. Exercițiul trebuie să testeze și service desk-ul, deoarece timpul contează când poate fi expusă sesiunea, nu doar parola.

Managementul trebuie să știe cine poate revoca sesiunile tenantului, cine investighează aplicațiile conectate și cine contactează clienții când este implicat un cont al furnizorului. Concentrarea raportată în IT services și MSP transformă identitatea terților într-o problemă de supply chain.

06

Relevanță NIS2, fără scurtături de conformitate

Campania nu stabilește singură încadrarea NIS2 și nu dovedește un incident notificabil. Ilustrează însă controale necesare într-un program matur: acces și autentificare, awareness, răspuns la incidente, risc de furnizor și recuperare bazată pe dovezi. Aplicabilitatea și notificarea depind de organizație, serviciu și impactul real.

Awarely Learning poate exersa deciziile utilizatorului și ale service desk-ului, Awarely Monitor poate atribui acțiuni și păstra dovada închiderii, iar Secretus poate reduce folosirea emailului și chatului pentru materialele sensibile de răspuns. Platformele susțin bucla de control; nu detectează BigBear, nu fac forensic și nu certifică conformitatea.

Surse și verificare

Deschide sursele originale pentru context, actualizări și formularea exactă a afirmațiilor.

AWARELY Intelligence

Continuă documentarea

Vezi toate articolele