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. En esta nota documentamos el baseline que corremos en produccion desde marzo de 2026: 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 durante nuestros propios ejercicios internos.

Empezamos por el hardware. Exigimos TPM 2.0 activo, Secure Boot con claves personalizadas, proteccion DMA habilitada y firmware con Intel Boot Guard o AMD Platform Secure Boot segun el fabricante. Sin esto, cualquier politica de software es teatro. El laptop estandar es un ThinkPad P14s Gen 5 o un Surface Laptop 7, ambos con SSD cifrado en XTS-AES 256 via BitLocker y PIN de pre-arranque de minimo 8 digitos. La clave de recuperacion vive en una boveda offline del equipo, nunca en cuenta Microsoft. Para quien quiera comparar el enfoque con Linux, escribimos Hardening de Linux Server: CIS Benchmark Aplicado sin Romper Produccion en el mismo estandar operativo.

Credential Guard y VBS son la primera capa de software que activamos via Group Policy: Device Guard, Virtualization Based Security, Secure Launch y HVCI obligatorios. En paralelo, LSASS corre como PPL con RunAsPPL=1 en el registro y auditoria de acceso activa. En pruebas internas esto rompio mimikatz convencional, comgost y dumps via comsvcs.dll sin necesidad de EDR. La proteccion LSA bloqueo el 100 por ciento de los intentos de inyeccion que reprodujimos desde Persistencia en Windows: 10 Tecnicas Documentadas y sus Contramedidas. El costo: cerca de 4 por ciento de overhead de CPU en compilaciones Rust pesadas, medido con nuestro pipeline de build del Sliver custom.

ASR (Attack Surface Reduction) viene despues y es donde la mayoria de equipos duda. Habilitamos las 16 reglas en modo block, no audit. Si, esto rompe macros de Office, procesos hijos de WMI, ejecucion de scripts ofuscados y USB no confiable. Mantenemos una OU separada llamada 'OffSec-Tools' donde algunas reglas quedan en audit para la maquina de laboratorio del investigador que necesita ejecutar 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 (block Office child processes) por si sola tumbo el 73 por ciento de los initial access que simulamos via Initial Access Simulado: Macros, LNK e ISO en un Lab Windows 11 Aislado.

AppLocker y WDAC operan en capas distintas. AppLocker controla user-mode con listas por publisher y ruta, ideal para frenar el ZIP sospechoso que el usuario bajo en Downloads. WDAC controla kernel y drivers via politica firmada con nuestro certificado EV, con las Microsoft Recommended Block Rules importadas en enero de 2026. Generamos la politica base con New-CIPolicy en modo audit durante 30 dias, recolectamos los event IDs 3076 y 3077, refinamos y movimos a enforce. Resultado: los drivers vulnerables catalogados en loldrivers.io, incluyendo los usados en rutinas de evasion que cubrimos en Evasion de EDR para Investigacion: Direct Syscalls Explicados sin Romantizar, simplemente no cargan. Solo binarios firmados por MS, Lenovo y nuestros hashes internos ejecutan.

Defender entra como ultima capa con Tamper Protection, Cloud Block Level alto, PUA en block, Network Protection encendido y Controlled Folder Access cubriendo Documentos, Desktop y el directorio de informes. Integramos los eventos con nuestro pipeline Sigma+Elastic descrito en Threat Hunting con Sigma y Elastic: Del Indicador a la Regla de Deteccion, con foco en alertas de modificacion de politica WDAC, creacion de servicio via sc.exe y acceso a handles LSASS con 0x1010. En 90 dias corriendo este stack en 47 estaciones tuvimos cero compromisos confirmados y 12 alertas de alto valor, dos de ellas intentos reales de drive-by durante engagements de bug bounty.

Takeaway practico: no intentes encender todo de golpe. Corre 30 dias en audit, exporta los logs a un SIEM, ajusta exclusiones minimas y solo entonces pasa a block. Documenta cada exclusion con ticket, owner y fecha de revision trimestral. El hardening que nadie revisa se pudre en seis meses. Si arrancas hoy desde cero, activa en este orden: BitLocker con PIN, Credential Guard, LSA PPL, ASR en block, AppLocker, WDAC audit, WDAC enforce. Cada paso por si solo ya paga el trabajo.