Cómo montar un home network attack simulator para pymes y casa

Inicio » Windows » Cómo montar un home network attack simulator para pymes y casa

Montar un home network attack simulator en casa se ha convertido en uno de los proyectos más divertidos y potentes para aprender ciberseguridad en serio, tanto si estás empezando como si quieres algo que se parezca a lo que se hace en una pyme real. La idea es sencilla: levantas una red virtual aislada, pones una máquina atacante, varios sistemas de víctima, un servidor de logs o SIEM y empiezas a lanzar ataques controlados para entender qué ocurre por dentro y cómo defenderte.

En lugar de limitarte a dos máquinas sueltas en VirtualBox, el enfoque moderno pasa por recrear una miniempresa en laboratorio: puestos de trabajo Windows, un servidor con servicios internos, un SIEM tipo Splunk o Wazuh, quizá alguna red Wi‑Fi simulada y un atacante con Kali Linux. En este entorno puedes practicar desde un simple malware generado con msfvenom y Metasploit hasta escenarios más complejos alineados con CTEM (Continuous Threat Exposure Management), siempre sin riesgo para tu red doméstica o de producción.

Qué es un home network attack simulator y por qué merece la pena

Cuando hablamos de home network attack simulator nos referimos a un laboratorio en el que replicas de forma controlada una red doméstica o de pequeña empresa para lanzar ataques, generar telemetría y entrenar técnicas de defensa. No es solo “jugar con Kali”, sino montar un escenario completo donde hay víctimas, servicios reales, registros centralizados, alertas y un ciclo de ataque‑detección‑respuesta.

Este concepto bebe directamente de los ciber rangos y entornos de entrenamiento que utilizan gobiernos y grandes organizaciones, donde se simulan miles de webs y usuarios falsos en redes aisladas. En casa o en una pyme haces lo mismo pero en pequeño: varios segmentos de red, equipos de usuario, un atacante, un SIEM y, si quieres rizar el rizo, usuarios sintéticos que generen tráfico «legítimo» de fondo.

La gracia de este enfoque es que cada ataque se convierte en un caso práctico completo: cómo entra el atacante, qué deja en los logs de Windows y Sysmon, cómo lo ve Splunk o ELK, qué alertas saltan y qué debería hacer un analista blue team. Diseñar el entorno con mentalidad defensiva es lo que diferencia un laboratorio serio de un simple “campo de pruebas” para exploits.

Además, gracias a la virtualización actual puedes ejecutar todo en un único host con suficiente RAM, totalmente aislado de tu red física. Así puedes hacer un DoS interno, probar malware o errores de configuración sin miedo a tirar abajo tu router ni comprometer otros dispositivos de casa o de la oficina.

Requisitos de hardware y software para el laboratorio

Antes de crear máquinas virtuales como si no hubiera mañana, merece la pena revisar los recursos mínimos para que el entorno sea usable. Un simulador con varias VMs, SIEM y herramientas de ataque se come memoria y CPU; si te quedas corto, el host se arrastrará y las prácticas serán un suplicio.

Como referencia realista, 16 GB de RAM en el equipo físico es un buen punto de partida para tener, por ejemplo, un Kali, un Windows 10 víctima, un servidor de logs/SIEM y algún componente extra encendidos a la vez. Con menos memoria es posible, pero tendrás que ir apagando VMs y recortando recursos, lo que limita mucho la fluidez de los ejercicios. Si quieres medir el rendimiento de tu host, prueba Unigine Superposition.

En cuanto al hipervisor, las opciones más habituales son VMware Workstation y VirtualBox, ambos capaces de crear redes internas aisladas, snapshots y clonados rápidos. VMware suele ir algo mejor en rendimiento e integración, mientras que VirtualBox tiene la ventaja de ser gratuito y omnipresente en entornos formativos.

A nivel de software base para el simulador, lo mínimo interesante sería: una ISO de Kali Linux u otra distro de pentesting para el atacante, una ISO de Windows 10 para los puestos de trabajo, Splunk Free o un SIEM alternativo para concentrar logs, y Sysmon con un fichero de configuración XML bien curado como los de proyectos tipo Sysmon Modular.

