Password Spraying

 •  Overview - A perpetrator attempts to authenticate to one or more domain accounts with one or more passwords, usually/often utilizing the use of password lists, until he/she is able to successfully authenticate to a domain account.

 •  Minimum Requirement - None. The perpetrator merely requires network access to a DC to attempt password spraying.

 •  Mitigation - i) Enforce domain account lockout policies to prevent unhindered password spraying attempts  ii) Require the use of strong (> 30 characters) and unique passwords on all domain accounts.  iii) Ideally, disable NTLM and use MFA

     ❗ Important - By design, the default Administrator account in Active Directory cannot be locked out. Use an extremely strong password for this account, enable auditing on it, and ensure that every authentication attempt to this account is monitored. Ideally, use MFA for this account and for all such accounts.

DCSync

 •  Overview - A perpetrator requests replication from a DC, and if the perpetrator has sufficient access, the DC fulfills the request, also sending over secrets (encrypted credentials of all requested accounts), which the perpetrator can then crack.

     ❗ Consequence - Once a perpetrator is able to obtain and crack the credentials of either the krbtgt account, or that of any DC (or SAW), or that of any user with privileged access in Active Directory, he/she can proceed to gain complete C2 (command and control) over the entire forest in almost no time.

 •  Minimum Requirement - Anyone with both, sufficient Get Replication Changes Active Directory Effective Permissions and Get Replication Changes All Active Directory Effective Permissions in the ACL of the domain root can perform DCSync.

 •  Mitigation - Ensure that no one, other than Domain Controllers, has the Extended Right - Get Replication Changes All Active Directory Effective Permissions on the domain root object.

SID History

 •  Overview - A perpetrator attempts to add the SID of a specific user/group (e.g. a privileged user/group) to the SID-History attribute of a domain account, and if the request succeeds, the added SID will be included in that account's Kerberos PAC.

 •  Minimum Requirement - To add a SID to the SID-History attribute on a domain account, a user either has to be a member of the Domain Admins group or have sufficient Extended Right - Migrate-SID-History Active Directory Effective Permissions

 •  Mitigation - i) Ensure that no one has sufficient access to modify the SID-History attribute, i.e. ensure that no one has Extended Right - Migrate-SID-History Active Directory Effective Permissions on the domain root object in an Active Directory domain. ii) Additionally, since SID History is primarily a (legacy) feature provided to enable domain migration, in most environments, there should be no need for it, so ensure that there are no accounts that have a value specified for this attribute.

Credential Extraction from ntds.dit

 •  Background - The four key service components of Active Directory include the Directory System Agent, the Database Layer, the Extensible Storage Engine and the Data Store. The Data Store is comprised of the file NTDS.dit (New Technology Directory Services Information Tree), which contains the entire contents of the Active Directory, including the password hashes of all accounts in the domain, which are encrypted. This file is ordinarily manipulated only by the ESE, and can be administered by the ntdsutil utility. During normal operations, Active Directory maintains a lock on this file, preventing it from being copied using standard file copy techniques. However, certain native tools (e.g. ntdsutil) can be used to copy the file. If a perpetrator is able to obtain a copy of this file and also obtain a copy of the SYSTEM registry hive of the same DC, with sufficient expertise (or automated malicious tooling), they may be able to decrypt the credentials of all accounts in the domain.

 •  Overview - A perpetrator attempts to exfiltrate the ntds.dit file and the SYSTEM registry hive from a DC, and if he/she is successfully able to do so, he/she could subsequently obtain the credentials of all accounts in an Active Directory domain.

 •  Minimum Requirement - To obtain a copy of the ntds.dit file and the SYSTEM registry hive from a DC, a user needs to be able to logon to a DC (and know how to bypass standard locking mechansims,) or obtain access to a valid AD backup.

 •  Mitigation - Ensure that perpetrators cannot obtain administrative access on to any DC, or compromise any DC, or extract the NTDS.dit file from any DS, or obtain access to any Active Directory backup.

