Did you ever wonder how you can move laterally through internal networks? or interact with remote machines without alerting EDRs?
Let’s assume that we have valid credentials or an active session with access to a remote machine, but we are without an option for executing a process remotely in a known, expected, or a highly-monitored method (i.e. WMI, Task Scheduler, WinRM, PowerShell Remoting).

For these scenarios, the DVS framework comes to the rescue.


The DVS framework is a swiss army knife that allows you to enumerate vulnerable functions of remote DCOM objects, launch them and even launch attacks using them.

The framework is being developed with a “Red Team” mindset and uses stealth methods to compromise remote machines.

The DVS framework contains various ways to bypass remote hardening against DCOM by re-enabling DCOM access remotely and automatically grant the required permissions to the attacking user.

The framework can also revert changes on the remote machine to their original state, prior to the attack – hiding these changes from defenders.

Our main insight is that the tool can also execute commands using non-vulnerable DCOM objects through an aqsome technique (Read below about Invoke-RegisterRemoteSchema)

Compatible with PowerShell 2.0 and up

Youtube Video PoC: DVS

  • Rafel Ivgi for mentoring, and helping with the architecture mindset of the tool.
  • Thanks to Yossi Sasi for helping me to optimize the script.
  • Thanks to Gleb Glazkov for writing the mitigation and preventions section

T1021.003 – Remote Services: Distributed Component Object Model

  • Microsoft dev center referense

      [MACHINESOFTWAREpoliciesMicrosoftwindows NTDCOMMachineLaunchRestriction]

    This key change may indicate that the DVS tool has disabled the DCOM remote activation and Remote Lauchrestrictions.

  • Use an application aware firewall to block DCOM access between computers. Especially from a computer which is not part of the IT or management infrastructure.
  • Intrusion prevention system (e.g. Snort, Suricata) can be used to detect DCOM protocol which is based on RPC (MS-RPC, MS-RPCE) and Remote registry protocol (MS-RRP).
  • Monitor Windows Defender firewall by enabling audit log on blocked traffic for domain and private profiles.
  • Monitor changes to the following key. It may indicate that the DVS tool has created a rule to bypass the Microsoft Defender Firewall dynamic RPC restrictions.
  • Monitor Windows event logs:

    Enable audit of events. Audit settings that should be enabled on success and failure: Audit account logon events | Audit logon events | Audit object access | NTLM Auditing

    Browse to this registry key: [HKEY_LOCAL_MACHINESOFTWAREMicrosoftOle] Create new DWORDs with value of ‘1’ called ActivationFailureLoggingLevel | CallFailureLoggingLevel | InvalidSecurityDescriptorLoggingLevel

    • 4624 (Successful Logon) – A blue team can create correlation of events to catch connections from remote machines to DCOM. An example:
      • event ID 4624 – Logon
      • Account Name: SYSTEM
      • Process Name: C:WindowsSystem32services.exe
    • 4680 (Unkown user or bad password) – Will occur when using a wrong user or password
    • 4688 (Process Creation) – Monitor vulnerable processes that create dangerous sub processes using an administrative user. Example:
      • Creator Process Name: C:WindowsSystem32mmc.exe -> New Process Name:C:WindowsSystem32cmd.exe
      • Creator Process Name: C:WindowsSystem32svchost.exe -> New Process Name:C:WindowsSystem32mmc.exe
    • 8002 (NTLM) – Audit Incoming NTLM Traffic that would be blocked. Example:
      • Calling process name: C:WindowsSystem32mmc.exe
      • Calling process user identity: USER
      • Calling process domain identity: DOMAIN
    • 8003 (NTLM) – Audit NTLM authentication in this domain. Example:
      • User: User
      • Domain: DOMAIN
      • Workstation: ATTACKER
      • Process: C:WindowsSystem32mmc.exe / C:WindowsSystem32dllhost.exe / C:WindowsSystem32svchost.exe / C:Program FilesInternet Exploreriexplore.exe
      • Logon type: 3
    • 10010 (Microsoft-Windows-DistributedCOM) – The server %1 did not register with DCOM within the required timeout.
    • 10014 (Microsoft-Windows-DistributedCOM) – for failed CLSID activasion due to disabled remote activation settings for COM+.
    • 10015 (Microsoft-Windows-DistributedCOM) – failed DCOM execution due to insufficient permissions.
    • 10016 (Microsoft-Windows-DistributedCOM) – failed DCOM execution due to insufficient permissions. Example:
      • The machine-default permission settings do not grant Local Activation permission for the COM Server application with CLSID {C2F03A33-21F5-47FA-B4BB-156362A2F239} and APPID {316CDED5-E4AE-4B15-9113-7055D84DCC97} to the user DOMAINScorpiones
    • 10021 (Microsoft-Windows-DistributedCOM) – The launch and activation security descriptor for the COM Server application with APPID {0000000} is invalid.