La empresa publica en LinkedIn los nombres de todos sus empleados. Sin saberlo, también publica los usuarios de su Active Directory. Así consigo el primer acceso en casi todas mis auditorías reales — sin credenciales, sin acceso previo.

MITRE ATT&CK: T1589.003 — Gather Victim Identity Information: Employee Names · T1110.003 — Password Spraying · T1078 — Valid Accounts

La suposición habitual es que sin credenciales solo puedes hacer un escaneo de puertos y esperar. Eso no es cierto. Kerberos te da mucho más de lo que parece.

La mayoría de los auditores tratan la fase sin autenticar como una zona muerta. Solo reconocimiento. Pero entre los datos públicos que las empresas exponen voluntariamente y la información que Kerberos filtra antes de que te autentiques, puedes construir una lista de usuarios válidos, confirmar qué cuentas tienen configuraciones débiles y conseguir las primeras credenciales — todo antes de tocar un prompt de login. Este es el flujo exacto que sigo, en orden, en cada engagement.

Paso 1: Identificar el formato de usuario

Antes de enumerar nada, necesitas saber cómo el dominio formatea los nombres de usuario. La respuesta casi siempre está en datos públicos.

Empieza por LinkedIn, la web corporativa o cualquier dato de brechas que tengas permiso para revisar en el scope del engagement. Busca correos corporativos expuestos — tickets de soporte, commits en GitHub, ponentes de conferencias, ofertas de empleo. Un único correo confirmado es suficiente.

[email protected] te dice que el formato es first.last. Un solo dato se propaga a través de todas las cuentas del directorio. A partir de ese momento, cada nombre que encuentres se convierte en un candidato a nombre de usuario.

Formatos más frecuentes en entornos españoles y europeos:

first.last — el más común en empresas españolas y europeas
flast — inicial del nombre + apellido
f.last — inicial del nombre + punto + apellido
firstlast — sin separador

Cuando encuentres varias direcciones de correo, cruza los datos para confirmar que el formato es consistente. Algunas organizaciones usan formatos distintos según el departamento o en empresas adquiridas. Anota las excepciones.

Paso 2: Construir la lista con linkedin2username

Con el formato confirmado, scrapeamos la lista de empleados de la empresa en LinkedIn y convertimos los nombres directamente en candidatos a nombre de usuario.

python3 linkedin2username.py -c "Nombre de la Empresa" -n first.last
# Resultado: 300-500 usuarios potenciales del dominio

Fuente: github.com/initstring/linkedin2username

Esto produce una lista bruta de candidatos derivada de los empleados listados públicamente. Una empresa con 500 empleados en LinkedIn que lista a su plantilla públicamente te da entre 300 y 500 candidatos sin autenticación, sin tocar la red del cliente y sin generar ningún log en su infraestructura. El scraping ocurre completamente en los servidores de LinkedIn.

La calidad del resultado depende de cuántos empleados listan su empleador. Las empresas tecnológicas y de servicios profesionales tienden a tener más cobertura. Las empresas industriales o de manufactura suelen tener menos — sus ingenieros no actualizan LinkedIn con tanta frecuencia.

Paso 3: Complementar con statistically-likely-usernames

El scraping de LinkedIn solo cubre a los empleados que listan la empresa públicamente. Para los demás — el equipo de IT con el perfil en privado, el departamento de finanzas que nunca actualizó su empresa — necesitas otra fuente.

git clone https://github.com/insidetrust/statistically-likely-usernames
# Cubre nombres no encontrados en el scraping de LinkedIn

Este repositorio contiene listas de nombres derivadas de datos de censos y población, ordenadas por frecuencia estadística. Los 1.000 primeros nombres combinados con los 1.000 apellidos más frecuentes cubre una fracción sustancial de cualquier plantilla. Aplica el mismo formato de usuario que identificaste en el Paso 1 y fusiona el resultado con tu lista de LinkedIn.

Deduplica la lista combinada antes de pasar al siguiente paso. En este punto tendrás entre 800 y 2.000 candidatos a nombre de usuario. La mayoría serán incorrectos. El siguiente paso reduce esa lista a la realidad.

