Apaga las funciones arriesgadas de Windows que adoran los atacantes (de forma segura)

Lo que los atacantes realmente abusan en Windows

La mayoría de las compromisos exitosos en Windows no son “un exploit mágico”. Son una cadena:

• Acceso inicial (phishing, robo de tokens, RDP expuesto, VPN vulnerable, macro maliciosa).
• Ejecución (PowerShell, WSH, procesos hijos de Office, tareas programadas).
• Acceso a credenciales (volcado de LSASS, relés NTLM, credenciales en caché, cuentas de servicio con alcance incorrecto).
• Movimiento lateral (SMB, WMI, WinRM, RDP, creación de servicios tipo PsExec).
• Persistencia (elementos de inicio, tareas programadas, servicios, abuso de GPO).
• Impacto (despliegue de ransomware, robo de datos, daño a controladores de dominio).

Las “funciones que adoran los atacantes” tienden a ser: antiguas, ampliamente desplegadas e invisibles en la operación diaria. También suelen ser capacidades administrativas legítimas. Ahí está la trampa: si no puedes distinguir a TI de un intruso en tus registros, el atacante ya ganó el juego del sigilo.

Nuestro objetivo aquí es reducir el número de herramientas integradas de las que un atacante puede depender, reducir el radio de explosión cuando lo intenten y hacer que el entorno genere ruido cuando se muevan.

Hechos interesantes y contexto histórico (porque esto no sucedió por accidente)

1. SMB1 data de la era de LAN Manager en los años 80: supuestos de diseño como redes confiables, descubrimiento excesivo y mínima higiene de autenticación.
2. NTLM se creó por compatibilidad entre versiones antiguas de Windows y entornos mixtos; perduró porque “funciona en todas partes” es una droga potente.
3. LLMNR se introdujo para hacer que la resolución de nombres “funcione” cuando DNS no está bien configurado. A los atacantes les encanta para capturar credenciales en redes planas.
4. WMI se convirtió en la navaja suiza de la gestión de Windows—y más tarde, del movimiento lateral—porque permite ejecución remota de procesos con los derechos adecuados.
5. PowerShell se diseñó primero para automatización; el endurecimiento de seguridad (registro, lenguaje restringido, AMSI) llegó después conforme evolucionó el modelo de amenaza.
6. Remote Registry existe principalmente por herramientas de gestión legacy. En entornos modernos con frecuencia es peso muerto con bordes afilados.
7. Autorun/Autoplay fueron una vez una función de UX para medios removibles. Se convirtieron en una característica de malware. La UX perdió esa pelea.
8. TLS 1.0/1.1 perduraron porque aplicaciones críticas y appliances no querían actualizarse. Atacantes y auditores de cumplimiento lo notaron.

Cómo deshabilitar funciones sin autoboicotearse

1) Mide el uso antes de eliminar

Desactivar SMB1 es fácil. Encontrar que un escáner de almacén aún habla SMB1 es el trabajo real. Antes de eliminar funciones, inventarias las dependencias.

2) Prefiere “encerrarlo” en lugar de “dejarlo activado”

Si una función es necesaria, restrínjela. Delimita por:

• Red: solo desde subredes de administración, solo a puertos de gestión, solo a través de un jump host.
• Identidad: grupos específicos, acceso JIT, cuentas administrativas separadas.
• Dispositivo: PAWs/SAWs para administradores, estratificación (estaciones de trabajo no administran servidores).
• Tiempo: elevación just-in-time, accesos con expiración, ventanas de cambio.

3) Haz la reversibilidad un requisito de diseño

Si no puedes revertirlo rápido, no vas a desplegar cambios. Para cada cambio decide:

• ¿Qué se rompe si estamos equivocados?
• ¿Cómo detectamos la rotura en menos de 10 minutos?
• ¿Cuál es el comando de rollback o el GPO?

4) Registra lo suficiente para demostrar que estás más seguro

El hardening que no se puede validar se convierte en una discusión religiosa. Quieres evidencia: menos eventos NTLM, menos puertos de gestión entrantes, menos motores de script disponibles, menos eventos de “servicio remoto creado”.

5) No confundas “deshabilitado” con “inaccesible”

Apagar un servicio ayuda. Bloquear el puerto en el firewall del host suele ser más fiable. Lo mejor es ambos, cuando sea posible.

Idea parafraseada de Gene Kim: cambios pequeños y frecuentes con retroalimentación rápida superan a los cambios monumentales, especialmente cuando la fiabilidad está en juego.

Manual de diagnóstico rápido (qué revisar primero/segundo/tercero)

