JadeProxとは？偽Claude・DLLサイドローディングの攻撃手法とIPS・EDRによる対策

JadeProxとは何か――偽Claude、DLLサイドローディング、政府・病院侵害の攻撃手法とIPS・EDRによる防ぎ方

はじめに

2026年7月24日、中国との関連が疑われる新たなサイバー攻撃クラスタ「JadeProx」が、病院、政府機関、教育機関などを標的にしていたと報じられました。

JadeProxは単一のマルウェア名ではありません。

攻撃者が使用するインフラ、フィッシングサイト、侵入後ツール、独自ローダーなどをまとめて追跡するために、セキュリティ企業Group-IBが付けたクラスタ名です。

この攻撃では、次のような複数の侵入方法が確認されています。

公開サーバーの脆弱性をNucleiで大量スキャンする
Java Management Extensions（JMX）などの管理機能を悪用する
LNK、VBS、MSIを組み合わせた標的型メールを送る
偽のClaudeダウンロードサイトからマルウェアを配布する
正規署名付きEXEに悪意のあるDLLを読み込ませる
Webシェルやトンネリングツールで内部ネットワークへ侵入する

Group-IBは2026年7月23日、Alibaba Cloud上で公開されたままになっていた攻撃者の作業用サーバーを調査し、ベトナムの公立病院、マレーシア外務省、香港の教育機関などを狙った活動を確認しました。財経新聞の記事は、このGroup-IBの調査を基にしています。

本記事では、JadeProxの攻撃方法を分かりやすく整理し、Cloudflare、Nginx、IPS、EDR、サーバー監視でどのように防ぐべきかを解説します。

JadeProxとは

JadeProxは、中国との関連が疑われているサイバー攻撃クラスタです。

ただし、現時点で中国政府や特定のAPTグループとの直接的な関係が証明されたわけではありません。

Group-IBは、次の特徴から「China-nexus」、つまり中国系の攻撃エコシステムと関連する可能性が高いと評価しています。

中国系APTで多用されるツールを使用
Alibaba CloudやAlibaba OSSを利用
中国語のMSIインストーラーを使用
中国系攻撃グループと重なるDLLサイドローディング
政府、外交、医療、教育機関を中心に標的化
iox、fscan、suo5、Neo-reGeorgなどを使用

一方で、複数の中国系攻撃グループでツールやインフラが共有される場合があるため、Group-IBは既存APTへ無理に帰属させず、独立したクラスタとしてJadeProxを追跡しています。

JadeProxの攻撃全体像

JadeProxの攻撃経路は、大きく3種類に分けられます。

【公開サーバーへの攻撃】

Nucleiによる大量スキャン
        ↓
脆弱なJavaアプリや管理画面を発見
        ↓
JMXなどの公開管理機能を悪用
        ↓
Webシェルを設置
        ↓
suo5・iox・Neo-reGeorgでトンネル作成
        ↓
内部サーバーやPACSへ侵入


【標的型メール】

ZIP添付
  ↓
LNKファイル
  ↓
VBSスクリプト
  ↓
正規署名付きEXE
  ↓
悪意のあるDLLをサイドロード
  ↓
TriBack Loader
  ↓
AdaptixC2


【偽Claudeサイト】

検索広告・検索結果
        ↓
偽Claudeサイト
        ↓
Claude-Pro-windows-x64.zip
        ↓
Claude.msi
        ↓
Windowsスタートアップへ配置
        ↓
正規EXE＋悪性DLL＋暗号化DAT
        ↓
TriBack Loader／DonutLoader
        ↓
Beagleバックドア

偽Claudeサイトから感染する仕組み

JadeProxとの関連が確認された攻撃では、正規のClaudeを装った偽サイトが使用されました。

偽サイトでは、約505MBの次のファイルが配布されていました。

Claude-Pro-windows-x64.zip

ZIP内にはClaude.msiが含まれており、実行するとWindowsのスタートアップフォルダへ次の3ファイルを配置します。

NOVupdate.exe
NOVupdate.exe.dat
avk.dll

NOVupdate.exe自体は、G DATA製品で使用されていた正規署名付きの実行ファイルです。

しかし、同じフォルダに攻撃者が作成した偽のavk.dllを置くことで、正規EXEに悪意のあるDLLを読み込ませます。これは「DLLサイドローディング」と呼ばれる攻撃です。

