Didier Stevens

There are several how-tos on the Internet explaining you how to extract hashes from the Active Directory database file. I used this how-to for Kali Linux: https://blog.joelj.org/windows-password-audit-with-kali-linux/

The tools libesedb and ntdsxtract are used in this how-to.

I encountered an error when making libesedb:

libcfile_support.c:742:2: error: #error Missing file remove function

Make sure to read the comment from May 6, 2016 for this how-to: it offers a solution for this error. Edit libcfile/libcfile_support.c and add this line at the top:

#define HAVE_UNLINK 1

First we get the Active Directory database file I published and unzip it:

Next we use libesedb (command esedbexport) to export the tables from ntds.dit:

This may take some time, depending on the size of the database.

The exported tables are in folder ntds.dit.export:

Then we use ntdsxtract (command dsusers.py) to export the hashes (LM and NTLM) from the exported tables. First we export the hashes in a format suitable for John the Ripper. We store the files in folder dump. This command also takes the SYSTEM registry hive (file system) to extract the system key to decrypt the hashes.

We let the command create the folder dump:

Next the tool detects 2 schemas in the exported tables (objects 5 and 1480). First we try schema object 5:

This fails:

So we start again with schema object 1480, but first we need to remove the dump folder:

Now you can find the extracted hashes (lm.john.out and nt.john.out) in folder dump:

Next we repeat the same command but export hashes in a format suitable for hashcat:

Now you can find the extracted hashes (lm.ocl.out and nt.ocl.out) in folder dump:

If you want these hash files to crack the passwords without having to run through this how-to, you can download them here:

ntds-hashes.zip (https)
MD5: B0A84D756C211A97087BA307F0CE5739
SHA256: 009520798DD34831C47ADAC47D6DEB3C153FC44BD9D400A0BB813EBA46728D86

I’m publishing a sample Active Directory database file (ntds.dit) together with the corresponding SYSTEM registry hive so that you can practise hash extraction and password cracking.

This ntds.dit and system file come from a virtual machine I installed just for this purpose: Windows Server 2003 Standard Edition with SP1 (English). The reason I selected an old Windows version, is that 2003 still supports LM hashes by default.

I changed the password policy to allow very weak passwords:

I added 40 users: 20 users with passwords taken from the rockyou database leak and 20 users with random passwords (varying in length from 1 to 20 characters). Some of the passwords I randomly selected from rockyou are longer than 14 characters: when a password is longer than 14 characters, Windows does not store a LM hash for that password.

You can find many how-tos on the Internet showing you how to extract the LM and NTLM hashes from the Active Directory database file. I too will posts examples of hash extraction and password cracking.

Happy cracking!

ntds.zip (https)
MD5: F20E477D9784E009777F286ABF718FA3
SHA256: F5EBBF57B3C646FC339ECEEE03063BEDE9E0E7FC8254B0E57A77CC4036134B04

When I tested hashcat 3.00 I got an error: “fatal error: ‘inc_vendor.cl’ file not found”. The fix for such errors is to update your (GPU) drivers. Unfortunately, I could not update at the moment but I still wanted to play with this new toy 🙂

Here is the output with the errors (the warnings are another indication that a driver update is necessary):

The error is a build error. hashcat was not able to compile the code for a brute-force LM hash attack for my GPU (m03000_a3.2ad8800f.kernel). Older versions of hashcat included compiled code for different attacks, hashes and devices. But since version 2.0 (when hashcat became open source) hashcat compiles this code when necessary: Just In Time (JIT). You can see this in the kernels folder. In older versions (< 2.0) of hashcat, this folder is populated with code. In the newer versions, it is empty.

The build log indicates why this error occurs: file inc_vendor.cl was not found (this file is present in the OpenCL folder) when compiling m03000_a3.cl.

My workaround is to temporarily make the OpenCL folder the working directory, and then run hashcat so that it can compile the kernels:

Now you can find the compiled kernels in the kernels folder:

The mask I specify with this hashcat command is also much smaller: ?1 This way, hashcat terminates quickly and I can move back to the directory I want and use the full mask ?1?1?1?1?1?1?1:

This time there is no build error, because the necessary kernels are already build and taken from the cache (folder kernels).

Remember, this is a workaround, not a fix. The fix is to update the drivers. I updated the drivers later (not without issues), deleted the content of the kernels folder, and started again. This time, without build errors.

FYI: I generated the LM hashes for this example with this website: https://www.tobtu.com/lmntlm.php

In a couple of days Windows will no longer trust sha-1 code-signing. It happened in the past that Microsoft announced changes to AuthentiCode, and then did not follow though, but it looks like this one is going to happen.

First of all, the loss of trust will not happen for all executables with a sha-1 signature. It will only happen with executables with a “Mark of the Web” attribute and without a timestamp or a timestamp after 1/1/2016.

A “Mark of the Web” attribute means that the executable is flagged as downloaded from an untrusted source (the Internet), like this one:

This is done with an Alternate Data Stream (ADS) named Zone.Identifier and with content like this:

[ZoneTransfer]
ZoneId=3

If you develop executables that will be downloaded and you sign with a sha-1 certificate, check that you also include a timestamp. As I explained in my blogpost, you can add a missing timestamp after signing. You don’t even need a code signing certificate to add a timestamp.

I have a couple of how-to posts on digital signatures, like this code signing post. Let me revisit this topic now that Microsoft announced some upcoming changes to code signing.

I use signtool.exe that came with Visual Studio 2013 in my examples. Here is how to use signtool.exe from the command-line to sign an executable:

FYI: in my case, I use option /a because I have more than one code signing certificate and I let signtool decide which one to use (option /a). But if you have only one code signing cert, you don’t need to use option /a.

