Command line naming a credential vault or password store file

Siemphony@siemphonymediumT1555unverified

Matches the command-line leg of MITRE's AN1198 — a process created with a password-store location on its command line — and spans the stores rather than picking one: the DPAPI master key directory that unlocks the rest, the Credential Manager and Vault blob directories, the browser credential databases and password-manager database files, plus the vaultcmd and dpapi module keywords MITRE's KeywordPatterns knob points at, with the values themselves authored here. Being the parent technique's rule it necessarily overlaps its sub-techniques, because at this level of ATT&CK there is no observable that is credential access from password stores in general rather than from one particular store; breadth across several stores in one selection is the only thing that makes it a parent rule at all, and browser session cookies are left out on purpose because the published T1539 rule already matches those paths. The brief also offers a file-access leg, but it maps Security EventID 4663 onto the Sysmon-shaped file_event category, and 4663 carries ObjectName and ProcessName rather than TargetFilename, so that feed needs a field mapping before anything written against it can match — this rule uses the Sysmon EventID 1 process_creation vocabulary and does not touch it. Only the name-it-on-the-command-line variant is visible this way: a stealer that opens the same files through the Win32 API, or that reads them out of a process it already controls, produces no command line to match. UNVERIFIED AS AUTHORED — derived from MITRE ATT&CK DET0430, 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 (ProcessCommandLine contains "\\Microsoft\\Protect\\" or ProcessCommandLine contains "\\Microsoft\\Credentials\\" or ProcessCommandLine contains "\\Microsoft\\Vault\\" or ProcessCommandLine contains "\\Login Data" or ProcessCommandLine contains "logins.json" or ProcessCommandLine contains "key4.db" or ProcessCommandLine contains ".kdbx" or ProcessCommandLine contains "vaultcmd" or ProcessCommandLine contains "dpapi::")

Splunk · SPL

Run this as a search.

index=* (CommandLine="*\\Microsoft\\Protect\\*" OR CommandLine="*\\Microsoft\\Credentials\\*" OR CommandLine="*\\Microsoft\\Vault\\*" OR CommandLine="*\\Login Data*" OR CommandLine="*logins.json*" OR CommandLine="*key4.db*" OR CommandLine="*.kdbx*" OR CommandLine="*vaultcmd*" OR CommandLine="*dpapi::*")

Elastic · ES|QL

Run this as a search.

FROM logs-*| WHERE (TO_LOWER(process.command_line) LIKE "*\\\\microsoft\\\\protect\\\\*" OR TO_LOWER(process.command_line) LIKE "*\\\\microsoft\\\\credentials\\\\*" OR TO_LOWER(process.command_line) LIKE "*\\\\microsoft\\\\vault\\\\*" OR TO_LOWER(process.command_line) LIKE "*\\\\login data*" OR TO_LOWER(process.command_line) LIKE "*logins.json*" OR TO_LOWER(process.command_line) LIKE "*key4.db*" OR TO_LOWER(process.command_line) LIKE "*.kdbx*" OR TO_LOWER(process.command_line) LIKE "*vaultcmd*" OR TO_LOWER(process.command_line) LIKE "*dpapi::*")

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. -->  <rule id="100000" level="7">    <!-- Set <if_sid> to the decoder/base rule for windows so this only evaluates relevant events. -->    <field name="CommandLine" type="pcre2">(?i)(\\Microsoft\\Protect\\|\\Microsoft\\Credentials\\|\\Microsoft\\Vault\\|\\Login Data|logins\.json|key4\.db|\.kdbx|vaultcmd|dpapi::)</field>    <description>Command line naming a credential vault or password store file</description>    <mitre>      <id>T1555</id>    </mitre>  </rule></group>

At a glance

Logsource: process_creation / windows
Level: medium
Category: credential_dump
Sigma status: experimental
Backends: 4 of 4 rendered
Updated: 30 Aug 2026
Rule ID: 9adc6b5e-9c60-483f-981f-17c443143227

ATT&CKT1555

T1555Credentials from Password Stores

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.

Lessoncredential dump

credential dumpAI draft — unreviewed

01 · What this rule detects

AN1198 describes correlated process-to-process access (Mimikatz reaching LSASS) and file reads against password stores, paired with execution of non-standard processes. This rule keeps neither correlation — it's a single process_creation selection matching a password-store location named on a command line. Being T1555's parent-technique rule, it deliberately spans several stores in one selection rather than picking one, because at this level there is no single observable that means "credential access from password stores in general." The description is explicit that this is the only variant visible this way: a stealer reading these same files through the Win32 API, or from inside a process it already controls, leaves no command line to match.

