GREY-X // WINDOWS LAB

icacls — WINDOWS FILESYSTEM PERMISSIONS

Sous Windows, avoir accès à un fichier ne signifie pas forcément pouvoir le modifier.

L’accès dépend notamment des permissions NTFS appliquées aux fichiers et aux répertoires.

La commande native :

icacls

permet d’afficher et de modifier ces permissions.

En cybersécurité, elle est particulièrement intéressante pour répondre à une question fondamentale :

QUI PEUT FAIRE QUOI ?

01 // Afficher les permissions

#

La syntaxe la plus simple :

icacls C:\Lab

Exemple :

C:\Lab
    NT AUTHORITY\SYSTEM:(I)(F)
    BUILTIN\Administrators:(I)(F)
    LAB\alice:(I)(M)
    LAB\bob:(I)(RX)

On peut alors identifier :

SYSTEM
Administrators
alice
bob

et surtout leurs niveaux d’accès.

02 // Comprendre les lettres

#

Les permissions les plus courantes sont :

F   → Full access
M   → Modify
RX  → Read & Execute
R   → Read
W   → Write
D   → Delete

Par exemple :

LAB\alice:(M)

signifie que alice dispose de droits de modification.

Alors que :

LAB\bob:(RX)

indique principalement :

Read
+
Execute

03 // Le fameux (I)``

#

Dans une sortie icacls, on rencontre souvent :

(I)

Par exemple :

LAB\alice:(I)(M)

I signifie :

Inherited

La permission est donc héritée d’un dossier parent.

On peut visualiser :

C:\Lab
   │
   └── Projects
          │
          └── script.ps1

Une permission définie sur :

C:\Lab

peut être héritée par :

C:\Lab\Projects

puis par :

script.ps1

L’héritage est donc un élément essentiel de l’analyse des permissions Windows.

04 // Analyser un fichier

#

Pour examiner un fichier précis :

icacls C:\Lab\config.txt

Exemple :

C:\Lab\config.txt
    NT AUTHORITY\SYSTEM:(F)
    BUILTIN\Administrators:(F)
    LAB\alice:(M)
    LAB\bob:(R)

On peut alors construire une matrice simple :

SYSTEM          → Full
Administrators  → Full
alice           → Modify
bob             → Read

Cette information devient particulièrement importante lorsque le fichier contient :

configuration
scripts
credentials
backups
logs
secrets

05 // Pourquoi c'est intéressant en Red Team ?

#

Imaginons :

C:\Program Files\APP\

avec :

LAB\user:(M)

Un utilisateur standard disposant de droits de modification sur un emplacement sensible peut représenter un problème de sécurité.

Pourquoi ?

Parce qu’une application ou un service peut utiliser des fichiers présents dans ce répertoire.

La chaîne de risque peut alors ressembler à :

Weak ACL
   ↓
User can modify file
   ↓
Application consumes file
   ↓
Security impact

L’objectif d’un pentest est donc de rechercher les permissions excessives, puis d’évaluer leur impact réel.

06 // Vérifier récursivement

#

Pour analyser un répertoire et son contenu :

icacls C:\Lab /T

/T signifie que l’analyse est effectuée récursivement.

On peut ainsi parcourir :

C:\Lab
├── config
│   ├── app.ini
│   └── database.ini
├── scripts
│   ├── backup.ps1
│   └── deploy.ps1
└── backup
    └── server.zip

et examiner les ACL de chaque élément.

Pour un audit, c’est particulièrement pratique.

07 // Rechercher les permissions problématiques

#

L’objectif n’est pas seulement de lire la sortie.

Il faut rechercher des situations comme :

Users:(M)
Everyone:(F)
Authenticated Users:(M)

sur des emplacements sensibles.

Par exemple :

C:\Program Files\APP

avec :

Users:(M)

mérite une analyse.

Mais attention :

Une permission dangereuse en apparence ne constitue pas automatiquement une vulnérabilité exploitable.

Il faut comprendre :

QUI
 ↓
A QUEL DROIT
 ↓
SUR QUEL OBJET
 ↓
UTILISÉ PAR QUOI
 ↓
AVEC QUEL IMPACT

08 // Vérifier un répertoire sensible

#

Dans un laboratoire :

icacls "C:\Program Files"

Puis :

icacls "C:\Program Files\NomApplication"

On peut comparer les permissions :

Parent
  ↓
Application
  ↓
Executable
  ↓
Configuration

Cette approche permet de repérer les différences d’ACL entre les différents niveaux.

09 // Modifier une permission

#

icacls ne sert pas uniquement à lire les ACL.

Il permet également de les modifier.

Par exemple :

icacls C:\Lab /grant LAB\alice:(M)

Cette commande accorde à alice le droit :

Modify

sur le répertoire.

Pour un laboratoire, cela permet de comprendre concrètement comment évoluent les ACL.

10 // Retirer une permission

#

Pour retirer une entrée :

icacls C:\Lab /remove LAB\alice

Il est également possible d’utiliser :

icacls C:\Lab /grant:r LAB\alice:(R)

