What happens after a malicious JSP webshell is dropped into SAP NetWeaver Visual Composer?

A dropped webshell gives the attacker persistent command execution on the affected SAP NetWeaver Java server. That foothold can be used to run additional payloads, stage further tooling, and maintain access across sessions. The practical consequence is that the compromise moves from vulnerability exploitation to ongoing control of the host and any reachable internal resources.

From Initial JSP Upload to Ongoing Server Control

Once a malicious JSP webshell lands in SAP NetWeaver Visual Composer, the problem is no longer just a single exploited endpoint. The attacker can issue commands through the server context, execute follow-on payloads, and turn the application tier into a durable access point. In practice, that changes the incident from a one-time intrusion into an active foothold that can be reused for reconnaissance, lateral movement, and persistence.

The key security issue is that a webshell inherits the trust and reach of the compromised Java application environment. That often means the attacker can interact with local files, processes, application data, and internal network paths that were never intended to be reachable from the outside. For SAP environments, that is especially important because application compromise can expose sensitive business workflows and connected enterprise systems. In practice, many security teams encounter the real impact only after the webshell has already been used to stage additional tooling and preserve access.

What the Webshell Enables in the SAP Java Stack

A JSP webshell works because the server is willing to compile and run attacker-supplied code as part of the normal application runtime. After upload, the webshell usually acts as a command interface: the attacker sends requests, the server executes those commands, and the results are returned through the same web path. From there, the attacker can enumerate the host, inspect configuration files, search for credentials, and determine what other systems the SAP runtime can reach.

Operationally, the next steps usually fall into a small set of patterns. The attacker may drop a more stable payload, create alternate access paths, or use the webshell to launch commands that blend into legitimate server activity. They may also pivot into adjacent applications or backend services if the compromised SAP host has trust relationships, shared credentials, or network access that extends beyond the original web tier. If monitoring is weak, the webshell can remain hidden because its traffic resembles normal HTTP activity.

Command execution is usually the first durable capability, not the last.
File access can expose configuration, logs, and embedded secrets.
Network reach from the SAP host can turn a single compromise into internal discovery.
Persistence often comes from creating redundant access, not from the first shell alone.

If defenders only remove the uploaded file but do not understand what the attacker executed, what else was staged, and which internal resources were contacted, the guidance breaks down quickly.

Where the Compromise Tends to Spread and What Teams Miss

Tighter containment often increases operational friction, because teams have to balance service continuity against the need to isolate a business-critical SAP system. That tradeoff matters here because the compromised host may still be serving business traffic even while it is under attacker control. Where consensus is strongest is on the need to treat the webshell as a live compromise marker, not a simple file hygiene issue.

One common mistake is to focus on the malicious JSP itself and ignore the wider execution path. Another is to assume that deleting the file ends the incident. In reality, the attacker may already have created another entry point, modified configuration, or harvested credentials for later use. The more connected the SAP host is to internal resources, the more likely the compromise becomes a launch point for secondary activity. Guidance is less uniform on exact eradication sequencing across SAP landscapes, but there is broad agreement that persistence checks and trust-boundary review must happen before declaring recovery.

Useful external reference material on machine-controlled access abuse is summarised in the OWASP Non-Human Identity Top 10, which helps frame why embedded credentials and machine trust can widen post-exploitation impact.

Risk and Threat Considerations

The material risk is persistence, privilege abuse, and downstream internal exposure after an attacker gains code execution through the webshell. The threat is not limited to the original application server: once the attacker can run commands in the SAP Java runtime, they can often use that position to explore trust relationships, credentials, and reachable services.

Failure mechanism: The compromise becomes durable when the attacker can reuse the webshell, deploy a secondary payload, or pivot through stored secrets and trusted network paths. Detection often fails when defenders treat the shell as a static artefact instead of an active execution channel.

Impact: The attacker can maintain access across sessions, stage additional tools, and potentially reach internal systems or business data that were not exposed directly on the internet.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
MITRE ATT&CK	T1059.007 — Command and Scripting Interpreter: JavaScript	JSP webshells rely on server-side code execution in Java-based runtimes.
	T1505.003 — Server Software Component: Web Shell	A JSP webshell is the archetypal web shell persistence mechanism.
	T1105 — Ingress Tool Transfer	Attackers commonly use a webshell to stage additional payloads onto the server.
Recommendation — Hunt for server-side script execution and block unexpected Java execution paths. Detect webshell placement and remove attacker-controlled server-side components immediately. Monitor for outbound retrieval and staging activity after initial compromise.
NIST CSF 2.0	PR.AC — Access Control	Post-shell activity depends on controlling what the compromised server can access.
	DE.CM — Security Continuous Monitoring	Webshell traffic and follow-on command execution require strong detection coverage.
Recommendation — Restrict application and service access paths to limit post-exploitation reach. Correlate process, file, and network telemetry to spot active webshell use.
CIS Controls v8	8 — Audit Log Management	Incident response depends on logs showing commands, staging, and lateral activity.
	10 — Malware Defenses	Webshell deployment is a malware-like persistence and execution problem.
Recommendation — Retain and review server, application, and authentication logs for compromise traces. Use layered malware controls to detect and contain attacker-supplied web code.

Practitioner Guidance

What to prioritise: Treat the webshell as an active compromise of the SAP Java server, then work outward from the host to the application, authentication, and network paths it can reach. The first question is not whether the file still exists, but what commands were executed and what follow-on activity was already staged.

What to verify: Confirm whether the attacker created alternate persistence, modified startup artefacts, touched configuration files, or accessed credentials and logs. If the server had outbound reach into internal systems, validate those connections as part of containment rather than assuming the compromise stayed local.

What good looks like: Recovery only becomes credible when command execution is removed, persistence avenues are closed, and the trust relationships exposed by the SAP host have been reviewed. A clean file system alone is not enough evidence.

Practitioner takeaway: The decisive issue is not the upload itself but the attacker’s ability to turn a business application server into a reusable execution and pivot point.