大阪急性期・総合医療センター 2022年 給食の委託先から入ったランサムウェア

攻撃者が最初に入ったのは病院ではなく、患者の給食を受託した会社の給食センターだった。そこから病院の給食サーバーへ、使われていないのに常時開いていたRDPで入り、全台で共通の管理者パスワードで電子カルテのサーバーまで届いた。病院の網の境界は、契約の数だけ外に延びていた。

2023年3月28日の大阪急性期・総合医療センター情報セキュリティインシデント調査委員会の報告書と概要に沿って書いています[1][2]。病院は2022年12月12日に基幹システムを、2023年1月11日に診療機能を完全に復旧した[1]。事業者は、報告書に倣いA社からE社の記号で示します。報告書は安全上の理由で一部の情報を伏せている。

要点

  • 2022年10月31日の早朝、給食事業者のセンターのサーバーから病院の給食サーバーへ大量のRDPの接続があり、電子カルテを含む基幹システムのサーバーの大部分が、ランサムウェア Elbie で暗号化された。
  • 入口は給食センターのVPN機器と見られる。CVE-2018-13379 が残り、その機器のIPアドレス、ID、パスワードが公開された一覧に載っていた。
  • 病院の境界のファイアウォールは、給食センターからのRDPを常時許していた。システムの事業者の求めで開けたが、実際には使われていなかった。
  • 中では、利用者全員が管理者、サーバーと端末の管理者パスワードが共通、ロックアウト無し、電子カルテのサーバーにウイルス対策無し。基幹システムの再稼働に43日、全体の復旧に73日かかった。
  • 報告書は中核の要因を、病院と事業者の責任分界の不明瞭さに置いた。外部接続の台帳、許可の基準、使われ方の確認を持つことが根本の直しになる。

何が起きたか

2022年4月から給食センターからのRDPが記録され、10月31日早朝に暗号化、12月12日に基幹システム、2023年1月11日に全体が復旧した 2022年4月 給食センターから RDPの記録が残る 10月31日 3時台 走査、続いて 大量のRDP 5時31分から サーバーで次々に 暗号化を実行 7時45分 障害を認知、紙の カルテへ切り替え 2023年1月11日 全体が復旧、 通常診療を再開 RDPの許可 常時開いたまま、使われ方は見ず 診療の制限 基幹の再稼働まで43日、全体73日 帯の長さは時間の比ではない
図1 給食センターからのRDPの記録から、発覚と復旧までの流れ
日付報告書の内容
2017年7月病院が給食事業者E社と患者給食の委託を契約。2018年4月から5年の業務。E社の給食システムを作ったのは、病院の給食システムと同じC社とD社[1]
2022年4月29日、5月24日、5月27日、6月8日給食事業者からのRDPのログオンによる操作が、病院のファイアウォールYのログに残る。報告書は、以前からE社経由で攻撃を受けていた可能性も否定できないとした[1]
9月29日から10月18日給食事業者からTCPの139、445、3389番への通信が記録される。一部はファイアウォールYで遮断[1]
10月31日 3時45分給食事業者から病院の給食サーバー、報告書のサーバーBへの走査が始まり、4時7分から4時10分ごろに大量のRDPの接続[1]
10月31日 5時31分以降運用管理サーバー、基幹サーバー、NASサーバー、仮想統合サーバーで順にランサムウェアが実行され、永続化された[1]
10月31日 7時45分出勤したヘルプデスクの職員が障害と身代金要求の文書を確認。8時30分ごろ電子カルテの事業者が感染を確認して遮断。8時50分に紙カルテでの運用へ切り替え、救急、予定手術、通常の外来を止めた[1]
10月31日厚生労働省に報告し、初動対応支援の専門家3人の派遣を受けた。専門家は同日、E社を経由した攻撃と判断した。同じ日の夕方、C社が給食センターのVPN機器のファームウェアを控えを取らずに更新し、機器のログが失われた[1]
11月4日予定手術を再開。11月9日までに、オフラインの控えを参照できる仕組みを作った[1]
12月12日電子カルテ、オーダリング、医事会計などの基幹システムが再稼働。障害の発生から43日目[1]
2023年1月11日部門システムを含む全体が復旧し、通常診療を再開。73日目[1]
2023年3月28日調査委員会の報告書と概要を公表[1][2]
  • 病院は865床。院内の端末は約2,200台で、感染の疑いがある約1,300台を全部は調べきれず、全サーバーと全端末を初期化した[1]。
  • 2022年11月の新入院患者は558人で前年同月の33.3%、初診は465人で17.9%、救急車の受け入れは88件で13.0%だった[1]。本事案に起因する死者は出ていない[1]。
  • 概要は、調査と復旧の費用を数億円以上、診療の制限による逸失利益を十数億円以上と見込む[2]。
  • 病院から給食事業者への目立つデータの転送は観測されず、報告書は情報漏えいの可能性は極めて低いとした[1]。
  • 電子カルテなどの控えはほぼ使え、10月27日の状態に戻した。重症系のシステムの控えはオンラインだけで、使えなかった[1]。

