NexaCorp DFIR: INC-2026-001 - Linux インフラストラクチャ侵害

NexaCorp インフラストラクチャに対する模擬侵入の DFIR 調査と検知エンジニアリング。BeCode Brussels Blue & Red Team ブートキャンプ（Mission 01）の 4 日間ソロエンゲージメントとして実施。成果物は 54 ページの調査報告書（PDF）と、PCAP リプレイで捕捉されたインシデントを検知する検証済み Suricata ルール 7 件です。

このリポジトリは、BeCode Cybersecurity Bootcamp（2025-2026 年次）の一環として実施された SOC アナリストのエンゲージメントを文書化したものです。ネットワークとログの証拠から完全な侵入を再構築し、検証済みの Suricata 検知ルール一式を提供します。NexaCorp DFIR シリーズの最初のインシデントです。

目次

• 運用上の注意
• 概略
• エンゲージメントの背景
• エグゼクティブサマリー
• キルチェーン概要
• このレポートの読み方
• 方法論
• 使用ツール
• 調査結果の概要
• 検知エンジニアリング
• リポジトリ構成
• 再現性
• 既知の制限
• NexaCorp DFIR シリーズ
• 謝辞
• 概要
• ライセンス

運用上の注意

これは架空のインフラストラクチャに対するラボエンゲージメントです。 NexaCorp は BeCode Brussels Mission 01 のシナリオとして使用される架空のクライアントです。侵害されたホストは、セキュリティトレーニング用に意図的に脆弱性を持たせた Metasploitable 2 VM であり、Caldera Sandcat インプラントは、実際の侵入者のビーコントラフィックがどのようなものかをアナリストに教えるラボの一部です。実際の組織、ネットワーク、人物は攻撃されていません。

このレポートで公開されているすべての IP アドレス、ホスト名、侵害指標（172.16.50.10、192.168.10.10、10.40.0.200、blue11、mesdec など）はラボ内限定の成果物であり、実際の脅威インテリジェンスではありません。これらを IOC として SIEM に取り込まないでください。

公開は 2026-05-17 に BeCode ラボコーチ（Thomas B.）によって承認されました。完全な機密保持声明は調査報告書（「配布と分類」セクション）に記載されています。

概略

エンゲージメントの背景

シナリオ（架空）。 中規模企業クライアントである NexaCorp は、内部監視で社内 Linux サーバーの 1 台からの予期しないアウトバウンドトラフィックが検知された後、BeCode Corp のブルーチームに連絡しました。ファイアウォールはトラフィックを記録しましたが、対応可能なアラートは発生しませんでした。経営陣は、開示と規制当局への通知を決定する前に、判断材料を必要としていました。

任務。 疑わしいインシデント期間を調査し、攻撃者の侵入経路と侵害後の活動を特徴づけ、既存の検知スタックが検知したもの（および見逃したもの）を評価し、優先順位付けされた是正計画を提供します。第 2 フェーズでは検知エンジニアリングを追加しました。再発をリアルタイムで検知できる、すぐに導入可能なネットワーク IDS ルールの作成です。

クライアントから受け取った証拠パッケージ。

教育的背景。 このエンゲージメントは、**BeCode Brussels Blue & Red Team ブートキャンプ（2025 年 11 月〜2026 年 9 月）**の Mission 01 として実施されました。実際の DFIR コンサルティングエンゲージメントを模した、ソロかつ時間制限付きの調査です。ラボインフラストラクチャ、NexaCorp の身元、IOC 値は意図的に架空のものです。方法論、ツール、レポート形式は、実世界の標準（NIST SP 800-61r2、SANS PICERL、MITRE ATT&CK）に従っています。

エグゼクティブサマリー

📄 完全版 54 ページの調査報告書が正式な成果物です。 PDF をダウンロード（215 KB）、または Markdown ソースを参照して grep / 引用に使用できます。

2026-05-09 22:53 UTC の夜、外部攻撃者（172.16.50.10）が CVE-2011-2523、つまり vsftpd 2.3.4（2011 年 7 月以降、侵害が公に文書化されているビルド）に存在するバックドアを悪用して、NexaCorp の内部サーバー（192.168.10.10）を侵害しました。:) で終わる単一の FTP USER リクエストが、TCP/6200 で認証不要の root バインドシェルを起動しました。攻撃者は 20 秒間のセッションで 8 件の偵察コマンドを実行し（永続化なし、データ持ち出しなし、このアクセスベクトルによる横展開なし）、切断しました。

