November 07, 2025 10 Minute Read

In 2024, I published Feline Hackers Among Us? (A Deep Dive and Simulation of the Meow Attack), which explored the notorious Meow attack campaign that had plagued unsecured databases since 2020. That article focused on demonstrating the attack against a single MongoDB instance using a simple Python script. A proof-of-concept that illustrates how devastating misconfigurations can be.

While the number of Meow attacks has decreased from its peak in 2020, Shodan searches still reveal dozens of compromised databases whose data has been replaced by random alphanumeric strings followed by “-MEOW”. The persistence of this threat led me to develop something more comprehensive.

Enter MAD-CAT (Meow Attack Data Corruption Automation Tool), a custom-built adversarial simulation tool designed to demonstrate Meow attacks across the actual six database platforms victimized by this campaign. This isn’t just an incremental improvement from the last article. It’s a complete reimagination of how security professionals can test, understand, and defend against data corruption attacks in diverse database environments.

MAD-CAT (Meow Attack Data Corruption Automation Tool)

MAD-CAT is a custom-built offensive security tool designed to simulate and demonstrate real-world implications of the Meow attack data corruption campaign on a variety of exposed and vulnerable database platforms and services. The tool supports all the actual database systems victimized by Meow attacks, including MongoDB, Elasticsearch, Cassandra, Redis, CouchDB, and Hadoop HDFS.

It is worth noting that Hadoop HDFS, while technically a distributed file system rather than a traditional database, serves as a critical data repository in enterprise environments and was targeted by real-world Meow attacks alongside traditional databases, making its inclusion essential for realistic attack simulation.

MAD-CAT was designed with a non-credentialed (for targets with no authentication mechanism) and a credentialed (for targets with default or weak credentials) mode to enable exploitation of both authenticated and unauthenticated access scenarios.

Furthermore, the tool supports single-target attacks for focused testing and bulk CSV-based campaigns that can process entire lists of targets in sequence to simulate an automated mass-exploitation approach.

In addition, the tool’s architecture implements a factory pattern, making extending MAD-CAT remarkably straightforward and allowing security researchers to add support for new database platforms by simply implementing a standardized set of methods without modifying the core framework. To obtain an overview of MAD-CAT, the help message output (using the `–help/-h` flag) and the supported database list output (using the `–list/-l` parameter) are shown in Figure 1 and Figure 2, respectively.

Figure 1. The MAD-CAT help message output.

Figure 2. The MAD-CAT supported database services list output.

MAD-CAT executes a systematic four-phase attack workflow that precisely replicates the methodology observed in real-world Meow attack victims. As illustrated in Figure 3, the attack begins by connecting to the target database (with or without credentials). Once connected, the tool enumerates all databases and their collections, tables, and indices, deliberately excluding system databases to focus corruption efforts on user data that would cause the greatest operational impact.

The corruption phase then fetches all records from each discovered collection. It systematically replaces every string and numeric field value with a ten-character random alphanumeric string followed by the literal suffix “-MEOW”, precisely matching the signature pattern documented by security researchers in thousands of compromised databases during the 2020 attack wave. Finally, MAD-CAT generates comprehensive reporting details.

Figure 3. The MAD-CAT attack workflow.

For verification purposes, the MAD-CAT project also provided the `fetch_data.py` script. This helper script can pull and print all current data from the databases, either all at once (e.g., fetch_data.py all) or per-service (e.g., fetch_data.py mongodb, etc.). It is primarily used in attack simulations to show the exact database contents before and after the MAD-CAT strike.

Dockerized Database Infrastructure: The Safe Playground

Following the original blog’s approach, I demonstrated pulling a single MongoDB Docker image and running it as an isolated target. MAD-CAT takes a fundamentally different and more sophisticated approach.

The tool includes a complete Docker Compose environment setup that orchestrates six database services simultaneously with intentionally vulnerable configurations. A very specific set of user template data is automatically populated into each database through initialization scripts during container startup.

The specifics of these data seeding operations are included in the init-scripts directory, and therefore, they will not be detailed here to save time.

This multi-container architecture creates an interconnected ecosystem that mirrors a somewhat realistic enterprise database infrastructure, where different database platforms operate within the same network environment and share common security boundaries. The Docker Compose file handles the complexity of spinning up MongoDB, Elasticsearch, Cassandra, Redis, CouchDB, and Hadoop HDFS in a coordinated manner, each configured with the types of security weaknesses that made the original Meow attacks so devastating.

