Chakravyuha: I'm Building a Purple Team AD Lab - Here's the Plan

I've spent years building things - applications, websites, personal projects - but always from the builder's side. Make it work, ship it, move on. Security was never part of how I thought about those builds.

What pulled me toward security was wanting to understand how organizations actually handle it at an industry level, not just how to break something in a lab. CTFs and TryHackMe rooms teach you to attack. They don't teach you logging, SIEM, monitoring, threat intelligence, or why a defender's deception layer matters - none of that shows up in a room built around one flag.

I ran into that gap directly when I messaged Harpreet Singh after reading his red-team-vs-purple-team post on LinkedIn, asking whether deception layers like honeypots and canary tokens actually work the way they're described on paper. He told me they're more common in mature enterprises than most people assume - Thinkst Canary, Microsoft Defender for Identity's decoy objects, and the identity-protection suites from CrowdStrike and SentinelOne all ship deception features by default now. Against automated tooling - mass Kerberoasting scans, a BloodHound collection - they work well, because the tooling doesn't discriminate. Against a careful manual operator, it comes down to engineering: a wrong pwdLastSet, a lastLogon that's too recent or never set, an odd SPN string - any of those gives a decoy away, and getting them right is a skill offense-only learning never touches.

That conversation was a small example of a bigger gap I kept hitting. I knew what logging was. I knew what a SIEM did, on paper. But when interviews actually asked me about them, I had nothing real to point to - just concepts I'd read, not things I'd done. I could have closed that gap with an online SOC simulator or a guided lab, but that's not how I learn well. I'd rather hit the real, unscripted version of a problem and work through it myself than have it pre-packaged for me. So instead of another course, I decided to build the thing itself - a lab where I'd actually have to think about logging, detection, and monitoring, not just execution.

I'm a B.Sc. Electronics (Honours) graduate from the University of Delhi working toward my first full-time SOC Analyst role. I completed the RISE Cybersecurity & Ethical Hacking Internship and hold the Google Cybersecurity Certificate.

TL;DR for recruiters / hiring managers

• What this is: A purple-team Active Directory lab - offense, defense, and architecture together, not just an attack showcase.
• What's different: A built-in deception layer, Sigma rules written from scratch, and every module following Attack → Detect → Respond → Harden.
• Why it exists: I kept failing to answer logging/SIEM/monitoring questions in interviews with real hands-on experience behind them. This is me closing that gap the way I actually learn - by building the real thing, not simulating it.

The Setup

I started with DC-01, a Windows Server 2022 domain controller, because every Active Directory environment starts there. It handles authentication, stores the directory, and provides DNS so every machine inside the domain can find each other.

Once the domain was running, I added SRV-01, a Windows Server 2019 file server. This isn't just another Windows machine - it gives the lab realistic services to attack. Service accounts, shared folders, and Service Principal Names (SPNs) create the conditions needed for techniques like Kerberoasting while still looking like something you'd expect to find in a small company.

Next came WS-01 and WS-02, two Windows 10 Enterprise workstations joined to the domain. These represent everyday employee machines. They generate normal logon activity, create realistic lateral movement paths, and provide endpoints where security monitoring actually matters.

After the Windows infrastructure was ready, I deployed a dedicated Ubuntu SIEM server running Wazuh. A SIEM platform collects logs from every Windows machine so I can see attacks from the defender's point of view instead of only from the attacker's. Sysmon extends the native Windows logs with detailed process, network, and registry telemetry that makes writing meaningful detections possible.

That verification mattered more than I expected. Early on, I found test events weren't reaching Wazuh's Discover view at all - not because the agents weren't sending them, but because the SIEM manager's root disk had filled up with old archive indices, which pushed OpenSearch into a block on new indices and silently broke Filebeat's ability to publish. The logs were arriving; they just weren't going anywhere I could see them. It's a small thing, but it's the difference between a pipeline that's "configured" and one that's actually confirmed working - and it's exactly the kind of failure a real SOC deals with, not something you'd hit running a scripted lab.

The build wasn't uninterrupted in other ways either - a couple of local power cuts corrupted VM state along the way, and snapshotting before any risky change went from "best practice I read about" to a habit I actually needed.

The final piece is a Kali Linux machine. It serves as the attack platform for every offensive exercise while staying separate from the rest of the environment. It has internet access only for updating tools, while all attack traffic stays inside an isolated host-only network.

Before I launch the first attack, I want the environment to look like a believable small business - not an empty domain built just to demonstrate one technique. Detection engineering is only meaningful when the environment behaves like one defenders might actually encounter.

What's Coming

• Module 1 - Kerberoasting: Can a single weak service account expose the entire domain?
• Module 2 - AS-REP Roasting: Sometimes the easiest credentials to steal never required authentication in the first place.
• Module 3 - Pass-the-Hash: What happens when knowing the password becomes completely unnecessary?
• Module 4 - BloodHound ACL Abuse: Small permission mistakes often become the biggest privilege escalation paths.
• Module 5 - DCSync: Replication rights can be more dangerous than administrator rights.
• Module 6 - Golden Ticket: What changes after an attacker effectively owns Kerberos itself?
• Module 7 - LAPS Bypass: Even good defensive controls have assumptions worth testing.
• Module 8 - Active Directory Certificate Services (ESC1): Certificates can become persistence mechanisms hiding in plain sight.
• Module 9 - Purple Team Reporting: Every attack ends with detection, response, hardening, and lessons learned - not just screenshots of a successful exploit.

What Makes This Different

A deception layer is built into the lab from day one. Honey service accounts, seeded credentials, and canary documents exist before any attack begins. The goal isn't just to catch automated tools - it's to understand what makes a decoy believable enough to fool a human operator too.

Every detection rule is written from scratch. Community Sigma rules are an excellent starting point and widely used in the industry. For this project, I want to understand the telemetry behind every alert, so each attack results in a Sigma rule I write myself - that forces me to understand the Windows events instead of treating detection as copy-paste.

The environment follows Microsoft's Active Directory tiering model. Administrative accounts, servers, and user workstations are deliberately separated instead of living in one flat domain. That creates more realistic attack paths and makes defensive decisions easier to explain.

Every module maps to both MITRE ATT&CK and MITRE Engage. ATT&CK explains what the attacker is doing. Engage focuses on how defenders can influence and detect that attacker through deception and active defense. Looking at both frameworks together gives a more complete picture than studying either one alone.

A SOC analyst isn't hired just because they know how an attack works. They're hired because they can recognize it, investigate it, understand its impact, and recommend a practical fix. That's the gap I want this project to close. Every technique in Chakravyuha follows the same cycle: Attack → Detect → Respond → Harden. If I can't explain every stage of that process, I haven't really learned the technique.

This post is the starting point for the entire Chakravyuha series. I'll document every stage - from building the lab and understanding Active Directory to executing attacks, writing detections, and hardening the environment - with a new post roughly every week as the project progresses.

Full series index: Series Link