一方、同じホストには、既存の MITRE Caldera「Sandcat」エージェントが /opt/caldera/sandcat（root、デーモン化）で実行されており、キャプチャ期間を通じて 40〜50 秒ごとに平文 HTTP で 10.40.0.200:8888 へビーコンを送信していることが判明しました。これはクライアントが当初フラグを立てた「異常なアウトバウンド接続」であり、証拠パッケージに含まれていない以前の侵害を示しています（インプラントは最初の PCAP フレームで既にアクティブでした）。

既存の Wazuh SIEM はターゲットホストから 397 件のイベントを取り込みましたが、発生したアラートは 4 件の高重大度アラート（全体の 1.0%）のみで、すべて汎用のブルートフォース（MITRE T1110）として分類されました。CVE-2011-2523 のエクスプロイトペイロード、TCP/6200 のバインドシェル、Caldera C2 チャネルを特定したものはありませんでした。エクスプロイトのバイト列（USER baduser:)）は vsftpd 自体によってログに記録されることはなく、SIEM には残りを確認できるネットワークテレメトリがありませんでした。フェーズ 2 で提供された 7 件の Suricata ルールが、この 3 つのギャップすべてを埋めます。

主要 IOC（ラボ限定。実際の SIEM には取り込まないでください）:

キルチェーン概要

捕捉されたインシデントには、PCAP から再構築された 2 つの異なる経路があります:

1. 露出したサービス: 公に文書化されたバックドア（CVE-2011-2523）を持つビルドである vsftpd 2.3.4 が、内部ネットワーク上で到達可能でした（Finding I1）。
2. エクスプロイト: :) で終わる単一の FTP USER リクエストがバックドアをトリガーしました（Finding I3）。
3. root バインドシェル: 認証不要の root シェルが TCP/6200 で開かれました。攻撃者は 20 秒間のセッションで 8 件の偵察コマンドを実行し、その後切断しました。このベクトルによる永続化やデータ持ち出しはありません（Finding I4）。
4. 並行する C2（既存）: 並行して、MITRE Caldera Sandcat インプラントが、期間全体を通じて平文 HTTP で 10.40.0.200:8888 へすでにビーコンを送信していました。これは、証拠バンドルに含まれていない以前の侵害の証拠です（Finding I5）。

このレポートの読み方

このリポジトリは、役割に応じて適切な深さで読み進められるように構成されています:

正式な成果物: reports/ 内の PDF。Markdown ソースは同一の内容で、検索可能性とバージョン管理のためにリポジトリに保持されています。

調査の足跡: notes/journal.md はアナリストの作業ノートです（検証・棄却された仮説、証拠の目録、計画の状況）。結論そのものだけでなく、どのように結論に至ったかを示すことで、正式なレポートを補完します。

検知ルールセット: detection/lab.rules には、インラインコメントでキーワードごとの完全な根拠とともに 7 件の Suricata ルールが含まれています。detection/README.md は、各ルールが捕捉されたインシデントで発火することを確認するために使用した、デプロイとリプレイの検証ワークフローを文書化しています。

方法論

このエンゲージメントは、3 つの業界標準フレームワークを重ね合わせて構成されています。

NIST SP 800-61r2: Computer Security Incident Handling Guide

NIST の 4 フェーズモデル（Preparation、Detection & Analysis、Containment / Eradication / Recovery、Post-Incident Activity）が高レベルの構造を提供します。このエンゲージメントでは、成果物のフェーズ 1 は NIST の「Detection & Analysis」に対応します（PCAP フォレンジック、SIEM 相関、攻撃者タイムラインの再構築）。フェーズ 2 は NIST の「Lessons Learned」に対応し、予防的コントロール（7 件の Suricata ルールと、レポートセクション 7 の優先順位付けされた推奨事項リスト）として具現化されています。

SANS PICERL: 戦術的調査フロー

