January 27, 2025 10 Minute Read

In the past decade, Oracle Database (Oracle DB) has reigned supreme in the competitive arena of database engine popularity ranking as shown in Figure 1 and Figure 2. This pervasiveness has led Oracle Database to be trusted by Fortune 500 companies (e.g. Netflix, LinkedIn, eBay, etc.) to house, process, and safeguard their critical data. Its popularity can be attributed to its ability to handle massive volumes of data and concurrent transactions with high performance, making Oracle Database optimized for enterprise-level workloads, where speed, efficiency, and reliability are critical.

However, lurking in the shadows is ODAT (Oracle Database Attacking Tool), a potent Python-based tool that dares to challenge this industry giant. Like a digital David taking aim at Goliath, ODAT’s capabilities are utilized by penetration testers as well as threat actors to expose the cracks in Oracle Database’s armor. Thus, proving that even the most formidable systems are not impervious to attacks.

Figure 1. Graphed database engine popularity ranking. Source: db-engines.com

Figure 2. Tabulated top 10 database engine popularity ranking. Source: db-engines.com

Oracle Database Overview

The Oracle Database is a cornerstone of modern enterprise data management. It is widely recognized as one of the most powerful and dominant relational database management systems (RDBMS) engineered for enterprise-level scalability, performance, and security. Furthermore, Oracle Database supports a wide range of enterprise-grade features, including transaction management, high availability, scalability, and advanced analytics. Its architecture is built to manage multi-terabyte data volumes, supporting OLTP (Online Transaction Processing), OLAP (Online Analytical Processing), and mixed workloads simultaneously. Moreover, Oracle Database’s Pluggable Database (PDB) feature allows multiple databases to run on a single instance, significantly improving resource efficiency. It supports native integration with programming languages such as Java and Python and offers comprehensive encryption features such as Transparent Data Encryption (TDE). In addition, Oracle Database was designed with an architecture that ensures ACID (Atomicity, Consistency, Isolation, and Durability) compliance to offer unparalleled transaction consistency and integrity while handling massive datasets. As the leading commercial off-the-shelf (COTS) database, Oracle Database is deployed across a variety of industries such as financial, healthcare, and government sectors to manage mission-critical workloads.

ODAT Overview

ODAT post-exploitation modules for foothold enumeration can then be used. Specifically, modules such as `dbmsxslprocessor` and `utlfile` allow file uploading and downloading of targeted critical files such as host OS configuration files (e.g. /etc/passwd, SSH keys, etc.) or Oracle Database configuration files (e.g. tnsnames.ora, listener.ora, etc), which can reveal additional attack vectors. If the exploit focuses only on the exfiltration of critical files, then modules such as `ctxsys` and `dbmsadvisor` can be utilized. Furthermore, ODAT also provides several post-exploitation capabilities. In particular, the `dbms_scheduler`, `externaltable`, and `java` modules enable attackers to execute arbitrary system commands, upload binaries, and even establish reverse shells on the target machine. If the primary concern was the discovery of sensitive data (e.g., credentials, PL/SQL code, etc.) then modules such as `search`, `unwrapper`, and `passwordstealer` could facilitate this process. 

In summary, ODAT integrates enumeration, credential brute-forcing, file manipulation, network scanning, and many more capabilities into a single Python-based tool, which provides pentesters and attackers a streamlined workflow for Oracle database exploitation testing. Overlapping ODAT modules allows for alternative routes of exploitation. Thus, ODAT generates better chances of exploit success in case the use of one module is not made possible due to having a target with the required configurations disabled (e.g. Java).

Figure 3. ODAT mind map diagram.

Docker Compose Setup

Cybersecurity professionals can use Docker to carry out experiments, giving them first-hand experience at conducting simulated attacks using tools such as ODAT. The simulation’s goal is to create a Docker network environment running three different Docker instances. One machine will contain an Oracle database, another will contain a Metasploitable machine to act as a vulnerable internal system interconnected with the Oracle Database instance, and finally, the last machine will contain ODAT.

Since this project requires running multiple Docker instances, using Docker Compose will surely make it easier to configure and deploy the Docker containers simultaneously. Therefore, the simulation’s first step will be to write the docker-compose.yml file. The docker-compose.yml file is a configuration file used by Docker Compose 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 4, 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 was set to 3.8. The `service` section will define the application's container as a service where each service represents a single container. For each service, the `image`, `container_name`, `networks`, `ports`, and other configurations can be specified.

