1200KM / sigma-rule
Privileged Container Deployed — Sigma Rule
Sigma rule c5cd1b20-36bb-488d-8c05-486be3d0cb97. Privileged Container Deployed — Sigma Rule. Detects the creation of a "privileged" container, an action which could be indicative of a threat actor mounting a container breakout attacks. A privileged container is a container that can access the host with all of the root capabilities of the host machine. This allows it to view, interact and modify processes, network operations, IPC calls, the file system, mount points, SELinux configurations etc. as the root user on the host. Various versions of "privileged" containers can be specified, e.g. by setting the securityContext.privileged flag in the resource specification, setting non-standard Linux capabilities, or configuring the hostNetwork/hostPID fields
Rule metadata and linked tags
Author: Leo Tsaousis (@laripping). Source status: test; severity: low. Source dates: 2024-03-26 / not supplied.
{
"category": "application",
"product": "kubernetes",
"service": "audit"
}Pinned original Sigma rule · Detection Rule License 1.1
Source SHA-256: e9b5c22430f8e04d296730ced110b1d14ef38c1c58ae6571884424a8ba7d8178
Detection logic
Original source YAML. Source-tag agreement is not proof of complete semantic coverage. This rule has not been compiled for a SIEM backend or validated against live telemetry here.
title: Privileged Container Deployed
id: c5cd1b20-36bb-488d-8c05-486be3d0cb97
status: test
description: |
Detects the creation of a "privileged" container, an action which could be indicative of a threat actor mounting a container breakout attacks.
A privileged container is a container that can access the host with all of the root capabilities of the host machine. This allows it to view, interact and modify processes, network operations, IPC calls, the file system, mount points, SELinux configurations etc. as the root user on the host.
Various versions of "privileged" containers can be specified, e.g. by setting the securityContext.privileged flag in the resource specification, setting non-standard Linux capabilities, or configuring the hostNetwork/hostPID fields
references:
- https://microsoft.github.io/Threat-Matrix-for-Kubernetes/techniques/Privileged%20container/
- https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-kubernetes.html#privilegeescalation-kubernetes-privilegedcontainer
- https://www.elastic.co/guide/en/security/current/kubernetes-pod-created-with-hostnetwork.html
- https://www.elastic.co/guide/en/security/current/kubernetes-container-created-with-excessive-linux-capabilities.html
author: Leo Tsaousis (@laripping)
date: 2024-03-26
tags:
- attack.t1611
- attack.privilege-escalation
logsource:
category: application
product: kubernetes
service: audit
detection:
selection:
verb: 'create'
objectRef.resource: 'pods'
capabilities: '*' # Note: Add the "exists" when it's implemented in SigmaHQ/Aurora
condition: selection
falsepositives:
- Unknown
level: low
False positives
- Unknown
Source references
- https://microsoft.github.io/Threat-Matrix-for-Kubernetes/techniques/Privileged%20container/
- https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-kubernetes.html#privilegeescalation-kubernetes-privilegedcontainer
- https://www.elastic.co/guide/en/security/current/kubernetes-pod-created-with-hostnetwork.html
- https://www.elastic.co/guide/en/security/current/kubernetes-container-created-with-excessive-linux-capabilities.html
Connected ecosystem references
Exact source-tagged techniques
Telemetry review
Read the original logsource above, then inspect the linked detection workspaces for technique-level sensor context. No per-rule telemetry equivalence is inferred.
Pinned research references. No browser attack runner, live simulation result or validated detector is asserted. Source mappings and validation limits are preserved. ATT&CK / Atomic provenance · Detection provenance.