Entmystifizierung von Ransomware-Techniken mithilfe von.NET-Assemblys: EXE- und DLL-Assemblys

In Teil eins In dieser Serie haben wir einige Techniken untersucht, die von Schadsoftware verwendet werden. Ransomware speziell. Wie wir gesehen haben, sind diese einzelnen Techniken wie Downloader, Dropper und Loader sowie Kodierung und Verschlüsselung allesamt legitime, programmierbare Funktionen, die von .Net (Punktnetz-) Software-Framework und viele andere Programmierframeworks und Codesprachen. Im Folgenden finden Sie eine Collage einiger der im vorherigen Artikel erörterten Techniken.

In diesem zweiten Artikel werden wir die Grundlagen von Assemblys anhand des Frameworks von Microsoft untersuchen .Net. Wir werden uns eingehender mit den Unterschieden zwischen Assemblys (EXE und DLL) und ihren Beziehungen befassen, die es ermöglichen, wie diese Funktionen letztendlich von einem anfänglichen High-Level-Code wie C#-Programmiercode aus ausgeführt werden. Wir werden den im vorherigen Artikel vorgestellten Code verwenden, um diese Unterschiede und Zusammenhänge zu untersuchen.‍

Was ist Microsoft.Net?

Microsoft .Net ist ein Framework für die Softwareentwicklung, das mehrere Programmiersprachen unterstützt und auf verschiedene Betriebssysteme abzielt. Unterstützte Programmiersprachen wie C# (ausgesprochen C-Sharp) werden kompiliert und als sogenannter verwalteter Code ausgeführt (im Gegensatz zu unverwaltetem oder systemeigenem Code). Um dies zu erreichen, .Net führt seinen Code auf einer dedizierten virtuellen Maschine aus und nicht direkt auf der Zielplattform. Diese virtuelle Maschine ist bekannt als .Net Common Language Runtime (CLR). Man kann es sich als den gemeinsamen Vermittler vorstellen, der schließlich den kompilierten oder zusammengestellten Code aus all den verschiedenen Programmiersprachen wie C#, VB.Net und F# ausführt .Net unterstützt. Dieses Beispiel unten zeigt den C#-Programmiersprachencode aus dem vorherigen Artikel.

Verwalteter Code bedeutet, dass der oben genannte C#-Programmiersprachencode auf hoher Ebene und andere wie F# und VB.Net zuerst in eine Zwischensprache (IL) kompiliert werden. Der oben abgebildete C#-High-Level-Code wird in die Anweisungen für die Zwischensprache kompiliert, die in der Abbildung unten gezeigt werden. Dieser Code ähnelt der Assembler-Programmiersyntax auf niedriger Ebene.

Diese Zwischensprache (IL) wird dann weiter zu nativem Code oder Maschinencode kompiliert, der auf die jeweilige Maschinenplattform abzielt. Diese Kompilierung erfolgt durch einen anderen .Net Komponente namens Just-in-Time (JIT) -Compiler.

Systemeigener Code oder Maschinencode ist eine Reihe von Anweisungen (Nullen und Einsen), die der Prozessor (CPU) eines bestimmten Computers versteht. Dieser letzte Schritt wird von der Common Language Runtime (CLR) verwaltet, die auch das JIT enthält. Die CLR ist die .Net Laufzeitumgebung oder virtuelle Maschine. Java ist ein weiteres Software-Framework, das das Konzept der Zwischenlaufzeiten verwendet. Ähnlich wie die Java Virtual Machine ist es ein Hauptbestandteil dessen, was .Net plattformunabhängig. .Net Code wird als verwalteter Code bezeichnet, da der Programmiercode von der zwischengeschalteten CLR verwaltet und nicht direkt von der CPU des Computers ausgeführt wird.

Ein Vorteil von verwaltetem Code in .Net ist automatische Speicherverwaltung und Garbage Collection. Das bedeutet, dass sich der Entwickler keine Gedanken über die Zuweisung und Freigabe von Computerspeicher in seinem Code machen muss, um Systemressourcen zu schonen, wie es beispielsweise bei C- oder C++-Code der Fall ist. In .Net, da ist der Garbage Collector, der regelmäßig ausgeführt wird, um freigegebenen Speicher zu verarbeiten. Er kann bei Bedarf auch vom Programmierer aufgerufen werden. Das folgende Diagramm zeigt die Architektur eines .Net Bewerbung.

