BlueVoyant analysiert neue Angriffskette über Microsoft Teams

Angreifer müssen Malware nicht zwangsläufig technisch revolutionieren, um Sicherheitsmechanismen zu umgehen – oft reicht es, ihre Auslieferung intelligenter zu tarnen. BlueVoyant hat eine neue Angriffskette rund um die FireClient-Backdoor analysiert , bei der Microsoft Teams, legitime Anwendungen, DLL-Sideloading und AWS-Infrastruktur zusammenspielen. Der Fall zeigt exemplarisch, warum klassische Signaturen und reputationsbasierte Kontrollen gegen zunehmend legitim wirkende Angriffsketten an Grenzen stoßen.

Von Microsoft Teams zum Fernzugriff

Das Security Operations Center (SOC) von BlueVoyant beobachtet seit mehreren Monaten verstärkt Social-Engineering-Angriffe über Microsoft Teams. Dabei kontaktieren die Angreifer ihre Opfer über die Kollaborationsplattform und versuchen, sich beispielsweise als IT-Support auszugeben.

Ziel ist es zunächst, Nutzer dazu zu bewegen, über legitime Fernwartungswerkzeuge wie Microsoft Quick Assist Zugriff auf das jeweilige Endgerät zu gewähren. Ist dieser Zugang hergestellt, beginnt die eigentliche Kompromittierungsphase: Die Täter installieren zusätzliche Werkzeuge, sichern Persistenz, sammeln Zugangsdaten und untersuchen die erreichbare Netzwerkumgebung.

Anschließend folgen typischerweise laterale Bewegungen und die Ausweitung von Berechtigungen.

FireClient kommt jetzt per MSI-Paket

BlueVoyant zufolge hat sich insbesondere die Auslieferung der FireClient-Backdoor weiterentwickelt. Während frühere Varianten Firefox-Profile missbrauchten, setzen die Angreifer mittlerweile auf Windows-Installer-Pakete im MSI-Format.

Diese enthalten eine portable Version der Multimedia-Anwendung Kodi. Wird kodi.exe ausgeführt, lädt die Anwendung über DLL-Sideloading eine manipulierte zlib.dll.

Die schädliche Bibliothek behält dabei die Export-Tabelle der legitimen DLL bei und erfüllt damit weiterhin die von Kodi erwarteten Abhängigkeiten. Gleichzeitig wird die Programmausführung auf einen eingebetteten FireClient-Loader umgeleitet.

Genau diese Kombination ist für Verteidiger problematisch: Nach außen startet zunächst eine legitime Anwendung, während der Schadcode im Hintergrund über eine manipulierte Bibliothek eingeschleust wird.

AWS-Infrastruktur erschwert die Netzwerkerkennung

Nach der Ausführung sammelt der Loader zunächst Informationen über das kompromittierte System. Dazu gehören unter anderem Gerätename, laufende Prozesse, Netzwerkkonfiguration und Benutzerinformationen.

Anschließend nimmt er Verbindung zu einem fest kodierten Command-and-Control-Server auf. In den von BlueVoyant untersuchten Fällen befand sich diese Infrastruktur hinter REST-API-Endpunkten des AWS API Gateway.

Damit verschiebt sich ein wesentlicher Teil der Tarnung auf die Netzwerkebene.

HTTPS-Verbindungen zu AWS-Diensten gehören in vielen Unternehmen zum normalen Datenverkehr und lassen sich nicht pauschal blockieren. Der schädliche Traffic kann deshalb legitimer API-Kommunikation ähneln und klassische reputations- oder infrastrukturbasierte Erkennung erheblich erschweren.

Erhält der Loader einen entsprechenden Befehl, öffnet er auf localhost einen Listener auf einem zufällig gewählten Port und entpackt anschließend die eigentliche FireClient-Backdoor.

Bei einem analysierten Angriff wurde die zweite Stufe unter dem Namen „Module Agent.exe“ in einem normalerweise Kodi zugeordneten Verzeichnis gespeichert. Die Platzierung zwischen legitimen Programmdateien dürfte bewusst gewählt worden sein, um eine manuelle Analyse zusätzlich zu erschweren. Angreifer passen ihre Werkzeuge an das Zielsystem an

Besonders interessant ist das Vorgehen nach der ersten Kompromittierung.

