Does this botnet affect RMerlin firmware?

[Ltvscout]

New KadNap botnet hijacks ASUS routers to fuel cybercrime proxy network

A newly discovered botnet malware called KadNap is targeting ASUS routers and other edge networking devices to turn them into proxies for malicious traffic.

www.bleepingcomputer.com

 

[ColinTaylor]

The server hosting the malware appears to be offline (or blocked).

 

[heysoundude]

The server hosting the malware appears to be offline (or blocked).

Works for me.

Lumen - isn’t that the company in the TV show Severance?

 

[killweav]

Lumen owns my ISP and according to the article has already blocked it. Banned the IP of the script host anyway.

 

[dave14305]

There used to be a time when @Adamm would update Skynet to add detection for known malware IOCs. Some ancient ones still exist in the script, but nothing new in a while. I think the asd daemon started to confuse Skynet as the malware due to the presence of the detection strings in the script.

 

[CornfieldWin]

14,000 member botnet of ASUS routers, very hard to disinfect. Not good.

The article does not indicate the exploits used or the fixes other than update now and update often which really explains nothing by itself.

 

[Viktor Jaep]

Here's a summary incase anyone is looking for more info:

Initial Access:
KadNap gains initial access via credential stuffing against SSH or ASUS router administrative web interfaces—no specific CVE exploitation has been confirmed.

The following Indicators of Compromise (IOCs) have been identified:

Malicious Script: aic.sh downloaded from 212.104.141[.]140
Malware Binary: kad (ELF file) stored in /jffs/.asusrouter

C2 & Peer Nodes:
45.135.180.38
45.135.180.177

Command-and-Control (C2) Infrastructure:
212.104.141[.]140 (primary staging host)

Additional Files:
fwr.sh
/tmp/.sose

Key Behaviors:
Establishes hourly cron job persistence.
Blocks SSH port 22 to prevent remediation.
Uses a custom Kademlia DHT protocol to hide C2 infrastructure.
Communicates via peer-to-peer (P2P) network to evade detection.

Remediation:
Perform a hard factory reset on the ASUS router.
Update to the latest firmware.
Disable remote management on the WAN interface.
Change default admin credentials.
Monitor for unusual outbound traffic.

Lumen Technologies has blocked traffic to the C2 infrastructure for its customers and shared IOCs publicly via GitHub for broader defense.

CISO Briefing: KadNap Botnet — Kademlia DHT C2 Evasion on ASUS Edge Devices

KadNap Botnet: Kademlia DHT C2 Evasion on ASUS Edge Devices Analysis of a P2P Router Botnet Powering the Doppelgänger Criminal Proxy Service Classification: Executive Brief Date: March 11, 202…

labs.cloudsecurityalliance.org

AGAIN, lesson for those to make sure you've hardened your perimeter. Don't expose SSH or web admin access to the internet. Exposed services are the Achilles heel to many of these compromises.

 

[CornfieldWin]

How do you think "harden the perimeter" interacts with the customer's ability on the BE19000AI's to download unsecured docker containers? Realize it is not the immediate issue, but consider the implications of extending a bare metal home router into unrestrained network utility and application space. Why isn't the community speaking out against what could be a devastatingly irresponsible trend, bad as things may already be.

 

[Viktor Jaep]

How do you think "harden the perimeter" interacts with the customer's ability on the BE19000AI's to download unsecured docker containers? Realize it is not the immediate issue, but consider the implications of extending a bare metal home router into unrestrained network utility and application space. Why isn't the community speaking out against what could be a devastatingly irresponsible trend, bad as things may already be.

I can tell you, I'm not a huge fan of this either. It gives a lot of power to unwitting home users who typically have no idea about security, complex networking concepts or technology in general. How are they going to know what holes their docker image just opened. I would be in favor of renaming it to the BE19000PB... PB=Pandora's Box

Getting my popcorn ready

 

[Tech9]

Don't expose SSH or web admin access to the internet.

ASUS routers are regularly targeted, but seems like ASUS see no issue:
[Wireless Router] How to set up ASUS wireless router to access WebGUI/Router App from WAN?

 

