Authentification vs autorisation : la frontière décisive en DFIR

Axiome forensique fondamental

Une authentification réussie ne prouve JAMAIS qu’une action malveillante a été autorisée OU exécutée.

L’authentification valide uniquement une preuve d’identité cryptographique. L’autorisation détermine si cette identité possède le droit d’accéder à l’objet. L’investigation DFIR doit obligatoirement prouver les deux étapes de manière indépendante :

Authentification (Qui ?) ≠ Autorisation (Permis ?) ≠ Accès (Touché ?) ≠ Action (Modifié/Exfiltré ?)

Concept

Dans tout système de sécurité informatique moderne, et particulièrement dans l’architecture Windows NT et Active Directory, deux mécanismes distincts et séquentiels s’enchaînent :

1. L’Authentification (Authentication / AuthN) — « Qui êtes-vous ? » : Le processus par lequel un principal de sécurité prouve son identité auprès d’une autorité de sécurité (SAM locale ou KDC Kerberos) au moyen d’un secret partagé (mot de passe), d’une clé cryptographique ou d’un certificat. Le résultat d’une authentification réussie est la création d’une session d’ouverture de session (Logon Session) et l’émission d’un jeton d’accès (Access Token).
2. L’Autorisation (Authorization / AuthZ) — « Que pouvez-vous faire ? » : Le processus par lequel le système d’exploitation (via le SRM - Security Reference Monitor) compare les SIDs et privilèges contenus dans le jeton d’accès de l’utilisateur avec la liste de contrôle d’accès discrétionnaire (DACL) de l’objet cible (fichier, clé de registre, service, partage réseau).

---

Pourquoi c’est important en DFIR

L’amalgame entre authentification et autorisation conduit fréquemment à des conclusions erronées lors de l’analyse d’incidents :

• L’illusion de la compromission totale : constater dans Security.evtx qu’un compte attaquant a généré un succès de connexion réseau (Event ID 4624, Logon Type 3) sur un serveur financier ne prouve pas qu’il a accédé aux données comptables. Si les partages et les fichiers possèdent des DACLs restrictives interdisant ce compte, toutes ses tentatives d’accès ont été rejetées avec un code d’erreur ACCESS_DENIED.
• L’incompréhension des scans NetExec : comme détaillé dans la Fiche 23 : NetExec: What Do the Results Actually Prove?, un voyant vert [+] dans NetExec atteste uniquement d’une authentification réussie, tandis que le tag Pwn3d! atteste d’une autorisation administrative (écriture dans ADMIN$ ou C$).
• Traversée de trust : l’existence d’une relation d’approbation entre le Domaine A et le Domaine B permet l’authentification cross-domaine, mais n’accorde par défaut aucun droit d’accès sur les serveurs du Domaine B (voir Fiche 13 : Active Directory Trust Fundamentals).

---

Comment ça fonctionne

Le cycle d’évaluation Windows

[Utilisateur / Client]
         │
         │ 1. Présentation des credentials (Kerberos AS-REQ ou NTLM Negotiate)
         ▼
[Autorité de Sécurité (DC / SAM)] ───────► Authentification (AuthN)
         │                                 Émet : Logon Session + Access Token
         │ 2. Requête d'accès à une ressource (\\FS01\Finances)
         ▼
[Moniteur de Référence de Sécurité (SRM)] ──► Autorisation (AuthZ)
         │                                   Compare : Token (SIDs + Privs) vs DACL
         ├─► Accès Accordé (STATUS_SUCCESS) ──► Événement 4624 + 5140/5145
         └─► Accès Refusé (STATUS_ACCESS_DENIED) ─► Événement 4624 + 5145 (Échec)

1. Identification : l’utilisateur soumet son nom d’utilisateur CORP\alice.
2. Authentification : le KDC valide le secret (hash Kerberos) et insère dans le ticket PAC les SIDs de tous les groupes dont alice est membre.
3. Logon local : sur le serveur cible, LSASS transforme le PAC en un Jeton d’accès local (Access Token).
4. Autorisation : alice tente d’ouvrir D:\Finances\bilan.xlsx. Le pilote système compare les SIDs du jeton aux ACEs (Access Control Entries) du fichier. Si aucun groupe d’alice n’a de droit de lecture ou si une entrée Deny existe, l’accès est bloqué.

---

Ce qui est possible

