Armitage is a GUI front-end for Metasploit and we can use it to run all sorts of attacks on our target Windows users. Since this is a new installation which Metasploit has never been run before, we start with errors and setup. The first illustration is the error raised by postgresql not starting when Armitage tried to bring up the Metasploit service:
Since this is Kali Linux 2.0, we will try and start the postgresql server with the command:
/etc/init.d/postgresql start
After starting postgresql successfully, we started the Metasploit console as well and then started Armitage from a terminal window, so we could watch the standard output while it came up. It took quite a while for the Armitage window to come up, and for a few minutes it looked like the Metasploit service would not let us bring Armitage up.
The first step after it came up was to load the exploits, as shown in the following illustration. You have two choices: Find Attacks and Hail Mary. If you choose Hail Mary, the system will throw everything it has at all the possible targets. If you choose Find Attacks, the likely exploits for each target will come up beside it. We are choosing the Find Attacks path. Hail Mary plays are very noisy. One sign of an expert using the Armitage tool is this specification of the required exploit, rather than just throwing everything at the target network.
Now we are ready to choose targets!
We can import hosts from a list, perform an NMap scan and discover them, or add hosts manually. Because we have only one target right now, we will enter the host manually.
Now we have our host, we can just add the OS version and see what Armitage can come up with. We know it is Windows 7 and we know it has a webserver live on it.
We clicked on the Services and Scan buttons above OS in the first dialog, from right clicking on the host, and it gave us a running Metasploit port scan. When you hit refresh on the services scan, it shows ports 139, 80, and 445 open with Microsoft-IIS 7.5 running and Windows 7 Professional SP1 (build 7601).
We are not creating a workspace for this test because the workspace function does not seem to work as expected. When we ran the Attacks | Find Attacks menu item, it created an additional menu when right-clicking the target machine. This opened a list of all the attacks available for that specific machine's operating system and known open ports. We chose iis for the image below and ran the commands under Check Exploits....
The output shows that the target machine is not susceptible to any of those exploits. This certainly saves time when searching for good exploits to run.
The HTTP attack list has 132 possible exploits, and you must keep in mind that this is a default instance of iis with only one static page up. There are so few customizations or helper applications for iis that direct exploitation is unlikely. When you are checking the viability of so many exploits, just use the keyboard shortcut Ctrl + F to open a search tool.
What if we are given a black-box test where we know the network segments to test but not the specific hosts? It is faster to run a test with Metasploit's scanner or with a linked NMap scan. The following uses the NMap Comprehensive scan. This is noisy and more easily discoverable than a surgical strike on a specific server, so it is best to run this when there is a lot of traffic on the network. Monday morning at about 9:30 should be pretty busy, as people get into the office and start checking their mail and whatnot.
When you choose NMap Comprehensive, a dialog opens asking your choice of IP or range. We are choosing the 192.168.56.0/24 network range to get the entire Class C network segment we expect. We choose the CIDR where the testing machine IP appears on the network. If it is a larger segment, we will miss some of the hosts. If you find no hosts live in the range of 192.168.56.1-192.168.56.255, you can decrease the /CIDR number. If the target network uses public IPs for their internal network, or they are using A or B class private IP ranges, you can reduce the /CIDR number.
As a memory jogger, in IP version 4, Classless Inter-Domain Routing (CIDR) was introduced to reduce waste of a limited number of available IP addresses. The CIDR number is the number of bits in the subnet mask. In theory, you can have CIDR numbers less than 8, which is the bitcount of a Class A network. Starting with our expected 254 possible hosts in a Class C network, every time you reduce the CIDR number by 1, you double the possible number of hosts to scan. A Class A network with 17 million hosts to scan can take an appreciably long time. This is one of the reasons you will never want to do that.
Now that our NMap scan is done, let's look at our hosts. We have the following hosts up at the moment:
- Kali Attack platform:
192.168.56.101 - Windows Workstation:
192.168.56.102 - Windows Server 2012:
192.168.56.103
In this chapter, we are going to go after the webserver on the Windows Server 2012.
There are dozens of possible exploits for HTTP and four exploits for IIS. The easiest thing to do is to check which exploits have a chance of working on this webserver. Since there are only four IIS exploits, we will check for those first.
The very last item in each list is a link to check exploits..., so we will do that now.
The outcome of the IIS check is that the host is not exploitable, so we have to go after the HTTP attacks and mssql injection attacks. This machine has several possible exploits, but for the most part the applications have proven to be difficult. We have another Windows webserver on the secondary network. We can rattle its cage a bit. The next image is the setup dialog for ms09_004_sp_replwritetovarbin_sqli, an injection exploit.
The following image is the exploit to attack Microsoft SQL Server: exploit/windows/mssql/ms09_004_sp_replwritetovarbin_sqli.
