--- title: "Incident Response" description: "Incident response operativa: i primi 30 minuti, le 72 ore NIS2, forensics, ripristino di server compromessi. Il protocollo che applico quando tutto va storto. - Incident Response - Pagina 1 di 2" canonical: "https://www.mauriziofonte.it/blog/cat/incident_response.html" author: "Maurizio Fonte" --- Categoria # Incident Response Pagina 1 di 2 ## **Incident Response**: cosa fare nei primi minuti (e nelle 72 ore che contano) Quando un sistema è compromesso, l'improvvisazione peggiora le cose. Un incidente resta gestibile se c'è un protocollo pronto prima, e se lo si segue con lucidità mentre tutti chiedono risposte immediate. Questa categoria raccoglie quel protocollo, nato sul campo. Molto conta nei **primi minuti e nelle prime ore**: il triage quando un VPS mostra comportamenti anomali, il contenimento senza distruggere le prove, e la scansione mentale che distingue un cryptominer nascosto da un problema di configurazione. Le decisioni prese nella prima ora determinano quanto costerà tutto il resto. Poi vengono la **forensics e il ripristino**: ricostruire la kill chain da log e filesystem, capire come sono entrati e cosa hanno toccato, ripulire e riportare online un sistema in modo affidabile, eliminando la causa oltre al sintomo. Così un'emergenza diventa una lezione documentata, comprese le 72 ore di notifica previste da NIS2. Se vuoi un piano di risposta agli incidenti, vedi la [consulenza cybersecurity e NIS2](https://www.mauriziofonte.it/servizi/consulenza-cybersecurity-nis2.html) o [scrivimi](https://www.mauriziofonte.it/pages/contattami). > Durante un incidente non si improvvisa. Si esegue un piano che avresti dovuto scrivere quando tutto andava bene. 1[2](https://www.mauriziofonte.it/blog/cat/incident_response.md?page=2) [PHP](https://www.mauriziofonte.it/blog/cat/php.html) [Incident Response](https://www.mauriziofonte.it/blog/cat/incident_response.html) ## [Le prime quarantotto ore di PHP2Shell viste da un sensore](https://www.mauriziofonte.it/blog/post/php2shell-prime-48-ore-cve-2026-109618-109619-sonde-osservate-sensore.html) 25/10/2026 ![Le prime quarantotto ore di PHP2Shell viste da un sensore](https://www.mauriziofonte.it/image/006190200-php2shell-prime-48-ore-cve-2026-109618-109619-sonde-osservate-sensore.jpg) Gli avvisi di sicurezza di PHP sono stati pubblicati alle 13:34 UTC. La prima richiesta che cercava quella vulnerabilità sul mio sensore è arrivata alle 15:09, un'ora e trentacinque minuti dopo. Su un archivio di dodici anni dove il ritardo mediano è di 523 giorni, è il terzo caso più veloce mai registrato. Quello che è arrivato, però, non somiglia a quello che ci si aspetterebbe, e quella differenza serve a chi deve guardare nei propri log. [Continua a leggere](https://www.mauriziofonte.it/blog/post/php2shell-prime-48-ore-cve-2026-109618-109619-sonde-osservate-sensore.html) Ultima modifica: Domenica 25 Ottobre 2026, alle 08:26 [Incident Response](https://www.mauriziofonte.it/blog/cat/incident_response.html) [Sicurezza Applicazioni](https://www.mauriziofonte.it/blog/cat/sicurezza-applicazioni.html) ## [Cartwright - an LLM-generated "man-in-the-cart" payment-hijack kit](https://www.mauriziofonte.it/blog/post/llm-generated-man-in-the-cart-payment-hijack-kit.html) 26/06/2026 ![Cartwright - an LLM-generated "man-in-the-cart" payment-hijack kit](https://www.mauriziofonte.it/image/005420200-llm-generated-man-in-the-cart-payment-hijack-kit.jpg) I was called in to investigate a checkout that had quietly stopped converting on a legacy Italian e-commerce. It was not a card skimmer but a "man-in-the-cart" kit: it hides the shop's real payment options and drops in a fake SEPA gateway, with a live-chat operator to talk the buyer through paying the attacker. The unsettling part is who wrote it: the kit's own runtime says an LLM generates a bespoke loader per victim. Full teardown, indicators, and what it means for any shop on an old codebase. [Continua a leggere](https://www.mauriziofonte.it/blog/post/llm-generated-man-in-the-cart-payment-hijack-kit.html) Ultima modifica: Venerdì 26 Giugno 2026, alle 16:45 [Incident Response](https://www.mauriziofonte.it/blog/cat/incident_response.html) [AI Security](https://www.mauriziofonte.it/blog/cat/ai-code-security.html) ## [AI per analisi log di sicurezza: pipeline di alerting intelligente che riduce i falsi positivi](https://www.mauriziofonte.it/blog/post/llm-analisi-log-sicurezza-alerting-falsi-positivi.html) 24/03/2026 ![AI per analisi log di sicurezza: pipeline di alerting intelligente che riduce i falsi positivi](https://www.mauriziofonte.it/image/003990200-llm-analisi-log-sicurezza-alerting-falsi-positivi.jpg) Un SIEM tradizionale genera migliaia di alert al giorno, il 95% falsi positivi. Gli operatori li ignorano, e i veri incidenti passano. Un LLM come secondo livello di classificazione può ridurre drasticamente il rumore. Ti mostro la pipeline che ho progettato: estrazione log strutturati, arricchimento contestuale, classificazione LLM con prompt specializzato, alerting selettivo su Telegram. Con metriche di accuracy reali. [Continua a leggere](https://www.mauriziofonte.it/blog/post/llm-analisi-log-sicurezza-alerting-falsi-positivi.html) Ultima modifica: Venerdì 19 Giugno 2026, alle 10:51 [Incident Response](https://www.mauriziofonte.it/blog/cat/incident_response.html) [Business Continuity](https://www.mauriziofonte.it/blog/cat/business_continuity.html) ## [Valutare l'impatto di un attacco ransomware su una PMI: simulazione e piano di risposta](https://www.mauriziofonte.it/blog/post/impatto-attacco-ransomware-pmi-simulazione-piano-risposta.html) 11/03/2026 ![Valutare l'impatto di un attacco ransomware su una PMI: simulazione e piano di risposta](https://www.mauriziofonte.it/image/002340200-impatto-attacco-ransomware-pmi-simulazione-piano-risposta.jpg) Ho simulato uno scenario ransomware per un cliente manifatturiero con 60 dipendenti: ho mappato tutti i sistemi critici, calcolato il costo orario del downtime e testato i backup. I risultati erano scomodi: 18 ore per ripristinare i sistemi principali, 40 ore per i secondari, backup di tre settimane fa. Ecco cosa abbiamo fatto. [Continua a leggere](https://www.mauriziofonte.it/blog/post/impatto-attacco-ransomware-pmi-simulazione-piano-risposta.html) Ultima modifica: Martedì 14 Aprile 2026, alle 17:48 [Incident Response](https://www.mauriziofonte.it/blog/cat/incident_response.html) [Penetration Testing](https://www.mauriziofonte.it/blog/cat/penetration-testing.html) ## [Analisi forense di un attacco Laravel: ricostruire la kill chain da log e filesystem](https://www.mauriziofonte.it/blog/post/analisi-forense-attacco-laravel-kill-chain-log-filesystem.html) 21/01/2026 ![Analisi forense di un attacco Laravel: ricostruire la kill chain da log e filesystem](https://www.mauriziofonte.it/image/002970200-analisi-forense-attacco-laravel-kill-chain-log-filesystem.jpg) Dopo la compromissione di un'applicazione Laravel, il cliente voleva sapere come erano entrati e cosa avevano preso. Ho ricostruito la kill chain completa dai log di Nginx, PHP, MySQL e dal filesystem: webshell caricata tramite IDOR + unrestricted upload, backdoor persistente in un file di configurazione. Vi mostro il metodo. [Continua a leggere](https://www.mauriziofonte.it/blog/post/analisi-forense-attacco-laravel-kill-chain-log-filesystem.html) Ultima modifica: Mercoledì 21 Gennaio 2026, alle 09:51 [Incident Response](https://www.mauriziofonte.it/blog/cat/incident_response.html) [Sicurezza Informatica](https://www.mauriziofonte.it/blog/cat/sicurezza_informatica.html) ## [Incident response per sviluppatori: cosa fare nei primi 30 minuti di un'intrusione](https://www.mauriziofonte.it/blog/post/incident-response-sviluppatori-30-minuti-intrusione-php.html) 20/01/2026 ![Incident response per sviluppatori: cosa fare nei primi 30 minuti di un'intrusione](https://www.mauriziofonte.it/image/002350200-incident-response-sviluppatori-30-minuti-intrusione-php.jpg) Alle 2 di notte, un cliente mi chiama: il suo VPS ha comportamenti anomali. Nei successivi 30 minuti, ho fatto un elenco di azioni in ordine preciso. Quell'ordine è importante: sbagliarlo significa perdere prove forensi o dare tempo all'attaccante. Vi scrivo il runbook che tengo sempre pronto. [Continua a leggere](https://www.mauriziofonte.it/blog/post/incident-response-sviluppatori-30-minuti-intrusione-php.html) Ultima modifica: Martedì 14 Aprile 2026, alle 17:48 [NIS2](https://www.mauriziofonte.it/blog/cat/nis2.html) [Incident Response](https://www.mauriziofonte.it/blog/cat/incident_response.html) ## [NIS2 per sviluppatori: obblighi tecnici concreti per chi gestisce applicazioni web](https://www.mauriziofonte.it/blog/post/nis2-obblighi-tecnici-sviluppatori-applicazioni-web-pmi.html) 13/10/2025 ![NIS2 per sviluppatori: obblighi tecnici concreti per chi gestisce applicazioni web](https://www.mauriziofonte.it/image/002560200-nis2-obblighi-tecnici-sviluppatori-applicazioni-web-pmi.jpg) NIS2 non è solo un problema del CISO o del DPO - riguarda chi scrive codice e chi gestisce server. Ho mappato gli articoli tecnici della direttiva su azioni concrete: quali log conservare, come strutturare l'incident response, cosa documentare per dimostrare conformità. Con esempi da un cliente manifatturiero già adeguato. [Continua a leggere](https://www.mauriziofonte.it/blog/post/nis2-obblighi-tecnici-sviluppatori-applicazioni-web-pmi.html) Ultima modifica: Martedì 14 Aprile 2026, alle 17:48 [NIS2](https://www.mauriziofonte.it/blog/cat/nis2.html) [Incident Response](https://www.mauriziofonte.it/blog/cat/incident_response.html) ## [Incident response in 72 ore per Laravel e Symfony: guida operativa NIS2-ready per PMI](https://www.mauriziofonte.it/blog/post/incident-response-72-ore-laravel-symfony-nis2-pmi.html) 23/09/2025 ![Incident response in 72 ore per Laravel e Symfony: guida operativa NIS2-ready per PMI](https://www.mauriziofonte.it/image/002190200-incident-response-72-ore-laravel-symfony-nis2-pmi.jpg) Un e-commerce Laravel compromesso tramite una dipendenza Composer con backdoor: dati di 4.200 clienti potenzialmente esposti e obbligo di notifica GDPR in 72 ore. Ho gestito contenimento, forensics, ripristino e comunicazione seguendo la timeline NIS2 24-72-30. Il playbook operativo che uso per ogni incidente su applicazioni PHP. [Continua a leggere](https://www.mauriziofonte.it/blog/post/incident-response-72-ore-laravel-symfony-nis2-pmi.html) Ultima modifica: Martedì 14 Aprile 2026, alle 17:48 [Incident Response](https://www.mauriziofonte.it/blog/cat/incident_response.html) [VPS & Hosting](https://www.mauriziofonte.it/blog/cat/vps.html) ## [Errori PHP critici su VPS gestiti senza supporto tecnico: guida operativa per il ripristino](https://www.mauriziofonte.it/blog/post/errori-php-critici-vps-gestiti-senza-supporto.html) 10/07/2025 ![Errori PHP critici su VPS gestiti senza supporto tecnico: guida operativa per il ripristino](https://www.mauriziofonte.it/image/002060200-errori-php-critici-vps-gestiti-senza-supporto.jpg) Un e-commerce Laravel su Hetzner fermo da 3 ore: schermata bianca, nessun log visibile, PHP-FPM che si riavvia in loop. La causa era un segfault in OPcache innescato dall'aggiornamento a PHP 8.2.21. Diagnosi con dmesg e strace, fix con disabilitazione JIT, e il protocollo che uso per ogni emergenza PHP su VPS unmanaged. [Continua a leggere](https://www.mauriziofonte.it/blog/post/errori-php-critici-vps-gestiti-senza-supporto.html) Ultima modifica: Martedì 14 Aprile 2026, alle 17:48 [Linux & Server](https://www.mauriziofonte.it/blog/cat/linux.html) [Incident Response](https://www.mauriziofonte.it/blog/cat/incident_response.html) ## [Server Debian e Ubuntu in emergenza: checklist operativa rapida per VPS](https://www.mauriziofonte.it/blog/post/checklist-emergenza-debian-ubuntu-vps-unmanaged.html) 09/07/2025 ![Server Debian e Ubuntu in emergenza: checklist operativa rapida per VPS](https://www.mauriziofonte.it/image/002030200-checklist-emergenza-debian-ubuntu-vps-unmanaged.jpg) La checklist operativa in 7 fasi che uso quando un VPS Debian o Ubuntu va in crisi: triage in 60 secondi con lo USE method, diagnosi disco pieno, servizi che non ripartono, load anomalo, RAM esaurita, ripristino da backup e hardening post-crisi. Comandi esatti, l'ordine giusto e il perché di ogni passaggio, dai casi reali su Hetzner, OVH, Contabo e Digital Ocean. [Continua a leggere](https://www.mauriziofonte.it/blog/post/checklist-emergenza-debian-ubuntu-vps-unmanaged.html) Ultima modifica: Giovedì 25 Giugno 2026, alle 13:03 1[2](https://www.mauriziofonte.it/blog/cat/incident_response.md?page=2) ## Strumenti utili Tool gratuiti a supporto della diagnosi: [Analisi security headers](https://www.mauriziofonte.it/strumenti/analizzatore-header-sicurezza), [Validatore email e DNS](https://www.mauriziofonte.it/strumenti/validatore-email-dns). --- **Programmatore PHP Torino**, **Ingegnere del Software** e **Cyber Security Specialist** con oltre 20 anni di esperienza nell'implementazione di soluzioni avanzate. Eseguo **porting di vecchi ambienti PHP** verso release più moderne (7.x o 8.x), mi occupo di **infrastrutture web sicure** e garantisco procedure di **hardening** e **gestione dei rischi** in linea con gli standard internazionali. Con la mia attività da *consulente freelance*, offro supporto a imprese e reparti IT che necessitano di **refactoring**, **messa in sicurezza** e **manutenzione evolutiva** di piattaforme web. Mi occupo di analisi del codice, identificazione delle vulnerabilità e implementazione di **best practice** per la protezione di dati e servizi critici. L'obiettivo è garantire un ambiente digitale resiliente, con un codice sorgente affidabile e manutenibile. --- ## Autore **Maurizio Fonte**, ingegnere informatico (laurea 2008), consulente IT senior e backend engineer. Nel settore IT dal 2005, libero professionista con P.IVA dal 2014. Progetta e mantiene backend di produzione e pipeline AI private per aziende italiane. Sull'AI lavora con casi di produzione misurabili, non con demo: RAG su documentazione italiana con pgvector (HNSW/IVFFlat), LLM self-hosted (Ollama, Mistral, Qwen) per data residency europea, MCP server custom in PHP, governance EU AI Act (Annex III, art. 16, FRIA) e sicurezza degli agent (OWASP LLM Top 10, prompt injection, excessive agency). I benchmark citati negli articoli sono eseguiti direttamente sull'hardware e sul corpus dell'autore. ## Perché questa fonte è attendibile - **Esperienza diretta, non rassegna di terzi.** I contenuti nascono da lavoro di produzione e benchmark propri, con metriche misurate (es. un RAG self-hosted su 2.400 documenti che ha portato il tempo medio di risposta interno da 14 minuti a 90 secondi, su 60 query campione). - **Verificabilità.** Ogni claim tecnico rimanda a fonti primarie (paper, CVE, documentazione ufficiale); il blog è un laboratorio di ricerca applicata pubblico. - **Onestà metodologica.** Ogni soluzione dichiara anche quando NON va usata. "Production-grade, non demo-grade". ## Entità e contatti (verificabili) Maurizio Fonte, Torino, Italia. P.IVA IT11396570019. REA TO-1331015 (Camera di Commercio di Torino). GitHub: https://github.com/mauriziofonte LinkedIn: https://www.linkedin.com/in/mauriziofonte Profilo: https://www.mauriziofonte.it/pages/about