AWS 渗透测试（三）

原文：annas-archive.org/md5/FFEC848CC6CB35A19A9CEB4325235FE9

译者：飞龙

协议：CC BY-NC-SA 4.0

第三部分：经验教训-报告撰写，保持在范围内，以及持续学习

到了这本书的这一部分，你应该已经熟悉了 AWS 渗透测试的基础知识以及其服务的利用方式。在这里，你将学习报告撰写的重要性以及在渗透测试中的价值。本节还将介绍如何保护 AWS 实例免受漏洞的影响，比如错误配置，同时解释在渗透测试时什么是合法的，什么是非法的。

本节包括以下章节：

• 第十章，渗透测试最佳实践

• 第十一章，避免麻烦

• 第十二章，AWS 的其他项目

第十章：渗透测试最佳实践

渗透测试并不是一种适合所有类型的评估。适用于一种渗透测试的内容可能与另一种不同。了解渗透测试的含义以及保持对趋势和技能集的了解是至关重要的。理解 AWS 渗透测试可能与传统的渗透测试不同同样重要，正如我们在本书中所看到的，并将在本章中进一步了解。我们必须了解 AWS 渗透测试的技术和非技术部分，这正是本章的重点。我们将首先概述渗透测试期间要执行的步骤。然后我们将了解 AWS 渗透测试的未知因素。我们将学习在进行渗透测试之前准备环境，最后，我们将讨论渗透测试后需要执行的一些实际步骤。

在本章中，我们将涵盖以下主题：

• AWS 的渗透测试方法论

• 了解您的渗透测试和 AWS 渗透测试的未知因素

• 渗透测试的预设条件

• 避免沟通中断

• 实现安全而非隐秘

• 渗透测试后

技术要求

本章的指导需要以下内容：

• AWS CLI

• Metasploit

AWS 的渗透测试方法论

这一部分将偏离用于非云渗透测试环境的传统渗透测试方法论。我们不遵循传统的渗透测试方法主要是因为我们的目标范围-在这种情况下，我们的目标将是 AWS 环境。此外，我们将使用客户提供的有效凭据执行功能测试。

重要提示

功能测试是一种扫描和检查漏洞和用户实施的错误配置服务的手段和方法。

整个章节将讨论渗透测试的注意事项和细节，需要在执行渗透测试之前和之后了解。然而，在我们讨论任何内容之前，我们需要了解如何对 AWS 进行渗透测试的步骤。

让我们详细分解在 AWS 目标上执行渗透测试的四个不同步骤：

1. 侦察

2. 利用

3. 利用后

4. 报告

让我们详细看看每一个。

侦察

侦察，也常被称为侦察，是我们使用各种工具收集有关目标的信息的过程。我们在第二章中使用了一些这些工具，渗透测试和道德黑客，并学习了如何收集有关目标的公共信息。

此外，我们使用侦察阶段来收集有关服务和用户的信息。Lambda、S3 和 EC2 等服务是您用来发现和枚举目标环境信息的服务-发现 S3 存储桶的完整 URL 路径，通过 EC2 找到公共 DNS 地址作为内部网络的入口点，以及识别弱 Lambda 函数和策略。所有这些都是 AWS 渗透测试期间侦察阶段的一部分。

一旦我们获得了关于目标环境的所有信息，就是时候进入利用阶段了，我们将开始创建攻击路径，以及武器化和利用我们的易受攻击的服务和目标。

利用

这绝对是 AWS 渗透测试方法论中更有趣的部分之一。我们在利用阶段收集的所有信息，并创建一个我们认为可以在目标环境上运行的攻击路径 - 当然，这是根据我们发现的信息。攻击路径是一个理论上的逐步过程，您可以根据在侦察阶段发现的信息来构建，以突出启动攻击所采取的步骤。让我们看看我们可以根据在 AWS 渗透测试的侦察阶段可能发现的信息创建的一些不同的攻击路径。我们将描述一个攻击路径，该路径从外部和内部威胁攻击服务。

攻击路径

以下是一个说明内部威胁可能会做什么的攻击路径。请记住，内部威胁是指为公司工作并已经具有有效凭据访问环境的人：

1. 发现一个具有弱策略和可能包含敏感信息的S3 存储桶。

2. 修改弱策略以允许内部人员检索机密信息。

3. 内部人员外泄敏感数据并创建一个新的策略，阻止合法用户访问 S3 存储桶。

这是一个潜在的 AWS 攻击路径示例，而不需要任何凭据的知识：

1. 在公共 GitHub 存储库中识别凭据。

2. 使用这些凭据对 AWS 环境进行身份验证。

3. 一个具有公共 DNS 的 EC2 实例托管一个易受攻击的 Web 应用程序，如 WordPress，允许渗透测试人员攻击和访问主机操作系统。

4. 安装后门以实现持久访问。

5. 扫描内部 VPC 网络并发现其他易受攻击的目标。

武器化

这些攻击路径说明了可能造成的潜在危害；然而，攻击路径只是基于在环境中发现的内容的理论。为了进行利用，攻击路径需要对其应用方法以武器化攻击路径。

重要提示

方法是用于执行攻击的工具和策略。

作为渗透测试人员，您将拥有工具来帮助您实现特定攻击路径的结果。诸如Kali Linux、Metasploit和AWS CLI之类的工具非常适合执行我们在本节中阐述的攻击路径。您还可以使用 Bash 或 Python 编写自己的工具，就像我们在第四章中所做的那样，利用 S3 存储桶。一旦您准备好所有工具，并且您的创造性攻击路径准备就绪，就是利用 AWS 服务的时候了。

利用

利用涉及通过逐步进行攻击路径的每个步骤和可能的利用方法来结合我们的攻击路径和方法。当然，由于攻击路径是理论性的而不是实际性的，可能会有时候您无法完全执行整个攻击路径。如果发生这种情况，请确保您记录并报告您能够做的事情，并说明对组织的影响。我们将在本章中更多地了解有关报告的内容，所以现在让我们继续讨论利用。

关于利用的一个重要事项是拒绝服务攻击，通常称为 DoS，如在《第六章》中提到的，设置和渗透测试 AWS Aurora RDS。如果攻击路径中包含 DoS 攻击作为攻击路径的一部分，那么您和渗透测试团队需要与客户讨论 DoS 是否是他们允许在渗透测试期间发生的事情。通常，您将有一个描述是否允许 DoS 的服务级别协议；然而，最好通知或询问是否允许 DoS，因为它是如此具有侵入性，可以关闭系统，使其对用户无用。此外，生产系统不应发生 DoS，因为生产系统与推动客户业务模型直接相关 - 这意味着生产系统通常与帮助生成某种收入相关。如果您怀疑生产系统容易受到 DoS 攻击，请要求生成一个复制目标系统的测试系统，以测试DoS 攻击。这样，您可以测试您的理论，同时不影响目标组织。

一旦您运行了攻击路径并完全执行了所有操作，我们需要看看是否有任何方法可以在被利用的环境中进行枢纽，并检查是否可以访问其他网络。

后期利用

在这个阶段，我们主要关注尝试发现我们可能能够使用来进一步攻击路径的其他资源。在 AWS 渗透测试方面，我们可以利用后期利用阶段来发现可能可利用的其他服务 - 通常，我们会发现其他易受攻击的服务托管在 EC2 实例上，就像我们在《第九章》中所做的那样，使用 Metasploit 和更多进行现实生活渗透测试。