The first Docker instance configured was the Oracle database as shown in Figure 5. It was a simple configuration with the Oracle database default TNS listener on port 1521 opened, and the password for the Oracle database was set, and IP address set to 172.27.0.10.

The second Docker instance configured with IP address 172.27.0.20 contained the complete standalone installation of ODAT as shown in Figure 6. Opting to use Docker instead of the typical download and installation process will save a lot of time from any potential troubleshooting related to issues such as Python dependencies and/or OS environment setup. To keep a container running without doing anything specific, the `tail -f /dev/null` trick is employed. By following /dev/null, the tail command never exits, and as a result, the container stays alive indefinitely.

The last Docker instance configured with IP address 172.27.0.30 was a Metasploitable2 machine as shown in Figure 7. Basically, the Metasploitable machine is a vulnerable machine designed to facilitate penetration testing, security assessments, and ethical hacking practices. It serves as an essential tool for security professionals and learners to develop and test exploit techniques in a controlled environment. In this particular case, the Metasploitable machine was configured to have ports 21, 22, 80, 445, and 3306 open, which are the services FTP, SSH, HTTP, SMB, and MySQL, respectively. These ports (when misconfigured) are the typical means pentesters or threat actors use to obtain either an initial foothold or an internal system pivot into a target. The simulations will make use of Metasploitable to demonstrate how ODAT can be used to conduct internal system enumeration via port scans.

Finally, as shown in Figure 8, the docker-compose.yml ends with the `networks` sections which define custom networks for containers to communicate securely and efficiently.

Figure 4. The docker-compose.yml file `version` and `services` configuration.

Figure 5. The Oracle DB Docker instance configuration.

Figure 6. The ODAT Docker instance configuration.

Figure 7. The Metasploitable Docker instance configuration.

Figure 8. The docker-compose.yml file `networks` configuration.

Now that the docker-compose.yml file has been populated with the intended configurations, it can be used to activate all the required Docker instances for this simulation. To do that, execute the command `sudo docker-compose up` within the directory where the created docker-compose.yml file is located. As shown in Figure 9, a snippet of the output displays that all services were created successfully.

Figure 9. Create and start the Docker containers.

Access to ODAT via Shell and ODAT Help Output

Now that the Docker setup is complete, the ODAT attack simulations can begin. To obtain CLI root access to the running ODAT Docker instance, the command `sudo docker exec -it odat /bin/bash` was executed as shown in Figure 10. The `odat.py` Python script can be found in the directory `/root/odat/.` To conduct a rudimentary test of the basic execution of ODAT, the command `python3 ./odat.py -h` was executed to display the general help message output as shown in Figure 11.

Figure 10. CLI access to the ODAT Docker instance.

Figure 11. The ODAT general help message output.

SID Guesser Attack via the `sidguesser` Module

In Oracle databases, the SID is a unique name that identifies a specific database instance on a host machine. The SID is crucial for establishing a connection to the database, as it tells the Oracle listener which database instance to direct a client request to. ODAT’s `sidguesser` module targets this fundamental component by attempting to guess the SID of a target Oracle database instance. As shown in Figure 12, the help message output displays all the options that the `sidguesser` module accommodates. By leveraging a list of common and default SIDs, the `sidguesser` module systematically probes the Oracle listener to identify valid SIDs, which can be critical for gaining unauthorized access. If an attacker successfully identifies a valid SID, they can connect to the database to launch further attacks, such as brute-forcing credentials using ODAT’s other modules.

This highlights the importance of securing Oracle listener configurations, as weak or default SIDs can serve as an entry point for attackers to exploit misconfigured or poorly monitored Oracle Database instances. As demonstrated in Figure 13, ODAT's `sidguesser`module was used to determine the Oracle database target has a SID value of 'FREE'.

Figure 12. ODAT's `sidguesser` module help message output.

Figure 13. Exposing the SID of the Oracle DB target.

The TNS Listener Probe via the `tnscmd` Module

The TNS is Oracle database's proprietary protocol for establishing and managing connections between clients and database servers. By default, TNS connection requests operate on TCP port 1521. Acting as the communication backbone, TNS enables data transfer, connection requests, and other critical operations between Oracle components over a network.

