NetScalerの2件を実攻撃、更新後も侵害痕跡の確認が必要

|著者: QUASA編集チーム|2 分で読めます
NetScalerの2件を実攻撃、更新後も侵害痕跡の確認が必要

Citrixは2026年9月27日のNetScaler向け勧告で、顧客管理のNetScaler ADCとNetScaler Gatewayにある脆弱性2件、CVE-2026-88771とCVE-2026-88772が未対策環境で悪用されたと公表した。通常版の修正版は14.1-73.37と13.1-64.23以降だ。更新は今後の悪用を防ぐために必要だが、更新前に侵入された装置の改変や認証情報の露出は、別途調べる必要がある。

9月29日公表のGoogleとMandiantの技術分析は、CVE-2026-88772を使う攻撃で認証前にroot権限が奪われ、PHP Webシェル「WHIPSHOT」とPython製トンネル「SLAPSHOT」が使われたと記している。活動は少なくとも9月上旬から続き、北米と欧州の政府、金融、技術、教育、法律・専門サービス分野の組織に影響した可能性がある。日本国内の被害状況は示されていないが、同じ条件の装置では稼働ビルドと侵害痕跡を確認する必要がある。

影響するビルドとDTLSの条件

最初に分けるべきなのは、製品のビルドと脆弱性ごとの構成条件だ。通常版の14.1系は14.1-73.37より前、13.1系は13.1-64.23より前が影響を受ける。NetScaler ADCのFIPS版は14.1-73.37 FIPS、13.1系のFIPS版とNDcPP版は13.1.37.279以降への更新が指定されている。Secure Private Access Hybridで顧客が管理するNetScalerインスタンスも対象に含まれる。

CVE-2026-88771は入力検証の不備により、認証されていない攻撃者が遠隔からコマンドを実行できる問題で、追加機能を有効にしていない標準構成も対象となる。一方、CVE-2026-88772はメモリ処理の問題で、DTLSが有効な仮想サーバーが条件だ。VPN仮想サーバーではDTLSが既定で有効になるため、設定に明示的な無効化がないGatewayを対象外と判断してはいけない。ほかの仮想サーバーも、DTLS型として構成されていれば確認が必要になる。

対象の確定には、資産台帳の製品名だけでなく、稼働中の各ノードのビルドと仮想サーバー設定を照合する。高可用性構成では待機系も個別に確認する。CERT-EUの注意喚起は、影響を受ける顧客管理装置の更新に加え、インターネットに公開された対象ビルドについて侵害調査を勧めている。

観測された攻撃が装置に残すもの

侵入後の挙動が詳しく公開されているのは、主にCVE-2026-88772を使った活動だ。攻撃は認証前のDTLSハンドシェイクでNetScaler Packet Processing Engine（NSPPE）を異常終了させ、基盤OSのroot権限に到達する。細工されたDTLSレコードによるメモリ破損が推定されているが、攻撃コード自体は入手されておらず、その細部は観測データからの分析である。

侵入後にはWebサーバーの設定ファイルが変更され、通常はスクリプトとして実行されない拡張子のファイルをPHPとして処理できるようにされた。観測された手法には、パッケージを装う.debファイルを実行させるものと、画像の.icoへの要求を.sigのWebシェルへ振り向けるものがある。これなら攻撃者は、VPN用クライアントファイルや画像に見える経路から、装置に置いたコードを呼び出せる。

WHIPSHOTはHTTPヘッダーに分割した通信内容を隠し、装置内で動くSLAPSHOTへ渡す。SLAPSHOTは装置から内部ホストへのTCP通信を中継し、観測された侵入の少なくとも一例では、内部の探索と認証情報の窃取に使われた。攻撃者がWebシェルからroot権限で動作を続けられるよう、/bin/shに不審なSUID権限を付けた例もある。こうしたファイルや設定の変更は、脆弱なビルドを更新しただけでは侵害の有無を判定できない理由になる。

資産確認、保全、更新の順序