Esta es la parte que usas cuando estás en medio de un incidente o de un cambio y alguien pregunta, “¿Por qué se rompió todo?” Quieres encontrar el cuello de botella rápido, no ganar una discusión.

Primero: confirma qué cambió y dónde

• GPO / Intune / directiva local: ¿se aplicó la configuración? ¿En qué OU / grupo de dispositivos?
• Eliminación de característica vs deshabilitar configuración: ¿alguien desinstaló una característica opcional (más difícil de revertir) o simplemente cambió una política?
• Ámbito del firewall: ¿bloqueamos un puerto necesario para las herramientas de gestión?

Segundo: identifica la ruta que falla (resolución de nombres, autenticación, transporte)

• Resolución de nombres: DNS vs retrocesos LLMNR/NBT-NS.
• Autenticación: Kerberos vs NTLM, autenticación basada en certificados vs contraseña.
• Transporte: SMB vs WinRM vs WMI/DCOM vs RDP.

Tercero: demuéstralo con una prueba limpia desde un host limpio

• Desde una estación de administración conocida buena, prueba el protocolo/puerto específico.
• Desde el servidor objetivo, inspecciona estado de listeners, estado de servicios y reglas de firewall.
• Revisa los registros de eventos del subsistema relevante (SMBClient, WinRM, Security, Schannel).

Mapa de triaje rápido

• No se puede acceder a recursos compartidos → revisa dialectos SMB, firewall 445, firma SMB, acceso de invitado.
• Comandos remotos fallan → revisa servicio WinRM, listener, firewall, uso indebido de TrustedHosts.
• App antigua no puede conectarse → revisa versiones/cifras TLS, configuraciones .NET, registros de Schannel.
• Retrasos en inicio de sesión → revisa retrocesos de resolución de nombres y alcanzabilidad del controlador de dominio.

Funciones de Windows de alto riesgo para apagar (o encerrar)

SMB1 (desactívalo; no hay nostalgia permitida)

SMB1 es una tasa de compatibilidad con un interés de seguridad. Si aún tienes clientes o servidores SMB1 necesitas un plan: identifícalos, aíslalos y retíralos. El valor seguro por defecto es: SMB1 apagado en todas partes.

Encierro como alternativa: si un dispositivo realmente inmovable requiere SMB1, colócalo en una VLAN dedicada, restringe SMB a un único servidor de archivos y evita que hable con cualquier otra cosa.

LLMNR y NBT-NS (apágalos para detener la captura fácil de credenciales)

LLMNR y NBT-NS “ayudan” cuando DNS falla. Los atacantes los abusan para suplantación (poisoning) y captura de hashes NTLM mediante ataques estilo responder. Si DNS no es fiable, arregla DNS. No mantengas la pistola en el pie.

NTLM (reducir; luego eliminar donde puedas)

Kerberos es el protocolo preferido en un dominio sano. NTLM es el fallback desordenado que los atacantes pueden relayear, degradar o recolectar. No tienes que activar “deshabilitar NTLM” globalmente el primer día. Necesitas un plan de reducción, respaldado por datos de eventos y excepciones con expiración.

PowerShell remoting y WinRM (restringir, no deshabilitar a lo bruto)

WinRM/PowerShell Remoting son útiles legítimamente. También son de alto valor para adversarios porque se mezclan como “tráfico administrativo”. La práctica recomendada es restringir quién puede usarlo, desde dónde y registrarlo bien. Si no lo necesitas en endpoints, desactívalo allí.

WMI/DCOM administración remota (restringir de forma estricta)

WMI remoto es otra vía clásica de movimiento lateral. Muchas organizaciones pueden trasladar tareas comunes a WinRM con endpoints restringidos y mejor auditoría. Si mantienes WMI remoto, delimítalo a hosts de administración y grupos administrativos.

Remote Registry (por lo general: deshabilitar)

Si no usas una herramienta que requiera Remote Registry, apágala. Es uno de esos servicios que amplían silenciosamente lo posible durante una intrusión sin aportar mucho valor moderno.

Windows Script Host (WSH) y motores de script legacy (a menudo: deshabilitar)

VBScript y JScript vía WSH son portadores frecuentes de payloads. Muchos entornos pueden desactivar WSH sin romper la funcionalidad central de Windows. Si una app legacy lo necesita, delimítalo a los hosts de esa app únicamente.

Macros de Office y comportamiento de “procesos hijos” (control agresivo)

Las macros no son malas. Las macros sin control sí. Establece política de macros, bloquea macros provenientes de Internet y reduce que Office lance procesos hijos cuando sea posible mediante reglas ASR. En la realidad corporativa tendrás excepciones. Hazlas explícitas y revisadas.

