DDoS

史上最疯：独家揭秘感染全球180万Android设备的巨型僵尸网络Kimwolf

Alex.Turing, Wang Hao, Acey9, rootkiter

• 29 min read
史上最疯：独家揭秘感染全球180万Android设备的巨型僵尸网络Kimwolf

背景介绍

2025年10月24日，安全社区的信任伙伴给我们提供了一个全新的僵尸网络样本，该样本最特别的地方是它的C2域名14emeliaterracewestroxburyma02132[.]su彼时在Cloudflare 域名流行度排名中位列第2，一周之后甚至超越Google，问鼎Cloudflare 域名流行度排名全球第一。毫无疑问这是一个超级大规模的僵尸网络，基于样本运行时输出的信息以及使用wolfssl库，我们将它命名为Kimwolf.

kimwolf_cfno1.png

Kimwolf 是一个使用 NDK 编译的僵尸网络，除具备典型的 DDoS 攻击能力外，还集成了代理转发、反向 Shell 和文件管理等功能。从整体架构来看，其功能设计并不复杂，但其中仍有一些值得关注的亮点：例如，该样本采用了简单而有效的栈异或（Stack XOR）操作对敏感数据进行加密；同时利用 DNS over TLS（DoT）协议封装 DNS 请求，以规避传统安全检测。此外，其 C2 身份认证采用基于椭圆曲线的数字签名保护机制，Bot 端会在验签通过后才接受通信指令。近期更引入EtherHiding技术以区块链域名对抗处置，这些特征在同类恶意软件中较为少见。从我们的分析结果来看，它主要针对Android平台电视盒子。C2 后台所显示的 “欢迎来到 Android Support Center” 信息也可以印证这一点。

kimwolf_banner.png

Kimwolf样本中使用“niggabox + v数字”的命名规则来标识版本号，社区伙伴先前提供的样本为v4版本。我们在完成逆向分析之后，将样本的情报导入XLab大网威胁感知系统，陆续捕获包括v4、v5在内的多个相关样本，实现了对该家族的自动化持续跟踪。

11月30日，我们再次捕获到该僵尸网络家族的一个新样本，并成功接管了其中一个C2域名，从而首次获得了直接观测该僵尸网络真实运行规模的机会。基于与我们注册的C2地址建立连接、且通信行为符合Kimwolf C2协议特征的源IP数据进行统计，在12月3日至12月5日的三天内，共观测到累计约270 万个不同的源IP地址。其中，12月3日观测到约136万个活跃 IP，12月4日约183万个，12月5日约150万个（不同日期之间存在IP重叠）。分析表明，Kimwolf主要感染对象为部署在住宅网络环境中的电视盒子。由于住宅网络通常采用动态IP分配机制，设备的公网IP会随时间变化，因此无法仅通过 IP数量准确衡量被感染设备的真实规模。换言之，累计观测到的270万个IP地址并不等同于270万台被感染设备。

尽管如此，我们仍有充分理由认为，kimwolf实际感染的设备数量超过180万台。这一判断基于以下几个方面的观察：

  • kimwolf使用多个C2基础设施。我们接管的仅是其中一部分C2，因此只能观测到部分Bot的活动，无法覆盖整个僵尸网络的全貌。
  • 在12月4日，我们观测到的Bot IP数量达到约183万，为历史峰值。当天，kimwolf 正常使用的部分C2被相关机构处置，导致大量Bot无法连接原有C2，转而尝试连接我们抢注的C2。这一异常事件使得更多Bot 在短时间内集中暴露，因此该日的数据可能更接近真实的感染规模下限。
  • 被感染设备分布在全球多个时区。受时区差异和使用习惯影响（例如夜间关机、节假日不使用电视盒子等），这些设备并不会同时在线，进一步增加了通过单一时间窗口全面观测的难度。
  • kimwolf 存在多个不同版本，且不同版本使用的C2并不完全相同，这也是我们无法获取完整视角的重要原因之一

综合以上因素，我们保守估计 kimwolf 的实际感染设备数量已超过180万台。如此规模的僵尸网络具备发动大规模网络攻击的能力，其潜在破坏力不容忽视。

