Verschlüsselte Herzen: Offenlegung des HeartCrypt Packer-as-a-Service-Betriebs

Zusammenfassung

Dieser Artikel analysiert einen neuen Packer-as-a-Service (PaaS) namens HeartCrypt, der zum Schutz von Malware eingesetzt wird. Er befindet sich seit Juli 2023 in der Entwicklung und wurde im Februar 2024 in den Vertrieb aufgenommen. Wir haben Beispiele für Malware-Muster identifiziert, die von diesem Dienst erstellt wurden, und zwar anhand von Zeichenfolgen, die in mehreren Entwicklungsmustern gefunden wurden, die die Betreiber zum Testen ihrer Arbeit verwendet haben.

Der Betreiber dieses Dienstes hat ihn über Untergrundforen und Telegram beworben. Seine Betreiber verlangen $20 pro zu packender Datei, die sowohl Windows x86 als auch .NET Nutzdaten unterstützt.

Die Mehrheit der HeartCrypt-Kunden sind Malware-Betreiber, die Familien wie LummaStealer, Remcos und Rhadamanthys verwenden. Wir haben jedoch auch Nutzlasten aus einer Vielzahl anderer Crimeware-Familien beobachtet.

HeartCrypt packt bösartigen Code in ansonsten legitime Binärdateien. Wir haben mit HeartCrypt gepackte Binärdateien sowohl in der externen als auch in der internen Telemetrie entdeckt.

Wir haben erfolgreich bösartigen Code für Nutzdaten aus Tausenden von HeartCrypt-Samples extrahiert. Ein Großteil der entpackten Payloads enthält Konfigurationsdaten, die wir verwendet haben, um Samples zu gruppieren und bösartige Kampagnen zu identifizieren, die auf verschiedene Branchen und Regionen abzielen.

Kunden von Palo Alto Networks sind durch die folgenden Produkte und Dienste besser vor den in diesem Artikel beschriebenen Bedrohungen geschützt:

• Cortex XDR und XSIAM
• Erweitertes WildFire

Wenn Sie glauben, dass Sie kompromittiert worden sein könnten oder ein dringendes Problem haben, wenden Sie sich bitte an das Referat 42 - Incident Response Team.

HeartCrypt Hintergrund

HeartCrypt wurde ursprünglich in Untergrundforen entdeckt und von Sicherheitsforschern im Februar und März 2024 gemeldet. In den acht Monaten, in denen HeartCrypt in Betrieb war, wurde es verwendet, um über 2.000 bösartige Nutzdaten zu verpacken, an denen etwa 45 verschiedene Malware-Familien beteiligt waren.

Wir fanden HeartCrypt in den jüngsten LummaStealer-Kampagnen, darunter eine, die sich als legitimer Softwareanbieter ausgab, und eine andere, die gefälschte CAPTCHAs verwendete. Wir haben auch Aktivitäten der Cyberkriminalität in lateinamerikanischen Ländern beobachtet, wobei Remcos und XWorm den HeartCrypt-Packer verwendeten.

Wir beobachteten HeartCrypt erstmals Ende Juni 2024 bei Routineuntersuchungen und stuften es zunächst als einen unbenannten, benutzerdefinierten Packer ein. Im Laufe der nächsten Wochen fanden wir immer mehr Malware-Familien, die diesen Packer verwendeten, und beschlossen, weitere Untersuchungen durchzuführen.

Anhand einzigartiger Byte-Muster, die in den gepackten Proben gefunden wurden, erstellten wir Jagdregeln und identifizierten Tausende von Proben, die bis Mitte 2023 zurückreichen. Nach der Implementierung von Prozessen zur Analyse dieser Proben im großen Maßstab haben wir mehrere bemerkenswerte Entdeckungen gemacht.

Unsere erste Entdeckung war, dass die Entwicklung im Juli 2023 begonnen zu haben scheint und das PaaS um den 17. Februar 2024 gestartet wurde. Fast 1.000 Proben aus diesem Zeitraum enthielten entweder keine Nutzlast oder eine Testnutzlast.

Zweitens wurde die gepackte Nutzlast durchweg als Ressource zu einer legitimen Binärdatei hinzugefügt, oft mit einem zufälligen Namen, obwohl frühe Versionen manchmal Namen verwendeten, die HeartCrypt enthielten. Dies führte uns zu unserer dritten Entdeckung, der Identifizierung des Verteilers des Packers.

