Malware is abusing car infotainment updates to install proxy software, turning Android head units into nodes for the BADBOX network.

Kaspersky researchers found something in June 2026 that made them stop and look twice: an Android app with no interface at all, installed like any ordinary app but making zero effort to disguise itself as legitimate. Their report documents the first known malware infection targeting car head units, the Android-based infotainment and control systems built into many modern vehicles, spread through the vehicle’s own official update mechanism.

Head units run Android for practical reasons, since manufacturers can build on existing source code and add their own custom system apps during production. That flexibility cuts both ways. Because head units are just Android devices under the hood, most apps built for smartphones can technically run on them too, including malware, even though something like a banking trojan would be wasted effort on a device nobody uses for mobile banking.

Kaspersky researchers found something unusual in June 2026: an Android app with no visible interface that was installed like a normal app but did not try to look legitimate. Their report describes what they say is the first known malware infection targeting car head units, Android-based systems used for infotainment and vehicle controls, delivered through the car’s official update system.

“We identified new Android malware: a multi-stage downloader whose ultimate purpose is ad fraud and creation of a proxy botnet.” reads the report published by Kaspersky. “The malware spread through the built-in updaters of Android-based automotive head unit firmware. This is the first documented case of malware found on a car head unit with an infection chain specific to that type of device.”

Car head units often use Android because it is flexible and lets manufacturers add their own software. But this also creates a security risk. Since these systems are basically Android devices, many apps designed for smartphones can also run on them, including malware.

The infection chain here starts inside TWCore, a completely legitimate system app responsible for analytics and firmware updates on DoFun head units. An MQTT message broker sends TWCore instructions about which APK files to download and install, and a specific configuration flag called installNotExists controls whether the app checks if something is already installed before pushing it.

“TWCore only checks whether an app is already installed on the device when installNotExists = false

The APK file is downloaded to <TWCore external cache dir>/push/apk/ for installation.”

which means setting that flag the other way turns a routine update channel into a silent installation pipeline for anything the attackers want to push.

What gets installed through that channel is a small dropper called JarService, carrying zero user interface and doing nothing but decrypting and loading the next stage. That stage is a loader that phones home to a command server, reports basic device details, and receives a download link for the actual payload, a third-stage module researchers found could be pulled in at least seven different versions simply by trying different version numbers in the download URL. That third stage turns out to be a clicker and reverse proxy component, checking in with its server every 90 minutes by default and waiting for new instructions.

“In this stage, the malware sends a POST request to /cpc/api/task every 90 minutes by default, containing information about the infected device (display resolution, device model, the SSID of the connected Wi-Fi network, MAC address, and so on) along with the Trojan’s configuration version.” continues the report. “If the configuration is outdated, the C2 server returns an updated configuration containing new C2 addresses and new paths for sending HTTP requests.”

The command system behind the malware is more powerful than you might expect from something running silently on a car’s dashboard. Researchers found nine commands, including ones that can change the clipboard, send HTTP requests, load web pages, and run JavaScript. In practice, attackers mainly used two: one to download and run new code, and another to send web requests.

The extra module they deployed, called “zhima,” was a reverse proxy. This means the main goal was not to attack or control the car. Instead, the attackers wanted to use infected cars’ internet connections as part of a larger proxy network.

Tracing the malware’s naming conventions and infrastructure led researchers to attribute the campaign, with high confidence, to MoYu Group, an actor connected to the BADBOX botnet that’s been documented previously by other researchers. A thread inside the second-stage loader carried the internal name “mosdk-host-loader,” which pointed toward malware previously found on TV set-top boxes tied to the same group, and overlapping network infrastructure independently spotted by a separate research team around the same time backed up the connection.

The command system behind the malware is more powerful than you might expect from something running silently on a car’s dashboard. Researchers found nine commands, including ones that can change the clipboard, send HTTP requests, load web pages, and run JavaScript. In practice, attackers mainly used two: one to download and run new code, and another to send web requests.

The extra module they deployed, called “zhima,” was a reverse proxy. This means the main goal was not to attack or control the car. Instead, the attackers wanted to use infected cars’ internet connections as part of a larger proxy network.

There is also a strange detail in the network’s infrastructure. The proxy service’s admin panel allows people to create accounts if they have a valid invite code. Its copyright text and login page also look similar to those used by at least two commercial residential-proxy services. This suggests the network may be linked to a business-like proxy service, while also using infected cars to provide internet connections.

