F5 BIG‑IP APM未認証RCEが「ディスク無改ざん」の幻影を生む——PoisonedRefreshの設計思想と運用側の落とし穴

今日の深掘りポイント

• 侵入は「未認証RCE＋メモリ内ウェブシェル」という王道と新機軸の合わせ技です。ディスクを汚さず、Apache/PHPの実行経路を乗っ取り、痕跡を極小化します。
• APMはVPN・SSO・ゼロトラの“関所”。ここが破られると「正規ユーザーの影」をまとった侵害が長期化しやすいです。
• 従来のファイル・インテグリティやIOCベースのハンティングは素通りされがちです。メモリ挙動とプロセスチェーンの監視に主軸を移す必要があります。
• 短期は「露出の遮断・緊急パッチ・プロセス健全性チェック」、中期は「アプライアンス上のランタイム可視化（eBPF等）と境界のゼロトラ化」への投資が効きます。

はじめに

F5 BIG‑IP APMは、企業のリモートアクセスと認証の心臓部です。この層で未認証RCEが成立し、しかもメモリ常駐のウェブシェルで持続化されると、運用者が「見た目の無害さ」に安心してしまう余白が生まれます。PoisonedRefreshは、まさにその余白を狙い撃つ設計で、ApacheのPHPモジュールのファイル／メモリ操作を傍受し、実行時にだけ悪性ペイロードを差し替えると報じられています。結果、ディスク上のファイルはクリーンのまま、Apacheプロセスは「別物」を実行することになります。検出や証跡保全の常道がすり抜けられるとき、わたしたちが頼れるのは“ランタイムの現実”だけです。

本稿では、確認されている事実関係と、その構造から見える実務リスク、そして即応から中長期の備えまでを整理します。数値スコアに現れた緊迫度合いは高く、現場の判断に猶予は少ないと読みます。

深掘り詳細

事実関係（一次情報ベースで確認できる範囲）

• 報道によれば、PoisonedRefreshはF5 BIG‑IP APMの未認証RCE（CVE‑2025‑53521）を起点に、メモリ内へPHPウェブシェルを注入し、ApacheのPHPモジュール内でファイル／メモリ操作を傍受する設計です。F5は悪用確認済みで、c05d5254キャンペーンとの関与が指摘されています。影響はAPM 15.1.x、16.1.x、17.1.x、17.5.xに及ぶとされます。［出典: 二次報道］GBHackersの解説
• 特徴は「ディスク上のPHPスクリプトは無害のまま」「Apacheプロセスが実行時に改変済みのメモリビューを解釈」という点です。すなわち、ファイルスキャンや改ざん検知では見落ちがちで、運用上は“健全に見える”アプライアンスが内部で別の振る舞いをしている可能性がある、ということです。

注記：現時点で筆者は当該CVEに関するF5の公式アドバイザリ本文を直接確認できていません。初報は二次報道のため、公式ドキュメントが公開され次第、版を改めて追記すべき事項です。一次情報の確認と差分吸収は、各組織で最優先タスクとして進めるべきです。

インサイト（設計上の狙いと“どこが痛いか”）

• メモリ内ウェブシェルは「ファイルに触れないこと」自体がゴールです。PHPエンジンの読込経路（zend_compile_fileやストリームラッパ）やglibcのopen/read系シンボルをフックすれば、同一パスのファイルでも「プロセスから見える内容」を差し替えられます。これにより、- 実ファイルのハッシュは正しい、- 署名検証も通る、- しかしプロセスが解釈したコードは別物、という“観測の逆説”が成立します。
• APMという特性上、認証フローに深く介在できるため、攻撃者は以下の“低ノイズ・高価値”オプションを得ます。
  • 資格情報・セッショントークンの窃取（SSO/IdP連携の要所を横取り）
  • アクセスポリシー評価点での条件分岐“だけ”を密かにすり替え、特定ユーザーやソースだけを通す「一点突破」
  • 管理者のUI/CLIトンネル化（/bin/bash起動などのサブプロセス連鎖）
• ディスク改ざんがないため、標準の改ざん検知、YARA on disk、差分バックアップ比較はどれも素通りしやすいです。防御の主舞台は、プロセスのライフサイクル、ロード済み共有ライブラリ、環境変数（LD_PRELOAD等）、システムコール面のふるまい監視に移ります。アプライアンスでこれをやる難しさこそが、攻撃者の“設計要件”だったはずです。

脅威シナリオと影響

以下は、現時点の公開情報に基づく仮説シナリオです。実際のTTPは組織ごとに検証をお願いします。

• シナリオA：認証ゲート乗っ取りによる継続的窃取

  • 初期侵入: Exploit Public-Facing Application（MITRE ATT&CK: T1190）により未認証RCEを獲得します。
  • 実行/持続化: Web Shell（T1505.003）をメモリ内に展開。必要に応じてHijack Execution Flow/Shared Libraries（T1574.002）や環境変数ハイジャック（LD_PRELOADの類、T1574.006に相当）でロード経路を確保します（仮説）。
  • 防御回避: Hide Artifacts（T1564）、Signed Binary Proxy Execution（T1218）等の正規実行経路悪用（仮説）。
  • 資格情報/収集: Input Capture（T1056）、Credentials from Web BrowsersやSSO連携部位のトークン収集（T1557中間者の派生、またはT1552不適切保護資格情報の悪用／仮説）。
  • C2通信: Application Layer Protocol: Web Protocols（T1071.001）でHTTP(S)に溶け込みます。
  • 影響: APM経由の“正規”セッションに偽装して持続化し、監査ノイズを低く保ったまま内部資産へピボットします。

