Detecting T1649 Steal or forge authentication certificates

How T1649 steal or forge authentication certificates shows up in a SOC

A SOC lead needs a direct answer: yes, certificate-based authentication can be abused, and T1649 Steal or forge authentication certificates is the ATT&CK technique that describes it. Under Credential Access (TA0006), an adversary who obtains a valid authentication certificate, or forges one that a trusting system accepts, can authenticate as a user or service without knowing a password. The certificate then becomes a durable credential, so resetting passwords alone may not remove the access. Mappings in this section reference Enterprise ATT&CK version 20.0, and any detection or control mapping your team writes should name the ATT&CK version it targets, because releases can rename, deprecate or revoke techniques.

Certificates show up in intrusions in two places that a SOC should watch together. On endpoints, the concern is the storage of certificate material and private keys, including user certificate stores, exported certificate files and the processes that read them. On identity providers, the concern is whether a certificate presented at sign-in matches an enrolled credential and whether that credential was issued, changed or bound to a new account through a legitimate path. An authentication event that looks normal on one side can be the only trace on the other, so correlating endpoint file and process activity with identity provider sign-in and credential change logs is the practical starting point.

Before writing detection rules, the SOC lead should confirm several items in the environment: which certificate authorities issue user, device and service certificates, which identity providers accept certificate-based sign-in, whether those sign-in events are forwarded to the SIEM with the certificate subject or thumbprint fields intact, and who owns certificate enrollment and revocation. These answers decide which data components are available and which alerts are realistic to build. Where a field is missing from the logs, record that gap as a risk to plan for, since a detection cannot be validated against telemetry that is never collected.

Which data sources reveal certificate theft and forgery

This table maps the data components most relevant to T1649 to the signal worth watching, the open-source collector that gathers it, and the platforms it covers. Read each row as a starting point for analytics, then confirm the current data component IDs in the STIX bundle for the ATT&CK version you target, because v18 changed data components.

Data component and signal	Open-source collector	Platforms covered
File Access (DC0055): reads of certificate and private key files, such as PFX, PEM or key stores, by processes outside expected certificate tooling	Wazuh file integrity monitoring and auditd rules, or Velociraptor artifacts that hunt on certificate store paths	Windows, Linux, macOS
Application Log Content (DC0038): certificate export, key download or signing events in Active Directory Certificate Services and identity provider admin logs	Wazuh decoders for AD CS and Windows event channels, with Sigma rules for certificate request and issuance events	Windows, Identity Provider
Process Creation (DC0032): command execution that invokes certificate export, key handling or token signing utilities outside approved change windows	Wazuh Sysmon or auditd process telemetry, Velociraptor process hunts for certificate tooling	Windows, Linux, macOS
Application Log Content (DC0038): administrative changes to trusted root stores, signing certificate templates or identity provider signing keys	Wazuh log collection from identity provider audit feeds and Windows event logs for certificate template changes	Identity Provider, Windows
Network context: TLS handshakes showing unexpected client certificates or certificate chains to internal identity services	Zeek ssl and x509 logs, or Suricata TLS metadata, correlated with identity provider authentication logs	Identity Provider, Windows, Linux, macOS (network view)
Unix certificate and key directories: changes to ownership, permissions or content of certificate and key stores	Wazuh file integrity monitoring on Linux and macOS paths, and Velociraptor collection of key store metadata	Linux, macOS

Detection ideas for stolen or forged certificates

The four to six concepts below cover the points where a stolen or forged authentication certificate leaves a trace: on the endpoint where the private key lives, in the act of copying it, at the identity provider where it is presented, and in the issuance records. Each card names the logic, the thresholds to tune in your own environment, and the benign activity that will trigger it first.

Unexpected access to private key stores

Certificate private keys on Windows are usually held in the machine or user certificate store, and on Linux and macOS in keychains, PKCS#11 tokens or key files. Alert when a process or account that has never touched these stores reads key material, using File Access and Process Access telemetry where your sensors record it. Start with a short allowlist of signing services, browsers and VPN clients, then review new entries weekly. Expect backup agents, endpoint security suites and MDM enrollment tooling to trigger this first, so tag their binaries and service accounts explicitly rather than suppressing the rule wholesale.

Certificate export and copy events

