弊社やらかしましたか？
「なんかマルウェア付きのメールが御社から送られてきたんですけど、困ります」と顧客からお問い合わせを受けちゃったどうしよう。うわあ、うちマルウェア感染してなんかばらまいちゃった？マルウェア検知してないけど何が起きてるの？全端末調査したほうがいいの？オロオロ。
おちつかなきゃ。まずは事実関係の調査ですよね。
確認のためにメールを入手
事実確認のために、相手に届いたメールをもらいましょう。メールヘッダがとても重要なので普段使っている「転送」じゃなく、ヘッダ付きで送って欲しいと依頼しましょう。とりあえず送ってと簡単に言えないところが面倒ですね。
相手が Outlook を使っている場合は、「[ファイル] > [プロパティ]をクリックしてヘッダーをコピーして送ってください」。Outlook 以外の場合には 「メールをデスクトップに保存してメモ帳で開いてスクリーンショットを送ってください」と頼みましょう。
ヘッダから情報収集
世の中にたくさん出回っているメールヘッダ解析資料を手掛かりに、送信元がだれなのかを確かめましょう。
集める情報は、まずどのクライアントIPアドレスから、どのSMTPサーバに投函したのか。
これは、メールヘッダの Received: のタイムスタンプの一番古いもの、メールヘッダの下の方にあります。
Received: from unknown(172.17.10.1) by ***.***.***.***(smtp.my.com)
with SMTP;Wed, 05 Aug 2020 09:00:09 +0900
こいつの from が、クライアントIPアドレス。このページでは便宜上 Client: と書くことにいたしましょう。smtp.my.com が投函先のSMTPサーバ (便宜上 Received: とします)。ただ、ローカルIPアドレスが記録されていることもあるので、その場合、ヘッダのより上の方にみつかった Received: の from を見るか、または SPFレコードの検証記録 (Received-SPF: や Authentication-Resunts: など) のhelo を確認しましょう。
Received-SPF: pass (省略)
client-ip=***.***.***.***; helo=smtp.my.com;
envelope-from=me@my.com
次に集める情報は、送信者。メールに表示される From: に加えて、SMTPサーバの認証時に使われたメールアカウント、こっちが重要です。これが、メールの配送情報(エンベロープ)に使われ、メールヘッダの Return-Path: に埋め込まれています。普段は一致していますが、なりすまされると不審なアドレスになったりします。
とりあえずその4ヘッダがわかれば十分かな。SMTPサーバの種類や設定によって記録のされ方がまちまちなので、情報収集面倒ですよね。
ほんとうにうちから送ったのか
さて読み解きタイムです。メールアカウントが乗っ取られているという深刻な状況から、自社のメールサーバ使われていないなりすましメールまで程度はさまざまですが、基本的に正規のメールに見えるほど事態は深刻です。
[4] のなりすましには、 From: の氏名にメールアドレスを埋め込んだりしてきます。
From: "弊社の担当者名<me@my.com>"<bad@spam.com>
顧客は弊社からのメールだと勘違いしちゃうけど、弊社が送ったものではないのです。
とはいえ、マルウェアの感染拡大を狙ったメールは、なんとなく取引先からのメールかと勘違いを誘い添付ファイルの開封を促せれば目的達成なので雑ななりすましでもいいのでしょう。そして、どのケースも、弊社と顧客の関係が分かった上で送られたメールに違いはありません。
つまり、弊社のどこからかアドレス帳が盗まれた可能性があるのです。次々と他の方からの問い合わせが来るようなら、その可能性は濃厚でしょう。
もちろん、取引先のアドレス帳が盗まれている可能性もありますが、それはそれ。自社の確認を優先しましょう。
発生しやすいのは [2] [4] あたりでしょうか。 [3] は今時、SPFレコード設定していない企業はどれだけあるんだろう。[1] は、「マルウェア感染端末から」メール送信を送った場合の例ですが、マルウェア作るんだったら「SMTP認証情報やアドレス帳」を「盗み出して外から」[2]のようにして送った方が利便性が高いような。派手に動くとマルウェアみつかっちゃうし。
なにが起きている可能性が高いかが整理できたら、セキュリティ対策とっていきましょう。
原因調査と対策
システム構成様々なので一概には言えないところではありますが、まず、メールが送られ続けている状況を止めるかせめて減らす必要があります。SMTP認証情報が盗まれている可能性があるなら、アカウントを一時凍結してメール送信できないようにしましょう。凍結する仕組みを持っていないなら・・・・どうしよう。サーバ止める？
DNSサーバにSPFレコード設定していなければ急ぎ、設定しましょう。[3]の可能性を潰せます。
それでも、[4]の形のなりすましメールは防げません。盗まれたアドレス帳は取り返せないのです。ホームページに「当社のなりすましメールに注意」と注意喚起を出しましょう。
さて、これで少しは調査する時間がつくれました。
時間をかけて影響範囲の整理と原因究明と事態の封じ込めをしていきましょう。
[1]マルウェア感染が確定なら、PCをネットワークから隔離。セキュリティベンダーを呼んで調査と駆除（またはPC交換）をいたしましょう。
PC隔離後にメールアカウントのSMTP認証パスワード変更を。マルウェア感染端末が活動したままだと、変更後のパスワードも盗み取られてしまいますもんね。
問題は、マルウェア感染が確定していない[2]アカウントが乗っ取られたり、[3][4]なりすましメールが送られたりした場合です。そのメールは外部から送られているんです。それでも、自社がマルウェア感染しているのでしょうか？・・・あれ？アドレス帳やSMTP認証情報はいつどこから盗まれたのでしょう。いま？いつ？どの端末から？マルウェア感染？サーバーが攻撃された？従業員が持ち出した？もしかして、自社が受けている被害について自分は何も分かっていないんじゃないか・・・・？
やはり、もうこの時点で、一度セキュリティベンダーを呼んで調べてもらうのがいいように思います。何も出てこなければそれが安心材料になりますし。ただ、[3][4]が数件程度なら「どこか別の誰かから盗まれた可能性」も大いにありえます。調査に数百万円つっこむ前に、しばらく様子見いたしましょう。すりきずで救急車呼ぶこともないでしょう。
顧客に送られた迷惑メールが Emotet だった場合はどうでしょう。この場合でも、過去にどこからか盗み出されて集められたメールアドレス宛に Emotet が送られた可能性があり、自社が Emotet に感染しているとは限りません。でも、もしかしたら、感染してる可能性が高いんじゃないか、うちの社員のリテラシー・・・部長はなんでも開いちゃうおじさん、疑念が拭い去れない。ということであれば、自身で確認して安心いたしましょう。
JPCERT/CC に公開されている マルウェアEmotetへの対応FAQ を頼りに、メールアプリを入れている Windows を対象に、Emotet 感染チェックをしてまわりましょう。ただし、2020年7月18日から流行している新しい Emotet に関しては2020年8月時点では EmoCheck ツールがまだ検知に対応していません。レジストリ確認方法も書かれているので、そのやり方で頑張りましょう。チェックした日時と、チェック方法と、対象端末のリストを残しておけばその後の調査にも役立ちます。
さあ Emotet に感染していると分かったら、どうしましょう。この場合、他の様々なマルウェアを呼び込んで他のPCやサーバにも感染拡大している可能性があります。自分たちでできるのはここまで。セキュリティベンダーを呼びましょう。この先は長い。
その後
なんとかできる対処はやって、自社はクリーンな状態にもどせましたとさ。ああしんどかった。
それでも、[4]の形のなりすましメールは防げません。盗まれたアドレス帳は取り返せないのです。これってどうしたらいいんでしょうね。
最後に
ちょっと乱暴にまとめすぎた気もするけど、コメントもらえたら改良していくこととしよう。
文章中で使用したドメインはすべて例です。実在するドメインとは関係がありません。
追記
2020-08-06 : @toshikawa さんのコメントを受けて、メールヘッダの入手手順と、emotet周りの追記をしました。どうもありがとう。