Wie Angreifer legitime RMM-Tools missbrauchen

Die wichtigsten Erkenntnisse

• Angreifer können Phishing-E-Mails und irreführende Dokumenten-Workflows nutzen, um Nutzer zur Installation legitimer RMM-Software zu bewegen.
• Die Installationskette kann eine getarnte ausführbare Datei, ein MSI-Paket, einen Windows-Dienst, Änderungen an der Firewall und Persistenz im abgesicherten Modus umfassen.
• Security-Teams sollten genehmigte RMM-Bereitstellungen von Software unterscheiden, die infolge ungewöhnlicher Aktivitäten über E-Mail, Browser, Skripte oder temporäre Verzeichnisse installiert wurde.
• Eine effektive Erkennung kombiniert Application Allowlisting mit Telemetriedaten aus E-Mails, Prozesserstellung, Diensten, Registrierungsänderungen, Firewall-Regeln und Netzwerkverbindungen.
• Wiederkehrende Köder und Installationsmuster können dabei helfen, zusammengehörige Kampagnen zu Clustern zusammenzufassen.

Vom Phishing zur Fernsteuerung

Analysten des Threat Intelligence Lab haben eine neue Welle von Kampagnen beobachtet, bei denen legitime Remote-Monitoring-and-Management-Tools als finaler Zugriffsmechanismus eingesetzt werden.

Remote-Monitoring-and-Management-Plattformen (RMM) unterstützen Administratoren bei der Verwaltung einer großen Anzahl von Computern. Sie bieten Fernsteuerung, Software-Bereitstellung, Systeminventarisierung, Dateiübertragung, Befehlsausführung und automatisierte Wartung.

Diese Funktionen bieten auch Angreifern einen sofort nutzbaren Zugangskanal. Statt eine eigene Backdoor zu entwickeln, kann ein Angreifer einen Nutzer dazu bewegen, einen Agenten zu installieren, der bereits die Remote-Administration ermöglicht. Dadurch kann der Angriff eher wie eine nicht autorisierte IT-Bereitstellung als wie eine herkömmliche Malware-Infektion wirken.

Im Laufe des Jahres 2026 beobachteten wir erneut zahlreiche Kampagnen, die legitime RMM-Produkte auf diese Weise einsetzten. Köder und Installationsprogramme änderten sich, die wiederkehrende Angriffskette blieb jedoch klar erkennbar: Vertrauen im Posteingang aufbauen, den Nutzer zur Ausführung bewegen, den RMM-Agenten installieren, Änderungen am Endgerät vornehmen und eine Verbindung zur Remote-Access-Infrastruktur herstellen.

Ein Chase-Köder führte zu FleetDeck

Im September 2026 wurden im Rahmen einer Chase-Kampagne innerhalb weniger Stunden mehr als 80.000 Nachrichten versendet. Die E-Mail gab vor, einen sicheren Kontoauszug bereitzustellen, und leitete die Empfänger zu einer HTML-Datei weiter, die über die GitHub-Infrastruktur für Nutzeranhänge gehostet wurde. Beim Öffnen der Datei wurde Chase_Statement.Viewer.exe heruntergeladen, die anschließend FleetDeck auf dem Endgerät installierte.

Der Dateiname ließ auf einen Dokumenten-Viewer schließen. Das Verhalten der Datei zeigte jedoch etwas anderes. Nach der Ausführung erstellte der Viewer ein MSI-Paket im temporären Verzeichnis des Nutzers und rief msiexec.exe auf. FleetDeck-Komponenten wurden unter C:\Program Files (x86)\FleetDeck Agent\ installiert und als FleetDeck Agent Service registriert. PowerShell-Befehle erstellten eingehende Windows-Firewall-Regeln für den Dienst und die ausführbare Agentendatei. Zudem wurde der Dienst unter dem Registrierungspfad SafeBoot Network eingetragen, sodass er im abgesicherten Modus mit Netzwerkunterstützung ausgeführt werden konnte.

So verlief die FleetDeck-Installation

