Sicurezza informatica per le PMI in Ticino, caso reale documentato del 23 febbraio 2026: la mia infrastruttura ha respinto sei eventi ostili in meno di dieci ore. Ecco cosa è successo, minuto per minuto, e cosa insegna a ogni PMI ticinese.

Che cos'è davvero un attacco informatico a una PMI

Quando si parla di attacchi informatici l'immaginario corre al criminale incappucciato che sceglie con cura la sua vittima. La realtà documentata in questo caso studio è diversa e, per certi versi, più inquietante: la stragrande maggioranza degli attacchi alle piccole e medie imprese è condotta da software automatici, con dietro sempre un criminale o una rete di criminali, che scandagliano liste di migliaia di domini, ventiquattro ore su ventiquattro, alla ricerca di una porta lasciata aperta. Non serve essere un bersaglio interessante ma basta semplicemente essere online. Ecco perché gli attacchi non colpiscono solo chi si espone pubblicamente.

Un attacco automatizzato è un programma che prova in sequenza centinaia di percorsi noti, backdoor lasciate da attacchi precedenti (ossia porte di entrata create precedentemente e apribili su richiesta), file di configurazione esposti, pannelli di amministrazione non protetti e passa al dominio successivo se non trova nulla. Il caso che raccontiamo qui è una giornata reale, registrata sui miei stessi sistemi, con orari, volumi e provenienze verificabili nei log.

Il problema reale: la tua azienda è già in una lista

Il 23 febbraio 2026, tra le una di notte e le dieci e mezza del mattino, la mia infrastruttura, ospitata su server cloud Infomaniak a Ginevra, quindi interamente su suolo svizzero, ha registrato sei eventi distinti: due scansioni alla ricerca di webshell, un flooding applicativo, un tentativo di clonazione del sito, una scansione di vulnerabilità da parte di un servizio di security intelligence e una ricognizione preliminare. In totale oltre novecento richieste ostili o anomale in meno di dieci ore, distribuite su tre provider cloud diversi.

Il punto che ogni titolare d'azienda ticinese dovrebbe considerare è questo:

quasi certamente il mio dominio non era stato scelto da qualcuno seduto a una scrivania. Era una voce in una lista automatizzata, come lo è in questo preciso momento il sito della tua azienda. La differenza tra chi subisce un danno e chi archivia l'episodio come statistica, o nel mio caso come caso studio, non sta nell'essere o meno un bersaglio ma sta in ciò che l'attaccante trova quando bussa.

E le conseguenze di una porta aperta non sono astratte. Un sito clonato viene usato per fare phishing contro i tuoi clienti con il tuo nome e la tua grafica. Una backdoor installata trasforma il tuo server in una base di lancio per attacchi ad altri, con il tuo indirizzo come mittente e implicazioni legali. Per un'azienda che lavora sulla fiducia e in Ticino la fiducia è la prima valuta, il danno reputazionale supera quasi sempre quello tecnico. Senza contare gli obblighi della nLPD che prevede che una violazione dei dati personali dei clienti non è più solo un problema informatico, ma è un vero e proprio problema legale.

L'errore comune: "siamo troppo piccoli per interessare a qualcuno"

È la frase che si sente più spesso, ed è esattamente il ragionamento su cui contano gli attaccanti. Gli strumenti automatici non valutano il fatturato ma valutano la superficie d'attacco. Anzi, le PMI sono il bersaglio preferito proprio perché statisticamente sono meno protette delle grandi aziende, a parità di valore dei dati che custodiscono, come anagrafiche dei clienti, fatture, contratti, credenziali. Chiunque ha questi dati e ogni attaccante in questi dati ci vede denaro facile.

Il secondo errore, più sottile, è delegare in bianco dicendo:"ho acquistato l'hosting, quindi ci pensa il provider". Un buon hosting svizzero come quello che utilizzo blocca molto, ma non sa nulla del tuo sito WordPress, delle tue configurazioni, dei tuoi plugin, dei tuoi utenti che accedono al sito. La sicurezza del livello applicativo, quello dove vivono i tuoi contenuti e i dati dei tuoi clienti, resta una responsabilità tua. E il terzo errore è anche il più banale, perché nessuno guarda i log.

Gli attacchi del mio caso studio sarebbero stati invisibili a chiunque non avesse un sistema di rilevamento e l'abitudine di analizzare ciò che segnala.

La soluzione corretta: difesa stratificata e risposta documentata

Nessuna delle sei minacce di quella giornata è stata fermata da un singolo strumento miracoloso. Sono state fermate da strati diversi, ciascuno progettato per un tipo diverso di minaccia:

