Back to Intelligence

Florida DAVID DMV Database Breached via Stolen Police Credentials — Detection and Hardening Guide for Defenders

SA
Security Arsenal Team
September 12, 2026
13 min read

The Florida Department of Highway Safety and Motor Vehicles (FLHSMV) has confirmed that its Driver and Vehicle Information Database (DAVID) was breached by attackers who gained access using credentials belonging to a police department employee. This is not a zero-day story, a ransomware detonation, or a supply-chain compromise — it is something more common and, frankly, more preventable: a legitimate account, used illegitimately, against a system holding PII on millions of Florida residents.

In 15 years of incident response, the breaches that sting the most during the postmortem are exactly this type. There is no exotic exploit chain to dissect. There is a valid username and password, an authorized application path, and a database that dutifully answered queries it should never have been asked at that volume, at that time, from that source. The perimeter did exactly what it was designed to do — and that was the problem.

This post breaks down the attack pattern, what defenders should be hunting for right now in their own environments, and the concrete controls that would have disrupted this intrusion at multiple points in the kill chain.

Technical Analysis: Anatomy of the DAVID Breach

What Was Compromised

DAVID is Florida's centralized driver and vehicle information system, queried daily by law enforcement and other authorized government users. It contains highly sensitive PII: full names, dates of birth, home addresses, driver's license numbers, photographs, vehicle registration data, and in some configurations, Social Security number fragments. Access is provisioned to law enforcement agencies, which then manage their own individual user accounts under memorandums of understanding with FLHSMV.

