The role of Certification Authority is to provide trust between different active directory entities or as an authentication mechanism in order to access specific resources such as web applications and services in a secure manner. Deployment of a Certification Authority across a windows domain can provide opportunities to threat actors for abuse that involves persistence and domain escalation. These attacks have been covered in detail in the paper Certified Pre-Owned that was released by Will Schroeder and Lee Christensen.

Attacks that utilize the Certification Authority are not common and require focus to ensure visibility and proper alerting to be in place to detect these attacks at an early stage. One of the attacks that have been discussed in the paper involves the account persistence via certificate. Threat actors who are going to use this technique will move away from traditional methods which involve the LSASS process for credential dumping. It is essential to understand the steps required to detect this technique using Group Policy to enable logging, the correlated Windows Events and Elastic queries.

Group Policy

Systems on the domain that act as a Certification Authority (CA) should have a number of events logged to ensure activities related to certificates and modifications on the CA are captured. However, logging is not enabled by default which can create a visibility gap during threat hunting for account persistence via certificates. Following the sequence of actions below will enable the necessary logging in the certification authority system.

certsrv.msc --> Right click on the CA --> Auditing

Success and failure activities related to the certification services can be enabled from the audit policies under the following GPO:

Computer Configuration --> Windows Settings --> Security Settings --> Advanced Audit Policy Configuration --> Audit Policies --> Object Access --> 
Audit Certification Services

Service ticket operations and authentication events via the Kerberos protocol should be logged since threat actors to complete the technique are required to request a ticket from the Key Distribution Center (KDC). Both “Success” and “Failure” events should be audited under the following group policy object:

Computer Configuration --> Windows Settings --> Security Settings --> Advanced Audit Policy Configuration --> Audit Policies --> Account Logon -->
Audit Kerberos Authentication Service & Audit Kerberos Service Ticket Operations

The Audit object access policy handles auditing access to all objects outside of active directory. Success and Failure events should be enabled from the following group policy object:

Computer Configuration --> Policies --> Windows Settings --> Security Settings --> Local Policies --> Audit Policy --> Audit object access

Certificate Requests & Approvals

During the first stage of the attack threat actors perform a certificate enrollment. The certification authority receives a certificate request and base on the existing configuration (automatic enrollment or manager approval) a certificate is issued or not. During this activity a windows event of 4886 is generated in the logs which represents a certificate request.

When the certificate authority approves the request and issue a certificate to an account this is captured on windows event 4887. This event contains some additional information such as the account which initiated the request and the cert client machine name (ccm) which is the host that it was used to perform this activity. Even though that this information is particularly useful to determine the origin of the attack during threat hunting some additional details are not visible. These details include the certificate template that it was used, the process name or if an alternate username was used in the SAN extension to perform impersonation.

Detailed certificate information is stored in the CA database which is a file that exists in the Active Directory Certificate Services (AD CS). The “certutil” Microsoft binary can retrieve this information for additional analysis. Results can be filtered with the use of “restrict” parameter in order specific certificate information to be displayed from the user account which perform the initial request. In an environment which certificate authority is utilized heavily this can generate massive information in the console. Obtaining the timestamp from the windows events can filter the results further to correlate the request of interest.

certutil.exe -v -view -restrict "Disposition=20,Request.SubmittedWhen>=9/18/2021 12:55 PM,RequesterName=PURPLE\pentestlab" -gmt -out requestername,rawrequest

The subject of the certificate and the public key associated with the private key that was used to sign the CSR are also displayed in the output.

Essential information is also displayed which is related to the user who performed the certificate request, the machine name and the process. The Certify tool was released to discover and perform abuse in not properly configured Active Directory Certificate Services. Since the process is related to Certify this could be considered an anomaly in legit requests which typically use the web interface directly.

Similarly the above information including the certificate template can be retrieved using the PSPKIAudit PowerShell tool by executing the following command:

Get-CertRequest -CAComputerName ca.purple.lab -HasSAN

Certificate Authentication

The second stage of the attack requires authentication via the Kerberos protocol with the certificate that was obtained. Threat actors can request Kerberos tickets from the Key Distribution Center (KDC) using a certificate. These type of requests are captured in the windows event 4768.

Certificate information such as the issuer name, the serial number and thumbprint are also populated in the event which could act as an indicator of an arbitrary activity due to anomaly of usage.

