刁嘉文,方濱興,,崔翔,王忠儒,甘蕊靈,馮林,姜海
(1.北京郵電大學可信分布式計算與服務教育部重點實驗室,北京 100876;2.廣州大學網絡空間先進技術研究院,廣東 廣州 510006;3.中國網絡空間研究院信息化研究所,北京 100010;4.北京丁牛科技有限公司,北京 100081)
域名系統(DNS,domain name system)是一種將域名和IP 地址相互映射的以層次結構分布的分布式數據庫系統[1],也是互聯網上普遍存在的基礎解析服務。防火墻等基礎防御設施為了保證用戶體驗一般不會對DNS 數據進行過多過濾,使其成為攻擊者手中較理想的秘密信道[2]。互聯網名稱與數字地址分配機構(ICANN,Internet Corporation for Assigned Names and Number)[3]將其命名為DNS 隱蔽信道(DCC,DNS covert channel)。
DCC 是指利用DNS 數據包中的可定義字段秘密傳遞信息的通道。其中,“DNS 協議”是目前網絡上使用的標準域名解析協議[4];“可定義字段”是DNS 數據包中的QNAME 字段、RDATA 字段及RawUDP 字段。利用DNS 數據包可以構建2 種信道:存儲信道及時間信道。由于時間信道可傳輸信息較少且對應的工具及惡意軟件很少,故主要研究存儲信道的利用情況。DCC 可以被用于數據泄露、命令控制(C&C,command &control)及繞過Wi-Fi連接注冊等惡意行為,進而可以用于遠控木馬(RAT,remote access trojan)、僵尸網絡(Botnet)、勒索軟件(Ransomeware)、高級持續性威脅(APT,advanced persistent threat)等絕大多數網絡攻擊。
雖然DCC 早在1998 年就開始出現,但在2020 年仍有許多惡意軟件利用其發起攻擊,相關開源工具也逐漸被攻擊組織惡意利用,對各個領域都產生了一定程度的影響[5-20]。在金融領域,活躍在該領域中的銷售點(POS,point of sale)惡意軟件(如AlinaPOS[5])經常利用DNS 查詢請求來泄露信息[6];在醫療領域,SentinelLabs[7]及 Unit42[8]報道稱Trickbot 開發人員在其惡意軟件中新增了Anchor_DNS 模塊,在針對美國醫療系統的攻擊中利用該模塊使用DCC 進行C&C。大多數工具開源且日趨成熟,有理由相信,未來可能會有越來越多的DCC 工具被惡意利用,DCC 惡意軟件也時刻威脅著網絡空間安全。
本文主要圍繞DCC 構建及DCC 檢測2 個方面進行論述,具體貢獻總結如下。
1) 對DCC 的威脅模型進行了歸類、總結;對DCC 的發展歷程進行了全面梳理,概括為3 個發展階段。
2) 對DCC 概念進行了形式化定義;對構建機理進行了深入剖析,為檢測研究提供有價值的參考。
3) 總結DCC 難以繞過的異常點,并對其異常進行了分析;對傳統檢測方法及人工智能賦能的檢測方法涉及的具有代表性的論文進行了總結梳理,指出現存問題。
4) 對未來的發展趨勢進行了展望,旨在從整體角度發現重點問題,為研究人員提供進一步研究的方向。
由于DNS 協議具有泛在性、隱蔽性,因此可以將DCC 運用于許多威脅活動中。DCC 分為2 種類型,若受害設備通過IP 地址直接與惡意權威名稱服務器(MANS,malicious authoritative name server)相連,則稱所構成的信道為直連信道,這種情況下一般使用RawUDP 字段傳輸信息;若受害設備通過本地默認解析連接到MANS,則稱所構成的信道為中繼信道,這種情況下一般使用QNAME 字段及RDATA 字段傳輸信息。由于前者較簡單,故這里主要討論后者所涉及的命令控制、數據泄露2 種威脅場景,其過程有著細微的差別,下面將進行詳細闡述。
1) 命令控制
普通防火墻等基礎防御設施一般不對DNS 進行過多過濾,使DCC 成為具有一定隱蔽性、穿透性的C&C 信道,可以實現受害設備與遠程攻擊者搭建的MANS 的雙向交互,如圖1 所示。受害設備向MANS 請求控制命令,MANS 收到后,將欲下發的命令進行處理,利用DNS 響應向受害設備發出命令,受害設備解碼獲得命令并執行。

圖1 命令控制流程
2) 數據泄露
在這種場景下,攻擊者會利用DNS 查詢請求將待傳送數據如敏感信息、文件等傳送到其搭建的MANS。由于大部分安全基礎設施都更加關注來自外部網絡的攻擊,因此這種攻擊需要主動監測內部流出流量才能發現,使數據泄露的全過程更隱蔽。受害設備向攻擊者搭建的MANS 發出請求,利用請求來泄露信息,如圖2 所示。如果待泄露文件較大,則需對其進行分片,然后將分片后的信息進行編碼壓縮傳送。服務器收到后,按照對應格式獲取信息,并適當響應。