BADBOX has survived several takedown attempts by researchers and law enforcement. This campaign shows why: the people behind it keep changing how they spread the malware and are moving into new types of devices. Cars are now joining smart TVs and set-top boxes as devices that can be quietly added to a botnet. As cars become more like computers, they also need the same kind of security protection.

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, Android Car)

Evooo1Bot is a Mirai-based Linux botnet that hijacks routers and IoT devices for DDoS attacks, credential theft and criminal proxy services.

Fortinet’s FortiGuard Labs disclosed Evooo1Bot in mid-August, a previously undocumented Linux botnet that’s been active since July 2026. The bot borrows Mirai‘s DDoS engine but adds encrypted command-and-control communications, an SSH brute-force scanner, a credential sniffer, and a SOCKS5 proxy module on top.

“FortiGuard Labs has been tracking a previously undocumented Linux botnet family, which we have named Evooo1Bot. The name derives from the hardcoded string “evooo1” found in every binary.” reads the report published by Fortinet. “While the malware reuses the DDoS engine from the publicly leaked Mirai source code, it extends the original framework with numerous capabilities, including encrypted C2 communications, an SSH brute-force scanner, a SOCKS relay module, a credential sniffer, and an integrated exploit arsenal targeting multiple known vulnerabilities.”

The botnet targets 18 known CVEs, some of them dating back to 2007, including:

• CVE-2007-3010: Alcatel OmniPCX Enterprise Remote Code Execution Vulnerability
• CVE-2016-6277: NETGEAR Multiple Routers Remote Code Execution Vulnerability
• CVE-2018-14558: Tenda AC7, AC9, and AC10 Routers Command Injection Vulnerability
• CVE-2019-14931: Mitsubishi Electric Europe B.V. ME-RTU devices and INEA ME-RTU devices remote Command Injection vulnerability
• CVE-2020-10987: Tenda AC1900 Router AC15 Model Remote Code Execution Vulnerability
• CVE-2021-46422: Telesquare SDT-CW3B1 Command Injection vulnerability
• CVE-2022-37055: D-Link Routers Buffer Overflow Vulnerability
• CVE-2024-29269, Telesquare TLR-2005KSH Command Injection Vulnerability
• CVE-2025-10123, D-Link DIR-823X Command Injection Vulnerability
• CVE-2025-55583: D-Link DIR-868L B1 router Command Injection Vulnerability

The bot communicates exclusively over port 443, which is intentional: the traffic blends into expected HTTPS flows at the network perimeter. After gaining initial access through one of its exploit modules or via brute-forced SSH credentials, the bot runs a loader script that clears Bash history to erase evidence of the intrusion before pulling the architecture-appropriate binary from an external server.

The breadth suggests the operators are scanning opportunistically for anything unpatched rather than targeting specific organizations.

“This capability significantly increases the value of an infected host to attackers. The victim’s IP address can be used to disguise malicious traffic, bypass geographic restrictions, or provide access to internal networks through an already compromised machine.” continues the report. “In larger botnets, the same functionality could also be used to build a distributed proxy infrastructure, enabling anonymous traffic forwarding or monetization through residential and enterprise proxy services.”

Evooo1Bot stands out because of its proxy module. A network of compromised routers, cameras, and firewalls acting as SOCKS5 relays is a valuable commodity; operators can use it themselves to obscure attack traffic, or sell access to other criminals looking for residential or enterprise IP addresses that don’t trigger geographic blocks.

“Unlike typical botnet commands that focus on downloading payloads or launching attacks, the !socks module turns an infected host into a SOCKS5 proxy that the operator can use as a network relay. It supports two operating modes. In direct mode, it opens a SOCKS5 listener on the infected host on the default TCP port 1080 and waits for incoming client connections. The implementation first attempts to create a dual-stack IPv6 listener and falls back to IPv4 if that fails. Each accepted client is then passed to the session handler for proxying.” continues the report. “The botnet also implements a reverse relay mode. Instead of exposing a listening port, the bot establishes an outbound encrypted connection to an operator-specified relay server. This persistent control channel listens for commands such as RELAY_NEW:<session_id>, which indicate that a new proxy session should be created.”

After establishing C2 contact, the bot accepts commands covering the full post-compromise toolkit: file upload and download, interactive shell access, persistence installation, binary updates, HTTP Basic Auth and Cookie header interception, DDoS over DNS, TCP, and UDP, and the HTTP exploit dispatcher.

