NOTE: Below, you will find all the technical information your IT-security team needs to find out whether or not your organization has been affected by this exploit. If you would like immediate help investigating or remediating a potential compromise, please reach out to us right away here. One of our specialists will get back with you ASAP.
Your Microsoft Exchange Server Could Still be Vulnerable
Earlier this year, the cybercartel that calls itself “Hafnium” leveled an attack exploiting vulnerabilities in Microsoft Exchange servers. Patches were released by Microsoft. Remediation steps were published. Known incidents were remediated. If everyone knew about and had access to information on identifying and fixing the problem, we should be looking at a closed case, right? On August 13, just as most people thought we were well past the Hafnium attack, a new related exploit was publicly identified by third parties as a potential vector for malicious PowerShell-related commands. The result? LockFile ransomware is being deployed to many organizations’ systems, and the question we are asking is, Why didn’t you update your servers? Of course, updating a complex system is never that simple, but this remains the central issue.
(I should note here that before becoming a certified Incident Response engineer, I spent years personally managing patch administration in enterprise IT environments. I know what the challenges are, and I’m coming at this issue from first-hand experience on both sides of the challenge.)
Why would anyone put off patching known vulnerabilities?
It would seem obvious that when there is a major attack like the one Hafnium leveled via the Microsoft Exchange exploit earlier this year, everyone would rush to apply the update and protect themselves. Why would you not patch something that you know could lead to a major ransomware attack? The answer is not as simple as one might think. No one likes downtime, period. Users complain. Everything slows down. People have to wait to perform basic tasks they are accustomed to doing daily. So, updating has to be done after hours. For busy teams who are already stretched thin and working overtime, one more night spent at the office until 2am is not exactly appealing. Plus, what if the update breaks something? Then the issues will flow downstream, affecting more users for a longer period of time. IT teams will have to drop what they are doing and fix the new problems, too.
What takes more time out of your IT team’s day, patching or a ransomware attack?
The truth is, it’s functionally easier in the short-term to avoid patching more business-impacting systems, like an Exchange server, because if something goes wrong, the fallout is bigger. I’ve seen this issue from both sides, managing patching administration in enterprise IT environments and performing incident response for clients whose unpatched systems led to a breach, I can tell you that disruption due to ransomware is far greater than disruption due to a squirrelly update. Nobody likes to still be working when the sun comes up the next day, but one day spent like that now and then far supersedes weeks of downtime, ransom negotiations, and stolen data.
__________________________________________________
Below are my notes on this attack, which we have been using to actively hunt for threats in our Security Operations Center. These should enable your IT-security teams to know what to look for and what to do.
Which servers are affected?
Exchange servers that may be impacted by this exploit are versions 2013, 2016, and 2019 that have not been patched since April or May. So, if May was the last time you patched your Exchange server, your servers are not safe and could still be exploited.
What does a LockFile incident look like?
Where LockFile is deployed, this is the pattern of infection observed:
- ProxyLogin/ProxyShell vulnerabilities in Microsoft Exchange are used to compromise Exchange servers
- Attacker uses access to download files
- *PetitPotam is installed. (PetiPotam allows attackers to take over an organization’s domain controller by leveraging PetitPotam method, which forces authentication to a remote NTLM relay under LockFile’s control.)
- PetitPotam is used to take over domain controller
- Once access is gained to local Domain Controller, attackers copy the LockFile ransomware, along with a batch file and supporting executables, onto the Domain Controller.
- Files are copied into the “SYSVOL/domain/scripts” directory (used to deploy scripts when network clients authenticate to the domain controller).
- Any clients who authenticate to the domain after these files have been copied over will execute them.
What to look for: Indicators of ProxyShell Compromise
- Exchange configuration file modified to hide the presence of webshell with a new virtual directory path. Some servers have multiple entries and virtual directories.
C:\Windows\System32\inetsrv\Config\applicationHost.config
- C:\ProgramData and subdirectories may also contain webshells
- Subdirectories may not be COM/COM1, but also see WHO, ZING, ZOO, XYZ, and others.
- Some entries use a physical path (location in the filesystem to offer the user with a webshell) with a UNC path “\\” that refers to a different machine.
- Webshells use XML/XSL transform with different variable names and a different HTTP parameter “password”. It is not a password or a key, but it acts like one.
- The following IP addresses and user agent strings have been identified that interact with webshells:
- 37.221.115[.]68 – python-requests/2.25.1
- 45.144.30[.]18 – python-requests/2.26.0
- 84.17.46[.]174 – python-requests/2.26.0
- 116.203.201[.]159 – python-requests/2.26.0
- 116.203.201[.]159 – Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)
- 203.184.132[.]186 – python-requests/2.25.1
- 203.184.132[.]186 – Mozilla/5.0+Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)
What to do if you find IOCs: ProxyShell Remediation
- Check C:\Windows\System32\inetsrv\Config\applicationHost.config for changes to include creating new virtual directories. Examine any newfound paths to hunt for and remove webshells.
- If you do see lines creating new virtual directories in the application.Host.config file:
- Delete the webshells present in the physicalPath location (if any)
- Edit the applicationHost.config to remove the lines
- Restart IIS service to ensure change is made
- Block known attacker IP addresses on your host, on-premise, and web application firewalls
Proxyshell Examples
Example of a new virtual directory created to hide the presence of webshells:
Example of virtual directories created – note the presence of UNC, as well as C:\ProgramData paths:
Again, if you need help, please reach out to us right away.
