2022年10月31日の朝、大阪市住吉区の 大阪急性期・総合医療センター で電子カルテが動かなくなり、サーバーには英文のランサムノートと、拡張子 .elbie に変わったファイルが残されていました。救急・外来・予定手術を止め、紙カルテでの診療に切り替わります。電子カルテを含む基幹システムの再稼働は43日目の12月12日、部門システムを含む全面復旧は73日目の2023年1月11日でした。
2023年3月28日に公表された調査委員会の報告書は、攻撃者が病院ではなく 院外の給食事業者のデータセンター から入り、病院の給食サーバーを踏み台にして電子カルテ系へ到達した経路を、ファイアウォールのログとフォレンジック結果から具体的に示しています。本記事では、この報告書をもとに各段階を整理します。
■ この記事のまとめ
- 初期侵入：給食事業者（E社）のデータセンターに、システム構築事業者がリモート保守用に設置したファイアウォール Z（SSL-VPN、FortiOS 5.4.2）。CVE-2018-13379 が未修正で、同機の IP・ID・パスワードが攻撃者の間で公開されたリストに載っていた
- 給食事業者内：辞書攻撃ツールで社内端末に RDP ログオン（Built-in Administrator のパスワードが共通かつ推測可能）。病院のサーバーB（栄養給食管理）の認証情報も入手
- 病院への侵入：E社と病院のサーバーB の間は、保守事業者の要請で RDP（3389）が常時許可されていた。10月31日 4:07 から大量の RDP 接続。ウイルス対策ソフトをアンインストールし、Mimikatz などのツールを設置
- 横展開：サーバーB の Administrator のパスワードが基幹系サーバーと共通、セグメントも同一。約240 の IP をスキャン、約70 の IP に RDP を試行し、仮想統合ホスト・運用管理・NAS などを暗号化。電子カルテサーバーにはウイルス対策ソフトがなかった
- 分類：VPN 装置の既知脆弱性・流出認証情報を起点とする、委託先経由の人手によるランサムウェア攻撃（Phobos 系 Elbie）
概要
| 項目 | 内容 |
|---|---|
| 被害組織 | 大阪急性期・総合医療センター（大阪府立病院機構） |
| 発生 | 2022年10月31日（4:07〜4:10 に大量の RDP 接続） |
| ランサムウェア | Elbie（Phobos ファミリー）。暗号化後の拡張子 .elbie |
| 侵入経路 | 給食事業者（E社）のデータセンターのファイアウォール Z（SSL-VPN、FortiOS 5.4.2）。CVE-2018-13379 未修正、ID/パスワードが公開リストに掲載 |
| 病院への経路 | E社のサーバーA → ファイアウォール Y（RDP・SMB などを常時許可）→ 病院のサーバーB（栄養給食管理） |
| 横展開 | Mimikatz によるパスワード解析、共通の Built-in Administrator パスワード、同一セグメント、PsExec の痕跡 |
| 被害 | 基幹システムサーバーの大部分が暗号化（物理約20台・仮想100台以上）。端末約2,200台に不正アクセスの痕跡 |
| 情報流出 | 可能性は極めて低い（通信ログ・フォレンジック調査から） |
| 復旧 | 基幹システム 12月12日（43日目）、全面復旧 2023年1月11日（73日目）。全サーバー・端末をクリーンインストール |
| 被害額 | 調査・復旧費用で数億円以上、逸失利益は十数億円以上の見込み |
| 攻撃の分類 | 既知脆弱性・有効なアカウントの悪用、委託先（サプライチェーン）経由の侵入、人手によるランサムウェア攻撃 |
事件の時系列
| 日時 | 出来事 |
|---|---|
| 2022年4月〜 | ファイアウォール Y のログで、E社からの RDP 通信がこの時期までさかのぼって確認された。10月31日以前からログオン失敗の記録もあった |
| 10月31日 3:45 | ファイアウォール Y が、E社からの大量の RDP セッションを記録 |
| 4:07〜4:10 | E社のサーバーA から病院のサーバーB へ大量の RDP 接続 |
| 4:08 以降 | RDP を使った操作を検知（当時はログ・アラートを誰も見ていなかった） |
| 遮断の約3時間前 | 病院に配置された給食関連の委託職員が、電子カルテが動かないことを確認 |
| 7:45 | システム管理委託職員がランサムノートと暗号化を確認 |
| 8:30〜8:40 | ネットワークを遮断 |
| 夕方（18時ごろ） | E社側の構築事業者がファイアウォール Z のファームウェアを 7.2.2 へ更新。バックアップを取らなかったため Syslog が消失 |
| 11月4日 | 予定手術を再開 |
| 11月9日 | オフラインのバックアップデータを参照できるシステムを用意 |
| 12月12日 | 電子カルテ・オーダリング・医事会計など基幹システムが再稼働 |
| 2023年1月11日 | 部門システムを含めて復旧し、通常診療を再開 |
| 2023年3月28日 | 調査委員会が報告書を公表 |
① 初期侵入：給食事業者のデータセンターの SSL-VPN
病院は患者給食を、外部の給食事業者（報告書ではE社。報道では社会医療法人生長会の給食センター）に委託していました。E社の給食センターのシステムは、構築事業者（C社）と給食アプリケーションの提供事業者（D社）が、ファイアウォール Z の SSL-VPN でリモート保守していました。
ファイアウォール Z の FortiOS は、当初 6.0.11 と説明されていましたが、後日の確認で 5.4.2 だったことが分かっています。この版には CVE-2018-13379（CVSS v3 9.8）が残っていました。SSL-VPN の Web ポータルのパストラバーサル（CWE-22）で、認証なしに装置のシステムファイルを読み出され、保存されている認証情報を得られるものです。詳しい影響範囲と悪用の仕組みについては、Fortinet の PSIRT アドバイザリ（FG-IR-18-384） と JPCERT/CC の注意喚起 をご参照ください。
報告書は、この脆弱性で収集された世界中の VPN 装置の IP アドレス・ID・パスワードの公開リストに E社のファイアウォール Z も掲載されていた ことを確認し、「公開されたリストにある ID、パスワードを使用して侵入されたと考えるのが合理的」としています（T1078、T1133、脆弱性の直接の悪用なら T1190）。接続元の制限もありませんでした。半田病院の事件（2021年10月）と同じ脆弱性・同じ流出リストです。
ただし、構築事業者が当日夕方にログを保全せずにファームウェアを更新したため、VPN の Syslog は残っておらず、侵入の日時や、10月31日の攻撃が単独で行われたのかは断定できていません。
② 給食事業者の社内：辞書攻撃と、病院サーバーの認証情報
攻撃者はE社のネットワークに入ると、辞書攻撃ツールで社内 LAN の端末に RDP でログオン しました（T1110、T1021.001）。E社の端末の Built-in Administrator のパスワードは共通で推測しやすく、攻撃ツールのパスワードリストに含まれていました。
ここで鍵になったのが、E社のサーバーA の業務の仕組みです。サーバーA は、病院のサーバーB の Built-in Administrator の ID・パスワードを使って、サーバーB の共有フォルダーと毎日ファイルをやり取りしていました。攻撃者はE社内でシステム情報（IP アドレスやパスワード情報など）を窃取し、病院に入るための認証情報も手に入れました。
③ 病院への侵入：常時接続の RDP
病院とE社の間は閉域網で結ばれ、病院側のファイアウォール Y は、E社からサーバーB への RDP（TCP/UDP 3389）、SMB（TCP/UDP 445、TCP 139）、SQL Server（TCP 1433） を許可していました。RDP の常時許可は構築事業者（C社）の要請によるものでしたが、後の調査で 実際には業務で使われていなかった ことが判明しています。
10月31日 4:07〜4:10、サーバーA からサーバーB へ大量の RDP 接続が発生しました。攻撃者はサーバーB に RDP でログオンすると、ウイルス対策ソフトをアンインストール し（T1562.001）、デスクトップに作ったフォルダーに Mimikatz などの攻撃ツールを置きました。サーバーB は NIC を2枚持ち、1枚はファイアウォール Y 側、もう1枚は 病院 LAN のサーバーセグメント に直接つながっていました。
④ 認証情報の取得と探索
サーバーB の Built-in Administrator のパスワードは Mimikatz で解析されました（T1003）。病院では、サーバーごと・端末ごとの Administrator のパスワードがそれぞれすべて共通 だったため、サーバーB で得たパスワードがそのまま他の基幹サーバーで使えました。パスワードポリシー自体は「英大小文字・数字12桁」でしたが、共通化されていれば1か所の漏えいで全台が開きます。
攻撃者はツールで到達可能な約240の IP アドレスなどの情報を集め（T1046）、サーバーB から約70の IP アドレスへ RDP 接続を試行しました。ドメインコントローラーのイベントログには 4625（ログオン失敗）が大量に記録されたあとに成功 が記録されており、アカウントロックアウトが設定されていなかったことも、試行を続けられた理由です。
⑤ 横展開と暗号化
フォレンジック調査の対象となったサーバーでは、基幹サーバー1〜3号機、運用管理サーバー、仮想統合ホスト（Oracle 用とその他）、別館 NAS などで Elbie ランサムウェアの感染 が確認されています（T1486）。ドメインコントローラーは RDP 接続の試行が確認されたものの暗号化されていません。端末では暗号化は確認されなかった一方、SMB での他ホストへの接続試行や PsExec の痕跡（T1569.002）が見つかっています。
電子カルテシステムのサーバーには、レスポンスの低下を懸念して ウイルス対策ソフトが導入されていませんでした（他のサーバーと端末には導入済み）。報告書は、攻撃者は「わざわざウイルス対策をアンインストールしなくても簡単に攻撃ツールを設置し、暗号化ツールを実行できた」と指摘しています。
持ち出しについては、RDP で E社からサーバーB へ約1.8MB（ツールのコピーと推定）、SMB でサーバーB から E社へ約7.9MB の通信があったものの、ログの詳細設定がなく内容は不明です。サーバーB のデータベースは50MB を超えるため、データベースの窃取はなかったと判断されています。
他の病院はなぜ無事だったのか
同じE社の給食システムには、ほかの病院も接続していました。報告書はそれらの病院と比較し、差を次のように整理しています。
| 給食サーバーのパスワード | 給食サーバーのセグメント | 結果 | |
|---|---|---|---|
| 大阪急性期・総合医療センター | 電子カルテ群と共通 | 電子カルテ群と共通 | 電子カルテ群まで暗号化 |
| L 病院 | 構築事業者の指定から1文字変更 | 電子カルテ群と別 | 不正アクセスの試行はあったが侵入されず |
| M 病院 | 電子カルテ群と別 | 電子カルテ群と別（ゲートウェイ端末も設置） | 給食サーバーには侵入されたが、その先へは進まれなかった |
入口が同じでも、パスワードの使い回しとセグメントの共有 の有無で被害が分かれたことになります。報告書は、攻撃者が L 病院・M 病院への侵入を諦め、大阪急性期・総合医療センターに集中したと見ています。
復旧：全台クリーンインストール
物理サーバー約20台・仮想サーバー100台以上が対象で、AD のログでは約1,000台の端末がログオンの失敗・成功を繰り返していました。平時のログがなく正常時との比較ができないため、病院は オフラインで保存していた患者データを使い、サーバー・端末をすべて初期化して再構築 する方針を取りました。2022年11月の実績は前年同月比で新入院患者33.3％、初診17.9％、手術28.1％、救急車搬入13.0％まで落ち込んでいます（本事案に起因する死者はなし）。
MITRE ATT&CK との対応
報告書自身も、脆弱性を CWE、攻撃手法を ATT&CK で整理しています（図6）。本記事の整理は次のとおりです。
| 段階（戦術） | 技術 | 本件での事実 |
|---|---|---|
| 初期アクセス | T1190／T1078／T1133 | FortiOS 5.4.2 の SSL-VPN。CVE-2018-13379 未修正、認証情報が公開リストに掲載 |
| 認証情報アクセス | T1110 Brute Force | E社の端末に辞書攻撃ツールで RDP ログオン。病院の DC にも 4625 が大量 |
| 横展開 | T1021.001 Remote Desktop Protocol | 常時許可の RDP でサーバーA→サーバーB、サーバーB から約70 IP へ試行 |
| 防御回避 | T1562.001 Disable or Modify Tools | サーバーB のウイルス対策ソフトをアンインストール |
| 認証情報アクセス | T1003 OS Credential Dumping | Mimikatz で Built-in Administrator のパスワードを解析 |
| 探索 | T1046 Network Service Discovery | 約240 の IP アドレスなどの情報を収集 |
| 実行 | T1569.002 Service Execution | 端末で PsExec の痕跡 |
| 影響 | T1486 Data Encrypted for Impact | Elbie で基幹サーバー群・NAS を暗号化 |
本事件を未然に防ぐために必要な予防策
初期侵入を防ぐ（委託先を含めて）
- 委託先の外部接続機器まで脆弱性管理の対象にする：報告書は、VPN 機器やファイアウォールの保守・脆弱性管理の役割分担が曖昧だったことを最初の発生要因に挙げています。機器ごとに管理者・設置者・保守範囲を文書で確認します。
- 認証情報が流出する脆弱性では、修正と全パスワード変更をセットで：修正が済んでいても、流出済みの認証情報で入られます。
- リモート保守の許可基準と棚卸し：外部接続を許可する基準を定め、許可した接続の利用状況とログを定期的に確認します。本件の RDP は実際には不要でした。
侵入後の拡大を食い止める
- パスワードの個別化：サーバー・端末の管理者パスワードを Windows LAPS などで一意にします。他院との差を分けたのはこの1点でした。
- 委託先と接続するサーバーの分離：委託先とファイルを授受するサーバーは、電子カルテ群と別セグメントに置き、間に必要最小限の通信だけを許可するゲートウェイ／ファイアウォールを挟みます。デュアル NIC で両方のセグメントに直結させない構成にします。
- 委託先に管理者アカウントを渡さない：ファイル授受は専用の権限の小さいアカウントで行い、Built-in Administrator を業務に使わせません。
- 標準ユーザー運用・UAC・ロックアウト：全ユーザーへの管理者権限付与をやめ、アカウントロックアウトを有効にします。
検知と影響の最小化
- 境界のログ・アラートを誰かが見る体制：ファイアウォール Y は 3:45 の時点で大量の RDP セッションを記録していました。監視とエスカレーションの経路を決めておけば、暗号化前に遮断できた可能性があります。
- 電子カルテサーバーにもマルウェア対策・EDR：性能への影響は除外設定の検証で対応し、導入しない慣習をやめます。
- オフラインバックアップと参照系：本件では、オフラインで保存していたデータを参照できるシステムを9日で用意し、診療を続けられました。
- ログを保全してから機器を更新する：インシデント対応の手順に、ファームウェア更新や初期化の前の証拠保全を入れます。
まとめ
大阪急性期・総合医療センターの事件は、病院が直接管理していない給食事業者の VPN 装置から始まりました。未修正の脆弱性と流出済みの認証情報で委託先に入り、委託先が持っていた病院サーバーの管理者パスワードと、使われていない常時接続の RDP で病院へ、そして共通のパスワードと同一セグメントで電子カルテ系へ――経路のどの段階にも、既に知られた対策で止められる点がありました。同じ委託先とつながっていた他の病院が、パスワードとセグメントの分離だけで被害を免れていたことは、内部の基本的な設定がどれほど結果を左右するかを示しています。
■ メモ
本記事は、大阪急性期・総合医療センター 情報セキュリティインシデント調査委員会の報告書（2023年3月28日）と報道をもとに、公表された範囲の事実を整理したものです。VPN 装置のログが失われたため、初期侵入の日時と手段は報告書でも推定にとどまります。
参考資料
- 大阪急性期・総合医療センター「情報セキュリティインシデント調査報告書」（PDF）
- 大阪急性期・総合医療センター「情報セキュリティインシデント調査報告書 概要」（PDF）
- Fortinet PSIRT「FG-IR-18-384」
- JPCERT/CC「複数の SSL VPN 製品の脆弱性に関する注意喚起」
- ITmedia エンタープライズ「大阪急性期・総合医療センターが前年10月のランサムウェア被害に関する調査報告書を公開『全ユーザーに管理者権限を付与』」
- ScanNetSecurity「大阪急性期・総合医療センターへのランサムウェア攻撃に関する報告書『誤った閉域網神話によるセキュリティ意識の薄れ』指摘」
- MITRE ATT&CK
ほかの事件の解説は「日本のサイバーセキュリティ事件まとめ」から読めます。