The credential sniffer intercepts authentication headers in transit, so any HTTP Basic Auth credentials passing through an infected device can be captured without any additional effort from the operator. If you’re still running devices with unpatched firmware from the CVE list above, or if any of your edge hardware is using default SSH credentials, Evooo1Bot is already scanning for you.

“Beyond traditional botnet functionality, it features encrypted C2 communications, multiple layers of string obfuscation using AES-256-CTR, ChaCha20, and XOR-based key derivation, as well as a 28-command remote administration interface.” concludes the report. “These capabilities place Evooo1Bot well beyond the technical baseline of conventional Mirai-derived malware.”

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, Evooo1Bot botnet)

Kimwolf v7: The Android TV Botnet That Now Hides Its Traffic Behind Chrome Fingerprints and Ethereum

Palo Alto Networks Unit 42 discovered Kimwolf v7 on February 3, 2026, while hunting threats following public disclosures of the botnet’s earlier activity.

The new version substantially upgrades the DDoS capabilities and command infrastructure of a botnet that has been targeting Android TV boxes since August 2025, while its Linux counterpart AISURU has been active since mid-2024. The operators’ core objective hasn’t changed, build a large-scale DDoS platform, but the methods for sustaining it and hiding its traffic have become considerably more sophisticated.

“This version upgrades its distributed denial-of-service (DDoS) attack capabilities and the resilience of its command-and-control (C2) infrastructure. Kimwolf primarily affects Android TV boxes and set-top boxes.

Kimwolf v7 adds an HTTP/2-based DDoS flood that constructs complete browser fingerprints. This makes attack traffic more difficult to distinguish from legitimate browsing.” reads the report by Palo Alto Networks.

“The threat’s binary includes five hard-coded public Ethereum-based endpoints for resolving Ethereum Name Service (ENS) domains. ENS is a blockchain-based naming system used to obtain C2 addresses.”

The nghttp2 library powers the HTTP/2 flood and constructs headers that mirror legitimate Chrome browser behavior at the protocol level, making rate-limiting and fingerprint-based DDoS mitigation significantly harder.

On top of that, the botnet uses Ethereum’s naming service to resolve its command server address, querying five legitimate public blockchain RPC endpoints shuffled randomly before each attempt, which means blocking any individual endpoint does almost nothing.

“Kimwolf also carries a hard-coded Tor .onion hidden service as a backup and a local proxy architecture for flexible routing between clearnet and Tor.” continues the report. “The malware developers added this function to directly respond to C2 server takedown efforts in December 2025.”

The three-tier structure, Ethereum ENS, then Tor hidden service, then local proxy on 127.0.0.1:23075, is a direct operational response to two takedowns the botnet suffered in December 2025. The local proxy routes all C2 traffic through the same local address regardless of whether it’s going to the clearnet or Tor, which means the proxy component can be updated independently without redeploying the main bot binary. Unit 42 also identified what it assesses with moderate confidence to be an operator-controlled RPC facade at eth.rpcuniverse.com, based on its single-tenant hosting, registration timing, and exclusive presence in Kimwolf samples.

Kimwolf spreads by abusing residential proxy services to reach Android TV boxes that ship with Android Debug Bridge enabled on port 5555. Once tunneled into a local network through a proxy endpoint, attackers can install the malware without any authentication. The botnet masks itself as “netd_service” to blend in with legitimate Android system processes, and Unit 42 found eight APK packages distributed between October and December 2025 that masquerade as a system service called SystemService, probing for root access before executing a bundled kernel payload.

Version 7 also strips out all scanning, exploitation, and brute-force functionality from the main binary — the operators have separated the propagation pipeline from the DDoS core. External loaders now handle initial access, while the Kimwolf binary handles attacks and acts as a relay. The attack method count was consolidated from 43 text-named commands in earlier versions to 15 numbered methods covering layers 3 through 7, including the new HTTP/2 flood, a high-performance UDP flood with ARM NEON SIMD acceleration optimized for the processors in Android TV boxes, and a TLS/HTTPS flood. Unit 42 clustered C2 infrastructure across 22 IP addresses in Saint Petersburg, Russia, all sharing the same SSH host key between December 2025 and February 2026.

The defensive guidance from Unit 42 is straightforward: treat Android TV boxes as untrusted devices and segment them from enterprise networks. Disabling ADB or restricting it to USB-only access removes the primary way this botnet gets onto devices. For detection, watch for outbound HTTPS connections to Ethereum RPC endpoints from devices that normally have no business touching blockchain services, Tor circuit activity or SOCKS5 proxy traffic from TV boxes, connections to localhost port 23075, and any Android consumer device running a process named “netd_service.”

