Pentru mulți utilizatori și pentru multe firme mici, activarea MFA este privită ca pasul final: ai pus încă un strat de protecție și contul este „rezolvat”. În realitate, unele campanii de phishing moderne nu încearcă doar să fure parola, ci și sesiunea deja autenticată. Aici intră în discuție atacurile de tip Adversary-in-the-Middle, prescurtate AiTM.
Într-un astfel de scenariu, victima ajunge pe o pagină intermediară care imită convingător portalul legitim de autentificare. Utilizatorul introduce parola, aprobă MFA, iar atacatorul urmărește să preia tokenul sau sesiunea rezultată după autentificare. Cu alte cuvinte, problema nu mai este doar compromiterea parolei, ci folosirea unei sesiuni valide după ce MFA a fost deja trecut.
Din perspectivă defensivă, primul semn important este o autentificare reușită urmată rapid de activitate dintr-un context pe care utilizatorul nu îl recunoaște. În loguri, asta poate însemna browser neobișnuit, dispozitiv necunoscut, locație nouă sau schimbări suspecte între proprietățile sesiunii. În documentația Microsoft Entra Identity Protection apar explicit detecții precum Unfamiliar sign-in properties, Suspicious browser, New country, Impossible travel, Anomalous Token, Token issuer anomaly și chiar Attacker in the Middle. Faptul că aceste semnale există separat arată clar că simplul succes al MFA nu înseamnă automat o sesiune sigură.
Al doilea indiciu este nepotrivirea dintre comportamentul utilizatorului și activitatea contului imediat după login. De exemplu, persoana se autentifică din București de pe laptopul de serviciu, dar la scurt timp apar accesări din altă țară, din alt browser sau de pe un dispozitiv care nu respectă profilul obișnuit. Pentru organizații, un astfel de model merită verificat imediat, mai ales dacă vizează conturi cu acces la email, SharePoint, Teams, CRM sau panouri administrative.
Un al treilea semn este apariția schimbărilor post-autentificare care nu au fost inițiate de utilizator. În mediile Microsoft, semnale utile pot include reguli suspecte în inbox, redirecționări neobișnuite de email sau alte acțiuni efectuate după login de o sesiune aparent validă. Acestea nu confirmă singure un caz AiTM, dar cresc serios nivelul de risc atunci când apar împreună cu semnale de sesiune anormală.
Pentru echipele mici, problema practică este că atacul poate arăta „curat”: parola a fost corectă, MFA a fost aprobat, iar accesul pare legitim. Tocmai de aceea, monitorizarea trebuie mutată dincolo de momentul autentificării. Merită urmărite cu prioritate jurnalele de sign-in, alertele de risc, dispozitivele folosite, țările din care apare activitatea și modificările sensibile făcute imediat după login. Dacă un utilizator raportează că „totul a mers normal”, dar apar semnale tehnice neobișnuite, incidentul nu trebuie închis prea repede.
Pe partea de protecție, documentația Microsoft recomandă controale mai puternice decât MFA clasic. Un exemplu este phishing-resistant MFA, unde sunt incluse metode precum FIDO2/passkeys, Windows Hello for Business sau autentificarea pe bază de certificat. Ideea este importantă: dacă metoda de autentificare este legată mai strâns de dispozitiv și de suprafața reală de login, riscul de interceptare printr-o pagină intermediară scade.
Tot în această zonă intră și token protection din Microsoft Entra Conditional Access. Rolul ei este să reducă reutilizarea tokenurilor furate prin legarea sesiunii de dispozitivul pe care a fost emisă. Nu este un remediu universal și are limitări de compatibilitate, dar este un control relevant exact pentru scenariul în care cineva încearcă să refolosească o sesiune obținută după MFA.
Dacă suspectezi un astfel de incident, reacția defensivă trebuie să fie rapidă: revocarea sesiunilor active, resetarea credențialelor, verificarea logurilor de autentificare, controlul regulilor de email și confirmarea dispozitivelor folosite. În paralel, merită verificat dacă utilizatorul a fost păcălit de o pagină intermediară și dacă organizația poate impune metode phishing-resistant pentru conturile sensibile.
Concluzia practică este simplă: MFA rămâne necesar, dar nu mai este suficient ca singur răspuns. În 2026, detecția bună înseamnă să cauți semnele furtului de sesiune după autentificare, nu doar eșecurile de login. Dacă urmărești contextul sesiunii, alertele de risc și metodele de autentificare folosite, ai șanse mult mai bune să observi compromiterea înainte ca ea să devină un incident major.
Surse
- Microsoft Learn – Microsoft Entra ID Protection risk detections
- Microsoft Learn – Token Protection in Microsoft Entra Conditional Access
- Microsoft Learn – Authentication strengths in Microsoft Entra ID
- Microsoft Learn – Enable passkeys (FIDO2) in Microsoft Entra ID
- Microsoft Learn – Anti-phishing policies in Microsoft 365
