AceCryptor und seine Funktionsweise im Detail

Die wichtigsten Punkte dieses Blogposts

• AceCryptor bietet Packdienste für Dutzende von sehr bekannten Malware-Familien an.
• Samples von AceCryptor sind weltweit weit verbreitet, da mehrere Bedrohungsakteure, die diesen Cryptor verwenden, ihre gepackte Malware aktiv in ihren eigenen Kampagnen verbreiten.
• AceCryptor ist stark verschleiert und hat im Laufe der Jahre viele Techniken eingesetzt, um nicht entdeckt zu werden.
• AceCryptor hat mehrere Varianten, die in diesem Blogpost beschrieben werden.
• Obwohl es möglich ist, technische Analysen von anderen Forschern zu finden (meist dort, wo dieser Cryptor als Teil/Stadium anderer Malware auftritt), zielt ESET Research darauf ab, nicht nur einen umfassenden Überblick über die Funktionalität von AceCryptor, sondern auch über seine Geschichte und Verbreitung zu geben.
• In den Jahren 2021 und 2022 schützte ESET mehr als 80.000 Kunden vor Malware, die von AceCryptor gepackt wurde.

Statistik und verpackte Familien im Überblick

Seit dem ersten Auftauchen von AceCryptor im Jahr 2016 haben viele Malware-Autoren die Dienste dieses Cryptors in Anspruch genommen, sogar die bekannteste Crimeware wie Emotet, als sie noch keinen eigenen Cryptor verwendete. Zwischen 2021 und 2022 hat ESET mehr als 80.000 einzigartige Samples von AceCryptor entdeckt. Aufgrund der hohen Anzahl verschiedener Malware-Familien, die darin enthalten sind, gehen wir davon aus, dass AceCryptor irgendwo als CaaS verkauft wird. Wenn wir die Anzahl der entdeckten Dateien berücksichtigen, gehen wir davon aus, dass die Gewinne der AceCryptor-Autoren nicht unerheblich sind, auch wenn wir die genauen Preise für diesen Dienst derzeit nicht kennen.

Aufgrund der hohen Anzahl von Samples in den vergangenen Jahren basieren die folgenden Statistiken nur auf Samples, die in den Jahren 2021 und 2022 entdeckt wurden. Wie in Abbildung 1 zu sehen ist, waren die Entdeckungstreffer in diesen beiden Jahren recht gleichmäßig verteilt, was bei Malware zu erwarten ist, die von einer großen Anzahl von Bedrohungsakteuren verwendet wird, die ihre Kampagnen nicht synchronisieren.

Abbildung 1. Anzahl der AceCryptor-Erkennungen in den Jahren 2021 und 2022 (gleitender 7-Tage-Durchschnitt)

Nachdem wir uns die von AceCryptor gepackte Malware angesehen haben, fanden wir über 200 ESET-Erkennungsnamen. Natürlich kann eine Malware-Familie aufgrund von Updates oder Änderungen der Verschleierung mehrere Erkennungsnamen für die einzelnen Varianten haben - z. B. sind MSIL/Spy.RedLine.A und MSIL/Spy.RedLine.B beide Erkennungsnamen für die Malware RedLine Stealer. Die Erkennungsnamen für einige andere Malware sind nicht nach Familie, sondern nach Klasse geordnet (z. B. ClipBanker oder Agent), da es sich bei vielen entpackten Malware-Samples um generische Clipboard-Stealer, Trojaner usw. handelt, die nicht so weit verbreitet sind und/oder nur leicht modifizierte Varianten anderer bekannter Malware sind, die in verschiedenen öffentlichen Repositories veröffentlicht wurden. Nach der Gruppierung können wir feststellen, dass zu den Malware-Familien, die nach dem Entpacken gefunden wurden, SmokeLoader, RedLine Stealer, RanumBot, Raccoon Stealer, STOP ransomware, Amadey, Fareit, Pitou, Tofsee, Taurus, Phobos, Formbook, Danabot, Warzone und viele andere gehören... Abbildung 2 zeigt einen Überblick über die Anzahl der Samples, die zu einigen der bekannten und weit verbreiteten Malware-Familien gehören, die von AceCryptor gepackt wurden.

