How can defenders detect malicious use of CertReq.exe?

What malicious CertReq.exe activity looks like in telemetry

CertReq.exe is a built-in Windows certificate request utility, so defenders usually do not look for the binary alone. The signal is the workflow around it: request generation, CA interaction, certificate retrieval, and follow-on authentication use that does not match normal enrollment patterns. That means process creation, command line, parent process, target CA, template choice, and the account or host involved all matter.

A useful baseline is whether the request belongs to a known enrollment path, such as workstation provisioning, smart card issuance, or an approved admin workflow. When CertReq.exe appears on an endpoint that normally does not enroll certificates, or when it is launched by an unusual parent process, it should be treated as potentially suspicious rather than merely uncommon.

How to spot abuse in process, request, and CA logs

Start by correlating endpoint telemetry with certificate authority records. A suspicious request often shows up as a certificate enrollment action from a non-admin endpoint, followed by retrieval of a certificate template that does not fit the host role or user role. If your environment logs request IDs, template names, subject attributes, SAN values, or requester identity, those fields are often the fastest way to see whether the activity is legitimate.

Command-line review is especially important because attackers frequently use CertReq.exe to automate enrollment or abuse certificate-based trust. Pay attention to unusual flags, nonstandard output paths, redirected requests, and sequences where the utility is used to stage a certificate for later authentication abuse. The broader Living off the Land Guide is useful here because the same detection logic used for other dual-use Windows binaries applies to CertReq.exe: context, parent process, and command-line intent matter more than the binary name itself.

Also watch for the certificate being used shortly after issuance in ways that do not match the original business function. A request that is immediately followed by unusual logon activity, delegation, impersonation, or access from a different host can indicate that the certificate was sought for post-exploitation use rather than for a normal operational need.

Why post-issuance behavior is a strong detection clue

Certificate abuse is rarely a one-step event. Defenders should treat certificate request telemetry and authentication telemetry as a chain, not separate events. A request alone may be benign, but a request that is quickly followed by lateral movement, privileged access, or sign-in attempts inconsistent with the requester’s normal pattern is much more concerning.

The most valuable hunting question is whether the certificate materially changes the actor’s ability to authenticate or impersonate. If the answer is yes, the certificate becomes part of the compromise path, not just an artifact. That is why defenders should connect CertReq.exe activity to account behavior, service access, and any subsequent use of certificate-based authentication, especially when the original request came from a machine that should not be involved in PKI administration.

The detection challenge is that this abuse can blend into legitimate certificate operations. Reviewers need to distinguish normal enrollment volume from anomalous identity use, unexpected template selection, and certificate retrieval from endpoints that have no clear business reason to participate in that workflow.

Risk and Threat Considerations

Malicious CertReq.exe use is risky because certificate issuance can become an authentication shortcut. If an attacker can obtain a certificate that maps to a trusted identity, they may gain durable access that looks legitimate in many logs and may outlive an ordinary password reset.

Failure mechanism: The attacker abuses a legitimate enrollment utility or workflow to request, retrieve, or stage a certificate, then uses that certificate for authentication, impersonation, or privilege expansion. Defenders miss the event when they monitor only the endpoint binary and not the CA records and follow-on identity activity.

Impact: The result can be unauthorized access, harder-to-detect lateral movement, and persistence through certificate-based trust. In practice, that can turn a single suspicious enrollment into a broader identity compromise incident.

Practitioner Guidance

What to verify: Confirm whether the host, user, and template combination is normal for your certificate enrollment model. If the request came from a workstation or server that does not usually perform PKI enrollment, treat that as a priority hunting lead rather than a low-confidence anomaly.

What to prioritize: Correlate process creation, CA request logs, and subsequent logon activity before you spend time on endpoint noise. The sequence matters more than any single event because malicious use is often only obvious after you see request, issuance, and use together.

Practitioner takeaway: The strongest detection is not “CertReq.exe ran,” but “CertReq.exe created a certificate path that led into identity abuse.” That means defenders should hunt across the full request-to-authentication chain, not stop at the process event.

Related resources from NHI Mgmt Group

• How can defenders detect malicious use of Bginfo.exe?
• How can defenders detect malicious use of Csc.exe?
• How can defenders detect malicious use of devtunnel.exe?
• How can defenders detect malicious use of Eventvwr.exe?