UPDATE 9/24/2025: Clarifications on Our PolarEdge Research
We were recently informed by a community member that the certificate highlighted in earlier versions of this research is also present in older versions of Mbed TLS, version 3.4.0, previously known as PolarSSL. Additionally, the TLS certificate we had associated with the “PolarEdge” malware also originates from the same Mbed TLS repository. This new context reduces the confidence of the evidence linking the exposure footprint or the RPX server we analyzed directly to PolarEdge.
While our follow-up investigation was derived from examining the historical data of a host known to have distributed the PolarEdge payload, it is now believed the actor is leveraging known certificates as a means of reducing unique attributes. Based on this, we believe the RPX server discussed in the blog was most likely either running on the attacker’s infrastructure or functioning as a relay server.
To ensure our reporting reflects this correction:
- We have removed the original research content (still available at the following archive links for transparency: “2025 State of the Internet: Digging into Residential Proxy Infrastructure” and “Pondering my ORB – A look at PolarEdge Adjacent Infrastructure”).
- The post below reflects the most updated and verified analysis of the infrastructure analyzed
- Our threat intelligence dataset has been updated accordingly
Transparency, reproducibility and accuracy are central to our research, and we will continue to clearly acknowledge situations like this in order to provide our community with the most reliable information possible.
Executive Summary
- In early 2025, Sekoia’s researchers discovered PolarEdge, a rapidly expanding IoT botnet that exploited the vulnerability CVE-2023-20118. In their research, they uncovered a swath of interesting leads using Censys
- We explore several services and certificates that frequently accompany the device types allegedly targeted by PolarEdge.
- Following a specific pivot, we uncovered a connect-back proxy management system that was detected running on a host associated with the PolarEdge compromises back in 2024, and is currently running on over 2,400 hosts.
- This system appears to be a well-designed server that may be one of the many tools used for managing the PolarEdge botnet.
Residential Proxies and ORBs: The Bigger Picture
Beneath the hum of everyday Internet traffic, millions of home and small business devices quietly pull double duty, functioning for their legitimate owners while also – either knowingly or unknowingly – relaying traffic for entirely separate purposes. These devices form the backbone of residential proxy networks, which route traffic through ordinary consumer equipment.
Not all residential proxies are malicious. Some operate with the full knowledge and consent of their owners – for example, those who rent out their home router’s IP address to a commercial proxy service. Owners are often unaware of exactly how their IP will be used, but have willingly placed it in a pool that could serve both benign and questionable purposes.
However, other devices are leveraged without consent. In the cybercrime ecosystem, threat actors commonly compromise routers, smart speakers, and other IoT devices to create residential proxy networks that hide malicious activity behind trusted, geographically diverse IP addresses. This makes them far more difficult to detect or block than data center proxies and gives attackers a layer of anonymity.
A particularly stealthy type of malicious proxies are Operation Relay Boxes (ORBs). ORBs are compromised exit nodes that forward traffic in order to carry out additional compromises or attacks on behalf of threat actors. What makes ORBs so valuable to attackers is that they don’t need to take over the device’s core function — they can quietly relay traffic in the background while the device continues to operate normally, making detection by the owner or ISP unlikely.
All ORBs are a type of malicious residential proxy node, but not all malicious residential proxies are ORBs. The key distinction is that ORBs are compromised devices used as exit nodes without the owner’s consent, compared to devices where the proxy function was enabled willingly. Whether the owner consents to the access or not, the end result can be the same: a trusted residential IP becomes a participant in someone else’s malicious operations.
In this post, we’ll examine “PolarEdge,” a suspected ORB network first reported on by Sekoia researchers that resurfaced with new tactics earlier this year.
What is PolarEdge?
In February 2025, Sekoia researchers reported on “PolarEdge,” an IoT botnet that has been active since at least late 2023. Initially, it followed a familiar playbook, exploiting a critical Cisco Small Business router vulnerability (CVE-2023-20118) to implant base64-encoded webshells.
By early 2025, however, PolarEdge shifted toward persistent compromise of a broader range of edge devices, including other routers and NAS units, using a custom TLS backdoor based on Mbed TLS (formerly PolarSSL). The backdoor enables encrypted command-and-control, log cleaning, and dynamic infrastructure updates.
PolarEdge stands out in the crowded IoT malware landscape as a potential candidate for an Operational Relay Box (ORB) network. While definitively classifying a network of nodes as an ORB network is challenging, several factors point in that direction: deliberate targeting of IoT devices within telecommunications and ISP infrastructure, long-lived persistence on compromised hosts, a technically sophisticated encrypted backdoor, a globally distributed footprint across multiple countries and networks, and consistent infrastructure churn.
Pivoting on a C2 Server
When we first began exploring PolarEdge, inspired by the original Sekoia analysis, our investigation initially centered on what was already known. Currently, Sekoia has identified several hosts that were clearly involved in the operation; however, a large set of unknown entities remains.
For example, we know the host 119.8.186[.]227 was used to distribute payloads via FTP to compromised devices.
“The attacker used the IP address 119.8.186[.]227 to distribute these payloads via FTP. This address is located in Singapore and belongs to Huawei Cloud (ASN: 136907). Based on a Censys search, several non-standard TCP ports are open, exposing TLS services associated with either suspicious certificates or those linked to Polar.” – Sekoia
By using our historical scan data, we can look at this attacker’s host on February 11, 2025 (around the time that Sekoia first observed attacker activity), and observe multiple services and certificates in use (some of which are still running on that host today):
This certificate (3f00058448b8f7e9a296d0cdf6567ceb23895345eae39d472350a27b24efe999) was running on an HTTP service and appeared to be associated with the domain “www[.]learningrtc[.]cn”. At face value, nothing about it was overtly suspicious, just a little odd. We decided to investigate what exactly this domain represented.
After some general internet searches led us to a handful of Chinese blog posts, all pointing to an e-book about WebRTC development, we finally uncovered a GitHub repository containing a certificate named “1557605_www.learningrtc.cn.pem”. After downloading the bundle, we extracted the SHA-256 fingerprint and confirmed it matched exactly with the certificate observed on the attacker’s host.
% openssl x509 -in wtf.pem -noout -fingerprint -sha256
sha256 Fingerprint=3F:00:05:84:48:B8:F7:E9:A2:96:D0:CD:F6:56:7C:EB:23:89:53:45:EA:E3:9D:47:23:50:A2:7B:24:EF:E9:99On its own, this was a meaningless coincidence; an e-book’s test certificate was reused on some attacker infrastructure. But when we began looking beyond this specific host, a pattern began to emerge. Over the past few years, the same certificate has been observed across numerous hosts, and many of those same hosts have also exposed suspicious-looking certificates with a “PolarSSL” subject and issuer on seemingly random high ports.
So, we once again examined the original attacker’s host (119.8.186[.]227) and noticed that it was also serving the same strange PolarSSL certificate on two ports: TCP/50000 and TCP/55555.
This led us to wonder: Were all of these certificates at one point entirely legitimate, only to be later co-opted for malicious use? And more importantly, what was the relationship (if any) between the benign-looking WebRTC e-book certificate and the more suspicious “PolarSSL” ones? So, we went in search of the origins of the PolarSSL certificate.
Unfortunately, our initial attempts to determine the origin of this certificate were unproductive. Unlike the WebRTC example, we found no code repositories, blog references, or documentation that explained its purpose. At first glance, examining its use across the broader internet (and over time) suggested a very strong overlap with the known PolarEdge botnet certificate.
But, we have since been notified that this certificate (and the original PolarEdge certificate) is, in fact, present in older versions of Mbed TLS, and can be found in the project’s public test data repository. This discovery means that the overlap we observed does not, by itself, constitute evidence of a direct PolarEdge connection.
% curl -s 'https://raw.githubusercontent.com/Mbed-TLS/mbedtls/refs/tags/v3.4.0/tests/data_files/server5.crt' |
openssl x509 -inform PEM -noout -fingerprint -sha256 |
sed 's/://g'
sha256 Fingerprint=E234E102CD8DE90E258906D253157AEB7699A3C6DF0C4E79E05D01801999DCB5
As part of this research, we pivoted on infrastructure that exposed multiple certificates simultaneously, looking for any outliers that might tie the threads together in some way. One host in particular stood out, 190.92.202[.]218, which was online back in October of 2024. This host presented not only the WebRTC certificate and several others referenced in the original Sekoia blog,
We shifted our focus to hosts currently serving these certificates. There were plenty of them, but one host immediately stood out. 8.219.153.173, located within the Alibaba Cloud ASN, one host exposed all of the certificates we had been tracking, and, more importantly, it also had an open directory on a very high port (HTTP/10000) with some extremely interesting filenames:
At the time, we didn’t realize it, but this open directory would prove to be the catalytic goldmine that brought the broader picture into sharper focus. The contents included gigabytes of logs, numerous administrative scripts, and a collection of binaries (some were immediately recognizable as open-source projects, such as Go-Shadowsocks2 and the aforementioned Go-Admin-Team server).
Within this directory were several configuration files, including one interesting one: config/clash.yaml, a configuration file for the Clash Proxy service. Buried inside was a single upstream SOCKS5 server pointing to 159.138.83.57:55556. An interesting fact about this configuration was that the username for the proxy was a UUID (which will become important in the next section). While that specific port appears to be down today, the same host currently exposes other ports, presenting some very familiar certificates (below)
More “PolarSSL” test certificates! It is also running that strange WebRTC certificate on port 19999. What the heck is going on?
Yet the real cool stuff came from one file in the directory that we couldn’t immediately tie to any public project: a single x86-64 ELF binary which has never even been seen in VirusTotal. But, lucky for us, it was compiled with debug symbols intact, which made the analysis effort significantly easier. What we uncovered inside turned out to be far more intriguing than we expected. It looked to be an ORB (operational relay box) management system.
The RPX Server
In this section, we will review the binary named “server_multi” (SHA256 Hash: 827797a9bff728ae6f46abd505e67a15e40b0ba69a8dc92a36fd90d9974c9593) and its function and purpose. We are calling it “RPX” due to the multiple debug log statements that include the source code path “/rpx/”. At its core, the RPX server operates as a reverse-connect proxy gateway. First, let’s talk about the terminology that will be used in the following sections.
Note: The only mention of an RPX project on the internet that we were able to find was a project called RPX, intended for local development proxying, written in a completely different language (TypeScript), and seemingly unrelated to the RPX discussed here.
Terminology
- RPX Server: A command-and-control-like service responsible for managing proxy nodes and exposing proxy services.
- Proxy Nodes: Hosts on the internet that establish reverse connections to the RPX server. Once registered, they are transparently used by clients via the RPX server.
- Proxy Services: SOCKS5 (plaintext and TLS) and Trojan-protocol services provided by the RPX server. These services are internally bridged to proxy nodes once the client has successfully authenticated.
- Go-Admin: A local service that communicates with the RPX server over a local Unix socket. It functions as an administrative control layer for validating sessions and managing proxy node registration.
Technical Analysis
Clients connect over plaintext TCP or TLS, performing either a SOCKS5 or Trojan-style handshake with the server. Unlike a traditional proxy, the RPX server does not establish a direct connection to the destination being requested. Instead, it:
- Selects a proxy node from its pool of registered reverse-connected nodes.
- Instructs the proxy node to initiate a connection to the requested target.
- Allocates an ephemeral port on the RPX server and awaits the proxy node’s reverse connection.
- Splices the connection so that traffic between the client and proxy node (either TCP or UDP) is transparently bridged through this new endpoint.
When a proxy node comes online, it connects to the RPX server over TLS and attempts a rudimentary handshake that includes the server’s UUID and a version identifier. Once this has been successfully parsed, it will send the “hello” exchange over to the go-admin server for validation.
If the go-admin server replies that this proxy node is authorized to join, the server will send back a hello response, and then submit a job to the server’s global job queue with a job type of 0x15.
This 0x15 job is handled in another thread called “JobThread”, and when it receives this specific job type, it will take the connected proxy node client, and add it to a global list of connected proxy nodes in a global array called “global_proxies” via the function “insert_available_proxy “
The RPX server exposes three proxy protocols: plaintext SOCKS5, TLS-wrapped SOCKS5, and Trojan; each of these is bound to its own port in a predictable sequence. When it starts, only one base port is configured. The plaintext SOCKS5 service listens on that base port, the TLS-wrapped SOCKS5 service listens on the base port plus one, and the Trojan service listens on the base port plus two. For example, if the configured port is 1111, then plaintext SOCKS5 will be available on port 1111, TLS-SOCKS5 on port 1112, and Trojan on port 1113.
While the handshake details differ slightly between these protocols, they ultimately follow the same general workflow:
- Client authentication: the proxy client connects and completes the protocol handshake (and requests a host to proxy to). The username/password of the client appears to be a means of indicating to the server which specific proxy (or set of proxies) they are interested in utilizing.
- Ephemeral port allocation – the RPX server selects a random port and begins listening on it.
- Proxy node selection – the RPX server selects an available proxy node from the global pool of connected proxy nodes.
- Reverse connection request – RPX then instructs the selected proxy node to dial back into the server on the newly allocated port.
- Bi-directional traffic establishment – Once the proxy node connects to the new port, it establishes a bidirectional channel, relaying client and proxy node traffic transparently to the requested destination.
Client authentication is done via a simple function called “verify”. The username is in the form of a UUID that can be mapped to a specific proxy the client wishes to use; we see this in action with the “clash.yaml” configuration file from the last section. The “verify” function calls “get_proxy_by_uuid” which attempts to find the proxy node registered with that uuid. The password seems to be a statically defined one set in the configuration file (“global_password”).
The reverse connection request is processed through the global job queue and handled by the JobThread using a job ID of 0x11. The following screenshot is a commented disassembly of the port allocation process and the setup of a job message sent to the JobThread.
Once the “JobThread” successfully selects a proxy node and passes along the connection information to the proxy node, the handler accepts a single client connection on the new listener. It then calls the function “is_forbit“, which checks the supplied client password against a list of banned values; if a match is found, the connection is immediately dropped. If no match is found, the handler proceeds based on the negotiated protocol: for UDP connections, it calls reverse_proxy_relay_udp, and for all others, it uses reverse_proxy_relay_tcp. Both of these relay functions establish the bidirectional channel that links the proxy client with the proxy node’s reverse connection to the RPX server. The following screenshot highlights this functionality.
It should be noted that traffic is not relayed as-is. Instead, the data is further obfuscated by either XOR or DES encryption.
In the UDP relay, we see a call to init_custom_key_tool, which sets up an Mbed TLS DES context using the static key “4 xbs.1x” for both encryption and decryption. Whenever inbound data needs to be decrypted, the relay uses read_custom_key_tool, and when outbound data must be encrypted, it invokes write_custom_key_tool.
However, in the TCP relay, even though the DES context is initialized, it doesn’t seem to use it; instead, it opts for a simple XOR shuffle using the one-byte key 0x11.
The xor_write calls another function called my_xor, which simply xor’s the incoming bytes with the key:
00406920 int64_t my_xor(char* buf, int n)
00406960 int32_t i
00406960
00406960 for (i = 0; i s< n; i += 1)
00406954 buf[sx.q(i)] ^= 0x11
00406954
00406963 return iThe TLS Trojan and SOCKS5 service are both processed by the same function using different arguments (the “label” argument in the screenshot below tells the function whether to handle the socket as Trojan or SOCKS) within their own respective threads initialized by a helper function called simple_tls_server:
This helper function creates and initializes the TLS context with a hardcoded private key named mbedtls_test_srv_key, and its public certificate mbedtls_test_srv_crt:
We can dump the contents of this data and pipe it to openssl to get the certificate information:
Here, we can see that the SHA-256 fingerprint for this embedded certificate is “e234e102…”. This certificate has been observed on more than 2,400 hosts across the internet, which initially suggested it might serve as a strong indicator of PolarEdge association. We now know it originates from older versions of Mbed TLS, meaning its presence alone cannot establish attribution. However, in this case, the certificate is used on a service found on a host attributed to PolarEdge back in 2024.
There is another thread that is started on the server called “PrintThread” which seems to log various stats, including how many proxy nodes are currently connected every five seconds:
Since we were also able to retrieve a number of log files from this specific open directory, we can see how many proxy nodes were connected to that server at any given time by grepping for the string “online nodes”. At its peak, in Aug of 2025, there were over 100 proxy nodes connected and active. So this is still a very active service.
2025-06-20 20:54:38 /root/project/rpx/server.c:1890 online nodes: 101,heart beat 60
2025-06-20 20:54:43 /root/project/rpx/server.c:1890 online nodes: 101,heart beat 60
2025-06-20 20:54:48 /root/project/rpx/server.c:1890 online nodes: 101,heart beat 60
2025-06-20 20:54:58 /root/project/rpx/server.c:1890 online nodes: 101,heart beat 60Client authentication is handled by a function named “verify,” and the username may be directly tied to what proxy nodes are chosen, and the password is checked against a single globally defined password. As shown in the screenshot below, the first four bytes of the “uuid” variable correspond to the socket file descriptor of the connect proxy node. And if any of these tests fail, the connection is terminated.
Conclusions
This ongoing investigation demonstrates how seemingly benign artifacts (such as a consistently reused test certificate from an e-book or open-source project) can unravel into larger findings. While we were unable to find a direct relationship between the RPX system and the PolarEdge botnet (we are, at the end of the day, just a port scanner), the overlap in certificates, services, and patterns is very hard to ignore.
Admittedly, the discovery of an open directory on a host presenting some of these suspicious certificates was a stroke of luck, but the insight into RPX provides a rare glimpse into the tools and infrastructure that may lie behind a large-scale IoT botnet, which we might not have had otherwise if not for scanning. It is also possible that this specific service is completely unrelated to PolarEdge and is instead a service that the botnet operators utilize to jump between different relays.
We will continue refining our scanning techniques to better fingerprint and interact with these services, and we hope to gain even further clarity in the future.
Mentioned IOCs
Hosts
- 119.8.186[.]227
- 190.92.202[.]218
- 159.138.83[.]57
Certificates / Hashes
- 3f00058448b8f7e9a296d0cdf6567ceb23895345eae39d472350a27b24efe999
- e234e102cd8de90e258906d253157aeb7699a3c6df0c4e79e05d01801999dcb5
Binaries
- server_multi: 827797a9bff728ae6f46abd505e67a15e40b0ba69a8dc92a36fd90d9974c9593
References
- https://blog.sekoia.io/polaredge-unveiling-an-uncovered-iot-botnet/
- https://cloud.google.com/blog/topics/threat-intelligence/china-nexus-espionage-orb-networks
- https://securityscorecard.com/wp-content/uploads/2025/06/LapDogs-STRIKE-Report-June-2025.pdf
