Detecting Lateral Movement in Active Directory: An SOC Analyst's Field Guide

Attackers rarely go straight to their target — and that progression leaves traces

When an attacker compromises an enterprise network, they rarely land exactly where they want to be. They get a foothold — a phished employee's workstation, an exposed service, a misconfigured application — and then work their way toward the things that actually matter: servers with sensitive data, backup systems, domain controllers, finance platforms.

That process of moving from system to system inside a network is called lateral movement. And in most enterprise environments, it runs through Active Directory.

What Is Active Directory and Why Do Attackers Target It?

Active Directory (AD) is the system that most Windows-based organizations use to manage who can access what. When you log into your work laptop, unlock a shared drive, or connect to an internal application, AD is checking your credentials and deciding whether to let you in. It is the central authentication backbone of the network.

That makes it extremely valuable to attackers. If you understand how AD works — and how to abuse its authentication mechanisms — you can move between systems using credentials and tickets that look completely legitimate. No obvious malware, no suspicious-looking files. Just valid-looking authentication events that blend into the noise of normal business activity.

This is what makes lateral movement through AD so difficult to catch: attackers are not breaking the system. They are using it — just in ways the legitimate user never intended.

The Three Things Analysts Should Understand

1. Attackers use real credentials, not just malware

A common misconception is that detecting an intrusion means detecting malware. In many modern intrusions, the most dangerous phase involves no malware at all. Once an attacker extracts a password hash from a compromised machine's memory, they can use that hash to authenticate as the victim user — without ever knowing the actual password.

This technique is called Pass-the-Hash. The attacker is not guessing or cracking the password — they are presenting a stolen key that Windows accepts as valid. From the system's perspective, it looks like a normal login.

A similar technique, Pass-the-Ticket, does the same thing with Kerberos authentication tickets. Think of a Kerberos ticket like a concert wristband — it proves you already cleared the entrance check, so you can move freely inside without showing ID again. If an attacker steals that wristband, they can use it to access systems as you.

2. Behavior and context matter more than individual events

A single login event from a user's account tells you almost nothing on its own. Context is what makes events meaningful.

A user logging into their workstation is normal. That same user's account suddenly authenticating to five different servers they have never accessed — at 2am, from a different machine — is not. Neither individual fact is alarming by itself. Together, they tell a story.

This is why lateral movement detection depends on establishing baselines. Analysts need to understand what normal looks like for users, accounts, and systems before they can reliably identify what is abnormal. Without that context, the noise of a large enterprise environment makes meaningful signals very hard to separate from routine activity.

3. The trail exists — if you have the right logs

Lateral movement leaves evidence. Authentication events, remote connections, process activity — it all gets recorded somewhere. The catch is that Windows does not log everything by default, and many organizations have not configured their systems to capture the events that matter most.

For example, detecting Pass-the-Hash reliably requires logs that show how a user authenticated — specifically, whether they used NTLM (the older authentication protocol more vulnerable to this attack) versus Kerberos. That detail is available in Windows event logs, but only if the right audit policies are enabled and those logs are being forwarded to a central SIEM.

This is one of the most common gaps in SOC detection capability. The data exists — but it was never collected.

What to Actually Watch For

Rather than a checklist of event IDs, here are the behavioral patterns that should prompt an analyst to investigate further:

Authentication from unexpected locations. A user account logging into systems it has never accessed before — particularly servers or domain controllers.
High-volume service ticket requests in a short window. A technique called Kerberoasting involves requesting authentication tickets for many different services very quickly, attempting to crack them offline. A spike in these requests from a single account is a meaningful signal.
Lateral tool execution on endpoints. Attackers commonly use built-in Windows tools — remote management utilities, scripting environments — to execute commands on remote systems after moving laterally. Processes spawned by these tools on machines the user doesn't normally administer warrant scrutiny.
Replication activity from non-server hosts. Domain controllers replicate data with each other as a normal function. Replication requests originating from a regular workstation are not normal and may indicate a technique called DCSync, where an attacker impersonates a domain controller to extract password data.

CyopScape Lab Note

Reading a Suspicious Authentication Event

This example is for educational purposes. The goal is to illustrate what an analyst should notice — not to provide attack tooling or guidance.

When reviewing authentication logs, the fields that matter most are not just who logged in — but how, from where, and to what. A simplified example of what a suspicious NTLM authentication might look like in a Windows Security log:

Windows Security Event (simplified)

Event ID:        4624 (Successful Logon)
Account Name:    j.harris
Logon Type:      3 (Network)
Auth Package:    NTLM
Source IP:       10.0.4.87
Target System:   FINANCESERVER01
Time:            03:14 AM

On its own, this might look routine. But an analyst should ask:

Does j.harris normally access FINANCESERVER01?
Is 10.0.4.87 their usual workstation?
Why is this happening at 3am?
Why NTLM — does this user's environment typically use Kerberos?

None of these questions alone close the case, but each one either builds or reduces confidence that something suspicious is happening. Investigation is about accumulating context — not waiting for a single definitive indicator.

What Good Detection Looks Like

Effective lateral movement detection is not about catching every technique the moment it happens. It is about having enough visibility that when an attacker progresses through an environment, they leave a trail that analysts can follow.

That requires three things working together:

The right log sources. Windows Advanced Audit Policies need to be configured. Logs from domain controllers, servers, and endpoints all need to flow into a central location. Gaps in log collection are gaps in detection.
A baseline of normal behavior. Without knowing what normal looks like for your environment, alert thresholds are guesswork. Baselining takes time but is what turns raw telemetry into actionable detection.
Detection rules that look for behavior, not just signatures. A rule that fires on a specific tool name will miss the same technique carried out with a different tool. Rules built around behavioral patterns — authentication anomalies, unusual access sequences, out-of-hours activity — are more durable.

Defensive Takeaways

Understand authentication before trying to detect abuse of it

If you are newer to SOC work, invest time in understanding how NTLM and Kerberos authentication actually work. You cannot reliably detect Pass-the-Hash or Pass-the-Ticket if you do not know what normal authentication looks like in the logs.

Ask "is this normal for this account?" before closing an alert

Lateral movement blends in. Before dismissing an authentication event as benign, check whether the account, source system, target system, and time of day are all consistent with that user's typical behavior.

Push for better logging in your environment

If your SOC cannot answer basic questions about authentication patterns — which protocol was used, from which source, to which target — the logging configuration needs attention. Detection engineering and log architecture are closely linked.

Lateral movement rarely happens once

When you find a suspicious authentication event, look for the pattern around it — not just the single event. Attackers move methodically. One anomalous login is often the middle of a sequence, not the beginning.

Final Thoughts

Lateral movement through Active Directory is not exotic. It is one of the most consistent and well-documented patterns in enterprise intrusions, used by everyone from opportunistic threat actors to sophisticated nation-state groups. The techniques are not secret — they are documented, studied, and regularly observed in the wild.

What separates organizations that catch it from those that do not is usually not detection sophistication — it is foundational visibility. The right logs, the right baselines, and analysts who know what questions to ask when something looks slightly off.

For junior analysts and students, the most valuable thing you can do is understand the underlying concepts before reaching for tools or rule libraries. Know how authentication works. Know what a normal login looks like. Then the abnormal ones become much easier to spot.

← Back to Insights