暗号化されたNOVupdate.exe.datはDLLによって復号され、DonutLoaderを経由してBeagleバックドアがメモリ上で実行されます。Beagleは、コマンド実行、ファイル送受信、ディレクトリ操作、自身の削除などを行えます。

DLLサイドローディングが危険な理由

通常のウイルス対策では、デジタル署名のあるEXEを信頼する傾向があります。

しかし、DLLサイドローディングでは、EXE本体は本物です。

正規署名付きEXE
        │
        ├─ 本物なので単体では安全に見える
        │
        ▼
同じフォルダのDLLを読み込む
        │
        ▼
悪意のあるDLLが実行される

つまり、次の判断は危険です。

デジタル署名が正常
    ＝
そのプロセスの動作も安全

MITRE ATT&CKでは、DLLサイドローディングをT1574.001として整理しています。攻撃者は正規アプリケーションと悪性DLLを同じ場所に置くことで、信頼されたプロセスの内部でマルウェアを実行します。暗号化された追加ペイロードと組み合わせることで、静的解析やファイル単体の検査も回避しやすくなります。

JadeProxで確認されたサーバー攻撃

JadeProxは、Windows端末だけを狙う攻撃ではありません。

Group-IBの調査では、攻撃者は香港の教育機関に関連する14,653件のURLをNucleiへ投入し、Critical判定の脆弱性を持つシステムを大量探索していました。

ベトナムの公立病院では、インターネットからアクセスできるJava Management Extensionsの経路を悪用し、Webシェルとsuo5を使って医療画像管理システムであるPACSへ接続していました。

また、マレーシア外務省に対しては、Neo-reGeorgやリバースシェルを使った侵入が試みられていました。

このことから、JadeProx対策では次の両方が必要です。

端末対策
＋
公開サーバー対策

JadeProxを防ぐための基本方針

JadeProx対策は、IOCのIPアドレスやドメインを遮断するだけでは不十分です。

攻撃者はドメインやIPを変更できますが、次の行動パターンは残ります。

脆弱性スキャン
管理ポートへの接続
Webシェル作成
トンネル確立
LNK・VBS・MSI実行
スタートアップフォルダへの配置
正規EXEから不審DLLをロード
普段通信しないプロセスから外部へ接続

したがって、次の多層防御が必要です。

Internet
   │
   ▼
Cloudflare WAF
   │
   ▼
Nginx
   │
   ▼
Django・Java・公開アプリ
   │
   ├─ IPS／NDR
   ├─ EDR
   ├─ DNS監視
   ├─ ファイル改ざん監視
   └─ SOC相関分析

優先度別の推奨対策

P0：直ちに実施する対策

公開IOCをDNS、Firewall、IPSへ登録する
JMX、RMI、管理画面をインターネットへ公開しない
スタートアップフォルダを全端末で調査する
LNK、VBS、MSIを含むメール添付を制限する
公開Javaアプリケーションを緊急点検する
Webシェルとトンネリングツールを探索する
サーバーから外部への不要な通信を制限する

P1：短期間で実施する対策

Cloudflare WAFで管理画面を許可リスト化する
Nginxで秘密ファイル探索を即時遮断する
Nucleiなどのスキャナをレート制限する
SysmonでDLLロードとファイル作成を記録する
ASRルールを監査モードで展開する
正規署名付きEXEの実行場所を監視する

P2：継続的に実施する対策

App Control for BusinessやWDACを導入する
IPS、EDR、DNS、WAFログを相関分析する
ファイル名ではなく攻撃チェーン全体で判定する
IOCを定期的に更新する
攻撃シミュレーションを行い、検知漏れを確認する

Cloudflare WAFの推奨設定

1. 管理画面を許可IPだけに制限する

Django管理画面を公開している場合は、社内IP、VPN、SASE出口IPなどだけに限定します。

CloudflareのIPリストをadmin_allowed_ipsとして作成した場合の例です。

(not ip.src in $admin_allowed_ips
 and http.request.uri.path wildcard "/admin/*")

推奨アクション：

Block

Cloudflareは、IPリストに含まれない接続元だけを管理画面で遮断するカスタムルールを公式に案内しています。

可能であれば、IP制限だけでなくCloudflare Access、SASE、ZTNA、VPNなどの認証レイヤーを追加してください。

