Two-Factor Authentication(2FA) can give an organization a false sense of security. The Windows OS has many ways to be logged into and remotely managed. These Windows OS tools leave a lot of entry points that can bypass 2FA protection. Most of the industry leaders in 2FA do not fully protect all the ways to log into a Windows Server.

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 WinRM. This discrepancy is easy to miss, and leaves systems unprotected.

Let’s explore how a Red Team can leverage this weakness.

What is WinRM?

In summary, 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.

Attacking WinRM to Bypass 2FA

Using WinRM to bypass 2FA is a straightforward process and an easy finding on a Red Team engagement. Windows Server OS since Windows Server 2012, will have WinRM enabled by default. However, there are a few other details you need before you can leverage the WinRM service. See the requirements below.

• A valid login for a User in the Administrators(Local System) or Domain Admins group.
• Access to port 5985(HTTP) or port 5986(HTTPS).

Port 5895 or 5896

To start you need to be able to reach port 5985 or 5986 on the system you want to bypass 2FA on. Depending on the system’s firewall profile settings, you may need to be on the same subnet as the target, but not always.

Since the Devil is in the Defaults, let’s see what Microsoft’s default settings are.

On private networks, the default Windows Firewall rule for PowerShell Remoting accepts all connections. On public networks, the default Windows Firewall rule allows PowerShell Remoting connections only from within the same subnet.

https://docs.microsoft.com/en-us/powershell/scripting/learn/remoting/winrmsecurity?view=powershell-7.2

Valid User

Needing a valid User account login with Administrators(Local System) or Domain Admins rights limits this attack greatly. So you will need to already have some key data about your target domain.

WinRM is not going to get you initial access to a system on the network, but it can help you move laterally. Additionally, you will be “Living off the Land”. Moving between systems with a built-in tool that encrypts all traffic(after the initial authentication) is of major value.

Theoretical Attack Chain

So how can we leverage WinRM in our path to obtaining Domain Admin rights?

Consider the following attack chain.

1. Breach a system; maybe a vulnerable web server or end-users system.
2. Gather passwords and hashes from breached system.
   • Check the local Administrator password. Local Administrator account password reuse is very common.
   • Gather Domain Users credentials.
3. Use breached credentials and login to Active Directory with WinRM, bypassing 2FA requirements.
4. Breach the KRBTGT user password hash in Active Directory.
5. With the known User account details and the KRBTGT user password hash, forge a GoldenTicket. WinRM uses Kerberos for authentication, so you now have persistent access to the domain.

Connect Over WinRM

Connecting over WinRM can be done in a few ways. The built-in PowerShell commands that use WinRM are “Enter-PSSession” and “Invoke-Command”. However, the tool you will find most helpful is Evil-WinRM. Evil-WinRM was built for leveraging WinRM’s features as a Red Team tool. Full remote PowerShell access, upload and download files, and much more.

Install Evil-WinRM

Let’s install the Evil-WinRM tool!

# Use the Ruby package manager to install the required dependencies.
gem install winrm winrm-fs stringio logger fileutils

# Clone repository
git clone https://github.com/Hackplayers/evil-winrm.git

# Move into DIR 
cd evil-winrm 

# Run the evil-winrm tool.
ruby evil-winrm.rb -i 10.0.0.5 -u Administrator -p 'THEpa$$Word!'

Using Evil-WinRM

Using Evil-WinRM is way too easy. We have so many options of how we can use the tool. For example, since WinRM works over Kerberos we can do a Pass-The-Hash login to a remote system. We don’t even need a plain text user password, just their NTLM password hash!

Wrap-up

We, as Red Teamers, can leverage a few methods using built-in Windows tools to bypass 2FA. Like most attacks, it only works under certain circumstances, but they are common in most networks. While 2FA systems protection is becoming more frequent, not all remote access methods are correctly defended. If you find that the WinRM ports are not reachable, think like a Systems Administrator and what other tools they may use to manage their network remotely.

Learn How To Defend the WinRM Service in Windows Server from 2FA Bypass