Ddos 
As containers become the backbone of modern software deployment, many organizations still misjudge their isolation guarantees — and attackers are taking notice. In a new technical deep dive, Kaspersky Labs exposes the invisible attack surfaces lurking inside containerized environments, warning that “this isolation is often overestimated.”
While containers encapsulate applications and their dependencies, they still share the host system’s kernel, which presents a unique set of challenges for threat detection and incident response. According to Kaspersky:
“Every process inside a container technically runs on the host, but within a separate namespace.”
This architectural reality blurs the lines between host and container-level activity — especially when visibility tools aren’t configured to distinguish them.
One of the key findings from Kaspersky’s frontline incident response work is the lack of visibility in containerized environments:
“Many organizations focus on monitoring containerized environments for operational health rather than security threats… Some lack the expertise to properly configure logging.”
This results in detection blind spots. Even host-based logs often don’t capture namespace or cgroup identifiers, making it difficult to trace the origin of an attack.
Kaspersky breaks down how container creation works — from runc in foreground mode (where runc remains the parent process) to detached mode (where a shim process manages the container’s lifecycle):
“In detached mode… the runc process will create it and immediately exit. Hence, the parent process of the container is the host’s PID 1 (systemd process)… unless the shim process sets itself as a subreaper.”
The report shows how understanding the parent-child relationship of processes is key to identifying whether an activity originated inside a container.
In stripped-down container images like BusyBox or Alpine, attackers often leverage minimalist shells to execute payloads or install dependencies. Kaspersky illustrates how:
“/bin/sh is replaced by the /bin/busybox on the BusyBox-based containers… all shell commands are either executed directly by the BusyBox process or are launched as child processes under the BusyBox process.”
Kaspersky’s investigation includes recent compromise assessments, such as:
- Docker CLI installed inside a running container, enabling attackers to communicate with Docker’s APIs from within the compromised environment.
- A malicious container spawned via base64-encoded command strings embedded in suspicious entrypoints.
- Discovery of a systemd-named process with a binary path pointing to /.redtail — later traced back to a compromised container.
“By tracking the parent processes… we confirmed the container in which the command was executed by checking the command-line argument of the shim process.”
Kaspersky urges defenders to analyze execution chains using host-based telemetry and understand the nuances of container runtime behavior.
Donate