Last updated: 9 October 2026

Executive summary

A webshell is a small script planted on a web server that gives an attacker a remote command line over ordinary HTTP or HTTPS, and it is one of the most common ways attackers keep access to a compromised internet-facing server. Microsoft reported web shell encounters on servers averaged 140,000 a month from August 2020 to January 2021, almost double the 77,000 monthly average of the year before. Trend Micro and TrendAI incident response research continues to find webshells in ransomware and espionage intrusions through 2026.

Webshells are hard to catch because they are tiny, easy to modify, blend in with legitimate web traffic, and increasingly live only in memory or inside IIS modules. Prevention therefore has to be layered: stop the initial exploit or upload, remove the ability to write and execute in web directories, and detect the behaviour that follows, such as a web server process spawning a command shell.

If a customer does only five things, they should be these:

  1. Patch internet-facing applications first. Exchange, SharePoint, Confluence, CMS cores, plugins and themes are frequent entry points in the cases reviewed here. Where patching lags, apply virtual patching through IPS.

  2. Stop the web service account writing to web-executable directories. Send uploads to a non-executable location and block script execution there.

  3. Monitor file integrity of web roots against a known-good baseline, and alert on any new or changed script file.

  4. Alert on web server processes spawning shells or recon tools (w3wp.exe, httpd, nginx, php-fpm, java or tomcat launching cmd, powershell, sh or bash).

  5. Centralise and retain web server, process and authentication logs so an incident can be scoped quickly.

This guide covers each of these for Windows and IIS, Linux with Apache and Nginx, and WordPress, Joomla and Drupal. It then explains the protections available in Trend Vision One and how to build a custom detection model that alerts early on webshell behaviour.

Understanding webshells

A webshell is a script or module that runs inside a web server's context and accepts commands from a remote attacker, so the attacker keeps access even after the original vulnerability is patched. MITRE tracks the technique as T1505.003 Server Software Component: Web Shell, usually reached through T1190 (Exploit Public-Facing Application).

How webshells get onto a server

  • Exploiting an unpatched application or server, such as Exchange (ProxyLogon), SharePoint (CVE-2019-0604, and the 2025 ToolShell chain), or Confluence (CVE-2023-22527).

  • Unrestricted file upload, where an upload form accepts .aspx, .php or .jsp files. In a Trend Micro Managed XDR investigation, the attacker used POSTs to upload pages to plant the shell.

  • Stolen or weak administrator credentials, then a plugin, theme or template editor used to write code (common in WordPress, Joomla and Drupal).

  • Vulnerable or malicious plugins, themes and extensions, including nulled (pirated) premium themes.

  • Other injection flaws, such as SQL injection with file-write privileges, local or remote file inclusion, and deserialization flaws.

Common types

TypeHow it worksExamplesOne-linerA single line that evaluates attacker-supplied input; tiny and easy to hide inside legitimate filesChina Chopper (ASP, PHP, ASPX variants)Full-featured file-basedFile manager, command execution, database access, upload and download in one pageWSO, c99, b374k, ASPXSpy, Godzilla, BehinderTunnelling / proxyRelays traffic through the web server into the internal networkreGeorg, Neo-reGeorgIn-memory (fileless)Injected into the running web or app server process, so no file exists to scanGodzilla memory shell in Confluence/TomcatServer module / backdoorA malicious IIS native or managed module, Exchange transport agent or Apache module that intercepts requestsMalicious IIS modules

What happens after the shell is planted

Trend Micro's incident response cases show a consistent sequence. The web server process (w3wp.exe on IIS) launches cmd.exe or powershell.exe for reconnaissance such as whoami, tasklist and systeminfo. The attacker then creates or changes accounts, downloads remote-access and tunnelling tools (the case above used AnyDesk and ngrok placed in C:\Users\Public), and archives and pulls data out through the web server itself. Ransomware operators use the same foothold: the Hello ransomware case went from a SharePoint flaw to China Chopper, then Cobalt Strike, then encryption.

Why they evade detection

  • They are small and trivially re-obfuscated, so signatures alone miss modified variants. Microsoft notes web shells are relatively easy to modify and recommends behaviour-based detection.

  • Attackers rename them to blend in (index.aspx, fonts.aspx, default.php, error.aspx, signout.aspx), use image-style extensions for companion tools, and fake file timestamps (timestomping).

  • Traffic looks like normal HTTPS, and tools such as Godzilla encrypt payloads (AES) so inspection of request bodies finds nothing readable.

  • In-memory and module-based variants leave no script file on disk to scan or compare.

Threat landscape and Trend Micro / TrendAI research

Trend Micro and TrendAI research since 2021 shows webshells are the common thread in intrusions that start with a public-facing vulnerability, whether the actor is a ransomware group or a state-aligned espionage team. The table lists the cases reviewed for this guide, newest first.

