Auf der Suche nach Hinweisen auf DLL-Side-Loading mit PowerShell und Sysmon

Seitenansicht eines Softwareentwicklers, der während der Arbeit von zu Hause aus am Computer programmiert

Autor

John Dwyer

Head of Research

IBM Security X-Force

Vor kurzem hat X-Force Red ein Tool namens Windows Feature Hunter veröffentlicht, das mithilfe von Frida Ziele für das Side-Loading von DLL-Dateien (Dynamic Link Library) auf einem Windows-System identifiziert. Um eine defensive Gegenmaßnahme für das Side-Loading von DLLs zu bieten, hat X-Force Incident Response SideLoaderHunter veröffentlicht, ein Systemprofilierungsskript und eine Sysmon-Konfiguration, die dazu dienen, Hinweise auf Side-Loading auf Windows-Systemen zu identifizieren. In diesem Beitrag wird erläutert, warum IBM X-Force dieses Tool für notwendig erachtet, seine Funktionen beschrieben und einige Anwendungsfälle analysiert.

Was ist DLL-Sideloading?

In Microsoft Windows können Programme festlegen, welche Bibliotheken zur Laufzeit geladen werden, indem sie einen vollständigen Pfad angeben oder einen anderen Mechanismus wie beispielsweise ein Manifest verwenden. Ein Programmmanifest ist eine externe Datei oder eine eingebettete Ressource innerhalb einer Anwendung, die zur Verwaltung der Namen und Versionen von gemeinsam genutzten Side-by-Side-Assemblies dient, die die Anwendung bei der Ausführung laden soll. Ein Programmmanifest kann DLL-Umleitungen, Dateinamen oder vollständige Pfade enthalten. Wenn ein Manifest nur auf einen Bibliotheksdateinamen verweist, gilt es als schwache Referenz und ist anfällig für einen DLL-Side-Loading-Angriff.

Wenn eine schwache Referenz auf eine Bibliothek erstellt wird, versucht Windows, die DLL anhand einer vordefinierten Suchreihenfolge zu finden. Der erste Speicherort, den Windows durchsucht, ist das Verzeichnis, aus dem die Anwendung geladen wird.

Ein DLL-Side-Loading-Angriff ist eine Technik, die darauf abzielt, schwache Bibliotheksreferenzen und die Standard-Suchreihenfolge von Windows auszunutzen, indem eine bösartige DLL-Datei, die sich als legitime DLL tarnt, auf einem System platziert wird, wo sie automatisch von einem legitimen Programm geladen wird.

Für weitere Informationen zum DLL-Seitenladen siehe MITRE ATT&CK Technique T1574.002.

Die neuesten Tech-News – von Experten bestätigt

Bleiben Sie mit dem Think-Newsletter über die wichtigsten – und faszinierendsten – Branchentrends in den Bereichen KI, Automatisierung, Daten und mehr auf dem Laufenden. Weitere Informationen finden Sie in der IBM Datenschutzerklärung.

Vielen Dank! Sie haben sich angemeldet.

Ihr Abonnement wird auf Englisch geliefert. In jedem Newsletter finden Sie einen Abmeldelink. Hier können Sie Ihre Abonnements verwalten oder sich abmelden. Weitere Informationen finden Sie in unserer IBM Datenschutzerklärung.

Bedrohungslandschaft durch DLL-Sideloading

Das Side-Loading von DLL-Dateien ist keine neue Technik, da die Sicherheitslücke im Zusammenhang mit der Suchreihenfolge in Windows bereits seit Windows XP besteht. X-Force hat beobachtet, dass DLL-Side-Loading vom Metamorfo-Banking-Trojaner verwendet wird, der schädliche MSI-Dateien ablegt, die eine signierte Binärdatei und eine schädliche DLL extrahieren, um einen Malware-Loader der zweiten Stufe auszuführen. Aufgrund der in Windows integrierten Standardsuchreihenfolge lädt die signierte Binärdatei die schädliche DLL und setzt den schädlichen Ausführungsablauf fort.

