大阪公立大学：仮想化基盤にランサムウェア、約500台のサーバーが停止し、バックアップの多くも暗号化。

大学が明らかにした内容

大阪公立大学は、大阪府内に5つのキャンパスを持つ公立大学です。2022年に大阪市立大学と大阪府立大学が統合して発足しました。

システムの障害は2026年10月2日（金）午前0時30分頃に始まりました。OMUエントランスページ。大学は同日に2回お知らせを出し、10月5日（月）の記者会見で原因を説明しました。

10月2日の2回のお知らせの内容です。

範囲。 全キャンパスで情報基盤システム全般が停止しました。ネットワーク、学内メール、ポータルサイト、教務系システムなどです。第1報。
発覚の経緯。 ベンダーからの連絡で把握しました。システム担当部署と運用委託事業者が調査していました。
動いていたもの。 医学部附属病院と獣医臨床センターのシステムには影響がありませんでした。Web出願サイトと入学手続サイトは学外のサーバーで運用しているため、利用を続けられました。第2報。
授業。 10月8日（木）まで全授業を休講とし、10月9日（金）以降に対面授業を再開する予定です。オンライン授業の再開は復旧状況を見て判断します。

10月5日の記者会見の内容です（MBS、共同通信、時事通信の報道による）。

原因。 大学はランサムウェアによるサイバー攻撃を受けたと判断しました。MBS。
侵入された場所。 大学の情報システムが使う仮想化基盤に侵入され、約500台のサーバーがすべて停止しました。共同通信によると、一部のデータが改ざんされた形跡も確認されています。共同通信。
バックアップ。 バックアップデータの多くが暗号化され、使えない状態です。復旧のめどは立っていません。
個人情報。 システムには在学生や卒業生ら少なくとも13万人の情報が保管されていました。氏名、住所、メールアドレス、携帯電話番号（MBS）、学生証の写真（共同通信）です。外部に流出したかどうかは調査中です。時事通信。
どこまで遡るか。 13万人には統合前の2大学の学生も含まれます。大阪市立大学は1995年以降、大阪府立大学は2005年以降です（MBS）。
報告。 大阪府警と文部科学省に報告し、10月5日には個人情報保護委員会にも連絡しました（共同通信）。
身代金。 身代金の要求の有無については、調査中のためコメントできないとしています。朝日新聞。

時系列。10月2日（金）午前0時30分頃、全5キャンパスでシステムが停止。大学はベンダーからの連絡で把握。14時、第1報：情報基盤システム全般が停止、原因は調査中、附属病院は影響なし。18時、第2報：10月8日まで休講、学外サーバーの出願サイトは利用可能。基盤と切り離した臨時お知らせサイトで情報発信。10月5日（月）16時の記者会見：仮想化基盤へのランサムウェア、約500台のサーバーが停止、バックアップの多くが暗号化、少なくとも13万人分の情報について調査中、警察と関係機関に報告。10月9日：対面授業の再開予定。10月22日：出願・入学手続の延長後の期限。

図1. 障害発生からランサムウェアの判明まで4日。オリジナルの図。

大学は、攻撃者、ランサムウェアの種類、仮想化基盤の製品、侵入経路を明らかにしていません。公式ウェブサイトは停止したままで、情報は臨時お知らせサイト（omu.moe）で発信されています。大学のエントランスページもこのサイトにリンクしています。MBSによると、このサイトは障害を受けた基盤システムとは切り離して運用されています。

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

1つの基盤、1つの被害範囲

編集部の評価。 約500台のサーバーが一斉に止まったのは、1つの仮想化基盤を共有していたからです。メール、ポータル、教務系システム、学生の記録が、同じホストの上で仮想マシンとして動いていました。仮想化基盤の管理層を握った攻撃者は、サーバーに1台ずつ侵入する必要がありません。下の層から仮想マシンを止めたり、暗号化したりできます。

守るべきなのは、1台ずつのサーバーではなく管理層です。次の4点を確認してください。

管理者IDを分ける。 ハイパーバイザーとその管理サーバーを操作するアカウントを、通常のディレクトリアカウントにしない。できれば、侵入者が最も握りやすいディレクトリに依存させない。
多要素認証と管理ネットワーク。 管理画面には、分離された管理ネットワーク上の専用端末からのみ到達できるようにする。学内や社内の一般ネットワークからは到達させない。
基盤のパッチを優先する。 ハイパーバイザーは、保守のたびに上の全サーバーが止まるため、パッチ適用が後回しになりがちです。だからこそ先に当てるべきです。
管理層を監視する。 サインイン、権限の変更、一斉の電源停止、データストアの変更を記録し、基盤の管理者自身が消せない場所に送る。

攻撃者が届いたバックアップ

編集部の評価。 暗号化されたサーバーは作り直せます。数日で終わる障害を数週間に延ばすのは、バックアップまで暗号化されたときです。大阪公立大学のバックアップデータの多くが暗号化されたのであれば、少なくともその部分のバックアップは、侵害された環境から到達でき、書き込めたことになります。

