Zehn Verfahren zur Prozessinjektion: Ein technischer Überblick über gängige und zukunftsweisende Verfahren

Prozessinjektion ist eine weit verbreitete Verteidigungsumgehungstechnik, die häufig in Malware- und dateilosen Gegner-Tradecrafts eingesetzt wird und das Ausführen von benutzerdefiniertem Code innerhalb des Adressraums eines anderen Prozesses beinhaltet. Prozessinjektion verbessert die Tarnung, und einige Techniken erreichen auch Persistenz. Obwohl es zahlreiche Techniken zur Prozessinjektion gibt, stelle ich in diesem Blog zehn Techniken vor, die im Alltag vorkommen und Malware-Code im Namen eines anderen Prozesses ausführen. Außerdem stelle ich Screenshots von vielen dieser Techniken bereit, um das Reverse Engineering und die Malware-Analyse zu erleichtern und so die Erkennung und Verteidigung gegen diese gängigen Techniken zu unterstützen.

1. KLASSISCHE DLL-INJEKTION ÜBER CREATEREMOTETHREAD UND LOADLIBRARY

Diese Technik ist eine der gebräuchlichsten Methoden, um Malware in einen anderen Prozess einzuschleusen. Die Schadsoftware schreibt den Pfad zu ihrer bösartigen Dynamic-Link-Bibliothek (DLL) im virtuellen Adressraum eines anderen Prozesses und sorgt dafür, dass der entfernte Prozess ihn lädt, indem sie einen entfernten Thread im Zielprozess erstellt.

Die Malware muss zunächst einen Prozess zur Injektion angreifen (z. B. svchost.exe). Dies geschieht üblicherweise durch das Durchsuchen von Prozessen und dem Aufruf eines Trios von Application Program Interfaces (APIs): CreateToolhelp32Snapshot, Process32First und Process32Next. CreateToolhelp32Snapshot ist eine API, die zur Aufzählung von Heap- oder Modulzuständen eines bestimmten Prozesses oder aller Prozesse verwendet wird und einen Snapshot zurückgibt. Process32First ruft Informationen über den ersten Prozess im Snapshot ab, und dann wird Process32Next in einer Schleife verwendet, um diese zu durchlaufen. Nachdem der Zielprozess gefunden wurde, erhält die Schadsoftware den Handle des Zielprozesses, indem sie OpenProcess aufruft.

Wie in Abbildung 1 gezeigt, ruft die Malware VirtualAllocEx auf, um einen Speicherplatz zu haben, um den Pfad zu ihrer DLL zu schreiben. Die Schadsoftware ruft dann WriteProcessMemory auf, um den Pfad im zugewiesenen Speicher zu schreiben. Schließlich ruft die Malware APIs wie CreateRemoteThread, NtCreateThreadEx oder RtlCreateUserThread auf, um den Code in einem anderen Prozess ausführen zu können. Die beiden letztgenannten sind undokumentiert. Die Grundidee ist jedoch, die Adresse von LoadLibrary an eine dieser APIs weiterzugeben, sodass ein entfernter Prozess die DLL im Namen der Malware ausführen muss.

CreateRemoteThread wird von vielen Sicherheitsprodukten verfolgt und markiert. Außerdem benötigt sie eine bösartige DLL auf der Festplatte, die erkannt werden könnte. Da Angreifer am häufigsten Code einschleusen, der Verteidigungen umgehen soll, werden ausgeklügelte Angreifer diesen Ansatz wahrscheinlich nicht verwenden. Der untenstehende Screenshot zeigt eine Malware namens Rebhip, die diese Technik anwendet.

2. PORTABLE AUSFÜHRBARE INJEKTION (PE-INJEKTION)