Der Vertreiber von HeartCrypt vermarktete die PaaS über mehrere Plattformen, darunter auch die von HeartCrypt:

• Telegramm
• BlackHatForums
• XSS.is
• Ausnutzen.in

In der Werbung wird angegeben, dass HeartCrypt 32-Bit-Windows-Nutzdaten mit $20 pro Krypto unterstützt. Abbildung 1 zeigt eine Anzeige in einem Telegram-Post und Abbildung 2 zeigt eine Anzeige in einem XSS.is-Post.

Beim PaaS-Modell von HeartCrypt übermitteln die Kunden ihre Malware über Telegram oder andere private Nachrichtendienste, woraufhin der Betreiber sie packt und als neue Binärdatei zurückschickt. Wie im nächsten Abschnitt beschrieben, ist der Packprozess ein Beispiel dafür, wie die Kombination selbst einfacher Techniken zu einer Herausforderung für Reverse Engineers werden kann.

HeartCrypt Technische Analyse

Erstellen des HeartCrypt-Stub

Der Packvorgang beginnt damit, dass bösartiger Code in eine ansonsten legitime ausführbare Datei eingeschleust wird. Dies scheint kein zufälliger Prozess zu sein. Unsere Analyse zeigt eine kundenseitige Anpassung.

Wir haben über 300 verschiedene legitime Binärdateien identifiziert, die von den Betreibern als Träger für die bösartige Nutzlast verwendet wurden, was auf ein gewisses Maß an clientseitiger Kontrolle schließen lässt. Wir vermuten, dass der HeartCrypt-Dienst es den Kunden ermöglicht, eine bestimmte Binärdatei für die Injektion auszuwählen und die endgültige Nutzlast auf das beabsichtigte Ziel zuzuschneiden.

So könnte beispielsweise ein Bedrohungsakteur, der eine Malware-Kampagne mit einem Installationsprogramm für eine legitime Windows-Anwendung durchführt, die Einschleusung in ein echtes, aber veraltetes Installationsprogramm verlangen. Die daraus resultierende gepackte Malware, die über eine Website verteilt wird, die sich als Softwareanbieter ausgibt, würde einem technisch weniger versierten Benutzer weitaus legitimer erscheinen, was die Wahrscheinlichkeit einer erfolgreichen Detonation erhöhen könnte.

Die Änderung der legitimen Binärdatei erfolgt in drei wesentlichen Schritten:

1. Ein zusammenhängender Codeblock wird dem .text-Abschnitt der Binärdatei hinzugefügt.
2. Der Kontrollfluss innerhalb der ursprünglichen Binärdatei wird gekapert.
3. Der Binärdatei werden mehrere Ressourcen hinzugefügt.

Zunächst fügt HeartCrypt einen zusammenhängenden Codeblock in den .text-Abschnitt der Binärdatei ein. Dieser Codeblock ist als positionsunabhängiger Code (PIC) konzipiert, ein Programmierkonstrukt, bei dem die Position des Codes im Speicher keinen Einfluss auf seine Ausführung hat. Dadurch kann der bösartige Code unabhängig davon ausgeführt werden, wo er vom Betriebssystem in den Speicher geladen wird.

Zweitens missbraucht HeartCrypt den Kontrollfluss innerhalb der ursprünglichen Binärdatei. Dies wird meist durch eine Änderung der start()-Funktion erreicht, dem Einstiegspunkt für viele ausführbare Programme. Die Modifikation umfasst in der Regel das Hinzufügen eines Aufrufs oder einer jmp-Anweisung, die die Ausführung an das neu hinzugefügte PIC umleitet. Abbildung 3 zeigt einen Abschnitt des disassemblierten Codes eines HeartCrypt-Beispiels mit einem Beispiel für eine hinzugefügte jmp-Anweisung.

Das injizierte PIC nutzt mehrere Methoden zur Verschleierung des Kontrollflusses, um eine Analyse zu erschweren. Dazu gehören:

• Stapel-Strings
• Dynamische API-Auflösung
• Hunderte von direkten jmp-Anweisungen
• Nicht-zurückkehrende Funktionen
• Arithmetische Operationen, die keinen Einfluss auf die Programmausführung haben
• Junk-Bytes nach jmp- und Call-Anweisungen, die die Disassemblierung und Dekompilierung behindern