どの組織でも確認すべきことです。

本番側から変更できないコピーを少なくとも1つ。 オフライン、または本番の管理者が短縮できない保持ロック付きのイミュータブルストレージ。
認証情報を分ける。 バックアップの管理画面が、本番と同じディレクトリや管理者アカウントを信頼しないようにする。
復元テストで時間を測る。 成功したかどうかだけでなく、「仮想化基盤そのものを戻すのに何時間、500台のサーバーを戻すのに何日か」を測る。この事案は、その問いに最悪の形で答えています。
対象範囲を確認する。 ファイル共有だけでなく、認証、メール、学籍などのシステムが含まれているか。

障害を共有しない連絡手段

大学は当日14時に第1報を出しました。学外でホストされている出願サイトと入学手続サイトは動き続けました。基盤システムから切り離した臨時お知らせサイトで、学生、教職員、附属病院、報道向けの情報を発信しました。

編集部の評価。 この部分は機能しており、参考にする価値があります。メインの基盤と何も共有しないステータスページと連絡手段を用意しておくことです。ホスティング、DNSの管理、管理者アカウントをすべて別にします。学内メールが止まったときに誰が投稿するかも、事前に決めておきます。

代替手段は隙にもなる

学内メールが使えないため、大学は経済支援制度を申請する学生に、Gmailなどの個人メールアドレスで登録するよう案内しました。経済支援制度のお知らせ。現実的な判断です。一方で学生は、連絡先が漏れた恐れのある状況で、いつもと違う経路から公式の依頼が届くことに慣れてしまいます。

編集部の評価。 大学の名をかたるフィッシングを想定してください。「アカウントの再登録」「奨学金の確認」「障害後のパスワード再設定」といった内容です。大学がどの経路で連絡し、何を決して求めないかを、学生と卒業生に伝えてください。メールが復旧したら、公式アドレスに戻すよう案内してください。

31年分の記録

流出の恐れがあるデータは、統合前の大学の一方では1995年まで遡ります。何十年も前に卒業した人も13万人に含まれます。

編集部の評価。 統合した組織は、古いシステムと古い記録を引き継ぎます。目的を終えた後も残している記録は、それを保管するシステムが侵害されたとき、報告すべき記録が1件増えることを意味します。保存期間のルールは、在籍者だけでなく卒業生や退職者も対象にすべきです。

どのチームが確認するか

チーム	実務上の次の対応
IT運用	ハイパーバイザーとバックアップの管理を、多要素認証付きの別の管理者アカウントに移し、分離した管理ネットワークからのみ到達できるようにする。イミュータブルまたはオフラインのバックアップが1つ以上あることを確認し、全体の復元にかかる時間を測る。
SIEM / SOC	ハイパーバイザー、管理サーバー、バックアップ管理画面のログを、それぞれの管理者が変更できない保存先に送る。管理者権限の追加、一斉の電源停止、バックアップジョブの削除、保持期間の変更でアラートを出す。下のハンティングを実行する。
EDR	Windowsサーバーで復元ポイントやバックアップを改ざんする操作がアラートになり、ホストを隔離できることを確認する。ハイパーバイザーには通常EDRエージェントが入らないため、管理層のログで補う。
法務・プライバシー	卒業生と退職者の記録の保存期間を確認する。共同研究や学生の受け入れなどで大学とデータを共有している場合、自社のどのデータが影響を受けたシステムにあったかを確認する。
メールセキュリティ	大阪公立大学の名前、今回の障害、代替の連絡手段を利用したフィッシングを想定する。社員に同大学の在学生や卒業生がいれば注意を促す。
委託先リスク	インフラ運用を委託している場合、ハイパーバイザーとバックアップの管理者認証情報を誰が持ち、どう守り、悪用されたら誰が気付くかを確認する。大阪公立大学はベンダーからの連絡で事案を把握しました。

IOCとハンティング

公開されたIOCはありません。 大学はランサムウェアの種類や攻撃者を明らかにしておらず、ハッシュ、ファイル名、IPアドレス、ドメインも公表していません。推測で補うべきではありません。この記事は、大阪公立大学を特定のグループや製品と結び付けるものではありません。

以下のハンティングは、ランサムウェアの事案で大規模な暗号化の前によく見られる挙動を、自組織の環境で探すものです。いずれも参考例であり、実環境では実行していません。テーブル名とフィールド名は2026年10月5日にMicrosoft LearnとSplunkの資料で確認しました。

1. Windowsの復元ポイントとバックアップカタログの削除。 Microsoft Defender XDRの高度なハンティングで、DeviceProcessEvents（Defender for Endpoint）を使います。バックアップソフトや管理者が正当に実行するコマンドも含まれます。アカウント、親プロセス、計画された変更かどうかを確認してください。