2. 秘密ファイル探索を遮断する

次のようなパスへのアクセスは通常発生しません。

/.env
/.git/
/.svn/
/.hg/
/backup.zip
/database.sql
/db.sql

Cloudflareカスタムルール例：

(http.request.uri.path contains "/.git"
 or http.request.uri.path contains "/.env"
 or http.request.uri.path contains "/.svn"
 or http.request.uri.path contains "/.hg")

推奨アクション：

Block

バックアップファイルについては、正規配布ファイルを誤遮断しないように対象パスを限定します。

3. 自動スキャナを段階的に制限する

低信頼度のスキャナ検知例です。

(not cf.client.bot and
 (
   http.user_agent contains "Nuclei"
   or http.user_agent contains "fscan"
   or http.user_agent contains "python-requests"
   or http.user_agent contains "Go-http-client"
 ))

最初から全面遮断すると、正規APIクライアント、監視ツール、開発者のcurlなどを誤検知する可能性があります。

初期アクションは次の順番が安全です。

Managed Challenge
        ↓
ログ確認
        ↓
対象パスを限定
        ↓
悪性と確認したものだけBlock

User-Agentは簡単に偽装できるため、単独でCritical判定してはいけません。

4. ログイン画面へレート制限を設定する

例：

対象:
/account/login/

条件:
POSTリクエスト

基準:
1IP当たり5回／60秒

超過時:
Managed Challengeまたは10分間Block

CloudflareのRate Limiting Rulesは、URIや接続元などの条件を使い、指定回数を超えたリクエストを遮断できます。ただし、利用可能な条件やカウント方法は契約プランによって異なります。

5. オリジンサーバーへの直接接続を遮断する

Cloudflareを導入していても、VPSの実IPが知られていると、攻撃者はCloudflareを通さず直接Nginxへ接続できます。

したがって、オリジンサーバーでは次を実施します。

80番・443番はCloudflareの送信元IPだけ許可
管理用SSHはWireGuardや許可IPだけ許可
Authenticated Origin Pullsを有効化
不要な8000、8080、8443、1099番などを閉じる
Cloudflareを通さないDNSレコードを作らない

Cloudflareも、オリジン側でCloudflareのIPアドレスだけを許可し、それ以外を明示的に遮断する構成を推奨しています。また、Authenticated Origin Pullsを使うことで、Cloudflareネットワークから来た接続かを証明できます。

Nginxの推奨設定

1. Cloudflare経由でも実IPを正しく取得する

Cloudflare配下で$remote_addrをそのまま使用すると、CloudflareのIPを利用者IPとして扱ってしまう場合があります。

set_real_ip_fromには、Cloudflare公式の最新IPレンジを登録します。

real_ip_header CF-Connecting-IP;
real_ip_recursive on;

# set_real_ip_fromにはCloudflare公式の
# 最新IPv4・IPv6レンジを登録する

これを行わずにレート制限すると、多数の利用者が同じCloudflare IPとして集計され、まとめて遮断される危険があります。

2. 秘密情報探索を444で切断する

location ~* ^/(?:\.env(?:\..*)?|\.git(?:/|$)|\.svn(?:/|$)|\.hg(?:/|$)) {
    access_log /var/log/nginx/security_drop.log;
    return 444;
}

location ~* ^/(?:backup|backups|dump|database|db)(?:[-_.][^/]*)?\.(?:sql|tar|gz|zip|7z)$ {
    access_log /var/log/nginx/security_drop.log;
    return 444;
}

444はNginx独自のレスポンスで、HTTP応答を返さず接続を終了します。

ただし、正規のZIP配布やバックアップダウンロード機能がある場合は、全拡張子を一律遮断せず、パスやファイル名を限定してください。

3. 認証画面へレート制限を設定する

httpブロック内：

limit_req_zone $binary_remote_addr
    zone=login_per_ip:10m
    rate=10r/m;

limit_req_zone $binary_remote_addr
    zone=general_per_ip:20m
    rate=10r/s;

ログイン画面：

location = /account/login/ {
    limit_req zone=login_per_ip burst=5 nodelay;
    limit_req_status 429;

    proxy_pass http://django_backend;
}

一般画面：

location / {
    limit_req zone=general_per_ip burst=20 nodelay;

    proxy_pass http://django_backend;
}

