La catena zero-day MikroTrick offre agli attaccanti il controllo amministrativo dei router MikroTik

I dispositivi MikroTik RouterOS con SSH esposto su internet sono sotto attacco attivo attraverso una catena di vulnerabilità nota come MikroTrick. La campagna può portare un attaccante dall'accesso SSH non autenticato al pieno controllo amministrativo di un router vulnerabile.

La catena combina CVE-2026-67276, una vulnerabilità critica che consente di eludere l'autenticazione tramite chiavi RSA, con un punteggio CVSS 9,2, e CVE-2026-86060, una falla che permette l'escalation dei privilegi all'interno di una sessione SSH. CERT Polska ha confermato compromissioni riuscite, inclusa la creazione di un account non autorizzato denominato ops.

Il ricercatore di sicurezza Costin Raiu ha riferito che lo sfruttamento potrebbe essere iniziato il 2 settembre 2026, un giorno prima che MikroTik pubblicasse le correzioni pertinenti. Questa sequenza fa di MikroTrick una campagna zero-day, non un'attività di sfruttamento iniziata soltanto dopo l'analisi pubblica delle patch.

Lo sfruttamento è iniziato prima degli aggiornamenti di sicurezza di MikroTik

I log pubblicati su un forum polacco dedicato alla sicurezza mostrano quelli che sembrano tentativi di sfruttamento risalenti al 2 settembre. Anche CERT Polska ha confermato separatamente la riuscita di attacchi iniziati almeno in quella data.

MikroTik ha pubblicato le correzioni per RouterOS 7.25beta3, 7.24.2, 7.23.4 e 6.49.21 il 3 settembre 2026. Anche RouterOS 7.23.5, pubblicato il 4 settembre 2026, è stato indicato come corretto.

Raiu ha pubblicato la propria analisi tecnica il 5 settembre 2026. Lo stesso giorno, CERT Polska ha diffuso un avviso in cui segnalava che vulnerabilità critiche di RouterOS erano sfruttate attivamente e invitava i clienti ad aggiornare immediatamente i dispositivi.

La tempistica lascia pensare che gli attaccanti sapessero che le correzioni erano imminenti e abbiano iniziato a scansionare o sfruttare i dispositivi prima che gli amministratori potessero applicare le patch. La maggior parte delle attività osservate proveniva da un singolo indirizzo, a indicare un'operazione in grado di colpire su larga scala i router esposti.

MikroTik ha inoltre inviato avvisi sulle vulnerabilità tramite la propria applicazione mobile ufficiale. Secondo quanto riferito, era la prima volta che l'azienda utilizzava questo canale per un avviso di sicurezza.

Per queste falle non è stata resa nota alcuna voce nel catalogo CISA Known Exploited Vulnerabilities né una scadenza associata per la remediation da parte delle amministrazioni federali. Tuttavia, lo sfruttamento già confermato dimostra che il rischio è concreto e operativo, non teorico.

Come la catena MikroTrick aggira l'autenticazione SSH

CVE-2026-67276 riguarda il modo in cui RouterOS verifica le chiavi pubbliche RSA durante l'autenticazione SSH. Un attaccante che conosca un nome utente valido e la componente pubblica della chiave RSA di quell'utente può creare una chiave fraudolenta che RouterOS accetta senza che l'attaccante disponga della corrispondente chiave privata.

Questo compromette un presupposto fondamentale della sicurezza SSH. Le chiavi pubbliche servono a identificare le credenziali autorizzate, mentre la chiave privata dimostra che chi si connette è il legittimo proprietario. Le build vulnerabili di RouterOS possono essere indotte ad accettare l'autenticazione anche in assenza di questa prova.

L'accesso non autorizzato viene quindi combinato con CVE-2026-86060, che consente l'escalation dei privilegi all'interno di una sessione SSH. La concatenazione delle due vulnerabilità può dare a un attaccante remoto non autenticato il pieno controllo amministrativo.

Per seguire questa via d'attacco, il servizio SSH di RouterOS deve essere raggiungibile dalla rete dell'attaccante. I router che espongono direttamente SSH su internet sono quelli più a rischio, anche se un dispositivo può essere preso di mira anche da un'altra rete non attendibile o già compromessa.

Le due vulnerabilità fanno parte di un gruppo di sei falle di RouterOS individuate e coordinate per la divulgazione da CERT Polska. Gli intervalli esatti delle build vulnerabili non sono stati resi noti. Gli amministratori dovrebbero quindi confrontare le proprie installazioni con le versioni corrette del ramo pertinente, senza presumere che una build di poco precedente sia sicura.

Le versioni corrette identificate sono:

• RouterOS 7.25beta3
• RouterOS 7.24.2
• RouterOS 7.23.5
• RouterOS 7.23.4
• RouterOS 6.49.21

Sia RouterOS 7.23.4 sia RouterOS 7.23.5 sono state indicate come versioni corrette. Gli operatori dovrebbero installare la versione corretta e attualmente supportata per il proprio ramo e verificare la versione installata dopo il riavvio o il completamento della procedura di aggiornamento.

L'accesso amministrativo espone l'intero perimetro di rete

Un router compromesso offre agli attaccanti molto più di un semplice punto d'appoggio su un singolo apparato. L'accesso amministrativo può consentire di modificare il routing, indebolire le policy del firewall, intercettare il traffico, reindirizzare le connessioni, creare tunnel o configurare il dispositivo come proxy.

