PCTAMALOU 2026 – Semaine 29 : La Reconstitution du Crime

🎯 Objectif de la semaine

Maîtriser l'art de l'analyse de logs forensique : transformer des millions d'événements bruts en une chronologie précise d'attaque. Apprendre à reconstituer chaque phase d'un incident (reconnaissance → accès initial → mouvement latéral → exfiltration) à partir de traces laissées dans les logs, pour comprendre non seulement ce qui s'est passé, mais comment et pourquoi.

Pourquoi c'est fondamental : Dans 93% des incidents de sécurité, les logs contiennent toutes les preuves nécessaires – si on sait les lire. L'analyse de logs est l'ADN de l'investigation numérique.

flowchart TD L[📊 Logs Bruts] --> C[🔍 Collecte & Centralisation] C --> N[🧹 Normalisation] N --> E[🎯 Enrichissement] E --> F[🔎 Filtrage & Recherche] F --> A[🧩 Analyse & Corrélation] A --> V[📈 Visualisation] V --> T[📋 Timeline Narrative] T --> R[📄 Rapport d'Investigation] subgraph "🕵️‍♂️ Phases d'Analyse" C N E F end subgraph "🎨 Reconstruction" A V T R end style L fill:#0a0e17,stroke:#9d4edd,stroke-width:2px style A fill:#0a0e17,stroke:#00d4ff,stroke-width:2px style R fill:#0a0e17,stroke:#00f5a0,stroke-width:2px

📚 Sujet – Théorie (1 heure)

L'Art de la Reconstruction : Des Logs à la Narration

L'analyse de logs n'est pas une simple recherche de mots-clés – c'est une enquête scientifique qui transforme des données brutes en intelligence actionnable. Chaque log est une empreinte numérique laissée par une action.

🔍

Collecte

Centralisation des logs depuis toutes les sources (syslog, Windows Event, applications)

🧹

Normalisation

Format commun (ECS), extraction champs structurés (IP, timestamp, user)

🎯

Enrichissement

Ajout contexte (geoIP, threat intel, asset DB, user roles)

🧩

Corrélation

Liaison événements par IP, user, hash, timestamp, MITRE ATT&CK

Kibana Query Language (KQL) : Votre Langage d'Investigation

🔍 Recherche Basique

syslog_program:"sshd" AND 
("failed password" OR 
"authentication failure")

🎯 Filtre Avancé

agent.name:"web-server-01" AND 
event.action:"process_started" AND 
process.args:"/tmp/suspicious"

📊 Agrégation

source.ip:192.168.56.100 | 
stats count() by user.name | 
sort count desc

La Méthodologie SANS SIFT : Processus d'Analyse Professionnelle

🔬 Les 6 Étapes de l'Analyse Forensique de Logs

Préparation : Contexte incident, scope, hypothèses
Identification : Sources logs pertinentes, timeframe
Collecte : Acquisition préservant l'intégrité (hash MD5/SHA)
Examen : Recherche patterns, anomalies, outliers
Analyse : Construction timeline, corrélation, attribution
Présentation : Rapport narratif avec preuves, conclusions, recommandations

MITRE ATT&CK : Le Cadre de Référence de l'Attaquant

🕒 Timeline d'Attaque Brute-Force SSH

gantt title Chronologie d'Attaque Brute-Force SSH dateFormat HH:mm axisFormat %H:%M section Reconnaissance Scan ports SSH :01, 00:00, 5m Fingerprint version :01, 00:05, 3m section Accès Initial Tentatives échouées 1-50 :01, 00:08, 10m Pause rate limit :01, 00:18, 2m Tentatives échouées 51-100 :01, 00:20, 10m Connexion réussie root:password123 :crit, 01, 00:30, 2m section Exécution Commande whoami :01, 00:32, 1m Élévation privilèges sudo su :01, 00:33, 1m section Persistance Création backdoor :01, 00:34, 3m Ajout clé SSH :01, 00:37, 2m section Exfiltration Compression données :01, 00:39, 5m Transfert externe :01, 00:44, 10m

Log Signatures : Ce Que Cherchent les Pros

⚠️ Signes d'une Attaque Brute-Force SSH

Pattern	Signification	Sévérité
`Failed password for root from 192.168.56.100`	Tentative échouée admin	Haute
`Connection closed by authenticating user root`	Authentification abandonnée	Moyenne
`Accepted password for root from 192.168.56.100`	Accès réussi admin	Critique
`PAM service(sshd) ignoring max retries; 6>3`	Rate limit dépassée	Haute

Enrichissement de Context : Au-Delà des Logs Bruts

🌍 Ce Que L'Enrichissement Ajoute

GeoIP : Localisation IP attaquante
Threat Intelligence : IP connue dans feeds malveillants
Asset Database : Importance du serveur compromis
User Context : Rôle, département, horaires normaux
Vulnerability Data : CVE connues sur le service

🔬 Mission pratique – Laboratoire (2 heures)

Architecture du Lab d'Analyse

flowchart LR K[Kali Attaquant
192.168.56.100] -->|Brute-force SSH| T[Target Ubuntu
192.168.56.20
Agent Wazuh] T -->|Logs SSH| W[Wazuh SIEM
192.168.56.10] W -->|Indexation| E[Elasticsearch] E -->|Visualisation| KI[Kibana
https://192.168.56.10:5601] A[Analyste] -->|Investigation| KI subgraph "📝 Logs Générés" L1["/var/log/auth.log
Failed password entries"] L2["/var/log/secure
PAM authentication"] L3["Wazuh alerts
Rule ID 5710, 5712"] end T --> L1 T --> L2 T --> L3 style K fill:#11151f,stroke:#ef4444,stroke-width:3px style T fill:#0a0e17,stroke:#00d4ff,stroke-width:2px style KI fill:#0a0e17,stroke:#9d4edd,stroke-width:2px

⚠️ Prérequis Critiques

📋 Vérification environnement :

Wazuh SIEM opérationnel (semaines 27-28)
Agent Wazuh installé sur cible Ubuntu
Accès Kibana (admin:SecretPCTAMALOU2026)
Service SSH activé sur cible

Étapes Détaillées d'Investigation

Étape 1 : Simulation d'Attaque Contrôlée

# Sur Kali - Simulation brute-force SSH contrôlée
# Création d'une wordlist ciblée
echo -e "password\n123456\nadmin\nroot\npassword123\npctamalou" > ~/wordlist_ssh.txt

# Attaque avec hydra (limité pour lab)
hydra -l root -P ~/wordlist_ssh.txt ssh://192.168.56.20 -t 2 -V

# Connexion manuelle réussie (mot de passe connu)
ssh root@192.168.56.20
# Mot de passe : pctamalou (si configuré)
# Exécution de commandes post-connexion
whoami
cat /etc/passwd | head -5
w  # Voir qui est connecté

🎭 Scénario d'attaque : L'attaquant tente 6 mots de passe courants, échoue sur les 5 premiers, réussit avec "pctamalou". Après connexion, il exécute des commandes de reconnaissance basique.

Étape 2 : Accès à Kibana et Recherche Initiale

# Accès Kibana via navigateur
https://192.168.56.10:5601
# Identifiants : admin / SecretPCTAMALOU2026

🔍 Première recherche : Tous les logs SSH

Dans Kibana → Discover :

# Filtre KQL pour logs SSH
data.syslog_program:"sshd" OR rule.groups:"sshd"

Champs à ajouter :

@timestamp (toujours)
data.syslog_message ou rule.description
srcip (source IP)
agent.name (machine cible)
rule.level (sévérité)

Étape 3 : Investigation Ciblée - Failed Logins

# Recherche spécifique tentatives échouées
agent.name:"ubuntu-target" AND 
(data.syslog_message:"failed password" OR 
rule.description:"SSH authentication failure") AND
@timestamp >= "now-1h"

# Avec enrichissement IP source
srcip:192.168.56.100 AND 
rule.level >= 5 AND
@timestamp:["now-1h" TO "now"]

# Agrégation par minute pour voir le pattern
srcip:192.168.56.100 |
stats count() by 
bucket(@timestamp, 1m) |
sort @timestamp asc

🎯 Défi d'Investigation

Trouvez :

La première tentative échouée
La dernière tentative échouée avant succès
Le timestamp exact de la connexion réussie
La première commande exécutée après connexion

Indice : Cherchez "Accepted password" et "session opened".

Étape 4 : Reconstruction Chronologique

📋 Création d'une Timeline Manuelle

Exporter les résultats en CSV puis créer un tableau chronologique :

## Chronologie d'Incident - Attaque SSH Brute-Force

### Métadonnées Incident
- **ID Incident** : PCTAMALOU-INC-2026-029
- **Date** : 2026-MM-JJ
- **Analyste** : [Votre Nom]
- **Sévérité** : CRITIQUE (CVSS: 9.8)

### Timeline Détaillée

| Timestamp (UTC) | Événement | Source IP | User | Niveau | Preuve |
|-----------------|-----------|-----------|------|--------|--------|
| 14:05:03 | Première tentative échouée | 192.168.56.100 | root | 5 | `Failed password for root from 192.168.56.100` |
| 14:05:05 | Tentative échouée #2 | 192.168.56.100 | root | 5 | `Failed password for root from 192.168.56.100` |
| 14:05:07 | Tentative échouée #3 | 192.168.56.100 | root | 5 | `Failed password for root from 192.168.56.100` |
| 14:05:09 | Tentative échouée #4 | 192.168.56.100 | root | 5 | `Failed password for root from 192.168.56.100` |
| 14:05:11 | Tentative échouée #5 | 192.168.56.100 | root | 5 | `Failed password for root from 192.168.56.100` |
| 14:05:15 | **Connexion réussie** | 192.168.56.100 | root | 12 | `Accepted password for root from 192.168.56.100` |
| 14:05:16 | Session ouverte | 192.168.56.100 | root | 3 | `pam_unix(sshd:session): session opened for user root` |
| 14:05:18 | Commande exécutée | 192.168.56.100 | root | 7 | `USER_CMD user=root cmd=whoami` |
| 14:05:20 | Commande exécutée | 192.168.56.100 | root | 7 | `USER_CMD user=root cmd=cat /etc/passwd` |
| 14:05:22 | Session fermée | 192.168.56.100 | root | 3 | `pam_unix(sshd:session): session closed for user root` |

### Analyse des Preuves
**Pattern détecté** : 5 tentatives échouées en 8 secondes, suivies d'une réussite.
**Moyen d'attaque** : Brute-force dictionary attack.
**Mot de passe compromis** : "pctamalou" (présent dans wordlist).
**Indicateurs de Compromise (IoC)** :
- IP source : 192.168.56.100 (Kali lab)
- Compte : root
- Heure : 14:05 UTC (activité anormale pour ce compte)

### Impact Évalué
- **Confidentialité** : HIGH - Accès root à la machine
- **Intégrité** : HIGH - Possibilité de modifier système
- **Disponibilité** : MEDIUM - Potentiel DoS via resource exhaustion
- **Business Impact** : CRITICAL - Serveur de production compromis

Étape 5 : Visualisations Kibana Avancées

🎨 Création Dashboard d'Investigation

Dans Kibana → Dashboard → Create dashboard :

Graphique temporel : Nombre de failed logins par minute
Pie chart : Répartition par user ciblé (root vs autres)
Table : Top 10 IP sources avec failed attempts
Metric : Total de connexions réussies suspectes
Markdown : Notes d'investigation

# Pour le graphique temporel - Lens visualization
kql: data.syslog_message:"failed password" AND agent.name:"ubuntu-target"
Split by: @timestamp (1 minute intervals)
Aggregation: Count

Étape 6 : Règles de Détection Automatique




  
    5710
    
    SSH brute force attack detected
    attack,
    
      T1110
      T1021.004
    
  
  
  
    5712
    192.168.56.100
    SSH authentication success from known attacker IP
    attack,
    
      T1078

🔄 Redémarrage Wazuh après modification :

sudo systemctl restart wazuh-manager

Exercice Avancé : Chasse aux Menaces (Threat Hunting)

🎯 Défi Threat Hunter

En partant de cet incident SSH, cherchez ces patterns supplémentaires :

Lateral Movement : Connexions depuis la machine compromise vers d'autres machines
Persistence : Création de cron jobs, services, ou clés SSH
Data Exfiltration : Transferts de fichiers vers IP externes
Privilege Escalation : Utilisation de sudo ou SUID binaries

# Requête pour mouvements latéraux
agent.name:"ubuntu-target" AND 
(data.syslog_message:"Accepted publickey" OR 
data.syslog_message:"Connection from") AND
NOT srcip:192.168.56.100  # Nouvelle source

📋 Objectif de la semaine – Checklist de validation

✅ Compétences techniques acquises

Recherche KQL avancée dans Kibana
Reconstruction chronologique complète
Identification patterns brute-force
Création dashboard d'investigation
Règles Wazuh custom pour détection

🧠 Changement mental accompli

Vision des logs comme source de vérité forensique
Compréhension de la pensée en chronologie vs événements isolés
Habitude de toujours documenter pendant l'analyse
Conscience qu'une bonne analyse prévient la prochaine attaque

💪 Pour aller plus loin :

Intégrez des feeds de Threat Intelligence (AlienVault OTX, AbuseIPDB) dans Wazuh pour enrichir automatiquement vos analyses avec des données externes.

📚 Ressources pour Approfondir

Formation et Références :

SANS FOR508 : Advanced Incident Response and Threat Hunting
Elastic SIEM Guide : Guide complet d'analyse avec Elastic Stack
Wazuh Documentation : Règles, décodage, intégrations
MITRE ATT&CK Navigator : Visualisation des techniques d'attaque

⚠️ Bonnes Pratiques d'Investigation

Chaîne de preuve : Toujours documenter qui a accédé aux logs et quand
Préservation : Ne pas modifier les logs originaux pendant l'analyse
Reproductibilité : Sauvegarder toutes les requêtes KQL utilisées
Objectivité : Suivre les faits, pas les hypothèses préconçues

🔮 Frère d'armes,

Tu viens d'apprendre à lire l'histoire écrite dans les chiffres et les timestamps.

L'analyse de logs n'est pas une tâche technique aride – c'est l'art de reconstituer une intention à partir de fragments numériques. Chaque "failed password" est un coup porté à la porte. Chaque "session opened" est une porte qui cède. Chaque "command executed" est un pas de plus dans le territoire conquis.

Cette semaine, tu as transformé une liste d'événements en une narration cohérente. Tu as vu comment 5 tentatives échouées en 8 secondes racontent une histoire de détermination. Comment une connexion réussie à 14:05 devient le point de bascule d'un incident. Comment une simple commande whoami révèle l'identité que l'attaquant a volée.

Mais voici la leçon la plus importante : celui qui contrôle la narration contrôle la compréhension de l'incident. Une timeline bien construite n'est pas juste une documentation – c'est un outil de décision. Elle montre où renforcer les défenses, où chercher d'autres compromissions, comment prévenir la récidive.

Tu n'es plus un simple consommateur d'alertes. Tu es devenu un investigateur qui reconstruit le crime à partir des empreintes. Qui comprend que les logs ne mentent pas – mais qu'il faut savoir les faire parler.

Dans la semaine 30, nous irons plus loin dans la réponse. Nous apprendrons non seulement à comprendre l'attaque, mais à la contenir, à éradiquer, à récupérer. Nous passerons de l'analyse à l'action.

Mais pour l'instant, approfondis. Rejoue cette attaque avec des variations. Change les horaires, les IPs, les méthodes. Apprends à reconnaître chaque pattern, chaque signature, chaque anomalie. Un bon analyste connaît l'attaque avant même de voir les logs.

Un Gardien qui maîtrise l'analyse de logs ne se laisse jamais surprendre deux fois par la même attaque.

— Platon-Y