Protección contra reconocimiento interno utilizando NetCease y SAMRi10

¿Qué es el Reconocimiento Interno?

La exploración interna es uno de los primeros pasos que un atacante tomará una vez que haya comprometido una cuenta de usuario o de computadora en su red. Utilizando diversas herramientas o scripts, enumeran y recopilan información que les ayudará a identificar qué activos deberían intentar comprometer a continuación para obtener lo que desean. Por ejemplo, BloodHound trazará rutas de ataque que pueden permitir a un adversario escalar sus privilegios de usuario ordinario a administrador.

Casi todos los métodos comunes de enumeración pueden ser ejecutados por un usuario sin privilegios, lo que los hace extremadamente difíciles de detectar y bloquear. En esta publicación, explicaré cómo usar para defenderse contra dos tipos de reconocimiento interno:

• Enumeración de sesiones por usuarios sin privilegios
• Consultas al protocolo MS-SAMR

Tipos de reconocimiento

Para encontrar información sobre la red que han penetrado, los atacantes a menudo enumeran los siguientes tipos de datos:

• Sesiones — Para descubrir quién ha iniciado sesión y dónde
• Usuarios — Para comprender a todos los usuarios en el dominio, idealmente con su membresía de grupo
• Grupos — Para ver todos los grupos en el dominio, idealmente con su membresía
• Listas de control de acceso (ACLs) de Active Directory — Para comprender qué principios de seguridad (como usuarios y grupos) pueden acceder a qué recursos
• Membresía de grupo local — Para ver quién tiene derechos de acceso en la máquina (especialmente quién tiene derechos administrativos)

Bloqueo de enumeración de sesiones con NetCease

Esta publicación de blog se centra en la enumeración de sesiones, que permite a un adversario determinar dónde están iniciadas las sesiones de cuentas de usuario y de servicio. Esa información les ayuda a priorizar qué hosts intentar comprometer primero, como aquellos que tienen un administrador con la sesión iniciada.

Nota: Los permisos predeterminados en Windows 10 han sido cambiados para evitar que los atacantes realicen enumeración de sesiones; sin embargo, todavía vale la pena verificar.

NetCease es un breve script de PowerShell que ayuda a prevenir la enumeración de sesiones cambiando la clave del Registro que controla los permisos del método NetSessionEnum. (La razón por la que esto se completa usando un script en lugar de manualmente es porque la clave, SrvsvcSessionInfo, solo es editable en un valor binario de reg.) Aquí está la ruta a la clave SrvsvcSessionInfo:

Ruta: HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/LanmanServer/DefaultSecurity

El valor predeterminado de la clave del registro SrvsvcSessionInfo es la ACL que permite el uso del método NetSessionEnum. Esto se asigna a lo siguiente:

• Miembro de Administradores
• Miembro de Operadores de Servidor
• Miembro de Power Users
• Usuarios autenticados

El permiso de Usuarios Autenticados permite a los atacantes realizar reconocimiento de sesión utilizando cualquier cuenta de usuario comprometida.

Lo que hace el script NetCease es respaldar el valor actual del registro y luego modificar los permisos, de modo que las siguientes ACEs estén en la ACL:

• InteractiveSid
• ServiceSid
• BatchSid
• Administradores
• Operadores de Servidor
• PowerUsers

Verificando la ACL

Si desea ver el descriptor de seguridad, puede usar el siguiente fragmento de PowerShell, que le mostrará la ACL:

      #Registry Key Information
$key = "HKLM:SYSTEMCurrentControlSetServicesLanmanServerDefaultSecurity"
$name = "SrvsvcSessionInfo"

#Get the Registry Key and Value
$Reg_Key = Get-Item -Path $key
$BtyeValue = $reg_Key.GetValue($name, $null)

#Create a CommonSecurityDescriptor Object using the Byte Value
$Security_Descriptor = New-Object -TypeName System.Security.AccessControl.CommonSecurityDescriptor -ArgumentList $true, $false, $ByteValue, 0

#Output of the ACL to make it simple to see for document. Use only $Security_Descriptor.DiscretionaryAcl if you want to see the full ACL!
$Security_Descriptor.DiscretionaryAcl | Select-Object SecurityIdentifier, ACEType | Format-Table -AutoSize
      