Exposición de RDP (reduce la superficie, luego reduce privilegios)

RDP no es el villano. RDP expuesto al mundo, o ampliamente habilitado internamente con controles débiles, sí lo es. Usa gateway/jump hosts, MFA, autenticación a nivel de red y restricciones de firewall del host. Además: no uses administradores de dominio para RDP rutinario.

TLS legacy y criptografía débil (apaga protocolos antiguos en servidores primero)

Los atacantes no necesitan romper la criptografía si sigues ofreciendo protocolos desactualizados. Deshabilitar TLS 1.0/1.1 y cifrados débiles puede romper integraciones antiguas, así que trátalo como un cambio SRE: detecta, prepara y despliega con monitorización.

Autorun/Autoplay (deshabilitar; no hay caso de negocio)

Los medios removibles aún existen en muchas industrias. Autorun no debe existir. Si quieres abrir algo automáticamente al insertar un dispositivo, necesitas una herramienta empresarial gestionada, no una función de los 2000 con historia de malware.

Broma #1: SMB1 es como conservar un teléfono de disco porque “todavía funciona”. Claro—hasta que alguien lo usa para llamar a larga distancia a tu costa.

Tareas prácticas: comandos, salidas y la decisión que tomas

Estas tareas están pensadas para ejecutarse desde un shell administrativo (PowerShell) en Windows. El formato del prompt más abajo está estandarizado; no sobrepienses el nombre de usuario. La parte importante es lo que aprendes de la salida y lo que haces después.

Tarea 1: Comprobar si SMB1 está habilitado (componente servidor)

cr0x@server:~$ powershell -NoProfile -Command "Get-WindowsOptionalFeature -Online -FeatureName SMB1Protocol | Format-List FeatureName,State"
FeatureName : SMB1Protocol
State       : Enabled

Qué significa la salida: SMB1 está instalado y habilitado en esta máquina.

Decisión: Si esto no es una isla legada aislada, programa su desactivación/remoción. Antes de cambiar, identifica clientes dependientes de SMB1 (ver Tarea 3).

Tarea 2: Deshabilitar SMB1 de forma segura (remoción de característica) y confirmar

cr0x@server:~$ powershell -NoProfile -Command "Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol -NoRestart"
Path          :
Online        : True
RestartNeeded : True

Qué significa la salida: SMB1 está deshabilitado; se requiere reiniciar para completar.

Decisión: Planifica el reinicio. Si es un servidor de archivos, coordina con los usuarios y monitoriza errores de acceso a recursos compartidos tras el reinicio.

Tarea 3: Detectar uso de SMB1 vía registros de eventos (SMB server)

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -LogName 'Microsoft-Windows-SMBServer/Audit' -MaxEvents 20 | Select-Object TimeCreated,Id,Message | Format-Table -AutoSize"
TimeCreated           Id Message
-----------           -- -------
2/5/2026 10:12:41 AM 3000 SMB1 negotiation detected from client 10.20.5.44.
2/5/2026 10:05:09 AM 3000 SMB1 negotiation detected from client 10.20.5.44.

Qué significa la salida: Un cliente en 10.20.5.44 está intentando usar SMB1.

Decisión: Encuentra al propietario del dispositivo. Si es un dispositivo legacy, aíslalo o actualízalo. No mantengas SMB1 habilitado globalmente para proteger un rincón polvoriento.

Tarea 4: Comprobar estado de firma SMB (cliente y servidor)

cr0x@server:~$ powershell -NoProfile -Command "Get-SmbServerConfiguration | Select-Object EnableSecuritySignature,RequireSecuritySignature | Format-List"
EnableSecuritySignature  : True
RequireSecuritySignature : False

Qué significa la salida: La firma SMB es soportada pero no obligatoria.

Decisión: En la mayoría de redes empresariales, obliga la firma SMB en servidores (especialmente DCs y servidores de archivos). Valida compatibilidad con clientes antiguos primero.

Tarea 5: Identificar si LLMNR está habilitado vía registro (comprobación local)

cr0x@server:~$ powershell -NoProfile -Command "Get-ItemProperty -Path 'HKLM:\Software\Policies\Microsoft\Windows NT\DNSClient' -Name EnableMulticast -ErrorAction SilentlyContinue | Format-List"
EnableMulticast : 1

Qué significa la salida: LLMNR está explícitamente habilitado por política (1).

Decisión: Establece esto a 0 vía GPO para sistemas unidos al dominio, luego valida que DNS sea fiable en las subredes afectadas.

