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
Followed by an obfuscated
Writing the bytes of the 'zip' file to a
zip appeared to be a fake file-extension and is actually a DLL containing a tool well-known to attackers called
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:
ProxyShellexploits, however this machine is patched.
It didn’t make much sense to move laterally to the Exchange server. Why use the
winrstool to execute
Mimikatzif 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
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.
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
When investigating the origin of this connection, we looked into the following things:
Was there a machine inside the network using the
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
WinRMon 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…
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 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
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
IISon 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
ProxyLogonpublicly 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
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
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 email@example.com
Our cyber experts have analyzed over eleven thousand alerts from the past year. In this blog, we share the results of this analysis. Read more.
Improve your digital security in the new year with these cybersecurity resolutions. Protect your business from the growing threat of cyberattacks in 2023.
Security Specialists from Eye Security have observed a rather large phishing campaign using a few interesting tactics that we would like to share.
An antivirus programme alone will not protect your company against cybercrime. Read more