How to Hunt for In-Memory Webshells That Leave No File on Disk

Most incident-response playbooks assume the attacker leaves a file behind: a web-accessible script, a dropped binary, a scheduled task pointing at a payload on disk. That assumption fails against in-memory webshells, where the malicious code lives inside a running process and never becomes a file your scanners can see. The September 2026 exploitation of the SharePoint flaw CVE-2026-65660 delivered exactly this kind of payload, decrypting and loading an assembly directly in the SharePoint worker process. This guide walks through how to hunt for that class of intrusion when the usual filesystem evidence is not there.

Understand What You Are Looking For

An in-memory webshellIn-Memory Webshell🛡️A backdoor loaded and executed inside a running process without being written to disk as a file. Because no file exists for scanners to detect, it must be hunted through process behavior, memory analysis, and logs rather than file signatures. is code that an attacker gets a legitimate process to load and execute without persisting it as a file the process would normally read from disk. In the SharePoint case, a deserializationDeserialization🛡️The process of converting stored or transmitted data back into an object. Insecure deserialization can allow attackers to execute code by manipulating serialized data. gadget chainGadget Chain🛡️A sequence of objects assembled from classes already present in an application and its libraries, arranged so that reconstructing them during deserialization performs an unintended action such as running a command or loading code. Finding one is the core of deserialization exploitation. called Assembly.Load on decrypted bytes, giving the attacker a running backdoor inside the worker process. There may be a small, transient footprint. In the CVE-2026-65660 attempts, exploitation was reported to expose a backdoor at a virtual path, /_layouts/15/sphealth.aspx, even though the payload itself was not written to disk. But you cannot rely on a file being there. Your evidence is going to come from four places: web-server logs, process behavior, memory, and downstream network activity. The concept underneath this attack is covered in how .NET deserialization turns attacker data into code execution; here we focus on finding it after the fact.

Step 1: Hunt the Request Logs

The delivery mechanism almost always leaves a trace in the web-server or application logs, because the exploitExploit🛡️Code or technique that takes advantage of a vulnerability to cause unintended behavior, such as gaining unauthorized access. has to arrive as a request. Start there.

• **Search for the exploit's entry points.** For the SharePoint chain, that meant POST requests to pages such as AddGallery.aspx and designgallery.aspx carrying DisplayMode=Edit. For any given vulnerabilityVulnerability🛡️A weakness in software, hardware, or processes that can be exploited by attackers to gain unauthorized access or cause harm., identify the vulnerable endpoint from the advisory or research and query for it directly.
• **Flag requests that should not be anonymous.** The pre-authentication variant of this attack sent those POSTs with no authentication cookie or authorization header. A privileged action arriving without any authentication material is a strong signal. This is the same reasoning we apply in how to hunt for forged admin tokens in API gatewayAPI Gateway🛡️A reverse proxy that sits in front of backend services, authenticating clients, enforcing rate limits and policy, and routing requests. Because it registers every client and stores every backend definition, an administrator on the gateway can reach credentials for everything it fronts. logs: look for the access that should have been impossible.
• **Look for oversized or paired request bodies.** The observed payload came in two stages, a small first body followed by a much larger one, repeated across several paths from one source in a tight window. Unusual body sizes and closely spaced bursts from a single address are worth pivoting on.
• **Normalize the paths.** Attackers retried the same pages with repeated directory prefixes to evade naive path matching. Decode and canonicalize URLs before you match, or you will miss variants.

Step 2: Examine Process Behavior

If the chain executed, the host process did something out of character. Web-application worker processes have a narrow, predictable behavior profile, and deviations stand out.

• **Child processes.** A web worker spawning a command shell, a scripting host, or an encoding utility is rarely legitimate. Process-lineage telemetry from an EDR agent is the fastest way to see this.
• **Unexpected outbound connections.** An in-memory loader often reaches out to retrieve a further stage or to signal a controller. Connections from the web process to unfamiliar destinations deserve scrutiny.
• **New assemblies or modules loaded at odd times.** On .NET platforms, module-load events for assemblies with random-looking names, appearing outside a deployment window, are a red flag. The SharePoint loader carried an embedded assembly with a generated name.

Step 3: Capture Memory Before You Reboot

The instinct after finding a compromised server is to reboot or reimage it. For an in-memory implant, that instinct destroys your best evidence. If the process is still running, capture a memory image or a process dump first. Strings and loaded-module analysis of that dump can reveal the loader, decrypted payload fragments, and indicators that never existed on disk. Only after you have preserved memory should you move to containment. This ordering matters enough that CISA's forensic-triage requirement under Binding Operational Directive 26-04, which applies to CVE-2026-65660, effectively mandates it for federal agencies before remediation.

Step 4: Correlate With Known Indicators, Carefully

Threat-intelligence reports will give you specific indicators: source addresses, file hashes for any recovered components, virtual paths like the sphealth.aspx backdoor. Use them, but weight them correctly. A source IP from a single honeypotHoneypot🛡️A decoy system deployed to be attacked so defenders can observe exploitation attempts safely. Honeypot networks give early warning that a vulnerability has moved from theoretical to actively exploited, often before official catalogs like CISA KEV confirm it. capture is useful only for correlating within the observed time window; it will rotate. A hash of a recovered loader is stronger but only catches that exact build. The durable detections are behavioral: the request pattern, the anonymous privileged access, the anomalous child process. Indicators confirm; behavior discovers.

Step 5: Assume Persistence Elsewhere

An attacker who achieved code execution rarely stops at one implant. Once you confirm compromise, widen the investigation. Check for new or modified scheduled tasks, service accounts, and legitimate administrative tools being used in unusual ways, the pattern discussed in how to detect living-off-the-land abuse on network security appliances. Review authentication logs for accounts that may have been created or elevated after the initial access. Rotate credentials that the compromised process could have reached, and treat any secrets it held as exposed.

Building It Into Routine

You cannot hunt in-memory webshells effectively if the telemetry does not exist when you go looking. That means keeping web-server access logs with full request detail, deploying endpoint telemetry that records process lineageProcess Lineage🛡️The parent-child chain of processes on a host, showing which process launched which. Hunting on lineage catches exploitation because compromised services spawn children they never would in normal operation. and module loads on your application servers, and retaining enough history to investigate a burst that happened weeks ago. The SharePoint intrusions became public roughly six weeks after the patch shipped; an organization that only kept two weeks of logs would have nothing to look at. Fileless attacks are not going away, and the servers most likely to face them, internet-facing application platforms, are the ones where this visibility is worth the cost.