Circa 2.250 organizzazioni sono state raggiunte in una campagna che ha sfruttato credenziali applicative sottratte a un fornitore IT: secondo la ricostruzione di TechCrunch, i tentativi di accesso hanno sfiorato quota 3.000 al minuto. Per una PMI la conseguenza concreta è semplice: un’integrazione che ieri serviva a backup o assistenza può diventare oggi una porta già autorizzata verso posta, file e sito WordPress.

Il rischio resta quando il fornitore esce

La manutenzione di WordPress raramente passa da un solo account. Un’agenzia può avere un amministratore nel CMS, un utente SFTP, una chiave SSH, un’applicazione OAuth sul tenant Microsoft 365 e un agente di assistenza remota installato su un computer. Il contratto può terminare, mentre questi accessi restano attivi perché nessuno ne possiede un inventario unico. È qui che il problema tecnico diventa organizzativo.

L’incidente ConnectWise è un promemoria utile, non la prova che ogni strumento remoto sia insicuro. Nel proprio Trust Center, l’azienda ha indicato accessi non autorizzati a credenziali applicative e ha chiesto ai partner coinvolti di mantenere disabilitate le connessioni interessate fino alle istruzioni di riattivazione. La lezione per WordPress è applicabile subito: la fiducia concessa a un fornitore deve avere un proprietario interno, uno scopo dichiarato e una data di revisione.

Crea un registro degli accessi in 20 minuti

Apri un foglio condiviso o il tuo password manager aziendale e registra quattro campi per ogni accesso: servizio, identità tecnica, responsabile interno e condizione di revoca. Parti da WordPress e hosting, poi aggiungi DNS, CDN, analytics, posta, backup e strumenti RMM. Non annotare le password nel foglio: serve una mappa delle autorizzazioni, non una nuova copia dei segreti.

Per WordPress controlla gli utenti con ruolo Amministratore, le Application Password e gli account creati dai plugin di gestione centralizzata. Sul provider verifica SFTP, SSH, pannello hosting e token API. Sul tenant cloud cerca applicazioni registrate, service principal, consensi e credenziali non più necessarie. Per ogni voce chiedi: chi la usa oggi, quale attività abilita e come la disattivo senza interrompere backup o aggiornamenti? Lo stesso principio vale per le chiavi API degli agenti AI: permessi e durata devono essere limitati prima dell’incidente, non dopo.

Revoca in ordine, poi controlla i log

La revoca efficace non consiste nel cambiare soltanto la password dell’amministratore WordPress. Prima sospendi l’identità del fornitore e i token collegati; poi ruota le credenziali condivise che non puoi attribuire a una persona; infine rimuovi agenti remoti, plugin di gestione e chiavi SSH non più richiesti. Se il servizio è ancora necessario, crea una nuova identità nominativa con il minimo privilegio e autenticazione a più fattori.

Dopo la modifica, verifica i log di WordPress, hosting, firewall e tenant cloud nell’intervallo precedente alla revoca. Cerca accessi da località insolite, nuove applicazioni, modifiche ai ruoli e sessioni persistenti. CISA, NSA e MS-ISAC hanno dedicato una guida congiunta all’abuso dei software RMM legittimi: il punto chiave è distinguere l’uso autorizzato da quello anomalo tramite policy, allowlist e monitoraggio. Documenta l’esito e programma la stessa verifica ogni trimestre.

L’errore da evitare: scollegare alla cieca

Disattivare tutto senza conoscere le dipendenze può cancellare la finestra di backup, bloccare gli aggiornamenti o togliere accesso proprio durante un’emergenza. Prima fotografa configurazione e ruoli, verifica l’ultimo backup recuperabile e concorda una finestra breve con il responsabile interno. La priorità non è fare pulizia in fretta: è ridurre l’accesso senza perdere continuità operativa. Se emerge un’attività sospetta, conserva i log e coinvolgi chi gestisce la risposta agli incidenti prima di reinstallare o cancellare sistemi.

Il take operativo è questo: ogni fornitore deve avere accessi separati, scadenza e procedura di uscita. Se oggi non riesci a elencare in pochi minuti chi può entrare nel tuo WordPress e nei servizi collegati, il primo lavoro non è installare un altro plugin di sicurezza. È costruire il registro, assegnare un proprietario e revocare ciò che non ha più una ragione verificabile per restare attivo.