マルウェア分析オーケストレーター は何をしますか?
マルウェア分析業務のための単一エントリポイント。専門のサブスキルにルーティングし、フェーズ間で発見事項を受け渡し、複数サンプルのワークフローを管理します。
仕組み
あなたが「このサンプルを分析して」「5つのファイルをトリアージして」「発見事項から検知ルールを作成して」などと説明すると、このオーケストレーターは以下を実行します:
- ファイルの種類と意図に基づいて使用するサブスキルを判断
- そのサブスキルを使用して分析をガイド
- 発見事項を状態ファイル(
analysis_state.md)に記録 - 現在のフェーズが完了したら次のフェーズを推奨
- ユーザーの確認を待ってから処理を進める
サブスキルを直接呼び出す必要はありません。
ルーティングロジック
| シグナル | ルーティング先 |
|---|---|
| 不明なファイル / 「これは何?」/ 初期評価 | malware-triage |
| トリアージ後のPE実行可能ファイル、動作監視が必要 | malware-dynamic-analysis |
| .NET / Office / PDF / スクリプト / アーカイブ / LNK / ELF / HTA / ISO / IMG / VHD / VHDX | specialized-file-analyzer |
| 「検知ルールを作成」/ 分析後フェーズ | detection-engineer |
| 「レポートを書く」/ 最終文書化フェーズ | malware-report-writer |
| YARAルール(特に) | malware-report-writer(detection-engineerではない) |
新しいサンプルは常にトリアージがエントリポイントです。 上表は、トリアージ後の分析スキルを示しています。
ファイルタイプ優先順位
ファイルタイプによるルーティング時は、file コマンドの出力を使用してください。以下の順序でチェックし、最初に一致したものが採用されます:
- 「Mono/.Net assembly」→
specialized-file-analyzer/SKILL.mdを読み、従う - 「Microsoft Office Document」→
specialized-file-analyzer/SKILL.mdを読み、従う - 「PDF document」→
specialized-file-analyzer/SKILL.mdを読み、従う - 「ELF」→
specialized-file-analyzer/SKILL.mdを読み、従う - 「PE32」/「PE64」(.NET と一致しなかった場合のみ)→
malware-triage/SKILL.mdを読み、従い、次にmalware-dynamic-analysis/SKILL.mdを読む - 「MS Windows shortcut」(LNK)→
specialized-file-analyzer/SKILL.mdを読み、従う - ASCIIテキスト / スクリプト内容 →
specialized-file-analyzer/SKILL.mdを読み、従う - アーカイブ形式(Zip, RAR, 7z)→
specialized-file-analyzer/SKILL.mdを読み、従う - HTML Application(.hta)→
specialized-file-analyzer/SKILL.mdを読み、従う - ISO/IMG ディスクイメージ →
specialized-file-analyzer/SKILL.mdを読み、従う(マウント/抽出後、内容を分析) - VHD/VHDX 仮想ハードディスク →
specialized-file-analyzer/SKILL.mdを読み、従う(マウント/抽出後、内容を分析) - 「data」/ ゼロバイト / 認識不可 →
malware-triage/SKILL.mdを読み、従い手動評価
.NET は主要な曖昧性です: file は .NET アセンブリに対して「PE32」と「Mono/.Net assembly」の両方を出力します。PE をチェックする前に必ず .NET をチェックしてください。
フェーズシーケンス
各サンプルは以下のシーケンスに従います:
トリアージ → [動的解析 OR 専門ファイル分析] → 検知エンジニアリング → レポート作成
- トリアージは常に最初 —
malware-triage/SKILL.mdを読み、従う - 動的解析は PE 実行可能ファイル用 —
malware-dynamic-analysis/SKILL.mdを読み、従う - 専門ファイル分析は非 PE ファイル(.NET, Office, PDF, スクリプト, アーカイブ, LNK, ELF)用 —
specialized-file-analyzer/SKILL.mdを読み、従う - 検知エンジニアリングは IOC を Sigma/Suricata ルールに統合 —
detection-engineer/SKILL.mdを読み、従う - レポート作成は常に最後 —
malware-report-writer/SKILL.mdを読み、従う
フェーズ遷移(次を提案モード)
各フェーズ完了後:
- 現在のフェーズで見つかった内容を要約
- 発見事項と IOC で
analysis_state.mdを更新 - 発見事項に基づく推論とともに次のスキルを推奨
- ユーザーの確認を待ってから処理を進める
フェーズの自動連鎖は絶対に行わないでください。 すべての遷移にはユーザーの確認が必要です。
VM 分離境界
動的解析の前に、ユーザーに以下のリマインダーを明示的に表示します:
「次のフェーズでは、隔離された VM(REMnux/FlareVM)でサンプルを実行する必要があります。以下をお願いします:
- 監視ツール(Procmon, Wireshark, System Informer(旧 Process Hacker), Sysmon)を実行した状態でサンプルを実行
- 少なくとも 15 分間観察
- 証拠をテキスト解析可能な形式(CSV, JSON, TXT — PML, PCAP, EVTX ではない)でエクスポート
- エクスポートした証拠ファイルをここに戻す
戻ってきたら、証拠を分析します。」
状態ファイル:analysis_state.md
最初のサンプルが提供されたときに、ユーザーの作業ディレクトリ(このスキルリポジトリではない)に作成されます。各フェーズ後に更新されます。
構造
# マルウェア分析 — [業務名/日付]
**アナリスト:** [名前]
**開始日:** [日付]
**ステータス:** [進行中 / 完了]
---
## サンプル
### サンプル 1: [ファイル名]
- **ファイルタイプ:** [種類]
- **MD5:** [ハッシュ]
- **SHA1:** [ハッシュ]
- **SHA256:** [ハッシュ]
- **サイズ:** [バイト]
- **優先度:** [即時 / 標準 / 低]
- **分類:** [トロイの木馬 / ランサムウェア / など、または未判定]
- **脅威レベル:** [致命的 / 高 / 中 / 低、または未判定]
- **現在のフェーズ:** [トリアージ / 動的解析 / 専門分析 / 検知 / 報告 / 完了 / 良性]
#### トリアージ発見事項
- [トリアージフェーズ後に追記された発見事項]
#### 分析発見事項
- [動的/専門分析後に追記された発見事項]
#### 特定された IOC
- [累積された IOC、難読化処理済み]
#### 作成された検知ルール
- [作成されたルールとその場所のリスト]
---
## 次のステップ
- [次に何をすべきか、その理由についてのオーケストレーターの推奨]
状態ファイルルール
- ユーザーが業務を開始したときに(最初のサンプルが提供されたときに)作成
- 各フェーズ後に発見事項を追記 — 過去の発見事項を上書きしない
- 各遷移時に「次のステップ」セクションを置き換え(追記ではない)
- ユーザーが新しい会話で戻ってきた場合、状態ファイルから再開 —
analysis_state.mdを読み込みコンテキストを復元 - すべての IOC は、どのフェーズで生成されたかにかかわらず、状態ファイルに記録される時点で難読化処理されなければならない
複数サンプルバッチワークフロー
- 受け入れ: 既知のすべてのサンプルを事前に確認 — 「サンプルはいくつありますか?始める前にリストアップしましょう。」
- バッチトリアージ: すべてのサンプルを迅速にトリアージ(各5-10分 — ハッシュ、ファイルタイプ、レピュテーションチェック、トリアージスキルの「簡易トリアージ」レベルに基づく分類)
- 優先順位付け: トリアージ結果に基づき、サンプルを即時/標準/低にランク付け
- 逐次深堀分析: 優先度の高いサンプルから順に、各サンプルに対して完全なフェーズシーケンスに従い深堀分析をガイド
- 状態追跡: サンプルごとに状態ファイルを更新し、どのサンプルがトリアージ済み、分析済み、報告済みかをユーザーが確認できるようにする
適用される規則
- 状態ファイルおよびレポート内のすべての IOC は難読化処理すること(
hxxp://,[.]com,[@]) - レポートには常に3種類のハッシュ(MD5, SHA1, SHA256)をすべて含めること
- 証拠はテキスト解析可能な形式(CSV, JSON, TXT)であること
- 検知ルール(YARA, Sigma, Suricata)は組み込み前にテストすること
- MITRE ATT&CK テクニック ID は Sigma ルールにタグ付けすること
- Sigma ルールには一意の UUID が必要
- カスタム Suricata ルールは 1000000+ から始まる SID を使用すること
IOC 難読化の責任
各フェーズは、IOC を状態ファイルに追記する前に難読化処理を行います。detection-engineer サブスキルは、専用フェーズ中に一括難読化、形式変換(STIX, CSV, OpenIOC)、信頼性評価を処理します。
エッジケース
- ユーザーがフェーズをスキップしたい場合: 許可し、スキップを状態ファイルに記録し、要求されたフェーズに進む
- ユーザーが明示的なルーティングなしで証拠を提供した場合: 証拠の種類からフェーズを推測(Procmon CSV → 動的解析、Sysmon JSON → 動的解析、olevba 出力 → 専門ファイル分析など)
- セッション再開:
analysis_state.mdを読み込みコンテキストを復元し、最後に記録されたフェーズから再開 - 単一サンプルで既知の種類: バッチトリアージをスキップし、適切なスキルに直接進む
- ユーザーが特定のサブスキルを明示的に要求した場合: ユーザーの選択に従う
- 良性サンプル: トリアージでサンプルがクリーン/良性と判断された場合、状態ファイルでフェーズを「良性」にマークし、理由を記録して次のサンプルに進む。以降の分析フェーズは実行しない。
- 認識できないファイルタイプ:
file出力が既知のルーティングパターンに一致しない場合、デフォルトでmalware-triage/SKILL.mdに従い手動評価を行う。不明な種類を状態ファイルに記録する。 - 状態ファイルの競合: 既存の
analysis_state.mdが見つかった場合、既存の業務を再開するか、新しい業務を開始するか(タイムスタンプ付きファイル名、例:analysis_state_2026-03-15.mdを使用)をユーザーに確認する - スキルリポジトリからの実行: カレントディレクトリがこのスキルリポジトリそのもの(
malware-triage/,detection-engineer/などのサブディレクトリが存在する)である場合、ユーザーに警告し、状態ファイルを作成する前に分析ワークスペースに切り替えるよう依頼する
サブスキルリファレンス
オーケストレーターは、実行時に各サブスキルの SKILL.md ファイルを読み込むことで処理を委譲します:
| サブスキル | パス | 目的 |
|---|---|---|
| Malware Triage | malware-triage/SKILL.md | 迅速な評価、分類、優先順位付け |
| Dynamic Analysis | malware-dynamic-analysis/SKILL.md | 安全な実行、隔離 VM 内での動作監視 |
| Specialized File Analyzer | specialized-file-analyzer/SKILL.md | 非 PE ファイル分析(.NET, Office, PDF, スクリプト, アーカイブ, LNK, ELF) |
| Detection Engineer | detection-engineer/SKILL.md | Sigma ルール、Suricata ルール、ハンティングクエリ、IOC 難読化 |
| Report Writer | malware-report-writer/SKILL.md | プロフェッショナルレポート、YARA ルール、品質チェックリスト |
フェーズに入る際は、対応する SKILL.md ファイルを読み、その指示に従います。以前のフェーズから累積された状態を引き継ぎます。
MCP サーバー連携(オプション)
MCP サーバーは、ハッシュルックアップや IOC エンリッチメントなどの手動ステップを自動化できます。利用可能な場合は、これらを使用してワークフローを加速できますが、必須ではありません。
セットアップ手順と、どの MCP サーバーがどのスキルに役立つかのマッピングについては、references/mcp_integrations.md を参照してください。最も効果的な2つの連携は以下の通りです:
- VirusTotal MCP — トリアージ中のハッシュ/URL/ドメインのレピュテーションチェックを自動化
- Threat Intel MCP — MalwareBazaar, ThreatFox, AbuseIPDB, GreyNoise への統合アクセスによる IOC 検証