Abuse SCCM Remote Control as Native VNC
20 October 2024
Last updated
20 October 2024
Last updated
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.
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.
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.
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.
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.
Reconfigure the SCCM remote control setting does not require service restart. CmRcService service will read the configurations in the registry for every new connection.
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 a few years ago.
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.
Add local/domain users to PermittedViewers means these users will be automatically added to the local group "ConfigMgr Remote Control Users".
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.
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 theCcmExec SCCM client service. The CcmExec service monitors changes in the SCCM remote control setting in WMI and updates the remote control service (CmRcService) accordingly.
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:
https://github.com/netero1010/SCCMVNC
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.
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.
