What are the signs that a MOVEit-style webshell attack is underway?

Look for IIS worker processes spawning csc.exe, unusual ASPX file creation under the webroot, and temporary directories with random eight-character names. Security teams should also watch for anomalous activity from the file transfer service account and process chains that indicate compiled payloads or unrelated library loads. Hashes alone are not enough for detection.

What the attacker leaves behind in the web tier

A MOVEit-style webshell campaign is usually visible first through web-server behavior, not through a neat signature. The most important clue is abnormal execution from IIS, especially when the worker process starts compiling code, writing unexpected ASPX files, or touching strange temporary folders under the webroot. Those artifacts point to server-side execution, not ordinary file transfer activity.

Another useful way to think about the pattern is that the attacker is trying to convert a web application into an execution surface. That means defenders should look for process creation that does not belong in a file transfer workflow, unexpected library loading, and file changes that appear designed to persist across requests rather than support a normal upload or download.

Process and file indicators that matter most

The strongest indicators are the ones that connect web activity to code execution. An IIS worker process spawning csc.exe is especially important because it suggests on-the-fly compilation, which is not normal behavior for a managed file transfer service. Unusual ASPX creation under the webroot is another major signal, because webshells need a reachable path that the web server can execute.

Temporary directories with random eight-character names are also worth attention when they appear alongside web server activity, because they often indicate staging or unpacking behavior. In practice, the useful question is not simply “did a file appear”, but “did a file appear in a place and sequence that fits attacker staging, compilation, and execution?” That broader pattern is much more reliable than any single filename.

Activity from the file transfer service account can be just as revealing as the file artifacts themselves. If that account starts launching unexpected child processes, touching code files, or interacting with paths outside its normal operational pattern, the account may have been abused as the execution context for the webshell chain.

Why hashes and isolated file checks miss the attack

Hash matching alone is weak for this class of incident because the attacker can change payloads, compile them dynamically, or rotate small components while preserving the same technique. A webshell campaign is a behavior problem as much as a file problem, so detection should combine process lineage, file writes, webroot changes, and service-account activity.

That is why defenders should correlate process trees and filesystem events instead of relying only on static indicators. A suspicious ASPX file with no surrounding process context is a clue; an IIS worker spawning a compiler and then writing that file is a much stronger incident signal.

Risk and Threat Considerations

These indicators matter because they often represent the moment at which a file transfer compromise becomes active code execution on the server. Once an attacker can compile, drop, or execute server-side payloads through the web tier, the blast radius can expand quickly to credential theft, lateral movement, and data access.

Failure mechanism: The attacker abuses trusted web-server execution paths, staged temporary locations, and service-account context to create or execute a webshell while blending into normal IIS activity. Static file hashes fail because the attacker can change the payload or compile it dynamically without changing the underlying technique.

Impact: Security teams may miss the compromise until the attacker has already established persistence, executed arbitrary code, or used the file transfer system as a bridge to adjacent systems and sensitive data.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
MITRE ATT&CK	T1059 — Command and Scripting Interpreter	Webshells and on-host code execution map to scripted command execution behavior.
	T1505.003 — Server Software Component: Web Shell	The question is explicitly about webshell attack signs and server-side persistence.
	T1105 — Ingress Tool Transfer	Webshell campaigns commonly stage payloads and drop tooling before execution.
Recommendation — Hunt for web-originated interpreter activity and correlate it with spawned child processes. Monitor web roots for unexpected server-side script creation and execution paths. Correlate suspicious file drops with follow-on execution and staging activity.
CIS Controls v8	CIS-8 — Audit Log Management	Detection depends on correlating process, file, and service-account activity in logs.
Recommendation — Centralize IIS, process, and file events so webshell behavior can be correlated quickly.
NIST SP 800-53 Rev 5	AU-12 — Audit Record Generation	The answer depends on generating and preserving the events needed to spot the attack chain.
Recommendation — Ensure web-server and process events are recorded at the level needed for forensic correlation.

Practitioner Guidance

What to verify: Confirm whether the suspicious process chain is actually attached to IIS or the file transfer service account, and whether the file writes landed in an executable web path. If the answer is yes, treat the event as active compromise evidence, not just a malware scan result.

What to measure: Track child processes from web-server workers, ASPX creation events under the webroot, and any repeated use of randomly named temporary directories. A rise in these signals together is more actionable than any one indicator on its own.

Common mistake: Teams often stop at file hashing or antivirus verdicts and miss the surrounding execution chain. For this attack pattern, the sequence of events is usually more important than the payload name.

Practitioner takeaway: The most reliable detection strategy is to join process lineage, file-system change, and service-account behavior into one timeline, because that is what exposes a webshell even when the payload itself keeps changing.