Introducción: Por Qué Necesitas un Laboratorio de Seguridad

En este post muestro cómo construir un laboratorio de seguridad completo que integra herramientas de pentesting con un stack empresarial de Microsoft, todo virtualizado en Hyper-V.

Este laboratorio te permite simular ataques reales, probar defensas empresariales, y entender cómo funcionan las herramientas de seguridad modernas en un entorno que replica una infraestructura corporativa real.

Arquitectura General del Laboratorio

El Concepto Principal

El laboratorio está diseñado con tres principios fundamentales:

  1. Segregación de red para aislar el tráfico ofensivo del corporativo
  2. Integración con servicios cloud de Azure para aprovechar capacidades empresariales de detección y respuesta
  3. Flexibilidad para escenarios de Red Team y Blue Team, permitiendo tanto ataques como defensas

La arquitectura se basa en Microsoft Hyper-V como hipervisor principal, ejecutándose sobre un host físico que gestiona toda la infraestructura virtualizada. Desde ahí se despliegan múltiples máquinas virtuales organizadas en distintos segmentos de red, cada uno con un propósito específico.

Arquitectura general del laboratorioUn host Hyper-V con pfSense y tres segmentos: VNET00 de pentesting, VNET01 corporativo y VNET02 de administración. Los servicios de nube (Entra ID, Intune, Defender XDR, Sentinel, Copilot for Security y Cloudflare) se alcanzan por Internet.InternetHost Hyper-VpfSenseFirewall y reglas entre segmentosWANVNET00LAN · 10.10.0.0/25VNET01OPT3 · 10.10.10.0/25VNET02OPT4 · 10.10.20.0/25Kali LinuxCaldera · BloodHoundLLMs VMOllama · Open WebUIDomain ControllerAD · Entra ConnectWindows 11MDE · IntuneUbuntu DesktopMDE · IntuneGuacamoleRDP/SSH webÚnico punto deentrada remotaServicios en la nubeEntra IDSSO · Acceso condicionalIntuneMDM / MAMDefender XDREndpoint · IdentitySentinelSIEM · SOARCopilot for SecurityAnálisis asistidoCloudflareTunnel + AccessHTTPSPublicado mediante Cloudflare Tunnel, sin abrir puertos hacia Internet
Arquitectura del laboratorio: un host Hyper-V con pfSense como único punto de paso entre tres segmentos, y los servicios de nube alcanzados por Internet.

Componentes Clave de la Infraestructura

1. El Núcleo: Microsoft Hyper-V

El hipervisor corre sobre un Minisforum UM890 Pro, con hostname Servidor(Ficticio). Sobre él conviven tanto el laboratorio de seguridad como el resto del stack de servicios del homelab.

Hyper-V provee la flexibilidad de crear switches virtuales, permitiendo simular una red empresarial completa con múltiples segmentos.

2. La Primera Línea de Defensa: pfSense Firewall

Entre el hipervisor y las redes internas corre pfSense como firewall principal, con las últimas correcciones de seguridad aplicadas (incluyendo el parche para la CVE-2026-58085 de WireGuard). Esta solución open source ofrece:

  • Control granular del tráfico entre subredes
  • Capacidades de NAT y port forwarding
  • Logs detallados para análisis forense
  • Reglas de firewall que simulan políticas empresariales reales

pfSense actúa como el punto de control central entre los dos segmentos internos del laboratorio. Verificando directamente por consola (opción de “Assign Interfaces” del menú de pfSense), la asignación real es:

Interfaz Hyper-VInterfaz pfSenseRedGateway
VNET00LAN10.10.0.0/2510.10.0.1
VNET01OPT310.10.10.0/2510.10.10.1
VNET02OPT410.10.20.0/2510.10.20.1

Y así se ve el mapeo interfaz por interfaz, con el dispositivo hn que usa cada una:

1
2
3
VNET00 (LAN)  -> HN1 -> V4: 10.10.0.1/25
VNET01 (OPT3) -> HN2 -> V4: 10.10.10.1/25
VNET02 (OPT4) -> HN3 -> V4: 10.10.20.1/25

Segmentación de Red: Topología Real

