Persistence is where an intrusion stops being an incident and becomes a tenancy. Of the techniques available, COM hijacking is among the quietest: it writes no executable to disk, it needs no administrative rights, and it leaves a trace that looks, to most monitoring, like ordinary application behaviour.
It maps to MITRE ATT&CK T1546.015 — Event Triggered Execution: Component Object Model Hijacking. This is what it is, why it is hard to see, and what actually catches it.
Why attackers want persistence at all
Once an attacker has a foothold, re-using the original access route is the riskiest thing they can do — especially if it was a complex exploit or a one-shot vector that cannot be reliably repeated. Persistence removes that need. The common mechanisms:
- Scheduled tasks — execution at a set time or at boot, often with elevated privilege. Effective, and noisy: task creation is a well-monitored event.
- Service installation — a covert backdoor masquerading as a legitimate system service. Also well monitored.
- Fileless persistence — in-memory execution through PowerShell or WMI, avoiding the filesystem and the detections built around it.
COM hijacking sits in the third category and is quieter than most of it.
What COM hijacking actually is
The Component Object Model is how Windows components talk to each other. Applications instantiate COM objects constantly — by CLSID, a GUID that the system resolves through the registry to find the DLL that implements it.
The weakness is one of precedence. Windows resolves a CLSID by checking the current user's registry hive before the machine-wide one. A user-writable location is consulted first, and a standard user can write there without any elevation.
An unprivileged user can register a COM object that shadows a legitimate system one. Any process that later instantiates that object loads the attacker's code instead — with the privileges and the reputation of whatever process did the instantiating.
That is the whole technique. No exploit, no vulnerability, no admin rights, no file dropped in a monitored location. The registry entry is the payload's entire footprint.
The related shell-handler variant
A close cousin abuses file-association and shell "open" handlers rather than CLSID registration — the registry entry that tells Windows what to run when a given file type or management console is opened. Redirect one of those and the next routine administrative action launches something else instead, inheriting the context of the process that started it. It is frequently discussed alongside COM hijacking and it is worth understanding the difference: one shadows a component, the other shadows a handler. Both rely on the same user-writable precedence.
We are not publishing the specific keys and values to set. The technique is publicly documented and our interest is in what the resulting telemetry looks like.
Why it is hard to detect
- Nothing is written to disk in the places that get watched. The persistence is a registry value.
- The executing process is legitimate. A trusted Windows binary loads the attacker's code, so process-reputation checks pass.
- Execution is user-triggered. The payload runs when someone opens the application they always open, so timing looks like normal work.
- No elevation is required, so nothing trips the detections built around privilege escalation.
- Forensic evidence is minimal — one registry key among hundreds of thousands, in a hive where applications legitimately write.
Detecting it
Registry telemetry is the whole game here, and the key insight is about location rather than content.
What to monitor
- CLSID registration in the per-user hive. A CLSID appearing under the current user's classes that also exists machine-wide is the core indicator — a legitimate application rarely needs to shadow a system component. This single condition catches the technique regardless of payload.
- Changes to shell open and file-association handlers, particularly for management consoles and administrative file types.
- COM server paths pointing somewhere unusual — a user profile directory, a temporary folder, or a DLL whose name resembles a system one.
- Trusted Windows binaries loading DLLs from user-writable paths. This is the second-order detection and it catches a broad class of attacks, not just this one.
Making it practical
Registry monitoring produces enormous volume, so the rule has to be specific or it gets tuned out — and a rule that has been tuned out is not a control. Two things make it workable:
- Baseline first. Establish which CLSIDs are legitimately registered per-user in your estate. In most environments the list is short and stable, which makes anything new genuinely interesting.
- Alert on the shadow condition, not on writes. Do not alert on registry modification. Alert on a per-user registration that overlaps a machine-wide one.
Sysmon with a filtered configuration covers this, as does EDR registry telemetry where it is enabled — which it often is not, because of the volume.
Preventing and limiting it
- Application control. If unsigned or user-writable DLLs cannot load, the hijack registers successfully and then fails to do anything. This is the only control that closes the technique rather than observing it.
- Least privilege limits what an attacker reaches afterwards. It does not prevent this — no elevation is needed — but it constrains the outcome.
- Audit persistence as a routine exercise. Autoruns-style review across the estate catches what real-time monitoring missed, and finds the hijack that predates your current tooling.
- Test it. A purple team exercise that plants a benign COM hijack answers the only question that matters: did your EDR see it, did an alert fire, and did anyone act on it.
Why this is worth your attention
COM hijacking is a good illustration of a whole class of problem. It is not a vulnerability, so no patch addresses it. It abuses a mechanism Windows depends on, so it cannot be disabled. It needs no privilege, so the controls built around privilege do not apply. And the code runs inside a legitimate process, so reputation-based defences pass it through.
What detects it is knowing what normal looks like in a part of the registry most organisations have never baselined — and having someone watching who understands why a per-user CLSID shadowing a system one is worth getting out of bed for.