In discussions with customers about the current situation — where active attacks are targeting on-premises SharePoint servers — it has become clear that additional clarity is needed regarding how AMSI integration works in SharePoint.
Here are some of the questions we’ve received:
Question: How can we verify if AMSI is working correctly in SharePoint
Answer: The first step is to verify that AMSI is functioning correctly at the operating system level. This can be done using the following PowerShell command:
AMSI Test Sample: 7e72c3ce-861b-4339-8740-0ac1484c1386
(This command works for Microsoft Defender. If you are using a different AV solution, please contact the vendor on how to test AMSI in their implementation.)
If AMSI is working as expected, you should receive a response indicating that malicious content was blocked, similar to this:
The second step is to check whether AMSI is working correctly in SharePoint. This can be done by executing the following PowerShell command (after updating the URL) against all SharePoint web applications:
Invoke-WebRequest -Uri "https://servername/sites/sitename?amsiscantest:x5opap4pzx54p7cc7$eicar-standard-antivirus-test-fileh+h*" -Method GET
Alternatively you can just enter this Url in your browser (again after updating it):
https://servername/sites/sitename?amsiscantest:x5opap4pzx54p7cc7-standard-antivirus-test-fileh+h*
If AMSI works correctly, you should see a 400 Bad Request response, as AMSI blocked the request.
Question: We have fully patched our SharePoint servers and did the key rotation. Why do we still get Defender messages similar to the following from the w3wp.process.
Answer: This is expected! The SharePoint AMSI integration uses a module in the IIS pipeline that passes all requests through AMSI to your antivirus solution before they reach SharePoint. If a request is malicious, it will be flagged accordingly, indicating that it originated from the w3wp.exe process, which passed it to the antivirus via AMSI.
In other words, this message confirms that a malicious request was received and blocked by AMSI before it could reach SharePoint. This behavior is independent of whether the patches have been installed or the machine keys have been rotated.
Question: How can AMSI in SharePoint be enabled and configured
Answer: Please follow the guidance provided in the following article: Configure AMSI integration with SharePoint Server.
References:
Permalink
Hello Stefan,
We have one more question.
We do not have a Defender. (We use Trellix)
AMSI is activated on the SharePoint side.
Can I use it to test AMSI at all?
AMSI Test Sample: 7e72c3ce-861b-4339-8740-0ac1484c1386
We get the following. back:
PS C:\Windows\system32> AMSI Test Sample: 7e72c3ce-861b-4339-8740-0ac1484c1386
AMSI : The term ‘AMSI’ is not recognized as the name of a cmdlet, function, script file, or operable program. Check
the spelling of the name, or if a path was included, verify that the path is correct and try again.
At line:1 char:1
+ AMSI Test Sample: 7e72c3ce-861b-4339-8740-0ac1484c1386
+ ~~~~
+ CategoryInfo : ObjectNotFound: (AMSI:String) [], CommandNotFoundException
+ FullyQualifiedErrorId : CommandNotFoundException
Translated with DeepL.com (free version)
Permalink
Hi Marcel,
good question. I found this on the Trellix website:
https://docs.trellix.com/bundle/amsi_2-1-0_ug/page/configuring-the-amsi-module/configuring-the-amsi-agent-module/verifying-amsi-detection.html
Cheers,
Stefan
Permalink
The link provided is obsolete (gives an error says „https://secure.eicar.org cannot be resolved“). Here’s the up-to-date version: https://thrive.trellix.com/s/article/KB94627?language=en_US
Permalink
Thanks Stefan,
the command works.
Permalink
I’m going through your recommended tests.
Test: AMSI Test Sample: 7e72c3ce-861b-4339-8740-0ac1484c1386
Result: produces the error as you provided.
Test: Invoke-WebRequest -Uri “https://servername/sites/sitename?amsiscantest:x5opap4pzx54p7cc7$eicar-standard-antivirus-test-fileh+h*” -Method GET (with URL updated accordingly)
Result: produces the 400 Bad request error
But… testing in the browser with the exact same URL as above (the one that produced the error), the page is rendering (i.e. no error is being displayed).
So it seems there’s an inconsistency between what Invoke-WebRequest produces versus what the browser produces. Is there something misconfigured within our environment?
Permalink
This is strange.
I would suggest to use Fiddler or a similar tool to compare the actual request Url being sent to the server from PowerShell and your browser.
There needs to be a difference as this is the only relevant criteria here.
Cheers,
Stefan
Permalink
From what I can tell, the test string from Microsoft’s documentation seems to be wrong. The PowerShell command works, because the string is given in double quotes and $eicar is therefore interpreted as variable. As $eicar is usually uninitialized, this gets expanded to empty string, effectively removing that part from the string. The correct test URL therefore excludes $eicar:
Invoke-WebRequest -Uri “https://servername/sites/sitename?amsiscantest:x5opap4pzx54p7cc7$eicar-standard-antivirus-test-fileh+h*” -Method GET
which gives the same result as the documented command
Invoke-WebRequest -Uri “https://servername/sites/sitename?amsiscantest:x5opap4pzx54p7cc7-standard-antivirus-test-fileh+h*” -Method GET
in a fresh PowerShell session. The test string given by Microsoft also doesn’t work in single quotes.
To test in the browser, navigate to “https://servername/sites/sitename?amsiscantest:x5opap4pzx54p7cc7$eicar-standard-antivirus-test-fileh+h*”.
Permalink
Thanks Kevin – Great finding!
Can you confirm that the request to the Url without $eicar works in the browser and is blocked with 400 Bad Request?
Cheers,
Stefan
Permalink
Hi Stefan,
unfortunately I mixed up the URLs in my original reply, but the explanation is still correct – $eicar should NOT be part of the test string/url. Just to clear it up again, the correct URL without $eicar is:
https://servername/sites/sitename?amsiscantest:x5opap4pzx54p7cc7-standard-antivirus-test-fileh+h*
Yes, I tested it on both our production and test systems using my browser and also PowerShell. The test via HTTP header also only works when omitting $eicar.
Permalink
Thanks Kevin for the confirmation.
I have updated the Url in the blog post above.
Cheers,
Stefan
Permalink
Thank you Stefan for this new Post.
As explained on the Previous page dedicated to the patching process. We don’t have the same behaviour between Powershell and Edge.
Locally on the sever and remotely from my desktop i can execute an invoke web request on powershell. I got the 400 error + the defender message.
But when testing from Edge with the command remotely: https://servername/sites/sitename?amsiscantest:x5opap4pzx54p7cc7$eicar-standard-antivirus-test-fileh+h* (modified with my own url). I don’t have any error message in Edge and on defender. Same behaviour as a server without the fix.
We can reproduce this situation with SE and 2019 (patch with KB5002768 for SE and KB5002753 KB5002754 for 2019)
Edge is not giving any message and Powershell is clearly blocking + message on defender.
Regards,
Matthew
Regards,
Matthew
Permalink
yes, i’m seeing the same thing; powershell throws an error (as expected) but the browser (using chrome) is rendering the page without issue.
Permalink
I would suggest to use Fiddler or a similar tool to compare the actual request Url being sent to the server from PowerShell and your browser.
There needs to be a difference as this is the only relevant criteria here.
Permalink
interestingly, once i opened the browser’s dev tools and refreshed, i received the 400 error. this was true with both chrome and edge.
off the top of my head, perhaps previously the browser just returned what it had cached?
Permalink
Strange i don’t have the 400 error in Chrome and Edge Dev toolbar. We did the test locally and remotely.
As Explained with powershell the request is blocked.
Permalink
Thanks Stefan. How about the machine key? In SE it shows up as a timer job “job-config-machine-key-rotation”, will that be enough to run this timer job to update the key?
For SP 2019, I have the script below, do I have to run this on each machine or per farm? also is there any easy way like SE to change the machine key in SP2019?
# Generate new keys$validationKey = Generate-MachineKey
$decryptionKey = Generate-MachineKey
# Update or insert the machineKey element
[xml]$xml = Get-Content $webConfigPath
$machineKeyNode = $xml.configuration.'system.web'.machineKey
if ($machineKeyNode) {
$machineKeyNode.SetAttribute("validationKey", $validationKey)
$machineKeyNode.SetAttribute("decryptionKey", $decryptionKey)
$machineKeyNode.SetAttribute("validation", "SHA1")
$machineKeyNode.SetAttribute("decryption", "AES")
} else {
$machineKeyElement = $xml.CreateElement("machineKey")
$machineKeyElement.SetAttribute("validationKey", $validationKey)
$machineKeyElement.SetAttribute("decryptionKey", $decryptionKey)
$machineKeyElement.SetAttribute("validation", "SHA1")
$machineKeyElement.SetAttribute("decryption", "AES")
$xml.configuration.'system.web'.AppendChild($machineKeyElement) | Out-Null
}
$xml.Save($webConfigPath)
Write-Host "Rotated machine keys for $($site.Name). Backup: $backupPath"
}
Restart IIS to apply changes
iisreset
Write-Host “Machine key rotation complete. All SharePoint web applications have new keys.”
Permalink
We do not even see that Job at all – is it possible to build it manually, if it’s not listed under SharePoint Job Definitions?
Permalink
This post is about AMSI and not about the key rotation. Best would be to post such question in the other blog post.
Permalink
Hello Stefan,
After executing “AMSI Test Sample” or “Invoke-WebRequest” defender automatically isolated the Front-End server that processed the request.
This response appears quite strict, especially considering that these test commands do not require administrator privileges in PowerShell, meaning anyone on the network could potentially trigger this. Just a few such web requests could isolate the entire Production farm.
Does Microsoft provide any recommended Defender settings related to AMSI?
Thank you.
Permalink
Hi MK,
this is a defender related question which I don’t have information on.
Please open a ticket with Microsoft support by choosing Microsoft Defender as the relevant product to get clarification.
Cheers,
Stefan
Permalink
Thanks for sharing information regarding AMSI, but for us it looks different at all:
I get “200 OK” in Browser for this Request: https://webappname/sites/sitename?amsiscantest:x5opap4pzx54p7cc7-standard-antivirus-test-fileh+h*
while I get “Invoke-WebRequest : 401 UNAUTHORIZED” for Invoke-WebRequest -Uri “https://webappname/sites/sitename?amsiscantest:x5opap4pzx54p7cc7-standard-antivirus-test-fileh+h*” -Method GET
Also in WebApp-Features it shows, it’s on, but in fact it is not functioning in a reliable manner … any way to troubleshoot/fix this properly?
Permalink
Hi Dani,
it seems AMSI is not working properly on this web application.
If you need assistance here I would suggest to open a ticket with Microsoft Support.
Cheers,
Stefan
Permalink
Our SP 2019 farms behave exactly as described in this blog, but we’re encountering exactly the same issue as yours on all our SE farms.
Permalink
Hi Dani, for your PowerShell test, try $cred=get-credential first, then do Invoke-WebRequest : 401 UNAUTHORIZED” for Invoke-WebRequest -Uri “https://webappname/sites/sitename?amsiscantest:x5opap4pzx54p7cc7-standard-antivirus-test-fileh+h*” -Method GET -credential $cred
Permalink
Thank you for the additional clarity in this post.
Permalink
Hi Stefan,
I have checked the 16/TEMPLATE/LAYOUTS folder and I cannot see any of the listed .aspx files from the previous post however there are a large number of javascript files that were created on the 20th and I see the file AddGaller.xap file which was created on the 21st? Is this to be expected?
Cheers
Rob
Permalink
That should be AddGallery.xap
Permalink
Hi Robert,
this question would have been better added to the other blog post.
But yes – these are files created by the security fix you installed.
They are expected.
Cheers,
Stefan
Permalink
What is the other blog post? I have questions about these files that were created at a suspicious time before we applied the security fix.
Permalink
Hi Ruben,
this one:
https://blog.stefan-gossner.com/2025/07/21/important-active-attacks-targeting-on-premises-sharepoint-server-customers/
Cheers,
Stefan
Permalink
The file creation and modified date of the files installed with the fix reflects the time they were created by Microsoft – not the installation time.
Permalink
I see a bunch of JS files with a time stamp of 7-20-25 1:41AM. That was Sunday morning. We did not apply the security patch until Monday mid morning. Should we be seeing this?
Permalink
Hi Ruben,
the creation and modified date reflects the date/time when they were created by Microsoft. Not the installation time on your machine.
Cheers,
Stefan
Permalink
Hi Stefan,
I have patched our SP 2016 server and rotated our ASP.NET keys, but we continue to see the AMSI blocking threats today. Are you saying this is expected behaviour even after the patch?
We had AMSI enabled all along and we weren’t getting these “blocked by AMSI” alerts before the exploit.
Cheers
Ruben
Permalink
Yes exactly. This is expected if the servers are currently under attack.
But AMSI together with your AV solution deflects the malicious requests.
Permalink
Dear Stefan,
Many thanks for your work — I’ve been following you for a long time.
I just have one question. There are so many comments and discussions everywhere; could you please create a single post that clearly lists what is required? Something like “Massive Attack: What You Need” — and then simply update that one post as needed.
There’s a lot of information out there, and many of us are feeling overwhelmed.
Thanks again,
Sylvain
Permalink
Hi Sylvain,
let me think about how to achieve this in a way that it benefits everyone considering the fact that different customers have different needs and are running into different type of problems.
Cheers,
Stefan
Permalink
After applying patches, do we still need to install Defender and integrate it with AMSI?
On our server we have AMSI enabled but we are using Symantec instead of Defender.
Permalink
Hi Frank,
if the patches are applied AMSI is recommended but not required.
In addition it does not matter if Defender is being used or a different AMSI enabled AV solution as long as it has the necessary signatures to identify the malicious requests.
Cheers,
Stefan
Permalink
With SP 2016 there seem to be limitations with AMSI.
Having issues enabling body scanning.
The command referenced here https://learn.microsoft.com/en-us/sharepoint/security-for-sharepoint-server/configure-amsi-integration throws an error:
” The property ‘AMSIBodyScanMode’ cannot be found on this object. Verify that the property exists and can be set.”
Is there any MS Documentaion.
ChatGPT/Co-pilot talks about limited functionality.
This error typically occurs in PowerShell when you’re trying to access or set a property that doesn’t exist on the object you’re working with. In this case, ‘AMSIBodyScanMode’ is a property introduced in SharePoint Server Subscription Edition (SPSE) Version 25H1 for configuring AMSI (Antimalware Scan Interface) body scanning.
Here’s what might be going wrong:
🛠 Possible Causes
Thanks in advance,
Lee
Permalink
Hi Lee, that is correct.
Body scanning is only available in SPSE.
In older SharePoint versions only Url and Headers can be scanned.
Cheers,
Stefan
Permalink
Hi Stefan,
I have both SPSE and 2016 farms and same AV (third party vendor) version on all farms. July vulnerability patch applied on all farms.
AMSI test is working fine with SPSE. AV is detecting and logging the test.
AMSI test is not doing anything on SP2016. Disabling/Enabling the feature does not change anything.
Any guidance on how to make AMSI work in SP2016.
Permalink
Hi Gabriel,
AMSI is an operating system feature available on Windows Server 2016 and later.
If you are running SharePoint 2016 on Windows Server 2012 R2 or earlier, AMSI cannot be used, as the operating system does not support it.
SharePoint communicates only with the OS-level AMSI functionality—not directly with the installed antivirus (AV) solution.
This means it is important to verify that the OS/AMSI integration is functioning correctly.
Unfortunately, each AV solution has a different method for testing this.
Please contact your AV vendor to find out how to verify that the OS/AMSI integration is working.
Once this integration is functioning properly, the SharePoint AMSI functionality should also work—provided the SharePoint AMSI feature is activated.
Common problems on the SharePoint side are discussed in this article:
https://blog.stefan-gossner.com/2023/10/17/trending-issue-module-sprequestfiltermodule-could-not-be-found-after-september-october-2023-cu/
Cheers,
Stefan
Permalink
We are running SharePoint 2016 on Windows Server 2016. AMSI is activated on all web applications. PowerShell and browser tests are not yielding any results as if the feature is not activated. Same AV and same tests are working fine for SP SE on Windows Server 2022.
I will check with the AV vendor again and report back.
Thanks.
Permalink
Hi Stefan,
Can Cortex XDR be integrated with SharePoint AMSI?
Thanks in advance!
Vijay
Permalink
Hi Vijay,
AMSI is an operating system feature. SharePoint only leverages it by passing information to the operating system AMSI feature.
So the correct question would be if Cortex XDR supports AMSI and can be integrated with your operating system.
Please context the vendor of your AV solution directly to get insights.
Cheers,
Stefan
Permalink
Is it still a good idea to exclude C:\Program Files\Common Files\microsoft shared\Web Server Extensions\16 from the antivirus Defender scanning?
That attack wanted to post a file on the folder C:\Program Files\Common Files\microsoft shared\Web Server Extensions\16\TEMPLATE\LAYOUTS
I prefer then to include all the folder C:\Program Files\Common Files\microsoft shared\Web Server Extensions in the Defender scan
Permalink
Hi Fabrice,
here is a list of all folders that should be excluded from anti virus scanning:
https://support.microsoft.com/en-us/office/certain-folders-may-have-to-be-excluded-from-antivirus-scanning-when-you-use-file-level-antivirus-software-in-sharepoint-01cbc532-a24e-4bba-8d67-0b1ed733a3d9
We have received support cases – mostly when trying to install a SharePoint fix – because files that were attempted to open for write were in use by AV which raised exceptions.
Cheers,
Stefan
Permalink
There’s some important AMSI-related news, see extract below.
Source: securityweek.com article dated July 22, 2025:
https://www.securityweek.com/microsoft-says-chinese-apts-exploited-toolshell-zero-days-weeks-before-patch/
Extract:
“[WatchTowr security firm] reported that it had found a way to exploit CVE-2025-53770 in a way that bypasses Antimalware Scan Interface (AMSI), the mitigation recommended by Microsoft to customers who cannot immediately apply the patches. This was also the mitigation recommended before patches were released for CVE-2025-53770 and CVE-2025-53771.
“AMSI was never a silver bullet, and this outcome was inevitable. But we’re concerned to hear that some organizations are choosing to ‘enable AMSI’ instead of patching. This is a very bad idea,” said WatchTowr CEO Benjamin Harris.
“Now that exploitation has been linked to nation-state actors, it would be naive to think they could leverage a SharePoint zero-day but somehow not bypass AMSI. Organizations must patch. Should go without saying – all the public PoCs will trigger AMSI, and mislead organizations into believing the mitigations are comprehensive/the host is no longer vulnerable. This would be incorrect,” Harris added.
More than 9,000 SharePoint instances were exposed to the web when news of the attacks broke, and hundreds of them were targeted in the first days.”
Permalink
SPSE, after patching to july25 + security patch
the ui for AMSI seems missing…. we can only enable/disable the feature
we patched directly from no23 -> july25 (which should contain all cumulatives in between…?)
is there any way to fetch the AMSI functionality from here ?
Permalink
Hi Johannes,
the UI is part of the Early Release Ring. I assume you are running Standard Release.
See here for details:
https://blog.stefan-gossner.com/2025/03/11/feature-update-25h1-for-sharepoint-server-subscription-edition-has-been-released-today/
Cheers,
Stefan
Permalink
Hi Stefan, do you have any tips of what could be on FE’s throwing http 500 errors after the CVE patch? Can access the site collections if host file is pointing to app layer straight. Thank you!
Permalink
Hi Giovanna,
that can be a large number of things. 500 Server error just tells us that something went wrong.
But the ULS log should give you more details.
Cheers,
Stefan
Permalink
We are on SharePoint 2019. I am being asked to verify that the AMSI Body Scan Mode is Balanced, but none of the commands are working. It appears that setting the Body Scan Mode is something only available on the SharePoint Server Subscription Edition. Is that correct? Is there anyway to tell what sort of scan mode we are using with SharePoint 2019?
Permalink
Hi Stuart,
SharePoint Server 2016 and 2019 do not support Body Scan Mode. This is a feature introduced in SharePoint Server Subscription Edition 25H1 Feature update.
SharePoint Server 2016 and 2019 only support scanning of Url and Http Headers and there is only an option to switch it on or off. No further configuration is available in these SharePoint versions.
Cheers,
Stefan
Permalink
After applying the patch we started having workflow issues such as “failed to start”. Is anyone experiencing this issue?
Permalink
Hi Warren,
in the last 12 month several security fixes which restricted Workflow operations have been released.
What was the last CU you installed before the security fix? To allow me to provide some ideas.
Cheers,
Stefan
Permalink
I don’t know for sure but I think it was the September 2024 CU.
Permalink
Hi Warren,
you can check it in the Central Administration in the Patch Status page.
Would be important if it was a patch older than September 2024 or not as September 2024 CU introduced the most critical and painful changes to Workflows.
Cheers,
Stefan
Permalink
Hey Stefan, it appears the last prior patch (CU) was July 2024.
KB5002289
KB5002305
KB5002136
Did the July 2025 security patch KB5002759 and KB5002760 Microsoft released include prior CU’s?
Thank you.
Permalink
Hi Warren,
yes – the July 2025 security patch is a CU and it includes all fixes released since RTM.
So you got all the nice problems now which customers experienced in the last 12 months.
Please have a look at this article:
https://blog.stefan-gossner.com/2024/09/13/trending-issue-problems-with-workflows-after-applying-september-2024-cu-for-sharepoint-2016-2019-se/
Cheers,
Stefan
Permalink
Since we don’t use Workflow Manager but instead use out of the box workflow I wonder if the patch removed the old components. Because I see messages like “Can’t find WorkflowServiceProxy or its service application proxy type name is null”
Permalink
Hi Warren,
I assume you mean you are using SP2010 workflows and not SP2013 workflows?
Because all SP2013 workflows require workflow manager.
WorkflowServiceProxy is also a component for SP2013 workflows and not involved with SP2010 workflows.
Cheers,
Stefan
Permalink
That is correct they are SP2010 Workflows. thanks
Permalink
Hi Stefan,
we updated our SP SE from May CU 2025 with the July 2025 Security Patch. We tried to make sure, that AMSI is running correctly. Real time protection is enabled.
AMSI test on operating system level works as described.
GUI elements for body settings is missing because of Standard Release Ring. AMSI is enabled in Full Mode via Powershell for the web application.
But testing AMSI in SharePoint delivers a 200 OK and no AMSI message.
Seems like AMSI integration in Sharepoint is broken. Any hints how to analyze and fix it?
Cheers
Toby
Permalink
Hi Toby,
how exactly did you test?
Cheers,
Stefan
Permalink
We’ve applied the patch and set the new machine key for our SharePoint 2016 environment. But we’re now getting the issue with secure store service application and when clicking the service application, we’re getting the error as
“Cannot complete this action as the Secure Store Shared Service is not responding. Please contact your administrator”
and when clicking administrators for the service application we’re getting error as
“The trust relationship between the primary and the trusted domain failed”.
Ultimately getting the error in code when consuming the service application as “Secure store service did not perform the operation”
This started after the patch and machine key rotation in our non-prod environments. we tried all the options suggested on the internet like starting the services, clear cache and app pool recycle and IIS reset. nothing worked. We created a new secure store application and it’s all working as expected. But we can’t do this in our production environment. Any setting or check on the layout folder respective to the service application can that holds the old machine key, that can be corrected to bring this service application back to functional?
Permalink
Hi Raja,
this error message is not related to SharePoint or a SharePoint patch: “The trust relationship between the primary and the trusted domain failed”.
This is a problem with the AD integration of the server machine on Windows level.
On the other hand it is not necessarily responsible for the problem with the secure store service – but it can be a side effect if service account impersonation fails due to this issue.
If you search for the error message in your preferred search engine you will find a large number of similar reports including possible actions to resolve the issue.
Cheers,
Stefan
Permalink
Hi. Sorry if this is not the correct post to ask this question?
We recently moved to SP Subscription edition and AMSI seems to be working well with SharePoint integration. I checked it with both powershell and browser based tests mentioned above.
However, if I try to upload a eicar.txt file or something similar which is used to test for malicious files on a SharePoint document library, it does not give me any errors. I am able to upload and download it successfully.
Does MS Defender and AMSI not work with real time upload and download of files like Symantec for SharePoint? I was under the impression that we no longer need a third party AV service provider for SharePoint at all.
Note: I have already checked the full body scan mode is on with value 2 for the web app where I tested uploading the files.
Would love to get some info on this?
Permalink
Hi Sangeet, this will require to enable full body scanning. The default is to check only url and http headers for malicious content.
Full body scanning is only available with early release configuration.
Cheers,
Stefan