Home

  • Building a PAM Labl: Tiered Admins, JIT Access, and Privilege Escalation Detection

    Most identity programs treat all admin accounts the same. One Domain Admins group, everyone who needs elevated access goes in, and nobody audits it until something goes wrong. That works until a help desk technician’s credentials get compromised and the attacker walks straight into your domain controllers because that technician was in Domain Admins.

    Privileged Access Management exists to stop exactly that. This lab builds a full PAM implementation on top of the IAM lab I published last week, same Citadel infrastructure, same domain, extended with tiered admin accounts, JIT elevation, a privileged account audit script, service account security examples, and a live privilege escalation simulation with event log evidence.

  • Building an IAM Lab: Provisioning, Access Reviews, and GPO from Scratch

    IAM sits at the intersection of security, compliance, and day-to-day IT operations. It’s what controls who gets access, to what, and for how long. One misconfigured account, one stale user that never got deprovisioned, one group with permissions broader than they should be, and you have a problem that no firewall catches. It’s one of those disciplines that looks straightforward on paper until you’re actually doing it.

  • AI-Assisted SOC Triage on Top of Splunk Using the Anthropic API

    I finished Part 3 of my Splunk lab series and immediately had the same thought I always have after a big lab build: okay, data is flowing, detections are running, but I’m still the one manually reading through events. That’s the gap I wanted to close.

    So I built a Python tool that pulls Windows Security events from Splunk, sends them to the Anthropic API, and gets back a structured SOC triage report with MITRE ATT&CK mapping. The whole thing runs in one command. The output that came back on the first real run flagged four attack patterns in my lab, including my own failed logins from a trusted VM listed as a HIGH severity brute force. That part I’ll come back to.

  • Building a Splunk SIEM Lab on Proxmox, Part 3: MITRE ATT&CK Mapping and Building a Complete SOC Workflow

    Part 1 and Part 2 got data flowing and detections running. By the end of Part 2 I had a brute force alert firing every 5 minutes and a dashboard showing failed logon activity across the lab. But running detections and having a SOC workflow are two different things. Part 3 closes the loop.

    This is the part where the lab starts looking less like a project and more like something a real detection engineer would build.

  • Building a Splunk SIEM Lab on Proxmox, Part 2: SPL Searches, Alerts, and Dashboards

    Part 1 got Splunk running with Universal Forwarders on two Windows endpoints. Logs were flowing. But staring at a raw event stream isn’t detection engineering, it’s just data collection. Part 2 is where the actual work starts.

    This is the phase where I went from “I have logs” to “I have detections.” By the end of this post I had a brute force alert running every 5 minutes and a dashboard that tells a story at a glance.

  • Building a Splunk SIEM Lab on Proxmox, Part 1: Install and Data Onboarding

    I already hold the Splunk Core User certification, so I knew the product. But it was about backing up that cert with something real. A working deployment, actual Windows endpoints, actual logs flowing in. The cert gets you in the door, the lab is what you talk about once you’re inside.

    This is Part 1 of a 3-part series. Part 2 covers SPL searches and correlation rules. Part 3 brings in MITRE ATT&CK mapping and a Splunk vs Wazuh comparison.

  • Building a Security Compliance Lab from Scratch: Part 3: Mapping to NIST CSF 2.0

    NIST CSF 2.0 shows up on more job descriptions than almost any other framework right now. Not because companies are all formally certified against it, but because it gives security teams a common language for talking about risk. If you can map real work to its six functions, you’re speaking that language.

    Part 1 and Part 2 of this series built the lab and demonstrated ISO 27001 Annex A controls. Part 3 takes the same environment and maps it to NIST CSF 2.0, covering all six functions: GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND, and RECOVER. The difference from Part 2 is that this time the evidence includes live attack simulation with automated response, a remediated compliance scan, and snapshot-based recovery.

  • Building a Security Compliance Lab from Scratch: Part 2: Demonstrating ISO 27001 Annex A Controls

    Security frameworks look great on a resume. They look better when you can show the evidence.

    Part 1 built the infrastructure: pfSense segmenting four network zones, Wazuh collecting logs from four agents, dc01 running Active Directory, and a fresh Rocky Linux 9 VM sitting in the Corporate zone waiting for its compliance scan. Part 2 is where the lab earns its name. This post maps six ISO 27001 Annex A controls to real activity in the lab and generates the kind of evidence you’d hand to an auditor.

  • Building a Security Compliance Lab from Scratch: Part 1, Infrastructure Setup

    Security frameworks show up on almost every cybersecurity job description. NIST CSF. ISO 27001. NIST 800-53. Whether you’re going for a SOC analyst role, a security engineer position, or a sysadmin job that’s shifting toward compliance work, there’s a good chance they’ll expect you to know at least one of them. Reading about these frameworks is one thing. Being able to say you built a lab that demonstrates them is a different conversation entirely.

    So I built the lab.

  • No More IP:Port, Custom Domains in My Homelab with Tailscale, Technitium, and NPMplus

    At some point every homelabber hits the same wall. You’ve got a dozen services running, everything works, but accessing them means remembering things like https://10.0.0.225:8006 for Proxmox or http://10.0.0.110:3000 for whatever else you spun up last week. And on top of that, every browser screams at you about untrusted certificates. It works, but it feels janky.

    I got tired of it. So I fixed it.

  • Setting Up Wazuh SIEM in My Homelab

    If you’re running a homelab and want to get into security monitoring without spinning up a full enterprise stack, Wazuh is one of the best starting points. It’s open source, actively maintained, and mirrors what you’d actually use in a real SOC environment. I’ve had it running for about three months now and it’s become one of the most valuable tools in my setup.

  • Spinning Up an Ubuntu Server VM on Proxmox

    If you’re running Proxmox and haven’t spun up a Linux VM yet, this is probably the best place to start. Ubuntu Server is lightweight, well documented, and works perfectly as a base for almost anything you want to run in your homelab. I spun this one up on Citadel, my dedicated cybersecurity lab server, to use as a foundation for a Wazuh SIEM deployment.

  • Welcome to SlyTech Blog

    This is where I’ll be documenting my homelab builds, cybersecurity lab work, and infrastructure projects. First real post coming soon.