在努力跟踪新版本的同时，我们也对旧版本充满了好奇。通过溯源分析，虽然没能捕获v1,v2之类的旧版本，但是我们惊奇的发现Kimwolf居然和Aisuru僵尸网络关联在一起。Kimwolf运行时依赖一个APK文件将它加载启动，一个于10月7日由印度上传到VT的DEX文件表现出了和Kimwolf的APK明显的同源特征，随后在10月18日该DEX的母体APK于阿尔及利亚被上传至VT，该APK的资源文件包含x86,x64,arm3个CPU架构的Aisuru样本。我们推测此次活动初期，攻击者直接复用了 Aisuru 的代码展开活动；随后，可能由于 Aisuru 样本在安全产品中的检测率较高——与 IoT 生态相比，Android 平台具备更成熟的安全防护体系——该团伙决定重新设计并开发了 Kimwolf 僵尸网络，以增强隐蔽性，规避检测。

从XLab指令跟踪系统的监测数据来看，统计显示Kimwolf僵尸网络的主要功能通常集中于流量代理，少量DDoS攻击。然而在11月19日至22日期间，它突然“发疯”：短短的3天，下发了17亿条DDoS攻击指令，攻击范围几乎覆盖全球大量IP地址。这是C2域名流行度登顶事件之后，又一次高调且疯狂的行动，理论上来说如此多的攻击指令和攻击目标可能无法对目标产生实质性的攻击效果，这次行为可能是纯粹为了彰显自身存在感。

当前，安全社区对Kimwolf的认知呈现两极分化态势。公开情报领域信息稀缺，其传播路径尚未明确，相关样本及其C2域名在VirusTotal上的检出率极低。同时，由于采用（DOT）等隐蔽技术，其C2与样本之间的关联性也未能被有效发现。然而，在非公开的威胁对抗层面，情况截然不同。我们观察到Kimwolf的C2域名已被未知方成功处置至少三次，迫使其战术升级，转而利用基于区块链的命名服务（例如Ethereum Name Service，即 .eth 域名）来加固基础设施，显示出其强大演化能力。鉴于Kimwolf已形成庞大攻击规模，且近期活动频率与攻击行为呈显著上升趋势，我方认为有必要打破情报沉默。特此发布本技术分析报告，公开相关研究成果，旨在推动威胁情报共享，凝聚社区力量共同应对此此类威胁，切实维护网络空间安全。

时间线

  • 10月24日，社区信任伙伴向我们提供了首个 kimwolf 样本，版本为 v4。

  • 11月1日至28日，Xlab 大网威胁感知系统独立捕获8个新样本，涵盖 v4 与 v5 版本。

  • 12月1日，Xlab 成功接管 v5 版本中的一个 C2 域名，观测到的日活跃 bot IP数量峰值约达 183 万。

  • 12月4日，Kimwolf C2域名被未知方处置，C2域名无法解析到有效的IP地址。

kimwolf_error1.png

  • 12月6日，Xlab再次捕获到新的 v5 样本，该样本启用6个新的 C2 地址。
  • 12月8日，发现在野活跃的下载服务器，成功捕获kimwolf活动相关脚本。
  • 12月10日，Kimwolf的新C2域名再次被处置

kimwolf_error2.png

  • 12月11日，Xlab再次捕获到新的 v5 样本，该样本的启用一个全新的C2域名，但C2端口并未开放；母体APK证书更新。
  • 12月12日，Kimwolf再次升级基础设施，通过引入区块链的域名来增强C2的抗打击能力，以回应此前遭到的多次处置，甚至嚣张宣称“手握百台服务器，欢迎来封”。

kimwolf_ens.png

感染规模 & 攻击能力

12月1日，我们成功接管了一个Kimwolf的C2域名，首次得以直接评估该僵尸网络的真实感染规模。从统计数据来看，累计感染IP超过366万，并于12月4日达到活跃峰值，单日节点IP高达1829977。我们的接管行动似乎触发了连锁反应，随后未知第三方对Kimwolf的其他C2基础设施实施了处置（如停止DNS解析）。此举破使Kimwolf的运营者不得不紧急进行升级，全面替换样本的C2配置，这导致我们观测到的数字急剧下降，当前日活规模在20万左右。

kimwolf_sinkhole.png

Kimwolf主要针对安卓平台，涉及电视、机顶盒，平板等设备，部分设备型号如下所示：