Salida antes de ejecutar NetCease:

Resultado después de ejecutar NetCease:

Nota: La información sobre los SIDs conocidos se puede encontrar aquí.

Prueba de enumeración de sesiones

Una forma fácil de probar si has bloqueado la enumeración de sesiones por cuentas de usuario ordinarias es usar la herramienta NetSess de Joeware.net, pero hay muchas otras opciones, incluyendo SharpHound. Al hacer esto, asegúrate de que estás utilizando una cuenta de usuario que no sea miembro de Administradores, Operadores de Servidor o Usuarios Avanzados.

Resultado antes de usar NetCease

      Netsess.exe [Computer]
      

Resultado después de usar NetCease con una cuenta sin privilegios

      Netsess.exe [Computer]
      

Resultado después de usar NetCease con una cuenta de usuario privilegiado

      Netsess.exe [Computer]
      

Bloqueo de reconocimiento utilizando Remote SAM (SAMR)

Los atacantes pueden realizar reconocimiento utilizando el protocolo SAMR, que puede consultar dispositivos de forma remota pero también puede consultar Active Directory. Utilizando SAMR, un atacante sin ningún privilegio administrativo puede encontrar grupos y usuarios altamente privilegiados, así como usuarios y grupos locales para cada sistema en la red. Herramientas como BloodHound pueden luego mapear automáticamente esta información en rutas de ataque para comprometer Active Directory.

Microsoft introdujo protecciones para la consulta de SAMR con Windows 10 y en 2017 agregó actualizaciones para sistemas operativos anteriores hasta Windows 7 y Server 2008 R2 utilizando la clave de registro RestrictRemoteSAM. Esta clave es una cadena (REG_SZ) que contendrá el SDDL del descriptor de seguridad que protege las llamadas Remote SAM.

En la edición aniversario de Windows 10 (1607) y Windows Server 2016 y posteriores, el SDDL predeterminado se cambió para permitir solo a los administradores locales consultar Remote SAM.

A continuación se presenta una tabla que desglosa los requisitos, el comportamiento predeterminado y las opciones de protección para todos los sistemas operativos:

Hay tres maneras de configurar la clave de registro RestrictRemoteSAM:

• Registro
• Group Policy
• SAMRi10 (Samaritano)

Repasemos cada uno de ellos.

Opción de registro

La clave de registro RestrictRemoteSAM está disponible para que los administradores la actualicen como deseen:

Ruta: HKLM/System/CurrentControlSet/Control/Lsa

Nombre: RestrictRemoteSAM

Valor predeterminado (SDDL) en Windows 10: O:SYG:SYD:(A;;RC;;;BA)

Componentes del SDDL

Como puede ver, el valor predeterminado que Windows 10 establece es SYSTEM para Propietario y Grupo Principal y Control de Lectura para Administradores integrados.

Verificando el SDDL antes de aplicarlo

Para verificar que el SDDL es correcto antes de aplicar el cambio, puede usar el comando ConvertFrom-SDDLString en PowerShell para convertirlo en un descriptor de seguridad que sea más fácil de leer.

Opción de Política de Grupo o Política de Seguridad Local

La política de grupo y la configuración de Security Policy permiten a los administradores establecer esta clave fácilmente. Esto puede funcionar bien para los administradores que quieren establecer el mismo valor en todos los sistemas o varios grupos de sistemas (por ejemplo, permitiendo conexiones SAM remotas para todos los servidores en una OU específica o un cierto conjunto de servidores de aplicaciones).

Los detalles sobre la configuración son los siguientes:

Opción SAMRi10 (Samaritano)

SAMRi10 es un script de PowerShell que ofrece una ventaja clave sobre las opciones anteriores: Crea un nuevo grupo local y delega acceso para que el grupo pueda realizar llamadas SAM remotas. Esto permite a los administradores controlar completamente esta funcionalidad en las Preferencias de Directiva de Grupo, o concederla manualmente a las cuentas cuando sea necesario.

El script SAMRi10 realiza lo siguiente:

1. Crea un grupo local llamado “Remote SAM Users”
2. Modifica el SDDL para incluir el grupo recién creado:
   • Si no hay un SDDL predeterminado, entonces otorgue acceso a los Administradores integrados.
   • Si existe un SDDL, entonces modifíquelo para incluir la nueva ACE para el grupo de Usuarios SAM Remotos.

Beneficios de usar SAMRi10

• Fácil de otorgar acceso granular para Remote SAM access
• Ayuda a las organizaciones que desean hacer cumplir el acceso de mínimo privilegio
• Puede utilizarse en conjunto con una membresía de local group membership Group Policy para otorgar acceso centralizado a los usuarios mediante el uso de targeting a nivel de elemento
• Puede ser utilizado por un sistema de Privileged Access Management (PAM) para otorgar fácilmente acceso dinámico (justo a tiempo) si una cuenta o proceso requiere este permiso específico

Defensa contra el Reconocimiento con Netwrix Solutions

Netwrix StealthAUDIT incluye un analizador de rutas de ataque que proporciona a los administradores información sobre sus ACLs de Active Directory para que puedan cerrar cualquier brecha antes de que los adversarios las exploten. Netwrix StealthINTERCEPT puede monitorear consultas LDAP y luego pasarlas a Netwrix StealthDEFEND, que puede detectar múltiples escenarios de reconocimiento y consultas de manera predeterminada, incluyendo BloodHound, consultas para todos los SPNs y consultas para todas las cuentas con password never expires.

FAQ

¿Qué es el reconocimiento interno y por qué debería importarle?

La exploración interna ocurre cuando los atacantes que ya han obtenido acceso inicial a su red comienzan a mapear su entorno para encontrar objetivos valiosos. Ya no están forzando la entrada – ya están registrados y buscando alrededor. Aquí es donde la mayoría de las estrategias de seguridad son insuficientes, enfocándose en las defensas perimetrales mientras los atacantes se mueven libremente en el interior utilizando credenciales legítimas.

La realidad es clara: no puedes proteger lo que no puedes ver, y no puedes controlar lo que no entiendes. El reconocimiento interno es la fase crítica donde los atacantes recopilan inteligencia sobre la estructura de tu Active Directory, identifican cuentas de alto valor y trazan rutas hacia tus datos más sensibles. Data Security comienza con la identidad, y eso significa prevenir que los atacantes enumeren tu infraestructura de identidad en primer lugar.

¿Cómo implementas NetCease para la protección de enumeración de sesiones?

NetCease bloquea los ataques de enumeración de sesiones al impedir que usuarios no autorizados enumeren las sesiones activas en sus controladores de dominio y servidores. La implementación es sencilla pero requiere planificación. Primero, descargue NetCease del repositorio oficial y verifique que lo está ejecutando en un sistema con PowerShell 5.1 o posterior.

Requisitos previos:

• Privilegios administrativos
• PowerShell 5.1 o posterior
• Sistema unido a un dominio o Windows Server

La herramienta funciona modificando la configuración del registro que controla cómo el servicio Windows Server responde a las solicitudes de enumeración de sesiones. Ejecute NetCease con privilegios administrativos en cada servidor que desee proteger, comenzando con sistemas no críticos para pruebas. Los cambios surten efecto inmediatamente sin requerir un reinicio, pero debe validar que las herramientas administrativas legítimas y las soluciones de monitoreo sigan funcionando correctamente.

La mejor práctica es implementar NetCease gradualmente en su entorno en lugar de desplegarlo en todas partes a la vez. Comience con servidores que no alojen aplicaciones críticas para el negocio, monitoree cualquier interrupción, luego expanda a controladores de dominio y otros objetivos de alto valor. Recuerde que prevenir el reconocimiento no se trata de hacer su red invisible, sino de hacer que los atacantes trabajen más duro y darle a sus sistemas de detección más tiempo para identificar actividad maliciosa.

¿Cuál es la diferencia entre SAMRi10 y las restricciones de SAM de Group Policy?