圖2 數據泄露流程
DCC 用于惡意活動一般存在于以上2 種場景中。對ATT&CK[21]上實際案例的利用情況統計發現,有些惡意軟件僅使用DCC 進行C&C,如Feederbot[22]、Pisloader[23]等;有些惡意軟件將DCC僅用于數據泄露,如FrameworkPOS[6]、Remsec[24]等;同時也有部分復用C&C 信道進行數據泄露的案例,如RDAT[25]、BONDUPDATER[26]等。
DCC 的發展可以概括為3 個階段:第一階段(1998 年—2010 年)是以NSTX[27]、OzymanDNS[28]、Heyoka[29]、PSUDP[30]等工具為代表的攻擊探索階段;第二階段(2011 年—2013 年)是以Feederbot[22]、Morto[31]等惡意軟件為代表的惡意利用階段;第三階段(2014 年—至今)是以APT34、FIN6 等APT組織為代表的組織化攻擊階段。
第一階段,攻擊探索階段。對DCC 的最初運用由隧道協議、傳輸文件開始,其本質為利用DNS數據包進行數據的秘密傳輸。1998 年,Pearson[32]首次描述了DNS隧道的基本情況,實現了利用DNS數據包進行的客戶端與服務器間的簡單通信;2002 年,由Szerb[27]完成的第一個較流行的隧道工具NSTX 使IP over DNS 成為可能,但其正常運行需要創建一個虛擬網絡設備(VDN,virtual network device),并且只能運行在Linux 系統上;2004 年,在Black Hat 大會上,Kaminsky[28]演示了其編寫的OzymanDNS 工具,該工具可以利用DNS 傳輸文件,也可以封裝SSH 隧道(SSH over DNS);2008 年,Miller[16]提出了旨在利用DNS 做C&C 的Reverse DNS,其將shellcode 代碼放入DNS 響應的TXT 資源記錄中,受害設備收到響應并執行后可以主動與服務器建立連接;2009 年,Revelli[29,33]在信道容量上進行了進一步思考提出了Heyoka,指出許多DNS接受域名標簽中的二進制數據,利用二進制編碼可以將帶寬從每字符5 位增加到每字符8 位。同時提出可以使用EDNS0,TXT 響應最多可存儲1 024 B;2010 年,Born[30,34]在Black Hat 上提出PSUDP,使用UDP 增加信道帶寬,指出可以在DNS 消息末尾注入數據而不會影響DNS 服務器解析,從而增加了信道帶寬。這一階段初步實現了利用DNS 數據包對數據的傳輸功能,擴寬了信道容量,但也為惡意活動提供了良好的技術基礎。
第二階段,惡意利用階段。2011 年,Dietrich等[22]分析了第一個基于DCC 的僵尸網絡Feederbot,發現其TXT 應答數據消息塊中使用RC4 流密碼加密(利用DNS 查詢來傳輸密鑰派生參數),同時使用循環冗余校驗保證數據完整性;卡巴斯基實驗室發現利用DNS 進行C&C 的蠕蟲W32.Morto[31],其只請求TXT 記錄,解密后得到IP 地址進而下載文件執行;美國能源局[35]發布白皮書表示可以通過DNS 查詢請求泄露機密信息且難以對其進行檢測。2013 年,Xu 等[36]論證了使用DCC 作為僵尸網絡C&C 通道的可行性,描述并定量分析了包搭載查詢、指數分布等查詢策略,這些策略可用于在網絡級別有效隱藏惡意DNS 活動,并指出DNS 是一個極有效的C&C 信道。這一階段的技術被惡意運用到僵尸網絡等網絡惡意行為中,對網絡安全造成了較嚴重的威脅。
第三階段,組織化攻擊階段。2014 年,APT組織FIN6 的FrameworkPOS[37]使用DNS 請求泄露了5 600 萬張借記卡/信用卡信息,在DNS 查詢中編碼了IP 地址、主機名、進程名等字段;2016 年,Wekby(APT18)的Pisloader[23]使用DNS 協議做C&C 信道發起攻擊;2017 年,OilRig(APT34)開發人員對Helminth[38]不同變體的子域首字符進行更改,進而躲避檢測,其依賴DNS 請求獲得具有指令含義的IP 地址(A 記錄)應答,將欲傳送的竊密文件使用DNS 查詢請求分塊傳送;2018 年,OilRig 將QUADAGENT 用于定向攻擊,初次握手時受害設備會得到C&C 服務器提供的會話標識符和預共享密鑰,并將其保存到注冊表,不必每次通信都進行握手;2019 年,Lab Dookhtegan Telegram Chanel 中泄露了關于APT34 的攻擊工具,其中Glimpse[39-40]可以利用DNS 傳輸指定目錄下的文件;2020 年,QuoIntelligence 發現WINNT(IAPT41)組織自定義Iodine 針對德國化工企業,其DNS 查詢使用Base128 編碼。OilRig 利用RDAT[10]針對中東電信組織,與其之前樣本相比,該樣本僅使用DNS進行C&C 通信而無HTTP 備用信道。Black Lotus Labs 發現Alina POS 編碼信用卡信息使用DNS 查詢泄露,指出DNS 經常不受監控,同時,為了確保在搜索設備的RAM 時準確找到信用卡數據,該惡意軟件引入了Luhn 校驗和算法。APT 組織自制惡意軟件或集成工具發起攻擊活動,逐漸將這一技術納入攻擊中,利用其傳輸敏感信息及進行C&C,攻擊組織化更明顯。圖3 列出了DCC 的發展歷程。

