Pentest de Active Directory: alcance y pruebas para empresas

Por Carlos Isidoro De Ayala Diaz ·

Pentest de Active Directory: define dominios, accesos, pruebas, límites operativos, evidencias y retest antes de autorizar una evaluación interna segura.

Diferencia el pentest de Active Directory de una revisión de configuración

Una revisión de configuración compara el directorio con criterios técnicos y localiza cuentas, permisos o políticas que merecen atención. Puede identificar grupos privilegiados con demasiados miembros, cuentas inactivas, delegaciones peligrosas o protocolos heredados. Ese análisis aporta valor, pero no demuestra por sí solo que un usuario con acceso limitado pueda encadenar varias condiciones y alcanzar un activo crítico.

El pentest de Active Directory añade una comprobación controlada. Parte de un acceso acordado y valida hasta dónde podría progresar un atacante dentro del entorno autorizado. No necesita convertir cada hallazgo en una explotación completa. La prueba debe obtener evidencia suficiente para confirmar el camino, explicar las precondiciones y detenerse antes de causar un impacto innecesario.

Un red team tiene otro objetivo. El contexto cambia. Puede evaluar detección y respuesta mediante un escenario más amplio, con menos conocimiento previo para parte de la organización. Puede incluir persistencia, evasión o movimientos que no forman parte de una evaluación interna convencional. No se debe suponer que estas actuaciones están incluidas porque la propuesta utilice expresiones como simulación de ataque.

Microsoft describe el acceso privilegiado como un camino completo formado por identidad, dispositivo, intermediarios e interfaz de administración. Esta idea ayuda a definir el trabajo. Revisar solo los grupos del dominio puede dejar fuera el equipo desde el que se administra, la VPN, una herramienta de gestión o una identidad híbrida con privilegios en Microsoft Entra ID. La propuesta debe indicar qué partes de ese camino se evaluarán.

Diferencias entre revisión, pentest interno y red team en un entorno Active Directory
ModalidadPunto de partidaEvidencia esperada
Revisión de configuraciónExportaciones, lectura autorizada o consola administrativaDesviaciones, exposición y recomendaciones sin explotación
Pentest internoUsuario, equipo o segmento acordadoCaminos de acceso comprobados con impacto controlado
Escenario híbridoIdentidad o sistema conectado a AD y Entra IDRelación entre privilegios locales, nube y controles de acceso
Red teamObjetivo y reglas de enfrentamiento específicasCapacidad de detección y respuesta ante un escenario autorizado

Define el punto de partida y los activos autorizados

El punto de partida determina qué pregunta responde la prueba. ¿Representa a un usuario estándar, un equipo corporativo o una conexión VPN de proveedor? Cada opción conduce a un escenario diferente. Empezar con una cuenta administrativa puede ser útil para revisar configuración, pero no demuestra el recorrido desde un acceso limitado.

El inventario debe nombrar dominios, bosques, relaciones de confianza y sedes incluidas. También concreta controladores de dominio, estaciones, servidores, sistemas de administración y servicios de identidad relacionados. Si existe sincronización con Microsoft Entra ID, se decide si forma parte del alcance. Las cuentas con privilegios simultáneos en nube y directorio local pueden unir dos planos de control, pero no deben probarse fuera de la autorización.

Conviene decidir expresamente si se revisan la infraestructura de clave pública y Active Directory Certificate Services, las cuentas de servicio, las políticas de grupo, las listas de control de acceso y la gestión de administradores locales. El hecho de que una tecnología dependa del dominio no la incorpora automáticamente. Un sistema alojado por un tercero, una aplicación crítica o una filial pueden requerir permiso adicional de su titular.

La empresa debe facilitar contactos, ventanas de trabajo y restricciones conocidas. También informa de sistemas frágiles, bloqueos de cuenta, horarios de procesos y cambios previstos. El equipo de pruebas necesita saber cómo comunicar un hallazgo crítico y quién puede autorizar una ampliación. Según el NCSC, cuando aparece un componente relacionado pero fuera de alcance, el responsable de riesgo decide si se amplía la prueba o se documenta la limitación.

Las cuentas de prueba deben tener propietario, vigencia y finalidad. Si se usan datos reales, se limita su consulta a lo imprescindible y se acuerda cómo se protegerán las evidencias. Siempre que sea posible, se preparan usuarios, grupos o archivos señuelo para demostrar acceso sin abrir información personal o comercial. El alcance identifica además qué registros conservará la empresa para relacionar la actividad del test con sus controles de detección.

