Neue trojanisierte ScreenConnect-Installer infizieren eine Maschine gleich mit mehreren RATs

Autor:innen: Ilia Dafchev, Eliad Kimhy

• Zunahme des Missbrauchs von ScreenConnect: Seit März 2025 beobachtet die Acronis Threat Research Unit (TRU) eine Zunahme von Angriffen, bei denen trojanisierte ConnectWise ScreenConnect-Installer genutzt werden, um sich Erstzugriff auf US-amerikanische Unternehmen zu verschaffen. Wir beobachten einen anhaltenden Trend zum Missbrauch von RMM-Tools, der weiterhin Cyberkriminelle anzieht – möglicherweise aufgrund der hohen Effektivität dieser Angriffsmethode.

• Evasive ClickOnce-Installer: Cyberkriminelle nutzen nun einen ClickOnce Runner-Installer für ScreenConnect, der keine eingebettete Konfiguration enthält. Stattdessen werden die Komponenten bei der Ausführung abgerufen. Dadurch werden herkömmliche statische Erkennungsmethoden weniger effektiv und der Schutz wird erschwert. Es bleiben nur wenige zuverlässige Abwehrmöglichkeiten.

• Automatisierte Bereitstellung von zwei Fernzugriffstrojanern: Unmittelbar nach der Installation von ScreenConnect nutzen Cyberkriminelle dessen Automatisierungsfunktionen, um zwei Fernzugriffstrojaner (RATs, Remote Access Trojaner) schnell bereitzustellen. Dabei kommen das bereits bekannte Tool AsyncRAT sowie ein bislang unbekannter, PowerShell-basierter RAT zum Einsatz. Die gleichzeitige Bereitstellung zweier Trojaner kann verschiedenen Zwecken dienen. Beispielsweise kann sie der Redundanz oder dem Testen von Tools dienen oder die gemeinsame Infrastruktur mehrerer Bedrohungsakteure widerspiegeln.

• Neuer PowerShell-RAT: Das TRU-Team hat einen „hausgemachten” Fernzugriffstrojaner entdeckt, der nicht in Open-Source-Repositorys zu finden ist. Er spioniert das System aus, exfiltriert Daten über „Microsoft.XMLHTTP” und nutzt mehrere Verschleierungstechniken. Aufgrund des einzigartigen Codes wird vermutet, dass er entwickelt wurde, um die signaturbasierte Erkennung zu umgehen.

• Weiterentwicklung der Infektionskette: Zwei Wochen nach der Kompromittierung aktualisierten die Cyberkriminellen ihre Infektionskette. Sie setzten nun Batch- und VBS-Loader ein, die verschlüsselte .NET-Assemblys abrufen und ausführen, um AsyncRAT bereitzustellen. Damit demonstrierten sie ihre Anpassungsfähigkeit und die Weiterentwicklung ihrer Infrastruktur.

• Social Engineering und Wiederverwendung von Infrastrukturen: Bösartige Installer werden vermutlich mittels Phishing und unter Verwendung von Dateinamen, die offizielle oder finanzielle Dokumente vortäuschen, verbreitet. Außerdem nutzen Cyberkriminelle vorkonfigurierte VMs mit Windows Server 2022 und konsistenten Hostnamen für mehrere Kampagnen. Das ermöglicht eine schnelle Wiederbereitstellung und Infrastrukturrotation.

• Abwehrmaßnahmen: Unternehmen sollten die Nutzung von RMM-Tools genau überwachen und ScreenConnect-Bereitstellungen sorgfältig prüfen.

In den letzten Monaten hat die Acronis Threat Research Unit (TRU) mehrere aktive und laufende Kampagnen identifiziert, bei denen trojanisierte Versionen von ConnectWise ScreenConnect eingesetzt wurden, um sich Erstzugang zu den Netzwerken der Opfer zu verschaffen und die Zielgeräte zu kompromittieren. Unsere Untersuchungen zeigen, dass die Häufigkeit dieser Kampagnen seit März 2025 zugenommen hat. Derzeit sind vor allem Unternehmen in den Vereinigten Staaten betroffen. Es gibt jedoch keine Hinweise darauf, wo sich die Cyberkriminellen befinden.

