MusahIssah/okta-threat-detection-lab

# 🛡️ Okta 威胁检测实验室 **凭证填充 | 不可能旅行 | MFA 疲劳攻击** **环境：** Okta Preview Sandbox (`org1-propp-2098f`) + Windows Server 2022 Active Directory (`Musah.com` 域) **工具：** Okta Admin Console · Okta ThreatInsight · Active Directory · Windscribe VPN **日期：** 2026 年 6 月 **作者：** Musah Issah — [LinkedIn](https://linkedin.com/in/musah-issah-925ba2313) · [GitHub](https://github.com/MusahIssah) ## 📌 概述 本实验室模拟了针对与 Active Directory 集成的 Okta 环境的三种真实身份攻击场景。目的是演示 SOC Analyst 或 IAM Engineer 如何使用 Okta 的原生安全工具来检测、调查和响应身份威胁。 所有攻击均在受控的家庭实验室环境中进行。没有任何真实系统受到破坏。截图中的 IP 地址已作脱敏处理以保护隐私。 ## 🎯 学习目标 - 启用并配置 Okta ThreatInsight 以进行实时威胁检测 - 模拟**凭证填充**攻击，并观察 Okta 和 Active Directory 之间的锁定连锁反应 - 使用 VPN 模拟**不可能旅行**场景，以生成地理位置上不一致的登录 - 使用重复的 Okta Verify 推送拒绝来模拟 **MFA 疲劳**攻击 - 在 Okta System Log 中分析所有三种攻击模式 - 了解 AD → Okta 信任关系，以及锁定如何在系统之间传递 ## 🛠️ 工具与技术 | 工具 | 用途 | |------|---------| | Okta Preview Sandbox | 身份提供者和检测平台 | | Okta ThreatInsight | 自动 IP 威胁检测和执行 | | Okta System Log | 审计日志和攻击证据收集 | | Okta Verify | 用于推送通知模拟的 MFA 身份验证器 | | Active Directory (Musah.com) | AD 同步用户账户的事实来源 | | Windscribe VPN (法兰克福) | 用于不可能旅行模拟的地理位置欺骗 | | Windows Server 2022 (Hyper-V) | 托管 AD 的域控制器 | ## 🗂️ 实验室架构 ``` Okta Preview Org (org1-propp-2098f) ├── AD Integration → Musah.com domain (MUS-DC-01) │ └── AD-synced users: Ruky Kiya, Louis Max, Jack Rose, etc. ├── Okta ThreatInsight → Log and enforce security based on threat level ├── Authenticators: Password, Okta Verify, Email, Google Authenticator └── System Log → Central audit trail for all events Attack Scenarios: ├── Scenario 1: Credential Stuffing → Target: Ruky Kiya (AD-synced) ├── Scenario 2: Impossible Travel → Target: Ruky Kiya (VPN: Frankfurt) └── Scenario 3: MFA Fatigue → Target: Test User (native Okta user) ``` ## 🔬 实战演练 ### 任务 1 — 启用 ThreatInsight 并验证 System Log 在模拟任何攻击之前，已启用 ThreatInsight，以确保 Okta 会根据 IP 威胁级别记录和执行安全策略。 **步骤 1 — 启用 ThreatInsight：** 导航至 **Security → General → Okta ThreatInsight Settings**。将 Action 设置为 **Log and enforce security based on threat level**。  **步骤 2 — 验证 System Log 是否处于活动状态：** System Log 立即捕获了 ThreatInsight 配置更改 — 确认审计追踪在任何攻击模拟开始之前已实时生效。  **步骤 3 — 确认目录中的活动用户：** 确认 29 名用户在 Okta 中处于 Active 状态，全部从 Active Directory (Musah.com 域) 同步。**Ruky Kiya** (`rkiya@Musah.com`) 被选为场景 1 和 2 的目标。  ### 场景 1 — 凭证填充攻击 **它是什么：** 攻击者从数据泄露中获取用户名/密码组合列表，并针对登录门户系统地尝试它们 — 期望其中一个能够成功。 **它是如何被模拟的：** 使用 Chrome 浏览器的无痕模式，在快速连续的尝试中，从同一 IP 地址对 Ruky Kiya 的账户进行了 10 多次使用不同错误密码的失败登录尝试。 **步骤 4 — 凭证填充尝试被拦截：** 经过几次失败的尝试后，Okta 显示“Unable to sign in.”  **步骤 5 — System Log 捕获攻击模式：** Okta System Log 显示了针对 Ruky Kiya 的密集 `FAILURE: INVALID_CREDENTIALS` 事件爆发 — 全部来自同一 IP 地址，发生在几秒钟内。这是教科书般的凭证填充特征：高频、同源、同目标的失败。  **步骤 6 — 配置锁定策略：**  **步骤 7 — 在登录页面确认账户锁定：** 在实施了新策略并重新运行模拟后，Okta 显示：*"Your account is locked. Please contact your administrator."*  **步骤 8 — 确认 AD 锁定：** 在域控制器 (MUS-DC-01) 上，**Active Directory Users and Computers → Ruky Kiya → Account 选项卡**显示：*"Unlock account. This account is currently locked out on this Active Directory Domain Controller."*  **步骤 9 — System Log 中的凭证填充证据：** System Log 清楚地显示了攻击特征 — Ruky Kiya 在极短的时间窗口内重复出现 `FAILURE: INVALID_CREDENTIALS`，全部源自同一源 IP。  **步骤 10 — 补救措施 — 在 AD 中解锁账户：** 通过取消勾选“Unlock account”复选框，直接在 Active Directory 中解锁了该账户。  ### 场景 2 — 不可能旅行 **它是什么：** 用户的账户在短时间内显示从两个地理位置相距甚远的地点成功登录，这使得物理旅行变得不可能 — 这是账户被盗用的强烈指标。 **它是如何被模拟的：** Windscribe VPN 通过德国法兰克福的出口节点 (`135.136.0.38`) 路由流量，然后断开连接，并从真实的家庭 IP 进行了第二次登录 — 两者均在 2 分钟内完成。 **步骤 11 — VPN 连接到法兰克福：** Windscribe VPN 通过 WireGuard 443 连接到法兰克福“Sausage Party”服务器，分配出口 IP `135.136.0.38`。  **步骤 12 — 通过 VPN（法兰克福）成功登录：** Ruky Kiya 在连接到法兰克福 VPN 节点时成功通过了 Okta 的身份验证。  **步骤 13 — VPN 断开后（真实位置）成功登录：** 30 秒后，VPN 断开连接，Ruky Kiya 再次从真实的家庭 IP 登录 — 模拟从纽约登录。  **步骤 14 — System Log 捕获不可能旅行证据：** | 时间 | IP | 位置 | |------|----|----------| | Jun 09 02:13:50 | 135.136.0.38 | 德国法兰克福 (VPN) | | Jun 09 02:16:01 | [已脱敏] | 美国纽约 (真实) | 同一用户。两个国家。相隔 2 分钟。这就是不可能旅行模式。  ### 场景 3 — MFA 疲劳攻击 **它是什么：** 已经拥有用户有效密码的攻击者会反复触发 MFA 推送通知，期望用户出于沮丧或困惑而批准其中一个。也称为 MFA 提示轰炸。 **为什么需要单独的测试用户：** Ruky Kiya 是 AD 源用户。为 AD 同步用户进行 MFA 注册需要额外的 Sign-On Policy 配置。为了保持实验室的整洁，创建了一个原生 Okta 用户 (`test.user@oktacertified.com`) 并将其注册到 Okta Verify。 **步骤 15 — Ruky Kiya 配置文件 — 未注册 MFA（AD 用户限制）：** Ruky Kiya 的 More Actions 菜单确认只有 AD 级别的操作可用 — 没有 MFA 重置选项，表明没有为此 AD 源用户注册任何身份验证器。  **步骤 16 — 确认 Okta Verify 作为身份验证器处于活动状态：** 在 **Security → Authenticators** 中确认 Okta Verify 处于 Active 状态，支持 Possession、Possession + Knowledge 和 Possession + Biometric 因素类型 — 具备 Phishing Resistant (Okta FastPass) 能力。  **步骤 17 — MFA 推送被拒绝 — 正在进行疲劳模拟：** 以测试用户身份登录并触发重复的 Okta Verify 推送通知。每次推送都在手机上被拒绝。Okta 显示 *"You have chosen to reject this login"* 以及 Resend push notification 按钮 — 这正是攻击者会利用的界面。  **步骤 18 — System Log 捕获 MFA 疲劳模式：** System Log 显示了定义 MFA 疲劳攻击的推送发送/MFA 拒绝交替循环： ``` 02:43:00 — A push was sent to a user for verification → SUCCESS 02:42:56 — Authentication of user via MFA → FAILURE: INVALID_CREDENTIALS 02:42:53 — A push was sent to a user for verification → SUCCESS 02:42:47 — Authentication of user via MFA → FAILURE: INVALID_CREDENTIALS 02:42:43 — A push was sent to a user for verification → SUCCESS 02:42:40 — Authentication of user via MFA → FAILURE: INVALID_CREDENTIALS ``` 发送推送 → 拒绝 → 发送推送 → 拒绝。在几秒钟内重复。这正是 Tier 2 SOC Analyst 会将其升级为 MFA 疲劳事件的确切模式。  ## ✅ 检测总结 | 场景 | 攻击模式 | 检测方法 | 证据 | |----------|---------------|------------------|----------| | 凭证填充 | 几秒内来自同一 IP 的 10 多次 `INVALID_CREDENTIALS` | Okta System Log + AD 锁定 | 截图 04–09 | | 不可能旅行 | 同一用户，2 个国家，相隔 2 分钟 | Okta System Log IP 对比 | 截图 14 | | MFA 疲劳 | 快速循环中交替的推送发送/MFA 拒绝 | Okta System Log MFA 事件 | 截图 18 | ## 🔐 关键发现与经验教训 **AD → Okta 信任关系：** 当用户是 AD 源时，AD 是权威的事实来源。由 Okta 登录失败触发的锁定会传递到 AD — 而不是相反。混合环境中的 SOC Analyst 在调查账户锁定时，必须同时检查 Okta System Log *和* Active Directory。 **ThreatInsight 依赖性：** Okta ThreatInsight 通过标记已知的恶意 IP 来增强检测，但它不能替代正确的密码锁定策略配置。必须同时配置两者才能实现全面覆盖。 **MFA 疲劳是一个策略问题：** MFA 疲劳场景之所以成功，是因为没有在 Okta Verify 上配置号码匹配或推送限制。在生产环境中，启用号码匹配（要求用户输入屏幕上显示的代码）可以完全消除推送轰炸攻击。 **AD 源用户需要额外的 MFA 配置：** 为 AD 同步用户进行 MFA 注册需要明确的 Sign-On Policy 规则。在实验室环境中，原生 Okta 用户更易于进行 MFA 测试的配置。 ## 🛡️ 推荐缓解措施 | 威胁 | 缓解措施 | |--------|-----------| | 凭证填充 | 在 3-5 次尝试后启用账户锁定；启用 ThreatInsight 执行 | | 不可能旅行 | 配置 Okta Behavior Detection 策略；对新设备 + 新位置发出警报 | | MFA 疲劳 | 在 Okta Verify 上启用号码匹配；限制每个会话的推送通知 | | AD 锁定传播 | 同时监控 Okta System Log 和 AD Security Event Log (Event ID 4740) | ## 📁 仓库结构 ``` okta-threat-detection-lab/ ├── README.md ├── docs/ │ └── methodology.md └── screenshots/ ├── 01-okta-threatinsight-enabled.png ├── 02-system-log-threatinsight-config-updated.png ├── 03-okta-directory-people-active-users.png ├── 04-credential-stuffing-unable-to-sign-in.png ├── 05-system-log-invalid-credentials-burst.png ├── 06-okta-password-policy-lockout-settings.png ├── 07-account-locked-contact-administrator.png ├── 08-ad-ruky-kiya-account-locked-out.png ├── 09-system-log-credential-stuffing-failures.png ├── 10-ad-ruky-kiya-account-unlocked.png ├── 11-windscribe-vpn-connected-frankfurt.png ├── 12-ruky-login-success-vpn-frankfurt.png ├── 13-ruky-login-success-real-ip.png ├── 14-system-log-impossible-travel-two-ips.png ├── 15-ruky-kiya-profile-more-actions.png ├── 16-okta-authenticators-okta-verify-active.png ├── 17-mfa-push-rejected-resend-notification.png └── 18-system-log-mfa-fatigue-push-deny-cycle.png ``` ## 🔗 相关项目 - [Okta AD 集成实验室](https://github.com/MusahIssah) — Active Directory 到 Okta 的预置工作流 - [JML 自动化流水线](https://github.com/MusahIssah) — 使用 Make.com 和 Okta API 实现入职-调岗-离职 (Joiner-Mover-Leaver) 自动化 - [PhishShield AI](https://github.com/MusahIssah) — 结合 Claude AI + AbuseIPDB 的网络钓鱼邮件分析器 ## 👤 关于 **ah Issah** — IAM Analyst 与 SOC Analyst | Okta Certified Professional | CompTIA Security+ 美国空军预备役 | DoD 秘密级许可 | 📍 纽约布朗克斯 🔗 [LinkedIn](https://linkedin.com/in/musah-issah-925ba2313) · [GitHub](https://github.com/MusahIssah)

标签：Active Directory, AMSI绕过, MFA, Okta, Plaso, Terraform 安全, 威胁检测, 安全实验环境, 身份与访问管理