Le 10 vulnerabilità che troviamo più spesso nei nostri Penetration Test su aziende italiane

Quando si parla di sicurezza aziendale si immaginano attacchi spettacolari, exploit zero-day, APT cinesi.
La realtà che vediamo ogni settimana nei Penetration Test sui clienti italiani è molto meno cinematografica e molto più ripetitiva. Le aziende vengono compromesse quasi sempre attraverso le stesse identiche vulnerabilità e si tratta quasi sempre di cyber igiene di base mancante.

Abbiamo provato a riassumere le dieci che incontriamo più spesso, con esempi concreti del tipo di scenari che ci capita di vedere durante i test.

Non sono i casi specifici di un cliente — quelli restano coperti da NDA — ma il tipo di configurazione che si ripete con frequenza nelle PMI e nelle mid-market italiane.

1. MFA assente, parziale, o pieno di “eccezioni operative”
2. Servizi di management esposti su Internet
3. Appliance perimetrali non patchate
4. Password deboli, riusate, di default
5. Active Directory: la miniera d’oro
6. Segmentazione di rete cosmetica
7. Permessi su file share e SharePoint fuori controllo
8. Email security non configurata
9. Backup raggiungibili, mal segregati, mai testati
10. Logging e monitoraggio: il silenzio nei nostri test

MFA assente, parziale, o pieno di “eccezioni operative”

• Outlook Web Access.
• Username del CFO recuperata in 30 secondi da LinkedIn.
• Password tentata: Password2026!.
• Login al primo colpo, nessun secondo fattore richiesto, accesso completo alla casella.

È così che cominciano la metà delle nostre catene di attacco esterno.
Il pattern più frequente non è l’assenza totale di MFA, ma la sua applicazione disomogenea: il CEO ne è “temporaneamente” esente perché viaggia, gli account di servizio non lo hanno per definizione, le mailbox condivise sono dimenticate, gli amministratori IT hanno una policy meno restrittiva “per gestire le emergenze”.

Ogni eccezione è una via d’ingresso documentata da Conditional Access che nessuno legge più.

Fix concreto: MFA obbligatorio su tutti gli account, comprese le shared mailbox (con accesso delegato, non credenziali condivise); Conditional Access che blocchi login da paesi non operativi; token hardware (FIDO2) per gli amministratori.

Servizi di management esposti su Internet

Una scansione del perimetro pubblico produce quasi sempre risultati immediati.

• Porta 3389 aperta su qualche IP;
• console VMware ESXi raggiungibile su 443 con certificato self-signed scaduto;
• NAS Synology esposto “perché serviva per accedere da casa nel 2020”;
• VPN SSL di un firewall dismesso ma mai spento;
• interfaccia web del controller WiFi accessibile pubblicamente.

Sono superfici d’attacco bersagliate ogni giorno da scanner automatici globali (Shodan, Censys, le botnet di ricognizione). Bastano credenziali deboli o una CVE non patchata e l’accesso iniziale è fatto.

Fix concreto: scansione ricorrente del proprio range pubblico (interna o tramite servizio di External Attack Surface Management); censimento documentato di tutti gli esposti con un owner per ciascuno; accesso ai servizi di management esclusivamente via VPN o ZTNA con MFA.

Appliance perimetrali non patchate

Negli ultimi due anni i vettori di compromissione iniziale più sfruttati a livello globale sono stati vulnerabilità su appliance perimetrali:

1. Fortinet (CVE-2023-27997, CVE-2024-21762)
2. Citrix NetScaler (CitrixBleed, CVE-2023-4966)
3. Ivanti Connect Secure (CVE-2024-21887 e seguito)
4. SonicWall SMA.

Sono dispositivi che restano in produzione per anni e che spesso non hanno un piano di aggiornamento sistematico.
Lo schema tipico: l’avviso del vendor arriva, viene letto da una persona che non ha autorità di pianificare il fermo, il ticket viene aperto, finisce in coda dietro le richieste di business. Per quando l’aggiornamento è schedulato, l’exploit pubblico è in giro da mesi.

Fix concreto: SLA formale di 7 giorni per patch critiche su appliance esposte, con escalation diretta al management; iscrizione ai feed PSIRT dei propri vendor e ai bollettini ACN; verifica periodica della superficie tramite servizi di Cyber Threat Intelligence.

Password deboli, riusate, di default

La prima wordlist che proviamo in un password spraying non è cracking sofisticato: è la combinazione {nomeazienda}+stagione+anno+!.

Funziona più spesso di quanto vorremmo ammettere. Subito dopo proviamo le credenziali aziendali presenti nei dump pubblici (Have I Been Pwned, Cit0day, Combolist degli ultimi anni): in molti casi sono identiche a quelle attive sull’home banking corporate o sulla VPN.

