One Police Login, 200,000 Driver Records: What Florida's DAVID Breach Says About Shared Government Portals

On September 3, somebody logged into Florida's Driver and Vehicle Information Database and started counting. Not searching. Counting. Record ID after record ID, pulling the HTML page and the photo for each driver, the way you'd scrape a product catalogue.

The next day, September 4, the Florida Department of Highway Safety and Motor Vehicles (FLHSMV) says it learned of the breach. By September 7, ShinyHunters had listed the "State of Florida DMV" on its leak site and was claiming more than 200,000 driver records. As proof, the group posted a screenshot of one record in particular: Jeffrey Epstein's, complete with address, Social Security number, date of birth, license number and registered vehicles, according to BleepingComputer.

On September 11, the day of the group's extortion deadline, FLHSMV confirmed it. The way in, the agency said, was a login belonging to a single Plant City Police Department user, credentials that had been "improperly stored on the employee's personal electronic device."

I've spent a lot of time on post-mortems where the initial access story changes three times before the final report. This one already has two competing versions, and neither of them is reassuring. So let's work through what's known, what's claimed, and what a portal like DAVID should have noticed long before a ransom note arrived.

What DAVID is, and why it's worth stealing

DAVID is not the DMV counter. It's the back-office lookup system Florida police and authorised government agencies use to pull driver and vehicle records on demand. A deputy at a traffic stop, a detective building a case, a records clerk at a partner agency: they all query the same system.

According to reporting from Fox News and gblock, a DAVID record can include a person's address, Social Security number, date of birth, license number, issuance and expiry dates, registered vehicles, insurance information, parking permits, and in many cases the license photo and signature. Danny Jenkins, CEO of ThreatLocker, told CSO Online that what's exposed is effectively "a person's photograph, signature, address, date of birth and other information contained in a legitimate government credential."

Read that list again with an attacker's eyes. That's a kit for impersonating someone to a bank, a mobile carrier or a help desk. We covered the downstream problem two days ago in our write-up of the IDScan Nexus breach and why photo ID no longer proves identity. DAVID is the upstream version: not a scan of the card, but the state's own source of truth behind it.

Two stories about the same front door

Here's where it gets awkward.

ShinyHunters' version, as told to BleepingComputer: they got in through "a password-reset flaw that let them compromise multiple accounts in the system," including accounts belonging to DMV employees and an FBI agent. They then "iterated through the records by IDs and downloaded the associated HTML and images." They also said they had since lost access and that the flaw was being patched.

FLHSMV's version, confirmed by CBS12 and Fox News: one compromised Plant City Police Department account, credentials stored on a personal device, the intrusion "quickly mitigated," and "no further breach has occurred or is ongoing." The Florida Attorney General's Office, Florida Digital Service and the Florida Department of Law Enforcement are investigating. The state hasn't confirmed a record count, said which fields were exposed, or said whether drivers will be notified.

Extortion crews lie. They inflate numbers and they invent exotic entry points because "we found a zero-day in your reset flow" sounds scarier than "we bought a password." So I'd weight the state's account more heavily on how the attacker got in.

But notice what the state's account actually admits. It doesn't say the attacker had to beat anything. A valid username and password, sitting on a phone or home computer, was enough to reach a statewide identity database and keep pulling records until somebody noticed. If ShinyHunters is lying about the reset flaw, the truth is arguably worse: no flaw was needed.

"Improperly stored" is doing a lot of work

The phrase "improperly stored on a personal electronic device" puts the blame on one employee. I understand why an agency writes it that way. I also think it's the least useful sentence in the disclosure.

Think about how credentials end up on a personal device. A browser offers to save the password and the user clicks yes. A notes app holds the login because the portal times out every shift. A family laptop picks up an infostealer from a cracked game, and the stealer sweeps every saved password, including the one for the state database the user logs into from home on a weekend. FLHSMV hasn't said which of these happened, and the reporting doesn't specify a method. But every one of them is ordinary. None of them requires a careless officer, just a normal one.

Once that password is in a stealer log, it's a commodity. It gets sorted by domain, and government and law enforcement portals are exactly the kind of entries crews like ShinyHunters go looking for. This is the same group, operating in the same style, as the one behind the McKesson breach that started with a vishing call to an Okta admin. Their playbook doesn't depend on exploits. It depends on getting a legitimate session and then moving faster than anyone watching.

So the question isn't "why did this one officer save a password?" Across a user base made up of hundreds of agencies, someone always will. The question is what happens in the minutes after a stolen login shows up.

200,000 queries has a shape

This is the part I keep coming back to.

A patrol officer might run a few dozen DAVID lookups in a busy shift. A records unit doing background work might run more. But a human being at a terminal does not pull 200,000 records in a few days, and does not pull them in ascending ID order, and does not fetch every photo in the result set as fast as the server will serve them.

If ShinyHunters' description is even roughly accurate, the access pattern looked like this:

• One account (or a handful) suddenly querying far beyond its historical baseline.
• Sequential record IDs, with no search terms. A cop searches for a plate or a name. A scraper walks a number line.
• No relationship to a case. Real lookups cluster around an incident, a stop, a jurisdiction. Enumeration touches drivers in every county in the state.
• Machine timing. Regular intervals, no lunch break, no shift change.
• A new device or network. If the session came from wherever ShinyHunters runs its tooling rather than a Plant City patrol laptop, that's a mismatch too.

