Web Shell - file 404.php

Hunt Hypothesis

This detection identifies adversaries establishing a web shell named “404.php” to maintain persistent access and execute commands on compromised web servers. Proactive hunting for this specific artifact in Azure Sentinel is critical because attackers often disguise malicious shells as standard error pages to evade routine monitoring while enabling lateral movement and data exfiltration.

YARA Rule

rule webshell_caidao_shell_404 {
	meta:
		description = "Web Shell - file 404.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 = 70
		hash = "ee94952dc53d9a29bdf4ece54c7a7aa7"
		id = "393e738a-b4c2-5630-a55f-c3caee4ff75e"
	strings:
		$s0 = "<?php $K=sTr_RepLaCe('`','','a`s`s`e`r`t');$M=$_POST[ice];IF($M==NuLl)HeaDeR('St"
	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 4 string patterns in its detection logic.

• Source Rule

False Positive Guidance

Here are 5 specific false positive scenarios for the Web Shell - file 404.php detection rule, including suggested filters and exclusions:

• Scenario: Automated Health Check by Load Balancer

  • Context: Enterprise load balancers (e.g., F5 BIG-IP, NGINX Plus, or AWS ALB) often perform continuous health checks against web endpoints. If the configuration uses a specific path named 404.php as a lightweight heartbeat endpoint, the system may interpret this legitimate file access as a suspicious web shell creation or execution attempt.
  • Suggested Filter: Exclude traffic originating from internal load balancer IP ranges where the HTTP User-Agent header contains strings like “F5-BIG-IP”, “NGINX”, or “ELB-HealthCheck”.

• Scenario: Scheduled Backup and Integrity Verification

  • Context: Internal backup solutions (e.g., Veeam, Rubrik, or custom Ansible playbooks) often run nightly jobs to verify the existence of critical web files. A scheduled job might explicitly query 404.php to confirm the web server’s file system integrity before archiving, triggering a “file creation/access” alert that mimics a shell upload.
  • Suggested Filter: Create an exclusion for events occurring during maintenance windows (e.g., 02:00–04:00 UTC) where the source process name matches known backup agents or orchestration tools like ansible-runner or veeam-agent.

• Scenario: CI/CD Pipeline Deployment Artifacts

  • Context: During automated deployments via Jenkins, GitLab CI, or Azure DevOps, the deployment pipeline often pushes a standard set of error pages to the web root. The file 404.php is frequently part of