通った道筋

給食センターのVPN機器から入り、センターのサーバーAで病院の資格情報を取り、常時許されたRDPで病院のサーバーBへ入り、共通の管理者パスワードで電子カルテのサーバー群へ広がった 給食事業者E社の給食センター 1 VPN機器 ファイアウォールZ C社が設置、CVE-2018-13379 公開の一覧にIDとパスワード 2 サーバーA 弱く共通のパスワードで入られ 病院の管理者の資格情報も 病院 ファイアウォールY E社からの3389番を常時許可 センターと病院は 閉域の回線でつながる 3 サーバーB 病院の給食サーバー NICが2枚で、院内の網にも直結 ウイルス対策を外し、資格情報を取る 4 電子カルテと部門のサーバー 管理者パスワードはサーバーBと共通 電子カルテのサーバーにウイルス対策無し 端末へもログオンを試す Elbie で暗号化
図2 報告書が推定した攻撃者の手順。給食センターの機器のログは失われ、入口は推定
手順報告書の推定
1 給食センターへC社がリモート保守のために置いたファイアウォールZの脆弱性か、公開された一覧の資格情報で入った。一覧は2021年9月に Fortinet が告知した、約8万7千台分の公開である[4]。報告書は、一覧のIDとパスワードで入ったと考えるのが合理的と書く[1]
2 センターの中辞書攻撃の道具でRDPのログオンに成功した。センターの端末の Built-in Administrator は共通で推測できるパスワードだった。サーバーAは、病院のサーバーBの Built-in Administrator のIDとパスワードで、毎日ファイルをやり取りしていた[1]
3 病院の給食サーバーへ常時許されたRDPで、窃取した資格情報を使ってサーバーBに入り、ウイルス対策を外した。ファイアウォールYは、139、445、1433、3389番を許していた[1]
4 院内のサーバーへサーバーBで道具を使い他のサーバーの資格情報を取った。サーバーの管理者IDとパスワードはほぼ同一で、電子カルテなど基幹と部門のサーバーに入り、ランサムウェアを実行した[1]

報告書は、自己増殖するウイルスが広がったのではなく、攻撃者が手で各機器に入って実行したと見る[1]。ADのイベントログには、ログオン失敗の4625が大量に並び、その後に成功が記録されていた[1]。報告書は、入口の弱点を CWE-22 の経路の横断、弱い資格情報を CWE-1391 と分類している[1]。

機器の版は資料によって違う

ファイアウォールZの事故の時点の版は、報告書の本文では後日の確認で5.4.2、概要では5.4.8と書かれ、一致しない[1][2]。NVD の記述では、CVE-2018-13379 が当たるのは FortiOS の5.4系なら5.4.6から5.4.12である[5]。どちらの版でも、資格情報が一覧に載っていた事実は変わらない。どちらの版かは決まっていない。

証拠は初動で消えた

C社の担当は、現地で管理画面を開いたときに出た更新の案内に従い、いつもの手順どおり作業の前に更新した。この機器は外から接続すると更新の案内を出さないため、長く更新されずにいた[1]。E社は、この機器を使っている認識が無かった[1]。報告書は、攻撃が10月31日の1回だけだったかを断定できないとした[1]。

なぜ境界が延びていたか

病院はA社からE社と別々に契約し、給食センターのVPN機器の更新と、病院へのRDPの許可の管理を、誰も持っていなかった 病院 情報資産を把握せず A社 電子カルテ、統括 B社 網と境界の機器 C社 給食の基盤、VPN D社 給食のアプリ E社 給食の受託 VPN機器の更新とRDPの許可の見直しを、誰が持つかが決まっていなかった
図3 報告書が示す契約の関係を簡略にしたもの。赤は侵入の経路に関わった事業者

報告書は、中核の要因を、病院と事業者の間で、保守や脆弱性の管理を誰が持つかが契約を含めて決まっていなかったことに置く[1]。

  • 病院は、C社の依頼で、E社からのRDPを既定の3389番のまま常時許可し、その後に使われ方を確かめなかった。2022年11月24日の会議で、この許可は実際には不要で使われていなかったと分かった[1]。
  • VPN機器やファイアウォールの保守と脆弱性の管理の役割は曖昧だった。医療情報部が調達していない医療機器、リモート保守の機器、建物の系のシステムは一元管理されていなかった[1][2]。
  • 病院の外部接続の箇所は多く、初動の時点で全部を把握できなかった[1]。
  • 総合情報システムの仕様が拠る厚生労働省のガイドラインは第4.3版のままで、当時の第5.2版に合わせた検証はされていなかった[1]。
  • 報告書は背景に、医療機関は閉域網だから安全という誤った神話で、病院と事業者の両方の意識が薄れたことを挙げる[1]。

