responding-to-incidents

インシデントへの対応

あらゆるインシデントで重要となる問いは、攻撃者がどこまで到達したか、そしてまだ侵入しているかの2つです。マルウェア、CVE、根本原因など、それ以外は補足情報にすぎません。この2つに順番に答えれば、対応の道筋が見えてきます。

使用する場面

• ホスト、アカウント、またはクラウドテナントが侵害された疑いがある、または侵害が確認された場合
• ディスクイメージ、メモリキャプチャ、ログセットのフォレンジック分析
• 攻撃者が何をいつ行ったかを再構成する場合
• 影響範囲を特定し、封じ込めを判断する場合
• 事後検証レポートや、規制当局／顧客向けのインシデント説明を作成する場合

使用しない場面

• 復元したサンプルの詳細な分析 — analyzing-malware を使用します
• 既知のインシデントがない状態でのプロアクティブな検索 — hunting-threats を使用します
• アラートがインシデントに該当するかどうかを判断する段階 — triaging-security-alerts を使用します。トリアージで真陽性が確認されてから、対応を開始します
• 検知できたはずのルールを構築する場合 — engineering-detections を使用します
• インシデントが AWS 上で発生した場合（キーの漏えい、CloudTrail／GuardDuty） — investigating-aws-incidents を使用します。Microsoft 365／Entra の場合は investigating-m365-entra を使用します
• 解析対象のパケットキャプチャがある場合 — analyzing-network-traffic を使用します
• セキュリティ上の要素がないサービス停止 — これはセキュリティインシデント対応のスキルです

詳細分析スキルへの移行

特定の証拠タイプには、それぞれ専用の手順スキルがあります。このスキルでは範囲と順序を定めます。特定のアーティファクトタイプが中心になったら、以下のスキルを使用してください。

アーティファクト／対象	スキル
Volatility を使って解析する RAM キャプチャ（注入されたコード、メモリ内の認証情報、終了したプロセスの接続）	analyzing-memory-images
Microsoft 365／Entra ID の侵害：ディスクやメモリはなく、クラウドログ（UAL、サインイン、OAuth の許可）のみがある場合	investigating-m365-entra
Linux ホスト上で攻撃者がどのように永続化したかを特定する場合 — あらゆる初期化経路を体系的に調査します	analyzing-linux-persistence

重要な順序

Preparation → Detection & Analysis → Containment → Eradication → Recovery → Lessons Learned
                      ↑__________________|
                    (re-scope after every new finding)

常に破られ、最も大きな損失につながるルールが2つあります。

修復の前に保全してください。 再起動、再イメージ化、あるいは「とりあえずクリーンアップする」だけでも、メモリ、実行中のプロセス状態、未書き込みのログが失われます。一度失われると、範囲に関する問いには答えられず、攻撃者を排除できたかどうかも推測するしかありません。

一部だけを封じ込めてはいけません。 部分的な封じ込めは、攻撃者に気づかれたことを知らせ、見落とした箇所からアクセスを再確立する時間を与えます。まず範囲を特定し、その後、一度にすべてを封じ込めてください。ただし、進行中の被害がある場合は、被害を止めることを優先し、そのためのトレードオフを受け入れてください。

証拠の取得

揮発性の順序（RFC 3227 §2.1） — 上から順に収集します。

registers, cache
routing table, arp cache, process table, kernel statistics, memory
temporary file systems            ← tmpfs, /dev/shm: staging lives here
disk
remote logging and monitoring data relevant to the system
physical configuration, network topology
archival media

RFC では、メモリ、プロセステーブル、ネットワーク状態は、互いに順序付けせず同じ階層に置かれています。現代の実務では、これをさらに細分化しています。まずメモリをキャプチャしてください。プロセスやソケットを列挙するために実行するコマンドは対象のホスト上で実行され、まだキャプチャしていないメモリに影響を与えるためです。一時ファイルシステムの階層も飛ばさないでください。/dev/shm と tmpfs は一般的なステージング場所であり、いずれ誰かが提案する再起動を行うと消えてしまいます。