Paso 4: Validar usuarios vía Kerberos (sin bloqueos)

Aquí es donde el flujo se separa de la simple especulación.

kerbrute userenum --dc DC-IP -d dominio.local usuarios.txt -o validos.txt

Kerbrute envía paquetes Kerberos AS-REQ al controlador de dominio por cada candidato. El DC responde de forma diferente según si la cuenta existe:

Cuenta no existe: KDC_ERR_C_PRINCIPAL_UNKNOWN
Cuenta existe pero se requiere preautenticación: KDC_ERR_PREAUTH_REQUIRED
Cuenta existe y la preautenticación está deshabilitada: el DC devuelve un TGT directamente — una cuenta roasteable con AS-REP

La propiedad crítica: Kerbrute distingue entre "la cuenta no existe" y "contraseña incorrecta" sin enviar ninguna contraseña en ningún momento. No hay intento de autenticación. No se genera ningún evento de fallo. No hay bloqueo de cuentas. Windows registra el Event ID 4768 para las solicitudes de ticket Kerberos, pero los defensores suelen alertar sobre fallos repetidos para la misma cuenta, no sobre respuestas KDC_ERR_C_PRINCIPAL_UNKNOWN en volumen.

Por eso usas Kerbrute y no LDAP para la enumeración sin autenticar. LDAP desde fuera de la red requiere una operación de bind — tienes que autenticarte antes de poder consultar. Kerberos está diseñado para responder a la pregunta "¿existe este principal?" como parte del flujo normal del protocolo.

Resultado típico: entre 800 y 2.000 candidatos entran, entre 80 y 150 usuarios válidos confirmados salen.

Paso 5: Verificar la política de contraseñas antes de sprayear

Nunca hagas spray sin leer la política. Esto no es opcional.

nxc smb DC-IP -u '' -p '' --pass-pol

Las sesiones nulas SMB están deshabilitadas por defecto en Windows moderno, pero el comando funciona más a menudo de lo que esperarías — especialmente en entornos con sistemas legacy o DCs anteriores a 2019. Cuando funciona, devuelve el umbral de bloqueo y la ventana de observación.

Lo que necesitas antes de tocar una sola cuenta:

Lockout threshold — cuántos intentos fallidos antes del bloqueo
Observation window — cuánto tiempo antes de que se reinicie el contador
Lockout duration — cuánto tiempo permanece bloqueada una cuenta

Si las sesiones nulas están bloqueadas, comprueba si el DC expone la política vía LDAP anonymous bind o vía respuestas AS-REP. Como alternativa, revisa datos de brechas o documentos públicos — algunas organizaciones reguladas publican sus políticas de seguridad.

La regla conservadora: un intento por cuenta por ventana de observación. Si la política es tres intentos en 30 minutos, mandas una contraseña por cuenta cada 30 minutos. Sprayear más rápido que eso es la forma de bloquear 200 cuentas y terminar el engagement.

Paso 6: Password spraying con patrón estacional

nxc smb DC-IP -u validos.txt -p 'Marzo2026!' --continue-on-success

Las contraseñas estacionales existen en todos los entornos. No por descuido — porque las políticas de rotación obligan a cambiarlas y nadie memoriza cadenas aleatorias. Cuando obligas a cambiar la contraseña cada 90 días, los usuarios resuelven el problema de forma racional: codifican la estación o el mes actual y el año, y añaden un carácter especial. Funciona. Es fácil de recordar. Y es predecible.

Patrones que producen resultados en entornos españoles, en orden aproximado de tasa de éxito:

Mes+Año! — Marzo2026!, Enero2026!, Octubre2025!
Empresa+Año! — derivado del nombre de la organización
Bienvenido1! — default de incorporación que nunca se cambió
Password1! — sigue funcionando en 2026, en todos los engagements

Ejecuta --continue-on-success para que netexec no se detenga en el primer resultado. En una lista de 100 usuarios válidos, las contraseñas estacionales suelen producir entre dos y cinco aciertos. Con uno es suficiente.