关于后期利用的另一个重要点是检查是否可以看到 VPC 内可能可见的其他网络。在渗透测试世界中，回想一下术语“分割” - 一个涉及不同网络之间不安全通信的术语。例如，我们希望检查并确保媒体网络不能直接与金融网络通信，因为金融网络将托管个人可识别信息（PII）。

能够通过网络进行枢纽或发现其他易受攻击的服务，使我们的 AWS 渗透测试方法能够充分详细地描述客户系统中最糟糕的可能性，通过展示对客户系统中的漏洞进行全面攻击。这种全面攻击突出了漏洞是真实且可利用的 - 这意味着攻击者也可以这样做！

一旦我们完成了在网络中的枢纽，就是时候重新追溯我们的步骤，看看我们可能错过了什么。这意味着回顾 AWS 渗透测试方法的整个过程。完成追溯步骤并回顾任何可能错过的项目后，就是开始撰写报告的时候了！

接下来，让我们开始讨论报告撰写过程。

报告

稍后的章节，“渗透测试后 - 在渗透测试之后”，将更详细地讨论并分解报告过程；然而，讨论如何在 AWS 方面使用报告是很好的。在收集来自您的渗透测试的信息时，您希望确保详细说明功能部分和更传统的渗透测试部分。这意味着哪些部分使用了凭据，哪些部分可以在没有凭据的情况下被利用。以这种方式突出这些问题，使目标业务能够了解攻击者或内部人员如何可能利用您的系统，同时也查看环境中一些功能改进的领域。

现在，让我们扩展这个想法，开始进一步讨论报告以及在 AWS 渗透测试技术部分完成后我们应该做些什么。

了解您的渗透测试和 AWS 渗透测试的未知因素。

不应该有任何石头被忽略-至少谚语是这样说的。关于 AWS 的渗透测试，甚至一般的渗透测试也可以说同样的事情。渗透测试的好坏取决于所有参与渗透测试的人。这意味着目标组织需要确保他们允许所有信息被共享，如果渗透测试团队怀疑需要任何额外的信息，这些信息应该提供给团队。这就是我们所说的知道未知。

了解在渗透测试中要寻找什么的最佳方法是不断进行渗透测试，并始终对新想法持开放态度。虽然这听起来有点陈词滥调，但确实有一定的道理。经验在引导渗透测试取得成功方面起着巨大的作用，而获得经验的唯一方法就是尽可能地进行道德黑客攻击-在不同的环境中，我可以补充。这就是为什么在本书中我们看了很多基于各种服务和应用程序的不同情景。这些练习中的每一个都有助于在您的头脑中建立数据库，您可以利用存储在数据库中的知识来帮助指导您未来的道路。

知道可以期待什么完全取决于过去的经验。例如，如果您想执行功能测试，您应该知道在渗透测试开始之前就应该拥有对 AWS 环境的凭证。您还应该知道应该全面了解正在测试的所有实例和资源。一个初级的云渗透测试人员可能不太清楚，也可能不知道该问什么。然而，在阅读本文并利用您的经验之后，您知道应该询问更多关于渗透测试应该包括什么内容以及应该要求哪些资源的问题-因此知道未知。

让我们讨论一下在进行基于 AWS 的渗透测试或包含在范围内的具有 AWS 资产的渗透测试之前，您需要确保了解的一些要点。

获取 AWS 凭证

收集凭证对于能够有效地对目标进行功能测试至关重要。没有这些凭证，您将无法访问任何资源，也无法检查配置错误，如策略、检测流程和易受攻击的功能。我们在本书的大部分内容中都看到，大多数资源在外部是不可用的，对公众可用的资源应该有某种业务理由，比如运行需要对互联网可访问的 Web 服务器的实例，共享公共资源的文件服务器，或者允许用户共享信息的 S3 公共存储桶。

虽然这些都是很好的理由，但仍然需要进行合理的解释，并制定政策，确保敏感信息不会放在公共资源中，并采取安全措施。

资源所有者

了解您正在测试的资源的所有者非常重要。我们指的不是整体客户，而是拥有 AWS 资源的部门。由于 AWS 易于扩展，而且极易出现实例管理不善的情况，因此与您正在测试的资源的运营和所有者直接沟通非常重要。这将使您能够在渗透测试之前、期间和之后讨论问题。您还将能够将任何渗透测试发现直接提交给该所有者。

应用程序的凭证

当我们对功能进行渗透测试时，拥有该应用程序的凭据是很重要的。没有凭据，我们将无法访问应用程序，也无法准确了解其工作原理，更重要的是，无法了解其在目标环境中的工作方式。了解应用程序在环境中的使用方式可以让您真正了解组织的运作方式以及它们是否在实践安全措施。

例如，Web 应用程序可能已经有了诸如强密码和使用加密的 HTTPS 流量等安全措施，但 Web 应用程序上的用户可能拥有过于宽松的控制权限，使他们能够操纵 Web 服务器，并且可能允许攻击者利用用户帐户进行攻击。如果没有应用程序的凭据，我们将无法正确评估应用程序的这一部分。

揭示私有和公共网络

另一个重要的事情是要知道您将在哪些网络中进行操作和评估。这有助于避免麻烦，也让您知道应该扫描哪些子网，只评估这些子网内的目标。我们还需要知道私有VPC中是否有与之关联的公共DNS名称的目标主机。这让我们知道潜在的易攻击区域和更有可能受到攻击的目标，因为它们对 Web 是开放的。

现在我们知道如何避免渗透测试中的未知部分，现在让我们开始向前迈进，讨论如何在渗透测试开始之前对我们的团队进行预先准备。

渗透测试的预先条件

为您的环境做好准备对于完成成功的渗透测试至关重要。就像了解未知一样，确保您和您的团队一切井然有序，并且每个人都对渗透测试的执行方式心知肚明是至关重要的。在渗透测试之前随时准备一份清单并确保所有问题都得到了解答是很好的。所有问题得到解答可以确保在渗透测试开始之前没有任何事情被忽略或未解答。

让我们讨论一些在开始渗透测试之前与您的团队和环境中应该具备的好事。

团队成员分配

虽然这似乎是显而易见的，但渗透测试团队中的每个人都知道他们在渗透测试中的具体工作职责是很重要的。通常情况下，你会希望有一个渗透测试人员执行部分网络或云部分的渗透测试，而另一个渗透测试人员则进行 Web 应用程序的渗透测试。同样重要的是，每个渗透测试人员都知道什么在范围内，什么不在范围内。特定的 API 可能是禁区，高价值的生产系统通常是禁区，某些云环境可能不符合资格。

无论进行何种渗透测试，每个测试人员都应该了解他们的职责以及应该进行渗透测试的时间。

文档准备

另一个建立起来的好事是为渗透测试人员建立一个集中的方式来存储和分享渗透测试期间的笔记。共享笔记确保渗透测试人员不会重叠，并且在渗透测试不同环境时也可以互相帮助。文档的另一个非常重要的方面是确保渗透测试人员在渗透测试期间拍摄屏幕截图。屏幕截图帮助渗透测试人员在报告中说明他们在渗透测试期间所做的事情。

联系人名单

在渗透测试期间拥有一个联系人名单是非常重要的，因为它让您知道在渗透测试期间应该联系哪些人以解答您可能遇到的问题。您应该有一个详细的名单，列出了各种问题应该联系哪些人，无论是访问云环境、无法访问网络，还是需要创建临时帐户。详细的人员名单将确保您可以迅速解决这些类型的问题。

