Just when you hoped the week would quieten down and yield you some SecOps downtime over the weekend…
…and along comes a brand new zero-day hole in Microsoft Exchange!
More precisely, two zero-days that can apparently be chained together, with the first bug used remotely to open enough of a hole to trigger the second bug, which potentially allows remote code execution (RCE) on the Exchange server itself.
Microsoft quickly published official guidance about these vulnerabilities, summarising 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-41040, is a Server-Side Request Forgery (SSRF) vulnerability, while the second, identified as CVE-2022-41082, allows remote code execution (RCE) when PowerShell is accessible to the attacker.
At this time, Microsoft is aware of limited targeted attacks using the two vulnerabilities to get into users’ systems. In these attacks, CVE-2022-41040 can enable an authenticated attacker to remotely trigger CVE-2022-41082. It should be noted that authenticated access to the vulnerable Exchange Server is necessary to successfully exploit either of the two vulnerabilities.
As far as we can see, there is a silver linings here:
- The bugs can’t be triggered by just anyone. Sure, any remote user who has already logged into to their email account over the internet, and whose computer is infected by malware, could in theory have their account subverted to launch an attack that exploits these bugs. But just having your Exchange server accessible over the internet is not enough on its own to expose you to attack, because so-called unauthenticated invocation of these bugs 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 actually prevent) attackers from chaining from the first vulnerability to the second. Although attacks might be possible without relying on triggering PowerShell commands, intrusion reports so far seem to suggest that PowerShell execution was a necessary part of the attack.
Update. The original version of this article listed a second “silver lining”, based on Microsoft’s recommendation to block TCP ports 5985 and 5986 on your Exchange server to shut off what’s known as PowerShell remoting. Microsoft claimed this would “limit” attackers from chaining from the first vulnerability to the second. That recommendation has now vanished without explanation from Microsoft’s own guidance, which now advises simply that you “disable remote PowerShell access for non-admin users”. There is no indication of whether this change specifically prevents this exploit, or is just a worthwhile security change anyway. [2022-10-08T20:00:00Z]
Memories of ProxyShell
If this attack reminds you of the ProxyShell vulnerability from about a year ago, you’re not alone in thinking that.
According to GTSC, the Vietnamese cybersecurity company that first investigated and reported these new holes, researchers “detected exploit requests in IIS logs with the same format as [the] ProxyShell vulnerability”.
Notably, the sort of threat-hunting query that we recommended for ProxyShell exploit spelunking back in 2021 seems to work for detecting abuse of these new zero-days, too:
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, notes 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 don’t yet know whether the new attack can be pulled off without leaving this specific tell-tale sign in your logs.
In other words, if you find trigger signs similar to those left behind by PowerShell exploits, you probably do have evidence of an attack, but absence of these signs is not evidence of absence.
According to GTSC, in attacks they’ve investigated so far, the cybercriminals used their unauthorised RCE powers to implant and run a variety of follow-on malware, including:
- Webshells implanted to open a web-based backdoor for later. Webshells typically allow follow-on attacks to embed arbitrary system commands, with arbitrary command arguments, into regular-looking HTTP requests. The webshell then directly executes the desired command with the privileges of the web server itself.
- Credential dumping malware. Credential stealers typically snoop around on disk and in memory (if they have sufficient privilege) looking for plaintext passwords, session cookies and authentication tokens that could allow what’s known as lateral movement to other computers on the network.
- Zombie malware in the form of DLLs loaded into legitimate-looking processes. One DLL sample that GTSC researchers analysed could be remotely fed with encrypted instructions to dump system information, run arbitrary commands, launch C# modules, and modify files and folders on the infected system.
We will update this article as we learn more, including reporting when Microsoft gets patches out to close these holes.
Threat hunting advice
For threat hunting advice from GTSC, who discovered and reported the bugs, from Microsoft, and from Sophos, please see:
What to do?
Mitigations include:
- Block PowerShell Remoting to reduce the risk of RCE. 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 of how to use IIS Server URL rewriting rules to detect and neutralise common forms of this attack.
- Ensure behavioural endpoint threat detection is enabled, even on servers. As mentioned above, GTSC reports that attacks seen so far include the implanting of webshells and malware DLLs to run arbitrary commands, manipulate files, and extract system information. This gives you numerous potentional detection-and-response indicators to get on top of a successful attack.
- Consider deauthenticating logged-in email users. If you can perform some sort of endpoint security assessment on each user’s device before allowing them to reauthenticate, you will reduce (albeit not eliminate) the risk of already-compromised devices being co-opted into launching attacks. You will also reduce what’s known as your overall attack surface by not having authenticated users hanging around who don’t need to be logged on, or who don’t even remember that they ever logged on in the first place.
- Apply any patches as soon as they are available. So far, only limited attacks have been reported, mostly in South East Asia, and GTSC is deliberately witholding details of the vulnerabilities until patches are out. But remember that once patches are published, cybercriminals will immediately start working backwards towards working exploits in the hope of catching out those who are tardy at applying updates.
So far [2022-09-30T13:30Z], it looks as though the most important things to bear in mind are: [a] the tips and techniques you learned for hunting down ProxyShell attacks are almost certainly going to be helpful here, if not the only tools you may need; [b] despite the similarities (and notwithstanding anything you may have seen online), this isn’t ProxyShell, so your your ProxyShell patches won’t protect you from it; and [c] when patches do arrive, assume that they will be reverse engineered back into working exploits very quickly, so don’t delay in applying them.
LEARN MORE ABOUT WEBSHELLS AND HOW TO PREVENT THEM