150 Million Driver's Licenses Leaked for Over a Year, and the Company Was the Last to Know

Hi there, Basestone subscriber! 👋

This month we're covering a different kind of incident. In early September, it came out that U.S. identity verification firm IDScan.net had over 160 million ID document images, including 153 million driver's licenses, for sale on the dark web. But the most striking part of this story isn't the scale, it's that nobody caught it. Attackers sat inside the company's internal systems for over a year, quietly relaying data out in real time, and the first to notice wasn't IDScan itself, wasn't a customer, and wasn't an auditor. It was a cybersecurity journalist who was browsing a dark web forum and stumbled across his own driver's license scan. Today we're looking at why this went undetected for so long, and the data retention decisions sitting behind it 🔍

📌 Quick summary of today's issue

• Over 153 million driver's licenses and other ID images leaked out of IDScan.net in real time for over a year, and the company only learned about it after an outside security journalist flagged it
• What attackers accessed wasn't just personal data, it was full infrared and ultraviolet scans of original ID documents, and security researchers point to that as the root cause: the company kept everything, when all it needed to keep was a verification result
• That same month, Korea's National Intelligence Service overhauled its public-sector cloud security certification framework, resetting how sensitive data stored in the cloud gets classified and governed
• The incident shows that breach scale isn't primarily a detection-technology problem, it's a design-time decision about what you keep and for how long

🔍 Here's how the breach came to light

A new marketplace shows up on the dark web

On August 31, a new dark web platform called Nexus appeared on Exploit, a Russian-language hacking forum. It advertised 153 million U.S. and Canadian driver's licenses, over 10 million ID cards, plus travel documents and medical marijuana cards. Full access required a separate payment, suggesting the attackers were holding the data for ransom.

A journalist found it before the company did

Security journalist Brian Krebs was browsing the platform when he found a scan of his own driver's license. He cross-referenced it against a document he'd submitted during a trip in June 2025 and traced it back to IDScan.net, then reported it. On September 1, the FBI's New Orleans field office opened a formal investigation, and IDScan.net didn't publicly confirm the breach until September 8. The company said it had "become aware of unauthorized access around September 1 and took immediate steps to secure our systems," but by then it had already been beaten to the discovery.

A real-time leak that ran for more than a year

What makes this worse is that this wasn't a one-time break-in. Attackers had access to internal object stores, administrative credentials, and backend pipelines, and relayed data out in real time for over a year. Given that IDScan processes roughly 21 million verifications a month, the volume leaked works out to something like seven months' worth of verification records sitting there, intact, the whole time. This wasn't a single breach, it was a long, quiet, ongoing exfiltration.

🧭 Why this leaked so much, for so long

Breach size came down to what was kept, and for how long

IDScan's job only requires keeping one thing after checking a document: a pass/fail result. What it actually kept was the full infrared and ultraviolet scans of both sides of every ID. Security researchers point to this as the root cause. A verification only needs a boolean, "is this document real," but the raw images that decision was based on kept piling up. In a system built this way, daily volume multiplied by retention period is exactly what determines how big the breach gets when one happens. Cutting retention down to days instead of months would have fundamentally shrunk the blast radius on its own.

There was no mechanism to catch bulk exfiltration

The fact that data kept leaking out in real time for over a year without anyone noticing also means there wasn't adequate monitoring for abnormal, large-scale data leaving cloud storage. The security industry's standard recommendation here is to set egress thresholds on cloud storage so that when far more data than usual leaves in a short window, it triggers an automatic alert, and to extend that monitoring to accounts that don't log in the normal way, like service accounts, so this kind of quiet leak doesn't slip through.

Consumers never had a relationship with this company to begin with

Another thing worth sitting with here: most of the people affected had probably never heard of IDScan.net. They had their ID scanned renting a car or getting carded at a store, with no way of knowing whose cloud that data ended up sitting in. As more companies outsource identity verification, that pile of third-party vendor risk, risk consumers never actually consented to, keeps growing.

Coincidentally, the same month, Korea overhauled its own cloud security framework

Not long after this story broke, on September 17, Korea's National Intelligence Service announced a full overhaul of its public-sector cloud security certification framework at Cyber Summit Korea 2026. It consolidates what used to be dual certification, from both the Ministry of Science and ICT and the NIS separately, under NIS authority, and replaces the old high/medium/low classification tiers with a Confidential/Sensitive/Open (CSO) scheme. This reform wasn't a response to the IDScan incident, but it's worth noting that how sensitive data sitting in the cloud gets classified and governed became a live question on both sides of the Pacific at almost the same time.

✅ Check these about your own data retention first

• Do you have a retention TTL that deletes raw source documents (ID scans, passports, etc.) right after verification, keeping only the result
• Do you have threshold-based detection on cloud storage that fires an automatic alert when far more data than usual leaves in a short window
• Does your monitoring cover access patterns from service accounts and backend pipelines that don't log in the way a human user does
• When you outsource identity verification or document processing to a vendor, does your contract spell out deletion obligations, proof of deletion, and what happens to the data when the contract ends

⚠️ What teams often miss

The false comfort of "it's encrypted, so it's safe"

There's no reporting that this data was unencrypted, but even if it had been encrypted, that wouldn't have mattered much once the admin credentials themselves were compromised. Encryption protects data at rest, it doesn't stop access that's disguised as legitimate. Watching what you're storing and whether access to it looks normal is a much more fundamental line of defense.

Nobody asks "why do we still have the original, if all we needed was the result"

A lot of organizations over-retain raw data early on, for convenience, and never revisit that decision as the service grows. How long to keep data isn't a security team's call alone, it needs to be decided at the product design stage.

"There was no new attack technique in this incident. There was just a question nobody asked for over a year: why do we still have this data." — Basestone Security Research Team

🚀 How to start small

A good first step is simply counting: what raw data does your identity verification or KYC process keep, and for how long? Multiply your average daily volume by your retention period in days, and you'll get a rough sense of how big a breach could get if one happened. If that number is bigger than you expected, cutting retention down to days alone can shrink your potential exposure dramatically.

If you'd like to revisit last month's help desk vishing story as well, we'd recommend reading Dissecting the Vishing Playbook That Breached McKesson, RingCentral, and a String of Major Companies in August 2026.