auditing-tls-certificate-transparency-logs

Auditoría de Logs de Transparencia de Certificados TLS

Cuándo Usar

• Monitorear dominios propios para detectar emisiones de certificados no autorizadas o inesperadas por parte de Autoridades de Certificación desconocidas.
• Descubrir subdominios y servicios ocultos mediante certificados registrados en logs CT públicos.
• Detectar infraestructura de phishing que utiliza certificados de dominios similares (typosquatting, ataques homógrafos).
• Auditar el cumplimiento de las Autoridades de Certificación verificando que todos los certificados emitidos aparecen en los logs CT según lo requieren las políticas de los navegadores.
• Construir un monitoreo continuo de certificados en un pipeline de operaciones de seguridad con alertas para nuevas emisiones.

No usar para atacar o interrumpir a las Autoridades de Certificación, para extraer logs CT violando límites de velocidad o términos de servicio, ni como el único método de enumeración de subdominios sin corroborar los resultados mediante verificación DNS.

Requisitos Previos

• Python 3.10+ con las bibliotecas requests, cryptography y pyOpenSSL instaladas.
• Acceso de red a crt.sh (HTTPS) y servidores públicos de logs CT.
• Una lista de dominios a monitorear (dominios propios, variaciones de marca, candidatos a typosquat).
• Credenciales SMTP o URL de webhook para alertar sobre nuevos descubrimientos de certificados.
• Comprensión básica de la estructura de certificados X.509 y la validación de cadenas de certificados TLS.

Flujo de Trabajo

Paso 1: Inventario de Dominios y Línea Base

Construir el inventario inicial de certificados para los dominios monitoreados:

• Definir el alcance del monitoreo: Enumere todos los dominios raíz propios, nombres de marca registrados y filiales conocidas. Incluya patrones comodín (%.ejemplo.com) para una cobertura completa de subdominios.
• Consultar crt.sh para certificados históricos: Use la API JSON de crt.sh para recuperar todos los certificados conocidos para cada dominio. El endpoint de la API https://crt.sh/?q=%.ejemplo.com&output=json devuelve certificados que coinciden con el patrón comodín con campos que incluyen issuer_ca_id, issuer_name, common_name, name_value, not_before, not_after y serial_number.
• Construir la base de datos de línea base: Almacene el conjunto inicial de certificados en una base de datos SQLite local con columnas para ID del certificado, dominio, emisor, fechas de validez, SANs (Subject Alternative Names) y marca de tiempo de primera aparición. Esta línea base evita alertar sobre certificados ya conocidos.
• Identificar AC autorizadas: A partir de la línea base, extraiga el conjunto de Autoridades de Certificación que han emitido legítimamente certificados para sus dominios. Cualquier emisión futura de una AC que no esté en este conjunto activa una alerta de alta prioridad.
• Mapear subdominios: Extraiga todos los subdominios únicos del campo name_value de todos los certificados para construir un inventario inicial de subdominios.

Paso 2: Monitoreo Continuo de Logs CT

Configurar el monitoreo continuo de nuevas emisiones de certificados:

• Consultar crt.sh periódicamente: Consulte la API de crt.sh a intervalos regulares (cada 15-60 minutos) para obtener nuevos certificados. Use el parámetro exclude=expired para centrarse en los certificados actualmente válidos. Compare los resultados con la base de datos de línea base para identificar nuevas entradas.
• Analizar los detalles del certificado: Para cada nuevo certificado, extraiga la lista completa de SAN, la cadena de emisores, el período de validez, el tipo y tamaño de clave, los detalles del SCT (Signed Certificate Timestamp) del log CT y la huella digital del certificado (SHA-256).
• Detectar precertificados: Los logs CT incluyen precertificados (certificados envenenados enviados antes de la emisión final). Realice un seguimiento de estos como advertencias tempranas, ya que indican que un certificado está a punto de emitirse, pero puede que aún no esté activo.
• Monitorear los Signed Tree Heads (STH) del log CT: Para un monitoreo avanzado, consulte directamente los servidores de logs CT para obtener el STH más reciente y verificar las pruebas de consistencia entre cabezas de árbol consecutivas. Una inconsistencia indica un mal comportamiento del log (ataque de visión dividida).
• Respetar los límites de velocidad: Respete los límites de velocidad de crt.sh espaciando las consultas y almacenando en caché las respuestas. Implemente un retroceso exponencial en respuestas HTTP 429. Para monitoreo de alto volumen, considere consultar la interfaz PostgreSQL de crt.sh directamente en crt.sh:5432.
• Alternativa Atom/RSS: Suscríbase al feed Atom de crt.sh para un monitoreo más ligero: https://crt.sh/atom?q=%25.ejemplo.com proporciona notificaciones en tiempo real de nuevas entradas en el log.

