Two Microsoft Exchange zero-days exploited in the wild.

Microsoft warns of vulnerabilities in Exchange Server.

Late Friday, Microsoft announced that three versions of its widely deployed Exchange server were affected by two zero-days. Redmond’s initial disclosure read:

“Microsoft is investigating two reported zero-day vulnerabilities affecting Microsoft Exchange Server 2013, Exchange Server 2016 and Exchange Server 2019. The second, identified as CVE-2022-41082, allows Remote Code Execution (RCE) if PowerShell is exposed to the attacker is.

“Currently Microsoft is aware of limited targeted attacks using these two vulnerabilities. In these attacks, CVE-2022-41040 can allow an authenticated attacker to remotely trigger CVE-2022-41082. It should be noted that authenticated access to the vulnerable Exchange Server is required to successfully exploit any of the vulnerabilities.

“We are working on an accelerated schedule to release a fix. Until then, we are providing mitigations and the detection guides below to help customers protect themselves from these attacks.”

Microsoft’s Security Response Center has provided an initial set of mitigation measures and risk assessment tools, including indicators of compromise, in its “Customer Guide to Reported Zero-Day Vulnerabilities in Microsoft Exchange Server.” Late Sunday, the Microsoft Security Response Center added this alert: “We strongly recommend that Exchange Server customers disable remote PowerShell access for non-admin users in your organization.”

GTSC first discovered the zero-days (and their exploitation).

In the course of security monitoring and incident response conducted by the SOC team in early August, Hanoi-based GTSC discovered through its Microsoft Exchange application “that a critical infrastructure was under attack.” They shared their discovery with the Zero Day Initiative and Microsoft, leading to the fixes Redmond released on Friday.

GTSC summarized the attackers’ activities as follows: “We recorded attacks to gather information and gain a foothold in the victim’s system. The attack team also used various techniques to create backdoors on the affected system and perform cross movements to other servers in the system. We found that webshells, mostly obfuscated, have been placed on Exchange servers. Using the user-agent, we determined that the attacker was using Antsword, an active, open-source, China-based, cross-platform website administration tool that supports webshell management.” were able to protect themselves until Microsoft could provide a patch.

It is not clear who is responsible for the observed exploitation, but GTSC sees strong circumstantial evidence that the perpetrator or perpetrators are Chinese. “We suspect these exploits are from Chinese attack groups based on the webshell code page of 936, a Microsoft character encoding for simplified Chinese.”

Sophos is pointing out what these temporary measures could amount to and sees this as a sort of “silver lining” in the cloud the incident is throwing over Exchange.

“The bugs cannot be triggered by just anyone.” That is, only an authenticated attacker can initiate them. “Sure, any remote user who has already logged into their email account over the internet and whose computer is infected with malware could theoretically compromise their account to launch an attack that exploits these flaws. But only by accessing your Exchange server The Internet alone is not enough to expose you to attacks, because so-called unauthenticated call this error is not possible.

“Blocking PowerShell remoting can limit attacks. According to Microsoft, blocking TCP ports 5985 and 5986 on your Exchange server will prevent (if not prevent) attackers from chaining from the first vulnerability to the second. Although attacks could be possible without relying on PowerShell commands being fired, attack reports to date seem to indicate that running PowerShell was a necessary part of the attack.

The zero-days are ProxyShell’s first cousin; Organizations that have found themselves vulnerable to ProxyShell should be particularly wary.

CISA adds both issues to its catalog of known exploits.

Late Friday, the US Cybersecurity and Infrastructure Security Agency (CISA) added both CVE-2022-41082 and CVE-2022-41040 to its catalog of known exploited vulnerabilities. It characterized CVE-2022-41082 as follows: “Microsoft Exchange Server contains an unspecified vulnerability that allows authenticated remote code execution. This vulnerability, named ProxyNotShell, can be chained to CVE-2022-41040, which allows remote code execution.” CVE-2022-41040, a server-side request forging vulnerability, is described as follows: “Microsoft Exchange Server allows server-side request forgery. Dubbed “ProxyNotShell,” this vulnerability can be chained to CVE-2022-41082, which allows remote code execution.” In both cases, CISA advises organizations to apply the mitigations provided by Microsoft. October time to take action.

Michael Assraf, CEO and co-founder of Vicarius, was impressed with how quickly CISA added the two vulnerabilities to its catalog. “CISA is usually late to the party for many of the KEV additions, but it seems the invitation was delivered early,” he wrote, going on to offer his summary of the vulnerabilities and their impact:

“Two zero-days in Microsoft Exchange servers have been discovered that, when chained together, can allow remote code execution. However, the recommendation states that authenticated access to the servers is required in order to exploit them. Therefore, attackers are likely to first run a phishing/social engineering campaign to gain authorization. Therefore, if you have Exchange servers, it is important to implement all suggested countermeasures according to Microsoft’s instructions. But equally, if not more importantly, is to redouble efforts to detect and report phishing in your organization.

“The other vulnerability is a command injection bug in Atlassian Bitbucket that was reported back in August. A patch is available for this CVE, and a PoC exploit is also circulating in the wild. Since Bitbucket is a code repository, sensitive intellectual property could be at risk as well as other components associated with the larger Jira/Trello framework. A malicious actor using this type of attack is most likely behind admin-level control to further dig into the network.”