Web Shell - file cmd.asp

Hunt Hypothesis

This detection rule identifies adversaries who have deployed a malicious web shell named cmd.asp to establish a persistent foothold and execute arbitrary commands on compromised web servers. Proactively hunting for this specific artifact in Azure Sentinel is critical because web shells often serve as the initial entry point for lateral movement and data exfiltration, allowing attackers to maintain stealthy access before broader network defenses are triggered.

YARA Rule

rule webshell_asp_cmd {
	meta:
		description = "Web Shell - file cmd.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 = "895ca846858c315a3ff8daa7c55b3119"
		id = "393e738a-b4c2-5630-a55f-c3caee4ff75e"
	strings:
		$s0 = "<%= \"\\\\\" & oScriptNet.ComputerName & \"\\\" & oScriptNet.UserName %>" fullword
		$s1 = "Set oFileSys = Server.CreateObject(\"Scripting.FileSystemObject\")" fullword
		$s3 = "Call oScript.Run (\"cmd.exe /c \" & szCMD & \" > \" & szTempFile, 0, True)" 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 cmd.asp detection rule, including suggested filters and exclusions tailored for an enterprise environment:

• Scheduled Backup or Health Check Scripts

  • Scenario: Enterprise backup solutions (e.g., Veeam, Rubrik) or custom monitoring scripts often deploy lightweight ASP files to the web root (/inetpub/wwwroot) to verify connectivity or trigger health checks. A script named cmd.asp might be created by a nightly maintenance job to log server status, triggering the rule due to its generic name and location within the IIS directory.
  • Filter/Exclusion: Create an exclusion based on the File Creation Time (e.g., exclude files created between 01:00–05:00 UTC) combined with a Source User filter for known service accounts like NT SERVICE\VeeamBackup or DOMAIN\HealthCheckSvc.

• Legacy Application Deployment via CI/CD Pipelines

  • Scenario: A DevOps pipeline (e.g., Azure DevOps, Jenkins) deploys a legacy internal tool that relies on an ASP.NET framework. The deployment process automatically writes a standard utility file named cmd.asp to the application’s virtual directory to handle command-line parameter parsing for the frontend, which matches the rule’s signature exactly.
  • Filter/Exclusion: Exclude files where the Parent Process is a known CI/CD agent (e.g., msbuild.exe, OctopusDeploy.exe, or AzureDevOpsAgent) and the file path contains specific application folders like \LegacyApp\bin\ rather than the root web directory.

• Third-Party Plugin Installation by Admins

  • Scenario: An administrator manually installs a third-party reporting plugin (e.g., from **Microsoft Dynamics