近期，一種新的難以捉摸的嚴重威脅已經出現(xiàn)，自2021年9月以來，它一直在滲透并駐留在全球的服務器上。這種被稱為HeadCrab的高級威脅利用了一種最先進的定制惡意軟件方式，使得該惡意軟件無法被無代理和傳統(tǒng)的防病毒解決方案檢測到，會危害大量 Redis 服務器。HeadCrab僵尸網絡已經控制了至少 1,200 臺服務器。

本報告將深入研究HeadCrab 攻擊的細節(jié)，研究其操作方法、用于逃避檢測的技術以及組織可以采取的保護其系統(tǒng)的步驟。

什么是 Redis？

Redis是一種開源的內存數(shù)據結構存儲，可用作數(shù)據庫、緩存或消息代理。默認情況下，Redis服務器不啟用身份驗證，旨在運行在安全、封閉的網絡上，而非暴露在互聯(lián)網上。這使得可從Internet訪問的默認Redis服務器容易受到未經授權的訪問和命令執(zhí)行的攻擊。

Redis集群提供了一種運行Redis安裝的方法，其中數(shù)據自動劃分并存儲在多個Redis節(jié)點上。在一個集群中，有一個主服務器和一個從服務器，可以方便地復制和同步數(shù)據。

默認的Redis命令之一是SLAVEOF，它指定一個服務器作為集群中另一個Redis服務器的從屬服務器。當服務器被定義為從服務器時，它將與主服務器同步，包括下載主服務器中存在的任何Redis模塊。

Redis模塊是可執(zhí)行的共享對象文件，可用于以各種方式增強服務器的功能。通過上傳模塊并通過Redis端口使用MODULE LOAD命令將模塊加載到服務器上。Redis 模塊使用Redis API執(zhí)行與服務器管理和控制相關的各種任務，例如使用RedisModule_CreateCommand API 定義自定義命令。

近年來，Redis 服務器已成為攻擊者的目標，通常是通過錯誤配置和漏洞。隨著 Redis 服務器變得越來越流行，攻擊的頻率也越來越高。

攻擊流程

這個故事始于對一個蜜罐的攻擊，當時攻擊者以 Redis 服務器為目標。該服務器最終使用SLAVEOF 命令被攻破，將其設置為攻擊者控制的另一臺 Redis 服務器的從服務器。Redis 主服務器隨后啟動了從服務器的同步，從服務器又將惡意Redis模塊 HeadCrab 惡意軟件下載到從服務器（蜜罐）上。攻擊者已使用此技術一段時間，并允許他們將惡意 Redis 模塊加載到受影響的主機上。如下圖所示，這些是從入站網絡數(shù)據收集中獲得的Redis命令日志。攻擊者首先列出所有可用模塊，配置服務器以允許上傳新模塊，然后將模塊下載到/tmp目錄。

將受害Redis服務器設置為從服務器

一旦模塊下載到受害服務器上的/tmp目錄，它就會使用MODULE LOAD /tmp/<module_name>命令加載到 Redis 進程中。如下面的屏幕截圖所示，攻擊者在最終成功之前嘗試加載多個模塊。

HeadCrab 惡意軟件模塊加載

在對加載的模塊進行逆向工程后，我們發(fā)現(xiàn)了一種復雜的、長期開發(fā)的惡意軟件。它為攻擊者提供了許多高級功能，并最終完全控制目標服務器。該模塊引入了 8 個自定義命令，以模式rds*命名，攻擊者使用這些命令在受感染的服務器上執(zhí)行操作。HeadCrab 惡意軟件的技術分析部分討論了惡意軟件功能和命令的完整列表。

蜜罐顯示攻擊的主要影響是用于加密貨幣挖掘的資源劫持。從內存中提取的礦工配置文件顯示，礦池主要托管在私人合法 IP 地址上。對這些 IP 地址的檢查表明，它們要么屬于干凈的主機，要么屬于一家領先的安全公司，這使得檢測和歸屬變得更加困難。在配置文件中找到了一項公共 Monero 礦池服務，但礦工在運行時未使用該服務。

