An Analysis of Brute-Force: The Coordinated Brute-Force Campaign Targeting Apache Tomcat Manager Interfaces

Background

In mid-2025, a significant, coordinated brute-force campaign targeted exposed Apache Tomcat Manager interfaces, signifying a strategic pivot by threat actors toward this ubiquitous web service. The analysis identified 295 unique malicious IP addresses systematically attempting to gain unauthorized access, with attack origins primarily concentrated in the United States, United Kingdom, Germany, the Netherlands, and Singapore [1]. This article presents a comprehensive analysis of the attack campaign, provides a root cause analysis of underlying security deficiencies, details real-world exploitation scenarios, and offers actionable mitigation strategies. The findings underscore the imperative for organizations to move beyond default configurations and implement a defense-in-depth security architecture for their Tomcat deployments [5]. This campaign critically illustrates how attackers successfully weaponize well-documented attack vectors at scale when foundational security hygiene is deficient [6].

1. Introduction

Apache Tomcat is a foundational component in the technology stack of numerous global enterprises, functioning as one of the most prevalent open-source Java servlet containers [7]. Its stability, flexibility, and open-source nature have led to its integration into countless commercial and custom-built applications, making it a cornerstone of modern web infrastructure. Its widespread implementation, however, also makes it a high-value target for malicious actors. The Tomcat Manager application, a web-based interface engineered to streamline administration and deployment, presents a particularly compelling vector for compromise. An improperly secured interface offers attackers a direct, low-effort method for deploying malicious payloads—such as web shells, ransomware, or cryptominers—and establishing a persistent, often undetected, foothold within an enterprise network [8].

In June 2025, security researchers observed a pronounced and coordinated escalation in brute-force attempts targeting the Tomcat Manager interface [1]. This activity was not random internet noise but a deliberate, large-scale campaign to identify and compromise exposed Tomcat services with alarming efficiency. The assailants utilized a distributed network of IP addresses, suggesting a degree of operational sophistication designed to circumvent rudimentary IP-based blocking and complicate forensic analysis. This campaign accentuates a persistent and hazardous reality: threat actors perpetually scan the internet for easily exploitable vulnerabilities. A misconfigured administrative interface represents one of the most accessible and consequential targets, effectively serving as an unlocked door into an organization's digital assets [9]. This article deconstructs this campaign, investigates its causes, and proposes a strategic framework for defense.

2. Analysis of the Attack Campaign

The June 2025 campaign was distinguished by its considerable scale and systematic execution. The threat intelligence firm GreyNoise reported a substantial increase in traffic targeting Tomcat Manager. Two specific indicators—"Tomcat Manager Brute Force Attempt" and "Tomcat Manager Login Attempt"—registered volumes that far surpassed established baselines [1]. On a single day, June 5, 2025, the firm documented 295 unique IP addresses conducting brute-force attacks, all classified as malicious. This coordinated offensive was not an opportunistic, unsophisticated attack but a calculated campaign to exploit a common and frequently overlooked security vulnerability at a global scale. The precision of the targeting suggests the use of pre-populated lists of vulnerable servers, likely curated over time through continuous internet reconnaissance.

2.1. Geographic Distribution of Attack Origins

The attacks emanated from a globally distributed set of IP addresses, although a notable concentration occurred in a select few countries with highly developed internet infrastructure. This distribution is likely a deliberate tactic to complicate attribution and bypass region-specific ingress filtering. Figure 1 delineates the primary sources of the attack traffic.

This geographic data suggests the attackers are leveraging compromised servers or virtual private servers (VPS) in these developed nations, plausibly to masquerade the malicious traffic as legitimate and circumvent detection systems that might apply greater scrutiny to traffic from regions known to harbor cybercriminal activities [1]. Using infrastructure in countries with strong data privacy laws can also hinder law enforcement investigations, providing an additional layer of operational security for the attackers. This method of co-opting legitimate infrastructure is a common tactic for advanced persistent threats (APTs) and organized cybercrime groups [6].

2.2. Attack Methodology

The campaign’s principal vector was a conventional yet persistently effective brute-force attack. The assailants employed automated scripts to systematically attempt common and default username and password combinations against the Tomcat Manager login interface. This dictionary-style attack leverages extensive lists of credentials gathered from previous breaches, default vendor settings, and common password patterns [10]. These combinations frequently include "admin/admin", "tomcat/tomcat", "manager/manager", and other readily guessable credentials. The efficacy of such a fundamental technique on a massive scale indicates a widespread deficiency in implementing basic password security policies. The attackers appeared to operate from a pre-compiled list of potential targets, likely aggregated from internet-wide scans utilizing tools such as Shodan or Censys, which can rapidly identify open Tomcat Manager ports and service banners, allowing for highly targeted and efficient attacks [11].

3. Root Cause Analysis