Skeleton Key

 •  Overview - A perpetrator attempts to authenticate to a compromised DC, in the security context of any account from that domain, with a specific password (i.e. the Skeleton Key), and the compromised DC successfully authenticates the request.

 •  Minimum Requirement - A DC against which such an authentication request is targeted, needs to have already been compromised first i.e. the perpetrator has already been able to gain administrative access on to that DC and install malicious code running in Kernel mode, that injects itself into the LSASS process and modifies the authentication process such that all authentication requests made with the correct password, or failing that, with a specific password (the Skeleton key) are granted.

 •  Mitigation - Ensure that perpetrators cannot obtain administrative access on to any DC, or compromise any DC, or have any untrustworthy code (e.g. a Kernel-mode driver) installed on any DC, by themselves or by someone authorized to do so.

     ❗ Important - It is imperative and paramount to understand that in order to be able to enact this attack vector, a perpetrator needs to have already compromised a DC, i.e. the forest has already been completely compromised.

AS-REP Roasting

 •  Overview - A perpetrator requests a TGT for a target account from the KDC (running on a DC). The KDC issues a TGT that is encrypted with the target account's password hash, which the perpetrator cracks to determine the account's password.

 •  Minimum Requirement - The KDC will only issue a TGT to the perpetrator for those domain accounts on which the Do not require Kerberos Pre-authentication setting is enabled. This setting is disabled by default on all domain accounts.

     ❗ Corollary - Anyone who has sufficient Write Property - userAccountControl Active Directory Effective Permissions on a domain account can enable the Do not require Kerberos Pre-authentication setting on that domain account, and subsequently attempt this attack on that domain account.

 •  Mitigation - i) Ensure that there are no domain accounts that do NOT require Kerberos pre-authentication.  ii) If such accounts are required, ensure that no such accounts possess administrative access (aka privileged access) in Active Directory.
                     iii) Ensure that you know exactly who can modify this setting on all domain accounts in Active Directory. (To learn how to make this determination, see Corollary above.)

Kerberoasting

 •  Overview - A perpetrator requests a TGS ticket for a target service from the KDC (running on a DC). The KDC issues a TGS that is encrypted with target service's password hash, which the perpetrator cracks to determine the service's password.

 •  Minimum Requirement - In order to be able to obtain a TGS for a target, the target account must have an SPN (Service Principal Name). Consequently, any domain account that has an SPN specified can be targeted using this attack vector.

     ❗ Corollary - Anyone who has sufficient Validated Write - Validated write to service principal name Active Directory Effective Permissions on a domain computer account can modify its Service-Principal-Name attribute, and subsequently attempt this attack on that domain account.

 •  Mitigation - i) Minimize the number of domain user accounts configured with SPNs,  ii) Use gMSAs in lieu of regular service accounts,  iii) Ensure that no such accounts possess administrative access (aka privileged access) in Active Directory.
                     iii) Ensure that you know exactly who can modify this setting on all domain accounts in Active Directory. (To learn how to make this determination, see Corollary above.)

