{"id":58457,"date":"2025-04-09T17:00:00","date_gmt":"2025-04-09T17:00:00","guid":{"rendered":"https:\/\/www.threatshub.org\/blog\/stopping-attacks-against-on-premises-exchange-server-and-sharepoint-server-with-amsi\/"},"modified":"2025-04-09T17:00:00","modified_gmt":"2025-04-09T17:00:00","slug":"stopping-attacks-against-on-premises-exchange-server-and-sharepoint-server-with-amsi","status":"publish","type":"post","link":"https:\/\/www.threatshub.org\/blog\/stopping-attacks-against-on-premises-exchange-server-and-sharepoint-server-with-amsi\/","title":{"rendered":"Stopping attacks against on-premises Exchange Server and SharePoint Server with AMSI"},"content":{"rendered":"

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>, 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.<\/p>\n

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<\/a> and ProxyNotShell<\/a> 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.<\/a> 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<\/a>.<\/p>\n

SharePoint Server has also been a consistent target for attackers exploiting critical vulnerabilities<\/a> 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<\/em>, installing remote monitoring and management (RMM) tools for broader access, and other malicious activities were observed.<\/p>\n

While cloud-based software offers some inherent security advantages in software updates and high availability, some organizations\u2019 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.<\/p>\n

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.<\/p>\n

AMSI integration<\/h2>\n

In both SharePoint Server<\/a> and Exchange Server<\/a>, 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<\/em> stage through the SPRequesterFilteringModule <\/strong>for SharePoint Server and HttpRequestFilteringModule <\/strong>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 <\/strong>response.<\/strong><\/p>\n

\"Diagram
Figure 1. Overview of AMSI Integration in SharePoint and Exchange Server<\/figcaption><\/figure>\n
\"Screenshot
Figure 2. AMSI protecting against mailbox exfiltration using public tool MailSniper<\/figcaption><\/figure>\n

Extending AMSI with request body scan<\/h3>\n

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.<\/p>\n

To address this emerging risk, we added newer improvements in both products. The Exchange Server November release<\/a> extended capabilities to include scanning of request bodies, ensuring broader protection. A similar improvement is added to SharePoint Server currently in public preview<\/a>. These enhanced security controls are not enabled by default, making it crucial for organizations to assess for stronger protection.<\/p>\n

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.<\/p>\n

Attacks targeting Exchange and SharePoint servers<\/h2>\n

SSRF exploitation<\/h3>\n

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.<\/p>\n

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.<\/p>\n

\"Screenshot
Figure 3. AMSI logs for CVE-2023-29357 with spoofed X-PROOF_TOKEN and Authorization headers<\/figcaption><\/figure>\n

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.<\/p>\n

\"Screenshot
Figure 4. AMSI logs for CVE-2022-41040 with malformed Autodiscover Request<\/figcaption><\/figure>\n

AMSI acted as first layer of defense<\/a> against these incidents, protecting customers against thousands of SSRF attempts observed on a daily basis, thereby breaking the exploitation chain.<\/p>\n

Suspicious access indicative of web shell interaction<\/h3>\n

In many intrusions, attackers drop web shells into public-facing directories. In one such Exchange server compromise, AMSI logged a suspicious .aspx<\/em> file interaction. This was highlighted by Microsoft Defender for Endpoint simply because there is no .aspx<\/em> file by that name in the said folder path: <\/p>\n

C:\\Program Files\\Microsoft\\Exchange Server\\V15\\FrontEnd\\HttpProxy\\owa\\auth\\Current\\scripts\\premium\\<\/em>. <\/p>\n

Attackers often rename web shells to legitimate filenames seen in different folder to avoid suspicion. In this case, the filename getidtoken <\/em>is a default shipped file but with .htm<\/em> extension.<\/p>\n

\"A
Figure 5. suspicious POST request logged in AMSI hinting at web shell interaction<\/figcaption><\/figure>\n

Similar stealthy activities have also been observed for SharePoint. In one case, the attackers modified the legitimate signout.aspx<\/em> file by appending web shell code. This allowed attackers to create a stealthy backdoor and maintain persistence without raising suspicion.<\/p>\n

\"Screenshot
Figure 6. Modified signout.aspx with web shell code appended at the end<\/figcaption><\/figure>\n

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\u2019s 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.<\/p>\n

\"Screenshot
Figure 7. Legitimate signout.aspx with hijacked \u2019username\u2019 parameter supplied with command<\/figcaption><\/figure>\n

Suspicious mailbox access through Exchange Web Services (EWS) abuse<\/h3>\n

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<\/a>, EWS was used post-compromise to search mailboxes for sensitive content and exfiltrate emails over HTTPS, blending in with legitimate traffic.<\/p>\n

Attackers leverage EWS\u2019s 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 \u2014 GetFolder<\/em>, FindItem<\/em>, and GetItem<\/em> \u2014 to stealthily search and exfiltrate sensitive emails from compromised mailboxes. GetFolder<\/em> API maps the mailbox structure, which can be used to identify key folders like Inbox and Sent Items. FindItem<\/em> API allows searching for emails containing specific keywords or supplied datetime filter to retrieve relevant results. Finally, GetItem<\/em> API is used to view full email contents and attachments.<\/p>\n

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.<\/p>\n

\"Screenshot<\/figure>\n
\"Screenshot<\/figure>\n
\"Screenshot
Figure 8. AMSI logs showing suspicious sequence of SOAP operations seen during remote mailbox access<\/figcaption><\/figure>\n

Insecure deserialization leading to RCE<\/h3>\n

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.<\/p>\n

A common pattern seen in these attacks is the use of legitimate management cmdlets like Get-Mailbox<\/em>, New-MailboxExportRequest<\/em>, or Set-<\/em> 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<\/em>, various file write APIs and Assembly.load<\/em>.<\/p>\n

\"Screenshot<\/figure>\n
\"Screenshot
Figure 9. AMSI logs showing the malicious argument to Get-Mailbox cmdlet.<\/figcaption><\/figure>\n

Web control abuse<\/h3>\n

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 <\/em>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<\/em> file is uploaded and registered in SharePoint\u2019s 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<\/em> type as DotNetAssembly<\/em> hinting at code execution. AMSI\u2019s deep integration enables visibility into the malicious Base64 buffer, which Microsoft Defender for Endpoint leverages to detect and block code execution attempts.<\/p>\n

\"Screenshot<\/figure>\n
\"Screenshot
Figure 10. AMSI logs showing upload of malicious .bdcm file with the package content<\/figcaption><\/figure>\n

Mitigation and protection guidance<\/h2>\n

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:<\/p>\n