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

Source: Dev.to

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.

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 / 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.

Validating Network Connectivity and Routing

A. Full Network Discovery from Kali

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.

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

B. Controlled Port Scanning

nmap -sS -p 1-1024 10.0.0.25

After the scan, search in Splunk:

index=* host=winserver*

What this proves

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

Observing Identity and Authentication Activity

A. Kerberos Authentication Validation

kinit administrator@LAB.LOCAL
klist