圖3 DCC 發展歷程
定義1DCC=(VictimMachine,DDP,CMD,POLICY,MANS,ConnectionType,δ)由七元組構成,反映的是攻擊者利用DNS 數據包中可定義字段創建的隱蔽信息傳輸通道。
1) VictimMachine 指的是感染了DCC 惡意軟件進而可利用DNS 數據包傳輸數據的受害設備集合,受害設備種類可以是PC、服務器、智能手機、物聯網(IoT,Internet of things)設備等一切當前已存在的、未來可能出現的、具備計算能力和通信能力并可發起 DNS 查詢請求的設備,記為VictimMachine={DCCMalware,S,ACTIVITY}。
DCCMalware 表示運行在受害設備上的惡意程序集合,記為DCCMalware={dccmalware1,dccmalware2,…,dccmal waren},其中dccmalwarei表示運行在VictimMachinei上的惡意程序,n表示受害設備的規模。
S表示DCCMalware 的狀態集合,記為S={s1,s2,…,sn}。
ACTIVITY 表示DCCMalware 的動作集合,記為ACTIVITY={SendData,ReceiveData,ReadData,ProcessData,…} 。
2) DDP(definable DNS packet)指的是可定義的DNS 數據包,記為DDP={QNAME,RDATA,RawUDP}。
QNAME 表示將待傳送信息進行處理后嵌入DNS 查詢區域的QNAME 字段中,可以包含編碼后的待傳送數據、編碼方法、序列號等及其各種組合方式。
RDATA 表示將命令/信息進行處理后嵌入DNS響應區域的RDATA 字段中。
RawUDP 表示將數據處理后嵌入DNS 分組載荷結束與UDP 分組載荷結束為止的空間中(需構造DNS 查詢包)。
3) CMD 表示DCCMalware 可執行的控制命令集合(DCCMalware 可以從RDATA 字段中提取控制命令或其本身硬編碼控制命令),記為CMD={rdata-derived cmd,hard-codedcmd}。
4) POLICY 表示保證數據高效可靠傳輸的策略,記為POLICY={encode,encryption,CRC,query structure,time interval,…}。
5) MANS 表示惡意權威名稱服務器。攻擊者搭建的權威名稱服務器用來托管惡意域名的名稱解析,實現與受害設備集群的通信。
6) ConnectionType表示連接類型,指的是受害設備與MANS 的連接類型。中繼信道是指受害設備通過本地默認解析連接到MANS;直連信道是指受害設備與MANS 通過IP 地址直接連接。
7)δ表示轉換函數,反映了惡意程序收到命令后產生的相應動作及狀態變遷,記為δ:DCCMalware×S×CMD? >DCCMalware×S× ACTIVITY,并滿足δ(dccmalware×si×cmd)=(dccmalware×sj×activity),i≠j。
深入了解惡意軟件的構建機理對于防御而言十分必要,圖4 顯示了DCC 的構建方式及通信過程。攻擊者通過一定手段使VictimMachine 感染DCCMalware 后與其控制的MANS 進行信息交互,通過POLICY 定制的傳輸策略,將信息嵌入DDP傳輸,建立起攻擊者與受控設備可靠、隱蔽的通信橋梁。VictimMachine 可以通過該信道向MANS 泄露信息,MANS 可以通過該信道向VictimMachine發送控制命令,進而使攻擊者獲取敏感信息/控制設備的活動狀態。

圖4 DCC 的構建方式及通信過程
通過對DNS 協議的分析發現,查詢區域中除QNAME 字段外,其他字段內容特定或可變動字符極少/一般不被惡意軟件利用,故QNAME 字段為該區域待傳送信息嵌入的最佳位置;應答區域中RDATA 字段為該區域信息嵌入的最佳位置。對DNS 數據包進行分析發現,DNS 頭中不包含資源記錄或包總長度信息,解析器依賴報頭中指定的資源記錄數量確定解析數據,最后一條解析完成就認為到達了末尾。因此,可在DNS 數據包末尾添加任意數量的數據,RawUDP 為信息嵌入的最佳位置。這樣,就構成了對DNS 數據包的利用。本文利用這些字段構建信道進行隱蔽通信,并對其中涉及的內容進行了詳細的說明(主要分析利用QNAME、RDATA 字段進行構造的模式,利用RawUDP 構造的模式較簡單而不做贅述)。
3.2.1基于QNAME 嵌入的數據回傳
將待傳輸數據嵌入 DNS 協議查詢區域的QNAME 字段中,可以將數據根據POLICY 處理后嵌入。嵌入格式需要遵循QNAME 字段規范,具有標簽,標簽間由句點間隔。每個標簽的最大長度為63 個字符,由字母、數字、連字符組成,且必須以字母或數字開頭、結尾。QNAME 的最大長度為253 個字符。受害設備將數據編碼后嵌入,可以使用Base64、Base32、Base16 及二進制、十六進制等方式進行編碼,也可以使用XOR、AES 等方式進行加密。將DNS 查詢包構造完成后,利用DNS 查詢請求將其傳輸到攻擊者搭建的MANS;MANS 接收識別DNS 查詢請求包,從QNAME 字段中按照對應的POLICY 提取并恢復數據,得到欲泄露的敏感信息或竊取的重要文件等。
以APT34 中的Helminth[38]為例,其DNS 查詢格式為00 <系統標識符><文件名字符><序列號>