どこで止められたか

委託先の入口、委託先の中、病院の境界、病院の中、戻す、の5段それぞれの下に、止める仕組みを置く 1 委託先の口 VPNの鍵が公開 2 委託先の中 病院の鍵を保管 3 病院の境界 RDPを常時許可 4 病院の中 共通の管理者 5 止まる 73日 機器の担当 更新する者を 文書で決める 渡す権限 管理者を渡さず 専用の受け口 接続の台帳 許可の基準と 使われ方の確認 初期設定 台ごとの管理者 標準ユーザー 戻す手段 オフラインの控え ログを先に保全 3が病院の手で閉じられた所。1と2は契約で、4と5は病院の中で持つ
図4 被害が進む5段と、それぞれで止める仕組み
段この件で報告されたこと止める仕組み
1 委託先の口VPN機器の更新は行われず、IDとパスワードの漏えいも確認された[1]機器ごとに管理者と設置者が、保守の範囲と脆弱性の管理の役割を文書で確かめる[1]。多要素認証と接続元の制限[6]
2 委託先の中センターのサーバーが、病院のサーバーの Built-in Administrator の資格情報で毎日ファイルをやり取りしていた[1]相手に渡す資格情報は、受け渡しに要る権限だけの専用のものにする
3 病院の境界不要なRDPを既定の番号で常時許可し、使われ方を確かめなかった[1]外部接続の許可の基準を決め、相手の環境を確かめ、目的と時間と通信のログを確かめる運用[1]
4 病院の中全員が管理者、管理者パスワードが共通、ロックアウト無し、電子カルテのサーバーにウイルス対策無し[1]標準ユーザー、台ごとのパスワード、ロックアウト、全サーバーにウイルス対策[1]
5 止まる重症系の控えはオンラインのみ。端末の多要素認証の仕組みも攻撃を受け、端末の調査ができなかった[1]影響の及ばない控えを数世代。認証の仕組みを含め、戻す順を決めておく[6]

1と2 委託先。自分の網の外にある自分の入口

病院は、給食センターの機器を自分の資産と思っていなかった。E社も、VPN機器を使っている認識が無かった[1]。機器を置いたのはC社で、更新を誰がするかは決まっていなかった[1]。このように、つながる相手の網の中にある機器は、病院の網へ入る入口の1つになる。報告書は、契約ごとに、2省のガイドラインに基づくサービス仕様適合開示書とSLAで責任分界と役割を文書にすることを提案する[1]。

サーバーAが病院のサーバーBの Built-in Administrator で毎日ファイルを渡していたことは、病院の管理者の資格情報を委託先の網に置いていたことになる[1]。相手が入られれば、その資格情報も取られる。受け渡しには、書き込みだけできる専用の受け口と専用のアカウントを用意し、管理者を渡さない。

3 境界。許可した穴を数え、使われ方を見る

病院のファイアウォールYは、閉域の回線の先にいるE社から、RDP、SMB、SQL Server の番号を通していた[1]。開けた理由は事業者の依頼で、閉じる時期も、使われているかの確認も無かった。報告書は、許可の基準を決め、申請があれば通信元の環境を確かめ、許可した後は目的と時間を確かめ、通信のログに他の不正な記録が無いかを確かめる運用を求める[1]。

悪い例。架空の病院の境界の許可。相手の網は 198.51.100.0/24

# 依頼を受けて開けたまま。理由も期限も残っていない
allow tcp 198.51.100.0/24 -> 192.0.2.20 port 3389      # RDP
allow tcp 198.51.100.0/24 -> 192.0.2.20 port 139,445   # SMB
allow tcp 198.51.100.0/24 -> 192.0.2.20 port 1433      # SQL Server

直した例。業務に要る受け渡しだけを、相手の決まった1台から許す

allow tcp 198.51.100.10 -> 192.0.2.30 port 22   # 受け渡し専用の受け口へ SFTP
  # 台帳 EXT-014 給食データの受け渡し 担当 情報企画室
  # 許可の見直し 半年ごと。ログは月ごとに担当が見る
deny  any 198.51.100.0/24 -> any                # それ以外は拒否して記録する

