Michael Elford

Michael is a cybersecurity professional that is passionate about 
malware analysis and reverse engineering.

Eine weitere Analyse der ausführbaren Datei ergab, dass die Datei bösartig war.

In diesem Blogbeitrag möchte ich die Ergebnisse der Untersuchung weitergeben, mit dem Ziel, das Publikum auf die Techniken aufmerksam zu machen, die zur effektiven Analyse von Malware im Allgemeinen und zur Analyse von ASyncRAT im Besonderen eingesetzt werden können.

ASyncRAT-Analyse

Note: All malware analysis should be carried out in a sandboxed environment.

Dies ist die Liste der Tools, die für diese Analyse verwendet wurden:

• FlareVM
• PEStudio
• dnSpy
• Cyberchef
• Müllmann

Als wir mit der Analyse der ersten Phase der Malware begannen, bestand der erste Schritt darin, die ausführbare Datei in PEStudio zu überprüfen. Dabei wurde bestätigt, dass es sich um eine .NET- Datei handelte. Darüber hinaus haben wir die relativ hohe Entropie als Hinweis auf Malware-Packung interpretiert, bei der Malware die Komplexität erhöht, um von Sicherheitslösungen unentdeckt zu bleiben.

Unser nächster Schritt bestand darin, die Zeichenfolgen der Malware zu durchforsten und alle Merkwürdigkeiten zur Kenntnis zu nehmen, auf die wir später vielleicht etwas genauer eingehen möchten.

Bei der Untersuchung der Zeichenfolgen haben wir sofort einige Zeichenfolgen identifiziert, die scheinbar verschleiert sind . Als Hinweis für uns selbst haben wir darauf hingewiesen, dass wir später möglicherweise ein „ Suchen und Ersetzen “ implementieren müssen .

Weitergehen

Nachdem wir festgestellt hatten, dass die Datei in .NET geschrieben wurde, und uns die verschleierten Zeichenfolgen notiert hatten, wandten wir uns an dnSpy , einen .NET-Debugger.

Eines der ersten Dinge, die uns auffielen, war eine Namensdiskrepanz. Der Name der ausführbaren Datei auf dem Host und der in dnSpy angezeigte Name der ausführbaren Datei sind völlig unterschiedlich. Der Grund, warum die ausführbare Datei mit einem völlig anderen Namen von Interesse ist, liegt darin, dass viele Bedrohungsakteure, die Malware verwenden, diese umbenennen, sodass sie nicht so viel Aufmerksamkeit auf sich ziehen und auf dem Host verborgen und leise im Hintergrund ausgeführt werden können Selbst wenn der Benutzer bemerkt, dass in seinem System etwas Seltsames vor sich geht, überspringt er die Datei und denkt, dass dies normal ist, und löst beim Benutzer und seinem AV keine Alarme aus.

Wenn wir uns den Code ansehen, gibt es eine Ersetzungsfunktion für eine Zeichenfolge, die wir zuvor notiert haben. Da wir nun sicher sind, was das Verschleierungsmuster ersetzt, können wir überprüfen, um welche Zeichenfolgen es sich handelt, die uns möglicherweise einen Hinweis darauf geben könnten, was passiert.

Am Faden ziehen

Zur Analyse der verschleierten Zeichenfolgen haben wir CyberChef verwendet . In CyberChef haben wir die Funktion „Suchen/Ersetzen“ verwendet, um die im Code gefundene Ersetzungsfunktion auszuführen. Dies ermöglichte es uns, den klaren Text dessen zu sehen, was verschleiert wurde, was zu einem klareren Verständnis der Vorgänge im Code führte.

Das Endergebnis der obigen Übung lieferte uns die entschleierte Version der Zeichenfolgen, die „Load“ und „Invoke“ enthielten. Dies zeigte, dass durch den in der ausführbaren Datei enthaltenen Code etwas geladen und ausgeführt („aufgerufen“) werden würde.

Wenn Sie sich zu irgendeinem Zeitpunkt nicht sicher sind, welche Aktionen diese Methoden bewirken, schauen Sie am besten bei Google vorbei und suchen Sie nach Dokumenten. Es mag zunächst zeitaufwändig sein, ist aber ein wichtiger Teil der Analyse von Malware.