Anstatt die Adresse der LoadLibrary weiterzugeben, kann Malware ihren bösartigen Code in einen bestehenden offenen Prozess kopieren und ihn dort ausführen lassen (entweder über einen kleinen Shellcode oder durch Aufruf von CreateRemoteThread). Ein Vorteil der PE-Injektion gegenüber der LoadLibrary-Technik ist, dass die Malware keine bösartige DLL auf der Festplatte ablegen muss. Ähnlich wie bei der ersten Technik weist die Malware Speicher in einem Hostprozess (z. B. VirtualAllocEx) zu, und anstatt einen „DLL-Pfad“ zu schreiben, schreibt sie ihren schädlichen Code durch Aufruf von WriteProcessMemory. Das Hindernis bei diesem Ansatz ist jedoch die Änderung der Basisadresse des kopierten Bildes. Wenn eine Malware ihr PE in einen anderen Prozess injiziert, erhält sie eine neue, unvorhersehbare Basisadresse, die die festen Adressen ihres PEs dynamisch neu berechnet. Um dies zu umgehen, muss die Malware ihre Adresse der Relocation-Tabelle im Hostprozess finden und die absoluten Adressen des kopierten Bildes durch ihre Relocation-Deskriptoren lösen.

Diese Technik ähnelt anderen Techniken, wie der reflektierenden DLL-Injektion und dem Speichermodul, da keine Dateien auf die Festplatte gelangen. Speichermodul- und reflektierende DLL-Injektionsansätze sind jedoch noch unauffälliger. Sie verlassen sich nicht auf zusätzliche Windows-APIs (z. B. CreateRemoteThread oder LoadLibrary), da sie sich selbst im Speicher laden und ausführen. Die reflektierende DLL-Injektion funktioniert, indem eine DLL erstellt wird, die sich beim Ausführen selbst in den Speicher kopiert, anstatt sich auf den Windows-Loader zu verlassen. Das Speichermodul ähnelt der reflektierenden DLL-Injektion, außer dass der Injektor oder Loader dafür verantwortlich ist, die Ziel-DLL in den Speicher abzubilden, anstatt die DLL-Abbildung selbst. In einem früheren Blogbeitrag wurden diese beiden In-Memory-Ansätze ausführlich diskutiert.

Bei der Analyse von PE-Injektion ist es sehr üblich, Schleifen zu sehen (meist zwei „for“-Schleifen, die ineineinander liegen), bevor CreateRemoteThread aufgerufen wird. Diese Technik ist bei Verschlüsselern (Software, die Malware verschlüsselt und verschleiert) recht beliebt. In Abbildung 2 nutzt der Sample-Unit-Test diese Technik. Der Code hat zwei verschachtelte Schleifen, um seine Relokationstabelle anzupassen, die vor den Aufrufen zu WriteProcessMemory und CreateRemoteThread sichtbar sind. Die „and 0x0fff“-Instruktion ist ebenfalls ein guter Indikator, da sie zeigt, dass die ersten 12 Bits verwendet werden, um den Offset in die virtuelle Adresse des enthaltenden Relokationsblocks zu bringen. Jetzt, da die Malware alle notwendigen Adressen neu berechnet hat, muss sie nur noch ihre Startadresse an CreateRemoteThread weitergeben und sie ausführen.

3. PROZESSHOLUNG (AUCH PROZESSERSATZ UND RUNPE GENANNT)

Anstatt Code in ein Host-Programm einzuschleusen (z. B. DLL-Injektion), kann Malware eine als „Process Hollowing“ bezeichnete Technik anwenden. Process Hollowing tritt auf, wenn eine Malware den legitimen Code aus dem Speicher des Zielprozesses entmappt (aushöhlt) und den Speicherbereich des Zielprozesses (z. B. svchost.exe) mit einer schädlichen ausführbaren Datei überschreibt.

Die Malware erstellt zunächst einen neuen Prozess, um den bösartigen Code im Ruhemodus zu hosten. Wie in Abbildung 3 gezeigt, geschieht dies, indem CreateProcess aufgerufen und das Process Creation Flag auf CREATE_SUSPENDED (0x00000004) gesetzt wird. Der primäre Thread des neuen Prozesses wird angehalten und erst dann ausgeführt, wenn die Funktion ResumeThread aufgerufen wird. Als Nächstes muss die Malware den Inhalt der legitimen Datei durch ihre bösartige Nutzlast ersetzen. Dies geschieht, indem der Speicher des Zielprozesses entmappt wird, indem entweder ZwUnmapViewViewOfSection oder NtUnmapViewViewOfSection aufgerufen wird. Diese beiden APIs geben im Grunde den gesamten Speicher frei, auf den ein Abschnitt hinweist. Da der Speicher nun nicht zugeordnet ist, führt der Loader VirtualAllocEx durch, um neuen Speicher für die Malware zuzuweisen, und verwendet WriteProcessMemory, um jeden Abschnitt der Malware in den Zielprozessraum zu schreiben. Die Malware ruft SetThreadContext auf, um den Eintrittspunkt auf einen neuen Codeabschnitt zu verweisen, den sie geschrieben hat. Am Ende nimmt die Malware den angehaltenen Thread wieder auf, indem sie ResumeThread aufruft, um den Prozess aus dem suspendierten Zustand zu nehmen.