Abbildung 2. In AceCryptor verpackte Malware-Familien in den Jahren 2021 und 2022

Die Überwachung der Aktivitäten von CaaS-Anbietern wie AceCryptor ist hilfreich für die Überwachung von Malware, die deren Dienste nutzt. Nehmen wir als Beispiel einen RedLine Stealer, der erstmals im ersten Quartal 2022 auftauchte. Wie in Abbildung 3 zu sehen ist, nutzten die RedLine Stealer Distributoren AceCryptor seit dem Beginn der Existenz von RedLine Stealer und tun dies auch weiterhin. Wenn wir also in der Lage sind, AceCryptor (und andere CaaS) zuverlässig zu erkennen, hilft uns das nicht nur bei der Erkennung neuer Bedrohungen, sondern auch bei der Überwachung der Aktivitäten von Bedrohungsakteuren.

Abbildung 3. Vorkommen von RedLine Stealer in AceCryptor Samples (7-Tage-Durchschnitt)

Die Ziele

Wie angesichts der Vielfalt der in AceCryptor enthaltenen Malware und der unterschiedlichen Interessen der verschiedenen Malware-Autoren zu erwarten war, ist AceCryptor überall auf der Welt zu finden. In den Jahren 2021 und 2022 verzeichnete die ESET-Telemetrie mehr als 240.000 Erkennungstreffer dieser Malware, d. h. mehr als 10.000 Treffer pro Monat. In Abbildung 4 sehen Sie die Länder mit der höchsten Anzahl an Erkennungen in den Jahren 2021 und 2022.

Abbildung 4. Heatmap der laut ESET-Telemetrie von AceCryptor betroffenen Länder 

In den Jahren 2021 und 2022 haben ESET-Produkte Malware-Varianten, die von AceCryptor gepackt wurden, auf mehr als 80.000 Kundencomputern entdeckt und blockiert. Außerdem entdeckten wir über 80.000 einzigartige Samples von AceCryptor. Natürlich kann jedes Sample auf mehreren Computern entdeckt werden oder ein Computer wurde mehrfach von ESET-Software geschützt, aber die Anzahl der eindeutigen Hashes zeigt, wie aktiv die Autoren von AceCryptor an der Verschleierung und Umgehung der Erkennung arbeiten. Wir werden die technischen Details der Verschleierungen von AceCryptor im Teil "Technische Analyse" dieses Blogposts genauer untersuchen.

Erwähnenswert ist hier, dass die Anzahl der einzelnen Samples von AceCryptor zwar sehr hoch ist, die Anzahl der darin enthaltenen einzelnen Samples jedoch weniger als 7.000 beträgt. Dies zeigt, wie sehr sich viele Malware-Autoren auf die Dienste eines Cryptors verlassen und dass es scheinbar bequemer für sie ist, für diese Art von Dienstleistung zu bezahlen, anstatt ihre Zeit und Ressourcen in die Implementierung einer eigenen Cryptor-Lösung zu investieren.

Verbreitung

Da AceCryptor von mehreren Bedrohungsakteuren verwendet wird, wird auch die mit ihm gepackte Malware auf verschiedene Weise verbreitet. Laut ESET-Telemetrie wurden Geräte mit AceCryptor-gepackter Malware hauptsächlich über trojanisierte Installationsprogramme für raubkopierte Software oder Spam-E-Mails mit bösartigen Anhängen infiziert.

Eine andere Möglichkeit, wie jemand mit AceCryptor-gepackter Malware in Kontakt kommen kann, ist über andere Malware, die neue, durch AceCryptor geschützte Malware herunterlädt. Ein Beispiel dafür ist das Amadey-Botnet, bei dem wir beobachtet haben, dass es einen mit AceCryptor gepackten RedLine Stealer heruntergeladen hat.

Wir möchten anmerken, dass dies in beide Richtungen funktioniert und einige der von AceCryptor geschützten Malware-Familien auch neue, zusätzliche Malware herunterladen können.

Technische Analyse