PICERL（Preparation、Identification、Containment、Eradication、Recovery、Lessons Learned）は SANS のインシデントレスポンスプロセスです。このエンゲージメントでの適用:

MITRE ATT&CK: テクニックのマッピング

すべての調査結果は、クライアントがこのインシデントを既存の脅威モデルと関連付けられるように、1 つ以上の MITRE ATT&CK テクニックにマッピングされています。10 件の調査結果全体で 14 の異なるテクニックが参照されています:

• Reconnaissance: T1595.002、T1592.002、T1589
• Initial Access: T1190（CVE-2011-2523 による公開アプリケーションのエクスプロイト）
• Execution: T1059.004（Unix シェル）
• Discovery: T1033、T1082、T1087.001、T1083、T1016、T1049、T1046
• Credential Access: T1110（ブルートフォース）
• Command and Control: T1071.001、T1102（Caldera Sandcat ビーコン）
• Privilege Escalation: T1078.003、T1548.003（疑わしい sudo アクティビティ）

調査結果ごとの完全なテクニック表はレポートセクション 4（IOC）にあり、調査結果ごとの詳細分析はセクション 3 と 5 にあります。

再現性

レポートのすべての主張は、証拠パッケージ内の証跡にトレース可能であり、それを再現するために必要な正確な tshark フィルター、Wazuh クエリ、または Suricata リプレイコマンドが付随しています。クイックスタートとして、レポートの付録 A（再現性コマンド）と、以下の再現性セクションを参照してください。

使用ツール

ネットワークフォレンジック

• tshark: PCAP トリアージ、TCP ストリーム再構築（-z follow,tcp,ascii）、プロトコルフィルタリング、フィールド抽出のための CLI Wireshark
• tcpreplay と tcprewrite: ラボの ens19（1450 バイト）に合わせた MTU 調整を行い、Suricata ルール検証のためにライブ監視インターフェースへの PCAP リプレイを実行
• Base64 デコーダー: Caldera Sandcat C2 ペイロード（ビーコン本体とオペレーターレスポンス）の再構築

ネットワーク IDS / 検知エンジニアリング

• Suricata 6.0.4（afpacket モード、シングルスレッド、ラボでは Hyperscan 無効）: 本成果物の 7 ルールを作成、検証、チューニング
• suricata -T: デプロイとチューニング中の設定・ルール検証
• kill -USR2 $(pgrep suricata): 反復的なチューニング中のルールのライブリロード

SIEM とホストテレメトリ

• Wazuh（マネージャー + ダッシュボード）: イベント相関、深刻度分布分析、ルール検索（rule.id 11452、5551 など）、397 イベントの CSV エクスポート
• 標準的な Linux テキストユーティリティ（grep、awk、jq）: ログマイニングと JSON パース

敵対者エミュレーションのコンテキスト（参照のみ、操作はしていない）

• MITRE Caldera（Sandcat エージェント）: 特徴づけの対象となる、シミュレートされた既存 C2 インプラントとしてターゲットホスト上に存在

参照フレームワーク

• NIST SP 800-61r2: Computer Security Incident Handling Guide
• SANS PICERL: 戦術的調査フロー
• MITRE ATT&CK: テクニックの帰属
• CVE-2011-2523 アドバイザリ: vsftpd 2.3.4 バックドアのリファレンス

調査結果の概要

10 件の調査結果（I1 〜 I10）は、調査報告書に詳細に文書化されています。各エントリには、証拠、再現性コマンド、MITRE ATT&CK マッピング、是正ガイダンスが含まれています。

深刻度の分布: 3 CRITICAL / 3 HIGH / 2 MEDIUM / 2 LOW

推奨される読み順: I1（脆弱なサービス）から始め、次に I3、I4（実際のエクスプロイトチェーン）、続いて I5（並行する無関係な C2 インプラント）を読みます。I2 と I6 は偵察のコンテキストを示します。I7 〜 I10 は防御体制に関する調査結果です（モニタリングが検知したものと見逃したもの）。

検知エンジニアリング