In einem von BlueVoyant beobachteten Fall begannen die Angreifer zunächst mit der Erkundung des internen Netzwerks und führten LDAP-Abfragen durch, um weitere Systeme und potenzielle Ziele zu identifizieren. Nachdem gültige Zugangsdaten erbeutet worden waren, nutzten sie RDP-Verbindungen, um auf kritische Server überzugreifen. Dabei verwendeten sie jedoch nicht überall denselben FireClient-Loader.

Stattdessen wurde die Malware gezielt an die jeweilige Serverumgebung angepasst. Auf einem System tarnten die Angreifer den Loader beispielsweise als Bestandteil der VMware Tools. Hierzu wurde eine manipulierte hgfs.dll in das echte VMware-Tools-Verzeichnis eingeschleust.

Beim Start der vertrauenswürdigen Anwendung vmtoolsd.exe lud diese anschließend die präparierte DLL und führte dadurch den FireClient-Loader aus.

Auf einem weiteren Server kam dieselbe Technik mit dem legitimen Nagios Cross-Platform Agent (NCPA) zum Einsatz. Die Angreifer platzierten dort eine manipulierte vcruntime140_1.dll, die beim Start der legitimen Anwendung per DLL-Sideloading geladen wurde.

Das Prinzip bleibt identisch: Die sichtbare Anwendung ist legitim, die nachgeladene Bibliothek jedoch nicht.

Eigenes Werkzeug übernimmt die Datenexfiltration

Zur Exfiltration der erbeuteten Daten nutzten die Angreifer schließlich ein eigenes Tool namens „multiplefolders.exe“.

Dabei handelt es sich laut BlueVoyant um eine mit PyInstaller erstellte Datei, die lokale Datenträger rekursiv durchsucht und gefundene Dateien an eine fest eingebettete AWS-Adresse überträgt.

Auch hier spielt Cloud-Infrastruktur den Angreifern in die Hände. Datenverkehr zu großen Cloud-Plattformen ist in Unternehmensnetzwerken alltäglich und lässt sich daher nicht ohne Weiteres als verdächtig einstufen. Nicht die Malware wird raffinierter – sondern ihre Tarnung Die aktuellen FireClient-Kampagnen zeigen eine Entwicklung, die über diese einzelne Malware-Familie hinausweist.

Die Angreifer verändern nicht zwangsläufig die Kernfunktionen ihrer Schadsoftware. Stattdessen optimieren sie deren Auslieferung, Platzierung und Kommunikation so lange, bis sich die Angriffskette möglichst unauffällig in normale Unternehmensprozesse einfügt.

Kodi, VMware Tools und NCPA dienen als vertrauenswürdige Ausführungshüllen. AWS-Infrastruktur sorgt für legitim wirkenden Netzwerkverkehr. DLL-Sideloading verschiebt die Schadcode-Ausführung in Prozesse, die auf den ersten Blick keinen Alarm auslösen müssen. Damit sinkt gleichzeitig der Wert isolierter Indicators of Compromise.

Verhaltensbasierte Detection wird entscheidend

Für Security-Teams folgt daraus eine klare Konsequenz: Die Verteidigung darf sich nicht ausschließlich auf bekannte Malware-Hashes, einzelne Dateien, Domains oder IP-Adressen konzentrieren.

Eine portable Anwendung, die plötzlich außerhalb ihres üblichen Installationspfades auftaucht, ungewöhnliche DLLs lädt und anschließend Cloud-APIs kontaktiert, kann beispielsweise deutlich aussagekräftiger sein als jede einzelne Komponente für sich.

BlueVoyant hat deshalb gezielte Erkennungsmechanismen für die beobachteten Techniken entwickelt. Dazu gehören Regeln für verdächtige Kodi-Installationen und Aktivitäten außerhalb typischer Programmverzeichnisse sowie Detection-Logik für auffällige Microsoft-Teams-Kommunikation externer Nutzer und mögliche IT-Support-Impersonation. Der FireClient-Fall unterstreicht damit einen grundsätzlichen Wandel moderner Angriffstechniken: Cyberkriminelle versuchen zunehmend nicht mehr, vollkommen unsichtbar zu werden. Sie versuchen vielmehr, möglichst legitim auszusehen.