theflink/hunt-sleeping-beaconsCallstack-Scanner, der IOCs von entpackten oder injizierten C2-Agenten identifiziert, indem er Thread-Leerlaufverhalten, nicht hinterlegten Speicher, Modul-Stomping, APCs, Timer und Return-Address-Spoofing analysiert.
Dieses Projekt ist (größtenteils) ein Callstack-Scanner, der versucht, IOCs zu identifizieren, die auf einen entpackten oder injizierten C2-Agenten hinweisen.
Alle Prüfungen basieren auf der Beobachtung, dass C2-Agenten zwischen ihren Callbacks warten, was den Beacon-Thread in den Leerlauf versetzt, und dieses Tool soll analysieren, was möglicherweise den Leerlauf des Threads verursacht hat.
Dies umfasst traditionelle IOCs wie ungebackenen Speicher oder gestampfte Module, versucht aber auch, mehrere Implementierungen von Sleepmasks zu erkennen, die APCs oder Timer verwenden. Letzteres erfolgt sowohl durch Analyse des Callstacks als auch durch Aufzählen von Timern und ihren genauen Callbacks aus dem Userland.
(Fast) keiner dieser IOCs kann als 100% True Positive betrachtet werden, die Erkennung von Modul-Stomping z.B. ist sehr anfällig für False Positives. Dennoch könnten die Ergebnisse den Verdacht auf das Verhalten eines Prozesses lenken.
DotNet- und 32-Bit-Binaries werden ignoriert.
Eine private r(w)x-Seite im Callstack könnte auf einen Beacon hinweisen, der zur Laufzeit entpackt oder injiziert wurde.
Mehrere Sleepmasks ändern die Seitenberechtigungen der Beacon-Seite auf nicht ausführbar. Dies führt zu einer verdächtigen nicht ausführbaren Seite im Callstack.
Beacons vermeiden oft private Speicherseiten, indem sie ein legitimes Modul von der Festplatte laden und überschreiben. Dank des Copy-on-Write-Mechanismus können manipulierte Images identifiziert werden, indem das Feld VirtualAttributes.SharedOriginal von MEMORY_WORKING_SET_EX_INFORMATION überprüft wird. Wenn eine Seite im Callstack nicht privat ist und SharedOriginal == 0 ist, wird sie als IOC betrachtet.
Dies ist wahrscheinlich die Erkennung, die am anfälligsten für False Positives ist. :'(
Mehrere Implementierungen von Sleepmasks reihen eine Serie von APCs zu Ntdll!NtContinue ein, von denen eine die Ausführung von Ntdll!WaitForSingleObject auslöst. Wenn also Ntdll!KiUserApcDispatcher im Callstack zu einer blockierenden Funktion gefunden wird, betrachtet dieses Tool es als IOC.
Ähnlich wie bei der verdächtigen Verwendung von APCs prüft dieses Tool auch auf ntdll!RtlpTpTimerCallback im Callstack zu einer blockierenden Funktion, um timerbasierte Sleepmasks zu erkennen.
Meinem Verständnis nach werden Timer auf Basis von ThreadPools implementiert. Wie Alon Leviev gezeigt hat können diese mit NtQueryInformationWorkerFactory und WorkerFactoryBasicInformation aufgezählt werden.
Die WORKER_FACTORY_BASIC_INFORMATION-Struktur enthält einen FULL_TP_POOL, der wiederum mit einer doppelt verlinkten Liste TimerQueue verknüpft ist. Das Durchlaufen dieser Liste von PFULL_TP_TIMER ermöglicht den Zugriff auf jeden registrierten Callback. Wenn ein Callback auf eine Reihe verdächtiger API-Aufrufe wie ntdll!ntcontinue verweist, kann dies als starkes IOC betrachtet werden.
Ursprünglich wurde Module Proxying als Methode eingeführt, um verdächtige Callstacks zu umgehen. Während der Bypass funktioniert, führt er einen weiteren starken IOC ein, da die NTAPI verwendet wird, um die WINAPI aufzurufen. Dies ist ungewöhnlich, da WINAPI eine Abstraktion für NTAPI ist. Wenn also ein Callstack beobachtet wird, in dem eine Sequenz von ntdll.dll->kernel32.dll->ntdll.dll gefunden wird, die mit dem Aufruf einer blockierenden Funktion endet, kann dies als IOC betrachtet werden.
Die meisten Return-Address-Spoofing-Implementierungen, die mir bekannt sind, verwenden eine Technik, bei der die aufgerufene Funktion zu einem jmp [Nonvolatile-Register]-Gadget zurückkehrt. Dieses Projekt iteriert einfach jede Rückkehradresse in Callstacks und sucht nach Mustern, die auf die Rückkehr zu einem jmp-Gadget hinweisen.
_ _ _____ ______
| | | | / ___| | ___ \
| |_| | \ `--. | |_/ /
| _ | `--. \ | ___ \
| | | | /\__/ / | |_/ /
\_| |_/ \____/ \____/
Hunt-Sleeping-Beacons | @thefLinkk
-p / --pid {PID}
--dotnet | Set to also include dotnet processes. ( Prone to false positivies )
--commandline | Enables output of cmdline for suspicious processes
-h / --help | Prints this message?