How to set up a home network attack simulator geared towards SMEs

Setting up a home network attack simulator has become one of the most engaging and useful projects for anyone starting out in cybersecurity or looking to take their career to the next level in a professional setting. The idea is simple: recreate real-world attacks in a lab environment and, at the same time, learn how to detect and contain them, just like a blue team would in a small or medium-sized company.

Instead of simply setting up a couple of virtual machines in VirtualBox , the truly interesting approach is to design a small, virtualized "mini-company" in a lab environment: user computers, a log server, SIEM tools, internal services, and, of course, an attacker. This allows you to present realistic threats, test defense mechanisms, and, most importantly, practice complete detection and response processes without compromising production networks or connecting to the real internet.

What is a home network attack simulator and why should you be interested?

A home network attack simulator is essentially a lab environment where you replicate a real network (home or small business) to launch controlled attacks, generate telemetry, and train defense techniques. It's not just "playing hacker" with Kali Linux, but building a scenario with victims, services, logs, alerts, and a complete attack and response cycle.

These types of simulators stem from the same need that large organizations have when they set up cyber ranks or exercises in classified environments: to train and evaluate teams without connecting to the internet and without malware infiltrating the system. There, complex suites of tools are used to simulate thousands of websites, realistic traffic, fake users, and entire networks; at home or in a small business, the idea is to replicate that approach but on a smaller scale.

In practice, a good home or small business network attack simulator allows you to answer these questions: How does an attacker gain access? What do they leave in the logs? How does a SIEM perceive it? What alerts should be created? What steps should the response team follow? Designing the environment with this "blue team" mindset is what makes your project serious and defensible to a professor or a security manager.

Furthermore, thanks to modern virtualization, you can set up the entire environment on a single host with sufficient RAM, isolated from the rest of your network, and reuse it for your own training, to train others, or even to conduct internal demos within a company without relying on external laboratories.

Hardware and software requirements for the laboratory

Before you start creating virtual machines like there's no tomorrow , it's a good idea to review your resource and tool requirements. A minimally realistic environment consumes memory and CPU, and if you fall short, you'll end up with a sluggish host and frozen VMs precisely when you need them most.

As a reasonable guideline, ideally you should have at least 16 GB of RAM in your hardware to run multiple virtual machines simultaneously without too much trouble. It's possible with less, but you'll have to reduce memory allocation in the VMs and shut some down to power others on, which complicates things and makes the experience less smooth.

Regarding virtualization, the most common options are VMware Workstation and VirtualBox, and it's worth considering technologies like Virtualization Based Security (VBS) . Both allow you to create isolated internal networks, snapshots, and fast VM cloning. VMware generally offers slightly better performance and integrations, while VirtualBox has the advantage of being free and widely used in academic environments.

At the level of operating systems and security software , the basics for this project would be:

• A Kali Linux ISO (or another pentesting-oriented distro) for the attacking team.
• A Windows 10 ISO for the end-user victim team.
• Splunk Free Installer or a SIEM alternative to centralize logs.
• Sysinternals' Sysmon and an XML configuration file well done, like those of Sysmon Modular type projects.

Finally, you'll need an internet connection, at least during the initial phase, to download ISOs, distribution updates, and all the necessary software. Once you have your lab set up, it's best to isolate it to avoid any surprises and ensure that no test malware escapes to your home or corporate network.

Network topology design for a simulated SME

The leap from a "home" lab to a simulator designed for a small or medium-sized business lies in the network topology: simply running Kali and Windows on the same network is no longer sufficient. It's necessary to think in terms of segments, roles, and services, just as you would in a production network.

A simple but realistic scheme could include at least three distinct zones within the virtual network: a user network (Windows 10), a segment where internal services reside (for example, a Windows or Linux server with some services and the SIEM), and the network from which Kali attacks. All of this can be implemented using internal networks in the hypervisor, virtual routers, or simply with well-configured NATs.

