Evaluación con PingCastle: del informe de AD al plan

Un informe de PingCastle es la forma más rápida de obtener una imagen honesta de un dominio de Active Directory. También es fácil usarlo mal. Algunos equipos lo ejecutan una vez, ven una puntuación en rojo, corrigen los tres hallazgos más fáciles y no vuelven a abrirlo. Otros persiguen una puntuación de cero y dedican semanas a higiene de poco impacto mientras un servidor con delegación sin restricciones o una GPO modificable sobre la OU Domain Controllers siguen abiertos. Esta guía explica cómo ejecutar PingCastle de forma segura, cómo leer sus resultados como pretende el modelo de puntuación y cómo convertir los hallazgos en un plan de corrección con responsables, orden y verificación.

La estrategia de evaluación más amplia, incluida la comparación con las líneas de base de SCT y CIS y el encaje de PingCastle junto a Purple Knight, está en la guía pilar de evaluación, copia de seguridad y recuperación. Esta guía trata de cómo pasar de un informe a un plan ejecutado.

Medir: ejecutar el health check

Descargue PingCastle desde su sitio oficial en una estación de trabajo de administración o en una estación de trabajo de acceso privilegiado. Verifique la firma del archivo y no lo ejecute desde un DC. Ejecútelo como usuario de dominio estándar. El health check no necesita derechos administrativos, y ejecutarlo como Domain Admin solo expone una credencial de Tier 0 en otro equipo.

# Verificar el binario antes del primer uso
Get-AuthenticodeSignature .\PingCastle.exe | Select-Object Status, SignerCertificate

# Health check contra un dominio concreto
.\PingCastle.exe --healthcheck --server corp.example.com

Si ejecuta PingCastle.exe sin argumentos, se abre un menú interactivo. La opción 1 es el mismo health check. Cada ejecución genera dos archivos con el nombre del dominio:

• ad_hc_<domain>.html, el informe para personas.
• ad_hc_<domain>.xml, los datos para el seguimiento de tendencias y los scripts. Contiene datos detallados sobre su dominio, así que guárdelo con el mismo cuidado que el HTML.

Ejecútelo una vez por dominio, incluidos todos los dominios secundarios y cualquier dominio en el que confíe. La sección de confianzas muestra lo que expone el dominio analizado, pero los riesgos internos de un dominio de confianza solo aparecen cuando analiza ese dominio.

Auditar: leer bien el informe

Las cuatro puntuaciones

PingCastle agrupa las reglas en cuatro categorías, cada una puntuada de 0 (lo mejor) a 100:

La puntuación de riesgo del dominio es la más alta de las cuatro, no la suma. Un dominio con 15, 10, 0 y 85 obtiene 85, porque a un atacante le basta con una categoría mala. También significa que corregir Stale Objects no mueve la puntuación principal mientras Anomalies sea la peor categoría.

Niveles de madurez e ID de regla

Cada regla tiene un ID con un prefijo de categoría (S-, P-, T-, A-), un valor en puntos y un nivel de madurez de 1 a 5. Los hallazgos de nivel 1 son los más críticos. La sección de madurez del informe indica el nivel más bajo en el que su dominio falla, y esa es una métrica de progreso para la dirección mejor que la puntuación bruta. Pasar del nivel 1 al nivel 3 es una mejora real aunque la puntuación apenas se mueva.

Despliegue cada regla en el informe HTML. El detalle enumera los objetos exactos implicados y enlaza con la documentación en la que se basa la regla. Trabaje siempre a partir de la lista de objetos, no del título de la regla.

Clasificar: convertir los hallazgos en un plan

Exporte las reglas desde el XML para poder incorporarlas a un sistema de seguimiento:

[xml]$hc = Get-Content .\ad_hc_corp.example.com.xml
$hc.SelectNodes('//HealthcheckRiskRule') |
  Select-Object RiskId, Category, Points, Rationale |
  Sort-Object Points -Descending |
  Export-Csv .\pingcastle-findings.csv -NoTypeInformation

Clasifique cada hallazgo en uno de estos cuatro grupos:

1. Corregir esta semana (ruta de ataque hacia Tier 0). Todo lo que dé a un usuario sin privilegios de administrador una vía hacia el control total del dominio. Algunos ejemplos son la delegación sin restricciones en servidores que no son DC, las ACE peligrosas en objetos privilegiados, las entidades de seguridad no predeterminadas con derechos de DCSync, las contraseñas GPP, las plantillas de AD CS vulnerables a ESC1 y el servicio de cola de impresión en ejecución en los DC. Se corresponden directamente con los derechos de DCSync, la eliminación de la delegación sin restricciones y la auditoría de plantillas de certificado.
2. Proyectos (requieren control de cambios). Configuraciones que pueden romper aplicaciones: firma LDAP, restricciones de NTLM, firma SMB, eliminación de RC4, implementación de LAPS. Asigne a cada una un responsable, un grupo piloto y una fase de auditoría antes de aplicarla.
3. Higiene (trabajo por lotes). Cuentas inactivas, objetos de equipo antiguos, contraseñas que no caducan en cuentas que no son de servicio. Automatícelo en lugar de corregirlo a mano.
4. Riesgo aceptado. Una excepción documentada con un responsable de negocio, un control compensatorio y una fecha de revisión. PingCastle no conoce sus excepciones, así que el registro reside en su sistema de seguimiento.

