Murauchi.com: an outage exposed the breach, and 7.7 million customer records had already left.

What Murauchi.com has stated

Murauchi.com is an online retailer of electronics and appliances. It published two notices about the incident, on 24 July and 15 September 2026, and an FAQ. Its website could not be reached from our network for this article, so the facts below come from reports that quote the notices directly: ScanNetSecurity, ITmedia, INTERNET Watch, Security Measures Lab, which also cites the FAQ, and USEN's Cyber Security Lab for the first notice. Where they agree, we report it as stated. The company's own pages are linked under "Sources".

The first notice, 24 July, said:

How it was found. An internal system failed in the early hours of 15 July. On 16 July, while restoring it, staff found traces of unauthorised access by a third party.
First response. The company cut external access to the systems involved and preserved them, then began an investigation with outside specialists. It filed a preliminary report with the Personal Information Protection Commission on 20 July and consulted the police on 23 July.
What may have leaked. Traces of leakage were found for customers' names, email addresses, postal addresses and phone numbers, and for some customers, date of birth and gender. No count was given.
What was not affected. Login IDs, passwords and card details are held in a separate system and were not involved.

The second notice, 15 September, after the forensic investigation:

The way in. The access began with the exploitation of a vulnerability in part of a web system the company manages. The attacker then reached several other systems. The notice does not name the software or the vulnerability.
Confirmed exfiltration. Customers' personal data was taken out of the company: 7,716,811 records with name, postal address, phone number, email address, date of birth and gender. The FAQ says email address, date of birth and gender apply to only some of the customers.
Notification. Emails to the customers concerned began on 15 September. As of that date, the company had found no misuse, financial loss or phishing linked to the incident.
Prevention. A review of access rights and of how credentials are managed, stronger monitoring and detection on servers and networks, and regular vulnerability assessments.

The FAQ adds that the company has filed both its preliminary and final reports with the Commission, that its online store, Murauchi.com Honten, kept trading after its systems were checked, and that its social media accounts are paused until about November 2026 so that all contact goes through one channel.

Figure 1. From an overnight failure to a confirmed leak in two months. Original graphic.

What changes in the security review

The outage was the alarm

Editorial assessment. The intrusion came to light because something broke, not because something was detected. The company's own list of measures includes stronger monitoring and detection, which says the same thing.

Two lessons follow for any team that runs web systems:

Treat an unexplained failure as a possible incident until someone has ruled that out. Restoring a server can rotate logs, overwrite disks and remove the evidence that would show how the attacker got in and what they took.
Preserve first, then restore. Murauchi.com cut external access and preserved its systems before the investigation. That is the step to copy. Write down in advance who can declare "possible incident" at 3 a.m., and what gets copied (disk snapshots, logs, memory where possible) before anyone rebuilds.

From one web system to many

The second notice describes an entry through one web system, followed by access to several others and then the customer data.

Editorial assessment. That path is the real finding. A vulnerability in an internet-facing system is always possible; what decides the size of the breach is what that system can reach. Check four things:

Network paths. Web servers should reach the customer database only through the narrow route the application needs, and should not be able to open administrative ports (SSH, RDP, SMB, database consoles) on other internal systems.
Credentials on web servers. Keep administrator passwords, keys and broad service-account credentials off them. The company's measures name access rights and credential management, which suggests credentials or access rights played a part in how the attacker moved between systems. The notices, as reported, do not say so directly.
Patch and inventory. Know which web systems you run, including old ones, and patch them on a deadline.
Alert on movement. A web server starting new connections to internal admin ports, or spawning a shell, is worth an alert on its own. The hunts below look for both.

What the separation saved

Card details, login IDs and passwords were in a separate system, and the attacker did not reach it.

Editorial assessment. That is the clearest control success in this case. It is also a design you can extend. Ask what would have happened if the customer table had been kept as apart from the web tier as the payment data was. And ask how far back your own customer records go: the notices, as reported, do not say how many of the 7.7 million records belong to customers who have not bought anything for years.

7.7 million records, not 7.7 million people

The company counts records (件), not people, and not every record has every field. The number of unique people affected is not given. Our review of Japan's breach year explains why these units matter.

What the data allows

Name, address, phone number and, for some, date of birth: that is what many call centres and online forms use to check identity.

Editorial assessment. For the people in this data, those facts no longer prove anything. If your support desk, password reset or account recovery accepts date of birth, address or phone number as proof, treat them as known to attackers, not as secrets. Expect phishing that uses the real details: fake versions of Murauchi.com's own notification email, refunds and delivery problems. Murauchi.com warns of messages posing as itself, online shopping malls and card companies. While its social media accounts are paused, watch for impostor accounts claiming to speak for it.

Which teams should act

