Bij een recente aanval deden criminelen zich voor als IT-support op Microsoft Teams. Via slimme social engineering kregen ze medewerkers zo ver dat ze remote control toestonden. Daarna draaide het niet om een fout in Teams zelf, maar om insecure Active Directory Certificate Services (AD CS)-instellingen waarmee aanvallers certificaten voor bevoorrechte accounts wisten te bemachtigen.
Het resultaat: in één van de twee onderzochte intrusies werd bedrijfsdata naar een externe server gekopieerd. Het rapport van Microsoft laat vooral zien hoe een kleine combinatie van menselijk vertrouwen en verkeerde certificaatconfiguratie kan leiden tot langdurige toegang.
IT-support fraude Teams: zo begonnen de aanvallen
Beide incidenten startten volgens Microsoft op dezelfde manier. Aanvallers namen contact op via Teams en belden of berichtten medewerkers terwijl ze zich voordeden als de eigen helpdesk of IT-afdeling. Daarbij werkten ze vanuit externe tenants en kozen namen die “support-achtig” klonken, zodat de kans groter werd dat werknemers de contactpersoon vertrouwden.
Concreet stuurden ze aan op een Windows-ondersteuningsroute: de medewerkers moesten Quick Assist openen, de bijbehorende verbindingcode voorlezen en daarmee de aanvaller hands-on toegang geven tot de pc.
Een update-map als dekmantel
Toen de aanvallers de werkplek onder controle hadden, plaatsten ze een archief in de map Downloads. Vervolgens pakten ze die inhoud uit in een nieuwe map die qua naam leek op een echte Windows-update. Daarna startten ze de inhoud met een portable runtime.
Microsoft benadrukt dat bestandsnamen alleen geen betrouwbaar signaal zijn. In ten minste één geval werd dezelfde runtime-achtige payload anders genoemd, maar bleken de versiegegevens nog steeds overeen te komen met echte runtime-componenten.
Waarom AD CS zo waardevol is voor aanvallers
AD CS is in Windows-omgevingen de rol die certificaten uitreikt voor gebruikers en computers. Bij in de praktijk vaak voorkomende misconfiguraties kunnen certificaten betekenen dat de houder zich kan aanmelden als het account dat in het certificaat wordt opgegeven.
In deze gevallen bleef het certificaat ook bruikbaar nadat een wachtwoord werd gereset of nadat de eerste machine waarop de aanvaller binnenkwam was “gewiped”. Dat maakte de aanval extra lastig om meteen uit te schakelen: je zet een stap terug, maar de identiteitstoegang kan blijven bestaan.
Casus 1: ESC1 misbruik en een “uitgesloten” privileged account
Bij de eerste intrusie vonden de aanvallers een certificaatsjabloon met een zwakte die bekendstaat als ESC1. Het kenmerk van dit soort sjablonen is dat een aanvrager kan bepalen voor welk account het certificaat bedoeld is. Daardoor kon een aanvaller met een laag bevoorrecht account toch certificaten aanvragen die stonden voor hoogprivileged accounts.
De eerste golf richtte zich op drie gebruikers en één workstation. Daarmee werden certificaten gegenereerd voor drie zeer bevoorrechte identiteiten. Microsoft Defender wist het grootste deel automatisch te stoppen en ook actieve sessies te onderbreken.
Er zat echter één cruciaal verschil in de respons: een privileged account was niet geraakt door de automatische maatregel. Daardoor bleef dat account bruikbaar.
Van certificaat naar domeincontroller
Circa 90 minuten later volgde een grotere golf. Nu gingen aanvallers te werk richting 16 gebruikers en een tweede workstation, met certificaten voor acht aanvullende bevoorrechte accounts. Volgens Microsoft werden daarna meer dan 1.000 vervolgpogingen geblokkeerd om via SMB bestanden te benaderen of om in te loggen.
Toch konden aanvallers vrijwel direct nadat ze het certificaat hadden, inloggen op een domeincontroller en daar DCSync uitvoeren. Met DCSync kan passworddata uit Active Directory worden gekopieerd. De operatie was al begonnen voordat de containment effectief werd; hoeveel precies werd verkregen, communiceerde Microsoft niet.
Het “openstaande” account gebruikte vervolgens data-transfer
Het account dat buiten de automatische disruptie viel werd niet direct uitgefaseerd. Microsoft beschrijft dat de aanvaller daarmee naar een fileserver ging en daarna een gemaskeerde versie van Rclone gebruikte om data van een share te verplaatsen naar een externe SFTP-locatie.
Ook hier gaf Microsoft geen exacte hoeveelheid data vrij die is meegenomen. Wel is het leerpunt glashelder: gedeeltelijke identity-containment kan de aanval beperken, maar laat soms een “levensvatbare” privileged route open als één identiteit niet wordt afgevangen.
Casus 2: ESC8 via PetitPotam en een certificaat voor de domeincontroller
De tweede intrusie begon opnieuw met de Teams- en Quick Assist-aanpak. Maar omdat het certificaatsjabloon daar niet dezelfde ESC1-zwakte had, koos de aanvaller een andere route.
De criminelen gebruikten PetitPotam om een domeincontroller te dwingen authenticatie uit te voeren richting een machine die zij beheerden. De resulterende NTLM-aanmelding werd vervolgens doorgestuurd naar de AD CS web enrollment-pagina. Dat doorgeven heet ESC8.
Met die relayed login kon de aanvaller een certificaat aanvragen voor de domeincontroller zelf. Daarna, met Kerberos via PKINIT, konden ze een ticket aanvragen dat langdurige toegang bood: wat begon als een eenmalige relay werd zo een bruikbare identiteit.
Waarom deze keer containment wél werkte
In deze tweede casus hield de reactie stand. Microsoft meldt dat Defender ESC8-alerts triggerde. De klant isoleerde vervolgens de workstation. Daarna volgde geen verdere activiteit.
Het verschil tussen casus 1 en 2 kwam volgens Microsoft neer op containment: in het eerste incident blokkeerde automatische disruptie het merendeel, maar bleef één account bruikbaar. In het tweede incident stopte isolatie van één workstation de aanval in de kern.
Wat je als verdediger kunt doen (zonder “patch” te verwachten)
Microsoft benadrukt: er is in deze scenario’s geen softwarefout in Teams waar je simpelweg een update op draait. Het probleem zit in configuratie en reactie. Dat maakt het des te belangrijker om zowel de menselijke als de technische kant te verankeren.
- Laat supportverzoeken verifiëren via een bekend intern kanaal voordat je scherm deelt of remote control toestaat.
- Beperk externe Teams-tenants die werknemers kunnen benaderen en sta alleen goedgekeurde remote-support tools toe.
- Herzie certificaatsjablonen: verwijder rechten die niet nodig zijn en kijk specifiek naar sjablonen die aanvragers laten bepalen welk account wordt opgenomen, of die te veel inschrijvingen toestaan.
- Hardening van AD CS web enrollment: Microsoft adviseert HTTPS en Extended Protection for Authentication (EPA) op web enrollment endpoints. Waar mogelijk: NTLM uitschakelen op die endpoints. Microsoft verwijst naar KB5005413 voor implementatie, en stelt dat Defender for Identity posture checks templates en endpoints kunnen flaggen voor ESC1 en ESC8.
- Activeer certificaat auditing. Als een slecht certificaat is uitgegeven, revok eer het. Houd er wel rekening mee dat revocation al uitgegeven Kerberos-tickets niet automatisch “ongedaan” maakt; je moet die actieve tickets apart beoordelen.
- Behandel “niet-afgevangen” identiteiten als bewuste beslissingen: wat buiten automatische containment valt, moet je handmatig afhandelen met een vooraf bepaalde actie.
Wat al bekend is, en wat dit rapport toevoegt
Microsoft koppelde de aanvallen niet aan een concreet, benoemd actor-grup. Ook gaf het bedrijf geen exacte datum van uitvoering.
De gebruikte technieken zijn niet nieuw: onderzoekers noemden de certificate weaknesses achter ESC1 en ESC8 al in 2021. PetitPotam werd in datzelfde jaar openbaar beschreven. Verder documenteerde Microsoft zelf eerder in 2026 de Teams helpdesk-naar-remote-access methode.
Wat het rapport vooral toevoegt, is het realistische “samenkomen” van de technieken in twee intrusies, inclusief het belangrijke inzicht rond het uitgesloten privileged account dat alsnog toegang kon blijven geven.
Detectie: waar je op kunt jagen
Het Microsoft-rapport bevat signalen uit meerdere hoeken: alerts rond Teams, endpoint-activiteiten en identiteitsobservaties. Daarnaast publiceerde Microsoft vier advanced hunting queries die volgens hen “starting points” zijn, geen definitief bewijs op zichzelf.
Verder deelt Microsoft drie bestands-hashes die gekoppeld zijn aan de scripts die bij de initial access worden gebruikt. Als je intern onderzoek doet, kan dat helpen bij het afbakenen van de initiële fase, maar het blijft raadzaam om vooral naar gedragspatronen en authenticatiesporen te kijken.
Gerelateerde waarschuwingen: remote support en netwerkactie
Als je dit soort incidenten wilt verkleinen, loont het om ook te kijken naar andere signalen rondom aanvallen op netwerk- en transportniveau. Eerder berichtten we over de sterke stijging van Network-layer DDoS en hoe je signalen herkent. Dat is een andere dreiging dan AD CS, maar de kern is vergelijkbaar: snelle herkenning en juiste isolatie maken het verschil.
Verder kun je leren van eerdere incidenten met Teams-achtige toegangsmanipulatie. Zo zagen we ook meldingen rond AI- en code-extensies die via aanvankelijke toegang tot systemen konden leiden, zoals een malafide Claude Code-extensie in Cursor. Ook daar staat het belang van snelle triage en het beperken van “toegang op basis van vertrouwen” centraal.
Conclusie
De kern van IT-support fraude Teams is dat aanvallers niet proberen Teams te hacken, maar medewerkers te overtuigen om remote control toe te staan via Quick Assist. Vervolgens gebruiken ze zwakke AD CS-configuraties om certificaten te verkrijgen waarmee privileged identiteiten alsnog te bereiken zijn.
Wie dit wil voorkomen, moet daarom twee lijnen tegelijk aanpakken: strengere verificatie van supportcontact en technische hardening van AD CS, plus een responsplan dat ook rekening houdt met het scenario waarin containment niet alle privileged accounts afvangt. Dat is het verschil tussen “bijna stoppen” en echt uitschakelen.
Bron: https://thehackernews.com/2026/11/attackers-pose-as-it-support-on.html