Nginxのlimit_reqは、指定したキーごとのリクエスト速度をleaky bucket方式で制御します。burstを超えたリクエストは拒否されます。初回導入時はlimit_req_dry_run on;を使い、実際には遮断せずログだけを確認すると安全です。

4. スキャナUser-Agentは専用レート制限にする

map $http_user_agent $scanner_key {
    default             "";
    ~*nuclei            $binary_remote_addr;
    ~*fscan             $binary_remote_addr;
    ~*python-requests   $binary_remote_addr;
    ~*go-http-client    $binary_remote_addr;
}

limit_req_zone $scanner_key
    zone=scanner_limit:10m
    rate=2r/s;

serverまたは対象location内：

limit_req zone=scanner_limit burst=5 nodelay;

mapのデフォルトを空文字にすると、通常利用者はこの専用制限の対象外になります。

ただし、User-Agentは偽装できるため、これは補助ルールです。

Suricata IPSの推奨ルール

以下はJadeProxの公開IOCを利用した防御用ルール例です。

IPSインラインモードではdrop、監視だけを行うIDSモードではalertへ変更します。

1. IOCのIPアドレスを遮断する

drop ip $HOME_NET any -> [43.106.71.28,8.217.190.58] any (msg:"JADEPROX outbound connection to known IOC IP"; classtype:trojan-activity; sid:9902001; rev:1;)

2. IOCドメインへのDNS問い合わせを遮断する

drop dns $HOME_NET any -> any 53 (msg:"JADEPROX DNS query to known IOC domain"; dns.query; pcre:"/(^|\.)(sylverixstrategy\.com|gouvvbo\.top|claude-pro\.com|vertextrust-advisors\.com|update-trellix\.com|update-crowdstrike\.com|update-sentinelone\.com|dlrz-web\.oss-cn-beijing\.aliyuncs\.com)$/i"; classtype:trojan-activity; sid:9902002; rev:1;)

3. TLSのSNIを検査する

drop tls $HOME_NET any -> $EXTERNAL_NET any (msg:"JADEPROX TLS SNI to known IOC domain"; flow:established,to_server; tls.sni; pcre:"/(^|\.)(sylverixstrategy\.com|gouvvbo\.top|claude-pro\.com|vertextrust-advisors\.com|update-trellix\.com|update-crowdstrike\.com|update-sentinelone\.com)$/i"; classtype:trojan-activity; sid:9902003; rev:1;)

4. 平文HTTPのHostを検査する

drop http $HOME_NET any -> $EXTERNAL_NET any (msg:"JADEPROX HTTP Host to known IOC domain"; flow:established,to_server; http.host; pcre:"/(^|\.)(sylverixstrategy\.com|gouvvbo\.top|claude-pro\.com|vertextrust-advisors\.com|update-trellix\.com|update-crowdstrike\.com|update-sentinelone\.com)$/i"; classtype:trojan-activity; sid:9902004; rev:1;)

公開IOCには、43.106.71[.]28、8.217.190[.]58、claude-pro[.]com、セキュリティ製品の更新サイトを装う複数のドメインなどが含まれます。

Suricataルールを本番投入する前の確認

sudo suricata -T \
  -c /etc/suricata/suricata.yaml \
  -S /etc/suricata/rules/jadeprox.rules

正常に読み込めることを確認してから再起動します。

sudo systemctl restart suricata
sudo systemctl status suricata

最初は次の順番で導入します。

alert
  ↓
ログと誤検知を確認
  ↓
特定IOCだけdrop
  ↓
挙動検知ルールを追加

Suricataのthresholdはアラート量を制御できますが、IPSのdropやrejectはしきい値に関係なく各パケットへ適用されます。「thresholdを付けたから指定回数までは遮断されない」と誤解しないよう注意が必要です。

IOCが増えた場合は、ルールへ直接追加するのではなくSuricataのDataset機能を利用すると管理しやすくなります。Datasetではドメインやサブドメインを外部リストとして読み込ませることができます。

Windows EDRの推奨設定

1. Microsoft Defender ASRルール

JadeProx対策として優先度が高いASRルールは次のとおりです。