An exported certificate with its private key is a portable credential, so exports deserve a rule of their own. Look for PFX or PKCS#12 file creation that includes a private key, certificate export operations logged by the operating system, and file copies of key containers to removable or network paths. Set the threshold at any export outside a change ticket window, and group events by host and account so repeated exports stand out. Certificate lifecycle and backup software performs legitimate exports on schedule, so record their expected export paths and times before you go live.

Certificate logins from unusual issuers

Identity providers that accept certificate-based sign-in record the issuing authority, subject and thumbprint of the presented certificate. Build a baseline of which issuers, subject patterns and thumbprints each application or user group normally presents, then alert on any login from a certificate that is outside that set. Pay particular attention to certificates from an issuer you do not operate, subjects that match no directory object, and logins that follow a new certificate enrollment within a short window. Smart card logon, device compliance checks and federated partners can all produce novel issuers, so confirm each new entry against your trust configuration.

Certificates issued outside enrollment

Certificates should come from a defined enrollment path, such as an internal certificate authority template, an MDM profile or an ACME client tied to a known account. Review issuance logs for certificates requested by accounts outside the enrollment service group, for templates that allow subject names to be supplied by the requester, and for certificates whose validity period or key usage differs from the template. Ask your certificate authority administrators which templates permit requester-supplied subjects, because that setting is the most common route to a forged identity. Certificate lifecycle platforms and automated renewal jobs will generate high volume here, so match on the service account and template rather than on request count.

Logins from certificates without a matching record

A sign-in that presents a valid certificate for a user whose directory record shows no enrolled certificate, or whose enrolled certificate has a different thumbprint, deserves review. Correlate identity provider sign-in events with directory and certificate authority records on subject and thumbprint, and flag mismatches across a short time window. Mismatches also appear after certificate renewals, when a directory attribute lags the new thumbprint, so compare against renewal timestamps before escalating. Review the first week of results manually, then tighten the window once your renewal pipeline is well understood.

How to validate the T1649 detection in a lab

This sequence proves that detections for T1649 Steal or Forge Authentication Certificates fire on the expected telemetry, that the evidence is complete enough to investigate, and that every gap is recorded so the rule can be tuned and re-tested against the ATT&CK version it targets. It runs in a private lab or cyber range owned and controlled by the client, with the environment owner approving each step in writing.

Agree scope and rules of engagement
Before any emulation, the security lead, the owner of the lab or range, and the team responsible for the affected platforms sign a written scope. The scope names the operating systems and identity provider in use, the accounts that may be involved, the time window, the systems that are off limits, and who can halt the exercise. Engagement contacts are agreed for the duration. The step is complete when the signed scope is filed with the exercise record and every participant confirms they know how to stop the exercise.
Define the emulated behavior conceptually
The team agrees, at a conceptual level only, which family of certificate-related behavior the exercise will represent for each platform in scope, such as an unexpected change to how a certificate store or signing material is accessed, or an authentication artifact being presented from an unexpected host. The plan records the ATT&CK technique and the targeted ATT&CK version, which should be stated explicitly because releases can rename, deprecate or revoke techniques. No commands, payloads or tooling steps are written into the plan. The step is complete when the plan maps each behavior to the data component expected to record it.
Confirm baseline logging before the run
Before the exercise, the lab engineer confirms that the relevant log sources are reaching the SIEM and are not dropping events. For Windows, Linux and macOS this means file access auditing on certificate and key locations, application logs where configured, and command execution records. For the identity provider, it means its audit and authentication logs. The engineer records the agent versions, audit policy settings and time synchronization state. The step is complete when a benign test event appears in each source with the expected fields.
Run the emulation and mark timestamps
The emulation is executed by the agreed operator inside the lab, and an observer keeps a timeline with start and end times for each planned behavior. Each action is labeled in the timeline with an exercise identifier so it can be matched against the logs later. The observer does not share the timeline with the detection team until the collection step is complete, so that detection results are not influenced. The step is complete when the operator confirms the planned behaviors ran or records which ones did not.
Confirm which log sources fired
The detection team searches each in-scope source for events within the recorded time windows and matches them to the exercise identifiers. For each planned behavior, they note whether a file access, application log, command execution or identity provider event appeared, and whether the alert rule raised a case. The team checks the source, not only the alert, because an alert can fire for the wrong reason. The step is complete when every planned behavior has a recorded result of detected, partially detected or not detected, with the source that supports it.
Record timestamps and fields
For each event that matched, the team records the event time, the host or identity, the account, the process or application involved, and the key fields the detection logic relies on. They also check that timestamps from different sources agree within an acceptable tolerance set by the client, and that the time zone and clock source are consistent. Missing or renamed fields are logged as findings. The step is complete when a structured evidence table exists for the exercise, ready to be attached to the detection record.
Document gaps and tune the detection
Every planned behavior that was not detected, and every source that was silent or incomplete, is written up as a gap with a cause and an owner. Causes may include missing audit policy, unparsed fields, noisy rules, or a platform that does not expose the needed telemetry. The team confirms which changes are within the client's control and which need vendor or platform confirmation. Tuning changes are made in version control, then the exercise is re-run against the same ATT&CK version to confirm the change. The step is complete when each gap has a status and the re-test results are filed.