エンゲージメントのフェーズ 2 では、捕捉されたインシデントを エクスプロイトシグネチャ、エクスプロイト後のシェル、並行する C2 チャネルの 3 つの角度からカバーする 7 件の Suricata ルール（SID 9000001 〜 9000007）を作成しました。各ルールは、SOC ワークステーション上の Suricata 6.0.4 インスタンスに対するオフライン PCAP リプレイで検証されています。

7 つのルール

検証サマリー

40 対 314 の差は、ルール 9000003、9000004、9000005、9000006 に対する意図的なスロットリングを反映しており、フォレンジックの詳細分析用に eve.json の生のアラートストリームを保持しつつ、SOC アナリストにクリーンな運用ビューを提供します。

注目すべき設計上の決定

デプロイ中の 4 つの反復的な修正は detection/README.md に文書化されています。重要な教訓:1. ポートに依存しないHTTP検出。 ルール9000004および9000005（Caldera）は当初、alert http と http.uri キーワードで記述されており、これらはSuricataのHTTPパーサーをポート80でのみ使用します。Caldera C2はポート8888で動作するため、パーサーは迂回され、ルールは決して発火しませんでした。修正：TCP+contentモード（alert tcp ... content:"POST /beacon"; content:"Go-http-client/1.1";）で書き直し、ポートに関係なく生のHTTPバイトに一致させます。 2. PCAPリプレイ中のflow:establishedは信頼できない。 リプレイウィンドウ外でキャプチャされたTCPハンドシェイクは、フロー状態マシンを不確定な状態のままにします。Calderaルールからflow:establishedを削除すると、ライブモードとリプレイモードの両方で一致するようになります。 3. SYNのみのルールに対する明示的なフロー方向。 ルール9000003（ポート6200）は SC_WARN_POOR_RULE: SYN-only ... w/o direction specified を発生させました。flow:to_server,not_established を追加することで修正しました。 4. RFC1918のみのラボにおけるHOME_NETとEXTERNAL_NET。 攻撃者、ターゲット、C2がすべてプライベート空間に存在する場合、EXTERNAL_NET = !$HOME_NET は空になり、 形式のルールは決して一致しません。ラボでの修正：両方で を使用します。本番での修正： を保護対象セグメントのみに絞ります。

誤検知に関する考慮事項

ルールごとの誤検知分析は レポートのセクション8.5 に文書化されています。ほとんどのルールは、適切にスコープされた環境では無視できるリスクしかありません。ルール9000005（aiohttp Serverヘッダー）と9000006（管理パス上のcurl/Wget）は、無害な内部Pythonサービスや管理スクリプトが存在する場合、チューニングが必要です。

