I returned from the conference at one in the morning) The speaker party did not let me go…

I returned from the conference at one in the morning) The speaker party did not let me go 😂

I promised that I would tell you about the report (I attached my presentation to the previous post in the comments if anyone wanted to watch it). While the official video of my performance has not been released, I will describe everything in text, which we are all already accustomed to

I went to BACON 2026 to give a talk about cryptojacking in Kubernetes. And initially it may seem that the topic is quite simple. Well, what is cryptojacking? Someone climbed onto the server, launched a miner, the CPU flew into space, the admin opened top, saw a suspicious process, killed it and that’s it. Or not all?

Cryptojacking today is a way to monetize access that has already been obtained. First, the attacker somehow gets into the infrastructure, and only then begins to turn other people’s resources into his own cryptocurrency 🤑

And Kubernetes only adds to the fun, because in Kubernetes the attacker can see Pod, Deployment, DaemonSet, ServiceAccount, RBAC, Kubernetes API and many other interesting things in front of his eyes

In 2025, researchers described campaigns that targeted the Docker API, used Tor, pulled payloads from hidden sources, and deployed cryptominers through container infrastructure. Unit 42 in 2026 separately showed that in Kubernetes attacks, after initial access, attackers look at the mounted ServiceAccount token, check rights through the Kubernetes API and only then deliver a secondary load, including miners and backdoors

That is, now we are dealing with the fact that the attacker, conditionally, was able to run his code, looked at the environment, found a token, checked the rights, launched the miner, went outside to connect to the pool and disguised the process as something that seemed adequate at first glance. And that’s it, he has established himself in infrastructure and can now quietly devour the organization’s resources for his own purposes for years.

And if the protection is built only around the CPU load graph, then we will only see the symptom, but will not be able to understand the cause. And this is exactly what I showed in the practical stand at the report

In the process of preparing the report, I assembled a laboratory bench with different namespaces and tools, which together caught their “symptoms” (in the report I called them evidence), and their correlation made it possible to fully analyze the incident. The point was to show that cryptojacking in cuber is covered not by one product, but by an architecture of several layers of protection

At the resource level, we need metrics. Prometheus, Grafana, metrics-server, etc., because it is important for us to see that some workload suddenly started eating CPU

At the network level, you need NetworkPolicy, Calico or Cilium. By default, we prohibit unnecessary egress, and allow only what the service really needs. If an application only needs an internal API, it should not be free to surf the Internet simply because

At the clearance level, you need Kyverno, OPA Gatekeeper or similar Policy Engine. They help prevent strange specifications, latest, images from untrusted sources, privileged Pod, hostPath and other gifts of fate for an attacker from entering the cluster

At the supply chain level we need Trivy, Grype, Syft, Cosign and normal work with images

At the rights level, normal RBAC is needed. If a workload is compromised, it should not be able to read secrets, create a Pod, or view the entire cluster. And if the application does not need the Kubernetes API at all, then it often does not need the automatically mounted ServiceAccount token (so we disable it where it is not needed)

At the runtime level you need Falco, Tetragon or something similar. Because some events can only be seen after the container is launched (shell launch, for example)

And then each layer separately sees only a piece of the picture, while together they record the incident

Therefore, you need to protect yourself from cryptojacking in cuber not by searching for a silver bullet, but by limiting the network, checking images, cutting off unnecessary rights, disabling unnecessary tokens and recording events in runtime

This is what my report at BACON 2026 was about) When the video of the performance comes out, I will also publish it