NetScalerはなぜ狙われ続けるのか 1年余りで悪用8件、VPN機器の守り方

NetScaler ADCとNetScaler Gatewayで、また悪用中の脆弱性が見つかりました。JPCERT/CCは2026年9月28日に注意喚起を出し、10月2日には侵害の調査に役立つ情報を追記しています。対象の版や確かめる点はNetScalerの注意喚起の更新を伝えたニュースにまとめました。この記事では、なぜこの機器が狙われ続けるのか、更新だけでは終わらない理由と、情シスが平時から整えておきたい守り方を深掘りします。

今回わかっていること

Cloud Software Groupは2026年9月27日、NetScaler ADCとNetScaler Gatewayの脆弱性8件を公表しました。JPCERT/CCによると、このうちCVE-2026-88771とCVE-2026-88772は、認証されていない遠隔の攻撃者に任意のコードを実行されるおそれがあり、すでに悪用が確認されています。回避策は提供されておらず、修正済みの版への更新が求められています。IPAも同じ日に、早急なアップデートを呼びかけました。

調査したMandiantとGoogle Threat Intelligence Group(GTIG)は、CVE-2026-88772を突く攻撃が少なくとも9月上旬から続いていたとしています。影響を受けたとみられるのは、北米と欧州の政府、金融、IT、教育、法律などの組織です。国内では、海外のセキュリティ組織の観測で9月24日以降に日本のNetScalerへの攻撃の試みが確認されています。ただしJPCERT/CCは、それが今回の脆弱性を狙ったものかは分かっていないとしています。

1年余りで、悪用済みの一覧に8件

米国のCISA(サイバーセキュリティ・インフラストラクチャ安全保障庁)は、実際に悪用された脆弱性を一覧(KEV)にして公開しています。米国の連邦政府機関は、ここに載った脆弱性を期限までに直すことが求められます。この一覧でNetScalerを調べると、2025年6月からの1年余りで8件が載っていました。

今回の2件は、公表と同じ9月27日に一覧に載り、連邦政府機関の対応期限は3日後の9月30日でした。9月だけで3件が載ったことになります。1度更新して終わりではなく、次の脆弱性がいつ来てもすぐ動ける体制が要る機器だといえます。

なぜVPN機器が狙われるのか

NetScaler Gatewayは、社外から社内のシステムに入るための入口(VPNやリモートアクセスの玄関)として使われます。インターネットに直接つながっているうえ、ここを乗っ取れば社内への通り道ができます。

Mandiantの報告では、攻撃者は機器を乗っ取ったあと、Pythonで書かれた中継の道具(SLAPSHOT)を置き、社内のネットワークへ通信を通していました。少なくとも1件では、その通り道を使って社内を調べ、認証情報を盗んでいたといいます。

見つけにくさもあります。Mandiantは、暗号化の通信はこの機器で解かれるため、手前のネットワーク機器では中身を見られないと指摘しています。さらに、調査に要るログの一部は、初期の設定では外に送られません。機器の中だけにログがあると、消されたり上書きされたりすれば追えなくなります。

攻撃の流れ

Mandiantの報告から、CVE-2026-88772を使った攻撃の流れを追うと次のとおりです。

1. 入口: 暗号化の通信を始めるやり取り(DTLS、UDPの443番)に細工したデータを送り、通信を処理する部分(NSPPE)を異常終了させて、最も強い権限(root)を得る
2. 裏口の設置: Webサーバーの設定ファイル(/etc/httpd.conf)を書き換え、画像や配布用のファイルに見せかけた名前のファイルを、プログラムとして動かせるようにする。そこにWebシェル(遠隔から命令を送るためのプログラム。WHIPSHOTなど)を置く
3. 権限の維持: /bin/shにSUIDという設定をして、Webサーバーからの命令もrootで動くようにする
4. 社内への通り道: SLAPSHOTで社内のネットワークへ通信を中継し、調査と認証情報の窃取を行う
5. 痕跡の消去: 定期実行の設定から自分の場所を消すなど、痕跡を隠す

