ATTACK CHAIN攻撃の連鎖
ファイル配信の穴から鍵とログインまでつながった
-
パストラバーサル
添付ファイルを公開するメディアサーバー
-
内部ソースと設定
config.ini を取得（10/11 16:39）
-
シークレットキー
サービス間ログイン用の鍵
-
アカウントIDの総当たり
鍵を使ってログインを試す
-
セッションから内部情報
登録者の連絡先など
30秒でわかる（2026年10月20日時点・経過報告の範囲）
・何が起きたか：自治体向け防災情報配信サービス SpeeCAN RAIDEN（アルカディア）に、2026年10月11日から不正アクセス。のちに NET119・119RAIDEN でも形跡が見つかった
・入口と連鎖：添付ファイルを公開するメディアサーバーのパストラバーサル → 設定ファイル（config.ini）のシークレットキー → アカウントIDの総当たり → ログインしたセッションから内部情報
・規模：SpeeCAN RAIDEN はメールアドレス最大約313万6,000件などの推定上限。確定数ではなく調査中
・分かっていないこと：ソフトウェア名、脆弱だった処理の詳細、実際に持ち出された件数
まずやること
・防災メール・NET119 の登録者：自治体や消防を名乗るメールのリンクから個人情報やパスワードを入力しない。対象かどうかは、自分で開いた自治体の公式サイトで確かめる
・自治体・消防の担当者：配信担当のログインパスワードを変える。登録者への告知と、配信再開の時期を自分の自治体の判断で出す
・ファイルを配信する Web アプリの開発者：アクセスログのトラバーサルの跡と、公開ディレクトリに置いた設定ファイルを確認コマンドで確かめる
委託先や組み込んだ仕組みが入口になる攻撃の全体像は、サプライチェーン攻撃とは｜手口・防御ツール比較・npm 12の新機構まで実践解説にまとめています。本記事は、この件で登録者と自治体がやることと、同じ連鎖を自社のどこで切るかに絞ります。
SpeeCAN RAIDEN 不正アクセスの時系列
TIMELINE経過報告の時系列
設定ファイルの取得から約7時間後に負荷で気づいた
-
06:26
10/11 アクセス開始
10:52 トラバーサル、11:04 セッション固定攻撃の試行
-
16:39
config.ini の取得に成功
16:16〜16:33 パスの探索とトラバーサルの試行
-
23:40
DB の異常な負荷を社内の監視で覚知
16:30 に不審な挙動とする資料もある
-
10/12〜
03:00頃 応急措置、13日に一部停止
15日に全サービス復旧、19日に経過報告
時刻は日本時間です。10月11日の動きはアルカディアの経過報告（10月19日）にある記録によります。
| 日時 | 出来事 | 出典 |
|---|---|---|
| 10-11 06:26 | アクセス開始 | 経過報告 |
| 10-11 10:52〜16:33 | ディレクトリトラバーサルの試行、セッション固定攻撃の試行（11:04）、パスの探索 | 経過報告 |
| 10-11 16:39 | 設定ファイル config.ini の取得に成功 | 経過報告 |
| 10-11 23:40 | 社内のシステム監視が DB の異常な負荷を覚知 | 経過報告 |
| 10-12 03:00頃 | 侵入経路の応急措置と影響調査を開始 | 経過報告 |
| 10-13 | 一部サービスを緊急停止し、攻撃元の IP を拒否。個人情報漏洩の可能性を公表 | 10月13日の公表 |
| 10-14 | NET119・119RAIDEN にも不正アクセスの形跡 | 同社の続報 |
| 10-15 | 全サービスを復旧。配信の再開時期は自治体ごとに違う | 同社の公表 |
| 10-19 | 経過報告で侵入の経路と再発防止策を公表 | 経過報告 |
検知の時刻は資料によって食い違います。経過報告は「23:40 に DB の異常な負荷を覚知」とし、10月11日16時30分に不審な挙動を確認したとする資料もあります。本記事は経過報告の記述を主にしました。どちらの時刻でも、設定ファイルが取られた16時39分より前に攻撃は止まっていません。
何が起きたか：パストラバーサルから鍵、ID総当たりまでの連鎖
経過報告は、手口を次のように説明しています。添付ファイルを公開しているメディアサーバーに、内部の URL へアクセスできるディレクトリパストラバーサルがあった。攻撃者はそこから内部ソースファイルを取得し、設定ファイルの中にあったサービス間ログイン用のシークレットキーを手に入れた。そのキーを使ってアカウントIDへの総当たりを行い、ログインしたセッションから内部情報を取得した、という流れです。
パストラバーサル（ディレクトリトラバーサル）は、ファイル名やパスを受け取る機能に ../ などを混ぜ、公開していない場所のファイルを読ませる攻撃です。CWE-22 に分類されます。
| 段 | 攻撃者が得たもの | 次の段に進めた理由（本記事の読み） |
|---|---|---|
| 1. メディアサーバーのパストラバーサル | 公開していないファイルを読む手段 | 受け取ったパスが公開ディレクトリの外を指しても拒まなかった |
| 2. 内部ソースと config.ini | アプリの作りと設定の中身 | 設定ファイルに秘密の値が書かれ、読めるファイルの範囲にあった |
| 3. サービス間ログイン用のシークレットキー | ログインの材料の片方 | 鍵が手に入れば、残りはアカウントIDだけだったと読める |
| 4. アカウントIDの総当たり | ログインしたセッション | 試行の回数が止められなかった |
| 5. セッションから内部情報 | 登録者の連絡先など | 1つのセッションから多くの情報に届いた |
右の列は、公表された連鎖から本記事が読み取ったものです。同社は、各段でどんな制限が欠けていたかを列挙していません。ソフトウェア名、言語、脆弱だった処理の書き方も公表されていないので、本記事は推測しません。
経過報告から言えること、言えないこと
・言えること：入口はファイルの配信機能で、取られたのは設定ファイルの中の鍵。鍵とアカウントIDの組み合わせでログインできた
・言えないこと：鍵がすべてのアカウントで共通だったか、ID の形式、総当たりの回数と所要時間、取得された情報の件数
・負荷で気づいた点：経過報告の記録では、侵入に気づいたきっかけは DB の異常な負荷。攻撃の途中の試行（トラバーサルや総当たり）では止まっていない
登録者と自治体の対応：防災メール・NET119 で確かめること
防災メール・NET119 の登録者
・対象かどうか：自治体ごとに、対象のサービスと項目、件数を発表している。自分で開いた自治体の公式サイトで確かめる
・不審な連絡：自治体や消防を名乗り、個人情報の再登録やパスワードの入力を求めるメールは開いたリンクから入力しない。登録のやり直しは自治体の公式サイトの案内に従う
・配信の再開：サービスは10月15日に復旧したが、配信を再開する時期は自治体ごとに違う。届かない間の防災情報は、自治体のサイトなどほかの経路で受け取る
NET119 は、音声での通報が難しい人がスマートフォンなどから 119番通報するためのサービスです。対象かどうかと、通報に使えるかは、登録した消防本部の案内で確かめてください。
自治体・消防の担当者
アルカディアは、システムの利用者にログインパスワードを変更してから使うよう呼びかけています。配信担当のアカウントは変更し、使い回していた他のサービスのパスワードも変えます。
委託先の事故で自治体側に残る仕事は、登録者への告知、問い合わせ窓口、配信を再開する判断、個人情報保護委員会への報告の整理です。件数は委託先の推定上限ではなく、自分の自治体の登録件数で告知している例が多くあります。
パストラバーサル対策：連鎖を各段で切る（開発者向け）
WHERE TO CUT各段で切る
どこか1段で切れていれば連鎖は止まる
連鎖の段
その段を切る対策
連鎖の段: パストラバーサル
その段を切る対策: パスを正規化し、公開ディレクトリの外を拒む
連鎖の段: 設定ファイルの取得
その段を切る対策: 設定と秘密をウェブから届く場所に置かない
連鎖の段: 鍵だけでログインできる
その段を切る対策: 鍵は KMS 等に置き、利用者ごとの認証と分ける
連鎖の段: ID の総当たり
その段を切る対策: 失敗回数の制限と、異常な負荷・試行の検知
ここからは同じ連鎖を自社で起こさないための一般論で、アルカディアの実装を指すものではありません。1段で止められなかったときに次の段で止まるよう、段ごとに別の対策を置きます。
| 段 | 切る対策 | 詳しくは |
|---|---|---|
| パストラバーサル | 受け取ったパスを正規化（シンボリックリンクも解決）してから、公開ディレクトリの中に収まるかを確かめる。ファイル名を受け取らず ID で引く形にできれば、そのほうが確実 | OWASP・CWE-22 |
| 設定ファイルの取得 | 設定と秘密の値を、アプリの公開ディレクトリやソースと同じ場所に置かない | 下の確認コマンド |
| 鍵だけでログインできる | 秘密の値は KMS やシークレット管理に置き、平文の設定に書かない。サービス間の鍵と、利用者ごとのログインを分ける | 暗号鍵管理の置き場所 |
| ID の総当たり | 鍵や接続元ごとの試行回数を制限し、失敗が続いたら止める | APIレート制限の設計 |
| セッションから内部情報 | 大量の読み出しと DB の負荷を記録し、閾値で知らせる | 監査ログの設計 |
パスを文字列で比べるだけの判定は、符号化した ..%2f や二重符号化の %252e、区切り文字の \ で抜けることがあります。比べるのは、デコードと正規化を済ませた後のパスです。
鍵の段は攻撃者の前提で分けると考えやすくなります。設定ファイルを読まれただけなら、秘密の値が KMS などにあれば鍵そのものは出ません。アプリの権限でコードを動かされた場合は、アプリが復号できる鍵は攻撃者も使えます。どこまで守れるかは、鍵を使える主体と条件の設計で変わります。
自システムの確認コマンド：トラバーサルの跡と、公開ディレクトリの設定ファイル
ここからは、ファイルを配信する Web サーバーを持つ側の確認です。この件の原因を調べるものではありません。どちらも読み取りだけで、見ているのは「ログに残った目印」と「置き場所」です。侵入されたかどうかの判定ではありません。
1. アクセスログに、トラバーサルの試行と 200 の応答が無いか
nginx の combined 書式のログを想定し、圧縮済みの古いログ（.gz）も読みます。ログの場所は自分の環境に置き換えてください。
cd /var/log/nginx && pwd
zgrep -hiE '"[A-Z]+ [^"]*(\.\./|\.\.%2f|\.\.%5c|%2e%2e(/|%2f|%5c)|%252e)[^"]*" 200 ' access.log* | awk '{print $1, $4, $7}' | sort | uniq -c
zgrep -hiE '"[A-Z]+ [^"]*(\.\./|\.\.%2f|\.\.%5c|%2e%2e(/|%2f|%5c)|%252e)' access.log* | awk '{print $1}' | sort | uniq -c | sort -rn
2行目では ../ とその符号化（大文字小文字・\ の符号化・二重符号化を含む）を含むリクエストのうち、200 を返したものを接続元・時刻・パスで出します。3行目は応答に関係なく試行の多い接続元を順に出します。
2. 公開ディレクトリに、設定ファイルや秘密の値の入ったファイルが無いか
ウェブサーバーが配信するディレクトリ（例は /var/www）に移ってから実行します。html/media/ のような添付ファイルの置き場所も含めて探します。
cd /var/www && pwd
find . -type f \( -name '*.ini' -o -name '.env' -o -name '*.bak' -o -name '*.sql' \) -print
結果の読み方と、このコマンドの限界
ダミーのログとディレクトリで、掲載したままのコマンドを走らせました（ログとディレクトリの場所だけ検証用に差し替え）。
| コマンド | 陽性対照（目印を置いた） | 陰性対照（置かない） |
|---|---|---|
| 200 を返した試行 | ../・..%2f・..%5c・%252e を含む 200 の行が出た（.gz 側も）。404 の行は出なかった |
通常の画像の取得だけのログで0行 |
| 試行の多い接続元 | 大文字の %2E%2E%2F で 404 になった試行も数えた |
同じログで0行 |
| 設定ファイル | media/config.ini・.env・app.ini.bak が出た |
index.html だけのディレクトリで0行 |
読むときの注意は3つです。
・何も出なくても侵入が無かったとは限らない：ログの保存期間より前は見られない。ここに無い符号化や、アプリが独自に受け取るパラメータ（パスを ID や Base64 で渡すもの）は拾わない。POST の本文はアクセスログに残らない
・出ても侵入とは限らない：スキャナーの試行は多くのサーバーに届く。200 でも、アプリが公開ディレクトリの中のエラー画面を返しただけのことがある。応答のバイト数と、そのパスで実際に何が返るかを突き合わせる
・設定ファイルを外に出すだけでは足りない：トラバーサルは公開ディレクトリの外も読む。2つ目のコマンドで減らせるのは URL を直接指定されたときの露出で、トラバーサルそのものはパスの検証で止める
SpeeCAN RAIDEN の影響範囲：件数の読み方と再発防止策
アルカディア 不正アクセスの件数は、出典ごとに単位と時点が違います。アルカディアの数字は推定上限で、自治体の数字はその内訳と重なりうるので、足し合わせません。
| 対象 | 件数 | 出典 |
|---|---|---|
| SpeeCAN RAIDEN 全体 | メールアドレス最大約313万6,000件、電話番号約10万5,000件、FAX番号約1万5,000件（推定上限・調査中） | アルカディア |
| NET119 | 当初、最大約1万3,000件（10月14日の続報） | アルカディア |
| さいたま市（防災情報配信） | 最大3万4,856件 | さいたま市 |
| 埼玉県警（安否確認システム） | 警察官・職員約1万3,000人に漏えいの可能性 | 埼玉県警の発表の要約 |
| 下関市 | 防災メール約1万5,000件、NET119 の50人 | 下関市の発表の要約 |
影響した自治体などの数は、資料によって幅があります（125以上とする集計もあります）。
経過報告と各公表の再発防止策は、段階を分けて読みます。
| 段階 | 内容 |
|---|---|
| 実施済み | データベースへのアクセス方法を見直し、サービスごとにパスワードを設定 |
| 予定 | 外部企業による脆弱性診断、2段階認証の導入 |
| 検討中 | SOC（セキュリティ監視の体制）の導入 |
対応から学べること
経過報告と各公表の時系列から、手口とは別に、事故のあとの動き方で参考になる点を挙げます。いずれも公表された事実からの本記事の読みで、同社の判断の是非を断じるものではありません。
| 論点 | 公表された事実 | 自社に当てはめるなら |
|---|---|---|
| 鍵の共有が被害を広げた | 10月14日に NET119・119RAIDEN でも形跡。再発防止策に「サービスごとにパスワードを設定」 | 鍵と DB の認証情報はサービスごとに分け、1つ漏れても隣に入れない形にする |
| 検知から停止までの時間 | 設定ファイルの取得（11日16:39）から覚知（23:40）まで約7時間、覚知から一部サービスの緊急停止（13日11:00）まで約35時間 | 止めにくいサービスほど、ログインや管理画面だけ閉じて配信は残すといった縮退運転の手順を先に決めておく |
| 委託先1社への集中 | 防災メールの配信を止めた自治体が多数に上った | 委託する側は、防災無線・Lアラート・SNS など別の経路を残す。復旧の連絡を受けても、安全を確かめてから再開する（実際にそうした自治体もある） |
| 数字の単位 | 推定上限（件）と、自治体ごとの確認数・可能性のある人数が並んだ | 件と人、上限と確定、可能性と確認済みを分けて書き、続報で変わったら前の数字との関係を書く |
| 経過の公表 | 分単位の時系列と手口、再発防止策を実施済み・予定・検討中に分けて公表した | 手本にできる。ただし先の発表と時刻が食い違うときは、どちらを正とするかを書く |
公表された対策は「サービスごとのパスワード設定」です。設定ファイルから取られたシークレットキーそのものを取り替えたかは、経過報告には明記されていません。漏れた鍵は、使えなくするまで漏れたままです。
続報では次の点を確かめます。
・実際に取得された情報の件数と項目
・脆弱性の修正の中身と、外部の脆弱性診断の結果
・シークレットキーとアカウントの扱い（取り替えたか）
・自治体ごとの配信再開と、登録者への個別の連絡
参照ソース
・アルカディア「不正アクセスの経過と当社の対処について」（2026-10-19） — 10月11日の時系列・侵入の連鎖・再発防止策
・アルカディア「SpeeCAN RAIDEN への不正アクセスによる個人情報漏洩の可能性について」（2026-10-13） — 第一報・一部サービスの停止
・さいたま市「防災情報配信システムの不正アクセスに伴う個人情報漏洩の可能性発生について」 — 市の件数
・埼玉県警、警察官・職員約1万3,000人の個人情報漏えいの可能性（セキュリティ対策Lab） — 埼玉県警の発表の要約（補助）
・山口県下関市「防災メール」約1万5,000件の登録情報に漏えいの可能性（セキュリティ対策Lab） — 下関市の発表の要約（補助）
・SpeeCAN RAIDEN への不正アクセスのまとめ（セキュリティ対策Lab） — 影響した自治体の集計（補助）
・アルカディアに不正アクセス、NET119にも影響（サイバーセキュリティ.com） — NET119 の当初件数（補助）
・防災情報配信サービス「SpeeCAN RAIDEN」への不正アクセスについてまとめてみた（piyolog） — 公表の経緯の整理（補助）
・OWASP: Path Traversal — 攻撃の定義と符号化の例
・CWE-22: Improper Limitation of a Pathname to a Restricted Directory — 分類