Im Gegensatz dazu, nicht-.Net Compiler wie VB6, C und C++ kompilieren ihren High-Level-Code direkt in den Maschinencode der Zielplattform (Betriebssystem und CPU). Die resultierende ausführbare Datei oder die Assembly von Code ist daher an die Zielmaschinenplattform des Compilers gebunden. Dies wird auch als unverwalteter oder systemeigener Code bezeichnet. Obwohl es sich architektonisch unterscheidet, ist es möglich, Code aus Assemblys zu verwenden, insbesondere DLLs, die in nativem Code in einem .Net-verwaltete Anwendung mithilfe einer Funktion, die bekannt ist als Interop Marshalling (Plattformaufruf). Beispiele hierfür sind die Verwendung nativer Windows-Betriebssystem-DLLs oder externer Bibliotheken, wie z. B. in C++ geschriebener Code, auf den in einem verwalteten System verwiesen wird .Net Anwendung, um einige Funktionen des Betriebssystems auf niedriger Ebene zu aktivieren. In diesem Fall .Net selbst kann als sichere Hülle für die nativen DLLs betrachtet werden, auf die das Windows-Betriebssystem angewiesen ist und von denen ein Großteil tatsächlich in C++ geschrieben ist.‍

Was ist eine .Net-Assembly?‍

Microsoft beschreibt .Net Baugruppen als eine einzige Einsatzeinheit. Das bedeutet, dass eine Assembly eine Sammlung verschiedener Arten von Code und zugehörigen Dateien ist, die in eine Form kompiliert (zusammengestellt) wurden, die auf jeder kompatiblen Version ausgeführt werden kann .Net Zielplattform. Die Ausführung erfolgt durch .Nets gemeinsame Sprachlaufzeit. Beispiele für Assemblys im Windows-Betriebssystem sind ausführbare Dateien (.exe) und Klassenbibliotheken oder DLL-Dateien (Dynamic Link Library).

Wenn Sie sich das folgende Beispielcodebild genauer ansehen, sehen Sie links die ausführbare C#-Assembly und rechts einen weiteren C#-DLL-Assemblycode (auch als Klassenbibliothek bekannt). Der ausführbare Code verweist auf die DLL-Datei und ruft dann während der Ausführung eine bestimmte Methode (Funktion) aus dem DLL-Code auf. Diese Verweise und Aufrufe wurden in der Abbildung unten hervorgehoben. Wir werden die Details beider Codeteile später in diesem Artikel erläutern. In dieser Serie werden wir auch zeigen, wie diese Kombination für böswillige Ziele verwendet werden kann.

Im nachfolgenden Beispiel wird die DLL-Datei im ausführbaren Code manuell referenziert. Das bedeutet, dass die DLL und zugehörige Informationen zu ihren Metadaten sowie Code (bestehend aus Modulen, Klassen und Methoden) während der Kompilierung des ausführbaren Codes referenziert werden.

Als gemeinsam genutzte Bibliothek kann DLL-Code nicht direkt alleine ausgeführt werden. Aus Sicht des Codes liegt das daran, dass DLLs keine Haupteinstiegspunktfunktion haben, von der aus sie ausgeführt werden können, und daher nicht als eigenständiger Code ausgeführt werden können, so wie es ein ausführbarer Code (.exe) eingerichtet ist. Die folgende Fehlermeldung zeigt beispielsweise, welche Folgen der Versuch hat, eine Klassenbibliothek oder DLL-Datei direkt von einem Compiler aus auszuführen.

Ausführbarer Code hingegen hat eine Haupteinstiegspunktfunktion oder -methode, mit der die Ausführung beginnt, aber eine DLL benötigt nicht wirklich eine Haupteinstiegspunktfunktion, da es sich in erster Linie um eine Bibliothek von Codeblöcken handelt, auf die von anderen Assemblys verwiesen wird.

Einmal referenziert, kann der spezifische Code in der DLL-Datei, der von Interesse ist, zur Ausführung aufgerufen werden. Wie im vorherigen Artikel gezeigt, wiederholen die folgenden Codebeispiele (EXE und DLL) diesen Punkt.

