Remediating a Web Shell Hidden in IIS or Apache Directories

A web shell hidden in an IIS or Apache directory is not just another suspicious file. It is an attacker-controlled script that gives remote access to the host through the web server, often blending with CMS files, uploads, caches or backup copies. Common examples include PHP, ASPX, JSP and CGI payloads that accept commands or expose a file browser. The danger is the access it grants, not how convincingly its filename resembles legitimate content.

Finding and removing that access requires a joined-up response across web logs, endpoint telemetry, identity systems and the hosting layer. Deleting one script is rarely enough: the intruder may have altered configuration, added a scheduled task, stolen credentials or moved laterally. Remediation must therefore establish what was reached, preserve evidence, remove persistence, rebuild where necessary and verify that the server can no longer be abused.

How attackers conceal web shells

A web shell normally begins life as a file written through a web-accessible path. That path might be an exposed file uploader, a CMS media directory, a writable image folder, a deployment share or an application with arbitrary upload or command-execution flaws. Attackers may also upload a small loader that downloads a larger payload, or use an existing management tool with a web shell manager. These tools commonly encode strings, alter timestamps or place the payload among thousands of files to frustrate manual review.

Once invoked, the script communicates with the web server and executes under its service account. On IIS this is commonly an application-pool identity such as IIS AppPool\SiteName; on Apache it may be apache, www-data or a dedicated PHP-FPM pool user. If that identity can reach domain resources, source control, deployment keys or other internal services, a basic backdoor becomes a path toward broader compromise. Monitoring must cover both the file and the privileges available to the web process.

Why IIS and Apache web roots become hiding places

IIS and Apache are attractive because both are designed to turn files into content or applications. Under IIS, writable locations can include upload folders, temporary application directories, content directories granted broad rights, or paths exposed through an application or virtual directory. Apache deployments present the same issue through DocumentRoot and Alias directives, public_html trees, shared hosting panels and PHP applications whose upload folders remain executable. A directory does not need to be obscure to be dangerous; script execution permission matters far more than its name.

This mix is common in Australia. A Melbourne retailer may run a modern cloud storefront alongside an IIS-based ordering system on an aged Windows server, while a Brisbane branch network reaches Apache-hosted line-of-business tools through a VPN. Smaller organisations often depend on a managed service provider to maintain both Windows and Linux estates. In the Australian market, channel-led delivery through resellers, distributors and specialist MSSPs is normal, making it especially important that remediation responsibilities and access to logs are clear before an incident begins.

Spotting a web shell before it spreads

Triage should combine three views: what changed on disk, what the web tier recorded, and what executed on the endpoint. Useful web indicators include a script receiving unexpected POST parameters, a one-off request for a recently created file, encoded query strings, a new executable file in an upload directory, or responses that resemble command output. File integrity monitoring can reveal unknown hashes, unusual ownership, executable bits on content files or changes to IIS handlers, Apache modules and .htaccess files. Comparing the deployment with a trusted copy or package manifest is often more reliable than trusting modification times alone.

Endpoint telemetry adds the missing context. On Windows, look for suspicious children of w3wp.exe, especially cmd.exe, PowerShell, certutil or rundll32. On Linux, investigate descendants of httpd, apache2 or php-fpm, including bash, curl, wget, nc or temporary utilities. Egress records may show a shell talking to an unfamiliar host, downloading another payload or tunnelling traffic. Attackers can rename processes and disable logging, so a clean antivirus result is not a clean bill of health; combine host, proxy, identity and network evidence.

Containment that preserves useful evidence

Contain the active risk before touching the payload. Where operationally possible, isolate the web server from user networks while retaining a tightly controlled management path, and block or alert on suspicious outbound traffic. Shared infrastructure needs care: removing one application from service is usually preferable to taking down unrelated tenants. If destructive activity is continuing, speed matters, but teams should still avoid casually deleting files or rebooting the machine because those actions can erase clues needed to scope the breach.

Once isolation is stable, capture volatile information such as running processes, active network connections, loaded modules and logged-in sessions, then take a forensic snapshot or disk image. Preserve the web server’s access and error logs, Windows Event records, Linux authentication and audit logs, endpoint alerts, proxy data and relevant cloud control-plane events. Record evidence handling, hashes and custody. CARM Security, developed by Exclusive Networks to integrate multiple security-vendor technologies, can bring these signals into a coordinated workflow for identification, containment, response and remediation rather than leaving responders to correlate disconnected alerts.