“Kimwolf v7 is a focused evolution of an already large-scale botnet. The HTTP/2 flood with Chrome browser fingerprinting complicates application-layer DDoS mitigation, as attack traffic now mirrors legitimate browser behavior at the protocol and header level.” concludes the report. “The three-tier C2 system (Ethereum ENS, Tor .onion, local proxy) indicates that the operators are investing in infrastructure built to withstand takedown operations.”

In March, the U.S. DoJ disrupted command-and-control infrastructure used by several IoT botnets, including AISURU, Kimwolf, JackSkid, and Mossad. The operation involved authorities from Canada and Germany, along with major tech companies, to target botnet operators and weaken their global cybercrime activities.

The AISURU/Kimwolf botnet was linked to a record-breaking DDoS attack that peaked at 31.4 Tbps and lasted just 35 seconds. Cloudflare said the November 2025 incident was part of a surge in hyper-volumetric HTTP DDoS attacks observed in late 2025, all automatically detected and mitigated.

Kimwolf is a newly discovered Android botnet linked to the Aisuru botnet that has infected over 1.8 million devices and issued more than 1.7 billion DDoS attack commands, according to XLab.

The Kimwol Android botnet primarily targets TV boxes, compiled using the NDK and equipped with DDoS, proxy forwarding, reverse shell, and file management functions. It encrypts sensitive data with a simple Stack XOR, uses DNS over TLS to hide communication, and authenticates C2 commands with elliptic curve digital signatures. Recent versions even incorporate EtherHiding to resist takedowns via blockchain domains.

Kimwolf follows a naming pattern of “niggabox + v[number]”; versions v4 and v5 have been tracked. By taking over one C2 domain, researchers observed around 2.7 million IPs interacting over three days, indicating a likely infection scale exceeding 1.8 million devices. Its infrastructure spans multiple C2s, global time zones, and versions, making it hard to estimate the total number of infections.

The botnet borrows the code from the Aisuru family, however, operators redesigned it to evade detection. Its primary function is traffic proxying, though it can execute massive DDoS attacks, as seen in a three-day period issuing 1.7 billion commands between November 19 and 22.

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, Kimwolf v7)

Researchers uncovered the 200,000-device Dysphoria botnet, which uses Ethereum and Solana domains to hide its command servers.

QiAnXin XLab, jointly with China’s CNCERT, disclosed Dysphoria, a botnet that has compromised roughly 200,000 devices worldwide and uses Ethereum and Solana blockchain domain names to hide its command infrastructure.

The botnet evolved from jackskid and fbot malware families and has been iterating rapidly since XLab first spotted it in March.

In four months, it added a custom RC4 encryption scheme, multi-chain blockchain C2 resolution, and a separate variant that converts infected devices into covert relay nodes.

“Since the first quarter of 2026, XLAB has been tracking a new botnet family called Dysphoria , with over 200,000 bots . This family has undergone frequent mutations and technological iterations in just a few months, demonstrating remarkable resilience.” reads the report published by QiAnXin XLab. “Its evolution has spanned multiple jackskidvariants fbotand recently introduced a C2 covert resolution mechanism based on blockchain ENS/SNS domains , even beginning to transform victim hosts into C2 relay/proxy nodes”

The blockchain-based C2 mechanism is the technically interesting part. Dysphoria queries ENS domains like burrberry.eth and ukranianhorseriding.eth, plus the Solana domain 24carnforth2merseyside.sol, retrieving TXT records that contain fake IPv6 strings. The real IP addresses are hidden inside those strings and recovered through a custom byte-transformation function, so the attacker’s server address never appears in plain text anywhere in the malware or the DNS traffic.

The string protection uses a heavily modified RC4 algorithm. Standard RC4 initializes its S-box with a key, then generates a keystream. Dysphoria adds two extra phases: a linear congruential generator that shuffles the S-box five times after initialization, and a linear feedback shift register that steps during keystream generation, XORing the output with additional rotations and bit shifts before the final byte is applied.

“The latest fbotvariant of Dysphoria has put considerable effort into string protection.” continues the report. “Its decryption algorithm borrows to some extent from jackskidthe code of [previous variant name – likely a specific code or implementation].