Preventive controls that limit certificate abuse

Certificate theft and forgery succeed when private keys are easy to copy and certificate or identity provider changes go unnoticed. The cards below pair key protection with audit coverage so that a stolen or misused certificate is both harder to obtain and visible when it is used. Each control is a decision your team can verify in its own environment.

Inventory certificate stores and key locations

Start by listing every place a certificate with a private key lives: user and machine certificate stores on Windows, keystores and key directories on Linux and macOS, and signing material held by the identity provider. Record the owner, purpose and export status of each one. Without this inventory, audit rules and encryption settings cover only the stores someone remembered. Ask which stores allow private key export and whether any service accounts hold keys they do not need.

Audit certificate store and IdP changes

Enable audit logging for changes to certificate stores, trust anchors and identity provider signing configuration. Alerts should fire on new trusted roots, changed certificate policies, new signing keys or certificates added to an identity provider, and changes to who may manage them. Confirm that these events reach your central log platform, such as Wazuh, with retention long enough to investigate a forged certificate discovered weeks after issuance.

Encrypt private keys at rest

Private keys stored as plain files are the easiest material to steal. Require that key files are encrypted with a passphrase or a key management service, and that access to the decryption path is limited to the service that needs it. Confirm that backups, configuration management repositories and container images do not carry unencrypted key material. Check that encryption protects the key itself, not only the disk it sits on.

Use hardware-backed key storage

Where the platform supports it, store signing keys in a hardware security module, a TPM, or a cloud key management service so that the private key cannot be exported in usable form. Ask your vendor or platform owner which keys can be generated inside the module and which must be imported. Keys that are imported or software-generated remain copyable, so treat them as higher risk and monitor their use closely.

Restrict who can export keys

Limit private key export to a named set of administrators and make export a logged, approved action. Review group memberships that grant export rights on Windows certificate stores, and file permissions on key directories elsewhere. Remove export rights from general administrator groups where they are not needed. Alert on export events and on key reads by processes outside the expected service, because these are the actions that turn a local compromise into a reusable forged certificate.

Train administrators on certificate requests

User Training (M1017) fits here for the small group who approve certificate requests, manage identity provider settings or handle exported keys. Teach them to verify unexpected certificate or trust changes through a second channel before approving them, and to report requests that arrive out of process. Keep the training short, tied to your own change procedures, and repeated when those procedures change.

Triage steps when a certificate detection fires

When a T1649 certificate detection fires, the first decision is whether the certificate is legitimate, and that check comes before any revocation. Compare the certificate's subject, issuer, serial number and thumbprint against your internal certificate authority inventory and against the enrollment record for the account or host involved. Confirm whether the issuance matches an expected request from the identity team, a certificate enrollment policy or a known automation job. Where the detection came from a Windows Active Directory Certificate Services issuance event, check whether the requesting identity, the template and the requested subject alternative names fit the template's documented purpose. Record the answer as a finding with the evidence used, because the rest of the triage depends on it.

Once legitimacy is in question, identify every host and account that presented or used the certificate. For smart card or certificate-based sign-in, pull the User Account Authentication records from the identity provider and the domain controllers for the affected subject, and list each sign-in that used the certificate thumbprint, source host and time window. Use File Access and Process Creation telemetry from the endpoint where the certificate's private key was reportedly exported or accessed to establish the scope. Decide whether a certificate should be revoked by weighing three things: whether the private key may have left a protected store, whether the certificate grants access to privileged or federated resources, and whether you can reissue it without disrupting critical services. Revocation publishes status through your certificate revocation infrastructure, so confirm that your relying parties check it. Escalate to the incident commander and identity owners when the certificate is tied to an administrator, a service account or a federation signing or token issuing certificate. Rotating a trust anchor or a token signing certificate is a broader change that affects every relying party, so plan it with the application owners and preserve the current state first. Before making any changes, export the certificate records, identity provider session logs and relevant host artifacts to write-once storage with hashes, so the evidence survives the remediation.