PublishedResearchEntry pointWebshell and toolingTrend protection named in the researchApr 2026Shadow-Earth-053Exchange (ProxyLogon chain) and IIS serversGODZILLA and custom ASP.NET shells (error.aspx, signout.aspx, timeout.ashx), then ShadowPadSearch App hunting, Threat Intelligence Hub; guidance to use IPS virtual patching and file integrity monitoringJul 2025CVE-2025-53770 / 53771 SharePoint attacksOn-premises SharePoint, ToolPane.aspx deserializationspinstall0.aspx, which steals the MachineKey so attackers can forge ViewStateIPS rule 1012390; TippingPoint filters 46160, 45905, 45906; DDI rule 5446; Vision One emerging threat entry (KB)Jan 2025Web shell intrusion via Managed XDRUnrestricted file upload on an IIS applicationcmd.aspx, up.aspx and similar; AnyDesk, ngrok, reverse shellRoot Cause Analysis; detection model "IIS Worker Process Spawning Suspicious PowerShell Command"Oct 2024Web shell and VPN threatsUpload to IIS; separately, compromised VPN credentialsTunnelling tools disguised as .jpg and .txt filesSearch App hunting on w3wp.exe file creation; DDI detection of Impacket activityAug 2024Godzilla fileless backdoorsAtlassian Confluence CVE-2023-22527In-memory Godzilla valve in Tomcat, with AES-encrypted trafficDPI rule 1011954 (Server & Workload Protection); DDI rule 4990Apr 2021Hello ransomwareSharePoint CVE-2019-0604Updated China Chopper (Backdoor.ASP.WEBSHELL.SMYAAIAS), then Cobalt StrikeAnti-malware detections across the chain

The lessons that recur across these cases:

  • The entry point is almost always a known vulnerability or an unrestricted upload. Virtual patching and fast patching close the window attackers use.

  • The first visible behaviour is a web server process running system commands. This is the most reliable detection point and is the basis of the custom detection model later in this guide.

  • Shells are used quickly, or kept in reserve. Attackers follow a shell with remote-access tools and new accounts, and the October 2024 research also found an earlier upload the attacker had not yet used. Alert on the first sign rather than waiting for damage.

  • Fileless techniques defeat file scanning on its own. Detection needs behavioural and network layers as well.

  • There is often more than one way back in. In the October 2024 webshell case the attacker created a local admin account that Trend assessed would be used later, so removing one webshell does not end an incident.

Universal prevention principles

These controls apply to every platform and CMS in the sections that follow. They reflect the joint NSA and ASD guidance on detecting and preventing web shell malware, Microsoft's web shell research, and Trend Micro's incident response findings.

  1. Patch internet-facing applications within days, not weeks. The NSA guidance notes attackers sometimes target vulnerabilities in internet-facing web applications within 24 hours. Prioritise Exchange, SharePoint, Confluence, CMS cores, plugins and themes, and enable automatic updates where the application supports them.

  2. Use virtual patching where patching is delayed. An intrusion prevention system with rules for the specific CVE blocks the exploit while the vendor patch is tested. See the Vision One section for the Trend options.

  3. Run the web service with least privilege. The service account should be able to read application code but not write to it, and should not be a local administrator. This blocks the most common upload route.

  4. Separate writable from executable. Store uploads outside the web root, or in a directory where script execution is disabled in the web server configuration. Never allow a directory to be both writable by the web service and executable as script.

  5. Validate uploads. Allow-list file types, check content as well as extension, rename files on upload, cap size, and scan uploaded files with anti-malware. Disable upload features that are not in use until validation is in place.

  6. Put a web application firewall in front of internet-facing sites. The OWASP Core Rule Set includes patterns that block malicious uploads and common injection attacks. A WAF stops many initial compromises but will not detect an established webshell on its own.

  7. Monitor file integrity of web roots. Compare production against a verified known-good copy, which the NSA calls the most effective detection method. Do not rely on timestamps, because attackers fake them.

  8. Segment the network. Place internet-facing servers in a DMZ with explicit rules for traffic to internal systems, so a compromised web server cannot reach domain controllers, databases and file servers freely.

  9. Restrict outbound traffic from web servers. Most web servers need very few outbound destinations. Blocking the rest breaks reverse shells, tool downloads and exfiltration.

  10. Remove what is not needed. Disable unused services, modules, sample applications, management endpoints, and legacy handlers (ASP, PHP, CGI) the site does not use.

  11. Protect administrator access. Use MFA on CMS admin panels, VPNs and remote management, and restrict admin paths by IP address where practical. Stolen credentials are a common way to upload a shell through a legitimate editor.

  12. Keep a known-good copy and tested backups. Deploy code from source control or a pipeline instead of editing on the server, so any unexpected file is by definition suspicious. Keep offline backups for recovery.

  13. Log centrally and keep the logs. Web access logs, process creation, authentication and file changes should be sent to a system the web server cannot modify.

Windows Server and IIS hardening

IIS is the most heavily targeted web platform in the Trend Micro cases above, and the pattern is consistent: an ASPX shell is written into a web directory, then w3wp.exe starts cmd.exe or powershell.exe. The controls below break that chain at each step.

Reduce the chance of a shell being written

  • Run each site in its own application pool with ApplicationPoolIdentity, never SYSTEM, NetworkService or a domain admin account. A shell inherits the permissions of the pool identity.

  • Make the web root read-only for the pool identity. Grant the site's own pool identity (IIS AppPool\) Read and Execute on application folders, and Modify only on the specific data or upload folders that need it. Avoid granting rights to the IIS_IUSRS group, because every application pool is a member of it, which undoes the per-site isolation.

  • Disable script execution in writable folders. Add a web.config in each upload or data folder that allow-lists only the file types you serve and removes script rights from handlers:

