前回の記事「PHP2Shell をどう追ったか — Sysdig Secure AI を活用した影響調査と対処の記録」では、2026年10月に緊急公開された PHP の深刻な脆弱性「PHP2Shell（CVE-2026-109618 / CVE-2026-109619、ともに CVSS v4.0 スコア 9.2）」に対して、Sysdig Secure AI を使って影響を受けるシステム（前回の例では demo-kube-aws クラスタの sysevent など）を素早く特定し、対処計画（Remediation Plan）を立てるまでの流れをご紹介しました。
どのシステムに脆弱性があるかが分かれば、ゴールに向けて一歩前進です。しかし、現場のエンジニアやセキュリティ担当者には、もうひとつ現実的で切実な悩みが残ります。
「パッチを当てるまでには、どうしてもテストや調整の時間がかかる。もし今日の真夜中に攻撃されたら、私たちは気づけるのだろうか？ そして、被害が出る前に止められるのだろうか？」
結論からお伝えします。
- 攻撃者が侵入した後に目的を果たすために行う「コマンドの実行」「外部への通信（リバースシェル）」「不正プログラムの配置」といった行動は、Sysdig Secure に最初から入っている標準ルールだけでしっかりと検知できます。
- さらに、Sysdig Secure の「レスポンスアクション（自動封じ込め機能）」を設定しておけば、たとえ真夜中に攻撃が起きても、人手を介さずに数秒で攻撃プロセスやコンテナを強制終了し、被害を自動で差し止めることができます。
- そして、PHP 内部のメモリ処理に関わる部分は「PHP の設定変更（応急処置）やパッチ適用」と組み合わせることで、入り口から出口まで隙のない多層防御が完成します。
この記事では、難しいルールのコードや専門的な構文には踏み込まず、「攻撃者が何をしたときに Sysdig がどうやって見破るのか」、そして「夜中でも自動で攻撃を止めるにはどうすればいいのか」を、誰にでもイメージできるようにわかりやすく紐解いていきます。
1. そもそも、なぜ「侵入された瞬間」ではなく「侵入された後の動き」を見張るのか？
まずは、PHP2Shell という攻撃の正体を簡単にイメージしてみましょう。
今回の脆弱性（CVE-2026-109618 / CVE-2026-109619）は、PHP のエンジン内部で「メモリの整理整頓がうまくいかなくなるバグ」を突くものです（参照: NCSC-NL Advisory、Datadog Security Labs）。攻撃者が特別に細工した HTTP リクエストを送りつけると、PHP がメモリ不足（Out-of-Memory）を起こしたり、すでに片付けたはずの古いメモリ領域を誤って参照（Use-After-Free）したりして、最終的に攻撃者の好きなプログラムを実行できてしまいます。特に Apache の mod_php 環境などでは、ログイン画面などの認証を通る前に、たった 1 回の通信で突破される危険性があります。
この「最初のひと突き」は、Web サーバや PHP という部屋（メモリ）の「中だけ」で静かに起きる出来事です。外で見張っている警備員（OS カーネルを見守る Sysdig / Falco）から見ると、ただ普通に Web のアクセスが来て、PHP がメモリを使っているだけにしか見えません。
しかし、攻撃者の本当の目的は「PHP のメモリを壊すこと」ではありません。その先にある「サーバを乗っ取って操作する」「裏口（バックドア）を作る」「データを盗み出す」ことです。
攻撃者がこうした目的を果たそうとして、部屋の外にある OS の機能（コマンドの起動、ネットワーク接続、ファイルの実行）に手を伸ばした瞬間、警備員である Sysdig の目の前に決定的な証拠が飛び出します。だからこそ、ランタイム脅威検知では「攻撃者が侵入後に起こすアクション」を網を張って待ち構えるのです。
2. 一目でわかる！攻撃のステップ別「Sysdig Secure の守備範囲と役割分担」
では、攻撃者が PHP2Shell を使ってサーバに侵入してから目的を果たすまでの流れを 5 つのステップに分けて、それぞれのステップをどうやって守るのか見てみましょう。
| 攻撃のステップ | 攻撃者がやること | どうやって守るか（役割分担） | 仕組みのポイント |
|---|---|---|---|
| Step 1: 初期侵入 | 細工したリクエストを送り、PHP のメモリ状態に干渉する | PHP の応急設定・パッチ / WAF で防御 | PHP のメモリ内部で起きる現象のため、PHP の設定（memory_limit=-1 等）やパッチ適用で入り口を固めます |
| Step 2: 偵察・コマンド実行 | Web サーバから OS のコマンド（whoami や curl など）を叩く |
Sysdig 標準ルールで即座に検知 | 本来コマンドを叩くはずのない Web サーバや PHP が、突然コマンドを起動したことを異常として捉えます |
| Step 3: 遠隔操作の確立 | 攻撃者の PC へ通信を繋ぎ直し、遠隔操作（リバースシェル）を始める | Sysdig 標準ルールで強力に検知（最も得意） | シェル（操作画面）の入出力が外部のネットワークに直接繋がれたことを、OS レベルで確実に捉えます |
| Step 4: マルウェアの実行 | 一時フォルダやメモリ上にウイルス等を置いて動かす | Sysdig 標準ルールで網羅的に検知 |
/tmp などの一時領域やメモリ上からプログラムが起動されたこと、または元のコンテナになかった新しいプログラムが動いたことを捉えます |
| Step 5: 持続化・コマンド操作 | 設置した裏口ファイル（Web シェル）等から OS コマンドを実行して操作を広げる | 裏口からのコマンド実行時に Sysdig で検知 ＋ 応急設定で予防 | 設置された Web シェルが OS コマンドを呼び出した瞬間に Step 2・Step 3 のルールが発動し、逃さず捕捉します |
それぞれのステップで、Sysdig Secure が具体的にどうやって攻撃を見破るのか、もう少しだけ覗いてみましょう。
3. 特別な設定なしでここまで見破る！Sysdig 標準ルールの 3 つの防衛網
カスタムルールを 1 行も書かなくても、Sysdig Secure に最初から用意されている標準ルールだけで、Step 2〜Step 4 の動きは幾重にもカバーされています。
防衛網 1：Web サーバの「いつもと違うコマンド実行」を見破る（Step 2）
普段、Web サーバ（Apache など）や PHP（php-fpm など）の仕事は、プログラムを動かして Web ページを返すことです。それなのに、突然「今の権限は何か調べるコマンド」や「外部から怪しいファイルをダウンロードするコマンド（curl や wget）」、あるいは「クラウド（AWS 等）の権限を調べるコマンド」を起動したらどうでしょうか。
Sysdig の標準ルール（Suspicious Command Executed by Web Server）は、「大元の親が Web サーバや PHP なのに、怪しいコマンドが起動された！」という親子関係を見張っています。攻撃者が一クッション置いてシェルを経由させたとしても、家系図をたどって「先祖に Web サーバや PHP がいること」を突き止めてアラートを上げます。
防衛網 2：攻撃者への「折り返し電話（リバースシェル）」を徹底包囲する（Step 3）
攻撃者がサーバを自由に操るために一番よく使う手口が「リバースシェル」です。外からサーバへ入るのではなく、乗っ取ったサーバ側から攻撃者の PC へ「折り返し電話」をかけさせ、遠隔操作の画面（シェル）を繋げる手法です。
ここは Sysdig が最も得意とする領域です。標準ルールには、攻撃者のあらゆる工夫を先回りした複数のルールが用意されています。
- 基本のリバースシェル検知（
Reverse Shell Detected）: 遠隔操作の画面（シェル）がネットワーク通信に直結された瞬間を、最高レベルの重要度（CRITICAL）で捉えます。 - 通信の暗号化や専用ツールの悪用もカバー: 攻撃者が監視の目を逃れるために
opensslで通信を暗号化したり、socatやnetcatといったネットワークツールを悪用したりしても、それぞれ専用のルール（OpenSSL Reverse Shell Detected、Socat Reverse Shell Detected、Netcat Remote Code Execution in Container）が待ち構えています。 - 怪しい司令塔（C2 サーバ）への通信検知（
Outbound Connection to C2 Servers）: 攻撃者のサーバとして知られている危険な IP アドレスへ通信しようとした瞬間にもアラートが上がります。
防衛網 3：どこに隠しても逃さない「不正プログラムの起動」検知（Step 4）
攻撃者がサーバ内にウイルス（暗号資産マイナーや遠隔操作ツールなど）を持ち込んで動かそうとした場合、ファイルを置く場所によって複数のルールが網を張っています。
- 一時フォルダからの実行（
Execution from /tmp）: 誰でもファイルを書き込める/tmpフォルダにプログラムを置いて動かした瞬間に検知します。 - メモリ領域からの実行（
Execution from /dev/shm/Fileless Malware Detected）: ハードディスクに証拠を残さないよう、メモリ上（/dev/shmやmemfd）にプログラムを展開して直接動かそうとする高度な「ファイルレス攻撃」も、最高レベルの重要度（CRITICAL）で即座に見破ります。 - コンテナへの後から追加されたプログラムの実行（
Drop and execute new binary in container）: コンテナ環境の場合、「元のコンテナイメージには入っていなかった新しいプログラム」が動いたこと自体を検知できます。
4. 防御力をさらに高める！知っておきたい「ルールの選び方」と「多層防御」のコツ
Sysdig Secure の標準ルールを最大限に活かし、より確実な守りを作るために、ぜひ押さえておきたい 2 つの実践ポイントをご紹介します。
ポイント 1：Web 経由の攻撃には「Web サーバ監視ルール」と「リバースシェル検知」を主役にする
コンテナのセキュリティでよく知られる有名ルールに Terminal shell in container（コンテナ内でのターミナルシェル起動）があります。これは管理者が kubectl exec などで「対話画面（ターミナル）付きのシェル」に直接ログインした際に見つけるためのルールです。
一方、PHP2Shell のように Web サーバの裏側で自動実行される攻撃に対しては、第 3 章でご紹介した「Web サーバの不審コマンド検知（Suspicious Command Executed by Web Server）」や「リバースシェル検知（Reverse Shell Detected）」が主役として活躍します。この 2 系統のルールをポリシーでしっかり有効にしておくことで、対話画面の有無にかかわらず、Web 経由の怪しい動きを網羅的にキャッチできるようになります。
ポイント 2：PHP の「応急設定」と「Sysdig のランタイム監視」をタッグで動かす
前回の記事で、Sysdig Secure AI が提案してくれた「PHP の設定変更（memory_limit=-1 の強制や session.upload_progress.enabled=0）」や「パッチ適用」を思い出してみてください。
PHP の設定変更は「PHP 内部のメモリが壊されるのを防ぐ（入り口の防御）」役割を担い、Sysdig のランタイム検知は「万が一侵入された後に、攻撃者が OS コマンドやネットワークを使って暴れるのを捕まえる（行動の防御）」役割を担います。この 2 つをタッグで動かすことで、PHP の内部処理から OS レベルの挙動まで、シームレスにカバーし合う盤石な体制が整います。
5. 真夜中の攻撃でも数秒で差し止める！Sysdig「レスポンスアクション」の威力
さて、ここからが本題のもうひとつの柱です。
「Sysdig の標準ルールで攻撃の事後アクションに気づけることは分かった。でも、もし夜中の 3 時にアラートが鳴ったら、翌朝誰かが気づくまでやりたい放題にされてしまうのでは？」
ご安心ください。Sysdig Secure には、脅威を見つけた瞬間に自動で攻撃を封じ込める「レスポンスアクション（Response Actions）」と「オートメーション（Automations）」が備わっています（参照: Sysdig Docs - Response Actions）。これを事前に設定しておけば、人間が寝ている間でも、Sysdig が自動で攻撃を差し止めてくれます。
夜間に自動で攻撃を止める 3 つの代表的なアクション
状況やシステムの重要度に合わせて、主に次の 3 つの止め方を選べます。
- 怪しいプロセスだけを狙い撃ちで強制終了する（
Kill Process）
Web サーバや PHP が、本来動かすはずのない「シェル」や「ダウンロードコマンド（curl等）」を起動した瞬間に、その怪しいプログラムだけを即座に強制終了（SIGKILL）させます。Web サーバ本体は止めずに、攻撃者が放ったコマンドだけをピンポイントで撃ち落とせるのが魅力です。 - 侵害されたコンテナごと強制終了し、綺麗な状態で再起動させる（
Container Kill/Container Stop）
「リバースシェルが張られた」「メモリ上でマルウェアが動いた」といった決定的な侵入（CRITICALルール）を検知した瞬間に、そのコンテナ自体を即座に終了させます。 - コンテナの通信を遮断して隔離する（
Isolate Network）
Automations 機能を使うと、侵害された疑いのある Pod に対して Kubernetes のネットワーク制限を自動で適用し、外部との通信を完全に遮断して「隔離部屋」に閉じ込めることができます。
PHP2Shell に対して「コンテナの強制終了」が劇的に効く理由
実は、Kubernetes 環境で動く PHP アプリケーションにとって、Sysdig の Container Kill（または Stop）は PHP2Shell に対する極めて相性の良い対抗策になります。
先ほど、PHP2Shell は「PHP のメモリを壊して汚染する攻撃」だとお話ししました。一度攻撃によってメモリが書き換えられた PHP ワーカープロセスは、そのまま動き続ける限り、攻撃者にとって都合の良い状態（裏口が開いた状態）を保ち続けてしまいます。
しかし、Sysdig が攻撃の動きを検知してコンテナを Kill または Stop すると、どうなるでしょうか。
コンテナが終了した瞬間、汚染されたメモリも、攻撃者がコンテナ内にこっそり置いた一時ファイルもすべて綺麗に消去されます。そして Kubernetes が自動的に「元のクリーンなイメージ」から新しいコンテナを立ち上げ直してくれます。つまり、「攻撃者の遠隔操作をブツッと断ち切る」と同時に、「壊された PHP のメモリ状態を初期化する」という 2 つの効果を、真夜中でも全自動で達成できるのです。
自動差し止めを設定するときの「プロのひと工夫」
夜間の自動差し止めを安心して任せるために、以下の 3 つをセットで設定しておくのがおすすめです。
- 証拠を残す「キャプチャ（Capture）」を必ず一緒に ON にする
コンテナを自動で強制終了させると、被害は止まりますが、コンテナ内の証拠も一緒に消えてしまいます。ポリシーの設定で「システムコールキャプチャ（録画）」や Automations の「ログ取得（Get Logs）・ファイル回収（Acquire File）」を同時に ON にしておけば、コンテナを消す前後の「攻撃者が何をやったかの全記録」を Sysdig 側にしっかり保存しておけます。翌朝出社してから、落ち着いて原因調査ができます。 - 確実にクロと言えるルールから自動停止を適用する
万が一の誤検知で本番サービスが止まるのを防ぐため、「リバースシェル検知（Reverse Shell Detected）」や「メモリ上でのマルウェア実行（Execution from /dev/shm、Fileless Malware Detected）」など、通常の業務では絶対に起きないCRITICALなルールに対して自動停止を設定し、影響範囲（対象クラスタやネームスペース）を絞っておくと安心です。 - 事前のスイッチ確認を忘れずに
クラスタに導入している Sysdig エージェント（Host Shield）側で、レスポンスアクションの許可スイッチ（Helm 設定のfeatures.respond.response_actions.enabled=true）が ON になっていることを事前に確認しておきましょう（デフォルトでは安全のため OFF になっています）。
6. まとめ：パッチが当たるまでの「最強の布陣」を作ろう
前編・後編にわたって、緊急の脆弱性「PHP2Shell（CVE-2026-109618 / CVE-2026-109619）」に対する Sysdig Secure の活用法を見てきました。最後に、パッチ適用が完了するまでの間に私たちが敷くべき「3 段構えの布陣」を整理します。
- 【把握と緩和】Sysdig Secure AI で影響箇所を特定し、まずは PHP の応急処置を入れる
demo-kube-awsクラスタのsyseventのように影響を受ける場所を特定したら、パッチ（PHP 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35）の準備を進めつつ、すぐできる応急処置（php_admin_valueでのmemory_limit=-1強制やsession.upload_progress.enabled=0の設定）で「入り口」を狭めます（参照: Sophos Advisory、Elastic Security Labs）。 - 【リアルタイム検知】Sysdig の標準ルールで「侵入後の動き」に目を光らせる
万が一入り口を突破されても、Web サーバからの不審なコマンド実行、リバースシェル、一時フォルダやメモリ上でのプログラム実行を、Sysdig の既存ルール群が逃さずキャッチします。 - 【自動差し止め】レスポンスアクションとキャプチャで、真夜中の攻撃も即座に封じ込める
検知した瞬間にプロセスやコンテナを自動終了させる設定と、証拠を録画するキャプチャを組み合わせておけば、夜間や休日でも被害の拡大を自動で食い止め、汚染されたメモリをクリーンな状態へリセットできます。
新しい脆弱性が発表されるたびに、「専用の新規ルールを作らなきゃ」「パッチが当たるまで夜も眠れない」と焦る必要はありません。すでに手元にある Sysdig Secure の標準ルールが「何を見張ってくれているのか」を知り、レスポンスアクションの自動スイッチを入れておく。それだけで、パッチ適用までの空白期間を驚くほど落ち着いて、安全に乗り切ることができます。