Spotting lateral movement in Windows logs and east-west traffic

The first machine an intruder lands on is rarely the one they want. A phished laptop or an exposed server is a doorway; what they are after (the directory, the file shares, the database, the backups) usually sits somewhere else. Getting from the doorway to the target means moving between systems, and that movement leaves traces in places defenders already collect: logon events, firewall logs, flow records.

This post is a field guide for that middle stretch. It stays on the defender's side throughout: what lateral movement is at the concept level, which signals show up in Windows authentication logs and in network traffic, which controls make the movement harder in the first place, and how to turn all of it into alerts your team can live with. There are no attack procedures here, only the things you can watch for and build.

What lateral movement means

MITRE ATT&CK lists Lateral Movement as tactic TA0008 and sums up the adversary's goal in one line: they are "trying to move through your environment." The tactic page explains that reaching the real objective often means exploring the network and then pivoting through multiple systems and accounts, and it lists nine techniques under the tactic, from Exploitation of Remote Services to Use Alternate Authentication Material (MITRE ATT&CK, TA0008).

The sentence on that page that matters most to a defender is the last one: adversaries might bring their own remote access tools, or they might use legitimate credentials with the network and operating system tools that are already there, which "may be stealthier" (TA0008). The Remote Services technique (T1021) covers exactly that: logging in with valid accounts to a service that accepts remote connections, such as telnet, SSH or VNC, then acting as that user. Its sub-techniques include Remote Desktop Protocol, SMB/Windows Admin Shares and Windows Remote Management.

That is why lateral movement is hard to catch with signatures. A joint CISA, NSA and FBI advisory about a state-sponsored group that relied on these "living off the land" methods notes that, because the activity blends into normal administration, conventional indicators of compromise are generally lacking, and it frames its guidance around behaviour analytics, anomaly detection and proactive hunting instead (CISA AA24-038A).

The practical consequence: you are rarely looking for a bad file. You are looking for a normal action done by the wrong account, from the wrong machine, at the wrong time, or over a path that should not exist.

How to read this guide

Each signal below follows the same shape: what it is, where it is recorded, why it matters, and what tends to cause false positives. The event IDs come from Microsoft's security auditing reference. Those pages now live in Microsoft Learn's archived Windows 10 section, but they remain the documented definitions of each event.

Signal 1: logons that don't fit the account

Event 4624 ("An account was successfully logged on") is written on the computer that was accessed, where the session was created (Microsoft Learn, 4624). That detail is easy to skip and important: to see a session arrive on a server, you need that server's Security log, not only the domain controller's.

The most useful field is Logon Type. A few of the documented values:

Source: Microsoft Learn, 4624 logon types.

The same event carries Workstation Name and Source Network Address (where the logon came from), Authentication Package (NTLM, Kerberos or Negotiate) and, since Windows 10, an Elevated Token flag that says whether the session has administrator privileges (4624).

Microsoft's own monitoring recommendations for 4624 read like a lateral movement checklist. They suggest watching high-value accounts (domain admins, the built-in local administrator, service accounts), accounts that should never be used, accounts used outside working hours, "restricted-use computers" where certain people should not be acting at all, and service accounts that should only log on from a known list of IP addresses (4624, Security Monitoring Recommendations).

Translated into questions you can ask of your logs:

• Did an admin account create a type 10 (Remote Desktop) session on a server from a user workstation instead of its admin workstation?
• Did a service account produce a network logon from an address outside its usual list?
• Did one source address produce type 3 logons on many hosts that it has never touched before?

False positives: management servers, vulnerability scanners, backup agents and deployment tools legitimately touch many hosts. Put them on an explicit list, and treat a new member of that list as a change that needs a ticket.

Signal 2: explicit credentials and special privileges

Two events tend to travel with interesting 4624s.

