Spring Ring: Vishing über Microsoft Teams mit dem Ziel, die Kontrolle über die Windows-Domäne zu erlangen

Ein angeblicher Helpdesk-Techniker eröffnet einen Chat in Microsoft Teams, ruft das Opfer an und führt es durch die Installation von Tools für den Fernzugriff. Hinter dem vorgetäuschten Support steckt jedoch eine offensive Operation, die bis zum Domain Controller reichen kann.

Die von Palo Alto Networks als Spring Ring bezeichnete Kampagne wurde am 2. September 2026 bekannt und zielte auf mindestens 150 Nutzer aus mindestens 10 Organisationen. Die beobachteten Aktivitäten fanden zwischen Januar und April statt.

Die Angreifer kombinierten Social Engineering, legitime Software für den Fernsupport, PowerShell-Payloads und NTLM-Relay-Techniken. Im fortgeschrittensten Angriffsweg versuchten sie, einen Domain Controller dazu zu zwingen, sich bei einer von ihnen kontrollierten Infrastruktur zu authentifizieren.

Der gefälschte Helpdesk meldet sich direkt in Teams

Der Angriff beginnt innerhalb von Microsoft Teams – einer Plattform, die viele Beschäftigte automatisch mit vertrauenswürdiger Unternehmenskommunikation verbinden. Die Angreifer erstellen Unterhaltungen unter Anzeigenamen, die an den Helpdesk, den IT-Support oder Supportmitarbeiter erinnern.

Auf den Chat folgt ein Sprachanruf. Der Wechsel zur Sprache ermöglicht es dem angeblichen Techniker, in Echtzeit Druck auszuüben, auf Bedenken zu reagieren und das Opfer durch eine genau festgelegte Abfolge von Aktionen zu führen.

Erfolgreiche Anrufe dauern in der Regel 10 bis 15 Minuten. Die Angreifer zeigen zudem eine gewisse Hartnäckigkeit: Sie wiederholen ihre Kontaktversuche und hinterlassen bei Bedarf Sprachnachrichten.

Das Ziel besteht nicht darin, den Nutzer zu einem einzelnen Klick zu bewegen. Das Opfer wird dazu gebracht, Programme auszuführen, Tools für die Fernadministration zu installieren oder speziell für seine Organisation vorbereitete Dateien zu öffnen.

Das ist ein deutlicher Unterschied zum herkömmlichen Phishing. Der Beschäftigte muss nicht nur eine statische Nachricht bewerten, sondern während eines Gesprächs mit jemandem Entscheidungen treffen, der sich als autorisierter Kollege ausgibt.

Laut einem von CrowdStrike veröffentlichten und in der Analyse der Kampagne zitierten Threat-Hunting-Bericht sollen sich Vishing-Angriffe in der ersten Hälfte des Jahres 2026 verdoppelt haben. Die Zahl stellt jedoch keine unabhängige Bestätigung von Spring Ring dar.

Quick Assist und RMM-Software ermöglichen den ersten Zugriff

Im ersten beobachteten Szenario überzeugt der angebliche Techniker den Nutzer, Windows Quick Assist oder eine RMM-Software zu starten – also ein legitimes Tool zur Überwachung und Fernverwaltung von Geräten.

Administratoren setzen diese Programme normalerweise für den Support ein. Wird die Sitzung jedoch vom Opfer autorisiert, kann der Angreifer die Kontrolle über den Computer erlangen, ohne unbedingt eine Software-Schwachstelle ausnutzen zu müssen.

Nach dem Zugriff führen die Betreiber von Spring Ring eine erste Aufklärung des Hosts und der Windows-Domäne durch. So versuchen sie, die Gerätekonfiguration, den Unternehmenskontext und mögliche Ansatzpunkte für die Fortsetzung des Eindringens zu ermitteln.

