Microsoft Threat Intelligence a publicat la 2 septembrie 2026 analiza unei campanii de intruziune în care atacatorii folosesc colaborarea externă din Microsoft Teams pentru a se prezenta drept personal IT sau help desk. Utilizatorul este convins să accepte controlul ecranului într-o sesiune Teams ori să pornească Quick Assist și să ofere codul de conectare. După ce primesc acces interactiv, operatorii instalează un pachet MSI malițios și un implant JavaScript care rulează cu ajutorul unui runtime Node.js legitim.
De ce un mesaj într-o aplicație aprobată pare credibil
Atacul nu începe cu un executabil evident și nici cu un domeniu care imită grosolan compania. Începe într-un instrument folosit zilnic, cu o explicație plauzibilă: actualizare de securitate, verificarea contului, filtru anti-spam ori evitarea dezactivării. Microsoft arată că interacțiunea vine dintr-un tenant extern și că Teams afișează indicatoare și avertismente, dar atacatorul încearcă să transforme urgența și conversația directă într-un motiv pentru ignorarea lor.
Odată acceptată sesiunea, instrumentul legitim de suport devine canalul de execuție. Microsoft a observat descărcarea silențioasă a unui MSI prin PowerShell, persistență la nivelul utilizatorului, capturi periodice de ecran, recunoaștere a hostului și a Active Directory și conexiuni WinRM către sisteme importante, inclusiv domain controllers și certificate authorities. Instrumentul legitim nu face acțiunea sigură; identitatea, inițiatorul și scopul sesiunii trebuie verificate separat.
Protocolul de suport pe care fiecare angajat trebuie să-l poată aplica
- Nu acorda control la distanță pentru o solicitare neașteptată, chiar dacă persoana cunoaște nume, roluri sau detalii tehnice interne.
- Verifică numărul tichetului și persoana prin portalul, extensia sau canalul intern pe care îl cunoști deja; nu folosi linkul ori numărul oferit de solicitant.
- Tratează marcajul de utilizator sau tenant extern ca semnal de oprire, nu ca detaliu cosmetic.
- Nu comunica un cod Quick Assist și nu aproba cererea de control până când identitatea și intervenția nu au fost confirmate independent.
- Dacă ai acceptat deja sesiunea, închide-o, deconectează dispozitivul conform procedurii interne și contactează imediat help desk-ul real; nu încerca să cureți singur urmele.
Help desk-ul trebuie să poată demonstra că este chiar help desk
Trainingul angajatului eșuează dacă procesul legitim arată identic cu frauda. Organizația are nevoie de un protocol predictibil: cine poate iniția suport, prin ce canal, cum este legată sesiunea de un tichet, ce informații nu vor fi cerute niciodată și cum poate utilizatorul verifica persoana fără să depindă de aceeași conversație. Microsoft recomandă inclusiv fraze interne de autentificare pentru help desk, alături de verificarea pe un canal cunoscut.
- Help desk: deschide sau confirmă tichetul înaintea sesiunii și explică exact ce control va cere și pentru cât timp.
- Administrator Teams: limitează colaborarea externă la domeniile necesare și verifică dacă indicatoarele pentru expeditori externi sunt vizibile.
- Endpoint și identity: controlează instrumentele RMM permise, aplică acces condiționat și pregătește revocarea sesiunilor și rotația credențialelor expuse.
- SOC: corelează o sesiune de asistență cu lansarea imediată a PowerShell, cmd, WScript, msiexec, runtime-uri portabile sau conexiuni WinRM neobișnuite.
- Management: aprobă excepțiile și stabilește când un incident pornit de la un singur laptop devine investigație la nivel de domeniu.
Tabletop în patru injecturi: de la mesaj la acces în domeniu
Rulează exercițiul cu un angajat, help desk, SOC, identity, endpoint și un manager. Scenariul este defensiv și nu cere executarea vreunei comenzi. Pentru fiecare inject notați decizia, ownerul, canalul de verificare, timpul și dovada care trebuie păstrată.
- Inject 1 — un utilizator extern numit „IT Support” cere urgent o sesiune Teams pentru o actualizare de securitate. Cum verifică angajatul solicitarea?
- Inject 2 — angajatul a aprobat controlul și vede pentru câteva secunde o fereastră PowerShell. Ce oprește, cui raportează și ce nu șterge?
- Inject 3 — endpointul a fost izolat, dar apar conexiuni WinRM și interogări Active Directory. Ce identități și sisteme intră în domeniul investigației?
- Inject 4 — un manager întreabă dacă organizația a fost lovită de ransomware. Cum comunică echipa accesul confirmat, impactul necunoscut și următoarea actualizare?
Ce merită măsurat după exercițiu
- Procentul participanților care folosesc un canal independent înainte de a accepta accesul la distanță.
- Timpul până la identificarea tenantului extern și raportarea conversației suspecte.
- Timpul până la închiderea sesiunii, izolarea endpointului și implicarea echipei de identitate.
- Procentul cazurilor în care resetarea parolei este însoțită de revocarea sesiunilor și evaluarea credențialelor accesibile de pe host.
- Calitatea comunicării: separarea dintre accesul observat, impactul confirmat și consecințele încă posibile.
Cum poate ajuta Learning Awarely
Learning Awarely poate livra același incident sub forme diferite pentru angajat, help desk, administrator, SOC și manager, apoi poate măsura alegerea canalului corect, viteza escaladării și înțelegerea limitelor fiecărui rol. Platforma nu configurează Teams, nu blochează Quick Assist și nu înlocuiește controalele endpoint sau răspunsul tehnic.
Obiectivul nu este ca oamenii să memoreze numele unui implant. Este ca o solicitare de suport să nu poată deveni acces la rețeaua internă doar pentru că apare într-o aplicație familiară și folosește un instrument legitim.