• シナリオB：一点突破のポリシー改変で“特定だけ通す”

  • 実行: 攻撃者は特定条件（特定のUA/源IP/クッキー）でのみPHPロジックを差し替えます。平時は完全に正規挙動に見えます。
  • 影響: 運用監視のしきい値を越えずに、標的ユーザーのログイン経路だけが汚染され、検知はさらに遅延します。

• 影響の勘所

  • 横断影響: 政府・金融・通信などAPMを境界に据える組織では、単なるアプライアンスの脆弱性を超え、認証/ID基盤の信用失墜に直結します。
  • 事業継続: 侵害の切断は「再起動で消える」可能性がある一方、未パッチのままでは短時間で再感染します。パッチ適用と露出遮断の並走が不可欠です。

セキュリティ担当者のアクション

優先度順で、インシデント・レスポンスの現実解を並べます。アプライアンス特有の制約を踏まえ、「できることから早く・確実に」を意識します。

1. 露出の即時抑制とバージョン把握

• 外部公開のAPM仮想サーバーを棚卸しし、緊急でIP制限・地理制限・一時停止の検討をします（業務影響の可逆性を担保したうえで、段階的ロールバック手順を用意します）。
• バージョン/モジュール確認（例）：tmshやGUIでAPMの系統（15.1/16.1/17.1/17.5）とパッチレベルを明示化します。脆弱範囲で未パッチなら、メンテナンスウィンドウを即確保します。

2. パッチ／推奨緩和策の適用

• F5の公式アドバイザリに従い、該当CVEの修正を最優先で適用します。アクセス・ポリシーを割り当てた仮想サーバーがトリガ条件と報じられているため、短期緩和としては「条件を満たす公開経路の最小化」も選択肢です（業務影響要評価）。
• 管理プレーンの到達遮断（管理UI/APIはアウトオブバンド/管理ネットのみ）を徹底します。

3. ランタイム健全性チェック（メモリ偏重の観点）

• Apache/php-fpm系プロセスが/bin/bash等のシェルを子プロセスとして起動していないかを確認します。例：ps -eo pid,ppid,comm,args --forest | egrep 'httpd|apache|php|bash' など（環境に応じて適宜置換します）。
• ネットワーク外向き接続の洗い出し：ss -tpn | grep -E 'httpd|apache|php' で、通常想定外のC2風コネクションがないかを確認します。
• 環境変数と共有ライブラリの列挙：/proc//environ（LD_PRELOAD/LD_LIBRARY_PATH）と、lsof -p | grep '.so' で不審な読み込みを確認します。apachectl -M 相当でロードモジュールの異常も点検します。
• 可能なら一時的にメモリダンプ（gcore等）を取得し、オフボックス解析（YARA on memory、PHPコード断片の特徴語：eval/assert/base64_decode/gzinflate等）を試みます。アプライアンスのSLAに抵触しない範囲で実施します。

4. ログとハンティングの要点

• APM/Apacheのアクセス・エラーログで、特定エンドポイントへの異常POST、ユーザーエージェントのエントロピーが高い連続アクセス、500系の断続など「挙動の乱れ」を可視化します。
• 侵害痕跡がディスクに残らない前提で、プロセス再起動／箱の再起動後に症状が一時的に消える“自己回復”を過信しないでください。未パッチのままでは再感染が常です。
• 監視を“プロセス・チェーン主語”に切り替え、- 誰が誰を起動したか、- どの.soがいつロードされたか、- どこに外向き接続したか、を継続収集します。可能ならeBPFベースのランタイム・テレメトリをアプライアンス境界で補完します。

5. 認証/ID基盤の補助線

• APM連携先（IdP/AD/RADIUS/LDAP）側で、直近の管理者ログイン、トークン発行の偏り、失敗/成功の相関を確認します。必要に応じて、強制パスワードリセット、トークン無効化、デバイス再登録を段階的に実施します。
• SSOの署名鍵・証明書の不正アクセス痕跡がないかを点検します。機微に触れる変更は監査ログと二人承認の裏取りを行います。

6. 中長期の備え（再発防止）

• アプライアンス運用に「ランタイム可視化」を標準装備します。eBPFセンサー、Sysmon for Linux相当、NDRのプロセス相関を、少なくとも“境界の関所”には適用します。
• アップグレード・パッチ適用のSLOを明文化し、露出資産の棚卸し（CMDB/ASM/ASM連携）を継続可能な運用に落とし込みます。
• APM直結の公開を最小化し、CDN/WAF/ゼロトラの三層で“入口の薄皮”を増やします。脆弱な時期ほど多層化は効きます。

7. レスポンスの最小反復（SRE的Runbook）

• 露出遮断 → 影響評価（ログ/プロセス/外向き接続） → パッチ適用 → 秘密情報/トークンの無効化 → 追加ハードニング → 継続監視、の反復を2〜3スプリントで回します。各ステップで巻き戻し手順を用意し、業務影響を定量で記録します。

最後に、数値スコアが示す「すぐ動ける／動くべき」シグナルは強い一方で、情報はまだ変動フェーズにあります。一次情報の更新に合わせ、検知クエリと抑止策を“可変”として設計しておくのが、いま取れる最も現実的な守り方です。境界で戦うのではなく、実行時の現実を観測して勝つ。その方向転換を、この案件は静かに迫っているのだと思います。

参考情報

• 二次報道（初報・技術的概観）: PoisonedRefresh Malware Targets F5 BIG-IP APM Servers to Deploy In-Memory PHP Web Shell (GBHackers)

注：当該CVEおよび修正情報のF5公式アドバイザリは、公開・更新タイミングに依存します。読者各位の環境で一次情報の入手と版管理を優先し、差分を組織内ナレッジに速やかに反映してください。