In dieser Phase der Analyse hatten wir genügend Erkenntnisse gesammelt, um damit zu beginnen, den Verlauf des Ausführungsablaufs der Malware zu skizzieren. Wir hatten festgestellt, dass die Malware etwas lud und ausführte und dass die Malware gepackt war und ausführbare Daten enthielt, die wir in der nächsten Analysephase sehen würden.

Auf der Suche nach dem Verborgenen

Für die Heap-Analyse wird das Tool Garbage Man verwendet – eine Technik, die es Analysten ermöglicht, einzugreifen und zu beobachten, wie sich die .NET-Malware entschlüsselt.

Die Analyse der Malware in Garbage Man half bei der Extraktion versteckter Daten, aus denen die zweite ausführbare Datei innerhalb der ersten ausführbaren Datei bestand.

Um die Malware weiter zu analysieren, haben wir die auf dem Host gefundene Original-Malware in Garbage Man ausgeführt. Zu Beginn haben wir eine Verzögerung von 300 ms mit 10 Schnappschüssen in 100-ms-Intervallen hinzugefügt.

Wir haben die Verzögerung hinzugefügt, um dem Prozess Zeit zu geben, mit der Ausführung zu beginnen, und die zusätzlichen Snapshots und Intervalle hinzugefügt, damit wir bei Bedarf die Differenz zwischen den Intervallen vergleichen können.

Nachdem Garbage Man die Datei ausgeführt hatte, hatten wir folgende Optionen:

• Durchsuchen Sie den Heap manuell und sehen Sie sich die Zeichenfolgen und Werte an, die in der ausführbaren Datei enthalten sind
• Nutzen Sie die Suchfunktion, um alle Schnappschüsse durchzusehen. Suchen Sie insbesondere nach Bytes, die mit dem Wert von MZ beginnen – dem PE-Header für ausführbare Dateien und DLL-Dateien – und ordnen Sie sie dann in absteigender Reihenfolge nach Größe. Die Suchfunktion liefert uns eine Ergebnisliste und wir können die Binärdateien mit MZ-Headern speichern und zur weiteren Analyse speichern.

Stufe zwei

Als wir uns mit stage2.exe befassten, stellten wir fest, dass bei der Überprüfung der Zeichenfolgen einige bemerkenswerte Win32-APIs hervorgehoben wurden, die von Malware genutzt werden . Einige herausgesprungene APIs standen im Zusammenhang mit der Manipulation von Prozessen [ T1055 ], insbesondere in diesem Fall mit Process Hollowing [ T1055.012 ] – eine gegnerische Technik, um einen angehaltenen, legitimen Prozess zu erstellen und dann seinen Speicher mit schädlichen Inhalten auszutauschen.

Da unsere zweite Stufe wieder in der .NET-Welt lag, nutzten wir dnSpy, um etwas tiefer zu graben. Als wir die ausführbare Datei öffneten, wurden wir mit einer Menge Informationen konfrontiert, die wir verarbeiten mussten. Wie bei der ersten Stufe war auch die Namenskonvention der zweiten Stufe verdächtig.

Als wir die Ausgabe von dnSpy untersuchten, entdeckten wir einen Abschnitt, der sich völlig von den anderen Teilen des Codes unterschied, da er verschleiert war und scheinbar eine Funktion im Speicher ausführte – beides Techniken, die verwendet werden, um der Erkennung zu entgehen [ T1140 ] .

Wir nutzten erneut Garbage Man, um heimlich zu beobachten, wie sich die Malware entschlüsselte. Wenn Sie jedoch eine alternative Technik zur Entschleierung dieses Teils des Codes wünschen, können Sie de4dot verwenden , das ihn möglicherweise auch in einem leichter lesbaren Format darstellt.

Als nächstes bestand das Ziel in Garbage Man darin, die dritte versteckte Stufe zu bergen . Unsere frühere Technik könnte hier erneut eingesetzt werden, indem die Binärdatei ausgeführt und nach den MZ-Headern gesucht wird.

Wir haben eine ausführbare Datei gefunden und als „stage3.exe“ gespeichert. Anschließend haben wir es verpackt und an PEstudio gesendet (darin sind auch Informationen für procexp.sys enthalten, aber wir werden uns zu diesem Zeitpunkt nicht darauf konzentrieren).

Stufe drei