Rehearsing T1649 detection in a private cyber range

In a private range, build a small Active Directory forest with an enterprise certificate authority, a file share holding exported certificate material for the exercise, and a SIEM collecting Windows security events, certificate service events and file access auditing. The facilitator plans injects such as an unexpected certificate request from a user account that normally never enrolls, and access to a certificate file by a process outside its usual path. Good detection means the SIEM raises an alert tied to the requesting identity, the host and the certificate template within minutes, and that the analyst can see the chain from file access to issuance. Good response means a ticket records the affected account, the serial number and the template, the responder revokes the certificate through the CA, publishes the updated revocation list, and confirms that services relying on it reject the old certificate. Illustrative check: the team should be able to name the CA administrator who approved the revocation and the time it took effect.

Range topology: one domain controller, one issuing CA, one file server and one client workstation, all isolated from production networks.
Injects: an enrollment request outside the normal population and a copy of a certificate file read by an unexpected process.
SIEM signals: certificate request and issuance events, file access audit events and account logon events correlated by account name.
Ticket content: affected identity, certificate serial number, template name, host and the first observed time.
Revocation drill: revoke, publish the revocation list, and verify rejection from a test service.

Confirm the exact event IDs and audit policy settings against your Windows Server version before writing rules.

Practitioner questions about detecting T1649

How do I cut file access noise on certificate stores without losing T1649 signal?

Start by scoping File Access telemetry to the certificate and private key locations that matter on each platform, then baseline which processes and service accounts read them during normal operations. Most noise comes from backup agents, endpoint security products, browsers and certificate lifecycle tools, so exclusions should be tied to a named process, signed binary and account, not to a folder alone. Review exclusions on a fixed schedule and record who approved each one. Test the tuned rule in the range with a benign, scripted access pattern so you can confirm the alert still fires after tuning. Confirm with your platform team which File Access events your Windows and Linux agents actually collect at the path level before writing the rule.

Do identity provider logs show certificate-based logins for T1649?

They can, but only if certificate-based authentication is enabled and logged in a way your pipeline captures. The User Account Authentication data component and Application Log Content are the telemetry types ATT&CK's detection strategies most often reference for this area, so check whether your identity provider records the authentication method, the certificate issuer and the requested account for each sign-in. Many deployments log the method in a field that must be parsed explicitly, and some do not record the issuer at all. Ask your identity provider vendor which fields are emitted for certificate logins and whether they are available through your log export. Map those fields to your detection logic only after you have confirmed them in a test tenant.

How should I handle sub-technique coverage across ATT&CK versions?

Record the ATT&CK version each detection maps to, and review the mapping whenever MITRE publishes a new release. Releases can rename, deprecate or revoke techniques and sub-techniques, so a rule that matched an older ID may need a new mapping or retirement. Keep a version field in your rule metadata and a change log that names the release reviewed. Check the sub-technique list against the STIX bundle for the version you target instead of relying on memory or secondary summaries. Confirm the current technique and sub-technique IDs for T1649 directly on the MITRE ATT&CK site before you lock a coverage map.

How do I keep T1649 detections aligned with ATT&CK v20.0?

Pin your detection repository to the v20.0 Enterprise content, then diff each detection's technique and data component references against the STIX bundle for that version. ATT&CK v18 moved detections into detection strategies and analytics, and changed data component IDs, so older rule references may point to retired structures. Keep a mapping table that links each Sigma or Wazuh rule to its detection strategy ID and the data components it relies on. Schedule a review after each release and log which rules changed. Ask your detection engineering lead to confirm the v20.0 bundle is the one your team uses, since the release date and version details should come from MITRE's own update notes.

How do I measure T1649 detection coverage in a cyber range?

Measure coverage by running scripted, benign test scenarios for each platform in scope, then checking whether the expected alert reaches the SIEM within the time your SOC has agreed to. Record a pass or fail per scenario, the telemetry source involved and the rule version that fired. Cover Windows, Linux, macOS and the identity provider separately, because the data sources differ. Keep the test cases in version control so you can rerun them after each rule change or ATT&CK release. Treat the results as evidence of your own detection pipeline, not as an independent assessment, and tell your auditors or assessors exactly what the range did and did not exercise.

