ヘッダーfromをなりすましたメールを検知する方法を調べてみた

最近、Emotetが復活し、いろいろな企業から感染報告が上がっているなーと思い、こういったなりすましメールを簡単に検知できる方法がないのか少し調べてみました。

とりあえず思いついたのは、ヘッダーfromは簡単に書き換えられてしまうということなので、偽装が難しいエンベローブfromと突き合わせればいいんじゃないか、ということでした。

エンベローブfromとヘッダーfromの違い

エンベローブfromとヘッダーfromの違いについては以下のサイトで詳しく説明されていますが、簡単に言うと、

・エンベローブfrom・・・郵便物の封筒に書かれている差出人名
・ヘッダーfrom・・・封筒の中にある便箋にかかれている差出人名

となるようです。

<参考サイト>
「エンベロープFrom」と「ヘッダFrom」の違いとは?(ベアメール )
https://baremail.jp/blog/2021/05/25/1377/?utm_source=pocket_mylist

受信メールからエンベローブfromが確認できるのか

違いがわかったところで次に疑問におもったのが、エンベローブfromって受信メールのどこに書いてあるのかということです。

この点についても上記のベアメール のサイトに書かれていますが、エンベローブについては、残念ながら最後のメールサーバで削除されてしまうようです。
(最後のメールサーバがわざわざ封筒から便箋を取り出してくれるみたいですね。)

ただし、この時にメールサーバでエンベローブfromの値をヘッダのReturn-Path:に転記してくれるようですので、結論としては、受信メールを見るだけで確認できるようです。

Emotetのなりすましは検知がむずかしい

なんだ、じゃあなりすましメールの代表格であるEmotetのメールも簡単に見つけられるんじゃないの?と思いましたが

このEmotet自体は、

・感染した企業のメールサーバを使って社外にメールをばらまく
・フリーメールアドレスから送信する場合、ヘッダーfromのなりすましはしない

といった方式をとっているので、エンベローブfromとヘッダーfromを突き合わせても意味がない(なりすましメールかどうか判断できない)ようです。

Emotetがこのような方式をとっている理由としては、最近、企業にDMARKというなりすましメールを検知する方法が普及してきたからではないかと思われます。

DMARKはSPFやDKIMの結果によりメールの処理を変えるだけではない

いままで私は、DMARKの機能について、

・SPFやDKIMのチェック結果によってメールのフィルタリングを変える
・正しい送信元にレポートを送る

といったような管理機能だけが備わっていると考えていました。

しかしながら、よくよく調べてみると上記以外にも、ヘッダーfromの詐称がおこなわれていないか確認する機能があるようです。
具体的には、

・SPFと連携する場合には、エンベローブfromとの突き合わせ
・DKIMと連携する場合には、Dkim-Signatureのdタグとの突き合わせ

をするらしいです。(DKIMの方はちょっと私には難解です。。。)

このあたりの詳しい話は以下のサイトにに書かれていますので、興味がある方は読んでみるといいと思います。

<参考サイト>
大きく遅れる日本のなりすましメール対策:DMARC(ProofPoint)
https://www.proofpoint.com/jp/blog/email-and-cloud-threats/Japan-lags-far-behind-in-fighting-spoofed-emails-DMARC?utm_source=pocket_mylist

メールにおけるDKIMの仕組み(Carpe Diem)
https://christina04.hatenablog.com/entry/domain-keys-identified-mail

結論

メールヘッダーfromのなりすまし対策としてDMARKを利用すれば検知できるものの、残念ながらEmotet対策としての有効打にはならないようです。

今のところ、受け取ったメールの件名や本文や見てあやしいなあと感じたら、

・メーラーに表示されているヘッダーfromを確認する
・添付ファイルは開かない
・埋め込まれているリンクはクリックしない

を徹底するしかないかなさそうですね。

なお、Emotetメールの特徴は以下のサイトに書かれていますので、一度確認しておくことをお勧めします。

<参考サイト>
「Emotet(エモテット)」と呼ばれるウイルスへの感染を狙うメールについて(IPA)
https://www.ipa.go.jp/security/announce/20191202.html#L18

Slackからメール送信をさせてみた

前回、Jiraで登録された課題をSlackに通知する設定を行いました。

http://k2-ornata.com/jira-slack_connetion/

ただし、Slackをずっと見続けているわけではないですし、メールを使ってその後の処理を自動化したいといった思いもあり、Slackの全ての新規メッセージをメール通知する設定を行なってみました。

デフォルトのメール通知は限定的

メール通知の設定を変えるにはSlack(ブラウザ)の右肩のプロフィーフ画像をクリックして、「環境設定」を表示させます。

