如何搭建无服务器的红队基础设施（Part 1）

一、前言

在红队行动期间，如果能够快速且程序化地部署基础设施通常能带来不少好处。现有大多数参考资料主要关注的是使用terraform来部署适用于红队的、面向服务器的基础设施，目前这方面研究已经有较为成熟的解决方案，大家可以深入阅读如下资料了解更多细节：

• Red Baron，@byt3bl33d3r
• 使用Terraform自动化部署红队基础设施（Part 1），@_RastaMouse
• 使用Terraform自动化部署红队基础设施（Part 2），@_RastaMouse

在本文中我们介绍了另一种可选方案，采用ASW Lambda无服务器计算（serverless computing）来实现红队基础设施的部署。

 

二、概述

最早我通过@_xpn才了解到serverless这种技术，当时他将这种技术与pushover集成起来，监控用户访问他搭建的钓鱼网站的具体时间。观摩这种方法的实际效果后，我意识到这种思路非常强大，可以用于多种应用场景。

Amazon已经给出了serverless computing这个概念的定义：

Serverless computing可以让您构建并运行应用及服务，无需考虑服务器方面的事务。Serverless应用不需要您动手去配置、扩展和管理任何服务器。您可以使用Serverless computing来构建几乎所有类型的应用或者后端服务，我们会帮您准备好应用程序在运行及高扩展性方面所需的一切。

作为红队人员，这种技术特别适合某些红队基础设施组件，因为我们不再需要花精力去提供、构建或者配置服务器。实际上serverless意味着我们可以在需要的时候，花几分钟时间程序化地创建新的服务，如果某次行动暴露，只需要简单清理并重新创建新的、无法被追踪溯源的基础架构即可。

AWS Lambda还有两个突出优点：

首先，当我们部署应用时，会自动获取源自Amazon Root CA的SSL证书：

其次，许多代理服务会将默认的amazonaws.com域名（虽然这里可以使用自定义的域名）划分到技术/互联网类别：

然而在操作过程中，我们对于客户端数据的存储方式非常关心（不论是静态还是传输中的动态）。我们要遵守一个重要原则：即便我们广泛使用了云服务（主要作为重定向器来使用），C2系统一定要交给自己的内部服务器来托管，避免在云端存储任何敏感数据。@malcomvetter之前在一篇<a href=”https://medium.com/@malcomvetter/responsible-red-teams-1c6209fd43cc”>文章中已经讨论过这个原则。大家可以在我们描述的某些工具实现原理中找到这个策略的身影。

 

三、无服务器网络爬虫

在行动的侦察阶段中，我们需要花大部分时间来了解客户的具体环境，其中就包括使用网络爬虫（web bugs）来跟踪用户接收并点击电子邮件的具体时间，也包括枚举客户端的软件信息。

AWS Lambda提供了实现该功能的完美平台，我们依托该平台实现了多个Lambda函数来执行跟踪任务，可以枚举客户端信息、将结果存储在Amazon关系型数据库服务中。我们开发的工具为lambda-webbugs，大家可以在MDSec ActiveBreach GitHub页面中下载源码。

使用serverless时，我们需要使用一个YAML配置文件（serverless.yml）来定义具体服务；lambda-webbugs对外公开的函数接口定义位于functions区中，总共有3个函数：ping、enum以及info，每个函数都使用handler关键字映射到一个python方法上，比如，ping函数会映射到handler.py文件中的ping(event, context)方法上：

functions:
ping:
handler: handler.ping
events:
- http:
path: collect/ping
method: get

函数公开的HTTP路径定义位于path键中，在如上示例中，该函数可以通过webbug/collect/ping这个URL来访问，其中webbug路径定义位于stage键中。

应用提供的3个函数如下所示：

1、/webbug/collect/ping：记录已访问过URL的用户。该函数接受token以及step查询参数。token为跟踪用户的唯一ID标识符，而step用来区分攻击过程的具体阶段。比如，step=1可以表示用户正在打开电子邮件，step=2可以表示用户正打开钓鱼页面，step=3可以表示用户正打开附件，攻击者可以根据需要设置具体场景。这些回调处理结果会存储在RDS数据库的webbug表中，其中包括用户的IP及User-Agent信息；

2、/webbug/collect/enum：渲染一个表面上看起来空白的HTML表单，可以执行JavaScript枚举脚本，将结果提交到info函数。该函数接受token查询参数；

3、/webbug/collect/info：接收枚举函数返回的结果，将结果保存到RDS数据库中。该函数接受token、sw以及intip查询参数。

为了便于演示，我们直接使用了PluginDetect库来枚举客户端的插件情况。

 

四、攻击样例

为了演示如何在真实的侦察活动中使用该方法，下面我将向大家介绍具体的使用步骤。

首先我们需要安装Serverless。在macOS上最快速的方法就是使用homebrew（brew install serverless）。命令执行完毕后，设置AWS_SECRET_ACCESS_KEY以及AWS_ACCESS_KEY_ID变量，使Serverless可以使用我们自己的AWS账户。

接下来需要在AWS中设置RDS实例，在rds_config.py脚本中配置凭据信息。

一旦RDS实例启动并正常运行，使用RDS实例对应的securityGroupIds以及subnetIds来更新VPC:configuration中的值，使其能部署到同一个VPC中，也就是说它们之间可以直接通信，无需重新配置安全组。从现在开始，我们只需要运行serverless ddeploy命令就可以将lambda-webbugs脚本部署到Lambda中：

以上操作就可以将我们的3个函数部署到Lambda中，用户可以通过对应的URL访问这些资源。

在侦察过程中，我们可能想分析用户是否在查看邮件，我们可以使用ping函数，在HTML电子邮件中嵌入如下内容来完成这个任务：

<img src=“https://x6025fpeq1.execute-api.eu-west-1.amazonaws.com/webbug/collect/ping?token=abcd&step=1” />

我们可能想要为每个钓鱼用户分配一个token值，以便跟踪起来更加方便，那么我们可以根据邮件操作的结果，使用step参数来表示具体阶段。当用户打开邮件时，邮件客户端就会尝试下载图片，发起HTTP请求，最终在我们的RDS数据库中的webbug表中新增一条记录：

假设我们的钓鱼邮件中包含一个诱饵，诱导用户访问我们控制的一个Web页面，以便进一步枚举用户信息，此时我们可以嵌入一个类似的IMG标签，这一次使用的是step=2，以便跟踪用户的受骗深度。

在同一个页面中，我们可以包含一个隐藏的iframe，再次请求枚举函数，枚举客户端的软件插件信息。请注意，这里我们需要提取令牌信息并将其重新插入iframe链接中，JavaScript很容易就可以完成这个任务，这里不再赘述：

<iframe src="https://x6025fpeq1.execute-api.eu-west-1.amazonaws.com/webbug/collect/enum?token=abcd" style="width:0; height:0; border:0; border:none" />

这次枚举操作会向collector函数发起POST请求，后者会将结果插入RDS数据库中，如下图所示：

由于我们的数据库采用云托管方案，我们选择不在数据库中存放敏感数据，所有用户都采用UUID值来标识。将结果存放在数据库中非常方便，我们可以根据实际需要来显示、组织并搜索这些信息，这一部分工作留待大家来完成。

出于安全目的，大家可能想使用自定义域名来配置Lambda函数，大家可以参考Amazon官方文档的详细介绍，本文不再赘述。