Maintaining Access

Maintaining Access Part 2: A Deeper Look at C2

Welcome back my fellow hackers! In the last lesson on maintaining access we discussed the bare bones concepts of what it means to maintain access and why it is important. Then we went on to install a backdoor in a Windows 7 Pro VM. This time we won’t be installing any backdoors (although I did figure out the privilege issue we had last time), but we’ll be taking a deeper look at C2. First we’ll define what C2 is, then we’ll go into detail on what makes a good C2 infrastructure.

Defining C2

C2 (otherwise written as C&C) is shorthand for Command and Control. C2 is the infrastructure that allows us persistent access to our targets. There are a number of qualities that a good C2 infrastructure should have, and we will also be defining and reviewing those within this lesson.

For those of you who are in penetration testing or looking to get into it, I should inform you that C2 is not always required. In fact, in some instances, C2 is out-of-scope. This means that the customer that hired you to perform the penetration test does not want you leaving backdoors and C2 infrastructure all over the place. Not only could this cause problems between you and the customer, it could end up in problems between you and the law (and trust me, it’s much better to stay on thisside of a cell). So, make sure you ask your customer or a representative of your customer about the scope of your penetration test. Now that we’ve got that out of the way, let’s talk about what qualities make up a C2 infrastructure.

Basic C2 Infrastructure Qualities

There are quite a few qualities that make up a proper C2 infrastructure. As we review these qualities, I’ll describe them in better detail and review why they are important to our overall C2 effectiveness.

1. Remote file system access – Our C2 infrastructure should allow us access to the file systems of all the victims that are under our influence. This includes the ability to download/upload files, move files, manage permissions, and all the other file system operations that we need to make our access persistent.
2. Remote command execution – Our infrastructure should allow us to execute commands on any given victim. This is a very basic requirement for C2 and does not require a deep explanation.
3. Stealth – When it comes to stealth, our infrastructure should be able to slip past any IDS/IPS or firewall that the traffic must flow through. This can be accomplished by disguising our data to look legitimate, such as a covert DNS channel. There are a number of protocols that we can use to hide data, and we’ll get to them in due time.
4. Fault tolerance – Our C2 client or agent (the software deployed on the victim) should be able to re-connect to our infrastructure automatically in the event of a network outage or other disruption.
5. Persistence – This one is pretty obvious, our C2 agent needs to be able to survive reboots and be persistent on the victim machine.
6. Secure communications – The data flowing back and forth between our victims and our infrastructure should not only be disguised, but encrypted. This means that we should encrypt the data before packing it into the disguising packet. This way even if packets from our C2 infrastructure are captured, the data packed within cannot be read without first finding or cracking the encryption key.

That does it for this article, next time we’ll be taking a more advanced look at C2 infrastructure and what technologies we can incorporate into it to make it more suitable. By the end of this series I’d like to be able to script our own C2 infrastructure and agent using Python. This infrastructure will include all the qualities we reviewed here (and hopefully more). See you then!

Filed Under: Malware, Network Penetration Testing, Penetration Testing, Recommended

Maintaining Access Part 1: Introduction and Metasploit Example

Welcome back my fellow hackers! Today we’re going to be starting the topic of maintaining access. First, we’ll discuss the concept of maintaining access and why it’s important. Then we’ll move on to our lab where we’ll compromise a PC and set up a backdoor so we can come back to it.

The Concept of Maintaining Access

When a system is compromised, the attacker is given temporary access to it (not including compromised management services such as SSH, telnet, etc.). If the system were to power cycle or the gained access be interrupted by some means, access would be lost. But, if quick action is taken by the attacker upon initial compromise, access can be maintained or persistent.

This persistent access often takes the form of a backdoor, which starts along with the system to give the attacker access without need for further exploitation. Launching a high number of exploits in an attempt to gain access to the same system is likely to alert an admin (a good one at least), and might lock you out for good. So, persistent access is definitely the way to go.

Maintaining Access with Metasploit

