Permissions NTFS, partages SMB et ACLs : le modèle d'autorisation Windows

Règle d'or de l'évaluation des accès réseau

Lorsqu’un utilisateur accède à un fichier à travers le réseau via SMB :

Permission Effective = Plus restrictif entre [Permissions de Partage] ET [Permissions NTFS]

Un partage SMB configuré avec Everyone: Full Control ne représente une faille critique que si les permissions NTFS sous-jacentes autorisent également l’écriture. L’analyste doit impérativement auditer les deux niveaux.

Concept

Le modèle de sécurité des objets sous Windows repose sur les Descripteurs de Sécurité (Security Descriptors) attachés à chaque objet sécurisable. Un descripteur contient :

• Le Propriétaire (Owner SID) : l’entité qui possède le contrôle légal de l’objet et peut toujours en modifier la DACL.
• Le Groupe Principal (Group SID) : utilisé pour la compatibilité POSIX.
• La DACL (Discretionary Access Control List) : liste ordonnée d’entrées de contrôle d’accès (ACE) définissant qui a le droit (Allow) ou l’interdiction (Deny) d’effectuer quelles opérations.
• La SACL (System Access Control List) : liste d’ACEs définissant les règles d’audit (génération des événements forensiques de succès ou d’échec d’accès).

---

Pourquoi c’est important en DFIR

L’audit des permissions NTFS et des partages SMB permet de résoudre les questions centrales d’une investigation :

1. Reconstituer le périmètre d’exfiltration : déterminer avec certitude si un compte d’utilisateur compromis avait la capacité de lire des répertoires confidentiels.
2. Expliquer le déploiement d’un ransomware : si un ransomware chiffre un partage distant, analyser les ACLs permet de prouver quel compte a été utilisé pour déposer les fichiers chiffrés et écraser les originaux.
3. Identifier la persistance par altération de DACL : les attaquants modifient fréquemment les DACLs d’objets sensibles (ex: clé de registre Run, binaire d’un service système, ou objet Active Directory AdminSDHolder) en ajoutant une ACE GenericAll pour s’octroyer un accès permanent.

---

Comment ça fonctionne

1. Structure et évaluation d’une DACL

Le Moniteur de Référence de Sécurité (SRM) applique un algorithme strict d’évaluation des ACEs de haut en bas :

[Requête : Lecture + Écriture]
         │
         ▼
┌────────────────────────────────────────────────────────┐
│ 1. ACE Explicite : DENY Écriture (Groupe Stagiaires)   │ ──► Refus Immédiat de l'Écriture !
├────────────────────────────────────────────────────────┤
│ 2. ACE Explicite : ALLOW Lecture (jdoe)                │ ──► Droit de Lecture Accordé !
├────────────────────────────────────────────────────────┤
│ 3. ACE Héritée   : ALLOW Écriture (Users)              │ ──► Ignoré car Deny explicite rencontré
└────────────────────────────────────────────────────────┘

Ordre canonique des ACEs :

1. ACEs explicites de refus (Explicit Deny)
2. ACEs explicites d’autorisation (Explicit Allow)
3. ACEs héritées de refus (Inherited Deny)
4. ACEs héritées d’autorisation (Inherited Allow)

Dès qu’une ACE Deny correspondante est rencontrée, l’opération demandée est immédiatement rejetée. Dès que tous les bits de l’accès demandé ont été validés par des ACEs Allow, l’évaluation s’arrête avec succès. Si la fin de la DACL est atteinte sans que tous les droits demandés soient accordés, l’accès est rejeté par défaut.

2. Partages SMB vs permissions NTFS

Réseau (SMB) ──► [Permissions de Partage] ──► [Permissions NTFS] ──► Fichier sur disque

Scénario Partage	Scénario NTFS	Résultat Effectif Réseau	Résultat Effectif Local (Console)
Everyone : Read	Everyone : Full Control	Lecture seule	Contrôle total
Everyone : Full Control	Everyone : Read	Lecture seule	Lecture seule
Domain Users : Change	Domain Users : Modify	Modification (écriture)	Modification (écriture)
Everyone : Full Control	jdoe : Deny Write	Refus d’écriture pour jdoe	Refus d’écriture pour jdoe

