Follow the Access · 08 — The Exposed Docker Socket: Root on the Host, Handed Over by the API

Follow the Access — Case 08. This register follows the intruder from the login prompt to the foothold's fate, and closes each case on what the access becomes: RANSOMED · MINED · PROXIED · HARVESTED · WIPED · RESOLD.

Case 01 mined a default-password router — a single cheap machine, a trickle of stolen compute. This case mines the same crime at industrial scale, because the machine it takes is not a router but an engine designed to run arbitrary workloads across a fleet of servers. When an organization builds modern infrastructure, it uses container orchestration — Docker to package and run applications, Kubernetes to schedule them across many machines. These systems are controlled through APIs: a Docker daemon socket, a Kubernetes API server. And when one of those control interfaces is left reachable on the internet without authentication, the attacker who finds it does not get a foothold on one box. He gets the ability to launch workloads on the whole platform, and launching a workload, it turns out, is the same as becoming root.

That is the pivot of the case, and it is worth stating precisely because it is not obvious. The Docker socket does not advertise itself as a root shell; it advertises itself as a way to manage containers. But a container is just a process the host runs, and the API lets the attacker define that process however he likes — including a container that mounts the host's entire filesystem and runs as the root user. So the ability to start a container is, in practice, the ability to read and write every file on the host as root, which is total control. An exposed, unauthenticated Docker API is a remote root shell wearing the costume of a REST interface. A Kubernetes API is the same, multiplied across every node in the cluster.

And the fate of that stolen engine is MINED. The crews who specialize in this vector — Kinsing, TeamTNT, and their kind — are cryptojacking operations, and the exposed orchestrator is almost the perfect target for them: a machine built to run workloads at scale, on elastic cloud compute, billed to someone else. They spin up mining containers, the CPUs roar, the Monero flows, and the victim pays the electricity — or worse, the cloud bill, which the miner can drive into the thousands. This is the case about the API that hands over root, and the crews who use it to turn other people's clouds into mining rigs.

1. Why Launching a Container Is Owning the Host

Begin with the technical fact that makes this vector so dangerous, because everything follows from it. Containers are often described as isolated, lightweight, sandboxed — and they can be, when configured carefully. But that isolation is a set of restrictions the host chooses to apply, not a wall the container is trapped behind by nature. The Docker API lets whoever controls it define a container without those restrictions. In particular, it lets him launch a container that mounts a host directory — including the root directory, the entire host filesystem — into the container, and run that container as root. Once he does, he is a root process with the host's whole disk mounted inside his reach. He can read every secret, write to every file, add himself to the system, replace binaries, install anything. He is root on the host, obtained not by exploiting the host at all but by asking the container API, politely, to run a container he designed for the purpose.

This is why network exposure of the Docker socket is catastrophic in a way that exposure of an ordinary application is not. An exposed web app might have a vulnerability; an exposed Docker socket is the vulnerability, by design, because its entire function is to run workloads with host-level power and it was never meant to be reached by strangers. It historically listened on port 2375 for remote management, and administrators sometimes enable that for convenience without the TLS authentication that is supposed to protect it — at which point the most powerful interface on the machine is answering to the open internet with no password. The Kubernetes API server is the same principle at cluster scale: it controls the scheduling of workloads across many worker nodes, so an unauthenticated or internet-exposed API server hands the attacker the ability to run containers on any node, and thus root across the fleet.

The general lesson, which the register will meet again, is that orchestration interfaces are privilege interfaces. Their job is to command infrastructure, so access to them is access to the infrastructure they command. Treating the Docker socket or the Kubernetes API as "just a management endpoint" that can be exposed for convenience is a category error: they are not endpoints that grant management, they are endpoints that grant control, and control of a machine that runs arbitrary containers is control of the machine. The attacker does not break in. He is handed the keys, because the keys were left in a door labeled "management" that was actually the door to root.

2. The Crews Who Industrialized It

Now the actors, because this vector, more than most, belongs to specific, well-documented, industrialized operations, and understanding them explains the disposition. The names that recur are Kinsing and TeamTNT — cryptojacking crews that built their entire business around cloud-native misconfiguration. Their operations are automated end to end: continuously scan the internet for exposed Docker APIs, unauthenticated Kubernetes clusters, and related cloud services; when one is found, launch a container or workload; inside it, install an XMRig-based Monero miner; connect the miner to a pool; and, characteristically, also spread — scanning from the newly compromised infrastructure for the next exposed orchestrator, and harvesting any cloud credentials found on the host to pivot deeper into the victim's cloud account.

