殭屍蜜網:首款具備誘捕及反探測能力的物聯網殭屍網路
一、概述
近期,我們跟蹤到一起特別的物聯網殭屍網路攻擊事件。該攻擊事件近3個月來對中國、美國、俄羅斯、德國等多個國家發動了較為頻繁的攻擊。這批攻擊雖然流量並不大,但在追蹤的過程中發現,這批攻擊中存在一些VT查殺率為0的惡意樣本,如圖1所示;並且還發現該殭屍網路的許多節點新奇地加入了誘捕及反探測能力。
圖1:VT檢測情況
這些殭屍樣本可以將受控裝置的指紋資訊偽裝成其他裝置的指紋(目前僅發現DVR的偽造指紋,推測駭客可以透過更新模組來偽造其他裝置指紋)。一方面以偽造裝置指紋的方式來欺騙如Shodan等各類漏洞掃描產品,以達到反探測的目的;另外一方面這種偽造的裝置指紋也被利用來做誘捕,如偽裝成為一個存在漏洞的裝置,以蜜罐誘捕的方式誘使其他駭客傳送利用程式碼進行攻擊,從而得到漏洞利用細節。因此,我們將此類殭屍所構建的可以對漏洞和攻擊樣本進行誘捕的殭屍網路命名為“殭屍蜜網”。
透過我們自己的物聯網威脅資料平臺及相關情報的交叉印證,發現“殭屍蜜網”包含兩類樣本。第一類是誘捕與反探測節點,對該樣本進行二進位制檔案相似度比對發現其攻擊模組和通訊協議與Moobot家族高度相似,推測與Moobot家族同源,因此將這類新型的惡意程式命名為Moobot_Trap,其借鑑了蜜罐的設計思想,除了偽裝自身為其他裝置外,還能透過誘捕其它攻擊者的漏洞利用情報與攻擊樣本,來靈活快速的升級其武器庫,加強自身的攻擊與防禦能力。第二類是構建代理網路的惡意代理節點,我們將其命名為Mal_Proxy,透過下發惡意代理模組,攻擊者能夠將受感染或購置的裝置作為新節點來代理任意流量,進而不斷髮展壯大其代理網路。惡意流量經代理網路中轉至Tor網路或真實C&C,一方面可以避免直接暴露身份,另一方面也能更好的穿透某些網路防火牆的限制。透過目前掌握的資料結合物聯網殭屍樣本的分析,我們還原出了該殭屍網路的攻擊模型如圖2所示:
圖2:”殭屍蜜網“攻擊模型
進一步溯源後,我們發現這次攻擊背後的組織可能同時掌控著包括Moobot、LeeHozer、Gafgyt變種在內的多個殭屍網路。該組織不僅具有多種0Day和Nday漏洞攻擊的能力,還擅長透過代理網路、Tor網路等代理技術來加強通訊的匿名化,從而提高其C&C伺服器的隱蔽性。本文將對捕獲到的殭屍樣本、惡意代理程式及其攻擊鏈進行剖析,並進一步對背後的駭客組織以及這些殭屍網路間的關聯性展開分析和追蹤。
二、攻擊資源分析
在追蹤過程中,我們發現“殭屍蜜網”與多個殭屍網路間存在較強的關聯性,包括Moobot、LeetHozer以及Gafgyt變種等等。以Moobot和LeetHozer兩類殭屍網路為例,proxy.2u0apcm6ylhdy7s.com域名曾作為Mal_Proxy的Downloader URL以及Moobot的C2;elrooted.com相關子域名曾用於Mal_Proxy的C2以及Moobot、LeetHozer的Downloader URL,類似域名資產重用的現象,表明兩類殭屍很有可能源自同一組織。我們整理了關聯樣本的傳播和執行流程如圖3所示:
圖3:關聯樣本的傳播和執行流程圖
其中,Moobot是樣本數量最多且持續活躍的一類殭屍,我們發現的具備誘捕及反探測能力的Moobot_Trap便是其同源家族。同時,由於Moobot前期傳播的樣本涉及Socks和Tor版本,也可能與此次發現的惡意代理程式有關。LeetHozer殭屍則是透過Socks5協議和Tor C&C建立連線,且與Mal_Proxy的活躍時間相近,推測LeetHozer內建的代理節點列表很大可能就是駭客控制的惡意代理網路。
根據目前的監測情況,該組織單日發起的攻擊次數約在100次左右,被攻擊目標則主要分佈在中國、美國、俄羅斯、德國等國家,其中針對我國的攻擊大多集中在新疆、河南、江蘇、臺灣等地區,攻擊記錄示例如圖4:
圖4:攻擊記錄
圖5:境內受攻擊IP位置分佈圖
此外,該組織還具備很強的漏洞利用能力,已知的武器庫包括今年初披露的LILIN DVR 0Day漏洞、HiSilicon DVR backdoor 0Day漏洞,以及諸多影響範圍廣泛、危害嚴重的Nday漏洞,一些被公開的漏洞POC也往往會被迅速整合並應用於其漏洞掃描模組,考慮到駭客還可以透過偽裝的誘捕節點收集其它攻擊者的情報及樣本情況,我們估計其可用的漏洞資源非常龐大。透過目前監測發現及相關報告中披露的漏洞利用情況,該組織利用的漏洞如表1所示:
表1:漏洞利用列表
在域名資產方面,該組織使用時間較長、頻次較高的域名為elrooted.com、2u0apcm6ylhdy7s.com以及頂級域名.xyz下的部分域名。這三類域名下的子域名長期被解析並用於其樣本的DownloaderURL或C&C。其中,185.172.110.0/23網段關聯著大量殭屍,例如185.172.110.240、185.172.110.224、185.172.110.235等等。
基於目前掌握的情況,我們總結該組織的特點如下:
● 該組織可能掌控著包括Moobot、LeeHozer、Gafgyt_variant在內的多個殭屍網路,攻擊目標遍佈全球,且近期仍在保持高頻率的攻擊活動
● 掌握著代理網路資源,與其它使用代理網路的殭屍存在一定關聯,且可能在地下論壇出售代理訪問許可權
● 擅長0DAY、NDAY漏洞利用
● 擅長使用Socks5代理、Tor網路等C&C隱藏技術
● 樣本掃描模組分佈在多種樣本中協作掃描,掃描效率高
● 樣本具備誘捕及反探測能力,能夠捕獲其它駭客的攻擊情報
● 具備一定的安全對抗能力,樣本迭代更新快、免殺性好,頻繁更換UPX幻數殼、更新敏感資訊加密演算法及通訊協議等
三、攻擊樣本分析
由於該組織擁有著兩類殭屍節點(誘捕與反探測節點、代理節點),我們也將重點對這兩類節點相關的樣本進行分析。第一類樣本為Moobot_Trap,其偽裝成為DVR實現誘捕與反偵測的功能;第二類樣本為實現反追蹤並與Tor網路對接的Socket5代理節點,包括惡意樣本Mal_Proxy和LeeHozer。
3.1Moobot_Trap分析
Moobot_Trap殭屍是一個功能完整的殭屍程式,其功能包括誘捕監測以及反探測、漏洞掃描、DDos攻擊。透過樣本的相似度比對,我們最終確定Moobot_Trap與Moobot家族同源,其攻擊程式碼和通訊協議具有高度的相似性。Moobot殭屍自2019年下半年開始活躍,其長期利用漏洞進行擴散與感染,該殭屍採用一種分散掃描的方式進行攻擊,即不將所有漏洞掃描方式整合在單個樣本內,而是將各種漏洞分佈在多類Bot樣本中,以提高掃描效率降低被發現的機率。Moobot_Trap也延續此種特徵,但其最重要改變是加入誘捕和反探測能力,其在受感染裝置上開啟一個mini_httpd服務,並偽裝成DVR裝置,一方面用於誘捕漏洞和攻擊樣本,一方面可以欺騙各類裝置探測平臺。
具體分析樣本如表2所示:
表2:樣本資訊
3.1.1 誘捕與反探測模組分析
該模組為了實現誘捕功能,將主動開啟WEB服務埠(80、8080、8000)與資料庫HSQL的服務埠(9002),一旦收到外界的http協議的掃描探測,便會返回偽裝的裝置指紋。目前發現的Moobot_Trap將受控裝置偽裝成DVR裝置,不過駭客可以透過更新模組來變更指紋資訊。此外該模組還能夠監控外界對該裝置發動的攻擊並將攻擊資訊上報給駭客預先佈置的C&C伺服器上,以此駭客可以獲取到漏洞掃描特徵和攻擊樣本。
( 1 ) 反探測:目前最為主流的裝置探測技術依然是基於指紋實現的,如Shodan、ZoomEye、Censys以及各類漏洞掃描產品,因而Moobot_Trap還提供一類能力就是給掃描源提供偽造的資訊,以欺騙掃描引擎做出錯誤的決策。一則Moobot_Trap可以將自身偽裝成為一個堅不可摧的裝置,讓掃描引擎認為這是一臺安全的裝置而降低被發現的機率;一則Moobot_Trap也可以將入侵的裝置偽裝成為一個存在新公開漏洞的裝置,其可以起到誘捕一些未公開的漏洞利用程式碼。在我們當前所發現的殭屍網路中,其中被入侵的任何一臺裝置都將被識別成為一個提供mini_httpd服務的DVR裝置(用於誘捕Mini_httpd1.19相關的漏洞利用程式碼)。
圖6:掃描指紋示例
Mini_httpd是一款微型的Http伺服器,在佔用系統資源較小的情況下可以保持一定程度的效能,因此廣泛被各類物聯網裝置(路由器,交換器,攝像頭等)作為嵌入式伺服器使用。而包括華為、海康威視、zyxel、樹莓派等廠商的旗下裝置都曾採用Mini_httpd元件,影響範圍很廣,相關漏洞可能影響全球數百萬裝置。所以駭客此類新穎的技術思路運用也需要引起我們足夠的重視。
( 2 ) 誘捕:我們知道,現實網路中存在大量蠕蟲和殭屍網路,他們永不間斷地掃描探測網路資源,同時他們也在實時更新其探測特徵,如駭客們的0day/Nday漏洞掃描特徵。而大部分可用於蠕蟲和殭屍傳播的物聯網漏洞都集中在HTTP服務的遠端命令執行漏洞(佔比更多的Telnet類攻擊以弱口令為主,此處不表)。該惡意模組正是以獲取此類漏洞攻擊行為為目的,在啟動埠上監視wget、tftp、/bin/sh命令,收集漏洞資訊和傳播樣本。下圖是一個遠端命令執行漏洞的Payload:
圖7:掃描Payload示例
當某些攻擊者、蠕蟲或者殭屍程式針對受感染裝置進行漏洞掃描或程式碼植入時,一旦攻擊Payload中攜帶有指定命令(如圖中的wget)時,該資料即被視為有效情報被轉發至Moobot_Trap駭客的C&C。透過這種類似蜜罐的監測技術,駭客可以捕獲到大量漏洞利用程式碼,甚至是0day漏洞,更進一步,還能夠透過傳播的殭屍樣本來提取和研究更多有價值的漏洞或技術。
從上面的分析我們還可以看出,如果駭客組織具備足夠的技術實力,還能透過捕獲的掃描資訊獲取到其它殭屍網路的Download IP或C&C並進一步實施入侵。通常情況下攻擊者的很多伺服器都來自漏洞入侵、Telnet爆破等等,那麼這些伺服器資產就很有可能被駭客組織二次入侵,原控制者擁有的肉雞資源也可能被共享或接管。下文我們將對Moobot_Trap進行分析與闡述。
Moobot_Trap首先會在80、8080、8000、9002四種埠中隨機選擇其一建立服務端監聽,可以認為駭客的目標就是收集這四類埠的掃描資料。
圖8:選擇埠建立監聽
當攻擊者掃描相應埠且傳送的請求資料包含wget、tftp、/bin/sh命令時,Moobot_Trap會返回偽造的mini_httpd伺服器資訊並將請求資料轉發給C&C,之後關閉與客戶端的連線(模擬HTTP無連線請求)。
圖9:返回mini_httpd伺服器資訊
連線C&C則是加密儲存在記憶體中(敏感資訊加密將在後續章節分析)。
圖10:轉發資料
模擬一次掃描的實際情況,當攻擊者針對誘捕節點進行漏洞掃描時,互動流量資料包如圖11所示:
圖11:互動資料包
Moobot_Trap檢測到wget命令時,會識別為有效情報,並將掃描資訊以如下的形式上報至C&C。
圖12:上報掃描資料
上報資料格式如表3所示:
表3:上報資料格式
3.1.2 敏感資訊加密
加密資料並非整段儲存在程式碼中,而是將字串常量分割成多個部分存放在rodata和text段,這也會給分析工作造成一定的干擾。
圖13:加密字串
具體加解密演算法與Mirai相同,金鑰為0x0deadbeef,所有字串的使用都是用時解密,用完即恢復加密,加解密演算法如圖14所示:
圖14:加解密演算法
3.1.3 埠掃描和資訊上報
Moobot掃描模組採用全網掃描,並將掃描結果上報Reporter,最後由Loader針對漏洞裝置植入樣本,歷史上其存在多種掃描版本:
( 1 ) TCP:23,26 (Telnet)
( 2 ) TCP:34567 (DVRIP)
( 3 ) TCP:4567(TVT)
( 4 ) TCP:5555 (ADB)
( 5 ) TCP:80,81,82,83,85,88,8000,8080,8081,9090,60001 (HTTP)
對於掃描http服務的樣本,如果檢測到如下Http Server則會上報Reporter。樣本解密後用於檢測的伺服器字串示例如下:
"Server: JAWS/1.0."
"Server: DWS."
"URL=/view/viewer_index.shtml?id=."
"Server: thttpd/2.25b PHP/20030920."
"Server: Boa/0.93.15."
這些不同掃描種類的樣本的DownloaderURL通常也是以對應漏洞裝置的名稱來命名和分類,例如:
表4:DownloadURL特點
對於掃描使用的爆破憑證,除了部分內建列表,還可以向C&C傳送請求指令以獲取爆破名稱密碼列表,請求值不同對應不同的爆破組合值。
圖15:返回爆破組合
當掃描發現可用漏洞裝置則會向Reporter上報裝置資訊。
圖16:上報裝置資訊
表5:上報裝置資訊解析
3.1.4 通訊協議及攻擊模組
Moobot_Trap在通訊協議方面與之前的版本有所變化,成功建立連線後,首先會向控制端傳送上線包。
圖17:上線資料包
表6:上線資料包解析
之後間隔60秒迴圈向控制端傳送心跳包[0x00 0x00](固定值),控制端則間隔20秒向殭屍程式回包[0x33 0x66 0x99](固定值)。
圖18:心跳資料包
當控制端傳送的指令前三位元組非[0x33 0x66 0x99]時,則進入攻擊模式解析指令。
圖19:解析攻擊
攻擊模組方面,Moobot_Trap延用了Mirai的攻擊形式,樣本包括7種攻擊模式。
圖20:攻擊模式
攻擊指令資料包如圖21所示:
對應結構體示意如下:
type Attack struct {
Duration uint32
Type uint8
Targets counts uint8
Targets map[uint32]uint8
Flags counts uint8
Flags map[uint8]string
}
表7:攻擊指令解析
3.2Mal_Proxy分析
Mal_Proxy是駭客組織用於構建代理網路的核心模組,其可以提供代理服務以及資訊上報功能。該模組輕便靈活,攻擊者可以透過引數配置代理服務,程式啟動後受控裝置即作為代理節點加入到代理網路中,為駭客的惡意活動提供隱匿保護。
Mal_Proxy存在兩個版本,V1版本C2為cest4.elrooted.com,V2版本C2則包括hxarasxg.hxarasxg.xyz和da.elrooted.com。其中V2版本增加了引數啟動、Socks5協議認證模式及UPX殼,並修改了殼的幻數(實際幻數0xBC7A3331)以對抗指令碼脫殼。Mal_Proxy樣本均被剝離符號且未留下任何與代理相關的字串、特徵等資訊,說明該組織具備一定的安全對抗經驗,有意給分析人員製造更多的困難,也使得Mal_Proxy保持了非常好的免殺性。
後文以V2版本為例進行具體分析,並會穿插一些V1版本的對比,樣本資訊如表8所示:
表8:樣本資訊
3.2.1 引數啟動模式
Mal_Proxy V1版本並不具備引數啟動模式,其代理埠號是透過時間戳計算出的隨機值得到(埠範圍:0至65535)。
圖22:V1版本獲取隨機埠
Mal_Proxy V2版本則新增了引數啟動模式,從而可以更加靈活的配置代理埠以及Socks5協議的使用者名稱/密碼認證模式。引數啟動共包含三種命令引數,命令形式為:
Mal_Proxy -pport -u user -P password
其中-p為指定的代理繫結埠,-u、-P為配置使用者名稱/密碼認證模式,如不配置預設為無需認證方式。
V2版本無參啟動會預設繫結本地28105埠,並以無需認證的方式執行程式。
圖23:引數啟動
程式執行後會在不同階段Fork多執行緒,並透過不同執行緒執行相應的功能模組,包括資訊上報模組和代理服務模組。
3.2.2 資訊上報模組
V2版本的資訊上報模組同樣區分有參和無參兩種模式,具體上報資訊同引數內容有關。而V1版本僅有一種上報方式,即V2版本的無參模式。
圖24:V1版本資訊上報
圖25:V2版本兩類資訊上報方式
無參上報資料包:
圖26:V2版本無參上報資料包
有參上報資料包:
圖27:V2版本有參上報資料包
表9:V2版本上報資料包解析
程式每間隔300秒迴圈向hxarasxg.hxarasxg.xyz:38129傳送心跳包上報引數資訊。同時程式模擬了域名查詢請求,透過公共服務DNS(8.8.8.8)來自行解析IP,從而防止hosts或resolv.conf被篡改或劫持造成的DNS查詢異常。
圖28:V2版本資訊上報
3.2.3 代理服務模組
代理模組執行緒首先會繫結監聽本地指定埠(代理埠),並透過listen、accept等操作函式來建立監聽並接收客戶端請求。
圖29:繫結監聽代理埠
之後代理模組會進一步針對客戶端的請求進行判斷和校驗,例如針對0x05 0x01 0x00 0x03內容的校驗,實則為Socks5協議認證階段的握手過程,進一步分析後可以確認該模組是基於Socks5協議的惡意代理程式服務端。
圖30:Socks5協議校驗
3.2.4 Socks5協議介紹
Socks5是一種網路傳輸協議,主要用於客戶端與外網伺服器之間通訊的中間傳遞。此協議並不負責代理伺服器的資料傳輸環節,而是在 C/S 兩端真實互動之間,建立起一條從客戶端到代理伺服器的授信連線。客戶端首先需要和服務端進行握手認證,可以採用使用者名稱/密碼認證或者無需認證方式,握手成功後即可進入資料傳輸階段,協議原理如圖31所示:
圖31:Socks5協議原理
以某次透過Socks5代理傳輸的攻擊指令為例,在已經藉助代理協議建立連線的情況下,C&C下發的攻擊指令經代理網路(54.188.198.118:9090)中轉後傳輸到Bot,此時捕獲的流量是無法獲取到真實C&C地址的,在一定程度上可以達到隱藏C&C的目的。
圖32:代理傳輸攻擊指令流量
從另一個角度考慮,Socks5協議雖然在傳輸階段具有隱藏C&C的效果,但其作為透明代理並不具備加密功能,認證和連線階段也並不安全。如果能夠嗅探協商握手階段的資料流量,依然能夠解析並獲取到樣本連線的真實C&C。基於這些原因,一些駭客還會進一步利用Tor 網路來加強隱匿性,由於Tor網路每一條通訊鏈路都由若干隨機選取的Tor節點組成,且通訊資料進行了多層加密,即使獲取到Tor C&C也難以溯源到隱藏的真實伺服器,所以在隱匿性方面Tor網路是更好的選擇。當然Tor網路也有其弊端,由於連線的複雜性,Tor網路的傳輸速率和成功率往往難以保證。綜合而言,考慮到現實情況中監聽受控伺服器代理客戶端到代理伺服器的全部流量是非常困難的,所以無論是普通代理網路,還是進一步使用Tor網路都能夠在一定程度上為殭屍網路提供充足的隱匿保護。
3.3LeeHozer分析
LeeHozer是一類藉助Socks5協議與Tor C&C通訊的新型殭屍家族,其設計了相對嚴謹而複雜的通訊協議。由於樣本下載地址(http://exec.elrooted.com/uc/i686)與Mal_ProxyC&C(cest4.elrooted.com)使用了相同的二級域名,且同期兩類樣本均更新迭代了引數啟動的新版本,我們認為二者有著較強的關聯性。下文以V3版本為例進行分析,並對其引數啟動、掃描模組、控制指令等功能的更新升級情況進行說明。
表10:樣本資訊
LeetHozer的攻擊目標主要是針對IOT裝置,一旦裝置重啟,其記憶體中的Bot程式也會隨之消失。所以LeetHozer會透過向watchdog(看門狗)傳送0x80045704來禁用watchdog功能,從而防止裝置重啟。
圖33:禁用watchdog
同時程式會在console中輸出/bin/sh: ./filename: not found迷惑使用者,之後執行埠掃描上報,協議校驗上線和攻擊模組等功能。
圖34:console輸出
3.3.1 敏感資訊加密
LeetHozer採用了自定義的演算法加密資源資訊,加密金鑰為qE6MGAbI。相關演算法如圖35所示:
圖35:加密演算法
解密後的資源資訊如表11所示:
表11:解密資源資訊
3.3.2 埠掃描和資訊上報
LeeHozer複用了Mirai的掃描形式,如掃描並登陸成功後則上報裝置資訊,且不同版本具有不同的掃描模式。
表12:掃描模式
V2版本掃描9530埠:
圖36:9530埠掃描
V3版本則有所不同,相較於之前的版本,V3版本增加了引數啟動配置。如果無參執行樣本,預設不會執行掃描功能;而如果啟動程式時新增telnet引數則會進行掃描操作(如“./samples telnet”)
圖37:23/26埠掃描
圖38:上報Reporter
3.3.3 通訊協議及攻擊模組
LeeHozer建立通訊的過程較為複雜,首先其會透過Socks5協議連線代理網路,從而進一步與Tor C&C建立連線:
圖39:Socks5協議互動
如果當前Socks代理連線失效,程式會隨機從內建的107個代理中選擇其一併重新建立代理連線,內建代理列表如下:
表13:代理列表
這批代理資源很有可能就是透過Mal_Proxy建立,當然,其中也可能包括一些共享資源和免費節點。
當LeeHozer成功和C&C建立連線後,還需經過兩輪校驗互動才能真正實現上線。
第一輪校驗:
Client->Server:
校驗請求包長度為255位元組,但只有前32位元組為有效內容。
圖40:第一輪校驗請求包
表14:第一輪校驗請求包解析
計算校驗值的演算法如圖41所示:
圖41:計算校驗值
Server->Client:
控制端回包同樣為255位元組,前32位元組有效。
圖42:第一輪控制端回包
客戶端會針對回包的兩個標誌位進行校驗,分別為0x70f1和0x4819,校驗透過後繼續進行第二輪互動。
圖43:標誌位校驗
第二輪校驗:
Client->Server:
客戶端校驗請求包仍為255位元組,前32位元組有效,部分資料來源自第一輪服務端的回包。
圖44:第二輪校驗請求包
表15:第二輪校驗請求包解析
Server->Client:
第二輪迴包與第一輪迴包相似,總長255位元組,前32位元組有效。
圖45:第二輪控制端回包
客戶端對0x70F2和0x2775兩個標誌位校驗成功後,殭屍的上線過程才算完成,之後殭屍等待控制端下發指令,其中指令的首位元組指定了控制指令型別。
控制指令共包括三類:
表16:控制指令型別
0x00 心跳包:
圖46:心跳包
0x01 傳送標識資訊:
圖47:傳送標識資訊
如首位元組為其它值,則會解析具體的指令功能,LeetHozer不同版本的功能指令如表18所示:
表17:功能指令表
圖48:V3版本攻擊指令判斷
我們觀察到,近期LeeHozer仍在持續展開攻擊活動,攻擊指令如圖48所示:
圖49:攻擊指令資料包
表18:攻擊指令資料解析
溯源與關聯
值得注意的是,LeeHozer在程式碼中多處使用了與vbrxmr相關的字串,例如‘GET /vbrxmr/i586 HTTP/1.0’、‘/bin/busybox VBRXMR’,以及C2(vbrxmrhrjnnouvjf.onion)等。與之相關的,Hoaxcalls(XTC)殭屍網路曾使用cbc.vbrxmr.pw作為C2,程式碼中也出現過vbrxmr字串,且同樣可以藉助代理網路通訊(具備Fastflux功能),Vbrxmr的頻繁出現也不得不讓人懷疑兩者之間存在一定的關聯。
圖50:Hoaxcalls字串
此外,透過搜尋LeeHozer的加密金鑰qE6MGAbI,還發現了另一種使用代理通訊的樣本,且其使用的代理列表也和LeeHozer有部分重合。
圖51:某代理樣本字串
類似的關聯表明這些使用代理的殭屍網路控制者間或多或少存在著一些聯絡,駭客們很可能在地下論壇交易代理資源、共享程式碼或是透過程式碼模仿來迷惑研究人員。
四、總結
隨著物聯網時代的快速發展,安全對抗也在不斷升級和進化。可以看到,越來越多的攻擊者嘗試從更多的維度開展攻擊活動和安全對抗。一方面,越來越多的攻擊者開始藉助代理網路來加強隱匿安全,代理資源作為隱匿C&C的前置網路無疑是一個巨大的威脅和隱患;另一方面,也出現了利用惡意樣本實現誘捕監測和反探測能力的應用新思路,這些都會給物聯網裝置的安全防護和研究工作帶來更多的變化,後續我們也會進行持續的關注和追蹤。
IOC資訊
Moobot:
URL :
http://exec.elrooted.com/ab/i686
http://conn.elrooted.com/li/arm
http://91.92.66.87:80/420/adb/x86
http://185.163.46.6/a/x86_64
http://5.252.179.60/b/x86_64
http://185.172.110.224/ab/i586
C2:
proxy.2u0apcm6ylhdy7s.com
abcdefg.elrooted.com
park.elrooted.com
frsaxhta.elrooted.com
cccc.elrooted.com
205.185.114.231
185.172.110.224
Reporter IP:
gfedcba.elrooted.com
hello.elrooted.com
HASH:
1a64cd13d9c71542ce60183356a615505f10ddc192eded5fce0f0075f3ad7648
ca3889994301f28baa791f4ef1aa473b0bc6e975cda703195787872795171869
e9a7aab3ab25c0a091d98d3ae4a313fba3b3bd0588bfe8e3624ec016bc11f02e
2516bdc3ae3818e30e1145f75811937e29ce10f94722c6da1ea7c28f4c0bc3dc
a6e18135a2afcd96957bff63388501465f5a1203b2d22ee0f1074661e286d9e3
59b1ca2d47af1d5b60b84c3a9d6a64a09b7340864b9e90247466d7f91ed53b84
d5d5488ae9c80558cc4634ce6d51837d82347fd48d1a665e606dcfbfdf638b7b
Mal_Proxy:
URL :
http://proxy.2u0apcm6ylhdy7s.com/b/x86_64
http://proxy.2u0apcm6ylhdy7s.com/b/armv7l
C2:
hxarasxg.hxarasxg.xyz
cest4.elrooted.com
da.elrooted.com
185.172.110.240
HASH:
a67f79c7ae6b1177309cb328d3ec93ec91960edf457a4f5a74120baaf80139ee V2
04114bd136941811e355df28e9b2eeaa941a04b61b185fd214a4c54daa171e1c V2
80f1973b82cbea485f27eb8c44983c565701fdc4e6d3e994ed57bf57a66b9c81 V2
f91427e74a84c34d329116443fa1c89c63dab57e01129345a9f9ed364533dd49 V1
4ed3c601022b4d8c1478521241b847dcacecd837bc75547f3a378ee9d5b9e15f V1
b41de82ea89e2ceedda5b4a856c273c4ce06429d876ee4a05ee9a2423741461f V1
LeeHozer:
C2:
vbrxmrhrjnnouvjf.onion:31337
37.49.226.171:31337
w6gr2jqz3eag4ksi.onion:31337
Reporter IP:
report.infidel.ml:9814
HASH:
84efc5ce8a0729b1248b5f7a43ddf371f517ac0a0eea0a5b0674ce195be61b8e v3
ca8095af62b836f3ddd12007bc8cb67cdd39266c3d40179691f9ee1ca94e9428 v2
1c5349696c04dfa8e0f458ad1d9aa360f4768b21d3dd83fb98d935691b1b2a88 v1
參考文獻:
1.https://blog.radware.com/security/botnets/2020/05/whos-viktor-tracking-down-the-xtc-polaris-botnets/
2.https://blog.netlab.360.com/the-leethozer-botnet-en/
3.https://www.exploit-db.com/exploits/48225
4.https://blog.netlab.360.com/multiple-botnets-are-spreading-using-lilin-dvr-0-day/
5.https://habr.com/en/post/486856/
啟明星辰積極防禦實驗室(ADLab)
ADLab成立於1999年,是中國安全行業最早成立的攻防技術研究實驗室之一,微軟MAPP計劃核心成員,“黑雀攻擊”概念首推者。截止目前,ADLab已透過CVE累計釋出安全漏洞1000餘個,透過 CNVD/CNNVD累計釋出安全漏洞800餘個,持續保持國際網路安全領域一流水準。實驗室研究方向涵蓋作業系統與應用系統安全研究、移動智慧終端安全研究、物聯網智慧裝置安全研究、Web安全研究、工控系統安全研究、雲安全研究。研究成果應用於產品核心技術研究、國家重點科技專案攻關、專業安全服務等。
相關文章
- 超大規模的物聯網殭屍網路:Pink2021-10-21
- 物聯網裝置殭屍網路趨勢分析2018-12-14
- 什麼是殭屍網路2019-01-04
- Mirai殭屍網路重出江湖2018-12-10AI
- 怎樣有效的治理殭屍網路?2019-09-18
- 揭秘Neutrino殭屍網路生成器2020-08-19
- RDP服務之GoldBrute殭屍網路2019-06-19Go
- 殭屍網路XorDDoS的原理分析與清除2019-10-24
- 瞄準Windows的新興殭屍網路:Kraken2022-02-27Windows
- 注意!首個物聯網殭屍網路新變種肆虐,大批Android裝置使用者受害2018-10-10Android
- Gafgyt變種——Jaws殭屍網路的分析報告2022-03-28
- Mirai 殭屍網路出現了新的變種2019-03-20AI
- 濫用ThinkPHP漏洞的殭屍網路Hakai和Yowai2019-02-20PHPAI
- 盤點:網際網路上無處不在的"殭屍"2018-04-27
- 物聯網教程Linux系統程式設計——特殊程式之殭屍程式2019-08-28Linux程式設計
- 斷劍重鑄?Kaiji殭屍網路正在重構2022-07-09AI
- DorkBot殭屍網路近期活躍情況報告2019-10-28
- 某殭屍網路被控端惡意樣本分析2020-08-19
- 狼煙再起 | 物聯網殭屍家族入侵模式再更新,阻擊需提前2021-01-28模式
- 殭屍網路瞄準SonicWall SSL VPN,揭開隱匿在物聯網裝置背後的真面目2021-03-19
- Mirai 殭屍網路作者與 FBI 合作而避免刑期2018-09-21AI
- 帶你瞭解殭屍網路是怎樣組成的?2019-06-25
- 如何有效的治理殭屍網路以此來避免遭遇DDOS?2019-07-04
- 殭屍網路 Emotet 能通過相鄰 Wi-Fi 網路傳播2020-02-14
- 挖礦殭屍網路蠕蟲病毒kdevtmpfsi處理過程2023-02-21dev
- fork和殭屍程式2019-06-29
- 什麼是殭屍網路攻擊?安全專業人員指南2022-02-21
- Sysrv-hello殭屍網路又有什麼新“招式”?深信服雲蜜罐捕獲最新變種2021-08-01
- 瞭解殭屍網路的控制型別可以做最好的防護措施!2019-06-26型別
- Linux中殭屍程式是什麼意思?怎麼檢視殭屍程式?2022-10-18Linux
- 第一個能在裝置重啟後繼續存活的殭屍網路2018-05-18
- 黑客輕鬆接管29個殭屍網路 只因運營商太菜2019-05-05黑客
- Muhstik殭屍網路木馬來襲,挖礦、攻擊兩不誤2020-11-24
- Chalubo殭屍網路來襲 IOT裝置或將受到DDoS攻擊2018-10-24
- Linux殭屍程式處置2020-10-22Linux
- 檢視 Linux 殭屍程式2019-04-17Linux
- 殭屍程式,孤兒程式2018-08-10
- 快速進擊的挖礦殭屍網路:單日攻擊破10萬次2018-05-25