4. THREAD-AUSFÜHRUNGS-HIJACKING (AUCH SUSPEND, INJECT UND RESUME (SIR))

Diese Technik weist einige Ähnlichkeiten mit der zuvor besprochenen Verfahrensholung auf. Beim Hijacking der Thread-Ausführung zielt Malware auf einen bestehenden Thread eines Prozesses ab und vermeidet verrauschte Prozess- oder Thread-Erstellungsoperationen. Daher werden Sie bei der Analyse wahrscheinlich Aufrufe zu CreateToolhelp32Snapshot und Thread32First erscheinen und danach dann „OpenThread“.

Nachdem der Thread den Zielthread erkannt hat, versetzt die Schadsoftware den Thread in den Aussetzungsmodus, indem sie SuspendThread aufruft, um die Injektion durchzuführen. Die Malware ruft VirtualAllocEx und WriteProcessMemory auf, um Speicher zuzuweisen und die Code-Injektion durchzuführen. Der Code kann Shellcode, den Pfad zur bösartigen DLL und die Adresse von LoadLibrary enthalten.

Abbildung 4 zeigt einen generischen Trojaner, der diese Technik verwendet. Um die Ausführung des Threads zu kapern, ändert die Malware das EIP-Register (ein Register, das die Adresse der nächsten Instruktion enthält) des Zielthreads, indem sie SetThreadContext aufruft. Anschließend setzt Malware den Thread wieder auf, um den Shellcode auszuführen, den sie für den Host-Prozess geschrieben hat. Aus Sicht des Angreifers kann der SIR-Ansatz problematisch sein, da das Aussetzen und Wiederaufnehmen eines Threads mitten in einem Systemaufruf dazu führen kann, dass das System abstürzt. Um dies zu vermeiden, würde eine ausgefeiltere Malware wieder aufgenommen und später erneut versuchen, wenn das EIP-Register im Bereich von NTDLL.dll liegt.

5. HOOK-INJEKTION ÜBER SETWINDOWSHOOKEX

Hooking ist eine Technik, die verwendet wird, um Funktionsaufrufe abzufangen. Malware kann die Hooking-Funktionalität nutzen, um ihre bösartige DLL dann zu laden, wenn ein Ereignis in einem bestimmten Thread ausgelöst wird. Dies geschieht üblicherweise durch den Aufruf von SetWindowsHookEx, um eine Hook-Routine in die Hook-Kette zu installieren. Die SetWindowsHookEx-Funktion benötigt vier Argumente. Das erste Argument ist die Art des Ereignisses. Die Ereignisse spiegeln die Bandbreite der Hook-Typen wider und reichen vom Tastendrücken auf der Tastatur (WH_KEYBOARD) bis hin zu Eingaben für die Maus (WH_MOUSE), CBT usw. Das zweite Argument zeigt auf die Funktion, die die Malware bei der Ereignisausführung aufrufen möchte. Das dritte Argument ist ein Modul, das die Funktion enthält. Daher ist es sehr üblich, Aufrufe zu LoadLibrary und GetProcAddress zu sehen, bevor SetWindowsHookEx aufgerufen wird. Das letzte Argument dieser Funktion ist der Faden, mit dem das Hook-Verfahren assoziiert werden soll. Wenn dieser Wert auf null gesetzt ist, führen alle Threads die Aktion aus, wenn das Ereignis ausgelöst wird. Allerdings zielt Malware in der Regel auf einen Thread ab, um weniger Rauschen zu erzielen, sodass es auch möglich ist, CreateToolhelp32Snapshot und Thread32Next vor SetWindowsHookEx aufzurufen, um einen einzelnen Thread zu finden und anzuvisieren. Sobald die DLL injiziert wurde, führt die Schadsoftware ihren bösartigen Code im Namen des Prozesses aus, bei dem ihre ThreadId an die SetWindowsHookEx-Funktion weitergegeben wurde. In Abbildung 5 implementiert Locky Ransomware diese Technik.

