在2017年4月份，我們釋出了一篇關於惡意程式的詳細報導，該程式使用DNS隧道與C＆C伺服器進行通訊。這項研究促使我們開發了一種技術來檢測類似的威脅，這使得我們能夠使用DNS隧道技術來收集大量的惡意軟體樣本。

在本文中，我們將研究一些使用DNS隧道技術的典型的惡意程式。卡巴斯基實驗室的安全產品使用通用的（'Trojan.Denes.UDP.C＆C'或'Backdoor.Win32.Denis。*'）判斷方法或人為檢測的方法來檢測它們。

Trojan.Win32.Ismdoor.gen

下面的第一個惡意軟體有多層的C＆C通訊協議結構，類似於OSI模型。由於這點將它與文章中的其他木馬區分開來，而Trojan.Win32.Ismdoor.gen的創造者顯然在設計和開發方面付出了很多努力。

當然，這個木馬的傳輸層使用了DNS隧道技術。儘管DNS伺服器配置和實際的協議允許這個值更大，但發出的'資料包'的長度還是被限制為60個字元，C＆C伺服器的命令被解析成IPv6地址。

典型的傳送到C＆C伺服器的查詢如下所示：

n.n.c...com

圖 傳輸層請求和響應的結構

在DNS隧道傳輸層之上有一個會話層協議，這意味著其具有交換“短”和“長”資料包的功能。不同於傳輸層的是，它有一個機制來檢查丟失的訊息。當全部的包傳送並接收後，傳輸層會話終止，會話層通過檢查每個傳送的資料包是否並正確接收從而關閉。這一切都取決於伺服器決定使用哪個選項;例如，在受感染的計算機上使用“長”資料包協議上傳檔案。

圖 短訊息交換協議的例子

短訊息

在這個級別上，程式的操作可以分解為五個步驟：

• 告訴伺服器會話ID
  
• 用資料包傳送訊息
  
• 傳送已傳送資料包的序號
  
• 接收即將收到的資料包序號
  
• 接收即將收到的資料包
  

一個會話例子如下圖：

1.告訴伺服器會話ID

每次通訊會話建立時，程式都會生成一個GUID並將其傳送到伺服器。然後使用此GUID來標識該會話中的所有通訊，並總是將其寫入第三級域名的位置。在這種情況下，url的結構如下：

n.n.c.<Session ID>.<Server domain>.com

訊息A67DDB8A2A17334765443253702AA3就是一個積極的回應。否則，GUID再次傳送到伺服器。

2.用資料包傳送訊息

正如我們前面所說，選定的通訊機制對資料包大小施加了一定的限制。發出的訊息被分成60個位元組長的資料包，並以URL的形式傳送：

..dr.. .com

得到的響應必須是A67DDB885A3432576548A2A3707334。

3.傳送已傳送資料包的序號

當所有資料包傳送成功後，它們的序號將作為查詢傳送，格式如下：

n..f...com

應該注意的是，分組編號從0開始, 得到的響應為20202020202020202020202020202020。

4.接收即將收到的資料包序號

這一步的URL格式如下：

n.n.fc...com

響應必須採用以下格式：

A67D: DB8: 85A3: 4325: 7654: 8A2A ::

5. 接收即將到來的資料包

接收下一個資料包的請求如下所示：

www. .s. ..com

即將收到的的訊息以16位元組的IPv6資料包的形式出現。

長訊息

在這種情況下，與伺服器的通訊可以分解成以下步驟：

傳送檔案被分割的資料包的數量;

傳送檔案；

定期向伺服器傳送查詢以檢查丟失的資料包；

重發丟失的資料包。

1.傳送資料包的數量

查詢： n....com

響應： A67DDB8A2A17334765443253702AA3

2.傳送檔案

查詢： ..d...com

響應：伺服器沒有回覆此訊息，或傳送“伺服器失敗”。

3.定期向伺服器傳送查詢以檢查丟失的資料包

程式定期地將下面的查詢傳送到伺服器：

uff.< Number of packets >..com

響應：20202020202020202020202020202020

之後，實現上一部分中的“接收即將到來的資料包數量”和“接收即將到來的資料包”。

作為響應，傳送伺服器丟失的包的數量（以逗號分隔）。

4.重發丟失的資料包

查詢: ..dl...com

OSI中的表示層負責編碼和解碼訊息，伺服器響應中的IPV4地址段是一個的常規16進位制的ASCII字串，向伺服器傳送查詢包含的DNS查詢，使用重新定義的索引表，並用Base64編碼。

圖 第一條訊息和它的表示層的示例

應用程式層只是一組類似於C＆C伺服器的類GET查詢：

• 檢查連線：查詢為字串'M：CC？';
  
• 註冊連線：這決定了可用的命令，以及受感染計算機和木馬的ID（M：AV？appId = <...>＆uniqueId = <...>）;
  
• 確定註冊命令；
  

• '泛型'響應（M：ME？appId = <...>＆message = <...>）;
  
• 接收命令（M：GAC？appId = 8）;
  
• 確認命令（M：CR？cd = );
  
• 傳送檔案(M:SF?commandId=CmdResult=|||);
  
• 接收檔案(M:GF?)。
  

