Posted in Blog, THP3

THP Ch 7 Review

Disclaimer: Educational purposes, personal reference, don’t do illegal hacking, IANAL, etc.

Note: THP3 is my primary source for this. I’m putting my thoughts and notes to help me remember the info while avoiding putting too much info from the book here. If you are considering buying the book, I highly recommend it. 

THP3 07 – The Quarterback Sneak – Evading AV and Network Detection

I’m expecting this chapter to be one that I go through now and come back to in the future. The content is fantastic, but not where I need to be spending a great deal of time with everything else I have going on. My goal is to go through, understand the concepts, and come back to it when I need it.

Writing Code for Red Team Campaigns

The offensive side needs to constantly adapt and understand different protections. Of course, the defensive side also needs to constantly adapt and understand different attacks. So basically, every one needs to bring their “A” game. Kim notes coding isn’t a requirement to pentesting, but it’s definitely a good thing to have. From my perspective, this is absolutely true. There is a lot you can do with all of the tools available. You may not ever have the need to write code as a pentester. But knowing some, especially scripting languages, and being able to understand what code is doing is really helpful. I don’t think everyone on a pentest team needs to be an expert coder, but having one would be helpful. I know that doing the coding work I have helps me understand what’s going on with tools and understand vulnerabilities.

The Basics Building a Keylogger

Keyloggers are a key tool, so why not learn how to write one? There are lots of reasons to deploy one. An earlier THP had one in Python, THP3 will be in C. I know C isn’t a lot of people’s favorite, but I like it. You will have to set up an environment to write C. Getting C setup can be a little finicky Kim talks about getting Win10 in a VM, installing Visual Studio, and using Vim for code editing. I’ll probably stick with what I already have set up for C. Kim also notes MSDN is a great resource. C does need compiling, so you have to set that up. Visual Studio has a compiler built in, but you need to have the Universal Windows Platform development and Desktop Development with C++ installed. Then open up the developer command prompt go to the folder and run “cl sourcefile.c io.c” to create the executable. The default is 32-bit, so you may need to switch it to 64. There is a script to do this in the Visual Studio folder – just have to locate it and run vcvarsall.bat x86_amd64. The keylogger Kim wrote uses SetWindowsHookEx and LowLevelKeyboardProc functions. Kim has info about the keylogger posted on Github, and I think the best way to learn this is pull up the code, open the book to this section, and work through the code line by line until you understand what’s going on. Kim also gives examples of how to obfuscate the program to avoid AV detection as well as how to test whether you have evaded AV. Kim specifically cautions against using VirusTotal in a real engagement to avoid samples being sent to vendors, but does recommend it for testing and learning.

Lots of good info in this section, but if you aren’t familiar with coding or C, it’s probably something to come back to when you can devote some time to it. My plan is to come back to this specific portion once I finish up a C programming series I’m working through.

THP Custom Droppers

Droppers are important to let you run implants without having them on the victim machine. Unfortunately droppers are single use items, but you can develop a standard server. Kim also reminds you to sanitize your strings. The researcher in me scoffs a bit at this, but the idea of pentesting or red teaming isn’t to make it easier to reverse engineer things.

The dropper can be a DLL or shellcode. The DLL option will save some API calls and be stealthier. Headers being modified may break some implants. There is a lot of shellcode available online, so it can be helpful to do some digging and see if you find anything that will be useful.

Running the server looks straightforward…just a matter of walking through the steps. Same for building the client and the configuration of both.

Kim also gives some recommendations for adding new handlers and further exercises.

Recompiling Metasploit/Meterpreter to Bypass AV and Network Detection

An upfront warning from Kim that this is more advanced and you’ll likely run into issues. This is something I’ve read a bit about, while recognizing I’m not at the point where I want to get into it yet. This post from Black Hills has good info about modifying the Metasploit x64 template to evade AV. There is a lab for this section – I’m saving that for later. Kim goes into quite a bit of detail, so between what’s available online and the steps in the book, I think getting it done won’t be too bad. I just recognize that I’m not where I want to be to do the lab and really understand what’s going on. It can be really hard to look at something and decide you need to build a better foundation before tackling it, and I’m generally a fan of jumping in and figuring it out, but limited time and priorities…

SharpShooter

Creating payloads to avoid AV is time consuming. Sounds about right. SharpShooter is a tool to specifically help with this. Interesting tool plus a walkthrough of basic usage. More tools to work with later on an as-needed basis. The project is on Github with fairly solid documentation.

Application Whitelisting Bypass

The idea here is sticking payloads into default Windows binaries. Sneaky and effective. MSBuild.exe is a popular choice because it’s a default app in the .NET Framework. You can use GreatSCT to put a malicious XML project file in and get a Meterpreter session.

Code Caves

Kim talks about finding the public shares and file being shared and executed and notes that using executable binaries as vessels for custom malware works well. Backdoor Factory isn’t maintained or supported anymore, but Kim notes it’s a solid tool. Kim also notes resources from hiderm (which was down when I tried to check it out) and abatchy (also couldn’t access) to help with backdoors. Hopefully they’ll both be available later. If you haven’t checked it out previously, abatchy’s blog is a really good resource. I’ve found a lot of what’s posted beneficial.

PowerShell Obfuscation

Depending on who you listen to, either everyone is moving to using PowerShell for exploits or everyone is moving away from it. I’m leaning a bit toward the second since I’m hearing more and more about PS scripts getting detected. Kim pointed out some ways to obfuscate things…by basically not typing the full command all the way out.

Some examples…

 -ExecutionPolicy Bypass
 -EP Bypass
 -Exec Bypass
 -Execution Bypass
 -ExecutionPol Bypass
 -Executio Bypass
 -Exec Bypass

I really do appreciate how several of those are basically, “ugh, I’m tired of typing, PowerShell, read my mind.” This will also work for WIndowStyle or EncodedCommand, and possibly others if you dig around. But more obfuscation would be needed, so Kim demos how this can be done using Invoke-Obfuscation. The same person (Daniel Bohannon) also developed a remote download cradle tool, Invoke-CradleCrafter.

PowerShell Without PowerShell

Basically, this section is what do you do when you have RCE, but PS isn’t a viable option. Kim recommends NoPowerShell and SharpPick (which is part of PowerPick) as good options.

HideMyPS

HideMyPS is a tool Kim wrote that obfuscates all the strings in a PS script. He notes it’s not production and was a POC tool, but still a cool idea. And if it works, it works. He does note that this will change all the function names in the PS script, so you have to see what you’ll need to use instead.

Wrap Up

I really enjoyed this chapter even though it was a lot of stuff that is more advanced than I’m ready to do. I love seeing all the cool things that are available. It gives me ideas for future projects and things to study to do my job better. I understand the basic concepts and goals, so that’s good enough for me right now.

Next Steps

Basically file all of this stuff so I can come back to it when needed. And work on what can be done to detect this kind of stuff. Nothing specific, just keep learning and working.

Author:

Lifelong paradox - cyber sec enthusiast - loves to learn

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.