← All articles

Yamato breach: 5.26 million buyer records stolen, with order details attached.

Yamato confirms stolen buyer, recipient and merchant records. What changed on 16 October, what did not leak, and how to verify payment requests.

Incident period: Access confirmed 28 Sep; reopened 9 Oct; theft confirmed 16 Oct 2026Sources checked: 17 Oct 2026Updated: 17 Oct 2026

30-second briefing

Key facts
Yamato confirms theft of about 5.26 million buyer records, 50,000 recipient records and 4,100 merchant records. Product details were included; billed amounts, outstanding balances and employee names were not confirmed taken.
Who should act
Email Security · Third-party Risk · Legal / Privacy · SIEM · IT Operations
First action
Verify payment requests through the shop or Yamato using contact details you obtain independently. Merchants should brief payment and customer-support staff.
Uncertainty to keep in mind
The entry method, attacker, intrusion duration and number of unique affected people remain undisclosed. Reports of suspicious messages do not establish misuse of this stolen data.
Yamato Holdings and Yamato Transport head office in Ginza, Tokyo: a white building with the yellow black-cat logo near the roof.
Photo: Lombroso, CC BY-SA 4.0, via Wikimedia Commons (cropped)
THE POSTURE QUESTION

A message can know the product, quantity and order reference and still be fraudulent. Verify the payment through a channel you start yourself.

Yamato has confirmed the theft. The scope is now clearer, and parts of the earlier warning have changed. Its 16 October report on the Kuroneko deferred-payment service lists about 5.26 million buyer records, 50,000 delivery-recipient records and 4,100 merchant records. Product names, quantities and unit prices are among the buyer fields. Yamato’s fourth report.

Updated 17 October 2026. This replaces our 3 October assessment of a possible leak. The illustrations and response guidance below reflect the fourth report.

Confirmed scope: approximately 5.26 million buyer records, including about 490,000 with email addresses; 50,000 delivery-recipient records; 4,100 merchant records. These are record groups, not unique people.

At a glance. Original graphic; Yamato’s fourth report is the source of the counts.

What changed on 16 October

Earlier position Latest disclosed position
Some information might have leaked; no count was available Unauthorized removal is confirmed, with three record groups identified
Billed amounts, outstanding balances and employee names were potentially involved Investigation did not confirm removal of those three items
The service was suspended It reopened at 13:00 JST on 9 October
Scope and secondary harm were under investigation Scope is specified; misuse of this data had not been confirmed at the fourth report

The correction matters. Our earlier article used billed amounts and balances to explain a possible fraudulent reminder. Those fields should no longer be described as confirmed stolen. Product details remain in the confirmed scope.

What was taken, and how to read the numbers

Group Approximate records Fields Dates covered by the records
Buyers 5,260,000 Name, address, phone, email, product details, application number, order date and credit reference number 1 October 2018–28 September 2026
Delivery recipients 50,000 Name, address, phone and shipment tracking number 5 February 2021–28 September 2026
Merchants 4,100 Merchant name and merchant code 1 October 2018–28 September 2026

Email addresses occur in about 490,000 of the buyer records; this is a subset, not an extra group. Credit-card and password information are excluded. The fourth report separately says removal of billed amounts, outstanding balances and employee names was not confirmed. Official scope table.

Records are not unique people. Adding the first two rounded counts gives roughly 5.31 million customer-related records, which explains that figure in reporting. The notice does not deduplicate people across groups. Merchant records are a separate category. ITmedia independently reports the same breakdown. ITmedia, 16 October.

The multi-year dates describe the information involved. They do not establish eight years of attacker access.

Three evidence categories: confirmed stolen buyer, recipient and merchant information; credit cards and passwords excluded; billed amounts, balances and employee names not confirmed taken. Intrusion method and unique affected people remain unknown.

Figure 1. Keep confirmed, excluded and unresolved findings separate. The table above provides the accessible field list.

The disclosure and recovery timeline

  • 28 September: unauthorized access was confirmed; Yamato restricted external access.
  • 29 September: the first public notice appeared.
  • 2 October: the second notice described possible data exposure.
  • 9 October, 13:00 JST: the deferred-payment service reopened while the data investigation continued.
  • 16 October: the fourth report confirmed unauthorized removal and revised the field list.

