Web Shell - file 01.asp

Hunt Hypothesis

This hunt hypothesis targets adversaries who establish persistent remote code execution capabilities by deploying a malicious ASP web shell named 01.asp to compromise server environments. Proactive hunting for this specific artifact in Azure Sentinel is critical because web shells often serve as an initial foothold for attackers, enabling them to execute arbitrary commands and maintain stealthy access before broader detection occurs.

YARA Rule

rule webshell_asp_01 {
	meta:
		description = "Web Shell - file 01.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 = 50
		hash = "61a687b0bea0ef97224c7bd2df118b87"
		id = "393e738a-b4c2-5630-a55f-c3caee4ff75e"
	strings:
		$s0 = "<%eval request(\"pass\")%>" 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 01.asp detection rule, including suggested filters and exclusions:

• Legacy Inventory Management System Deployment

  • Scenario: The enterprise’s legacy inventory system (running on IIS) utilizes a standardized naming convention where new module updates are packaged as 01.asp within the /Inventory/Modules directory. This file is automatically deployed by the nightly CI/CD pipeline using Azure DevOps, creating a legitimate file that matches the YARA signature exactly.
  • Filter/Exclusion: Configure the EDR (e.g., Microsoft Defender for Endpoint or CrowdStrike) to exclude files matching C:\inetpub\wwwroot\Inventory\Modules\01.asp from web shell detection logic. Additionally, whitelist the specific hash of this known good file in the YARA rule’s exclusion list.

• Automated Reporting Dashboard Refresh

  • Scenario: A scheduled SQL Server Agent job triggers a PowerShell script every morning at 06:00 to generate dynamic financial reports. The script dynamically creates a temporary ASP handler named 01.asp in the /Reports/Temp folder to render charts before deleting it after processing. This transient creation triggers the rule during peak business hours.
  • Filter/Exclusion: Implement a time-based exclusion window (e.g., 05:30–07:30) for alerts originating from the C:\inetpub\wwwroot\Reports\Temp directory. Alternatively, add a YARA condition to exclude files where the file age is less than 1 hour and the parent process is identified as sqlagent.exe.

• Third-Party CRM Integration Module

  • Scenario: The organization uses a third-party CRM (e.g., Salesforce or Dynamics 365) that installs a connector module. During the