Jump to content

Hacker Technology

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

  • Entries

    16114

  • Comments

    7952

  • Views

    863106996

Contributors to this blog

  • HireHackking 16114

About this blog

Hacking techniques include penetration testing, network security, reverse cracking, malware analysis, vulnerability exploitation, encryption cracking, social engineering, etc., used to identify and fix security flaws in systems.

HireHackking

概要：“薪資調整”類釣魚郵件激增本週（2023年7月3日~7日），網際思安麥賽安全實驗室(MailSec Lab)觀察到大量新增的“薪資調整”類釣魚郵件攻擊，並做了詳細的風險特徵、攻擊溯源等技術研究與分析，請各企事業單位及時做好相關的防護。

熱點描述：關於此批“薪資調整”類釣魚郵件的典型樣本郵件，如下圖所示：

圖1. 關於薪資調整通知的釣魚郵件

1.jpg

該郵件通過偽造“薪資調整”通知，誘導員工點擊郵件正文中URL超鏈接，從而訪問精心構造的釣魚網站。當員工輸入其郵箱帳號和密碼後，攻擊者將獲得該私人賬戶信息，並可利用該信息成功登陸員工的私人郵件賬戶。

圖2. 點擊超鏈接後訪問的釣魚網站

2.jpg

圖3. 記錄帳號信息，並模擬系統繁忙

3.jpg

專家分析：MailSec Lab的技術專家從源IP、URL鏈接、郵件頭、郵件內容等方面，對此郵件的風險特徵進行了詳盡的技術分析。

l 郵件頭分析：X-Mailer字段此類風險郵件的頭部包含的“X-Mailer”字段值為“Supmailer 38.1.2”。

圖4. 郵件頭部X-Mailer字段展示

4.jpg

X-Mailer字段表明了攻擊者通過Supmailer軟件的38.1.2版本來發送釣魚郵件。 Supmailer是由一家德國公司研發的，用於批量創建和發送廣告郵件的軟件。該軟件的官方網站是“https://int.supermailer.de/”。該文件頭字段表明郵件發送者通過使用Supmailer軟件群發釣魚郵件，而非正常使用Outlook, Foxmail等郵件客戶端發送郵件。

圖5. Supmailer官方網站

5.jpg

圖6. Supmailer廣告郵件群發軟件界面截圖

6.jpg

l 郵件頭分析：源IP字段通過對郵件頭字段的分析可知，在該釣魚郵件到達公司之前，分別先後經過了221.235.220.134和218.70.153.165兩跳IP地址。

圖7. 郵件頭部源IP字段展示

7.jpg

查詢覆蓋全球的91個RBL數據源，檢測結果如下。兩個外部IP地址被列入了多達10多個的RBL黑名單。

序列號URL/IP被列為黑名單的RBL名稱1

218.70.153.165

Anonmails DNSBL

2

BARRACUDA

3

Sender Score Reputation Network

4

SORBS SPAM

5

Spamhaus ZEN

6

UCEPROTECTL2

7

TRUNCATE

8

UCEPROTECTL3

9

221.235.220.134

RATS NoPtr

10

Spamhaus ZEN

11

UCEPROTECTL2

12

UCEPROTECTL3

l URL超鏈接分析對URL鏈接的Whois信息進行查詢。該網站於1個多月前建立（2023年5月22日），並且服務器位於香港，因此不用進行公安註冊。此類新建設且未進行公安部註冊的網站大概率被用於發起黑客攻擊。

圖8 郵件中URL鏈接的Whois信息

8.jpg

對該IP進行域名反查，可得知該IP地址下共服務了42個域名，其中有近20個域名被威脅情報識別為惡意域名。由此可見，該IP下的服務器被攻擊者用於批量建設釣魚網站。

圖9. 同一個IP下有近20個惡意域名

9.jpg

並且該URL超鏈接的域名被知名威脅情報也列為惡意域名：

圖10. 該域名被威脅情報列為惡意域名

10.jpg

郵件正文中URL鏈接格式如下：https://mail-al.cn/#contact@

HireHackking

本期熱點“電子發票”木馬類惡意郵件激增本週（2023年7月10日~14日），網際思安麥賽安全實驗室(MailSec Lab)觀察到大量新增的以“電子發票”為主題的特洛伊木馬類惡意郵件，並做了詳細的風險特徵、攻擊溯源等技術研究與分析，請各企事業單位及時做好相關的防護。

2023.07.10~2023.07.1401熱點描述關於此批“電子發票”為主題的病毒樣本郵件，如下圖所示：

圖1. “電子發票”為主題的特洛伊木馬郵件

图片

該郵件通過偽造下載電子發票通知，誘導員工點擊郵件正文中的URL超鏈接，從而下載Trojan Droppers程序。當員工雙擊觸發程序後，該惡意程序將自動連接攻擊者搭建的惡意網站，進一步下載特洛伊木馬病毒，並對計算機進行遠程控制、數據盜竊、內網橫向攻擊等APT攻擊行為。

图片思安知識小課堂Trojan Droppers是一種惡意軟件，用於傳遞和部署其他惡意軟件或特洛伊木馬（Trojans）。它們通常被設計成看似無害或合法的文件，以欺騙用戶進行下載和執行。一旦Trojan Dropper被執行，它會解壓或下載其他惡意組件並將其安裝到受感染的計算機上，而這些組件可能會執行各種惡意活動，如竊取敏感信息、遠程控制計算機、加密文件等。

Trojan Droppers的主要目標是通過繞過安全防護機制，將惡意軟件引入目標系統。為了達到這個目的，它們常常採用以下策略：

偽裝成合法文件：Trojan Droppers會將自己偽裝成常見的文件類型，如圖像文件、文檔、媒體文件等，以便讓用戶誤以為它們是無害的。

利用安全漏洞：Trojan Droppers可能會利用操作系統或應用程序中的已知漏洞，通過這些漏洞將惡意軟件注入目標系統。

社會工程攻擊：Trojan Droppers有時會利用社會工程技術，通過欺騙用戶進行下載和執行。例如，它們可能會偽裝成電子郵件附件、下載鏈接或彈出廣告等形式出現。

多層加密和混淆：為了逃避安全軟件的檢測，Trojan Droppers通常使用多層加密和混淆技術，使其代碼變得難以分析和檢測。

一旦Trojan Dropper成功投遞並安裝了其他惡意軟件或特洛伊木馬，後者可能會執行各種惡意活動，如數據竊取、遠程控制、密鑰記錄、網絡攻擊等。

圖2. 點擊鏈接後下載Trojan Droppers程序

图片

02專家分析MailSec Lab的技術專家從源IP、URL鏈接、EXE文件風險性、郵件頭、郵件內容等方面，對此郵件的風險特徵進行了詳盡的技術分析。

PART01惡意鏈接的域名图片提前劃重點使用welljoint.com域名的某高科技公司，通過“新網互聯”網站購買了域名和郵箱服務。但是該郵箱服務器被黑客攻陷，welljoint.com域名被惡意利用為下載Trojan Droppers程序提供服務。

從分析來看，不僅是welljoint.com域名受影響，其他十幾個域名也同時受影響，可能被黑客用於攻擊活動。

通過瀏覽器直接訪問URL鏈接的域名“welljoint.com”，可以了解到使用該域名的公司為一家位於上海的高科技公司，主要為銀行、保險等金融機構提供聯絡中心系統解決方案，曾獲“上海市科技小巨人”和“專精特新中小企業”榮譽。

圖3. 某某科技公司官方網站

图片

對“welljoint.com”域名的Whois信息進行查詢。該域名於2011年5月11日註冊，到期時間為2032年4月17日，域名持有者為“Xin Net Technology Corporation”。

圖4. welljoint.com的Whois信息

图片

進一步調查可知，該域名的持有者“Xin Net Technology Corporation”（新網互聯）為一家提供域名註冊、虛擬主機、網站建設等服務的公司。而通過“天眼查”可以了解到，在welljoint.com域名上建設官方網站的某高科技公司成立於2011年4月21日。結合以上信息，我們可以推斷：該高科技公司成立1個月以後，通過新網互聯公司註冊了域名。

圖5. 通過新網互聯註冊域名

图片

郵件樣本中的惡意URL鏈接為：

http://mail.welljoint.com:81/download/attachment/

HireHackking

概要：Bounce類釣魚郵件激增

本週（2023年7月17日~21日），思安麥賽安全實驗室觀察到大量增加的Bounce釣魚郵件，請各單位和企業做好相關的防護。

熱點描述：

關於此批Bounce釣魚郵件，如下圖所示：

圖1. Bounce釣魚郵件樣本

1.jpg

為了隱藏真實身份並躲避欲攻擊對象所在公司的郵件安全檢測，防止攻擊郵件被攔截，黑客偽造並使用目標攻擊對象的郵件地址作為發件人郵件地址，並故意將郵件投遞給一個知名公司的不存在郵件地址。因為收件人地址不存在，該知名的公司的郵件服務器會向發件人地址發送bounce退信郵件，通知該發件人郵件投遞失敗。

當被攻擊對象所在公司的郵件服務器收到bounce退信郵件後，因為該郵件來自於知名公司，所以會正常的接收該退信郵件並將郵件放置到發件人的收件箱。一旦員工打開退信郵件的附件後，將查看到黑客發送來的威脅信息：

圖2. 含威脅信息的郵件

2.jpg

專家分析：

思安麥賽安全實驗室的專家對此郵件的風險特徵進行了技術分析。

分析1：源IP地址

對bounce退信郵件的附件進行分析，根據郵件頭的指定字段可知，該惡意郵件的來源IP地址（攻擊者IP地址）是121.52.144.171。

圖3. 郵件頭部源IP字段展示

3.jpg

該IP地址位於“巴基斯坦/旁遮普邦/拉瓦爾品第”地區，網絡服務商為“HEC”。當前該IP地址下使用了“華為USG6630防火牆”和“騰達路由器”設備，說明該IP地址下的組織很大概率為一個正常運行的企業或服務商，而黑客攻陷或租用了該組織的計算機，並使用該計算機發送了Bounce攻擊郵件，而非使用私人網絡環境發起攻擊。

圖4. 該IP下的華為USG6630防火牆

4.jpg

圖5. 該IP下的騰達路由器

5.jpg

與此同時，查詢該IP地址的信譽可知，此IP地址所在的網段，曾經存在大量惡意IP地址：

圖6. 該IP網段下曾存在大量惡意IP地址

6.jpg

分析2：偽造發件人地址

攻擊者從位於巴基斯坦的計算機上，偽裝為國內某家知名公司的員工，向馬來西亞一家金融機構發送了攻擊郵件。該馬來西亞公司的郵件設備，嘗試對發件人郵件地址進行了SPF和DKIM驗證，驗證發件人地址的有效性。然而很可惜，該國內知名公司的域名並未開啟相關的郵件防偽造檢測機制。因此馬來西亞公司的郵件設備未拒絕該郵件，並因為收件人在該公司不存在，而向中國公司發出了退信郵件。

圖7. 被攻擊公司未開啟郵件防偽造機制

7.jpg

圖8. 通過了對發件人地址有效性的驗證

8.jpg

分析3：郵件攻擊鏈路溯源

經分析此郵件的完整攻擊溯源圖9如下所示：

9.jpg

總結與攻擊溯源：

經思安麥賽安全實驗室的分析測試，我們認為此“Bounce釣魚”郵件樣本含有的風險特徵包括：

攻擊起源IP地址下的組織很大概率為一個正常運行的企業或服務商，而黑客攻陷或租用了該組織的計算機，並使用該計算機發送了Bounce攻擊郵件；

攻擊起源IP地址所在的網段，曾經存在大量惡意IP地址；

攻擊者偽裝為國內某家知名公司的員工發送郵件，該中國公司的域名並未開啟相關的郵件防偽造檢測機制；

郵件正文內容中含比特幣、匯款、賬戶等敏感詞彙。

防范建議：

Bounce釣魚郵件是一種郵件攻擊手段，通常用於隱蔽地向攻擊目標發送惡意內容，而避免直接暴露攻擊者的郵件地址，並躲避被攻擊目標組織的郵件安全檢測。

要防範Bounce釣魚郵件應遵循如下一些安全實踐：

1. 本域名郵件地址驗證：實施SPF、DKIM和DMARC等發件人驗證技術，從而幫助第三方組織驗證郵件的真實來源；

2. 警惕緊急情況：釣魚郵件常常試圖製造緊急情況，以迫使受害者匆忙採取行動。要保持冷靜，不要受到威脅或誘惑；

3. 使用郵件安全防護設備：部署可靠且穩定的郵件安全網關、郵件安全沙箱等郵件安全防護設備；

4. 定期檢查安全防護設備：確保郵件安全防護設備的策略配置正確且生效，並確保設備的防護庫已升級到最新版本；

5. 培養安全意識：加強員工和自己的安全意識培訓，教育他們如何識別潛在的惡意郵件，並提醒他們不要隨意打開可疑的附件；

6. 鼓勵員工報告可疑郵件：如果收到可疑郵件，員工應及時將其報告給您的組織或相關機構，以幫助企業採取適當的行動保護其他員工；

7. 驗證財務交易：如果收到涉及財務交易的電子郵件，避免通過郵件直接響應。相反，通過銀行官方網站、銀行櫃檯、財務部同事等安全渠道來驗證交易。

8. 防止個人和郵件信息洩露：盡量不要在公開的論壇、社交媒體或不受信任的網站上洩露個人和郵件信息。攻擊者可能會利用這些信息來製作更具針對性的釣魚郵件；

麥賽安全實驗室（MailSec Lab）介紹：

北京網際思安科技有限公司麥賽郵件安全實驗室（MailSec Lab）依託於網際思安過去12年積累的郵件威脅數據，匯集了一批10+工作經驗的行業專家，專注於新型郵件威脅的調研，和下一代郵件安全技術的創新性研究。在過去十多年中，MailSec Lab服務於3000+家各個行業領域的典範客戶，獲得客戶的廣泛讚譽。與此同時，實驗室積極與國際和國內知名信息安全廠商合作，廣泛開展威脅情報互換、共同研究等合作，構建共同防禦的威脅防護體系。

HireHackking

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

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

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

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

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

1.png

真實遊戲的網頁（上）和假冒遊戲的網頁（下）

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

2.png

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

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

3.png

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

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

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

4.png

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

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

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

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

5.png

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

2. 它將內容寫入路徑為

6.png

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

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

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

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

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

Binance

Exodus

Keplr

Metamask

Phantom

Trust wallet

7.png

用於竊取錢包數據的函數

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

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

/bin/sh -c security default-keychain

8.png

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

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

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

9.png

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

10.png

獲取受害者密碼的對話框

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

11.png

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

12.png

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

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

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

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

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

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

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

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

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

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

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

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

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

13.png

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

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

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

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

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

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

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

14.png

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

15.png

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

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

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

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

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

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

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

HireHackking

moon-luna-red-danger-sl-1200x600.jpg

Luna：用Rust 編寫的全新勒索軟件上個月，卡巴斯基實驗室的研究人員在暗網勒索軟件論壇上發現了一個新型惡意軟件，該惡意軟件是用Rust 編寫的，可以在Windows、Linux 和ESXi 系統上運行，研究人員通過卡巴斯基安全網絡(KSN) 找到了一些樣本。

1.png

Luna 中可用的命令行選項

從可用的命令行選項來看，Luna 相當簡單。但是，它使用的加密方案並不那麼典型，因為它涉及x25519 和AES，這是勒索軟件方案中不經常遇到的組合。

Linux 和ESXi 示例都是使用相同的源代碼編譯的，與Windows 版本相比有一些細微的變化。例如，如果Linux 示例在沒有命令行參數的情況下執行，它們將不會運行。相反，它們將顯示可以使用的可用參數。其餘代碼與Windows 版本相比沒有顯著變化。

開發者稱Luna 只與講俄語的機構合作。此外，在二進製文件中硬編碼的贖金記錄包含拼寫錯誤。例如，它說“a little team”而不是“a small team”。因此，我們假設Luna 背後的開發者是講俄語的人。由於Luna 是一個新發現的組織，關於其受害者的數據仍然很少。

Luna 證實了跨平台勒索軟件的趨勢：當前的勒索軟件組織嚴重依賴Golang 和Rust 等語言，其中就包括BlackCat 和Hive。這些語言與平台無關，用這些語言編寫的勒索軟件可以很容易地從一個平台移植到其他平台，因此攻擊可以同時針對不同的操作系統。除此之外，跨平台語言有助於規避靜態分析。

Black Basta

Black Basta 是一種用C++ 編寫的相對較新的勒索軟件變體，於2022 年2 月首次被發現。該惡意軟件、基礎設施和活動當時仍處於開發模式。例如，受害者博客尚未上線，但Black Basta 網站已經可供受害者使用。

Black Basta 支持命令行參數“-forcepath”，該參數只用於加密指定目錄下的文件。否則，整個系統(除某些關鍵目錄外)將被加密。

兩個月後，也就是四月，勒索軟件變得更加成熟。新功能包括在加密之前以安全模式啟動系統，以及出於持久性原因模仿Windows 服務。

安全模式重啟功能並不是我們每天都會遇到的，儘管它有它的優勢。例如，一些終端解決方案不會在安全模式下運行，這意味著不會檢測到勒索軟件，並且系統中的文件可以“輕鬆”加密。為了以安全模式啟動，勒索軟件執行以下命令：

C:\Windows\SysNative\bcdedit/setsafebootnetworkChanges

C:\Windows\System32\bcdedit/setsafebootnetworkChanges早期版本的Black Basta 包含與當前使用的不同的記錄，顯示出與Conti使用的贖金記錄相似。這並不像看起來那麼奇怪，因為當時Black Basta 仍處於開發模式。

2.jpg

贖金記錄比較

為了確定Conti 和早期版本的Black Basta 之間確實沒有代碼重疊，研究人員人員提取了一些樣本。確實，如下圖所示，只有字符串重疊。因此，代碼本身沒有重疊。

3.png

與Conti 勒索軟件重疊

適用於Linux 的Black Basta在上個月的另一份報告中，我們討論了Linux 的Black Basta 版本。它是專門為ESXi 系統設計的，但它也可以用於Linux 系統的一般加密，儘管這會有點麻煩。

就像Windows 版本一樣，Linux 版本只支持一個命令行參數：“-forcepath”。使用時，只對指定目錄進行加密。如果沒有給出參數，“/vmfs/volumes”文件夾將被加密。

該版本的加密方案使用ChaCha20和多線程技術，借助系統中不同的處理器來加速加密過程。鑑於ESXi環境通常使用多個CPU 來執行VM 場，惡意軟件的設計（包括所選的加密算法）允許操作員盡快對環境進行加密。在加密文件之前，Black Basta 使用chmod 命令在與用戶級別相同的上下文中訪問它。

Black Basta目標對Black Basta 組織發布的受害者的分析顯示，迄今為止，該組織已成功在很短的時間內攻擊了40 多名不同的受害者。受害者博客顯示，包括製造、電子、承包商等在內的各個業務部門都受到了影響。根據分析數據，我們可以看到歐洲、亞洲和美國也受到了攻擊。

HireHackking

BlackMatter是一種勒索軟件變體，它使用Salsa20和1024位RSA加密文件，並需要大量加密貨幣進行解密。與許多其他勒索軟件組織一樣，BlackMatter通過洩露數據的威脅來增加獲得支付贖金的機會。 BlackMatter作為一種勒索軟件即服務(RaaS)運行。

2022年6月，LockBit發布了其勒索軟件3.0版。在這篇文章中，我們將詳細討論其攻擊過程，以及其與BlackMatter勒索軟件的相似之處。

2022年3月，也就是LockBit2.0首次出現不到一年後，研究人員發現了即將推出的LockBit勒索軟件新變種。 LockBit3.0，又名“LockBitBlack”，要到6月下旬才會發布，與此同時，該組織推出了新的漏洞洩露網站和漏洞獎勵計劃。此後，一位研究人員分享了LockBit3.0的樣本，以及他對新變體的初步分析。

detect it easy是一款跨平台的PE查殼工具，研究人員使用這個工具發現這個特定的LockBit3.0樣本是一個Win32.exe文件，其中包含多個部分，由未知的加殼器封裝（圖1）。根據樣本的原始來源，惡意軟件使用此參數執行：

{04830965-76E6-6A9A-8EE1-6AF7499C1D08}.exe-kLocalServiceNetworkRestricted-passdb66023ab2abcb9957fb01ed50cdfa6aLockBit3.0示例隨後會刪除一個.ico文件，該文件的文件名與附加到%PROGRAMDATA%文件夾中加密文件的文件名相同（圖2）。

1.png

LockBit3.0的文件屬性

2.png

%PROGRAMDATA%文件夾中的.ico文件

作為其加密過程的一部分，LockBit3.0附加了擴展名HLJkNskOq（圖3），並將加密文件的圖標更改為上述.ico文件的圖標。

3.png

帶有新文件名和擴展名的加密文件，以及LockBit的勒索信

然後，勒索軟件釋放其勒索信，其中提到了“IlonMusk”和歐盟的通用數據保護條例(GDPR)。最後，它會更改受害者計算機的壁紙，以通知他們盡快繳納贖金。

4.jpg

LockBit3.0勒索信的內容

5.png

LockBit3.0的桌面壁紙

與BlackMatter勒索軟件的相似之處研究人員指出，LockBit 3.0的部分代碼似乎借鑒了BlackMatter勒索軟件，因此LockBit 3.0又被稱為LockBit Black。同樣地，我們在調試LockBit3.0示例期間發現了BlackMatter和新的LockBit變體之間存在相似之處。從我們對解壓樣本的檢查和研究員ChuongDong提供的分析中，我們發現LockBit3.0需要一個pass參數來解密其主程序。研究人員已經觀察到其他勒索軟件家族，如Egregor也表現出了相同的行為，其中需要參數才能繼續執行該程序。如果參數不可用，這會使二進製文件更難反轉。

6.png

使用-pass參數解密部分

LockBit 3.0通過哈希DLL的API名稱來執行API收集，然後將其與勒索軟件所需的API列表進行比較。這個程序與BlackMatter相同，因為重命名BlackMatter的API的外部可用腳本也適用於LockBit 3.0。

7.png

LockBit3.0的API收集程序

8.png

BlackMatter的API收集程序

9.png

LockBit3.0用於重命名API的XOR密鑰

10.png

BlackMatter用於重命名API的XOR密鑰

LockBit 3.0沒有直接調用收集到的API的地址，而是實現了一個蹦床指針，該指針指向一個已分配的堆，其中包含一個反彙編代碼，然後該代碼將跳轉到NtTerminateProcess API的API地址。堆中包含的代碼是從這組代碼中隨機選擇的：

隨機數ROR；

隨機數ROL；

異或密鑰；

通過隨機數ROR，然後異或到密鑰；

ROL隨機數，然後異或到密鑰；

11.png

LockBit3.0的蹦床指針代碼

12.png

LockBit3.0對NtTerminateProcessAPI的蹦床調用

LockBit3.0和BlackMatter也實現了相同的反調試技術：兩者都通過NtSetThreadInformationAPI將線程信息設置為ThreadHideFromDebugger(0x11)，以導致任何調試器在這個線程上設置斷點時崩潰。

13.png

通過NtSetThreatInformation的ThreadHideFromDebugger

與BlackMatter一樣，LockBit3.0在使用API時使用線程而不是直接調用API，這可能是為了讓研究人員更難分析。它使用的字符串使用簡單的按位XOR程序、按位XOR和NOT程序或涉及線性同餘生成器(LCG)算法以生成偽隨機密鑰的解密程序。除了添加了按位XOR和NOT程序，其他都類似於BlackMatter的操作方式。

14.png

LockBit3.0用於字符串解密的按位異或程序

15.png

LockBit3.0的按位XOR和NOT用於字符串解密

16.png

LockBit的3.0字符串解密使用LCG算法

LockBit3.0的配置使用相同的XOR程序和從LCG偽隨機數生成器獲得的密鑰進行解密，然後使用稱為APLib的壓縮庫進行解壓縮。

17.png

LockBit3.0的配置列表

LockBit3.0還會檢查受害計算機的UI語言，以避免用這些語言攻擊計算機：

阿拉伯語（敘利亞）；

亞美尼亞語（亞美尼亞）；

阿塞拜疆語（西里爾語阿塞拜疆）；

阿塞拜疆語（拉丁語阿塞拜疆）；

白俄羅斯語（白俄羅斯）；

格魯吉亞語（格魯吉亞）；

哈薩克語（哈薩克斯坦）；

吉爾吉斯（吉爾吉斯斯坦）；

羅馬尼亞語（摩爾多瓦）；

俄語（摩爾多瓦）；

俄語（俄羅斯）；

塔吉克語（西里爾塔吉克斯坦）；

土庫曼（土庫曼斯坦）；

韃靼語（俄羅斯）；

烏克蘭語（烏克蘭）；

烏茲別克語（西里爾文烏茲別克斯坦）；

烏茲別克語（拉丁烏茲別克斯坦）；

LockBit3.0還保留了這些BlackMatter程序，以用於提權升級：

使用UACMe的方法繞過用戶帳戶控制(UAC)，這是在dllhost.exe下使用ICMLuaUtil COM接口；

複製Explorer.exe令牌以供自己使用；

執行32位或64位shellcode注入以提升其令牌。

LockBit3.0和BlackMatter都用作加密文件擴展名、勒索信名稱以及壁紙和圖標名稱的字符串是Base64編碼的哈希。然而，這兩種勒索軟件之間的一個關關鍵區別在於，LockBit3.0選擇使用嵌入在其配置中的RSA公鑰，並使用MD5對其進行哈希處理，而BlackMatter使用具有相同算法對API進行哈希處理的MachineGUID。這使得被同一樣本感染的所有計算機的字符串看起來都相似，這可能是LockBit的操作人員的一種嘗試，以便他們更容易識別加密文件所需的RSA私鑰對。

18.png

BlackMatter（左）和LockBit3.0（右）的字符串生成

與BlackMatter一樣，LockBit3.0也執行以下程序：

嘗試使用其配置列表中的憑據登錄，以確定受感染的系統是否是將用於以後程序的域管理員的一部分；

一個類似於BlackMatter的程序會終止並從其配置列表中刪除進程和服務；

擦除每個驅動器的回收站文件夾；

檢查計算機名哈希列表，以避免從其配置列表中刪除；

如果設置了標誌，則從其配置列表連接到CC服務器；

如果在其配置標誌中設置，則加密網絡共享和Exchange郵箱；

從其配置列表中獲取要避免使用的文件、文件夾和擴展名列表；

加密.lnk文件時使用指向文件；

在任何可用的打印機上打印勒索信並修改桌面壁紙；

使用與BlackMatter相同的加密算法；

LockBit3.0對卷影副本的刪除顯然是從BlackMatter的代碼中刪除的，因為這是使用WindowsManagementInstrumentation(WMI)通過COM對象執行的，而不是LockBit2.0使用vssadmin.exe。

19.png

LockBit3.0通過WMI刪除卷影副本

這個最新的LockBit迭代只在提供特定參數時才會執行一些程序。 LockBit 3.0只接受表2中列出的參數，而BlackMatter只接受-safe、-wall和-path參數。

20.png

LockBit3.0接受的參數列表

新的LockBit變體使用哈希和基於代碼檢查參數，它被設計為只執行一個來自參數的例程，除了-pass，它需要在檢查其他參數之前執行。如果提供了-wall參數，則打印勒索信和更改受害計算機牆紙的程序也類似於BlackMatter的程序。像BlackMatter一樣，只要提供了-safe參數，LockBit3.0也可以在安全模式下重新啟動並通過RunOnce註冊表執行。

然而，它們的配置標誌之間有一個關鍵的區別：BlackMatter只有9個標誌，而LockBit3.0有24個，詳見表3。

21.1.png

21.2.png

21.3.png

21.4.png

可以在LockBit 3.0的配置中設置的標誌

第三個LockBit版本的一個值得注意的行為是它的文件刪除技術：它不使用cmd.exe執行將執行刪除的批處理文件或命令，而是刪除並執行從二進製文件中解密的.tmp文件。但是，只要提供了-gspd參數，它就會保留LockBit2.0的一些功能，例如早期版本通過組策略更新進行橫向移動的能力。

執行的.tmp文件會覆蓋勒索軟件二進製文件的內容，然後使用基於原始文件名長度的新文件名多次重命名該二進製文件，例如，一個名為1.exe的文件，它有五個字符（包括文件擴展名），被重命名為AAAAA，然後是BBBBB，直到ZZZZZ。重命名文件後，LockBit3.0最終將其刪除。該程序可能是LockBit勒索軟件組織試圖避免通過取證工具進行恢復，並通過完全刪除任何勒索軟件的痕跡來掩蓋他們的踪跡。

22.png

LockBit3.0多次重命名勒索軟件文件

23.png

LockBit3.0在反復重命名後刪除勒索軟件文件

VirusTotal上的LockBit3.0最近，一位研究人員在VirusTotal上發現了另一個LockBit 3.0示例，在撰寫本文時，在撰寫本文時檢測到了19個。這個特定的示例是一個包含兩層模糊代碼的PowerShell腳本。在對腳本進行去混淆之後，我們發現LockBit 3.0能夠通過反射加載將DLL注入內存，使用的代碼與BlackMatter自己的PowerShell代碼相同。

24.png

截至2022年7月21日在VirusTotal上發現的LockBit3.0樣本

25.png

LockBit3.0的第一層混淆代碼

26.png

LockBit3.0的第二層混淆代碼

27.png

LockBit3.0的反混淆PowerShell腳本

28.png

LockBit3.0的主要功能

29.png

BlackMatter的主要功能

此特定示例具有通過Base64壓縮和加密的有效負載。為了訪問它，我們修改了腳本以轉儲有效負載而不是執行它。通過轉儲有效載荷，我們能夠獲得LockBit3.0的主要二進製文件。

執行時，該腳本表現出與之前發現的LockBit3.0示例相同的行為。此特定示例將19MqZqZ0附加到加密文件的文件名。

30.png

LockBit3.0的有效載荷

31.png

轉儲LockBit3.0的有效負載

32.png

LockBit3.0的主要二進製文件

33.png

LockBit3.0的加密文件，其名稱後附有19MqZqZ0

這個特定的LockBit 3.0示例的有效負載只檢查3個哈希參數，而之前的LockBit3.0示例檢查了8個。它的DLL有效負載是反射式加載的，其通過管理共享和組策略傳播程序的代碼是為PE（便攜式可執行文件）二進製文件設計的，而不是為PowerShell腳本設計的，這可能解釋了為什麼某些程序不起作用。另一種可能性是，LockBit3.0的勒索軟件構建器可能會選擇禁用某些程序。即使檢查了-pass

HireHackking

Linux 內核是一個不斷迭代的代碼庫，截至2021 年，其代碼行數已超過3000 萬行。然而，由於用戶通常不會運行最新的頂層Linux 內核，因此從用戶的角度來看，它也是一個非常分散的代碼庫，這對安全性有重要影響。一致的安全屬性（跨內核版本、處理器架構、編譯器版本）是grsecurity一個重要目標，但頂層通常不會將添加的預防性安全檢查或功能向後移植到舊支持的內核，並且這些措施的狀態沒有很快被最終用戶採用，實際上，必須是有經驗的專注於安全的內核開發人員才能確定他們自己系統的狀態。

