All the information I’m about to go over is nothing new, I’m just trying to organize all my notes on pen testing mssql. Hopefully my notes will help others. All the commands and instructions are Linux based so keep that in mind.

The first thing you’ll need to do is discover IP addresses that have mssql running. So you’ll accomplish this by running some type of scan. The scanner of choice is always nmap but there are some things you’ll need to consider when scanning for mssql. The default port for mssql is 1433 but just like with any service it can listen any port. So for starters it’s definitely a good idea to scan an IP range looking for port 1433.

Step 1 scan for port 1433, this can be done using the following nmap command.

This will only scan for port 1433 on host 130-140, your IP range will vary. My output is below.

In this case the 131 host port is closed but the 132 host has port 1433 open. So great success we’ve found a box running mssql. Hold your horses because this is simply the beginning. If you’re scanning is focused then this type of scan is fine, meaning I’m not scanning thousands of hosts I’m only focused on a handful of hosts. If I’m only concerned about scanning a handful of hosts then my next step would be to determine two things.

1. Version of the database
2. Are there any other additional listening ports for this database

To determine the version of the database we can once again turn to nmap.

The “-A” option will try and determine as much information as it can about the service on port 1433 in this case. The “-A” option will also try and determine the underlying OS running as well. Below is the output from this scan.

So you’ll notice in the output nmap is reporting the version of mssql to be SQL Server 2005 which is correct in this case. Knowing the version is very important because different versions of SQL Server provide different security features and also have different vulnerabilities. There are other ways of determining the version of sql server without authenticating but to me nmap is the best solution.

Next let’s talk about looking for other ports that mssql may be listening on. For multiple reasons, like load balancing, mssql can listen on multiple ports. When pen testing mssql we want to know what those ports are so we can bang against them. Depending on the configuration you can authenticate to every listening mssql port. One thing to keep in mind is that you can authenticate to mssql using your normal windows / network / active directory credentials or you can authenticate using an account that was setup on the mssql server. This is basically known as windows authentication or sql authentication. When setting up the sql server and ports the database administrator will have to configure on how this authentication takes place. The easier target is using sql credentials as those are typically configured with a weaker password policy. Now that I’ve discussed some of the issues let’s get cracking. So to determine additional ports that a database may be running on we’ll once again turn to nmap. This time I told mssql to also listen on port 1444 and 1433.

So now go ahead and run the same nmap command as before.

So we see that nmap reports back ports 1444 and 1433 are listening. You may be wondering how nmap knew that port 1444 was open. MSSQL runs a service called the “browser service” which runs on port 1434 and uses UDP instead of TCP. If this browser service wasn’t running nmap wouldn’t be able to pull this information. Basically nmap queries port 1434 asking for any other instances that are running on different ports. It does this using the mssql nmap script. There are a couple of other tools here and here that do the same thing but I stick with nmap since it’s already baked in. So the browser service and additional ports is a very important to keep in mind when pen testing mssql.

Now we have more information about our target which hopefully means we’ll find a weak spot that we can exploit. Once you know the version it’s always recommended to search CVE (common vulnerabilities and weaknesses) and it may also not be a bad idea to search inside the metasploit tool as well. There aren’t a whole lot of remote code execution vulnerabilities for anything SQL Server 2005 and beyond but it’s always worth checking just to make sure. So if they aren’t running an old unpatched version of mssql then that means you’ll need credentials to authenticate to the sql server. This means we’ll need to try and brute force the credentials. The main tool I like to use to perform brute force attacks is medusa, another good alternative is hydra. I have had different degrees of luck with both tools so it may be useful to run both tools although my default is medusa. I will only cover how to use medusa, below is the typical command line options that you feed into medusa.

The -h is the host, the -U is the username list, -P is the password list, -O is the output file, -M is the module you want to run against in this case it’s mssql. Below is the output of this command.

Your output file resemble the following.

The file output is much easier to parse and we can see in the next to last line that it was successful in finding credentials of username = sa and password = password. By default medusa will run against the standard port which is 1433 in this case, if you want medusa to run against a non standard port you’ll need to include the “-n” option.

So you see that medusa was able to authenticate to port 1444 with the same username and password. This may not always be the case. With mssql you can configure different ports with different credentials so it’s always best to run a brute force tool like medusa on each individual port and see if you get any hits. Medusa and hydra can take a while to run in my case I had a very small dictionary seen below.

Large dictionaries can take some time to run so keep that in mind when you’re brute forcing using these kinds of tools. So we got lucky and we credentials for a mssql database, that’s awesome but it’s just another step in the process. Going forward we have a couple of options. As a true attacker you would consider the following options.

