Brute-force attacks and BlueKeep exploits usurp convenience of direct RDP connections; ESET releases a tool to test your Windows machines for vulnerable versions

• Secure Rdp Windows 10
• Free Rdp For Windows 10
• Tls 1.2 Rdp Windows 10
• Windows 10 Rdp Server

Is Remote Desktop secure/encrypted I recently enable remote desktop on my home computer to try and access it on the go. I operate on windows 10 pro on both the the remote and connecting PC and currently meet meet requirements for enhanced security. How to Secure a Remote Desktop. Remote Desktop is a Windows service that allows users to connect to a host computer from a different location. This allows users to access information stored on a separate computer from any place that allows. Microsoft RDS can be used to help secure on-premises deployments, cloud deployments, and remote services from various Microsoft partners (e.g., Citrix). Leveraging RDS to connect to on-premises systems enhances security by reducing the exposure of systems directly to the internet. Remote Desktop can be secured using SSL/TLS in Windows Vista, Windows 7, Windows 8, Windows 10 and Windows Server 2003/2008/2012/2016.Some systems listed are no longer supported by Microsoft and therefore do not meet Campus security standards. If unsupported systems are still in use, a security exception is required. Unfortunately, Remote Desktop feature is not available in Windows 10 Home, it can only be enabled on computers running Windows Pro, Windows Enterprise and Windows Server. Although, Windows 10 Home is equipped with Remote Desktop Client Software, it lacks the propriety RDP server from Microsoft, required for accessing remote computers.

While the BlueKeep (CVE-2019-0708) vulnerability has not, to date, caused widespread havoc, and we will be looking at the reasons why in this post, it is still very early in its exploitation life cycle. The fact remains that many systems are still not patched, and a thoroughly wormable version of the exploit might still be found. Because of these factors, ESET has created a free utility to check if a system is vulnerable.

Sometimes, you have to say something about things that “go without saying” and it seems the best way to start this post is by mentioning just that, because this is not a subject I expected to have to write about in this day and age. Easeus partition master keygen 9.2 2. Before we dive in, let’s begin by looking at an old maxim.

There is an old saying in the information security field that if an adversary has physical access to your computer then it is not your computer anymore. The reason for this is quite simple: once the attackers have their hands on a computer, they can change anything they want. Installing devices such as hardware keyloggers, removing disk drives and copying them, and otherwise deleting, altering or adding anything they want on the system all become exponentially easier when you can walk right up to the computer. This is not a particularly surprising turn of events, nor a particularly clever one. Rather, it is an unavoidable truth. For the adversaries, it’s just part of their job description. Longchamp serial number authentication.

Businesses and schools and all sorts of organizations are not blind to this, though. These kinds of places do not put their servers at the front desk in the lobby, reception area, visitor center, waiting room or other locations where the public or, conceivably, any employee, faculty, student, or staff may enter and gain physical access to them. Or, at least, no business that wants to remain in business allows this. Usually, there’s some separation of the servers, whether they be in their own dedicated room, or even tucked away in some back corner that is off-limits to most personnel.

Yet for all this common knowledge, the lessons learned about security in the physical world do not always transfer well (or correctly) into the internet world. There are many servers running various versions of Microsoft Windows server operating systems that are directly connected to the internet with what amounts to little or no practical security around who can access them. And that brings us to the discussion of RDP.

What is RDP?

RDP, short for Remote Desktop Protocol, allows one computer to connect to another computer over a network in order to use it remotely. In a domain, computers running a Windows Client operating system, such as Windows XP or Windows 10, come with RDP client software preinstalled as part of the operating system, which allows them to connect to other computers on the network, including the organization’s server(s). A connection to a server in this case means it could be directly to the server’s operating system, or it could be to an operating system running inside a virtual machine on that server. From that connection, a person can open directories, download and upload files, and run programs, just as if using the keyboard and monitor connected to that server.

