Exchange Server and SharePoint Server are business-critical assets and considered crown jewels for many organizations, making them attractive targets for attacks. To help customers protect their environments and respond to these attacks, Exchange Server and SharePoint Server now integrate with the Windows Antimalware Scan Interface (AMSI), a versatile standard that enables applications and services to work seamlessly with any AMSI-compatible antimalware product. The integration of AMSI with SharePoint and Exchange Server provides an essential layer of protection by preventing harmful web requests from reaching backend endpoints.
Threat actors have consistently relied on outdated or misconfigured assets, exploiting vulnerabilities that enable them to gain a persistent foothold inside the target. For instance, in the case of Exchange Server, ProxyShell and ProxyNotShell vulnerabilities were widely exploited in attacks long after they were fixed by security updates in 2021 and 2022, respectively. In these attacks, threat actors abused a combination of server-side request forgery (SSRF) and privilege escalation flaws, allowing remote code execution. Successful compromise enabled threat actors to drop web shells, conduct lateral movement, and exfiltrate sensitive data, often evading detection for extended periods. More recently, attackers have shifted to NTLM relay and credential leakage techniques. Office documents and emails sent through Outlook serve as effective entry points for attackers to exploit NTLM coercion vulnerabilities, given their ability to embed UNC links within them. Attackers exploit NTLM authentication by relaying credentials to a vulnerable server, potentially resulting in target account compromise. Microsoft has released mitigation guidance against NTLM relay attacks.
SharePoint Server has also been a consistent target for attackers exploiting critical vulnerabilities to gain persistent and privileged access inside the target. In recent attacks, stealthy persistence tactics, such as replacing or appending web shell code into existing files like signout.aspx, installing remote monitoring and management (RMM) tools for broader access, and other malicious activities were observed.
While cloud-based software offers some inherent security advantages in software updates and high availability, some organizations’ requirements mean they need to run on-premises Exchange and SharePoint implementations. As cyber threats continue to grow in sophistication, it has never been more important to ensure that the on-premises infrastructure remains secure. This AMSI integration on SharePoint Server and Exchange Server becomes especially important when attackers attempt to exploit security vulnerabilities, particularly zero-days. With AMSI integrated, these malicious attempts are detected and blocked in real-time, offering a critical defense mechanism while organizations work on installing official patches and updates. AMSI detections are surfaced on the Microsoft Defender portal, enabling SecOps teams to investigate, correlate with other malicious activity in the environment, and remediate.
In this blog post, we discuss different types of attacks targeting Exchange and SharePoint, and demonstrate how AMSI is helping organizations protect against these attacks. We also share mitigation and protection guidance, as well as detection details and hunting queries.
In both SharePoint Server and Exchange Server, AMSI is integrated as a security filter module within the IIS pipeline to inspect incoming HTTP requests before they are processed by the application. The filter is triggered at the onBeginRequest stage through the SPRequesterFilteringModule for SharePoint Server and HttpRequestFilteringModule for Exchange Server, allowing it to analyze incoming requests before they reach authentication and authorization phases. This integration ensures that potential threats are identified before they interact with internal processing, mitigating the risk of exploitation. On detecting a malicious request, the application returns a HTTP 400 Bad Request response.
When AMSI was first integrated, it provided an important layer of defense by scanning incoming request headers. This was crucial for identifying malicious activity, particularly SSRF attempts. However, many modern attacks are now embedded within request bodies, rather than just in the headers. This meant that header-only scans were no longer enough to catch the full range of sophisticated threats.
To address this emerging risk, we added newer improvements in both products. The Exchange Server November release extended capabilities to include scanning of request bodies, ensuring broader protection. A similar improvement is added to SharePoint Server currently in public preview. These enhanced security controls are not enabled by default, making it crucial for organizations to assess for stronger protection.
Microsoft recommends evaluating and enabling these extended options for better protection and visibility. These enhancements are especially important for detecting and mitigating remote code execution vulnerabilities and particularly post-authentication vulnerabilities where SSRF may not be needed. The introduction of request body scanning is a critical step in our commitment to protect these crown jewels against more sophisticated, evasive threats. With the ability to inspect the full content of incoming requests, AMSI now detects a wider range of malicious activities.
Server-side request forgery (SSRF) can allow attackers to make unauthorized requests on behalf of the server, potentially accessing internal services, metadata endpoints, or even escalating privileges. Attackers can exploit SSRF to bypass authentication mechanisms by leveraging internal API calls. Additionally, by chaining SSRF with additional flaws, attackers could gain unauthorized access to the backend and perform arbitrary remote code execution within the environment.
One example is CVE-2023-29357, a critical authentication bypass vulnerability in SharePoint Server. This flaw allowed attackers to bypass authentication and gain elevated privileges by exploiting improper validation of security tokens. In attacks, this was combined with another vulnerability, CVE-2023-24955, to achieve unauthenticated remote code execution on vulnerable SharePoint servers.
Another example is CVE-2022-41040, an AutoDiscover SSRF vulnerability in Exchange Server. By targeting AutoDiscover, attackers exploited the trust relationships within Exchange to impersonate users and trigger backend functionality that normally requires authentication, laying the groundwork for remote code execution.
AMSI acted as first layer of defense against these incidents, protecting customers against thousands of SSRF attempts observed on a daily basis, thereby breaking the exploitation chain.
In many intrusions, attackers drop web shells into public-facing directories. In one such Exchange server compromise, AMSI logged a suspicious .aspx file interaction. This was highlighted by Microsoft Defender for Endpoint simply because there is no .aspx file by that name in the said folder path:
C:Program FilesMicrosoftExchange ServerV15FrontEndHttpProxyowaauthCurrentscriptspremium.
Attackers often rename web shells to legitimate filenames seen in different folder to avoid suspicion. In this case, the filename getidtoken is a default shipped file but with .htm extension.
Similar stealthy activities have also been observed for SharePoint. In one case, the attackers modified the legitimate signout.aspx file by appending web shell code. This allowed attackers to create a stealthy backdoor and maintain persistence without raising suspicion.
AMSI acts as a real-time inspection and defense layer similar to a web application firewall (WAF) and plays a critical role in detecting and responding to active compromises. AMSI inspects incoming requests, captures malicious web shell interactions, and logs them for analysis. This level of visibility enables Microsoft Defender for Endpoint to pinpoint the exact location of malicious files on disk, such as within Exchange’s Outlook Web Application (OWA), where attackers commonly stage web shells. By correlating AMSI network logs with suspicious activity, Microsoft Defender for Endpoint can locate and remove previously undetected files, effectively cleaning the infected server and mitigating further damage. Importantly, this capability provides durable protection, allowing defenders to monitor and react to threats even in post-compromise scenarios.
Exchange Web Services (EWS) is a core component of Microsoft Exchange that allows programmatic access to mailboxes through SOAP-based APIs. While this is critical for legitimate operations such as Outlook integration, mobile sync, and third-party app, the service is also widely abused by threat actors. Notably, in incidents like CVE-2023-23397, EWS was used post-compromise to search mailboxes for sensitive content and exfiltrate emails over HTTPS, blending in with legitimate traffic.
Attackers leverage EWS’s deep access to perform mailbox searches, download entire inboxes, and set up hidden forwarding rules, often using stolen credentials or after gaining a foothold via another Exchange vulnerability. Attackers commonly abuse EWS APIs — GetFolder, FindItem, and GetItem — to stealthily search and exfiltrate sensitive emails from compromised mailboxes. GetFolder API maps the mailbox structure, which can be used to identify key folders like Inbox and Sent Items. FindItem API allows searching for emails containing specific keywords or supplied datetime filter to retrieve relevant results. Finally, GetItem API is used to view full email contents and attachments.
This API-driven abuse technique blends in with legitimate EWS traffic, making detection challenging without deep content inspection. AMSI addresses this with request body scanning, which enables real-time detection of suspicious search patterns, abnormal access, and targeted email theft. Below is a sequence of suspicious SOAP calls logged by AMSI when attackers attempt to exfiltrate emails.
The PowerShell application pool is a privileged component that handles remote PowerShell sessions in Exchange, typically invoked by Exchange Control Panel (ECP) or Exchange Management Shell (EMS). It runs under SYSTEM or high-privileged service accounts, making it a prime target for misuse. After gaining access to backend PowerShell endpoints, attackers can pass crafted cmdlets and arguments that trigger operations such as arbitrary file writes and command execution. This method has been observed in major incidents like ProxyShell and ProxyNotShell, where attackers execute system-level commands via crafted PowerShell requests.
A common pattern seen in these attacks is the use of legitimate management cmdlets like Get-Mailbox, New-MailboxExportRequest, or Set- commands, but with crafted arguments or malicious serialization payloads that trigger code execution in the backend. AMSI now has complete visibility into all the backend PowerShell commands along with the passed arguments to inspect the request buffer for any suspicious API calls such as Process.Start, various file write APIs and Assembly.load.
Exploitation of vulnerabilities like CVE-2024-38094, CVE-2024-38024, and CVE-2024-38023 exemplify attacks that abuse Site owner privileges to execute arbitrary code on the SharePoint server. The exploitation leverages the Business Data Connectivity (BDC) feature and malicious use of the BDCMetadata.bdcm file. This XML-based file defines connections to external data sources but could be abused to reference dangerous .NET classes and methods. Once the malicious .bdcm file is uploaded and registered in SharePoint’s BDC service (using site owner permissions), the attacker can trigger execution by creating an External List or web part that interacts with the BDC model. SharePoint processes this model and reflectively loads and executes the specified method, leading to RCE as the SharePoint service account, which typically has high privileges. With body scan enabled, the complete payload is available for inspection and surfaces LobSystem type as DotNetAssembly hinting at code execution. AMSI’s deep integration enables visibility into the malicious Base64 buffer, which Microsoft Defender for Endpoint leverages to detect and block code execution attempts.
As these attacks show, SharePoint and Exchange servers are high-value targets. These attacks also tend to be advanced threats with highly evasive techniques. Keeping these servers safe from these advanced attacks is of utmost importance. Here are steps that organizations can take:
Microsoft Defender XDR customers can refer to the list of applicable detections below. Microsoft Defender XDR coordinates detection, prevention, investigation, and response across endpoints, identities, email, apps to provide integrated protection against attacks like the threat discussed in this blog.
Customers with provisioned access can also use Microsoft Security Copilot in Microsoft Defender to investigate and respond to incidents, hunt for threats, and protect their organization with relevant threat intelligence.
Microsoft Defender Antivirus detects threats on SharePoint Server as the following malware:
Microsoft Defender Antivirus detects threats on Exchange Server as the following malware:
The following Microsoft Defender for Endpoint alerts might indicate activity related to this threats discussed in this blog. Note, however, that these alerts can be also triggered by unrelated threat activity.
Microsoft Defender Vulnerability Management surfaces devices that may be affected by the following vulnerabilities used by the threats discussed in this blog:
CVE-2021-34473, CVE-2021-34523, CVE-2021-31207, CVE-2022-41040, CVE-2022-41082, CVE-2019-0604, CVE-2024-21413, CVE-2023-23397, CVE-2023-36563, CVE-2023-29357, CVE-2023-24955, CVE-2024-38094, CVE-2024-38024, CVE-2024-38023
Microsoft Security Exposure Management (MSEM) provides enhanced visibility for important assets by offering customers predefined classification logics for high-value assets. This includes both managed (Microsoft Defender for Endpoint-onboarded) and unmanaged Exchange servers.
Customers can review the device inventory and the critical classification library to identify Exchange servers and consider applying the new security settings on them.
Security Copilot customers can use the standalone experience to create their own prompts or run the following pre-built promptbooks to automate incident response or investigation tasks related to this threat:
Note that some promptbooks require access to plugins for Microsoft products such as Microsoft Defender XDR or Microsoft Sentinel.
Microsoft Defender XDR customers can run the following query to find related activity in their networks:
Processes run by the IIS worker process
Broadly search for processes executed by the IIS worker process. Further investigation should be performed on any devices where the created process is indicative of reconnaissance.
DeviceProcessEvents
| where InitiatingProcessFileName == 'w3wp.exe'
| where InitiatingProcessCommandLine contains "MSExchange" or InitiatingProcessCommandLine contains "SharePoint"
| where FileName !in~ ("csc.exe","cvtres.exe","conhost.exe","OleConverter.exe","wermgr.exe","WerFault.exe","TranscodingService.exe")
| project FileName, ProcessCommandLine, InitiatingProcessCommandLine, DeviceId, Timestamp
Chopper web shell command line
Chopper is one of the most widespread web shells targeting SharePoint and Exchange servers. Use this query to hunt for Chopper web shell activity:
DeviceProcessEvents
| where InitiatingProcessFileName =~ "w3wp.exe" and FileName == "cmd.exe"
| where ProcessCommandLine has "&cd&echo"
Suspicious files in SharePoint or Exchange directories
DeviceFileEvents
| where Timestamp >= ago(7d)
| where InitiatingProcessFileName == "w3wp.exe"
| where FolderPath has "FrontEndHttpProxy" or FolderPath has "TEMPLATELAYOUTS " or FolderPath has "aspnet_client"
| where InitiatingProcessCommandLine contains "MSExchange" or InitiatingProcessCommandLine contains "Sharepoint"
| project FileName,FolderPath,SHA256, InitiatingProcessCommandLine, DeviceId, Timestamp
Microsoft Sentinel customers can use the TI Mapping analytics (a series of analytics all prefixed with ‘TI map’) to automatically match the malicious domain indicators mentioned in this blog post with data in their workspace. If the TI Map analytics are not currently deployed, customers can install the Threat Intelligence solution from the Microsoft Sentinel Content Hub to have the analytics rule deployed in their Sentinel workspace.
Our post on web shell threat hunting with Microsoft Sentinel also provides guidance on looking for web shells in general. The Exchange SSRF Autodiscover ProxyShell detection, which was created in response to ProxyShell, can be used for queries due to functional similarities with this threat. Also, the new Exchange Server Suspicious File Downloads and Exchange Worker Process Making Remote Call queries specifically look for suspicious downloads or activity in IIS logs. In addition to these, we have a few more that could be helpful in looking for post-exploitation activity:
For the latest security research from the Microsoft Threat Intelligence community, check out the Microsoft Threat Intelligence Blog: https://aka.ms/threatintelblog.
To get notified about new publications and to join discussions on social media, follow us on LinkedIn at https://www.linkedin.com/showcase/microsoft-threat-intelligence, and on X (formerly Twitter) at https://x.com/MsftSecIntel.
To hear stories and insights from the Microsoft Threat Intelligence community about the ever-evolving threat landscape, listen to the Microsoft Threat Intelligence podcast: https://thecyberwire.com/podcasts/microsoft-threat-intelligence.
The post Stopping attacks against on-premises Exchange Server and SharePoint Server with AMSI appeared first on Microsoft Security Blog.
Source: Microsoft Security