LATEST UPDATE (04/10/2022)
The latest guidance from Microsoft (released on the 02/10/2022) says to disable administrators from being able to execute remote PowerShell via the exchange PowerShell web endpoint /PowerShellRead more: Exploitation of Microsoft Exchange Servers seen in the wild
October 2, 2022 updates:
- Added to the Mitigations section: we strongly recommend Exchange Server customers to disable remote PowerShell access for non-admin users in your organization. Guidance on how to do this for single user or multiple users is here.
- Updated Detection section to refer to Analyzing attacks using the Exchange vulnerabilities CVE-2022-41040 and CVE-2022-41082.
- Remove exchange web services from the internet (there are reasons to do and not do this)
- Restrict hybrid servers to allow OWA to O365 only
- Leverage dynamic blocking
- Greynoise has a list of IPs known here: https://api.greynoise.io/v3/tags/8bf9b766-bf0f-452f-80bf-1d0903847793/ips?format=txt&token=rYZCpLOTf6UnUbBoUpF3Q
Obviously bear in mind this needs auth! but also auth isn’t always that hard..
Microsoft Research have just released (0825 30/09/2022) this: Customer Guidance for Reported Zero-day Vulnerabilities in Microsoft Exchange Server – Microsoft Security Response Center
Microsoft have released a Exchange Server Emergency Mitigation (EMS) which includes URL re-write rules to HELP mitigate this (but likely don’t eliminate all risks due to potential bypasses)
Current Scenario (Updated 11:27 30/09/2022)
Likely “Zero day” exploit in the wild being used to attack exchange servers via a simmilar endpoint to ProxyShell. A mitigation is to apply URL rewrite rules, or to disconect the service internet from untrsuted networks until a patch is available. The Exploit is reported to required AUTHENTICATION, which may significantly limit the volume of exploitation (however credentials are only a phish away). It’s also reported the exploitation in the wild used /Powershell after exploiting the autodiscover endpoint.
Overview (orginal post area)
Yesterday it was reported there was a “new” zero day vulnerability being exploited in the wild. But there appears to be some confusion and a lack of speciifc evidence to showcase the vulnerability being “new” or simply being a differnt exploit path/approach for an existing CVE (e.g. ProxyShell).
The situation from my pov (at time of writing) is still unclear. It would be odd to not advise people ensure they are running the latest supported Exchange CU and Security update release (check both!) – if the exploits are 0-day (which it looks like they are) you will need to also patch when MS release a patch!
- You may also wish to: use a WAF/Web Platform (IIS or reverse proxy) to restrict access to potentially vulnreable strings/endpoints.
- You should probably review vendor guidance (Microsoft)
- You may want to review your exchange servers for indicators of compromise (IOCs)
- Check log files for activity, Check for dropped webshells, Check process logs (if you have them!)
- Microsoft Recomends using the URL re-write module see (Customer Guidance for Reported Zero-day Vulnerabilities in Microsoft Exchange Server – Microsoft Security Response Center
Global Attack Surface
There are 201,995 Exchange Servers with Outlook Web Access Exposed (According to Shodan)
9.5% of the worlds Exchange attack surface is vulnerable to CVE-2021-31206
2.1% of the worlds Exchange attack surface is vulnerable to ProxyShell CVEs (above) (based on the shodan data)
Exchange CU Versions
IMPORTANT: Your NEED the LATEST Cummualative Update (CU) and the LATEST Security Updates (SU) for Exchange (and given this is a likely zero day scenario you will need to patch again when the latest patches are released from MS)
Exchange 2019 CU12 Aug22SU
Exchange 2016 CU 23 Aug22SU
Exchange Server 2013 CU23 Aug22SU
The situation appears to be evolving, as always security vulnerabilities and in the wild exploitations can be a fast moving landscape, internet facing systems need suitable and adequate protections, that doesn’t include just exposing IIS on TCP 443 and walking away. It requires capabilities such as:
- DoS/DDoS Defence Considerations
- Logging and Alerting
- Staff to monitor and respond
- Secure Configurations
- Endpoint Detection and Response Capabilities (EDR)
- Incident Response Planning
- Threat Intelligence
and many more things!
This post is a fast publish and may contain errors and/or the situation may change. I’ll try and keep it updated.