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

to-top