MikroTrick e MemTensor: router senza login e pacchetti AI trasformano la fiducia in accesso

🛡️ Executive Summary

• MikroTrick concatena due vulnerabilità RouterOS per ottenere privilegi amministrativi via SSH senza password, chiavi o autenticazione completata.
• Versioni compromesse di due pacchetti MemTensor su npm e PyPI distribuiscono il malware multipiattaforma sckit per sottrarre credenziali.
• I due incidenti colpiscono estremi diversi della stessa catena: infrastruttura di rete esposta e ambienti di sviluppo autorizzati a distribuire software.

Due compromissioni tecnicamente lontane mostrano lo stesso problema: quando un componente fidato acquisisce troppo potere, l’attaccante non deve necessariamente violare il bersaglio finale. La catena MikroTrick consente di prendere il controllo amministrativo di router MikroTik raggiungibili via SSH senza completare l’autenticazione. Nel mondo dello sviluppo, versioni compromesse di pacchetti MemTensor distribuite attraverso npm e PyPI installano invece sckit, un implant Go capace di cercare credenziali e segreti su Windows, Linux e macOS. Nel primo caso viene spezzato il confine tra rete pubblica e amministrazione del router; nel secondo viene sfruttata la fiducia automatica riposta nei package registry e nelle pipeline di pubblicazione.

MikroTrick combina due falle SSH e arriva alla console amministrativa

La ricostruzione tecnica di CERT Polska identifica con precisione le due vulnerabilità che formano MikroTrick: CVE-2026-67279 e CVE-2026-86060. La prima altera la macchina a stati del server SSH di RouterOS. Durante una rinegoziazione delle chiavi avviata nella fase di autenticazione, il sistema vulnerabile può passare alla gestione dei channel senza avere mai inviato SSH_MSG_USERAUTH_SUCCESS.

Da sola la falla non assegna ancora un’identità autenticata né privilegi. È CVE-2026-86060 a trasformare quel salto logico in accesso amministrativo. RouterOS passa username e policy mask al programma /nova/bin/login come argomenti della command line senza validare correttamente un nome utente che inizi con caratteri speciali. Utilizzando -2 come username, l’attaccante induce il processo a interpretare il valore come un’opzione e può controllare la policy mask associata alla sessione.

La combinazione permette quindi di raggiungere una console con privilegi full senza conoscere la password, possedere una chiave SSH valida o terminare normalmente il login. I log compatibili con questo schema risalgono almeno al 2 settembre, un giorno prima della distribuzione delle patch. Matrice Digitale aveva già seguito gli attacchi contro RouterOS e l’emergere di MikroTrick e successivamente l’ingresso di MikroTik nel catalogo KEV. La nuova analisi chiarisce ora esattamente come i due bug vengono concatenati.

Leggi anche: CISA inserisce RouterOS nel KEV insieme ad altre vulnerabilità sfruttate

Gli attacchi precedono la disclosure e lasciano tracce precise

MikroTik ha distribuito le correzioni il 3 settembre nelle versioni RouterOS 6.49.21, 7.23.4, 7.24.2 e 7.25beta3. CERT Polska aveva poi confermato pubblicamente il 5 settembre che una combinazione di vulnerabilità veniva già utilizzata contro sistemi con SSH raggiungibile da Internet. Gli indicatori sono particolarmente riconoscibili. Nei log analizzati compare un tentativo di login fallito per l’utente -2, seguito in alcuni casi dalla creazione di un account ops appartenente al gruppo full. CERT Polska ha associato ad attività osservate anche gli indirizzi 82.192.72.4 e 103.102.31.18. Il meccanismo Flagged introdotto nelle versioni corrette può individuare alcune modifiche sospette, ma la stessa CERT avverte che l’assenza del flag non dimostra che il router sia pulito. Su un dispositivo potenzialmente compromesso, installare la patch chiude il vettore ma non elimina account, script, scheduler, tunnel o configurazioni eventualmente lasciati dall’attaccante. Il prerequisito fondamentale resta l’esposizione SSH. MikroTik non espone di default le porte amministrative verso Internet nella configurazione domestica standard, quindi il rischio più elevato riguarda apparati nei quali firewall e accesso remoto sono stati modificati.

