Microsoft Exchange exploits – step one in ransomware chain
Once attackers gain a foothold on web servers, there are all manner of nasty tricks and malware they can leverage immediately or put into play later – like ransomware.
Since the research blogpost – Exchange servers under siege from at least 10 APT groups – ESET has been busy looking at the attack trends that have emerged post exploitation. In this piece, we’d like to specifically provide you with a quick update on the CVE-2021-26855 exploit chain affecting Microsoft Exchange, which includes the CVE-2021-26857, CVE-2021-26858, and CVE-2021-27065 vulnerabilities.
ESET currently detects the following mechanisms used by Hafnium, LuckyMouse and other groups to compromise Microsoft Exchange servers:
In light of recent Microsoft Exchange exploits after the vulnerability disclosure and patch release, and combing through our own data, we now wonder how many organizations have already been probed and infiltrated for future attacks, such as by ransomware.
Image 1. ESET detections of Microsoft Exchange server attack attempts
The calculus for attackers is simple: Get a foothold on a Microsoft Exchange server, which gives you very privileged access to a company – possibly admin rights – and then plan your upcoming attack. To counter these sorts of scenarios, the recommended first step after applying patches is to perform an investigation and search for compromise remnants and malware or malware traces. Companies sporting endpoint detection and response (EDR) tools will be able to this with measurably better effect. ESET has pursued mitigation strategies on multiple fronts with researchers and even corporate officers getting in on the act. ESET Netherlands CTO Donny Maasland has also contributed to the effort, creating a custom set of rules for ESET Enterprise Inspector that can be used to detect CVE-2021-26855 exploitation. The rules fall into two classes:
A set of rules dealing with network (URL) connections. These rules detect the actual server-side request forgery (SSRF) exploit that targets Microsoft Exchange’s code and are payload independent.
A rule that checks the IIS process when writing .aspx files to disk.
The rules referenced above are configured for ESET Enterprise Inspector, however, it should be possible to adapt them for other EDR platforms.
Click Here to Download Rules[JS1]
These are certainly interesting times we live in, when CTOs join researchers and security operations center teams in demonstrating use cases for EDR. However, the frenzy of malicious activity wrought by Exchange exploits has set a new precedent. Attack attempts – some of what we can expect
In the graphic above we can see a snapshot of post-exploitation malware, some of which can bring ransomware along with it. In this scenario, attackers can gain command shell access to the web server powering Microsoft Exchange and use its privileges to deploy ransomware across the company.
Additionally, since attackers have a foothold on key servers, they can directly exploit the server platform to deliver malware that can exfiltrate data, encrypt sensitive information and plant a backdoor for later use, all playing into the ransomware scenario.
If attackers are simply interested in unfettered data theft of competitive secrets, they may not leave a trace, so ransomware may not be their first objective. But we’ve also seen attackers use ransomware as a smokescreen to divert defenders’ attention and energy elsewhere while the real attack continues.
Another tactic is to lay low, avoid detection for months or years and quietly listen for sensitive information they can exfiltrate later, after they’ve had ample time to get to know your network and its resources.
Less noisy attackers also try to find ways to disable security defenses, allowing them to traverse networks and slurp up resources as they go.
It is also possible to fake a credible ransomware attack by claiming to have infiltrated Exchange servers and demanding a ransom – some companies might just unwittingly pay although they haven’t actually had their data compromised. Essentially, this is an updated version of the sextortion scam emails that have targeted individuals who were victims of data breaches that included an email address and password.
In all these scenarios, it’s easy to understand the level of concern, and why some recommend disconnecting Exchange servers from the internet altogether until they can be investigated and patched. The good news is that Microsoft readied and released a patch in a very short timeframe, reducing the potential spread. But the potential negative effects result from a combination of likelihood and impact – so even though the likelihood might be small, it will still be tough to brace for the impact. More trouble?
Hidden in plain sight among the exploits, and the wave of ransomware that is already following post exploitation, are other threats like ASP/ReGeorg.B, which is detected by ESET as a Potentially Unsafe Application (PUsA) an otherwise legitimate piece of code that is being misused, with ill intent. With PUSAs added to the already complex mix of risks and threats laid at our doorsteps, we can be sure of a long road ahead.
Note: Detection of potentially unsafe applications is not enabled by default in ESET software. For information on enabling detection of PUsAs, see ESET Knowledgebase Articles [KB3204] and [KB6982].
The good news here is that Microsoft responded quickly, sharing information about the attacks as well as patches for affected versions of Microsoft Exchange. If you are responsible for administering Microsoft Exchange within your organization, your highest priority was testing the patch and deploying it immediately. This was a situation in which restarting a server in the middle of the workday may have been required and it has the potential to set the tone for 2021 and beyond. Finally, it would be a good time to check and verify backups in case your organization was affected. Follow our blog for more on the Exchange server saga and what ESET continues to learn about this precedent-setting moment.
[JS1]CTA Button: https://github.com/dmaasland/eei-rules/tree/main/CVE-2021-26855