detection Lateral Movement via BitLocker COM Hijacking

[AAtashGar]

Add detection for BitLocker COM Hijacking Lateral Movement (T1546.015)

What does this PR do?

Adds a new experimental ESCU detection + analytic story for the novel BitLocker Network Unlock COM Object Hijacking technique published in August 2025.

This living-off-the-land lateral movement method:

• Enables RemoteRegistry service
• Writes a malicious DLL path to HKCU\Software\Classes\CLSID\{A7A63E5C-3877-4840-8727-C1EA9D7A4D50}\InprocServer32
• Triggers code execution via baaupdate.exe (from explorer.exe) or BdeUISrv.exe (from svchost.exe)

This is the first public detection covering this advanced technique.

Files added:

• detections/endpoint/lateral_movement_bitlocker_com_hijacking.yml
• macros/lateral_movement_bitlocker_com_hijacking_filter.yml
• stories/bitlocker_com_hijacking_lateral_movement.yml

Screenshots

Checklist

• Validate name matches <platform>_<mitre att&ck technique>_<short description> nomenclature
• [CI/CD](https://github.com/splunk/security_content/actions) jobs passed (local contentctl validate --path . → No issues)
• Validated SPL logic (tested on simulated events)
• Validated tags, description, how_to_implement, known_false_positives
• Verified references match analytic
• No lookup updates — N/A
• All lines < 80 characters, yamllint clean

Testing Performed

→ Validation Completed - No issues detected!

→ All files valid

[nasbench]

Hey @AAtashGar before reviewing this. Just wanted to ask any particular reason you want this as experimental instead of production. From your screenshot it looks like you have the data already.

Simply export it as raw and then upload it to https://github.com/splunk/attack_data as LFS with a corresponding yaml definition. (See old PRs for reference).

Or if you want you could upload the raw logs here and we will take care of it, if we deem the rule ineteresting.

[AAtashGar]

Dear @nasbench
Regarding experimental vs production: I marked it experimental because it's a novel technique (first public detection) and I used simulated data from BitlockMove repo for testing. But you're right — I have the raw logs ready. I'll export them and create a PR to splunk/attack_data with YAML definition.

Should I change status to production after adding the data? Happy to upload raw logs here if needed.

Let me know if there's anything else!

[nasbench]

@AAtashGar in this repo context. Production means tested rules aka with logs and experimental means untested. So yes once you upload the data to attack data and Link it you can switch the status and I can start reviewing it.

Cheers

[AAtashGar]

@nasbench Perfect, thanks for clarifying! Got it
I'll export the raw logs and create a PR to splunk/attack_data, After that, I'll update the status to production and push the change. Looking forward to your review
Thank you

[AAtashGar]

@nasbench Done! attack_data PR created with LFS logs and YAML definition:
splunk/attack_data#1098

Status changed to production in detection file and pushed.

Ready for review — thanks!

[patel-bhavin]

@AAtashGar - these filter macros are auto generated during build time ! can we remove this macros/ file from the PR

[patel-bhavin]

lets remove the line1 and 2

[patel-bhavin]

can you add Ali Atashgar (AAtashGar), Github Community

[patel-bhavin]

can we perhaps add more details to this description?

[patel-bhavin]

can you add Ali Atashgar (AAtashGar), Github Community

[patel-bhavin]

Lets remove this line 1

[patel-bhavin]

update this type to TTP