Credential Manager vault accessed via vaultcmd or keymgr

Siemphony@siemphonyhighT1555.004unverified

Matches process creation of vaultcmd.exe, the built-in command-line tool for listing and managing Windows Credential Manager vaults, or rundll32.exe invoked against keymgr.dll — the classic "Stored User Names and Passwords" applet AN0378 names as the process leg of vault access. Both are the concrete, single-event observable the analytic offers; the API-call leg (CredEnumerateA) produces no Windows event on its own, and the file-access leg the brief maps to Sysmon EventID 15 (create_stream_hash) fires on alternate-data-stream creation, not on a read of an existing .vcrd file, so it cannot carry "someone opened this vault file" either. Security 4688 requires the Audit Process Creation subcategory, and CommandLine on top of that needs the separate Include command line in process creation events policy — neither is on by default. UNVERIFIED AS AUTHORED — derived from MITRE ATT&CK DET0134, not hand-written and not tested by its author. Any lab result is on this rule's own page.Full description

The 4 SIEM queries below are previews produced by Siemphony’s own translator, not pySigma, and none has been executed against a real backend — review before you deploy.

detection.yml

Sentinel · KQL

Run this as a search.

DeviceProcessEvents| where (FolderPath endswith "\\vaultcmd.exe" or (FolderPath endswith "\\rundll32.exe" and ProcessCommandLine contains "keymgr.dll"))

Splunk · SPL

Run this as a search.

index=* (Image="*\\vaultcmd.exe" OR (Image="*\\rundll32.exe" AND CommandLine="*keymgr.dll*"))

Elastic · ES|QL

Run this as a search.

FROM logs-*| WHERE (TO_LOWER(process.executable) LIKE "*\\\\vaultcmd.exe" OR (TO_LOWER(process.executable) LIKE "*\\\\rundll32.exe" AND TO_LOWER(process.command_line) LIKE "*keymgr.dll*"))

Wazuh · XML rule

Deploy to your manager — this is a rule, not a search.

<group name="sigma,windows,process_creation,">  <!-- Rule ids must be unique on your manager; 100000+ is the user range. -->  <!-- 2 rules: the Sigma condition ORs across different fields,       which one rule cannot express. Any one matching is a hit. -->  <rule id="100000" level="12">    <!-- Set <if_sid> to the decoder/base rule for windows so this only evaluates relevant events. -->    <field name="Image" type="pcre2">(?i)\\vaultcmd\.exe$</field>    <description>Credential Manager vault accessed via vaultcmd or keymgr (1/2)</description>    <mitre>      <id>T1555.004</id>    </mitre>  </rule>   <rule id="100001" level="12">    <!-- Set <if_sid> to the decoder/base rule for windows so this only evaluates relevant events. -->    <field name="Image" type="pcre2">(?i)\\rundll32\.exe$</field>    <field name="CommandLine" type="pcre2">(?i)keymgr\.dll</field>    <description>Credential Manager vault accessed via vaultcmd or keymgr (2/2)</description>    <mitre>      <id>T1555.004</id>    </mitre>  </rule></group>

At a glance

Logsource: process_creation / windows
Level: high
Category: browser_credential_theft
Sigma status: experimental
Backends: 4 of 4 rendered
Updated: 30 Aug 2026
Rule ID: 4b164438-0ae7-4412-87ef-f88d877e3cef

ATT&CKT1555.004

T1555.004Windows Credential Manager

ATT&CK® is a registered trademark of The MITRE Corporation. These mappings are the rule author’s, and are neither reviewed nor endorsed by MITRE.

Lessonbrowser credential theft

browser credential theftAI draft — unreviewed

01 · What this rule detects

AN0378 describes three ways to catch Windows Credential Manager abuse: anomalous process execution, suspicious API calls (CredEnumerateA), and direct file access to .vcrd/.vpol Credential Locker files. This rule catches exactly one of those three: process creation. It fires when vaultcmd.exe runs — the built-in CLI for listing and managing vaults — or when rundll32.exe is used to load keymgr.dll, the "Stored User Names and Passwords" applet. It does not see the API leg or the file-access leg at all; those require telemetry this logsource cannot carry, and the description says so explicitly.

02 · Telemetry you need

The logsource is category: process_creation, product: windows, copied from the brief. In practice that means Security EventID 4688, and 4688 is not recorded by default: the Audit Process Creation subcategory has to be enabled, and the CommandLine field the selection_keymgr block depends on needs the separate Include command line in process creation events policy on top of that. Without both, the rule returns zero rows — and zero rows here means blind, not clean.

03 · How the logic works

