1200kmSECURITY RESEARCH

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

Original YAML and metadata in JSON

False positives

  • Unknown

Source references

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.