Search for related artefacts across every reachable web server, not only the directory where the shell was found. Review web-accessible shares, deployment paths, content-management systems and temporary transfer locations. Use the compromised server’s timestamps and indicators to narrow the hunt, but do not let the initial access vector narrow it too far: stolen credentials, exposed management interfaces and vulnerable applications can create several independent footholds. Escalate to the incident lead and involve legal, privacy and insurer contacts early when notification duties may apply.

Cleaning the server and rebuilding trust

Rebuilding the affected server from a known-good image is usually safer than deleting a suspicious file and declaring the job done. Restore only validated application content, reapply required configuration through controlled change management, and scan every restored layer. If rebuilding is not feasible, remove the web shell and associated uploads only after forensic capture, then inspect IIS application-host settings, modules, handlers, application pools and scheduled tasks. On Apache, inspect modules, .htaccess directives, PHP settings, cron jobs, startup files, service units and user accounts. Malicious changes often sit outside the directory that first raised the alarm.

Close the route that allowed the file to arrive, whether it was an unpatched application, weak file permissions, a public management console or valid credentials used to deploy the payload. Patch the exploited software, rotate passwords and service-account secrets from a clean environment, revoke sessions and tokens, and replace exposed keys or certificates where necessary. Review data access for possible theft. Australian organisations in the finance sector should also assess APRA CPS 230 obligations, while entities covered by the Privacy Act may need to assess the Notifiable Data Breaches scheme and OAIC notification requirements with qualified advisers.

Hardening IIS and Apache hosting

Prevention starts with separating data from execution. On IIS, place uploads on a separate path, deny script execution there, use application-pool identities with minimum rights, and restrict write permissions to the service account that needs them. On Apache, use the appropriate service or FPM pool user, deny execution in upload and media directories, and prevent users from overriding security settings with writable .htaccess files. Validate permissions on Linux rather than applying broad recursive changes, and test each site’s functionality after restrictions because shared applications often contain undocumented write paths.

Create a known-good baseline for web roots, configuration and privileged files, then monitor changes with file-integrity tooling and endpoint detection. Centralise IIS, Apache and application logs in a SIEM and retain them long enough for incident review. A WAF can reduce exposure to malicious uploads and command patterns, but it is not a substitute for patching or execution controls. Egress filtering, privileged-access management, phishing-resistant multifactor authentication and separate administrative paths further reduce the chance that a web request becomes domain access. Mapping these measures to the Australian Signals Directorate’s Essential Eight also helps teams prioritise controls consistently across cloud and on-premises estates.

Comparing IIS and Apache response

The operating-system difference changes the commands, account model and artefacts that responders will see, but the response sequence remains the same: isolate, preserve, scope, rebuild, hunt and harden. Teams operating both IIS and Apache should avoid maintaining two unrelated playbooks. They should maintain one evidence standard, named escalation paths and tested access to critical logs, while allowing platform-specific technical steps to be captured separately.

Area	IIS	Apache
Service execution	w3wp.exe runs each application pool	httpd or apache2 serves requests; code may run through mod_php or PHP-FPM
Paths to inspect	Site root, upload and media folders, temporary paths, virtual directories	DocumentRoot, Alias targets, public_html, CMS and upload paths
Identity boundary	Named application-pool account plus NTFS permissions	Apache service account, dedicated FPM pool, Linux ownership and permissions
Logs and telemetry	IIS request logs, Windows Event records, EDR and process trees	Apache access and error logs, PHP-FPM logs, auditd, EDR and process trees
Common persistence	Application-pool settings, IIS modules and handlers, scheduled tasks and startup items	Loaded modules, .htaccess, cron jobs, service units and startup files
Key hardening	Deny script handlers in upload paths, separate pools and apply least privilege	Disable execution in writable paths, protect .htaccess, isolate FPM pools and apply least privilege

During an arvo change window, a practical validation plan can replay the original request against the restored application, confirm that the payload path returns an appropriate denial, and verify that the web process cannot create or execute files in content locations. It should also test whether known persistence mechanisms have returned, whether privileged credentials still work from expected hosts, and whether outbound traffic is constrained. Keep the validation evidence with the incident record so the result can withstand internal audit, regulator or insurer review.

The practical takeaway is to treat a web shell as evidence of server compromise until proven otherwise, and to rebuild when confidence cannot be restored. For Australian security teams, the strongest outcome is a known-good web tier, least-privilege service accounts, restricted execution in writable paths, retained telemetry and a rehearsed partnership with the MSP or channel provider; these controls turn a high-pressure arvo incident into a controlled, repeatable recovery.