ODAT's `tnscmd` module leverages this protocol to interact with the Oracle TNS Listener, a key component responsible for handling incoming connection requests. As shown in Figure 14, the help message output displays all the options that the `tnscmd` module accommodates. One of the `tnscmd` module options is `--ping` which sends a TNS ping command to get the Oracle database listener and more importantly, it serves as confirmation that the TNS Listener is running and reachable. As demonstrated in Figure 15, ODAT's `tnscmd` module with the `--ping` option was used to indeed confirm that the TNS listener is operational on the Oracle database target and to expose that the target's listener has an alias value of 'LISTENER'.

Figure 14. ODAT's `tnscmd` module help message output.

Figure 15. Exposing the listener alias of the Oracle DB target.

The TNS Poison Attack `tnspoison` Module

ODAT's `tnspoison` module exploits a specific vulnerability (CVE-2012-1675) in Oracle's TNS listener service to perform a TNS poisoning attack. TNS poisoning occurs when an attacker manipulates the TNS listener to reroute database client connections to a malicious server or to intercept legitimate traffic. By using the `tnspoison` module, attackers can inject rogue network routing entries into the TNS listener configuration, effectively enabling man-in-the-middle (MitM) attacks or denial-of-service (DoS) conditions. Once poisoned, legitimate Oracle database clients unknowingly connect to the attacker's server, potentially exposing sensitive credentials and query data. As shown in Figure 16, the help message output displays all the options the `tnspoison` module accommodates. One of the`tnspoison`module options is `--test-module` which will test if the target is vulnerable to this attack. The `tnspoison` module with the `--test-module` option was then executed. As shown in Figure 17, this particular target was not vulnerable to a TNS poisoning attack. Fortunately, the target has a newer Oracle Database version, and this attack is only possible with older versions of Oracle's TNS Listener.

Figure 16. ODAT's `tnspoison` module help message output.

Figure 17. Testing ODAT's `tnspoison` module on the Oracle DB target (not vulnerable).

Credential Guesser via the `passwordguesser` Module

ODAT’s `passwordguesser` module is designed to perform brute-force attacks against Oracle Database accounts by attempting to guess valid username and/or password combinations. As shown in Figure 18, the help message output displays all the options that the `passwordguesser` module accommodates. Oracle databases rely on user accounts to authenticate and authorize access. Therefore, weak credentials can pose a significant security risk. The `passwordguesser` module can systematically test a series of username-password pairs to identify valid login credentials that may have been left as default or poorly configured. A particularly useful option within this module is the `--accounts-file` option, which allows attackers or pentesters to supply a file containing multiple username and password combinations to streamline the guessing process. This file is typically formatted with entries such as `<username>/<password>` thus enabling ODAT to methodically test each pair against the target Oracle instance. The `--accounts-file` option enhances flexibility, allowing testers to customize their brute-force attempts by using widely available password dictionaries or lists of known default credentials. This capability makes ODAT an effective tool for exposing weakly configured Oracle database accounts. As demonstrated in Figure 19, ODAT's `passwordguesser` module was used to expose the fact that the Oracle Database target has an existing account with the username and password combination values of 'sys/Oracle123,' respectively.

Figure 18. ODAT's `passwordguesser` module help message output.

Figure 19. Exposing valid user account credentials of the Oracle DB target.

Password Spraying Attack via the `passwordguesser` Module

Password spraying is an offensive security technique where an attacker attempts to authenticate multiple user accounts using a single or small set of common passwords. This method deviates from the typical approach, which is brute-forcing one account with multiple password attempts. Password spraying reduces the risk of triggering account lockouts, which often occur after repeated failed login attempts on a single account. Password spraying is particularly effective against systems with weak password policies or where default passwords are still in use.

ODAT’s `passwordguesser` module can be used to conduct password spraying attacks against Oracle databases by leveraging its ability to test specific username-password combinations systematically. By supplying a list of usernames (such as known database accounts) and a small list of commonly used or default passwords, testers can use the module to check for valid credentials across multiple accounts without overwhelming any single one. This is further facilitated through the `--logins-file-pwd` option, which allows users to specify a file containing common Oracle Database account usernames. This approach is stealthier and aligns with real-world attack scenarios where adversaries exploit weak authentication practices to gain a foothold in enterprise Oracle Database systems. As demonstrated in Figure 20, ODAT's `passwordguesser` module was used as a means to conduct a password spraying attack against the Oracle Database target to once again expose an account with the username and password combination values of 'sys/Oracle123', respectively.

