SMB Lateral Movement: Harden Windows Without Breaking Shares

What SMB abuse looks like when an attacker already has a foothold

MITRE ATT&CK treats this pattern as a lateral movement sub-technique built around remote share access, followed by actions like service creation or scheduled tasks on the target host. That matters because the protocol itself is not the problem; the problem is that the attacker has found a trusted internal channel and is now reusing it to move.

1. They land on one machine through phishing, stolen credentials, or another initial access path.
2. They reuse a valid account or hash to authenticate to another internal host over SMB.
3. They enumerate shares, especially administrative ones such as ADMIN$ and C$.
4. They stage a binary, script, or service payload on the remote machine.
5. They turn that file copy into execution through the Service Control Manager, a scheduled task, or another native mechanism.

Some operators stop at file staging; others use named pipes and service control to make the chain look even more like normal administration. Either way, the pattern is simple on paper and messy in real life, which is why the next question is what makes it so reliable inside corporate networks.

Why it spreads so well in Windows estates

I keep seeing the same reasons: SMB is already trusted, admin shares exist for management, and many environments still allow far more east-west connectivity than they realise. Once an attacker reaches one endpoint, moving to the next one can feel like normal admin traffic unless you are watching the sequence rather than the single event.

• Valid credentials beat perimeter controls. A firewall does not help much when the attacker is already authenticated on the inside.
• Administrative shares lower friction. Management paths are useful for defenders, but they are also convenient staging points for payloads.
• Remote execution can look ordinary. Service creation and scheduled tasks are common IT actions, so the context matters.
• Legacy dependencies keep SMB alive. File servers, imaging systems, backup tools, and printer workflows still rely on it in many organisations.
• Newer transport options do not remove the problem. Even when SMB is wrapped differently, the security question is still who can reach what, and from where.

This is why I do not think about SMB as a single vulnerability. I think about it as an attack path that becomes dangerous when identity, network reach, and administrative privilege line up in the wrong order. That is also why detection becomes much more practical once you focus on the sequence rather than the share name alone.

The signals that usually expose the pivot

The cleanest detections are usually not one log line by itself. I look for a sequence: a share access, then a file copy or access check, then a remote execution step on the destination host. Microsoft’s monitoring guidance for share events is useful here because it specifically encourages scrutiny when the source address should not be reaching that computer.

If I only had a few minutes to triage, I would prioritise the combination of share access plus a remote execution artifact on the same destination host. Single events can be noisy; patterns are harder to fake. The same account being used on multiple machines is often more important than the specific tool, because it shows the attacker is reusing trust rather than doing one-off administration.

How I would harden SMB without breaking file sharing

This is where many teams overcorrect. A blanket shutdown of SMB sounds decisive, but in a real Windows environment it can break Group Policy processing, file access, printers, backup workflows, and remote administration. I would rather narrow the attack surface sharply than create a service outage the business later reverses.

Modern Windows file sharing is usually about TCP 445; older NetBIOS transport on UDP 137-138 and TCP 139 should be treated as legacy unless you have a hard dependency. On non-share endpoints, the cleanest move is to block inbound File and Printer Sharing, Netlogon, Remote Event Log Management, and Remote Service Management over SMB, then allow only the management paths you actually need.

On the current Windows 11 24H2 and Windows Server 2025 line, Microsoft has already moved the defaults in this direction: signing is required by default on the newest builds, outbound SMB client connections require encryption, and failed NTLM or Local KDC Kerberos attempts are rate-limited with a two-second pause. That does not eliminate abuse, but it does raise the cost of noisy guessing and weakly protected paths.

If your estate uses SMB over QUIC, the transport changes, but the trust problem does not; certificate-backed allow lists and client control still need to be part of the policy. For a UK organisation, I would also treat outbound SMB from user endpoints as privileged traffic, not background noise. If a workstation can talk to any peer over SMB, the attacker gets a cheap pivot lane. If it can only talk to the specific servers it truly needs, the path becomes far less useful.

That gives you a strong preventive baseline, but it still leaves the question of what to do when one host is already compromised.

What to do when you suspect an active pivot

Once I suspect SMB-based spread, I work from containment outward. The goal is to stop the attacker from reusing the same credentials or the same trusted path on the next machine.

1. Isolate the source host and the target host if you can do so without destroying evidence.
2. Preserve volatile data and logs before you wipe anything, especially if credential theft is on the table.
3. Check for the share-access-to-execution sequence: share events, dropped binaries, new services, and scheduled tasks.
4. Reset or rotate the credentials that were used, starting with any privileged account and any service account that touched multiple hosts.
5. Look for the same account or source machine hitting additional systems over the same time window.
6. Validate that the remediation did not just remove a visible file while leaving a reusable credential or access token behind.

I would be careful not to overfocus on the payload name. In SMB-driven incidents, the interesting part is often the path, not the tool. If the attacker already has a valid account, deleting one binary can be cosmetic while the real access remains intact. The final step is therefore to lock in a baseline that makes the next attempt materially harder.

The baseline I would ship first in a mixed Windows estate

If I had to start from zero, I would keep the list short and boring, because boring controls are the ones that survive procurement, operations, and change control. In practice, this is the first pass I would put in place:

• Disable SMBv1 everywhere and keep SMBv2/SMBv3 as the only supported dialects.
• Block inbound SMB on endpoints that do not host shares or serve a clear business function.
• Allow outbound SMB only to approved domain controllers, file servers, and other named infrastructure.
• Require SMB signing, and turn on encryption for shares that carry sensitive data or cross less-trusted network segments.
• Forward SMB and Windows security events centrally so that share access, service installation, and remote execution can be correlated.

My rule of thumb is simple: if a workstation can freely reach another workstation over SMB, the network is already too flat. If a file share can be reached without signing or encryption, the path is too easy to abuse. And if your detections only start after the payload runs, you are seeing the problem late.