In this scenario, Kali Linux acts as the external attacker or a compromised machine attempting to gain access to the company's internal resources. Windows 10 acts as an employee's workstation, with office tools, a web browser, email, and anything else you deem necessary to provide context. Splunk serves as the central monitoring system, receiving events from both Windows (Sysmon and system logs) and any other devices you choose to add.

The idea is that all malicious traffic generated passes through the SIEM's "radar" and is recorded for analysis. This way, each simulated attack automatically becomes a case study: you can reconstruct the timeline, identify indicators of compromise, and test correlation rules or alerts that could then be extrapolated to a real-world SME environment.

Creating and configuring virtual machines

The first practical step of the project involves setting up the necessary virtual machines and placing them within the defined topology. This is where you choose how much memory and CPU to allocate to each one, which disks to use, and how to connect them to each other.

For Kali Linux, the typical process is to download the ISO from the official website , create a new VM in VMware or VirtualBox, allocate a few gigabytes of RAM and a few cores, and complete the installation like any other system. Immediately after installation, it's advisable to update all the packages to ensure you have the latest version of your penetration testing tools.

The Windows 10 virtual machine is created similarly , using the official Microsoft ISO. It's advisable to allocate more memory to it than you would to Kali if you plan to install Splunk or run multiple user applications simultaneously. During installation, ensure the network configuration allows it to communicate with the other VMs in the lab, but without internet access unless strictly necessary for your tests.

It's good practice to create snapshots once you have your VMs in a "clean" state with the system updated and the basic tools installed. This way, every time you perform an aggressive simulation (for example, running malware generated with msfvenom), you can revert to the initial state without having to reinstall everything from scratch.

Log monitoring with Splunk as the central SIEM

For a home network attack simulator to be valuable from a defensive standpoint , you need a system capable of collecting and analyzing events across the entire network. Splunk, even in its free version, fits in very well as a lightweight lab SIEM and is perfectly suited for teaching monitoring and detection concepts.

The typical deployment in a small environment involves installing Splunk directly on the Windows 10 machine or on a dedicated Windows/Linux server within the same topology. Once installed, you log in with administrator credentials, configure the indexes, and begin defining data entries to collect security, system, and application logs, and, very importantly, the rich events generated by Sysmon.

Within Splunk, you can create specific searches to track suspicious activity , such as anomalous processes, outbound connections to unusual ports, or suspicious modifications to the Windows registry. From these searches, the next logical step is to transform useful queries into alerts that are triggered when certain conditions are met, thus emulating the daily work of a security analyst.

The more telemetry you send to the SIEM, the more realistic your exercises will be , but the greater the volume of data to manage. In an academic or demonstration environment, it's reasonable to focus on key logs for intrusion detection: login events, processes, network activity, critical configuration changes, and logs specific to installed security tools.

Using Sysmon on Windows to capture malicious activity

Sysmon (System Monitor) is an essential tool if you want to see "from the inside" what malware or an intrusion is doing on a Windows system. Unlike traditional logs, Sysmon generates highly detailed events about processes, network connections, file system modifications, and much more, making it the foundation of many advanced detection methods.

Installing Sysmon on a Windows 10 VM involves downloading it from the Sysinternals website and using a robust XML configuration file. Instead of writing it from scratch, it's common to use public configurations maintained by the community, which already include rules for filtering out noise and highlighting typically malicious behavior.

The deployment is performed from a PowerShell console with administrator privileges , specifying the executable and the XML configuration file. After installation, it's advisable to verify that the service is running correctly and that events begin appearing in the Windows Event Viewer, under the Microsoft-Windows-Sysmon logs.

Once you've confirmed that Sysmon is working, the key step is to ensure that its events are being sent to Splunk or your SIEM. As soon as you generate a simulated attack, Sysmon will leave a forensic trail of processes, hashes, connections, and actions that you can later analyze at your leisure, reconstructing the entire attack scenario step by step.

Generating test malware with msfvenom

