ムラウチドットコム：障害が侵入を明らかにしたとき、771万件の顧客情報はすでに持ち出されていた。

ムラウチドットコムが公表した内容

ムラウチドットコムは、家電やパソコンなどを扱うオンライン販売事業者です。今回の事案について、2026年7月24日と9月15日の2回のお知らせと、よくある質問を公表しています。この記事の作成時、同社のサイトには当サイトのネットワークから接続できませんでした。 そのため、以下の事実はお知らせを直接引用している報道によります：ScanNetSecurity、ITmedia、INTERNET Watch、よくある質問にも触れているセキュリティ対策Lab、第一報についてはUSENのサイバーセキュリティラボです。報道の内容が一致する点を、公表どおりとして記載しています。同社のページは「出典」に掲載しています。

7月24日の第一報の内容：

発覚の経緯。 7月15日未明に社内システムで障害が発生しました。翌16日の復旧作業中に、第三者による不正アクセスの痕跡を確認しました。
初動。 該当システムへの外部からのアクセスを遮断して保全し、外部専門家とともに調査を始めました。7月20日に個人情報保護委員会へ速報を提出し、7月23日に警察へ被害相談をしています。
漏えいの可能性。 顧客の氏名、メールアドレス、住所、電話番号、一部の顧客については生年月日と性別について、漏えいの痕跡が確認されました。件数は示されていません。
対象外。 ID、パスワード、クレジットカード番号などの決済情報は別のシステムで管理しており、対象に含まれていません。

9月15日の第二報（フォレンジック調査の結果）：

侵入の起点。 同社が管理するWebシステムの一部に存在していた脆弱性が悪用されたことが起点で、その後複数のシステムへの不正アクセスが判明しました。ソフトウェアや脆弱性の名前は示されていません。
外部への持ち出しを確認。 顧客の個人情報が外部に持ち出されたことを確認しました。7,716,811件で、氏名、住所、電話番号、メールアドレス、生年月日、性別です。よくある質問では、メールアドレス、生年月日、性別は対象顧客の一部としています。
通知。 9月15日から、対象の顧客に個別にメールを送っています。同日時点で、本件に起因する不正利用、金銭被害、フィッシングメールなどの被害は確認されていません。
再発防止策。 アクセス権限と認証情報の管理方法の見直し、サーバー・ネットワークの監視と不正アクセスの検知体制の強化、定期的な脆弱性診断です。

よくある質問によると、個人情報保護委員会には速報と確報の両方を提出済みです。オンラインストア「ムラウチドットコム本店」は、システムの安全性を確認したうえで営業を続けています。問い合わせ窓口を一本化するため、SNSの運用は2026年11月ごろまで休止しています。

時系列。7月15日未明：社内システムで障害。7月16日：復旧作業中に不正アクセスの痕跡を確認し、外部からのアクセスを遮断して保全。7月20日：個人情報保護委員会へ速報。7月23日：警察へ相談。7月24日：第一報、漏えいの痕跡、件数は未公表。9月15日：第二報。フォレンジック調査完了、Webシステムの脆弱性を起点に複数のシステムへ、7,716,811件の持ち出しを確認、顧客へのメール連絡を開始。痕跡の確認から範囲の確定まで63日。

図1. 深夜の障害から、漏えいの確定まで2か月。オリジナルの図。

セキュリティ見直しで変わること

障害が警報だった

当サイトの分析： 侵入が明らかになったのは、検知したからではなく、システムが壊れたからです。同社自身の再発防止策に監視と検知の強化が含まれていることも、それを示しています。

Webシステムを運用するチームには、2つの教訓があります。

原因の分からない障害は、否定されるまでインシデントの可能性として扱う。 サーバーを復旧させると、ログのローテーションやディスクの上書きで、侵入経路や持ち出された内容を示す証拠が消えることがあります。
復旧の前に保全する。 ムラウチドットコムは、調査の前に外部アクセスを遮断し、システムを保全しました。これは見習うべき手順です。深夜3時に「インシデントの可能性」と判断できるのは誰か、再構築の前に何を保存するか（ディスクのスナップショット、ログ、可能ならメモリ）を、事前に決めておいてください。

1つのWebシステムから、複数のシステムへ

第二報は、1つのWebシステムからの侵入と、その後の複数のシステムへのアクセス、そして顧客情報の持ち出しを説明しています。

当サイトの分析： 本当の発見はこの経路です。外部公開システムの脆弱性は、常にありえます。漏えいの規模を決めるのは、そのシステムから何に届くかです。次の4点を確認してください。

ネットワークの経路。 Webサーバーから顧客データベースへの通信は、アプリケーションが必要とする狭い経路に限ります。他の社内システムの管理用ポート（SSH、RDP、SMB、データベースの管理画面）へは接続できないようにします。
Webサーバー上の認証情報。 管理者のパスワード、鍵、権限の広いサービスアカウントの認証情報を置かないでください。同社の再発防止策にはアクセス権限と認証情報の管理が挙がっており、攻撃者がシステム間を移動する際に認証情報や権限が関わったことを示唆します。ただし報道されている公表文は、そう明言していません。
棚卸しとパッチ。 古いものも含め、運用しているWebシステムを把握し、期限を決めてパッチを当ててください。
移動を検知する。 Webサーバーが社内の管理用ポートに新たに接続したり、シェルを起動したりすることは、それだけでアラートに値します。下のハンティングは、この両方を探します。