What makes these crews the embodiment of the MINED disposition is their single-mindedness. They are not opportunists who take whatever they find and decide later what to do with it; they are miners, specialized and efficient, whose entire tooling is oriented toward one outcome: convert the seized compute into cryptocurrency as quickly and quietly as possible. They do not negotiate, do not extort, do not exfiltrate for sale — those would draw attention and require effort. They mine, because mining is the frictionless monetization of exactly the resource an orchestrator provides in abundance: compute. Their scanning is relentless and their turnaround is fast; an exposed Docker socket can be found and mining within minutes of appearing, because the crews' scanners never stop and the payload deployment is fully automated.

And they fit the target as much as the target fits them. An orchestrator is a machine whose whole purpose is to run containers; a miner is a container. There is no impedance mismatch, no clever adaptation required — the attacker uses the platform exactly as designed, to run a workload, and the workload happens to be theft. This is why cloud cryptojacking through exposed orchestration is such a stable, enduring crime: the crews are specialized and automated, the target is abundant and self-advertising to a scanner, and the abuse is a native use of the platform rather than a subversion of it. The exposed Docker socket does not have to be tricked into mining. It just has to be told to, by someone who was never supposed to be able to tell it anything.

3. MINED — Cloud Compute Is the Ideal Thing to Steal

Now the disposition, and the exposed orchestrator earns MINED more richly than the humble router of Case 01, because the compute it offers is not a trickle but a torrent, and the theft is not merely of electricity but of money billed directly to the victim. The economics of cloud cryptojacking are what make this vector so lucrative and so damaging.

Consider what the attacker seizes. Not a single low-power device, but a platform designed to run heavy workloads across many servers — and increasingly, a platform running on cloud infrastructure with elastic, auto-scaling, pay-per-use compute. When the miner starts and drives the CPUs to maximum, several things happen that compound the theft. The victim's compute is consumed, degrading whatever legitimate workloads the platform was running. The electricity, if it is the victim's own hardware, is drawn at full tilt. But if it is cloud compute — and much orchestration is — the consumption becomes a bill: the victim is charged, by the hour, by the CPU, for the resources the miner is burning. And then the cruelest multiplier engages. Cloud platforms auto-scale: when load rises, they provision more capacity to handle it. The miner's load looks, to the platform, like legitimate demand, so the platform obligingly spins up more nodes — which the miner also seizes and drives to maximum, which looks like more demand, which triggers more scaling. It is a runaway loop that maximizes the attacker's hash rate and the victim's bill in lockstep, and it can run for days before anyone notices the CPU graphs pinned at the ceiling or the invoice climbing into the thousands.

So the disposition is MINED, and it is the same crime as Case 01 in kind and a vastly larger one in degree. The default-password camera gave the attacker one weak CPU and cost its owner a few watts. The exposed Kubernetes cluster gives the attacker a fleet of powerful CPUs, growing on demand, and costs its owner real money extracted directly from their cloud account. It is MINED rather than RANSOMED because the crews who specialize here are miners by trade and because the machine is a compute engine begging to be used as one — the path of least resistance from "I control this orchestrator" to "I have money" runs straight through mining, with no victim to negotiate, no data to steal and fence, no attention to attract. The orchestrator is the ideal thing to mine because it is, definitionally, a machine for running compute-heavy workloads at scale, and mining is a compute-heavy workload. The attacker did not repurpose the engine. He simply fed it the fuel it was built to burn, and pocketed the exhaust.

4. The Boundary That Keeps Breaking

Pause on the container boundary, because the defense of this vector leans heavily on isolation, and isolation is exactly what keeps failing. The comforting story about containers is that even if one is compromised, it is sandboxed — the attacker is trapped inside the container, unable to reach the host. If that were reliably true, an exposed Docker socket would be far less dangerous, because the mining container would be confined. The trouble is that the boundary is porous by configuration and breakable by flaw.

