How Active Directory Misconfiguration Enables Lateral Movement

An attacker who compromises one Active Directory account rarely wants to remain limited to that identity or computer. They look for another system, credential or permission that moves them closer to valuable data and administrative control.

That movement does not always depend on an advanced vulnerability. It is often enabled by ordinary configuration decisions: the same local administrator password on many computers, broad server access, an administrator signing in to a lower-trust system or a service account with more rights than its application requires.

Active Directory connects users, computers, groups, policies and services. Those relationships allow an organisation to operate efficiently, but poorly controlled relationships also give an attacker routes through the environment. Lateral movement becomes possible when control of one identity or system helps compromise another.

What Lateral Movement Means in Active Directory

Lateral movement is the progression from an initially compromised account or device to other identities and systems. The next step may provide wider access, more reliable persistence or a route towards privilege escalation.

Movement and escalation often overlap, but they are not identical. An attacker might move from one employee workstation to another system without gaining greater authority. They may also move into a server where a more privileged account is active, turning access to that computer into an opportunity to obtain stronger credentials or tokens.

Active Directory supports this process because authenticated users can normally discover a substantial amount about the directory. They can identify accounts, computers, group relationships, service identities and other environmental clues. The article How Attackers Turn Ordinary Active Directory Access into Privilege explains how those individual steps form a wider attack path. This article focuses on the configuration choices that make movement between those steps possible.

Shared Local Administrator Credentials Create a Ready-Made Route

If several computers use the same local administrator account and password, compromise of one credential may grant administrative access to every system on which it is reused. The attacker does not need to compromise a separate domain account for each device.

The risk becomes more serious when the shared account is present across workstations and servers. A credential recovered from a relatively unimportant endpoint can become a route to a management server, application host or another system where more valuable identities operate.

Windows LAPS addresses this problem by managing a unique local administrator password for each covered device and controlling who can retrieve it. Deployment still requires careful policy, permission and recovery design. A unique password limits the value of one compromised local credential; it does not make an overprivileged endpoint safe.

Broad Local Administration Expands the Movement Surface

Domain groups are often added to local Administrators groups for convenience. Support teams, application administrators and infrastructure staff may receive access across whole groups of servers even though their work concerns only a subset.

Each additional administrator creates another identity that could be used to reach those systems. Each additional system also becomes somewhere those administrative credentials might be exposed. If the same account administers desktops, member servers and identity systems, compromise in one part of the estate can cross boundaries that were intended to contain it.

Review local administration by role and scope. Separate workstation support, server operations and control-plane administration. Where an occasional task requires elevation, a controlled, time-limited process reduces the need to retain wide standing rights.

Privileged Sign-Ins Connect High-Trust Accounts to Lower-Trust Systems

A well-protected administrator account can still be exposed if it is used from or used to access an inadequately protected computer. Credentials, tickets and active sessions may become available to an attacker who already controls that device.

This is why administrative separation must cover accounts, endpoints and sign-in paths. Administrators should use separate identities for routine and privileged work, and powerful accounts should be restricted from signing in to systems below their trust level. Protected administrative workstations or suitable access intermediaries provide a cleaner source for sensitive administration.

The legacy AD tier model expressed this as a rule against administering a higher tier from a lower one. Microsoft's broader Enterprise Access Model now describes control, management and data or workload planes, but the underlying principle remains useful: a lower-trust system must not be able to capture the authority used to control a higher-trust one.

Delegated Permissions Can Provide an Indirect Step Across the Directory

An account does not need to belong to Domain Admins to exert powerful control. Delegated rights may allow it to reset another user's password, change group membership, modify an object's permissions or alter an organisational unit containing sensitive identities.

These rights are easily overlooked when they are inherited, granted to a nested group or left behind after a role changes. An ordinary-looking support group can become a lateral movement route if it controls a more privileged account or another group further along the path.

Review effective control as well as direct membership. Our guide to identifying privileged accounts in Active Directory covers nested groups, delegated rights and systems that can provide hidden administrative access.