To liven things up, you need a realistic payload that behaves like malware but that you can completely control. msfvenom, part of the Metasploit ecosystem, lets you create custom malicious executables that connect back to your Kali machine and give you a remote session on the victim.

From the Kali VM, you can generate, for example, a disguised executable with an innocent-sounding name, such as "document" or "CV," which you would then run on Windows 10 to simulate an employee opening a malicious file. The msfvenom command defines the payload type, the attacker's IP address and port (LHOST and LPORT), and the file output format.

The result is a binary file that, to the Windows system and many basic antivirus programs , can go undetected if they are not properly updated or configured. In the lab setting, it's common practice to temporarily disable Windows Defender or other security solutions on the VM so they don't interfere with the experiment, allowing you to focus on the log and SIEM detection aspects.

It is important to emphasize that these payloads are intended exclusively for educational use within the isolated environment you have created. They should never leave that lab or be used against systems you do not control or for which you do not have explicit authorization, as this would constitute the illicit use of offensive tools.

Metasploit listener configuration and attack execution

With the payload generated, the next step is to prepare the Metasploit listener in Kali , which will be responsible for receiving the connection from the victim machine when someone executes the malicious file. This is done from msfconsole, the framework's main interface.

Within Metasploit, select the appropriate exploit or handler for the payload you created , configure LHOST and LPORT to match the parameters used in msfvenom, and set the listener to wait. From that point on, any execution of the binary on Windows should trigger a reverse connection to Kali.

When the victim runs the supposed document, if everything is configured correctly , you'll obtain a Meterpreter session or similar that allows you to interact with the Windows system: listing files, capturing screenshots, downloading documents, etc. Beyond the spectacle, what's interesting for the project is observing what all this leaves in the logs.

From the blue team's perspective, the active Metasploit session is just the tip of the iceberg . What's truly valuable is going to Splunk, filtering by the victim's host, and examining what events have been generated: creation of suspicious processes, connections to unusual ports, writes to specific paths, possible persistence modifications, and so on. That's where you learn to translate a technical attack into detectable signals.

Detection, analysis and alerting of attacks in Splunk

Once the environment is capable of detecting the attack, it's time to work on the defensive side . Splunk becomes the dashboard from which you analyze the intrusion and decide how to configure useful alerts for an SME environment.

Start by performing simple searches on the logs generated during the attack : processes launched around the time, outgoing connections from the compromised machine, Sysmon events with unknown hashes, etc. Gradually, you'll identify patterns that repeat each time you execute the same payload.

With these clear patterns, you can create detection rules in Splunk that trigger when certain indicators of compromise appear, such as a binary executed from a temporary folder, an outgoing connection to an unusual port, or the creation of unusually chained processes on a standard workstation.

In addition to basic alerts, it's very useful to build specific dashboards for your lab: logical network maps, lists of hosts with the most suspicious events, time-based graphs of anomalous activity, etc. Even if the environment is small, thinking as if you were designing dashboards for a real company will help you better frame the project as a solution for SMEs.

Solving common problems in the laboratory

In these types of simulation environments, it's quite normal for "nothing to happen" at first : the payload doesn't connect, Metasploit doesn't receive sessions, Splunk doesn't see any events, or Sysmon seems silent. That's precisely why it makes sense to incorporate a well-developed troubleshooting section into your project.

If the payload fails to log in to Kali , the usual suspects are network parameters: incorrect IP address, misconfigured LHOST/LPORT, or an incorrect interface type selection on the VM (NAT, bridge, internal network). It's also important to check that no firewalls are blocking the listener port or that Windows Defender hasn't quarantined the executable.

When the problem lies with log visibility , it's usually due to an incomplete Sysmon configuration or because Splunk isn't receiving events from the correct source. Checking that the Sysmon service is running, that the XML configuration file is valid, and that the data entries in Splunk are pointing to the correct Windows event channel usually resolves most cases.

Another common problem in complex labs is performance : too many VMs for the available RAM. In these cases, prioritization is key: you might be able to shut down some auxiliary machines, reduce the memory of the less critical ones, or even separate the system into two scenarios (one focused on attack and the other on monitoring) depending on the needs of each exercise.

