1.攻撃について
(1)攻撃の流れ
一般的な流れは以下
(2)ネットワーク経由でPCに侵入できるの？
| Q.そもそもPCって、ローカルログオンしかできないんじゃないの？RDPが有効になっているの？なぜ、他のPCが侵入できるのか。 |
A.「ローカルログオンのみ許可」の設定でも、C$（管理共有）が開いていて、管理者権限が奪われると、不正侵入されます。「ローカル管理者アカウント（Administratorなど）」のパスワードが、簡単なものだったり、みんな同じだったりすることがよくあるのです。
また、乗っ取りたいPCのフォルダに遠隔操作ツールをコピーし、「サービスコントロールマネージャー（SCM）」や「WMI」といったWindowsの管理機能をネットワーク越しに叩きます。
(3)ラテラルムーブメントって、どのポートが多いの？
企業環境では、以下のポートに対するインバウンド（受信）通信がFWで意図的に許可されていることがよくあります。
| 用途 | ポート | 補足 |
|---|---|---|
| ファイルとプリンターの共有 (SMB) | TCP/445 | たまに空いている。なぜかというと、プリンタでスキャンをする場合、それをPCに取り込むことがあるが、プリンタ→PCへの通信なので、空いている |
| Windows Management Instrumentation (WMI) | TCP/135 および 動的ポート | SKYSEA、LanScope、あるいはMicrosoftのSCCM（MECM）といった統合管理ツールを導入する際、空いている場合がある。Intuneは問題ない。PC側からクラウド（Microsoftのサーバー）に対しするアウトバウンド通信（HTTPS/443番）であるため |
| RDP | TCP/3389 | GUIベースでの横展開。意図的に空けてRDPをONにしないと接続不可 |
| SSH | TCP/22 | Linuxサーバーやネットワーク機器（ルータ、スイッチ）への横展開で使用。意図的にSSHサービスを有効にしないと接続不可 |
| Kerberos (認証) | TCP/UDP/88 | Active Directory環境において、「Pass-the-Ticket」や「ゴールデンチケット（ドメイン全体の万能鍵偽造）」といった高度な攻撃を行う際に、ドメインコントローラとの通信で発生します。PCはそもそも88番ポートは開いてないので、PCへの横展開への攻撃ではない |
※ただし、対象PCのFW設定において、上記のような管理用ポート（TCP/445やTCP/135など）のインバウンド通信がすべて厳格にブロックされていれば、攻撃者はネットワーク越しにC$を開くことも、WMIを叩くこともできないため、このネットワーク経由の手法は失敗します。
(3)認証情報の漏洩
どうやって漏洩する？
1)フィッシング
→ 偽サイト等により、利用者が認証情報を入力してしまう
2)利用者PCのマルウェア感染
→ キーロガーや情報窃取型マルウェアにより認証情報が取得される
3)他システムで漏洩した認証情報の使い回し
→ パスワードの使い回しにより、別経路で漏洩したIDが悪用される
これらの漏洩した情報は、ブラックマーケットに送られる。以下のニュースに「160億件以上のログイン認証情報」とあるように、認証情報が闇で蓄積されている。
【参考URL】https://news.yahoo.co.jp/articles/301d83ae61b352a823182842fe908bffe791ade2
「160億件以上のログイン認証情報が流出していたことを6月19日に発表」「過去最大規模のデータ漏洩の一つ」「流出した情報には、URL、ログインID、パスワード、セッショントークン、クッキー、メタデータなどが含まれており」「インフォスティーラーマルウェア（ログイン情報や機密データを盗むことに特化したマルウェア）の急速な蔓延に強い懸念」
| ■参考：IAB このブラックマーケットにおける認証情報の売買で暗躍しているのが、IAB（Initial Access Broker：初期アクセスブローカー）と呼ばれるサイバー犯罪者である。IABとは、企業や組織のネットワークへ侵入するための「初期アクセス権（VPNやRDPの認証情報、バックドアの接続権など）」を専門に取得し、それをランサムウェア攻撃者などの他の犯罪グループに販売する仲介業者 |
(4)EDR等の無効化
| Q.そんなことはできるのか |
A.攻撃者は認証情報を取得してログインするので、管理者権限が付与されていれば可能です。また、管理者権限付与されていない場合、権限昇格してOFFにしたのでしょう。
| Q.そのような行為をしたら、EDRで検知するのではないか。 |
A.正規のユーザでログインした行為とみなされます。なので、EDRでは、無効化までの動作を検知はしなさそうです。一方、権限昇格などの動作は、動作によっては検知可能だと思います。
| Q.端末内でEDRが無効化されたことをアラートで送ることはできないのか。 |
A.可能です。CrowdstrikeなどのEDRの場合、EDRを無効したりアンインストールすると、管理コンソールにて検知できるようになっています。Widndows Defenderでもおそらくできます。※ちなみに、Defenderの削除はできないが、無効化はできる。
| Q.じゃあなぜ気づけない？ |
A.いくつかの理由があると思います。
・そのような機能がないEDRであった
・アラートが多いので、アラートを見逃してしまった
・そもそも監視していなかった
また、無効にはするけど、マルウェア等で、管理コンソールにはそれらしき応答をするようにし、検知機能だけをOFFにする攻撃者もあるようです。やっかいですね。
| ■参考：BYOVD（Bring Your Own Vulnerable Driver）攻撃 攻撃者が「正規の署名済みだが脆弱性を持つドライバ」を標的端末に持ち込み、カーネルレベルで悪用する手法。これにより、EDRの無効化や特権プロセスの操作を試みます。CrowdStrike社の場合、「Falcon BYOVD protections」という機能が実装されているため、検知、防御ができる仕組みを実装しております。 ←機能を実装しているということは、そういう攻撃を受ける可能性があるということでしょう。 https://www.crowdstrike.com/en-us/blog/falcon-prevents-vulnerable-driver-attacks-real-world-intrusion/ |
(5)バックアップの削除
攻撃者はバックアップデータを削除したり、バックアップの機能を無効化したり停止したりします。なぜなら、被害者企業にバックアップデータがあったら、脅しが効かなくなるからです。
2.被害状況について
2.1 JIPDECの調査報告
(1)概要
・「『企業IT利活用動向調査2026』から見る 日本企業のDX、AI活用、ランサムウェア被害の実態」
（出典：https://www.jipdec.or.jp/archives/publications/h2le1c000000bkzt-att/ITresarch2026report.pdf）
・以下は引用
| ランサムウェアの感染割合は45.8%と約2社に 1社がランサムウェアの被害を経験しており、ランサムウェアが企業にとって極めて現実的な脅威とな っていることが示されている。身代金の支払い状況を見ると、感染被害にあった企業のうち身代金を支払った割合は20.1%、支払わ なかった割合は25.7%となっている。注目されるのは復旧の成否であり、身代金を支払っても復旧に成功した割合は20.2%にとどまる一方、復旧に失敗した割合は25.6%に上っている。 |
(2)データ化
❶ランサムウェア感染被害の全体状況
| 項目 | 社数 | 割合 |
|---|---|---|
| 被害に遭った（感染した） | 507社 | 45.8% |
| 被害に遭わなかった等 | 600社 | 54.2% |
❷感染企業における「身代金」の支払い状況
| 項目 | 社数 | 割合（感染企業ベース） |
|---|---|---|
| 支払った | 222社 | 43.8% |
| 支払わなかった | 285社 | 56.2% |
❸感染企業における「データ・システム」の復旧状況
| 項目 | 社数 | 割合（感染企業ベース） |
|---|---|---|
| 復旧に成功した | 224社 | 44.2% |
| 復旧に失敗した | 283社 | 55.8% |
❹支払い有無別の復旧成否（クロス集計）
■ 身代金を支払った企業（222社）
| 項目 | 社数 | 割合 |
|---|---|---|
| 復旧に成功した | 83社 | 37.4% |
| 復旧に失敗した | 139社 | 62.6% |
■ 身代金を支払わなかった企業（285社）
| 項目 | 社数 | 割合 |
|---|---|---|
| 復旧に成功した | 141社 | 49.5% |
| 復旧に失敗した | 144社 | 50.5% |
❺考察（憶測で、正当な根拠はありません）
・「支払った企業（成功率37.4%）」よりも「支払わなかった企業（成功率49.5%）」の方が復旧率が高くなっています。これは「支払う行為」自体が復旧を阻害したのではなく、両者の「被害に遭う前の備え」（バックアップがあったなど）や「企業体質の違い」が影響していると考えられます。
・「身代金を払ったのに復旧できない」ケースの裏側には、単に「攻撃者にだまされた」以外にも、企業側のスキル不足・体制不足で、攻撃者から「復号するための鍵（ツール）」が送られてきても、復旧できなかったこともある可能性（あくまでも可能性）があると思います。
3.対策
(1)PCでの対策
・OSおよびソフトウェアの最新パッチ適用
・EDRの導入
・管理者権限を抜く
・許可されたアプリケーションしかインストールしない
たとえば、攻撃者は Honeygain のような「帯域幅共有ツール（プロキシウェア）」を悪用し、被害者のPCを踏み台として利用します。
https://blog.talosintelligence.com/proxyware-abuse/
・PowerShell等のスクリプト実行制限
一般ユーザーがPowerShellやWSH（Windows Script Host）を不用意に実行できないようにポリシーで制限します。
・可能であれば、業務で不要な機能は使えないようにする。たとえば、業務で不要な場合はRDP機能を無効化します。
(4)ID/パスワードが漏洩しないようにするためにすること
① システムを設計・提案する立場での対策
・パスワードに依存しない認証方式を採用（二要素認証（MFA）など）
・外部接続が必要な場合は入口を制限する→ 保守用途などは送信元IPアドレス制限を行う。
② 利用者（個人）の立場での対策
・ID／パスワードを使い回さない
・フィッシングサイトへの入力をしないように注意する
・ OS・ブラウザ・セキュリティ対策ソフトを最新に保つ。
・（最近では推奨されていませんが、）PWをたまには変える。※少なくとも、漏洩したと思われる場合はすぐに変える