Unconstrained Delegation

 •  Background - Kerberos delegation is a feature wherein a service can be configured to impersonate a client. Delegation can be constrained or unconstrained. In constrained delegation, a service can only impersonate those clients that have been explicitly authorized to be delegated to that service. In unconstrained delegation, the service can impersonate any client on whose account the Account is sensitive and cannot be delegated setting is not set. In Microsoft's implementation of Kerberos, when a domain-joined machine is configured for unconstrained delegation, and a client authenticates to it, a copy of the client's TGT is stored in the memory of the LSASS (Local Security Authority Subsystem) process on that domain-joined machine.

 •  Overview - A perpetrator compromises a computer that is trusted for unconstrained delegation, then either lures a target account to authenticate to it and extracts its TGT from memory, or extracts the TGTs of any/all previously authenticated to it.

 •  Minimum Requirement - i) The perpetrator must have administrative access on the machine trusted for unconstrained delegation.  ii) The target account must not be marked sensitive  iii) The target account must have authenticated to the machine.

     ❗ Note - There are several attack techniques (e.g. PrinterBug, PetitPotam etc.) that can be used to coerce a security principal to authenticate to a machine owned by a perpetrator, obviating the need for a perpetrator to access a compromised machine.

 •  Mitigation - i) Ensure that only those computer accounts that absolutely need to be trusted for unconstrained delegation are trusted for the same, treat each such computer as though it were a Domain Controller, and ensure that only Domain Admin equivalent users have administrative access to it. ii) Ensure that the Account is sensitive and cannot be delegated setting is set on every single domain account that is considered to be an Active Directory administrative account (or a SAW's account.) iii) Ensure that you know exactly who can modify this setting on all domain computer accounts in Active Directory; to modify this setting, a security principal needs sufficient Write Property - userAccountControl Active Directory Effective Permissions as well the Enable computer and user accounts to be trusted for delegation user right granted in the default Domain Controllers Security policy.

Constrained Delegation

 •  Overview - A perpetrator compromises a computer that is trusted for constrained delegation, then performs a S4U2Self+S4U2Proxy to request and obtain a (forwarded) Kerberos service ticket that can be used to authenticate to any service specified in the msDS-AllowedToDelegateTo attribute of the account trusted for constrained delegation, as almost* any principal of choice. Additionally, the list of permitted services specified on various targets (via SPNS) can also be altered

 •  Minimum Requirement - i) The perpetrator must have administrative access on the machine trusted for constrained delegation.  *ii) The account being impersonated must not have the Account is sensitive and cannot be delegated setting enabled.

     ❗ Note - To enable an account to be trusted for constrained delegation, the following access is required - Write Property - msDS-AllowedToDelegateTo Active Directory Effective Permissions and Write Property - userAccountControl Active Directory Effective Permissions on the account, as well as the Enable computer and user accounts to be trusted for delegation user right granted in the default Domain Controllers Security policy. Anyone who has such access and has control of a service running as that account, could modify this attribute to include any target of choice, then attempt this attack against that target.

 •  Mitigation - i) Ensure that only those accounts that absolutely need to be trusted for constrained delegation are trusted for the same.  ii) Ensure that no such account is trusted to delegate to any services on any Domain Controller or SAW.  iii) Ensure that the Account is sensitive and cannot be delegated setting is set on every single domain account that is considered to be an Active Directory administrative account (or a SAW's account.)  iv) Ensure that you know exactly who can modify the msDS-AllowedToDelegateTo setting on all domain computer accounts in Active Directory; the access required to modify this setting on a domain account is specified in the Note above (i.e. immediately preceding this paragraph.)

Resource-based Constrained Delegation (RBCD)

 •  Overview - A perpetrator adds the SPN of a service account he/she controls, to the list of service accounts permitted to act on behalf of users when authenticating to a specific target (by modifying the msDS-AllowedToActOnBehalfOfOtherIdentity attribute on the target's computer account in Active Directory,) then performs a S4U2Self+S4U2Proxy to request and obtain a (forwarded) Kerberos service ticket that can be used to authenticate to the target as almost* any principal of choice.

 •  Minimum Requirement - i) The perpetrator must have sufficient Write Property - msDS-AllowedToActOnBehalfOfOtherIdentity Active Directory Effective Permissions on the computer account object (in Active Directory) of the target.  ii) The perpetrator must have control over the service account whose identity was specified in msDS-AllowedToActOnBehalfOfOtherIdentity attribute of the target resource('s computer object in Active Directory) to be able to request S4U* tickets.  *iii) The account being impersonated must not have the Account is sensitive and cannot be delegated setting enabled.

     ❗ Corollary - Anyone who has sufficient Write Property - msDS-AllowedToActOnBehalfOfOtherIdentity Active Directory Effective Permissions on a domain computer account and has control of a service (or computer) account in Active Directory could attempt this attack against that domain computer account.

 •  Mitigation - i) Ensure that only highly trustworthy administrative personnel have sufficient msDS-AllowedToActOnBehalfOfOtherIdentity Active Directory Effective Permissions -or- Modify Permissions Active Directory Effective Permissions -or- Modify Owner Active Directory Effective Permissions on all domain controller computer accounts, on all SAW domain computer accounts, and ideally on all domain computer accounts in Active Directory.  ii) Ensure that the Account is sensitive and cannot be delegated setting is set on every single domain account that is considered to be an Active Directory administrative account (or a SAW's account.)

Golden Ticket

 •  Overview - A perpetrator first obtains the hash of the KRBTGT's domain account, then uses it to forge TGTs, which are then used to request and obtain TGS tickets from the KDC (running on a DC) on behalf of any user('s account) of choice.

 •  Minimum Requirement - The perpetrator must have access to the KRBTGT's account's hash. This can only be obtained by dumping the NTDS.dit file on a DC (, which requires admin access to a DC,) or access to an AD backup, or DCSync.

 •  Mitigation - Ensure that perpetrators cannot obtain unauthorized access to the NTDS.dit file, or gain admin access to a DC, or access to an AD backup, or successfuly perform a DCSync operation against Active Directory.

     ❗ Important - It is imperative and paramount to understand that in order to be able to enact this attack vector, a perpetrator needs to have already gained Domain Admin equivalent privileged access in Active Directory, i.e. the forest has already been completely compromised.

