Botnet PolarEdge

I ricercatori di sicurezza hanno recentemente svelato i meccanismi di una famiglia di botnet incentrata sui router, denominata PolarEdge. La sua combinazione di comunicazione basata su TLS, trucchi di configurazione incorporati e misure anti-analisi deliberate la rendono una minaccia notevole per i dispositivi di rete domestici e delle PMI.

Cronologia e scoperta

I ricercatori hanno documentato per la prima volta PolarEdge nel febbraio 2025, collegandolo a campagne che prendevano di mira router e dispositivi NAS di diversi fornitori. Entro agosto 2025, gli analisti avevano mappato gran parte dell'infrastruttura della botnet e osservato tratti coerenti con una rete in stile Operational Relay Box (ORB). La telemetria retrospettiva suggerisce che alcune attività di PolarEdge potrebbero risalire addirittura a giugno 2023.

Obiettivi e accesso iniziale

Sono stati identificati come obiettivi i dispositivi dei principali fornitori, tra cui Cisco, ASUS, QNAP e Synology, evidenziando che sia i router di livello enterprise che quelli di livello consumer e i sistemi NAS sono a rischio di sfruttamento.

Nelle catene di attacchi del febbraio 2025, gli autori della minaccia hanno sfruttato una vulnerabilità Cisco nota (CVE-2023-20118) per recuperare un piccolo script shell inviato tramite FTP denominato "q". Il ruolo di tale script era quello di recuperare e avviare la backdoor ELF PolarEdge sull'host compromesso.

Progettazione dell’impianto centrale

PolarEdge è un impianto ELF compatibile con TLS che principalmente:

• Invia un'impronta digitale dell'host a un server di comando e controllo (C2), quindi
• Attende i comandi su un server TLS integrato implementato tramite mbedTLS v2.8.0.

Il comportamento predefinito dell'impianto è quello di agire come server TLS utilizzando un protocollo binario personalizzato. Un campo chiave del protocollo è HasCommand: quando questo campo è uguale al carattere ASCII 1, l'impianto legge il campo Command, esegue il comando specificato localmente e restituisce l'output del comando grezzo al C2.

Modalità di funzionamento

PolarEdge supporta due modalità aggiuntive:

Modalità Connect-back : l'impianto si comporta come un client TLS per estrarre file da server remoti.

Modalità debug : una modalità interattiva che consente agli operatori di modificare al volo i parametri di configurazione (ad esempio, gli indirizzi del server).

Configurazione e offuscamento incorporati

La botnet memorizza la sua configurazione di runtime negli ultimi 512 byte dell'immagine ELF. Quel blocco è offuscato da un XOR a singolo byte; i ricercatori segnalano che la chiave XOR è 0x11, che deve essere applicata per recuperare la configurazione.

Operazioni sui file

Dopo l'esecuzione, l'impianto esegue spostamenti e rimozioni del file system (ad esempio, lo spostamento di file binari come /usr/bin/wget e /sbin/curl e l'eliminazione di file come /share/CACHEDEV1_DATA/.qpkg/CMS-WS/cgi-bin/library.cgi.bak). L'intento operativo preciso alla base di queste azioni non è del tutto chiaro dai dati disponibili.

Tecniche di evasione e anti-analisi

PolarEdge incorpora una serie di sofisticati meccanismi difensivi progettati per eludere il rilevamento e impedire l'analisi, rendendo più difficile per i ricercatori della sicurezza e gli strumenti automatizzati identificarne il comportamento e analizzarne il funzionamento interno.

Nasconde i dettagli delle routine di inizializzazione e di fingerprinting del server TLS tramite offuscamento.

Durante l'avvio, esegue il process masquerading, scegliendo casualmente un nome di processo da un elenco integrato per confondersi con i servizi di sistema legittimi.

Alcuni dei nomi possibili includono:

• igmpproxy
• wscd
• /sbin/dhcpd
• httpd
• upnpd
• applicazione i-app

Resilienza senza persistenza classica

PolarEdge non sembra installare un meccanismo di persistenza tradizionale che sopravviva ai riavvii. Invece, esegue un trucco a runtime: esegue un fork e il processo figlio esegue un polling ogni 30 secondi per verificare se la directory /proc/ del processo padre esiste ancora. Se quella directory scompare (indicando che il processo padre è scomparso), il processo figlio esegue un comando shell per rilanciare la backdoor, fornendo di fatto un ripristino opportunistico a runtime anziché una persistenza permanente all'avvio.

Takeaway difensivi

Le organizzazioni che gestiscono router e dispositivi NAS dovrebbero assicurarsi di applicare gli aggiornamenti e le mitigazioni dei fornitori per CVE-2023-20118 e vulnerabilità simili di esecuzione remota. Dovrebbero monitorare attivamente attività TLS insolite da dispositivi di rete e connessioni in uscita verso host inaspettati. È altrettanto fondamentale prestare attenzione a segnali di mascheramento dei processi e a eventuali modifiche o eliminazioni non autorizzate di file binari di rete e script rivolti al web.