{
	"id": "5bc596e3-687f-40cf-808e-9c551efc625b",
	"created_at": "2026-04-06T00:11:47.587802Z",
	"updated_at": "2026-04-10T03:32:46.248968Z",
	"deleted_at": null,
	"sha1_hash": "be48fcbf0bb242bfc07005c81fc85259d76aa711",
	"title": "PolarEdge: Unveiling an uncovered ORB network",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1226540,
	"plain_text": "PolarEdge: Unveiling an uncovered ORB network\r\nBy Jeremy Scion,\u0026nbsp;Felix Aimé\u0026nbsp;and\u0026nbsp;Sekoia TDR\r\nPublished: 2025-02-25 · Archived: 2026-04-05 20:22:51 UTC\r\nThis article on was originally distributed as a private FLINT report to our customers on 19 February 2025.\r\nTable of contents\r\nIntroduction\r\nVulnerability overview\r\nHoneypot observation\r\nCase 1 : webshell\r\nCase : backdoor TLS\r\nPayloads analysis\r\nPolarEdge – an advanced TLS Backdoor\r\nFirewall Configuration\r\nTLS Backdoor\r\nC2-Reporting\r\nAdditional devices targeted by PolarEdge botnet\r\nAsus payload\r\nQNAP payload\r\nSynology payload\r\nInfrastructure\r\nDelivery\r\nReport server\r\nAsus link\r\nSynology link\r\nQNAP link\r\nIllumination of compromised assets\r\nConclusion\r\nIoCs\r\nIntroduction\r\nThe monitoring and analysis of vulnerability exploitations are among the primary responsibilities of Sekoia’s\r\nThreat Detection \u0026 Research (TDR) team. Using our honeypots, we monitor traffic targeting various edge devices\r\nand internet-facing applications.\r\nOn 22 January 2025, suspicious network traces were observed via our honeypots. Analysis indicated an attempt to\r\nexploit the CVE-2023-20118 vulnerability. Through this exploit, the attacker executed a remote command (RCE)\r\nhttps://blog.sekoia.io/polaredge-unveiling-an-uncovered-iot-botnet/\r\nPage 1 of 13\n\nto deploy a webshell on the target router. From 22 to 31 January, several similar attempts were recorded.\r\nOn 10 February 2025, another attempt to exploit this vulnerability was identified. In this instance, the attacker\r\nexecuted a remote command to download and run a script. Ultimately, this attack led to the victim being infected\r\nvia an undocumented implant. Analysis of this implant shows that it is a form of TLS backdoor containing pre-defined commands. The investigation also uncovered other payloads from the same family, but targeting different\r\ndevices, notably Asus, QNAP and Synology. \r\nThe study of these payloads led to the discovery of a botnet comprising over 2,000 infected assets around the\r\nworld, as well as the attacker’s infrastructure. The analysis suggests that this botnet has been active since at least\r\nthe end of 2023. The TDR team named these payloads and the corresponding botnet PolarEdge due to their use\r\nof the Mbed TLS library (previously named PolarSSL), Polar certificates, and their focus on targeting edge\r\ndevices.\r\nThis blog post provides an analysis of the backdoor and the associated botnet. Additionally, it shares insights into\r\nthe adversary’s infrastructure.\r\nVulnerability overview\r\nCVE-2023-20118 is a vulnerability affecting Cisco Small Business Routers RV016, RV042, RV042G, RV082,\r\nRV320, and RV325, specifically within the web-based management interface exposed. This vulnerability is caused\r\nby  improper input validation, which allows an unauthenticated attacker to execute remote commands (RCE) on\r\nthe affected device by sending specially crafted HTTP requests.\r\nThe vulnerability is located in the binaries /cgi-bin/config_mirror.exp , specifically within the delete_cert\r\nfunction. A public proof-of-concept (PoC) demonstrates that the flaw also affects the export_cert function and\r\nis likely present in other functions within these binaries.\r\nIn our honeypot observations, attackers exploit the delete_cert function, which builds and executes an rm\r\ncommand based on user input but lacks proper validation. This flaw allows attackers to inject malicious\r\ncommands using special characters like $(COMMAND) or ; , leading to arbitrary code execution. The vulnerability\r\nstems from the function directly concatenating user input into a system call without verification, making it\r\nsusceptible to command injection through crafted arguments.\r\nHoneypot observation\r\nCase 1 : webshell\r\nBetween 22 and 31 January, an attacker attempted to deploy a webshell by exploiting the vulnerability. The\r\nattacker consistently used the IP address 45.77.152[.]227 . Initially, they checked whether the webshell was\r\nfunctional on the target router by issuing an echo command. If the webshell was not present, they proceeded with\r\nits deployment following a specific process. The attacker set two parameters in the header of their POST HTTP\r\nrequest:\r\nM – containing the base64-encoded webshell, compressed using gzip.\r\nhttps://blog.sekoia.io/polaredge-unveiling-an-uncovered-iot-botnet/\r\nPage 2 of 13\n\nCMD – containing the instructions to be executed by the injected command.\r\nTo achieve persistence, the attacker replaced the router’s authentication CGI script\r\n( /usr/local/EasyAccess/www/cgi-bin/userLogin.cgi ) with their webshell.\r\nThe deployed webshell included an authentication mechanism. A key had to be provided via the PASSHASH\r\nparameter in the request header, alongside the XCMD parameter containing the command to be executed. If the\r\nrequest lacked the PASSHASH parameter or an incorrect key was supplied, the webshell reverted to the standard\r\nauthentication process. However, if the key was correct, the specified command was executed.\r\nUsing their webshell, the attacker attempts to upload a file named tmp[REDACTED].tar.gz into the router’s\r\n/tmp/ directory. Then, they try to extract its contents, which should include a shell script named s.sh , and\r\nexecute it. However, we haven’t been able to retrieve the entire file.\r\nThe webshell’s authentication key was used to scan the internet, revealing only four infected routers. Sekoia\r\nsuspects that the webshell is being used only to deliver a second-stage payload, and then deleted by the attacker.\r\nCase 2 : backdoor TLS\r\nhttps://blog.sekoia.io/polaredge-unveiling-an-uncovered-iot-botnet/\r\nPage 3 of 13\n\nOn 10 February 2025, a different operational pattern was observed. The same exploit commands were sent\r\nsimultaneously from multiple IP addresses. These IPs, originating from different countries, appeared to be\r\nassociated with Edge devices and all requests used the same User-Agent: Mozilla/5.0 (Macintosh; Intel Mac\r\nOS X 10_13_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.85 Safari/537.36 , indicating a\r\ncoordinated attack. This behaviour is indicative of a botnet.\r\nThe attacker exploited the vulnerability to retrieve a script named q via FTP and execute it. The q named shell\r\nscript is designed to download, install, and run a TLS backdoor on the targeted system.\r\nPayloads analysis\r\nIn the TLS backdoor case, the infection starts with the execution of a shell script named q that is designed to\r\ndownload, install, and run a payload on a compromised system. It carries out the following actions:\r\n1. Cleanup \u0026 Self-Destruction\r\nDeletes various log files ( /tmp/httpd.log , /tmp/web.log ) and itself ( rm $0 ).\r\nRemoves /tmp/.lock ). If it exists or the system is not running MIPS64 architecture, it exits.\r\n2. Process Termination \u0026 Locking\r\nCreates a lock file to prevent multiple instances from running.\r\nKills any running instances of suspicious processes like ca , config.exp , process_monitor , and\r\napplication .\r\n3. Downloading a Malicious Payload\r\nUses busybox’s ftpget to download a file ( t.tar ) from 119.8.186[.]227 using hardcoded\r\ncredentials.\r\nIf the downloaded file size is incorrect, it retries after 15 seconds.\r\n4. Execution of Malicious Binary (cipher_log)\r\nAttempts to execute a binary named cipher_log present in the extracted files, ensuring it is copied\r\nto /etc/flash/etc/ .\r\n5. Persistence Mechanism\r\nModifies /etc/flash/etc/cipher.sh to ensure the malware runs in the background, executing\r\ncipher_log repeatedly.\r\nhttps://blog.sekoia.io/polaredge-unveiling-an-uncovered-iot-botnet/\r\nPage 4 of 13\n\nInjects a malicious command into system files like /tmp/splitDB/BONJOUR and\r\n/tmp/splitDB/SYSTEM , ensuring execution on system startup.\r\n6. Execution \u0026 Cleanup\r\nSaves settings (saveSettings), then executes /tmp/cipher_log .\r\nKills the httpd (web server) process.\r\nRemoves the lock file ( /tmp/.lock ) and the malware binary ( /tmp/cipher_log ).\r\nPolarEdge – an advanced TLS Backdoor\r\ncipher_log is an ELF binary compiled for the MIPS64 architecture, with a hash value of\r\neda7cc5e1781c681afe99bf513fcaf5ae86afbf1d84dfd23aa563b1a043cbba8 . Its entry point leads to a function\r\nnamed main, which not only executes various actions to hide the binary’s process but also establishes a TLS\r\nbackdoor.\r\nFirewall configuration\r\nThe iptables_check function uses the iptables utility to adjust the device firewall rules, specifically to allow\r\nconnections to the port used by the TLS backdoor.\r\nTLS Backdoor\r\nThe function command_listen() initialises and sets up an TLS-secured server that listens for incoming client\r\nconnections.\r\n1. TLS Configuration: the function loads TLS certificate ( server.crt ) and private key ( server.key ),\r\ninitialises OpenSSL libraries and creates a TLS context.\r\n2. Socket Creation and Binding: it creates a socket using socket(AF_INET, SOCK_STREAM, 0) . Binds the\r\nsocket to the specified port ( param_1 that seems to be random) and sets the socket to listen for incoming\r\nconnections.\r\n3. Accepting and Handling Clients:\r\nEnters an infinite loop to accept incoming connections.\r\nUpon connection, it establishes a TLS session.\r\nSets socket options and performs an TLS handshake\r\nhttps://blog.sekoia.io/polaredge-unveiling-an-uncovered-iot-botnet/\r\nPage 5 of 13\n\nIf the handshake is successful, the function spawns a child process to manage the client request. Upon\r\nauthentication, it can execute commands using exec_command .\r\nCloses the TLS session and cleans up after handling a client.\r\nThe payload strings reveal multiple public certificates and a private key. Each certificate includes the PolarSSL\r\npattern in either the subject or issuer field. PolarSSL, now known as Mbed TLS, is a C library that provides\r\ncryptographic functions, X.509 certificate handling, and SSL/TLS and DTLS protocols. Its lightweight design\r\nmakes it ideal for embedded systems.\r\nThe certificate associated with the private key has the following characteristics:\r\nIssuer : C=NL;O=PolarSSL,CN=PolarSSL Test CA\r\nSubject : C=NL,O=PolarSSL,CN=localhost\r\nHash : 80cbc316aa58f8be722fd26b3026f077e61c82398599f9f719eade4bcd98173e\r\nC2 Reporting\r\nThe binary informs the C2 server that it has successfully infected a new device by calling the wget_main and\r\nwget_get functions. The C2 server’s hostname and parameters are XOR-encrypted with the hardcoded one byte\r\n0x48 key. Once reconstructed, the payload sends a notification to the following URL:\r\nhxxps://195.123.212[.]54:58425/cCq65x?ip=[DEVICE PUBLIC\r\nIP]\u0026version=1.6\u0026module=CISCO_3\u0026cmd=putdata\u0026data=BRAND=Cisco,MODULE=CISCO_3,PORT=[BINDING PORT],PWD=\r\n[BINARY EXECUTION PATH],MAC=[DEVICE MAC ADDRESS]\r\nThe domain name of this server is also stored in an XOR-encrypted form and corresponds to\r\nhxxps://largeroofs[.]top:58425 The malware transmits this information to the reporting server, enabling the\r\nattacker to determine which device was infected through the IP address/port pairing. The attacker undoubtedly\r\nuses random ports as a tactic to hinder the tracking of their botnet.\r\nAdditional devices targeted by PolarEdge Botnet\r\nA search on VirusTotal using the marking patterns found in cipher_log revealed four new payloads. Based on the\r\nparameters configured in the hardcoded URLs, we can deduce that these payloads target Asus, QNAP and\r\nSynology devices. Notably, these four payloads were submitted on different dates, the earliest on 15 February\r\n2024 and the most recent on 3 February 2025. This indicates that the botnet has been active since at least February\r\n2024.\r\nThe TDR team is still analysing the code of these payloads which do not resemble any known malware. Three out\r\nof four payloads have no detections on VirusTotal and have no similarities to known malware on Intezer.\r\nIt is also interesting to note that all payloads were submitted to VirusTotal by users located in Taiwan. These three\r\ncompanies (Asus, QNAP, and Synology) are based in Taiwan. It is possible that the incident response teams of\r\nthese companies submitted these samples in connection with the exploitation of vulnerabilities.\r\nAsus payload\r\nhttps://blog.sekoia.io/polaredge-unveiling-an-uncovered-iot-botnet/\r\nPage 6 of 13\n\n13cd040a7f488e937b1b234d71a0126b7bc74367bf6538b6961c476f5d620d13 is an ELF binary for the X86_64\r\narchitecture and named sshd_sftp . This sample was submitted to VirusTotal on 15 February 2024. It shares\r\ncommon characteristics with previously analysed payloads but unlike the cipher_log payload, the notification URI\r\nis hardcoded in plain text. The payload communicates with hxxps://asustordownload[.]com:45674 .\r\nQNAP payload\r\n464f29d5f496b4acffc455330f00adb34ab920c66ca1908eee262339d6946bcd is an ELF binary for the X86_64\r\narchitecture and named QTS.install.ssl . This sample was submitted to VirusTotal on 21 February 2024.\r\nSimilar to the Asus payload, it shares many similarities with cipher_log, and in this case as well, the URI is\r\nhardcoded in plain text.\r\nThe payload communicates with hxxps://siotherlentsearsitech[.]shop:58425 . This domain name points to\r\nthe address 195.123.212[.]54 , which is also used by cipher_log .\r\nSynology payload\r\nWe also discovered two payloads targeting Synology. Based on their submission on VirusTotal, they appear to be\r\nmore recent, the oldest being submitted in December 2024. Furthermore, the notification URI is hardcoded,\r\nXORed, and encoded in Base64. It can be assumed that between February 2024 and December 2024, the attacker\r\nevolved the payload, particularly to better conceal this information.\r\n932b2545bd6e3ad74b82ca2199944edecf9c92ad3f75fce0d07e04ab084824d5  is an ELF binary for the X86_64\r\narchitecture and named hdparmd . This sample was submitted to VirusTotal on 30 December 2024. The\r\npayload communicates with  hxxps://122.8.183[.]181:59711  and , we also note the presence of the\r\nurl:  hxxps://ssofhoseuegsgrfnu[.]ru/inet_pton . The domain is now Sinkholed by Sekoia.\r\n121969d72f8e6f09ad93cf17500c479c452e230e27e7b157d5c9336dff15b6ef is an ELF binary for the X86_64\r\narchitecture and named hdparmd . This sample was submitted to VirusTotal on 3 January 2025. The\r\npayload communicates with headached.cc and also with the url:\r\nhxxps://ssofhoseuegsgrfnu[.]ru/inet_pton\r\nInfrastructure\r\nDelivery\r\nThe attacker used the IP address 119.8.186[.]227 to distribute these payloads via FTP. This address is located in\r\nSingapore and belongs to Huawei Cloud (ASN: 136907). Based on a Censys search, several non-standard TCP\r\nports are open, exposing TLS services associated with either suspicious certificates or those linked to Polar.\r\nOn TCP 45065\r\nIssuer: C=JP, ST=nik, L=kom, O=hik, OU=ces, CN=wwie, emailAddress=vviw@gmail.com\r\nSubject: C=JP, ST=nik, L=kom, O=hik, OU=ces, CN=wwie, emailAddress=vviw@gmail.com\r\nHash: a56da1901cf6cabf8e94755bc3bcfacb9b5164df8f241e8774b8865afd4656e9\r\nOn TCP 5000, 54520, 55555, 55557\r\nIssuer: C=NL, O=PolarSSL, CN=Polarssl Test EC CA\r\nhttps://blog.sekoia.io/polaredge-unveiling-an-uncovered-iot-botnet/\r\nPage 7 of 13\n\nSubject: C=NL, O=PolarSSL, CN=localhost\r\nHash: 234e102cd8de90e258906d253157aeb7699a3c6df0c4e79e05d01801999dcb5\r\nOn TCP 53642\r\nIssuer: C=AU, ST=aa, L=ss, O=qw, OU=ew, CN=re, emailAddress=tr@gmail.com\r\nSubject: C=AU, ST=aa, L=ss, O=qw, OU=ew, CN=re, emailAddress=tr@gmail.com\r\nHash: b3f0b226d45eb4af7f24e7a8d9f701b5b29c26326be0a507db171ad2aa1205c7\r\nA passive DNS search on this IP address shows that it is associated with four domains exhibiting strong\r\nsimilarities:\r\nlonglog[.]cc\r\nlandim[.]cc\r\nhitchil[.]cc\r\nlogchim[.]cc\r\nBesides having a .cc TLD, these four domains were registered on 19 July 2024 via Namecheap. Passive DNS\r\nsearches indicate that they have been linked to this IP address since at least 20 August 2024. In addition to the\r\npayloads, access to the FTP service reveals the presence of other files on the server, including scripts named\r\nauto_close.sh , ftpstart.sh , ftpstop.sh , and user .\r\nThese files, all dated 24 July 2024, are used for the operation of the FTP server. The ARM payload, named w , is\r\ndated 20 August 2024, while those used to compromise Cisco routers are dated 10 February 2025. This suggests\r\nthat the attacker has been using this IP address since at least 24 July 2024 and that the four .cc domains belong to\r\nthe attacker\r\nReporting server\r\nThe IP address 195.123.212[.]54 is located in Latvia and belongs to Green Floid LLC (ASN:50979). Once\r\nagain, this server exposes TLS services on high TCP ports with TLS certificates. However, pivoting on these\r\ncertificates does not reveal any additional IP address.\r\nA focus on Green Floid LLC\r\nhttps://blog.sekoia.io/polaredge-unveiling-an-uncovered-iot-botnet/\r\nPage 8 of 13\n\nAccording to the Krebs on Security article titled “Stark Industries Solutions: An Iron Hammer in the Cloud”, Stark\r\nIndustries Solutions and Green Floid LLC are linked through their association with Proxyline, a large proxy\r\nservice based in Russia. Spur.us, a company that monitors VPNs and proxy services worldwide, discovered that\r\nStark Industries hosts at least 74 VPN services and 40 proxy services, including Proxyline.\r\nAn analysis of Proxyline’s infrastructure revealed over a million proxies distributed across multiple providers,\r\nwith the largest concentration hosted by Stark Industries Solutions. Among the providers associated with\r\nProxyline, two appear frequently: ITL LLC, also known as Information Technology Laboratories Group, based in\r\nKharkiv, Ukraine, and Green Floid LLC, a hosting company based in Miami.\r\nGreen Floid had previously been mentioned in a 2017 CNN article, which interviewed its owner regarding the use\r\nof its proxy networks by Russian troll farms to conceal disinformation campaigns linked to the Kremlin’s Internet\r\nResearch Agency (IRA).\r\nThus, Stark Industries Solutions and Green Floid LLC are connected through their mutual relationship with\r\nProxyline and their involvement in proxy activities that may be linked to Russian disinformation campaigns.\r\nA passive DNS search on this IP address reveals link with several domains using the .top TLD:\r\naipricadd[.]top – registered on 13 March 2024 via Namesilo\r\nfirebasesafer[.]top – registered on 19 March 2024 via Namesilo\r\nlargeroofs[.]top – registered on 15 March 2024 via Namesilo and XOR-encoded in the cipher_log payload\r\nThe link between largeroofs[.]top and the attacker is confirmed, as this domain appears in a payload. Given\r\nthat the other two domains were registered within the same timeframe, using the same .top TLD and the same\r\nregistrar, it is highly likely that they also belong to the attacker.\r\nAsus link\r\nAnalysis of the 13cd040a7f488e937b1b234d71a0126b7bc74367bf6538b6961c476f5d620d13 payload indicates an\r\nassociation with: hxxps://asustordownload[.]com:45674\r\nThis domain is linked to IP address 43.129.205[.]244 , which is located in Hong Kong and belongs to Tencent\r\nASN 132203. It was registered on 21 March 2024 via Alibaba Cloud. This registration date aligns with the\r\ntimeframe of the .top domain registrations, suggesting that the operation likely began in March 2024.\r\nSynology link\r\nPayloads 932b2545bd6e3ad74b82ca2199944edecf9c92ad3f75fce0d07e04ab084824d5 and\r\n121969d72f8e6f09ad93cf17500c479c452e230e27e7b157d5c9336dff15b6ef, targeting Synology devices, notify on\r\ntwo IP addresses.\r\n122.8.183[.]181 : this address is located in Mexico and belongs to Huawei Cloud ASN 136907. A passive DNS\r\nsearch on this IP address shows that it is associated with three domains exhibiting strong similarities:\r\ngardensc[.]cc – registered on 22 January 2025 via Namecheap\r\nhttps://blog.sekoia.io/polaredge-unveiling-an-uncovered-iot-botnet/\r\nPage 9 of 13\n\nheadached[.]cc – registered on 11 November 2024 via Namecheap\r\ndurianlink[.]cc – registered on 11 November 2024 via Namecheap\r\n159.138.119[.]99 : this address is located in Chile and also belongs to Huawei Cloud ASN 136907. A passive\r\nDNS search on this IP address shows that it is associated with four domains exhibiting strong similarities:\r\nnternetd[.]cc – registered on 02 December 2024 via Namecheap\r\nsuiteiol[.]cc – registered on 02 December 2024 via Namecheap\r\ncentrequ[.]cc – registered on 12 November 2024 via Namecheap\r\nicecreand[.]cc – registered on 12 November 2024 via Namecheap\r\nQNAP link\r\nAnalysis of the 464f29d5f496b4acffc455330f00adb34ab920c66ca1908eee262339d6946bcd payload indicates an\r\nassociation with hxxps://siotherlentsearsitech[.]shop:58425 . This domain name points to the address\r\n195.123.212[.]54 , which is also used by the cisco payload cipher_log. \r\nThe domain was registered on 27 November 2023 through Namecheap. This is the oldest domain associated with\r\nthis botnet, indicating that the botnet has been active since at least that date.\r\nIllumination of compromised assets\r\nAs outlined in Case 2: TLS Backdoor chapter, honeypot logs reveal that the vulnerability is exploited within the\r\nsame timeframe by multiple distinct IP addresses who share similarities, indicating a coordinated attack. This\r\npattern suggests botnet activity.\r\nAn analysis of these IP addresses reveals that most are edge devices, primarily Cisco routers. Many of these\r\ndevices have a TLS service running on a random port, associated with a notably distinctive certificate. \r\nhttps://blog.sekoia.io/polaredge-unveiling-an-uncovered-iot-botnet/\r\nPage 10 of 13\n\nThis certificate is also utilised on a TLS port of the delivery FTP server.  It is also present on numerous devices,\r\nassociated with the PolarSSL certificate of the cipher_log payload, and connected to random ports. By searching\r\nthis certificate with Censys engine, 2,017 unique IP addresses were identified.\r\nThis certificate is present on Cisco, Asus and Synology, aligning with the various payloads analysed. Regarding\r\nthe equipment, we observe:\r\nFor Cisco : Cisco RV042, Cisco RV340 and Cisco RV345\r\nFor Asus : RT-AX55, RT-AX88U and RT-AC58U\r\nAs shown in the diagram below, the USA is the most affected country by the botnet, with 540 IPs. Taiwan, where\r\nmany samples have been submitted to VirusTotal, ranks 6th with 115 IPs. The botnet appears to be particularly\r\nprevalent in Asia and South-America. However, it is unclear whether this is due to these regions being a primary\r\ntarget or because it hosts more vulnerable devices.\r\nThe purpose of this botnet has not yet been determined. Cross-checking the IP addresses with our telemetry\r\nhas not revealed any specific activity. An objective of PolarEdge could be to control compromised edge devices,\r\ntransforming them into Operational Relay Boxes for launching offensive cyber attacks. This is a working\r\nhypothesis, and we currently have no evidence to support it; we continue to investigate further\r\nhttps://blog.sekoia.io/polaredge-unveiling-an-uncovered-iot-botnet/\r\nPage 11 of 13\n\nConclusion\r\nPolarEdge botnet has been active since at least the end of 2023, targeting a wide range of devices and associated\r\nwith a significant infrastructure. The botnet exploits multiple vulnerabilities across different types of equipment,\r\nhighlighting its ability to target various systems. The complexity of the payloads further underscores the\r\nsophistication of the operation, suggesting that it is being conducted by skilled operators. This indicates that\r\nPolarEdge is a well-coordinated and substantial cyber threat.\r\nEdge devices remain a key component in the operational infrastructures of many threat actors, including the\r\nPolarEdge botnet operators. These devices are frequently targeted because of their accessibility, vulnerabilities,\r\nand their role in providing exit nodes that enable anonymous and distributed attacks. With a large number of\r\ncompromised devices spread across different regions, malicious actors can hide their activities and conduct attacks\r\nwith reduced risk of detection.\r\nThe main objective of PolarEdge remains unclear, but a working hypothesis suggests that it could be using\r\ncompromised devices as Operational Relay Boxes (ORB) to facilitate offensive cyber operations. We continue to\r\nanalyse the payloads and monitor this threat closely, as we work to better understand its tactics, techniques, and\r\noverall goals.\r\nThank you for reading this blog post. Please don’t hesitate to provide your feedback on our publications\r\nby clicking here. You can also contact us at tdr[at]sekoia.io for further discussions.\r\nIoCs\r\nWebshell – sha256\r\n1ca7262f91d517853a0551b14abb0306c4e3567e41b1e82a018f0aac718e499e\r\nPolarEdge botnet – sha256\r\neda7cc5e1781c681afe99bf513fcaf5ae86afbf1d84dfd23aa563b1a043cbba8\r\n13cd040a7f488e937b1b234d71a0126b7bc74367bf6538b6961c476f5d620d13\r\n464f29d5f496b4acffc455330f00adb34ab920c66ca1908eee262339d6946bcd\r\nµ932b2545bd6e3ad74b82ca2199944edecf9c92ad3f75fce0d07e04ab084824d5\r\n121969d72f8e6f09ad93cf17500c479c452e230e27e7b157d5c9336dff15b6ef\r\nPolarEdge botnet – Delivery infrastructure\r\n119.8.186[.]227\r\nlonglog[.]cc\r\nlandim[.]cc\r\nhitchil[.]cc\r\nLogchim[.]cc\r\nssofhoseuegsgrfnu[.]ru\r\nhttps://blog.sekoia.io/polaredge-unveiling-an-uncovered-iot-botnet/\r\nPage 12 of 13\n\nPolarEdge botnet – Reporting infrastructure\r\naipricadd[.]top\r\nfirebasesafer[.]top\r\nlargeroofs[.]top\r\nsiotherlentsearsitech[.]shop\r\nasustordownload[.]com\r\ngardensc[.]cc\r\nheadached[.]cc\r\ndurianlink[.]cc\r\nnternetd[.]cc\r\nsuiteiol[.]cc\r\ncentrequ[.]cc\r\nicecreand[.]cc\r\n159.138.119[.]99\r\n43.129.205[.]244\r\n122.8.183[.]181\r\n195.123.212[.]54\r\nFeel free to read other Sekoia.io TDR (Threat Detection \u0026 Research) analysis here :\r\nBotnet CTI Infrastructure\r\nShare this post:\r\nSource: https://blog.sekoia.io/polaredge-unveiling-an-uncovered-iot-botnet/\r\nhttps://blog.sekoia.io/polaredge-unveiling-an-uncovered-iot-botnet/\r\nPage 13 of 13",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://blog.sekoia.io/polaredge-unveiling-an-uncovered-iot-botnet/"
	],
	"report_names": [
		"polaredge-unveiling-an-uncovered-iot-botnet"
	],
	"threat_actors": [
		{
			"id": "3fff98c9-ad02-401d-9d4b-f78b5b634f31",
			"created_at": "2023-01-06T13:46:38.376868Z",
			"updated_at": "2026-04-10T02:00:02.949077Z",
			"deleted_at": null,
			"main_name": "Cleaver",
			"aliases": [
				"G0003",
				"Operation Cleaver",
				"Op Cleaver",
				"Tarh Andishan",
				"Alibaba",
				"TG-2889",
				"Cobalt Gypsy"
			],
			"source_name": "MISPGALAXY:Cleaver",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		}
	],
	"ts_created_at": 1775434307,
	"ts_updated_at": 1775791966,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/be48fcbf0bb242bfc07005c81fc85259d76aa711.pdf",
		"text": "https://archive.orkl.eu/be48fcbf0bb242bfc07005c81fc85259d76aa711.txt",
		"img": "https://archive.orkl.eu/be48fcbf0bb242bfc07005c81fc85259d76aa711.jpg"
	}
}