Derzeit verwendet AceCryptor eine mehrstufige, dreischichtige Architektur. Es sind zwei Versionen des ersten Layers bekannt, die derzeit im Einsatz sind - eine Version, die TEA (Tiny Encryption Algorithm) zur Entschlüsselung des zweiten Layers verwendet, und eine Version, die einen linearen Kongruenzgenerator (LCG) von Microsoft Visual/Quick/C++ zur Entschlüsselung des zweiten Layers verwendet. Der zweite Layer besteht aus Shellcode, der Verteidigungstricks durchführt, und dann den dritten Layer entschlüsselt und startet. Dieser schließlich ist ein weiterer Shellcode, der ebenfalls einige Tricks zur Abwehr von Analyse anwendet und dessen Aufgabe es ist, diese Payload zu starten. Es sind zwei Versionen des dritten Layers bekannt: Eine Version führt Process Hollowing durch, während die andere einen Reflective Loader verwendet und ihr eigenes Image mit der PE der endgültigen Payload überschreibt.

Abbildung 5. Architektur von AceCryptor

Layer 1

Auch wenn es zwei Versionen von Layer 1 gibt, funktionieren sie sehr ähnlich. Ihre Hauptaufgaben lassen sich wie folgt zusammenfassen:

1. Laden des verschlüsselten Layers 2 in den zugewiesenen Speicher.
2. Entschlüsseln des Layers 2.
3. Aufruf oder Sprung zum Layer 2.

Der wichtigste Teil dieser Phase sind die Verschleierungen. Im Laufe der Jahre wurden immer wieder neue Verschleierungen hinzugefügt - bis zu dem Punkt, an dem fast jeder Teil der Binärdatei irgendwie randomisiert und verschleiert ist. Dies führt zu großen Problemen für jemanden, der versucht, YARA-Regeln oder statische Erkennungen zu entwickeln.

Loops

Die Autoren nutzen Schleifen ("Loops") für mehrere Verschleierungsmaßnahmen. Die erste und einfachste Technik besteht darin, Schleifen mit Junk-Code zu verwenden, um die Analyse zu erschweren. Wir haben die Verwendung von Junk-Code seit 2016 gesehen, als wir die ersten Samples von AceCryptor registriert haben. Diese Loops sind mit vielen API-Aufrufen gefüllt, die nicht nur Analysten verlangsamen, die nicht wissen, was vor sich geht, sondern auch die Protokolle von Sandboxen, die API-Aufrufe abfangen, überfordern und damit unbrauchbar machen. Die Schleifen können viele MOV-Anweisungen und mathematische Operationen enthalten, wiederum nur, um die Analysten zu verwirren und dadurch die Analysezeit zu verlängern.

Abbildung 6. AceCryptors Verschleierungen mit Loops und dem Verstecken wichtiger Teile des Codes

Die zweite Verwendung von Loops besteht darin, eine Verzögerung zu erreichen. Wir haben beobachtet, dass einige Versionen von AceCryptor den zweite Layer fast sofort starten, aber andere enthalten Schleifen, die so zeitaufwändig sind, dass sie die Ausführung sogar um mehrere Minuten verzögern können: Die Verzögerung der Ausführung einiger Teile der Malware ist eine bekannte Technik, aber die Verwendung von API-Aufrufen wie Sleep kann bereits einige Alarmzeichen auslösen. Selbst wenn dies nicht der Fall ist, implementieren einige Sandboxen wie Cuckoo Sandbox Techniken zum Überspringen des Ruhezustands, um die Verzögerung zu vermeiden und mit den interessanten Teilen fortzufahren. Die Implementierung von Verzögerungen durch Schleifen und die Ausführung von Junk-Code ist auch eine Komplikation bei der dynamischen Analyse, da der Analytiker erkennen muss, welche Schleifen Junk-Schleifen sind und daher übersprungen werden können.

