Rutas de scripts de inicio de sesión AD: revisar scriptPath y ACL

Qué significan las rutas de scripts de inicio de sesión AD

Las rutas de scripts de inicio de sesión AD merecen un inventario y una revisión de responsabilidades antes de cambiar los permisos. Un atributo de usuario con valor indica dónde está configurado un script de inicio de sesión; no indica si el destino existe, si alguien sigue utilizándolo ni quién puede cambiar su contenido. Trate la ruta como el punto de partida para recopilar evidencias.

La referencia del esquema Script-Path de Microsoft identifica scriptPath como la ruta del script de inicio de sesión del usuario y permite una cadena nula. El parámetro ScriptPath de New-ADUser acepta una ruta local absoluta o una ruta UNC (Universal Naming Convention). Por tanto, un valor UNC es una opción de configuración documentada. Su presencia por sí sola no demuestra un control de acceso débil.

Las preguntas útiles son concretas: ¿qué usuario apunta a qué destino, quién es responsable de la función de negocio, qué clientes lo utilizan y qué entidades de seguridad pueden modificar ese destino? El responsable de la cuenta, quien mantiene el script y el administrador del servidor de archivos pueden ser personas distintas. Registre cada responsabilidad en lugar de suponer que el propietario del sistema de archivos también aprueba el uso de negocio.

Cómo funciona: distinguir asignación, contenido y uso

La revisión tiene tres niveles. El atributo del directorio asigna una ruta. El archivo referenciado y sus dependencias contienen las instrucciones. El comportamiento real del cliente al iniciar sesión determina si se utilizan esas instrucciones. La evidencia de un nivel no puede sustituir a la de los demás.

La técnica Network Logon Script de MITRE ATT&CK describe el abuso de scripts asignados mediante Active Directory o una directiva de grupo y recomienda limitar su escritura a los administradores designados. Describe la ejecución con los privilegios del usuario al que se asignan. No deduzca una ejecución como SYSTEM de un hallazgo sobre una ruta de red. Para investigar un posible abuso, establezca una capacidad no autorizada para alterar el script o redirigir su asignación y después determine que un cliente pertinente utiliza el contenido modificado. Este artículo no afirma que se haya producido ninguno de esos eventos.

Mantenga el scriptPath del usuario separado de los scripts configurados dentro de una GPO. Si interviene el despliegue de directivas, utilice la revisión independiente de Read, Apply y el ámbito de las GPO. Sus preguntas sobre Read para el equipo y Apply dirigido se refieren a la recuperación y aplicación de la directiva; no establecen quién puede reescribir el archivo referenciado por el atributo de un usuario.

Inspeccione también el contenido para identificar dependencias y credenciales expuestas mediante el proceso de revisión apropiado. La revisión existente de credenciales en archivos SYSVOL, incluidos los scripts aborda esa cuestión. Un inventario de rutas no puede establecer si un script contiene un secreto, y este flujo de trabajo no repite la investigación independiente de cPassword.

Detección: inventariar usuarios, resolver destinos e inspeccionar ambas ACL

1. Inventariar las rutas configuradas sin excluir a los usuarios deshabilitados

Ejecute los siguientes ejemplos desde un entorno administrativo Windows autorizado con los módulos pertinentes. Son ejemplos basados en la documentación, no comandos ejecutados contra un dominio de cliente. Sustituya el servidor, la base de búsqueda, las identidades y las rutas de ejemplo por valores aprobados.

La referencia de Get-ADUser documenta -LDAPFilter, -SearchBase, -Server y la recuperación de atributos adicionales con -Properties. Esta consulta inventaría los usuarios que tienen scriptPath, incluidas las cuentas deshabilitadas:

Get-ADUser -LDAPFilter '(scriptPath=*)' -SearchBase 'DC=example,DC=com' -Server 'dc01.example.com' -Properties scriptPath | Format-List -Property DistinguishedName,SamAccountName,Enabled,scriptPath

Una alternativa que utiliza la sintaxis de filtro del módulo es:

Get-ADUser -Filter 'scriptPath -like "*"' -SearchBase 'DC=example,DC=com' -Server 'dc01.example.com' -Properties scriptPath | Format-List -Property DistinguishedName,SamAccountName,Enabled,scriptPath

