Web Shell - file list.jsp

Hunt Hypothesis

This rule detects adversaries who deploy a list.jsp web shell to enumerate directory contents and establish a persistent foothold on compromised web servers. A proactive hunt is essential in Azure Sentinel because this specific artifact often serves as an early indicator of post-exploitation activity, allowing the SOC team to identify lateral movement before attackers escalate privileges or exfiltrate sensitive data.

YARA Rule

rule webshell_jsp_list {
	meta:
		description = "Web Shell - file list.jsp"
		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 = "1ea290ff4259dcaeb680cec992738eda"
		id = "393e738a-b4c2-5630-a55f-c3caee4ff75e"
	strings:
		$s0 = "<FORM METHOD=\"POST\" NAME=\"myform\" ACTION=\"\">" fullword
		$s2 = "out.print(\") <A Style='Color: \" + fcolor.toString() + \";' HRef='?file=\" + fn"
		$s7 = "if(flist[i].canRead() == true) out.print(\"r\" ); else out.print(\"-\");" 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 3 string patterns in its detection logic.

• Source Rule

False Positive Guidance

Here are 4 specific false positive scenarios for the Web Shell - file list.jsp detection rule, including suggested filters and exclusions tailored for an enterprise environment:

• Scenario: Legitimate Deployment via CI/CD Pipeline

  • Context: Automated deployment tools (e.g., Jenkins, GitLab CI, or Azure DevOps) frequently push updated web artifacts to the application server. During a standard release window, the pipeline may deploy a list.jsp file as part of a new module or update an existing inventory page used by internal stakeholders.
  • Filter/Exclusion: Create an exclusion rule based on the source identity (e.g., ProcessName == "jenkins-agent.exe" or SourceIP in [10.20.5.1-10.20.5.10]) and restrict the alert to occur only during defined maintenance windows (e.g., 02:00–04:00 UTC).

• Scenario: Scheduled Backup or Reporting Job

  • Context: Enterprise monitoring suites like Splunk, Datadog, or custom internal scripts often run nightly jobs that generate a list.jsp file to display server status, log summaries, or asset inventories. These jobs are triggered by the OS scheduler (Windows Task Scheduler or Linux Cron) rather than user interaction.
  • Filter/Exclusion: Exclude events where the user account matches known service accounts (e.g., User == "svc-backup", User == "system"). Additionally, filter out files created with a specific naming convention suffix if applicable (e.g., FileName endsWith "_report.jsp"), or exclude based on the file’s creation timestamp falling within the scheduled job window.

• Scenario: Admin Manual Maintenance and Debugging

  • Context: System administrators often manually upload diagnostic tools