作為系統管理員，我們首先要擔心的問題是一個系統的安全性和穩定性，其次才是它的效能和效率。一個系統是否安全，一般來說與系統的複雜性有直接關係。對於必須開放訪問的系統來說，成熟而可靠的系統保護措施是十分重要的。而對作為各種程序運行平台的操作系統而言，系統越複雜可能隱藏的攻擊面也就越多。

受copy_*_user 中的檢查影響的漏洞類型在過去已經出現過幾次，例如， Mathias Krause 在2013 年的修復報告。在討論這些檢查時，最有意義的是談論當前的頂層狀態，之後我們可以討論代碼的歷史以及它是如何隨著時間的推移而演變的。

當前頂層copy_*_user() 檢查在當前的頂層內核中，copy_from_user（用於將數據從用戶級複製到內核）和copy_to_user（用於將數據從內核複製到用戶級）實現如下：

1.png

因此，如果check_copy_size() 通過，則將調用較低級別的copy_*_user 例程。這些較低級別的例程可以內聯或不內聯，具體取決於處理器架構，但它們的實現方式保持不變：

2.png

access_ok() 是一個古老的例程，其目的是驗證用戶空間中提供的範圍（作為copy_from_user 的源，copy_to_user 的目標）是否實際駐留在用戶空間中。這個API 最近發生了變化，從thread_info 結構中刪除了addr_limit 並將內核拆分為內核副本到它自己的API。以前，在addr_limit 恢復之前的set_fs(KERNEL_DS) 或惡意修改的addr_limit（過去幾年的常見漏洞利用技術）之後運行的代碼可以（ab）使用copy*user 進行任意內核讀/寫。

should_fail_usercopy() 與錯誤注入（模糊增強）有關，可以忽略。 instrument_* 同樣可以忽略，因為它與KASAN（調試/模糊測試增強）有關。出於生產安全目的，我們感興趣的唯一代碼是access_ok() 和check_copy_size()。

3.png

讓我們稍微解釋一下這裡顯示的內容:__compiletime_object_size()是一個宏，它利用了編譯器的__builtin_object_size()。如果內核中用於復制的源或目標(適當)的對象的大小能夠在編譯時確定，這將返回該對象的大小。否則，編譯器版本不支持__builtin_object_size()，它返回-1。

當內核對象的大小是靜態已知的並且要復制的長度也是恆定的時，__bad_copy_from() 和__bad_copy_to() 都是編譯時出現的錯誤，這種情況在實踐中不太可能會變成安全問題，除非代碼從未測試/使用過。當對像大小靜態已知但複製長度不是編譯時常量時，Copy_overflow()是一個運行時警告。

如果復制長度大於INT_MAX，“WARN_ON_ONCE(bytes INT_MAX)”檢查將產生運行時警告。由於這是在無符號size_t 類型上計算的，因此當在有符號int 或long 類型上解釋時（即oss-sec 上報告的錯誤的情況），這具有拒絕負長度的附加效果。稍後會詳細介紹此檢查。

check_object_size() 來自頂層的USERCOPY 功能的有限版本。不會對其返回值進行檢查，因為它不會像其他檢查那樣簡單地使復制失敗，而是在usercopy_abort() 中執行BUG() ，這在簡單的情況下將簡單地終止所涉及的進程，但在更複雜的場景中，例如在用戶空間副本周圍保留互斥鎖可能會導致某些代碼路徑鎖定，或者在panic_on_oops 場景中，會導致系統崩潰。

關於oss-sec 報告中討論的漏洞的實際影響，由於2018 年6 月的'fsi: Add cfam char devices'中針對Linux 4.19 引入了錯誤的CFAM 更改，因此cfam_write() 案例將進入copy_from_user()使用負長度，到達check_copy_size() ，其中__compiletime_object_size() 將返回4 用於復製到的__be32 數據變量，然後由於字節不是編譯時常量，將調用copy_overflow()，觸發其中包含的WARN()，並錯誤地中止複制操作。

為了簡潔起見，我們將把分析限制在這些方面，而不會深入raw_copy_*_user()本身的實現，它已經看到了自己的體系結構特定的發展，包括SMAP/PAN/等的引入和Spectre的發現。

在繼續之前要注意的最後一點是memset()只存在於_copy_from_user()中，內核註釋如下：

注意：1.只有copy_from_user() 在短複製的情況下將目標置零。 2.__copy_from_user() 和__copy_from_user_inatomic() 都不為零。 3.他們的調用者絕對必須檢查返回值。

注意__copy_*_user(兩個下劃線)和_copy_*_user(一個下劃線)是不同的。這個memset()的原因大概是為了解決Linux歷史上copy_*_user被標記為__must_check屬性之前的情況，要求調用者檢查返回值是否錯誤。考慮一種常見的情況，即從用戶級複製結構，內核更改了某些字段，然後將結構複製回用戶級。如果來自用戶級的副本或內核設置字段沒有寫入的區域被複製回用戶級，且未初始化，它們可能會將之前的內存內容洩漏到用戶級(信息洩漏)。用戶級還可以通過使部分複制範圍包括未映射的地址或操作的無效權限來強制低級複製例程中的部分失敗。

check_object_size() 的歷史這個檢查第一次出現在2016年6月的Linux 4.8版本中，通過commit“mm: Hardened usercopy”。它的提交信息如下：

“這是將PAX_USERCOPY移植到主線內核的開始。這是由CONFIG_HARDENED_USERCOPY控制的第一組特性。這項工作是基於PaX Team和Brad Spengler的代碼，以及Casey Schaufler的早期移植。其他非平板頁面測試來自Rik van Riel。”

check_object_size() 通過引用堆和其他元數據來工作，以便在運行時盡可能驗證複製操作是否發生在單個對象的範圍內。

儘管上面提到的提交消息是移植完整功能的開始，但在5年裡，除了禁用上述添加的頁面測試(grsecurity中不存在)以外，該功能沒有出現其他重大變化，這破壞了內核的幾個方面。 PAX_USERCOPY最初發佈於2009年，比有限的上游版本早了大約7年。強化後的用戶複製代碼沒有向後移植到早期版本，包括當時的活動LTS 版本。因此，頂層4.4 XLTS。

__compiletime_object_size()/__builtin_object_size() 的歷史__builtin_object_size()在2005年Arjan van de Ven編寫的FORTIFY_SOURCE補丁中首次使用。它最初關注的是FORTIFY_SOURCE在用戶級中也涵蓋的典型的str*和mem* api。 2009 年，在研究FORTIFY_SOURCE 在內核中的實際覆蓋範圍時，我將Arjan 的工作擴展到對更多函數執行檢查，並增加了它對一些[k|v]malloc 對像大小的編譯時知識，發現它只檢測了約30% 的涵蓋API 實例，不過從安全角度來看，是不太可能出現被攻擊的。

這些str* 和mem* API 的覆蓋範圍是在2017 年7 月為4.13 內核提交“include/linux/string.h: add the option of fortified string.h functions”，但沒有提及早期的工作，或者任何使用一些動態分配對像大小的改進知識，將其有效覆蓋率降低到我最初調查的30% 以下。

2009 年Arjan van de Ven 通過提交“x86: Use __builtin_object_size() to validate the buffer size for copy_from_user()”為x86 頂層添加了用於copy__*_user 的__builtin_object_size()。這個Linux 2.6.34的初始版本只覆蓋了copy_from_user，僅從2013 年10 月開始涵蓋copy_to_user，其中Jan Beulich 為Linux 3.13 提交了'x86: Unify copy_to_user() and add size checking to it'。它看到了許多重構，最終通過Al Viro 在2017 年3 月為4.12 版本的Linux 提交'generic .copy_._user primitives'產生了一個獨立於架構的變體。

正如我們之前提到的，__builtin_object_size() 是由編譯器提供的。 2013 年4 月，為了響應內核在某些GCC版本上現有使用內置函數產生的編譯時錯誤，Guenter Roeck 合併了“gcc4: disable __compiletime_object_size for GCC 4.6+”，使得整個練習對受影響的編譯器毫無用處版本（當時，最新發布的GCC 版本是4.8.0）。

“我想指出，儘管__compiletime_object_size() 在4.6 之前被限制為gcc，但整個構造將變得越來越沒有意義。 然而，我會質疑commit 2fb0815c9ee6b9ac50e15dd8360ec76d9fa46a2 ('gcc4: disable__compiletime_object_size for GCC 4.6+') 確實是必要的，相反，這應該像從一開始就在這裡做的那樣處理。”

然而，直到2016年8月Josh Poimboeuf的Linux 4.8 commit:“mm/usercopy: get rid of CONFIG_DEBUG_STRICT_USER_COPY_CHECKS”，對GCC=4.1和4.6使用__builtin_object_size()的限制被更改為GCC=4.1。在這次提交時，GCC 6.2是最新的編譯器版本。 Josh的提交也消除了啟用調試選項以獲得功能的需要。

綜上所述，在大約三年的時間裡，除了少數內核開發人員對內核進行檢查之外，用戶都沒有進行過有關操作。還應該注意的是，放寬對__builtin_object_size() 版本限制的4.8 提交從未向後移植到早期的內核，這意味著即使對於今天最新的4.4 XLTS 版本，任何涉及此的檢查對於幾乎任何現代用戶都是完全無實操可能性的。

你可能想知道，Clang在構建Linux時是如何發揮作用的，儘管谷歌在2018 年底開始使用Clang 構建內核的4.4 內核。 Clang 歷史上（甚至在最新版本中）偽造了4.2.1 的GCC 版本，因此不受這些更改的影響。

WARN_ON_ONCE 的歷史（bytes INT_MAX）這種檢查最早是Linus Torvalds 本人在2005 年2 月對2.6.11 內核通過BUG_ON() 對i386 進行的檢查。由於Andi Kleen 的提交“[PATCH] i386: Remove copy_*_user BUG_ONs for (size 0)”，兩年多後，這些檢查在2.6.22版本的內核中被刪除，並錯誤地解釋為“access_ok檢查這種情況，不需要檢查兩次”。這種解釋是錯誤的，因為雖然access_ok()確實有效地檢查了相同的情況，但BUG_ON()避免了後續memset()的執行，此後memset()就可以執行了。

在grsecurity 中，2.6.29 版本的Linux 在2009 年8 月時在Linux 支持的幾乎所有架構中安全地實施了此檢查，沒有BUG_ON()。重要的是，此檢查是在access_ok() 之前執行的，並且在copy_from_user() 的情況下避免了稍後將討論的易受攻擊的memset()。

在頂層，這項檢查是由Kees Cook 在2019 年12 月針對Linux 5.5通過“uaccess: disallow INT_MAX copy sizes”引入的。由於只有2 行更改，因此一個月後它被反向移植到Linux 5.4。然而，由於copy_*_user API 在前幾年經歷了相當大的變動，這個簡單的改變並沒有被進一步的反向移植，因此在上游的4.4、4.9、4.14或4.19 XLTS內核中也沒有出現，而這些內核現在仍然支持XLTS。

copy_from_user memset 的歷史在x86 上，至少可以追溯到2002 年之前，只有在access_ok() 成功時才對失敗的copy_from_user 進行歸零。例如當copy_from_user的大小不是編譯時常量時調用__generic_copy_from_user 的實現。後來，情況發生了變化，從Linux 2.4.3.4 的這個提交開始，從隨後的2.4.35版本的這個改變開始，該版本在access_ok()失敗時添加了歸零設置。

Andrew Morton在2003年6月發布了一個x86補丁，提到了在access_ok()失敗的情況下重新放置memset()。

最有趣的是，早在2002年的Linux 2.4.4.4中，ARM就有以下變化：

6.png

目前尚不清楚該評論是指它緩解了前面描述的安全漏洞還是引入了一個漏洞，該漏洞可能由攻擊者控制長度的緩衝區歸零，然而，這一改變確實帶來了一個潛在漏洞。考慮到由於計算中的一些溢出而導致n=-1 的情況：access_ok() 在32 位ARM 上將失敗，因為n 表示為添加到任何用戶空間的無符號值地址將涵蓋包括內核空間在內的範圍。 else 情況將被觸發，導致長度為0xffffffff 的memzero()，肯定會導致系統無法恢復的DoS。

目前該問題仍然存在於頂層中。

由於2019年添加的禁止INT_MAX副本大小的頂層檢查是在check_copy_size()中實現的，因此它失敗了，避免了對_copy_from_user()的調用，這將執行錯誤的memset()，與十年前的grsecurity更改相同。然而，由於未知的原因，在提交消息或它所引用的郵件列表討論中，根本沒有提到修復這個漏洞。

如上所述，由於頂層的更改未向後移植到4.4、4.9、4.14 或4.19版本種，因此可以將負長度傳遞給copy_from_user() 的內核版本中存在的錯誤可能會導致大量內存損壞並保證系統DoS。如果有人接受某些人提出的緩解建議並啟用panic_on_warn，2019年進行的頂層更改也會通過恐慌導致DoS。

HireHackking

最近在Linux 內核TEE 子系統中發現了一個釋放後重引用（UAF）漏洞，影響版本小於等於5.15.11，分配了CVE編號CVE-2021-44733。

簡單的UAF無法進一步利用，在對漏洞代碼路徑做了進一步分析，簡單寫了個PoC測試後發現是可以覆蓋Linux內核中的函數指針的，本文沒有提供權限提升的漏洞利用代碼，但是在環境設置部分提供了運行OPTTE和漏洞利用的測試環境。

0x01 背景信息TEE是Trusted Execution Environment,也就是可信執行環境，通常用於數字版權保護（Digital Rights Management）、移動支付保護、敏感數據保護。 TEE的實現是基於ARM TrustZone。

需要介紹的另一個概念是REE，也就是Rich Execution Environment，被稱為通用執行環境，這是所有移動設備的通用運行環境，運行Android、iOS 系統。 OS的代碼量龐雜很容易出現漏洞，OS可以讀寫APP軟件中的所有數據，存在大量針對REE的高級攻擊技術和漏洞利用代碼。

TEE受硬件機制的保護，TEE隔離於REE，只能通過特定入口和TEE進行通信；TEE可以訪問REE的內存，可以抵禦某些硬件攻擊。

TEE實質上是一個可信子操作系統，比如最常見的ARM CPU上的TrustZone，運行在CPU芯片中的子OS，TEE驅動程序會處理TEE OS和上層操作之間的通信。

TEE 子系統會對TEE驅動程序進行註冊初始化、會管理Linux 和TEE的共享內存、會為TEE提供通用API。

驅動程序註冊初始化步驟：

1.根據設備類型，構造所需描述驅動的結構體。該結構體需要繼承structdevice_driver結構，並給幾個重要的成員初始化。

2.通過module_init宏調用驅動程序的初始化函數xx_init_module，在初始化函數中註冊驅動程序。

3.驅動程序會遍歷總線上的structdevice和structdevice_driver兩條鍊錶，調用總線的match函數，對設備與驅動程序進行匹配。

4.如果設備與驅動程序匹配成功，則調用驅動程序的probe函數。

什麼是註冊驅動程序：

初始化函數中調用的xx_register_driver函數就是註冊驅動程序，初始化函數執行其實非常簡單，執行一下xx_register_driver函數就會返回，這也是Linux驅動程序的標準註冊流程：module_init--xx_init_module--xx_register_driver。 TEE接口include/uapi/linux/tee.h中的結構體和宏定義提供了TEE的通用使用接口，用戶空間和客戶端可通過打開/dev/tee[0-9] 或/dev/teepriv[0-9] 連接TEE驅動程序。

下面是在include/uapi/linux/tee.h中定義的結構體接口：

TEE_IOC_SHM_ALLOC 分配共享內存並返回用戶空間可以映射的文件描述符。當用戶空間不再需要文件描述符時，它應該被關閉。當不再需要共享內存時，應該使用munmap() 取消映射以允許重用內存。

TEE_IOC_VERSION 讓用戶空間知道此驅動程序處理哪個TEE 及其功能。

TEE_IOC_OPEN_SESSION 打開一個到可信應用程序的新會話。

TEE_IOC_INVOKE 調用可信應用程序中的函數。

TEE_IOC_CANCEL 可以取消正在進行的TEE_IOC_OPEN_SESSION 或TEE_IOC_INVOKE。

TEE_IOC_CLOSE_SESSION 關閉與可信應用程序的會話。

mmap會將一個文件和其他對象映射到內存空間中。文件被映射到多個頁上，如果文件的大小不是所有頁的大小之和，最後一個頁不被使用的空間將會清零。 munmap執行相反的操作，刪除特定地址區域的對象映射。 TEE有兩種客戶端：普通客戶端和請求者客戶端，請求者客戶端是TEE在Linux OS中的輔助進程，用於訪問資源，比如文件系統訪問等。普通客戶端會打開/dev/tee[0-9]*，請求者kehu客戶端會打開/dev/teepriv[0-9]。

/dev/目錄下是Linux的外部設備文件，注意不是驅動文件，Linux會將所有設備認為是文件。客戶端和TEE 之間的大部分通信對驅動程序來說是不透明的。驅動程序的主要工作是接收來自客戶端的請求，將它們轉發到TEE 並將結果發回。在請求方的情況下，通信在另一個方向進行，TEE 向請求方發送請求，然後請求方將結果發回。

TEE是在安全環境中運行的可信操作系統，例如ARM CPU 上的TrustZone。 TEE 驅動程序會處理與TEE 通信所需的細節，驅動程序更重要的職責是為基於Globalplatform TEE 客戶端API 規範的TEE 提供通用API，而且還管理Linux 和TEE 之間的共享內存。該子系統可以通過CONFIG_OPTEE在ARM 架構的內核配置中進行配置來啟用。

The secure world包含表示為OP-TEE OS 的可信操作系統。在此操作系統之上，可以運行受信任應用程序(TA)，這些應用程序可以在隔離環境中執行某些操作，參見圖1。

image-20220117152205863.png

圖1：TEE 概述

The normal world 包括Linux 用戶空間和內核空間，可以使用客戶端應用程序(CA) 和TEE 子系統公開的API 與這些應用程序交互。 CA 可以向特定TA 打開會話並調用TA 實現的功能。在TA 和CA 之間來回傳遞任何參數都是使用共享內存完成的。接下來描述使用所有相關係統調用的CA 和TA 之間的交互。

1、CA 打開/dev/tee[0-9]以與驅動程序通信。對於使用這些API 的傳統方式，這是使用libteec 隱式完成的。

2、CA 可以使用IOCTL TEE_IOC_SHM_ALLOC。這將分配共享內存並返回一個文件描述符，用戶空間可以將其用作mmap 的一部分。

3、下一步是使用IOCTL TEE_IOC_OPEN_SESSION和指定特定TA 的uuid建立會話。這個uuid 在TA 的編譯過程中是硬編碼的。

4、為了調用TA 中的特定函數，CA 通過指定函數的標識符以及輸入參數來調用該函數，這裡使用的是TEE_IOC_INVOKE。

5、當CA 完成所有請求後，可以使用TEE_IOC_CLOSE_SESSION關閉會話。

image.png

圖2：CA 和TA 之間的會話

客戶端和TEE 之間的大部分通信對驅動程序來說是不透明的。驅動程序的主要工作是管理上下文、接收來自客戶端的請求、將它們轉發到TEE 並將結果發回。

0x02 對TEE 驅動器的模糊測試CVE-2021-44733 是使用syzkaller 模糊測試發現的，下面提供了相關的描述文件。 ioctl$TEE_SHM_REGISTER_FD只是Linaro內核樹的一部分，根據syzkaller 文檔正確配置後，“Setting up the environment”中提供的環境就可以用於模糊測試了。

#include

resourcefd_tee0[fd]

resourcesession_resource[int32]

openat$tee0(fdconst[AT_FDCWD],devptr[in,string['/dev/tee0']],flagsflags[open_flags],modeflags[open_mode])fd_tee0

ioctl$TEE_OPEN_SESSION(fdfd_tee0,cmdconst[0x8010a402],argptr[inout,tee_ioctl_buf_data_session])

ioctl$TEE_INVOKE(fdfd_tee0,cmdconst[0x8010a403],argptr[inout,tee_ioctl_buf_data_invoke])

ioctl$TEE_CANCEL(fdfd_tee0,cmdconst[0x8008a404],argptr[in,tee_ioctl_buf_data_cancel])

ioctl$TEE_CLOSE_SESSION(fdfd_tee0,cmdconst[0x8004a405],argptr[in,tee_ioctl_buf_data_close])

ioctl$TEE_VERSION(fdfd_tee0,cmdconst[0x800ca400],argptr[out,tee_ioctl_buf_data_version])

ioctl$TEE_SHM_ALLOC(fdfd_tee0,cmdconst[0xc010a401],argptr[inout,tee_ioctl_buf_data_shm_alloc])

ioctl$TEE_SHM_REGISTER(fdfd_tee0,cmdconst[0xc018a409],argptr[inout,tee_ioctl_buf_data_shm_register])

ioctl$TEE_SHM_REGISTER_FD(fdfd_tee0,cmdconst[0xc018a408],argptr[inout,tee_ioctl_buf_data_shm_register_fd])

ioctl$TEE_SUPPL_RECV(fdfd_tee0,cmdconst[0x8010a406],argptr[inout,tee_ioctl_buf_suppl_recv])

ioctl$TEE_SUPPL_SEND(fdfd_tee0,cmdconst[0x8010a407],argptr[inout,tee_ioctl_buf_suppl_send])

#COMMON

#=======================================================

defineTEE_IOCTL_UUID_LEN16

tee_ioctl_param_struct{

attrflags[TEE_IOCTL_PARAM_ATTR_TYPE,int64]

aint64

bint64

cint64

}

TEE_IOCTL_PARAM_ATTR_TYPE=0,1,2,3,5,6,7

TEE_LOGIN=0,1,2,4,5,6

#OPENSESSION

#=======================================================

tee_ioctl_buf_data_session{

buf_ptrptr64[inout,tee_ioctl_open_session_struct]

buf_lenlen[buf_ptr,int64]

}

tee_ioctl_open_session_struct{

uuidarray[int8,TEE_IOCTL_UUID_LEN](in)

clnt_uuidarray[int8,TEE_IOCTL_UUID_LEN](in)

clnt_loginflags[TEE_LOGIN,int32](in)

cancel_idint32(in)

sessionsession_resource(out)

retint32(out)

ret_originint32(out)

num_paramslen[params,int32](in)

paramsarray[tee_ioctl_param_struct](in)

}

#INVOKE

#=======================================================

tee_ioctl_buf_data_invoke{

buf_ptrptr64[inout,tee_ioctl_invoke_struct]

buf_lenlen[buf_ptr,int64]

}

tee_ioctl_invoke_struct{

funcint32(in)

sessionsession_resource(in)

cancel_idint32(in)

retint32(out)

ret_originint32(out)

num_paramslen[params,int32](in)

paramsarray[tee_ioctl_param_struct](in)

}

#CANCELSESSION

#=======================================================

tee_ioctl_buf_data_cancel{

cancel_idint32(in)

sessionsession_resource(in)

}

#CLOSESESSION

#=======================================================

tee_ioctl_buf_data_close{

sessionsession_resource(in)

}

#VERSION

#=======================================================

tee_ioctl_buf_data_version{

impl_idint32(out)

impl_capsint32(out)

gen_capsint32(out)

}

#SHMALLOC

#=======================================================

tee_ioctl_buf_data_shm_alloc{

sizeint64(inout)

flagsconst[0,int32](inout)

idint32(out)

}

#SHMREGISTER

#=======================================================

tee_ioctl_buf_data_shm_register{

addrint64(in)

lengthint64(inout)

flagsconst[0,int32](inout)

idint32(out)

}

#SHMREGISTERFD

#=======================================================

tee_ioctl_buf_data_shm_register_fd{

fdint64(in)

sizeint64(out)

flagsconst[0,int32](in)

idint32(out)

}[align[8]]

#SUPPLICANTRECV

#=======================================================

tee_ioctl_buf_suppl_recv{

funcint32(in)

num_paramslen[params,int32](inout)

paramsarray[tee_ioctl_param_struct](inout)

}

#SUPPLICANTSEND

#=======================================================

tee_ioctl_buf_suppl_send{

retint32(out)

num_paramslen[params,int32](in)

paramsarray[tee_ioctl_param_struct](in)

}模糊測試中的崩潰是由於持有互斥對象時task _ struct 的use-after-free 漏洞：

==================================================================

BUG:KASAN:use-after-freein__mutex_lock.constprop.0+0x118c/0x11c4

Readofsize4ataddr863b0714bytaskoptee_example_r/244

CPU:0PID:244Comm:optee_example_rTainted:GD5.14.0#151

Hardwarename:GenericDTbasedsystem

[](unwind_backtrace)from[](show_stack+0x20/0x24)

[](show_stack)from[](dump_stack_lvl+0x5c/0x68)

[](dump_stack_lvl)from[](print_address_description.constprop.0+0x38/0x304)

[](print_address_description.constprop.0)from[](kasan_report+0x1c0/0x1dc)

[](kasan_report)from[](__mutex_lock.constprop.0+0x118c/0x11c4)

[](__mutex_lock.constprop.0)from[](mutex_lock+0x128/0x13c)

[](mutex_lock)from[](tee_shm_release+0x4b0/0x6cc)

[](tee_shm_release)from[](dma_buf_release+0x1b8/0x2f0)

[](dma_buf_release)from[](__dentry_kill+0x4c4/0x678)

[](__dentry_kill)from[](dput+0x630/0xba4)

[](dput)from[](__fput+0x3b4/0x900)

[](__fput)from[](task_work_run+0x15c/0x230)

[](task_work_run)from[](do_exit+0x103c/0x3770)

[](do_exit)from[](do_group_exit+0x134/0x3ac)

[](do_group_exit)from[](get_signal+0x7d8/0x2f28)

[](get_signal)from[](do_work_pending+0x984/0x154c)

[](do_work_pending)from[](slow_work_pending+0xc/0x20)

Exceptionstack(0x85743fb0to0x85743ff8)

3fa0:00023108000000800000000000000000

3fc0:66bca2d066bca2d066bca2d0000000f066bca2d066bca340000000006ec00b0c

3fe0:66bc9cc866bc9cb80001165566c80c20000e013000023108

Allocatedbytask242:

set_alloc_info+0x48/0x50

__kasan_slab_alloc+0x48/0x58

kmem_cache_alloc+0x14c/0x314

copy_process+0x2014/0x7b18

kernel_clone+0x244/0xfc8

sys_clone+0xc8/0xec

ret_fast_syscall+0x0/0x58

0x6ec00a10

Freedbytask67:

kasan_set_track+0x28/0x30

kasan_set_free_info+0x20

HireHackking

針對香港iOS用戶進行水坑攻擊的LightSpy惡意軟件，近日被發現嵌入在來自20台活躍服務器的安卓植入體Core（核心）及其14個相關插件當中，用於攻擊移動用戶。

LightSpy是一種移動高級持續性威脅（mAPT），它使用新穎的複雜技術來攻擊移動用戶。其中，這個惡意軟件已被證實出自黑客組織APT41之手。

最近的報告表明，該惡意軟件一直在使用微信支付系統訪問支付數據、監控私密通信，並執行各種惡意活動。

LightSpy APT攻擊微信用戶據多起報告顯示，LightSpy惡意軟件是一套功能齊全的模塊化監視工具集，被發現使用各種插件來洩露並竊取私密數據和支付數據。此外，該惡意軟件強烈關注受害者的私密信息。

其功能包括：利用後端基礎設施從微信支付中洩露支付數據，並從微信獲取音頻相關功能，以記錄受害者的VOIP對話內容。

然而，該惡意軟件不能作為一個獨立的應用程序來運行，因為它也是一個插件，該惡意軟件的核心負責執行整條攻擊鏈所需的所有功能。

核心功能包括設備指紋收集、控制服務器連接建立、從服務器檢索命令以及更新自身和額外的攻擊載荷文件（又叫作插件）。

LightSpy的14個插件該惡意軟件已添加了多個插件，包括soft list（軟列表）、baseinfo（基礎信息）、bill（賬單）、cameramodule（攝像頭模塊）、chatfile（聊天文件）、filemanager（文件管理器）、locationmodule（位置模塊）、locationBaidu（位置百度）、qq、shell、soundrecord（錄音）、telegram、wechat（微信）和wifi。

12112.jpg

信息來源： ThreatFabric

正如報告中提到，最重要的插件之一是位置模塊插件，它負責位置跟踪，可以發送當前位置的快照，也可以設置指定時間間隔的位置跟踪。這個插件基於兩個位置跟踪框架：騰訊位置SDK和百度位置SDK。

另一個重要的插件是Soundrecord（錄音）插件，它負責錄製音頻。這個插件還可以立即或在指定的時間間隔開始麥克風錄音。此外，這個插件還可以記錄來電通話內容。

Bill（賬單）插件是另一個重要的插件，它負責從微信支付收集受害者的支付歷史信息，這包括上一筆賬單的ID、賬單類型、交易ID、日期以及已支付處理的標誌。

22222.jpg

iOS命令和安卓命令之間的關係（來源：ThreatFabric）

基礎設施LightSpy基礎設施包含幾十個服務器，分佈在中國大陸、中國香港、中國台灣、新加坡和俄羅斯，由於一些服務器返回不同的命令和載荷，可以推測攻擊者為每次活動使用不同的IP地址或域。與此同時，由於一些服務器返回載荷（應該是在2018年編譯的），可以假設攻擊者可以在幾個攻擊活動中重複使用同一套基礎設施。另一個關於長壽命服務器的假設是，安全行業人士常常不會發現/披露這些服務器，因此不需要更改IP地址。

在分析LightSpy基礎設施時，我們發現了兩個值得注意的時刻：

LightSpy與AndroidControl（WyrmSpy）的聯繫

我們獲取了硬編碼到核心中的IP地址，與Lookout報告中披露的IP地址是同一個。

1.png

圖1

結果是35900端口已關閉，主機沒有響應LightSpy請求。同時，有幾個開放的端口提供https服務。

端口11090對應的https服務器使用過期證書加以保護，SHA256指紋為f0fc2c418e012e034a170964c0d68fee2c0efe424a90b0f4c4cd5e13d1e36824，還有另外兩台主機使用相同的服務和相同的證書。兩台主機都打開了端口443，服務於一個名為AndroidControl v1.0.4的管理面板。

2.png

圖2

有第三台主機具有相同的收藏夾圖標（MD5散列542974b44d9c9797bcbc9d9218d9aee5），它託管相同的面板。這個主機上的面板錯誤配置，暴露了應該用於前後端之間通信的後端端點：

3.png

圖3

第一個值得關注的點是“控制”端點，這種端點位於Lookout報告的WyrmSpy樣本中。

為了確認這三個主機與WyrmSpy有關，我們做了一個簡單的請求雙“控制”端點，看到了相同的結果：

