Active Directory Certificate Services (ADCS) is used to manage certificates for systems, users, applications, and more in an enterprise environment. Misconfigurations in ADCS can introduce critical vulnerabilities into an enterprise Active Directory environment. A few escalation techniques are covered in ESC1, ESC2&3, ESC4, ESC8. Each of those blogs include some of the security event IDs that could be used to detect these attacks. In this blog post, we are going to walk through how to detect some of these attacks in detail.
Well, first things first, to create an alert for malicious activity, we need to ensure that we are logging ADCS events. By default, ADCS auditing is not enabled. The CA’s auditing properties can be viewed via the certsrv utility, Right Click CA > Properties > Auditing. As shown in the screenshot below, the default settings are set to not log any events.
Let’s fix that. We can enable auditing by selecting each event as shown in the figure below.
In this blog, I demonstrated a privilege escalation technique known as ESC1 that allows a low privileged account to escalate to a privileged account (domain admin). I also mentioned the following security event IDs.
In the previous section, we enabled auditing for the ADCS service, and now we will see what this looks like in Microsoft Sentinel. Sentinel uses the Kusto Query Language (KQL). We are going to run the following basic query to identify the privilege escalation activity.
SecurityEvent
| where EventID == 4886 or EventID == 4887Upon further investigation of the results, we can see that the “Requester” and the “UPN” (subject of the certificate) do not match.
Now that we’ve confirmed that we have appropriate logging in place and we defined a query to identify this attack, let’s save this query to Sentinel.
Next, let’s create an alert based on the query we defined. Click “New Alert Rule” then “Create Microsoft Sentinel Alert” to create a new rule based on this query.
Define the name, description, and severity. You can also set the MITRE technique. For this example, I am just modifying the name and description. I left the other values set to their defaults.
Configure the rule logic, such as how often the rule will be executed and from how far back in time it should check. I set this to run every 5 minutes and look at the data from the past five minutes for this example.
Review the rule configuration and click “save” to complete the rule creation.
Now that we have configured the alert, we can exploit a vulnerable certificate template using the low privileged user noprivuserADCS to request a certificate for the domain admin the domain admin doadmin.
certipy req -target-ip 192.168.2.4 \
-u [email protected] \
-p 'REDACTED' \
-ca doazlab-DC01-CA \
-template DOAZLab_User \
-dc-ip 192.168.2.4 -upn [email protected] \
-sid $DOADMINSID
If you navigate to the Sentinel resource in Azure, you will see the graph that represents the alerts triggered.
As shown in the figure below, the ADCS ESC1 alert we configured earlier was triggered.
Microsoft recently released a patch to attempt to prevent a low privilege user from requesting a certificate for a privileged account. If a certificate is requested and the SID of the requestor does not match the SID of the subject, an error occurs with Event ID 39 or 41. The windows event is shown below.
An alert can be configured in Sentinel to detect this event as well.
Now that you’ve enabled auditing and learned how to create an alert in Sentinel, you can create alerts based on the other ADCS escalation techniques. Here are a couple of additional event IDs to consider generating alerts for:
Ready to learn more?
Level up your skills with affordable classes from Antisyphon!
Available live/virtual and on-demand
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。