【実務編:第24回】ヘッダ分析と IOC抽出

2025年9月19日

要点サマリ（先に結論）

ヘッダ分析：Authentication-Results と Received ヘッダを最初に見る。SPF/DKIM/DMARC の結果は Authentication-Results に出る。送信元IPは外側（下側）の Received をたどる。
IOC抽出：IoC（Indicator of Compromise）とは、サイバー攻撃を受けた際に残る指標を指し、一般的には「セキュリティ侵害インジケーター」や「侵害指標」と呼ばれます。
IoCで取得できる情報の例としては
マルウェアのファイル名
通信先のURL
IPアドレス
ドメイン
エクスプロイトコード
などが挙げられます。これらの情報は、データ侵害が発生しているかの判断材料になるだけでなく、サイバー攻撃に使用されたツール・手法を明らかにするための手掛かりとしても有用です。IoCは企業のサイバーセキュリティにおいて不可欠な要素であり、攻撃からの防御や迅速な対応において重要な役割を果たします。添付ファイルはハッシュ（SHA256推奨）を算出。メール本文のURLは正規表現で抽出。送信元IPはReceivedヘッダの送信側IPを使う。
次のアクション：IOCをVirusTotal/MISP/自社TIと照合 → SIEM/EDRで横展開検索 → 隔離・削除。

1) 生のメールヘッダ（サンプル） — まずはこれを読む

下は実務で見るような 簡略化した生ヘッダ の例です（実際はもっと長く Received が複数行になります）。

From: "Payroll Dept" <payroll@pay-secure.com>
To: y.kimura@company.co.jp
Subject: Invoice 2025/10
Message-ID: <CAFf1+xyz@mail-198-51-100-77.provider.net>
Date: Wed, 8 Oct 2025 00:05:20 +0000
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_Part_123456_abcdef"

2) ヘッダ分析の手順（順を追って）

手順 A — 全体をざっと見る（所要時間：30秒）

Authentication-Results を探す（メール受信サーバが付与していることが多い）。
Received を下から上へ（最初に外部から来た記録を探すため）たどる。
From / Return-Path / Message-ID を確認。

チェックポイント（最初に見る）

Authentication-Results に spf=pass|fail|neutral / dkim=pass|fail / dmarc=pass|fail があるか？
一番外側の Received に書かれた IP（例上：198.51.100.77）は自社の許可送信元か？
Return-Path と From のドメインが一致するか（なりすましのヒント）？

手順 B — 送信元IPを精査（所要時間：1〜3分）

Received ヘッダの 一番下（または下寄り） に外部送信者のIPがあることが多い。上サンプルでは 198.51.100.77 が外部送信元。
そのIPの逆引き（PTR）やWHOISをチェック（コマンド例を下に示します）。

Linux / macOS コマンド例

# PTR（逆引き）
dig -x 198.51.100.77 +short

# WHOIS（所有者情報）
whois 198.51.100.77

見るべき点

IPが公的にメールを出すプロバイダ（SendGrid, AWS, etc.）か？それとも個人ISPやホスティングか？
プロバイダのIPレンジが送信ドメインのMXやSPFに含まれているか（次でSPF確認）。

手順 C — SPF の確認（所要時間：1〜3分）

ヘッダに spf=... が出ている場合は結果を確認（pass/fail）。
自分でSPFレコードを確認するには DNS TXT を取得：

dig +short TXT pay-secure.com
# 例出力: "v=spf1 include:spf.protection.example -all"

ヘッダの送信元IP（198.51.100.77）が SPF レコードで許可されているかを確認：
- v=spf1 include:xxxxx -all の include チェーンを展開して該当IPが範囲に入るか判断する（手作業は面倒なので後述のSPFチェックツールやオンラインを使うことが多い）。

解釈例

spf=fail → ドメインがその送信IPを許可していない（疑わしい）
spf=pass → 送信元はドメインの指定通り（ただし From ヘッダが偽装されている可能性はある）

手順 D — DKIM の確認（所要時間：1〜5分）

ヘッダに dkim=pass header.d=pay-secure.com header.s=selector1 があるか。selector1 と pay-secure.com を取り出す。
公開鍵は selector1._domainkey.pay-secure.com の TXT レコードに格納されている。確認用コマンド：

dig +short TXT selector1._domainkey.pay-secure.com
# 例出力: "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."

DKIM 検証は受信メールの本文とヘッダを使って署名を検証する操作で、受信サーバ（MTA）がやるもの。ヘッダの dkim=pass があれば署名検証は通っている。自分でも検証したければ opendkim-testmsg や dkimpy 等を使う。

解釈

dkim=pass → 送信ドメインの署名が有効（なりすまし保護に強い）
dkim=fail → 署名が壊れているか、改竄されているか、偽署名

手順 E — DMARC の確認（所要時間：1分）

Authentication-Results に dmarc=pass|fail が出る。
自分でも _dmarc.pay-secure.com の TXT を確認：

dig +short TXT _dmarc.pay-secure.com
# 例出力: "v=DMARC1; p=quarantine; rua=mailto:dmarc-rua@pay-secure.com"

解釈

dmarc=fail かつ p=reject/quarantine が設定されているのにメールが受信されている場合は、受信側がルールを緩めている可能性がある＝注意。

手順 F — ヘッダの詐称パターンに注意

From: と Return-Path: が異なる（Return-Path が本当の送信元を示すことが多い）
Message-ID のドメイン部が怪しい（例：@mail-198-51-100-77.provider.net）
複数の Received を辿って出所がプロキシ経由 / 中継業者でないか確認

3) IOC抽出（添付ファイルハッシュ / URL / 送信元IP）手順

