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

About

Blog

Apps

Platform