Silver Ticket

 •  Overview - A perpetrator obtains the hash of a domain computer account or that of a domain user account in whose context a service is running on a computer, then uses it to forge valid TGS tickets to access that computer and/or impersonate it.

 •  Minimum Requirement - The perpetrator must have access to the target account's hash. This can only be obtained in several ways, including by employing various attack vectors described on this page.

 •  Mitigation - Considering that there are various ways in which perpetrators can obtain the hash of a specific account, it is not practically possible to entirely mitigate this attack vector. However, changing the passwords of all domain accounts on a regular basis (e.g. every 30 days) can help reduce its effectiveness. Far more importantly, ensuring that domain computer accounts are i) not members of any groups that have privileged access in Active Directory, including any default administrative groups in Active Directory, and ii) do not have any modify access (i.e. Modify Owner, Modify Permissions, Create Child or Write Property permissions) provisioned in Active Directory (other than that provisioned on a least-privilege basis).

Golden SAML

 •  Background - Active Directory Federation Services (ADFS) enables securely extending authentication across security and enterprise boundaries, such as from Active Directory to the Cloud. It can be configured as an IDP for/to Cloud services, and can issue SAML (Security Assertion Markup Language) tokens for Active Directory identities (domain accounts) that can be used to gain access to Cloud services. ADFS has a token signing certificate and uses its private key to sign SAML responses.

 •  Overview - A perpetrator compromises the service account used by AD FS or obtains administrative access to the AD FS Server, to then gain access to the AD FS token signing certificate and its private key, then also acquire the Distributed Key Manager (DKM) master key (which decrypts the AD FS certificate) from AD DS, and is then able to forge SAML responses to impersonate any (Active Directory) user and to obtain access to any service (in the Cloud) that trusts AD FS as an IDP.

 •  Minimum Requirement - i) The perpetrator must have access to the AD FS Service account.  ii) The perpetrator must have administrative access to the AD FS Server.  iii) The perpetrator must have access to the DKM master key from AD DS.

 •  Mitigation - i) Afford the same level of protection to AD FS servers as DCs  ii) Ensure that the AD FS service account is a gMSA account, and used solely for AD FS  iii) Tightly control and limit admin access to AD FS Servers to AD FS admins only

     ❗ Important - This attack vector is only made possible by the fact that the administrative compromise of a server that is effectively an IDP trusted to vouch for Active Directory identities can enable a perpetrator to gain access to the master key, and forge identities. That is not a weakness in/of Active Directory.

ESC1

 •  Overview - A perpetrator requests a client authentication certificate and provides an alternate name i.e. that of the target security principal, for the subject. The CA issues the requested certificate to the perpetrator if the minimum requirement is met.

 •  Minimum Requirement - i) Perpetrator is allowed to enroll for this certificate  ii) Manager approval: Not Required  iii) Authorized signatures: Not Required  iv) Extended Key Usage (EKU): Client Authentication  v) Enrollee supplies Subject: True

 •  Mitigation - Ensure that there are no certificate templates that non-administrative accounts are enrolled to be able to request, for which Enrollee Supplies Subject setting is set to True.