El patrón de presencia del atributo adapta los ejemplos de filtros de Active Directory de Microsoft. Format-List muestra las propiedades indicadas; conserve también el inventario subyacente en su sistema de evidencias aprobado. Registre el controlador de dominio consultado, la base de búsqueda, la hora de recopilación y cualquier error. Una consulta parcial o fallida no constituye un inventario completo.

Vincule cada usuario a la ruta y a un responsable. Mantenga visibles las cuentas deshabilitadas como casos de ciclo de vida: pregunte si la asignación se conserva para un retorno previsto, si se copió de una plantilla o si está obsoleta. No habilite una cuenta para probar su script. La asignación de un usuario deshabilitado no demuestra un uso actual; aun así, puede identificar un destino compartido con otros usuarios.

2. Resolver el destino en el contexto real del cliente

Conserve el valor literal del atributo antes de interpretarlo. Para una cadena relativa, identifique su base de resolución en el cliente y en el flujo de inicio de sesión pertinentes; no la resuelva respecto al directorio de trabajo de su consola administrativa. Para una ruta local absoluta, identifique el cliente en el que debería existir ese archivo. Para una ruta de red, identifique el servidor, el recurso compartido y el archivo realmente alcanzados por el cliente de prueba. Registre explícitamente los casos sin resolver.

Pregunte al responsable del mantenimiento de qué scripts, ejecutables, archivos de configuración u otros recursos depende el punto de entrada. Revise también esos destinos. Cambiar solo la ACL del punto de entrada es insuficiente si una dependencia no revisada proporciona las instrucciones que utiliza el script.

Tras resolver un archivo candidato, este ejemplo utiliza los parámetros documentados de Test-Path:

Test-Path -LiteralPath '\\files01.example.com\LogonScripts\onboarding.cmd' -PathType Leaf

Leaf comprueba un destino de tipo archivo; -LiteralPath evita interpretar comodines. Registre la identidad, el cliente y los errores junto al resultado. Esta comprobación de existencia no demuestra una ejecución satisfactoria al iniciar sesión, la corrección del script ni permiso para modificar el archivo. Confirme el uso real mediante un piloto aprobado con el responsable del script.

3. Inspeccionar por separado los permisos del recurso compartido y del sistema de archivos

En el servidor de archivos identificado, utilice Get-SmbShare para relacionar el nombre del recurso compartido con su ruta local. Después, utilice Get-SmbShareAccess para recuperar su ACL de recurso compartido. Estos ejemplos adaptan las consultas -Name documentadas:

Get-SmbShare -Name 'LogonScripts' | Format-List -Property Name,ScopeName,Path

Get-SmbShareAccess -Name 'LogonScripts'

Ejecútelas en el servidor que realmente aloja el destino. Si se trata de un recurso compartido con ámbito específico, identifique ese ámbito y utilice el parámetro -ScopeName documentado. Un recurso compartido de nombre similar en otro servidor no es evidencia para este destino. Conserve cada entidad beneficiaria, entrada Allow o Deny y nivel de acceso.

Para NTFS, Get-Acl recupera el descriptor de seguridad del recurso en Windows. Tras confirmar la ruta local real, inspeccione el archivo y el directorio que lo contiene:

Get-Acl -LiteralPath 'D:\LogonScripts\onboarding.cmd' | Format-List -Property *

Get-Acl -LiteralPath 'D:\LogonScripts' | Format-List -Property *

Son ejemplos, no una afirmación de que este recurso compartido corresponda a D:\LogonScripts. Recopile la propiedad, las entradas de acceso y la herencia. Resuelva los grupos detrás de cada entidad beneficiaria antes de concluir qué usuarios pueden cambiar el contenido. El listado de ACL es evidencia para esa revisión, no una simulación del acceso efectivo de cada identidad.

El modelo de seguridad de archivos de Microsoft evalúa los derechos solicitados respecto al token del llamador y al descriptor del objeto. Sus constantes de derechos de acceso a archivos distinguen entre escribir datos de archivo, crear archivos en un directorio y eliminar elementos secundarios. Revise la capacidad para alterar o reemplazar contenido, además de la administración de permisos; leer el script es una cuestión distinta. Inspeccione conjuntamente las evidencias del recurso compartido y de NTFS para la vía de acceso específica.

Remediación: revisar primero y después realizar una corrección dirigida (Remediation)

1. Acordar el comportamiento previsto y quién puede escribir