Die Kombination dieser Techniken macht sowohl die statische als auch die dynamische Analyse extrem mühsam.

Mit einiger Mühe hat unsere Analyse ergeben, dass das ursprüngliche PIC aus zwei Schichten besteht: einem verschlüsselten Block, der von einer kleinen Entschlüsselungsroutine umhüllt ist. Die erste Schicht verwendet spezifische Byte-Muster, um den Anfang und das Ende des verschlüsselten Blocks zu identifizieren. Die Abbildungen 4 und 5 unten zeigen dies als disassemblierten Code aus IDA Pro.

Nach dem Auffinden des verschlüsselten Blocks führt das PIC eine Substitutionsoperation an jedem Byte durch, und die Ausführung geht direkt zum entschlüsselten Block über. Der für die Ersetzung verwendete Wert wird nach dem Zufallsprinzip ausgewählt und liegt immer im Bereich von eins bis neun.

Der entschlüsselte Block verwendet dieselben Verschleierungstechniken wie die erste Schicht, wodurch wiederum eine statische Analyse nicht möglich ist. Diese zweite Schicht des PIC durchläuft die der Binärdatei hinzugefügten Ressourcen und führt nacheinander den Code in jeder dieser Ressourcen aus. Jede Iteration wird in drei Schritten durchgeführt.

Das PIC erstellt zunächst eine Stapelzeichenfolge, die den Ressourcennamen enthält. Anschließend nutzt es die Windows-APIs FindResourceW, LoadResource und LockResource, um einen Zeiger auf die entsprechende Ressource zu erhalten.

Schließlich werden mit VirtualProtect die Speicherschutzattribute der Ressource geändert und die Codeausführung ermöglicht. Die Ausführung wird direkt an die Ressource übertragen, und nach Abschluss wird die Kontrolle an das ursprüngliche PIC zurückgegeben, das den ursprünglichen Speicherschutz der Ressource mit VirtualProtect wiederherstellt. Die folgende Abbildung 6 gibt einen Überblick über den bisherigen Ablauf der Ausführung.

Nach dem Hijacking des Kontrollflusses fügt HeartCrypt der Binärdatei mehrere Ressourcen hinzu, die jeweils eine Schlüsselrolle in der Funktionalität des Packers spielen und auf jeder Ebene eine ähnliche Verschleierung verwenden. Wir analysieren nun jede Ressource im Detail und decken ihre individuellen Funktionen und ihren gemeinsamen Beitrag zur Funktionalität des Packers auf.

Enträtseln der Shellcode-Ressourcen

Jede in die Binärdatei eingebettete Ressource enthält PIC, das als Bitmap-Bilddatei (BMP) getarnt ist. Diese beginnt mit einem Standard-BMP-Header, gefolgt von einem sich wiederholenden hexadezimalen Muster zum Auffüllen.

Abbildung 7 zeigt ein Beispiel einer Ressource PIC in einem Hex-Editor, in dem die ersten beiden Bytes als ASCII-Zeichen BM und das sich wiederholende hexadezimale Muster als 0x09 zu sehen sind.

Nach dem sich wiederholenden hexadezimalen Muster markiert die Ressource den Beginn ihres PICs mit einer Folge von Bytes direkt vor dem Einstiegspunkt des PICs. Nach der Identifizierung dieser Bytefolge überträgt das primäre PIC die Ausführung an das Ressourcen-PIC.

Abbildung 8 zeigt diese Bytesequenz später in der Ressource PIC als 0x13371337, kurz vor dem Einstiegspunkt.

Die Ressource PIC spiegelt die Struktur des anfänglichen PIC-Blocks in der legitimen Binärdatei wider und besteht aus zwei Schichten mit denselben Verschleierungstechniken, die zuvor besprochen wurden. Jede Ressource führt eine andere Kernfunktion aus, wobei alle beobachteten HeartCrypt-Samples demselben Muster folgen.

Ressource 1: Anti-Abhängigkeits-Emulation

Die erste Ressource dient offenbar dazu, die Emulation von Abhängigkeiten in einer Sandbox-Umgebung zu erkennen. Sie versucht absichtlich, nicht existierende DLLs über LoadLibraryW zu laden, insbesondere k7rn7l32.dll und ntd3ll.dll.

