ScreenConnect firmato e pulito diventa un trojan: ecco come i RMM diventano armi

Attori di minaccia distribuiscono un installer legittimo di ScreenConnect preconfigurato per collegarsi a un relay controllato dall'attaccante, sfruttando la trust implicita nei tool di remote monitoring and management per eludere i controlli di sicurezza. L'analisi di un campione rilevato in un'email di phishing dimostra come un binario firmato da ConnectWise possa diventare un access point remoto senza alcuna alterazione del codice. Il report, pubblicato su SANS Internet Storm Center da Xavier Mertens, Senior ISC Handler, indica una data "Thu, Oct 1st" che presenta una discrepanza calendariologica con il 1 ottobre 2024 (martedì): la cronologia esatta resta quindi incerta.

Il campione che non sembra un malware

L'email analizzata dal handler SANS presentava una finta notifica d'ordine in PDF e indirizzava il destinatario al download di un eseguibile. Il file non era un clone, non un dropper, non un binario patchato: era l'installer ufficiale di ScreenConnect, firmato digitalmente con la stessa catena di trust che il sistema operativo riconoscerebbe per qualsiasi distribuzione legittima.

L'Authenticode digest corrisponde esattamente alla firma. Non c'è overlay, non c'è append alla certificate table, non c'è la classica "signed-but-tampered config trick" che alcuni attaccanti usano per iniettare dati malevoli in zone non coperte dalla firma. Il binario è integro. E questo è precisamente il problema.

"The PE is signed by ConnectWise, LLC (DigiCert G4 Code Signing CA1). The Authenticode digest matches the signed digest exactly. There's no overlay and nothing appended to or injected into the certificate table, so the signed-but-tampered config trick isn't used here." — Xavier Mertens, Senior ISC Handler

Come funziona la "configurazione come arma"

Il meccanismo non sfrutta una vulnerabilità. Sfrutta la progettazione stessa del software RMM. Il client ScreenConnect contiene parametri di connessione — instance ID, relay, chiave pubblica — che normalmente punterebbero all'infrastruttura dell'IT provider legittimo. L'attaccante ha semplicemente preconfigurato questi parametri per puntare al proprio relay: instance-v2e3e2-relay.screenconnect.com, con instance ID v2e3e2 e una chiave pubblica RSA-2048 il cui hash SHA256 è 16b1cec1…9b00ead7.

Il risultato è un client "tuttofare" che, una volta eseguito, stabilisce una connessione legittima all'infrastruttura cloud di ConnectWise, ma instradata verso un'istanza controllata dall'attaccante. Il traffico esce dal network vittima attraverso endpoint appartenenti al dominio ufficiale del vendor. I filtri URL, i proxy, le whitelist applicative non hanno su coso basarsi per bloccare.

Perché il rilevamento fallisce

Il campione era sconosciuto su VirusTotal quando Mertens lo ha analizzato. Questo significa che nessun motore antivirus aveva ancora generato una signature, né esisteva reputazione negativa per quel particolare hash. La ragione è strutturale: non c'è malware da rilevare. Il binario è lo stesso che migliaia di MSP distribuiscono quotidianamente ai propri clienti.

L'email, secondo la fonte, ha superato i controlli di sicurezza di base. Il link puntava a un vero file PE eseguibile, ospitato su un dominio australiano che apparentemente non era già inserito in blocklist. La catena di consegna non presentava i classici indicatori di compromissione: niente macro Office, niente script Powershell offuscato, niente exploit del browser. Solo un clic, un download, un'esecuzione.

"Such tools are a gold mine for attackers because they are easy to deploy and trusted by most used!" — Xavier Mertens, Senior ISC Handler

Perche e importante

Il dossier non specifica misure correttive indicate dal vendor o contromisure operative consigliate agli utenti. Il brief non documenta se il relay instance-v2e3e2 sia stato sospeso da ConnectWise, né fornisce indicatori di compromissione aggiuntivi per la ricerca in propri ambienti. Non emerge la scala della campagna: il report descrive un singolo campione analizzato, senza indicare se altri relay o istanze siano coinvolti.

Il dossier non specifica la motivazione dell'attaccante — accesso remoto per ransomware, spionaggio, o vendita di accesso — né la geografia delle vittime targettate. Non sono documentate azioni raccomandate da parte di ConnectWise, né misure di hardening o monitoring specifiche per questa tecnica.

Ciò che il report documenta con chiarezza è il vettore: la trust chain del software firmato usata come ponte per l'accesso remoto. Per i team di sicurezza, questo implica uno spostamento del perimetro di rilevamento. Non più "questo file è firmato, quindi affidabile", ma "questo file firmato sta comunicando con un relay non autorizzato". Il punto di controllo si sposta dal binario all'attività di rete, dalla firma all'anomalia comportamentale.

L'incidente si inserisce in un pattern più ampio di abusi RMM documentato dal progetto LOLRMM, citato nel report SANS come riferimento correlato. La differenza qui è l'eleganza tecnica: nessuna modifica, nessun exploit, solo configurazione. Il binario rimane pulito anche dopo l'esecuzione, ostacolando le analisi forensi basate su artefatti di compromissione tradizionali.

Limiti e punti ancora da verificare

La base probatoria si limita a un singolo campione osservato da un handler SANS. Mancano conferme indipendenti da fonti di sicurezza primarie — Wiz, Snyk, Mandiant, CISA — o advisory strutturati. Non è quantificabile la diffusione della campagna, né è possibile stabilire se il dominio thelittlecupandsaucer[.]com[.]au sia ancora attivo o sia stato oggetto di takedown.

La data dell'incidente presenta un'incoerenza interna ("Thu, Oct 1st" contro 1 ottobre 2024 = martedì) che il dossier non risolve. Non è noto se altri campioni con diversi instance ID o relay siano stati rilevati in altri contesti. Il brief non specifica inoltre se la chiave pubblica RSA-2048 identificata sia riutilizzabile come indicatore di compromissione per la ricerca retroattiva.

La fonte non chiarisce se l'istanza relay sia registrata su ConnectWise con credenziali dell'attaccante o con dati di identità rubati, né fornisce dettagli sulla persistenza del client una volta installato. Il report si concentra sull'analisi statica del campione, non sull'esecuzione dinamica o sull'osservazione del traffico di rete in tempo reale.

Le informazioni sono basate sull advisory citata e aggiornate al momento della pubblicazione.

Le informazioni sono basate sulla fonte citata e aggiornate al momento della pubblicazione.

Fonti

• https://isc.sans.edu/diary/rss/33388
• https://www.screenconnect.com/
• https://lolrmm.io/
• https://xameco.be/
• https://xameco.be/pgpkey.txt