Obwohl es sich nicht um die von Bedrohungsakteuren am häufigsten verwendete Technik handelt, wird DLL-Side-Loading zunehmend von Ransomware-Betreibern eingesetzt, die DLL-Side-Loading nutzen,um die Ransomware-Payload auszuführen und so der Erkennung durch Sicherheitsprodukte zu entgehen.

Zum Beispiel nutzte der Ransomware-Betreiber REvil eine DLL-Sideloading-Schwachstelle in einer Windows-Defender-ausführbaren Datei (MsMpEng.exe), um eine bösartige DLL namens mpsvc.dll zu laden, die die Ransomware-Payload enthält.

Mixture of Experts | 12. Dezember, Folge 85

KI entschlüsseln: Wöchentlicher Nachrichtenüberblick

Schließen Sie sich unserer erstklassigen Expertenrunde aus Ingenieuren, Forschern, Produktführern und anderen an, die sich durch das KI-Rauschen kämpfen, um Ihnen die neuesten KI-Nachrichten und Erkenntnisse zu liefern.

Erkennung von DLL-Sideloading

X-Force hat nur wenige Fälle beobachtet, in denen Bedrohungsakteure oder Malware vorhandene Binärdateien oder Module auf einem System überschreiben, um einen DLL-Side-Loading-Angriff auszuführen, da dies zu einem Systemabsturz oder zu Fehlern führen könnte, die wiederum eine Erkennung verursachen.

Stattdessen nutzen Bedrohungsakteure oder Malware, die DLL-Side-Loading einsetzen, vor der Ausführung eines Angriffs in der Regel zwei Vorgehensweisen:

  1. Ein signiertes ausführbares Programm wird zusammen mit der schädlichen DLL in einem Zielverzeichnis abgelegt.
  2. Das Verschieben einer Windows-ausführbaren Datei aus System32 oder SysWow64 auf dem Zielcomputer in ein nicht standardmäßiges Verzeichnis und das Platzieren der schädlichen DLL im selben Ordner.

Der erste Anwendungsfall ist eine relativ einfache Erkennungsmethode. Auch wenn die Binärdatei signiert ist, würde ihre Ausführung dennoch als Anomalie innerhalb eines Programm-Ausführungsdatensatzes angesehen werden. Im zuvor erwähnten Metamorfo-Beispiel hat die Malware das Speicherauszugsprogramm AVDump32.exe von Avast installiert. das in jesus.exe umbenannt wurde und eine schädliche DLL namens dbghelp.dll seitlich geladen hat.

In diesem Beispiel wurde die Identifizierung von jesus.exe durch eine Frequenzanalyse der Dateinamen erreicht, die in einem Datensatz zur Programmausführung aufgezeichnet wurden.

Frequenzanalyse der Binärnamen im Datensatz zur Programmausführung

Abbildung 1: Frequenzanalyse der Binärnamen im Datensatz zur Programmausführung

Der zweite Anwendungsfall kann schwieriger zu erkennen sein, da er häufig vertrauenswürdige Standard-Windows-Anwendungen nutzt, um die schädliche DLL auszuführen, wodurch sich die schädliche Aktivität besser in die Daten zur Ausführung nicht schädlicher Programme einfügt. Es gibt Möglichkeiten zur Erkennung durch eine Frequenzanalyse des vollständigen Pfads der Binärdatei innerhalb eines Programmausführungsdatensatzes, aber ohne jegliche Filterung ist diese Analyse viel zu ineffizient.

Stattdessen kann der Datensatz zur Programmausführung standardmäßig so gefiltert werden, dass er nur ausführbare Dateien enthält, die sich in System32 oder SysWow64 befinden. In diesem Fall würde die Analyse für alle Programmausführungsdaten durchgeführt werden, die mit ausführbaren Dateien in System32 oder SysWow64 in Verbindung stehen, bei denen der vollständige Pfad der Binärdatei nicht mit dem Standardpfad übereinstimmt.

Um diese Analyse durchzuführen, erstellen Sie eine Lookup-Tabelle der Standard-Ausführungsdateien von System32 und SysWow64 aus Windows-Systemen, die als Kontrolldatensatz dient, anhand dessen Verteidiger Anomalien identifizieren können.