Als wir die ausführbare Datei der dritten Stufe in PEstudio überprüften, stellten wir erneut fest, dass es sich um eine .NET-Datei handelte und dass sie Zeichenfolgen und APIs enthielt, die darauf hindeuteten, dass sie versuchte, eine Netzwerkverbindung zu einer externen Quelle herzustellen – wie der API Send . Dies war ein deutlicher Hinweis darauf, dass es sich um einen RAS-Trojaner handelte; Ich rieche eine RATTE [ TA0011 ]!

Nachdem wir über PEstudio einen kurzen Blick auf die Saiten der dritten Stufe geworfen hatten, sind wir zurück zum alten, zuverlässigen dnSpy gesprungen. Bei der Durchsicht von Phase drei stellten wir fest, dass AES-Verschlüsselung verwendet wurde, um den Port und die IP/Domäne zu verschlüsseln, die den Befehls- und Kontrollmechanismus (C2) des Angreifers bildeten. Wir hatten es mit Sicherheit mit einem RAT zu tun und wollten die mit dieser Verschlüsselung verbundenen IoCs erfassen.

Wir setzen in dnSpy einen Haltepunkt, an dem die AES-Entschlüsselung durchgeführt wurde, und führen dann den Debugger dafür aus, um die entschlüsselte Zeichenfolge zu finden. Die Verwendung einer „Stopp-Start“-Technik mit Haltepunkten in einem Debugger ermöglicht es einem Malware-Analysten, die Malware im richtigen Moment anzuhalten, während sie sich selbst ent- oder entschlüsselt. Dadurch können wir verstehen, was die Malware gerade tut.

Als wir an unserem Haltepunkt ankamen, wurde die Ausführung der Malware angehalten. Jetzt ließen wir die Malware vorsichtig Schritt für Schritt voranschreiten, indem wir die „Step-Over“-Schaltfläche nutzten. Wir taten dies, bis die Malware schließlich mit der Entschlüsselungsphase begann und wir zunächst die von dieser RAT verwendeten Ports erhielten.

Als wir die verschiedenen Abschnitte durchgingen, konnten wir erkennen, dass dieser RAT die Ports „6606, 7707, 8808“ verwendete, und schließlich entschlüsselten wir den RAT, bis er uns den gegnerischen Server lieferte, an den er zurückgemeldet hatte: „109.206.241.“ [.]84“.

Verteidigung gegen RATs

Unsere Abhilfemaßnahmen werden variieren, aber der erste Schritt besteht darin, die Blockierung dieser öffentlichen IPv4-Adresse auf der Firewall-Ebene der Organisation zu empfehlen, damit die RAT nicht mehr ausstrahlen kann.

Der Ratschlag zur Abwehr von RATs ist eigentlich ein Ratschlag für Malware insgesamt:

• Der wichtigste Ratschlag besteht darin, die Mitarbeiter darin zu schulen, zu überprüfen, was sie herunterladen. Ganz gleich, ob es sich um einen E-Mail-Anhang oder eine Website handelt, die verspricht, ihren Computer schneller laufen zu lassen, wenn sie etwas ausführt: Sicherheitsbewusstseinsschulungen sind die beste und erste Verteidigungsebene, deren Priorität wir Ihnen empfehlen.
• Nutzen Sie die Netzwerktelemetrie, um unerwartete Aktivitäten zu überwachen. Unabhängig davon, ob es sich um ein VPN, eine Firewall oder einen eher auf Sicherheit ausgerichteten Netflow handelt: Ein Auge auf den ein- und ausgehenden Datenverkehr hilft dabei, anomales Verhalten zu erkennen. Darüber hinaus kann es nur eine gute Sache sein , eine gut gepflegte Sperrliste für neue und aufkommende bösartige Adressen zu pflegen.
• Gute Sicherheitstools sind der perfekte Feind unserer Gegner. Stellen Sie bereit, was für Ihre Organisation funktioniert. Stellen Sie einfach etwas bereit . Eine Maschine ohne Sicherheitslösungen ist eine Maschine, die ein unkontrollierbares und inakzeptables Risiko für Ihr Unternehmen darstellt.

Big thanks to Matthew Brennan and Chad Hudson for help and guidance. 
Hopefully this writeup has helped show examples of some good tools and 
techniques that can be used to help decrypt and understand what is going on 
with other .NET executables in the future.