フィッシングなどのなりすましメールは増加しており、メール文面も違和感がなく差出人もなりすましているため見極めが困難です。なりすましの起こる原因と技術的な観点の対策を紹介します。
日々受信するメールの中に、身に覚えのないメールが届いている経験をされたことが一度はあるのではないでしょうか。こういった受信者の同意なく送られてくるメールをスパムメールと呼びます。商品の宣伝や出会い系、アダルト系などが中心になりますが、中には大手企業を名乗った偽サイトへ誘導し、個人情報を窃取しようとするフィッシングメールや、マルウェアに感染させて攻撃を行うための踏み台として利用しようとするマルスパムメールといった悪質なものもあります。
フィッシングなどのなりすましメールは毎月増加しており、フィッシング対策協議会によると、2022年6月のフィッシング報告件数は88,250件にも上ります。主な手口として、まず銀行やクレジットカード会社、電子決済会社などの実在する有名な組織を騙ってターゲットに送り付けます。本文には偽サイトへのリンクがあり、それをクリックしたユーザーを正規のサイトを模倣した偽サイトへ誘導します。そこでIDやパスワードなどを入力するように促し、その情報を盗み取ります。
スパムメールで、現在もっとも活動的なものの1つがEmotetへの感染を狙ったメールです。Emotetが2021年11月に攻撃活動を再開して以来、Emotetをインストールさせるためのファイルを添付したメールの報告件数も増加しています。実際に弊社のお客さま環境でも、Emotetに感染させることを目的としたメールが大量に届いています。手口としては、正規のメールに対して返信をなりすまし添付ファイル付きのメールをターゲットに送付し、添付ファイルを開かせるように誘導します。本文も業務上開封してしまいそうな文面が用いられており、それに騙され添付ファイルを開いてしまうと、マルウェアがダウンロードされ感染してしまいます。
いずれの場合も共通しているのは、本文の文面に違和感がなくなってきており、「なりすまし」という手法が用いられる点です。「なりすまし」とは、悪意のある第三者が差出人に実在する企業・団体や、業務でやり取りをしたことがある人物のメールアドレスを使用し、正規のものであるかのように信じさせることです。実際、フィッシング対策協議会の調査結果では、フィッシングメールの半数以上がなりすましメールとなっていました。
このように、本文の文面に違和感もなく、差出人もなりすましが行われているため、目視でなりすましメールを見破るのには限界があります。そこで、技術的な観点からメールのなりすましを見破る方法を「フィッシング詐欺に注意!なりすましメールの手口と調査方法とは」で紹介しています。しかし、日々の業務の中で不審なメールを毎回確認するのは時間的に難しく、また、メールに関する一定の知識も要求されるため、誰でもできるわけではありません。この記事では、Emotetにも利用されているなりすましメールに対して企業がどのような対策をとるべきかを、技術的な観点で紹介をしていきます。また利用者が行う対策方法は、フィッシング対策協議会のガイドラインを参考に行ってください。
なりすましはどうして起こるのか
なりすましメール対策を紹介する前に、なりすましが起こる原因について解説します。
電子メールは図1のような構造になっており、エンベロープとデータ部に分かれています。また、データ部はさらにヘッダーと本文(ボディ)に分かれています。
エンベロープにはエンベロープFromとエンベロープToがあり、このエンベロープToをもとにメールの配送が行われます。送信者アドレスは、エンベロープFromの他にもヘッダーの情報の1つであるヘッダーFromがあります。なりすまし対策を考えるうえでこの2つのFromはとても重要なものとなってくるため、その役割を以下に示します。
表1:2つのFromとその役割
From | 役割 |
---|---|
エンベロープFrom | ・SMTPのMAIL FROMコマンドで設定される送信者アドレスで、システムがメールの転送時に利用する ・メールソフトでは、Return-Pathヘッダーとして設定される |
ヘッダーFrom | ・メールソフト上で表示される送信者アドレスで、人間が差出人を判断するのに利用する |
その他にも、メーラーなどのメールソフトで表示されるヘッダーの情報には、以下のようなものがあります。
表2:ヘッダーのパラメータ
ヘッダー | 役割 |
---|---|
Return-path | ・送信先まで到達しなかった際に送信エラーが返されるアドレス ・SMTPコマンドのMAILの内容が設定される |
X-Original-To | ・送信者が本来送信した宛先アドレス ・転送された場合などは、自身のアドレスと異なることがある |
Delivered-To | ・メールサーバーが配信した先のアドレス ・転送などされていない場合は送信者が送信した宛先アドレスと一致し、X-Original-Toとも一致する |
Received(from) | ・1つ前に中継したサーバーのホスト情報(SMTPクライアント) ・サーバーを中継するたびに付加されるため、通信経路の確認をすることができる 上の方ほど受信先に近く、下の方ほど送信先に近い |
Received(by) | ・メールを中継したサーバーのホスト情報(ドメイン名、ホスト名) |
Received(for) | ・最終宛先(Toと同一) |
From | ・送信者のアドレス |
To/CC | ・宛先アドレス |
普段私たちがメールソフトでメールを見た際に表示される差出人は、ヘッダーFromに設定された送信者のアドレスになります。
しかし、メールの送信に利用されるSMTP(Simple Mail Transfer Protocol)およびそれに準拠したプロトコルでは、ヘッダーFromは自由に設定することができます。これを悪用して、スパムメールの送信者はヘッダーFromを実在する企業などの正規のメールアドレスに詐称し、ターゲットに送り付けます。そのため、メールの受信者には正規のメールアドレスから届いたように見え、なりすましと気付かずに偽サイトのリンクを踏んでしまったり、添付されているファイルを開いたりしてしまいます。
なりすましメール対策(送信ドメイン認証)
なりすましメール対策の1つに送信ドメイン認証があります。送信ドメイン認証では、受信したメールの送信者のドメインを検証し、詐称されていないか検査を行います。そのため、人の目では判別が難しいなりすましであっても検出することができます。以降で、送信ドメイン認証で用いられる3つの方式について解説します。
3-1.SPF(Sender Policy Framework)
SPFは、IPアドレスをもとに送信者のドメイン認証をする方式です。SPFを利用するには、送信側と受信側で対応している必要があります。
送信側ではあらかじめSPFレコードと呼ばれる検証用のデータをDNSサーバーに登録しておきます。SPFレコードには、ドメイン名とメールを配信するメールサーバーIPアドレスの組が記載されています。
メールを受信したメールサーバーは、ヘッダーFromではなくエンベロープに設定された送信元アドレスのドメイン名をもとに、DNSサーバーへSPFレコードを問い合わせます。この時、正規の送信元からのメールであれば送信元IPアドレスとSPFレコードに記載されているIPアドレスが一致し、SPFの検証に成功します。しかし、なりすましメールの場合は送信元IPアドレスがSPFレコードのものとは異なるため、検知することが可能です。
SPFは、DNSサーバーにSPFレコードを登録するだけなので比較的容易に導入することができる一方、問題点もあります。SPFは送信元メールサーバーのIPアドレスとSPFレコードに設定されたIPアドレスとを比較して検証を行うものでした。そのため、メール配信の経路上で転送が行われていた場合、送信元メールサーバーのIPアドレスが転送をしたメールサーバーのものに書き換わってしまい、正規のメールであってもSPFの検証に失敗してしまいます。
3-2.DKIM(DomainKeys Identified Mail)
もう1つの送信ドメイン認証の方式がDKIMです。SPFでは送信者のドメイン認証に、送信元メールサーバーのIPアドレスを利用していましたが、DKIMでは電子署名を利用します。DKIMもSPFと同様に送信側と受信側が対応している必要があります。
送信側では秘密鍵と公開鍵のペアを作成しDNSサーバーのTXTレコードに公開鍵を登録しておきます。メール送信時は、秘密鍵でメール本文およびヘッダーからデジタル署名を作成し、それをヘッダーに付与してから送信します。
メールを受信したメールサーバーは、送信者が付与したヘッダーをもとにDNSサーバーへ公開鍵を問い合わせます。その後、取得した公開鍵を使ってデジタル署名の検証をします。この時、正規の送信元からのメールであればデジタル署名の検証に成功します。しかし、なりすましメールやメールが途中で改ざんされていた場合は署名の検証に失敗するため、それにより検知が可能です。
DKIMは電子署名を用いることで、送信元ドメインの認証だけでなく本文やヘッダーの改ざんも検知できます。また、メール配信の経路上で転送が行われていても検証に影響はありません。一方で、送信側ではデジタル署名の設定や管理をする必要があり手間がかかります。また、送信時にはデジタル署名の付与をする必要があり、受信側でもデジタル署名の検証が必要となるためサーバーの負荷が高くなってしまいます。こういった経緯もあり、導入している組織が少ないのが実情です。
3-3.DMARC(Domain-based Message Authentication, Reporting and Conformance)
ここまでSPFとDKIMの仕組みについて述べてきました。SPFとDKIMのメリットと課題についてまとめると次のようになります。
表3:SPFとDKIMのメリットと課題
認証方式 | メリット | 課題 |
---|---|---|
SPF | エンベロープFromの正当性を検証できる | ・ヘッダーFromのなりすましは検証できない ・メール内容の改ざんは検知できない ・検証失敗時のメールの処理方法は受信側に委ねられている |
DKIM | 電子署名によりメール内容の改ざんを検知できる | ・送信元の正当性は完全には保証できない ・検証失敗時のメールの処理方法は受信側に委ねられている |
これらの課題を解消する方法としてDMARCがあります。DMARCは、これまで説明してきたSPFやDKIMのような新しい認証方式ではなく、これらの認証結果を利用して、送信者ドメインの認証を行います。DMARCではSPFやDKIMで認証したドメインとヘッダーFromが一致しているかを検証するため、ヘッダーFromのなりすましや送信元の正当性を高い精度で検証できます。また、DMARCでは送信者が受信者にメールの取り扱い方法を指定することができます。SPFやDKIMでは受信者に認証に失敗したメールの取り扱い方が任されていたため、なりすましメールであっても受信者の設定によっては受信されていました。そこで、DMARCでは送信者が認証に失敗したメールの取り扱い方法を定義したDMARCポリシーを用意し、受信者に認証に失敗したメールの処理方法を指定することができます。その他にも、DMARCレコードへ認証に失敗した場合にその結果を通知する宛先を設定することで、認証結果についての詳細なレポートとして受け取ることができ、DMARCポリシーの設定基準などの迷惑メール対策に役立てることができます。
送信側ではDNSサーバーのTXTレコードに、認証に失敗したメールの取り扱い方法などを定義したDMARCレコードを登録しておきます。なお、前述の通りDMARCではSPFとDKIMを利用するため、少なくとも片方が導入済みであることが前提条件となります。
メールを受信したメールサーバーは、SPFやDKIMで送信者のドメイン認証を行います。それと同時に、受信したメールのヘッダーFromからドメイン名を取得し、DNSサーバーにDMARCレコードを問い合わせます。この時、正規の送信元からのメールであればヘッダーFromとSPFやDKIMで認証したドメイン名が一致し、DMARCの検証に成功します。
しかし、なりすましメールの場合はSPFやDKIMの検証が失敗したり、ヘッダーFromと不一致となるためDMARCの検証に失敗します。検証に失敗した場合は、さきほど問い合わせたDMARCレコードのポリシーに則って受信処理をします。
DMARCはドメイン認証だけでなく、認証に失敗したメールの取り扱い方法を指定し、受けとったレポートをもとにポリシーの見直しができるため、SPFやDKIMと比べて高い精度でなりすましメールを検知できます。導入も、SPFやDKIMを利用するため、既にいずれかが導入済みであれば比較的容易に行えます。一方で、ドメインごとにレポートを受信するため管理負荷が高くなってしまいます。また、理由はさまざまありますが、日本プルーフポイント株式会社の調査によると、日経225企業 の25%しか導入していないという結果が出ています。そのため、DKIMと同様に、導入していても利用できないことが多いという問題もあります。
まとめ
冒頭でも述べたように、スパムメールは増加の一途をたどっており、なりすましや違和感のない文面によって見破るのが困難になってきています。実際にお客様環境にスパムメール届く機会が増加していますが、大半のフィッシングメールは文面に違和感がないか、あるいはなりすましメールと疑っていなければ見つけられないほど違和感が軽微になっています。
このような問題を解決する手段として送信ドメイン認証を紹介しました。送信ドメイン認証を利用することで、人の目では判断が難しいなりすましメールを検知でき、スパムメールの被害を軽減することができます。送信ドメイン認証として3つ紹介をしましたが、いずれか1つを導入するだけではなく、全てを導入することでより効果的な対策ができます。