When ransomware encrypts every computer in a company at once, the key step is often that the attackers took Active Directory (AD) first. AD is the account and permission hub of most corporate networks; the Canadian Centre for Cyber Security notes that once AD is compromised, threat actors can gain privileged access to all of the systems and users it manages[1]. CISA likewise says that compromising AD often equates to compromising the entire enterprise, letting attackers escalate privileges, move laterally, establish persistence and, in many cases, gain broad control of cloud resources too[2]. Once attackers hold domain admin rights, one common move is to push the ransomware to every computer at once through Group Policy (GPO): MITRE ATT&CK records that LockBit 2.0 can modify Group Policy to disable Windows Defender and automatically infect devices in a domain, that Prestige ransomware was deployed using the Default Domain Group Policy Object on a domain controller, and that Qilin has pushed a scheduled task through a GPO to execute its payload[3]. For the full attack chain, see How ransomware gets into a company.

This article is for IT staff at small and mid-size companies who run on-premises AD (often synchronized with Microsoft Entra ID) without a dedicated identity team. It starts with the common attack techniques described in joint guidance from several national cyber security agencies, then covers hardening based on Microsoft's own documentation, the events worth monitoring and the assessment tools available, and ends with a priority order for a team with limited time.

How attackers take AD: the techniques in the joint guidance

"Detecting and Mitigating Active Directory Compromises" was released by the Australian Signals Directorate's Australian Cyber Security Centre (ASD's ACSC) together with the US CISA and NSA, the Canadian Centre for Cyber Security, and the UK and New Zealand National Cyber Security Centres[1]. It was first published in September 2024 and updated on 15 September 2026, when its sections on detecting DCSync and on Shadow Credentials were expanded[2]. The techniques it covers include Kerberoasting, AS-REP roasting, password spraying, MachineAccountQuota, unconstrained delegation, passwords in Group Policy, Active Directory Certificate Services (AD CS), Golden Certificate, DCSync, dumping ntds.dit, Golden Ticket, Silver Ticket, Golden SAML, Microsoft Entra Connect, one-way domain trust bypass, SID History, Skeleton Key and Shadow Credentials[1]. Here are several of them, with how they work and the main countermeasures:

  • Kerberoasting: any account holding a valid ticket-granting ticket (TGT) can ask a domain controller for a service ticket for any service account (an account with an SPN); if the ticket uses RC4, part of it is encrypted with the service account's password hash, which the attacker can take away and brute-force offline[4]. Countermeasures: use AES rather than RC4 where possible; give service accounts passwords of ideally 25+ characters that are changed periodically, or switch to group Managed Service Accounts (gMSA); give service accounts only the privileges they need and keep them out of privileged groups such as Domain Admins[4].
  • AS-REP roasting: Kerberos preauthentication is enabled by default; if an account is set to "Do not require Kerberos preauthentication", an attacker can obtain data that may be encrypted with a weak algorithm such as RC4 without knowing the password, then crack it offline[5]. The countermeasures are to keep preauthentication enabled on all accounts wherever possible, audit changes to that setting, and likewise use AES and long passwords[5].
  • Password spraying: trying one or a few common passwords against many accounts, so no single account fails often enough to trigger a lockout[6]. The countermeasures are MFA, a lockout threshold for failed sign-ins, and a password policy based on NIST guidance[6]. For password rules see How to set a password policy; for choosing MFA see the MFA rollout guide.
  • DCSync: the attacker poses as a domain controller and uses the domain controller replication API to request a "sync" of account data; the password data it pulls may include current and historical hashes of accounts such as KRBTGT and administrators, and members of Administrators, Domain Admins and Enterprise Admins, as well as domain controller computer accounts, can run it[7]. The countermeasure is to manage the access control list for "Replicating Directory Changes" and related replication permissions, so only the right principals hold them[7].
  • Golden Ticket: an attacker who obtains the KRBTGT account's password hash (usually dumped after gaining privileged access to a domain controller) can forge a TGT for any account in AD[8]. The countermeasures are to limit domain admin accounts to domain controllers and a few servers, delegating other admin work to separate accounts, and, if the hash may have leaked, to reset the KRBTGT password twice so existing forged tickets stop working[8].
  • Active Directory Certificate Services (AD CS): certificates issued by AD CS can be used as sign-in credentials; a certificate's subject alternative name (SAN) records its owner's alternate names, and misconfigured templates or enrollment permissions can let an attacker escalate privileges[9]. MITRE recommends treating CA servers as Tier 0 assets, auditing overly permissive templates and enrollment permissions, disabling SAN use in authentication to enforce strict user mappings or requiring CA certificate manager approval for templates that include a SAN, and properly protecting certificates and private keys[9].

Separate privilege first: access model, dedicated accounts and admin workstations

The enterprise access model: lower levels must not control higher ones

