SANS Digital Forensics and Incident Response Blog

SQL Rootkits

by Craig Wright

The traditional means of recovering a compromised system has been to rebuild the server and to reload the data. Rarely is the data validated to any extent in this process. In fact, many organizations have no idea of their data structures and it is rare to even find an up to date ERD (Entity Relationship Diagram). With T-SQL, PL-SQL and other extensions to the SQL language, this is a dangerous approach.

Trojanised SQL statements in databases are still fairly rare (at least outside of Gaming, Media and Finance — areas where money is easily made), but they are becoming more common. As we start to lock both web servers and networks down, new threats evolve. Being that databases are often the target of an attack and hold both authentication information and valuable data, it is surprising that more effort has not been directed this way. But this is changing.

Some of the more common uses of a database rootkit include:

  • Altering database objects and tables
  • Changing the indexes, keys and constraints
  • Adding and removing triggers
  • Modifying the execution path in the database
  • Creating database users or even hiding them
  • Injecting stored procedures

Databases are rarely (I am yet to see one) set to use ANSI SQL. The benefits that are obtained through the use of SQL extensions are too great. These extensions extend the database application into a smaller semi-contained operating system. PL-SQL and T-SQL statement calls can be used to:

  • Access the underlying operating system files and registry
  • Connect to the network
  • Schedule programs and stored procedures

A stored process could be created in order to SPAM networks, port-scan systems and about anything else you can think of.

There are some commercial tools that do aid in checking databases:

· DB Audit ( is easy to tailor and does not require installation of any additional software or services on the database server or network. It supports Oracle, Microsoft SQL Server, Sybase ASE, Sybase ASA and IBM DB2. It is implemented on the database back-end to reduce the risk of back door access that would be unrecorded.

· Lumigent Audit DB ( provides comprehensive monitoring and auditing of data access and modifications. It provides an audit trail of who has accessed or modified what data, and supports best auditing practices including segregation of duties. Audit DB supports IBM DB2, Microsoft SQL Server, Oracle and Sybase databases.

· DbProtect by Application Security ( uses a network-based, vulnerability assessment scanner to test database applications. It also provides structured risk mitigation, and real-time intrusion monitoring, coupled with centralized management and reporting. DbProtect provides security and auditing capabilities for complex, diverse enterprise database environments.

The difficultly is that none of these really addresses the full range of what an attacker can do. Hence it comes to knowing your system.

This is where CASE (Computer Aided Software Engineering) tools for Databases come to the forefront. By displaying visual objects, colors and better diagrams may all be introduced to further enhance the analyst's capacity to review the database structure and hopefully uncover a rootkit. Reverse engineering a database helps as you gain knowledge of the various structures that have been created within the database. Some of these include:

  • The indexes,
  • Fields,
  • Relationships,
  • Sub-categories,
  • Views,
  • Connections,
  • Primary keys and alternate keys,
  • Triggers,
  • Constraints,
  • Procedures and functions,
  • Rules,
  • Table space and storage details associated with the database,
  • Sequences used and finally the entities within the database.

The level of security inside many databases has changed little over the last decade, instead trusting that the network and application servers will be sufficient. This is far from a good approach. To this end, Pete Finnigan has numerous good papers about Oracle security on his site.

Next time you have to restore a compromised system, think about checking the data as well. Even better, plan ahead and start by mapping and monitoring the database now.

Craig Wright is a Director with Information Defense in Australia. He holds both the GSE-Malware and GSE-Compliance certifications from GIAC. He is a perpetual student with numerous post graduate degrees including an LLM specializing in international commercial law and ecommerce law as well as working on his 4th IT focused Masters degree (Masters in System Development) from Charles Stuart University where he is helping to launch a Masters degree in digital forensics. He is starting his second doctorate, a PhD on the quantification of information system risk at CSU in April this year.


Posted March 27, 2009 at 12:55 PM | Permalink | Reply


That's a lot to worry about. In the past, I created an automated text comparison of the schema. Whenever a table, field, stored procedure, or trigger was added or deleted, I got an email. I thought that worked well.
Now I see there is so much more. Thanks.