The Key That Should Not Have Worked

The number that made this story travel was 800,000 - the count of electric vehicles whose owner data sat exposed in Amazon cloud storage for months. For roughly 460,000 of them, the location data was precise enough to place a car within about ten centimetres.

Not "somewhere on this street." Which parking space. Which side of the driveway. Repeated over time, that is not location data, it is a movement profile - and reporting indicated the affected owners included politicians, business leaders and law enforcement officers.

But the detail that should change how you run your own estate is not the precision of the data. It is how the researchers got to it.

What happened

In late November 2024, an anonymous whistle-blower brought a finding to the Chaos Computer Club, Europe's largest ethical hacker association. The CCC investigated, confirmed it, and notified Cariad - Volkswagen Group's software subsidiary - on 26 November 2024. They gave the group 30 days to close it before going public, and separately alerted Lower Saxony's State Data Protection Officer and the Federal Ministry of the Interior.

Der Spiegel published in late December.

Terabytes of data collected from connected vehicles across Volkswagen, Audi, SEAT and Skoda had been reachable in Amazon cloud storage for months. Cariad attributed it to incorrect configuration in two of its IT applications. Alongside precise GPS coordinates and vehicle status, the exposure included names, email addresses, phone numbers and home addresses.

Cariad's technical team closed the access promptly once notified, and stated that no passwords or payment data were involved, and that the CCC had access only to data collected from vehicles rather than to the vehicles themselves.

The chain, and the link that mattered

Researchers found a memory dump from an internal Cariad application. Inside it were access keys to the Amazon cloud storage instance where vehicle data was kept.

It is tempting to file this as an application security failure - an application exposed a memory dump, so fix the application. That reading is incomplete, and it leads teams to the wrong remediation. It's also tempting to read this as a permissions problem - that the keys simply had too much access. Narrowing what the keys could do wouldn't have changed the outcome: they'd still have worked for whoever found them. The failure wasn't the scope of the access. It was that the access, once copied out of memory, was still valid.

An attack chain is made of several links, and you only have to cut it once. This one had three:

1. An internal application exposed a memory dump.
2. That dump contained long-lived, reusable cloud access keys.
3. Those keys carried no further check on who was presenting them - no MFA, no conditional access, no context. Whoever had the key had the access.

Link one belongs to application security, and it always will. Link three follows automatically from link two - a reusable key works wherever it is presented, which is the entire point of a reusable key.

Link two is the one worth arguing about, because it is the one most organisations have quietly filed under bad luck. It is not bad luck. It is a configuration decision that somebody made, probably years earlier, probably for good reasons at the time.

The dump was the delivery mechanism. The credential being reusable was the misconfiguration.

Why "the credential leaked" is a configuration problem

Most organizations treat leaked credentials as an unfortunate reality to be managed. Scan the repositories. Rotate on discovery. Train the developers. Accept that some will get out.

That framing made sense when there was no alternative. There is now.

It helps to rank the ways machines and people actually prove who they are, from weakest to strongest.

• Anonymous or wildcard access. Azure anonymous access, AWS access granted to all principals, any wildcard permission model. Once the resource is discovered and reachable, anyone may be able to reach it. This should never be used for sensitive resources.
• ‍Password authentication. Predictable and leakable. Passwords are reused, patterned and guessable, exposed in compromised repositories or shared in a chat window. The human factor remains one of the weakest parts of cloud identity.‍
• Access keys. Stronger than passwords because they are not guessable. Still leakable. Long-lived keys end up in public Git repositories, CI/CD logs, developer laptops - and, as at Cariad, in a memory dump.‍
• Native cloud IAM integration. The strongest option, and the one that changes the attacker's job rather than their odds. Human identities use an identity provider with MFA and conditional access, centrally managed and audited. Machine identities use short-lived mechanisms - role assumption in AWS, managed identities in Azure - instead of static credentials.

Cariad's workload sat on the third rung. The fix is the fourth.

Re-run the incident one rung higher

Keep every other fact identical. The application still exposes a memory dump. Researchers still find it. The storage still holds terabytes of telemetry. What changes is what the dump is worth.

With native IAM integration, there is no static key in memory to recover. What an attacker finds is either nothing reusable at all, or a short-lived token that expires before it is useful. To get anywhere from there, they would have to compromise a trusted identity flow, satisfy access conditions, and leave traces in centralized audit logs.

The application flaw does not disappear. The chain breaks anyway. And that generalizes well beyond this incident, because a leaked credential is how a large share of cloud compromises begin. If the credential is not reusable, the most common opening move in cloud attacks simply stops working.

Who generates the keys

One more thing about this case is worth naming, because it determines whether the fix above ever reaches the systems that need it. Cariad is Volkswagen Group's software division. The configuration was in Cariad's applications, in Cariad's cloud environment. The headline said Volkswagen.

That shape is common and rarely governed. Software subsidiaries. Digital innovation units. Joint ventures. Recently acquired brands still on their own tenancy. Regional entities with delegated autonomy. Each has its own engineering culture, its own delivery pressure and frequently its own cloud accounts, while the parent carries the regulatory exposure and the brand damage.

Central security policy typically reaches these units by influence rather than by control. A standard is published. A questionnaire is completed. An architecture review happens for large projects and not for the rest.

None of that stops an engineer in a subsidiary generating a set of long-lived access keys on a Tuesday because it was the quickest way to make something work. A policy that says "use managed identities" is a document. Something that prevents the key being created is a control.

Why detection was not the answer

The exposure lasted months and was found by an outside researcher acting on an anonymous tip, not by internal scanning.

Secret scanning would not have helped either, and it is worth being precise about why. Scanners look for credentials in repositories and code. This key was in a memory dump produced at runtime by a running application - not a place any repository scanner looks.

That is the general problem with detecting leaked credentials. You are trying to enumerate every place a secret could end up. The alternative is to make sure the secret is not worth finding.

How Aryon helps

The useful question after an incident like this is not "which control would have solved the whole attack." None of them do, and any vendor claiming otherwise is selling. The question is which links can be removed before deployment, so the chain cannot be assembled at all.

For this incident, that link is the credential. Aryon lets you deploy policies that are enforced at deployment, at the moment a resource is created or changed:

Leakable credentials can be prevented, not just monitored. A policy can prevent long-lived static access keys from being created in the first place, requiring role assumption or managed identities instead. That is the difference between finding leaked keys faster and having nothing worth leaking.

‍