« 代理后具有相同设备令牌哈希的多个 Okta 用户身份验证事件 具有相同设备令牌哈希的多个 Okta 用户身份验证事件 »
Elastic 文档 ›Elastic 安全解决方案 [8.14] ›检测和警报 ›预构建规则参考

多个 Okta 用户身份验证事件（具有客户端地址）

编辑

多个 Okta 用户身份验证事件（具有客户端地址）编辑

当从同一客户端地址报告了针对多个用户的超过特定阈值的 Okta 用户身份验证事件时发出警报。攻击者可能会尝试使用已知用户名和密码列表从同一设备发起凭据填充或密码喷洒攻击，以获取对用户帐户的未经授权的访问权限。

规则类型: esql

规则索引: 无

严重性: 低

风险评分: 21

运行间隔: 5 分钟

搜索以下时间段的索引: now-9m（日期数学格式，另请参阅 额外回溯时间）

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

参考:

标签:

  • 用例: 身份和访问审计
  • 数据源: Okta
  • 战术: 凭据访问

版本: 1

规则作者:

  • Elastic

规则许可证: Elastic 许可证 v2

调查指南编辑

分类和分析

调查多个 Okta 用户身份验证事件（具有客户端地址）

当从同一客户端地址报告了针对多个用户的超过特定阈值的 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 字段以确定身份验证是否成功。 - 通过检查参与此操作的行为者之前的操作来查看他们的过去活动。 - 评估在 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 == "user.session.start" OR event.action RLIKE "user\\.authentication(.*)")
    AND okta.outcome.reason == "INVALID_CREDENTIALS"
| STATS
    source_auth_count = COUNT_DISTINCT(okta.actor.id)
    BY okta.client.ip, okta.actor.alternate_id
| WHERE
    source_auth_count > 5
| SORT
    source_auth_count DESC

框架: MITRE ATT&CKTM

« 代理后具有相同设备令牌哈希的多个 Okta 用户身份验证事件 具有相同设备令牌哈希的多个 Okta 用户身份验证事件 »