Para cada asignación, registre el responsable de negocio, la población de clientes prevista, los responsables de mantenimiento aprobados y el acceso de lectura necesario. Clasifíquela como necesaria, obsoleta o sin resolver. Mantenga visible la incertidumbre en lugar de tratarla como permiso para eliminar. Un destino compartido puede tener varios consumidores, por lo que debe coordinar su cambio con cada responsable afectado.

2. Conservar un estado de reversión y probar el cambio en un piloto

Conserve el atributo actual, el contenido del destino, las dependencias y ambos conjuntos de permisos mediante su proceso de copia de seguridad aprobado. Elija un usuario de prueba habilitado y un cliente representativos. Defina el resultado esperado y las condiciones de fallo antes del piloto. Para las cuentas deshabilitadas, utilice una decisión de ciclo de vida en lugar de una prueba de inicio de sesión forzada.

3. Corregir el problema verificado en su origen

Si el destino es necesario pero una entidad no prevista puede cambiarlo, haga que el responsable del servidor de archivos corrija la concesión específica del recurso compartido o de NTFS mediante el procedimiento de cambio aprobado. Revise las concesiones heredadas y las dependencias antes de seleccionar el cambio. La mitigación de MITRE respalda restringir quién puede escribir los scripts; no prescribe una ACL universal para todos los entornos.

Si la asignación apunta a un destino incorrecto, cambie el atributo de ese usuario solo después de validar el reemplazo. La siguiente vista previa utiliza los parámetros ScriptPath y WhatIf documentados de Set-ADUser:

Set-ADUser -Identity 'CN=PilotUser,OU=Users,DC=example,DC=com' -Server 'dc01.example.com' -ScriptPath '\\files01.example.com\LogonScripts\approved.cmd' -WhatIf

-WhatIf muestra una vista previa de la operación sin aplicarla. Este comando es una opción para corregir una asignación aprobada, no una recomendación de migrar a todos los usuarios a rutas UNC. Si una asignación está obsoleta, retírela mediante el procedimiento de gestión de cuentas acordado después de comprobar las dependencias compartidas. No elimine un archivo referenciado solo porque un usuario ya no lo necesite.

4. Volver a leer la configuración y verificar el comportamiento autorizado

Vuelva a consultar al usuario concreto después del cambio aprobado:

Get-ADUser -Identity 'CN=PilotUser,OU=Users,DC=example,DC=com' -Server 'dc01.example.com' -Properties scriptPath | Format-List -Property DistinguishedName,Enabled,scriptPath

Vuelva a leer ambas ACL si cambiaron los permisos. Repita la prueba de cliente aprobada por el responsable y valide la recuperación necesaria y el comportamiento esperado. Cuando corresponda, verifique que una entidad no prevista para escribir carece de acceso efectivo de modificación mediante el procedimiento autorizado de pruebas de acceso de la organización. Conserve el contexto de prueba, los resultados, las excepciones y la decisión de reversión junto al inventario. Volver a leer el atributo por sí solo no puede validar los efectos del script.

Cómo detecta EtcSec este caso

La comprobación DANGEROUS_LOGON_SCRIPTS de EtcSec proporciona una lista para revisar. En el commit 15fc6399c215eabc415c370b762303cfcd7a353a de etc-collector, dangerous-logon-scripts.go:46 recorre los usuarios proporcionados y selecciona un ScriptPath no vacío si contiene dos barras inversas consecutivas en cualquier posición o empieza por //. La rama de barras inversas no exige un prefijo UNC estricto. El hallazgo es Medium y Count es el número de usuarios coincidentes, no de archivos distintos ni de recursos compartidos vulnerables.

No hay un filtro Disabled en este Detect(). Por tanto, los usuarios deshabilitados pueden aparecer cuando se proporcionan en los datos de auditoría. Una ruta vacía no coincide; las rutas relativas y otras cadenas fuera del predicado pueden quedar fuera de esta lista de revisión. A la inversa, una cadena coincidente no demuestra un destino UNC válido y accesible.

El proveedor LDAP solicita scriptPath en parser.go:49, lo copia a ScriptPath en parser.go:171 y recupera usuarios mediante client.go:460. Esta comprobación no lee el archivo de destino, la ACL del recurso compartido, la ACL NTFS ni la ejecución efectiva. Su salida no puede confirmar un acceso de escritura no autorizado, una persistencia satisfactoria ni una ejecución como SYSTEM. El ámbito y la integridad de la recopilación también limitan lo que representa la lista.