インシデント対応事例から学ぶ教訓 case5 「知らぬ間に攻撃に加担させられるかも？クラウドメールアカウント乗っ取りの被害」

今回のインシデントに学ぶ教訓

・メールシステムへの侵害が自社だけでなく、他社の被害を招く可能性があることを理解し、セキュリティ対策優先度を見直すこと

メールシステムはコミュニケーションツールの為、様々なシステムの中でも2次被害を招きやすいもの。
二次被害リスクを考慮の上、そのセキュリティ対策優先度を決定する必要がある。

・クラウドサービスのセキュリティレベルが、アカウント認証に依存する部分が大きいことを理解し、管理状況や認証機構を見直すこと

クラウドサービスでは、セキュリティ機能としてアカウント認証が占める役割が大きい。
アカウント認証を突破する様々な攻撃が存在する中で、自社のアカウント管理が十分か定期的に見直す必要がある。

・「正常」なメールアカウントの動作を把握し、最小限のアクセス制御を設定の上、挙動を監視すること

業務の中で、メールサービスをいつ誰がどの端末やどこの地域から使用するのかを定義し、それ以外を制限または監視することで想定外のアクセスの防止や気づきにくいなりすましを検知することができる。

今回の事例の経緯（実話をもとにしたフィクションとなります。）

とある企業で部長職を勤めるBさんは、自身の業務上出張の機会が多く、日ごろから全国各地様々な地域に出向いていました。
Ｂさんの会社では、外出の多い人が出先でもスムーズに顧客とコミュニケーションを行えるよう、クラウドのメールサービスを導入していました。

事件が発覚した日もＢさんは出張で熊本を訪れており、打ち合わせを実施した後に取引先のＣ社担当者より着信があったことに気づきました。
折り返して要件を確認したところ、Ｃ社担当者からは思いもよらない話を告げられました。
「Ｂさんの名義で、いつもと文体の異なる怪しいメールが私宛てに届いているのですが、Ｂさんが送られたもので間違いないでしょうか？」
全く身に覚えのない連絡を受けたＢさんは、まず自身が送った覚えがないことを伝えるとともに、メールの中身について細かく確認しました。
Ｃ社担当者によると、ところどころ文法のおかしい日本語と見慣れないURLが記載されているとのことから、そのURLには絶対にアクセスしないよう告げ、一度事実確認の為自身のメール送信履歴などを確認することにしました。

自身の送信済みフォルダには数十件の不審なメールの送信履歴があり、何かしらのサイバー攻撃を受けていることを確信したＢさんは、社内のIT部門担当者にすぐに電話し、アカウントの停止や自身の端末の隔離方法を尋ね、実行しました。

その後数日間、Ｂさんの一部の業務は停止したままでしたが、Ｂさん保有端末のログ調査等を社内で行いました。
しかし、特に端末側にマルウェアや不審な挙動の痕跡はなかったことから、今回のインシデント発生の原因がわからず、今後も攻撃が続く可能性に不安を感じていました。
そこで自社で導入していたセキュリティ製品ベンダーのトレンドマイクロに協力を依頼することを決めました。

トレンドマイクロと協力して調査を行う中で、クラウドメールサービスのアカウント認証が突破されて、乗っ取られたことがわかりました。
アカウント乗っ取りの原因がわかったことから、対策すべき事項が整理され、それらを速やかに実施し、事態は一旦収束しました。

以上が今回の事例の顛末となります。
本記事では、この一連のインシデントの中でどういった攻撃が行われていたのか、またどのような対策を実施するべきだったかに関して具体的に紹介し、ここから学び取れる教訓をご紹介したいと思います。

なお、本事案において注目すべきことの1つは、なりすまして送られたメールに記載されていたURLがマルウェアをダウンロードするサイトに誘導するものだったことが挙げられます。
調査の中で判明したことですが、もし記載されていたサイトからダウンロードしたファイルを開いた場合、マルウェアが実行されその端末は遠隔操作されるようにプログラムされていた為、Ｂさんのアカウントが、さらなる攻撃拡大に利用されようとしていたことが分かります。
なりすましメールは送られるだけでも自社の評判低下につながる上、さらなる被害を生む可能性を含んでいます。
自社だけでなく、関係する他社への危害を抑える為にも、アカウントの乗っ取りへの対策は重要性が高いといえるでしょう。

侵害された資産

まずは、今回侵害されたデジタル資産を図にマッピングします。