• PRGA stage : Introducing LFSR (Linear Feedback Shift Register) stepping during stream generation and performing complex shift swapping.”
• KSA Phase 1 : Standard RC4 initialization.
• KSA 2nd stage : Introduce the LCG (Linear Congruent Generator) algorithm to shuffle the S-box 5 times consecutively.”

All strings in the malware are encrypted with this scheme, which means a basic strings scan returns nothing useful.

The relay variant that appeared on June 25 is a meaningful escalation. It strips out all DDoS attack modules and focuses entirely on turning the infected device into a hidden relay node. After gaining access, it broadcasts a UPnP discovery request across the local network, finds the gateway router, and maps 155 port forwarding rules.

“Once external traffic (such as front-end requests from an attacker or a DDoS sample) connects to a port on the compromised machine bot:P, the relay sample will:

• At the underlying level, Linux’s high-performance epollasynchronous non-blocking I/O driver is used to bind the connections at both ends, implementing bidirectional non-blocking transparent data relay .
• c2:PInitiate an outbound connection immediately to the actual remote device (on the same port).” states the report.

Every four seconds, each relay node reports its status to a heartbeat collection server at login.trees4sale.net:9000, sending a JSON health report with connection count and bandwidth. The architecture means the attacker’s real C2 address never appears in any DDoS bot’s traffic, because the bots only talk to other infected devices acting as relays.

Between July 14 and 20, XLab recorded peak daily pings of 740,000 from infected hosts, with up to 239,000 overseas devices and 1,801 Chinese devices active per day. The operators claim 4 Tbps of DDoS capacity on their public promotion site, selling attack packages ranging from tens to hundreds of dollars depending on duration and bandwidth, a mature commercial operation with subscription tiers. Dysphoria spreads through weak Telnet and SSH credentials and a range of known vulnerabilities in routers, cameras, and IoT devices, including recent ones like CVE-2025-55182 and older ones like CVE-2017-17215 in Huawei devices that remain unpatched across large device fleets. The FTP banner on the download servers reads: “220 cool ftp server hosted on brian krebs’ giant ass 4head.” Apparently even botnet operators have a sense of humor.

“Regarding DDoS attacks, Dysphoria’s targets are located globally, covering multiple industries including internet services and gaming. The victims are characterized by their wide distribution and broad industry coverage.” concludes the report. “Continuous monitoring shows that its attack activity occurs almost daily, maintaining a high level of activity overall. The attack target trends are as follows:”

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, Dysphoria Botnet)

TuxBot v3, an AI-built IoT botnet for 17 architectures, shipped with LLM bugs and safety disclaimers the developer never removed.

Palo Alto Networks’ Unit 42 identified a previously undocumented modular IoT botnet framework called TuxBot v3 Evolution, and it comes with an unusual detail: the developer used a large language model to write significant portions of the code, and the LLM’s safety disclaimer ended up in every compiled binary. Sixty-one C source files each carry an identical header warning that “this code is for educational and authorized security research only.” The developer shipped it without removing a single line.

“The malware authors leveraged an LLM to assist in their code development, yielding mixed results. While the AI complied with their request to generate botnet code, it included a safety disclaimer that the developer failed to remove before shipping.” reads the Unit 42’s report. “Although the LLM clearly aided in constructing the botnet, several functions in the analyzed samples failed to work correctly. While a manual code review could have easily resolved these errors, the authors neglected this step. “

The LLM’s raw chain-of-thought reasoning was also left verbatim in source file comments throughout the codebase, including gems like “// I created them so I should know?” and “// Wait, where is the command?”, an LLM narrating its own confusion to itself, preserved for posterity in a working botnet.

The framework is substantial. It cross-compiles a C-based bot agent for 17 architectures, including ARM, MIPS, PowerPC, RISC-V, and x86_64. It includes a Go-based command-and-control server with a DDoS-for-hire panel, a custom exploit virtual machine, Docker-based test infrastructure, and an automated build system.

The bot brute-forces Telnet access with 1,496 credential pairs and contains exploit code targeting more than 30 IoT device families.

“The TuxBot framework we recovered and analyzed is approximately 70% functional. The core infection flow (scanning, credential brute-forcing, persistence, primary C2 setup and DDoS execution) works.” continues the report. “The Telnet, SSH, HTTP and Android Debug Bridge (ADB) scanners all operate correctly. Furthermore, with its 1,496 credential pairs, the Telnet scanner remains a viable infection vector.”

The parts that don’t work trace almost entirely to bugs introduced by the LLM.