Device Model Device Model Device Model Device Model
TV BOX SuperBOX HiDPTAndroid P200
X96Q XBOX SmartTV MX10

感染设备分布在全球222个国家和地区，排名前15国家分析为巴西14.63%，印度12.71%，美国9.58%，阿根廷7.19%，南非3.85%，菲律宾3.58%，墨西哥3.07%，中国3.04%，泰国2.46%，沙特
2.37%，印度尼西亚1.87%，摩洛哥1.85%，土耳其1.60%，伊拉克1.53%，巴基斯坦1.39% 。
kimwolf_vic.png

熟悉DDoS的读者可能会好奇：“如此庞大的僵尸网络，其攻击能力究竟达到了何种水平？”虽然我们无法直接度量，但通过两次大型DDoS事件的观察以及与Aisuru的横向对比，我们认为Kimwolf的攻击能力已接近30Tbps。

  • 某知名云服务商在11月23日22：09Z观测到一起2.3Bpps的攻击，参与攻击的IP数量为45万，我方确认Kimwolf参与其中。
  • 某知名云服务商在12月9日09:35Z观测到的一起接近30Tbps，2.9Gpps攻击，经过数据比之后，双方确定Kimwolf参与其中。
  • Cloudflare在其2025第三季度的DDoS威胁报告指出Aisuru是目前已知攻击能力最强的僵尸网络之一，控制规模达百万级 IoT/网络设备，可持续发动 Tbps 级 乃至峰值接近 30 Tbps、10+ Bpps 的超大规模 DDoS 攻击。

实际上，我们认为Cloudflare观测到多起被归因于Aisuru的攻击背后，可能并非只有Aisuru一个僵尸网络在活动，Kimwolf也可能参与其中，甚至是由Kimwolf主导。这两大僵尸网络在9月至11月期间通过相同的感染脚本传播，共存于同一批设备中，它们其实隶属于同一个黑客团伙。

Kimwolf与Aisuru关联

我们是如何发现Kimwolf与Aisuru的关联呢？一切要从10月25日捕获的APK样本（MD5: b688c22aabcd83138bba4afb9b3ef4fc）说起，它的文件名与包名分别为aisuru.apk和com.n2.systemservice0644。这个样本实现了一个恶意的Android启动接收器（Boot Receiver），能够在设备启动完成后自动运行。

其主要恶意行为是：从应用自身的res/raw/资源目录中，提取一个预置的二进制文件（通过资源ID R.raw.libniggakernel引用），并将其写入应用数据目录下，命名为niggakernel，随后将该文件权限设置为可执行。接着，样本会尝试通过su命令获取root权限来执行此恶意程序，实现持久化驻留与系统控制。

经分析，这个预置的二进制文件ji.so，实质上就是“kimwolf”恶意软件。之前安全社区向我们提供的样本，正是该文件脱壳后的版本。

kimwolf_1025apk.png

以上述APK的种种特征为线索，我们发现APK（MD5:887747dc1687953902488489b805d965）具有明显的同源特征，比如使用相同的资源ID名libniggakernel，相同的包名systemservice0644，Log标识“LOL”，预置文件名ji.so等。

kimwolf_1018apk.png

令我们惊奇的是，这个APK中预置的3个二进制文件c0.so, ji.so, q8.so并不属于kimwolf家族，而是AISURU僵尸网络。它们与我们9月15日分析报告中提及的样本053a0abe0600d16a91b822eb538987bca3f3ab55使用相同的tiananmeng C2和Reporter。

kimwolf_1018aisuru.png

11月29日，更多证据浮出水面，两个先后从美国上传至VirusTotal的APK样本与上面俩个APK高性相似。经分析，它们lib目录中的libdevice.so分别对应“kimwolf”和“aisuru”新变种。

  • 902cf9a76ade062a6888851b9d1ed30d

    家族：kimwolf

    包名：com.n2.systemservice063

    so文件目录：/lib/armeabi-v7a/libdevice.so

  • 8011ed1d1851c6ae31274c2ac8edfc06 ，

    家族：aisuru

    包名：com.n2.systemservice062

    so文件目录：/lib/armeabi-v7a/libdevice.so