---

Ce qui est possible

• Être propriétaire sans avoir le droit de lire : si la DACL retire tous les droits au propriétaire, celui-ci ne peut pas lire le fichier immédiatement. Cependant, en tant que propriétaire, il détient le droit fondamental WRITE_DAC : il peut réécrire la DACL pour se redonner les droits d’accès.
• Bypass des ACLs via SeBackupPrivilege : les logiciels de sauvegarde (et les attaquants qui en détiennent le privilège) ouvrent les fichiers avec le drapeau FILE_FLAG_BACKUP_SEMANTICS, ce qui force le noyau à ignorer la DACL.
• Créer des partages cachés : ajouter le symbole $ à la fin du nom de partage (ex: CONFIDENTIAL$) masque le partage lors de l’énumération réseau NetBIOS/SMB ordinaire, mais ne restreint en rien ses droits d’accès.

---

Ce qui n’est pas possible

• Outrepasser un deny explicite via une appartenance de groupe : si jdoe est dans Domain Admins (Allow), mais qu’une ACE explicite stipule jdoe : Deny, l’interdiction prime toujours.
• Écrire à travers le réseau si le partage est en lecture seule : même le compte Domain Admins ne peut pas modifier un fichier via un partage SMB restreint à Read.

---

Confusions fréquentes

Pièges d'investigation

1. Confondre une DACL vide et l’absence de DACL :
   • DACL vide (0 ACE) : personne n’a d’accès (Access Denied pour tous).
   • Absence de DACL (NULL DACL) : aucune sécurité configurée (Everyone: Full Control implicite).
2. Oublier le filtre UAC sur les partages administratifs : pour se connecter à ADMIN$ ou C$, un compte administrateur de domaine n’est pas bridé par l’UAC réseau. En revanche, un administrateur local non-RID-500 est bridé par LocalAccountTokenFilterPolicy et se verra refuser l’accès distant à C$ par défaut.

---

Artefacts / traces

Pour prouver l’accès effectif à un partage ou à un fichier sensible :

EventID: 5140 # Un objet de partage réseau a été accédé
ShareName: \\*\Finance
IpAddress: 192.168.1.105
SubjectUserName: jdoe

EventID: 5145 # Un objet de partage réseau a été vérifié (Audit détaillé)
ShareName: \\*\Finance
RelativeTargetName: Facturation\salaires_2026.xlsx
AccessMask: 0x120089 # ReadData, ReadEA, ReadAttributes, ReadControl
AccessList: %%4416 (ReadData)
SubjectUserName: jdoe
SubjectUserSid: S-1-5-21-111111111-222222222-333333333-1105

---

Méthodes d’investigation

1. Inspecter la DACL d’un fichier suspect avec icacls :

   icacls "C:\Partage\secret.docx"
   # Exemple de sortie :
   # CORP\jdoe:(I)(F)        <- F = Full Control, (I) = Hérité
   # CORP\Stagiaires:(N)     <- N = None (Deny)

2. Calculer les permissions effectives avec PowerShell :

   (Get-Acl -Path "C:\Partage\secret.docx").Access |
     Select-Object IdentityReference, AccessControlType, FileSystemRights, IsInherited

3. Lister les partages SMB et leurs permissions :

   Get-SmbShare
   Get-SmbShareAccess -Name "Finance"

---

Points clés à retenir

1. L’accès réseau est toujours borné par le filtre le plus strict entre partage SMB et NTFS.
2. L’ordre canonique place les refus explicites (Explicit Deny) au sommet de l’évaluation.
3. Le propriétaire d’un objet (Owner) peut TOUJOURS réécrire la DACL via WRITE_DAC.
4. L’event ID 5145 consigne le fichier spécifique et l’AccessMask réel demandé.

---

Références

• Microsoft Learn: How AccessCheck Works
• Fiche 05 : authentication vs authorization
• Fiche 06 : Windows access tokens and security context
• Fiche 07 : Windows groups and nested group membership