Die ausführbare Anwendung wird ausgeführt und ruft Code aus der DLL auf, auf die sie verwiesen hat, um die in der folgenden Abbildung gezeigte Ausgabe zu erzeugen.

Dieses einfache Programm zeigt, wie .Net Assemblys wie EXEs und DLLs können zusammen verwendet werden.

Der oben erwähnte DLL-Code hat eine Methode (Funktion), die zwei Parameter pro Eingabe verwendet — einen Vornamen und ein Alter — und dann eine Begrüßungsnachricht mit diesen Informationen anzeigt. Der ausführbare Code hingegen führt Code aus, der Benutzereingaben wie Vorname und Alter von der Befehlszeile akzeptiert und diese Informationen dann als Argumente oder Eingaben an die DLL-Methode weiterleitet. Die Meldung aus dem DLL-Code wird dann mithilfe der Informationen, die die EXE-Anwendung vom Benutzer gesammelt hat, wieder auf dem Konsolenbildschirm angezeigt. ‍

.NET-Assemblys

‍Wenn Sie eine statische Analyse der ausführbaren Datei durchführen, werden die verschiedenen Referenzen von DLLs und anderen Komponenten angezeigt, die zur Ausführung importiert wurden. Zusätzlich zu unserer eigenen benutzerdefinierten DLL importiert die ausführbare Assembly auch zusätzliche DLLs, die mit folgenden Elementen verknüpft sind .Net selbst wie mscorlib das ist eine DLL, die Basiscode (Klassen, Typen usw.) enthält und etwas ist, das unser Programm benötigt, um reibungslos zu laufen.

In unserer Codeentwicklungsumgebung Visual Studio können wir die Verwendung von bestätigen mscorlib indem er seinen Ursprung in einem der Datentypen zurückverfolgt (in diesem Fall Schnur von System.Zeichenfolge in .Net). Dies zeigt das eingebaute .Net Baugruppe, von der dieser Typ stammt, welcher ist mscorlib wie unten gezeigt.

Eine Zeichenfolge ist in der Programmiersprache ein Datentyp, bei dem der Text, den der Benutzer eingibt und der dann wieder angezeigt wird, gespeichert wird. Aus unserer statischen Analyse können wir auch die DLL mit dem Namen „" entnehmenDLL_DontNet_Assembly.“ Dies ist unsere benutzerdefinierte DLL, die die Datei“ enthältDisplayMsg-Methode“ Methode, die dem Benutzer eine Nachricht anzeigt, nachdem er seine Daten eingegeben hat.

In unserem Beispiel haben wir während der Compilierung unseres gesamten Codes auf unsere benutzerdefinierte DLL Bezug genommen und sie manuell geladen, bevor das Programm ausgeführt wurde. Es ist auch möglich, während der Ausführung einer ausführbaren Datei auf eine DLL zu verweisen. This can be especially in cases, when we have during the compiliering our codes may not access on the required dll. This process is defined as reflexion and allows the investigation a .Net Assembly (Metadaten and Attributes) and also for use of code (Module, Classes, Methods and Properties), der darin enthalten ist, während der Laufzeit unseres Programms. This technology can also be optimiert werden, im Rückblick auf böswillige Ansichten bei sogenannten reflektierenden DLL-Injektionsangriffen.‍

.Net Assemblys (ausführbare Dateien und Klassenbibliotheken) bestehen auch aus einer Manifestdatei, die Metadaten über Assembly und den Intermediate Language (IL) -Code enthält, die Common Language Runtime zusammen ermöglichen, sodass die Assembly auf jeder kompatiblen Plattform ausgeführt werden kann, die ausgeführt werden kann .Net. The image below shows the IL assembly instructions and the manifest structure of both assemblys — EXE and DLL. The manifest file contains the metadata about .Net Montage wie Versionsnummer, Beschreibung usw.

Wir sollten jetzt ein grundlegendes Verständnis von haben .Net Software-Framework, die entsprechenden Assemblys und wie sie miteinander interagieren können.

Im nächsten Artikel werden wir die Techniken und Fähigkeiten, die wir bisher erwähnt und gelernt haben, in einer einzigen ausführbaren bösartigen Ransomware-Datei zusammenfassen.

Erfahre mehr also, wie Illumio Zero Trust Segmentation Ihnen helfen kann, Ransomware-Angriffe einzudämmen.