Texas Compliance Vendor Exposes 40K+ Sensitive DOT Records in S3 Leak

Researchers disclosed a large-scale exposure of personally identifiable information (PII) after an anonymous tip revealed an unsecured Amazon S3 bucket tied to a Texas compliance vendor. The leaky storage contained more than 18,000 photos of Social Security cards, over 23,000 driver’s-license images, plus drug-test results, liability insurance and vehicle-insurance cards, background-check consent forms, employment contracts, inspection reports and other DOT-related documents. Researchers traced the data to AJT Compliance, LLC and its DOT SHIELD platform; after responsible disclosure the vendor secured the bucket.

Disclosure timeline reported by researchers:

• Leak discovered: July 31, 2025
• Initial public disclosure: August 1, 2025
• Leak closed: September 3, 2025

“The leak is especially alarming because a platform designed to ensure compliance with government regulations ended up exposing highly sensitive personal information tied to US Department of Transportation requirements,” the research team warned.

The exposed records span 2022 to the present and were actively receiving new uploads while investigators were validating the finding. Because Texas employs a very large logistics workforce—more than 212,000 heavy truck drivers in 2023—the dataset may affect up to 10% of the state’s drivers and a large set of contractor and fleet personnel.

For vendor context, AJT Compliance publishes details about the DOT SHIELD product on its site; the platform is marketed as an end-to-end compliance and driver-file management system.

Technical Breakdown, Root Cause, and Risk Implications

Root Cause: Public S3 Access

Investigators say the breach resulted from an S3 bucket configured with public read and list permissions—one of the most common cloud misconfigurations. When a bucket allows LIST and GET to anonymous principals, any object stored there is discoverable and downloadable by anyone with the bucket name or an index page. This class of incident is fully preventable with standard AWS controls such as S3 Block Public Access and least-privilege bucket policies; AWS documents the recommended configuration in its [S3 Block Public Access] guidance.

Evidence of Active Uploads and Scale

Reports indicate the bucket contained tens of thousands of high-resolution images and PDF documents, and new files were uploaded during the investigative window—implying either a production/test sync was misconfigured or a lifecycle job was pointed at a public bucket. The exposure included sensitive identity documents that enable high-impact fraud: SSNs, driver-license numbers, and drug-test records.

How Attackers Could Exploit the Data (Attack Vectors and Motive)

With SSNs, licenses and employment paperwork, adversaries can:

• Build synthetic or full identity profiles to open credit, apply for loans, or file fraudulent tax returns.
• Bypass KBA (knowledge-based authentication) and call customer-service lines to social-engineer access to accounts.
• Commit targeted doxxing or extortion of drivers and their families.
• Craft highly convincing spear-phishing and account-takeover campaigns directed at fleets, carriers and recruiting platforms that use drivers’ personal data.

Comparative Incidents

This leak follows a pattern of third-party providers exposing citizen data via misconfigured cloud storage. Recent, relevant incidents include the Texas Department of Transportation crash-report exposure and earlier background-check vendor leaks; these show a systemic risk when vendors hold regulated records but lack cloud governance.

Detection Indicators and Forensic Artifacts to Hunt

SOC teams and cloud security engineers should hunt for:

• S3 bucket policies or ACLs granting Principal: * with s3:GetObject / s3:ListBucket.
• CloudTrail GetObject and ListObjectsV2 calls from anonymous or unusual IP prefixes.
• Newly created IAM keys with broad S3 permissions or recent changes to BlockPublicAccess settings.
• Object naming patterns that match driver or DOT filenames (e.g., SSN_, license_, drugtest_).

Example AWS CLI checks defenders can run (requires appropriate IAM permissions):

# List bucket ACL and policy
aws s3api get-bucket-acl --bucket <bucket-name>
aws s3api get-bucket-policy --bucket <bucket-name> | jq .

# Check public access block settings
aws s3api get-public-access-block --bucket <bucket-name> || echo "No public access block found"

# Find recent anonymous GETs via CloudTrail (pseudo-command)
aws cloudtrail lookup-events --lookup-attributes AttributeKey=EventName,AttributeValue=GetObject \
  --start-time 2025-07-01 --end-time 2025-09-05

A simple CloudTrail Athena query to find GetObject events from unusual sources can help enumerate potential data harvesting.

Remediation Advice, Responsibilities, and Next Steps

Immediate Actions for AJT Compliance and Similar Vendors

1. Secure S3 buckets: enable S3 Block Public Access at the account level and remove any Principal: "*" permissions from bucket policies and ACLs. Follow AWS best practices for S3 object ownership and disable ACLs where possible. Refer to [AWS S3 Security Best Practices] for implementation steps.
2. Rotate credentials and audit service accounts: invalidate keys used by CI/CD or sync jobs that were writing to the bucket and inspect build pipelines for mispointed artifacts.
3. Conduct forensic triage: preserve bucket inventory, CloudTrail logs, and any storage access logs for legal/notification purposes; capture timestamps and object checksums for victim notification.
4. Notify affected parties and regulators: under U.S. state breach-notification laws, impacted individuals and state attorneys general may need to be informed depending on jurisdiction and sensitivity. Prompt transparency reduces downstream reputational and regulatory risk.
5. Implement least-privilege ingestion: re-architect uploads so that driver documents are stored behind authenticated APIs that apply server-side encryption and token-based, short-lived presigned URLs for legitimate downloads.

Sample minimal bucket policy to prevent public GETs (illustrative):

{
  "Version":"2012-10-17",
  "Statement":[
    {
      "Sid":"DenyPublicRead",
      "Effect":"Deny",
      "Principal":"*",
      "Action":["s3:GetObject","s3:ListBucket"],
      "Resource":["arn:aws:s3:::example-bucket","arn:aws:s3:::example-bucket/*"],
      "Condition":{
        "Bool":{"aws:SecureTransport":"false"}
      }
    }
  ]
}

For Fleet Operators and HR Teams Using Third-Party Compliance Portals

• Inventory what you share: reduce uploaded fields to minimum required by DOT; avoid storing SSNs or store them tokenized/encrypted with strict access controls.
• Revoke and reissue credentials: where identity documents were compromised, require new hire verification and update onboarding flows.
• Contractual remediation: demand vendor attestations, proof of remediation, and periodic third-party security assessments (penetration test + cloud configuration audit).

For Affected Truckers and Individuals

1. Place fraud alerts or freezes: contact the three major credit bureaus (Equifax, Experian, TransUnion) to place a credit freeze or an initial fraud alert.
2. Monitor Social Security Activity: if SSNs were exposed, contact the Social Security Administration and monitor for unrecognized benefits claims; consider IRS Identity Protection PIN if eligible.
3. Change job-portal and payroll passwords; enable MFA: rotate passwords used for employer portals and any accounts that used the same credentials.
4. File reports and preserve evidence: report identity theft or attempted fraud to local law enforcement, the FTC (IdentityTheft.gov), and, where applicable, your state attorney general. Save copies of suspicious communications.
5. Consider identity-protection services or short-term credit monitoring, especially if financial applications or tax-related activity is suspected.

Researchers emphasize the severity of exposing documents that were intended to ensure regulatory compliance: “With these details in the wrong hands, malicious actors could open credit accounts, collect Social Security benefits belonging to the affected individuals, or engage in doxxing.” This frames the issue as both a compliance failure and a public-safety risk.

This leak echoes other third-party failures such as the TxDOT crash-report data compromise and past background-check vendor exposures—cases where vendors holding regulated or high-value records lacked cloud governance. These incidents underline that supply-chain and vendor security must be treated with the same rigor as in-house systems.