# Memory first, always, on a live suspect host
# Linux
sudo ./avml mem.lime                 # or LiME
# Windows
DumpIt.exe /OUTPUT mem.raw           # or winpmem
# macOS — do NOT reach for osxpmem. Rekall is archived, its last release was
# 2017 and Intel-only, and its kext-based approach is blocked by SIP and
# kext restrictions on Big Sur and later, and on all Apple Silicon. Full-RAM
# capture on a modern Mac realistically needs commercial tooling with the
# required Apple entitlements (e.g. Volexity Surge Collect). If none is
# available, do not stall the response: take process-scoped dumps and a
# comprehensive live-triage collection instead, and record in the incident
# log that full physical memory was not obtainable and why.

# Volatile state before you touch the disk
ps auxwwf; ss -tunap; lsof -n; last -Faiw; w
netstat -anob                        # Windows
Get-NetTCPConnection | Where State -eq Established

# Disk: image, do not analyze in place
sudo dd if=/dev/sda bs=4M conv=noerror,sync status=progress | tee image.dd | sha256sum
sudo ewfacquire /dev/sda             # E01 with built-in hashing, preferred
# Mount read-only, always via a write blocker or loop with `ro`
sudo mount -o ro,noexec,noload,loop image.dd /mnt/evidence

証拠保全の連鎖は、後から追加する書類作業ではありません。 収集時に以下を記録してください。

Evidence ID | Source host/serial | Collected by | UTC timestamp | Method/tool+version
SHA-256 at acquisition | SHA-256 at each transfer | Custodian at each handoff | Storage location

直ちにハッシュ値を計算し、コピーのたびに検証してください。また、原本を使って作業してはいけません。訴訟や規制上の問題に発展する可能性がある場合は、収集後ではなく収集前に法務部門を関与させてください。

トリアージのための収集

ほとんどのインシデントでは、ホストごとにディスク全体をイメージ化すると時間がかかりすぎます。まず大規模な対象に対して必要な情報を絞って収集し、その後、重要なホストのみをイメージ化してください。

# Windows: KAPE with the SANS triage target set
kape.exe --tsource C: --target !SANS_Triage --tdest E:\out --vhdx host01

# Linux/macOS: UAC or a scripted collection
./uac -p full /evidence/host01

# Cloud/EDR: pull the equivalent via API
# - EDR raw telemetry for the window ±7 days
# - Snapshot the volume before terminating any instance
aws ec2 create-snapshot --volume-id vol-xxx --description "IR-<case> preserve"

質問別のアーティファクト分析

すべてを処理するのではなく、質問に答えるアーティファクトを確認してください。