今回主に侵害が確認されたデジタル資産は上記青枠に含まれるクラウドメールサーバーと赤枠に含まれる社内外の業務用端末です。
赤枠内の端末はインターネット上に存在する端末ではありませんが、クラウドメールサーバー経由でメールを受信した端末群となります。
青枠左の攻撃者PC群は、クラウドメールサーバーの認証を突破するべく、攻撃者は多数の端末からログイン試行を試みていた上、1人の攻撃者によるものかまでは不明の為、複数台を並べて記載しています。
なお、前述のとおりBさんの端末を含む自社内の端末にはセキュリティソリューションの導入が実施されていました。

攻撃経路

次に上記の資産に対してどのような経路で攻撃が行われたか図に記載します。(痕跡のあった動作を実線で記載)

調査の中では、まずクラウドメールサーバーのサインインやメールのログを確認しました。
結果、Bさんが利用していない期間に、被害を受けたクラウドメールサーバーに対して、海外のIPアドレスから複数回のログイン試行が行われていることが確認されました。
度重なるログイン試行により、アカウントのロック機能が作動しており、エラーが発生していたことも確認されました。
ただし、アカウントのロック機能自体は時間の経過で解除されるものであったため、解除後もログイン試行は実施されていました。
そのうちのいくつかにおいて、ログインが成功してしまったことが確認されたことから今回の攻撃の侵入要因が、アカウントリスト攻撃(辞書攻撃）などによる認証突破であることがわかりました。
Bさんの会社では、クラウドメールサーバーの認証機構としてユーザー名とパスワードのみによる基本認証を採用していたことから、こうしたオンラインサービスへの不正ログインを狙った攻撃に対する防御力が低かったことが侵害要因の1つとして挙げられます。

次にBさんのアカウントを踏み台にして送られたメールの内容に関しても調査を行いました。
メール本文に記載されているURLからダウンロードしたファイルを詳細に調査したところ、全てマルウェアであることがわかりました。
具体的にはURSNIF等の著名な情報窃取型マルウェアなどであり、それらは情報を窃取し、感染した端末を起点にさらなる感染拡大を狙うボットネット型のマルウェアでもありました。
今回のアカウント侵害も、より広い範囲に攻撃者のマルウェアを展開する為の活動の一部であったことが伺えます。

防御体制上の脆弱性

前項の「攻撃経路」で行われた攻撃者による侵害について、個々の段階で防御できなかった理由を突き詰めることで、理想の防御体制と現実の防御体制の間のギャップを明らかにすることができます。この理想と現実の「ギャップ」は、言い換えれば「防御体制上の脆弱性」です。今後の対策改善のためにも、今回の侵害で狙われた「防御体制上の脆弱性」を以下にまとめます。

	防げた可能性のある攻撃	防御体制上の脆弱性	事前に行うべき対策
①	クラウドのメールサービスの認証を突破された	メールアカウントのID・PWの複雑性が不足していた	・パスワードの複雑性を向上するポリシーを更新し、アカウントの堅牢性を高める
①	クラウドのメールサービスの認証を突破された	基本認証を利用しており、認証機構の強度が十分でなかった	・アカウント情報だけでは利用できないよう多要素認証方式を採用する
②	クラウドのメールアカウントが乗っ取られた	メールサービスへのアクセス制御が不足していた	・業務上使用するIPアドレスのレンジからのみアクセスできるようにする、または業務上不要であれば海外からのアクセスを禁止するなど、クラウドサービスに対してもアクセス制御を実施する
③	クラウドのメールサービスに秘密裏にログインされた	メールサービスへのログイン監視が不足していた	・クラウドにおいてもセキュリティ製品を導入し、認証失敗などの不審な活動を検知する

表1：改善可能な防御体制上の脆弱性とその対策

今回のインシデント発生の根本的な原因は、クラウドのメールアカウントの認証が突破されてしまったことにあります。
クラウドサービスはWEB上にホストされているサービスである為、いつどんな場所、どんな端末からでもインターネットさえ使えれば、そのサービスを利用できるという高い利便性を持つと同時に、攻撃者にとっても認証さえ突破してしまえば組織内部のネットワークに侵入せずとも侵害できるシステムであるという特徴があります。
その為、システムのセキュリティレベルが、アカウントの複雑性や認証機構の強度に大きく依存します。
対策としては、そもそものパスワードを複雑にすること（12文字以上で4種の英大文字、小文字、数字、記号などを組み合わせるなど）や、ワンタイム認証の利用、さらに記憶以外の認証機構として生体情報やマシン情報などを組み合わせた多要素認証方式の採用などが有効といえます。

また、万が一認証情報が奪われた場合でも、特定のIPアドレスレンジ（社内IPからのみ、海外のIPは完全に遮断など）からしかアクセスできないような制御を施すことで、その悪用を阻止できます。
さらに、クラウド環境に対してもセキュリティ技術を適用し、メールサービスに対する不審なログイン試行や失敗、業務上利用されることのない海外IPからのアクセス試行などを監視することで、攻撃自体の発生に素早く気づくことが可能となる為、被害低減の効果が期待できます。

今回のような侵害が発覚した際、初動対応として下記のような対応が考えられます。

1. 侵害を受けていると疑われる端末の隔離や調査
端末のスキャンを実行し、マルウェア等がコンピューター内に存在するかを確認する。

2. なりすましに利用されているアカウントのサインインのブロックやアカウント情報の変更
変更の際には、これまでに使用した事のあるパスワードと異なる物を設定する。

3. 送信済みアイテムの確認
どんな内容が何名または何社に送られたかを確認し、影響範囲や連絡事項を検討する。

4. 侵害の形跡の確認
クラウドやセキュリティログを確認し、身に覚えのない転送設定が無いかや、被害端末以外にも影響がないか確認する。

5. 不審URLのブロックリスト登録
送付されたメール等にURLが含まれる場合には、ブロックリストとして該当URLを登録する。

6. なりすましメールの事象公表の検討
事象や状況が整理された後に、経営戦略に則って、今回の被害の内容や影響についてプレスリリースなどで対外発表を行う。

拡散やさらなる侵害の拡大を抑えつつ、影響範囲を探るという対応を速やかに行うことが求められます。
また他者にメールが送付されていた場合などには、対外的なコミュニケーションをどのようにとっていくかに関しても、経営レベルの判断が求められます。
なお、調査の中でマルウェアや不審なURLが見つかった際は、セキュリティベンダーに依頼し、検体の解析等を行う事も有効な手立てとなります。

まとめ

今回はクラウドのメールアカウントが乗っ取られてスパムメール送信の踏み台として悪用される事例を紹介しました。
本事例から学び取れる教訓として以下3つが言えます。

・メールシステムへの侵害が自社だけでなく、他社の被害を招く可能性があることを理解し、セキュリティ対策優先度を見直すこと

・クラウドサービスのセキュリティレベルが、アカウント認証に依存する部分が大きいことを理解し、管理状況や認証機構を見直すこと

・「正常」なメールアカウントの動作を把握し、最小限のアクセス制御を設定の上、挙動を監視すること

業務の中で、メールサービスをいつ誰がどの端末やどこの地域から使用するのかを定義し、それ以外を制限または監視することで
想定外のアクセスの防止や気づきにくいなりすましを検知することができる。

最近、ChatGPTなどの生成AIの普及や知名度の向上がめざましい中、詐欺やなりすましメールなどに使用される可能性も懸念されています。

トレンドマイクロ製品「Trend Micro Cloud App Security™」で、2022年に検出された世界全体のBECメールの内、日本での検出数は0.2%ほどでした。
世界全体の中で見た場合に、日本での詐欺メールの試みが少ないということは、言語的壁による防御作用があるからだと言われてきました。
しかし、生成AIの普及により、言語障壁が下がることが多くの人にメリットをもたらすと同時に、サイバー攻撃者にもその恩恵をもたらし、日本語を用いた文章作成が以前よりも簡易になる事で、攻撃の試みが増加する可能性があります。
フィッシングやBECなど、メールにまつわる脅威は依然増加傾向にあるので、言語という防壁を失った場合、日本におけるメールサービスを取り巻くリスクは大きく増大すると言えるでしょう。
とはいえ、メールサービスの利用がビジネスに欠かせないことは自明なので、それらの利便性を保ちつつも悪用されない、または悪用されても被害につながらないような対策を施していくことがより重要になるでしょう。

今回のように攻撃シナリオを具体的に把握することで、致命的な被害につながり得る脆弱性を事前に把握し対処を施すことが可能になります。
他社のインシデント事例を参考に、自社にとって優先するべきリスク対応を決定することは有効な戦略の1つと言えるでしょう。