RDP was invented by Citrix in 1995 and sold as part of an enhanced version of Windows NT 3.51 called WinFrame. In 1998, Microsoft added RDP to Windows NT 4.0 Terminal Server Edition. Since then, the protocol has been a part of all versions of Microsoft’s line of Windows Server operating systems, as well as being included with all non-home user editions of Windows Client operating systems since Windows XP was released in 2001. Today, common users of RDP include system administrators doing remote administration of servers from their cubicles without having to go into the server room, as well as remote workers who can connect to virtualized desktop machines inside their organization’s domain.

What do attackers do with RDP?

For the past couple of years, ESET has seen an increasing number of incidents where the attackers have connected remotely to a Windows Server from the internet using RDP and logged on as the computer’s administrator. Once the attackers are logged into the server as administrator, they will typically perform some reconnaissance to determine what the server is used for, by whom, and when it is being used.

Once the attackers know the kind of server they have control of, they can begin performing malicious actions. Common malicious activities we have seen include:

• clearing log files containing evidence of their presence on the system
• disabling scheduled backups and shadow copies
• disabling security software or setting up exclusions in it (which is allowed for administrators)
• downloading and installing various programs onto the server
• erasing or overwriting old backups, if they are accessible
• exfiltrating data from the server

This is not a complete list of all the things an attacker can do, nor is an attacker necessarily going to perform all of these activities. Attackers may connect multiple times over days or just once, if they have a predetermined agenda. While the exact nature of what attackers will do varies greatly, two of the most common are:

• installing coin-mining programs in order to generatecryptocurrency, such as Monero
• installing ransomware in order to extort money from the organization, often to be paid using cryptocurrency, such as bitcoin

In some cases, attackers might install additional remote-control software to maintain access (persistence) to compromised servers in case their RDP activities are discovered and terminated.

We have not seen any servers that were compromised both to extort via ransomware and to mine cryptocurrency, but we have seen instances where a server was compromised by one attacker to mine cryptocurrency, then later compromised by other attackers who changed the coin miner so that the proceeds went to them, instead. It seems there is little honor among thieves.

Knowledge around RDP attacks has reached a point that even sextortion scammers are incorporating mention of it in their ransom notes in an attempt to make their scams sound more legitimate.

Figure 1. Image from sextortion email scam mentioning RDP

For more information about these types of email scams, I recommend this series of articles by my colleague Bruce P. Burrell: Part I, Part II, and Part III.

Mass RDP attacks

Attacks performed with RDP have been slowly, but steadily, increasing, and subject to a number of governmental advisories from the FBI, the UK’s NCSC, Canada’s CCCS, and Australia’s ACSC, to name a few.

However, in May 2019 the floodgates opened with the arrival of CVE-2019-0708, aka “BlueKeep,” a security vulnerability in RDP affecting Windows 2000, Windows XP, Windows Vista, Windows 7, Windows Server 2003, Windows Server 2003 R2, Windows Server 2008 and Windows Server 2008 R2. On the desktop, Windows 8 and later, and on servers, Windows Server 2012 and later, are unaffected.

The BlueKeep vulnerability allows attackers to run arbitrary program code on their victims’ computers. While even individual attackers can be a widespread threat because they can use automated tools for attacks, this vulnerability is “wormable,” which means an attack could spread itself automatically across networks without any intervention by users, just as the Win32/Diskcoder.C (aka NotPetya) and Conficker worms have in the past.

Exploitation of wormable vulnerabilities is generally considered a severe issue. Microsoft has assigned the vulnerability its highest severity level, Critical, in its published guidance for customers, and in the US government’s National Vulnerability Database, the entry for CVE-2019-0708 is scored as 9.8 out of 10. Microsoft issued a blog post strongly recommending that users install its patches, including those for out-of-support operating systems such as Windows XP and Windows Server 2003. Concerns about a wormable exploit were so high that, at the beginning of June, the US National Security Agency issued a rare advisory recommending installation of Microsoft’s patches for the flaw.