4648 ("A logon was attempted using explicit credentials") is generated when a process logs on by explicitly supplying an account's credentials. Microsoft notes that it most commonly comes from scheduled tasks or the RUNAS command, and that it also occurs routinely during normal operation (Microsoft Learn, 4648). On its own it is noise. Its value is in the pairing: the event records both the account that was logged in and the account whose credentials were used, plus a Target Server Name. Microsoft's recommendations include alerting when a subject should not know or use another account's credentials, or when credentials are used from an unexpected network address (4648).

4672 ("Special privileges assigned to new logon") fires when a new session receives sensitive privileges such as SeDebugPrivilege or SeBackupPrivilege. Every SYSTEM logon triggers it, so Microsoft recommends monitoring it where the account is not one of the well-known system principals and is not an administrative account expected to hold those privileges (Microsoft Learn, 4672).

The glue between them is the Logon ID field, which Microsoft documents as the way to correlate a 4624 with a related 4672 on the same machine (4624). A network logon, immediately granted debug privileges, by an account that has never logged on to that host before, is a much stronger story than any one of those events alone.

Signal 3: failures that cluster, and failures that mean your rules work

Event 4625 ("An account failed to log on") is logged on the computer where the attempt was made, and it is written on domain controllers, member servers and workstations alike (Microsoft Learn, 4625). The Status and Sub Status codes explain why. A few that Microsoft specifically recommends monitoring:

• 0xC000006A, bad password, for critical or service accounts, "especially watch for a number of such events in a row";
• 0xC0000070, logon from an unauthorized workstation;
• 0xC000015B, the user has not been granted the requested logon type on this machine.

(4625, monitoring table)

The last two are worth a second look. They appear when a logon restriction you configured stopped someone, for example an admin account that is not allowed to sign in to workstations. A well-tiered environment should produce very few of them, so each one is either a misconfiguration to fix or a person or process testing a boundary. Microsoft also recommends monitoring all 4625 events for local accounts and service accounts, because those accounts typically should not be locked out (4625).

Signal 4: NTLM where you expected Kerberos

Microsoft documents that the Negotiate package, which chooses between the two protocols, selects Kerberos unless one of the systems involved cannot use it or the calling application did not provide enough information (4624, Authentication Package). So in a domain where Kerberos is the norm, NTLM showing up where it shouldn't is a signal in itself.

MITRE's detection strategy for Pass the Hash (T1550.002) describes the defender's view in concept: look for anomalous NTLM network (type 3) authentications that have no matching domain logon activity, and for mismatches between the source user context and the system being accessed. Microsoft's 4624 guidance offers the matching log filters: if NTLM is not used in your organisation, or should not be used by a specific account, monitor every 4624 whose Authentication Package is NTLM; and if only NTLMv2 is allowed, watch the Package Name (NTLM only) field for anything else (4624).

False positives: older applications, devices without domain membership and logons to local accounts can all produce legitimate NTLM. The goal is not zero NTLM on day one; it is a short, known list of NTLM sources, so that a new one stands out.

Signal 5: east-west traffic with no business reason

Host logs tell you who logged on. Network logs tell you which paths exist and which ones somebody tried. The joint guidance Identifying and Mitigating Living Off the Land Techniques (CISA, NSA, FBI and partners) is direct about where to look (CISA LOTL guidance, PDF):

• Blocked attempts. In a properly segmented network, denied traffic can itself be an indicator of compromise, as can network discovery originating from inside.
• SMB across segments or sites, such as a user reaching file servers unrelated to their role.
• A workstation talking to a back-end database, when only the front-end server should.

Admin protocols have well-known default ports, which makes them easy to watch: Remote Desktop listens on TCP 3389 by default (Microsoft Learn), WinRM 2.0 listens on 5985 for HTTP and 5986 for HTTPS (Microsoft Learn), and SMB uses TCP 445 (Microsoft Learn, Secure SMB traffic). Defaults can be changed, so treat port numbers as a starting filter, not proof.