Die Nutzung von ConnectWise ScreenConnect als Einfallstor ist zwar kein neues Phänomen, doch weisen diese jüngsten Kampagnen einige Neuerungen auf. So werden beispielsweise kleinere ClickOnce Runner-Installer anstelle von vollständigen Installern bereitgestellt. Diese ClickOnce-Installer sind weitaus evasiver als bisher beobachtete Installer, da sie nicht mehr auf eingebettete Konfigurationen angewiesen sind und somit schwerer zu erkennen sind. Nach der Installation können die Cyberkriminellen die Kontrolle über den kompromittierten Computer übernehmen. Sie können dann zusätzliche Malware installieren, Daten stehlen, ihren Verbleib im System dauerhaft sichern und sich lateral im Netzwerk bewegen.

Der Missbrauch von RMM-Software (Remote Monitoring and Management) wie ScreenConnect kommt immer häufiger vor. Damit reiht sich diese Software in die wachsende Liste legitimer Tools ein, die für böswillige Aktivitäten zweckentfremdet werden. ScreenConnect-Installer sind bei dieser Art von Angriffen oft signiert und erscheinen als vertrauenswürdige Programme. Sie gewähren dem Eindringling jedoch umfassende Kontrolle über den kompromittierten Computer.

In der Regel nutzen IT-Teams ScreenConnect, um per Fernzugriff auf Systeme zuzugreifen, beispielsweise zu Support-Zwecken oder um auf Vorfälle zu reagieren. Cyberkriminelle können RMM-Software auf verschiedene Weise als Waffe einsetzen. Beispielsweise können sie Schwachstellen ausnutzen oder das legitime Produkt hacken bzw. missbrauchen. Dabei entsteht immer eine ausführbare Datei, die den Computer des Opfers mit einem von den Cyberkriminellen kontrollierten Server verbindet. Unter Umständen warten die Eindringlinge Tage oder sogar Wochen, bevor sie aktiv werden, wenn die bösartige RMM-Software unentdeckt bleibt.

In diesem Bericht beschreiben wir detailliert die jüngsten Kampagnen, bei denen ScreenConnect für die Erstinfektion genutzt wird. Ebenso wird die nach der Kompromittierung bereitgestellte Malware ausführlich erläutert. Sicherheitsteams können die hier dargelegten Erkenntnisse und Empfehlungen nutzen, um ihre Abwehrmaßnahmen zu optimieren und sich gegen ähnliche Bedrohungen zu wappnen.

Der Angriff beginnt mit einer schädlichen ausführbaren Datei namens „agreement_support-pdf.Client.exe”, die offenbar über den Browser Microsoft Edge heruntergeladen wurde. Bei dieser Datei handelt es sich um einen ClickOnce-Installer, der als legitimes Support-Dokument getarnt ist. Dies ist eine häufig eingesetzte Social-Engineering-Methode, um Opfer dazu zu verleiten, nicht vertrauenswürdigen Code auszuführen. Der Angriff geht vermutlich auf eine Social-Engineering-Kampagne zurück, die über E-Mail-Phishing oder andere Methoden verbreitet wurde.

Button

Button

Nach der Ausführung startet der Installer die Datei „ScreenConnect.ClientSetup.exe“. Diese verbindet den Computer des Opfers nach der Installation mit dem C2-Server der Cyberkriminellen.

Wie bereits erwähnt, unterscheiden sich diese Installer von früheren Angriffen, bei denen ScreenConnect missbraucht wurde, dadurch, dass sie einen ClickOnce Runner-Installer verwenden. Dieser ist kleiner und enthält keine eingebettete Konfiguration. Er verbindet sich stattdessen direkt mit dem konfigurierten ScreenConnect-Server und lädt die erforderlichen Komponenten und Konfigurationen herunter, um mit der Installation fortzufahren. Dadurch werden die Installer deutlich schwieriger zu erkennen. Bei vorherigen Angriffen konnte eine Sicherheitssoftware nach bestimmten Phrasen in der eingebetteten Konfiguration suchen, um verdächtige ScreenConnect-Ausführungen zu erkennen und zu stoppen. Dies ist bei dieser neuen Angriffsversion jedoch nicht mehr möglich. Die einzigen beiden zuverlässigen Schutzmaßnahmen wären, die C2-Domäne auf die Blacklist zu setzen, was jedoch im Voraus schwer umzusetzen ist, oder ScreenConnect komplett zu blockieren.