分離が守ったもの

カード情報、ログインID、パスワードは別のシステムにあり、攻撃者はそこに届きませんでした。

当サイトの分析： これは、この事案で最もはっきりした対策の成功例です。この設計は広げられます。顧客情報のテーブルを、決済情報と同じようにWeb層から切り離していたらどうなったか、考えてみてください。また、自社の顧客情報がどこまで遡るかも確認してください。報道されている公表文は、771万件のうち何年も購入のない顧客の記録がどれだけあるかを示していません。

771万「件」であり、771万「人」ではない

同社は人数ではなく件数で数えており、すべての記録にすべての項目があるわけではありません。影響を受けた人数は示されていません。単位の違いがなぜ重要かは、日本の情報漏えい、この1年で説明しています。

この情報で何ができるか

氏名、住所、電話番号、そして一部には生年月日。多くのコールセンターやオンラインの手続きが、本人確認に使う情報です。

当サイトの分析： この情報に含まれる人については、これらはもはや本人である証明になりません。サポート窓口、パスワードの再設定、アカウントの復旧で、生年月日、住所、電話番号を本人確認に使っているなら、秘密ではなく攻撃者が知っている情報として扱ってください。実際の情報を使ったフィッシングを想定してください。ムラウチドットコムの通知メールの偽物、返金、配送トラブルを装うものです。同社は、同社やECモール、クレジットカード会社を装ったメール、SMS、電話に注意するよう呼びかけています。SNSが休止している間は、同社を名乗るなりすましアカウントにも注意してください。

どのチームが確認するか

チーム	実務上の次の対応
IT運用	外部公開のWebシステムごとに、ネットワーク上で何に届くかを洗い出し、社内システムへの管理用の経路を閉じる。Webサーバーに保存された認証情報を取り除く。決済情報の分離を維持し、顧客情報にも同じ考え方を適用できるか検討する。
SIEM / SOC	障害対応の手順書に、インシデントの確認を加える。復旧の前にログとスナップショットを保全する。Webサーバーによるシェルの起動や社内の管理用ポートへの接続にアラートを出す。下のハンティングを実行する。
EDR	Linuxを含むWebサーバーにエージェントを入れ、プロセスと通信のイベントを収集する。説明のつかないWebサーバーの子プロセスを確認する。
メールセキュリティ	ムラウチドットコムの通知メール、返金、配送を装った誘導を想定する。顧客である可能性のある社員に注意を促す。
法務・プライバシー	過去の顧客の情報の保存期間を見直す。自社のお知らせで件数と人数をどう書き分けるかを確認し、第一報を出す前に第二報までを計画する。

IOCとハンティング

公開されたIOCはありません。 報道されている公表文は、ソフトウェア、脆弱性、IPアドレス、ドメイン、ファイルを示していません。推測で補うべきではありません。

以下のハンティングは、今回の侵入の後に続いた2つの段階を探します。Webサーバーが本来実行しないコマンドを実行すること、そしてWebサーバーが他のシステムに入り込むことです。対象は自組織の環境です。いずれも参考例であり、実環境では実行していません。テーブル名とフィールド名は2026年10月6日にMicrosoft LearnとSplunkの資料で確認しました。

1. Webサーバーのプロセスによるシェルや偵察ツールの起動。 Microsoft Defender XDRの高度なハンティングで、DeviceProcessEventsを使います。Defender for Endpointを導入したWindows（IIS）とLinuxのサーバーが対象です。デプロイ用のスクリプトや死活監視も該当することがあるため、コマンドラインとアカウントを確認してください。

// 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. 同じ確認をSplunkで。 Splunk Add-on for Sysmonで収集した、WindowsのWebサーバーのSysmonプロセス作成イベント（イベントID 1）を使います。インデックス名を置き換えてください。

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サーバーから社内の管理用・データベース用ポートへの接続。 Microsoft Defender XDRの高度なハンティングで、DeviceNetworkEventsを使います。1行目に自社のWebサーバーを列挙してください。それまで使ったことのないポートへの初めての接続が手がかりです。

// 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

結果を読むときの注意点です。

ヒットは手がかりであり、証拠ではありません。サーバーの担当者と変更記録で確認してください。
該当なしでも、安全とは言えません。ログが欠けている、保存期間を過ぎている、あるいはWebシェルが新しいプロセスを起動せずにサーバーのプロセス内で動いている可能性があります。
データベースと通信するのが正常なアプリケーションも、3つ目のクエリに表示されます。確認済みの組み合わせは除外してください。
DeviceProcessEvents、DeviceNetworkEvents。

分かっていないこと

どのWebシステム、ソフトウェア、脆弱性だったか。
不正アクセスの開始時期と、7月15日の障害までに攻撃者がどれだけ内部にいたか。
7月15日に何が故障したか、攻撃者が原因だったか。
攻撃者がWebシステムから他のシステムへどう移動したか。
7,716,811件が何人分か、どこまで遡るか。
情報が売買・公開されているか。 報告はありません。

出典と更新履歴

2026年10月6日11:50 JSTまでの公開情報を確認しました。ムラウチドットコムのサイトは当サイトのネットワークからの接続を遮断していたため、お知らせは直接読んでいません。上記5件の報道を相互に照合しました。この記事のきっかけは、ScanNetSecurityの10月6日の記事です。この記事は公開情報に基づく独立した編集分析であり、当サイトによる調査ではありません。現時点で訂正はありません。