金丝雀基础设施与现实世界的 TTP

有效的云安全侧重于威胁行为者在现实世界事件中使用的技术。我维护aws-customer-security-incidents以整合有关这些事件和行为者的公共数据。

金丝雀（尤其是金丝雀基础设施）是一种优雅的方法，可以自信地对以下操作发出警报：

• 在正常业务过程中不应该发生这种情况，并且

• 攻击者无法抗拒采取

Tracebit更深入地概述了其好处，但其基本思想是在您的云环境中植入绊线，根据常见的攻击者 TTP 触发高信号警报。

让我们看一下最近三起（复杂的）AWS 安全事件，并讨论金丝雀如何帮助您在整个攻击生命周期中尽早检测到这些事件。

勒索软件攻击

第一个案例来自 Yotam Meitar，他在 fwd:cloudsec 2024 的演讲中分享了细节：“应对云端复杂的勒索攻击：一个真实案例研究”-https://www.youtube.com/watch?v=f066e7WndTQ

在这起事件中，一名工程师将一个已知存在漏洞的应用程序部署到了 EKS Pod。该应用程序原本用于测试，仅在内部公开，但已部署到生产环境中。另一名员工意外更改了管理该应用程序访问权限的共享安全组，并将其公开。

攻击者在一次非针对性扫描中很快发现了暴露的漏洞。他们入侵了 Kubernetes Pod，从而获得了 EC2 实例 IAM 角色。此角色对 Secrets Manager 具有过度特权的访问权限。一个可访问的机密授予了绕过正在使用的自定义身份提供者的能力。最后，通过身份提供者的访问权限，攻击者能够从 S3 存储桶中窃取 MongoDB 备份。

从最初访问开始，这次攻击只持续了几天。受害组织在收到赎金通知后才意识到这一点。Yotam 明确表示，这种速度在云事件中很常见。

使用 Tracebit 检测此攻击

应对云端复杂的勒索攻击：真实案例研究 – Yotam Meitar

这次攻击“速度很快”，但金丝雀的速度更快。在这种情况下，我们可以看到金丝雀基础设施有几次机会提供攻击的早期预警。

• 实例入侵：攻击者最初的立足点是 EKS 中运行的受感染应用程序。Canary Credentials 可以放置在多个常见位置，应用程序和 EKS Pod 都可以访问这些位置，包括环境变量和众所周知的 `.aws/` 配置文件。在这种无针对性的攻击中，攻击者通常会在这些位置搜索和使用凭证。

• Secrets Manager：攻击者继续使用实例的 IAM 角色访问 Secrets Manager 中的机密。Tracebit 支持创建适合您环境的 Canary Secrets Manager 机密。

• 身份提供者：自定义身份提供者是此受害者独有的。但是，它可以与非常灵活的 Canary Credentials 一起使用，以检测绕过或破坏这种关键服务。如果受害者使用的是 Okta，Tracebit 可以更进一步，为 Canary Okta 应用程序提供原生支持。

• S3：访问和泄露 S3 数据为使用金丝雀 S3 基础设施捕获攻击者提供了最后的机会。理想情况下，你可以在攻击者开始泄露数据之前就捕获他们。然而，正如我在Guardduty 研究中发现的那样，你应该分层部署金丝雀以确保可靠、确定性的检测。

SugarCRM

Unit42 的 Margaret Zimmermann在 Black Hat和一篇博客文章中分享了与 SugarCRM 远程代码漏洞 ( CVE-2023-22952 )相关事件的详细信息。

在一个案例中，SugarCRM 在 EC2 上运行。攻击者通过上述漏洞获得初始访问权限。然后，攻击者能够从主机上的纯文本凭证文件中获取长期访问密钥。获得这些凭证后，他们使用其访问权限对 AWS 控制平面执行发现调用。此发现活动包括 GetCallerIdentity、AWS Organizations 和 Cost & Usage。此外，攻击者还运行Pacu和ScoutSuite来扫描广泛的 AWS 服务。攻击者继续利用和渗透，目标是 RDS。攻击者能够创建 RDS 实例的快照，将其暴露在端口 3306 上，并在攻击者控制的帐户中恢复快照。

总体而言，这些攻击持续了数周，其中 AWS 组件持续了数天。Unit42 观察到，发现阶段似乎快速且自动化，但泄露速度较慢，并且根据观察到的拼写错误，显然是手动操作。

使用 Tracebit 检测此攻击

当零日漏洞和访问密钥在云端发生冲突时 – Margaret Zimmermann

虽然这个攻击链比勒索软件案例的复杂程度要低得多，但它提供了大量的金丝雀基础设施检测机会。