圖5 真實案例查詢請求情況
再如,對APT34 核心組件Glimpse[39]進行復現,該組件中的一種DNS 查詢格式為

圖6 使用wireshark 抓包觀察情況
對該組織涉及的其他惡意軟件DNS 查詢情況進行統計得到表1,可以發現每種惡意軟件具備獨有的子域名構成方法,子域名中不僅包括編碼后的數據,還包括一些序列號、隨機數等輔助字串。同時,域名“go0gie.com”與“google.com”較類似。對ATT&CK[21]上涉及的全部惡意軟件進行統計發現,編碼方式主要集中在Base64、Base32 及Hex編碼3 種;每種惡意軟件采用一種或幾種固定的子域名結構來傳送數據,一般包含輔助傳輸字串;可以一次傳遞一位字串[41],也可以傳輸較多信息。當數據較大時,可分塊傳送。

表1 APT34 惡意軟件域名構成情況舉例
3.2.2基于RDATA 嵌入的命令獲取
將待傳輸數據嵌入 DNS 協議應答區域的RDATA 字段中,根據請求確定響應資源記錄類型(A/TXT/AAAA 等)。嵌入數據需要符合對應資源記錄的格式規范,可以將數據根據POLICY 處理后嵌入。例如,A 記錄用來指定主機名對應的IP 地址,只能使用IP 地址;TXT 記錄為域名設置說明,可使用文本信息,單個TXT 記錄不超過255 B(不同服務商的實際限制會有所區別)。此外,還有CNAME 記錄、NULL 記錄、MX 記錄等,這里不做贅述。構造完成DNS 響應包后,將其發送至受害設備。受害設備接收識別DNS 響應包,從RDATA字段中按照對應的POLICY 提取并恢復控制命令,得到rdata-derived cmd。DCCMalware 根據rdata-derived cmd 通過δ產生相應動作及狀態變遷。
同樣以APT34 的Helminth[38]為例,由于該樣本請求A 記錄,DNS 應答格式為IP 地址。其響應33.33.x.x 表示為提供腳本文件名,指示惡意軟件開始下載數據以保存到批處理腳本;33.33.33.33 指示惡意軟件停止下載數據并執行下載的批處理腳本。真實案例響應情況如圖7 所示,33.33.97.97 中97.97 指的是創建一個名為aa.bat 的文件,數字97 表示“a”的ASCII字符,可以利用這樣的字符轉換來傳遞信息及指令。

圖7 真實案例響應情況
再如,以復現的Glimpse[39]為例。如圖8 所示,通過查詢子域名 000564b81fdbDe0000A2C09T.fengrou2019.club 的TXT 記錄發現,Glimpse 使用Base64 將命令編碼在應答TXT 記錄中,TXT 記錄中 d2hvYW1pJmlwY29uZmlnIC9hbGw=解碼后為“whoami&ipconfig/all”。

圖8 Glimpse 查詢響應情況
為了解實際的資源記錄利用情況,本文對一些主要的惡意軟件及工具情況進行了統計,結果如表2 和表3 所示。從表2 和表3 可以發現,惡意軟件應答字段記錄類型一般為A、TXT、AAAA 記錄等;工具應答字段記錄類型一般為TXT、CNAME、NULL 記錄,以獲得更大的帶寬,傳遞更多信息,可運行在Linux及Windows 等主流操作系統上。

表2 惡意軟件利用應答字段記錄類型情況

表3 工具利用應答字段記錄類型情況
3.2.3兩者關系
基于QNAME 嵌入的數據回傳與基于RDATA嵌入的命令獲取兩者有一定關系但并不相同,前者主要利用查詢泄露數據,后者主要利用應答獲取命令,具體說明如下。
基于QNAME嵌入的數據回傳主要為將處理后的數據利用DNS 查詢的QNAME 字段進行泄露,對應的DNS 響應一般為固定或連續的IP 地址應答。數據泄露場景對應應答情況如表4 所示,其響應并不嵌入命令,而是使用相同或連續的IP 地址。例如,xHunt 的應答IP 相同,Glimpse 的應答IP 呈現遞增趨勢,避免產生大量NXDOMAIN過于異常的情況。

