Site icon Windows Active Directory

Monitoring lateral movement paths in AD

Arun Kumar
Monitoring Lateral Movement Paths in Active Directory

Lateral movement is what happens after an attacker (or rogue insider) gets an initial foothold: they pivot from one machine/account to another until they reach high-value targets like file servers, application tiers, and ultimately Domain Admin or Tier-0 assets. In Active Directory (AD), lateral movement succeeds not because of one “big exploit,” but because of paths: reusable credentials, delegation edges, permissive admin models, and authentication flows that quietly connect systems.

This article shows how to monitor lateral movement as paths (not isolated events): how to collect the right signals, stitch them into meaningful chains, and build detection that catches pivots early—before they reach Tier 0.

Table of contents

What you’re really monitoring (paths, not alerts)

Most teams monitor AD lateral movement like a list of suspicious events: “4624 here, 4688 there.” That creates noise. Path-based monitoring flips the model:

  • Nodes: users, service accounts, computers, servers, DCs, admin workstations, jump hosts.
  • Edges: authentications, remote executions, admin rights, delegation rights, share access, RDP/WinRM/WMI usage.
  • Paths: sequences of edges that move from low-trust to high-trust assets (e.g., user workstation → app server → management server → DC).

Practically, you want to answer questions like:

  • Which accounts are authenticating to new hosts (especially servers) today?
  • Where do privileged credentials land (interactive logons, cached creds, tokens)?
  • Which hosts are behaving like “pivot points” (lots of inbound admin auth + outbound connections)?
  • Are lateral steps happening across tiers (workstation → server, server → DC)?

If you need a refresher on the authentication mechanics that make lateral movement possible (Kerberos vs NTLM, ticketing, and where artifacts appear), start here: NTLM authentication and Kerberos Authentication Protocols Explained.

Telemetry you need (and where it lives)

You can’t monitor paths if you only collect DC logs. Lateral movement happens primarily on member servers and workstations—that’s where remote execution, token use, service creation, and interactive logons show up.

Minimum viable collection (start here)

  • Domain Controllers: Kerberos/NTLM authentication events, account changes, group membership changes.
  • Tier-0 and admin infrastructure: PAWs/jump hosts, management servers, virtualization hosts, backup servers.
  • Tier-1 servers: application and file servers that admins touch routinely.
  • Representative workstations: at least IT/admin endpoints; ideally all.

Windows logs and event IDs that matter

Authentication & credential use

  • 4624 (successful logon) — pay attention to Logon Type (3, 9, 10), Account, Source IP/Workstation.
  • 4625 (failed logon) — noisy alone; high-signal when chained to success or cross-host spray patterns.
  • 4648 (explicit credentials) — “RunAs” style usage; great for spotting credential re-use.
  • 4672 (special privileges assigned) — indicates admin-level token on the target host.
  • 4768/4769/4771 (Kerberos) — ticket requests; useful for server access and unusual service ticket patterns.
  • 4776 (NTLM auth) — essential if NTLM is still in play.

Remote execution & persistence-like steps used during movement

  • 4688 (process creation) — requires enabling audit policy; combine with command-line logging where possible.
  • 4697 (service installed) and/or 7045 (new service) — common for remote service execution patterns.
  • 5140/5145 (SMB share access / detailed file share) — admin share and tooling movement signals.
  • Scheduled tasks events (Task Scheduler operational log) — remote task creation is a frequent pivot method.

If you’re using Microsoft Defender for Identity (MDI), it can dramatically reduce time-to-signal for identity-driven lateral movement by correlating DC sensor data and identity behaviors. See: Microsoft Defender for Identity: A comprehensive overview and Event collection with Microsoft Defender for Identity.

Collection architecture tips (to avoid blind spots)

  • Centralize logs (SIEM, data lake, or MDI + SIEM). Local-only logs are “forensics after the fact.”
  • Time sync is non-negotiable. If timestamps drift, your path reconstruction fails.
  • Normalize identities: map sAMAccountName/UPN/SID consistently; service accounts often appear differently across sources.
  • Tag tiers: label hosts as Tier-0/Tier-1/workstations so detections can reason about “uphill” movement.

Building an identity + host movement graph

A path-based program needs a simple internal model:

  • Identity graph: who can administer what (local admin groups, delegated rights, remote management permissions).
  • Movement graph: who actually logged on to what, from where, and how (RDP/SMB/WinRM/WMI).

Step 1: Inventory and tier your estate

  • Classify Tier-0 (DCs, ADFS/PKI, identity infrastructure), Tier-1 (servers), Tier-2 (workstations).
  • Identify “choke points”: jump servers, patch/management systems, backup servers. These are favorite pivots.

Step 2: Map admin rights (where paths are born)

Lateral movement accelerates when admin rights sprawl. In legacy environments, “everyone is local admin somewhere” becomes a hidden motorway to Tier-0. If this sounds familiar, read: Excess Permissions: Lessons from Legacy Setups.

Practical mapping inputs:

  • Local Administrators group membership across servers and endpoints (including nested groups).
  • Remote management permissions (WinRM, RDP groups, WMI/DCOM permissions).
  • Delegation / OU and GPO rights that indirectly grant control.