现在我们了解了在开始渗透测试之前需要发生的事情，让我们讨论一下在进行渗透测试时应该了解的一些事情。其中最大的问题之一就是缺乏沟通，这正是我们接下来要分解的内容。

避免沟通中断

在渗透测试过程中，很容易迷失在细节中，忘记评估的另一边有人依赖你与他们讨论渗透测试过程中发生的事情。我太多次见到渗透测试开始后完全中断了沟通，直到渗透测试结束才有沟通。然而，这不应该是这样的-永远不应该。

在渗透测试过程中，你的客户通常会对你在做什么感到好奇，让他们了解正在发生的事情实际上是有益的。为什么这很重要？有多种方式。让我们看看如何通过保持沟通的自由流动来让每个人都参与其中，并帮助避免可能出现的任何交谈障碍。

每日开始和结束的电子邮件

每次开始和结束渗透测试时发送电子邮件，让客户知道你何时开始，并让他们真正感受到“渗透测试人员正在进行测试，所以如果看到警报弹出，我们不要过度反应”。这也让客户感到他们得到了他们付费的东西-不是说他们没有-这给了他们对于选择你进行渗透测试的决定的信誉感。此外，你可以利用每天开始的电子邮件来提出你可能需要回答的渗透测试当天的任何问题，或者为你遇到的障碍寻求答案。障碍可能是无法访问资源，或者被锁定在范围内的某些东西。

发送结束邮件同样非常重要。发送结束邮件让客户知道你已经完成了，通常也是他们有问题时可以向你提问的时间。此外，发送结束邮件让客户能够与他们自己的团队交流，看看他们是否发现了任何异常情况，并让他们了解他们的员工是否发现了任何问题。最后一点-发送结束邮件为你提供了一点保险。通过发送结束邮件，你通知他们，在渗透测试结束后发现的任何异常网络活动都不是你或你的团队所为。

利用会议

会议可能会变得沉闷和有些多余，因此重要的是不要浪费客户的时间，不要在渗透测试范围之外进行不必要的沟通，或者每天在会议中说同样的事情。此外，过多的长时间会议会浪费宝贵的渗透测试时间。那么，在客户会议中产生影响又不浪费时间的最佳方式是什么呢？通过安排每周第一天和最后一天的短会议。

每周的第一天会议应该用来陈述任何评论、担忧、关注或问题，不应超过 30 分钟。如果会议持续时间超过 30 分钟，通常意味着在渗透测试开始之前就缺少了信息。当然，也有例外情况，比如因为泄露了敏感信息或者你的渗透测试团队意外地导致了某些问题而不得不停止渗透测试。

每周结束时进行快速回顾会议，让你和你的团队提出可能没有在每日开始和结束的电子邮件中得到答案的问题，同时也让客户向你提出他们可能有的任何问题。这也是结束一周的好方法，在周末休息之前进行更加个人化、友好的交谈。记住，作为渗透测试人员，你的工作是友好而不是傲慢，所以确保客户从你和你的团队那里得到一贯友好和欢迎的态度是成功的关键之一。

简短简单地回答问题

在 IT 中最大的问题之一是技术讨论往往对许多参与其中的人来说太过技术化。使用过多的技术术语会使对话变得混乱，并经常让客户感到困惑。这就是为什么重要的是使用简单而简短的讨论来回答技术问题，而不带有技术上的混乱。让我们快速看一个攻击 S3 存储桶的问题如何被回答得太过技术化，然后展示如何以简单的方式回答。

这个答案太过技术化：

在渗透测试期间，我们发现了 S3 存储桶托管 PII 数据，通过绕过允许渗透测试人员直接访问 S3 存储桶的弱策略。渗透测试人员能够通过 S3 存储桶的完整 URL 查询和外泄数据。

正如你所看到的，这个例子使用了一些非常技术化的术语，非 IT 员工可能无法完全理解。如果有人不理解你使用的术语，他们要么会提问，这可能会花费更多时间，从而削弱渗透测试的时间。另一方面，困惑的人可能甚至不会提问，然后离开时感到不确定。这就是为什么使用简单术语很重要。让我们回答同样的问题，但使用更简单的术语。

这个答案更加用户友好：

在渗透测试期间，我们发现了 S3 资源中包含的敏感信息，可以直接与用户和客户相关联。渗透测试人员能够突破 S3 资源的策略，并将数据复制到自己的攻击机器上。

这个例子避免使用非常技术化的术语，而是使用了“资源”这样的术语，而不是“存储桶”。“存储桶”是一个与 AWS 相关的技术术语，许多用户可能不理解；然而，使用“资源”这个词有助于弥合这一差距。我们还用“打破”这个词，而不是“绕过”，因为“打破”是一个与道德黑客相关的相当常见的词，为公众所知。

我们已经看了很多不同的领域，如何准确有效地对 AWS 进行渗透测试。现在，让我们看看在渗透测试期间和之后，当我们阐明渗透测试结果和补救措施时，我们如何不误导客户和自己。

实现安全而不是模糊

本节将讨论我们如何远离模糊，实际上帮助自己、客户和业务，以及如何在对组织进行渗透测试后保持一定程度的实际安全实施。我们必须使用最佳实践，并让客户知道并理解如何改善他们的安全姿态，而不会妨碍这些客户进行日常运营。然而，这并不意味着只是放置一个真正没有作用的安全控制来打补丁。

重要提示

创可贴是一种临时修复方法，不是最好的修复方法。此外，只要对网络或系统有一些基本知识，创可贴就很容易被绕过。

模糊安全

让我们讨论一下“模糊安全”对我们和我们的渗透测试工作的真正含义，特别是在讨论我们如何在 AWS 系统中实施这种“伪安全”时。正如前面提到的，我们需要确保我们使用最佳实践来帮助我们的目标企业实现最高评级的安全姿态。

通过模糊来保护安全是一个术语，它应用了可能保护组织的技术，但往往忽视了可能导致其他问题的其他问题。通常，人们认为这是实施安全性，以便只有内部组织可以访问不安全的资源；然而，正如我们所看到的，内部并不意味着安全。大多数 AWS 渗透测试是功能测试的一部分，用于帮助公司更好地保护其系统。这种类型的测试使用合法的凭据来访问内部系统，并查看内部人员可以在环境中做什么。

现在，让我们看一个相关的练习，让我们看看 S3 存储桶以及我们如何避免通过模糊来保护安全。

避免 S3 存储桶的模糊

让我们讨论如何通过模糊来保护 AWS S3 存储桶。假设我们已经完成了客户的 S3 环境的渗透测试，并发现了一个公共 S3 存储桶，并且也没有实施访问控制。让我们看看我们发现的资源：

1. 首先，我们发现了packtawspentesting存储桶。我们在第四章，利用 S3 存储桶中发现了这个存储桶。让我们从存储桶中提取公共访问块的信息：

$ aws s3api  get-public-access-block --bucket packtawspentesting

您将看到以下输出：

图 10.1 - 公共存储桶策略块

所有公共功能都设置为 false，这意味着这个存储桶是开放的！

重要提示

要找到关于公共存储桶策略的更详细信息，请访问 AWS 资源，阅读来自公共存储桶的输出：docs.aws.amazon.com/cli/latest/reference/s3api/get-public-access-block.html。

1. 现在我们看到我们的存储桶是公开的，让我们继续检查我们目标存储桶的权限：

