Attack on the Active Directory via Microsoft Intune - and how they can be contained with TameMyCerts

Dirk Jan Mollema recently presented an attack that can be used to obtain a certificate for highly privileged accounts via Intune. This can then be used to compress the entire Active Directory environment.

The attack is similar in its basic features to what I have already described in the article "From Zero to Enterprise Administrator through Network Device Enrollment Service (NDES) - and What to Do About It" and in the article "Attack vector on Active Directory directory service via smartcard logon mechanism" (generally also known as ESC1).

What is new, however, is to utilize the Mobile Device Management (MDM) system - in this case Microsoft Intune - accordingly.

What is not new, however, is what can be done with the TameMyCerts Policy Module for Active Directory Certificate Services to drastically reduce the attack surface.

We should also not be lulled into a false sense of security if our company uses a different MDM system. The basic attack is the same everywhere, and with most other MDM systems the certificate application process is even more insecure.

The basic problem is that they all take advantage of the fact that the certificate use case used requires the associated certificate template to be configured in such a way that any identities requested by the applicant are accepted (offline certificate template).

This configuration literally screams trouble

If an attacker is now able to send a certificate request directly or indirectly to the certification authority, he can have certificates issued for any identity - including those of privileged accounts.

TameMyCerts solves this dilemma.

What is TameMyCerts and how does it work?

TameMyCerts is a Policy moduleto secure the Microsoft certification authority (Active Directory Certificate Services). It extends the functions of the certification authority and enables the Extended application of regulationsto enable the secure automation of certificate issuance. TameMyCerts is unique in the Microsoft ecosystem and is available under a free license. It can downloaded via GitHub and can be used free of charge.

TameMyCerts gets involved in the certificate issuing process (graphic © Microsoft)

TameMyCerts is open source and can be used free of charge. For use in the corporate sector, however, we recommend the Conclusion of a maintenance contract. This ensures that you receive qualified support and that the module can be further developed to a high quality in the long term.

TameMyCerts also stands for outstanding quality. All functions are backed up with automatic tests to ensure that they work perfectly.

TameMyCerts always looks for reasons to reject a certificate request that has been approved by the Microsoft certification authority. The reverse case - that a certificate request that has already been rejected is nevertheless approved again - will never occur.

Enforce precisely defined certificate fields with precisely defined syntax

TameMyCerts allows you to precisely define the certificate content that can be requested for offline certificate templates.

It allows us to make the following restrictions.

Restrict the permitted Subject Relative Distinguished Name (RDN) and Subject Alternative Name (SAN) types.
Application of syntax rules (regular expressions, IP subnet masks) against the defined RDN and SAN types

Linking (mapping) the requested identity back to the relevant accounts

TameMyCerts can map the requested certificate content back to the relevant account. The certificate content is evaluated using defined rules and a suitable object is searched for in the Active Directory.

A rejection will then be made in the following cases:

No object matching the search criteria was found.
More than one object matching the search criteria was found.
The object found is deactivated.
The object found is not a member of defined security groups.
The object found is a member of defined prohibited security groups.
Attributes on the found object correspond to undefined syntactic criteria.

Concrete implementation of a policy configuration

TameMyCerts is comprehensively documented. The documentation can be viewed online.

In order to enable the issuance of certificates for regular Intune users in a precisely defined scope, we create certificates after the Installation of TameMyCerts the set of rules described below. We will use a configuration for user certificates. However, the basic logic is similar for device certificates.

Creating a configuration file

The first step is to create a configuration file (XML) with the same name as the certificate template in the directory created during installation.

In our example, the certificate template is called "ADCSLaborIntuneUser" and our configuration file is called "ADCSLaborIntuneUser.xml".

We then refine our set of rules until it limits the options for applying for a certificate as much as possible.

Step 1: Syntax rules

In our example, we assume that we have defined the following rules in Intune:

The requested certificate content will therefore be as follows:

The Subject Distinguished Name (DN) contains the user name (CN={{UserName}}) and the e-mail address of the user (E={{EmailAddress}}).
The Subject Alternative Name (SAN) will contain the user's principal name ({{UserPrincipalName}})

Our syntax rules are therefore as follows:

<Subject>
  <SubjectRule>
    <Field>commonName</Field>
    <Mandatory>true</Mandatory>
    <Patterns>
      <Pattern>
        <Expression>^[a-zA-Z0-9]*$</Expression>
      </Pattern>
    </Patterns>
  </SubjectRule>
  <SubjectRule>
    <Field>emailAddress</Field>
    <Mandatory>true</Mandatory>
    <Patterns>
      <Pattern>
        <Expression>^[a-zA-Z0-9]*\@intra\.adcslabor\.de$</Expression>
      </Pattern>
    </Patterns>
  </SubjectRule>