Wenn die Sandbox mit der Erzeugung einer Dummy-DLL reagiert, um einen Absturz des Programms zu verhindern, ruft HeartCrypt ExitProcess auf und beendet die Ausführung. Dies ist eine rudimentäre und unzuverlässige Methode der Sandbox-Erkennung, da moderne Sandboxen in der Regel einen kontrollierten Fehlercode zurückgeben, anstatt eine gefälschte DLL zu erzeugen. Ein weiterer Hinweis auf diese Funktionalität erschien in frühen Entwicklungsbeispielen, in denen der Autor die Stack-Zeichenkette CheckLibraryEmulated mit MessageBoxW verknüpfte, wahrscheinlich zu Testzwecken.

Ressource 2: Prüfung der Sandbox-Schleifenemulation

Frühere Versionen der zweiten Ressource (wie auch viele der anderen Ressourcen) boten durch Debug-Strings nützliche Einblicke in die Funktionalität. Bei dieser Ressource ermöglichte es uns die Zeichenfolge CheckLoopEmulated sowie das Fehlen einer zeitbezogenen API, schnell zu erkennen, wofür diese Ressource verantwortlich sein könnte.

Die Ressource tritt in eine while-Schleife ein, die ähnlich wie ein Hash-Algorithmus eine große Anzahl von mathematischen Berechnungen mit einem hart kodierten Ausgangswert durchführt. Der resultierende Hash-Wert wird mit einem erwarteten Wert verglichen.

Wenn die beiden Werte übereinstimmen, setzt das Beispiel einen Flag-Wert im Speicher, um anzuzeigen, dass die Schleife nicht emuliert oder in irgendeiner Weise verändert wurde. Wenn dieses Flag nicht gesetzt ist, ruft der Prozess ExitProcess auf.

Ressource 3: Umgehung des Windows Defender

Die dritte Ressource bietet Anti-Sandbox-Funktionen zur Umgehung von Windows Defender. Sie nutzt virtuelle DLLs (VDLLs), bei denen es sich um spezielle Versionen von Windows-DLLs innerhalb des Defender-Emulators handelt, wie von Alexei Bulazel auf der BlackHat 2018 [PDF] beschrieben.

Beispielsweise verfügt kernel32.dll im Emulator über zusätzliche APIs wie MpReportEvent und MpAddToScanQueue. Wenn HeartCrypt diese API von kernel32 laden kann, kann es davon ausgehen, dass das Beispiel im Defender-Emulator ausgeführt wird.

Diese Anti-Sandbox-Technik wurde erstmals Anfang April 2024 von Harfang Lab in der RaspberryRobin-Malware gemeldet. Nur 15 Tage später wurde sie von den Autoren von HeartCrypt in der dritten Ressource übernommen.

Vor der Übernahme der Defender-Umgehungstechnik enthielt HeartCrypt eine andere Anti-Sandbox-Technik, die versuchte, d3d9::Direct3DCreate9 zu laden. Nach unserer Analyse glauben wir, dass dies mit einer Anti-Sandbox/Anti-VM-Technik übereinstimmt, die in dem von Check Point Research entwickelten InviZzzible Virtual Environment Assessor gefunden wurde.

Bei dieser Technik wird die Funktion GetAdapterIdentifier innerhalb eines IDirect3D9-Objekts verwendet, um festzustellen, ob die Hersteller-ID mit bekannten VM-Anbietern übereinstimmt. Alternativ könnten die HeartCrypt-Autoren diese Technik auch unter der Annahme implementiert haben, dass eine Sandbox wahrscheinlich keine Direct3D-Funktionalität bereitstellt. Wenn das Beispiel beispielsweise die d3d9-Bibliothek nicht laden könnte, würde es abgebrochen werden.

Ressource 4: Endgültige Ausführung der Nutzlast

Die vierte Ressource entschlüsselt und injiziert die endgültige Nutzlast, indem sie auf eine andere eingebettete Ressource zugreift, die die verschlüsselte Nutzlast enthält. Diese Ressource gibt sich als BMP-Datei aus, enthält aber keine zusätzlichen Auffüllungsbytes oder PIC. Stattdessen wird der BMP-Header einfach an die kodierte Nutzlast angehängt.

