Hardening Active Directory Before the Attack

Phase 10 reached an important boundary today. The Windows Server 2025 domain controller and Windows 11 Enterprise client are built, but I did not want to install the attacker VM until I could answer a more important question: is the identity environment actually in a known-good state?

That turned today's work into a hardening and validation session rather than an attack session. I tested delegated administration, restricted Tier-0 use, expanded audit coverage, patched both Windows systems, chased down a multihomed DNS problem and finished by creating powered-off restore points.

Proving delegated workstation administration

The workstation administration model uses AGDLP rather than assigning privileges directly to individual users. My separate administrative identity is a member of the workstation-admin Global group, which is nested into a Domain Local permission group. Group Policy then places that Domain Local group into the built-in Administrators group on domain workstations.

I validated the complete chain on WIN11-CLIENT. The administrative identity received local administrator rights through the intended group path, while a normal employee identity remained a standard user. That turned the group design from a diagram into a tested authorization model.

A successful domain join exposed a default I did not want

One of the most useful findings happened almost by accident. A normal employee credential was accepted during the Windows client domain join. The join worked, but that was not consistent with the administrative boundary I was trying to build.

I traced the behavior to ms-DS-MachineAccountQuota, which was still set to 10. Instead of leaving the default in place, I reduced the quota to zero and explicitly delegated workstation computer-object administration to the workstation-admin role on the workstation OU. I verified the resulting ACL rather than assuming the delegation wizard had done what I intended.

The lesson was bigger than one setting: successful authentication does not automatically mean the authorization model is correct. Defaults still need to be compared against the design.

Keeping Tier-0 credentials away from ordinary workstations

I also finished the privileged-logon boundary. A dedicated GPO denies the Tier-0 group local interactive and Remote Desktop logon to ordinary workstations. Testing mattered here too: the Tier-0 identity was rejected at WIN11-CLIENT, while the delegated workstation-admin identity could still sign in successfully.

The result is a clearer separation between everyday IT work, workstation/server administration and domain-level administration instead of treating every privileged task as a reason to use Domain Admin credentials.

Building the telemetry before generating the attack

A dedicated Advanced Audit Policy GPO is now applied to the domain controller and workstation. It records authentication and logon activity, Kerberos authentication and service-ticket operations, account lockouts, account and security-group changes, process creation, policy changes and important system events.

This is intentionally being done before the offensive exercises. When I later generate password-spray and Kerberos activity, I want to know what telemetry should exist and why, rather than retrofitting logging after discovering that the evidence is missing.

Patching exposed a second troubleshooting problem

DC01 was patched before the attack baseline was frozen. The restart stalled for hours and eventually required a forced power-off. After recovery I did not assume Active Directory had survived cleanly: I rechecked the core AD services, SYSVOL and NETLOGON, domain-controller connectivity and DNS.

That validation exposed a persistent multihomed DNS issue. DC01 was publishing its VirtualBox NAT IPv4 and IPv6 addresses in authoritative AD DNS alongside the isolated lab address, even though normal DNS registration on the NAT interface had already been disabled.

Reproducing the DNS problem before fixing it

I forced domain-controller DNS registration and confirmed that the unwanted records returned. That was useful because it separated a stale-record problem from an active registration problem.

The fix in this lab was to restrict the DNS Server listener to the isolated AD interface at 10.10.10.10, restart DNS and deliberately force DC registration again. The unwanted NAT records did not come back. From WIN11-CLIENT, DC01 then resolved only through the lab address and the domain secure channel remained healthy.

I finished with another domain-controller connectivity check and confirmed the core AD, DNS, Kerberos, Netlogon and AD Web Services services were healthy.

Freezing the clean pre-attack baseline

With both Windows systems patched and validated, I shut them down cleanly and created powered-off VirtualBox snapshots named DC01 - Pre-Attack Identity Baseline and WIN11-CLIENT - Pre-Attack Identity Baseline.

Those snapshots mark the end of the first half of this part of Phase 10. The environment has been built, administered, hardened, instrumented, troubleshot and validated before any intentional attack activity is introduced.

What comes next

Kali is next, but the goal is not to collect attack commands. The next chapter is Attack → Detect → Investigate → Remediate. Controlled password-spray, Kerberoasting and credential-access exercises will stay inside the isolated lab and will be connected to Windows and Wazuh evidence, investigation notes, remediation and incident-response records.

Today's biggest takeaway was that the pre-attack validation was not administrative cleanup. It produced two of the most useful findings in the lab so far: an overly broad machine-join default and a domain controller registering the wrong interfaces in DNS. Finding and fixing those before attacking the environment made the defensive baseline much more meaningful.

Read the Phase 10 progress record ↗