En Windows existen ciertos recursos compartidos establecidos por defecto con intenciones administrativas. Entre ellos está el conocido C$ (C dolar, el símbolo “$” indica que se trata de un recurso que el sistema mantiene “oculto”), que seguramente muchos usaríamos para poder conectarnos al equipo remoto de una red de forma subyacente al usuario de ese equipo, básicamente tener acceso a su disco del sistema C: (letra de unidad asignada por defecto en sistemas Windows).
Podemos ver en la consola de Microsoft (fsmgmt.msc) de “Carpetas compartidas”, los recursos que por defecto son compartidos, donde veremos el conocido c$ (C dolar) entre otros.
Figura 1: Consola Microsoft fsmgmt.msc “Carpetas compartidas”.
Para que esta conexión sea posible, aparte de tener las debidas configuraciones de red bien configuradas como veremos más adelante. Hablando en este caso de una “red privada o doméstica” es necesario una de las dos siguientes posibilidades:
- Conocer el usuario y contraseña con privilegios administrativos de la máquina remota.
- Crear un usuario y contraseña igual que el usuario con el que intentamos conectarnos al equipo remoto.
En este caso nos quedaremos con la opción más cómoda que sería la de añadir el usuario al equipo remoto.
En el caso de formar parte de una red de dominio, esto se debería administrar con grupos en el propio controlador de dominio (DC). En este caso podríamos crear un grupo en el que incluiríamos a los usuarios administrativos y ese grupo incluirlo en grupo de administradores de forma manual o por algún script mediante GPOs en los equipos de la red de Dominio.
Escenario de ejemplo:
- Equipo: PLUTON | Usuario activo: maria
- Equipo: JUPITER | Usuario activo: juan
En el siguiente ejemplo, de una red privada, el usuario activo en el equipo local es “juan” (equipo: Jupiter), pero el usuario remoto con el que queremos acceder desde el cliente es “maria” (del equipo: Pluton, pero que se creará también en el equipo Jupiter). Por lo que en el equipo remoto crearíamos una cuenta de usuario con la misma contraseña que la del equipo donde queremos acceder y lo agregamos al grupo de Administradores, de modo que haya una coherencia entre este usuario en ambas máquinas.
Figura 2: Usuarios administradores del equipo remoto.
Hasta este punto todo correcto. Pero cuando intentamos acceder con el usuario y contraseña del mismo que el del equipo remoto aunque exista dicha coherencia de credenciales igualmente, por seguridad, nos solicita usuario y contraseña a través del UAC. Por lo que queremos es evitar o eludir el UAC en este caso.
Escribiendo en una ventana de ejecución el nombre o dirección IP del equipo remoto seguido del recurso compartido C$: \\equipo_remoto\c$.
Figura 3: Ejecutando el recurso compartido C$ hacia un equipo remoto de la misma red.
En sistemas Windows XP dentro de una red era común si teníamos los suficientes privilegios en un usuario frente a un equipo remoto el poder acceder a su disco C: (letra de unidad asignada por defecto a un sistema Windows) ya que este por defecto se compartía.
Esto a partir de Windows Vista en adelante con la incorporación del sistema UAC (User Account Control) nos solicita, por seguridad, que nos autentiquemos con un usuario privilegiado de la máquina remota y por lo tanto confirmemos las credenciales del usuario con el que intentamos acceder a la máquina remota. En siguiente caso el usuario maria del equipo Pluton quiere conectarse al equipo Jupiter.
Figura 4: Autenticación de login con UAC para el acceso al recurso compartido C$.
Para poder eludir el UAC, solamente en este caso, podremos hacerlo fácilmente añadiendo un valor con un dato específico en una clave concreta del registro de Windows. Pero antes comentaré algunas configuraciones previas a tener en cuenta para todos los equipos de red o en los que queramos tener este tipo de acceso.
Antes de establecer la clave de registro oportuna, revisamos la configuración de la red privada para comprobar si está todo bien establecido, por defecto cuando nos unimos a un grupo de trabajo de una red privada o de hogar esto se autoconfigura correctamente.
En el caso de usar una red privada, formar parte de un grupo de trabajo o grupo del hogar, nos centraremos en la configuración de uso compartido avanzado de este. En el apartado privado (que sería el que correspondería en este caso) comprobaremos que esté activada la “detección de redes, compartir archivos e impresoras, y que Windows administre las conexiones del grupo del hogar”.
Por defecto, cuando configuramos un equipo para que este se una a un grupo del hogar esta configuración debería estar ya preestablecida del siguiente modo.
Figura 5: Configuración del uso compartido de redes (entorno privado).
En un segundo bloque vemos la configuración de “Todas las redes” las cuales son otro tipo de características en la que digamos que el uso compartido no afecta para “perfiles públicos o invitados”.
Deberemos tener activas las tres opciones disponibles, o simplemente las dos últimas opciones “Usar un cifrado de 128 bits y activar el uso compartido por contraseña”, el cual en este caso no tendrá relevancia si lo tenemos activado o desactivado, ya que no se trataría de recursos compartidos de forma intencionada sino de los recursos compartidos por defecto del sistema, esta característica no está disponible en equipos que se encuentren en un dominio.
En la primera opción “Activar el uso compartido para todos los usuarios a carpetas públicas” se refiere a aquellas carpetas del perfil de usuario que por defecto Windows comparte, pero que no tienen una gran importancia si no guardamos nada en ellas.
Figura 6: Configuración del uso compartido de redes (todas las redes).
Al activar las características anteriores, sobre todo la que respeta al uso compartido de archivos e impresoras, esta por defecto añade unas determinadas reglas de entrada en el WFAS (Windows Firewall Advanced Security) referentes al protocolo SMB (Service Message Block), las cuales se deberían aplicar en este caso solo al perfil privado.
Figura 7: Reglas de entrada del Firewall avanzado para SMB “Compartir archivos e impresoras”.
Por último comprobaremos un par de servicios. El servicio “Examinador de equipos” (Browser) realiza repetidas comprobaciones de actualización para conocer a los equipos vecinos de una misma red, de modo que así nuestro equipo estará actualizando la lista de equipos latentes dentro de la red.
Figura 8: Servicio “Examinador de equipos de red” (Browser).
El servicio “Servidor” (LanmanServer) nos proporcionará compatibilidad para todos aquellos equipos que quieran acceder a este, ofreciendo así el servicio necesario para acceder a sus recursos compartidos.
Figura 9: Servicio “Servidor” (LanmanServer).
Finalmente y el motivo por lo que escribo este artículo, sería añadir el valor necesario en el registro de Windows para poder bypassear la autenticación UAC. La autenticación se hace pero se hace de forma subyacente, esto simplemente nos evita autenticarnos con usuario y contraseña de forma manual.
En el registro de Windows del equipo remoto que queremos conectarnos (Jupiter), buscamos la clave:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
Añadimos un nuevo valor REG_DWORD de 32 bits (aunque el sistema sea de x64 el valor tendría que ser igualmente de 32 bits). El nombre de este valor será: LocalAccountTokenFilterPolicy y la información de dato la establecemos a “1”.
Debilita una mitigación clave contra Pass-the-Hash
LocalAccountTokenFilterPolicy=1desactiva el filtrado de tokens UAC para sesiones remotas con cuentas locales. En entornos donde la cuentaAdministradorlocal comparte hash entre máquinas (típico en parques sin LAPS), un atacante con un solo hash puede moverse lateralmente vía SMB/WMI sin restricciones. Combínalo con LAPS o restricciones de Tier 0 antes de aplicar.
Figura 10: “LocalAccountTokenFilterPolicy” para evitar la autenticación manual en acceso a C$.
Ahora simplemente cerramos el registro y probamos, si aún así no se actualizasen los cambios, cerraríamos sesión o si fuese necesario (que en las pruebas que he realizado no ha sido necesario) reiniciaríamos el equipo.
Veremos que ahora al intentar acceder al recurso compartido C$ del equipo remoto al que hemos añadido este valor no nos pedirá de forma visible la autenticación de un usuario con privilegios para acceder a él y a ese recurso.
Se puede ver en una fsmgmt.msc la existencia de una sesión remota activa del usuario maria procedente del equipo remoto Pluton, la cual solo usó el usuario local creado en el grupo administradores del equipo Jupiter (equipo remoto al que se conectó maria) para autenticarse, aunque como se ve en la captura de pantalla la sesión es con referencia al equipo remoto que accedió. (usuario maria del equipo Pluton accedió al equipo > Jupiter) . Visualizando las sesiones activas en la consola fsmgmt.msc.
Figura 11: Conexión remota activa, existencia de una sesión de usuario conectada al equipo.
Esto está definido por Microsoft (KB951016): https://support.microsoft.com/es-es/kb/951016
Saludos!