Background: Microsoft Advisories 

On July 8, 2025, as part of its July Patch Tuesday rollout, Microsoft issued two CVEs’ CVE-2025-49704 and CVE-2025-49706 that affected SharePoint 2016, SharePoint 2019, and the Subscription Version of SharePoint which is designed to be evergreen meaning it receives continuous updates rather than requiring upgrades every few years. Microsoft also issued an advisory notifying the end-of-life of the SharePoint 2013 server. The referenced CVEs were targeted to fix a Remote Code Execution flaw (CVE-2025-49704) and an Authentication Bypass flaw (CVE-2025-49706) in the affected versions of SharePoint.  

On July 19, 2025, Microsoft issued two additional CVEs that fixed  a possible bypass for the above-referenced CVE. These new CVEs included CVE-2025-53770 (that fixed a bypass to CVE 2025-49704) and CVE-2025-53771 (that fixed a bypass to CVE-2025-49706).  

Are cloud versions of SharePoint impacted?

Microsoft is diligent about patching vulnerabilities and monitoring their apps for malicious activities. As a result, while the cloud versions may have been impacted at some point, they may not be impacted over time. 

Background: CISA’s Advisories

On July 22nd, 2025, CISA issued two Known Exploited Vulnerability (KEV) Advisories for CVEs’ CVE-2025-49704 and CVE-2025-49706. CISA is yet to issue KEV advisories for the flaws exposed by CVEs’ CVE-2025-53770 and CVE-2025-53771. 

In these advisories, CISA reminded all federal agencies via its Binding Operational Directive (BOD) 22-01 charter to apply patches for all CVE’s.  

Vulnerability Mitigation: Microsoft’s Recommendations 

The National Vulnerability Database (NVD) page for CVE-2025-53770 (a Remote Code Execution flaw) enumerates the Microsoft Advisory for the CVE. This Microsoft Advisory recommends that its customers should: 

1. Use supported versions of on-premises SharePoint Server 
2. Apply the latest security updates linked above. 
3. Deploy Microsoft Defender for Endpoint protection, or equivalent threat solutions 
4. Ensure the Antimalware Scan Interface (AMSI) is turned on and configured correctly, with an appropriate antivirus solution such as Defender Antivirus 
5. Rotate SharePoint Server ASP.NET machine keys 

Microsoft’s advisory also recommends using an EDR product such as Microsoft Defender to mitigate these latest vulnerabilities using indicators of compromise.  

As we all know, sophisticated Threat Actors have used legitimate OS (aka LOLBIN) executables (aka LOLBIN) such as PowerShell, to execute their malicious actions, and therefore, they can easily float under the radar of EDR products, such as Defender. The Indicators of Compromise (IOCs) for these two CVEs include a series of IP addresses and a set of four checksums as referenced here. Further examination of File Hash-based IOC details from VirusTotal shows:

1. Hash:10e01ce96889c7b4366cfa1e7d99759e4e2b6e5dfe378087d9e836b7278abfb6 

File name: machinekey.aspx 

2. Hash: 0548fad567c22ccf19031671f7ec1f53b735abf93dc11245bc9ea4dfd463fe40 

File name: osvmhdfl.dll. The attackers’ DLL payloads (osvmhdfl.dll, bjcloiyq.dll) are .NET assemblies compiled as recently as July 2025, purpose-built for SharePoint environments. Their primary function is to access, via reflection, the MachineKeySection of the ASP.NET configuration—bypassing standard application controls. 

Even a small change in the exploit code will render the file hash useless. The accompanying demo shows that the White Hat hacker did not use either file, which is why the exploit used in this demo was able to blindside any EDR. The White Hat hacker did not leverage any DLL. The entire attack was constructed using HTTP payloads. 

It is important to note that a Threat Actor is not compelled to use the blacklisted IP addresses stated in the IOC. Net result, an EDR that uses IOCs such as the ones described above will be easily blindsided. 

Kill Chain of Tool Shell:The threat actor uses anonymous credentials to access a URL and, using a POST HTTP Request, drops a malicious View State payload. View State is a special ASP.NET artifact that contains serialized data that can be used across multiple POST requests. This serialized object is protected using a Validation key and a Decryption key. If a threat actor can gain knowledge of these two machine keys, they can craft a malicious serialized object, encrypt it using the said machine keys, and then send a malicious Post Message. This leverages the previously delivered malicious View State object. The victim workload will happily execute the said serialized object since the validation and decryption keys check out. With this, the Threat Actor can execute any arbitrary code on the vulnerable workload, including stealing confidential content stored in SharePoint. The precise kill chain for this vulnerability is as shown below:

It is important to note that instead of using CVE-2025-53770 in step 3 above, another Remote Code Execution vulnerability disclosed in Microsoft’s August security update, CVE-2025-49712 (CVSS score: 8.8), which fixes yet another ViewState serialized data vulnerability, could have been used with equally devastating impact. 

As can be seen in the accompanying demo, several of Virsec’s Protection Engines shown in the kill chain, stopped the attack – well before the threat actor could even install the web shell and exfiltrate the machine keys from the victim SharePoint Server. All this was done without leveraging any ephemeral Indicator of Compromise referenced above. Instead, Virsec’s Protection Engines leveraged its patent-protected runtime zero-trust lockdown technology to stop untrusted code supplied by a Threat Actor. As a result, OTTOGUARD.AI offers Workload Patchless Mitigation, an autonomous remediation solution to vulnerabilities such as the troublesome Tool Shell vulnerability. 

What is Workload Patchless Mitigation 

An autonomous and fully automated remediation solution that provides vulnerability mitigation should deliver the following characteristics: 

1. Theoretically a patch stops exploitation of the underlying vulnerability thereby delivering Zero Dwell time exploit protection and MTTR (Meant Time to Remediate) equal to ZERO. It stands to reason that a Patchless Mitigation solution must be as effective as a patch in that it must deliver Zero Dwell time.  
2. A Vulnerability Mitigation solution cannot hide behind a reachability argument. A determined Threat Actor can phish insiders and reach any part of the enterprise’s infrastructure 
3. A Vulnerability Mitigation solution cannot hide behind an exploitability argument. Believing that Threat Actors cannot exploit vulnerability undermines the ability of Threat Actors and therefore akin to sticking one’s head in sand. Please watch the demo accompanying this blog to see how a White Hat hacker created an exploit even when CISA has not labelled the latest two vulnerabilities as KEVs. 
4. A Vulnerability Mitigation solution must not use Indicators of Compromise (IOC) such as IP addresses, file names and hashes, byte patterns in network traffic, as well as any ephemeral Threat Intelligence that a Threat Actor can manipulate. 
5. A Vulnerability Mitigation must not force the user into making poor choices in the name of prioritization. Instead, it should be able to scale no matter how many vulnerabilities have built up over time. Given the volume, prioritization may appear to be the way to go, but an effective Vulnerability Mitigation solution should not force the enterprise into making compromises. Threat Actors are creatures of opportunity – when one presents itself, they will take it.  

Vulnerability Mitigation Strategies: Why OTTOGUARD.AI?

Unlike other solutions that promise improved remediation timelines that is measured at best in days, Virsec’s OTTOGUARD.AI offers vulnerability mitigation: 

• Even when the vulnerability is a zero-day vulnerability. In such a scenario, the vulnerability is known to a few privileged people, which excludes the targeted app’s vendor. 
• Even when a patch from the vulnerable app’s vendor is not yet available. Creating a patch involves root cause analysis, coding, testing, and developing distribution procedures.  
• Even when a patch is available but has not been deployed. There can be many reasons, from simple ones such as lack of awareness or non-availability of testing/deployment resources to complex reasons such as loss caused by business discontinuity or any other reason in between.  
• Even when a patch prescribed by the app’s ISV is broken and cannot protect the vulnerable app. Recall that the Log4J vulnerability took four iterations of patching before the library was finally patched adequately.  
• Even when the app has reached the end-of-life stage and no further patches are forthcoming. Most software will reach end-of-life in 5 to 7 years. Changing apps that deliver is not easy. We often see apps that are 20 to 30 years old and still going strong. 
• Even when no Indicators of Compromise are available or the list is not complete 
• Even if the Threat Actor changes their exploit code. No two pieces of code written by different people will have the same file hash. Even a trivial difference in an algorithm, such as an additional variable that does nothing, will result in a substantial change in the hash of the code, and any cyber protection that relies on the published Indicator of Compromise will be readily blindsided. 
• Even when the accelerated pace of AI-assisted code generation increases the risk of reintroducing old vulnerabilities or creating new ones, given a tendency for models to choose insecure coding methods when given a choice. 

Conclusion

Only OTTOGUARD.AI offers a Workload Patchless Mitigation solution that can achieve a significant relief (over 90% reduction from critical and high CVE’s) from the risk to enterprise assets and confidential information from the snowball of vulnerabilities that keeps gathering momentum. 

Your business can unlock these benefits without: 

• Taking production servers offline 
• Having to test the patches 
• The risk of breaking the functionality of the app, and 
• Running the risk of the patch not even working adequately 
• Panic when a new RCE vulnerability is announced, even before it becomes a CVE

Protect your assets. Think patchless. 

FAQs