Acordar pruebas, límites y condiciones de parada

Las pruebas deben seguir objetivos, no una lista automática de técnicas. ¿Qué camino necesita comprobar la empresa y hasta qué impacto puede llegar? Un bloque puede revisar cuentas y grupos privilegiados, incluidos miembros anidados y cuentas de servicio. Otro puede comprobar permisos sobre objetos sensibles, delegaciones, relaciones de confianza y administración local.

Microsoft señala riesgos como privilegios simultáneos en Entra ID y Active Directory, cuentas de servicio dentro de grupos críticos, delegación de cuentas privilegiadas y permisos capaces de modificar grupos sensibles. También documenta la exposición de credenciales mediante LDAP sin protección y la importancia de contraseñas locales distintas con Windows LAPS. Estos elementos orientan la cobertura, pero el informe debe reflejar lo observado en el entorno concreto.

Los ataques de contraseña requieren límites específicos. La propuesta indica si se permiten, con qué cuentas, frecuencia y umbral. Antes se revisa la política de bloqueo y se excluyen identidades críticas. Una prueba no debe provocar una interrupción para demostrar que existe una contraseña débil. Puede utilizar cuentas preparadas o validar una muestra controlada cuando el riesgo operativo no permite trabajar con usuarios reales.

El acceso a credenciales, la replicación del directorio, la modificación de objetos o el control de un servidor pueden tener consecuencias amplias. La autorización debe indicar qué acciones se pueden simular, cuáles requieren confirmación inmediata y cuáles quedan prohibidas. No hace falta copiar una base de datos de directorio ni extraer documentos reales para demostrar que un permiso permitiría hacerlo. Una evidencia mínima y reproducible suele ser más útil y segura.

Las condiciones de parada cubren bloqueos, degradación, acceso a datos inesperados, aparición de sistemas fuera de alcance y señales de un incidente real. Se designa un contacto disponible durante la ventana de pruebas. El equipo registra la hora, el origen y la acción realizada para que operaciones pueda distinguir el ejercicio de otra actividad. NIST SP 800-115 sitúa estas reglas antes de la ejecución, no como una decisión improvisada cuando ya existe impacto.

Exige evidencias, recomendaciones y una segunda comprobación

El informe debe mostrar caminos, no solo alertas aisladas. Cada hallazgo identifica el punto de partida, las condiciones necesarias, los objetos o sistemas afectados y la evidencia de la comprobación. Explica hasta dónde llegó la prueba y dónde se detuvo. También separa un riesgo confirmado de una hipótesis que no pudo validarse por límites operativos o falta de autorización.

La prioridad combina impacto y exposición. Ese contexto importa. Una cuenta de servicio con privilegios amplios puede ser crítica si opera en muchos equipos y conserva credenciales duraderas. El mismo nombre técnico puede tener un riesgo distinto si la cuenta está aislada, supervisada y limitada. La recomendación debe señalar el control que rompe el camino: reducir privilegios, separar cuentas, corregir permisos, proteger delegaciones o aislar la administración.

Las capturas y salidas de herramientas necesitan contexto. El informe conserva fechas, identificadores técnicos y pasos suficientes para que el equipo responsable reproduzca la condición sin entregar secretos innecesarios. Incluye un resumen ejecutivo y un anexo técnico. El primero explica decisiones y prioridades. El segundo permite ejecutar correcciones y comprobar después si el camino ha desaparecido.

Entregar recomendaciones no significa que las correcciones estén ejecutadas. Cambiar permisos, cuentas, delegaciones o políticas puede afectar servicios y requiere un alcance propio. La propuesta debe especificar si contempla apoyo a la remediación. También debe indicar si incluye un retest y qué hallazgos se volverán a comprobar. Una segunda revisión acotada no equivale a repetir todo el pentest de Active Directory.

Las certificaciones OSCP y OSEP respaldan conocimientos de evaluación técnica, pero no sustituyen un alcance bien definido ni garantizan que no existan otros caminos. Élite Solutions Tech puede preparar desde Murcia una propuesta para empresas regionales y nacionales. La propuesta concretará sistemas, accesos, pruebas, evidencias, correcciones y segunda comprobación sin dar por incluidas actuaciones no autorizadas.