At the beginning of September, Rapid7, the developer of the Metasploit pentesting tool, announced the release of a BlueKeep exploit. While no major escalations in BlueKeep activity were reported for the next couple of months, this has recently changed. At the beginning of November, mass reports of BlueKeep exploitation became public, as noted by ZDNet and WIRED, amongst other news outlets. The attacks have reportedly been less than successful, with about 91% of vulnerable computers crashing with a stop error (aka bug check or Blue Screen of Death) when the attacker attempts to exploit the BlueKeep vulnerability. However, on the remaining 9% of vulnerable computers, these attackers successfully installed Monero cryptomining software. So, while not the feared wormable attack, it does appear a criminal group has automated exploitation, albeit without a high success rate.

When I originally started writing this blog post, it was not my intention to go into a detailed description of the vulnerability, nor was it to provide a timeline of its exploitation: my goal was to provide readers with an understanding of what must be done to protect themselves against this threat. So, let’s take a look at what needs to be done.

Defending against RDP-borne attackers

So, with all that in mind, what can you do? Well, the first thing, obviously, is to stop connecting directly to your servers over the internet using RDP. This may be problematic for some businesses, because there may be some seemingly legitimate reasons for this. However, with support for both Windows Server 2008 and Windows 7 ending in January 2020, having computers running these and being directly accessible using RDP via the internet represents a risk to your business that you should already be planning to mitigate.

This does not mean that you immediately need to stop using RDP, but that you need to take additional steps to secure it as soon and as quickly as possible. Toward this end, we have created a table with the top ten steps you can take to begin securing your computers from RDP-based attacks.

This table is loosely based on order of importance and ease of implementation, but that can vary depending upon your organization. Some of these may not be applicable to your organization, or it may be more practical to do them in a different order, or there may be additional steps your organization needs to take.

You should verify that your endpoint security software detects the BlueKeep vulnerability. BlueKeep is detected as RDP/Exploit.CVE-2019-0708 by ESET’s Network Attack Protection module, which is an extension of ESET’s firewall technology present in ESET Internet Security and ESET Smart Security Premium for consumers, and ESET’s endpoint protection programs for businesses.

Figure 2. ESET Antimalware technology explained: Network Attack Protection

It should be noted, though, that there are scenarios where detection may not occur, such as the exploit first crashing the system because it is unreliable. In order for it to be more effective, it would need to be paired with another exploit, such as an information disclosure vulnerability that reveals kernel memory addresses so that they no longer need to be guessed. This could reduce the amount of crashes, as the current exploit performs such a large heap spray.

If you are using security software from another vendor, check with them to see if BlueKeep is detected and how.

Keep in mind, these steps represent only the beginning of what you can do to protect against RDP attacks. While having detection for attacks is a good start, it is not a substitute for patching or replacing vulnerable computers. Your information security staff and trusted security partners can provide you with additional guidance specific to your environment.

Using ESET’s BlueKeep (CVE-2019-0708) vulnerability checker

ESET has released a free BlueKeep (CVE-2019-0708) tool to check if a computer running Windows is vulnerable to exploitation. As of the time of publication, the tool can be downloaded from:

(Be sure to check ESET’s Tools and Utilities page for newer versions)

This program has been tested against 32-bit and 64-bit versions of Windows XP, Windows Vista, Windows Server 2003, Windows Server 2003 R2, Windows Server 2008 and Windows Server 2008 R2 before and after applying Microsoft’s updates for BlueKeep. To use the program, run the executable. There are no command-line arguments for use with the initial release.

When run, the program will report if the system is vulnerable to exploitation, if the system is patched against exploitation, or if the system is not vulnerable to BlueKeep exploitation. In the event the system is vulnerable, the tool will take the user to the web page to download the appropriate patch on Microsoft’s web site.

While this is a single-purpose tool intended for personal use and is not intended to be deployed for mass use in an automated environment, it does have limited error reporting. For scripting, the tool returns an ERRORLEVEL of zero if the system is protected, and one if it is vulnerable or an error has occurred.

Figure 3. Example of running tool on unpatched Windows 7 system

Figure 4. Example of running tool on patched Windows 7 system

Figure 5. Example of running tool on non-vulnerable Windows 10 system

Final thoughts and additional reading

While BlueKeep exploitation may never become widespread, its inclusion in pentesting tools means that it will become a permanent part of in-house security tests. So, the real solution to preventing BlueKeep exploitation is to remove vulnerable devices from your company’s network.

