Un dialog Microsoft autentic poate fura tokenul OAuth chiar după MFA

La 23 septembrie 2026, cercetarea Huntress semnată de Andrew Schwartz a prezentat un test pe Windows 11 24H2: un pachet AppX încărcat lateral a deschis prin WWAHost.exe un dialog autentic Microsoft, iar codul OAuth a fost capturat după MFA; Schwartz descrie pasul astfel: «I completed my MFA.» În tenantul său de test, codul a fost schimbat în tokenuri de acces și de reîmprospătare.

În analiza f4n6 publicată în aceeași zi, cazul este încadrat ca demonstrație tehnică, fără o intruziune documentată într-o organizație; sunt propuse și reguli inițiale Sigma și YARA. Pentru administratorii Microsoft 365, punctul decisiv este cine primește rezultatul autentificării: utilizatorul intră pe pagina reală Microsoft, dar aplicația care a pornit fluxul primește codul de autorizare.

Cum iese codul OAuth dintr-un dialog autentic

Pachetul AppX din test a declarat în manifest o regulă ContentUriRules cu WindowsRuntimeAccess="all" pentru o pagină găzduită pe sistemul Kali al cercetătorului. WWAHost.exe, o componentă Windows semnată de Microsoft, a încărcat pagina în gazda aplicației. JavaScriptul de acolo a primit acces la interfețele Windows Runtime, inclusiv WebAuthenticationBroker, care poate lansa un flux OAuth. Faptul că procesul gazdă este semnat nu transformă pagina externă într-o sursă de încredere.

Cererea a folosit identitatea aplicației Microsoft Office și un URI de redirecționare de tip oob, prin care codul de autorizare revine aplicației apelante. Dialogul a afișat login.microsoftonline.com, fără bara obișnuită a browserului; utilizatorul a introdus parola și a încheiat MFA pe infrastructura Microsoft. Brokerul a returnat apoi codul scriptului care inițiase cererea. Acesta l-a trimis receptorului de pe sistemul Kali, unde codul a fost schimbat în tokenuri. Pagina de conectare este legitimă, însă aplicația care inițiază cererea poate controla unde ajunge rezultatul.

Condiția de pe dispozitiv: Developer Mode și pachetul

Lanțul cere mai întâi executarea codului în sesiunea utilizatorului și o configurație Windows care permite înregistrarea pachetului. În test, Developer Mode era activ, iar Add-AppxPackage -Register a înregistrat pachetul fără o nouă solicitare de drepturi de administrator și fără semnarea lui. Activarea Developer Mode necesită însă drepturi de administrator. Când condiția lipsește, comanda din demonstrație este respinsă cu eroarea 0x80073CFF; simpla afișare a unui dialog Microsoft nu ar reproduce atacul.

O distincție contează la inventarierea dispozitivelor: documentația Microsoft despre pachetele Windows cere Developer Mode pentru înregistrarea directă dintr-un folder a unui pachet nesemnat, pe când AllowAllTrustedApps permite instalarea pachetelor semnate cu un certificat în care dispozitivul are încredere. Astfel, prezența politicii de încărcare laterală nu dovedește singură că exact pachetul nesemnat din test poate fi înregistrat prin aceeași comandă. Verificarea trebuie să lege politica activă de tipul pachetului și de semnătura lui, mai ales pe stațiile de dezvoltare și pe sistemele gestionate prin politici de grup.

Ce pot permite tokenurile după autentificarea multifactor

În demonstrație, codul capturat a produs un token de acces și unul de reîmprospătare. Cercetătorul a folosit ulterior tokenul de reîmprospătare pentru a obține un nou token de acces de pe alt dispozitiv și din altă rețea, fără încă un dialog MFA. Persistența depinde de valabilitatea tokenului și de revocarea sa; terminarea sesiunii vizibile pe calculator nu demonstrează că accesul prin token s-a încheiat.

Setul de permisiuni delegate observat includea operațiuni pentru poștă, fișiere OneDrive și SharePoint, conversații și canale Teams, calendar și director. În tenantul de test au fost validate inclusiv citirea profilului utilizatorului și interogări ale directorului prin Microsoft Graph. Totuși, un token delegat poate face doar ceea ce permit împreună permisiunile aplicației și drepturile contului autentificat; Directory.Read.All nu oferă automat rol de administrator. De aceea, impactul unui cod capturat depinde de contul care a parcurs dialogul, nu doar de lista de permisiuni afișată pentru aplicația Office.

Semnale care leagă AppX, WWAHost.exe și accesul la cont

În jurnalul Entra ID, autentificarea din test apărea ca o conectare reușită a aplicației Microsoft Office. Indicatorul de rețea mai util este cererea făcută de gazda AppX către pagina externă: ea purta identificatorul MSAppHost/3.0, în timp ce etapa de conectare Microsoft apărea ca MSAuthHost/1.0. Această diferență permite separarea traficului care duce codul la receptor de traficul de autentificare către login.microsoftonline.com. Un domeniu Microsoft în jurnalul DNS, luat separat, este un semnal prea slab.

• În jurnalele de proces și de instalare, căutați Add-AppxPackage -Register dintr-o cale în care utilizatorul poate scrie, apoi pachetul AppX și procesul WWAHost.exe asociat. Jurnalul AppXDeploymentServer și înregistrarea comenzilor PowerShell pot păstra urmele acestei secvențe.
• În manifest, corelați ContentUriRules și WindowsRuntimeAccess="all" cu o origine externă. O regulă YARA care caută doar această permisiune și WebAuthenticationBroker poate produce alarme pe pachete legitime de dezvoltare; originea și contextul instalării dau sens rezultatului.
• În registru și politici, inventariați AllowDevelopmentWithoutDevLicense și AllowAllTrustedApps. Prima valoare arată configurația Developer Mode folosită în test; a doua cere interpretare împreună cu semnătura și modalitatea de instalare a aplicației.
• În DNS și proxy, corelați WWAHost.exe ori MSAppHost/3.0 cu o destinație din afara infrastructurii Microsoft, apoi comparați momentul cu autentificarea Office și cu accesul ulterior la resursele contului.

Lista domeniilor Microsoft permise într-o regulă de rețea trebuie ajustată la traficul legitim al organizației: unele servicii folosesc domenii care nu se termină în microsoft.com, iar un domeniu permis poate găzdui conținut controlat de altcineva. Politicile Conditional Access care cer un dispozitiv conform pot limita folosirea tokenului de pe un dispozitiv neadministrat; ele nu înlătură capturarea codului pe dispozitivul conform unde a rulat pachetul.

Dacă această secvență este confirmată, eliminarea pachetului nu închide automat accesul obținut prin tokenul de reîmprospătare. Revocarea tokenurilor de reîmprospătare și analiza operațiunilor făcute ulterior în poștă, fișiere, Teams și director devin partea decisivă a răspunsului pentru contul afectat.