COM is the standard procedure on how client/server apps communicate and also the optimized APIs commonly used by developers. DCOM stands for Distributed COM whole the COM means Component Object Model (COM).


In this blog post, we answer the following questions:

  1. What is Windows Distributed Component Object Model?
  2. What is setting name: DCOM: Machine Access Restrictions?
  3. How does DCOM Work?
  4. Is DCOM vulnerable to attack?
  5. Security Best Practices for DCOM
  6. How to harden DCOM


What is Windows Distributed Component Object Model


The distribution of component object models across different computers is called Distributed Component Object Model (DCOM). It means an object of the client program can request services from objects on the server program on other computers within the same network. DCOM can also be implemented on a majority of UNIX platforms and aids communication among software components across different computers within a wide area network, local area network(LAN), or over the internet. To sum up DCOM, it is a software component in the Windows operating system developed by Microsoft that allows COM objects to communicate with each other over the same network.


The History of DCOM


The history of DCOM dated to when Microsoft began modularizing its Windows and applications several years ago. The company broke them into functional compartments having well-structured ‘version safe’ interfaces. The essence of the initiative was to facilitate interoperability among Windows and applications.


While the competitors of Microsoft started building a distributed object system known as ‘CORBA,’ Microsoft felt that everyone is going ‘distributed’ while maintaining the status quo, so they added D to establish DCOM. They integrated DCOM in Windows, syncing it into virtually all versions from Windows 98, even though it was not necessary or needed. Thus, it could be said that Microsoft also had a distributed object system. The protocol is how virtually all Windows services communicate, like a Microsoft Management Console.


COM has been the baseline for various Microsoft products and technologies. It serves as a binary interoperability measure for designing reusable software components capable of interacting during runtime.


Microsoft Windows Modularization Timeline 1


Image description: Microsoft Windows Modularization Timeline


Alt text: Object Linking and Embedding> Component Object Model (COM)> ActiveX> Distributed Component Object Model


Here is a summary of Microsoft's updates to DCOM:


Phase 1: June 8 2021. Hardening changes were disabled by default. To enable them, a registry key was needed.


Phase 2: June 14 2022. Changes were now enabled by default, and could be disabled with a registry key.


Phase 3: March 14 2023. This update enabled changes by default and removed the possibility of disabling them.



Abbreviation Component Object Model Distributed Component Object Model
Execution Space Client-side Server-side
Model Interface Standard Model for distributed applications
Object Reusability Allows Does not allows
Installation Required on the machine to be used on Required on the same network
Memory Utilization Not better utilization Enhanced memory utilization


What is setting name: DCOM: Machine Access Restrictions?


DCOM: Machine Access Restrictions is the policy setting that determines which users or groups might access DCOM application remotely or locally. This setting is used to control the attack surface of the computer for DCOM applications.


You can use this policy setting to specify access permissions to all the computers to particular users for DCOM applications in the enterprise. When you specify the users or groups that are to be given permission, the security descriptor field is populated with the Security Descriptor Definition Language representation of those groups and privileges. If the security descriptor is left blank, the policy setting is defined in the template, but it is not enforced. Users and groups can be given explicit Allow or Deny privileges on both local access and remote access.


The registry settings that are created as a result of enabling the DCOM: Machine Access Restrictions in Security Descriptor Definition Language (SDDL) syntax policy setting take precedence over (have higher priority) the previous registry settings in this area. RpcSs checks the new registry keys in the Policies section for the computer restrictions, and these registry entries take precedence over the existing registry keys under OLE. This means that previously existing registry settings are no longer effective, and if you make changes to the existing settings, the computer access permissions for any users are not changed. You should take care to correctly configure their list of users and groups.


The possible values for this policy setting are:


Blank. This represents the local security policy way of deleting the policy enforcement key. This value deletes the policy and then sets it as Not defined state. The Blank value is set by using the ACL editor and emptying the list, and then pressing OK.


SDDL. This is the Security Descriptor Definition Language representation of the groups and privileges you specify when you enable this policy.


Not Defined. This is the default value.


request demo


Is DCOM connected to other protocols?


DCOM apps don’t need a particular network transport protocol (NTP) to implement client-component interaction. IT can conveniently leverage different network protocols such as NetBIOS, User Datagram Protocol, and Sequenced /Internetwork Packet Exchange. The protocol also enables security settings that the earlier protocols can employ, whether connection-based or connectionless.