更为关键的是，这俩个APK使用了相同的签名证书，证书SHA1指纹为182256bca46a5c02def26550a154561ec5b2b983。该证书的内容特征，如Common Name:John Dinglebert Dinglenut VIII VanSack Smith具有高度独特性，在互联网上并无公开记录，由此可以判断，它们出自同一开发组织之手。

kimwolf_apkcertificate.png

12月8日，我们终于有了一锤定音的证据，在Downloaer服务器93.95.112.59上捕获的脚本中直接将kimwolf(mreo31.apk)和aisuru(meow217)关联在一起。

kimwolf_dlscript.png

谨慎的读者或许会问：“是否存在一种可能，即Aisuru团伙的代码遭泄露或已转卖给了第三方？”坦白而言，这种可能性确实存在。所幸的是，上述11月29日捕获的Aisuru样本，虽然C2地址已更新，但仍复用了此前名为tiananmeng的Reporter。基础设施的复用强有力地排除了第三方复用代码的可能性。综上，我们在技术层面有高度的信心将Kimwolf归属于Aisuru团伙。

kimwolf_aisurunew.png

技术细节

我们捕获的Kimwolf样本中可以分成v4，v5俩个大版本。在v4中，Kimwolf的作者或是出于恶趣味，或是出于表达政治态度，喜欢在控制台输出各种信息。例如在样本18dcf61dad028b9e6f9e4aa664e7ff92，输出$$ ForeheadSDK v2.0 Premium Edition $$；样本2078af54891b32ea0b1d1bf08b552fe8输出 Kim Jong-un Leads Our Nation to Strength. Long live our Supreme Leader!。最夸张的是样本1c03d82026b6bcf5acd8fc4bcf48ed00，除出输出一系列政治观点，还专门嘲讽知名网络安全调查记者Krebs，称其拥有“大脑门”（KREBSFIVEHEADFANCLUB），甚至戏谑地让Xlab团队“品尝童子蛋”（VIRGINBOYEGGSFORXLAB）。

kimwolf_console3.png

Kimwolf的作者相当睚眦必报，我们抢注其C2之后，他们马上反击，在ssl_socket的DDoS攻击方法中，留下一个“彩蛋”对中国人进行污名化。对此，我们只想说：“迟早得吃我们几记铁拳”。

idontlikemchineseniggas
becausetheylikeitrealyoung
myniggatheylikeit131415.com

v4与v5版本的核心恶意功能高度一致，其运作流程均可概括为：样本在受感染设备启动后，首先通过创建文件socket实现单一实例，确保同一设备上仅有一个进程持续运行；随后解密内嵌的C2域名，并为了规避常规检测，使用DNS-over-TLS协议向公共DNS服务（8.8.8.8或1.1.1.1）的853端口发起查询，以获取真实C2 IP；最终与该IP建立通信连接，进入等待状态，随时准备接收并执行来自控制端的指令。

v4与v5版本最显著的区别在于获取真实C2 IP的方式：v4版本直接使用DNS查询C2域名的A记录，而v5版本在查询到IP后，还需进行异或操作。以C2域名rtrdedge1.samsungcdn[.]cloud为例，其在12月3日解析出的IP为44.7.0.45，与0xce0491异或后得到真实的C2 IP45.206.3.189。

kimwolf_realip.png

12月12日Kimwolf开始使用EtherHiding技术，样本了引入一个 ENS 域名（Ethereum Name Service，以太坊名称服务），pawsatyou.eth，C2隐藏在“lol”的文本记录。

kimwolf_enslol.png
但真实C2并不是"lol"中的IPV6，而是取地址的后4字节再进行异或后得到真实IP。以fed0:5dec:ea5e:d013:130:9:1be7:8599为例，取后4字节1b e7 85 99与0x93141715后得到真实C2 IP136.243.146.140。

kimwolf_decipv6.png

ENS的技术本质是一套部署在以太坊上的智能合约系统，pawsatyou.eth的合约地址为0xde569B825877c47fE637913eCE5216C644dE081F。熟悉智能合约的读者不难理解这一设计背后的优势：Kimwolf通过合约实现了一种类似云端配置C2的渠道，即使C2 IP被处置，攻击者只需更新lol记录就能快速下发新的C2。而这个渠道本身依托于区块链的去中心化特性，不受以太坊或其他区块链运营方的监管，也无法被阻断。