Bei einer der analysierten Aktivitäten wurde versucht, einen in PowerShell geschriebenen und verschleierten RAT herunterzuladen. Die Payload hätte dauerhafte Fernzugriffsmöglichkeiten bereitgestellt, doch der Endpoint-Schutz blockierte ihre Ausführung.

Der Name des RAT wurde nicht veröffentlicht. Auch Hashes der Dateien, Domains, IP-Adressen oder andere technische Indikatoren, die sich direkt für eine rückwirkende Suche nutzen ließen, liegen nicht vor.

Dieser Mangel macht verhaltensbasierte Erkennung umso wichtiger. Wer sich ausschließlich auf die Suche nach einer bestimmten Malware-Signatur beschränkt, läuft Gefahr, die Anfangsphase zu übersehen, in der autorisierte Tools und vom Nutzer bestätigte Aktionen zum Einsatz kommen.

Vom versteckten Browser zum NTLM-Relay-Versuch

Der zweite Angriffsweg weist eine komplexere technische Kette auf. Die Angreifer leiten das Opfer zu Dateien weiter, die auf Cloud-Infrastrukturen gehostet und auf den jeweiligen Nutzer sowie die Zielorganisation zugeschnitten sind.

Die ausführbaren Dateien richten einen Persistenzmechanismus ein und starten eine verborgene Instanz von Microsoft Edge. Anschließend laden sie eine Erweiterung per Sideloading, führen eine Aufklärung des internen Netzwerks durch und erzeugen NTLM-Authentifizierungsverkehr.

Die gefährlichste Phase besteht in einem auf PetitPotam basierenden NTLM-Relay-Versuch. Die Technik soll ein Windows-System – in diesem Fall den Domain Controller – dazu bringen, eine Authentifizierung bei einem vom Angreifer kontrollierten Ziel zu initiieren.

Der Angreifer versucht anschließend, diese Authentifizierung an einen anderen Dienst weiterzuleiten und sich damit Privilegien zu verschaffen, über die er nicht direkt verfügt. Gelingt der Vorgang bei entsprechend exponierten Systemen und Konfigurationen, kann sich die Kontrolle vom ursprünglichen Endpoint auf die Identitätsinfrastruktur ausweiten.

Das endgültige Ziel ist besonders sensibel. Ein Domain Controller verwaltet Authentifizierungen, Konten, Richtlinien und Vertrauensbeziehungen der Windows-Umgebung. Wird er kompromittiert, kann dies den Weg zur Kontrolle der gesamten Domäne ebnen.

Der Managed-Detection-Service von Unit 42, einer Abteilung von Palo Alto Networks, blockierte den Versuch, die Infrastruktur zu übernehmen. Der beobachtete Domain Controller wurde daher offenbar nicht tatsächlich kompromittiert.

Umfang und Grenzen der verfügbaren Informationen

Palo Alto Networks zählte mindestens 150 Zielnutzer in mindestens 10 Organisationen. Eine Gesamterfolgsquote wurde jedoch nicht veröffentlicht. Daher lässt sich nicht feststellen, wie viele Opfer die Dateien ausgeführt oder den Fernzugriff gewährt haben.

Die beiden detailliert beschriebenen Versuche wurden gestoppt: Der PowerShell-RAT durch den Endpoint-Schutz und der Angriff auf die Domäne durch den Unit-42-Service. Daraus folgt jedoch nicht, dass jeder mit der Kampagne verbundene Vorfall denselben Ausgang nahm.

Die konkreten Versionen von Microsoft Teams, Windows, Quick Assist oder Edge wurden nicht genannt. Spring Ring wird nicht als Ausnutzung einer Schwachstelle in einer bestimmten Version beschrieben, sondern als Missbrauch legitimer Funktionen in Verbindung mit Social-Engineering- und Windows-Authentifizierungstechniken.

Dementsprechend wurde weder ein entsprechender Patch genannt noch eine der Kampagne zugeordnete CVE. Die Aktualisierung der Systeme bleibt eine notwendige Maßnahme, neutralisiert jedoch keinen Anruf, bei dem der Nutzer freiwillig eine Fernzugriffssitzung autorisiert.

