Loading

Creation or Modification of Domain Backup DPAPI private key

Identifies the creation or modification of Domain Backup private keys. Adversaries may extract the Data Protection API (DPAPI) domain backup key from a Domain Controller (DC) to be able to decrypt any domain user master key file.

Rule type: eql
Rule indices:

  • winlogbeat-*
  • logs-endpoint.events.file-*
  • logs-windows.sysmon_operational-*
  • endgame-*
  • logs-sentinel_one_cloud_funnel.*
  • logs-m365_defender.event-*
  • logs-crowdstrike.fdr*

Rule Severity: high
Risk Score: 73
Runs every:
Searches indices from: now-9m
Maximum alerts per execution: 100
References:

Tags:

  • Domain: Endpoint
  • OS: Windows
  • Use Case: Threat Detection
  • Tactic: Credential Access
  • Data Source: Elastic Endgame
  • Data Source: Elastic Defend
  • Data Source: Sysmon
  • Data Source: SentinelOne
  • Data Source: Microsoft Defender XDR
  • Data Source: Crowdstrike
  • Resources: Investigation Guide

Version: 418
Rule authors:

  • Elastic

Rule license: Elastic License v2

This rule is designed for data generated by Elastic Defend, which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules.

Setup instructions: https://ela.st/install-elastic-defend

This rule also supports the following third-party data sources. For setup instructions, refer to the links below:

  • Does the alert show a new or changed domain DPAPI backup key artifact?

    • Focus: event.type, event.action, file.name, file.path, and file.size; distinguish ntds_capi_*.pfx or ntds_capi_*.pvk in temp, user, share, removable, archive, or controlled recovery paths.
    • Implication: escalate on create or modify activity in staging paths or analyst home directories because the artifact can unlock domain DPAPI-protected secrets; lower suspicion only when the path is a controlled DC recovery or IR location tied to the same case.

  • Is the acting process a recognized recovery tool or an export utility being abused?

    • Why: live DC retrieval and offline AD database extraction both create domain-scale DPAPI exposure once backup keys leave controlled recovery.
    • Focus: process-start events scoped by host.id and process.entity_id, checking process.executable, process.command_line, process.pe.original_file_name, process.parent.command_line, and process.code_signature.subject_name. $investigate_0
    • Implication: escalate when a shell, script host, renamed binary, or command line expresses backup-key export outside controlled recovery; lower concern only when tool identity, parent, and output path fit one controlled recovery workflow.

  • Did the same process export companion key material or package the result?

    • Focus: file events scoped to process.entity_id, or host.id plus process.pid in a tight time window, checking file.name, file.path, file.Ext.original.path, and file.Ext.original.name. $investigate_1
    • Implication: escalate when the process creates multiple backup-key outputs, writes companion legacy-key material, renames the files, archives them, or stages other credential-sensitive artifacts.
    • Hint: if ntds_capi_* disappears quickly, trace rename events through file.Ext.original.path and file.Ext.original.name; if those fields are absent, fall back to current file.path plus the same process.entity_id or host/PID time window.

  • Do the user and host telemetry fit a tightly scoped recovery operator path?

    • Focus: user.id, user.name, user.domain, host.id, and host.name; separate domain recovery, backup, or IR identities from standard users and ad hoc workstations.
    • Implication: escalate when the user or host identity is mismatched, generic, or unexplained for domain backup-key handling; treat a plausible operator and host pairing as candidate benign only after the file, process, and artifact evidence also fit the same workflow.

  • Did follow-on activity stage the export for off-host use?

    • Focus: process, child-process, file, and network events for the recovered process scope, especially process.command_line, process.parent.command_line, UNC, removable-media, archive, or share values in file.path, and off-host connections. $investigate_4 $investigate_5
    • Implication: escalate when copy, archive, compression, removable-media, or share-write activity follows the export, especially from a non-DC host; absence of staging evidence narrows scope but does not close the alert by itself.

  • If local evidence remains suspicious or unresolved and related-alert telemetry is available, does the same user or host show credential-access, staging, or tier-0 alerts?

    • Focus: optional related-alert views for user.id, especially DPAPI abuse, LSASS or credential dumping, DCSync, archive or share staging, lateral movement to DCs, or tier-0 persistence. $investigate_2
    • Hint: Pivot by host.id when user scope is sparse or host role changes urgency; absence of related-alert telemetry is unresolved, not benign. $investigate_3
    • Implication: broaden to domain-compromise scoping when related alerts show credential access, DC access, or staging around the same time; absence of related alerts can narrow scope but must not close the alert without local file, process, artifact, and context alignment.

  • Escalate on unrecognized export path, export-tool intent, companion artifacts, mismatched user or host, staging, or corroborating tier-0 alerts; close only when telemetry and recovery, backup, or IR verification bind one controlled workflow; preserve and escalate if evidence is mixed or visibility is incomplete.

  • AD disaster-recovery, backup validation, or IR collection can legitimately export DPAPI domain backup material. Confirm telemetry first: process.executable, process.command_line, file.path, user.id, and host.id must all align with the same exact workflow.
  • Use a recovery ticket, backup job, or IR case only to verify an already aligned telemetry pattern; do not close on records alone. If records are unavailable, recurring telemetry is a candidate benign pattern, not closure, until it verifies one controlled recovery path without contradictory staging.
  • Before creating an exception, validate that the same process.executable, process.command_line, file.path, user.id, and host.id recur across prior alerts from this rule. Build the exception from that confirmed workflow, and avoid exceptions on file.name alone, .pvk or .pfx extensions alone, or the host alone.
  • If confirmed benign, reverse any temporary containment and record the process path, command-line pattern, export location, operator identity, and host role that justified closure. Create an exception only if that same workflow recurs consistently across prior alerts from this rule.
  • If suspicious but unconfirmed, preserve the exported file.path, rename evidence from file.Ext.original.path or file.Ext.original.name, the file-event timeline, recovered process.entity_id or process.pid, process.command_line, responsible user.id, host.id, and any UNC, removable-media, archive, or share paths before destructive changes. Apply reversible containment first, such as temporarily restricting share access or outbound connectivity for the affected host.id; escalate to host isolation or account containment only if companion staging, corroborating alerts, or other findings show broader compromise and the asset role can tolerate it.
  • If confirmed malicious, preserve the same artifacts and use endpoint response to isolate the host or terminate the responsible process. If direct response is unavailable, escalate with the preserved artifact set to the team that can act. For domain controllers, weigh service impact before isolation but do not leave the export accessible.
  • If unauthorized domain backup-key export is confirmed on a domain controller, activate the organization's Active Directory compromise response plan, preserve evidence needed to scope DPAPI-protected credential exposure, and begin privileged-account hygiene according to that plan.
  • Before deleting or rotating anything, review related host.id and user.id activity for the same exported filenames, companion legacy-key artifacts, archive names, and UNC or share paths. Then eradicate the unauthorized export files, staging archives, copy utilities, scripts, and persistence mechanisms uncovered during the investigation, and remediate the privilege path or access vector that allowed the export.
  • After containment, hunt for the same exported filenames, archive names, and UNC or share paths across other hosts.
file where host.os.type == "windows" and event.type != "deletion" and file.name : ("ntds_capi_*.pfx", "ntds_capi_*.pvk")

Framework: MITRE ATT&CK