本文の内容は、2023年10月5日に NIGEL DOUGLAS が投稿したブログ（https://sysdig.com/blog/detect-impersonation-attacks-okta-idp/)を元に日本語に翻訳・再構成した内容となっております。
増大するアイデンティティ攻撃の脅威に対抗するために、組織は従来のセキュリティ対策を超えたプロアクティブなアプローチを採用する必要があります。ITDR（Identity Threat Detection and Response）は、そのようなアプローチの 1 つで、ユーザー ID とアクセス管理に関連する不審な活動の監視と対応に重点を置いています。ITDR ソリューションは、複数のログイン試行失敗、通常とは異なる場所からのアクセス、システム内の異常な動作など、通常とは異なるパターンを発見するのに役立ちます。
クロステナントなりすまし攻撃
MGM やその他のホスピタリティ／カジノ・グループが被害に遭った クロステナントなりすまし攻撃 をよりよく理解するためには、これらの攻撃者が使用した具体的な 戦術, テクニック,と手順 (TTPs) を掘り下げる必要があります。これらのTTPは、Oktaセキュリティチームが特定したもので、Oktaのお客様組織内で高度な特権を持つロールを侵害するために採用された手法に光を当てています。これらの攻撃は、高度に洗練されており、横方向への移動と防御メカニズムの回避という斬新なアプローチを含んでいます。基本的に、攻撃者は一旦アクセスすると、その痕跡を巧みに隠しながら自由に移動する能力を発揮します。
使用されたTTPを理解する
これらの攻撃者の主な目的の1つは、Oktaのスーパー管理者アカウントを標的とし、侵害することです。これにより、正当なIDフェデレーション機能を悪用し、標的組織内のユーザーになりすますことが可能になります。これらの攻撃を効果的に防御するには、これらのTTPを詳細に理解し、堅牢なセキュリティ検出ルールをビルドするための貴重なリソースとなる有用な監査ログを活用することが不可欠です。このようなプロアクティブなアプローチにより、組織はこのような巧妙な脅威に対する防御を強化することができます。
ソーシャル・エンジニアリング
攻撃者が巧妙なフィッシング・キャンペーンを実施するようになったため、Okta管理者はこのようなキャンペーンを検出する能力を強化することが重要になりました。このような状況では、Okta FastPassのような既存のテクノロジの活用が不可欠です。FastPassはゼロトラスト認証ソリューションを提供し、ユーザのアイデンティティとデバイスの両方に対する強い信頼を維持しながら、エンドユーザの摩擦を減らすことを目的としています。フィッシング検知を改善するために、Okta管理者は以下のシステムログクエリーを実行し、多要素認証(MFA)の失敗がフィッシングの可能性を示しているインスタンスを把握することができます：
eventType eq "user.authentication.auth_via_mfa" AND result eq "FAILURE" AND outcome.reason eq "FastPass declined phishing attempt"Code language: JavaScript (javascript)
Oktaのイベントログの扱い方を理解することで、オープンソースのFalcoのルールロジックを使って、Sysdigで同様のルールを簡単に構築することができます。例えば、Oktaのフィッシング攻撃を検知するために作成されたルールを以下に示します：
rule: Okta FastPass Phishing Attempt<br>desc: Detect a phishing attempt using FastPass<br>condition: okta.evt.type = "user.authentication.auth_via_mfa" and okta.result="FAILURE" and okta.reason="FastPass declined phishing attempt"Code language: JavaScript (javascript)
匿名化
自分たちの活動を隠すために、攻撃者は匿名化プロキシ・サービスを通じて侵害されたアカウントにアクセスし、以前はユーザー・アカウントに関連付けられていなかったIPアドレスとデバイスを使用しました。もちろん、これらの匿名化フィードにインバウンドまたはアウトバウンドの接続が行われたときに検出することができます。Sysdigを使用することで、ユーザはOktaのセキュリティルールを独自に構築し、匿名IPフィードへの不審なインバウンドまたはアウトバウンド接続の試みを検出することができます：
- rule: Okta Suspicious IP Inbound Request
desc: >-
Detect inbound requests from known suspicious IP sources, such as TOR exit
Nodes and anonymization proxy services, to Okta services.
condition: okta.client.ip in (ti_anonymous_ips) and okta.result="PASS"
output: >-
Suspicious IP Inbound Request (okta.client.ip=%okta.client.ip,
okta.target.user.name=%okta.target.user.name,
okta.useragent.raw=%okta.useragent.raw, okta.app=%okta.app)
priority: CRITICAL
source: oktaCode language: JavaScript (javascript)
ここから、OktaのIndicators of Compromise (IoC) disclosureで指定されたIPをti_anon_ipsマクロに入力するだけです。長期的には、匿名化フィードを更新するためのマネージド・セキュリティ・アプローチが必要になります。別のアプローチとしては、以下のシステムログクエリに見られるように、匿名化プロキシを介したサインイン試行に対して特別に警告を発することが考えられます。
eventType eq "user.session.start" and securityContext.isProxy eq "true"Code language: CSS (css)
最近の MGM のなりすまし攻撃の場合、脅威の主体は匿名化されたプロキシ・サービスを使用して管理者アカウントにアクセスし、 認証者をリセットして他のアカウントに高い権限を割り当てるために使用しました。Oktaの監査ロギングサービスに関する知識とFalcoのルールロジックに基づいて、Proxyサービスを経由したOktaのサインイン試行を検出するための特別なルールを構築することができます。
rule: Okta Sign-in via Proxy
desc: Detect a successful Okta sign-in via a proxy
condition: okta.evt.type = "user.session.start" and json.value[/securityContext/isProxy] = "true" and okta.result = "SUCCESS"Code language: JavaScript (javascript)
特権昇格
侵害されたスーパー管理者アカウントは、他のアカウントに高い権限を付与したり、既存の管理者アカウントの登録済み認証機能をリセットしたりするために使用されました。場合によっては、認証ポリシーから第 2 要素の要件が削除されることさえありました。
しかし、ファクターダウングレードのシステムログイベントがないことは注目に値します。すべての有効化および無効化イベントを監視するには、Oktaで次のクエリーを実行する必要があります：
eventType sw "system.mfa.factor"Code language: CSS (css)
ベストプラクティスとして、ユーザはユーザアカウントからすべての MFA が削除されたことを検知し、アカウント乗っ取りの可能性を示すことができます。上記の Okta イベントタイプに基づいて、MFA の削除を識別するルールを設定できます。
rule: Removing MFA from Admin in Okta
desc: Detect removing MFA on the Admin in Okta
condition: okta.evt.type = "system.mfa.factor.deactivate"Code language: HTTP (http)
なりすましアプリ
攻撃者は、他のユーザーに代わって侵害された組織内のアプリケーションにアクセスする「なりすましアプリ」として機能するように、2つ目のアイデンティティプロバイダー（IdP）を設定しました。攻撃者が管理するこの「ソース」IdPは、ターゲットとインバウンドのフェデレーション関係を確立しました。幸運にも、Okta には、なりすましを開始したユーザーセッションに関連するイベントタイプがあります：
eventType sw "user.session.impersonation.initiate"Code language: CSS (css)
複雑なルールロジックは必要なく、以下のようにuser.session.impersonation.initiateイベントにフラグが立ったときにSysdigアラートをトリガーするだけです：
rule: User initiating impersonation session in Okta
desc: Detect a user who initiates an impersonation session in Okta
condition: okta.evt.type = "user.session.impersonation.initiate"Code language: HTTP (http)
シングルサインオン（SSO）の操作
攻撃者は、「ソース」IdPから、侵害された「ターゲット」IdPの実際のユーザーと一致するように、2番目の「ソース」IdPのターゲットユーザーのユーザー名パラメータを操作しました。この操作により、標的のIdPのアプリケーションに標的のユーザーとしてSSOを行うことが許可され、これらの高度に特権化されたアカウントを保護することの重要性がさらに増しました。これらのアカウントを保護することは、単にセキュリティコンプライアンスの問題ではなく、組織のアイデンティティとアクセス管理のエコシステムの完全性を維持するために基本的に必要なことです。
より包括的なアイデンティティ・セキュリティのスタンスを確立するためには、Okta FastPassのようなOktaサービスを活用して、潜在的なフィッシングの試みから保護し、Okta ThreatInsightで疑わしいIPリクエストを検出することが不可欠です。しかし、これらのイベントに高い信頼性で迅速に対応するには、マネージドITDRのアプローチが必要です。
本稿執筆時点で、SysdigはOktaのアクティビティを監視するための34の設定済みルールを提供しています。
組織は侵害を検出し、阻止するまでの時間を改善する必要があります
現代の状況では、組織はホストエンドポイント、クラウドサービス、アイデンティティプロバイダーを含む、多数のソースから発生するデータソースを管理することが任務となっています。この包括的な監視は、これらすべての多様な環境にわたって必要なレベルの可視性を前提としています。多くの場合、組織は集中型の SIEM（セキュリティインシデントおよびイベント管理）プラットフォームにログを送信することを選択します
これとは対照的に、Sysdigのようなインシデント・レスポンス・ツールが提供するデータの前処理における高い効率性は、SIEMにデータを流すことによる非効率性を最小限に抑えます。この難問は、アイデンティティ・セキュリティに関連する問題を特定し、迅速に対処するために不可欠な機能を備えたアイデンティティ中心の ITDR ソリューションに対する切迫した需要となりつつあります。クラウド環境のコンテキストでは、この要件は通常、CDR（Cloud Detection and Response）の領域と一致します。
まとめ
ID プロバイダのセキュリティ確保は、多面的な課題であり、万能なソリューションはありません。セキュリティを強化するには、特権アプリケーション・アクセス用に認証ポリシーを構成し、再認証を強制することを検討します。進化するセキュリティ環境に備え、最新の認証ツールやリカバリ方法に対応しましょう。
リモート管理ツールの使用を制限することで、最小特権アクセスの原則をヘルプデスク・チームにも適用します。デバイスや権限の変更に対応するため、Okta環境内での脅威検出と対応を強化するために、Sysdigのようなオープンソースの脅威検出と対応（TDR）ツールの使用を検討します。
結論として、魔法のようなソリューションはありませんが、強力な認証ポリシー、最小限の特権アクセス、およびTDRツールを含むプロアクティブで適応的なアプローチにより、進化する脅威に対するIDプロバイダのセキュリティを大幅に強化することができます。