Die verfügbaren Daten stammen aus der Untersuchung von Palo Alto Networks. Eine unabhängige Bestätigung derselben Vorfälle liegt nicht vor.

Spring Ring erkennen und eindämmen

Die erste Gegenmaßnahme besteht darin, den Kontaktkanal von der Identitätsprüfung zu trennen. Eine über Teams eingehende Anfrage sollte nicht allein deshalb als authentisch gelten, weil sie innerhalb einer Unternehmensumgebung erscheint.

Wenn ein angeblicher Techniker dazu auffordert, Quick Assist zu starten, eine RMM-Software zu installieren oder eine Datei auszuführen, sollte der Beschäftigte den Vorgang abbrechen und den Helpdesk über eine bereits bekannte Telefonnummer oder ein bekanntes Portal kontaktieren. Kontaktdaten, die der Gesprächspartner nennt, dürfen dafür nicht verwendet werden.

Organisationen können außerdem auf mehreren Ebenen ansetzen:

• Quick Assist und RMM-Tools auf autorisierte Nutzer, Geräte und Supportabläufe beschränken;
• den Start unerwarteter Fernzugriffssitzungen protokollieren und mit neuen Kontakten in Teams korrelieren;
• verschleiertes PowerShell, ungewöhnliche Downloads, versteckt gestartete Browser und per Sideloading geladene Erweiterungen erkennen;
• ausführbare Dateien überprüfen, die von Cloud-Diensten heruntergeladen wurden – insbesondere, wenn sie personalisiert sind oder während eines Anrufs übermittelt wurden;
• NTLM-Authentifizierungen zu externen Zielen oder nicht genehmigten Systemen analysieren;
• nach Verhaltensmustern suchen, die auf eine Erzwingung der Authentifizierung und Relay-Angriffe hindeuten;
• die Überwachung von Domain Controllern und identitätsbezogenen Anomalien verstärken;
• Beschäftigte mit Sprachsimulationen schulen, nicht nur mit E-Mail-Phishing-Übungen.

Da keine Hashes und öffentlichen Netzwerkadressen vorliegen, sind verhaltensbasierte Indikatoren besonders hilfreich: wiederholte Kontakte durch gefälschte Supportkonten, unerwartete Anrufe, nicht autorisierte RMM-Starts, die Ausführung von PowerShell und ungewöhnlicher NTLM-Datenverkehr.

Die Verfügbarkeitsprobleme von Teams sind separate Vorfälle

Am 4. September 2026 wurden auch Betriebsprobleme bei Microsoft Teams gemeldet. Es gibt jedoch keine Hinweise auf einen Zusammenhang mit Spring Ring.

Der Vorfall TM1466820 kann verhindern, dass der Windows-Desktopclient geöffnet wird, oder das erste Laden um bis zu zwei Minuten verzögern. Microsoft nannte Teams im Web, die mobile App und andere Zugriffsmethoden als vorübergehende Lösungen.

Ein davon unabhängiges Problem mit der Kennung TM1466659 betrifft einige Mac-Nutzer, die nicht an Anrufen oder Besprechungen teilnehmen können. Microsoft analysierte die Logs und überprüfte die Ursache erneut, nachdem zunächst eine Codeänderung als möglicher Auslöser vermutet worden war.

Dabei handelt es sich um Verfügbarkeitsprobleme und nicht um Belege für eine Kompromittierung. Es ist nicht bekannt, dass sie die Spring-Ring-Angriffe verursacht, erleichtert oder verborgen haben.

Die Unterscheidung ist entscheidend: Die Kampagne nutzt das Vertrauen in Collaboration-Tools aus, nicht die gemeldeten Störungen der Clients. Die Abwehr muss sich daher sowohl auf technische Kontrollen als auch auf die Überprüfung von Supportprozessen und Identitäten konzentrieren.