Tre ore possono bastare per passare dal primo tentativo all’accesso privilegiato nel cloud. Microsoft ha osservato questa finestra in più attacchi accelerati da ARTEX, un framework di penetration test guidato da agenti AI. Per una PMI la conseguenza è concreta: l’inventario aggiornato una volta al trimestre e gli alert controllati il giorno dopo non sono più un livello di difesa adeguato.

Il punto non è acquistare subito un nuovo prodotto “AI security”. Bisogna ridurre ciò che un agente può scoprire, togliere privilegi alle identità applicative e preparare una risposta eseguibile mentre l’attacco è ancora in corso. Questa guida traduce il caso ARTEX in un piano di lavoro per WordPress, Microsoft 365, servizi cloud e automazioni aziendali.

ARTEX cambia la velocità, non le regole

ARTEX nasce come piattaforma open source per penetration test autorizzati. Riceve un obiettivo in linguaggio naturale, lo divide in attività e coordina più agenti che eseguono ricognizione, test e raccolta delle evidenze. Secondo CERT-EU, il rispetto dello scope dipende dalle regole configurate e dal modello: non esiste un vincolo tecnico rigido che impedisca all’agente di uscire dal perimetro previsto.

Il progetto originale è stato ritirato nell’ottobre 2026 dopo le prime segnalazioni di abuso, ma fork e copie continuano a circolare. Il 4 novembre 2026 Censys rilevava 1.465 console ARTEX esposte su Internet. Circa 650 erano concentrate in due blocchi di hosting configurati allo stesso modo; restavano circa 815 installazioni dall’aspetto distinto. In 155 host, pari al 10,6% del campione, Censys vedeva anche almeno un altro artefatto classificato come minaccia.

Il dato più utile non è il numero assoluto, che può cambiare rapidamente. È la dinamica: strumenti offensivi potenti vengono installati con pannelli pubblici, directory aperte e configurazioni predefinite. Gli stessi errori che espongono l’attaccante espongono ogni azienda che mette online una nuova dashboard senza autenticazione, un ambiente di staging dimenticato o un endpoint di automazione troppo permissivo.

Perché una PMI è un bersaglio adatto

Un operatore umano deve scegliere dove investire tempo. Un agente può provare in parallelo molti percorsi economici: password deboli, applicazioni web non aggiornate, pannelli amministrativi esposti, token riutilizzati e permessi OAuth eccessivi. Non gli serve una vulnerabilità spettacolare. Gli basta concatenare due o tre errori ordinari prima che qualcuno reagisca.

Microsoft Threat Intelligence ha collegato ARTEX all’attività del gruppo Storm-0940. Nella campagna descritta, il framework ha accelerato scansione, ricognizione, password spraying e abuso di applicazioni OAuth. Dopo una compromissione nella filiera ConnectWise, gli attaccanti hanno tentato l’accesso a oltre 2.250 tenant. Una parte della campagna ha prodotto più di 151.000 accessi falliti contro 327 account di otto organizzazioni, con picchi superiori a 2.900 tentativi al minuto. In quel blocco Microsoft non ha osservato autenticazioni riuscite, emissione di token o modifiche alla directory: il volume di attività, da solo, non dimostra una violazione.

Questa distinzione è importante. Gli alert rumorosi possono indicare che i controlli stanno funzionando, ma la velocità riduce il tempo disponibile per capirlo. Se il team deve prima scoprire chi gestisce il dominio, dove sono i log o quale fornitore possiede il backup, la finestra operativa è già persa.

La mia tesi è semplice: contro gli agenti offensivi una PMI ottiene più valore da un perimetro piccolo e spiegabile che da un altro cruscotto. Ogni servizio non censito, credenziale applicativa permanente o pannello raggiungibile dall’esterno diventa un ramo in più che l’automazione può esplorare.

Fase 1: inventario esterno in due ore

Il primo controllo deve partire dalla vista di Internet, non dal foglio Excel interno. Elenca domini, sottodomini, indirizzi IP pubblici, VPN, pannelli di hosting, WordPress, ambienti di staging, webmail, NAS, strumenti RMM, webhook e servizi di automazione. Per ogni elemento registra proprietario, funzione, autenticazione, data dell’ultima patch e necessità reale di essere pubblico.

La domanda decisiva è: “Se questo indirizzo compare oggi in un motore di scansione, cosa può capire un estraneo senza credenziali?”. Apri le URL da una rete esterna e verifica intestazioni, pagine di login, messaggi di errore, directory, documentazione API e banner di versione. Non eseguire test invasivi su sistemi che non possiedi o per i quali non hai un’autorizzazione esplicita.

  • Chiudi pannelli, database e dashboard che non richiedono accesso pubblico.
  • Filtra gli strumenti amministrativi con VPN, allowlist IP o access proxy con MFA.
  • Separa staging e produzione: credenziali, database, bucket e chiavi non devono essere condivisi.
  • Riduci le risposte di errore che rivelano framework, percorsi interni o versioni.
  • Assegna un responsabile e una scadenza a ogni esposizione che non puoi eliminare subito.

Su WordPress controlla almeno accesso al backend, XML-RPC se non necessario, REST endpoint personalizzati, directory di upload e plugin con interfacce proprie. Non bloccare alla cieca le API core: misura prima quali integrazioni le usano. Per estendere la verifica a fornitori, account e asset amministrativi, usa anche la checklist Sicurezza: il controllo è il bersaglio. Il principio è togliere superficie inutile senza rompere il servizio.

