Topic starter
12/07/2026 12:17 pm
TL;DR: A new Windows lateral movement technique, BitlockMove, uses SMB, WMI/RPC, and DCOM to make BitLocker load a planted DLL under the logged-in user, then fans out if that account has broad rights, according to Zero Networks. The core lesson is that attack paths stitched from legitimate protocols are best neutralised by default-deny segmentation, not by chasing each new technique.
Editorial analysis by NHI Mgmt Group, based on content published by Zero Networks: “Blocked by Default: Stopping “BitlockMove” (BitLocker COM Hijacking) with Microsegmentation”.
Key questions
Q: What fails when SMB and RPC are open by default in Windows environments?
A: When SMB and RPC are open by default, attackers can stitch together file copy, remote registry modification, and COM execution into a lateral movement chain.
Q: Why does broad user access make BitLocker COM hijacking more dangerous?
A: Broad user access increases the blast radius after the DLL is loaded because the attack executes in the context of the current user.
Q: How do organisations know if lateral movement controls are actually working?
A: They work when a compromised endpoint cannot reach other critical systems by default.
Practitioner guidance
- Enforce default-deny east-west segmentation Block peer-to-peer SMB and restrict internal RPC reachability unless a business dependency has been explicitly approved and documented.
- Tighten remote registry and RPC function exposure Limit high-port RPC paths and suppress rarely used RPC operations that allow remote registry writes or similar management actions.
- Reduce the reach of logged-in user sessions Review which internal systems a standard user context can reach and remove unnecessary administrative, share, and management access paths.
Bottom line: BitlockMove shows that an attacker can turn legitimate Windows management traffic into a lateral movement path without relying on a new exploit class.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
12/07/2026 12:31 pm
BitlockMove is a default-trust problem, not a BitLocker problem. The technique works because normal Windows management channels are permitted to talk to each other by default. That means the control failure sits in east-west reachability and remote function exposure, not in the application layer itself. Practitioners should therefore review connectivity policy before they chase technique-specific detections.
A question worth separating out:
Q: Should organisations rely on detection or blocking for new Windows lateral movement techniques?
A: 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.
👉 Read our full editorial: BitLocker COM hijacking shows why lateral movement should be blocked by default