mcpField
O
okta-attack

okta-attack

github.com/uphiago安全1.3k40 次安装8 周前更新
代码仓库

关于 okta-attack

okta-attack 是针对 Okta 身份系统的安全测试技能，适用于相关授权测试，涵盖租户发现、认证流程与因子分析，以及 OIDC、SAML 和凭据失陷后的检查。

主要功能

  1. 01发现 Okta 租户
  2. 02分析认证流程与因子
  3. 03审慎的密码喷洒指引
  4. 04检查 OIDC 重定向 URI
  5. 05检查 SAML 与管理 API

适用场景

  1. 01梳理组织的 Okta 租户
  2. 02评估 MFA 因子暴露情况
  3. 03测试 OIDC 或 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
  • 网页引用 /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 --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 次（比 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 --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 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，是实际攻击中侦察后最有效的三种基础手法。

验证

  1. 检测 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 是身份提供商，相关配置错误会影响所有下游应用。这比单个应用的配置错误影响更大。
  • 绕过 Okta Verify — Okta FastPass 和设备信任策略存在特定的绕过途径（无需验证即可注册设备）。应专门测试这些途径。
  • Okta Classic 与 OIE — Okta Identity Engine 与 Okta Classic 的策略和绕过途径不同。测试前应先确认组织使用的类型。

相关技能与链式攻击

  • 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 — 在混合组织中，M365 常将 Okta 用作 IdP。链式攻击原语：在 Okta 租户上通过 okta-attack 枚举用户并进行密码喷洒 → 成功 → 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 问门槛验证捕获的凭据（令牌、代码、验证因素）是否确实授予了有意义的访问权限。链式攻击原语：验证 Okta 攻击原语 → 使用 triage-validation 确认访问层面 → 使用 redteam-report-template 明确说明联合应用的影响范围。
  • password-spray-methodology — 适用于所有协议的通用密码喷洒流程 + 错误代码差异分析

评论

支持 Markdown