Das TRU-Team hat die bösartige Adresse anhand der Installationsparameter im Installer entdeckt. Dieser wurde mit den Parametern „e=Support&y=Guest&h=morco[.]rovider[.]net&p=8041” ausgeführt. Dadurch wurde eine Verbindung zu der von den Eindringlingen kontrollierten Domain „morco.rovider[.]net” hergestellt. Die kürzlich registrierte Domain wird auf einem virtuellen privaten Server (VPS) gehostet, der mit stealthrdp[.]com verbunden ist. Zudem wurde beobachtet, dass die Domain andere schädliche Varianten verbreitet. Dies deutet darauf hin, dass sie Teil einer umfassenderen Infrastruktur für Malware-Kampagnen ist.

Bei diesem Angriff wird ein bestimmter lokaler ScreenConnect-Installer missbraucht. Da lokale Installationen unabhängig von der Cloud-Infrastruktur sein müssen, bietet ConnectWise seinen Kund:innen die Möglichkeit, einen Server und Clients innerhalb ihres eigenen Netzwerks einzurichten, ohne dass sie auf Cloud-Komponenten angewiesen sind. Dieses System besteht aus zwei Komponenten: einem Server- und einem Client-Installer. Der Server-Installer wird bei legitimen Versionen mit einer Adresse konfiguriert und kann auch Client-Installer erstellen.

Bei diesem Angriff haben die Cyberkriminellen vermutlich eine gehackte Version des Server-Installers erworben. Mithilfe dieser konnten sie die Serveradresse ändern. Dadurch können Cyberkriminelle Installer erstellen, die eine Verbindung zu ihrem eigenen bösartigen ScreenConnect-Server herstellen, während sie für Sicherheitssoftware legitim erscheinen. Ohne Kenntnis der eingebetteten Serveradresse ist eine Erkennung dieser Installer schwierig.

Nach der Installation von ScreenConnect und der Verbindung mit dem C2-Server der Eindringlinge entfaltete sich über einen Zeitraum von etwa zwei Monaten ein komplexes Angriffsmuster. Das TRU-Team analysierte die Entwicklung des Angriffs im Zeitverlauf und stellte fest, dass mehrere RATs gleichzeitig bereitgestellt und abwechselnd eingesetzt wurden. Einer davon war ein PowerShell-basierter RAT mit grundlegenden Funktionen, die anderen waren etablierte und weit verbreitete Tools wie AsyncRAT. Aufgrund dieser Überlappung ist unklar, ob eine einzige Person für die Angriffe verantwortlich ist oder ob die Infrastruktur von mehreren Parteien gemeinsam genutzt wird, die den Zugang wiederum an andere Personen verkaufen, die eventuell nichts voneinander wissen.

Nach der Installation von ScreenConnect werden innerhalb weniger Minuten zwei Payloads auf das System übertragen. Dies beruht auf einer Funktion von ScreenConnect, mit der IT-Verantwortliche Automatisierungen einrichten können. Dazu gehört beispielsweise die Ausführung eines Skripts, wenn sich Benutzer:innen zum ersten Mal mit dem Server verbinden. Dadurch können Cyberkriminelle unmittelbar nach der ScreenConnect-Installation automatisch eine Reihe verschiedener RATs installieren.

Button

Button

Zur Ausführung der ersten Schadsoftware nutzen die Cyberkriminellen ScreenConnect, um eine Batch-Datei namens „BypaasaUpdate.bat“ herunterzuladen und auszuführen. Diese erste Batch-Datei fungiert als Downloader und Stager für alle weiteren Phasen der Infektion mit der ersten Payload und lädt eine ZIP-Datei herunter, die Folgendes enthält:

• 1.txt: Eine Textdatei, die AsyncRAT enthält.