Bei der Nutzlast handelt es sich um eine ausführbare Windows-Binärdatei, die durch eine Ein-Byte-XOR-Operation verschlüsselt wird, die über einen Schlüssel rotiert, der in der PIC-Ressource als Stack-String fest codiert ist. Wir haben in allen HeartCrypt-Samples über 50 verschiedene XOR-Schlüssel identifiziert, ohne dass ein Muster erkennbar ist. Es ist möglich, dass der Kunde den Schlüssel zur Verfügung stellt, aber zum jetzigen Zeitpunkt haben wir keine Möglichkeit, diese Theorie zu überprüfen.

Nach der Entschlüsselung analysiert das PIC den entschlüsselten PE-Header, um festzustellen, ob die endgültige Nutzlast eine .NET-Assembly oder eine nativ kompilierte ausführbare Datei ist. Wenn es sich bei dem gepackten Beispiel um eine .NET-Assembly handelt, versucht HeartCrypt, csc.exe (oder in einigen Fällen AppLaunch.exe) aus dem Microsoft .NET Framework-Verzeichnis zu starten. Anschließend wird der erzeugte Prozess ausgehöhlt, indem die endgültige Nutzlast in ihn injiziert und ausgeführt wird.

Handelt es sich bei dem Beispiel nicht um eine .NET-Assembly, legt HeartCrypt eine Kopie von sich selbst an und injiziert die endgültige Nutzlast mithilfe einer ähnlichen Process-Hollowing-Technik. Während Process Hollowing die primäre Methode der Injektion ist, haben wir ein Beispiel identifiziert, das auf NtQueueApcThread verweist, was darauf hindeutet, dass der Entwickler Anstrengungen unternommen hat, um die Injektionsmethoden zu diversifizieren.

Ressource 5: HeartCrypt-Persistenz

Die fünfte Ressource scheint optional zu sein, da sie nicht in allen von uns identifizierten Beispielen vorhanden ist. Ihr Zweck ist es, mithilfe des Registrierungsschlüssels HKCU\Software\Microsoft\Windows\CurrentVersion\Run die Persistenz auf dem System herzustellen.

HeartCrypt legt eine aufgeblähte Version von sich selbst auf dem Dateisystem ab und fügt mehrere hunderttausend Kilobyte Null-Polsterung hinzu, bevor es sie in einem fest kodierten Dateipfad speichert. Anschließend setzt es den Schlüssel CurrentVersion\Run so, dass er auf diese Datei verweist. Um die Registrierung zu ändern, verwendet HeartCrypt entweder Windows-API-Funktionen oder den Befehl reg add über cmd.exe.

Abbildung 9 unten zeigt eine visuelle Darstellung des gesamten HeartCrypt-Ausführungsablaufs.

Extrahieren von HeartCrypt-Payloads

Nachdem wir die einzelnen Funktionen jeder eingebetteten Ressource innerhalb des HeartCrypt-Packers detailliert beschrieben hatten, bestand unser nächster Schritt darin, den Prozess der Extraktion von Nutzdaten zur weiteren Analyse zu automatisieren. Dazu musste ein Skript entwickelt werden, das in der Lage war, den XOR-Schlüssel innerhalb der BMP-getarnten Ressourcen zu identifizieren.

Obwohl die Verschleierung von HeartCrypt die statische Analyse stark behindert, ist die Extraktion der Schlüsselinformationen relativ trivial. Die verschlüsselte Nutzlast ist immer eine XOR-verknüpfte Ein-Byte-Windows-Binärdatei, so dass wir einige grundlegende Methoden verwenden können, um den Schlüssel zu erzwingen.

Der erste Schritt besteht darin, den Anfang der kodierten Nutzdaten innerhalb der Ressource zu lokalisieren, der sich immer am gleichen Offset befindet. Wir können davon ausgehen, dass die ersten 2 Bytes der kodierten Nutzdaten zu MZ (0x4D5A) dekodiert werden, den magischen Windows PE-Bytes, die sich am Anfang aller ausführbaren Dateien befinden. Da XOR-Operationen umkehrbar sind, können wir die verschlüsselten Bytes mit 0x4D5A XOR-verknüpfen, was zu den ersten 2 Bytes des XOR-Schlüssels führt.

