On the Surface Pro, try checking in Control Panel All Control Panel Items Windows Firewall Allowed apps, and make sure 'Remote Desktop Connection' is allowed to pass through. Make sure Remote Desktop Connection is enabled also. Control Panel All Control Panel Items System Remote Settings. See if any other security software is blocking you. If you’ve changed the Remote Desktop Port or added another Remote Desktop Listening Port in Windows 10 and your Firewall is active you will need to manually create a rule to allow incoming connection on the new port. Here’s how to add a new TCP rule for RDP in the Windows 10 Firewall. Did this help you out? Like the video!Have another problem? Let me know in the comments Buy Me a Coffee? This tutorial I wil. Enable Remote Connections on Remote PC. Step 1: Press Windows key + R to open a Run dialog.
-->Jun 24, 2019 Firewall rules can be created to restrict Remote Desktop access so that only a specific IP address or a range of IP addresses can access a given device. This can be achieved by simply opening “Windows Firewall with Advanced Security,” clicking on Inbound Rules and scrolling down to the RDP rule. A screen shot can be seen below.
Use these steps when a Remote Desktop client can't connect to a remote desktop but doesn't provide messages or other symptoms that would help identify the cause.
Check the status of the RDP protocol
Check the status of the RDP protocol on a local computer
To check and change the status of the RDP protocol on a local computer, see How to enable Remote Desktop.
Note
If the remote desktop options are not available, see Check whether a Group Policy Object is blocking RDP.
Check the status of the RDP protocol on a remote computer
Important
Follow this section's instructions carefully. Serious problems can occur if the registry is modified incorrectly. Before you start modifying the registry, back up the registry so you can restore it in case something goes wrong.
To check and change the status of the RDP protocol on a remote computer, use a network registry connection:
- First, go to the Start menu, then select Run. In the text box that appears, enter regedt32.
- In the Registry Editor, select File, then select Connect Network Registry.
- In the Select Computer dialog box, enter the name of the remote computer, select Check Names, and then select OK.
- Navigate to HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlTerminal Server.
- If the value of the fDenyTSConnections key is 0, then RDP is enabled.
- If the value of the fDenyTSConnections key is 1, then RDP is disabled.
- To enable RDP, change the value of fDenyTSConnections from 1 to 0.
Check whether a Group Policy Object (GPO) is blocking RDP on a local computer
If you can't turn on RDP in the user interface or the value of fDenyTSConnections reverts to 1 after you've changed it, a GPO may be overriding the computer-level settings.
To check the group policy configuration on a local computer, open a Command Prompt window as an administrator, and enter the following command:
After this command finishes, open gpresult.html. In Computer ConfigurationAdministrative TemplatesWindows ComponentsRemote Desktop ServicesRemote Desktop Session HostConnections, find the Allow users to connect remotely by using Remote Desktop Services policy.
If the setting for this policy is Enabled, Group Policy is not blocking RDP connections.
If the setting for this policy is Disabled, check Winning GPO. This is the GPO that is blocking RDP connections.
Check whether a GPO is blocking RDP on a remote computer
To check the Group Policy configuration on a remote computer, the command is almost the same as for a local computer:
The file that this command produces (gpresult-<computer name>.html) uses the same information format as the local computer version (gpresult.html) uses.
Modifying a blocking GPO
You can modify these settings in the Group Policy Object Editor (GPE) and Group Policy Management Console (GPM). For more information about how to use Group Policy, see Advanced Group Policy Management.
To modify the blocking policy, use one of the following methods:
- In GPE, access the appropriate level of GPO (such as local or domain), and navigate to Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Connections > Allow users to connect remotely by using Remote Desktop Services.
- Set the policy to either Enabled or Not configured.
- On the affected computers, open a command prompt window as an administrator, and run the gpupdate /force command.
- In GPM, navigate to the organizational unit (OU) in which the blocking policy is applied to the affected computers and delete the policy from the OU.
Check the status of the RDP services
On both the local (client) computer and the remote (target) computer, the following services should be running:
- Remote Desktop Services (TermService)
- Remote Desktop Services UserMode Port Redirector (UmRdpService)
You can use the Services MMC snap-in to manage the services locally or remotely. You can also use PowerShell to manage the services locally or remotely (if the remote computer is configured to accept remote PowerShell cmdlets).
On either computer, if one or both services are not running, start them.
Note
If you start the Remote Desktop Services service, click Yes to automatically restart the Remote Desktop Services UserMode Port Redirector service.
Check that the RDP listener is functioning
Important
Follow this section's instructions carefully. Serious problems can occur if the registry is modified incorrectly. Before you starty modifying the registry, back up the registry so you can restore it in case something goes wrong.
Check the status of the RDP listener
For this procedure, use a PowerShell instance that has administrative permissions. For a local computer, you can also use a command prompt that has administrative permissions. However, this procedure uses PowerShell because the same cmdlets work both locally and remotely.
To connect to a remote computer, run the following cmdlet:
Enter qwinsta.
If the list includes rdp-tcp with a status of Listen, the RDP listener is working. Proceed to Check the RDP listener port. Otherwise, continue at step 4.
Export the RDP listener configuration from a working computer.
- Sign in to a computer that has the same operating system version as the affected computer has, and access that computer's registry (for example, by using Registry Editor).
- Navigate to the following registry entry:
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlTerminal ServerWinStationsRDP-Tcp - Export the entry to a .reg file. For example, in Registry Editor, right-click the entry, select Export, and then enter a filename for the exported settings.
- Copy the exported .reg file to the affected computer.
To import the RDP listener configuration, open a PowerShell window that has administrative permissions on the affected computer (or open the PowerShell window and connect to the affected computer remotely).
To back up the existing registry entry, enter the following cmdlet:
To remove the existing registry entry, enter the following cmdlets:
To import the new registry entry and then restart the service, enter the following cmdlets:
Replace <filename> with the name of the exported .reg file.
Test the configuration by trying the remote desktop connection again. If you still can't connect, restart the affected computer.
If you still can't connect, check the status of the RDP self-signed certificate.
Check the status of the RDP self-signed certificate
- If you still can't connect, open the Certificates MMC snap-in. When you are prompted to select the certificate store to manage, select Computer account, and then select the affected computer.
- In the Certificates folder under Remote Desktop, delete the RDP self-signed certificate.
- On the affected computer, restart the Remote Desktop Services service.
- Refresh the Certificates snap-in.
- If the RDP self-signed certificate has not been recreated, check the permissions of the MachineKeys folder.
Check the permissions of the MachineKeys folder
- On the affected computer, open Explorer, and then navigate to C:ProgramDataMicrosoftCryptoRSA.
- Right-click MachineKeys, select Properties, select Security, and then select Advanced.
- Make sure that the following permissions are configured:
- BuiltinAdministrators: Full control
- Everyone: Read, Write
Check the RDP listener port
On both the local (client) computer and the remote (target) computer, the RDP listener should be listening on port 3389. No other applications should be using this port.
Important
Follow this section's instructions carefully. Serious problems can occur if the registry is modified incorrectly. Before you starty modifying the registry, back up the registry so you can restore it in case something goes wrong.
To check or change the RDP port, use the Registry Editor:
- Go to the Start menu, select Run, then enter regedt32 into the text box that appears.
- To connect to a remote computer, select File, and then select Connect Network Registry.
- In the Select Computer dialog box, enter the name of the remote computer, select Check Names, and then select OK.
- Open the registry and navigate to HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlTerminal ServerWinStations<listener>.
- If PortNumber has a value other than 3389, change it to 3389.
Important
You can operate Remote Desktop services using another port. However, we don't recommend you do this. This article doesn't cover how to troubleshoot that type of configuration.
- After you change the port number, restart the Remote Desktop Services service.
Check that another application isn't trying to use the same port
For this procedure, use a PowerShell instance that has administrative permissions. For a local computer, you can also use a command prompt that has administrative permissions. However, this procedure uses PowerShell because the same cmdlets work locally and remotely.
Open a PowerShell window. To connect to a remote computer, enter Enter-PSSession -ComputerName <computer name>.
Enter the following command:
Look for an entry for TCP port 3389 (or the assigned RDP port) with a status of Listening.
Note
The process identifier (PID) for the process or service using that port appears under the PID column.
To determine which application is using port 3389 (or the assigned RDP port), enter the following command:
Look for an entry for the PID number that is associated with the port (from the netstat output). The services or processes that are associated with that PID appear on the right column.
If an application or service other than Remote Desktop Services (TermServ.exe) is using the port, you can resolve the conflict by using one of the following methods:
- Configure the other application or service to use a different port (recommended).
- Uninstall the other application or service.
- Configure RDP to use a different port, and then restart the Remote Desktop Services service (not recommended).
Check whether a firewall is blocking the RDP port
Use the psping tool to test whether you can reach the affected computer by using port 3389.
Go to a different computer that isn't affected and download psping from https://live.sysinternals.com/psping.exe.
Open a command prompt window as an administrator, change to the directory in which you installed psping, and then enter the following command:
Check the output of the psping command for results such as the following:
- Connecting to <computer IP>: The remote computer is reachable.
- (0% loss): All attempts to connect succeeded.
- The remote computer refused the network connection: The remote computer is not reachable.
- (100% loss): All attempts to connect failed.
Run psping on multiple computers to test their ability to connect to the affected computer.
Note whether the affected computer blocks connections from all other computers, some other computers, or only one other computer.
Recommended next steps:
- Engage your network administrators to verify that the network allows RDP traffic to the affected computer.
- Investigate the configurations of any firewalls between the source computers and the affected computer (including Windows Firewall on the affected computer) to determine whether a firewall is blocking the RDP port.
RDP on the Radar
Recently, McAfee released a blog related to the wormable RDP vulnerability referred to as CVE-2019-0708 or “Bluekeep.” The blog highlights a particular vulnerability in RDP which was deemed critical by Microsoft due to the fact that it exploitable over a network connection without authentication. These attributes make it particularly ‘wormable’ – it can easily be coded to spread itself by reaching out to other accessible networked hosts, similar to the famous EternalBlue exploit of 2017. This seems particularly relevant when (at the time of writing) 3,865,098 instances of port 3389 are showing as open on Shodan.
Prior to this, RDP was already on our radar. Last July, McAfee ATR did a deep dive on Remote Desktop Protocol (RDP) marketplaces and described the sheer ease with which cybercriminals can obtain access to a large variety of computer systems, some of which are very sensitive. One of the methods of RDP misuse that we discussed was how it could aid deploying a targeted ransomware campaign. At that time one of the most prolific targeted ransomware groups was SamSam. To gain an initial foothold on its victims’ networks, SamSam would often rely on weakly protected RDP access. From its RDP launchpad, it would proceed to move laterally through a victim’s network, successfully exploiting and discovering additional weaknesses, for instance in a company’s Active Directory (AD).
In November 2018, the FBI and the Justice department indicted two Iranian men for developing and spreading the SamSam ransomware extorting hospitals, municipalities and public institutions, causing over $30 million in losses. Unfortunately, this did not stop other cybercriminals from using similar tactics, techniques and procedures (TTPs).
The sheer number of vulnerable systems in the wild make it a “target” rich environment for cybercriminals.
In the beginning of 2019 we dedicated several blogs to the Ryuk ransomware family that has been using RDP as an initial entry vector. Even though RDP misuse has been around for many years, it does seem to have gained an increased popularity amongst criminals focused on targeted ransomware.
Recent statistics showed that RDP is the most dominant attack vector, being used in 63.5% of disclosed targeted ransomware campaigns in Q1 of 2019.
Source: Coveware Q1 statistics
Securing RDP
Given the dire circumstances highlighted above it is wise to question if externally accessible RDP is an absolute necessity for any organization. It is also wise to consider how to better secure RDP if you are absolutely reliant on it. The good news is there are several easy steps that help an organization to better secure RDP access.
That is why, in this blog, we will use the adversarial knowledge from the McAfee ATR red team to explain what easy measures can be undertaken to harden RDP access.
Recommendations are additional to standard systems hygiene which should be carried out for all systems (although it becomes more important for Internet connected hosts), such as keeping all software up-to-date, and we intentionally avoid ‘security through obscurity’ items such as changing the RDP port number.
Do not allow RDP connections over the open Internet
To be very clear… RDP should never be open to the Internet. The internet is continuously being scanned for open port 3389 (the default RDP port). Even with a complex password policy and multi-factor authentication you can be vulnerable to denial of service and user account lockout. A much safer alternative is to use a Virtual Private Network (VPN). A VPN will allow a remote user to securely access their corporate network without exposing their computer to the entire Internet. The connection is mutually encrypted, providing authentication for both client and server, preferably using a dual factor, while creating a secure tunnel to the corporate network. As you only have access to the network you will still need to RDP to the computer but can do so more securely without exposing it to the internet.
Use Complex Passwords
An often-used alternative acronym for RDP is “Really Dumb Passwords.” That short phrase encapsulates the number one vulnerability of RDP systems, simply by scanning the internet for systems that accept RDP connections and launching a brute-force attack with popular tools such as, ForcerX, NLBrute, Hydra or RDP Forcer to gain access.
Using complex passwords will make brute-force RDP attacks harder to succeed.
Below are the top 15 passwords used on vulnerable RDP systems. We built this list based on information on weak passwords shared by a friendly Law Enforcement Agency from taken down RDP shops. What is most shocking is the fact that there is such a large number of vulnerable RDP systems did not even have a password.
The TOP 15 used passwords on vulnerable RDP systems
[no password]
123456
P@ssw0rd
123
Password1
1234
password
1
12345
Password123
admin
test
test123
Welcome1
scan
Use Multi-Factor Authentication
In addition to a complex password, it is best practice use multi-factor authentication. Even with great care and diligence, a username and password can still be compromised. If legitimate credentials have been compromised, multi-factor authentication adds an additional layer of protection by requiring the user to provide a security token, e.g. a code received by notification or a biometric verification. Better yet, a FIDO based authentication device can provide an extra factor which is not vulnerable to spoofing attacks, in a similar fashion to other one-time-password (OTP) mechanisms. This increases the difficulty for an unauthorized person to gain access to the computing device.
Use an RDP Gateway
Recent versions of Windows Server provide an RDP gateway server. This provides one external interface to many internal RDP endpoints, thus simplifying management, including many of the items outlined in the following recommendations. These comprise of logging, TLS certificates, authentication to the end device without actually exposing it to the Internet, authorization to internal host and user restrictions, etc.
Microsoft provides detailed instructions for configuration of remote desktop gateway server, for Windows Server 2008 R2 as an example, over here.
Lock out users and block or timeout IPs that have too many failed logon attempts
A high number of failed logon attempts is a strong indication of a brute force attack. Limiting the number of logon attempts per user can prevent such attacks. A failed logon attempt is logged under Windows Event ID 4625. An RDP logon falls under logon type 10, RemoteInteractive. The account lockout threshold can be specified in the local group policy under security settings: Account Policies.
For logging purposes, it is best to log both failed and successful logons. Additionally, it is important to note that “specific security layer for RDP connections” needs to be enabled. Otherwise, you will be unable to tell that the logon attempt came over RDP or see the source IP address. A comparison is shown below.
Event log network logon (type 3) note no source network address
Event log RDP logon (type 10) note the source network address present
Use a Firewall to restrict access
Firewall rules can be created to restrict Remote Desktop access so that only a specific IP address or a range of IP addresses can access a given device. This can be achieved by simply opening “Windows Firewall with Advanced Security,” clicking on Inbound Rules and scrolling down to the RDP rule. A screen shot can be seen below.
Firewall settings for inbound RDP connections
Enable Restricted Admin Mode
When connecting to a remote machine via RDP, credentials are stored on that machine and may be retrievable by other users of the systems (e.g. malicious attackers). Microsoft has added restricted admin mode which instructs the RDP server not to store credentials of users who log in. Behind the scenes, the server now uses ‘network’ login rather than ‘interactive’ and therefore uses hashes or Kerberos tickets rather than passwords for authentication. Assessment of the pros and cons of this option are recommended before enabling in your environment. On the negative side, the use of network login exposes the possibility of credential reuse (pass the hash) attacks against the RDP server. Pass the hash is likely possible anyway, internally, via other exposed ports so may not significantly increase exposure there, but when including this option to Internet servers, where other ports are likely (and should be!) restricted, pass the hash is then extended to the Internet. Given the pros and cons, avoiding internal escalation of privilege is often prioritized and therefore restricted admin mode is enabled.
Microsoft TechNet describes configuration and usage of restricted mode here.
Encryption
There are four levels of encryption supported by standard RDP: Low, Client Compatible, High, and FIPS Compliant. This is configured on the Remote Desktop server. This can be further improved upon by using Enhanced RDP Security. When Enhanced RDP security is used, encryption and server authentication are implemented by external security protocols, e.g. TLS or CredSSP. One of the key benefits of Enhanced RDP Security is that it enables the use of Network Level Authentication (NLA) when using CredSSP as the external security protocol.
Certificate management is always a complexity, but Microsoft does provide this through the use of Active Directory Certificate Services (ADCS). Certificates can be pushed using Group Policy Objects (GPO) where this is available. Incompatible operating system environments must import certificates via the web interface exposed at https://<server>/Certsrv.
Enable Network Level Authentication (NLA)
To reduce the amount of initially required server resources, and thereby mitigate against denial of service attacks, network level authentication (NLA) can be used. Within this mode, strong authentication takes place before the remote desktop connection is established, using the Credential Security Support Provider (CredSSP) either through TLS or Kerberos. NLA can also help to protect against man-in-the-middle attacks, where credentials are intercepted. However, be aware that NLA over NTLM does not provide strong authentication and should be disabled in favor of NLA over TLS (with valid certificates).
Microsoft TechNet describes configuration and usage of NLA in Windows Server 2008 R2 here.
Interestingly, BlueKeep, mentioned above, is partially mitigated by having NLA enabled. As reported by Microsoft in the associated advisory “With NLA turned on, an attacker would first need to authenticate to Remote Desktop Services using a valid account on the target system before the attacker could exploit the vulnerability.”
Restrict users who can logon using RDP
All administrators can use RDP by default. Remote access should be limited to only the accounts that require it. If all administrators do not need remote access you should consider removing the Administrator account from the RDP access group. You can then add the specific users which require access to the “Remote Desktop Users” group. See here for more information on managing users in your RDS collection.
Minimize the Number of Local Administrator Accounts
Local administrator accounts provide an attack vector for attackers who gain access to a system. Credentials can be cracked offline and more accounts means more likelihood of a successful crack. Therefore, you should aim for a maximum of one local administrator account which is secured appropriately.
Ensure that Local Administrator Accounts are Unique
If the local administrator accounts match those assigned to their counterparts on other systems within the server’s internal network, the attacker can potentially re-use credentials to move laterally. This issue occurs quite frequently, so Microsoft provided Local Administrator Password Solution (LAPS) as a means to avoid this scenario across the organization with central management of unique local administrator credentials. This is particularly relevant for externally exposed systems.
Microsoft provides a download and usage information for LAPS here.
Limit Domain Administrator Account Access
Microsoft Remote Desktop 0x2407 Mac
Accounts within the domain admins group have full control of the domain by default, by virtue of being part of the administrators group for all domain controllers, domain workstations and domain member servers. If a credential for a domain admin account is retrieved from the RDP server, the attacker now holds the ‘keys to the kingdom’ and is in full control of the entire domain. You should reduce the amount of domain administrators within the organization in general and avoid accessing the RDP server or other externally exposed systems via these accounts, to avoid inadvertently making credentials accessible.
In general, ‘least privilege’ administration models should be used. Microsoft provides guidance in this area, including how best to use domain admin accounts, here.
Remote Desktop Download
Consider Placement Within the Network
Microsoft Remote Desktop
Where possible, RDP servers should be placed within a DMZ or other restricted area of the network. The idea here is that if an attack is successful, its scope is reduced and confined to the RDP server alone. Often RDP is exposed specifically to allow external users onto the network, so this may not be a feasible solution, however it should be considered and the quantity of services reachable within the internal network should be minimized.
Consider using an account-naming convention that does not reveal organizational information
There are many options for account naming conventions, ranging from firstname.lastname to not deriving usernames from name data; all having their pros and cons. However, some of the more commonly used account naming conventions such as firstname.lastname, make it very easy to guess usernames and email addresses. This can be a security concern as spammers and hackers will readily use this information.
Conclusion
When trying to run an efficient IT organization, having remote access to certain computer systems might be essential. Unfortunately, when not implemented correctly, the tools that make remote access possible also open your systems up to unwanted guests. In the last few years there have been far too many examples of where vulnerable RDP access gave way to a full-scale network compromise.
In this article we have shown that RDP access can be hardened with some easy steps. Please take the time to review your RDP security posture.