• Pe.txt: Eine Textdatei mit einem .NET AMSI-Bypass und einem Persistenzmechanismus.

• Skype.ps1: Ein PowerShell-Skript zum Verarbeiten und Laden der oben genannten txt-Dateien als .NET-Assemblys.

• b.bat: Ein Batch-Skript, das zum Ausführen des obigen PowerShell-Skripts verwendet wird.

Button

Button

Nachdem die Dateien extrahiert wurden, wird zunächst „b.bat“ aufgerufen, welches wiederum „Skype.ps1“ ausführt. „Skype.ps1“ lädt anschließend die Dateien „pe.txt“ und „1.txt“ als .NET-Assemblys in den Arbeitsspeicher.

Button

Button

Button

Button

Die Datei „1.txt” enthält den bekannten und weit verbreiteten Fernzugriffstrojaner AsyncRAT, der sowohl für Penetrationstests als auch von Cyberkriminellen häufig genutzt wird. Die Datei „pe.txt” wird hingegen verwendet, um die Anti-Malware-Scan-Schnittstelle (AMSI) zu umgehen. Dadurch kann das Skript weiterhin bösartige Skripte ausführen und eine dauerhafte Präsenz im infizierten System herstellen.

Zur Sicherstellung des Verbleibs im infizierten System wird eine zusätzliche Datei namens „Microsoft.vbs” erstellt, die ausschließlich dazu dient, „Skype.ps1” erneut auszuführen. Anschließend wird ein geplanter Task erstellt, der „Microsoft.vbs” nach einer Minute einmalig ausführt. Sobald der Task ausgeführt wird, führt „Microsoft.vbs” „Skype.ps1” erneut aus. Dadurch werden die Dateien „1.txt” (bzw. „AsyncRAT”) und „pe.txt” erneut geladen. Diese richten dann einen neuen geplanten Task für eine Minute in der Zukunft ein. Auf diese Weise wird ein Persistenzmechanismus geschaffen, durch den AsyncRAT jede Minute neu in den Arbeitsspeicher geladen wird und der gesamte Persistenzmechanismus immer wieder neu gestartet wird.

Das bedeutet, dass „Skype.ps1” jede Minute versucht, AsyncRAT in den Speicher zu laden. „1.txt” (bzw. AsyncRAT) überprüft jedoch einen bestimmten Mutex („AsyncMutex_al026”), um festzustellen, ob AsyncRAT bereits ausgeführt wird. Wenn ja, wird es beendet. Auf diese Weise wird AsyncRAT nicht jede Minute neu geladen, sondern nur, wenn es noch nicht ausgeführt wurde.

Zu beachten ist auch, dass dieser Persistenzmechanismus sehr „laut” ist. Das Ausführen eines PowerShell-Skripts jede Minute hinterlässt eine enorme Anzahl von Spuren. Dies korrigieren die Eindringlinge in einer späteren Phase des Angriffs.

Einige Minuten nach dem Laden und Einrichten von AsyncRAT wurde ein weiteres Skript über ScreenConnect heruntergeladen und ausgeführt. Während das erste Skript das bekannte Tool AsyncRAT installierte, installierte das zweite Skript überraschenderweise einen neuartigen Payload in Form eines „hausgemachten” Fernzugriffstrojaners. Dieser RAT wurde als PowerShell-Skript geschrieben und bietet grundlegende Funktionen wie das Ausführen von Programmen und das Herunterladen und Ausführen von Dateien sowie einen einfachen Persistenzmechanismus. Er ähnelt keinem der uns bekannten Open-Source-Tools und wurde möglicherweise von den Cyberkriminellen selbst programmiert.

Dabei handelt es sich höchstwahrscheinlich um eine weitere automatische Ausführung, wodurch sich die Frage stellt, warum zwei Fernzugriffstrojaner auf einer infizierten Maschine installiert werden. Darauf gibt es keine eindeutige Antwort, aber es gibt einige Möglichkeiten:

1.      Die Eindringlinge agieren möglicherweise äußerst vorsichtig. Falls ein RAT entdeckt wird, kann das andere verwendet werden, um eine Hintertür offen zu halten. Oder dieser zweite RAT ist vielleicht auf eine Weise evasiv, die der erste nicht ist.