Le :r permet de remplacer les autorisations explicites existantes pour cet utilisateur par celles spécifiées.

Exemple :

Avant
LAB\alice → Modify

Après
LAB\alice → Read

11 // Héritage des permissions

#

L’héritage est un concept fondamental.

Pour désactiver l’héritage :

icacls C:\Lab /inheritance:d

Pour le réactiver :

icacls C:\Lab /inheritance:e

Il faut cependant être prudent avec les modifications d’ACL.

Une mauvaise manipulation peut provoquer :

accès refusé
application cassée
service inaccessible
héritage incorrect

Dans un environnement réel, les ACL doivent donc être modifiées avec précaution.

12 // Sauvegarder les ACL

#

Dans un audit, il peut être utile de sauvegarder les permissions avant modification :

icacls C:\Lab /save C:\Temp\lab-acl.txt /T

Cela permet de conserver une représentation des ACL.

On peut ensuite restaurer les permissions avec :

icacls C:\ /restore C:\Temp\lab-acl.txt

La restauration doit évidemment être réalisée avec prudence et sur le bon périmètre.

13 // Le lien avec net share

#

C’est ici que icacls, net share et net use deviennent particulièrement intéressants ensemble.

On peut avoir :

             WINDOWS SERVER
                  │
          ┌───────┴───────┐
          ▼               ▼
      net share        NTFS ACL
          │               │
          ▼               ▼
       SMB SHARE       icacls
          │               │
          └───────┬───────┘
                  ▼
             EFFECTIVE
              ACCESS

Exemple :

Share Permissions
        +
NTFS Permissions
        ↓
Effective Access

C’est pourquoi voir :

\\SERVER\Backup

ne suffit pas.

Il faut également comprendre :

Qui peut accéder ?
Qui peut lire ?
Qui peut écrire ?
Qui peut modifier ?
Qui peut supprimer ?

14 // Mini-lab GREY-X

#

Créer un environnement :

mkdir C:\Lab
echo GREY-X > C:\Lab\test.txt

Afficher les permissions :

icacls C:\Lab

Puis :

icacls C:\Lab\test.txt

Créer un utilisateur de laboratoire :

net user labuser "LabPassword123!" /add

Accorder un accès en lecture :

icacls C:\Lab /grant labuser:(R)

Vérifier :

icacls C:\Lab

Puis modifier :

icacls C:\Lab /grant:r labuser:(M)

Observer la différence.

Enfin, nettoyer le laboratoire :

icacls C:\Lab /remove labuser
net user labuser /delete

L’objectif est de voir concrètement la différence entre :

Read
Modify
Full Control

15 // Une ACL n'est pas une vulnérabilité

#

C’est une distinction importante en pentest.

Trouver :

Users:(M)

ne signifie pas automatiquement :

RCE

ou :

Privilege Escalation

Il faut analyser le contexte.

Par exemple :

User can modify file
        ↓
Quel fichier ?
        ↓
Qui l'utilise ?
        ↓
Quel processus le charge ?
        ↓
Avec quels privilèges ?
        ↓
Quel impact ?

C’est cette analyse qui permet de transformer une mauvaise configuration en véritable finding de sécurité lorsqu’un impact démontrable existe.

16 // Côté Blue Team

#

Pour le défenseur, icacls permet d’auditer rapidement les permissions :

icacls C:\Important

Puis récursivement :

icacls C:\Important /T

Il faut notamment rechercher :

Everyone
Users
Authenticated Users

avec des permissions trop larges sur :

applications
scripts
services
configurations
sauvegardes
répertoires système

La règle générale reste :

Least Privilege
        +
Controlled Inheritance
        +
Regular ACL Review

17 // Commandes essentielles

#

icacls C:\Lab

→ afficher les ACL.

icacls C:\Lab /T

→ analyser récursivement.

icacls C:\Lab /grant user:(R)

→ accorder la lecture.

icacls C:\Lab /grant user:(M)

→ accorder la modification.

icacls C:\Lab /remove user

→ supprimer une entrée.

icacls C:\Lab /inheritance:d

→ désactiver l’héritage.

icacls C:\Lab /inheritance:e

→ activer l’héritage.

icacls C:\Lab /save C:\Temp\acl.txt /T

→ sauvegarder les ACL.

18 // La chaîne complète

#

Avec les trois commandes :

net share

on découvre ce que Windows partage.

net use

on observe les connexions aux ressources réseau.

icacls

on analyse les permissions NTFS.

On obtient alors :

             WINDOWS
                │
        ┌───────┼────────┐
        ▼       ▼        ▼
    net share  net use  icacls
        │       │        │
        ▼       ▼        ▼
     SHARES  SESSIONS   ACLs
        │       │        │
        └───────┼────────┘
                ▼
          ACCESS CONTROL
                │
                ▼
          SECURITY REVIEW

net share montre l’exposition.

net use montre les connexions.

icacls montre les permissions.

Et c’est précisément la combinaison des trois qui permet de mieux comprendre la surface d’accès d’un environnement Windows.

GREY-X — Enumerate. Inspect. Understand. Secure.