OSにはパッチを適用している。アンチウイルスも有効。ファイアウォールにも異常はない。
ここまで確認できれば、「このPCはかなり安全だろう」と感じるのは自然です。
ところがランサムウェア攻撃では、セキュリティ画面に目立った異常が出ないまま侵害が進み、ファイル暗号化に気づいたときには、すでに情報の閲覧や認証情報の取得、別端末への横展開まで進んでいることがあります。
実際に隔離したラボ環境を使い、Windows端末への侵入から情報収集、アクセスの維持、ネットワーク内への横展開、ファイル暗号化までを一連の流れとして検証しました。
検証していて特に印象的だったのは、攻撃が進んでいる最中も、利用者側のPCが驚くほど「普通」に見えることです。
派手な警告画面はありません。ブラウザも動きます。Windows Securityも、一見すると問題がないように見えます。
「普通に使えている」と「安全である」は、同じではありません。
※以下は、隔離された検証環境で実施した教育・セキュリティ検証目的の攻撃シミュレーションです。不正アクセスやマルウェアの作成・実行を推奨するものではありません。
始まりは、たった一つの添付ファイルだった
検証環境には、企業で使用されるPCを想定したWindows端末と、攻撃側のKali Linuxを用意しました。
攻撃側から大量のパスワードを試したり、目立つ通信を延々と送り続けたりするところから始めたわけではありません。
入口となったのは、メールで受け取ったWordファイルを想定したシナリオです。
今回使用したWindows端末では、Windows Security上の各保護機能は有効な状態でした。画面だけを見れば、大きな問題はないように見えます。
しかし、検証用文書を起点として端末上で処理が実行されると、Windows端末側から攻撃側へ通信が発生しました。
ここで知っておきたいのは、攻撃者が外部からPCへ直接接続する形だけが侵入ではないということです。
侵害された端末側から攻撃者のシステムへ通信させ、遠隔からコマンドを実行できる状態を作る方法もあります。こうした接続は「リバースシェル」と呼ばれます。
外部から入ってくる通信だけを意識していると、端末から外へ出ていく不審な通信を見落とすことがあります。
現在のWindows・Office環境では防御も変わっている
今回の検証環境ではWindows 10 Professional 20H2を使用していますが、2026年現在、Windows 10は通常サポートを終了しており、現在の標準的なWindows環境をそのまま表すものではありません。
Office側の防御も変わっています。現在のMicrosoft 365 Appsでは、インターネットから取得したOfficeファイルに含まれるVBAマクロを既定でブロックする仕組みがあります。
そのため、「メール添付のWordファイルを開けば、現在の環境でも必ず同じように感染する」という話ではありません。
それでも、この検証から得られる教訓は変わりません。
一つの防御を突破されたとき、その次の防御が機能するか。
企業のランサムウェア対策では、ここまで考えておく必要があります。
Windows Securityが緑でも、侵害されていないとは限らない
検証中、Windows Securityの画面だけを見ると、ウイルス対策やファイアウォールなどは正常な状態を示していました。
それでも裏側では、Windows端末と攻撃側の間で接続が成立しています。
ここから「Windows Defenderでは守れない」と結論づけるのは正しくありません。
現在のMicrosoft Defenderには、マルウェア検出だけでなく、クラウド保護や振る舞い検知などがあります。企業向けのMicrosoft Defender for Endpointでは、EDRやAttack Surface Reduction（ASR）など、さらに広い防御・検知機能も利用できます。
重要なのは、セキュリティ製品が「有効」と表示されていることと、必要な機能が適切に設定され、監視・運用されていることは別だという点です。
普通にChromeが動いていても、裏では侵害が続いていた
今回の検証で、個人的に一番分かりやすいと感じた場面があります。
侵害後のWindows端末でGoogle Chromeを開いてみると、何事もなかったようにブラウザが起動します。Googleも表示され、普通に検索できます。
利用者から見れば、いつものPCです。
ブラウザは動く。Webサイトも開ける。大きな警告も出ていない。
しかし、その裏では攻撃者側との接続が残っています。
端末が正常に動いていることは、端末が安全である証明にはなりません。
「再起動すれば消える」とも限らない
攻撃者にとって、一度侵入できたからといって、それで十分とは限りません。
PCが再起動した。プロセスが停止した。ユーザーがログアウトした。
それだけでアクセスを失ってしまえば、その後の活動を続けにくくなります。
そこで使われる考え方が「永続化（Persistence）」です。
今回の検証でも、侵入後にアクセス経路を維持する処理を行いました。
企業側で重要なのは、その具体的な実装方法ではありません。
インシデントが発生したとき、
「怪しいプロセスを停止したから終わり」
「一度再起動したから大丈夫」
と判断しないことです。
不審な自動起動設定、追加されたアカウント、タスク、サービスなど、再びアクセスするための変更が残っていないかまで確認する必要があります。
侵入後、攻撃者はいきなり暗号化しない
ランサムウェアという名前から、「感染したらすぐにファイルが暗号化される」と考えがちです。
しかし、実際の攻撃では暗号化より前に価値のある行動があります。
攻撃者にとって侵入した端末は、単なる暗号化対象ではありません。組織内部を調べるための足場でもあります。
侵入後には、たとえば次のような情報が攻撃者にとって重要になります。
- どの端末へ侵入したのか
- どのネットワークに接続されているのか
- ドメイン環境に参加しているか
- どのユーザー権限で動いているか
- 周囲にどのようなシステムが存在するか
- そのユーザーがどの情報へアクセスできるか
ランサムウェア攻撃を「ファイルを暗号化するマルウェア」とだけ考えると、この前段階を見落とします。
本当に怖いのは、暗号化される前に読まれること
検証では、攻撃側からWindows端末のDocumentsフォルダーへアクセスできる状態になりました。
中には契約書、Word文書、銀行口座情報を想定したテストデータなどを置いています。
ランサムウェア被害というと、
「ファイルが暗号化されて開けなくなる」
ことに目が向きます。
しかし、暗号化する前に攻撃者がファイルを閲覧できていたのであれば、すでに情報漏洩が発生している可能性があります。
現在のランサムウェア攻撃では、データを窃取した後にファイルを暗号化し、「支払わなければ盗んだ情報を公開する」と脅す二重恐喝も問題になっています。
つまり、バックアップから復旧できたとしても、外部へ持ち出された情報まで取り戻せるわけではありません。
認証情報を奪われると、1台の感染では終わらない
侵害したWindows端末から認証に関係する情報を取得できれば、そのユーザーが利用できる別システムへ攻撃範囲を広げられる可能性があります。
社員のPCからファイルサーバーへ接続できる。同じアカウントで複数の社内システムへログインできる。端末間で管理用通信が許可されている。
通常業務では便利なこうした「信頼関係」が、端末侵害後には攻撃者の移動経路になることがあります。
今回の検証でも、端末侵害後に認証情報へのアクセス、ネットワーク内のシステム探索、別端末への接続可能性の確認などを行いました。
最初に侵害されたPCが1台でも、そこから取得できる権限によっては被害範囲が大きく変わります。
1台の感染が組織全体へ広がる「横展開」
一つの端末を起点として、ネットワーク内の別システムへ攻撃範囲を広げていく動きを「ラテラルムーブメント（Lateral Movement／横展開）」と呼びます。
今回の検証では、Infection Monkeyを利用して、ネットワーク上でどのシステムへ到達できたのか、どのような経路で通信できたのかも可視化しました。
図を見ると、最初の端末を中心に複数のシステムへ経路が伸びています。一方で、ネットワーク上では確認できても、実際には到達していないシステムも区別できます。
こうして可視化すると、「最初の1台を侵害された後に何が起きるのか」がかなり分かりやすくなります。
検証レポートからは、端末間で利用できるリモート管理機能や、ネットワークセグメンテーションの不足など、横展開につながり得るポイントも確認できます。
セグメンテーションの目的は、
「絶対に侵入されないネットワーク」を作ることではなく、「侵入されても遠くまで行かせない」ことです。
一般社員のPCから重要サーバーへ直接通信する必要があるのか。PC同士で管理用通信を許可する必要があるのか。
平常時の利便性だけでなく、侵害後の動きを想定してネットワークを設計する必要があります。
ランサムウェアは「最後に見える症状」にすぎない
情報収集、ファイルへのアクセス、認証情報の取得、周辺システムの探索、横展開。
こうした工程の後で、ファイル暗号化が始まります。
被害者が最初に異変へ気づくのは、この段階かもしれません。
ファイルが開けない。見慣れないファイルが増えている。デスクトップやフォルダー内に身代金要求を示す文書が置かれている。
今回使用した検証用ランサムウェアでは、暗号化後にREADME形式のメッセージも表示させています。
メッセージには「pizza and beerを送ってほしい」というジョークを入れていますが、実際のランサムウェアでは、暗号資産による支払い、期限、データ公開の脅迫、攻撃者との連絡手段などが記載される場合があります。
ここまで来て、ようやく利用者から見ても「何かがおかしい」と分かります。
しかし、攻撃者側から見ると暗号化はかなり後半です。
ランサムノートが表示された瞬間が、攻撃の始まりとは限りません。
暗号化されたPCだけを初期化して終わりにするのではなく、いつ侵入されたのか、情報を持ち出されていないか、認証情報が漏れていないか、別端末へ横展開していないかまで確認する必要があります。
メールを「利用者に届く前」に止める
今回の攻撃シナリオでは、メール添付ファイルが最初の入口でした。
そこで重要になるのが、「社員が怪しいファイルを見破れるか」だけに頼らないことです。
メールセキュリティ製品には、添付ファイルやURLを検査したり、疑わしいファイルを隔離環境で実行して挙動を確認するサンドボックス機能を備えたものがあります。
文書を開いた直後に不審なプロセスを起動したり、通常とは考えにくい外部通信を始めたりすれば、利用者へ届く前に検知できる可能性があります。
社員が開くかどうかを、最後の防波堤にしない。
これも多層防御の考え方です。
アンチウイルスだけでは足りない理由
現在のアンチウイルスは、単純に既知のマルウェアファイルだけを探しているわけではありません。それでも、単一の機能ですべての攻撃を止めることはできません。
企業環境では、
- Officeアプリから通常とは異なるプロセスが起動した
- 不審なスクリプトが実行された
- 普段見ない宛先への通信が発生した
- 認証情報へ不自然なアクセスがあった
- 一つの端末から複数端末への接続が急増した
といった一連の振る舞いを見ることが重要になります。
EDR（Endpoint Detection and Response）は、こうした端末上の挙動を継続的に収集し、検知・調査・対応につなげるための仕組みです。
ただ、EDRも導入するだけでは十分ではありません。
アラートが出たら誰が確認するのか。夜間や休日はどう対応するのか。侵害端末を誰が隔離するのか。
運用まで決まって初めて、防御として機能します。
「バックアップがある」だけでは安心できない
ランサムウェア対策としてバックアップは非常に重要です。
ただし、侵害された端末から常時書き換え・削除できるバックアップでは、一緒に暗号化されたり削除されたりする可能性があります。
企業では、少なくとも次の点を確認しておきたいところです。
- 本番環境から適切に分離されているか
- バックアップ用の認証情報を分離しているか
- 攻撃者から削除・変更されにくい仕組みになっているか
- オフラインまたは変更不能なコピーが存在するか
- 実際に復元テストを行っているか
バックアップで重要なのは、単に「取れていること」ではありません。
侵害後に本当に業務を戻せることです。
現在の企業環境なら、どこで攻撃を止めるべきか
今回の流れを見ると、一つの製品だけですべてを止めようとすることが難しい理由が分かります。
| 攻撃段階 | 主な防御策 |
|---|---|
| メール受信 | メールフィルタリング、添付ファイル検査、サンドボックス |
| Office文書の実行 | インターネット由来マクロのブロック、ASR |
| 不審なプロセス実行 | EDR、アプリケーション制御 |
| 外部への通信 | DNS・Webフィルタリング、プロキシ監視、Network Protection |
| 認証情報の悪用 | 最小権限、管理者権限の分離、認証基盤の保護 |
| 横展開 | ネットワークセグメンテーション、端末間通信の制御 |
| ファイル暗号化 | EDR、Controlled Folder Accessなど |
| 復旧 | オフライン／変更不能なバックアップ、復元テスト |
メールで止められなくても、実行時に止める。
実行されても、不審な通信や振る舞いで検知する。
そこを突破されても、認証情報を守る。
認証情報を奪われても、横展開させない。
暗号化まで進んでも、確実に復旧できる状態を作る。
この考え方が多層防御です。
企業で見直したいランサムウェア対策
OSとソフトウェアをサポート対象に保つ
パッチ適用は基本です。
同時に、サポートが終了したOSやソフトウェアを残さないことも重要です。
Windows 10を現在も利用している企業では、延長セキュリティ更新の適用状況やWindows 11への移行計画を含め、利用環境を確認する必要があります。
Officeマクロやスクリプトの実行範囲を絞る
業務上マクロが必要な部署があるとしても、全社員が自由に実行できる必要はありません。
インターネット由来のファイルに対する保護が例外設定などで弱められていないかも確認します。
メールフィルタリングとサンドボックスを活用する
危険な添付ファイルやURLを利用者へ届く前に検査します。
社員の注意力だけではなく、入口でも攻撃を落とせる仕組みを作ります。
EDRを導入し、アラート対応まで決める
EDRの導入状況だけでなく、端末が正しく監視対象になっているか、誰がアラートを見るのか、侵害時にどう隔離するのかまで確認します。
「製品は入っているけれど、誰もアラートを見ていない」という状態では十分な効果を期待できません。
端末同士の通信を必要以上に許可しない
一般社員のPCから重要サーバーへ、本当に直接通信する必要があるでしょうか。
PC同士の管理用通信も含め、侵害後の横展開を想定してネットワークを見直します。
アカウントへ必要以上の権限を与えない
一つの認証情報を奪われた場合、そのアカウントでどこまで到達できるのかを確認します。
最小権限を徹底すれば、侵入そのものを止められなかった場合でも、被害範囲を小さくできます。
バックアップを攻撃者からも守る
オフライン化、変更不能化、認証情報の分離などを組み合わせます。
そして定期的に復元テストを行い、「バックアップファイルがある」ではなく「業務を復旧できる」ことを確認します。
社員が「いつもと違う」に気づける環境を作る
技術対策ですべての不審メールを100％止めることは困難です。
外部から届いたOffice文書、不自然な認証画面、突然のQRコード、見慣れないファイル共有などに遭遇したとき、
「これは一度確認した方がよさそうだ」
と判断できる社員を増やすことも重要です。
ただし、セキュリティ教育は「だまされた社員を責めるため」に行うものではありません。
迷ったときにすぐ相談できる窓口と、報告しやすいルールまでセットにすることが大切です。
「侵入された後」を一度試しておく
セキュリティ製品の導入一覧を眺めるだけでは、本当に攻撃を止められるかは分かりません。
想定する攻撃経路に対して、
- どこで検知できるのか
- どこで遮断できるのか
- 横展開はどこまで可能なのか
- 認証情報を取得されたらどこまで影響するのか
- 侵害が起きたとき誰が気づけるのか
を実際に確認することが重要です。
ペネトレーションテストやRed Team演習が有効なのも、この部分です。
設定上は問題がなく見えても、攻撃者の視点で一つずつ経路をつないでいくと、思わぬところから重要システムまで到達できることがあります。
「パッチを当てた」はゴールではなくスタート地点
今回の検証を通して改めて感じるのは、
端末が正常に見えることと、安全であることは同じではない
ということです。
パッチ適用は必要です。アンチウイルスも必要です。ファイアウォールも必要です。
ただ、それぞれは防御の一層にすぎません。
今回も、入口は一つのファイルでした。
そこから端末へのアクセスが生まれ、利用者には普通に見える状態のまま情報を確認でき、認証情報を起点として周囲へ影響が広がり、最後に暗号化という目に見える被害へ到達しました。
一つの防御が失敗したとしても、その次で止められる。
次も突破されたとしても、さらにその次で被害を限定できる。
その積み重ねが、現実的なランサムウェア対策です。
「パッチを当てているから大丈夫か」ではなく、
「一つ突破されたとき、次の防御は本当に機能するか」
一度そこまで確認してみると、自社のセキュリティで本当に見直すべき場所が見えやすくなります。
投稿者プロフィール
-
Offensive Security Engineer
15年以上の実績を持つ国際的なホワイトハッカーで、日本を拠点に活動しています。「レッドチーム」分野に精通し、脆弱性診断や模擬攻撃の設計を多数手がけてきました。現在はCyberCrewの主要メンバーとして、サイバー攻撃の対応やセキュリティ教育を通じ、企業の安全なIT環境構築を支援しています。
主な保有資格：
● Certified Red Team Specialist（CyberWarFare Labs / EC-Council）
● CEH Master（EC-Council）
● OffSec Penetration Tester（Offensive Security）