Durante la fase de montaje necesitarás conexión a Internet para descargar ISOs, actualizaciones y herramientas adicionales. Una vez tengas todo instalado y parcheado, lo sensato es aislar totalmente el laboratorio para que ningún payload, malware de prueba o tráfico extraño salga a tu red real ni llegue a Internet.

Diseño de la topología de red pensando en una pyme

El salto de un simple laboratorio doméstico a un simulador orientado a pymes está en cómo diseñas la red virtual. No basta con poner Kali y Windows en el mismo switch virtual; necesitas roles y segmentos que se parezcan a una red de producción, con zonas diferenciadas.

Un esquema sencillo pero creíble puede tener al menos tres áreas: una red de usuarios (estaciones Windows 10), un segmento de servicios internos (servidor de aplicaciones, servidor de logs o SIEM, quizá un controlador de dominio) y la red desde la que ataca Kali, que puede representar Internet o un equipo ya comprometido dentro de la organización.

Estas zonas se suelen montar con redes internas del hipervisor, routers virtuales o NATs que te permitan controlar qué segmentos se ven entre sí y cómo circula el tráfico. La idea es replicar una miniinfraestructura con algo de profundidad: no todo está en la misma VLAN ni todo es accesible directamente desde el atacante.

En esta topología, Kali Linux actúa como adversario externo o insider, la máquina Windows 10 representa un empleado típico y el servidor con Splunk o similar hace de sistema central de monitorización. Todo lo que ocurra en la red —procesos, conexiones, cambios relevantes— debería acabar reflejado en los logs que consume el SIEM.

De este modo, cada ataque que lances se deja ver desde la consola de defensa y puedes reconstruir la línea temporal: cómo se ejecuta el payload, qué procesos arranca, a qué IP y puerto se conecta, cómo se mantiene la persistencia, etc. Ese es el tipo de visibilidad que luego se busca en redes reales de pymes.

Creación y configuración de las máquinas virtuales

Con el diseño de red claro, toca levantar las VMs que formarán tu miniempresa. Lo habitual es empezar por Kali (atacante) y uno o varios Windows 10 (usuarios), y luego añadir el servidor que alojará Splunk u otras piezas defensivas.

Para Kali Linux, el proceso es directo: descargas la ISO oficial, creas una VM nueva en VMware o VirtualBox, le asignas algunos núcleos y RAM suficiente, y completas la instalación como en cualquier otra distro. Nada más terminar, conviene ejecutar un buen update & upgrade para tener al día Metasploit, msfvenom y el resto de herramientas de pentesting.

La VM Windows 10 se crea de forma similar usando la ISO de Microsoft, con algo más de RAM si vas a instalar Splunk ahí mismo o piensas ejecutar aplicaciones de oficina, navegadores, clientes de correo, etc. Durante la instalación, asegúrate de que la interfaz de red se conecta al segmento correcto del laboratorio y no sale a Internet si no lo necesitas.

Es una gran idea crear snapshots en un estado “limpio”, justo después de actualizar el sistema y añadir las herramientas básicas. Así, cada vez que hagas una prueba agresiva (malware, ransomware simulado, cambios en el registro, etc.) puedes volver atrás con un clic y evitar reinstalaciones eternas.

Si tu hardware lo permite, puedes añadir VMs adicionales para enriquecer la simulación: un servidor Linux con servicios web internos, un servidor de correo, un controlador de dominio, o incluso una máquina específica para un stack ELK o para Wazuh si quieres explorar SIEM alternativos a Splunk. Si prefieres equipos compactos, considera plataformas con AMD Ryzen Embedded.

Monitorización de logs: Splunk como SIEM ligero

Para que el simulador tenga valor de verdad del lado del blue team, hace falta un sistema que centralice los eventos de todos los equipos. Splunk, incluso en su versión gratuita, encaja perfectamente como SIEM ligero de laboratorio y permite enseñar conceptos clave de monitorización y detección.

El despliegue más sencillo consiste en instalar Splunk en la propia VM Windows 10 o en un servidor dedicado dentro de la red de servicios internos. Tras la instalación, accedes a la interfaz web con la cuenta de administrador, creas los índices necesarios y configuras entradas de datos para recibir registros de seguridad, sistema, aplicaciones y, en especial, los eventos de Sysmon.