1. Plunder the database for information
2. Use your credentials to gain further access (e.g. administrator on the underlying operating system)
3. Start serving up malware for potential victims

I’m not going to touch on the third option but I will discuss the first and second option. So for the first option once we have credentials we can start to query the database. In this scenario I’ve got the best kind of credentials you can ask for on a mssql database which is the “sa” user. This will not always be the case but it’s the example I’ve chosen to follow. One good thing to run with credentials is metasploit’s enum tool. This module basically gives you an overview of the sql server configuration and some note worthy security related configurations. Below is how to use mssql_enum.

Below is the output of running the tool.

I’m not going to go through this entire output but all of it is relevant to security configuration. Things to note are permissions which the service runs as, password settings (e.g. account lock outs, password expiration), and stored procedures that are available. You can read more about stored procedures but the main thing to know is that they extend the functionality of mssql by giving easy access to common tasks such as granting access to a database. The one stored procedure every pen tester wants access to is the mighty xp_cmdshell which allows you to execute operating system commands with a database call. So information that you can obtain, xp_cmdshell enabled or disabled, about the database will help you to further assess or pen test the setup. Going forward it’s best to have some sort of mssql client so that you can make sql queries to the database. I’m a fan of keeping things lightweight so I prefer command line clients and not GUI (graphical user interface) clients. So for accessing mssql from Linux I recommend sqsh and as for accessing from a windows PC I like the Microsoft SQL Server Command Line Utilities which will first require an install of the Microsoft SQL Server Native Client, both microsoft tools can be found here. Now we’ll get items of interest such as stored procedures but first let’s use one of the clients mentioned to access and run some sql queries. The syntax for both clients is very similar but first let’s look at the microsoft client. You’ll first need to change to the proper folder where the sql client was installed.

So to connect to 192.168.134.132 run the following command.

Below are the basic options for this command

After you’ve run the above command you should see the following.

So the “1>” is the prompt where you will enter your sql commands, let’s just run a basic sql query to confirm everything works, we’ll query for the version in this case.

So after typing your sql query you’ll be dropped down to your second prompt “2>” there you will need to type “go” and hit enter for it to run your query. Running the sqsh client you’ll get similar results.

Just type “exit” if you want to leave the client. Another thing to note is the help menu for both commands. Below is the help command for sqsh.

Help for sqlcmd.exe

One thing that might not be very clear from the help output is how you would connect to a different port. By default both of these clients connect on port 1433, if you want to connect to a different port you’ll have to use the following syntax.

So getting the versions of the database proves that our clients are working correctly and we have access, next we’ll focus on sql queries that will extract some useful information that a pen tester could leverage.
Determine the current user

Create user “travis” with password “secret”

Or another way

Create a table named pwned

Determine current database

List all databases

Determine host name of PC the database is installed on

Determine users with sysadmin rights

Add user travis to the sysadmin role

Now as an attacker I mentioned the three basic options of plunder database, use credentials for further access, and hosting malware. The commands above are examples of “plundering” the database and these commands merely scratch the surface. Another plundering idea would be to search all databases for “items of interest”. Once you have credentials to the database you have plenty of options for plundering. The second step I mentioned was using your credentials for further access. Two things come to my mind which is cracking sql passwords and gaining access to the underlying OS that hosts the database. An attacker would want to know sql passwords because often those passwords are reused. That reuse includes other databases and possibly other credentials such as active directory credentials. The other piece of gaining access to the underlying OS of the database will allow you to do a number of things such as key logging, searching the file system, pass the hash technique, etc. So I’ll first discuss how to crack the encrypted passwords inside of a mssql database. Just so we’re on the same page a password is not supposed to be stored in clear text in a database is suppose to be stored encrypted as a cryptographic hash. Cryptographic hash is a fancy way of saying that the password cannot be easily determined and they encrypted value is commonly referred as a hash, not to be confused with the delicious food. So the next step is to get these hashes and crack’em.

Extract username and password hashes

You should see something like the following

Now you can take that password hash and feed it into a password cracker such as john the ripper but before you do that you’ll need to add a zero plus X “0x” to the beginning of the password hash. This needs to be done because john the ripper expects password hashes in certain formats and if you need to know what that format is for various types of hash functions then pentestmonkey is a good resource for this type of information. So your modified hash with zero plus X in front should look like the following.

Now put that into a text file so we can feed it to john the ripper, in this case I named it mssqlHash.txt. Next all you have to do is use the command “john” along with the file that contains the password hashes as below.