Figure 20. Password spraying attack of the Oracle DB target.

Foothold Enumeration by an Internal System Port Scan via `utltcp` Module

Internal network enumeration via port scans is a critical phase in offensive security. It is when an attacker that has already gained initial access to a network attempts to discover active hosts, open ports, and running services within the internal interconnected infrastructure. This process helps identify potential targets and pathways for further exploitation. Unlike external scans, internal port scans operate within the organization’s perimeter defenses, often revealing services or systems that are not hardened against insider threats.

ODAT's `utltcp` module leverages Oracle’s built-in UTL_TCP package, which is typically used for network communication tasks. As shown in Figure 21, the help message output displays all the options the `utltcp` module accommodates. By exploiting this functionality, ODAT can perform internal network port scans directly from a compromised Oracle Database server. The attacker merely needs to specify an IP address and a set of ports to probe to enable ODAT to send crafted network requests to check for active services. This technique allows the compromised Oracle Database itself to act as a pivot point for scanning the network, which may sometimes bypass network restrictions and detection mechanisms. This capability is especially powerful in scenarios where the attacker has compromised the database but lacks direct access to the broader internal network.

Figure 21. ODAT's `utltcp` module help message output.

Prior to conducting the internal network enumeration, ODAT's utltcp module has the `--test-module` option. This option is extremely useful for attackers in real-world attack scenarios as it allows for the module to be tested first before bombarding the target with network traffic, which can result in premature detection by automated internal defense systems. As demonstrated in Figure 22, ODAT's `utltcp` module with the `--test-module` option was executed to determine that the required `UTL_TCP` library is present on the Oracle Database target. Therefore, internal network enumeration may be conducted.

Figure 22. Testing ODAT's `utltcp` module on the target Oracle DB (vulnerable).

As previously mentioned, a Metasploitable Docker instance was running with an IP address of 172.27.0.30. To reiterate, the Metasploitable machine was configured to have ports 21, 22, 80, 445, and 3306 open, which are the FTP, SSH, HTTP, SMB, and MySQL services, respectively. Again, these ports (when misconfigured) are the typical means pentesters or threat actors use to obtain either an initial foothold or an internal system pivot into a target. As demonstrated in Figure 23, ODAT's `utltcp` module with the `--scan-ports` option was executed along with the target IP address (172.27.0.30) and the intended ports (21, 22, 80, 445, and 3306) to be probed. This scan has determined that an internal machine interconnected to the Oracle Database target has a number of ports open for potential further pivoting. To verify the output claimed by ODAT, an NMAP scan was conducted on the Metasploitable machine, which indeed verified the output of ODAT as shown in Figure 24.

Figure 23. Exposing ports opened on an internal system (Metasploitable) interconnected to the Oracle DB target.

Figure 24. NMAP scan to verify opened ports on the Metasploitable machine.

File Download via `dbmsxslprocessor` Module

In offensive security, the ability to download and read files from a target system is a significant step toward gathering sensitive information, escalating privileges, or enabling lateral movement within a network. File access provides attackers with critical insights into a target’s configuration, user accounts, and credentials, which often exposes vulnerabilities or misconfigurations that can be further exploited.

ODAT's `dbmsxslprocessor` module takes advantage of Oracle's DBMS_XSLPROCESSOR package, which allows the database to process XML documents and interact with the file system. By exploiting this functionality, attackers or penetration testers can download and read files directly from the server hosting the Oracle Database. This capability is invaluable, as it bypasses traditional access controls and allows the retrieval of files that would otherwise be protected. As shown in Figure 25, the help message output displays all the options that the `dbmsxslprocessor` module accommodates.

Specific files such as /etc/passwd, which contains user account information on Unix/Linux systems provide details about local users and can aid in further password-based attacks. Similarly, files such as tnsnames.ora, sqlnet.ora, and listener.ora are core configuration files for Oracle databases. As demonstrated in Figure 26, ODAT's `dbmsxslprocessor` module was executed with the `--test-module` option against the Oracle database target to verify that file download attacks can indeed be conducted.

In short, the `dbmsxslprocessor` module in ODAT enables attackers to pivot from database access to file-level access, which significantly broadens the scope of their compromise. By extracting key system and configuration files, attackers can piece together a comprehensive understanding of the target’s environment, identify additional vulnerabilities, and plan their next moves with precision.