kimwolf_updatec2.png

总体来说，Kimwolf的功能并不复杂，下文将以12月9日捕获的样本为主要分析对象，从字串解密，单一实例，网络协议等方面剖析Kimwolf的技术细节。

MD5:3e1377869bd6e80e005b71b9e991c060
MAGIC:ELF 32-bit LSB executable, ARM, EABI5 version 1 (GNU/Linux), statically linked, no section header
PACKER: UPX

字串解密

Kimwolf使用简单的栈异或（Stack XOR）操作对C2， DNS Resolver等敏感数据进行加密。IDA反编译的伪码中可以看到大量类似的代码片段，veorq_s64是8字节的异或指令，所以说解密很简单可以使用正则提取出操作数，然后进行异或即可，下图示例中v63解密的内容正是C2 staging.pproxy1[.]fun

kimwolf_xor.png

相信尝试过手动解密的读者都会觉得这非常不方便，会问有没有更高效的方法呢？答案是肯定的，稍加观察上图的代码片段，可知解密后的C2字串是函数sub_8F00的第2个参数。根据这个特点，可以借助模拟器实现C2的批量自动解密。

import flare_emu

eh=flare_emu.EmuHelper()
def iterateHook(eh, address, argv, userData):
   
    if eh.isValidEmuPtr(argv[1]):
        buf=eh.getEmuString(eh.getRegVal('R1'))
        print(f"0x{address:x} ---> {buf}")

eh.iterate(0x00008F00,iterateHook)

最终效果如下，成功解密出6个C2：

kimwolf_decryption.png
veorq_s64的指令码为VEOR Q8, Q8, Q9，通过它可以定位所有加密字串所在的函数。再根据在不同函数所呈现的模式，利用flare_emu的iterate或emulateRange就能方便的实现解密所有敏感字串。

kimwolf_pattern.png

单一实例

Kimwolf将自身进程名伪装为netd_services或tv_helper，并使用名为@niggaboxv[数字]的Unix域socket实现单一实例控制。这一组合特征可作为高置信度感染指标用于设备排查。

kimwolf_unix.png

网络协议

Kimwolf的网络通信始终采用TLS加密。早期版本中，应用层协议直接承载于TLS隧道；在当前版本中，在发送register消息之前还会进行websocket握手，但后续并没有使用该协议。它的网络通信报文遵循“Header + Body”的固定格式。在Header中，Reserved字段为固定值1，而Magic则是已迭代变更三次，当前版本为“AD216CD4”；Body部分则是不同的功能有不同的结构。

type Header struct {
	Magic    [4]byte   // "DPRK" -> "FD9177FF" -> "AD216CD4"
	Reserved uint8    //1 
	MsgType  uint8
	MsgID    uint32
	BodyLen  uint32
	CRC32    uint32
}

MsgType字段则是用于说明消息类型，它的取值及对应的功能如下表所示：

MsgType desc
0 register
1 verify
2 confirm
3 heartbeat
4 reconnect
5 tcp proxy
6 udp proxy
7 reverse shell
8 cmd execute
9 write file
10 read file
12 ddos attack

Bot与C2服务器之间的通信初始化采用一种三阶段握手机制。双方必须顺序完成register、verify、confirm三次交互，实现双向身份认证后，才被视为建立可信会话。
接下来，让我们以实际产生的网络流量来解释Bot与C2的交互过程。

kimwolf_traffic.png

Step1: Register, Bot ---> C2

Bot向C2 发送俩次18字节的Header，其中MsgType为0，MsgID，BodyLen，CRC32字段均为0，Magic为FD9177FF 。

Step2: Varify, C2 ---> Bot

C2使用私钥对随机消息生成椭圆曲线数字签名，并按以下格式构建报文Body部分。

type VerifyBody struct {
	MsgLen uint32
	Msg    []byte
	SigLen uint32
	Sig    []byte
}

