NexaCorp DFIR : INC-2026-001 - Compromission d'infrastructure Linux

Investigation DFIR et ingénierie de détection sur une intrusion simulée contre l'infrastructure NexaCorp. Menée dans le cadre d'un engagement solo de 4 jours (bootcamp Blue & Red Team BeCode Bruxelles, Mission 01). Le livrable est un rapport de conclusions de 54 pages (PDF) plus 7 règles Suricata validées qui détectent l'incident capturé dans une relecture de PCAP.

Ce dépôt documente un engagement d'analyste SOC réalisé dans le cadre du BeCode Cybersecurity Bootcamp (promotion 2025-2026). Il reconstruit une intrusion complète à partir de preuves réseau et de logs, puis livre un ensemble validé de règles de détection Suricata. C'est le premier incident de la série NexaCorp DFIR.

Table des matières

• Avis opérationnel
• En un coup d'œil
• Contexte de l'engagement
• Résumé exécutif
• Résumé de la kill chain
• Comment lire ce rapport
• Méthodologie
• Outils utilisés
• Résumé des conclusions
• Ingénierie de détection
• Structure du dépôt
• Reproductibilité
• Limites connues
• Série NexaCorp DFIR
• Remerciements
• À propos
• Licence

Avis opérationnel

Ceci est un engagement de laboratoire contre une infrastructure fictive. NexaCorp est un client fictif utilisé comme scénario pour la Mission 01 de BeCode Bruxelles. L'hôte compromis est une machine virtuelle Metasploitable 2 intentionnellement vulnérable pour la formation en sécurité, et l'implant Caldera Sandcat fait partie du laboratoire pour apprendre à l'analyste à quoi ressemble le trafic d'un véritable intrus. Aucune organisation, réseau ou personne réelle n'a été attaqué.

Toutes les adresses IP, noms d'hôte et indicateurs de compromission publiés dans ce rapport (172.16.50.10, 192.168.10.10, 10.40.0.200, blue11, mesdec, etc.) sont des artefacts de laboratoire locaux, et non des renseignements sur les menaces réelles. Ne les introduisez pas dans un SIEM comme des IOC.

Publication autorisée par le coach de laboratoire BeCode (Thomas B.) le 2026-05-17. La déclaration de confidentialité complète figure dans le rapport de conclusions (section « Distribution et classification »).

En un coup d'œil

Contexte de l'engagement

Scénario (fictif). NexaCorp, un client d'entreprise de taille moyenne, a contacté l'équipe bleue de BeCode Corp après que leur surveillance interne a signalé un trafic sortant inattendu d'un de leurs serveurs Linux internes. Le pare-feu a enregistré le trafic mais n'a déclenché aucune alerte exploitable. Le conseil d'administration avait besoin d'une détermination avant de décider de la divulgation et de la notification réglementaire.

Mandat. Enquêter sur la fenêtre d'incident suspectée, caractériser la voie d'entrée de l'attaquant et son activité post-exploitation, évaluer ce que la pile de détection existante a capturé (et manqué), et livrer un plan de remédiation priorisé. Une seconde phase a ajouté l'ingénierie de détection : produire des règles IDS réseau prêtes à déployer qui détecteraient une récidive en temps réel.

Package de preuves reçu du client.

Contexte pédagogique. Cet engagement a été réalisé pendant le bootcamp Blue & Red Team BeCode Bruxelles (novembre 2025 à septembre 2026) en tant que Mission 01 : une investigation solo et chronométrée simulant un véritable engagement de conseil DFIR. L'infrastructure de laboratoire, l'identité NexaCorp et les valeurs des IOC sont délibérément fictives. La méthodologie, les outils et le format du rapport suivent les normes réelles (NIST SP 800-61r2, SANS PICERL, MITRE ATT&CK).

Résumé exécutif

📄 Le rapport de conclusions complet de 54 pages est le livrable canonique. Télécharger le PDF (215 Ko) ou parcourir la source Markdown pour grep/citation.

Le soir du 2026-05-09 à 22 h 53 UTC, un attaquant externe (172.16.50.10) a compromis un serveur interne NexaCorp (192.168.10.10) en exploitant CVE-2011-2523, la porte dérobée présente dans vsftpd 2.3.4 (une version dont la compromission est documentée publiquement depuis juillet 2011). Une simple requête FTP USER se terminant par :) a déclenché un shell racine sans authentification sur le port TCP/6200. L'attaquant a exécuté 8 commandes de reconnaissance pendant une session de 20 secondes (aucune persistance, aucune exfiltration, aucun mouvement latéral via ce vecteur d'accès) et s'est déconnecté.