Team	Practical next step
IT operations	Map what each internet-facing web system can reach on the network, and close administrative paths to internal systems. Remove stored credentials from web servers. Keep payment data separated, and consider doing the same for customer records.
SIEM / SOC	Add an incident check to the outage runbook: preserve logs and snapshots before restoring. Alert on web servers that spawn shells or open connections to internal admin ports. Run the hunts below.
EDR	Make sure web servers, including Linux ones, run an agent and report process and network events. Review any web-server child process you cannot explain.
Email security	Expect lures quoting Murauchi.com's notification email, refunds or deliveries. Warn staff who may be customers.
Legal / privacy	Review retention for former customers. Check how your own notices describe records versus people, and plan the second notice before the first goes out.

IOCs and hunting

No indicators are published. The notices, as reported, name no software, vulnerability, IP address, domain or file. None should be inferred.

The hunts below look for two steps that followed the entry here: a web server running commands it should not, and a web server reaching into other systems. They are for your own environment. All are illustrative and were not run against live data. Table and field names were checked against Microsoft Learn and Splunk documentation on 6 October 2026.

1. Web server processes starting shells or recon tools. Microsoft Defender XDR advanced hunting, DeviceProcessEvents. Covers Windows (IIS) and Linux servers that run Defender for Endpoint. Deployment scripts and health checks can match; review the command line and the account.

// Illustrative; not run against live data. Microsoft Defender XDR advanced hunting.
// Shells and recon tools started by web server processes.
let WebServers = dynamic(["w3wp.exe", "httpd", "apache2", "nginx", "php-fpm", "php-cgi", "java", "tomcat", "node"]);
let Suspicious = dynamic(["cmd.exe", "powershell.exe", "pwsh.exe", "sh", "bash", "dash", "whoami.exe", "whoami",
    "id", "uname", "curl", "wget", "certutil.exe", "net.exe", "nltest.exe", "python", "python3", "perl"]);
DeviceProcessEvents
| where Timestamp > ago(30d)
| where InitiatingProcessFileName in~ (WebServers)
| where FileName in~ (Suspicious)
| project Timestamp, DeviceName, AccountName, InitiatingProcessFileName, FileName, ProcessCommandLine
| order by Timestamp desc
| take 200

2. The same check in Splunk. Sysmon process creation events (Event ID 1) from Windows web servers, collected with the Splunk Add-on for Sysmon. Replace the index.

index="REPLACE_WITH_WINDOWS_INDEX" source="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=1 earliest=-30d latest=now
| eval parent=lower(mvindex(split(ParentImage, "\\"), -1)), child=lower(mvindex(split(Image, "\\"), -1))
| where parent IN ("w3wp.exe", "httpd.exe", "nginx.exe", "php-cgi.exe", "java.exe", "tomcat9.exe", "node.exe")
    AND child IN ("cmd.exe", "powershell.exe", "pwsh.exe", "whoami.exe", "certutil.exe", "net.exe", "nltest.exe")
| table _time Computer User ParentImage Image CommandLine
| sort 0 - _time
| head 200

3. Web servers connecting to internal admin and database ports. Microsoft Defender XDR advanced hunting, DeviceNetworkEvents. List your web servers in the first line. A first connection to a port the server has never used is the lead.

// Illustrative; not run against live data. Microsoft Defender XDR advanced hunting.
// Web servers opening connections to internal administrative or database ports.
let WebServerNames = dynamic(["REPLACE_WITH_WEB_SERVER_NAME_1", "REPLACE_WITH_WEB_SERVER_NAME_2"]);
let AdminPorts = dynamic([22, 135, 139, 445, 1433, 1521, 3306, 3389, 5432, 5985, 5986, 6379, 27017]);
DeviceNetworkEvents
| where Timestamp > ago(30d)
| where DeviceName in~ (WebServerNames)
| where ActionType == "ConnectionSuccess" and RemoteIPType == "Private"
| where RemotePort in (AdminPorts)
| summarize Connections = count(), FirstSeen = min(Timestamp), LastSeen = max(Timestamp),
    Processes = make_set(InitiatingProcessFileName, 5) by DeviceName, RemoteIP, RemotePort
| order by FirstSeen desc
| take 200

Read the results with these limits in mind:

A match is a lead, not proof. Confirm it with the server owner and the change record.
No match is not proof of safety. Logs may be missing or out of retention, and a web shell can run inside the server process without starting a new one.
An application that is supposed to talk to its database will appear in the third query. Exclude known pairs once checked.
DeviceProcessEvents; DeviceNetworkEvents.

What remains unknown

Which web system, software and vulnerability were involved.
When the access began, and how long the attacker was inside before the failure on 15 July.
What failed on 15 July, and whether the attacker caused it.
How the attacker moved from the web system to the others.
How many people the 7,716,811 records represent, and how far back they go.
Whether the data is being sold or published. None has been reported.

Sources and updates

Reviewed for public information up to 6 October 2026, 11:50 JST. Murauchi.com's site blocked access from our network, so its notices were not read directly; the five reports above were checked against each other. ScanNetSecurity's report of 6 October was the prompt for this article. This is independent editorial analysis of public statements, not an investigation. No corrections so far.

30-second briefing