Unkodierte ausführbare Windows-Dateien enthalten immer mehrere Blöcke mit Null-Bytes, z. B. direkt nach den Abschnittsüberschriften und unmittelbar vor dem Abschnitt .text. Wenn ein Null-Byte in einer Ein-Byte-XOR-Operation verwendet wird, ist das Ergebnis das Byte, das zur Durchführung der XOR-Operation verwendet wird. Daher wissen wir, dass bei der Kodierung der Nutzdaten der XOR-Schlüssel in diesen Blöcken enthalten ist.

Sobald wir die ersten Bytes des XOR-Schlüssels identifiziert haben, können wir die gesamte Binärdatei nach Sequenzen durchsuchen, die mit diesen 2 Bytes beginnen, was zu einer Liste möglicher Schlüssel führt. Wir versuchen dann, die Nutzlast mit jedem möglichen Schlüssel zu dekodieren. Wenn die resultierenden Daten eine gültige PE-Datei sind, können wir davon ausgehen, dass wir den richtigen Schlüssel identifiziert haben.

Während die Brute-Force-Methode bei jedem HeartCrypt-Beispiel, das wir gefunden haben, erfolgreich war, haben wir unsere Methode aktualisiert, um einen effizienteren Ansatz zu wählen.

Wie bereits erwähnt, enthält jede HeartCrypt-Ressource einen PIC-Block, der in zwei Schichten strukturiert ist: Die erste Schicht wendet eine Ein-Byte-Substitutionsoperation an, um die zweite zu entschlüsseln. Mithilfe der Frequenzanalyse können wir den Substitutionsschlüssel schnell identifizieren.

Bei unserer manuellen Analyse einer dekodierten HeartCrypt-Ressource PIC der zweiten Schicht stellten wir fest, dass die Bytes 0x00 und 0xFF am häufigsten vorkamen. Wir wissen, dass beim Verschlüsselungsprozess jedem Byte ein fester Wert hinzugefügt wird. Da 0x00 der häufigste Wert im dekodierten PIC ist, wird das häufigste Byte im kodierten PIC den Substitutionsschlüssel anzeigen. Wir haben diese Logik in unser Skript implementiert und es war erfolgreich bei der Dekodierung der ersten beiden Schichten der PIC-Ressourcenblöcke in allen HeartCrypt-Proben.

Die vierte HeartCrypt-Ressource enthält den XOR-Schlüssel, der als Stack-String im PIC der zweiten Schicht gespeichert ist. Nachdem wir den Prozess der Dekodierung des PIC automatisiert hatten, implementierten wir eine einfache Regex, um alle Stack-Strings zu extrahieren, so dass wir den XOR-Schlüssel für jede Probe identifizieren konnten, ohne uns auf Brute-Force zu verlassen.

Letztendlich waren wir in der Lage, die endgültigen Nutzdaten aus allen HeartCrypt-Samples zu extrahieren und gegebenenfalls weitere Verarbeitungsschritte wie die Extraktion der Konfiguration durchzuführen.

Bösartige Kampagnen mit HeartCrypt

Durch die Analyse der von unserer internen Telemetrie gesammelten Daten konnten wir ein besseres Verständnis der HeartCrypt-Aktivität gewinnen. Unsere Analyse zeigt, dass im Durchschnitt jeden Tag knapp 10 neue HeartCrypt-Samples gefunden werden, mit gelegentlichen Spitzen von 60 Samples, wie in Abbildung 10 dargestellt.

Einige dieser Spitzenwerte traten während der Entwicklungsphase auf, zwischen Juni 2023 und Mitte Februar 2024. Diese Proben hatten keine Nutzlasten oder Testnutzlasten, die 127.0.0.1 als C2-Adresse verwendeten, und viele enthielten Debug-Strings innerhalb der PIC-Schichten.

Unsere Analyse zeigt, dass die XOR-Schlüssel der Nutzdaten offenbar in gewissem Maße kundenspezifisch angepasst werden. In allen Stichproben fanden wir etwa 55 XOR-Schlüssel, die aus verschiedenen ASCII-Zeichenfolgen mit unterschiedlichen Themen bestehen. Zu diesen Themen gehören Monate, die auf die Kampagne hinweisen, Firmennamen von EDR/AV-Software sowie zufällige Zeichenfolgen, wie in Abbildung 11 unten dargestellt.

Die automatische Extraktion der Nutzdaten ermöglichte es uns, die Proben nach der identifizierten Malware-Familie zu gruppieren, wie in Abbildung 12 dargestellt.

