Skip to main content

Web Shells – Threat Awareness and Guidance

This advisory outlines the Web shells threat and provides prevention, detection and mitigation strategies for administrators of web servers that have active content languages installed.

Prevention and Mitigation

Installation of a web shell is commonly accomplished through web application vulnerabilities or configuration weaknesses. Therefore, identification and closure of these vulnerabilities is crucial to avoiding potential compromise. The following suggestions specify good security and web shell specific practices:

  • Employ regular updates to applications and the host operating system to ensure protection against known vulnerabilities.
  • Implement a least-privileges policy on the web server to:
    • Reduce adversaries’ ability to escalate privileges or pivot laterally to other hosts.
    • Control creation and execution of files in particular directories.
  • If not already present, consider deploying a demilitarised zone (DMZ) between your web facing systems and the corporate network. Limiting the interaction and logging traffic between the two provides a method to identify possible malicious activity.
  • Ensure a secure configuration of web servers. All unnecessary services and ports should be disabled or blocked. All necessary services and ports should be restricted where feasible. This can include allowing or blocking external access to administration panels and not using default login credentials.
  • Utilise a reverse proxy or alternative service, such as mod_security, to restrict accessible URL paths to known legitimate ones.
  • Establish, and backup offline, a “known good” version of the relevant server and a regular change-management policy to enable monitoring for changes to servable content with a file integrity system.
  • Employ user input validation to restrict local and remote file inclusion vulnerabilities.
  • Conducting regular system and application vulnerability scans is an effective method of establishing areas of risk. While this does not protect against zero day attacks it will highlight possible areas of concern.
  • Furthermore, the deployment of a web application firewall, as well as regular virus signature checks, application fuzzing, code reviews and server network analysis can assist with establishing areas of risk and also help to minimise zero day exploits.


Due to the potential simplicity and ease of modification of web shells, they can be difficult to detect. For example, anti-virus products have been known to produce poor results in detecting web shells.

The following may be indicators that your system has been infected by a web shell. Note anumber of these indicators are common to legitimate files. Any suspected malicious files should be considered in the context of other indicators and triaged to determine whether further inspection or validation is required.

  • Abnormal periods of high site usage (due to potential uploading and downloading activity);
  • Files with an unusual timestamp (e.g. more recent than the last update of the web applications installed);
  • Suspicious files in internet accessible locations (web root);
  • Files containing references to suspicious keywords such as cmd.exe or eval;
  • Unexpected connections in logs. For example:
    • A file type generating unexpected or anomalous network traffic (e.g. a JPG file making requests with POST parameters);
    • Suspicious logins originating from internal subnets to DMZ servers and vice versa.
  • Any evidence of suspicious shell commands, such as directory traversal, by the web server process.

Some web shells will display differently depending on the user-agent string. For example, the shell may not display to a search engine spider’s user-agent. This can be an effective method of identification. To do this, there are plugins (such as “User-Agent Switcher”) that can assist with temporarily changing a user-agent.

Client characteristics can also allude to possible web shell activity. One particular example that could be present in web access logs, is that the client will often visit only the web shell script URI itself whereas a standard user would be seen to load the webpage from a linked page/referrer or would be expected to load additional content/resources. In addition, performing frequency analysis on the web access logs could indicate the location of a web shell. Most legitimate URI visits will contain varying user-agents, whereas a web shell is generally only visited by the creator resulting in limited user-agent variants.

Contact details

Australian government customers with questions regarding this advice should contact the ACSC via 1300 CYBER1 (1300 292 371)

Australian businesses or other private sector organisations seeking further information should contact CERT Australia by emailing or by calling 1300 172 499.

Additional Resources

Was this information helpful?
Was this information helpful?

Thanks for your feedback!


Tell us why this information was helpful and we’ll work on making more pages like it