Web Shell - file up.jsp

Hunt Hypothesis

This detection identifies adversaries deploying a malicious JSP web shell named “up.jsp” to establish a persistent foothold and execute arbitrary commands on compromised web servers. Proactive hunting for this artifact in Azure Sentinel is critical because web shells often serve as an initial entry point for lateral movement and data exfiltration, requiring immediate containment before attackers can expand their presence within the environment.

YARA Rule

rule webshell_jsp_up {
	meta:
		description = "Web Shell - file up.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 = "515a5dd86fe48f673b72422cccf5a585"
		id = "393e738a-b4c2-5630-a55f-c3caee4ff75e"
	strings:
		$s9 = "// BUG: Corta el fichero si es mayor de 640Ks" 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 up.jsp detection rule, including suggested filters and exclusions tailored for an enterprise environment:

• Scenario: Scheduled Backup or Deployment Scripts

  • Context: Automated deployment pipelines (e.g., Jenkins, GitLab CI) or nightly backup jobs often upload a standard up.jsp utility to the web root (/webapps) to verify connectivity or trigger post-deployment health checks. These scripts are legitimate and run on a fixed schedule rather than via user interaction.
  • Filter/Exclusion: Create an exclusion based on the Source IP of the CI/CD server (e.g., 10.20.5.15) or filter events where the Process Name is java running under a specific service account (e.g., svc-deploy). Additionally, exclude files created during maintenance windows (e.g., 02:00–04:00 UTC).

• Scenario: Vendor Support Portal Updates

  • Context: Third-party vendors (such as Salesforce, ServiceNow, or SAP) often push updates to the enterprise web server that include a generic up.jsp file for their specific module integration. These files are part of standard patching cycles and not indicative of an attacker uploading a malicious shell.
  • Filter/Exclusion: Implement a filter excluding events where the User Agent string contains known vendor identifiers (e.g., Salesforce-Connector, SAP-Updater) or exclude file creation paths under specific vendor directories (e.g., /webapps/vendor-modules/*).

• Scenario: Internal Admin Maintenance Tasks

  • Context: System administrators frequently manually upload the up.jsp file to test new Tomcat configurations, update JSP libraries, or troubleshoot application errors. This is a common “ad