Internal compromise is rarely loud at first. The attacker usually starts with a valid account, a remote admin channel, or a small foothold on one device, then works outward until the environment looks normal from the outside and compromised from the inside. This article shows how to detect lateral movement by reading the right logs, recognising the most common pivot patterns, and separating real intrusion from routine admin work in UK hybrid networks.
Key points to keep in view
- Look for combinations, not single events: a successful logon, remote execution, and east-west connections mean far more together than separately.
- Identity is usually the first clue: one account suddenly touching many hosts, or using explicit credentials from a new workstation, deserves attention.
- Host, service, and network data need to line up; single-source detection is too easy to evade.
- Remote services and tool transfer are high-signal behaviours, especially when they appear outside change windows.
- Baselining reduces noise: patching, backups, software deployment, and support sessions create many false alarms.
What lateral movement looks like in a real network
I treat lateral movement as the point where an incident stops being local and starts becoming systemic. Once an attacker has one foothold, the next step is usually to reuse credentials, reach another host, and repeat the process until they find something valuable enough to impact. In practice, that often looks ordinary at first: a valid login, a remote desktop session, a management command, or a file copied through a normal share.
That is why the first question I ask is not whether the activity is technically possible, but whether it is plausible for that user, on that device, at that time. The same command can be routine in an IT admin session and highly suspicious in a finance workstation. Context matters more than the tool name.
Identity reuse
Stolen or reused credentials are the cleanest path through a network because they avoid noisy exploit chains. A compromised account that begins authenticating to servers it has never touched before, especially across several systems in a short window, is one of the strongest early indicators I look for. If the account is privileged, the risk rises fast because every additional hop expands the attacker’s reach.
Remote services
Remote services are the classic pivot layer: RDP, SSH, WinRM, WMI, remote shell tooling, and cloud or virtualisation consoles. They are also where attackers blend in best, because administrators use the same channels every day. The difference is usually in the pattern, not the protocol. A single administrative hop during business hours may be fine. A sequence of logins from one workstation to six servers in fifteen minutes usually is not.
Read Also: TLS 1.2 Cipher Suites - What's Safe & What to Disable?
Tool transfer and staging
Once attackers have moved, they often stage tools on the next machine so they can keep going. They may use SMB shares, admin shares, RDP copy features, SCP, or synced folders to move payloads and scripts between systems. Living off the Land matters here too, meaning built-in utilities such as PowerShell, PsExec-style execution, scheduled tasks, or native file transfer tools that already exist in the environment. That is why the next step is not more theory; it is better telemetry.
The logs and signals that matter most
The UK's NCSC is blunt about this: strong detection usually depends on multiple sources of information. I agree with that approach. No single log type tells the whole story, and the best detections come from correlating identity, endpoint, and network data around the same time window.
| Signal source | What I collect | What it can reveal | Common gap |
|---|---|---|---|
| Identity and authentication | Successful and failed logons, explicit-credential use, privilege events, Kerberos or NTLM activity, and identity-provider sign-ins | Account reuse, unusual source hosts, repeated access to multiple systems, and suspicious privilege use | Missing service accounts, weak MFA coverage, or no visibility into cloud identities |
| Endpoint execution | Process creation, command line, parent-child process relationships, service creation, scheduled tasks, PowerShell, WMI, and remote shell activity | Remote execution, tool staging, and post-access behaviour that follows a successful login | Logs kept locally on the endpoint only, or disabled script/process auditing |
| Network telemetry | NetFlow, firewall logs, proxy logs, DNS, SMB, RDP, SSH, and other east-west connections | Pivots between internal hosts, unusual internal ports, and bursts of remote administration | No visibility into internal traffic, especially between user VLANs and server segments |
| Administrative activity | Group changes, new service accounts, privileged session logs, jump-box access, and remote management actions | Privilege escalation, reuse of admin paths, and abuse of trusted management channels | Admin activity blended into normal operations with no separate audit trail |
| Cloud and remote access | VPN sign-ins, cloud control-plane events, bastion access, and role assignments | Hybrid pivots from on-prem to cloud, or the other way around | Logs split across consoles that are never correlated |
For investigations, I want at least 30 days of searchable logs as a bare minimum, and 90 days is far more useful when the movement is slow or the attacker pauses between hops. Short retention is one of the most common reasons teams miss the path and only see the end state. That becomes much clearer when you start looking for the exact patterns that matter.
Detection patterns that deserve an alert
Most lateral movement is not caught by one perfect indicator. It is caught by a cluster of small anomalies that line up over a short period. I usually look for the relationship between who logged in, from where, to what, and what happened next.
| Pattern | Why it matters | What to check next |
|---|---|---|
| One account authenticates to three or more hosts within 15 to 30 minutes | Normal users rarely fan out that quickly; attackers often do | Source workstation, time of day, host class, and whether the access matches the user’s role |
| Remote login followed by unusual commands, file writes, or script execution | This is a classic post-access pivot path | Process tree, parent process, command line, and whether the session used admin credentials |
| SMB, RDP, SSH, or WinRM access to multiple internal systems from the same source host | Internal hopping often reuses a single compromised workstation or jump box | Whether the source is a management host, a user endpoint, or something that should not be acting as a pivot |
| Explicit credential use from an unusual device | This often points to stolen credentials or a script running under another identity | Account history, recent password changes, and whether MFA should have blocked the attempt |
| Admin share access or file transfer followed by service creation or a scheduled task | That sequence is highly consistent with staging and remote execution | New binaries, new services, and signs of lateral tool transfer |
| SSH from a new source IP followed by sudo, su, or an outbound connection to another internal host | This is a strong Linux pivot pattern | Shell history, auth logs, and whether the source host is normally used for administration |
| Bursts of Kerberos or NTLM requests across several systems | Credential abuse often creates a noisy auth trail even when the attacker is careful | Ticket requests, failed-to-success transitions, and any matching endpoint activity |
MITRE ATT&CK groups these behaviours under remote services, remote execution, and lateral tool transfer, and that framing is useful because it stops you from treating each event as isolated noise. In a real hunt, I want to connect the login, the process, and the new internal destination before I decide whether it is an incident or just an admin job. Once you have those patterns, the question becomes how to investigate them without losing time or evidence.
A practical investigation workflow
- Anchor on the first suspicious host and account. I start by identifying the earliest system that looks abnormal, then I ask which account was used, which protocol was involved, and whether the behaviour fits that user’s normal work.
- Reconstruct the hop path. I map source host, destination host, protocol, and timestamp. If the same account touched multiple hosts in a short window, I treat that chain as the likely attack path until proven otherwise.
- Pull endpoint and identity logs around the same window. I want logon records, process creation, service creation, network connections, and any privilege events before and after the suspicious hop. A single log rarely proves much on its own.
- Check for post-access behaviour. Successful lateral movement usually leaves a second layer of activity: archive creation, file transfer, script execution, credential dumping attempts, or a sudden connection to another internal segment.
- Decide containment based on spread risk. If the host is still talking to other internal systems, I isolate it quickly. If the account appears compromised but the endpoint is still under observation, I may preserve the session first and then disable access in a controlled way.
I also keep the investigation window practical. Thirty to sixty minutes before and after the first suspicious event is often enough to expose the chain, but slower attacks may need a much wider lookback. The key is not to chase every log at once; it is to prove or disprove the pivot path fast enough to contain it. That leads directly to the mistakes that make teams miss the signal in the first place.
Where teams usually miss the signal
In my experience, lateral movement is missed less because the attacker is brilliant and more because the monitoring model is incomplete. The activity looks legitimate if you only see one half of the picture, and it looks like background noise if you do not know what normal admin work actually looks like.
| Blind spot | Why it hides the attack | What fixes it |
|---|---|---|
| Third-party support and vendor access | Remote sessions from trusted suppliers can look routine, even when they are abused | Separate vendor accounts, stricter approvals, and tighter audit trails for remote access |
| Overtrust in admin tools | Tools like PowerShell, RDP, SSH, and remote deployment utilities are often allowed by default | Allowlist the normal paths and alert on admin tooling outside maintenance windows |
| No east-west visibility | Teams see internet traffic but miss internal pivots between hosts | Collect flow data between segments, especially user-to-server and server-to-server paths |
| Poorly scoped service accounts | Attackers love accounts that can talk to many systems without human oversight | Limit privileges, rotate secrets, and monitor unusual reuse of service identities |
| False positives from change activity | Backups, patching, software deployment, and help-desk work can mimic intrusion | Baselines, change windows, and contextual allowlisting by team and asset class |
| Fragmented logging | Identity, endpoint, and network data live in separate tools that are never correlated | Build a single investigation path across the SIEM, EDR, and identity platform |
That is the part many teams underestimate: the cleanest attacker move often looks exactly like a valid admin move unless you know the expected source, timing, and destination. UK organisations feel this especially in hybrid estates, where third-party access, VPNs, and shared management tools create a lot of normal-looking noise. The final step is deciding what I would build first if I were tightening detection from scratch.
The detection stack I would build first in a UK hybrid environment
If I had to prioritise, I would focus on the paths that turn a single breach into a wider compromise. That means the accounts, hosts, and channels that matter most when an attacker is trying to pivot:
- Privileged identity monitoring for admin accounts, service accounts, and any identity that can reach multiple segments.
- Endpoint process and logon auditing on jump boxes, admin workstations, domain controllers, backup servers, and remote support endpoints.
- East-west network visibility between user VLANs, server VLANs, and any cloud-connected or partner-facing segment.
- Strong audit trails for remote administration, including remote desktop, SSH, WinRM, scheduled tasks, and service creation.
- Tight privilege design with PAM or just-in-time access for sensitive systems so stolen credentials have a shorter useful life.
- Segmentation around critical assets so a compromised workstation cannot easily become a launch point for the rest of the estate.
If I had only two moves to make this quarter, I would improve multi-source logging first and then narrow the admin paths attackers can abuse. That combination does more than most single tools ever will: it gives you a better chance of seeing the pivot early, understanding the full path, and stopping the breach before it becomes a multi-host incident.