Fase 2: identità e applicazioni entro la giornata

La seconda area è l’identità, soprattutto quella non umana. Un account amministratore con MFA è solo una parte del problema. Plugin WordPress, connettori Microsoft 365, account di servizio, webhook e strumenti no-code possono conservare token che non richiedono un login interattivo.

Crea un inventario delle applicazioni registrate e dei relativi permessi. In Microsoft 365 verifica accessi dei service principal, credenziali aggiunte di recente, modifiche ai privilegi e chiamate anomale a Microsoft Graph. Microsoft raccomanda proprio questi controlli nel caso Storm-0940, perché l’abuso delle identità applicative può proseguire anche senza indovinare la password di un utente.

Per ogni integrazione applica quattro domande:

  1. Il token è ancora necessario e ha una scadenza?
  2. I permessi sono limitati alle sole risorse usate?
  3. La credenziale è conservata in un secret manager, non nel codice o in un file pubblico?
  4. Esiste un log che permetta di attribuire ogni uso a un servizio preciso?

Revoca le integrazioni senza proprietario prima di ottimizzare quelle note. Ruota subito le credenziali trovate in repository, backup accessibili o configurazioni condivise. Per WordPress, assegna Application Password distinte alle automazioni: se una viene compromessa puoi revocarla senza cambiare la password principale e senza fermare gli altri flussi.

Se trovi un token sospetto, non limitarti a sostituirlo. Conserva i log, ricostruisci l’intervallo di esposizione e verifica le azioni eseguite. Ho raccolto questa sequenza nella guida interna Token rubati: piano di risposta SaaS.

Fase 3: rilevazione pensata per le macchine

Un attacco automatizzato può generare segnali molto più rapidi del comportamento umano. Le soglie devono quindi osservare velocità, parallelismo e cambi di identità, non soltanto il totale giornaliero. Un rapporto visto la mattina successiva serve alla ricostruzione, non al contenimento.

Configura alert per questi eventi:

  • picchi di errori di autenticazione distribuiti su molti account;
  • accessi riusciti subito dopo una sequenza di tentativi falliti;
  • nuove credenziali aggiunte ad applicazioni OAuth o account di servizio;
  • variazioni di ruoli, gruppi amministrativi e permessi Graph;
  • scansioni ripetitive su endpoint, parametri o percorsi inesistenti;
  • processi di rete o escalation di privilegi anomali sugli host esposti;
  • download massivi e chiamate API incompatibili con il normale lavoro del servizio.

Evita di bloccare automaticamente ogni picco senza contesto: potresti fermare un crawler legittimo, un job interno o un test autorizzato. Collega invece l’alert a un’azione preparata: disabilitare una credenziale, isolare un host, limitare un endpoint o attivare una regola WAF temporanea. CERT-EU raccomanda anche di conservare nel ciclo di remediation i rilievi a bassa severità, perché un agente può concatenare più configurazioni minori in un percorso ad alto impatto.

Il runbook dei primi 30 minuti

Il runbook deve stare fuori dai sistemi che potrebbe servire a ripristinare. Indica persone, contatti dei fornitori, accessi di emergenza e posizione dei log. Poi scrivi una sequenza breve che il responsabile possa eseguire sotto pressione.

  1. Conferma il segnale: identifica asset, account, intervallo temporale e fonte dell’alert.
  2. Preserva le evidenze: esporta log di autenticazione, applicazioni, WAF, hosting e WordPress prima della rotazione.
  3. Contieni: revoca token, sospendi account o isola il servizio colpito limitando l’impatto sul business.
  4. Cerca persistenza: controlla nuove credenziali, ruoli, utenti, scheduled task, plugin e modifiche ai file.
  5. Decidi il ripristino: usa una copia verificata e cambia le credenziali coinvolte prima di riaprire l’accesso.
  6. Registra: annota decisioni, orari, responsabili e sistemi controllati per evitare buchi nella verifica.

Una prova da tavolo di 30 minuti vale più di un documento di venti pagine mai testato. Simula un token applicativo rubato o un pannello WordPress esposto e misura quanto tempo serve per arrivare ai log, revocare l’accesso e contattare il fornitore. Se un passaggio dipende da una sola persona, non hai ancora un processo: hai una dipendenza.

Cosa completare nelle prossime 24 ore

Non serve risolvere l’intera sicurezza aziendale in un giorno. Serve eliminare i percorsi più economici per l’attaccante e ridurre il tempo di reazione.

  • Completa l’elenco degli asset raggiungibili da Internet e chiudi almeno un’esposizione inutile.
  • Proteggi i pannelli amministrativi con MFA e un livello di accesso separato dalla sola password.
  • Rivedi le applicazioni OAuth, gli account di servizio e le Application Password WordPress.
  • Attiva un alert su modifiche a credenziali applicative e ruoli privilegiati.
  • Definisci chi può revocare un token e chi può isolare un servizio fuori orario.
  • Esegui una simulazione breve e annota i minuti persi per mancanza di accessi o informazioni.

Il caso ARTEX mostra che la variabile cambiata dall’AI è il tempo. Le debolezze restano note: superfici esposte, patch in ritardo, identità troppo potenti e log non presidiati. La risposta pratica è rendere il perimetro più piccolo, le autorizzazioni più brevi e il contenimento più veloce. È meno appariscente di una nuova piattaforma, ma è il lavoro che sottrae davvero opzioni a un agente offensivo.

Fonti