リポジトリ構成```text

NexaCorp-DFIR-INC-2026-001/ ├── README.md (this file) ├── LICENSE (MIT) ├── .gitignore ├── .github/ │ └── workflows/ │ └── ci.yml markdownlint + typography + Suricata rule check ├── reports/ │ ├── INC-2026-001_Findings_Report.pdf canonical 54-page deliverable │ └── INC-2026-001_Findings_Report.md same content, Markdown source ├── detection/ │ ├── lab.rules 7 Suricata rules (SID 9000001-9000007) │ └── README.md deploy + replay validation workflow ├── evidence-summary/ │ └── ioc-summary.md indicators of compromise (SIEM-ingestible) ├── methodology/ │ ├── attack-timeline.md incident timeline (UTC) │ └── attck-mapping.md MITRE ATT&CK mapping table └── notes/ └── journal.md analyst investigation journal (hypotheses, plan, IOCs, timeline)

**ファイル分類：**

| パス | 役割 | 対象読者 |
|---|---|---|
| `reports/*.pdf` | 正式な成果物、正式レポート | クライアント、採用担当者、監査人 |
| `reports/*.md` | 同一内容、grep しやすいソース | 引用や差分確認を行う人 |
| `detection/lab.rules` | 本番投入可能な Suricata ルールセット | SOC / 検知エンジニア |
| `detection/README.md` | デプロイ + リプレイ検証ガイド | 検知エンジニアのオンボーディング |
| `evidence-summary/ioc-summary.md` | カテゴリ別の侵害インジケータ（IoC） | SOC / 脅威ハンティング |
| `methodology/attack-timeline.md` | インシデントタイムライン（UTC） | DFIR 実務者 |
| `methodology/attck-mapping.md` | MITRE ATT&CK マッピング表 | DFIR / 検知エンジニア |
| `notes/journal.md` | 調査作業ノート | 手法を学ぶ DFIR 実務者 |
| `.github/workflows/ci.yml` | プッシュ時に markdownlint、タイポグラフィ、Suricata ルール検証（`suricata -T`、`detection/*.rules` が存在する場合に実行）を自動実行 | CI |

## 再現性

調査結果レポートのすべての主張は、エビデンスパッケージ内のアーティファクトにトレース可能です。PCAP 自体は再配布されません（BeCode ラボの所有物）が、コマンドとクエリは文書化されているため、自分のコピーを持っている人なら誰でも分析を再現できます。

### 主要な調査結果の再現（PCAP 解析）

`tshark`（Wireshark CLI）と元の `attack.pcap` が必要です：```bash
# 1. PCAP overview
tshark -r attack.pcap -q -z io,stat,0

# 2. TCP conversations (reveals attacker, target, C2)
tshark -r attack.pcap -q -z conv,tcp | head -30

# 3. Confirm vsftpd 2.3.4 banner exposure (Finding I1)
tshark -r attack.pcap -Y "ftp && ip.src == 192.168.10.10" \
  -T fields -e frame.time -e ftp.response.code -e ftp.response.arg | head -5

# 4. Find the CVE-2011-2523 exploit payload (Finding I3)
tshark -r attack.pcap -Y 'ftp.request.command == "USER"' \
  -T fields -e frame.time -e ftp.request.arg

# 5. Reconstruct the root shell session on TCP/6200 (Finding I4)
tshark -r attack.pcap -q -z follow,tcp,ascii,70

# 6. Reconstruct the Caldera C2 beacon (Finding I5)
tshark -r attack.pcap -q -z follow,tcp,ascii,6 | head -50

ルール検証の再現（Suricata リプレイ）

Suricata 6.0.x、tcpreplay、および監視対象インターフェース（ラボでは ens19、ご自身のものに置き換えてください）が必要です:```bash

1. Install the ruleset

sudo cp detection/lab.rules /etc/suricata/rules/learner/lab.rules

2. Hot-reload Suricata without restart

sudo kill -USR2 $(pgrep -f suricata) sleep 5

3. Clear the alert log for a clean baseline

sudo truncate -s 0 /var/log/suricata/fast.log

4. Replay the PCAP at top speed

sudo tcpreplay --intf1=ens19 --topspeed attack_mtu.pcap

5. Count alerts per rule (expect 7 distinct SIDs)

sudo grep -oE '[1:[0-9]+:' /var/log/suricata/fast.log | sort | uniq -c | sort -rn

I'm ready to translate the content. However, it looks like the input chunk is empty — no source text was provided. Please provide the actual Markdown content for chunk 8 so I can translate it accurately.```text
     30 [1:9000002:    (vsftpd banner repeated per session)
      3 [1:9000007:    (FTP USER enumeration threshold)
      3 [1:9000006:    (HTTP admin path enumeration)
      1 [1:9000005:    (Caldera C2 response)
      1 [1:9000004:    (Caldera Sandcat beacon, throttled)
      1 [1:9000003:    (Backdoor port 6200 SYN)
      1 [1:9000001:    (vsftpd USER smiley exploit)

7/7 のルールが正しく発動しました。 完全な証拠パッケージ（fast.log、eve.json、スロットリング設定、Suricata バージョンスナップショット）は、調査報告書の付録 E に列挙されています。

既知の制限事項

• 証拠パッケージはインシデント途中から始まる。 PCAP は 2026-05-09 20:08 UTC に始まるが、Caldera Sandcat エージェントはすでにフレーム 1 でアクティブにビーコンを送信している。インプラントをインストールした初期侵害はそれより前に発生しており、データには含まれていない。インプラント前の活動に関する結論は、Wazuh の full_log フィールドから推定されたものであり、直接観測されたものではない。
• ホスト監査ログは攻撃期間と重ならない。 ローカルの auth.log と syslog は PCAP 終了の約 5 時間後に開始され、最初のエントリは syslogd restart（おそらく VM 再起動）である。ローテーションされたログファイルは提供されていない。これは Finding I10 として文書化されている。
• スコープはフォレンジック＋検知エンジニアリングであり、ライブレスポンスではない。 封じ込め、根絶、フォレンジック取得（メモリイメージ、ディスクイメージ）、永続化の列挙は、報告書では P0 推奨事項 として文書化されているが、実行されていない。このエンゲージメントにはライブホストへのアクセスがなかったためである。それらのループを閉じるにはフォローアップのエンゲージメントが必要となる。
• 7 つの Suricata ルールはこの特定のインシデントシグネチャを検知する。 高度な攻撃者は、エクスプロイトのバイトパターンを変更する（USER 引数に代替のヌルバイト終端を使用する）、Caldera を別の User-Agent で再コンパイルする、または C2 を暗号化 HTTPS に移行する（JA3/JA4 のような TLS メタデータ分析がフォールバックとなる）ことで、ルールを回避できる。このルールは捕捉された脅威シナリオには適切であり、長期的な検知戦略では行動ベースおよびメタデータベースの検知を追加すべきである。
• 調査中の Wazuh 取り込みギャップ。 SIEM ログ取り込みパイプラインは、2026-05-11 11:39 UTC まで一時的に利用できなかった（調査の途中で、ラボコーチによって復旧された）。そのため、4 つの高重大度アラートは、実際のインシデントタイムスタンプ（5月9日 21:00-22:53）ではなく、取り込みタイムスタンプ（5月11日 13:17-13:28）でダッシュボードに表示され、相関イベントの見かけ上のタイミングが歪められる。
• ラボでは HOME_NET が any に設定されていた。 実際の NexaCorp 展開では、HOME_NET を保護対象セグメントのみ（例: 192.168.10.0/24）に絞り込み、 が攻撃者スペースを正しくカバーするようにする必要がある。納品されたルールはラボ用に調整されており、本番使用前にこの 1 つの設定変更が必要である。

NexaCorp DFIR シリーズ

• INC-2026-001: このリポジトリ
• INC-2026-002: 特権昇格と永続化（Tor SSH、SUID、バックドアアカウント）
• INC-2026-003: 1 か月目のインシデント横断評価
• INC-2026-004: SQL インジェクション（Web ポータル）
• INC-2026-005: OS コマンドインジェクションと Web シェル（Web ポータル）
• INC-2026-006: 格納型 XSS とセッションハイジャック（Web ポータル）
• INC-2026-007: IDOR と壊れたアクセス制御（NexaPortal）; 2 か月目のキャップストーン
• INC-2026-008: AD 偵察と Kerberoasting（3 か月目の最初のインシデント）

謝辞

• Thomas B.（BeCode ラボコーチ）: シナリオ設計、調査途中の Wazuh 取り込み修正、ポートフォリオ利用のための公開許可。
• MITRE には、シミュレートされた C2 インプラントを動かした Caldera フレームワークと、すべての調査結果をマッピングするために使用した ATT&CK ナレッジベースに感謝します。
• Suricata プロジェクト には、7 つのルールを 30 分以内にデプロイ可能にしたエンジンに感謝します。

概要

2026-05-15 に、BeCode Brussels の Blue & Red Team ブートキャンプ（2025 年 11 月から 2026 年 9 月）の Mission 01 として実施されたソロ DFIR エンゲージメント。

著者: Johan-Emmanuel Hatchi（LinkedIn）。

2026 年 9 月からベルギーでのサイバーセキュリティインターンシップの機会を募集中。この種のエンドツーエンドの調査業務（PCAP フォレンジック、SIEM 相関、IDS ルール作成、正式なクライアントレポート作成）がスコープに含まれる SOC / DFIR / 検知エンジニアリングの役割を探しています。

ライセンス

MIT, 2026 Johan-Emmanuel Hatchi.

detection/lab.rules 内の Suricata ルールと報告書のテキストは、どちらも同じ MIT ライセンスの下でリリースされています。帰属表示付きで自由にコピー、改変、再展開できます。PCAP、ラボインフラストラクチャ、およびエンゲージメントブリーフィングは BeCode Brussels の所有物であり、再配布されません。