Microsoft uses the "enterprise access model" to show where privileged access sits in overall access control. It evolved from the older AD tier model (Tier 0/1/2), which covered on-premises AD only: Tier 0 has expanded into the "control plane", covering all aspects of access control; Tier 1 is split into the "management plane" for enterprise-wide IT management and the "data/workload plane" for individual systems; Tier 2 is split into "user access" and "app access"[10]. The core principle is to enforce the hierarchy so that lower planes cannot take control of higher ones[10]. For a small company, the most practical first step is to draw your own control plane: domain controllers, AD CS, the Entra Connect server, and the accounts and computers that can administer them all need the highest level of protection.

Keep admin accounts separate from daily accounts

Every administrator needs at least two accounts: a normal one for email, browsing and daily work, and a dedicated one used only for administration that never reads email or browses the web. Microsoft's hardening guidance for Entra Connect puts it plainly: everyone with privileged access should have a dedicated account, and administrators should not browse the web, check email or do day-to-day productivity work with highly privileged accounts[11]. Domain admin accounts should also be limited to domain controllers and a few servers, not used to sign in to ordinary workstations[8].

Privileged access workstations (PAWs)

An attacker who controls a computer can impersonate the accounts that sign in to it or steal their credentials, so the computer used to manage privileged systems must itself be clean[12]. Microsoft defines three device security levels: enterprise, specialized and privileged. A privileged access workstation restricts local admin rights and which applications can run, denies web traffic by default except for a short list of permitted destinations, and blocks email and general web browsing, the two most common phishing vectors, so separate accounts and computers must be provided for everyday work[12]. On a tight budget, at least set aside one dedicated computer that is used only to manage AD and never for email or browsing.

The Protected Users group

When you add the human accounts of domain admins and other highly privileged users to the Protected Users group, Windows applies protections that cannot be changed: on the device, plaintext credentials and NTLM hashes are no longer cached, Kerberos stops creating DES or RC4 keys, and offline sign-in is no longer supported; on the domain controller, these accounts cannot use NTLM authentication, cannot use DES or RC4 in preauthentication, cannot be delegated, and their TGTs are fixed at a four-hour lifetime[13]. The domain functional level must be at least Windows Server 2012 R2; never add service or computer accounts; and test before adding highly privileged accounts so you do not lock yourself out[13].

Close default gaps: LAPS, gMSA, krbtgt, NTLM and Entra Connect

Windows LAPS: a different local admin password on every computer

Local administrator accounts often share the same password across many devices, so an attacker who gets one can move laterally to the rest; Windows LAPS regularly rotates each device's local administrator password, backs it up to AD or Microsoft Entra ID, and can also manage the DSRM account password on domain controllers[14]. It is a built-in Windows feature that needs no separate download or installation and is available at no cost on all supported Windows platforms: it is included in Windows 11 23H2 and Windows Server 2025 and later, and earlier Windows 10, Windows 11, Windows Server 2019 and 2022 got it from the 11 April 2023 Windows update (Windows 10 reached end of support on 14 October 2025, so only devices still receiving updates have it)[14]. The legacy Microsoft LAPS product is deprecated as of Windows 11 23H2 and newer versions block its installer; with Windows LAPS backing up to AD you can also turn on password encryption and password history[14].

gMSA: let Windows handle service account passwords

Kerberoasting cracks service account passwords, so how those passwords are generated and how often they change matters most. With a gMSA, Windows manages the password: the domain controller computes it from keys supplied by the Key Distribution Service, the keys change periodically, and no administrator has to handle it; one gMSA can be shared by the same service across several servers, it works with Windows Server 2012 and later, and Microsoft says to always configure AES for it[15]. Service accounts that really cannot move to gMSA should at least get passwords of 25 or more characters and be removed from privileged groups[4].

The krbtgt password: reset it twice, at least 10 hours apart

Microsoft explains that the krbtgt account's password history value is 2, so it keeps the two most recent passwords, and you must reset it twice to clear the old ones completely[16]. Wait at least 10 hours between the two resets, which is the default maximum lifetime for user and service tickets; if you have changed those settings, wait longer than the configured value[16]. The password you type does not matter, because the system generates a strong password automatically[16]. MITRE also suggests considering rotating the KRBTGT password every 180 days[8]. For when to reset it during an incident, and in what order relative to other accounts, see The first 24 hours of a suspected breach.

Reduce NTLM and LLMNR

Microsoft now classifies NTLM as deprecated and in January 2026 published a phased plan to switch it off: phase one provides enhanced NTLM auditing on Windows Server 2025 and Windows 11 24H2 and later, showing where and why NTLM is still used; phase two adds features that cut down fallback to NTLM; only in the next major Windows Server release and the associated client releases will network NTLM be disabled by default, and even then it stays in the OS and can be re-enabled by policy[17]. Since default disablement is scheduled for the next major release, what to do now is turn on auditing, map the applications that depend on NTLM, move critical workloads to Kerberos, and test NTLM-off configurations outside production[17]. The LLMNR risk is that an attacker on the internal network answers LLMNR, NBT-NS or mDNS name queries, poses as the requested host, and tricks computers into sending authentication material it can collect or relay; MITRE recommends disabling LLMNR, mDNS and NetBIOS through Group Policy where they are not needed, and enabling SMB signing to stop NTLMv2 relay attacks[18].

