FalconFriday — Code execution through Microsoft SQL Server and Oracle Database — 0xFF19

During red teaming engagements we often encounter database credentials in, for example, database scripts. These can be used to authenticate to databases and gain access to the data in these databases.

Moreover, if the associated users are sufficiently privileged, this may yield you a nice code execution on a server. Plenty has been written on how to abuse such credentials, and well-known tools include the ‘Impacket’ toolkit published by SecureAuth and various exploits published by Raptor.

In this blog we will discuss how you can detect abuse of these code execution features of Microsoft and Oracle databases, using Microsoft Defender for Endpoint log sources on the Microsoft 365 Defender platform.

Microsoft SQL Server

MS SQL Server has a system stored procedure to execute operating system commands: xp_cmdshell. This stored procedure is disable by default, but can be enabled remotely if the user has sufficient permissions.


Using xp_cmdshell, you can execute commands on the operating system as if you are in a command shell. An excellent tool for this is the Impacket mssqlclient.py, which streamlines enabling and using xp_cmdshell from the command line.

If the user you obtained is member of the ‘sysadmin’ role, the commands will be executed using the permissions of MS SQL Server, usually giving you full control of the system.


From a defensive perspective, it is quite difficult to monitor the usage of xp_cmdshell directly, as this does not show up in the default (system) logs that are ingested. However, we can monitor for the cmd.exe process spawned by sqlserver.exe, which results from the usage of xp_cmdshell.

| where InitiatingProcessParentFileName =~ "sqlservr.exe"
| where InitiatingProcessCommandLine startswith "\"cmd.exe\" /c";

These base events can then be further filtered by matching against known lolbins, recon bins or low-prevalence files — as can be seen in our rule on GitHub.

Oracle Database

While Oracle Database does not have a direct code execution feature like Microsoft SQL Server, it does support the addition and execution of Java code within the Database Management System. This feature can, with sufficient permissions, be used to obtain code execution on the Oracle server.


By uploading custom Java routines, you can gain command execution on Oracle servers. An excellent set of routines for these are raptor’s raptor_ora. These can be easily installed and used from the command line through Oracle SQL*Plus and grant file-system access (read/write) as well as the ability to execute arbitrary binaries.


As an adversary can theoretically load an entire malware suite into Java, it is a lot harder to monitor for abuse of this functionality. However, if we assume that the adversary will at some point interact with the operating system, we can monitor for unexpected binaries being executed by the Oracle process.

| where InitiatingProcessFileName =~ "oracle.exe"
| where not(FileName in~ ("conhost.exe", "oradim.exe"))

It is a simple rule, but in our experience it provides sufficient leads.

There can be legitimate commands being executed by Java routines, which are part of developed applications. These will need to be whitelisted on a case-by-case basis. In our testing we noticed that conhost.exe and oradmin.exe are regularly called, so these are whitelisted, but you would need to validate this for your own environment.

You can find the full rule here on GitHub.


While you cannot always look inside every application from your monitoring solution, you can monitor their impact on the system. By keeping an eye on the commands and binaries being executed by trusted, high-privileged programs, you can detect such suspicious behavior sooner.

Of course, and most importantly: the privileged credentials which allow you to execute privileged procedures like xp_cmdshell or adding and executing Java code to Oracle should be kept very secure. Any account with such permissions basically has full control over the affected database servers, even though they may not have direct local administrator permissions on the system.

Knowledge center

Other articles

Together. Secure. Today.

Stay in the loop and sign up to our newsletter

FalconForce realizes ambitions by working closely with its customers in a methodical manner, improving their security in the digital domain.

Energieweg 3
3542 DZ Utrecht
The Netherlands

FalconForce B.V.
[email protected]
(+31) 85 044 93 34

KVK 76682307
BTW NL860745314B01