Web Shell - file MySQL Web Interface Version 0.8.php

Hunt Hypothesis

This detection identifies the deployment of a malicious web shell disguised as a MySQL interface version 0.8.php, which adversaries often use to establish persistence and execute arbitrary commands on compromised web servers. Proactive hunting for this artifact in Azure Sentinel is critical because web shells frequently evade standard signature-based defenses by mimicking legitimate application files, allowing attackers to maintain covert access to sensitive data and internal networks.

YARA Rule

rule webshell_MySQL_Web_Interface_Version_0_8 {
	meta:
		description = "Web Shell - file MySQL Web Interface Version 0.8.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 = "36d4f34d0a22080f47bb1cb94107c60f"
		id = "393e738a-b4c2-5630-a55f-c3caee4ff75e"
	strings:
		$s2 = "href='$PHP_SELF?action=dumpTable&dbname=$dbname&tablename=$tablename'>Dump</a>"
	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 specific false positive scenarios for the Web Shell - file MySQL Web Interface Version 0.8.php detection rule, along with recommended filters and exclusions:

• Scenario: Automated Backup Script Execution

  • Context: A nightly maintenance job scheduled via Windows Task Scheduler or a Cron job on a Linux server executes a custom Python script using requests library to verify database connectivity. The script uploads the standard 0.8.php interface file to a temporary staging directory (/var/www/html/maintenance) before running a health check query against the MySQL instance.
  • Filter/Exclusion: Create an exclusion rule based on the source IP address of the backup server (e.g., 192.168.10.55) and restrict the detection to the specific staging directory path (*maintenance*). Alternatively, exclude events occurring during the defined maintenance window (e.g., 02:00–04:00 UTC daily).

• Scenario: Developer CI/CD Pipeline Deployment

  • Context: The Jenkins or GitLab CI pipeline triggers a deployment for a new microservice. As part of the “Post-Deployment Verification” stage, the automation tool (e.g., Ansible running on the build agent) deploys the 0.8.php file to the web root (/opt/webapp/public) to allow QA engineers to manually verify database connection strings before promoting the build to production.
  • Filter/Exclusion: Filter out alerts where the user identity matches known service accounts (e.g., svc-deploy, jenkins-bot) and the file creation timestamp aligns with active pipeline run IDs. Exclude files created within the specific deployment directory structure (*/deployments/*).

• **Scenario: Third-Party Monitoring Agent Installation