Web Shell - file Java Shell.jsp

Hunt Hypothesis

This detection identifies adversaries deploying a malicious Shell.jsp web shell to establish persistent access and execute commands on compromised Java-based web servers within Azure Sentinel. Proactive hunting for this artifact is critical because web shells serve as a primary foothold for attackers to pivot laterally, exfiltrate sensitive data, or maintain long-term persistence while often evading standard perimeter defenses.

YARA Rule

rule webshell_Java_Shell {
	meta:
		description = "Web Shell - file Java Shell.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 = "36403bc776eb12e8b7cc0eb47c8aac83"
		id = "393e738a-b4c2-5630-a55f-c3caee4ff75e"
	strings:
		$s4 = "public JythonShell(int columns, int rows, int scrollback) {" fullword
		$s9 = "this(null, Py.getSystemState(), columns, rows, scrollback);" 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 2 string patterns in its detection logic.

• Source Rule

False Positive Guidance

Here are 5 specific false positive scenarios for the Web Shell - file Java Shell.jsp detection rule, including suggested filters and exclusions:

• Scenario: Automated Deployment via CI/CD Pipeline

  • Context: DevOps teams using tools like Jenkins, GitLab CI, or Azure DevOps frequently deploy standard Shell.jsp files as part of a release artifact to Tomcat or WebLogic servers. These deployments often occur during scheduled maintenance windows and involve the creation of new JSP files that match the rule’s signature but are legitimate code, not malicious shells.
  • Filter/Exclusion: Exclude file creations where the source process is a known CI/CD agent (e.g., jenkins-agent.exe, gitlab-runner) or where the user account is a dedicated service account (e.g., svc-deploy, ci-bot). Additionally, filter out events occurring within defined deployment windows (e.g., 02:00–04:00 UTC).

• Scenario: Scheduled Health Check and Monitoring Scripts

  • Context: Enterprise monitoring solutions like SolarWinds, Splunk Universal Forwarder, or custom Ansible playbooks often upload a lightweight Shell.jsp to the web root to act as an endpoint for health checks, log rotation triggers, or internal API status polling. These are recurring, scheduled tasks that generate the exact file pattern detected by the rule.
  • Filter/Exclusion: Create an exclusion based on the specific file path (e.g., /monitoring/status/Shell.jsp) and filter events where the source IP belongs to the internal monitoring subnet or the user context is a known service account (e.g., svc-monitor, ansible-runner).

• Scenario: Application Server Self-Configuration and Hot Deployment

  • Context: Java application servers such as **