However, it may not always be possible to do so because a vulnerable device occupies a critical role in the business, because of cost, or for other reasons. We have long advocated taking a layered approach to security, and protecting against BlueKeep is no exception. In fact, some of the steps outlined above, for example, installing a 2FA application such as ESET Secure Authentication, may help secure your networks from intruders and other threats as well.

Further information about RDP and BlueKeep can be found at:

• CSO Online. Microsoft urges Windows customers to patch wormable RDP flaw. (15 May 2019)
• Description of the security update for the remote code execution vulnerability in Windows XP SP3, Windows Server 2003 SP2, Windows Server 2003 SP2 R2, Windows XP Professional x64 Edition SP2, Windows XP Embedded SP3, Windows Embedded POSReady 2009, and Windows Embedded Standard 2009. (17 June 2019)
• Customer guidance for CVE-2019-0708 | Remote Desktop Services Remote Code Execution Vulnerability: May 14, 2019. (14 May 2019)
• CVE-2019-0708 | Remote Desktop Services Remote Code Execution Vulnerability. (14 May 2019)
• Configure Network level Authentication for Remote desktop Services Connections. (13 June 2013)
• CVE-2019-0708. (undated)
• NSA Cybersecurity Advisory: Patch Remote Desktop Services on Legacy Versions of Windows. (4 June 2019)
• An update on the Microsoft Windows RDP “BlueKeep” Vulnerability (CVE-2019-0708) [now with pcaps]. (22 May 2019)
• US-CERT, Technical Alert AA19-168A: Microsoft Operating Systems BlueKeep Vulnerability. (17 June 2019)
• First BlueKeep attacks prompt fresh warnings. (11 November 2019)
• Microsoft warns of new BlueKeep-like flaws. (15 August 2019)
• BlueKeep patching isn’t progressing fast enough. (17 July 2019)
• NSA joins chorus urging Windows users to patch ‘BlueKeep’. (6 June 2019)
• Patch now! Why the BlueKeep vulnerability is a big deal. (22 May 2019)
• Intense scanning activity detected for BlueKeep RDP flaw. (26 May 2019)

Special thanks to my colleagues Alexis Dorais-Joncas, Bruce P. Burrell, Michal F., Nick FitzGerald, Branislav O., Matúš P., Peter R., Peter Stančík, Štefan S., and other colleagues from ESET for their assistance with this article.

MITRE ATT&CK techniques

Are you still using computers vulnerable to BlueKeep? Did ESET’s BlueKeep (CVE-2019-0708) vulnerability checker help? If so, what steps have you taken to mitigate exploitation? Be sure to let us know, below!

Secure Rdp Windows 10

How secure is Windows Remote Desktop?

Remote Desktop sessions operate over an encrypted channel, preventing anyone from viewing your session by listening on the network. However, there is a vulnerability in the method used to encrypt sessions in earlier versions of RDP. This vulnerability can allow unauthorized access to your session using a man-in-the-middle attack.

Remote Desktop can be secured using SSL/TLS in Windows Vista, Windows 7, Windows 8, Windows 10 and Windows Server 2003/2008/2012/2016. *Some systems listed are no longer supported by Microsoft and therefore do not meet Campus security standards. If unsupported systems are still in use, a security exception is required.

While Remote Desktop is more secure than remote administration tools such as VNC that do not encrypt the entire session, any time Administrator access to a system is granted remotely there are risks. The following tips will help to secure Remote Desktop access to both desktops and servers that you support.

Basic Security Tips for Remote Desktop

1. Use strong passwords

Strong passwords on any accounts with access to Remote Desktop should be considered a required step before enabling Remote Desktop. Refer to the campus password complexity guidelines for tips.

2. Use Two-factor authentication

Departments should consider using a two-factor authentication approach. This topic is beyond the scope of this article, but RD Gateways can be configured to integrate with the Campus instance of DUO. Other unsupported by campus options available would be a simple mechanism for controlling authentication via two-factor certificate based smartcards. This approach utilizes the Remote Desktop host itself, in conjunction with YubiKey and RSA as examples.

