In this rapidly evolving cyber world, one has to stay up-to-date on security trends. With the increase in zero-day vulnerability sales and leaks, the trillion dollar threat business is working out big time for the bad guys, more so due to the presence of persistently available vulnerable systems across the world.

With the shift in the revenue model from demanding ransoms to cryptomining, the adversaries are always staying on top, and they have realized that the fastest way to spread any malware would be only through identifying a vulnerability that has a wider reach.

Cases in the past have shown us how malware like Wannacry, NotPetya, Mirai, etc. have caused huge havoc. These use zero-day/N-day vulnerabilities along with plain brute force to spread the infection.

We regularly see attacks against vulnerable services that have been exposed on a server, but the daily attacks we see at K7 Labs are not just these; they also include heavy brute force on RDP. Ransomware and crypto-malware families such as Dharma, SamSam, LockCrypt, Ryuk, Sodinokibi  and RDPminer abuse RDP services via brute force or known vulnerabilities to gain an initial foothold into the system. With the increase in internet scanners and monitoring tools like Shodan, it has become easy for adversaries to scale their target easily. The RDP threat remains more potent than ever because of factors such as legacy operating systems which are still in use, even though these are not supported by the OS vendor for updates;  open RDP ports that have been misconfigured, which can be used by threat actors to gain network access; delay by the users in installing the patches, among others.


RDP has been a major infection vector in the recent past and our stats prove that it has become one of the prevalent threats, among others, like SMB and email infection. 

Major ransomware and cryptominers are capitalizing on RDP brute force/dictionary attacks along with other exploits. The root cause of the RDP infections is usually overlooked and not remediated properly.

Malware programs are using the following ways to exploit RDP:

  1. Misconfigured RDP server-These are servers which require no authentication
  2. Outdated RDP server-These include servers unpatched with respect to the latest known vulnerability (which was CVE-2019-0708, as of when this blog was written)
  3. RDP server with weak password & no account lockout policy-This is widely seen

Please refer to our earlier blog Exposing Vulnerable Indian Cyberspace for more detailed insights on the misconfiguration of RDP servers.

Incident forensics, including analysing the Windows event logs, clearly shows us one of the methods used by malware to gain an initial foothold.

Figure 1: Event logs showing brute force attempts on RDP

This pattern has been observed in many malware attacks in the wild. Please check the recommendations at the end of this blog to protect yourselves from brute force attacks.


Zero-day vulnerabilities are a serious threat for everyone. Over recent years, zero-day vulnerabilities leaked from various institutions and individuals have been exploited in a flash by various threat actors, resulting in data and financial losses. In the last quarter, Microsoft issued a patch for a wormable Remote Code Execution (RCE) vulnerability in windows RDP service reported by the UK’s National Cyber Security Centre (NCSC). At the time of writing this blog, there was no known malware found abusing this vulnerability. 

Here’s what’s under the hood:

CVE-2019-0708 aka BlueKeep, is an RCE vulnerability reported in Microsofts’ RDP implementation, patched by Microsoft in May 2019.

RDP uses Static Virtual Channels (SVC) to communicate application specific data related to different aspects of the connection; for example to use specific hardware. Virtual Channels are extensions to enhance Remote Desktop Service (RDS) applications. A total of 31 virtual channels can be requested in a connection.

Data exchange for SVC occurs in the early phase of establishing an RDP connection before user authentication takes place. It is at this point, when the user tries to request for and communicate with the channel named MS_T120, that a vulnerability is triggered.

A Virtual Channel request is made during a Generic Conference Control (GCC) Conference Create Request. A GCC request and response pair is used to exchange core, security and network data related to an RDP connection (Figure 2).

Figure 2: Sequence followed by RDP while establishing connection. Basic settings are communicated during GCC conference request/response

Channel name and options are present in the request and the allocated channel number is sent in the response. While requesting a default RDP connection, MS_T120 is not included in the channels requested. In the rdpwd.sys driver, Microsoft internally binds channel MS_T120 to channel number 31 in MCSIcaVirtualQueryBindings() function call by default for every connection.

Figure 3: MCSIcaVirtualQueryBindings() binding channel MS_T120 in rdpwd.sys driver

As you can see in the screenshots below (Figure 4), when an MS_T120 channel is requested during a connection, the server binds a random channel number between 1 and 31 and shares it with the client (in this case mapped Channel 1005- 0x3ED). This channel binding is in addition to internal binding performed by rdpwd.sys driver, resulting in multiple binding for the same channel.

Figure 4: Channel Request and Response while establishing RDP connection

Upon analyzing the patch, it was observed that Microsoft had updated termdd.sys which is another Windows driver used for handling RDP connections. This update statically binds channel MS_T120 to channel number 31 alone, hence preventing multiple channel binds. We observed that the comparison for string MS_T120 in IcaRebindVirtualChannels() function is present in the updated termdd.sys file before setting a static value of 1Fh (decimal 31) for channel binding and calling ICABindChannel() function, as shown in Figure 5.