6. INJEKTION UND PERSISTENZ DURCH REGISTERMODIFIKATION (Z. B. APPINIT_DLLS, APPCERTDLLS, IFEO)

Appinit_DLL, AppCertDlls und IFEO (Image File Execution Options) sind alles Registrierungsschlüssel, die von Malware sowohl für Injektion als auch für Persistenz verwendet werden. Die Einträge befinden sich an folgenden Orten:

HKLM\Software\Microsoft\Windows NT\CurrentVersion\Windows\Appinit_Dlls HKLM\Software\Wow6432Node\Microsoft\Windows NT\CurrentVersion\Windows\Appinit_Dlls HKLM\System\CurrentControlSet\Control\Session Manager\AppCertDlls HKLM\Software\Microsoft\Windows NT\currentversion\image file execution options

AppInit_DLLs

Malware kann den Standort ihrer bösartigen Bibliothek unter den Appinit_Dlls Registrierungsschlüssel einfügen, damit ein anderer Prozess ihre Bibliothek lädt. Jede Bibliothek unter diesem Registrierungsschlüssel wird in jeden Prozess geladen, der User32.dll lädt. User32.dll ist eine sehr verbreitete Bibliothek, die zum Speichern grafischer Elemente wie Dialogfelder verwendet wird. Wenn eine Malware diesen Unterschlüssel ändert, laden die meisten Prozesse die bösartige Bibliothek. Abbildung 6 zeigt den Trojaner Ginwui, der auf diesen Ansatz für Injektion und Persistenz setzt. Er öffnet einfach den Appinit_Dlls Registrierungsschlüssel, indem er RegCreateKeyEx aufruft, und ändert dessen Werte durch Aufruf von RegSetValueEx.

AppCertDlls

Dieser Ansatz ähnelt sehr dem AppInit_DLLs-Ansatz, außer dass DLLs unter diesem Registrierungsschlüssel in jeden Prozess geladen werden, der die Win32-API-Funktionen CreateProcess, CreateProcessAsUser, CreateProcessWithLogonW, CreateProcessWithTokenW und WinExec aufruft.

Ausführungsoptionen für Bilddateien (IFEO)

IFEO wird typischerweise für Debugging-Zwecke verwendet. Entwickler können unter diesem Registrierungsschlüssel den "Debugger Value" festlegen, um ein Programm an eine andere ausführbare Datei zum Debugging anzuhängen. Daher wird jedes Mal, wenn die ausführbare Datei gestartet wird, das daran angeschlossene Programm gestartet wird. Um diese Funktion zu nutzen, können Sie einfach den Pfad zum Debugger geben und ihn an die ausführbare Datei anhängen, die Sie analysieren möchten. Malware kann diesen Registrierungsschlüssel so verändern, dass er sich selbst in die Ziel-ausführbare Datei einfügt. In Abbildung 7 implementiert der Diztakun-Trojaner diese Technik, indem er den Debugger-Wert des Task-Managers ändert.

7. APC-INJEKTION UND ATOMBOMBENANGRIFF

Malware kann Asynchronous Procedure Calls (APC) nutzen, um einen anderen Thread dazu zu zwingen, seinen eigenen Code auszuführen, indem er ihn an die APC-Warteschlange des Zielthreads anhängt. Jeder Thread verfügt über eine Warteschlange von APCs, die auf die Ausführung warten, sobald der Zielthread in einen veränderbaren Zustand eintritt. Ein Thread tritt in einen alarmierbaren Zustand, wenn er die Funktionen SleepEx, SignalObjectAndWait, MsgWaitForMultipleObjectsEx, WaitForMultipleObjectsEx oder WaitForSingleObjectEx aufruft. Die Malware sucht in der Regel nach jedem Thread, der sich in einem veränderbaren Zustand befindet, und ruft dann OpenThread und QueueUserAPC auf, um einen APC an einen Thread zu verteilen. QueueUserAPC nimmt drei Argumente: 1) einen Handle für den Zielthread; 2) einen Zeiger auf die Funktion, die die Schadsoftware ausführen möchte; 3) und den Parameter, der an den Funktionszeiger übergeben wird. In Abbildung 8 ruft Amanahe-Malware zunächst OpenThread auf, um einen Handle eines anderen Threads zu erhalten, und ruft dann QueueUserAPC mit LoadLibraryA als Funktionszeiger auf, um seine bösartige DLL in einen anderen Thread einzuschleusen.