This file-centric attack vector demonstrates how seemingly isolated database misconfigurations can escalate into full system compromise. The following screenshots of the file download attacks come in pairs. First, the screenshots show the execution of ODAT's `dbmsxslprocessor` module with the `--get-file` option, and then, the second screenshot consists of the `cat` command to expose the contents of the downloaded file. Figure 27 and Figure 28, Figure 29 and Figure 30, Figure 31 and Figure 32, Figure 33 and Figure 34, Figure 35, and Figure 36 represent file download attacks for the files /etc/passwd, tnsnames.ora, sqlnet.ora, listener.ora, and orapwFREE.

Figure 25. ODAT's `dbmsxslprocessor` module help message output.

Figure 26. Testing ODAT's `dbmsxslprocessor` module on the target Oracle DB (vulnerable).

Figure 27. Obtain copy of the `/etc/passwd` file.

Figure 28. Expose the content of the `/etc/passwd` file.

Figure 29. Obtain copy of the `tnsnames.ora` file.

Figure 30. Expose the content of the `tnsnames.ora` file.

Figure 31. Obtain copy of the `sqlnet.ora` file.

Figure 32. Expose the content of the `sqlnet.ora` file.

Figure 33. Obtain copy of the `listener.ora` file.

Figure 34. Expose the content of the `listener.ora` file.

Figure 35. Obtain copy of the `orapwFREE.ora` file.

Figure 36. Expose the content of the `orapwFREE.ora` file.

File Deletion via `utlfile` Module

In offensive security, the ability to delete files from a target system can be a powerful capability. For an attacker, file deletion can serve multiple purposes, such as disabling system services, corrupting essential applications, or eliminating log files to cover tracks and avoid detection during post-exploitation activities.

ODAT's `utlfile` module leverages the UTL_FILE package, which Oracle traditionally uses to manage file input/output operations on the server file system. By exploiting this package, attackers can not only read and write files but also delete files on the target system. As shown in Figure 37, the help message output displays all the options that the `utlfile` module accommodates.

Using ODAT's `utlfile` module, an attacker can target key files, such as database configuration files, log files, or system-critical resources, to cause disruption or further obscure malicious activities. For example, deleting files such as listener.ora could disable the Oracle listener, which handles incoming database connections, to effectively bring down database services. Additionally, the ability to delete log files or audit trails can impede incident response efforts, which makes it difficult for defenders to detect and trace malicious activity. As demonstrated in Figure 38, ODAT's `utlfile` module was executed with the `--test-module` option against the Oracle database target to verify that file download attacks can indeed be conducted.

As an overview of this simulation, first, a file will be created, then ODAT will be used to upload this newly created file, and finally, ODAT will be used to remove this recently uploaded file.

To kick off this simulation, a sample file named `utlfile_file_upload_test.txt` was created via the `touch` command. Then, the `echo` command was executed to input sample contents in the form of `utlfile` within this created text file. Next, the `cat` command was executed to confirm the created file indeed exists, and its content was verified to be `utlfile`.

These three steps are all encapsulated in Figure 39. As demonstrated in Figure 40, ODAT's `utlfile` module with the `--put-file` option was used to upload the sample text file into the host OS `/tmp/` directory of the Oracle Database target machine.

Before proceeding with the actual file deletion simulation, CLI access to the Oracle Database target machine was used to execute the `ls -al /tmp/` command to indeed confirm that the file was successfully uploaded, as shown in Figure 41. Finally, as demonstrated in Figure 42, ODAT's `utlfile` module with the `--remove-file` option was used to delete the sample file in the host OS `/tmp/` directory of the Oracle database target machine. As confirmed in Figure 43, CLI access to the Oracle Database target machine was once again used, but this time, to confirm that the sample file was indeed successfully deleted.

Figure 37. ODAT's `utlfile` module help message output.

Figure 38. Testing ODAT's `utlfile` module on the target Oracle DB (vulnerable).

Figure 39. Create the sample file for file upload simulation.

Figure 40. File upload simulation via ODAT’s `utlfile` module.

Figure 41. Verification of file upload to the Oracle DB target host.

Figure 42. File deletion simulation via ODAT’s `utlfile` module.

Figure 43. Verification of file deletion on the Oracle DB target host.

Obtain SQL Shell via `search` Module