Now that we’ve discussed what exactly is means to obtain persistent access, we can go ahead and try it for ourselves. Thankfully, Metasploit comes equipped to get the job done. First we’ll gain access to the victim PC, then we’ll establish our persistent access. Once that’s all done, we’ll restart the victim PC and reconnect to the backdoor!

Step 1: Initial Compromise

Since this isn’t an exploitation lesson we’re not going to get too fancy here. We’ll be using Metasploit’s web delivery module to download and execute our payload from the victim PC. First we’ll go ahead and set up the web delivery module:

Once its loaded the module, we’ll use the show options command to see what options we need to set in order to run this module:

Looking at the options here, it seems we need to set a URIPATH, a new payload, the payloads LHOST, and the exploit target ID. I’ll be setting the URIPATH to “/pwn” because its randomized otherwise. The LHOST should be the local IP address of the attacking machine, the payload should be the Windows reverse TCP meterpreter, and the target ID should be 2 for windows powershell:

Note: while it is not shown in the screenshot, you must change the payload to windows/meterpreter/reverse_tcp or any other Windows compatible payload.

Now that we’ve got our options set, we should be able to use the exploit command to get everything rolling. Once it starts, it will generate a command that we need to run on the target machine. Since our payload server is listening on port 8080, our regular HTTP port 80 is still available. So I’ll be copying our command from Metasploit into a file in /var/www/html/ (the root directory for the apache2 web service). Once we’ve got the command copied to a text file, we can start the apache2 service:

With that squared away, we can move over to our victim PC and point the browser at our attackers local IP address. In the URL, specify the file you wrote the command to, in my case its command:

Now all we have to do is open up CMD on the victim station and paste our command (if you’re in the wild a rubber ducky might be useful):

Now that we’ve run our command, the CMD should close. Going back to our attacker machine, we can see that we now have a meterpreter session running on the victim PC:

Step 2: Privilege Escalation

So we’ve got access. But we don’t have enough access. Right now we’re running with the same privileges as the user. If we want persistent access, we very well might need more rights. To gain these privileges, we’ll use Metasploit’s local exploit suggester:

Setting our session number to one, we should be able to gather information on how we can further exploit this system:

After some time waiting (and bit more time sifting through results) we can conclude that this system is vulnerable to Schlamperei (CVE-2013-1300) allowing us to gain SYSTEM privileges. Let’s go ahead and load up the Metasploit module:

This is a pretty simple module, so we’ll set our session number to one and fire away:

Now that we’ve got a second meterpreter session, let’s take a look at our privileges:

There we have it! We now have SYSTEM privileges and can move on to setting up our persistent access. Note: you may want to act fast, in my experience the schlamperei module yields SYSTEM privileges, but can be downgraded back to user privileges over time.

Step 3: Establishing Persistent Access

So, we’ve got our SYSTEM access and we’re ready to go. Now we’ll be using our NT AUTHORITY level meterpreter session to establish a persistent backdoor to this victim. From within the meterpreter, we can use the run command along with the persistence script to view the help page:

Ideally, I would’ve liked to have used the -S option for a deeper foothold, but was given some access errors. I’ll be finding a way around this (probably manually installing the backdoor) but for now we’ll be using the -U flag, which will start the backdoor when the user logs in. We’ll also be using -i to specify the interval between connection attempts, the -p flag to specify the port number to connect back on, and the -r flag to specify the remote host (attacker machine or C&C server) to connect back to:

Let’s break down what the persistence script is doing right now. First is build a resource file to cleanup the backdoor. A resource file is a file used by metasploit to perform a series of commands (sort of like a macro). Once the resource file is built, it creates the payload. In this case our payload is a reverse TCP meterpreter. After the payload is generated and written as a persistent script to a randomly chosen temporary directory, an entry is made into the registry. This entry will start the script that was written when the user logs in. To view this registry key, open regedit on the Windows machine and navigate to the path shown in your output.

Step 4: Returning to the Victim Machine

Now that we have our backdoor installed and ready to go, we’ll close metasploit and re-open it, as well as power off the victim PC. Once metasploit opens back up we need to set up our handler to catch the connection from the backdoor. For this we’ll use the multi/handler module configured with the options we set when we ran the persistence script:

The handler is now listening on port 31337 for the reverse connection. Let’s go ahead and power up our victim PC:

Once the victim PC is powered up, we should log the victim user in and keep an eye on our Metasploit console to see the handler catch the reverse connection from the backdoor:

There we go! Our handler caught the reverse connection and now we have another meterpreter session after the victim PC was reset. Just to prove that our access truly is persistent, let’s kill the new session and get a new one:

As you can see in the above screenshots, the session we received from the victim did not have SYSTEM privileges, but regular user privileges. This is due to using the -U flag instead of the -S flag in the persistence module and is something I intend to resolve in the next article, where we’ll be attempting to build our own backdoor instead of letting Metasploit do all the work for us!

Filed Under: Featured, Hack Tools, Malware, Penetration Testing Tools, Recommended, System Hacking, Windows Hacking

Evading Anti-virus Part 2: Obfuscating Payloads with Msfvenom

Welcome back hackers. In the last edition of our journey into evading anti-virus, we used Shellter to infect EXEs with a payload. Today we’re going to be taking it down a notch and talking about obfuscating payloads with msfvenom.

Obfuscation is the concept that we can take our payload and change its signature. If we can change its signature, it can help us to get past anti-virus. Obfuscation in and of itself is usually not enough to fool today’s anti-virus, but it may be effective against out-of-date or some lesser anti-virus software. That being said, its still important that we review and understand obfuscation so we can implement it along with other techniques.

Since obfuscation alone will likely fail, I’ll be using VirusTotal. So, let’s get started!

Step 1: Generate Un-encoded Payload

We’ll be generating two payloads, one encoded and one unencoded. But, before we do either, we should take a look at the msfvenom help page, which we can see by using the –help flag at the command line:

The only flags we need are -p, -f, -a, –platform, and -o. This will allow us to generate an EXE of the unencoded shellcode. We’ll also need to set the LHOST and LPORT variables when we create our payload. LHOST should be the machine the payload will connect back to, and LPORT should be the port to connect on. Now that we know everything we need, let’s put it together and generate our unencoded payload:

Alright, we have our first, unencoded payload. Now we can make our encoded payload, after that we’ll be able to see the difference.

Step 2: Generate Encoded Payload

Now we’re getting into the point of this article. Msfvenom comes with many encoders, which are all options for different ways to encode our payload. To view the encoders that we can use, we need to give the –list encoders flag when we call msfvenom:

There are way too many encoders to fit into a single screenshot, but you get the gist, there’s a lot of encoders. The one’s we’re going to be using today are shikata_ga_nai and countdown. Shikata ga nai is a polymorphic encoder, which means that it will change the signature of the file every time we use it. I’m using countdown in conjunction with shikata ga nai just to show an example of using multiple encoders for a single payload (feel free to use whatever encoders you want).

In order to generate our encoded payload, we need the -e and -i flags. These flags will allow us to specify an encoder, and the amount of times to iterate the encoder over the shellcode. In order to use multiple encoders, we need to use msfvenom and output our encoded payload in the raw format, which we then pipe into another msfvenom command. After all encoding is complete, the final msfvenom command will format it into an EXE. Let’s see it:

Once this process gets going we’re going to see a lot of output. Now that we have our payloads, we can move on to running them against VirusTotal.

Step 3: Check our Payloads against VirusTotal

We’ll start with our unencoded payload. We just need to use the File option on the VirusTotal site:

Alright, so most anti-virus software detected our payload. Now that we have that baseline, let’s try the obfuscated payload and see if our results are any better:

So we have our results, but I hate fractions, so I took the liberty of converting our fractions here to percentages with Python:

As we can see, our obfuscation didn’t do much (as expected). But, if we were to combine this obfuscation with other anti-virus evasion techniques we might stand a better chance. Next time we’ll either be using a program called Veil for other obfuscation techniques, or a tool called AVET (Anti-Virus Evasion Tool) to use some entirely different techniques (I haven’t decided which yet). I’ll see you then!

Filed Under: Ethical Hacking, Featured, Hack Tools, Malware, RecommendedTagged With: evasion

Evading Anti-virus Part 1: Infecting EXEs with Shellter