4.png

圖4

在WyrmSpy的代碼中，我們可以看到它等待對含有字段“suc”的請求進行響應：

5.png

圖5

因此，這三個主機都是WyrmSpy的活躍C2，或者正如攻擊者所命名的AndroidControl或androidRat。

由於面板在處於調試模式的Django中，它暴露了一些內部信息，比如一個內部文件夾（整個前端和後端文件存儲在服務器中），以及另一個IP地址47.115.7[.]112：

6.png

圖6

LightSpy面板其中一台C2服務53601端口，該服務含有Admin面板：

7.png

圖7

面板在VUEJS中，除了面板結構外，我們在底層沒有發現任何值得注意的痕跡。 VUEJS節點的功能仍然不清楚。

8.png

圖8

一篇關於LightSpy的完整報告已經由ThreatFabric發布（詳見https://www.threatfabric.com/blogs/lightspy-mapt-mobile-payment-system-attack），提供了有關威脅途徑、源代碼、分析及其他信息的詳細信息。

攻陷指標控制服務器：域

spaceskd[.]com

IP

103.27.108[.]207

46.17.43[.]74

文件哈希：第二階段載荷（smallmload .jar）

SHA256

407abddf78d0b802dd0b8e733aee3eb2a51f7ae116ae9428d554313f12108a4c

bd6ec04d41a5da66d23533e586c939eece483e9b105bd378053e6073df50ba99

核心SHA256

版本

68252b005bbd70e30f3bb4ca816ed09b87778b5ba1207de0abe41c24ce644541

6.5.24

5f93a19988cd87775ad0822a35da98d1abcc36142fd63f140d488b30045bdc00

6.5.24

bdcc5fc529e12ecb465088b0a975bd3a97c29791b4e55ee3023fa4f6db1669dc

6.5.25

9da5c381c28e0b2c0c0ff9a6ffcd9208f060537c3b6c1a086abe2903e85f6fdd

6.2.1

a01896bf0c39189bdb24f64a50a9c608039a50b068a41ebf2d49868cc709cdd3

6.5.19

77f0fc4271b1b9a42cd6949d3a6060d912b6b53266e9af96581a2e78d7beb87b

6.2.0

d640ad3e0a224536e58d771fe907a37be1a90ad26bf0dc77d7df86d7a6f7ca0e

6.2.1

3849adc161d699edaca161d5b6335dfb7e5005056679907618d5e74b9f78792f

6.2.6

2282c6caef2dd5accc1166615684ef2345cf7615fe27bea97944445ac48d5ce4

5.2.1

插件插件名稱

SHA256

softlist

7d17cdc012f3c2067330fb200811a7a300359c2ad89cdcf1092491fbf5a5a112

baseinfo

cc6a95d3e01312ca57304dc8cd966d461ef3195aab30c325bee8e5b39b78ae89

bill

c6ccd599c6122b894839e12d080062de0fa59c4cd854b255e088d22e11433ef6

cameramodule

bace120bf24d8c6cfbb2c8bfeed1365112297740e2a71a02ea2877f5ffc6b325

chatfile

7d8a08af719f87425d1643d59979d4a3ef86a5fc81d1f06cfa2fd8c18aeb766b

filemanager

e5bdeedac2c5a3e53c1fdc07d652c5d7c9b346bcf86fc7184c88603ff2180546

locationmodule

bf338e548c26f3001f8ad2739e2978586f757777f902e5c4ab471467fd6d1c04

locationBaidu

177e52c37a4ff83cd2e5a24ff87870b3e82911436a33290135f49356b8ee0eb1

qq

f32fa0db00388ce4fed4e829b17e0b06ae63dc0d0fac3f457b0f4915608ac3b5

shell

e1152fe2c3f4573f9b27ca6da4c72ee84029b437747ef3091faa5a4a4b9296be

soundrecord

c0c7b902a30e5a3a788f3ba85217250735aaaf125a152a32ee603469e2dfb39e

telegram

71d676480ec51c7e09d9c0f2accb1bdce34e16e929625c2c8a0483b9629a1486

wechat

bcb31d308ba9d6a8dbaf8b538cee4085d3ef37c5cb19bf7e7bed3728cb132ec1

wifi

446506fa7f7dc66568af4ab03e273ff25ee1dc59d0440086c1075d030fe72b11

HireHackking

Vishing即語音釣魚，是網路釣魚(Phishing)的電話版本。黑客們利用語音釣魚的方式,在短短的幾分鐘內就可清空人們的賬戶。近年來，隨著Vishing的興起，人們便不再信任未知號碼呼叫。

比如，接到冒充銀行員工的聯繫人打來的電話是非常令人討厭的，最近研究人員遇到了一組以前從未見過的惡意應用程序，開發者將其稱為“Letscall”，目前針對的是來自韓國的個人用戶。從技術上講，沒有任何規定禁止他們將攻擊範圍擴大到歐盟國家。換句話說，我們正在處理一個隨時可用的框架，任何攻擊者都可以使用它，因為它包含了關於如何操作受影響設備以及如何與受害者溝通的所有說明和工具。

該組織可能包括：熟悉現代VOIP流量路由概念的Android開發人員，我們稱其為“開發人員”，因為我們在其中一個階段觀察到命令命名的差異。

設計人員負責網頁、圖標以及管理面板、網絡釣魚網頁和移動惡意應用程序的內容。

前端開發人員熟悉JavaScript開發，包括VOIP流量處理。

後端開發人員熟悉保護後端API免受未經授權訪問的技術。

呼叫具有語音社會工程攻擊技能的接線員，他們可以流利地說不同的語言。

攻擊分為三個階段：受害者訪問一個特別製作的釣魚網頁，看起來像Google Play Store。受害者從該頁面下載惡意應用程序鏈的第一階段。

第一階段（我們稱之為下載程序）在設備上運行準備工作，獲得必要的權限，打開釣魚網頁，並安裝第二階段惡意軟件，該惡意軟件將從控制服務器下載。

第二階段是一個強大的間諜軟件應用程序，它將幫助攻擊者竊取數據，並將受攻擊的設備註冊到P2P VOIP網絡中，該網絡用於通過視頻或語音通話與受害者通信。此應用程序還會釋放第三個階段，即鏈的下一個部分。

letcall使用WEBRTC技術來路由VOIP流量，並將受害者與呼叫中心操作員連接起來。為了達到最大的電話或視頻通話質量，並克服NAT和防火牆，Letscall使用STUN/TURN方法，包括Google STUN服務器。

第三階段是第二階段惡意軟件的配套應用程序，並擴展了一些功能，它包含電話呼叫功能，用於將呼叫從受害者設備重定向到攻擊者呼叫中心。

1.png

Vishing技術迭代過程

這種釣魚攻擊已經發展得非常先進和復雜了，因為欺詐者現在使用現代技術進行語音通信路由和自動呼叫受害者的系統（所謂的自動竊取者，用於通過電話自動廣告），並播放預先錄製的誘惑信息。如果受害者上鉤了，接線員就會接起電話，引導受害者按照騙子的要求行事。攻擊者可能會欺騙受害者到最近的自動取款機取現金，或者迫使受害者披露個人信息，如銀行賬戶數據、信用卡詳細信息或銀行憑證。

在過去的幾年裡，這種攻擊已經成為一種明顯的趨勢，沒有證據表明欺詐者會放棄該方法。

如今，受害者和安全行業都在發展，並通過各種防禦機制對抗這種攻擊。使用呼叫者識別應用程序或了解欺詐者策略可能足以抵禦攻擊者。

這可能是欺詐者試圖利用他們所掌握的任何類型的信息，而不僅僅是使用姓名和電話號碼來獲得受害者信任的原因之一。為了獲得更高級別的信任，攻擊者通過訪問受害者設備對受害者進行偵察。

將這兩種類型的攻擊(手機攻擊和Vishing)結合起來，欺詐者可以“一舉兩得”：我們觀察到的一種常見攻擊類型包括在請求受害者小額貸款。如果受害者註意到一些不尋常的活動，攻擊者將打電話給受害者，冒充銀行安全小組的成員，並向受害者保證沒有什麼可擔心的。

在完全控制受攻擊設備的情況下，攻擊者還會將任何呼叫重新路由到由攻擊者管理的另一個呼叫中心。如果受害者決定聯繫銀行並詢問與可疑活動有關的問題，準備充分的接線員將接聽電話。使用這種作案手法，攻擊者還可能要求受害者提供更多細節，以幫助他們進行犯罪活動並完成資金轉移。

這種攻擊是非常危險的，因為受害者必須償還貸款，金融機構可能不會關心這種攻擊和設備攻擊，從而降低了調查潛在欺詐攻擊的可能性。這就是為什麼這樣的攻擊應該被業界披露和報告的原因。

對於“letcall”惡意軟件的所有三個階段，攻擊者都使用了強大的逃避檢測技術。一些版本的下載程序使用騰訊Legu模糊處理或Bangcle（SecShell）進行了保護。對於第二和第三階段，使用了ZIP文件目錄樹中的長名稱和清單攻擊技術。 Checkpoint最近也報導了同樣的技術。然而，從代碼和基礎設施的角度來看，這些活動是不同的。攻擊者有可能彼此分享知識，或者受到同一地區其他攻擊者的影響。

“Letscall”第二和第三階段規模巨大，我們的研究仍在進行中。然而，我們現在想提供一些見解。

下載程序目前還不知道攻擊者如何說服受害者訪問可以找到下載程序的誘餌網頁，這可能是一種黑化的SEO技術或使用垃圾郵件的社會工程。到目前為止，我們知道這些頁面模仿了Google Playstore，並針對移動屏幕分辨率進行了優化。這裡一個值得注意的細節是頁面的語言為韓語。

2.png

從技術角度來看，使用的下載程序是相對簡單的應用程序，有時使用我們稍後將描述的自定義技術。下載程序的目標是做兩件事：下載並運行第二階段應用程序。有效負載的URL地址被硬編碼到應用程序中。

3.webp.jpg

打開帶有網絡釣魚窗口的web視圖，該窗口也硬編碼到應用程序中。

這些頁面會因正在進行的傳播活動而有所不同，研究人員發現至少有3個頁面模仿了Banksala（貸款比較聚合器）、Finda（貸款對比聚合器）和KICS（韓國刑事司法服務信息系統）。

4.png

每個頁面都會誘使受害者輸入敏感信息，如居民註冊號（身份證）、電話號碼、家庭地址、工資大小和雇主姓名。該輸入數據將自動發送給攻擊者。同樣的數據也被輸入到貸款聚合器的原始網頁中。我們可以非常肯定地說，攻擊者要么會使用竊取的數據在合法網站上填寫類似的表格來申請貸款，要么也可能是網絡釣魚頁面在受害者和貸款聚合頁面之間充當代理：

5.png

第二階段乍一看，這個應用程序顯然是非常模糊的，要分析它的功能需要很長時間。讓我們來看看其中的每一種技術：

1.APK文件中包含長路徑名。一些分析系統將無法處理提取此類APK文件的內容。

6.webp.jpg

2.XML文件攻擊。

3.代碼打包：核心DEX文件不包含清單中列出的代碼。然而，它包含模糊代碼，這些代碼將從APK收集文件，對其進行解密並加載。這些文件位於APK文件的根目錄中，它們的名稱以“o”開頭，以“bf”結尾，即“obf”或模糊處理：

7.webp.jpg

所有的文件都有相似的標題和相對較低的熵。

8.png

甚至還隱藏了一些字符串：

9.webp.jpg

經過一些修改之後，很明顯，這幾十個文件都是DEX文件，只是在它們的標頭文件中做了微小的修改。通過觀察文件第一個字節中重複的0x1f值，我們可以猜測，為了隱藏原始標頭，使用了一個字節的異或加密，並且只加密了文件的0x64字節。

我們重建了APK文件並分析了代碼。在第一步分析之後，我們意識到我們面臨著一些重大問題。

10.webp.jpg

由此產生的APK文件基於十幾個不同的框架，包括okhttp3和butterknife等流行的框架，以及我們第一次觀察到的一些庫。

最有趣的庫是im/zego。

第二階段濫用合法服務ZEGOCLOUD作為IP語音通信和消息傳遞的提供商。為了處理這種依賴於WEB RTC的通信，攻擊者使用中繼服務器。特別使用的公開可用的STUN/TURN服務器，包括來自Google的服務器，以及自配置的服務器。在此過程中，他們還竊取了應用程序代碼中的憑據。

11.png

需要這樣的功能來執行呼叫中心運營商和受害者之間的P2P語音/視頻連接，並且相同的信道也用於具有許多不同命令的C2通信。此外，該惡意軟件還支持使用網絡套接字進行通信。來自P2P服務和web套接字通信的命令有時會相互重複，共涉及32個命令。

為了過濾數據並更改配置，惡意軟件使用傳統的http通信：

13.webp.jpg

攻擊者還可以對需要重定向的電話號碼配置白名單，對需要繞過重定向的電話號碼配置黑名單。

我們注意到的另一件有趣的事情是nanoHTTPD的使用，這個應用程序創建一個本地http服務器，然後打開Chrome瀏覽器進行訪問。

14.webp.jpg

通過濫用可訪問性服務，它將把必要的界面元素推入Chrome，並將第三階段的惡意軟件傳遞給受害者。這種更複雜的方法被用來以更有效的方式欺騙受害者。

第三階段從技術角度來看，安裝的下一個APK文件看起來與第二階段APK非常相似，使用了相同的逃避檢測技術，並且相同的xor加密DEX文件位於APK文件的根文件夾中。此應用程序還包含一個大型代碼庫：

15.webp.jpg

第三階段最有趣的部分是名為“phonecallapp”的包，該包包含負責電話操縱攻擊的代碼，它將攔截傳入和傳出的呼叫，並根據攻擊者的願望重新路由。

為了配置處理電話呼叫的方式，攻擊者使用具有以下結構的本地SQLite數據庫：

16.webp.jpg

在第三階段APK的資產中，已經準備好了MP3語音信息，如果有人試圖撥打銀行電話，就會播放給受害者。

17.webp.jpg

對於攻擊者來說，他們的目標顯然是模仿客戶給銀行打電話時的體驗。

第三階段有自己的一組命令，其中還包括Web套接字命令。

其中一些命令與地址簿的操作有關，例如創建和刪除聯繫人。其他命令涉及創建、修改和刪除過濾器，這些過濾器確定哪些調用應該被攔截，哪些應該被忽略。

基礎設施18.png

在我們獲得Downloader之後，我們開始分析C2服務器並分析了管理面板。

19.webp.jpg

與許多不同的WEB應用程序一樣，它由兩部分組成。

基於VueJS的前端，用於向攻擊者提供可視化內容；

基於Laravel PHP框架的後端，使用API與前端和惡意應用程序通信；

前端是最有趣的部分，因為它為管理員和電話接線員提供了一個功能齊全的工作帳戶。從這個面板中，電話接線員可以選擇受害者，並直接從瀏覽器開始視頻/音頻對話。運營商還可以看到從目標洩漏並上傳到基礎設施的完整詳細信息列表。它由至少33000個代碼字符串組成。

我們確定了操作員可以使用的至少19個與受攻擊設備控制相關的菜單：

20.webp.jpg

此JavaScript應用程序將使用與兩個階段的應用程序相同的VOIP基礎設施，這些服務器列在管理面板配置文件中：

21.webp.jpg

值得注意的是，前端應用程序包含所謂的教程和演示。 ThreatFabric能夠下載其中的兩個。在這些視頻中，我們可以觀察到完整的攻擊鏈以及它是如何在野外發生的。它們可能是為了方便電話接線員，從受害者的角度向他們展示攻擊過程，並使他們能夠回答受害者可能提出的問題。

22.png

在分析了前端面板之後，我們發現了後端的各種API。攻擊者將他們分為兩大類：

Admin—負責管理操作員對管理面板的訪問的API，

sys-user—負責從後端基礎設施檢索數據並控制受感染設備的API。

Admin面板代碼還顯示了一些圖片和音頻文件，音頻文件與我們在第三階段應用程序中看到的相同。

另一方面，圖片為我們提供了一些額外細節，例如可能支持四種語言：英語、韓語、日語和中文。

23.webp.jpg

一些圖片包含元信息，比如它們被創建的時間(2022-12-02 15：22)。此外，還提供了一個時區：+8。這個時區對應的是南亞國家，包括中國。

24.webp.jpg

我們還觀察了幾個韓國金融機構的名稱，這些名稱將在攻擊中被使用。

總結在分析了“letcall”惡意軟件活動後，研究人員確定這是一個熟悉Android安全和現代語音路由技術的網絡犯罪組織。該組織證明，技術上精心設計的社會工程攻擊仍然極其危險。該組織致力於使用虛假的Google Play頁面，竊取現有韓國應用程序的圖標，並結合使用nanoHTTPD的新技術來減少有效負載。

居民登記號碼(或身份證)盜竊可以為網絡攻擊者攻擊打開方便之門，我們看到，隨著政府、私人和公共機構越來越多地採用電子身份證解決方案，這種攻擊方式只會增加。重複使用其他攻擊者使用的相同逃避檢測技術在亞洲攻擊組織中很常見。

從網絡分析的角度來看，觀察另一種控制殭屍網絡並將流量隱藏在WEB RTC服務內部的方法是很有趣的。這突出了這樣一個事實，即無論使用的是私人服務器還是谷歌STUN服務器，此類流量都應該始終由保護系統進行分析。

關於“letcall”應用程序，我們討論了多功能間諜軟件，該軟件的設計密切關注與受害者的視頻和音頻連接，以及攔截短信和電話等通信。基於其代碼中包含的許多不同特性，letcall可以被歸類為RAT。 RAT允許攻擊者了解受害者的所有信息，並執行有效的社會工程攻擊。

最後，一些設計良好的基礎設施可能會被講不同語言的電話運營商使用。研究人員預測，這樣的工具包可以作為MaaS(惡意軟件即服務)在暗網上傳播。

為了保證安全，我們需要拒絕任何可疑應用程序的訪問。

HireHackking

1、概述Lazarus組織近期利用社交平台實施新型釣魚攻擊，通過社交平台誘導受害者使用被改造成木馬的開源軟件，從而獲取到受害主機的控制權限。觀成科技安全研究團隊發現該組織在某次攻擊活動中使用了被改造成木馬的開源軟件UltraVNC。 UltraVNC是一款開源的遠程管理工具，Lazarus組織在該工具中嵌入了惡意下載器。下載器會從CC服務器（互聯網失陷主機）獲取惡意DLL並在內存中加載，與服務器的CC通信全程使用HTTPS加密協議，加密載荷裡的通信交互數據本身又使用了自定義的加密方式進行二次加密。

2、通信過程表2-1 樣本信息表

image.png

該樣本類型為ISO，其中包含兩個文件：Amazon_Assessment.exe、ReadMe.txt。木馬化UltraVNC執行後，通過HTTPS加密協議上傳系統信息，從CC服務器下載並執行擴展DLL文件。

1.png

圖2-1 木馬化UltraVNC通信過程圖

2.1上線木馬化的UltraVNC獲取註冊表鍵值”\HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\System\BIOS\SystemManufacturer”，即受害主機的生產廠商信息和工作組名稱，用“|”符號連接後進行Base64編碼並附加在樣本中硬編碼的URL後面，形如：https://kaonnews.com/wp-admin/network/sitemap.php?2E9AE1F528B27A798D8BE424E4E7A4E6=。然後，URL使用單字節0x89進行異或加密，加密後的信息通過HTTPS加密協議發送給CC服務器。見圖2-1中的①。

2.png

圖2-2 上線包（HTTPS）

3.png

圖2-3 上線包（HTTPS解密後）

2.2解密釋放惡意DLL攻擊者通過社交平台誘導受害者使用木馬化的UltraVNC連接ReadMe.txt中記錄的IP 54.182.16.65後，見圖2-1中的②。 UltraVNC中攻擊者添加的代碼會計算該IP字符串的哈希值，將其作為密鑰，循環異或解密樣本中包含的惡意Dll文件，並在當前進程中加載運行。

2.3上傳系統信息惡意DLL獲取電腦名、系統磁盤信息、用戶名、當前進程ID等信息，生成隨機數作為通信校驗的key（也用於URI生成）。

4.png

圖2-4 DLL中硬編碼的通信URL

5.png

圖2-5 上傳信息數據（加密前）

DLL對數據進行ZIP壓縮+自定義加密+Base64編碼處理後使用HTTPS加密上傳到CC服務器，見圖2-1中的③。

6.png

圖2-6 上傳系統信息（HTTPS）

7.png

圖2-7 POST上傳系統信息（HTTPS解密後）

8.png

圖2-8 自定義加密算法

2.4URI生成DLL除上線包外使用的URI均隨機生成，URI參數數量為1到3個。 DLL首先生成第一個隨機數用來選擇不同的參數，參數列表如下圖所示，再生成第二個隨機數來決定參數的值，參數值可以是隨機字符串，也可以是參數字符串與通信檢驗的Key加法運算後的數據。

9.png

圖2-9 通信隨機選取的部分參數列表圖

2.5下發後續攻擊載荷該DLL在使用POST請求上傳系統信息後，每分鐘向目標URL發送無載荷GET請求，用來獲取下階段攻擊載荷。 CC服務器下發的數據也經過了ZIP壓縮+自定義加密+Base64編碼。該DLL接收到下發的數據後解密，解密後的數據包含URL（用來替換樣本通信的URL）以及擴展DLL文件，樣本會加載運行下載的擴展DLL，作為下階段攻擊載荷，見圖2-1中的④。

10.png

圖2-10 模擬服務器下發後續載荷格式圖

3、總結Lazarus組織在該款木馬化開源工具中硬編碼了多個常見的URL參數字段，發送心跳包時，使用隨機數來選擇參數、生成參數的值，導致了心跳包長度不固定，弱化了加密通信中的數據長度特徵。 Lazarus組織使用的CC服務器為失陷主機，TLS通信證書為失陷主機的正常HTTPS業務證書，從而將攻擊流量隱藏到了大量的正常HTTPS訪問流量之中，阻礙了研究人員對其服務器特徵的收集。但是該款木馬化開源工具訪問失陷主機的TLS客戶端指紋和瀏覽器正常訪問失陷主機的TLS客戶端指紋是有較大差異的。另外該工具在請求後續載荷的時候有每分鐘1次的心跳行為，雖然心跳包長度並不固定，但是長度是在一定範圍內變化的，具有一定流行為特徵。

HireHackking

sl-abstract-malicious-binary-code-1200-1200x600.jpg今年上半年，一家軟件供應商受到了Lazarus惡意軟件的攻擊，該惡意軟件是通過未打補丁的正版軟件傳播的。值得注意的是，這些軟件漏洞並不是新的，儘管供應商發出了警告和補丁，但許多供應商的系統仍繼續使用有漏洞的軟件，允許攻擊者利用它們。幸運的是，研究人員的主動響應發現了對另一個供應商的攻擊，並有效地挫敗了攻擊者的努力。

經過進一步調查，研究人員發現開發被利用軟件的軟件供應商之前曾多次成為Lazarus的受害者。這種反復出現的漏洞表明，一個持久的攻擊者的目標可能是竊取有價值的源代碼或篡改軟件供應鏈，他們繼續利用公司軟件中的漏洞，同時瞄准其他軟件製造商。

1.png

攻擊時間

攻擊者表現出了高度的複雜性，採用了先進的逃避技術，並引入了SIGNBT惡意軟件來控制受害者。此外，在內存中發現的其他惡意軟件包括Lazarus著名的LPEClient，這是一種以受害者分析和有效負載傳播而聞名的工具，此前曾在針對國防承包商和加密貨幣行業的攻擊中被觀察到。

執行情況如下：

1.一個軟件供應商通過利用另一個備受矚目的軟件而受到威脅。

2.這次攻擊中使用的SIGNBT惡意軟件採用了多種攻擊鍊和複雜的技術。

3.在這次攻擊中使用的LPEClient被觀察到執行一系列與Lazarus組織相關的目標攻擊。

SIGNBT加載程序在2023年7月中旬，研究人員發現了一系列針對幾名受害者的攻擊，這些攻擊是通過合法的安全軟件進行的，這些軟件旨在使用數字證書加密網絡通信。該軟件被利用來傳遞惡意軟件的確切方法仍然難以捉摸。然而，研究人員在正版軟件的進程中發現了利用後的活動。

在檢查受害者係統中受攻擊安全軟件的內存時，研究人員發現了帶有shellcode的SIGNBT惡意軟件的存在，這個shellcode負責直接在內存中啟動Windows可執行文件。

攻擊者使用各種策略在受攻擊系統上建立和維護持久性。這包括在系統文件夾中創建一個名為ualapi.dll的文件，該文件在每次系統引導時由spoolsv.exe進程自動加載。此外，在幾個樣本中，記錄了註冊表項以執行合法文件，以進行惡意的側加載，從而進一步確保了持久性攻擊機制。

2.png

加載最終有效負載方法

利用spoolsv.exe進程進行劫持是Lazarus的長期策略。每次重啟後自動加載ualapi.dll文件並不是這個攻擊者獨有的新技術，研究人員在過去看到過類似的策略被Gopuram惡意軟件使用。

惡意的ualapi.dll文件是使用名為Shareaza Torrent Wizard的公開源代碼開發的，shareaza是一款在國外評價極高並且相當流行的開放源代碼的p2p軟件(簡稱raza),Shareaza集合了edonkey、gnutella(1和2)和bt四種流行p2p網絡類型,並可以用於http下載,在以後的版本將會支持ftp下載,由於其優秀的界面(支持換膚)、簡潔的操作以及極強的可製定性,所以在國外廣為流傳,其評價已躍居所有p2p軟件的前5之列,並且許多p2p的下載站點已將其指定為bt的官方下載工具。

Wizard 是基於Laravel開發框架開發的一款開源項目（API）文檔管理工具。 目前支持三種類型的文檔管理Markdown。它遵循典型的Lazarus組織攻擊方法，利用公共源代碼作為基礎，並向其中註入特定的惡意功能。這個加載程序惡意軟件有一個程序來驗證受害者，它通過從Windows註冊表中讀取受害者的MachineGuid來查看其是否存在其中，然後將其與嵌入的MachineGuid值進行比較。為了訪問這個嵌入式MachineGuid值，惡意軟件定位序列“43 EB 8C BD 1D 98 3D 14”，並讀取緊隨其後的DWORD。只有當受害者的MachineGuid與預期的匹配時，惡意軟件才會進行下一步。然後，惡意軟件從硬編碼的文件路徑讀取有效負載並繼續其惡意活動。

1.有效負載路徑：C:\Windows\system32\config\systemprofile\appdata\Local\tw-100a-a00-e14d9.tmp

加載程序進程從tw-100a-a00-e14d9.tmp中檢索前32個字節，並使用該數據作為AES解密密鑰來解密其餘內容。一旦解密，負載(標識為SIGNBT的Windows可執行文件)將直接加載到內存中。在這種情況下，加載的有效負載也從相同的路徑讀取配置文件，但文件名略有不同。

配置文件：C:\Windows\system32\config\systemprofile\appdata\Local\tw-100b-a00-e14d9.tmp，

該文件內部是一個base64編碼的字符串，這與之前的SIGNBT惡意軟件方法中使用的方法類似。該字符串的前32個字符作為AES解密密鑰，後面的數據包含惡意軟件使用的配置信息。解密後的配置數據包括三個C2地址(稱為代理)、睡眠間隔、版本信息、監視的目標以及對惡意軟件操作至關重要的各種其他參數等詳細信息。

SIGNBT大多數SIGNBT惡意軟件樣本是通過惡意軟件加載程序啟動的，該加載程序只在內存中運行。在執行時，惡意軟件在初始化其配置數據後，通過發送信標開始與C2服務器通信。在其C2通信中，惡意軟件使用以SIGNBT開頭的獨特字符串。這一獨特的特點為它贏得了SIGNBT的稱號。此外，惡意軟件在其C2操作的每個階段使用不同的前綴來驗證和維護其活動。

3.png

惡意軟件採用多步驟過程來創建一個24字節的值，用於各種目的。首先，它通過以下組件生成這個值：

1.8字節的硬編碼值(SIGNBTLG):這是值的固定部分，用於驗證客戶端連接的合法性。

2.主機名MD5哈希的8個字節:包括受害者計算機名MD5哈希的前8個字節，有助於區分每個受害者。

3.隨機生成的8字節標識符：另外8字節隨機生成，可能用於會話標識符。

在創建了這個24字節的值之後，惡意軟件會生成另外24字節的隨機數據。然後使用另一個隨機生成的24字節密鑰將這兩組24字節組合在一起。隨後，結果值和24字節密鑰都用base64編碼。最後，將這些編碼值與三個或七個隨機生成的HTTP參數名組合在一起。在未來的所有C2通信中，惡意軟件使用類似的結構，這使得檢測和分析其通信更具挑戰性。

4.png

HTTP POST數據結構

惡意軟件使用一種機制來驗證從C2服務器接收到的響應數據。具體來說，它檢查響應數據是否包含硬編碼的HTML腳本。

5.png

在驗證過程中，惡意軟件使用base64解碼來自C2服務器的前12個字節，用加號替換空格以創建一個7個字符的字符串，然後對接下來的12個字節重複此過程。然後將每個集合中的前七個字符異或處理並與“success”字符串進行比較，此重複過程應用於每個HTTP通信序列，以驗證響應是否符合預期的“success”標準。

接下來，惡意軟件發送帶有SIGNBTKE頭的HTTP請求，如果它收到來自C2服務器的“success”消息，它會激活CCBrush類中的getInfo函數。該功能收集受害者計算機的各種信息，如計算機名稱、產品名稱、操作系統詳細信息、系統正常運行時間、CPU信息、系統區域設置、時區、網絡狀態和惡意軟件配置數據。在發送此特定於系統的信息之後，惡意軟件發送另一個帶有SIGNBTGC前綴的HTTP請求，這次使用從100個可能的參數名稱列表中隨機選擇的嵌入式HTTP參數。

6.png

使用AES和從SIGNBTLG HTTP請求獲得的解密密鑰對從C2服務器接收到的數據進行解密。如果解密的數據是“keep”，惡意軟件使用SIGNBTSR前綴響應“OK”消息，表示通信成功。如果存在問題，惡意軟件使用SIGNBTFI前綴來傳達問題或通信失敗的性質。綜上所述，C2通信過程可以描述如下:

7.png

C2通信過程

如果傳遞的數據不等於“keep”，表明需要特定的指令或操作，則惡意軟件繼續調用相應的類和函數進行後門攻擊，SIGNBT惡意軟件配備了一套廣泛的功能，旨在對受害者的系統施加控制。為了執行這些功能，惡意軟件以類名、函數名和任何必要參數的形式從C2服務器接收指令。然後，它執行嵌入在惡意軟件代碼庫中的相關功能。

8.png

每個後門命令的名稱都很簡單，實現了常用的Windows命令，如ping、netstat和systeminfo。需要注意的是，後門能夠為自動執行植入額外的有效負載，內部命名為“deploy”。這個後門函數通過使用AES解密的命令行參數接收文件路徑，使用這個命令，可以觀察到SIGNBT植入瞭如上所述的SIGNBT加載程序部分已經描述過的魔幻DLL。