Indépendamment, le même hôte s'est avéré exécuter un agent MITRE Caldera « Sandcat » préexistant à /opt/caldera/sandcat (root, démonisé) émettant des balises toutes les 40 à 50 secondes en HTTP en clair vers 10.40.0.200:8888 tout au long de la fenêtre capturée. C'est la « connexion sortante inhabituelle » initialement signalée par le client et indique une compromission antérieure non représentée dans le package de preuves (l'implant était déjà actif dans la première trame PCAP).

Le SIEM Wazuh existant a ingéré 397 événements de l'hôte cible mais n'a déclenché que 4 alertes de haute sévérité (1,0 % du total), toutes classées comme force brute générique (MITRE T1110). Aucune n'a identifié la charge utile de l'exploit CVE-2011-2523, le shell lié sur TCP/6200 ou le canal C2 Caldera : l'octet de l'exploit (USER baduser:)) n'est jamais enregistré par vsftpd lui-même, et le SIEM n'avait aucune télémétrie réseau pour voir le reste. Les 7 règles Suricata livrées dans la Phase 2 comblent les trois lacunes.

IOC principaux (limités au laboratoire, ne pas introduire dans un SIEM réel) :

Résumé de la kill chain

L'incident capturé comporte deux fils distincts, reconstitués à partir du PCAP :

1. Service exposé : vsftpd 2.3.4, une version avec une porte dérobée documentée publiquement (CVE-2011-2523), était accessible sur le réseau interne (Conclusion I1).
2. Exploit : une simple requête FTP USER se terminant par :) a déclenché la porte dérobée (Conclusion I3).
3. Shell racine lié : un shell racine sans authentification s'est ouvert sur TCP/6200 ; l'attaquant a exécuté 8 commandes de reconnaissance pendant une session de 20 secondes, puis s'est déconnecté, sans persistance ni exfiltration via ce vecteur (Conclusion I4).
4. C2 parallèle (préexistant) : indépendamment, un implant MITRE Caldera Sandcat balisait déjà en HTTP en clair vers 10.40.0.200:8888 tout au long de la fenêtre, preuve d'une compromission antérieure non représentée dans le lot de preuves (Conclusion I5).

Comment lire ce rapport

Le dépôt est organisé pour que vous puissiez plonger au bon niveau selon votre rôle :

Livrable canonique : le PDF dans reports/. La source Markdown contient le même contenu, conservé dans le dépôt pour la recherche et le contrôle de version.

Piste d'investigation : notes/journal.md est le cahier de travail de l'analyste (hypothèses testées et réfutées, inventaire des preuves, état du plan). Il complète le rapport formel en montrant comment les conclusions ont été atteintes, et pas seulement les conclusions elles-mêmes.

Ensemble de règles de détection : detection/lab.rules contient les 7 règles Suricata avec une justification complète par mot-clé dans les commentaires en ligne. detection/README.md documente le workflow de déploiement et de validation par relecture utilisé pour confirmer que chaque règle se déclenche sur l'incident capturé.

Méthodologie

L'engagement suit trois frameworks standard de l'industrie superposés.

NIST SP 800-61r2 : Guide de traitement des incidents de sécurité informatique

