You have 2FA deployed to all your Windows Servers and even choose to use a hardware 2FA key like Yubikey or Duo. You are sleeping well at night knowing the servers have protection, even if an Attacker breaches the internal LAN network. Everything is good, right? Well, those Windows Servers may not be as safe as you think.

Most 2FA systems only work for interactive logins, like Remote Desktop(RDP) or at the login console. The 2FA support does not extend to non-interactive logins, like PowerShell Remoting through Windows Remote Management(WinRM).

So how secure is WinRM? Let’s explore how the Blue Team can mitigate the WinRM security risks.

Short on time? TLDR

---

What is Windows Remote Management?

In summary, Windows Remote Management(WinRM) is a protocol that runs over HTTP and is used to manage remote systems. PowerShell Remoting runs on top of WinRM to run commands on remote systems. So you can think of WinRM as Linux’s SSH but for Windows.

Windows Remote Management (WinRM) is the Microsoft implementation of WS-Management Protocol, a standard Simple Object Access Protocol (SOAP)-based, firewall-friendly protocol that allows hardware and operating systems, from different vendors, to interoperate.

https://docs.microsoft.com/en-us/windows/win32/winrm/portal

Whenever you use a PowerShell Remoting command(Invoke-Command, or Enter-PSSession) you are connecting to the remote system using WinRM. All this traffic happens on port 5985(HTTP) or port 5986(HTTPS). So keep this in mind when building your defenses.

---

Defending Windows Remote Management

There is no checkbox or GPO option to prevent WinRM from being a 2FA bypass. It is even more difficult if you actually need and use WinRM, like in management scripts. I personally have tons of PowerShell scripts that rely on the “Invoke-Command” tool. So let’s explore a layered defense strategy to block would-be Attackers.

So what does an Attacker Need for this attack?

Knowing the requirements for an attack allows us to find ways of blocking an Attacker.

Attack Requirements

1. Network connection to port 5985(HTTP) or 5986(HTTPS) of the remote system.
2. A valid username and password, OR the passwords hash.
3. Local Administrators rights on the remote system, or Domain Admin rights.
4. The ability to run PowerShell on their local, or currently breached system.

If you want to know more about how this attack chain works, see my write-up on Attacking WinRM.

---

Cover the Basics – Firewalls

Let’s assume you cannot outright disable WinRM because you need it. We can start by limiting the number of systems in the network that can connect to servers that have WinRM enabled. If you have 500 total end-points in the network and 400 of those are end-users, then blocking them mitigates 80% of the total risk.

VLAN Segmentation

Segment the network and block all access from non-essential networks. If there is a service the Office end-users need access to, then create a specific Access Control List(ACL) for the service. For example, there is a web application the Office Workers need to use. Create an ACL that allows Port 80 & 443 from the Office Network to the web server in the Server Network.

TURN ON WINDOWS FIREWALL!

I cannot count how many times I find Windows built-in Firewall in the disabled state. Turn Windows Firewall on, better yet, set and enforce the Firewall settings via GPO.

The above Firewall and VLAN defense layers will limit Attack Requirement #1.

---

Protect Passwords and Their Hashes

Local Administrator Accounts with LAPS

Let’s say a company needs to administer over 500 end-points in the network. For many reasons, those end-points need to still have a local Administrator account. The trap System Administrators fall into is using the same password for these accounts throughout the environment. So if An Attacker breaches one system he has, in effect, breached all systems. However, what’s the alternative, keep a spreadsheet with 500 passwords? That does not sound secure either. So what’s the answer?

Local Administrator Password Solution(LAPS) provides management of local account passwords of domain-joined computers. LAPS simplifies password management by storing unique, long, and complex passwords for each system in Active Directory (AD). Then when you need to access a system with the local Administrator account, only a selected few System admins can view the password in AD.

There are many other security features provided by LAPS and I recommend you read more about them at this link.

Domain Admin Group Member Accounts in AD

Here is a simple one to implement. User accounts with membership in the Domain Admins group, need to be added to the Protected Users group as well. Members of the Protected Users group have additional security features enabled around how their password is cached on systems throughout the network. This makes it harder for an Attacker to pull a Domain Admin’s password from memory on systems they breach.

Before implementing this change read through the documentation and be aware of the changes this causes. Do not add all Domain Admins to the Protected Users group until you test out the effects.

Other Resources

• Microsofts documentation on Protected Users Security Group
• Also, see this great blog post “Ten things you need to be aware of before using the Protected Users Group”

The above password defense layers will limit Attack Requirements #2 & #3.

---

Block PowerShell Access For Basic Users

Generally, end-users do not need access to PowerShell. Since PowerShell is not something an end-user needs let’s disable access to it so it cannot be misused.

We are going to create a GPO in Active Directory that will not allow PowerShell to run on a user’s system. We will then assign that GPO to the Basic Users group.

Create a new GPO and edit it. Go to the following location and make the below changes.

Locations: User Configuration –> Policies –> Administrative Templates –> System –> “Don’t run specified Windows applications“

Now you can assign this GPO to the Organizational Units(OU) that holds all those Basic User accounts. If an Attacker breaches one of the Basic User end-points they will not be able to access PowerShell. Thus making it harder to use WinRM to bypass 2FA, or do any number of other attacks.

The above blocking PowerShell defense layer will limit Attack Requirement #4.

---

Wrap-Up: TLDR

Bypassing 2FA on Windows systems can be done quickly using built-in tools. Our job as Blue Team Defenders is to understand these attacks and build a defense against them. We identified four critical pieces of the WinRM attack and how we can mitigate their risk. Those mitigations are as follows.

1. Limit network access to servers that use WinRM on ports 5985 & 5986 through VLAN Segmentation with ACL rules and Windows Firewalls.
2. Limit password re-use of the local Administrator account.
3. Protect Domain Admin account credentialsstored in the system cache.
4. Block Basic User accounts from accessing PowerShell on their systems.

These defenses combined will significantly impede an Attacker from using WinRM against you.

---