Service Accounts Can Bridge Applications and Systems

Service accounts often run across several computers, connect to databases or APIs and retain stable credentials for long periods. They may also receive local administration or directory rights because an application was difficult to configure with a narrower permission set.

A weak or exposed service-account password can therefore unlock more than one system. Kerberos service accounts with discoverable service principal names deserve particular attention where their passwords are weak or long-lived, because an authenticated user can request a service ticket and attempt to recover the password offline.

Record the owner, purpose, dependencies, permitted hosts and exact rights of each important service identity. Use Group Managed Service Accounts where supported, prevent interactive sign-in where it is unnecessary and reduce privileges to those required by the service.

Group Policy and Management Systems Can Distribute an Attacker's Reach

Group Policy, software deployment, endpoint management and remote-administration platforms are intended to make changes at scale. Control of one of those systems can give an attacker the same advantage.

A person who can edit a Group Policy Object linked to sensitive computers may be able to change their security settings or cause code to run. Administrative control of a deployment platform may enable commands or software to be delivered to many endpoints. The management system's own service accounts, servers and consoles therefore belong in the privilege review.

Protect who can edit policies, who can link them and which objects they affect. Monitor changes to sensitive GPOs and management configuration. Do not assess these systems solely by whether their operators appear in a well-known Active Directory group.

Legacy Authentication and Open Management Paths Increase Reach

Older authentication protocols and permissive network access can make stolen credentials easier to reuse. NTLM dependencies, weak protocol settings and services accepting authentication from unnecessary network locations may give an attacker more ways to reach the next system.

Remote Desktop, SMB, WinRM and other management services are legitimate operational tools. The risk lies in exposing them broadly, allowing excessive accounts to use them or failing to monitor where connections originate. Host firewalls and network controls should restrict administrative protocols to approved sources and destinations.

Reducing legacy authentication requires discovery and staged remediation. Disabling a protocol without understanding application dependencies can cause disruption; leaving it enabled indefinitely preserves an avoidable movement path. Measure actual use, identify owners and migrate or isolate systems that cannot yet be changed.

Stale Accounts and Old Computers Preserve Forgotten Paths

Dormant user and computer accounts are often treated as an identity-hygiene issue, but they can also support lateral movement. An old account may retain group membership, delegated rights or access to systems that current administrators no longer remember.

Disabled accounts still require review because their permissions and group relationships may remain. An account can be re-enabled, or its group membership may reveal how access was historically structured. Old computer accounts and unmanaged devices can also weaken trust in which systems are permitted to authenticate or receive policy.

Follow a controlled discovery and remediation process rather than deleting candidates based on one timestamp. The guide How to Find Stale Accounts in Active Directory explains how to combine inactivity, ownership and dependency evidence.

Trusts and Hybrid Identity Extend the Path Beyond One Domain

Forest and domain trusts allow identities to access resources across boundaries. Hybrid synchronisation and management connect on-premises Active Directory with Microsoft Entra ID and cloud services. Those connections should be assessed as potential movement paths in both directions.

Review the purpose, direction, authentication scope and administration of each trust. For hybrid identity, identify which systems and accounts can change synchronised identities, authentication configuration or cloud roles. Protect synchronisation and federation servers as control-plane assets rather than ordinary application servers.

A Typical Path Combines Several Modest Weaknesses

Consider an attacker who compromises an employee workstation. The user has no privileged group membership, but a support group has broad local administration across office computers. One member of that support group signs in to the compromised device to investigate a problem.

1. The attacker gains control of an ordinary workstation and user account.
2. A broadly privileged support identity signs in to the affected computer.
3. The exposed support access permits movement to a management server.
4. The management server holds a service identity with rights over a server OU.
5. A delegated permission allows policy or configuration affecting sensitive systems to change.
6. The attacker reaches a control-plane asset without initially compromising Domain Admin.