Welcome back my fellow hackers! Today we’re going to be entering some new territory. When we’re attempting to compromise a system, we need to be stealthy. A part of this stealthiness is learning to evade antivirus software. To start us on this journey, we’re going to be talking about a tool called Shellter.

Shellter is a tool that allows us to inject payloads into a legitimate Windows executable (EXE) file. This injection allows us to disguise a payload as a real executable, which can drastically increase our chances of getting past antivirus. In order to demonstrate this technique, we’re going to be injecting a reverse TCP meterpreter payload into an EXE.

Note: Shellter is built for Windows, but is capable of running via wine in Linux. I’ll be using an ESXi lab to create a 32-bit Windows 7 VM to run Shellter in.

Step 1: Download Shellter and Legitimate EXE

For our demonstration today, we’re going to be attempting to evade the built-in Windows 7 Windows Defender. To do this, we’ll be using Shellter to infect the installer for mIRC, an IRC client built for Windows. Shellter can be downloaded here, and the mIRC installer can be downloaded here.

Shellter does not require an installer to be run, so all we need to do is extract the Shellter ZIP file. We also need to move the mIRC installer to the directory where the Shellter EXE is. Once this is complete, we can begin our injection!

Step 2: Inject Payload into EXE

Now that we have everything ready, we can inject a payload into the mIRC installer. Shellter comes with a list of payloads that we can use, and we can also generate our own payloads. For this lesson however, we will be using the payloads provided by Shellter.

Note: Remember to run Shellter as an administrator, so it has the permissions it needs.

Once we start Shellter, we have a choice between automatic and manual mode. Automatic mode works well, but for our demonstration we’ll be using manual mode. This gives us more control over things like where the payload is injected, obfuscation, and applying polymorphic code.

Once we select manual mode, we opt to skip the online version check, then we give Shellter the name of the EXE we want to inject our payload into. Once we’ve specified the EXE, we have a couple other prompts we need to get through:

Please note that the reasoning behind setting the number of instructions for Shellter to trace to two-hundred is simply because the mIRC installer is a small and simple EXE. Now that we’ve given Shellter the info it needs, it will begin tracing the mIRC executable. While this is happening, let’s move over to the Kali VM we’ll be using for this lesson. We need to know its IP address on the LAN in order to tell our payload who to connect back to:

Now that we know our local IP address, let’s go back to our Windows VM and see the next prompts Shellter has for us:

The stealth mode option will maintain the original functionality of the EXE, in this case it is not needed as we are simply using this EXE to gain access. If we were, for example, performing a man in the middle attack, we could redirect the user to download a version of the EXE they’re after that’s been infected by us. This would allow us to slip the payload into the EXE without alerting the user.

As for the payload, we’re just going to stick with the usual reverse TCP meterpreter (we’ll use a custom payload next time). Once we’ve given Shellter the information regarding our payload, we’ll be given another set of prompts:

Polymorphic code is an important concept to understand in evading antivirus. Polymorphic code uses an engine to change the way to code works, while keeping the original functionality of it. Shellter gives us the option to prepend polymorphic code to our EXE, changing the way it looks to the antivirus. We’ll append about one-thousand bytes of polymorphic code to our EXE, which should be enough.

After a bit of waiting, we should see Shellter tell us that everything is good to go:

Now that our EXE is infected, we can move on to the next step.

Step 3: Run Defender Scan and Set up Handler

To test our EXE’s stealthiness, we’re going to run a quick scan in Windows Defender:

While Defender is scanning, let’s move over to our Kali machine and get our handler ready:

This handler will catch the connection that the payload will make back to us. Once we’ve got the handler set up, let’s go back to our Windows VM and see how the scan went:

There is it, we successfully evaded Windows Defender. Now that we know Windows Defender doesn’t see our infected EXE as malware, let’s execute it and see if our payload works:

There we have it, our payload works and made it past the antivirus.

This article is the start of a series I’m going to be continuing here on HackingLoops. There are many other tactics and techniques for evading antivirus software, and we’ll get to them in due time. Next time we’ll be tackling obfuscation.