By configuration, because the Docker API itself lets the attacker request a container without the boundary — mounting the host filesystem, running privileged, mapping the host network, or mounting the Docker socket into the container so the container can control Docker in turn. The isolation is opt-in from the attacker's side: he simply declines it when he defines his container. And by flaw, because even when isolation is meant to be enforced, vulnerabilities erode it. The Docker Desktop Enhanced Container Isolation bypass, catalogued as CVE-2026-6406, is a representative example: a flag intended for legitimate use could be abused to mount the Docker socket into a container despite the isolation feature that was supposed to prevent exactly that, re-exposing the host-control primitive the isolation was designed to deny. It belongs to a long, recurring class of container-escape and socket-exposure flaws — the boundary between container and host is one of the most probed surfaces in modern infrastructure, and it is breached with regularity.

The lesson is that isolation is a control to be maintained, not a guarantee to be assumed. Defenders who reason "the miner is only in a container, so the host is safe" are relying on a boundary that the attacker may have declined at launch, or that a flaw may have dissolved. The exposed orchestrator is dangerous precisely because it lets the attacker choose his own level of isolation — and he will always choose none. This is why the primary defense cannot be "contain the container" but must be "never let the stranger reach the API at all," because once he can command the orchestrator, he can command it to give him a container with no boundary, and the sandbox becomes a formality he simply opts out of. The wall exists, but the API hands the attacker the authority to build his room without it.

5. Guarding the Interface That Hands Out Root

The register owes the defense, and here it is clear in principle and specific in practice, because the vector is fundamentally about access to a privilege interface: guard that interface as you would guard root, because it is root. The measures follow directly from that framing.

First and above all: never expose the Docker daemon socket to the network. It should be managed locally, over the Unix socket, or if remote management is truly needed, only over mutually authenticated TLS so that no unauthenticated stranger can reach it. An internet-facing Docker socket on port 2375 with no TLS is not a configuration to harden — it is one to eliminate, immediately, because it is a public root shell. Second, for Kubernetes: never leave the API server unauthenticated or reachable from the open internet; require strong authentication, enforce role-based access control so that even authenticated identities have only the permissions they need, and restrict the API server's network exposure to the administrators and systems that legitimately require it. Third, sever the container-to-host path: do not mount the Docker socket into containers (the very thing CVE-2026-6406 abused), run containers unprivileged and without host filesystem mounts by default, and treat any workload that requests host-level access as a red flag requiring justification. Fourth, patch the isolation flaws promptly, because the boundary is only as good as its current version. And fifth, monitor for the signatures of this specific abuse: sustained maximum CPU, unexpected container or pod launches, outbound connections to mining pools, and cloud bills or auto-scaling events that do not match legitimate demand.

That last measure deserves emphasis, because it is the safety net when the perimeter fails. Cloud cryptojacking is loud in one dimension even as it is quiet in others: it pins the CPU. A victim watching resource utilization and cloud spend will see the miner as a sustained, unexplained maximum where there should be variable, workload-driven usage — and the runaway auto-scaling that makes the theft so expensive also makes it, if anyone is looking, unmistakable. The tragedy of the thousands-of-dollars cloud cryptojacking bill is that the signal was blazing the whole time; no one was watching the graph. So the defense is two-layered: keep the stranger away from the orchestration API, which prevents the compromise, and watch compute and cost for the runaway signature, which bounds the damage when prevention fails. The orchestrator hands out host-level power through its API; the defense is simply to treat that API with the gravity that power deserves, which — as the steady success of Kinsing and TeamTNT attests — far too many deployments do not.

6. The counter-narrative, steelmanned

The strongest objection to this case is that it describes an obsolete misconfiguration — that no competent team exposes a raw Docker socket to the internet anymore, and that managed cloud platforms have made this vector a solved relic.

The argument runs like this. Exposing port 2375 without TLS is a beginner's error that the industry moved past years ago; modern Kubernetes distributions authenticate by default, managed cloud services (EKS, GKE, AKS) do not expose unauthenticated API servers, and the whole cloud-native ecosystem has matured around secure defaults. The Kinsing and TeamTNT campaigns, the objection continues, thrived in an earlier, sloppier era of container adoption and are now hitting a shrinking pool of the careless; treating this as a live, first-rank vector overstates a threat that good defaults have largely designed away. And dwelling on the runaway-cloud-bill horror story, the objection adds, is fear-mongering — cloud providers now have anomaly detection and spending alerts that catch cryptojacking quickly. On this view the exposed orchestrator is a fading vector kept alive mainly by a diminishing tail of misconfigured legacy deployments.