Eine dritte Verschleierungstechnik mit Schleifen besteht darin, wichtige Operationen in ihnen zu verstecken. Unter den Junk-Schleifen gibt es einige, die auf eine bestimmte Iteration warten und genau während dieser Iteration passiert etwas. Normalerweise wird mit GetProcAddress eine API geladen, die später verwendet wird, oder eine Konstante wie der Offset der verschlüsselten Daten wird demaskiert. Wenn diese bestimmte Iteration einer Schleife nicht stattfindet, stürzt das Sample später ab. In Kombination mit Junk-Code bedeutet dies, dass man zur dynamischen Analyse der Malware zunächst analysieren muss, welche Schleifen oder Iterationen von Schleifen übersprungen werden können und welche nicht. Das bedeutet, dass der Analytiker entweder Zeit damit verbringen kann, Junk-Code zu analysieren oder zu warten, bis der gesamte Junk-Code ausgeführt wurde. In Abbildung 6 oben sehen Sie zwei Schleifen, von denen die erste eine für die spätere Ausführung wichtige Operation enthält, während die andere nur aus Junk-Code besteht. Natürlich kann es sein (und ist es in der Mehrzahl der Samples nicht), dass dies bei allen Schleifen nicht so leicht zu erkennen ist, insbesondere wenn die Schleifen mit den wichtigen Operationen auch Junk-Code enthalten.

Randomisierung – Du sollst nicht YARA!

Ein weiterer wichtiger Teil des ersten Layers ist die Randomisierung. Junk-Code und die zuvor erwähnten Schleifen werden in jedem Sample nach dem Zufallsprinzip verteilt, und zwar so, dass:

• sich die Anzahl der Iterationen ändert,
• sich API-Aufrufe ändern,
• sich die Anzahl der API-Aufrufe ändert und
• sich Junk-Arithmetik oder MOV-Befehle ändern.

Diese Randomisierung kann auch die Identifizierung des Entschlüsselungsalgorithmus und der Schlüssel erheblich erschweren. In Abbildung 7 und Abbildung 8 sehen Sie die ursprüngliche, unverschleierte und die verschleierte Version des TEA-Algorithmus zu sehen. In der verschleierten Version gibt es nicht nur unbrauchbare arithmetische Anweisungen, sondern auch einige Teile des Algorithmus sind in Unterprogramme unterteilt und bekannte Konstanten (Summe und Delta in Abbildung 7) sind maskiert, um eine korrekte Identifizierung des Algorithmus unwahrscheinlich oder zumindest schwieriger zu machen.

Abbildung 7. TEA-Entschlüsselungsfunktion - unverschleiert

Abbildung 8. TEA-Entschlüsselungsfunktion - verschleiert

Der Code ist nicht das einzige, was zufällig ist. Der verschlüsselte Layer 2 und sein Entschlüsselungsschlüssel werden derzeit in der Regel im .text- oder .data-Abschnitt gespeichert, aber sie werden durch einige Offsets versteckt, die sich zwischen den Samples ändern. Nach erfolgreicher Entschlüsselung des Layers 2: In einigen Samples befindet sich der Code am Anfang der entschlüsselten Daten, aber es gibt auch Samples, bei denen am Ende ein Block mit Zufallsdaten am Anfang steht und Sie den richtigen Offset kennen müssen, um den Anfang des Codes der Layer 2 zu finden.

Die Autoren von AceCryptor setzen auch die folgenden Merkmale nach dem Zufallsprinzip ein:

• Der PDB-Pfad beginnt immer mit C:\, aber der Rest des Pfades ist zufällig.
• Ressourcen mit zufälligen Namen und Inhalten, wie in Abbildung 9 zu sehen ist. Die Autoren von AceCryptor füllen Samples mit zufällig generierten Ressourcen, die zufällig generierte Daten enthalten. Wir gehen davon aus, dass dies geschieht, um Samples weniger verdächtig zu machen und das Auffinden der tatsächlich verschlüsselten Daten zu erschweren. Die Ressourcen können enthalten:
  • String Tables
  • Menüs
  • Bitmaps
  • Binärdaten
• Im Code verwendete Strings.
• Icons - auch wenn die Icons, die in vielen Samples verwendet werden, ähnlich aussehen, sind sie nur leicht verändert/zufällig angeordnet, um einzigartig zu sein.
• Zufällige Dummy-Namen für Abschnitte.
• Speicherzuweisungsfunktionen für Layer-2-Daten - GlobalAlloc, LocalAlloc und VirtualAlloc.
• Verwendung einiger APIs, die für die Codeausführung wichtig sind - sie können statisch importiert oder über GetModuleHandleA und GetProcAddress bezogen werden.

