Breșa RingCentral și phishingul Greatness: cum recunoști mesajele care fură tokenul MFA

RingCentral a publicat pe 28 iulie 2026 un avertisment despre o campanie sofisticată de inginerie socială care a afectat datele unei părți dintre clienți. Compania spune că a oprit activitatea neautorizată, că nu a mai observat activitate nouă după măsurile de remediere și că platforma principală și serviciile sale au continuat să funcționeze.

Pe 13 august, Have I Been Pwned a adăugat un set verificat asociat incidentului: 1.596.490 de adrese de e-mail unice, împreună cu nume, numere de telefon și adrese fizice. HIBP descrie o campanie de extorcare revendicată de ShinyHunters, dar atribuirea și afirmațiile grupării nu trebuie confundate cu informațiile confirmate direct de RingCentral.

Ce este confirmat și ce rămâne necunoscut

• RingCentral confirmă o campanie de inginerie socială și afectarea datelor pentru o parte limitată dintre clienți; persoanele vizate sunt contactate direct.
• Compania afirmă că incidentul nu a afectat platforma principală și nu a întrerupt serviciile RingCentral.
• HIBP marchează setul drept verificat și numără 1.596.490 de adrese de e-mail unice; această cifră nu înseamnă automat același număr de persoane sau organizații distincte.
• Setul descris de HIBP include e-mailuri, nume, telefoane și adrese fizice. Nu sunt enumerate parole, tokenuri de autentificare sau conținutul comunicațiilor.
• RingCentral nu a publicat vectorul complet de acces, numărul propriu de persoane afectate ori lista tuturor câmpurilor pentru fiecare client.
• ShinyHunters a revendicat campania de extorcare; această atribuire rămâne raportată, nu confirmată de companie în buletinul public.

Atacul observat: voicemail și evaluare de performanță

ZeroBEC a analizat o campanie Greatness care a trimis mesaje ce pretindeau că vin de la RingCentral. Momelile anunțau un voicemail ori o evaluare de performanță și cereau deschiderea mesajului. Unele afișau chiar un banner fals potrivit căruia expeditorul fusese verificat de organizație.

În cazul investigat, mesajele nu treceau verificările normale de autentificare a e-mailului, dar au ajuns în inbox deoarece domeniul furnizorului fusese introdus într-o listă de expeditori de încredere. Excepția configurată de organizație a cântărit mai mult decât semnalele tehnice care indicau falsificarea expeditorului.

• Numele unui furnizor real, sigla și faptul că organizația folosește serviciul nu autentifică mesajul.
• Un banner din corpul e-mailului care spune „verified” sau „safe sender” este conținut controlat de expeditor, nu dovada unei verificări.
• O notificare neobișnuită despre voicemail, HR sau evaluarea performanței se verifică în aplicația deschisă separat, nu prin butonul primit.
• O pagină Microsoft cu brandingul corect al companiei poate fi intermediată de un atacator; aspectul vizual nu înlocuiește verificarea domeniului și a contextului.
• Introducerea unui device code indicat de altcineva poate autoriza dispozitivul atacatorului chiar dacă pagina Microsoft este autentică.

De ce MFA poate apărea ca reușit și contul totuși să fie compromis

Greatness suportă fluxuri adversary-in-the-middle și device-code phishing. În primul caz, pagina atacatorului intermediază autentificarea reală, iar utilizatorul își introduce parola și aprobă MFA. Atacatorul obține tokenul deja autorizat și îl poate reutiliza. În al doilea caz, victima introduce într-o pagină Microsoft legitimă un cod generat pentru dispozitivul atacatorului.

Decizia corectă pentru utilizator

• Nu apăsa butonul din notificarea neașteptată. Deschide separat aplicația RingCentral, portalul HR sau Microsoft 365 dintr-un bookmark cunoscut.
• Verifică dacă voicemailul, evaluarea sau documentul există în aplicația oficială. Absența lui este un semnal clar de raportare.
• Nu aproba MFA și nu introduce un device code dacă nu ai început tu autentificarea pe dispozitivul și în aplicația așteptată.
• Raportează mesajul prin funcția organizației și păstrează e-mailul original; o captură poate pierde anteturile necesare investigației.
• Dacă ai interacționat, spune exact ce ai introdus și ce ai aprobat. Raportarea rapidă este mai importantă decât teama de a fi judecat.

Răspunsul help desk-ului și al echipei de identitate

• Resetează parola când a fost divulgată, dar nu opri răspunsul aici: revocă sesiunile, access tokenurile și refresh tokenurile afectate.
• Verifică autentificările și utilizarea Microsoft Graph, Outlook, Teams, SharePoint și OneDrive după momentul interacțiunii.
• Controlează modificările MFA, aplicațiile autorizate, regulile de forward și consent-urile OAuth apărute după compromitere.
• Auditează excepțiile safe sender. O regulă pentru un furnizor trebuie să ceară autentificare validă, nu să accepte orice mesaj care declară domeniul respectiv.
• Caută mesajul la toți destinatarii și elimină-l controlat, fără să redistribui linkul malițios în comunicarea internă.

Tabletop în cinci injecturi

Rulează exercițiul cu angajați, HR, help desk, identity, SOC și comunicare. Pentru fiecare etapă cere decizia, ownerul, termenul, dovada și criteriul de escaladare.

• Inject 1 — patru angajați primesc simultan un „voicemail urgent” RingCentral. Unul observă că nu există mesaj în aplicație. Cine raportează și cum este oprită distribuirea?
• Inject 2 — un manager primește o falsă evaluare de performanță, cu sigla și numele companiei. Ce canal separat folosește pentru verificare?
• Inject 3 — un utilizator a introdus parola și a aprobat MFA. Ce este revocat imediat și ce loguri sunt păstrate?
• Inject 4 — mesajele au trecut deoarece domeniul furnizorului era allowlistat. Cine poate modifica regula și cum se testează fără a bloca mesajele legitime?
• Inject 5 — un coleg afirmă că „breșa RingCentral a cauzat atacul”. Comunicarea trebuie să corecteze această concluzie, păstrând în același timp avertizarea utilă.

Ce măsurăm după exercițiu

• Procentul participanților care deschid separat aplicația oficială înainte de a interacționa cu mesajul.
• Procentul celor care refuză un device code sau o aprobare MFA pe care nu au inițiat-o.
• Timpul median până la prima raportare și timpul până la eliminarea mesajului din toate inboxurile.
• Timpul până la revocarea tokenurilor, nu doar până la resetarea parolei.
• Numărul excepțiilor de e-mail bazate doar pe domeniu și procentul înlocuit cu reguli care cer autentificare validă.

În Learning Awarely, scenariul poate deveni un modul diferențiat pe roluri: utilizatorii exersează schimbarea canalului, help desk-ul răspunsul după token theft, iar administratorii auditul excepțiilor. Rezultatul urmărit nu este memorarea numelui Greatness, ci reducerea timpului dintre mesaj, verificare, raportare și revocarea accesului.