2.      Es ist auch möglich, dass die Eindringlinge einen neuen RAT testen, den sie gerade entwickeln, und beschlossen haben, beide zu installieren.

3.      Mehrere Personen nutzen dieselbe Infrastruktur (oder ihnen wurde der Zugang dazu verkauft).

Ungeachtet des Grundes konnten wir eine neue C2-Adresse feststellen. Bei der Analyse des Angriffs in den folgenden Wochen haben wir außerdem herausgefunden, dass beide Fernzugriffstrojaner zum Einsatz kamen.

Button

Button

Auch die Angriffskette scheint einfacher zu sein: Sie beginnt mit einer JavaScript-Datei, die offenbar nach dem Port der C2-Adresse benannt ist und in einem temporären Ordner abgelegt wird. Das Skript führt dann im Wesentlichen den gesamten RAT als PowerShell-Befehl aus.

Button

Button

Nach der Entschleierung enthüllt dieser ein Skript, das als eine Art „hausgemachter” Fernzugriffstrojaner fungiert. Der Trojaner deaktiviert AMSI, richtet einen Listener für Befehle ein, führt eine erste Erkundung durch, stellt seinen Verbleib im System sicher und startet eine Endlosschleife, die als Befehlshandler dient.

Zunächst führt das Skript eine Systemerkundung durch, bei der es mithilfe der Windows-Verwaltungsinstrumentation (WMI) Informationen zu installierten Antivirenprogrammen sammelt. Darüber hinaus werden Informationen zum Namen und zur Architektur des Betriebssystems, zur UUID, zum Computernamen und zum Benutzernamen erfasst. All diese Informationen werden anschließend mithilfe von „Microsoft.XMLHTTP” an den C2-Server des Eindringlings gesendet. Dieser wird auch zum Abhören von Befehlen verwendet. Die Verwendung dieses COM-Objekts ist in diesem Kontext interessant, da es üblicherweise in VBS-Skripten zum Einsatz kommt. Es ist möglich, dass diese Methode anstelle der integrierten PowerShell-Befehle gewählt wurde, um einer Erkennung zu entgehen, da viele Sicherheitsprodukte nach PowerShell-Befehlen suchen, die eine Internetverbindung herstellen.

Button

Button

Der Befehlshandler besteht aus einer Schleife, die alle drei Sekunden eine POST-Anfrage an den C2-Server sendet und auf eine Antwort wartet. Basierend auf der Antwort führt die Schleife dann die folgenden Befehle aus:

1.      RF (Run File): Mit diesem Befehl kann der Eindringling eine Binärdatei in einen temporären Ordner schreiben und ausführen.

2.      TR: Empfängt PowerShell-Code vom C2-Server, speichert ihn als .ps1-Datei auf der Festplatte und führt ihn aus. Darüber hinaus richtet es mithilfe eines VBS-Skripts einen Persistenzmechanismus ein. Dieses ist so konfiguriert, dass es beim Systemstart über den Autostart-Ordner ausgeführt wird und das PowerShell-Skript startet. So können beliebig viele zusätzliche Hintertüren oder andere Skripte eingerichtet werden, die Cyberkriminelle dauerhaft im System ablegen möchte.

3.      Exc: Ermöglicht das Schreiben eines VBS-Skripts in einen temporären Ordner und dessen Ausführung.

4.      Sc: Dieser Befehl führt eine ähnliche Aktion aus wie der RF-Befehl, wird aber zum Schreiben von Klartext und vermutlich auch zur Ausführung von Skripten verwendet.

5.      Cl: Beendet die Schleife und schließt das Skript.

6.      Un: Beendet die Schleife und schließt das Skript.

Um im System zu verbleiben, wird eine Kopie der Datei „8911.js“ (die ursprüngliche JavaScript-Datei, die das RAT-Skript gestartet hat) im Autostart-Ordner unter dem Namen „FirefoxUpdate.js“ erstellt.

