こんにちは、セキュリティエンジニアの岩田です。今回は「擬似サイバー攻撃演習」と銘打って行った社内の演習についてご紹介します。

擬似サイバー攻撃演習とは?

実際のサイバー攻撃をシミュレーションして実施することで、現在行なっているセキュリティ対策が有効に機能しているかを検証するための演習です。「レッドチーム演習」や「脅威ベースのペネトレーションテスト(TLPT)」などと呼ばれるものと同様の試みですが、誰にでもより直感的に内容が伝わるようにこの名称にしました。

今回は2要素認証を回避するフィッシング攻撃によって実環境のID管理サービス(IDaaS)のアカウントを乗っ取って侵入し、機密情報を盗み出す攻撃シナリオで演習を行いました。

具体的には、攻撃者がフィッシングメールをユーザーに送ってフィッシングサイトに誘導し、ユーザーからのフィッシングサイトへのリクエスト内容をそのまま実際のサイトに転送することで、2要素認証を回避してユーザーのアカウントを乗っ取るAdversary in the Middle(AitM)と呼ばれる攻撃です。

また、この演習は今回が初めての試みだったので、スモールスタートとして攻撃対象はセキュリティグループのメンバーのみに絞って実施しました。

演習の流れ

事前準備

グラウンドルール決め

まずは攻撃側と防御側がそれぞれに対して「やること/やって良いこと」、「やらないこと/やってはいけないこと」のグラウンドルールを定めました。例えば以下のような項目です。

攻撃側
- やること/やって良いこと
  - フィッシング
  - アカウントの乗っ取り
  - 業務PCへの擬似マルウェア感染、操作
  - 会社の機密情報の窃取
- やらないこと/やってはいけないこと
  - データの削除、破壊、暗号化
  - 身代金の要求
  - 攻撃対象者の個人情報や人事・労務関連情報のアクセス
  - 他チームへ影響を与える可能性のある攻撃や設定変更など
防御側
- やること/やって良いこと
  - 何か異常を検知した時の調査や必要な対応
- やらないこと/やってはいけないこと
  - 社内へのインシデント報告
  - 社外への連絡

このグラウンドルールの「やらないこと/やってはいけないこと」に定めた事象が発生した際には即時演習を中断することも定めておきました。

また、フィッシング攻撃に対してわざと騙されて被害者になる役割の人もあらかじめ決めておきました。フィッシングに騙されないことももちろん重要ではありますが、今回の演習はたとえ騙されてしまったとしてもその先でセキュリティ対策が有効に機能するかを検証することが目的なので、少なくとも1人は被害にあうようにしました。

IoC(Indicator of Compromise)の共有

今回は演習用の環境ではなく実環境で実施するため、本物の攻撃と演習での擬似攻撃を区別できるように、事前に擬似攻撃で使うIPアドレスやドメイン名を事前共有IoCとして共有しておきました。

アラートやログの調査の結果、事前共有IoCと一致する事象であれば演習だとわかるようにしておくことで、サービスの停止や外部連絡などの過剰な対応をしてしまうことを防ぐ目的で行いました。

情報収集

演習とはいえなるべく現実に発生しうる攻撃をシミュレーションしたかったので、初期侵入の攻撃に利用する情報は、社内情報は使用せずにインターネットを検索して入手できる情報だけを元に行うようにしました。

情報収集は演習実施の期間の前に行い、攻撃対象者の名前やメールアドレス、使用しているシステムの情報などを入手してまとめておきました。

リソース開発

攻撃のためのインフラやツールなども演習実施前に用意しておきました。

具体的にはクラウドサービス上へのフィッシングサイトやプロキシサーバーの用意、フィッシングメールの作成などを行っておきました。

事前告知

攻撃の準備が整ったら、セキュリティグループのメンバー(=攻撃対象者)に演習の実施期間を告知しました。具体的な日付や攻撃内容は明かさず、この期間に攻撃を実施するということだけを伝えるようにしました。

また、何か不測の事態が発生した場合に備えて、念のため情報システムグループにも演習を実施することを共有しておきました。

攻撃の実施

初期侵入

最初の侵入はIDaaSの通知メールに見せかけたフィッシングメールを送信しました。実際のIDaaSの通知メールを元に、ロゴやレイアウトも本物と似たようなメールを送り、メール内のリンクからフィッシングサイトに誘導しました。

認証情報の窃取

フィッシングサイトには、上述のAitM攻撃と呼ばれる、ユーザーからのリクエストを実際のサイトへプロキシする動きをするものを使用しました。

実際のサイトへのリクエスト/レスポンスをプロキシするため、URLが違うだけで見た目は全く本物と同一で区別がつきません。

また2要素認証のリクエストも実際のサイトに送るため、実際のサイトからのプッシュ通知がユーザーに届き、攻撃者は被害者のユーザー自身が2要素認証で認証した後のセッション情報を盗むことで、2要素認証を回避してアカウントを乗っ取ることが可能です。

また、ユーザー自身が普段ログインしているブラウザからアクセスしている状態になるため、新しいデバイスからのログイン通知なども送られてきませんでした。

このような2要素認証を回避するフィッシングは近年増加しており、Microsoftなども記事を公開しています。

参考: Token tactics: How to prevent, detect, and respond to cloud token theft

機密情報の窃取 / 不正プログラムの実行

IDaaSのアカウントを乗っ取ってしまえば、利用している各種サービスにはシングルサインオン(SSO)でアクセスできるため、簡単にさまざまな機密情報にアクセスできてしまいます。

また今回の攻撃対象となったセキュリティグループのメンバーは強い権限を持っているため、SSOによりモバイルデバイス管理ツールにアクセスして、管理ツールの機能を利用して擬似マルウェアをPCに配布することもできました。

IDaaSによるSSOは、ID/パスワード管理の負担を軽減してID管理の強化ができる一方で、万が一アカウントが乗っ取られた時の被害は非常に大きくなってしまいます。そのため2要素認証などでセキュリティ強化を行うのですが、ワンタイムパスワードやプッシュ通知などの一般的な2要素認証では、今回のAitM攻撃の例のようにアカウントの乗っ取りを防げないことがあります。

これを防ぐためにFIDO2/WebAuthnなどのフィッシング耐性のある2要素認証の利用が推奨されており、先日米国CISA(Cybersecurity & Infrastructure Security Agency)からもガイダンスが公開されていました。

参考: CISA Releases Guidance on Phishing-Resistant and Numbers Matching Multifactor Authentication

また防御側の対応で、乗っ取られたアカウントのセッションをIDaaS側でリセットしたりIDaaS上のアカウントを無効化したものの、サービス側のセッションは有効なままで、その後もセッションの有効期限が切れるまで攻撃者は依然としてサービスにアクセス可能でした。この場合はサービス側でもセッションのリセットなどの対応が必要になります。