示例中Body按上述结构体进行解析可知：

  • MsgLen为4字节

  • Msg为 xx xx xx xx

  • SigLen为0x47字节

  • 签名

  #Signature
  
  00000000  30 45 02 20 14 ca ab 58 4d 88 b7 e2 26 f2 a0 80  |0E. .Ê«XM.·â&ò .|
  00000010  49 22 c9 b0 98 9e f4 2b f9 01 8e 4c 20 71 ed 17  |I"É°..ô+ù..L qí.|
  00000020  cc 57 b6 b4 02 21 00 e0 c7 92 cb 28 d8 c9 d7 66  |ÌW¶´.!.àÇ.Ë(ØÉ×f|
  00000030  4f 1b d0 80 b8 35 26 dd 68 65 93 f2 69 13 13 e8  |O.Ð.¸5&Ýhe.òi..è|
  00000040  42 bd a7 6d a8 04 92                             |B½§m¨..|

当Bot收到Verify报文时，会使用硬编码的公钥验签。验证通过后即进入最终的Confirm阶段。Kimwolf的作者设计这一机制，本意是保护其C2网络不被他人接管。

# Publickey

00000000  30 59 30 13 06 07 2a 86 48 ce 3d 02 01 06 08 2a  |0Y0...*.HÎ=....*|
00000010  86 48 ce 3d 03 01 07 03 42 00 04 ed 6a a0 57 2d  |.HÎ=....B..íj W-|
00000020  53 02 ce 35 cc 0a 04 93 2d b4 86 c9 a8 e2 93 f5  |S.Î5Ì...-´.ɨâ.õ|
00000030  69 07 86 0f 99 42 4b a6 5c 12 7a e7 12 48 56 ad  |i....BK¦\.zç.HV.|
00000040  34 b5 ae 92 ec 98 c9 bc e1 d8 15 dc 6e 1c 59 1b  |4µ®.ì.ɼáØ.Ün.Y.|
00000050  be 96 b8 a9 5b 95 46 34 19 5a d2                 |¾.¸©[.F4.ZÒ|

Step3: Confirm, Bot -> C2

Bot将运行时传入的第一个参数做为分组标识，并按照GroupBody结构进行构造，上报给C2。示例使用的分组字串为“android-postboot-rt“。

type GroupBody struct {
	MsgLen uint32
	Group    []byte
}

Step3 : Confirm, C2 -> BOT

C2服务器在收到Bot的Confirm报文后，会查验其所属分组是否已预先在活动中启用。若匹配成功，则确认该Bot身份合法，并向其回传一个Confirm响应报文。该响应报文的MsgType字段值为2，且MsgID、BodyLen、CRC32字段均置为0。

经过以上流程之后，Bot和C2才算完成双完身份的认证，Bot开始等待执行C2发下的指令。当指令号是12时，Kimwolf执行DDoS相关功能，相信熟悉Mirai的读者看到DDoSBody的肯定会心一笑，该结构正是源于Mirai。

Type DDoSBody struct {
	AtkID     uint32
	AtkType   uint8
	Duration  uint32
	TargetCnt uint32
	Targets   []Target
	FlagCnt   uint32
	Flags     []Flag
}

以下为Kimwolf支持的13种DDoS 攻击方法。

kimwolf_vector.png

指令跟踪

从Xlab的数据看Kimwolf僵尸网络的主要指令是利用Bot节点提供代理服务，占所有指令的96.5%。其余为DDoS攻击指令。DDoS攻击目标遍布全球各个行业。攻击目标主要集中在美国、中国、法国、德国、加拿大等地区。

cmdtypeimags
指令类型分布

迷之攻击，3天17亿

11月19日到22日，Kimwolf在短短的3天时间内，下发了高达17亿条指令，随机攻击全球大量IP地址。我们不清楚它为什么会有这种让人迷惑的攻击行为，因为这些攻击可能也无法对目标地址造成实质性的伤害。甚至一度怀疑是不是我们自己产生的BUG导致了这些异常。直到与我们多家头部云服务商进行数据核验后，才最终确认——Kimwolf 就是这么疯狂，它确实是扫射了整个互联网。

cmdtypeimags
DDoS攻击趋势

嚣张的攻击Payload

Kimwolf时常在DDoS的Payload中夹带各种嘲笑，挑衅，甚至勒索信息。

  • 嘲讽

kimwolf_bad_cmd_2.png

  • 挑衅

kimwolf_bad_cmd_1.png

  • 勒索

kimwolf_ransom_cmd.png

额外的组件

在此次活动中，攻击者了为了最大限度的榨干被入侵设备的带宽，利益最大化。除了Kimwolf和Aisuru之后，还投入了Rust语言实现的Command Client以及ByteConnect SDK。

1: Command Client

Command Client的目的是组建代理网络，它以代理 socks 为目标, 从 C2 接收代理请求, 并将代理结果返回给 C2。

kimwolf_ruststr.png

样本会将 CC 地址以密文形式保存在 rodata 段, 解密算法并不复杂, 为同长密码表的按字节异或.

def dec(encbts):
    tb1_off = 0
    tb2_off = 0x058BCD2 - 0x058BCA0
    bts = []
    for i in range(0, 0x30*4):
        bts.append(chr(encbts[tb1_off+i] ^ encbts[tb2_off+i]))
    return("".join(bts[:0x32]))

基于我们手中的样本, 可还原出两条CC地址, 分别如下:

proxy-sdk.14emeliaterracewestroxburyma02132.su:443
sdk-bright.14emeliaterracewestroxburyma02132.su:443

2: ByteConnect SDK

所谓ByteConnect SDK 是一款变现解决方案，可帮助开发者在各种平台上通过应用程序创收，他们宣称自己的 SDK 设计轻巧、安全，易于集成，它无广告，无加密货币挖矿，不影响性能，对用户体验的影响极小，用户甚至不会察觉到它的存在。

kimwolf_byteconnect.png

Downloader脚本下载的mreo12正是ByteConnect SDK。

kimwolf_bc.png

ByteConnect的主页有一个收入计算公式：1万个接入点客，70% Opt-in Rate，每月将有490美元的收入。以Kimwolf 180万的规模来说，其背后的组织每月通过ByteConnect赚取的惊人的88200美元。

kimwolf_money.png

小小八卦

调查发现，Kimwolf的作者对知名网络安全调查记者Brian Krebs表现出近乎“痴迷”的执念，在多个样本中留下与他相关的彩蛋。

例如，在样本2078af54891b32ea0b1d1bf08b552fe8中，其udp_dns与mc_enc攻击方法中均嵌入了域名fuckbriankrebs[.]com，用于生成DNS请求载荷。

而在样本1c03d82026b6bcf5acd8fc4bcf48ed00的控制台输出中，更是直接出现了KREBSFIVEHEADFANCLUB字样，直译为“Krebs大脑门粉丝俱乐部”，哈哈，妥妥的“黑粉”行为。

除了这种直接的“致敬”，还有隐藏更深的“爱”。我们接管的C2域名fuckyoukrebs1.briankrabs.seanobrien[redacted]ssn[redacted].su，除了明面上Krebs俩次，这一域名还暗藏玄机：seanobrien[redacted]对应的可能是Krebs的实际住址，ssn[redacted]则可能是其社会安全号码。如此行为，堪称网安世界的“私生饭”，着实让人发憷。

总结

这是我们目前掌握的Kimwolf僵尸网络的大部分情报。巨型僵尸网络始发于2016年的mirai，感染的目标主要集中在家庭宽带路由器，摄像头等IoT设备上。然而近年来 Badbox、Bigpanzi、Vo1d、Kimwolf等多个百万级巨型僵尸网络信息被披露，表明部分攻击者开始将注意力转向多款智能电视、电视盒子。这些设备普遍存在固件漏洞、预装恶意组件、弱口令以及缺乏安全更新机制等问题，极易被攻击者长期控制并用于大规模网络攻击。我们披露本次Kimwolf僵尸网络的动机之一，就是呼吁安全社区对智能电视相关设备给予应有的重视。

智能电视被攻击者拿到root权限后，带来的攻击不限于传统的网络空间，攻击者可以利用受控终端插播被篡改、有偏向或者极端视频，在许多国家的法律体制中，未经书面许可插播内容是破坏了观众和电视节目供应商的契约，是违法行为。例如，美国华盛顿特区 HUD 总部的电视设备曾被黑客篡改并播放一段未经授权的 AI 伪造视频（内容为特朗普亲吻马斯克脚趾，并附带LONG LIVE THE REAL KING字样），引发了显著的公共安全与舆论风险，等等。这是我们披露本次Kimwolf僵尸网络的动机之二，呼吁执法机构考虑对此类对智能电视相关的涉嫌违法行为加以审查。

imags
美国全国广播公司新闻（NBC News）报道

在多重威胁叠加的背景下，无论是普通电视盒子用户、销售渠道、运营商，还是监管部门与厂商，都必须高度重视电视盒子的安全。其中，电视盒子用户尤其应当：确保设备来源可靠、使用可及时更新的固件、避免设置弱密码，并拒绝安装来路不明的 APK，以降低被僵尸网络感染和操控的风险。

诚挚欢迎各国CERT（计算机应急响应小组）与我们联系，共享情报与视野，携手打击网络犯罪，共同维护全球网络安全。如果您对我们的研究感兴趣，或者了解内幕消息，欢迎通过X平台与我们联系。

IOC

Sample MD5

# APK
887747dc1687953902488489b805d965
b688c22aabcd83138bba4afb9b3ef4fc
2fd5481e9d20dad6d27e320d5464f71e
5f4ed952e69abb337f9405352cb5cc05
4cd750f32ee5d4f9e335751ae992ce64
8011ed1d1851c6ae31274c2ac8edfc06
95efbc9fdc5c7bcbf469de3a0cc35699
bda398fcd6da2ddd4c756e7e7c47f8d8
ea7e4930b7506c1a5ca7fee10547ef6b
dfe8d1f591d53259e573b98acb178e84
3a172e3a2d330c49d7baa42ead3b6539

# SO ELF
726557aaebee929541f9c60ec86d356e
bf06011784990b3cca02fe997ff9b33d
d086086b35d6c2ecf60b405e79f36d05
2078af54891b32ea0b1d1bf08b552fe8
b89ee1304b94f0951af31433dac9a1bd
34dfa5bc38b8c6108406b1e4da9a21e4
51cfe61eac636aae33a88aa5f95e5185
1c03d82026b6bcf5acd8fc4bcf48ed00

e96073b7ed4a8eb40bed6980a287bc9f
f8a70ca813a6f5123c3869d418f00fe5
33435ec640fbd3451f5316c9e45d46e8
9053cef2ea429339b64f3df88cad8e3f
85ba20e982ed8088bb1ba7ed23b0c497
9b37f3bf3b91aa4f135a6c64aba643bd

# RUST
b1d4739d692d70c3e715f742ac329b05
5490fb81cf24a2defa87ea251f553d11
cf7960034540cd25840d619702c73a26

# Downloader
e4be95de21627b8f988ba9b55c34380c

C2

api.groksearch[.net
nnkjzfaxkjanxzk.14emeliaterracewestroxburyma02132[.su

zachebt.chachasli[.de
zachebt.groksearch[.net
rtrdedge1.samsungcdn[.cloud
fuckzachebt.meowmeowmeowmeowmeow.meow.indiahackgod[.su

staging.pproxy1[.fun
sdk-dl-prod.proxiessdk[.online
sdk-dl-production.proxiessdk[.store

lol.713mtauburnctcolumbusoh43085[.st

pawsatyou[.eth
lolbroweborrowtvbro.713mtauburnctcolumbusoh43085[.st

Downloader

93.95.112.50	AS397923 - Resi Rack L.L.C.
93.95.112.51	AS397923 - Resi Rack L.L.C.
93.95.112.52	AS397923 - Resi Rack L.L.C.
93.95.112.53	AS397923 - Resi Rack L.L.C.
93.95.112.54	AS397923 - Resi Rack L.L.C.
93.95.112.55	AS397923 - Resi Rack L.L.C.
93.95.112.59	AS397923 - Resi Rack L.L.C.

Appendix

cyberchef

https://gchq.github.io/CyberChef/#recipe=Fork('%5C%5Cn','%5C%5Cn',false)Change_IP_format('Dotted%20Decimal','Hex')Swap_endianness('Hex',4,true)From_Hex('Auto')XOR(%7B'option':'Hex','string':'00%20ce%2004%2091'%7D,'Standard',false)To_Hex('Space',0)Change_IP_format('Hex','Dotted%20Decimal')&input=NDQuNy4wLjQ1CjE2OC4xLjAuNDUKMTY3LjEuMC40NQoxNjIuMS4wLjQ1CjE4OS4xLjAuNDUKMTgxLjEuMC40NQoxMzEuMS4wLjQ1