Tips to prevent RDP and other remote attacks on Microsoft networks

One long-favored way that ransomware enters your system is through Microsoft’s Remote Desktop Protocol (RDP) attacks. Years ago when we used Microsoft’s Terminal Services (from which RDP evolved) for shared remote access inside or outside of an office, attackers would use a tool called TSGrinder. It would first review a network for Terminal Services traffic on port 3389. Then attackers would use tools to guess the password to gain network access. They would go after administrator accounts first. Even if we changed the administrator account name or moved the Terminal Services protocol to another port, attackers would often sniff the TCP/IP traffic and identify where it was moved to.

Attackers still go after our remote access, this time via RDP. With human-operated ransomware techniques, attackers gain access and then use higher privileges to gain more access in a network. You have several ways to protect your network from brute-force or other targeted remote attacks. 

Use administrator accounts with blank passwords

Believe it or not, one way to block such attacks is to have a blank password for the administrator account. Using the Group Policy setting “Accounts: Limit local account use of blank passwords to console logon only” blocks the ability for anyone to remote into the network with a blank password. While this clearly is not an ideal protection, it’s an interesting one that’s been available in Group Policy since Server 2003.

Set Windows 11 lockout policies

Included in the Insider releases of Windows 11 and ultimately coming to Windows 11 22H2 will be a new policy that will set a more granular lockout policy than we currently have with Windows 10 or server platforms. The lockout policy in Windows 10 and Windows 11 appears as follows:

You get three policies: “Account locker duration”, “Account lockout threshold”, and one to reset account lockout counter after a set number of minutes.

Windows 11 22H2 will ship with one more policy setting and with the following defaults:

• Account lockout duration will be set to 10 minutes.
• Account lockout threshold will be set to 10 invalid logon attempts.
• Reset account lockout counter after 10 minutes.

In addition, there is a new setting: “Allow Administrator account lockout”. In social media posts, David Weston, Microsoft’s vice president for Enterprise and Operating system security, indicated that this would be backported to Windows 10.

Add multi-factor authentication and account lockout tools

What should you do in the meantime? RDP is responsible for roughly 70% to 80% of network breaches, so I recommend upping the ante. That starts with adding multi-factor authentication to the remote process.

TS_Block is a tool that blocks brute-force Terminal Services login attempts. As the developer notes in the readme file, it is “a VBScript program that acts as a WMI event sink to receive events logged by Windows in response to invalid Terminal Services logons.” It will:

• Block logons from an IP address with a username flagged as “block immediately.”
• Block IP addresses if more logon attempts are made than the preset allowance in a time period.

The “block immediately” usernames and thresholds associated with repeated logon attempts are configurable with these default settings:

• Block immediately usernames – administrator, root, guest
• Logon attempts allowed – 5 in 120 seconds (2 minutes)
• Duration of block – 300 seconds (5 minutes)

It also comes with a Group Policy administrative template file.

Account lockout is not new. In fact, it’s been discussed for many years, but we often don’t take the time to review user security baselines and other defaults as recommended by Microsoft or NIST. Case in point is a blog post from 2014 on configuring account lockout thresholds.

Review your password policies

Encourage the use of smart cards or other processes that do not rely on passwords. You should also set standards for password length and complexity.

Microsoft will be setting default password policies going forward, but you should adjust and tweak them to your needs. If you are getting many help-desk calls to reset passwords, review what the root cause is. Do you not have a reasonable password policy? Do you not have a process to self-change and reset passwords? Do you rely only on passwords and not use more modern technology that allows for authentication process that are easier for the end user, but at the same time more secure by design? If you find after rolling out these defaults in your Windows 11 environment that it causes more issues in your environment, you may need to review and add technology rather than remove the default policies.