A questo si aggiungono le credenziali “operative” mai cambiate dal go-live: il videoregistratore della videosorveglianza con admin/admin, la multifunzione con la password sul retro, il gestionale on-prem con la credenziale del primo amministratore che era andato in pensione nel 2018, l’access point con la password del SSID stampata su un’etichetta in sala riunioni.

Fix concreto

• password manager aziendale obbligatorio
• passphrase lunghe (16+ caratteri) sugli account utente
• password di 12+ caratteri sui service account
• monitoraggio dark web delle credenziali del dominio
• audit annuale delle credenziali di default su tutti i device di rete e IoT.

Active Directory: la miniera d’oro

Una volta atterrati sulla rete interna — anche con un solo account utente standard — l’Active Directory si trasforma in un campo aperto.
Pochi minuti di Kerberoasting estraggono gli hash di tutti gli account di servizio con SPN; bastano una GPU consumer e una wordlist mirata per crackarne offline una parte significativa in poche ore.

La password dell’account svc_sql resa in mezza giornata — e quello stesso account ha permessi inutilmente ampi su tre server diversi.
Poi: cpassword nelle GPO Preferences (ancora oggi, nel 2026, in archivi storici mai bonificati), cifrato con una chiave pubblica di Microsoft nota dal 2014; gruppo Domain Admins con 27 membri di cui 22 inattivi da anni; deleghe Kerberos non vincolate su server pubblicati; AdminCount = 1 dimenticato su utenze ormai standard. Una mappa BloodHound trasforma tutto questo in un percorso visivo dall’utente di reception al Domain Admin in 4-5 hop.

Fix concreto

• tier model degli amministratori (T0/T1/T2 con account separati);
• rotazione automatica delle password dei service account con soluzioni dedicate (gMSA dove possibile);
• audit periodico con PingCastle e BloodHound;
• LAPS per gli amministratori locali;
• bonifica delle GPO storiche.

Segmentazione di rete cosmetica

• Dal WiFi degli ospiti riusciamo a “vedere” i server più importanti dell’azienda.
• Dalla rete dell’amministrazione raggiungiamo i macchinari della produzione.
• Dalla postazione dell’ufficio acquisti arriviamo al server dei backup.

Quando la rete è davvero piatta, un attaccante non ha bisogno di tecniche sofisticate per spostarsi: gli basta camminare da un sistema all’altro.

In molte aziende la “segmentazione” esiste sulla carta — VLAN definite, schemi di rete ordinati, documenti di policy — ma mancano i firewall interni che facciano davvero rispettare quelle regole.
I protocolli usati per la gestione dei sistemi Windows girano liberi tra zone che dovrebbero essere isolate.

La rete della produzione (PLC, macchinari, SCADA) è quasi sempre la più trascurata: raggiungibile dalla rete uffici come se fosse una semplice estensione della LAN, in modi che farebbero rabbrividire qualunque auditor industriale.

Fix concreto: firewall interno con regole esplicite tra le zone, evitando configurazioni “qualsiasi cosa verso qualsiasi cosa”; isolamento delle macchine critiche (Domain Controller, backup, ERP); rete della produzione completamente separata, con una zona di interscambio dedicata e accessi controllati; verifica periodica delle regole con test reali, non solo riletture documentali.

Permessi su file share e SharePoint fuori controllo

Cartella di rete \\fileserver01\Direzione, accessibile da un dipendente neoassunto del reparto marketing (non abbiamo scelto questo reparto per un motivo specifico).
Dentro: piani industriali, accordi di acquisizione in corso, contratti con i fornitori chiave.
Cartella \\fileserver01\HR accanto: buste paga di tutti i dipendenti, scansioni di carte d’identità, contratti di lavoro. Nessuno se n’era accorto perché nessuno aveva mai controllato chi accedesse a cosa.

Su SharePoint la situazione è ancora peggiose a gestirla non ci sono professionisti preparati.
I permessi vengono ereditati di sottocartella in sottocartella senza che nessuno li riveda dall’attivazione del tenant; la condivisione “tramite link a chiunque” è disabilitata nelle policy ma riabilitata per singole “eccezioni” che poi nessuno chiude mai.

Il vecchio file Password_Servizi.xlsx resta indicizzato dal motore di ricerca interno: una query con parole come “password” o “vpn” restituisce quasi sempre qualcosa di prezioso.

Fix concreto: revisione periodica dei permessi su tutti i file server e su SharePoint, applicazione rigorosa del principio “solo chi deve sapere”;
rimozione del gruppo Everyone e degli accessi anonimi; classificazione dei dati sensibili con Microsoft Purview o equivalenti; alert quando qualcuno accede a directory marcate come riservate.

Email security non configurata

Bastano pochi secondi per scoprire come è configurato il dominio email di un’azienda.
Troppo spesso troviamo che le tre tecnologie che dovrebbero impedire ai malintenzionati di falsificare il mittente — SPF, DKIM e DMARC — sono assenti o configurate in modalità “avviso”, che di fatto non blocca nulla.
A quel punto, da qualsiasi connessione Internet, possiamo inviare un’email che sembra arrivare dall’Amministratore Delegato dell’azienda al CFO, con oggetto “Bonifico urgente”.