02 · Telemetry you need

category: process_creation, product: windows — Sysmon EventID 1, the vocabulary AN1198's fourth log source supplies. The brief also offers a file-access leg over Security EventID 4663, but the description flags a real trap: 4663 carries ObjectName and ProcessName, not the file_event category's TargetFilename, so that feed needs a field mapping before anything written against it could match — this rule doesn't touch it.

03 · How the logic works

One selection, CommandLine|contains, against nine values covering four stores. DPAPI: \Microsoft\Protect\. Credential Manager and Vault: \Microsoft\Credentials\, \Microsoft\Vault\, vaultcmd. Browser credential databases: \Login Data, logins.json, key4.db. Password managers: .kdbx. Plus dpapi::, a Mimikatz module-invocation keyword. MITRE's KeywordPatterns knob names the kind of pattern to watch for; every value populating it here is the rule author's own list. Browser session cookies are left out on purpose — the description notes the published T1539 rule already covers that path.

04 · Common false positives

The rule's own first false positive names its dominant source directly: a password manager opened by its own user puts the .kdbx path on the command line on every launch, and in any estate that deploys one, that's the highest-volume match by a long way — the stated reason for level: medium. The review treats this as more than a disclosed cost: with zero filter blocks in the rule, that volume is unmitigated, not merely described. It also surfaces a false positive the list misses: DFIR triage collectors. KAPE, CyLR and Velociraptor target definitions name \Microsoft\Protect\, \Microsoft\Credentials\, Login Data and key4.db as literal collection arguments, so routine or automated triage fires this rule on every collection against every profile — a security tool tripping the security rule.

05 · Detection maturity

tier_1: . Reasoned from a MITRE scaffold with no query logic, never run against a log line. Tracing it forward on paper says a Mimikatz `dpapi::` invocation or a raw `copy "Login Data"` would land in the list — that's analysis, not verification.
tier_2: run read-only, add the vault-client exclusion above, and rank surviving hits by parent image to separate installer/backup/DFIR tooling from anything unexplained before touching the level.
tier_3: ** build MITRE's dropped process-access correlation (LSASS/DPAPI/Vault handle access joined to the matching command line) as a companion rule, so a hit means credential extraction rather than a file path mentioned in an argument.

Tuning & false positivesexperimental · 4 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 review's concrete fix: add a filter excluding the vault client's own image — Image|endswith: ['\KeePass.exe', '\KeePassXC.exe', '\1Password.exe'] under condition: selection and not filter_vault_client. That costs one block, removes the stated dominant volume, and loses nothing an adversary does, since copying a .kdbx uses copy, robocopy, or PowerShell, not the vault client itself. Without that filter, the review's own math argues for level: low rather than medium. Separately, '\Login Data' requires a leading backslash to match, so cd into the browser profile first and reference the file by bare name and it never matches — while 'logins.json' and 'key4.db' are unanchored and would still catch the same maneuver; drop the leading backslash for consistency. Last, understand this rule will double-fire once T1555.003/.004/.005 rules exist in the corpus, since every value here belongs to one of those sub-techniques — that's a known, accepted superset, not a bug to fix later.

Declared by the author

A password manager opened by its own user, which puts the .kdbx database path on the command line every time the database is double-clicked or the client is relaunched from a shortcut. In any estate that deploys one this is the rule's highest-volume match by a long way, and it is why the level is medium rather than high.
Backup, endpoint-DLP and profile-migration agents that walk the user profile by absolute path and name the Protect or Credentials directory as an argument. The event is byte-for-byte what a harvester produces and only the parent process and the schedule separate them.
Administrators and helpdesk scripts running vaultcmd to inventory or clear a stale saved credential, and the logon and logoff scripts on VDI and roaming-profile estates that reset the credential store on a fixed schedule across every session.
Browser profile repair scripts and browser automation harnesses pointed at a seeded profile directory, both of which name Login Data or key4.db on the command line during ordinary support work and ordinary builds.

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, evaluated against their process_creation events.

Share this rule

/u/siemphony/9adc6b5e-9c60-483f-981f-17c443143227

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.

Command line naming a credential vault or password store file

The detection

detection.yml

Sentinel · KQL

Splunk · SPL

Elastic · ES|QL

Wazuh · XML rule

Community

Verdicts from engineers who deployed it