3. Update your software

One advantage of using Remote Desktop rather than 3rd party remote admin tools is that components are updated automatically with the latest security fixes in the standard Microsoft patch cycle. Make sure you are running the latest versions of both the client and server software by enabling and auditing automatic Microsoft Updates. If you are using Remote Desktop clients on other platforms, make sure they are still supported and that you have the latest versions. Older versions may not support high encryption and may have other security flaws.

4. Restrict access using firewalls

Use firewalls (both software and hardware where available) to restrict access to remote desktop listening ports (default is TCP 3389). Using an RDP Gateway is highly recommended for restricting RDP access to desktops and servers (see discussion below). As an alternative to support off-campus connectivity, you can use the campus VPN software to get a campus IP address and add the campus VPN network address pool to your RDP firewall exception rule. Visit our page for more information on the campus VPN service.

5. Enable Network Level Authentication

Windows 10, Windows Server 2012 R2/2016/2019 also provide Network Level Authentication (NLA) by default. It is best to leave this in place, as NLA provides an extra level of authentication before a connection is established. You should only configure Remote Desktop servers to allow connections without NLA if you use Remote Desktop clients on other platforms that don't support it.

• NLA should be enabled by default onWindows 10, Windows Server 2012 R2/2016/2019.

• To check you may look at Group Policy setting Require user authentication for remote connections by using Network Level Authentication found at ComputerPoliciesWindows ComponentsRemote Desktop ServicesRemote Desktop Session HostSecurity. This Group Policy setting must be enabled on the server running the Remote Desktop Session Host role.

6. Limit users who can log in using Remote Desktop

By default, all Administrators can log in to Remote Desktop. If you have multiple Administrator accounts on your computer, you should limit remote access only to those accounts that need it. If Remote Desktop is not used for system administration, remove all administrative access via RDP, and only allow user accounts requiring RDP service. For Departments that manage many machines remotely remove the local Administrator account from RDP access at and add a technical group instead.

1. Click Start-->Programs-->Administrative Tools-->Local Security Policy

2. Under Local Policies-->User Rights Assignment, go to 'Allow logon through Terminal Services.' Or “Allow logon through Remote Desktop Services”

3. Remove the Administrators group and leave the Remote Desktop Users group.

4. Use the System control panel to add users to the Remote Desktop Users group.

A typical MS operating system will have the following setting by default as seen in the Local Security Policy:

The problem is that “Administrators” is here by default, and your “Local Admin” account is in administrators. Although a password convention to avoid identical local admin passwords on the local machine and tightly controlling access to these passwords or conventions is recommended, using a local admin account to work on a machine remotely does not properly log and identify the user using the system. It is best to override the local security policy with a Group Policy Setting.

To control access to the systems, even more, using “Restricted Groups” via Group Policy is also helpful.

If you use a “Restricted Group” setting to place your group, e.g., “CAMPUSLAW-TECHIES” into “Administrators” and “Remote Desktop Users,” your techies will still have administrative access remotely, but using the steps above, you have removed the problematic “local administrator account” having RDP access. Going forward, whenever new machines are added in the OU under the GPO, your settings will be correct.

7. Set an account lockout policy

By setting your computer to lock an account for a set number of incorrect guesses, you will help prevent hackers from using automated password guessing tools from gaining access to your system (this is known as a 'brute-force' attack). To set an account lockout policy:

1. Go to Start-->Programs--> Administrative Tools--> Local Security Policy
2. Under Account Policies--> Account Lockout Policies, set values for all three options. Three invalid attempts with 3-minute lockout durations are reasonable choices.

Best Practices for Additional Security

1. Do not allow direct RDP access to clients or servers from off campus.

Having RDP (port 3389) open to off campus networks is highly discouraged and is a known vector for many attacks. The options below list ways of improving security while still allowing RDP access to system.

Once an RDP gateway has been set up, hosts should be configured to only allow RDP connections from the Gateway host or campus subnets where needed.

2. Use RDP Gateways (Best Option)