A — 添付ファイルのハッシュ取得（SHA256推奨）

ステップ（安全に扱う）

添付をサンドボックス用の隔離環境に保存する（本番環境のPCで直接開かない）。
Linux マシンで SHA256 を計算：

# 保存したファイルを hash
sha256sum invoice_202510.xlsm
# 例出力:
# ab12cd34ef56...  invoice_202510.xlsm

そのハッシュを VirusTotal / 自社TI / MISP に照会（既知マルウェアかどうか）
- （社内でAPIキーがあるなら vt.py や vt-cli を使う）

注意点

ファイル名だけで判断しない（攻撃者はわざと正規名を使う）
ハッシュ照会で malicious になれば高信頼のIOC

B — メール本文からURLを抽出

基本コマンド（テキスト保存されている場合）

# メール本文を text.txt に保存しておく
# 簡単なURL抽出（http/https）
grep -oE 'https?://[^ \"\<\>]*' text.txt | sort -u

正規表現の例（より厳密）

# 複雑なURLも拾う
perl -nle 'print for /https?:\/\/[^\s"\'\<\>]+/g' text.txt | sort -u

抽出後の確認

抽出したURLのドメインを whois や dig で確認（新規登録日をチェック）
URL を直接ブラウザで開かない（安全なサンドボックスで開く）
URL の短縮リンクは展開して最終ドメインを確認する（curl -I -L で HEAD 取得して Location を確認）

curl -I -L -sS "http://bit.ly/xxx" | sed -n '1,10p'

C — 送信元IPの抽出

送信元IP は Received ヘッダの外側（下の方）で見つかる（上のサンプルなら 198.51.100.77）。
そのIPについては PTR / WHOIS / RBL（ブラックリスト）チェックを行う。

RBL (Realtime Blackhole List) 確認例

# rbl check (簡易)
dig +short 77.100.51.198.bl.spamcop.net A
# 返り値が空でなければリスト登録されている可能性

4) 具体的な「調査テンプレート」 — そのまま使えるチェックリスト

ヘッダを全件保存（.eml 形式）して証拠保全。
Authentication-Results を確認（SPF/DKIM/DMARC の結果メモ）。
Received を下から上へ辿り、最初に外部と通信したIP を特定 → PTR / WHOIS / RBL を確認。
Return-Path と From を比較（不一致なら警戒）。
添付を隔離環境に保存し、SHA256 を算出 → TIに照会。
本文から URL を抽出 → 短縮URLは展開 → サンドボックスで解析。
抽出した IOC（hash, url, ip, domain）を SIEM / EDR に入れて横展開検索（下にクエリ例）。
結果に応じて「隔離 / 全社削除 / ユーザー通知 / EDR隔離」等のアクションを実施。
最後に調査ログ・スクリーンショットを報告書に保存。

5) SIEM / EDRでの横展開検索例（実務でよく使うクエリ）

Splunk — 添付ファイルハッシュ（例）

index=mailgw OR index=edr
| search attachment_hash="ab12cd34ef56*"
| stats count by host, user, _time

KQL（Azure Sentinel）— 抽出したURLでプロキシログ検索

ProxyLogs
| where Url contains "login-payments-verify.xyz"
| summarize count() by ClientIP, UserPrincipalName, bin(TimeGenerated, 1h)

EDR（概念） — ハッシュで端末検索

# 製品によってAPI/GUIが違う。概念：
GET /api/v1/file/search?hash=ab12cd34ef56...
-> returns list of endpoints which executed/received this file

6) よくある落とし穴と注意点

ヘッダは改竄されることがある：受信サーバが付与した Authentication-Results は信用度が高いが、送信元の Received は中継を経ると細工される可能性あり。常に複数ヘッダと相関すること。
短縮URL / リダイレクトに要注意：最初のドメインは正規サイト風でも最終遷移先が悪性の場合がある。必ず展開して最終ホストを確認。
ハッシュは一意だが可変：マクロ付き Office は実行時に内容が変わることがあり、ハッシュが異なることがある（ファイルのメタ情報等）。複数の指標（命令列、ドメイン、IP）で判定する。
SPFがpassでも安心はできない：送信者が正規メール送信サービスを使っている可能性がある（攻撃者がそのサービスを悪用）。DKIMの有無・Fromドメインとの整合性も見る。

7) 参考プレイブック（短縮版：不審メール検知時の即実行フロー）

受信メールを隔離（メールGW）。証拠として .eml を保存。
ヘッダ分析（上の手順A〜Fを迅速に実行） → 送信元IP / SPF/DKIM/DMARC 結果を記録。
添付の SHA256 を算出 → TIで照会。
抽出した URL をプロキシログで検索、開封済みユーザーの特定。
開封ユーザーがいれば EDRで端末を隔離・プロセス/ネットワークログを取得。
IOC を SIEM/EDR に投入して横展開。
結果に応じて全社通知 or 関係者限定注意喚起を実施。
事後：検知ルールに IOC を登録 / SOAR で自動化プレイブックを作成。

8) 追加ツール（便利なもの）

dig, whois — DNS / レンジ確認
opendkim-testkey, opendkim-testmsg, dkimpy — DKIM 検証
sha256sum / md5sum — ファイルハッシュ
curl -I -L — 短縮URL展開（HEAD確認）
VirusTotal / MISP / 自社TI — ハッシュ/URLの照会
SIEM（Splunk / Sentinel）・EDR（CrowdStrike/MS Defender/SentinelOne） — 横展開検索

よかったらシェアしてね！

URLをコピーしました！

URLをコピーしました！

コメントするコメントをキャンセル

コメントを投稿するにはログインしてください。

【実務編:第24回】ヘッダ分析 と IOC抽出