Falscher IT-Support in Teams – ein Klick öffnet den Weg zum Domänencontroller
Microsoft Threat Intelligence veröffentlichte am 2. September 2026 eine Analyse einer beobachteten Angriffskampagne: Täter kontaktieren Beschäftigte aus einem externen Microsoft-Teams-Mandanten, treten als interner IT-Support auf und bewegen sie zur Freigabe einer interaktiven Fernsitzung. Danach installierten die Angreifer in den untersuchten Fällen ein Node.js-Implantat, erkundeten Active Directory und stellten WinRM-Verbindungen zu hochwertigen Systemen einschließlich Domänencontrollern und Zertifizierungsstellen her.
Der am 3. September veröffentlichte Bericht von TechRadar beschreibt denselben aktuellen Kampagnenablauf vom externen Teams-Kontakt über den Fernzugriff bis zur internen Aufklärung und lateralen Bewegung. Der Klick aus dem Titel ist die Bestätigung der Fernsteuerung: Er kompromittiert nicht automatisch den Domänencontroller, gibt einem externen Operator aber die Kontrolle über den Arbeitsplatz, von dem aus die beobachtete Angriffskette weiterführt.
Vom externen Teams-Kontakt zum Node.js-Implantat
Die Täter umgehen die Warnhinweise von Teams nicht technisch. Der Kontakt bleibt als extern gekennzeichnet, und Teams zeigt beim ersten Austausch Optionen zum Annehmen oder Blockieren. Die Angreifer versuchen stattdessen, diese Signale mit einer glaubwürdig wirkenden Supportrolle und Zeitdruck zu entwerten.
Als Vorwand dienen beispielsweise eine angebliche Sicherheitsaktualisierung, eine Kontoprüfung, ein Problem mit dem Spamfilter oder eine drohende Kontosperre. Der Chat kann durch einen Anruf ergänzt werden. So lassen sich Anweisungen mündlich geben, während im Nachrichtenverlauf weniger verwertbare Hinweise zurückbleiben.
Das Ziel ist eine von der betroffenen Person selbst gestartete oder genehmigte Fernwartung: Sie soll während einer Teams-Bildschirmfreigabe die Steuerung übergeben, Quick Assist öffnen oder ein anderes Werkzeug für Remote Monitoring and Management zulassen. Der Zugriff entsteht damit über eine legitime Funktion, obwohl die Person am anderen Ende nicht zum eigenen Helpdesk gehört.
Nach der Freigabe führt der Operator PowerShell im Kontext der laufenden Sitzung aus. Ein als Update getarntes MSI-Paket wird aus einem Cloudspeicher geladen und ohne sichtbare Installationsoberfläche eingerichtet. Das Paket legt einen Loader und eine verschlüsselte Nutzlast im Benutzerprofil ab; bei Bedarf kommt eine legitime portable Node.js-Laufzeit hinzu, die das entschlüsselte JavaScript-Implantat ausführt.
Keines der beteiligten Programme ist für sich allein ein verlässlicher Alarmgrund. Teams, Fernwartungssoftware, PowerShell, Windows Installer und Node.js haben legitime Einsatzbereiche. Aussagekräftig ist ihre enge zeitliche Folge nach einem unerwarteten externen Supportkontakt.
Jede Stufe hat einen anderen Kontrollverantwortlichen
Der früheste Kontrollpunkt liegt im Helpdesk-Prozess. Eine unerwartete Supportanfrage sollte über einen bekannten internen Kanal bestätigt werden, bevor Fernzugriff gewährt wird. Ein vorhandenes Ticket, ein Rückruf über die intern veröffentlichte Nummer oder eine festgelegte Authentisierungsphrase sind belastbarer als Anzeigename und Profilbild des Kontakts.
Die Teams-Administration entscheidet, welche externen Organisationen Beschäftigte überhaupt erreichen können. Wo offene Kommunikation nicht erforderlich ist, kann der Zugang auf geschäftlich benötigte Domains begrenzt werden. Kennzeichnungen externer Absender sollten sichtbar bleiben; Ausnahmen für Partner benötigen einen klaren Eigentümer und einen überprüfbaren Zweck.
Auf Endgeräten müssen erlaubte Fernwartungswerkzeuge festgelegt und andere Programme blockiert oder mindestens überwacht werden. Hinzu kommen Kontrollen für unerwartete MSI-Installationen und Folgeprozesse aus PowerShell, WScript oder cmd.exe. Besonders auffällig ist eine portable oder umbenannte Node.js-Datei in einem beschreibbaren Benutzerverzeichnis, wenn sie kurz nach einer Fernsitzung unbekannte Daten oder temporäre Skripte verarbeitet.
Für die praktische Zuordnung ergibt sich eine Entscheidungskette:
- Helpdesk: Identität und Anlass jedes unerwarteten Supportkontakts über einen unabhängigen Kanal prüfen.
- Teams-Administration: externe Kommunikation auf erforderliche Organisationen begrenzen und externe Kontakte eindeutig kennzeichnen.
- Endpunktschutz und SOC: Fernwartung, PowerShell, stille MSI-Installation und Node.js-Ausführung als zusammenhängende Sequenz auswerten.
- Identitäts- und Windows-Administration: privilegierte Anmeldedaten auf Benutzergeräten begrenzen und administrative Protokolle nur von festgelegten Verwaltungssystemen zulassen.
Phishing-resistente Mehrfaktor-Authentisierung, verwaltete Geräte und Conditional Access können den Wert erreichbarer Anmeldedaten reduzieren. Sie verhindern jedoch nicht, dass ein Angreifer eine bereits freigegebene Sitzung bedient. Deshalb müssen Identitätskontrollen die Regeln für Support und Fernzugriff ergänzen, nicht ersetzen.
WinRM zeigt den Weg zu den Domänencontrollern
Das Implantat sammelt zunächst Informationen über Rechner, Region, Sicherheitsprodukte und Virtualisierung und fertigt wiederholt Bildschirmaufnahmen an. Danach folgen Abfragen von Domänenkonten, Benutzern und Servern mit nativen Windows-Werkzeugen und Active Directory Service Interfaces. Weitere Nutzlasten können über vertraute Windows-Binärdateien ausgeführt werden.
In der entscheidenden späteren Phase initiierte die Node.js-Hintertür interne WinRM-Verbindungen über TCP-Port 5985. Die beobachteten Ziele umfassten zahlreiche domänengebundene Systeme, darunter Datei-, Datenbank- und Anwendungsserver sowie Domänencontroller und Zertifizierungsstellen. Belegt sind damit Verbindungsversuche beziehungsweise laterale Bewegung zu diesen Systemen, nicht deren vollständige Übernahme in jedem Fall.
Eine pauschale Warnung für jede WinRM-Nutzung wäre in Umgebungen mit legitimer Windows-Fernverwaltung zu unspezifisch. Deutlich stärker ist das Signal, wenn die Verbindung von einem gewöhnlichen Arbeitsplatz oder einem nicht administrativen Prozess zu einem Identitätssystem ausgeht und kurz zuvor eine externe Teams-Kommunikation, Fernsteuerung, PowerShell-Ausführung, stille MSI-Installation und Node.js-Aktivität auf demselben Gerät aufgetreten sind.
Administrativ sollte WinRM zu Domänencontrollern und Zertifizierungsstellen nur aus definierten Verwaltungsnetzen oder von autorisierten Managementsystemen erreichbar sein. Die Überwachung muss deshalb nicht nur Ziel und Port, sondern auch Quellgerät, Benutzerkontext, auslösenden Prozess und die vorausgehende Fernwartungssitzung zusammenführen.
Was bestätigt ist – und was offenbleibt
Öffentlich dokumentiert sind die technische Angriffskette und die beobachteten Bewegungen zu zentraler Identitätsinfrastruktur. Nicht öffentlich benannt sind die verantwortliche Gruppe, die Zahl der betroffenen Organisationen, einzelne Opfer, Branchen- oder Länderschwerpunkte. Eine besondere Konzentration auf Deutschland, Österreich oder die Schweiz lässt sich daher nicht ableiten.
Domänenaufklärung und Zugriffe auf Identitätssysteme können groß angelegtem Datendiebstahl, Erpressung oder Ransomware vorausgehen. Die beschriebenen Beobachtungen belegen jedoch nicht, dass jeder untersuchte Einbruch mit Datenabfluss oder Verschlüsselung endete. Der gesicherte Befund bleibt enger: Eine freiwillig genehmigte Support-Sitzung kann den ersten Zugriff liefern, anschließend führen MSI- und Node.js-Staging sowie WinRM bis an Systeme heran, die für die Kontrolle einer Windows-Domäne zentral sind.
Lesen Sie auch:
Newsletter abonnieren
Erhalten Sie die neuesten Nachrichten zu Web3, KI und Krypto direkt in Ihren Posteingang.