經過分析，攻擊者最初對受害者的攻擊涉及利用軟件漏洞，然後，他們開始使用DLL側加載技術部署SIGNBT惡意軟件。此外，攻擊者使用後門功能“deploy”來為自動執行植入額外的有效負載。這種多方面的攻擊表明了攻擊的高度複雜程度。

LPEClient使用如上所述的綜合後門，攻擊者在受害者的內存中部署了額外的惡意軟件。值得注意的是，這些新發布的惡意軟件變體主要只在系統內存中執行，而不干擾磁盤。根據研究人員的追踪分析，他們已經觀察到攻擊者向受害者設備提供了LPEClient和憑據轉儲實用程序等工具。

9.png

SIGNBT提供的額外有效負載

LPEClient惡意軟件並不新鮮，最早是在2020年對國防承包商攻擊的調查中發現的，它旨在收集受害者信息並從遠程服務器下載額外的有效負載以在內存中運行。雖然之前已經有過報導，但最近的發現表明LPEClient已經發生了重大的迭代。它現在採用先進的技術來改進其隱身性並避免檢測，例如禁用用戶模式系統調用掛鉤和恢復系統庫內存部分。這表明攻擊者在不斷努力提高其惡意軟件的複雜性和有效性。

與其他攻擊活動的聯繫此次攻擊中使用的一種名為LPEClient的惡意軟件在最近被認為是Lazarus組織開發的表現最為突出的攻擊活動。這種特殊的惡意軟件一直作為初始攻擊載體，加速了有效負載的傳播。在很長一段時間裡，專門針對國防承包商和核工程師。

在最近的一次事件中，攻擊者通過木馬化的VNC或Putty客戶端發送LPEClient進行中間攻擊，從而攻擊目標。另一個針對加密貨幣行業的活動是在2023年7月發現的，在這個以經濟動機的攻擊活動中，攻擊者利用了與3CX供應鏈攻擊有關的Gopuram惡意軟件。有趣的是，在該樣本中，攻擊者還使用了LPEClient惡意軟件。在引入Gopuram集群之前，LPEClient被用於傳播後續的惡意軟件。這三個被認為是Lazarus在2023年發起的攻擊，說明了不同的初始攻擊載體和攻擊鏈，但它們始終依賴於LPEClient惡意軟件來傳遞最終的有效負載。

10.png

2023年Lazarus攻擊的三此活動的攻擊鏈

總結在當今的網絡安全領域，Lazarus組織仍然是一個高度活躍和多才多藝的攻擊者。攻擊者已經展示了對IT環境的深刻理解，改進了他們的策略，包括利用高知名度軟件中的漏洞，這種方法允許他們在初始攻擊完成後有效地傳播惡意軟件。此外，這個臭名昭著的攻擊者的活動超越了地理界限和行業部門，他們針對不同的行業有不同的目標，使用不同的工具、戰術和技術，這突出表明他們最近的活動具有復雜的方法和明確的動機。

HireHackking

1.概述近期，安天CERT（安天應急響應中心）在梳理安全事件時，發現一例偽裝成韓國互聯網安全局（KISA）研究員針對韓國新聞行業重要人物進行魚叉釣魚的網絡攻擊活動，經研判分析，此次活動來自Kimsuky組織。 Kimsuky是一個疑似來源於半島方向的網絡間諜組織，其至少自2012 年以來一直保持活躍。該組織的最初攻擊目標主要是韓國的政府、軍隊、外交、智囊團以及各領域專家，如今已擴展覆蓋至歐美、俄羅斯、日本等亞洲國家和地區，其情報收集活動的重點也從最初的與半島方向相關外交政策和國家安全問題拓展到數字貨幣等領域。

此次釣魚攻擊手法可總結如下：攻擊者首先通過老版本的BBS論壇程序漏洞入侵一批網站，上傳Webshell控製網站服務器用作跳板，掛載功能腳本和待分發的載荷。然後攻擊者發送魚叉式釣魚郵件，等待受害者的機器中招後下載跳板上的載荷，執行後可獲得受害機器的系統信息、文件和憑證等重要數據。

2.攻擊流程分析經過分析還原，推測攻擊流程如下：攻擊者首先通過BBS漏洞入侵了網站，然後上傳Webshell及其他攻擊活動中所需要的組件到web服務器，web服務器作為跳板機，實現發送郵件、接收受害者信息、提供惡意載荷下載等功能。最後攻擊者構造釣魚郵件投遞到目標機誘導用戶執行，攻擊者可通過Webshell獲取收集到的受害者信息。

图 2 1 攻击流程示意图.jpg

圖2‑1 攻擊流程示意圖

3.釣魚郵件分析表3‑1二進制可執行文件

3-1.png

此次攻擊活動目標為駐韓-韓國境內的Daily NK代表，攻擊者向其發送標題可譯為“210813_Business Contact (Cyber Safety)”的釣魚郵件，釣魚郵件中僅包含了一個含有惡意宏的doc附件。

表3‑2郵件信息

3-2.png

釣魚郵件的內容如下所示。

图 3 1 钓鱼邮件.jpg

圖3‑1 釣魚郵件

值得注意的是，該附件打開時需要密碼，等目標郵件詢問正確的密碼時，攻擊者將回复補充密碼。仿冒真實案例[1]，此次行動中回复的內容大致為“我很抱歉，先生。看來我犯了一個錯誤。密碼是cyber08^。謝謝。Dongwook Kim 高級研究員。”

图 3 2 附件打开时需要密码.jpg

圖3‑2 附件打開時需要密碼

图 3 3 攻击者回复补充密码[1].jpg

圖3‑3 攻擊者回复補充密碼[1]

攻擊者以文檔創建於早期Word版本作為藉口，誘導目標啟用宏。

图 3 4 诱导目标启用宏.jpg

圖3‑4 誘導目標啟用宏

文檔中的宏代碼主要實現兩部分功能，一部分用於顯示出文檔中的誘餌內容，另一部分用於從服務端下載惡意載荷並執行。

图 3 5 文档中的宏代码.jpg

圖3‑5 文檔中的宏代碼

正文誘餌內容大致以韓國網絡振興院的口吻描述智能手機感染惡意程序的應對方法，以增強文檔的可信性。

图 3 6 显示出的诱饵内容.jpg

圖3‑6 顯示出的誘餌內容

創建1589989024.xml文件到模板路徑下，並通過調用wscript.exe來執行xml中的vbscript代碼，VBScript代碼用於從服務端下載惡意載荷並執行。代碼內容如下：

图 3 7 下载恶意载荷的代码.jpg

圖3‑7 下載惡意載荷的代碼

图 3 8 xml文件内容.jpg

圖3‑8 xml文件內容

分析過程中載荷已被刪除，因此無法對後續載荷進行分析，但參考以往同源樣本可估測後續實現的功能主要如下[2]：

1) 將VBAWarnings數據添加到MS Office註冊表中以此更改安全功能。

2) 構造特定的http數據頭，並將收集的信息（系統信息、進程列表、最近訪問的文件等）經過Base64編碼後傳回跳板機。

3) 設置計劃任務用於執行跳板機中的其它惡意代碼。

4) 執行經過Base64編碼的PowerShell腳本，運行帶有惡意的鍵盤記錄功能，以記錄用戶的鍵盤輸入。

图 3 9 击键记录功能的Powershell脚本[2].jpg

圖3‑9 擊鍵記錄功能的Powershell腳本[2]

4.跳板機分析4.1 Webshell分析經過研判，載荷分發服務器的性質為跳板機，通過掃描發現某目錄下存在Webshell，根據服務器運行內容判斷攻擊者可能通過BBS漏洞入侵，得手後上傳Webshell來對服務器進行操作，包括上傳工具腳本和處理日誌結果。

對Webshell分析發現其採用的是嵌套的gzinflate和base64_decode做加密：

图 4 1 Webshell代码.jpg

圖4‑1 Webshell代碼

該工具可能為Kimsuky組織自研的Webshell工具，能夠獲取網站服務器的操作系統版本、操作系統名、主機名、cpu型號、IP地址等信息，具備目錄選擇及文件的下載、重命名、刪除、查看、上傳等功能。图 4 2 Webshell界面.jpg

圖4‑2 Webshell界面

在對網站文件排查時發現日誌文件中記錄如下信息，猜測在攻擊過程中如果檢測到目標存在分析行為，會自動刪除所有文件。

图 4 3 文件删除的日志.jpg

圖4‑3 文件刪除的日誌

4.2 發件工具分析跳板機中的其餘惡意文件已被刪除，只觀察到其中部分php文件。發現遺留的php文件中包含可能為該組織自有的發件工具，將該發件工具插入到跳板機的web目錄中，設置好可用來操縱跳板機發送郵件。

spacer.gif 图 4 4 轻量级邮件发送工具.jpg

圖4‑4 輕量級郵件發送工具

4.3 受害日誌分析跳板機會將受害者主機的信息存放到文件中，此行為猜測應為上述宏文檔下載的後續惡意載荷所具備的功能。文件中收集的信息包括：基礎系統信息、反病毒產品列表、特殊文件夾下的文件-最近編輯或打開的、進程列表信息。受害機中的文件名中含有許多“報導資料”、“平澤”字樣以及許多時事新聞內容，以此推測受害者是一名韓國人，且且應是新聞從業人員。

图 4 5 收集到的受害者信息.jpg

圖4‑5 收集到的受害者信息

根據對收集到的日誌、郵件等信息進行分析，我們發現連接Webshell的IP與魚叉郵件中的發件IP一致(192.203.145.*)。查詢到該IP地址歸屬於韓國建國大學，其只曾開放過3389端口且當前已關閉，無法繼續分析，猜測其可能是攻擊者攻陷的跳板機。

图 4 6 发送鱼叉邮件的IP所指向的主机.jpg

圖4‑6 發送魚叉郵件的IP所指向的主機

5 威脅框架映射本次系列攻擊活動共涉及ATTCK框架中9個階段的13個技術點，具體行為的技術特點分佈圖如下：图 5 1 技术特点对应ATT&CK的映射.jpg

圖5‑1 技術特點對應ATTCK的映射

具體的ATTCK技術行為描述表如下：

表5-1 ATTCK技術行為描述表

5-1.png

6.總結Kimsuky組織作為半島方向的APT組織，一直保持著很高的活躍度，其對熱點事件尤其是軍事政治和外交等相關的事件保持較高的關注，該組織在攻擊過程中體現出輕量化、多階段腳本載荷的特點，以避免檢測或延遲分析時間。此次攻擊活動與以往攻擊活動相似，均是入侵網站將其作為跳板機同受害機通信，此類攻擊手法能夠在一定程度上減少暴露的可能。

附錄：參考資料[1] 북한 해킹조직 ‘탈륨’, KISA 직원까지 사칭…전방위 공격

https://www.dailynk.com/20210817-4/

[2] 탈륨조직, 국내 블록체인 기업 체불확인원 문서로 공격 수행

https://blog.alyac.co.kr/3458

HireHackking

IVANTIAVALANCHE漏洞利用（上）

是否需要任何身份驗證？此時，我似乎擁有了發送我自己的信息所需的一切。但是，當我發送時，我看到目標服務沒有任何反應。我查看了InfoRail服務日誌文件，發現了這些有趣的行：

11.png

InfoRail日誌文件——刪除未經身份驗證的消息

我似乎漏掉了一個重要的部分：身份驗證。有了有關協議和加密的所有詳細信息，我能夠快速識別網絡流量中的註冊消息。這是負載不以XML形式存儲的罕見示例之一。下面的截圖展示了一個註冊消息的片段：

12.png

註冊消息的片段

這裡研究人員發現了幾件重要的事情：

马云惹不起马云 --reg.appident——指定嘗試註冊的服務的名稱。

马云惹不起马云--reg.uname/reg.puname——指定看起來像用戶名的東西。

马云惹不起马云--reg.cred/reg.pcred——指定看起來像哈希密碼的東西。

經過大量的代碼分析，我確定了以下內容：

马云惹不起马云--Uname和puname是部分隨機的。

马云惹不起马云--Cred和pcred值是MD5哈希值，基於以下值：

马云惹不起马云--用戶名（.anonymous.0.digits）。

马云惹不起马云--密鑰的適當片段，在源代碼中被硬編碼。

同樣，唯一需要的秘密在源代碼中是可見的。攻擊者可以檢索密鑰並構造他自己的有效註冊消息。

最後，我們可以正確註冊InfoRail服務並將我們自己的消息發送到任何Avalanche服務。

在這個階段，可以驗證ObjectGraph類中沒有實現allowlist的服務。我找出了其中的5個：

马云惹不起马云數據存儲服務(ZDI-CAN-15169)。

马云惹不起马云StatServer服務(ZDI-CAN-15130)。

马云惹不起马云通知服務器服務(ZDI-CAN-15448)。

马云惹不起马云證書管理服務器服務(ZDI-CAN-15449)。

马云惹不起马云Web文件服務器服務(ZDI-CAN-15330)。

我們有五個XStream反序列化終端，可以反序列化我們提供的任何東西。人們可以立即開始考慮利用這種反序列化的方法。首先，XStream對其安全性非常透明。他們的安全頁面（可在此處獲得）基於Java運行時中可用的類提供多個小工具。遺憾的是，沒有合適的小工具適用於我試圖利用的前四個服務，因為沒有加載所需的類。

XStream試圖允許盡可能多的對像圖，默認轉換器幾乎是steroid上的Java序列化。除了對第一個不可序列化的父構造函數的調用之外，Java序列化可以實現的一切似乎都可以通過XStream實現（括代理構造）包。

在較新版本的XStream中似乎沒有代理構造。但是，我們仍然應該能夠使用ysoserial小工具來利用它。那時還沒有用於XStream的Ysoserial小工具，所以我自己創建了幾個。它們可以在這個GitHub存儲庫中找到。

使用我的ysoserialXStream小工具，我成功地在四個Avalanche服務中執行了重構代碼。以下是我能夠利用的服務的摘要，以及所需的小工具：

马云惹不起马云StatServer：使用AspectJWeaver和CommonsBeanutils1利用。

马云惹不起马云數據存儲庫：使用C3P0和CommonsBeanutils1進行利用。

马云惹不起马云證書管理服務器：使用CommonsBeanutils1利用。

马云惹不起马云Avalanche通知服務器：使用CommonsBeanutils1利用。

沒有特別的原因，讓我們關注StatServer。首先，我們必須找到將反序列化包含的XML有效負載的消息的主題和子類別。據此，InfoRail協議消息標頭應包含以下鍵和值：

马云惹不起马云h.distlist=255.3.2.12

马云惹不起马云h.msgsubcat=3502（GetMuCellTowerData消息）

在本例中，我們將使用AspectJWeaver小工具，它允許我們上傳文件。下面是XStream的AspectJWeaver小工具：

AspectJWeaver.xml

13.png

這個小工具任務如下：

马云惹不起马云iConstant標籤包含Base64文件內容。

马云惹不起马云folder標籤包含上傳目錄的路徑。我的目標是AvalancheWeb應用程序根目錄。

• key標記指定文件的名稱。

有了所有需要的數據，我們就可以開始利用過程了：

14.png

StatServer利用——上傳Webshell

以下屏幕截圖展示了上傳的webshell和whoami命令的執行。

15.png

StatServerExploitation——Webshell和命令執行

成功！綜上所述，可以向Avalanche服務發送消息的攻擊者可以在4個不同的服務中濫用XStream反序列化。

我還在第五個服務上實現了遠程代碼執行。然而，利用這個服務要復雜得多。

利用JNDI查找Java命名和目錄接口(JNDI)查找有很長的歷史，在Log4Shell漏洞出現之前，許多研究人員就已經熟悉了這個向量。 CVE-2021-39146就是一個證明，它是一個觸發查找的XStream反序列化小工具。它是唯一一個對Web File Server服務有效的XStream小工具，對此我無法製作一個有效的ysoserial小工具。

儘管如此，我們仍在處理一個新的Java版本。因此，我們不能濫用遠程類加載。此外，攻擊者不能濫用LDAP反序列化向量(此處有描述[PDF])。使用JNDI注入，我們可以交付序列化的有效負載，然後由目標反序列化。然而，我們沒有意識到任何反序列化小工具可能被濫用在Web文件服務器。如果有任何gadget，我們首先就不需要JNDI查找。幸運的是，在Web文件服務器類路徑中包含了幾個有趣的JAR包。

16.png

Web文件服務器- Tomcat jar

可以看到，Web File Server加載了幾個Tomcat JAR包。你可能還熟悉MichaelStepankin發現的技術，它濫用TomcatBeanFactory中的不安全反射通過JNDILookup執行任意命令。

總之，我們可以執行以下攻擊：

马云惹不起马云設置惡意LDAP服務器，該服務器將為惡意BeanFactory提供服務。我們將使用RogueJNDI工具。

马云惹不起马云註冊InfoRail服務。

马云惹不起马云發送包含CVE-2021-39146小工具的消息，以指向在步驟1中定義的服務器的Web文件服務器為目標。

马云惹不起马云Web文件服務器進行LDAP查找並從惡意服務器檢索數據。

马云惹不起马云遠程代碼執行。

LDAP服務器的設置如下圖所示：

17.png

RogueJndi的設置

下一個片段展示了用於此概念證明的CVE-2021-39146小工具：

jndiGadget.xml

18.png

如果一切順利，並且成功地執行了查找，那麼Rogue JNDI應該顯示以下消息，並且應該在目標系統上執行代碼。

19.png

被觸發的JNDI查找

總而言之，我們能夠濫用自定義的IvantiAvalanche協議和XML消息反序列化機制來利用五種不同的服務並以SYSTEM權限遠程執行代碼。我在IvantiAvalanche中發現了更多反序列化漏洞。接下來，我將繼續討論協議和跨服務通信。

在通信和身份驗證消息中濫用攻擊條件如上所述，各種Avalanche服務在InfoRail的幫助下相互通信。當服務提供響應時，該響應將再次通過InfoRail服務轉發。這項研究的想法是：攻擊者是否有可能欺騙響應？如果是這樣，就有可能濫用IvantiAvalanche行為並執行潛在的惡意操作。

我重點研究了身份驗證操作，如下圖所示：

20.png

認證方案當用戶通過AvalancheWeb應用程序登錄面板進行身份驗證時，後端會將身份驗證消息傳輸到EnterpriseServer。此服務驗證憑據並發回適當的響應。如果提供的憑據正確，則用戶將通過身份驗證。

在這個研究過程中，我學到了兩件重要的事情：

马云惹不起马云攻擊者可以註冊為任何服務。

马云惹不起马云身份驗證消息分佈在註冊的Enterprise Server的每個實例中。

據此，攻擊者可以將自己註冊為企業服務器，並截獲傳入的身份驗證消息。但是，這種行為並沒有什麼直接的後果，因為傳輸的密碼是經過哈希和加密的。

下一個問題是是否可以將攻擊者自己的響應傳遞給AvalancheWeb，以及它是否會被接受。事實證明，是的，這是可能的！如果你想提供自己的響應，則必須在消息標頭中正確設置兩個值：

马云惹不起马云Origin——發送消息的AvalancheWeb後端的主題(ID)。

马云惹不起马云MsgId——原始身份驗證消息的消息ID。

這兩個值都比較容易獲得，因此攻擊者可以對消息提供自己的響應。它將被正在等待響應的服務接受。下圖展示了一個攻擊場景示例。

21.png

攻擊條件攻擊場景如下：

——攻擊者嘗試使用錯誤的憑據登錄Web應用程序。

——Web應用程序發送認證消息。

——InfoRail服務將消息發送到兩台企業服務器：合法服務器和惡意服務器。

——攻擊時間：

——合法服務器以“錯誤憑據”消息響應。

——惡意服務器以“credentialsOK”消息響應。如果攻擊者的服務器首先傳遞消息，則將其轉發到AvalancheWeb應用程序。

——攻擊者獲得身份驗證。

請注意，針對攻擊者服務器的“登錄消息”不是故意存在的（儘管它實際上是傳輸給攻擊者的）。我想強調一個事實，即可以在不可能讀取消息的情況下利用這個問題。在此攻擊中，攻擊者必須暴力破解已經提到的消息ID值。它使整個攻擊複雜化，但仍然有可能被利用。

總結這一部分，攻擊者可以設置自己的惡意Enterprise Server，並濫用攻擊條件來向Web應用程序交付自己的身份驗證響應。還有兩件事需要調查：響應消息是什麼樣的，我們能否緩解攻擊？

身份驗證處理以下代碼段提供了對登錄消息的示例響應。請注意，這些消息在合法使用期間會更大。但是，對於概念驗證，我已將它們最小化並僅存儲了開發所需的那些部分。

22.png

響應消息由幾個重要部分組成：

马云惹不起马云它包含一個responseObject標記，它是一個序列化的用戶對象。

马云惹不起马云它包含一個非常重要的responseCode標籤。

马云惹不起马云在身份驗證期間的某個時刻，Web後端調用UserService.doLogin方法：

doLogin.java

23.png

在[1]處，UserCredentials對像被實例化。然後，設置其成員。

在[2]處，將調用authenticate方法，並將在[1]處初始化的對像作為參數傳遞：

authenticate.java

24.png

在[1]處，初始化UserLogin對象。

在[2]處，UserCredentials對像被序列化。

在[3]處，消息正在發送到企業服務器，Web後端等待響應。

在[4]處，驗證響應中包含的responseCode。我們希望它等於0。

在[5]處，userLogin.authenticated設置為True。

在[6]處，userLogin.currentUser被設置為包含在responseObject中的對象。

在[7]處，該方法返回userLogin對象。

基本上，響應應該有一個等於0的responseCode。它還應該在responseObject標記中包含一個正確序列化的User對象。

最後，我們分析負責調用doLogin函數的UserBean.loginInner方法的片段。

loginInner.java

25.png

在[1]處，調用doLogin方法。它檢索UserLogin類型的對象。

在[2]處，它將this.currentUser設置為userLogin.currentUser。

在[3]處，它設置各種其他設置。

有一件非常重要的事情需要注意：Web後端不會將登錄面板中提供的用戶名與企業服務器檢索到的用戶名進行比較。因此，攻擊者可以：

马云惹不起马云觸髮用戶名為“poc”的身份驗證。

马云惹不起马云贏得攻擊並在響應中提供用戶“amcadmin”。

马云惹不起马云然後攻擊者將被認證為“amcadmin”。

總而言之，攻擊者似乎沒有任何障礙，他的響應應該由WebBackend處理，沒有任何問題。接下來，我們將注意力轉向防禦。

在默認安裝中，EnterpriseServer和InfoRail服務與Web後端位於同一主機上。這使得攻擊條件的利用變得更加困難，因為合法的通信由本地接口處理，這比通過外部網絡接口的通信要快得多。

儘管如此，攻擊者還是有一些優勢。例如，他不必生成動態響應，因為響應負載可以在漏洞利用中進行硬編碼。下表概述了攻擊者和合法EnterpriseServer必須執行的操作。

攻擊者從原始登錄消息中獲取消息ID，並將其放置在標頭中。

發送靜態響應。

企業服務器從原始登錄消息中獲取消息ID並將其放在標頭中。

解密並驗證用戶的憑據。

檢索用戶的詳細信息並創建用戶對象。

動態創建響應。

遠程攻擊者需要執行的操作要少得多，可以更快地準備響應。它使攻擊可以順利進行。

未經身份驗證的攻擊者可以修改Avalanche系統設置。這是由於一個單獨的漏洞允許繞過域身份驗證(ZDI-CAN-15919)。遠程攻擊者可以啟用基於LDAP的身份驗證並為LDAP服務器配置設置任何地址。在這種情況下，合法的EnterpriseServer將首先嘗試訪問這個“非法”身份驗證服務器。這將給攻擊者額外的1 - 2秒時間(如果使用得當，甚至更多)。這樣，攻擊者就可以獲得更多的時間來發起攻擊。

HireHackking

2023年11月，IPStorm基礎設施被FBI拆除，同時對與IPStorm惡意軟件有關的相關個人進行了定罪。這是當前打擊網絡威脅工作中的一個重要里程碑。

本文將對IPStorm惡意軟件的變體和功能進行深入介紹。

2019年5月，來自anomaly的研究人員發現了一種新的針對Windows的Golang惡意軟件，他們將其命名為IPStorm。 IPStorm是一種殭屍網絡，它濫用名為星際文件系統(IPFS)的合法點對點(p2p)網絡作為掩蓋惡意流量的手段。據發現，該惡意軟件允許攻擊者在受害者的Windows計算機上執行任意PowerShell命令。

研究人員最近確定了針對各種Linux架構(ARM, AMD64, Intel 80386)和平台(服務器，Android, IoT)的IPStorm新Linux變體並檢測到一個macOS變體。在本文發佈時，macOS變體和大多數Linux樣本在VirusTotal中完全未被檢測到。 IPStorm是用Golang編寫的，這使得Intezer能夠檢測到Linux樣本和由anomaly首先報告的Windows惡意軟件之間的跨平台代碼連接。

linux變體比Windows變體有更多的功能，比如使用SSH暴力破解來傳播給更多的受害者，以及濫用Steam遊戲和廣告平台的欺詐性網絡活動。 linux變體調整了一些功能，以解釋該操作系統和Windows之間存在的根本差異。

接下來將介紹IPStorm Windows和Linux樣本之間的代碼關係圖，分析其中一個Linux變體的行為，並將其功能和功能與舊的Windows樣本進行比較，以跟踪其演變。

IPStorm技術分析大多數IPStorm Linux樣本在我們將它們提交給Intezer進行分析之前是完全未被檢測到的。

在這篇文章中，我們將重點關注658638c6bef52e03e6aea4b6c1b2b3b8d81ad40144b56b2122d96e6957c33117 Linux樣本。

1.png

658638c6bef52e03e6aea4b6c1b2b3b8d81ad40144b56b2122d96e6957c33117在VirusTotal中未檢測到樣本

由於IPStorm是用Golang編寫的，我們不僅可以觀察到不同Linux變體之間的強代碼連接，還可以識別到2019年上傳至Intezer的IPStorm Windows樣本的連接。

2.png

由Intezer分析分類的IPStorm惡意軟件家族樣本

下圖強調了不同版本和操作系統之間的代碼相似性。節點表示單個樣本，線條表示它們之間的代碼關係，所有的樣本都以某種方式相互聯繫。

3.png

不同樣本間的IPStorm代碼相似性圖。節點表示單個樣本，線條表示它們之間的代碼關係

該圖描繪了三個主要的集群，每個集群都包含具有強代碼連接的樣本:

PE, intel 80386架構；

ELF, intel 80386架構；

ELF和x86-64架構；

你還會注意到ELF集群和ELF和PE intel 80386架構集群之間存在共享代碼。

你可以使用這個GitHub存儲庫中的cluster_directory.py API腳本來創建你自己的集群圖。

IPStorm Linux變體活動流程去除Linux的變體符號，使用插件IDAGolangHelper，我們檢索了文件的符號，並準確地看到了惡意軟件包含哪些包。在Go語言中，包是一群組成特定功能的Go源文件，每個Go源文件都屬於一個包。

Linux惡意軟件的主要邏輯是在一個名為storm_starter的包中實現的，這是一個Windows變體中沒有的新包。所有的邏輯都是通過Windows變體的main函數實現的。

這兩個版本在實現主要流程的方式上有相似之處，但是，由於兩個操作系統之間存在差異，Linux實例具有額外的功能並調整了一些邏輯。

Linux迭代首先禁用內存不足(OOM)殺手程序，以防止它終止惡意軟件，隨後繼續檢查以防止病毒或其他惡意軟件進一步執行與安全工具有相關的任何進程。接下來，惡意軟件生成公鑰將其保存在一個名為strom.key的文件中。這個密鑰保存的位置是基於惡意軟件被執行時的權限。如果惡意軟件以root權限執行，密鑰將存儲在/etc/storm.key；否則，將保存在/tmp/storm.key下。然後，惡意軟件試圖與點對點網絡中的其他節點建立連接。

惡意軟件向不同的服務發送HTTP請求，如diagnostic[.]opendns[.]com/myip, ifconfig[.]io/ip和myip[.]dnsomatic[.]]com接收受害服務器的外部IP地址。如果惡意軟件以root身份運行，它將在systemd下創建一個服務來實現持久化，並將自己複製到/usr/bin/storm，否則將被拷貝到/tmp/storm目錄下；然後，惡意軟件將從新的安裝路徑重新啟動。

這個新進程負責執行IPStorm惡意軟件的主要功能，包括之前在Windows變體中看到的逆向shell，維護與P2P網絡中其他對等節點的連接，以及將惡意軟件傳播給其他受害者的新功能。

4.png

IPStorm Linux輸出非特權用戶

Linux與Windows比較比較IPStorm linux變體0.2.05a和Windows變體0.0.2m可以發現，開發者添加了一些功能，並修改了現有的功能來攻擊Linux平台。

包比較該惡意軟件由不同的Golang包組成，每個包提供不同的功能。下表對兩個版本之間的包比較進行了分類:

5.1.png

5.2.png

5.3.png

注:我們將linux變體0.2.05a與Windows變體0.0.2m進行了比較，將後者在anomaly的報告中進行了分析。然而，惡意軟件經常被更新，我們已經觀察到多個不同的版本，它們之間的功能也可能不同。

功能比較掃描工具：Android和SSH暴力破解Linux變體試圖通過SSH暴力破解在互聯網上傳播和感染其他受害者。一旦建立連接，惡意軟件將通過比較受攻擊服務器的主機名和字符串“svr04”(這是corie SSH蜜罐的默認主機名)來檢查受害服務器是否是蜜罐。如果惡意軟件識別到蜜罐，它將關閉連接，否則它將繼續下載有效載荷並感染服務器。

6.png

驗證服務器是否為蜜罐

linux變體特有的另一種傳播方法是搜索潛在的Android受害者，惡意軟件檢查連接ADB (Android Debug Bridge)到受害節點的設備。一旦識別出來，它就會將之前從P2P網絡下載的Android版本的IPStorm上傳到設備上。

7.png

來自storm服務日誌的屏幕截圖，顯示下載的文件

繞過殺毒軟件IPStorm Windows和linux變體都實現了與檢測逃避相關的功能，每個版本使用不同的技術。在linux變體中，負責此邏輯的包稱為storm_malware_guard。該文件遍歷所有當前運行的進程，以便找到並終止可能檢測到惡意軟件活動的進程。

storm_malware_guard包中實現此技術的函數稱為KillSuspiciousProcesses。這個包中的其他函數負責獲取有關CPU和內存使用情況、I/O端口數量以及返回有關進程和線程信息的函數的信息。

在Windows變體中，逃避邏輯是在一個名為avbypass的包中實現的。該技術基於隨機睡眠時間和多個函數調用，此方法的目的是使反病毒解決方案更難跟踪原始進程。

似乎由於不同的操作系統，每個版本的IPStorm都有自己的逃避檢測的方法。