Two independent selections, joined with 1 of selection* (an OR): - selection_vaultcmd: Image|endswith: '\vaultcmd.exe' - selection_keymgr: Image|endswith: '\rundll32.exe' AND CommandLine|contains: 'keymgr.dll' Either one alone triggers the rule. Notice what's absent: the brief's own analytic description talks about correlating process creation with a subsequent file read of .vcrd/.vpol files, but Sigma as modeled in this corpus's lib/sigma has no aggregation or time-window construct — no | count() by, no near. So this rule can only ever be the precursor signal, not the correlation AN0378 actually describes. That's the norm across this corpus, not a defect specific to this rule: a Sigma rule here flags "this process ran," and a human or a real SIEM has to do the "and then a vault file was touched" join afterward. The two Sysmon-based log sources in the brief (EID 10 process_access, EID 15 create_stream_hash) were deliberately left out too — the reviewer confirmed EID 15 in particular is a dead selector for this purpose, since it fires on alternate-data-stream creation, not on reading an existing .vcrd file, so it structurally cannot carry "someone opened this vault." Also invisible: an adversary calling CredEnumerateA/CredReadA directly from a custom binary or a .NET wrapper never spawns either watched process, so this rule is silent against that path entirely.

04 · Common false positives

Three named, specific false positives, not generic hedging: help-desk staff using the supported rundll32.exe keymgr.dll,KRShowKeyMgr UI during a support call; profile-migration or credential-backup tooling shelling out to vaultcmd.exe /list or /listcreds; and scheduled compliance scripts running a periodic vaultcmd /list inventory sweep. All three are legitimate, documented uses of the exact commands this rule watches for.

05 · Detection maturity

tier_1: UNVERIFIED — the lowest tier in this corpus's maturity model. This rule has never been executed against a single log line. No false-positive rate, hit count, or noise estimate above is measured; treat every claim here as a hypothesis to validate against real data, not a result.

Tuning & false positivesexperimental · 3 declared

experimental (current stage)
test
stable

Written and reasoned about, but not yet run against real telemetry. Expect to tune it before trusting it.

Tuning tips

The brief names three tuning knobs (mutableElements) — MonitoredPaths, TimeWindow, and PrivilegedUsers — but none of them are implemented in this Sigma logic; MITRE names these knobs, this rule doesn't populate any of them, because path scoping and time-window correlation aren't expressible in this Sigma dialect. A human tuning this rule would add those as a downstream correlation layer: cross-reference hits against PrivilegedUsers to suppress known help-desk/service accounts, and pair with file-access telemetry on MonitoredPaths within a TimeWindow to reconstruct what AN0378 actually asks for. level: high reflects that vaultcmd/keymgr invocation is rare outside the three named benign sources — reconsider it if any of those sources turns out to be high-volume in your environment.

Declared by the author

Help-desk technicians using the legacy Stored User Names and Passwords applet (rundll32.exe keymgr.dll,KRShowKeyMgr) to view or remove a saved network credential during a support call — the documented, supported way to reach that UI.
Profile-migration or credential-backup tooling that shells out to vaultcmd.exe /list or /listcreds as part of a Windows-to-Windows user migration.
Security or compliance scripts that run a scheduled vaultcmd /list sweep as a periodic credential inventory check.

Noise check0 of 30 fired

Fires on none of the 30 ordinary behaviours the baseline holds for this log type. That is not a precision guarantee: it means only not caught by these 30 behaviours, and the next ordinary behaviour nobody wrote down may still match.

Run live against 65 hand-written events of ordinary corporate activity — backup agents, software distribution, patching, helpdesk scripts, EDR. It says nothing about how often the rule would fire in production, which is the number that actually exhausts an analyst.

Verification1 run

Not verified

Siemphony benign baseline
completed
Siemphony IR · 3 Sept 2026
No events matched, so this run proves nothing either way.

Test it yourselfin your browser

Runs here in your browser against public attack recordings. A preview — not the verification badge.

Recordings of T1555.004, evaluated against their process_creation events.

Share this rule

/u/siemphony/4b164438-0ae7-4412-87ef-f88d877e3cef

More from this repertoire

All compositions

Verdicts · reactions · comments

Community

Verdicts from engineers who actually deployed it, and the conversation around it.

Not yet reported on

Nobody has run this in a real environment and said what happened.

Verdicts from engineers who deployed it

0 cast

No verdicts reported yet. The first one is worth more than the tenth — say what you ran it against.

No comments yet. Someone who deploys this will have something to say about it.

Credential Manager vault accessed via vaultcmd or keymgr

The detection

detection.yml

Sentinel · KQL

Splunk · SPL

Elastic · ES|QL

Wazuh · XML rule

Community

Verdicts from engineers who deployed it