Paso 3: Descubrimiento de Subdominios Mediante Datos CT

Extraer y validar subdominios encontrados en los datos de transparencia de certificados:

• Expansión de comodines: Los certificados con SAN comodín (*.dev.ejemplo.com) revelan la existencia de subdominios que pueden no estar en los archivos de zona DNS. Registre el dominio principal como un objetivo para una enumeración adicional.
• Minería de certificados históricos: Consulte crt.sh sin el parámetro exclude=expired para encontrar subdominios de certificados caducados que aún puedan resolverse en DNS. Estos representan infraestructuras históricas que podrían ser vulnerables a una toma de control de subdominios.
• Validación DNS: Para cada subdominio descubierto, realice una resolución DNS (registros A, AAAA, CNAME) para determinar si el subdominio está actualmente activo. Compare con rangos de IP conocidos para identificar TI en la sombra o servicios no autorizados.
• Detección de typosquat: Genere permutaciones del dominio monitoreado (bitsquatting, homógrafo, inserción, omisión, transposición, reemplazo adyacente al teclado) y consulte los logs CT en busca de certificados emitidos para estas variaciones. Los certificados para dominios typosquat indican firmemente una infraestructura de phishing.
• Deduplicación y enriquecimiento: Normalice los subdominios descubiertos (minúsculas, eliminar puntos finales), deduplíquelos y enriquézcalos con datos WHOIS, geolocalización de IP y encabezados de respuesta HTTP para priorizar la investigación.

Paso 4: Alertas de Emisión de Certificados

Configurar reglas de alerta para eventos de certificados relevantes para la seguridad:

• Alerta de AC no autorizada: Se activa cuando un certificado es emitido por una AC que no está en la lista de AC autorizadas. Esta es la alerta de mayor prioridad, ya que puede indicar secuestro de dominio, secuestro BGP para validación de dominio o una AC comprometida.
• Alerta de nuevo subdominio: Se activa cuando un certificado contiene una SAN con un subdominio no visto anteriormente. Esto detecta implementaciones de TI en la sombra y servicios no autorizados.
• Alerta de certificado comodín: Se activa ante cualquier nueva emisión de un certificado comodín, ya que los certificados comodín tienen un impacto más amplio si se ven comprometidos y su emisión debe controlarse estrictamente.
• Anomalía de certificado de corta duración: Alerta cuando los certificados tienen períodos de validez inusualmente cortos (menos de 24 horas) que se desvían del ciclo de vida normal de los certificados de la organización, ya que esto puede indicar abuso de Let's Encrypt o infraestructura de phishing automatizada.
• Advertencia de vencimiento: Alerta cuando los certificados de servicios críticos se acercan al vencimiento (30, 14, 7 días) según el campo not_after de los datos del log CT.
• Entrega de alertas: Envíe alertas por correo electrónico (SMTP), webhook de Slack, PagerDuty o escríbalas en un formato de registro JSON compatible con SIEM para su integración con el monitoreo de seguridad existente.

Paso 5: Verificación de Integridad y Reportes de Logs CT

Verificar la integridad del log y producir evidencia de cumplimiento:

• Monitoreo de Signed Tree Head (STH): Obtenga el STH más reciente de cada log CT monitoreado a través del endpoint de API get-sth. El STH contiene el tamaño del árbol y una marca de tiempo firmada. Verifique la firma utilizando la clave pública del log.
• Verificación de prueba de consistencia: Entre recuperaciones consecutivas de STH, solicite una prueba de consistencia a través de get-sth-consistency para verificar que el log solo permite anexar y no se han modificado ni eliminado entradas.
• Informe de inventario de certificados: Elabore un inventario completo de todos los certificados emitidos para los dominios monitoreados, agrupados por emisor, con estado de validez y métricas de fortaleza de clave.
• Análisis de diversidad de AC: Informe sobre cuántas AC diferentes emiten certificados para la organización, identificando oportunidades de consolidación y puntos únicos de falla.
• Evidencia de cumplimiento: Para organizaciones sujetas a PCI-DSS, SOC 2 o marcos similares, los registros de monitoreo CT proporcionan evidencia de la gestión del ciclo de vida de los certificados y las capacidades de detección de emisiones no autorizadas.

Conceptos Clave

Término	Definición
Transparencia de Certificados (CT)	Un marco abierto (RFC 6962) que obliga a las Autoridades de Certificación a registrar todos los certificados emitidos en logs de solo anexión auditables públicamente, permitiendo a los propietarios de dominios detectar emisiones no autorizadas
Signed Certificate Timestamp (SCT)	Una promesa de un log CT de que un certificado se incluirá dentro del Retardo Máximo de Fusión (típicamente 24 horas); los navegadores requieren SCT de múltiples logs antes de confiar en un certificado
Árbol Merkle	La estructura de datos criptográfica utilizada por los logs CT donde los nodos hoja son hashes de certificados y los nodos padre son hashes de sus hijos, permitiendo pruebas de consistencia e inclusión eficientes
Precertificado	Un certificado enviado a los logs CT antes de la emisión final, que contiene una extensión de veneno (OID 1.3.6.1.4.1.11129.2.4.3) que impide su uso para TLS pero reserva su lugar en el log
crt.sh	Un servicio web gratuito operado por Sectigo que agrega certificados de todos los logs CT principales en una base de datos PostgreSQL buscable, proporcionando acceso tanto web como por API
Toma de Control de Subdominio	Una vulnerabilidad donde el registro DNS de un subdominio apunta a un servicio dado de baja (proveedor de nube, CDN) que un atacante puede reclamar, hecho detectable a través de certificados CT caducados
Retardo Máximo de Fusión (MMD)	El tiempo máximo (típicamente 24 horas) que un log CT tiene para incorporar un certificado enviado en su árbol Merkle después de devolver un SCT
Registro CAA	Registro de Autorización de Autoridad de Certificación DNS que especifica qué AC tienen permitido emitir certificados para un dominio; el monitoreo CT detecta violaciones de la política CAA

Herramientas y Sistemas

• crt.sh: Agregador principal de logs CT que proporciona acceso a la API JSON en https://crt.sh/?q=<consulta>&output=json con soporte para consultas comodín, filtrado de identidad y recuperación de detalles de certificados
• ct-woodpecker: Herramienta de código abierto para monitoreo de logs CT de Let's Encrypt que se integra con Prometheus y Grafana para el monitoreo operativo de la salud y consistencia del log
• certspotter: Monitor de logs CT de SSLMate que observa certificados recién emitidos y envía notificaciones; disponible como servicio alojado o herramienta auto-alojada
• Google Argon / Xenon / Icarus: Logs CT operados por Google que se encuentran entre los más utilizados, consultables a través de la API RFC 6962 en sus respectivas URL de log
• OpenSSL: Herramienta de línea de comandos para analizar detalles de certificados, verificar cadenas y extraer listas SAN de certificados recuperados a través del monitoreo CT

Escenarios Comunes

Escenario: Detección de Emisión No Autorizada de Certificados para una Empresa de Servicios Financieros

