--- title: "Attacco hacker in corso: cosa fare e come risolverlo" description: Scopri come gestire un attacco informatico, contenere i danni e ripristinare i sistemi aziendali in modo efficace e strategico. image: https://blog.cyberoo.com/hubfs/Cyberoo%20Blog%20-%20Grafiche%20di%20copertina%20(5)-4.gif --- - Solutions Threat Management - [Cos’è la Cyber Security Suite?](https://cyberoo.com/cyber-security-suite/) - [Cypeer – Sicurezza interna](https://cyberoo.com/managed-detection-and-response/) - [CSI – Protezione dalle minacce esterne](https://cyberoo.com/cyber-threat-intelligence/) Governance & Processes - [Incident response](https://cyberoo.com/incident-response/) - [Risk Assessment](https://cyberoo.com/risk-assessment/) - [Vulnerability Assessment & Penetration Test](https://cyberoo.com/vulnerability-assessment-penetration-test/) - [Cyber Security Advisory & vCISO](https://cyberoo.com/cyber-security-advisory-vciso/) Compliance - [Titaan Neemesi – GDPR compliance](https://cyberoo.com/titaan-neemesi-gdpr-compliance/) People Security - [KEATRIX – Human Risk & Security TrAIning Platform per Aziende](https://cyberoo.com/keatrix-security-awareness-platform-business-ita/) - Corporate Cyberoo - [Azienda](https://cyberoo.com/cyberoo-azienda-italiana-cybersecurity/) - [Certificazioni](https://cyberoo.com/certificazioni/) - [People](https://cyberoo.com/people-team-cyberoo/) - [Above The Rest](https://cyberoo.com/above-the-rest/) - [Jobs](https://cyberoo.com/jobs/) Investors - [Investors relations](https://cyberoo.com/investors-relations/) - [Sostenibilità](https://cyberoo.com/sostenibilita/) - Resources - [Cyber Resources](https://cyberoo.com/cyber-resources/) - [Cyber Blog](https://blog.cyberoo.com/) - [Tech Blog](https://cert.cyberoo.com/) - [Press News](https://cyberoo.com/news-press/) - [Media Kit](https://cyberoo.com/media-kit/) [![Cyberoo](https://blog.cyberoo.com/hubfs/raw_assets/public/Cyberoo_May2023/images/CYBEROO-logo.svg)](https://cyberoo.com/) - [Contatti](https://cyberoo.com/contacts/) - Italiano - [English](https://blog.cyberoo.com/en) - [Français](https://cyberoo.com/fr/) - [Deutsch](https://cyberoo.com/de/) - [Polski](https://blog.cyberoo.com/pl) - [Español](https://cyberoo.com/es/) - Solutions - Threat Management - [Cos’è la Cyber Security Suite?](https://cyberoo.com/cyber-security-suite/) - [Cypeer – Sicurezza interna](https://cyberoo.com/managed-detection-and-response/) - [CSI – Protezione dalle minacce esterne](https://cyberoo.com/cyber-threat-intelligence/) - Governance & Processes - [Incident response](https://cyberoo.com/incident-response/) - [Risk Assessment](https://cyberoo.com/risk-assessment/) - [Vulnerability Assessment & Penetration Test](https://cyberoo.com/vulnerability-assessment-penetration-test/) - [Cyber Security Advisory & vCISO](https://cyberoo.com/cyber-security-advisory-vciso/) - Compliance - [Titaan Neemesi – GDPR compliance](https://cyberoo.com/titaan-neemesi-gdpr-compliance/) - People Security - [KEATRIX – Human Risk & Security TrAIning Platform per Aziende](https://cyberoo.com/keatrix-security-awareness-platform-business-ita/) - Corporate - Cyberoo - [Azienda](https://cyberoo.com/cyberoo-azienda-italiana-cybersecurity/) - [Certificazioni](https://cyberoo.com/certificazioni/) - [People](https://cyberoo.com/people-team-cyberoo/) - [Above The Rest](https://cyberoo.com/above-the-rest/) - [Jobs](https://cyberoo.com/jobs/) - Investors - [Investors relations](https://cyberoo.com/investors-relations/) - [Sostenibilità](https://cyberoo.com/sostenibilita/) - Resources - [Cyber Resources](https://cyberoo.com/cyber-resources/) - [Cyber Blog](https://blog.cyberoo.com/) - [Tech Blog](https://cert.cyberoo.com/) - [Press News](https://cyberoo.com/news-press/) - [Media Kit](https://cyberoo.com/media-kit/) - [Contatti](https://cyberoo.com/contacts/) - Italiano - [English](https://blog.cyberoo.com/en) - [Français](https://cyberoo.com/fr/) - [Deutsch](https://cyberoo.com/de/) - [Polski](https://blog.cyberoo.com/pl) - [Español](https://cyberoo.com/es/) - - - - - ![](https://blog.cyberoo.com/hubfs/Cyberoo%20Blog%20-%20Grafiche%20di%20copertina%20(5)-4.gif) # Attacco hacker in corso: cosa fare e come risolverlo Published by [Andrea Coli - Incident Response Manager](https://blog.cyberoo.com/author/andrea-coli) on 12 novembre 2026 #### Ascolta l'articolo « » 0:00 0:00 1x 1.5x 2x Il tuo browser non supporta l'audio.   Che cosa succede quando un **attacco informatico** ferma un’azienda? I file diventano inaccessibili, l’ERP si blocca, produzione e logistica si fermano e le consegne si accumulano. Bisogna capire che cosa sta succedendo e decidere quali sistemi isolare mentre le persone attendono risposte e l’incertezza comincia a pesare. Ad esempio, un attacco ransomware può rendere molto visibili queste conseguenze. **La cifratura però è soltanto l’ultima fase di un’intrusione**. Prima possono esserci stati accessi abusivi, sottrazione di dati e l’installazione di meccanismi per riaccedere nei sistemi. Da dove si comincia? Dall’**attivazione del team incaricato alla gestione degli incidenti** e dal **contenimento del danno**. Le prime informazioni sono determinanti per chiarire quali sistemi sono coinvolti e quali attività aziendali sono a rischio. Analisi, autorizzazioni e priorità di ripristino devono procedere insieme e in modo coordinato. Chi ha affrontato il percorso di [conformità alla NIS2](https://blog.cyberoo.com/direttiva-nis2-stato-dellarte-2026-e-scadenze-operative-da-rispettare) o la certificazione ISO/IEC 27001 sa che analisi dei rischi e business impact analysis servono a collegare i processi aziendali ai sistemi informatici che li sostengono. Anche la [categorizzazione di attività e servizi richiesta da ACN](https://www.acn.gov.it/portale/nis/categorizzazione) ha imposto ai soggetti essenziali ed importanti di individuare i processi strategici per il business. Sono proprio questi gli elementi che indicano che cosa deve tornare in esercizio per primo e in quali tempi. Eppure, in molte aziende la risposta si arena nelle prime fasi. Manca la mappatura tra processi e sistemi, nessuno ha stabilito a monte che cosa è prioritario e parametri come **MTPD (o MTO), RTO e RPO** non sono mai stati definiti. Così le decisioni sulla ripartenza vengono prese sotto pressione e nel momento peggiore per farlo.   # Un caso concreto Nel caso che ti racconto l'accesso iniziale avviene attraverso una **VPN senza autenticazione multifattore** assegnata ad un fornitore. L’attività DFIR ha determinato che il consulente lavorava abitualmente con un computer personale sprovvisto di EDR e le credenziali dei suoi clienti erano conservate localmente su file. **Un infostealer** (un malware che sottrae credenziali e spesso anche i cookie di sessione), le ha esfiltrate: in pochi istanti **decine di credenziali VPN** di altrettante aziende sono state compromesse. Ottenuto l’accesso gli attaccanti esplorano la rete, recuperano le credenziali dall'ambiente di virtualizzazione, individuano i backup, sottraggono i dati e avviano la cifratura dei file delle macchine virtuali. Le conseguenze sono pesanti: **giorni di fermo produttivo**, cassa integrazione e penali per le consegne mancate.   # Attacco in corso: che cosa fare subito Se più persone in azienda segnalano problemi su sistemi diversi, bisogna dare l’allarme e ingaggiare il responsabile della gestione degli incidenti (**IR Manager**). Malfunzionamenti diffusi non indicano per forza un attacco, ma vanno trattati come un possibile incidente finché non si dimostra il contrario. La prima cosa da capire in pochissimo tempo è la natura dell’evento: incidente cyber o problema di altra origine come un guasto sistemistico o di rete? Procedure e catena di comando devono chiarire chi analizza gli eventi, chi decide e chi interviene sui sistemi. Servono contatti utilizzabili anche fuori orario, un’adeguata copertura contrattuale con i fornitori (es. system integrator) e priorità legate ai processi che l’azienda deve mantenere operativi. Tutti questi elementi dovrebbero essere già documentati nell’**Incident Response Plan**. Per iniziare servono informazioni verificabili: quale anomalia è stata osservata? A che ora? Su quali sistemi e con quali effetti? Cosa fare in pratica: - **Coordinamento**: individuare un referente unico per la gestione dell’incidente e coinvolgere staff IT, direzione, punto di contatto e referente CSIRT (se l’organizzazione è un soggetto NIS), DPO, risorse umane, comunicazione e supporto legale. - **Segnalare**: raccogliere orari, messaggi di errore, sistemi interessati e riferimenti degli alert. Acquisizioni e analisi spettano ai tecnici: chi segnala non deve riavviare, cancellare file o intervenire di propria iniziativa. - **Contenere**: isolare dalla rete i sistemi coinvolti evitando per quanto possibile di spegnerli, e bloccare gli accessi abusivi valutando l’impatto sui servizi essenziali. - **Conservare**: coordinare la raccolta delle evidenze con il contenimento prima che reinstallazioni e ripristini le sovrascrivano. - **Comunicazione**: stabilire un canale affidabile e un referente per gli aggiornamenti verso clienti, fornitori e personale. Se gli strumenti aziendali sono compromessi o c’è il dubbio che lo siano, si passa ad un canale alternativo concordato in anticipo. Aspettare di avere ricostruito ogni dettaglio mentre l’attacco continua può aumentare il danno. La risposta richiede azioni tempestive e tracciabilità.   # Contenere l’attacco Il contenimento serve a impedire all’attaccante di continuare a operare. Nel caso della VPN il primo passo è **intervenire sull’accesso compromesso** e poi verificare fin dove l’attaccante sia arrivato: il sistema da cui è partito l’allarme può essere solo una parte dell’incidente. Le azioni tipiche sono l’isolamento dalla rete dei sistemi coinvolti, la disabilitazione degli account compromessi e la revoca delle sessioni attive. **Cambiare la password non basta**: token e sessioni già aperte possono restare validi e vanno revocati in modo specifico. Il team deve poi verificare che gli accessi siano davvero interrotti tenendo conto che ogni sistema ha tempi e meccanismi di revoca propri. In parallelo si cercano altre tracce della compromissione: account creati dall’attaccante, privilegi modificati, accessi anomali e meccanismi di persistenza. I sistemi di virtualizzazione e di backup vanno controllati anche quando non ci sono ancora prove dirette del loro coinvolgimento: se l’attaccante aveva le credenziali per raggiungerli o se la loro criticità lo giustifica. Quando isolare un sistema non è possibile e bisogna fermare la propagazione dell’attacco, il team di risposta può decidere di **spegnere i dispositivi interessati**. È una scelta di responsabilità poiché lo spegnimento cancella il contenuto della memoria volatile, utile all’indagine. Per i sistemi da cui dipendono la produzione o servizi critici, ogni azione di contenimento va coordinata con la continuità operativa e con la sicurezza delle persone. Il piano di risposta deve indicare anche chi autorizza tali decisioni.   # Conservare le evidenze per capire che cosa è successo Durante l’emergenza viene spontaneo pensare subito al ripristino: rimettere in funzione il server, recuperare gli applicativi, riaprire gli accessi vpn, ecc. Prima di reinstallare o ripristinare però, bisogna **mettere al sicuro le informazioni** che servono a ricostruire l’attacco e questo non significa rimandare il contenimento. Le fonti principali sono i log di autenticazione, gli eventi degli endpoint, i registri degli accessi remoti e i log di firewall e proxy. Insieme permettono di ricostruire da dove è entrato l’attaccante, quali account ha usato, quali sistemi ha raggiunto e se ha esfiltrato dati. Per ogni acquisizione si registrano origine, data e ora e chi l’ha eseguita, e si **calcola l’hash** per dimostrare che la copia non è stata alterata. Accanto alle evidenze serve un **“diario” dell’incidente**, con decisioni, autorizzazioni, azioni ed effetti osservati. La cronologia ricostruita in questa fase ha anche un uso pratico immediato: indica da quando l’attaccante era presente nell’ambiente, e quindi quali backup possono contenere le sue tracce.   # Come si risolve un incidente La bonifica (eradication) elimina ciò che ha reso possibile l’intrusione e ciò che l’attaccante ha lasciato nell’ambiente per mantenerne il controllo. Il ripristino (recovery) riporta i servizi in esercizio ma solo dopo le verifiche necessarie. Nel caso esaminato, recuperare i file avrebbe risolto solo una parte del problema: restavano gli accessi remoti, i privilegi eccessivi, le postazioni poco protette e i backup vulnerabili. La bonifica deve chiudere il vettore d’ingresso, rimuovere gli accessi abusivi e verificare tutti i sistemi coinvolti. ### **Le persistenze finiscono anche nei backup** Un backup disponibile è un punto di partenza, non la prova che l’ambiente sia pronto a ripartire. Le copie offline o immutabili garantiscono che i dati ci siano ancora ma non dicono nulla su che cosa contengono. Se l’attaccante è rimasto nella rete per giorni o settimane prima della cifratura, i backup di quel periodo contengono anche ciò che ha installato per rientrare: account creati o modificati, attività pianificate, servizi e chiavi di avvio automatico, strumenti di accesso remoto, web shell, modifiche ai criteri di gruppo. **Ripristinare un server da una copia di questo tipo significa rimettere in esercizio anche la porta d’ingresso.** ### **Analizzare i server ripristinati prima di ricollegarli** Una volta ripristinati i server andranno analizzati in un ambiente isolato senza collegamento alla rete compromessa né a Internet. Le verifiche principali consistono in: 1. **Punto di ripristino:** scegliere in base alle esigenze aziendali tenendo presente la data con la cronologia dell’intrusione che spesso precede di molto la cifratura 2. **Persistenze:** cercare account, attività pianificate, servizi, programmi in avvio automatico, software di accesso remoto e file sospetti, usando soprattutto gli indicatori di compromissione (ioc) emersi dall’indagine 3. **Identità:** reimpostare le credenziali compromesse anche sui sistemi ripristinati ed eseguire il doppio reset di krbtgt nel domain controller secondo procedura 4. **Patch e configurazioni:** correggere eventuali vulnerabilità e configurazioni sfruttate prima di ricollegare il sistema 5. **Monitoraggio:** ricollegare i sistemi gradualmente con strumenti di rilevamento attivi e una sorveglianza più stretta nelle settimane successive. ### **Ripartire per passaggi verificabili** Le priorità di ripartenza le decidono la direzione e i responsabili dei processi insieme al team tecnico. Si parte dalle applicazioni indispensabili per lavorare e dai servizi da cui dipendono seguendo le priorità e i tempi definiti nella business impact analysis. Prima di rimettere in esercizio ogni sistema vanno confermati tre elementi: **bonifica completata, vettore d’ingresso chiuso, controlli di sicurezza attivi**. Il ritorno all’operatività procede per gradi e con i sistemi ripristinati sotto monitoraggio.   # Chi decide e chi comunica La catena di comando serve ad autorizzare gli isolamenti, scegliere le priorità di ripristino e tenere informati i reparti. Funziona se le informazioni circolano nei due sensi: chi analizza l’attacco deve conoscere le conseguenze operative di ogni intervento e chi guida l’azienda deve ricevere elementi sufficienti per decidere. Un aggiornamento utile distingue sempre tre cose: **ciò che sappiamo, ciò che stiamo verificando e quale sarà il prossimo passaggio**. Lo stesso criterio vale verso dipendenti, clienti e partner. Le comunicazioni vanno coordinate da un unico referente riportando solo i fatti confermati e senza diffondere dettagli che potrebbero ostacolare la risposta. Il caso del consulente esterno rende concreta anche la questione dei fornitori. Prima di dare istruzioni o concedere accessi a un fornitore conviene **verificarne l’identità attraverso un canale indipendente** perché proprio i suoi strumenti potrebbero essere compromessi. Nella ricostruzione vanno considerati anche gli account e i dispositivi delle terze parti: l’analisi non si ferma al confine della rete aziendale. C’è infine un aspetto che riguarda gli altri clienti del fornitore. Se le credenziali sono state sottratte da un dispositivo che ne conteneva molte, il rischio non riguarda solo l’azienda attaccata: va chiesto al fornitore di verificare ad esempio i suoi sistemi informatici e di avvisare i clienti potenzialmente a rischio compromissione.   # Notifiche: verificare gli obblighi Gestione tecnica e notifiche procedono in parallelo. L'[articolo 25 del D.Lgs. 138/2024](https://www.gazzettaufficiale.it/eli/id/2024/10/01/24G00155/SG) prevede senza ingiustificato ritardo, una **pre-notifica al CSIRT Italia entro 24 ore** dalla conoscenza dell'incidente significativo e una **notifica entro 72 ore** dallo stesso momento. La **relazione finale va inviata entro un mese dalla notifica**. Se l'incidente è ancora in corso occorrono relazioni mensili sui progressi e una finale entro un mese dalla conclusione della gestione. Il GDPR richiede una valutazione distinta: una violazione di dati personali può compromettere riservatezza, integrità o disponibilità anche senza esfiltrazione accertata. Il titolare notifica all'autorità di controllo competente senza ingiustificato ritardo **entro 72 ore dalla conoscenza**, salvo che sia improbabile un rischio per i diritti e le libertà delle persone. Il responsabile del trattamento informa il titolare senza ingiustificato ritardo. Se la violazione può presentare un rischio elevato per i diritti e le libertà delle persone, il titolare deve comunicarla agli interessati senza ingiustificato ritardo, salvo le eccezioni dell'articolo 34 del GDPR. Tutte le violazioni di dati personali vanno documentate. **La notifica al CSIRT Italia non sostituisce quella eventualmente dovuta ai sensi del GDPR** e va valutata anche la denuncia alla Polizia Postale.   # Dopo l’emergenza Quando i servizi ripartono la tentazione è chiudere il capitolo. Proprio a quel punto l'analisi deve diventare un **piano di lavoro**: problema individuato, intervento da completare, responsabile e verifica del risultato. Nel caso che abbiamo esaminato, la remediation ha riguardato queste misure: - **Accessi:** account dedicati per ciascun fornitore, privilegi minimi, accesso abilitato solo quando serve e da dispositivi gestiti, requisiti di sicurezza nei contratti e predisposizione di jump server confinati in segmenti di rete con policy di attraversamento puntuali gestite da firewall. MFA per vpn, posta elettronica e sistemi critici - **Separazione:** credenziali di gestione distinte dal dominio, protette con MFA e amministrazione privilegiata organizzata per livelli - **EDR:** per rilevare e analizzare comportamenti sospetti sugli endpoint - **Password manager:** per gestire le credenziali con strumenti dedicati - **Backup 3-2-1-1-0:** tre copie dei dati, su due supporti diversi, una fuori sede e una offline o immutabile. Test di ripristino periodici per verificare l’effettiva recuperabilità. L’architettura di backup va gestita con credenziali separate dal dominio - **Segmentazione della rete:** per limitare la possibilità di spostarsi tra sistemi - **Monitoraggio continuo MDR:** monitoraggio dell’infrastruttura h24 365gg per rilevamento, analisi e risposta alle minacce. Essenziale per prevenire lo sviluppo di un’azione offensiva.   # Ripartire sapendo che cosa è stato risolto Il caso della VPN collega direttamente una credenziale rubata al fermo aziendale. La risposta deve interrompere quel percorso eradicando ciò che l'attaccante ha lasciato anche nei backup e correggerne le cause. La capacità di reagire si costruisce collegando ciò che spesso viene gestito separatamente. **Monitoraggio, analisi, decisioni, interventi tecnici, comunicazione e obblighi normativi devono far parte dello stesso lavoro.** Prima di chiudere l'incidente occorre verificare che ogni correzione abbia un responsabile e un criterio con cui controllarne l'esito. Alla prossima anomalia sapere chi deve fare cosa sarà utile quanto riconoscere tempestivamente i segnali di una potenziale compromissione. ![Andrea Coli - Incident Response Manager](https://blog.cyberoo.com/hs-fs/hubfs/Speaker%20webinar%20(8).png?width=96&height=96&name=Speaker%20webinar%20(8).png) [**Andrea Coli - Incident Response Manager**](https://blog.cyberoo.com/author/andrea-coli) Incident Response Manager, Cyberoo   Tags: [Governance & Processes](https://blog.cyberoo.com/tag/governance-processes) [Back to Blog](https://blog.cyberoo.com) - [Tweet](https://twitter.com/share) [![Cyberoo](https://blog.cyberoo.com/hubfs/raw_assets/public/Cyberoo_May2023/images/CYBEROO-logo.svg "Cyberoo")](https://blog.cyberoo.com/) **TRUSTED BY USERS** [![Capterra](https://blog.cyberoo.com/hubfs/raw_assets/public/Cyberoo_May2023/images/a0e3aa33abf348490d739e99e692012d.svg "Capterra")](https://www.capterra.com/reviews/206253/Cyber-Security-Suite?utm_source=vendor&utm_medium=badge&utm_campaign=capterra_reviews_badge) ![Gartner Peer](https://blog.cyberoo.com/hubfs/raw_assets/public/Cyberoo_May2023/images/GartnerPeerInsightsLogo-white.svg "Gartner Peer") - SERVICES - [CYPEER](https://cyberoo.com/en/managed-detection-and-response/) - [CSI](https://cyberoo.com/en/threat-intelligence/) - [INCIDENT RESPONSE](https://cyberoo.com/en/incident-response/) - [TITAAN NEEMESI](https://cyberoo.com/en/titaan-neemesi/) - [KEATRIX](https://cyberoo.com/en/keatrix-security-awareness-training/) - LINK UTILI - [WE ARE CYBEROO](https://cyberoo.com/azienda/) - [INVESTORS RELATIONS](https://cyberoo.com/investors-relations/) - [CYBER RESOURCES](https://cyberoo.com/cyber-resources/) - [BLOG](https://blog.cyberoo.com/) - [NEWS](https://cyberoo.com/news-press/) - [CONTACTS](https://cyberoo.com/contacts/) © 2026 CYBEROO. Sede Legale: via Brigata Reggio, 37 – 42124 Reggio Emilia (RE) – PEC amministrazione@pec.cyberoo.com Capitale sociale € 1.035.432,35 i.v. Cod. fiscale e P.IVA 04318950286 – R.E.A. RE 288453 [Privacy Policy](https://cyberoo.com/privacy-policy/) - [Registro Nazionale degli Aiuti di Stato](https://www.rna.gov.it/RegistroNazionaleTrasparenza/faces/pages/TrasparenzaAiuto.jspx) - ISO27001 - - - ```json { "@context" : "https://schema.org", "@type" : "BlogPosting", "author" : { "@type" : "Person", "name" : "Andrea Coli - Incident Response Manager", "url" : "https://blog.cyberoo.com/author/andrea-coli" }, "dateModified" : "2026-11-12T08:59:10.962Z", "datePublished" : "2026-11-12T08:59:10.000Z", "headline" : "Attacco hacker in corso: cosa fare e come risolverlo", "image" : [ "https://blog.cyberoo.com/hubfs/Cyberoo%20Blog%20-%20Grafiche%20di%20copertina%20(5)-4.gif" ], "mainEntityOfPage" : { "@id" : "https://blog.cyberoo.com/attacco-hacker-in-corso-cosa-fare-e-come-risolverlo", "@type" : "WebPage" }, "publisher" : { "@type" : "Organization", "logo" : { "@type" : "ImageObject", "url" : "/hs/hsstatic/content_shared_assets/static-1.4092/img/vast.png" }, "name" : "Cyberoo" } } ``` ```json { "@context" : "https://schema.org", "@type" : "Article", "about" : { "@type" : "Thing", "name" : "Governance & Processes" }, "articleBody" : "Ascolta l'articolo « » 0:00 0:00 1x 1.5x 2x Il tuo browser non supporta l'audio. Che cosa succede quando un attacco informatico ferma un’azienda? I file diventano inaccessibili, l’ERP si blocca, produzione e logistica si fermano e le consegne si accumulano. Bisogna capire che cosa sta succedendo e decidere quali sistemi isolare mentre le persone attendono risposte e l’incertezza comincia a pesare. Ad esempio, un attacco ransomware può rendere molto visibili queste conseguenze. La cifratura però è soltanto l’ultima fase di un’intrusione. Prima possono esserci stati accessi abusivi, sottrazione di dati e l’installazione di meccanismi per riaccedere nei sistemi. Da dove si comincia? Dall’attivazione del team incaricato alla gestione degli incidenti e dal contenimento del danno. Le prime informazioni sono determinanti per chiarire quali sistemi sono coinvolti e quali attività aziendali sono a rischio. Analisi, autorizzazioni e priorità di ripristino devono procedere insieme e in modo coordinato. Chi ha affrontato il percorso di conformità alla NIS2 o la certificazione ISO/IEC 27001 sa che analisi dei rischi e business impact analysis servono a collegare i processi aziendali ai sistemi informatici che li sostengono. Anche la categorizzazione di attività e servizi richiesta da ACN ha imposto ai soggetti essenziali ed importanti di individuare i processi strategici per il business. Sono proprio questi gli elementi che indicano che cosa deve tornare in esercizio per primo e in quali tempi. Eppure, in molte aziende la risposta si arena nelle prime fasi. Manca la mappatura tra processi e sistemi, nessuno ha stabilito a monte che cosa è prioritario e parametri come MTPD (o MTO), RTO e RPO non sono mai stati definiti. Così le decisioni sulla ripartenza vengono prese sotto pressione e nel momento peggiore per farlo. Un caso concreto Nel caso che ti racconto l'accesso iniziale avviene attraverso una VPN senza autenticazione multifattore assegnata ad un fornitore. L’attività DFIR ha determinato che il consulente lavorava abitualmente con un computer personale sprovvisto di EDR e le credenziali dei suoi clienti erano conservate localmente su file. Un infostealer (un malware che sottrae credenziali e spesso anche i cookie di sessione), le ha esfiltrate: in pochi istanti decine di credenziali VPN di altrettante aziende sono state compromesse. Ottenuto l’accesso gli attaccanti esplorano la rete, recuperano le credenziali dall'ambiente di virtualizzazione, individuano i backup, sottraggono i dati e avviano la cifratura dei file delle macchine virtuali. Le conseguenze sono pesanti: giorni di fermo produttivo, cassa integrazione e penali per le consegne mancate. Attacco in corso: che cosa fare subito Se più persone in azienda segnalano problemi su sistemi diversi, bisogna dare l’allarme e ingaggiare il responsabile della gestione degli incidenti (IR Manager). Malfunzionamenti diffusi non indicano per forza un attacco, ma vanno trattati come un possibile incidente finché non si dimostra il contrario. La prima cosa da capire in pochissimo tempo è la natura dell’evento: incidente cyber o problema di altra origine come un guasto sistemistico o di rete? Procedure e catena di comando devono chiarire chi analizza gli eventi, chi decide e chi interviene sui sistemi. Servono contatti utilizzabili anche fuori orario, un’adeguata copertura contrattuale con i fornitori (es. system integrator) e priorità legate ai processi che l’azienda deve mantenere operativi. Tutti questi elementi dovrebbero essere già documentati nell’Incident Response Plan. Per iniziare servono informazioni verificabili: quale anomalia è stata osservata? A che ora? Su quali sistemi e con quali effetti? Cosa fare in pratica: Coordinamento: individuare un referente unico per la gestione dell’incidente e coinvolgere staff IT, direzione, punto di contatto e referente CSIRT (se l’organizzazione è un soggetto NIS), DPO, risorse umane, comunicazione e supporto legale. Segnalare: raccogliere orari, messaggi di errore, sistemi interessati e riferimenti degli alert. Acquisizioni e analisi spettano ai tecnici: chi segnala non deve riavviare, cancellare file o intervenire di propria iniziativa. Contenere: isolare dalla rete i sistemi coinvolti evitando per quanto possibile di spegnerli, e bloccare gli accessi abusivi valutando l’impatto sui servizi essenziali. Conservare: coordinare la raccolta delle evidenze con il contenimento prima che reinstallazioni e ripristini le sovrascrivano. Comunicazione: stabilire un canale affidabile e un referente per gli aggiornamenti verso clienti, fornitori e personale. Se gli strumenti aziendali sono compromessi o c’è il dubbio che lo siano, si passa ad un canale alternativo concordato in anticipo. Aspettare di avere ricostruito ogni dettaglio mentre l’attacco continua può aumentare il danno. La risposta richiede azioni tempestive e tracciabilità. Contenere l’attacco Il contenimento serve a impedire all’attaccante di continuare a operare. Nel caso della VPN il primo passo è intervenire sull’accesso compromesso e poi verificare fin dove l’attaccante sia arrivato: il sistema da cui è partito l’allarme può essere solo una parte dell’incidente. Le azioni tipiche sono l’isolamento dalla rete dei sistemi coinvolti, la disabilitazione degli account compromessi e la revoca delle sessioni attive. Cambiare la password non basta: token e sessioni già aperte possono restare validi e vanno revocati in modo specifico. Il team deve poi verificare che gli accessi siano davvero interrotti tenendo conto che ogni sistema ha tempi e meccanismi di revoca propri. In parallelo si cercano altre tracce della compromissione: account creati dall’attaccante, privilegi modificati, accessi anomali e meccanismi di persistenza. I sistemi di virtualizzazione e di backup vanno controllati anche quando non ci sono ancora prove dirette del loro coinvolgimento: se l’attaccante aveva le credenziali per raggiungerli o se la loro criticità lo giustifica. Quando isolare un sistema non è possibile e bisogna fermare la propagazione dell’attacco, il team di risposta può decidere di spegnere i dispositivi interessati. È una scelta di responsabilità poiché lo spegnimento cancella il contenuto della memoria volatile, utile all’indagine. Per i sistemi da cui dipendono la produzione o servizi critici, ogni azione di contenimento va coordinata con la continuità operativa e con la sicurezza delle persone. Il piano di risposta deve indicare anche chi autorizza tali decisioni. Conservare le evidenze per capire che cosa è successo Durante l’emergenza viene spontaneo pensare subito al ripristino: rimettere in funzione il server, recuperare gli applicativi, riaprire gli accessi vpn, ecc. Prima di reinstallare o ripristinare però, bisogna mettere al sicuro le informazioni che servono a ricostruire l’attacco e questo non significa rimandare il contenimento. Le fonti principali sono i log di autenticazione, gli eventi degli endpoint, i registri degli accessi remoti e i log di firewall e proxy. Insieme permettono di ricostruire da dove è entrato l’attaccante, quali account ha usato, quali sistemi ha raggiunto e se ha esfiltrato dati. Per ogni acquisizione si registrano origine, data e ora e chi l’ha eseguita, e si calcola l’hash per dimostrare che la copia non è stata alterata. Accanto alle evidenze serve un “diario” dell’incidente, con decisioni, autorizzazioni, azioni ed effetti osservati. La cronologia ricostruita in questa fase ha anche un uso pratico immediato: indica da quando l’attaccante era presente nell’ambiente, e quindi quali backup possono contenere le sue tracce. Come si risolve un incidente La bonifica (eradication) elimina ciò che ha reso possibile l’intrusione e ciò che l’attaccante ha lasciato nell’ambiente per mantenerne il controllo. Il ripristino (recovery) riporta i servizi in esercizio ma solo dopo le verifiche necessarie. Nel caso esaminato, recuperare i file avrebbe risolto solo una parte del problema: restavano gli accessi remoti, i privilegi eccessivi, le postazioni poco protette e i backup vulnerabili. La bonifica deve chiudere il vettore d’ingresso, rimuovere gli accessi abusivi e verificare tutti i sistemi coinvolti. Le persistenze finiscono anche nei backup Un backup disponibile è un punto di partenza, non la prova che l’ambiente sia pronto a ripartire. Le copie offline o immutabili garantiscono che i dati ci siano ancora ma non dicono nulla su che cosa contengono. Se l’attaccante è rimasto nella rete per giorni o settimane prima della cifratura, i backup di quel periodo contengono anche ciò che ha installato per rientrare: account creati o modificati, attività pianificate, servizi e chiavi di avvio automatico, strumenti di accesso remoto, web shell, modifiche ai criteri di gruppo. Ripristinare un server da una copia di questo tipo significa rimettere in esercizio anche la porta d’ingresso. Analizzare i server ripristinati prima di ricollegarli Una volta ripristinati i server andranno analizzati in un ambiente isolato senza collegamento alla rete compromessa né a Internet. Le verifiche principali consistono in: Punto di ripristino: scegliere in base alle esigenze aziendali tenendo presente la data con la cronologia dell’intrusione che spesso precede di molto la cifratura Persistenze: cercare account, attività pianificate, servizi, programmi in avvio automatico, software di accesso remoto e file sospetti, usando soprattutto gli indicatori di compromissione (ioc) emersi dall’indagine Identità: reimpostare le credenziali compromesse anche sui sistemi ripristinati ed eseguire il doppio reset di krbtgt nel domain controller secondo procedura Patch e configurazioni: correggere eventuali vulnerabilità e configurazioni sfruttate prima di ricollegare il sistema Monitoraggio: ricollegare i sistemi gradualmente con strumenti di rilevamento attivi e una sorveglianza più stretta nelle settimane successive. Ripartire per passaggi verificabili Le priorità di ripartenza le decidono la direzione e i responsabili dei processi insieme al team tecnico. Si parte dalle applicazioni indispensabili per lavorare e dai servizi da cui dipendono seguendo le priorità e i tempi definiti nella business impact analysis. Prima di rimettere in esercizio ogni sistema vanno confermati tre elementi: bonifica completata, vettore d’ingresso chiuso, controlli di sicurezza attivi. Il ritorno all’operatività procede per gradi e con i sistemi ripristinati sotto monitoraggio. Chi decide e chi comunica La catena di comando serve ad autorizzare gli isolamenti, scegliere le priorità di ripristino e tenere informati i reparti. Funziona se le informazioni circolano nei due sensi: chi analizza l’attacco deve conoscere le conseguenze operative di ogni intervento e chi guida l’azienda deve ricevere elementi sufficienti per decidere. Un aggiornamento utile distingue sempre tre cose: ciò che sappiamo, ciò che stiamo verificando e quale sarà il prossimo passaggio. Lo stesso criterio vale verso dipendenti, clienti e partner. Le comunicazioni vanno coordinate da un unico referente riportando solo i fatti confermati e senza diffondere dettagli che potrebbero ostacolare la risposta. Il caso del consulente esterno rende concreta anche la questione dei fornitori. Prima di dare istruzioni o concedere accessi a un fornitore conviene verificarne l’identità attraverso un canale indipendente perché proprio i suoi strumenti potrebbero essere compromessi. Nella ricostruzione vanno considerati anche gli account e i dispositivi delle terze parti: l’analisi non si ferma al confine della rete aziendale. C’è infine un aspetto che riguarda gli altri clienti del fornitore. Se le credenziali sono state sottratte da un dispositivo che ne conteneva molte, il rischio non riguarda solo l’azienda attaccata: va chiesto al fornitore di verificare ad esempio i suoi sistemi informatici e di avvisare i clienti potenzialmente a rischio compromissione. Notifiche: verificare gli obblighi Gestione tecnica e notifiche procedono in parallelo. L'articolo 25 del D.Lgs. 138/2024 prevede senza ingiustificato ritardo, una pre-notifica al CSIRT Italia entro 24 ore dalla conoscenza dell'incidente significativo e una notifica entro 72 ore dallo stesso momento. La relazione finale va inviata entro un mese dalla notifica. Se l'incidente è ancora in corso occorrono relazioni mensili sui progressi e una finale entro un mese dalla conclusione della gestione. Il GDPR richiede una valutazione distinta: una violazione di dati personali può compromettere riservatezza, integrità o disponibilità anche senza esfiltrazione accertata. Il titolare notifica all'autorità di controllo competente senza ingiustificato ritardo entro 72 ore dalla conoscenza, salvo che sia improbabile un rischio per i diritti e le libertà delle persone. Il responsabile del trattamento informa il titolare senza ingiustificato ritardo. Se la violazione può presentare un rischio elevato per i diritti e le libertà delle persone, il titolare deve comunicarla agli interessati senza ingiustificato ritardo, salvo le eccezioni dell'articolo 34 del GDPR. Tutte le violazioni di dati personali vanno documentate. La notifica al CSIRT Italia non sostituisce quella eventualmente dovuta ai sensi del GDPR e va valutata anche la denuncia alla Polizia Postale. Dopo l’emergenza Quando i servizi ripartono la tentazione è chiudere il capitolo. Proprio a quel punto l'analisi deve diventare un piano di lavoro: problema individuato, intervento da completare, responsabile e verifica del risultato. Nel caso che abbiamo esaminato, la remediation ha riguardato queste misure: Accessi: account dedicati per ciascun fornitore, privilegi minimi, accesso abilitato solo quando serve e da dispositivi gestiti, requisiti di sicurezza nei contratti e predisposizione di jump server confinati in segmenti di rete con policy di attraversamento puntuali gestite da firewall. MFA per vpn, posta elettronica e sistemi critici Separazione: credenziali di gestione distinte dal dominio, protette con MFA e amministrazione privilegiata organizzata per livelli EDR: per rilevare e analizzare comportamenti sospetti sugli endpoint Password manager: per gestire le credenziali con strumenti dedicati Backup 3-2-1-1-0: tre copie dei dati, su due supporti diversi, una fuori sede e una offline o immutabile. Test di ripristino periodici per verificare l’effettiva recuperabilità. L’architettura di backup va gestita con credenziali separate dal dominio Segmentazione della rete: per limitare la possibilità di spostarsi tra sistemi Monitoraggio continuo MDR: monitoraggio dell’infrastruttura h24 365gg per rilevamento, analisi e risposta alle minacce. Essenziale per prevenire lo sviluppo di un’azione offensiva. Ripartire sapendo che cosa è stato risolto Il caso della VPN collega direttamente una credenziale rubata al fermo aziendale. La risposta deve interrompere quel percorso eradicando ciò che l'attaccante ha lasciato anche nei backup e correggerne le cause. La capacità di reagire si costruisce collegando ciò che spesso viene gestito separatamente. Monitoraggio, analisi, decisioni, interventi tecnici, comunicazione e obblighi normativi devono far parte dello stesso lavoro. Prima di chiudere l'incidente occorre verificare che ogni correzione abbia un responsabile e un criterio con cui controllarne l'esito. Alla prossima anomalia sapere chi deve fare cosa sarà utile quanto riconoscere tempestivamente i segnali di una potenziale compromissione. Andrea Coli - Incident Response Manager Incident Response Manager, Cyberoo", "author" : { "@type" : "Person", "name" : "Andrea Coli - Incident Response Manager", "sameAs" : [ "https://www.linkedin.com/company/cyberoo-italia" ], "url" : "https://blog.cyberoo.com/author/andrea-coli" }, "dateModified" : "1794473950969", "datePublished" : "2026-11-12 08:59:10", "description" : "Scopri come gestire un attacco informatico, contenere i danni e ripristinare i sistemi aziendali in modo efficace e strategico.", "editor" : { "@type" : "Person", "name" : "Andrea Coli - Incident Response Manager" }, "headline" : "Attacco hacker in corso: cosa fare e come risolverlo", "image" : { "@type" : "ImageObject", "height" : 675, "url" : "https://content.cyberoo.com/hubfs/Cyberoo%20Blog%20-%20Grafiche%20di%20copertina%20%285%29-4.gif", "width" : 1200 }, "inLanguage" : "it-IT", "isAccessibleForFree" : true, "mainEntityOfPage" : { "@id" : "https://blog.cyberoo.com/attacco-hacker-in-corso-cosa-fare-e-come-risolverlo", "@type" : "WebPage" }, "publisher" : { "@type" : "Organization", "logo" : { "@type" : "ImageObject", "url" : "" }, "name" : "Blog", "sameAs" : [ "https://www.linkedin.com/company/cyberoo-italia" ] }, "url" : "https://blog.cyberoo.com/attacco-hacker-in-corso-cosa-fare-e-come-risolverlo", "wordCount" : 2330 } ```