L’email arriva. Non in spam: in posta in arrivo.
Il banner che dovrebbe segnalare visibilmente le email esterne? Spesso disattivato, “perché confondeva gli utenti”.
È il prerequisito perfetto per ogni truffa di tipo CEO fraud e per ogni falso “cambio IBAN” inviato a un fornitore.
Le aziende italiane stanno perdendo cifre a sei zeri proprio con questi schemi e la difesa costa il prezzo di pochi record DNS configurati come si deve.

Fix concreto: SPF in modalità bloccante; DKIM con chiavi crittografiche aggiornate; DMARC in modalità “rifiuta”, preceduto da un periodo di monitoraggio per non perdere email legittime; banner “Esterna” attivo su tutte le mail provenienti dall’esterno; attivazione di un sistema di protezione anti-phishing avanzato.

Backup raggiungibili, mal segregati, mai testati

Il server dei backup è membro dello stesso dominio Windows dell’azienda.
L’account che lo gestisce ha la stessa password — non per distrazione, per “comodità operativa” — dell’account dell’amministratore IT.
Le copie di sicurezza vengono salvate sullo stesso storage dei dati di produzione. La replica “esterna” è una cartella condivisa su un NAS in un altro ufficio della stessa azienda, raggiungibile dalla rete come qualunque altra cartella. Per un ransomware tutto questo non è un backup: sono dati di produzione raddoppiati, e cifrabili tutti insieme.

C’è poi un punto che emerge solo quando si prova davvero a ripristinare i dati. In molte aziende i backup risultano “verdi” sulla console di controllo, ma quando si tenta un restore reale — su un sistema vuoto, simulando il giorno dopo un attacco — non funzionano: qualcosa si era rotto silenziosamente mesi prima e nessuno lo aveva notato.

Fix concreto: applicare la regola 3-2-1-1-0 (tre copie dei dati, su due supporti diversi, una fuori sede, una offline o resa immodificabile, zero errori nei test di ripristino); usare repository immutabili che impediscano la modifica dei file di backup (S3 Object Lock, Veeam Hardened Repository, Azure Immutable Blob); separare completamente gli account di gestione backup dal dominio di produzione; attivare l’autenticazione a due fattori sulla console di backup; testare il ripristino dei dati ogni trimestre — davvero, non solo formalmente.

Logging e monitoraggio: il silenzio nei nostri test

Durante un test interno alziamo gradualmente il “rumore” delle nostre azioni: prima ricognizione silenziosa, poi attiva, poi esecuzione di strumenti che un attaccante reale userebbe per estrarre credenziali e muoversi nella rete, infine il trasferimento di un file di prova verso un nostro server esterno.
Nel debrief con il cliente chiediamo: “Avete visto qualcosa?”. La risposta tipica è: “Abbiamo i log, ma dove dovevamo guardare?”.

I log esistono, ma sono sparpagliati su decine di sistemi diversi.
La conservazione degli eventi di sicurezza su Windows è quella di default — pochi giorni — perché lo spazio disco non è mai stato dimensionato anche per la sicurezza.
L’antivirus aziendale è stato disinstallato dai server “perché rallentava gli applicativi”.

Non c’è un sistema centrale che raccolga i log, non c’è chi li guardi, non ci sono regole automatiche che facciano scattare un allarme quando succede qualcosa di anomalo. Quando arriverà un attacco vero, l’analisi forense partirà letteralmente da zero — e in molti casi non si arriverà mai a capire da dove l’attaccante sia entrato né cosa abbia portato via.

Fix concreto: un sistema centralizzato di raccolta e analisi dei log; regole di allarme prioritarie su accessi anomali, esecuzione di strumenti sospetti, accessi a cartelle riservate; conservazione dei log di sicurezza per almeno 12 mesi; valutazione di un servizio di Security Operation Center gestito (MDR) per le realtà che non possono permettersi un team interno H24.

Il filo rosso non è tecnico, è organizzativo.
Queste vulnerabilità si accumulano quando in azienda manca una funzione dedicata a rilevarle: l’IT manager è impegnato a tenere in piedi i servizi quotidiani e non ha tempo per la sicurezza proattiva, i fornitori spesso lasciano in piedi le configurazioni di default, i progetti vengono chiusi senza una verifica finale sul piano della sicurezza, le eccezioni nate come temporanee diventano permanenti.

Un Penetration Test o un Vulnerability Assessment con intervento manuale dell’analista fatto bene non serve a produrre un report che finirà archiviato in una cartella. Serve a costruire una lista di priorità di intervento condivisa tra IT e management, basata su evidenze reali. E in un quadro in cui la NIS2 chiede di dimostrare l’efficacia delle misure di sicurezza, sapere davvero cosa c’è nei propri sistemi — non quello che si presume di avere — è il punto di partenza non negoziabile.