我們不僅發(fā)現(xiàn)了HeadCrab惡意軟件，還發(fā)現(xiàn)了一種在Redis服務器中檢測其感染的獨特方法。當這一方法應用于暴露在外的服務器時，發(fā)現(xiàn)了大約 1,200 臺活躍的受感染服務器。受害者似乎沒有什么共同點，但攻擊者似乎主要針對Redis服務器，并且對Redis模塊和API有深刻的理解和專業(yè)知識，正如惡意軟件所展示的那樣。

我們注意到攻擊者已竭盡全力確保其攻擊的隱蔽性。該惡意軟件旨在繞過基于卷的掃描，因為它僅在內存中運行，而不存儲在磁盤上。此外，使用Redis模塊框架和API刪除日志。攻擊者與合法IP地址（主要是其他受感染的服務器）通信，以逃避檢測并降低被安全解決方案列入黑名單的可能性。該惡意軟件主要基于不太可能被標記為惡意的Redis進程。有效載荷通過memfd加載，內存文件，內核模塊直接從內存加載，避免磁盤寫入。

HeadCrab 惡意軟件的技術分析

HeadCrab 惡意軟件是一種高度復雜且先進的威脅。作為惡意Redis模塊框架構建，它擁有眾多選項和功能。本節(jié)將概述通過我們的靜態(tài)和動態(tài)分析確定的惡意軟件的主要功能。

如截圖所示，HeadCrab樣本在Virus Total (MD5=c5b992c76b7c9fa3b9bd755dd3b5af76) 上只有少量安全產品可以檢測。盡管我們嘗試獲取更多樣本，目前還沒有發(fā)現(xiàn)更多的樣本，這讓我們更加懷疑這是一種高度規(guī)避的新型惡意軟件。

驗證它在執(zhí)行時只運行一次

在初始執(zhí)行時，惡意軟件利用RedisModule_OnLoad函數(shù)，該函數(shù)在Redis服務器加載模塊時觸發(fā)。然后，惡意軟件會保存相關Redis API函數(shù)的地址以備后用，并檢查是否已加載名為rds的模塊，如果已加載，則立即退出而不進行任何惡意操作。

初始環(huán)境范圍界定

存儲啟動模塊加載的連接信息以供將來檢查。此外，惡意軟件會檢查它是作為特權 root 用戶還是作為名為redis的特權較低的用戶運行。

重視操作安全性（幻數(shù)）

該模塊可以加載2個參數(shù)（幻數(shù)），它們實際上是2個全局幻數(shù)，用作加密密鑰并驗證它的操作者是否真的是威脅者。之后，惡意軟件可以在其執(zhí)行流程中的不同位置對這些幻數(shù)進行一些操作。該模塊可以加載或不加載幻數(shù)，這將影響惡意軟件執(zhí)行期間的某些功能。如果模塊加載了2個參數(shù)，一些Redis默認命令（8個命令：Module、Client、Debug、Shutdown、Monitor、Slaveof、Replicaof、Config) 被主要返回錯誤的命令覆蓋。這樣做是為了避免惡意軟件檢測。如果模塊未加載2個參數(shù)，則跳過此步驟。修改后的默認命令如下：

此外，惡意軟件會刪除Redis日志文件，如果它是通過將其截斷為0大小重新創(chuàng)建的，則將其清空。

準備工作

惡意軟件會進行一些檢查以確定操作過程。我們不會詳細介紹這些檢查，但會檢查/testing路徑和執(zhí)行日期，并根據某些功能是否正在執(zhí)行來進行檢查。信號處理函數(shù)被替換并被惡意軟件用來與其子進程通信。

隱藏代碼執(zhí)行

惡意軟件找到動態(tài)加載程序的路徑，以便它可以執(zhí)行進程。通過簡單地提供所需可執(zhí)行文件的路徑作為參數(shù)，動態(tài)加載程序可用于以其名稱執(zhí)行進程。這可用于繞過基于檢查進程執(zhí)行來檢測惡意文件的安全解決方案。由于動態(tài)加載器是一個合法的二進制文件，它不會被標記為惡意的，并且惡意軟件可以在這些安全解決方案中隱藏自己。

從內存中執(zhí)行

該惡意軟件試圖在memfd_create系統(tǒng)調用的幫助下創(chuàng)建無文件文件。如果成功，它會創(chuàng)建10個memfd或臨時文件并保存它們供以后使用。

