Web Shell - file 2.php

Hunt Hypothesis

This detection identifies adversaries establishing a persistent web shell named “2.php” to execute arbitrary commands and maintain access within a compromised web server environment. Proactive hunting for this specific artifact in Azure Sentinel is critical because web shells often serve as an initial foothold for lateral movement and data exfiltration, requiring immediate investigation before the adversary can expand their presence.

YARA Rule

rule webshell_php_2 {
	meta:
		description = "Web Shell - file 2.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 = "267c37c3a285a84f541066fc5b3c1747"
		id = "393e738a-b4c2-5630-a55f-c3caee4ff75e"
	strings:
		$s0 = "<?php assert($_REQUEST[\"c\"]);?> " 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 5 specific false positive scenarios for the Web Shell - file 2.php detection rule, including context and recommended filters:

• Scheduled Backup or Migration Scripts

  • Scenario: An automated nightly backup job (e.g., using Veeam or a custom Python/Bash script) temporarily creates a staging file named 2.php in the web root to aggregate logs before archiving. The file exists briefly and is deleted immediately after processing, mimicking a transient web shell deployment.
  • Filter/Exclusion: Exclude files created by specific service accounts (e.g., svc-backup, system) or filter out events where the file creation timestamp falls within the defined maintenance window (e.g., 02:00–04:00 UTC).

• CI/CD Pipeline Deployment Artifacts

  • Scenario: During a continuous integration deployment using Jenkins or GitLab CI, the build agent deploys a temporary test file named 2.php to verify configuration changes or run smoke tests before the final release. This is often part of an automated “staging” phase rather than manual user intervention.
  • Filter/Exclusion: Create an exclusion rule for file creations originating from IP addresses belonging to the CI/CD server range (e.g., 10.20.50.x) or exclude events where the process name matches known deployment tools like jenkins-agent.exe or gitlab-runner.

• Third-Party Plugin Installation

  • Scenario: An administrator installs a new module for a CMS (e.g., WordPress, Drupal, or Joomla) via the admin dashboard. The plugin installer automatically generates a helper file named 2.php in the /wp-content/plugins/ directory to handle initial configuration or database schema updates.