ESC2

 •  Overview - A perpetrator first requests and successfully obtains an Any Purpose EKU certificate, then uses this obtained certificate in a Certificate Request Agent role to subsequently request and obtain any certificate of choice for any purpose.

 •  Minimum Requirement - i) Perpetrator is allowed to enroll for this certificate  ii) Manager approval: Not Required  iii) Authorized signatures: Not Required  iv) Extended Key Usage (EKU): Either not set, or set to Any Purpose

 •  Mitigation - Ensure that there are no certificate templates that non-administrative accounts are enrolled to be able to request, for which the Application Policies (EKU) value is either not set or set to Any Purpose.

ESC3

 •  Overview - A perpetrator first requests and successfully obtains an Certificate Request Agent EKU certificate, then uses it in a Certificate Request Agent role to subsequently request and obtain any certificate in another subject's name.

 •  Minimum Requirement - i) Perpetrator is allowed to enroll for this certificate  ii) Manager approval: Not Required  iii) Authorized signatures: Not Required  iv) Extended Key Usage (EKU): Certificate Request Agent

 •  Mitigation - Ensure that there are no certificate templates that non-administrative accounts are enrolled to be able to request, for which the Application Policies (EKU) value is set to Certificate Request Agent.

ESC4

 •  Overview - A perpetrator leverages excessive Active Directory Effective Permissions on a template's object in Active Directory, to alter one or more properites on it that then make it vulnerable to exploitation, and then exploit those vulnerabilities.

 •  Example - A perpetrator first modifies the mspki-certificate-name-flag property on a certificate template, enabling the specification of Subject Alt Names in a CSR, then proceeds to easily enact an ESC1 attack (described above) on the template.

 •  Minimum Requirement - i) Perpetrator is allowed to enroll for this certificate  ii) Manager approval: Not Required  iii) Authorized signatures: Not Required  iv) Perpetrator has sufficient modify Active Directory Effective Permissions on template object

 •  Mitigation - Ensure that only highly trustworthy administrative personnel have sufficient Write property - {x} Active Directory Effective Permissions, where {x} is an exploitable attribute, e.g. mspki-certificate-name-flag  -or-  Modify Permissions Active Directory Effective Permissions  -or-  Modify Owner Active Directory Effective Permissions on all certificate templates in Active Directory.

ESC5

 •  Overview - A perpetrator gains administrative access over a Certificate Authority (CA), then gains access to the CA's root or issuing certificate private key, enabling him/her to issue certificates at will. In essence, the attacker could forge a certificate for any domain user (including any Domain Admin or any DC account) and sign it using this key, and it will be accepted by DCs as valid authentication for that identity, with such access persisting for as long as the certificate is valid (or until revoked.)

 •  Minimum Requirement - The perpetrator must have administrative access to a CA.

 •  Mitigation - i) Afford the same level of protection to AD CS servers (i.e. CAs) as one does to AD DS Domain Controllers  ii) Tightly control and limit administrative access to all AD CS Servers to AD CS admins only

     ❗ Important - It is imperative and paramount to understand that in order to be able to enact this attack vector, a perpetrator needs to have already gained administrative access on to a Certiticate Authority that AD DS relies on for authentication i.e. the forest has already been completely compromised.

ESC6

 •  Overview - A perpetrator modifies the default behaviour of a CA such that the inclusion of a Subject Alternate Name is allowed even if a template itself does not permit it, enabling the perpetrator to request a certificate for any subject of choice.

 •  Minimum Requirement - The perpetrator requires sufficient access to modify a registry entry (to introduce the flag EDITF_ATTRIBUTESUBJECTALTNAME2) on the Certificate Authority and then restart Certficate Services.

 •  Mitigation - Ensure that only highly trustworthy administrative personnel can logon to a CA server, restart a CA server, or restart the Certificate Services service on a CA Server.

