Most companies freely acknowledge that a data breach event would cause significant impact to their business. If a company processes, stores and accesses sensitive customer information (i.e. medical records, credit cards, social security numbers, etc.), it would also acknowledge that it already knows what types of data the criminals mostly like want to steal … or hold hostage.

All this knowledge is extremely helpful, and it’s a great starting point for any organization. Unfortunately, that knowledge is not enough. Many of these same companies are lacking critical visibility and insight to exactly how criminals might exploit their people, processes, or technologies to gain unauthorized access to the sensitive information that they’ve been entrusted to protect. As a result, their cybersecurity dollars are often misspent on fancy boxes that aren’t doing much to improve the company’s overall cybersecurity resilience.

For this blog post, I am going to talk about one way to gain insight by understanding how a hacker might exploit passwords.  In large enterprises especially, Domain Administrator-level access rarely provides direct access to the sensitive customer data that criminals are trying to steal. In most instances, the most sensitive information is often most easily accessed from a third-party application that is installed on employee workstations. Because security engagements are usually time-constrained, we often find ourselves trying to gain access to as many employee accounts as quickly possible. This is where password cracking comes into play.

Hashes

In a Microsoft Windows environment, there are primarily two types of hashes that we try to obtain for the purposes of cracking user passwords and gaining access to their individual systems. The first type of hash is referred to as a NetNTLM hash. NetNTLM is a challenge/response-based authentication protocol and works in the following manner:

 A user accesses a client computer and provides a domain name, username, and password. The client computes a cryptographic hash of the password and discards the actual password 

1. The client sends the username to the server (in plaintext). 
2. The server generates a 16-byte random number, called a challenge or nonce, and sends it to the client. 
3. The client encrypts this challenge with the hash of the user's password and returns the result to the server. This is called the response. 
4. The server sends the following three items to the domain controller:
1. Username 
2. Challenge sent to the client 
3. Response received from the client 
5. The domain controller uses the username to retrieve the hash of the user's password from the Security Account Manager database. It uses this password hash to encrypt the challenge. 
6. The domain controller compares the encrypted challenge it computed (in step 6) to the response computed by the client (in step 4). If they are identical, authentication is considered successful and the domain controller notifies the server.

NetNTLM hashes are often able to be captured on a network using a variety of methods/tools and are able to be cracked if the password is not strong. Depicted below is a NetNTLMv2 hash that was captured using a tool called Responder.

The second type of hashes are known as NT Hashes. These hashes are stored in the NTDS database on an organization’s domain controller and includes critical information about domain users, groups, and group membership. It also includes the password hashes for all users in the domain. These hashes are protected from access by an encrypted key that is stored in the SYSTEM registry hive. 

For the sake of this article, we’re going to focus on NT Hashes – just to keep things simple. Once we have obtained Domain Administrator-level access during an engagement, we typically proceed with extracting all of the Active Directory account hashes from the NTDS database on a domain controller. There are a number of ways to achieve this, and one method is to use the Windows utility “ntdsutil” (see below). After we have extracted the database from the system, there are still a number of steps to convert the database into a usable format for hash cracking. This is outside of the scope of this article.

With our acquired list of hashes, the next step is to attempt to crack them. Similar to the above statement, there are a number of tools that one can utilize for cracking hashes. In the examples below, we’re going to be using a free password tool called Hashcat.

Cracking NT Hashes

For the remainder of this article, I want to step you through my approach and methodology for cracking NT hashes. This is not intended to be a step-by-step walk through for how to crack hashes with Hashcat – but rather to provide insights into my approach for cracking passwords during an engagement.

Before we start cracking our hashes with Hashcat, let’s explore what our hashes look like in plaintext format.

With Hashcat, there are a few different “modes of operation” that are available for use. There is no “right” or “wrong” option here because password cracking is a bit of a science as much as it is an art. The most important thing is to understand each mode and how to apply it to your situation.

For example, if I’m working with a company in the healthcare space, it’s highly probable that a number of employees are using the word “healthcare” or “health” in their password. To test this theory, I que up the following command:

The above command takes the word “Healthcare” and appends every possible 4-digit combination to it. It starts with 0000 and ends with 9999. Every time Hashcat does this, it generates a NT Hash in the same format as we saw stored in the above NTDS.dit database file. Hashcat compares every generated hash against the list that we extracted (above) and looks for any matches. This is called a Mask Attack.

