Hacking Articles Tips Tricks Videos Tutorials

SQL Injection JR. Pentester -TryHackMe

Hi, amazing hackers in this story you are gonna how to what is SQL injections and how to find them in different types.Continue reading on Medium »
Read more...

8 views20:19

ThreadStackSpoofer - PoC For An Advanced In-Memory Evasion Technique Allowing To Better Hide Injected Shellcode'S Memory Allocation From Scanners And Analysts
http://www.kitploit.com/2021/10/threadstackspoofer-poc-for-advanced-in.html

___________________________
@hacking_Attack
@Hacking_Video

Kitploit

Kitploit – Maintenance in Progress

Kitploit is temporarily under maintenance. We’ll be back shortly with improvements.

7 viewsedited 21:10

Hacking Articles Tips Tricks Videos Tutorials

6 views21:10

Hacking Articles Tips Tricks Videos Tutorials

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 (https://www.kitploit.com/search/label/Shellcodes) while in-process memory.
Intro
This is an example implementation for 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 hide references to the shellcode on thread's call stack thus masquerading allocations containing malware's code.Implementation along with my ShellcodeFluctuation (https://github.com/mgeeky/ShellcodeFluctuation) brings Offensive Security community sample implementations to catch up on the offering made by commercial C2 products, so that we can do no worse in our Red Team toolings.
Implementation has changed
Current implementation differs heavily to what was originally published. This is because I realised there is a way simpler approach to terminate thread's call stack processal and hide shellcode's related frames by simply writing 0 to the return address of the first frame we control:
void WINAPI MySleep(DWORD _dwMilliseconds)
{
[...]
auto overwrite = (PULONG_PTR)_AddressOfReturnAddress();
const auto origReturnAddress = *overwrite;
*overwrite = 0;

[...]
*overwrite = origReturnAddress;
}
The previous implementation, utilising StackWalk64 can be accessed in this commit c250724 (https://github.com/mgeeky/ThreadStackSpoofer/tree/c2507248723d167fb2feddf50d35435a17fd61a2).This implementation is much more stable and works nicely on both Debug and Release under two architectures - x64 and x86.
Demo
This is how a call stack may look like when it is NOT spoofed:

___________________________
@hacking_Attack
@Hacking_Video

KitPloit - PenTest & Hacking Tools

Leading source of security tools, hacking tools, cybersecurity and network security. Learn about new tools and updates in one place.

6 viewsedited 21:10

Hacking Articles Tips Tricks Videos Tutorials

6 views21:10

Hacking Articles Tips Tricks Videos Tutorials

This in turn, when thread stack spoofing is enabled:

___________________________
@hacking_Attack
@Hacking_Video

6 viewsedited 21:10

Hacking Articles Tips Tricks Videos Tutorials

Above we can see that the last frame on our call stack is our MySleep callback. One can wonder does it immediately brings opportunities new IOCs? Hunting rules can look for threads having call stacks not unwinding into following expected thread entry points located within system libraries:kernel32!BaseThreadInitThunk+0x14
ntdll!RtlUserThreadStart+0x21
However the call stack of the spoofed thread may look rather odd at first, a brief examination of my system shown, that there are other threads not unwinding to the above entry points as well:

___________________________
@hacking_Attack
@Hacking_Video

7 viewsedited 21:10

Hacking Articles Tips Tricks Videos Tutorials

7 views21:10

Hacking Articles Tips Tricks Videos Tutorials

7 views21:10

Hacking Articles Tips Tricks Videos Tutorials

The above screenshot (https://www.kitploit.com/search/label/Screenshot) shows a thread of unmodified Total Commander x64. As we can see, its call stack pretty much resembles our own in terms of initial call stack frames.Why should we care about carefully faking our call stack when there are processes exhibiting traits that we can simply mimic?
How it works?
The rough algorithm is following:Read shellcode's contents from file.Acquire all the necessary function pointers from dbghelp.dll, call SymInitializeHook kernel32!Sleep pointing back to our callback.Inject and launch shellcode via VirtualAlloc + memcpy + CreateThread. The thread should start from our runShellcode function to avoid having Thread's StartAddress point into somewhere unexpected and anomalous (such as ntdll!RtlUserThreadStart+0x21)As soon as Beacon attempts to sleep, our MySleep callback gets invoked.We then overwrite last return address on the stack to 0 which effectively should finish the call stack.Finally a call to ::SleepEx is 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:

___________________________
@hacking_Attack
@Hacking_Video

KitPloit - PenTest & Hacking Tools

Leading source of security tools, hacking tools, cybersecurity and network security. Learn about new tools and updates in one place.

7 viewsedited 21:10

Hacking Articles Tips Tricks Videos Tutorials

7 views21:10

Hacking Articles Tips Tricks Videos Tutorials

Where: is a path to the shellcode file when 1 or true will enable thread stack spoofing and anything else disables it.Example run that spoofs beacon's thread call stack: .\x64\Release\ThreadStackSpoofer.exe .\tests\beacon64.bin 1 [.] Reading shellcode bytes... [.] Hooking kernel32!Sleep... [.] Injecting shellcode... [+] Shellcode is now running. [>] Original return address: 0x1926747bd51. Finishing call stack... ===> MySleep(5000) [<] Restoring original return address... [>] Original return address: 0x1926747bd51. Finishing call stack... ===> MySleep(5000) [<] Restoring original return address... [>] Original return address: 0x1926747bd51. Finishing call stack... ">PS D:\dev2\ThreadStackSpoofer> .\x64\Release\ThreadStackSpoofer.exe .\tests\beacon64.bin 1
[.] Reading shellcode bytes...
[.] Hooking kernel32!Sleep...
[.] Injecting shellcode...
[+] Shellcode is now running.
[>] Original return address: 0x1926747bd51. Finishing call stack...

===> MySleep(5000)

[<] Restoring original return address...
[>] Original return address: 0x1926747bd51. Finishing call stack...

===> MySleep(5000)

[<] Restoring original return address...
[>] Original return address: 0x1926747bd51. Finishing call stack...

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 (https://www.arashparsa.com/hook-heaps-and-live-free/) - which can let you evade Beacon configuration extractors like BeaconEyeChange your Beacon's memory pages protection (https://www.kitploit.com/search/label/Protection) to RW (from RX/RWX) and encrypt their contents - using Shellcode Fluctuation (https://github.com/mgeeky/ShellcodeFluctuation) technique - right before sleeping (that could evade scanners such as Moneta or pe-sieve)Clear out any leftovers from Reflective Loader to avoid in-memory signatured detectionsUnhook everything you might have hooked (such as AMSI, ETW, WLDP) before sleeping and then re-hook afterwards.
Actually this is not (yet) a true stack spoofing
As it's been pointed out to me, the technique here is not yet truly holding up to its name for being a stack spoofer. Since we're merely overwriting return addresses on the thread's stack, we're not spoofing the remaining areas of the stack itself. Moreover we're leaving our call stack unwindable meaking it look anomalous since the system will not be able to properly walk the entire call stack frames chain.However I'm aware of these shortcomings, at the moment I've left it as is since I cared mostly about evading automated scanners that could iterate over processes, enumerate their threads, walk those threads stacks and pick up on any return address pointing back to a non-image memory (such as SEC_PRIVATE - the one allocated dynamically by VirtuaAlloc and friends). A focused malware analyst would immediately spot the oddity and consider the thread rather unusual, hunting down our implant. More than sure about it. Yet, I don't believe that nowadays automated scanners such as AV/EDR have sorts of heuristics implemented that would actually walk each thread's stack to verify whether its un-windable ¯\_(ツ)_/¯ .Surely this project (and commercial implementation found in C2 frameworks) gives AV & EDR vendors arguments to consider implementing appropriate heuristics covering such a novel evasion technique.In order to improve this technique, one can aim for a true Thread Stack Spoofer by inserting carefully crafted fake stack frames established in an reverse-unwinding process. Read more on this idea below.

___________________________
@hacking_Attack
@Hacking_Video

Arash's Blog

Hook Heaps and Live Free

Table of Contents
1. Introduction
2. Hooking 1. IAT Hooking
2. Trampoline Hooking

3. Putting the EXE Together
4. Thread Targeted Heap Encryption: Considerations
5. Additional Observations During the Journey

UPDATE
Decided to add a small…

7 viewsedited 21:10

About

Blog

Apps

Platform