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.
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
Now that we know the system is vulnerable to this attack we can fire up msfconsole and exploit the target.
Simply run msfconsole
Don’t you love the banners every time you login 🙂
Search for the ms08_067 module with a simple search
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)
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.
set RHOST 192.168.1.104
“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.
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.
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.
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.
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.
set rhost 192.168.1.105
set SMBUSER administrator
set SMBPASS 25d4823ec0752acc38f10713b629b565:cf4762a61e232355aa12d713a083d5fd
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.
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.
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.
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.
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!