As shown in Figure 4, executing the simple command `sudo docker-compose upcreates a dedicated network bridge, establishes persistent volumes for each database platform, and sequentially brings each service online with status indicators confirming successful initialization. The output demonstrates the infrastructure creation process, with each database service marked as “done” after completing its startup sequence, transforming what would have been a complex manual setup process into a single command that delivers a complete vulnerable database environment ready for security testing.

Figure 4. Creation and initialization of the Dockerized database infrastructure.

As observed in Figure 5, running `sudo docker ps -a` reveals the complete infrastructure with all six containers running simultaneously, displaying their exposed ports (MongoDB on 27017, Elasticsearch on 9200, Cassandra on 9042, Redis on 6379, CouchDB on 5984, and Hadoop on 9870), their running status uptime, and their interconnected network configuration that allows MAD-CAT to target all platforms through their standard ports.

Figure 5. Status verification of Dockerized targets.

MongoDB — The Classic Target

MongoDB is a popular NoSQL document database that stores data in flexible JSON-like documents. It uses BSON (Binary JSON) for efficient storage, querying, and support for data types beyond standard JSON. Its schema-less design and rich query language make it ideal for web applications, analytics, and data that doesn’t fit rigid tables. MongoDB supports indexing and replication, and it scales horizontally by sharding.

Many organizations use MongoDB for everything from user profiles and logs to product catalogs and Internet of Things (IoT) telemetry. It’s prized for high availability and ease of development. However, misconfigured MongoDB instances (especially those exposed without an authentication mechanism) are a prime target for attackers. Successful data corruption in MongoDB instances that contain critical records (customer data, configurations, or logs) would be irreversibly scrambled and can have devastating consequences. For example, personally identifiable information (PII) or proprietary information in a MongoDB instance could be overwritten with garbage and a “-MEOW” tag, potentially breaking applications or causing compliance failures if not recoverable.

The simulation starts by executing the `python fetch_data.py mongo` command as shown in Figure 6. The output dumps the pristine initial state of MongoDB data.

Figure 6. Fetched initial MongoDB data values.

As shown in Figure 7, the Meow attack is conducted on the MongoDB target by executing the `python mad_cat.py -t 192.168.1.11 -s mongodb -p 27017 -u root -pw example` command. The tool connected and began corrupting documents. Within seconds, it reported all collections processed and the number of records altered. No errors occurred. Therefore, the “cat” had entered the building unnoticed.

Figure 7. MAD-CAT execution on the MongoDB target.

To verify the effects of the Meow attack, the `python fetch_data.py mongo` command was again executed. As shown in Figure 8, all the original content is gone, and every value had been replaced by random text followed by “-MEOW”.

Figure 8. Fetched post-attack MongoDB data values.

Elasticsearch — The Search Engine Catastrophe

Elasticsearch is a distributed search and analytics engine built on Lucene. It stores JSON documents in inverted-index structures, making it excellent for text search, log analysis, and real-time analytics. Commonly used as part of the “ELK” stack (with Logstash and Kibana), Elasticsearch ingests logs, metrics, and any document data and allows complex queries at scale.

Organizations deploy Elasticsearch for everything from log aggregation and SIEM to customer search features on websites. It’s especially popular for logs, metrics, and time-series data. A corruption attack here can silently poison search indices. For instance, an e-commerce site might find every product name replaced with nonsense ending in “-MEOW”, or an analyst might find logs overwritten beyond use. Data loss in Elasticsearch could break search services and destroy historical records of system events.

The simulation starts by executing the `python fetch_data.py elasticsearch` command as shown in Figure 9. The output dumps the initial pristine state of Elasticsearch data.

Figure 9. Fetched initial Elasticsearch data values.

As shown in Figure 10, the Meow attack is conducted on the Elasticsearch target by executing the `python mad_cat.py -t 192.168.1.12 -s elasticsearch -p 9200 -u admin -pw secret` command. The tool exploited the open HTTP endpoint and proceeded to rewrite every indexed document’s data.

Figure 10. MAD-CAT execution on the Elasticsearch target.

To verify the effects of the Meow attack, the `python fetch_data.py elasticsearch` command was again executed. As shown in Figure 11, the output revealed that each text field had been garbled, and every original string became random characters with “-MEOW”. The index still exists, but all its contents are effectively junk. This mirrors real-world Meow attacks, where Elasticsearch indices were found intact but filled with meowing garbage.

Figure 11. Fetched post-attack Elasticsearch data values.

Cassandra — Distributed Database Mayhem

Apache Cassandra is an open-source, distributed NoSQL database designed for high throughput and availability. It uses a wide-column model inspired by Google’s Bigtable and a distributed architecture inspired by Amazon’s Dynamo. Data is organized into tables with flexible columns, using CQL (Cassandra Query Language) for schema and queries. Cassandra clusters scale horizontally with no single point of failure, so it’s popular in big data and IoT scenarios.

Organizations use Cassandra for massive workloads requiring fast writes and reads across many servers (e.g., telecoms, time-series data, recommendation engines). Its emphasis on always-on availability means even temporary data corruption can be disastrous. Corrupted rows could propagate across the cluster via replication. A Meow-style overwriting of Cassandra column values could wipe out critical data, such as sensor readings or transaction logs.

The simulation starts by executing the `python fetch_data.py cassandra` command (which issues a CQL SELECT) as shown in Figure 12. The output dumps the initial pristine state of Cassandra data.

Figure 12. Fetched initial Cassandra data values.

As shown in Figure 13, the Meow attack is conducted on the Cassandra target by executing the `python mad_cat.py -t 192.168.1.13 -s cassandra -p 9042` command. MAD-CAT connected on port 9042 and enumerated keyspaces and tables (skipping system keyspaces). It then updated each column’s value.

Figure 13. MAD-CAT execution on the Cassandra target.

To verify the effects of MAD-CAT, the `python fetch_data.py cassandra` command was again executed. As shown in Figure 14, it now shows every column entry replaced by a string ending in “-MEOW”. In effect, all user data is gone.

Figure 14. Fetched post-attack Cassandra data values.

Redis — The Caching Layer Under Attack

Redis is an open-source, in-memory key-value data store. It supports simple types (e.g., strings, lists, sets, hashes, streams) and is famous for extreme speed. Due to the fact that it keeps data in RAM (with optional disk persistence), Redis is used as a cache, session store, message broker, and sometimes as a primary database for real-time applications.

Firms deploy Redis for low-latency tasks such as caching API responses, session management, real-time leaderboards, job queues, etc. A corruption of Redis data can break many services at once. Since Redis is typically an open key space, a mass-overwrite means all keys become effectively random. Losing Redis cache or state is typically recoverable since the data can be rebuilt from the source database. However, if the application relied on Redis as the primary or only storage for certain data, that data could be permanently lost.

The simulation starts by executing the `python fetch_data.py redis` command to list all Redis keys and values, as shown in Figure 15. The output dumps the initial pristine state of Redis data.

Figure 15. Fetched initial Redis data values.

As shown in Figure 16, the Meow attack is conducted on the Cassandra target by executing the `python mad_cat.py -t 192.168.1.14 -s redis -p 6379` command. MAD-CAT connected via TCP 6379 and proceeded to overwrite each key’s value.

Figure 16: MAD-CAT execution on the Redis target.

To verify the effects of the Meow attack, the `python fetch_data.py redis` command was again executed. As shown in Figure 17, every value has now been replaced with gibberish plus “-MEOW”. The keys themselves remained, but their contents are effectively gone. This demonstrates that MAD-CAT could wipe a Redis target’s entire keyspace in a blink. Any data relying on those keys would thus be disrupted.

Figure 17. Fetched post-attack Redis data values.

CouchDB — The Web Application Backend

Apache CouchDB is an open-source NoSQL document database that stores data in JSON format. It’s schema-free and accessed via HTTP REST APIs. CouchDB is known for ease of replication, offline capability, and handling loosely structured data. Unlike MongoDB, CouchDB uses MVCC (multi-version concurrency) and design-doc-based MapReduce views for queries. Data is stored as documents (JSON) and attachments, with CouchDB’s built-in replication enabling sync across devices.

Enterprises often use CouchDB for offline-first and mobile sync applications due to bi-directional replication features. It might power mobile apps or browser-based databases that sync back to a central server. It’s also used where JSON query flexibility is needed alongside simple HTTP access. A Meow attack corruption here could disrupt replication and data integrity. For example, if documents on the master contain garbage, they would propagate to all replicas. Losing CouchDB data can mean losing transactional state for mobile users or breaking a composite of distributed datasets.

The simulation starts by executing the `python fetch_data.py couchdb` command to fetch all documents as shown in Figure 18. The output dumps the initial pristine state of Redis data.

Figure 18. Fetched initial CouchDB data values.

As shown in Figure 19, the Meow attack is conducted on the Cassandra target by executing the `python mad_cat.py -t 192.168.1.15 -s couchdb -p 5984 -u admin -pw password` command. MAD-CAT to connect to the CouchDB HTTP interface and update each document.

Figure 19. MAD-CAT execution on the CouchDB target.

To verify the effects of the Meow attack, the `python fetch_data.py couchdb` command was again executed. As shown in Figure 20, it showed that every field value in the JSON document was replaced with an alphanumeric string ending in “-MEOW”. This simulation shows how CouchDB is as vulnerable as any other target with misconfigured access.

Figure 20. Fetched post-attack CouchDB data values.

Hadoop HDFS — Big Data Catastrophe

Hadoop HDFS (Hadoop Distributed File System) is the storage layer of Apache Hadoop. It is a fault-tolerant, distributed file system designed to run on commodity hardware. HDFS can scale to thousands of nodes and is optimized for high-throughput access to large datasets (gigabytes to terabytes). Files are split into large blocks and replicated across DataNodes, making HDFS a backbone for big data analytics and storage.

In many organizations, HDFS is commonly used in data lakes, Hadoop clusters, and big-data pipelines where huge datasets (logs, ML training sets, etc.) live. An HDFS corruption attack is particularly scary because it could affect terabytes of data. HDFS’s built-in replication feature is normally a strength for fault tolerance However, it becomes a vulnerability during a corruption attack because, once files are corrupted, HDFS automatically replicates the corrupted data across multiple nodes, spreading the damage throughout the cluster. For example, if all files in HDFS suddenly had “meows” in their content, batch jobs and queries would fail or produce nonsense.For example, if all files in HDFS suddenly had “meows” in their content, batch jobs and queries would fail or produce nonsense.

The simulation starts by executing the `python fetch_data.py hadoop` command to list files and content from HDFS as shown in Figure 21. The output dumps the initial pristine state of HDFS data.

Figure 21. Fetched initial Hadoop data values.

As shown in Figure 22, the Meow attack is conducted on the Hadoop HDFS target by executing the `python mad_cat.py -t 192.168.1.16 -s hadoop` command. MAD-CAT connects to the HDFS NameNode via the WebHDFS REST API on port 9870 and enumerates directories and files recursively from the root directory. It then replaces file content with random alphanumeric strings followed by “-MEOW”.

Figure 22. MAD-CAT execution on the Hadoop target.

To verify the effects of the Meow attack, the `python fetch_data.py hadoop` command was again executed. As shown in Figure 23 the file’s content was scrambled with streams of gibberish characters ending in “-MEOW”. Even though the file paths and names remained, their contents were ruined. A Hadoop cluster relying on that data would be effectively knocked offline until backups or re-ingestions are performed.

Figure 23. Fetched post-attack Hadoop data values.

MAD-CAT Unleashed (Attack Simulation on an Entire Healthcare Enterprise via the Bulk CSV Mode)

Modern enterprises rarely rely on a single database. They depend on a diverse ecosystem, each platform serving a specialized purpose. In a healthcare setting, for example, a document-oriented database such as MongoDB might store patient records and medical histories, while Elasticsearch can be used to power fast searches across patient documentation and lab results.

A distributed system such as Cassandra could handle streams of data from connected IoT medical devices, ensuring real-time monitoring and analytics. Redis might cache session data and resource availability to keep hospital applications responsive, while CouchDB can be utilized to support patient-facing portals for appointments and prescriptions. Meanwhile, a Hadoop cluster can quietly archive years of billing and compliance data for auditing and analytics. Together, these interconnected systems form the digital backbone of modern healthcare.

In a traditional single-target attack, an attacker identifies an exposed database and exploits those with no authentication mechanisms immediately, while databases with weak or default credentials are breached shortly after via brief brute-force or credential-reuse attempts. In most cases, the security team eventually detects suspicious activity and initiates an investigation, followed by incident response and broader infrastructure checks to ensure no other systems are at risk. This sequential process gives defenders time to identify, isolate, and contain the breach before it escalates further.

In contrast, MAD-CAT’s CSV bulk-target feature launches with a precompiled list of targets (some of which already include required credentials), enabling exploitation in a single coordinated strike. In some cases, attackers deliberately refrain from conducting their attack (e.g., corrupting data) upon accumulating credentials to gather more targets in order for a higher impact strike. Therefore, defenders don’t get the opportunity to react.

The simulation starts by executing the `python fetch_data.py all` command to list files and content from all six databases in this simulated enterprise environment, as shown in Figures 24 and 25. The output dumps the initial pristine state of data from all six databases.

Figure 24. Fetched initial data values of all six databases part 1 of 2.

Figure 25. Fetched initial data values of all six databases part 2 of 2.

As shown in Figure 26, MAD-CAT’s bulk CSV attack mode proceeds by crafting a CSV file listing every target’s IP, database, port, and credentials (if required). For targets without authentication, the username and password fields are left as empty strings (represented by “”,“” in the CSV). In this example, the file contains six targets spanning all supported database platforms.

* Figure 26. Creation of the CSV file for the MAD-CAT bulk attack mode.*

Finally, the `python mad_cat.py -c list.csv` is executed and its output is shown in Figures 27, 28, and 29. In one fell swoop, MAD-CAT connected to each listed host to perform the data corruption signature of the attack on each database. This simulates an enterprise-wide attack where multiple databases are compromised in quick succession.

Figure 27. MAD-CAT execution on all six database targets part 1 of 3

Figure 28. MAD-CAT execution on all six database targets part 2 of 3.

Figure 29. MAD-CAT execution on all six database targets part 3 of 3.

To verify the catastrophic effects of the simultaneous six-database Meow attack campaign, the `python fetch_data.py all` command was executed once more to survey the devastation left in the wake of MAD-CAT’s automated assault, as shown in Figures 30, 31, and 32.

The results paint a grim picture of organizational data destruction that mirrors the nightmare scenario faced by thousands of real victims during the 2020 Meow attack wave. In our hypothetical healthcare enterprise database infrastructure scenario, the MongoDB corruption would transform patient records containing medical histories, allergies, and current medications into unreadable garbage. The Elasticsearch destruction would eliminate the organization’s ability to search across years of clinical documentation.

Cassandra’s corrupted IoT telemetry would eliminate months of historical device data that physicians rely on to establish patient baselines and trend analysis. The Redis cache corruption would invalidate all active user sessions simultaneously, ejecting every physician, nurse, and staff member from the system mid-workflow.

CouchDB’s patient portal destruction would eliminate patients’ ability to access their own health information, schedule appointments, or request prescription refills. Finally, the Hadoop HDFS corruption would destroy years of billing records and compliance audit trails, making it impossible to submit insurance claims, prove services rendered, or demonstrate regulatory compliance with data retention requirements.

Figure 30. Fetched post-attack data values of all six database targets part 1 of 3.

Figure 31. Fetched post-attack data values of all six database targets part 2 of 3.

Figure 32. Fetched post-attack data values of all six database targets part 3 of 3.

The Meow Attack in 2025: A Five-Year Retrospective Through Shodan Analysis

In my 2024 article, I used Shodan to document the state of the Meow attack approximately four years after its inception, discovering 13 compromised Elasticsearch instances and 89 compromised MongoDB instances still actively exhibiting characteristic data corruption patterns. Now, nearly a year later, towards the end of 2025, I return to Shodan to examine not just the current snapshot but the trend lines that tell a more complete story about this persistent threat and the security community’s response to it.

Elasticsearch Targets: The Decline of “meow indices”

As of September 2025, only seven compromised Elasticsearch targets remain visible on Shodan, representing a dramatic decrease from the 13 targets I documented in mid-2024. As illustrated in Figure 33, the historical trend data provided by Shodan paints an even more compelling picture of this decline. The attack reached its absolute peak in late 2020 and early 2021, when Shodan indexed over 13,000 compromised Elasticsearch instances displaying the characteristic “-MEOW” corruption pattern. This represented the height of the Meow attack’s impact on Elasticsearch infrastructure worldwide, likely driven by the widespread deployment of default configurations that lacked authentication requirements in older Elasticsearch versions.

The graph shows a precipitous decline throughout 2021, with the number of compromised instances dropping from the peak of 13,000 to approximately 2,000 by the end of the year. This represents an 85% reduction in a single year, suggesting that the initial wave of publicity surrounding the Meow attack prompted many organizations to audit and secure their Elasticsearch deployments. The decline continued more gradually through 2022 and 2023. By 2024, the number stabilized in the low double digits, and as of September 2025, we see only seven remaining compromised instances.

Figure 33. Meow attack trend line of Elasticsearch.

MongoDB Targets: Port 27017 Under Siege

As of September 2025, Shodan identifies 26 compromised MongoDB instances, down from the 89 I documented in late 2024. This represents a 70% reduction in just over a year, demonstrating significant progress in MongoDB security posture across the Internet.

As illustrated in Figure 34, attacks peaked in late 2020. Shodan indexed nearly 6,000 compromised MongoDB instances displaying the Meow attack signature. The graph shows this dramatic spike occurring rapidly, suggesting that MongoDB’s widespread deployment with default configurations that lacked authentication made it an exceptionally attractive target. The subsequent decline has been steady and sustained, with the number dropping to approximately 300 by mid-2021, then continuing to fall through 2022 and 2023. By 2024, the count had declined to double digits, and the current figure of 26 in September 2025 represents just 0.43% of the peak infection count from 2020.

Figure 34. Meow attack trend line of MongoDB

CouchDB: The Forgotten Target

While my original 2024 article focused primarily on Elasticsearch and MongoDB as the main targets of the Meow attack, expanding the analysis to include CouchDB reveals another dimension of this attack campaign. As of August 2025, only three compromised CouchDB instances remain visible on Shodan, representing the tail end of an attack wave that peaked at around 280 compromised instances in late 2020.

As illustrated in Figure 35, the CouchDB trend line shows the steepest decline of all three database platforms analyzed. From its peak of around 280 instances in late 2020, the number plummeted to approximately 40 hits by 2022. The current count of three instances represents a 98.9% reduction from the peak, suggesting that CouchDB administrators were either more responsive to security advisories or that the CouchDB user base is smaller and more security-conscious than MongoDB or Elasticsearch deployments. However, the persistence of even three compromised instances demonstrates that legacy, vulnerable systems or security negligence persist.

Figure 35. Meow attack trend line of CouchDB.

Understanding the Decline: Credit Where Credit Is Due

The dramatic downward trend across all three database platforms reflects credit to multiple factors in the security ecosystem. Database vendors have responded by making authentication required by default in newer versions, with MongoDB 3.6 and later requiring authentication out of the box, and Elasticsearch 8.0 implementing security features by default. Security awareness campaigns and incident response sharing within the community meant that each new Meow attack victim served as a warning to others, prompting proactive security audits.

The trend graphs showing the rise and fall of Meow attack victims serve as a report card on the industry’s response to a known threat, and by this measure, the industry has earned high marks for significantly reducing the attack surface from peak levels. However, Shodan’s data also serves as a sobering reminder that perfect security remains elusive. The fact that compromised instances still exist five years after the attack began, and that new victims continue to appear even in 2025, demonstrates that security awareness and best practices have not achieved universal adoption.

As we move forward into 2025 and beyond, the Shodan trend data suggests that the Meow attack will likely persist at low levels indefinitely, continuing to claim victims from the long tail of poorly maintained infrastructure while the overall threat level remains dramatically reduced from the crisis levels of 2020. This represents both a success story worth celebrating and a call to action for the security community to continue vigilance against even well-known attack vectors that some organizations have yet to address.

Conclusion

The Meow attack boils down to one painful lesson: misconfiguration kills. Any database left wide open (no authentication, default credentials, or open to the web) is at risk of being rewritten by a bored attacker. We’ve seen it firsthand across MongoDB, Elasticsearch, Cassandra, Redis, CouchDB, and Hadoop; all data can be swept away and replaced with feline gibberish.

Our MAD-CAT simulations underscore how a Meow attack might operate in the wild. While the original Meow attack perpetrators remained anonymous, MAD-CAT provides a plausible reconstruction, including multi-database support, a credentialed or non-credentialed approach, and execution in bulk or one-by-one. It even replicates the trademark “-MEOW” suffix. The automation in MAD-CAT means a single operator could cripple an entire data stack with minimal effort. This is a sobering reminder to secure every database.

Trustwave’s dbProtect and AppDetectivePro products address the aforementioned vulnerabilities, including detection of potential misconfigurations in user authentication (or lack thereof), alerts for discovered default settings (e.g., ports, access credentials), and verification of the latest patch or product version installation. To deliver the latest protection available, Trustwave SpiderLabs security researchers constantly scan the web for new vulnerabilities and, if they exist, updates that fix them. We then incorporate these updates into our solutions.