The success of this large-scale brute-force campaign stems not from a novel zero-day exploit, but from the persistent and pervasive neglect of fundamental security configurations. The root causes trace to a confluence of administrative oversight, insecure default postures, and insufficient security consciousness within the application deployment lifecycle, particularly in environments that prioritize speed of delivery over secure development practices [12].

3.1. Insecure Default Configurations

Insecure default settings are a primary contributing factor. While newer versions of Tomcat have improved security, legacy versions, or those installed via certain package managers, may deploy with the Manager application pre-enabled and accessible [7]. More significantly, they often ship with default user accounts and weak, publicly documented passwords. For instance, the default tomcat-users.xml file provides a template for creating administrative users. In the rush of a deployment cycle, developers or system administrators may simply uncomment these examples without modifying the credentials, thereby inadvertently creating a publicly accessible backdoor. This oversight is especially common in non-production environments (development, testing, staging) that are later promoted to production without a proper security review [5].

3.2. Weak and Default Credentials

The reliance on weak or default credentials remains one of the most significant, self-inflicted security deficiencies. During expedited deployment timelines, developers and administrators often prioritize functionality over security, leaving default passwords like "tomcat" or "s3cret" in place for expediency. This campaign's success directly testifies to this pervasive issue. Threat actors know these common practices and have developed extensive dictionaries of default credentials for a wide range of applications, including Tomcat [10]. A single weak password on an internet-facing server is sufficient to facilitate a breach, turning a simple oversight into a major security incident. A lack of enforced password complexity and rotation policies within many organizations compounds the problem [6].

3.3. Lack of Network Segmentation and Access Control

Deficient network architecture constitutes another principal cause. The Tomcat Manager interface should never be exposed to the public internet. As an administrative tool, it should only be accessible from a trusted internal network or via a secure Virtual Private Network (VPN) [5]. The fact that attackers could conduct a large-scale brute-force campaign indicates that thousands of organizations have their Tomcat Manager interfaces directly exposed online, often due to misconfigured cloud security groups or firewall rules. This absence of proper network segmentation demonstrates a failure to apply the principle of least privilege, where services are exposed only to the networks and users that possess an explicit requirement for access. This practice creates a flat network topology where compromising one external service can lead to broad internal access [13].

4. Recent Examples and Impact (2024-2025)

While the identities of compromised organizations often remain private, threat intelligence reports document the impact of compromised Tomcat servers. In a 2024 incident, a mid-sized e-commerce company experienced a significant data breach after attackers gained access to its network through a misconfigured Tomcat Manager interface [2]. The attackers used default credentials to authenticate, deployed a web shell as a WAR file, and subsequently moved laterally across the network using credential-dumping tools to harvest additional administrative accounts. This access ultimately allowed them to reach and exfiltrate sensitive customer databases and deploy ransomware to cover their tracks. The total financial impact of this incident—encompassing remediation, regulatory penalties under GDPR, and reputational damage—was estimated in the millions of dollars.

More recently, in early 2025, threat actors used compromised Tomcat servers as nodes in a botnet for launching Distributed Denial of Service (DDoS) attacks and for cryptocurrency mining operations [3]. By exploiting weak Manager passwords, they installed malicious software that monopolized server CPU and memory resources. This not only severely degraded performance for legitimate applications, causing business disruption, but also significantly increased operational expenditures for the victim organization due to higher cloud computing bills. These examples illustrate that the initial compromise of a Tomcat server is frequently the precursor to a much larger and more damaging attack sequence.

5. Recommendations for Mitigation

Defending against these attacks necessitates a multi-layered, defense-in-depth approach that integrates technical controls, robust policies, and continuous monitoring. The following recommendations provide a comprehensive framework for securing Apache Tomcat deployments.

5.1. Secure the Tomcat Manager Application

• Disable or Remove the Manager Application: If the web-based Manager application is not essential for production operations, remove it entirely from the webapps directory. This is the most definitive method for eliminating its attack surface [7].
• Restrict Access: If the Manager application is required, restrict its access at the network level. Employ a firewall or, more specifically, the RemoteAddrValve within Tomcat's context.xml file to ensure that only connections from trusted, whitelisted IP addresses or subnets are permitted [5].
• Utilize Strong, Unique Passwords: Enforce a stringent password policy for all Tomcat user accounts. Passwords must be of sufficient length (at least 12 characters), complexity (using a mix of upper/lower case letters, numbers, and symbols), and be unique to the service. Change default or easily guessable passwords immediately upon deployment [10].

5.2. Harden the Tomcat Server

