這次不是Mirai的變種：針對新型Botnet Torii的分析
責編：gltian ｜2018-09-29 13:13:27概述
2018年是Mirai和QBot變種不斷涌現的一年。任何一個腳本小子，都可以對Mirai源代碼稍作修改，給它起上一個新名稱，然后將其作為新的僵尸網絡發布。
在過去的一周里，我們一直在監測一個新型的惡意軟件，我們稱之為Torii。與Mirai和其他目前已知的僵尸網絡不同，它使用了一些比較高級的技術。
與絕大多數IoT僵尸網絡不同，這一新型的僵尸網絡在成功入侵設備之后，會增強其隱蔽性和持久性。它不會像一般的僵尸網絡那樣，攻擊網絡中的其他設備，也不會挖掘加密貨幣。相反，它具有一系列非常全面的功能，可以用于泄露敏感信息。其具有的模塊化架構，能使用多層加密通信，獲取命令或可執行文件并執行。
此外，Torii可以感染多種架構的設備，并具有良好的兼容性，包括MIPS、ARM、x86、x64、PowerPC、SuperH等，是目前為止我們所見過的兼容范圍最廣的惡意軟件。
由于我們在持續監測這種威脅，根據監測結果，我們發現其自2017年12月以來就開始活動，甚至活動時間可能更早。
最后，我們對@VessOnSecurity的研究成果表示感謝，他在Twitter上發表了一篇關于該樣本的分析，他是從自己的蜜罐上獲取到的這一樣本。
根據這位安全研究人員的說法，這一僵尸網絡從Tor出口節點對他的蜜罐進行了Telnet攻擊，因此我們決定將這個僵尸網絡命名為Torii。
在本文中，我們重點說明迄今為止對這一僵尸網絡的了解，分析其傳播過程、各個階段以及一些重要特征。
目前，針對該僵尸網絡的分析仍在進行中，如果有更進一步的調查結果，我們也會及時更新。
接下來，讓我們從感染向量開始。
對初始Shell腳本的分析
在感染鏈的開始階段，首先針對目標設備的弱口令進行Telnet攻擊，然后執行初始Shell腳本。這一腳本與IoT惡意軟件所經常使用的腳本完全不同，因為它更為復雜。
腳本首先嘗試檢測目標設備的體系結構，然后嘗試下載相應的Payload。Torii支持的體系結構非常多，包括基于x86_64、x86、ARM、MIPS、Motorola 68k、SuperH、PPC的設備，支持多種位寬和字節順序。這樣一來，Torii的感染范圍就非常廣泛，能夠在眾多常見的設備上運行。
惡意軟件使用多個命令下載二進制Payload，其執行的命令包括：wget、ftpget、ftp、busybox wget和busybox ftpget。它還同時使用多個命令，使其傳遞Payload的可能性達到最大。
如果無法使用wget或busybox wget命令通過HTTP協議下載二進制文件，那么它將會采用FTP協議。使用FTP協議時，需要經過身份驗證。在腳本中提供了身份驗證信息：
用戶名：u=”<redacted>“
密碼：p=”<redacted>“
FTP端口：po=404
FTP/HTTP服務器IP地址：104.237.218.85（在本文撰寫時，該IP地址仍然存在）
通過連接到FTP服務器，惡意軟件能實現大量工作：
完整文件請點擊：?https://cdn2.hubspot.net/hubfs/486579/torii_directory_structure.txt?t=1538013373318
在服務器中，有來自NGINX和FTP服務器的日志、Payload樣本、將被感染設備定向到惡意軟件所在主機的Bash腳本等。我們將在本文的最后，討論從日志中發現的內容。首先，先讓我們來分析一下在服務器托管的腳本。
第一階段Payload分析（Dropper）
在腳本確定目標設備的架構之后，就會從服務器下載并執行對應的二進制文件。所有這些二進制文件都是ELF格式。在分析這些Payload時，我們發現它們都非常相似，并且僅僅是第二階段Payload的Dropper。值得注意的是，它們使用了多種方法使第二階段能在目標設備上盡可能持久化。我們來深入了解其中的細節。
針對本文，我們分析的是x86的樣本，其SHA256哈希值為：
0ff70de135cee727eca5780621ba05a6ce215ad4c759b3a096dd5ece1ac3d378
由于樣本經過混淆，我們首先需要嘗試對其進行反混淆。因此，我們深入研究了一些文本字符串，以嘗試找到該惡意軟件的工作方式。第一和第二階段中的絕大多數文本字符串都是通過簡單的XOR方式進行加密的，并且在運行時需要特定字符串對它們進行解密。我們使用以下IDA Python腳本進行解密：
sea = ScreenEA()
max_size = 0xFF
for i in range(0x00, max_size):
b = Byte(sea+i)
decoded_byte = (b ^ (0xFEBCEADE >> 8 * (i % 4))) & 0xFF;
PatchByte(sea+i,decoded_byte)
if b == 0x00 or decoded_byte == 0x00:
break
e.g. F1 9A CE 91 BD C5 CF 9B B2 8C 93 9B A6 8F BC 00 → ‘/proc/self/exe’
第一階段的核心功能是安裝另一個ELF文件，也就是第二階段的可執行文件，它包含在第一階段的ELF文件中。
該文件將會安裝在一個偽隨機的位置，這個位置是通過組合預先定義好的列表中的內容來生成的，目錄列表如下：
"/usr/bin" "/usr/lib" $HOME_PATH "/system/xbin" "/dev" $LOCATION_OF_1ST_STAGE "/var/tmp" "/tmp"
文件名列表如下：
“setenvi“ “bridged“ “swapper“ “natd“ “lftpd“ “initenv“ “unix_upstart“ “mntctrd“
通過上面的兩個列表，就能生成目標文件的路徑。
確保第二階段持久化
然后，Dropper需要確保能夠執行第二階段Payload，并會保證其持久化。該惡意軟件的獨特之處在于它實現持久化的方式非常強大，至少采用了6種方法來確保文件能夠保留在設備上，并且持續運行。惡意軟件不是從6種方法中選擇一種，而是全部都會執行：
（1）通過向~.bashrc中注入代碼，實現自動執行；
（2）通過向crontab中添加“@reboot”子句，實現自動執行；
（3）通過systemd自動執行“System Daemon”服務，實現自動執行；
（4）通過/etc/init和PATH實現自動執行，將自身偽裝成“System Daemon”服務；
（5）通過修改SELinux策略管理，實現自動執行；
（6）通過/etc/inittab實現自動執行。
完成后，它會投放自身內部的ELF，也就是第二階段的Payload。
第二階段Payload分析（Bot）
第二階段Payload是一個完整的Bot，能夠從其C&C服務器執行命令。在Payload中還包含起其他功能，例如簡單的反調試技術、數據泄露、多層通信加密等。
此外，第二階段中發現的許多功能都與第一階段Payload相同，這樣看來很可能二者都是由同一作者創建的。
針對所有版本，第一階段Payload中的代碼幾乎是相同的。然而我們在第二階段中發現，不同硬件架構的二進制文件之間存在差異。為了能夠對大多數版本中的核心功能進行分析，我們選取了x86架構版本的Payload，其SHA256哈希值為：
5c74bd2e20ef97e39e3c027f130c62f0cfdd6f6e008250b3c5c35ff9647f2abe
該惡意軟件所使用的反分析方法，不如我們在Windows或移動端惡意軟件中看到的方法那么先進，但惡意軟件作者仍在持續改進這一部分。
（1）在執行后，將會運行60秒的sleep()函數，可能會繞過簡單的沙箱；
（2）通過prctl(PR_SET_NAME)調用，將進程名隨機化為“[[a-z]{12,17}]”（正則表達式），以避免通過進程名稱黑名單檢測到該惡意軟件；
（3）通過從可執行文件中刪除符號，加大分析的難度。
當我們首次從惡意服務器104[.]237.218[.]85下載樣本時，所下載的樣本都包含符號，這樣使得分析過程更為建安。但有趣的是，在幾天之后，我們下載的版本中已經不包含符號。除此之外，這兩個版本之間沒有任何差異。這樣一來，我們能夠判斷，惡意軟件作者還在持續改進惡意軟件，以保護可執行文件難以被分析。
如前文所述，這個組件是一個與C&C服務器通信的Bot。我們使用此前發現用于XOR的密碼，對C&C地址再次執行XOR操作，發現似乎每個版本的Torii都包含3個C&C地址。我們所分析的惡意軟件，會嘗試從以下C&C服務器獲取命令：
top[.]haletteompson[.]com cloud[.]tillywirtz[.]com trade[.]andrewabendroth[.]com
它嘗試與列表中的第一個域名進行通信，如果失敗將會轉到下一個域名。此外，如果出現失敗的情況，它還會嘗試通過Google的DNS 8.8.8.8進行域名解析。
自2018年9月15日以來，這三個域名都解析到同一個IP 66[.]85.157[.]90。此外，在同一個IP上托管的其他一些域名也非常可疑：
cloud[.]tillywirtz[.]com dushe[.]cc editor[.]akotae[.]com press[.]eonhep[.]com web[.]reeglais[.]com psoriasiafreelife[.]win q3x1u[.]psoriasiafreelife[.]win server[.]blurayburnersoftware[.]com top[.]haletteompson[.]com trade[.]andrewabendroth[.]com www[.]bubo[.]cc www[.]dushe[.]cc
在同一個IP地址，托管了這么多看起來很奇怪的域名，這一點非常可疑。另外，在此之前，C&C域名是解析到另一個不同的IP地址（184[.]95.48[.]12）。
通過更深入的挖掘，我們還發現了另一組屬于Torii的ELF樣本，其中包括3個不同的C&C地址：
press[.]eonhep[.]com editor[.]akotae[.]com web[.]reeglais[.]com
它們在此前都解析到相同的IP地址（184[.]95.48[.]12）。并且，press[.]eonhep[.]com自2017年12月8日就開始解析到這一地址。因此，我們認為該惡意軟件至少自2017年12月就開始存在，或者可能存在的時間更長。
第二階段通過TCP協議443端口，與這些C&C服務器以及其他加密層進行通信。有趣的是，它使用443端口來迷惑分析人員，因為443是HTTPS端口，而這一惡意軟件實際上并沒有使用TLS協議進行通信。針對每條消息（包括回復的內容），都會生成一個我們稱之為“消息信封”的結構，每個信封都經過AES-128加密，并且其中包含一個MD5校驗和，以確保其中的內容沒有被修改或損壞。此外，每個信封都包含一條消息流，其中每條消息都通過簡單的XOR方法進行加密，這與混淆字符串的加密方式不同。它看起來沒有那么強大，因為通信中包含了解密的密鑰。
Torii在連接到C&C服務器時，還會發出以下隱私信息：
（1）主機名；
（2）進程ID；
（3）第二階段可執行文件的路徑；
（4）在/sys/class/net/%interface_name%/address中找到的所有MAC地址及其哈希值，這部分內容形成了被感染用戶的獨有ID，允許惡意軟件作者更容易地進行指紋識別和設備標記，這些內容也會同時存儲在本地，其文件名諸如：
GfmVZfJKWnCheFxEVAzvAMiZZGjfFoumtiJtntFkiJTmoSsLtSIvEtufBgkgugUOogJebQojzhYNaqyVKJqRcnWDtJlNPIdeOMKP、VFgKRiHQQcLhUZfvuRUqPKCtcrjmhtKcYQorAWhqAuZuWfQqymGnWiiZAsljnyNlocePAOHaKHvGoNXMZfByomZqEMbtkOEzQkQq、XAgHrWKSKyJktzLCMcEqYqfoeUBtgodeOjLgfvArTLeOkPSyRxqrpvFWRhRYvVcLeNtMKTdgFhwrypsRoIiDeObVxTTuOVfSkzgx等；
（5）uname()調用后獲得的詳細信息，包括sysname、version、release和machine；
（6）特定命令的輸出結果，目的是獲取目標設備相關的更多信息。
特定命令如下：
id 2>/dev/null uname -a 2>/dev/null whoami 2>/dev/null cat /proc/cpuinfo 2>/dev/null cat /proc/meminfo 2>/dev/null cat /proc/version 2>/dev/null cat /proc/partitions 2>/dev/null cat /etc/*release /etc/issue 2>/dev/null
在分析代碼的過程中，我們發現Bot組件正在與C&C進行通信，并且會在無限循環中不斷輪詢，詢問C&C服務器是否有任何命令需要執行。在收到命令后，它會回復命令執行的結果。每個消息信封中都包含一個特定值，用于指定其命令的類型，在回復內容中也會附帶相同的值。目前，我們發現了如下命令類型：
（1）0xBB32：將文件從C&C存儲到本地驅動器
接收：從C&C接收的文件存儲到本地的位置、文件、MD5校驗和
回復：存儲文件的文件路徑、錯誤代碼
（2）0xA16D：接收C&C輪詢的間隔時間
接收：DWORD與C&C通信之間的暫停（Sleep）時間
回復：代碼為66的消息
（3）0xAE35：在Shell解釋器中執行特定命令，并將輸出結果發回C&C
接收：在Shell中要執行的命令（sh -c “exec COMMAND”）、間隔時間（以秒為單位，最大為60）、帶有Shell解釋器路徑的字符串（可選）
回復：包含命令執行內容的輸出結果（stdoout+stderr）
（4）0xA863：將文件從C&C存儲到特定路徑，并將其標志更改為“rwxr-xr-x”使其可執行，然后執行
接收：從C&C接收的文件存儲到本地的位置、文件、MD5校驗和
回復：存儲文件的文件路徑、執行該文件后的返回代碼
（5）0xE04B：檢查本地系統上是否存在特定文件，并返回其大小
接收：要檢查的文件路徑
回復：文件路徑、文件大小
（6）0xF28C：從所選文件F的偏移量O處讀取N個字節，并將其發送到C&C服務器
接收：要讀取文件（F）的文件路徑、QWORD偏移量（O）、DWORD要讀取的字節數（N）
回復：文件內容、偏移量、讀取的字節大小、讀取內容的MD5校驗和
（7）0xDEB7：刪除指定的文件
接收：要刪除的文件名
回復：錯誤代碼
（8）0xC221：從特定URL下載文件
接收：存儲文件的路徑、URL
回復：存儲文件的路徑、URL
（9）0xF76F：獲取新C&C服務器地址，并開始與其進行通信
接收：？、新域名、新端口號、？
回復：？、新域名、新端口號、？
（10）0x5B77/0x73BF/0xEBF0（可能還有其他代碼）：在目標設備上執行Ping或者獲取心跳包
接收：特定內容
回復：重復收到的信息
對二進制文件sm_packed_agent的分析
在我們對服務器進行分析時，還發現了另一個有趣的二進制文件，我們設法從FTP服務器杉獲取了名為“sm_packed_agent”的二進制文件。我們目前沒有在服務器上發現這一二進制文件已經被使用的證據，但通過對其功能進行分析，發現它可以用于向目標設備發送任何遠程命令。該二進制文件中包含一個使用UPX加殼的GO語言應用程序，其中包含一些有趣的字符串，表明它具有類似于副武器的功能：
該二進制文件，使用了以下第三方庫：
https://github.com/shirou/gopsutil/host
https://github.com/shirou/gopsutil/cpu
https://github.com/shirou/gopsutil/mem
https://github.com/shirou/gopsutil/net
其可能的源代碼名稱如下：
/go/src/Monitor_GO/agent/agent.go
/go/src/Monitor_GO/sm_agent.go
其中，可能有一些庫濫用了BSD許可證。顯然，Torii的作者并不關注侵權問題。
sm_agent的功能如下：
（1）在cmdline –p上使用一個帶有端口號的參數；
（2）初始化加密，加載TLS、密鑰和證書；
（3）創建服務器，并監聽TLS連接；
（4）等待以BSON格式編碼的命令；
（5）使用命令處理程序，對命令進行處理：
1: Monitor_GO_agent__Agent_GetSystemInfo 2: Monitor_GO_agent__Agent_GetPerformanceMetrics 7: Monitor_GO_agent__Agent_ExecCmdWithTimeout
TLS加密、證書和密鑰：
（1）Agent使用ChaCha20-Poly1305流密碼進行TLS加密；
（2）同一目錄下的密鑰和證書；
（3）自簽名的授權證書ca.crt，簽名為Mayola Mednick；
（4）由ca.crt為Dorothea Gladding發布的client.crt；
（5）由ca.crt為Graham Tudisco發布的server.crt和server.key。
由于證書是自簽名的，所以使用的名稱也顯然是虛假的。
Start-agent.sh：
該腳本將會首先終止任何先前啟動的sm_packed_agent實例，然后在TCP協議45709端口上運行sm_packed_agent，當出現運行失敗的情況會嘗試重新運行。
目前，還暫時不清楚Torii作者是如何使用的這項服務，但它非常通用，可以在設備上運行幾乎任何命令。因為這應用程序是使用GO語言編寫的，所以可以非常容易地重新編譯，從而在幾乎任何架構上使用。考慮到該文件是在惡意軟件分發的主機上運行，說明它很可能是后門，或者是用于組織多臺機器的服務。
惡意服務器日志分析
最后，我們分析了從Nginx服務器和FTP服務器（104[.]237.218[.]85）上發現的日志。通過這些訪問日志，我們可以推斷出Torii實際感染了多少客戶端，或者有多少客戶端試圖下載該惡意軟件。
在我們撰寫此文章時，Torii的作者已經禁用了FTP和Nginx日志記錄，但是根據已有的日志，我們可以生成一些簡單的統計信息。
根據服務器上面的日志，在9月7日、8日、19日和20日，共有206個IP連接到服務器。
Access-2018-09-07.log – 包含54個不同的IP地址 Access-2018-09-08.log - 包含20個不同的IP地址 Access-2018-09-19.log - 包含189個不同的IP地址 Access-2018-09-20.log - 包含10個不同的IP地址
其中，有一個IP地址38[.]124.61[.]111連接該服務器的次數達到了1056393次。
通過查看日志，似乎有人使用了DirBuster-1.0-RC1，嘗試分析該服務器的內部結構。事實上，DirBuster通常用于猜測Web服務器的目錄和文件名，并且會生成大量請求。其實，這次掃描是完全沒有必要的，因為針對Torii這樣復雜的惡意軟件，有更加有效的方法。
通過掃描38[.]124.61[.]111的端口，我們可以發現有下面幾個端口是開啟的：
在27655端口上，有一個SSH Banner，其內容為：
SSH-2.0-OpenSSH_7.4p1 Raspbian-10+deb9u3
看上去，這個盒子正在運行Raspbian。
除此之外，我們還可以對FTP服務器日志進行分析。
分析發現，有幾個客戶端曾連接，并下載了一些沒有位于FTP服務器上的文件：
Sat Sep 8 08:31:24 2018 1 128.199.109.115 6 /media/veracrypt1/nginx/md/zing.txt b _ o r md ftp 0 * c
根據我們分析的日志內容，總共有592個不同的客戶端，在幾天時間之內從該服務器下載文件。需要提醒大家的是，一旦目標設備收到Payload，就會停止連接到下載服務器，轉為連接到C&C服務器。因此，我們通過該日志，就可以看到這些日志記錄的時間段范圍內，有多少網絡中的新設備感染了這一惡意軟件。
此外，有8個客戶端同時使用了HTTP服務器和FTP服務器，這可能是由于HTTP方式下載失敗，或是Torii作者在測試Bash腳本和服務器的功能。
由于沒有證據，我們無法做出更多的推測。這臺服務器可能只是眾多感染目標連接的服務器之一，要揭示這個僵尸網絡的真實規模，還需要進一步的調查。考慮到所分析的惡意軟件的復雜程度，我們認為它可能是為了控制大量不同類型的設備而設計的。
結論
盡管我們的研究仍在繼續，但目前的結論已經表明，Torii是物聯網惡意軟件發展過程中的一個重要樣本，它的復雜程度已經高于我們此前看到的水平。一旦它感染了某個設備，不僅會泄露設備自身的一些敏感信息，還會通過與C&C的通信允許Torii作者執行任意代碼或傳遞任何Payload。這樣一來，Torii就成為了一個可供今后持續使用的模塊化平臺。此外，由于Payload自身不會掃描其他目標，因此它在網絡上非常隱蔽。
我們還將持續進行研究，并及時披露新發現的成果。