Active Directory Hardening After a Password Spray Attack
Active Directory hardening became urgent at 04:11 AM with the first EDR alert. EDR alerts at 4 AM. Eighty-three source IPs. Three service-account compromises. And an AD that had grown for fifteen years without a real review.
The Active Directory Hardening Challenge
The password-spray attack itself was contained relatively quickly. The deeper problem was what the EDR’s telemetry surfaced about the AD environment:
- No tier model. Domain admins logged into ordinary workstations daily; one of them used the same workstation for personal email.
- Stale accounts. 287 accounts had not authenticated in over 180 days but were still enabled, including a former CFO’s account from 2021.
- Service-account passwords were 8–10 characters, some unchanged for 4+ years.
- No MFA on admin accounts. A successful spray on a single admin would have been catastrophic.
Our Active Directory Hardening Approach
We split the engagement into containment, structural fix, and detection improvement.
- Days 1–7 (containment): reset every privileged credential, MFA enforced on every admin within 48 hours, blocked the attacker’s known IPs at the perimeter, kicked all active sessions, audited recent privileged actions.
- Days 8–60 (structural): implement Microsoft’s tier model — Tier 0 (domain controllers, AD), Tier 1 (server admins), Tier 2 (workstation admins). Privileged admin workstations isolated. Service accounts moved to Group Managed Service Accounts (gMSA) where the underlying service supported them; the rest had their passwords lengthened and rotated.
- Days 61–90 (detection): Microsoft Defender for Identity deployed on every domain controller. Conditional access policies tightened. Alerting rules tuned with the SOC partner.
What We Built for Active Directory Hardening
- AD Tier 0/1/2 separation — written policy, group memberships restructured, dedicated PAW (privileged admin workstations) for Tier 0 and Tier 1.
- MFA on every admin and service-account-equivalent role — FIDO2 keys for the four named domain admins, authenticator app for everyone else.
- Conditional access policies — admin actions only allowed from PAWs, only from corporate IP ranges, only when device is compliant per Intune.
- Service account hygiene — 24 of 47 migrated to gMSA, the rest rotated to 32-character random passwords with a documented rotation schedule.
- Microsoft Defender for Identity on all DCs with custom detection rules tuned for the client’s environment.
- Dormant account cleanup — 287 accounts disabled (after a 30-day notification period to managers); 49 of those were removed entirely after the further 90-day grace period.
- Password policy review — minimum length raised to 14 characters, NIST-aligned (no forced rotation, but enforced breach-detected reset via Defender for Identity’s leaked-credential feed).
Outcomes
- Zero successful password sprays in the trailing 12 months. Defender for Identity has flagged 14 attempted spray patterns; all were blocked at the conditional-access layer before any credential was validated.
- Domain admin login from non-PAW: dropped from a daily occurrence to zero.
- 287 dormant accounts disabled, 49 deleted entirely.
- Service account compromise risk: the 24 migrated to gMSA cannot be password-sprayed at all (managed passwords rotated by AD, not user-known).
- Mean time to detect privileged anomaly dropped from “months” to under an hour for the patterns Defender for Identity covers.
What We'd Do Differently
The single biggest mistake on our side was not insisting that the IT team’s daily-driver workstations be re-imaged before they accessed the new tier-restricted admin tools. We assumed clean workstations because EDR had not flagged anything; in week 6 we found one IT admin’s machine had a low-detection-rate stealer that had been quiet during the spray. We reset that admin’s credentials again and re-imaged the laptop. On subsequent engagements, IT-team workstation re-imaging is a Day-1 prerequisite, not a discovery.
Second: dormant-account notification. We sent the 30-day notice via email; some managers missed it because of how their inboxes were filtered. Two notable exceptions had to be re-enabled within 48 hours of the disable date. We now use multi-channel notifications (email + Teams DM + line-manager spreadsheet review) before disabling, and we run a “shadow disable” — accounts logged-as-disabled for 14 days first.
Stack & Tools
- Active Directory on Windows Server 2022 (across 14 DCs, 3 sites)
- Microsoft Defender for Identity (formerly Azure ATP)
- Microsoft Entra ID with Conditional Access
- Microsoft Intune for PAW configuration baselines
- Lithnet Password Policy (where AD-native policy hit limitations)
- BloodHound CE for privilege-path discovery during the discovery phase
FAQ
Why did you implement the tier model now if it had been recommended for years?
The incident provided executive air cover. Pre-incident, the IT team had repeatedly proposed tier separation and been declined for being “too disruptive”. Post-incident, the proposal moved forward in days. We name this dynamic explicitly in our hardening proposals now — sometimes the right answer is to do the work before the incident forces it.
How do you handle gMSA for services that do not support managed service accounts?
32-character random passwords stored in a privileged access vault, rotated on a documented cadence (90 days for non-internet-facing, 30 days for higher-risk services). The password is fetched programmatically by the service; no human ever sees it.
Did Conditional Access break anyone's workflow?
Briefly. One field-services manager travelled internationally without notifying IT; his admin actions were blocked from a non-corporate IP. We added a documented “travel exception” workflow with 24-hour expiry. Net: one inconvenience, zero compromises.
How do you keep this from drifting back over 2 years?
We left the client with a quarterly self-audit checklist (privileged group membership, dormant accounts, conditional-access exception log) and we run an external review yearly. Drift is the default state of any AD; only periodic review keeps it tight.
Active Directory Hardening as a Continuous Operation
Active Directory hardening is not a 90-day engagement that ends. AD drifts: privileged-group membership grows, dormant accounts re-accumulate, conditional-access exceptions accrete. Active Directory hardening as a continuous operation means quarterly self-audits, half-yearly external review, and a one-page Active Directory hardening dashboard the IT team checks weekly. The clients we work with who run Active Directory hardening as a discipline see zero successful sprays year over year; the clients who treat it as a project pay us to come back after the next incident.
Further reading: VITI Security cybersecurity services · Microsoft AD tier model.
Need help on something like this? VITI Security works with operators, BPOs, and SMBs across India and abroad.
Get an AD Hardening Review