Allow set for the Effect:![Figure 10.2 – Public bucket policy     ](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/a165ccf5088f4f2d83eb712850fb2c73~tplv-k3u1fbpfcp-zoom-1.image)Figure 10.2 – Public bucket policy We see the `Allow` effect is allowed on the S3 bucket – meaning we can literally do anything we want with the bucket. We can exfiltrate, put, and delete data off the bucket. 

1. 由于我们将要报告这个问题，我们需要找到一个简单的方法来找出谁拥有这个存储桶。在我们的情况下，我们将使用 Metasploit。通过在 Kali 终端中输入msfdb run命令来启动 Metasploit。一旦 Metasploit 启动，我们将使用auxiliary/cloud/aws/enum_s3模块。将访问 ID和密钥设置为账户的 ID 和密钥，然后点击运行。如果您需要复习，请返回第九章，使用 Metasploit 进行真实渗透测试等进行复习：

图 10.3 - 从 Metasploit 检索的存储桶策略

我们可以看到拥有这个存储桶的用户以及它所属的区域。这将使我们能够报告问题并直接将其链接到所有者，以便他们知道并修复这个问题。通过通过渗透测试报告直接向用户报告，我们可以打开一条直接的沟通线路，以防用户在尝试修复问题时遇到任何问题。这是远离安全性的模糊的第一步。

步骤 1涉及确保我们直接与参与的每个人保持沟通，没有人被排除在外。渗透测试是一个大型的参与活动，可以让每个人都有乐趣和学习的经验-但只有在我们涉及渗透测试范围内的人员时才能有学习的经验。传统上，受影响的用户直到渗透测试后才会被他们自己的团队通知。这意味着客户可能只允许他们认为与解决问题相关的内容。

重要提示

重要的是要注意，一些客户可能不希望你直接与他们的员工合作。如果是这种情况，请理解这是客户的要求，不应被忽视。打破客户的范围和理解意味着打破客户的信任，从而打破业务关系。

现在，让我们看看我们如何在完成渗透测试后通过最佳判断和实践帮助保护客户的 S3 资源的步骤 2。为此，我们需要登录 AWS 控制台，并通过 AWS GUI 访问我们的 S3 存储桶存储库。我们将采取这种方法，就好像我们是管理员，因为我们需要知道如何解决问题的确切细节，并向我们的目标受众说明。

让我们从前往我们的 S3 存储桶开始，这些存储桶位于s3.console.aws.amazon.com/s3/home?region=us-west-2#。

一旦您到达 S3 存储桶的位置，让我们继续通过将公共存储桶变为私有存储桶。删除公共访问将确保组织外的任何人都无法访问 S3 存储桶：

1. 首先，单击名为packtawspentesting的存储桶。

2. 接下来，单击权限选项卡。

3. 然后，单击编辑：

图 10.4 - 通过 AWS 控制台编辑存储桶策略

1. 检查阻止所有公共访问：

图 10.5 - 通过 AWS 控制台阻止公共访问

1. 最后，单击保存。

现在，目标存储桶不应该对公众可访问，这意味着只有内部主机可以访问它。

现在我们需要继续进行步骤 3。在这最后一步中，我们将拒绝所有存储桶的访问，然后管理员将需要根据公司政策配置存储桶。因此，我们将坚持要求他们制定一个拒绝所有访问的策略，然后允许管理员根据需要知道的访问创建新规则：

重要提示

需要知道的访问涉及只允许根据其工作职能需要访问的人访问。

1. 让我们通过转到packtawspentesting S3 存储桶开始我们的最后一步。

2. 单击选项卡后，我们需要将Effect:Allow更改为Effect:Deny：

图 10.6 - 通过 AWS 控制台手动更改存储桶策略

1. 完成后，您需要单击保存。之后就完成了。

干得好，我们现在成功保护了我们的存储桶，并建议我们的目标更改其存储桶策略以符合其公司政策。通过确保我们实施了强大的安全层，我们采取了深度安全的方法，而不是模糊安全的方法。

使用简单的术语使您和客户相互关联是增加您的渗透测试方法的价值的许多关键之一。还要记住，关于渗透测试的并非一切都是技术性的！

现在我们知道在渗透测试之前和期间需要发生什么，让我们看看在渗透测试完成后应该发生什么。

渗透测试后

渗透测试的一个重要部分是审查渗透测试期间发生的一切，并且能够以所有人都能理解的水平进行说明。除了确保信息可读之外，还要确保采取了渗透测试后的适当步骤。

让我们继续讨论一些简单而实用的步骤，您可以期望在完成渗透测试后采取。

渗透测试后会议

完成渗透测试后，渗透测试团队将需要收集并讨论渗透测试期间发生的事情。这意味着任何问题、胜利以及可能有价值的信息都需要进行审查和记录。这样做可以让团队从错误中学习，并利用这些错误和学习经验应用于未来的渗透测试。另一方面，讨论哪些方面做得好可以让团队扩展他们更好的技术，并为未来的渗透测试实施更好的解决方案。

这次会议还应该讨论团队在测试期间收集到的内容，并讨论哪些发现可以成为报告中的建议。发现和建议告诉客户需要修复的严重问题，以帮助确保客户的系统姿态。结果将基于一个类似以下的矩阵：

图 10.7 - 渗透测试报告的风险矩阵

正如你所看到的，它讨论了可能性和影响 - 这使我们能够根据对客户的影响以及这个问题被利用的可能性来调整影响。让我们花点时间，通过一个例子来看看这个。

假设渗透测试人员在生产系统上发现了一个易于利用的漏洞。对于生产系统，影响需要被放置在高。这需要被放置在高，因为生产系统是公司依赖的用于产生收入的东西 - 因此，系统崩溃将会导致影响客户并可能造成货币损失。此外，由于漏洞易于利用（考虑使用 Metasploit），这是非常可能的。这将使生产系统上的问题的整体评分被放置在高。

现在让我们继续讨论报告，以及如何将我们刚刚学到的应用到报告中！

报告

报告通常被视为渗透测试中最关键的步骤之一；毕竟，建议将被呈现给客户。在创建报告时，你和整个渗透测试团队一起通过文档，并在发送给客户之前进行多次审查和编辑是至关重要的。进行多次审查将确保语法准确，并呈现出不同的理解方式来展示发现和建议。

报告中的发现应该显示出对公司的风险和严重性。风险是指漏洞可能被利用的可能性，而严重性则警示公司漏洞被利用对组织可能造成的影响。

报告将提供建议如何帮助消除发现的问题的路线图，同时确保这些问题不会再次出现。

例如，如果在渗透测试期间发现了公共 S3 存储桶，渗透测试团队可以提出一个为期 3 个月的路线图，帮助缓解已识别的问题，并防止 AWS 环境中脆弱的公共存储桶再次出现：

图 10.8 - 救济路线图

正如你所看到的，这相当详细地说明了需要以及如何及时消除 S3 存储桶问题。现在，让我们讨论如何跟进我们的客户。

六个月后的跟进

在渗透测试参与后的 6 个月后跟进，可以让你检查客户是否已经纠正了你在第一次渗透测试期间发现的问题。在 6 个月的跟进测试期间，最佳实践是使用黑盒方法，因为它只允许你专注于上次渗透测试期间发现的问题，并查看它是否可能引发了新问题。

如果在 6 个月的跟进期间发现了新问题，那么这些问题需要被记录并报告，就像在初始渗透测试期间一样。如果发现了另一个问题，那么你的团队还需要根据这些发现在 6 个月后进行另一次检查。

重要提示

渗透测试合同中应明确规定，如果在 6 个月的跟进期间发现了新问题，将需要额外的渗透测试服务。

