###### tags: `mail`

# なりすましメール調査の知識

## SPF
Sender Policy Framework
smtp.mailfrom（別名エンベロープ）のドメインで公開している SPF の値（IPアドレスのリスト）と SenderIP が一致するかを認証する。
認証成功なら意図した送信サーバから送信されたメールであることが保証される。

https://salt.iajapan.org/wpmu/anti_spam/admin/tech/explanation/spf/

### キーワード
smtp.mailfrom：
SMTP プロトコル上でクライアントーサーバが会話する時に送信元を名乗る時のコマンド（で名乗ったFROMアドレス）。

Return-Path：
smtp.mailfrom はプロトコル上で使用される値なのでメールクライアントがメールヘッダに書いて送ることはしない。ただし、サーバ側で Mailer Daemon の場合などの返信先として Return-Path ヘッダを追加する。この時に使用されるのが smtp.mailfrom。

エンベロープ：
Return-Pathのドメインのことだと思えばいい。

SenderIP：
送信時の SMTP サーバの IP アドレス。Received ヘッダで確認できる。

### 解析に使用するヘッダ
Received ヘッダ：
SenderIP を割り出すのに使用する。

Authentication-Results ヘッダ：
SPF/DKIM/DMARC/COMPAUTH に関する認証結果を格納するヘッダ。SPF では smtp.mailfrom, SenderIP, 認証結果を確認することができる。

Received-SPF ヘッダ：
ここにも SPF に関する認証結果が格納されている。認証に使用したドメイン（実質的に smtp.mailfrom）、SenderIP, 認証結果を確認できる。

### 解析に使用しないヘッダ（主要なもののみ）
From ヘッダ：
From ヘッダで書かれたメールアドレスや表示名は認証には全く寄与しない。

### 解析に便利なツール

https://emailstuff.org/spf
入れ子になった include も再帰問い合わせして全部表示してくれる

### SPF の確認
当該ドメインの DNS TXT レコードで v=spfv1 から始まるレコード（spf2.0 は若干違う）

コマンド例：

$ dig txt <domain> +short | grep spf

### 認証結果
ここが分かりやすい
https://salt.iajapan.org/wpmu/anti_spam/admin/tech/explanation/spf/#60

* SenderIP が SPF の IPアドレスリストに含まれている場合
* Pass になる

* SenderIP が SPF の IPアドレスリストに含まれていない場合
* SPF に ?all がある場合：Neutral
* SPF に ~all がある場合：SoftFail
* SPF に -all がある場合：Fail

* 当該ドメインに SPF レコードがない場合
* None になる

* 当該ドメインの SPF レコードの書式が間違っている場合
* PermError になる

### よくある勘違い

#### Q：SPF=Pass だからなりすましメールではない
SPF は smtp.mailfrom と SenderIP を見ているだけで、From ヘッダは見ていない。From ヘッダがどう書き換えられていようと認証結果には影響ない。

#### Q：From ドメインと Return-Path のドメインが不一致なら Fail でないの？
From ドメインは見ていない。
Return-Path はエンベロープであり smtp.mailfrom。このドメインの SPF を見に行っている。

#### Q：SPF レコード見当たらない
TXT レコードを引いていますか？

## DKIM
DomainKeys Identified Mail
指定したヘッダの組み合わせで生成したハッシュ、本文のハッシュで電子署名を付けたメール。
受信側で同じヘッダの組み合わせでハッシュを生成する。
これとドメインの公開鍵を使って電子署名から取り出したハッシュが一致するかを検証する。
認証成功なら指定したヘッダや本文が改ざんされていないことが保証される。

https://salt.iajapan.org/wpmu/anti_spam/admin/tech/explanation/dkim/

### キーワード

DKIM-Signature ヘッダ：
送信者が電子署名を行った際に使用したヘッダの組み合わせやアルゴリズム、生成されたハッシュが書かれている。電子署名の値もこのヘッダに書かれる。

セレクタ：
DKIM で使用する公開鍵の値は単純な DNS TXT 問い合わせでは取得できない。
DKIM-Signature ヘッダに使用しているセレクタの値が書かれており、これを利用して DNS クエリを作る。

### 解析に使用するヘッダ

DKIM-Signature ヘッダ：
このあたりのタグ（パラメータ）を覚えておくとよい。
d　　公開鍵を問い合わせるドメイン
s　　セレクタ
h　　ハッシュ生成に使用されたヘッダの組み合わせ
b　　電子署名データ
bh　 本文から生成したハッシュ

Authentication-Results ヘッダ：
DKIM の結果はこのヘッダに書かれる。

### 解析に便利なツール

https://dmarcian.com/dkim-inspector/
セレクタ（DKIM-Signature ヘッダの s タグ）を確認してから利用しましょう。

### DKIM-ADSP
From ヘッダのドメインと d タグのドメインが一致するかを確認するための仕組み。
見たことがないので説明できない。

### DKIM の確認
当該ドメインとセレクタを使い、フォーマットした FQDN に DNS TXT レコードを問い合わせる。
セレクタが必要なので当該ドメインからの DKIM-Signature ヘッダ付きメールを受け取らないと確認できない。

コマンド例：

$ dig txt <selector>._domainkey.<domain> +short

### よくある勘違い

#### Q：DKIM-Signature に認証結果が書かれていない
認証結果は Authentication-Results ヘッダに書かれます。

#### Q：DKIM=Pass だからメッセージは改ざんされていない
指定したヘッダの組み合わせで生成した電子署名なので、指定していないヘッダは改ざんされている可能性を否定できない。

#### Q：DKIM レコード見当たらない
TXT レコードを引いていますか？
\<selector>._domainkey.\<domain> の形式で問い合わせていますか？