A diferencia de lo que documenté originalmente, la topología confirmada directamente por consola de pfSense muestra solo tres interfaces internas activas en el host. Las dos que forman el laboratorio de seguridad son:

VNET00: El Arsenal de Pentesting (10.10.0.0/25)

Este segmento (VNET00, interfaz LAN en pfSense) aloja las herramientas ofensivas del laboratorio. Aquí corre:

Kali Linux

  • La distribución de pentesting por excelencia, preconfigurada con cientos de herramientas de seguridad
  • Ideal para pruebas de penetración, análisis de vulnerabilidades y explotación

Caldera + BloodHound (corriendo en la propia VM de Kali, no como máquinas separadas)

  • Caldera: plataforma de emulación de adversarios desarrollada por MITRE, permite automatizar cadenas de ataque complejas y simular APTs mapeadas al framework ATT&CK
  • BloodHound: herramienta open-source para mapear y visualizar rutas de ataque en Active Directory mediante teoría de grafos (Neo4j); SharpHound recolecta relaciones de privilegios (usuarios, grupos, ACLs, sesiones) para descubrir caminos hacia cuentas sensibles como Domain Admin

LLMs VM

Lo que en la versión original era solo una mención suelta a Open WebUI hoy es una VM completa dedicada a IA, conectada lógicamente a Kali para pruebas de seguridad sobre modelos de lenguaje:

  • Ollama corriendo como servicio systemd nativo
  • Open WebUI como interfaz
  • Hermes Agent (Nous Research), publicado externamente vía Cloudflare Tunnel
  • Un proxy reverso que registra cada request, response y cadena de razonamiento como NDJSON, alimentando una tabla personalizada en Log Analytics
  • Una regla de detección en Sentinel para prompt injection / jailbreak (en inglés y español, mapeada a MITRE), que ya ha disparado exitosamente en pruebas reales
  • Uso planeado con PyRIT y Promptfoo para red-teaming de IA contra el propio endpoint
Flujo de red-teaming de IA generativaLos clientes del modelo pasan por un proxy reverso en la LLMs VM, que registra cada request, response y cadena de razonamiento como NDJSON. Los registros llegan a una tabla personalizada en Log Analytics, donde una regla de Sentinel detecta prompt injection y jailbreak.Clientes del modeloOpen WebUIHermes AgentPyRIT · PromptfooplaneadoLLMs VM · VNET00Proxy reversoregistra request, responsey cadena de razonamientoOllamamodelo localLog Analyticstabla personalizadaSentinel: regla de detecciónprompt injection / jailbreakEN y ES · mapeada a MITREIncidente en Sentinelya disparada en pruebas realesNDJSONPublicado mediante Cloudflare Tunnel
Flujo de la LLMs VM: cada request, response y cadena de razonamiento pasa por el proxy, se guarda como NDJSON en Log Analytics y alimenta la regla de Sentinel.

VNET01: El Entorno Corporativo (10.10.10.0/25)

Este segmento (VNET01, interfaz OPT3 en pfSense) simula una red empresarial típica con los componentes que encontrarías en un entorno de producción:

Active Directory Domain Controller

  • Corazón de la infraestructura de identidad
  • Defender for Identity monitoreando el tráfico de autenticación
  • Defender for Server
  • Entra Connect para sincronización híbrida con el tenant cloud

Windows 11

  • Unida al dominio
  • Defender for Endpoint para detección de amenazas
  • Microsoft Intune para gestión (MDM/MAM)

Ubuntu Desktop 26.04 (VM-Linux), la incorporación más reciente al laboratorio

  • Enrolada en Microsoft Intune
  • Onboarding a Defender for Endpoint confirmado y saludable

VNET02: El segmento que faltaba, administración (10.10.20.0/25)

Una pieza que no existía en el diseño original: un segmento dedicado (VNET02, interfaz OPT4 en pfSense) para administración, con una VM de Apache Guacamole que da acceso remoto por navegador (RDP/SSH) a Kali, al Domain Controller y a Windows 11, sin necesidad de exponer esos puertos directamente. El acceso externo a Guacamole va detrás de Cloudflare Tunnel, con Cloudflare Access exigiendo SSO contra Entra ID antes de llegar siquiera a la pantalla de login.