逆向shell兩個版本的IPStorm都使用backshell這個名稱來指代逆向shell的功能，Linux變體的backshell功能與Windows變體相同。

Windows變體有一個名為powershell的包，其中包含實現逆向shell的函數。 linux變體中也有相同的包，但它只包含一個函數:storm_powershell__ptr_Backend_StartProcess。該函數用於獲取受感染系統的逆向shell。

逆向shell的實現是兩個IPStorm變體之間代碼重用連接的一個清晰樣本。下面的截屏顯示了兩個版本中文件名的變化和相同的函數名:

Linux:

8.png

windows:

9.png

持久性linux變體只有在以root權限執行時才會嘗試獲得持久性，另一方面，Windows變體總是希望獲得持久性。惡意軟件的每個變體，Linux和Windows，都使用不同的技術來獲得持久性，因為它們針對的操作系統根本不同。

Windows變體通過將自身複製到隨機位置並將程序添加到HKCU:SoftwareMicrosoftWindowsCurrentVersionRun註冊項來實現持久性。

linux變體通過在/etc/systemd/system/storm.service下創建systemd服務來實現持久化。

10.png

/etc/systemd/system/storm.service

11.png

在Linux變體中實現持久性的函數

另一個區別是文件被複製到的位置。 Windows變體使用隨機文件路徑，linux變體使用固定路徑。

網絡流量除了創建逆向shell之外，我們還發現IPStorm的Linux變體利用其廣泛傳播的優勢在backshell執行不同的欺詐活動，濫用遊戲和廣告盈利。由於它是殭屍網絡，惡意軟件利用來自不同可信來源的大量請求，因此不會被阻止或追踪。

在Windows變體中沒有觀察到這種活動。

Steam遊戲欺詐Steam是Valve公司推出的一款受歡迎的遊戲服務，在全球擁有數億用戶，它還為想要在自己的網站上使用Steam數據的開發者提供了一個API。

作為遊戲開發者盈利過程的一部分，Steam用戶可以購買和出售不同的道具，如裝備、皮膚和其他遊戲內元素。這個平台非常受歡迎，已經成為網絡罪犯的熱門目標。

攻擊者使用的一種已知方法是創建網絡釣魚網站，引誘用戶提交他們的Steam登錄憑證，通過訪問用戶的憑據，攻擊者可以完全訪問該帳戶，包括API密鑰。

IPStorm生成了大量的流量到Steam的API，查詢各種Steam用戶的數據，並使用多個有效的API密鑰。

12.png

目前懷疑這些被盜賬戶是被監控的虛假交易騙局的一部分。

廣告欺詐該惡意軟件生成模仿虛假廣告點擊的請求。我們追踪到的所有廣告都與色情網站有關，惡意軟件在不同的預定義網站上爬行，搜索廣告iframe，並通過瀏覽iframe來模仿用戶的“點擊”。

13.png

惡意軟件向廣告平台生成請求的樣本

14.png

惡意軟件爬過的網站

IPStorm檢測受攻擊系統檢測可以通過以下步驟檢查系統是否被IPStorm惡意軟件攻擊。

1.執行pstree | grep storm，檢查系統是否啟動IPStorm進程。

15.png

IPStorm通常使用多線程運行。

2.執行sudo systemctl status strom.service命令，檢查系統上運行的服務，因為如果惡意軟件以root權限執行，它將創建一個用於持久化的服務。

16.png

3.檢查系統中是否存在IPStorm的文件。

執行sudo find/-name “storm*” -type f命令

3.1在非root執行的情況下，輸出將類似於下面的屏幕截圖：

17.png

3.2如果惡意軟件以root權限執行，輸出將類似於下面的屏幕截圖:

18.png

4.檢查系統上開放的端口以及與之關聯的進程。執行sudo ss -tulpn命令，在下面的屏幕截圖中，屬於IPStorm惡意軟件的許多進程監聽特定端口。

19.png

5.免費使用Intezer Protect社區測試版來識別系統上正在運行的進程。下面的屏幕截圖來自服務器上執行的IPStorm警報，系統提供的信息包括惡意軟件家族名稱，可執行文件的完整路徑，進程ID，執行時間，以及到Intezer的鏈接，你可以在此惡意軟件中觀察到普遍的代碼重用。

20.png

系統受攻擊後如何終止IPStorm1.如果惡意軟件作為服務運行，則應執行sudo systemctl stop storm.service命令停止該服務:

2.刪除所有與IPStorm惡意軟件相關的文件。

3.執行sudo pkill -9 storm命令終止該進程

IPStorm響應我們提供了一個YARA規則，旨在針對內存中的工件運行，以便能夠檢測這些植入程序。

系統安全加固1.確保SSH連接是安全的。使用密鑰代替密碼或使用多因素身份驗證，瀏覽此處獲取有關SSH加固的更多提示。

2.確保系統更新到最新的軟件，並與最新的安全最佳實踐保持一致。

3.使用運行時雲工作負載保護解決方案，如Intezer Protect。 Protect提供了對系統中代碼的完整運行時可見性，並對偏離安全基線的任何可疑或未經授權的代碼發出警報。

總結IPStorm背後的攻擊者非常活躍，頻繁發布具有新功能和改進的更新版本，以及擴展到幾個不同的平台和架構，現在帶有Linux惡意軟件的IPStorm是在Golang開發的跨平台惡意軟件的最新樣本。被IPStorm攻擊的平台不僅暴露於其服務的後門，而且還被添加到IPStorm殭屍網絡中，試圖傳播給其他受害者。在過去的六個月裡，人們發現了越來越多的Golang ELF惡意軟件攻擊服務器，IPStorm是其中的一部分，其他惡意軟件還有Kaiji、Kinsing和FritzFrog。

HireHackking

想要輕鬆掌握Android 惡意軟件的逆轉技術嗎？ Incinerator 將是你在這場網絡攻防戰中的得力夥伴，無論是資深專家還是初出茅廬的新手，都能在這款工具中找到自己的舞台。

大家好！在這篇文章裡，我們將探索Incinerator 的強大功能、豐富特性以及它所帶來的種種優勢。這款Android 逆向工程工具集的靈感來自於廣受好評的Shambles項目。

1.png

我們的目標非常明確：打造一款能夠輕鬆應對Android 應用，尤其是惡意軟件的高級逆向工具。我們需要的是一個集反編譯、解密、動態調試和漏洞檢測於一體的全能工具。而且，這款工具還得能夠快速、準確地揪出那些常見和隱蔽的威脅跡象（IOCs）。

正是基於這些目標，我們推出了Incinerator！簡單來說，它是一個功能全面、操作簡便的逆向工程生態系統。不論你是經驗豐富的逆向工程專家，還是剛踏入惡意軟件分析領域的新手，Incinerator 都能滿足你的需求。

Incinerator 應用內置了多種強大功能，讓你可以輕鬆反編譯Android 應用，自動解密內容，取消反射API 調用，獲取清晰的反混淆代碼，並在真實設備上進行實時調試分析。這對於那些想要深入了解、分析和逆轉Android 惡意軟件的人來說，是一個完美的選擇，即使你沒有太多經驗也沒關係。

Incinerator 在後台進行的分析工作包括組件分析、安全漏洞檢測、靜態和動態代碼分析、漏洞挖掘以及惡意代碼分析。通過全面的檢查，Incinerator 能夠有效地幫助用戶識別和解決安全風險和漏洞。

在更高層次上，Incinerator 將解密任務放在雲端處理，其內部的漏洞分析引擎沙箱會實時更新漏洞庫，能夠精確到代碼的具體行來定位惡意代碼或漏洞。

多年前，Incinerator 與JEB 或GDA 進行了性能對比測試，並展現出了卓越的性能。如果你想看完整的對比報告，可以點擊這裡查看。

此外，我們還對比了多個威脅情報中心和在線沙箱的惡意代碼檢測與分析能力，以此來衡量Incinerator 的性能。結果同樣令人滿意，相關報告也可供大家參考。

2.png

3.png

現在，讓我們來認識一下Incinerator 背後的團隊。這款工具由Lian Security的一支約12 人的工程師團隊開發，歷時約兩年。他們也是SHAMBLES、INCINERATOR和FLEGIAS等產品的開發者，這些產品覆蓋了從軟件、基礎設施、硬件到基本操作和維護、產品UI 設計等多個領域。

4.png

Incinerator 可以在Windows、MacOS和Linux系統上運行。它支持分析APK 和DEX 文件。 APK 文件包含了編譯後的代碼文件（.dex 文件）、資源文件、證書和清單文件。 DEX 文件是Android 系統的可執行文件，包含了應用程序的所有操作指令和運行時數據。

分析文件的途徑有兩種，一種是通過Incinerator 的桌面應用程序界面，如下圖所示。

5.png

另一種是通過雲端的網絡門戶進行。

6.png

選擇哪一種方式，全憑個人喜好。我個人習慣於通過桌面應用程序上傳和打開APK。上傳後，你可以登錄到雲端門戶，在https://incinerator.cloud/#/main/task/list查看上傳的樣本。

7.png

從網絡門戶，你可以查看和處理生成的基於網絡的報告。這些報告可以分享給其他人進行APK 分析。這種訪問權限需要在你的UCENTER賬戶中進行配置，默認情況下是不公開的。

8.png

如果你想要深入了解報告，或者跟隨我們的分析步驟，請點擊這裡，你將看到如下的報告內容。

9.png

Incinerator 使用的ML 模型具有非常高的準確性。 Incinerator 的一些功能實際上是開源的，可以在Lian Security 的Github上找到。特別是用於處理和生成報告數據的兩個模型已經公開。

android-malware-detection

apk-obfucation-detection

在Base Info和Behavior Info面板以及Static Analysis、Dynamic Analysis和APK Risk側邊面板中，包含了大量的信息。我們的目標是提供一個材料清單（BOM），它從包管理器、二進製文件、源代碼和容器圖片中派生。

讓我們看看我個人特別喜歡的一些功能。你可以下載APK 的網絡流量，並將其導入到Wireshark 中進行分析。

10.png

例如，應用程序權限（Application Permissions）等許多面板，都是基於androidmanifest.xml文件的分析結果得出的，還有更多信息等待你去發掘。

11.png

快速瀏覽一下報告中的軟件組成分析（SCA）部分，你會發現這些信息大部分都是非常有價值的。

12.png

我邀請你自己去探索這份報告。我不會再次回到這個網絡門戶，因為在網絡上看到的所有內容都已經融入到了主應用程序中。

一旦樣本被雲端引擎完全分析，我們就可以開始在Incinerator 應用程序中對其進行分析。當你第一次加載樣本時，APK 報告會加載出來，它和網絡門戶報告中的內容非常相似。

13.png

如前所述，Incinerator 是一個沙箱工具，用於記錄應用程序的整個執行過程，以調用棧的形式展示。當用戶在本地打開相應的樣本時，我們可以提供類似動態調試的體驗。這使得用戶能夠理解樣本在動態執行後是如何被觸發的。

14.png

工具界面主要分為兩個部分：Base Info和Behavior info。每個部分提供的信息和主要差異如下，這些是你在使用時通常會看到的內容，但請注意，這裡列出的並不是全部信息。

15.png

在右側，我們有四個面板：Android Monitor、Set Debug Device、Static Analysis和Dynamic Analysis，我們將在後面的內容中詳細探討這些面板。

16.jpg

這是Incinerator 用戶界面的基本佈局。

17.png

讓我們開始逆轉一些惡意軟件吧！以FakeCalls 為例。逆轉惡意軟件的主要目標之一是識別攻擊者用來竊取和外洩數據的C2 和CC 通信渠道。 Incinerator 在識別這些通信渠道方面表現得非常出色。

18.png

正如上圖所示，我們知道這款惡意軟件使用了死信箱解析器（T1102.001）。這是一種將惡意內容存儲在合法網絡服務上，然後通過調用將其安裝到受害者設備上的技術。這些服務常常用來代理和掩蓋與真實CC 服務器之間的通信，通過額外的域名和IP 地址實現。

讓我們通過checkpoint 報告中檢索到的curl 信息，手動在Incinerator 中逆轉這種行為。 Incinerator 引擎識別出了執行請求到C2 服務器daebak222.com/huhu/admin.txt的代碼，如下圖所示。

19.png

如果我們對端點執行curl 命令，將會得到以下輸出。

$ curl https://www.daebak222.com/huhu/admin.txt

{

'a01': 'eWVlYWIrPj5mZmY_dXB0c3B6IyMjP3J-fA==',

'b05': 'Y2ViYWIrPj4gICI_IyAjPykpPyAlKSspIiMjPn14Z3Q=',

'a07': 'eWVlYWIrPj4gKSM_ICc_JSM_ICkrJCEkJD55ZHlkPnB1fHh_P2VpZQ=='

}

我們的目標是理解惡意軟件為何要獲取這些信息，以及它的用途。結果發現，這些信息被用來更新它的C2 通信渠道。這次檢測的整個調用棧指向了ServerInfoService.java，它調用了Service和Binder Android類，這些類通常在你需要通過HTTP 請求獲取服務器信息的服務中使用。它還提供了其他組件訪問這些信息的方法。

ServerInfo類包含了有關服務器的信息。

a01 (eWVlYWIrPj5mZmY_dXB0c3B6IyMjP3J-fA==),

b05 (Y2ViYWIrPj4gICI_IyAjPykpPyAlKSspIiMjPn14Z3Q=),

a07 (eWVlYWIrPj4gKSM_ICc_JSM_ICkrJCEkJD55ZHlkPnB1fHh_P2VpZQ==)

它代表了我們期望從服務器獲取的各種屬性。

20.png

其中，serverInfo.a01代表新服務器，serverInfo.b05代表備用服務器，serverInfo.a07代表從哪個服務器獲取信息。 fetch()和fetchFromAlternative()方法用來啟動HTTP 請求，以獲取服務器信息。

21.png

如果我們在Incinerator 控制台中按下tab鍵進入fetch()方法，我們可以看到Android 應用程序字節碼的中間語言，也就是所謂的'smali' 代碼。在這裡我們可以清楚地看到eWVlYWIrPj5mZmY_dXB0c3B6IyMjP3J-fD55ZHlkPnB1fHh_P2VpZQ==實際上是daebak222.com/huhu/admin.txt。就在下面，我們有onData方法，如果成功獲取服務器信息，則記錄成功消息。然後，它會檢查ServerInfo對象的字段（a01、b05、a07）是否有空。如果任何一個字段為空，它會記錄一個警告消息，指示服務器信息無效。否則，它將調用ServerInfoService類的updateServerInfo方法，傳遞接收到的ServerInfo對象，以更新服務器信息。

22.png

太棒了！有了Incinerator，這一切都變得非常簡單。接下來，讓我們看看Incinerator 的檢測能力。 Incinerator 識別出惡意軟件能夠捕獲設備接收的SMS 消息，發送短信，並根據C2 服務器的指令撥打電話。

23.png

讓我們驗證一下這款惡意軟件是否真的具備在受感染設備上捕獲電話通話、短信等信息的能力。首先，我們需要確認惡意軟件是否已經獲取或為自己分配了獲取這些信息的權限。從下面的圖中可以看出，它確實擁有大量權限。

24.png

那麼，惡意軟件是如何獲得這些權限的呢？我們可以雙擊調用棧中的任何參數，打開相應的代碼進行查看。特別值得注意的是Add New Device Administrator的事件。

25.png

惡意軟件會檢查設備管理員是否活躍，如果不是，它會通過發送一個Intent 來請求設備管理員權限，這個Intent的動作是android.app.action.ADD_DEVICE_ADMIN。只要用戶不答應，它就會不斷地通過循環窗口請求權限。

26.png

27.png

一旦用戶授予了權限，根據我的經驗，唯一手動停用它的方法是在Settings - Security - Device Management中操作，但到那時可能已經太晚了。

下面列出的是應用程序請求或已經獲取的權限，但這個列表並不全面：

permissionNames.add('READ CONTACTS');

permissionNames.add('WRITE CONTACTS');

permissionNames.add('READ SMS');

permissionNames.add('RECEIVE SMS');

permissionNames.add('SEND SMS');

permissionNames.add('RECORD AUDIO');

permissionNames.add('READ PHONE STATE');

permissionNames.add('WRITE EXTERNAL STORAGE');

permissionNames.add('READ EXTERNAL STORAGE');

permissionNames.add('CHANGE WIFI STATE');

permissionNames.add('INTERNET');

permissionNames.add('ACCESS WIFI STATE');

permissionNames.add('GET ACCOUNTS');

permissionNames.add('READ LOGS');

permissionNames.add('PROCESS OUTGOING CALLS');

permissionNames.add('CALL PHONE');

permissionNames.add('RECEIVE BOOT COMPLETED');

permissionNames.add('DISABLE KEYGUARD');

permissionNames.add('INSTALL SHORTCUT');

permissionNames.add('UNINSTALL SHORTCUT');

permissionNames.add('WAKE LOCK');

permissionNames.add('CHANGE WIFI STATE');

permissionNames.add('INTERNET');

permissionNames.add('ACCESS WIFI STATE');

permissionNames.add('GET ACCOUNTS');

permissionNames.add('READ LOGS');

permissionNames.add('PROCESS OUTGOING CALLS');

permissionNames.a

HireHackking

我們分析了IcedID殭屍網絡的最新變化，該活動濫用谷歌點擊付費(PPC)廣告，通過惡意廣告攻擊傳播IcedID。 IcedID 是最早在2017 年被披露的模塊化銀行木馬，也是近年來最流行的惡意軟件家族之一。 IcedID 主要針對金融行業發起攻擊，還會充當其他惡意軟件家族（如Vatet、Egregor、REvil）的Dropper。

在密切跟踪IcedID殭屍網絡的活動後，我們發現它的傳播方法發生了一些重大變化。自2022年12月以來，我們觀察到谷歌點擊付費(PPC)廣告被攻擊者濫用，通過惡意廣告攻擊傳播IcedID。趨勢科技已將檢測到的IcedID變體命名為TrojanSpy.Win64.ICEDID.SMYXCLGZ。

像谷歌廣告這樣的廣告平台，其目的是使企業能夠向目標受眾展示廣告，以提高流量和增加銷售。惡意軟件發布者濫用同樣的功能，使用一種被稱為惡意廣告的技術，其中選擇的關鍵字被劫持，顯示惡意廣告，誘使毫無戒心的搜索引擎用戶下載惡意軟件。

在我們的調查中，攻擊者使用惡意廣告通過合法組織和知名應用程序的克隆網頁傳播IcedID惡意軟件。最近，美國聯邦調查局(FBI)發布了一份關於網絡犯罪分子如何濫用搜索引擎廣告服務來偽裝成合法網站，並通過一些經濟誘惑將用戶引向惡意網站。

本文介紹了IcedID殭屍網絡的最新傳播方法和它使用的新加載程序的技術細節。

技術分析

有機搜索結果是由Google PageRank算法生成的，而谷歌廣告出現在有機搜索結果的上方、旁邊、下方或更突出的位置。當這些廣告被攻擊者通過惡意廣告劫持時，它們可以將用戶引導到惡意網站。

劫持搜索結果的關鍵詞

在調查中，我們發現IcedID傳播者劫持了這些品牌和應用程序用來顯示廣告的關鍵詞：

？？.png

這些惡意網站看起來就像合法網站一樣。下圖顯示了一個看起來合法的惡意Slack網頁，被IcedID傳播者用來引誘受害者下載惡意軟件。

1.png

一個被IcedID傳播者使用的看似合法的惡意Slack網頁

感染鏈

整個感染流程包括傳播初始加載程序，進入設備並最終釋放有效負載。有效負載通常是後門。

2.png

IcedID殭屍網絡惡意軟件感染鏈

通過劫持搜索的廣告結果發起攻擊用戶會通過在Google上輸入搜索詞來搜索應用程序，在這個特定的示例中，用戶想要下載AnyDesk應用程序，並在Google搜索欄上輸入搜索詞“AnyDesk”。被劫持的AnyDesk應用程序的廣告會導致惡意網站顯示在有機搜索結果上方。

IcedID攻擊者濫用合法的Keitaro交通方向系統(TDS)來過濾研究員和沙盒流量，隨後受害者被重定向到惡意網站。

一旦用戶選擇了“下載”按鈕，它就會下載用戶系統中ZIP文件中的惡意Microsoft軟件安裝程序（MSI）或Windows安裝程序文件。

3.1.png

3.2.png

IcedID殭屍網絡惡意廣告感染鏈

新的IcedID殭屍網絡加載程序在這個攻擊活動中，加載程序通過MSI文件被釋放，這並不是IcedID的常規操作。

安裝程序會釋放幾個文件，並通過rundll32.exe調用“init”導出函數，然後執行惡意加載程序例程。

這個“加載程序”DLL具有以下特徵:

開發者使用了一個合法的DLL，並在最後一個序數處使用“init”導出函數名將一個合法函數替換為惡意加載程序函數；

IcedID加載程序中每個合法導出函數的第一個字符都替換為字母“h”；

對惡意函數的引用是一個經過修復的合法函數；

生成的惡意文件幾乎與合法版本完全相同。這對機器學習(ML)檢測解決方案來說是一個挑戰。

從表面上看，惡意的IcedID和合法的sqlite3.dll文件幾乎完全相同。下圖顯示了使用由安全研究員Karsten Hahn開發的PortEx Analyzer工具對這些文件進行的並排比較。該工具允許我們快速地可視化可移植可執行(PE)文件的結構。

4.png

惡意IcedID(左)和合法PE(右)文件的可視化表示(使用Karsten Hahn的PortEx Analyzer工具)

因此，我們假設這是針對兩種類型的惡意軟件檢測技術的攻擊：

機器學習檢測引擎；

白名單系統；

充當IcedID加載程序的篡改DLL文件我們已經觀察到，一些被修改為充當IcedID加載程序的文件是眾所周知且廣泛使用的庫。

已被修改為IcedID加載程序的文件如下所示：

5.png

在sqlite3.dll中，我們觀察到在序號270處的函數“sqlite3_win32_write_debug”已被IcedID加載程序中的惡意“init”函數替換。

上面列出的修改後的DLL文件就是這種情況，最後一個序號的導出函數被惡意的“init”函數替換。

6.png

IcedID修改（左）和正常（右）文件的比較，其中前者在最後一個序號的導出函數被惡意的“init”函數替換

進一步調查表明，該文件的結構是相同的。

7.png

IcedID修改文件和普通文件的比較，其中兩個文件顯示相同的結構

執行“MsiExec.exe”執行（父進程）(MITRE ID T1218.007 - System Binary Proxy Execution: msiexec)；

生成“rundll32.exe” (MITRE ID T1218.011 - System Binary Proxy Execution: rundll32.exe)；

“rundll32.exe”通過“zzzzInvokeManagedCustomActionOutOfProc”(MITRE ID T1218.011 - System Binary Proxy Execution: rundll32.exe)運行自定義操作“Z3z1Z”；

自定義操作生成第二個“rundll32.exe”以運行帶有“init”導出函數(MITRE IDs T1027.009 - Embedded Payloads and T1218.011 - System Binary Proxy Execution: rundll32.exe)的IcedID加載程序“MSI3480c3c1.msi”。

8.png

IcedID加載程序執行鏈

9.png

MSI自定義操作

10.png

包含自定義操作的MSI結構

總結IcedID是一個值得注意的惡意軟件家族，能夠傳播其他有效負載，包括Cobalt Strike和其他惡意軟件。 IcedID使攻擊者能夠執行具有高度影響力的後續攻擊，從而導致整個系統被破壞，例如竊取數據和使用勒索攻擊癱瘓整個系統。惡意廣告和規避加載程序的使用都在提醒我們部署分層安全解決方案的重要性，包括自定義沙箱、預測性機器學習、行為監控以及文件和網絡聲譽檢測功能。終端用戶還可以考慮使用廣告攔截器來阻止惡意攻擊。

HireHackking

場景導入目前IAST應用環境中，Java應用佔據了90%以上。傳統IAST對Java應用進行Agent安裝時，需要修改Tomcat、WebLogic等的啟動腳本，增加javaagent參數來實現Agent的安裝加載。

對於安裝人員來說，Agent安裝需要知悉Web容器的安裝路徑，並且需要對每個容器的啟動腳本進行修改，最後重啟Web容器，完成Agent的安裝。

在實際的使用過程中，部署人員常常由於腳本修改不當、找不到Web容器等問題導致安裝失敗。除此之外，當團隊需要對幾百上千個應用進行安裝測試時，對安裝人員來說將是一項異常艱鉅的任務。此外，若後期需要對Agent進行升級或者卸載操作也將是一場運維災難。

Agent部署技術基礎JDK從1.5版本開始引入了java.lang.instrument包，可以通過其更方便地實現字節碼增強。核心功能由java.lang.instrument.Instrumentation提供，這個接口的方法提供了註冊類文件轉換器、獲取所有已加載的類等功能，允許對已加載和未加載的類進行修改。

在JDK5中，開發人員只能在JVM啟動時指定一個java agent，在premain中操作字節碼，這種Instrumentaion方式僅限於main方法執行前，存在很大的局限性。從JDK6開始引入了動態Attach Agent的方案，可以在JVM啟動後任意時刻遠程加載Agent，jstack、jps、jmap等工具都是利用Attach API來實現的。

Instrumentation的第一種使用方式是通過JVM的啟動參數-javaagent來啟動，一個典型的使用方式如下所示:

1.png

在SecPoint.jar中，AgentMain類有一個靜態的premain方法，JVM在類加載時會先執行AgentMain類的premain方法，再執行Java應用本身的main方法。在premain方法中可以對class文件進行修改。這種字節碼修改的方式並不會對源代碼做任何修改，但是可以實現對JVM中的類的動態修改和增強，從而捕獲應用程序的數據傳播過程。

Instrumentation的第二種方式是在JVM運行以後在任意時刻通過Attach API遠程加載Agent的jar包。在啟動時加載的Agent會調用premain方法，動態Attach的Agent會執行agentmain方法。 Attach的發起端是一個獨立的java程序，這個java程序會調用`VirtualMachine.attach`方法開始和目標JVM進行跨進程通信，從而實現字節碼增強。

安全玻璃盒經驗目前，【安全玻璃盒】孝道科技IAST為了滿足真實場景下大規模部署的場景，針對Java Agent的安裝方式做了多種方式的功能實現，使得用戶能夠根據實際需求靈活選擇部署方式，盡可能將Agent安裝過程自動化，減輕部署及後續運維的工作量。

1.手動java agent部署這種方式即為傳統的javaagent部署方式，首先需要將Agent下載至應用服務器中，之後修改對應Web容器的啟動腳本（例如，tomcat需要修catalina.sh或者catalina.bat），在指定位置添加javaagent等參數後重啟容器即可完成安裝部署。

2.png

2.自動java agent部署該方式由安裝人員或者在後台指定Web容器的位置，並Agent下載至應用服務器後，通過使用“install”參數啟動Agent後，將自動修改Web容器啟動腳本中的啟動腳本，在其中添加對應的參數。例如：

3.png

3.Attach部署Attach部署方式需要JDK6以上版本，並且需要服務器中具備JDK環境（JRE不包含tools.jar和attach.so）。將Agent下載至應用服務器後，通過啟動Agent並選擇需要綁定的java進程，即可針對指定java服務完成Agent安裝部署。

4.png

4.一鍵腳本部署自動化腳本的方式能夠通過統一的腳本實現對不同應用環境的Java服務進行Agent部署安裝，當在應用服務器運行腳本後，能夠自動從後台服務器下載Agent至服務器中，並自動對java進行進行Attach安裝。該方式對於大規模部署及容器等環境極為適用。

HireHackking

在這個挑戰中，我們被賦予了運行在hypervisor中的linux虛擬機的root權限，目標是實現hypervisor逃逸，以訪問宿主機系統上的旗標文件。在這個過程中，我們發現了多個安全漏洞，通過它們可以實現lkvm的零日攻擊，使得具有虛擬機訪問權限的攻擊者能夠在宿主機上執行任意命令。

在這篇文章中，當提到行號時，請參考kvmtool的git checkout 39181fc6429f4e9e71473284940e35857b42772a。

攻擊面由於我們是在hypervisor內運行，並且宿主機和虛擬機內存之間實現了顯式的隔離，因此，我們需要找到一種方法與宿主機的進程進行通信。實際上，我們可以通過pci與宿主機進行通信，因為Lkvm通過pci模擬了3個硬件設備：virtio-console、virtio-net和virtio-balloon。我們可以使用內存映射的IO與這些設備進行交互，也就是對特定的物理內存地址進行讀取和寫入操作。如果我們對0xd2000000-0xd20000ff(balloon-virtio)範圍內的地址進行寫操作，虛擬機就會被中斷，並且控制流將被傳遞給linux系統的kvm驅動程序，然後進一步傳遞給lkvm進程。

信息洩露當從這個地址執行讀取操作時，我們首先遇到的一個函數是virtio/pci.c第148行的virtio_pci__data_in函數：

image.png

該函數可以將偏移量映射為bar（地址範圍），這意味著，如果我們在地址0xD2000000+VIRTIO_PCI_QUEUE_NUM==0xD2000008處執行讀取操作，我們將進入第二個case子句。需要注意的是，這裡的默認case子句非常有趣：在第118行調用virtio_pci__specific_data_in：

image.png

在這裡，我們總是以else if的case子句結束，因為這不是MSIX操作。另外，config_offset是根據從virtio_pci__data_in傳遞的偏移量來計算的，我們看到它具有完整的訪問權限，並且沒有進行任何綁定檢查。並且，config_offset的值是在調用virtio__get_dev_specific_field時作為返回參數進行計算的。如果我們沒有執行MSIX操作，config_offset就是設置為傳遞給virtio__get_dev_specific_field的第一個參數的值，其偏移量為-20。

到目前為止，我們只討論了virtio和pci泛型函數，但這裡調用了ops-get_config，在本例中，它從balloon驅動程序中提取了u8*配置。這個函數只是一個簡單的getter，代碼如下所示：

image.png

正如我們在下面所看到的，virtio_balloon_config是結構體的最後一個元素；讀者可能已經註意到了，config結構體非常小。由於bar（地址範圍）為0x100(0xD2000000-0xD20000FF)，因此，只要將偏移量設置為大於20，我們就能以0x10020+sizeof(virtio_balloon_config)的形式訪問這個config結構體。在這個地址範圍內執行寫入操作時，相當於對config結構體執行寫操作，這意味著我們獲得了一個越界讀/寫原語。

image.png

這段內存並沒有分配在堆棧上，而是分配到一個mmaped區域中。這意味著我們無法通過破壞這個內存區來控製程序流。但是，我們能夠利用這個漏洞來洩露信息，即洩露兩個感興趣的指針，其中一個指向bln_dev結構體本身的地址，另一個指向lkvm二進製文件的基址。

為了在用戶空間進程中洩漏這兩個指針，我們可以使用/dev/mem來訪問虛擬機的物理內存，具體代碼如下所示：

image.png

