BOTNET KIMWOLF: Internal DDoS Attacks and How to Mitigate Now (2026)
Once again, ISP networks are under attack… but now the enemy comes from within. Have you ever seen the call center explode with complaints of unexplained slowness? We’ve barely recovered from the attack that exploited vulnerabilities in the Realtek SDK where routers and ONUs were compromised and used for DDoS against third parties, and we’re already dealing with a much more dangerous and widespread threat: the AISURU/Kimwolf botnet. This botnet mainly exploits cheap Android IPTV, SmartTV and set-top-box devices installed in users’ homes. These devices become zombies that sell home proxies and, to a lesser extent, participate in DDoS attacks on third parties. The result? Widespread problems on several fronts: RESULT: frustrated customers, high support costs and reputational risk for the entire ISP. A vicious circle that nobody wants and that is growing fast. REAL CHAOS! Below is a compilation of questions and answers to what we already know about the subject. And at the end some tips on how to protect or mitigate yourself. 1) Where is this attack coming from and why? According to security websites Xlab and Synthient, the actors involved in the botnet use it to make money from certain types of service: Since they have complete control of all the devices, they use the command-control servers to create browsing tunnels, install apps and launch DDoS attacks against third parties. There have also been reports of things beyond security, such as passing on images and videos of controversial subjects (political, geo-political, etc.). 2) Are there already a lot of people infected? Data from Synthient and XLab indicate that, although this represents only a fraction of all communications, there were more than 12 million unique IP addresses (estimated to represent about 2 million devices). Most of them come from Brazil (~15%), followed by Vietnam, India, the U.S., and Argentina. The Chinese security company XLab identified that the Kimwolf botnet had compromised between 1.8 and 2 million devices, with a strong concentration in Brazil, India, the United States and Argentina. Image: blog.xLab.qianxin.com 3) How is the equipment infected? You’ve probably wondered how this equipment can be so cheap, right? That’s right. Some images of devices that are already infected. Source: Synthient. It has also been found that they do not undergo a rigorous process of vulnerability fixes, security patches, and updates/improvements. This is a goldmine for criminals. The main way Kimwolf is infected is by exploiting a flaw in the SDKs of residential proxy applications (such as Byteconnect, IPIDEA and PYPROXY). The attacker rents a legitimate proxy from these services, uses the tunnel to “go back” through the device’s own connection and access the internal local network where he finds the ADB (Android Debug Bridge) exposed without authentication (port 5555 and similar). In seconds, it sends remote commands, downloads the malware and installs everything. Residential proxy infection topology. Source: Synthient. There are a number of ways in which equipment can be infected (but they all end up converging on this main mechanism): 1º) From the factory Many devices leave the factory with proxy-residential applications pre-installed (without the user knowing), in order to monetize the bandwidth later. When the device enters the proxy pool (e.g. IPIDEA, Byteconnect, PYPROXY), the attacker exploits exactly this open port.This is the main way of infection and this is how the Kimwolf botnet spread the most, with millions of compromised devices in months. 2º) By installing unreliable apps Users install third-party (unverified) applications, and these silently add the proxy SDK, activating the exploit path via ADB. 3º) Vulnerable ADB/Telnet ports Some of these IPTVs already come with ADB exposed by default. Even without the initial SDK, a small scan/brute force on ports such as 5555, 3222 or 5858 allows shell access and installation of the malware. 4) What are these proxy apps? Basically, they are companies that sell internet browsing through their “proxies” around the world. When you buy a service from them, you set up a “VPN” to their servers, and then your browsing goes through the chosen package (for example, browsing through residential IPs in Brazil, Vietnam, etc.). They make money by charging a few dollars per GB of traffic. But what to do? If you want an easy answer, you won’t get it. We’re going to have to tackle this problem on several fronts. After all, unlike other botnets where the device was in the ISP’s control (the router, the UN, etc), in this case the infected equipment in 99% of cases is the customer’s own. From an ISP perspective, we can tackle the problem in 4 actions: Action 1: identify offending customers/equipment On Synthient’s github (the link will be further down), there is a fraction of the list of IPs/ports used in the botnet. But they are already the first step towards identification. Use this list and compare it with the communications in your netflow software (preferably made4flow), coming from your BNG. With this, you will already know who is infected internally. Action 2: mitigate / circumvent impacts This is where technical creativity comes in. The basic thing is to block communications through a firewall or blackhole (but these don’t last long and serve at most as a band-aid – because the botnet is just as capable of changing IPs/networks as pirate TVs are of bypassing Anatel’s blocks). Once this is done, start thinking about more elaborate solutions. If you need help, call us! Action 3: fix infected equipment The recommendations of security websites are: destroy these devices. Period. But we know the reality. You can’t destroy a customer’s device, but you can work on raising awareness. Develop a script, play your cards right and go visit your client. Show them how their network is being used to commit crimes. Show them the sites, the articles. Try updating, resetting, removing suspicious applications. Use the website https://synthient.com/check to show the customer that they have been caught in the botnet scans. Action 4: implement constant monitoring If you’re dealing with this in your network and want to exchange ideas about filters,
CGN/BNG Performance Tests on Huawei NE8000 Platform
Learn from Luiz Puppin, a Huawei specialist, how to perform a technical analysis of the Forwarding Performance tests carried out in a laboratory environment with the Huawei NE8000 platform, validating the equipment’s ability to operate as an integrated BNG+CGN at high load. The tests sought to verify: Purpose of Performance Tests The aim was to prove that the Huawei solution can be sustained: These features are essential for ISPs and operators with a high concentration of subscribers behind CGNs. Architecture used The topology used connects: Methodology 5. Evidence and Results Below are the verifications taken directly from the test file. 5.1. Subscribers successfully authenticated The report confirms the simultaneous authentication of thousands of PPPoE subscribers: The total validated was: 5.2. Creation of 32 million NAT sessions The DUT has reached the scalability limit set by the manufacturer: In other words, the equipment was able to withstand 32 million simultaneous streams without any noticeable degradation. 5.3. Sustained Traffic at 50 Gbps – No Packet Loss In other words: 5.4. Bidirectional traffic 50 Gbps (25G + 25G) The laboratory validated simultaneous upstream and downstream operation: Again, with zero packet loss: 5.5. CPU stability The CPU remains at stable levels, without reaching critical limits. 5.6. Completion of Performance Tests Based on the evidence, it is possible to conclude that: Therefore, the platform demonstrates real capacity to operate CGN/BNG in large-scale environments, with a high volume of traffic and a high density of subscribers. This article was developed in collaboration with Huawei Brazil’s team of ISP IP Product Managers, with special thanks to Thiago Sério and Natan Fernandes. Need help setting up your Huawei devices? We can help you! I want to learn more
