Containing The Threat: Analyzing Cryptomining Campaigns

The talk opens with a container primer written from the host's point of view. A container is a regular process on the host, isolated by namespaces, which limit what it can see, and cgroups, which limit how much it can use. The speakers show that Docker containers have no resource limits by default, and they walk through capabilities and seccomp profiles, noting that these controls only help when the operator sets them.

The core of the talk is cryptomining activity that has persisted for several years. The speakers report tens of thousands of weekly detections in their telemetry and trace how the TeamTNT actor moved from exposed Redis servers to exposed Docker APIs and later to Kubernetes. The typical flow scans for open endpoints, starts a privileged container, and downloads a miner, then steals credentials and plants SSH keys for persistence. They say they built a comparable setup in under an hour. A live demo compared a prevention product with a detection-only Falco setup: the prevention side killed the miner before memory climbed, while the detection-only side let the miner consume nearly all available memory.

The main takeaway is that an unauthenticated Docker daemon exposed over TCP gives anyone who finds it root-level control, so not exposing it is the only dependable control. TLS authentication and runtime monitoring reduce the risk, and rootless Podman limits what a compromised container can do on the host. The speakers also note that Docker and Redis are moving to drop unauthenticated remote access by default, which may change how this opportunistic activity develops.