• Run Tomcat with a Dedicated User Account: Do not run the Tomcat service with root or Administrator privileges. Create a dedicated, unprivileged user account for the service to limit the potential impact of a compromise and prevent an attacker from gaining immediate system-level control [7].
• Maintain Current Software Versions: Regularly apply security patches for both Apache Tomcat and the underlying Java Runtime Environment. A formal patch management program should test and deploy updates in a timely manner. New vulnerabilities are discovered regularly, and timely patching is a critical defensive measure. For example, security teams disclosed and patched several critical vulnerabilities, including a path equivalence flaw (CVE-2025-24813), in early 2025 [4].
• Enable the Security Manager: For high-security environments, enable the Java Security Manager. This will execute Tomcat and its web applications within a restrictive sandbox, limiting their ability to perform sensitive actions like file system access or network connections. This measure requires thorough testing to ensure application compatibility but provides a formidable layer of defense against post-exploitation activities [7].

5.3. Implement Continuous Monitoring and Defense

• Monitor Access Logs: Conduct regular, automated reviews of Tomcat's access logs for indicators of brute-force activity, such as a high volume of 401 or 403 error codes from a single IP address or multiple IPs over a short duration. Integrate these logs with a Security Information and Event Management (SIEM) system for correlation and alerting [5].
• Employ a Web Application Firewall (WAF): A WAF can furnish an additional layer of protection by detecting and blocking malicious requests—including brute-force attempts, SQL injection, and cross-site scripting—before they reach the Tomcat server [14].
• Implement Account Lockout Policies: Configure Tomcat's LockOutRealm to automatically lock user accounts following a specified number of failed login attempts (e.g., five attempts within five minutes). This policy can effectively thwart automated brute-force attacks by making them computationally infeasible [7].

6. Conclusion

The 2025 coordinated brute-force campaign against Apache Tomcat Manager interfaces is an illustrative case study of persistent, fundamental security oversights. It demonstrates that sophisticated threat actors will continue to exploit the most elementary misconfigurations—weak credentials and exposed administrative interfaces—to achieve their objectives with high rates of success. The root causes are not technical defects in the software itself, but rather procedural and architectural deficiencies in its deployment and management, often stemming from a disconnect between development speed and security diligence [12].

For Chief Information Security Officers, Chief Technology Officers, and other IT leaders, the paramount conclusion is the importance of foundational security hygiene. A defense-in-depth strategy that encompasses secure configuration management, robust access controls, and continuous, vigilant monitoring is indispensable for protecting against these and analogous threats [13]. The recommendations outlined in this article provide a clear, strategic roadmap for hardening Tomcat deployments. By moving beyond insecure defaults, fostering a culture of security awareness, and embracing a proactive security posture, organizations can substantially reduce their attack surface and build a more resilient defense against future coordinated attacks.

References

[1] GreyNoise Intelligence, "Coordinated Brute Force Activity Targeting Apache Tomcat Manager," GreyNoise Blog, June 10, 2025. [Online]. Available: https://www.greynoise.io/blog/coordinated-brute-force-activity-targeting-apache-tomcat-manager

[2] Mandiant, "M-Trends 2025," Mandiant, 2025.

[3] CrowdStrike, "2025 Global Threat Report," CrowdStrike, 2025.

[4] Akamai, "Detecting and Mitigating Apache Tomcat CVE-2025-24813," Akamai Blog, March 20, 2025. [Online]. Available: https://www.akamai.com/blog/security-research/march-apache-tomcat-path-equivalence-traffic-detections-mitigations

[5] Center for Internet Security, "CIS Apache Tomcat Benchmark," 2025. [Online]. Available: https://www.cisecurity.org/benchmark/apache_tomcat/

[6] Verizon, "2025 Data Breach Investigations Report," Verizon, 2025.

[7] Apache Software Foundation, "Apache Tomcat 9 Security Considerations," Apache Tomcat Documentation, 2025. [Online]. Available: https://tomcat.apache.org/tomcat-9.0-doc/security-howto.html

[8] OWASP Foundation, "OWASP Top Ten Project," 2024. [Online]. Available: https://owasp.org/www-project-top-ten/

[9] S. K. Sood and S. Singh, "A survey on password cracking techniques and countermeasures," Journal of Network and Computer Applications, vol. 82, pp. 1-16, 2017.

[10] T. Moore, R. Clayton, and R. Anderson, "The economics of online crime," Journal of Economic Perspectives, vol. 23, no. 3, pp. 3-20, 2009.

[11] J. Matherly, "Shodan: The Scariest Search Engine on the Internet," Shodan Blog, 2009. [Online]. Available: https://blog.shodan.io/

[12] G. A. Alvarez, "A Root Cause Analysis of Cybersecurity Incidents," SANS Institute, 2023.

[13] National Institute of Standards and Technology, "Zero Trust Architecture," NIST Special Publication 800-207, 2020.

[14] A. Al-Haj, "Web Application Firewalls (WAFs): A Practical Approach," IEEE Security & Privacy, vol. 15, no. 4, pp. 84-88, 2017.