• Un firewall applicativo perimetrale (Cloudflare), che ha bloccato la ricognizione preliminare prima ancora che raggiungesse il server.
• Regole ModSecurity sul server, che hanno riconosciuto e respinto il flooding applicativo in tempo reale.
• Hardening dell'installazione WordPress, che ha fatto sì che le 642 richieste complessive a caccia di backdoor ricevessero soltanto risposte 404, ossia non c'era nulla da trovare.
• Un sistema proprietario di rilevamento della clonazione, che ha generato un alert nel momento esatto in cui uno scraper ha tentato di clonare il sito.
• Un processo di risposta: analisi dei log, identificazione delle origini, segnalazione formale agli abuse desk dei provider coinvolti.

L'ultimo punto merita attenzione perché è quello che quasi nessuno fa. Difendersi è metà del lavoro, ma l'altra metà è rendere conto agli operatori cloud di ciò che parte dalle loro reti di computer.

È un'attività che richiede metodo, documentazione tecnica precisa e pazienza, ma permette di chiudere il cerchio. Infatti trasforma un episodio subìto in un'azione che riduce la capacità offensiva dell'attaccante.

La procedura: cosa è stato fatto, passo dopo passo

La risposta all'incidente ha seguito una sequenza precisa, replicabile per qualsiasi azienda con un presidio di sicurezza adeguato.

• Primo: rilevamento in tempo reale con gli alert generati dai sistemi di monitoraggio e dal rilevamento clonazione.
• Secondo: analisi dei log per ricostruire ogni evento: orari, volumi, indirizzi IP, user agent, percorsi richiesti, distinguendo il traffico ostile da quello legittimo.
• Terzo: verifica dell'impatto, controllando che nessuna richiesta sensibile avesse ricevuto risposta positiva e che nessun accesso fosse stato ottenuto.
• Quarto: attribuzione delle origini tramite i registri pubblici degli operatori di rete.
• Quinto: segnalazione formale agli abuse desk di ciascun provider, con resoconto tecnico circostanziato.
• Sesto: verifica dell'esito e archiviazione della documentazione completa dell'incidente.

Un dettaglio del terzo passaggio dimostra perché l'analisi umana resta indispensabile, infatti una delle sei origini era LeakIX, una piattaforma legittima di security intelligence che indicizza esposizioni pubbliche.

Un sistema di blocco indiscriminato l'avrebbe trattata come un nemico, ma con l'analisi l'ho correttamente classificata come servizio, non da segnalare. Saper distinguere conta quanto saper bloccare.

Il caso concreto: timeline del 23 febbraio 2026

Ecco la cronologia completa della giornata, così come ricostruita dai log dei miei sistemi:

Orario CET	Tipo di attacco	Origine	Esito
01:15–01:19	Scansione webshell, 194 richieste	Microsoft Azure	Tutte le richieste respinte con 404, nessun accesso
01:46–01:51	Scansione webshell, 448 richieste	VPN Consumer Singapore/Panama	Tutte le richieste respinte con 404, nessun accesso
09:14–09:15	Flooding applicativo, 257 richieste in 60 secondi	Microsoft Azure	Bloccato da regola ModSecurity, nessun impatto operativo
10:16	Tentativo di clonazione del sito (scraper mascherato da Chrome)	Microsoft Azure	Rilevato in un secondo dal sistema di rilevamento clonazione
10:36–10:37	Scansione di sicurezza LeakIX (servizio legittimo)	DigitalOcean	Richieste sensibili bloccate; classificato come non malevolo
Non determinato	Ricognizione preliminare (HEAD request)	Vultr	Bloccato da Cloudflare prima di raggiungere il server

Il bilancio tecnico della giornata:

oltre novecento richieste analizzate, zero accessi ottenuti, zero file sensibili serviti, zero impatto operativo. Ogni livello della difesa ha fatto il suo lavoro, e il tentativo più sofisticato, ossia la clonazione mascherata da browser reale, è stato rilevato in un secondo.

Il profilo dell'attaccante

L'analisi incrociata degli eventi ostili ha delineato un quadro coerente:

un singolo soggetto con competenze tecniche intermedie, che ha operato in modo pianificato ma non professionale. Ha iniziato nella notte cercando backdoor già installate da attacchi precedenti, ossia il metodo più opportunistico che esista, e poi ha testato la tenuta del server con un flooding di sessanta secondi, e infine ha tentato la mossa più ambiziosa, ossia clonare il sito simulando un browser Chrome, con l'obiettivo probabile di duplicarlo per phishing o per analisi offline.

Gli errori commessi però lo tradiscono. Ha usato più risorse dello stesso provider cloud nello stesso giorno, rendendo il pattern riconoscibile e segnalabile in modo unitario, I suoi scanner notturni operavano senza user agent, una grossolanità che qualsiasi strumento professionale avrebbe evitato. E lo scraper dichiarava una versione di Chrome che non esiste nemmeno pubblicamente, firma inequivocabile di uno script di automazione configurato male. Trovando porte chiuse a ogni tentativo ha con ogni probabilità abbandonato il bersaglio e proseguito verso il dominio successivo della sua lista.

Le segnalazioni e la conferma di Microsoft

