Hardening de Windows 11 para Estaciones de Trabajo de Alto Riesgo

Una estacion de pentester comprometida es una pesadilla regulatoria: claves SSH de clientes, capturas de credenciales, payloads firmados e informes bajo NDA conviven en la misma maquina. En Basilisk OffSec tratamos cada laptop Windows 11 como un endpoint hostil hasta prueba en contrario, y lo endurecemos como si el operador fuera a ser phisheado, asaltado y auditado en la misma semana. Esta nota documenta el baseline que corremos en produccion desde marzo de 2026 sobre 47 maquinas: reglas ASR en modo block, Credential Guard con VBS reforzado, AppLocker para el perimetro de usuario y WDAC para el kernel. La configuracion no es bonita, pero redujo de forma medible la superficie que mapeamos en Bypass de AMSI y ETW para Investigacion Defensiva: Lo que los Blue Teams Deben Saber. Esta version ampliada recorre toda la pila capa por capa, con los ajustes exactos, las contrapartidas y el orden de despliegue que evita que ladrilles tu propia flota.

El modelo de amenaza: por que el laptop del operador es la joya de la corona

Antes de tocar un solo objeto de directiva de grupo, escribe contra quien defiendes. Un laptop de seguridad ofensiva no es un endpoint corporativo normal: guarda secretos de cliente descifrados, perfiles de C2 e informes que describen como entrar en otras empresas. Los adversarios realistas son tres: un operador de phishing que aterriza un macro o un LNK malicioso, un ladron que roba el dispositivo en un aeropuerto y un atacante decidido que quiere especificamente los datos del cliente. Cada uno exige un control distinto. El phishing se responde con control de ejecucion (ASR, AppLocker, WDAC); el robo se responde con cifrado de pre-arranque y vinculo a TPM; el compromiso dirigido se responde con aislamiento de credenciales y telemetria. Saltarse el modelo y activar todo de golpe es como los equipos rompen labs de Caldera y luego, frustrados, desactivan la politica entera. Mapea los activos, priorizalos y deja que ese ranking decida que interruptor accionas primero.

Fundamento de hardware: TPM, Secure Boot, DMA y firmware

Todo control de software de abajo descansa sobre hardware confiable, asi que empezamos ahi. Exigimos TPM 2.0 activo, Secure Boot con nuestras propias claves inscritas, proteccion Kernel DMA habilitada y firmware con Intel Boot Guard o AMD Platform Secure Boot segun el fabricante. Sin esa raiz de confianza, cualquier politica es teatro: un ataque DMA por Thunderbolt o un cargador de arranque manipulado desmonta todo en minutos. El laptop estandar es un ThinkPad P14s Gen 5 o un Surface Laptop 7. Deshabilitamos CSM legado, bloqueamos el firmware con contrasena de supervisor y apagamos el arranque desde USB y red para la flota general. En firmware tambien deshabilitamos radios sin uso y el lector de huella cuando el modelo exige pre-arranque solo por PIN. Quien quiera el mismo estandar operativo en servidores, escribimos Hardening de Linux Server: CIS Benchmark Aplicado sin Romper Produccion con la misma filosofia.

Cifrado de disco completo: BitLocker con PIN de pre-arranque

BitLocker es innegociable y debe atarse a TPM mas PIN de pre-arranque, no solo a TPM. TPM-only desbloquea el disco automaticamente al arrancar, lo que significa que un laptop apagado y robado esta a un truco de cold-boot o DMA del texto plano. Forzamos XTS-AES 256, exigimos un PIN numerico de al menos ocho digitos (via la directiva de autenticacion adicional al inicio) y guardamos la clave de recuperacion de 48 digitos en una boveda offline del equipo, nunca en cuenta Microsoft ni en un Active Directory legible por el helpdesk. Tambien habilitamos BitLocker para unidades de datos fijas y extraibles, de modo que la particion de informes y cualquier USB de trabajo quedan cubiertos. La suspension de proteccion para actualizaciones casuales de firmware esta deshabilitada; cada desbloqueo se registra. Resultado: un dispositivo perdido es una perdida de hardware, no una notificacion de brecha.

Credential Guard, VBS, Secure Launch y HVCI

