DragonForce: Missbrauch von Microsoft Teams Relays als C2-Tarnung

The Hacker News berichtet über DragonForce-Akteure, die Microsoft Teams Relays zur Tarnung von Backdoor.Turn-C2-Verkehr missbrauchen sollen. Für Unternehmen ist die Meldung unangenehm, weil legitime Kollaborationsdienste in der Netzwerkanalyse schnell als normal gelten.

Meldung und Einordnung

Die aktuelle Meldung passt in ein Muster, das Administratoren aus vielen Vorfällen kennen: Angreifer nutzen nicht nur einzelne Schwachstellen, sondern alltägliche Betriebswege. Genau deshalb muss die Bewertung über eine reine Produktmeldung hinausgehen. Entscheidend ist, welche Systeme im eigenen Unternehmen betroffen sein können und welche Telemetrie vorhanden ist.

Für kleine Unternehmen ist besonders wichtig, dass Schutzmaßnahmen nicht nur auf dem Papier stehen. Wenn ein Angriff legitime Kanäle, bekannte Dateitypen oder normale Webfunktionen nutzt, braucht es klare Freigabeprozesse, Protokollierung und Zuständigkeiten.

Technische Details für Admins

Technisch geht es um eine Kombination aus aktueller Bedrohung, vorhandenen Basisdiensten und fehlender Sichtbarkeit. Admins sollten deshalb prüfen, welche Logs verfügbar sind, welche EDR- oder Defender-Signale ausgewertet werden und welche Ausnahmen historisch gewachsen sind.

Risiko für KMU und Betrieb

KMU sind nicht automatisch Hauptziel, aber häufig Kollateralschaden oder leichter Einstiegspunkt. Wenn USB-Geräte, Kollaborationsdienste, Webskripte oder Zahlungsprozesse betroffen sind, reicht ein einzelner Virenscanner nicht aus.

Der operative Mehrwert entsteht durch konkrete Prüfungen: Inventar, Konfiguration, Verantwortlichkeit und Nachkontrolle. Die Meldung sollte also als Anlass dienen, bestehende Prozesse zu testen, statt nur eine Nachricht abzuhaken.

Was Admins jetzt prüfen sollten

1. Betroffene Produkte, Dienste oder Prozesse im eigenen Bestand suchen.
2. Vorhandene Logs und Sicherheitsmeldungen für die letzten Tage prüfen.
3. Ausnahmen in Defender, EDR, Firewall, Browser oder Webserver-Konfiguration kontrollieren.
4. Zuständigkeit für Bewertung und Umsetzung in einem Ticket festhalten.
5. Benutzer mit erhöhtem Risiko gezielt informieren, aber nicht mit generischen Warnungen überfluten.
6. Änderungen zuerst in kleiner Gruppe testen, wenn produktive Dienste betroffen sind.
7. Nach Umsetzung prüfen, ob Monitoring weiterhin funktioniert.
8. Offene Restrisiken dokumentieren und mit Frist versehen.
9. Externe Dienstleister oder Shop-Agenturen einbinden, wenn sie Konfigurationen betreün.
10. Vorfallannahmen für den nächsten Notfallplan ergänzen.

Betriebscheck nach der Meldung

Nach der ersten Bewertung lohnt ein kleiner Betriebscheck mit Ticket oder Änderungsprotokoll. So bleibt nachvollziehbar, was geprüft wurde, wer zuständig war und welche offenen Punkte nachlaufen müssen.

1. gibt es ein vollständiges Inventar der betroffenen Systeme?
2. werden Sicherheitsereignisse zentral ausgewertet?
3. sind Ausnahmen begründet und aktüll?
4. ist klar, wer externe Skripte, Teams-Richtlinien oder USB-Regeln freigibt?
5. existiert ein nachvollziehbarer Nachweis für die Prüfung?

Admin-Einschätzung

Aus Admin-Sicht ist die wichtigste Lehre: Angriffe bewegen sich immer stärker durch normale Geschäftsprozesse. Genau dort müssen Kontrollen sitzen, ohne den Betrieb unnötig zu blockieren.

Wer jetzt saubere Standards für Updates, Freigaben, Monitoring und Reaktion etabliert, reduziert späteren Stress. Einzelne Meldungen werden dann nicht zum Ausnahmezustand, sondern zu einem planbaren Sicherheitsvorgang.

Passende Anleitungen auf S-EDV

1. Windows-Installationsmedium erstellen – hilft bei Wiederherstellung und Neuaufbau kompromittierter Windows-Systeme.
2. Linux-Server absichern – ergänzt den Blick auf erreichbare Dienste und Basishärtung.
3. Cloudflare Tunnel für Synology NAS – passt zur Reduktion direkter Exposition und kontrollierter Veröffentlichung.

Quellen

1. The Hacker News: DragonForce abuse Microsoft Teams relays
2. Microsoft Defender XDR
3. CISA Known Exploited Vulnerabilities Catalog