How it started ?
At the 10th of May around lunch, our Security Operation Center 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 is 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 is next ?
Looking at that 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 non of these seemed to work as the Exchange server was patched. This let to a temporary conclusion that the attacker was not using the Internet facing appliance on this machine. Lets move on to the second clue.
WinRS
Looking at how WinRM
works via winrs
, it executes the winrs.exe binary on the server and (temporary) 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?
-
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 was not a machine 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 an 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 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 settings 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 machines 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 try 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 utilized by an attacker, even if the attacker itself enabled the WinRM
service during compromitation. In our case, we know this Exchange server got 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 backdoors, 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 a nice 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!
For questions contact cti@eye.security