nldcsc-elastic-rules 0.0.8__py3-none-any.whl

nldcsc_elastic_rules/rules/integrations/kubernetes/initial_access_anonymous_request_authorized.toml

@@ -0,0 +1,98 @@
+[metadata]
+creation_date = "2022/09/13"
+integration = ["kubernetes"]
+maturity = "production"
+updated_date = "2025/06/18"
+
+[rule]
+author = ["Elastic"]
+description = """
+This rule detects when an unauthenticated user request is authorized within the cluster. Attackers may attempt to use
+anonymous accounts to gain initial access to the cluster or to avoid attribution of their activities within the cluster.
+This rule excludes the /healthz, /livez and /readyz endpoints which are commonly accessed anonymously.
+"""
+false_positives = [
+    """
+    Anonymous access to the API server is a dangerous setting enabled by default. Common anonymous connections (e.g.,
+    health checks) have been excluded from this rule. All other instances of authorized anonymous requests should be
+    investigated.
+    """,
+]
+index = ["logs-kubernetes.audit_logs-*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "Kubernetes Anonymous Request Authorized"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+### Investigating Kubernetes Anonymous Request Authorized
+
+Kubernetes, a container orchestration platform, manages workloads and services. It uses authentication to control access. Adversaries might exploit anonymous access to perform unauthorized actions without leaving traces. The detection rule identifies unauthorized access by monitoring audit logs for anonymous requests that are allowed, excluding common health check endpoints, to flag potential misuse.
+
+### Possible investigation steps
+
+- Review the audit logs for the specific event.dataset:kubernetes.audit_logs to identify the context and details of the anonymous request.
+- Examine the kubernetes.audit.user.username field to confirm if the request was made by "system:anonymous" or "system:unauthenticated" and assess the potential risk associated with these accounts.
+- Analyze the kubernetes.audit.requestURI to determine the target of the request and verify if it is outside the excluded endpoints (/healthz, /livez, /readyz), which could indicate suspicious activity.
+- Investigate the source IP address and other network metadata associated with the request to identify the origin and assess if it aligns with known or expected traffic patterns.
+- Check for any subsequent or related activities in the audit logs that might indicate further unauthorized actions or attempts to exploit the cluster.
+
+### False positive analysis
+
+- Health check endpoints like /healthz, /livez, and /readyz are already excluded, but ensure any custom health check endpoints are also excluded to prevent false positives.
+- Regularly scheduled maintenance tasks or automated scripts that use anonymous access for legitimate purposes should be identified and excluded from the rule to avoid unnecessary alerts.
+- Some monitoring tools might use anonymous requests for gathering metrics; verify these tools and exclude their specific request patterns if they are known to be safe.
+- Development environments might have different access patterns compared to production; consider creating separate rules or exceptions for non-production clusters to reduce noise.
+- Review the audit logs to identify any recurring anonymous requests that are part of normal operations and adjust the rule to exclude these specific cases.
+
+### Response and remediation
+
+- Immediately isolate the affected Kubernetes cluster to prevent further unauthorized access and potential lateral movement by the adversary.
+- Revoke any anonymous access permissions that are not explicitly required for the operation of the cluster, ensuring that all access is authenticated and authorized.
+- Conduct a thorough review of the audit logs to identify any unauthorized actions performed by anonymous users and assess the impact on the cluster.
+- Reset credentials and access tokens for any accounts that may have been compromised or used in conjunction with the anonymous access.
+- Implement network segmentation to limit the exposure of the Kubernetes API server to only trusted networks and users.
+- Escalate the incident to the security operations team for further investigation and to determine if additional clusters or systems are affected.
+- Enhance monitoring and alerting for unauthorized access attempts, focusing on detecting and responding to similar threats in the future.
+
+## Setup
+
+The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule."""
+references = [
+    "https://media.defense.gov/2022/Aug/29/2003066362/-1/-1/0/CTR_KUBERNETES_HARDENING_GUIDANCE_1.2_20220829.PDF",
+]
+risk_score = 47
+rule_id = "63c057cc-339a-11ed-a261-0242ac120002"
+severity = "medium"
+tags = ["Data Source: Kubernetes", "Tactic: Execution", "Tactic: Initial Access", "Tactic: Defense Evasion", "Resources: Investigation Guide"]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+event.dataset:kubernetes.audit_logs
+  and kubernetes.audit.annotations.authorization_k8s_io/decision:allow
+  and kubernetes.audit.user.username:("system:anonymous" or "system:unauthenticated" or not *)
+  and not kubernetes.audit.requestURI:(/healthz* or /livez* or /readyz*)
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1078"
+name = "Valid Accounts"
+reference = "https://attack.mitre.org/techniques/T1078/"
+[[rule.threat.technique.subtechnique]]
+id = "T1078.001"
+name = "Default Accounts"
+reference = "https://attack.mitre.org/techniques/T1078/001/"
+
+
+
+[rule.threat.tactic]
+id = "TA0001"
+name = "Initial Access"
+reference = "https://attack.mitre.org/tactics/TA0001/"
+

nldcsc_elastic_rules/rules/integrations/kubernetes/persistence_exposed_service_created_with_type_nodeport.toml

@@ -0,0 +1,104 @@
+[metadata]
+creation_date = "2022/07/05"
+integration = ["kubernetes"]
+maturity = "production"
+updated_date = "2025/06/18"
+
+[rule]
+author = ["Elastic"]
+description = """
+This rule detects an attempt to create or modify a service as type NodePort. The NodePort service allows a user to
+externally expose a set of labeled pods to the internet. This creates an open port on every worker node in the cluster
+that has a pod for that service. When external traffic is received on that open port, it directs it to the specific pod
+through the service representing it. A malicious user can configure a service as type Nodeport in order to intercept
+traffic from other pods or nodes, bypassing firewalls and other network security measures configured for load balancers
+within a cluster. This creates a direct method of communication between the cluster and the outside world, which could
+be used for more malicious behavior and certainly widens the attack surface of your cluster.
+"""
+false_positives = [
+    """
+    Developers may have a legitimate use for NodePorts. For frontend parts of an application you may want to expose a
+    Service onto an external IP address without using cloud specific Loadbalancers. NodePort can be used to expose the
+    Service on each Node's IP at a static port (the NodePort). You'll be able to contact the NodePort Service from
+    outside the cluster, by requesting <NodeIP>:<NodePort>. NodePort unlike Loadbalancers, allow the freedom to set up
+    your own load balancing solution, configure environments that aren't fully supported by Kubernetes, or even to
+    expose one or more node's IPs directly.
+    """,
+]
+index = ["logs-kubernetes.audit_logs-*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "Kubernetes Exposed Service Created With Type NodePort"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+### Investigating Kubernetes Exposed Service Created With Type NodePort
+
+Kubernetes NodePort services enable external access to cluster pods by opening a port on each worker node. This can be exploited by attackers to bypass network security, intercept traffic, or establish unauthorized communication channels. The detection rule identifies suspicious NodePort service creation or modification by monitoring Kubernetes audit logs for specific actions and authorization decisions, helping to mitigate potential security risks.
+
+### Possible investigation steps
+
+- Review the Kubernetes audit logs to identify the specific service that was created or modified with the type NodePort. Focus on entries where kubernetes.audit.objectRef.resource is "services" and kubernetes.audit.verb is "create", "update", or "patch".
+- Check the kubernetes.audit.annotations.authorization_k8s_io/decision field to confirm that the action was allowed, ensuring that the service creation or modification was authorized.
+- Identify the user or service account responsible for the action by examining the relevant fields in the audit logs, such as the user identity or service account name.
+- Investigate the context of the NodePort service by reviewing the associated pods and their labels to understand what applications or services are being exposed externally.
+- Assess the network security implications by determining if the NodePort service could potentially bypass existing firewalls or security controls, and evaluate the risk of unauthorized access or data interception.
+- Verify if the NodePort service is necessary for legitimate business purposes or if it was created without proper justification, indicating potential malicious intent.
+
+### False positive analysis
+
+- Routine service updates or deployments may trigger the rule if NodePort services are part of standard operations. To manage this, create exceptions for specific namespaces or service accounts that are known to perform these actions regularly.
+- Development or testing environments often use NodePort services for ease of access. Exclude these environments from the rule by filtering based on labels or annotations that identify non-production clusters.
+- Automated deployment tools or scripts that configure services as NodePort for legitimate reasons can cause false positives. Identify these tools and add their service accounts to an exception list to prevent unnecessary alerts.
+- Internal services that require external access for legitimate business needs might be flagged. Document these services and apply exceptions based on their specific labels or annotations to avoid false alarms.
+- Temporary configurations during incident response or troubleshooting might involve NodePort services. Ensure that these activities are logged and approved, and consider temporary exceptions during the incident resolution period.
+
+### Response and remediation
+
+- Immediately isolate the affected NodePort service by removing or disabling it to prevent further unauthorized access or traffic interception.
+- Review and revoke any unauthorized access or permissions granted to users or service accounts that created or modified the NodePort service.
+- Conduct a thorough audit of network traffic logs to identify any suspicious or unauthorized external connections made through the NodePort service.
+- Implement network segmentation and firewall rules to restrict external access to critical services and ensure that only necessary ports are exposed.
+- Escalate the incident to the security operations team for further investigation and to assess potential impacts on the cluster's security posture.
+- Apply security patches and updates to Kubernetes components and worker nodes to mitigate any known vulnerabilities that could be exploited.
+- Enhance monitoring and alerting mechanisms to detect future unauthorized NodePort service creations or modifications promptly.
+
+## Setup
+
+The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule."""
+references = [
+    "https://kubernetes.io/docs/concepts/services-networking/service/#publishing-services-service-types",
+    "https://kubernetes.io/docs/concepts/services-networking/service/#type-nodeport",
+    "https://www.tigera.io/blog/new-vulnerability-exposes-kubernetes-to-man-in-the-middle-attacks-heres-how-to-mitigate/",
+]
+risk_score = 47
+rule_id = "65f9bccd-510b-40df-8263-334f03174fed"
+severity = "medium"
+tags = ["Data Source: Kubernetes", "Tactic: Execution", "Tactic: Persistence", "Resources: Investigation Guide"]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+event.dataset : "kubernetes.audit_logs"
+  and kubernetes.audit.annotations.authorization_k8s_io/decision:"allow"
+  and kubernetes.audit.objectRef.resource:"services"
+  and kubernetes.audit.verb:("create" or "update" or "patch")
+  and kubernetes.audit.requestObject.spec.type:"NodePort"
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1133"
+name = "External Remote Services"
+reference = "https://attack.mitre.org/techniques/T1133/"
+
+
+[rule.threat.tactic]
+id = "TA0003"
+name = "Persistence"
+reference = "https://attack.mitre.org/tactics/TA0003/"
+

nldcsc_elastic_rules/rules/integrations/kubernetes/privilege_escalation_container_created_with_excessive_linux_capabilities.toml

@@ -0,0 +1,97 @@
+[metadata]
+creation_date = "2022/09/20"
+integration = ["kubernetes"]
+maturity = "production"
+updated_date = "2025/06/18"
+
+[rule]
+author = ["Elastic"]
+description = """
+This rule detects a container deployed with one or more dangerously permissive Linux capabilities. An attacker with the
+ability to deploy a container with added capabilities could use this for further execution, lateral movement, or
+privilege escalation within a cluster. The capabilities detected in this rule have been used in container escapes to the
+host machine.
+"""
+false_positives = [
+    """
+    Some container images require the addition of privileged capabilities. This rule leaves space for the exception of
+    trusted container images. To add an exception, add the trusted container image name to the query field,
+    kubernetes.audit.requestObject.spec.containers.image.
+    """,
+]
+index = ["logs-kubernetes.audit_logs-*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "Kubernetes Container Created with Excessive Linux Capabilities"
+note = """## Triage and analysis
+
+### Investigating Kubernetes Container Created with Excessive Linux Capabilities
+
+Linux capabilities were designed to divide root privileges into smaller units. Each capability grants a thread just enough power to perform specific privileged tasks. In Kubernetes, containers are given a set of default capabilities that can be dropped or added to at the time of creation. Added capabilities entitle containers in a pod with additional privileges that can be used to change
+core processes, change network settings of a cluster, or directly access the underlying host. The following have been used in container escape techniques:
+
+BPF - Allow creating BPF maps, loading BPF Type Format (BTF) data, retrieve JITed code of BPF programs, and more.
+DAC_READ_SEARCH - Bypass file read permission checks and directory read and execute permission checks.
+NET_ADMIN - Perform various network-related operations.
+SYS_ADMIN - Perform a range of system administration operations.
+SYS_BOOT - Use reboot(2) and kexec_load(2), reboot and load a new kernel for later execution.
+SYS_MODULE - Load and unload kernel modules.
+SYS_PTRACE - Trace arbitrary processes using ptrace(2).
+SYS_RAWIO - Perform I/O port operations (iopl(2) and ioperm(2)).
+SYSLOG - Perform privileged syslog(2) operations.
+
+### False positive analysis
+
+- While these capabilities are not included by default in containers, some legitimate images may need to add them. This rule leaves space for the exception of trusted container images. To add an exception, add the trusted container image name to the query field, kubernetes.audit.requestObject.spec.containers.image.
+
+## Setup
+
+The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule."""
+references = [
+    "https://kubernetes.io/docs/tasks/configure-pod-container/security-context/#set-capabilities-for-a-container",
+    "https://0xn3va.gitbook.io/cheat-sheets/container/escaping/excessive-capabilities",
+    "https://man7.org/linux/man-pages/man7/capabilities.7.html",
+    "https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities",
+]
+risk_score = 47
+rule_id = "7164081a-3930-11ed-a261-0242ac120002"
+severity = "medium"
+tags = ["Data Source: Kubernetes", "Tactic: Execution", "Tactic: Privilege Escalation", "Resources: Investigation Guide"]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+event.dataset: kubernetes.audit_logs
+  and kubernetes.audit.annotations.authorization_k8s_io/decision:"allow"
+  and kubernetes.audit.verb: create
+  and kubernetes.audit.objectRef.resource: pods
+  and kubernetes.audit.requestObject.spec.containers.securityContext.capabilities.add: ("BPF" or "DAC_READ_SEARCH"  or "NET_ADMIN" or "SYS_ADMIN" or "SYS_BOOT" or "SYS_MODULE" or "SYS_PTRACE" or "SYS_RAWIO"  or "SYSLOG")
+  and not kubernetes.audit.requestObject.spec.containers.image : ("docker.elastic.co/beats/elastic-agent:8.4.0" or "rancher/klipper-lb:v0.3.5" or "")
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1611"
+name = "Escape to Host"
+reference = "https://attack.mitre.org/techniques/T1611/"
+
+
+[rule.threat.tactic]
+id = "TA0004"
+name = "Privilege Escalation"
+reference = "https://attack.mitre.org/tactics/TA0004/"
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1610"
+name = "Deploy Container"
+reference = "https://attack.mitre.org/techniques/T1610/"
+
+
+[rule.threat.tactic]
+id = "TA0002"
+name = "Execution"
+reference = "https://attack.mitre.org/tactics/TA0002/"
+

nldcsc_elastic_rules/rules/integrations/kubernetes/privilege_escalation_pod_created_with_hostipc.toml

@@ -0,0 +1,114 @@
+[metadata]
+creation_date = "2022/07/05"
+integration = ["kubernetes"]
+maturity = "production"
+updated_date = "2025/06/18"
+
+[rule]
+author = ["Elastic"]
+description = """
+This rule detects an attempt to create or modify a pod using the host IPC namespace. This gives access to data used by
+any pod that also use the hosts IPC namespace. If any process on the host or any processes in a pod uses the hosts
+inter-process communication mechanisms (shared memory, semaphore arrays, message queues, etc.), an attacker can
+read/write to those same mechanisms. They may look for files in /dev/shm or use ipcs to check for any IPC facilities
+being used.
+"""
+false_positives = [
+    """
+    An administrator or developer may want to use a pod that runs as root and shares the host's IPC, Network, and PID
+    namespaces for debugging purposes. If something is going wrong in the cluster and there is no easy way to SSH onto
+    the host nodes directly, a privileged pod of this nature can be useful for viewing things like iptable rules and
+    network namespaces from the host's perspective. Add exceptions for trusted container images using the query field
+    "kubernetes.audit.requestObject.spec.container.image"
+    """,
+]
+index = ["logs-kubernetes.audit_logs-*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "Kubernetes Pod Created With HostIPC"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+### Investigating Kubernetes Pod Created With HostIPC
+
+Kubernetes allows pods to share the host's IPC namespace, enabling inter-process communication. While useful for legitimate applications, adversaries can exploit this to access shared memory and IPC mechanisms, potentially leading to data exposure or privilege escalation. The detection rule identifies suspicious pod creation or modification events that enable host IPC, excluding known benign images, to flag potential security threats.
+
+### Possible investigation steps
+
+- Review the Kubernetes audit logs to identify the specific pod creation or modification event that triggered the alert, focusing on the event.dataset field with the value "kubernetes.audit_logs".
+- Examine the kubernetes.audit.annotations.authorization_k8s_io/decision field to confirm that the action was allowed, and verify the identity of the user or service account that initiated the request.
+- Investigate the kubernetes.audit.objectRef.resource field to ensure the resource involved is indeed a pod, and check the kubernetes.audit.verb field to determine if the action was a create, update, or patch operation.
+- Analyze the kubernetes.audit.requestObject.spec.hostIPC field to confirm that host IPC was enabled, and cross-reference with the kubernetes.audit.requestObject.spec.containers.image field to ensure the image is not part of the known benign list.
+- Check for any other pods or processes on the host that might be using the host's IPC namespace, and assess if there is any unauthorized access or data exposure risk.
+- Look for any suspicious activity or anomalies in the /dev/shm directory or use the ipcs command to identify any IPC facilities that might be exploited.
+
+### False positive analysis
+
+- Pods using hostIPC for legitimate inter-process communication may trigger alerts. Review the pod's purpose and verify if hostIPC is necessary for its function.
+- Known benign images, such as monitoring or logging agents, might use hostIPC. Update the exclusion list to include these images if they are verified as non-threatening.
+- Development or testing environments often use hostIPC for debugging purposes. Consider excluding these environments from the rule or creating a separate rule with a higher threshold for alerts.
+- Automated deployment tools might temporarily use hostIPC during setup. Ensure these tools are recognized and excluded if they are part of a controlled and secure process.
+- Regularly review and update the exclusion list to reflect changes in your environment, ensuring that only verified and necessary uses of hostIPC are excluded.
+
+### Response and remediation
+
+- Immediately isolate the affected pod to prevent further access to the host's IPC namespace. This can be done by cordoning the node or deleting the pod if necessary.
+- Review and revoke any unnecessary permissions or roles that allowed the pod to be created or modified with hostIPC enabled. Ensure that only trusted entities have the capability to modify pod specifications.
+- Conduct a thorough audit of other pods and configurations in the cluster to identify any additional instances where hostIPC is enabled without a valid justification.
+- Implement network policies to restrict communication between pods and the host, limiting the potential impact of any unauthorized access to the host's IPC mechanisms.
+- Escalate the incident to the security operations team for further investigation and to determine if any data exposure or privilege escalation occurred.
+- Update security policies and configurations to prevent the use of hostIPC in future pod deployments unless explicitly required and approved.
+- Enhance monitoring and alerting to detect similar attempts in the future, ensuring that any unauthorized use of hostIPC is promptly flagged and addressed.
+
+## Setup
+
+The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule."""
+references = [
+    "https://research.nccgroup.com/2021/11/10/detection-engineering-for-kubernetes-clusters/#part3-kubernetes-detections",
+    "https://kubernetes.io/docs/concepts/security/pod-security-policy/#host-namespaces",
+    "https://bishopfox.com/blog/kubernetes-pod-privilege-escalation",
+]
+risk_score = 47
+rule_id = "764c8437-a581-4537-8060-1fdb0e92c92d"
+severity = "medium"
+tags = ["Data Source: Kubernetes", "Tactic: Execution", "Tactic: Privilege Escalation", "Resources: Investigation Guide"]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+event.dataset : "kubernetes.audit_logs"
+  and kubernetes.audit.annotations.authorization_k8s_io/decision:"allow"
+  and kubernetes.audit.objectRef.resource:"pods"
+  and kubernetes.audit.verb:("create" or "update" or "patch")
+  and kubernetes.audit.requestObject.spec.hostIPC:true
+  and not kubernetes.audit.requestObject.spec.containers.image: ("docker.elastic.co/beats/elastic-agent:8.4.0")
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1611"
+name = "Escape to Host"
+reference = "https://attack.mitre.org/techniques/T1611/"
+
+
+[rule.threat.tactic]
+id = "TA0004"
+name = "Privilege Escalation"
+reference = "https://attack.mitre.org/tactics/TA0004/"
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1610"
+name = "Deploy Container"
+reference = "https://attack.mitre.org/techniques/T1610/"
+
+
+[rule.threat.tactic]
+id = "TA0002"
+name = "Execution"
+reference = "https://attack.mitre.org/tactics/TA0002/"
+

nldcsc_elastic_rules/rules/integrations/kubernetes/privilege_escalation_pod_created_with_hostnetwork.toml

@@ -0,0 +1,111 @@
+[metadata]
+creation_date = "2022/07/05"
+integration = ["kubernetes"]
+maturity = "production"
+updated_date = "2025/06/18"
+
+[rule]
+author = ["Elastic"]
+description = """
+This rules detects an attempt to create or modify a pod attached to the host network. HostNetwork allows a pod to use
+the node network namespace. Doing so gives the pod access to any service running on localhost of the host. An attacker
+could use this access to snoop on network activity of other pods on the same node or bypass restrictive network policies
+applied to its given namespace.
+"""
+false_positives = [
+    """
+    An administrator or developer may want to use a pod that runs as root and shares the hosts IPC, Network, and PID
+    namespaces for debugging purposes. If something is going wrong in the cluster and there is no easy way to SSH onto
+    the host nodes directly, a privileged pod of this nature can be useful for viewing things like iptable rules and
+    network namespaces from the host's perspective. Add exceptions for trusted container images using the query field
+    "kubernetes.audit.requestObject.spec.container.image"
+    """,
+]
+index = ["logs-kubernetes.audit_logs-*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "Kubernetes Pod Created With HostNetwork"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+### Investigating Kubernetes Pod Created With HostNetwork
+
+Kubernetes allows pods to connect to the host's network namespace using HostNetwork, granting them direct access to the node's network interfaces. This capability can be exploited by attackers to monitor or intercept network traffic, potentially bypassing network policies. The detection rule identifies suspicious pod creation or modification events with HostNetwork enabled, excluding known benign images, to flag potential privilege escalation attempts.
+
+### Possible investigation steps
+
+- Review the Kubernetes audit logs to identify the source of the pod creation or modification event, focusing on the user or service account associated with the action.
+- Examine the pod's configuration details, especially the containers' images, to determine if any unauthorized or suspicious images are being used, excluding known benign images like "docker.elastic.co/beats/elastic-agent:8.4.0".
+- Investigate the network activity of the node where the pod is running to identify any unusual traffic patterns or potential data exfiltration attempts.
+- Check the Kubernetes RBAC (Role-Based Access Control) settings to ensure that the user or service account has appropriate permissions and is not overly privileged.
+- Assess the necessity of using HostNetwork for the pod in question and determine if it can be reconfigured to operate without this setting to reduce potential security risks.
+
+### False positive analysis
+
+- Pods used for monitoring or logging may require HostNetwork access to gather network data across nodes. Users can exclude these by adding their specific container images to the exception list in the detection rule.
+- Certain system-level services or infrastructure components might need HostNetwork for legitimate reasons, such as network plugins or ingress controllers. Identify these services and update the rule to exclude their specific images or namespaces.
+- Development or testing environments might frequently create pods with HostNetwork for debugging purposes. Consider creating a separate rule or environment-specific exceptions to avoid alert fatigue in these scenarios.
+- Pods that are part of a known and trusted deployment process, which require HostNetwork for valid operational reasons, should be documented and excluded from the rule to prevent unnecessary alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected pod by cordoning the node to prevent new pods from being scheduled and draining existing pods to other nodes, except the suspicious one.
+- Terminate the suspicious pod to stop any potential malicious activity and prevent further network access.
+- Review and revoke any unnecessary permissions or roles associated with the service account used by the pod to limit privilege escalation opportunities.
+- Conduct a thorough audit of network policies to ensure they are correctly configured to prevent unauthorized access to the host network.
+- Escalate the incident to the security operations team for further investigation and to determine if any data was accessed or exfiltrated.
+- Implement additional monitoring and alerting for any future pod creations with HostNetwork enabled to quickly detect similar threats.
+- Review and update Kubernetes RBAC policies to enforce the principle of least privilege, ensuring only trusted entities can create pods with HostNetwork enabled.
+
+## Setup
+
+The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule."""
+references = [
+    "https://research.nccgroup.com/2021/11/10/detection-engineering-for-kubernetes-clusters/#part3-kubernetes-detections",
+    "https://kubernetes.io/docs/concepts/security/pod-security-policy/#host-namespaces",
+    "https://bishopfox.com/blog/kubernetes-pod-privilege-escalation",
+]
+risk_score = 47
+rule_id = "12cbf709-69e8-4055-94f9-24314385c27e"
+severity = "medium"
+tags = ["Data Source: Kubernetes", "Tactic: Execution", "Tactic: Privilege Escalation", "Resources: Investigation Guide"]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+event.dataset : "kubernetes.audit_logs"
+  and kubernetes.audit.annotations.authorization_k8s_io/decision:"allow"
+  and kubernetes.audit.objectRef.resource:"pods"
+  and kubernetes.audit.verb:("create" or "update" or "patch")
+  and kubernetes.audit.requestObject.spec.hostNetwork:true
+  and not kubernetes.audit.requestObject.spec.containers.image: ("docker.elastic.co/beats/elastic-agent:8.4.0")
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1611"
+name = "Escape to Host"
+reference = "https://attack.mitre.org/techniques/T1611/"
+
+
+[rule.threat.tactic]
+id = "TA0004"
+name = "Privilege Escalation"
+reference = "https://attack.mitre.org/tactics/TA0004/"
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1610"
+name = "Deploy Container"
+reference = "https://attack.mitre.org/techniques/T1610/"
+
+
+[rule.threat.tactic]
+id = "TA0002"
+name = "Execution"
+reference = "https://attack.mitre.org/tactics/TA0002/"
+

nldcsc_elastic_rules/rules/integrations/kubernetes/privilege_escalation_pod_created_with_hostpid.toml

@@ -0,0 +1,114 @@
+[metadata]
+creation_date = "2022/07/05"
+integration = ["kubernetes"]
+maturity = "production"
+updated_date = "2025/06/18"
+
+[rule]
+author = ["Elastic"]
+description = """
+This rule detects an attempt to create or modify a pod attached to the host PID namespace. HostPID allows a pod to
+access all the processes running on the host and could allow an attacker to take malicious action. When paired with
+ptrace this can be used to escalate privileges outside of the container. When paired with a privileged container, the
+pod can see all of the processes on the host. An attacker can enter the init system (PID 1) on the host. From there,
+they could execute a shell and continue to escalate privileges to root.
+"""
+false_positives = [
+    """
+    An administrator or developer may want to use a pod that runs as root and shares the hosts IPC, Network, and PID
+    namespaces for debugging purposes. If something is going wrong in the cluster and there is no easy way to SSH onto
+    the host nodes directly, a privileged pod of this nature can be useful for viewing things like iptable rules and
+    network namespaces from the host's perspective. Add exceptions for trusted container images using the query field
+    "kubernetes.audit.requestObject.spec.container.image"
+    """,
+]
+index = ["logs-kubernetes.audit_logs-*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "Kubernetes Pod Created With HostPID"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+### Investigating Kubernetes Pod Created With HostPID
+
+Kubernetes allows pods to share the host's process ID (PID) namespace, enabling visibility into host processes. While useful for debugging, this can be exploited by attackers to escalate privileges, especially when combined with privileged containers. The detection rule identifies attempts to create or modify pods with HostPID enabled, excluding known safe images, to flag potential privilege escalation activities.
+
+### Possible investigation steps
+
+- Review the Kubernetes audit logs to identify the user or service account responsible for the pod creation or modification attempt. Look for the `kubernetes.audit.user.username` field to determine who initiated the action.
+- Examine the `kubernetes.audit.requestObject.spec.containers.image` field to identify the container images used in the pod. Verify if any unknown or suspicious images are being deployed.
+- Check the `kubernetes.audit.annotations.authorization_k8s_io/decision` field to confirm that the action was allowed and investigate the context or reason for this decision.
+- Investigate the `kubernetes.audit.objectRef.resource` and `kubernetes.audit.verb` fields to understand the specific action taken (create, update, or patch) and the resource involved.
+- Assess the necessity and legitimacy of using HostPID in the pod's configuration by consulting with the relevant development or operations teams. Determine if there is a valid use case or if it was potentially misconfigured or maliciously set.
+- Review any recent changes in the Kubernetes environment or related configurations that might have led to this alert, focusing on changes around the time the alert was triggered.
+
+### False positive analysis
+
+- Known safe images like "docker.elastic.co/beats/elastic-agent:8.4.0" are already excluded, but other internal tools or monitoring agents that require HostPID for legitimate reasons might trigger false positives. Review and identify such images and add them to the exclusion list.
+- Development or testing environments often use HostPID for debugging purposes. Consider creating a separate rule or exception for these environments to prevent unnecessary alerts.
+- Some system maintenance tasks might require temporary use of HostPID. Document these tasks and schedule them during known maintenance windows, then adjust the rule to exclude these specific time frames.
+- Regularly review audit logs to identify patterns of benign HostPID usage. Use this information to refine the rule and reduce false positives by updating the exclusion criteria.
+- Collaborate with development and operations teams to understand legitimate use cases for HostPID in your environment, and adjust the rule to accommodate these scenarios without compromising security.
+
+### Response and remediation
+
+- Immediately isolate the affected pod to prevent further interaction with the host processes. This can be done by cordoning the node or deleting the pod if necessary.
+- Review and revoke any unnecessary permissions or roles that may have allowed the creation of pods with HostPID enabled. Ensure that only trusted users and service accounts have the ability to create such pods.
+- Conduct a thorough investigation of the container images used in the pod to ensure they are from trusted sources and have not been tampered with. Remove any untrusted or suspicious images from the registry.
+- Check for any unauthorized access or changes to the host system's processes and files. If any malicious activity is detected, take steps to restore affected systems from backups and patch any vulnerabilities.
+- Implement network segmentation to limit the communication between pods and the host system, reducing the risk of lateral movement by an attacker.
+- Enhance monitoring and logging to capture detailed audit logs of Kubernetes API activities, focusing on changes to pod specifications and the use of HostPID. This will aid in detecting similar threats in the future.
+- Escalate the incident to the security operations team for further analysis and to determine if additional security measures or incident response actions are required.
+
+## Setup
+
+The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule."""
+references = [
+    "https://research.nccgroup.com/2021/11/10/detection-engineering-for-kubernetes-clusters/#part3-kubernetes-detections",
+    "https://kubernetes.io/docs/concepts/security/pod-security-policy/#host-namespaces",
+    "https://bishopfox.com/blog/kubernetes-pod-privilege-escalation",
+]
+risk_score = 47
+rule_id = "df7fda76-c92b-4943-bc68-04460a5ea5ba"
+severity = "medium"
+tags = ["Data Source: Kubernetes", "Tactic: Execution", "Tactic: Privilege Escalation", "Resources: Investigation Guide"]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+event.dataset : "kubernetes.audit_logs"
+  and kubernetes.audit.annotations.authorization_k8s_io/decision:"allow"
+  and kubernetes.audit.objectRef.resource:"pods"
+  and kubernetes.audit.verb:("create" or "update" or "patch")
+  and kubernetes.audit.requestObject.spec.hostPID:true
+  and not kubernetes.audit.requestObject.spec.containers.image: ("docker.elastic.co/beats/elastic-agent:8.4.0")
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1611"
+name = "Escape to Host"
+reference = "https://attack.mitre.org/techniques/T1611/"
+
+
+[rule.threat.tactic]
+id = "TA0004"
+name = "Privilege Escalation"
+reference = "https://attack.mitre.org/tactics/TA0004/"
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1610"
+name = "Deploy Container"
+reference = "https://attack.mitre.org/techniques/T1610/"
+
+
+[rule.threat.tactic]
+id = "TA0002"
+name = "Execution"
+reference = "https://attack.mitre.org/tactics/TA0002/"
+