icacls: rewriting NTFS permissions to read a file

icacls es la utilidad de Windows para ver y modificar las listas de control de acceso (ACL) de ficheros y carpetas NTFS. En post-explotación resuelve un problema concreto y frecuente: tener una sesión privilegiada pero no poder leer un fichero porque su ACL no incluye a tu identidad. Si tienes permiso para cambiar la ACL, te concedes acceso y lees.

Por qué SYSTEM no siempre puede leer todo. Es un error común creer que NT AUTHORITY\SYSTEM lo abre todo. El acceso a un fichero lo decide su ACL, no el "rango" de la cuenta: si la ACL de root.txt solo concede Administrator y al usuario que lo creó, una shell como SYSTEM recibe Access is denied. Lo que sí da poder a SYSTEM/Administrator es la capacidad de tomar posesión y reescribir la ACL.

La maniobra. Conceder control total a tu identidad sobre el fichero y leerlo:

icacls root.txt                                  # ver la ACL actual (quien puede leer)
takeown /f root.txt                              # apropiarse si no eres el dueno
icacls root.txt /grant "nt authority\system":F   # concederte control total
type root.txt
accesschk.exe -quv "%username%" C:\ruta          # buscar objetos donde puedes reescribir la ACL

/grant <user>:F añade una ACE de control total (F); si hiciera falta apropiarse primero, se usa takeown /f <file>. Tras el cambio, la lectura ya no se deniega.

Cuándo aparece. Es el remate típico de cajas donde se llega a SYSTEM por un servicio (por ejemplo, psexec.py tras reutilizar una contraseña) pero la flag tiene una ACL restrictiva que excluye a SYSTEM. También sirve para abrir ficheros de configuración o credenciales protegidos.

Indicio frente a prueba. Access is denied no significa "imposible": indica que esa identidad no está en la ACL. La prueba de que puedes saltártelo es poder ejecutar el /grant con éxito (Successfully processed 1 files), lo que confirma que tienes WRITE_DAC/propiedad sobre el objeto.

Cómo detectarlo. Con auditoría de acceso a objetos activada, el cambio de ACL genera el Event ID 4670 ("se cambiaron los permisos de un objeto") y la toma de posesión el 4674/uso de SeTakeOwnershipPrivilege; la ejecución de icacls /grant o takeown queda en 4688 (creación de proceso) y, con Sysmon, en el Event ID 1 con la línea de comando completa. La firma es un /grant sobre un fichero sensible (root.txt, web.config, un .kdbx) por una cuenta que acaba de obtener privilegios, seguido de su lectura (4663 de lectura sobre el mismo objeto). Un takeown seguido de icacls /grant sobre ficheros que la cuenta no creó es el patrón inconfundible.

Defensa. Mantener ACL mínimas no evita esto frente a SYSTEM/Administrador (pueden reescribirlas), así que la mitigación real es no dejar que un atacante llegue a esas identidades; auditar cambios de ACL (takeown/icacls, eventos 4670/4674) con registro de eventos. Relacionado con abuso de SeImpersonatePrivilege y reutilización de credenciales.