Atombombing ist eine Technik, die erstmals von enSilo-Forschung eingeführt und dann in Dridex V4 verwendet wurde. Wie wir in einem früheren Beitrag ausführlich besprochen haben, basiert die Technik auch auf der APC-Injektion. Allerdings verwendet es Atomtabellen, um in den Speicher eines anderen Prozesses zu schreiben.

8. ZUSÄTZLICHE FENSTERSPEICHER-INJEKTION (EWMI) ÜBER SETWINDOWLONG

EWMI basiert darauf, in den zusätzlichen Fensterspeicher des Explorer-Tray-Fensters einzuschicken und wurde bereits einige Male bei Malware-Familien wie Gapz und PowerLoader verwendet. Beim Registrieren einer Fensterklasse kann eine Anwendung eine Anzahl zusätzlicher Speicherbytes angeben, die als Extra Window Memory (EWM) bezeichnet werden. Allerdings gibt es in EWM nicht viel Platz. Um diese Einschränkung zu umgehen, schreibt die Malware Code in einen gemeinsamen Bereich von explorer.exe und verwendet SetWindowLong und SendNotifyMessage, um einen Funktionszeiger zu haben, der auf den Shellcode zeigt, und führt ihn dann aus.

Die Schadsoftware hat zwei Möglichkeiten, wenn es darum geht, in einen gemeinsamen Abschnitt zu schreiben. Es kann entweder einen geteilten Abschnitt erstellen und ihn sowohl auf sich selbst als auch auf einen anderen Prozess (z. B. explorer.exe) abbilden lassen, oder er kann einfach einen bereits bestehenden gemeinsamen Abschnitt öffnen. Ersteres hat zusätzlich zu einigen anderen API-Aufrufen den Overhead der Zuweisung von Heap-Speicher und das Aufrufen von NTMapViewOfSection, sodass letzterer Ansatz häufiger verwendet wird. Nachdem die Malware ihren Shellcode in einem gemeinsamen Abschnitt geschrieben hat, verwendet sie GetWindowLong und SetWindowLong, um auf den zusätzlichen Fensterspeicher von "Shell_TrayWnd" zuzugreifen und ihn zu verändern. GetWindowLong ist eine API, die verwendet wird, um den 32-Bit-Wert am angegebenen Offset in den zusätzlichen Fensterspeicher eines Fensterklassenobjekts abzurufen, und SetWindowLong wird verwendet, um Werte am angegebenen Offset zu ändern. Dadurch kann die Malware einfach den Offset eines Funktionszeiger in der Fensterklasse ändern und ihn auf den Shellcode verweisen, der im geteilten Abschnitt geschrieben ist.

Wie bei den meisten anderen oben genannten Techniken muss die Malware den von ihr geschriebenen Code auslösen. In zuvor besprochenen Techniken erreichte Malware dies, indem sie APIs wie CreateRemoteThread, QueueUserAPC oder SetThreadContext aufgerufen hat. Bei diesem Ansatz löst die Malware stattdessen den eingeschleusten Code aus, indem sie SendNotifyMessage aufruft. Nach Ausführung von SendNotifyMessage empfängt Shell_TrayWnd die Kontrolle auf die Adresse, auf die zuvor von SetWindowLong gesetzter Wert zeigt. In Abbildung 9 verwendet eine Malware namens PowerLoader diese Technik.

9. INJEKTION MIT SHIMS

