WinRS and Exchange, a sneaky backdoor

How it started ?

On the 10th of May around lunch, our Security Operation Centre got an alert about a blocked Powershell execution on an Exchange server at one of our relatively new customers. Within two minutes it became clear that this was a True Positive, as malicious activity was definitely happening on this Exchange server:

• An Administrator executing whoami,

• Followed by an obfuscated .ps1 script

• Downloading a zip file from ip.ad.rr.ess/372d948068ba897962acd60.zip

• Writing the bytes of the 'zip' file to a .dll in C:\windows\temp\nio.dll

The zip appeared to be a fake file-extension and was actually a DLL containing a tool well-known to attackers called Mimikatz. Mimikatz is a tool to extract credentials and other authentication variables from the system, in an attempt to elevate to an account with more rights within a network. While the execution of the malicious activity was blocked by our EDR, we were wondering where this attack came from. The parent process appeared to be winrshost.exe, the receiving end of a remote management tool built-in as a part of the Windows operating system. By enabling Windows Remote Management (WinRM) on a machine, one can use winrs to execute commands as follows: winrs /r:myserver command. However, this is where it gets interesting … we could not directly locate where this connection came from.

So what's next ?

Looking at the fact this was an Exchange server, two things directly came to mind:

• The infamous ProxyLogon and ProxyShell exploits, however this machine is patched.

• It didn’t make much sense to move laterally to the Exchange server. Why use the winrs tool to execute Mimikatz if you are already this far?

ProxyShell & ProxyLogon

Looking at the IIS logs of the Exchange server, we saw no interesting entries around the timeframe of the incident. There were attempts to abuse the ProxyLogon and ProxyShell vulnerabilities, however none of these seemed to work as the Exchange server was patched. This led to a temporary conclusion that the attacker was not using the Internet facing appliance on this machine. Let's move on to the second clue.

WinRS

Looking at how WinRM works via winrs, it executes the winrs.exe binary on the server and (temporarily) spawns a program called winrshost.exe on the client machine to accept the commands and execute them. The default ports for WinRM are 5985 for HTTP and 5986 for HTTPS.

When investigating the origin of this connection, we looked into the following things:

• Was there a machine inside the network using the winrs binary?

  • If so, could it connect to the Exchange server and do the timestamps match ?

• Is there another program trying to reach the Exchange server, possibly via WinRM on any of its default ports?

To both these questions, the answer is No. In the entire network there were no machines using winrs nor was there any connection being made to any of the WinRM ports (or any event log like Windows Remote Management/Operational to tell us what the source was). Besides, why would you jump to an Exchange server to deploy Mimikatz if you are already so deep inside the network. At this moment nothing made much sense, but then …

What is going on?

When looking into all events prior to the execution of the malicious Powershell script, we noticed that Sysmon was installed and gave us an additional clue. Sysmon made a reverse DNS request to an IP which appeared to be a TOR exit node and connected to the Exchange server on port 443 just a few seconds before the execution of the .ps1 script. This was not as clear directly from our EDR nor was there any trace in the IIS log of the Exchange server. Somehow the event bypasses the IIS while still connecting to this machine. A colleague mentioned the use of a tool called Evil-winRM as a possible attack vector and then all the pieces of the puzzle started to come together…

Puzzle Completed

We know that WinRM is enabled on the Exchange server, so how is it configured ? When looking at the winrm config using winrm get winrm/config we found the following interesting configuration line:

EnableCompatibilityHttpsListener = true

This setting enables the need to retain the original port listener, and at the same time, to add another listener to ensure that the original port can be used by the administrator..

This in addition to the listener configs using winrm enumerate winrm/config/listener, which stated the following interesting lines:

Listener [Source="Compatability"] (NON default)
Port = 443 (default)
URLPrefix = wsman (default)

Additionally, when setting up WinRM e.g via winrm quickconfig, WinRM can make changes to the local machine's Firewall to open up ports to access the machine for remote management. While these changes do not affect the Exchange server (which already has port 443 open), they give us the indication that additional commands were run on this server to tamper with the WinRM config. We noticed that at least two Firewall rules were created on the 8th of March 2021.

So, can we connect to this Exchange server via winrs? Well, not directly but is is clear that WinRM is available with correct authentication:

 

Access to WinRM on Exchange but in need of authentication.

Looking again at the config of WinRM we see that all forms of authentication are allowed:

We didn’t have the credentials to access the Administrator account, however we know this Exchange server suffered from a breach from ProxyLogon and didn’t reset their Administrator password since 2019 (before they became our customer). Hence it is very likely the attacker returned to see if there was still access to this Exchange server and tried to compromise the domain (hence the use of Mimikatz).

Chaining everything together:

• Windows Remote Management enabled (not strange for an Exchange machine, but only for local access)

• A config containing a legacy compatibility mode, to connect to this server using port 443.

• A listener to accept connections and not reaching the IIS on this machine.

• Although the Firewall rules do not add anything new (as port 443 was already open), looking at the dates it is very suspicious that this was just after ProxyLogon publicly hit the world.

• A nice, but simple backdoor.

After we found out what was going on, we changed the listener to run without the compatibility mode :Set-Item WSMan:\localhost\Service\EnableCompatibilityHttpsListener -Value $false

Conclusion

This kind of sneaky backdoor was something we had not seen before. We feel it is important to note that without valid credentials this backdoor cannot be utilised by an attacker, even if the attacker itself enabled the WinRM service while it was compromised. In our case, we know this Exchange server became compromised during the times of ProxyLogon and ProxyShell, making it very likely the attacker obtained the credentials during that time.

When we went looking to OSINT for this type of backdoor, we found very limited information (in English) about this kind of backdoor. This article: Penetration Testing-Port Reuse Forward Backdoor - actorsfit describes in a quick and concise manner how this type of port reuse with winrm can be used by penetration testers and how this is possible due to the implementation Microsoft used in its TCP stack.

In the end our EDR blocked all malicious activity, cleaned up all the malicious files and made sure nothing malicious was actually executed. For us it was an enjoyable hunt to see what exactly was going on, and a good learning experience to see how Windows handles TCP connections on the same port.

See you next time!