Loading

Modification of WDigest Security Provider

Identifies attempts to modify the WDigest security provider in the registry to force the user's password to be stored in clear text in memory. Windows 8.1+ and Server 2012 R2+ disable WDigest plaintext credential caching by default, but setting UseLogonCredential to 1 re-enables it, causing LSASS to retain cleartext passwords for subsequent interactive logons. Adversaries abuse this to prepare for credential dumping from LSASS memory.

Rule type: eql
Rule indices:

  • winlogbeat-*
  • logs-endpoint.events.registry-*
  • logs-windows.sysmon_operational-*
  • endgame-*
  • logs-m365_defender.event-*

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
  • Resources: Investigation Guide
  • Data Source: Elastic Endgame
  • Data Source: Elastic Defend
  • Data Source: Sysmon
  • Data Source: Microsoft Defender XDR

Version: 217
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:

  • Is the write to the active ControlSet, and does host context explain enablement?

    • Focus: registry.path, registry.data.strings, and host.id.
    • Implication: escalate when the active ControlSet is enabled, leaving cleartext credentials in LSASS for later logons; lower suspicion only for a recognized lab or legacy compatibility host with the exact expected pattern.

  • Which process made the change, and does its identity fit?

    • Focus: process.executable, process.command_line, process.code_signature.subject_name, and process.parent.command_line. $investigate_0
    • Hint: pivot on host.id plus process.entity_id; if absent, bound to alert time and host.
    • Implication: escalate when the writer is unsigned, user-writable, renamed, script-launched, or has an unrelated parent; lower suspicion only when identity, parent, and registry outcome match one recognized validation activity. Trusted signer alone is not clearance.

  • Does user and session context explain the change?

    • Focus: user.id, user.domain, process.Ext.session_info.logon_type, and process.Ext.token.integrity_level_name.
    • Implication: escalate when a normal user, unexpected admin, service account, remote session, or elevated token performs the write outside a recognized test path.

  • Did the same process leave WDigest enabled or change adjacent security registry state?

    • Focus: registry events from the same process.entity_id: registry.path, registry.value, and registry.data.strings. $investigate_1
    • Hint: check for WDigest reversal and LSA or SecurityProviders changes before widening to the host.
    • Implication: escalate when WDigest stays enabled or the writer weakens LSA or security-provider settings; scope narrower when the write is isolated, promptly reversed, and no contradictory registry evidence remains.

  • Does process activity after the write show credential-dumping preparation or execution?

    • Focus: child process events from process.entity_id: process.executable and process.command_line. $investigate_2
    • Implication: escalate when children show Mimikatz/sekurlsa, ProcDump or comsvcs.dll LSASS dumping, CrackMapExec, PowerShell remote execution, archives, or cleanup; absent follow-on evidence narrows extraction proof but does not clear enablement.

  • Did any accounts authenticate while WDigest was enabled?

    • Focus: logon events after @timestamp: event.code 4624, winlog.event_data.TargetUserName, winlog.event_data.AuthenticationPackageName, winlog.logon.type, and source.ip. $investigate_3
    • Hint: expand until WDigest is disabled or the host is contained; for domain NTLM, search domain-controller 4776 records for the alert host as source workstation.
    • Implication: escalate credential exposure when successful WDigest or privileged logons occur after enablement. Missing authentication telemetry is unresolved, not benign.

  • If local evidence is suspicious or unresolved, do related alerts change scope?

    • Focus: alerts for user.id, especially credential access, privilege escalation, or lateral movement. $investigate_4
    • Hint: compare host alerts for precursor access, LSASS-oriented follow-on, staging, or cleanup. $investigate_5
    • Implication: broaden when the same user or host shows adjacent post-compromise behavior; keep local when related alerts are quiet and local evidence fits one recognized workflow.

  • Escalate when writer identity, session context, registry changes, unreverted WDigest exposure, follow-on activity, or related alerts indicate unauthorized credential-protection weakening; close only when those categories align with one confirmed activity and no contradictions remain; preserve and escalate when evidence is mixed or incomplete.

  • Authorized security validation or legacy compatibility testing may enable WDigest. Confirm process.executable, process.command_line, process.parent.command_line, user.id, host.id, registry.data.strings, prompt reversion, and no contradictory registry or LSASS-oriented follow-on. If telemetry cannot prove the activity, leave unresolved.
  • Build exceptions from the minimum confirmed workflow: process.executable or signer, process.parent.command_line, user.id, host.id, registry.path, and expected registry.data.strings. Avoid exceptions on registry.path, process.name, signer, or host.id alone.
  • If confirmed benign, reverse any temporary containment, document the aligned workflow evidence, and create an exception only when the confirmed evidence pattern is expected to repeat and can be scoped narrowly.
  • If suspicious but unconfirmed, preserve the alert, process tree, command lines, relevant registry events, related-alert results, and current WDigest state before containment. Apply reversible containment first, such as heightened monitoring or EDR network restrictions, and use host isolation only when follow-on dumping, unreverted exposure on a sensitive host, or broader compromise evidence justifies the operational impact.
  • If confirmed malicious, preserve the writer process.entity_id, process tree, command lines, registry evidence, and current WDigest state; then isolate the host when the evidence supports it, restore WDigest to the disabled state, and eradicate only the scripts, binaries, registry changes, and persistence found during the investigation.
  • After containment, review other registry changes by the same process and scope accounts that may have authenticated while WDigest was enabled through available authentication records; when those records are unavailable, treat credential exposure as unresolved and prioritize privileged, service, and lateral-movement-capable accounts for credential hygiene.
  • Post-incident hardening: restrict who can modify WDigest and related LSA policy, validate baseline configuration through endpoint or policy management, retain registry and process telemetry for this host class, and document the confirmed workflow or malicious pattern for future analysts.
registry where host.os.type == "windows" and event.type in ("creation", "change") and
    registry.value : "UseLogonCredential" and
    registry.path : "*\\SYSTEM\\*ControlSet*\\Control\\SecurityProviders\\WDigest\\UseLogonCredential" and
    registry.data.strings : ("1", "0x00000001") and
    not (process.executable : "?:\\Windows\\System32\\svchost.exe" and user.id : "S-1-5-18")

Framework: MITRE ATT&CK

Framework: MITRE ATT&CK