La primera capa de software es la seguridad basada en virtualizacion. Via Group Policy hacemos obligatorios Device Guard, Virtualization Based Security, Secure Launch y HVCI (integridad de codigo forzada por el hipervisor). Credential Guard mueve los hashes NTLM y los tickets Kerberos a un proceso aislado en VTL1 que el SO normal no puede leer, de modo que un punto de apoyo en la sesion de usuario no puede simplemente raspar credenciales de dominio de memoria. HVCI exige que solo corra en el kernel codigo firmado y verificado, cerrando la puerta a rootkits sin firmar y muchas cadenas BYOVD. Secure Launch usa el DRTM de la CPU para reestablecer confianza tras el firmware, achicando la ventana de arranque temprano. Hay un costo real: HVCI bloquea algunos drivers viejos y agrega unos puntos de overhead en compilaciones pesadas, medido con nuestro pipeline de build del Sliver custom. Ese costo compra una sesion de operador que filtra mucho menos cuando inevitablemente la pinchan.

Proteccion de LSASS: RunAsPPL y auditoria de acceso

Incluso con Credential Guard, LSASS sigue siendo blanco de dumping por handles, asi que lo corremos como Protected Process Light. Ponemos RunAsPPL=1 en HKLM\SYSTEM\CurrentControlSet\Control\Lsa (variante bloqueada por UEFI donde se soporta) y activamos la auditoria de acceso a LSASS. En pruebas internas esto rompio mimikatz convencional, el abuso de MiniDump via comsvcs.dll y varios trucos de duplicacion de handles sin necesidad de EDR, y la proteccion LSA bloqueo cada intento de inyeccion que reprodujimos desde Persistencia en Windows: 10 Tecnicas Documentadas y sus Contramedidas. El control complementario es una regla de deteccion sobre acceso a handles de proceso a lsass.exe con mascara de acceso deseada 0x1010 o 0x1410, la senal delatora de un intento de dump. Costo: cerca de cuatro por ciento de overhead de CPU en compilaciones Rust pesadas, medido con nuestro pipeline del Sliver custom. Precio barato para el camino de robo de credenciales mas abusado en Windows.

Reglas de Attack Surface Reduction en modo block

ASR viene despues y es justo donde la mayoria de equipos pierde el nervio. Habilitamos las dieciseis reglas en block, no en audit. Si, esto rompe procesos hijos de Office, ejecucion de scripts ofuscados, procesos generados por WMI y ejecutables USB no confiables. Mantenemos una OU separada llamada "OffSec-Tools" donde algunas reglas quedan en audit para la maquina de laboratorio del investigador que necesita correr Caldera, como describimos en Adversary Emulation con Caldera y MITRE ATT&CK en Laboratorio Corporativo. Para el resto de la flota, la regla D4F940AB-401B-4EFC-AADC-AD5F3C50688A (bloquear procesos hijos de Office) por si sola tumbo el 73 por ciento de los initial access que simulamos en Initial Access Simulado: Macros, LNK e ISO en un Lab Windows 11 Aislado. Combinala con bloquear robo de credenciales de LSASS, contenido ejecutable de correo y llamadas Win32 desde macros de Office para el mayor retorno por regla.

AppLocker para el perimetro de usuario

AppLocker y WDAC viven en capas distintas y quieres ambas. AppLocker gobierna user-mode con listas por publisher y por ruta y es ideal para frenar el ZIP sospechoso que el usuario bajo a Downloads o un script bajo un perfil de usuario. Denegamos por defecto la ejecucion desde ubicaciones escribibles (Downloads, Temp, AppData) y permitimos solo binarios firmados mas una ruta de herramientas curada bajo un directorio propiedad de admin. Las reglas cubren EXE, DLL, MSI, Script y apps empaquetadas; las reglas DLL estan activas pese a su costo porque el side-loading de DLL es una tecnica favorita de loaders. AppLocker se aplica via el servicio Application Identity y se audita primero: dos semanas en "solo auditoria", cosechamos los eventos 8003 y 8004, y luego pasamos a enforce. No es una frontera dura por si sola, pero como tamiz externo delante de WDAC elimina una enorme clase de basura lanzada por el usuario.

WDAC para la capa de kernel y drivers

WDAC (Windows Defender Application Control) es la verdadera frontera de integridad de codigo y cubre kernel y drivers via una politica firmada atada a nuestro certificado EV, con las Microsoft Recommended Driver Block Rules importadas en enero de 2026. Generamos la politica base con New-CIPolicy, la corremos en audit 30 dias, recolectamos los event IDs 3076 y 3077, refinamos y solo entonces la promovemos a enforce. El pago: los drivers vulnerables catalogados en loldrivers.io, incluyendo los usados en las rutinas de evasion que cubrimos en Evasion de EDR para Investigacion: Direct Syscalls Explicados sin Romantizar, simplemente no cargan. Solo ejecutan binarios firmados por Microsoft, por el OEM (Lenovo, Microsoft Surface) o que coinciden con nuestros hashes internos. Desplegamos la politica como archivo firmado y bloqueado por UEFI, de modo que un atacante con admin no pueda cambiarla en silencio, y alertamos ante cualquier evento de modificacion de politica como senal de alta severidad.

