DNS 隐蔽信道综述
2021-06-04刁嘉文方滨兴崔翔王忠儒甘蕊灵冯林姜海
刁嘉文，方滨兴,，崔翔，王忠儒，甘蕊灵，冯林，姜海
（1.北京邮电大学可信分布式计算与服务教育部重点实验室，北京 100876；2.广州大学网络空间先进技术研究院，广东 广州 510006；3.中国网络空间研究院信息化研究所，北京 100010；4.北京丁牛科技有限公司，北京 100081）
1 引言
域名系统（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) 对未来的发展趋势进行了展望，旨在从整体角度发现重点问题，为研究人员提供进一步研究的方向。
2 DCC 威胁模型与发展历程
2.1 威胁模型
由于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]等。
2.2 发展历程
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 发展历程
3 DCC 构建机理
3.1 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。
3.2 构建机理
深入了解恶意软件的构建机理对于防御而言十分必要，图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 查询中，并没有泄露过多数据。
3.3 DCC 的高效可靠通信策略
为了保证数据可以从受害设备完整、隐秘地传输到MANS 上，保证命令成功下达到受害设备上，成功窃取需要的数据/获得有效的命令，攻击者在传输过程中使用POLICY 来保障信息的可靠传输。
1) 加入辅助传输字串/使用循环冗余校验（CRC,cyclic redundancy check）机制，保证传输数据完整性。由于DNS 协议一般封装在UDP 数据包中传输，UDP 只提供数据的不可靠传输[42]。服务器可能收到其他DNS 查询请求或网络时延造成数据无法按正常顺序传输等情况，导致数据丢失/乱序，进而恢复失败。为避免此现象发生和信息失效，攻击者通常会在子域名中引入辅助传输字串。如表1 所示，子域名构成时可以加入一些如序列号、序列总数、文件名等辅助传输字串来保证可靠通信。在接收端，识别构造结构，按照对应的方式进行处理，得到最终的传输信息；同时，攻击者也会在应答中引入CRC 机制等来保证命令/信息传递的完整性。例如，最初的Feederbot 就在其DNS 应答TXT 记录中引入了CRC32，以此来保证僵尸网络命令的完整传输。
2) 在子域名/应答资源记录嵌入过程中，引入编码/加密机制，保护数据机密性。从受害设备中获取并利用DNS 查询传递的信息可能为设备本身信息或敏感信息等，为了使数据隐秘传输/不被感知，这类信息一般不在网络上明文传输。攻击者引入编码技术，对待传送的信息进行编码后嵌入，再逐一传送。同时，攻击者欲窃取内容，通常不能完全符合DNS 域名的语法规定，需要对目标内容执行编码转换，使转换后的内容基本符合DNS 协议规范。在数据保密性要求较高的场景下，可以引入AES等加密算法，对传输的数据进行加密。但在传送之初，双方要协商好通信密钥，以便在接收端可以顺利解密出信息。
4 DCC 的检测方法
4.1 异常点
基于对构建机理的深入剖析可以发现，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 在进行恶意活动过程中产生的流量与正常流量有所差别，因此可以利用这些异常点对恶意活动进行检测。研究人员对检测方式进行了一系列研究，利用基于匹配的方法及机器学习、深度学习等方法进行检测。接下来，将对这些检测方法涉及的具有代表性的论文进行逐一说明并进行对比，提出相关问题。
4.2 传统检测方式
2010 年，Born 等[43]通过分析DNS 查询和响应中域名单字母、双字母和三字母的字符频率检测DCC。可以使用该方法检测的原因是自然语言遵循Zipf 定律，而隐蔽信道流量的字符频率分布更均匀。该文使用n-gram 字符频率分析法，对前100 万个顶级域名及Iodine、Dns2tcp 等隐蔽信道工具进行分类，清楚地显示了合法流量和隐蔽信道传输数据的区别，但仅使用字符频率的差别来进行二分类的方法并不灵活，容易绕过。Karasaridis 等[44]提出了一种基于流的检测方法，根据DNS 数据包大小分布差异性和交叉熵等统计属性近实时检测异常。2013 年，Ellens 等[45]结合了流量信息和统计方法进行异常检测，特别在流方面使用了每个流的字节数、每个流的数据包数、每个数据包的字节数和流持续时间等特征，通过阈值法、Brodsky-Darkhovsky 法、分布法并进行结合，实现了5 个检测器，并对其进行比较，指出不同场景适合不同方法。2014 年，Kara等[46]全面分析了恶意载荷分布位置，提出了一种基于资源记录分布情况来检测DCC 的方法，并使用近实时数据评估了其有效性。
4.3 经典机器学习方法
传统检测方式一般利用基于规则的静态阈值[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 攻击的检测情况。
4.4 深度学习检测方法
由于经典机器学习检测方法面临特征选取问题，特征选择依赖于专家知识只能提取有限的特征，但实际流量中可能还含有一些隐含的统计特征未被人发现，故有学者提出使用深度学习进行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 利用深度学习检测方法进行检测的各主要论文情况
5 结束语
DCC 作为一种有效的攻击手段，已经被用于大量的APT 攻击中，对众多领域都造成了较严重的危害，是网络安全领域关注的热点。随着万物互联时代开启和5G 技术的发展，联网设备数量将持续攀升，DCC 可能带来更严重的数据泄露及各类安全问题。
本文回顾DCC 的发展历程，将其发展历程分为3 个阶段，描绘了其演进过程，指出攻击组织化及隐蔽信道工具恶意化趋势；界定范围，形式化定义了DCC，提出七元组并对构建机理进行了深入的剖析；提取DCC 构建机理中难以改变的异常特征，进而更有针对地应对DCC，更好地服务于检测工作。从3 个方面（包括传统检测方法、经典机器学习检测方法及深度学习检测方法）对已有的检测工作进行归纳分析发现，传统检测方法面临阈值设置易绕过、重要特征提取不全面等问题，可能导致对未知攻击检测效果不理想；经典机器学习检测方法面临真实攻击数据匮乏、部分论文使用特征及数据集不全面的问题；深度学习检测方法起步较晚，除面临数据集匮乏问题，其涉及重点论文使用相同数据集进行训练、检测，对真实及未知攻击的检测较为匮乏，有较广阔的研究空间。未来研究可能会将传统方式与人工智能方式相结合进行检测，取长补短，达到更好的检测效果。
考虑到当前互联网发展及DCC 发展的新趋势，研究人员务必对其进行深入研究，完善防御体系，协同安全研究团队及数据分析团队共同应对日趋严重的网络威胁。
