by Bhabesh Raj Rai, Associate Security Analyst Engineer
Recent Active Directory (AD) privilege escalation vulnerabilities allow standard domain users to impersonate domain administrators. If the attack is successful, administrators could find themselves in the undesirable position of needing to clean and rebuild their entire AD. Using LogPoint SIEM and SOAR, administrators can detect, investigate and remediate AD privilege escalations with high-fidelity detections and out-of-the-box playbooks.
On Nov. 9, 2021, Microsoft fixed a string of privilege escalation vulnerabilities in AD which when chained, allow a standard domain user to impersonate a high-privilege user, such as a domain administrator. Several proof-of-concepts (PoCs ) are publicly available which enable even a less sophisticated threat actor to easily compromise the entire domain.
CVE-2021-42278 and CVE-2021-42287 are both privilege escalation vulnerabilities in Active Directory Domain Services and have a 8.8 CVSS score. Both vulnerabilities allow an attacker to impersonate a domain controller – CVE-2021-42278 uses computer account sAMAccountName spoofing and CVE-2021-42287 uses Kerberos (Privileged Attribute Certificate) PAC confusion. Administrators should ensure that they have applied Microsoft’s KB5008102 for CVE-2021-42278 and Microsoft’s KB5008380 for CVE-2021-42287 on all their domain controllers.
Security researcher Charlie Clark has extensively covered how to weaponize these vulnerabilities. In simple terms, the attack chain starts by creating a new computer account to the AD domain followed by renaming that computer account to mirror the name of an existing domain controller but without the trailing ‘$’. Then, a Kerberos TGT request is sent using that new computer name followed by renaming the created computer account to an arbitrary value. Finally, the chain concludes by requesting a Kerberos S4U2self ticket using the retrieved TGT. If every step succeeds, then the attacker will obtain a service ticket to a domain controller. The attacker gets a ticket because when we request a S4U2self ticket using a TGT of an account that does not exist (since we renamed it), the KDC automatically searches again by adding a trailing ‘$’. PoCs in python and EXE became available after Clark’s disclosure and even script-kiddies can easily compromise the whole AD domain using the PoCs.
Administrators should note that for the attack chain to start, an unprivileged user should be able to add a computer to an existing domain. By default, AD permits standard domain users to add up to 10 computers to an AD domain through MS-DS-Machine-Account-Quota attribute. We advise administrators to change the attribute value to zero in all their domains.
LogPoint customers can use our UseCases v5.1.1 package that contains analytics for the AD privilege escalation vulnerabilities.
Detecting AD privilege escalations using LogPoint
To detect AD privilege escalations, LogPoint customers need to have AD Domain Services log sources. As described above, the attack chain consists of quite a few steps, which means several event logs will be generated as the attack progresses. Security analysts can use the generated event logs to create high-fidelity detections. We can look for new computer account creation (EID 4741) followed by renaming of that computer account (EID 4781) to a new value that does not have a trailing ‘$’.
[label=Computer label=Account label=Create] as s1
[label=Account label=Name label=Change target_user="*$" -new_user="*$"] as s2
within 5 second
| rename s1.computer as computer, s1.user as user, s2.new_user as new_computer_name
| chart count() by user, computer, new_computer_name
Searching for account creation followed by rename operation to a new value that does not have a trailing ‘$’
Next, we can look for renaming of an account to remove the trailing ‘$’ followed by a Kerberos TGT request (EID 4768) using that renamed account.
[label=Account label=Name label=Change target_user="*$" -new_user="*$"] as s1
[norm_id=WinServer event_id=4768 -user="*$"] as s2
within 5 second on s1.new_user=s2.user
| rename s1.target_user as old_computer_name, s1.new_user as
new_computer_name, s1.user as user, s2.source_address as source_address
| chart count() by user, old_computer_name, new_computer_name, source_address
Searching for account name change followed by Kerberos TGT request using renamed account
Alternatively, we can hunt for suspicious Kerberos service ticket requests (in this case S4U2self) that specifies a domain controller in both service and user fields but the latter does not include the trailing ‘$’.
norm_id=WinServer event_id=4769 service IN WINDOWS_DC
| norm on service <dc:'\S+'>$
| process compare(user, dc) as result
| search result=true
| chart count() by log_ts, user, dc, service, source_address
Searching for suspicious Kerberos service ticket requests
To find the user being impersonated in the S4U2self request, we can look for the aforementioned suspicious Kerberos service ticket request followed by a user login from the same IP address that made the suspicious service ticket request.
[norm_id=WinServer event_id=4769 service IN WINDOWS_DC
| norm on service <dc:'\S+'>$
| process compare(user, dc) as result
| search result=true] as s1 followed by
[norm_id=WinServer event_id=4624] as s2
within 5 second on s1.host=s2.host and s1.source_address=s2.source_address
| rename s1.log_ts as log_ts, s2.log_ts as login_ts, s1.host as host, s1.user as user,
s1.service as service, s1.dc as dc, s2.user as impersonated_user, s2.source_address as source_address
| chart count() by log_ts, login_ts, user, service, dc, impersonated_user, source_address
Searching for an impersonated account
The python PoC has an option to directly open a shell after successful exploitation, which we can see in the new service installation event. We can note that the service was created by the impersonated user.
label=Service label=Install path="%COMSPEC%*\\127.0.0.1\C$\*"
| chart count() by user, file, service, path
Searching for suspicious paths in new service installations
Attackers, after obtaining the service ticket of a domain controller (DC), can easily use the DCSync technique to dump that DC’s password hashes. LogPoint customers can use alerts that ship with the Alert Rules package for detecting attacks commonly used by attackers.
Searching for artifacts of a DCSync attack
Investigating post-compromise activity using LogPoint SOAR
Administrators can use LogPoint SOAR to create playbooks that perform investigations related to post-compromise activity of the attackers.
Some important steps in the investigation include checking for:
- The creation of new users for persistence.
- A trace of any SYSTEM shells on the affected domain controller.
- Suspicious service installations.
- Credential dumping by mimikatz.
- A DCSync attack.
LogPoint SOAR playbook for investigating post-compromise activity after AD privilege escalation
After executing the playbook in LogPoint SOAR, we can view the cases created by the playbook’s components in the investigation timeline to get a high-level overview of the investigation’s results.
LogPoint SOAR investigation timeline gathers the results of the investigation
Remediating AD privilege escalation
If the attackers managed to compromise the entire domain, administrators need to clean and rebuild their entire Active Directory from scratch. Doing this is a complicated and manual task and normally cannot be completely automated. To rebuild AD, administrators can implement the following remediation steps.
- Create fresh credentials for all accounts.
- Initiate procedures for resetting KRBTGT account password.
- Check for changes in group policy (GPO) and logon scripts.
- Promote fresh new servers to DCs and move the FSMO roles to it so that the old DCs can be decommissioned.
Administrators should watch out for privilege escalation vulnerabilities because ransomware actors can readily use them to minimize their ransomware deployment time. We advise defenders to test out the PoC in a lab environment that has the same configuration as their production environment. Defenders can test and tune their detections and be sure that the log source requirement of the detection is satisfied rather than blindly using the detection.