AmazonVirtualPrivateCloud(AmazonVPC)允许您在定义的虚拟网络中启动AWS资源。这个虚拟网络与您在数据中心运行的传统网络非常相似，将为您提供使用AWS可扩展基础设施的优势。简单地说，VPC是AWS用来将您的网络与其他客户网络隔离开来的虚拟网络服务。在VPC中，用户数据将与其他AWS租户在逻辑上分离，以确保数据安全。VPC可以简单理解为虚拟数据中心。在这个虚拟数据中心里，我们可以创建不同的子网（公网和私网）来搭建我们的web服务器、应用服务器、数据库服务器等服务。VPC具有以下特点：VPC中可以创建多个子网；可以在选定的子网上启动EC2实例；每个子网都可以分配自己规划的IP地址；每个子网都可以配置自己的路由表；可以创建互联网网关并绑定到VPC，以便EC2实例可以访问互联网；VPC对您的AWS资源有更安全的保护；...AWSVPC致力于识别和检测整个企业的攻击者技术；在端点、本地和云端，Hunters团队研究了一种使用VPC功能允许客户控制其IP地址的技术。攻击者可以使用它来控制在访问受感染帐户时将哪些IP地址写入AWSCloudTrail日志。这可能允许攻击者欺骗依赖于Cloudtrail日志的各种安全保护，例如SIEM和云安全工具。这些包括但不限于GuardDuty、Rapid7和Lacework。此外，寻找攻击证据的分析师可能会错过它。这篇文章回顾了混淆技术的技术细节并提供了可操作的建议。攻击者控制CloudTrailSourceIP通过控制其源IP地址，攻击者可以保持隐藏状态，从而有可能绕过仅依赖AWSCloudTrail的安全措施。因此，通过使恶意行为看起来好像是由合法对象执行的，这可以使恶意行为看起来无害，并且难以检测攻击痕迹并将入侵归因于特定来源。如果您的安全工具仅依赖AWSCloudTrail日志中的sourceIP字段，则缓解措施如下。技术分析为了成功执行该技术，攻击者需要从受害者账户获取合法的AWS凭证，然后创建一个VPC端点，允许您的VPC中的EC2实例和AWS服务直接在他们自己的账户内进行通信。沟通。创建一个IP范围的VPC，当他们使用受损凭证时可以混淆他们的流量。以下是我们需要描述的关键功能，以解释如何使用此技术：CloudTrail日志有一个“sourceIPAddress”字段。该字段包含攻击者的IP地址，在大多数情况下是公共IPv4地址。但是，如果攻击者通过VPC的端点在AWSVPC内发出AWSAPI请求，CloudTrail日志中记录的IP地址就是VPC中“内部”EC2的IP地址，即攻击者所获取的IP地址可以控制。用户可以在VPC中设置任意IPv4地址范围，包括rfc1918地址范围和外部可路由的IP地址范围。公共可路由IP块只能通过虚拟专用网关访问，而不是Internet网关。这允许攻击者创建一个IP寻址方案来模仿受害者自己的网络或信誉良好的外部服务。另一个重要的事实是，登录CloudTrail的userAgent字段显示了攻击者的userAgent字符串，该字符串完全由进行API调用的攻击者控制。然而，这不是该技术的直接部分，使用它可以帮助进一步使模拟看起来合法。在私有AWS账户（攻击者账户“A”）中创建了一个带有我们选择的私有IPCIDR块(12.34.56.0/24)的VPC。然后，我们在此VPC中创建了一个EC2实例，并将其私有IPv4地址选择为12.34.56.78。具有“外部”私有IPv4地址的攻击者设备我们在受害者的帐户（“B”）中生成了API凭据，作为攻击者在使用此技术之前泄露的凭据。然后，我们在攻击者的EC2实例上的~/.aws/credentials文件中配置了这些“被盗”的凭证，以便从攻击者控制的账户A中的实例发出的AWSCLI调用将使用它们。接下来，我们在攻击者帐户中为我们打算对其进行API调用的服务创建了一个VPC端点。我们从125个可以创建VPC端点的AWS服务中选择了44个最重要的服务的子集，并为每个服务选择了一个不需要任何特定参数的API调用。为了验证该技术，我们进行了测试。为了进行比较，我们首先从EC2实例对服务进行API调用，而不是通过VPC端点进行隧道传输。这些调用以实例的公共IP地址作为源IP出现在CloudTrail日志中。在下一步中，我们为上述服务创建了VPC端点，并在每个服务中重新运行AWSCLI命令，这次是通过VPC端点。测试成功，在CloudTrail日志中显示了攻击者选择的“内部”IP地址作为源IP。攻击者可以出于许多不同的目的混淆他们的IP地址，这里有一些例子：1.“组织”公共IP地址：如果攻击者收集有关受害组织的公共互联网基础设施的信息，攻击者可以使用对应于该组织某些部分的公共IP公共基础设施。比如公司对外的VPNIP地址。2.员工“家庭”外部IP地址：如果攻击者获得有关员工在离开办公室时使用的外部IP地址的情报，他们可以选择该IP，错误地将任何调查指向“无辜”员工。例如，云IT管理员的家庭IP地址。3.第三方服务提供商的公共IP地址：攻击者可以在AWS客户环境中使用属于第三方服务提供商的已知公共IP地址，增加逃避威胁情报和信誉服务的机会。由于有时这些IP可能会被AWS客户列入白名单，因此攻击者可以执行更多的敏感API调用。示例1：使用属于企业云安全产品的IP地址（最好是受害组织使用的IP地址）。示例2：使用198.20.69.74，流行的互联网扫描仪Shodan从该地址扫描整个互联网。4.特殊的私有、保留、测试或仅文档IPv4子网块：有4-5个子网被定义为临时用途的“保留IP”，使用其中之一也可以帮助规避信誉服务，完整列表可在此处获得.示例：使用来自TEST-NET子网的IP地址（192.0.2.0/24、198.51.100.0/24或203.0.113.0/24）。哪些AWS服务支持VPC端点访问此技术只能用于对可以为其创建VPC端点的AWS服务进行API调用。然而，截至2021年5月，可以为125种不同的AWS服务创建VPC端点，包括大多数知名的AWS服务（如EC2、S3、Lambda、STS、DynamoDB、SecretsManager等），只有重要的例外是我们已经看到它是IAM。此外，AWS还在不断扩展VPC端点支持的服务列表。可在AWS门户中查看受支持服务的完整列表。需要注意的是：1.该技术不会影响攻击者在使用受害者泄露的AWSAPI凭证时实际拥有的IAM权限，他们只能调用被盗凭证具有IAM权限的API。2.使用该技术时，攻击者控制的源IP是AWS管理控制台中记录的源IP，查看CloudTrail服务中的CloudTrail事件历史，以及CloudTrail以JSON文件形式写入S3的事件。3.仅凭记录的IP无法确定攻击者为组织外攻击者，也无法确定其真实来源。但是，可以确定该VPC不属于该组织。这可以用来绕过基于IP的IAM策略吗？我们测试了此技术是否可用于绕过基于IAM源IP的策略（使用aws:SourceIp密钥）。该测试假设，在某些情况下，组织将此类策略配置为仅允许来自特定子网的某些敏感AWS操作。在这种假设下，我们测试了在这种情况下，如果攻击者创建具有相应“内部”IPv4CIDR块的VPC并使用VPC端点，他们是否可以成功调用敏感的AWSAPI，从而“绕过”此类策略。我们发现（有关详细信息，请访问https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceip）当通过VPC端点完成API调用时，aws：SourceIp密钥不可用（相反，aws:VpcSourceIp可用），因此此技术不能用于绕过此类IAM策略。如何在您的环境中检测此类活动：通常，当通过VPC端点进行AWSAPI调用时，可选的vpcEndpointIDCloudTrail字段会被填充（使用VPC端点的ID），与所有其他调用不同，这些调用不填充此字段。这是该技术在日志中的唯一残留用法。鉴于此，我们的第一个建议是查看vpcEndpointID字段。通过查看VPC端点（使用填充的vpcEndpointId字段）和未在VPC中使用的私有IP范围，检测使用不在您的VPC中使用的任何私有IP范围内的IP地址的攻击者相对容易您的VPC在源IP地址内进行的任何AWSAPI调用都已完成。SQL检测查询示例但是，很难检测到攻击者使用的IP地址是您的任何VPC中的有效私有IP地址。这是因为当您在您的环境中使用VPC端点时，攻击者的合法操作和攻击者的操作生成的日志中的唯一区别是记录的特定VPC端点ID。我们建议使用更多基于异常的检测逻辑来解决此用例，检测组织中从未见过的新VPC端点ID的使用最后，我们建议AWSCloudTrail用户将他们的云事件与端点、本地、电子邮件、身份等与其他传感器交叉引用。跨攻击面的全面自动检测是发现被忽视威胁的最有效方法。本文翻译自：https://www.hunters.ai/blog/hunters-research-detecting-obfuscated-attacker-ip-in-aws如有转载请注明出处。