Obtaining an SQL shell on an Oracle Database is a pivotal accomplishment in offensive security as it provides direct access to interact with the database server and execute SQL queries. From an attacker's or penetration tester's perspective, an SQL shell essentially allows real-time querying, data manipulation, and reconnaissance within the target database environment.

The ODAT tool's `search` module, when used specifically with the `--sql-shell` option, facilitates this process by enabling attackers to interactively execute SQL commands as if they were connected directly via a database client. As shown in Figure 44, the help message output displays all the options that the `search` module accommodates which includes the `--sql-shell` option. This capability can be exploited to extract sensitive data, enumerate database schema, or even create and manipulate user data. As demonstrated in Figure 45, ODAT's `search` module was executed with the `--test-module` option against the Oracle Database target to verify that file download attacks can indeed be conducted.

As shown in Figure 46, ODAT's `search` module was executed with the `--sql-shell` option against the Oracle database target to obtain a fully functional SQL shell. Attackers may now execute several critical commands to achieve their objectives.

A simple yet insightful SQL command to execute is `SELECT * FROM v$version` as shown in Figure 47, which exposes the Oracle Database version, including the release, component, and build information. With this information, attackers may be able to find specific weaknesses and vulnerabilities (e.g. a CVE with a known available public exploit) affected by the particular version/release/build of the target Oracle Database.

Figure 44. ODAT's `search` module help message output.

Figure 45. Testing ODAT's `search` module on the target Oracle DB (vulnerable).

Figure 46. Obtain SQL shell via ODAT’s `search` module.

Figure 47. Obtain Oracle DB banner information via SQL shell.

Figure 48. Obtain Oracle DB accessible tables via SQL shell.

Figure 49. Obtain a list of all Oracle DB available user accounts via SQL shell.

Obtain Reverse Shell via `utlfile` (File Upload) and `externaltable` (File Execution) Modules

Obtaining reverse shell access is a significant milestone in offensive security because it allows attackers or penetration testers to gain command-line control of a target system. Unlike SQL shell access, which is limited to database interactions and query execution, a reverse shell provides access to the operating system of the database server. This level of control enables an attacker to execute system commands, explore the file system, escalate privileges, install persistent backdoors, or pivot further within the internal network.

ODAT facilitates this process using its `utlfile` module for file uploads and the `externaltable` module for file execution. As shown in Figure 50, the help message output displays all the options that the `externaltable` module accommodates.

First, an attacker can upload a payload (e.g. a reverse shell script) to the target system using the `utlfile` module. Once the payload is placed on the server, the `externaltable` module can be leveraged to execute the uploaded file, which effectively triggers the reverse shell connection back to the attacker's machine. As demonstated in Figure 51, ODAT's `externaltable` module was executed with the `--test-module` option against the Oracle Database target to verify that file execution attacks can indeed be conducted.

For example, a file with a `sh` extension will be created with its contents containing a reverse shell script. Then ODAT's `utlfile` module will be used to upload this reverse shell file into the compromised Oracle database host machine, and finally ODAT's `externaltable` module will be used to execute the reverse shell script to ultimately obtain a reverse shell.

Let’s look at this five-step simulation.

First, reverse shell file named `sample_reverse_shell.sh` was created via the `touch` command. Second, the `echo` command was executed to input reverse shell one-liner command into the `sh` file. Third, the `chmod` command was executed with the `+x` parameter to provide the reverse shell script execution rights. The fourth step sees the `cat` command executed to confirm the created file indeed exists, and its content is verified to have the correct contents. Fifth, the `ls -al` command was used to ensure that the execution permissions were provided to the reverse shell script as intended.

These five steps can be seen in Figure 52. As demonstrated in Figure 53, ODAT's utlfile module with the `--put-file` option was used to upload the reverse shell file into the host OS `/tmp/` directory of the Oracle database target machine. Before proceeding any further, a Netcat listener was started on port 9001 to anticipate the reverse shell script execution (as intended in this simulation) as shown in Figure 54. And then, as demonstrated in Figure 55, ODAT's `externaltable` module with the `--exec` option was used to execute the reverse shell file in the host OS `/tmp/` directory of the Oracle Database target machine. Finally, as shown in Figure 56, the Netcat listener was successfully activated to spawn a fully functioning reverse shell. For educational purposes, Figure 57 shows how the reverse shell code was generated via the web resource ‘www.revshell.com’.

