Laboratorio de Escaneo de Vulnerabilidades con Nessus — Azure

Ciclo completo de gestión de vulnerabilidades: escanear, encontrar, corregir, verificar — ejecutado contra mi entorno de laboratorio de Azure Active Directory en vivo usando un escáner Nessus dedicado desplegado con Terraform.

Qué Demuestra Este Laboratorio

Desplegué una máquina virtual escáner Ubuntu 24.04 dedicada en mi entorno de laboratorio de Azure AD existente, ejecuté un escaneo de línea base no autenticado y un escaneo con credenciales contra un controlador de dominio, un servidor de archivos y un cliente unido al dominio, analicé los resultados, remedié un hallazgo de gravedad Alta (CVE-2013-3900) mediante el endurecimiento del registro con PowerShell, y verifiqué la corrección con un nuevo escaneo. Este es el flujo de trabajo completo que los programas empresariales de gestión de vulnerabilidades ejecutan continuamente.

Ese salto en los hallazgos es el argumento completo para el escaneo con credenciales: el hallazgo de gravedad Alta CVE-2013-3900 que remedié en este laboratorio es una comprobación local que el escaneo sin autenticar no pudo ver en absoluto.

Arquitectura

Aparato escáner NESSUS01 dedicado en Subnet-Servidores con rutas de escaneo con credenciales a los tres objetivos Windows. El plano de gestión solo se puede alcanzar mediante túnel SSH desde la estación de trabajo de administración — el puerto 8834 nunca se expone públicamente.

El escáner se une a la VNet de laboratorio existente de mi serie de Automatización de Infraestructura Azure Empresarial, desplegado como una configuración independiente de Terraform con su propio estado remoto.

Decisiones de diseño que tomé:

• Máquina virtual escáner dedicada en lugar de instalar Nessus en un objetivo. Los escáneres empresariales se colocan como dispositivos de red independientes con línea de visión despejada hacia sus objetivos: escanear desde un host que también es un objetivo contamina los resultados.
• Fuentes de datos de Terraform contra infraestructura existente. La configuración del escáner referencia la VNet y subred existentes mediante bloques data en lugar de duplicarlos, con el estado aislado en su propia clave nessus-scanner.tfstate para que el escáner pueda crearse y destruirse sin tocar el estado central del laboratorio.
• La interfaz web de Nessus (puerto 8834) nunca se expone públicamente. El NSG solo permite SSH (22) desde mi IP de administración; accedo a la interfaz a través de un túnel SSH (ssh -L 8834:localhost:8834). La exposición del plano de gestión es la forma número uno en que los dispositivos escáner se ven comprometidos.
• Autenticación solo por clave SSH — par de claves ed25519, sin autenticación por contraseña en el escáner.

Fase 0 — Revisión de Seguridad Previa al Vuelo (Practica lo que Escaneas)

Antes de desplegar cualquier cosa, audité las reglas NSG existentes — y encontré exactamente el tipo de configuración incorrecta que este laboratorio existe para detectar: la regla RDP permitía origen * (cualquier IP en internet).

Auditoría previa al vuelo: la consulta az network nsg list expone Allow-RDP-3389 abierta a cualquier origen (*).

Lo ajusté a mi IP pública actual antes de proceder:

az network nsg rule update -g RG-FileServerLab --nsg-name NSG-RDP \
  -n Allow-RDP-3389 --source-address-prefixes $(curl -s ifconfig.me)

La misma regla después de la remediación: origen restringido a una sola IP de administración.

Encontrar y corregir una exposición en tu propio entorno antes de apuntar un escáner hacia ella es el cambio de mentalidad de "ejecutar una herramienta" a "hacer seguridad".

Fase 1 — Desplegar el Escáner con Terraform

Cinco recursos — IP pública, NSG, NIC, asociación NSG y la máquina virtual Ubuntu — desplegados en menos de dos minutos:

terraform apply: 5 añadidos, 0 cambiados, 0 destruidos. Las salidas incluyen el comando SSH listo para usar.

Luego me conecté por SSH y realicé la instalación sin interfaz gráfica de Nessus Essentials 10.12.1:

Primera conexión SSH a NESSUS01 con autenticación basada en clave — Ubuntu 24.04 activo en 10.0.1.8, listo para la instalación sin interfaz de Nessus.

Fase 2 — Escaneo de Línea Base Sin Autenticar

Primer escaneo: sin credenciales — esto es lo que un atacante en el segmento de red ve.

Escaneo de Red Básico dirigido a los tres hosts: 10.0.1.5, 10.0.1.6, 10.0.1.7.

Resultados de línea base: 35 hallazgos en 3 hosts, columna Auth mostrando Fail — Nessus no pudo iniciar sesión, por lo que cada resultado proviene solo de observación externa.

Fase 3 — Escaneo con Credenciales

El escaneo con credenciales es el estándar empresarial para la gestión interna de vulnerabilidades. Preparé los objetivos Windows habilitando el servicio de Registro Remoto y abriendo los grupos de reglas de firewall requeridos en el perfil de Dominio:

Set-Service -Name RemoteRegistry -StartupType Automatic
Start-Service RemoteRegistry
Set-NetFirewallRule -DisplayGroup "File and Printer Sharing" -Enabled True -Profile Domain
Set-NetFirewallRule -DisplayGroup "Windows Management Instrumentation (WMI)" -Enabled True -Profile Domain

