Building a Virtualized Cybersecurity Lab: Introducing an Adversary with Kali Linux

This is the Fourth blog post in a series about building my Virtual home lab network as a Cybersecurity Student.

Originally, I planned to integrate a physical Kali Linux system via VPN. After encountering unnecessary operational complexity, I pivoted to deploying a Kali Linux virtual machine directly inside the lab-LAN. This approach improves reproducibility, safety, and visibility while still supporting realistic attack simulation.

This design choice also reflects many real-world incidents, where adversarial activity originates from inside a trusted or semi-trusted network rather than directly from the public internet.

Lab Architecture Reminder

As a recap, this virtualized cybersecurity lab consists of:

• pfSense firewall acting as router, DHCP server, and DNS forwarder
• Lab-NAT and Lab-LAN virtual networks
• Windows Server 2022 (Active Directory Domain Controller)
• Windows 11 domain-joined workstation
• Ubuntu Desktop (Splunk SIEM)
• Ubuntu Server (infrastructure services)
• Kali Linux attack VM (internal adversary) At this stage, the environment mirrors a small enterprise network with centralized identity, logging, and segmented routing.

Process Overview

Introducing Kali as an Internal Adversary

The goal of this step is to deploy a controlled attack system that lives entirely inside the lab-LAN and can generate observable activity without exposing the host system or external networks.

Step 1 — Creating the Kali Linux VM

The Kali Linux VM is deployed using the same virt-install and Virt-Manager workflow used throughout the lab:

sudo virt-install \
  --name kali \
  --ram 4096 \
  --vcpus 2 \
  --disk path=/var/lib/libvirt/images/kali.qcow2,size=20,format=qcow2 \
  --cdrom /var/lib/libvirt/boot/kali-linux.iso \
  --network network=lab-lan,model=virtio \
  --os-variant ubuntu22.04 \
  --graphics spice \
  --boot uefi

Notes:

• The Kali VM is connected only to the lab-LAN, keeping it isolated from the host and internet.
• A static IP is recommended to ensure repeatable attack simulations and predictable logging.

Step 2 — Configure a Static IP (Optional but Recommended)

Manually assigning a static IP simplifies Splunk searches and detection logic.

Step 3 — Integrating Kali with Splunk

With centralized logging already in place, the next step is to ensure activity generated from Kali is observable.

sudo apt install rsyslog
echo '*.* @10.0.0.52:514' | sudo tee /etc/rsyslog.d/60-splunk.conf
sudo systemctl restart rsyslog

Logs are forwarded using UDP syslog to remain consistent with the existing Ubuntu and pfSense log ingestion pipeline.

In a production environment, forwarding logs from an attack system would be carefully scoped. In this lab, full visibility is intentional to support learning and detection validation.

This ensures that authentication attempts, network activity, and simulated attacks from Kali appear in the SIEM alongside logs from Windows, Linux, and pfSense.

Validating Network Connectivity and Routing

A. Full Network Discovery from Kali

From the Kali VM:

ip a
ip route
nmap -sn 10.0.0.0/24

What this proves:

• Kali is correctly attached to the lab-LAN
• pfSense is routing traffic as designed
• All domain members are reachable

📸 Screenshot: Nmap host discovery showing pfSense, DC, Windows 11, and Splunk

SOC Lens:
Internal host discovery is a common reconnaissance technique and often triggers investigation due to unusual scanning behavior.

Tie-in to Part 1:
This validates the segmentation and routing configured in the pfSense-based network.

B. Controlled Port Scanning

nmap -sS -p 1-1024 10.0.0.25

Immediately after, search in Splunk:

index=* host=winserver*

This query confirms that scan activity from Kali is generating security-relevant events on the Windows host and that those events are centrally searchable.

What this proves:

• Attack traffic is successfully generated
• Host firewall behavior is visible
• Telemetry is ingested centrally

Tie-in to Part 3:
This confirms that network activity appears in Splunk in near real time.

Observing Identity and Authentication Activity

A. Kerberos Authentication Validation

kinit [e-mail]
klist

What this proves:

• Active Directory is functional
• DNS, Kerberos, and time synchronization are working
• Cross-platform Linux and Windows identity integration is functioning as expected

In Splunk, search for:

• Event ID 4768 (Kerberos TGT request)
• Event ID 4624 (successful logon)

Tie-in to Part 2:
Identity remains the primary control plane of the environment.

DNS and Name Resolution Validation

nslookup lab.local
nslookup winserver.lab.local
nslookup google.com

What this proves:

• Internal DNS resolution via Active Directory
• Name-based attack paths are observable

In Splunk:

• Review DNS query logs from the Domain Controller

Tie-in to Parts 2 & 3:
DNS underpins authentication, monitoring, and attack visibility.

Generating Detectable Attack Traffic

Visibility and Detection Validation

nmap -A 10.0.0.0/24

In Splunk:

index=* sourcetype=sysmon EventCode=3

Observed:

• Network connections
• Process names
• Source IP = Kali VM

This confirms the environment is not just functional — it is observable.

Key Takeaways / Lessons Learned

• Introducing a Kali Linux attack VM completes the lab by adding an adversarial perspective to an enterprise-style environment
• Internal adversaries are often more realistic than external attackers
• Identity-based telemetry produces the strongest detection signals
• Visibility validates architecture, not just configuration
• Meaningful detections do not require exploitation
• Correlation across data sources enables true investigation

Next Steps / Learning Opportunities

With networking, identity, visibility, and adversarial simulation in place, future work will focus on detection quality and response workflows.
Planned next steps include:
Building targeted Splunk detections for reconnaissance and authentication abuse
Mapping observed activity to MITRE ATT&CK techniques
Establishing behavioral baselines
Implementing Windows Event Forwarding (WEF)
Expanding pfSense monitoring and alerting
Evaluating alternative SIEM platforms such as Wazuh

Why This Lab Matters

This project demonstrates how networking, identity, logging, and adversarial behavior intersect in real environments. Rather than focusing on exploitation, the lab emphasizes understanding how attacks are detected, investigated, and correlated when proper visibility exists.

The goal is not exploitation — it is comprehension.