This is Part 2 of our series on ToolShell, following up on our previous interview with Erik Montcalm, Senior VP of Security Services and Technology at SecureOps. ToolShell is a SharePoint vulnerability that gives attackers persistent access to compromised servers.
In this extended Q&A, Patrick Ethier, a cybersecurity veteran with extensive experience guiding enterprise security strategy and operations, and the Chief Technology Officer at SecureOps, explains how attackers maintain stealth, the challenges of remediation, and why cloud adoption and proper vendor management are critical to a healthy security posture. Patrick also identifies the types of organizations most at risk, illustrating the challenges of on-premise SharePoint management and the consequences of legacy and customized deployments. His commentary offers both a stark warning and practical guidance for CISOs to mitigate risk.
Patrick Ethier: Yeah, this is a combination, or chain, of plain-out security issues. It is caused by the fact that SharePoint is a collaboration platform/CMS and the OnPrem version typically doesn’t separate end-user usage and administrator usage. Administrators see admin panels, regular users see their content, but underneath, it’s usually configured as one big monolithic application from a privileges perspective.
The chain is complicated but using common techniques. In the first part of the chain, they figured out how to bypass authentication by simply swapping out a standard HTTP header on a valid request. This is clearly a variant on a bug that Microsoft attempted to patch in the past. Then they use a serialization feature in SharePoint’s ToolPane widget in order to trick SharePoint into executing remote code (RCE). In many cases, this involves installing a remote shell or backdoor. From there, the world is your oyster. This chain would then be used to steal keys from the registry to forge further credentials. This enables the attacker to continue accessing the system using legitimate channels and remain unnoticed.
Think of it like leaving your house for three months and someone finds a way to break in. They move around quietly at first. Then they make friends with the neighbors and suddenly it looks like they’ve always been part of the neighborhood. They can clone keys, install secret doors, and keep hanging out while they look like they belong there. This goes very quickly from bypassing authentication credentials to owning the whole place. Once that happens, the only real fix is to bulldoze the house and start over. There’s no clean way to just look inside and remove them completely.
PE: Once the system is owned, this becomes very much a standard security problem. It’ll depend on the access level of service accounts, on the network and a bunch of other factors.
If your servers are isolated and locked down, it is analogous to the house being in the middle of a forest. Interactions with neighbors are limited. They can’t influence neighbors easily and essentially hit a wall.
But if service account access isn’t restricted or the network is messy, outdated, or poorly segmented, attackers can move around quietly and extend their reach. They’re careful not to make noise, because every interaction increases the chance you’ll notice.
Their stealth at that point isn’t just hiding in memory. If you’re doing strategic levels of logging, things start showing up in logs; how they manipulate credentials, how they interact with the system over time, upload files, download files, etc.
Patrick: ToolShell is just the brand describing this particular chain of attacks that typically results in remote code being executed and a remote shell is installed. Remote shell attacks have a few flavors. Some are in-memory, one-shot attacks that perform a few steps and then get flushed out of memory. These are quick and almost invisible with a limited footprint. Other flavors are more active and upload files or backdoors that persist and modify the system continuously.
The serialization CVE in the SharePoint tool pane is key. It lets attackers inject code in multiple ways. As mentioned above, depending on the attacker’s approach, you may not notice anything, or they will attempt some more sophisticated steps in order to achieve full persistent access. The CVE description seems to indicate a bunch of IoCs (indicators of compromise) for specific filenames to look for. This is great going forward, but in a zero-day situation where you don’t know what the filenames could be, simple HIDS configuration won’t necessarily mitigate this. That’s why having a robust EDR that watches memory, monitors new files, and logs suspicious activity is critical.
Patrick: These days, you can rely on EDR and logging to provide a good portion of the heavy lift for protecting against these things. It’s not infallible, but when using both in tandem, you can watch for anomalies in memory execution, new or modified files, unusual traffic through proxies, probes out to other systems that are out of the ordinary, unusual byte sizes in sessions, etc.
Even if you can’t detect everything immediately, logs let you correlate activity to potentially identify compromised systems. Using a WAF (web application firewall) can also help out greatly. For example, the first step in the ToolShell attack chain exploits referrer headers which can easily be locked down and sanitized by a WAF. The WAF can also remove any other header that isn’t required by the platform.
Once an advisory comes out, you can quickly implement emergency rules with both EDR and WAF to block further exploitation until a patch is made available. You can also look for IoCs in EDR, WAF and system logs which can help provide some level of assurance or indication that a system was indeed compromised to avoid bulldozing the house as we were referring to previously.
Patrick: No. You reduce risk, but never eliminate it. Defense-in-depth—EDR, XDR, segmentation, using a WAF, monitoring, change control, training —is the best way to stay ahead. Compliance alone doesn’t protect you, but it shows you’re making a conscious effort and usually has a big continuous improvement component to it. Ultimately, it’s about intent and effort. If something gets through, you’re better prepared to respond.
Patrick: That’s tricky. SharePoint lets users add scripts and widgets, often without proper change control. Over time, you may not know if something malicious was added months ago. Restoring from backups without auditing can reintroduce those scripts. You have to differentiate legitimate user activity from potential threats. If you leave it entirely to end-users, it becomes very hard to know what’s safe.
Patrick: Culture matters. Many companies adopt an “if it works, don’t fix it” mindset. They install SharePoint on-prem and never maintain it properly. Limited IT resources, no dedicated security staff, and lack of formal change management make persistence easy. This also applies to third-party vendors. If they don’t patch or audit properly, your exposure multiplies.
Patrick: Everybody that uses OnPrem servers is at risk to various degrees. But certain circumstances make it a lot more likely that something like ToolShell will be difficult to recover from.
The first group is companies running SharePoint on-prem with limited IT resources. They can’t maintain architecture, patching, or monitoring properly, which leaves them vulnerable. This group should consider moving to cloud-based services or reduce the public exposure of their SharePoint services in any way possible.
The second is organizations that deployed SharePoint on-prem due to compliance requirements, like GDPR or HIPAA. They might lock down the server physically, but if it’s exposed to the internet for convenience, that’s a risk. In this case, careful review of the architecture and associated security controls should be reviewed using ToolShell as a table-top premise.
Third, companies using third-party products built on SharePoint. If third party vendors don’t formally address patching, monitoring, and disclosure, you inherit that risk. Paying attention to clauses in the service contract that ensure the vendor follows best practices that have been reviewed by a standard such as SOC2 or ISO27000 is important.
All three should reassess the value of an on-prem SharePoint deployment. The risks and long term costs of a cloud migration is often safer and cheaper, because Microsoft handles the heavy lifting. They continuously maintain the architecture, perform patching, and conduct monitoring at scale, which otherwise these organizations have to do themselves.
Patrick: It’s mostly a procurement and contract issue. Your RFPs and contracts should require vendors to maintain updates, follow compliance frameworks, and disclose vulnerabilities. Ask them directly: “What are you doing about this?” If they’re SOC 2 compliant or ISO 27000 audited, and they have disclosure clauses, you can make informed decisions.
Patrick: Focus on doing things properly. Build auditing, logging, and monitoring into your practices. Maintain clear contracts and disclosure clauses with vendors. Consider cloud migration if on-prem support is weak. Don’t underestimate architecture. Even small missteps, like leaving a server exposed, can be leveraged by attackers.
You won’t catch everything, but structured practices put you in a position to respond effectively.
ToolShell shows that even familiar platforms like SharePoint remain vulnerable. Attackers exploit stealth, memory-based execution, and dormant scripts to persist. Organizations with limited IT resources, strict compliance needs, or reliance on third-party SharePoint solutions are most at risk. Defense-in-depth, auditing, cloud migration, and robust change management are critical. Most importantly, companies should focus on effort and intent—structured practices and vigilance give teams the best chance to manage and recover from incidents.
Moreover, this vulnerability exists only in the on-prem version of the application. By migrating to a cloud deployment, organizations can circumvent the vulnerability altogether.
Contact SecureOps today to discuss how best to protect your environment from ToolShell and other vulnerabilities.