表4 數據泄露場景對應應答情況
基于RDATA 嵌入的命令獲取主要為將處理后的數據利用DNS 響應的RDATA 字段進行傳輸,進而使受害設備可以通過響應獲取命令,與響應對應的查詢本身不用來泄露過多數據,而是一種獲取命令的請求方式。如圖 8 所示,000564b81fdbDe 0000A2C09T.fengrou2019.club,其中“000564b81f dbDe”為GUID,“0000A2”為隨機字符,“C”為固定位,“0”為數據包表示偏移量,“9”為操作類型偏移量,“T”為固定位。可見,在獲取命令的DNS 響應所對應的DNS 查詢中,并沒有泄露過多數據。
為了保證數據可以從受害設備完整、隱秘地傳輸到MANS 上,保證命令成功下達到受害設備上,成功竊取需要的數據/獲得有效的命令,攻擊者在傳輸過程中使用POLICY 來保障信息的可靠傳輸。
1) 加入輔助傳輸字串/使用循環冗余校驗(CRC,cyclic redundancy check)機制,保證傳輸數據完整性。由于DNS 協議一般封裝在UDP 數據包中傳輸,UDP 只提供數據的不可靠傳輸[42]。服務器可能收到其他DNS 查詢請求或網絡時延造成數據無法按正常順序傳輸等情況,導致數據丟失/亂序,進而恢復失敗。為避免此現象發生和信息失效,攻擊者通常會在子域名中引入輔助傳輸字串。如表1 所示,子域名構成時可以加入一些如序列號、序列總數、文件名等輔助傳輸字串來保證可靠通信。在接收端,識別構造結構,按照對應的方式進行處理,得到最終的傳輸信息;同時,攻擊者也會在應答中引入CRC 機制等來保證命令/信息傳遞的完整性。例如,最初的Feederbot 就在其DNS 應答TXT 記錄中引入了CRC32,以此來保證僵尸網絡命令的完整傳輸。
2) 在子域名/應答資源記錄嵌入過程中,引入編碼/加密機制,保護數據機密性。從受害設備中獲取并利用DNS 查詢傳遞的信息可能為設備本身信息或敏感信息等,為了使數據隱秘傳輸/不被感知,這類信息一般不在網絡上明文傳輸。攻擊者引入編碼技術,對待傳送的信息進行編碼后嵌入,再逐一傳送。同時,攻擊者欲竊取內容,通常不能完全符合DNS 域名的語法規定,需要對目標內容執行編碼轉換,使轉換后的內容基本符合DNS 協議規范。在數據保密性要求較高的場景下,可以引入AES等加密算法,對傳輸的數據進行加密。但在傳送之初,雙方要協商好通信密鑰,以便在接收端可以順利解密出信息。
基于對構建機理的深入剖析可以發現,DCCMalware 構建的DNS 查詢及響應數據包與正常的DNS 數據包有所差別。由于DNS 協議信息承載量較小,QNAME 及RDATA 的長度都有限制,例如請求中QNAME 長度不能超過253 個字符。若要傳輸成百上千的MB 級別的文件,勢必要發出數十萬甚至上百萬規模的DNS 請求。同時,需要對傳輸內容進行編碼,從而不可避免地導致若干異常。從攻擊者角度看,弱化異常勢必會降低攻擊效率。為了保證攻擊效果,異常難以避免。防御方需要提取其中難以繞過的異常點進行檢測,從而達到較良好的檢測效果。通過對構建機理的深入剖析及對檢測論文的通讀,目前主要的檢測方向是針對DDP 及請求應答情況的異常進行分析。將異常特征概括歸為單域名異常及多域名統計異常2 類,并分別對其進行闡述。
4.1.1單域名異常
異常點可以反映在基礎特征、可讀性特征、結構性特征3 個方面,下面進行詳細介紹。
1) 基礎特征
DNS 數據包長度/UDP 長度。DNS 協議一般封裝在UDP 數據包中傳輸且DNS 分組載荷結束與UDP 分組載荷結束的位置一致。攻擊者為了傳輸信息,可能會在DNS 分組載荷結束與UDP 分組載荷結束之間嵌入數據,造成與正常DNS 數據包的差異。例如Iodine 具備直連模式,當發現可以與MANS通過IP 地址直接連接時,就會切換到該模式,在DNS 分組載荷結束與UDP 分組載荷結束之間嵌入數據,使用RawUDP 進行通信。
子域名長度。攻擊者將待泄露數據處理后嵌入查詢中的QNAME 字段傳輸,會嘗試在子域名中放入盡可能多的數據來獲得更高的帶寬,導致與正常子域名在長度上的差異性。如表 1 所示,DCCMalware 的子域名一般較長,而正常的域名如“scholar.google.com”,其中子域名“scholar”一般較短。
子域名數字數量/占比、子域名大寫字符數量/占比。將數據加密/編碼后,會產生更多的大寫字符及數字字符,導致與正常子域名的差異性。如圖5所示,子域名005aa003P3T647071636F6E626C316E 385C61646D696E7369747261746F 中大寫字符和數字字符的比例較高,而在正常域名如“store.google.com”中,“store”不含大寫字符及數字字符。同時,部分情況下子域名允許使用二進制數據,攻擊者可能用此編碼方式來擴展信道帶寬,從而使其具備較高的數字占比。
子域熵。正常子域名通常是一些看起來有意義的字符串,而惡意子域名通常是被加密/編碼后看起來無意義的數據。一般地,信息被編碼后會呈現更大的熵,此差距可以成為衡量正常子域名與惡意子域名的一個指標。
C2 域名欺騙性。一般地,默認使用Alexa top列表中的域名發出的請求為正常請求。攻擊者為使C2 域名看起來更正常,可能會為其MANS 注冊具備欺騙性的域名。如表1 所示,惡意軟件使用了類似google.com的go0gie.com域名,從而呈現欺騙性。因此可以通過計算惡意域名與常用域名的相似性來進行判斷。
資源記錄分布及長度。DNS 一般用于域名與IP地址間的映射,所以請求記錄通常為A/AAAA 記錄。對主要的DCCMalware 使用的資源記錄進行統計,如表2 和表3 所示,DCCMalware 也可能會使用TXT、CNAME 等記錄進行信息傳遞,造成與正常請求的差異。同時,由于要將待傳遞信息嵌入資源記錄中,如圖8 所示,所以資源記錄的長度也是一個重要的衡量指標。
2) 可讀性特征
子域名包含單詞數、子域名中最大單詞長度。正常子域名一般由多個單詞構成且最大單詞長度合理,惡意域名中提煉不出單詞或最大單詞長度異常。例如“zhidao.baidu.com”為正常域名,5624b81f001dbe0000A9C82T.EBB466767667256666 7725E88E9A23FBFD932F3F64079E4F730B7986CC 06.33333210100A.fengrou2019.club 為惡意域名。可以看出,正常域名、惡意域名在這2 個方面的差異性。
子域名單/雙/三字母頻率。正常子域名一般屬自然語言遵循Zipf 定律,而惡意子域名字符頻率分布更均勻。
3) 結構性特征
子域名標簽數量。正常子域名一般含有較少標簽,而惡意域名可能具有較多標簽,所以標簽數量也是一個可以參考的指標。例如,正常域名“map.baidu.com”,子域名具有一個標簽;惡意子域名如表1 所示,ALMA Dot 子域名具有7 個標簽。
平均/最大標簽長度。正常子域名標簽一般較短,惡意子域名可能含有較長的標簽長度。正常域名如“tieba.baidu.com”,其中標簽“tieba”僅含5 個字符。惡意子域名如圖6 所示,Glimpse 查詢請求中的第二個標簽表示傳輸內容,其標簽長度為60 個字符,明顯較長。
4.1.2多域名統計異常
同位相同字符數/最大公共子串長度。同位相同字符數是指2 個同域子域名中相對位置相同的字符數,最大公共字串長度指的是2 個同域子域名中所有公共子串中最長的公共子串長度。正常子域名沒有固定結構,而同一次惡意活動中的子域名一般具有相同結構,如表1 所示。相應地,正常流量幾乎不會有大量字符相同的情況,也不會具備較長的公共子串。而惡意子域名所攜帶的標志信息會成為它們之間的相同字符,且可能存在較長的公共子串。以Glimpse 為例,圖9 給出了部分查詢流量,它們具備相同的公共子串。