Abbildung 9. Die Ressourcen von AceCryptor werden nach dem Zufallsprinzip mit zufällig generierten Inhalten erzeugt, um Samples weniger verdächtig zu machen

Abbildung 10. AceCryptors zufällige Strings in Ressourcen

Vorherige Versionen

Im Laufe der Jahre wurden die Autoren von AceCryptor immer geübter in der Entwicklung von Malware und der Cryptor wurde verändert und weiterentwickelt. Auch wenn es viele kleinere Änderungen, Aktualisierungen und Verbesserungen gab, gehörten zu den interessanten Merkmalen der älteren Versionen von Layer 1 die folgenden:

• Im Jahr 2016 verwendete AceCryptor eine Version von Layer 1 mit XTEA-Verschlüsselungsalgorithmus.
• Im Zeitraum 2017-2018 verwendete AceCryptor eine weitere Layer-1-Version, bei der der Verschlüsselungsalgorithmus RC4 verwendet wurde.
• Die ersten (X)TEA- und LCG-Versionen von Layer 1 erschienen im Jahr 2016. Im Gegensatz zur LCG-Version wurde die XTEA-Version schnell nicht mehr verwendet und durch die TEA-Version ersetzt.
• In älteren Versionen war der verschlüsselte Layer 2 in den Ressourcen in einem BMP-Bild versteckt. Dieses Bild wurde nach dem Zufallsprinzip mit zufälliger Breite und Höhe erzeugt, und die Mitte des Bildes wurde herausgeschnitten und durch verschlüsselte Daten ersetzt. Die Daten mussten an der richtigen Stelle gefunden werden.

Layer 2

Layer 2 von AceCryptor erschien im Jahr 2019. Bis dahin startete AceCryptor Layer 3 direkt von Layer 1 aus. Dieser Layer dient als zusätzliche Verschlüsselung und Schutz von Layer 3 und besteht, wie Abbildung 11 zeigt, aus drei Teilen:

• positionsunabhängiger Code,
• eine benutzerdefinierte Struktur, die wir L2_INFO_STRUCT genannt haben und die Informationen über Layer 3 enthält, und
• die Daten des Layer 3

Abbildung 11. Layer-2-Struktur von AceCryptor

In einem ersten Schritt verwendet AceCryptor eine gängige Technik, um einige API-Funktionsadressen zu erhalten. Er löst die Funktionen GetProcAddress und LoadLibraryA auf, indem er PEB_LDR_DATA verwendet, um geladene Module zu durchlaufen, und indem er die Hash-Werte ihrer Exportnamen mit hartkodierten Werten vergleicht. Als Prüfsummenfunktion verwendet AceCryptor eine shl1_add-Funktion, die bereits in hashDb implementiert ist und die Identifizierung von aufgelösten APIs beschleunigen kann.

Def hash(data):
	  val = 0
	  for i in data:
		    b = i
			b = 0xff & (b | 0x60)
			val = val + b
			val = val << 1
			val = 0xffffffff & val
	  return val

Abbildung 12. shl1_add-Hash, in Python implementiert

Dann erhält AceCryptor ein Handle für kernel32.dll mit LoadLibraryA und verwendet dieses und GetProcAddress, um weitere APIs aufzulösen.

Für die nächsten Schritte verwendet AceCryptor Informationen aus seiner benutzerdefinierten Struktur L2_INFO_STRUCT (siehe Abbildung 13), die sich ganz am Ende des positionsunabhängigen Codes befindet, wie in Abbildung 11 zu sehen ist.

Struct __unaligned __declspec(align(1)) L2_INFO_STRUCT
{
	  DWORD encryptedDataSize;
	  DWORD keySeed;
	  BYTE compressionFlag;
	  DWORD decompressedDataSize;
	  … //empty fields (padding or reserved for future use) filled with zeros
}

Abbildung 13. Übersicht über den L2_INFO_STRUCT von Layer 2

In den nächsten Schritten entschlüsselt AceCryptor den Layer 3, der mit LCG von Microsoft Visual/QuickC/C++ verschlüsselt wird. Die Entschlüsselung erfolgt an Ort und Stelle. Wenn das compressionFlag gesetzt ist, weist AceCryptor mit der VirtualAlloc-API Speicher zu und dekomprimiert die entschlüsselten Daten mit dem LZO_1Z-Dekomprimierungsalgorithmus. Danach springt die Ausführung in den entschlüsselten und optional dekomprimierten Layer 3.

