Network
Missbrauch vertrauenswürdiger Software
Angreifer installieren und betreiben einen umkonfigurierten ScreenConnect-Client als verdecktes Remote Access Tool. Unsere Fallbeispiele zeigen, wie der Missbrauch vertrauenswürdiger Software funktioniert und welche Abwehrmaßnahmen dagegen helfen.
Save to Folio
Wichtigste Erkenntnisse
- Wir haben mehrere Angriffe aufgedeckt, die das mit einer Codesignatur versehene Fernzugriffstool „ScreenConnect“ als verdeckte RAT missbrauchten und so umkonfigurierten, dass es Daten an die Angreifer übermittelte, während es wie legitime IT-Software aussah.
- Die Verbreitungsmethode variierte je nach Fall von Phishing-Köder und Malvertising-Weiterleitungen.
- In einem Fall erlangte der Angreifer vollständige praktische Kontrolle, wechselte regelmäßig die Domains, stellte mehrere als Microsoft-Dienste getarnte ScreenConnect-Instanzen bereit, sorgte für mehrschichtige Persistenz, führte Skripte aus, um konkurrierende RMM-Tools zu entfernen, bevor er einen Neustart erzwang.
Das TrendAI Vision One™ Services – Managed Detection and Response (MDR)-Team beobachtete den wiederkehrenden Missbrauch von ConnectWise ScreenConnect, einem legitimen und codesignierten Fernwartungstool. Dabei wird ScreenConnect als verdecktes Fernzugriffstool (RAT) eingesetzt, und zwar für verschiedene Einbrüche, unterschiedliche Opfer und separate Infrastrukturen, wahrscheinlich von verschiedenen Akteuren gesteuert. Anstatt eigene Malware zu schreiben, verleiten die Akteure die Opfer dazu, einen vom Angreifer konfigurierten ScreenConnect-Client zu installieren, der dem Angreifer die vollständige Fernsteuerung des Computers ermöglicht, dabei jedoch wie gewöhnliche IT-Software aussieht und die Prüfmechanismen umgeht, die zur Erkennung herkömmlicher Malware entwickelt wurden.
In all diesen Fällen erreichten die Angreifer ihr Vorhaben über verschiedene Verbreitungswege, wie Phishing-Mails mit Dokumenten, Einladungen und Ködern zum Thema Steuern, durch SEO manipulierte Suchergebnisse, die mit Trojanern infizierte Freeware-Installationsprogramme bereitstellten, über Werbung verbreitete und Drive-by-Angriffe.
Im schwerwiegendsten Fall wurde ein Remote Monitoring and Management-Tool verwendet, um ein anderes zu installieren. Die Angriffe wurden in unterschiedlichen Phasen des Angriffszyklus gestoppt – von einer Phishing-Mail, die direkt nach dem Eingang blockiert wurde, bis hin zu einer stillen Kompromittierung mit direkter Zugriffskontrolle auf SYSTEM-Ebene.
Zwei Fälle gingen weiter als die anderen. Einmal gelang die Ausführung über SEO-Poisoning: Ein Nutzer, der nach einem Freeware-Tool suchte, wurde zu einem manipulierten Suchergebnis geleitet, und der Download bündelte eine funktionierende Kopie der Anwendung mit einem versteckten ScreenConnect-Client. Ein anderer schwerwiegender Fall kam gänzlich ohne Beteiligung eines Nutzers aus. Der ScreenConnect-Client wurde über einen bereits auf dem System vorhandenen SimpleHelp-RMM-Agenten bereitgestellt – ein signiertes RAT, das zur Bereitstellung eines weiteren RAT genutzt wurde. Hier wechselte der Angreifer Domains und Hosts, behielt dabei jedoch seine Build-Pipeline und seine Tools bei, was es schwierig macht, die Aktivität allein anhand von Indikatoren zu blockieren.
ScreenConnect als Angriffswerkzeug
Der Missbrauch von ScreenConnect wird in der Sicherheitsbranche bereits seit mehreren Jahren dokumentiert, wobei stets dieselben Verbreitungswege beobachtet wurden. Frühe Untersuchungen von 2022 zur böswilligen Nutzung von ScreenConnect wurden in einem CISA-Hinweis vom Januar 2023 zitiert, gefolgt von den Anfang 2024 weit verbreiteten Sicherheitslücken CVE-2024-1708/CVE-2024-1709 zur Umgehung der Authentifizierung. Die Berichterstattung intensivierte sich dann im Laufe des Jahres 2025 und bis 2026 hinein, als die Angreifer von der Ausnutzung von Sicherheitslücken auf die mittels Social Engineering erfolgte Verbreitung neu konfigurierter, codesignierter Clients umstellten. Dieser Ansatz, bei dem man sich „auf vertrauenswürdige Software stützt“, ermöglicht es dem bösartigen Client, sich in den legitimen ScreenConnect-Datenverkehr einzuschleusen und Tools zu umgehen, die bekannte Fernzugriffssoftware weniger genau prüfen.
Der Angriffs-Lebenszyklus
Diese Angriffe folgen unabhängig von der Übertragungsmethode im Großen und Ganzen demselben Muster – von der ersten Zustellung über die Installation bis hin zu manuellen Eingaben am Computer. Der Unterschied liegt darin, in welchem Stadium das MDR-Team oder der Kunde die Attacke stoppte.
Wir konnten die meisten dieser Installationsversuche frühzeitig abfangen, und nur zwei Fälle gingen so weit, dass es zu manuellen Eingaben am Computer kam: der Fall der RMM-Verkettung und der des SEO-Poisoning, der kurz nach der Ausführung eingedämmt wurde. Diese Fälle zeigen, was auf eine erfolgreiche ScreenConnect-Installation folgen kann, sie sollten jedoch nicht als garantiertes Ergebnis für jeden einzelnen Fall interpretiert werden.
Die Fälle betreffen außerdem unterschiedliche Opfer, Übertragungswege und in den meisten Fällen separate Akteure. Einige nutzen zwar gemeinsame Infrastruktur und Vorgehensweisen, und bei wenigen gibt es Überschneidungen mit separat gemeldeten öffentlichen Kampagnen, doch diese Verbindungen deuten höchstens auf gemeinsame oder verwandte Operationen hin, nicht auf einen einzigen zuordenbaren Akteur.
Die Herausforderung bei der Triage
Eine ScreenConnect-Erkennung ist für sich genommen selten ein eindeutiges Signal. Harmlose und böswillige Nutzung sehen nahezu identisch aus. In einigen Fällen stellte sich der von uns markierte Client als zugelassenes Fernwartungstool heraus. In anderen Fällen nutzte der Kunde ScreenConnect zwar rechtmäßig, jedoch nicht die spezifische Instanz, die wir entdeckt hatten. Das verlässliche Signal ist nicht die Binärdatei oder die Domäne des Anbieters, sondern die spezifische Instanz, das Relay und die Download-Quelle, mit der eine Verbindung hergestellt wird – und genau darauf konzentrierte sich letztendlich unsere Triage. Eine detaillierte Beschreibung der Angriffsabfolge sowie weitere Einzelheiten zu den beschriebenen Fällen beinhaltet der Originalbeitrag.
Fazit
Diese Fälle veranschaulichen, wie legitime Tools als Waffen eingesetzt werden: Angreifer konfigurieren einen echten, code-signierten Client so um, dass er eine Verbindung zu einer von ihnen kontrollierten Infrastruktur herstellt, und verbreiten ihn dann über beliebige Kanäle, die eine Installation ermöglichen. Das Installationsprogramm besteht jede Reputationsprüfung. Die Binärdatei ist echt. Das Einzige, was eine zulässige Bereitstellung von einer böswilligen unterscheidet, ist der Kontext: Woher sie stammt, mit welchem Relay sie sich verbindet und ob jemand sie autorisiert hat.
Der extremste Fall zeigte, wie diese Technik aussieht, wenn sie nicht frühzeitig entdeckt wird. Der Angreifer ging geduldig und strukturiert vor: drei fehlgeschlagene Download-Versuche, bevor auf eine funktionierende Domain umgeschaltet wurde, mehrere ScreenConnect-Instanzen, die mit Microsoft-ähnlichen Dienstnamen und Verzeichnispfaden bereitgestellt wurden, Persistenz-Hooks, die bis in die Windows-Anmeldeoberfläche reichten, sowie eine methodische, Skript für Skript erfolgende Entfernung jedes konkurrierenden Fernzugriffstools auf dem Host, bevor ein Neustart erzwungen wurde. Die dahinterstehende Infrastruktur war auf dieselbe Weise aufgebaut: ein Pool von Knoten mit doppelter Funktion, die über eine gemeinsame Build-Pipeline bereitgestellt wurden, wobei Lock-Domains zwischen verschiedenen IP-Adressen wechselten, um sicherzustellen, dass keine einzelne Abschaltung den Betrieb unterbrach. Diese Art von Redundanz ist darauf ausgelegt, indikatorbasierte Blockierungen zu überdauern.
Die meisten Eindringversuche in dieser Reihe wurden gestoppt, bevor der Angreifer Fuß fassen konnte – nicht, weil der Installer als bösartig gekennzeichnet wurde, sondern weil MDR-Analysten den Kontext um ihn herum rekonstruierten, was automatisierte Tools nicht leisten konnten.
Empfehlungen
Wir empfehlen Unternehmen, die folgenden Kontrollmaßnahmen zu implementieren:
Richtlinie für eine RMM-Whitelist einführen: Dokumentieren Sie alle autorisierten Fernzugriffstools und deren spezifische Instanz-IDs. Jede Verbindung von ScreenConnect, SimpleHelp oder ähnlichen Tools zu nicht genehmigten Relays sollte eine sofortige Untersuchung auslösen.
Bekannte Missbrauchsmuster blockieren: Implementieren Sie eine URL-Filterung für die von uns beobachteten gängigen ScreenConnect-Staging-Muster (Pfade ?e=Access&y=Guest und /Bin/), sobald diese auf nicht autorisierten Instanzen auftreten.
Implementieren Sie eine Netzwerksegmentierung für Verwaltungstools: RMM-Software sollte sich nur von dafür vorgesehenen Administrator-Arbeitsplätzen aus mit bestimmten internen Systemen verbinden, niemals von Endgeräten allgemeiner Benutzer zu externen Relays.
TrendAI Vision One™ Threat Intelligence Hub bietet auf der TrendAI Vision One™-Plattform die neuesten Erkenntnisse zu aufkommenden Bedrohungen und Akteuren, exklusive strategische Berichte von TrendAI™ Research sowie den TrendAI Vision One™ Threat Intelligence Feed.
Kunden von TrendAI Vision One können die XDR Data Explorer App nutzen, um die bösartigen Indikatoren mit den Daten in der eigenen Umgebung zu Aufklärungszwecken zu vergleichen. Einzelheiten dazu im Originalbeitrag. Hier finden Sie auch die MITRE ATT&CK-Techniken und die Indicators of Compromise.