As you can see, the version of signtool.exe I use (6.3.9600.16384) still uses sha1 by default.

To use sha256 as digest algorithm (since Microsoft will deprecate sha1), use option /fd sha256, like this:

When we look at the details of the signature, we see that there is no Signing time or Countersignatures:

The signature is valid, because we are still in the certificate validity period:

But once we are outside the certificate validity period, the signature is no longer valid:

And this is because a countersignature from a timestamping service is missing. A countersignature can be added with option /tr and the URL of a timestamping service, like this one:

Correction: use this URL for sha256 timestamping: http://timestamp.globalsign.com/?signature=sha2

Option /tr URL specifies a timestamping service that supports the RFC 3161 protocol.

And now the signature remains valid, even after the code signing certificate has expired:

To be sure that the timestamping service uses sha256, we can request this with option /td sha256:

Conclusion: always use a timestamping service when signing code, this way your signature will not expire.

Remark: code signing and timestamping are 2 different operations. There is no requirement to execute these operation with a single command. You can also timestamp a signed executable like this:

First command: sign

Second command: timestamp

And you don’t need a code signing certificate to timestamp a signed executable. You can take any executable with an embedded signature, and add a new timestamping signature with this signtool.exe timestamp command. Why do I mention this? This will become clear in a next post, where we take a closer look at Microsoft’s sha256 code signing announcement.

A last remark: as mentioned, option /a lets signtool.exe decide which certificate (from the certificate store) to use for the code signing (in case you have more than one code signing certificate). But if you want to explicitly select the code signing certificate to use, you can use option /sha1 with the sha1 fingerprint of the certificate you want to use. Important: /sha1 is a method to select a certificate, it does NOT instruct signtool to use the sha1 algorithm for the signature.

I have an updated version of this how-to here: “How-to: Make Your Own Cert With OpenSSL on Windows (Reloaded)“

Some people following my “Howto: Make Your Own Cert With OpenSSL” do this on Windows and some of them encounter problems. So this post shows the procedure on Windows.

If you don’t know how to use the command-line or you don’t want to install OpenSSL to create a simple certificate, I created a tool for Windows that doesn’t require installation: CreateCertGUI.

For your info: I also have a video showing this howto.

First of all, on Windows you will need to install OpenSLL from binaries. I got these binaries.

I installed the latest version (v1.0.2a) and choose the 32-bit version (Win32). I choose the 32-bit version because this will work for every Windows machine: the 32-bit version works on 32-bit and 64-bit machines.

Warning: don’t use version 1.1.0 or later, you’ll get this error: “problem creating object tsa_policy1=1.2.3.4.1”

If you start the installation and get the following message:

then you need to cancel the installation and install the Visual C++ 2008 Redistributables first. You can find download links on the same page. If you install Win32 OpenSSL (32-bit), install Visual C++ 2008 Redistributables, and if you install Win64 OpenSSL (64-bit), install Visual C++ 2008 Redistributables (x64).

The installation of the Redistributables is easy:

After this, you can restart the OpenSSL installation:

I will create the certificates in folder c:\demo. So go ahead and create this folder on your machine.

Then start a command-line prompt (cmd.exe), and go to the demo folder (type: cd \demo).

Before you start OpenSSL, you need to set 2 environment variables:

set RANDFILE=c:\demo\.rnd
set OPENSSL_CONF=C:\OpenSSL-Win32\bin\openssl.cfg

Now you can start OpenSSL, type: c:\OpenSSL-Win32\bin\openssl.exe:

And from here on, the commands are the same as for my “Howto: Make Your Own Cert With OpenSSL”.

First we generate a 4096-bit long RSA key for our root CA and store it in file ca.key:

genrsa -out ca.key 4096

If you want to password-protect this key, add option -des3.

Next, we create our self-signed root CA certificate ca.crt; you’ll need to provide an identity for your root CA:

req -new -x509 -days 1826 -key ca.key -out ca.crt

The -x509 option is used for a self-signed certificate. 1826 days gives us a cert valid for 5 years.

Next step: create our subordinate CA that will be used for the actual signing. First, generate the key:

genrsa -out ia.key 4096

Then, request a certificate for this subordinate CA:

req -new -key ia.key -out ia.csr

Make sure that the Common Name you enter here is different from the Common Name you entered previously for the root CA. If they are the same, you will get an error later on when creating the pkcs12 file.

Next step: process the request for the subordinate CA certificate and get it signed by the root CA.

x509 -req -days 730 -in ia.csr -CA ca.crt -CAkey ca.key -set_serial 01 -out ia.crt

The cert will be valid for 2 years (730 days) and I decided to choose my own serial number 01 for this cert (-set_serial 01). For the root CA, I let OpenSSL generate a random serial number.

That’s all there is to it! Of course, there are many options I didn’t use. Consult the OpenSSL documentation for more info. For example, I didn’t restrict my subordinate CA key usage to digital signatures. It can be used for anything, even making another subordinate CA. When you buy a code signing certificate, the CA company will limit its use to code signing. And I did not use passwords to protect my keys. In a production environment, you want to protect your keys with passwords.

To use this subordinate CA key for Authenticode signatures with Microsoft’s signtool, you’ll have to package the keys and certs in a PKCS12 file:

pkcs12 -export -out ia.p12 -inkey ia.key -in ia.crt -chain -CAfile ca.crt

If you did not provide a different Common Name for the root CA and the intermediate CA, then you’ll get this error:

Error self signed certificate getting chain.
error in pkcs12

To sign executables in Windows with the signtool: install file ia.p12 in your certificate store (e.g. double click it), and then use signtool /wizard to sign your PE file.

The certificates (.crt files) you created here can also be double-clicked in Windows to view/install them: