Using samdump2

In Penetration Testing, Weidman walks you through pulling hashes from the Security Account Manager (SAM) database on a Windows machine. SysKey is the Microsoft utility that encrypts the SAM database. SysKey uses the bootkey for encryption, which is actually an amalgamation of four separate keys contained in hidden fields within the registry. Luckily there are some tools that do the hard work of extracting the key for us

In the text, bkhive is used to extract the key and then samdump2 is used to decrypt the SAM database and reveal the password hashes. The hashes must then be cracked using John the Ripper or another similar hash cracking tool.

When walking through the scenario in the text, there are a few issues. First, bkhive is no longer pre-installed on Kali. It isn’t necessary for it to be installed, as samdump2 can perform both functions, but the syntax is not readily apparent and searching on the Internet yields a lot of outdated information on using bkhive in conjunction with samdump2. Previously bkhive would be the tool that extracted the key from the SYSTEM hive and samdump2 would take that key, decrypt the SAM file. This gives you the password hashes and associated accounts for the machine. There are two solutions to get this working again: install older versions of bkhive and samdump2 software and use those or use samdump2 for both functions.

First, we’ll install the old versions. This is a bad way to do things, but doing this will allow you to follow the example in the text as written. This took longer to figure out than I care to admit.

The Kali repositories have bkhive available, however installing from the repo does not give you a usable application, instead building out directories in /usr/share and placing documentation in those. Older versions of the software are maintained online and can be downloaded:

wget http://http.us.debian.org/debian/pool/main/b/bkhive/bkhive_1.1.1-1_amd64.deb

apt-get install libssl-dev

dpkg -i bkhive_1.1.1-1_amd64.deb

 Now you have a version of bkhive that will work with the steps and syntax in the text. But the installed version of samdump2 still won’t accept the key as input, it is looking for the SYSTEM hive.

So to roll back the version of samdump2, first we have to install libssl1.0.0:

wget http://security.debian.org/debian-security/pool/updates/main/o/openssl/libssl1.0.0_1.0.1t-1+deb8u5_amd64.deb

dpkg -i libssl1.0.0_1.0.1t-1+deb8u5_amd64.deb

Now install the old version of samdump2:

wget http://http.us.debian.org/debian/pool/main/s/samdump2/samdump2_1.1.1-1.1_amd64.deb

Dpkg -i samdump2_1.1.1-1.1_amd64.deb

And now we follow the example in the text:

The simpler, and definitely preferable, alternative is just to use samdump2 for both key extraction and for pulling the hashes out of the SAM database. The syntax is pretty simple:

samdump2 SYSTEM SAM > hashes.txt

This command takes the location of the key to be extracted, the location of the SAM database, performs the extraction, decrypts the SAM database, and then outputs the results to hashes.txt. There are options for debugging if needed, available in the command help. Simple enough! Now using either method you have hashes ready to be cracked.

Moar Recon: Netcat and Web Vulnerabilities

I wanted to add a little more detail to what I’m doing with reconnaissance, but I want to be careful not to just copy the stuff in the book. I don’t think that adds anything of value when trying to learn, plus I don’t think anyone would appreciate me uploading their book to the internet one chapter at a time.

So to take it a little further and focus more on OSCP objectives, as I’ve understood from my research, we want to do as much of this enumeration as we can without tools like Nessus. The first thing to try is running nmap scripts. Nmap comes with a ton of scripts loaded that can gauge for vulnerabilities, perform exploits, detect service versions, plus a ton of other things. For my purposes I’m only running the default scripts to just get an idea of what they do.

nse1

We get a ton of information here. From the top, we see FTP. It has run a script and tested anonymous logon and found that open. We can dig just a little deeper and see if we can find anything else with netcat:

nc-ftp1

Netcat displays the version and would allow us to log in. We can do a search and find that there doesn’t seem to be any exploits associated with this particular version of Filezilla. Moving on, we see that SMTP was listed along with a list of available commands. From here we can attempt to verify any possible account names we may think we have. The nmap scan shows us that ports 80 and 443 are hosting websites is XAMPP 1.7.2. We can verify this pretty easily:

xampp1

We can use netcat again to connect and find out a little more information about the server. What kind of web server is it running? What supporting services?

nc-http1

This is my first time really using netcat operationally, I’m familiar with the functionality and syntax but now we’re in it. As you see above, I get what appears to be an error. Even though we get an error, we still get the information we were looking for. The server is running Apache 2.2.12, WebDAV 2 is running which we know from the text should be examined for default credentials, and php 5.3 is running.

I tried to dig more into the error and decided to fire up Aule (vulnerable Ubuntu machine that is designed for use with the book) and try that. So the website works:

aule1

And we try netcat:

nc-aule-http1

And get a similar error, but again we get the header information we were looking for. This needs more testing, right now on every server I have with a website I get back the “bad request” error but it isn’t the end of the world since I get the header info and that is my objective right now.

One of the things the book points out about Lorien is that it is running phpmyadmin, because it comes in XAMPP. Since it is there in black and white, we know to check it. But how could we use a tool to find this out if it were not in the book? Using Nikto we can scan Lorien to see more information about available web interfaces:

nikto-lorien1

I ran it this way to just get an idea of the output. For Lorien I got a lot of output and it was easier to pipe the Nikto results into a text file and go through it that way. Nikto enumerates each available directory and we can look at the web pages associated with those. Like the /server-status page:

lorien-site-enum1

The server information we have here matches up with the results of the Nikto scan, the netcat results, the nmap scan, the Nessus scan, and the OpenVAS scan. Which is cheating, since Nessus and OpenVAS actually use nmap. But still important to note the different ways to get needed info.

Further down the directory list we see /server-info:

lorien-site-enum4

Again, we see the server info. But there is much more. We have the root directory right there, which if we didn’t already know would help us with directory traversal. We have the location of various configuration files. Hey let’s look at at mod_alias.c, the Apache file that maps URL requests to aliases (among other things):

lorien-site-enum5

We see several accessible directories and can try each one. Hey look, it’s phpmyadmin:

lorien-site-enum2

We can look at this service and determine vulnerabilities, but the page is helpful as well:

lorien-site-enum3

Oh my…

There are some other issues to identify here from the book, but I’m more concerned with how to get the info on my own and using tools I know rather than just reading the vulnerability info from the book. We have enough information now to move forward. One thing I do want to investigate is credentials. From the book we know that WebDAV is running here with default credentials, however I need to identify the best way to discover that using available tools. 

This is finals/project presentation time at school so I have no idea when I will get a chance to move forward with my lab. At least a week I am thinking.