In recent breach incidents, threat actors have been observed not only accessing systems, but also directly querying internal databases and stealing sensitive information. Particularly, more threat actors are installing DB client tools directly on targeted systems to exfiltrate data, and legitimate tools such as DBeaver, Navicat, and sqlcmd are being used in this process.

 

These behaviors are easy to disguise as those of a legitimate administrator, making them difficult to detect. Traces of the leak can only be confirmed through some system logs, local records of client tools, and execution logs of SQL servers.

 

Furthermore, DB client tools require users to explicitly set the database address (IP), port, and account credentials (ID/PW) to operate normally. Therefore, the use of such tools indicates that the threat actor had already obtained all the necessary information to access the database. This may suggest that the threat actor had moved on to the information gathering and exfiltration stages.

 

This report analyzes the characteristics and traces of DB client tools that are installed directly by threat actors in breached systems, and the logs that are generated by these tools and the responses and detection methods that are available from a security perspective. The analysis is based on a simulated environment with an MS-SQL environment.

 

Analysis by Tool

This report covers only DBeaver, Navicat, and sqlcmd tools for which cases of threat actor exploitation have been identified. Each tool has been tested in its latest version in a Windows environment, and the log location and file name may vary by version.

 

Tool	Version
DBeaver	25.0.4
Navicat for Premium	17.2.5
sqlcmd	N/A(LOLBins)

Table 1. Version information of tools used in the test

 

DBeaver

DBeaver is an open-source tool that supports various relational databases. It is a GUI-based application that provides features such as query execution, data lookup, and export.

 

Figure 1. DBeaver program

 

System and Log Traces

Whether data has been exfiltrated using DBeaver can be checked through the ‘dbeaver-debug.log’ and ‘.log’ files.

 

DBeaver allows users to export query results or entire tables as files in various formats such as CSV, Excel, and JSON through its built-in export feature. These export activities and user behaviors can be traced through debug logs, which are useful for tracking traces related to data breaches. The debug logs record not only the data export history, but also the DBeaver version, installation path, execution time, and termination time.

 

Figure 2. Data export feature of DBeaver

 

• Path: C:\Users\<Username>\AppData\Roaming\DBeaverData\workspace<Version>\.metadata\dbeaver-debug.log
• File Name Pattern: ${table}_${timestamp}

 

The “Export to the new file” string in the debug log allows users to trace the export of their data, along with detailed information such as the file name. Even if this log does not exist, the connection history of when a user accessed which database is still recorded. This can be used to determine whether a non-administrator user accessed a sensitive database at a specific time.

 

Figure 3. Trace of data export from DBeaver debug logs (dbeaver-debug.log)

 

The .log file records system errors and exception information that occur while DBeaver is running. This includes information such as DB connection failures, driver loading errors, and SQL syntax errors. This allows users to check whether the threat actor actually accessed the DB and whether their attempts to exfiltrate data were successful.

• Path: C:\Users\<Username>\AppData\Roaming\DBeaverData\workspace<Version>\.metadata\.log

 

Case Used

The threat actor accessed the affected system via RDP and then searched for and installed DBeaver in a web browser. Afterward, they extracted data in the format of the default save file name, ‘${table}_${timestamp}.txt.’ Some of the queries executed by the threat actor during this process were identified through the .log file. These included queries that were not executed due to a lack of access permissions and failed attempts caused by SQL syntax errors. This information indicates that the threat actor conducted multiple test operations.

 

Figure 4. History of the threat actor installing the DBeaver program

 

Figure 5. Query not executed due to lack of access permission (.log)

 

Figure 6. Query not executed due to a syntax error (.log)

 

Navicat

Navicat is a software developed by PremiumSoft that supports various databases and provides features such as SQL queries and data export. While the tool is commercial, it offers a 14-day free trial, making it popular among threat actors. Navicat version 17 was used in this tool test.

 

Figure 7. Screen of Navicat being executed

 

System and Log Traces

When using Navicat in a Windows environment, details of the export task are not saved in the default log file. If there is a profile file in the ‘.nexptmssql’ format that saves the export settings, the export task can be indirectly estimated by using this file. The file includes the target table and query results, and it is stored in an XML-based structure. ‘TargetName’ and ‘TargetfilePath’ each contain information about the name of the exported table and its location.

 

Figure 8. Export history that can be checked in Navicat (.nexptmssql)

 

• Path: C:\Users\Administrator\Documents\Navicat\SQL Server\Servers\<Server Name>\<DB Name>\<Schema Name>\
• Saved File Name: <File Name>.nexptmssql

 

