Web Shell - file 404.asp

Hunt Hypothesis

This detection identifies adversaries establishing a web shell by creating an anomalous “404.asp” file, which often serves as a covert entry point for remote command execution and lateral movement within compromised web servers. Proactively hunting for this specific artifact in Azure Sentinel is critical to rapidly identify and neutralize persistent threats that leverage standard error pages to mask malicious activity before they escalate into broader network compromises.

YARA Rule

rule webshell_asp_404 {
	meta:
		description = "Web Shell - file 404.asp"
		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 = "d9fa1e8513dbf59fa5d130f389032a2d"
		id = "393e738a-b4c2-5630-a55f-c3caee4ff75e"
	strings:
		$s0 = "lFyw6pd^DKV^4CDRWmmnO1GVKDl:y& f+2"
	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 404.asp detection rule, including actionable filters and exclusions:

• Scheduled Backup of Custom Error Pages

  • Scenario: The enterprise backup solution (e.g., Veeam or Commvault) performs a nightly incremental backup that includes the IIS root directory. During this process, the backup agent temporarily creates a placeholder or staging file named 404.asp in the web content folder before archiving it, triggering the rule due to the file’s sudden appearance and subsequent modification.
  • Filter/Exclusion: Exclude processes running under the specific backup service account (e.g., NT SERVICE\VeeamTransportService) or filter out events where the source IP belongs to the internal backup server subnet (e.g., 10.20.50.x).

• Automated Deployment via CI/CD Pipeline

  • Scenario: A DevOps team utilizes Azure DevOps or Jenkins pipelines to deploy updated error handling templates. The deployment script explicitly copies a standard 404.asp template from an artifact repository into the production web root (C:\inetpub\wwwroot) as part of the release workflow, which is misidentified as a new shell upload by an unknown user.
  • Filter/Exclusion: Create an exclusion for files created or modified by the deployment service account (e.g., DOMAIN\CICD-Deployer) and restrict alerts to only trigger if the file hash does not match the known “golden” hash of the standard 404 template stored in the configuration management database.

• IIS Health Monitoring & Probing

  • Scenario: The internal load balancer (e.g., F5 or AWS ALB) performs continuous health checks against web nodes. As part of a dynamic routing test, the monitoring script occasionally