In less than 1 second, Hashcat was able to iterate through every possible combination and cracked two hashes – providing us with the plaintext password for 2 Active Directory accounts. It should be noted that these are 14-character passwords, too. Many employees, incorrectly, assume such a password to be secure based on its length.

Another approach that has proven quite effective involves compiling a list of words that might be specific to the organization. For example, I would typically consider the industry, all street addresses for all physical locations, company name, etc. All of these get added into a file, as depicted below.

Our syntax has been altered slightly and our new command will use the words contained in the file above and append every possible numeral, uppercase/lowercase combination, and special character…all while trying every possible iteration between character sets 1 – 5 (?a?a?a?a?a). This attack is a bit more complicated and will take longer to process than the first one. It is known as a Hybrid Wordlist + Masking Attack. 

As hashes are cracked, we can observe that the cracked hashes vary in length, complexity and also have special characters.

We can also observe longer passwords being cracked as well – highlighting the value of the increment switch.

Wordlist attack

The next attack mode that we’ll look at within this post is the classic (and very effective) dictionary or “wordlist” attack. With this type of attack, we provide Hashcat with a massive list of possible passwords and Hashcat will “hash” each password in that list and then compare to the hash from our provided NTDS.dit file. If Haschat finds a match, the password is considered cracked. With this of type of attack, the most important factor is having a wordlist that contains a significant number of commonly used passwords. A very popular password list is crackstation.txt – which I’m using in the below example.

The command to perform this type of attack is seen below:

Using crackstation.txt as our wordlist we are able to crack a large number of passwords in a matter of seconds.

Wordlists & Rules Attack

The last type of attack that we’ll cover in this post involves combing wordlists (as seen above) and “rules”. This type of attack mode is very powerful with lots of possibilities for use. In order to simplify the explanation of this mode, we can consider this example. Let’s say our wordlist contains the string of “password”. We can use a rule to replace every instance of the letter “a” with a “@” sign. We can also replace every “o” with the a “0”. As an example, I have a built out a “leet speak” rule, which is seen below:

With our new (albeit simple) rule compiled, we can now combine our rule with our custom wordlist to see if any users are using any “leet speak” type passwords. We have added a few new words to our common.txt wordlist such as “Tennessee” and “Password”. As seen below, multiple users have selected passwords that meet the criteria within the rule.

We regularly perform security testing for companies that have made significant investments into a wide variety of cybersecurity solutions. However, a common denominator across many of these companies (whether large or small) is that employees are selecting incredibly weak passwords that are easily cracked… and these cracked passwords often provide us with easy access to sensitive information. From my perspective as an ethical hacker, I think there are three big contributing factors to this issue:

1. Employees have not been provided with a company sanctioned password management solution and are expected to keep track of hundreds of passwords to perform their job. As a result, they choose easy to remember passwords that follow some sort of pattern (i.e. Spring2018, Summer2018, Winter2018, etc.). Unfortunately, many of these types of passwords meet password complexity requirements – but they are not suitable passwords and should not be used.
2. Many companies have not provided their employees with guidance on what constitutes a secure password or how to construct a secure password.
3. Many companies still require employees to change their passwords every 30-90 days – which is no longer considered a best practice. Frequent password changes invite users to select passwords based around some pattern.

In closing, companies need to understand how criminal hackers operate and adjust their defensive plans accordingly. Yes, we need to check the cybersecurity boxes and other comprehensive technical solutions; however, we cannot afford to neglect the basics either. In many cases, significant security improvements can be made for very little cost. Regular user accounts are a huge target and a single compromised account can result of thousands of customer records being compromised.

As it relates to passwords specifically, organizations should consider the following tips:

1. Don’t rely on passwords alone and enable multifactor authentication wherever possible.
2. Abandon traditional passwords in exchange for random phrases (i.e.: “running ninja guitar sidewalk chair”)
3. Avoiding reusing and sharing passwords
4. Provide employees with a password manager to store passwords and other company secrets
5. Stop requiring employees to frequently change passwords
6. Provide regular training and guidance to employees around selecting secure passwords
7. Perform regular password audits to validate compliance with password policies
8. Implement measures that actively prevent employees from selecting weak passwords
9. Ensure systems that store password hashes are properly hardened.
10. Never type a password on a system that you do not trust

Up Next: