Add COM and TypeLib per-user hijacking hunts (T1546.015, T1574.008)

[clivoa]

What this adds

Two hunting queries for related COM-family persistence routes, both absent from queries/ today:

• com_hijacking_per_user_clsid_server.yml (T1546.015)
• typelib_hijacking_per_user_registration.yml (T1574.008)

Both are per-user registry hijacks: the attacker writes a key under HKCU that shadows the machine-wide entry, so their code runs with no admin rights when the COM object or type library is resolved.

How they work

Both key on registry value writes (AsepValueUpdate or RegGenericValueUpdate, so the hunt does not depend on which one a tenant emits) under a real user SID (\REGISTRY\USER\S-1-5-21-...), which excludes SYSTEM and the service accounts.

• COM: RegObjectName matches a CLSID\{GUID} server key, InprocServer32, LocalServer32 or TreatAs. All three are valid hijack points, not only InprocServer32.
• TypeLib: RegObjectName matches a TypeLib\{GUID}\...\win32 (or win64/win16) platform key.

Each then uses a case block to rank what the key now resolves to. The high-confidence rows are a script moniker or remote path and, for TypeLib, a scriptlet or script host; the user-writable-path and plain per-user cases are there to review against a baseline. The Reason field carries that label so a hunter triages the sharp cases first.

Duplicates check

Browsed queries/. There is COM/scheduled-task content (tasks_scheduled_with_ComHandler.yml) but nothing for CLSID server hijacking or TypeLib hijacking, so these do not overlap an existing file.

Testing

• Both pass the repo validator: python .github/scripts/validate_single.py queries/<file>.yml returns valid for each, so the Validate Queries check should pass.
• The CQL is written against CrowdStrike's documented registry event schema (AsepValueUpdate/RegGenericValueUpdate, RegObjectName, RegValueName, RegStringValue) and uses only standard CQL (in, inline regex, case, table, sort).

Caveat, stated in each query

I do not have a live Falcon tenant to run these against, so each query's explanation says so and asks the reader to confirm the event_simpleName values and field names against their own registry telemetry before relying on it. If your telemetry records these writes under a different event, the first filter is the one to adjust. Happy to refine either query if a maintainer can check the field names against real data.

[dweissbacher]

Thanks @clivoa, and thanks for flagging that these were untested. I ran both against a live tenant.

TypeLib: zero TypeLib{GUID} writes in four weeks against 1,400+ CLSID writes. The sensor doesn't appear to record these keys, so the query has nothing to match. Also, T1546.015 fits better than T1574.008.

COM: runs, but every row over four weeks was benign (toast activators, Store apps, OneDrive/Teams/EdgeUpdate), and the user-writable tier was all Microsoft updaters. Getting it to a useful signal took an exclusion stage built from that one fleet's data, and those exclusions are specific enough that I doubt they'd transfer. Per-user COM registration is so common in legitimate software that a general-purpose version of this hunt is hard to write without either drowning in noise or overfitting to one environment.

Closing this one. If you find an angle that narrows it down, for example limiting to CLSIDs known to be loaded by high-value processes, I'd be glad to review a fresh submission.