Tarea 6: Deshabilitar LLMNR (remediación local para pruebas)

cr0x@server:~$ powershell -NoProfile -Command "New-Item -Path 'HKLM:\Software\Policies\Microsoft\Windows NT\DNSClient' -Force | Out-Null; Set-ItemProperty -Path 'HKLM:\Software\Policies\Microsoft\Windows NT\DNSClient' -Name EnableMulticast -Type DWord -Value 0; Get-ItemProperty -Path 'HKLM:\Software\Policies\Microsoft\Windows NT\DNSClient' -Name EnableMulticast"
EnableMulticast : 0

Qué significa la salida: LLMNR ahora está deshabilitado por política en este host.

Decisión: Inclúyelo en la política centralizada (GPO/Intune). Considera también deshabilitar NBT-NS donde sea factible (Tarea 7).

Tarea 7: Comprobar configuración NetBIOS sobre TCP/IP (por interfaz)

cr0x@server:~$ powershell -NoProfile -Command "Get-WmiObject -Class Win32_NetworkAdapterConfiguration -Filter 'IPEnabled=TRUE' | Select-Object Description,TcpipNetbiosOptions | Format-Table -AutoSize"
Description                          TcpipNetbiosOptions
-----------                          -------------------
Intel(R) Ethernet Connection         0

Qué significa la salida: TcpipNetbiosOptions 0 suele significar “Predeterminado” (controlado por DHCP). 1 habilita, 2 deshabilita.

Decisión: Si no necesitas NetBIOS, configúralo en 2 vía opciones DHCP o estándares locales. Valida dependencias legacy primero (sistemas antiguos, herramientas de descubrimiento antiguas).

Tarea 8: Comprobar si WinRM está habilitado y escuchando

cr0x@server:~$ powershell -NoProfile -Command "winrm enumerate winrm/config/listener"
Listener
    Address = *
    Transport = HTTP
    Port = 5985
    Hostname
    Enabled = true

Qué significa la salida: WinRM está habilitado y escuchando en HTTP 5985.

Decisión: Para servidores, mantén WinRM pero restringe el inbound a subredes administrativas y aplica autenticación adecuada. Para endpoints, considera deshabilitarlo totalmente salvo sea necesario.

Tarea 9: Deshabilitar PowerShell remoting en endpoints (dirigido)

cr0x@server:~$ powershell -NoProfile -Command "Disable-PSRemoting -Force; Get-Service WinRM | Select-Object Name,Status,StartType | Format-Table -AutoSize"
Name Status StartType
---- ------ ---------
WinRM Stopped Disabled

Qué significa la salida: El servicio WinRM está detenido y deshabilitado; PS Remoting está apagado.

Decisión: Aplica esto a la OU/grupo de dispositivos de estaciones de trabajo, no a tus servidores de gestión. Mantén una vía de emergencia (por ejemplo, la shell remota de tu EDR, o herramientas de gestión en red).

Tarea 10: Comprobar estado del servicio Remote Registry

cr0x@server:~$ powershell -NoProfile -Command "Get-Service RemoteRegistry | Select-Object Name,Status,StartType | Format-Table -AutoSize"
Name           Status  StartType
----           ------  ---------
RemoteRegistry Running Automatic

Qué significa la salida: Remote Registry está en ejecución y configurado para arrancar automáticamente.

Decisión: Si no puedes nombrar la herramienta que lo necesita, desactívalo (Tarea 11). Si una herramienta lo requiere, delimita esa herramienta a una VLAN de gestión y limita quién puede alcanzarla.

Tarea 11: Deshabilitar Remote Registry y bloquear inbound con defensa en profundidad de firewall

cr0x@server:~$ powershell -NoProfile -Command "Stop-Service RemoteRegistry -Force; Set-Service RemoteRegistry -StartupType Disabled; Get-Service RemoteRegistry | Format-Table -AutoSize"
Status  Name           DisplayName
------  ----           -----------
Stopped RemoteRegistry Remote Registry

Qué significa la salida: El servicio está detenido y no arrancará en el inicio.

Decisión: Verifica que tu gestión de sistemas siga funcionando. Si algo se rompe, debería ser una dependencia conocida—si es una sorpresa, acabas de encontrar un riesgo no documentado.

Tarea 12: Comprobar si WSH (cscript/wscript) está habilitado

cr0x@server:~$ powershell -NoProfile -Command "Get-ItemProperty -Path 'HKLM:\Software\Microsoft\Windows Script Host\Settings' -Name Enabled -ErrorAction SilentlyContinue | Format-List"
Enabled : 1

