Suport IT fals în Teams: de la remote access la WinRM
Microsoft Threat Intelligence a publicat la 2 septembrie 2026 analiza unei campanii operate manual care începe prin Microsoft Teams. Un atacator dintr-un tenant extern se prezintă drept suport IT sau helpdesk și convinge utilizatorul să ofere control asupra dispozitivului printr-o sesiune legitimă de asistență remote. Operatorul instalează apoi un MSI malițios, un runtime Node.js portabil și un implant JavaScript persistent.
Microsoft a observat recunoaștere a hostului și Active Directory, capturi periodice de ecran, execuție prin utilitare Windows legitime și conexiuni WinRM către sisteme cu valoare ridicată, inclusiv controllere de domeniu și autorități de certificare. Nu este o vulnerabilitate în Teams și nu există public un număr de victime sau o atribuire; este abuzul unei colaborări permise și al încrederii acordate suportului.
Lanțul observat, de la conversație la mișcare laterală
Secvența este importantă deoarece aproape fiecare etapă folosește o funcție sau un instrument legitim. Nici Teams, nici Node.js, msiexec, PowerShell ori WinRM nu reprezintă singure dovada unui incident. Corelarea ordinii, identității utilizatorului, căii fișierelor, proceselor părinte și destinațiilor separă administrarea normală de lanțul suspect.
- ▸Un utilizator primește un chat sau apel Teams de la un tenant extern, cu o identitate care imită suportul IT.
- ▸Pretextul cere o actualizare, verificarea contului ori rezolvarea unei probleme și conduce la control remote prin screen sharing sau Quick Assist.
- ▸În sesiunea interactivă, atacatorul folosește PowerShell pentru a descărca și instala silențios un pachet MSI găzduit în cloud.
- ▸Pachetul instalează în profilul utilizatorului un runtime Node.js legitim și un loader care decriptează un implant JavaScript.
- ▸Implantul primește sarcini prin HTTPS, inventariază sistemul și domeniul, face capturi de ecran și lansează componente suplimentare prin utilitare semnate.
- ▸Operatorul inițiază conexiuni WinRM către servere, controllere de domeniu și autorități de certificare, folosind accesul și credențialele disponibile de pe endpoint.
Ce este confirmat și ce nu trebuie presupus
Microsoft spune că a observat campania și publică tehnicile, semnalele și query-urile defensive asociate. Cercetări independente relatate anterior de BleepingComputer descriu un tipar înrudit: apeluri Teams cu suport fals, instrumente remote legitime și malware bazat pe Node.js. Aceste surse susțin existența tacticii, dar nu demonstrează că toate eșantioanele aparțin aceluiași operator.
Nu sunt publicate numărul organizațiilor afectate, țările, numele victimelor sau atribuirea. Microsoft prezintă furtul de date, extorcarea și ransomware-ul ca posibile obiective ulterioare ale unui astfel de acces, nu ca rezultate confirmate în fiecare intruziune analizată. Articolul nu trebuie să transforme această capacitate într-un impact deja produs.
Semnalele defensive care merită corelate
Microsoft oferă query-uri Defender XDR pentru aceste comportamente. Ele trebuie adaptate la retenția și nomenclatura mediului și testate pentru zgomot. O alertă izolată poate descrie activitate administrativă legitimă; mai multe semnale în succesiunea observată cresc încrederea și justifică izolarea rapidă.
- ▸Un chat sau apel extern cu identitate de helpdesk, urmat imediat de screen sharing, Quick Assist sau alt instrument RMM.
- ▸PowerShell pornit într-o sesiune interactivă care scrie un MSI într-un director Downloads, AppData ori Temp, urmat de instalare silențioasă.
- ▸node.exe sau o copie redenumită care rulează din LocalAppData, mai ales cu un loader dintr-o extensie neobișnuită sau lansat de WScript.
- ▸Persistență nouă în cheia Run a utilizatorului sau în Startup, cu nume care imită o actualizare legitimă.
- ▸Enumerări Active Directory, interogări LDAP, inventarierea serverelor și capturi de ecran apărute după sesiunea remote.
- ▸Conexiuni WinRM pe TCP 5985 către multe sisteme, în special atunci când procesul inițiator sau contul nu aparține administrării aprobate.
Răspunsul nu se încheie când sesiunea remote este oprită
Ștergerea MSI-ului sau a implantului demonstrează numai eliminarea unui artefact local. Nu infirmă folosirea credențialelor, persistența suplimentară sau schimbările realizate pe gazdele accesate ulterior.
- ▸Izolează endpointul și păstrează telemetria Teams, Entra, endpoint, PowerShell, instalare MSI, registry și rețea înainte de curățare.
- ▸Identifică tenantul extern, contul, conversația, apelul și instrumentul remote, apoi caută aceleași elemente în întreaga organizație.
- ▸Determină ce credențiale, tokenuri, sesiuni și secrete erau accesibile utilizatorului și proceselor de pe dispozitiv.
- ▸Revocă sesiunile și rotește credențialele aflate în raza plauzibilă de acces; include conturile privilegiate dacă au fost folosite pe host.
- ▸Examinează conexiunile WinRM și autentificările către fiecare sistem intern, nu doar procesele de pe endpointul inițial.
- ▸Dacă au fost vizate controllere de domeniu sau autorități de certificare, tratează identitatea enterprise drept un flux separat de investigație și recuperare.
Controale care reduc șansa repetării
Microsoft recomandă verificarea oricărui contact de suport nesolicitat printr-un canal intern cunoscut. O procedură simplă trebuie să permită utilizatorului să confirme ticketul și identitatea tehnicianului fără a continua aceeași conversație inițiată de persoana necunoscută.
Teams permite administrarea accesului extern și restricționarea domeniilor. Organizațiile trebuie să aleagă politica pe baza nevoilor reale de colaborare, nu să blocheze automat partenerii necesari. Restricția trebuie completată cu etichetele de utilizator extern, raportarea expeditorilor suspecți și monitorizarea anomaliilor de domeniu.
La nivel de endpoint și identitate, limitează instrumentele RMM aprobate, controlează execuția din directoare scrise de utilizator, aplică MFA rezistent la phishing și dispozitive conforme și restricționează WinRM la stații și conturi administrative desemnate. Niciun control singular nu oprește întregul lanț.
Ce dovedește închiderea incidentului
Un status „resolved” fără această rază verificată riscă să închidă numai simptomul vizibil. Dovada trebuie să arate ce a fost observat, ce a fost căutat, ce a fost remediat și ce incertitudine a rămas.
- ▸Cronologia chatului sau apelului, sesiunii remote, execuției, persistenței, recunoașterii și conexiunilor interne.
- ▸Lista endpointurilor, conturilor și sistemelor interne atinse sau infirmate prin telemetrie, cu owner pentru fiecare.
- ▸Dovada izolării și eliminării persistenței, plus rezultatul căutării organizaționale pentru aceleași comportamente.
- ▸Lista sesiunilor revocate și a credențialelor rotite, împreună cu motivul includerii sau excluderii lor.
- ▸Rezultatul investigației pentru WinRM, controllere de domeniu și autorități de certificare.
- ▸Schimbările aprobate pentru politica Teams, instrumentele remote și administrarea WinRM, cu testarea funcțiilor legitime.
Cum ajută MONITOR AWARELY
MONITOR AWARELY nu inspectează conversații Teams și nu detectează implantul Node.js. Poate susține partea operațională a răspunsului: activele și produsele relevante, ownerii, sarcinile de verificare, termenele, excepțiile și dovezile care leagă endpointul inițial de sistemele interne investigate.
Separarea contează: XDR, SIEM, Entra și telemetria Teams produc semnalele tehnice, iar registrul de remediere trebuie să păstreze deciziile și rezultatele până când accesul remote, identitățile și mișcarea laterală au fost evaluate explicit.
Urmărește accesul remote până la fiecare activ și identitate
MONITOR AWARELY ajută la legarea activelor, expunerilor, ownerilor și dovezilor de remediere. Nu inspectează conversații Teams și nu înlocuiește XDR, SIEM, IAM sau investigația criminalistică.