Cartwright - an LLM-generated "man-in-the-cart" payment-hijack kit
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
Ultima modifica:
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. 
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. 
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. 
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. 
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. 
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. 
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. 
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. 
VPS compromesso: CPU al 100%, login SSH a forza bruta riusciti, un cryptominer nascosto in /dev/shm camuffato da thread del kernel. Il playbook di incident response che applico su un server unmanaged: triage senza riavviare, conservazione delle evidenze, forensics, eradicazione della persistenza, ripristino e hardening post-incidente. Con la prospettiva offensiva su come entra l'attaccante e cosa lascia dietro di sé.