随着许多组织将其基础设施、应用程序和数据迁移到云产品，攻击者也将其运营能力扩展到了云环境中，以实现其目标，无论是窃取知识产权、破坏业务运营，还是扣押组织的数据进行勒索。为了保护我们用户的数据免受攻击，Elastic Security 智能与分析团队研究并开发了规则，以检测云端和端点上的攻击者行为。
在这篇文章中，我们将讨论安全运营团队在云监控和检测方面面临的挑战，以及为什么针对云环境的攻击常常会成功。我们将分享有关我们免费云检测规则的详细信息（包括在Elastic Security 7.9中发布的许多新规则），并展示它们如何帮助Elastic Security用户。
我们还将解释 Elastic 如何从各种云平台提取日志，以及 Elastic 通用模式 (ECS) 如何使防御者能够轻松进行搜索、监控和检测。
云监控和检测的挑战
当要求安全团队监控、检测和响应组织云环境中的威胁时，他们通常会遇到以下一个或多个挑战
- 资源限制： 学习和理解云技术及其不断变化的数据源可能需要大量时间。许多安全运营团队没有资源来分配给这项持续的工作。
- 了解攻击者的策略：针对诸如 Windows 等知名平台上的攻击者行为已经过深入研究，并与安全社区共享。安全团队可能不深入了解攻击者如何在云环境中运行，或者不具备提供测试环境以实践攻防技术来保护其组织的能力。
- 盲点： 为了进行有效的监控和检测，安全从业者可用的数据必须是相关的、准确的和及时的。只要安全团队可以依赖数据的质量，那么发送到 SIEM 的云日志就可以用于检测和响应。
- 数据规范化： 大多数云平台都有自己的日志类别和事件模式。将日志规范化为通用模式并非一项简单的一次性任务。例如，一些安全团队在 SIEM 中索引的数据源中，对于主机名有几个不同的字段名称。如果没有规范化且有文档记录的模式，分析师（尤其是经验不足的分析师）可能很难编写搜索查询并有效地关联跨数据源的事件。
使用 Elastic 提取和搜索云日志
Elastic 拥有大量 Filebeat 模块，可用于简化将许多不同的日志格式收集、解析和可视化为通用模式（包括诸如Amazon Web Services (AWS)、Azure、Okta和Office 365 等云平台）。新 Filebeat 模块的快速开发是一个持续的过程。
Elastic 通用模式 (ECS) 定义了一组通用字段，用于将来自连接数据源（例如，AWS/Okta）的日志提取到 Elasticsearch 中。日志数据被规范化为一种格式，其中各种字段名称可用于查询中，以关联跨数据源的行为。这对安全和 IT 运营团队有很多好处。
从业人员和管理员无需花费大量时间来转换或规范化提取的日志，以使字段名称遵循他们自己的通用模式。自己管理这样的模式并非易事，而且是一项持续的工作。Elastic 管理 ECS（节省用户的时间和资源），以便安全团队可以依赖一组通用的字段名称来快速有效地搜索他们的数据。
最终用户可以在跨多个数据源进行搜索时依赖于在其查询中使用相同的字段名称，这具有以下优点
- 拥有一致的搜索模式可以节省安全分析师的时间，并降低新分析师的入门门槛。分析师无需学习或记住每个数据源的所有不同字段名称及其用途。
- 分析师可以关联跨数据源的事件，例如端点、代理和防火墙，这有助于他们更有效地查询数据，并在调查、事件或搜寻期间做出合理的决策。
- 分析师可以轻松生成时间轴或构建所发生活动的直观视图。
检测在云环境中运行的攻击者
Elastic Security 智能与分析团队对攻击者策略的研究产生了新的检测功能，例如规则和机器学习作业——这些功能使小型安全团队能够产生巨大的影响。诸如此类的安全功能增加了攻击者发动攻击的成本。Elastic Security 用户可以期望看到对增加云攻击成本的持续关注。
在这篇博文的其余部分中，我们将模拟针对 AWS 和 Okta 云环境的攻击技术。我们将回顾由可疑活动生成的警报，以及分析师如何使用 Elastic Security 执行初始分类并完成调查。我们还将演示分析师如何向检测规则添加例外，以便筛选良性事件并继续针对可疑行为发出警报。
监控 AWS CloudTrail 日志以检测可疑行为
随着组织迁移到或在 AWS 等云平台中提供新的基础设施，他们面临着我们之前描述的常见挑战。幸运的是，Elastic Security 提供了各种强大的 AWS 规则，可在7.9 版中免费使用，以检测 AWS 环境中的可疑行为。
适用于 AWS 的 Filebeat 模块可帮助您轻松地将 CloudTrail、简单存储服务 (S3)、弹性负载均衡 (ELB) 和虚拟私有云 (VPC) 流日志发送到 Elasticsearch，以便在 Elastic Security 中进行监控和检测。让我们来看一个利用 CloudTrail 数据的攻防场景。CloudTrail 提供 AWS 账户活动的事件历史记录，包括通过 AWS 管理控制台、AWS 软件开发工具包 (SDK)、命令行工具和其他 AWS 服务执行的操作。此事件历史记录有助于简化安全检测、分析和调查。
许多针对 AWS 的攻击都始于攻击者获取访问密钥和/或秘密访问密钥详细信息。可以通过多种方式收集这些密钥，包括通过网络钓鱼、数据泄露、GitHub 存储库、屏幕截图、错误消息、快照数据或仅仅是糟糕的密钥管理实践。通过获取这些密钥，攻击者可以对您的 AWS 基础设施采取各种操作。
让我们来看一下可能发生的许多潜在攻击场景之一。在以下示例中，攻击者枚举了已为 AWS 账户配置的跟踪和监控功能。他们在执行此操作后，禁用跟踪和配置记录器，以试图逃避检测，然后继续收集机密。
模拟 AWS 中的攻击者行为
在此演示中，我们将使用 Pacu 来执行攻击。Pacu 是一个流行的 AWS 基础设施利用框架，由 Rhino Security Labs 开发和维护。Pacu 采用模块化设计，类似于 Metasploit 和 Koadic 等其他漏洞利用框架，使攻击者能够利用 AWS 账户中的配置缺陷。攻击者可以使用 Pacu 在尝试执行模块之前检查是否已将所需权限分配给受攻击的账户。从攻击者的角度来看，这有助于避免创建不必要的噪音和日志，并通过运行最终会失败的模块来引起防御者的额外关注。
攻击者首先使用 detection__enum_services 模块枚举服务，以确定为 AWS 账户启用了哪些日志记录和监控服务。
攻击者发现了八个跟踪、十个配置规则、一个记录器和一个交付通道。本质上，枚举脚本正在查询某些 AWS API 调用，以列出或描述有关环境的相关信息。通过查看该模块的 代码，我们可以看到目标 API。
DescribeSubscription
GetSubscriptionState
DescribeTrails
ListDetectors
DescribeConfigRules
DescribeConfigurationRecorders
DescribeConfigurationRecorderStatus
DescribeDeliveryChannels
DescribeDeliveryChannelStatus
DescribeConfigurationAggregators
DescribeAlarms
DescribeFlowLogs在攻击者确定正在运行的服务后，他们的下一个逻辑步骤可能是通过禁用跟踪、警报、检测器或记录器来中断日志记录和监控，以试图逃避检测。为了实现此目标，我们将使用一个名为 detection__disruption 的不同模块来禁用名为 brentlog 的跟踪，并停止名为 default 的配置记录器。
此时，随着跟踪日志的暂停和配置记录器停止跟踪资源更改，攻击者可能希望检查 Secrets Manager 中是否有任何凭据、API 密钥或令牌可用，如果有，则收集它们。在本场景中，攻击者使用 enum_secrets 模块，并在目录 /sessions/brent/downloads/secrets/secrets_manager 中找到一个密钥。收集这些密钥可以帮助攻击者实现横向移动和/或特权提升。
我们将在此处停止我们虚构的攻击场景，但如果您好奇地想了解攻击者接下来可能采取的行动，以下 Google 搜索将返回一些示例：intitle:"AWS" intext:("attack" | "breach")。在下一节中，我们将从防御者的角度来看一下这种行为是什么样的，以及如何使用 Elastic Security 来检测这种行为。
检测和调查 AWS 中的可疑行为
在监控先前提及的 API 的使用情况时，可能很难区分良性活动和可疑行为，例如攻击者枚举环境。在生产环境中，监控对这些 API 的调用可能会很嘈杂，因为这种行为非常常见。为了帮助找到这种罕见且可能可疑的行为，除了我们提供的 AWS 检测规则之外，我们在 7.9 中专门针对 AWS CloudTrail 发布了 机器学习 作业，这些作业有助于识别异常值，例如使用传统检测规则很难找到的不寻常活动模式。
查看我们先前攻击的检测页面，我们可以看到触发了多个警报。我们免费的内置检测规则识别出了暂停跟踪、停止配置记录器以及从密钥管理器获取敏感信息的技术。其他警报来自 AWS 命令的异常国家/地区 和 用户的异常 AWS 命令 的机器学习作业，它们识别出对于该命令来说不寻常的地理位置（国家/地区）或通常不使用该命令的用户上下文。
如果我们深入研究其中一个机器学习警报，我们可以看到它检测到的内容的描述，以及一个内置的调查指南，引导分析师完成分析异常 CloudTrail 事件时的潜在工作流程。
我们还可以查看来自 AWS 配置记录器已停止 警报的时间线视图中的详细信息。我特别感兴趣的字段是 API 调用、用户代理字符串、用户身份类型、请求参数和整个事件的原始文本。
通过分析警报，我们可以快速确定
| 字段 | 描述 |
| event.action | 告诉我们发出的 AWS API 调用，StopConfigurationRecorder |
| request_parameters | 提供有关请求中发送内容的详细信息，在我们的例子中，是配置记录器名称 default |
| user.name | 告知我们是谁发出的请求，pacu |
| user_identity.type | 包含有关身份和访问管理 (IAM) 身份类型的详细信息。在我们的例子中，是 IAMUser。Root 是我们内置规则的另一种用户身份类型。 |
| user_agent | HTTP User-Agent 标头的值。用户代理字符串可以轻松修改，但如果账户通常使用 AWS Java SDK 进行 API 调用，并且它发生更改，那么检测到异常的用户代理字符串可以快速取胜。 |
| event.original | 提供原始警报详细信息 |
表 1 - 警报字段分析
分析警报后，我们可以开始拼凑事件，并查看用户在触发警报之前（以及之后（如果适用））采取了哪些操作。同样，我们也可以在这里发现攻击者的枚举行为。
我们可能还想在我们的环境中搜索特定的 API 调用，以查看它们是否被其他用户或主机、来自不同的 IP 或在其他时间框架内调用，这些在我们的环境中可能是可疑的。
我们还可以创建一个可视化，以查找我们环境中不常见的 API 调用，并从那里进行深入分析。对于 AWS，API 调用位于 event.action 字段中。
如演示所示，我们免费的 AWS 内置规则可以检测到此活动以及许多其他潜在的攻击场景。我们已经开放了我们的 规则存储库，并鼓励您查看并了解如何 贡献（如果感兴趣）。
检测 Okta 日志中的可疑行为
Okta 单点登录 (SSO) 是一种云解决方案，允许用户通过集中式流程使用单个用户帐户登录到其组织中的各种系统。告知最终用户他们只需要记住一个用户名和密码，而不是十个或更多，这降低了他们采用不良密码习惯的风险，并使系统管理员能够实施更强的密码策略。此外，可以在 Okta 中配置多因素身份验证 (MFA) 策略，这提高了攻击者的进入门槛。当攻击者发现其目标网络或用户帐户强制使用 MFA 时，许多攻击者只会转而寻找更容易的目标。
虽然 SSO 解决方案可以提供方便的用户体验并降低组织的网络安全风险，但这些集中式系统为许多系统和应用程序提供了一种骨架钥匙，通常是攻击者的诱人目标。例如，如果攻击者设法收集到 Okta 管理员的凭据或 API 令牌，他们可能会尝试执行以下非详尽列表中的任何操作
- 修改或禁用一个或多个应用程序的 MFA 策略，以削弱受害者的安全控制。
- 创建新的用户帐户或 API 令牌，以在其目标环境中保持持久性，并尝试“融入”并逃避检测。
- 修改、删除或停用 Okta 网络区域，以放松对用户或管理员可以从中登录的地理位置的限制。
- 删除或禁用应用程序或其他配置，以创建拒绝服务 (DoS) 状况并影响公司的业务运营。
为了使安全团队能够监控其 Okta 环境中的可疑活动，我们的 Okta Filebeat 模块可以提取 Okta 系统日志事件，并将其发送到 Elasticsearch 进行索引。Okta 的系统日志记录与组织相关的事件，以便提供一个审计跟踪，可用于了解平台活动。Elastic 安全情报与分析团队拥有 免费规则来检测 Okta 日志中的可疑活动，并将在未来继续添加更多规则。
在以下示例中，假设攻击者在获得对组织网络的初始访问权限后收集了一个 API 令牌。该 API 令牌具有管理员权限，攻击者在其目标 Oka 环境中执行了一些操作
- 创建一个新的用户帐户并为其分配管理权限，以便在安全团队发现当前 API 令牌已泄露时，在目标环境中保持存在
- 停用登录策略，以削弱目标的安全控制
- 禁用网络区域，以使攻击者能够在入侵期间从任何地理位置进行身份验证
Okta Filebeat 模块已配置为将 Okta 系统日志事件发送到 Elasticsearch，并且我们的 Okta 规则已在 Elastic Security 中激活。可疑活动触发了下面图 12 中所示的三个警报。
单击其中一个警报使分析师可以查看有关该规则的更多信息，包括该规则检测到的行为的描述、严重性和风险评分，以及相关的 MITRE ATT&CK® 战术和技术。分析师可以向下滚动页面，并在时间线中开始调查警报。
要了解有关 Elastic 如何支持 ATT&CK 的更多信息，请参阅我们的演示文稿：如何计划和执行狩猎。
安全从业人员知道每个组织的网络都不同。在一个环境中看起来可疑的行为可能在另一个环境中是良性的。为了帮助安全团队在“噪声”中找到所谓的“信号”，用户可以向其检测规则添加例外，以过滤良性事件并继续警报可疑事件。图 14 显示了正在向 Okta 规则添加例外。
我们还引入了“阈值”规则类型。阈值规则会聚合查询结果，并在匹配事件的数量超过特定阈值时生成警报。当来自单个源 IP 地址发生 25 次 Okta 用户身份验证失败时，下面的示例规则将生成警报。这可能表示暴力破解或密码喷洒攻击。
在时间线中查看阈值规则生成的警报使分析师可以查看触发该规则的事件，并开始其分类过程或调查。
结论
根据 Verizon 最新的数据泄露调查报告，去年审查的 3,950 起数据泄露事件中，有 24% 涉及云资产。随着各组织不断将其数据和业务运营迁移到云端，我们可以预计这个数字将会增加。
在这篇博客文章中，我们讨论了安全团队在尝试监控、检测和调查其组织云环境中的可疑行为时面临的一些挑战。我们通过一些实际的例子，说明了攻击者如何在云环境中运作，以及 Elastic Security 如何检测这些技术。
Elastic Security 情报与分析团队研究攻击者的手段，并为包括云在内的多个平台开发新的检测规则和机器学习作业。我们的用户可以期待我们继续专注于增加云攻击的成本。
配置我们的 Filebeat 模块以将日志发送到 Elasticsearch，并在 Elastic Security 中启用检测规则非常容易。我们的免费检测规则可帮助安全团队监控这些日志并检测可疑行为，无论其团队规模大小。Elastic Security 使分析师能够快速有效地分类和调查这些警报。
如果您有兴趣了解更多关于 Elastic Security 的信息，您可以免费下载它，或注册 Elastic Cloud 的 14 天免费试用。