Le modèle en 4 phases de NIST (Préparation, Détection & Analyse, Confinement / Éradication / Rétablissement, Activité post-incident) fournit la structure de haut niveau. Dans cet engagement, la Phase 1 du livrable correspond à la phase « Détection & Analyse » du NIST (forensique PCAP, corrélation SIEM, reconstruction de la chronologie de l'attaquant). La Phase 2 correspond à la phase « Leçons apprises » du NIST traduite en contrôles préventifs (les 7 règles Suricata et la liste de recommandations priorisées dans la section 7 du rapport).

SANS PICERL : flux d'investigation tactique

PICERL (Préparation, Identification, Confinement, Éradication, Rétablissement, Leçons apprises) est le processus de réponse aux incidents SANS. Appliqué dans cet engagement :

MITRE ATT&CK : cartographie des techniques

Chaque conclusion est cartographiée à une ou plusieurs techniques MITRE ATT&CK pour permettre au client de corréler cet incident avec leur modèle de menace existant. 14 techniques distinctes sont référencées dans les 10 conclusions :

• Reconnaissance : T1595.002, T1592.002, T1589
• Accès initial : T1190 (Exploitation d'application exposée au public via CVE-2011-2523)
• Exécution : T1059.004 (Shell Unix)
• Découverte : T1033, T1082, T1087.001, T1083, T1016, T1049, T1046
• Accès aux identifiants : T1110 (Force brute)
• Commande et contrôle : T1071.001, T1102 (Balise Caldera Sandcat)
• Élévation de privilèges : T1078.003, T1548.003 (activité sudo suspectée)

Le tableau complet des techniques par conclusion se trouve dans la section 4 (IOC) du rapport et les analyses approfondies par conclusion dans les sections 3 et 5.

Reproductibilité

Chaque affirmation du rapport est traçable à un artefact dans le package de preuves, avec le filtre tshark exact, la requête Wazuh ou la commande de relecture Suricata nécessaire pour la reproduire. Voir l'Annexe A (Commandes de reproductibilité) dans le rapport et la section Reproductibilité ci-dessous pour un démarrage rapide.

Outils utilisés

Forensique réseau

• tshark : Wireshark CLI pour le triage PCAP, la reconstruction de flux TCP (-z follow,tcp,ascii), le filtrage de protocole et l'extraction de champs
• tcpreplay et tcprewrite : relecture PCAP sur une interface de surveillance en direct pour la validation des règles Suricata, avec ajustement MTU pour correspondre à l'interface ens19 du laboratoire (1 450 octets)
• Décodeurs Base64 : reconstruction des charges utiles C2 de Caldera Sandcat (corps de balise et réponse de l'opérateur)

IDS réseau / ingénierie de détection

• Suricata 6.0.4 (mode afpacket, mono-thread, Hyperscan désactivé en laboratoire) : rédaction, validation et réglage des 7 règles de ce livrable
• suricata -T : validation de la configuration et des règles lors du déploiement et du réglage
• kill -USR2 $(pgrep suricata) : rechargement en direct des règles lors du réglage itératif

SIEM et télémétrie hôte

• Wazuh (gestionnaire + tableau de bord) : corrélation d'événements, analyse de distribution de sévérité, recherche de règles (rule.id 11452, 5551, etc.), export CSV de 397 événements
• Utilitaires texte Linux standards (grep, awk, jq) : exploration de logs et analyse JSON

Contexte d'émulation adverse (référencé, non exploité)

• MITRE Caldera (agent Sandcat) : présent sur l'hôte cible comme implant C2 simulé préexistant en cours de caractérisation

Frameworks de référence

• NIST SP 800-61r2 : Guide de traitement des incidents de sécurité informatique
• SANS PICERL : flux d'investigation tactique
• MITRE ATT&CK : attribution des techniques
• Avis CVE-2011-2523 : référence de la porte dérobée vsftpd 2.3.4

Résumé des conclusions

Les 10 conclusions (I1 à I10) sont documentées en détail dans le rapport de conclusions. Chaque entrée comprend les preuves, les commandes de reproductibilité, la cartographie MITRE ATT&CK et les conseils de remédiation.

Répartition des sévérités : 3 CRITIQUE / 3 HAUT / 2 MOYEN / 2 BAS

Recommandation de lecture : commencez par I1 (le service vulnérable), puis I3 puis I4 (la chaîne d'exploitation réelle), puis I5 (l'implant C2 parallèle et non lié). I2 et I6 donnent le contexte de la reconnaissance. I7 à I10 sont les conclusions sur la posture défensive (ce que la surveillance a vu par rapport à ce qu'elle a manqué).

Ingénierie de détection

La Phase 2 de l'engagement a produit 7 règles Suricata (SID 9000001 à 9000007) couvrant l'incident capturé sous trois angles : la signature de l'exploit, le shell post-exploit et le canal C2 parallèle. Chaque règle est validée par une relecture PCAP hors ligne contre une instance Suricata 6.0.4 sur le poste de travail SOC.

Les 7 règles

Résumé de validation

L'écart 40 vs 314 reflète une limitation délibérée sur les règles 9000003, 9000004, 9000005, 9000006 pour offrir aux analystes SOC une vue opérationnelle propre tout en préservant le flux brut d'alertes dans eve.json pour les analyses forensiques approfondies.

Décisions de conception notables

Quatre corrections itératives lors du déploiement sont documentées dans detection/README.md. Leçons clés :1. Détection HTTP indépendante du port. Les règles 9000004 et 9000005 (Caldera) ont été initialement écrites avec les mots-clés alert http et http.uri, qui n'activent le parseur HTTP de Suricata que sur le port 80. Le C2 de Caldera tourne sur le port 8888, donc le parseur a été contourné et les règles ne se sont jamais déclenchées. Correction : réécriture en mode TCP+content (alert tcp ... content:"POST /beacon"; content:"Go-http-client/1.1";) qui correspond aux octets HTTP bruts quel que soit le port. 2. flow:established peu fiable lors de la relecture PCAP. Une poignée de main TCP capturée en dehors de la fenêtre de relecture laisse la machine d'état du flux dans un état indéterminé. Supprimer flow:established des règles Caldera permet de les faire correspondre en modes direct et relecture. 3. Direction de flux explicite pour les règles SYN uniquement. La règle 9000003 (port 6200) a généré SC_WARN_POOR_RULE: SYN-only ... w/o direction specified. Corrigé en ajoutant flow:to_server,not_established. 4. HOME_NET vs dans les laboratoires uniquement RFC1918. Lorsque l'attaquant, la cible et le C2 résident tous dans l'espace privé, devient vide et les règles de la forme ne correspondent jamais. Correction laboratoire : utiliser dans les deux. Correction production : réduire au seul segment protégé.

Considérations sur les faux positifs

L'analyse des faux positifs par règle est documentée dans la section 8.5 du rapport. La plupart des règles présentent un risque négligeable dans un environnement bien délimité ; les règles 9000005 (en-tête Serveur aiohttp) et 9000006 (curl/Wget sur des chemins d'administration) nécessitent un réglage si des services Python internes bénins ou des scripts d'administration sont présents.

Structure du dépôt```text

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)

**Classifications des fichiers :**

| Chemin | Rôle | Public |
|---|---|---|
| `reports/*.pdf` | Livrable canonique, rapport formel | Client, recruteur, auditeur |
| `reports/*.md` | Même contenu, source compatible grep | Toute personne citant ou comparant |
| `detection/lab.rules` | Ensemble de règles Suricata prêt pour la production | SOC / ingénieur détection |
| `detection/README.md` | Guide de déploiement et validation par rejeu | Intégration ingénieur détection |
| `evidence-summary/ioc-summary.md` | Indicateurs de compromission, par catégorie | SOC / chasse aux menaces |
| `methodology/attack-timeline.md` | Chronologie de l'incident (UTC) | Praticien DFIR |
| `methodology/attck-mapping.md` | Table de correspondance MITRE ATT&CK | Praticien DFIR / ingénieur détection |
| `notes/journal.md` | Cahier de travail d'investigation | Praticien DFIR étudiant la méthode |
| `.github/workflows/ci.yml` | Automatisation markdownlint, typographie et validation des règles Suricata (`suricata -T`, s'exécute lorsque `detection/*.rules` est présent) lors d'un push | CI |

## Reproductibilité

Chaque affirmation du rapport de conclusions est traçable jusqu'à un artefact dans le dossier de preuves. La PCAP elle-même n'est pas redistribuée (propriété du labo BeCode), mais les commandes et requêtes sont documentées afin que toute personne disposant de sa propre copie puisse reproduire l'analyse.

### Reproduire les résultats clés (analyse PCAP)

Nécessite `tshark` (CLI Wireshark) et le fichier `attack.pcap` original :```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

Reproduire la validation des règles (Suricata replay)

Nécessite Suricata 6.0.x, tcpreplay, et une interface surveillée (ens19 dans le labo ; remplacez par la vôtre) :```bash

1. Install the ruleset

sudo cp detection/lab.rules /etc/suricata/rules/learner/lab.rules

2. Hot-reload Suricata without restart

sudo kill -USR2 $(pgrep -f suricata) sleep 5

3. Clear the alert log for a clean baseline

sudo truncate -s 0 /var/log/suricata/fast.log

4. Replay the PCAP at top speed

sudo tcpreplay --intf1=ens19 --topspeed attack_mtu.pcap

5. Count alerts per rule (expect 7 distinct SIDs)

sudo grep -oE '[1:[0-9]+:' /var/log/suricata/fast.log | sort | uniq -c | sort -rn

Sortie attendue (après un rejeu complet) :```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 règles se déclenchent correctement. Le dossier de preuves complet (fast.log, eve.json, config de throttling, instantané de la version de Suricata) est énuméré dans l'Annexe E du rapport de constatations.

Limites connues

• Le dossier de preuves commence en milieu d'incident. Le PCAP débute à 2026-05-09 20:08 UTC, mais l'agent Caldera Sandcat effectue déjà du beaconing actif dans la trame 1. La compromission initiale qui a installé l'implant s'est produite plus tôt et n'est pas représentée dans les données. Les conclusions sur l'activité pré-implant sont extrapolées à partir des champs full_log de Wazuh, non observées directement.
• Les journaux d'audit de l'hôte ne couvrent pas la fenêtre d'attaque. Les auth.log et syslog locaux commencent ~5 heures après la fin du PCAP, la première entrée étant un redémarrage syslogd (probablement un redémarrage de VM). Aucun fichier de journal roté n'a été fourni. Cela est documenté comme Constatation I10.
• Le périmètre était forensique + ingénierie de détection, pas réponse en direct. Le confinement, l'éradication, l'acquisition forensique (image mémoire, image disque) et l'énumération de persistance sont documentés comme recommandations P0 dans le rapport, mais n'ont pas été exécutés : l'intervention n'avait pas d'accès direct à l'hôte. Une intervention de suivi serait nécessaire pour boucler ces points.
• Les 7 règles Suricata détectent cette signature d'incident spécifique. Un attaquant sophistiqué peut les contourner en modifiant le motif d'octets de l'exploit (terminateurs alternatifs d'octet nul sur l'argument USER), en recompilant Caldera avec un User-Agent différent, ou en déplaçant le C2 vers HTTPS chiffré (l'analyse des métadonnées TLS comme JA3/JA4 serait le repli). Les règles sont appropriées pour le scénario de menace capturé ; une stratégie de détection à plus long terme devrait ajouter des détections comportementales et basées sur les métadonnées.
• Lacune d'ingestion Wazuh pendant l'investigation. Le pipeline d'ingestion des logs SIEM était temporairement indisponible jusqu'au 2026-05-11 11:39 UTC (en cours d'investigation, rétabli par le coach du lab). Les 4 alertes de haute sévérité apparaissent donc dans le tableau de bord avec des (11 mai 13:17-13:28) plutôt qu'avec les timestamps réels de l'incident (9 mai 21:00-22:53), ce qui déforme le timing apparent des événements de corrélation.

Série DFIR NexaCorp

• INC-2026-001 : ce dépôt
• INC-2026-002 : escalade de privilèges et persistance (Tor SSH, SUID, compte backdoor)
• INC-2026-003 : évaluation inter-incidents du mois 1
• INC-2026-004 : injection SQL (portail web)
• INC-2026-005 : injection de commandes OS et web shell (portail web)
• INC-2026-006 : XSS stocké et détournement de session (portail web)
• INC-2026-007 : IDOR et contrôle d'accès brisé (NexaPortal) ; projet de fin de mois 2
• INC-2026-008 : reconnaissance AD et Kerberoasting (premier incident du mois 3)

Remerciements

• Thomas B. (coach du lab BeCode) : conception du scénario, correction de l'ingestion Wazuh en cours d'investigation, autorisation de publication pour usage portfolio.
• MITRE pour le framework Caldera qui a alimenté l'implant C2 simulé, et pour la base de connaissances ATT&CK utilisée pour cartographier chaque constatation.
• Le projet Suricata pour le moteur qui a rendu les 7 règles déployables en moins de 30 minutes.

À propos

Intervention DFIR en solo réalisée pendant le bootcamp Blue & Red Team de BeCode Brussels (novembre 2025 à septembre 2026), Mission 01, le 2026-05-15.

Auteur : Johan-Emmanuel Hatchi (LinkedIn).

Ouvert aux opportunités de stage en cybersécurité à partir de septembre 2026 en Belgique. Recherche des postes SOC / DFIR / ingénierie de détection où ce genre de travail d'investigation de bout en bout (forensique PCAP, corrélation SIEM, rédaction de règles IDS, rapports clients formels) est dans le périmètre.

Licence

MIT, 2026 Johan-Emmanuel Hatchi.

Les règles Suricata dans detection/lab.rules et le texte du rapport sont tous deux publiés sous la même licence MIT : libre de copier, adapter et redéployer avec attribution. Le PCAP, l'infrastructure du lab et les briefings de l'intervention restent la propriété de BeCode Brussels et ne sont pas redistribués.