Preparación del objetivo en FS01 — RemoteRegistry ejecutándose con inicio Automático, reglas WMI y de Compartición de Archivos e Impresoras habilitadas para el perfil de Dominio.

Configuré credenciales de Windows en el escaneo con las opciones de seguridad que requieren las empresas: nunca enviar credenciales en texto claro, y solo NTLMv2.

Configuración de credenciales de Windows — dominio LAB, NTLMv1 deshabilitado, transmisión de credenciales en texto claro deshabilitada, inicio automático de Registro Remoto habilitado para el escaneo.

Resultados con credenciales: 64 hallazgos — un aumento del 83% sobre la línea base sin autenticar contra los mismos tres hosts.

Hallazgos ordenados por gravedad, con la comprobación local WinVerifyTrust de gravedad Alta ahora visible — un hallazgo que el escaneo sin autenticar no tenía forma de detectar.

Fase 4 — Analizar el Hallazgo Alto: CVE-2013-3900

El plugin #166555 marcó Validación de Firma WinVerifyTrust (CVE-2013-3900) tanto en DC01 como en FS01 — puntuación base CVSS v3 8.8, Tenable VPR 9.0. El valor de registro EnableCertPaddingCheck faltaba, dejando a los hosts en un estado donde un atacante podría añadir contenido malicioso a un ejecutable firmado sin invalidar su firma Authenticode.

Análisis completo del hallazgo: la salida del plugin confirma que el valor de registro está ausente en 10.0.1.5 y 10.0.1.6, con la ruta exacta de remediación documentada en la sección Solución.

Por qué este hallazgo es importante: es una vulnerabilidad de mitigación por configuración — no existe parche porque Microsoft hizo la corrección optativa. Se distribuyó faltante en imágenes nuevas de Windows Server 2025 en 2026, trece años después de la publicación del CVE. Esta es exactamente la clase de problema que solo el escaneo con credenciales y la gestión de configuración detectan.

Fase 5 — Remediar y Verificar

Apliqué la corrección en los hosts afectados según la sección Solución del plugin — estableciendo EnableCertPaddingCheck = 1 en ambas rutas de registro de 64 bits y Wow6432Node — luego verifiqué ambas claves antes de volver a escanear:

New-Item -Path "HKLM:\Software\Microsoft\Cryptography\Wintrust\Config" -Force | Out-Null
Set-ItemProperty -Path "HKLM:\Software\Microsoft\Cryptography\Wintrust\Config" `
  -Name "EnableCertPaddingCheck" -Value "1" -Type String

New-Item -Path "HKLM:\Software\Wow6432Node\Microsoft\Cryptography\Wintrust\Config" -Force | Out-Null
Set-ItemProperty -Path "HKLM:\Software\Wow6432Node\Microsoft\Cryptography\Wintrust\Config" `
  -Name "EnableCertPaddingCheck" -Value "1" -Type String

Remediación aplicada y verificada con Get-ItemProperty — ambas rutas de registro ahora devuelven EnableCertPaddingCheck : 1.

Luego el paso que la mayoría omite — el nuevo escaneo de verificación. No cierras el ticket hasta que el escáner confirma que el hallazgo ha desaparecido:

Escaneo de verificación (Historial: 2): el hallazgo de gravedad Alta CVE-2013-3900 está resuelto. La gravedad más alta restante es Media.

Encontrar → analizar → corregir → verificar. Ciclo cerrado.

Habilidades Demostradas

Por Qué Esto Es Importante para el Trabajo

La gestión de vulnerabilidades es una función central en prácticamente todos los roles de operaciones de seguridad, seguridad en la nube y GRC. Este laboratorio cubre todo el trabajo — no solo ejecutar un escáner, sino diseñar su ubicación de forma segura, preparar los objetivos correctamente, distinguir la señal del ruido en los resultados, ejecutar una remediación y demostrar que funcionó. La comparación entre sin autenticar y con credenciales, y el nuevo escaneo de verificación, son las dos cosas que separan a los profesionales de los operadores de herramientas.

Informe de Evaluación

El entregable profesional completo — resumen ejecutivo, metodología, análisis detallado del hallazgo CVE-2013-3900, disposición de riesgo residual y recomendaciones priorizadas — está disponible como PDF:

Vulnerability-Assessment-Report.pdf

Nessus Essentials no incluye exportación de informes, por lo que este entregable fue creado de forma independiente a partir de los datos del escaneo — que es en sí misma la habilidad de elaboración de informes de evaluación que el nivel gratuito omite.

Laboratorios Relacionados

Este escáner se despliega en el entorno construido por mi serie de Automatización de Infraestructura Azure Empresarial:

• Laboratorio 1 — Infraestructura Terraform
• Laboratorio 2 — Active Directory
• Laboratorio 3 — Servidor de Archivos NTFS y RBAC
• Laboratorios 4–6 — RBAC de Azure

No se almacenan secretos en este repositorio — el escáner utiliza solo autenticación por clave SSH, y las credenciales de escaneo se ingresaron directamente en la consola de Nessus, nunca se confirmaron en el código.