The Attack Chain (Defender's View)

Based on FLHSMV's confirmation, the intrusion followed a pattern we see constantly in IR engagements:

  1. Credential theft upstream. The attacker obtained valid credentials belonging to a police department employee. Common upstream vectors for this include infostealer malware (RedLine, Lumma, Vidar-class stealers harvesting browser credential stores), phishing against agency email, or credential reuse from a third-party breach. The DMV system itself was not the initial target — the identity was.

  2. Legitimate-path authentication. The attacker logged into DAVID through the normal application interface using the stolen account. No exploit, no malware on FLHSMV infrastructure, no anomalous protocol behavior. From the authentication system's perspective, this was a valid user.

  3. Mass querying / data harvesting. Once inside, the attacker ran lookups against driver records. The distinguishing characteristic of abuse in these systems is almost always behavioral: query volume far exceeding a patrol officer's normal workload, queries at unusual hours, lookups with no corresponding case or traffic-stop context, and bulk-pattern queries (sequential license numbers, broad name searches).

Why This Threat Class Is Active and Growing in 2025–2026

Stolen credentials remain the top initial access vector in confirmed breaches across every major industry dataset, and infostealer-as-a-service ecosystems have industrialized the theft and resale of government employee logins. Law enforcement and DMV-adjacent credentials are specifically valuable on criminal markets because they unlock query-based PII systems — DAVID, state CJIS-connected systems, NCIC terminals — that cannot be scraped from the open web. There is no CVE to patch here. The vulnerability is an unmonitored trust relationship between an identity provider (the police department) and a data custodian (FLHSMV).

Exploitation Status

Confirmed in-the-wild breach. FLHSMV has publicly acknowledged the incident. This is active criminal tradecraft against government PII databases, not a theoretical risk. Every state DMV, every agency with delegated query access to a shared PII system, and every police department issuing DAVID-equivalent credentials should treat this as a direct warning shot.

Detection & Response

The hard truth: by the time the attacker is querying DAVID, prevention has already failed. Detection therefore rests on two pillars — catching the credential misuse at authentication time and catching the behavioral anomaly at query time. Both are achievable with telemetry most agencies already collect but rarely alert on.

Sigma Rules

These rules target the host-side and identity-side behaviors that typically surround this attack class: infostealer credential harvesting on the endpoint (the upstream vector) and anomalous logon patterns against sensitive applications.

YAML
---
title: Potential Credential Theft via Browser Credential Store Access
id: 3f9c1a72-8b4d-4e21-a6c3-2d7e9f0b1a45
status: experimental
description: Detects suspicious access to browser credential databases (Login Data, logins.json) by non-browser processes, consistent with infostealer activity that commonly precedes credential-based breaches like the FLHSMV DAVID incident.
references:
  - https://www.bleepingcomputer.com/news/security/florida-confirms-dmv-database-breached-via-stolen-police-account/
  - https://attack.mitre.org/techniques/T1555/003/
author: Security Arsenal
date: 2026/01/15
tags:
  - attack.credential_access
  - attack.t1555.003
logsource:
  category: file_event
  product: windows
detection:
  selection_paths:
    TargetFilename|contains:
      - '\AppData\Local\Google\Chrome\User Data\Default\Login Data'
      - '\AppData\Local\Microsoft\Edge\User Data\Default\Login Data'
      - '\AppData\Roaming\Mozilla\Firefox\Profiles\'
      - '\AppData\Local\Google\Chrome\User Data\Local State'
  selection_exclusions:
    Image|endswith:
      - '\chrome.exe'
      - '\msedge.exe'
      - '\firefox.exe'
  condition: selection_paths and not selection_exclusions
falsepositives:
  - Legitimate backup or EDR software reading browser stores
  - Password managers with browser integration
level: high
---
title: LSASS Memory Access by Non-System Process
id: 8e2b5d14-6c3f-4a98-b7d2-9f1e4c6a0d83
status: experimental
description: Detects processes opening a handle to LSASS with access rights consistent with credential dumping. Credential theft from endpoints is the most common upstream source of stolen government accounts used against systems like DAVID.
references:
  - https://attack.mitre.org/techniques/T1003/001/
  - https://www.bleepingcomputer.com/news/security/florida-confirms-dmv-database-breached-via-stolen-police-account/
author: Security Arsenal
date: 2026/01/15
tags:
  - attack.credential_access
  - attack.t1003.001
logsource:
  category: process_access
  product: windows
detection:
  selection:
    TargetImage|endswith: '\lsass.exe'
    GrantedAccess|contains:
      - '0x1010'
      - '0x1410'
      - '0x1438'
      - '0x143a'
      - '0x1fffff'
  filter_legitimate:
    SourceImage|endswith:
      - '\svchost.exe'
      - '\MsMpEng.exe'
      - '\wininit.exe'
      - '\csrss.exe'
  condition: selection and not filter_legitimate
falsepositives:
  - EDR and AV products performing legitimate memory inspection (tune exclusions per environment)
  - Internal auditing tools
level: high

Note on the second rule: tune the SourceImage exclusions against your actual EDR stack before enabling at high level. In environments without Sysmon's process-access logging, the equivalent detection lives in Microsoft Defender for Endpoint's DeviceEvents table (see KQL below).

KQL — Microsoft Sentinel / Defender

The most valuable detection for a DAVID-style breach is behavioral anomaly detection on the application side: a user whose query volume or session pattern deviates sharply from their own baseline. The following queries cover identity-side anomalies (assuming sign-in logs are ingested) and application query-volume deviation (assuming DAVID/audit logs are ingested via a custom table or CommonSecurityLog).

KQL — Microsoft Sentinel / Defender
// Query 1: Impossible travel / anomalous sign-in location for accounts
// accessing sensitive PII systems (tune the app name filter to your environment)
let threshold = 3;
SigninLogs
| where TimeGenerated > ago(14d)
| where AppDisplayName has_any ("DAVID", "DMV", "CJIS", "NCIC")
    or AppId in (/* your sensitive app IDs */ "00000000-0000-0000-0000-000000000000")
| summarize Locations = make_set(Location), IPs = make_set(IPAddress),
            SigninCount = count() by UserPrincipalName, bin(TimeGenerated, 1d)
| where array_length(Locations) > threshold or SigninCount > 50
| project TimeGenerated, UserPrincipalName, SigninCount, Locations, IPs
| order by SigninCount desc;

// Query 2: Application query volume deviation from user baseline
// (adapt table/column names to your ingested DAVID audit logs)
let lookback = 30d;
let recent = 1d;
let baseline =
    DAVIDAudit_CL
    | where TimeGenerated > ago(lookback) and TimeGenerated < ago(recent)
    | summarize AvgDailyQueries = count() / toreal(toint(lookback / 1d)) by UserId_s;
DAVIDAudit_CL
| where TimeGenerated > ago(recent)
| summarize RecentQueries = count(),
            DistinctRecords = dcount(RecordQueried_s),
            FirstQuery = min(TimeGenerated), LastQuery = max(TimeGenerated) by UserId_s
| join kind=inner baseline on UserId_s
| where RecentQueries > (AvgDailyQueries * 5) and RecentQueries > 100
| extend DeviationFactor = round(RecentQueries / AvgDailyQueries, 1)
| project UserId_s, RecentQueries, AvgDailyQueries, DeviationFactor,
          DistinctRecords, FirstQuery, LastQuery
| order by DeviationFactor desc;

// Query 3: Endpoint-side infostealer behavior — browser credential store access
DeviceFileEvents
| where TimeGenerated > ago(7d)
| where FolderPath has_any ("Login Data", "Local State", "logins.json", "cookies.sqlite")
| where InitiatingProcessFileName !in~ ("chrome.exe", "msedge.exe", "firefox.exe", "brave.exe")
| project TimeGenerated, DeviceName, InitiatingProcessFileName,
          InitiatingProcessCommandLine, FolderPath, AccountName
| order by TimeGenerated desc;

Query 2 is the money query for this threat class. A patrol officer who averages 15 DAVID lookups a day does not run 900 in an afternoon. Tune the multipliers to your agency's real baselines — K9 and traffic units query more than detectives — but the shape of the detection (deviation from the user's own history, not a static threshold) is what keeps it out of the noise bin.