Das folgende PowerShell-Skript listet die Ausführungsdateien in System32 und SysWow64 auf und exportiert die Ergebnisse in eine CSV-Datei.

Die Verwendung von sysbins.csv als Kontrollgruppe ermöglicht die Identifizierung der Programmausführung und liefert Hinweise auf Windows-Anwendungen außerhalb ihrer Standardverzeichnisse System32 oder SysWow64.

$SysBinList = Get-ChildItem $env:SystemRoot\system32\
,$env:SystemRoot\syswow64\ -Recurse -ErrorAction SilentlyContinue | Where-Object
{($_.Extension -like “.exe”)} -ErrorAction SilentlyContinue | Select Name;$SysBinLobj
= $SysBinList.Name | select -Unique | Select-Object @{Name=’Name’;
Expression={$_}};$SysBinLobj | export-csv sysbins.csv -NoTypeInformation
Frequenzanalyse des gesamten Pfads der System32-Binärdateien

Abbildung 2: Frequenzanalyse des vollständigen Pfads der System32-Binärdateien

Es ist wichtig zu beachten, dass Bedrohungsakteure die Erkennung durch Dateinamenabgleich umgehen können, indem sie die ausführbare Binärdatei umbenennen, da die Side-Loading-Technik unabhängig vom Namen der ausführbaren Datei weiterhin funktionsfähig bleibt.

Side-Load-Side-Loading mspaint.exe (umbenannt in notmspaint.exe) mit msftedit.dll

Abbildung 3: Side-LoadSide-Loading mspaint.exe (umbenannt in notmspaint.exe) mit msftedit.dll

Eine Möglichkeit, umbenannte ausführbare Dateien zu erkennen, besteht darin, die Hash-Werte der ausführbaren Dateien in den Verzeichnissen „System32“ und „SysWow64“ auf Windows-Rechnern genauer zu analysieren oder die internen Namen der ausführbaren Dateien von den Zielsystemen zu erfassen. Einige Lösungen zur Überwachung der Prozessausführung, wie beispielsweise Sysmon, erfassen den internen Namen einer ausführbaren Datei bei ihrer Ausführung. Darüber hinaus bietet PowerShell die Möglichkeit, den ursprünglichen Dateinamen einer ausführbaren Datei nach ihrer Umbenennung aufzulisten.

Auflistung des ursprünglichen Dateinamenattributs in PowerShell

Abbildung 4: Auflistung des ursprünglichen Dateinamenattributs in PowerShell

Das folgende Skript listet eine Reihe von ausführbaren Hash-Werten in den Verzeichnissen „System32“ und „SysWow64“ auf, die auch als Kontrolldatensatz verwendet werden können, um standardmäßige Windows-Ausführungsdateien an nicht standardmäßigen Speicherorten zu identifizieren.

$binarray=@()$SysBinList = Get-ChildItem $env:SystemRoot\system32\,$env:SystemRoot
\syswow64\ -Recurse -ErrorAction SilentlyContinue
| Where-Object {($_.Extension -like “.exe”)} -ErrorAction SilentlyContinue | Select FullName,Name

foreach($bin in $SysBinList)

{

$binhash = Get-FileHash $bin.FullName -Algorithm SHA1

$binobject = New-Object psobject

$binobject | Add-Member -MemberType NoteProperty -Name “Name” -Value $bin.Name

$binobject | Add-Member -MemberType NoteProperty -Name “Hash” -Value $binhash.Hash

$binarray += $binobject

}

$binarray | export-csv sysbinhash.csv -NoTypeInformation

Abbildung 5: PowerShell-Skript zum Sammeln von Datei-Hashes

Die oben genannten Erkennungen sind jedoch effektiver, wenn zentralisierte Prozessausführungsdaten vorliegen und die Möglichkeit besteht, innerhalb einer Umgebung Basiswerte für Aktivitäten im Zeitverlauf festzulegen. Das ist bei einer Untersuchung jedoch sehr selten der Fall.

