Observable signs include unexpected WAR uploads, the appearance of web shell files such as JSP-based implants, followed by shell scripts and binary payloads being dropped and executed. In the article’s attack, the operator also tried to erase command history, which is a strong defense evasion signal. Those behaviors together indicate legitimate admin activity has been abused.
How to Recognize Tomcat Compromise While It Is Still Active
A Tomcat compromise in progress usually shows up as activity that looks like application deployment, but does not behave like normal administration. The key clue is a chain of file and execution events, not a single artifact. Once one abnormal upload, dropper, or web-accessible implant appears, the attacker usually tries to turn that foothold into repeatable command execution.
What the Runtime Artifact Pattern Usually Looks Like
The first sign is often a new or unexpected WAR landing in a deployment path or upload location that should not be receiving code from an untrusted source. That may be followed by JSP-based web shells or other files that can execute server-side commands. In practical terms, the compromise becomes visible when Tomcat starts serving content that behaves like an interactive control surface instead of an application page.
The next stage is usually post-exploitation staging. Attackers often drop shell scripts, binary payloads, or small helper tools once they have command execution, because the initial web shell is rarely the final objective. If you see a short-lived file appear, get executed, and disappear, that is more consistent with intrusion activity than with routine application behavior.
Command-history tampering is another important runtime signal. When an operator tries to clear shell history or suppress logs, they are usually trying to reduce visibility after interactive access has already been achieved. That behavior matters because it shifts the assessment from a suspicious upload to an active compromise with defense evasion in progress.
Why These Signs Matter for Incident Triage
A Tomcat compromise is not just about an unexpected file on disk. It is about whether the server has crossed from normal application execution into attacker-controlled execution. At that point, the important questions are whether the attacker can re-enter, whether the implant is web reachable, and whether the host has already been used to stage additional tooling or lateral movement.
For that reason, runtime signs should be read as a sequence. Uploaded WAR, executable web shell, secondary payload drop, and history wiping together indicate an active abuse path, not a static misconfiguration. The more of those behaviors you can correlate in one time window, the stronger the case that the server is under live control rather than merely exposed.
Risk and Threat Considerations
Tomcat runtime compromise is risky because it can blend legitimate application activity with adversary execution, which makes the attacker hard to distinguish from normal operators. The most dangerous condition is when the web tier can write and execute in the same path, because that turns a routine deployment surface into a durable access path.
Failure mechanism: The attacker gains server-side execution through an uploaded or dropped web-accessible artifact, then uses that foothold to stage additional tools, conceal activity, and maintain control.
Impact: Expect code execution, credential or secret exposure, persistence, and possible movement into adjacent services if the compromised host has trusted access beyond the web server.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5, CIS Controls v8 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1505.003 — Web Shell | Tomcat web shells are a classic server-side persistence and execution pattern. |
| T1059 — Command and Scripting Interpreter | Dropped shell scripts and binary launch activity indicate command execution after foothold. | |
| T1070.003 — Clear Command History | History erasure is explicit defense evasion and often follows interactive compromise. | |
| Recommendation — Map suspicious JSP artifacts to T1505.003 and hunt for post-exploitation activity. Correlate script and interpreter execution with the initial web-access event. Treat command-history clearing as a high-confidence evasion indicator and scope the session. | ||
| NIST SP 800-53 Rev 5 | SI-4 — System Monitoring | Runtime compromise signs depend on detecting anomalous execution and file activity. |
| AU-12 — Audit Generation | You need logs that preserve web-tier actions, file writes, and command traces. | |
| CM-7 — Least Functionality | Unexpected WAR upload paths and executable write locations reflect excessive runtime capability. | |
| Recommendation — Monitor for unexpected uploads, executions, and tampering on the Tomcat host. Ensure Tomcat and host audit sources capture deploy, write, and execution events. Restrict writable and executable paths so web content cannot become a code-drop surface. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | History wiping and staging behavior are only visible if logs and command traces are retained. |
| Recommendation — Centralize and protect logs so tampering and post-compromise actions remain visible. | ||
| OWASP ASVS | V15 — Secure Coding and Architecture | The underlying issue is unsafe deployment and execution architecture in the web application path. |
| Recommendation — Review deployment architecture so uploaded content cannot become executable server-side code. | ||
Practitioner Guidance
What to verify: Treat any unexpected WAR or JSP in a writable Tomcat path as evidence to confirm, not a harmless anomaly. Check whether the file was introduced through a normal deployment pipeline, whether the timestamp matches a change window, and whether the process that wrote it should have had that privilege in the first place.
Decision rule: If the file is web reachable and can execute commands, prioritize containment over curiosity. Preserve volatile evidence, block further execution paths, and look for follow-on drops, outbound callbacks, and history or log tampering before you spend time on root-cause theory.
Practitioner takeaway: The operational signal is not just “a suspicious file exists”, it is “the server is now behaving like an attacker runtime.” Once that pattern appears, assume the host may already be a staging point for deeper compromise.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 25, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