Using an RDP Gateway is strongly recommended. It provides a way to tightly restrict access to Remote Desktop ports while supporting remote connections through a single 'Gateway' server. When using an RD Gateway server, all Remote Desktop services on your desktop and workstations should be restricted to only allow access only from the RD Gateway. The RD Gateway server listens for Remote Desktop requests over HTTPS (port 443) and connects the client to the Remote Desktop service on the target machine.

1. Utilize Campus RDP Gateway Service. This is the best option to allow RDP access to system categorized as UC P2 and lower. Includes DUO integration. RDP Gateway Service is provided by the Windows Team. Documentation is available here: https://berkeley.sharepoint.com/sites/calnetad/gateway.

   The RDP Gateway Service also supports the new Remote Access Services requirement of the draft MSSND update (requirement 8), which requires the use of an approved service (i.e., RDP gateway, dedicated gateway, or bSecure VPN) for access to the UC Berkeley network from the public Internet.

2. Dedicated Gateway Service (Managed). Needed for rdp access to systems that are UC P4 or higher. Must also be configured for DUO
   Some campus units use an IST managed VPS as an RD Gateway. A rough estimate might be that 30-100 concurrent users can use one RD Gateway. The HA at the virtual layer provides enough fault-tolerant and reliable access; however a slightly more sophisticated RD gateway implementation can be done with network load balancing.

3. Dedicated Gateway Service (Unmanaged). Installing and configuring RD Gateway on department run hardware.
   There are many online documents for configuring this embedded Windows 2016/2019 component. The official documentation is here: https://docs.microsoft.com/en-us/windows-server/remote/remote-desktop-se..
   Installing the configuring, the role service is mostly as described; however, using a Calnet issued trusted Comodo certificate is recommended. Using a self-signed cert is ok for testing, and using a CalnetPKI cert can work if all clients have trusted the UCB root. The Comodo cert is usually better accepted so that your end users do not receive certificate warnings.
   Configuring your client to use your RD Gateway is simple.The official documentation for the MS Client is here: http://technet.microsoft.com/en-us/library/cc770601.aspx

Free Rdp For Windows 10

In essence, a simple change on the advanced tab of your RDP client is all that is necessary:

3. Change the listening port for Remote Desktop

Changing the listening port will help to 'hide' Remote Desktop from hackers who are scanning the network for computers listening on the default Remote Desktop port (TCP 3389). This offers effective protection against the latest RDP worms such, as Morto. To do this, edit the following registry key (WARNING: do not try this unless you are familiar with the Windows Registry and TCP/IP): HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlTerminal ServerWinStationsRDP-Tcp. Change the listening port from 3389 to something else and remember to update any firewall rules with the new port. Although this approach is helpful, it is security by obscurity, which is not the most reliable security approach. You should ensure that you are also using other methods to tighten down access as described in this article.

4. Tunnel Remote Desktop connections through IPSec or SSH

If using an RD Gateway is not feasible, you can add an extra layer of authentication and encryption by tunneling your Remote Desktop sessions through IPSec or SSH. IPSec is built-in to all Windows operating systems since Windows 2000, but use and management are greatly improved in Windows 10 (see: http://technet.microsoft.com/en-us/network/bb531150). If an SSH server is available, you can use SSH tunneling for Remote Desktop connections.

5. Use existing management tools for RDP logging and configuration

Using other components like VNC or PCAnywhere is not recommended because they may not log in a fashion that is auditable or protected. With RDP, logins are audited to the local security log, and often to the domain controller auditing system. When monitoring local security logs, look for anomalies in RDP sessions such as login attempts from the local Administrator account. RDP also has the benefit of a central management approach via GPO as described above. Whenever possible, use GPOs or other Windows configuration management tools to ensure a consistent and secure RDP configuration across all your servers and desktops.

Tls 1.2 Rdp Windows 10

By enforcing the use of an RDP gateway, you also get a third level of auditing that is easier to read than combing through the domain controller logins and is separate from the target machine so it is not subject to tampering. This type of log can make it much easier to monitor how and when RDP is being used across all the devices in your environment.

Windows 10 Rdp Server

This work is licensed under a Creative Commons Attribution-NonCommercial 4.0 International License.