The pattern with the best signal-to-noise ratio is workstation to workstation. NSA and CISA's red and blue teams recommend limiting it outright: "All workstation communications should occur through a server to prevent lateral movement" (CISA AA23-278A). Once peer-to-peer admin traffic is blocked, every denied attempt between two laptops is worth a look.

 EAST-WEST: who is talking to whom?                             
                                                                
                      ┃             ┌─────────────────────────┐ 
                      ┃             │ SIEM: denied east-west  │ 
    o 01  o 02  o 03■ ╏   [FILE]    │                         │ 
                      ┃             │ no denies yet           │ 
                      ┃             │                         │ 
                      ┃             │ count  · · · · · · ·    │ 
    o 06  ● 07  o 08  ┃             │                ^        │ 
                      ┃             │ rule: 5+ peers denied   │ 
                      ┃             │                         │ 
                      ┃             │ watching                │ 
    o 11  o 12  o 13  ┃   [APP]     │                         │ 
                      ┃             │                         │ 
                      ┃             └─────────────────────────┘ 
    WORKSTATIONS          SERVERS                               
                                                                
 ● compromised  o host  × denied  ┃ wall  ■ planned flow        

That is the core idea of this whole guide in one picture: once the normal paths are narrow, the abnormal ones become loud.

Signal 6: the session trail, and the gaps in it

Two smaller signals from the same 2024 advisory are worth adding to any lateral movement watch list (CISA AA24-038A):

• Remote Desktop session events. The advisory's table of key log indicators lists IDs 21 to 25 from the Terminal Services Local Session Manager operational log: authentication to a session, a new session starting, logoff, disconnect and reconnect. For a new session or a reconnection, it notes that this may imply lateral movement or unauthorised remote access, especially if the user or session is unexpected. Paired with type 10 logons in the Security log, these events give you the duration and shape of each session.
• Security log cleared (1102). The advisory says all 1102 entries should be investigated, because logs are generally not cleared. An intruder covering their tracks is one reason it appears; an unplanned administrator action is another, and both deserve a ticket.

Controls that limit the spread

Detection buys time. Architecture decides how much ground an intruder can cover before you use that time. MITRE's mitigations for Remote Services (T1021) are a good outline: limit which accounts can use remote services, limit access to resources over the network, require MFA, and avoid reusing local administrator passwords. Here is what each looks like in practice.

Segmentation and host firewalls

MITRE's Network Segmentation mitigation (M1030) describes dividing a network into isolated segments to restrict lateral movement, and for Remote Desktop specifically it suggests firewall rules that block RDP between security zones. The LOTL guidance adds the payoff in plain words: when a threat actor compromises legitimate credentials, appropriate segmentation limits the "blast radius" of reachable systems (CISA LOTL guidance).

Inside a segment, the host firewall does the same job at a smaller scale. Microsoft's SMB hardening guide points out that file servers and domain controllers need inbound SMB to do their role, asks which client endpoints need inbound SMB at all, and describes an outbound Windows Defender Firewall policy that allows SMB only to the minimum set of servers as "a lateral defense-in-depth measure" (Microsoft Learn, Secure SMB traffic). The same page recommends disabling the SMB Server service where nothing needs it, and rolling the change out through phased Group Policy deployments, starting with small-scale tests on selected servers and clients.

Windows LAPS: no shared local admin password

A shared local administrator password turns one compromised laptop into a key for every laptop. Microsoft says it directly: local administrator accounts often share the same password across many devices, which attackers can exploit to move laterally (Microsoft Learn, Windows LAPS overview). NSA and CISA give the same advice from the other direction: "Do not reuse local administrator account passwords across systems" (AA23-278A).

Windows LAPS rotates each device's local administrator password, backs it up to Microsoft Entra ID or Active Directory, and lets authorised administrators retrieve it. Microsoft lists "protection against pass-the-hash and lateral-traversal attacks" among its benefits (LAPS overview). A few facts worth knowing before you plan it:

• It is built into Windows 11 23H2 and later, Windows Server 2025, and earlier supported versions that received the April 11, 2023 update. Backing up passwords to Active Directory needs no other licence, and backing up to Microsoft Entra ID needs Microsoft Entra ID Free or higher (LAPS overview).
• The legacy Microsoft LAPS product is deprecated on Windows 11 23H2 and later (LAPS overview).
• It can rotate the password automatically after the managed account is used to sign in, with a configurable grace period, to bound how long a revealed password stays useful (Microsoft Learn, Windows LAPS architecture).
• When passwords are stored in Active Directory, Microsoft highly recommends enabling password encryption. It calls the permissions to read or decrypt those passwords sensitive, says they should be carefully monitored, and describes reserving them for members of Domain Admins as the most secure approach (LAPS architecture).

That last point is also a detection hook: since the read and decrypt permissions are sensitive, who holds them, and who uses them, belongs in your baseline.

Tiered administration

The idea behind tiering is that credentials must never flow from a more trusted system into a less trusted one, and a less trusted system must never control a more trusted one. Microsoft's enterprise access model, which builds on the older Active Directory tier model, frames it as three planes (control, management, and data/workload) and says to "enforce hierarchy" to prevent control of higher planes from lower planes (Microsoft Learn, Enterprise access model). In that model, Tier 0 grows into the control plane, the old Tier 1 splits into management and data/workload planes, and Tier 2 becomes user access and app access.

                                                                
 ┌─ TIER 0  identity / control plane ─────────┐  RULE           
 │                                            │  control flows  
 │    [DC]          [IdP]         [PAW-0]     │  down, never up 
 └────────────────────────────────────────────┘                 
                                          ┊                     
                                          ┊                     
 ┌─ TIER 1  servers ──────────────────────────┐  upward denied  
 │                                            │  0              
 │    [SRV]         [SRV]         [PAW-1]     │                 
 └────────────────────────────────────────────┘                 
                                          ┊                     
                                          ┊                     
 ┌─ TIER 2  user workstations ────────────────┐  admins use     
 │                                            │  a PAW in their 
 │    [ws]          [ws]          [ws]        │  own tier       
 └────────────────────────────────────────────┘                 
                                                                
 ▼ allowed control  ▲ from below  × refused at boundary         

Two concrete rules make tiering real:

1. Admins work from an admin workstation in their own tier. CISA's 2024 advisory recommends permitting administrative activity only from workstations hardened appropriately for the administrative tier (AA24-038A), and the LOTL guidance recommends Privileged Access Workstations (PAWs), starting with Active Directory administrators (CISA LOTL guidance).
2. Top-tier accounts don't sign in below their tier. The LOTL guidance puts it bluntly: user accounts with domain administrator privileges "should never log into anything except domain controllers" (CISA LOTL guidance).

Both rules produce clean detections. A Tier 0 account appearing in a 4624 on a workstation, or a 4625 with sub-status 0xC000015B because a logon-right restriction blocked it, is exactly the kind of event that should never happen by accident.

MFA for administrators, and its limits

Microsoft's Conditional Access guidance says accounts with administrative rights are targeted by attackers and recommends requiring phishing-resistant MFA for a minimum list of admin roles, such as Global Administrator, Privileged Role Administrator and Security Administrator (Microsoft Learn, Require MFA for administrators). The LOTL guidance asks for phishing-resistant MFA across all systems, "especially for privileged accounts," plus just-in-time privileged access (CISA LOTL guidance).

MFA protects the sign-ins it is applied to. It does not automatically protect every protocol behind them. The NSA and CISA misconfigurations advisory gives a sharp example: when smart-card requirements are misconfigured so that an account's password hash never changes, a captured hash stays usable for pass-the-hash for as long as the account exists. Their mitigations are to disable NTLM and other legacy protocols where possible and to re-randomise those hashes regularly (AA23-278A). MFA belongs on the list next to LAPS, tiering and NTLM reduction, not instead of them.

Detection engineering: baselines and tuning

Every signal above depends on knowing what normal looks like. The LOTL guidance's detection best practices make this the centre of the work: aggregate logs in a central, write-once location; establish and continuously maintain baselines of network, user, administrative and application activity; compare current activity against those baselines; reduce alert noise by tuning on priority; and use user and entity behaviour analytics (UEBA) (CISA LOTL guidance). NSA and CISA's misconfigurations advisory says the same in fewer words: establish a baseline of normal traffic, host activity and user behaviour, and investigate deviations (AA23-278A).