強調在容器中執(zhí)行

惡意軟件檢查進程ID是否低于31。我們推測這樣做是為了檢測服務是否在容器中運行。如果惡意軟件不在容器上運行，則會檢查幾個服務管理程序，如systemd、initd、upstart等。如果安裝了它們中的任何一個，它們將被標記，稍后將用于將持久化的服務和腳本放置在適當?shù)奈恢?。我們假設惡意軟件在容器上跳過了這一步，因為它是無效的。

創(chuàng)建新的Redis命令

然后惡意軟件創(chuàng)建新的 Redis 命令，用于使攻擊者能夠操作惡意軟件：

• rdsa該命令接受兩個參數(shù)。一個是 Redis 配置文件的路徑，第二個是惡意 Redis 模塊的路徑。此函數(shù)在 Redis 配置中添加一行，用于加載帶有幻數(shù)的惡意模塊。為了獲得惡意軟件的進一步持久性，它隱藏了loadmodule命令輸出。此命令用于加載惡意模塊，并通過向打印到屏幕的輸出添加填充來隱藏其活動。
• rdss執(zhí)行帶有popen并返回進程輸出作為命令輸出
• rdsp將默認命令替換為惡意函數(shù)以逃避檢測。
• rdsi通過截斷更新加密中使用的幻數(shù)和空日志。
• rdsmMONITOR是一個 Redis 調試命令，它流回 Redis 服務器處理的每個命令。它也被 rdsp 命令或使用 2 個參數(shù)加載模塊所取代。這個新命令負責恢復對MONITOR命令的更改——重新啟用服務器調試。
• rdsc偵聽所需端口上的傳入連接，并啟用與 C2 服務器建立加密通信通道。下面的附錄部分詳細描述了可用的命令。為了強調它的一些強大功能，惡意軟件可以創(chuàng)建一個新套接字并將其連接到 C2 命令套接字，將網絡隧道連接到另一個 IP 地址和端口對，執(zhí)行 shell 命令，將文件內容發(fā)送到 C2，將數(shù)據寫入打開 memfd 文件，讀取保存的 memfd 文件的內容并發(fā)送回 C2，加載無文件內核模塊，以及許多其他強大的功能。
• rdsr與 C2 服務器建立加密通信通道。與上面的 rdsc 相同。
• rdsx恢復被覆蓋的命令并將它們恢復為默認的 Redis 命令。

在以下截圖中，您可以看到對其中一些命令的模擬：

覆蓋和恢復默認命令的示例

誰是HeadCrab？或者，什么是 HeadCrab？

這個攻擊者和惡意軟件為什么被稱為HeadCrab。答案很簡單。攻擊者在攻擊過的機器中留下了如下信息。

正如以上截圖所示，攻擊者被識別為HeadCrab，這是游戲《半條命》中的一種怪物，它會附著在人類身上并將他們變成僵尸。這很合理，因為我們已經看到這種威脅使 Redis服務器僵尸化并使用它們橫向移動到其他服務器。

此外，攻擊者還創(chuàng)建了一個專門針對Nautilus團隊的博客條目。此參考適用于有關Redigo的博客。Redigo是一種針對Redis服務器的新型惡意軟件，攻擊者利用了一個允許從LUA沙箱中逃逸的漏洞，并導致目標服務器上的遠程代碼執(zhí)行 (CVE-2022-0543)。在進一步審查新發(fā)現(xiàn)的惡意軟件并在惡意軟件中發(fā)表個人專用評論后，我們認為到Redigo惡意軟件也在利用主從技術，而不是 LUA 沙箱逃逸。

這個攻擊組織是高度離散的，因此無法在開源中找到其活動的許多跡象。我們確實找到了上圖中出現(xiàn)的“pamdicks”。在Trend Micro的博客中，提到了一個名為netlink的rootkit用于更改與CPU相關的統(tǒng)計信息（可以隱藏pamdicks進程和 CPU 負載）來隱藏加密挖礦。但很可能是攻擊者所指的內容。

運行時檢測

HeadCrab惡意軟件旨在偷偷攻擊Redis服務器，無論它們是在容器中還是在VM上運行。企業(yè)都需要使用容器安全或主機安全類解決方案進行實時檢測，我并使用實時惡意行為指標來識別 HeadCrab 惡意軟件等隱秘攻擊。