如上所述，這個木馬是精心設計和編寫的，有一個經過深思熟慮的通訊系統以及一個有效載荷的豐富功能。下面是一些它的主要命令：

• SI - 傳送有關感染系統的資訊;
  
• RunNewVersion - 更新;
  
• Restart - 重啟；
  
• remove - 刪除；
  
• CreateMimi1Bat - 執行 Mimikatz;
  
• ExecuteKL - 啟用鍵盤記錄器;
  
• RemoveKL - 刪除由ExecuteKL建立的檔案;
  
• GetVersion - 報告木馬的版本;
  
• PauseUpload - 暫停上傳檔案到伺服器;
  
• ResumeUpload - 恢復上傳檔案到伺服器;
  
• PauseDownload - 暫停從伺服器上下載檔案;
  
• ResumeDownload - 恢復從伺服器上下載檔案；
  
• PWS - 截圖;
  
• DownloadFile - 從伺服器下載檔案;
  
• UploadFile - 上傳檔案到伺服器。
  
• 其他可用於木馬的命令負責其操作的邏輯（如改變C＆C地址等）。
  

Backdoor.Win32.ClIEcker

下一個樣本使用了一種不同的工作流，基於ANY DNS 資料包。該機制允許惡意程式從伺服器接收隨機結構的DNS資料包。這個木馬沒有任何邏輯上的子協議 - 只有傳送和接收資料包的請求。我們能夠檢測到這個木馬的幾處不同，接下來我們描述一下這些特徵。

Backdoor.Win32.ClIEcker的一個有趣的特點是如何找到受害者計算機的IP地址 - 它使用了Internet Explorer的COM介面。該木馬包含一系列網頁地址，訪問者在其中可以看到他們自己的IP地址（例如http://www.ip-adress.com）。該木馬隨機選擇其中一個地址訪問，在頁面主體中查詢IP地址後面的字串，並提取該字串。為了儘可能掩蓋這個查詢，木馬還將選擇一個隨機引用地址，並將其用於Internet Explorer的相應請求。

唯一不清楚的是為什麼使用這種複雜的方法，通常，木馬通過向站點返回包含IP地址的字串作為HTML頁面的資料，來找出計算機的IP地址。也許這樣做是為了避免解決這個木馬的IoC列表中的IP地址，或者它可能只是一個從程式碼儲存庫或論壇中進行的無意義的剪下和貼上工作。

更復雜的是，木馬程式支援一個命令，在伺服器請求的情況下，在Internet Explorer中開啟一個網站 - 為此使用形式為“IEXPLORE.EXE

google.com”的簡單呼叫，而不是複雜的COM互動。因此，雖然木馬可能被檢測為Trojan-Clicker，但正如我們在前面的文章中所解釋的那樣，木馬程式通常使用虛擬桌面來執行此操作。

圖 用於解析IP /引用地址和通過COM接收頁面內容的URL地址示例

在發起請求時，描述受害者系統的幾個引數與一個唯一的RC4金鑰一起傳送，該金鑰是使用受害者計算機中的以下資訊建立的：

• 作業系統的版本;
  
• 顯示調變解調器連線是否被使用的邏輯標誌位;
  
• 木馬ID;
  
• 經加密的使用者IP地址;
  
• 反病毒服務程式碼。
  

解釋下最後一點，該木馬包含一個安全軟體列表;每個安全產品在傳送到伺服器的程式碼中都有一個編碼號。例如，所有與McAfee產品相關的程式都將通過反病毒服務程式碼中的標誌0x400表示。

接下來，我們將給出一些命令的描述：

程式碼號為8的命令值得特別注意，因為它包含了木馬的主要功能。它的工作是下載和啟動有效載荷。這個命令有以下的引數：

檔案以TXT格式的DNS資料包中傳輸。

在預設情況下，所有與伺服器進行的通訊均使用基於受害者計算機資訊生成的RC4金鑰進行加密。但是，伺服器可能會要求更改金鑰，並在檔案下載請求中傳送新的金鑰。在任何情況下，生成S盒所需的金鑰都是自己加密的，隨後使用結果字串。

S盒根據分組編號進行修改，因此每個新分組都是唯一的。

解密完成後，使用CRC32檢查生成的檔案的完整性。

Backdoor.Win32.Denis

Backdoor.Win32.Denis具有最簡單的結構和DNS伺服器通訊功能。這個惡意軟體與本文中描述的木馬具有相同的名稱，這是僅有的一點相同之處。

這個惡意程式使用一個DNS格式的資料包與DNS伺服器進行通訊; 在這種格式中，響應大小被限制為4位元組。所有跡象表明這是一個常規的木馬下載器，並且下載檔案的速度很慢，傳送到伺服器的訊息的典型格式如下所示：

IC...

“Container”域指的是木馬程式的打包形式,其結構會因命令和響應而變化很大。UID是長度為0x20個位元組長度的使用者ID，它是一個Base32編碼的字串，經解碼後具有以下的結構：

“container”也是一個Base32編碼的字串：

在這裡一共有四種型別的容器，木馬根據收到的命令和執行結果確定需要哪一個：

命令

從命令的描述可以看出，這個木馬的目的是下載和啟動檔案。

本文由看雪翻譯小組 fyb波 編譯，來源securelist 

轉載請註明來自看雪社群