Desde Splunk puedes diseñar búsquedas específicas para localizar procesos sospechosos, conexiones salientes anómalas, ejecuciones desde rutas raras o cambios en el sistema que huelan a persistencia. A partir de estas búsquedas, podrás generar alertas programadas que se activen automáticamente cuando se detecten patrones de ataque.

Es importante encontrar un equilibrio en la cantidad de telemetría: cuantos más logs envíes, mayor realismo y más contexto tendrás, pero también crecerán el consumo de recursos y el ruido. En un entorno doméstico o de pyme simulada es razonable centrarse en eventos de seguridad, logs de aplicaciones críticas, Sysmon y, si los hay, registros específicos de tus soluciones EDR o antivirus.

A medida que vayas afinando las detecciones, tiene sentido construir dashboards que resuman el estado del laboratorio: hosts con más eventos anómalos, picos de actividad sospechosa, gráficos temporales de conexiones extrañas, etc. Aunque el entorno sea pequeño, pensar en términos de cuadros de mando reales te ayuda a interiorizar la lógica del trabajo en un SOC.

Sysmon en Windows: ver qué hace realmente el ataque

Sysmon (System Monitor) es una de las herramientas clave para observar el interior de Windows cuando ejecutas un payload o sufres una intrusión. Genera eventos muy detallados sobre creación de procesos, conexiones de red, cambios en el sistema de ficheros y otros comportamientos típicos de malware.

Su instalación en la VM Windows 10 pasa por descargar el binario de Sysinternals y acompañarlo de un fichero sysmonconfig.xml robusto, preferiblemente basado en configuraciones públicas mantenidas por la comunidad para filtrar ruido y destacar actividades potencialmente maliciosas.

La puesta en marcha se hace desde PowerShell con privilegios de administrador, indicando el ejecutable y el XML de configuración apropiado. Una vez instalado, revisas en el Visor de Eventos que el canal de Microsoft-Windows-Sysmon esté generando datos y que la configuración se haya aplicado sin errores.

El siguiente paso crítico es integrar esos eventos con el SIEM: Splunk debe poder leer los registros de Sysmon, bien mediante un forwarder, bien a través de la recogida directa de logs de eventos de Windows. A partir de ese momento, cada simulación dejará un rastro forense completo listo para ser analizado.

Gracias a Sysmon, podrás ver cosas como el proceso que ejecuta el payload, los hijos que crea, las conexiones de salida que establece, los hashes de los binarios implicados o la creación de claves de registro para persistencia, todo ello perfectamente trazable en tu laboratorio.

Generación de payloads de prueba con msfvenom

Para darle vida al entorno ofensivo necesitas un malware controlado que puedas diseccionar. msfvenom, parte del framework Metasploit, permite generar ejecutables maliciosos personalizados que establecen una conexión inversa hacia tu Kali y te dan acceso remoto a la máquina víctima.

Desde la VM de Kali puedes crear un payload “disfrazado” con nombre de documento o archivo inocente, por ejemplo un supuesto «resume.pdf.exe» que un usuario descuidado podría ejecutar pensando que es su currículum. En el comando defines el tipo de payload, la IP del atacante (LHOST), el puerto (LPORT) y el formato de salida.

El resultado será un binario que, dentro del laboratorio aislado, se comporta como un troyano clásico: al ejecutarse en Windows, abre una sesión remota hacia Metasploit. Para que el ejercicio funcione sin demasiadas trabas, suele ser recomendable desactivar temporalmente Windows Defender y cualquier otro antivirus en la VM de pruebas.

Es fundamental remarcar que estos payloads están pensados solo para fines educativos dentro del entorno que controlas. No deben salir de tu red virtual ni usarse contra sistemas ajenos o sin autorización explícita; de lo contrario, estarías cruzando claramente la línea de lo legal.

Si quieres ir un poco más allá, puedes generar distintas variantes de payload cambiando técnicas de ofuscación, puertos, protocolos o mecanismos de persistencia, y observar cómo cambia la telemetría y qué detecciones adicionales tendrías que configurar en Splunk.

Listener de Metasploit y ejecución del ataque

Con el payload creado, toca preparar el entorno en Kali para recibir la conexión. Para ello utilizas msfconsole, el interfaz principal de Metasploit, desde el que configurarás un handler acorde al tipo de payload generado con msfvenom.