Velociraptor VQL

For DFIR teams scoping the upstream credential theft on a police department endpoint, this artifact hunts for evidence of infostealer access to browser credential stores alongside suspicious process execution from user-writable paths:

VQL — Velociraptor
-- Hunt: Browser credential store access + suspicious user-path execution
-- Scopes endpoints for infostealer activity preceding credential-based breaches
SELECT Pid,
       Name,
       Exe,
       CommandLine,
       Username,
       CreateTime
FROM pslist()
WHERE Exe =~ '(?i)\\\\(AppData|Temp|Downloads|Public)\\\\'
   OR CommandLine =~ '(?i)(Login Data|logins\\.json|Local State|cookies\\.sqlite)'

-- Complementary artifact: enumerate browser credential store files with
-- recent access by non-browser processes (run per-user via artifact)
SELECT FullPath,
       Size,
       Mtime,
       Atime
FROM glob(globs='C:/Users/*/AppData/Local/*/Chrome/User Data/*/Login Data')
WHERE Atime > Mtime
ORDER BY Atime DESC

Remediation & Hardening Script

The following PowerShell performs two functions relevant to this incident class on Windows domain endpoints: (1) audits for enabled LSASS protection (Credential Guard / RunAsPPL), which directly blunts the credential-dumping vector that feeds these breaches, and (2) identifies stale privileged accounts — a common source of the stolen credentials in delegated-access models like DAVID's.

PowerShell
# ============================================================
# Security Arsenal — Credential Theft Surface Audit
# Run elevated on endpoints / DCs. Read-only: reports, does not change.
# ============================================================

# --- Check 1: LSASS RunAsPPL (credential dump mitigation) ---
$ppl = Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa' `
       -Name 'RunAsPPL' -ErrorAction SilentlyContinue
if ($null -eq $ppl) {
    Write-Output "[FAIL] LSASS RunAsPPL not configured. Credentials dumpable from memory."
    Write-Output "       Remediate: Set HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\RunAsPPL = 1 (DWORD)"
} else {
    Write-Output "[PASS] LSASS protection enabled (RunAsPPL=$($ppl.RunAsPPL))"
}

# --- Check 2: WDigest plaintext credential caching ---
$wdigest = Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest' `
           -Name 'UseLogonCredential' -ErrorAction SilentlyContinue
if ($null -ne $wdigest -and $wdigest.UseLogonCredential -eq 1) {
    Write-Output "[FAIL] WDigest plaintext credential caching ENABLED. Set UseLogonCredential = 0."
} else {
    Write-Output "[PASS] WDigest plaintext caching disabled or not configured."
}

# --- Check 3: Credential Guard status (Windows 10/11 Enterprise) ---
$cg = Get-CimInstance -ClassName Win32_DeviceGuard `
      -Namespace 'root\Microsoft\Windows\DeviceGuard' -ErrorAction SilentlyContinue
if ($cg -and $cg.SecurityServicesRunning -contains 1) {
    Write-Output "[PASS] Credential Guard is running."
} else {
    Write-Output "[WARN] Credential Guard not running. Enable via GPO/Intune where hardware supports it."
}

# --- Check 4: Stale enabled accounts (delegated-access risk) ---
# Flags enabled accounts with no logon in 90+ days — prime theft targets
if (Get-Module -ListAvailable -Name ActiveDirectory) {
    Import-Module ActiveDirectory
    $cutoff = (Get-Date).AddDays(-90)
    Get-ADUser -Filter { Enabled -eq $true -and LastLogonDate -lt $cutoff } `
        -Properties LastLogonDate, MemberOf |
        Select-Object SamAccountName, LastLogonDate,
            @{N='Groups';E={($_.MemberOf | ForEach-Object {($_ -split ',')[0] -replace 'CN=',''}) -join '; '}} |
        Format-Table -AutoSize
    Write-Output "[ACTION] Review stale accounts above. Disable or recertify per agency policy."
} else {
    Write-Output "[SKIP] ActiveDirectory module not present — run on a DC or RSAT host for stale-account audit."
}

