I’ve had the opportunity to run some testing against Endpoint Detection and Response (EDR) solutions using various attacker techniques, and one of my favorite techniques at the moment is process injection on Windows. Process injection is the action of injecting arbitrary code (which is typically malicious code) into some already running process so that the running process runs the arbitrary code. From an attacker perspective, performing process injection comes with a number of benefits:
You don’t have to directly execute your malicious code, which will most likely get picked up by a number of different security solutions on Windows
You can obfuscate your malicious code so that it doesn’t look malicious before injecting it
Assuming there are no advanced security solutions on the Windows host, you can inject the code into “normal” programs (like notepad.exe) without risk of detection
More advanced security solutions (like EDR) tend to pick up the Windows API calls used by typical process injection (like CreateRemoteThread or VirtualAlloc), but it’s still cool to understand how it can be performed. I used the UrbanBishop program from the SharpSuite set of tools (https://github.com/FuzzySecurity/Sharp-Suite/tree/master/UrbanBishop) in order to do it. From a high level view, what it does is creates a local read/write section of memory in the UrbanBishop program, maps that read/write section into some remote process of your choosing (so it’s shared between the two processes), puts your code in this section, and then executes the code in the context of that remote process. Keep in mind that your code has to be position independent, meaning that it needs to execute at any memory address without having to modify the code itself.
I used Cobalt Strike to create the position independent code which spawns a beacon (modified to use direct syscalls instead of the default Windows API calls it uses per https://www.youtube.com/watch?v=mZyMs2PP38w), converted the code into shellcode using a slightly modified bin2sc.py (https://gist.github.com/superkojiman/11164279), and put the shellcode directly into the UrbanBishop source code before compiling it. “Normal” UrbanBishop operation requires that the shellcode is separate from the UrbanBishop source code, but it can be modified so that it holds the shellcode itself. After doing this, I compiled UrbanBishop using Visual Studio and executed it, which resulted in a nice Cobalt Strike beacon to play with.
Including the shellcode (scString) into the UrbanBishop source code
Activation of UrbanBishop with embedded shellcode
All this being performed, some security solutions will detect UrbanBishop injecting to a remote process, so I further modified UrbanBishop to inject the code into itself as opposed to a remote process:
Changing the code to inject into itself on line 260 of the code
It’s fun to be able to modify existing malware from time to time.