Active Directory Hardening: Critical Case

Active Directory hardening — Cyber insurance readiness — lead-Firewall-_scale_security

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.

WordPress incident response — Bug bounty challenges — VITI-VanGuard
Industry: Logistics — domestic freight + warehousing
Scale: 350 employees, AD with 612 user accounts and 47 service accounts, 14 domain controllers across 3 sites
Services: Incident response, AD tier model implementation, Defender for Identity, conditional access
Duration: 90 days
Region: India (head office + 2 regional centres)
Outcome: Zero successful sprays in 12 months; 287 dormant accounts disabled; MFA on every admin

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

What do you think?

Related articles

Contact us

Partner with Us for Comprehensive IT

We’re happy to answer any questions you may have and help you determine which of our services best fit your needs.

Your benefits:
What happens next?
1

We Schedule a call at your convenience 

2

We do a discovery and consulting meting 

3

We prepare a proposal 

Schedule a Free Consultation