Expansions and improvements: towards a CTEM environment for SMEs

Once you master the basic Kali + Windows + Splunk scenario , the next level is to evolve your home network attack simulator into something closer to a continuous threat exposure management program, known as CTEM (Continuous Threat Exposure Management).

The idea behind CTEM is to go beyond "I launch an attack and look at the logs ," to move to a systematic cycle in which you evaluate the organization's attack surface (even if it's simulated), prioritize which threats have the greatest impact, automate testing, and continuously adjust defenses based on how real attacks behave.

In practice, this can translate into integrating other log analysis platforms such as ELK Stack (Elasticsearch, Logstash, Kibana) to have more customized dashboards, or incorporating Wazuh as an open source SIEM/EDR to add additional correlation capabilities, lightweight agents on endpoints, and community-maintained detection rules.

Another natural step is to automate attacks using scripts in Python or other languages ​​that execute predefined MITRE ATT&CK sequences, allowing you to launch recurring test “campaigns” and measure how your detections improve (or worsen) over time. This brings your lab much closer to the exercise model used by advanced organizations.

Advanced suites for simulating the Internet in closed networks

In more demanding environments, such as government agencies or large corporations , the concept of attack simulators goes a step further, constructing veritable "fake internets" within completely isolated networks. The idea is to give students the feeling of navigating, attacking, and defending on the global network without ever leaving the controlled environment.

To achieve this, specialized tool suites developed by cybersecurity R&D teams are used, aiming to bring realism, efficiency, and cost reduction to the creation of simulations. These solutions typically consist of several components that, together, create the feeling of a living ecosystem with thousands of services, users, and varied traffic.

Even if your SME project doesn't need to reach that level of complexity , knowing these tools helps inspire you and justify the design of your lab as a small-scale version of what is being done at a large level in the world of cybersecurity training.

TopGen: simulation of multiple services from a single host

TopGen is an application service simulator designed for offline exercise networks . It allows you to host a multitude of application-level services, such as HTTP websites, DNS domains, or virtual mail servers, each with its own specific configuration, on a single machine (physical or virtual).

The key to TopGen is that it assigns a large number of unique IP addresses to the host's loopback interface , so that each simulated service responds as if it were a separate server on the network. Routing and service daemon configuration ensure that client traffic reaches the correct destination and that responses are sent out with the appropriate IP address.

In a simulator for SMEs, you could draw inspiration from this approach to recreate several internal servers (corporate website, mail server, employee portal) using fewer physical resources, while maintaining the illusion of a corporate infrastructure with many different assets.

This greatly enriches attack and defense exercises , as the attacker has more potential targets and the defender must manage a greater diversity of logs, certificates, configurations, and possible entry points.

GreyBox: Internet backbone emulation in a single VM

GreyBox is a virtual machine designed to provide complete emulation of the internet backbone in isolated environments. It includes simulated connectivity for hundreds of websites, mail servers, cryptocurrency environments, and other services, all running on Linux containers.

In addition to application services, GreyBox emulates the Internet's own infrastructure , with root DNS and top-level domain (TLD) servers, a functional WHOIS service, and a Tier I web cloud with IP addresses and autonomous systems reminiscent of the real world.

One of the most interesting details is that many of the included web pages are copies of front pages from thousands of real sites, making the browsing experience within the simulator very similar to that of the Internet, even though everything is actually contained within your laboratory.

While you may not need to set up a complete GreyBox for your project , you could consider equipping your lab with some additional services (various internal websites, simulated external pseudo-services) that make phishing, browsing, or traffic analysis tests more believable for the users participating in the exercise.

GHOSTS: Synthetic users and realistic traffic

GHOSTS is a framework designed to create "synthetic users" on a training network . Instead of simply generating artificial traffic, it aims to simulate the behavior of real people using the computers: browsing, sending emails, executing commands, working with documents, etc.

