Sekoia Threat Detection & Response (TDR) researchers have published an in-depth technical analysis of the PolarEdge Backdoor, a stealthy implant deployed through exploitation of CVE-2023-20118, a remote code execution affecting Cisco routers. The discovery follows the firm’s earlier revelation of the PolarEdge botnet, first detected in January 2025, now shown to have spread beyond Cisco to Asus, QNAP, and Synology devices.
The second wave of attacks began on February 10, 2025, when Sekoia’s honeypots detected simultaneous exploitation attempts using a distinctive User-Agent string mimicking Google Chrome on macOS. The attackers executed a shell script, q, which in turn downloaded and launched the PolarEdge backdoor.
Sekoia’s deeper analysis identified that “q downloads and launches the PolarEdge backdoor on the compromised system.”
The analyzed sample—an ELF 64-bit executable targeting QNAP NAS devices—was 1.6 MB in size, statically linked, and stripped of debugging symbols, showing clear intent to resist analysis.
The implant functions as a custom TLS server, implemented using mbedTLS v2.8.0, and is capable of receiving commands and executing them directly on the infected host. Sekoia notes that “The backdoor’s primary function is to send a host fingerprint to its command-and-control server and then listen for commands over a built-in TLS server implemented with mbedTLS.”
When executed without arguments, the backdoor operates in its default server mode, which “launches a TLS server to listen for incoming commands and spawns a dedicated thread that sends a daily host fingerprint to the C2.”
Interestingly, the malware also performs filesystem manipulation upon startup. Sekoia explains: “At startup, the backdoor moves and deletes certain files on the device… we think that’s to prevent other threat actors from accessing the systems with the same .”
These file operations target utilities such as /usr/bin/wget and /sbin/curl, renaming or removing them to block competing malware from exploiting the same device.
The PolarEdge Backdoor stores its configuration data within the final 512 bytes of the binary, obfuscated using a one-byte XOR (0x11). The configuration contains three key sections — a “filter file,” TLS parameters, and C2 server list.
Sekoia details: “The configuration is separated into three parts, each part identified by a marker and separated by 8 null bytes. The content is then decrypted using a simple XOR with the single-byte key 0x11.”
The TLS certificates embedded in the binary include a chain of self-signed PolarSSL test certificates, providing both RSA and ECDSA cryptographic options. The main certificate’s subject and issuer fields identify the actor’s self-signed infrastructure:
“Subject: C=NL, O=PolarSSL, CN=localhost; Issuer: C=NL, O=PolarSSL, CN=PolarSSL Test CA.”
Unlike typical IoT malware using HTTP or MQTT, the backdoor communicates through a custom binary protocol over TLS, validated by a series of “magic tokens.”
Sekoia writes: “Parsing an incoming request involves verifying fixed magic tokens and checking that one of them matches the value stored in the backdoor’s configuration. The response carries only the raw output of the executed command, with no additional framing or authentication.”
This lack of authentication means “anyone with read access to the installed binary can extract these magic values and issue arbitrary commands.”
Every 24 hours, the backdoor initiates a fingerprinting routine, collecting system metadata and transmitting it to its command-and-control server.
Sekoia’s report outlines the scope of the data: “The fingerprint includes the following data: local IP addresses, MAC addresses, current process ID, device brand (qnap), module version (QNAP_2), and the path of the filter file.”
The malware constructs an HTTP GET query containing the collected identifiers:
“ip=%s&version=%s&module=%s&cmd=putdata&data=BRAND=qnap,FILTER_FILE=%s,PID=%d,MODULE=%s,MAC=%s.”
If the command-and-control server responds with a payload, it is saved and executed from /tmp/.qnax.sh, giving the attacker remote command execution and persistence capabilities.
The PolarEdge Backdoor employs multiple encryption layers, from simple XOR obfuscation to the PRESENT block cipher for decrypting internal code sections at runtime.
The malware also uses an affine cipher layered with Base64 encoding for certain strings, alongside rotation-based ciphers for obfuscating ELF section names.
To evade detection, the malware uses process name randomization, masquerading as common system daemons such as igmpproxy, dhcpd, or upnpd.
Sekoia notes: “It also hides its internals by attempting to mount over its own /proc/<pid> directory, binding /proc/11 or /proc/1 onto it.”
While the backdoor does not maintain persistence after reboot, it spawns a child watchdog process that “every 30 seconds checks whether /proc/<parent-pid> still exists. If the directory has disappeared, the child executes a shell command to relaunch the backdoor.”
Beyond its default server behavior, the malware supports connect-back and debug modes — giving attackers flexibility in command-and-control operations.
In connect-back mode, “the backdoor acts as a TLS client to download a file from a remote server… constructs and issues an HTTP GET request over TLS and writes the response body to the specified local file.”
In debug mode, the operator can update the C2 server dynamically by using a Base64-encoded parameter. Sekoia explains: “When executed with the options -m d -d <encrypted and base64 value>, the backdoor enters in a special mode that updates only its C2 address.”