// Illustrative; not run against live data. Microsoft Defender XDR advanced hunting.
// Commands that delete shadow copies or backup catalogues, or disable Windows recovery.
DeviceProcessEvents
| where Timestamp > ago(7d)
| where (FileName =~ "vssadmin.exe" and ProcessCommandLine has "delete" and ProcessCommandLine has "shadows")
    or (FileName =~ "wmic.exe" and ProcessCommandLine has "shadowcopy" and ProcessCommandLine has "delete")
    or (FileName =~ "wbadmin.exe" and ProcessCommandLine has "delete")
    or (FileName =~ "bcdedit.exe" and ProcessCommandLine has "recoveryenabled")
    or (FileName in~ ("powershell.exe", "pwsh.exe") and ProcessCommandLine contains "Win32_ShadowCopy")
| project Timestamp, DeviceName, AccountDomain, AccountName, FileName, ProcessCommandLine,
    InitiatingProcessFileName, InitiatingProcessCommandLine
| order by Timestamp desc
| take 200

2. 同じ確認をSplunkで。 Splunk Add-on for Sysmonで収集したSysmonのプロセス作成イベント（イベントID 1）を使います。フィールドはImage、CommandLine、ParentImage、User、Computerです。インデックス名は置き換えてください。

index="REPLACE_WITH_WINDOWS_INDEX" source="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=1 earliest=-7d latest=now
| eval image=lower(mvindex(split(Image, "\\"), -1)), cmd=lower(CommandLine)
| where (image="vssadmin.exe" AND like(cmd, "%delete%shadows%"))
    OR (image="wmic.exe" AND like(cmd, "%shadowcopy%delete%"))
    OR (image="wbadmin.exe" AND like(cmd, "%delete%"))
    OR (image="bcdedit.exe" AND like(cmd, "%recoveryenabled%"))
    OR (image IN ("powershell.exe", "pwsh.exe") AND like(cmd, "%win32_shadowcopy%"))
| table _time Computer User ParentImage Image CommandLine
| sort 0 - _time
| head 200

3. ハイパーバイザーの管理者権限を与えるディレクトリグループ。 Active Directoryに参加したVMware ESXiホストを運用している場合のみ該当します。大阪公立大学は仮想化基盤の製品を明らかにしていません。Microsoftは2024年、パッチ未適用のドメイン参加ESXiホストが「ESX Admins」という名前のドメイングループに完全な管理者権限を与えるため、ランサムウェア攻撃者がこのグループを作成していたと報告しました（CVE-2024-37085）。Microsoft Securityブログ。Broadcomのアドバイザリは既定のグループ名を「ESXi Admins」としているため、クエリでは両方を確認します。Microsoft SentinelのSecurityEventテーブルを使い、ドメインコントローラーのセキュリティログ（グループ管理の監査を有効化）が収集されていることが前提です。

// Illustrative; not run against live data. Microsoft Sentinel, SecurityEvent (domain controller Security log).
// Creation of, or membership changes to, a group that ESXi may treat as administrators.
SecurityEvent
| where TimeGenerated > ago(30d)
| where EventID in (4727, 4728, 4731, 4732, 4737, 4754, 4755, 4756)
| where TargetUserName in~ ("ESX Admins", "ESXi Admins")
| project TimeGenerated, Computer, EventID, Activity, SubjectAccount, MemberName, TargetUserName
| order by TimeGenerated desc
| take 100

このグループが存在し、意図して作成したものでなければ、インシデントとして扱ってください。運用で使っている場合は、ホストにパッチを適用し、メンバーを確認してください。これ以上に有用な証拠は、ハイパーバイザーの管理ログそのものにあります。SIEMに転送している組織は多くありません。まず埋めるべきなのはその穴です。

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

ヒットは手がかりであり、証拠ではありません。アカウントの持ち主と変更記録で確認してください。
該当なしでも安全とは言えません。ログの欠落、保持期間切れ、攻撃者による削除がありえます。
これらのクエリでは、ハイパーバイザーやバックアップ装置の内部は見えません。それぞれの製品のログを使ってください。
DeviceProcessEvents、SecurityEvent。

分かっていないこと

侵入経路と、10月2日より前にどれだけの期間、内部にいたか。
どの仮想化製品とバックアップ製品が関係し、なぜ一部のバックアップが無事で、ほかが暗号化されたのか。
データが持ち出されたか。 13万人という数字はシステムが保管していた情報であり、流出が確認された数ではありません。
身代金の要求や犯行声明があるか。
共同通信が報じた**「改ざんされた形跡」**が何を指すか。
復旧にかかる期間。 見通しは示されていません。
附属病院のシステムが影響を受けなかった理由。 大学は構成を説明していません。

出典と更新履歴

すべての出典は2026年10月5日、日本時間19時30分頃までに確認しました。この時点で、大学は10月5日の記者会見の内容を臨時お知らせサイトに文書で掲載していませんでした。記者会見の内容は、上記の報道によります。この記事のきっかけはHackRisk.ioの要約ですが、事実の出典としては使っていません。大学が自ら発表や調査結果を公表した場合、この記事を更新します。現時点で訂正はありません。