This reverse shell allows attackers to have substantial control of the server's operating system. With a reverse shell, attackers can manipulate system files, run native OS tools, and establish deeper footholds for persistence or lateral movement within the network. This expanded access significantly increases the attacker's capability to exploit misconfigurations, exfiltrate sensitive data, and pivot to other systems. The ability to transition from database exploitation to full system compromise demonstrates the critical importance of securing database servers, as their vulnerabilities can quickly escalate into a broader system-wide breach.

Figure 50. ODAT's `externaltable` module help message output.

Figure 51. Testing ODAT's `externaltable` module on the target Oracle DB (vulnerable).

Figure 52. Create the reverse shell script file for reverse shell simulation.

Figure 53. File upload of the reverse shell script to the Oracle DB target host via ODAT’s `utlfile` module.

Figure 54. Starting the Netcat listener on port 9001.

Figure 55. File execution of the uploaded reverse shell script file via ODAT’s `externaltable` module.

Figure 56. Obtain reverse shell access to the Oracle DB target host.

Figure 57. Reverse shell generator used for this simulation.

ODAT Demonstration in a CTF Box (HTB: Silo)

A perfect opportunity to use ODAT is in Capture-The-Flag (CTF) platforms that host machines with a vulnerable and/or misconfigured Oracle Database. A specific example would be the CTF machine called Silo. The Silo machine centers its challenge around the exploitation of an Oracle Database to secure a foothold into a system. Silo was initially designed to be solved manually through the application of various tools and techniques. However, ODAT significantly streamlines the enumeration and exploitation process. ODAT transforms what was intended as a mid-level difficulty machine into a considerably more accessible challenge by automating intricate tasks and minimizing the need for manual intervention, therefore reducing the overall difficulty of the machine.

To preserve the thrill that comes with the enumeration routine and the satisfaction of obtaining crucial information that leads to further one's position in an exploitation process, critical data within the following screenshots will be redacted with a red box. In the demonstration shown in Figure 58, ODAT was successfully installed and was swiftly executed against the Silo machine via the `sidguesser` module, which exposed the SID value. The SID value was then used as a parameter in the follow-up attack to the Oracle database target via ODAT's `passwordguesser` module, exposing a valid username and password credential pair as shown in Figure 59. Finally, the SID value and the credential pair were then used as parameters by the sqlplus CLI tool to successfully obtain SQL shell access to the Oracle Database as shown in Figure 60.

Figure 58. Exposing the SID of the Oracle DB target on the Silo CTF machine.

Figure 59. Exposing valid user account credentials of the Oracle DB target on the Silo CTF machine.

Figure 60. Obtain SQL shell access to the Oracle DB target on the Silo CTF machine.

Conclusion

ODAT stands as a great representation of the perpetual evolution of penetration testing tools. ODAT demonstrates its ability to handle the sophistication of Oracle Database exploitation with the simplicity and flexibility of Python. By consolidating the complexities of Oracle Database-specific attack vectors into a single Python tool, ODAT empowers penetration testers, security professionals, and threat actors to systematically uncover vulnerabilities, misconfigurations, and insecure practices in one of the most robust database platforms in the world.

ODAT integrates a comprehensive suite of modules catering to pre- and post-exploitation phases from SID enumeration and credential brute-forcing to file manipulation and even reverse shell creation. Its modular design and overlapping functionalities ensure adaptability, which offers multiple pathways to exploit Oracle databases based on the target’s specific configuration. Whether it’s enabling lateral movement through network scanning or abusing unpatched vulnerabilities like TNS poisoning, ODAT transforms what could have been an arduous process into a structured and efficient workflow.

Trustwave's dbProtect and AppDetectivePro products have comprehensive coverage for many of the aforementioned misconfigurations and vulnerabilities in this article. Specifically, many of the CVEs (eg. CVE-2012-3137, CVE-2012-1675, CVE-2014-4237, CVE-2018-3004, CVE-2018-300, etc.) that ODAT has exploited are addressed in a timely manner due to having dedicated Trustwave SpiderLabs security researchers constantly keeping abreast with Oracle Critical Patch Updates (CPU) annual quarterly schedules to update Trustwave products with the latest protections available. Moreover, the specific weaknesses and vulnerabilities (e.g. default SID values, default account credentials, misconfigurations, disabled security, missing patches, etc.) demonstrated in the simulations are also addressed through our products’ comprehensive scanning, detection capabilities, and extensive database activity monitoring.