質問	Windows	Linux	macOS
何が実行されたか？	Prefetch、Amcache、ShimCache、SRUM、Sysmon E1	auditd、シェル履歴、/var/log/*、systemd ジャーナル	ExecPolicy DB、/var/db/、統合ログ
永続化の痕跡は？	Run キー、サービス、スケジュールされたタスク、WMI サブスクリプション、スタートアップフォルダー	cron、systemd ユニット、.bashrc、ld.so.preload、init	LaunchAgents/Daemons、ログイン項目、プロファイル
ラテラルムーブメントは？	4624 タイプ 3/10、4648、4672、RDP ログ、SMB 共有	auth.log、wtmp、.ssh/authorized_keys、known_hosts	Linux と同様に、ARD ログも確認
認証情報へのアクセスは？	LSASS ハンドル（Sysmon E10）、procdump を含む 4688	/etc/shadow の読み取り、ptrace、sshd のメモリ	キーチェーンアクセスログ
データのステージング／持ち出しは？	ごみ箱、$MFT のタイムスタンプ、アーカイブの作成、USN ジャーナル	find -newermt、大きな一時ファイル、履歴内の tar／zip	同様
アクセスされたファイルは？	$MFT、$UsnJrnl、LNK、JumpLists、シェルバッグ	atime（有効な場合）、auditd	FSEvents
ブラウザー／ダウンロードは？	履歴 DB、Zone.Identifier ADS	ブラウザープロファイル DB	隔離 DB（LSQuarantine）

# Memory analysis — where "are they still here" usually gets answered
vol -f mem.raw windows.pstree
vol -f mem.raw windows.malfind          # injected RWX regions
vol -f mem.raw windows.netscan
vol -f mem.raw windows.cmdline
vol -f mem.raw linux.bash               # recovered shell history

# Filesystem timeline
fls -r -m / image.dd > body.txt && mactime -b body.txt -d > timeline.csv
log2timeline.py --storage-file plaso.db image.dd && psort.py -o dynamic plaso.db > super.csv

クラウドおよび ID インシデント

現代の侵入のほとんどは、マルウェアではなく ID を経由して発生します。ホストだけで調査を終えないでください。

# AWS
aws cloudtrail lookup-events --lookup-attributes AttributeKey=Username,AttributeValue=<user>
# Look for: CreateAccessKey, AttachUserPolicy, AssumeRole chains, ConsoleLogin
# without MFA, GetSecretValue, CreateTrail/StopLogging (anti-forensics)

# Azure / Entra ID
# SigninLogs: impossible travel, legacy auth, unfamiliar device
# AuditLogs: "Add service principal credentials", "Consent to application",
#            "Update conditional access policy", role assignments

# Google Workspace / GCP
# Admin audit: OAuth token grants, mail forwarding rules, delegation changes

攻撃者が作成した OAuth アプリケーション、サービスプリンシパルの認証情報、メール転送ルールは、クラウドインシデントで最も見落とされやすい永続化の痕跡です。駆除の際には、これらを明示的に列挙してください。

タイムラインの再構築

タイムラインは、ほかのすべての作業が支える成果物です。

• すべて UTC に統一します。 取り込み時に時刻を正規化し、ソースのタイムゾーンを記録します。
• 各行のソースアーティファクトを引用します。 引用のないタイムラインは、根拠を示すことも再構築することもできません。
• 観測事実と推測を分けます。 「プロセスが作成された（Sysmon E1）」は観測事実で、「攻撃者がここに横展開した」は推測です。異なるものとして明示してください。
• タイムスタンプの偽装に注意してください。 $MFT の $STANDARD_INFORMATION は簡単に偽造できますが、$FILE_NAME はそうではありません。両者の不一致自体が発見事項です。
• 最も早い侵害の証拠を特定したら、さらに前まで調べます。 最初に見つけたものが、実際に最初に起きたこととは限りません。

UTC Timestamp        | Host    | Event                                  | Source            | O/I
2026-07-12 03:14:02  | WEB01   | POST /upload.aspx 200, 1.2MB, IP x.x.x.x| IIS log           | O
2026-07-12 03:14:40  | WEB01   | w3wp.exe → cmd.exe → whoami            | Sysmon E1         | O
2026-07-12 03:15:05  | WEB01   | Initial access via upload vuln          | correlation       | I

スコープの特定

次の点に答えるまでは封じ込めを行わないでください。そうしないと、誤った範囲を封じ込めてしまいます。

1. 最初の侵害対象 — 最初に侵害されたホスト／アカウントと、初期アクセス経路
2. 攻撃者が取得できた可能性のあるすべての認証情報 — 侵害されたホストからキャッシュ、入力、保存、またはアクセスが可能だったものはすべて無効とみなします
3. それらの認証情報が使われたすべてのホスト — EDR アラートだけでなく、認証ログから横展開をたどります
4. 永続化の痕跡の一覧 — ホストごと、ID ごとに明示的に記載します
5. データの露出 — アクセス可能だったもの、アクセスされたもの、外部に持ち出されたもの

スコープは広がります。新しいホストが見つかったら、そのホストについて手順 2 からやり直してください。

封じ込めと駆除

# Contain without destroying evidence
# - Network-isolate via EDR rather than powering off (preserves memory)
# - Revoke sessions and tokens, not just passwords: OAuth grants, refresh
#   tokens, Kerberos TGTs, API keys, SSH keys
# - Disable rather than delete accounts, so the artifacts survive

# Eradication checklist, per compromised identity
#   password reset, MFA re-enrollment, session/token revocation, key rotation
# For AD-wide compromise: krbtgt reset twice, ~10h apart

攻撃者が SYSTEM／root 権限を得ていた場合は、クリーンアップではなく再イメージ化してください。完全に把握できていないホストからインプラントを除去したと証明することはできません。誤った判断の代償は、調査全体をやり直すことです。

復旧の条件 — 次のすべてを満たすまで復元しないでください。初期アクセス経路が塞がれていること、特定された永続化の痕跡がすべて除去されていること、認証情報がローテーションされていること、観測された TTP に対する検知が用意されていること。復元したシステムは、少なくとも通常の業務サイクルが一巡するまで、検知感度を高めて監視してください。

却下すべき合理化

• 「今すぐ再イメージ化して、後で調査しましょう。」 再イメージ化すると、そのホストの調査はそこで終わります。
• 「アラートが出たホストは1台だけなので、影響を受けたのも1台だけです。」 アラートが示すのは検知範囲であり、攻撃者の活動範囲ではありません。
• 「パスワードをリセットしたので、このアカウントは安全です。」 リフレッシュトークン、アプリパスワード、既存のセッションは、パスワードをリセットしても有効なままです。
• 「EDRが検知していたはずです。」 今確認している事象は検知されませんでした。検知の抜けを想定し、独立したアーティファクトソースで裏付けてください。
• 「AVが駆除しました。」 AVが削除するのはファイルです。永続化の仕組み、認証情報、二つ目のインプラントは削除しません。
• 「ログが残っているのは過去7日間だけなので、分かりません。」 報告書ではスコープ上の制限として記載してください。「7日前より前には何も起きていない」と暗黙に見なしてはいけません。
• 「確信が持てるまでは記録しないでおきましょう。」 その時点で記録したメモが証拠になります。記録を遅らせず、不確実性を明示してください。

成果物

• エグゼクティブサマリー — 何が起きたか、影響、現在の状況を平易な言葉で記載
• タイムライン — UTC、情報源を明記し、観測事項と推定事項を区別
• スコープ — ホスト、アカウント、データと、それぞれを含めた根拠および除外した根拠
• 根本原因 — 初期アクセス経路と、機能しなかった対策
• 実施した対応 — 封じ込め、根絶、復旧と、そのタイムスタンプ
• 証拠台帳 — 項目、ハッシュ、保管の連鎖
• 情報の欠落 — 特定できなかった事項とその理由（ログの保持期間、EDRなしなど）
• 推奨事項 — 優先順位を付け、ナラティブで明らかになった具体的な失敗にそれぞれ結び付ける

事後レビューでは個人を責めず、対策やプロセスの失敗を分析します。原因として個人の名前を挙げる事後レビューは、次のインシデントで沈黙を招きます。

ATT&CK のカバレッジ

secskills-core/ttp-index.json から生成 — このファイルを編集してから、 python3 scripts/sync_attack.py --write を実行してください。レポートに記載する前に、ID が現在の ATT&CK リリースと一致することを再確認してください。

永続化（TA0003）

• T1098.001 追加のクラウド認証情報 — exploiting-cloud-platforms も参照
• T1098.002 追加のメール委任アクセス許可

防御回避（TA0005）

• T1070 インジケーターの削除
• T1070.001 Windows イベントログの消去 — hunting-threats も参照
• T1070.006 タイムスタンプの改ざん
• T1562 防御の妨害 — hunting-threats も参照
• T1562.001 ツールの無効化または変更 — hunting-threats も参照

収集（TA0009）

• T1114 メールの収集

影響（TA0040）

• T1485 データの破壊
• T1486 影響を与えるためのデータ暗号化 — analyzing-malware も参照
• T1489 サービスの停止
• T1490 システムの復旧の妨害 — hunting-threats も参照

これらの検知コンテンツについては、engineering-detections を参照してください。プロアクティブな検索には hunting-threats、侵害後の対応には responding-to-incidents を参照してください。

参考資料

• analyzing-malware — スコープ設定と IOC に役立つサンプル分析
• hunting-threats — ここで見つかった TTP を用いたプロアクティブな検索
• engineering-detections — このインシデントで明らかになった検知の抜けを解消
• NIST SP 800-61r3（インシデント対応）、SP 800-86（フォレンジック技術）、RFC 3227
• 中核的なツール群としての Volatility 3、Plaso/log2timeline、KAPE、Velociraptor、TheHive