Das Skript verwendet mehrere Verschleierungstechniken, um einer Erkennung zu entgehen und die Analyse zu erschweren. So sind Variablen- und Funktionsnamen bewusst lang, unsinnig oder stehen in keinem Zusammenhang mit ihrem Zweck, während die Befehlsausführung hinter dynamisch berechneten Aliasen verborgen ist. Wichtige Schaddaten, wie beispielsweise das VBS-Persistenzskript, werden als Charcode-Arrays gespeichert und erst zur Laufzeit entschlüsselt. Der AMSI-Bypass wird als Base64-kodierte .NET-Assembly gespeichert. Der Befehlshandler verwendet kurze, kryptische Codes (wie RF, TR, Sc) anstelle von beschreibenden Namen und abgelegte Dateien erhalten zufällige oder GUID-basierte Namen.

Das Skript nutzt integrierte Windows-Objekte wie „Microsoft.XMLHTTP” für die Kommunikation mit dem C2-Server und „Microsoft.VisualBasic.Interaction” zur Erstellung von Objekten, so dass diese wie legitime Aktivitäten aussehen. Daten zum System werden über HTTP-Header statt über offensichtliche Parameter exfiltriert und Fehlermeldungen werden unterdrückt, um keine Aufmerksamkeit zu erregen. Diese mehrschichtigen Verschleierungsstrategien erschweren es Sicherheitssoftware, das tatsächliche Verhalten des Skripts automatisch zu erkennen und zu verhindern.

Insgesamt ist dieses Skript sehr interessant, unter anderem auch, weil wir es nirgendwo sonst gefunden haben. Obwohl Teile des Codes offenbar wiederverwendet wurden, scheint dieser „hausgemachte” Fernzugriffstrojaner größtenteils vom Angreifer bzw. der Angreiferin selbst geschrieben worden zu sein. Dies hat vermutlich den Vorteil, dass das Tool genau auf den Angriff abgestimmt werden kann und eine Erkennung anhand spezifischer, bekannter Muster oder Signaturen vermieden wird. Andererseits fehlen möglicherweise einige der erweiterten Funktionen anderer Tools. Dies ist eine interessante Erkenntnis, die die Frage aufwirft, ob mehr als eine Person dieselbe Infrastruktur nutzt.

Button

Button

Zwei Wochen nach der ersten Kompromittierung nutzten die Eindringlinge ihren ScreenConnect-Zugang, um eine neue Version von AsyncRAT zusammen mit einer modifizierten Infektionskette bereitzustellen.

Die neue Infektionskette beginnt mit einem Batch-Skript, das „MicrosoftUpdate.vbs” startet – einen einfachen Wrapper für einen PowerShell-Einzeiler, der als Loader dient. Dieses PowerShell-Skript lädt die beiden Dateien „logs.ldr” und „logs.ldk” in das Verzeichnis „C:\Users\Public” herunter.

Button

Button

Button

Button

Sowohl die Datei „logs.ldk” als auch die Datei „logs.ldr” sind codierte .NET-Assemblys. Das PowerShell-Skript entschlüsselt zunächst „logs.ldk” und führt sie aus. Dabei handelt es sich um eine .NET-DLL namens „Obfuscator.dll“, die zwei Funktionen erfüllt: Einerseits sorgt sie für den Verbleib im System und andererseits dient sie als sekundärer Loader für „logs.ldr“, die eigentlichen AsyncRAT-Schaddaten.

Die Persistenz wird durch einen geplanten Task namens „Skype Updater“ erreicht. Dieser ist so konfiguriert, dass er bei der Benutzeranmeldung „C:\Users\Public\Ab.vbs” ausführt. Dieses VBS-Skript imitiert das Verhalten von „MicrosoftUpdate.vbs“ und fungiert als Wrapper, der den PowerShell-basierten Loader aufruft.

AsyncRAT (logs.ldr) wird schließlich über den Methodenaufruf „[Obfuscator.A]::Main($f2)” der .NET-DLL „Obfuscator.dll” entschlüsselt und in den Arbeitsspeicher geladen. Dieser Aufruf wird innerhalb des PowerShell-Skripts ausgeführt.

Button

Button