Flujo de acceso remoto seguroEl administrador entra por Cloudflare Access, que exige SSO contra Entra ID, a través de Cloudflare Tunnel hasta Guacamole en VNET02, y desde ahí abre RDP o SSH hacia Kali, el Domain Controller y Windows 11.Entra IDautenticación SSOAdministradornavegador webCloudflare AccessSSO antes del loginCloudflare Tunnelconexión salienteGuacamoleVNET02 · administraciónSSOHTTPS1234RDP / SSHKali LinuxVNET00Domain ControllerVNET01Windows 11VNET015Ningún puerto se expone a Internet:la conexión siempre sale desde el túnel.
Acceso remoto: Cloudflare Access exige SSO contra Entra ID y el túnel entrega la sesión a Guacamole, que abre RDP o SSH hacia las VMs.

Integración con el Stack de Seguridad de Microsoft

La Nube como Centro de Comando

Una de las características más poderosas de este laboratorio es su integración con los servicios de seguridad de Microsoft. Esto permite probar tecnologías empresariales reales y entender cómo funcionan las arquitecturas híbridas modernas.

Flujo de telemetría y detecciónLos endpoints del segmento VNET01 envían señales a Defender for Endpoint e Identity dentro de Defender XDR, que escala incidentes a Sentinel. La LLMs VM envía registros NDJSON a Log Analytics. Sentinel entrega contexto a Copilot for Security.Kali + CalderaVNET00 · ataque simuladoataques simuladosEndpoints · VNET01Windows 11agente MDEUbuntu Desktopagente MDEDomain Controllersensor MDIMicrosoft Defender XDRDefender for EndpointWindows y LinuxDefender for Identitytráfico de autenticaciónDefender for Cloud AppsShadow IT · DLPMicrosoft SentinelIncidentes de Defender XDRescalados a SentinelReglas de detecciónanalytics y machine learningLog Analyticsincluye tablas propiasincidentesLLMs VMVNET00 · proxy NDJSONregistros NDJSONCopilot for Securitycontexto y remediación
Flujo de detección: los endpoints reportan a Defender XDR, que escala incidentes a Sentinel, y la LLMs VM aporta sus propios registros a Log Analytics.

Entra ID

  • Gestión de identidades cloud
  • Single sign-on para aplicaciones SaaS
  • Políticas de acceso condicional basadas en riesgo

Microsoft Defender XDR

  • Plataforma unificada de detección y respuesta
  • Correlación de alertas entre endpoints, identidades, email y aplicaciones cloud
  • Investigación automatizada de incidentes
  • Monitoreo especializado de Active Directory: detecta ataques como Pass-the-Hash, Pass-the-Ticket, Overpass-the-Hash, Golden Ticket y movimientos laterales anómalos
  • Recibe señales tanto de los endpoints Windows como de la nueva Ubuntu Desktop

Defender for Cloud Apps

  • Visibilidad y control sobre aplicaciones SaaS
  • Detección de Shadow IT
  • Políticas de prevención de pérdida de datos (DLP)

Microsoft Sentinel

  • SIEM y SOAR en la nube
  • Correlación de eventos de múltiples fuentes
  • Playbooks automatizados para respuesta a incidentes
  • Análisis con machine learning para detección de anomalías
  • Recibe los incidentes escalados desde Defender XDR

Copilot for Security

  • Asistente de IA para análisis de amenazas
  • Generación automática de informes de incidentes
  • Recomendaciones basadas en inteligencia de amenazas global

Casos de Uso Prácticos

Escenario 1: Simulación de Ransomware

Desde VNET00 (pentesting), Kali Linux lanza un ataque de ransomware simulado contra los endpoints en VNET01. Se observa cómo:

  1. Defender for Endpoint detecta y bloquea el comportamiento malicioso
  2. Sentinel correlaciona los eventos y genera un incidente
  3. Copilot for Security proporciona contexto y recomendaciones de remediación

Escenario 2: Movimiento Lateral con Caldera

Caldera emula las técnicas de un APT intentando moverse lateralmente en la red corporativa:

  1. Compromiso inicial en un endpoint
  2. Intento de escalar privilegios y moverse hacia el Domain Controller
  3. Defender for Identity detecta los patrones anómalos de autenticación
  4. Defender XDR correlaciona todas las alertas en una única línea temporal del ataque