Nach der Aktivierung fragte FleetDeck den Host über PowerShell und WMI ab. Zu den erfassten Daten gehörten Domäne, Systemstatus, Hersteller und Modell, physischer Arbeitsspeicher, Betriebssystem und Version, BIOS-Seriennummer, Zeitpunkt des letzten Systemstarts, Prozessor, Grafikcontroller, Architektur, Netzwerkadaptertyp, MAC-Adresse, Systemsprache und externe IP-Adresse. Anschließend kommunizierte der Agent mit legitimer FleetDeck-Infrastruktur.

Dieselbe Angriffskette umfasst mehrere RMM-Produkte

Der Chase-Fall ist kein Einzelfall, bei dem Angreifer auf ein Remote-Access-Produkt setzen. Andere Kampagnen nutzten unterschiedliche Köder und Bereitstellungsmechanismen, folgten jedoch derselben operativen Logik: Der Nutzer wird dazu gebracht, ein Dokument, Skript oder Installationsprogramm auszuführen. Anschließend dient ein legitimes Administrationstool als finaler Zugangskanal.

ScreenConnect wurde über vermeintliche Behördenmitteilungen, Updates für Kollaborationsplattformen und Köder zur Dokumentensignatur verbreitet. SimpleHelp wurde installiert, nachdem ein Dropper das Hostsystem analysiert hatte. Eine rechnungsbezogene Kampagne nutzte ein ZIP-Archiv und einen kleinen Batch-Downloader, um einen vermutlich vorkonfigurierten MeshAgent anzufordern und eine vollständige Installation mit Administratorrechten zu starten. Remcos, ursprünglich als legitimes Remote-Administrationstool vermarktet, wurde über verschiedene Angriffsketten mit Archiven, Skripten und Verschleierungstechniken verbreitet.

Die eingesetzten Tools änderten sich, der operative Vorteil blieb jedoch bestehen. RMM-Produkte bieten ausgereifte Funktionen für Persistenz, Systemerkennung, Remote-Ausführung, Dateiübertragung und Überwachung. Zudem können sie mit Herstellerinfrastruktur kommunizieren, die legitim erscheint. Dadurch ist der Verhaltenskontext wichtiger als eine einfache Domain-Blockliste.

Produkt	Bereitstellungskontext
ScreenConnect	Behördenmitteilungen, Updates für Kollaborationsplattformen und Köder zur Dokumentensignatur
SimpleHelp	Social-Security-Köder mit einem als .scr-Datei bereitgestellten Dropper
MeshAgent	Rechnungsbezogenes ZIP-Archiv und Batch-Downloader
Remcos	Angriffsketten mit Archiven, Skripten und Verschleierungstechniken

Die Installationskette erkennen

Unternehmen sollten ein Inventar der Remote-Management-Software führen, die einem legitimen Geschäftszweck dient. Für jedes genehmigte Produkt sollten der erwartete Tenant bzw. das erwartete Konto, die Bereitstellungsmethode, der zuständige Support-Verantwortliche und die Endgeräte dokumentiert werden. Produkte, die für den Geschäftsbetrieb nicht erforderlich sind, sollten durch Richtlinien für Anwendungskontrolle und Endpoint-Security eingeschränkt werden.

Die Erkennung sollte sich anschließend darauf konzentrieren, wie die Software auf das System gelangt ist, wodurch sie gestartet wurde und welche Änderungen unmittelbar danach erfolgten. Nützliche Kombinationen sind beispielsweise:

• ein neuer RMM-Agent, der von einem E-Mail-Client, Browser oder Skriptinterpreter gestartet wird oder aus einem vom Nutzer beschreibbaren temporären Verzeichnis ausgeführt wird; 
• ein Installationsprogramm, das in Downloads oder Temp heruntergeladen und anschließend unter Program Files kopiert wird; 
• ein neuer Dienst, der mit einem RMM-Produkt verknüpft ist und außerhalb des genehmigten Bereitstellungsprozesses eingerichtet wird; 
• Prozessketten wie wscript.exe gefolgt von PowerShell und msiexec.exe oder cmd.exe gefolgt von PowerShell und curl.exe; 
• eingehende Firewall-Regeln, die kurz nach der Installation eines neuen Agenten durch PowerShell erstellt werden; 
• Änderungen an SafeBoot, Run-Schlüsseln, dem Autostart-Ordner oder COM nach einer Interaktion mit einer externen Nachricht. 

