On 20 February 2018, cloud security company RedLock revealed that attackers had broken into a Tesla cloud environment and used it to mine cryptocurrency. According to RedLock, as reported by Fortune, eWeek and Security Affairs, the intruders got in through a Kubernetes administration console that had no password. Inside one Kubernetes pod they found access credentials for Tesla's Amazon Web Services (AWS) environment, which reached an Amazon S3 bucket holding sensitive data including vehicle telemetry. The attackers ran Stratum mining software and took steps to hide it: a private mining pool, traffic hidden behind CloudFlare, non-standard ports and throttled CPU use. RedLock found the intrusion while trying to trace the owner of exposed AWS credentials and reported it to Tesla, which paid a bug bounty. Tesla said it fixed the problem within hours and that the impact appeared limited to internally used engineering test cars, with no sign that customer privacy or vehicle safety was compromised.
Key takeaways
- Tesla's Kubernetes administration console was reachable without a password, according to RedLock, and attackers used it to run cryptocurrency miners on Tesla's cloud infrastructure.
- RedLock says access credentials for Tesla's AWS environment were exposed inside one Kubernetes pod, opening an S3 bucket with telemetry data. Fortune reported that mapping and vehicle servicing data were also potentially exposed.
- The miners avoided detection by using a private pool, hiding behind CloudFlare, using non-standard ports and keeping CPU use low, according to RedLock as reported by eWeek and Fortune.
- Tesla said it fixed the issue within hours of RedLock's report and found no indication that customer privacy or vehicle safety was affected. How long the attackers had access and how much they mined is not known.
- The identity lesson: a cloud credential stored in a workload is exposed to anyone who can reach that workload's control plane.
At a glance
| Organisation | Tesla |
|---|---|
| When | Intrusion date not published; Security Affairs places it in 2017. Disclosed by RedLock on 20 February 2018 |
| Attacker | Unknown cryptojacking actor; found by RedLock's Cloud Security Intelligence team |
| Entry point | A Kubernetes administration console exposed without password protection |
| Identities abused | AWS access credentials exposed inside a Kubernetes pod, which gave access to an Amazon S3 bucket; Tesla's cloud compute used for mining |
| Impact | Unauthorised cryptocurrency mining on Tesla's infrastructure; potential exposure of telemetry, mapping and vehicle servicing data; Tesla says impact was limited to internal engineering test cars |
| Category | NHI. Incident class: confirmed NHI breach (exposed AWS credentials and compute abused for cryptojacking) |
What happened
RedLock, a cloud security start-up, published the Tesla findings as part of a wider report on cloud security. Fortune, which reported the story on 20 February 2018, said RedLock's researchers came across the intrusion while trying to identify who owned a set of publicly exposed AWS credentials. Following them led to Tesla's Kubernetes console, the web interface used to manage containers, which had no password. "We weren't the first to get to it," RedLock's chief executive Varun Badhwar told Fortune.
In its blog post, reproduced by Security Affairs, RedLock wrote: "Within one Kubernetes pod, access credentials were exposed to Tesla's AWS environment". Those credentials reached an Amazon S3 bucket that held sensitive data, including telemetry. The attackers had deployed cryptomining software, which Fortune identified as Stratum mining software, and worked to stay hidden. According to RedLock's findings as reported by eWeek and Fortune, they did not use a public mining pool, hid their IP addresses behind CloudFlare, used non-standard ports and kept CPU usage low. The researchers told Fortune they did not know which cryptocurrency was mined, how much was made, or how long the intruders had access. Badhwar said the team "didn't try to dig in too much" once they understood what they had found.
RedLock notified Tesla, which addressed the issue and paid the researchers $3,133.70 through its bug bounty programme, according to Fortune. A Tesla spokesperson said the company maintains "a bug bounty program to encourage this type of research" and dealt with the vulnerability "within hours of learning about it". "The impact seems to be limited to internally-used engineering test cars only," the spokesperson said, adding that "our initial investigation found no indication that customer privacy or vehicle safety or security was compromised in any way."
RedLock presented Tesla as one example of a wider problem. Its chief technology officer, Gaurav Kumar, told eWeek that "The RedLock CSI team has found hundreds of unprotected Kubernetes admin consoles in the past few months", and the report said 8% of organisations it studied had been affected by cryptojacking.
Timeline
| Date | Event |
|---|---|
| 2017 | Attackers compromise Tesla's Kubernetes console and begin mining, according to Security Affairs; the exact start is not published. |
| 2018 | RedLock finds the intrusion while tracing exposed AWS credentials and reports it to Tesla, which fixes it and pays a bug bounty. |
| 20 February 2018 | RedLock publishes its findings; Fortune reports the Tesla intrusion. |
| 21 February 2018 | eWeek reports the wider RedLock findings, including hundreds of unprotected Kubernetes consoles. |
How it happened: the identity attack path
- Open control plane. Tesla's Kubernetes administration console was reachable from the internet without a password, giving anyone who found it control over the containers it managed.
- Credentials inside a pod. One of the pods held access credentials for Tesla's AWS environment, readable through the console.
- Cloud access. The credentials reached an Amazon S3 bucket with telemetry and other data, according to RedLock.
- Compute hijacked. The attackers deployed mining software and ran it on Tesla's cloud infrastructure.
- Hiding in plain sight. A private pool, CloudFlare, non-standard ports and low CPU use kept the activity from standing out, until RedLock traced the exposed credentials back to Tesla.
Impact
- Confirmed: unauthorised cryptocurrency mining on Tesla's cloud infrastructure, and AWS credentials exposed to whoever reached the console.
- Potential data exposure: an S3 bucket with telemetry data, and according to Fortune also mapping and vehicle servicing data. Badhwar told Fortune it did not contain personally identifiable information as such.
- Tesla's position: impact limited to internally used engineering test cars, with no indication that customer privacy or vehicle safety or security was compromised.
- Unknown: how long the attackers had access, which coin they mined and how much they earned.
What this means for NHI governance
Cryptojacking is often treated as a nuisance, but the Tesla case shows the identity chain behind it. A management interface without authentication gave access to workloads, the workloads carried a cloud credential, and that credential reached both compute and stored data. The attackers chose to mine, but the same access could have been used to read or change what was in the bucket. Every link in that chain was a non-human identity or a machine interface that nobody was watching.
The fixes are well understood today: authenticate every Kubernetes management surface, never store cloud keys in pods, give workloads short-lived credentials through workload identity federation, and alert on unusual compute use and outbound traffic. Later incidents such as the Amazon AWS Crypto-Mining Campaign 2025 and the Imperva breach 2019 show the same pattern of AWS keys taken from exposed compute. Our Kubernetes NHI Security Guide and Cloud Workload Identity Guide cover the controls.
Recommendations
- Require authentication on every Kubernetes management interface. Dashboards and API servers should never be reachable anonymously, and ideally not from the internet at all. See our Kubernetes NHI Security Guide.
- Remove static cloud keys from pods. Use workload identity so pods receive short-lived, narrowly scoped credentials instead of long-lived access keys. See the Cloud Workload Identity Guide.
- Scope workload credentials to what the workload needs. A pod's credential should not read unrelated S3 buckets or launch arbitrary compute. See the Cloud PAM and CIEM Guide.
- Restrict outbound traffic. RedLock recommended a deny-all default for outbound cloud traffic, which blocks miners from reaching their pools.
- Monitor compute use and configuration changes. Alert on unexpected workloads, sustained CPU use and changes to cluster configuration, and investigate rather than tune out.
- Rotate credentials after any exposure. Treat every credential reachable from an exposed console as compromised. See the Leaked Credential Response Playbook.
Frequently asked questions
How was Tesla's cloud hacked in 2018?
According to RedLock, attackers found a Tesla Kubernetes administration console that had no password, used it to reach a pod holding AWS access credentials, and used Tesla's cloud resources to mine cryptocurrency while hiding the activity.
Was Tesla customer data stolen in the cryptojacking attack?
Tesla said its initial investigation found no indication that customer privacy or vehicle safety or security was compromised, and that the impact appeared limited to internally used engineering test cars. An S3 bucket with telemetry data was reachable with the exposed credentials, according to RedLock.
What is cryptojacking?
Cryptojacking is the use of someone else's computing resources to mine cryptocurrency without permission. In cloud environments it usually starts with stolen or exposed credentials, or an unprotected management interface, and the victim pays for the compute.
Related NHI Mgmt Group resources
Amazon AWS Crypto-Mining Campaign 2025 · Imperva Breach 2019 · Capital One Breach 2019 · Kubernetes NHI Security Guide · Cloud Workload Identity Guide
How NHI Mgmt Group can help
Containers and clusters multiply the number of machine identities an organisation runs, often with credentials nobody tracks. We help teams find the cloud keys inside their workloads, replace them with workload identity and lock down the consoles that manage them. See our NHI and AI agent security training.