我们已经学到了如何在渗透测试之前、期间和之后对 AWS 进行渗透测试。现在，让我们开始总结并继续前进到下一章。

总结

这一章让我们看到了更多关于如何进行 AWS 渗透测试的常规和非常规方法，同时也让我们深入了解了渗透测试最关键的一点：报告。我们还学到了如何使我们的渗透测试对我们和我们的团队都高效和有效，同时也对我们的客户和他们的组织产生影响的宝贵经验。

在下一章中，我们将开始学习更多关于渗透测试中要避免的事情，以及如何保持在范围内并避免麻烦！

进一步阅读

• 渗透测试的艺术：blog.rapid7.com/2020/02/13/ask-a-pen-tester-q-a-part-2-everything-you-need-to-know-about-the-art-of-penetration-testing/

• 关于安全性通过模糊性的更多讨论：www.techopedia.com/definition/21985/security-through-obscurity-sto

第十一章：避免麻烦

对 AWS 系统进行渗透测试可能会对系统造成严重干扰，如果执行不正确还可能导致法律问题。在对 AWS 进行渗透测试时，了解您作为渗透测试人员可以执行和不能执行的操作至关重要。这些类型的攻击会在渗透测试期间使系统崩溃，破坏您的声誉，同时还可能破坏客户系统，并给渗透测试公司和目标客户带来重大收入损失。

本章将讨论拒绝服务（DoS）和洪水攻击以及它们的工作原理。了解这些攻击的工作原理说明了攻击的严重性，以及为什么我们应该远离它们。

我们将通过讨论压力测试来结束本章，有时也称为负载测试，并对压力测试是什么以及客户是否应该担心有一个高层次的了解。

在本章中，我们将涵盖以下主题：

• 禁止的活动

• 通过 DoS 耗尽服务

• 了解洪水

• 避免法律问题

• 压力测试

禁止的活动

在进行渗透测试时，了解哪些活动是允许的，哪些是不允许的是至关重要的。正如我们在整本书中所述，这就是我们所说的“范围内”和“范围外”。当我们提到范围内的系统时，我们讨论的是我们可以在什么时间测试以及我们对这些范围内主机产生多大影响。然而，了解范围外的内容同样重要。了解范围外的内容可以确保您只测试客户要求的内容，并且可以避免您和您的团队逃避任何类型的法律罚款或惩罚。

接下来的部分将讨论 AWS 在其基础设施和服务方面禁止的活动。请记住，共享安全模型的一部分依赖于 AWS 及其硬件的正常运行 - 因此 AWS 对其产品的测试方式有发言权。

让我们继续讨论在 AWS 上禁止的攻击 - DoS 和洪水。

通过 DoS 耗尽服务

DoS 和分布式拒绝服务（DDoS）是破坏性攻击，目标包括各种系统，如网站和应用程序，有时还可能针对用户。DoS 攻击会产生大量流量，旨在压倒目标并使其无用或使其下线。DDoS 攻击执行相同的攻击，只是它是从多个受损或受控主机 - 称为僵尸网络 - 进行攻击。

重要说明

大量受控或受损的主机通常被称为僵尸网络。AWS 有一篇关于僵尸网络的较旧但有趣的文章，位于这里：aws.amazon.com/security/security-bulletins/zeus-botnet-controller/。

DoS 和 DDoS 攻击将攻击开放系统互联（OSI）模型的多个图层；然而，我们经常看到的攻击更多发生在图层 3、图层 4、图层 6 和图层 7。以下截图来自 AWS 的网站，显示了各种图层：

图 11.1 - AWS 的图层

图层 3、4、6 和 7 说明了破坏性攻击最突出的图层，并可以分为两个不同的图层。将这些图层分组可以简化缓解过程，因为它允许我们将缓解技术应用于一个组中的多个图层。我们将图层分为以下组：

• 基础架构层（图层 3 和 4）

• 应用层（图层 6 和 7）

在考虑我们的分组时，让我们讨论它们以及它们在 AWS 方面的目标服务。

基础架构层攻击

基础架构层攻击侧重于攻击网络层（3）和传输层（4）。在 AWS 中，我们看到的一些更常见的攻击涉及 SYN 洪水和 UDP 洪水——我们将在本章的了解洪水部分进一步讨论——旨在使该层的服务崩溃。这包括通过 TCP、UDP 和 IP 建立的任何连接的中断，例如在 AWS 环境中与其他节点建立连接。

现在，让我们讨论下一层，即应用层，并考虑它对 AWS 的影响。

应用层攻击

应用层发生的攻击通常较少见；然而，它们也存在自己的问题。虽然这些类型的 DoS 攻击可以产生大量流量值以使服务崩溃，但它们也可能是简单的改变文件、策略或其他类型的数据的完整性，从而允许访问和授权资源。我们在本书中已经看到了一些攻击情况和方法，这些情况说明通过改变 S3 策略或更改 EC2 实例上的 SSH 密钥来拒绝服务。

应用层攻击主要针对 AWS 的 SSH 和 HTTP。这意味着如果 API 和 EC2 实例的访问没有得到正确的保护，它们可能会受到攻击。我们将在本章的减轻洪水攻击和 DoS部分进一步讨论保护和减轻措施。

现在我们了解了各层，让我们继续讨论洪水以及在渗透测试期间的含义。

了解洪水

洪水是一种简单但有效的策略，恶意和好奇的用户通过向目标主机发送大量数据包来希望淹没主机。洪水的另一个部分使其简单是它使用网络中的最短路径到达目标，或者在我们的情况下，到达我们的VPC和云环境。这意味着当洪水攻击发生时，它可能会影响除目标之外的其他主机，因为洪水会喷射到其他节点以找到最短路径。

此外，洪水是 DoS 攻击中常见的技术。DoS 攻击的任务是压倒和淹没网络、系统或环境，使可用性受到干扰，服务被关闭。

现在，让我们提到一些洪水技术，以及一些 DoS 攻击的风格。

UDP 洪水

端口洪水涉及攻击系统的端口并用用户数据协议（UDP）数据包溢出它们。由于 UDP 数据包是无连接的，它们可以以不需要目标主机建立任何已建立连接的洪水发送。当目标收到大量 UDP 数据包时，它可能会变得不堪重负并下线。如果目标主机下线，将向我们发送一条表明目的地不可达的消息。

讨论 SYN 洪水和 TCP 握手

SYN 洪水，或 TCP SYN 洪水，是一种利用三向 TCP 握手的 DoS 攻击，通过发送大量 SYN 请求而不接受目标发送的 ACK 请求来进行攻击。基本上，这样做会让目标等待来自攻击者的响应，同时处理来自攻击者机器的大量 SYN 请求。

为了更好地理解 SYN 洪水，我们需要了解 TCP 握手及其工作原理。以下步骤突出了 TCP 握手在两个节点之间启动的三个步骤——在我们的情况下，这可能是目标和攻击者之间的连接：

1. 攻击者机器向目标发送一个 SYN 消息以请求与目标建立连接。

2. 目标向攻击者机器发送一个 SYN-ACK 请求并确认该请求。

3. 攻击者机器响应 ACK 消息，并启动连接。

以下图表说明了我们刚才提到的步骤，并帮助直观地理解 TCP 三次握手：

图 11.2 - TCP 三次握手

现在我们了解了握手的工作原理，让我们讨论一下如何利用这个握手来攻击我们的目标。以下步骤将突出显示 SYN 洪水是如何执行的：

