皆さん、こんにちは。

業務改善を行うIT・業務コンサルタント、高橋です。

さて、今日は実在の人物や組織になりすましたメールを送り付け、添付ファイルを開くことでウイルスに感染する『Emotet（エモテット）』に関する注意喚起です。

なりすましメールでの感染に注意

JPCERTコーディネーションセンターによると、このマルウエア『Emotet（エモテット）』は主にメールに添付された『Word形式のファイル』を実行し、コンテンツの有効化を実行することで感染に繋がることが分かっているそうで、実際に感染に繋がる可能性のあるメールの例は以下のようになっているとされています。

・メールアカウント名＜実際の送信元アドレス＞

・RE：実際に送受信したメールの件名

・メールの受信者名

・Word形式の添付ファイル

・メール本文

・感染したメールアドレス

・実際に受信したメール本文

・実際に受信したメールに含まれる履歴

このような感じになっているようですが、確かに実際にやりとりしたメール履歴からの返信メールを装われていると表面的には疑わないかと思います。

これは、マルウエア『Emotet（エモテット）』が窃取した情報などを元に独自に作成されているものに加え、実際の組織間のメールのやりとりの内容を転用することで、感染元から送信先への返信を装うものがあるとされているため、注意が必要です。

そして、添付ファイルにはコンテンツの有効化を促す内容が記載されているようで、有効化してしまうと『Emotet（エモテット）』がダウンロードされてしまいます。

※　Wordの設定によっては有効化の警告が表示されずに『Emotet（エモテット）』がダウンロードされる場合もあります。

この『Emotet（エモテット）』に感染した場合、次のような影響が発生する可能性があるとされています。

・端末やブラウザに保存されたパスワード等の認証情報が窃取される

・窃取されたパスワードを悪用され SMB によりネットワーク内に感染が広がる

・メールアカウントとパスワードが窃取される

・メール本文とアドレス帳の情報が窃取される

・窃取されたメールアカウントや本文などが悪用され、Emotet の感染を広げるメールが送信される

また、『Emotet（エモテット）』の感染予防対策などとしては、次のようなことを検討します。

・組織内への注意喚起の実施

・Word マクロの自動実行の無効化 ※

・メールセキュリティ製品の導入によるマルウエア付きメールの検知

・メールの監査ログの有効化

・OS に定期的にパッチを適用 (SMBの脆弱性をついた感染拡大に対する対策)

・定期的なオフラインバックアップの取得（標的型ランサムウエア攻撃に対する対策）

※ Microsoft Office Word のセキュリティセンターのマクロの設定で、「警告を表示してすべてのマクロを無効にする」を選択する。

もし感染してしまった場合、

・感染した端末のネットワークからの隔離

・感染した端末が利用していたメールアカウントのパスワード変更

・ 組織内の全端末のウイルス対策ソフトによるフルスキャン

・感染した端末を利用していたアカウントのパスワード変更

・ネットワークトラフィックログの監視

・調査後の感染した端末の初期化

これらの対応も必要になってきます。

ご注意ください。

皆さん、こんにちは。

業務改善を行うIT・業務コンサルタント、高橋です。

冒頭に書いた内容はある企業にて施されているメール送信に対する施策ですが（SPF、DKIM、DMARC）、この状態でも偽装されたメールは受信者に届いてしまうことはあります。

それは何故でしょうか？

DMARCの宣言が絶対ではない理由

まず、DMARCにはポリシーというものがあり、どのように対処通知を行うかの記述があります。

１．何もしない（none）

２．隔離（quarantine）

３．拒否（reject）

これにプラスして、どれくらいの割合でメールを評価するかの適用割合というものが記述されている場合もあります。

従って、DMARCによる宣言があるからと言って必ず偽装されたメールが受信者に届かないわけではありません。

（ポリシーの設定を『何もしない（none）』にしているケースはよくあります。）

また、DMARCにおいて『拒否（reject）』としている場合でも受信者に届くことはあります。

それは何故か？

受信者側のメールサーバーに委ねている部分があるからです。

DMARCは受信者側に対して通知（要求依頼）はするものの、それに対応する形で受信者側のメールサーバーが設定されていない場合はその通知は適用されません。

（適用しようがありません。）

これらのことを理由に、DMARCによる宣言があるからと言って偽装メールが絶対に届かないようになっているというわけではないのです。

皆さん、こんにちは。

業務改善を行うIT・業務コンサルタント、高橋です。

今日の記事ですが、中小・零細企業、小規模事業者において『DKIM』まで導入することは難しい（レンタルサーバが対応していない場合が多い）などの理由から、それが行えない前提として読んでください。

『DKIM』導入可能な場合においては下記の限りではありません。

さて、自社や自店のドメインが偽装されたメールなどに使われていたことを知っても、ある意味では八方塞がりになってしまう可能性があります。

それはどういった状態だと思いますか？

DMARCのポリシーは受信者の協力も必要

事業者が使っているドメインであれば、DNSのTXTレコードにSPF認証に関する記述が加えられていることは昨今においては普通のことと言えます。

逆に、記述がないのであれば追加しておくべきです。

例：example.com. IN TXT “v=spf1 ip4:***.***.***.*** include:example.com -all”

（***.***.***.***の部分はv4のIPアドレスが入ります。）

さて、このSPFに関する記述が入っている場合でDMARCの記述も追加されている場合、Appleなどはポシリーを『none（指定なし）』にしていますが、MicrosoftやGoogleは『reject（拒否）』にしています。

