The part that matters most is stopping internal spread
- Lateral spread is the stage where one foothold becomes a multi-system incident.
- It usually depends on valid credentials, remote services, shared administration paths, or flat network design.
- The earliest warning signs are identity anomalies, remote execution, and unusual east-west traffic.
- Segmentation, least privilege, MFA, and isolated backups do more than any single detection rule.
- Containment decisions in the first hour matter more than trying to clean every host at once.
What lateral movement means in a ransomware incident
Initial access is just the door. Once inside, attackers map the network, identify high-value systems, and pivot from one host to another until they can disable security tools, tamper with backups, or launch encryption at scale. In practice, I think of it as a trust-abuse problem: if one account can reach too much, one compromise becomes many.
That is why the spread phase matters more than the first alert. A workstation infection is inconvenient; a compromised admin session that can touch file servers, identity systems, and backup consoles is a business event. The attacker is not usually trying to be clever for its own sake. It is trying to turn a single foothold into broad operational control.
For a UK organisation, the risk is often amplified by mixed estates: branch offices, remote support, cloud identity, and legacy Windows infrastructure all tied together by convenience. Once those trust paths exist, ransomware does not need exotic exploits to move. It just needs the right credentials and enough room to pivot.
From here, the question becomes simple: which routes do attackers actually use to move around, and which ones should defenders care about first?
The main ways attackers spread across a network
Most internal spread follows a few predictable patterns. The tools change, but the logic stays the same: reuse trust, find reachable systems, and deliver the payload through something the environment already allows.
Stolen credentials and token reuse
Valid accounts are the cleanest path. If an attacker steals a password, a hash, a session token, or a cloud access token, it may be enough to sign in as if they belong there. That is why a single compromised admin identity is often more dangerous than a noisy endpoint infection. Once the attacker can authenticate, the network starts to look like a set of open doors instead of separate systems.
Remote administration channels
RDP, remote services, WinRM, SSH, VPN access, and admin shares are legitimate tools. In an incident, the problem is not the tool itself but the fact that it already carries trust and is often allowed between too many systems. If an attacker can blend into normal remote administration, alerts arrive late and the spread looks like routine IT work until the impact becomes obvious.
Shared storage and deployment tooling
SMB shares, software deployment systems, scheduled tasks, and remote service creation can all move payloads fast. These are useful mechanisms for central management, which is exactly why they become dangerous when permissions are broad or change control is weak. A tool that exists to simplify operations can become a broadcast mechanism for malware when it has more reach than it should.
Identity and management-plane abuse
Modern intrusions often move through the identity layer rather than just hopping from endpoint to endpoint. If an attacker reaches directory services, cloud admin consoles, or the system that synchronises identities between environments, the spread can jump from local compromise to domain-wide control. That is the point where recovery gets expensive, because the attacker is no longer just inside the network. It is inside the control plane.
The practical lesson is straightforward: lateral movement is usually less about a fancy exploit and more about abusing the paths administrators already rely on every day. That is also why poorly designed trust boundaries make the next phase so much easier.
Why it succeeds so quickly in real organisations
The fastest-moving intrusions usually find the same weaknesses: overprivileged accounts, flat networks, shared local admin passwords, weak MFA coverage, and internal systems that can talk to almost everything. Add third-party support links, stale service accounts, and legacy platforms that were never designed for modern segmentation, and the attacker gets a very forgiving environment.
This is where UK guidance is useful. The NCSC has repeatedly treated segmentation as one of the most effective containment controls because it reduces the number of places an attacker can reach after the first compromise. I agree with that emphasis. Segmentation is not glamorous, but it is one of the few controls that changes the attacker’s maths instead of just adding another alert.
Speed is another factor. In many incidents, the internal spread happens in hours, not days. Recent cases of self-propagating ransomware make the point even more sharply: once the malware or operator can reuse trust at scale, the infection wave grows faster than a manual response team can chase it.
That is why I push teams to think beyond perimeter security. Once the initial foothold is in place, the real question is whether the attacker can move freely, or whether every step forces a delay, a permission check, or a hard stop.
How I would detect it before encryption starts
I would not wait for file encryption to appear. By that point, the attacker has usually finished the interesting part. The better approach is to look for combinations of identity, endpoint, and network signals that do not fit normal admin behaviour.
| Signal | What it usually means | What I would check first |
|---|---|---|
| Multiple failed logins followed by a successful admin sign-in from a new host | Credential abuse, password spraying, or a stolen account being reused | Source device, account history, MFA status, and whether the login aligns with normal support activity |
| New remote service creation or a sudden scheduled task on several hosts | Scripted pivoting or remote execution | Parent process, initiating account, and whether the change was tied to an approved maintenance window |
| Spikes in SMB, RDP, or WinRM traffic between workstations and servers | East-west movement beyond normal administrative patterns | Whether the connections match approved admin paths and whether the source endpoint is expected to manage servers |
| Backup system access from an ordinary user endpoint | Attempt to weaken recovery options | Backup admin separation, network restrictions, and any unusual privilege escalation before the access |
| GPO edits, mass software deployment, or remote script execution | Broad payload distribution | Change records, recent privilege use, and whether the action affects more systems than the operator normally manages |
The pattern matters more than any single alert. One odd login can be a helpdesk mistake. One remote task can be routine maintenance. Put them together with new admin shares, unusual service creation, and backup tampering, and the picture changes quickly. What I want at that point is correlation, not more isolated noise.
That leads directly to the controls that make those signals less likely in the first place.
Controls that slow the spread instead of just creating more alerts
There is no single control that stops everything, but some measures clearly do more work than others. The goal is not to make an attack impossible. The goal is to make the attacker’s next move expensive, visible, or blocked.
| Control | What it limits | Practical trade-off |
|---|---|---|
| Network segmentation | Unrestricted east-west movement and reach to critical systems | Requires design effort and disciplined exception handling, but pays off quickly when an incident starts |
| Least privilege and privileged access management | Credential reuse and broad admin blast radius | Needs account redesign and change management, but it removes standing access that attackers love |
| MFA for remote, cloud, and privileged access | Simple password theft | Only works if every privileged path is covered, including break-glass routes and third-party access |
| Application control and script restrictions | Abuse of trusted tooling and common living-off-the-land techniques | Can be noisy to tune at first, especially in mixed legacy environments |
| Immutable backups with separate admin access | Ransom leverage and recovery collapse | Backups are only useful if restore paths are tested under realistic pressure |
| EDR with automated containment | Fast propagation across multiple hosts | Depends on telemetry quality, but can buy the response team valuable minutes |
The control stack works best when the pieces reinforce one another. Segmentation reduces reach. MFA and PAM reduce credential reuse. Application control slows tool abuse. Immutable backups keep recovery possible. If one layer fails, the others should still make the attacker’s job awkward.
What I would not do is rely on detection alone and hope the alert fires soon enough. The spread phase can move faster than human response, especially when a privileged account or management server is involved.
What to do in the first hour of containment
The first hour is about preserving control, not winning a forensic marathon. If the attacker is still active, every minute spent debating the perfect cleanup plan can expand the damage.
- Isolate hosts that show signs of remote execution, rapid file changes, or encryption.
- Disable compromised accounts, revoke active sessions, and rotate privileged credentials that may have been exposed.
- Cut the remote admin paths the attacker is using, especially if they cross trust zones.
- Protect backups and virtualisation management before you start broad remediation.
- Preserve logs, authentication records, and endpoint evidence so you can reconstruct the spread later.
- Coordinate communications early so IT, security, leadership, and external responders are not working from different assumptions.
One mistake I see often is teams rushing to reimage systems before they understand the path the attacker used. That can erase evidence and leave the original foothold untouched. Containment should come first; clean-up can follow once you know the spread is stopped.
If there is a single rule here, it is this: do not let a compromise of one system automatically become trust in every other system.
What a stronger ransomware posture looks like in practice
The most resilient organisations are usually not the ones with the most tools. They are the ones that have mapped their trust paths honestly and removed the easy ones. They know which accounts can touch production, which systems can reach backups, and which remote channels are truly necessary.
- Separate backup administration from daily domain administration.
- Review third-party access routes as if they were production dependencies, because they are.
- Test segmented restore paths, not just backups themselves.
- Measure east-west visibility every month, not only after an incident.
- Rehearse the isolation runbook until it can be executed under pressure.
That is the practical endpoint of this topic. The attacker’s advantage comes from hidden trust and loose internal reach; the defender’s advantage comes from making those paths narrower, noisier, and slower. If you do that well, ransomware still hurts, but it no longer has an easy route to become an organisation-wide shutdown.
