All work

Aug 2025 - Present Solo lab: attack, detect, document

Cybersecurity Lab

A blue-and-red security portfolio where every attack I run ends on the control that catches it: custom Snort and Wazuh detections, a Splunk pipeline, DFIR, and exploit work in an isolated VM lab.

Snort Splunk Wazuh Kali DFIR
Cybersecurity Lab screenshot

Cybersecurity Lab is where I pair attack and defense so neither one is theoretical. The rule I built it on is simple: you cannot tune a detection for a technique you have never run. So every offensive project generates a real technique in an isolated VM lab, I watch it land on the wire or in the logs, and then I match it to the control that detects or stops it. It collects 11 defensive projects and 5 offensive ones — Snort rule writing, a Splunk pipeline, a Wazuh SIEM, vulnerability management, digital forensics, plus recon, reverse shells, a buffer overflow, password cracking, and steganography — all run against self-built or authorized targets, with the write-ups stopping short of reusable exploit code.

Defensive
11 projects
Offensive
5 projects
Detection
Snort · Splunk · Wazuh
Frameworks
NIST · ATT&CK
Stack
Kali Linux Snort Splunk Wazuh Nessus Wireshark Sysmon FTK Imager YARA MITRE ATT&CK VirtualBox

Why I built it

Most security writeups are one-sided: either an attack with no defender, or a dashboard screenshot with no attacker. This lab refuses to pick a side. Each offensive technique is generated in an isolated lab, observed in a packet capture or a log, and then matched to the specific control that would detect or stop it.

The defensive projects are built the same way — on artifacts I actually captured or wrote, not screenshots of someone else dashboard. Eleven defensive projects and five offensive ones sit in one portfolio because tuning a detection and running the attack it catches are the same job.

The defensive half: eleven projects

A Wazuh all-in-one node watches agents across the lab, with logs flowing inward to the SIEM only and the manager unable to be administered from the segments it monitors. For detection engineering I wrote Snort rules from scratch — FIN, NULL, and Xmas scan signatures, oversized-ICMP, and DNS logging — validated each with snort -T, then fired live scans from a Kali box and watched them trip in the console.

The eleven defensive projects run from incident response and forensics through detection, hardening, and threat intel:

Wireshark Follow TCP Stream showing Telnet login credentials in cleartext
Telnet: the stream reassembles in Wireshark and hands over the login in cleartext
Wireshark Follow TCP Stream of an SSH session showing only ciphertext after the handshake
SSH: the same Follow-Stream view is opaque ciphertext once the handshake completes
01 · Vendor breach IR
A real credential-rotation and access-review response to a vendor breach, written as a full IR record
02 · DFIR investigation
Live response in order of volatility, hash-verified disk imaging, and indicator development
03 · Detection engineering
Writing and testing Snort rules, plus a Windows-log investigation that exposed a default detection gap
04 · Vuln management & hardening
Vulnerability scanning, STIG hardening, and scripted Windows patching
05 · Protocol analysis
Capturing plaintext credentials on the wire and proving what encryption hides
06 · Incident case studies
Real-world breaches mapped to the response lifecycle and MITRE ATT&CK
07 · Wazuh SIEM
Single-node Wazuh, Linux agent enrollment, and FIM/SCA/vulnerability visibility
08 · Secure WordPress
Defense-in-depth behind Cloudflare Tunnel, Caddy, WAF rules, 2FA, and backups
09 · Mobile forensics
A mobile QR-phishing campaign mapped to ATT&CK plus a Snapchat iOS artifact methodology
10 · OSINT & IOC reporting
A passive VirusTotal reputation assessment written up as a formal IOC report
11 · Snort → Splunk pipeline
A team capstone feeding a Snort sensor into Splunk via a Universal Forwarder

The offensive half, ending on a control

The offensive projects all run in host-only VM networks against Metasploitable or targets I built, and each one ends on the defense that would have stopped it. nmap scans in six modes, confirmed packet-by-packet in Wireshark, map to the Snort scan rules I wrote. A reverse shell that connects back over netcat maps to egress filtering and segmentation.

A 116-byte input that overwrites a return address with 0x41414141 — stopped deliberately before code execution — maps to stack canaries, NX, ASLR, and PIE. hashcat recovering only the MD5 hashes from a mixed set maps to salted, slow KDFs like bcrypt and Argon2.

hashcat terminal run recovering only the MD5 hashes from a mixed hash set
Password cracking: hashcat recovers only the MD5 entries from a mixed set
An ordinary-looking cover image that conceals an AES-encrypted payload via OpenStego
Steganography: this ordinary-looking image carries an AES-encrypted payload hidden with OpenStego
01 · Recon & port scanning
Every nmap scan type captured in Wireshark, the flag exchange that tells open from closed, and an OS fingerprint
02 · Stack buffer overflow
ASLR demonstrated, a vulnerable C program overflowed to a controlled crash, and the mitigations that defeat it
03 · Password cracking
A hashcat dictionary attack on mixed hashes, why only some fell, and the storage choices that stop it
04 · Reverse shell & post-exploitation
A connect-back shell reading and writing files, why it beats a bind shell, and the egress controls that catch it
05 · Steganography
Hiding an encrypted file inside an ordinary image with OpenStego, recovering it, and the controls that catch the channel

Incident response and forensics

Two projects are full investigations. One is a vendor-breach incident response built on the NIST SP 800-61 lifecycle: I inventoried exposed secrets, scoped them by blast radius, rotated by exposure starting with the most direct, and verified with eight checks and four grep sweeps that all returned zero surviving secrets — the functional retest even surfaced an unrelated bug.

The other is a DFIR exercise on a Windows 11 VM: imaging a disk with FTK Imager under dual MD5 and SHA-1 hashes, capturing volatile evidence in order of volatility, running a benign-looking outbound 443 connection to ground, and producing three OpenIOC indicators from a registry persistence finding.

Back to all work