Skip to content
Security

Event ID 4886: Certificate request received

Certificate Services received a certificate requestSecurity event 4886 is logged on an AD CS certification authority when it receives a certificate request, with the request ID and the requesting account.
4886
Event ID
4886
Channel
Security
Provider
Microsoft-Windows-Security-Auditing
Log file
Security.evtx
Category
Active Directory
Default logging
Needs configuration

What event 4886 means

Event 4886 is written by an Active Directory Certificate Services CA each time it receives a certificate request. It records the RequestId, the Requester account and the request Attributes. What happens next is logged under the same request ID: 4887 when the certificate is issued, 4888 when denied, 4889 when set to pending.

Certificates are credentials. A certificate that allows client authentication can be used to obtain Kerberos tickets for the account named in it, so abuse of misconfigured templates is a direct path to domain privilege escalation and persistence. 4886 is the first place the CA records such a request and the account that made it.

The event only exists when auditing is enabled twice: in the audit policy and in the CA's own audit filter.

When it is logged

Audit policy / configuration

Advanced Audit Policy Configuration > Object Access > Audit Certification Services (Success), plus "Issue and manage certificate requests" enabled on the Auditing tab of the CA properties (the CA audit filter).

Logged only on servers running the AD CS certification authority role. Older builds do not record the subject alternative name requested in the CSR; review the issued certificate in the CA database when a request looks suspicious.

Key fields

FieldWhat it tells you
RequestIdCA request number. Use it to join 4886 with 4887, 4888 or 4889 and to look the request up in the CA database.
RequesterAccount that submitted the request, as DOMAIN\user or DOMAIN\HOST$.
AttributesRequest attributes supplied with the request, such as the client machine name (ccm:). On a CA that accepts SAN attributes, a san: attribute here names the identity being requested.

Common benign sources

  • Autoenrollment of user and computer certificates across the domain.
  • Web server, domain controller and device certificate renewals.
  • Administrators or PKI operators requesting certificates through the Certificates MMC or certreq.

What attackers do that produces it

  • Abuse of a vulnerable template (e.g. one that lets the requester supply the subject) to request a certificate for a privileged account, using tools such as Certify or Certipy.
  • A low-privileged account requesting certificates from templates it has never used, or at unusual volume.

Investigation tips

  • Join on RequestId with 4887 to see whether and for which subject the certificate was issued.
  • Look up the request in the CA database (certutil -view or the CA console) to see the template and requested SAN.
  • Compare Requester with the identity in the issued certificate; a mismatch for a privileged account is a strong lead.
  • Follow the certificate's use with 4768 on domain controllers (PKINIT authentication).

MITRE ATT&CK techniques

TechniqueTactics
T1649 Steal or Forge Authentication CertificatesCredential Access

MITRE ATT&CK v19.2. Technique and tactic names are MITRE's.

Sigma rules for this event

No bundled SigmaHQ rule targets this event ID specifically. Rules on related events may still cover the activity.

Run these rules on your logs

Drop a .evtx file into the viewer: all 2,395 bundled SigmaHQ rules run locally in your browser. Nothing is uploaded.

Sources and further reading