jhatchi/nexacorp-dfir-inc-2026-001Indagine DFIR + 7 regole Suricata su un'intrusione simulata di NexaCorp (vsftpd 2.3.4 CVE-2011-2523 + MITRE Caldera C2). Incarico individuale di 4 giorni (BeCode Brussels Mission 01). Report di 54 pagine, 10 riscontri, 7/7 regole validate tramite replay PCAP.
Indagine DFIR e ingegneria di rilevamento su un'intrusione simulata contro l'infrastruttura di NexaCorp. Svolta come incarico individuale di 4 giorni (bootcamp Blue & Red Team di BeCode Bruxelles, Missione 01). Il risultato è un report di 54 pagine (PDF) più 7 regole Suricata validate che intercettano l'incidente acquisito in replay PCAP.
Questo repository documenta un incarico da analista SOC svolto nell'ambito del BeCode Cybersecurity Bootcamp (promozione 2025-2026). Ricostruisce un'intera intrusione partendo dalle evidenze di rete e dai log, e fornisce un set validato di regole di rilevamento Suricata. È il primo incidente della serie NexaCorp DFIR.
Questo è un esercizio di laboratorio su infrastrutture fittizie. NexaCorp è un cliente fittizio usato come scenario per la Missione 01 di BeCode Bruxelles. L'host compromesso è una VM Metasploitable 2 volutamente vulnerabile per l'addestramento sulla sicurezza, e l'impianto Caldera Sandcat fa parte del laboratorio per insegnare all'analista come appare il traffico di beacon di un vero intruso. Nessuna organizzazione, rete o persona reale è stata attaccata.
Tutti gli indirizzi IP, gli hostname e gli indicatori di compromissione pubblicati in questo report (172.16.50.10, 192.168.10.10, 10.40.0.200, blue11, mesdec, ecc.) sono artefatti locali di laboratorio, non threat intelligence del mondo reale. Non inserirli in un SIEM come IOC.
Pubblicazione autorizzata dal coach di laboratorio BeCode (Thomas B.) il 2026-05-17. La dichiarazione completa di riservatezza compare nel report dei risultati (sezione "Distribution and Classification").
| Metadati dell'incarico | Valore |
|---|---|
| Riferimento | BCC-2026 / INC-2026-001 |
| Durata | 4 giorni (individuale) |
| Fasi | DFIR (forense) + ingegneria di rilevamento |
| Consegnato | 2026-05-15 |
| Stato | Completato (Fase 1 + Fase 2) |
| Risultati dell'indagine | Valore |
|---|---|
| Risultati | 10 (3 CRITICI, 3 ALTI, 2 MEDI, 2 BASSI) |
| Tecniche MITRE ATT&CK mappate | 14 |
| Cattura di rete analizzata | 5.194 pacchetti in 5h31m (943 KB PCAP) |
| Eventi Wazuh correlati | 397 dall'agente 020 |
| Regole Suricata create | 7 (SID 9000001-9000007) |
| Regole validate tramite replay PCAP | 7/7 (40 alert in fast.log, 314 record in eve.json) |
Scenario (fittizio). NexaCorp, un cliente aziendale di medie dimensioni, ha contattato il blue team di BeCode Corp dopo che il monitoraggio interno ha segnalato traffico in uscita inatteso da uno dei loro server Linux interni. Il firewall registrava il traffico ma non ha generato alcun alert azionabile. Il consiglio di amministrazione aveva bisogno di una valutazione prima di decidere in merito alla divulgazione e alla notifica alle autorità di regolamentazione.
Mandato. Indagare sulla finestra temporale dell'incidente sospetto, caratterizzare il percorso di ingresso dell'attaccante e l'attività post-exploitation, valutare cosa lo stack di rilevamento esistente ha intercettato (e cosa ha mancato), e consegnare un piano di remediation prioritizzato. Una seconda fase ha aggiunto l'ingegneria di rilevamento: produrre regole IDS di rete pronte per la distribuzione che intercettino una recidiva in tempo reale.
Pacchetto di evidenze ricevuto dal cliente.
| Artefatto | Copertura | Nota |
|---|---|---|
| Cattura di rete (PCAP) | dal 2026-05-09 20:08 al 2026-05-10 01:39 UTC (5h31m, 5.194 pacchetti) | Inizia a metà incidente: l'impianto stava già facendo beaconing nel frame 1 |
| Log di autenticazione dell'host | dal 2026-05-10 06:47 UTC in poi | Solo post-incidente (gap di ~5 ore dopo la fine del PCAP) |
| Syslog dell'host | dal 2026-05-10 06:37 UTC in poi | La prima voce è syslogd restart, suggerisce un riavvio della VM |
| Esportazione alert SIEM (Wazuh) | n/a | Il file era una risposta HTTP 404, non dati. Recuperati 397 eventi in seguito tramite query diretta sul dashboard |
Contesto formativo. Questo incarico è stato svolto durante il bootcamp Blue & Red Team di BeCode Bruxelles (novembre 2025 - settembre 2026) come Missione 01: un'indagine individuale con tempo limitato che simula un vero incarico di consulenza DFIR. L'infrastruttura di laboratorio, l'identità di NexaCorp e i valori IOC sono volutamente fittizi. La metodologia, gli strumenti e il formato del report seguono standard reali (NIST SP 800-61r2, SANS PICERL, MITRE ATT&CK).
📄 Il report completo di 54 pagine è il deliverable canonico. Scarica il PDF (215 KB) oppure sfoglia il sorgente Markdown per grep/citazioni.
Nella serata del 2026-05-09 alle 22:53 UTC, un attaccante esterno (172.16.50.10) ha compromesso un server interno NexaCorp (192.168.10.10) sfruttando CVE-2011-2523, la backdoor presente in vsftpd 2.3.4 (una build documentata pubblicamente come compromessa dal luglio 2011). Una singola richiesta FTP USER terminante con :) ha attivato una root bind shell non autenticata sulla porta TCP/6200. L'attaccante ha eseguito 8 comandi di ricognizione in una sessione di 20 secondi (nessuna persistenza, nessuna esfiltrazione, nessun movimento laterale tramite questo vettore di accesso) e si è disconnesso.
Indipendentemente, è stato rilevato che lo stesso host eseguiva un agente MITRE Caldera "Sandcat" preesistente in /opt/caldera/sandcat (root, daemonizzato) che effettuava beaconing ogni 40-50 secondi in HTTP in chiaro verso 10.40.0.200:8888 per tutta la finestra di cattura. Questa è la "connessione in uscita anomala" inizialmente segnalata dal cliente e indica una compromissione precedente non rappresentata nel pacchetto di evidenze (l'implant era già attivo nel primo frame del PCAP).
Il SIEM Wazuh esistente ha ingerito 397 eventi dall'host target ma ha generato solo 4 alert ad alta severità (1,0% del totale), tutti classificati come brute-force generico (MITRE T1110). Nessuno ha identificato il payload dell'exploit CVE-2011-2523, la bind shell sulla TCP/6200 o il canale C2 di Caldera: il byte dell'exploit (USER baduser:)) non viene mai registrato da vsftpd stesso, e il SIEM non aveva telemetria di rete per vedere il resto. Le 7 regole Suricata consegnate nella Fase 2 chiudono tutte e tre le lacune.
IOC principali (limitati al laboratorio, non inserirli in un SIEM reale):
| Tipo | Valore | Contesto |
|---|---|---|
| IP sorgente (attaccante) | 172.16.50.10 | exploit vsftpd, ricognizione multi-protocollo, brute-force SSH |
| IP target | 192.168.10.10 | Server interno compromesso (Metasploitable 2) |
| IP C2 | 10.40.0.200:8888 | Comando e controllo Caldera Sandcat |
| Porta backdoor | 6200/tcp | Root bind shell CVE-2011-2523 |
| Payload exploit | FTP USER terminante con :) | Pattern di attivazione della backdoor |
L'incidente acquisito ha due filoni distinti, ricostruiti dal PCAP:
vsftpd 2.3.4, una build con una backdoor pubblicamente documentata (CVE-2011-2523), era raggiungibile sulla rete interna (Risultato I1).USER terminante con :) ha attivato la backdoor (Risultato I3).10.40.0.200:8888 per tutta la finestra, prova di una compromissione precedente non rappresentata nel pacchetto di evidenze (Risultato I5).Il repository è organizzato in modo da poter entrare nel dettaglio giusto per il tuo ruolo:
| Se sei un... | Inizia da qui | Tempo |
|---|---|---|
| Reclutatore o hiring manager | Questo README + scorri la sintesi esecutiva del PDF | 5 min |
| Analista SOC che valuta l'idoneità | Sezioni 5 (Detection Gap) e 8 (Detection Engineering) del PDF + detection/lab.rules | 20 min |
| Professionista DFIR | PDF completo + notes/journal.md per il percorso investigativo | 60 min |
| Ingegnere di rilevamento | detection/lab.rules + detection/README.md per distribuzione e validazione tramite replay | 30 min |
| Chiunque voglia fare grep, citare o diff | Sorgente Markdown del report | quando serve |
Deliverable canonico: il PDF in reports/. Il sorgente Markdown ha contenuto identico, mantenuto nel repository per ricercabilità e controllo versione.
Traccia investigativa: notes/journal.md è il quaderno di lavoro dell'analista (ipotesi testate e confutate, inventario delle evidenze, stato del piano). Completa il report formale mostrando come sono state raggiunte le conclusioni, non solo le conclusioni stesse.
Set di regole di rilevamento: detection/lab.rules contiene le 7 regole Suricata con la giustificazione completa per ogni keyword nei commenti inline. detection/README.md documenta il flusso di lavoro di validazione deploy-and-replay usato per confermare che ogni regola scatti sull'incidente acquisito.
L'incarico segue tre framework standard di settore combinati tra loro.
Il modello a 4 fasi del NIST (Preparation, Detection & Analysis, Containment / Eradication / Recovery, Post-Incident Activity) fornisce la struttura di alto livello. In questo incarico, la Fase 1 del deliverable corrisponde alla "Detection & Analysis" del NIST (forensics su PCAP, correlazione SIEM, ricostruzione della timeline dell'attaccante). La Fase 2 corrisponde alle "Lessons Learned" del NIST, tradotte in controlli preventivi (le 7 regole Suricata e la lista di raccomandazioni prioritizzate nella sezione 7 del report).
PICERL (Preparation, Identification, Containment, Eradication, Recovery, Lessons Learned) è il processo di incident response del SANS. Applicato in questo incarico:
| Fase PICERL | Questo incarico |
|---|---|
| Preparation | Ambiente di laboratorio validato dal coach, pacchetto di evidenze approvato, scope definito (forense + ingegneria di rilevamento), timebox di 4 giorni |
| Identification | Triage PCAP + correlazione eventi Wazuh + analisi basata su ipotesi (7 ipotesi, 1 confutata, 5 confermate, 1 inconcludente) |
| Containment / Eradication / Recovery | Documentate come raccomandazioni P0 (quarantena dell'host, rimozione di vsftpd, pulizia dell'implant Caldera) ma non eseguite (fuori scope: solo analisi forense, non risposta attiva) |
| Lessons Learned | Ingegneria di rilevamento della Fase 2: 7 regole Suricata + note di tuning + analisi dei falsi positivi (sezione 8 del report) |
Ogni risultato è mappato su una o più tecniche MITRE ATT&CK per consentire al cliente di correlare questo incidente con il proprio modello di minaccia esistente. 14 tecniche distinte sono citate nei 10 risultati:
La tabella completa delle tecniche per ogni risultato si trova nella sezione 4 (IOC) del report e negli approfondimenti per risultato nelle sezioni 3 e 5.
Ogni affermazione del report è riconducibile a un artefatto nel pacchetto di evidenze, con l'esatto filtro tshark, la query Wazuh o il comando di replay Suricata necessario per riprodurla. Vedi Allegato A (Comandi di riproducibilità) nel report e la sezione Riproducibilità qui sotto per un avvio rapido.
Forensics di rete
tshark: CLI di Wireshark per triage PCAP, ricostruzione dei flussi TCP (-z follow,tcp,ascii), filtraggio dei protocolli ed estrazione dei campitcpreplay e tcprewrite: replay PCAP su un'interfaccia di monitoraggio live per la validazione delle regole Suricata, con regolazione MTU per adattarla alla ens19 del laboratorio (1450 byte)IDS di rete / ingegneria di rilevamento
afpacket, single-thread, Hyperscan disattivato in laboratorio): create, validate e ottimizzate le 7 regole di questo deliverablesuricata -T: validazione di configurazione e regole durante distribuzione e tuningkill -USR2 $(pgrep suricata): ricaricamento live delle regole durante il tuning iterativoSIEM e telemetria host
rule.id 11452, 5551, ecc.), esportazione CSV dei 397 eventigrep, awk, jq): mining dei log e parsing JSONContesto di emulazione dell'avversario (citato, non gestito)
Framework di riferimento
I 10 risultati (da I1 a I10) sono documentati in dettaglio nel report dei risultati. Ogni voce include evidenze, comandi di riproducibilità, mappatura MITRE ATT&CK e indicazioni di remediation.
| ID | Gravità | Titolo | Tecnica MITRE primaria |
|---|---|---|---|
| I1 | 🔴 CRITICA | Servizio vulnerabile vsftpd 2.3.4 esposto sulla rete interna | T1190 |
| I2 | 🟡 MEDIA | Fase di ricognizione lenta e prolungata precedente all'exploit | T1595.002, T1589 |
| I3 | 🟠 ALTA | Sfruttamento di CVE-2011-2523 tramite trigger backdoor USER con :) | T1190 |
| I4 | 🔴 CRITICA | Root bind shell non autenticata sulla TCP/6200, eseguiti 8 comandi di enumerazione | T1059.004, T1082 |
| I5 | 🔴 CRITICA | Implant C2 MITRE Caldera Sandcat preesistente (indipendente dall'attacco FTP) | T1071.001, T1102 |
| I6 | 🟢 BASSA | Enumerazione servizi multi-protocollo (HTTP, SSH, SMTP, Telnet, MySQL) | T1046 |
| I7 | 🟡 MEDIA | Tentativi di brute-force SSH visibili in Wazuh, fuori dalla finestra di cattura PCAP | T1110 |
| I8 | 🟠 ALTA | Attività sudo anomala incluso 2 eventi di primo sudo | T1548.003 |
| I9 | 🟠 ALTA | Copertura di rilevamento insufficiente del SIEM Wazuh per questa classe di attacco | (gap difensivo) |
| I10 | 🟢 BASSA | I log di audit dell'host non coprono la finestra dell'incidente | (gap di evidenze) |
Distribuzione della gravità: 3 CRITICHE / 3 ALTE / 2 MEDIE / 2 BASSE
Ordine di lettura consigliato: inizia con I1 (il servizio vulnerabile), poi I3 e I4 (la vera catena di sfruttamento), quindi I5 (l'implant C2 parallelo e non correlato). I2 e I6 forniscono il contesto di ricognizione. Da I7 a I10 sono i risultati sulla postura difensiva (cosa il monitoraggio ha visto vs cosa ha mancato).
La Fase 2 dell'incarico ha prodotto 7 regole Suricata (SID da 9000001 a 9000007) che coprono l'incidente acquisito da tre angolazioni: la firma dell'exploit, la shell post-exploit e il canale C2 parallelo. Ogni regola è validata tramite replay PCAP offline contro un'istanza Suricata 6.0.4 sulla workstation SOC.
| SID | Obiettivo di rilevamento | Livello | Tecnica MITRE | Attivata nel replay |
|---|---|---|---|---|
| 9000001 | Trigger backdoor vsftpd 2.3.4: argomento USER terminante con :) | payload TCP/21 | T1190 | ✅ 1/1 |
| 9000002 | Banner vulnerabile vsftpd 2.3.4 annunciato (220 (vsFTPd 2.3.4)) | payload TCP/21 | T1190 | ✅ 30 (banner ripetuto a ogni sessione FTP) |
| 9000003 | Connessione TCP in ingresso alla porta backdoor 6200 (solo SYN) | TCP/6200 | T1059.004 | ✅ 1/1 (connessione bind shell) |
| 9000004 | Beacon dell'agente MITRE Caldera Sandcat (POST /beacon + UA Go-http-client/1.1) | TCP+content (indipendente dalla porta) | T1071.001, T1102 | ✅ 1 (limitato a 1 per sorgente ogni 60s) |
| 9000005 | Risposta del server C2 Caldera (HTTP Server: Python/3.10 aiohttp/3.13.4) | TCP+content (indipendente dalla porta) | T1071.001 | ✅ 1 (limitato a 1 per sorgente ogni 300s) |
| 9000006 | Enumerazione di percorsi admin HTTP da curl/Wget (/admin, /login, /phpmyadmin) | payload TCP/80 | T1595.002, T1592.002 | ✅ 3 |
| 9000007 | Enumerazione lenta di USER FTP (5+ tentativi in 30 min dalla stessa sorgente) | TCP/21 + soglia | T1589, T1078.003 | ✅ 3 |
| Metrica | Valore |
|---|---|
| Regole create | 7 |
| Regole che si sono attivate correttamente nel replay PCAP | 7/7 ✅ |
Alert in fast.log (deduplicati, vista SOC) | 40 |
Record in eve.json (grezzi, pre-throttle) | 314 |
| Versione Suricata | 6.0.4 (afpacket, single-thread) |
| Comando di replay | tcpreplay --intf1=ens19 --topspeed attack_mtu.pcap |
| Validazione CI | markdownlint, tipografia e suricata -T controllo regole a ogni push |
La differenza tra 40 e 314 riflette un throttling deliberato sulle regole 9000003, 9000004, 9000005, 9000006 per dare agli analisti SOC una visione operativa pulita, preservando al contempo il flusso di alert grezzo in eve.json per approfondimenti forensi.
Quattro correzioni iterative durante la distribuzione sono documentate in detection/README.md. Lezioni chiave:1. Rilevamento HTTP agnostico rispetto alla porta. Le regole 9000004 e 9000005 (Caldera) sono state inizialmente scritte con le parole chiave alert http e http.uri, che attivano il parser HTTP di Suricata solo sulla porta 80. Il C2 di Caldera gira sulla porta 8888, quindi il parser veniva bypassato e le regole non scattavano mai. Correzione: riscrittura in modalità TCP+content (alert tcp ... content:"POST /beacon"; content:"Go-http-client/1.1";) che corrisponde ai byte HTTP grezzi indipendentemente dalla porta.
2. flow:established inaffidabile durante la riproduzione di PCAP. Un handshake TCP catturato al di fuori della finestra di riproduzione lascia la macchina a stati del flusso in uno stato indeterminato. Rimuovere flow:established dalle regole Caldera le fa corrispondere sia in modalità live che in riproduzione.
3. Direzione di flusso esplicita per le regole solo-SYN. La regola 9000003 (porta 6200) ha generato SC_WARN_POOR_RULE: SYN-only ... w/o direction specified. Corretta aggiungendo flow:to_server,not_established.
4. HOME_NET vs EXTERNAL_NET in laboratori solo-RFC1918. Quando attaccante, target e C2 vivono tutti nello spazio privato, EXTERNAL_NET = !$HOME_NET diventa vuoto e le regole della forma $EXTERNAL_NET any -> $HOME_NET 21 non corrispondono mai. Correzione in laboratorio: usare any in entrambi. Correzione in produzione: restringere HOME_NET al solo segmento protetto.
L'analisi dei falsi positivi per regola è documentata nella sezione 8.5 del report. La maggior parte delle regole comporta un rischio trascurabile in un ambiente ben delimitato; le regole 9000005 (header Server di aiohttp) e 9000006 (curl/Wget su percorsi amministrativi) richiedono ottimizzazione se sono presenti servizi Python interni benigni o script amministrativi.
NexaCorp-DFIR-INC-2026-001/ ├── README.md (this file) ├── LICENSE (MIT) ├── .gitignore ├── .github/ │ └── workflows/ │ └── ci.yml markdownlint + typography + Suricata rule check ├── reports/ │ ├── INC-2026-001_Findings_Report.pdf canonical 54-page deliverable │ └── INC-2026-001_Findings_Report.md same content, Markdown source ├── detection/ │ ├── lab.rules 7 Suricata rules (SID 9000001-9000007) │ └── README.md deploy + replay validation workflow ├── evidence-summary/ │ └── ioc-summary.md indicators of compromise (SIEM-ingestible) ├── methodology/ │ ├── attack-timeline.md incident timeline (UTC) │ └── attck-mapping.md MITRE ATT&CK mapping table └── notes/ └── journal.md analyst investigation journal (hypotheses, plan, IOCs, timeline)
**Classificazione dei file:**
| Percorso | Ruolo | Destinatario |
|---|---|---|
| `reports/*.pdf` | Deliverable canonico, report formale | Cliente, recruiter, auditor |
| `reports/*.md` | Stesso contenuto, sorgente grep-friendly | Chiunque citi o faccia diff |
| `detection/lab.rules` | Ruleset Suricata pronto per la produzione | SOC / detection engineer |
| `detection/README.md` | Guida al deployment e validazione tramite replay | Onboarding detection engineer |
| `evidence-summary/ioc-summary.md` | Indicatori di compromissione, per categoria | SOC / threat hunting |
| `methodology/attack-timeline.md` | Timeline dell'incidente (UTC) | Professionista DFIR |
| `methodology/attck-mapping.md` | Tabella di mapping MITRE ATT&CK | DFIR / detection engineer |
| `notes/journal.md` | Quaderno di lavoro dell'indagine | Professionista DFIR che studia il metodo |
| `.github/workflows/ci.yml` | Validazione automatizzata di markdownlint, tipografia e regole Suricata (`suricata -T`, eseguita quando `detection/*.rules` è presente) al push | CI |
## Riproducibilità
Ogni affermazione nel report dei risultati è riconducibile a un artefatto nel pacchetto di evidenze. Il PCAP stesso non viene ridistribuito (proprietà del laboratorio BeCode), ma i comandi e le query sono documentati affinché chiunque abbia una propria copia possa riprodurre l'analisi.
### Riproduci i risultati principali (analisi PCAP)
Richiede `tshark` (CLI di Wireshark) e il `attack.pcap` originale:```bash
# 1. PCAP overview
tshark -r attack.pcap -q -z io,stat,0
# 2. TCP conversations (reveals attacker, target, C2)
tshark -r attack.pcap -q -z conv,tcp | head -30
# 3. Confirm vsftpd 2.3.4 banner exposure (Finding I1)
tshark -r attack.pcap -Y "ftp && ip.src == 192.168.10.10" \
-T fields -e frame.time -e ftp.response.code -e ftp.response.arg | head -5
# 4. Find the CVE-2011-2523 exploit payload (Finding I3)
tshark -r attack.pcap -Y 'ftp.request.command == "USER"' \
-T fields -e frame.time -e ftp.request.arg
# 5. Reconstruct the root shell session on TCP/6200 (Finding I4)
tshark -r attack.pcap -q -z follow,tcp,ascii,70
# 6. Reconstruct the Caldera C2 beacon (Finding I5)
tshark -r attack.pcap -q -z follow,tcp,ascii,6 | head -50
Richiede Suricata 6.0.x, tcpreplay, e un'interfaccia monitorata (ens19 in laboratorio; sostituisci la tua):```bash
sudo cp detection/lab.rules /etc/suricata/rules/learner/lab.rules
sudo kill -USR2 $(pgrep -f suricata) sleep 5
sudo truncate -s 0 /var/log/suricata/fast.log
sudo tcpreplay --intf1=ens19 --topspeed attack_mtu.pcap
sudo grep -oE '[1:[0-9]+:' /var/log/suricata/fast.log | sort | uniq -c | sort -rn
Output previsto (dopo un replay completo):```text
30 [1:9000002: (vsftpd banner repeated per session)
3 [1:9000007: (FTP USER enumeration threshold)
3 [1:9000006: (HTTP admin path enumeration)
1 [1:9000005: (Caldera C2 response)
1 [1:9000004: (Caldera Sandcat beacon, throttled)
1 [1:9000003: (Backdoor port 6200 SYN)
1 [1:9000001: (vsftpd USER smiley exploit)
7/7 regole scattano correttamente. Il pacchetto completo di prove (fast.log, eve.json, configurazione di throttling, snapshot della versione di Suricata) è elencato nell'Allegato E del rapporto dei riscontri.
full_log di Wazuh, non osservate direttamente.auth.log e syslog locali iniziano ~5 ore dopo la fine del PCAP, con la prima voce che è syslogd restart (probabile riavvio della VM). Non sono stati forniti file di log ruotati. Questo è documentato come Finding I10.USER), ricompilando Caldera con un User-Agent diverso o spostando il C2 su HTTPS cifrato (l'analisi dei metadati TLS come JA3/JA4 sarebbe il fallback). Le regole sono appropriate per lo scenario di minaccia catturato; la strategia di rilevamento a lungo termine dovrebbe aggiungere rilevamenti comportamentali e basati sui metadati.HOME_NET è stato impostato su any per il lab. In una distribuzione NexaCorp reale, HOME_NET deve essere limitato al solo segmento protetto (es. 192.168.10.0/24) in modo che EXTERNAL_NET = !$HOME_NET copra correttamente lo spazio dell'attaccante. Le regole così consegnate sono ottimizzate per il lab e necessitano di questa singola modifica di configurazione prima dell'uso in produzione.full_log per tutti gli 80 eventi sudo per identificare quali account utente li hanno attivati (e i timestamp relativi all'exploit FTP), e rivedere i 12 successi di autenticazione SSH per distinguere le sessioni admin legittime da quelle controllate dall'attaccante. Entrambi sono documentati nell'allegato "Open Questions" del report.Intervento DFIR individuale svolto durante il bootcamp Blue & Red Team di BeCode Brussels (novembre 2025 a settembre 2026), Mission 01, il 2026-05-15.
Author: Johan-Emmanuel Hatchi (LinkedIn).
Aperto a opportunità di tirocinio in cybersecurity a partire da settembre 2026 in Belgio. Cerco ruoli SOC / DFIR / detection engineering in cui questo tipo di lavoro investigativo end-to-end (forensics su PCAP, correlazione SIEM, scrittura di regole IDS, reportistica formale per il cliente) rientri nel perimetro.
MIT, 2026 Johan-Emmanuel Hatchi.
Le regole Suricata in detection/lab.rules e il testo del report sono entrambi rilasciati sotto la stessa licenza MIT: liberi di essere copiati, adattati e ridistribuiti con attribuzione. Il PCAP, l'infrastruttura di laboratorio e i briefing dell'intervento restano di proprietà di BeCode Brussels e non vengono ridistribuiti.