How can a web shell provide persistence?¶
A web shell can provide persistence by leaving a remotely accessible command mechanism on a server after the original vulnerability or account access is removed.
Avoid the dangerous assumption¶
The dangerous assumption is that patching the original vulnerability removes the offender’s access.
It may not.
Once installed, the shell may allow commands, file transfer, credential theft, further deployment or movement into other systems.
Investigators should preserve:
- the web-shell file
- path and hash
- creation and modification time
- web requests to it
- commands and parameters
- process activity
- files created
- accounts used
- network connections
- server and application logs.
The presence of the shell does not prove continued use.
Request and process evidence may show whether it was accessed.
A shell may be renamed, modified or hidden among legitimate application files.
It may also remain on another server, replica, container or backup after removal from the first system.
Do not delete the shell before preserving the content and surrounding evidence.
Patching should be recorded separately from shell removal because they address different parts of the access route.
Where web applications are replicated, the shell may be copied automatically to several instances or restored from an image or backup. Identify whether multiple copies represent repeated offender action or normal platform replication.
Preserve deployment, container and replication records so copied shells are not mistaken for separate installations.
This distinction may materially change the inferred scale of compromise.
Operational takeaway¶
Treat the web shell as a separate persistence mechanism, preserve its use and configuration evidence and do not assume patching alone removed access.