Blocked by Default: Stopping “BitlockMove” (BitLocker COM Hijacking) with Microsegmentation

TL;DR 

At TROOPERS25, security researcher Fabian Mosch (r-tec Cyber Security) showed a new way to move laterally in Windows: remotely tweak BitLocker settings so a planted file runs under the currently logged-in user on the target. If that user has broad rights, an attacker can quickly fan out. Zero Networks Segment shuts this path down by default – peer-to-peer SMB is denied and the required RPC ports aren’t open unless you’ve explicitly allowed them. No CVE chase needed – the route simply doesn’t exist in the first place. 

The Attack in a Nutshell 

1. The attacker copies a malicious DLL to the target over SMB (445). 
2. The attacker writes a new registry key over WMI / RPC (135 + high port) that specifies the DLL path. This is needed for performing the COM Hijacking in the next step. 
3. The attacker triggers a DCOM function (high RPC port) that causes BitLocker to load the copied DLL, taking its path from the created registry key.  

A deep dive into the lateral movement technique can be found on the Purple Team blog post. 

How Zero Networks Segment Breaks the Chain by Default 

Zero Networks’ automated microsegmentation creates “firewall bubbles” around every asset. East-west access is denied unless it’s learned/approved as necessary for business. That means: 

• SMB 445: Closed by default between peers, so the DLL drop fails. 
• RPC high ports: Even if 445 were allowed for legit reasons, the RPC follow-on to a dynamic high port is still blocked unless it’s part of an approved dependency. 
• RPC Segmentation: In cases where you want to enable RPC traffic (e.g. DC servers), the RPC Firewall can block rarely used RPC interfaces and operations. 

This layered approach means you don’t have to push an urgent rule for each brand-new attack technique; the default stance already prevents the lateral move.

The attack is blocked by default, already at stage #1 

…and the attacker’s view 

And even if we allow SMB (in case we have a legitimate file server), the RPC high ports would still be blocked and the attack will be prevented. 

Multi-Layered Approach 

But what happens if we have a host that requires both SMB and RPC to be open? For those edge cases, we have our RPC Firewall protection. Using the RPC Firewall, we can allow or block specific RPC functions. By default, any irregular RPC activity would be blocked out of the box: 

The RPC Firewall blocking the attack 

We can also decide to just block specific functionality, such as preventing writing remote registry keys. In this example, we created a rule to block BaseRegSetValue, the RPC function that writes registry keys. 

The RPC Firewall is only blocking the registry key creation, which still prevents the attack 

And just for the sake of completeness, this is what the attack looks like on our portal if you disable the segmentation protection (of course this not recommended, but just done here to show the entire flow of the attack).

Why This Matters (Again): Stop Chasing CVEs 

We’ve all been here: headline → PoC → scramble. Whether it’s LDAPNightmare, BadSuccessor, or now a BitLocker COM hijack pivot, the pattern is the same – legitimate protocols are stitched into a lateral path. If you only react per-CVE, you’ll always be behind. With microsegmentation, that path simply isn’t available unless you explicitly allow it. Tiring CVE sprints replaced with calm, proactive defense. Zen.