如何搭建無伺服器的紅隊基礎設施（Part 1）
一、前言
在紅隊行動期間，如果能夠快速且程式化地部署基礎設施通常能帶來不少好處。現有大多數參考資料主要關注的是使用 terraform 來部署適用於紅隊的、面向伺服器的基礎設施，目前這方面研究已經有較為成熟的解決方案，大家可以深入閱讀如下資料瞭解更多細節：
- ofollow,noindex" target="_blank">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 官方文件 的詳細介紹，本文不再贅述。