Japanese car-sharing service Times Car (operated by Times Mobility / the Park24 Group) has confirmed a cyberattack that compromised approximately 6.6 million user accounts. The disclosure, made public late last week, places this incident among the largest consumer-facing breaches reported in Japan this year — a scale comparable to the Line-Yahoo and NTT Docomo incidents that reshaped Japan's breach-notification landscape in recent years.
While the full technical disclosure is still developing, the confirmed facts are what matter operationally right now:
- ~6.6 million user accounts compromised — this is a mass PII exposure event, not a handful of records.
- The affected population is a consumer mobility user base — names, contact details, membership identifiers, and potentially driver's license verification data used for car-sharing eligibility are the classes of data typically held by these platforms.
- The breach was disclosed via official notice, indicating the company has at least partially completed containment triage and legal/notification obligations under Japan's APPI (Act on the Protection of Personal Information), which mandates notification to the Personal Information Protection Commission (PPC).
For defenders, this is not just a "their problem" story. Breaches of this scale feed three downstream attack waves within days to weeks:
- Credential stuffing against other services where the same users reused passwords.
- Targeted phishing/smishing impersonating Times Car breach notifications ("verify your account," "compensation claim" lures).
- Social engineering against enterprises — Japanese organizations whose employees are Times Car users should expect business-context phishing leveraging real user data.
If you run a SOC, now is the time to hunt, harden, and brief — not wait for the forensic report.
Technical Analysis
What we know (and what we don't)
No CVE has been publicly associated with this intrusion, and Times Car has not yet published the initial access vector. That is normal at this stage of disclosure. What we can do as practitioners is reason from the pattern: mass extraction of customer account records from a consumer web/mobile platform typically traces back to one of a small set of root causes:
| Likely Vector | Typical Observable |
|---|---|
| Compromised web application or API (auth bypass, IDOR, SQLi against customer DB) | Abnormal query volume from app service accounts; burst reads on customer tables |
| Exposed/misconfigured cloud storage or database | Public object storage listing events; DB reachable from untrusted networks |
| Stolen credentials (admin, CI/CD, third-party vendor) | Impossible-travel logins; new service account usage; session token replay |
| Third-party / supply-chain compromise | Vendor account activity outside normal windows; unexpected egress to vendor IPs |
Given the scale (6.6M records), bulk database access or bulk API enumeration is far more likely than per-record web scraping — which means the extraction would have generated detectable signals: large egress transfers, service-account query anomalies, or backup/snapshot access.
Exploitation status
- No PoC or CVE is public. This is an intrusion/breach event, not a disclosed software vulnerability.
- CISA KEV: Not applicable — no associated CVE.
- Active exploitation: The data is confirmed exfiltrated. The primary residual risk is secondary abuse of the leaked dataset.
The downstream threat model (what YOUR SOC should actually prepare for)
1. Credential stuffing. Consumer password reuse rates remain stubbornly high (industry surveys consistently put it above 60%). If Times Car stored passwords as hashes — and the hashing was weak (MD5/SHA1, unsalted) — cracking begins immediately. Assume attackers will test recovered credentials against Microsoft 365, VPN portals, SaaS apps, and consumer services.
2. Breach-themed phishing. Within days of every major Japanese breach disclosure, lure campaigns appear impersonating the breached company. Expect emails/SMS claiming: "Your Times Car account may have been compromised — log in to secure it," "Compensation registration," or "Confirm your personal data." These collect credentials and payment data.
3. Help-desk and identity-recovery abuse. Attackers armed with real PII (name, email, phone, membership number) can defeat weak identity-verification flows at other organizations — password resets, SIM swaps, and support-desk social engineering.
Detection & Response
The detections below target the two most probable behaviors defenders can act on today: (a) credential-stuffing activity against your own environment using leaked credentials, and (b) phishing infrastructure impersonating Times Car breach notifications. The third rule targets the bulk-exfiltration pattern that likely characterized the breach itself — use it to check whether you have a similar blind spot.
Sigma Rules
---
title: Password Spray or Credential Stuffing Against Web Authentication
id: 3b7a2c1d-8e4f-4a5b-9c6d-2e1f0a9b8c7d
status: experimental
description: Detects high-volume failed authentication from a single source targeting many distinct accounts, consistent with credential stuffing using breached credential lists such as those from mass PII breaches.
references:
- https://attack.mitre.org/techniques/T1110/004/
- https://www.bleepingcomputer.com/news/security/times-car-confirms-data-breach-affecting-66-million-user-accounts/
author: Security Arsenal
date: 2026/04/06
tags:
- attack.credential_access
- attack.t1110.004
logsource:
category: authentication
product: windows
detection:
selection:
EventID: 4625
condition: selection
falsepositives:
- Misconfigured service accounts
- Legacy clients retrying expired passwords
level: medium
---
title: Phishing URL Referencing Breach Impersonation Lures
id: 9f2e1d4c-5b6a-4c7d-8e9f-0a1b2c3d4e5f
status: experimental
description: Detects web requests to lookalike domains or URLs using Times Car breach-themed lure keywords, consistent with post-breach phishing campaigns impersonating breach notification or compensation portals.
references:
- https://attack.mitre.org/techniques/T1566/002/
- https://www.bleepingcomputer.com/news/security/times-car-confirms-data-breach-affecting-66-million-user-accounts/
author: Security Arsenal
date: 2026/04/06
tags:
- attack.initial_access
- attack.t1566.002
logsource:
category: proxy
detection:
selection_keywords:
c-uri|contains:
- 'timescar'
- 'times-car'
- 'times_car'
c-uri|contains:
- 'verify'
- 'secure'
- 'update'
- 'compensation'
- 'support'
filter_legitimate:
cs-host|contains:
- 'timescar.jp'
- 'share.timescar.jp'
- 'park24.co.jp'
condition: selection_keywords and not filter_legitimate
falsepositives:
- Security research or threat intel lookups
level: high
---
title: Anomalous Bulk Database Query Volume by Service Account
id: 1a4b6c8d-2e3f-4a5b-8c9d-0e1f2a3b4c5d
status: experimental
description: Detects database audit events indicating full-table reads or bulk SELECT operations on customer/account tables by application service accounts, a pattern consistent with mass PII extraction as seen in large consumer-platform breaches.
references:
- https://attack.mitre.org/techniques/T1213/
- https://attack.mitre.org/techniques/T1530/
- https://www.bleepingcomputer.com/news/security/times-car-confirms-data-breach-affecting-66-million-user-accounts/
author: Security Arsenal
date: 2026/04/06
tags:
- attack.collection
- attack.t1213
- attack.exfiltration
logsource:
category: database
product: sqlserver
detection:
selection:
statement|contains:
- 'SELECT * FROM'
- 'BULK INSERT'
- 'INTO OUTFILE'
statement|contains|all:
- 'customer'
- 'user'
- 'member'
- 'account'
condition: selection
falsepositives:
- Scheduled ETL or reporting jobs
- Legitimate backup/export operations
level: high
KQL — Microsoft Sentinel / Defender
This hunt surfaces authentication anomalies consistent with credential stuffing against your environment in the wake of a mass credential leak. Run it against Entra ID sign-in logs (or ADFS/SSO equivalents ingested into Sentinel), and pair it with a watchlist of Times Car-themed phishing domains as your intel feeds publish them.
// Credential stuffing / password spray detection following mass credential breach
// Looks for single sources failing auth against many distinct accounts, then succeeding
let window = 1h;
SigninLogs
| where TimeGenerated > ago(7d)
| summarize
FailedCount = countif(ResultType != 0),
SuccessCount = countif(ResultType == 0),
DistinctAccounts = dcount(UserPrincipalName),
Accounts = make_set(UserPrincipalName, 25)
by IPAddress, AppDisplayName, bin(TimeGenerated, window)
| where DistinctAccounts > 10 and FailedCount > 20
| extend StuffingRatio = round(todouble(FailedCount) / todouble(DistinctAccounts), 2)
| project TimeGenerated, IPAddress, AppDisplayName, DistinctAccounts, FailedCount, SuccessCount, StuffingRatio, Accounts
| sort by DistinctAccounts desc;
// Proxy / web hunt for Times Car impersonation lure traffic (CEF-ingested proxy logs)
CommonSecurityLog
| where TimeGenerated > ago(7d)
| where RequestURL has_any ("timescar", "times-car", "times_car")
and RequestURL has_any ("verify", "secure", "update", "compensation", "support", "notice")
and not(DestinationHostName has_any ("timescar.jp", "park24.co.jp"))
| project TimeGenerated, SourceIP, DestinationHostName, RequestURL, RequestMethod, DeviceAction
| sort by TimeGenerated desc;
// Endpoint hunt: users opening credential-harvest lure attachments or HTML files
DeviceFileEvents
| where TimeGenerated > ago(7d)
| where FileName has_any ("timescar", "times_car", "TimesCAR", "breach_notice", "account_verify")
| project TimeGenerated, DeviceName, InitiatingProcessAccountName, FileName, FolderPath, SHA256
| sort by TimeGenerated desc;
Velociraptor VQL
If you suspect a user in your environment interacted with a breach-themed lure, this artifact enumerates browser download artifacts and recently executed files matching the lure naming patterns — useful for scoping which endpoints to isolate and which users need credential resets.
-- Hunt endpoints for Times Car breach-lure artifacts: downloads and recent execution
SELECT FullPath, Size, Mtime,
hash(path=FullPath) AS Hash
FROM glob(globs=[
'C:/Users/*/Downloads/*timescar*',
'C:/Users/*/Downloads/*Times*Car*',
'C:/Users/*/Downloads/*verify*account*',
'C:/Users/*/Downloads/*breach*',
'C:/Users/*/Downloads/*compensation*'
])
WHERE Mtime > timestamp(epoch=1700000000)
ORDER BY Mtime DESC
-- Correlate with recent process execution from user-writable paths (lure payload execution)
SELECT Pid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE Exe =~ '(?i)Users\\\\.*\\\\(Downloads|AppData|Temp)\\\\'
OR CommandLine =~ '(?i)(timescar|breach|verify|compensation)'
ORDER BY CreateTime DESC
Hardening & Verification Script
For Windows/Entra environments, the highest-value preventive control against the credential-stuffing fallout is enforcing MFA coverage and blocking legacy authentication. This PowerShell audits your exposure — run it in read-only audit mode first, then remediate gaps it surfaces.
# Audit MFA coverage and legacy auth exposure — run with read-only Graph scopes first
# Requires: Microsoft.Graph PowerShell module, Connect-MgGraph -Scopes 'User.Read.All','Policy.Read.All','AuditLog.Read.All'
# 1) Find users WITHOUT any strong auth method registered (prime stuffing targets)
$users = Get-MgUser -All -Property 'Id,DisplayName,UserPrincipalName,AccountEnabled'
$report = foreach ($u in $users | Where-Object { $_.AccountEnabled }) {
$methods = Get-MgUserAuthenticationMethod -UserId $u.Id -ErrorAction SilentlyContinue
[PSCustomObject]@{
UserPrincipalName = $u.UserPrincipalName
MFARegistered = ($methods.AdditionalProperties.'@odata.type' -join ';') -match 'microsoftAuthenticator|phoneAuthentication|fido2|windowsHello'
MethodCount = $methods.Count
}
}
$report | Where-Object { -not $_.MFARegistered } | Export-Csv -Path '.\users_without_mfa.csv' -NoTypeInformation
Write-Host "Users without MFA: $(($report | Where-Object { -not $_.MFARegistered }).Count) — see users_without_mfa.csv"
# 2) Check for legacy authentication block via Conditional Access policy presence
$policies = Get-MgIdentityConditionalAccessPolicy
$legacyBlock = $policies | Where-Object { $_.Conditions.ClientAppTypes -contains 'other' -or $_.Conditions.ClientAppTypes -contains 'exchangeActiveSync' }
if (-not $legacyBlock) { Write-Warning 'No Conditional Access policy blocking legacy auth detected — create one immediately.' }
# 3) Pull last 24h of risky sign-ins for triage
$start = (Get-Date).AddDays(-1).ToString('yyyy-MM-ddTHH:mm:ssZ')
Get-MgIdentityProtectionRiskySignIn -Filter "createdDateTime ge $start" -All |
Select-Object UserPrincipalName, IpAddress, RiskLevel, RiskDetail, CreatedDateTime |
Export-Csv -Path '.\risky_signins_24h.csv' -NoTypeInformation
Write-Host 'Exported risky_signins_24h.csv for SOC triage.'
#!/bin/bash
# Linux/web-tier audit: detect bulk egress anomalies and exposed database listeners
# Run on web/app servers and DB hosts during breach self-assessment
# 1) Any database listeners reachable beyond localhost? (MySQL/Postgres/Mongo/Redis)
echo "=== Listening DB ports ==="
ss -tlnp | grep -E ':(3306|5432|27017|6379|1433)\b'
# 2) Top egress talkers in last 24h (requires netflow/nethogs history or use conntrack snapshot)
echo "=== Current high-volume outbound connections ==="
ss -tnp state established | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -rn | head -20
# 3) Web server access log: burst requests from single IPs (potential enumeration/scraping)
echo "=== Top requestors today (adjust log path) ==="
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20
# 4) Large response bodies — possible bulk data export via web layer
echo "=== Responses > 5MB today ==="
awk '$10 > 5000000 {print $1, $7, $10}' /var/log/nginx/access.log | head -50
# 5) Recent archive/compression of data directories (staging for exfil)
echo "=== Recently created archives ==="
find /var /tmp /home /opt -type f \( -name '*.tar.gz' -o -name '*.zip' -o -name '*.7z' -o -name '*.sql' -o -name '*.csv' \) -mtime -7 -size +10M 2>/dev/null
Remediation
If you are Times Car (or in a similar post-breach position)
- Complete forensic scoping before declaring containment. 6.6M records means the attacker touched core customer data stores. Confirm: initial access vector, dwell time, whether password hashes/payment tokens were accessed (vs. profile data only), and whether any driver's license verification documents (which car-sharing platforms in Japan collect for membership approval) were exposed — that data class materially raises identity-theft risk and notification obligations.
- Force password resets and invalidate all sessions/tokens — not just for affected users, but platform-wide if hash integrity cannot be proven. Audit the hashing scheme; if anything weaker than bcrypt/argon2 was in use, assume passwords are recoverable.
- Rotate all secrets reachable from the compromised tier: API keys, database credentials, service-account tokens, signing keys, third-party integrations.
- Fulfill APPI obligations: notify the PPC and affected individuals with concrete protective guidance (not boilerplate) — vague breach notices drive users straight into phishing lures.
- Stand up brand-abuse monitoring for lookalike domains and phishing kits impersonating the breach notification itself. Register/block obvious typosquats proactively.
For every other organization (the realistic audience of this post)
- Enforce MFA everywhere it isn't already — the audit script above finds your gaps in minutes. Credential-stuffing waves from this breach will hit VPNs, M365, and SaaS portals within days.
- Block legacy authentication (IMAP/POP/basic auth) — it bypasses MFA and is the first thing stuffers test.
- Brief your users now. A short internal advisory: "If you use Times Car, change any reused passwords; treat any email/SMS about the Times Car breach as hostile until verified via the official app/website."
- Tighten help-desk identity verification. With fresh, legitimate PII in circulation, knowledge-based verification (name + phone + email) is effectively broken for these users. Require a second channel (manager approval, hardware token, known-device confirmation) for resets.
- Run the bulk-exfiltration self-check on your own customer-facing platforms: database listeners, egress anomalies, service-account query patterns. The uncomfortable question every CISO should ask this week is: would we have detected the query that pulled 6.6 million rows?
- Monitor threat intel feeds for the leaked dataset's appearance on breach forums/marketplaces and update blocklists with confirmed Times Car-themed phishing infrastructure as it's published.
There is no patch for this one — there never is for breaches. The remediation is detection depth, identity hardening, and honest answers about your own visibility. Treat this as a live-fire tabletop: the same techniques that emptied Times Car's customer database are being run against consumer platforms every week, and the organizations that fare best are the ones that already hunted for bulk access before they needed to.
Related Resources
Security Arsenal Incident Response Services AlertMonitor Platform Book a SOC Assessment incident-response Intel Hub
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.