Remcos ist die Nutzlast, die am häufigsten in allen HeartCrypt-Samples zu sehen ist, da die HeartCrypt-Entwickler sie während ihres Entwicklungszyklus häufig als Testnutzlast verwendeten. Wir haben in den letzten Monaten auch mehrere Cluster von Remcos beobachtet, die auf lateinamerikanische Länder abzielen. Weitere Einzelheiten finden Sie im Abschnitt "Indikatoren für eine Gefährdung" in diesem Artikel.

Lumma Steal ist eine weitere Nutzlast, die häufig von HeartCrypt-gepackten Samples eingesetzt wird. Wir haben vor kurzem HeartCrypt-Samples aus einer zuvor gemeldeten LummaStealer-Kampagne identifiziert, die sich als Software-Anbieter ausgeben, über die wir ursprünglich im Oktober 2024 berichteten.

Wir haben auch HeartCrypt-gepackte LummaStealer-Samples aus einer Kampagne entdeckt, die gefälschte CAPTCHAs und ein PowerShell-Skript zum Kopieren und Einfügen verwendet, das demjenigen ähnelt, über das wir ursprünglich im August 2024 berichtet haben. Diese Kampagnen sind seither aktiv geblieben.

Schlussfolgerung

Unsere Analyse von HeartCrypt - einer PaaS, die von verschiedenen Bedrohungsakteuren aktiv genutzt wird - zeigt, wie die Muster in freier Wildbahn aussehen, einschließlich der Extraktion von Nutzdaten für die Gruppierung. Wir haben die Entwicklung von HeartCrypt von der ersten Entwicklung im Juli 2023 bis zum Start im Februar 2024 dokumentiert und seine Verwendung in über 2.000 bösartigen Nutzdaten aus 45 Malware-Familien verfolgt.

Die Verschleierungstechniken des Packers kombinieren PIC, mehrere Verschlüsselungsebenen und ressourcenbasierte Ausführung, um die Analyse erheblich zu erschweren. Das PaaS-Modell von HeartCrypt, das in verschiedenen Untergrundforen vermarktet wird, senkt die Einstiegshürde für Malware-Betreiber und erhöht das Volumen und den Erfolg von Infektionen.

Diese niedrigere Einstiegshürde unterstreicht die Notwendigkeit für Verteidiger, eine proaktive Bedrohungsjagd zu betreiben und sich auf die Identifizierung einzigartiger Bytemuster und Packer-Merkmale zu konzentrieren, um verschleierte Malware zu erkennen. Außerdem zeigt die Leichtigkeit, mit der Bedrohungsakteure Dienste wie HeartCrypt nutzen können, die kontinuierliche Kommerzialisierung der Malware-Entwicklung.

Kunden von Palo Alto Networks sind durch die folgenden Produkte und Dienste besser vor den in diesem Artikel beschriebenen Bedrohungen geschützt:

• Cortex XDR und XSIAM
• Erweitertes WildFire

Wenn Sie glauben, dass Sie kompromittiert wurden oder ein dringendes Anliegen haben, wenden Sie sich an das Team von Unit 42 Incident Response oder rufen Sie an:

• Gebührenfrei für Nordamerika: 866.486.4842 (866.4.UNIT42)
• EMEA: +31.20.299.3130
• APAC: +65.6983.8730
• Japan: +81.50.1790.0200

Palo Alto Networks hat diese Erkenntnisse mit den anderen Mitgliedern der Cyber Threat Alliance (CTA) geteilt. CTA-Mitglieder nutzen diese Erkenntnisse, um ihren Kunden schnell Schutzmaßnahmen zu bieten und böswillige Cyber-Akteure systematisch zu stören. Erfahren Sie mehr über die Cyber Threat Alliance.

HeartCrypt YARA-Regel

Indikatoren für Kompromisse

A text-based CSV spreadsheet for the HeartCrypt samples we have identified so far is available at a link from our GitHub repository.

Zusätzliche Ressourcen

• LummaStealer Campaign – @Unit42_Intel on X
• Lumma Captcha Campaign – @Unit42_Intel on X
• Defender Emulation Talk [PDF] – Black Hat 2028, Alexei Bulazel
• RaspberryRobin AntiEmulation – Harfang Lab

Jerome Tujague