Die neu bereitgestellte AsyncRAT-Instanz verfügte über eine aktualisierte Konfiguration. So wurde insbesondere ein neuer Mutex-String verwendet: „AsyncMutex_alosh20215”. Die Kommunikation mit dem Command-and-Control-Server (C2) erfolgte über die Ports 4501, 4502 und 4503,

während die C2-Infrastruktur unverändert blieb und weiterhin unter 185.196.9.158 gehostet wurde.

Button

Button

Einige Tage nach Bereitstellung der aktualisierten AsyncRAT-Version haben wir festgestellt, dass ein weiterer Fernzugriffstrojaner über die WMI übertragen wurde. Dies geschah nur wenige Minuten nach der Ausführung der mit AsyncRAT verbundenen Skripte. Eine eindeutige Zuordnung ist anhand der verfügbaren Beweise nicht möglich. Die zeitliche Nähe der beiden Ereignisse lässt jedoch einen Zusammenhang vermuten.

Dabei wurde beobachtet, wie der Prozess „WmiPrvSE.exe” einen PowerShell-Befehl ausführte, der die Funktion „Invoke-WebRequest” verwendete, um das Skript „NvContainerRecovery.ps1” in das Verzeichnis „C:\Users\Public” herunterzuladen. Unmittelbar danach rief derselbe WMI-Prozess PowerShell erneut auf, um das heruntergeladene Skript auszuführen.

Button

Button

Zunächst stellt das Skript „NvContainerRecovery.ps1“ seine Persistenz sicher, indem es ein VBS-Skript im Ordner „Autostart“ erstellt. Diese VBS-Datei dient lediglich als Wrapper, um das PowerShell-Skript bei jeder Benutzeranmeldung auszuführen.

Nachdem der Persistenzmechanismus eingerichtet wurde, lädt das PowerShell-Skript eine .NET-DLL, die Process Hollowing implementiert. Mithilfe dieser Methode wird eine weitere .NET-Assembly in eine erzeugte Instanz von „RegAsm.exe“ injiziert. Die injizierte Assembly ist für die Entschlüsselung und das Laden einer endgültigen .NET-Payload verantwortlich, die als PureHVNC RAT identifiziert wurde.

Die PureHVNC-Instanz ist so konfiguriert, dass sie eine Verbindung zu 169.156.208.185 auf Port 8020 herstellt.

Button

Button

Button

Button

Button

Button

Bei der Untersuchung der Angriffsinfrastruktur haben wir mehrere verschiedene Domains entdeckt. Wir nehmen an, dass die Eindringlinge diese nutzen. Neben morco.rovider.net sind dies die beiden weiteren Domains gaza.rovider.net und lightc.rovider.net. Beide stehen im Zusammenhang mit ScreenConnect-Installern, deren Server auf stealthrdp.com gehostet werden. Sie wurden auch im Zusammenhang mit XWorm und DCRat beobachtet, was auf eine umfassendere Angriffsinfrastruktur hindeuten könnte als bisher bekannt.

Wir haben zahlreiche Fälle identifiziert, in denen ScreenConnect-Installer verwendet wurden, um eine Verbindung zu mutmaßlich gehackten lokalen ScreenConnect-Servern herzustellen. Die überwiegende Mehrheit dieser Vorfälle ereignete sich in den Vereinigten Staaten. Die Dateinamen der Installer deuten stark darauf hin, dass die Verbreitung mittels Phishing oder anderer Social-Engineering-Techniken erfolgte.

Die ausführbaren Dateien waren in der Regel so benannt, dass sie wie legitime Dokumente aussahen. Dadurch sollten die Opfer dazu verleitet werden, sie auszuführen. Beispiele:

• Social_Security_Statement_Documents_386267.exe MD5: 2EECA7166487DDC0B4C36B718DF31C93

• ssa_view.exe MD5: C92D37BC45F6088458C70C1CF53C06F6

• Social-Security-Available-Statement-3025147.ClientSetup.exe MD5: BA261666A657BDE2E8E071EE6E7D5357

• agreement_support-pdf.Client.exe MD5: 34ED21AC2399CC08BD051A283FD59FCE

