Building on my previous article, in this article we will adopt the “Immutable Artifacts” methodology to detect such artifacts for enabling/disabling RDP connections on a Windows machine.

The registry architecture for RDP connections is quite complex, and there are many keys that can be changed to modify various RDP related settings. For our purpose, we will focus only on artifacts that are related to disabling and enabling RDP connections.

In my attempt, I have changed those settings using the UI slider from the “Remote Desktop” part of the control panel, which looks like this:

As you can see, RDP is currently disabled on my machine. In order to find the immutable artifacts, I have used “Procmon” with the following filters:

When I changed the slider to “Enable”, the following logs are generated in Procmon:

So when we enable RDP connections on a machine, the following MUST happen:

• HKLM\System\CurrentControlSet\Control\Terminal Server\fDenyTSConnections -> Value set to 0
• HKLM\System\CurrentControlSet\Control\Terminal Server\updateRDStatus -> Value set to 1
• It is important to note, even if the above keys are set correctly for enabling RDP — as long as “fEnableWinStation” is set to 0, you will not be able to connect to that machine via RDP. It must be set to 1, but that change does not happen when you enable/disable RDP via the UI slider.

Attempting to use WMIC to evade detection

If we take Metasploit as an example, even in the builtin “getgui” command and using the post-exploit module of post/windows/manage/enable_rdp, which allows us to add a user with RDP access, it utilizes changing the value of fDenyTSConnections

We can also try to interact with WMIC to attempt to bypass this using the command:

And then we can use procmon to see if this does something:

No luck here! using WMIC also must interact with fDenyTSConnections

Detection opportunities

Remember to make sure to enable SACL auditing on that key and that you’re also auditing registry via Group Policy

A sophisticated enough attacker might be able to hook certain API calls or use injection/memory patching techniques to enable RDP access without directly modifying fDenyTSConnections, but that is something I am lacking the knowledge to test. For the vast majority of cases based on what is observed “in the wild”, the following is very much sufficient:

This activity can be detected by either utilizing Event ID 4657, where the Object Name contains fDenyTSConnections

Or by utilizing Sysmon event id 13

If you enjoyed the article, feel free to connect with me!
https://www.linkedin.com/in/daniel-koifman-61072218b/
https://medium.com/@koifsec
https://detections.xyz/