Escenario 3: Exfiltración de Datos

Simulación de un intento de exfiltración de datos sensibles:

  1. Creación de archivos con información falsa pero marcada como confidencial
  2. Intento de subirlos a servicios cloud no autorizados
  3. Defender for Cloud Apps detecta y bloquea la transferencia
  4. Las políticas de DLP generan alertas y evidencia forense

Escenario 4: Red-teaming de IA generativa

Un caso de uso nuevo que no existía en la versión original del lab: usar el proxy de la LLMs VM para probar resistencia a prompt injection y jailbreaks contra el propio modelo local, con las detecciones correlacionadas en Sentinel igual que cualquier otro evento de seguridad del laboratorio.

Guía de Implementación Paso a Paso

Fase 1: Preparación del Host

Requisitos de hardware (los que uso en producción, no el mínimo):

  • 96GB RAM
  • Procesador con virtualización habilitada (AMD-V o Intel VT-x)
  • Almacenamiento SSD/NVMe, con un disco externo dedicado a backups en frío
  • Conectividad de red gestionada con VLANs a nivel de switch

Instalación de Hyper-V:

  1. Habilitar el rol de Hyper-V
  2. Crear switches virtuales para cada segmento
  3. Configurar la red de management

Fase 2: Despliegue del Firewall

Instalación de pfSense:

  1. Descargar la ISO de pfSense (versión 2.9.0 o superior)
  2. Crear la VM con recursos mínimos (2GB RAM, 20GB disco)
  3. Asignar interfaces para WAN y cada segmento interno
  4. Configurar reglas iniciales de firewall

Configuración de segmentos:

  1. Crear el segmento VNET00 de pentesting (10.10.0.0/25)
  2. Crear el segmento VNET01 para la red corporativa (10.10.10.0/25)
  3. Crear el segmento VNET02 dedicado a administración y acceso remoto (10.10.20.0/25)
  4. Configurar DHCP para cada segmento
  5. Implementar reglas de aislamiento entre ellos

Fase 3: Despliegue del Entorno de Pentesting

Kali Linux:

  1. Descargar la última versión de Kali
  2. Asignar recursos (4GB RAM, 40GB disco como mínimo)
  3. Configurar IP estática dentro del segmento VNET00
  4. Actualizar todas las herramientas

Caldera:

  1. Clonar el repositorio de GitHub
  2. Instalar directamente en Kali
  3. Configurar agentes para Windows
  4. Importar adversarios del framework ATT&CK

BloodHound:

  1. Preparar Neo4j (puertos 7474/7687, cambiar contraseña por defecto) e instalar BloodHound CE
  2. En un Windows unido al dominio, ejecutar SharpHound (EXE o PowerShell) para la recolección
  3. Importar el ZIP resultante en la GUI, ejecutar consultas integradas o Cypher, exportar rutas críticas

LLMs VM:

  1. Instalar Ollama como servicio systemd
  2. Desplegar Open WebUI
  3. Configurar el proxy reverso de logging si quieres correlación con Sentinel
  4. Conectar Hermes Agent u otro agente contra el endpoint local de Ollama

Fase 4: Construcción del Dominio Active Directory

Domain Controller:

  1. Instalar Windows Server
  2. Promover a Domain Controller
  3. Configurar DNS y DHCP
  4. Crear estructura de OUs y GPOs

Endpoints gestionados:

  1. Desplegar Windows 11
  2. Desplegar una Ubuntu Desktop LTS con entorno GNOME si quieres cobertura Linux
  3. Unir ambos al dominio o inscribirlos en Intune según corresponda
  4. Crear usuarios con distintos niveles de privilegio

Fase 5: Integración con Microsoft Secure

Configuración de Entra Connect:

  1. Instalar en el DC o en un servidor dedicado
  2. Configurar sincronización de hash de contraseñas
  3. Habilitar writeback de dispositivos si aplica

Onboarding a Microsoft Defender:

  1. Registrar los dispositivos Windows en Defender for Endpoint
  2. Para Linux, descargar el paquete de onboarding desde el portal y ejecutar el script oficial MicrosoftDefenderATPOnboardingLinuxServer.py, que genera el mdatp_onboard.json en el formato correcto
  3. Configurar Defender for Identity en el DC
  4. Habilitar la integración con Sentinel