這裡，leak_u64使用ioread8從virtio-balloon所在的0xD2000000處的mmap/dev/mem區域讀取數據。我們將這20個字節加上一個越界的偏移量，使其正好指向lkvm可執行文件的地址，這樣我們就能實現信息洩漏了。對於bln_dev洩漏，我們可以重複相同的過程。

獲得程序流程的控制權現在終於到了最有趣的部分：控制rip。假如我們能利用前面的漏洞來編寫任意的越界代碼，那麼，我們可以破壞哪些有趣的數據呢？在下圖中，我在virtio_pci__specific_data_in函數中設置了一個斷點來檢查bln_dev內存。在這裡，我轉儲了位於config結構體後面的內存內容。其中，我們看到一些名為exit_lists的結構體，不幸的是，由於我們可以突破0x100的限制，所以，這些結構體都是可達的。但這些到底是什麼？

1.png

由於virtio_pci__specific_data_in中的偏移量-20導致轉儲不是0x10對齊的，所以地址可能會有點亂

當lkvm二進製文件關閉時，它會進行拆卸處理，包括調用一些退出處理程序，這就是我們在這裡發現的東西。如果我們查看init.c內部的第51行，我們會發現代碼非常平易近人：

image.png

這裡可以看到，在退出lkvm時，會遍歷struct init_item數組，並從數組中的最後一個元素開始，對每個元素調用t-init函數。這就是前面發現的exit_lists。列表中的每個條目都是指向init_item的指針（該結構體也用於初始化，它也因此得名）。如果我們能夠控制其中的指針，我們就就能偽造一個init_item，並在終止虛擬機操作系統時改變程序流程。

image.png

查看上面init_item的struct定義，我們就會發現它其實非常簡單：其中包含2個鍊錶指針、一個名稱指針和我們想要控制的函數指針，它相對於init_item頂部的偏移量為0x18。

實際上，我們之前在virtio_pci__data_in函數中還發現了其他功能，而不僅僅是對config進行讀取和寫入操作。下面，讓我們看一下virtio/pci.c第287行中該函數的等價物data_out：

image.png

這裡，我們對VIRTIO_PCI_QUEUE_PFN的第二個case子句非常感興趣，因為它調用了virtio-balloon特定的init虛擬隊列函數。我們可以在virtio/balloon.c中的第200行找到這個函數，具體如下所示：

image.png

正如我們所看到的，當調用vring_init時，它將vr-desc=p設置為完全處於我們控制之下的虛擬機物理頁面。我們可以看到，vring_init是從init_vq中調用的，參數是p，而p是從virtio_get_vq中獲得的，在那裡它可以找到給定頁幀號（pfn）的宿主機虛擬地址。在init_vq中，我們看到參數vq被用來計算進入bdev-vqs數組的偏移量。這個queue=bdev-vqs[vq]; 語句又是完全沒有任何約束檢查的，儘管在任何給定時間只有3個隊列。這意味著，只要控制了vq參數，我們就可以有效地插入一個指向虛擬機內存的邊界之外的指針。

在virtio_pci__data_out的代碼清單中，對init_vq的調用是作為vq的參數通過vpci-queue_selector進行傳遞的，在同一個清單中，我們還發現完全可以通過switch語句中的VIRTIO_PCI_QUEUE_SEL子句來控制vpci-queue_selector。

通過下面vring*vr的結構體定義，我們可以看到它有4個成員，大小為0x20，這意味著我們不能在任意位置插入這個指針。實際上，只有在偏移量0x20*x+8處，我們才能完全控制x。

image.png

大家肯定還記得，我們的exit_lists離這個bdev結構體的位置並不遠，而且，現在我們還獲得了一個未綁定的、指示插入位置的指針，所以，我們只要將vq設置為0x16，那麼，我們就能在這個exit_lists的最後一個條目中插入這個指針，具體代碼如下所示：

image.png

這裡，我們將頁幀號設置為0x1，這表示虛擬機物理地址0x1000，並再次使用/dev/mem，將物理地址0x1000映射為我們具有讀寫權限的用戶空間進程中的一個地址。顯然，以任何正常的方式重新引導或退出虛擬機操作系統，都不會調用這些退出處理程序，但幸運的是，在未定義的指令導致內核崩潰時，卻會調用這些程序。哈哈，大家還記得echo c /proc/sysrq-trigger嗎？

退出前的內存轉儲：

1.png

0x41代表字母A

這裡我們看到，所有從上面的memset插入的“A”，都出現在exit_lists+72內的地址上。很明顯，我們現在已經控制了程序流程，因為t-init(kvm)調用的這個地址完全處於我們的控制之下。既然已經得到了控制權，我們自然就可以重定向程序流程了。

現在，我們需要將代碼重定向到一個目標，以便在宿主機系統上執行代碼或命令，幸運的是，這個二進製文件含有返回函數virtio_net_exec_script的ret gadget：

1.png

超級好用的ret gadget