ESC7

 •  Overview - A perpetrator who has sufficient Manage Certificate Authority access rights, grants him/herself the Manage Certificates permission, following which he/she can manually approve any pending certificate issuance requests.

 •  Minimum Requirement - The perpetrator requires sufficient access to be able to manage a CA.

 •  Mitigation - Ensure that only highly trustworthy administrative personnel have sufficient access to be able to manage CAs.

     ❗ Important - It is imperative and paramount to understand that in order to be able to enact this attack vector, a perpetrator needs to have sufficient access to be able to manage a CA server, i.e. (in an environment where AD DS relies on AD CS,) the forest has already been completely compromised.

ESC8

 •  Overview - A perpetrator coerces a target machine (e.g. a DC) to authenticate to a machine owned by the perpetrator, then relays the NTLM hash of the target machine to a misconfigured (EPA disabled) AD CS Certificate Enrollment Web Service, accessible via http, to request and successfully obtain a certificate as the target machine, i.e. bearing the target machine's identity, enabling the perpetrator to request a TGT on behalf of the target machine, and extract the NTLM hash of the target machine from the TGT, which once obtained can be used to access any resource of choice in the security context of the target machine. In the case of a DC, the perpetrator can then easily perform a DCSync and obtain everyone's credentials.

 •  Minimum Requirement - i) A misconfigured AD CS Web Enrollment Service i.e. a) accessible via http & b) accepts NTLM authentication,  ii) Target machine must be susceptible to coercion i.e. can be forced to authenticate to an attacker's machine.

 •  Mitigation - i) Enable Extended Protection for Authentication (EPA) on AD CS Web Enrollment Servers,  2) Disable http on AD CS Web Enrollment Servers (Require SSL),  iii) If possible, disable NTLM authentication on DCs and on AD CS CAs.

ESC9

 •  Overview - A perpetrator requests a client authentication certificate and provides an alternate name i.e. that of the target security principal, for the subject. The CA issues the requested certificate to the perpetrator if the minimum requirement is met.

 •  Minimum Requirement - i) Perpetrator is allowed to enroll for this certificate  ii) Manager approval: Not Required  iii) Authorized signatures: Not Required  iv) Extended Key Usage (EKU): Client Authentication,  v) The value of the registry key StrongCertificateBindingEnforcement on Domain Controllers is set to 0 or 1, and  vi) Certificate mapping enforcement is weak i.e. the CT_FLAG_NO_SECURITY_EXTENSION is enabled in the msPKI-Enrollment-Flag attribute of the certificate's template.
In addition, perpetrator also requires sufficient Write Property - userPrincipalName Active Directory Effective Permissions on the domain account for which the client authentication certificate is being requested, so as to be able to change its UPN.

     ❗ Corollary - Anyone who has sufficient Write Property - msPKI-Enrollment-Flag Active Directory Effective Permissions on a certificate template can weaken certificate mapping enforcement on that template, and subsequently attempt this attack on that template.

 •  Mitigation - Set StrongCertificateBindingEnforcement on DCs = 2. Alternatively, ensure that there are no certificate templates that non-admin accounts are enrolled to be able to request, for which all of the above minimum requirements are true and also ensure that only highly authorized and trustworthy individuals have sufficient Write Property - msPKI-Enrollment-Flag Active Directory Effective Permissions on all certificate templates published in Active Directory.

ESC10

 •  Overview - A perpetrator requests a client authentication certificate and provides an alternate name i.e. that of the target security principal, for the subject. The CA issues the requested certificate to the perpetrator if the minimum requirement is met.

 •  Variations - There are two variations of this attack, each relying on the value of a unique registry key on DCs. The first variation involves requesting a certificate for Kerberos authentication and relies on the value of the registry key StrongCertificateBindingEnforcement being 0. The second involves requesting a machine account's certificate for authentication via SChannel and relies on the value of the registry key CertificateMappingMethods having the 0x04 flag (UPN mapping) enabled.

 •  Minimum Requirement (Variation 1) - i) Perpetrator is allowed to enroll for this certificate  ii) Manager approval: Not Required  iii) Authorized signatures: Not Required  iv) Extended Key Usage (EKU): Client Authentication,  v) The value of the registry key StrongCertificateBindingEnforcement on Domain Controllers is set to 0, and  vi) Perpetrator has sufficient Active Directory Effective Permissions to modify the userPrincipalName (UPN) attribute of a security principal.

 •  Minimum Requirement (Variation 2) - i) Perpetrator is allowed to enroll for this certificate  ii) Manager approval: Not Required  iii) Authorized signatures: Not Required  iv) Extended Key Usage (EKU): Client Authentication,  v) The value of the registry key CertificateMappingMethods on Domain Controllers has the flag 0x04 enabled, and  vi) Perpetrator has sufficient Active Directory Effective Permissions to modify the userPrincipalName (UPN) attribute of a security principal.

 •  Mitigation - To mitigate attack vector (variation 1), set the value of the registry key StrongCertificateBindingEnforcement = 2 on DCs. To mitigate attack vector (variation 2), disable the 0x04 flag in the CertificateMappingMethods registry key on DCs.