The most consequential LLM failure is in the C2 authentication module. The developer asked for Argon2id password hashing. The LLM couldn’t import the right library, fell back to SHA256 loops, but kept the Argon2id comments, constants, and output format, including a return value formatted as “$argon2id$v=19$…” that contains nothing of the sort.

“Despite its use of PKBDF2 for password hashing, the LLM formats the output to look like Argon2id anyway:

return fmt.Sprintf("$argon2id$v=19$m=%d,t=%d,p=%d$%s$%s", ...)

The LLM hallucinated that it implemented Argon2id but actually fell back to SHA256 loops while keeping the Argon2id comments, constants and output format.” states the report.

There’s also an XOR key mismatch that breaks the IRC fallback channel, four exploit payloads, and HTTP polling. The custom exploit VM never fires because the Go compiler writes the file magic as “TUXE” while the C runtime expects “EXPL.” Sixteen exploit functions are compiled as dead code that never get called. Seventy-eight attack vectors mapped to six handlers, all HTTP application-layer methods silently redirected to TCP SYN floods.

“During our research, we were able to fix these issues with a handful of LLM-assisted prompts. We reconstructed the correct table entries and fixed the IRC C2 channel with a few targeted prompts.” states Palo Alto Networks. “Given that the operator already has the source code and has been actively deploying binaries (six new samples in April 2026), we can reasonably assume that a version with some or all of these fixes already exists in the wild.”

Unit 42 found six new samples in internal telemetry in April 2026, compiled with GCC 14.2.0 production builds across multiple architectures. The C2 infrastructure at 209.182.237[.]133 has been active since at least March 2026.

The developer’s Git log leaked their workstation hostname pointing to an Iranian-hosted machine, and the parent domain digikalas[.]online resolves to Iran’s Arvan Cloud CDN. Shared dropper infrastructure at 185.10.68[.]127 on FlokiNET links TuxBot to Kaitori v3.9 and AISURU tooling, separate codebases that all converge on the same bulletproof host, placing the operator within the Keksec ecosystem.

The development timeline starts in January 2025 with the developer cloning the open-source MHDDoS DDoS toolkit from GitHub, with 254 automated benchmark reports generated in early January 2026 and the first VirusTotal submission appearing January 20. Somebody spent a year building this. The AI helped with most of it, introduced most of the bugs, and nobody caught them because the generated code reads cleanly on the surface.

“Shared infrastructure with Kaitori v3.9 and AISURU tooling places the TuxBot operator within the Keksec ecosystem. This group is known for running multiple IoT botnet variants in parallel. TuxBot appears to be another variant in that portfolio. It’s one that aims to go beyond the usual Mirai fork with its encrypted C2, its DGA and a modular exploit system, even though that system does not work yet in the version we recovered.” continues the report. “The broken features can be fixed. We demonstrated this during our analysis by reconstructing the IRC C2 channel and decrypting the mismatched table entries with a few targeted LLM prompts. “

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, TuxBot v3)

Google disrupted NetNut, a major proxy network that routed internet traffic through compromised home devices used by cybercriminals.

Google has disrupted NetNut, one of the world’s largest residential proxy networks. The service routed internet traffic through home devices, allowing customers to hide their real location and identity.

“Today, in coordination with the FBI, Lumen, and others, Google took action against the NetNut residential proxy network, also known as Popa.” reads the Google’s announcment. “This action builds on our disruption of the IPIDEA proxy network that took place in January 2026, and is a continuation of Google’s objective to dismantle malicious residential proxy networks.”

While proxy services have legitimate uses, networks like NetNut are also widely abused by cybercriminals for fraud, account takeovers, web scraping, and other malicious activities.

NetNut is composed of approximately 2 million compromised home devices. It turns smart TVs, streaming boxes, and other consumer devices into proxy nodes, allowing cybercriminals and espionage groups to hide their identity. Owners often have no idea their devices are being misused, exposing their home networks to additional threats while their internet connections can be abused for hacking, password spraying, fraud, and DDoS attacks.

“In a single week during June 2026, GTIG observed 316 distinct threat clusters using suspected NetNut exit nodes, including cybercriminal and espionage groups. These bad actors can use NetNut to mask their origin IP address when accessing victim environments, accessing their own infrastructure, and conducting password spray attacks.” states the announcement. “Furthermore, when a consumer device becomes an exit node, unauthorized network traffic passes through it.”

