{"description":"Trending threats, MITRE ATT\u0026CK coverage, and detection metadata. Fed continuously.","feed_url":"https://feed.craftedsignal.io/tags/systemd/feed.json","home_page_url":"https://feed.craftedsignal.io/","items":[{"_cs_actors":[],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["Red Hat Enterprise Linux","Ubuntu","Debian","Arch Linux","Docker runtime","Kubernetes"],"_cs_severities":["medium"],"_cs_tags":["linux","cgroups","container","kubernetes","docker","systemd","threat-detection"],"_cs_type":"advisory","_cs_vendors":["Red Hat","Canonical","Docker","Google"],"content_html":"\u003cp\u003eLinux cgroups (control groups) are a kernel feature designed for resource management, allowing administrators to limit the resources available to specific processes. While intended for system stability and performance, cgroups also expose valuable telemetry that can be leveraged for threat detection and incident response. This is particularly useful in modern Linux environments heavily reliant on containerization and systemd. Defenders can utilize cgroup information to gain deeper insights into process behavior, establish relationships between processes, and differentiate between benign and malicious activities. By understanding how cgroups are structured and utilized by different systems, security teams can enhance their ability to detect and respond to threats on Linux servers. The blog post highlights the practical application of cgroups in systemd, Docker, and Kubernetes environments, providing a foundation for building more effective detection strategies.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker gains initial access to a Linux server, potentially through exploiting a vulnerability or using compromised credentials.\u003c/li\u003e\n\u003cli\u003eAttacker executes a malicious script or binary on the server.\u003c/li\u003e\n\u003cli\u003eThe malicious process is assigned a cgroup by the system, depending on whether it\u0026rsquo;s managed by systemd, Docker, or Kubernetes.\u003c/li\u003e\n\u003cli\u003eIf the process is a systemd service, it will be associated with a cgroup under \u003ccode\u003e/system.slice/\u003c/code\u003e, which reveals the service name.\u003c/li\u003e\n\u003cli\u003eIf the process is running within a Docker container, it will be assigned a cgroup under \u003ccode\u003e/docker/$CONTAINER_ID\u003c/code\u003e, allowing for grouping of all container processes.\u003c/li\u003e\n\u003cli\u003eIn a Kubernetes environment, the cgroup path will include the pod ID and Quality-of-Service class, such as \u003ccode\u003e/kubepods/$CLASS/pod$POD_ID/$CONTAINER_ID\u003c/code\u003e (cgroupfs driver) or \u003ccode\u003e/kubepods.slice/kubepods-$CLASS.slice/$POD_ID.slice/$CONTAINER_ID\u003c/code\u003e (systemd driver).\u003c/li\u003e\n\u003cli\u003eThe attacker attempts lateral movement or persistence, spawning additional processes that inherit the same cgroup, which can be used to correlate attacker activity.\u003c/li\u003e\n\u003cli\u003eThe attacker achieves their objective, such as deploying a coinminer or exfiltrating sensitive data, leaving behind processes that can be identified and grouped via their cgroup assignment.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eCompromised Linux servers can lead to data breaches, service disruptions, and resource hijacking. If an attacker successfully establishes persistence, they can maintain unauthorized access for extended periods. The presence of coinminers can degrade system performance and increase energy consumption. Understanding the cgroup assignments of malicious processes can aid in identifying the scope of the compromise, the attacker\u0026rsquo;s objectives, and the affected systems.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eMonitor process creation events and collect the associated cgroup path to establish baselines of normal system behavior, especially within containerized environments.\u003c/li\u003e\n\u003cli\u003eDeploy the provided Sigma rule to detect unexpected processes running within Docker containers based on the cgroup path.\u003c/li\u003e\n\u003cli\u003eUse the provided Sigma rule to detect processes running under user-level systemd services, correlating with user login sessions to identify anomalous behavior.\u003c/li\u003e\n\u003cli\u003eInvestigate processes with unusual cgroup assignments, particularly those lacking expected container or systemd associations.\u003c/li\u003e\n\u003cli\u003eCorrelate cgroup information with other telemetry, such as network connections and file modifications, to gain a more comprehensive understanding of attacker activity.\u003c/li\u003e\n\u003cli\u003eUtilize the \u003ccode\u003esystemd-cgls\u003c/code\u003e command on Linux systems to list all active cgroups and their associated processes for manual investigation and validation of detection rules.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-05-13T13:03:36Z","date_published":"2026-05-13T13:03:36Z","id":"https://feed.craftedsignal.io/briefs/2026-05-linux-cgroups/","summary":"This brief outlines how Linux cgroups, a kernel feature for resource management, can be repurposed to provide valuable telemetry for detecting malicious processes, particularly in systemd, Docker, and Kubernetes environments, aiding in investigations of server compromises.","title":"Leveraging Linux Cgroups for Threat Detection and Investigation","url":"https://feed.craftedsignal.io/briefs/2026-05-linux-cgroups/"}],"language":"en","title":"CraftedSignal Threat Feed — Systemd","version":"https://jsonfeed.org/version/1.1"}