Common signs include unexpected JSP files in the Visual Composer directories, suspicious shell history showing curl, wget, or piped bash execution, and signs of second-stage payloads. If attackers use tunneling services or deploy webshells such as helper.jsp or cache.jsp, that often indicates active post-exploitation activity rather than a failed scan or harmless probe.
Why SAP NetWeaver Visual Composer activity deserves immediate triage
When signs of SAP NetWeaver Visual Composer exploitation appear, the question is no longer whether an exposure exists but whether an attacker has moved beyond initial access into staging, persistence, or follow-on execution. For defenders, that changes the priority from patch validation to containment, evidence preservation, and scope assessment. This is especially important because web-facing application compromise often leaves only a narrow window before attackers add a webshell, fetch payloads, or pivot into adjacent SAP functions. For control context, the general hardening and monitoring expectations in NIST SP 800-53 Rev 5 Security and Privacy Controls remain relevant for logging, access monitoring, and incident response discipline. In practice, many security teams recognise this pattern only after the attacker has already used the initial foothold to prove command execution and stage a second toolset.
How exploitation usually shows up in the environment
Visual Composer exploitation tends to become visible through artifacts that are hard to explain as normal application behaviour. Unexpected JSP creation inside Visual Composer-related directories is one of the strongest clues because JSP files are a common way to turn a web application weakness into server-side execution. Once that happens, attackers often move quickly to lightweight command execution and payload retrieval, which is why shell history containing curl, wget, or piped shell commands matters. Those commands are not proof by themselves, but in this context they often show the handoff from exploit to interactive control.
Teams should also look for second-stage indicators that suggest the intrusion is already operational. That can include webshells, follow-on tooling, unusual outbound connections to staging hosts, or tunneling services used to conceal interactive access. If the environment shows both file-system changes and command-history evidence, the event should be treated as active compromise rather than a transient probe. The most useful response sequence is to preserve volatile evidence first, then identify the affected application tier, then determine whether the same pattern appears on other SAP nodes or internet-facing systems.
- Check for JSP or other unexpected executable files in Visual Composer paths.
- Correlate web-server logs, shell history, and process creation around the same time window.
- Inspect outbound connections for staging servers, tunneling relays, or unusual low-volume beaconing.
- Look for follow-on artifacts such as webshells, new admin activity, or changes outside normal deployment windows.
This guidance breaks down when defenders only have partial logging or delayed file integrity visibility, because the strongest signs may already have been overwritten by attacker cleanup.
Common patterns that can be mistaken for a false alarm
Tighter suspicion thresholds often increase investigation overhead, so teams need to balance noise reduction against the cost of missing a live intrusion. Not every suspicious file is malicious, and not every command-history artifact proves compromise, which is why context is essential. A JSP file may be legitimate in a managed deployment process, and a troubleshooting command may resemble attacker tooling. The difference is usually whether the artifact fits an approved change path, an expected maintenance window, and a known operator identity.
Guidance versus consensus is important here: there is broad agreement that unexpected executable web content and post-exploitation tooling are serious, but there is no single universal indicator set that proves exploitation across every SAP landscape. In practice, defenders should treat the combination of internet-facing exposure, unusual file creation, shell execution, and outbound staging as materially stronger than any one signal alone. If only one weak signal exists, corroborate it with logs and change records before escalating to full incident response.
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 CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1505.003 — Web Shell | Visual Composer exploitation often ends in webshell deployment. |
| Recommendation — Hunt for webshell artifacts and correlate them with inbound exploit activity. | ||
| CIS Controls v8 | 8 — Audit Log Management | Exploit signs are confirmed by web, host, and command-history evidence. |
| 17 — Incident Response Management | Suspected exploitation requires containment and evidence preservation. | |
| Recommendation — Centralise and retain logs so you can correlate file creation, shell activity, and outbound staging. Escalate to incident response and preserve volatile evidence before making disruptive changes. | ||
| NIST CSF 2.0 | DE.AE — Anomalies and Events | Suspicious files and command execution are anomaly signals requiring triage. |
| RS.AN — Analysis | The question is about recognising active exploitation and confirming scope. | |
| Recommendation — Triage anomalous file, process, and network activity as potential compromise. Analyze correlated indicators to determine whether exploitation is active and how far it has spread. | ||
Practitioner Guidance
What to prioritise: Treat the first priority as confirming whether attacker-controlled execution has already occurred, not as proving the exploit source. If there is evidence of JSP creation plus command execution plus outbound staging, assume the incident is active until proven otherwise.
What to verify: Verify whether each suspicious artifact has a legitimate deployment explanation, an approved change ticket, and a matching maintenance window. If any one of those is missing, the burden of proof shifts toward compromise rather than benign administration.
Escalation / exception: Escalate immediately when you see webshell-style filenames, unexpected executable files in application directories, or tunneling behaviour tied to the same host. Those combinations indicate the attacker may already have stable access and the window for low-disruption containment is closing.
Practitioner takeaway: The most important judgment is whether the environment shows isolated suspicion or a chained sequence of exploit, execution, and staging. Once the signs line up into a sequence, the question changes from "is this real?" to "how far has it spread?"
Related resources from NHI Mgmt Group
- What breaks when SAP NetWeaver Visual Composer is exposed to unauthenticated upload abuse?
- What are the signs that PHP-CGI exploitation is already underway on a server?
- What are the signs that cloud compute defense evasion is already underway?
- What are the signs that credential stuffing is already underway in an environment?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 10, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