Qué significa la salida: Windows Script Host está habilitado.

Decisión: Si no tienes scripts VBScript de inicio sancionados o scripts administrativos legacy, desactiva WSH vía política y migra la automatización a PowerShell con registro.

Tarea 13: Deshabilitar WSH (piloto dirigido) y verificar comportamiento

cr0x@server:~$ powershell -NoProfile -Command "New-Item -Path 'HKLM:\Software\Microsoft\Windows Script Host\Settings' -Force | Out-Null; Set-ItemProperty -Path 'HKLM:\Software\Microsoft\Windows Script Host\Settings' -Name Enabled -Type DWord -Value 0; Get-ItemProperty -Path 'HKLM:\Software\Microsoft\Windows Script Host\Settings' -Name Enabled"
Enabled : 0

Qué significa la salida: WSH ahora está deshabilitado en este host.

Decisión: Haz un piloto en un departamento primero (finanzas a menudo tiene “macros/scripts misteriosos”). Rastrea tickets de mesa de ayuda; estarás mapeando dependencias ocultas.

Tarea 14: Comprobar exposición de RDP (servicio + grupo de reglas de firewall)

cr0x@server:~$ powershell -NoProfile -Command "Get-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Control\Terminal Server' -Name fDenyTSConnections | Select-Object fDenyTSConnections; Get-NetFirewallRule -DisplayGroup 'Remote Desktop' | Select-Object DisplayName,Enabled,Direction,Action | Format-Table -AutoSize"
fDenyTSConnections
------------------
0

DisplayName                             Enabled Direction Action
-----------                             ------- -------- ------
Remote Desktop - User Mode (TCP-In)      True    Inbound  Allow
Remote Desktop - User Mode (UDP-In)      True    Inbound  Allow

Qué significa la salida: RDP está permitido y las reglas de firewall están habilitadas.

Decisión: Si esto no es un jump host o un terminal server, deshabilita RDP o restringe el ámbito del firewall a subredes administrativas. No lo dejes ampliamente accesible “por si acaso”.

Tarea 15: Verificar señales de uso de NTLM en registros de Seguridad (comprobación local rápida)

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624} -MaxEvents 50 | Where-Object { $_.Message -match 'NTLM' } | Select-Object TimeCreated,Id,Message | Select-Object -First 3 | Format-Table -Wrap"
TimeCreated           Id Message
-----------           -- -------
2/5/2026 9:44:10 AM 4624 ... Authentication Package: NTLM ...
2/5/2026 9:43:58 AM 4624 ... Authentication Package: NTLM ...

Qué significa la salida: Inicios de sesión recientes usaron NTLM en este sistema.

Decisión: No puedes matar NTLM a ciegas. Necesitas identificar qué apps/dispositivos lo están provocando, luego moverlos a Kerberos o autenticación moderna, o aislarlos.

Tarea 16: Comprobar configuraciones de protocolo TLS (Schannel) para versiones legacy

cr0x@server:~$ powershell -NoProfile -Command "Get-ChildItem 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols' -ErrorAction SilentlyContinue | Select-Object PSChildName | Format-Table -AutoSize"
PSChildName
-----------
TLS 1.0
TLS 1.1
TLS 1.2
TLS 1.3

Qué significa la salida: Existen las claves de protocolo. La presencia no equivale a habilitado/deshabilitado; debes revisar subclaves y valores.

Decisión: En servidores, desactiva TLS 1.0/1.1 tras validar dependencias. Comienza con servicios internos no expuestos a Internet y avanza hacia afuera.

Broma #2: Apagar TLS legacy es como limpiar debajo de la nevera: desagradable, atrasado y vas a descubrir algo que antes era comida.

Tres microhistorias corporativas (anonimizadas, plausibles y dolorosamente familiares)

Microhistoria 1: El incidente causado por una suposición errónea

Asumieron que “red interna” significaba “red confiable”. Era una empresa mediana con una LAN de campus relativamente plana, algunas VLAN y mucha fe. LLMNR y NBT-NS quedaron habilitados porque a veces DNS fallaba en un edificio y nadie quería que los llamaran por resolución de nombres.

Un atacante entró en el portátil de un usuario mediante un adjunto de phishing común. No hubo exploit de kernel. Nada espectacular. Luego montó un setup tipo responder en la misma subred. El entorno ofreció gustoso intentos de autenticación NTLM cada vez que una máquina intentaba resolver un nombre que DNS no respondía lo suficientemente rápido.

