Le PAC Kerberos (privilege attribute certificate) : contenu, validation, falsification

Concept

Lorsqu’un utilisateur s’authentifie auprès du KDC Active Directory, le KDC assemble une structure de données binaire appelée PAC et l’insère dans la partie chiffrée du TGT, puis du TGS.

Le PAC contient :

Les identifiants de sécurité de l’utilisateur : son SID principal (UserSid), son groupe principal (PrimaryGroupId).
L’ensemble de ses appartenances à des groupes : la liste exhaustive de tous les RIDs de groupes de domaine auxquels l’utilisateur appartient (GroupIds), ainsi que les SIDs de domaines externes (ExtraSids / sIDHistory).
Les signatures cryptographiques de garantie :
- Server signature : signée avec la clé du service cible (prouve que le serveur n’a pas altéré le PAC).
- KDC signature : signée avec la clé krbtgt du KDC (prouve que c’est bien le KDC qui a généré le PAC).
- Ticket signature & full PAC signature (depuis CVE-2022-37967 / kb5020805) : signatures additionnelles introduites pour contrer définitivement les falsifications de PAC.

Pourquoi c’est important en DFIR

Le PAC est le point d’impact de nombreuses attaques d’élévation de privilèges majeures :

Falsification de PAC (golden / Diamond / silver tickets) : lorsqu’un attaquant possède la clé krbtgt ou la clé de compte d’un service, il peut forger un PAC de toutes pièces en s’auto-attribuant le SID S-1-5-21-...-512 (Domain Admins).
Vulnérabilités critiques historiques (MS14-068 / CVE-2014-6324 et CVE-2021-42287) : ces vulnérabilités permettaient à un simple utilisateur de demander au KDC de signer un PAC forgé ou de manipuler les noms de comptes machines (sAMAccountName spoofing / noPac) pour obtenir des droits d’administrateur de domaine en quelques secondes.
Validation du PAC par le service cible (PAC validation) : comprendre pourquoi un serveur applicatif contacte parfois le DC via RPC Netlogon pour valider un PAC permet d’expliquer des flux réseau et des logs apparemment contradictoires.

Comment ça fonctionne

Anatomie d’un PAC Kerberos (MS-PAC)

┌────────────────────────────────────────────────────────┐
│                   STRUCTURE DU PAC                     │
├────────────────────────────────────────────────────────┤
│ 1. PACTYPE Header (Nombre de buffers et version)       │
├────────────────────────────────────────────────────────┤
│ 2. KERB_VALIDATION_INFO (Logon Info Buffer) :          │
│    - User SID : S-1-5-21-DOM-1001                      │
│    - Group RIDs : [513, 1105, 1108]                    │
│    - sIDHistory / ExtraSids : [S-1-5-21-OLD-512]       │
│    - UserAccountControl flags                          │
├────────────────────────────────────────────────────────┤
│ 3. PAC_CLIENT_INFO (Nom du compte et timestamp logon)  │
├────────────────────────────────────────────────────────┤
│ 4. SERVER_SIGNATURE (Chiffrée avec la clé du Service)  │
├────────────────────────────────────────────────────────┤
│ 5. KDC_SIGNATURE (Chiffrée avec la clé krbtgt)         │
├────────────────────────────────────────────────────────┤
│ 6. PAC_ATTRIBUTES_INFO (Flags PAC, ex: PAC requesté)   │
├────────────────────────────────────────────────────────┤
│ 7. FULL_PAC_CHECKSUM (Signature cryptographique HMAC)  │
└────────────────────────────────────────────────────────┘

Le processus de vérification du PAC

Lors de la réception d’un TGS, le serveur cible déchiffre le ticket avec son propre secret de compte (clé machine ou compte de service).
Il vérifie la Server Signature du PAC.
Si la signature est valide, le Local Security Authority (LSA) du serveur extrait les SIDs du PAC et construit le Jeton d’accès (Access Token) de l’utilisateur pour la session.
Validation KDC (facultative historiquement) : pour les services sous privilèges locaux élevés, le serveur peut envoyer une requête RPC Netlogon LogonSamLogonEx au DC pour demander confirmation de la validité de la KDC Signature.

Ce qui est possible

Inspecter le contenu d’un PAC en mémoire : des outils DFIR ou de sécurité (ex: Mimikatz kerberos::list /export, Rubeus triage, ou Wireshark) permettent de décoder intégralement la structure ASN.1 / NDR d’un PAC Kerberos.
Forger n’importe quel groupe dans le PAC avec la clé krbtgt : posséder le hash ou la clé AES du compte krbtgt permet de générer un PAC contenant n’importe quel SID et de calculer la signature KDC légitime.
Forcer la validation stricte du PAC : les correctifs récents de Microsoft (mode Enforcement de CVE-2022-37967) rejettent systématiquement tout ticket ne comportant pas de signature Full PAC valide.