Ogni evento ostile è stato segnalato formalmente all'operatore della rete di provenienza, con documentazione tecnica completa. Questo è l'esito:

Destinatario	Oggetto della segnalazione	Esito
Microsoft Azure Safeguards (CARS)	Tentativo di clonazione del sito	Validata: Microsoft ha confermato la violazione e adottato provvedimenti verso la risorsa responsabile (vedi immagine)
Microsoft Azure Safeguards (CARS)	Scansione webshell e flooding applicativo	In prima analisi rigetatto
Abuse desk VPN Consumer	Scansione webshell ad alto volume	Inviata
Abuse desk Vultr	Ricognizione automatizzata	Inviata

Il risultato più significativo infatti è arrivato a giugno, ossia il team Azure Safeguards di Microsoft ha chiuso il caso relativo al tentativo di clonazione confermando per iscritto che la segnalazione era stata validata e che erano stati adottati provvedimenti appropriati verso la risorsa responsabile.

In altre parole l'analisi indipendente di uno dei più grandi operatori cloud al mondo ha confermato punto per punto la ricostruzione tecnica. Non capita spesso che una segnalazione di abuso superi il vaglio di un hyperscaler, ma quando succede è la certificazione esterna che il lavoro di analisi era corretto.

Vale la pena essere trasparenti anche sul rovescio della medaglia.

Due segnalazioni alla stessa Microsoft, relative a eventi minori della medesima giornata, erano state rigettate in prima analisi.

È la normalità di questo lavoro, perché gli abuse desk ricevono volumi enormi di segnalazioni e applicano filtri severi. Ciò che fa la differenza è la qualità della documentazione e la persistenza del metodo. Una segnalazione validata su un caso sostanziale vale più di dieci segnalazioni archiviate.

Il prossimo passo: l'analisi quotidiana automatizzata con l'AI

Questo caso studio fotografa un presidio analitico già maturo ma la mia direzione è già tracciata.

Sto portando l'intero ciclo, dalla raccolta degli alert, all'analisi dei log, alla classificazione delle minacce e la generazione di reportistica, dentro una pipeline automatizzata.

L'architettura su cui sto lavorando usa n8n come livello di orchestrazione e un modello AI come analista. Ogni giorno il sistema raccoglie i logs e gli alerts delle ventiquattro ore precedenti, li sottopone all'analisi automatica e produce un report che distingue il rumore di fondo dagli eventi che richiedono l'attenzione umana.

Il principio resta quello che ha funzionato il 23 febbraio. L'automazione amplifica l'analisi, non la sostituisce mai. Ed essendo coerenti con ciò che raccomando ai clienti, l'elaborazione avviene su infrastruttura conforme ai requisiti svizzeri di protezione dei dati, perché la sovranità dei dati non è uno slogan di marketing ma è un vincolo di ogni mio progetto. Per le PMI ticinesi questo significherà, in prospettiva, un presidio di sicurezza continuo con un rapporto qualità-costo che fino a ieri era riservato solo alle grandi organizzazioni.

In sintesi

Il 23 febbraio 2026 un'infrastruttura svizzera ospitata a Ginevra ha respinto sei eventi ostili o anomali in meno di dieci ore. Due scansioni alla ricerca di backdoor (642 richieste, tutte respinte), un flooding applicativo (257 richieste in 60 secondi, bloccato da ModSecurity), un tentativo di clonazione del sito (rilevato in un secondo), una ricognizione automatizzata (bloccata dal firewall perimetrale) e una scansione di un servizio legittimo di security intelligence (correttamente classificata come non malevola). Nessun accesso è stato ottenuto, nessun dato è stato esposto, nessuna operatività è stata interrotta. Tutti gli eventi ostili sono stati segnalati agli operatori di rete. Microsoft ha validato la segnalazione relativa al tentativo di clonazione confermando di avere adottato provvedimenti. La lezione per le PMI è che gli attacchi automatizzati colpiscono qualsiasi sito online, indipendentemente dalle dimensioni dell'azienda. E la protezione efficace è una difesa su più livelli unita ad analisi dei logs e a un processo documentato di risposta agli incidenti.

Articoli di approfondimento:

Sicurezza digitale e privacy per le PMI ticinesi: cosa impone la legge

Vuoi sapere cosa succede sul tuo server mentre non guardi?

Il mio programma Swiss Sentinel applica alle PMI ticinesi lo stesso presidio documentato in questo caso studio. Difesa stratificata, monitoraggio continuo, analisi degli incidenti e segnalazione formale agli operatori, su infrastruttura svizzera e nel pieno rispetto della nLPD. Se vuoi capire qual è oggi la superficie d'attacco della tua azienda e come viene presidiata parliamone, perché la prima conversazione serve a valutare la tua situazione reale, non a venderti un pacchetto standard.

Contattami per e-mail su mail@patrickpasquillo.net e parliamo davvero della vostra sicurezza.

Patrick Pasquillo - Digital Collaboration Specialist