Layer 3 – Prozess Hollowing

Im ersten Schritt beschafft sich AceCryptor die Adressen der LoadLibraryA- und GetProcAddress-APIs auf dieselbe Weise wie in ` 2 - es durchläuft geladene Module, durchläuft Exporte und verwendet shl1_add-Prüfsummen. Dann erhält AceCryptor die Adressen mehrerer API-Funktionen und DLL-Handles.

Abbildung 14. Struktur des Layer 3 von AceCryptor - Prozess Hollowing

Im nächsten Schritt verwendet AceCryptor die API GetFileAttributesA und prüft die Dateisystemattribute einer Datei namens apfHQ. Die Attribute werden mit einer nicht vorhandenen Kombination von Flags 0x637ADF verglichen, und wenn sie gleich sind, landet das Programm in einer Endlosschleife. Da dies im letzten Layer verwendet wird, der bereits gut versteckt ist, und da dies nicht der einzige Trick hier ist, gehen wir davon aus, dass es sich nicht um eine weitere Verschleierungstechnik handelt, sondern eher um einen undokumentierten Anti-Sandbox/Anti-Emulator-Trick gegen eine unbekannte, aber spezifische Sandbox/einen Emulator, der diesen Wert zurückgibt.

Wenn das Programm erfolgreich fortgesetzt wird, erfolgt eine weitere Anti-Sandbox/Anti-Emulator-Prüfung. Nun verwendet AceCryptor die API RegisterClassExA, um eine Klasse mit dem Klassennamen saodkfnosa9uin zu registrieren. Dann versucht er, mit der API CreateWindowExA ein Fenster mit dem Namen mfoaskdfnoa zu erstellen. Im letzten Schritt dieser Prüfung versucht AceCryptor, die APIs PostMessageA und GetMessageA zu verwenden, um eine Nachricht zu übergeben. Da diese APIs nicht so häufig verwendet werden, hilft diese Prüfung, Sandboxen/Emulatoren zu umgehen, die diese APIs nicht implementiert haben oder bei denen die emulierten APIs nicht richtig funktionieren.

Abbildung 15. Anti-VM/Anti-Emulator-Trick

Nachdem diese Prüfungen erfolgreich bestanden wurden, verwendet AceCryptor die Technik des Process Hollowing, bei der eine neue Instanz des aktuellen Prozesses erstellt wird (GetCommandLineA, CreateProcessA), die endgültige Payload dem neu erstellten Prozess zugeordnet und dieser gestartet wird.

Vorherige Versionen

Der Anti-Investigation-Trick mit RegisterClassExA, CreateWindowExA, PostMessageA, GetMessageA wurde in früheren Versionen (z. B. SHA-1: 01906C1B73ECFFD72F98E729D8EDEDD8A716B7E3) auf Layer 1 verwendet und später (als er getestet und die Architektur des Cryptors weiterentwickelt wurde) auf Layer 3 verschoben.

Layer 3 – Reflective Loader

Der erste Schritt dieses Layers, ähnlich wie Layer 2 und Layer 3 - Process Hollowing, beschafft die Adressen der API-Funktionen GetProcAddress und LoadLibraryA. Der Unterschied besteht darin, dass die Autoren dieses Mal aus irgendeinem Grund nicht die Prüfsummenfunktion shl1_add verwendet haben, sondern zunächst die GetProcAddress über das Durchlaufen geladener Module, das Durchlaufen von Exporten und den Vergleich von Zeichenketten ermitteln. Dann verwenden sie GetProcAddress, um die Funktion LoadLibraryA zu erhalten. Mit diesen beiden APIs lädt AceCryptor die Adressen einiger weiterer API-Funktionen und ein Handle zu kernel32.dll.

Abbildung 16. Aufbau des Layer 3 Reflective Loaders

In dem Code gibt es einen Trick (siehe Abbildung 17), bei dem AceCryptor Code mit Daten vermischt. AceCryptor kontrolliert einen Wert, der nach einem Aufruf an der Rücksprungadresse steht. Dieser Wert wird standardmäßig auf Null gesetzt, und später schreibt AceCryptor dort die Adresse des Eingangspunkts der endgültigen Payload hinein. Wenn das Programm gepatcht wird und der Wert auf einen Wert ungleich Null gesetzt wird, springt das Programm zu der Adresse, auf die dieser Wert zeigt, und stürzt ab.

Abbildung 17. Mischen von Code und Daten

Im nächsten Schritt führt AceCryptor eine bekannte Anti-VM-Prüfung durch, die sich gegen die Sandbox von Cuckoo, IDA Pro+Bochs und Norman SandBox richtet. In Abbildung 19 ist zu sehen, dass das Flag SEM_NOALIGNMENTFAULTEXCEPT mit dem Wert 0x04 immer von der Cuckoo-Sandbox gesetzt wird. Aus diesem Grund gibt der zweite Aufruf von SetErrorMode im Code aus Abbildung 18 nicht denselben Wert zurück, der durch den vorherigen Aufruf gesetzt wurde.

Abbildung 18. Anti-VM Trick

Abbildung 19. Code der Cuckoo Sandbox

In den letzten Schritten prüft AceCryptor zunächst, ob die endgültige Payload (erneut) komprimiert wurde, und wenn ja, verwendet er die LZO_1Z-Dekompression. Ähnlich wie Layer 2 verwendet der Reflective Loader von Layer 3 eine benutzerdefinierte Struktur, die wir ENCRYPTED_DATA_INFO_STRUCT genannt haben (Abbildung 16). Sie befindet sich direkt zwischen dem positionsunabhängigen Code und der endgültigen Payload und enthält Informationen wie das Komprimierungsflag, die Anzahl der Abschnitte der Payload, die (de)komprimierte Größe der Payload, die Adresse des Einstiegspunkts, die Adressen einiger Verzeichnisse, die Adresse der Bildverschiebungstabelle und so weiter. AceCryptor verwendet diese Informationen (im Gegensatz zu Layer 3 - Process Hollowing, das die PE der endgültigen Payload analysiert), um eine reflektierende Codeladetechnik anzuwenden, bei der er sein eigenes Image mit dem Image der endgültigen Payload neu mappt (map sections, rebase image, ...) und die Payload durch den Aufruf ihres Einstiegspunkts startet.

Fazit

AceCryptor ist eine langlebige und weit verbreitete Crypto-Malware, die auf der ganzen Welt verbreitet ist. Wir gehen davon aus, dass sie irgendwo im Dark Web/ in Untergrundforen als CaaS verkauft wird. Die Dienste dieser Malware wurden von Dutzenden verschiedener Malware-Familien genutzt, und viele von ihnen verlassen sich auf diesen Cryptor als ihren Hauptschutz gegen statische Erkennungen.

Da die Malware von vielen Bedrohungsakteuren verwendet wird, kann jeder betroffen sein. Aufgrund der Vielfalt der gepackten Malware ist es schwierig abzuschätzen, wie schwerwiegend die Folgen für ein gefährdetes Opfer sind. AceCryptor kann durch andere Malware, die bereits auf dem Rechner des Opfers läuft, eingeschleust worden sein, oder wenn das Opfer direkt betroffen wurde, z. B. durch das Öffnen eines bösartigen E-Mail-Anhangs, könnte die darin enthaltene Malware zusätzliche Malware heruntergeladen haben. Daher kann es sehr schwierig sein, den befallenen Rechner zu reinigen.

Auch wenn es derzeit nicht möglich ist, AceCryptor einem bestimmten Bedrohungsakteur zuzuordnen, und wir davon ausgehen, dass AceCryptor weiterhin weit verbreitet sein wird, wird eine genauere Überwachung dazu beitragen, neue Kampagnen von Malware-Familien, die diesen Cryptor enthalten, zu verhindern und zu entdecken.

IOCs

Files

Hinweis: Die aufgelisteten Dateien sind eine sinnvolle Auswahl von Samples im Laufe der Zeit, die verschiedene Versionen von AceCryptor abdecken oder unterschiedliche Malware enthalten.

Named objects

MITRE ATT&CK techniques

This table was built using version 12 of the MITRE ATT&CK enterprise techniques.