Prepping for OSCP: Walkthrough for LazySysAdmin

Prepping for OSCP: Walkthrough for LazySysAdmin

With a request in for approval to start my OSCP training, I decided I should probably get started on some write-ups for the VulnHub VMs I've done. So without further ado, here is my guide for how I rooted LazySysAdmin:

Discovery

The first step to any engagement, is to know in which network you will be working.  To figure this out, I ran an ifconfig to see which IP address I pulled from DHCP:

Figure 1 IP Address of Attacking Machine

So it looks like I’ll be working in the 192.168.56.0/24 subnet.  With this information in hand, I could look for other hosts on this subnet using netdiscover:

Figure 2 Netdiscover Results with Hosts

As you can see in Figure 2, there are a couple of hosts on the network.  192.168.56.1 is the gateway, with 192.168.56.100 being the DHCP server and 192.168.56.101 being our target machine.

Enumeration

With the network mapped out, it was time to see what was open on our target.  I began with a basic nmap scan just to get a good idea of what was running on default/popular ports so I could start a more thorough scan later and just let it run:

Figure 3 nmap parameters

For those unfamiliar with nmap, let’s break down the command:

1. Nmap:  the application we are running.  This does the port scanning of the target IP
2. -sS: this indicates the type of scan we are wanting to run.  In this case, we are doing a Syn Stealth Scan
3. -Pn: this tells nmap to treat machines that don’t reply to ping (ICMP) requests as live targets.  This will certainly slow down a scan, but some machines are configured to not respond, so better safe than sorry!
4. -vv: this means we want to see EVERYTHING (verbose) in our output.  I like to see the progress of my scans as they are running.
5. 192.168.56.101: our target machine’s IP address (LazySysAdmin)

Figure 4 Nmap Output

Pretty verbose right?  The main things we are looking for are ports.  Now, in my scan, I did not specify I wanted to capture banners of each port (-sV), so I’m going to take the service listed as is (22 is actually SSH, 80 is actually an http server, etc.)

So straight out the gate, we have a couple of options.  Anytime I see a webserver running, I tend to gravitate towards that, so we’ll start there!

The Web Server (80/TCP)

Figure 5 The Static Webpage

I find this webpage to be interesting because normally, a website is interactive, but this one has static content (non-clickable buttons, dead links, etc.).  With no way to interact with the page, let’s kick off a nikto scan to see if there are any interesting tidbits of info we can gather:

Figure 6 Nikto host scan

Within a couple of seconds, we have information at our fingertips:

Figure 7 Nikto Scan Results

From here, we see that there are a couple of directories in the robots.txt file, a phpMyAdmin directory, an info.php page (which is great for gathering information about the server configuration), as well as a wordpress site.

Navigating to the info.php page, we see some information about the server:

Figure 8 info.php page

Further down the page, we can see apache version info, user/group (www-data), document roots (/var/www/html), etc.  I’ll leave you to look at all of this and identify what’s most important to you.

Wordpress sites always fascinate me in VMs because people come up with some great situations.  So we go to http://192.168.56.101/wordpress/ and find a pretty basic wordpress site:

Figure 9 Wordpress Page

So already, we see someone unhappy with the install process of WordPress, and they have also, perhaps unknowingly, given us information that could help us.  Their name is: togie.  I’ll keep this in the back of my memory while I kickoff a WordPress scan and check some of the other services:

Figure 10 WPScan Command

Again, we’ll break down this command for those who are unfamiliar with wpscan:

1. Wpscan: the name of the application we are running
2. --url http://192.168.56.101/wordpress/: the wordpress site to scan
3. --enumerate utp: this tells wpscan we care about users, plugins, and themes

NetBIOS and SAMBA (139/TCP, 445/TCP)

Normally, I ignore NetBIOS and SAMBA during VulnHub VMs, but there wasn’t too much that seemed interesting in the nmap scan, so I decided to give it a shot.  To enumerate NetBIOS names, I used nmblookup:

Figure 11 nmblookup command

The breakdown for this command is:

1. Nmblookup: the name of the application we are running
2. -A 192.168.56.101: does a node status on <name> as an IP address

Figure 12 nmblookup Results

Alright, we have some NetBIOS names of LAZYSYSADMIN and the default WORKGROUP.  With a non-default NetBIOS name of LAZYSYSADMIN, I’ll use that in my smbclient command:

Figure 13 smbclient command

The arguments are as follows:

1. Smbclient: the application to run
2. -I 192.168.56.101: the IP address to connect to
3. -L \\LAZYSYSADMIN: get the list of shares on \\LAZYSYSADMIN
4. -N: don’t use a password (anonymous connection since we don’t have a password yet ☹)

Figure 14 smbclient results

So it appears as though we have three shares available to us: print$, share$, and IPC$.  Going down the line, I was prompted with a connection failure on the print$ share:

Figure 15 Failed print$ access

However, when connecting to share$, we see that we are anonymously connected to LAZYSYSADMIN:

Figure 16 share$ anonymous access

At this point, we browse the share with an “ls” which displays the following output:

Figure 17 share$ files

I download the .txt files with a simple get request:

Figure 18 Downloading files deets.txt, robots.txt, and todolist.txt

Now in another terminal, I print those files to my console:

Figure 19 Contents of the 3 files we downloaded

It seems as though a lazy sys admin has given us a password (12345).  Since the only username I may have is “togie”, I give SSH a shot:

SSH

Figure 20 ssh banner

Well it appears that ssh is indeed running on port 22 as our nmap scan suggested.  As you can see, I specified “togie” as my user, and upon entering “12345” as the password:

Figure 21 togie successful login

Again, this is the only user I’m aware of, so I’m going to just go for gold and see if we have sudo permissions:

Figure 22 sudo for togie confirmed

At this point, popping root is as easy as 1,2,3,4,5:

Figure 23 Never fear, I is here

We are still in /home/togie, so let’s cd to /root and see if there are any goodies:

Mitigations

All of these attacks could have been prevented if the following were changed:

1. Anonymous shares were disabled
2. Sysadmin had not written down the password in a .txt file (deets.txt)
3. Password could have been easily bruteforced due to being only 5 characters long consisting of only numbers.  Therefore, they should be required to provide a longer password, especially given their elevated permissions.

Lessons Learned

This was a rather enjoyable (albeit very easy) beginner Boot2Root, thanks to @TogieMcdogie for putting it together.  This Boot2Root definitely reinforced that NetBIOS and SMB enumeration should not be ignored, no matter what the results.  This fact alone makes me want to go back through other VMs and see what more information can be obtained.