保守のためにRDPが要るなら、常時ではなく、申請のあった時間だけ、多要素認証を通したゲートウェイから開ける。厚生労働省のガイドラインは、リモートメンテナンスについて、管理者の共通アカウントの禁止、端末とIPアドレスでの経路の制限、RDPを直接インターネットに開かないこと、リモートアクセス用のゲートウェイ、ログの定期のレビュー、委託先の管理を求める[6]。

4 中。報告書が挙げた4つの初期設定

報告書は、Windows の初期設定が適切に変えられていれば、大規模に広がることなく防げた可能性が高いと書く[1]。

横展開を許した設定報告書の再発防止策
利用者全員に管理者の権限があり、ウイルス対策を外された利用者は標準ユーザーにし、管理者の名前に administrator のような安直な名を使わず、UACを効かせる[1]
Windows のパスワードがサーバーと端末ですべて共通サーバーと端末ごとにすべて別にする[1]
ロックアウトの設定が無く、総当たりと辞書攻撃でログオンが成功したロックアウトを有効にする[1]
電子カルテのサーバーにウイルス対策が無い電子カルテのサーバーにも入れる[1]

サーバーBはNICを2枚持ち、給食センター側と院内の網の両方に直接つながっていた[1]。網の境界を越える機器は、境界のファイアウォールを素通りする道になる。報告書は、医療情報部の管轄外の機器がこの形で多数つながっていたとも書く[1]。推測による入り込みの止め方は A07 認証の不備、設定の既定値の残り方は A02 セキュリティ設定の不備 の型1にある。

5 戻す。ログを残してから直す

半田病院の件と同じく、事業者が初動で機器を更新し、入口の証拠が消えた[1][3]。更新の案内に従う日常の手順が、事故の中ではそのまま証拠を消す手順になる。事故の手順書には、機器に触る前にログと設定を外へ写すことを、事業者の手順より先に書く。記録と保全は A09 セキュリティログとアラートの不備 にある。

守り方

根本の直し
  • 病院の網につながる機器と外部接続を、医療機器、保守用の機器、委託先の側の機器まで含めてすべて台帳に載せ、重要度で分けてリスクを分析する[1][7]。
  • 契約ごとに、保守、脆弱性の管理、外部接続の責任分界を文書にする。複数の事業者が関わるなら、受ける側の体制と責任者を決めさせる[1]。
  • 外部接続は、許可の基準、相手の環境の確認、目的と期限、使われ方の定期の確認を持つ運用にする[1]。
  • 委託先に病院の管理者の資格情報を渡さない。受け渡しは専用の受け口と専用の権限で行う。
緩和の策
  • 利用者を標準ユーザーにし、管理者パスワードを台ごとに別にし、ロックアウトを有効にする[1]。
  • 電子カルテのサーバーを含め、全サーバーにマルウェア対策を入れる[1]。
  • 保守の接続は、多要素認証、接続元の制限、ゲートウェイを通し、RDPを常時開けない[6]。
  • NICを2枚持つ機器のように境界をまたぐ物を無くすか、境界のファイアウォールの後ろに置き直す[1]。
  • 控えを数世代、影響の及ばない手段で持ち、戻す手順を試す。重症系のように止められない系ほど先に[1][6]。
  • 事故の手順書に、機器に触る前のログの保全を書き、事業者とも共有する[1]。

厚生労働省の令和8年度版のチェックリストは、医療機関に、サーバー、端末、ネットワーク機器の台帳、リモートメンテナンスをしている機器の有無を事業者に確かめること、ネットワーク機器の接続元の制限を求め、事業者の側には、保守の契約の範囲外の項目の責任は医療機関が負うとして、責任分界の認識の違いが無いかを事業者から確かめるよう求める[7]。医療法施行規則14条2項は、病院の管理者にサイバーセキュリティを確保する措置を求める[8]。前年の 半田病院 2021年 と比べると、入口は委託先に移ったが、中の設定の欠けはほぼ同じだった。

参照

  1. 調査報告書 大阪急性期・総合医療センター 情報セキュリティインシデント調査委員会、2023年3月28日
  2. 情報セキュリティインシデント調査報告書 概要 同調査委員会、2023年3月28日
  3. 徳島県つるぎ町立半田病院 コンピュータウイルス感染事案 有識者会議調査報告書 同有識者会議、2022年6月7日
  4. Malicious Actor Discloses FortiGate SSL-VPN Credentials Fortinet PSIRT、2021年9月8日
  5. CVE-2018-13379 NIST NVD
  6. 医療情報システムの安全管理に関するガイドライン 第7.0版 システム運用編 厚生労働省、2026年6月。10.2、11の節
  7. 医療機関・薬局におけるサイバーセキュリティ対策チェックリスト 令和8年度版 厚生労働省、2026年6月
  8. 医療法施行規則 第14条第2項 e-Gov法令検索