ルール	GUID	推奨初期設定
メール・Webメールからの実行可能コンテンツをブロック	`be9ba2d9-53ea-4cdc-84e5-9b1eeee46550`	Audit
難読化されたスクリプトをブロック	`5beb7efe-fd9a-4556-801d-275e5ffc04cc`	Audit
JS・VBSによるダウンロード済み実行ファイル起動をブロック	`d3e037e1-3eb8-44c8-a917-57927947596d`	Audit
信頼性・経過時間などを満たさないEXEをブロック	`01443614-cd74-433a-b99e-2ecdc07bfc25`	Audit
Officeによる子プロセス作成をブロック	`d4f940ab-401b-4efc-aadc-ad5f3c50688a`	Audit
Officeによる実行可能ファイル作成をブロック	`3b576869-a4ec-4529-8536-b80a7769e899`	Audit

これらのルールは、JadeProxで使用されたZIP、LNK、VBS、MSI、暗号化ペイロードの実行経路を直接または間接的に抑制します。Microsoftは各ASRルールのGUIDと、対象となるスクリプト・メール・実行ファイルの挙動を公開しています。

ローカル検証用のPowerShell例：

$ruleIds = @(
    "be9ba2d9-53ea-4cdc-84e5-9b1eeee46550",
    "5beb7efe-fd9a-4556-801d-275e5ffc04cc",
    "d3e037e1-3eb8-44c8-a917-57927947596d",
    "01443614-cd74-433a-b99e-2ecdc07bfc25",
    "d4f940ab-401b-4efc-aadc-ad5f3c50688a",
    "3b576869-a4ec-4529-8536-b80a7769e899"
)

$actions = @(
    "AuditMode",
    "AuditMode",
    "AuditMode",
    "AuditMode",
    "AuditMode",
    "AuditMode"
)

Add-MpPreference `
    -AttackSurfaceReductionRules_Ids $ruleIds `
    -AttackSurfaceReductionRules_Actions $actions

Microsoftも、最初に監査モードで動作と影響を確認してから有効化する手順を案内しています。

本番環境では、ローカル設定ではなくIntune、グループポリシー、Microsoft Defender for Endpointなどで一元管理してください。

2. Sysmonで監視するイベント

最低限、次のSysmonイベントを収集します。

Event ID	内容	JadeProxで見るポイント
1	Process Create	VBS、MSI、署名付きEXEの起動
3	Network Connection	普段通信しないEXEから外部接続
7	Image Load	不審なDLLの読み込み
11	File Create	Startup、Temp、AppDataへの作成
13	Registry Value Set	Runキーなどの永続化

Microsoftは、File Createでユーザー書き込み可能領域に作成された実行ファイルを、Image Loadで未署名または想定外のDLLを確認するよう案内しています。

3. 最重要のEDR相関ルール

単独のファイル名だけではなく、次の条件を組み合わせます。

条件1:
Startup、AppData、Tempなどへ
EXE・DLL・DAT・LOGが作成された

AND

条件2:
同じディレクトリに
正規署名付きEXEとDLLが存在する

AND

条件3:
そのEXEがDLLをロードした

AND

条件4:
直後に外部通信が発生した

上記すべてが成立した場合：

Severity: Critical
自動隔離: 有効
プロセス停止: 有効
ネットワーク遮断: 有効

次のファイル名は、特に確認優先度を上げます。

NOVUpdate.exe
NOVUpdate.exe.dat
avk.dll
hostfxr.dll
MpClient.dll
Claude.msi
Claude.vbs
~del.vbs.bat

ただし、hostfxr.dllやMpClient.dllは正規環境でも存在する可能性があります。

ファイル名だけで削除せず、次を確認してください。

配置場所
ハッシュ
デジタル署名
親プロセス
同時に作成されたファイル
外部通信先
実行ユーザー
初回確認時刻

4. App Control for Business／WDAC

より強い対策として、ユーザー書き込み可能な次の場所からEXEやDLLを実行できないようにします。

Downloads
Desktop
AppData
Temp
Windows Startup
メール添付展開先

ただし、パス単位の許可ルールを広く作りすぎると、そのフォルダへ攻撃者が置いたファイルまで許可してしまいます。

MicrosoftのApp Control for Businessは、実行時にそのパスが管理者だけ書き込み可能かを確認する仕組みを備えています。ユーザー書き込み可能なパスを安易に許可しないことが重要です。

Linux・公開サーバーの推奨対策

1. JMXや管理ポートを公開しない

次のポートや管理機能は、インターネットへ直接公開しないことが基本です。