Here john the ripper was able to crack this hash and determined the password was “secret”. So now that you’ve cracked some passwords on this database there’s a good chance that username and password will work on other databases within the environment you’re testing. Seeing how server and database admins like to keep things together that same username and password will probably work on another machine on the same vlan so just start nmap scanning to find those open ports then add the username and password you found into your medusa dictionary then let medusa do it’s brute forcing and hopefully you’ll find another database you can gain access to.

The last technique I’ll discuss is gaining access to the underlying operating system that the database is running on. Having sysadmin credentials on the database is awesome but having admin on the underlying operating system is even better. As I mentioned before the stored procedure xp_cmdshell is the best way to gain this kind of access but as you can see from the metasploit enum module xp_cmdshell isn’t always at our disposal. The xp_cmdshell was enabled by default on mssql 2000 but mssql 2005 and beyond by default does not enable this stored procedure. Even so a mssql 2000 database administrator could disable it as well. One way and maybe the easiest way is to use metasploits mssql_payload module to enable the xp_cmdshell and give you a meterpreter shell back. Below is the command you’ll need to run. You have to set at least the host you’re targeting (rhost) and the password of the “sa” account. This module will not work unless the user you’re authenticating with has sysadmin credentials, so the account doesn’t have to be “sa” but it has to be a user with a sysadmin role.

So at this point we have a meterpreter command prompt on the target computer which is better than a regular windows command prompt. From here we can launch a number of attacks. I’m not going to touch on those for that just simply google “post exploitation” to get an idea of what you may want to accomplish next. At this point its a good idea to make sure you’re on the right computer and determine the types of credentials we have on our target machine. The following commands will determine that information.

So we’re on the correct computer and we have “system” credentials which is the highest credentials you can have on a windows platform. Great success. At the heart of this metasploit module is some sql commands that will enable the xp_cmdshell. If you wanted to manually enable xp_cmdshell you could enter the sql commands below.

That’s all folks, more could be covered here but this will get you started. Once again I haven’t covered anything new here and this documentation is meant to capture some of the common tasks that need to be completed when testing mssql. Hope this helps and happy mssql hunting.

So up to this point you’ve probably only ran honeyd on your laptop or desktop machine. If you want to get the most out of honeyd then you’ll probably want to run it on either a server or an embedded device. In the beginning of this series I mentioned you could run a honeypot in a number of ways. Two of the ways I mentioned was to attract malware to a vulnerable system so that you can analyze the latest and greatest malware. The other way was to attract attackers on your network. In my series I’m going to keep the focus on detecting attackers on the local network and not trying to find new malware. The honeynet project already does a great job of tracking down the latest and greatest malware so check that project out.

If you’re going to use honeyd to detect attackers on your local network then you’ll need to place your honeypot as close to your networking equipment as possible. This being the case a racked server or small device with numerous network interfaces will likely be the best solution. A racked server didn’t make much sense for my solution mainly due to the cost but a small embedded device would need good specs to make a good solution. I found a couple of solutions.

First the option that I went with to implement my honeypot running honeyd. The Soekris Net5501.

The great thing about the Soekris is that it has four network interfaces. This allows you access to four different vlans within your environment. Out of the box it comes with the ability to load an OS on compact flash, which is the option that I went with. You could also get a PCI extension that could be fitted with a hard drive. If your install of a honeypot would require large data storage then you’ll need to think about that option. I did not care about data storage, I simply wanted an alert when honeyd saw something come across the wire. Besides even if you needed storage you could have honeyd ship off that data / logs to a centralized location. For $250 bucks this is a great solution. You won’t find to many small devices like this that have four network interfaces. Now you could get a full rack system with plenty of network interfaces but then your cost goes up. More network interfaces would mean that you have access to more vlans so if that’s important to you then you’ll have to plan accordingly. This is setup is not meant to cover your entire organization just a handful of important vlans. Below is a diagram of a potential setup.

In this setup you can place a honeyd host on four different vlans looking for any devices that connect to your honeypot when they should have no business connecting to your honeypot. Keep in mind this is not meant to be an intrusion detection replacement. This solution will ride on top of your existing intrusion detection. Besides most intrusion detection setups that I’ve seen don’t monitor activity inside a particular vlan much less traffic between vlans. The setup I’ve described here is meant to monitor vlans with important assests and data. So in the scenario above you would have to connect your Soekris device to a “core” router that has the vlans you want to monitor. You could also connect the Soekris device to multiple routers if those vlans are mananged by different routers. There are numerous ways to tackle a problem that I’ve described but this is just one of those ways.

