Microsoft Teams IT-support scams zijn de laatste tijd opvallend terugkerend: aanvallers gebruiken externe chat om zich voor IT-personeel uit te geven en slachtoffers te bewegen tot acties die malware of zelfs ransomware mogelijk maken. Wat het extra lastig maakt, is dat het niet draait om een softwarefout, maar om misbruik van vertrouwen.
Volgens een rapport van Arctic Wolf Labs zien onderzoekers honderden gevallen waarin dezelfde aanpak terugkomt: dezelfde (of sterk vergelijkbare) Teams-identiteiten, helpdesk-achtige weergavenamen en vaak ook dezelfde soorten tools voor externe toegang. In dit artikel zet ik de meest voorkomende patronen op een rij en vertaalt dat naar praktische maatregelen voor je organisatie.
Waarom Microsoft Teams IT-support scams zo overtuigend zijn
Het kernidee achter deze scams is simpel: de aanvaller maakt een Teams-identiteit die lijkt op een legitiem IT-kanaal, zodat waarschuwingen bij externe chat minder snel “alarmbellen” laten rinkelen. De berichten komen vaak binnen via externe chat, waarbij gebruikers de indruk kunnen krijgen dat ze met een bekende helpdesk of collega te maken hebben.
Arctic Wolf Labs beschrijft dat het gedrag telkens overeenkomt in meerdere onderdelen: aanvallen maken gebruik van “throwaway tenants” (nieuw aangemaakte of overgenomen Microsoft 365-omgevingen), hanteren IT-thema display names en zetten remote-access tooling in om door te pakken.
De nep-IT persona’s en teams weergavenamen
Een opvallend kenmerk is het gebruik van IT-achtige of vriendelijk klinkende namen die helpen om externe-user waarschuwingen te omzeilen. Daarbij wordt de aanvaller vaak niet herkenbaar als “vreemd”, maar juist als “support” of “IT”.
De onderzoekers noemen onder meer weergavenamen zoals:
- “Help Desk” en “IT Support”
- “HelpDesk Manager” of “HelpDesk Supervisor”
- “IT Service Desk – Liam / Matt / Scott”
- “Enterprise IT & Security (Internal)”
- “IT Tech Support Internal”
- Varianten waarin ook de naam van de organisatie of het domein is verwerkt
In recente iteraties voegen aanvallers bovendien vaker een component toe die lijkt op de eigen organisatie, zodat het bericht nog minder verdacht voelt.
Nieuwe of “fallback” Microsoft 365-domeinen als geloofwaardigheidslaag
Veel van deze Microsoft Teams IT-support scams zijn opgezet met nieuw aangemaakte tenants of overgenomen omgevingen. Daarbij komt een specifieke strategie terug: gebruik van domeinen die lijken op interne IT-infrastructuur.
In 30–40% van de onderzochte gevallen wordt het zogenaamde *.onmicrosoft.com-domein gebruikt. Dat is een vaste fallback die Microsoft genereert bij het aanmaken van een Microsoft 365-tenant. Door de tenantnaam helpdesk- of support-achtig te kiezen, kan zo’n domein geloofwaardig ogen, bijvoorbeeld:
- helpdeskteam365.onmicrosoft[.]com
- itendpoint365.onmicrosoft[.]com
- itcoreportal.onmicrosoft[.]com
- itadmin922.onmicrosoft[.]com
- corporateitservicellc.onmicrosoft[.]com
Daarnaast melden onderzoekers een verschuiving richting betaalde top-level domains (TLD’s) voor het opzetten van fake identiteiten. In de gevallen die ze bekeken, komt ongeveer 50% met “.top”, circa 40% met “.com” en een klein deel met meerlaagse varianten zoals “.com.pl”, “.com.vn” of “.com.br”.
Mail-bombing vooraf: eerst druk creëren, dan Teams
In meerdere gevallen wordt de Teams-chat niet “cold” ingezet, maar voorafgegaan door mail bombing. Daarbij wordt de mailbox overspoeld met honderden bevestigingen van nieuwsbrieven of abonnementen, vaak in korte tijd.
Het doel hiervan is om een kunstmatig gevoel van urgentie te creëren. Kort daarna volgt het IT-support bericht in Teams, waarin de aanvaller zich aanbiedt om het “probleem” op te lossen.
Deze combinatie werkt omdat gebruikers in een stresssituatie sneller geneigd zijn om de volgende stap te volgen, zeker als het bericht vriendelijk en technisch genoeg klinkt.
Van chat naar remote access: handen aan het toetsenbord
De vervolgstap draait om remote toegang. Deze Microsoft Teams IT-support scams richten zich vooral op organisaties waar externe toegang is toegestaan en zetten social engineering in om slachtoffers hands-on-keyboard toegang te geven.
Dat gebeurt via legitiem klinkende remote monitoring & management (RMM) tools, zoals:
- Quick Assist
- AnyDesk
- ScreenConnect (ConnectWise)
- TeamViewer
- Atera
- Zoho Assist
- NetSupport
- LogMeIn
Eenmaal verbonden wordt de sessie gebruikt voor recon, het plaatsen van extra payloads, en in sommige gevallen laterale beweging richting domeincontrollers. Ook kan er een extra RMM-tool worden toegevoegd voor redundantie voordat data wordt geëxfiltreerd en de ransomware wordt uitgerold.
Payloads, omwegen en waarom URL’s soms worden vermeden
Arctic Wolf Labs meldt dat aanvallers niet altijd een URL plakken in Teams. In plaats daarvan navigeren ze tijdens de remote sessie naar de payload. Dat verkleint de kans dat beveiligingsscanning zoals Safe Links / ZAP direct ingrijpt.
Voor detectie benadrukken onderzoekers het belang van endpoint- en identity-telemetrie. Alleen content-scanning van het Teams-bericht is dan niet genoeg, omdat de kritieke stappen plaatsvinden in de remote sessie.
Voorbeeldaanpak: PowerShell, Azure Blob Storage en een Python implant
In een concreet voorbeeld dat Arctic Wolf Labs beschrijft, gaf de aanvaller het slachtoffer instructies om een PowerShell-opdracht uit te voeren. De opdracht moest een bestand downloaden van Microsoft Azure Blob Storage en vervolgens starten.
Wanneer het slachtoffer het MSI-installatiebestand draait, activeert dat een PowerShell-script dat een Python implant uitpakt en uitvoert. Daarna volgt nog een MSI-stap die LDAP-queries uitvoert op Active Directory om computer- en gebruikersobjecten op te halen.
De gestolen informatie wordt vervolgens naar een externe server verzonden. Dit is een illustratie van hoe een ogenschijnlijk “IT-fix” kan omslaan naar een volledige compromittering van informatie en toegang.
Wat je nu kunt doen tegen Microsoft Teams IT-support scams
Omdat dit type aanval draait om vertrouwen en procesmisbruik, moet je maatregelen combineren: beleid, training, technische controles én detectie. Hieronder staan acties die je vaak direct kunt aanscherpen.
Maak het “IT-gedrag” eenduidig
Definieer een helder incidentproces: hoe ziet een echte IT-hulpvraag eruit, en wie mag remote toegang aanvragen? Zorg dat gebruikers weten dat support in de regel geen “directe acties” afdwingt via externe chat zonder verificatie.
Verifieer bij externe chat, zeker bij urgentie
Bij Teams-berichten van helpdesk-achtige accounts: check altijd via een tweede kanaal (bijv. ticketnummer of vast IT-telefoonnummer). Urgente verzoeken—zeker met verwijzing naar “verhelp dit nu”—moeten extra gecontroleerd worden.
Beperk en controleer remote access
Als je remote tools inzet, leg dan streng vast wanneer en door wie verbindingen mogen worden gemaakt. Kijk ook naar logging rond remote sessies: wat start er, wie vraagt het aan en vanaf welke identiteit?
Let op endpoint-signalen na een remote sessie
Omdat aanvallers vaak pas payloads uitrollen tijdens de remote sessie, is het nuttig om na een remote connectie te kijken naar verdachte PowerShell-activiteit, ongebruikelijke installatiepogingen (zoals MSI-gedrag) en contact met externe infrastructuur.
Verbeter identity-telemetrie en context tussen alerts
Arctic Wolf Labs wijst op het belang van context. Idealiter koppelt je detectiesysteem gebeurtenissen aan elkaar: externe chat → remote access → verdachte command execution → gegevensuitvoer. Zo voorkom je dat alerts los “op zichzelf” blijven staan.
Wil je dit soort detectiekoppeling verder vertalen naar de praktijk? Lees dan ook eens Bron: https://thehackernews.com/2026/10/attackers-use-microsoft-teams-it.html
