{
	"id": "ce37daef-9ba8-4d47-85e9-43765ced6ca8",
	"created_at": "2026-04-10T03:20:15.834761Z",
	"updated_at": "2026-04-10T13:12:08.916274Z",
	"deleted_at": null,
	"sha1_hash": "50583f63e3c12ac6ab19ce90bd9913d50bba051d",
	"title": "Long Live The Vo1d Botnet: New Variant Hits 1.6 Million TV Globally",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 5174913,
	"plain_text": "Long Live The Vo1d Botnet: New Variant Hits 1.6 Million TV\r\nGlobally\r\nBy Alex.Turing\r\nPublished: 2025-02-27 · Archived: 2026-04-10 02:50:34 UTC\r\nPrologue\r\nOn February 24, 2025, NBC News reported: \"Unauthorized AI-generated footage suddenly played on televisions\r\nat the U.S. Department of Housing and Urban Development (HUD) headquarters in Washington, D.C. The video\r\nshowed President Donald Trump bowing to kiss Elon Musk's toes, accompanied by the bold caption LONG LIVE\r\nTHE REAL KING . Staff were unable to shut it down and had to unplug all TVs.\" The incident quickly sparked\r\nwidespread public debate and caught the attention of the cybersecurity community, prompting a reevaluation of\r\nthe significant risks posed by hacked devices like televisions and set-top boxes.\r\nImagine sitting on your couch watching TV when suddenly the screen flickers, the remote stops\r\nworking, and the program is replaced by garbled code and eerie commands. Your TV, as if hijacked by\r\nan invisible force, becomes a \"digital puppet.\" This isn’t science fiction—it’s a real and growing threat.\r\nThe Vo1d botnet is silently taking control of millions of Android TV devices worldwide. ----By XLab\r\nBackground\r\nOn November 28, 2024, XLab's Cyber Threat Insight and Analysis System(CTIA) detected IP 38.46.218.36\r\ndistributing an ELF file named jddx with a VirusTotal 0 detection. Our AI detection module flagged it as\r\ncontaining \"Bigpanzi botnet DNA\", piquing our interest. A quick analysis confirmed that jddx is a downloader\r\nemploying the Bigpanzi string encryption algorithm , though its code structure differs significantly from\r\nknown Bigpanzi samples. Could the million-device botnet Bigpanzi, which we exposed last year, be quietly\r\nbranching into new operations? With this question in mind, we dove deeper. Our findings revealed that jddx\r\nactually belongs to a new variant of another million-device botnet Vo1d. It’s a a previously undiscovered\r\ndownloader delivering a fresh Vo1d payload. This marked the beginning of Vo1d's new campaign.\r\nScale and Impact\r\nAccording to our sinkhole statistic, Vo1d has infected 1.6 million Android TV devices across 200+ countries and\r\nregions. To put this into perspective:\r\n2024 Cloudflare Attack: A 5.6 Tbps DDoS attack, capable of crashing any website, used just 15,000\r\ndevices. Vo1d controls over 1.6 million—100 times larger.\r\n2016 Mirai Botnet: It crippled the U.S. East Coast internet, taking down Twitter and Netflix, with only\r\nhundreds of thousands of devices. Vo1d dwarfs this scale.\r\nhttps://blog.xlab.qianxin.com/long-live-the-vo1d_botnet/\r\nPage 1 of 50\n\nCurrently, Vo1d is used for profit, but its full control over devices allows attackers to pivot to large-scale\r\ncyberattacks or other criminal activities. For instance, Cloudflare's 2024 Q4 report noted Android TVs and set-top\r\nboxes participating in DDoS attacks. If Vo1d were weaponized, its 1.6 million devices could disrupt critical\r\nsystems like banking, healthcare, and aviation, causing widespread chaos.\r\nBeyond traditional attacks, compromised TVs and set-top boxes pose unique risks as core media devices. Hackers\r\ncould exploit them to broadcast unauthorized content, as seen in real-world cases:\r\nDecember 11, 2023: UAE set-top boxes were hacked to display videos of the Israel-Palestine conflict.\r\nFebruary 24, 2025: TVs at the U.S. Department of Housing and Urban Development showed AI-generated\r\nfootage of Trump kissing Musk's toes.\r\nImagine Vo1d-controlled Android TV spreading violent, terrorist, or pornographic content, or using deepfake\r\ntechnology for political propaganda. The societal impact would be devastating.\r\nSignificant Findings\r\nOur investigation into jddx led to significant findings:\r\nSamples \u0026 Infrastructure: 89 new samples captured, a lot of infrastructure, including 2 Reporter, 4\r\nDownloaders, 21 C2 domains, 258 DGA seeds, and over 100,000 DGA domains.\r\nDaily active IPs: ~800,000, peaking at 1,590,299 on January 14, 2025.\r\nVo1d has evolved to enhance its stealth, resilience, and anti-detection capabilities:\r\n1. Enhanced Encryption: RSA encryption secures network communication, preventing C2 takeover even if\r\nDGA domains are registered by researchers.\r\n2. Infrastructure Upgrade: Hardcoded and DGA-based Redirector C2s improve flexibility and resilience.\r\n3. Payload Delivery Optimization: Each payload uses a unique Downloader, with XXTEA encryption and\r\nRSA-protected keys, making analysis harder.\r\nIn 2025, XLab's tracking system revealed Vo1d's operations:\r\nProxy Networks: A core focus, leveraging infected devices to build anonymous proxy services.\r\nAd Fraud and Fake Traffic: Activities like ad promotion and click fraud.\r\nFrom the payload’s functionality, it’s clear that a proxy network is one of Vo1d’s core objectives. The commercial\r\nvalue of this goal has been well-proven by the success of the 911S5 proxy service. According to the U.S.\r\nDepartment of Justice, the operators of 911S5 raked in over $99 million in illicit profits by selling proxy services.\r\nAs global law enforcement ramps up its crackdown on cybercrime, the demand for anonymization services among\r\ncriminal groups continues to surge. Vo1d’s proxy network, built by controlling a massive number of devices\r\nworldwide, offers greater appeal than traditional proxies, better meeting the needs for anonymity and stealth.\r\nVo1d's massive scale and continuous evolution pose a severe, long-term threat to global cybersecurity. Its ability\r\nto operate undetected for over three months highlights its stealth. By sharing our findings, we aim to contribute to\r\nthe fight against cybercrime and raise awareness of this formidable threat.\r\nhttps://blog.xlab.qianxin.com/long-live-the-vo1d_botnet/\r\nPage 2 of 50\n\nTranco 1M C2 Infra\r\n1. C2 Infrastructure\r\nThrough the jddx sample captured on November 28, we identified the C2 domain ssl8rrs2.com and a network\r\nbehavior pattern involving 21,120 DGA-generated C2 domains based on 32 DGA seeds. The IP 3.146.93.253,\r\nbound to these C2 domains, serves as a core infrastructure for Vo1d's current campaign. This IP resolves to five\r\ndifferent domains, including ssl8rrs2.com, which have been further verified as C2 domains in subsequent\r\nsamples.\r\nTo enhance reliability and evade detection, these domains utilize different ports for load balancing. For example:\r\nssl8rrs2.com uses port 55600.\r\nviewboot uses port 55503.\r\nThis multi-port strategy significantly improves the network's resilience and makes it harder to detect and disrupt.\r\nThrough traceability analysis, we identified another critical asset: 3.132.75.97. This IP is associated with the\r\nfollowing seven domains。Among these, ttss442 and works883 have been confirmed as C2 domains in recently\r\ncaptured samples. For the remaining five domains, based on their naming patterns, creation timelines, and other\r\ncontextual clues, we have high confidence in attributing them to the Vo1d group's infrastructure.\r\nhttps://blog.xlab.qianxin.com/long-live-the-vo1d_botnet/\r\nPage 3 of 50\n\n2. Tranco 1M Ranking\r\nThe Tranco Ranking is a comprehensive system designed to measure website popularity, providing accurate and\r\nreliable global website ranking data. It integrates multiple data sources, including Cisco Umbrella, Majestic,\r\nFarsight, Cloudflare Radar, and the Chrome User Experience Report (CrUX), making it a widely used tool in\r\nacademia.\r\nIn the Tranco rankings, a significant portion of Vo1d botnet's C2 domains have entered the global top 500,000,\r\nwith some even ranking within the top 50,000.\r\nA notable example is ttss442, which was registered on November 3, 2024. Within just a few months, it surged into\r\nthe global top 55,000. This rapid rise highlights the massive scale and striking activity level of the Vo1d botnet.\r\nhttps://blog.xlab.qianxin.com/long-live-the-vo1d_botnet/\r\nPage 4 of 50\n\nMillion-Scale Network\r\n1. Legacy Scale\r\nDr.Web previously disclosed 5 DGA seeds related to Vo1d. After reverse-engineering the DGA algorithm, we\r\nregistered 5 domains to measure the legacy scale of Vo1d's older version. Based on the data, the daily active bots\r\n(DAB) for the legacy version are approximately 5,000.\r\nhttps://blog.xlab.qianxin.com/long-live-the-vo1d_botnet/\r\nPage 5 of 50\n\n2. Current Scale\r\nThe DGA algorithm used in this Vo1d variant is identical to the one disclosed by Dr.Web in earlier samples.\r\nHowever, the number of supported DGA seeds has significantly increased—from 5 hardcoded seeds in the initial\r\nversion to 32 in the current variant. This expansion has dramatically increased the scale of generated domains.\r\nAs our traceability efforts progressed, we registered 258 DGA C2 domains, providing a partial view into the Vo1d\r\nbotnet's operations. Based on the collected data:\r\nApproximately 1.6 million devices have been infected, spanning 226 countries and regions.\r\nStarting from January 14, 2025, the daily active bots (DAB) remained close to 1.5 million for seven\r\nconsecutive days, peaking at 1,590,299 on January 19.\r\nThe current daily active bot count is approximately 800,000.\r\nhttps://blog.xlab.qianxin.com/long-live-the-vo1d_botnet/\r\nPage 6 of 50\n\nBased on data collected from February 1 to 15, the top 15 countries by infection rate are as follows:\r\nCountry Percentage\r\nBrazil 24.97%\r\nSouth Africa 13.60%\r\nIndonesia 10.54%\r\nArgentina 5.27%\r\nThailand 3.40%\r\nChina 3.13%\r\nMorocco 2.79%\r\nPhilippines 2.22%\r\nGermany 2.17%\r\nMalaysia 2.14%\r\nPakistan 2.12%\r\nIraq 1.29%\r\nMexico 1.29%\r\nRussia 1.14%\r\nEcuador 1.04%\r\nhttps://blog.xlab.qianxin.com/long-live-the-vo1d_botnet/\r\nPage 7 of 50\n\nNotably, China has a significant infection, with a daily active bot count exceeding 20,000.\r\nBeginning on February 21, 2025, the Vo1d botnet experienced a notable surge in infections, with daily active bots\r\nincreasing from 800,000 to over 1.1 million. Below is the list of the top 15 countries by infection rate as of\r\nFebruary 25.\r\nIt is particularly noteworthy that India has surged from the 29th position to 2nd place in terms of infection rates.\r\nMeanwhile, China's infection count has also risen significantly, approaching 50,000 active bots.\r\n3. Surge and Drop\r\nEach C2 in the Vo1d botnet uses a distinct port, allowing us to gauge the activity level of a specific C2 by\r\nmonitoring the number of Bot IPs communicating through that port. Over a two-month observation period, we\r\nfound that most ports maintained relatively stable communication levels, forming the baseline of Vo1d's infection\r\nscale. However, port 55560 exhibited unusual behavior, with frequent and dramatic surges and drops in\r\ncommunication volume.\r\nhttps://blog.xlab.qianxin.com/long-live-the-vo1d_botnet/\r\nPage 8 of 50\n\nThe dramatic fluctuations in Vo1d's activity are closely tied to rapid increases and decreases in infection rates\r\nwithin specific countries, with India being a prime example. Its infection count often experiences tenfold changes\r\novernight. Below are key instances of these fluctuations:\r\nJanuary 14, 2025:Vo1d's scale increased from 810,000 to 1.52 million.India's infection count surged from\r\n18,400 to 147,619.\r\nJanuary 22, 2025: Vo1d's scale dropped sharply from 1.43 million to 780,000. India's infection count fell\r\nfrom 94,430 to 5,042.\r\nFebruary 20 - February 23, 2025: Vo1d's scale grew from 820,000 to 1.16 million. India's infection count\r\nskyrocketed from 3,901 to 217,771.\r\nhttps://blog.xlab.qianxin.com/long-live-the-vo1d_botnet/\r\nPage 9 of 50\n\nWe speculate that the phenomenon of \"rapid surges followed by sharp declines\" may be attributed to Vo1d leasing\r\nits botnet infrastructure in specific regions to other groups. Here's how this \"rental-return\" cycle could work:\r\nLeasing Phase:\r\nAt the start of a lease, bots are diverted from the main Vo1d network to serve the lessee's operations. This\r\ndiversion causes a sudden drop in Vo1d's infection count as the bots are temporarily removed from its active pool.\r\nReturn Phase:\r\nOnce the lease period ends, the bots rejoin the Vo1d network. This reintegration leads to a rapid spike in infection\r\ncounts as the bots become active again under Vo1d's control.\r\nThis cyclical mechanism of \"leasing and returning\" could explain the observed fluctuations in Vo1d's scale at\r\nspecific time points.\r\n4. XLab Codomain System\r\nThe discovery of 258 DGA domains was crucial for measuring the scale of Vo1d's operations. While 256 domains\r\nwere identified through traditional reverse engineering methods—analyzing malicious samples, extracting DGA\r\nseeds, and generating domains based on the algorithm—the remaining 2 unique DGA domains were captured\r\nusing XLab's newly developed Codomain system. These two domains provided critical visibility into infections\r\nwithin China.\r\nThe Codomain system is an innovative tool based on DNS co-occurrence technology, which monitors and\r\nanalyzes the relationships between domains frequently queried by the same set of hosts within a similar\r\ntimeframe. In simple terms, if a group of domains is often queried together by the same hosts, they are likely\r\nrelated. For example, Vo1d's bots access hardcoded C2s, DGA-generated C2s, and Reporter domains during\r\noperation. By meeting specific timing conditions, these domains can be linked in the Codomain system, helping\r\nresearchers trace the attacker's infrastructure.\r\nThe Codomain system played a pivotal role in our analysis and traceability efforts, particularly in the following\r\nthree areas:\r\n1. Discovering New Assets Without Samples\r\nOn December 5, 2024, after completing the analysis of the jddx sample, we questioned whether our work was\r\ndone. By analyzing the co-occurring domains of the jddx C2, we uncovered new Downloaders and hidden C2s,\r\nindicating that additional samples were still active outside our scope.\r\nhttps://blog.xlab.qianxin.com/long-live-the-vo1d_botnet/\r\nPage 10 of 50\n\nThrough the co-occurring domains of the C2 ssl8rrs2, we discovered the domain wowokeys, which\r\nresolved to the same IP (38.46.218.36) as jddx's Downloader ssl87362, confirming wowokeys as another\r\nDownloader.\r\nFurther investigation of wowokeys' co-occurring domains led us to works883.com, whose naming pattern\r\nmirrored the Reporter works883.xyz, raising suspicions. (The name works883 itself is intriguing, possibly\r\nmocking the intense \"996\" work culture.)\r\nFinally, by examining the co-occurring domains of works883.com, we identified a batch of unknown\r\ndomains matching Vo1d's DGA pattern. This confirmed works883.com as a previously undiscovered C2,\r\nand on January 6, 2025, we successfully captured samples related to this C2.\r\n2. Confirming C2 Identities Without Samples\r\nAs mentioned in the C2 infrastructure section, we found 7 suspicious domains on the IP 3.132.75.97 (resolved by\r\nworks883.com). While only 2 were linked to known samples, the remaining 5 were attributed to Vo1d based on\r\ntheir naming patterns and creation times. Codomain helped confirm some of these as C2s. For example, the co-occurring domains of snakeers.com clearly matched Vo1d's DGA pattern, providing solid evidence of its C2\r\nidentity.\r\nhttps://blog.xlab.qianxin.com/long-live-the-vo1d_botnet/\r\nPage 11 of 50\n\n3. Discovering New DGA Domains Without Samples\r\nOn December 8, 2024, while monitoring 135 million Bot IPs through a DGA C2 sinkhole, we noticed an\r\nunusually low infection count in China—only a few dozen cases—despite the country's vast number of Android\r\nTV devices. To address this gap, we used Codomain to uncover unknown DGA domains.\r\nOn December 15, while analyzing the co-occurring domains of works883.com, we discovered DGA domains\r\ngenerated by an unknown seed: {mask}2940637fafa. Vo1d's DGA algorithm supports three TLDs: net, com, and\r\ntop, which are treated equally. When registering Vo1d DGA C2s, we typically chose .top due to lower costs.\r\nHowever, registering the .top version of z{mask}2940637fafa yielded no infections.\r\nBy January 6, 2025, we had identified 256 DGA seeds in samples, but {mask}2940637fafa was not among them.\r\nInitially, we thought this seed might belong to an expired sample, but on January 18, we realized our mistake:\r\nz{mask}2940637fafa.com had consistently high DNS query volumes in China, yet we had registered the top\r\nversion.\r\nhttps://blog.xlab.qianxin.com/long-live-the-vo1d_botnet/\r\nPage 12 of 50\n\nAfter quickly registering the .com version, the results were immediate: China's infection count surged overnight,\r\nwith daily active bots jumping from a few dozen to around 20,000. Globally, this domain contributed 150,000\r\ndaily active infection IPs.\r\nThe significant traffic generated by domains from the {mask}2940637fafa seed indicates the presence of highly\r\nactive, unknown Vo1d samples in the wild. Although we did not capture these samples, Codomain enabled us\r\nto gain visibility and fill the gap in China's infection data.\r\nTechnical Analysis\r\nhttps://blog.xlab.qianxin.com/long-live-the-vo1d_botnet/\r\nPage 13 of 50\n\nAmong the 89 samples we captured, s63 stands out as an ideal candidate for technical analysis. It downloads a\r\nsubsequent payload, ts01, which is a compressed package containing multiple components that communicate with\r\nthe core C2 IP 3.146.93.253. Below, we will analyze s63 in detail, covering its network communication, payload\r\ndecryption, and the dissection of ts01's components to explore the new techniques introduced in Vo1d's latest\r\ncampaign.\r\nPart 1: Downloader s63\r\ns63 is a dynamically linked ELF file, making reverse engineering relatively straightforward.\r\nMD5: 9e116f9ad2ff072f02aa2ebd671582a5\r\nMagic: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, BuildID[sha1]=70672a8ccee1\r\nIn summary, it first decrypts sensitive configuration information, such as the download server address, payload\r\nname, and XXTEA key. Then, it sends command 0x10 to the download server to request redundant download\r\nserver addresses. Next, it sends command 0x11 to the redundant server to request the payload. Finally, it decrypts\r\nand executes the payload.\r\n1.1 Decrypting Configuration\r\nThe Downloader stores its configuration in the .data section, which is decrypted using the decstring function\r\nwhen needed.\r\nAfter a detailed analysis of the decstring function, it was discovered that the ciphertext consists of two parts: a\r\nheader and a body. The header is 3 bytes long, and the XOR value of these bytes determines the length of the\r\nbody. The first and second bytes of the header are used to XOR-decrypt the body. Below is an equivalent Python\r\nimplementation of the decryption function. If you’re a long-time reader of our blog, this decryption logic might\r\nhttps://blog.xlab.qianxin.com/long-live-the-vo1d_botnet/\r\nPage 14 of 50\n\nfeel familiar—and it should! In fact, it’s identical to the Bigpanzi string decryption function we disclosed in\r\nJanuary 2024.\r\nHere’s the equivalent Python implementation:\r\ndef decbuf(buf):\r\n leng = buf[0] ^ buf[1] ^ buf[2]\r\n out = ''\r\n for i in range(3, leng + 3):\r\n tmp = ((buf[i] ^ buf[1]) - buf[1]) \u0026 0xff\r\n out += chr((tmp ^ buf[0]))\r\n return out\r\nBelow is the decrypted configuration information, where the two most crucial elements are the XXTEA key and\r\nthe download server address. The sample parses the string 38.46.218.36:ts01:9999 using the format specifier %\r\n[^:]:%[^:]:%d , extracting the download server address 38.46.218.36:9999 and the payload filename ts01.\r\n1.2 Network Communication\r\nThe Downloader deployed this time supports two command, 0x10 and 0x11, which correspond to the functions of\r\nrequesting redundant download servers and requesting the payload, respectively. The network packet format is\r\nlength:cmd:body , where the length field is 4 bytes long and represents the combined length of the cmd and body\r\nfields; the cmd field is 1 byte, and the body field’s length is length - 1. The actual network traffic generated is\r\nshown below, and it’s evident that the server’s responses to the 0x10 and 0x11 command requests are both\r\nencrypted.\r\nhttps://blog.xlab.qianxin.com/long-live-the-vo1d_botnet/\r\nPage 15 of 50\n\n1.3 Decrypting Traffic\r\nLet’s examine the response packet for the 0x10 command. Based on the length:cmd:body format, the body’s\r\nciphertext is 2d 5e 64 ca 3d bc c3 34 39 9f f3 27 d8 2d e8 d3 81 d0 6f 7d b7 f3 c7 49 . The decryption\r\nalgorithm is XXTEA, using the key b6d5c945d61a73641e710f357214f3e3 from the configuration. Notably,\r\nXXTEA keys are fixed at 16 bytes, so the actual valid key is the first 16 bytes: b6d5c945d61a7364. DrWeb’s\r\nanalysis article contains errors regarding the XXTEA key .\r\nUsing CyberChef to decrypt the body ciphertext reveals the redundant download server address as\r\n38.46.218.39:9999. After obtaining this address, s63 sends the 0x11 command to it, requesting the encrypted\r\npayload.\r\nNext, let’s examine the response packet for the 0x11 command requesting ts01. Based on the packet format\r\nmentioned earlier, the body’s length is 0x000636b1 bytes. It consists of two parts: the first 256 bytes are RSA-encrypted ciphertext, which can be decrypted to reveal the XXTEA key, while the remaining portion is the actual\r\npayload encrypted with XXTEA.\r\nhttps://blog.xlab.qianxin.com/long-live-the-vo1d_botnet/\r\nPage 16 of 50\n\nThe sample contains a hardcoded RSA public key in the N (modulus) - e (public exponent) format. The N\r\nvalue is 256 bytes (little-endian), as shown in the figure below, while the e value is a fixed constant of 65537.\r\nWith the above knowledge, you can easily decrypt the RSA ciphertext using Python’s pow function. The result is\r\nshown in the figure below. The last 32 bytes of the decrypted plaintext form the XXTEA key, though only the first\r\n16 bytes, 041db10bf25d4722 , are actually used.\r\nhttps://blog.xlab.qianxin.com/long-live-the-vo1d_botnet/\r\nPage 17 of 50\n\nEager security researchers, like us, might reach this point and be itching to try decrypting the payload using the\r\nXXTEA key mentioned above. However, the result is disappointing—it fails to yield the correct payload. When\r\ntroubleshooting, we first verified the decryption algorithm: yep, even if Jesus himself showed up, it’s definitely\r\nXXTEA.\r\nThe algorithm is correct, the key is correct—so why does it fail? At that moment, we were just as puzzled as you.\r\n1.4 ASR XXTEA\r\nAlthough the decrypted payload could be obtained through simulation or dynamic dumping, we, as security\r\nresearchers, weren’t satisfied with a black-box approach. Driven by a relentless curiosity—and fueled by a few\r\ncups of coffee—we conducted a meticulous comparison and discovered that Vo1d’s XXTEA algorithm for\r\ndecrypting the payload is actually a modified version. It replaces the standard XXTEA’s logical right shift\r\n(LSR) with an arithmetic right shift (ASR) . We dubbed this modified algorithm asr_xxtea and found it\r\npresent across various Vo1d components. Modifying standard algorithms is uncommon in malware development,\r\nand this finding indirectly highlights the Vo1d group’s deep technical expertise.\r\nhttps://blog.xlab.qianxin.com/long-live-the-vo1d_botnet/\r\nPage 18 of 50\n\nTo decrypt correctly, replace the LSR in the standard XXTEA algorithm with an ASR( You can find the python\r\nverison in the Appendix).\r\nPart2: Payload ts01\r\nThe decrypted ts01 is a compressed package containing four files: cv, install.sh, vo1d, and x.apk. While some\r\nfunctionalities overlap with those disclosed by Dr. Web, we will provide a concise analysis of their roles.\r\nhttps://blog.xlab.qianxin.com/long-live-the-vo1d_botnet/\r\nPage 19 of 50\n\n2.1 install.sh\r\nThis script has a straightforward purpose: launching the cv component.\r\n2.2 cv Component\r\nThe cv component performs four main functions:\r\n1. Cleaning up old Vo1d components.\r\n2. Launching the Vo1d component.\r\n3. Installing and launching x.apk .\r\n4. Reporting device status.\r\nBefore diving into the analysis of specific functions, let’s first examine the decryption of sensitive strings in a CV\r\nsample. In this sample, a large number of sensitive strings are encrypted and stored in the data segment, with the\r\ndecryption function decstring having 39 cross-references.\r\nhttps://blog.xlab.qianxin.com/long-live-the-vo1d_botnet/\r\nPage 20 of 50\n\nGenerally speaking, when dealing with a situation involving a significant number of encrypted items like this, a\r\npractical approach to facilitate reverse engineering is to patch the ciphertext with the decrypted plaintext. Below is\r\nan IDApython script we’ve prepared to achieve this goal.\r\nimport flare_emu\r\naddr_list = []\r\ndef decbuf(buf):\r\n leng = buf[0] ^ buf[1] ^ buf[2]\r\n out = ''\r\n for i in range(3, leng + 3):\r\n tmp = ((buf[i] ^ buf[1]) - buf[1]) \u0026 0xff\r\n out += chr((tmp ^ buf[0]))\r\n return out\r\ndef iterateHook(eh, address, argv, userData):\r\n addr = argv[0]\r\n header = ida_bytes.get_bytes(addr, 3)\r\n leng = header[0] ^ header[1] ^ header[2]\r\n if leng \u003c= 255:\r\n buf = ida_bytes.get_bytes(addr, leng + 3)\r\n out = decbuf(buf)\r\n if addr not in addr_list:\r\n addr_list.append(addr)\r\n print(f'0x{argv[0]:x} ---\u003e {out}')\r\n ida_bytes.patch_bytes(addr, b'\\x00' * (leng + 3))\r\n ida_bytes.patch_bytes(addr, out.encode())\r\n idc.create_strlit(addr, addr + leng)\r\neh = flare_emu.EmuHelper()\r\neh.iterate(eh.analysisHelper.getNameAddr(\"decstring\"), iterateHook)\r\nhttps://blog.xlab.qianxin.com/long-live-the-vo1d_botnet/\r\nPage 21 of 50\n\nThe script decrypts and patches the .data section, revealing plaintext strings for easier analysis.\r\n2.2.1 Cleaning Up Old Vo1d Components\r\nThe cv component removes traces of previous Vo1d installations by:\r\nhttps://blog.xlab.qianxin.com/long-live-the-vo1d_botnet/\r\nPage 22 of 50\n\nKilling processes:\r\n/data/google/daemon\r\n/data/google/rild\r\n/system/xbin/wd\r\n/data/system/installd\r\nDeleting files and directories:\r\nrm -rf /data/google\r\nrm -rf /data/data/com.goog1e.apps\r\nUninstalling apps:\r\npm uninstall com.google.android.services\r\n2.2.2 Launching the Vo1d Component\r\nThe cv component checks if the current Vo1d component’s MD5 matches\r\na4df8a0484e04fe660563b69c93c7f14 . If not, it requests a new payload ( d2 ) from ssl87362.com:9999 and\r\nexecutes it.\r\nDownload Process:\r\nUses commands 0x10 and 0x11 to request and download d2 .\r\nUnlike previous responses, the 0x11 response for d2 is not encrypted, delivering the payload in plain\r\nELF format.\r\nhttps://blog.xlab.qianxin.com/long-live-the-vo1d_botnet/\r\nPage 23 of 50\n\n2.2.3 Installing and Launching x.apk\r\nThe cv component installs and launches x.apk by executing the following:\r\n2.2.4 Reporting Device Status\r\nThe cv component constructs a JSON-formatted device status report and sends it to catmore88.com .\r\n2.3 vo1d Component\r\nThe vo1d sample embeds a payload encrypted with the asr_xxtea algorithm. Its primary function is to decrypt\r\nthis payload and then load and execute its exported init function in memory. The payload itself is stored in the\r\ndata segment, with a hardcoded key of fPNH830ES23QOPIM*\u0026S955(2WR@L*\u0026GF . However, the actual effective key\r\nconsists of the first 16 bytes: fPNH830ES23QOPIM . The decryption code follows a distinct pattern and pre-constructs a structure related to the payload.\r\nhttps://blog.xlab.qianxin.com/long-live-the-vo1d_botnet/\r\nPage 24 of 50\n\nHere, we’d like to introduce readers to a method for emulated decryption using flare_emu , which was heavily\r\nutilized—and proven quite practical—before we fully cracked the asr_xxtea algorithm. By simply locating the\r\nfunction address of asr_xxtea , the payload address, and the payload length, the payload can be decrypted.\r\nimport time\r\nimport idautils\r\nimport idc\r\nimport ida_bytes\r\nimport flare_emu\r\ndef extract_payload(xxtea_call: int, input_addr: int, length: int, key: bytes = b'fPNH830ES23QOPIM') -\u003e None:\r\n start_time = time.time()\r\n eh = flare_emu.EmuHelper()\r\n eh.apiHooks.update({\r\n '__aeabi_memclr': eh.apiHooks['memset'],\r\n '__aeabi_memcpy': eh.apiHooks['memcpy']\r\n })\r\n out_buf = eh.allocEmuMem(length)\r\n in_buf = ida_bytes.get_bytes(input_addr, length)\r\n eh.emulateRange(\r\n startAddr=xxtea_call,\r\n registers={'R0': in_buf, 'R1': out_buf, 'R2': length, 'R3': key},\r\n skipCalls=False\r\n )\r\n decrypted_data = eh.getEmuBytes(out_buf, length)\r\n output_filename = f\"{idc.get_root_filename()}.decrypt\"\r\n with open(output_filename, \"wb\") as output_file:\r\n output_file.write(decrypted_data)\r\n print(eh.getEmuState())\r\n print(f\"Time taken: {time.time() - start_time:.2f} seconds\")\r\nxxtea_addr = 0x94FC\r\ninput_addr = 0x0001B124\r\nhttps://blog.xlab.qianxin.com/long-live-the-vo1d_botnet/\r\nPage 25 of 50\n\nlength = 0xA004\r\nextract_payload(xxtea_addr, input_addr, length)\r\nCompared to directly using asr_xxtea , emulating decryption with a script is significantly slower, taking\r\napproximately 30 seconds to complete. Nonetheless, both approaches achieve the same result—successfully\r\ndecrypting the embedded payload in the sample. The decrypted payload turns out to be a backdoor, with its basic\r\ndetails outlined below:\r\nMD5: 68ec86a761233798142a6f483995f7e9\r\nMagic: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked\r\nThis backdoor is actually an upgraded version of Android.Vo1d5, as previously disclosed by Dr.Web. Its core\r\nfunctionality remains unchanged: establishing communication with a C2 server and downloading and executing a\r\nnative library. However, it has undergone significant updates to its network communication mechanisms, notably\r\nintroducing a Redirector C2. The Redirector C2 serves to provide the bot with the real C2 server address,\r\nleveraging a hardcoded Redirector C2 and a large pool of domains generated by a DGA to construct an expansive\r\nnetwork architecture.\r\nAdditionally, the integration of RSA encryption further enhances the security and stealth of the communication,\r\nmaking the network both difficult to hijack and resistant to disruption. The following analysis will focus primarily\r\non the network communication aspect. For readers interested in the functionality details, please refer to Dr.Web’s\r\nblog, as we won’t elaborate on that here.\r\nSimilarly, the sensitive strings within the payload are also encrypted. Below is a partial list of decrypted sensitive\r\nstrings related to network communication, including the hardcoded Redirector C2, DGA seed, and TLDs used by\r\nthe DGA.\r\n2.3.1 Redirector C2 Network Communication\r\nThe process for the Bot to obtain the real C2 address is straightforward: it first connects to the Redirector C2 at\r\npxleo5fbca7141b5.com and sends a fixed 4-byte check-in message, DD CC BB AA . It then receives a 256-byte\r\nencrypted response from the C2, which is decrypted using RSA. If the decrypted message starts with Okay , it\r\ncontains one or more real C2 addresses, which the Bot extracts using the newline character \\n as a delimiter.\r\nhttps://blog.xlab.qianxin.com/long-live-the-vo1d_botnet/\r\nPage 26 of 50\n\nTake captured traffic as an example: the decrypted response from the Redirector C2 reveals the real C2 as\r\n52.14.24.94:81 .\r\nNext, the Bot reports device status to the real C2 server and awaits commands, with all communication encrypted\r\nvia RSA. The sample hardcodes an RSA public key in N - e format, where N is shown below (little-endian), and e\r\nis 65537. Given the nature of asymmetric encryption, as long as the private key remains uncompromised, only the\r\nC2 server can decrypt the Bot’s requests or issue valid commands.\r\nhttps://blog.xlab.qianxin.com/long-live-the-vo1d_botnet/\r\nPage 27 of 50\n\nThe network packet format for Bot-to-real-C2 communication is length (4 bytes) + RSA ciphertext . Due to\r\nRSA’s properties, we can only decrypt C2 responses. (Note: The traffic below is from liblogs , not vo1d , and\r\nis used here only to demonstrate RSA decryption of C2 traffic.)\r\nThe process of requesting the real C2 via DGA-generated domains is identical. While DGA helps evade detection,\r\nit’s a double-edged sword—security researchers can seize control by preemptively registering domains. However,\r\nthe vo1d botnet relies on RSA to prevent third-party hijacking; even if DGA domains are registered, no \"valid\"\r\ncommands or payloads can be issued without the private key.\r\nhttps://blog.xlab.qianxin.com/long-live-the-vo1d_botnet/\r\nPage 28 of 50\n\n2.3.2 DGA (Domain Generation Algorithm)\r\nIn this update, the Vo1d botnet increased the number of DGA seeds from 4 in the previous version to 32, while\r\nthe algorithm itself remained unchanged. Notably, although the sample hardcodes four TLDs— xyz , top ,\r\ncom , and net — xyz is not actually used. The seeds and the number of domains generated per seed vary across\r\nsamples. We identified 8 groups totaling 256 DGA seeds, with each seed producing either 220 or 500 domains,\r\nresulting in 21,120 or 48,000 domains per group.\r\nhttps://blog.xlab.qianxin.com/long-live-the-vo1d_botnet/\r\nPage 29 of 50\n\nThe Vo1d botnet’s DGA algorithm uses only the first 5 bytes of a seed for computation, leading to a highly\r\nrecognizable pattern in the generated domains. For example, with the seed edd3b49c6ed34236 , DNS requests in\r\nPcap data reveal a clear pattern where \"only the first 5 bytes of the domain name change.\" After analyzing the\r\nDGA algorithm, we implemented a Python version that generates domains perfectly matching the real DNS\r\nrequests observed in the Pcap.\r\n2.4 x.apk Component\r\nThe package name of x.apk is com.google.android.gms.stable , clearly an attempt to masquerade as Google\r\nPlay Services to deceive users. It achieves persistence by listening for the BOOT_COMPLETED event, ensuring it\r\nruns automatically after a device reboot. Additionally, by setting excludeFromRecents=\"true\" and\r\ntheme=\"@style/onePixelActivity\" , it hides its activity traces, further enhancing its stealth.\r\nhttps://blog.xlab.qianxin.com/long-live-the-vo1d_botnet/\r\nPage 30 of 50\n\nThe primary purpose of x.apk is to load the liblogs.so file, copy the test file from the asset directory to\r\n/data/system/startup , and then execute it.\r\n1. test \u0026 liblogs\r\nThe test and liblogs files share the same functionality as the previously analyzed vo1d component:\r\ndecrypting a payload and calling its exported init function. In fact, vo1d and test originate from the same\r\nsource, with liblogs differing only in the network protocol used to communicate with the real C2.\r\nAnalysis of the payloads reveals that test and liblogs share highly similar core logic,\r\ndiffering only in their hardcoded Redirector C2 addresses, ports, DGA seeds, and network protocols for\r\nreal C2 communication:\r\nhttps://blog.xlab.qianxin.com/long-live-the-vo1d_botnet/\r\nPage 31 of 50\n\n1. The C2 used by the test payload is ttekf42.com:55500.\r\n2. The C2 used by the liblogs payload is tumune3.com:55501.\r\nFurther analysis shows that the core IP 3.146.93.253 distributes traffic across multiple ports (55500, 55501,\r\n55502, 55503, 55600), each tied to one of five distinct domains. This multi-port, multi-domain approach prevents\r\noverloading a single service process.\r\nSimilarly, another core IP, 3.132.75.97, follows the same traffic distribution pattern.\r\nPart 3: Operational Analysis\r\nReverse engineering efforts by Dr.Web and XLab on the Vo1d botnet have primarily answered what it can do.\r\nHowever, the question of what such a large-scale botnet is actually doing remains largely unanswered. To address\r\nthis, we implemented the Vo1d network protocol within the XLab Command Tracing System. As the saying\r\ngoes, \"Where there's a will, there's a way\"—our efforts quickly bore fruit.\r\nOn January 2, 2025, we successfully captured and decrypted a command, as shown below. The \"u\" field indicates\r\na payload to download and execute. The decrypted p6332 is a downloader from the earlier s63 , while p8232\r\nintroduces a new component in the Vo1d family: a DexLoader , tasked with decrypting and executing an\r\nembedded DEX-format payload.\r\nhttps://blog.xlab.qianxin.com/long-live-the-vo1d_botnet/\r\nPage 32 of 50\n\n3.1 DexLoader\r\nThe DEX payload within DexLoader is encrypted using the asr_xxtea algorithm with the key\r\nd99202323077ee9e . The decrypted DEX is a \"skeleton\"—retaining method definitions, prototypes, and attributes,\r\nbut stripped of method bytecode.\r\nhttps://blog.xlab.qianxin.com/long-live-the-vo1d_botnet/\r\nPage 33 of 50\n\nAfter restoration via the restore_dex and restore_dex_header functions, the payload is fully reconstructed.\r\nDexLoader then loads and executes the DEX using methods tailored to the device's SDK version.\r\nhttps://blog.xlab.qianxin.com/long-live-the-vo1d_botnet/\r\nPage 34 of 50\n\nBelow is a subset of captured DexLoader instances, their corresponding DEX payloads, and launch parameters.\r\nOur analysis focuses on p8232 and p8932 . The DEX files released by these DexLoaders , along with\r\nsubsequent downloaded samples, frequently use \"MzEntry\" and \"MzSDK\" strings for debugging. We’ve adopted\r\nthe \"Mz\" naming convention and internally dubbed this family Mzmess.\r\nDexLoader Name DEX Package Name Parameter\r\np7332 com.rmk.app.AllPlayer SJ008\r\np8232 com.nasa.cook.CookInit wx717\r\np8932 com.nasa.cook.CookInit mx1220\r\nIn essence, Mzmess is a modular Android malware family comprising three components— entry , sdk , and\r\nplugin —with distinct roles:\r\nentry : Downloads the SDK.\r\nsdk : Manages its own updates and downloads plugins.\r\nplugin : Executes business logic, such as proxy services or ad fraud.\r\n3.2 Mzmess Entry\r\nThe entry component is a downloader focused on retrieving the SDK. To obscure its purpose, sensitive strings\r\nare encrypted using a XOR method.\r\nhttps://blog.xlab.qianxin.com/long-live-the-vo1d_botnet/\r\nPage 35 of 50\n\nDecrypted strings include critical URLs ( f136a to f143h ), categorized into sdkbin (SDK downloads) and\r\nreportcompbin (device reporting), and f134E , an AES key:\r\nf136a http://dcsdk.100ulife.com/sdkbin\r\nf137b https://dcsdk.100ulife.com/sdkbin\r\nf138c http://dcsdk.100ulife.com/reportcompbin\r\nf139d https://dcsdk.100ulife.com/reportcompbin\r\nf140e http://dcsdkos.dc16888888.com/sdkbin\r\nf141f https://dcsdkos.dc16888888.com/sdkbin\r\nf142g http://dcsdkos.dc16888888.com/reportcompbin\r\nf143h https://dcsdkos.dc16888888.com/reportcompbin\r\nf144i data\r\nf145j versionNo\r\nf146k url\r\nf147l md5\r\nf148m channel\r\nf149n terminalVersion\r\nf150o deviceId\r\nf151p packageName\r\nf152q mac\r\nf153r androidId\r\nf154s init\r\nf155t showAdvert\r\nf156u kill\r\nf157v dalvik.system.DexClassLoader\r\nf158w loadClass\r\nf159x com.sun.galaxy.lib.OceanInit\r\nhttps://blog.xlab.qianxin.com/long-live-the-vo1d_botnet/\r\nPage 36 of 50\n\nf160y letu\r\nf161z .jar\r\nf130A /com/ocean/zoe/letu.jet\r\nf131B java.lang.ClassLoader\r\nf132C getClassLoader\r\nf133D AES\r\nf134E DE252F9AC7624D723212E7E70972134D\r\nf135F KEY_SHELL_BURY\r\nThis sample uses the HTTPS dc16888888 domain (though 100ulife is interchangeable):\r\nC2: https://dcsdkos.dc16888888.com/sdkbin\r\nReporter: https://dcsdkos.dc16888888.com/reportcompbin\r\nThe sample requests the next-stage SDK via POST to the C2 URL, adding custom headers ( version , channel )\r\nand encrypting the body with AES-256 ECB using the key DE252F9AC7624D723212E7E70972134D . The reporter\r\nprocess is similar, with the body additionally compressed using Gzip.\r\nHeader:\r\n{\r\n \"Accept\": \"*/*\",\r\n \"Connection\": \"Keep-Alive\",\r\n \"Content-Type\": \"application/json\",\r\n \"charset\": \"utf-8\",\r\n \"channel\": \"wx717\",\r\n \"version\": \"1013\"\r\n}\r\nBody:\r\n{\r\n \"channel\": \"wx717\",\r\n \"terminalVersion\": 17,\r\n \"deviceId\": \"aabbccddaabbccddaabbccddaabbccdd\",\r\n \"packageName\": \"com.nasa.cook\",\r\n \"mac\": \"00:16:3e:4a:bc:d3\",\r\n \"androidId\": \"aabbccdd\",\r\n \"hasWebView\": true\r\n}\r\nThe C2 response, decrypted with the same AES key, provides a URL for downloading the next-stage Mzmess\r\nSDK.\r\nhttps://blog.xlab.qianxin.com/long-live-the-vo1d_botnet/\r\nPage 37 of 50\n\n3.3 Mzmess SDK\r\nThe SDK handles self-updates and manages plugin downloads. It mirrors the entry ’s download approach, using\r\nthe same AES encryption and key, but adds pluginbin for plugin-related requests alongside sdkbin and\r\nreportcompbin .\r\nPlugins are requested via POST with the following JSON body:\r\n{\r\n \"cdist\": \"\",\r\n \"channel\": \"wx717\",\r\n \"deviceId\": \"aabbccddaabbccddaabbccddaabbccdd\",\r\n \"localPluginInfos\": []\r\n}\r\nhttps://blog.xlab.qianxin.com/long-live-the-vo1d_botnet/\r\nPage 38 of 50\n\nThe C2 response, decrypted with AES, specifies plugin download URLs:\r\nThe SDK then downloads and executes the corresponding business plugins based on these URLs.\r\n3.4 Mzmess Plugins\r\nWe captured four distinct plugins, named popa , jaguar , lxhwdg , and spirit based on their package names.\r\nTheir functionality suggests the Vo1d botnet supports illicit activities like proxy networks, ad promotion, and\r\ntraffic inflation.\r\n3.4.1 Popa Plugin\r\nThe popa plugin facilitates proxy services. It hardcodes nine C2s but fetches encrypted data from a Google\r\nDrive URL ( https://drive.usercontent.google.com/download?id=1K95AXo75gi-jJSE9vuVPVEyBya0JUm0w ),\r\ndecrypted with AES-ECB using the key eeorahrabcap286! . The decrypted C2s align with the hardcoded ones.\r\nhttps://blog.xlab.qianxin.com/long-live-the-vo1d_botnet/\r\nPage 39 of 50\n\nIt selects a C2, constructs https://lb.\u003cC2\u003e:5002/devicereg , and registers the device via GET. The response’s\r\nservers or peer_servers field provides a new ProxyC2 .\r\nFinally, it establishes a TCP+SSL connection with the ProxyC2 for proxy tasks, supporting these message types:\r\nMessageType Description\r\n1 Register\r\n2 Register Reply\r\nhttps://blog.xlab.qianxin.com/long-live-the-vo1d_botnet/\r\nPage 40 of 50\n\nMessageType Description\r\n3 Ping\r\n4 Pong\r\n5 Open Tunnel\r\n6 Tunnel Status\r\n7 Tunnel Message\r\n8 Close Tunnel\r\n3.4.2 Jaguar Plugin\r\nThe jaguar plugin’s core logic resides in the native libjaguar.so , with Java code only invoking its\r\nstartAgent function. Like popa , it serves proxy purposes, registering via:\r\nGET http://jaguar-distributor.syslogcollector.com:12000/v1/agent/ctrl\r\nResponse: {\"host\":\"128.1.71.243\",\"port\":21001}\r\nMultiple ProxyC2s were observed, all using port 21001. It registers with TCP, encoding data in a custom bjson\r\nformat (binary JSON, no open-source equivalent):\r\ncmd_type Description\r\n1 Start Action\r\n2 Register Confirm\r\n3 Unknown\r\n4 Ping Message\r\n5 Pong Message\r\nhttps://blog.xlab.qianxin.com/long-live-the-vo1d_botnet/\r\nPage 41 of 50\n\nFor cmd_type=1 , proxy actions include:\r\naction_type Description\r\n2 New Proxy Client\r\n3 UDP Connect Request\r\n4 Send Message Response\r\n5 Send Response \u0026 Exit\r\n6 Speed Test\r\n3.4.3 Lxhwdg Plugin\r\nThe lxhwdg plugin enables remote function calls via WSS on port 2345 of the C2, parsing responses into a\r\nCallRequest class for execution. Unfortunately, the C2 is currently offline, leaving its true intent unclear.\r\n3.4.4 Spirit Plugin\r\nhttps://blog.xlab.qianxin.com/long-live-the-vo1d_botnet/\r\nPage 42 of 50\n\nThe spirit plugin executes JavaScript for ad promotion and traffic inflation. It fetches tasks dynamically:\r\n1. Check Connection:\r\nGET http://task.moyu88.xyz/cpc/api/proxy/origin\r\nResponse: {\"code\":200,\"data\":\"00bz7xh\"}\r\n2. Fetch Tasks (RSA-encrypted):\r\nPOST http://task.moyu88.xyz/cpc/api/task\r\nResponse: {\"code\":200,\"data\":{\"orderId\":-1774990216,\"tasks\":[{\"productId\":0,\"taskId\":2097500401,\"version\":0}]}}\r\n3. Task Details:\r\nGET http://task.moyu88.xyz/cpc/api/xml?productId=0\r\nResponse: {\"code\":200,\"data\":[{\"productId\":0,\"script\":\"{\\\"tagName\\\":\\\"return\\\",\\\"key\\\":\\\"no_route\\\"}\",\"version\":\r\nBrute-forcing productId (e.g., 43) reveals detailed tasks:\r\nhttps://blog.xlab.qianxin.com/long-live-the-vo1d_botnet/\r\nPage 43 of 50\n\nThis concludes the operational analysis of the Vo1d botnet and Mzmess. Their relationship remains unclear—no\r\ndirect ties have been found at the sample or infrastructure level. We speculate that the group behind Vo1d may be\r\n\"leasing\" the network to cybercrime operators. This is merely a hypothesis, and we welcome insights from those\r\nwith insider knowledge.\r\nLeave no stone unturned\r\nWhile tracing earlier versions of the Vo1d botnet, we uncovered two C2 domains—synntre.com and\r\nremoredo.com—previously unmarked by the security community. We believe their resolved IP, 3.17.255.32,\r\nserved as a core C2 IP in the botnet’s early iterations.\r\nAmong related domains, bitemores and meiboot were already flagged by Dr.Web as C2s. But what about the\r\nothers? Take csskkjw.com, for instance. VirusTotal provided a lead: csskkjw.com/s3/b7027626. The downloaded\r\nb7027626 file was encrypted. We first tried decrypting it with the RSA public key mentioned earlier—no luck.\r\nDisappointing, to say the least.\r\nThen, one day, it hit us: a sample tied to synntre.com contained another RSA public key (big-endian). We gave it\r\na shot, and success—it decrypted into a DexLoader , confirming csskkjw.com as a Vo1d asset. A small victory\r\nworth savoring!\r\nhttps://blog.xlab.qianxin.com/long-live-the-vo1d_botnet/\r\nPage 44 of 50\n\nNext, we analyzed the resolution history of the remaining domains, uncovering two additional IPs:\r\n13.229.152.241 and 18.139.54.2. These three IPs share significant domain overlap. Domains in the red box are\r\nconfirmed Vo1d C2s; for the rest, based on registration timelines and naming patterns, we’re highly confident they\r\nbelong to the Vo1d group as well.\r\nhttps://blog.xlab.qianxin.com/long-live-the-vo1d_botnet/\r\nPage 45 of 50\n\nConclusion\r\nThis article has delved into the Vo1d botnet’s new features, including its Redirector C2 mechanism, the unique\r\nasr_xxtea payload decryption algorithm, DGA implementation, and some of its operational capabilities. In\r\nrecent years, the security community has exposed several million-strong botnets targeting Android TVs and set-top boxes, such as Badbox, Bigpanzi, and Vo1d. Why do these devices repeatedly fall prey to large-scale\r\ninfections? We propose two key perspectives: supply chain dynamics and user behavior.\r\nSupply Chain Perspective: Some device manufacturers have ties to illicit actors, pre-installing malicious\r\ncomponents at the factory level. As shipment volumes grow, so does the infection scale, culminating in the jaw-dropping botnets we see today.\r\nUser Behavior Perspective: Many users harbor misconceptions about the security of TV boxes, deeming them\r\nsafer than smartphones and thus rarely installing protective software. Additionally, the widespread practice of\r\ndownloading cracked apps, third-party software, or flashing unofficial firmware—often to access free media—\r\ngreatly increases device exposure, creating fertile ground for malware proliferation.\r\nhttps://blog.xlab.qianxin.com/long-live-the-vo1d_botnet/\r\nPage 46 of 50\n\nOur investigation into Vo1d’s business model continues, with confirmed ties to several companies already\r\nestablished. Moving forward, we aim to share more technical details and insider insights with the community. We\r\nalso hope to leverage collective expertise to clarify the relationship between Bigpanzi and Vo1d, both million-scale botnets targeting Android TVs and sharing string decryption algorithms. This overlap is unlikely to be mere\r\ncoincidence. However, linking them solely based on algorithmic similarity lacks sufficient evidence. We suspect\r\ndeeper connections—shared codebases, developer resources, or even divergent branches of the same group.\r\nThis report encapsulates most of our current intelligence on the Vo1d botnet. We hope it serves as a technical\r\nreference for the security community’s deeper analysis. We warmly invite CERTs worldwide to collaborate with\r\nus, sharing insights and perspectives to combat cybercrime and safeguard global cybersecurity. If our research\r\npiques your interest or you possess insider knowledge, feel free to reach out via X.\r\nIOC\r\nVo1d C2\r\nssl8rrs2.com\r\nttekf42.com\r\nttss442.com\r\nworks883.com\r\ncsskkjw.com\r\ncatmore23.com\r\nsynntre.com\r\ncsok997.com\r\nconannt.com\r\nqocoll.com\r\nhaveits.com\r\nremoredo.com\r\ncatmos99.com\r\nVo1d Downloader\r\nssl87362.com\r\nwowokeys.com\r\n38.46.218.36\r\n38.46.218.37\r\n38.46.218.38\r\n38.46.218.39\r\nVo1d Reporter\r\nworks883.xyz\r\nhttps://blog.xlab.qianxin.com/long-live-the-vo1d_botnet/\r\nPage 47 of 50\n\ncatmore88.com\r\nVo1d Samples\r\n01a692df9deb5e8db620e4fb7e687836 jbf\r\nde8f69efdb29cdf5fd12dd7b74584696 jem\r\n456e14aa644bd31d85e0fe6f78d8fc15 jfz\r\n30da72fda6d0f5e3972272332d7fc47b jhz\r\nfc7dc3c5306d6a508023160953168a16 jddx\r\n53493b07fe423b1dbdc789803cbac7c1 jeex\r\n2d6d91c5988dcab2eb4dab1ec55cfbb9 jtxx\r\n9e116f9ad2ff072f02aa2ebd671582a5 s63\r\nb447aaf52c1efad388612f8220969c35 vo1d\r\nVo1d Payload\r\n## with 5 bytes size\u0026cmd\r\n6bb3258b688f81dfd03128bccf18823b ts01\r\n0c454831bdb679bdd083c5a7cc785733 p6332\r\nbb6b9aec7d4bfa524c7c5117257e4d78 p7332\r\n6168dafc5a1d297cf33b26b65db315cc p8232\r\n4f4d5e37feda9e9556c816c100e1de30 p8932\r\nd9126d936d505b9fa9a8278fda1daaae ts01.decrypt\r\n5701ee051f80e92c1efc5ad32f8401d3 p6332.decrypt\r\na07533a9504fff0756a8ba59ca0af4d6 p7332.decrypt\r\n47c5bf4fbce983c2182ba103d2773dff p8232.decrypt\r\n4efa4566794d86e033c2362cad05f1f8 p8932.decrypt\r\n## without 5 bytes size\u0026cmd\r\n2de1775908db39f3c4edbb7a7d99268d b7027626\r\na774eb68f60621bfddd8db461d978c12 b7027626.decrypt\r\nMzmess C2\r\ndcsdk.100ulife.com\r\ndcsdkos.dc16888888.com\r\n8.219.89.234\r\nhttps://blog.xlab.qianxin.com/long-live-the-vo1d_botnet/\r\nPage 48 of 50\n\npopa C2\r\ngmslb.net\r\nphonemesh.org\r\nlinkmob.org\r\npeercon.org\r\nphonegrid.org\r\nsafernetwork.io\r\nlbk-sol.com\r\nsklstech.com\r\nkyc-holdings.com\r\njaguar C2\r\njaguar-distributor.syslogcollector.com\r\n38.61.8.14\r\n38.61.8.31\r\n69.28.62.49\r\n69.28.62.39\r\n156.236.118.48\r\n69.28.62.51\r\n38.61.8.11\r\n38.61.8.13\r\n69.28.62.38\r\n156.236.118.27\r\n69.28.62.60\r\n38.61.8.33\r\n69.28.62.52\r\n69.28.62.50\r\n38.61.8.12\r\n128.1.71.243\r\n69.28.62.48\r\n69.28.62.41\r\n69.28.62.42\r\n69.28.62.61\r\nlxhwdg C2\r\ng.sxim.me\r\nreg.sxim.me\r\nref.sxim.me\r\nspirit\r\nhttps://blog.xlab.qianxin.com/long-live-the-vo1d_botnet/\r\nPage 49 of 50\n\ntask.mymoyu.shop\r\ntask.moyu88.xyz\r\ntask1.ziyemy.shop\r\ntask2.ziyemy.shop\r\nadstat.moyu88.xyz\r\nadstat.ziyemy.shop:3389\r\nadstat.ad3g.com\r\nadstat2.ziyemy.shop\r\nupdate.ad3g.com\r\nspiritlib.cyou\r\nAppendix\r\nPython ASR\r\ndef asr(value, shift):\r\n \"\"\"\r\n Perform an arithmetic shift right (ASR) operation.\r\n :param value: The signed 32-bit integer (treated as 32-bit)\r\n :param shift: The number of positions to shift.\r\n :return: The result of the arithmetic shift right.\r\n \"\"\"\r\n if value \u0026 0x80000000: # Check if MSB is set (negative number)\r\n return (value \u003e\u003e shift) | (0xFFFFFFFF \u003c\u003c (32 - shift)) \u0026 0xFFFFFFFF\r\n else:\r\n return value \u003e\u003e shift\r\nSource: https://blog.xlab.qianxin.com/long-live-the-vo1d_botnet/\r\nhttps://blog.xlab.qianxin.com/long-live-the-vo1d_botnet/\r\nPage 50 of 50",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://blog.xlab.qianxin.com/long-live-the-vo1d_botnet/"
	],
	"report_names": [
		"long-live-the-vo1d_botnet"
	],
	"threat_actors": [],
	"ts_created_at": 1775791215,
	"ts_updated_at": 1775826728,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/50583f63e3c12ac6ab19ce90bd9913d50bba051d.pdf",
		"text": "https://archive.orkl.eu/50583f63e3c12ac6ab19ce90bd9913d50bba051d.txt",
		"img": "https://archive.orkl.eu/50583f63e3c12ac6ab19ce90bd9913d50bba051d.jpg"
	}
}