1. 攻击发起 SYN 洪水。攻击者发送多个 SYN 请求，这些请求发送到目标服务器。

2. 目标接收并响应来自攻击机器的过载请求，而没有收到 ACK 响应。在试图从攻击者机器接收 ACK 时，目标仍将受到来自攻击者机器的 SYN 请求的过载。

3. 服务中断，使目标无法处理合法请求。

下图说明了我们在洪水方法论中提到的三个步骤：

图 11.3 - 滥用三次握手的 DoS

正如我们所看到的，如果不正确减轻洪水攻击，洪水攻击可能会带来危险。服务中断意味着收入损失、声誉损失和员工信任的潜在损失。我们将在稍后更详细地探讨这些原因；然而，请记住，尽管洪水是一种危险的攻击，但在 AWS 中有一个很好的解决方案。

现在我们从高层次理解了 DoS、DDoS 和洪水攻击，让我们提到如何防止这些攻击发生。这是我们向客户推荐的如何保护其系统免受破坏性攻击的建议。

减轻洪水攻击和 DoS

对洪水的最基本理解以及如何减轻其影响是，大多数操作系统（如 Windows）会限制 ICMP 响应并过滤掉请求的过载。您也可以使用更传统的方法，使用防火墙解决方案来帮助减轻这些攻击。AWS 提供了一项名为AWS 防火墙的服务，它充当Web 应用程序防火墙（WAF），可用于过滤您的 AWS 环境和 API 的流量，并防止针对您的 Web 应用程序的常见利用。

还有另一项名为AWS Shield的服务，它有助于防止针对在 AWS 中运行的任何应用程序的 DoS 和 DDoS 攻击。这两层服务提供了实时检测和减轻，以防止发送到应用程序的过载流量实际上造成任何损害 - 这很棒，因为 AWS Shield 基本上承担了所有繁重的工作，而不需要您额外的 AWS 支持。

那么，AWS Shield 究竟是如何工作的，为什么应该推荐它来防止任何类型的 DoS 攻击呢？

简而言之，AWS Shield 创建并提供基于启发式的实时监控和内联减轻。这意味着 AWS Shield 使用先进的监控技术，在环境中创建基于通常流量的基线，并将报告任何偏离该流量的情况。此外，它还将对常见和更频繁的攻击进行实时减轻，例如 DoS 和洪水攻击。它还将提供更具体的检测和高级的减轻技术，有助于阻碍更高级的攻击方式，例如 DDoS 攻击。

您可以在这里了解更多关于 AWS Shield 以及它如何帮助您制定减轻策略：aws.amazon.com/shield/。

另一种减轻任何破坏性攻击的方法是减少 AWS 环境的攻击面。这意味着确保 EC2 实例不公开可用，除非基于业务原因需要。应用程序对互联网的暴露越少，它们被发现和攻击的可能性就越小。我们还可以通过放置负载均衡器在环境中来帮助承担环境将承受的负载。以下图表显示了负载均衡器如何在四个不同节点之间分配负载，并根据它们在那个时候能够处理的流量类型来分配负载：

图 11.4 - AWS 内的负载均衡

如您所见，负载均衡器不是每个节点独立处理流量，而是根据每个节点能够处理的流量量来分发流量。

最后要提到的一点，但也非常重要的是，您必须有受过培训的 AWS 工程师，能够在环境中安全有效地实施安全控制。您的工程师实施这些控制的最佳方式是了解并知道环境中的正常流量和异常流量。这就是为什么文化在安全中如此重要，不仅在 AWS 中，也在企业本身。

虽然文化是一个巨大的影响，但同样重要的是要知道内部人员可能会对组织产生影响，以及他们的恶意黑客心态如何在组织内部引发问题。接下来的部分将讨论黑客心态与 DoS 和 DDoS 攻击的关系。

DoS 和 DDoS 的攻击者心态

攻击者执行破坏性攻击的原因有很多。在这种情况下，威胁行为将是 DoS 或 DDoS 攻击，旨在直接制造破坏公司声誉的麻烦，或者很多时候用于制造政治状态，如果政治关联方拥有 AWS 系统。

我们在第三章中提到，探索渗透测试和 AWS，一些不同类型的攻击者，如内部人员和外部人员。这些相同的攻击者心态可以应用于执行 DoS 和洪水攻击的原因。

现在我们更多地了解了我们需要远离的攻击，让我们结束本章，并讨论一些您可能会面临的法律问题，如果超出了渗透测试的范围。

避免法律问题

正如我们在本书中所看到的，渗透测试可能会非常侵入性，有时甚至可能非常危险，如果您的团队不完全了解渗透测试的范围，可能会导致罚款，甚至可能会被认为违反《计算机欺诈和滥用法》（CFAA）而采取行动。根据渗透测试团队测试的对象和内容，您还可能违反其他法律，如联邦和州法律；然而，这将取决于每次渗透测试。

说了这些，让我们快速看一下如何在法律和客户方面避免麻烦。

免于监狱的牌

这是确保在渗透测试期间避免任何法律冲突的最重要的基本因素之一。免于监狱的牌本质上是一张纸，说明渗透测试团队被授权对目标组织进行渗透测试 - 但是，它还应该注明渗透测试团队被允许进行渗透测试的“什么”，“在哪里”，和“何时”。这非常重要，因为由于高价值流量时间，渗透测试人员可能无法在某些时间进行渗透测试；他们也可能未经授权进行网络或托管在 AWS 环境中的 Web 应用程序的某些渗透测试区域。

在目标组织向渗透测试团队提供免责卡之前，需要明确了解范围。如果需要添加或删除渗透测试范围内的内容，那么应该进行更正，并列在免责卡上。

潜在损害

这是我们许多人不喜欢讨论的话题，或者至少在讨论时感到非常不安：系统可能在渗透测试期间被损坏或关闭的可能性。当要求对生产或实时系统进行渗透测试时，如果系统崩溃将导致巨大的收入损失，这尤其具有挑战性。渗透测试团队和客户组织必须制定一项紧急响应计划，以防不幸发生故障。此外，应该有一种解决方案，可以启动一个模仿生产环境的测试系统。

在对 AWS 进行渗透测试时，我们可以建议我们的客户创建一个模仿生产环境的单独的私人 VPC，并且只允许渗透测试团队访问。这样做可以让渗透测试团队实时测试系统，而不会对实时系统造成任何伤害。

了解数据分类

我们想知道在渗透测试期间存储在环境中的数据类型。如果有信用卡数据、社会安全号码和其他敏感数据，那么需要有一份说明，说明在渗透测试期间可能会看到数据。当然，如果发现明文存储的敏感数据应该加密，渗透测试团队需要立即通知他们的客户。

在本章中，我们已经学到了很多关于有影响力的攻击，也了解了一些法律问题。现在，让我们讨论另一个问题，我们需要了解并注意 - 压力测试。

压力测试

围绕着亚马逊客户计划使用某种类型的高容量测试来测试其系统、网络和产品的可靠性和耐久性建立了政策。在这种情况下，客户通常希望确保托管在 EC2 实例上的 Web 服务器能够承受大量的流量。压力测试，有时也称为负载测试或游戏测试，还可以确保如果流量对 Web 服务器造成了太大的压力，流量将被负载均衡器重定向。有关负载均衡的高级视图，请参阅图 11.4。

为什么要进行压力测试？

如前所述，我们进行压力测试是为了确保目标环境能够承受在系统生产期间可能预期的大量流量。

重要说明

生产服务器通常可以在网络上访问，并确保来自合法和非法来源的大量流量。