The final stage of the attack is to query the privilege access attribute (PAC) in order to retrieve the NTLM hash of the account. This type of request is logged as a windows event with code 4769. Even though that it could not be considered directly as an indicator of a malicious activity the fact that the service targets the machine account of the certificate authority can raise suspicion. Ability to know which are the standard Kerberos tickets requests can enable SOC teams to distinguish the arbitrary requests.

Elastic

Focus on the windows logs should be towards the information which is related to certificate requests and approvals, accounts which performed these requests, host names, and target user names and service names. Correlation of this information could help towards threat hunting for certificate based account persistence. Execution of the below KQL query will display all the certificate requests towards the Certificate Authority. The “winlog.event_data.Attributes” will display from which origin source the request was initiated and the “winlog.event_data.Requester” the account. This information can be used to identify accounts and computers which are likely compromised and attempt to perform the technique of account persistence via certificates.

host.name: "ca.purple.lab"  and event.code: "4886"  and winlog.task : "Certification Services" and message: Requester and winlog.event_data.Attributes: "
ccm:Hive.purple.lab" and winlog.event_data.Requester : "PURPLE\\pentestlab"

When the certification authority issues a certificate the action is logged with event ID of 4887. A slight modification on the above query will provide the details of the account which a certificate has been issued.

host.name: "ca.purple.lab"  and event.code: "4887"  and winlog.task : "Certification Services" and message: Requester and winlog.event_data.Attributes: "
ccm:Hive.purple.lab" and winlog.event_data.Requester : "PURPLE\\pentestlab" 

Kerberos ticket requests are logged with event ID 4768. However, using the machine account of the certificate authority more targeted queries can be executed to correlate Kerberos tickets with that account as an attack indicator. This event log is an indication that a ticket was requested from the domain controller using a certificate for authentication.

event.code: "4768" and message: TGT and winlog.event_data.TargetUserName : "CA$"

Retrieval of the NTLM hash via the privilege attribute certificate (PAC) generate windows event that have a specific pattern. Execution of queries to discover 4769 windows events correlated with the machine account of the certificate authority for the target username and service name is an indication of a PAC request.

event.code: "4769" and winlog.event_data.TargetUserName : "CA$@PURPLE.LAB"  and winlog.task: Kerberos Service Ticket Operations and 
winlog.event_data.ServiceName : "CA$"

Tools

Implementation of the attack is conducted with the use of Certify and Rubeus. In their original repositories there are Yara rules which can be used for detection. Both projects have been developed in C# and detection is focused towards the “typelibguid” values which is mapped to the ProjectGuid which uniquely identifies a project. In the scenario that threat actors and red teams have built these tools without any modification directly from the original source the “typelibguid” can provide a detection opportunity. However, this should not be considered a reliable method as threat actors could modify the ProjectGuid from the vcxproj file.

rule Certify
{
    meta:
        description = "The TypeLibGUID present in a .NET binary maps directly to the ProjectGuid found in the '.csproj' file of a .NET project."
        author = "Will Schroeder (@harmj0y)"
    strings:
        $typelibguid = "64524ca5-e4d0-41b3-acc3-3bdbefd40c97" ascii nocase wide
    condition:
        uint16(0) == 0x5A4D and $typelibguid
}

rule Rubeus
{
    meta:
        description = "The TypeLibGUID present in a .NET binary maps directly to the ProjectGuid found in the '.csproj' file of a .NET project. This rule looks for .NET PE files that contain the ProjectGuid found in the public Rubeus project."
        md5 = "66e0681a500c726ed52e5ea9423d2654"
        rev = 4
        author = "FireEye"
    strings:
        $typelibguid = "658C8B7F-3664-4A95-9572-A3E5871DFC06" ascii nocase wide
    condition:
        uint16(0) == 0x5A4D and $typelibguid
}

Execution of the above Yara rules will determine the presence of these tools on the disk as the example below or in memory of a process.

yara64.exe -s -r Rubeus.yar "<Path/PID>"
yara64.exe -s -r Certify.yar "<Path/PID>"

Windows Events

If you are interested to learn more about how Pentest Laboratories and our custom cyber attack scenarios can improve your organisation readiness against cyber threats please contact us.