Using Deception Against Pass-the-Hash Attacks

Pass the Hash Attack
Share on linkedin
Share on facebook
Share on twitter
Share on reddit
Share on email
Share on print

Pass-the-Hash Attacks: Logins Without Passwords

Using deception in cyber defense is an established concept. Here, we will discuss how deception can be used to subtly guide even experienced attackers to honey pots and honey nets. 

The pass-the-hash attack is based on what seems like a great idea for remote access to machines: Don’t send or store passwords in cleartext.

In order to protect user passwords from disclosure, only the hash of the password is sent over the network or stored on a computer. In order to authenticate to a computer, a user provides a password hashed identically to when the account was created (same hash algorithm and salt), and the hashes are compared. Since it is (statistically) impossible for two passwords to produce identical hashes, if a user provides a password that hashes to an identical value to the stored hash, it’s assumed the password is correct and login is successful.

While this does a great job of protecting the password from exposure, in many cases the hash essentially replaces the password in usefulness to an attacker.

If the attacker can steal a password hash, they can provide it to a computer when it’s expecting a hash (either on the network or after the computer expects a cleartext password to be hashed) and gain the same access to the computer as if they had the password.

One way to use hashes on Windows is by providing fake NTLM (NT LAN Manager) challenge-response packets. When a user wants to authenticate to a server using a domain controller, the server sends a random 16-byte challenge to the client and expects the encryption of the challenge with the NLTM hash of the user’s password as a response.

The username, challenge, and response are sent to the domain controller who confirms that the hash of the user’s password decrypts the response to the original challenge. The expected functionality is for the user to provide the password, for it to be hashed and then used as the encryption key.

Instead, an attacker can use a stolen hash to encrypt the challenge and successfully authenticate to the server via the domain controller.

Stealing Password Hashes

There are multiple methods by which an attacker can learn password hashes to use in a pass-the-hash attack. A couple of common ones involve stealing the Windows SAM file and dumping memory from the lsass.exe process on Windows.

Windows Security Accounts Manager (SAM) database is where password hashes are stored for local and remote users on the system. While the Windows kernel does not allow any other program to read the SAM file while it is running, it is possible to dump a copy of the SAM file out of memory if an attacker gains administrator access to a computer.

The Local Security Authority Subsystem Service (lsass.exe) enforces the security policy of the Windows operating system. Its duties include logging users into a system, managing password changes, and creating tokens to grant access to various resources. To do this, it needs access to password hashes. This means these hashes are stored somewhere in the process’s memory.

A common method of stealing these hashes is to perform a DLL injection on the lsass.exe process. This involves instructing lsass.exe to load and execute a malicious DLL (an executable that provides library functions to another executable). The malicious DLL searches the memory of lsass.exe for password hashes and exfiltrates them for use by the attacker.

Imaginary Users: Using Deception to Defeat Pass-the-Hash

Networks using Windows domain controllers trade a little bit of security in exchange for a lot of convenience. By allowing users to have a single identity (username/password) to access all computers within a domain, efficiency is increased; however, it does make a network vulnerable to attacks like pass-the hash.

Attackers exploit Windows domains by stealing a username and the associated hash from one computer and using it to gain access to others within the network using a pass-the-hash attack.

Attackers trust the credentials that they steal and use in pass-the-hash attacks. Creation of these hashes is part of “business as usual” in a Windows domain, so there is no reason for an attacker to think that a stolen hash would lead them anywhere but where they wanted to go.

Exploiting this trust is a perfect application of deception and a way to subtly guide attackers to where a defender wants them to go (i.e. honeypots and honeynets designed to distract attackers and observe their tools and techniques to better defend the true network).

Defenders can take advantage of pass-the-hash attacks by planting fake password hashes on computers that have a high probability of being attacked (anything providing public-facing services). These credentials will be designed to point attackers to honeypots and honeynets (i.e. by being a “valid” username/password on the deceptive server). Since this is exactly what an attacker is looking for when attempting a pass-the-hash attack, they should happily follow these links to the deceptive server and away from the protected company network.

By monitoring Windows system logs, Avertium’s TruSOC Managed Security Service can detect pass-the-hash attacks. As a top managed security service provider, Avertium partners with you to provide expert turnkey 24x7x365 data protection from our dual SOC 2 certified security operations centers to ease the burden of monitoring and detecting ever-changing threats.

Reach out to start the conversation.

Share this:
Share on linkedin
Share on twitter
Share on facebook
Share on reddit
Share on email
Share on print

Sign-up for Weekly Updates

We use cookies to personalize your experience. By using our website, you agree to our Privacy Policy.