The Entra Connect server belongs to the control plane

The Entra Connect server that synchronizes on-premises AD with Entra ID holds critical identity data, and Microsoft requires it to be treated as a Tier 0 component and hardened as a control plane asset[11]. The reason is that an attacker who controls this server can manipulate users in Entra ID, for example by resetting their passwords[11]. Microsoft's hardening list includes restricting administrative access to domain admins or other tightly controlled groups, denying NTLM authentication on the server, enabling MFA for all privileged users, disabling soft matching and hard match takeover when not needed, and using Windows LAPS and dedicated privileged access workstations[11]. Microsoft also requires Entra Connect Sync to be upgraded to version 2.6.84.0 or later with application-based authentication configured by 7 April 2027, or synchronization will stop working[11]. For cloud admin account settings, see Microsoft 365 and Google Workspace security baselines.

Monitoring and regular checks

Events to watch on domain controllers

  • 4769 (Kerberos service ticket requested): service tickets with RC4 encryption (encryption type 0x17), or one account requesting an unusual number of service tickets in a short time, are Kerberoasting signals[4].
  • 4768 (Kerberos TGT requested): requests with preauthentication type 0 mean an account has preauthentication disabled and may indicate AS-REP roasting; heavy enumeration of accounts set to "Do not require Kerberos preauthentication" also deserves attention[5].
  • The pattern of failed sign-ins: many different accounts failing with the same password, or a small set of passwords, in a short time is the classic sign of password spraying[6]. Attackers also switch to LDAP and Kerberos attempts because these are less likely to trigger the Windows logon failure event 4625 commonly raised by failed SMB connections, so watching 4625 alone will miss them[6].
  • 4662 (an operation was performed on an object): used to detect DCSync. Legitimate directory replication only comes from known domain controllers, so any replication operation from another computer should be investigated[19].
  • Privileged group membership changes and new or re-enabled accounts: especially Domain Admins, Enterprise Admins and Administrators; any change without a matching change ticket is worth running down the same day.

Make sure the domain controllers' audit policy actually generates these events, and forward them to a central store that an attacker with domain admin rights cannot delete; for which logs to collect and how long to keep them, see What to log and how long to keep it.

Assessment tools: see your own AD clearly

  • Microsoft Defender for Identity: sensors installed on your identity infrastructure capture and parse network traffic and Windows events locally and send them to a cloud service for analysis; it provides identity security posture assessments through Microsoft Secure Score and lateral movement path analysis, and detects reconnaissance, credential compromise attempts such as brute force, lateral movement, and domain dominance behavior such as malicious domain controller replication and Golden Ticket activity[20].
  • PingCastle: an assessment tool for AD and Entra ID security posture that produces a consolidated risk indicators report and an AD map, and uses a maturity evaluation to give management and operations a common vocabulary; it was acquired by Netwrix in 2024 and offers a free Community Edition alongside paid editions[21].
  • BloodHound Community Edition: maintained by SpecterOps and released under the Apache 2.0 license, it uses graph theory to reveal hidden and often unintended relationships in identity and access management systems, supports AD and Azure environments, and is fed by the SharpHound and AzureHound data collectors[22].

The three serve different purposes: Defender for Identity is a continuous monitoring and detection service, while PingCastle and BloodHound CE suit periodic runs to find configuration weaknesses and attack paths. Before running them in your own environment, get written authorization and tell whoever monitors the network, so the activity does not trigger alerts or get mistaken for an attack. If the high-risk findings are more than your team can handle, consider a security health check.

Action checklist

With limited staff, work in this order; the first four items mostly need no extra budget:

  1. List the members of Domain Admins, Enterprise Admins, Administrators and other privileged groups, remove accounts that do not need to be there, and confirm no service accounts are among them.
  2. Create a dedicated admin account for each administrator and take daily accounts out of privileged groups; domain admin accounts sign in only to domain controllers and dedicated admin computers.
  3. Deploy the LAPS built into Windows so every computer has a different local administrator password.
  4. Run PingCastle or BloodHound CE once and fix these first: accounts without preauthentication, service accounts whose passwords have not changed in years, and overly permissive AD CS templates and replication permissions.
  5. Turn on and centrally retain events 4768, 4769, 4662 and failed sign-ins, and set real-time alerts for privileged group changes.
  6. Move service accounts to gMSA step by step; for those that cannot move yet, set passwords of 25+ characters and use AES.
  7. Test Protected Users with one domain admin account first; if nothing breaks, add every administrator's human account.
  8. Turn on NTLM auditing to find dependent systems; once you know nothing breaks, disable LLMNR and NetBIOS through Group Policy and enable SMB signing.
  9. Treat the Entra Connect server, AD CS and domain controllers as the control plane, managed only from dedicated admin computers; make sure Entra Connect Sync is upgraded before 7 April 2027.
  10. Write down the procedure for resetting krbtgt twice (at least 10 hours apart) and add it to regular maintenance; in a suspected compromise, follow the order in the first 24 hours guide.