The reopening notice also extended payment-slip deadlines falling on or after 28 September by 17 days. Its example changes 1 October to 18 October. Follow the official notice for your payment, and use a contact route you obtain independently if anything is unclear. Reopening and deadline notice.

Timeline from unauthorized access confirmation on 28 September through notices on 29 September and 2 October, reopening on 9 October at 13:00 JST, and confirmed theft on 16 October. Reopening and completion of impact assessment are distinct milestones.

Figure 2. Service recovery and impact assessment followed different schedules. All operational times are JST.

Why order details still matter

Editorial assessment. A contact list lets a scammer address someone by name. An order record can help them impersonate a conversation the customer expects: a delivery problem, return, refund or payment query.

An invented example is: “We need to verify the two items in your recent order before processing the refund.” Knowledge of the item or a reference number may make the approach credible. It does not establish who sent it.

Do not assume a leaked unit price is the amount currently owed. Shipping, discounts, taxes, returns and payments can change the payable amount. The distinction is especially important because billed amounts and balances were not confirmed taken.

Delivery recipients deserve their own check. The disclosed group is not limited to the purchaser’s contact record. A recipient may need to ask the purchaser or shop about an order rather than assume that never selecting deferred payment removes them from scope.

Yamato reports inquiries about suspicious email, SMS and calls, while stating that secondary harm from misuse of this data had not been confirmed. Those reports do not establish a connection to the stolen records. Current notice.

Customers: verify the request before the payment

  1. Open the shop’s order history yourself, using an existing bookmark or the app you already use.
  2. Compare the order and payment status. A correct product name, reference or sender display name is insufficient.
  3. Check deadline changes against the official reopening notice. An urgent inbound message should not decide your deadline.
  4. Contact the shop or Yamato through a separately obtained channel. Avoid links, attachments, QR codes and callback numbers supplied by an unexpected request.
  5. If you entered credentials or card details on a suspicious page, change the affected credentials through the real service, revoke sessions where available and contact the card issuer or bank promptly. This responds to your interaction with a suspected scam; the breach notice does not report stolen card or password data.

Yamato publishes examples of impersonation messages and advises against opening suspicious links or attachments. Official impersonation warning.

Verification flow for an unexpected payment request: pause the inbound link, open an existing shop account independently, compare order and payment status, contact an independently verified channel if anything differs, then pay only through a verified route. Disclosure details alone do not authenticate the sender.

Figure 3. A suggested verification workflow, not Yamato’s interface or evidence of an observed fraud campaign.

Merchants and security teams: keep three workstreams open

Workstream Practical action Evidence to retain
Customer impact Ask the provider which buyer, recipient and merchant records concern you. Distinguish records from people and confirmed fields from earlier possibilities. Provider notices, field-level scope and your matching order references
Fraud and support Brief staff about refund, settlement-account and payment-verification pretexts. Confirm account changes through an established channel with a second approver. Original messages, relevant headers, call notes and approval history
Service and privacy Check checkout and payment reconciliation after reopening. Assess retention and notification duties against your role and confirmed scope. Reopening checks, customer guidance, retention decisions and counsel’s assessment

The operational lesson is that a payment provider holds context for both sides of a transaction. Review who can export order details, whether bulk reads are recorded and how old recipient information is removed or restricted. These are defensive review questions, not findings about Yamato’s implementation.

Our API data-exposure response playbook provides decisions for preserving evidence, scoping returned data and checking wider impact. Its evidence and scope sections are useful here; Yamato has not disclosed an API attack, so no API-specific cause should be assigned to this incident.

Hunting for follow-on impersonation

Yamato has not published attacker infrastructure or a usable incident IOC set in the reviewed notices. These examples look for possible follow-on messages, not the original intrusion. They are illustrative and have not been run against a live tenant.

The two KQL queries use Microsoft Defender XDR’s EmailEvents table and require Defender for Office 365 telemetry. Fields were checked against Microsoft’s schema. Adjust the UTC window to your retention. Japanese text uses contains to avoid relying on space-separated words.