• SSADocumentViewer-nXpJ2.exe MD5: A58719D9DDE0179C25215637766C2AB0

• 2024 BUSINESS SCHEDULE COMPLETE ORGANIZERpdf.exe MD5: 316119C77032A24822A64C86C1E4B2A0

Wie dieses Muster der Dateibenennung zeigt, wird versucht, offizielle oder finanzielle Dokumente vorzutäuschen. Diese betreffen hauptsächlich Sozialversicherungsangelegenheiten oder rechtliche Vereinbarungen.

In diesen Fällen haben wir vor allem die Bereitstellung von AsyncRAT und Remcos RAT beobachtet.

Bei Remcos haben wir außerdem festgestellt, dass der Eindringling dieselbe VM für mehrere Kampagnen wiederverwendet hat, obwohl diese unter verschiedenen IP-Adressen gehostet wurden. Laut den Ergebnissen der Suchmaschine Shodan lief auf der VM Windows Server 2022, das Remote Desktop Protocol (RDP) war aktiviert und es wurde ein ScreenConnect-Server gehostet. Der Hostname „WIN-BUNS25TD77J” war bei allen Funden konsistent.

Im Rahmen der Sammlung weiterer Varianten aus Threat-Intelligence-Quellen haben wir zudem den gängigen Hostnamen „COPY-OF-VM-2022” entdeckt, der von verschiedenen Kampagnen verwendet wurde. Es sieht so aus, als hätten die Cyberkriminellen VMs vorkonfiguriert, die sie unter verschiedenen Adressen hosten. Dadurch ist eine schnelle Einrichtung und Änderung der Infrastruktur möglich.

Netzwerk:

• 169.156.208.185

• 185.196.9.158

• 185.196.8.100

• morco[.]rovider[.]net

• hxxps://eywordvailabom[.]com/sa/16-05.txt

• hxxps://systemwindowsupdate[.]com/alosh/logs.ldk

• hxxps://guilloton[.]fr/x.zip

Mutexe:

• AsyncMutex_al026

• AsyncMutex_alosh20215

Dateien:

• agreement_support-pdf.Client

67A32455A94B3396AD956CBDDA81D8ED1CD3727315159E025299057118DEB6AC

• Skype.ps1

BB182B8545B8C825811C6D09C738C230FE54BC96ADF1F10A3683B7E5294B5289

• 1.txt

C260779FB1C9FF775739F6CF1853C9C33131ECF176737F6AF26B0AC60A6081DC

• Pe.txt

53AAD05571E86F22E2C75ED4FA6C8F553C3EBD58DCA8BE9FE8A143784AEF29D7

• BypaasaUpdate.bat

973A02FF597864E3920ED1041D24D629A0762CDE932EB69AEA066CD2235404F8

• Pe.txt in dekodierter Form (AMSI-Patcher)

1DA9428DF9A04E6CA1D836D1E941B61E30B6AF952D24D7B451A8D1E906ECE0C0

• 1.txt in dekodierter Form (AsyncRAT)

E7C482E66EFA99EA98E2C79BEB0A31C5120B73E4951A5F33133066B17E009DA1

• logs.ldr

A4BF71F97C3A2F3FDA496D204B5E744D6F1DA8D888ACE3867DA08D072AF01245

• logs.ldk

6FA549F446A541856784695DB808DE2E5C67DA271C64ECC966C7C0B02622D58B

• logs.ldr (dekodiert)

10EEB21202E7EB055F9FAC37DAB96F86DFEB9F28C0510F33E4324D12087CACF2

• logs.ldk (dekodiert)

6AE546DA4D6D78D4262F3A2FF5E4F58C345294383ED9FF5E4DAA52466FE79E2F

• Powershell-RAT

B82E616E956A956FF5D9AFFCC13C907CF5054439FB5EE5A6F7AA5FFEE030DA56

• NvContainerRecovery.ps1

EF66D80511CD46C5173BF13E750C51114EE891E833F4F256A23E7DE4790ACC73

• PureHVNC RAT

068504CB4AC18D504247EF7A2C19A76B17A85E795B52E541FA8A49DE69B91F01