Maintaining Access Part 1: Introduction and Metasploit Example

 

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!

Introduction to Exploitation, Part 1: Introducing Concepts and Terminology

Welcome back my fellow hackers! Today we’re going to be starting a series that I’ve been meaning to start for some time now. We’re going to start discussing exploitation. As hackers, exploitation is a very large part of our job. Once we find the vulnerabilities, we need to exploit them. We’ve already covered some aspects of exploitation in the past, so if you’re not up to speed I suggest starting with those.

First we’ll talk about some terms that get thrown around a lot when talking about exploitation. I’m just going to make a list of the terms, followed by their definition. These terms are going to be used a lot later in this series, so you should really make sure you understand these terms. If you need help, leave a comment or e-mail me at thedefalt@protonmail.com. I’ll try my best to help you get a better grasp on these terms, as they are very important.

• Exploit: An exploit is simply a program/script designed to take advantage of a security flaw. There are many different kinds of exploits, but that is beyond the scope of this introduction. That being said, we’ll cover the more specific types of exploits later in this series.
• Local exploit: A local exploit is an exploit that only works when run locally on the target. These are often used to gain more privileges once initial access to the target system is gained. If the attacker is attempting to physically access the target system, these can be used to easily and quickly gain complete control over the system.
• Remote exploit: A remote exploit is an exploit that works when fired over a network. These are usually used to gain initial access to a system, while local exploits are normally used to gain privileges once basic access to the system of obtained.
• Privilege escalation exploit: This exploit type is just as it sounds. These exploits are specifically designed to exploit vulnerabilities that will yield a higher level of privileges to the attacker (Ex: system services, firmware flaws, poor system configuration). If these exploits are successful, the attacker can attain absolute control over the target system.
• Zero-day exploit: These are the trump cards of hacking. A zero day exploit is an exploit that has never been seen before. Naturally, since the vulnerability is unknown, the exploit is extremely difficult to detect and even harder to stop.
• Payload: Exploits aren’t magic. While they can open opportunities to execute code, there still needs to be code to execute. This is where payloads come in. A payload is simply the code that is executed upon exploitation. A good metaphor for this is a bomber plane. The pilot (attacker) uses the plane (exploit) to get in place in order to drop the bomb (payload). The plane simply puts the pilot in position so that the bomb can be dropped. The same concept applies to us hackers. The exploits simply put is in position to execute the payload. There are many different kinds of payloads, but we won’t get into that just yet.
• Stager: Stagers are important so read this part really carefully. In order for payloads to execute, they have to be stored in the memory of the system. When we exploit a program, we have a very limited amount of memory to store the payload in. Because of this, we often won’t have enough room in memory to store the entire payload. This is why we have stagers. Stagers are a sort of payload. A stager is a payload that will download and execute a larger payload. It’s a payload that downloads and executes another payload, simple enough, right? Since a stager’s only job is to fetch a larger payload, we can use them where we don’t have enough memory to work with. If the payload is too large to fit into the memory available to us, we can use a stager instead. This allows us to work around memory limitations to deliver our payload to the target.
• Post exploitation: After a vulnerability is found and exploited, we’ll have access to the target system. But now what? Well that’s where post exploitation comes into play. Post exploitation is all the stuff we do after we gain access. This includes everything from extracting sensitive information to installing a software key logger. Everything that is done after access (and higher privileges) are gained is considered post exploitation.
• FUD (Fully UnDetectable): This term is not exclusive to exploitation. It is also used a lot when discussing malware (viruses, worms, trojans, etc.). This term mainly applies to payloads, as the payload is the code that is actually executed as the result of an exploit. FUD simply means that the malicious code is fully undetectable by any anti-virus software that may be present on the target system. For example, if you know that your target is running up-to-date anti-virus, you might want to take a look into making your payload FUD. Truly FUD payloads are difficult to come by, but we can get pretty close. We’ll cover making payloads FUD(ish) later in this series.
• Encoders: Anti-virus developers aren’t stupid, they know what we hackers are up to. Every piece of software has a signature. Anti-virus can use these signatures to spot and remove known malware. Payloads also have a signature, seeing as they’re just small bits of malicious code. This means that anti-virus can detect and stop our payloads from running, and that can be a big problem! Encoders can take our payload and change the way it looks by encoding it. When we encode a payload, the signature changes, so by using encoders, we stand a better chance of sneaking past that pesky anti-virus!

