Web Shell - file list.php

Hunt Hypothesis

This detection targets adversaries who deploy a malicious list.php web shell to establish a persistent foothold and execute commands on compromised web servers. Proactively hunting for this indicator in Azure Sentinel is critical because web shells often serve as an initial entry point for lateral movement, data exfiltration, or privilege escalation that may evade standard signature-based defenses.

YARA Rule

rule webshell_php_list {
	meta:
		description = "Web Shell - file list.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 = "922b128ddd90e1dc2f73088956c548ed"
		id = "393e738a-b4c2-5630-a55f-c3caee4ff75e"
	strings:
		$s1 = "// list.php = Directory & File Listing" fullword
		$s2 = "    echo \"( ) <a href=?file=\" . $fichero . \"/\" . $filename . \">\" . $filena"
		$s9 = "// by: The Dark Raver" fullword
	condition:
		1 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 3 string patterns in its detection logic.

• Source Rule

False Positive Guidance

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

• Scenario: CMS Admin Dashboard Initialization

  • Context: The list.php file is a standard component of popular Content Management Systems (CMS) like WordPress, Joomla, or custom internal portals. It is frequently accessed by the system itself during dashboard load, user listing views, and plugin initialization scripts.
  • Filter/Exclusion: Create an exclusion based on the User-Agent string containing known CMS identifiers (e.g., WordPress, Joomla) or exclude requests originating from internal IP ranges assigned to the web server cluster where the CMS is hosted.

• Scenario: Scheduled Inventory Reporting Job

  • Context: An automated nightly job using Cron (Linux) or Task Scheduler (Windows Server) runs a script that queries list.php to generate inventory reports for the supply chain team. This triggers the rule every morning at 02:00 AM regardless of user interaction.
  • Filter/Exclusion: Implement a time-based filter excluding alerts generated between 01:30 and 04:00 on weekdays, or add an exclusion for the specific service account (e.g., svc-inventory-report) executing the job.

• Scenario: Third-Party Integration Health Checks

  • Context: External monitoring tools like Datadog, New Relic, or Pingdom perform synthetic transactions to verify API endpoint availability. These tools often hit the /list.php endpoint as a “heartbeat” check, triggering the rule due to the file name matching the web shell pattern.
  • Filter/Exclusion: Exclude traffic where the source IP belongs to known monitoring provider ranges (e.g.,