[ad_1]
The Windows Antimalware Scan Interface (AMSI) is a versatile standard that allows applications and services to integrate with any antimalware product present on a machine. AMSI is vendor agnostic and designed to allow for the most common malware scanning and protection techniques provided by today’s products to be integrated into applications.
Seeing that Exchange administrators might not be familiar with AMSI, we wanted to provide an overview of various components that make this work, because…
Exchange Server integration arrives
As of the June 2021 quarterly updates, Exchange Server supports integration with AMSI. This provides the ability for an AMSI-capable antivirus/antimalware solution to scan content in HTTP requests sent to the Exchange Server and block a malicious request before it is handled by Exchange. The scan is performed in real-time as the server begins to process the request. AMSI, as implemented in June 2021 Cumulative Updates (CUs), only scans the HTTP protocol, and is not meant to be a replacement to existing server-level or message hygiene protections.
There is no observed performance impact from AMSI scanning when tested with Microsoft Defender and no changes to be made to the existing documented Exchange Sever antivirus exclusions. Each antivirus provider develops their own definitions that utilize AMSI technology, therefore your level of protection remains dependent on how quickly your specific solution can be dynamically updated to detect the latest threats.
The following steps will help you understand a bit more about what is needed on each of the Exchange servers to ensure that AMSI Integration is enabled and working:
AMSI integration with Exchange Server prerequisites
To start let’s make sure our Exchange Server can even support AMSI integration. Check the following prerequisites on each server:
- Windows Server 2016, or higher
- Exchange Server 2016 CU21 / Exchange Server 2019 CU10, or higher
- Microsoft Defender with AV engine version at or higher than 1.1.18300.4 (alternatively, a compatible AMSI capable third-party AV provider – please check with your vendor)
How to find your installed AMSI provider
Now that you have met the prerequisites let’s confirm that you have an AMSI provider installed on the server. To do so you will need to run the following Windows PowerShell commands and review the output:
Get-ChildItem ‘HKLM:SOFTWAREMicrosoftAMSIProviders’ -recurse
Get-ChildItem ‘HKLM:SOFTWAREClassesCLSID{GUID obtained from previous command}’
For example, you can set a variable and then search for the RegEx Results of all AMSI Providers installed by running:
$AMSI = Get-ChildItem ‘HKLM:SOFTWAREMicrosoftAMSIProviders’ -Recurse
$AMSI -match ‘[0-9A-Fa-f-]{36}’
$Matches.Values | ForEach-Object {Get-ChildItem “HKLM:SOFTWAREClassesCLSID{$_}” | Format-Table -AutoSize}
For example:
Windows PowerShell
Copyright (C) Microsoft Corporation. All rights reserved.
C:PowerShell> $AMSI = Get-ChildItem ‘HKLM:SOFTWAREMicrosoftAMSIProviders’ -Recurse
C:PowerShell> $AMSI -match ‘[0-9A-Fa-f-]{36}’
C:PowerShell> $Matches.Values | ForEach-Object {Get-ChildItem “HKLM:SOFTWAREClassesCLSID{$_}” | Format-Table -AutoSize} Hive: HKEY_LOCAL_MACHINESOFTWAREClassesCLSID{2781761E-28E0-4109-99FE-B9D127C57AFE}
Name Property
—- ——–
Hosts (default) : Scanned Hosting Applications
Implemented Categories
InprocServer32 (default) : “C:ProgramDataMicrosoftWindows DefenderPlatform4.18.2106.6-0MpOav.dll”
ThreadingModel : Both
The results show us that the only provider we have installed is in C:ProgramDataMicrosoftWindows DefenderPlatform4.18.2106.6-0MpOav.dll which is Microsoft Windows Defender. So now we know that the Windows 2016 operating system or higher sees our AMSI Provider installation.
Web.config files
Next for AMSI Integration to work correctly we need to make sure that the HttpRequestFilteringModule line below is present in the <Modules> section of the FrontEnd and ClientAccess web.config files:
<add name=”HttpRequestFilteringModule” type=”Microsoft.Exchange.HttpRequestFiltering.HttpRequestFilteringModule, Microsoft.Exchange.HttpRequestFiltering, Version=15.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35″ />
If you make a habit of replacing web.config files, you need to make sure that you have this line or AMSI will not work properly.
Confirm your Windows Defender version via the command line
If you are using Microsoft Windows Defender jump into the command line and make sure you have updated the signatures to the latest version.
- Launch Command Prompt as an administrator
- Navigate to C:ProgramDataMicrosoftWindows DefenderPlatform<antimalware platform version>
- Run mpcmdrun.exe -SignatureUpdate. This will check for the latest definitions and report your current engine version.
Microsoft Windows Command Prompt
Copyright (C) Microsoft Corporation. All rights reserved.
C:ProgramDataMicrosoftWindows DefenderPlatform4.18.2105.5-0>MpCmdRun.exe -SignatureUpdate
Signature update started . . .
Service Version: 4.18.2106.6
Engine Version: 1.1.18300.4
AntiSpyware Signature Version: 1.343.1364.0
AntiVirus Signature Version: 1.343.1364.0
Signature update finished. No updates needed
C:ProgramDataMicrosoftWindows DefenderPlatform4.18.2105.5-0>
Confirm that AMSI integration is working
If any request is detected to be malicious by the AMSI module it is logged in the %ExchangeInstallPath%LoggingHttpRequestFiltering folder and the value for ScanResult is “Detected”. This module does not create logs for safe calls so, if a log is present then a malicious call was seen at some point. When a request get blocked IIS will issues return code 400 / Bad Request back to the requestor.
Once a malicious connection is detected the log will look something like this:
DateTime,MajorVersion,MinorVersion,BuildVersion,RevisionVersion,ServerHostName,SharedCacheLatency,TotalLatency,HttpMethod,UrlHost,UrlStem,UrlQuery,ServerIP,Protocol,HeaderNames,CookieNames,ScanResult,GenericInfo,GenericErrors
#Software: Microsoft Exchange Server
#Version: 15.01.build
#Log-type: Http Request Filtering Logs
#Date: 2021-06-30T10:03:57.573Z
#Fields:
DateTime,MajorVersion,MinorVersion,BuildVersion,RevisionVersion,ServerHostName,SharedCacheLatency,TotalLatency,HttpMethod,UrlHost,UrlStem,UrlQuery,ServerIP,Protocol,HeaderNames,CookieNames,ScanResult,GenericInfo,GenericErrors
6/30/2021 10:03:57 AM,15,1,2334,0,SERVER01,,,POST,localhost,/ecp/x.js,,::1,FrontEnd.Ecp,Content-Length;Cookie;Host,X-BEResource,Detected,,
6/30/2021 10:09:41 AM,15,1,2334,0,SERVER01,,,POST,SERVER01.contoso.com,/ecp/x.js,,192.168.10.52,FrontEnd.Ecp,Content-Length;Cookie;Host,X-BEResource,Detected,,
6/30/2021 10:09:43 AM,15,1,2334,0,SERVER01,,,POST,SERVER01.contoso.com,/ecp/x.js,,192.168.10.52,FrontEnd.Ecp,Content-Length;Cookie;Host,X-BEResource,Detected,,
How to disable AMSI integration with Exchange Server
If for some reason you need to temporarily disable the AMSI integration for testing or troubleshooting purposes. You can do so by opening Exchange Management Shell and create a new server override:
Welcome to the Exchange Management Shell!
[PS] C:PowerShell> New-SettingOverride -Name “DisablingAMSIScan” -Component Cafe -Section HttpRequestFiltering -Parameters (“Enabled=False”) -Reason “Testing”
[PS] C:PowerShell> Get-ExchangeDiagnosticInfo -Process Microsoft.Exchange.Directory.TopologyService -Component VariantConfiguration -Argument Refresh
[PS] C:PowerShell> Restart-Service -Name W3SVC, WAS -Force
Once your testing is complete, re-enable the AMSI integration by removing the setting override:
Welcome to the Exchange Management Shell!
[PS] C:PowerShell> Remove-SettingOverride -Name “DisablingAMSIScan” -Component Cafe -Section HttpRequestFiltering -Parameters (“Enabled=False”) -Reason “Testing”
[PS] C:PowerShell> Get-ExchangeDiagnosticInfo -Process Microsoft.Exchange.Directory.TopologyService -Component VariantConfiguration -Argument Refresh
[PS] C:PowerShell> Restart-Service -Name W3SVC, WAS -Force
You will have to restart the Internet Information Services (IIS) on the machine which will disrupt connectivity so make sure to do this when there will be no impact to the server or under a maintenance period.
Self-service test script
The new script we have created will let you test your Exchange Server AMSI integration with Microsoft Defender. The script can send a crafted HTTP request that will trigger the anti-malware scanner and once run you can check the HttpRequestFiltering folder for a log. The script can also check your AMSI Providers on the system and even enable and disable AMSI integration. The script is available at the CSS-Exchange Repo on GitHub [Test-AMSI]. Please see GitHub for script usage tips / documentation!
Source link
