云环境攻击模拟利器:Stratus Red Team 技术解析
今天,我很高兴发布一个过去几周一直在开发的新开源项目:Stratus Red Team,这是一个对抗模拟和紫队测试工具,专注于在云环境中模拟常见攻击技术。
开发动机
我的专业经验很大程度上涉及威胁检测。从学校毕业后,我首先在一家专注于终端安全的本地托管检测与响应公司从事威胁检测用例工作。后来当我转到一家科技公司的云安全岗位时,我发现检测云中的恶意活动面临着类似的挑战。
其中之一是在实时环境中重现攻击者的战术、技术和程序(TTPs),以验证我们的日志管道和检测逻辑是否能够端到端正常工作。对于传统的终端和本地安全,存在几个开源项目,如Atomic Red Team™或MITRE Caldera。然而,这些工具都不是云原生的,没有考虑云提供商和基础设施,或者缺乏足够数量的云聚焦攻击技术。
认识 Stratus Red Team
Stratus Red Team 是一个在2021年初开始在我脑海中成熟的项目。得益于我在Datadog担任云安全研究员的新职位,我终于能够执行它,并且我很自豪我们将其作为100%免费和开源软件发布!
https://stratus-red-team.cloud/ https://github.com/DataDog/stratus-red-team
您可以在Datadog博客上阅读官方公告: https://www.datadoghq.com/blog/cyber-attack-simulation-with-stratus-red-team/
我建议您先阅读那篇文章,然后继续阅读这里。为了避免内容重复,我不会涵盖基础知识。
什么是 Stratus Red Team?
Stratus Red Team 是一个轻量级的Go二进制文件,您可以轻松安装。它打包了许多AWS特定的攻击技术。每个攻击技术都有一个文档页面,从源代码自动生成。
Stratus Red Team 处理启动执行攻击技术所需的任何基础设施或配置。这就是它所谓的"预热"攻击技术。一旦攻击技术"预热"完成,它就可以被"引爆",即执行以模拟其意图模拟的攻击者行为。
底层工作原理
攻击技术即代码
在底层,每个攻击技术包括:
- 一段Terraform代码,描述Stratus Red Team在引爆攻击技术之前需要部署的先决条件基础设施
- 一段Go代码,定义技术元数据及其引爆逻辑
让我们看一个攻击技术"停止CloudTrail跟踪"的例子。先决条件的Terraform代码定义了一个记录到S3存储桶的CloudTrail跟踪。攻击技术定义包括其名称、与MITRE ATT&CK的映射以及引爆函数。在这里,引爆包括停止CloudTrail跟踪。
Terraform(先决条件基础设施)
|
|
Go(攻击技术定义)
|
|
编排 Terraform
Stratus Red Team 使用 Terraform 来启动和销毁先决条件的基础设施和配置。这对最终用户是透明的。您甚至不需要安装 Terraform!Stratus Red Team 使用 Hashicorp 的 terraform-exec 库来下载和编排 Terraform。Terraform 二进制文件存储在 ~/.stratus-red-team/terraform,因此不会与您现有的 Terraform 版本冲突。
当您预热或清理技术时,Stratus Red Team 以编程方式调用 terraform apply 和 terraform destroy。
状态存储
Stratus Red Team 是有状态的。它需要保持关于以下内容的状态:
- 每个攻击技术的状态
- 每个攻击技术先决条件的 Terraform 状态
- 每个攻击技术先决条件的 Terraform 输出
它将此信息存储在您的本地文件系统上,位于 ~/.stratus-red-team/[technique-id] 下。
理念和设计选择
在构建 Stratus Red Team 时,我不得不做出几个设计选择。本节充当架构决策记录,给出这些选择背后的理由。
编程语言:Python vs. Go
虽然我之前接触 Python 更多,但它也是我因为缺乏静态类型而积极不喜欢的语言。根据我的经验,这使得开发缓慢且容易出错 - 尤其是在使用第三方库(如 AWS SDK)时。更重要的是,Python 没有可靠的 Terraform 包装器。
这就是我选择使用 Go 的原因。Hashicorp 维护了一个官方的 Terraform 包装器。Go 是强类型的,这意味着在使用 AWS SDK 时,您确切知道它期望什么类型、字段名称和字段类型。这大大加快了开发工作流程:如果它编译了,您就有信心它能运行。
选择 Go 的主要缺点是缺乏可扩展性。与 Python 相反,Go 无法轻松动态加载用户提供的代码。这意味着向 Stratus Red Team 添加新攻击技术的唯一方法是将它们打包到主二进制文件中,或者在将 Stratus Red Team 用作库时以编程方式定义它们。
处理先决条件基础设施
攻击技术需要先决条件基础设施才能运行。例如,从 VPC 中移除 VPC 流日志的攻击技术需要 VPC、VPC 流日志配置和 CloudWatch 日志组。
有几种方法可以解决这个问题:
- 让最终用户负责手动创建所需的基础设施
- 向最终用户提供 Terraform 代码,并让他们负责创建所需的基础设施
- 将 Terraform 代码打包在二进制文件中,并负责创建和移除所需的基础设施
我觉得选项 1 和 2 对于 CLI 工具没有带来太多价值。它们更适合"利用演练"或教程,因为它们没有封装复杂性。
这就是为什么我选择选项 3。在减少复杂性的同时,它也给最终用户更少的灵活性。通常,Stratus Red Team 目前不支持针对现有基础设施引爆攻击技术。例如,当引爆"通过存储桶策略后门 S3 存储桶"时,Stratus Red Team 将创建一个新的 S3 存储桶并对其引爆技术。您不能将其指向现有的 S3 存储桶。如果您觉得这是一个重要的限制,请在相应的问题中告诉我!
什么构成了好的攻击技术?
对我来说,能够回答这个问题很重要:Stratus Red Team 中打包了哪些攻击技术,为什么?这是我对这个问题的有主见的看法,我在理念页面中更详细地讨论了这一点。
- 技术应该是细粒度的,即模拟攻击链的单个步骤。
- 技术应该模拟合理的攻击者活动。应该总是可以从中推导出现实的威胁检测规则。一个不现实检测的例子是:每次调用
sts:GetCallerIdentity时发出警报。 - 技术应该是自包含的,不应该对您的 AWS 账户的先前状态做任何假设。这说起来容易做起来难,因为它使得实现诸如"禁用 GuardDuty 检测器"这样的技术具有挑战性(因为 AWS 每个区域只允许一个 GuardDuty 检测器)。
虽然这些是主观和有主见的,但我希望确保 Stratus Red Team 仍然是一个云安全从业者可以用来测试、验证和增强现实世界威胁检测用例的项目。
选择支持的平台
从一开始,我就设想 Stratus Red Team 应该支持多个云平台 - 我以此为目标构建了它。对于初始版本,我选择专注于 AWS。我计划在未来添加 Kubernetes 和 Azure 支持,可能还有 GCP。
关于测试
Stratus Red Team 的核心带有非平凡的逻辑。在这种情况下,对我来说拥有一些单元测试是必不可少的。我编写了超过 35 个单元测试,并在此过程中学到了很多。一个教训是,您越早考虑测试,以后需要进行的重构就越少。
一旦我处理了核心,我想知道如何处理攻击技术的测试,这些技术也被定义为 Go 代码。不幸的是,我发现没有好的解决方案。AWS SDK for Go V2 没有提供任何允许生成模拟的 Go 接口。不过多深入细节,这意味着在使用的 AWS 服务和 API 调用旨在快速发展的环境中,对攻击技术进行单元测试具有挑战性。
我们可以在另一个级别测试攻击技术:针对实时 AWS 账户引爆它们,并确保引爆产生了预期的结果。但这会很慢,容易出错,并且增加的价值有限。这就是为什么目前没有攻击技术代码的单元测试。
Stratus Red Team 的下一步计划
我很自豪能够在几周内发布 Stratus Red Team,并且非常高兴我的雇主 Datadog 给了我这个机会。现在初始版本已经发布,我渴望听取您的反馈,并用它来改进项目。什么工作得很好,您会改进什么?您喜欢什么,或者缺少什么?我很想听听您的意见 - 我的 Twitter 私信是开放的。您也可以给我发送电子邮件,或打开 GitHub 问题。
在社区的初步反馈和使用之后,我希望:
- 添加更多 AWS 攻击技术
- 引入 Kubernetes 支持
- 引入可选遥测以了解人们最常使用的攻击技术(默认关闭)
感谢阅读!让我们在 Twitter 上继续讨论。