JMX / RMI
1099
Java管理コンソール
デバッグポート
Docker API
Redis
PostgreSQL
MySQL
Elasticsearch
Prometheus管理系
Grafana管理画面

JMXは、localhost、内部ネットワーク、WireGuard、SASE、ZTNAなどからのみ接続できるようにします。

Internet
   ×
   │
   │ 接続禁止
   ▼
JMX

管理端末
   │
WireGuard／ZTNA
   │
   ▼
JMX

2. 不審ツールを検索する

sudo find /tmp /var/tmp /dev/shm /opt /usr/local/bin \
  -type f \
  \( \
    -iname '*suo5*' \
    -o -iname 'iox' \
    -o -iname 'fscan' \
    -o -iname 'neoreg.py' \
    -o -iname 'socks5-server' \
    -o -iname 'linux_amd64' \
  \) \
  -ls

待受ポート確認：

sudo ss -lntup
sudo lsof -nP -iTCP -sTCP:LISTEN

最近作成された実行ファイル：

sudo find /tmp /var/tmp /dev/shm \
  -type f \
  -mtime -7 \
  -executable \
  -ls

Webルートの最近の変更：

sudo find /var/www \
  -type f \
  -mtime -7 \
  -printf '%TY-%Tm-%Td %TH:%TM:%TS %u %g %m %p\n'

ファイル名が一致しただけで侵害と断定してはいけません。正規の検証ツールとして導入されている可能性もあるため、ハッシュ、実行履歴、所有者、外部通信を確認します。

3. Webシェル対策

Webサーバーユーザーにアプリコードを書き換えさせない
アップロードフォルダではスクリプトを実行させない
コンテナイメージを読み取り専用にする
Webルートへファイル改ざん監視を導入する
www-dataやnginxユーザーからのシェル起動を検知する
Webプロセスからcurl、wget、bash、shが起動されたら警告する
一時領域からの実行を監視する

Djangoでアップロードファイルを扱う場合は、アップロード先を静的配信専用にし、Python、PHP、JSP、CGIなどとして実行されない構成にします。

4. 外向き通信を制限する

侵害後のC2通信やトンネル確立を防ぐため、サーバーからインターネットへの通信を必要最小限に制限します。

許可:
OS更新
Dockerレジストリ
DNS
NTP
必要な外部API
監視・バックアップ先

原則拒否:
任意IPへのTCP 443
任意IPへのUDP 8080
不明なSOCKS通信
未申請の外部SSH

すべての443番通信を許可すると、攻撃者は通常のHTTPSに紛れてC2通信を行えます。

メールゲートウェイの推奨設定

次の添付ファイルを重点的に制限します。

.lnk
.vbs
.js
.jse
.wsf
.hta
.msi
.scr
.iso
.img

ZIP内も展開検査し、次の組み合わせを高リスクと判定します。

ZIP
 ├─ LNK
 ├─ VBS
 ├─ MSI
 ├─ おとりPDF
 └─ 正規EXE＋DLL＋DAT

二重拡張子も検知します。

invoice.pdf.lnk
document.docx.exe
~del.vbs.bat

Group-IBは、_CL_######形式の入れ子フォルダ、~del.vbs.bat、スタートアップフォルダ内の正規EXE・DLL・暗号化ファイルの組み合わせを探索するよう推奨しています。

SOC・IPSでの推奨スコアリング

Low

NucleiなどのUser-Agentを1回確認
.envや.gitへ単発アクセス
存在しない管理画面への単発アクセス

対応：

記録のみ

Medium

1IPから複数の秘密ファイルを探索
多数の異なるポートを短時間に調査
Java管理画面やJMX関連パスへ接続
User-Agentとスキャン挙動が一致

対応：

Managed Challenge
レート制限
SOCアラート

High

Webプロセスからシェルが起動
/tmpや/dev/shmから不審バイナリを実行
スタートアップへEXE・DLL・DATが同時作成
署名付きEXEがユーザー書き込み可能領域から起動
正規EXEが同一フォルダの不審DLLをロード

対応：

自動隔離候補
担当者へ即時通知
関連端末・IPの調査

Critical

JadeProx IOCへ通信
Webシェル経由でトンネル確立
内部DB、PACS、管理ネットワークへ横展開
スタートアップ永続化とC2通信が同時成立
suo5、iox、Neo-reGeorgなどの実行と外部接続が成立

