Home/ATT&CK Technique/Component Object Model and Distributed COM
ATT&CK Technique

Component Object Model and Distributed COM

T1175 · lateral-movement, execution
▤ Generate a SIEM detection for T1175 ◈ Deployable detections for T1175 ⚠ CVEs mapped to T1175 ♛ Hunt package for T1175

This technique has been deprecated. Please use Distributed Component Object Model and Component Object Model. Adversaries may use the Windows Component Object Model (COM) and Distributed Component Object Model (DCOM) for local code execution or to execute on remote systems as part of lateral movement. COM is a component of the native Windows application programming interface (API) that enables interaction between software objects, or executable code that implements one or more interfaces.

Through COM, a client object can call methods of server objects, which are typically Dynamic Link Libraries (DLL) or executables (EXE). DCOM is transparent middleware that extends the functionality of Component Object Model (COM) beyond a local computer using remote procedure call (RPC) technology. Permissions to interact with local and remote server COM objects are specified by access control lists (ACL) in the Registry.

By default, only Administrators may remotely activate and launch COM objects through DCOM. Adversaries may abuse COM for local command and/or payload execution. Various COM interfaces are exposed that can be abused to invoke arbitrary execution via a variety of programming languages such as C, C++, Java, and VBScript.

Specific COM objects also exists to directly perform functions beyond code execution, such as creating a Scheduled Task/Job, fileless download/execution, and other adversary behaviors such as Privilege Escalation and Persistence. Adversaries may use DCOM for lateral movement. Through DCOM, adversaries operating in the context of an appropriately privileged user can remotely obtain arbitrary and even direct shellcode execution through Office applications as well as other Windows objects that contain insecure methods.

DCOM can also execute macros in existing documents and may also invoke Dynamic Data Exchange (DDE) execution directly through a COM created instance of a Microsoft Office application, bypassing the need for a malicious document.

Windows
▸ How to use this page - the detection-engineering loop
Attackers have goals (tactics - “get credentials”, “move laterally”) and techniques are the concrete methods they use to reach them. This page is one method - T1175 - broken into everything you need to catch it.
The loop this page is built for (this is the job):
  1. Understand the behaviour - read the description and the Atomic Tests to see exactly what the attacker does on a host or network.
  2. Find the telemetry - what data source would reveal it (process creation, registry, network flow, auth logs). Detection Coverage shows which surfaces already have a rule and which are blind.
  3. Get or write the detection - adapt ready logic (CAR Analytics, SIEM Detections, Falco, or Sigma via Generate a SIEM detection), or author your own.
  4. Test it - run an Atomic Test in a lab and confirm your rule actually fires. A detection you have not tested is a hope, not coverage.
  5. Deploy and tune - push it, then watch for false positives and adjust.
What each panel is for:
Atomic Testssafely reproduce the technique in a lab to validate that a detection fires. Detection Coveragewhich detection surfaces have a rule for this technique; none is a blind spot to close, or simply not applicable (YARA matches files, not network behaviour). CAR / SIEM / Falcoready-made detection logic (Splunk SPL, Elastic EQL, Sentinel KQL, Falco) you adapt to your own SIEM. Mitigationsreduce exposure so the technique is harder to use at all - prevent, not just detect. Actors / Attributionwho actually uses this, so you prioritise by your own threat model. Attack Path / LOTLwhat attackers do before and after this step, and the legitimate tools they abuse to do it.
Where this fits: you usually arrive here from a CVE (“which techniques does it enable”) and leave with a tested detection deployed. The buttons above jump straight to building one, the deployable rules, the CVEs that use T1175, and a hunt package.
◈

Detection Coverage

0/9 layers
Coverage across standard detection surfaces. Rows marked none have no rule of that type mapped. Some are real blind spots worth closing; others are simply not applicable to this technique (e.g. YARA matches malware files, not network behaviour).
Behavioral / log (Sigma) none
Analytics (MITRE CAR) none
Runtime / container (Falco) none
File / malware (YARA) none
Network (Suricata/Snort) none
Vuln scan (Nuclei) none
SIEM (Splunk ESCU) none
SIEM (Elastic) none
SIEM (Azure Sentinel) none
External lookups - second-class, for what we don’t hold ourselves
MITRE ATT&CKAtomic Red Teamcar (MITRE)
SOC and Response
CVE triage
Stack monitoring
Am I affected
IOC triage
KEV catalog
Recently exploited
Daily brief
Change tracking
Detection Engineering
Coverage workspace
Detection coverage
Coverage check
Telemetry ceiling
SIEM query builder
Sigma rules
SIEM rules
YARA rules
Network rules
D3FEND
Threat Hunting
Threat actors
ATT&CK techniques
Attack paths
Indicators
Atomic tests
Red Team and Pentest
Exploitability triage
Recon pack
Attack paths
CAPEC patterns
Adversary emulation
Compliance and GRC
Framework mapping
Control assessment
Audit view
Atlas Search Threat actors Techniques Tools & malware CWE CAPEC KEV catalog Package vulns
About All capabilities Pricing API docs Privacy policy Terms of service
threatengine.sh