LetsDefend- SOC 175- PowerShell Found in Requested URL- (CVE-2022–41082)

Domiziana Foti
4 min readOct 18, 2022

In early August, the GTSC SOC team (Vietnamese company) discovered two new vulnerabilities that were reported to the Zero-day Initiative (ZDI) to enable further coordination with Microsoft.

The zero-day vulnerabilities affecting Microsoft Exchange Server, CVE-2022–41040 and CVE-2022–41082, were disclosed by Microsoft security researchers on September 29. When combined, the vulnerabilities permit remote code execution (RCE).

According to MSTIC the attack is made by chaining CVE-2022–41040 and CVE-2022–41082 in a small number of targeted attacks and observed these attacks in fewer than 10 organizations globally.

CVE-2022–41040 is a server-side request forgery (SSRF) vulnerability, while CVE-2022–41082, allows remote code execution (RCE) when Exchange PowerShell is accessible to the attacker. It’s vital to remember that in order to be exploited, both require authenticated access to the desired server. The authentication needed for exploitation can be that of a standard user.

Diagram of attacks using Exchange vulnerabilities CVE-2022–41040 and CVE-2022–41082. Font: https://www.microsoft.com/security/blog/2022/09/30/analyzing-attacks-using-the-exchange-vulnerabilities-cve-2022-41040-and-cve-2022-41082/

CVE-2022–41082 looks very similar to ProxyShell, a chain of three vulnerabilities in Exchange Server discovered by Orange Tsai in 2021. The original ProxyShell attack chain did not require authentication, while CVE-2022–41082 does.

On Letsdefend we have this information for starting our analysis:

Starting our analysis we notice immediately that the alert trigger reason is: “Request URL Contains PowerShell”.

So this means that we should see some requests on port 443 by the source IP Address 58.237.200.6

But first let’s check the the source IP Address 58.237.200.6:

Font: AbuseIPDB
Font: Whatismyipaddress
Font: VirusTotal

The IP address is flagged as malicious and it is connected to a south korean telco company.

The next step is to check the logs. In the log management page we see that multiple requests were made from IP 58.237.200.6 to the IP address 172.16.20.8. Another interesting thing that can be noted is the port used: 443.

This definitely ring a bell in our mind.

If we open the raw logs, we see that there is an attempt to use Proxy(not)Shell vulnerability:

The exploit works in two stages:

  1. Requests with a similar format to the ProxyShell vulnerability: autodiscover/autodiscover.json?@evil.com/<Exchange-backend-endpoint>&Email=autodiscover/autodiscover.json%3f@evil.com.
  2. The use of the link above to access a component in the backend where the RCE could be implemented.

It is a worth noting that there is an autodiscover.json abuse:

The vulnerability exists in passing the string Autodiscover/Autodiscover.json to the email field in the URL. By passing that string, Exchange does not perform sufficient checks on the address, and through its normalization process, this leads to arbitrary access to backend URLs as NT AUTHORITY/SYSTEM.

But we can also see from the logs that all the attempts are blocked .

The first question we are asked when we start the playbook is as follows:

The correct answer is malicious as previously seen.

The attack type is other since the vulnerability exploit remote code execution when Exchange PowerShell is accessible to the attacker.

We can say that is not planned. There is no evidence of either email or possible simulation-related exercises.

The traffic direction is Internet →Company as we have seen analyzing the logs.

The correct answer is no since we have seen that all devices have blocked it.

No, we don’t need Tier 2 Escalation since the attack is not successful.

Fonts:

--

--