Google warns users to avoid apps that promise money for sharing “unused bandwidth” or internet access, as they are often used to build malicious proxy networks. Download apps only from trusted stores, review VPN and proxy permissions, and keep security features like Google Play Protect enabled. When buying connected devices such as TV boxes, choose reputable brands and verify they are Play Protect certified to reduce the risk of compromise.

“While point-in-time disruptions are a critical tool to protect our users, continued and coordinated effort is needed to reduce malicious proxy networks in the long run.” concludes the announcement. “We encourage mobile platforms, ISPs, and other tech platforms to continue sharing intelligence and to take direct action to block malicious C2 infrastructure.”

Cybersecurity firms involved in the investigation linked NetNut to Alarum Technologies, although the company denies operating a botnet and says users consent to bandwidth sharing. Researchers dispute that claim, reporting no clear user consent in tested apps. Google’s disruption has weakened NetNut by removing millions of compromised devices, but warns the threat remains because many proxy providers resell the same infrastructure. Experts believe the takedown will significantly disrupt cybercriminals while also reducing abuse tied to large DDoS botnets.

“Alarum takes this matter seriously and will fully cooperate with law enforcement to ensure any misuse of its infrastructure is thoroughly investigated and those responsible are held to account,” Omer Weiss, legal counsel for NetNut parent Alarum Technologies, said in a written statement, as reported by KrebsOnSecurity.

Synthient founder Benjamin Brundage recently reported he believes the operation is a major setback for cybercriminals, especially after Google’s earlier action against IPIDEA, NetNut’s main competitor, significantly weakened another key source of residential proxy infrastructure.

“As KrebsOnSecurity has warned repeatedly, most of the no-name TV streaming boxes for sale on the major e-commerce websites either come pre-installed with residential proxy software, or require the installation of proxy SDKs in order to use the device for its stated purpose (streaming pirated movies, sporting events and TV shows).” concludes KrebsOnSecurity. “Google’s advice here is sound: When it comes to TV boxes, stick to name brands from reputable manufacturers, and then be sparing and judicious with any apps you choose to install.”

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, botnet)

RustDuck is a small, evolving DDoS botnet migrating to Rust. It uses advanced encryption, anti-analysis evasion, and exploits known IoT flaws.

Since February 2026, researchers at QiAnXin’s XLab have been tracking a new malware family, called RustDuck, that hijacks routers, cameras, Android set-top boxes, and exposed servers, then uses them to flood targets with junk traffic until they go offline. It’s not the biggest DDoS botnet around right now, and that’s almost beside the point.

“The reason XLab flagged it is the speed at which it’s changing. The codebase is actively migrating from C to Rust, and each new variant brings meaningfully more sophisticated encryption, evasion, and communication design.” reads the report published by XLab.

“Although the family’s current activity level and influence in DDoS attacks are not yet comparable to some mainstream botnets, its speed of technological evolution deserves significant attention. Research has found that the family is undergoing a comprehensive technological transition from C to Rust, and its anti-defense and traffic encryption techniques are also iterating rapidly.”

RustDuck doesn’t rely on a single entry point. It combines weak and default passwords on Telnet and SSH interfaces with a broad list of known device vulnerabilities. Targeted hardware includes Android ADB interfaces, DVRs and cameras from TVT, and networking gear from Ruijie, TP-Link, and ZTE. On the software side, it goes after exposed ThinkPHP installations, Jenkins servers, and Hadoop YARN endpoints, which pushes its reach from cheap home hardware into server environments.

The named CVEs in its arsenal range from recent to ancient. CVE-2025-29635 is a command-injection flaw in discontinued D-Link DIR-823X routers that CISA added to its Known Exploited Vulnerabilities list in April 2026. CVE-2017-17215 is a remote code execution bug in Huawei HG532 routers that Mirai variants were already abusing nine years ago. CVE-2024-1781 hits Totolink X6000R routers whose manufacturer never responded to the disclosure. CVE-2018-8007 targets an authenticated admin code execution path in Apache CouchDB. XLab observed more than 20 IP addresses actively spreading the botnet, with 176.65.139[.]204 the most active delivery source.

The XLab researchers reported that RustDuck installs itself in two stages. A loader arrives first, decrypts a compressed payload, and hands execution to a heavier core module. The loader itself has gone through four documented variants, each with a different encryption scheme: the first used a Linear Congruential Generator with XOR and LZ4 compression; the second upgraded to Xoshiro128 with hardcoded constants designed to make batch decryption nearly impossible; the third reverted to standard XOR with a fixed magic string; the fourth introduced ChaCha20 as the stream cipher. The progression isn’t random. Each step reflects the authors responding to detection.

