Externer Teams-Kontakt ersetzt die Phishing-Mail

Microsoft Threat Intelligence meldete am 2. September 2026 eine aktive, menschlich gesteuerte Angriffskampagne über Microsoft Teams. Angreifer treten aus einem externen Mandanten als interner IT-Support auf und drängen Beschäftigte zu einer interaktiven Fernwartung. Verwendet werden unter anderem die Steuerungsfreigabe einer Teams-Bildschirmübertragung, Quick Assist oder andere Remote-Monitoring-and-Management-Werkzeuge.

Der Angriff nutzt keine Schwachstelle in Teams. Er setzt darauf, dass ein Benutzer die Kennzeichnung des externen Kontakts und weitere Warnungen übergeht. Vorwände wie ein angebliches Sicherheitsupdate, eine Kontoprüfung oder eine drohende Deaktivierung erzeugen Zeitdruck. Teilweise ergänzt ein Telefonat den Chat, sodass entscheidende Anweisungen nicht im Nachrichtenverlauf stehen.

Signierte Werkzeuge tragen die Angriffskette

Nach der Freigabe des Fernzugriffs lädt der Angreifer per PowerShell ein präpariertes MSI-Paket aus einem Cloudspeicher und installiert es ohne sichtbaren Dialog über Windows Installer. Das Paket legt einen portablen, legitimen Node.js-Laufzeitkern und ein verschleiertes JavaScript-Implantat unter LocalAppData ab. PowerShell, cmd.exe, WScript und später rundll32.exe übernehmen weitere Ausführungsschritte.

Die von Microsoft untersuchten Varianten richteten eine Persistenz im Benutzerkontext ein: entweder über einen Run-Schlüssel unter HKEY_CURRENT_USER oder über eine Verknüpfung im Autostartordner. Beide tarnten sich mit dem Namen EdgeUpdate. Das Implantat empfängt Aufgaben über HTTPS, führt System- und Sicherheitsabfragen aus und erstellt wiederholt Bildschirmaufnahmen.

Anschließend folgt die Active-Directory-Aufklärung. Native Befehle und ADSI-Abfragen erfassen Domänenkonten, Benutzerbeschreibungen und Windows-Server. Der Angreifer prüft erreichbare Systeme und initiiert WinRM-Verbindungen über TCP 5985. Zu den beobachteten Zielen gehören Domain Controller und Active-Directory-Zertifizierungsstellen. Damit wird ein übernommener Benutzerarbeitsplatz zum Ausgangspunkt für Zugriffe auf Identitätssysteme und weitere kritische Server.

Erkennung muss die Abfolge verbinden

Einzelne Bestandteile können im normalen Betrieb legitim sein. Aussagekräftig ist ihre zeitliche Kombination:

  • Ein externer Teams-Chat oder -Anruf gibt sich als IT- oder Helpdesk-Kontakt aus.
  • Unmittelbar nach einer Fernwartung starten vom Benutzerdesktop PowerShell oder cmd.exe.
  • PowerShell schreibt ein MSI in Downloads, AppData oder ein temporäres Verzeichnis; msiexec installiert es still.
  • node.exe oder eine umbenannte Node.js-Datei startet aus LocalAppData und verarbeitet Skripte oder Dateien mit ungewöhnlichen Endungen.
  • WScript, ein EdgeUpdate-Run-Eintrag oder eine gleichnamige Autostartverknüpfung erscheint im Benutzerprofil.
  • ADSI- oder LDAP-Aufklärung, Bildschirmaufnahmen und WinRM-Verbindungen zu vielen internen Systemen folgen aus einem Benutzerprozess heraus.

Teams-, Endpoint-, Identity- und Netzwerk-Telemetrie sollten über Benutzer, Gerät und Zeitfenster korreliert werden. Eine Erkennung, die nur nach unbekannten Binärdateien sucht, greift zu kurz, weil die Kampagne bewusst legitime Laufzeiten und Windows-Werkzeuge verwendet.

Supportzugriff und WinRM begrenzen

Teams External Access sollte auf tatsächlich benötigte und vertrauenswürdige Domänen eingeschränkt werden. Supportkontakte benötigen einen bekannten internen Prüfweg, etwa ein bestehendes Ticket und eine Rückbestätigung über die offizielle Helpdesk-Nummer. Aus einem unerwarteten Chat oder Anruf heraus darf keine Steuerungsfreigabe erfolgen.

Quick Assist und RMM-Werkzeuge sollten nur dort verfügbar sein, wo sie betrieblich erforderlich und überwacht sind. Für privilegierte Anwendungen helfen phishing-resistente MFA, verwaltete Geräte und Conditional Access dabei, den Wert erbeuteter Sitzungen und Anmeldedaten zu begrenzen. Lokale Administratorrechte und wiederverwendbare privilegierte Anmeldedaten auf Benutzergeräten vergrößern dagegen den möglichen Folgeschaden.

WinRM gehört auf autorisierte Managementsysteme und Verwaltungsnetze begrenzt. Verbindungen von Benutzerarbeitsplätzen zu Domain Controllern oder Zertifizierungsstellen sowie WinRM-Aufrufe aus nicht administrativen Prozessen sollten alarmieren. Attack-Surface-Reduction-Regeln und Defender-Netzwerk-, Web- und Cloudschutz müssen kontrolliert ausgerollt und auf wirksamen Blockbetrieb geprüft werden.

Bei einem Treffer ist der Endpunkt zu isolieren und die zugehörige Teams-, Endpoint- und Identitätstelemetrie zu sichern. Sitzungen sind zu widerrufen und alle vom betroffenen System erreichbaren Anmeldedaten zu rotieren; dazu gehören gegebenenfalls auch dort verwendete Domänenadministratorkonten. Zugriffe auf Domain Controller und Zertifizierungsstellen, privilegierte Gruppen, neue Dienste, Aufgaben und Autostarteinträge sind Teil der Incident-Triage.

Der unmittelbare Check: externe Teams-Kommunikation auf notwendige Domänen begrenzen, Fernsupport verbindlich verifizieren und WinRM-Pfade von Benutzergeräten zu Tier-0-Systemen schließen.