# --- Check 5: Local admin membership review ---
Get-LocalGroupMember -Group 'Administrators' -ErrorAction SilentlyContinue |
    Select-Object Name, ObjectClass, PrincipalSource | Format-Table -AutoSize
Write-Output "[ACTION] Validate every local admin entry above. Remove shared/standing admin where feasible."

Remediation: What FLHSMV-Style Incidents Demand

There is no patch for stolen credentials. Remediation here is architectural and procedural. Based on how this breach unfolded, the following controls map directly to failure points in the kill chain:

Immediate (0–72 hours) — For Agencies in a Similar Position

  1. Force password resets and session revocation for all accounts with access to the shared PII system. Assume any credential stored in a browser or emailed in plaintext is compromised. Invalidate active sessions/tokens, not just passwords.
  2. Enforce phishing-resistant MFA (FIDO2/security keys or, at minimum, TOTP — never SMS) on every account with DAVID-equivalent access. If the portal sits behind a network allowlist instead of MFA, that allowlist is your entire authentication layer — treat that as an emergency gap.
  3. Pull 90 days of query audit logs for the compromised account and every account from the same source agency. Establish the blast radius: which records were viewed, in what volume, over what window.
  4. Preserve evidence for the upstream credential-theft investigation on the police department side: endpoint triage images of the employee's workstation, browser artifacts, email gateway logs. The stolen credential had an origin story — you need it to prevent recurrence.

Short Term (2–6 weeks)

  1. Implement query-rate alerting at the application layer. Per-user daily/weekly query thresholds with deviation-from-baseline analytics (see KQL Query 2). This is the single highest-value detective control for delegated PII databases. FLHSMV's own audit capability ultimately surfaced this breach — the lesson is to automate and alert on it, not review it after the fact.
  2. Deploy contextual access controls: impossible-travel detection, device compliance checks, and time-of-day restrictions for sensitive application sign-ins via Entra ID Conditional Access (or your IdP equivalent). A DAVID login from a residential ISP in another country at 3 a.m. should never complete.
  3. Harden endpoints that hold the credentials: LSASS protection (RunAsPPL), Credential Guard, WDigest disabled, EDR with credential-theft detections enabled (script above audits these). The police department endpoint is part of the DMV's attack surface under a delegated trust model.

Strategic (Quarter)

  1. Re-architect around just-in-time, case-linked access. Mature deployments of CJIS-adjacent systems require a case number or incident reference per query, with supervisory review of lookups. This converts bulk harvesting from a silent operation into a policy violation on the first anomalous query.
  2. Renegotiate the shared-responsibility terms in MOUs between data custodians (DMVs) and consuming agencies (police departments): mandatory breach-notification timelines for credential compromise, minimum endpoint security baselines, periodic account recertification, and the custodian's right to suspend agency access on audit findings.
  3. Tabletop the delegated-credential scenario. Your IR plan almost certainly covers ransomware and external intrusion. Does it cover "a trusted partner's employee's password was stolen and used to query our PII database for six weeks"? Run that exercise.

Breach Notification and Compliance Notes

For the affected organization, driver's license data triggers state breach-notification statutes and, depending on data elements involved, may intersect with DPPA (Driver's Privacy Protection Act) obligations and CJIS Security Policy requirements for the law enforcement side. Engage counsel early, document the query audit trail meticulously, and expect regulator questions to center on why behavioral monitoring did not catch the anomaly sooner — that is now the standard of care for query-based PII systems.

Bottom Line

The FLHSMV/DAVID breach is a case study in 2026's dominant breach pattern: identities are the perimeter, and delegated trust relationships are the softest part of that perimeter. No malware touched Florida's systems. No vulnerability was exploited. A valid account did exactly what valid accounts are allowed to do — just far more of it, for the wrong reasons.

If your organization operates or consumes a shared PII database, your detection posture must answer one question at any moment: is each credentialed user behaving like themselves? If you cannot answer that with telemetry and alerting today, this breach is your warning to build it — before your audit logs become someone else's exfiltration receipt.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub

Is your security operations ready?

Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.