Um diese Herausforderung zu bewältigen, stellt X-Force Datenerfassungsprogramme bereit, um Metadaten von Endpunkten in großem Umfang zu sammeln. Eines dieser Dienstprogramme ist SideLoadHunter, das den Endpunkt auf DLLs und ausführbare Dateien in Benutzerprofilen, System32 und SysWow64 überprüft. Sobald die ausführbaren Dateien und DLLs profiliert wurden, führt X-Force eine vergleichende Analyse durch, um mögliche Hinweise auf DLL-Side-Loading anhand von Dateinamen, Hash-Werten und internen Namen zu identifizieren. Zusätzlich werden Programm-Ausführungsartefakte auf Hinweise auf Side-Loading-ausführbare Dateien analysiert, die nicht mehr auf der Festplatte vorhanden sind. Dieses Tool wurde auf PowerShell portiert und kann hier heruntergeladen werden.

SideLoadHunter

Die Hauptfunktionen von SideLoadHunter sind:

  • Get-SideLoadDetect: Vergleichende Analysefunktion, die entwickelt wurde, um Situationen zu identifizieren, in denen sich eine ausführbare Datei von System32/SysWow64 in einem Benutzerverzeichnis befindet, zusammen mit einer DLL, die mit einem DLL-Namen von System32/SysWow64 übereinstimmt, jedoch nicht von Microsoft signiert ist.
  • Get-SusShimcache: Um einige Erkennungen für seitlich geladene ausführbare Dateien bereitzustellen, die sich nicht mehr auf der Festplatte befinden, analysiert SusShimcache ShimCache-Einträge für System32- und SysWow64-ausführbare Dateien, die von einem nicht standardmäßigen Speicherort aus ausgeführt wurden.
  • Get-SusExecs & Get-SusDLLs: Erstellt ein Profil eines Systems, um ausführbare Dateien und DLL-Dateien für System32 und SysWow64 zu finden, die sich nicht an ihrem Standardspeicherort befinden.
Ausführung von Side-Loadhunter.ps1

Abbildung 6: Ausführung von Side-Loadhunter.ps1

SideLoadDetect

Durch kontinuierliche Forschung zu ausführbaren Dateien, die für Side-Loading auf Windows-Systemen anfällig sind, hat X-Force eine Liste mit Namen von ausführbaren Dateien und den zugehörigen DLLs erstellt, die für Side-Loading geeignet sind.

Eine vollständige Liste der Seitenlastziele finden Sie hier.

Um die Echtzeiterkennung dieser Side-Load-Ziele zu unterstützen, hat X-Force die Liste bekannter Side-Load-Angriffe in eine Sysmon-Konfiguration migriert, die darauf abzielt, das Laden von Modulen für die zugehörigen ausführbaren Dateien und DLLs zu protokollieren.

Die Sysmon-Konfiguration ist hier zu finden.

Sysmon-Ereignis aus Side-Loadhunter.xml

Abbildung 7: Sysmon-Ereignis aus Side-Loadhunter.xml

Mehr als System32 und SysWow64

Während Malware und Angreifer in der Regel auf ausführbare Dateien in den Verzeichnissen „System32“ und „SysWow64“ abzielen, um diese seitlich zu laden, ist die Möglichkeit, eine DLL seitlich in eine ausführbare Datei zu laden, nicht auf diese Verzeichnisse beschränkt. Beispielsweise kann durch die Zusammenarbeit zwischen X-Force Incident Response und X-Force Red die ausführbare Datei „OneDriveStandaloneUpdater.exe“, die standardmäßig auf Windows 10-Systemen unter „%userprofile%\appdata\local\Microsoft\OneDrive“ zu finden ist, über „WofUtil.dll“ seitlich geladen werden. die sich standardmäßig im Verzeichnis „%windir%\system32\" befindet.

Side-Loading von OneDriveStandaloneUpdater.exe mit WofUtil.dll

Abbildung 8: Side-Loading von OneDriveStandaloneUpdater.exe mit WofUtil.dll

X-Force führt derzeit weitere Untersuchungen durch, um eine umfassendere Liste der ausführbaren Dateien und DLL-Dateien zu erstellen, die Ziele für Side-Loading sind. Bitte beachten Sie, dass weitere Informationen folgen werden.