Contexto: Un banco monitorea su dominio principal (banco.ejemplo.com) y descubre a través de los logs CT que una Autoridad de Certificación que nunca han utilizado ha emitido un certificado que cubre secure-login.banco.ejemplo.com, un subdominio que no existe en su DNS.

Enfoque:

1. El agente de monitoreo CT detecta un nuevo certificado de "FreeSSL CA" para secure-login.banco.ejemplo.com en los resultados de crt.sh, que no está en la lista de AC autorizadas (DigiCert, Sectigo).
2. Se activa una alerta como AC no autorizada + nuevo subdominio, escalando al equipo de seguridad dentro de los 15 minutos posteriores a la entrada en el log CT.
3. Investigue el certificado: extraiga la clave pública, verifique si el dominio se validó mediante un desafío HTTP-01 o DNS-01, consulte WHOIS para la organización emisora.
4. La consulta DNS de secure-login.banco.ejemplo.com revela que se resuelve a una dirección IP en un proveedor de alojamiento no utilizado por el banco, lo que confirma que se trata de una infraestructura de atacante.
5. Inicie la respuesta a incidentes: solicite la revocación del certificado a FreeSSL CA, presente un informe de abuso de dominio, agregue la IP a listas de bloqueo y notifique al equipo anti-phishing.
6. Implemente registros CAA DNS (banco.ejemplo.com. CAA 0 issue "digicert.com") para evitar que AC no autorizadas emitan certificados futuros.

Errores comunes:

• No monitorear patrones comodín (%.banco.ejemplo.com) y perder certificados para subdominios.
• Ignorar los precertificados que aparecen en los logs CT antes de que se emita el certificado real, perdiendo la ventaja de la advertencia temprana.
• No verificar que los registros CAA estén configurados correctamente en todos los dominios después de un incidente.
• Generar demasiadas alertas sobre renovaciones legítimas de certificados porque la base de datos de línea base no se actualizó después de cambios autorizados.

Escenario: Mapeo de Superficie de Ataque Mediante el Descubrimiento de Subdominios a Través de Logs CT

Contexto: Un probador de penetración utiliza los logs CT como la primera fase del reconocimiento externo para mapear los servicios orientados a Internet de la organización objetivo antes del escaneo activo.

Enfoque:

1. Consulte crt.sh para %.objetivo.com y todos los dominios de filiales conocidos, recopilando 2400 certificados únicos que abarcan 8 años.
2. Extraiga 347 subdominios únicos de los campos SAN de todos los certificados, incluidos los caducados.
3. Resuelva mediante DNS los 347 subdominios, encontrando 189 actualmente activos con registros A/AAAA.
4. Identifique 12 subdominios que apuntan a servicios en la nube dados de baja (CNAME a buckets S3, endpoints de Azure) que son candidatos para la toma de control de subdominios.
5. Descubra staging-api.objetivo.com y dev-portal.objetivo.com que no están en el alcance documentado del objetivo, pero son accesibles y ejecutan versiones de software más antiguas.
6. Presente los hallazgos a la organización objetivo, mostrando la brecha entre su inventario de activos conocido y la superficie de ataque derivada de CT.

Errores comunes:

• Asumir que todos los subdominios descubiertos por CT están dentro del alcance sin confirmarlo con el propietario del activo.
• No verificar las respuestas DNS comodín que hacen que parezca que los subdominios existen cuando se resuelven a un comodín.
• Confiar únicamente en los datos CT sin hacer referencias cruzadas con bases de datos DNS pasivas para una cobertura completa.

Formato de Salida

## Informe de Monitoreo de Logs CT

**Dominio**: ejemplo.com
**Período de Monitoreo**: 2026-03-01 a 2026-03-19
**Total de Certificados Rastreados**: 142
**Nuevos Certificados Detectados**: 7
**Alertas Generadas**: 2

### Alerta: Emisión por AC No Autorizada
- **Gravedad**: Crítica
- **CN del Certificado**: secure-login.ejemplo.com
- **SANs**: secure-login.ejemplo.com, ...