Dos reglas mantienen la honestidad del proceso. Primero, cada elemento del grupo 1 recibe un responsable y una fecha en cuestión de días. Segundo, las categorías Privileged Accounts y Trusts se revisan en cada ejecución, porque son las que cambian más rápido y las que más importan.

Asigne cada hallazgo al método del sitio: Medir (la lista de objetos del informe), Auditar (activar el registro para la configuración antes de cambiarla), Aplicar y Verificar (la siguiente ejecución de PingCastle). La lista de comprobación de hardening ofrece un orden predeterminado si lo necesita.

Presentar los resultados

La dirección no necesita el informe HTML. Necesita tres cosas en una sola página: el nivel de madurez actual y su tendencia, el número de hallazgos abiertos del grupo 1 con su antigüedad y la lista de riesgos aceptados con sus responsables nominales. Deje la puntuación bruta en un anexo, porque oscila con los cambios de reglas y da pie a la conversación equivocada.

Para cada dominio, muestre las puntuaciones por categoría una junto a otra. Un bosque cuyo dominio raíz está en el nivel de madurez 3 pero cuyo dominio secundario adquirido está en el nivel 1 es un bosque de nivel 1, porque las confianzas dentro de un bosque no detienen a un atacante. Dígalo explícitamente, para que la financiación vaya al dominio más débil y no al más visible.

Aplicar: programar y seguir la tendencia

Un único informe es una instantánea. Programe el health check para que cualquier deriva aparezca en menos de una semana:

$action  = New-ScheduledTaskAction -Execute 'C:\Tools\PingCastle\PingCastle.exe' `
  -Argument '--healthcheck --server corp.example.com' -WorkingDirectory 'D:\PingCastle\Reports'
$trigger = New-ScheduledTaskTrigger -Weekly -DaysOfWeek Monday -At 6am
Register-ScheduledTask -TaskName 'PingCastle weekly' -Action $action -Trigger $trigger `
  -User 'CORP\svc-pingcastle' -Password (Read-Host 'Password')

Mejor aún, use una gMSA como identidad de la tarea para no almacenar ninguna contraseña. Conserve los archivos XML, renombrados con la fecha, en una carpeta que solo pueda leer el equipo de seguridad. Actualice PingCastle de forma deliberada, no automática, e indique la versión en el nombre de archivo de cada informe. Un cambio de reglas nunca debe confundirse con un cambio en su dominio.

Verificar

Después de cada sprint de corrección, vuelva a ejecutarlo y compare los conjuntos de reglas en lugar de las puntuaciones:

[xml]$old = Get-Content .\2026-08-31_ad_hc_corp.example.com.xml
[xml]$new = Get-Content .\2026-09-28_ad_hc_corp.example.com.xml
$o = $old.SelectNodes('//HealthcheckRiskRule').RiskId
$n = $new.SelectNodes('//HealthcheckRiskRule').RiskId
Compare-Object $o $n | ForEach-Object {
  [pscustomobject]@{ RiskId = $_.InputObject; Change = if ($_.SideIndicator -eq '=>') {'NEW'} else {'FIXED'} }
}

Trate cada regla NEW en Privileged Accounts o Trusts como un incidente hasta que se explique. Compruebe quién cambió qué con los eventos de grupos y confianzas de la referencia de ID de evento. En los elementos corregidos, confirme que la lista de objetos está vacía, no solo que el valor en puntos ha bajado de un umbral.

Qué se rompe

Ejecutar PingCastle es una operación de solo lectura, pero actuar sobre su informe sin la fase de auditoría rompe cosas:

• Aplicar directamente los hallazgos de protocolos. Exigir la firma LDAP, deshabilitar NTLMv1 o eliminar RC4 porque lo diga un informe, sin la fase de auditoría, provoca interrupciones del servicio. Los dispositivos antiguos, los escáneres y las aplicaciones Java son los primeros en fallar.
• Deshabilitar en masa las cuentas inactivas. «Inactiva» se basa en lastLogonTimestamp, que puede tener un retraso de hasta 14 días, y algunas cuentas de servicio se autentican de formas que no lo actualizan. Deshabilítelas por lotes, muévalas a una OU de cuarentena y elimínelas solo tras un periodo de espera.
• Agregar administradores a Protected Users. Esto elimina NTLM, DES, RC4 y la delegación de credenciales para esas cuentas. Pruebe el flujo de trabajo de cada administrador antes de un cambio masivo.
• Alertas de las herramientas de seguridad. El health check realiza consultas LDAP amplias que Defender for Identity o sus honeytokens pueden marcar como reconocimiento. Informe al SOC de qué cuenta y qué host lo ejecutan, y exclúyalo deliberadamente de las reglas de los señuelos.

Lecturas relacionadas: el área de evaluación, copia de seguridad y recuperación cubre el resto de esta serie, la gestión de rutas de ataque encuentra las vías hacia Tier 0 que los analizadores basados en reglas no ven, y proteger las copias de seguridad de AD frente al ransomware trata el control que PingCastle no puede comprobar por usted.