[Viktor Jaep]

ASUS routers are regularly targeted, but seems like ASUS see no issue:
[Wireless Router] How to set up ASUS wireless router to access WebGUI/Router App from WAN?

"ASUS PROTIP: How to get your router hacked in 3 easy steps!"

 

[CornfieldWin]

ASUS routers are regularly targeted, but seems like ASUS see no issue:
[Wireless Router] How to set up ASUS wireless router to access WebGUI/Router App from WAN?

Agreed.

ASUS routers are regularly targeted, but seems like ASUS see no issue:
[Wireless Router] How to set up ASUS wireless router to access WebGUI/Router App from WAN?

Agreed.

 

[thelonelycoder]

"ASUS PROTIP: How to get your router hacked in 3 easy steps!"

Doesn't Skynet have a warning message if these ports are open? I remember seeing it.

I should probably add something similar into amtm.
We want the users, the routers and our scripts save, right?

 

[Viktor Jaep]

Doesn't Skynet have a warning message if these ports are open? I remember seeing it.

I should probably add something similar into amtm.
We want the users, the routers and our scripts save, right?

The way things are reporting back on our routers since the introduction of 3006, it seems to be very misleading. When you run an nmap against my WAN IP, you get these results:

Even though these ports are not accessible from the outside. I know that the UDP is definitely not accessible/filtered. But the TCP seems very misleading without doing further checks.

 

[ColinTaylor]

The way things are reporting back on our routers since the introduction of 3006, it seems to be very misleading. When you run an nmap against my WAN IP, you get these results:

View attachment 70716
View attachment 70717

Even though these ports are not accessible from the outside. I know that the UDP is definitely not accessible/filtered. But the TCP seems very misleading without doing further checks.

That's not a problem with the router, it's a problem interpreting the results of the test. Testing from the router itself or LAN is not valid because there are firewall rules that allow all traffic from the LAN/router. Just because you're using the WAN address doesn't mean you're testing from the internet side. The same is true for 3004.

 

[Viktor Jaep]

That's not a problem with the router, it's a problem interpreting the results of the test. Testing from the router itself or LAN is not valid because there are firewall rules that allow all traffic from the LAN/router. Just because you're using the WAN address doesn't mean you're testing from the internet side. The same is true for 3004.

It wasn't doing this with 3004. Running nmap against the WAN would yield no results as it should have been. As soon as I loaded 3006, that was the first thing I noticed that it is interpreting this differently.

 

[ColinTaylor]

It wasn't doing this with 3004. Running nmap against the WAN would yield no results as it should have been. As soon as I loaded 3006, that was the first thing I noticed that it is interpreting this differently.

I ran the same nmap tests on my router running 3004 and a LAN PC before posting and got the same results as in your post (apart from port 8083 which I don't use). I've run these tests in the past also with the same results. So I don't understand why your past results were different. I also don't understand why you would think you would see no results.

EDIT: Perhaps you were running something like Skynet that was doing additional blocking? Just a guess.

 

[NoLight]

Lumen owns my ISP and according to the article has already blocked it. Banned the IP of the script host anyway.

AT&T (Forged Fiber 37) has acquired substantially all of the residential/small-business fiber in 11 states from Lumen on 02/02/26.

MT, WY, ND, SD, and ~35,000 in those 11 states stayed with Lumen (CenturyLink).

 

[Adamm]

Skynet blocks users from exposing ssh/webui to WAN unless secure mode is disabled in the settings. So any Skynet user in theory should be safe.

I’ll look into any IOC’s that can be included such as we have done for previous malware outbreaks over the years.

 

[Viktor Jaep]

I ran the same nmap tests on my router running 3004 and a LAN PC before posting and got the same results as in your post (apart from port 8083 which I don't use). I've run these tests in the past also with the same results. So I don't understand why your past results were different. I also don't understand why you would think you would see no results.

EDIT: Perhaps you were running something like Skynet that was doing additional blocking? Just a guess.

I just tried it against my 3004 router, and you're right. SSH shows as exposed on the WAN. I will have to look through the message history and see exactly when it was that caused this change in the past. Thank you for checking on your end as well.