On the other hand, in the Linux environment, the exported details can be checked via the LogExport.txt file. However, this log is not cumulative and is overwritten each time it is run. Therefore, caution is needed when tracing the activity history over a long period or identifying the threat actor’s past activities.

 

• Path: . /home/your_username/.config/navicat/Premium/Logs
• Saved File Name: LogExport.txt

 

Case Used

The threat actor accessed the system with RDP and a reverse tunneling environment. After gaining access, the threat actor installed Navicat version 17 to access the DB, and used the SELECT statement to query the number of rows in the table where user information is stored. The threat actor then used the Export feature to save the data in the table in the form of a <DB name>.mdb file, which was then used to store the data in the table and exfiltrate it externally.

 

Figure 9. Table query history identified in LogHistory.txt

 

Figure 10. Table extraction history found in LogExport.txt

 

sqlcmd

sqlcmd is a command-line database management tool provided by Microsoft SQL Server, and it is installed by default when configuring the SQL Server environment. It is also classified as a Living off the Land Binary (LoLBin), which is a legitimate executable that threat actors can misuse. Threat actors use sqlcmd to send SQL query commands and perform actions such as table queries and database backups when exfiltrating information from MS-SQL environments.

 

System and Log Traces

Credentials are required to use sqlcmd to back up databases and tables. MS-SQL uses two authentication methods: Windows Authentication (local account) and SQL Authentication (sa account). The sqlcmd command options used differ depending on the authentication method.

 

Option	Description
-S	Entering the address and port of SQL Server
-U	Setting SQL server login account (SQL authentication)
-P	Setting password
-d	Settings the name of the database to connect
-Q	Specifying the SQL query to execute
-s	Setting column separator
-E	Windows account authentication

Table 2. Key options utilized by threat actors when backing up MS-SQL

 

Feature	Command Example
Windows credentials authentication	sqlcmd -S localhost -E -Q “BACKUP DATABASE [Test] TO DISK=’C:\Test.bak’ WITH INIT
SQL credentials authentication	sqlcmd -S 192.168.0.1,1433 -U sa -P password -Q “BACKUP DATABASE [Test] TO DISK=’C:\Backup\Test.bak’ WITH INIT

Table 3. Example of sqlcmd commands according to MS-SQL authentication methods

 

To authenticate with Windows authentication, use the -E option. This option performs authentication as the current user of the Windows session without requiring additional credentials. However, if the command prompt is running with SYSTEM privileges due to privilege escalation, Windows authentication cannot be performed, and the sqlcmd command will fail.

 

Figure 11. Authentication failure log when executing the sqlcmd command with SYSTEM privileges

 

When backing up a database using the BACKUP query with the sqlcmd command, you can check the backup history in the trc and Error logs, which are the key logs of MS-SQL.

 

• Path: C:\Program Files\Microsoft SQL Server\MSSQLXX.<InstanceName>\MSSQL\Log
• Stored file name: ERRORLOG.*/ log_*.trc

 

Figure 12. Trc log when backing up the database using the sqlcmd command

 

Figure 13. Error log when backing up the database using the sqlcmd command

 

Case Used

After gaining control over the MS-SQL server, the threat actor created a batch script file. The batch script contains commands using sqlcmd to query and store table information. The threat actor then executed the batch file with administrator privileges to store the table information within the database in the format [Table Name].dat and exfiltrated it externally. However, when the table query result is saved as a file using the SELECT statement, the logs related to MS-SQL do not show any history. But multiple records were found in the SRUM artifact showing that the sqlcmd.exe process had communicated with various data. This is considered to be a record of communication that occurred during the data query process.

 

Figure 14. Contents of the batch file used by the threat actor for sqlcmd command

 

Figure 15. Network communications history of sqlcmd

 

Conclusion

In addition to the tools mentioned above, threat actors can use various DB client tools to query data within a database after breaching a system. Since these DB client tools are also used in normal operation, detecting their use through anti-malware products is practically difficult.

 

From the perspective of responding to a breach, it is crucial to analyze the system and log traces described above to quickly identify what data the threat actor accessed and what information was leaked. If the use of DB client tools is not necessary in an organization’s environment, behavior-based security solutions such as EDR can be utilized to detect the creation and execution history of these tools. It is also effective to regularly check the DB logs in the infrastructure to ensure that there is a backup history for the DBs and tables.

 

It is also important to actively utilize the access control features provided by the DBMS. Database accounts should only be given the minimum permissions that each user needs, and access should be restricted to specific administrator IPs.

 

Lastly, sharing DB connection account credentials via email, or storing them in Excel or text files, can easily lead to their theft by threat actors, so these practices should be strictly avoided. Poor management practices like these can result in a massive data breach, so it is crucial to prevent them from the beginning.