Microsoft Defender for Identity now detects suspicious certificate usage

Identity protection has become one of the cornerstones of modern security practices but the way we work and interact with the technology around us has evolved, giving cybercriminals new avenues to exploit. One technique that has grown in popularity over the past few years targets the Active Directory Certificate Services to bypass the protections in place around your Active Directory and gain access to your domain.

As biometrics, smartcards, and other forms of authentication become more and more commonplace almost every modern organization has been forced to implement some kind of public key infrastructure (PKI) to issue and manage certificates which serve (among other usages) as password-equivalents. In Active Directory environments, the common Certificate Authority server (the core of the public key infrastructure) is a member server with the Active Directory Certificate Services (AD CS) role installed. Because of this, AD CS servers should be treated with the same caution and security measures as other Identity Providers (Domain Controllers, AD FS servers) and other tier-0 assets.

As our goal at Microsoft Defender for Identity (MDI) is to provide our customers with complete coverage and protection for Identity threats, it includes covering attack techniques involving the less traditional identity providers, including the relatively new threats emerging on AD CS. As for today, Microsoft Defender for Identity already covers several abuses for AD CS and the “Suspicious certificate usage over Kerberos protocol” introduced in this blog post expands this coverage.

Real World Example

To demonstrate these new capabilities we will examine this real-life example where MDI has detected suspicious activity and revealed adversarial activity that allowed the attacker to gain full domain dominance.

We start with an MDI alert of “Suspicious certificate usage over Kerberos protocol (PKINIT)” which was fired by the user “ABC_svc”. From the alert we can learn that this user was marked as a sensitive user by MDI. We can also note from the alert details that the certificate which was used for authentication had been issued shortly before the alert was triggered – making this event even more suspicious.

To put together the full attack story, we will track the activity preceding the alert, trying to identify reconnaissance activity, privilege escalation, and post-exploitation – together composing the attack flow that occurred on the victim machine which triggered this alert.

Reconnaissance

We see in the preceding hour of the alert some basic recon commands (which are very unlikely to be executed by a regular user), when two things catch our eyes. We can see that the attacker enumerated a particularly sensitive group, likely looking for a target user to compromise. In the image below we can see the account that triggered the original alert, ABC_svc, was specifically queried.

We also see that Certify – an open-source attack tool used for certificate reconnaissance and manipulation - was used, confirming this is a True-Positive (TP).

From the image above we can tell the attacker performed certificate template reconnaissance, looking for misconfigured certificate templates. Vulnerable templates that can be identified are very lucrative attack vectors, as they often enable an attacker to perform privilege escalation from unprivileged user to domain admins permissions.

Utilization of Attack Tools

With an understanding of the main tools used on the compromised machine prior to the alert, we can track the attackers' activity and understand the scope of the breach. In the image below we can see some of the more interesting activity- commands showing abuse of certificates and an attempt to harvest locally cached credentials using lsass.exe.

We can tell these efforts likely bore fruit because immediately following the certificate template reconnaissance the attacker issued a certificate from the Certificate Authority server and attempted to use it. This process repeats itself 3 times each targeting a different certificate template. The first two attempts seem to have failed and the third triggered the alert and our investigation.

From the syntax above we can see the Rubeus attack tool was utilized for authenticating using the certificate, and we note that the certify request command provided the /altname parameter was in fact our compromised user from the alert. With that understanding, we can surmise that this was probably a case of ESC1 - privilege escalation technique. ESC1 is an escalation technique in which an attacker leverages misconfigured templates that has “Client Authentication” EKU which makes the certificate valid for carrying Kerberos PKINIT authentication, unrestrictive enrollment permissions and most importantly – it has the CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT flag on. All those together enable unprivileged users to issue certificate while supplying subjectAltName. This ultimately results in a certificate that is valid for authenticating as the (arbitrary) user supplied in the subjectAltName – ABC_svc in our case.

After obtaining a certificate valid for a highly privileged user and authenticating with it, the attacker uses the ticket he retrieved and makes his way to full domain compromise.

Suspicious certificate usage over Kerberos protocol (PKINIT)

The majority of the AD CS abuse techniques (including the example above) involve suspicious usage of a certificate in some phase of the attack. From now on, when a suspicious certificate authentication occurs against a Domain Controller with an installed MDI sensor, the following alert will be shown in the M365D portal:

This alert indicates that a possible compromise occurred to the user\computer that was used in this activity. We would recommend investigating this issue as followed:

• Using the following Advanced Hunting query, you can trace which services were requested by the compromised user and track the malicious activity across the organization.
  

• Investigate the source computer that initiated the Kerberos activity and search for malicious tools or suspicious connections.
  
• Check if the compromised user was logged on to the source computer when the attack occurred. If not, it increases the chances that this logon was not a legitimate one.
  
• If the user is indeed compromised, the compromised certificate can be revoked using Active Directory Certificate Services, thus making it invalid from now on. The certificate can be located using the Thumbprint in the alert evidence.
  

Security advisories for AD CS

As stated above, Active Directory Certificate Services play an important role in the environment they are deployed but it also has many various potential abuses and misconfigurations that need to be secured immediately.

To Prevent this kind of compromise in the first place, we will recommend implementing some security guidelines and hardenings.

• Treat your AD CS servers as tier-0 assets. They are as important as Domain Controllers.
  
• Harden your AD CS servers against ESC8 technique, according to this advisory.
  
• Reduce attack surface. If possible, disable unused certificate templates and enrollment permissions.
  
• Monitor certificate enrollments in your organization, to have further visibility on AD CS operations.
  

Wrapping up

In the above example, we have demonstrated a real-life example of an adversary activity, in all its phases - from reconnaissance to gaining domain dominance. Our new security alert detected one of the phases of the malicious activity, providing essential information regarding the scope of the attack. It is also important to mention that most of the malicious activity described above can be easily detected by an EDR, but while all these techniques are detected on the endpoint side, an MDI alert was triggered using the MDI sensor installed on the Domain Controllers across the organization. That means that if the same attack occurs from an unmanaged machine, the MDI sensor will still detect the suspicious activity successfully.

Additional resources

We're always keen on hearing your feedback, so please let us know in the comments section below if you have questions or insights about this detection or capabilities you would like Microsoft Defender for Identity to have.

Also, be sure to check out:

• Start a  free trial of Microsoft Defender for Identity.
  
• Check out our response to recent threats
  
  • Protect against hybrid identity attacks (microsoft.com)
    
  • How Microsoft Defender for Identity protects against DFSCoerce
    
  • Detecting and preventing privilege escalation attacks leveraging Kerberos relaying
    

  [*]Learn how to respond to on-premises identity compromise with Defender for Identity.

Continue reading...