Thread Stack Spoofing / Call Stack Spoofing PoC
A PoC implementation for an advanced in-memory evasion technique that spoofs Thread Call Stack. This technique allows to bypass thread-based memory examination rules and better hide shellcodes while in-process memory.
This is an example implementation for the Thread Stack Spoofing technique aiming to evade Malware Analysts, AVs, and EDRs looking for references to shellcode’s frames in an examined thread’s call stack. The idea is to walk back the thread’s call stack and overwrite return addresses in subsequent function frames thus masquerading allocations containing malware’s code.
An implementation may differ, however, the idea is roughly similar to what MDSec’s Nighthawk C2 offers for its agents. Especially demonstrated in this video:
A note on wording – some may argue that the technique presented in this implementation is not strictly Thread Stack Spoofing but rather Call Stack Spoofing to some extent. I myself believe, that whatever wording is used here, the outcome remains similar to what was presented in an originally named technique – thus the borrowed name for this code. Since we’re clobbering some pointers on the thread’s stack, wouldn’t we call it spoofing the stack anyway and ultimately still resort to – Thread Stack Spoofing? The answer is left to the reader.
How does it work?
This program performs self-injection shellcode (roughly via classic
CreateThread). Then when shellcode runs (this implementation specifically targets Cobalt Strike Beacon implants) a Windows function will be hooked intercepting the moment when Beacon falls asleep
kernel32!Sleep. Whenever hooked
MySleep function gets invoked, it will spoof its own call stack leading to this
MySleep function and begin sleeping. Having awaited for expected amount of time, the Thread’s call stack will get restored assuring stable return and shellcode’s execution resumption.
The rough algorithm is following:
- Read shellcode’s contents from file.
- Acquire all the necessary function pointers from
kernel32!Sleeppointing back to our callback.
- Inject and launch shellcode via
CreateThread. A slight twist here is that our thread starts from a legitimate
ntdll!RltUserThreadStart+0x21address to mimic other threads
- As soon as Beacon attempts to sleep, our
MySleepcallback gets invoked.
- Stack Spoofing begins.
- Firstly we walk call stack of our current thread, utilising
- We save all of the stack frames that match our
seems-to-be-beacon-framecriterias (such as return address points back to a memory being
Type = 0, or memory’s protection flags are not
- We terate over collected frames (gathered function frame pointers
frame.frameAddr) and overwrite on-stack return addresses with a fake
- Finally a call to
::SleepExis made to let the Beacon’s sleep while waiting for further communication.
- After Sleep is finished, we restore previously saved original function return addresses and execution is resumed.
Function return addresses are scattered all around the thread’s stack memory area, pointed to by
RBP/EBP register. In order to find them on the stack, we need to firstly collect frame pointers, then dereference them for overwriting:
How do I use it?
Look at the code and its implementation, understand the concept and re-implement the concept within your own Shellcode Loaders that you utilise to deliver your Red Team engagements. This is an yet another technique for advanced in-memory evasion that increases your Teams’ chances for not getting caught by Anti-Viruses, EDRs and Malware Analysts taking look at your implants.
While developing your advanced shellcode loader, you might also want to implement:
- Process Heap Encryption – take an inspiration from this blog post: Hook Heaps and Live Free – which can let you evade Beacon configuration extractors like
- Change your Beacon’s memory pages protection to
RX/RWX) and encrypt their contents before sleeping (that could evade scanners such as
- Clear out any leftovers from Reflective Loader to avoid in-memory signatured detections
- Unhook everything you might have hooked (such as AMSI, ETW, WLDP) before sleeping and then re-hook afterward.
Author: Mariusz Banach / mgeeky, <mb [at] binary-offensive.com>, ’21
Source: Penetration Testing