Figure 5: IcaRebindVirtualChannels() function definition in old and updated termdd.sys file

Since channels are requested in the early stages of a connection setup (Figure 2), an unauthenticated adversary can easily attempt to establish a connection to exploit CVE-2019-0708 using specially crafted packets, to request and communicate via the MS_T120 channel.

As observed earlier, on requesting connection to MS_T120, it is bound to a random channel (channel 5 when we tried) and Microsoft internally binds to channel number 31. When data is sent to this channel, Windows closes the channel due to an error and frees the channel binding. But since there are multiple bindings, one binding still remains open allowing exploitation of a Use-After-Free vulnerability. IcaFreeChannel() is called as shown in Figure 6.

Figure 6: System stack as observed during crash dump analysis

Windows 8 and later versions are not affected by this vulnerability due to differences in the way they handle an RDP connection request. However, we recommend updating and installing the latest available patch on all versions of Windows; disabling RDP if not required.


Vulnerabilities in RDP go a long way back, dating to early 2000 – numerous vulnerabilities over two decades (MS00-087, MS02-051, CVE-2012-0002, CVE-2015-2373, CVE-2013-1296), however, perhaps surprisingly, RDP’s share of the vulnerabilities amongst all Microsoft products is still quite low. Yet, the malware infections and system compromises that happen using RDP have been consistently rising.

Figure 7: Infection vector for June-Sept 2019 Ransomware attacks as observed in K7 Labs

We at K7 Labs have witnessed an increase in RDP incidents over the last quarter. Even though actual exploitation of the recently patched unauthenticated RDP vulnerability is yet to be seen, our telemetry data shows that there is huge reconnaissance activity happening for this particular vulnerability. The below graph indicates the percentage of hits on the BlueKeep vulnerability over all IDS hits since June 2019.

Figure 8: Graph showing continuous reconnaissance for the BlueKeep vulnerability 

From the stats it is evident that there is a constant reconnaissance for the BlueKeep vulnerability. On the other hand, Shodan has released stats stating that more than 700,000 machines are vulnerable to the BlueKeep vulnerability worldwide. Even if we remove the devices with Network Level Authentication (NLA) enabled from this count, the resultant number is pretty large for this wormable vulnerability.

Figure 9: Devices exposed to BlueKeep vulnerability

In India alone there are 7081 publicly exposed devices that are vulnerable to CVE-2019-0708 (BlueKeep) vulnerability.

Figure 10: Devices exposed to BlueKeep vulnerability in India

The infection rates would skyrocket if a malware exploits this vulnerability as the above-mentioned stats are just the publicly exposed devices. The number of vulnerable devices on internal networks would make this number much larger. 

Remediation and protection from RDP threats

Protecting your system is a continuous process and it’s challenging to keep ourselves up-to-date with the latest threat landscape, although this is important. Security through obscurity may not completely evade the threat but, decreases the attack surface exposed to threats. Given below are a few tips to protect the system:

  • Patch the vulnerabilities in third party applications
  • Update the operating system to the latest build
  • Use firewall and allow only whitelisted IP addresses to use the RDP
  • Change the default RDP port to an unusual port
Figure 11: Update RDP port in Windows registry

Open registry editor and go to the path “Computer -> HKEY_LOCAL_MACHINE -> SYSTEM -> CurrentControlSet -> Control -> Terminal Server -> WinStations -> RDP-Tcp” and change the value for PortNumber to a different number.

  • Strengthen your RDP users’ passwords, as most of the RDP ransomware try to brute force to get into the system
  • Enable Network Level Authentication (NLA) for RDP
Figure 12: Enabling NLA for RDP

Go to Properties of “My Computer” and click on the “Advanced System Settings” on the left pane. Choose the “Remote” tab and select the third option to enable NLA. If the RDP service is not required, choose the first option to disable it.

  • Implement an Account Lockout Policy to limit brute force/dictionary attacks
Figure 13: Set Account lockout threshold value to defend against brute force attempts

Go to Start and search for “Local Security Policy”. In the left pane go to “Security Settings -> Account Policies -> Account Lockout Policy” and choose the lockout threshold as appropriate.

  • Turn off the RDP service if you don’t need it
  • Access RDP via a secure channel like VPN

Although at the time of writing this blog there was no confirmed malware abusing this wormable vulnerability CVE-2019-0708, it is highly recommended that you protect your assets by updating your operating system to an up-to-date one which includes the latest security patches.

K7 Security products actively detect attempts to exploit the BlueKeep vulnerability (CVE-2019-0708) under vulnerability scan & IDS (Rule:intrusion attack – id:000200DC).



Like what you're reading? Subscribe to our top stories.

If you want to subscribe to our monthly newsletter, please submit the form below.

    Leave a comment

    Your email address will not be published. Required fields are marked *