What's new

Malware damaging ASUS routers?

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

Would this be consider a temporary fix in the meantime or permanent?

As permanent as you want it to be, just like any workaround. I never used AiCloud so I've no worries.

*edit* This attack vector has been seen before, a while ago though - CVE-2013-4937. Asus fixed that one pretty quick, but I wonder if their firmware developers opened the door again.
 
Last edited:
Ax82u and ax96u models are infected as well, even I updated to the latest firmware (I am a Ax82u user) the WAN spikes started and broke my wifi 2.4g and 5ghz performance by doing factory reset on the firmware that suppose to secure the hack. Strange enough is not doing a proper factory reset, not even using the hard method (wps buttom) to restore even the wifi are code or partitions of the router again.
 
thanks never used any icloud services i keep it as simple as possible , less chance of problems
 
thanks never used any icloud services i keep it as simple as possible , less chance of problems
Same here....never used AiCloud and maybe the "temp" fix is working well for those that use this feature! Some folks might not even be aware of it.
 
Watching the BE98 (normal, not Pro)
while the router you paid more for

GT-BE98 and GT-BE98 Pro are versions of the same router intended for different regions. You pay for what is available in your country, no choice between Pro and non-Pro version. If one got firmware update today most likely the other will get firmware update shortly after.
 
Very interesting indeed. This is the MIPS router from 2012:

1730866226251.png


I personally never expected to see a new firmware for this long time EoL product, but shows level of care. 👍
 
Looks like the RT-AX86U Pro got an update:
No manual download file as of this post available yet on Asus's main support website or the Asus US support website. From the link, the release notes:

Firmware version 3.0.0.6_102_34334-gc806ad3_403-gd851b
- Release Note -

Bug Fixes and Enhancements:
1. Strengthened input validation and data processing workflows to further protect information security.
2. Enhanced AiCloud password protection mechanisms, safeguarding against unauthorized access attempts.
3. Enhanced device security through improved buffer handling in connection features.
4. Refined data handling processes, ensuring secure and accurate information management.
5. Enhanced file access control mechanisms, promoting a more secure operating environment.
6. Strengthened certificate protection, providing enhanced data security.
 
Same issue, 2022 RT-AX86U, and I never used AiCloud. Current Version : 3.0.0.4.388_24243-g3b611ea
* suddenly my login credentials did not work starting around Nov 3, 2024
* I did a factory reset (took multiple tries), and setup everything in WiFi-Router mode as before, no AiCloud
* when accessing the WiFi settings I got the pop-up: "The Country Code is not exist! Please enter Country Code."

After logging in to the router via SSH, I was able to confirm that ccode was not set (no result), I was able to set the country code from the commandline, and it now does persist after reboot... but...
-> the reboot takes a suspiciously long time,
-> the pop-up is gone
-> the WiFi networks still don't come up 😞, WiFi lights are off

So no real luck here - just posting this here in case it helps someone else



# nvram get 0:ccode
# nvram get 1:ccode
# nvram get ccode
# nvram get wl_country_code
#
# nvram set 0:ccode=US
# nvram set 1:ccode=US
# nvram set ccode=US
# nvram set wl_country_code=US
# nvram set pci/1/1/ccode=US
# nvram set pci/2/1/ccode=US
# nvram set pci/1/1/vendid=0x14e4
# nvram set pci/2/1/vendid=0x14e4
# nvram commit
# reboot


# nvram get 0:ccode
US
# nvram get 1:ccode
US
# nvram get ccode
US

# nvram get wl0_radio
1
# nvram get wl1_radio
1

# ifconfig | grep wl
# service restart_wireless

Done.
# ifconfig | grep wl
# lsmod | grep wl
wl 7549641 0
dpsta 22764 1 wl
cfg80211 229463 1 wl
igs 24708 1 wl
emf 17102 2 wl,igs
hnd 329395 4 wl,dpsta,igs,emf
wfd 32344 1 wl
bcmlibs 22457 6 wl,wfd,pktrunner,bcm_enet,pktflow,rdpa
wlcsm 13599 70 hnd,bcm_pcie_hcd

So radios are enabled 🤔 but no joy

------------------

Here are the full logs of what happens when the `service restart_wireless` is run:

Nov 6 13:42:49 rc_service: service 21820:notify_rc restart_wireless
Nov 6 13:42:49 kernel: ubi2: attaching mtd10
Nov 6 13:42:49 kernel: ubi2: scanning is finished
Nov 6 13:42:49 kernel: ubi2: attached mtd10 (name "misc1", size 8 MiB)
Nov 6 13:42:49 kernel: ubi2: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes
Nov 6 13:42:49 kernel: ubi2: min./max. I/O unit sizes: 2048/2048, sub-page size 2048
Nov 6 13:42:49 kernel: ubi2: VID header offset: 2048 (aligned 2048), data offset: 4096
Nov 6 13:42:49 kernel: ubi2: good PEBs: 64, bad PEBs: 0, corrupted PEBs: 0
Nov 6 13:42:49 kernel: ubi2: user volume: 1, internal volumes: 1, max. volumes count: 128
Nov 6 13:42:49 kernel: ubi2: max/mean erase counter: 31/13, WL threshold: 4096, image sequence number: 1725884149
Nov 6 13:42:49 kernel: ubi2: available PEBs: 0, total reserved PEBs: 64, PEBs reserved for bad PEB handling: 4
Nov 6 13:42:49 kernel: ubi2: background thread "ubi_bgt2d" started, PID 21977
Nov 6 13:42:50 kernel: UBIFS (ubi2:0): background thread "ubifs_bgt2_0" started, PID 22010
Nov 6 13:42:50 kernel: UBIFS (ubi2:0): UBIFS: mounted UBI device 2, volume 0, name "nvram"
Nov 6 13:42:50 kernel: UBIFS (ubi2:0): LEB size: 126976 bytes (124 KiB), min./max. I/O unit sizes: 2048 bytes/2048 bytes
Nov 6 13:42:50 kernel: UBIFS (ubi2:0): FS size: 5840896 bytes (5 MiB, 46 LEBs), journal size 1396736 bytes (1 MiB, 11 LEBs)
Nov 6 13:42:50 kernel: UBIFS (ubi2:0): reserved for root: 0 bytes (0 KiB)
Nov 6 13:42:50 kernel: UBIFS (ubi2:0): media format: w4/r0 (latest is w4/r0), UUID 4B2A44DD-417E-46D8-97CE-24D278768884, small LPT model
Nov 6 13:42:50 kernel: UBIFS (ubi2:0): un-mount UBI device 2
Nov 6 13:42:50 kernel: UBIFS (ubi2:0): background thread "ubifs_bgt2_0" stops
Nov 6 13:42:51 kernel: ubi2: detaching mtd10
Nov 6 13:42:51 kernel: ubi2: mtd10 is detached
Nov 6 13:42:51 kernel: ubi2: attaching mtd10
Nov 6 13:42:51 kernel: ubi2: scanning is finished
Nov 6 13:42:51 kernel: ubi2: attached mtd10 (name "misc1", size 8 MiB)
Nov 6 13:42:51 kernel: ubi2: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes
Nov 6 13:42:51 kernel: ubi2: min./max. I/O unit sizes: 2048/2048, sub-page size 2048
Nov 6 13:42:51 kernel: ubi2: VID header offset: 2048 (aligned 2048), data offset: 4096
Nov 6 13:42:51 kernel: ubi2: good PEBs: 64, bad PEBs: 0, corrupted PEBs: 0
Nov 6 13:42:51 kernel: ubi2: user volume: 1, internal volumes: 1, max. volumes count: 128
Nov 6 13:42:51 kernel: ubi2: max/mean erase counter: 31/13, WL threshold: 4096, image sequence number: 1725884149
Nov 6 13:42:51 kernel: ubi2: available PEBs: 0, total reserved PEBs: 64, PEBs reserved for bad PEB handling: 4
Nov 6 13:42:51 kernel: ubi2: background thread "ubi_bgt2d" started, PID 22071
Nov 6 13:42:52 kernel: UBIFS (ubi2:0): background thread "ubifs_bgt2_0" started, PID 22088
Nov 6 13:42:52 kernel: UBIFS (ubi2:0): UBIFS: mounted UBI device 2, volume 0, name "nvram"
Nov 6 13:42:52 kernel: UBIFS (ubi2:0): LEB size: 126976 bytes (124 KiB), min./max. I/O unit sizes: 2048 bytes/2048 bytes
Nov 6 13:42:52 kernel: UBIFS (ubi2:0): FS size: 5840896 bytes (5 MiB, 46 LEBs), journal size 1396736 bytes (1 MiB, 11 LEBs)
Nov 6 13:42:52 kernel: UBIFS (ubi2:0): reserved for root: 0 bytes (0 KiB)
Nov 6 13:42:52 kernel: UBIFS (ubi2:0): media format: w4/r0 (latest is w4/r0), UUID 4B2A44DD-417E-46D8-97CE-24D278768884, small LPT model
Nov 6 13:42:52 kernel: UBIFS (ubi2:0): un-mount UBI device 2
Nov 6 13:42:52 kernel: UBIFS (ubi2:0): background thread "ubifs_bgt2_0" stops
Nov 6 13:42:52 kernel: ubi2: detaching mtd10
Nov 6 13:42:52 kernel: ubi2: mtd10 is detached
Nov 6 13:42:52 get_ext_phy_id: 0/1/0/0
Nov 6 13:42:52 kernel: ^[[0;33;41m[ERROR vlan] registerVlanDeviceByName,349: Could not find Real Device eth6^[[0m
Nov 6 13:42:52 kernel: ^[[0;33;41m[ERROR vlan] vlanIoctl ,639: Failed to create VLAN device (eth6, eth6.0)^[[0m
Nov 6 13:42:52 kernel: ^[[0;33;41m[ERROR vlan] registerVlanDeviceByName,349: Could not find Real Device eth6^[[0m
Nov 6 13:42:52 kernel: ^[[0;33;41m[ERROR vlan] vlanIoctl ,639: Failed to create VLAN device (eth6, eth6.501)^[[0m
Nov 6 13:42:52 kernel: ^[[0;33;41m[ERROR vlan] bcmVlan_insertTagRule,2339: Real Device eth6 has no VLAN Interfaces^[[0m
Nov 6 13:42:52 kernel: ^[[0;33;41m[ERROR vlan] vlanIoctl ,771: Failed to Insert Tag Rule in eth6 (tags=0, dir=0)^[[0m
Nov 6 13:42:52 kernel: ^[[0;33;41m[ERROR vlan] bcmVlan_insertTagRule,2339: Real Device eth6 has no VLAN Interfaces^[[0m
Nov 6 13:42:52 kernel: ^[[0;33;41m[ERROR vlan] vlanIoctl ,771: Failed to Insert Tag Rule in eth6 (tags=0, dir=1)^[[0m
Nov 6 13:42:52 kernel: ^[[0;33;41m[ERROR vlan] bcmVlan_insertTagRule,2339: Real Device eth6 has no VLAN Interfaces^[[0m
Nov 6 13:42:52 kernel: ^[[0;33;41m[ERROR vlan] vlanIoctl ,771: Failed to Insert Tag Rule in eth6 (tags=0, dir=1)^[[0m
Nov 6 13:42:52 kernel: ^[[0;33;41m[ERROR vlan] bcmVlan_insertTagRule,2339: Real Device eth6 has no VLAN Interfaces^[[0m
Nov 6 13:42:52 kernel: ^[[0;33;41m[ERROR vlan] vlanIoctl ,771: Failed to Insert Tag Rule in eth6 (tags=1, dir=0)^[[0m
(repeats)
Nov 6 13:43:00 rc_service: watchdog 3229:notify_rc start_amas_lanctrl
Nov 6 13:43:00 rc_service: watchdog 3229:notify_rc start_cfgsync
 
Last edited:
Same issue, 2022 RT-AX86U, and I never used AiCloud

Unfortunately, the most affected RT-AX86U/S models still don't have firmware update. Perhaps taking them temporarily off-line is not the worst idea. Damaged router with no AiCloud enabled is concerning. My own RT-AX86U is off-line, I would like to play with it some more after the storm.
 
@Tilo There are similar failures to yours that aren't caused by this malignant code. I really don't believe your problem is related to the topic of this thread.
 
Unfortunately, the most affected RT-AX86U/S models still don't have firmware update. Perhaps taking them temporarily off-line is not the worst idea. Damaged router with no AiCloud enabled is concerning. My own RT-AX86U is off-line, I would like to play with it some more after the storm.
My RT-AX86U Pro was driving me nuts with this problem. After several factory resets and manual reconfigurations, with WAN access turned off, it just kept coming back. Turned out it was the remote access that I need in order to use WOL remotely. Everything else in AiCloud was turned off. I made sure AiCloud was completely disabled, and the problem hasn't returned. I ended up turning on Instant Guard VPN, set it to only allow internet access (no LAN access), and now I can use the Asus Router app to trigger WOL after connecting with Instant Guard. I should have set it up this way to start with. I will not be using AiCloud for anything moving forward, even after they patch it.
 
Turned out it was the remote access

Web Access from WAN is something regularly targeted on Asus routers and general advice is to keep it disabled. Unfortunately, Asus App enables it automatically when remote access is allowed. Most users don't know this remote access is made so simple and not through VPN tunnel.
 
Very interesting indeed. This is the MIPS router from 2012:

View attachment 62287

I personally never expected to see a new firmware for this long time EoL product, but shows level of care. 👍
that is why I like Asus , my RT-12 WAS SUPPORTED FOR YEARS LOST COUNT ON HOW LONG SEEMS LIKE IT WAS SUPPORTED FOR 10 YEARS OR MORE
 
if your radio modules do not work, this is a hack
you can restore the work, for this you need to restore the factory settings of the device
 
Web Access from WAN is something regularly targeted on Asus routers and general advice is to keep it disabled. Unfortunately, Asus App enables it automatically when remote access is allowed. Most users don't know this remote access is made so simple and not through VPN tunnel.
Yeah, it's a shame because the Instant Guard setup is basically as simple as turning it on. I'd never even paid any attention to it. I was going to set up a regular IPsec VPN and just decided to give it a try. Its actually pretty slick. Why wouldn't ASUS just use that for basic remote access by default? I guess they figure you'll want to try the other AiCloud stuff if it's enabled anyway.
 
This malware issue killing Asus routers has to be described in a sticky thread with a warning sign!

Nice call at the end of the day - I remember something over on HackerNews mentioning a new malware that used the Mirai network as a platform for other CPU archs - so for Asus, it's both MIPS and ARM...

Just note that the current Malware isn't Asus specific - it's multi-arch, including the MIPS, ARM platforms, it's also going after PPC and Quantenna ARC ISA's - it's pretty clever, and one the the first to be persistent for some platforms...

what's interesting is that most routers do not need to enable dropbear for SSH/Telnet, and more importantly, do not launch the busybox ash shell (the one built into busybox) - the code will run just fine without it...
 

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top