Wow, that was a mouthful! That’s a lot of information to digest so I’m going to cut this off here. In the next article we’ll be introducing some common exploitation tools, such as Metasploit. But before we get there, you should really have a good grasp on everything we talked about here. Remember, if you need clarification on anything, leave a comment or e-mail me at thedefalt@protonmail.com and I’ll do my best to help you!

PwnLab CTF Walkthrough Part 1: Recon and Data Extraction

Welcome back everyone! This is the first in a new series we’re launching that will walk you through various capture the flag (CTF) challenges. In order to ease into this new series we’re going to take a minute now to detail what a CTF challenge is (for those of you that don’t already know). Then, we’ll get hacking at the PwnLab: init CTF challenge. So, let’s get started!

What is a CTF Challenge?

Simply put, a CTF challenge is a system that has been intentionally configured with vulnerable software for the sole purpose of hacking. When hacking a CTF the “player” (attacker) must find and exploit these vulnerabilities in order to gain access to a text file containing the flag. Once the flag has been read, the game is won!

You may be wondering how this helps us become better hackers. Well, my direct answer to that question is: practice makes perfect! If we really take the time to play these CTF challenges, we become exposed to a far wider range of attacks than we’d normally see. By seeing and using these attacks ourselves, we gain a better understanding of how they work, which in turn makes us better hackers. Now that we know what a CTF is and the perks gained from playing them, let’s get started at hacking our first CTF challenge!

Hacking the PwnLab: init CTF

The first CTF challenge we’ll be taking a crack at is PwnLab: init. This is meant to be a relatively easy CTF to complete, so it’s a perfect candidate to start us out! When we download PwnLab, it comes as a VM, so we can run it inside VirtualBox, which is what we’ll be doing here. This CTF can get a bit lengthy, so we’re going to split the pwnage up into two parts. This part will be reconnaissance and preparing the attack, and the next part will be exploitation and privilege escalation. Let’s get hacking!

Step 1: Finding the Target

If we’re going to hack PwnLab, we need to know it’s address! Since PwnLab is configured to automatically pull an IP address via DHCP, we need to have a scan running in order to see it’s address. So, we’ll start the scan, then we’ll start the PwnLab VM and we’ll have the address. We’ll be hacking PwnLab from BackTrack, so we’ll be using netdiscover. First we need to find the address range to use in netdiscover. We can use the ifconfig command for this:

We can see that our address is 10.130.10.18 with a subnet mask of 255.255.255.0. By representing this information is CIDR notation, we can deduce that we need to scan for the 10.130.10.0/24 range of IP addresses. The netdiscover tool has a lot of output, so I’ve typed the command out as well. Now that we have our scan ready, let’s execute it. We’ll need to give it a second to gather results, then we’ll start our VM. Once we do, we should see a new host appear in the scan results:

We can see at the end of our netdiscover output that we have the IP address of out target, 10.130.10.41. Now that we have this address, we can do some recon on the target.

Step 2: Performing a Port Scan with Nmap

In order to find potential vulnerabilities on our target, we need to know what ports are open, and what services are listening on those ports. To find this oh-so-valuable information, we’ll be performing a port scan using nmap. Let’s see the command and the output, then we’ll discuss what’s happening under the hood:

We can see that we’ve not only used nmap, but we’ve given a variety of flags and switches to customize our scan. We’ve disabled host checking (-Pn), enabled SYN scanning (-sS), and enabled service detection (-sV). We’ve also specified that we only want to scan ports 1 through 4000. Then, we pipe the output into a new text file named nmap.txt. This is so that we can look at the scan results again at any time without having to re-scan the target.

