Credential file search
A filesystem search tool (find, grep, locate, rg, ag) was run against patterns that only make sense if the goal is credentials: private-key…
What it detects
A filesystem search tool (find, grep, locate, rg, ag) was run against patterns that only make sense if the goal is credentials: private-key extensions (.pem, .key, .pfx, .p12), SSH key names (id_rsa, id_ed25519), GPG and keyring paths, password-manager databases (.kdbx, KeePass config), HashiCorp .vault-token, or the words password/credential/creds used as a search pattern.
This is the sweep that happens after a foothold and before lateral movement: an attacker who has landed on a host asks the filesystem where the keys are, because a stolen key is quieter and longer-lived than a stolen password. The individual commands are unremarkable; what makes it a finding is a search whose target set is exactly "things that unlock other systems".
MITRE ATT&CK mapping
False positives and triage
Developers and administrators grep for the word "password" all the time — in a config repository, in application logs, while debugging an auth failure. On a workstation or a build box this rule is a hunting signal, not an alert; on a production server with no interactive users it is much closer to a finding.
Work through it in this order:
* Whose session. A search run by a service account, or by a login uid that does not normally log in interactively, is the interesting case. * Where it ran. grep -r password in a checked-out repo is development; the same search rooted at /, /home or /etc is enumeration. * What came next. Credential discovery is a means, not an end — look for the SSH session, sudo, or outbound connection that follows it. Discovery alone with no follow-on is usually noise; discovery followed by movement is the intrusion.
Tune by excluding known development paths and CI workspaces rather than by dropping patterns from the list: the key-file extensions are the low-noise half of this rule and removing them would leave only the noisy half.
The rule
Declarative YAML read by the detection engine — data, never executed. Confidence 50%. Source: rules/linux/credential_file_search.yaml, licensed under the Apache License 2.0.
id: linux.credential_access.credential_file_search
version: 1.0.0
status: stable
severity: medium
confidence: 0.5
platforms: [linux]
mitre_techniques: [T1552.004, T1555.005, T1552.001]
description: |
A filesystem search tool (`find`, `grep`, `locate`, `rg`, `ag`) was run against
patterns that only make sense if the goal is credentials: private-key extensions
(`.pem`, `.key`, `.pfx`, `.p12`), SSH key names (`id_rsa`, `id_ed25519`), GPG and
keyring paths, password-manager databases (`.kdbx`, KeePass config), HashiCorp
`.vault-token`, or the words password/credential/creds used as a search pattern.
This is the sweep that happens after a foothold and before lateral movement: an
attacker who has landed on a host asks the filesystem where the keys are, because
a stolen key is quieter and longer-lived than a stolen password. The individual
commands are unremarkable; what makes it a finding is a search whose target set is
exactly "things that unlock other systems".
match:
command_line_regex: '(?i)\b(find|grep|egrep|fgrep|rg|ag|locate|ripgrep)\b[^\n]*(\.pem|\.pfx|\.p12|\.kdbx|\.jks|\.keyring|\.vault-token|\.gnupg|\.gpg\b|\.pgp\b|id_rsa|id_dsa|id_ecdsa|id_ed25519|authorized_keys|keepass|\bcreds?\b|credential|password)'
false_positive_guidance: |
Developers and administrators grep for the word "password" all the time —
in a config repository, in application logs, while debugging an auth failure. On a
workstation or a build box this rule is a hunting signal, not an alert; on a
production server with no interactive users it is much closer to a finding.
Work through it in this order:
* Whose session. A search run by a service account, or by a login uid that does not
normally log in interactively, is the interesting case.
* Where it ran. `grep -r password` in a checked-out repo is development; the same
search rooted at `/`, `/home` or `/etc` is enumeration.
* What came next. Credential discovery is a means, not an end — look for the SSH
session, `sudo`, or outbound connection that follows it. Discovery alone with no
follow-on is usually noise; discovery followed by movement is the intrusion.
Tune by excluding known development paths and CI workspaces rather than by dropping
patterns from the list: the key-file extensions are the low-noise half of this rule
and removing them would leave only the noisy half.
Related detections
Run this rule on your own logs — offline
KIROSEC runs this rule and the rest of the library over Windows, Linux, macOS and cloud audit logs on the analyst's own machine. Every alert links to the events that raised it, and nothing leaves the device.