Slide 11 of 28
Part 2 · How It WorksSlide 11
Slide 11 · Real Incident
Tesla — how Pattern 2 played out on a Kubernetes cluster.
February 2018. No password. AWS credentials in plain sight. Cryptominer running for unknown time.
📄 RedLock Cloud Security Intelligence Report · February 2018
TIMELINE
Tesla Kubernetes Breach — Discovered February 2018

The setup: Tesla operated a Kubernetes cluster on AWS for non-production workloads. The cluster had the Kubernetes web dashboard deployed — a legitimate management UI. The dashboard was exposed on the public internet with no authentication. Anyone with the IP and port could access the full cluster management interface.

What attackers saw in the dashboard:

• All running pods and their environment variables — including AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY

• Container logs showing application activity

• The ability to create new pods, exec into existing pods, and modify the cluster

What attackers did: They deployed a cryptomining container — a pod running a Monero miner connected to a mining pool via a proxy to mask traffic. The miner was configured to use minimal CPU to avoid detection. Tesla’s AWS bill funded the mining operation for an unknown period before RedLock discovered it.

How RedLock found it: Automated scanning of cloud environments looking for internet-exposed administrative interfaces. The Kubernetes dashboard was found at a public IP on a non-standard port. The discovery and disclosure to Tesla happened in February 2018. Tesla patched it the same day. The cryptominer had been running for an unknown duration before discovery.
The Kubernetes dashboard default problem

In 2018, the Kubernetes dashboard was not the only instance — RedLock found multiple companies with the same misconfiguration in the same report. The dashboard had been deployed without authentication because the Kubernetes documentation at the time made it easy to deploy without emphasizing that it needed to be secured before any internet exposure.

← Back Pattern 2 mechanics →