For privileged accounts, the LOTL guidance is specific about what to record: which tools admins usually use, the commands they run, their active hours and the devices they interact with, and even the usual sequence of activity (CISA LOTL guidance).

 BASELINE: logons per hour, account adm-ops                     
                                                                
                                                                
                        usual (office hours, PAW-02)            
                                                                
      │                           --                            
      │                       ----  ----                        
      │                     --          --                      
      │                 ----              ----                  
      │                                                         
      │                                                         
      │                                                         
      ───────────────────────────────────────────────────       
        00          06          12          18       23         
                                                                
 usual: 08-18, type 10, from PAW-02                             
 watching                                                       
 █ logons  - - usual envelope  red: outside it                  

A few tuning habits from the same guidance help keep alerts trustworthy:

• Avoid overly broad rules, in both inclusion and exclusion lists. An exclusion like "ignore everything from the management subnet" is a hiding place.
• Reduce the number of allowed admin tools and logon types with the IT team, so the baseline gets smaller and deviations get clearer.
• Name alerts with a maturity level and the ATT&CK phase, so triage knows how much to trust a rule and where it sits in an intrusion, and update the maturity as the rule stabilises.

(CISA LOTL guidance)

One way to start, signal by signal:

A checklist for defenders

• Security logs from servers and workstations reach a central store that intruders cannot edit.
• Logon events (4624, 4625, 4648, 4672) are collected, with Logon Type, source address and Authentication Package parsed.
• Each admin account has a documented set of source machines, and logons from anywhere else alert.
• Workstation-to-workstation admin traffic (SMB, RDP, WinRM) is blocked by host firewalls, and the denies are logged.
• Between zones, only planned flows pass, and denied attempts are reviewed rather than discarded.
• Windows LAPS manages every local administrator password, with encryption on and password reads monitored.
• Tier 0 accounts sign in only to Tier 0 systems, from Tier 0 admin workstations.
• Phishing-resistant MFA is required for admin roles, and NTLM use is shrinking toward a known list.
• Baselines exist for privileged accounts (hours, tools, devices), and alerts carry a maturity level and ATT&CK phase.
• Event 1102 (log cleared) always reaches a person.

None of this needs exotic tooling. Most of it is narrowing the paths that exist, writing down what normal looks like, and making sure the rare event that breaks the pattern lands in front of someone who will look at it.

Sources

• MITRE ATT&CK, Lateral Movement (TA0008)
• MITRE ATT&CK, Remote Services (T1021)
• MITRE ATT&CK, Use Alternate Authentication Material: Pass the Hash (T1550.002)
• MITRE ATT&CK, Network Segmentation (M1030)
• CISA, NSA, FBI and partners, AA24-038A: PRC State-Sponsored Actors Compromise and Maintain Persistent Access to U.S. Critical Infrastructure (February 7, 2024)
• CISA, NSA, FBI and partners, Identifying and Mitigating Living Off the Land Techniques (PDF)
• CISA, Identifying and Mitigating Living Off the Land Techniques, resource page (February 7, 2024)
• NSA and CISA, AA23-278A: Top Ten Cybersecurity Misconfigurations (October 5, 2023)
• Microsoft Learn, 4624(S): An account was successfully logged on
• Microsoft Learn, 4625(F): An account failed to log on
• Microsoft Learn, 4648(S): A logon was attempted using explicit credentials
• Microsoft Learn, 4672(S): Special privileges assigned to new logon
• Microsoft Learn, Windows LAPS overview
• Microsoft Learn, Windows LAPS architecture
• Microsoft Learn, Securing privileged access: Enterprise access model
• Microsoft Learn, Require MFA for administrators with Conditional Access
• Microsoft Learn, Secure SMB traffic in Windows Server
• Microsoft Learn, Change the Remote Desktop listening port
• Microsoft Learn, Installation and configuration for Windows Remote Management