<configuration>
  <system.webServer>
    <security>
      <requestFiltering>
        <!-- Serve only these static file types from this folder -->
        <fileExtensions allowUnlisted="false">
          <add fileExtension=".jpg"  allowed="true" />
          <add fileExtension=".jpeg" allowed="true" />
          <add fileExtension=".png"  allowed="true" />
          <add fileExtension=".gif"  allowed="true" />
          <add fileExtension=".pdf"  allowed="true" />
        </fileExtensions>
      </requestFiltering>
    </security>
    <!-- Extra layer: handlers needing script or execute rights are not selected -->
    <handlers accessPolicy="Read" />
  </system.webServer>
</configuration>

Request filtering with allowUnlisted set to false is the enforceable control here, because IIS rejects any request for an extension not on the list. The accessPolicy setting is only a filter that stops script handlers being selected, and Microsoft's documentation says it is not an enforceable security policy. The handlers section can also be locked at server level, in which case set it through Handler Mappings > Edit Feature Permissions in IIS Manager or unlock the section. Test on a staging copy first, because an allow-list also blocks extensionless requests. The strongest option remains to keep uploads outside the web root.

  • Remove handler mappings and modules the site does not use (classic ASP, CGI, ISAPI, WebDAV, directory browsing). Test on a staging copy first.

  • Keep an allow-list of ASPX files. Alert when a new .aspx, .ashx, .asmx or .asp file appears, particularly in folders such as aspnet_client, SharePoint's TEMPLATE\LAYOUTS, and Exchange's auth directories, which Trend research shows attackers favour.

  • Block execution from staging folders such as C:\Users\Public, C:\ProgramData and temp directories using application control (WDAC, AppLocker, or Trend Application Control).

Application-specific steps

  • Exchange: install every Security Update promptly, restrict external access to ECP and the admin endpoints, and apply Microsoft's Exchange Emergency Mitigation service where available.

  • SharePoint: apply the July 2025 and later security updates, turn on AMSI integration in Full Mode as Microsoft recommends, watch the LAYOUTS directory for unexpected .aspx files (spinstall0.aspx and similar), and rotate the farm MachineKey if a server was exposed before patching (Set-SPMachineKey or the Machine Key Rotation timer job), then restart IIS on every SharePoint server with iisreset, as Microsoft's July 2025 guidance describes.

  • Custom ASP.NET apps: review every upload handler. The January 2025 Trend case began with an upload page that accepted any file type.

Watch for IIS module backdoors

A malicious IIS module can act as a webshell without any ASPX file, so file scanning of the web root will miss it. Microsoft's IIS modules research recommends:

# Enable module change logging (Event ID 29 = module added/removed, 50 = configuration changes committed)
wevtutil sl /e:true Microsoft-IIS-Configuration/Operational

# Baseline the installed modules, then compare regularly
& "$env:windir\system32\inetsrv\appcmd.exe" list modules

Also alert on gacutil.exe or appcmd.exe add module being launched from w3wp.exe, new DLLs in the bin folders and Global Assembly Cache, and changes to web.config.

Enable the logging that makes detection possible

  • Process creation auditing with command line (Event ID 4688), or Sysmon, so child processes of w3wp.exe are visible.

  • PowerShell script block logging (Event ID 4104). The Trend Managed XDR case used this to decode the attacker's encoded reverse shell.

  • IIS advanced logging, including the User-Agent, Referer and POST requests, forwarded to a central log platform.

  • On Exchange servers, Microsoft Defender users can enable the attack surface reduction rule Block Webshell creation for Servers, which needs Microsoft Defender Antivirus and applies to Exchange on Windows Server 2016 and later. For all other web server roles, and for Trend customers, Server & Workload Protection (Integrity Monitoring, Application Control and Activity Monitoring) provides the file-change and process visibility.

Linux, Apache and Nginx hardening

On Linux the equivalent of the IIS pattern is a PHP, JSP or CGI process running as www-data, apache or nginx that writes a script file and then runs commands. The aim is to make the web user unable to write code, unable to execute what it writes, and visible when it runs anything unusual.

Reduce the chance of a shell being written

  • Separate code ownership from the web user. Code should be owned by a deploy account and read-only to the web server process. Only the upload and cache directories should be writable by it. The Drupal project's file permission guidance describes this model and applies to any PHP application.

  • Use a separate user and PHP-FPM pool per site, so one compromised site cannot write into another.

  • Mount upload and temp locations noexec, nosuid, nodev where the layout allows, for example a dedicated partition for uploads and /tmp. This stops programs being run directly from those locations, but it does not stop PHP, because the interpreter only reads the file. Use the execution rules below for scripts.

  • Block script execution in upload directories. AllowOverride None matters, because attackers often upload a .htaccess file that turns PHP back on. Apache 2.4:

<Directory "/var/www/html/wp-content/uploads">
    AllowOverride None
    Options -ExecCGI -Indexes
    <FilesMatch "\.(php|phtml|phar|php[0-9])$">
        Require all denied
    </FilesMatch>
</Directory>

Nginx:

# ^~ stops the main PHP regex location from taking over inside uploads
location ^~ /wp-content/uploads/ {
    location ~* \.(php|phtml|phar)$ { deny all; }
}
  • Restrict PHP functions that give attackers a shell. In php.ini or a PHP-FPM override such as /etc/php//fpm/conf.d/99-security.ini (Debian and Ubuntu layout; paths differ on RHEL):
disable_functions = exec,passthru,shell_exec,system,proc_open,popen,pcntl_exec,parse_ini_file,show_source
allow_url_fopen = Off
allow_url_include = Off
open_basedir = /var/www/example.org:/tmp

Test first, because some applications and plugins need these functions. Treat this as one layer only, since determined attackers can sometimes bypass it.

  • Confine the web server with SELinux or AppArmor in enforcing mode, and on SELinux leave booleans such as httpd_can_network_connect turned off unless the site needs outbound connections.

  • Remove unneeded Apache modules (mod_cgi, mod_userdir, mod_status exposed externally) and deploy ModSecurity with the OWASP Core Rule Set, or an equivalent WAF in front.

  • Restrict outbound connections from the web user with nftables or iptables owner matching, or at the network firewall, so a reverse shell cannot call out.

  • Harden the service unit. Settings such as NoNewPrivileges, ProtectSystem and ReadWritePaths in the systemd unit narrow what a compromised process can touch.

Watch for persistence tricks

Attackers hide Linux and PHP shells outside obvious files. Check .htaccess and .user.ini for unexpected auto_prepend_file or handler rules, cron entries for the web user, new SSH keys, and PHP files with image extensions or double extensions processed by a misconfigured handler.

Detection with built-in tools

The NSA guidance and open tools such as Wazuh use the same two ideas: audit what the web user executes, and watch the web root for changes.

# /etc/audit/rules.d/webshell.rules  (www-data is UID 33 on Debian/Ubuntu; use apache or nginx UID on RHEL)
-a always,exit -F arch=b64 -S execve -F euid=33 -k webshell_exec
-a always,exit -F arch=b32 -S execve -F euid=33 -k webshell_exec
-w /var/www/html -p wa -k webroot_change
# Load the rules with: augenrules --load

# Compare production against a known-good copy
diff -r /srv/known-good/site /var/www/html

# Quick triage: script files in upload directories, and recently changed scripts
find /var/www -path '*/uploads/*' \( -name '*.php' -o -name '*.phtml' -o -name '*.phar' \)
find /var/www -type f -name '*.php' -mtime -7

# Common dangerous functions (expect false positives, review manually)
grep -RIlE '(eval|assert|gzinflate|str_rot13|base64_decode)\s*\(' /var/www

For Java stacks such as Tomcat and Confluence, apply vendor patches immediately and alert on the Java process starting sh, bash or any system utility. The Godzilla case shows these in-memory shells leave no file to find.

CMS hardening: WordPress, Joomla and Drupal

Content management systems are a favourite target because they run on large numbers of servers and depend on third-party plugins, themes and extensions that are often outdated. The Linux and Windows controls above all apply. The steps below are specific to each CMS.

Across all three, the order of priority is the same: keep core and every extension patched, remove what is not used, protect admin logins with MFA, stop the web user writing to code folders, and stop PHP running in upload folders.

WordPress

  • Patch quickly and enable automatic updates for core, plugins and themes. Vulnerable plugins are the usual entry point.

  • Remove unused plugins and themes rather than deactivating them, and install only from the official repository or a vendor you trust. Never use nulled (pirated) premium themes or plugins, which commonly ship with a shell.

  • Turn off the dashboard code editors in wp-config.php so a stolen admin login cannot edit PHP directly. The WordPress hardening guide documents this setting:

define( 'DISALLOW_FILE_EDIT', true );

  • Consider blocking installs from the dashboard with DISALLOW_FILE_MODS on sites where updates are deployed through a pipeline. This stops an attacker uploading a malicious plugin, but it also stops dashboard and automatic updates, so only use it with a managed update process.

  • Set permissions to 755 for directories and 644 for files, keep wp-config.php locked down, and let only wp-content/uploads be writable by the web user. Block PHP in uploads (see the Linux section). With code read-only to the web user, dashboard and automatic updates cannot write files, so run updates as the file owner, for example WP-CLI from a scheduled job or your deployment pipeline.

  • Enforce MFA and strong passwords for all administrator and editor accounts, limit login attempts, and disable XML-RPC if it is not needed.

  • Verify integrity regularly with WP-CLI, which compares files against the official checksums (the plugin check covers plugins hosted on WordPress.org only, so compare commercial plugins against the vendor's package):

wp core verify-checksums
wp plugin verify-checksums --all

Joomla

  • Keep the core and every extension updated and uninstall extensions you do not use, deleting their leftover files. The Joomla security checklist advises checking the official list of vulnerable third-party extensions, downloading only from trusted sources, and testing on a development site first.

  • Enable multi-factor authentication for Super Users and administrators (built into Joomla 4.2 and later), and give day-to-day editors the lowest role that works.

  • Protect the /administrator path with an IP allow-list or an extra web-server login.

  • Set permissions to 755 for directories and 644 for files, with configuration.php made read-only and not writable by the web user.

  • Restrict the Media Manager to the file types you actually need, and block PHP execution in the images and media folders. Move the tmp and logs folders to a location a casual visitor cannot find, and delete the installation directory, archives and temporary files from the server.

  • Review the Action Logs and the Super User list for accounts you do not recognise.

Drupal

  • Apply security releases the day they ship. The Drupalgeddon 2 flaw (CVE-2018-7600) was widely exploited soon after proof-of-concept code was published. Subscribe to Drupal security advisories.

  • Manage code with Composer and check dependencies regularly (composer audit, drush pm:security). Remove unused modules and themes.

  • Make code read-only to the web server. Use the commands from the Drupal file permissions guide:

chown -R deploy:www-data .
find . -type d -exec chmod u=rwx,g=rx,o= '{}' \;
find . -type f -exec chmod u=rw,g=r,o= '{}' \;
# files directory only: group-writable so Drupal can store uploads
find ./sites/*/files -type d -exec chmod ug=rwx,o= '{}' \;
find ./sites/*/files -type f -exec chmod ug=rw,o= '{}' \;

  • Protect settings.php, which holds database credentials in plain text, by removing world-read permission. Keep the .htaccess file Drupal places in the files directory in place, as it denies PHP execution there on Apache. Nginx ignores .htaccess, so add an equivalent location rule (see the Linux section) when running Nginx.

  • Limit who can use the PHP-capable and code-editing features, and require MFA on administrator accounts through a maintained module.

Quick comparison

ControlWordPressJoomlaDrupalIntegrity checkwp core verify-checksums, wp plugin verify-checksums --allCompare against the official release package and a known-good copyCompare against Composer-installed code and a known-good copyBlock admin code editingDISALLOW_FILE_EDITDo not grant file-editing roles; use read-only codeRead-only code ownership, no PHP-executing text formatsUpload folderwp-content/uploadsimages (Media Manager default)sites/*/filesMain entry point to watchPlugins and themesThird-party extensionsCore and contributed module advisories

Detection and monitoring

No single detection method catches every webshell, so customers should combine at least a file-based method, a behavioural method and a network or log method. The table shows what each one finds and where it falls short.

MethodWhat it catchesBlind spotKnown-good comparison and file integrity monitoringNew or changed script files in web roots, including renamed shellsFileless shells, IIS modules outside the web root, and noisy on busy sites unless baselinedAnti-malware and file scanningKnown and ML-detected shell files, including uploads at the point of entryObfuscated or newly modified variants; anything that is never written to diskProcess behaviour (EDR)A web server process starting cmd, PowerShell, sh or recon tools, including from in-memory shellsShells that only use the web language's own functions without spawning processesWeb log and traffic analysisRarely requested scripts, odd user agents, POSTs to unusual URIs, off-hours accessEncrypted bodies hide content, and needs good logging and a baselineNetwork flow monitoringWeb servers connecting outbound or to internal systems they never normally reach, and unexpected listenersShells that only answer inbound requestsIPS and WAFThe exploit or upload that delivers the shellEstablished shell traffic that looks like normal requests

Web log analysis

The NSA guidance recommends looking for URIs that very few distinct user agents or client IPs ever request, because a webshell is typically used by one operator. Other signs are POST requests to scripts that never normally receive them, requests with no Referer header, access outside normal hours, requests to files in upload folders, and responses of unusual size.

# Least-requested URIs in a combined-format access log: a starting point for review
awk '{print $7}' access.log | sort | uniq -c | sort -n | head -50

Process and endpoint behaviour

These are the highest-value alerts, and they are consistent across Microsoft, NSA and Trend guidance:

  • w3wp.exe, httpd, nginx, php-fpm, java or tomcat starting cmd.exe, powershell.exe, sh, bash, curl, wget or nc.

  • Reconnaissance commands launched by a web service account, such as whoami, net, ipconfig, systeminfo, tasklist and netstat.

  • A script file (.aspx, .ashx, .asp, .php, .jsp) created in a web directory by a process other than your deployment tooling.

  • Web server processes writing archives, executables or tools into C:\Users\Public, C:\ProgramData, /tmp or /dev/shm.

  • New local accounts, or new members of the Administrators or Remote Desktop groups, soon after any of the above.

Network and exposure checks

  • Map which servers should accept inbound web traffic, and alert on any web server opening a new listening port.

  • Alert on web servers connecting to internal management ports (RDP, SMB, WinRM, SSH) that they never normally use.

  • Scan your own external footprint regularly so forgotten or test servers are patched or removed.

Review cycle

Run a known-good comparison of every internet-facing web root on a schedule, such as weekly, and after every patch or deployment. Review new IIS modules and PHP auto_prepend settings in the same cycle. Treat any unexplained script file as an incident until proven otherwise.

Trend Vision One protection against webshells

Trend Vision One (also branded TrendAI Vision One) covers the webshell lifecycle at several layers: blocking the exploit, spotting the shell file, detecting the behaviour that follows, and giving analysts the data to investigate. Availability depends on which Vision One modules and licences a customer has, so confirm each item against their tenant.

Servers need Server & Workload Protection. The server controls in this guide come from Trend Server & Workload Protection, not standard endpoint protection. According to Trend's protection modules documentation, Intrusion Prevention for server applications (the virtual patching rules for products such as SharePoint and Confluence), Integrity Monitoring, Log Inspection and Activity Monitoring are available only in Server & Workload Protection, while standard endpoint protection offers the desktop-focused set. Standard endpoint protection should not be used as the protection for the web servers covered here.

StageCapabilityHow it helpsSourceBlock the exploitIntrusion Prevention (virtual patching) in Server & Workload ProtectionRules for specific CVEs inspect traffic and block exploitation before the server is patched. Examples: rule 1011954 for Confluence CVE-2023-22527 and rule 1012390 for SharePoint CVE-2025-49706 and 53771Godzilla research, SharePoint KBBlock the exploitNetwork Security (TippingPoint) filters and Deep Discovery Inspector rulesNetwork-level filters for the same CVEs, such as filters 46160, 45905 and 45906 for SharePoint, plus DDI rules 4990 and 5446. Coverage for SharePoint flaws found at Pwn2Own was live from May 2025SharePoint researchStop the shell fileAnti-malware with Trend threat intelligenceDetects webshell families named Backdoor.ASP.WEBSHELL., Backdoor.PHP.WEBSHELL. and Backdoor.JS.WEBSHELL.*, including China Chopper variantsHello ransomware researchStop the shell fileApplication Control and Integrity MonitoringApplication Control detects new or modified files and can enforce an allow-list; Integrity Monitoring alerts on changes to web roots and configuration filesProtection modulesStop the C2Web Reputation and FirewallBlocks known command-and-control and malware hosting domains, and restricts outbound connectionsSame as aboveDetect behaviourDetection models and Observed Attack Techniques in Vision One XDRBuilt-in models such as "IIS Worker Process Spawning Suspicious PowerShell Command" flag w3wp.exe spawning shells and raise Workbench alertsManaged XDR caseInvestigateWorkbench, Root Cause Analysis and the Search appMaps the process tree from the exploited web server to the commands run, and lets analysts hunt across endpoint activity dataSame as aboveStay aheadThreat Intelligence Hub and Threat InsightsEmerging-threat entries such as CVE-2025-53770 give customers a prompt to check exposureSharePoint researchRespondSecurity Playbooks, response actions and Managed XDRAutomates containment (for example isolating the endpoint), and Managed XDR adds expert investigation, as in the January 2025 caseCustom detection model preview

Suggested baseline for each web server

  1. Install the Server & Workload Protection agent on every internet-facing server, with Anti-Malware, Intrusion Prevention, Integrity Monitoring, Application Control and Web Reputation enabled.

  2. Apply IPS recommendation scans so the rules matching the installed applications are assigned automatically, and enable automatic rule updates. Check the Intrusion Prevention behaviour is set to Prevent rather than Detect, otherwise matching rules only log.

  3. Monitor the web root, web.config, and application configuration directories with Integrity Monitoring.

  4. Turn on Activity Monitoring in the agent policy and register the agent with Vision One XDR, because the detection models and the Search app depend on that data. Trend's XDR integration documentation lists agent version 20.0.0-1681 or later for Windows and Linux, and outbound connectivity to the XDR addresses. Remote isolation needs 20.0.0-2593 or later, so keep agents current.

  5. Add the custom detection model in the next section so the customer is alerted the first time a web server process runs a command shell.

  6. Connect Workbench alerts to the customer's SIEM, ticketing or Security Playbooks.

Hunting in the Search app

The queries below use the Endpoint Activity Data search method. The first three come from the community TMHunting recipes and the last is the query Trend published in its SharePoint research. In these queries, eventSubId 101 is a file creation event.

# IIS worker process starting a command shell
processFilePath:"c:\windows\system32\inetsrv\w3wp.exe" AND objectFilePath:cmd.exe

# Files created by IIS worker processes
parentFilePath:(w3wp.exe OR UMWorkerProcess.exe) AND eventSubId: 101

# New compiled ASPX files under aspnet_client
objectFilePath:("*\inetpub\wwwroot\aspnet_client*" AND *aspx) AND eventSubId: 101

# SharePoint ToolShell: spinstall0.aspx written by PowerShell
eventSubId: 901 AND objectRawDataStr: "TEMPLATE\LAYOUTS\spinstall0.aspx"

Rule and filter numbers above are those published in the cited research at the time and may be superseded, so check the current ID in the Vision One console or the Trend knowledge base before quoting it to a customer.

Creating a custom detection model in Vision One

A custom detection model lets a customer raise a Workbench alert the moment a specific webshell behaviour appears in their own environment, without waiting for a built-in model to cover it. It has two parts: a custom filter that describes the events to look for, and a custom model that decides when matching events become an alert. Alerts appear in Workbench and as Custom Observed Attack Techniques events, and flow to the Workbench API, SIEM integrations and Security Playbooks, as described in the custom detection model documentation.

Before you start

  • The servers must have the Server & Workload Protection agent installed and reporting activity data to Vision One (Activity Monitoring enabled, agent 20.0.0-1681 or later), because the filters query that data.

  • You need a role that can use Detection Model Management.

  • Use the Search app first to confirm the query returns the events you expect. Custom filters use the same search query syntax.

  • Menu names change between releases. The current path is Agentic SIEM and XDR > Detection Model Management. Older documentation shows it under XDR.

Step 1: Create the custom filter

Steps follow the custom filter documentation.

  1. Go to Agentic SIEM and XDR > Detection Model Management > Custom filters and click Add.

  2. Enter a Filter name and Description. Use a naming convention such as WEB-01 w3wp spawns command shell.

  3. Set the Severity (Low, Medium, High or Critical). Use Low while testing so the filter does not affect dashboards.

  4. Select the Event type. For process and file activity on servers, choose ENDPOINT_ACTIVITY (or TELEMETRY_FILE for file events only). If you are using a third-party log source, choose THIRD_PARTY_LOG and enter the Vendor; otherwise pick the matching Event ID.

  5. Enter the Query (examples below).

  6. Click Validate Query, then use the option to preview search results to confirm it matches what you expect and not too much else.

  7. Optionally add Custom tags (up to 10, each up to 64 characters), for example webshell and T1505.003.

  8. Click Save.

You can also import a Sigma rule under Add filters > Import from computer (ZIP or YAML). Rules from the SigmaHQ repository can convert automatically if their logsource is supported, others need manual edits, and conversion can take several minutes to take effect. See Import Sigma rules.

Step 2: Create the custom model

Steps follow the custom model documentation.

  1. Go to Detection Model Management > Custom models and click Add.

  2. Enter the Model name and Description.

  3. Choose the Severity (Low, Medium or High). Medium or higher affects the Risk Index in Cyber Risk Overview, so start at Low for testing, then raise it once the model is tuned.

  4. Choose the filtering mode: Single filter, Multiple filters (combined with AND or OR, not mixed), or Multiple filters in sequence. A model can use up to 5 filters.

  5. Select the filter and set the Threshold, the number of matching events (greater than 0) needed to raise an alert. Use 1 for high-confidence behaviour such as a shell spawned by w3wp.exe.

  6. Choose the event grouping: Company, Container, Endpoint or User account. Endpoint is the right choice for webshell models, so the threshold counts per server.

  7. Set the schedule: Frequency (how often the query runs) and Period (how far back each run looks). Choose the shortest frequency available so the alert arrives quickly.

  8. Set Status to enabled and save.

Recommended webshell models

These are starting points. The field names come from Trend's published research and the community TMHunting recipes, so validate and preview each query in your tenant before saving, as syntax details such as escaping can vary. Trend's custom filter documentation also supports regex between forward slashes for precision (up to 5 patterns per query, spaces either side of the slashes, and backslash, slash and quote characters escaped), which helps if wildcard matching proves too broad.

Model 1: Web server process spawns a command shell (Windows). Single filter, threshold 1, group by Endpoint, severity High once tuned. This is the highest-value alert, matching the behaviour in the IIS and SharePoint cases above.

processFilePath:"c:\windows\system32\inetsrv\w3wp.exe" AND objectFilePath:(*cmd.exe OR *powershell.exe)

Model 2: Web server process spawns a shell (Linux). Same settings. This needs Linux activity data from the Server & Workload Protection agent, so confirm it appears in the Search app first. Expect some legitimate matches: PHP's mail() function runs sendmail through /bin/sh, so contact forms can trigger it and need an exclusion. Add *java to the process list for Tomcat or Confluence servers.

processFilePath:(*httpd OR *apache2 OR *nginx OR *php-fpm*) AND objectFilePath:(*/bin/sh OR */bin/bash OR */bin/dash)

