DCOM Hardening: Best Practices for DCOM Windows Security

What is DCOM in Windows?

The distribution of component object models across different computers is called Distributed Component Object Model (DCOM). DCOM in Windows 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 (Distributed Component Object Model) dates 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 Technologies started building a distributed object system known as ‘CORBA,’ Microsoft felt that everyone was 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 of 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.

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.

COM vs DCOM

DCOM Alternatives

OPC UA: An alternative to DCOM is OPC UA (OPC Unified Architecture) that is firewall-friendly and can be controlled and managed via standard network techniques. This successor to the OPC DA standard offers platform independence and interoperability, making it a viable alternative to OPC Classic and DCOM.

Tunneling: To replace communication via DCOM technology, some software manufacturers have developed Tunneling. Tunneling converts data into simple TCP/IP, encrypts it, and routes it past the firewall. The data is then unpacked in the target network and provided to the OPC server. This solution can replace DCOM and serves as an alternative to DCOM encryption. If you are already using OPC UA, Tunneling is no longer necessary.

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.

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.

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.

DCOM Vulnerabilities

The potential attack vector exploiting the DCOM vulnerability is the device network. Although a successful attack requires meeting a complex set of conditions, it can lead to an elevation of privilege exploit. If a user is deceived into authenticating with a malicious machine, the attacker can relay this authentication to a victim DCOM server, steal the user’s identity, and make remote COM calls.

The Windows DCOM Server Security Feature Bypass (CVE-2021-26414) vulnerability allows attackers to elevate their privileges and gain unauthorized access to a system by exploiting how WMI connections are made through the DCOM protocol.

The solution to this complex vulnerability is hardening DCOM authentication with server-side enforcement, which is already available to you. Specifically, the updated and hardened DCOM servers enable you to verify that any client/server applications in your environment work as expected.

DCOM Hardening

This issue specifically impacts enterprise users who are domain-joined, Azure Active Directory-joined, or those using DCOM with Windows Workgroups. It does not affect general consumers. Microsoft discovered a vulnerability that made them roll out hardening updates to DCOM in 3 stages.

The following operating systems were deemed to be at risk:

• Windows Server 2008 Service Pack 2 and newer server versions
• Windows 7 and newer client OS versions
• Non-Windows DCOM clients and servers

DCOM configuration is essential to secure to avoid communication breakdown between systems that utilize DCOM. This could lead to operational downtime if you are unprepared for Microsoft’s timeline. 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.

Enable DCOM Hardening

Manage changes for Windows DCOM Server Security Feature Bypass (see KB 5004442)

• Path: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole\AppCompat
• Value Name: “RequireIntegrityActivationAuthenticationLevel”
• Type: dword
• Value Data: default = not defined = enabled (after the June 2022 update); 0x00000000 = disabled; 0x00000001 = enabled. A reboot is required when making any change to the value for “RequireIntegrityActivationAuthenticationLevel”.

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

Below are best 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.