Metasploit is one of the many tools that can be used during a penetration test, and it actually consists of a whole suite of tools, that forms part of a complete attacking framework. Metasploit is not the best tool for every job during a penetration test. However it definitely has its place, and can be very handy if used appropriately.
For the purpose of this blog I will go through a scenario of steps that might be taken during a penetration test. I will purposely use only Metasploit, doing so trying to demonstrate the potential that Metaspliot has.
It is not sensible to rely exclusively on your tools during a penetration test... as they might be wrong from time to time.
It is good practice to try and verify your results and/or findings with another tool if possible. Naturally nothing beats manual verification, for example if a tool says anonymous FTP is possible, the best is to manually FTP to that host and make sure the tool is correct.
As an attack platform, I will be using Backtrack 5R2, which has Metasploit already installed. Also very important it comes with a postgresql database already setup, connected and ready to accept data.
The scope and target network for this penetration test scenario will be 192.168.3.0/24.
So, let's start off with some basics…
Open msfconsole, and check the database status.
OK so let's talk about workspaces. In Metasploit workspaces are used as logical units for information. You can have different workspaces for different penetration tests or different locations of the penetration test. It is easy to import and export data between different workspaces.
There are a couple of tables storing the data inside the workspaces like hosts, services, vulns, loot and notes. Information can be added into these tables manually, for example adding a host into the hosts table:
And a service can also be added manually into the services table:
To populate these tables automatically, you can use db_nmap. You can also use your favorite scanning tool, export your results to an xml file, then import the xml file into the Metasploit database. This can be done with using the db_import inside mfsconsole; as you can see various tools are supported:
Let's start by doing a nmap scan:
Taking a look at the hosts table, you can see it contains the scan results:
Taking a look at the services table, we can also display tables with only the fields we want to see:
Because we see so many Windows hosts, let's take a look at a auxilliary module, a smb version scanner:
So we need to specify a target host, with the set command. But we will have to do the hosts one by one. This is one of the places where the metaplot database comes in very handy, we will add hosts from the services database with the port 445 as a file:
After the scan is done we take a look at the services table:
So we have Windows 2003 hosts, only one host has service pack 1 installed. We have the names for the hosts and the Domain name is "TEST".
Other information I'm just guessing is TEST-EMEA-DC-01 is a domain controller and TEST-EMEA-DB-01 might be a database server.
OK, let's look at the potential database server:
So one would assume mssql because it is a Windows host. But that by default runs on TCP port 1433 which is not present. I am going to take a shot in the dark and run a test for mssql:
Seems like we have a winner:
OK, there. It picked up a mssql instance. Running on port 1043, SQLEXPRESS.
It's running version 9.00.4035.00, and according to the build number it's Microsoft SQL 2005 SP3.
We peek into the services table, to see what changed:
It added TCP port 1043 as mssql as well as UDP port 1433, this is the port that gave the real port for mssql away.
Now that we know there is a databse running and on what port, we can do a brute-force attack, using Metasploit yet again.
We set the right RPORT and we are going to try the same password as the username:
Then we run it, and succesfully find the password:
OK, we have the password. So this is our first credential. So we take a look at the creds table:
Exploit time:
So we know the username, password and the port:
Then we have a meterpreter shell:
Background that session. Then we look at the sessions, and we have 1 session:
Next I want to show you some post exploit modules
OK so we can use smart _hashdump to check for hashes. Set SESSIONS and GETSYSTEM parameters:
Then we run it:
OK so we have something in the loot table.
It got SYSTEM priviledges, and was able to get 2 hashes. It seems the true administrator account is "localadmin" seeing the RID is 500. So Adminstrator is just as dummy account.
So we look at the loot table because we haven't already:
So we look at creds, we have 3 already:
We need to test to see if this local admin password is re-used on the other systems.
So we have erveything we need:
First we add the hosts list, from the services table:
So we are not cracking the hash, we are going to simply passing the hash. We also set
USER_AS_PASS to false and BLANK_PASSWORDS to false:
We see lots of successful, logins when we run it:
Loads more credentials found:
So we have the local password for vulnerable Windows systems. We can use the psexec exploit, but you will have to do it one by one. In exploits you have a RHOST not a RHOSTS so you can't give it a list. I want to show you another thing you can use for automation - resource scripts.
With the help of various sources on the Internet, I put together this script. This script can be easily changed and more modules can be added to step through:
We just do the psexec at the moment.
We can't run the resource yet, as by default the payload windows/meterpreter/reverse_tcp is used, the problem with that is the listening port can't be the same, so we use the windows/meterpreter/bind_tcp payload instead:
Then we run my resource script:
We are left with 9 sessions, with the localadmin account:
We then need to try and find some more hashes, now normally we have to do it manually again, by interacting with every session and dumping the hashes.
Instead we can use a post module credential collector. This post module will give us the hashes and also very importantly it will use incognito and look for domain tokens. But again the module needs to be run manually step by step on each session, unless we use another resource file…
Starts collecting hashes and tokens:
Session 5 and session 6 seems to have some interesting domain tokens:
We manage to steal the token and now we have domain admin level access:
This concludes the demonstration of Metasploit and some of its various components within.
Happy Metasploiting…