ESC11

 •  Note - This is not a commonly used credential theft attack vector.

ESC12

 •  Note - This is not a commonly used credential theft attack vector.

ESC13

 •  Overview - A perpetrator requests a client authentication certificate against a certificate template that has an OID group link specified, and if the minimum requirement is met, the CA issues the requested certificate to the perpetrator, and when the perpetrator uses it request a TGT, it will result in the group specified in the group OID link of the certificate template being added to the PAC, enabling the perpetrator to be able to access any resource that is protected by that specific security group.

 •  Minimum Requirement - i) Perpetrator is allowed to enroll for this certificate  ii) Manager approval: Not Required  iii) Authorized signatures: Not Required  iv) Certificate template has an issuance policy extension specified  v) Issuance policy (represented as an instance of class msPKI-Enterprise-Oid) has an OID group link specified in its msDS-OIDToGroupLink attribute  vi) Extended Key Usage (EKU): Client Authentication.

     ❗ Corollary - Anyone who has sufficient Write Property - msDS-OIDToGroupLink Active Directory Effective Permissions on an issuance policy in Active Directory can modify the security group associated with the issuance policy.

 •  Mitigation - i) Ensure that there are no certificate templates that are linked to highly privileged groups that non-administrative accounts are enrolled to be able to request. ii) Require Manager approval for the issuance of all such certificates. iii) Ensure that no unauthorized users have sufficient Modify Owner, Modify Permissions or Write Property - msDS-OIDToGroupLink Active Directory Effective Permissions on any Issuance Policy objects (class: msPKI-Enterprise-Oid) in Active Directory.

     ❗ Note - This is a relatively lame attack vector, because in reality, given the system requirement that the linked security group must always be empty, the only situation wherein this can be practically used is to compromise a resource that is then protected by that specific empty universal security group.

ESC14

 •  Overview - A perpetrator exploits explicit certificate mapping to be able to authenticate as a target account. To do so, he/she first obtains a client authentication certificate from the CA using the account he/she controls, then adds an explicit certificate mapping that refers to this obtained certificate by modifying the altSecurityIdentities attribute on the target account's domain account in Active Directory.

 •  Minimum Requirement - i) Perpetrator is allowed to enroll for this certificate  ii) Manager approval: Not Required  iii) Authorized signatures: Not Required  iv) Perpetrator has Write Property - altSecurityIdentities Active Directory Effective Permissions on target account's domain account object in Active Directory.

 •  Mitigation - Ensure that only authorized personnel have Write Property - altSecurityIdentities Active Directory Effective Permissions on target account's domain account object in Active Directory

ESC15

 •  Overview - A perpetrator requests a certificate, providing an application policy of choice and a subject alternative name i.e. that of the target principal. The CA issues the requested certificate to the perpetrator if the minimum requirement is met.

 •  Minimum Requirement - i) Perpetrator is allowed to enroll for this certificate  ii) Manager approval: Not Required  iii) Authorized signatures: Not Required  iv) Template Version = 1,  v) Source of subject name = "Supplied in the request".

 •  Mitigation - Discontinue use of Schema version 1 certificates. Alternatively, ensure that there are no certificate templates that non-admin accounts are enrolled to be able to request, for which all of the above minimum requirements are true.