For safer delegation patterns that reduce unintended paths, see: How to delegate OU permissions with minimal risk.

Step 3: Watch trust boundaries and cross-boundary pivots

If your environment has trusts (or complex multi-forest layouts), lateral paths can cross boundaries in surprising ways. Tightening and continuously verifying trust protections is part of monitoring. See: SID filtering in complex AD layouts: expert guide & runbook.

High-signal detection patterns

The goal is not “alert on everything.” It’s to catch uphill movement and credential re-use early. Below are patterns that work well in real environments when paired with baselining and tier tagging.

1) First-time (or rare) admin logon to a server

  • Signal: 4624 + 4672 on a server where that account hasn’t logged on (or hasn’t recently).
  • Boost: source is a workstation (Tier-2) and target is Tier-1 or Tier-0.
  • Interpretation: credential re-use or admin session spread.

2) “Workstation-to-many-servers” pattern (pivot host behavior)

  • Signal: one source host authenticates to many distinct servers in a short window.
  • Boost: explicit credentials (4648) or special privileges (4672) appear on multiple targets.
  • Interpretation: a compromised admin endpoint, scripted admin tooling, or an attacker enumerating paths.

3) Remote service creation / suspicious service install bursts

  • Signal: 4697 and/or 7045 on member servers, especially when preceded by 4624 Logon Type 3.
  • Boost: service is created by an unusual account or from an unusual source IP/host.
  • Interpretation: remote execution or hands-on-keyboard pivot activity.

4) Admin share access + tooling movement

  • Signal: 5140/5145 access to ADMIN$ or C$ combined with 4688 process creation shortly after.
  • Boost: repeated across multiple targets from the same source.
  • Interpretation: staging, copying tools, or remote execution workflow.

5) Kerberos/NTLM anomalies that indicate “credential hopping”

  • Signal: unusual NTLM usage (4776) in a Kerberos-heavy environment, or spikes in service ticket requests (4769) to many servers.
  • Boost: activity occurs outside the account’s normal admin window or from a new source host.
  • Interpretation: credential material being used broadly, or misconfigured apps/services being leveraged as stepping stones.

6) Cross-tier movement (the “uphill” rule)

Your highest-signal rule is simple:

  • Alert when: Tier-2 (workstation) → Tier-1 (server) → Tier-0 (identity) edges occur within the same user/session time window.
  • Why: most legitimate operations don’t “climb tiers” quickly without an approved workflow (PAW/jump host).

Baseline before you tune

  • Baseline admin logon patterns per admin team (which hosts, what hours, what methods).
  • Baseline service account authentication (which servers should ever see those accounts).
  • Baseline remote management usage (RDP vs WinRM vs tooling) so “new methods” pop.

Triage runbook: proving (or disproving) lateral movement

When an alert fires, your analysts need a repeatable way to confirm a path quickly.

Step A: Identify the “pivot edge”

  • Which account authenticated to which host?
  • From what source host/IP, and using what logon type?
  • Did the target grant admin-level token (4672)?

Step B: Expand to a path window

  • Look 30–60 minutes before and after for the same account and same source host.
  • Check for additional target hosts contacted in that window.
  • Check for explicit credential use (4648) and new processes (4688).

Step C: Validate legitimacy fast

  • Is there a change ticket, maintenance window, or known admin action matching the target?
  • Is the source host an approved admin workstation/jump host?
  • Does the account normally administer that host (baseline)?

Step D: Contain based on what the path implies

  • If source is a workstation: isolate the endpoint first (likely credential theft / token abuse).
  • If target is a pivot server: review recent inbound admin sessions and outbound connections from that server.
  • If Tier-0 touched: treat as potential domain compromise—initiate Tier-0 incident procedures.

Reducing paths while you monitor

Monitoring catches movement in progress; reducing paths makes movement harder to perform and easier to detect.

  • Enforce tiering: admin accounts only log onto systems in their tier; Tier-0 only from PAWs/jump hosts.
  • Minimize NTLM exposure: reduce where possible; track where it’s still used and why.
  • Constrain delegation: avoid broad delegation patterns that create unexpected access edges.
  • Reduce admin sprawl: shrink local admin group membership and remove stale nested groups.
  • Harden remote management: restrict WinRM/WMI/RDP to approved admin networks and hosts.
  • Protect credential landing zones: keep privileged credentials off user workstations; use just-in-time/admin workflows where possible.

The biggest win is often cultural/operational: if admins stop logging onto random servers from daily-driver laptops, lateral movement paths collapse.

Inter-linked reading that supports the program above:

Quick checklist: your first 14 days

  1. Tag Tier-0/Tier-1/Tier-2 assets in your logging/SIEM.
  2. Ensure 4624/4625/4648/4672 + relevant DC Kerberos/NTLM events are collected centrally.
  3. Enable process creation auditing (4688) on servers and admin endpoints where feasible.
  4. Create “rare admin logon” and “workstation-to-many-servers” detections.
  5. Identify and monitor pivot assets (jump hosts, management servers, backup systems).
  6. Start shrinking admin sprawl and enforcing tier-based admin workflows.

Done right, lateral movement monitoring becomes a living map: you’re not just catching attacks—you’re continuously discovering where your AD design allows “easy travel,” and closing those routes.

Exit mobile version