Web Shell - file server.php

Hunt Hypothesis

This detection identifies potential web shell deployments where adversaries establish a persistent backdoor via a server.php file to execute commands and maintain access on compromised web servers. Proactively hunting for this behavior in Azure Sentinel is critical to uncover stealthy post-exploitation activities that may evade standard signature-based alerts, ensuring early identification of unauthorized persistence mechanisms before lateral movement occurs.

YARA Rule

rule webshell_php_sh_server {
	meta:
		description = "Web Shell - file server.php"
		license = "Detection Rule License 1.1 https://github.com/Neo23x0/signature-base/blob/master/LICENSE"
		author = "Florian Roth (Nextron Systems)"
		date = "2014/01/28"
		score = 50
		hash = "d87b019e74064aa90e2bb143e5e16cfa"
		id = "393e738a-b4c2-5630-a55f-c3caee4ff75e"
	strings:
		$s0 = "eval(getenv('HTTP_CODE'));" fullword
	condition:
		all of them
}

Deployment Notes

This YARA rule can be deployed in the following contexts:

• Microsoft Defender for Endpoint — Custom indicators / advanced hunting
• Email Gateway — Attachment scanning
• File Share Monitoring — Periodic scanning of shared drives
• YARA CLI — Manual threat hunting on endpoints

This rule contains 1 string patterns in its detection logic.

• Source Rule

False Positive Guidance

Here are 4 specific false positive scenarios for the “Web Shell - file server.php” detection rule, including suggested filters or exclusions:

• Scenario: Automated CMS Plugin Updates

  • Context: The enterprise uses a Content Management System (e.g., WordPress, Drupal, or Joomla) where the core update mechanism or third-party plugins (like WooCommerce or Yoast SEO) automatically deploy server.php files during scheduled maintenance windows to handle API routing or session management. These legitimate updates often trigger the rule because they involve new PHP file creation in web root directories.
  • Suggested Filter/Exclusion: Create a whitelist exclusion for specific file paths (e.g., /var/www/html/wp-content/plugins/*/server.php) and correlate alerts with the execution of known update tools like wp-cli or Jenkins build pipelines running during maintenance windows (02:00–04:00 UTC).

• Scenario: Load Balancer Health Checks

  • Context: Infrastructure teams deploy a reverse proxy (e.g., NGINX, HAProxy, or AWS ALB) that performs continuous health checks by requesting server.php to verify backend application availability. In some configurations, the load balancer may write a temporary server.php log or status file upon successful connection establishment, mimicking web shell creation behavior.
  • Suggested Filter/Exclusion: Exclude alerts where the source IP belongs to the internal Load Balancer subnet (e.g., 10.20.50.x) and the user agent string matches known health check identifiers (e.g., HealthCheck-Agent or kube-probe). Additionally, filter out files with a size under 2KB that are modified but not executed by a web server process.

• Scenario: DevOps CI/CD Deployment Pipelines

  • Context: During automated deployment cycles using tools like