负载测试，或者压力测试，本质上是一种保证政策，让您放心了解您的 AWS 环境的可用性 - 确保您的网站或应用程序不会崩溃！如果某些东西，特别是在生产中，出现故障，可能会导致收入损失，公司与客户之间的信任丧失，或者员工与公司之间的信任关系丧失。

现在我们了解了压力测试的影响 - 在某种意义上，我们也了解了如果不进行压力测试会有什么影响 - 让我们讨论如何在 AWS 环境中进行压力测试。

授权压力测试

要获得在 AWS 环境中执行压力测试的授权，您需要向 AWS 提交一个接收表格。虽然大多数客户网络不在指导方针范围内，但检查是必不可少的 - 毕竟，不进行环境压力测试可能会导致更大的问题！

虽然 AWS 在提供资源方面做得很好，以防止与高流量相关的任何问题，但客户可以向 AWS 员工发送电子邮件，以确定他们的网络是否应该接受负载测试，以及应该对测试施加多少负载。

如果有疑虑，客户应该将查询发送至aws-security-simulated-event@amazon.com。一旦确认收到电子邮件，客户对其网络的担忧将需要在一个接收表格上填写，并且他们必须授权 AWS 评估他们的环境，以分析是否需要进行压力测试。

压力测试的同意将基于风险和相关系统的影响。建议客户说明潜在的高流量可能对实时系统产生的影响。如果授权进行压力测试，建议备用站点准备就绪，以防生产系统未能通过负载测试。生产系统未能通过负载测试将导致系统下线，客户无法访问。

另一个保持一致备份的好方法是在内部网络上拥有生产系统的开发模型或测试模型。这个复制的实时系统可以用来测试新功能，并且可以在外部和内部渗透测试期间作为目标，而不是针对生产站点。如果生产站点的测试系统不可用，强烈建议拥有一个！

现在我们更了解压力测试以及如何使用它来评估我们自己的系统，让我们开始总结本章并继续前进到下一章。

总结

在本章中，我们讨论了在渗透测试期间要注意的事项，并了解了 DoS、DDoS 和洪水攻击的更多细节。正如我们所了解的，这些攻击可能会产生极大影响，并违反 AWS 政策。我们还了解了如何避免法律问题以及如何减轻渗透测试期间可能出现的任何潜在法律问题。我们通过讨论压力测试以及 AWS 客户可以做些什么来了解他们的环境是否应该接受负载平衡测试来结束了本章。

在下一章，也是最后一章中，我们将探讨一些其他项目，可以帮助加强我们的 AWS 方法论。

进一步阅读

• AWS 渗透测试：aws.amazon.com/security/penetration-testing/

• 什么是 DDoS 和 DoS？aws.amazon.com/shield/ddos-attack-protection/

• 压力测试：aws.amazon.com/ec2/testing/

第十二章：AWS 的其他项目

为了结束这本书，我想简要提及另外两个不同的项目，这些项目值得注意并深入研究。在整本书中，我们已经从高层次和低层次（实际操作部分）来创建了对渗透测试的一致理解以及它对 AWS 的意义。本章将讨论一个开源框架，该框架由红队人员、渗透测试人员和道德黑客使用，使企业能够测试其组织上的真实对手战术和方法，以最终通过发现弱点来改进控制和防御。最后，我们将以一个有趣的练习结束，这个练习源自我在 2019 年提出的一个钓鱼项目，我们将学习如何利用 EC2 快速设置并产生影响的钓鱼练习，您可以在经授权的组织中使用。

在本章中，我们将涵盖以下主题：

• 理解 MITRE ATT&CK 框架

• 使用 AWS 进行钓鱼

技术要求

本章的技术要求如下：

• MITRE ATT&CK Navigator：mitre-attack.github.io/attack-navigator/enterprise/

• Kali Linux

• 本章使用的钓鱼程序：github.com/thelinuxchoice/blackeye

理解 MITRE ATT&CK 框架

根据范围的不同，渗透测试可能会变成一个庞大而繁琐的工作，可能会严重影响渗透测试的质量。在渗透测试时，我们希望能够提供创造性和现实的场景，以便与我们的客户和客户网络和系统进行互动。在渗透测试期间，我们称我们的行动和方法为TTPs - 其含义如下：

• 战术

• 技术

• 程序

这三个词构成了我们进行渗透测试的很大一部分；然而，如果我们不真正理解它们的含义，那么我们就无法利用它们。为了更好地理解它们，我们可以将它们应用到一个名为 MITRE ATT&CK 框架的开放知识库中，并通过将它们应用到现实场景中来讨论这些术语。

MITRE ATT&CK 框架使我们能够开发自己的方法和行动，以 TTPs 的形式实现对客户的质量承诺。该框架是一个庞大的知识库，充满了真实的对手战术，我们可以利用它来创建威胁模型和现实的渗透测试路线图。

MITRE ATT&CK 框架的另一个重要好处是，它让您模仿现实威胁场景，我们将在发现 MITRE ATT&CK Navigator部分中更详细地了解。在我们开始使用 MITRE 创建攻击路径之前，我们需要了解如何将其用于 AWS 渗透测试。接下来的部分将讨论 AWS 矩阵，该矩阵通过 MITRE ATT&CK 框架展示了战术和技术。

了解 AWS 矩阵中的 TTPs

MITRE ATT&CK 框架中的 AWS 矩阵使我们能够通过查看真实技术并将其应用于我们的渗透测试方法来推动我们的限制和攻击路径。由于渗透测试的方式有很多种，而且有很多不同的场景，AWS 矩阵使我们能够通过提供源自真实攻击的真实场景来少思考多行动。

要查看矩阵，请访问attack.mitre.org/matrices/enterprise/cloud/aws/。

让我们来看看矩阵及其在设置攻击方面的真正含义。以下截图显示了 AWS 矩阵的菜单：

图 12.1 - MITRE ATT&CK

这看起来像是一个非常复杂的 Excel 表格，但实际上并没有看起来那么复杂。它真正做的是分解我们在渗透测试过程中使用的攻击步骤 - 唯一的区别是这是使用真实世界的方法，而不是理论方法，所以让我们分解一下这些主题，以便我们可以简明地理解在对 AWS 进行渗透测试时它们的含义：

• 初始访问详细说明了我们可以获得允许访问面向用户的服务（如 S3、EC2、Lambda 等）的凭据的各种方式。这些凭据可以通过攻击路径以不同方式访问；然而，更常见的方式是通过暴露的 GitHub 和 GitLab。如果你访问以下链接，它显示了一个真正的高级持续威胁（APT）是如何通过使用受损的 Office 365 帐户收集凭据的：attack.mitre.org/techniques/T1078/004/。

以下是描述的屏幕截图：

图 12.2 - APT33

请注意，它引用了一个真实的威胁行为者。这意味着我们可以使用这个属性来创建一个攻击客户的“真实”路径，以验证他们是否容易受到这种类型的攻击。

• 持久性包括维持对系统的访问。我们在第九章中做过这个，使用 Metasploit 和更多进行现实生活的渗透测试，当处理不同的 Metasploit 场景时。通常，我们可以创建帐户或使用我们拥有的有效帐户来保持持久性。提升权限的方式与此类似，涉及发现具有更高权限的有效 AWS 帐户，或者在受损帐户上执行垂直权限提升。

