AWS EKS Admission Webhook Created or Modified
Detects creation, modification, or deletion of Kubernetes MutatingWebhookConfigurations or ValidatingWebhookConfigurations by non-system identities. Admission webhooks intercept every API request matching their rules before persistence, giving an attacker powerful capabilities: injecting malicious sidecars into every new pod via a mutating webhook, blocking security tooling deployments via a validating webhook, or silently exfiltrating pod specifications to an external server. Webhook manipulation is a stealthy persistence and defense evasion technique because the webhook configuration itself looks benign in kubectl output while actively modifying or intercepting all matching Kubernetes API traffic.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2026/08/03"
3integration = ["aws"]
4maturity = "production"
5min_stack_comments = "The AWS integration adds the aws.eks_audit data stream in package 8.9.0, which requires Kibana 9.6.0 or later."
6min_stack_version = "9.6.0"
7updated_date = "2026/10/21"
8
9[rule]
10author = ["Elastic"]
11description = """
12Detects creation, modification, or deletion of Kubernetes MutatingWebhookConfigurations or
13ValidatingWebhookConfigurations by non-system identities. Admission webhooks intercept every API request matching their
14rules before persistence, giving an attacker powerful capabilities: injecting malicious sidecars into every new pod via
15a mutating webhook, blocking security tooling deployments via a validating webhook, or silently exfiltrating pod
16specifications to an external server. Webhook manipulation is a stealthy persistence and defense evasion technique
17because the webhook configuration itself looks benign in kubectl output while actively modifying or intercepting all
18matching Kubernetes API traffic.
19"""
20false_positives = [
21 """
22 Cluster operators and GitOps automation may legitimately install or upgrade admission controllers (e.g.
23 cert-manager, Gatekeeper, Kyverno, service mesh components). Validate change tickets and approved controllers before
24 tuning.
25 """,
26]
27from = "now-9m"
28index = ["logs-aws.eks_audit-*"]
29language = "kuery"
30license = "Elastic License v2"
31name = "AWS EKS Admission Webhook Created or Modified"
32note = """## Triage and analysis
33
34### Investigating AWS EKS Admission Webhook Created or Modified
35Admission webhooks can mutate or validate resources before they are persisted. A malicious webhook can inject sidecars,
36alter securityContext, block defensive workloads, or exfiltrate pod specs. This rule alerts on allowed changes to
37MutatingWebhookConfiguration and ValidatingWebhookConfiguration objects by identities outside common system patterns.
38
39### Possible investigation steps
40
41- Confirm the webhook resource and operation:
42 - aws.eks.audit.objectRef.resource and aws.eks.audit.verb
43 - aws.eks.audit.objectRef.name (the webhook configuration name)
44- Attribute the actor and access path:
45 - user.name (human vs service account vs node identity)
46 - source.ip and user_agent.original
47 - In cloud-managed clusters, map the identity to IAM/Entra principal data present in aws.eks.audit.user.extra.*.
48- Extract the webhook destination and review for external exfiltration:
49 - aws.eks.audit.requestObject.webhooks.clientConfig.url (suspicious when pointing to the public internet)
50 - aws.eks.audit.requestObject.webhooks.clientConfig.service.* (in-cluster service; still validate namespace/name)
51- Review impact-driving webhook settings:
52 - failurePolicy (e.g., Ignore can make malicious webhooks stealthier by avoiding obvious outages)
53 - namespaceSelector / objectSelector targeting (e.g., excluding kube-system while targeting everything else)
54 - rules.operations and rules.resources (e.g., CREATE pods is consistent with broad sidecar injection)
55 - sideEffects, timeoutSeconds, matchPolicy, reinvocationPolicy
56- Scope blast radius and follow-on activity:
57 - Hunt for pods created/updated after the webhook change that include unexpected containers, initContainers, env vars,
58 volume mounts, or securityContext changes.
59 - Check for concurrent RBAC changes, token creation, or secret access from the same identity and source IP.
60
61### False positive analysis
62
63- GitOps upgrades or controller installs can legitimately change admission webhooks. Validate the change against:
64 - approved Helm/Git commits, change tickets, and expected controller namespaces
65 - known controller identities (cert-manager, Gatekeeper, Kyverno, service mesh controllers)
66
67### Response and remediation
68
69- If unauthorized, revert or delete the webhook configuration from a known-good source (GitOps/Helm), then block the
70 actor identity and rotate any credentials it used.
71- If the webhook targeted pod creation, assume workload impact: identify affected namespaces/workloads, redeploy from
72 trusted manifests/images, and validate that new pods are no longer being mutated.
73- If an external clientConfig.url was used, treat it as potential data exfiltration and review egress/DNS logs for the
74 destination around the alert window."""
75risk_score = 47
76rule_id = "82f48bb2-bb1b-582b-8cf5-c8172f1e3da9"
77setup = """This rule reads EKS control-plane audit logs collected by the AWS integration
78into `logs-aws.eks_audit-*`, where the AWS EKS audit ingest
79pipelines normalize each audit record under `aws.eks.audit.*`.
80
81Enable the `audit` control-plane log type on the EKS cluster, send its
82CloudWatch log group through the AWS integration, and confirm events carry
83`data_stream.dataset: aws.eks_audit` and
84`cloud.provider: aws` before enabling this rule.
85"""
86severity = "medium"
87tags = [
88 "Domain: Cloud",
89 "Domain: Containers",
90 "Platform: AWS",
91 "Platform: Kubernetes",
92 "Data Source: AWS",
93 "Data Source: Amazon Web Services",
94 "Data Source: Kubernetes API Server Audit Logs",
95 "Service: AWS EKS",
96 "Use Case: Threat Detection",
97 "Tactic: Persistence",
98 "Tactic: Defense Evasion",
99 "Rule Type: Custom Query (KQL)",
100 "Resources: Investigation Guide",
101 "Profile: Beta",
102]
103timestamp_override = "event.ingested"
104type = "query"
105
106query = '''
107data_stream.dataset:"aws.eks_audit" and
108aws.eks.audit.objectRef.resource:("mutatingwebhookconfigurations" or "validatingwebhookconfigurations") and
109aws.eks.audit.verb:("create" or "update" or "patch" or "delete") and
110aws.eks.audit.annotations.authorization_k8s_io/decision:"allow" and
111user.name:(* and not
112 (system\:kube-controller-manager or
113 system\:kube-scheduler or
114 system\:serviceaccount\:kube-system\:* or
115 eks\:* or
116 system\:serviceaccount\:cert-manager\:* or
117 system\:serviceaccount\:gatekeeper-system\:* or
118 system\:serviceaccount\:kyverno\:* or
119 system\:serviceaccount\:*\:*-operator)
120) and
121aws.eks.audit.objectRef.name:(* and not (pod-identity-webhook or vpc-resource-mutating-webhook)) and
122not (aws.eks.audit.user.groups:"system:serviceaccounts:flux-system" and aws.eks.audit.objectRef.name:"k8tz")
123'''
124
125
126[[rule.threat]]
127framework = "MITRE ATT&CK"
128[[rule.threat.technique]]
129id = "T1546"
130name = "Event Triggered Execution"
131reference = "https://attack.mitre.org/techniques/T1546/"
132
133
134[rule.threat.tactic]
135id = "TA0003"
136name = "Persistence"
137reference = "https://attack.mitre.org/tactics/TA0003/"
138[[rule.threat]]
139framework = "MITRE ATT&CK"
140[[rule.threat.technique]]
141id = "T1562"
142name = "Impair Defenses"
143reference = "https://attack.mitre.org/techniques/T1562/"
144
145
146[rule.threat.tactic]
147id = "TA0005"
148name = "Defense Evasion"
149reference = "https://attack.mitre.org/tactics/TA0005/"
Triage and analysis
Investigating AWS EKS Admission Webhook Created or Modified
Admission webhooks can mutate or validate resources before they are persisted. A malicious webhook can inject sidecars, alter securityContext, block defensive workloads, or exfiltrate pod specs. This rule alerts on allowed changes to MutatingWebhookConfiguration and ValidatingWebhookConfiguration objects by identities outside common system patterns.
Possible investigation steps
- Confirm the webhook resource and operation:
- aws.eks.audit.objectRef.resource and aws.eks.audit.verb
- aws.eks.audit.objectRef.name (the webhook configuration name)
- Attribute the actor and access path:
- user.name (human vs service account vs node identity)
- source.ip and user_agent.original
- In cloud-managed clusters, map the identity to IAM/Entra principal data present in aws.eks.audit.user.extra.*.
- Extract the webhook destination and review for external exfiltration:
- aws.eks.audit.requestObject.webhooks.clientConfig.url (suspicious when pointing to the public internet)
- aws.eks.audit.requestObject.webhooks.clientConfig.service.* (in-cluster service; still validate namespace/name)
- Review impact-driving webhook settings:
- failurePolicy (e.g., Ignore can make malicious webhooks stealthier by avoiding obvious outages)
- namespaceSelector / objectSelector targeting (e.g., excluding kube-system while targeting everything else)
- rules.operations and rules.resources (e.g., CREATE pods is consistent with broad sidecar injection)
- sideEffects, timeoutSeconds, matchPolicy, reinvocationPolicy
- Scope blast radius and follow-on activity:
- Hunt for pods created/updated after the webhook change that include unexpected containers, initContainers, env vars, volume mounts, or securityContext changes.
- Check for concurrent RBAC changes, token creation, or secret access from the same identity and source IP.
False positive analysis
- GitOps upgrades or controller installs can legitimately change admission webhooks. Validate the change against:
- approved Helm/Git commits, change tickets, and expected controller namespaces
- known controller identities (cert-manager, Gatekeeper, Kyverno, service mesh controllers)
Response and remediation
- If unauthorized, revert or delete the webhook configuration from a known-good source (GitOps/Helm), then block the actor identity and rotate any credentials it used.
- If the webhook targeted pod creation, assume workload impact: identify affected namespaces/workloads, redeploy from trusted manifests/images, and validate that new pods are no longer being mutated.
- If an external clientConfig.url was used, treat it as potential data exfiltration and review egress/DNS logs for the destination around the alert window.
Related rules
- AWS EKS Authentication Configuration Modified
- AWS EKS Client Certificate Signing Request Created or Approved
- AWS EKS Cluster-Admin Role Binding Created
- AWS EKS Creation of a RoleBinding Referencing a ServiceAccount
- AWS EKS Events Deleted