SAMRi10 y Group Policy restringen el acceso a la base de datos del Security Account Manager (SAM), pero operan en diferentes niveles y sirven para distintos casos de uso. SAMRi10 es un script de PowerShell que modifica directamente la configuración del registro en máquinas individuales, brindándote control granular sobre las restricciones de acceso a SAM en sistemas específicos.

Las restricciones de SAM de Directiva de Grupo funcionan a nivel de dominio, permitiéndote implementar políticas consistentes en múltiples sistemas de manera simultánea. El enfoque de Directiva de Grupo es mejor para despliegues a gran escala donde necesitas protección uniforme en muchas máquinas. SAMRi10 es ideal para servidores específicos, entornos de prueba o situaciones donde necesitas configuraciones personalizadas que no se ajustan a las plantillas estándar de Directiva de Grupo.

La implementación técnica también difiere. SAMRi10 modifica directamente la clave de registro RestrictRemoteSAM, mientras que la Política de Grupo utiliza el sistema de plantillas administrativas para lograr el mismo resultado. Ambos métodos son efectivos, pero SAMRi10 te ofrece más flexibilidad para la resolución de problemas y configuraciones personalizadas. Para la mayoría de las organizaciones, un enfoque híbrido funciona mejor: utilizar la Política de Grupo para restricciones SAM básicas en todo el dominio, y luego usar SAMRi10 para sistemas específicos que requieran un endurecimiento adicional.

¿Cómo verifica que las medidas de protección contra el reconocimiento están funcionando?

Probar su protección contra reconocimiento requiere un enfoque metódico que simule técnicas reales de atacantes sin interrumpir las operaciones. Comience con pruebas básicas de enumeración de sesiones utilizando herramientas como NetSess o los comandos Get-WmiObject de PowerShell desde una cuenta no administrativa. Si NetCease está funcionando correctamente, estos intentos deberían fallar o retornar información limitada.

Para las restricciones de SAM, pruebe el acceso remoto a la base de datos del Security Account Manager utilizando herramientas como enum4linux o rpcclient desde un sistema Linux, o comandos net use desde Windows. Las restricciones de SAM correctamente configuradas deberían bloquear intentos de enumeración no autorizados mientras aún permiten acceso administrativo legítimo.

La clave es probar desde la perspectiva del atacante. Cree cuentas de prueba con privilegios de usuario estándar e intente técnicas comunes de reconocimiento como la enumeración de dominios, el descubrimiento de recursos compartidos y el listado de cuentas de usuario. Documente qué funciona y qué no, luego ajuste sus medidas de protección en consecuencia. Recuerde que la seguridad efectiva no se trata de bloquear todo, sino de controlar qué información está disponible para quién, al mismo tiempo que se asegura de que las funciones legítimas del negocio continúen operando correctamente.

¿Cuándo debería revertir los cambios de NetCease y SAMRi10?

Rollback scenarios typically involve compatibility issues with legitimate administrative tools, unexpected application failures, or business process disruptions that weren’t identified during testing. NetCease and SAMRi10 both provide rollback options, but the process differs for each tool.

Para NetCease, revertir implica deshacer las modificaciones del registro que controlan la enumeración de sesiones. La herramienta incluye parámetros para restaurar la configuración original, pero siempre debe documentar la baseline configuration antes de realizar cambios. Pruebe el proceso de reversión primero en un entorno de laboratorio para asegurarse de entender los pasos y el tiempo involucrado.

La reversión de SAMRi10 es más compleja porque implica múltiples claves de registro y posibles interacciones con la Política de Grupo. Si ha implementado restricciones de SAM a través de la Política de Grupo, utilice las herramientas de gestión de políticas para revertir los cambios. Para modificaciones directas del registro, SAMRi10 incluye funciones de restauración, pero la verificación manual es esencial para asegurar una reversión completa.

El mejor enfoque es proactivo: implementar cambios durante las ventanas de mantenimiento, tener procedimientos de reversión documentados y probados, y monitorear de cerca los sistemas afectados durante al menos 24-48 horas después de la implementación. La mayoría de los problemas de compatibilidad surgen rápidamente, pero algunos pueden hacerse evidentes solo durante procesos empresariales específicos u operaciones del sistema.