En horas ya tenían credenciales útiles en otros sitios. No “dominio admin” de inmediato. Algo peor: una cuenta de servicio que tenía admin local en gran cantidad de sistemas porque facilitaba el despliegue de software. Desde ahí, WMI remoto y SMB hicieron el resto.

La reunión post- incidente tuvo los habituales: “¿Por qué no lo paró el firewall?” y “¿Por qué el antivirus no fue suficiente?” La respuesta incómoda fue más simple: la propia red estaba participando en la compromisión porque estaba configurada para aceptar comportamientos de fallback inseguros como normales.

La solución no fue heroica. Arreglaron DNS correctamente, deshabilitaron LLMNR, redujeron NTLM y dejaron de dar cuentas de despliegue con admin local amplio. El mayor cambio fue cultural: “interno” dejó de ser sinónimo de “seguro”.

Microhistoria 2: La optimización que salió mal

Una gran empresa quería administración remota más rápida. El equipo de parches se cansó de que RDP fuera lento y los jump boxes estuvieran sobrecargados, así que alguien “optimizó” habilitando WinRM ampliamente y añadiendo una entrada amplia en TrustedHosts para hacer las conexiones “menos molestas”. Funcionó. Todo fue más rápido. Los tickets bajaron.

Luego un atacante obtuvo un foothold en una estación de trabajo. Con admin local, pudo leer suficiente configuración y detalles en caché para empezar a usar las mismas vías convenientes de gestión remota. WinRM hizo el movimiento lateral más limpio, silencioso y menos dependiente de herramientas antiguas y ruidosas. TrustedHosts redujo la fricción de maneras que también redujeron la seguridad.

Cuando el equipo de respuesta revisó los logs, parecía TI. Comandos remotos, sesiones remotas, protocolos legítimos. La diferencia fue la hora del día y hosts de origen que no coincidían con patrones administrativos habituales, pero eso es sutil cuando estás bajo presión.

La “optimización” no fue WinRM en sí. WinRM puede ser una buena idea. El fallo fue habilitarlo en todas partes sin delimitación de red, sin configuración estricta de endpoints y sin controles de identidad cerrados. Al final lo rehicieron: WinRM solo desde estaciones de trabajo administrativas endurecidas, solo a servidores y fuertemente registrado. En endpoints, estaba apagado salvo que hubiera una razón.

Microhistoria 3: La práctica aburrida pero correcta que salvó el día

Una firma de servicios financieros aplicaba un modelo estricto de estratificación: los administradores usaban estaciones dedicadas; los administradores de dominio no navegaban por la web; y los protocolos de gestión estaban restringidos por reglas de firewall a una VLAN de gestión. No era glamuroso. Los nuevos se quejaban. Todos querían excepciones.

También tenían un hábito que parece papeleo hasta que te salva: planes de cambio con pasos explícitos de rollback. Cada cambio de hardening tenía una sección “cómo deshacer esto a las 2 AM”, y el rollback se probaba en un laboratorio que realmente se parecía a producción.

Durante un incidente, el portátil de un contratista fue comprometido fuera de la red y luego conectado en sitio. El atacante intentó movimiento lateral clásico: escanear 445, intentar sesiones SMB, intentar WinRM, intentar RDP. Se topó con muros rápido. Los puertos no eran alcanzables desde ese segmento de red, y las credenciales robadas no eran suficientes porque el acceso privilegiado requería otra cuenta usada solo desde estaciones administrativas.

El atacante siguió causando problemas en ese endpoint. Pero la organización evitó la fase “ahora está por todas partes”. La lección no fue “somos impenetrables”. Fue que la segmentación aburrida y la higiene disciplinada de administración convierten un desastre en un ticket.

Errores comunes: síntomas → causa raíz → solución

1) “Tras deshabilitar LLMNR, algunas apps no encuentran servidores por nombre”

Síntomas: Los usuarios se quejan de que “antes funcionaba” al escribir nombres cortos; algunas apps legacy agotan tiempos; helpdesk ve fallos intermitentes.

Causa raíz: DNS está incompleto (faltan registros A, sufijos de búsqueda rotos) y LLMNR/NBT-NS actuaban como parche.

Solución: Arregla DNS y opciones DHCP (lista de sufijos de búsqueda), asegúrate de que existan registros forward/reverse donde se necesite y actualiza apps para usar FQDN. Mantén LLMNR apagado.

2) “La remoción de SMB1 rompió un dispositivo crítico”

Síntomas: Un escáner/copista/appliance antiguo no puede escribir a un recurso compartido; logs muestran fallos de negociación.

Causa raíz: Firmware del dispositivo solo soporta SMB1.