No single weakness necessarily appears critical in isolation. Broad local administration, unsafe privileged sign-in, an overprivileged service account and weak delegation become serious because they connect. Removing any one of those links may prevent the route from succeeding.

Why Conventional Reviews Often Miss Lateral Movement Paths

Separate reports may list privileged groups, local administrators, service accounts and recent logons. Each report can be accurate while the relationship between them remains invisible.

Point-in-time reviews also age quickly. A new nested group, temporary support permission or administrator sign-in can create a path after the review. Vulnerability scanning may identify weaknesses on individual hosts without showing which identities and management systems connect them.

Assess both configuration and behaviour. Configuration shows where movement may be possible; authentication and endpoint evidence shows which paths are actually being used. Repeated reviews reveal whether remediation has reduced exposure or merely moved it elsewhere.

Break the Paths at Several Points

There is no single switch that prevents lateral movement. The most effective programme removes several opportunities from the chain and watches the routes that must remain.

• Use unique, managed local administrator passwords through Windows LAPS.
• Reduce broad local administration and separate workstation, server and control-plane roles.
• Use separate administrative accounts and protected sources for privileged work.
• Restrict where powerful identities can sign in and where management protocols can connect.
• Review nested groups, delegated permissions, Group Policy rights and management platforms.
• Replace long-lived service credentials with managed identities where possible.
• Remove or isolate legacy authentication after measuring its dependencies.
• Retire stale accounts, obsolete computers and unnecessary trust relationships.
• Use time-limited elevation and controlled privileged sessions for occasional access.

Our practical guide to securing Active Directory against privilege escalation turns these principles into a sequenced control programme.

Monitor Movement as Well as Directory Change

Directory auditing can reveal group, permission and policy changes that create new paths. It does not by itself show every use of stolen credentials across endpoints and servers. Authentication, endpoint and network evidence must be brought together to identify unusual sequences.

Useful detection questions include:

• Is an account authenticating to systems it does not normally use?
• Has one identity reached several computers in an unusual period or sequence?
• Is a privileged account signing in from an unexpected or lower-trust device?
• Is a service account being used interactively or from an unapproved host?
• Did a group, ACL or GPO change shortly before new administrative activity?
• Has audit policy, endpoint protection or logging been weakened?

Identity Threat Detection & Response can help connect suspicious identity activity with directory context, while Active Directory reporting provides visibility of accounts, groups, permissions and changes. Alerts still need owners, response procedures and sufficient retained evidence to support investigation.

Containment Must Account for the Whole Path

Disabling the first compromised account may not contain an incident if the attacker has already obtained another credential, established a session or changed a delegated permission. Response should identify the accounts, endpoints and management systems touched along the route.

Preserve relevant logs, isolate affected devices and invalidate exposed credentials in a controlled order. Review newly created accounts, group changes, service configuration and persistence mechanisms. Where control-plane compromise is possible, use a prepared forest recovery and privileged-access restoration plan rather than relying solely on routine object recovery.

Where Technology Supports the Control Model

Different controls address different parts of lateral movement. Authentication controls can restrict logons and add context to suspicious access. Directory auditing can identify changes to groups, permissions and policy. Privileged access management can broker credentials, constrain administrative access and record sensitive sessions.

Armstrong's Identity Security, Identity Threat Detection & Response and Privileged Access Management capabilities address complementary parts of the problem. Product selection should follow an assessment of the actual paths in the environment: which identities are exposed, which systems they can reach and which controls are missing between them.

Final Thoughts

Lateral movement is rarely enabled by one dramatic Active Directory mistake. More often, an attacker combines several ordinary weaknesses: a reused credential, broad local administration, an unsafe privileged sign-in, an overprivileged service account or a forgotten delegated right.

The directory turns those weaknesses into a route because it connects identities, computers and administrative systems. Defenders need the same connected view. Review who can reach each system, what credentials are exposed there and where that access leads next.

By reducing shared and standing privilege, protecting administrative paths and monitoring both configuration and behaviour, organisations can make an initial compromise much harder to turn into control of the wider estate.