MemTensor porta sckit dentro npm e PyPI

Il secondo caso sposta il problema dai router alle workstation degli sviluppatori. Secondo la ricerca tecnica di StepSecurity, un attaccante è riuscito a pubblicare versioni malevole di due pacchetti legittimi del progetto MemTensor. Sul registry npm risultano compromesse le versioni 0.1.21, 0.1.23 e 0.1.25 di @memtensor/memos-cloud-openclaw-plugin; le versioni intermedie 0.1.22 e 0.1.24 risultano invece pulite. Su PyPI è stata compromessa MemoryOS 2.0.34, successivamente posta in quarantena.

Le release malevole incorporano sckit, un eseguibile Go realizzato per Windows, Linux e macOS su architetture x64 e ARM64. Nel plugin OpenClaw il payload viene avviato all’accensione del gateway dell’agente e durante gli eventi di memory recall. In questo secondo caso riceve anche il testo del prompt dell’utente oltre alle variabili d’ambiente del processo. Il rischio quindi non riguarda soltanto il computer locale. Le variabili d’ambiente di un ambiente di sviluppo o di una pipeline CI possono contenere token cloud, chiavi di package registry, credenziali GitHub e altri segreti riutilizzabili per propagare la compromissione.

sckit cerca credenziali e possiede primitive da supply chain worm

La ricerca di SafeDep ricostruisce una catena particolarmente pericolosa. Il malware cerca credenziali nella home directory e invia i dati verso infrastrutture sotto il dominio skyleen.fr. L’analisi del framework mostra inoltre codice e template orientati a installarsi in pacchetti npm, pacchetti Python e workflow GitHub Actions. Qui serve una distinzione: SafeDep documenta la presenza delle primitive di propagazione nel malware, ma non afferma che sckit abbia già prodotto una diffusione autonoma oltre MemTensor. La compromissione confermata riguarda i pacchetti pubblicati dal progetto; la capacità di trasformarsi in un worm più ampio è tecnicamente presente ma non equivale a propagazione osservata. L’incidente arriva in una fase nella quale npm è già sottoposto a forte pressione. PhantomRaven ha usato pacchetti e LLM per sottrarre segreti agli sviluppatori, mentre indexed-btree ha dimostrato che bloccare gli install script non elimina il malware se il payload viene spostato al runtime. Poco prima, TanStack e CrowdSec erano entrati nello stesso ciclo di compromissioni della supply chain npm.

Continua con:

• Shai-Hulud cerca 469 percorsi per rubare credenziali da AI, cloud e CI/CD
• Plugin4Shell rompe i pin SHA dei coding agent e riapre il rischio supply chain

Router e package registry mostrano lo stesso problema di fiducia

MikroTrick e MemTensor non condividono codice, infrastruttura o attori noti. Condividono però una proprietà strutturale: l’attaccante raggiunge il bersaglio acquisendo la capacità di un componente intermedio già autorizzato. Nel router, la combinazione di due errori porta una connessione SSH non autenticata fino alla console amministrativa. Nella supply chain, una release pubblicata con l’identità di un progetto legittimo viene installata perché npm e PyPI rappresentano il normale percorso di distribuzione del software. Per le organizzazioni, questo modifica anche le priorità difensive. Sul perimetro significa eliminare l’esposizione non necessaria delle interfacce amministrative e trattare un router compromesso come un possibile punto di persistenza. Negli ambienti di sviluppo significa invece ridurre la durata dei token, separare i privilegi di pubblicazione, controllare le dipendenze e monitorare ciò che un pacchetto esegue dopo l’installazione. La supply chain e il perimetro di rete sembrano domini distinti. In realtà entrambi dipendono dalla stessa domanda: quale componente può agire con privilegi elevati perché l’infrastruttura si fida già di lui? MikroTrick e sckit mostrano cosa accade quando quella fiducia diventa il vero vettore d’attacco.