• Être authentifié avec zéro droit d’accès : un utilisateur invité ou un utilisateur standard d’un domaine externe approuvé peut s’authentifier sur un serveur (Event 4624) sans avoir le droit de lire le moindre fichier ni d’énumérer les partages.
• Être autorisé sans être administrateur : un compte peut disposer des permissions complètes sur une base de données ou un dossier sans avoir le moindre privilège local d’administration.
• Échouer à l’autorisation tout en restant connecté : une session réseau reste ouverte même si des centaines de requêtes de lecture de fichiers sont rejetées par ACCESS_DENIED.

---

Ce qui n’est pas possible

• Être autorisé sans authentification préalable (hors null session / anonyme) : le SRM Windows refuse d’évaluer une requête d’accès sur un objet sécurisé sans un jeton d’accès valide rattaché au thread demandeur.
• Modifier une autorisation sans détenir le droit WRITE_DAC : l’attribution de droits sur un objet requiert d’en être le propriétaire (Owner) ou d’avoir explicitement la permission de modifier sa liste de contrôle d’accès.

---

Confusions fréquentes

Pièges majeurs en DFIR

1. Confondre event 4624 et accès aux données : l’Event ID 4624 consigne la création d’une session de connexion, pas l’ouverture d’un fichier. Pour prouver l’accès au fichier, l’analyste doit rechercher les événements de partage (5140 / 5145) ou l’audit d’accès aux objets (4663).
2. Croire qu’un compte désactivé peut être autorisé : la désactivation d’un compte dans l’AD bloque immédiatement l’authentification (phase 1). Même si le compte reste présent dans toutes les ACLs (phase 2), il ne peut plus jamais générer de jeton d’accès.

---

Exemple concret : l’attaque sans accès

Lors d’un audit post-incident après une attaque de type Akira :

• L’attaquant a volé les identifiants d’un compte de prestataire : CORP\prestataire_vpn.
• Il utilise l’outil NetExec pour sonder 50 serveurs internes : nxc smb 192.168.1.0/24 -u prestataire_vpn -p P@ssword123
• Sur les 50 serveurs, NetExec affiche du vert [+] : l’authentification réussit partout (Event 4624 sur chaque machine).
• Cependant, le compte prestataire_vpn ne fait partie d’aucun groupe d’administration et les partages administratifs ADMIN$ et C$ lui sont strictement interdits. Aucun voyant Pwn3d! n’apparaît.
• L’attaquant n’a pu déposer aucun payload, ni exécuter de commande, ni lire de données confidentielles.

Conclure à la compromission des 50 serveurs serait une erreur forensique majeure : seule l’identité du prestataire a été compromise, tandis que les barrières d’autorisation des serveurs ont parfaitement résisté.

---

Artefacts / traces

Étape	Événement Security.evtx	Description & Interprétation Forensique
Authentification réussie	Event ID 4624	Création de session (vérifier LogonType: 3 et TargetUserName).
Authentification échouée	Event ID 4625	Mauvais mot de passe, compte verrouillé ou désactivé (Status / SubStatus).
Tentative d’autorisation sur partage	Event ID 5140	Un partage réseau a été accédé.
Évaluation détaillée de l’autorisation	Event ID 5145	Vérifier AccessMask : 0x1 (Read), 0x2 (Write), 0x12019f (Full Control). Un échec génère un code Access Denied.
Accès objet local	Event ID 4663	Tentative d’accès à un fichier spécifique après contrôle DACL.

---

Méthodes d’investigation

1. Rechercher les succès d’authentification suivis de refus d’autorisation :

   # Détecter les événements de partage avec accès refusé pour un utilisateur suspect
   Get-WinEvent -FilterHashtable @{LogName='Security';Id=5145} | Where-Object {
       $_.Properties[14].Value -like "*Access Denied*" -and $_.Properties[1].Value -eq "prestataire_vpn"
   }

2. Corréler le LogonId : Le champ TargetLogonId de l’événement 4624 est le lien pivot qui se retrouve dans tous les événements 5145 ou 4663 ultérieurs générés par cette même session.

---

Points clés à retenir

1. L’authentification valide le secret de l’identité, l’autorisation valide les droits d’action.
2. L’event ID 4624 prouve la connexion, JAMAIS le vol OU la modification de données.
3. L’évaluation d’autorisation s’effectue localement sur le serveur hébergeant la ressource à partir du jeton d’accès.
4. NetExec [+] = authentification réussie ; Pwn3d! = autorisation administrative validée.

---

Références

• Microsoft Learn: Security Reference Monitor Architecture
• Fiche 06 : Windows access tokens and security context
• Fiche 08 : NTFS permissions, share permissions and ACLs
• Fiche 23 : netExec : what do the results actually prove?