Sensitive Identity File Open by Suspicious Process via Auditd
Detects Auditd opened-file reads on sensitive root and cluster paths (Kubernetes token mounts, kubelet and admin kubeconfig, PKI material, shadow, root SSH keys, root cloud CLI and Docker config) when the process looks like common copy or scripting utilities or the binary runs from temp or run staging. User home paths are excluded so file watches stay explicit and aligned with auditd.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2026/04/24"
3integration = ["auditd_manager"]
4maturity = "production"
5updated_date = "2026/04/24"
6
7[rule]
8author = ["Elastic"]
9description = """
10Detects Auditd opened-file reads on sensitive root and cluster paths (Kubernetes token mounts, kubelet and admin
11kubeconfig, PKI material, shadow, root SSH keys, root cloud CLI and Docker config) when the process looks like common
12copy or scripting utilities or the binary runs from temp or run staging. User home paths are excluded so file watches
13stay explicit and aligned with auditd.
14"""
15false_positives = [
16 """
17 Backup, configuration management, and image scanners may open the same paths from scripted utilities; baseline
18 trusted agents and narrow exclusions by process executable hash or parent chain.
19 """,
20 """
21 Administrators reading kubeconfig or cloud profiles during migration can match; correlate with change tickets and
22 bastion sessions.
23 """,
24 """
25 Credential reads under non-root home trees are intentionally excluded; clone the rule with explicit per-user
26 file.path values and optional process.executable prefixes if you must cover interactive accounts with matching
27 audit -w lines for those paths.
28 """,
29]
30from = "now-9m"
31index = ["logs-auditd_manager.auditd-*"]
32language = "kuery"
33license = "Elastic License v2"
34name = "Sensitive Identity File Open by Suspicious Process via Auditd"
35note = """## Triage and analysis
36
37### Investigating Sensitive Identity File Open by Suspicious Process via Auditd
38
39Review which file.path matched, the process name and executable, parent command line, and the Linux user or audit
40identity. Pivot on the same host for adjacent opens, network egress, or privilege changes. Compare against known
41maintenance windows and automation identities.
42
43### Possible investigation steps
44
45- Confirm whether the workload is a Kubernetes node, jump host, or developer machine and whether the actor should read
46 the matched path at all.
47- For Kubernetes token paths, map the process to a container or host PID namespace and inspect pod security context and
48 projected volumes.
49- For cloud credential JSON or shared credentials files, check cloud audit logs for API or token activity shortly after
50 the open timestamp.
51- Capture file hash and process binary hash where possible for incident evidence.
52
53### False positive analysis
54
55- Legitimate kubelet or control plane components may touch admin.conf or PKI material on control plane nodes; scope the
56 rule to worker roles if noisy.
57- CI users running tests from /tmp with cat against a copied kubeconfig can match; tune process or user allowlists.
58
59### Response and remediation
60
61- If malicious, isolate the host, rotate exposed keys and tokens, invalidate cloud sessions, and review RBAC and file
62 permissions on shared credential stores.
63"""
64references = [
65 "https://attack.mitre.org/techniques/T1552/001/",
66 "https://attack.mitre.org/techniques/T1552/007/",
67]
68risk_score = 73
69rule_id = "e4c5d6e7-f8a9-4012-b3c4-d5e6f7a80912"
70setup = """## Setup
71
72This rule expects the Elastic Agent Auditd Manager integration on Linux, with audit rules that emit file open events
73for the paths you care about. Use Fleet to install and configure Auditd Manager, then paste custom rules into the
74integration so opens are audited before they reach Elasticsearch.
75
76### Step 1: Add Auditd Manager in Fleet
77
781. In Kibana, open Management, then Integrations.
792. Search for Auditd Manager and open the integration card.
803. Click Add Auditd Manager, assign a name, and add the integration to the Elastic Agent policy that runs on your
81 Linux hosts (nodes, jump boxes, or developer workstations as applicable).
824. Save and deploy the policy so agents enroll or update.
83
84### Step 2: Paste audit rules into Auditd Manager
85
861. Edit the same Auditd Manager integration policy.
872. Open the Audit rules (or Auditd rule files) section used for free-form audit.rules content.
883. Paste the block below into the audit rules text box, then save the integration policy again so agents reload rules.
89
90The permission mask uses r (read) together with w (write) and a (attribute change) so auditd emits events on read
91opens such as cat or head, which align with opened-file in the detection query. Write and attribute bits still catch
92modifications. If your site policy prefers read-only watches, you may narrow to -p r at the cost of missing write-side
93telemetry on the same paths.
Kubernetes and node identity material
-w /var/run/secrets/kubernetes.io/serviceaccount/token -p rwa -k elastic_sensitive_identity -w /var/run/secrets/eks.amazonaws.com/serviceaccount/token -p rwa -k elastic_sensitive_identity -w /var/run/secrets/azure/tokens/azure-identity-token -p rwa -k elastic_sensitive_identity -w /var/run/secrets/tokens/azure-identity-token -p rwa -k elastic_sensitive_identity -w /var/lib/kubelet/kubeconfig -p rwa -k elastic_sensitive_identity -w /etc/kubernetes/admin.conf -p rwa -k elastic_sensitive_identity -w /etc/kubernetes/pki/ca.key -p rwa -k elastic_sensitive_identity -w /etc/kubernetes/pki/apiserver-kubelet-client.key -p rwa -k elastic_sensitive_identity -w /var/lib/kubelet/pki/kubelet-client-current.pem -p rwa -k elastic_sensitive_identity -w /etc/rancher/k3s/k3s.yaml -p rwa -k elastic_sensitive_identity
Host credential stores (root only)
-w /etc/shadow -p rwa -k elastic_sensitive_identity -w /root/.ssh/id_rsa -p rwa -k elastic_sensitive_identity -w /root/.ssh/id_ed25519 -p rwa -k elastic_sensitive_identity -w /root/.ssh/id_ecdsa -p rwa -k elastic_sensitive_identity -w /root/.aws/credentials -p rwa -k elastic_sensitive_identity -w /root/.aws/config -p rwa -k elastic_sensitive_identity -w /root/.azure/accessTokens.json -p rwa -k elastic_sensitive_identity -w /root/.azure/azureProfile.json -p rwa -k elastic_sensitive_identity -w /root/.azure/msal_token_cache.json -p rwa -k elastic_sensitive_identity -w /root/.config/gcloud/application_default_credentials.json -p rwa -k elastic_sensitive_identity -w /root/.config/gcloud/credentials.db -p rwa -k elastic_sensitive_identity -w /root/.config/gcloud/access_tokens.db -p rwa -k elastic_sensitive_identity -w /root/.kube/config -p rwa -k elastic_sensitive_identity -w /root/.docker/config.json -p rwa -k elastic_sensitive_identity
1
2### Step 3: Reload and verify
3
41. Confirm auditd is active on the host and that auditctl -l (or equivalent) lists the new rules without syntax errors.
52. Generate a harmless test open in a lab (for example cat of a non-production token file you control) and confirm
6 documents land in logs-auditd_manager.auditd-* with event.category file and event.action opened-file (or the closest
7 normalized action your stack maps for open syscalls).
83. If event.action differs in your environment, adjust the rule query to include the mapped value while keeping the
9 same path and process logic.
10
11Further background: https://docs.elastic.co/integrations/auditd_manager
12"""
13severity = "high"
14tags = [
15 "Domain: Endpoint",
16 "Domain: Identity",
17 "OS: Linux",
18 "Use Case: Threat Detection",
19 "Tactic: Credential Access",
20 "Data Source: Auditd Manager",
21 "Resources: Investigation Guide",
22]
23timestamp_override = "event.ingested"
24type = "query"
25query = '''
26host.os.type:"linux" and
27data_stream.dataset:"auditd_manager.auditd" and
28event.category:"file" and
29event.action:"opened-file" and
30(
31 process.name:(
32 cp or mv or ln or cat or head or tail or
33 base64 or xxd or od or
34 curl or wget or
35 tar or zip or gzip or scp or rsync or
36 python* or perl* or ruby* or node or bun or php* or lua* or
37 tee or dd or
38 nc or ncat or netcat or socat or
39 openssl or ssh or sftp or
40 busybox or jq or yq or
41 strings or xargs or sed or awk or grep or find or
42 .*
43 ) or
44 process.executable:(/tmp/* or /var/tmp/* or /dev/shm/* or /run/*) or
45 (process.name:(sh or bash or zsh or dash or fish or ksh) and process.args:("-c" or "-i"))
46) and
47file.path:(
48 "/var/run/secrets/kubernetes.io/serviceaccount/token" or
49 "/var/run/secrets/kubernetes.io/serviceaccount/ca.crt" or
50 "/var/run/secrets/eks.amazonaws.com/serviceaccount/token" or
51 "/var/run/secrets/azure/tokens/azure-identity-token" or
52 "/var/run/secrets/tokens/azure-identity-token" or
53 "/var/lib/kubelet/kubeconfig" or
54 "/etc/kubernetes/admin.conf" or
55 "/etc/kubernetes/pki/ca.key" or
56 "/etc/kubernetes/pki/apiserver-kubelet-client.key" or
57 "/var/lib/kubelet/pki/kubelet-client-current.pem" or
58 "/etc/rancher/k3s/k3s.yaml" or
59 "/etc/shadow" or
60 "/root/.ssh/id_rsa" or
61 "/root/.ssh/id_ed25519" or
62 "/root/.ssh/id_ecdsa" or
63 "/root/.aws/credentials" or
64 "/root/.aws/config" or
65 "/root/.aws/cli/cache" or
66 "/root/.aws/sso/cache" or
67 "/root/.azure/accessTokens.json" or
68 "/root/.azure/azureProfile.json" or
69 "/root/.azure/msal_token_cache.json" or
70 "/root/.azure/msal_http_cache.bin" or
71 "/root/.config/gcloud/application_default_credentials.json" or
72 "/root/.config/gcloud/credentials.db" or
73 "/root/.config/gcloud/access_tokens.db" or
74 "/root/.config/gcloud/legacy_credentials" or
75 "/root/.kube/config" or
76 "/root/.docker/config.json"
77)
78'''
79
80[[rule.threat]]
81framework = "MITRE ATT&CK"
82
83[[rule.threat.technique]]
84id = "T1552"
85name = "Unsecured Credentials"
86reference = "https://attack.mitre.org/techniques/T1552/"
87
88[[rule.threat.technique.subtechnique]]
89id = "T1552.001"
90name = "Credentials In Files"
91reference = "https://attack.mitre.org/techniques/T1552/001/"
92
93[[rule.threat.technique.subtechnique]]
94id = "T1552.007"
95name = "Container API"
96reference = "https://attack.mitre.org/techniques/T1552/007/"
97
98[rule.threat.tactic]
99id = "TA0006"
100name = "Credential Access"
101reference = "https://attack.mitre.org/tactics/TA0006/"
Triage and analysis
Investigating Sensitive Identity File Open by Suspicious Process via Auditd
Review which file.path matched, the process name and executable, parent command line, and the Linux user or audit identity. Pivot on the same host for adjacent opens, network egress, or privilege changes. Compare against known maintenance windows and automation identities.
Possible investigation steps
- Confirm whether the workload is a Kubernetes node, jump host, or developer machine and whether the actor should read the matched path at all.
- For Kubernetes token paths, map the process to a container or host PID namespace and inspect pod security context and projected volumes.
- For cloud credential JSON or shared credentials files, check cloud audit logs for API or token activity shortly after the open timestamp.
- Capture file hash and process binary hash where possible for incident evidence.
False positive analysis
- Legitimate kubelet or control plane components may touch admin.conf or PKI material on control plane nodes; scope the rule to worker roles if noisy.
- CI users running tests from /tmp with cat against a copied kubeconfig can match; tune process or user allowlists.
Response and remediation
- If malicious, isolate the host, rotate exposed keys and tokens, invalidate cloud sessions, and review RBAC and file permissions on shared credential stores.
References
Related rules
- Credential Access via TruffleHog Execution
- Potential Secret Scanning via Gitleaks
- Authentication via Unusual PAM Grantor
- Linux Process Hooking via GDB
- Linux init (PID 1) Secret Dump via GDB