#### Q：ニュースで話題になっているこの企業の DKIM を確認したいんだが
まずはその企業から DKIM-Signature 付きのメールを受け取ってください。
セレクタが分からないと確認しようがないです。

## DMARC
Domain-based Message Authentication, Reporting, and Conformance
自分の管理するドメインが成りすましメールに使われていないかを知るための仕組み。
SPF/DKIM で認証失敗が発生した場合の受信サーバに於いての当該メールの処理方法（破棄など）や、失敗時の連絡先を公開しておく。
SPF/DKIM と異なり From ヘッダとエンベロープの違いを確認するので、成りすまし有無の判断にも使える。

https://salt.iajapan.org/wpmu/anti_spam/admin/tech/rfc/rfc7489/

### キーワード

### 解析に使用するヘッダ
Authentication-Results ヘッダ：
dmarc の結果と判断された action がここに書かれる。
action は基本的には送信サーバから取得した DMARC の p の値が fail の場合の action となるが、受信サーバ側で勝手に判断しているケースも見受けられる模様。

### 解析に便利なツール
https://dmarcian.com/dmarc-inspector/

### DKIM の確認
当該ドメインに _dmarc を付けて DNS TXT レコードを問い合わせる。

コマンド例：

$ dig txt _dmarc.<domain> +short

## メール検証技術
SPF：エンベロープ（return-pathとして記録される。smtp.mailfrom）のドメインの SPFレコードと SenderIP が一致するか検証し、意図した送信者か確認。
DKIM：送信者指定のヘッダや本文などで生成したハッシュと電子署名から公開鍵で取り出せるハッシュで検証し改ざん有無の確認。
DMARC：FROMヘッダとエンベロープのドメインで検証する。違うなら fail。

## 確認ツール達
SPFレコードの確認：https://emailstuff.org/spf
DKIMレコードの確認：https://dmarcian.com/dkim-inspector/　（Selector は dkim-signature の s= の値を指定する）
DMARC設定の確認：https://dmarcian.com/dmarc-inspector/
SPF/DKIM/DMARC の結果およびメール配信経路の確認：https://toolbox.googleapps.com/apps/messageheader/

## 解釈例
SPF=Pass の意味するもの：送信者の IP アドレスが意図したものかどうか。FROM ヘッダとエンベロープが一致するかは気にしていない。
DKIM=Verified の意味するもの：送信した時と内容が変わっているかどうか。FROMヘッダとDKIMで公開鍵を問い合わせるドメインが一致するかは気にしていない。
DMARC=fail の意味するもの：SPF/DKIM で失敗したか、FROM ヘッダとエンベロープが違う（←なりすましを意味しない）。
DMARC=Pass の意味するもの：なりすましの可能性はかなり低いんじゃないかな。

## O365で付与されるメールヘッダの意味
https://docs.microsoft.com/ja-jp/microsoft-365/security/office-365-security/anti-spam-message-headers?view=o365-worldwide

## How to Analyse Emails?

Before learning how to conduct an email analysis, you need to know the structure of an email header. Let's quickly review the email header structure.

| Field | Details |
| -------- | -------- |
| From | The sender's address. |
| To | The receiver's address, including CC and BCC. |
| Date | Timestamp, when the email was **sent**. |
| Subject | The subject of the email. |
| Return Path | The return address of the reply, a.k.a. "Reply-To". If you reply to an email, the reply will go to the address mentioned in this field.
| Domain Key and DKIM Signatures | Email signatures are provided by email services to identify and authenticate emails. |
| SPF | Shows the server that was used to send the email. It will help to understand if the actual server is used to send the email from a specific domain. |
| Message-ID | Unique ID of the email. |
| MIME-Version | Used MIME version. It will help to understand the delivered "non-text" contents and attachments. |
| X-Headers | The receiver mail providers usually add these fields. Provided info is usually experimental and can be different according to the mail provider. |
| X-Received | Mail servers that the email went through. |
| X-Spam Status | Spam score of the email. |
| X-Mailer | Email client name. |

## Important Email Header Fields for Quick Analysis

Analysing multiple header fields can be confusing at first glance, but starting from the key points will make the analysis process slightly easier. A simple process of email analysis is shown below.

| Questions to Ask / Required Checks | Evaluation |
| -------- | -------- |
| Do the "From", "To", and "CC" fields contain valid addresses? | Having invalid addresses is a red flag. |
| Are the "From" and "To" fields the same? | Having **the same** sender and recipient is a red flag. |
| Are the "From" and "Return-Path" fields the same? | Having **different** values in these sections is a red flag. |
| Was the email sent from the correct server? | Email should have come from the official mail servers of the sender. |
| Does the "Message-ID" field exist, and is it valid? | Empty and malformed values are red flags. |
| Do the hyperlinks redirect to suspicious/abnormal sites? | Suspicious links and redirections are red flags. |
| Do the attachments consist of or contain malware? | Suspicious attachments are a red flag. File hashes marked as suspicious/malicious by sandboxes are a red flag. |

## Analysis tools and sites
### Tools
amlanalyzer

### Sites
Simple email reputation
https://emailrep.io/

| Tool | Purpose |
| ---- | ---- |
| VirusTotal | A service that provides a cloud-based detection toolset and sandbox environment. |
| InQuest | A service provides network and file analysis by using threat analytics. |
| IPinfo.io | A service that provides detailed information about an IP address by focusing on geolocation data and service provider. |
Talos Reputation | An IP reputation check service is provided by Cisco Talos. |
| Urlscan.io | A service that analyses websites by simulating regular user behaviour. |
| Browserling | A browser sandbox is used to test suspicious/malicious links. |
| Wannabrowser | A browser sandbox is used to test suspicious/malicious links. |