Kampagnen clustern, ohne die Attribution überzubewerten

Wir fassen wiederkehrende Kampagnen anhand wiederholter Phishing-Themen, Bereitstellungsmethoden, des Loader-Verhaltens, der RMM-Bereitstellungsmuster und der Wiederverwendung von Infrastruktur in internen Aktivitätsclustern zusammen. Diese Cluster beschreiben beobachtete Vorgehensweisen. Sie benennen keinen konkreten Angreifer.

RMM-Software und Hosting-Infrastruktur können von voneinander unabhängigen Angreifern wiederverwendet werden. Daher reichen die vorliegenden Belege nicht aus, um diese Fälle einer bestimmten Gruppe zuzuordnen. Das Clustering ist dennoch hilfreich: Es verbindet scheinbar voneinander getrennte Vorfälle, macht wiederkehrende Bereitstellungsmuster sichtbar und hilft Analysten zu erkennen, wenn eine bekannte Angriffskette zur Bereitstellung eines anderen Remote-Access-Produkts verwendet wird.

Fazit

Die Chase-Kampagne zeigt, wie schnell aus einem gewöhnlichen Phishing-Köder eine nicht autorisierte Remote-Management-Bereitstellung werden kann. In nur wenigen Schritten führte die Nachahmung einer vertrauenswürdigen Marke den Nutzer zu einer HTML-Datei, einer ausführbaren Datei, einer MSI-Installation, einem Windows-Dienst, Persistenzänderungen und einem aktiven Remote-Access-Kanal.

Die übergeordnete Erkenntnis lautet: Die Marke der Software ist nur ein Teil der Untersuchung. Eine effektive Abwehr kombiniert Software-Allowlisting, kontrollierte RMM-Bereitstellungen und verhaltensbasierte Erkennung entlang der Installationskette. Security-Teams sollten legitime Tools identifizieren, die außerhalb legitimer Abläufe eingesetzt werden, einzelne Kampagnen anhand wiederkehrender Vorgehensweisen miteinander verknüpfen und diese Erkenntnisse für eine frühere und zuverlässigere Erkennung nutzen.

Kompromittierungsindikatoren (IoC)

Die folgenden Indikatoren beziehen sich auf die in diesem Artikel beschriebene Chase/FleetDeck-Kampagne.

Typ	Wert	Beschreibung
URL	https://github.com/user-attachments/files/31489398/Chase_SecureDocument.html?Voka.com	Schädliche URL zum Hosten des Payloads und zur Einbettung in die E-Mail – Chase-Imitation
URL	https://github.com/user-attachments/files/31489398/Chase_SecureDocument.html?Vouka.com	Schädliche URL zum Hosten des Payloads und zur Einbettung in die E-Mail – Chase-Imitation
E-Mail	[email protected]	E-Mail-Adresse, die zum Versand der schädlichen Kampagne verwendet wurde
E-Mail	[email protected]	E-Mail-Adresse, die zum Versand der schädlichen Kampagne verwendet wurde
IP	129.159.94.43	IP-Adresse, die zum Versand der schädlichen Kampagne verwendet wurde
IP	79.127.222.213	IP-Adresse, die zum Versand der schädlichen Kampagne verwendet wurde
IP	23.234.104.111	IP-Adresse, die zum Versand der schädlichen Kampagne verwendet wurde
SHA256	09ccaa4487af73b7f490656e1289acc6f532964498bcaff4cb4b0125384b7093	Chase_SecureDocument.html / Datei, die heruntergeladen wird, wenn das Opfer auf die in der E-Mail eingebettete URL klickt
SHA256	b3d73d532a9b4786dd17b1d1814e9c4fcbc3841f1b4fed1e92a8793ee4980dd6	Chase_Statement.Viewer.exe / Datei, die heruntergeladen wird, wenn das Opfer die HTML-Datei öffnet