公開 PoC が出たら、検知ルールを待たずにハンティング条件を作る（論文「Encore」の考え方）
調べた 45 件の CVE のうち、公開の検知ルール（Sigma・Elastic・Splunk）があったのは 37 件。そのうち 33 件では Python の PoC がルールより中央値 22 日早く出ていた。この空白期間を、PoC を実行せずに静的解析してルール化することで埋める手法の提案。
仕組み
- PoC のライブラリー呼び出し（
requests.postやファイル操作など）を、攻撃される側の Web サーバー・プロキシー・ホストのログに残る操作に対応付ける表を事前に作る。 - そこから 3 種類のルールを作る：
| ルール | 一致させるもの | 用途 |
|---|---|---|
| リクエストルール | 脆弱なエンドポイントへのリクエスト | 広く拾う（誤検知も多い：正常 27,081 件中 9,113 件が候補）＝ハンティング用 |
| ペイロードルール | リクエスト中のペイロード断片 | 攻撃そのものの証拠。正常通信では警告ゼロ |
| ホストルール | サーバー上の操作（ファイル作成など） | 同上 | - 失敗した攻撃の試みも検出対象になる。
結果
- 45 件中 43 件を検出。Splunk の既存ルール（ESCU）より、別 CVE のログへの誤反応が少ない（30 件間で Splunk 20 組 vs Encore 2 組）。
- Claude Opus 5 / GPT-6 Astra に同じ PoC からルールを書かせた場合は 32 件・31 件の検出で、誤反応も多かった。
自分たちで使うなら
- 重要な CVE の PoC が出たら、PoC の「送る URL・メソッド・パラメーター」と「サーバー側に作るファイルや実行するコマンド」を抜き出す（実行はしない）。
- まず脆弱なエンドポイントへのアクセスを過去ログで洗い（ハンティング）、次にペイロード断片・ホスト上の操作で絞り込んでアラートにする。
- LLM にルールを書かせる場合も、上の対応付けを人が確認する。丸投げは検出漏れと誤反応が増える。
注意
- 前提は公開された Python PoC と対応表。表にない raw ソケット上のプロトコルは対象外。対応表の構築に約 9 人日かかる。