• 防御规避有各种技术可以执行，以帮助绕过防御，如 AWS 环境中的防火墙和其他检测服务。如果我们看一下云计算基础设施技术之一，我们会看到一个创建云实例的子技术。这是一个有趣的概念，因为在渗透测试期间，我们创建一个成为环境一部分并且可以在渗透测试期间用作流氓服务器的新实例。

• 关于这个过程的另一个重要部分是发现阶段。在这个阶段，对手 - 在这种情况下是渗透测试团队 - 使用各种技术来通过侦察和枚举收集有关目标网络的信息。我们通过使用各种工具发现 EC2、S3、Lambda 和开放信息来进行了相当多的侦察和发现。

• 接下来，一旦我们发现了目标，我们就朝着收集和外泄网络外的数据的方向前进。这意味着我们可以使用技术和程序将信息从网络中拉出并传输到我们的网络中。在对手的方法中，有访问 AWS 环境的威胁或恶意黑客会收集数据并将其推送到位于代理服务器后面的他们的服务器。

重要说明

代理服务器充当目标和攻击者服务器之间的中间主机。代理服务器用于“隐藏”攻击者服务器。

• 另一个值得一提的部分是 MITRE ATT&CK 框架的最后一部分涉及威胁的影响。影响可以是破坏网站或网页服务器，通过DDoS或DoS使服务中断。这些类型的攻击很常见，如果在渗透测试期间发生了什么，或者更糟糕的是，如果实际威胁或 APT 造成了大规模影响，这可能会对组织造成真正的伤害！

重要说明

要更多地了解 MITRE ATT&CK 框架，请查看完整的框架：attack.mitre.org/。

现在我们已经讨论了 MITRE ATT&CK 框架，让我们开始看看 MITRE ATT&CK Navigator - 一个让我们在高层次上映射和说明攻击的工具。

发现 MITRE ATT&CK Navigator

在本节中，我们将快速看一下如何在高层次上使用该工具，以及运营商（红队员）和渗透测试人员如何使用这种插图类型的工具来揭示特定攻击。在这个例子中，我们将看一下 APT33 使用的一些攻击，APT33 是一个被怀疑的伊朗威胁组织，自 2013 年以来一直进行着行动。APT33 的目标包括美国、沙特阿拉伯和韩国等国家，他们对航空领域感兴趣。您可以在这里找到有关 APT33 的更多信息：attack.mitre.org/groups/G0064/。

让我们从这里开始导航器：mitre-attack.github.io/attack-navigator/enterprise/。

在导航器上，按照以下步骤创建 APT33 路线图：

1. 在部分工具部分点击多选，并在威胁组部分向下滚动，直到找到APT33。找到后，点击选择：

图 12.3 - MITRE 导航器中的下拉菜单

1. 现在我们已经选择了APT33，我们已经选择了它的所有技术。现在，让我们通过点击技术控件下的油漆桶来突出显示这些技术。在这个例子中，我们选择了红色作为颜色：

图 12.4 - 使用颜色突出显示攻击方法

1. 选择颜色后，您的屏幕应该开始填充您选择的颜色。这些颜色突出显示了APT33使用的策略和技术，以及您的渗透测试团队如何执行这些攻击。这也是向高层管理人员展示攻击者如何针对其他 AWS 环境的方式，并允许就如何防范这类攻击进行公开讨论。以下是来自 ATT&CK Navigator 的APT33的攻击路线图的插图：

图 12.5 - 完整的突出显示的攻击路径

这就是本章的导航器部分。正如你所看到的，导航器是一个很棒的、简单而简洁的工具，它将帮助我们向高层管理人员和我们的渗透测试团队说明我们的攻击路径，并允许我们在保持在轨道上的同时执行我们的渗透测试。

现在我们了解了如何将 MITRE ATT&CK 与我们的渗透测试结合使用，让我们来看看攻击者和渗透测试人员如何通过钓鱼手段和方法获得初始访问权限。

通过钓鱼上钩

钓鱼是一种网络攻击，占受害组织遭受的入侵的约 70%。这种不太技术性的欺骗技术通常涉及攻击者制作某种类型的有效负载，然后将其发送给一个或多个受害者。有效负载包括一封带有某种恶意软件或链接的电子邮件，诱使用户点击它们。这是通过欺骗和借口的艺术来使用的，通常有一种诱饵用于诱使目标。

现在，让我们继续看看如何在教育环境中应用钓鱼。这样做的目的是帮助您，读者，了解一个简单而有效的钓鱼网站可以如何执行基本的技术属性。

使用 AWS 执行钓鱼

现在我们了解了什么是网络钓鱼，让我们来看一个快速但非常有趣的例子，使用我们的 AWS Kali Linux 机器来执行网络钓鱼攻击的练习。在开始之前，您需要确保您的 Kali Linux 机器已经启动并运行。一旦您的 Kali Linux 机器运行起来，通过其公共 IP 地址 SSH 连接到它。一旦您登录到 Kali 机器，按照以下步骤进行：

1. 从 GitHub 获取 BlackEye 的副本：

$ git clone https://github.com/thelinuxchoice/blackeye

1. 接下来，切换到该工具的目录：

$ cd blackeye

1. 启动应用程序：

$ bash blackeye

1. 启动应用程序后，您将被提示选择要克隆用于网络钓鱼攻击的网站。在这种情况下，我们将选择Linkedin，选择选项13：

图 12.6 – BlackEye 主屏幕

1. 在选择选项13后，确保将公共 DNS作为本地 IP。这将确保该工具绑定到我们的本地 DNS 名称以进行路由。

现在站点已经运行并等待目标访问，或者它在网络钓鱼邮件中，让用户点击链接。

要查看页面，请将公共 DNS 输入到您首选浏览器的 URL 栏中：

图 12.7 – 钓鱼 LinkedIn 网站

正如我们所看到的，该网站看起来很正常；然而，我们可以看到在顶部附近的搜索栏中的 URL 不同。对于一个警觉的用户来说，这将是一个明显的指示，表明这是一个网络钓鱼计划；然而，一个不太警觉的用户可能会被欺骗并输入他们的信息。

尝试向应用程序输入一些凭据。请勿使用您的合法 LinkedIn 凭据！

一旦您输入您的凭据，点击登录，就像您通常会做的那样。您应该会被重定向到真正的 LinkedIn 页面。发生的事情是 BlackEye 工具收集了您的凭据，并将您重定向到实际的 LinkedIn 页面再次尝试登录。普通用户可能会将此视为潜在错误，然后再次尝试登录。然而，如果我们查看后台并返回到我们的 Kali 终端，我们会注意到另一件事——我们的凭据已经被收集并保存了！

图 12.8 – 被盗的凭据

正如我们所看到的，我们有可以用来访问 LinkedIn 的凭据。当然，这些并不是合法的；然而，在现实生活中的网络钓鱼计划中，收集到的凭据可能会导致很多麻烦，比如欺诈、身份盗用和数据泄露。

重要提示

关于这个主题的有趣互动视频，请查看Simply Cyber，以了解使用这个工具的精彩现场演示！

www.youtube.com/watch?time_continue=2&v=aa7e7oLPyp4&feature=emb_logo

总结

在本章中，我们通过分析和讨论 MITRE ATT&CK 框架，学习了一些攻击技术，然后通过一个有趣的互动练习结束了本章，该练习利用 AWS 进行 AWS 网络钓鱼活动。

这一章结束了。我希望您和我一样喜欢阅读它！

进一步阅读

关于 AWS 上真实攻击的文章：www.darkreading.com/cloud/hackers-use-public-cloud-features-to-breach-persist-in-business-networks/d/d-id/1332618