Solución: Actualiza firmware o reemplaza el dispositivo. Hasta entonces: aísla el dispositivo en su propia VLAN, restringe SMB a un servidor de entregas dedicado y monitoriza ese servidor estrictamente.

3) “Deshabilitar WinRM rompió el parcheo”

Síntomas: Trabajos de parcheo fallan; inventario remoto falla; el error menciona WSMan o conectividad 5985/5986.

Causa raíz: Tus herramientas dependían de WinRM y lo deshabilitaste sin una ruta de reemplazo o alcance.

Solución: Reactiva WinRM donde sea requerido, pero restringe inbound a subredes y hosts de gestión, usa HTTPS cuando corresponda y elimina patrones amplios de TrustedHosts.

4) “Tras endurecer reglas de firewall, RDP está ‘aleatoriamente’ inaccesible”

Síntomas: Algunos administradores pueden RDP y otros no. Funciona desde la oficina pero no desde VPN (o viceversa).

Causa raíz: El alcance del firewall basado en rangos IP no incluye todas las redes fuente administrativas; los pools VPN no estaban incluidos.

Solución: Define redes fuente administrativas explícitamente, documéntalas y aplica RDP vía gateway/jump host en lugar de listas de permitidos dispersas.

5) “Apagar WSH rompió scripts de inicio de sesión”

Síntomas: Mapeos de unidades o impresoras fallan; usuarios se quejan tras iniciar sesión.

Causa raíz: Aún tienes scripts de inicio VBScript o scripts GPO legacy.

Solución: Migra a scripts PowerShell con firma y registro adecuados, o usa Group Policy Preferences para mapeos cuando sea posible. Mantén WSH deshabilitado en endpoints una vez migrado.

6) “Deshabilitar TLS 1.0 rompió una integración de proveedor”

Síntomas: El cliente falla al conectar; el servidor muestra errores Schannel; el proveedor dice “ayer funcionaba”.

Causa raíz: El cliente (o servidor) del proveedor solo soporta TLS legacy o cifrados débiles.

Solución: Actualiza la integración. Si necesitas una excepción temporal, aísla ese endpoint/servicio y fija una fecha de expiración para la excepción con un responsable.

7) “Deshabilitamos NTLM y la autenticación empezó a fallar por todas partes”

Síntomas: Acceso a recursos de dominio falla; apps antiguas dejan de autenticarse; fallos raros en inicio de servicios.

Causa raíz: Saltaste la fase de medición y no identificaste dependencias NTLM; probablemente incluye sistemas no unidos al dominio, NAS antiguos o SPNs mal configurados que impiden Kerberos.

Solución: Reactiva temporalmente, recopila eventos de auditoría NTLM, arregla SPNs y DNS, migra o aísla sistemas legacy y vuelve a aplicar restricciones de forma incremental.

Listas de verificación / plan paso a paso

Fase 0: Elige tu alcance (no intentes abarcarlo todo)

• Comienza con estaciones de trabajo (mayor tasa de phishing) y exposición de gestión de servidores (mayor radio de explosión).
• Define cómo se ve “hecho” para una OU/grupo piloto de dispositivos.
• Decide tu ruta de rollback para cada configuración.

Fase 1: Inventario y línea base (1–2 semanas)

• Encuentra uso de SMB1 (Tarea 3) en servidores de archivos.
• Muestra uso de NTLM (Tarea 15) en servidores y endpoints representativos.
• Lista dónde se requiere WinRM (parcheo, gestión de configuración, inventario).
• Identifica uso de scripts legacy (WSH, scripts de inicio, tareas programadas).
• Registra estado actual de habilitación de RDP y alcance de firewall (Tarea 14).

Fase 2: Ganancias rápidas con bajo riesgo de rotura (piloto primero)

• Deshabilita Autorun/Autoplay (por política) en todos los endpoints.
• Deshabilita Remote Registry en endpoints y la mayoría de servidores (Tarea 10/11).
• Deshabilita LLMNR vía política (Tarea 6), luego corrige problemas de DNS que afloren.
• Restringe RDP: quítalo de endpoints; exige jump host para servidores.

Fase 3: Cambios de alto impacto con gestión de dependencias

• Desactiva SMB1 ampliamente (Tarea 1/2), aísla excepciones.
• Endurece WinRM: solo desde subredes administrativas, considera HTTPS, elimina TrustedHosts amplios.
• Reduce NTLM: empieza con auditoría, luego restricciones en servidores de alto valor (DCs, servidores de archivos).
• Deshabilita WSH en endpoints (Tarea 13), migra scripts.
• Deshabilita TLS 1.0/1.1 en servidores en oleadas, validando cada integración.