We can see by the result of our scan that PwnLab is hosting a MySQL database and some sort of website. The database may contain some sweet goodies, but I think we’ll take a look at this web server being hosted on port 80 first.

Step 3: Analyzing the Web App for Vulnerabilities

Since we know that there’s a web app being hosted on PwnLab, we’re going to see if we can find any vulnerabilities to exploit. We’re going to start by pointing our browser to PwnLab’s IP address. Once we do, we should be greeted with a home page like this:

Nothing particularly stands out on the home page, so let’s move to the login page and see if anything sticks out to us:

When we move to the login page, we can see the URI change as a new resource is selected. After some research I found that there’s a local file inclusion vulnerability in this sort of resource selection. Local file inclusion (LFI) can help us read files that we otherwise shouldn’t be able to read. In this case, we can use it to read the source code of the PHP scripts that run the web app. We’ll have to use a variant of LFI that uses built-in PHP converters to convert the source code to base64 so we can decode and read it.

Step 4: Retrieving and Reviewing the Login PHP Script Source Code

In order to exploit this LFI vulnerability, we simply need to modify the URI and point the base64 converter to the login.php resource. Once we do, we should see a result such as this:

There we go! We successfully exploited LFI. Now we need to retrieve this base64 string and decode it to get the login PHP script source code. We can download the base64 string by re-using the current URL and feeding it to the curl command, we’re also going to save the output to a file named tmp.txt. Let’s do that now:

Now, the curl command will also save the rest of the source code for the webpage, so we need to open a text editor and remove the HTML tags so we have nothing but the base64 string left; I’ll leave that to you. Now that we have our base64 string in a text file, we can decode it and delete our temp. file. Let’s decode the base64 now:

We’ve decoded the base64 and stored the output in a new text file. We then delete our temporary file as we no longer need it. Now that we have the login page source code, let’s take a look at it:

Step 5: Retrieving and Viewing the Config PHP Source Code

We can see here at the very beginning of the login PHP source code, it required code from another resource named config.php. Since the LFI worked for the login PHP script, it should work for the config PHP script as well. I’m not going to go through the whole process again, as it’s the exact same steps we took before. I will however post a screenshot with all the steps. Let’s download and decode the config.php source code:

Now that we have the config.php source, we can see what PwnLab is trying to hide from us:

Aha! We found a username and a password inside the config.php source code. I’m willing to bet that these are the credentials we need to log into the MySQL database we saw earlier!

Step 6: Log into and Explore the MySQL Database

Now that we have the creds to get into the MySQL database, we can log in and see what goodies they’re trying to keep from us. We can use the default MySQL client installed on BackTrack to log into and explore the MySQL database. Once we give all the info to our client, we should be prompted with a password, and once we enter the password, we should be given a MySQL prompt. Let’s log into the database now:

There we go! Our stolen credentials checked out and now we have access to the database. Now we can use the show and use commands in order to find and select a database, and show the tables inside that database. Let’s start by looking for databases with the show command:

When we execute our show command, we are returned with a single database under the name Users. This must be where they keep all the user passwords! Let’s utilize the use command in order to select this database, then we’ll use the select command to extract all the data from it:

Once we extracted all entries from the users table we were given a table of usernames and passwords. But, it seems that the passwords are encoded with base64. But, that’s not a problem for determined attackers like us!

Step 7: Retrieve and Decode the Credentials

I’ve made a new file named users.txt and have stored the usernames and passwords in it. We can now go through and use the echo command along with the base64 command in order to decode each of these passwords. We’ll start by decoding kent’s password:

Now we just have to repeat this process for the other two usernames and we end up with credentials that look like this:

Now that we have credentials, we may be able to cause more havoc in the web app we used earlier! But, we’ll save that for the next part, as we’ve done more than enough damage here.

Today we covered and demonstrated the concept of LFI and basic data extraction with native tools. In the next part, we’ll use these newly found credentials to gain access to the functionality of the web app, and thus the PwnLab server. We’ll then perform some privilege escalation and capture that flag!