対応：

通信遮断
端末隔離
プロセス停止
認証情報失効
インシデント宣言

IPS運用で重要な設定

IPSでは、状態を次のように分けて管理します。

detect_only
    検知のみ

block_candidate
    遮断候補

waf_enforced
    CloudflareやWAFでは遮断済み

sensor_ack_pending
    センサーへの反映確認待ち

active_block
    IPSまたはFirewallで実遮断中

expired
    IOC期限切れ

false_positive
    誤検知確認済み

特に、

WAFで遮断済み

と

IPSセンサーへ反映済み

は同じ状態ではありません。

ダッシュボード上で分離しないと、実際にはセンサー未反映なのに「防御済み」と誤認する危険があります。

IOCルールには次の項目を持たせます。

IOC値
種別
情報源
初回確認日
最終確認日
有効期限
信頼度
対応アクション
対象センサー
反映状態
誤検知除外

感染が疑われる場合の初動

1. ネットワークから隔離する

LANケーブルを抜くだけではなく、EDRまたはスイッチ側で隔離します。

2. 電源をすぐに切らない

メモリ上だけで動作しているペイロードや通信情報が失われる可能性があります。

3. 証拠を保全する

メモリ
プロセス一覧
ネットワーク接続
DNSキャッシュ
Startupフォルダ
Temp、AppData
Windowsイベントログ
Sysmonログ
EDRタイムライン
メール原本
ダウンロード元URL

4. IOCを全社検索する

IP
ドメイン
ハッシュ
ファイル名
フォルダ名
証明書
親子プロセス

5. 永続化を確認する

Startup
Runキー
Scheduled Task
サービス
WMI永続化
DLLサイドローディング
Webシェル
cron
systemd

6. 認証情報を変更する

感染端末だけでなく、その端末から利用したVPN、クラウド、管理画面、SSH鍵なども対象にします。

7. 初期侵入経路を修正する

マルウェアだけ削除しても、脆弱なJMXやWebアプリが残っていれば再侵入されます。

まとめ

JadeProxの危険性は、単に「偽Claudeから感染する」という点だけではありません。

この攻撃クラスタは、次の異なる侵入経路を並行して使用しています。

脆弱性スキャン
標的型メール
偽ソフトウェア
Webシェル
トンネリング
DLLサイドローディング

防御側がIOCだけに依存すると、攻撃者がIPやドメインを変更した時点で検知できなくなります。

そのため、次の多層防御が必要です。

Cloudflare
    公開面のスキャンと管理画面を防御

Nginx
    秘密ファイル探索と大量アクセスを遮断

IPS
    IOC通信、DNS、TLS、HTTPを遮断

EDR
    DLLロード、スタートアップ、スクリプト実行を検知

App Control
    ユーザー領域からの不正実行を防止

SOC
    複数ログを攻撃チェーンとして相関分析

最も重要なのは、正規署名付きEXEを無条件に信用しないことです。

正規EXE
＋
不審DLL
＋
暗号化DAT・LOG
＋
ユーザー書き込み可能フォルダ
＋
外部通信

この組み合わせを高優先度で検知することで、JadeProxだけでなく、PlugX、ShadowPadなど類似のDLLサイドローディング型攻撃にも対応できます。

FAQ

JadeProxは中国政府の攻撃組織ですか？

現時点では断定できません。中国系APTで使われるツール、インフラ、標的傾向との重なりから、Group-IBは中国との関連が疑われるクラスタと評価しています。

ウイルス対策ソフトだけで防げますか？

不十分です。正規署名付きEXE、暗号化ファイル、メモリ実行、コールバックAPIなどを使用するため、ファイル単体の検査だけでなく、EDR、IPS、DNS監視、アプリケーション制御が必要です。

公開IOCを遮断すれば安全ですか？

IOC遮断は必要ですが、それだけでは不十分です。ドメインやIPは変更されるため、DLLサイドローディング、スタートアップ永続化、Webシェル、トンネル、異常な外部通信などの挙動も検知する必要があります。

出典・最終確認（2026年7月31日）

Group-IBのJadeProx技術報告

名称、感染チェーン、活動主体の評価は公開時点のGroup-IB調査に基づきます。帰属は新しい証拠によって変わり得る分析結果です。

Group-IB JadeProx技術報告