Webシェルは、見つからないように「ページが見つかりません(404)」と返しながら命令を受け付ける作りだったといいます。アクセスのログでは、404なのに処理に時間がかかり、返したデータが数キロバイトもある、という不自然な記録として残ることがあります。

更新だけでは終わらない理由

修正済みの版にすれば、入口の脆弱性はふさがります。しかし、更新の前に入り込まれていた場合、攻撃者が置いたWebシェルや書き換えた設定は残ります。JPCERT/CCも、対策の適用とあわせて侵害の有無を調べるよう求めています。

Mandiantは、侵害が疑われるときの手順として、次のことを挙げています。

• 機器をネットワークから切り離す
• 2台で冗長にしている場合は、設定の同期を止め、1台ずつ調べる(乗っ取られた側の書き換えが、もう1台に写らないように)
• 機器から外への通信を絞る
• 仮想の機器なら、再起動の前にメモリも含めたスナップショットを残す
• 管理者や接続中の利用者のセッションを無効にする
• 機器の管理者のパスワード、SSHの鍵、TLSの証明書と秘密鍵を入れ替える
• 機器が使っている連携の認証情報(LDAPの接続用アカウント、RADIUSの共有の秘密、SNMP、APIの資格情報など)を入れ替える
• 機器がつながっている社内のサーバー(Citrixの関連サーバーなど)のログで、不審なログインや横への移動の跡を調べる

認証情報の入れ替えは、更新が済んでから行うよう注意しています。更新の前に替えても、同じ入口からまた盗まれるおそれがあるためです。

情シスがやること

いますぐ

• 機器の台帳で、NetScaler ADCとGatewayの有無と稼働している版を確かめる
• 14.1系は14.1-73.37以降、13.1系は13.1-64.23以降に更新する(FIPS版は個別の版)
• すぐに更新できないときは、DTLSが要らなければ無効にし、インターネット側のファイアウォールでUDPの443番を止める。ただし、これはCVE-2026-88772への対策で、CVE-2026-88771には効かない
• Mandiantの手順に沿って侵害の調査をする(設定ファイル、Webシェルの置き場所、ログ、/tmp/.uxdportなどの不審なファイル、/bin/shのSUID、不審なPythonの処理)

平時から整えておくこと

Mandiantは、機器の管理の面でも次の制限を勧めています。

• 管理用の画面(NSIP)や管理のための通信を、インターネットに出さない。管理は決めたネットワークや踏み台からだけにする
• 機器から外への通信は、原則すべて止め、DNSや時刻合わせなど必要な先だけ許す
• 機器のログ(ns.log、/var/log/messages、Webサーバーのログ)をSIEMなどの外の保管先に送る。/var/log/messagesは通常のログの転送には含まれない

あわせて、社内の決まりとして次のことを決めておくと、次の脆弱性が出たときに迷いません。

• インターネットに出ている機器(VPN、ファイアウォール、リモートアクセス)を台帳にまとめ、更新の担当と連絡先を書いておく
• 悪用済みの脆弱性が出たら、何日以内に更新するかを決めておく
• 侵害が疑われたときの連絡先と、隔離の判断をする人を決めておく

境界の機器の台帳は、次のテンプレをそのまま使えます。

保守を外部に任せている場合

NetScalerの運用を販売店や保守会社に任せている会社では、「更新をお願いした」だけで止まりがちです。次の点を文書でもらうと、社内に説明しやすくなります。

• 稼働している版と、修正済みの版にした日時
• 侵害の調査をしたか、その範囲と結果
• 管理画面がインターネットに出ていないか、外への通信を絞っているか
• ログをどこに、どれだけの期間残しているか

委託先への確認は、次のチェックシートが使えます。

侵害が見つかった、または疑いがあるときは、経緯と対応を記録に残しておきます。