In the world of malware, common ransomware schemes aim to take the data within databases (considered the "gold" in the vault of any organization) and hold them hostage, promising data recovery upon ransom payment.
Typically, most of these schemes follow an expected script: encrypting files, requesting payment, and then delivering a decryption key. This model, while damaging, generally allows victims to recover if they pay the ransom. However, the Xbash malware defies these norms, introducing a much more sinister approach.
Discovered in 2018, Xbash attacks target databases such as MySQL, MariaDB, PostgreSQL, MongoDB, Redis, Elasticsearch, and OracleDB. These databases are critical to operations and the security and integrity of stored information, including user data, financial records, and business intelligence. Xbash also has the capacity for other sinister activities, such as cryptomining, botnet capabilities, and self-propagation, which we will discuss briefly in this article. However, the focus will be on the database attack component of the Xbash malware.
Xbash is a multifaceted malware with capabilities ranging from database ransomware, botnet capabilities, cryptomining, and self-propagation. By leveraging its botnet traits, Xbash can recruit infected systems to execute further attacks. On the other hand, its cryptomining aspect exploits infected systems' resources to mine cryptocurrency, consequently draining computational power. Finally, Xbash also has a self-propagation feature that provides rapid dissemination across networks, making it extremely challenging to contain.
It is apparent that Xbash malware demonstrates an extraordinary level of sophistication. It was developed in a language often neglected in the field of malware development, Python. In contrast, predominant options such as C or C++ for malware development are attributed to their low-level programming capabilities. Therefore, C or C++ enables a variety of critical benefits that make a malware potent, such as seamless interactivity with system APIs, efficient resource usage, and direct memory manipulation.
These are the primary attributes that make both C and C++ ideal for producing exceptionally optimized and highly intrusive malicious tools. However, Python provides unique advantages that raise its utility in the realm of malware development. Python has both the simplicity and versatility that enable developers to substantially expedite the process of developing complex malware.
In contrast, C or C++ necessitates the rigorous management of memory and manual compilation across platforms that often requires meticulous debugging, which extends the overall deployment cycle. On the other hand, Python is innately interpreted and its plethora of libraries enables the creation of cross-platform malicious payloads. In particular, the PyInstaller library revolutionizes the malware deployment phase. PyInstaller has a multitude of functions that facilitate malware development and deployment. Firstly, it enables the consolidation and singular-packaging of malware by bundling all required dependencies, which includes the crucial Python runtime and third-party libraries. Therefore, this ensures consistent execution across targeted systems without requiring Python to be preinstalled. In addition, PyInstaller can evade static analysis tools through obfuscation by code compression and applying complex encryption.
The Xbash malware probes a long list of TCP and UDP ports in a targeted IP address. Essentially, it verifies if these ports are open and then checks if they have known or easy-to-exploit weaknesses and vulnerabilities. In particular, MySQL, MariaDB, MongoDB, PostgreSQL, Redis, Elasticsearch, and OracleDB are some of the databases the Xbash malware actively seeks.
Xbash does this by primarily probing default ports designated to these database platforms. The Xbash malware specifically targeted Linux-based databases. MySQL is an open-source relational database management system (RDBMS) based on Structured Query Language (SQL) and optimized for web- and cloud-based applications. MariaDB is an open-source fork of MySQL and was designed for great performance and scalability.
PostgreSQL is a highly extensible and open-source relational database known for its support for JSON and XML and its capacity for complex data operations. Redis is an in-memory data structure store designed specifically for high-performance and low-latency that can support processing complex data types such as sets, hashes, lists, and strings. Oracle Database (OracleDB) is a multi-model database management system optimized for high transaction volumes and complex analytic queries that make them ideal for mission-critical applications in enterprise environments.
Elasticsearch is a widely used search and analytics engine for log and event data analysis, text search, and data storage. It stores data as documents in the JSON format and organizes them into indices, which enables fast, full-text searches. MongoDB is a NoSQL database that stores data in flexible JSON-like documents within collections. It uses a schema-less model that allows dynamic document structures and is widely known for its ease of use, scalability, and flexibility.
Attacks on these databases can bring vital systems to a halt, which could consequently lead to costly downtime and data recovery efforts. For many businesses, losing databases such as MySQL or PostgreSQL could result in halted e-commerce, delayed analytics, and weakened decision-making capabilities. MariaDB's integration into various applications makes it essential for efficient data processing, so an attack could disrupt extensive workflows. Elasticsearch is crucial for fast search and analytics, and thus, disruptions could slow business intelligence functions that organizations rely on for their critical operations.
Similarly, OracleDB supports high-volume transaction systems; any damage can severely impact vital business operations. Attacks on NoSQL databases such as MongoDB and Redis can negatively impact applications that require rapid and efficient data retrieval tasks. Compromising these databases not only debilitates operations but also negatively impacts customer trust, which damages the overall reputation of the victimized organization.
Cybersecurity teams use Docker to test vulnerabilities by creating isolated, reproducible environments. It allows security professionals to simulate attacks, run exploits, and analyze responses without affecting the host system. Docker's containerization ensures consistent testing conditions, making identifying, assessing, and mitigating security flaws easier.
Docker can be used to carry out experiments, allowing cybersecurity professionals to have first-hand experience conducting this attack. This simulation aims to create a network within a private subnet (e.g., Subnet and CIDR: 192.168.1.0/24) that contains operational databases with crucial organizational data (e.g., user and employee personally identifiable information or PII). These running databases will then be attacked in one fell swoop by executing a Python script emulating the Xbash behavior of wiping data and replacing them with a warning message resembling a ransom note for the held-up data as hostage.
This is a relatively large project to simulate. Therefore, the use of Docker Compose will surely make the deployment and configuration of these databases all at once a lot easier. The first step of the simulation will be to write the docker-compose.yml file. The docker-compose.yml file is a configuration file Docker Compose uses to define and manage multi-container applications.
It describes the services (containers), networks, and volumes required for an application. Each service includes settings such as the image to use, ports to expose, environment variables, volumes to mount, and network configurations. The file is written in YAML format, making it human-readable and easy to edit. By running `docker-compose up`, the file orchestrates the setup and execution of all defined services, streamlining complex deployments. It promotes modularity and reusability, allowing developers to quickly spawn environments across different systems.
As shown in Figure 1, the docker-compose.yml file starts with the `version` and `service` sections. The `version` section specifies the Compose file format version to determine the features and syntax available. In this particular case, it is set to 3. The `service` section will define the application's containers as services, with each service representing a single container. For each service, the `image`, `container_name,` `networks,` `ports,` and other configurations can be specified.
As shown in Figure 2 to Figure 8, the services for the containers running MongoDB, MySQL, MariaDB, PostgreSQL, Redis, Elasticsearch, and OracleDB are configured, respectively. Basically, these containers are set to have their databases running on designated default ports with easily guessed credentials and no security configurations. In addition, they are all set with the subnet and CIDR values of 192.168.1.0/24 to emulate an interconnected private network. Moreover, the volumes of each container are configured to load a predetermined dataset to emulate the data to be wiped by Xbash. Some of the containers have `entrypoint` configurations to facilitate the upload of the sample dataset.
Finally, as shown in Figure 9, the docker-compose.yml ends with the `volumes` and `networks` sections. The `volumes` section lists named volumes that can be shared between containers or persist data outside containers. The `networks` section defines custom networks for containers to communicate securely and efficiently.
Figure 1. The docker-compose.yml File `version` and `services` sections
Figure 2. MongoDB container configuration
Figure 3. MySQL container configuration
Figure 4. MariaDB container configuration
Figure 5. PostgreSQL container configuration
Figure 6. Redis container configuration
Figure 7. Elasticsearch container configuration
Figure 8. OracleDB container configuration
Figure 9. The docker-compose.yml File `volumes` and `networks` sections
Now that the docker-compose.yml file has been populated with the intended configurations, it can now be used to activate all the databases.
To do that, we executed the command `sudo docker-compose up` within the directory where the created docker-compose.yml file is located. As shown in Figure 10, a snippet of the output displays that all services were created successfully.
Figure 10. Create and start the Docker containers
As observed in the docker-compose.yml file, the `volumes` and/or `entrypoint` sections of each service have references to other files with a variety of different file extensions such as *.sql, *.js, *.json or *.sh. These files are basically used to facilitate the data sample upload to each database. Some require a single file to get the job done, while other databases may require multiple files to upload the sample data.
It should be noted that further elaboration on the content of each file will not be done in this section as it will be a tedious process. Besides, most of these files are self-explanatory, while only a minority are deemed complex. The contents of each file are presented in Figure 11 to Figure 20.
Figure 11. The `mongodb-init.js` file is used to upload the sample data to the MongoDB service.
Figure 12. The `mysql-init.sql` file is used to upload the sample data to the MySQL service.
Figure 13. The `mariadb-init.sql` file is used to upload the sample data to the MariaDBservice
Figure 14. The `postgres-init.sql` file is used to upload the sample data to the MariaDB service.
Figure 15. The `redis-entrypoint.sh` file is used to facilitate the upload of the sample data to the Redisservice.
Figure 16. The `redis-init.sh` file is used to upload the sample data to the Redis service.
Figure 17. The `custom-entrypoint.sh` file is used to facilitate the upload of the sample data to the Elasticsearch service.
Figure 18. The `bulk_data.json` file is used to upload the sample data to the Elasticsearchservice.
Figure 19. The `healthcheck.sql` file is used to provide a health check for the OracleDB service startup.
Figure 20. The `init-scripts/init.sql` file is used to facilitate the upload of the sample data to the OracleDB service.
The Docker container setup is complete. A Python script was crafted to ensure the individual databases run and possess the intended sample data. As shown in Figure 21, `fetch_data.py` was executed successfully, which outputs the sample data of each of the seven running databases.
Figure 21. The `fetch_data.py` output.
Figure 22 to Figure 30 shows the whole content of the `fetch_data.py` Python code. Without going into the minutiae of this code, it essentially connects to each of the seven running databases and extracts the sample data uploaded to each of them.
Figure 22. The list of required Python libraries are imported for the `fetch_data.py` Python script.
Figure 23. Fetch the MongoDB target data.
Figure 24. Fetch the MySQL target data.
Figure 25. Fetch the MariaDB targetdata.
Figure 26. Fetch the PostgreSQL target data.
Figure 27. Fetch the Redis target data.
Figure 28. Fetch the Elasticsearch targetdata.
Figure 29. Fetch the OracleDB targetdata.
Figure 30. The culmination of all Python methods of the `fetch_data.py` Python script.
The next and most crucial component of this simulation is the exploit. Being true to form, this Xbash exploit was also created in Python. However, its functions were limited to emulate the real exploit's data wiping and ransom note creation functions. First, the Python script acquires access to each of the seven operational databases via weak credentials, default ports, and lack of security configurations.
Second, the sample PII data was deleted and replaced with the table/collection/index/key named `WARNING` containing the data 'You have been ransomed.' Take note that the warning message mentioned “ransom,” but the files were never backed up to any command-and-control (C2) server for any sort of recovery if a ransom was ever paid out, just like Xbash. Figure 31 shows the successful execution of the Xbash exploit affecting all seven databases. The entire content of this script can be found in Figure 32 to Figure 41, each broken down into sections of the code.
Figure 31. The `xbash_simulation.py` output
Figure 32. The list of required Python libraries are imported for the `xbash_simulation.py` Python script.
Figure 33. Setting up the Python logging and the warning message constant
Figure 34. Simulates the Xbash attack on the MongoDB target
Figure 35. Simulates the Xbash attack on the MySQL target
Figure 36. Simulates the Xbash attack on the MariaDB target
Figure 37. Simulates the Xbash attack on the PostgreSQL target
Figure 38. Simulates the Xbash attack on the Redis target
Figure 39. Simulates the Xbash attack on the Elasticsearch target
Figure 40. Simulates the Xbash attack on the Oracle target
Figure 41. Running the Xbash attack simulation
Finally, now that the Xbash attack has wreaked havoc and the dust has settled, it is time to see its effects. Another Python script has been constructed to check the intended aftermath of the Xbash attack simulation. As shown in Figure 42, the Python script `xbash_aftermath.py` was executed successfully.
To elaborate, the script was designed to connect to each running database and scan all available tables, collections, indices, and keys. We observed that all the databases contain only a single entry, which is 'WARNING.' Therefore, the Xbash exploit effectively deleted the sample PII data.
Furthermore, the script then checks the data within each 'WARNING' entry. They all produce the same value: 'Your data has been ransomed.' The Xbash exploit has laid waste to this victim's data across all its operational databases. It left a simple sadistic note that offers hope that will surely not manifest in the victim's favor. As shown in Figure 43 to Figure 52, the entire script `xbash_aftermath.py` is broken down into multiple sections to be referenced.
Figure 42. The `xbash_aftermath.py` output
Figure 43. The list of required Python libraries are imported for the `xbash_aftermath.py` Python script.
Figure 44. Setting up the Python logging
Figure 45. Checking the MongoDB target data after the Xbash simulation
Figure 46. Checking the MySQL target data after the Xbash simulation
Figure 47. Checking the MariaDB target data after the Xbash simulation
Figure 48. Checking the PostgreSQL target data after the Xbash simulation
Figure 49. Checking the Redis target data after the Xbash simulation
Figure 50. Checking the Elasticsearch target data after the Xbash simulation
Figure 51. Checking the OracleDB target data after the Xbash simulation
Figure 52. The culmination of all Python methods of the `xbash_aftermath.py` Python script
As with any malware simulation project, a systematic and comprehensive clean-up process should be performed. Despite this project having a relatively low probability of generating real damage, it is good practice to conduct the clean-up process to align with security best practices.
First, the `sudo docker-compose down -v` command is executed, which stops and removes running containers and their associated networks and volumes specified in the docker-compose.yml file. This ensures that project-specific resources are cleared.
Second, the `sudo docker system prune -f` command is executed, which carries out a wider scoped clean-up by eliminating unused Docker objects, such as containers that have been stopped, suspended images, and unused networks, to restore disk space.
Third, the `sudo docker volume prune -f` is executed, explicitly targeting unused volumes and disposing of any persistent storage no longer associated with active containers. Finally, the `sudo docker network prune -f` is executed to enable clearing unused networks to prevent persistent configurations that could cause conflicts with future Docker projects. These commands may overlap slightly in functionality, but they ensure an extra layer of thoroughness. These clean-up commands ensure that the accidental reactivation of potentially hazardous environments is prevented, conserve system resources, and prepare the Docker host for future use in a clean and secure state. As shown in Figure 53, the set of four individual clean-up commands for Docker were entered in a single successful execution.
Figure 53. The successful execution of the set of clean-up Docker commands.
The Xbash malware is a great representation of the accelerated evolution of cybersecurity threats that challenge traditional perceptions of ransomware and database attacks. Contrary to other run-of-the-mill ransomware, Xbash conducts permanent data deletion, cryptomining, botnet use, and self-propagation. Xbash achieves this by leveraging Python's unique capabilities for rapid software function development and the ability to provide stealth (anti-detection). Its propensity for targeting critical databases to exploit their default ports and inherent vulnerabilities makes it a grave concern for organizations reliant on these systems. Ultimately, Xbash is a stark reminder of the ever-evolving nature of cyberthreats and the critical importance of safeguarding organizational assets such as the sensitive data within databases.
Trustwave's dbProtect and AppDetectivePro products have coverage for all the aforementioned databases in this article (MySQL, MariaDB, PostgreSQL, MongoDB, Redis, Elasticsearch, and OracleDB), which facilitate the fortification of an organization's defenses against sophisticated malware such as Xbash. Moreover, the specific weaknesses and vulnerabilities (e.g., weak passwords, default ports, misconfigurations, disabled security, etc.) demonstrated in the simulations are also addressed through dbProtect and AppDetectivePro's comprehensive scanning, detection capabilities and extensive database activity monitoring.