Companies that didn’t have remote access systems in place had to plunge headlong into deploying them several months ago when the global coronavirus pandemic broke out. Many IT teams were unprepared for this wholesale shift to remote work. Consequently, security flaws stemming from misconfigurations, reliance on insecure remote access protocols, and installation of known-vulnerable outdated software and shadow IT were rampant.
Some organizations have already suffered the consequences of these mistakes. Some managed to emerge mostly unscathed—for now. One way or another, it’s high time everyone drew the right conclusions.
Since the start of the year, the overall tolerance of telework has grown by leaps and bounds. Businesses are increasingly treating WFH and remote work as a permissible format on a long-term, even permanent, basis.
Some of the more commonly used methods for remote access include VPN, RDS, and VNC. Each may have their proper uses, but each can present dire security risks when stretched beyond their narrow use cases. While admins have a ton of tools to choose from, they need to make the right choices based how their enterprise is architected, and the specific use cases that must be supported.
This blog will focus on Remote Desktop Protocol/Services (RDP/RDS) security, which tends to be more commonly used in MB environments due the ease of deployment. Please read on for an overview of known RDS/RDP, vulnerabilities, to walkthrough several attack scenarios against network infrastructure based on Active Directory, and to learn some key mitigation strategies. Hopefully, this information will help some of you steer clear of typical slip-ups and strengthen your enterprise security.
Recent RDS/RDP vulnerabilities
Cybercriminals, especially ransomware creators, are keenly attuned to remote access vulnerabilities and are primed to pounce. Zero-day vulnerabilities generally present the most wide-open vulnerabilities, because no patch has yet been created. RDS, though widely used, has some particularly dangerous published vulnerabilities. Here’s a quick summary of some of the RDS vulnerabilities that Microsoft has recently announced:
This vulnerability can be a source of issues for users who connect to a compromised server. The attacker may take control of a user’s device or gain a foothold in the system to maintain persistent remote access.
CVE-2019-1181 / CVE-2020-0609 / CVE-2019-1182
These vulnerabilities allow an unauthenticated adversary to pull off remote code execution on a server running RDS. All it takes is a specially crafted request. These flaws can also be used to create computer worms – malicious code that autonomously replicates itself to other devices on the same network. In plain words, these vulnerabilities can put the whole enterprise network at risk. The only rescue is to apply software updates with patches once they are available.
Remote access software has gained a great deal of traction with both researchers and malefactors. Therefore, we may find out about new loopholes of that sort being unearthed down the line. The good news is, not all vulnerabilities are backed by public exploits. The bad news, though, is that seasoned cybercriminals may have enough expertise to mastermind an exploit based on a vulnerability description or through methods like Patch Diffing. With that said, I strongly recommend that companies regularly update their software, keep abreast of new vulnerability reports, enforce the principle of least privilege wherever possible to prevent, or at least mitigate, the threats posed by vulnerable software, and apply advanced application control measures, which offer protection against fileless attacks.
Remote Desktop Attack Vectors
Let’s move on to the typical logic of attacks zeroing in on network infrastructure based on Active Directory. The techniques below apply to the following intruder profile: it’s an adversary who has a valid user account combined with access to the Remote Desktop Gateway, that is, the terminal server. On a side note, the latter may be accessible from an external network. By leveraging these methods, the crook can expand the attack surface and maintain persistence. Although the network configuration may vary in each specific scenario, the techniques below are fairly universal.
Examples of escaping restricted shell environment and privilege escalation
When attempting to access a Remote Desktop Gateway, the adversary will most likely encounter a kind of restricted environment. An application is launched on the terminal server as part of establishing the connection. It can be a Remote Desktop Protocol connection window for local resources, the File Explorer (formerly known as Windows Explorer), office packets, or any other software.
The attacker’s goal is to access the command execution routine so that he can launch CMD or PowerShell scripts. Several classic techniques for escaping the Windows sandbox could help in this regard. Let’s dwell on these tricks.
Scenario 1. The attacker has access to the Remote Desktop connection interface within Remote Desktop Gateway.
The first step is to open the “Show Options” menu. It lists the options for managing the connection configuration files. It’s easy to access the File Explorer from this screen – all it takes is clicking on the “Open” or “Save” button.
Once the File Explorer is opened, its address bar enables launching allowed executables and can also display the file system hierarchy. This may be useful for the attacker in case the system drives are hidden and therefore cannot be accessed directly.
A scenario like this can be replayed when the Excel component of the Microsoft Office package is used as a remote application. Furthermore, Office macros are a notoriously weak link that can also be mishandled for exploitation.
Scenario 2. While having an identical scope of access as in the previous scenario, the attacker opens several Remote Desktop connections under the same account. The second attempt to connect will close the first connection, and an error message will appear on the screen. Clicking on the “Help” button on this notification will bring up Internet Explorer on the server, which will allow the criminal to access the File Explorer.
Scenario 3. If the ability to launch executable files is restricted, the attacker may encounter a situation where the group policies disallow triggering cmd.exe. There is a way to circumvent this by launching a BAT file from the Remote Desktop containing a string such as cmd.exe /K <command name>.
Scenario 4. The use of executable block lists to block specific applications isn’t ultimately effective and can be bypassed.
Let’s look into the following situation: you blocked access to the command line tool and configured group policies to ban Internet Explorer and PowerShell from being executed. The attacker tries to fire up PowerShell via the contextual menu of the modal window opened with the Shift key pressed – no luck. Then, the attacker tries to execute PowerShell via the address bar and fails again. How does the attacker bypass the restriction then?
It suffices to copy PowerShell.exe from the C:\Windows\System32\WindowsPowerShell\v1.0 folder to the user directory, rename it to something different from PowerShell.exe, and voila – it can be executed.
The default setting of the Remote Desktop connection allows access to the client’s local drives. The attacker can copy PowerShell.exe from there, rename the executable, and run it. In many cases, there are folders that didn’t end up in the block list and, therefore, can be accessed.
Furthermore, if it’s a company-issued computer, chances are that some software developers left a few scripts behind that can be launched or even modified. I have come across such scripts several times. Some of them could even be executed with the privileges of the domain administrator. To recap, block lists aren’t a remedy for any intrusion.
How to Build Secure RDP connections
There are many more scenarios to get around the traditional defenses and carry out a privilege escalation attack. The common denominator is that the malefactor accesses the File Explorer at the early stage of the attack. Numerous third-party applications use the native Windows file management tools, and similar techniques can be applied as long as these apps are operating in a restricted environment.
There are plenty of options to orchestrate an attack even in a restricted environment. However, you can raise the bar for a potential intruder. Here are six tips that will help fend off attacks exploiting the Remote Desktop connection.
1. Use group policies to specify application allow lists and block lists.
This still leaves some loopholes for arbitrary code execution, though. Consider familiarizing yourself with the LOLBAS project to get an idea of undocumented methods for manipulating files and running code in a system. It’s preferable to combine different types of restrictions. For instance, you can allow Microsoft-signed executables, while restricting the use of cmd.exe.
2. Disable settings tabs in Internet Explorer (you can do it locally via the registry).
3. Use the Regedit tool to prevent the built-in Windows Help feature from being opened.
4. Disable the option of mounting local drives for remote connections, if it’s not critical for your organization.
5. Restrict access to local drives of a remote machine, while only keeping the user folders accessible.
6. Remove admin privileges and enforce least privilege, such as with a privileged access management (PAM) solution, that can enable effective Windows administration without Domain Admin or other superuser privileges
Microsoft is not the only environment suffering from such attacks. Apple macOS networks have seen a dramatic increase in ransomware attacks related to remote desktops.
Hopefully, this article will help you take the security of your company’s remote workforce implementation to the next level.
David Balaban, David Balaban
David Balaban is a computer security researcher with over 17 years of experience in malware analysis and antivirus software evaluation. David runs Privacy-PC.com and MacSecurity.net projects that present expert opinions on contemporary information security matters, including social engineering, malware, penetration testing, threat intelligence, online privacy, and white hat hacking. David has a strong malware troubleshooting background, with the recent focus on ransomware countermeasures