Dentro de Metasploit seleccionas el módulo de handler apropiado, estableces LHOST y LPORT para que coincidan exactamente con los parámetros del payload y arrancas el listener. Desde ese momento, la máquina atacante se queda esperando que la víctima ejecute el binario.

Cuando el usuario de la VM Windows 10 abre el supuesto documento malicioso, si la red está bien configurada y no hay cortafuegos bloqueando, el payload se conectará a Kali y obtendrás una sesión Meterpreter (u otra según el tipo de payload) con control sobre el sistema remoto.

Más allá del efecto “wow” de tener una shell remota, lo interesante de cara al home network attack simulator es observar la huella que deja esta intrusión: procesos iniciados, tráfico generado, modificaciones en el sistema operativo, etc., todo ello capturado por Sysmon y enviado a Splunk.

Desde la perspectiva defensiva, esta sesión es solo un síntoma visible de una cadena de eventos más larga. Analizarla con calma en el SIEM te permite entrenar el ojo para detectar patrones de intrusión similares aunque el malware sea distinto en el futuro.

Detección, análisis y alertado en Splunk

Una vez que el ataque ya ha ocurrido y los logs están recogidos, llega el momento de ponerse la gorra de analista blue team y bucear en Splunk para reconstruir el incidente y extraer reglas de detección útiles.

Empieza lanzando búsquedas sencillas acotadas por tiempo y host: qué procesos se ejecutaron en la máquina víctima durante la ventana en la que abriste el payload, qué conexiones de red salientes se establecieron, qué eventos de Sysmon indicaron creación de ejecutables en carpetas temporales, etc.

A medida que vayas identificando patrones que se repiten (por ejemplo, un proceso hijo concreto, una ruta sospechosa o un puerto no habitual), podrás convertir esas consultas en alertas programadas que salten cada vez que se detecte un comportamiento similar.

Además de las alertas sencillas, es interesante trabajar correlaciones que combinen varios indicadores: un ejecutable en %TEMP%, seguido de una conexión saliente hacia una IP concreta y la creación de una clave de registro extraña, por ejemplo. Este tipo de correlaciones se parecen mucho a las reglas que emplean los SIEM en entornos productivos.

No olvides la parte visual: construir dashboards específicos para tu laboratorio te ayudará a vigilar de un vistazo eventos relevantes, hosts más “ruidosos” o timeframe de actividad maliciosa. Es una buena forma de practicar cómo sintetizar y presentar la información de seguridad a otros equipos o a responsables no técnicos.

Solución de problemas habituales en el laboratorio

Es muy normal que al principio las cosas no funcionen a la primera: el payload no conecta, Metasploit no recibe sesiones, Splunk no ve eventos o Sysmon parece mudo. Precisamente por eso compensa dedicar tiempo a documentar el troubleshooting de tu simulador.

Si el payload no llega a establecer sesión con Kali, revisa lo básico: IP de la máquina atacante, LHOST y LPORT correctamente configurados en msfvenom y msfconsole, tipo de red de cada VM (NAT, bridge o red interna) y posibles firewalls bloqueando el puerto del listener.

Cuando el problema es que no ves logs en Splunk, normalmente se debe a una entrada de datos mal configurada o a que Sysmon no está enviando sus eventos al canal que Splunk está monitorizando. Verificar que el servicio de Sysmon esté en ejecución, que el XML de configuración sea válido y que el índice de Splunk reciba datos desde la máquina afectada suele solucionar gran parte de los casos.

Otro clásico en laboratorios con muchas VMs es quedarse corto de recursos: si notas que todo va a tirones, quizá tengas demasiadas máquinas encendidas a la vez para la RAM disponible. En ese caso, prioriza lo esencial para cada ejercicio (por ejemplo, Kali + 1 Windows + servidor de logs) y apaga VMs accesorias hasta que tu hardware dé más de sí.

También puede ocurrir que el propio antivirus o Windows Defender estorben incluso dentro del laboratorio. Si estás trabajando con payloads controlados, tiene sentido desactivar temporalmente estas defensas en la VM de víctima para centrarte en la parte de detección basada en logs, dejando claro siempre que esto se hace solo en un entorno aislado y con fines formativos.