圖9 惡意子域名間相同字符情況
最大公共子串是否包含數字/字母。正常域名間一般不具備相似的結構特征,而同一次惡意活動惡意域名間一般具備相似結構。如表 1 中的BONUPDATER 所示,同一次攻擊在特定位置上具有“4”“B007”這樣相同的字母及數字,而幾個正常域名間一般不具備這樣的特征,造成正常域名與惡意域名間的差異。
同域IP 離散性。正常域名中同域子域名對應IP 地址較離散,如正常域名www.baidu.com 對應應答IP 地址為39.156.66.14,域名map.baidu.com 對應 應 答 IP 地 址 為 111.206.208.32,域 名tieba.baidu.com 對應應答IP 地址為112.34.111.194。對于惡意域名請求,攻擊者會制定MANS 對查詢的應答規則,一般使用固定IP 或遞增IP 應答。如表4所示,惡意軟件Wekby-xHunt 同域應答IP 相同,APT34-Glimpse 同域應答IP 遞增,從而造成正常域名與惡意域名間同域IP 應答差異。
DNS 數據包總數。在正常情況下,例如在企業局域網中,每天的DNS 數據包總數一般在一個固定區間范圍內。當DCCMalware 運行時,一般會產生較大量的DNS 查詢,DNS 數據包總數則可能超出正常情況下的統計區間。
DNS 請求頻率。在正常情況下,一般為手動輸入DNS 發起請求,請求頻率有限;在惡意情況下,由于DNS 協議可傳輸字符有限,惡意軟件欲傳輸大文件時,需要大量DNS 請求才能完成傳送。為提高攻擊效率,可能會使用較高頻率的請求來泄露數據。所以,DNS 請求頻率也是一個比較重要的指標。
DNS 請求應答比。在正常情況下,DNS 請求應答比大概為1:1;在惡意情況下,可能只利用DNS請求來泄露數據而不設置應答,大量的無應答構成異常。
應答碼。應答碼RCODE 表示對應響應的狀態。在正常DNS 請求與應答中,應答碼一般為0,表示DNS 請求應答過程成功完成。當應答碼為3 時,表示此域名沒有任何類型的解析記錄。在惡意軟件如Heyoka 中,其將響應設為應答碼為 3 的簡單NXDOMAIN 應答。當利用其傳輸數據產生大量請求時,會伴隨著大量NXDOMAIN 應答。所以,應答碼的情況也可以作為一個參考指標。
同域請求數量/占比。在正常情況下,一般良性的域不太可能被同一設備經常反復查詢;在惡意情況下,惡意軟件需要對同一域名反復查詢來泄露信息。所以,同域請求數量/占比是一個可以用來衡量異常的指標。
由于DCC 在進行惡意活動過程中產生的流量與正常流量有所差別,因此可以利用這些異常點對惡意活動進行檢測。研究人員對檢測方式進行了一系列研究,利用基于匹配的方法及機器學習、深度學習等方法進行檢測。接下來,將對這些檢測方法涉及的具有代表性的論文進行逐一說明并進行對比,提出相關問題。
2010 年,Born 等[43]通過分析DNS 查詢和響應中域名單字母、雙字母和三字母的字符頻率檢測DCC。可以使用該方法檢測的原因是自然語言遵循Zipf 定律,而隱蔽信道流量的字符頻率分布更均勻。該文使用n-gram 字符頻率分析法,對前100 萬個頂級域名及Iodine、Dns2tcp 等隱蔽信道工具進行分類,清楚地顯示了合法流量和隱蔽信道傳輸數據的區別,但僅使用字符頻率的差別來進行二分類的方法并不靈活,容易繞過。Karasaridis 等[44]提出了一種基于流的檢測方法,根據DNS 數據包大小分布差異性和交叉熵等統計屬性近實時檢測異常。2013 年,Ellens 等[45]結合了流量信息和統計方法進行異常檢測,特別在流方面使用了每個流的字節數、每個流的數據包數、每個數據包的字節數和流持續時間等特征,通過閾值法、Brodsky-Darkhovsky 法、分布法并進行結合,實現了5 個檢測器,并對其進行比較,指出不同場景適合不同方法。2014 年,Kara等[46]全面分析了惡意載荷分布位置,提出了一種基于資源記錄分布情況來檢測DCC 的方法,并使用近實時數據評估了其有效性。
傳統檢測方式一般利用基于規則的靜態閾值[47],其檢測方法不靈活、誤報率高、易被繞過。隨著機器學習的發展,使用其賦能安全檢測的研究逐漸進入大眾視野。有針對惡意域名檢測的論文[48-49],也有專門針對DCC 檢測的論文。在DCC 檢測方面,研究人員做了不少工作,但也存在一些較棘手的問題。惡意活動一旦被發現,攻擊者控制的DNS 服務器很容易被關停,造成活性樣本較少,真實攻擊數據匱乏,對DCC 的檢測面臨更嚴峻的數據集問題。對利用經典機器學習檢測發展以來的代表性論文進行總結歸納,厘清發展趨勢,提出存在問題,更好地服務于防御工作。
在非監督學習檢測方面,2011 年,Dietrich 等[22]提出利用RDATA 差異性及通信行為差異性兩方面特征,使用K-均值聚類的方式在網絡流量中檢測C&C 信道,實驗結果顯示無誤報,同時也可以實現對未知樣本的檢測。
在監督學習檢測方面,2013 年,Aiello 等[50]將傳統貝葉斯引入DCC 檢測中,使用查詢、響應包大小及統計特征共12 個特征進行檢測,并評估了其檢測方法的可靠性;同年,章思宇等[51]通過分析DCC 流量特性,提取可區分特征12 個,利用J48決策樹、樸素貝葉斯和邏輯回歸3 種方法分別進行訓練檢測,可以檢測已經訓練的及未訓練的隱蔽信道,但其訓練集樣本數量較少,導致準確率不高。2016 年,Buczak 等[52]使用隨機森林算法進行檢測,對未知工具的檢測率僅有95.89%。2017 年,Liu 等[53]使用支持向量機、決策樹和邏輯回歸3 種算法綜合了4 種特征(18 種行為特征)針對已知隱蔽隧道工具集進行二分類檢測,獲得了較高的準確率,并指出使用SVM 算法的檢測效果最佳。2018 年,Almusawi 等[54]提出了一種多標簽支持向量機方法來檢測和分類隱蔽信道,并與多標簽貝葉斯分類器比較,不僅區分了正常流量及惡意流量還對FTP、HTTP 及POP3 等協議進行了分類[55-56],但是只使用了隱蔽信道工具進行檢測,未涉及對惡意軟件的檢測情況。2019 年,Nadler 等[57]提取了7 種特征訓練正常流量,通過iforest 構建異常檢測模型準確識別現有工具及惡意軟件流量。2020 年,Ahmed 等[58]描繪了科研機構網絡與校園網的DNS 流量各項特征的密度圖,基于密度圖提出檢測特征并使用iForest 算法進行檢測。實驗主要針對利用DNS 查詢進行數據泄露的檢測,使用竊密工具DET 進行訓練,對DET 及未訓練的惡意軟件進行檢測,達到了較高的準確率。
使用機器學習進行檢測不可避免地會提到使用方法及數據集問題,對于實驗正確性及效果都有一定程度的影響。本文對使用經典機器學習進行檢測的論文進行通讀,對重點論文利用的方法、訓練集、測試集及結果進行統計對比,把握基于機器學習的檢測發展情況。
從表5 可以發現,目前論文的檢測方法涵蓋了監督學習及非監督學習方法。決策樹及支持向量機等是研究者較為熱衷的檢測算法;訓練集多使用隱蔽信道工具進行訓練,測試集方面涵蓋針對已知數據集[53-54]及已知、未知數據集[51-52,57-58]的檢測;部分論文使用隱蔽信道工具進行實驗,針對真實攻擊的檢測較為匱乏[51,53-54]。