將攻擊映射到 MITRE ATT&CK 框架

這里我們將上述攻擊中的組件映射到MITRE ATT&CK框架的相應攻擊技術：

總結、補救和緩解

在此報告中，我們揭示了負責創(chuàng)建高級惡意Redis框架的攻擊者 HeadCrab 的威脅。我們深入研究惡意軟件的內部工作原理并展示其豐富的功能。調查顯示，HeadCrab 的僵尸網絡已經控制了 1,200 多臺服務器，所有服務器都感染了該惡意軟件。我們有理由相信，HeadCrab 將堅持使用尖端技術滲透服務器，無論是通過利用錯誤配置還是漏洞。

立即修復受感染的服務器

如果您的服務器遭到破壞，則必須假設您的網絡也遭到破壞并立即啟動您的事件響應流程。這將幫助您檢測違規(guī)的程度、隔離受感染的系統(tǒng)并清理受影響的環(huán)境。雖然可以通過刪除關聯(lián)的服務和腳本來刪除惡意軟件，但刪除加載模塊從Redis配置和重啟服務器來看，攻擊者仍然保留了一些能力，包括刪除文件、執(zhí)行二進制文件、竊取 SSH 密鑰、掃描和與其他系統(tǒng)通信以及加載內核模塊的能力。這使得攻擊者可以在網絡中橫向移動。從服務器中完全消除攻擊者的存在可能是一項復雜的任務。為確保您的網絡安全，我們建議將Redis數(shù)據庫的備份保存到一個文件中，并盡可能將其遷移到具有適當授權和流量控制并且不能直接從Internet訪問的新服務器。

緩解建議

為了降低 Redis 服務器的風險，您希望通過確保Redis配置符合安全最佳實踐來強化環(huán)境。

在本報告中，攻擊者使用“主從”技術從遠程服務器復制數(shù)據庫到目標服務器（蜜罐）。此功能最初由Redis創(chuàng)建以提高性能和創(chuàng)建冗余，但被攻擊者積極使用以迅速感染目標并逃避檢測。我們建議采取以下步驟來加強您的Redis服務器的安全性：

(1) Redis 旨在供受信任環(huán)境中的受信任客戶端訪問。

這意味著通常，將Redis實例直接暴露給Internet或通常暴露給不受信任的客戶端可以直接訪問Redis TCP端口或UNIX套接字的環(huán)境并不是一個好主意。

(2) 每當您在云中使用Redis時，最好啟用保護模式以增強安全性。

保護模式確保數(shù)據庫只響應環(huán)回地址，并生成錯誤作為對所有從其他IP地址連接的節(jié)點的答復。

(3) 使用綁定參數(shù)接受來自已知主機的通信.

您的Redis服務器將只監(jiān)聽通過bind選項指定的地址的連接。這是一種安全措施，允許丟棄不是在網絡內部建立的連接。

(4) 如果沒有主動使用“slaveof”功能，我們強烈建議禁用它。

(5) 您可以在Redis安全管理部分或他們的相關博客中閱讀更多安全建議。

可以采取一些進一步的步驟來減輕對云中軟件開發(fā)生命周期的威脅，我們建議遵循以下準則：

• 未知威脅和零日漏洞將繼續(xù)存在。即使您做的每件事都正確，您也無法始終保護您的運行時環(huán)境免受此類攻擊。因此，您需要監(jiān)視運行時環(huán)境。部署 容器安全或主機安全解決方案以保護您的運行時環(huán)境。運行時監(jiān)控是一種基本實踐，可幫助快速緩解問題并最大程度地減少中斷。監(jiān)視過程還適用于可能發(fā)生可疑活動（例如，下載惡意二進制文件）的運行時環(huán)境。
• 掃描您的軟件供應鏈。您可以使用開源工具，例如 Chain-bench，旨在根據新的 CIS 軟件供應鏈基準審核您的軟件供應鏈堆棧的安全合規(guī)性。
• 為您的開發(fā)人員、DevOps 和安全團隊提供掃描漏洞和錯誤配置的工具。除了 商業(yè)化軟件工具，您還可以找到特定的開源工具（例如 Trivy）來掃描此類漏洞。