1. 实例入侵：攻击者最初的立足点是运行在 EC2 实例上的受感染应用程序。在这种情况下，他们在 `.aws/` 配置文件中找到了有效凭证。但是，金丝雀凭证仍然可以与这些有效凭证一起放置，或者更好的是，可以与使用更安全的实例角色（使用 IMDSv2）同时实施。

2. 嘈杂的发现：这次攻击采取了分散式的发现方法，包括运行 Pacu 和 ScoutSuite。整个环境中的 Canary 基础设施会迅速发出这种广泛枚举的信号。安全工具的误报噪音可能会淹没这个信号，这就是为什么 Tracebit 被设计为自动过滤掉您现有的安全工具。Pacu 具有会在各种 Canary 资源上触发的模块，例如 Tracebit 的 SSM 参数和 DynamoDB 表。ScoutSuite 的 IAM 和 S3 枚举是 Canary 检测的其他机会。

Scattered Spider / LUCR-3 / UNC3944 / Star Fraud / Octo Tempest / Scatter Swine / Muddled Libra

Scattered Spider 可能是针对云环境的最活跃且最受关注的威胁行为者。有关该组织的报告来自以下机构：

• CISA——分散蜘蛛

• Mandiant – 你为什么给我发短信？UNC3944 利用短信网络钓鱼活动进行 SIM 卡交换、勒索软件、敲诈勒索和恶名昭彰

• Reliaquest – 分散蜘蛛攻击分析

• Crowdstrike – 并非模拟：CrowdStrike 调查揭露针对电信和 BPO 公司的入侵活动

• Unit42 – 混乱中的 Libra 向云端的演进

• Permiso – LUCR-3：分散蜘蛛在云中实现 SaaS 化

这里没有单个案例可介绍，但我们可以从这些报告的细节中整合出“标准”的分散蜘蛛云攻击链。

Scattered Spider 通常从有针对性的社会工程学开始，其中还可能涉及网络钓鱼、短信钓鱼、SIM 卡交换和 MFA 疲劳策略。获得初始访问权限后，他们会：

• 搜索内部文档、聊天记录和代码，主要针对凭证

• 部署恶意软件以窃取凭证，并在受害者的系统上搜索不安全存储的凭证

• 访问身份提供商 (Okta) 仪表板并使用连接的应用程序和 CSP 环境

• 枚举敏感的 AWS 服务，包括 AWS S3 和 Secrets Manager

在窃取了足够多的数据后，Scattered Spider 便会通过窃取数据、敲诈勒索和部署勒索软件等方式来获取经济利益。

使用 Tracebit 检测此攻击

Scattered Spider / LUCR-3

Scattered Spider 所展现的发现广度，加上其对云资源和身份提供商的关注，使其很容易受到 Canary Infrastructure 的早期检测。

• 嘈杂发现：该威胁行为者倾向于搜索内部聊天记录、文档和代码存储库，所有这些都为播种金丝雀凭证提供了机会。

• 凭证窃取恶意软件：特别是如果您没有使用静态凭证，在员工笔记本电脑上部署金丝雀凭证可以诱使攻击者进行早期检测。

• 身份提供者：Tracebit 的原生 Okta 金丝雀可以完美地捕捉到该行为者通过员工 IdP 仪表板进入连接应用程序的模式

• S3 和 Secrets Manager：使用 S3 基础设施和 S3 存储桶内的 Canary 数据，访问和泄露 S3 数据为捕获攻击者提供了最后的机会。同样，Tracebit 的 Canary Secrets Manager Secrets 根据您的环境量身定制，对 LUCR-3 来说是一个诱人的诱惑

总结

有句俗话说：“以云的速度，检测为时已晚。”

‍我觉得这是失败主义。虽然我们通常说云攻击是高度自动化的并且发生得很快，但这些案例表明，即使是经验丰富的攻击者也可能需要数天才能实现其目标。

仅从这一小部分攻击样本来看，我们还可以看到攻击者技术的多样性。有些涉及 EC2 实例或 EKS。有些攻击者以 S3 为目标，其他攻击者则以 Secrets Manager 或 RDS 为目标。我们发现自定义 IdP 和 SaaS IdP 均受到攻击。

Canary Infrastructure 提供了灵活且有针对性的检测机会来应对这些攻击。Canary 凭证是便携式绊网的一个例子，它可以检测从凭证窃取恶意软件到实例泄露的一切。另一方面，Tracebit 的原生 Okta Canaries 为 Scattered Spider 对 IdP 的关注提供了一个独特的伪装答案。