Okta ユーザーを欺くソーシャル・エンジニアリング:Super Admin アカウントが狙われている

Social Engineering Attacks Target Okta Customers To Achieve A Highly Privileged Role

2023/09/02 SecurityAffairs — Okta が顧客に発している警告は、この数週間で観察されている、管理者権限への昇格を目的としたソーシャル・エンジニアリング攻撃に関するものだ。この攻撃は、IT サービス・デスクのスタッフを騙して、高度な権限を持つユーザーが登録した、すべての多要素認証 (MFA) 要素をリセットするよう促すものである。なお、現時点において同社は、この攻撃を実施した脅威アクターを特定していない。Okta の顧客組織 (テナント) において、高度な特権ロールを獲得した脅威アクターは、横方向への移動を行い、また、防御回避の斬新な手法を採用している。


Okta のアドバイザリには、「この数週間における、米国を拠点とする複数の Okta 顧客からの報告によると、各社の IT サービス・デスク担当者に対するソーシャル・エンジニアリング攻撃が発生し、それらには一貫したパターンがあることが判った。この攻撃の戦略は、サービス・デスク担当者に対して、登録されている特権ユーザーたちの、すべての多要素認証 (MFA) 要素をリセットするよう促すというものだ。そして、高度な特権を持つ Okta Super Administrator アカウントの侵害に成功した攻撃者は、正規の ID フェデレーション機能を悪用し、侵害した組織内ユーザーへのなりすましを可能にしている」と記されている。

一連の攻撃の前提として考えられるのは、すでに脅威者が、特権ユーザー・アカウントのパスワードを知っていたケースである。また、IT サービス・デスクに電話する前に、Active Directory (AD) を介した委任認証フローの操作が可能だったケースも有り得る。

この脅威アクターが標的としているのは、Okta 顧客内で Super Admin パーミッションを持つユーザーである。

この攻撃では、侵害したアカウントにアクセスするために、匿名化されたプロキシ・サービスが用いられ、また、これまではユーザー・アカウントに関連付けられていなかった、IP とデバイスが用いられたことが確認されている。

Super Admin アカウントを侵害した脅威アクターは、そのアカウントを用いることで、他のアカウントへの高権限の割り当てや、既存の管理者アカウントに登録されている認証機能のリセットなどを行っている。さらに Okta は、脅威アクターが認証ポリシーの第2要素を削除したことも報告している。

このハッキング・キャンペーンは、2023年7月29日〜8月19日に観測されたという。

2022年の Twilio と Cloudflareに対する攻撃でも使用された、フィッシング・キットである 0ktapus を、この脅威アクターは使用しているという。このツールは、ユーザーを騙して認証情報や MFA コードを提供させることを目的としている。

この脅威アクターは直近の攻撃において、侵害した組織内のアプリケーションに、他のユーザーに代わってアクセスする「なりすましアプリ」を機能させるために、第2の ID プロバイダーを設定していることが目撃されている。

Okta のアドバイザリには、「この脅威アクターは直近の攻撃において、侵害した組織内のアプリケーションに、他のユーザーに代わってアクセスする “なりすましアプリ” を機能させるために、第2の ID プロバイダーを設定していることが目撃されている。この2番目の ID プロバイダーも攻撃者により制御されており、ターゲットとの受信フェデレーション関係 (Org2Org) と呼ばれることもある) において “source” IdP として機能する」と記されている。

Okta から顧客に推奨されるのは、以下の項目である:

  • 管理コンソールなどの特権アプリケーションへのアクセスにおいて、サインインするたびに再認証を要求するよう、認証ポリシー (Application Sign-on Policies) を設定する。
  • セルフ・サービス・リカバリを使用する場合は、利用可能な最も強力な認証機能 (Okta Verify または Google Authenticator) を用いてリカバリを開始し、リカバリ・フローを信頼できるネットワークに限定する (IP/ASN/ジオロケーションによる) 。
  • ヘルプデスク担当者によるリモート管理/監視 (RMM) ツールの使用を見直し、統合し、他のすべての RMM ツールの実行をブロックする。
  • 視覚的な検証と委任されたワークフローを組み合わせて、ヘルプ・デスクの本人確認プロセスを強化する。ここでは、ヘルプデスク担当者がユーザーの身元を確認するための、MFA チャレンジおよびアクセス・リクエストを発行する。つまり、ユーザーの要素がリセットされる前に、ライン・マネージャーによる承認が必要となる。
  • 新規のデバイスおよび、疑わしいアクティビティに関して、エンドユーザ通知をオンにしてテストする。
  • Super Admin ロールの使用を見直して制限する。つまり、Super Admin アクセスには特権アクセス管理 (PAM) を導入し、保守のタスクには Custom Admin ロールを使用し、リスクの高いタスクの実行権限を委譲していく。
  • 管理者専用のポリシーを実施する。つまり、管理者に対しては、管理対象デバイスからのサインインと、フィッシングに強い MFA (Okta FastPass/FIDO2 WebAuthn0 によるサインインを義務付ける。そのアクセスを、信頼できるネットワーク・ゾーンに制限し、匿名化プロキシからのアクセスを拒否する。