These virtual characters can take on various roles , from diligent administrators to malicious insiders or careless users who make security mistakes. Interestingly, their actions generate traffic and events that appear entirely human and are not directly associated with the GHOSTS software itself.

Introducing a similar concept into your home network attack simulator (even with simple scripts that periodically open websites, send emails, or copy files) means that attacks don't occur in a network "void," but rather amidst legitimate activity. This makes detection slightly more complex and more similar to what happens in a real small or medium-sized business.

Furthermore, GHOSTS allows for the orchestration of friendly, hostile, and random behaviors , opening the door to complex insider threat exercises, multiple incident response, and false alarm management, all within a controlled environment.

vTunnel: managing traffic outside the field of view

In large-scale simulations, there's always a lot of "backstage" traffic, including telemetry, scoring, orchestration commands, and other invisible threads that keep the simulator running. If participants see this traffic, it breaks the spell and can be mistaken for malicious activity.

vTunnel is specifically designed to hide this administrative traffic by creating a tunnel channel that removes these communications from the game space. The traffic is injected and extracted from the virtual machines through the hypervisor, so players cannot see it using standard network monitoring tools.

In a small lab, simply separating the management networks physically might suffice , but the concept of having an invisible control plane can be useful. For example, to collect metrics from your VMs, control automation scripts, or manage synthetic users without contaminating the data analyzed by the defenders.

This approach helps exercises focus on the traffic that is truly relevant to the use case you want to demonstrate (attacks, browsing, email, etc.), reducing noise and preventing students from wasting time analyzing pure infrastructure packets from the simulator.

WELLE-D: Advanced Wi-Fi Network Simulation

Another interesting piece in this type of suite is WELLE-D , whose objective is to offer a complete emulation of Wi-Fi networks within virtual environments, without emitting a single real radio signal, something especially useful in classified areas where the use of wireless devices is prohibited.

WELLE-D creates virtual wireless interfaces that generate real 802.11 frames , but encapsulates them over hidden channels so they don't appear as conventional Ethernet traffic. From the perspective of Wi-Fi auditing tools, you appear to be interacting with a legitimate wireless network, when in reality everything is happening inside the virtualization server.

This allows students to practice attacks and defenses on wireless networks in a completely secure manner and without interfering with the physical environment, using the same tools they would use in a real audit: frame capture, packet injection, attacks on authentication protocols, etc.

In the context of a simulated SME, you could incorporate the idea of ​​virtual Wi-Fi networks to fulfill the role of the typical guest network or the internal wireless network of the office, and thus include attacks such as password cracking, rogue AP or lateral movement from a compromised access point.

TopoMojo: Construction and reuse of laboratories

Finally, TopoMojo is a web application designed to simplify the creation and deployment of virtual labs . It acts as a kind of "topology library" from which you can design, save, and launch complete training environments.

TopoMojo has two main sides: the player and the content creator . The player navigates through the available labs, sets them up, and accesses the machines to complete the exercise objectives. The creator designs the topologies, defines the networks, the number of hosts, the base images, and the necessary connections.

The philosophy behind TopoMojo fits perfectly with your project : to build a simulation environment that is not just a one-off for a presentation, but a platform that you can reuse, share with other students or colleagues, and evolve with new attack and defense scenarios over time.

Even without using TopoMojo directly, it's a good idea to document your lab as if you were going to upload it to such a platform: describe the VMs, the topology, the use cases, and the steps to get it up and running. This gives it a professional touch and makes it easier for anyone to replicate and learn from it.

Overall, a well-designed home network attack simulator for an SME combines the technical aspects (virtualization, networking, Kali Linux, Windows, Splunk, Sysmon, controlled malware generation) with a pedagogical design layer inspired by these large simulation suites: realistic traffic, synthetic users, separation of layers, and the ability to scale and automate. In this way, your project ceases to be a simple testing lab and becomes a training and continuous improvement tool for defenses, closely resembling what serious organizations are already using to strengthen their cybersecurity teams.