</Subject>
<SubjectAlternativeName>
  <SubjectRule>
    <Field>userPrincipalName</Field>
    <Mandatory>true</Mandatory>
    <Patterns>
      <Pattern>
        <Expression>^[a-zA-Z0-9]*\@intra\.adcslabor\.de$</Expression>
      </Pattern>
    </Patterns>
  </SubjectRule>
</SubjectAlternativeName>

Step 2: Mapping the requested certificate content to the corresponding Active Directory account

We know that our Intune users are all in a certain organizational unit. So we limit the search accordingly.

<DirectoryServicesMapping>
  <!-- ... -->
  <SearchRoot>OU=ADCS Labor Users,DC=intra,DC=adcslabor,DC=de</SearchRoot>
</DirectoryServicesMapping>

Clear mapping criteria are required to establish the connection between the requested certificate content and the Active Directory account. Since the certificate requests must meet the userPrincipalName this can be used. We would therefore like the content of the userPrincipalName SANs of the certificate request to include objects of type user with the same value in its userPrincipalName attribute.

A corresponding rule would look like this. However, as this is the default setting, it can also be omitted.

<DirectoryServicesMapping>
  <!-- ... -->
  <CertificateAttribute>userPrincipalName</CertificateAttribute>
  <DirectoryServicesAttribute>userPrincipalName</DirectoryServicesAttribute>
  <ObjectCategory>user</ObjectCategory>
</DirectoryServicesMapping>

We also know that all Intune users must be members of a certain security group in order to be issued a certificate.

<DirectoryServicesMapping>
  <!-- ... -->
  <AllowedSecurityGroups>
    <string>CN=Intune Users,OU=ADCS Labor Groups,DC=intra,DC=adcslabor,DC=de</string>
  </AllowedSecurityGroups>
<DirectoryServicesMapping>

Furthermore, we do not want members of privileged groups to receive a certificate under any circumstances.

<DirectoryServicesMapping>
  <!-- ... -->
  <DisallowedSecurityGroups>
    <string>CN=Domain Admins,CN=Users,DC=intra,DC=adcslabor,DC=de</string>
  </DisallowedSecurityGroups>
<DirectoryServicesMapping>

Optional: SID certificate extension

While we are at it, we could also enter the Security Identifier certificate extension in the issued certificate.

<SecurityIdentifierExtension>Add</SecurityIdentifierExtension>

The alternative approach of the SID Uniform Resource Identifier (URI) is also supported by TameMyCerts. And it is generally recommended that this highly sensitive information is not requested by the applicant, but instead entered into the certificate by the certification authority using TameMyCerts. This ensures that the SID associated with the linked account ends up in the certificate.

Optional: Use the Active Directory attributes of the mapped account to enhance the certificate content

The attributes that can be used are here documented.

We could also decide to change the requested certificate content. For example, we could add the company name and write the department name from the user account properties in the Subject Distinguished Name of the issued certificate.

<OutboundSubject>
  <OutboundSubjectRule>
    <Field>organizationName</Field>
    <Value>ADCS Labor</Value>
  </OutboundSubjectRule>
  <OutboundSubjectRule>
    <Field>organizationalUnitName</Field>
    <Value>{ad:department}</Value>
  </OutboundSubjectRule>
</OutboundSubject>

Summary

Further examples are included with TameMyCerts. The sample configuration files are also available on GitHub.

The complete guideline definition then looks as follows:

<CertificateRequestPolicy xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <Subject>
    <SubjectRule>
      <Field>commonName</Field>
      <Mandatory>true</Mandatory>
      <Patterns>
        <Pattern>
          <Expression>^[a-zA-Z0-9]*$</Expression>
        </Pattern>
      </Patterns>
    </SubjectRule>
    <SubjectRule>
      <Field>emailAddress</Field>
      <Mandatory>true</Mandatory>
      <Patterns>
        <Pattern>
          <Expression>^[a-zA-Z0-9]*\@intra\.adcslabor\.de$</Expression>
        </Pattern>
      </Patterns>
    </SubjectRule>
  </Subject>
  <SubjectAlternativeName>
    <SubjectRule>
      <Field>userPrincipalName</Field>
      <Mandatory>true</Mandatory>
      <Patterns>
        <Pattern>
          <Expression>^[a-zA-Z0-9]*\@intra\.adcslabor\.de$</Expression>
        </Pattern>
      </Patterns>
    </SubjectRule>
  </SubjectAlternativeName>
  <DirectoryServicesMapping>
    <SearchRoot>OU=ADCS Labor Users,DC=intra,DC=adcslabor,DC=de</SearchRoot>
    <AllowedSecurityGroups>
      <string>CN=Intune Users,OU=ADCS Labor Groups,DC=intra,DC=adcslabor,DC=de</string>
    </AllowedSecurityGroups>
    <DisallowedSecurityGroups>
      <string>CN=Domain Admins,CN=Users,DC=intra,DC=adcslabor,DC=de</string>
    </DisallowedSecurityGroups>
  </DirectoryServicesMapping>
  <OutboundSubject>
    <OutboundSubjectRule>
      <Field>organizationName</Field>
      <Value>ADCS Labor</Value>
    </OutboundSubjectRule>
    <OutboundSubjectRule>
      <Field>organizationalUnitName</Field>
      <Value>{ad:department}</Value>
    </OutboundSubjectRule>
  </OutboundSubject>
  <SecurityIdentifierExtension>Add</SecurityIdentifierExtension>
