用于身份验证的 Okta 设备令牌 Cookie 生成数量过多
编辑用于身份验证的 Okta 设备令牌 Cookie 生成数量过多
编辑检测 Okta 客户端地址在单个用户身份验证中是否生成多个设备令牌哈希的 Okta 用户身份验证事件数量是否超过某个阈值。攻击者可能会尝试从同一设备发起凭据填充或密码喷洒攻击,方法是使用已知用户名和密码列表来获取对用户帐户的未授权访问。
规则类型: esql
规则索引: 无
严重性: 低
风险评分: 21
每隔: 5 分钟
搜索索引范围: now-9m (日期数学格式,另请参阅 额外回溯时间
)
每次执行的最大警报数: 100
参考:
- https://support.okta.com/help/s/article/How-does-the-Device-Token-work?language=en_US
- https://developer.okta.com/docs/reference/api/event-types/
- https://elastic.ac.cn/security-labs/testing-okta-visibility-and-detection-dorothy
- https://sec.okta.com/articles/2023/08/cross-tenant-impersonation-prevention-and-detection
- https://www.okta.com/resources/whitepaper-how-adaptive-mfa-can-help-in-mitigating-brute-force-attacks/
- https://elastic.ac.cn/security-labs/monitoring-okta-threats-with-elastic-security
- https://elastic.ac.cn/security-labs/starter-guide-to-understanding-okta
标签:
- 用例:身份和访问审计
- 数据源:Okta
- 战术:凭据访问
版本: 3
规则作者:
- Elastic
规则许可证: Elastic License v2
调查指南
编辑分类和分析
调查用于身份验证的 Okta 设备令牌 Cookie 生成数量过多
此规则检测到来自同一客户端地址的多个用户的 Okta 用户身份验证事件是否超过某个阈值。攻击者可能会尝试从同一设备发起凭据填充攻击,方法是使用已知用户名和密码列表来获取对用户帐户的未授权访问。请注意,Okta 不会记录身份验证尝试期间提供的未识别用户名,因此此规则可能无法检测到所有凭据填充尝试,或者可能表示针对性攻击。
可能的调查步骤
- 由于这是一个 ES|QL 规则,因此可以使用
okta.actor.alternate_id
和okta.client.ip
值来转到与此活动相关的原始身份验证事件。 - 通过检查
okta.actor.id
、okta.actor.type
、okta.actor.alternate_id
和okta.actor.display_name
字段来识别参与此操作的用户。 - 通过分析
okta.client.ip
、okta.client.user_agent.raw_user_agent
、okta.client.zone
、okta.client.device
和okta.client.id
字段来确定用于这些操作的设备客户端。 - 查看
okta.security_context.is_proxy
字段以确定该设备是否为代理。 - 如果该设备是代理,则可能表示用户正在使用代理访问多个帐户以进行密码喷洒。
- 使用
okta.actor.alternate_id
值列表,查看event.outcome
结果以确定身份验证是否成功。 - 如果任何用户的身份验证都成功,则可以转到这些用户的
event.action
值以提供其他上下文。 - 识别 Okta 最终用户后,查看
okta.debug_context.debug_data.dt_hash
字段。 - 历史分析应指示此设备令牌哈希是否通常与用户相关联。
- 查看
okta.event_type
字段以确定发生的事件类型。 - 如果事件类型为
user.authentication.sso
,则用户可能是出于安全或隐私原因通过代理合法地启动了会话。 - 如果事件类型为
user.authentication.password
,则用户可能正在使用代理访问多个帐户以进行密码喷洒。 - 如果事件类型为
user.session.start
,则源可能已尝试通过 Okta 身份验证 API 建立会话。 - 检查
okta.outcome.result
字段以确定身份验证是否成功。 - 通过检查其先前的操作来查看参与此操作的执行者(s) 的过去活动。
- 评估在
okta.event_type
字段中此事件之前和之后发生的事件,以帮助了解活动的完整上下文。 - 这可能有助于确定用户、Okta 和应用程序之间发生的认证和授权操作。
误报分析
- 用户可能是出于安全或隐私原因通过代理合法地启动了会话。
- 用户可能共享与工作或个人使用相关的端点,其中使用单独的 Okta 帐户。
- 从体系结构上讲,此共享端点可能出于安全或隐私原因利用代理。
- 自助服务终端和会议室计算机等共享系统可能被多个用户使用。
- 共享工作空间可能有一个由多个用户使用的单个端点。
响应和补救措施
- 查看参与此操作的用户的个人资料,以确定是否可以预期使用代理。
- 如果用户是合法的,并且基于设备分析身份验证行为没有可疑之处,则无需采取任何操作。
- 如果用户是合法的,但身份验证行为可疑,请考虑重置相关用户的密码并启用多因素身份验证 (MFA)。
- 如果已启用 MFA,请考虑重置用户的 MFA。
- 如果任何用户不是合法的,请考虑停用用户的帐户。
- 对 Okta 策略进行审查,并确保它们符合安全最佳实践。
- 与内部 IT 团队核实以确定相关帐户是否最近根据用户的请求重置了 MFA。
- 如果是,请与用户确认这是一个合法的请求。
- 如果是,但这不是一个合法的请求,请考虑暂时停用用户的帐户。
- 重置用户的密码并重置 MFA。
- 如果这是一个误报,请考虑将
okta.debug_context.debug_data.dt_hash
字段添加到规则中的exceptions
列表中。 - 这将阻止此设备的此事件将来触发规则。
- 或者,将
okta.client.ip
或 CIDR 范围添加到exceptions
列表中可以阻止此事件将来触发规则。 - 这应该谨慎操作,因为它可能会阻止生成合法的警报。
设置
编辑需要 Okta Fleet 集成、Filebeat 模块或类似结构的数据才能与此规则兼容。
规则查询
编辑FROM logs-okta* | WHERE event.dataset == "okta.system" AND (event.action RLIKE "user\\.authentication(.*)" OR event.action == "user.session.start") AND okta.debug_context.debug_data.request_uri == "/api/v1/authn" AND okta.outcome.reason == "INVALID_CREDENTIALS" | KEEP event.action, okta.debug_context.debug_data.dt_hash, okta.client.ip, okta.actor.alternate_id, okta.debug_context.debug_data.request_uri, okta.outcome.reason | STATS source_auth_count = COUNT_DISTINCT(okta.debug_context.debug_data.dt_hash) BY okta.client.ip, okta.actor.alternate_id | WHERE source_auth_count >= 30 | SORT source_auth_count DESC
框架: MITRE ATT&CKTM
-
战术
- 名称:凭据访问
- ID:TA0006
- 参考网址:https://attack.mitre.org/tactics/TA0006/
-
技术
- 名称:暴力破解
- ID:T1110
- 参考网址:https://attack.mitre.org/techniques/T1110/
-
子技术
- 名称:密码喷洒
- ID:T1110.003
- 参考网址:https://attack.mitre.org/techniques/T1110/003/
-
技术
- 名称:暴力破解
- ID:T1110
- 参考网址:https://attack.mitre.org/techniques/T1110/
-
子技术
- 名称:凭据填充
- ID:T1110.004
- 参考网址:https://attack.mitre.org/techniques/T1110/004/