Microsoft Defender como ultima capa y su telemetria

Defender entra al final con Tamper Protection activa, Cloud Block Level en alto, PUA en block, Network Protection encendido y Controlled Folder Access cubriendo Documentos, Escritorio y el directorio de informes. El punto no es que Defender atrape todo; es que cada capa de arriba ya estrecho el campo, asi que Defender ahora es un sensor de alta senal en vez de un portero ruidoso. Enviamos los eventos al pipeline Sigma+Elastic descrito en Threat Hunting con Sigma y Elastic: Del Indicador a la Regla de Deteccion, con foco en modificacion de politica WDAC, creacion de servicio via sc.exe, persistencia por tareas programadas y acceso a handles LSASS con mascara 0x1010. En 90 dias sobre 47 estaciones registramos cero compromisos confirmados y doce alertas de alto valor, dos de ellas intentos reales de drive-by durante engagements de bug bounty. Telemetria sin turno de revision es decoracion, asi que cada clase de alerta tiene un owner nombrado y un runbook.

Metodologia de despliegue y gobernanza de exclusiones

El mayor modo de fallo es accionar todos los interruptores de golpe, romper a alguien a mitad de engagement y tener la politica entera desactivada con rabia antes del almuerzo. No lo hagas. Corre 30 dias en audit, exporta los logs a un SIEM, ajusta el conjunto minimo viable de exclusiones y solo entonces pasa a block. Cada exclusion recibe un ticket de Jira, un owner nombrado y una fecha de revision trimestral, porque el hardening que nadie revisa se pudre en seis meses cuando llegan herramientas y versiones de driver nuevas. Versiona las politicas como codigo en un repo git, firmalas en CI y despliegalas via Intune o tu gestor de configuracion para que el baseline sea reproducible y comparable. Trata la OU OffSec-Tools como una excepcion documentada y monitoreada, no como una puerta trasera permanente, y re-basalinala cada trimestre contra lo que los investigadores realmente siguen necesitando.

FAQ: rompe esto el tooling diario de pentest?

En su mayoria no, y donde lo hace la rotura es intencional y acotada. WDAC en enforce bloquea tooling custom sin firmar, por eso el lab del investigador vive en su propia OU con politica relajada y sin datos de cliente. Para la flota de produccion firmamos nuestros binarios internos y agregamos sus hashes a la politica WDAC, de modo que las herramientas caseras en Rust y Go corren mientras los ejecutables sin firmar al azar no. ASR en block impide que Office lance cmd.exe o PowerShell, algo que casi nunca ocurre en trabajo legitimo de operador; los pocos templates de reporte con muchos macros se migraron fuera de VBA. Si una herramienta de verdad necesita una excepcion, pasa por el proceso de exclusion con ticket en vez de una relajacion general de politica, de modo que el radio de impacto de cada permiso queda chico y auditable.

FAQ: como arranco desde cero sin caidas?

Activa controles en orden de dependencia para que cada paso sea valioso y reversible por si mismo. La secuencia que recomendamos es: primero BitLocker con PIN de pre-arranque, luego Credential Guard y VBS, luego LSA PPL, luego ASR en audit seguido de block, luego AppLocker en audit seguido de enforce, luego WDAC en audit seguido de enforce. Cada etapa corre al menos una semana con logs fluyendo al SIEM antes de que aterrice la siguiente, de modo que una regresion se contrasta contra una variable y no diez. Manten un rollback documentado para cada GPO y un admin local de emergencia guardado offline. Nadie deberia poder senalar un solo cambio y decir "no sabemos si eso fue lo que lo rompio", porque cambiaste exactamente una cosa a la vez.

Conclusion: un baseline que sobrevive al contacto

El hardening de estaciones de alto riesgo no es un proyecto heroico de un dia; es un baseline en capas que tiene que sobrevivir engagements reales, escenarios de robo reales y auditorias reales. Raiz de confianza en hardware, BitLocker con PIN, Credential Guard, LSA PPL, ASR en block, AppLocker, WDAC y un sensor Defender alimentando un pipeline monitoreado convierten juntos al laptop del operador de blanco blando en un lugar genuinamente hostil para aterrizar. El orden importa tanto como los ajustes: audit antes de block, una variable a la vez, cada excepcion con ticket y revisada. Hazlo en esa secuencia, manten las politicas en git, y correras operaciones ofensivas sobre maquinas que de verdad puedes defender, entregar a un auditor y perder en un aeropuerto sin escribir una notificacion de brecha.