対応は更新を急ぎつつ、更新前の侵入を調べられる記録を可能な範囲で残す順序で進める。再起動で失われる情報があり、侵害後のログには削除や改変が加えられている可能性もある。装置内の記録と、既に外部へ送られた記録を区別して扱うことが重要だ。

  1. 外部に公開されたNetScaler ADCとGatewayを洗い出し、各ノードの稼働ビルド、公開アドレス、役割を記録する。VPN仮想サーバーでDTLSが明示的に無効かどうか、ほかにDTLS型の仮想サーバーがあるかも設定から確認する。
  2. 更新や再起動の前に、取得可能な設定、システムログ、Webサーバーログと時刻情報を保全する。仮想装置では運用上可能ならメモリを含む状態の保存も検討する。同時に、ファイアウォール、通信フロー、認証基盤など装置外の記録を確保する。
  3. 該当する修正版を導入し、起動後の実ビルドを確認する。更新を待つ間にDTLSやUDP/443を制限する場合、それが対象とするのはCVE-2026-88772の経路であり、CVE-2026-88771への修正を代替しない。
  4. 保全した記録と装置の設定・ファイルを時系列で照合する。侵害が疑われるノードは接続を制限し、高可用性構成の相手側も調べる。不審な設定が同期で複製されないよう、両ノードの状態を確認するまで同期の扱いにも注意する。

ログの所在は見落としやすい。NSPPEの終了や監視プロセスの記録は装置のシステムログに、Webシェルへの要求はWebサーバーのアクセスログやエラーログに残り得る。標準の監査ログ転送には含まれない種類があるため、監視基盤に記録がないことだけで異常がなかったとは判断できない。装置内のログが残っているかを早い段階で確認したい。

ログ、Webシェル、不審通信をどう照合するか

通信記録では、DTLSハンドシェイクの失敗と、その直後のNSPPEの終了を同じ装置の時刻で並べる。特に内部エラーを伴う失敗とプロセス終了の組み合わせは優先して調べるべき兆候だ。予期しない再起動や高可用性構成の切り替わりも、同じ時間帯に起きていないか確認する。失敗ログ一つだけで侵入を断定せず、装置内外の記録を重ねて判断する。

ファイル側では、/etc/httpd.confなどに、.debや.sigをPHPとして実行させる設定や、/vpn/media/の画像要求をスクリプト置き場へ振り向ける設定がないかを見る。VPN用クライアントの配布先や静的ファイルの置き場では、拡張子がパッケージや画像でも、中身がPHPのテキストであるファイルを調べる。ファイル名は侵入先ごとに変わり得るため、既知の名前との一致だけでは足りない。

Webアクセスログでは、画像に見える要求が404応答を返しながら大きな本文を返す、処理時間が長い、VPN用パス付近の行が不自然に欠ける、といった挙動を照合する。エラーログに残る.sigなどの存在しないファイルへの要求も手掛かりになる。/tmp/.uxdportや/tmp/.uxdlock、予期しないPythonプロセス、/bin/shのSUID権限は、トンネルや権限維持の調査点だ。

装置から外へ出る通信も見る必要がある。NetScalerから多数の内部ホスト、ドメインコントローラー、認証情報を扱うシステムへ向かう予期しない接続があれば、Webシェルのアクセス時刻と突き合わせる。TLS通信が装置で終端される場合、上流のネットワーク機器にはHTTPの要求パスやヘッダーが見えないことがある。上流のフローログは接続先の把握に、装置のWebログは要求内容の把握に使い分ける。

侵害が疑われた装置の扱い

Webシェルや不審な設定変更が見つかった場合は、修正版を導入済みでも侵害対応が必要になる。接続を制限して証拠を保全し、もう一方の高可用性ノードと、装置から到達できた内部システムを調べる。装置の管理者資格情報だけでなく、連携先のサービスアカウント、VPNセッション、証明書や秘密鍵にも露出の可能性を検討する。

資格情報の変更は、侵害装置へ新しい秘密を再び渡さないよう、更新と封じ込めの状態を確認してから進める。調査で残る実務上の焦点は、更新前のログがどこまで保存され、Webシェルの設置時刻と内部への通信を結び付けられるかだ。装置外に残る認証・通信記録は、装置内の記録が欠けている場合にも侵入範囲を絞る手掛かりになる。

関連記事：

共有:

関連記事

ニュースレターを購読

Web3、AI、暗号資産の最新ニュースを受信箱にお届けします。

0