Web Shell - file sys3.jsp

Hunt Hypothesis

This detection identifies adversaries deploying a malicious web shell named sys3.jsp to establish persistent access and execute commands on compromised web servers. A proactive hunt is essential in Azure Sentinel to uncover hidden post-exploitation activities that evade standard signature-based alerts, ensuring early identification of potential lateral movement or data exfiltration attempts.

YARA Rule

rule webshell_jsp_sys3 {
	meta:
		description = "Web Shell - file sys3.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 = "b3028a854d07674f4d8a9cf2fb6137ec"
		id = "393e738a-b4c2-5630-a55f-c3caee4ff75e"
	strings:
		$s1 = "<input type=\"submit\" name=\"btnSubmit\" value=\"Upload\">" fullword
		$s4 = "String path=new String(request.getParameter(\"path\").getBytes(\"ISO-8859-1\""
		$s9 = "<%@page contentType=\"text/html;charset=gb2312\"%>" 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 5 specific false positive scenarios for the Web Shell - file sys3.jsp detection rule, along with recommended filters or exclusions:

• Scenario: Automated Deployment via CI/CD Pipeline

  • Context: A DevOps team uses Jenkins or GitLab CI to deploy a new version of an enterprise application. The deployment script automatically copies the sys3.jsp file (a standard utility component) into the web root directory (/webapps/app/sys3.jsp) during the nightly build process.
  • Filter/Exclusion: Create an exclusion rule that ignores alerts where the source IP belongs to the CI/CD server subnet (e.g., 10.20.50.x) and the file creation/modification timestamp aligns with the scheduled deployment window (e.g., 02:00–04:00 UTC).

• Scenario: Scheduled Backup Utility Execution

  • Context: The enterprise runs a nightly backup job using Veeam or Commvault. As part of the pre-backup verification routine, the agent writes a temporary status file named sys3.jsp to the web server’s staging directory before archiving. This mimics the behavior of a web shell being dropped by an attacker.
  • Filter/Exclusion: Exclude events where the process name is the backup agent executable (e.g., vcagent.exe, vbrsvc.exe) and the file path contains specific keywords like /staging or /temp.

• Scenario: Application Health Check by Load Balancer

  • Context: An F5 BIG-IP load balancer or AWS Elastic Load Balancer (ELB) performs active health checks against web servers. The check script occasionally triggers a request that causes the application server to generate a temporary sys3.jsp log