There is another device that I believe is very handy in these types of situations and that’s the Alix boards by PC Engines. If you want to buy one I would recomend NetGate which also has other options such as enclosures and lots of other wireless goodness. The Alix board plus enclosure is very small, about the same size of a home wireless router. Below is an Alix board without the enclosure.

You can buy them with a number of configurations, the one above has three network interfaces, one compact flash, one mini pci, plus a cpu and RAM. So no hard drive but you can easily run your OS on the compact flash. Of course the OS of choice should be Linux. Hopefully this answers the question as to what hardware you might could use for your installation of a honeypot in your organization’s environment. Unless you do everything at your organization this type of work will require you to work closely with your network engineering team. That’s all I have, I’d love to hear from others on how they have their honeypots setup and what hardware is powering that setup. Please comment if you have a question.

Remotely determine logged in user

List running processes

Kill a process

Determine open shares

Determine IP address

Get a new IP address

Remotely display machine’s MAC address

Remotely list running processes every second

Remotely display System Info

Disk drive information

Bios info

List all patches

Look for a particular patch

Remotely List Local Enabled Accounts

Start a service remotely

List services

Disable startup service

List user accounts

Enable RDP remotely

List number of times a user logged on

Query active RDP sessions

Remove active RDP session ID 2

Remotely query registry for last logged in user

List all computers in domain “blah”

Reboot

Shutdown

Remotely reboot machine

Copy entire folder and its contents from a remote source to local machine

Find location of file with string “blah” in file name

Spawn a new command prompt

Determine name of a machine with known IP

Find directory named blah

Command line history

Determine the current user (aka whoami Linux equivalent)

Determine who is apart of the administrators group

Add a user where travis is the username and password is blah

Add user travis to administrators group

List user accounts

Map a network share with a given drive letter of T:

List network connections and the programs that are making those connections

Display contents of file text.txt

Edit contents of file text.txt

Determine PC name

Run cmd.exe as administrator user

Uninstall a program, Symantec in this case ;-}

Determine whether a system is 32 or 64 bit

Powershell one liner download file

Information about OS version and other useful system information

Startup applications

Recursively unzip all zip folders, you’ll need unzip.exe for this

It’s rare during a penetration test that I actually exploit a vulnerability to gain more information. Newcomers to my filed will often use the term “network security”. I don’t care about the network, have the network for all I care. What I’m more concerned about is the information inside the network. The better way to describe it is “information security”. Performing penetration tests one has to keep that in mind, yea it’s fun to exploit some user that’s running an old version of war-ftp but if that user doesn’t yield sensitive information then who cares to some extent.

I often see that professional penetration testers will highlight an open windows share that can be read or written to by everyone. They will often highlight other shares that are accessible by a large group such as Authenticated users. I don’t want to scoff at these types of open shares as they should be investigated by the business owner that created the open shares. The main thing to consider is what information lies within those open shares. Open shares are usually created for a reason, so that users easily share information. This is not bad unless the information in those shares is secret / classified material. To check for this possible sensitive information one would have to search all the files and folders in that share. Now you can use the cute little dog search feature inside of windows explorer to look for this information but using that your hands are somewhat tied. The search feature inside windows explorer actually does a nice job but if you wanted to automate the process to look at multiple shares and search for multiple terms then you’re out of luck. Because of this I wanted to script something that would automate the process. Powershell could have been an option but because I’m already familiar with python I stuck to what I know. This means that in order to run the script you’ll have to have python installed on windows. I could have written the script to work in Linux but that would have meant using cifs to map drives which seemed like more of a headache then just using python on windows.

You’ll need to open up a windows command prompt to run the script and it’s a good idead to add Python to the windows path. So the script takes two arguments. The first argument is the file containing all the shares that you want to search. The second argument is the file that contains all the terms you want to search for. So to run the script you would issue a command similar to below, where searchShares.py is the name of the python script.

Your shares.txt file should look similar to below.

Your searchTerms.txt file should look similar to below.

In the example above the term “secret” will be recursively searched in all three shares. Then “password” will be recursively searched in all three shares, then so on and so on. The script will output any file, file name, or folder name that matches any of the search terms. Currently the script will read each file in binary format which means if it comes across a word document file (such as document.doc) it doesn’t open / read the file like microsoft word would. The current script reads each line of the binary file looking for your search term. Reading a text file as binary seems to work fine but reading in microsoft office documents as binary have different results. One thing I’ve noticed in my testing is that generally speaking it does just fine searching through a *.doc file but has trouble searching through a *.docx file. Binary searching is not ideal but it’s my current solution. Python has the capability to open microsoft office documents in a more native format but for my first go round I haven’t implemented that solution.