Microsoft stellt Entwicklern hauptsächlich Shims zur Verfügung, um Abwärtskompatibilität zu gewährleisten. Shims ermöglichen es Entwicklern, Korrekturen auf ihre Programme anzuwenden, ohne Code neu schreiben zu müssen. Durch die Nutzung von Shims können Entwickler dem Betriebssystem vorschreiben, wie es mit seiner Anwendung umgehen soll. Shims sind im Grunde eine Möglichkeit, sich mit APIs zu verbinden und spezifische ausführbare Dateien anzuvisieren. Malware kann Shims nutzen, um eine ausführbare Datei sowohl für Persistenz als auch für die Injektion anzugreifen. Windows führt die Shim Engine aus, wenn sie eine Binärdatei lädt, um nach shimmenden Datenbanken zu suchen und die entsprechenden Korrekturen anzuwenden.

Es gibt viele Fehlerbehebungen, die angewendet werden können, aber die Favoriten von Malware sind diejenigen, die teilweise sicherheitsbezogen sind (z. B. DisableNX, DisableSEH, InjectDLL usw.). Um eine Shimling-Datenbank zu installieren, kann Malware verschiedene Ansätze einsetzen. Ein gängiger Ansatz ist zum Beispiel, sdbinst.exe einfach auszuführen und auf die bösartige SDB-Datei zu verweisen. In Abbildung 10 verwendet eine Adware, "Search Protect by Conduit", einen Shim zur Persistenz und Injektion. Es führt einen "InjectDLL"-Shim in Google Chrome durch, um vc32loader.dll zu laden. Es gibt einige wenige Tools zur Analyse von SDB-Dateien, aber für die Analyse des unten aufgeführten SDB habe ich Python-SDB verwendet.

10. IAT HOOKING UND INLINE HOOKING (AUCH USERLAND ROOTKITS GENANNT)

IAT-Hooking und Inline-Hooking werden allgemein als Userland-Rootkits bezeichnet. IAT-Hooking ist eine Technik, die von Malware verwendet wird, um die Importadresstabelle zu ändern. Wenn eine legitime Anwendung eine API aufruft, die sich in einer DLL befindet, wird die ersetzte Funktion anstelle der ursprünglichen ausgeführt. Im Gegensatz dazu verändert Malware beim Inline-Hooking die API-Funktion selbst. In Abbildung 11 führt die Malware FinFisher IAT-Hooking durch, indem sie den Standort des CreateWindowEx-Codes ändert.

SCHLUSSFOLGERUNG

In diesem Beitrag habe ich zehn verschiedene Techniken behandelt, die Malware nutzt, um ihre Aktivitäten in einem anderen Prozess zu verbergen. Im Allgemeinen injiziert Malware entweder ihren Shellcode direkt in einen anderen Prozess oder zwingt einen anderen Prozess, seine bösartige Bibliothek zu laden. In Tabelle 1 habe ich die verschiedenen Techniken klassifiziert und Proben bereitgestellt, die als Referenz zur Beobachtung jeder in diesem Beitrag behandelten Injektionstechnik dienen. Die im Artikel enthaltenen Zahlen helfen dem Forscher, die verschiedenen Techniken zur Umkehrung von Malware zu erkennen.

Angreifer und Forscher entdecken regelmäßig neue Techniken, um Injektionen zu erreichen und Tarnung zu gewährleisten. Dieser Beitrag hat zehn gängige und aufkommende Techniken vorgestellt, aber es gibt auch weitere, wie zum Beispiel COM-Entführungen. Verteidiger werden nie "fertig" sein mit ihrer Mission, tarnante Prozessinjektionen zu erkennen und zu verhindern, denn Gegner werden nie aufhören zu innovieren.

Bei Endgame erforschen wir ständig fortschrittliche Tarntechniken und integrieren Schutzmaßnahmen in unser Produkt. Wir schichten Fähigkeiten, die bösartige DLLs erkennen, die auf einer bestimmten Persistenz geladen werden (wie AppInit-DLLs, COM-Hijacks und mehr), viele Formen der Code-Injection in Echtzeit über unseren patentierten Shellcode-Injektionsschutz verhindern und bösartige injizierte Payloads im Speicher erkennen, die mit einer der oben genannten Techniken über unsere patentangemeldeten Dateilosen Angriffserkennungstechniken laufen. Dieser Ansatz ermöglicht es unserer Plattform, effektiver als jedes andere Produkt auf dem Markt gegen Code-Einschleusung zu schützen und gleichzeitig die Widerstandsfähigkeit gegen Bypass durch neue Code-Injektionstechniken zu maximieren.