INFRA-TESLA-K8S-2018
Kubernetes · Kubernetes admin console (Tesla AWS environment)
Résumé
In 2018, attackers found Tesla's Kubernetes admin console sitting open on the internet with no password. Inside, they found Tesla's AWS cloud keys. But instead of stealing data or causing damage, they did something quieter and increasingly common: they used Tesla's cloud to mine cryptocurrency, on Tesla's bill. And they hid it carefully, throttling the mining and hiding the traffic behind Cloudflare so it would not stand out. It is the textbook cryptojacking case, and a reminder that an exposed dashboard is a door to your cloud account, and that the first sign of a breach is often a suspiciously busy server, not a ransom note.
How it happened
Tesla's Kubernetes administrative console was exposed directly to the internet with no password protection and anonymous access allowed. These consoles are scanned for constantly, so attackers found it, opened it, and discovered Tesla's AWS access credentials stored inside a Kubernetes pod, which granted access to an S3 bucket holding telemetry from Tesla's internal engineering test cars. That turned an open dashboard into access to Tesla's cloud account.
Rather than steal data, the attackers deployed cryptomining software inside Tesla's AWS and went to some lengths to stay hidden: they used custom mining code rather than a known service like Coinhive, ran the mining pool behind Cloudflare with the Stratum endpoint kept unlisted so it dodged threat-intelligence feeds, used a non-standard port, and throttled CPU usage to keep below the thresholds that trigger alerts. The cloud-security firm RedLock (later part of Palo Alto Networks Prisma Cloud) spotted the activity on 30 January 2018, noting it could not tell how long the mining had been running, and reported it. Tesla remediated within hours, paid RedLock a $3,133.70 bug bounty (a leetspeak nod to "1337"), and stated that no customer or vehicle data was compromised.
The damage
The direct harm was modest, stolen compute, plus the exposed AWS keys that could have enabled something far worse. The significance was what it represented: it helped make cryptojacking of cloud environments a mainstream concern, and it showed how an exposed admin console plus cloud credentials stored insecurely is a common, easily-scanned entry point. The careful evasion, throttling and a Cloudflare-hidden pool, illustrated a broader shift toward quiet theft that hides under the radar rather than loud, obvious damage.
Why Tesla-K8s still matters
It is the exposed-dashboard and stored-cloud-credentials lesson. A Kubernetes dashboard on the public internet with no authentication is a wide-open door, and cloud credentials sitting in the environment turn that door into full account takeover. Cryptojacking is also the canary in the coal mine: an attacker who can mine in your cloud can usually do far worse, so a mining hit should be treated as a wake-up call about deeper exposure, not a nuisance. The defences: never expose the Kubernetes dashboard or API to the internet, enforce RBAC with the control plane behind a VPN or allowlist, scope service-account and node IAM to least privilege so a compromised pod cannot reach cloud credentials, enforce IMDSv2, and monitor for unexpected workloads and mining traffic. It is the same cloud-credential-exposure family as the Capital One breach.
Comment le corriger
- Take the exposed console offline, require authentication, and rotate the AWS credentials it exposed immediately.
- Remove the cryptomining workloads and any persistence, and rebuild affected nodes.
- Audit cloud logs for what the stolen credentials touched beyond mining; assume the attacker could have done more.
Comment l’éviter
- Never expose the Kubernetes dashboard or API server to the internet; require authentication and disable anonymous access.
- Enforce RBAC and put the control plane behind a VPN or IP allowlist.
- Scope pod service-account and node IAM to least privilege so a compromised pod cannot reach cloud credentials.
- Enforce IMDSv2 and restrict pod access to the instance metadata endpoint.
- Monitor for unexpected workloads and outbound traffic indicative of cryptomining.
Références
Vulnérabilités liées
Tout Infra →- HIGHCLOUD-POWERAPPS-2021
On August 23, 2021, UpGuard disclosed that misconfigured Microsoft Power Apps portals exposed roughly 38 million records across 47 organizations, including American Airlines, Ford, J.B. Hunt, the Maryland Department of Health, the State of Indiana, New York City agencies, and Microsoft itself. Exposed data included names, email addresses, phone numbers, social security numbers, and COVID-19 contact tracing and vaccination appointment information. Power Apps portals surface list data through OData list feeds reachable at predictable URLs, and access to those feeds is gated by Table Permissions, but Table Permissions were disabled by default on every list. Because security was opt-in, any portal where a developer enabled an OData feed without explicitly configuring and enabling Table Permissions returned its records to any unauthenticated visitor querying the OData endpoint. This is an insecure-default access-control misconfiguration where the platform defaulted to anonymous read rather than deny.
- HIGHCLOUD-KUBELET-HILDEGARD-2021
On February 3, 2021, Palo Alto Networks Unit 42 reported Hildegard, the first known TeamTNT campaign targeting Kubernetes, detected in January 2021. The attackers gained initial access through a misconfigured kubelet: the kubelet read-write API on port 10250 was reachable and accepted anonymous, unauthenticated requests because it was configured with --anonymous-auth set to true and --authorization-mode set to AlwaysAllow, the insecure legacy defaults shipped by some self-managed clusters. Anyone who could reach port 10250 could call the kubelet run-command API to execute commands inside running pods with no credentials. The attackers used this to exec into pods, move laterally across containers, scan for more exposed kubelets, and harvest cloud access keys, SSH keys, Docker credentials, and service-account tokens from the environment. They then deployed the XMRig Monero miner for cryptojacking, using a tmate reverse shell and IRC for command and control and LD_PRELOAD injection to hide processes. The misconfiguration class is missing authentication caused by an insecure default on an internet-reachable management port.
- CRITICALINFRA-MONGODB-2017
Tens of thousands of MongoDB instances were left exposed to the internet with no authentication on the admin account, a known insecure default in older versions. Multiple attacker groups scanned the internet via Shodan, connected anonymously, exfiltrated or deleted the database contents, and left a ransom note demanding Bitcoin. By early January 2017 roughly 10,500 servers, about a quarter of all internet-facing MongoDB databases, were hit, and cumulative waves through 2017 ruined over 45,000 databases. Many victims who paid recovered nothing because competing crews overwrote each other's ransom notes and in many cases never copied the data.
- HIGHCLOUD-ENVFILE-EXTORTION-2024
On August 15, 2024, Palo Alto Networks Unit 42 detailed a large-scale extortion campaign that compromised cloud environments by harvesting exposed environment variable files. Attackers scanned at least 110,000 domains and collected over 90,000 unique variables, including roughly 7,000 cloud service credentials and 1,515 social media credentials, with their infrastructure probing around 230 million targets. The vector was a web server misconfiguration: .env files inside the web root were served as plaintext over HTTP because the servers had no rule denying access to dotfiles, exposing the long-lived AWS IAM access keys hardcoded inside. The initial IAM principals lacked full admin but retained permission to create roles and users, so attackers called CreateRole and attached AdministratorAccess to escalate, then spun up Lambda functions across regions to automate further internet-wide scanning. They used the victims' own AWS accounts to exfiltrate and delete S3 objects, then uploaded ransom notes demanding payment. The failure chain combined exposed dotfiles, long-lived hardcoded credentials, and over-permissioned IAM, not any cloud-provider flaw.
- CRITICALCONTAINER-EXPOSED-DOCKER-API
Exposed Docker API is a recurring misconfiguration class in which the Docker remote API (default TCP 2375 plaintext, 2376 TLS) is published to untrusted networks without TLS or authentication, granting anyone who reaches it full control of the daemon. Because dockerd runs as root and the unauthenticated API permits arbitrary container creation, an attacker can launch a privileged container that bind-mounts the host root filesystem and then chroots into it to escape to the host. The Commando Cat campaign, reported in 2024 by Cado Security and analyzed by Trend Micro (advisory dated 13 June 2024), abused exactly this exposure: it deployed a benign image (cmd.cat/chattr) generated by the open-source Commando project, then used chroot and volume binding of the host's root directory into the container to break out and run host-level payloads. The delivered payloads installed cryptocurrency miners, registered persistence and a stealthy backdoor (including DropBear SSH on TCP 3022), and exfiltrated host and cloud-service-provider credentials. Shell-script and command-and-control infrastructure overlapped with the TeamTNT cryptojacking group.
- HIGHCLOUD-IAC-TFSTATE-EXPOSURE
Exposed Terraform state is an Infrastructure-as-Code hygiene failure class in which the terraform.tfstate file leaks credentials because Terraform records every managed resource attribute, including secrets, in cleartext JSON by default. HashiCorp documents that Terraform stores state in a plaintext file that includes any secret values defined in the configuration, so database passwords, IAM access keys, TLS private keys, and API tokens are written verbatim into state. The exposure paths are concrete and repeatedly observed: state committed to a public or private git repository without a .gitignore rule, state left in a world-readable or misconfigured S3 bucket, state captured in CI/CD logs, or state held in a remote backend that lacks encryption at rest and access controls. Numerous terraform.tfstate files have been found in public GitHub repositories and open S3 buckets, and because the file is effectively a master key to the infrastructure, an attacker who reads it obtains working credentials and bypasses the perimeter entirely without exploiting any vulnerability.