Forgot your password?
typodupeerror
Botnet Network Security The Internet

Researchers Discover 14,000 Routers Wrangled Into Never-Before-Seen Botnet (arstechnica.com) 32

An anonymous reader quotes a report from Ars Technica: Researchers say they have uncovered a takedown-resistant botnet of 14,000 routers and other network devices -- primarily made by Asus -- that have been conscripted into a proxy network that anonymously carries traffic used for cybercrime. The malware -- dubbed KadNap -- takes hold by exploiting vulnerabilities that have gone unpatched by their owners, Chris Formosa, a researcher at security firm Lumen's Black Lotus Labs, told Ars. The high concentration of Asus routers is likely due to botnet operators acquiring a reliable exploit for vulnerabilities affecting those models. He said it's unlikely that the attackers are using any zero-days in the operation.

The number of infected routers averages about 14,000 per day, up from 10,000 last August, when Black Lotus discovered the botnet. Compromised devices are overwhelmingly located in the US, with smaller populations in Taiwan, Hong Kong, and Russia. One of the most salient features of KadNap is a sophisticated peer-to-peer design based on Kademlia (PDF), a network structure that uses distributed hash tables to conceal the IP addresses of command-and-control servers. The design makes the botnet resistant to detection and takedowns through traditional methods.

[...] Despite the resistance to normal takedown methods, Black Lotus says it has devised a means to block all network traffic to or from the control infrastructure." The lab is also distributing the indicators of compromise to public feeds to help other parties block access. [...] People who are concerned their devices are infected can check this page for IP addresses and a file hash found in device logs. To disinfect devices, they must be factory reset. Because KadNap stores a shell script that runs when an infected router reboots, simply restarting the device will result in it being compromised all over again. Device owners should also ensure all available firmware updates have been installed, that administrative passwords are strong, and that remote access has been disabled unless needed.

This discussion has been archived. No new comments can be posted.

Researchers Discover 14,000 Routers Wrangled Into Never-Before-Seen Botnet

