在分析云中身份泄露事件的这些年里，我们发现相同的攻击者会定期出现，有些出现的频率更高。在我们了解到的攻击行为中，最活跃的攻击者就是我们称之为“EC2 Grouper”的攻击者。在过去几年中，我们在数十个客户环境中发现了该攻击者，这使他们成为我们跟踪到的最活跃的组织之一。该攻击者通常的嫌疑在于，他们在攻击中倾向于使用类似的用户代理和相同的安全组命名约定。
虽然用户代理甚至安全组名称等指标可以帮助归因和追踪，但我们发现它们对于全面的威胁检测并不可靠。在这篇博客中，我们将详细介绍与 EC2 Grouper 相关的策略，以及如何利用Lacework FortiCNAPP来检测此威胁等。更重要的是，我们将展示如何在不依赖特定于参与者的指标的情况下实现这一点，这些指标本质上可能是暂时的。
战术和技巧
EC2 Grouper 的特点是使用 AWS 工具通过 PowerShell 进行攻击。他们的用户代理推测了这一点，并且多年来一直保持一致：
AWSPowerShell.Common/4.1.90.0 .NET_Core/6.0.5 OS/Microsoft_Windows_10.0.17763 PowerShellCore/7.-1 ClientAsync
在最近的攻击中，他们更新了他们的 UA，现在包含新的版本和不寻常的 # 字符，这可能表明存在一种检测对策。
AWSPowerShell.Common/4.1.534.0 ua/2.0 .NET_Core#6.0.5 OS/windows#10.0.17763.0 md/ARCH#X64 PowerShellCore/7.-1 cfg/retry-mode#legacy md/ClientAsync
随着安全组命名约定的出现，出现了一个更加一致的指标。云中的攻击通常利用 CreateSecurityGroup API ( T1098 ) 来实现云环境中的远程访问和横向移动。EC2 Grouper 通常会尝试使用相同的命名约定（ec2group 加上 1-5 的顺序组合后缀）创建多个组。示例请求参数：
{"groupDescription":"ec2group","groupName":"ec2group"}
{"groupDescription":"ec2group1","groupName":"ec2group1"}
{"groupDescription":"ec2group12","groupName":"ec2group12"}
{“groupDescription”：“ec2group123”，“groupName”：“ec2group123”}
{"groupDescription":"ec2group1234","groupName":"ec2group1234"}
{"groupDescription":"ec2group12345","groupName":"ec2group12345"}
在所有 EC2 Grouper 攻击实例中，云活动似乎基本都是自动化的。攻击者首先会调用 DescribeInstanceTypes 来清点环境中的 EC2 类型，然后调用 DescribeRegions 来检索有关可用资源区域的信息。获取可用区域后，将针对每个可用区域迭代执行以下 API 调用：
- DescribeVpcs：请求有关给定区域中的 VPC（虚拟私有云）的信息。（T1580）
- CreateSecurityGroup：创建一个名为“ec2group”的新安全组。（T1098 和 T1021）
- DescribeSecurityGroups：查询账户中可用的安全组。
- DescribeAccountAttributes：获取账户属性，可能用于与资源相关的配额。（T1580）
- GetServiceQuota：检查服务配额，可能是为了确定资源使用限制。（T1580）
- DescribeInstances：收集有关可能正在运行、待处理或关闭的现有 EC2 实例的信息。（T1580）
- RunInstances：尝试使用 ec2group 安全组启动新的 EC2 实例。（T1496）
有趣的是，我们从未观察到对 AuthorizeSecurityGroupIngress 的调用，而这最终是配置对使用安全组启动的任何 EC2 的入站访问所必需的。然而，在几次情况下，我们观察到了 CreateInternetGateway 和 CreateVpc，它们是远程访问所必需的。到目前为止，我们还没有观察到什么可以归类为基于目标的操作或在受损云环境中的手动活动。这可能是因为 EC2 Grouper 在升级时是有选择性的，或者受损帐户在升级之前就被检测到并隔离了。尽管如此，资源劫持 (T1496) 可能是总体目标。然而，目前尚未确认其目的是什么。
检测
在涉及有效账户的每次攻击中，凭证肯定来自某个地方。泄露密钥的最常见来源之一仍然是代码存储库。开发人员经常错误地将云访问密钥提交到公共存储库。一旦发生这种情况，时间就开始流逝，直到凭证落入攻击者手中、被秘密扫描仪发现，或两者兼而有之。据信这是 EC2 Grouper 获取凭证的主要方法，因为他们的云攻击经常伴随着其他威胁行为者的攻击。然而，EC2 Grouper 是迄今为止据称使用这种方法最多的行为者。
鉴于在代码存储库中获取凭证的流行，寻找合法的秘密扫描服务作为检测策略的一部分是明智之举。这些包括 GitGuardian 和 Github 的秘密扫描服务。 在我们的综合警报中，我们将秘密扫描作为一个信号，因为它经常与非法凭证使用结合在一起出现。
[
]
当然，仅凭凭证检查并不能表明存在入侵，因此需要关联其他信号以减少误报。在对 EC2 Grouper 发出警报时，我们的复合警报评估了其他技术，例如使用已知在攻击中被利用的特定 API。在开源TDiscover 项目的帮助下，这些技术可以有效地映射到相应的技术。
[
最后，我们将异常作为综合警报的一部分进行评估。涉嫌攻击可能表现出恶意侦察或特权提升的特征。然而，通过异常检测来确认这一点至关重要。 [
结论
识别云中有效凭证的非法使用可能是一项细致入微且困难的任务。这给检测带来了相当大的挑战，因为绝大多数云攻击都涉及被盗用的凭证。虽然本博客中详述的攻击具有针对攻击者的策略和技术的各种原子指标，但大多数攻击并不表现出这些独特的特征。为了实现更高的准确性，关联涉及攻击者无法控制的方面的较弱信号变得更加重要。例如，虽然攻击者可以轻松控制其源 IP 和用户代理，但他们_无法_控制它是否对环境异常。同样，他们无法控制实现其目标所需的 API 或 API 序列。通过利用这些作为复合警报机制的信号，可以实现更高水平的检测效率
