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!

[AAtashGar]

Thanks for your help, I changed the things you said, I hope I understood the change regarding the author correctly
I appreciate you taking the time to help me merge this request.
@patel-bhavin

[nasbench]

This can be optimized by moving the filter early as well as adding conditions to the subsearch to look only for changes to the status of the service to Enabled from Disabled.

Also the field you are using are not the XML fields but the General view field. Which we do not recommend using.

Now for the condition, you are filtering for any CLSID which is not the case of the attack. But instead it targets specific CLSID. You should filter on those.

Also keep in mind that EID 4663/4657 requires a dedicated SACL in the key/value to trigger.

You need better filtering to avoid non-related matches.

[nasbench]

The grouping needs to also take into account a timespan to be more efficient since these events could occur unrelated. Add a time span of 10 minutes or so to be more efficient.

[nasbench]

You could choose the perfect names here instead of using a rename later, just use quotes if the name contains spaces

[nasbench]

Since you are using event id that require a dedicated audit policy and SACL configured. You have to provide these details in here.

What policy needs to be enabled as well as the appropriate SACLs to be configured to capture this

[nasbench]

I do not think an analytic story is necessary, since this is only one detection and 1 type of attack on this. If it was more then it would make more sense.

So in my opinion you could drop this. And move some of the details into the description of this detection.

[nasbench]

You will have to add an appropriate test section that points to the data that you uploaded.
Take a look at the detection hosted in this repo for examples.

[AAtashGar]

Thanks for your advice, I checked and corrected everything.
@nasbench