表5 利用經典機器學習進行檢測的各主要論文情況
目前,許多論文中研究人員使用DCC 工具生成的惡意流量進行檢測工作,缺乏對真實攻擊流量的檢測。對工具產生良好的檢測效果,并不意味著該檢測方式可以很好地應對真實攻擊及未知攻擊,研究者應當著重關注對真實DCC 攻擊的檢測情況。
由于經典機器學習檢測方法面臨特征選取問題,特征選擇依賴于專家知識只能提取有限的特征,但實際流量中可能還含有一些隱含的統計特征未被人發現,故有學者提出使用深度學習進行DCC檢測。早在2009 年,Hind[59]就首次提出使用人工神經網絡(ANN,artificial neural network)構建分類器對DCC 工具進行檢測的想法。隨著深度神經網絡近幾年逐步發展,研究者開始使用深度學習對DCC 進行檢測。2019 年,Liu 等[60]將流量以字節為單位轉換成向量矩陣,每一個字節通過獨熱編碼(One-Hot)轉換為一個257 維的向量,通過CNN模型對流量進行檢測,并與SVM 及邏輯回歸等方式進行對比,得到了較好的準確率及召回率。2020 年,張猛等[61]對CNN 進行了改進形成RDCC-CNN 方法,提取了48 個表征元素,將其轉換成灰度圖片表征DNS 流量數據,對隱蔽信道進行檢測,達到了很好的準確率及誤報率。同年,Wu 等[62]提出利用深度神經網絡自動學習特征進行檢測,學習正常DNS 流量的特征,通過計算正常樣本與惡意樣本之間的均方誤差來檢測DCC。本文對深度學習檢測方面的2 篇主要論文進行分析,如表6 所示,主要針對使用方法、訓練集、測試集實驗結果等進行對比。
從表6 可以發現,2 篇論文都使用CNN 及其改進算法進行檢測,檢測方法較單一;2 篇論文都是針對已知的數據集進行檢測,未體現針對未知樣本的表現情況;完全針對隱蔽信道工具進行實驗,缺乏對真實攻擊的檢測。同時,針對真實攻擊、未知攻擊的檢測并不明朗,還有較廣泛的思考空間及待挖掘價值。

