F5 BIG-IPのAPM（アクセスポリシーマネージャー、リモートアクセスや認証を制御するモジュール）をオンプレミスやDMZで運用しているインフラ担当者に向けた内容です。
2026年に報告された「PoisonedRefresh」と呼ばれるLinux向けルートキット（OS内部に潜伏し正規プロセスを乗っ取る攻撃コード）は、BIG-IP APM機器を標的にしています。単なるマルウェア感染ではなく、ディスク上のファイルが正常に見えるまま、稼働中のApacheプロセスの記憶領域だけを改ざんする点が特徴です。SREやセキュリティ運用の観点から、何が起き、どう検知し、どう復旧するかを整理します。
何が起きるのか
PoisonedRefreshは、BIG-IP APMが内部で使っているApache httpdとlibphp（PHPをApacheに組み込むための共有ライブラリ）を標的にします。
攻撃者はまずインストーラーを使い、httpdの起動プロセスとSELinux（Linuxのアクセス制御を強制する仕組み）の設定、さらにアップデート処理そのものを改変します。これにより再起動やソフトウェア更新をまたいでも、仕込んだコードが生き残る状態を作ります。
次の段階では、Apache起動時のフック（特定処理に割り込んで別のコードを実行させる仕組み）を仕掛け、libphpの読み込みを待ちます。そして正規のPHPファイルには一切手を加えず、メモリ上に展開された内容にだけWebシェル（外部から任意コマンドを実行させる仕掛け）を注入します。
特定のマーカーを含むPOSTリクエストを受け取ると復号・実行し、さらに別の足場からUNIXソケット経由で接続すると、TCPリスナーを開かずに対話的なBashシェルを得られる仕組みも備えています。TCPの待ち受けポートが存在しないため、通常のポートスキャンやネットワーク型の異常検知ではまず見つかりません。
なぜ検知が難しいのか
原因を段階的に分解すると、次のようになります。
まず、改ざんの対象がディスク上のファイルではなく実行中プロセスのメモリだという点です。多くの改ざん検知ツールはファイルのハッシュ値やタイムスタンプを比較する仕組みで、ディスクが健全であればアラートを出しません。ls -la や md5sum でPHPファイルを確認しても、異常は見つからない設計になっています。
次に、通信経路の問題があります。UNIXソケット（同一ホスト内のプロセス間通信に使うファイル型の通信路）を使う経路は、TCPフローとして観測されません。ネットワーク側のIDS/IPSやNetFlowのログだけを監視していても、この経路の通信は原理的に見えない構造です。
さらに、正常系との混在も検知を妨げます。攻撃者が仕込んだレスポンスはCSS（スタイルシート）のContent-Typeを装うケースがあり、通常のトラフィックに紛れ込みます。ユーザー側からは通常のサービス応答と区別がつきません。
最後に運用面の課題です。BIG-IPのようなアプライアンス機器はブラックボックス的に扱われがちで、内部プロセスに対する継続的なオブザーバビリティ（システム内部の状態を外部から観測できるようにする設計思想）が手薄になりやすい領域です。EDR（エンドポイント検知応答ツール）の対象外になっているケースも珍しくありません。
自分の環境が該当するか確認する
まず、CVE-2025-53521の対象バージョンに該当するかどうかをF5公式のセキュリティアドバイザリで確認します。BIG-IP管理画面またはCLIから、稼働中のソフトウェアバージョンを次のように確認できます。
tmsh show sys version次に、APMモジュールが有効化されているかどうかも確認しておきます。APMを使っていない構成であれば、直接の攻撃面は狭まります。
tmsh list apm profile accessそのうえで、既にパッチ適用前の期間にAPMが外部からアクセス可能だった場合は、パッチを当てるだけでなく侵害調査を行う必要があります。バージョンアップは脆弱性を塞ぐだけで、既に仕込まれたルートキットを除去する処理ではないためです。
調査の観点としては、次のログ・情報源を確認します。
- リバースプロキシやWAFのログで、
.php3を対象としたPOSTリクエストとHTTP 201かつContent-Typeがtext/cssという組み合わせがないか - アプライアンスのプロセス監査やメモリダンプが取得可能であれば、httpdの改変・libphpへの不審なフック・UNIXソケットの存在
- IdP（認証基盤）側で、APM経由のセッションに紐づく不審な認証やセッション再利用がないか
- クラウド上にAPMを構築している場合は、IAMやAPI操作の監査ログでの異常なワークロード操作
DNSログだけではリクエスト本文やレスポンスコードは分からないため、これ単独での判定は不十分です。
対策の手順
1. F5公式のCVE-2025-53521向け修正を適用します。適用前に必ずメンテナンスウィンドウとロールバック手順を用意しておきます。
2. 既知の正常な状態（クリーンな導入時のイメージやゴールデンイメージ）と、現在稼働中のhttpdバイナリ、SELinuxポリシー、Apacheワーカープロセスのメモリ構成を比較します。差分があれば侵害の兆候です。
3. 侵害の疑いがあるアプライアンスはネットワークから隔離し、証跡を保全した上で信頼できるイメージから再構築します。設定の移行だけで済ませず、機器そのものを作り直す判断が安全です。
4. アプライアンス上および接続先システムの認証情報を全てローテーションします。APM経由で取得された可能性のあるセッションやトークンも無効化対象に含めます。
5. IaC（Terraform/Pulumiなどによるインフラのコード管理）でBIG-IPの構成を管理している場合は、再構築後の状態を新たな正としてコード側を更新し、手動変更のドリフト（コードと実環境のズレ）を検出できる体制に戻します。
6. SLO（サービスレベル目標）にセキュリティ関連の可用性影響を組み込んでいる場合は、今回のような侵害対応にかかる復旧時間を、障害対応Runbook（対応手順書）にあらかじめ落とし込んでおきます。次に同種のインシデントが起きた際、判断に迷う時間を減らせます。
導入前後で確認しておくこと
BIG-IP APMのようなネットワーク境界機器は、可用性設計上「落ちない」ことが優先され、内部プロセスの継続的な監視が後回しになりがちです。
今回のケースが示すのは、ディスクの健全性チェックだけでは不十分で、稼働中プロセスのメモリ状態まで見る仕組みが必要という点です。
最低限、次の3点は確認しておく価値があります。
tmsh show sys versionでCVE-2025-53521の対象バージョンかどうか- リバースプロキシ・WAFログに
.php3へのPOSTとtext/css応答の組み合わせがないか - アプライアンスの再構築とIaCによる構成管理が実際に機能する体制になっているか
パッチ適用は入口に過ぎません。境界機器の内部まで見える化する運用に、少しずつでも近づけていくことが現実的な一歩です。