Not enough people know about the Audit and Threat Detection feature in Microsoft Azure. So, I’m hoping to help spread the word today. I decided to write a post to help explain the Microsoft Azure Threat Detection types.

First, you should know that it is crazy simple to enable Audit and Threat Detection for your Azure SQL Database. All you need to do is navigate to your Azure SQL instance, locate ‘Auditing & Threat Detection” in the left column, enable the features, point to a storage account, add an email address, and click ‘Save’. That’s it, you are done.


Enable audit and threat detection for azure


If you hate GUIs but love security, then you are in luck because you can enable the feature using Powershell, if desired. If you click on the ‘Threat Detection Types’ you will see a blade and the following options:


Azure Threat Detection Types


There are no descriptions for any of these threat types. Here is the documentation for the feature, they don’t mention these types there, either. That’s why I’m writing this post, so that you can understand more about those types.

Azure Threat Detection: Anomalous Client Login

The Audit and Threat Detection service will detect unusual and high-risk access activities. This detection is based upon behavioral analytics and anomaly detection. Here are some examples:

– If someone has logged in from an unusual location (so, a change in the access pattern)
– If a new user has logged in for the first time (so, a change in the access patterns of database principals)
– The attempt to brute force credentials (Say, a high number of failed logins with different credentials)
– A potentially harmful application was used to access the database

Here’s what an anomalous login alert could look like:




Azure Threat Detection: SQL Injection Vulnerability

This threat detection type indicates that your application has generated a faulty SQL statement in the database. This is an indication that your application is vulnerable to a SQL injection attack. There are a few possible reasons for the generation of a faulty statement:

– There exists a defect in your application that is causing the faulty SQL statement
– User input is not being sanitized properly, resulting in a faulty SQL statement
– You are not using parameters in your dynamic SQL
– You are not using stored procedures

When the Threat Detection service sees this activity, it logs it as a vulnerability. The service will alert you, giving you a chance to investigate and remediate the issue before it is exploited. Think of SQL Injection Vulnerability as a warning signal, telling you in advance to fix the issue before it becomes a problem.

Azure Threat Detection: SQL Injection

This SQL Injection threat type is triggered when an active exploit is happening against an identified vulnerability. SQL injection attacks are often a random series of SQL statements in an effort to see what, if any, data can be returned. An attacker will start with a series of statements that will return pieces of information that they can then use to build upon their attack statements, ultimately resulting in a significant data breach. The Treat Detection service will alert you when the attack is happening. However, the service will avoid filling your inbox. It will only send so many emails per hour. So, if you get an email, you should act upon it quickly. Just because you didn’t get an email for a few minutes doesn’t mean the attack has stopped.

You can use the following demo application to simulate both alerts.

All of these alerts can be easily found in the Azure Security Center. You can view threats detected against a database, instance, or even the subscription level.



Take a moment and think how you are currently monitoring for SQL injection attacks. Chances are the answer is “we aren’t”. The Audit and Threat Detection feature in Microsoft Azure is worth the effort to migrate your workloads to Microsoft Azure.

Data security and privacy should be your top priority. Microsoft Azure is making it easy for you, all you have to do is enable the feature and input an email address.

It’s that easy to help protect yourself against SQL injection attacks.