Slack – プロフィール画像

環境設定のポップアップ画面が表示されますので、左ペインの「通知」を選択し、まずは「通知のタイミング」を設定します。

1.通知のタイミング

デフォルトでは「ダイレクトメッセージ&メンション&キーワード」となっていますので、すべてをメール通知させたい場合は、「すべての新規メッセージ」を選択します。

Jira – 通知設定

次に画面を下にスクロールさせて「デスクトップでアクティブでない場合」のプルダウンを選択します。

2.利用者のアクティブ状況による通知設定

通常は「非アクティブの状態になったらすぐ」に設定されていますが、常に新規メッセージを通知したい場合は、「アクティブ状態でもモバイル通知をすぐに受け取る」を選択しておきます。

Jira – 通知設定

実際にメールが送信されるか試してみる

一つ注意点がありますが、メール送信はメッセージを追加した本人のメールアドレスには届かないようです。

したがって、このテストをするにはSlack参加メンバーが2名以上(2アカウント以上)必要です。

まずはどちらかのアカウントで、Slackに新しいメッセージ「アラート004〜006」を登録します。(実際にはJiraにて新規に作成した課題が「アラート004〜006」として登録されている。)

Slackでの新規メッセージ追加

するともう一方のアカウントのメールアドレスに、最後のメッセージ「アラート006」が登録された9:24から13分後の9:37に以下のとおり3つのメッセージがまとめて送信されてきました。

Slackからのメール通知内容

すべてのメッセージをリアルタイムでメール送信してくれる機能もあると良さそうですが、システム的な負荷やメール爆弾になってしまうことも考えると、これが限界なのかもしれませんね。

メール送受信時の文字コードについて(その1)

最近、メールを送受信する際の文字コードについて調べる機会があり、自分の理解を確実にする為にここにまとめてみることにしました。

したがって、もしかしたら勘違いしている点もあるかもしれないので、その時はご容赦ください。

1.文字コードとは?

そもそも文字コードとは何なのか?ここをちゃんと理解できている人は少ないのではないかと思います。

しかし、ここをちゃんと押さえておかないと、あとで必ず混乱してくると思います。

まず、文字コードというと以下の2つの意味があります。

a. 文字を表示する際などに実際にコンピュータが扱う数字(バイト表現)
b. 人間がコンピュータとやりとりする為に文字に割り当てられた番号(符号化文字)

2つの文字コード

おそらく今回このページを見ている人の多くは、b.の「符号化文字」のことを文字コードと考えているのではないかと思います。

この符号化文字は、特定の文字の集合(文字集合)の中で各文字が一意に特定されるように番号が割り当てられています。

なお、符号化文字については以下のサイトで詳しく解説されていますので、とても参考になると思います。

<参考サイト>
・わわわIT用語辞典(https://wa3.i-3-i.info/word15291.html)

次に、文字集合について少し解説します。

2.文字集合(文字セット)

世の中にはアルファベットやひらがな、漢字以外にも様々な言語の様々な文字があり、さらにはコンピュータで利用される制御文字などもあります。

それらの文字をどこまでセット(1つのまとまり)にするかで、様々な文字セット(文字集合)があります。

例えば代表的な文字集合は以下の通りです。

文字セット含まれる文字
ASCIIAmerican Standard Code for Information Interchangeの略
アメリカンなので米国で定義されたのでしょう
JIS X 0208いわゆるJIS第1第2水準漢字
JIS X 0213JIS X 0208に対してローマ数字や丸付き数字などを追加したもの
Unicode世界で使われる全ての文字を共通の文字集合で利用できるようにしようとしたもの
代表的な文字集合

なお、文字集合についてもっと詳しく知りたい人は以下のサイトが参考になると思います。

<参考サイト>
・ウィキペディア 文字集合(https://ja.wikipedia.org/wiki/文字集合)

ここまでで符号化文字と文字集合がざっくり理解できたと思いますので、次に符号化文字集合を説明します。

3.符号化文字集合

符号化文字集合とは、言葉通り、符号化された文字集合です。

したがって、代表的な符号化文字集合としては、「2.文字集合」にて表にまとめた ASCII や JIS X 0208、JIS X 0213、Unicode などがあります。

4.文字符号化方式(文字コードの一つ)

文字符号化方式には、ASCIIやEUC-JP、Shift_JIS、UTF-8などがあり、これらは普段コンピュータを利用している中で馴染みのある人が多いのではないでしょうか?

また、普通の人?はこれらを指して文字コードと言っていることが多いと思います。(実は私もそうでしたが、正確な表現ではなかったようです。)

今回の記事ではここまでにして、次回はメール送信時の文字コードについてまとめたいと考えています。