Comments Filter:
  • by abulafia ( 7826 ) on Wednesday March 11, 2026 @08:08PM (#66036406)
    Beginning to think that, if you are a normie[1], affirmatively picking your malware might be the way to go. You're going to get pwned, so you may as well pick one that will defend your gateway from other gangs and hopefully not be too awful.

    Maybe someday we'll seeing APTs advertising for vassals and competing on terms.

    [1] As in, you don't run snort at home or monitor CVE feeds

  • by ZombieCatInABox ( 5665338 ) on Wednesday March 11, 2026 @09:55PM (#66036482)

    ... OpenWRT. That is all.

    • What ever happened to that project that was announced here on Slashdot a while back where someone was gonna try to make a fully open-source-hardware, OpenWRT-compatible wifi router device? Did that ever manage to get off the ground?

      • Ah, it appears that it did. I was thinking of this [slashdot.org]. I don't know if it's any good though.

        • I'd welcome a home router that uses stock OpenWRT. That particular one also seems to be on amazon but not really getting traction. Asus name recognition seems to mean something here.
    • Almost all of these cheapie routers start by customizing openWRT for their hardware. openWRT has had it's own numerous vulnerabilities, over the years. And then there were countless more bugs and hard coded credentials added on top by these shitty routers.

      The point is that openWRT is definitely not the Holy Grail of internet router OSes. I won't even touch on the impossibility of even above average users installing and using it safely.

      • by serafean ( 4896143 ) on Thursday March 12, 2026 @08:27AM (#66036806)

        > The point is that openWRT is definitely not the Holy Grail of internet router OSes.

        That may be, but openwrt at least gets updates.

        • ...that you're discouraged from doing.

          https://openwrt.org/meta/infob... [openwrt.org]

          (I consider this a serious flaw of OpenWRT and do not understand why they've not put processes in place to ensure the downsides they mention don't happen. It's not like Debian or RedHat have the same issue.)

          • yes, opkg (apk since 25.12) shouldn't be used for system upgrades, and since everything is "system" in openwrt, an equivalent to apt-get update doesn't exist.

            There are processes in place, it's called attended sysupgrade [1] which internally uses the owut tool [2]. Those work like a charm.

            And then there is TurrisOS [3] (openwrt for the Turris routers) which somehow coerces opkg to perform the upgrade, with btrfs snapshots as a layer of safety in case things go bad.

            [1] https://openwrt.org/docs/guide... [openwrt.org]
            [2] htt [openwrt.org]

            • > There are processes in place, it's called attended sysupgrade [1] which internally uses the owut tool [2]. Those work like a charm.

              Which is not available in Luci from what I can see. Note also the page I linked to does not say "opkg doesn't do this but we created sysupgrade to do it instead". I feel ultimately this is NOT a supported mechanism even if they claim nothing could possibly go wrong - I mean, why not have it in Luci? Why not tell users logging in via ssh or Luci if there's an update availabl

    • If you're suggesting router manufacturers install OpenWRT, that's just going to create a monoculture which means any bug will get exploited with far, far, more routers than the current situation. Additionally, OpenWRT is not great on the security updates thing - they literally discourage you from updating packages en-mass, and there's no "Urgent! You must upgrade Luci because security hole!" thing to subscribe to.

      If you're suggesting users do this, (1) it's not easy to install OpenWRT in the first place. Ma

    • by mspohr ( 589790 )

      OpenWRT
      This is the obvious solution but it's too complicated for many people.

    • I'd prefer OpenSense, or maybe an OpenBSD based distro that just does routing and firewalls

  • A worthy adversary! (Score:4, Interesting)

    by Gravis Zero ( 934156 ) on Wednesday March 11, 2026 @11:13PM (#66036542)

    One of the most salient features of KadNap is a sophisticated peer-to-peer design based on Kademlia (PDF), a network structure that uses distributed hash tables to conceal the IP addresses of command-and-control servers.

    For the unaware, distributed hash tables (DHT) are regularly used for file-sharing applications, not the distribute files but to find other computers that are sharing files. The downside of DHT is that it's "slow" meaning it can take several minutes for a message to permeate the network.

    Far too often, it seems like cyber criminals are too dumb to be effective because you almost never hear about P2P infrastructure when it comes to botnets. They just keep putting up obvious C&C points that just get taken down, time and time again. When I read this exact paper years ago, it seemed obvious to me that this was the perfect to improve the resiliency for secret/illegal networks. Despite that, it's almost never used!

    Don't get me wrong, they'll still get taken down but it will be more of a challenge.

    • by kackle ( 910159 )
      Thanks for the info., though I am ignorant about this area. Hypothetically, if such routers had unalterable firmware (such as from the PROM days), could they still be hacked in such ways?
      • Well, couldn't be updated to close a hole either - unless the PROM had a hook for add-on code from RAM or from storage...in which case you're right back where you started with installing vulns.

      • if such routers had unalterable firmware (such as from the PROM days), could they still be hacked in such ways?

        Yes. If you can find a trivial error in the binary that enables you to write to RAM which is then executed, that's arbitrary code execution. [wikipedia.org] This can be used to bootstrap receiving a malware package which would overwrite more RAM. XIP (execute in place) [wikipedia.org] firmware (which is executed from read-only memory) could help reduce the attack surface but not eliminate it. However, consumer grade vendors use compressed filesystems (usually SquashFS [wikipedia.org]) to save money on flash memory which makes using XIP impossible. Even i

        • by kackle ( 910159 )
          I wonder what the feasibility would be of making volatile memory non-executable. I write firmware, but have never thought of that before.

          Further, the cost of routers being a little higher for temporary-user-updating-enabling (switches) seems like it's worth it overall. That is, such "insurance" would be no different than locks we take for granted on our houses, fire extinguishers, spare tires and bringing along an umbrella.
          • I wonder what the feasibility would be of making volatile memory non-executable.

            I see no reason that it couldn't be but stack memory could still be hijacked. ROP would still be an option.

            the cost of routers being a little higher for temporary-user-updating-enabling (switches) seems like it's worth it overall.

            It 100% is worth it for the consumer but vendors don't see any benefit because it costs more and consumers are dummies that don't understand the value.

            • by kackle ( 910159 )
              Perhaps marketing/education would be the key: 'New Gravis Zero(tm) hacking protection guaranteed up to $100,000 in damages (federal/law enforcement proof required).' Etc.
              • While plausible, consumer devices are generally a race to the bottom so it's unlikely to become the norm. A far more effective tool would be simple regulatory requirements for new updatable devices with embedded firmware that lack an isolated management interface. Maybe throw in a shadow stack requirement to thwart ROP. It would certainly shake up the MCU market because XIP isn't universally supported and shadow stacks are unheard of.

                • by kackle ( 910159 )
                  It seems like it would be difficult to police.
                  • Not really, just make it a certification process like we do for radio and electrical stuff.

                    • by kackle ( 910159 )
                      From what I've seen with cheap electronics from overseas, manufacturers getting the certifications seems hit-or-miss. And that's assuming the products are legitimately certified when they have appropriate labeling.
                    • Sure but all the major brands are conformant and that's the bulk of devices. Perfect is the enemy of good.

Per buck you get more computing action with the small computer. -- R.W. Hamming

Working...