Blocking has to come first when the attack path depends on routine Windows protocols. Detection is still useful, but it becomes a backstop rather than the primary defence. If the environment allows SMB, RPC, and DCOM by default, every new technique forces a race that defenders are likely to lose.
Why blocking matters before detection when Windows lateral movement rides on default protocols
New Windows lateral movement techniques usually do not invent a fresh transport, they abuse what is already trusted. If SMB, RPC, and DCOM remain broadly reachable, an attacker can keep testing variants until one lands. Blocking reduces the attacker’s path length and turns many new tricks into noisy failures instead of reliable execution.
Detection still matters, but it is slower to pay off when the control plane is already open. Once a lateral move is possible through routine Windows administration paths, defenders are forced into signature chasing and behavioural tuning while the technique evolves.
A useful way to think about this is that blocking narrows the problem to a smaller number of exceptions and approved administration flows. Detection then becomes a confirmation layer for what slipped past policy, rather than the only thing standing between a new technique and spread.
Where the control boundary should sit in Windows environments
The practical boundary is not “can we see it?”, but “should this host talk to that host in this way at all?”. In many estates, the answer is no for most endpoints and yes only for tightly defined management channels. That means segmentation, local firewall policy, and administrative scoping are part of the lateral movement answer, not just network hygiene.
This is especially important because lateral movement techniques often reuse native authentication and remote management paths. When the environment treats those paths as normal, a defender cannot reliably distinguish legitimate admin activity from attacker movement based on protocol alone. The control objective is to make legitimate use narrow, explicit, and auditable.
Blocking also helps force attacker trade-offs. If one remote method is denied, the attacker may need to escalate privileges, pivot through another tier, or expose itself through more distinctive behaviour. That is useful even when the eventual detection capability is imperfect.
Detection should validate exposure, not carry the full burden
Detection remains valuable for catching mis-scoped allow rules, unexpected admin use, and movement that occurs through approved channels. It is also the only realistic way to understand whether blocking is actually working at scale. But if detection is the primary defence, every new Windows technique becomes a race between attacker adaptation and analyst coverage.
In practice, the strongest posture is to detect for verification and investigation while relying on blocking to reduce the attack surface. That means monitoring should focus on exceptions, unusual source-to-destination pairs, and administrative behaviour that does not match known operations, rather than assuming alerting alone can prevent spread.
For organisations running mixed legacy and modern Windows estates, the hardest part is often not technical possibility but operational discipline. If exceptions accumulate faster than they are reviewed, the environment quietly reverts to an attacker-friendly model where lateral movement is only one missed detection away.
Risk and Threat Considerations
When SMB, RPC, and DCOM are left broadly available, new lateral movement techniques do not need to break the platform, they only need to exploit routine trust. That creates exposure to rapid propagation, privilege escalation, and noisy-but-successful pivoting across otherwise well-managed Windows estates.
Failure mechanism: Attackers abuse allowed remote administration and inter-host communication paths, then iterate across protocol variants until one succeeds or until they obtain credentials or permissions that unlock broader movement.
Impact: A single compromised host can become a launch point for domain-wide reach, making containment depend on speed of response rather than on preventive control.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1021 — Remote Services | Windows lateral movement commonly abuses remote services and admin protocols. |
| Recommendation — Restrict remote services and hunt for abuse of allowed Windows remote administration paths. | ||
| NIST SP 800-53 Rev 5 | SC-7 — Boundary Protection | Blocking SMB, RPC, and DCOM depends on network boundary enforcement between hosts. |
| AC-6 — Least Privilege | Lateral movement succeeds faster when remote administration rights are too broad. | |
| Recommendation — Enforce boundary rules that deny unnecessary east-west Windows traffic by default. Limit administrative reach so compromised accounts cannot pivot broadly across Windows systems. | ||
| CIS Controls v8 | CIS-12 — Network Infrastructure Management | Windows lateral movement defense depends on controlling network paths and segmentation. |
| CIS-6 — Access Control Management | Preventing movement requires tight control over who can remotely access which systems. | |
| Recommendation — Segment Windows networks and remove unnecessary host-to-host communication paths. Review and remove remote access paths that are not explicitly required for operations. | ||
Practitioner Guidance
What to prioritise: Reduce east-west Windows reachability first, then tune detection around the approved management paths that remain. If a connection is not required for administration, block it by default.
What to verify: Confirm that the block policy is enforced between workstation tiers, server tiers, and administrative jump points, and that exceptions are owned, documented, and time-bounded.
Common mistake: Treating broad protocol availability as harmless because alerting exists. If detection is expected to catch every novel movement technique, the control model is already backward.
Practitioner takeaway: For Windows lateral movement, prevention has to shrink the attack path before detection can add meaningful value; otherwise every new technique becomes an operational response exercise.
Related resources from NHI Mgmt Group
- What breaks when organisations rely on detection but leave lateral movement paths open?
- What do security teams get wrong about Windows lateral movement techniques like BitlockMove?
- Why does network-based intrusion detection matter more when organisations need to spot ransomware, lateral movement, and scanning early?
- What breaks when organisations rely on monitoring alone to stop lateral movement?