Threat HUNTing Platform
Credential Risk Assessment and Remediation
ORKOS: Preventing the 9 steps to domain collapse
R9B understands the cognitive aspects of cyber operations. Our curriculum provides the hands-on technical skills students require to attain a variety of advanced cybersecurity qualifications. We instill the knowledge, skills, and abilities necessary for our students to defeat the adversary. Below are our available courses. Please check back often as our course offerings are updated regularly. Government organizations, please contact R9B directly via training@root9B.com for pricing and purchasing information.
On a Windows domain, users authenticate to resources like file shares using the Kerberos protocol by default. Older
versions of Windows defaulted to the NTLM protocol, which is still enabled on newer systems (in the updated NTLMv2
form), but only used by default when accessing a non-domain resource, or accessing a server by IP address instead of
The NTLM protocol uses a challenge-response handshake based on the hash of the user’s password to authenticate the
user. For example, suppose the administrator Alice needs to see the files on a web server named WEBSERVER1 in a Windows
domain. Since the hash of Alice’s password is only available on a domain controller or Alice’s system, when she
accesses WEBSERVER1, WEBSERVER1 must pass through the challenge and response to a domain controller to authenticate
NTLM Pass-Through Authentication. Source: Microsoft
Kerberos is based on the domain controller granting tickets to named resources. When logging in, Alice obtains a
Ticket-Granting-Ticket (TGT) from a DC which Alice then presents back to a DC whenever necessary to obtain service
tickets to access remote servers, such as WEBSERVER1. This ticket will then be authenticated by WEBSERVER1’s secret
hash, which is known only by the DC and WEBSERVER1, and contain all the information necessary to authenticate Alice to
WEBSERVER1. Now WEBSERVER1 no longer needs to talk to a DC for each authentication, since Alice’s computer already did,
and the DC only needs to validate the user’s password once. This elimination of challenge-response helps Kerberos
improve speed, one of its main advantages.
Kerberos Authentication. Source: Microsoft
Critically for security, this process introduces another advantage; WEBSERVER1 no longer observes a challenge-response
based on Alice’s password. If Henry the hacker has managed to compromise WEBSERVER1, as frequently happens to
internet-facing web servers, Henry will want Alice’s password to take over the rest of the network, but he won’t see
any indication of it by passively listening, even if Alice remotely authenticates to and manages WEBSERVER1.
Henry could try to guess Alice’s password on the live network, but after a few tries, he will lock out Alice’s account,
preventing him from guessing further and alerting Alice that something is wrong. On the other hand, if Alice’s computer
used NTLM to authenticate to WEBSERVER1, Henry would be able to copy the challenge-response back to his own computer
and crack it offline. NTLMv1 and earlier can be considered completely broken, and as a result are now disabled by
default, but NTLMv2 can still be brute-forced offline. A decent computer can try 1 billion passwords per second against
an NTLMv2 challenge-response and has a good chance at cracking the password quickly, even if it was a complex password.
Since this happens offline, no alerts will be triggered and Alice’s account will not be locked out. In contrast, if
Alice’s computer uses Kerberos, Henry no longer sees any network traffic based on Alice’s password and so cannot launch
an offline brute-force attack.
The good news for Henry is that as long as NTLMv2 is enabled on Alice’s computer (and it is enabled by default), he may
be able to get Alice to downgrade from Kerberos. While proper downgrade techniques from a higher version of NTLM/LM to
a lower version have been published and implemented before (but are now generally blocked by NTLMv2 minimum version policies), we’re
unaware of any transparent downgrade attacks from Kerberos to NTLM, since it was designed to prevent that. However,
Henry can still achieve a downgrade with the following methods if some additional requirements can be met:
But if Alice puts in her username and password, her computer will still send the NTLMv2 challenge-response to
WEBSERVER1 for Henry to attempt to crack.
As this error is a very common error that can come up due to any of a number of network issues (e.g. DNS), in
our experience, administrators will attempt to retry using the system’s IP address. In this case, NTLMv2 will
once again be used and can be cracked offline.
The most effective remediation against this attack is to disable the use of all NTLM protocols, using group policies
first implemented in Windows Server 2008r2. By blocking outbound NTLM requests from domain systems, clients will no
longer send out NTLM authentication to any servers that have not been specifically exempted.
Another effective method for remediation of this attack is to enforce the use of smart cards. When an account is set to
require smart card authentication, the NTLM hash will be randomized into 128 random bits, which is well beyond the
reach of bruteforce cracking. Smart cards have many other benefits, but do entail additional costs and logistics issues
as well. However, using smart cards will not stop the related NTLM relay attack which is beyond the scope of this blog post. Disabling NTLM either client-side
or server-side or domain-wide is required to prevent the NTLM relay attack.
The following procedures will show how to extract an NTLMv2 challenge/response from a standard pcap packet capture and
crack them with oclHashcat
It will be displayed as: “NTLM Server Challenge: <16 hex digits>” (in our case, “NTLM Server Challenge:
It will be displayed as: “NTProofStr: <32 hex digits>” (in our case, “NTProofStr:
It will copy out as a long hex string of variable length. It may be shorter or longer than this example:
BACK TO NEWSROOM