Más allá de lo básico: CTEM, ELK, Wazuh y automatización

Cuando domines el escenario clásico de Kali + Windows + Splunk, el siguiente nivel es evolucionar tu home network attack simulator hacia algo más parecido a un programa de CTEM (Continuous Threat Exposure Management), donde las pruebas de ataque y defensa son continuas y sistemáticas.

El enfoque CTEM implica ir más allá del “lanzo un ataque y miro qué pasa”, para pasar a ciclos periódicos en los que analizas la superficie de ataque de tu red simulada, priorizas qué amenazas probar, automatizas campañas y ajustas defensas en función de los resultados.

En la práctica, esto puede significar integrar otras plataformas de análisis como ELK Stack (Elasticsearch, Logstash y Kibana) para explotar mejor tus logs, o incorporar Wazuh como SIEM/EDR open source con agentes en los endpoints, reglas de correlación mantenidas por la comunidad y capacidades de respuesta más avanzadas.

Otra línea de evolución muy interesante es automatizar los ataques mediante scripts en Python u otros lenguajes que ejecuten colecciones de técnicas MITRE ATT&CK. De este modo puedes lanzar campañas de prueba recurrentes y medir cómo mejoran tus detecciones a lo largo del tiempo conforme vas afinando reglas y configuraciones.

Si quieres que tu simulador sea reutilizable y compartible, puedes inspirarte en plataformas como TopoMojo, que permiten diseñar, guardar y desplegar laboratorios completos desde una interfaz web. Aunque no lo uses directamente, documentar tu entorno como si fueras a publicarlo en una plataforma así le da un toque muy profesional.

Suites avanzadas de simulación: ideas para enriquecer tu laboratorio

En entornos de alto nivel, como gobiernos o grandes corporaciones, los simuladores de red dan un paso más y crean auténticos “Internet falsos” totalmente contenidos. Aunque probablemente no necesites ese nivel de complejidad en casa, conocer estos conceptos te puede dar ideas muy buenas para enriquecer tu laboratorio.

Herramientas como TopGen permiten levantar multitud de servicios (webs, DNS, correo) en un solo host, asignando muchas IPs a la interfaz de loopback. Así cada servicio parece un servidor distinto, lo que en una pyme simulada se traduce en poder tener varias webs internas y servicios corporativos sin disparar el consumo de recursos.

Por otro lado, proyectos tipo GreyBox ofrecen una emulación del backbone de Internet dentro de una sola VM, con cientos de webs copiadas de sitios reales, DNS raíz simulados, servicios de criptomonedas y más, todo corriendo en contenedores. La experiencia para el usuario es casi indistinguible de navegar por la red real, pero todo ocurre en un entorno cerrado.

Frameworks como GHOSTS añaden la capa de usuarios sintéticos que generan tráfico verosímil: navegan, envían correos, abren documentos, cometen errores de seguridad, etc. Introducir algo similar, aunque sea con scripts sencillos, hará que tus ataques no destaquen en un «vacío», sino en medio de actividad legítima, lo que dificulta y hace más realista la detección.

Finalmente, componentes como vTunnel separan el tráfico de gestión (telemetría interna, scoring, control de los propios usuarios sintéticos) del tráfico que ven los jugadores, de modo que las herramientas de análisis no se llenen de ruido de infraestructura y puedas centrarte en lo que de verdad importa: los ataques y la actividad del día a día de la red simulada.

Si a todo esto le sumas la posibilidad de simular redes Wi‑Fi al estilo de soluciones como WELLE-D —redes inalámbricas virtuales que no emiten radio real—, puedes incorporar a tu entorno ataques típicos sobre Wi‑Fi de oficina: cracking de contraseñas, puntos de acceso maliciosos, movimientos laterales desde la red de invitados, etc., todo sin interferir con el entorno físico.

Con todos estos elementos combinados, tu home network attack simulator deja de ser un laboratorio puntual para hacer pruebas sueltas y se convierte en una plataforma viva de formación y experimentación. Podrás recrear escenarios que van desde un simple malware doméstico hasta campañas elaboradas contra una pyme simulada, siempre con la tranquilidad de estar operando en un entorno totalmente controlado y ético.