How do attackers use the Component Object Model?

How attackers turn COM into a trusted execution path

Attackers abuse the component object model because it gives them a way to invoke functionality through normal Windows interfaces instead of launching obviously malicious binaries. That matters when the goal is to blend in, reduce script-blocking friction, or ride along with applications that are already allowed to use COM. The core risk is not COM itself, but the trust defenders place in legitimate-looking object creation and activation.

In practice, this often means using COM to start code indirectly, to execute within a host process that already has access, or to make malicious activity look like ordinary application behaviour. That is why defenders should treat unexpected COM activation as an execution signal, not just a configuration detail. ATT&CK-oriented defenders can use MITRE ATT&CK Guide for Defenders to map those observations to detection logic and technique coverage, and to place COM abuse in the wider execution and persistence picture.

Why COM abuse is useful to an attacker

COM is attractive because it can let attackers inherit trust from signed software, Office automation, or other approved components. That lowers the chance that simple application controls or basic allowlists will notice the action. It also gives attackers a flexible way to reach functionality that may be awkward to invoke directly from a script, macro, or launcher.

COM abuse is especially effective when the attacker is trying to move from initial execution to a more stable foothold. A malicious actor may use COM not only to run code, but also to plant a control path that survives reboots or user activity. That is why COM-related activity should be reviewed alongside broader persistence behaviour, not as an isolated event. The Persistence Techniques Guide is useful here because COM hijacking is often one piece of a larger persistence chain.

COM also helps attackers hide in the noise of normal Windows administration and application automation. If an environment already relies on macro-driven workflows, shell extensions, scheduled automation, or application add-ins, then malicious COM use can look routine unless defenders know which registrations, parent-child chains, and activation patterns are normal for each host class.

What defenders should watch for first

The most useful starting point is to compare observed COM usage against the host’s expected baseline. Sudden registrations, new CLSIDs or InprocServer32 paths, unusual COM object creation from Office, script hosts, browsers, or service processes, and activation from user context into privileged context are all worth attention. Parent-child process chains matter because COM abuse often appears as indirect execution, where the initial launcher is benign-looking but the resulting process tree is not.

Review script and macro activity that instantiates COM objects unexpectedly, especially when those objects are used to launch shells, load libraries, or trigger remote administrative functions. If the same technique is appearing across multiple hosts, or if it arrives through an application that should not normally automate COM, treat it as a likely intrusion indicator rather than a one-off anomaly. For related remote execution and host-to-host patterns, Lateral Movement Guide can help distinguish COM-based execution from adjacent movement techniques that may look similar in telemetry.

COM abuse can also overlap with credential theft and post-compromise movement, so the surrounding host activity matters. If COM activation is followed by abnormal network connections, token use, or repeated child-process spawning, the issue is usually bigger than a single suspicious registration.

Risk and Threat Considerations

COM abuse is dangerous because it exploits an execution path that defenders often trust by default. The same feature that helps applications interoperate can also let an attacker hide command execution, evade weak allowlists, and pivot from user-level activity into a more durable foothold.

Failure mechanism: The attacker instantiates or hijacks a COM object so that trusted software launches or loads the malicious action on their behalf, which obscures the original source of execution and can bypass simplistic application filtering.

Impact: This can lead to stealthier code execution, harder attribution, persistence through COM registration changes, and a cleaner path to follow-on compromise such as lateral movement or credential access.

Practitioner Guidance

What to verify: Confirm which COM registrations are normal for each endpoint role, then flag new or rarely used CLSIDs, suspicious server paths, and registrations created outside approved software deployment windows. The important judgement is whether the object activation is expected for that host and application, not whether the registration itself looks syntactically valid.

Decision rule: If COM activity originates from a script host, macro-enabled document, or user process that does not normally automate COM, treat it as higher priority than a generic process anomaly. If the object creation leads to shell spawning, library loading, or unexpected child processes, escalate quickly and investigate for persistence or hands-on-keyboard activity.

Practitioner takeaway: The key defensive question is not “is COM present?”, but “is this COM activation normal for this user, application, and host role?” Once that baseline is broken, the activity should be investigated as an execution and persistence signal, not just a registry change.

Related resources from NHI Mgmt Group

• Why do attackers often check model availability before trying to generate content?
• How do attackers turn a supply-chain incident into wider NHI compromise?
• What does AI model abuse reveal about the current NHI threat surface?
• How do attackers operationalise stolen OAuth tokens at scale?