The register concedes the maturation and denies the obituary. Yes, secure defaults have spread, managed platforms authenticate, and the rawest exposures are rarer than they were — genuine progress, and the case is glad of it. But the cloud-native attack surface has grown far faster than the defaults have secured it: every self-managed cluster, every developer's exposed Docker host, every CI/CD runner, every misconfigured RBAC policy that grants too much, every legacy deployment predating the good defaults, and every new team learning containers the way earlier teams learned Redis — in a safe local environment, then shipped carelessly to a dangerous one. The Kinsing and TeamTNT operations have not retired; they persist and adapt precisely because the supply of misconfiguration is continuously replenished by the breakneck pace of cloud adoption, and their continued documentation by threat researchers is the evidence. The claim that managed platforms are safe is true and beside the point: the vector lives in the vast space of self-managed and misconfigured orchestration that sits alongside the managed platforms, and that space is enormous and growing. On the cloud-bill point: anomaly detection helps and the case recommends exactly that monitoring, but the recurring reality of large surprise cryptojacking bills demonstrates that the alerts are frequently unconfigured or unwatched — which is the same gap between available control and applied control that runs through every case in this register. The exposed orchestrator earns its place not as a legacy curio but as the industrial-scale version of the register's oldest crime: the compute engine, seized through an interface that hands out root, and made to mine.

7. Disposition — MINED

Case 08 followed the exposed container-orchestration API — the Docker daemon socket on port 2375, the unauthenticated Kubernetes API server — and the pivot that makes it so dangerous: launching a container is owning the host, because the API lets the attacker define a container that mounts the host as root, and the Kubernetes API multiplies that across the cluster. It is not an endpoint that grants management; it is an endpoint that grants control, left answering to strangers. The crews who work it — Kinsing, TeamTNT, and their kind — are industrialized cryptojacking operations, scanning relentlessly and deploying automatically, and the container boundary they are supposed to be trapped by is one they simply decline at launch or dissolve with an isolation flaw like CVE-2026-6406.

The disposition — the foothold's fate — is MINED. The exposed orchestrator is almost the perfect cryptojacking target: a machine built to run compute-heavy workloads at scale, on elastic cloud compute billed to the victim, so the attacker spins up mining containers and the CPUs roar and the Monero flows while the owner pays. And cloud elasticity makes the theft self-amplifying — the miner's load triggers auto-scaling that provisions more nodes the miner also seizes, a runaway loop that maximizes the attacker's hash rate and the victim's bill together, into the thousands of dollars, before anyone looks at the graph. It is MINED rather than RANSOMED because the crews are miners by trade and the machine is a compute engine begging to be used as one; the same fate as the default-password router of Case 01, at a scale larger by orders of magnitude. The honeypot beneath these words confirms the destination even through a different door: its most common captured payload is the very XMRig-based miner these crews deploy.

The defense is to treat the API with the gravity of the power it hands out: never expose the Docker socket, authenticate and restrict the Kubernetes API, sever the container-to-host path, patch the isolation flaws, and — the safety net — watch compute and cost for the runaway signature that cryptojacking cannot hide. The vectors do not lie: the interface labeled "management" was the door to root, a scanner found it, a container was launched that mounted the whole host, and the victim's cloud became a mining rig that grew every hour it went unwatched. We do not judge. We record. We let people judge — and then, if they are wise, guard the API that hands out root as if it hands out root.

Follow the Access continues. Case 08 disposition: MINED. Confidence: HIGH — the Docker/Kubernetes security model (container-as-root-on-host via the API) is documented platform behavior; the cloud-native cryptojacking crews (Kinsing, TeamTNT) and their scan-and-mine operations are extensively documented in public threat reporting; the container-isolation bypass (CVE-2026-6406) is a public CVE; and the honeypot's own dominant payload capture (RedTail/elf.xmrig) is exactly the miner these crews deploy — corroborating the destination of the vector even though the honeypot most often observes the credential door of Cases 01–02. The self-amplifying cloud-bill dynamic is drawn from documented cloud cryptojacking economics. The MINED-vs-RANSOMED divergence is argued from the crews' specialization and the machine's nature. Classification: TLP:WHITE. Include everything — the vectors do not lie, and they do not judge. The reader judges the management door that was really the root door.