盗取凭据用于在重置 MFA 后登录 Okta 帐户

编辑

盗取凭据用于在重置 MFA 后登录 Okta 帐户编辑

检测 Windows 主机上的一系列可疑活动,表明凭据被泄露,随后采取行动削弱 Okta 用户帐户的多因素身份验证 (MFA) 和单点登录 (SSO) 机制。

规则类型: eql

规则索引:

  • filebeat-*
  • logs-okta*
  • .alerts-security.*
  • logs-endpoint.events.*

严重程度: 高

风险评分: 73

每隔: 6h

: now-12h (日期数学格式,另见 其他回溯时间)

每次执行的最大警报数: 100

参考资料:

标签:

  • 战术: 持久性
  • 用例: 身份和访问审计
  • 数据源: Okta
  • 数据源: Elastic Defend
  • 规则类型: 高阶规则
  • 域: 端点
  • 域: 云

版本: 1

规则作者:

  • Elastic

规则许可: Elastic 许可证 v2

调查指南编辑

分类和分析

调查盗取凭据用于在重置 MFA 后登录 Okta 帐户

此规则检测 Windows 主机上的一系列可疑活动,表明凭据被泄露,随后采取行动削弱 Okta 用户帐户的多因素身份验证 (MFA) 和单点登录 (SSO) 机制。

通常,攻击者最初会通过各种方式从目标端点提取凭据。随后,他们可能利用社会工程学来重置与 Okta 帐户关联的 MFA 凭据,尤其是在 Active Directory (AD) 服务与 Okta 集成的场景中。成功重置 MFA 允许使用盗取的凭据未经授权访问被泄露的 Okta 帐户。然后,攻击者可以为其自己的设备注册 MFA,为其无限制地访问用户的 Okta 帐户和任何关联的 SaaS 应用程序铺平道路。如果被泄露的帐户具有管理员权限,这尤其令人担忧,因为它可能导致对组织资源和配置的广泛访问。

可能的调查步骤

  • 通过检查 user.name 字段来识别与 Okta 登录尝试关联的用户帐户。
  • 通过检查警报文档中的 host.namehost.id 字段来识别此用户的凭据访问警报的端点。
  • 交叉检查 Okta 用户和端点用户以确认它们是同一个人。
  • 联系用户以确认他们是否最近有意重置了其 MFA 凭据或寻求帮助来执行此操作。
  • 如果用户不知道 MFA 重置,则可能需要立即进行事件响应以防止进一步泄露。

误报分析

  • Windows 管理员可能在执行合法管理操作期间触发了低保真度凭据访问警报。在此之后,管理员可能已为自己重置了 MFA 凭据,然后登录到 Okta 控制台以进行 AD 目录服务集成管理。

响应和修复

  • 如果确认用户没有有意重置其 MFA 因素,请停用用户帐户。
  • 停用后,重置用户的密码和 MFA 因素以重新控制帐户。
  • 确保在此过程中停止所有用户会话。
  • 如果 Okta 没有同步回 AD,请立即重置用户的 AD 密码。
  • 可能需要对用户端点进行取证分析以确定泄露的根本原因并确定泄露的范围。
  • 查看 Okta 系统日志以识别与用户帐户关联的任何其他可疑活动,例如创建备份帐户。
  • 使用从 MFA 因素重置中捕获的设备 ID,搜索所有 Okta 日志中与设备 ID 关联的任何其他活动。

设置

设置编辑

Okta 和 Elastic Defend 舰队集成结构化数据需要与该规则兼容。Okta 与 AD 同步的目录服务集成对于该规则的有效性也是必需的,因为它依赖于对来自 Okta 和 Elastic Defend 事件的 user.name 进行分类。

规则查询编辑

sequence by user.name with maxspan=12h
    [any where host.os.type == "windows" and signal.rule.threat.tactic.name == "Credential Access"]
    [any where event.dataset == "okta.system" and okta.event_type == "user.mfa.factor.update"]
    [any where event.dataset == "okta.system" and okta.event_type: ("user.session.start", "user.authentication*")]

框架: MITRE ATT&CKTM