Fase 4: Haz que perdure (la parte que la mayoría omite)

• Mueve el hardening a builds estándar (gold images, gestión de configuración, policy-as-code donde sea posible).
• Requiere tickets de excepción con responsables y fechas de expiración.
• Monitorea la deriva: comprobaciones periódicas de servicios re-habilitados y reglas de firewall reabiertas.
• Haz ejercicios de mesa: “Si una estación es comprometida—¿a qué puede llegar?”

Preguntas frecuentes

1) ¿Debería simplemente desactivar PowerShell por completo?

No. PowerShell es clave para la administración moderna de Windows y herramientas de seguridad. Endurécelo: registro, endpoints restringidos, limita remoting y quién puede ejecutar qué y dónde.

2) ¿Desactivar SMB1 basta para detener ransomware?

No. Elimina un eslabón débil común, pero el ransomware se propaga por múltiples vías: credenciales robadas, ejecución remota, protocolos de gestión expuestos y mala segmentación. Trata SMB1 como una base obligatoria, no como bala de plata.

3) Si desactivo LLMNR, ¿algo se romperá?

Pueden romperse cosas si tu DNS es descuidado. Eso no es razón para mantener LLMNR; es razón para arreglar DNS. Haz un piloto primero y luego expande.

4) ¿Por qué no bloquear todos los puertos administrativos entrantes en todas partes?

Puedes, y a menudo es buena idea, pero aún necesitas un plano de gestión. El patrón maduro es: puertos administrativos alcanzables solo desde estaciones administrativas endurecidas/jump hosts en una red de gestión.

5) ¿Cuál es el enfoque más seguro para reducir NTLM?

Audita primero, luego arregla bloqueadores de Kerberos (DNS/SPNs/desincronización horaria), y después restringe NTLM en tus servidores de mayor valor. Haz excepciones explícitas y temporales.

6) ¿Remote Registry alguna vez está justificado?

A veces, en herramientas muy concretas o escenarios legacy de gestión. Si lo mantienes, no lo dejes abierto: delimita acceso por firewall, grupos de admins y subred de gestión. Si no, desactívalo.

7) Necesitamos RDP para soporte de proveedores. ¿Cuál es la opción menos mala?

Usa un jump host con MFA, acceso limitado en el tiempo y grabación de sesión si está disponible. No expongas RDP directamente a Internet y no des cuentas amplias a proveedores.

8) ¿Puedo deshabilitar WSH si usamos mucho Office?

Sí—WSH no es lo mismo que macros de Office. WSH es cscript/wscript ejecutando VBScript/JScript. Algunas organizaciones aún tienen scripts de inicio VBScript; migra antes de deshabilitar globalmente.

9) ¿Cómo evito romper apps antiguas al deshabilitar TLS 1.0/1.1?

Inventaria qué servicios aceptan TLS entrante y qué clientes conectan saliente. Deshabilita por etapas: servicios no críticos primero, luego los críticos con un plan de rollback. Si un proveedor no puede soportar TLS moderno, aísla esa integración y planifica su reemplazo.

10) ¿Cuál es el mayor “riesgo silencioso” que ves en entornos Windows?

Rutas de movimiento lateral demasiado permisivas combinadas con conveniencia administrativa: admin local amplio, WinRM/WMI en todas partes y segmentación débil. Los atacantes no necesitan trucos exóticos cuando el entorno está diseñado para movimiento sin fricción.

Conclusión: próximos pasos que puedes implementar esta semana

Si quieres progreso práctico—no una fantasía de hardening—haz esto en una semana:

1. Elige un grupo piloto de estaciones y aplica: deshabilita LLMNR, deshabilita Remote Registry, deshabilita WSH y restringe RDP.
2. En servidores de archivos, comprueba estado SMB1 y eventos de negociación SMB1; empieza a aislar o actualizar dispositivos dependientes de SMB1.
3. En servidores, inventaria el uso de WinRM y luego restringe inbound WinRM a subredes de gestión en lugar de convertirlo en una puerta abierta en todas partes.
4. Empieza a medir NTLM y crea un backlog de reducción. No adivines.
5. Escribe pasos de rollback para cada cambio y pruébalos una vez. Esa es la diferencia entre un despliegue con confianza y una reversión por pánico.

Apagar funciones arriesgadas de Windows no se trata de hacer tu entorno “perfecto”. Se trata de hacerlo aburridamente difícil para que los atacantes se muevan, y obviamente ruidoso cuando lo intentan.