Cuando Kerbrute devolvió cuentas con la preautenticación deshabilitada en el Paso 4, sáltate el spray para esas cuentas — extrae sus hashes directamente y rompe offline. Ese es el flujo de AS-REP roasting y no requiere adivinar ninguna contraseña. El Kerberoasting llega después, una vez tienes acceso autenticado.

El insight contraintuitivo

Kerberos es la clave: te dice si un usuario existe sin que tengas que autenticarte y sin generar bloqueos. LDAP no te da eso desde fuera. La mayoría de los defensores no monitorizan los fallos de AS-REQ como actividad sospechosa — monitorizan los intentos de login fallidos, que este flujo no genera ninguno.

Y las contraseñas estacionales existen en el 100% de los entornos. Sin excepción. La rotación forzada de contraseñas es exactamente lo que las crea. Cuanto más estrictamente obligas a rotar, más predecibles se vuelven las contraseñas.

El gap no está en las herramientas que despliegan los defensores. Está en lo que eligen instrumentar. El volumen de fallos de preautenticación Kerberos desde una única fuente es detectable. La mayoría de las organizaciones no lo están buscando.

Cómo gestiona ADscan esta fase

ADscan ejecuta las fases 0 y 1 automáticamente. El comando start_unauth enumera el dominio sin credenciales — reconocimiento DNS, intentos de sesión nula SMB, LDAP anonymous bind y descubrimiento de cuentas AS-REP roastables. Las cuentas con la preautenticación deshabilitada se muestran inmediatamente, con el paso de extracción de hashes listo para ejecutar.

La enumeración de usuarios válidos, la comprobación de AS-REP y el spray inicial ocurren en un solo comando en lugar de seis herramientas separadas. El resultado alimenta directamente el grafo de ataque para que veas qué cuentas descubiertas tienen caminos hacia Domain Admin antes de decidir dónde enfocar el engagement.

¿Realizas 2 o más engagements de AD al año? Solicita acceso beta PRO — gratuito durante 90 días.

Detección

Enumeración de usuarios con Kerbrute: Event ID 4768 con código de resultado 0x6 (KDC_ERR_C_PRINCIPAL_UNKNOWN) — detectable si monitorizas específicamente los fallos Kerberos contra cuentas inexistentes en volumen desde una única IP de origen. La mayoría de las reglas SIEM alertan sobre el Event ID 4625 (fallo de inicio de sesión), que esta técnica no genera ninguno.

Password spraying: Event ID 4625 con múltiples cuentas desde la misma IP de origen. Un spray con rate limiting — un intento por cuenta por ventana de observación — es difícil de distinguir del ruido de fondo de fallos normales en la mayoría de organizaciones. La señal está en el patrón: muchas cuentas distintas, mismo origen, misma contraseña, espaciadas uniformemente en el tiempo.

linkedin2username: Sin detección a nivel de red. Scrapeada una web pública. La propia detección de abuso de LinkedIn puede marcar la sesión, pero no hay nada que detectar en la infraestructura de la organización objetivo.

Prevención

Deshabilita las exenciones de preautenticación. Cada cuenta con DONT_REQ_PREAUTH activado es explotable sin necesidad de adivinar una contraseña. Audita y remedia. Casi nunca hay una razón técnica legítima para esta configuración en entornos modernos.

Monitoriza los fallos de preautenticación Kerberos en bloque desde una única fuente. Construye una regla SIEM para volumen alto de eventos 4768 con código de resultado 0x6 desde una única IP de origen en una ventana corta. Ajusta el umbral según tus patrones normales de autenticación.

Usa ventanas de observación más largas en la política de bloqueo. Contraintuitivamente, una ventana de observación de 60 minutos dificulta más el spraying que una de 30 minutos — el atacante solo puede enviar un intento por cuenta por hora en lugar de por media hora. No previene el spray, pero extiende el tiempo necesario para recorrer el espacio de contraseñas.

Audita la exposición de empleados en LinkedIn. No puedes impedir que los empleados listen su empleador, pero sí entender lo que ve un atacante. Ejecuta linkedin2username contra tu propia organización trimestralmente y revisa el resultado.

Para la metodología completa desde el acceso inicial hasta el compromiso del dominio, consulta la guía de pentesting de Active Directory.