How does DCOM Work?

For DCOM to work properly, COM objects must be configured properly on both of the connecting computers on the same network. The Windows Registry houses the protocol’s configuration data within three identifiers known as:

  • Class Identifiers
  • Programmatic Identifiers
  • Application Identifiers


The Class Identifier or CLSID. This is a Global Unique Identifier. Every installed program in a program has a CLSID stored by Windows. If you want to run a class, a correct CLSID will be essential, so Windows can get the direction and discover the program.


Programmer leverages the Programmatic Identifier or (PROGID) to replace complex and strict CLSID. They can be easily read and understood.


The Application Identifier (APPID) identifies every class of similar executables and the permissions needed to access it. APPID has to work appropriately for DCOM to work. Otherwise, you will get a permission error if you create a remote object.

Process of a DCOM Query

A DCOM transaction takes place in the following way:


  • The DCOM client computer prompts the remote computer to establish an object leveraging its PROGID or CLSID. Peradventure, the client goes through the APPID, and the computer verifies the CLSID via PROGID. The remote computer then assesses and verifies if the client possesses permission to create the object.



  • The remote computer verifies the application identifier of the client and checks whether the client has authorization or not. DLLHOST.exe( in case of a dll) or DCOMLaunch.exe (in case of exe) will establish the example of the class requested by the client machine. If passed, an instance of the class requested by the client will be created.


  • {Communication is successful!!!} Communication will be successful and the client will have access to all functions on the remote computer. In a situation where the APPID is misconfigured, the client lacks the correct permissions, or the CLSID is redirecting to an old version of the exe or issues, you will get a “can’t create object’ notification.



Are DCOM connections vulnerable to attacks?

Since DCOM is capable of running programs on computers many vulnerabilities exist and threat actors can exploit it to implement lateral movement attacks, thus accessing more data. To gain entry into DCOM threat actors have been known to use PowerShell to execute temporary code on the exploited system.


Major vulnerabilities are listed below:

  • Remote Procedure Call (RPC) Runtime Library Vulnerability
  • Remote Procedure Call (RPC) over HTTP Vulnerability
  • Object Identity Vulnerability
  • Remote Procedure Call Subsystem Service (RPCSS) Vulnerability

Security Best Practices for DCOM


Security of DCOM is important in any operating system because it protects the processes and the data. If DCOM is not secured then anyone with access to the network can modify the processes which may result in a breached system.


Below are the practices that should be followed for a better and secure DCOM experience:

  • Only use Windows 7 to 10 if possible, because Microsoft no longer provides support to DCOM for other versions of Windows.
  • When running DCOM, make sure that the user logged in has administrative rights. These admin rights are important for setting up DCOM.
  • After every change, you make on DCOM, either on the client-side or the server-side make sure to restart the corresponding application for changes to take effect successfully.
  • Make sure that the systems communicating with each other have the right to do so, or else DCOM will not work.
  • Regularly review and update DCOM-related registry keys as part of maintaining security best practices in the Windows operating system.


DCOM Hardening


Microsoft recently discovered a vulnerability that made them roll out hardening updates to DCOM in 3 stages.


It is essential to configure DCOM securely to avoid communication breakdown between systems that utilize DCOM. This could lead to operational downtime if you are unprepared for Microsoft’s timeline.


Here is the timeline:

MC timeline

Alt Text: DCOM Hardening Updates Timeline



It has been reported the possibility of relaying Kerberos authentication via a DCOM Connection and with so many threat actors trying to exploit a vulnerability, it is recommended to apply an appropriate patch or choose an automated remediation solution to achieve a hardened system.


System Hardening

Achieving a basic hardening posture requires allocation of time, resources and planning from IT teams; every passing day is a day that your systems are vulnerable.


Microsoft provides best practice analyzers based on role and server version that can help you further harden your systems by making recommendations. Regularly review and update DCOM-related registry keys as part of maintaining security best practices in the Windows operating system.


CalCom’s Automated Hardening Solution learns your endpoints and predicts the impact of every configuration change on endpoint functionality, indicating the possibility of outages when implementing your desired policy and ensures that the organization’s endpoints will be resilient, constantly hardened, and monitored.


cis benchmark hardening


You might be interested