What are the signs that Tomcat has already been compromised by a web shell campaign?

Common signs include unexpected JSP files, binary drift, deleted or replaced files, unusual outbound connections, and processes masquerading as system or kernel tasks. You may also see cryptomining traffic, repeated file copies into manager, ROOT, or docs paths, and audit events tied to unpacking or privilege changes. These indicators point to active post-exploitation activity.

Why This Matters for Security Teams

A Tomcat web shell campaign is rarely just a file-level issue. Once an attacker can write JSP content into a deployed application path, the server can become a staging point for credential theft, lateral movement, payload retrieval, and cryptomining. The operational risk is that normal application behaviour can continue while the attacker uses the same host for remote command execution and persistence. Guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because it reinforces integrity monitoring, audit logging, and controlled configuration change as core defensive expectations.

Security teams often miss early compromise because they focus on the initial exploit vector rather than the post-exploitation footprint. The strongest signals are usually integrity drift, unexpected executable content in web roots, and outbound traffic that does not match the application’s normal role. In practice, many security teams encounter web shell compromise only after file integrity alerts, unusual process trees, or cloud bill spikes reveal activity that had already been running for days.

How It Works in Practice

Detecting a compromised Tomcat server means correlating file, process, network, and authentication evidence. A single suspicious JSP file may be enough to justify investigation, but the broader picture is what distinguishes a one-off deployment mistake from active compromise. Attackers often place web shells in manager, ROOT, or docs directories because those paths are commonly reachable and less likely to be scrutinised after deployment.

Look for the mechanics of persistence and execution:

• Unexpected JSP, WAR, or script files appearing outside normal release workflows.
• Files with recent timestamps but unrelated ownership, permissions, or naming conventions.
• New child processes spawned by the Tomcat service account that do not match application behaviour.
• Outbound connections to IPs, domains, or ports not used by the application, especially for command-and-control or payload retrieval.
• Evidence of archive unpacking, privilege escalation attempts, or repeated copying into web-accessible folders.

Defenders should also check whether file integrity monitoring, EDR, and application logs tell the same story. A web shell often leaves a small but coherent trail: a file write, a web request that executes a command, and then a follow-on connection or download. That makes correlation more valuable than any single indicator. When available, align investigation steps with memory capture, immutable log review, and restoration from known-good artifacts rather than trying to “clean” the existing installation in place.

For readers mapping this to a broader intrusion pattern, the Anthropic — first AI-orchestrated cyber espionage campaign report is relevant as a reminder that modern intrusion tradecraft increasingly combines automation, reconnaissance, and rapid follow-on action once a foothold is gained. These controls tend to break down when Tomcat runs with broad write access to its own deployment directories and application logging is too sparse to reconstruct the request sequence.

Common Variations and Edge Cases

Tighter monitoring often increases operational noise and review overhead, requiring organisations to balance fast detection against the cost of chasing benign deployment changes. That tradeoff matters because Tomcat environments vary widely across development, staging, and production, and not every unexpected JSP is malicious.

There is no universal standard for this yet, but current guidance suggests treating the following as higher-risk edge cases:

• Frequent redeployments that make normal file drift hard to distinguish from attacker activity.
• Shared host or container environments where process lineage is obscured by orchestration layers.
• Legacy applications that legitimately write into web-accessible directories and therefore reduce the value of file-path heuristics alone.
• Servers with weak audit logging, where the compromise is visible only through network egress or downstream abuse.

In containerised deployments, compromise may show up as modified image layers, mounted volumes, or runtime changes that do not persist in the container filesystem after restart. In cloud environments, defenders should also check whether metadata access, secret retrieval, or identity misuse is occurring alongside the web shell activity, because the web shell is often only one step in a larger intrusion chain. The most reliable approach is to compare expected deployment behaviour against actual runtime behaviour and escalate any unexplained divergence quickly.

Related resources from NHI Mgmt Group

• How should organisations respond when a supplier has already been compromised?
• Why do compromised-password checks matter if MFA is already deployed?
• Who should own response when an AI-driven fraud campaign uses compromised credentials?
• Why do shorter certificate lifetimes improve security if keys are not already compromised?