Model 3: Script file created in a web directory. Single filter, threshold 1, group by Endpoint, start at Medium. Expect noise from legitimate deployments, so tune it by narrowing the path to folders that should never receive new scripts, or by excluding your deployment tooling. SharePoint and Exchange updates also write .aspx files into these folders, so expect alerts during patch windows.

eventSubId: 101 AND objectFilePath:(*.aspx OR *.ashx OR *.asp OR *.asmx) AND objectFilePath:(*inetpub* OR *wwwroot* OR *LAYOUTS*)

Model 4: SharePoint ToolShell indicator. Single filter, threshold 1, severity High. This is the query Trend published for the spinstall0.aspx dropper. Microsoft also reported spinstall.aspx, spinstall1.aspx and spinstall2.aspx variants, so consider a second filter for those names.

eventSubId: 901 AND objectRawDataStr: "TEMPLATE\LAYOUTS\spinstall0.aspx"

Model 5: Escalation after a web shell command (sequence). Use Multiple filters in sequence, group by Endpoint, severity High. Filter 1 is Model 1's query. Filter 2 looks for an account being created or added to a group with net /add, which the Trend cases show attackers do after gaining a shell. Seeing both on one server is a strong sign of active compromise.

objectFilePath:(*net.exe OR *net1.exe) AND objectCmd:*/add*

