Microsoft is advising Exchange Server administrators to remove some of the endpoint antivirus exclusions that the company’s own documentation recommended in the past. The rules are no longer needed for server stability and their presence could prevent the detection of backdoors deployed by attackers.
“Times have changed, and so has the cybersecurity landscape,” the Exchange Server team said in a blog post. “We’ve found that some existing exclusions — namely the Temporary ASP.NET Files and Inetsrv folders, and the PowerShell and w3wp processes — are no longer needed, and that it would be much better to scan these files and folders. Keeping these exclusions may prevent detections of IIS webshells and backdoor modules, which represent the most common security issues.”
Why exclude Exchange folders and processes from antivirus scans?
While Microsoft has always encouraged running antivirus software on Exchange Servers for better protection, it also published guidelines to prevent possible conflicts and stability issues these may cause while performing either memory- or file-scanning activities. “The biggest potential problem is a Windows antivirus program might lock or quarantine an open log file or database file that Exchange needs to modify,” Microsoft’s documentation explains. “This can cause severe failures in Exchange Server, and it might also generate 1018 event log errors. Therefore, excluding these files from being scanned by the Windows antivirus program is very important.”
The list of recommended exclusions include many folders and files that relate to database availability groups, offline address books, mailbox databases, process logs, queues, web components, content conversion, unified messaging, transport logs, connection filtering, and syncing. They also include a long list of running processes and file types. Furthermore, these folders, processes, and file extensions can be different for different versions of Exchange.
Most of these antivirus exclusions are still critical for the stability of Exchange and shouldn’t be removed. The ones that Microsoft thinks are no longer worth keeping are:
- %SystemRoot%\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files
The Exchange Server team has validated that removing these exclusions has no performance impact when using Microsoft Defender on Exchange Server 2019 running the latest Exchange Server updates. They also believe it should be safe to remove them from Exchange Server 2016 and Exchange Server 2013 — whose support ends in April — but they advise admins to keep an eye on the servers and if any issues appear to simply add the exclusions back.
Why remove these particular exclusions?
Exchange and Microsoft IIS web servers have been a constant target for attackers in recent years as they exploit vulnerabilities in unpatched deployments to install webshells or malicious extensions/modules
In early 2021, hundreds of Microsoft Exchange Servers were hacked through zero-day vulnerabilities by a Chinese cyberespionage group dubbed Hafnium. The group deployed webshells — remotely accessible backdoor scripts — on the servers, prompting the FBI to obtain a rare warrant that allowed the agency to actually connect to the private servers and remove clean malware.
In July that same year, another APT group dubbed Praying Mantis exploited serialization flaws in ASP.NET applications to deploy fileless malware on IIS servers. This malware, dubbed NodeIISWeb, was built to hijack IIS functionality and was injected into the w3wp.exe process.
The attacks containing IIS-native malware continued, with antivirus firm ESET tracking 14 groups that used IIS backdoors and information stealers, many of them deployed as IIS extensions or modules. Some of them targeted Exchange Servers with Outlook on the web (OWA) enabled, because OWA is served using IIS. Last year, antivirus firm Kaspersky Lab reported that Exchange Servers belonging to government and military organizations from Europe, South Asia, Middle East, and Africa were infected with a malware program called SessionManager that functioned as an IIS module.
All these attacks provide a hint as to why Microsoft chose those particular antivirus exclusions: the ASP.NET temporary files folder because attackers exploited ASP.NET applications, the w3wp.exe process because malware gets injected directly into it, PowerShell because many backdoors take the form of PowerShell scripts, and the Inetsrv folder because that’s the IIS installation folder where malicious modules and extensions could be deployed.