The core module is where the Rust rewrite is happening, and Rust binaries are genuinely harder to analyze than the C that has powered device malware for years. That’s not a minor operational detail. It means the newer samples resist the standard toolkit analysts have used on IoT malware since Mirai.

Before RustDuck does anything visible, the core module runs a weighted scoring system to decide whether it’s sitting on a real victim device or inside a researcher’s lab. Each detected condition adds points to a risk score. Hit the threshold, and the malware erases its traces and exits cleanly.

“To thwart automated sandbox analysis and dynamic debugging by reverse engineers, the Core module incorporates a dynamic weight scoring mechanism. During runtime, the software iterates through various environment checks.” continues the report. “When the accumulated risk score exceeds a preset threshold, the program automatically erases traces and exits.”

The highest-weight checks, worth 100 points each, scan the process list for tools like Wireshark, gdb, and Frida, read /proc/self/status to detect an attached debugger, and verify a SHA256 checksum appended to the malware’s own file so it knows if anyone has modified it or inserted breakpoints. A check worth 50 points looks for honeypot configuration files from Cowrie and Dionaea in standard system paths. Another worth 35 points makes an asynchronous connection attempt to 192.0.2.1, an IP address reserved for testing that should never respond on a real network. If it does respond, the malware knows it’s inside a fake environment built to fool it, and leaves.

The timing check is particularly well-constructed. It samples two independent clocks before and after a deliberate half-second sleep, then compares the difference. A sandbox that speeds up time to rush malware through its behavior, or a debugger that pauses execution at a breakpoint, will show an anomaly in that comparison. Both conditions trigger an exit.

Once the malware decides the environment is genuine, it initiates a structured two-phase connection to its command-and-control infrastructure. The handshake phase uses ChaCha20-Poly1305 encryption and a Curve25519 key exchange, with session keys derived through HKDF-SHA256. The key rotates every ten minutes. After the handshake completes, the session switches to AES-GCM with separate keys for traffic going up to the server and commands coming down, a design that breaks the assumption that capturing one key gives you both directions of the conversation.

The command loop traffic adds a three-byte header that mimics the structure of standard TLS records, which helps the traffic blend into normal encrypted web traffic at the network layer.

“The new variant’s network communication protocol deeply references the IK pattern of the Noise protocol framework. Relying on the client’s hardcoded server static public key and the ephemeral public key generated at runtime for ECDH, session keys are derived. Additionally, the protocol introduces a global MsgID across all phases, which is used for message sequence verification and participates in rolling generation of new keys.” continues the report. “This design cuts off the possibility of decrypting traffic on the network side using plaintext keys.”

The C2 domains lean on free dynamic DNS services, specifically duckdns.org, which is where the name comes from.

Once a device checks in successfully, the operator has five commands available: launch a DDoS attack across various flood types, stop an active attack, fetch the device’s current status and resource usage, upgrade the malware to a newer build, and push new C2 infrastructure dynamically. That last one matters because it means the operator can rotate away from a blocklisted domain without losing the infected device.

RustDuck isn’t the first botnet to pick up Rust. Fortinet documented RustoBot in April 2025, a Rust-based DDoS botnet spreading through Totolink and other routers using a structurally similar playbook. The broader DDoS landscape has been brutal this year: AISURU and related botnets, combining over three million hijacked devices, drove attacks approaching 30 Tbps before a US-led takedown this spring. Next to that scale, RustDuck is currently small.

One detail XLab flags without drawing a firm conclusion: the most active delivery IP, 176.65.139[.]204, sits in the same small address block as infrastructure tied to a separate ADB-targeting DDoS botnet reported earlier in 2026. Shared bulletproof hosting is a plausible explanation. Worth noting either way.

There’s no single patch for RustDuck because it’s not a single vulnerability. Shutting down its entry points means getting remote management interfaces off the public internet entirely, disabling Android Debug Bridge where it isn’t needed, and never leaving Telnet or SSH reachable with default credentials. CouchDB has patched releases available. The D-Link DIR-823X does not, and CISA’s guidance is to pull it from service. The Totolink maker never responded to the disclosure at all. Gear past end-of-life needs to be replaced, not managed around.

XLab’s full report includes the loader SHA1 hashes, known C2 domains, and the active delivery addresses. Feed them into your monitoring now, before the next variant makes the current indicators stale.

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, newsletter)