</CertificateRequestPolicy>

Logging and alerting

The events logged by TameMyCerts are here documented.

If the certification authority rejects a certificate request through TameMyCerts, this event is logged on the certification authority and a corresponding alert can be triggered.

Function test

For testing I use the PSCertificateEnrollment PowerShell module. The type of certificate request - i.e. whether via MS-WCCE, via SCEP, and with or without Mobile Device Management - is irrelevant for the test, as the certificate request is checked directly at the certification authority and is therefore independent of the type of request.

Case 1: Violation of defined certificate content

For the first test, we apply for a certificate, which is only a commonName includes.

New-CertificateRequest -Subject "CN=rudi" |
Get-IssuedCertificate -ConfigString "CA02.intra.adcslabor.de\ADCS Labor Issuing CA 1" -CertificateTemplate "ADCSLaborIntuneUser"

However, as we remember, our syntax rules require that a emailAddress and a userPrincipalName are included. The certificate request is rejected accordingly and an event is logged.

Case 2: Syntax rules prevent exhibition

For the second test, we request all defined fields, but create an error in the userPrincipalName in.

New-CertificateRequest `
  -Subject "CN=rudi,E=rudi@intra.adcslabor.de"  `
  -Upn "rudi@adcslabor.de" | 
Get-IssuedCertificate -ConfigString "CA02.intra.adcslabor.de\ADCS Labor Issuing CA 1" -CertificateTemplate "ADCSLaborIntuneUser"

The certificate request is rejected accordingly.

Case 3: Mapping of the requested object fails

For the next test, we request a userPrincipalName that is not known in the domain.

New-CertificateRequest `
  -Subject "CN=rudi,E=rudi@intra.adcslabor.de" `
  -Upn "rudy@intra.adcslabor.de" |
Get-IssuedCertificate -ConfigString "CA02.intra.adcslabor.de\ADCS Labor Issuing CA 1" -CertificateTemplate "ADCSLaborIntuneUser"

The certificate request is rejected accordingly.

We are correcting our error, but the user we are looking for is not in the defined organizational unit.

New-CertificateRequest -Subject "CN=rudi,E=rudi@intra.adcslabor.de" -Upn "rudi@intra.adcslabor.de" | Get-IssuedCertificate -ConfigString "CA02.intra.adcslabor.de\ADCS Labor Issuing CA 1" -CertificateTemplate "ADCSLaborIntuneUser"

Our certificate request is rejected accordingly.

Case 4: Group memberships for the requested object fail

Now that we have moved our test user Rudi to the correct organizational unit, let's try our luck again.

New-CertificateRequest `
  -Subject "CN=rudi,E=rudi@intra.adcslabor.de" `
  -Upn "rudi@intra.adcslabor.de" | 
Get-IssuedCertificate -ConfigString "CA02.intra.adcslabor.de\ADCS Labor Issuing CA 1" -CertificateTemplate "ADCSLaborIntuneUser"

However, the user is not a member of one of the defined groups - accordingly, the certificate request is rejected again.

Okay, let's add Rudi to the defined "Intune Users" and try again.

However, since the user is a member of the forbidden group of domain administrators, we fail again.

Case 5: Successful exhibition

When our user Rudi finally fulfills all the requirements, we will finally receive our certificate.

In the subject Distinguished Name we see that the "department" attribute from the connected Active Directory account was transferred to the organizationalUnit field of the certificate. The company name was also transferred to the organizationName field of the certificate.

The Security Identifier certificate extension can also be found in the issued certificate.

Conclusion

Trust is good, control is better. TameMyCerts allows PKI administrators to regain control over their issued certificates and significantly increase the security level of the PKI.

But wait... there's more

TameMyCerts can do much more, and can offer significant added value for a variety of use cases. Here is an excerpt of these...