Gli attaccanti possono inoltre aggiungere utenti e chiavi SSH, creare attività pianificate, distribuire script o modificare le impostazioni dei servizi per mantenere l'accesso. Le funzionalità di sniffing dei pacchetti potrebbero esporre il traffico e le credenziali che attraversano il router, mentre modifiche al routing o alla configurazione relativa al DNS potrebbero indirizzare gli utenti verso infrastrutture controllate dagli attaccanti.

Le installazioni MikroTik datate sono particolarmente esposte quando ricevono poca manutenzione. I router possono rimanere operativi per anni, rendendo i dispositivi dimenticati e quelli distribuiti nelle filiali senza adeguata gestione candidati probabili a ricevere le patch in ritardo.

I dispositivi che utilizzano la configurazione firewall predefinita di MikroTik e non espongono SSH su internet sono considerati probabilmente protetti da questa specifica via d'accesso remota. Ciò non dimostra che siano aggiornati o che non siano stati compromessi con altri metodi. È comunque necessario verificare l'esposizione delle interfacce di gestione e le versioni del software.

I log e la cronologia della configurazione possono rivelare una compromissione

Un tentativo MikroTrick fallito può creare una voce nel log di autenticazione contenente il nome utente -2. Non si tratta di un nome account normale e la sua presenza nei record di RouterOS dovrebbe essere oggetto di indagine.

Le attività riuscite possono essere registrate in /system history con un formato simile a:

ssh:-2@<IP>

Gli analisti della risposta agli incidenti dovrebbero correlare questo evento con le successive attività amministrative. Tra le modifiche sospette rientrano:

• Creazione o modifica di utenti e chiavi SSH
• Nuovi script o voci dello scheduler, oppure modifiche a quelli esistenti
• Modifiche ai servizi abilitati
• Modifica delle regole del firewall o del routing
• Attivazione di proxy o tunnel
• Modifica della configurazione per lo sniffing dei pacchetti
• Altre modifiche alla configurazione prive di spiegazione

L'account non autorizzato ops è un indicatore confermato della campagna. La sua presenza dovrebbe attivare immediatamente un'indagine di risposta agli incidenti.

L'assenza di una voce -2 non dimostra che il router sia integro. I log potrebbero essere stati ruotati, sovrascritti o cancellati da un attaccante. Un evento storico che mostri ssh:-2@<IP> seguito da un'azione di configurazione dovrebbe essere trattato come una compromissione confermata, a meno che non provenga da un test di sicurezza autorizzato.

Gli investigatori dovrebbero esaminare sia lo stato attuale sia i record storici. È necessario controllare utenti, chiavi, script, attività pianificate, servizi, policy del firewall, proxy, tunnel, impostazioni per la cattura dei pacchetti e regole di accesso alla gestione.

Indicatori dell'infrastruttura della campagna e dei file

La maggior parte degli attacchi osservati proveniva da 82.192.72[.]4, un indirizzo ospitato da Leaseweb. Anche un secondo indirizzo, 103.102.31[.]18, è stato associato alla campagna.

L'indirizzo principale ospitava quattro file:

• Una build MIPS del binario ufficiale precompilato BusyBox 1.16.1, compilato nel 2010
• ftpsrv.py
• launch.sh
• serve.py

Al momento dell'analisi, tre dei file forniti non risultavano rilevati da VirusTotal. Un numero ridotto o nullo di rilevamenti non deve essere interpretato come prova della loro innocuità in questo contesto operativo.

I difensori possono cercare nei file raccolti e nella telemetria i seguenti hash SHA-256:

File	SHA-256
ftpsrv.py	6e95f70fdbabb57881b3f5b2c8465d4b17ba901100704efb1278bb3386e6729d
launch.sh	972b474b896f9fac3cd6b5b8476b410b8f39fbedee8a3b0c745d6e3b328d7dcd
serve.py	6dca83338d60467b65b7789d4d59754e40a7aaa36f40ea2da57538367ac9b89e

Non è stato reso noto l'hash del binario BusyBox. È opportuno esaminare i dati storici di rete alla ricerca di connessioni in entrata o in uscita che coinvolgano entrambi gli indirizzi IP segnalati.

Prima le patch, poi l'analisi dei router esposti

Gli amministratori dovrebbero aggiornare immediatamente alla versione corretta di RouterOS appropriata e verificare che l'upgrade sia andato a buon fine. SSH dovrebbe essere disabilitato o limitato ovunque sia raggiungibile da internet o da un'altra rete non attendibile.

L'accesso alla gestione dovrebbe invece essere limitato a percorsi amministrativi attendibili, a indirizzi sorgente rigorosamente controllati o a meccanismi di accesso interno protetti. Filtrare i due indirizzi della campagna è utile, ma non può sostituire l'applicazione delle patch, perché gli attaccanti possono spostarsi su nuove infrastrutture.

Qualsiasi dispositivo RouterOS con SSH accessibile da internet dovrebbe essere considerato potenzialmente compromesso finché non saranno esaminati i log, la cronologia della configurazione, gli utenti, le chiavi e le impostazioni attive.

Se viene rilevata un'attività amministrativa non autorizzata, gli analisti della risposta agli incidenti dovrebbero isolare il router, preservare i log e le prove di configurazione, cambiare le password e le chiavi SSH, rimuovere i meccanismi di persistenza e verificare le policy di routing e del firewall. Potrebbe essere necessario ricostruire o ripristinare l'apparato attraverso una procedura affidabile.

Al 5 settembre non era stato segnalato alcun proof of concept pubblico funzionante. Raiu stimava che potesse comparire su GitHub entro uno o due giorni, anche se lo sfruttamento attivo era già in corso senza di esso. Attendere la pubblicazione del codice di exploit non avrebbe quindi offerto ai difensori alcun margine di sicurezza significativo.