Just when you were hoping the week would wind down and give you some SecOps downtime over the weekend…
…and a new zero-day hole in Microsoft Exchange arrives!
More precisely, two zero days which can apparently be chained, with the first bug used remotely to open a hole enough to trigger the second bug, potentially allowing remote code execution (RCE) on the Exchange server itself.
Microsoft quickly published official guidance about these vulnerabilities, summarizing the situation as follows:
Microsoft is investigating two reported zero-day vulnerabilities affecting Microsoft Exchange Server 2013, 2016, and 2019. The first vulnerability, identified as CVE-2022-41040is a server-side request forgery (SSRF) vulnerability, while the second, identified as CVE-2022-41082allows remote code execution (RCE) when the attacker can access PowerShell.
At this time, Microsoft is aware of limited targeted attacks using the two vulnerabilities to enter user systems. In these attacks, CVE-2022-41040 can allow an authenticated attacker to remotely activate CVE-2022-41082. It should be noted that authenticated access to the vulnerable Exchange server is required to successfully exploit either vulnerability.
From what we can see, there are two positives here:
- Bugs can’t be triggered by just anyone. Sure, any remote user who is already logged into their email account over the Internet and whose computer is infected by malware could theoretically have their account subverted to launch an attack that takes advantage of these bugs. But just having your Exchange server accessible over the Internet isn’t enough on its own to expose it to attack, because so-called unauthenticated invocation of these errors is not possible.
- Blocking PowerShell Remoting can limit attacks. According to Microsoft, blocking TCP ports 5985 and 5986 on your Exchange server will limit (if not prevent) attackers from chaining from the first vulnerability to the second. Although the attacks may be possible without relying on the activation of PowerShell commands, the intrusion reports so far seem to suggest that the execution of PowerShell was a necessary part of the attack.
ProxyShell Memories
If this attack reminds you of the ProxyShell vulnerability from about a year ago, you’re not the only one who thinks that.
According to GTSC, the Vietnamese cybersecurity company that first investigated and reported these new holes, researchers “Exploit requests detected in IIS logs with the same format as [the] ProxyShell vulnerability”.
In particular, the type of threat hunting query we recommend for ProxyShell exploit caving in 2021 seems to work also to detect the abuse of these new zero days:
SELECT grep.* FROM file CROSS JOIN grep ON (grep.path = file.path) WHERE file.path LIKE 'C:\inetpub\logs\LogFiles\W3SVC%\u_ex210[89]%' AND grep.pattern = 'autodiscover.json'
microsoft too grades that “[the detection we] created in response to ProxyShell can be used for queries as there are similarities in function with this threat.”
Of course, we still don’t know if the new attack can be carried out without leaving this specific telltale sign in their logs.
In other words, if you find trigger signs similar to those left by PowerShell vulnerabilities, you probably have evidence of an attack, but the absence of these signs is not evidence of absence.
According to GTSC, in the attacks they have investigated so far, cybercriminals used their unauthorized RCE powers to implant and execute a variety of follow-on malware, including:
- Webshells implanted to open a web-based backdoor for later. Webshells generally allow tracking attacks to embed arbitrary system commands, with arbitrary command arguments, into regular-looking HTTP requests. The webshell then directly execute the desired command with the privileges of the web server itself.
- Credential dump malware. Credential thieves often snoop on disk and memory (if they have sufficient privileges) looking for plain text passwords, session cookies and authentication tokens that could allow what is known as lateral movement to other computers on the network.
- Zombie malware in the form of DLL files loaded into legitimate-looking processes. A sample of DLLs that GTSC researchers analyzed could be remotely fed encrypted instructions to dump system information, execute arbitrary commands, launch C# modules, and modify files and folders on the infected system.
We’ll update this article as we learn more, including reporting when Microsoft gets patches to close these holes.
Threat Hunting Tips
For tips on hunting for threats from GTSC, which discovered and reported the bugs, from Microsoft, and from Sophos, see:
To do?
Mitigations include:
- Block PowerShell Remoting to reduce the risk of ROSC. As mentioned above, blocking TCP ports 5985 and 5986 will limit attacks on your Exchange server, according to Microsoft.
- Use a URL rewrite rule to block known attack triggers. GTSC and Microsoft have explanations on how to use IIS server URL rewrite rules to detect and neutralize common forms of this attack.
- Make sure behavioral endpoint threat detection is enabled, including on servers. As mentioned above, GTSC reports that the attacks seen so far include the implantation of webshells and malware DLLs to execute arbitrary commands, manipulate files, and extract system information. This gives you numerous potential detection and response indicators to monitor a successful attack.
- Consider deauthenticating logged in email users. If you can perform some kind of endpoint security assessment on each user’s device before allowing them to re-authenticate, you will reduce (although not eliminate) the risk of already compromised devices being co-opted to launch attacks. It will also reduce what is known as your attack surface by not having authenticated users hanging around who don’t need to log in, or don’t even remember they ever logged in in the first place.
- Apply patches as soon as they are available. Only limited attacks have been reported so far, mostly in Southeast Asia, and GTSC is deliberately hiding details of the vulnerabilities until patches come out. But remember that once patches are released, cybercriminals will immediately start working backwards to work with exploits in hopes of catching those who are slow to apply updates.
Up to this point [2022-09-30T13:30Z]It seems that the most important things to keep in mind are: [a] The tips and techniques you’ve learned to hunt down ProxyShell attacks are sure to come in handy here, if not the only tools you may need; [b] despite the similarities (and despite everything you’ve seen online), this It is not ProxyShell, so your ProxyShell patches won’t protect you; Y [c] when the patches arrive, expect them to be reverse-engineered to work again very quickly, so don’t delay in applying them.
LEARN MORE ABOUT WEBSHELLS AND HOW TO PREVENT THEM