Once you run the script you will see output similar to below.

This output on the command prompt is to given as a verbose message so that you know what’s going on with the script. The output on the command prompt will not tell you if it found a search term. The results of your searching is placed in a text file called output.txt located in the current directory. The content of output.txt should look similar to the following.

So you can see that it matches the file name as well as the contents of the file. One thing to keep in mind is that this script can take a while to run. There two factors that control how fast it runs, 1) Speed of the network and 2) Size (GB, MB, etc) of the share. It works best when your network is local and not in another city. The biggest factor is going to be the size of the share. Running this script on a major file sahre that is say 800 GB in size will take a very long time. Keep in mind you can specify specific directories, so instead of searching in the root share such as \\share\one maybe it’s a better idea to searh in \\share\one\two\three. So keep these factors in mind when running the script. Below is the script, simply cut and paste into your text editor of choice and save as searchShares.py

import os

import sys

import re



output = open('output.txt', 'a')

output.write('\n')

fileList = []

shareList = open(sys.argv[1])

eachShare = shareList.readlines();

for shares in eachShare:

    path = shares.rstrip('\r\n')

    print '\nWalking directory ' + path + '\n'

    for root, subFolders, files in os.walk(path):

        #print 'Indexing ' + root + '\n'

        for file in files:

            fileList.append(os.path.join(root,file))

            print 'Found ' + root + file

keywords = open(sys.argv[2])

searchTerm = keywords.readlines();

output.write('=== Directories or file names matching search criteria ===\n')

for term in searchTerm:

    strip = term.rstrip('\r\n')

    if any(strip in s for s in fileList):

        matching = [s for s in fileList if strip in s]

        for item in matching:

            output.write('\n' + item)

output.write('\n\n=== Files matching search criteria ===\n\n')

for term in searchTerm:

    strip = term.strip('\r\n')

    for item in fileList:

        print 'Searching file ' + item + ' for term ' + term

        searchFile = open(item, 'rb')

        for line in searchFile:

            if re.search(strip, line, re.IGNORECASE):

                output.write('found ' + strip + ' in file ' + item + '\n')

                break

    searchFile.close()

output.close()

Let me know if this works / doesn’t work and also let me know if you have any suggestions on how to make it better. One thing I might do in the future is to limit the types of files it searches to say only .txt, .doc, .xls, etc. Happy hunting for information on shares.

In the past two tutorials I’ve used DHCP to obtain IP’s for our honeypots running honeyd. Using dhcp is fine when testing honeyd and getting familiar with how honeyd works but a static IP may be more suitable for your environment. In my case I initially fooled around with honeyd via dhcp but when I wanted to implement in a more production environment I realized that static IP’s are more stable and less maintenance. In order to ping our honeypot the router / switch has to know what IP and MAC address our honeypot has so it can update it’s information, going through dhcp does this automatically. I’ll touch on how to add the static IP configuration later but first let’s go over our layout. I’ll be using the same simple layout as in the first tutorial as seen below.

There may need to be some clarification in that diagram. Backtrack is what is actually running honeyd, the address of 192.168.99.135 (labeled Honeyd) which is the honeypot honeyd created can be configured to emulate any operating system. Now for the honeyd config file.

So the only real difference between dhcp and a static IP is the last line of the config. If you go back to the first tutorial you’ll notice the last line is the only difference as well. As a side I’ve used some configs that do not have the MAC address defined in their config but when I did not include the “set windows ethernet” line honeyd would complain and not start. So after you’ve set your config simply start honeyd.

After running honeyd you should get similar output to below.

The difference in output between static and dynamic is that you’ll see the IP address your honeypot gets when using DHCP. With static IP configuration you’re not going to get that in your output because you already know the IP you’re using. So the output via DHCP will the lines below included.

So now you’ve take care of properly setting up honeyd to use a static IP address but now you’ll have to configure the network to use your static IP. In my enterprise production environment I’ve configured this via the DHCP server. I went into the DHCP server and made a static reservation. I also had to configure the switch I plugged my computer into and tell what VLAN that port needed to be assigned to. If you’re trying to get this set up in your work production environment you may have to work with your network team that manages DHCP / DNS / routers & switches. Networks may be managed differently so check with your local team on how you would get a static IP. Now if you’re doing this on a home network for testing then you probably have a wireless router such as Linksys. Inside all of these home wireless routers you can configure static IP’s. Each wireless router will have different steps for configuring static IP’s so refer to your manufacturers documentation on how to do that.

Next in this tutorial is what to run your honeypot / honeyd on? Laptop, desktop, server? These questions will be tackled in future articles.