None of those signals needs AI or a fancy behavioural engine. A rate limit per account and an alert on sequential ID access would have caught the shape on day one. Instead the disclosure tells us the agency learned of the breach on September 4, the day after downloads began, and the group still claims six-figure volume. Whether that gap was hours or a full day, it was enough.

And there's a reason it's hard. Law enforcement databases are designed to answer quickly and not ask questions. You don't want a deputy at a roadside stop getting a CAPTCHA. Every friction control fights the mission. That tension is real, and it's why I don't think rate limits alone are the answer.

The record nobody should ever open

Here's the control I'd want in front of a system like DAVID, and it's one that doesn't slow down a single legitimate lookup.

Seed the database with drivers who don't exist.

Honey records are an old idea in database security. You insert a small number of synthetic entries: plausible names, plausible addresses, license numbers in the valid format, IDs scattered through the range. No real case will ever lead an officer to them, because they're not tied to any real plate, any real person, any real incident. A legitimate user has no reason to type that name. So the only way someone opens one of those records is by browsing or enumerating.

Now replay the DAVID breach with a few hundred honey records spread across the ID space. The scraper starts at some number and walks upward. Within the first few thousand records, it hits a synthetic driver. That fetch is a high-confidence alert, and it reads very differently from "anomalous volume, please review." It says: this account just opened a record that only an enumerator would open. There's no baseline to tune and no threshold to argue about. Zero false positives comes straight from the arithmetic here: legitimate users have no path to the decoy.

A few practical details from doing this kind of work:

1. Scatter them, don't cluster them. If the decoys sit together at the end of the table, a scraper that starts at the beginning won't hit one for hours. Spread them so any contiguous run of a few thousand IDs contains at least one.
2. Make them boring. A decoy named "Test User" or one with an obviously fake SSN prefix gets filtered by any attacker who looks. Use the same distributions as real data.
3. Tag the photo, not just the row. ShinyHunters said they downloaded the images. A decoy record whose license photo is served from a unique URL gives you a second tripwire, and tells you the attacker is pulling media, not just text.
4. Wire the alert to the account, not the analyst. The response to a honey record hit should be automatic session termination for that user, followed by a human looking at it. In a scrape that pulls hundreds of records a minute, waiting for a ticket costs you tens of thousands of drivers.
5. Plant a decoy login too. If stolen credential lists are how these crews get in, put a fake DAVID-style account into the places credentials leak from. Any login attempt with it tells you someone is working from a dump, often before they find a real account that works.

That last point matters for the "personal device" problem. You can't police every home laptop of every officer at every agency with DAVID access. You can make sure that when a credential dump is being tested against your portal, a tripwire fires. Our honeytoken and decoy solutions are built around that idea: fake identities and credentials that nobody legitimate will ever touch, so any touch is a signal.

What about MFA?

Fair question. The reporting I've seen doesn't say whether DAVID required multi-factor authentication for this account, and FLHSMV hasn't addressed it. If it didn't, that's the first fix, and it's overdue for any system holding SSNs.

But I'd caution against treating MFA as the whole answer. Infostealers increasingly grab session cookies along with passwords, and a stolen cookie skips the second factor entirely. We wrote about this pattern in the BigBear 2.0 phishing kit that steals Microsoft 365 sessions. MFA closes the "saved password" door. It doesn't tell you what a valid session is doing once it's inside. Honey records do.

This isn't new, and that's the problem

Misuse of police databases has been documented for years. A 2016 Associated Press investigation found that, across the U.S., police officers and employees were fired, suspended or resigned more than 325 times between 2013 and 2015 for misusing confidential law enforcement databases, with more than 250 further cases of lesser discipline. Those were insiders looking up exes, neighbours and celebrities.

That history should have taught agencies something. If insiders with legitimate access will browse records they have no case for, then "access equals authorisation" was never a sound model. The Epstein screenshot ShinyHunters posted is the outsider version of the same behaviour: a celebrity lookup with no investigative purpose. A honey record named to look like a public figure, sitting in a database that police officers can query, would catch both kinds of misuse.

Questions I'd ask if I ran a shared portal

If you run anything that looks like DAVID, whether a state records system, a healthcare exchange, a benefits portal or a partner extranet with thousands of users across dozens of organisations, these are the questions this breach should push onto your agenda:

• Can you see per-account query volume in real time, and do you know what normal looks like for each user type?
• Would you notice sequential ID access? It's a trivial query against your audit log. Run it against last month's data and see what turns up.
• Do you know where your users log in from? A partner-agency account suddenly appearing from a hosting provider deserves a hard stop.
• Does your search interface even allow lookups by internal ID? If legitimate users search by name or plate, an ID-walking endpoint is attack surface with no business purpose.
• Is there anything in your data that only an attacker would touch? If the answer is no, every alert you have depends on thresholds an attacker can stay under.

That last question is the one most shared portals can't answer yes to today.

Where this leaves Floridians

As of this writing, FLHSMV has not published an official count of exposed records, has not listed the fields involved, and has not said whether affected drivers will be notified. ShinyHunters, for its part, told BleepingComputer it plans to announce breaches of other state DMV platforms "over the coming weeks."

If that threat is real, the next state already has a stolen login in a stealer log somewhere. The password will work. The session will look legitimate. The only open question is whether anything inside the database is set up to notice a visitor who reads every record in order. If you'd like to see how a honey record trips in practice, and how quickly a scraping session gets cut off when it does, book a Mine2 demo and we'll walk through it against a live decoy dataset.