Step 3: Test and tune

  1. Run each query in the Search app across the last 30 days to see how many events it would have matched. A good webshell model should return zero or very few.

  2. Save the model at Low severity and leave it for a week or two. Review every alert and add exclusions to the filter for known legitimate processes.

  3. Have the customer's authorised testers trigger the behaviour once on a non-production server, for example a lab page that runs whoami, and confirm the alert reaches Workbench.

  4. Raise the severity to Medium or High and enable notifications.

Step 4: Connect alerts to response

  • Send Workbench alerts to the customer's SIEM or ticketing system through the Workbench API or the existing integrations.

  • Use Security Playbooks to automate the first response, for example notifying the on-call team or isolating the endpoint, once the model is trusted.

  • Document who responds, and use the incident response checklist in this guide.

Limits and notes

  • Custom filters are limited to 50 per environment. The documentation states the custom model limit as 50 on one page and 500 on another, so check the current figure in the Online Help Center.

  • Renaming a model or changing its description does not update alerts that were already raised.

  • Models can be exported and imported, so a tested set can be reused across tenants, which is useful for managed service providers.

  • This approach alerts on behaviour. It complements, and does not replace, IPS virtual patching, anti-malware and integrity monitoring.

Incident response playbook for a suspected webshell

A found webshell should be treated as a full server compromise until shown otherwise, because by the time it is noticed the attacker has usually already run commands. Customers who have a retainer or Managed XDR service should call it in at step 1.

  1. Preserve evidence before cleaning. Take a disk snapshot or image. If an in-memory shell is possible (Java, Tomcat, IIS modules), capture memory or the running process list before restarting anything. Do not simply delete the file.

  2. Contain. Isolate the server from the network, ideally keeping it powered on for forensics. In Vision One, the Isolate Endpoint response action does this remotely for servers whose Server & Workload Protection agent is version 20.0.0-2593 or later, registered with XDR and with Activity Monitoring enabled. Block known attacker IPs and domains, understanding that this alone does not remove access.

  3. Scope. Use web logs to find the first request to the shell file and work backwards to the request that planted it. Use process and endpoint data (Vision One Root Cause Analysis and the Search app) to list every command the web process ran, files it created, accounts it added and outbound connections it made. Search every other web server for the same filenames, hashes, IPs and behaviour, because attackers commonly leave several shells and Microsoft documented redundant installs across multiple servers.

  4. Find the way in. Identify the vulnerable application, plugin, upload form or stolen credential, and fix it. A shell removed without closing the entry point returns within days.

  5. Eradicate persistence. Check for new local or domain accounts, scheduled tasks and services, IIS modules and handlers, Exchange transport agents, auto_prepend_file settings, cron entries, SSH keys, and remote-access tools such as AnyDesk and ngrok.

  6. Reset credentials and secrets. Assume anything the web process could read is exposed: database and API credentials, service accounts, CMS administrator passwords, TLS private keys, and for SharePoint the farm MachineKey. Reset domain credentials if the server held privileged tokens or the attacker reached the domain.

  7. Rebuild or restore. Where an attacker had administrative or SYSTEM rights, rebuild the server from a trusted image and redeploy the application from source control, rather than cleaning it in place. Restore data only from backups that pre-date the compromise.

  8. Harden and monitor. Apply the controls in this guide, deploy the custom detection models, and watch the rebuilt server closely for at least 30 days.

  9. Report and review. Check legal and contractual notification duties, such as privacy breach notification rules and reporting to the national cyber security agency, and record lessons learned.