Brand-name messages from other sender domains. This uses the visible From domain. A forged official From address can evade it; investigate authentication results and message headers separately. Legitimate partners, news and newsletters can match.

Download brand-impersonation KQL.

// Illustrative only; not executed against a tenant.
// Microsoft Defender XDR: requires Defender for Office 365 EmailEvents.
// UTC window; adjust to your retention and investigation period.
let Start = datetime(2026-09-28T00:00:00Z);
let End = datetime(2026-10-18T00:00:00Z);
let OfficialDomains = dynamic(["kuronekoyamato.co.jp", "yamato-hd.co.jp"]);
EmailEvents
| where Timestamp >= Start and Timestamp < End
| where EmailDirection == "Inbound"
| extend Text = strcat(Subject, " ", SenderDisplayName),
         SenderDomain = tolower(SenderFromDomain)
| where Text contains "ヤマト" or Text contains "クロネコ"
    or Text contains "yamato" or Text contains "kuroneko"
| where SenderDomain !in (OfficialDomains)
    and not(SenderDomain endswith ".kuronekoyamato.co.jp")
    and not(SenderDomain endswith ".yamato-hd.co.jp")
| project Timestamp, NetworkMessageId, SenderFromAddress, SenderFromDomain,
          SenderDisplayName, Subject, RecipientEmailAddress, DeliveryAction, ThreatTypes
| order by Timestamp desc

Merchant, settlement and refund pretexts. This inspects the subject and display name, not the message body.

Download merchant-pretext KQL.

// Illustrative only; not executed against a tenant.
// Microsoft Defender XDR: EmailEvents. Subject/display-name triage, not body inspection.
let Start = datetime(2026-09-28T00:00:00Z);
let End = datetime(2026-10-18T00:00:00Z);
EmailEvents
| where Timestamp >= Start and Timestamp < End
| where EmailDirection == "Inbound"
| extend Text = strcat(Subject, " ", SenderDisplayName)
| where (Text contains "ヤマト" or Text contains "クロネコ"
        or Text contains "yamato" or Text contains "kuroneko")
    and (Text contains "口座" or Text contains "振込先"
        or Text contains "加盟店" or Text contains "精算"
        or Text contains "bank account" or Text contains "settlement"
        or Text contains "merchant" or Text contains "refund")
| project Timestamp, NetworkMessageId, SenderFromAddress, SenderFromDomain,
          Subject, RecipientEmailAddress, DeliveryAction
| order by Timestamp desc

Brand-like hosts in proxy logs. Replace the index and both field placeholders. Supply a hostname field, not a full URL. Splunk’s time strings use the search user’s timezone; set it explicitly. The domain exclusions below are review aids, not a complete list of legitimate partners.

Download proxy-review SPL.

index=YOUR_PROXY_INDEX earliest="09/28/2026:00:00:00" latest="10/18/2026:00:00:00"
(kuroneko OR yamato)
| eval host_l=lower(YOUR_URL_HOST_FIELD)
| where match(host_l, "kuroneko|yamato")
    AND NOT match(host_l, "(^|\\.)(kuronekoyamato\\.co\\.jp|yamato-hd\\.co\\.jp)$")
| stats count min(_time) AS first_seen max(_time) AS last_seen BY host_l YOUR_CLIENT_FIELD
| convert ctime(first_seen) ctime(last_seen)
| sort - count
| head 200

A match requires investigation; no match establishes nothing about the original breach. These data sources do not cover SMS, calls or paper correspondence. Route customer reports to the same fraud-review process.

What remains unknown

The reviewed disclosures do not identify the entry route, exploited vulnerability, attacker, intrusion start or exfiltration duration. They do not give a deduplicated affected-person count or establish a connection to other recent Japanese breaches. Service resumption is a recovery milestone; it is not independent proof about every aspect of historical access.

Reporting note and sources

Reviewed 17 October 2026. The fourth report and reopening PDF were read directly. The current scope and counts were cross-checked with ITmedia and Logistics Today. The fourth report’s correction was used to revise our earlier text and replace the old graphics. Facts attributed to Yamato are company findings; fraud scenarios and proposed controls are SecOpsNomad’s analysis.

All articles →日本語で読む ↗