{ "id": "b37b0b0d-bf14-466e-b937-ccee089af439", "created_at": "2026-04-06T01:30:03.958785Z", "updated_at": "2026-04-10T03:35:28.940879Z", "deleted_at": null, "sha1_hash": "ec1a9cb66c13ecedea94eccee0ffc7ad555a2615", "title": "Kimwolf Exposed: The Massive Android Botnet with 1.8 Million Infected Devices", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 7529350, "plain_text": "Kimwolf Exposed: The Massive Android Botnet with 1.8 Million\r\nInfected Devices\r\nBy Wang Hao\r\nPublished: 2025-12-17 · Archived: 2026-04-06 01:16:24 UTC\r\nBackground\r\nOn October 24, 2025, a trusted partner in the security community provided us with a brand-new botnet sample.\r\nThe most distinctive feature of this sample was its C2 domain, 14emeliaterracewestroxburyma02132[.]su ,\r\nwhich at the time ranked 2nd in the Cloudflare Domain Rankings. A week later, it even surpassed Google to claim\r\nthe number one spot in Cloudflare's global domain popularity rankings. There is no doubt that this is a hyper-scale\r\nbotnet. Based on the information output during runtime and its use of the wolfSSL library, we have named it\r\nKimwolf.\r\nhttp://blog.xlab.qianxin.com/kimwolf-botnet-en/\r\nPage 1 of 27\n\nKimwolf is a botnet compiled using the NDK. In addition to typical DDoS attack capabilities, it integrates proxy\r\nforwarding, reverse shell, and file management functions. From an overall architectural perspective, its functional\r\ndesign is not complex, but there are some highlights worth noting: for example, the sample uses a simple yet\r\neffective Stack XOR operation to encrypt sensitive data; meanwhile, it utilizes the DNS over TLS (DoT) protocol\r\nto encapsulate DNS requests to evade traditional security detection. Furthermore, its C2 identity authentication\r\nemploys a digital signature protection mechanism based on elliptic curves, where the Bot side will only accept\r\ncommunication instructions after the signature verification passes. Recently, it has even introduced EtherHiding\r\ntechnology to counter takedowns using blockchain domains. These features are relatively rare in similar malware.\r\nBased on our analysis results, it primarily targets Android platform TV boxes. The \"Welcome to Android Support\r\nCenter\" message displayed on the C2 backend also corroborates this.\r\nThe Kimwolf samples use a naming rule of \"niggabox + v[number]\" to identify version numbers. The sample\r\npreviously provided by our community partner was version v4. After completing the reverse engineering analysis,\r\nwe imported the sample's intelligence into the XLab's Cyber Threat Insight and Analysis System, successively\r\ncapturing multiple related samples including v4 and v5, achieving automated continuous tracking of this\r\nfamily.\r\nhttp://blog.xlab.qianxin.com/kimwolf-botnet-en/\r\nPage 2 of 27\n\nOn November 30, we captured another new sample of this botnet family and successfully took over one of the C2\r\ndomains, thereby obtaining the opportunity to directly observe the true operating scale of this botnet for the first\r\ntime. Based on statistics from source IP data that established connections with our registered C2 address and\r\nwhose communication behavior matched Kimwolf C2 protocol characteristics, we observed a cumulative total of\r\napproximately 2.7 million distinct source IP addresses over the three days from December 3 to December 5.\r\nAmong them, we observed approximately 1.36 million active IPs on December 3, about 1.83 million on\r\nDecember 4, and about 1.5 million on December 5 (there is IP overlap between different dates). Analysis indicates\r\nthat Kimwolf's primary infection targets are TV boxes deployed in residential network environments. Since\r\nresidential networks usually adopt dynamic IP allocation mechanisms, the public IPs of devices change over time,\r\nso the true scale of infected devices cannot be accurately measured solely by the quantity of IPs. In other words,\r\nthe cumulative observation of 2.7 million IP addresses does not equate to 2.7 million infected devices.\r\nDespite this, we still have sufficient reason to believe that the actual number of devices infected by Kimwolf\r\nexceeds 1.8 million. This judgment is based on observations in the following areas:\r\nKimwolf uses multiple C2 infrastructures. We took over only a portion of the C2s, so we could only\r\nobserve the activity of some Bots, unable to cover the full picture of the botnet.\r\nOn December 4, the number of Bot IPs we observed reached approximately 1.83 million, a historical peak.\r\nOn that day, parts of the C2s normally used by Kimwolf were taken down by relevant organizations,\r\ncausing a large number of Bots to fail to connect to the original C2s and turn to try connecting to the C2 we\r\npreemptively registered. This anomalous event caused more Bots to be centrally exposed in a short period,\r\nso the data for that day may be closer to the lower limit of the true infection scale.\r\nInfected devices are distributed across multiple global time zones. Affected by time zone differences and\r\nusage habits (e.g., turning off devices at night, not using TV boxes during holidays, etc.), these devices are\r\nnot online simultaneously, further increasing the difficulty of comprehensive observation through a single\r\ntime window.\r\nKimwolf exists in multiple different versions, and the C2s used by different versions are not completely\r\nidentical, which is also one of the important reasons why we cannot obtain a complete perspective.\r\nCombining the above factors, we conservatively estimate that the actual number of devices infected by Kimwolf\r\nhas exceeded 1.8 million. A botnet of such scale possesses the capability to launch massive cyberattacks, and its\r\npotential destructive power cannot be ignored.\r\nWhile working hard to track new versions, we were also full of curiosity about the old versions. Through source\r\ntracing analysis, although we failed to capture old versions like v1 or v2, we surprisingly found that Kimwolf is\r\nactually associated with the Aisuru botnet. Kimwolf relies on an APK file to load and start it during runtime. A\r\nDEX file uploaded to VT from India on October 7 showed obvious homologous characteristics with Kimwolf's\r\nAPK. Subsequently, on October 18, the parent APK of that DEX was uploaded to VT from Algeria; the resource\r\nfiles of this APK contained Aisuru samples for 3 CPU architectures: x86, x64, and arm. We speculate that in the\r\nearly stages of this campaign, the attackers directly reused Aisuru's code; subsequently, likely because Aisuru\r\nsamples had high detection rates in security products—Android platforms have more mature security protection\r\nsystems compared to IoT ecosystems—the group decided to redesign and develop the Kimwolf botnet to enhance\r\nstealth and evade detection.\r\nhttp://blog.xlab.qianxin.com/kimwolf-botnet-en/\r\nPage 3 of 27\n\nFrom the monitoring data of the XLab command tracking system, statistics show that the main functions of the\r\nKimwolf botnet are usually concentrated on traffic proxying, with a small amount of DDoS attacks. However,\r\nbetween November 19 and 22, it suddenly went \"crazy\": in just 3 days, it issued 1.7 billion DDoS attack\r\ncommands, with the attack range covering massive amounts of IP addresses globally. This high-profile spree\r\nfollows on the heels of the C2 domain's unprecedented rise to #1 in global popularity. Theoretically, such a large\r\nnumber of attack commands and targets may not be able to produce substantial attack effects on the targets; this\r\nbehavior may have been purely to demonstrate its own presence.\r\nCurrently, the security community's understanding of Kimwolf presents a polarized situation. Information in the\r\npublic intelligence field is scarce, its propagation path is not yet clear, and the detection rate of related samples\r\nand their C2 domains on VirusTotal is extremely low. At the same time, due to the adoption of covert technologies\r\nlike (DoT), the association between its C2 and samples has not been effectively discovered. However, at the non-public threat confrontation level, the situation is entirely different. We observed that Kimwolf's C2 domains\r\nhave been successfully taken down by unknown parties at least three times, forcing it to upgrade its tactics and\r\nturn to using ENS (Ethereum Name Service) to harden its infrastructure, demonstrating its powerful evolutionary\r\ncapability. Given that Kimwolf has formed a massive attack scale, and its recent activity frequency and attack\r\nbehaviors show a significant upward trend, we believe it is necessary to break the intelligence silence. We hereby\r\nrelease this technical analysis report to make relevant research results public, aiming to promote threat intelligence\r\nsharing, gather community strength to jointly respond to such threats, and effectively maintain cyberspace\r\nsecurity.\r\nTimeline\r\nOctober 24: A trusted community partner provided us with the first Kimwolf sample, version v4.\r\nNovember 1 to 28: The Xlab Large-scale Network Threat Perception System independently captured 8\r\nnew samples, covering v4 and v5 versions.\r\nDecember 1: Xlab successfully took over a C2 domain in version v5, observing a peak daily active bot IP\r\ncount of approximately 1.83 million.\r\nDecember 4: A Kimwolf C2 domain was taken down by an unknown party; the C2 domain could not\r\nresolve to a valid IP address.\r\nhttp://blog.xlab.qianxin.com/kimwolf-botnet-en/\r\nPage 4 of 27\n\nDecember 6: Xlab captured a new v5 sample again, which enabled 6 new C2 domains.\r\nDecember 8: An active downloader server was discovered in the wild, and scripts related to Kimwolf\r\nactivities were successfully captured.\r\nDecember 10: Kimwolf's new C2 domain was taken down again.\r\nDecember 11: Xlab captured a new v5 sample again; this sample enabled a brand new C2 domain, but the\r\nC2 port was not open; the parent APK certificate was updated.\r\nDecember 12: Kimwolf upgraded its infrastructure again, enhancing C2 resilience by introducing ENS\r\ndomains in response to the multiple previous takedowns, even arrogantly declaring \"we have 100s of\r\nservers keep trying LOL!\"\r\nhttp://blog.xlab.qianxin.com/kimwolf-botnet-en/\r\nPage 5 of 27\n\nScale \u0026 Capability\r\nOn December 1, we successfully took over a Kimwolf C2 domain, allowing us to directly assess the true infection\r\nscale of this botnet for the first time. Statistically, the cumulative infected IPs exceeded 3.66 million, reaching an\r\nactivity peak on December 4 with single-day node IPs as high as 1,829,977. Our takeover action seemed to trigger\r\na chain reaction, followed by unknown third parties implementing takedowns (such as stopping DNS resolution)\r\non Kimwolf's other C2 infrastructures. This forced Kimwolf's operators to perform emergency upgrades,\r\ncompletely replacing the sample's C2 configurations, which caused the numbers we observed to drop sharply.\r\ncurrently, the daily active scale is around 200,000.\r\nKimwolf mainly targets the Android platform, involving TVs, set-top boxes, tablets, and other devices. Some\r\ndevice models are shown below:\r\nhttp://blog.xlab.qianxin.com/kimwolf-botnet-en/\r\nPage 6 of 27\n\nDevice Model Device Model Device Model Device Model\r\nTV BOX SuperBOX HiDPTAndroid P200\r\nX96Q XBOX SmartTV MX10\r\nInfected devices are distributed in 222 countries and regions globally. The top 15 countries are analyzed as: Brazil\r\n14.63%, India 12.71%, USA 9.58%, Argentina 7.19%, South Africa 3.85%, Philippines 3.58%, Mexico 3.07%,\r\nChina 3.04%, Thailand 2.46%, Saudi Arabia 2.37%, Indonesia 1.87%, Morocco 1.85%, Turkey 1.60%, Iraq\r\n1.53%, Pakistan 1.39%.\r\nReaders familiar with DDoS might be curious: \"For such a huge botnet, what level has its attack capability\r\nactually reached?\" Although we cannot directly measure it, through observations of two large-scale DDoS events\r\nhttp://blog.xlab.qianxin.com/kimwolf-botnet-en/\r\nPage 7 of 27\n\nand a horizontal comparison with Aisuru, we believe Kimwolf's attack capability is close to 30Tbps.\r\nA well-known cloud service provider observed a 2.3Bpps attack at 22:09Z on November 23, with 450,000\r\nparticipating IPs. We confirmed Kimwolf's participation.\r\nA well-known cloud service provider observed an attack nearing 30Tbps and 2.9Gpps at 09:35Z on\r\nDecember 9. After data comparison, both parties confirmed Kimwolf's participation.\r\nCloudflare pointed out in its Q3 2025 DDoS threat report that Aisuru is one of the strongest known botnets\r\ncurrently, with a control scale of millions of IoT/network devices, capable of sustaining Tbps-level attacks\r\nand even peak attacks approaching 30 Tbps and 10+ Bpps.\r\nIn fact, we believe that behind many attacks observed by Cloudflare attributed to Aisuru, it may not just be the\r\nAisuru botnet acting alone; Kimwolf may also be participating, or even led by Kimwolf. These two major botnets\r\npropagated through the same infection scripts between September and November, coexisting in the same batch of\r\ndevices. They actually belong to the same hacker group.\r\nKimwolf \u0026 Aisuru\r\nHow did we uncover the connection between Kimwolf and Aisuru? It all started with the APK sample (MD5:\r\nb688c22aabcd83138bba4afb9b3ef4fc) captured on October 25. The file and package names were aisuru.apk\r\nand com.n2.systemservice0644 , respectively. This sample implemented a malicious Android boot receiver,\r\nenabling automatic execution upon device startup.\r\nIts main malicious behavior is: extracting a preset binary file (referenced via resource ID\r\nR.raw.libniggakernel ) from the application's own res/raw/ resource directory, writing it to the application\r\ndata directory named niggakernel , and then setting the file permission to executable. Subsequently, the sample\r\nattempts to obtain root privileges via the su command to execute this malicious program, achieving persistence\r\nand system control.\r\nUpon analysis, this preset binary file ji.so is essentially the \"kimwolf\" malware. The sample previously\r\nprovided to us by the security community was exactly the unpacked version of this file.\r\nhttp://blog.xlab.qianxin.com/kimwolf-botnet-en/\r\nPage 8 of 27\n\nUsing various features of the aforementioned APK as clues, we found that the APK (MD5:\r\n887747dc1687953902488489b805d965) has obvious homologous characteristics, such as using the same resource\r\nID name libniggakernel , the same package name systemservice0644 , Log identifier \"LOL\", preset filename\r\nji.so , etc.\r\nWhat surprised us is that the 3 binary files c0.so , ji.so , and q8.so preset in this APK do not belong to the\r\nkimwolf family, but to the AISURU botnet. They use the same C2 and Reporter as the sample\r\n053a0abe0600d16a91b822eb538987bca3f3ab55 mentioned in our September 15 analysis report.\r\nOn November 29, more evidence surfaced. Two APK samples uploaded to VirusTotal successively from the\r\nUnited States were highly similar to the two APKs above. Upon analysis, the libdevice.so in their lib\r\ndirectories corresponded to new variants of \"kimwolf\" and \"aisuru\" respectively.\r\n902cf9a76ade062a6888851b9d1ed30d\r\nFamily: kimwolf\r\nPackage Name: com.n2.systemservice063\r\nlib file directory: /lib/armeabi-v7a/libdevice.so\r\n8011ed1d1851c6ae31274c2ac8edfc06\r\nFamily: aisuru\r\nPackage Name: com.n2.systemservice062\r\nlib file directory: /lib/armeabi-v7a/libdevice.so\r\nMore crucially, these two APKs used the same signing certificate. The certificate SHA1 fingerprint is\r\n182256bca46a5c02def26550a154561ec5b2b983. The content features of this certificate, such as Common Name:\r\nJohn Dinglebert Dinglenut VIII VanSack Smith , are highly unique and have no public record on the internet.\r\nFrom this, it can be judged that they come from the hands of the same development organization.\r\nhttp://blog.xlab.qianxin.com/kimwolf-botnet-en/\r\nPage 9 of 27\n\nOn December 8, we finally had definitive evidence. The script captured on the Downloader server 93.95.112.59\r\ndirectly associated kimwolf ( mreo31.apk ) and aisuru ( meow217 ) together.\r\nCautious readers might ask: \"Is there a possibility that the Aisuru group's code was leaked or sold to a third\r\nparty?\" Frankly speaking, this possibility does exist. Fortunately, although the C2 addresses of the Aisuru samples\r\ncaptured on November 29 mentioned above were updated, they still reused the previously named tiananmeng\r\nReporter. The reuse of infrastructure strongly eliminates the possibility of third-party code reuse. In summary, we\r\nhave high confidence in attributing Kimwolf to the Aisuru group.\r\nTechnical Details\r\nhttp://blog.xlab.qianxin.com/kimwolf-botnet-en/\r\nPage 10 of 27\n\nThe Kimwolf samples we captured can be divided into two major versions: v4 and v5. In v4, Kimwolf's author,\r\neither out of bad taste or to express political attitudes, liked to output various information in the console.\r\nsample 18dcf61dad028b9e6f9e4aa664e7ff92 outputs $$ ForeheadSDK v2.0 Premium Edition $$ ;\r\nsample 2078af54891b32ea0b1d1bf08b552fe8 outputs Kim Jong-un Leads Our Nation to Strength. Long\r\nlive our Supreme Leader! .\r\nThe most exaggerated one is sample 1c03d82026b6bcf5acd8fc4bcf48ed00 , which, besides outputting a series of\r\npolitical views, specifically mocked the well-known cybersecurity investigative journalist Krebs, calling him \"Big\r\nForehead\" (KREBSFIVEHEADFANCLUB), and even jokingly asked the Xlab team to \"taste virgin boy eggs\"\r\n(VIRGINBOYEGGSFORXLAB).\r\nKimwolf's author is quite vengeful. After we preemptively registered their C2, they immediately counterattacked,\r\nleaving an \"easter egg\" in the DDoS attack method of ssl_socket to stigmatize Chinese people. regarding this,\r\nwe just want to say: \"Sooner or later, you'll taste our iron fist.\"\r\nidontlikemchineseniggas\r\nbecausetheylikeitrealyoung\r\nmyniggatheylikeit131415.com\r\nThe core malicious functions of v4 and v5 versions are highly consistent. The execution flow of these samples can\r\nbe summarized as follows: after the sample starts on the infected device, it first achieves single instance by\r\ncreating a file socket to ensure only one process runs continuously on the same device; subsequently, it decrypts\r\nthe embedded C2 domain, and to evade conventional detection, uses the DNS-over-TLS protocol to initiate\r\nhttp://blog.xlab.qianxin.com/kimwolf-botnet-en/\r\nPage 11 of 27\n\nqueries to the port 853 of public DNS services (8.8.8.8 or 1.1.1.1) to obtain the real C2 IP; finally, it establishes a\r\ncommunication connection with that IP, entering a waiting state, ready to receive and execute commands from the\r\ncontrol end at any time.\r\nThe most significant difference between v4 and v5 versions lies in the method of obtaining the real C2 IP: v4\r\nversion directly uses DNS to query the A record of the C2 domain, while v5 version, after querying the IP, requires\r\nan XOR operation. Taking C2 domain rtrdedge1.samsungcdn[.]cloud as an example, the IP resolved on\r\nDecember 3 was 44.7.0.45 ; after XORing with 0xce0491, the real C2 IP 45.206.3.189 is obtained.\r\nOn December 12, Kimwolf began using EtherHiding technology. The sample introduced an ENS domain\r\n(Ethereum Name Service), pawsatyou.eth, with the C2 hidden in the \"lol\" text record.\r\nBut the real C2 is not the IPv6 in \"lol\", but rather obtained by taking the last 4 bytes of the address and performing\r\nan XOR operation to get the real IP. Taking fed0:5dec:ea5e:d013:130:9:1be7:8599 as an example, taking the\r\nlast 4 bytes 1b e7 85 99 and XORing with 0x93141715 yields the real C2 IP 136.243.146.140 .\r\nhttp://blog.xlab.qianxin.com/kimwolf-botnet-en/\r\nPage 12 of 27\n\nThe technical essence of ENS is a system of smart contracts deployed on Ethereum. The contract address for\r\npawsatyou.eth is 0xde569B825877c47fE637913eCE5216C644dE081F . Readers familiar with smart contracts will\r\nnot find it difficult to understand the advantage behind this design: Kimwolf implements a channel similar to\r\ncloud configuration for C2 via the contract. Even if the C2 IP is taken down, the attacker only needs to update the\r\nlol record to quickly issue a new C2. And this channel itself relies on the decentralized nature of blockchain,\r\nunregulated by Ethereum or other blockchain operators, and cannot be blocked.\r\nOverall, Kimwolf's functions are not complex. The following text will take the sample captured on December 9 as\r\nthe main analysis object to dissect Kimwolf's technical details from aspects of string decryption, single instance,\r\nand network protocols.\r\nMD5: 3e1377869bd6e80e005b71b9e991c060\r\nMAGIC: ELF 32-bit LSB executable, ARM, EABI5 version 1 (GNU/Linux), statically linked, no section header\r\nPACKER: UPX\r\nString Decryption\r\nKimwolf uses simple Stack XOR operations to encrypt sensitive data like C2, DNS Resolver, etc. A large number\r\nof similar code snippets can be seen in the pseudo-code decompiled by IDA. veorq_s64 is an 8-byte XOR\r\nhttp://blog.xlab.qianxin.com/kimwolf-botnet-en/\r\nPage 13 of 27\n\ninstruction, so decryption is simple: one can use regex to extract the operands and then perform the XOR. In the\r\nfigure below, the content decrypted by v63 is exactly the C2 staging.pproxy1[.]fun .\r\nI believe readers who have tried manual decryption will find this very inconvenient and ask if there is a more\r\nefficient method. The answer is yes. With a little observation of the code snippet above, we know that the\r\ndecrypted C2 string is the 2nd parameter of function sub_8F00 . Based on this characteristic, we can use an\r\nemulator to achieve batch automatic decryption of C2s.\r\nimport flare_emu\r\neh=flare_emu.EmuHelper()\r\ndef iterateHook(eh, address, argv, userData):\r\n \r\n if eh.isValidEmuPtr(argv[1]):\r\n buf=eh.getEmuString(eh.getRegVal('R1'))\r\n print(f\"0x{address:x} ---\u003e {buf}\")\r\neh.iterate(0x00008F00,iterateHook)\r\nThe final effect is as follows, successfully decrypting 6 C2s:\r\nhttp://blog.xlab.qianxin.com/kimwolf-botnet-en/\r\nPage 14 of 27\n\nThe instruction code for veorq_s64 is VEOR Q8, Q8, Q9 . Through it, we can locate all functions where\r\nencrypted strings are located. Then, based on the patterns presented in different functions, using flare_emu 's\r\niterate or emulateRange can conveniently achieve decryption of all sensitive strings.\r\nSingle Instance\r\nhttp://blog.xlab.qianxin.com/kimwolf-botnet-en/\r\nPage 15 of 27\n\nKimwolf disguises its own process name as netd_services or tv_helper , and uses a Unix domain socket\r\nnamed @niggaboxv[number] to implement single instance control. This combination of features can be used as a\r\nhigh-confidence Indicator of Compromise (IOC) for device troubleshooting.\r\nNetwork Protocol\r\nKimwolf's network communication always uses TLS encryption. In early versions, the application layer protocol\r\nwas directly carried over the TLS tunnel; in the current version, a websocket handshake is performed before\r\nsending the register message, but the protocol is not used subsequently. Its network communication packets\r\nfollow a fixed \"Header + Body\" format. In the Header, the Reserved field is a fixed value 1, while the Magic has\r\niterated three times, currently being \"AD216CD4\"; the structure of the message body varies depending on the\r\nmessage type.\r\ntype Header struct {\r\nMagic [4]byte // \"DPRK\" -\u003e \"FD9177FF\" -\u003e \"AD216CD4\"\r\nReserved uint8 // 1\r\nMsgType uint8\r\nMsgID uint32\r\nBodyLen uint32\r\nCRC32 uint32\r\n}\r\nThe MsgType field is used to explain the message type. Its values and corresponding functions are shown in the\r\ntable below:\r\nMsgType desc\r\n0 register\r\n1 verify\r\n2 confirm\r\n3 heartbeat\r\n4 reconnect\r\n5 tcp proxy\r\n6 udp proxy\r\nhttp://blog.xlab.qianxin.com/kimwolf-botnet-en/\r\nPage 16 of 27\n\nMsgType desc\r\n7 reverse shell\r\n8 cmd execute\r\n9 write file\r\n10 read file\r\n12 ddos attack\r\nCommunication initialization between the Bot and C2 server adopts a three-stage handshake mechanism. Both\r\nparties must sequentially complete the three interactions of register , verify , and confirm to achieve two-way identity authentication before it is considered a trusted session established.\r\nNext, let's explain the interaction process between Bot and C2 using actually generated network traffic.\r\nStep 1: Register, Bot ---\u003e C2\r\nThe Bot sends two 18-byte Headers to the C2, where MsgType is 0, MsgID, BodyLen, CRC32 fields are all 0, and\r\nMagic is FD9177FF .\r\nStep 2: Verify, C2 ---\u003e Bot\r\nThe C2 generates an Elliptic Curve Digital Signature for a random message using a private key and constructs the\r\npacket Body part in the following format.\r\ntype VerifyBody struct {\r\nMsgLen uint32\r\nMsg []byte\r\nSigLen uint32\r\nSig []byte\r\n}\r\nhttp://blog.xlab.qianxin.com/kimwolf-botnet-en/\r\nPage 17 of 27\n\nParsing the Body in the example according to the above structure reveals:\r\nMsgLen is 4 bytes\r\nMsg is xx xx xx xx\r\nSigLen is 0x47 bytes\r\nSignature\r\n #Signature\r\n \r\n 00000000 30 45 02 20 14 ca ab 58 4d 88 b7 e2 26 f2 a0 80 |0E. .Ê«XM.·â\u0026ò.|\r\n 00000010 49 22 c9 b0 98 9e f4 2b f9 01 8e 4c 20 71 ed 17 |I\"É°..ô+ù..L qí.|\r\n 00000020 cc 57 b6 b4 02 21 00 e0 c7 92 cb 28 d8 c9 d7 66 |ÌW¶´.!.àÇ.Ë(ØÉ×f|\r\n 00000030 4f 1b d0 80 b8 35 26 dd 68 65 93 f2 69 13 13 e8 |O.Ð.¸5\u0026Ýhe.òi..è|\r\n 00000040 42 bd a7 6d a8 04 92 |B½§m¨..|\r\nWhen the Bot receives the Verify packet, it uses the hardcoded public key to verify the signature. Once verified, it\r\nenters the final Confirm stage. The author of Kimwolf designed this mechanism with the intention of protecting\r\ntheir C2 network from being taken over by others.\r\n# Publickey\r\n00000000 30 59 30 13 06 07 2a 86 48 ce 3d 02 01 06 08 2a |0Y0...*.HÎ=....*|\r\n00000010 86 48 ce 3d 03 01 07 03 42 00 04 ed 6a a0 57 2d |.HÎ=....B..íjW-|\r\n00000020 53 02 ce 35 cc 0a 04 93 2d b4 86 c9 a8 e2 93 f5 |S.Î5Ì...-´.ɨâ.õ|\r\n00000030 69 07 86 0f 99 42 4b a6 5c 12 7a e7 12 48 56 ad |i....BK¦\\.zç.HV.|\r\n00000040 34 b5 ae 92 ec 98 c9 bc e1 d8 15 dc 6e 1c 59 1b |4µ®.ì.ɼáØ.Ün.Y.|\r\n00000050 be 96 b8 a9 5b 95 46 34 19 5a d2 |¾.¸©[.F4.ZÒ|\r\nStep 3: Confirm, Bot -\u003e C2\r\nThe Bot uses the first parameter passed at runtime as the group identifier, constructs it according to the\r\nGroupBody structure, and reports it to the C2. The group string used in the example is \"android-postboot-rt\".\r\ntype GroupBody struct {\r\nMsgLen uint32\r\nGroup []byte\r\n}\r\nStep 3: Confirm, C2 -\u003e BOT\r\nhttp://blog.xlab.qianxin.com/kimwolf-botnet-en/\r\nPage 18 of 27\n\nAfter receiving the Bot's Confirm packet, the C2 server checks whether its belonging group has been pre-enabled\r\nin the campaign. If the match is successful, the Bot's identity is confirmed as legal, and a Confirm response packet\r\nis sent back to it. The MsgType field value of this response packet is 2, and MsgID, BodyLen, CRC32 fields are\r\nall set to 0.\r\nAfter the above process, the Bot and C2 complete the two-way identity authentication, and the Bot begins waiting\r\nto execute commands sent by the C2. When the command number is 12, Kimwolf executes DDoS-related\r\nfunctions. I believe readers familiar with Mirai will smile knowingly when seeing the DDoSBody, as this structure\r\noriginates exactly from Mirai.\r\nType DDoSBody struct {\r\nAtkID uint32\r\nAtkType uint8\r\nDuration uint32\r\nTargetCnt uint32\r\nTargets []Target\r\nFlagCnt uint32\r\nFlags []Flag\r\n}\r\nBelow are the 13 DDoS attack methods supported by Kimwolf.\r\nhttp://blog.xlab.qianxin.com/kimwolf-botnet-en/\r\nPage 19 of 27\n\nCommand Tracking\r\nData from Xlab shows that the main command of the Kimwolf botnet is to use Bot nodes to provide proxy\r\nservices, accounting for 96.5% of all commands. The rest are DDoS attack commands. DDoS attack targets are\r\nspread across various industries globally. Attack targets are mainly concentrated in regions like the USA, China,\r\nFrance, Germany, and Canada.\r\nhttp://blog.xlab.qianxin.com/kimwolf-botnet-en/\r\nPage 20 of 27\n\nDistribution of command types\r\n1.7 Billion in 3 Days\r\nFrom November 19 to 22, in just 3 short days, Kimwolf issued a staggering 1.7 billion commands, randomly\r\nattacking massive amounts of IP addresses globally. We don't know why it had such confusing attack behavior, as\r\nthese attacks might not even cause substantial damage to the target addresses. We even once suspected whether a\r\nBUG produced by ourselves caused these anomalies. It wasn't until we verified data with multiple top cloud\r\nservice providers that we finally confirmed—Kimwolf is just that crazy; it indeed sprayed the entire internet.\r\nDDoS Attack Trends\r\nArrogant Attack Payloads\r\nKimwolf often includes various ridicule, provocation, and even extortion information in DDoS Payloads.\r\nAdditional Components\r\nIn this campaign, to maximize the bandwidth extraction from compromised devices and maximize profit, the\r\nattackers deployed a Rust-based Command Client and ByteConnect SDK in addition to Kimwolf and Aisuru.\r\n1: Command Client\r\nhttp://blog.xlab.qianxin.com/kimwolf-botnet-en/\r\nPage 21 of 27\n\nThe purpose of the Command Client is to form a proxy network. It targets proxying socks, receives proxy requests\r\nfrom C2, and returns proxy results to C2.\r\nThe sample saves the CC address in ciphertext in the rodata section. The decryption algorithm is not complex,\r\nbeing a byte-wise XOR with a password table of the same length.\r\ndef dec(encbts):\r\n tb1_off = 0\r\n tb2_off = 0x058BCD2 - 0x058BCA0\r\n bts = []\r\n for i in range(0, 0x30*4):\r\n bts.append(chr(encbts[tb1_off+i] ^ encbts[tb2_off+i]))\r\n return(\"\".join(bts[:0x32]))\r\nBased on the samples we have, two CC addresses can be restored, as follows:\r\nproxy-sdk.14emeliaterracewestroxburyma02132.su:443\r\nsdk-bright.14emeliaterracewestroxburyma02132.su:443\r\n2: ByteConnect SDK\r\nThe so-called ByteConnect SDK is a monetization solution that helps developers generate revenue through\r\napplications on various platforms. They claim their SDK is designed to be lightweight, secure, and easy to\r\nintegrate; it is ad-free, has no cryptocurrency mining, does not affect performance, has minimal impact on user\r\nexperience, and users won't even notice its existence.\r\nhttp://blog.xlab.qianxin.com/kimwolf-botnet-en/\r\nPage 22 of 27\n\nmreo12 downloaded by the Downloader script is exactly the ByteConnect SDK.\r\nByteConnect's homepage has a revenue calculation formula: 10,000 access point users, 70% Opt-in Rate, will\r\nyield $490 monthly revenue. With Kimwolf's scale of 1.8 million, the organization behind it earns an astonishing\r\n$88,200 monthly through ByteConnect.\r\nhttp://blog.xlab.qianxin.com/kimwolf-botnet-en/\r\nPage 23 of 27\n\nLittle Gossip\r\nInvestigations found that the author of Kimwolf shows an almost \"obsessive\" fixation on the well-known\r\ncybersecurity investigative journalist Brian Krebs, leaving easter eggs related to him in multiple samples.\r\nFor example, in sample 2078af54891b32ea0b1d1bf08b552fe8 , the domain fuckbriankrebs[.]com is embedded in\r\nboth its udp_dns and mc_enc attack methods, used to generate DNS request payloads.\r\nAnd in the console output of sample 1c03d82026b6bcf5acd8fc4bcf48ed00 , the text\r\nKREBSFIVEHEADFANCLUB appears directly, literally \"Krebs Big Forehead Fan Club,\". Talk about a\r\ndedicated 'hater'.\r\nBesides this direct \"tribute,\" there is \"love\" hidden deeper. The C2 domain we took over\r\nfuckyoukrebs1.briankrabs.seanobrien[redacted]ssn[redacted].su , aside from the string 'krebs' appearing\r\ntwice in the domain itself, hides a mystery: seanobrien[redacted] likely corresponds to Krebs' actual address,\r\nand ssn[redacted] is likely his Social Security Number. Such behavior can be called a \"sasaeng fan\" in the\r\ncyber security world, truly chilling.\r\nSummary\r\nhttp://blog.xlab.qianxin.com/kimwolf-botnet-en/\r\nPage 24 of 27\n\nThis is the majority of the intelligence we currently possess on the Kimwolf botnet. Giant botnets originated with\r\nMirai in 2016, with infection targets mainly concentrated on IoT devices like home broadband routers and\r\ncameras. However, in recent years, information on multiple million-level giant botnets like Badbox, Bigpanzi,\r\nVo1d, and Kimwolf has been disclosed, indicating that some attackers have started to turn their attention to\r\nvarious smart TVs and TV boxes. These devices generally suffer from problems like firmware vulnerabilities, pre-installed malicious components, weak passwords, and lack of security update mechanisms, making them\r\nextremely easy for attackers to control long-term and use for large-scale cyberattacks. One of our motives for\r\ndisclosing the Kimwolf botnet this time is to call on the security community to give due attention to smart TV-related devices.\r\nAfter attackers gain root privileges on smart TVs, the resulting attacks are not limited to traditional cyberspace.\r\nAttackers can use controlled terminals to insert tampered, biased, or extreme videos. In the legal systems of many\r\ncountries, inserting content without written permission violates the contract between the viewer and the TV\r\nprogram provider and is illegal. For example, TV equipment at the HUD headquarters in Washington, D.C., USA,\r\nwas tampered with by hackers to play an unauthorized AI-forged video (showing Trump kissing Musk's toes, with\r\nthe caption LONG LIVE THE REAL KING ), triggering significant public safety and public opinion risks, etc. This is\r\nour second motive for disclosing the Kimwolf botnet this time, calling on law enforcement agencies to consider\r\nscrutinizing such suspected illegal activities related to smart TVs.\r\nNBC News\r\nAgainst the backdrop of overlapping threats, whether ordinary TV box users, sales channels, operators, or\r\nregulatory departments and manufacturers, all must attach great importance to the security of TV boxes. Among\r\nthem, TV box users should especially: ensure devices come from reliable sources, use firmware that can be\r\nupdated in time, avoid setting weak passwords, and refuse to install APKs of unknown origin to reduce the risk of\r\nbeing infected and controlled by botnets.\r\nWe sincerely welcome CERTs from all countries to contact us, share intelligence and vision, join hands to combat\r\ncybercrime, and jointly maintain global cybersecurity. If you are interested in our research, or know inside\r\nhttp://blog.xlab.qianxin.com/kimwolf-botnet-en/\r\nPage 25 of 27\n\ninformation, feel free to contact us via X platform.\r\nIOC\r\nSample MD5\r\n# APK\r\n887747dc1687953902488489b805d965\r\nb688c22aabcd83138bba4afb9b3ef4fc\r\n2fd5481e9d20dad6d27e320d5464f71e\r\n5f4ed952e69abb337f9405352cb5cc05\r\n4cd750f32ee5d4f9e335751ae992ce64\r\n8011ed1d1851c6ae31274c2ac8edfc06\r\n95efbc9fdc5c7bcbf469de3a0cc35699\r\nbda398fcd6da2ddd4c756e7e7c47f8d8\r\nea7e4930b7506c1a5ca7fee10547ef6b\r\ndfe8d1f591d53259e573b98acb178e84\r\n3a172e3a2d330c49d7baa42ead3b6539\r\n# SO ELF\r\n726557aaebee929541f9c60ec86d356e\r\nbf06011784990b3cca02fe997ff9b33d\r\nd086086b35d6c2ecf60b405e79f36d05\r\n2078af54891b32ea0b1d1bf08b552fe8\r\nb89ee1304b94f0951af31433dac9a1bd\r\n34dfa5bc38b8c6108406b1e4da9a21e4\r\n51cfe61eac636aae33a88aa5f95e5185\r\n1c03d82026b6bcf5acd8fc4bcf48ed00\r\ne96073b7ed4a8eb40bed6980a287bc9f\r\nf8a70ca813a6f5123c3869d418f00fe5\r\n33435ec640fbd3451f5316c9e45d46e8\r\n9053cef2ea429339b64f3df88cad8e3f\r\n85ba20e982ed8088bb1ba7ed23b0c497\r\n9b37f3bf3b91aa4f135a6c64aba643bd\r\n# RUST\r\nb1d4739d692d70c3e715f742ac329b05\r\n5490fb81cf24a2defa87ea251f553d11\r\ncf7960034540cd25840d619702c73a26\r\n# Downloader\r\ne4be95de21627b8f988ba9b55c34380c\r\nC2\r\nhttp://blog.xlab.qianxin.com/kimwolf-botnet-en/\r\nPage 26 of 27\n\napi.groksearch[.net\r\nnnkjzfaxkjanxzk.14emeliaterracewestroxburyma02132[.su\r\nzachebt.chachasli[.de\r\nzachebt.groksearch[.net\r\nrtrdedge1.samsungcdn[.cloud\r\nfuckzachebt.meowmeowmeowmeowmeow.meow.indiahackgod[.su\r\nstaging.pproxy1[.fun\r\nsdk-dl-prod.proxiessdk[.online\r\nsdk-dl-production.proxiessdk[.store\r\nlol.713mtauburnctcolumbusoh43085[.st\r\npawsatyou[.eth\r\nlolbroweborrowtvbro.713mtauburnctcolumbusoh43085[.st\r\nDownloader\r\n93.95.112.50 AS397923 - Resi Rack L.L.C.\r\n93.95.112.51 AS397923 - Resi Rack L.L.C.\r\n93.95.112.52 AS397923 - Resi Rack L.L.C.\r\n93.95.112.53 AS397923 - Resi Rack L.L.C.\r\n93.95.112.54 AS397923 - Resi Rack L.L.C.\r\n93.95.112.55 AS397923 - Resi Rack L.L.C.\r\n93.95.112.59 AS397923 - Resi Rack L.L.C.\r\nAppendix\r\ncyberchef\r\nhttps://gchq.github.io/CyberChef/#recipe=Fork('%5C%5Cn','%5C%5Cn',false)Change_IP_format('Dotted%20Decimal','He\r\nSource: http://blog.xlab.qianxin.com/kimwolf-botnet-en/\r\nhttp://blog.xlab.qianxin.com/kimwolf-botnet-en/\r\nPage 27 of 27", "extraction_quality": 1, "language": "EN", "sources": [ "Malpedia" ], "references": [ "http://blog.xlab.qianxin.com/kimwolf-botnet-en/" ], "report_names": [ "kimwolf-botnet-en" ], "threat_actors": [ { "id": "42a6a29d-6b98-4fd6-a742-a45a0306c7b0", "created_at": "2022-10-25T15:50:23.710403Z", "updated_at": "2026-04-10T02:00:05.281246Z", "deleted_at": null, "main_name": "Silence", "aliases": [ "Whisper Spider" ], "source_name": "MITRE:Silence", "tools": [ "Winexe", "SDelete" ], "source_id": "MITRE", "reports": null }, { "id": "5d2bd376-fcdc-4c6a-bc2c-17ebbb5b81a4", "created_at": "2022-10-25T16:07:23.667223Z", "updated_at": "2026-04-10T02:00:04.705778Z", "deleted_at": null, "main_name": "GCHQ", "aliases": [ "Government Communications Headquarters", "Operation Socialist" ], "source_name": "ETDA:GCHQ", "tools": [ "Prax", "Regin", "WarriorPride" ], "source_id": "ETDA", "reports": null }, { "id": "eb5915d6-49a0-464d-9e4e-e1e2d3d31bc7", "created_at": "2025-03-29T02:05:20.764715Z", "updated_at": "2026-04-10T02:00:03.851829Z", "deleted_at": null, "main_name": "GOLD WYMAN", "aliases": [ "Silence " ], "source_name": "Secureworks:GOLD WYMAN", "tools": [ "Silence" ], "source_id": "Secureworks", "reports": null }, { "id": "88e53203-891a-46f8-9ced-81d874a271c4", "created_at": "2022-10-25T16:07:24.191982Z", "updated_at": "2026-04-10T02:00:04.895327Z", "deleted_at": null, "main_name": "Silence", "aliases": [ "ATK 86", "Contract Crew", "G0091", "TAG-CR8", "TEMP.TruthTeller", "Whisper Spider" ], "source_name": "ETDA:Silence", "tools": [ "EDA", "EmpireDNSAgent", "Farse", "Ivoke", "Kikothac", "LOLBAS", "LOLBins", "Living off the Land", "Meterpreter", "ProxyBot", "ReconModule", "Silence.Downloader", "TiniMet", "TinyMet", "TrueBot", "xfs-disp.exe" ], "source_id": "ETDA", "reports": null } ], "ts_created_at": 1775439003, "ts_updated_at": 1775792128, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/ec1a9cb66c13ecedea94eccee0ffc7ad555a2615.pdf", "text": "https://archive.orkl.eu/ec1a9cb66c13ecedea94eccee0ffc7ad555a2615.txt", "img": "https://archive.orkl.eu/ec1a9cb66c13ecedea94eccee0ffc7ad555a2615.jpg" } }