[レポート][SBテクノロジー株式会社]Microsoft 365 アカウントを攻撃するインフラの分析 – CODE BLUE 2022 #codeblue_jp

こんにちは、臼田です。

今回はCODE BLUE 2022で行われた以下のセッションのレポートです。

[SBテクノロジー株式会社]Microsoft 365 アカウントを攻撃するインフラの分析

Microsoft 365 を利用するためのアカウントはユーザーが管理し、不正利用に対して備える必要があるが、不正利用被害時の公開情報も少なく判断に迷うことも少なくない。 そのため、不正利用被害時の各機能の検出精度を収集するための環境を用意し、意図的に不正利用被害を発生させて状況を観察した。 また、AitM といったセッションハイジャックを起点とするアカウント不正利用に対して、ユーザーサイドで検出する方式について検討する。

Presented by : 安藤 翔一 (SBテクノロジー株式会社 シニアセキュリティアーキテクト)

レポート

• 自己紹介
  • 現在はMicrosoft 365を対象としたフィッシングの調査
• イントロダクション
  • Microsoft 365はExchange Onlineなど組織のコミュニケーションやビジネスに関する機能を多数含んでいるクラウドサービス
  • 多くの企業が利用している
  • Microsoftによってセキュリティが強化される一方、ユーザーの責任範囲もまだある
  • フィッシングやリスト型攻撃などに対策する必要がある
  • アカウントへの権限集中
  • 乗っ取られた際のリスクが大きい
  • アカウントを保護する機能として多要素認証など条件付きアクセス
  • Identity Protection
  • Defender for Cloud App
  • 公開事例が少なく判断に迷う
  • 侵害行為ログの収集基盤を構築
    • ID/Passで乗っ取ることができる環境
• 悪用されているクラウドサービス
  • フィッシングサイトを構成する要素
  • ユーザーを騙すためのコンテンツと資格情報の送信の2機能
  • 同じサーバーにホストされている場合も、違うサーバーの場合もある
  • フロントは大量に作ることができる
  • アクターにメリットがある
• 構成する要素2
  • クラウドが利用されるようになってきた
  • たくさんある
  • 例えばCloudflare WorkersとTelegramが利用されたり
  • クラウド上でフィッシングサイトを構築できる
  • フィッシングコンテンツはテイクダウンさあれるが、情報格納側はテイクダウンされにくい
  • 情報送信先はサインイン試行が無いこともあり難しい
• サービスを悪用したフィッシングURLパターン
  • パスのみが異なるパターン
    • FQDNが正規コンテンツと変わらずドメインレピュテーションによる検出が望めない
  • サブドメインのみが異なるパターン
    • ドメインレピュテーションが可能
• クラウドサービス事業者側においても対策が必要か
  • 無償利用枠の悪用が多いのでは
  • Herokuでは段階的に無償枠を廃止していく
  • 通報後のAbuse対応もコスト増になるのでアクターが利用しづらい方法の検討は必要
  • アクターの身元確認がつきやすい
  • フィッシングキットを使えない
  • アカウントへのサービス利用開始通知がある
• アカウント不正利用元IPアドレス
  • アカウントを脅威から守るためには多要素認証を利用する
  • ID/Passのみと比べると大幅に良くなる
  • ID/Passの漏洩がリスクであることは変わりがない
  • 漏洩検出にサインイン元IPで検出できるか
  • 侵害を仕掛けてきたIPは6681個のIPアドレスが使いまわしていなかった
  • IPアドレスの偏りは少ない
  • ブロックリスト型の保護はあまりいい効果はでない
  • Geo IP情報を国別に確認
    • 日本は全体の5.52%
    • 75%ぐらいがVPNサービスのIP
    • VPNを防いたら結構防げる
  • VPN利用に限定してブロックする方法がない
  • Microsoft 365単体で検出/ブロックができない
  • 条件付きアクセスではIPリストが必要で現実的ではない
  • Azure AD Identity Protectionの有効化
  • Defender for Cloud Appのポリシーで遮断
• リバースプロキシ型のMicrosoft 365フィッシングサイト
  • ワンタイムパスワードをバイパスするサイトが登場
  • 認証インターフェイスをそのまま仲介し、ユーザーも気づきづらい
  • ID/Passも盗んでいるのでセッションを着れば終わりではない
  • OTPも本物と同じ画面が出る
  • 正規のURLにリダイレクトする場合も
• 課題
  • AzureADがユーザーからのリクエストか、フィッシングサイトかわからない
  • 単純な方法は証明書やFIDO2が適切
    • ただコストや費用がかかる
    • フィッシングサイトのブロックリストは限界や漏れがある
  • ユーザー側から確認する？
    • 正規のURLか確認してほしい
    • 人は確認を怠る
    • 自動的に検出できないか
    • Cookieを使用する
    • 拡張機能を使って検知する
• デモ
  • 拡張機能を入れる
  • 正規のサイトでアクセス
  • フィッシングサイトにアクセスするとアラートが出る
• 稼働中のリバースプロキシ型フィッシングサイトの調査
  • 4件あるサイトのうち全てで同じ名前のCookieを発行していた
• まとめ
  • 多要素認証が効果的な防御手段である
  • 多要素認証を利用できないアカウントに対する防衛手段を検討するため、不正サインインを誘導した
  • IPアドレスのブロックはリスト化するのは効果が薄い
  • Cookieを確認する手法の有効性を確認したが、検出できないものも出てくる可能性はある
• 追加情報
  • Windows 11のセキュリティ機能でブラウザやメモ帳にパスワードが入力されたことを検出する機能

感想

ちゃんと証明書配布しようね！