A web shell is a script placed on a server that can give someone continuing control through the website. Finding an unexpected script is concerning, but the response needs more than deleting a file. The team must understand how it arrived, what it allowed, and whether other access remains.
Understand the idea
First separate an unusual file from a confirmed intrusion. Check the deployment record, file ownership, recent changes, and relevant server activity. If the file is malicious, preserve suitable evidence before cleanup. The entry point may be a software weakness, an upload feature, or a stolen administrator account.
- Preserve
Record the suspicious file and relevant server activity.
- Contain
Restrict access and investigate the original entry point.
- Recover
Rebuild or restore as needed, then verify the boundary.
A practical example
For example, a suspicious script disappears during cleanup and returns a day later. The team discovers that an unwanted scheduled task recreates it. Removing only the visible file had left the deeper problem in place. Recovery now includes the task, affected credentials, and the original entry route.
What to do next
- Contain access. Follow the response plan to restrict the affected service and preserve business-critical dependencies. Use a clean administrative device.
- Preserve evidence. Save relevant web, application, identity, and endpoint events. Handle suspicious files as evidence; do not execute them to “see what they do.”
- Find the write path. Investigate vulnerable components, stolen administrator accounts, deployment passwords and access keys, and excessive filesystem permissions.
- Rebuild from a trusted source when warranted. A known-good deployment is often more defensible than manually declaring each remaining file clean. Patch the entry point before reconnecting.
- Rotate exposed secrets and verify access. Consider database passwords and access keys, API keys, service accounts, and sessions reachable from the compromised environment.
How to check the result
Verify that the original route is closed and that unexpected changes do not return. A rebuild from a trusted source may be needed when the team cannot confidently account for server changes.
Can I delete the file and close the incident?
First preserve appropriate evidence and assess other changes and credentials. A replacement file, scheduled task, or stolen identity could survive that deletion.
Sources and useful guides
The following resources provide background and more detailed guidance. Use the sections that match your service and situation.