If ransomware or data theft followed the shell, as in the Hello ransomware and Managed XDR cases, widen the investigation to cover lateral movement and exfiltration, and engage the customer's incident response provider.

Quick-reference checklist and sources

Use this checklist for an internet-facing server review. Each item maps to a section above.

Prevent

  • OS, web server, application, CMS core, plugins and themes are patched, with a defined window for critical fixes

  • IPS virtual patching is enabled for internet-facing applications

  • A WAF protects public sites

  • The web service account cannot write to code directories and is not an administrator

  • Upload folders are outside the web root or have script execution disabled

  • Upload features validate type and content, and uploads are scanned

  • Unused modules, handlers, plugins, themes and sample content are removed

  • Administrator logins use MFA and are restricted where possible

  • The web server's outbound traffic is restricted to what it needs

  • The server sits in a segmented DMZ with explicit rules to internal systems

Detect

  • File integrity monitoring covers web roots, web.config and application configuration

  • A known-good copy exists and is compared on a schedule

  • Process creation, PowerShell and web logs are collected centrally and retained

  • IIS module changes are logged (Event IDs 29 and 50), and the module list is baselined

  • Server & Workload Protection agent (not standard endpoint protection) is installed on every server with Anti-Malware, Intrusion Prevention, Integrity Monitoring, Application Control and Activity Monitoring enabled

  • The custom detection models from this guide are created, tested and routed to the on-call team

Respond

  • An incident response plan covers webshells and names who isolates a server

  • Response actions and Security Playbooks are configured and tested

  • Offline backups exist and a restore has been tested

  • Contacts for the customer's incident response provider and Managed XDR service are current

Sources

Trend Micro and TrendAI research and documentation

Independent guidance