使用被盗凭证在 MFA 重置后登录 Okta 帐户

编辑

使用被盗凭证在 MFA 重置后登录 Okta 帐户

编辑

检测 Windows 主机上一系列可疑活动,这些活动表明凭证被盗用,随后试图破坏 Okta 用户帐户的多因素身份验证 (MFA) 和单点登录 (SSO) 机制。

规则类型: eql

规则索引:

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

严重程度: 高

风险评分: 73

运行频率: 6 小时

搜索索引起始时间: now-12h (日期数学格式,另请参阅 额外回溯时间)

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

参考资料:

标签:

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

版本: 205

规则作者:

  • Elastic

规则许可证: Elastic License 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 Fleet 集成结构化数据兼容。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