Blog
Inginerie socială5 august 20268 min de citit

Kali365: phishingul care te trimite pe pagina adevărată Microsoft — și de ce MFA nu te salvează

Un kit de phishing folosește fluxul legitim de autentificare prin cod de dispozitiv al Microsoft. Nu există pagină falsă, nu se tastează nicio parolă, iar MFA se completează corect — atacatorul primește tokenurile.

Pe 5 august 2026 a fost documentat public Kali365, un kit de phishing care nu încearcă să îți fure parola. Nu are pagină falsă de login, nu imită domeniul Microsoft și nu are nevoie să treacă de MFA. Îți cere, pur și simplu, să te autentifici pe portalul autentic Microsoft și să introduci acolo un cod pe care ți-l dă el.

Sfatul clasic „verifică adresa din bara de navigare" nu ajută aici: adresa este a Microsoft, certificatul este al Microsoft, iar autentificarea chiar se întâmplă pe serverele Microsoft. Singurul element controlat de atacator este codul pe care îl tastezi.

Cum funcționează, pas cu pas

  • Momeala: o pagină care imită SharePoint, OneDrive sau DocuSign și îți spune că trebuie să te autentifici ca să vezi un document.
  • Redirecționarea: ești trimis la portalul real de autentificare prin cod de dispozitiv al Microsoft și ți se cere să introduci un cod. Codul este generat de atacator, pentru sesiunea lui.
  • Autentificarea: îți introduci datele și confirmi MFA — corect, pe infrastructura Microsoft. Din perspectiva ta, totul a mers bine.
  • Rezultatul: atacatorul primește token de acces și token de reîmprospătare pentru contul tău Microsoft 365.

Fluxul cu cod de dispozitiv există pentru un motiv legitim: dispozitive fără tastatură sau browser — televizoare, imprimante, dispozitive IoT — trebuie să se autentifice cumva. Ai un cod pe ecranul dispozitivului, îl tastezi pe telefon, iar dispozitivul primește tokenul. Atacul constă exclusiv în a te convinge că tu ești cel care aprobă propriul dispozitiv, când de fapt aprobi sesiunea altcuiva.

De ce MFA nu oprește atacul

Pentru că MFA face exact ce trebuie. Tu ești utilizatorul legitim, parola este corectă, al doilea factor este al tău. Nimic nu a fost ocolit — autentificarea a reușit, iar rezultatul ei a fost predat unei sesiuni pe care nu o controlezi. Tokenul de reîmprospătare obținut astfel supraviețuiește schimbării parolei, ceea ce înseamnă că reacția reflexă „schimbă-ți parola" nu închide accesul. Sesiunile trebuie revocate explicit.

Ce obține atacatorul

Acces la email, documente interne, date despre clienți și resurse cloud. De aici drumul obișnuit este frauda financiară: manipularea facturilor și compromiterea emailului de business, unde atacatorul citește corespondența reală și intervine la momentul potrivit într-o discuție despre plăți, de pe adresa autentică a companiei.

Telemetria ANY.RUN indică peste 80 de sesiuni publice legate de campanie în fiecare săptămână. Ținta principală sunt Statele Unite, iar sectoarele vizate includ producția, tehnologia, sănătatea, administrația publică, consultanța și furnizorii de servicii de securitate administrate.

Ce oprește efectiv atacul

  • Blochează fluxul cu cod de dispozitiv acolo unde nu îl folosești. Entra ID permite acest lucru printr-o politică de Conditional Access pe condiția de „authentication flows". Dacă organizația ta nu are dispozitive care chiar au nevoie de el, dezactivarea elimină întreaga clasă de atac dintr-o singură setare.
  • Dacă îl folosești, restrânge-l: permite-l doar pentru grupurile și dispozitivele care îl cer, nu pentru toată lumea, implicit.
  • Monitorizează autentificările prin acest flux. Sunt rare într-o organizație normală, deci un vârf este un semnal bun, nu zgomot.
  • La suspiciune, revocă sesiunile și tokenurile de reîmprospătare, nu doar parola. Altfel accesul rămâne deschis.
  • Passkey-urile și autentificarea legată de dispozitiv reduc suprafața, dar reține că aici problema nu este furtul parolei, ci consimțământul acordat unei sesiuni străine.

Partea de awareness, care este cea grea

Instruirea obișnuită învață oamenii să se uite la adresa site-ului și la lacăt. Aici ambele sunt corecte. Reflexul care chiar funcționează este altul, și trebuie predat explicit: nu introduce niciodată un cod de autentificare pe care nu l-ai generat tu, pe un dispozitiv aflat în fața ta. Dacă un email, un chat sau o pagină web îți furnizează un cod și îți cere să îl tastezi în altă parte, direcția este inversă față de cum trebuie să fie — codurile legitime merg dinspre dispozitivul tău către serviciu, nu dinspre un mesaj primit către tine.

Este aceeași structură ca la ClickFix, unde victima lipește o comandă în Windows+R, sau ca la fraudele cu OTP, unde victima citește codul primit prin SMS unei persoane de la telefon. În toate trei, atacatorul nu sparge nimic — mută o acțiune tehnică în sarcina victimei și o convinge că este normală. Simulările de phishing care testează doar „ai apăsat pe link?" nu antrenează acest reflex.

#phishing#Microsoft 365#device code#OAuth#MFA#BEC#Entra ID#Conditional Access