Configuración de Sentinel:

  1. Crear el workspace de Log Analytics
  2. Conectar las fuentes de datos (Windows Security Events, Defender, tablas personalizadas si tienes telemetría propia)
  3. Importar reglas de detección de la comunidad
  4. Configurar playbooks de respuesta

Fase 6: Acceso remoto seguro

Guacamole en el segmento VNET02:

  1. Desplegar una VM dedicada en el nuevo segmento de administración
  2. Configurar las conexiones RDP/SSH hacia Kali, el DC y Windows 11
  3. Publicar el acceso externo vía túnel zero-trust, nunca abriendo puertos directamente
  4. Exigir SSO corporativo antes de llegar a la pantalla de login de Guacamole

Mejores Prácticas y Consideraciones de Seguridad

Aislamiento y Segmentación

  • Nunca conectes el segmento de pentesting directamente a tu red de producción
  • Utiliza reglas estrictas en el firewall para controlar el flujo de tráfico entre segmentos
  • Implementa logging exhaustivo en todos los puntos de la red
  • El acceso remoto a cualquier parte del laboratorio debe pasar por un punto de entrada único, autenticado y sin puertos expuestos directamente a internet

Gestión de Recursos

  • Implementa snapshots antes de cada sesión de testing
  • Documenta todas las configuraciones y cambios, incluida la topología real de red (verificarla contra la consola del firewall, no solo contra lo que “debería” ser)

Cumplimiento y Legalidad

  • Asegúrate de tener licencias válidas para todo el software
  • Nunca utilices herramientas de pentesting contra sistemas que no te pertenecen
  • Implementa políticas de retención de logs según tus necesidades

Expansiones Futuras

Una vez que el laboratorio base esté funcionando, algunas expansiones que estoy evaluando:

  • Migración de las VMs del laboratorio de seguridad de Hyper-V a un nodo Proxmox dedicado, con un bridge VLAN-aware
  • AdaptixC2 como una VM de comando y control separada de Kali
  • Segmento DMZ con aplicaciones web vulnerables (DVWA, WebGoat)
  • Memoria compartida entre agentes de IA (Qdrant o pgvector) para correlacionar hallazgos entre la LLMs VM y el resto del stack de automatización

Recursos y Herramientas Adicionales

Herramientas recomendadas:

  • Mimikatz: para testing de credenciales
  • PowerShell Empire: framework de post-explotación
  • Atomic Red Team: biblioteca de pruebas atómicas

Recursos de aprendizaje:

  • Microsoft Learn para configuración de servicios
  • MITRE ATT&CK Framework para técnicas de ataque
  • SANS Reading Room para papers de seguridad
  • GitHub Security Lab para vulnerabilidades y exploits

Conclusión

Este laboratorio proporciona un entorno completo para practicar tanto técnicas ofensivas como defensivas en un contexto empresarial realista. La integración con el stack de seguridad de Microsoft permite experimentar con tecnologías que se encuentran en entornos de producción reales, mientras que la segmentación de red garantiza que los experimentos permanezcan controlados.

La arquitectura documentada aquí no es estática: entre la primera versión de este post y esta actualización cambió la topología real de red (confirmada directamente por consola de pfSense, no asumida), se retiró un endpoint que ya no aportaba valor, se sumó cobertura Linux al dominio, y el laboratorio ganó una VM de IA que ahora es, en sí misma, superficie de pruebas de seguridad. Vale la pena revisar periódicamente que la documentación siga reflejando lo que realmente corre, y no lo que corría cuando se escribió.

Próximos Pasos

  1. Comienza con la configuración básica y ve expandiendo gradualmente
  2. Documenta tus experimentos y hallazgos, y revisa esa documentación contra la realidad de vez en cuando
  3. Comparte tu conocimiento con la comunidad
  4. Mantente actualizado con las últimas amenazas y defensas

Nota legal: este laboratorio es únicamente para fines educativos y de investigación. Nunca utilices estas herramientas o técnicas contra sistemas que no te pertenezcan o sin autorización explícita. El mal uso de estas herramientas puede tener consecuencias legales graves.