表6 利用深度學習檢測方法進行檢測的各主要論文情況
DCC 作為一種有效的攻擊手段,已經被用于大量的APT 攻擊中,對眾多領域都造成了較嚴重的危害,是網絡安全領域關注的熱點。隨著萬物互聯時代開啟和5G 技術的發展,聯網設備數量將持續攀升,DCC 可能帶來更嚴重的數據泄露及各類安全問題。
本文回顧DCC 的發展歷程,將其發展歷程分為3 個階段,描繪了其演進過程,指出攻擊組織化及隱蔽信道工具惡意化趨勢;界定范圍,形式化定義了DCC,提出七元組并對構建機理進行了深入的剖析;提取DCC 構建機理中難以改變的異常特征,進而更有針對地應對DCC,更好地服務于檢測工作。從3 個方面(包括傳統檢測方法、經典機器學習檢測方法及深度學習檢測方法)對已有的檢測工作進行歸納分析發現,傳統檢測方法面臨閾值設置易繞過、重要特征提取不全面等問題,可能導致對未知攻擊檢測效果不理想;經典機器學習檢測方法面臨真實攻擊數據匱乏、部分論文使用特征及數據集不全面的問題;深度學習檢測方法起步較晚,除面臨數據集匱乏問題,其涉及重點論文使用相同數據集進行訓練、檢測,對真實及未知攻擊的檢測較為匱乏,有較廣闊的研究空間。未來研究可能會將傳統方式與人工智能方式相結合進行檢測,取長補短,達到更好的檢測效果。
考慮到當前互聯網發展及DCC 發展的新趨勢,研究人員務必對其進行深入研究,完善防御體系,協同安全研究團隊及數據分析團隊共同應對日趨嚴重的網絡威脅。