これ、受信者が転送処理などを行わずにストレートにメールを受信している場合においては『none（指定なし）』から『quarantine（隔離）』、『quarantine（隔離）』から『reject（拒否）』と、フィルター処理の割合を組み合わせながら段階的にポリシー変更を行っていけば良いですが、受信者が転送処理などを行っている場合、相手のサーバ設定によっては『none（指定なし）』から他に変更することで問題が生じます。

例えば、受信者が自動転送設定をしていた場合で、その際のIPアドレスの出力を転送元IPアドレスとしていた場合、送信元ドメインとそのIPアドレスが一致せず、SPF認証は『Pass』とならないため受信者がメールを受け取れない可能性が出てきます。

（DMARCのフィルター処理（PCT）の設定値にもよります。）

このような場合においては正直八方塞がりのような状態になります。

従って、受信者側に自動転送をやめてもらうか、受信者側に転送先メールアドレスを開示いただくか、何らかの協力をお願いすることになります。

（メールサーバの仕様を簡単に変更するわけにもいきませんので。）

まずは偽装されたメールが出回っていることをアナウンスすることからスタートですが、『全く関係のない消費者などが被害にあわない』、『自社や自店のドメインを傷つけない』ためには、最終的にはDMARCのポリシーを『reject（拒否）』にできる環境整備を行っていく必要性があるでしょう。

また、冒頭でも書きました通り、これを送信者側のみで解決しようとした場合は『DKIM』の導入が必要となります。

しかし、それはロシアから送られてきたレポートでした。

皆さん、こんにちは。

業務改善を行うIT・業務コンサルタント、高橋です。

私は普段、偽装メール（なりすまし）対策の一環としてSPFやDKIM、DMARCを使うことをお勧めしていますが、この偽装メール（なりすまし）は日本国内に限った話しではありません。

ロシアから届いたDMARCレポート

普段、DMARCレポートが届くのは現状Googleからのみであったのですが、ある日、ロシアからDMARCレポートが届きました。

その段階では、このロシアからのDMARCレポートそのものがスパムメールなのでは？と疑いをもち、メールのヘッダ情報などを調査しましたが問題は見受けられませんでした。

何かしっくりこず、セキュリティチェックを通してレポートファイルを確認したところ、どうやらロシアのIPアドレス宛にコーポレートドメインを偽装してメールが配信されたようでした。

前者の方はロシアでメールを含めたサービスを提供している企業で、その企業がDMARCレポートを配信する仕組みを取り入れていたことからコーポレートドメインのDMARCレポートが届いたということで、実際に問題な行為を行ったのは後者のIPアドレスを利用した者と考えられます。

このように、偽装メール（なりすまし）は日本国内宛にとどまらず海外宛にまで及んでいます。

現在、コーポレートドメインをはじめすべてのドメインに対してDMARCを採用しているのですが、メールに対する制御は『none：そのまま受信させる』のまま様子見をしていた状態でした。

今回のことを考えると、やはり『quarantine：隔離させる』か、『reject：受信を拒否する』に変更していくことになるでしょう。

これらに変更することで、受信者のメールサーバーに対して隔離、もしくは拒否を依頼することができますので被害を抑制することが可能です。

しかし、課題も残ります。

先日起きたケースとして、相手先がGmailなどに自動転送していた場合、Fromは送信元メールアドレスのままなであったものの、出力されるIPアドレスは転送元のIPアドレスでした。

（相手先の契約サーバーの仕様によって左右されます。）

このような場合はつじつまがあわないことになりますのでSPF認証は失敗となり、DMARCにおけるメールの制御によっては相手にメールが届かないケースが出てきたりします。

皆さん、こんにちは。

業務改善を行うIT・業務コンサルタント、高橋です。

昨日の記事に続き、今日は実際の処理設定方法に関してお話しします。

添付ファイル付きメールへの処理方法

まず、メールのヘッダー情報には以下のものがあります。

・添付ファイルのないテキスト形式の場合、『Content-Type: text/plain』

・添付ファイル付きのメールの場合、『Content-Type: multipart/mixed』

そして、例えばzipファイルが添付されたメールにはボディ部分のソースに以下のものがあります。

Content-Type: application/x-zip-compressed（zip or x-compress or その他）

Content-Disposition: attachment（attachmentは添付ファイルのこと）

filename=”〇〇”

これらを使い、添付ファイル付きのメールをフィルタリングしてあげます。

例えば、添付ファイルの種類によってり条件指定する場合には、

『Content-Type: application/x-zip-compressed（zip or x-compress or その他）』や、『Content-Type: application/msexcel（vnd.ms-excel or その他）』

などを使い、

ファイルの種類で指定しない場合には、

『Content-Type: multipart/mixed』や『Content-Disposition: attachment』

などを使うことによってフィルタリングが可能です。

特定のファイル名のものを指定する場合には『filename=”〇〇”』を使えば良いです。

ただし、これが可能なのはメールサーバのフィルタリング編集が可能な場合に限っての話しになりますが、そもそもメールサーバにてウイルスメールの駆除や隔離が行えているということであれば、この話しは念のための措置ということになります。

追伸：昨日『専用アカウントに転送してしまう』ということを書いたのは、取引先などとのやりとりにおいてすべてを削除してしまうわけにはいかない場合、単なるフォルダ分けですと端末（クライアントパソコン）に受信することにもなるため、『専用アカウント』に転送し、転送されたメールはウェブメールなどにて慎重に確認の上、必要なものだけを取り出すという意味で書いたわけです。