CLOUD-BLUEBLEED-2022

On May 12, 2023, Toyota disclosed that a cloud environment managed by its Toyota Connected subsidiary had exposed data on roughly 2.15 million customers, essentially the entire Japanese user base of its T-Connect, G-Link, G-Link Lite, and G-BOOK connected services registered since November 2013. The data was exposed from November 6, 2013 to April 17, 2023, nearly a decade, and included in-vehicle GPS terminal IDs, vehicle chassis numbers, location history with timestamps, and a subset of drive-recorder video footage, but not names, credit cards, or other directly identifying personal data. The root cause was a cloud database misconfigured to be publicly accessible instead of private, attributed to human error during setup and allowing unauthenticated internet access. Toyota cited a lack of active detection mechanisms and insufficient enforcement of data-handling rules, which is why the misconfiguration persisted undetected for years. A follow-up disclosure on May 31, 2023 found additional misconfigured cloud services exposing around 260,000 more customers.

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.

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.

A misconfigured ModSecurity web application firewall on an AWS EC2 instance was abused via server-side request forgery to reach the EC2 Instance Metadata Service at 169.254.169.254 and retrieve the temporary IAM credentials of the WAF's role. Because that role was over-privileged, the attacker used the stolen credentials to exfiltrate data from Capital One's S3 buckets. Roughly 100 million US individuals and 6 million Canadians were exposed, including about 140,000 Social Security numbers and 80,000 linked bank account numbers. Attacker Paige Thompson, a former AWS engineer, was arrested July 29, 2019 and later convicted. The incident directly motivated AWS's release of IMDSv2.

Tesla's Kubernetes administrative console was exposed to the internet without password protection, allowing attackers to access it and discover Tesla's AWS access credentials stored within. The attackers used the environment to run cryptomining software inside Tesla's AWS, employing evasion techniques such as hiding the mining pool behind CloudFlare, using a non-standard mining endpoint, and throttling CPU usage to avoid detection. It was discovered by the RedLock Cloud Security Intelligence team, later part of Palo Alto Networks Prisma Cloud, and Tesla remediated within hours stating no customer or vehicle data was compromised.

On October 10, 2017, UpGuard publicly disclosed that Accenture had left four Amazon S3 buckets exposed, originally found by researcher Chris Vickery on September 17, 2017. The buckets were named acp-deployment, acpcollector, acp-software, and acp-ssl under the Accenture Cloud Platform prefix, with the largest holding 137GB. They were configured for public access, so anyone who entered or guessed the bucket URL could download the contents with no authentication, and because the S3 subdomain matched the bucket name the names were predictable. Exposed material included a master access key for Accenture's AWS KMS account stored in plaintext, internal Identity API credentials, nearly 40,000 plaintext passwords in a database backup, private signing and decryption keys, certificates, VPN keys, and Google and Azure credentials. The root cause was an S3 public-read misconfiguration: buckets that are private by default had been reconfigured to allow anonymous access, contradicting the secure default.