Microsoft Corp. is investigating reports that attackers are exploiting two previously unknown vulnerabilities in Exchange Server, a technology many organizations rely on to send and receive email. Microsoft says it is expediting work on software patches to plug the security holes. In the meantime, it is urging a subset of Exchange customers to enable a setting that could help mitigate ongoing attacks.
In customer guidance released Thursday, Microsoft said it is investigating two reported zero-day flaws affecting Microsoft Exchange Server 2013, 2016, and 2019. CVE-2022-41040, is a Server-Side Request Forgery (SSRF) vulnerability that can enable an authenticated attacker to remotely trigger the second zero-day vulnerability — CVE-2022-41082 — which allows remote code execution (RCE) when PowerShell is accessible to the attacker.
Microsoft said Exchange Online has detections and mitigation in place to protect customers. Customers using on-premises Microsoft Exchange servers are urged to review the mitigations suggested in the security advisory, which Microsoft says should block the known attack patterns.
Vietnamese security firm GTSC on Thursday published a writeup on the two Exchange zero-day flaws, saying it first observed the attacks in early August being used to drop “webshells.” These web-based backdoors offer attackers an easy-to-use, password-protected hacking tool that can be accessed over the Internet from any browser.
“We detected webshells, mostly obfuscated, being dropped to Exchange servers,” GTSC wrote. “Using the user-agent, we detected that the attacker uses Antsword, an active Chinese-based opensource cross-platform website administration tool that supports webshell management. We suspect that these come from a Chinese attack group because the webshell codepage is 936, which is a Microsoft character encoding for simplified Chinese.”
GTSC’s advisory includes details about post-compromise activity and related malware, as well as steps it took to help customers respond to active compromises of their Exchange Server environment. But the company said it would withhold more technical details of the vulnerabilities for now.
In March 2021, hundreds of thousands of organizations worldwide had their email stolen and multiple backdoor webshells installed, all thanks to four zero-day vulnerabilities in Exchange Server.
Granted, the zero-day flaws that powered that debacle were far more critical than the two detailed this week, and there are no signs yet that exploit code has been publicly released (that will likely change soon). But part of what made last year’s Exchange Server mass hack so pervasive was that vulnerable organizations had little or no advance notice on what to look for before their Exchange Server environments were completely owned by multiple attackers.
Microsoft is quick to point out that these zero-day flaws require an attacker to have a valid username and password for an Exchange user, but this may not be such a tall order for the hackers behind these latest exploits against Exchange Server.
Steven Adair is president of Volexity, the Virginia-based cybersecurity firm that was among the first to sound the alarm about the Exchange zero-days targeted in the 2021 mass hack. Adair said GTSC’s writeup includes an Internet address used by the attackers that Volexity has tied with high confidence to a China-based hacking group that has recently been observed phishing Exchange users for their credentials.
In February 2022, Volexity warned that this same Chinese hacking group was behind the mass exploitation of a zero-day vulnerability in the Zimbra Collaboration Suite, which is a competitor to Microsoft Exchange that many enterprises use to manage email and other forms of messaging.
If your organization runs Exchange Server, please consider reviewing the Microsoft mitigations and the GTSC post-mortem on their investigations.
You’d think enterprises would have given up on Exchange by now. How many times is Lucy going to pull the football?
Another day, another exchange zero day
Features, baby. More.
@YYZ – At this point, running your own mail server is a fool’s errand, especially if you want the Microsoft ecosystem. Let them do it and worry about patching it, go to a competitor, or host your own non-Microsoft solution. Once you have CAL’s and hardware, you get by cheaper letting them do it.
I retired 5 years ago and merely follow the news industry news now. Glad to not have to worry about it any longer. I’m baffled that the frequency and severity of Exchange 0days have gotten worse, not better, yet few seem willing to right it off. It’s almost as if Microsoft is trying to force everyone to their cloud
There’s a pretty good opinion piece here with some interesting conclusions:
Isn’t it about time developers stop worrying about ease of setup and provide software that is locked down and must be opened up manually. Why make PowerShell available unless required?
Because there’s no downside to bad security for the producers of software, from the lowly devs to the C-suite. No matter how bad the security, everybody still gets paid. Sometimes you’ll get a big flashy news item about how they are going to get real about security Real Soon Now (TM) but eventually the process of creating, marketing and selling software returns to the default state of security being ignored. Everybody knows that security costs time and treasure and has negative ROI, so no matter what fuss and bother is going on at a security breach, eventually it will go away and they can get back to pushing out new features and building more technical debt.
Remember the big fuss Bill Gates made years ago about getting security into Microsoft products? That was 20 years ago and they still haven’t figured it out.
One thought: CVE is historically very slow to publish things like this. The GSD has published entries already (and thenf lipped them to reflect the CVEs that were assigned). They are available at https://gsd.id/GSD-2022-41040 and https://gsd.id/GSD-2022-41082 (for any CVE really just replace the CVE bit with “https://gsd.id/GSD” to find it) and linking to them will provide information instead of a “CVE-2022-41040 not found.” error.
like the 0 flaw of spotify application without final user client consent.