Active Directory (AD) is a central identity and access management service in many Windows enterprise environments. Because it controls authentication, group membership, permissions, and access to domain resources, weaknesses in AD can allow attackers to move from a compromised workstation to highly privileged accounts. Common attack paths include credential theft, Kerberoasting, abuse of excessive permissions, NTLM relay, misconfigured delegation, and Group Policy abuse. Defending AD requires least privilege, strong authentication, secure configuration, tiered administration, continuous monitoring, and regular assessment of identity relationships.
An employee signs in to a corporate workstation using their domain account. They access shared folders, internal applications, and other resources without entering separate credentials for every service.
Behind this familiar experience, Active Directory maintains identities, group memberships, authentication information, and access relationships across the organisation.
This central role makes AD a valuable target.
If an attacker compromises an ordinary domain user, they may attempt to discover other accounts, identify systems with weak configurations, obtain additional credentials, or exploit excessive permissions. In some environments, these weaknesses can create a path toward domain administrator privileges.
The risk is not limited to a single vulnerable server. Active Directory security depends on relationships between users, computers, service accounts, groups, authentication protocols, delegated permissions, and administrative systems.
An AD attack path is a sequence of weaknesses or permissions that an attacker can combine to reach a more valuable identity or resource.
Understanding these paths helps defenders identify the conditions that allow an initial compromise to become a domain-wide incident.
A typical Active Directory Domain Services (AD DS) environment may include:
Domain controllers: Servers that provide directory services and support domain authentication.
Domain users and groups: Identities and collections of identities used for access control.
Computer accounts: Represent domain-joined computers.
Service accounts: Identities used by applications and services.
Group Policy: A mechanism for managing Windows configuration and security settings.
Organizational Units (OUs): Containers used to organise directory objects and apply delegated administration or policy.
Kerberos and NTLM: Authentication protocols used in Windows environments, depending on configuration and compatibility requirements.
Trust relationships: Relationships that can allow authentication or resource access across domains or forests.
Security weaknesses in these components can combine in unexpected ways. For example, a standard user may have no direct administrative access but could still reach a privileged account through a chain of excessive permissions, vulnerable service accounts, or misconfigured delegation.
Defenders should therefore examine both individual settings and the relationships between identities and resources.
Kerberoasting targets service accounts associated with Service Principal Names (SPNs).
In Kerberos environments, an authenticated domain user can request a service ticket for a service associated with an SPN. Depending on the encryption type and configuration, the ticket may provide material that an attacker can attempt to crack offline to recover the service account's password.
The primary risk is often a service account protected by a weak or reused password. If the account also has excessive privileges, successful password recovery can provide a route to further access.
Defensive measures:
Use long, random passwords for service accounts where managed service accounts are not suitable.
Prefer group Managed Service Accounts (gMSAs) when supported by the application.
Remove unnecessary privileges from service identities.
Review accounts associated with SPNs.
Monitor unusual Kerberos service-ticket requests and investigate them alongside other evidence.
SOC investigation: Windows Security Event ID 4769 records Kerberos service-ticket operations when the relevant auditing is available. Unusual request patterns, encryption types, account context, and surrounding activity may support an investigation, but a single event does not prove Kerberoasting.
MITRE ATT&CK: Steal or Forge Kerberos Tickets: Kerberoasting (T1558.003).
Pass the Hash is an authentication technique in which an attacker uses a captured password hash to authenticate to systems or services that accept the relevant NTLM authentication flow, without first recovering the original plaintext password.
This can be especially damaging when local administrator credentials are reused across multiple computers or when an attacker obtains credentials from a privileged system.
A compromised workstation may become a stepping stone to other systems if the same administrative credentials are accepted elsewhere.
Defensive measures:
Reduce NTLM usage where operationally feasible.
Use unique local administrator passwords with Windows LAPS or an equivalent managed solution.
Limit administrative privileges on user workstations.
Avoid routine use of privileged domain accounts on lower-trust systems.
Monitor unusual NTLM authentication and remote logons.
SOC investigation: Correlate authentication events with source and destination systems, account privileges, logon type, and process activity. Windows Security Event IDs 4624 and 4625 can help identify successful and failed logons; their presence alone does not establish Pass the Hash.
MITRE ATT&CK: Use Alternate Authentication Material: Pass the Hash (T1550.002).
Kerberos tickets allow users and services to authenticate without repeatedly supplying their passwords. If an attacker obtains a valid ticket from a compromised system, they may be able to reuse it within its validity and access scope.
The impact depends on the ticket type, privileges, target service, and surrounding controls.
Defensive measures:
Protect privileged sessions and restrict where administrative accounts can log in.
Use separate administrative accounts and hardened management workstations.
Apply appropriate credential protections.
Monitor unusual Kerberos ticket use and authentication patterns.
Investigate unexpected access to sensitive services.
SOC investigation: Review Kerberos ticket-related events alongside logon records, process telemetry, account context, and activity on the target service. Windows Security Event IDs 4768 and 4769 can provide useful context, but they do not by themselves prove ticket theft or reuse.
MITRE ATT&CK: Use Alternate Authentication Material: Pass the Ticket (T1550.003).
NTLM relay attacks exploit authentication flows in which an attacker can relay authentication material to another service. Under the right conditions, the target service may accept the relayed authentication and grant access as the victim identity.
Relay opportunities can arise when legacy authentication remains enabled and protections such as SMB signing, Extended Protection for Authentication, or appropriate channel binding are missing where required.
A successful relay does not necessarily require the attacker to recover the victim's password.
Defensive measures:
Reduce or disable NTLM where feasible.
Enforce SMB signing where appropriate.
Enable Extended Protection for Authentication on supported services.
Configure channel binding for applicable protocols and services.
Review and restrict unnecessary authentication exposure.
Monitor suspicious authentication patterns and unexpected access to sensitive services.
SOC investigation: Correlate NTLM authentication, network connections, service access, and account activity. Investigate unexpected authentication from workstations to servers that do not normally interact.
MITRE ATT&CK: Adversary-in-the-Middle: LLMNR/NBT-NS Poisoning and SMB Relay (T1557.001) may be relevant when the observed behaviour matches that technique. Not every NTLM relay scenario maps to this sub-technique.
DCSync abuses directory replication permissions to request replication data from a domain controller. An attacker with sufficient directory replication rights may be able to obtain sensitive credential material without directly extracting it from the domain controller's memory.
This is particularly dangerous because the permissions required for replication are legitimate capabilities used by domain controllers and certain directory-management services.
An ordinary domain user should not generally possess these rights without a clear, approved business requirement.
Defensive measures:
Restrict directory replication permissions to trusted, necessary identities.
Review privileged ACLs and delegated permissions.
Monitor changes to replication-related rights.
Investigate unexpected directory replication activity.
Protect privileged credentials and administrative systems.
SOC investigation: Examine directory-service access auditing, replication-related activity, account privileges, and changes to directory permissions. Relevant telemetry depends on audit configuration and environment. Investigate replication requests from unexpected systems or identities rather than treating normal domain-controller replication as suspicious by default.
MITRE ATT&CK: Steal or Forge Kerberos Tickets: DCSync (T1003.006).
Group Policy allows administrators to manage security settings, scripts, software deployment, and configuration across domain-joined systems.
An attacker who obtains inappropriate rights to modify a Group Policy Object (GPO), its linked settings, or associated files may be able to change configurations across many computers within its scope.
The impact depends on the GPO's permissions, links, settings, and the systems that apply it.
Defensive measures:
Restrict GPO modification and linking permissions.
Review delegated rights on Group Policy Objects.
Monitor changes to important GPOs and their associated files.
Protect administrative workstations and privileged accounts.
Maintain change records and validate unexpected policy changes.
SOC investigation: Identify the modified policy, the actor, the affected scope, and the resulting configuration changes. Determine whether the activity was authorised and whether endpoints subsequently applied the policy.
Active Directory uses access control lists (ACLs) to determine which identities can modify directory objects and perform specific actions.
Misconfigured permissions may allow a low-privilege identity to change another account, modify a group, alter a computer object, or affect other security-relevant directory attributes.
These permissions can create indirect paths to privilege escalation even when the initial account has no obvious administrative role.
For example, a user who can modify membership of a privileged group may be able to gain elevated access if the permission is not intended and the change is accepted.
Defensive measures:
Audit privileged groups and directory-object ACLs.
Remove unnecessary delegated permissions.
Review rights that permit account or group modification.
Monitor privileged group membership changes.
Use a documented approval process for directory permission changes.
SOC investigation: Establish which object was modified, which identity performed the action, what permissions allowed it, and whether the resulting access was used.
Kerberos delegation enables services to access other resources on behalf of users in approved scenarios. Poorly configured delegation can expand the impact of a compromised service or computer account.
Unconstrained delegation can be especially risky because of the way credentials and tickets may become available to a delegated system. Constrained delegation and resource-based constrained delegation can also introduce risk if their configuration or permissions are abused.
Defensive measures:
Review systems configured for delegation.
Remove unconstrained delegation where it is not required.
Prefer appropriately restricted delegation models.
Protect accounts and computers that require delegation.
Audit changes to delegation-related attributes and permissions.
SOC investigation: Review delegation settings, changes to directory attributes, service-account privileges, and suspicious ticket activity. A delegation configuration is not automatically malicious; investigators must determine whether it is necessary and securely implemented.
Password spraying involves attempting a small number of likely passwords across multiple accounts rather than making many attempts against one account. This can help attackers avoid simplistic per-account thresholds.
If successful, the compromised account may become an entry point for further Active Directory discovery and privilege escalation.
Defensive measures:
Enforce MFA where supported, especially for remote and privileged access.
Use strong password policies and compromised-password protections.
Monitor failed authentication patterns across many accounts.
Apply suitable rate limits and account-protection controls.
Investigate unusual successful logons following repeated failures.
SOC investigation: Correlate failed and successful logons by source, account, device, and time window. Windows Security Event ID 4625 can show failed logons, while 4624 records successful logons. Neither event alone confirms password spraying.
MITRE ATT&CK: Brute Force: Password Spraying (T1110.003).
A domain compromise often results from several weaknesses combined rather than one isolated vulnerability.
Consider this hypothetical sequence:
An attacker compromises an ordinary employee workstation through phishing.
The attacker obtains access to a domain account or local credentials.
Excessive local administrator access or credential reuse allows movement to another system.
The attacker discovers a service account with weak credential protection.
The service account has unnecessary access to sensitive systems.
The attacker uses that access to reach additional resources or privileged identities.
Each step depends on the environment and the evidence available. This example is not a claim that every intrusion follows the same sequence.
Defenders should identify the earliest point where the chain could have been interrupted. MFA may reduce some account-compromise opportunities, unique local administrator passwords can limit credential reuse, and least-privilege service accounts can prevent an initial foothold from becoming a broader compromise.
Active Directory investigations depend on the telemetry enabled in the environment. Centralise relevant events and retain sufficient context to correlate authentication, directory changes, and endpoint activity.
Windows Event IDSecurity relevance4624Successful logon4625Failed logon4672Special privileges assigned to a new logon4768Kerberos authentication ticket (TGT) requested4769Kerberos service ticket requested4771Kerberos pre-authentication failed4776NTLM credential validation4720User account created4728 / 4732 / 4756Member added to a security group, depending on group scope4739Domain policy changed4742Computer account changed5136Directory service object modified, when appropriate auditing is enabled4662An operation was performed on a directory service object, when appropriate auditing is enabledEvent availability and details depend on audit policies, Windows versions, directory configuration, and collection settings. Some activities require additional directory-service auditing to generate useful records.
A SOC detection can alert when an account is added to a sensitive group such as Domain Admins or another organisation-defined privileged group.
The investigation should determine:
Which account performed the change?
Which account was added?
Was there an approved change request?
What source device and logon session were involved?
Did the newly privileged account perform unusual actions afterward?
A group membership change is not automatically malicious. The objective is to identify unauthorised changes and connect them to the surrounding activity.
An analyst observes a spike in service-ticket requests from a workstation.
The investigation should compare the requesting identity, destination services, encryption types, normal usage patterns, and related process activity. A spike can result from legitimate application behaviour, so the detection should use baselines and additional evidence rather than a single static threshold.
Apply least privilege to users, service accounts, and administrators.
Use separate accounts for routine and privileged work.
Remove stale accounts and unnecessary group memberships.
Protect privileged credentials and reduce their exposure to lower-trust endpoints.
Use managed service accounts where suitable.
Deploy MFA for supported access paths.
Reduce reliance on NTLM where feasible.
Use strong, unique passwords for accounts that require them.
Monitor authentication failures and suspicious successful logons.
Review Kerberos and delegation configurations.
Limit interactive logons to domain controllers.
Restrict administrative access to approved management systems.
Keep domain controllers patched and securely configured.
Monitor sensitive directory changes and privileged activity.
Protect backups and recovery mechanisms.
Audit ACLs and delegated permissions.
Restrict replication rights to necessary identities.
Review privileged group membership regularly.
Protect Group Policy Objects and monitor changes.
Assess delegation, service-account, and authentication settings.
Centralise domain-controller and endpoint logs.
Correlate identity events with EDR and network telemetry.
Create detections for unusual privilege changes and authentication patterns.
Regularly assess AD attack paths using authorised tools and controlled procedures.
Maintain a tested response plan for suspected domain compromise.
When an investigation indicates that a privileged AD account or domain controller may be compromised, response must be carefully coordinated.
Validate the incident: Identify affected accounts, endpoints, domain controllers, and evidence supporting the suspected compromise.
Contain affected systems and identities: Follow established procedures to isolate compromised endpoints, disable or restrict accounts, and revoke sessions where supported.
Preserve evidence: Collect relevant authentication, directory, endpoint, and network logs before they expire or are overwritten.
Determine the attack path: Identify how the attacker gained access, which permissions were abused, and whether other systems or accounts are affected.
Remove unauthorised access: Address malicious persistence, excessive permissions, compromised credentials, and unsafe configurations.
Recover carefully: Restore trusted configurations and services, validate domain health, and follow specialist procedures for domain-controller or domain-level compromise.
Monitor for recurrence: Search for related accounts, endpoints, authentication patterns, and directory changes.
A suspected domain-level compromise may require specialist incident-response support. Resetting a single password or deleting one suspicious account may be insufficient if privileged credentials, directory replication rights, or domain-controller integrity have been affected.
Organisations often underestimate how small configuration weaknesses can combine into larger attack paths.
Common mistakes include:
Reusing local administrator passwords across endpoints.
Giving service accounts unnecessary administrative rights.
Allowing broad interactive access with privileged accounts.
Leaving legacy authentication enabled without a business requirement.
Failing to monitor changes to privileged groups and directory ACLs.
Overlooking delegation settings.
Retaining unused accounts and excessive permissions.
Relying on perimeter firewalls without controlling internal access.
Assuming that successful authentication proves the user is legitimate.
Failing to test incident-response procedures for domain compromise.
The solution is not simply to add more alerts. Organisations need to reduce unnecessary privileges, remove risky configurations, and ensure that important identity activity is visible to security teams.
Active Directory remains a critical component of many enterprise environments, which makes its identities, permissions, and authentication mechanisms attractive targets for attackers.
Kerberoasting, Pass the Hash, NTLM relay, DCSync, delegation abuse, password spraying, and excessive directory permissions can each create opportunities for compromise. The greatest risk often emerges when multiple weaknesses form a path from a low-privilege account to a sensitive resource or privileged identity.
Effective defence requires more than protecting domain controllers. Organisations must secure service accounts, restrict administrative access, review directory permissions, monitor authentication, and investigate unexpected changes to identities and policies.
For SOC analysts, the key is to correlate authentication events, directory modifications, endpoint telemetry, and privilege changes to reconstruct the attack path. Finding and closing the earliest exploitable weakness can prevent a limited endpoint compromise from escalating into a domain-wide incident.
Further Reading
Microsoft Learn: Active Directory Domain Services
Microsoft Learn: Windows LAPS
MITRE ATT&CK
CISA — Cybersecurity advisories and defensive guidance.
PingCastle — Active Directory security assessment.
BloodHound — Analysis of Active Directory and identity attack paths; use only in authorised environments.
Continue reading
Security & Defense
Command-and-control (C2) traffic enables attackers to communicate with compromised systems, issue commands, retrieve information, and deliver additional payloads. Organisations det...
Security & Defense
Zero Trust is a cybersecurity approach based on the principle of never automatically trusting a user, device, application, or network connection simply because it is inside a corpo...
Security & Defense
Endpoint Detection and Response (EDR) solutions monitor endpoint activity, analyse suspicious behaviour, detect potential cyberattacks, and support rapid incident response. By corr...
3 entries, most recent posts.
Cybersecurity researchers have uncovered an AI-assisted cybercrime operation attributed to CyberXero, a financially motivated initial access broker th...
Senior Hosting Security Engineer
The convergence of Operational Technology (OT), the Internet of Things (IoT), and traditional enterprise IT networks is transforming how organisations...
