The PolarEdge backdoor is a significant evolution in IoT malware, characterized by its sophisticated communication methods and persistent threat to network infrastructure. Initially observed in January 2025, the attack chain begins with the exploitation of CVE-2023-20118, a remote code execution vulnerability in Cisco routers. Attackers use this flaw to deploy a web shell, which then executes a script to download and install the PolarEdge payload via FTP.
PolarEdge's advanced design is evident in its use of a custom TLS implementation and a proprietary binary protocol for C2 communications, complicating detection and analysis. The malware exhibits remarkable versatility, with variants specifically designed for Asus, QNAP, and Synology devices. The coordinated nature of the campaign, originating from multiple international IP addresses while using consistent attack fingerprints, points to a well-resourced and persistent threat actor aiming for long-term access.
Figure (1): File Information
When executed without arguments, the PolarEdge backdoor enters its default server mode. In this state, it performs the following actions:
Figure (2): Command server
The PolarEdge backdoor stores its configuration in a structured, encrypted format within the final 512 bytes of the binary. The configuration is decrypted at runtime using a single-byte XOR cipher with the key 0x11 and is segmented into three distinct parts, each identified by a unique marker.
Figure (3): PolarEdge Backdoor configuration
Figure (4): Configuration details
PolarEdge is its custom TLS server implementation, which leverages the mbedTLS v2.8.0 library. This methodology represents a departure from conventional malware communication techniques, establishing encrypted channels that closely mimic legitimate network traffic. The TLS implementation employs multiple certificates—including leaf certificates and certificate authority chains—to create a convincing encrypted communication infrastructure.
The malware executes a proprietary binary protocol over TLS connections that relies on hardcoded tokens embedded within the executable's data sections. This protocol mandates specific magic values for request validation, utilizing tokens stored in the malware's configuration alongside others hardcoded within the binary. Command execution is initiated when incoming requests contain the ASCII character '1' in the HasCommand field, succeeded by a two-byte length indicator and the actual command string.
In the backdoor's main operating mode, fingerprinting operates within a dedicated thread that executes daily. This thread performs the following sequence:
The process begins with configuration parsing, as illustrated in Figure 5. The function scans the trailing configuration block for the magic bytes b"\x21\x12\x01\x47\x51\x13\x81\x15" (labeled MAGIC_3) that mark the C2 section. It then decrypts the C2 address using xor_0x11 and reconstructs the URL for fingerprint transmission.
The fingerprint collects the following host data:
The backdoor constructs the HTTP GET query string using this encrypted, hardcoded format-string. The backdoor also reads /proc/uptime to obtain the device's uptime, though this value is not incorporated into the fingerprint.
Figure (5): Fingerprinting process
Finally, the function calls set_ssl_client to send the GET request to the C2. If the server responds with a payload, it is written to /tmp/.qnax.sh. Before exiting, the thread checks for the presence of /tmp/.qnax.sh and, if found, executes it.
Figure (6): Execution of /tmp/.qnax.sh
Beyond the one-byte XOR applied to configuration data, the backdoor utilizes two straightforward rotation ciphers to obfuscate section names. strings are decrypted during startup to restore the names of the .init_rodata and .init_text sections in memory:
More significantly, the sample implements the PRESENT block cipher (published in 2007) to decrypt these two sections at runtime. PRESENT operates as a 64-bit block cipher with an 80-bit key (though 128-bit is also supported by the specification). Its key schedule generates 32 round keys, each 80 bits (later truncated to 64 bits), and the core algorithm executes 31 rounds consisting of:
A final 32nd round key is reserved exclusively for key whitening outside the primary rounds. Since the specification addresses only single-block encryption, PolarEdge's authors chain multiple blocks by utilizing the full, untruncated output of the key schedule as the subsequent block's key.
The hardcoded key used in the sample is: 01 00 02 00 00 00 00 00 00 00
In analysis:
A third encryption algorithm combines Base64 encoding with an affine cipher over ASCII letters: y = (9x + 15) mod 26
This algorithm applies a per-character affine cipher to ASCII letters while preserving case and leaves all non-alphabetic bytes unchanged. The encrypted string:
Figure (7): Encrypted string
Figure (8): Decrypted string
PolarEdge Backdoor supports two auxiliary operational modes: connect-back mode and debug mode.
In connect-back mode, the backdoor operates as a TLS client to retrieve files from remote servers. This mode requires the following command-line arguments:
Figure (9): Request in connect-back mode
Using these parameters, the malware constructs and issues an HTTP GET request over TLS, writing the server's response body to the specified local file.
When executed with the options -m d -d <encrypted_base64_value>, the backdoor enters a special mode dedicated to updating its C2 address configuration. This functionality proved particularly useful during analysis by enabling redirection of fingerprint requests to be controlled servers, hence the "debug mode" designation.
In this mode, the backdoor first verifies the existence of the filter file /tmp/GLyzaagK. If present, it:
To redirect communications to 127.0.0.1:58425, an operator would execute:
Figure (10): Debug mode command
| Tactic (TA) | Technique | MITRE ID |
|---|---|---|
| Execution (TA0002) | Scripting | T1064 |
| Defense Evasion (TA0005) | Obfuscated Files or Information | T1027 |
| Defense Evasion (TA0005) | Scripting | T1064 |
| Defense Evasion (TA0005) | Indicator Removal | T1070 |
| Defense Evasion (TA0005) | File Deletion (sub-technique) | T1070.004 |
| Defense Evasion (TA0005) | Deobfuscate/Decode Files or Information | T1140 |
| Defense Evasion (TA0005) | File and Directory Permissions Modification | T1222 |
| Defense Evasion (TA0005) | Hide Artifacts | T1564 |
| Defense Evasion (TA0005) | Hidden Files and Directories (sub-technique) | T1564.001 |
| Discovery (TA0007) | Remote System Discovery | T1018 |
| Discovery (TA0007) | File and Directory Discovery | T1083 |
| Discovery (TA0007) | Software Discovery | T1518 |
| Discovery (TA0007) | Security Software Discovery (sub-technique) | T1518.001 |
| Command and Control (TA0011) | Application Layer Protocol | T1071 |
| Command and Control (TA0011) | Non-Standard Port | T1571 |
The reverse-engineering analysis of the PolarEdge Backdoor reveals a sophisticated implant centered around a custom TLS server implementation and an unauthenticated binary protocol for remote command execution. The malware employs multiple layers of obfuscation, storing its configuration within the final 512 bytes of the ELF image protected by one-byte XOR encryption, while critical .init_rodata and .init_text sections are decrypted at runtime using a chained PRESENT block cipher.
The implant incorporates several anti-analysis techniques including randomized process names, /proc filesystem remounting, and watchdog forking mechanisms to maintain persistence and evade detection. Additionally, PolarEdge supports auxiliary operational modes—connect-back for file retrieval and debug for dynamic C2 server updates—providing flexibility for operator control and maintenance.
This combination of advanced cryptographic techniques, stealth mechanisms, and modular functionality positions PolarEdge as a capable and persistent threat to compromised systems.