現在，如果我們能夠控制$rdi寄存器並跳轉到virtio_net_exec_script中用紅色箭頭標記的指令，就可以成功調用execl(command_we_control,），從而在宿主機系統上執行命令。

綜合起來現在，我們已經能夠偽造init_item，啟動調用exevl的ROP鏈，或者說是JOP鏈，接下來，我們將藉助於Jump oriented programming技術實現我們的目標。總而言之，我們現在利用第一個安全漏洞實現了指針洩露，並能控制該內存區域中一些字節的值，因為我們可以在洩漏的內區域中隨意執行寫入操作。同時，我們還找到了一種控制rip的方法，但遺憾的是，我們還無法控制函數調用t-init(kvm)中的參數kvm。

當我們第一次調用t-init時，$rbx指向我們偽造的init_item，也就是處於我們的控制之下的一段內存。

首先，我們要跳到這個gadget： mov rax, qword ptr [rbx +0x28]; mov rdi, rbx; mov rsi, qword ptr [rax + 8]; call qword ptr [rax];

這將交換rbx和rdi寄存器中的值，使我們能夠控制任何函數調用的第一個參數，並再次通過[$rbx +0x28]獲取一個新的跳轉位置。

現在，我們可以直接跳到前面介紹的那個超級棒的gadget代碼處了，因為我們現在能夠控制$rdi了。

1.png大功告成

現在，代碼將調用execl('/bin/sh', '', null);並返回一個shell！我們已經為這個漏洞申請了編號CVE-2021-45464，目前正在等待批准。至於完整的exploit，請參考原文末尾；但要注意的是，對於所有版本的lkvm來說，必須對利用代碼進行相應的修改：根據特定的二進制代碼修改gadget的偏移量。

HireHackking

5.3. 立即關閉應用程序HTTP/3實現可以在任何時候立即關閉QUIC連接。這將導致向對等方發送一個QUIC CONNECTION_CLOSE幀，這表明應用層已經終止了連接。此幀中的應用程序錯誤代碼向對等方表明連接被關閉的原因。有關在HTTP/3 中關閉連接時可以使用的錯誤代碼，請參閱第8 節。

在關閉連接之前，可能會發送一個GOAWAY 幀以允許客戶端重試某些請求。將GOAWAY幀包含在與QUIC CONNECTION_CLOSE幀相同的包中可以提高客戶端接收幀的機會。

如果存在未明確關閉的打開流，則在關閉連接時將其悄悄關閉。

5.4. 運輸關閉由於各種原因，QUIC傳輸可以向應用層表明連接已經終止。這可能是由於對等方明確地關閉、傳輸層錯誤或中斷連接的網絡拓撲變化造成的。

如果連接在沒有GOAWAY幀的情況下終止，客戶端必須假定發送的任何請求，無論是全部的還是部分的，都可能已經被處理。

6. 流映射和使用QUIC流提供可靠的字節按順序傳遞，但不保證與其他流上的字節的傳遞順序。在QUIC的版本1中，包含HTTP幀的流數據由QUIC stream幀承載，但是這個幀對HTTP幀層是不可見的。傳輸層對接收到的流數據進行緩沖和排序，向應用程序公開可靠的字節流。雖然QUIC允許在流中無序傳遞，但HTTP/3 並未使用此功能。

QUIC 流可以是單向的，僅從發起者到接收者傳輸數據，也可以是雙向的，雙向傳輸數據。流可以由客戶端或服務器發起。

當通過QUIC 發送HTTP 字段和數據時，QUIC 層處理大部分流管理。使用QUIC 時，HTTP 不需要進行任何單獨的多路復用，通過QUIC 流發送的數據總是映射到特定的HTTP 事務或整個HTTP/3 連接上下文。

6.1雙向流所有客戶端發起的雙向流都用於HTTP請求和響應。雙向流確保響應可以很容易地與請求相關聯。這些流稱為請求流。

這意味著客戶端的第一個請求發生在QUIC流0上，隨後的請求發生在流4、流8等流中。為了允許這些流打開，HTTP/3服務器應該為允許的流數量和初始流控制窗口配置非零的最小值。為了避免不必要地限制並行性，一次至少應該允許100個請求流。

HTTP/3不使用服務器發起的雙向流，儘管擴展可以定義這些流的用途。客戶端必須將接收到服務器發起的雙向流作為H3_STREAM_CREATION_ERROR類型的連接錯誤，除非已經協商了這樣的擴展。

6.2單向流任意一個方向的單向流都可用於不同的用途。其目的由流類型表示，該流類型在流的開頭作為可變長度整數發送。這個整數後面的數據的格式和結構由流類型決定。

1.png

單向流標頭

HTTP/3連接在其生命週期的早期階段的性能對單向流上的數據創建和交換非常敏感。過度限制流的數量或這些流的流控制窗口的終端將增加遠程對等方提前達到限制並被阻止的機會。特別是，實現應該考慮遠程對等方可能希望使用他們被允許使用的一些單向流來執行保留的流行為。

每個終端都需要為HTTP控制流創建至少一個單向流。 QPACK需要兩個額外的單向流，而其他擴展可能需要更多的流。因此，客戶端和服務器端發送的傳輸參數必須允許對等方創建至少三個單向流。這些傳輸參數還應該為每個單向流提供至少1024字節的流量控制信用。

請注意，如果終端在創建關項單向流之前消耗了所有初始信用，則不需要授予額外信用來創建更多單向流。終端應該首先創建HTTP 控制流以及強制擴展所需的單向流（例如QPACK 編碼器和解碼器流），然後在其對等方允許的情況下創建其他流。

如果流標頭是接收方不支持的流類型，則無法使用流的其餘部分，因為語義未知。未知流類型的接收者必須中止讀取流或刪除傳入數據而不進行進一步處理。如果讀取被中止，接收者應該使用H3_STREAM_CREATION_ERROR 錯誤代碼或保留的錯誤代碼。接收者不得將未知流類型視為任何類型的連接錯誤。

由於某些流類型會影響連接狀態，因此接收者不應在讀取流類型之前刪除來自傳入單向流的數據。

實現可以在知道對等方是否支持它們之前發送流類型。但是，可以修改現有協議組件（包括QPACK 或其他擴展）的狀態或語義的流類型，在知道對等方支持它們之前，絕對不能發送。

除非另有說明，否則發送者可以關閉或重置單向流。接收者必須容忍單向流在接收到單向流標頭之前被關閉或重置。

6.2.1 控制流控制流由0x00流類型表示。該流上的數據由HTTP/3幀組成。

每一方必須在連接開始時初始化一個控制流，並將其SETTINGS幀作為該流的第一幀發送。如果控制流的第一幀是任何其他幀類型，則必須作為H3_MISSING_SETTINGS類型的連接錯誤處理。每個對等方只允許一個控制流；接收到第二個聲稱是控制流的流必須作為H3_STREAM_CREATION_ERROR類型的連接錯誤處理。發送方絕對不能關閉控制流，接收方也絕對不能請求發送方關閉控制流。如果任何一個控制流在任何時候被關閉，這必須作為h3_close_critical_stream類型的連接錯誤處理。

由於控制流的內容用於管理其他流的行為，終端應該提供足夠的流控制信用來防止對等方控制流被阻止。

使用一對單向流而不是一個雙向流。這允許任何一方能夠盡快發送數據。根據QUIC連接上是否有0-RTT，客戶端或服務器都可以首先發送流數據。

6.2.2 push stream服務器推送是HTTP/2中引入的一個可選特性，它允許服務器在請求發出之前發起響應。 push stream由流類型0x01指示，後面是它所實現的承諾的Push ID，編碼為可變長度整數。該流上的剩餘數據由HTTP/3幀組成，並通過零個或多個臨時HTTP響應，以及隨後的單個最終HTTP 響應來實現承諾的服務器推送。只有服務器可以推送，如果服務器接收到客戶端發起的push stream，則必須將其視為H3_STREAM_CREATION_ERROR 類型的連接錯誤。

2.png

push stream標頭

客戶端不應在讀取push stream標頭之前中止對push stream的讀取，因為這可能導致客戶端和服務器之間在已使用推送ID 的情況下出現分歧。

每個Push ID只能在push stream標頭中使用一次。如果客戶端檢測到一個push stream標頭包含在另一個push stream標頭中使用的Push ID，客戶端必須將其作為H3_ID_ERROR類型的連接錯誤處理。

6.2.3 保留流類型對於N 的非負整數值，格式為0x1f * N +0x21 的流類型被保留以執行忽略未知類型的要求。這些流沒有語義，可以在需要應用層填充時發送。它們也可以在當前沒有數據傳輸的連接上發送。終端在接收時絕對不能認為這些流有任何意義。

以發送實現選擇的任何方式選擇流的有效負載和長度。當發送保留流類型時，實現可以乾淨地終止流或重置流。當重置流時，應該使用H3_NO_ERROR錯誤碼或保留錯誤碼。

7. HTTP幀層如上所述，HTTP幀在QUIC流上傳輸。 HTTP/3定義了三種流類型：控制流、請求流和push stream。本節介紹HTTP/3 幀格式及其允許的流類型。

3.png

HTTP/3幀和流類型概述

SETTINGS幀只能作為控制流的第一幀出現，從表1(1)中可以看出。請注意，與QUIC幀不同，HTTP/3幀可以跨越多個數據包。

7.1 幀佈局所有幀都具有以下格式：

4.png

HTTP/3幀格式

每個幀包括以下字段：

類型：標識幀類型的可變長度整數。

長度：一個可變長度整數，用於描述幀有效負載的長度（以字節為單位）。

幀載荷：有效負載，其語義由Type 字段確定。

每個幀的有效負載必須準確包含在其描述中標識的字段。在已識別字段之後包含附加字節的幀有效載荷或在已識別字段結束之前終止的幀有效載荷必須被視為H3_FRAME_ERROR 類型的連接錯誤。特別是，冗余長度編碼必須經過驗證是自洽的。

當流完全終止時，如果流上的最後一幀被截斷，則必須將其視為H3_FRAME_ERROR 類型的連接錯誤。突然終止的流可以在幀中的任何點重置。

7.2 幀的定義7.2.1 數據DATA 幀(type=0x00) 傳送與HTTP 請求或響應內容相關的任意可變長度字節序列。

DATA 幀必須與HTTP 請求或響應相關聯。如果在控制流上接收到DATA 幀，接收者必須以H3_FRAME_UNEXPECTED 類型的連接錯誤進行響應。

5.png

數據幀

7.2.2 標頭HEADERS 幀(type=0x01) 用於攜帶使用QPACK 編碼的HTTP 字段部分。

6.png

標頭幀

HEADERS 幀只能在請求流或push stream上發送。如果在控制流上接收到HEADERS 幀，則接收者必須以H3_FRAME_UNEXPECTED 類型的連接錯誤進行響應。

7.2.3 CANCEL_PUSHCANCEL_PUSH 幀（類型=0x03）用於在接收push stream之前請求取消服務器推送。 CANCEL_PUSH 幀通過推送ID（參見第4.6 節）標識服務器推送，編碼為可變長度整數。

當客戶端發送一個CANCEL_PUSH幀時，它表示不希望接收承諾的資源。服務器應該中止發送資源，但是這樣做的機制取決於相應的push stream的狀態。如果服務器還沒有創建push stream，它就不會創建push stream。如果push stream是打開的，服務器應該突然終止該流。如果push stream已經結束，服務器仍然可以突然終止流或不採取任何行動。

服務器發送一個CANCEL_PUSH幀來表明它不會履行先前發送的承諾。客戶端不能期望相應的承諾得到實現，除非它已經接收並處理了承諾的響應。無論是否打開了push stream，當服務器確定承諾不會被履行時，它應該發送一個CANCEL_PUSH 幀。如果流已經打開，服務器可以中止在流上發送，錯誤代碼為H3_REQUEST_CANCELLED。

發送CANCEL_PUSH 幀對現有push stream的狀態沒有直接影響。當客戶端已經接收到相應的push stream時，它不應該發送CANCEL_PUSH 幀。在客戶端發送CANCEL_PUSH 幀後，push stream可能會到達，因為服務器可能尚未處理CANCEL_PUSH。客戶端應該中止讀取流，錯誤代碼為H3_REQUEST_CANCELLED。

在控制流上發送CANCEL_PUSH 幀。在控制流以外的流上接收CANCEL_PUSH 幀必須被視為H3_FRAME_UNEXPECTED 類型的連接錯誤。

7.png

CANCEL_PUSH幀

CANCEL_PUSH 幀攜帶一個編碼為可變長度整數的Push ID。 Push ID字段標識正在被取消的服務器推送。如果接收到的CANCEL_PUSH幀引用了一個大於當前連接允許的push ID，這必須作為H3_ID_ERROR類型的連接錯誤處理。

如果客戶端收到CANCEL_PUSH 幀，則該幀可能會標識由於重新排序而尚未被PUSH_PROMISE 幀提及的推送ID。如果服務器接收到一個尚未被PUSH_PROMISE 幀提及的推送ID 的CANCEL_PUSH 幀，則必須將其視為H3_ID_ERROR 類型的連接錯誤。

7.2.4 設置SETTINGS 幀(type=0x04) 傳遞影響終端通信方式的配置參數，例如對對等行為的偏好和約束。單獨地，一個SETTINGS 參數也可以稱為'setting'；每個SETTINGS參數的標識和值可以稱為“設置標識”和“設置值”。

SETTINGS 幀始終適用於整個HTTP/3 連接，而不是單個流。 SETTINGS 幀必須作為每個控制流的第一幀被每個對等方發送，並且不得隨後發送。如果終端在控制流上接收到第二個SETTINGS 幀，終端必須以H3_FRAME_UNEXPECTED 類型的連接錯誤響應。

SETTINGS 幀不得在控制流以外的任何流上發送。如果終端在不同的流上接收到SETTINGS 幀，終端必須以H3_FRAME_UNEXPECTED 類型的連接錯誤響應。

SETTINGS 參數未協商；它們描述了接收對等方可以使用的發送對等方的特徵。但是，使用SETTINGS 可以暗示協商：每個對等方都使用SETTINGS 來發布一組支持的值。設置的定義將描述每個對等方如何組合這兩個集合以得出將使用哪個選項的結論。 SETTINGS 不提供識別選擇何時生效的機制。

每個對等方可以通告相同參數的不同值。例如，客戶端可能願意使用非常大的響應字段段，而服務器則對請求大小更加謹慎。

相同的設置標識符不能在SETTINGS 幀中出現多次。接收端可以將重複設置標識符的存在視為H3_SETTINGS_ERROR類型的連接錯誤。

SETTINGS幀的有效載荷由零個或多個參數組成。每個參數由一個設置標識符和一個值組成，它們都編碼為QUIC可變長度整數。

8.png

設置幀

一個實現必須忽略任何帶有它不理解的標識符的參數。

7.2.4.1 定義SETTINGS參數HTTP/3 中定義了以下設置：

SETTINGS_MAX_FIELD_SECTION_SIZE (0x06)：

默認值為無限制。

為N 的非負整數值設置格式為0x1f * N +0x21 的標識符被保留以執行忽略未知標識符的要求。此類設置沒有明確的含義。終端應該在其SETTINGS幀中包含至少一個這樣的設置。終端絕對不能認為這些設置在接收時有任何意義。

由於該設置沒有定義的含義，因此該設置的值可以是實現選擇的任何值。

在[HTTP/2]中定義的設置標識符沒有對應的HTTP/3設置也被保留。這些保留的設置絕對不能發送，並且它們的接收必須作為H3_SETTINGS_ERROR類型的連接錯誤處理。

其他設置可以通過HTTP/3 的擴展來定義。

7.2.4.2 初始化HTTP實現絕對不能發送基於當前對對等方設置的理解而無效的幀或請求。

所有設置都從初始值開始。每個終端應該使用這些初始值在對等方的SETTINGS幀到達之前發送消息，因為攜帶設置的數據包可能會丟失或延遲。當SETTINGS幀到達時，任何設置都將被更改為新的值。

這樣就不需要在發送消息之前等待SETTINGS幀。在發送SETTINGS幀之前，終端絕對不能要求從對等方接收任何數據，必須在傳輸準備好發送數據後立即發送設置。

對於服務器，每個客戶端設置的初始值都是默認值。

對於使用1-RTT QUIC連接的客戶端，每個服務器設置的初始值都是缺省值。 1-RTT項在包含設置的包被QUIC處理之前總是可用的，即使服務器立即發送SETTINGS 也是如此。客戶端不應該在發送請求之前無限期地等待SETTINGS 到達，但他們應該處理接收到的數據報以增加在發送第一個請求之前處理SETTINGS 的可能性。

當使用0-RTT QUIC連接時，每個服務器設置的初始值都是上一個會話中使用的值。客戶端應該存儲服務器在HTTP/3連接中提供的恢復信息的設置，但在某些情況下，他們可以選擇不存儲設置(例如，如果會話票據在SETTINGS幀之前收到)。當嘗試0-RTT時，客戶端必須遵守存儲的設置，如果沒有存儲值，則使用默認值。一旦服務器提供了新的設置，客戶端必須遵守這些值。

服務器可以記住它發布的設置，或存儲票據中值的完整性保護副本，並在接受0-RTT數據時恢復信息。服務器使用HTTP/3設置值來決定是否接受0-RTT數據。如果服務器不能確定客戶端記住的設置與它的當前設置是兼容的，它絕對不能接受0-RTT數據。如果符合這些設置的客戶端不會違反服務器的當前設置，則記住的設置是兼容的。

服務器可以接受0-RTT並隨後在其SETTINGS幀中提供不同的設置。如果0-RTT數據被服務器接受，它的SETTINGS幀絕對不能減少任何限製或改變任何可能被客戶端與它的0-RTT數據違反的值。服務器必須包括與其默認值不同的所有設置。如果服務器接受0-RTT，但隨後發送的設置與之前指定的設置不兼容，則必須將其視為H3_SETTINGS_ERROR 類型的連接錯誤。如果服務器接受0-RTT 但隨後發送的SETTINGS 幀忽略了客戶端理解的設置值（除了保留的設置標識符），該設置值之前指定為具有非默認值，則必須將其視為連接錯誤輸入H3_SETTINGS_ERROR。

7.2.5 PUSH_PROMISEPUSH_PROMISE 幀（類型=0x05）用於在請求流中從服務器到客戶端攜帶承諾的請求標頭部分。

8.png

PUSH_PROMISE 幀

有效載荷包括：

PUSHID：一個可變長度的整數，用於標識服務器推送操作。 Push ID用於push stream標頭和CANCEL_PUSH幀。

服務器絕對不能使用比客戶端提供的MAX_PUSH_ID幀大的Push ID。客戶端收到推送承諾幀時，如果推送承諾幀的ID大於客戶端發布的Push ID，則必須將其視為連接錯誤H3_ID_ERROR。

一個服務器可以在多個推送承諾幀中使用相同的Push ID。如果是這樣，解壓後的請求標頭集必須包含相同順序相同的字段，並且每個字段的名稱和值必須完全匹配。客戶端應該多次比較請求標頭部分以獲得承諾的資源。如果客戶端收到一個已經承諾的Push ID，並且檢測到不匹配，它必須響應一個H3_GENERAL_PROTOCOL_ERROR類型的連接錯誤。如果解壓後的字段部分完全匹配，客戶端應該將推送內容與每一個接收到推送承諾幀的流關聯起來。

允許重複引用相同的Push ID主要是為了減少並發請求造成的重複。服務器應該避免長時間重複使用Push ID。客戶端很可能使用服務器推送響應，而不保留它們以供重用。當客戶端看到一個推送承諾幀使用了一個他們已經使用並刪除的Push ID時，會被迫忽略這個承諾。

如果在控制流上接收到推送承諾幀，客戶端必須響應一個H3_FRAME_UNEXPECTED類型的連接錯誤。

客戶端不能發送PUSH_PROMISE幀。服務器必須將接收到的PUSH_PROMISE幀作為H3_FRAME_UNEXPECTED類型的連接錯誤處理。

關於整個服務器推送機制的描述，請參見4.6節。

7.2.6 關閉GOAWAY幀(type=0x07)用於啟動HTTP/3連接的任意終端的安全關閉。 GOAWAY 允許終端停止接受新請求或推送，同時仍完成對先前接收到的請求和推送的處理。這將啟用管理操作，例如服務器維護。 GOAWAY 本身不會關閉連接。

9.png

GOAWAY幀

GOAWAY幀總是在控制流上發送。在服務器到客戶端的方向上，它攜帶客戶端發起的雙向流的QUIC 流ID，編碼為可變長度整數。客戶端必須將接收到包含任何其他類型的流ID 的GOAWAY 幀視為H3_ID_ERROR 類型的連接錯誤。

在客戶端到服務器的方向上，GOAWAY幀攜帶一個被編碼為變長整數的Push ID。

GOAWAY幀適用於整個連接，而不是特定的流。客戶端必須將控制流以外的流上的GOAWAY幀作為H3_FRAME_UNEXPECTED類型的連接錯誤處理。

關於GOAWAY幀的更多信息請參見5.2節。

7.2.7 MAX_PUSH_IDMAX_PUSH_ID幀(type=0x0d)被客戶端用來控制服務器可以發起的服務器推送的數量。這設置了服務器可以在PUSH_PROMISE和CANCEL_PUSH幀中使用的Push ID的最大值。因此，除了由QUIC傳輸維持的限制外，這也限制了服務器可以發起的push stream的數量。

MAX_PUSH_ID幀總是在控制流上發送。在任何其他流上接收到MAX_PUSH_ID幀必須作為H3_FRAME_UNEXPECTED類型的連接

HireHackking

10. 安全注意事項HTTP/3的安全考慮應該與使用TLS的HTTP/2相當。然而，[HTTP/2] 第10 節中的許多注意事項適用於[QUIC-TRANSPORT]。

10.1. 服務器權限HTTP/3依賴於HTTP對權限的定義。建立權限時的安全考慮在[HTTP]第17.1節中進行討論。

10.2 跨協議攻擊在TLS 和QUIC 握手中使用ALPN 在處理應用層字節之前建立目標應用協議。這確保了終端有強有力的保證，即對等方使用相同的協議。

這並不能保證免受所有跨協議攻擊。我們會在[QUIC- transport]中描述一些方法，可以使用QUIC 數據包的明文對不使用經過身份驗證的傳輸的終端執行請求偽造的方法。

10.3. 中間封裝（Intermediary-Encapsulation）攻擊HTTP/3 字段編碼允許在HTTP 使用的語法中表達不是有效字段名稱的名稱（[HTTP] 的第5.1 節）。包含無效字段名稱的請求或響應必須被視為格式錯誤。因此，中介無法將包含無效字段名稱的HTTP/3 請求或響應轉換為HTTP/1.1 消息。

同樣，HTTP/3 可以傳輸無效的字段值。雖然大多數可以編碼的值不會改變字段解析，但如果逐字翻譯，攻擊者可能會利用回車符(ASCII0x0d)、換行符(ASCII0x0a) 和空字符(ASCII0x00)。任何包含字段值中不允許的字符的請求或響應都必須被視為格式錯誤。有效字符由[HTTP] 第5.5 節中的“field-content”ABNF 規則定義。

10.4 推送響應的可緩存性推送響應沒有來自客戶端的明確請求，請求是由服務端在PUSH_PROMISE幀中提供的。

根據原始服務器在Cache-Control 標頭字段中提供的指導，可以緩存推送的響應。但是，如果一台服務器託管多個租戶，這可能會導致問題。例如，服務器可能會為多個用戶提供其URI 空間的一小部分。

當多個租戶共享同一服務器上的空間時，該服務器必須確保租戶無法推送他們無權訪問的資源的表示。未能強制執行此操作將允許租戶提供將在緩存之外提供的表示，從而覆蓋權威租戶提供的實際表示。

要求客戶端拒絕原始服務器不具有權威性的推送響應（見第4.6 節）。

10.5 拒絕服務注意事項與HTTP/1.1 或HTTP/2 連接相比，HTTP/3 連接可能需要更大的資源承諾才能運行。字段壓縮和流量控制的使用取決於用於存儲更多狀態的資源的承諾。這些功能的設置可確保這些功能的內存承諾受到嚴格限制。

PUSH_PROMISE幀的數量也以類似的方式被限制。接受服務器推送的客戶端應該限制一次發送的Push ID的數量。

處理能力不能像狀態能力那樣得到有效保護。

發送對等方需要忽略的未定義協議元素的能力可能被濫用，從而導致對等方花費額外的處理時間。這可以通過設置多個未定義的SETTINGS參數、未知幀類型或未知流類型來完成。但是請注意，某些用途是完全合法的，例如可理解的擴展和填充以增加對流量分析的阻止力。

所有這些功能，例如服務器推送、未知協議元素、字段壓縮都有合法的用途。只有在不必要或過度使用時，這些功能才會成為一種負擔。

如果不監控此類行為的終端，則會使自己面臨拒絕服務攻擊。實現應該跟踪這些功能的使用，並對它們的使用設置限制。終端可以將可疑的活動視為H3_EXCESSIVE_LOAD類型的連接錯誤，但誤報將導致中斷有效連接和請求。

10.5.1 字段段大小的限制

大字段部分（第4.1 節）可能導致實現提交大量狀態。對路由至關重要的標頭字段可能出現在標頭部分的末尾，這會阻止標頭部分流傳輸到其最終目的地。這種排序和其他原因（例如確保緩存正確性）意味著終端可能需要緩衝整個標頭部分。由於字段部分的大小沒有硬性限制，一些終端可能被迫為標頭字段提交大量可用內存。

終端可以使用SETTINGS_MAX_FIELD_SECTION_SIZE（第4.2.2 節）設置來通知對等方可能適用於字段部分大小的限制。此設置只是建議性的，因此終端可以選擇發送超出此限制的字段部分，並有可能將請求或響應視為格式錯誤。此設置特定於HTTP/3 連接，因此任何請求或響應都可能遇到具有較低未知限制的躍點。中間人可以嘗試通過傳遞不同對等方提供的值來避免這個問題，但他們沒有義務這樣做。

當服務器接收到比它願意處理的更大的字段段時，可以發送一個HTTP 431(請求標頭字段太大)狀態碼([RFC6585])。客戶端可以刪除它無法處理的響應。

10.5.2 連接問題

CONNECT方法可以用於在代理上創建不成比例的負載，因為與創建和維護TCP連接相比，流的創建是相對便宜的。因此，支持CONNECT的代理在接受並發請求的數量上可能比較保守。

代理還可能會在關閉攜帶CONNECT 請求的流之後為TCP 連接維護一些資源，因為傳出TCP 連接仍處於TIME_WAIT 狀態。考慮到這一點，代理可能會在TCP 連接終止後延遲增加QUIC 流限制一段時間。

10.6 使用壓縮當秘密數據在與攻擊者控制的數據相同的上下文中被壓縮時，壓縮可以讓攻擊者恢復秘密數據。 HTTP/3 啟用字段壓縮（第4.2 節）；以下問題也適用於HTTP 壓縮內容編碼的使用，具體請參閱[HTTP] 的第8.4.1 節。

有一些針對壓縮的攻擊利用了網絡的功能(例如，[BREACH])。攻擊者誘導多個包含不同明文的請求，觀察每個請求中生成的密文的長度，當對秘密的猜測正確時，會顯示較短的長度。

在安全通道上通信的實現不得壓縮包含機密和攻擊者控制的數據的內容，除非每個數據源使用單獨的壓縮上下文。如果不能可靠地確定數據源，則不得使用壓縮。

10.7 填充和流量分析填充可用於掩蓋幀內容的確切大小，並用於緩解HTTP 中的特定攻擊，例如，壓縮內容包括攻擊者控制的明文和秘密數據的攻擊（例如，[BREACH]）。

當HTTP/2使用填充幀和其他幀中的填充字段來使連接更能阻止流量分析時，HTTP/3既可以依賴傳輸層填充，也可以使用在7.2.8節和6.2.3節中討論的保留幀和流類型。這些填充方法在填充的粒度、如何根據受保護的信息排列填充、是否在數據包丟失的情況下應用填充以及實現如何控制填充等方面產生不同的結果。

保留流類型可用於在連接空閒時提供發送流量的外觀。因為HTTP流量經常以突發的形式出現，所以可以使用明顯的流量來掩蓋這種突發的時間或持續時間，甚至看起來像是在發送恆定的數據流。然而，由於這些流量仍然是由接收方控制的流量，如果不能及時排出這些流量並提供額外的流量控制信用，可能會限制發送方發送真實流量的能力。

為了緩解依賴於壓縮的攻擊，禁用或限制壓縮可能比填充更可取。

填充方法的使用可能導致保護效果不如看上去那麼明顯。冗餘填充甚至可能適得其反。充其量，填充只會使攻擊者更難通過增加攻擊者必須觀察的幀數來推斷長度信息。錯誤實現的填充方案很容易被繞過。特別是，具有可預測分佈的隨機填充提供的保護非常少。同樣，將有效負載填充到固定大小會在有效負載大小跨越固定大小邊界時暴露信息，如果攻擊者可以控制明文，這是可能的。

10.8 幀解析一些協議元素包含嵌套的長度元素，通常以具有顯式長度的幀的形式包含可變長度整數。這可能會給粗心的實施者帶來安全風險。實現必須確保幀的長度與其包含的字段長度完全匹配。

10.9 早期的數據將0-RTT 與HTTP/3 一起使用會導致重放攻擊。當使用帶有0-RTT 的HTTP/3 時，必須應用[HTTP-REPLAY] 中的反重放緩解措施。在將[HTTP-REPLAY] 應用於HTTP/3 時，對TLS 層的引用是指在QUIC 中執行的握手，而對應用程序數據的所有引用指的是流的內容。

10.10 遷移某些HTTP實現使用客戶端地址進行日誌記錄或訪問控制。由於QUIC客戶端的地址可能會在連接期間發生變化，並且未來版本可能支持同時使用多個地址，因此此類實現將需要主動檢索客戶端的當前地址或相關地址，或者明確接受原始地址可能會更改。

10.11 隱私注意事項HTTP/3的一些特徵為觀察者提供了一個機會，可以在一段時間內關聯單個客戶端或服務器的操作。這包括設置的值，對刺激的反應時間，以及處理由設置控制的任何功能。

就這些在行為上產生可觀察到的差異而言，它們可以用作對特定客戶進行指紋識別的基礎。

HTTP/3 對使用單個QUIC 連接的偏好允許關聯用戶在站點上的活動。重用不同來源的連接允許跨這些來源的活動相關聯。

QUIC的幾個功能要求立即響應，終端可以使用它來測量對等方的延遲，在某些情況下，這可能會出現隱私洩露。

11. IANA 注意事項本文檔註冊了一個新的ALPN 協議ID（第11.1 節）並創建了管理HTTP/3 中代碼點分配的新註冊表。

11.1. 註冊HTTP/3標識字符串本文在[RFC7301]建立的“TLS 應用層協議協商(ALPN) 協議ID”註冊表中創建了一個新的HTTP/3標識註冊。

“h3”字符串標識HTTP/3；

協議：HTTP/3；

識別順序：0x680x33 ('h3')；

規格：本文件；

11.2 新註冊在本文中創建的新註冊按照[QUIC-TRANSPORT] 第22.1 節中記錄的QUIC 註冊政策運行。這些註冊表都包括[QUIC-TRANSPORT] 的第22.1.1 節中列出的通用字段集。這些註冊表出現在“超文本傳輸協議版本3 (HTTP/3)”標題下。

這些註冊表中的初始分配都被分配了永久狀態，並列出了IETF 的變更控制者和HTTP 工作組的聯繫人(ietf-http-wg@w3.org)。

11.2.1 幀類型

本文為HTTP/3幀類型代碼建立了一個註冊表。 “HTTP/3幀類型”註冊表管理62位空間。本註冊中心遵循QUIC註冊中心政策；參見11.2節。該註冊表遵循QUIC 註冊表政策；見第11.2 節。此註冊表中的永久註冊是使用規範要求策略([RFC8126]) 分配的，但0x00 和0x3f 之間的值（十六進制；包括在內）除外，這些值是使用標準操作或IESG 批准分配的，如[ RFC8126]。

雖然此註冊表與[HTTP/2] 中定義的“HTTP/2 幀類型”註冊表是分開的，但在代碼空間重疊的情況下，分配最好彼此平行。如果一個條目僅存在於一個註冊表中，則應盡一切努力避免將相應的值分配給不相關的操作。評審員可以拒絕與相應註冊表中相同值衝突的不相關註冊。

除了第11.2節中描述的常見字段外，本註冊中心的永久註冊必須包括以下字段：

幀類型：幀類型的名稱或標籤。

幀類型的規範必須包括幀佈局及其語義的描述，包括有條件存在的幀的任何部分。

下表中的條目都是由本文介紹過的。

12.png

初始HTTP/3幀類型

對於N 的非負整數值，即0x21、0x40、到0x3ffffffffffffffe，格式為0x1f * N +0x21 的每個代碼不得由IANA 分配，並且不得出現在分配值列表中。

11.2.2 SETTINGS參數

由於為HTTP/3設置了註冊表。 “HTTP/3設置”註冊表管理62位空間。該註冊表遵循QUIC 註冊表政策，具體見第11.2 節。此註冊表中的永久註冊是使用規範要求策略([RFC8126]) 分配的，但0x00 和0x3f 之間的值（十六進制；包括在內）除外，這些值是使用標準操作或IESG 批准分配的，如[ RFC8126]。

雖然此註冊表不同於[HTTP/2] 中定義的“HTTP/2 設置”的註冊表，但最好是這些分配彼此並行。如果一個條目僅存在於一個註冊表中，則應盡一切努力避免將相應的值分配給不相關的操作。評審員可以拒絕與相應註冊表中相同值衝突的不相關註冊。

除了第11.2 節中描述的通用字段外，此註冊表中的永久註冊必須包括以下字段：

設置名稱：設置的符號名稱，指定設置名稱是可選的。

默認值：該設置的值，除非另有說明。默認值應該是最具限制性的值。

13.png

初始HTTP/3設置

出於格式原因，可以通過刪除'SETTINGS_'前綴來簡化設置名稱。

對於N 的非負整數值（即0x21、0x40、到0x3ffffffffffffffe），格式為0x1f * N +0x21 的每個代碼不得由IANA 分配，並且不得出現在分配值列表中。

11.2.3 錯誤代碼

已經建立了HTTP/3錯誤碼的註冊表。 “HTTP/3錯誤碼”註冊表管理一個62位的空間。該註冊中心遵循QUIC註冊中心政策。此註冊表中的永久註冊使用規範要求策略([RFC8126])分配，但0x00 和0x3f 之間的值（十六進制包括在內）除外，這些值是使用標準操作或IESG 批准分配的。

錯誤代碼的註冊需要包含錯誤代碼的描述，建議審閱者檢查新註冊是否可能與現有錯誤代碼重複。鼓勵使用現有註冊，但不是強制性的。不鼓勵使用在“HTTP/2 錯誤代碼”註冊表中註冊的值，專家審閱者可能會拒絕此類註冊。

除了第11.2節中描述的通用字段外，這個註冊表還包括兩個附加字段。在本註冊中心的永久註冊必須包括以下字段：

名稱：錯誤代碼的名稱。

描述：錯誤代碼語義的簡要描述。

下表中的條目是本文所介紹的。這些錯誤代碼是從對規範要求策略運行的範圍中選擇的，以避免與HTTP/2 錯誤代碼衝突。

14.png

初始HTTP/3 錯誤代碼

對於N 的非負整數值（即0x21、0x40、到0x3ffffffffffffffe），格式為0x1f * N +0x21 的每個代碼不得由IANA 分配，並且不得出現在分配值列表中。

11.2.4 流類型

HTTP/3單向流類型會建立一個註冊表，“HTTP/3流類型”註冊表管理62位空間。該註冊表遵循QUIC 註冊表政策；見第11.2 節。此註冊表中的永久註冊是使用規範要求策略分配的，但0x00 和0x3f 之間的值（十六進制包括在內）除外，這些值是使用標準操作或IESG 批准分配的。

除了第11.2 節中描述的常見字段外，此註冊表中的永久註冊必須包括以下字段：

流類型：流類型的名稱或標籤。

發件人：HTTP/3 連接上的哪個終端可以啟動這種類型的流。值為“客戶端”、“服務器”或“兩者都有”。

永久註冊的規範必須包括流類型的描述，包括流內容的佈局和語義。

下表中的初始流類型是本文出現過的：

15.png

初始流類型

對於N 的非負整數值（即0x21、0x40、到0x3ffffffffffffffe），格式為0x1f * N +0x21 的每個代碼不得由IANA 分配，並且不得出現在分配值列表中。

HireHackking

QUIC 傳輸協議具有HTTP 傳輸所需的幾個特性，例如stream multiplexing、每個流的流控制和低延遲連接建立。本文檔描述了HTTP 語義在QUIC 上的映射。本文還介紹了QUIC 包含的HTTP/2 功能，並描述瞭如何將HTTP/2 擴展移植到HTTP/3。

簡介HTTP語義([HTTP])在互聯網上廣泛應用於各種服務。這些語義最常用於HTTP/1.1和HTTP/2。 HTTP/1.1被用於各種傳輸和會話層，而HTTP/2主要用於TCP上的TLS。 HTTP/3在一個新的傳輸協議上支持相同的語義：QUIC。

1.1 HTTP的早期版本HTTP/1.1 ([HTTP/1.1])使用空格分隔的文本字段來傳遞HTTP消息。雖然這些交換是人類可讀的，但使用空格進行消息格式化會導致解析複雜性和對變體行為的過度容忍。

由於HTTP/1.1不包括多路復用層，因此通常使用多個TCP 連接來並行處理請求。然而，這對擁塞控制（congestion control）和網絡效率有負面影響，因為TCP 不跨多個連接共享擁塞控制。

HTTP/2 引入了一個二進制幀和多路復用層，在不修改傳輸層的情況下改善了延遲。然而，由於HTTP/2的多路復用的並行特性對TCP的丟失恢復機制是不可見的，因此丟失或重新排序的數據包會導致所有活動事務都經歷停頓，無論該事務是否直接受到丟失數據包的影響。

1.2 委託給QUICQUIC 傳輸協議結合了stream multiplexing和每個流的流控制，類似於HTTP/2幀層提供的。通過提供流級別的可靠性和整個連接的擁塞控制，與TCP映射相比，QUIC有能力提高HTTP的性能。 QUIC還在傳輸層合併了TLS 1.3 ([TLS])，提供了與在TCP上運行TLS相當的機密性和完整性，並改善了TCP快速打開([TFO])的連接設置延遲。

本文定義了HTTP/3：HTTP 語義在QUIC 傳輸協議上的映射，大量借鑒了HTTP/2 的設計。 HTTP/3 依賴於QUIC 來提供數據的機密性和完整性保護；對等認證；可靠、有序、按流交付。在將流生命週期和流控制問題委託給QUIC 時，每個流都使用類似於HTTP/2 幀的二進制幀。 QUIC 包含一些HTTP/2 功能，而其他功能則在QUIC 之上實現。

2.HTTP/3協議概述HTTP/3使用QUIC傳輸協議和類似於HTTP/2的內部幀層為HTTP語義提供了傳輸。

一旦客戶端知道某個終端存在HTTP/3 服務器，它就會打開一個QUIC 連接。 QUIC 提供協議協商、基於流的多路復用和流控制。

在每個流中，HTTP/3 通信的基本單位是一個幀。每種幀類型都有不同的用途。例如，HEADERS 和DATA 幀構成了HTTP 請求和響應的基礎）。適用於整個連接的幀在專用控制流上傳輸。

請求的多路復用是使用QUIC流抽象來執行的，這在[QUIC- transport]的第2節中描述。每個請求-響應對使用一個QUIC流。流之間是相互獨立的，所以一個流被阻止或丟失不會影響其他流的進程。

服務器推送是HTTP/2中引入的一種交互方案，它允許服務器在客戶端發出指定請求之前向客戶端推送一個請求-響應交換。這就權衡了網絡使用和潛在的延遲增益。一些HTTP/3幀被用來管理服務器推送，例如PUSH_PROMISE，MAX_PUSH_ID和CANCEL_PUSH。

與HTTP/2 一樣，請求和響應字段被壓縮以進行傳輸。因為HPACK ([HPACK]) 依賴於壓縮字段部分的順序傳輸（QUIC 不提供保證），所以HTTP/3 用QPACK ([QPACK]) 替換了HPACK。 QPACK 使用單獨的單向流來修改和跟踪字段表狀態，而編碼字段部分引用表的狀態而不修改它。

3.連接設置和管理3.1 發現HTTP/3終端HTTP依賴權威的概念響應：在給定目標資源在響應消息由源服務器發起（或在其方向）時的狀態的情況下，該響應已被確定為對該請求最合適的響應在目標URI 中標識。

“https”方案將授權與擁有證書相關聯，客戶端認為該證書對於由URI 的授權組件標識的主機是可信賴的。在TLS 握手中接收到服務器證書後，客戶端必須驗證證書是否與URI的源服務器匹配。如果證書無法針對URI 的源服務器進行驗證，則客戶端不得認為服務器對該源具有權威性。

客戶端可以嘗試通過將主機標識符解析為IP 地址來嘗試訪問具有“https”URI 的資源，在指定端口上建立到該地址的QUIC 連接（包括如上所述的服務器證書驗證），並通過該安全連接向服務器發送以URI為目標的HTTP/3請求消息。除非使用其他機制來選擇HTTP/3，否則在TLS 握手期間在應用層協議協商擴展中使用令牌“h3”。

連接問題(例如，阻止UDP)可能導致無法建立一個QUIC連接；在這種情況下，客戶端應該嘗試使用基於TCP 的HTTP 版本。

服務器可以在任何UDP 端口上提供HTTP/3；替代服務廣告始終包含明確地端口，並且URI 包含與方案關聯的明確地端口或默認端口。

3.1.1HTTP替代服務HTTP 源可以使用“h3”ALPN 令牌通過Alt-Svc HTTP 響應頭字段或HTTP/2 ALTSVC 幀([ALTSVC]) 通告等效HTTP/3 終端的可用性。

例如，在HTTP響應中，通過包含以下標頭字段，可以表明HTTP/3在UDP端口50781上相同主機名是可用的：

Alt-Svc: h3=':50781'

在接收到表示HTTP/3支持的Alt-Svc記錄時，客戶端可以嘗試建立到指定主機和端口的QUIC連接；如果連接成功，客戶端可以使用本文檔中描述的映射發送HTTP請求。

3.1.2其他方案儘管HTTP獨立於傳輸協議，但“HTTP”方案將權限與在權限組件中標識的任何主機的指定端口上接收TCP連接的能力相關聯。由於HTTP/3不使用TCP，所以HTTP/3不能用於直接訪問由“HTTP”URI標識的資源的權威服務器。然而，諸如[ALTSVC]這樣的協議擴展允許授權服務器識別其他同樣具有授權且可能通過HTTP/3可訪問的服務。

當向方案不是“https”的源發起請求之前，客戶端必須確保服務器願意為該方案提供服務。對於方案為“http”的源，我們會在之後介紹實現此目的的實驗方法。

3.2 建立連接HTTP/3依賴於QUIC版本1作為底層傳輸，未來的規範可能會定義使用HTTP/3 的其他QUIC 傳輸版本。

QUIC 版本1 使用TLS 版本1.3 或更高版本作為其握手協議。 HTTP/3 客戶端必須支持在TLS 握手期間向服務器指示目標主機的機制。如果服務器由域名([DNS-TERMS]) 標識，則客戶端必鬚髮送服務器名稱指示(SNI; [RFC6066]) TLS 擴展，除非有另一種機制來指示使用的目標主機。

在建立連接期間，通過在TLS握手中選擇ALPN令牌“h3”來表示對HTTP/3的支持。對其他應用層協議的支持可以在相同的握手中提供。

雖然與核心QUIC 協議有關的連接級別選項是在初始加密握手中設置的，但特定於HTTP/3 的設置在SETTINGS 幀中傳遞。在建立了QUIC連接之後，每個終端必鬚髮送一個SETTINGS幀作為它們各自的HTTP控制流的初始幀。

3.3 連接重用HTTP/3連接是跨多個請求的持久連接。為了獲得最佳性能，客戶端在確定不再需要與服務器進行進一步通信之前(例如，當用戶導航離開某個特定的網頁時)不會關閉連接，或者直到服務器關閉連接。

一旦存在到服務器終端的連接，該連接可以被重用於具有多個不同URI 權限組件的請求。要使用一個現有的連接到一個新的源，客戶端必須驗證服務器為新的源服務器提供的證書。這意味著客戶端將需要保留服務器證書和驗證該證書所需的任何額外信息，否則客戶端將無法為其他源重用連接。

如果證書由於任何原因對於新源不可接受，則不得重用連接，並且應該為新源建立新連接。如果證書無法驗證的原因可能適用於已經與連接關聯的其他來源，客戶端應該重新驗證這些來源的服務器證書。例如，如果由於證書已過期或被吊銷而導致證書驗證失敗，則這可能用於使該證書用於建立權限的所有其他來源無效。

客戶端不應打開多個到給定IP 地址和UDP 端口的HTTP/3 連接，其中IP 地址和端口可能來自URI、選定的替代服務([ALTSVC])、配置的代理或名稱解析其中任何一個。客戶端可以使用不同的傳輸或TLS 配置打開到相同IP 地址和UDP 端口的多個HTTP/3 連接，但應避免使用相同配置創建多個連接。

服務器應盡可能長時間地保持打開的HTTP/3 連接，但在必要時允許終止空閒連接。當任何一個終端選擇關閉HTTP/3連接時，終止的終端應該首先發送一個GOAWAY 幀，以便兩個終端能夠可靠地確定之前發送的幀是否已經被處理並完成或終止任何必要的剩餘任務。

如果服務器不希望客戶端重用HTTP/3連接，它可以發送一個421(錯誤定向請求)狀狀態代碼來響應請求來表明它對請求不具有權威性。

4.在HTTP/3中表達HTTP語義4.1HTTP 消息幀客戶端在請求流上發送HTTP 請求，請求流是客戶端發起的雙向QUIC 流。客戶端必須在給定的流上只發送一個請求。服務器在與請求相同的流上發送零個或多個臨時HTTP響應，然後是一個最終HTTP響應，詳細信息如下。

推送響應在服務器發起的單向QUIC流上發送，服務器以與標準響應相同的方式發送零個或多個臨時HTTP響應，然後是一個最終HTTP響應。在給定的流中，收到多個請求或在最終HTTP 響應之後收到額外的HTTP 響應必須被視為格式錯誤。

一個HTTP消息(請求或響應)包括：

標頭部分，包括消息控制數據，作為單個標頭幀發送；

可選地，如果內容存在，則以一系列數據幀的形式發送；

可選地，尾部部分（如果存在）作為單個HEADERS 幀發送。

接收到無效的幀序列必須被視為H3_FRAME_UNEXPECTED 類型的連接錯誤。特別是，任何HEADERS 幀之前的DATA 幀，或尾部HEADERS 幀之後的HEADERS 或DATA 幀，都被認為是無效的。其他幀類型，尤其是未知幀類型，可能會根據它們自己的規則被允許。

服務器可以在響應消息的幀之前、之後或與響應消息的幀交錯發送一個或多個PUSH_PROMISE 幀。這些PUSH_PROMISE 幀不是響應的一部分。 push stream上不允許使用PUSH_PROMISE 幀；包含PUSH_PROMISE 幀的推送響應必須被視為H3_FRAME_UNEXPECTED 類型的連接錯誤。

HEADERS 和PUSH_PROMISE 幀可能會引用對QPACK 動態表的更新。雖然這些更新不是消息交換的直接部分，但必須先接收和處理它們，然後才能使用消息。

傳輸編碼沒有為HTTP/3定義；Transfer-Encoding標頭字段絕對不能被使用。

當且僅當一個或多個臨時響應在對同一請求的最終響應之前，響應可能包含多個消息。臨時響應不包含內容或預告片部分。

HTTP 請求/響應交換完全使用客戶端發起的雙向QUIC 流。發送請求後，客戶端必須關閉要發送的流。除非使用CONNECT 方法，否則客戶端不得依賴於接收到對其請求的響應來進行流關閉。發送最終響應後，服務器必須關閉要發送的流。此時，QUIC 流已完全關閉。

當流關閉時，這表示最終HTTP消息的結束。因為有些消息很大或沒有綁定，所以一旦接收到足夠的消息以進行處理，終端就應該開始處理部分HTTP消息。如果客戶端發起的流終止時沒有足夠的HTTP消息來提供完整的響應，服務器應該以錯誤碼H3_REQUEST_INCOMPLETE終止其響應流。

如果響應不依賴於尚未發送和接收的請求的任何部分，服務器可以在客戶端發送整個請求之前發送一個完整的響應。當服務器不需要接收請求的剩餘部分時，它可以中止讀取請求流，發送一個完整的響應，並關閉流的發送部分。當請求客戶端停止發送請求流時，應該使用錯誤碼H3_NO_ERROR。客戶絕對不能因為他們的請求被突然終止而刪除完整的回复，儘管客戶總是可以根據自己的判斷刪除其他原因的回复。如果服務器發送了部分或完整的響應，但沒有終止讀取請求，客戶端應該繼續發送請求的內容，並正常關閉流。

4.1.1取消和拒絕請求一旦請求流被打開，請求可以被任何一個終端取消。如果對響應不再感興趣，客戶端會取消請求；如果服務器無法或選擇不響應請求，則會取消請求。如果可能，建議服務器發送一個帶有適當狀態碼的HTTP響應，而不是取消它已經開始處理的請求。

實現應該通過突然終止流中仍然打開的任何方向來取消請求。為此，實現重置流的發送部分，併中止流的接收部分的讀取。

當服務器取消請求而不執行任何應用程序處理時，該請求被認為是“被拒絕”的。服務器應該中止包含錯誤代碼H3_REQUEST_REJECTED的響應流。在這種情況下，“已處理”意味著流中的一些數據被傳遞到軟件的較高層，該軟件可能因此採取了一些操作。客戶端可以將被服務器拒絕的請求當作從未發送過，從而允許它們稍後重試。

對於部分或全部處理的請求，服務器不得使用H3_REQUEST_REJECTED 錯誤代碼。當服務器在部分處理後放棄響應時，它應該以錯誤代碼H3_REQUEST_CANCELLED 中止其響應流。

客戶端應該使用錯誤代碼H3_REQUEST_CANCELLED來取消請求。在接收到此錯誤碼後，如果沒有執行任何處理，服務器可能會使用錯誤碼H3_REQUEST_REJECTED突然終止響應。客戶端絕對不能使用H3_REQUEST_REJECTED錯誤碼，除非服務端使用此錯誤碼請求關閉請求流。

如果在收到完整響應後取消流，客戶端可以忽略取消並使用響應。但是，如果在收到部分響應後取消流，則不應使用響應。只有GET、PUT 或DELETE 等冪等操作可以安全地重試；客戶端不應該使用非冪等方法自動重試請求，除非它有某種方法可以知道請求語義是獨立於方法的冪等，或者有某種方法可以檢測到原始請求從未被應用。

4.1.2 格式錯誤的請求和響應格式錯誤的請求或響應是一個有效的幀序列，但由於以下原因而無效：禁止字段或偽標頭字段的存在；

沒有強制性的偽標頭字段；

偽標頭字段的無效值；

字段後的偽標頭字段；

無效的HTTP 消息序列；

包含大寫字段名稱；

在字段名稱或值中包含無效字符。

如果一個請求或響應被定義為包含content - length標頭字段，如果content - length標頭字段的值不等於接收到的數據幀長度之和，則該請求或響應是不規範的。一個被定義為永遠沒有內容的響應，即使有content - length，也可以有一個非零的content - length標頭字段，即使數據幀中沒有包含任何內容。

處理HTTP 請求或響應的中介（即任何不充當隧道的中介）不得轉發格式錯誤的請求或響應。檢測到的格式錯誤的請求或響應必須被視為H3_MESSAGE_ERROR 類型的流錯誤。

對於格式錯誤的請求，服務器可以在關閉或重置流之前發送一個指示錯誤的HTTP 響應。客戶端不得接受格式錯誤的響應。請注意，這些要求旨在防止針對HTTP 的幾種常見攻擊；它們是故意嚴格的，因為允許可能暴露這些漏洞的實現。

4.2 HTTP字段HTTP消息以一系列項值對的形式攜帶元數據，稱為“HTTP字段”。與HTTP/2類似，HTTP/3還有一些額外的注意事項，包括字段名、連接標頭字段和偽標頭字段中的字符的使用。

字段名是包含ASCII字符子集的字符串。字段名中的字符必須在編碼之前轉換為小寫。字段名稱中包含大寫字符的請求或響應必須被視為格式不正確。

HTTP/3 不使用Connection 頭字段來指示特定於連接的字段；在此協議中，特定於連接的元數據通過其他方式傳送。終端絕對不能生成包含連接特定字段的HTTP/3字段部分；任何包含連接特定字段的消息都必須被視為格式錯誤。

唯一的例外是TE標頭字段，它可能出現在HTTP/3請求標頭中；如果是，它不能包含除“trailers”之外的任何值。

將HTTP/1.x 消息轉換為HTTP/3 的中介必須刪除連接特定的標頭字段，否則它們的消息將被其他HTTP/3 終端視為格式錯誤。

4.2.1 字段壓縮（field compression）[QPACK]描述了HPACK的一個變體，它使編碼器能夠控制由壓縮引起的標頭阻止的數量。這允許編碼器平衡壓縮效率和延遲。 HTTP/3 使用QPACK 來壓縮頭部和尾部部分，包括出現在標頭部分的控制數據。

為了提高壓縮效率，在壓縮之前，Cookie 標頭字段([COOKIES])可以拆分為單獨的字段行，每行包含一個或多個cookie 對。如果一個解壓縮的字段部分包含多個cookie字段行，則在傳遞到HTTP/2 或HTTP/3 以外的上下文之前，必須使用“;”的兩字節分隔符（ASCII0x3b，0x20）將它們連接成單個字節字符串，例如HTTP/1.1 連接，或通用HTTP 服務器應用程序。

4.2.2 標頭大小限制HTTP/3實現可能會對單個HTTP消息接受的消息標頭的最大大小施加限制。如果服務器接收到的標頭區域比它願意處理的更大，它可以發送一個HTTP 431(請求標頭字段太大)狀態碼([RFC6585])。客戶端可以刪除它無法處理的響應。字段列表的大小是根據未壓縮的字段大小計算的，包括名稱和值的長度(以字節為單位)，外加每個字段的32字節開銷。

如果一個實現希望將此限制通知其對等方，則可以在SETTINGS_MAX_FIELD_SECTION_SIZE 參數中將其作為字節數傳送。接收到此參數的實現不應該發送超過指示大小的HTTP 消息標頭，因為對等方可能會拒絕處理它。但是，HTTP 消息在到達源服務器之前可以經過一個或多個中介。因為這個限制是由處理消息的每個實現單獨應用的，所以不能保證低於這個限制的消息被接受。

4.3. HTTP控制數據與HTTP/2類似，HTTP/3使用了一系列偽標頭字段，其中字段名以字符(ASCII0x3a)開頭。這些偽標頭字段傳遞消息控制數據。

偽標頭字段不是HTTP字段。終端絕對不能生成除本文檔中定義的那些以外的偽標頭字段。然而，延期可以協商修改此限制。

偽標頭字段僅在定義它們的上下文中有效。為請求定義的偽標頭字段絕對不能出現在響應中；為響應定義的偽標頭字段絕對不能出現在請求中。偽標頭字段絕對不能出現在尾部部分。終端必須將包含未定義或無效偽標頭字段的請求或響應視為格式錯誤。

所有的偽標頭字段必須出現在普通標頭字段之前的標頭部分。任何包含出現在普通標頭字段之後的標頭部分中的偽標頭字段的請求或響應都必須被視為格式錯誤。

4.3.1. 請求偽標頭字段為請求定義了以下偽標頭字段：

':method'：包含HTTP方法；

':scheme'：包含目標URI的方案部分。

：scheme偽標頭不局限於具有“http”和“https”方案的URI。代理或網關可以轉換非HTTP方案的請求，使HTTP 能夠與非HTTP 服務進行交互。

':authority'：包含目標URI的權限部分，權限不得包含方案“http”或“https”的URI 的已棄用userinfo 子組件。

為確保HTTP/1.1 請求行可以準確再現，當從具有特定方法形式的請求目標的HTTP/1.1 請求轉換時，必須省略此偽標頭字段。直接生成HTTP/3 請求的客戶端應該使用:authority 偽標頭字段而不是Host 標頭字段。如果請求中沒有Host字段，則將HTTP/3 請求轉換為HTTP/1.1 的中介必須通過複製:authority 偽標頭字段的值來創建Host字段。

':path'：包含目標URI的路徑和查詢部分後跟“查詢”結果。

對於“http”或“https”URI，此偽頭字段不得為空；不包含路徑組件的“http”或“https”URI 必須包含值/（ASCII0x2f）。不包含路徑組件的OPTIONS 請求包含:path 偽標頭字段的值* (ASCII0x2a)。

所有HTTP/3 請求必須只包含一個:method、scheme 和:path 偽標頭字段的值，除非請求是CONNECT 請求。

如果:scheme 偽標頭字段標識了具有強制權限組件（包括“http”和“https”）的方案，則請求必須包含:authority 偽標頭字段或Host 標頭字段。如果這些字段存在，則它們不得為空。如果兩個字段都存在，它們必須包含相同的值。如果該方案沒有強制授權組件並且在請求目標中沒有提供任何內容，則請求不得包含:authority 偽標頭或Host 標頭字段。

如果一個HTTP請求省略了強制的偽標頭字段或者包含了這些偽標頭字段的無效值，那麼這個請求就是不規範的。

HTTP/3沒有定義攜帶HTTP/1.1請求行中包含的版本標識符的方法。 HTTP/3請求隱含的協議版本是“3.0”。

4.3.2. 響應偽標頭字段對於響應，定義了一個帶有HTTP 狀態代碼的“:status”偽標頭字段。這個偽標頭字段必須包含在所有響應中，否則，響應格式錯誤。

HTTP/3沒有定義一種方式來攜帶包含在HTTP/1.1狀態行中的版本或原因短語。 HTTP/3響應隱含的協議版本是“3.0”。

4.4. 連接方法CONNECT 方法請求接收方建立一條到請求目標標識的目標源服務器的隧道，它主要與HTTP 代理一起使用，以與源服務器建立TLS 會話，以便與“https”資源進行交互。

在HTTP/1.x 中，CONNECT 用於將整個HTTP 連接轉換為到遠程主機的隧道。在HTTP/2 和HTTP/3 中，CONNECT 方法用於在單個流上建立隧道。

CONNECT請求構造如下：

:method 偽標頭字段設置為“CONNECT”；

:scheme 和:path 偽標頭字段被省略；

:authority 偽標頭字段包含要連接的主機和端口，相當於CONNECT 請求的請求目標的權限形式。

請求流在請求結束時保持打開狀態，以攜帶要傳輸的數據。不符合這些限制的CONNECT請求是不正確的。

支持CONNECT 的代理與:authority 偽標頭字段中標識的服務器建立TCP 連接（[RFC0793]）。一旦成功建立此連接，代理就會向客戶端發送一個包含2xx 系列狀態代碼的HEADERS 幀。

流上的所有數據幀都對應於TCP連接上發送或接收的數據。客戶端發送的任何數據幀的有效載荷都由代理傳輸給TCP服務器，從TCP服務器接收到的數據被代理打包成數據幀。請注意，不能保證TCP 段的大小和數量可預測地映射到HTTP DATA 或QUIC STREAM 幀的大小和數量。

C

HireHackking

微信截图_20230930000731.png

GuLoader和Remcos關係大揭秘（上）

來自VgoStore的GuLoader及其與CloudEyE的關聯研究人員在2023年看到的樣本，是否真的是在2020年發現的與CloudEyE有關的GuLoader嗎？

事實上，GuLoader現在看起來真的不一樣了。該執行不像2020年在GuLoader中那樣涉及VB6應用程序，現在它以VBS腳本或NSIS可執行文件的形式傳播。 2020和2023版本唯一的共同點是GuLoader核心功能：加密shellcode，然而，這一部分也發生了重大變化。正如研究人員在上一篇文章中所描述的，GuLoader的開發人員使用了新的模糊處理技術，這些技術掩蓋了真實的執行流，並使自動反彙編工具和調試器無法分析代碼，新版本還使用算術運算實現了數據模糊處理。

然而，研究人員仍然設法在代碼中找到了相似之處，在下面的屏幕截圖中，您可以看到這兩個版本都使用了反調試技巧：修補DbgUiRemoteBreakIn和DbgBreakPoint函數。儘管由於新版本中的混淆，程序集代碼非常不同，但在2020年和2023年的GuLoader版本中，相同的字節用於覆蓋研究人員在卸載代碼後可以看到的函數的代碼。

29.png

2020年和2023年GuLoader版本的代碼相似性

一般來說，關於反分析技術，兩個版本的列表非常相似。很明顯，反分析技術的數量隨著每個新版本的發布而增加。

此外，所有版本的shellcode都使用大型結構來存儲shellcode執行的各個階段可能需要的全局變量，該結構的基址存儲在EBP寄存器中。此結構中各種變量的偏移量在不同版本之間發生了變化，而其他偏移量保持不變。

研究人員最近在2023年分析的樣本（MD5:40b9ca22013d02303d49d8f922ac2739）和2020年的舊樣本（MD5:d621b39ec6294c998580cc21f33b2f46）中得出：

30.png

2023年和2020(CloudEyE)的GuLoader的全局結構中API函數指針的相同偏移量

在這兩個樣本中，存儲許多API函數地址的變量的偏移量是相同的。

研究人員還發現了GuLoader的中間版本可供研究人員使用，他們在2021年和2022年確定了這些樣本。讓我們比較一下研究人員從2021年首次看到的樣本中提取的解密例程代碼（MD5:abf39daaa33505f26959db465116f21f）與上一個樣本中的2023 GuLoader樣本中的例程(MD5：40b9ca22013d02303d49d8f922ac2739)。由於混淆，這些函數中的彙編代碼略有不同，然而，如果研究人員使用反編譯器，他們會得到兩個樣本相同的結果。

31.png

2021年和2023年的GuLoader版本中相同的反編譯代碼

由於類似的行為和代碼模式，研究人員的惡意軟件自動分類和配置提取工具將這些樣本識別為GuLoader。

32.png

2021年、2022年和2023年的樣本被確定為GuLoader

研究人員使用自動分析處理了6000多個GuLoader樣本，這些樣本按首次看到的日期排序，並識別了不同版本的GuLoader，這也使研究人員能夠構建GuLoadershellcode版本的時間表。在下表中，研究人員標記了數據加密和模糊處理算法發生重大變化的版本的字符串，包括用於下載有效負載的URL，以及有效負載解密密鑰：

33.png

不同GuLoader shellcode版本出現的時間

該圖表顯示，對於GuLoader shellcode的每個新版本，舊版本的樣本數量都大大減少。以上列出的所有事實使研究人員確信，GuLoader的新版本，包括VgoStore演示的樣本，仍然是研究人員在2020年展示的與CloudEyE和Securitycode.eu相關的惡意軟件。

BreakingSecurity和VgoStore的幕後黑手如上所述，暱稱為“EMINэM”的用戶是BreakinSecurity.net官方Telegram群組的負責人：

34.png

“EMINэM”Telegram用戶詳細信息

研究人員可以在“EMINэM”發布的視頻中看到非常具體的製品，其中包括桌面“This PC”和文件夾“EM1NeM”的自定義圖標：

35.png

EMINэM的桌面工件

研究人員可以用這些來識別“EMINэM”創建的視頻。

現在讓回到@VgoStore_Group群，在該群的管理員中，可以看到兩個用戶：“EMINэM”(自定義標題為“Trusted Vendor”)和VGO (@VgoStore)：

36.png

VgoStore Telegram群管理員

VGO和“EMINэM”偽裝成不同的用戶，研究人員甚至可以在這個組中找到他們之間的“對話”：

37.png

VGO與“EMINэM”之間的“對話”

然而，如果研究人員仔細觀看用戶VGO發布的視頻，研究人員會注意到用戶“EMINэM”發布的相同的偽裝對象：

38.png

“EMINэM”在VGO發布的視頻中的桌面

關於本視頻中“EMINэM”桌面的工件，研究人員注意到一個細節。他們看到用戶通過WinSCP連接到遠程主機，並打開文件夾“/var/www/html/zarath”，研究人員在主機“194.180.48.211”上發現了一個同名的打開目錄，這是研究人員在分析用戶VGO演示TheProtect的VBS變體的視頻時發現的，研究人員將其識別為GuLoader。

基於此，研究人員可以假設BreakingSecurity和VgoStore Telegram群都由同一個人控制，並且他還擁有兩個帳戶：“EMINэM”和VGO。

接下來，研究人員嘗試在Google上搜索“VgoStore”，發現用戶“VgoStore”在“wordpress.org”網站論壇上尋求WordPress插件的幫助。在對話期間，用戶發布了屬於YouTube用戶“EMINe M”(@BreakingSecurity)的兩個未列出的YouTube視頻的鏈接：

39.png

“EMINэM”在“wordpress.org”網站論壇上發布的未列出的YouTube視頻

在視頻“2023 01 26 15 18 16”(https：//www.youtube.com/watch?v=L8yB_xybTPs)的開頭，研究人員看到了視頻中“EMINэM”的桌面上的熟悉的真人快打壁紙。研究人員還可以看到遠程桌面的IP地址“173.212.217.108”，“EMINэM”通過它訪問虛擬主機面板和電子郵件“abudllah.alshamsy(at)gmail[.]com”：

40.png

通過遠程桌面由“EMINэM”管理的服務器的IP地址

在第二個視頻(“2023 01 26 20 02 07”，https：//www.youtube.com/watch?v=KHp07C3DgWo)中，研究人員觀察到VgoStore WordPress管理面板，BreakingSecurity和VgoStore的“訂單”選項卡同時打開：

41.png

BreakingSecurity和VgoStore的“訂單”選項卡在“EMINэM”的視頻中同時打開

儘管試圖隱瞞與VgoStore的任何直接聯繫，但可以發現“EMINэM”原來是BreakingSecurity和VgoStore網站以及Telegram群的管理員。

EMINэM的身份“EMINэM”在WordPress論壇上發布的一個視頻(“2023 01 26 15 18 16”，https：//www.youtube.com/watch?v=L8yB_xybTPs)相當長。 “EMINэM”在不同的窗口之間反复切換，其中一些幀顯示了有助於研究人員調查的敏感數據。

“EMINэM”使用“Rabea Akram”假名通過電子郵件(expert.eminem@gmail[.]com)與網站通信：

42.png

“EMINэM” 使用假名管理的相關網站

在10：36處，研究人員可以看到“EMINэM”以“Shadi Gharz Elddin”的名義預訂了航班：

43.png

“EMINэM”在航班預訂確認電子郵件中的真實姓名

研究人員很容易就找到了Shadi Gharz的Facebook和Twitter賬戶，他在這些賬戶上公開寫道，他的工作地點是BreakingSecurity：

44.png

Shadi Gharz的社交網絡頁面

知道“EMINэM”的真名是Shadi後，就可以假設選擇“EMINэM”這個暱稱的來源很可能是藝術家Eminem的歌曲“the real Slim Shady”。

由“EMINэM”進行的惡意活動除了前面提到的樣本(SHA256：63559daa72c778e9657ca53e2a72deb541cdec3e0d36ecf04d15ddbf3786aea8, c914dab00f2b1d63c50eb217eeb29bcd5fe20b4e61538b0d9d052ff1b746fd73)之外，研究人員發現“EMINэM” 在過去幾年中策劃許多攻擊。

1. 在Eminem於2021年發布的一段視頻https：//youtu.be/5xpYjLbDpnE?t=84中，在1：24處，研究人員看到了瀏覽器的歷史記錄：

45.png

“EMINэM”的瀏覽器歷史記錄包含Formbook CC服務器的地址

上面的列表包含用於控制木馬和檢索被盜數據的Formbook信息竊取面板的地址。以下是使用給定地址的CC服務器的Formbook樣本列表：

46.png

2. 在“EMINэM”發布的不同視頻中，研究人員注意到他通過RDP或SFTP管理的服務器的幾個IP地址。

研究人員能夠下載前面提到的打開目錄“hxxp：//194.180.48.211/zarath/”的當前內容：

47.png

“194.180.48.211/zarath/”的內容

研究人員發現這個文件夾中的一部分文件是GuLoader加密的shellcode，其餘的是加密的有效負載，其中大多數是Remcos。雖然開發人員可能會聲稱Remcos和GuLoader (CloudEyE, TheProtect)是合法軟件，但研究人員也在這個文件夾中發現了兩個真正的惡意有效負載，研究人員將其識別為Amadey Loader，以及相應的加載和解密這些有效負載的GuLoader shellcode：

48.png

3.在2022年4月19日“EMINэM”在@BreakingSecurity_Group群中發布的視頻中，研究人員看到他如何以root用戶(這意味著他是該服務器的所有者)連接到名為“CaliPB”的遠程服務器，IP地址為“38.242.193.23”：

49.png

“EMINэM”以root用戶身份使用WinSCP連接到他的服務器

在下一個截圖中，研究人員可以通過web訪問“/var/www/html”文件夾的內容，並註意到一個名為“private”的子文件夾：

50.png

“EMINэM”服務器上文件夾' /var/www/html '的內容

不幸的是，無法檢索“私有”文件夾的內容，然而，研究人員仍然能夠使用VirusTotal找到相關的樣本。研究人員分析了之前從主機“38.242.193.23”下載的樣本。其中，研究人員找到了GuLoader和Remcos：

51.png

在這個表中，研究人員再次看到之前與“EMINэM”連接的IP地址“194.180.48.211”和“173.212.217.108”，但是現在研究人員看到新的IP地址“185.217.1.137”被用作Remcos的CC服務器。該IP地址屬於提供端口轉發服務的nVPN，可能是“EMINэM”用來隱藏其Remcos CC服務器的真實IP地址。研究人員的假設得到了以下事實的證實，在其中一個視頻中，研究人員在“EMINэM”的郵箱中看到一封來自nVPN的信：

52.png

“EMINэM”收到的nVpn.net確認電子郵件

研究人員還發現了一個域名“vrezvrez.com”，該域名在錄製視頻期間被解析為IP地址“38.242.193.23”，另外還發現了5個4.1版本的Formbook樣本，它們的CC服務器URL為“vrezvrez.com/private/”：

53.png

因此，證據顯示，Eminem不僅參與了Remcos和GuLoader的攻擊，還使用了Formbook和Amadey Loader等知名惡意軟件。

收入分析研究人員在WordPress論壇上發現的由“EMINэM”上傳的未列出的YouTube視頻“2023 01 26 15 18 16”包含了更多有助於研究人員調查的數據。研究人員在5：41處看到“EMINэM”的Gmail帳戶的收件箱，研究人員注意到了來自tochkaobmena.com服務的郵件。在視頻中可以從電子郵件中恢復鏈接：

https：//tochkaobmena.com/hst_FhaMv1rUzBTMfXlgR71vRjafr47K0wQyjuF/

54.png

數字貨幣兌換確認包含一個URL

點擊鏈接，就可以找到了包含數字資產交換操作結果的頁面（Perfect Money USD-Tron USDT），其中包含Tron區塊鏈錢包地址：TLqC6F4AVs8MrdiQDgRuFcW2Xp3iY3hg2D，研究人員分析了交易記錄，併計算了該賬戶在過去一年天內收到的近6萬美元收入。

很明顯，BreakingSecurity和VgoStore只有部分資金是通過這個錢包流動的，詳細觀看視頻後，研究人員可以更好地了解VgoStore的收入。在5:06處，我們看到WordPress管理頁麵包含WooCommerce插件的報告：

55.png

WordPress管理頁面顯示銷售統計數據

15000美元可被視為VgoStore網站上Remcos和其他服務銷售的月收入估計。

總結Remcos和GuLoader等工具曾經只在黑客論壇上出售，現在卻偽裝成合法產品公開，這種工具現在很容易獲得，在懷有惡意的個人中很受歡迎。

調查結果顯示，一個化名為EMINэM的個人管理著BreakingSecurity和VgoStore網站，這些網站以新名稱TheProtect公開出售Remcos和GuLoader。研究人員還發現了EMINэM參與惡意軟件傳播的證據，包括臭名昭著的Formbook信息竊取程序和Amadey Loader，與此同時，EMINэM利用TheProtect繞過殺毒軟件的能力，將其用於自己的惡意目的。

根據這些發現，很明顯，BreakingSecurity、VgoStore及其產品所宣傳的合法性只不過是煙幕彈，這些服務背後的個人與網絡犯罪社區緊密相連，利用他們的平台為非法活動提供便利，並從銷售充滿惡意軟件的工具中獲利。

HireHackking

微信截图_20230930000731.png

惡意軟件經常將自己偽裝成合法工具，最近比較有代表性的例子是Remcos RAT(遠程管理工具)和GuLoader(也稱為CloudEyE Protector)，他們在最流行的惡意軟件排名中佔據榜首位置。

1.png

Remcos和GuLoader在十大惡意軟件中的排名

由於Remcos很容易被殺毒軟件檢測到，因此很難用於攻擊，然而，GuLoader可以用來幫助Remcos繞過殺毒軟件。目前，GuLoader現在在與Remcos相同的平台上以新名稱銷售，並被包裝成為一種加密器，使其有效負載完全無法被檢測到。此外，監督該平台的管理員還管理BreakingSecurity網站，該網站是Remcos RAT和相關Telegram通道的官方網站。有證據表明，銷售Remcos和GuLoader的個人使用Amadey和Formbook等惡意軟件，並使用GuLoader作為預防措施，與Remcos和GuLoader賣家相關的域名和IP地址出現在惡意軟件分析報告中。

Remcos和GuLoader的賣家清楚地意識到他們的工具被攻擊者所利用，儘管他們聲稱自己是無辜的。研究人員最終曝光了負責出售Remcos和GuLoader的個人，揭露了他們的社交網絡，並揭示了通過這些非法活動產生的大量收入。

GuLoader 和Remcos的關係GuLoader於三年多前被發現，其是一個高度保護的基於shellcode的加載器，它採用了許多技術來防止手動和自動分析。此外，在最近的樣本中，通過使用.LNK文件、VBS和PowerShell腳本，利用了來自遠程服務器的代碼片段的多階段加載，這些技術的結合允許GuLoader樣本在VirusTotal上實現零檢測率，並將任何惡意負載傳遞到受害者的計算機上。

2020年，研究人員曝光了一個通過securitycode.eu 銷售CloudEyE的平台，它與GuLoader有關，這迫使創建者暫停運營。在他們的網站上，他們發布了一條消息，稱他們的服務旨在保護知識產權，而不是傳播惡意軟件。

2.png

幾個月後，他們的網站恢復了CloudEyE的銷售，不久之後，研究人員在監測中觀察到新的GuLoader攻擊數量增加，以及新版本的出現。目前，研究人員每天會監控到數十個新的GuLoader樣本。

3.png

過去6個月每天涉及GuLoader的攻擊次數

在之前關於最新版本GuLoader的分析中，研究人員故意省略了CloudEyE和新版本GuLoader之間的任何联系，因為他們觀察到GuLoader在名為“VgoStore”的網站上以另一個名稱“The Protector” 傳播。事實證明，VgoStore與Remcos密切相關。

Remcos是一款著名的遠程監控工具，其營銷目的是為了合法的跟踪和監控。自2016年出現以來，研究人員一直在許多網絡釣魚活動中監測Remcos，除了典型的遠程管理工具功能外，Remcos還包括一些不常見的功能，如中間人(MITM)功能、密碼竊取、跟踪瀏覽器歷史記錄、竊取cookie、密鑰記錄和網絡攝像頭控制。這些功能超出了RAT的典型範圍。

在黑客論壇上的CloudEyE廣告消失後，研究人員開始在互聯網上尋找有關CloudEyE Protector的信息。在谷歌搜索結果的第一頁，研究人員發現了一個Utopia項目網站的鏈接，其中CloudEyE Protector被列在“商家”部分，就在BreakingSecurity (Remcos RAT的官方網站)之後：

4.png

BreakingSecurity和CloudEyE在Utopia網站上的廣告

研究人員還注意到，在2022-2023年，Remcos樣本的數量幾乎佔能夠識別惡意軟件家族的所有成功解密GuLoader有效負載的四分之一。

5.png

確定的GuLoader有效負載

換句話說，在過去的一年裡，Remcos已經成為使用GuLoader傳播的最常見的惡意軟件。如上所述，這不是巧合。

VGO TheProtect——GuLoader的新產品Remcos的營銷和銷售最初是在黑客論壇上進行的，後來在一個名為BreakingSecurity[.]net的專門網站上進行銷售。從2022年開始，人們可以在另一個名為VgoStore[.]net的網站上找到Remcos的銷售，VgoStore在@BreakingSecurity_Group Telegram群中被宣傳為Remcos的官方經銷商，該組織由暱稱為“EMINэM”的版主(用戶名@breakindsecurity， @emin3m， @Break1ngSecurir1ty)運營：

6.png

“EMINэM”在BreakingSecurity Telegram群發布的VgoStore廣告

在VgoStore，除了breakingsecurity的Remcos，你還可以找到一個完整的惡意傳播包和初始訪問工具包，如“Excel 和Doc 漏洞”，LNK漏洞，RDP帳戶，專用DNS，加密器等。這些工具被標記為“教育”。

在這些工具中，研究人員注意到了TheProtect(Private Protect服務)：

7.png

除了@BreakingSecurity_Group Telegram群之外，“EMINэM”還為VgoStore維護了一個名為@VgoStore_Group的Telegram群。在這些群中，每當用戶要求提供加密服務時，“EMINэM”和另一位管理員“VGO”就會推送TheProtect，同樣值得注意的是，在一條消息中，“EMINэM”提到TheProtect是一個幫助Remcos繞過Windows Defender (WD)的工具：

8.png

TheProtect在BreakingSecurity和VgoStore Telegram群中的廣告

與此同時，在BreakingSecurity Telegram群中，管理員似乎試圖與惡意活動保持距離，稱他們只提供了一種將Remcos列入殺毒白名單的方法，而不是繞過保護。與VgoStore群相反，在VgoStore群中，TheProtect被宣傳為提供“運行時FUD”的服務，即在執行樣本時完全無法被殺毒軟件檢測到：

9.png

VGO和“EMINэM”在BreakingSecurity和VgoStore Telegram群中發布的消息

TheProtect有兩種保護方式：Private Protect和Script Protect。

10.png

protect保護方法

根據VgoStore官網顯示，Script Protect提供的文件為VBS文件，而不是EXE文件。

“Private Protect”一詞可能具有誤導性，因為它可能給人一種印象，即每個客戶都收到了一個獨特的工具。然而，在進一步檢查VgoStore的Telegram群和YouTube頻道中的視頻後，很明顯有兩種類型的加密服務可用：一種基於NSIS (Nullsoft Scriptable Install System)，另一種基於VBS (Visual Basic Scripting)。

研究人員懷疑這與最常見的GuLoader變體相似，其中一個是VBS變體，另一個是NSIS變體。

Script Protect是非常昂貴的，在30天內，4個受保護文件的售價為7000美元，對於Script Protect和Private Protect，他們都聲明“研究人員保留最多3天的時間來提供受保護的軟件。”這讓研究人員認為保護過程並不是完全自動化的，這意味著購買者可能不會收到自動生成受保護文件的構建器，就像CloudEyE的情況一樣。

Protect VBS變體正如研究人員之前所寫的，VgoStore會在Telegram群@VgoStore_Group發布產品更新，客戶可以獲得支持。在這個群組中，管理員經常發布演示其產品功能的視頻。

11.png

VgoStore Telegram群

在該組織於2023年3月5日發布的一個視頻中，用戶@VgoStore演示了使用偽裝成PDF的LNK文件進行攻擊。

12.png

在VgoStore Telegram群中發布的視頻

在這個視頻中，研究人員看到點擊LNK文件會導致新的進程“eilowutil.exe”啟動一個與遠程服務器“84.21.172.49：1040”的TCP連接。在啟動LNK文件之前，視頻顯示所有Windows Defender功能都已啟用，並且Windows Defender在整個執行過程中沒有引發任何警報。

視頻提供了被測試樣本的重要細節，使研究人員能夠恢復完整的攻擊鏈。在01：13處，研究人員可以簡單看到process Hacker顯示的powershell.exe進程的命令行，這使研究人員能夠識別本視頻中演示的樣本(SHA256：c914dab00f2b1d63c50eb217eeb29bcd5fe20b4e61538b0d9d052ff1b746fd73)，並使用行為搜索查詢在VirusTotal上找到它：

13.png

視頻中演示的進程命令行使研究人員能夠在VirusTotal上找到一個相關的樣本

當研究人員下載腳本時，研究人員發現它類似於研究人員在文章《基于云的恶意软件传播：GuLoader的演变》 中描述的GuLoader的VBS變體。與研究人員在上一篇文章中描述的版本的唯一區別是，shellcode以base64編碼的形式嵌入VBScript中，然後放入註冊表中：

14.png

存儲在註冊表中的base64編碼加密數據

VBScript的另一部分包含有兩層混淆的PowerShell腳本。該腳本包含在視頻截圖中觀察到的字符串，用於識別此惡意樣本($Tjringernes=， Diu;DyrFAttuEncnNatcWootLobiLsioReknUnd)：

15.png

部分VBS包含混淆的PowerShell腳本

在去混淆之後，研究人員得到了以下代碼：

16.png

去混淆PowerShell腳本

這段代碼從註冊表加載base64編碼的數據，使用CallWindowProcA API函數解碼並運行它，方法與基於《云的恶意软件传播：GuLoader的演变》 中描述的相同。該代碼的前645個字節沒有被加密，並且包含解密器的代碼，其餘的數據包含加密的shellcode。

研究人員用於自動分析惡意樣本的工具將加密數據識別為GuLoader，並成功解密shellcode，包括GuLoader配置、下載有效負載的URL和有效負載解密密鑰：

17.png

解密後的GuLoader配置

截止發文，URL“hxxp：//194[.180.48.211/nini/EAbsGhbSQL10. html”“Aca”仍然活躍。因此，研究人員能夠下載最終的有效負載(SHA256 7bd663ea34e358050986bde528612039f476f3b315ee169c79359177a8d01e03)，他們使用從GuLoader shellcode中提取的密鑰來解密它。解密後的樣本似乎是Remcos RAT（SHA256 25c45221a9475246e20845430bdd63b513a9a9a73ed447bd7935ff9ecee5a61e）。

18.png

GuLoader攻擊鏈的恢復部分

研究人員從這個Remcos樣本中提取並解密了CC配置，發現它包含一個CC服務器的地址“84.21.172.49:1040”：

19.png

解密後的Remcos CC配置

最後，使用最初找到的GuLoader VBS樣本“Leekish.VBS”的“VirusTotal Relations”選項卡，研究人員還發現了下載該文件的URL：“hxxp://194.180.48.211/nini/Leekish.vbs”。這個地址也在視頻中被披露：

20.png

下載在VirusTotal上找到的初始VBS樣本的URL

視頻（第00:45幀）中展示的另一個有趣的社會工程技巧是操縱LNK文件，攻擊者誤導用戶相信它是PDF文檔。即使用戶懸停在LNK文件上，工具提示也會顯示“Type: PDF Document”；此外，如果用戶雙擊LNK文件，它實際上會打開一個誘餌PDF文件，而惡意進程會在後台靜默運行。

這是通過以下簡單步驟實現的：

1.文件擴展名更改為“.pdf.lnk”，利用默認情況下隱藏的文件擴展名。

2.LNK描述被修改為顯示“PDF文檔”，利用了Windows顯示快捷方式描述字段內容的事實。請注意，工具提示中顯示的大小與實際文件大小不同。工具提示顯示“Size: 7.11Kb”，取自快捷方式的Description字段，而文件大小實際上是3Kb。

3.圖標源已更改為顯示PDF圖標。

4.LNK文件還下載並執行一個誘餌PDF文件。

21.png

偽裝成PDF文檔的LNK文件

研究人員在VirusTotal上發現了一個LNK文件(SHA256：63559daa72c778e9657ca53e2a72deb541cdec3e0d36ecf04d15ddbf3786aea8)，該文件引用了上述URL，並包含完全相同的Description字段：

22.png

解析後的LNK文件

此惡意快捷方式文件利用Windows System32文件夾中存在的合法腳本SyncAppvPublishingServer.vbs的功能來運行任意PowerShell命令。命令行參數包含用於下載和運行惡意腳本“Leekish.vbs”和PDF誘餌的PowerShell命令，msedge.exe文件中的PDF圖標用作快捷方式圖標。

因此，研究人員已經恢復了視頻中展示的完整攻擊鏈，並確定了大部分涉及的文件和組件。視頻中提到的“Script Protect文件”似乎是Remcos RAT，其CC服務器位於“84.21.172.48:1040”。研究人員將保護程序確定為GuLoader的VBS版本：

23.png

VgoStore Telegram群視頻中顯示的完整攻擊鏈

這個攻擊鏈類似於研究人員從GuLoader之前的攻擊中看到的，RedCanary博客中也有描述，這個VBS和LNK樣本特別有趣，因為研究人員在去年(2023年2月)發現了針對註冊會計師和會計師的攻擊。

保護NSIS變體VgoStore還有一個YouTube頻道。 2023年4月12日發布的視頻“Lnk Exploit”與研究人員上面分析的視頻非常相似。演示者下載一個包含LNK文件的文檔並運行此LNK文件。如視頻所示，同時安裝了所有最新的Windows更新，並啟用了安全功能。與前面的情況一樣，如果研究人員在2分11秒處暫停視頻，就可以看到由於運行LNK文件而創建的powershell.exe進程的命令行。

24.png

包含URL的命令行

上面屏幕截圖中的process命令行包含2個URL，截至發文時，這兩個URL都是活動的，這使研究人員能夠下載這些文件。

25.png

其中一個示例是一個誘餌PDF，第二個示例是NSIS安裝程序包

HireHackking

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

受影響平台：Linux；

影響用戶：任何組織；

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

嚴重級別：嚴重；

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

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

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

攻擊鏈picture1.png

GoTrim攻擊鏈

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

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

picture2.png

PHP下載腳本

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

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

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

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

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

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

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

VICTIM_EXTERNAL_IP:HTTP_SERVER_PORT:1:OUTBOUND_IP:AES_PASSPHRASE

VICTIM_EXTERNAL_IP：設備的外部/公共IP；

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

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

OUTBOUND_IP：目標設備的出站/本地IP地址；

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

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

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

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

picture3.png

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

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

1. Bot ID：木馬的唯一ID；

2.外部IP：受害設備的公共IP地址；

3.HTTP服務器端口：為HTTP服務器隨機生成的端口（客戶端模式為0）；

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

5.出站IP：受害目標設備的本地IP地址；

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

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

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

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

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

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

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

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

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

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

picture4.png

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

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

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

2. 命令ID：表示當前任務的命令；

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

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

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

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

c.命令選項2(修改後)：對於認證命令，該選項包含密碼；

d.命令選項3：WordPress認證的未知選項；

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

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

惡意軟件支持以下命令：

1：驗證WordPress域提供的憑據；

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

3：根據OpenCart域驗證所提供的憑據；

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

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

11：終止惡意軟件；

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

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

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

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

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

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

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

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

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

微信截图_20221215094401.png

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

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

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

picture5.png

WordPress身份驗證請求

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

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

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

目標URL；

使用者名稱;

密碼；

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

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

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

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

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

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

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

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

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

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

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

Google reCAPTCHA；

BestWebSoft的reCAPTCHA；

WP限制登錄嘗試；

屏蔽安全Captcha；

All in One Security (AIOS)Captcha；

JetPackCaptcha；

BestWebSoft的Captcha；

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

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

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

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

picture6.png

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

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

picture7.png

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

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