変更要約: 初版
3.5ログ解釈とマルウェア解析出力
OS・アプリケーション・コマンドラインのログや、SIEM/SOARが集約・自動化する記録からイベントを読み解く力と、検体を隔離環境で実行するデトネーションチャンバ/サンドボックスの概念、そしてその解析出力（ハッシュ・URL・システム/イベント/ネットワーク情報）をIoCとして活用する判断を学びます。
SOCの日常は「ログを読んでイベントを組み立てる」ことに尽きます。ただしログはOS・アプリ・コマンドラインで粒度も語彙も違い、SIEMはそれらを横断相関し、SOARは定型対応を自動化します。さらに、正体不明の検体はサンドボックス（デトネーションチャンバ）で安全に実行させ、その振る舞い（生成ファイルのハッシュ、接続先URL/IP、レジストリ変更）をIoCとして抽出します。この節では、単発のログ行や解析レポートから「何が起きたか」を復元し、次の一手を決める判断を扱います。
3.5.1ログ源とSIEM/SOAR
- OS/アプリ/CLIログ＝OSログ（Windowsイベントログ、Linux
/var/log）はログオンやサービス状態を、アプリログ（Webサーバのアクセスログ等）はアプリ固有の事象を、CLIログ（シェル履歴、sudo/監査ログ）は実行されたコマンドを示す。例えばsshd[2011]: Failed password for invalid user admin from 203.0.113.5はSSHへの総当たりの兆候。粒度が違うので組み合わせてイベントを組み立てる。 - SIEM＝多数のログを収集・正規化・相関し、単独ログでは見えない攻撃（例：複数ホストにまたがる認証失敗の連鎖）をアラート化する分析基盤。時刻同期（NTP）が崩れると相関が狂うため、タイムスタンプの整合が前提。
- SOAR＝SIEM等の検知を受け、プレイブックに沿って対応を自動化/半自動化する（例：不審IPの自動ブロック、端末隔離、チケット起票）。反復的な一次対応を高速化し、アナリストを判断が要る事案に集中させる。
3.5.2サンドボックスと解析出力
- サンドボックス/デトネーションチャンバ＝疑わしい検体を本番から隔離した環境で実際に実行（デトネート）し、その振る舞いを観測する動的解析。静的解析（実行せず構造を調べる）が難読化で行き詰まるケースでも、実際の動作を明らかにできる。ただし高度なマルウェアはサンドボックス回避（仮想環境検知や時間差実行）を行うため、無反応＝安全とは限らない。
- 解析出力＝レポートには、生成/変更ファイルのハッシュ（MD5/SHA-256）、接続先URL/ドメイン/IP、レジストリ/ファイルシステムの変更、起動プロセス、ネットワーク挙動などが並ぶ。これらはIoCとして、SIEMやEDRに投入し他ホストの汚染確認やブロックに使える。特にハッシュは検体を一意に識別する指標。
「OSログ=ログオン/サービス、アプリログ=アプリ固有、CLIログ=実行コマンド」「SIEM=収集・正規化・相関でアラート化（時刻同期が前提）」「SOAR=プレイブックで対応を自動化」「サンドボックス/デトネーションチャンバ=隔離環境で実行し振る舞いを観測（回避に注意）」「解析出力のハッシュ/URL/IPはIoCとして横展開確認に使う」が頻出です。ログ行やレポートを見たらどの源から何が言えるかを即断しましょう。
あるユーザから「添付ファイルを開いたが何も起きなかった」と報告があり、あなたはその添付を調べています。まず静的解析でハッシュを取り既知判定に照らしますが、ヒットしません（未知/亜種の可能性）。難読化されており構造だけでは意図が読めないため、サンドボックス（デトネーションチャンバ）で隔離実行します。レポートには、実行後に svchost32.exe という紛らわしい名前のファイルを生成（SHA-256 記録）、hxxp://malicious-update[.]example/gate.php というURLへビーコン、HKCU\...\Run に自身を登録、という振る舞いが並びました。ここで「ユーザ環境では何も起きなかったから無害」と結論するのは誤りです——高度なマルウェアはサンドボックス回避を行う一方、実ユーザ環境では条件が揃って発火することがあり、無反応＝安全ではないからです。むしろサンドボックスが明らかにした挙動こそが真の姿です。次の一手は、レポートのハッシュ・接続先URL/IP・Runキーの登録名をIoCとして抽出し、SIEMへ投入して「同じハッシュのファイルや同じURLへの通信が他のどの端末にあるか」を横断相関で洗い出すことです。ヒットした端末があればSOARのプレイブックで自動隔離やIPブロック、チケット起票を走らせ、一次対応を高速化します。ログ源の使い分けも重要で、Webプロキシ/DNSログはそのビーコンURLへの通信有無（アプリ/ネットワークの事実）を、OSログはRunキー登録やサービス化の痕跡を、CLI/監査ログは手動での横展開コマンドを示します——単一ログでは断片しか見えず、SIEMで束ねて初めて「侵害の全体像」になるのです。要は、サンドボックスで「検体が何をするか」を確定し、その出力をIoC化してSIEM/SOARで「どこまで広がったか」を確認し止める——この流れが動的解析とログ運用を結ぶ実務の背骨です。
| 源 | 主に分かること | 例 | 使いどころ |
|---|---|---|---|
| OSログ | ログオン・サービス・永続化 | Security 4625・Runキー登録 | 認証異常・自動起動を追う |
| アプリ/CLIログ | アプリ固有事象・実行コマンド | Webアクセスログ・`sudo`/監査ログ | 攻撃入力・手動操作を確認 |
| SIEM | 横断相関で全体像 | 複数ホストの認証失敗連鎖 | 単独ログで見えない攻撃を検知 |
| SOAR | プレイブックで対応自動化 | 不審IPの自動ブロック/隔離 | 反復的な一次対応を高速化 |
| サンドボックス出力 | 検体の振る舞い＝IoC | ハッシュ・接続URL/IP・生成ファイル | IoC化しSIEM/EDRで横展開確認 |
ひっかけ： 「サンドボックスで実行しても何も起きなかったので、その検体は完全に無害だ」は誤りです——高度なマルウェアはサンドボックス回避（仮想環境検知・時間差/条件付き発火）を行うため、無反応＝安全とは限りません。また「解析レポートのハッシュやURLは記録して終わり」も誤り＝それらはIoCとしてSIEM/EDRに投入し、他ホストの汚染確認とブロックに活かしてこそ価値が出ます。さらに、SIEMの相関は時刻同期（NTP）の整合が崩れると狂う点に注意。
3.5.3この節のまとめ
- OSログはログオン/永続化、アプリ/CLIログはアプリ事象/実行コマンド、SIEMは横断相関で全体像、SOARはプレイブックで対応自動化——源ごとに言えることが違う
- サンドボックス（デトネーションチャンバ）は隔離環境で検体を実行し振る舞いを観測する動的解析。無反応＝安全ではない（サンドボックス回避に注意）
- 解析出力のハッシュ/URL/IP/レジストリ変更はIoCとしてSIEM/EDRに投入し、他ホストの汚染確認とブロックに使う
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. ユーザが開いた添付ファイルをサンドボックス（デトネーションチャンバ）で実行したところ、紛らわしい名前のファイル生成、外部URLへのビーコン、HKCU\...\Run への自己登録が観測された。一方ユーザ端末では表面上何も起きていない。SOCアナリストの判断として最も適切なものはどれか。
Q2. 複数のホストにまたがって、短時間に多数の認証失敗が連鎖して発生している攻撃を検知したい。単独ホストのログだけでは全体像が見えない。この目的に最も適した仕組みはどれか。
Q3. SIEMが特定の不審IPからの攻撃を検知するたびに、アナリストが手作業で当該IPのブロック・端末隔離・チケット起票を繰り返しており、対応が追いつかない。この反復的な一次対応を高速化する仕組みとして最も適切なものはどれか。