Ce qui n’est pas possible

Modifier le PAC d’un ticket en transit sans casser les signatures : un attaquant en position d’homme du milieu (MitM) ne peut pas modifier les SIDs d’un PAC sans invalider les signatures cryptographiques du serveur et du KDC.
Injecter un PAC forgé sur un service qui effectue la validation RPC netlogon sans posséder la clé KRBTGT : dans une attaque Silver Ticket (où seule la clé du service est connue), si le serveur cible envoie le PAC au DC pour vérification, le DC détecte la fausse signature KDC et rejette l’authentification.
Conserver des privilèges révoqués si le ticket expire : le PAC est figé au moment de la génération du ticket. Si un utilisateur est retiré d’un groupe dans l’Active Directory, ses droits persistent jusqu’à l’expiration du ticket de service en cours (généralement 10 heures), mais sont perdus dès le renouvellement.

Confusions fréquentes en DFIR

Confusion fréquente	Réalité forensique vérifiable
« Le ticket Kerberos prouve que l’utilisateur appartient actuellement à ces groupes dans l’annuaire. »	Non. Le PAC reflète l’état des groupes au moment de l’émission du TGT. Si l’attaquant a été retiré d’un groupe il y a 2 heures, son PAC en mémoire possède encore le RID du groupe jusqu’à expiration du ticket.
« Un Silver Ticket possède une signature KDC valide. »	Faux. L’attaquant qui forge un Silver Ticket ne possède pas la clé `krbtgt` ; il génère une signature KDC bidon. Le Silver Ticket ne fonctionne que si le serveur ne vérifie pas la signature auprès du DC.
« Tous les services vérifient le PAC auprès du contrôleur de domaine. »	La majorité des services applicatifs Windows ne vérifient que la Server Signature localement pour des raisons de performance réseau.

Exemple concret d’investigation

Lors d’un audit forensique post-intrusion, l’enquêteur extrait les tickets Kerberos résiduels en mémoire sur un serveur SQL compromis :

L’outil Rubeus.exe dump /luid:0x3e7 extrait un ticket de service présenté pour accéder au service MSSQLSvc/sql01.corp.local.
Le décodage du PAC révèle :
- Nom d’utilisateur déclaré : guest
- SIDs dans GroupIds : RID 512 (Domain Admins), RID 519 (Enterprise Admins).
- Signature KDC : algorithme HMAC-MD5 (RC4), alors que le domaine applique AES-256 depuis 5 ans.
Les logs du DC (Event 4769) pour ce timestamp ne montrent aucune demande de TGS pour guest ciblant sql01.
Conclusion irréfutable : le ticket a été forgé de toutes pièces hors-ligne (Silver Ticket) à l’aide du hash NTLM volé du compte de service SQL.

Artefacts et traces forensiques

Journaux de sécurité DC (événements de mise à jour et durcissement PAC) :
- Event ID 30 (Microsoft-Windows-Kerberos-key-distribution-center) : rejet d’un ticket présentant un PAC non signé ou non conforme aux exigences CVE-2022-37967.
- Event ID 31 : avertissement concernant un ticket présentant une signature PAC faible.
Journaux de sécurité des serveurs membres :
- Event ID 4624 : champ Security ID et groupes renseignés à partir du PAC décodé par la LSA.
Captures réseau (PCAP) :
- Champ padata de type PA-PAC-REQUEST (type 128) dans les messages AS-REQ et TGS-REQ.
- Structure binaire ASN.1 AuthorizationData de type AD-IF-RELEVANT encapsulant le PAC (type 1).

Méthodes d’investigation

Extraire et analyser les tickets Kerberos en mémoire : Utiliser des outils forensiques pour inspecter les SIDs encapsulés dans le PAC des sessions suspectes.
Vérifier les types de chiffrement du PAC : Détecter toute régression anormale vers RC4 (0x17) dans les signatures de tickets.
Surveiller les événements système Kerberos-key-distribution-center : Auditer les événements 30, 31, 32 dans le journal System des contrôleurs de domaine pour identifier des tentatives d’exploitation de faux PACs.

Outils d’investigation

Rubeus :

Rubeus.exe triage
Rubeus.exe dump /nowrap

Wireshark : Filtre : kerberos.pac.client_name ou inspection du champ kerberos.AuthorizationData.
Klist (Windows natif) :
Fenêtre de terminal
```
klist get cifs/dc01.corp.local
```

Points clés à retenir

Le PAC est l’extension Microsoft qui transporte les droits et groupes au sein des tickets Kerberos.
Le PAC est protégé par deux signatures cryptographiques fondamentales : la clé du Service et la clé krbtgt.
La possession de la clé krbtgt permet de forger n’importe quel PAC (Golden Ticket).
Les tickets forgés avec la seule clé de service (Silver Ticket) ont une fausse signature KDC.