Which mitigations should I verify before relying on T1649 detections?

Verify the two mitigations ATT&CK maps to this technique, Audit and Encrypt Sensitive Information, because detections depend on them. Audit determines whether file access and authentication events are generated at all, so confirm the audit policy or equivalent logging settings on each host and identity system. Encrypt Sensitive Information reduces the value of stolen key material, so confirm where private keys are stored, who can read them and whether hardware or OS-protected stores are used where supported. Document the current state of each control with a dated configuration export. Ask your platform team to confirm the exact settings for your operating systems and identity product, since these vary by version.

Can my team run T1649 detection and response rehearsals ourselves?

Yes, if you have a lab that mirrors your logging pipeline, a SIEM and a way to run controlled, benign test activity, but the work takes skilled time. Your team needs to build the test scenarios, isolate them from production, confirm telemetry, and review the results with the SOC. Many teams find it useful to have an outside party review the scope and the evidence, which is a service DeployOpen offers through fixed-scope engagements in a private cyber range. Ask any provider to state in writing which platforms, telemetry sources and detection rules are in scope, and who owns the findings.

How DeployOpen builds and tests T1649 detections

Detection work for T1649 Steal or forge authentication certificates starts with a written scope that names the platforms in play, which telemetry is available on each one, and which systems are out of bounds for testing. For this technique that usually means agreeing in advance which certificate stores, identity provider signing and token services, and certificate authority logs the client can export, and who approves any test activity against production hosts. The scope also records which logs are retained and for how long, because a detection that depends on a short retention window will fail a later review. Most engagements are fixed-scope, so the agreed deliverables, the platforms covered and the exclusions are fixed before any rule is written. Confirm with your own team which data sources you can actually collect today, since that list decides what can be detected at all.

Once the scope is agreed, detection logic is mapped to a named ATT&CK version. DeployOpen targets the Enterprise matrix version your team has chosen, and records that version in every rule header and mapping sheet, because technique IDs, detection strategies and data component references can change between releases. The mapping links each analytic to the data components that support it, such as File Access (DC0055) and Application Log Content (DC0038), and to the mitigations your organization intends to rely on, including Audit (M1047) and Encrypt Sensitive Information (M1041). Rules are written as Sigma or platform-native logic where the client's SIEM requires it, and each one is reviewed for the specific certificate paths, service accounts and admin tooling already present in the environment, so that known legitimate activity is documented as an exception rather than silently excluded.

Rules are then exercised in a private cyber range that mirrors the client's logging configuration, with benign certificate activity and controlled test events replayed so that true positives, false positives and missing telemetry can be measured. The range results drive tuning, and the handover package includes the tuned rules, their version mapping, the data source dependencies, known blind spots, and a response runbook covering triage, certificate revocation and reissuance decisions, and evidence capture. Your team should ask for the test records, the list of unresolved gaps, and the named owner for each runbook step before accepting the work. DeployOpen supports these deliverables as readiness evidence for compliance assessments, but independent auditors and certification bodies make the assessment decisions.

How DeployOpen builds purple team exercises for certificate abuse

DeployOpen approaches T1649 Steal or Forge Authentication Certificates as a joint exercise between your detection engineers and our testers, run inside your own environment or a private cyber range. Each engagement is scoped in writing, built on open-source telemetry you already collect or can deploy, and handed over with documentation your team can keep running.

How we scope

Written scope names the platforms in play, such as Windows, Linux, macOS and your identity provider, before any work starts.
We confirm which telemetry exists for File Access, Application Log Content and Command Execution, and where gaps need closing.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before the exercise begins.

How we build

We build detection logic for Wazuh, Security Onion or your chosen stack, described in words and mapped to the ATT&CK version you target.
Exercise scenarios run in a private cyber range that mirrors your certificate stores, identity provider and log pipeline.
Each detection is validated against the exercise, with false positives and missed events recorded for tuning.

How we hand over

Deliverables include detection rules, mapping to the relevant mitigations such as Audit and Encrypt Sensitive Information, and validation results.
Response runbooks cover triage, certificate revocation steps and evidence preservation, written for your analysts.
Your team receives a rehearsal plan so the exercise can be repeated after tuning or ATT&CK updates.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Retainers can cover re-running certificate abuse scenarios when your environment, identity provider or ATT&CK mappings change.
Ask for a quote built from the written scope, which sets out one-time build work separately from recurring support.

T1649 Steal or forge authentication certificates