本文为译文，原文链接：https://www.chrisfarris.com/post/aws-ir/
今天在BSides Atlanta上，我发表了关于如何在 AWS 中处理事件的演讲。该演讲和这篇文章旨在帮助那些已经熟悉事件响应原则的人了解当事件涉及 AWS 控制平面时该怎么做。您可以在此处找到幻灯片。
为什么 AWS 和云中的 IR 不同？
因为一切都需要凭据。信用在每个人的云应用程序中飞来飞去。长期凭证，短期凭证，都是一串串。如果您知道在哪里查找，字符串很容易找到。EC2 实例元数据服务在 169.254.169.254 上分发它们。您可以在 Lambda 函数的环境变量中找到它们。Fargate 容器有一个环境变量，它告诉您要 curl 的内部 URL。
所有这些凭据都可以访问查看或修改您的基础架构。要正确响应事件，您需要知道攻击者更改了什么。幸运的是，AWS 的 API 驱动特性可以帮助您。
准备
CloudTrail
用于事件响应的最重要的 AWS 服务是 AWS CloudTrail。CloudTrail 记录对您的 AWS 账户的每个经过身份验证的 API 调用。每个 CloudTrail 事件都包括执行 API 调用的主体、API 调用的来源 IP 地址、进行 API 调用的时间、针对哪个服务执行的操作以及受调用影响的资源。
CloudTrail 和 IAM 是相互关联的，理解其中一个有助于另一个。几乎每个对 AWS 的 API 调用都经过身份验证，并且所有 API 调用都必须经过授权。这是通过 IAM 完成的。虽然 IAM 策略创建可能非常复杂，但策略语句的核心是可以执行的特定操作。这些按服务和 API 操作细分，然后在 CloudTrail 中显示为 eventSource 和 eventName。
| IAM 动作 | 事件源 | 事件名称 |
| ---------------------- | ------------------------ | ----------------- |
| ec2:DescribeInstances | ec2.amazonaws.com | DescribeInstances |
| iam:CreateUser | iam.amazonaws.com | CreateUser |
| s3:DeleteBucket | s3.amazonaws.com | DeleteBucket |
| cloudtrail:StopLogging | cloudtrail.amazonaws.com | StopLogging |
并非所有经过身份验证的事件都记录在 CloudTrail 中。只有管理事件。如果要跟踪对特定数据源（如 S3、DynamoDB 或 Lamba 函数）的访问，则需要为 CLoudTrail 启用数据事件。不幸的是，这不是免费的。DataEvents 每 100,000 个事件花费 10c。这可以加起来，但另一种选择是必须向法律顾问解释您不知道数据是否被泄露。
GuardDuty
您要启用的下一个服务是 GuardDuty。Amazon GuardDuty 是 AWS 的托管威胁检测服务，它利用三个主要数据源：
安全帐户和审计角色
我强烈支持拥有一个专用的安全账户，并且为安全工具创建一个专用账户是 AWS 的治理最佳实践之一。您应该将此帐户用于 GuardDuty 和 Macie 等组织范围的安全工具。对于部署到您组织的所有 AWS 账户中的安全审计角色，该账户也应该受到信任。确保您的 SOC 和 IR 团队可以登录安全帐户（只读访问），并能够在所有其他帐户中担任安全审计角色。
如果您的组织有这种倾向，最好有一个专门的响应者角色，该角色具有安全审计角色的所有可见性，以及执行本文中记录的部分或全部遏制措施的能力。与您的中央云工程团队合作，定义安全性可以采取哪些步骤来执行遏制，以及需要将哪些内容上报给云团队或应用程序所有者。
最后，不要将此帐户用于安全工作负载（例如您的 SEIM 或 EDR）。你放在那里的网络东西越多，安全帐户本身被破坏的机会就越大。
SEIM & 搜索
所有这些数据都需要可搜索。还需要可搜索的是您的本地和其他遥测数据。您如何将您的 CloudTrail sourceIPAddress 与您的 VPN 日志或 SSO 提供商相关联？
即使您没有 SEIM 或 SOAR 平台，也可以使用 Slack 之类的工具向您的响应者发出警报。
Inventory
Inventory对于了解您拥有什么并围绕您的活动装饰业务环境至关重要。如果您在一个帐户中看到异常行为，那是一个没有人应该访问的 prod 帐户，还是一个用于测试事物的沙盒？受影响的资源是否有 PII、PCI 或财务数据？您需要就活动联系谁？
所有这些都是 AWS 无法提供的关键业务环境。
我将在以后的博客文章中讨论这个问题，但Steampipe是一个很有价值的工具来提取帐户库存信息。我已经构建了一些脚本来将 Steampipe 数据提取到 Splunk 查找表中。
相关联系
这就是我建议公司架构师将核心遥测数据纳入他们的 SEIM 的方式——特别是对我来说，Splunk。
利用 AWS Organizations 和 Delegated Admin 的功能在所有账户中启用和管理 CloudTrail 和 GuardDuty
对于 CloudTrail，利用 S3 事件和 SQS 告诉 Splunk 要摄取哪些对象。
对于 GuardDuty，将 Lambda 订阅到事件总线并通过 HTTP 事件收集器推送结果。
利用 Steampipe 或您的 CMDB 作为活动的装饰。具体来说：
5.利用其他数据源，如 VPN 日志、SSO 身份验证等。
安全联系人和根邮件
为帐户设置安全联系人通常被忽略，但非常重要。默认情况下，AWS 会向账户的根电子邮件地址发送严重滥用和安全通知。但是，安全团队很少参与其中，AWS 会向根地址发送大量其他营销垃圾邮件。
为您的公司建立一个云安全警报分发列表，并将其设置为您所有 AWS 账户中的安全联系人。AWS 现在允许您通过 API 做到这一点，我已经编写了一个快速修复来帮助.
其他工具
- VPC FlowLogs 将帮助您了解网络平面的内容。谁从你的城堡进进出出？
- 准备执行 EC2 或容器取证操作最好在您需要之前完成。
- Detective 是 AWS 的一项托管功能，可帮助您了解和调查事件，但它非常昂贵。如果您还没有工具来提供帮助，这很有用
- Macie 非常适合在您的环境中查找 PII。PII 就像放射性废物；你想知道它在哪里，这样你就可以避免它。我已经在 Macie 上写了很多。
建立检测目录
好的，我在 S3 中有 30 亿个 JSON 块，现在怎么办？
链接到 CloudTrail Sightings
| Higher Fidelity Events | Common but Significant |
| ---------------------- | --------------------------- |
| CreateTrustAnchor | ConsoleLogin |
| CreateUser | GetFederationToken |
| CreateLoginProfile | StartSession |
| UpdateLoginProfile | GetAuthorizationToken |
| CreateAccessKey | CreateKeyPair |
| AttachUserPolicy | CreateRole |
| DeleteTrail | PutUserPolicy |
| PutEventSelectors | PutGroupPolicy |
| StopLogging | CreateGroup |
| LeaveOrganization | AttachRolePolicy |
| DeleteFlowLogs | PutRolePolicy |
| DeleteVpc | CreatePolicyVersion |
| GetPasswordData | UpdateAssumeRolePolicy |
| GetSecretValue | UpdateFunctionConfiguration |
| ModifyImageAttribute | ListSecrets |
| | ModifySnapshotAttribute |
| | PutBucketPolicy |
| | PutBucketAcl |
其中许多取自 Zack Allen 出色的cloudtrail2sightings 存储库
以下是我喜欢使用和提醒的一些检测。这些缺少很多专有过滤和交叉引用，因此您需要针对您的环境调整它们。
逃避检测
第一个很明显：寻找任何与 CloudTrail 或 GuardDuty 搞混的尝试。
index=cloudtrail
eventName=StopLogging OR DeleteTrail OR PutEventSelectors OR DeleteDetector
| iplocation sourceIPAddress
| table userIdentity.arn, sourceIPAddress,
City, Country
如果有人在做其中之一，那可能很糟糕。如果他们不是从您通常操作的位置进行操作，那就更糟了。
这里需要吗iplocation？不，但它可以帮助提供上下文或让我知道首先要跳过哪个事件。
错误来自哪里？
这是另一个可以带来有趣结果的方法。此查询查看所有错误消息以及它们的来源。您可能希望从 Ashburn 或应用程序处于活动状态的 AWS 区域看到很多。来自明斯克或撒马尔罕的更少。
index=cloudtrail errorMessage=*
| iplocation sourceIPAddress
| stats count by City, Country
| sort -City, Country
这将获得很多点击。开发人员和工程师会在他们的 IAM 策略中犯错误，并且可能不会注意到正在发生的错误。此外，有些人可能无权查看内容，但如果他们有权访问 AWS 控制台，则控制台将为他们进行 API 调用。
但是，如果您查看长尾，您可能会发现有人拥有一些访问凭据并且只是在测试他们所做的事情并遇到错误。
奇怪的凭证使用
查看 sourceIPAddress 长尾的另一个例子是这个：
index=cloudtrail
eventName=GetCallerIdentity OR ListBuckets OR DescribeInstances
| iplocation sourceIPAddress
| table userIdentity.arn, sourceIPAddress,
City, Country
| sort -City, Country
最短的 AWS 命令是aws s3 ls，它转换为ListBucketseventName。下一个最常见的侦察命令是aws sts get-caller-identity（AWS 的 whoami）。有趣的是，STSGetCallerIdentity是少数不需要任何身份验证即可执行的 AWS API 命令之一。您不能通过 IAM 拒绝它。
DescribeInstances是另一个半常见的侦察命令。
在这里，我们将通过 IP 查找他们的位置，并再次查看位置的长尾。
持久性检测
最后一个检测示例。在这里，我们看到了 IAM 用户的创建。一种建立持久性的超级常用方法。
eventName="CreateUser"
| iplocation sourceIPAddress
| search Country!="United States"
| table userIdentity.arn, sourceIPAddress,
City, Country
IAM 用户比较常见。它们仍然是与本地系统或其他云提供商交互的最常见方式。但是，如果您看到它们是从陌生的地方创建的，那就值得研究了。
所有这些都只是查看 GeoLocation 数据。根据您的组织和文化，您也许可以使用 sourceIPAddress 过滤这些查询以获得更好的保真度。
鉴别
您最有可能从以下其中之一收到事件通知：
AWS 信任与安全
您的 AWS 账单/账单提醒
服务影响
您的检测目录
GuardDuty
Twitter
CloudTrail 调查
这是我在查看事件时使用的调查流程的抽象：
如果事件与资源相关，可能是恶意行为，我想知道：谁创建了它？然后我查看创建它的身份，看看该身份还做了什么。
- 他们创造了其他资源吗？
- 他们是否修改了其他身份？
- 它们来自哪些源 IP 地址？然后我查看源 IP 地址。其他哪些身份使用了该 SourceIPAddress？他们有没有做任何看似恶意的事情？
您需要递归所有 Identity 和 sourceIPAddress 的路径，直到您全面了解攻击者所做的事情。
您可以将各种事件名称绑定到各种 MITRE TTP
- s3:ListBuckets 是枚举
- s3:GetObject 是溢出
- cloudtrail:StopLogging 是逃逸
- iam:CreateUser 是持续
DataDog 的Zack Allen已经开始了一个很好的 repo 来做那个映射。
我们可以从对可疑资源的查询开始：
index="aws_cloudtrail" "i-086c8727e55bb6d68"
readOnly=false
| table eventName, eventSource, userIdentity.arn, sourceIPAddress
你会得到类似的结果
{ [-]
awsRegion: us-east-1
eventCategory: Management
eventID: 7b4856eb-8c0c-4e66-969c
eventName: RunInstances
eventSource: ec2.amazonaws.com
eventTime: 2022-08-13T12:30:36Z
eventType: AwsApiCall
eventVersion: 1.08
managementEvent: true
readOnly: false
recipientAccountId: 755629548949
requestParameters: { [-]
blockDeviceMapping: { [+] }
disableApiStop: false
disableApiTermination: false
instanceType: t2.micro
instancesSet: { [-]
items: [ [-]
{ imageId: ami-0a25ed80a0ff1d536
} ] }
monitoring: { [+] }
subnetId: subnet-0dc76374a87f3d69c
}
responseElements: { [+] }
sourceIPAddress: 3.236.91.34
tlsDetails: { [+] }
userAgent:
aws-cli/2.7.20 Python/3.9.11 Linux/5.15.0-1015-aws exe/x86_64.ubuntu.22 prompt/off command/ec2.run-instances
userIdentity: { [-]
accessKeyId: ASIA273YH4WKQTS7ZTUB
accountId: 755629548949
arn: arn:aws:sts::755629548949:assumed-role/Developer/testing
principalId: AROA273YH4WKXW4OHPYYD:testing
sessionContext: { [+]
}
type: AssumedRole
}
}
从实际事件来看，我们知道：
- 实例大小：
t2.micro
- 使用的图像：
ami-0a25ed80a0ff1d536
- 创作者IP：
3.236.91.34
- 它是使用 Linux 机器上的 AWS CLI 创建的（请参阅 userAgent）
- 由经过身份验证为开发人员角色的人
接下来，您想通过以下方式调查该角色：
index="aws_cloudtrail" userIdentity.arn=arn:aws:sts::759429568549:assumed-role/Developer/*
| table eventName, eventSource, sourceIPAddress
寻找横向/纵向运动
横向运动可以是我们通常认为的主机对主机。或者它可以是云帐户到云帐户。此外，还有一些方法可以从地面垂直旋转到云和从云到地面。
对其他 AWS 账户的 AWS AssumeRole 调用可以作为云平面横向移动的指标
正如我在本次演讲顶部所描述的，AuthorizeSecurityGroupIngress 可能是使用云来解决网络控制以促进网络中的横向移动的人。
横向或纵向运动的迹象：
- sts:AssumeRole（云到云）
- ssm:StartSession（云到地）
- ssm:SendCommand（云到地）
- ec2-instance-connect:SendSSHPublicKey（云到地）
- ec2:AuthorizeSecurityGroupIngress（云对地，或地对地）
- VPC 流日志（地对地）
注意：这些操作使用 IAM 操作语法进行缩写
AWS SSM 是一种服务器管理服务。如果您看到有人拨打 SSM 电话，那可能是云到地面的移动。与 EC2 Instance Connect 服务相同，它允许您管理机器上的 SSH 密钥。在这两种情况下，某些云平面身份都在您的实例内的网络级别操纵事物。
横向移动查询：
index=cloudtrail eventName=AssumeRole OR StartSession OR SendCommand OR SendSSHPublicKey | stats count by eventName, userIdentity.arn, sourceIPAddress
遏制与根除
因此，您已经确定了一个事件。怎么办？恐慌？
从这些开始：
- 查看已经发生的 IR 流程。AWS 是否对推送到公共 GitHub 存储库的访问密钥应用了隔离策略？
- 通过使访问密钥或会话令牌无效来锁定攻击者。
- 识别初始访问向量。他们最初是如何获得信誉的？
- 弄清楚攻击者做了什么。
- 寻找横向/纵向运动。网络和云平面之间的移动？他们是在云身份或云帐户之间切换吗？
访问密钥隔离
如果您公开向 GitHub 提交访问密钥（就像我生成下图所做的那样），您将收到这封电子邮件，AWS 将自动将隔离策略应用于用户。此策略不会阻止对用户的所有使用。相反，它只是阻止用户使用大量计算资源来挖掘比特币。大多数事情仍然是允许的。此处的目的是保护 AWS 免受资源使用失控的影响，并且必须为您提供大量信用。
此电子邮件和策略附件都是自动化的。我在 15:14:39 提交了一个密钥，到 15:16:30，AWS 已经锁定了它。所以不到两分钟。
以下是该策略的说明：
它否认最有可能造成财务损失或允许攻击者转移到另一个帐户的特定操作。上面的第一个操作 cloudtrail:LookupEvents 是攻击者可以侦察以查看他或她可以承担的其他帐户中是否有其他角色的一种方式。
禁用访问密钥
隔离策略是不够的。您想尽快禁用密钥！注意：要禁用密钥，不要删除它。您可能不知道在事件开始时禁用密钥对服务的影响。您可能需要重新启用它才能从服务影响中恢复。
这是您的响应者角色应该拥有的权力之一。
撤销活动会话
对于 Lambda、EC2 实例和容器使用的临时凭证，您需要使受损凭证无效。通过 AWS 控制台，您可以说“拒绝在 X 日期时间之前创建的所有会话的所有内容”。合法的应用程序应该恢复并要求新的密钥。但是，攻击者可能能够再次使用相同的漏洞。
应用您自己的拒绝策略
如果您无法确定妥协的最初来源，一种选择是否认一切。他们不能再造成任何伤害，但你可以观察他们正在做什么或试图做什么。您有两个拒绝策略选项，具体取决于应用程序的影响和一般知识。
这个会直接否认一切。如果您不确定并且可以破坏产品，请从这里开始。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": ["*"],
"Resource": ["*"]
}
]
}
这个更细致入微，除了你需要的那一系列东西之外，它会拒绝所有的行为。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"NotAction": ["THINGS YOU NEED"],
"Resource": ["*"]
}
]
}
您可能需要与您的开发人员交谈以获取您需要的东西的列表。
应用 IP 地址条件
对先前的遏制选项的一个转折是将凭据的使用限制为少数已知且受信任的 IP 地址。这可以减少对服务的影响，同时还可以限制攻击者使用凭据的能力。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": ["*"],
"Resource": ["*"],
"Condition": {
"Bool": {"aws:ViaAWSService": "false"},
"NotIpAddress": {
"aws:SourceIp": ["192.0.2.0/24","203.0.113.19/32"]
}
}
}
]
}
识别初始访问向量
作为收容的一部分，你需要做的一件关键事情是首先弄清楚他们是如何进入的。如果它是泄露到 GitHub 的密钥，那很容易。如果攻击者由于应用程序问题而从 EC2 实例或容器中窃取了凭证，那将更难找到。对于 EC2 实例角色，实例 ID 是角色会话名称的一部分，这可能会对您有所帮助。
但是，如果您找不到初始向量，您将在遏制中玩弄鬼，或者您必须对您应用的遏制策略产生更大的影响。这是最佳实践是每个资源或应用程序具有一个角色的原因之一（另一个是维护最小特权）。
是否存在数据泄露
到目前为止，我们所看到的非常有助于了解您的攻击者是否修改了任何内容、创建了加密矿工或机器人等。
但是你怎么知道他们是否得到了你的数据呢？您可能会看到 ListBuckets eventName，但这并不能证明任何数据泄露。
我在谈论 CloudTrail 时提到了数据事件。它们真的很大，所以我不会把它们喂给 SEIM。相反，我将它们保留在 S3 中，因为我只需要它们用于偶尔的成本优化研究或发生事故时。
要在 S3 中查询 CloudTrail 事件，您可以使用 Athena。我将向您指出AWS 文档以进行设置，他们有很好的解释。
在这里，我正在提取帐户中所有 S3 访问的报告。如果我需要通过特定的 IP 地址或身份进行限制，我可以使用 WHERE 子句。
结论
我希望这对您在 AWS 事件中可能遇到的一些事情有所帮助。最后要注意的一件事，就像你的中学数学老师一样，在教授捷径方法之前，我让你完成了所有这些工作。AWS 有一个团队致力于在事件发生时帮助支持客户。它被称为客户事件响应团队，最重要的是，它不需要您拥有他们的顶级 5 位数支持计划。它对任何AWS 客户开放，无论其规模和支持计划如何。
