Using Azure Application Insigths in Vulnerability Analysis

One of the tools that are commonly created in hosted web applications, Azure Application Insigths, is underutilized by the development, operations and security teams.

What is possible with App Insights?

App Inisgths captures logs and performs tasks to evaluate web app performance, stability and usage statistics.

When compared to other common tools with Google Analytics, it is important to remember that App Insigths also works as an APM (App Performance Monitoring) detailing functions and lines of code such as database calls, which are causing slowdowns.

He particularly liked some Smart detection settings functions that are common rules for detecting trends or problems, as well as metrics and Live Metrics as below. Alias, see that the contact page already demonstrates a simulated attack in the contact page call:

Another interesting function that I use frequently in projects is Avaliabiliy where we can create test rules with specific pages in different locations of Azure to work like the old Global Monitoring Service.

The focus of this post is not detailing the functions of APM, but its use by the security team.

How is App Insights useful for Security?

First we have the Application Map where we start the analysis. Basically it’s a simple model of dependencies and communication from within and without, including the availability analysis we’ve shown earlier.

But when removing the WAF to generate the logs and demonstrate in this post, the result was very fast as can be seen in the diagram below.

Note that the two addresses at the bottom are unknown sources and could be attacks, while you also clearly see crawlers and robots from Google and another site, but these would not be the problem.

By asking above for the package details and communication exchanged with my blog with this address it is possible to see what they tried and how many times.

The next step is to click on Samples or on the list on the right side to analyze the queries that were received.

As can be seen below, it is possible to identify where and how the access was carried out by this domain that was analyzing the details.

But let’s keep it running longer with the WAF disabled and we’ll see it with a detailed history.

Validating real attacks

Now with more time exposed (as we like to take risks ) my blog could have more data to be demonstrated.

Let’s open in detail the items on the map where they showed the statistics of crashes.

On the first details screen we see that just from failures in the last 24 hours I received more than 11 thousand calls!!!

But joy turns to sadness, or rather worry, these 11290 calls are actually part of an attack orchestrated by brute force…

Now let’s get a better understanding of what they’re trying to do on my blog. For that, let’s do a “walk” through the App Insigths data.

On the left side we can already see that the attacks were made by trying to send parameters and lists directly on the blog pages.

Opening up more details I can find out that the source of the attack is PCs in China using a specific SDK. In some cases it is also possible to see the IP and thus create a blocking list or potential attackers.

Here is another more recent example that had almost the same origin (another Chinese city), but with details of sophistication where a script was used and not just a SQL Injection :

Continuing the walk I can see the sequence that the "user" used on my site, see that the list of attempts was long, and often on the same page:

The attack on the screen above is a very common SQL Injection to be used on websites by attackers. See details in CAPEC – CAPEC-66: SQL Injection (Version 3.5) (mitre.org)

What to do when detecting an attack on the website, website or application?

In general the Web Application Firewall handles most of the attacks we’ve seen happen on my blog in 24 hours, so much so that I had no idea before that they could reach almost 12,000 in just 24 hours.

But even if you have a WAF it is important that you constantly monitor the number of page failures to identify if it is an application problem or an attack that is trying to find vulnerabilities, like the examples above on my site.

Another important action is to help developers and not accept commands directly from POST, much less concatenate strings into internal parameters and commands.

Also use a robust development library, for example in my exposure test I didn’t have the blog invaded because the .NET itself already has filters to avoid commands sent directly in the POST or URL.

As a more sophisticated feature for targeted attacks, see the Create Work Items option where you can create automations, for example, stop a certain service or even bring down a server when you detect a very big anomaly!

Remembering that App Insights integrates with Log Analytics for queries and Sentinel for smart Threats security!!!!

Conclusion

If you don’t know, don’t have enabled or don’t use App Insights start now!

Don’t limit yourself to performance analytics and sessions, learn to also read the signs of security breaches before an intrusion occurs.