How to Generate Azure Sentinel Incidents for Testing and Demos

Do you want to generate an Incident in Azure Sentinel for testing/demoing? Here’s a couple easy ways to do it. These are a few of the methods I use (and have customers use) after building a customer lab. Additionally, I may update this post from time-to-time to include more methods and I’m only going to share methods that aren’t harmful. For the methods that work against a computer or VM, please consider using a temporary system that’s not part of a production environment.

AppLocker Bypass

With Azure Security Center data connection enabled and the Log Analytics agent installed, from the agented workstation or VM run the following against a system file. In my example I’m running it against the PrintIsolationProxy.dll file, but it can be any system file that exists in the System32 directory of a Windows machine.

regsvr32.exe /s /u /i:test.sct PrintIsolationProxy.dll
Incident created against AppLocker Bypass Detection

Detection of Clearing of the Security Event Log

This one also requires an agented system with the Azure Security Center Data Connector enabled.

Make sure to enable the Analytics Rule titled: “Security Event log cleared

Analytics Rule to Enable

Now, on the agented Windows system, clear the Security Event log. Of course, you can automate this through PowerShell or some other mechanism, but here it is in the system’s Event Viewer.

Clear the Security Event Log

Once the log file has been cleared the Incident will be created.

Event Log cleared Incident

P.S. Don’t forget – if you want to investigate Defender generated Incidents in Azure Security Center, you have to ensure some additional access is applied. See: How to Apply the Proper Role to Allow an Analyst to Investigate Azure Sentinel Incidents in Azure Defender

Cloud Shell Execution

Create an Analytics Rule using the following KQL query:

| where ResourceGroup startswith "CLOUD-SHELL"
| where ResourceProviderValue == "MICROSOFT.STORAGE"
| where ActivityStatusValue == "Start"
| extend action_ = tostring(parse_json(Authorization).action) 
| summarize count() by TimeGenerated , ResourceGroup  , Caller , CallerIpAddress , ActivityStatusValue
| extend AccountCustomEntity = Caller
| extend IPCustomEntity = CallerIpAddress

Set the Analytics Rule schedule very aggressive, i.e., run every hour (or sooner), looking up data in the last 1 day.

Run Azure Cloud Shell and the following Incident will be created.

Cloud Shell execution monitoring

Brute force attack against Azure Portal

Enable the “Brute force attack against Azure Portal” Analytics Rule, which requires that you have the Azure Active Directory Connector enabled for the SigninLogs.

Access “” with a valid user account, but with the wrong password 5 times or more.

Brute force attack against the Azure portal

Using Microsoft Cloud App Security

Its awesome to me how active this Azure Sentinel community is and how willing everyone is to share their fabulous creations. In response to my list here in this blog post, Paul Rouse has posted his own method of generating demo data using MCAS.

Read it here:

How to easily generate test Incidents in Azure Sentinel using Microsoft Cloud App Security

[SAMPLE] Defender Alerts

If you have Azure Security Center/Defender connected to Azure Sentinel, you can go into Azure Security Center in the Security Alerts blade and generate Sample alerts.

Creating sample alerts

Make sure you have bi-directional sync enabled to ensure when you close out an Incident in Sentinel is also closes it out in Security Center. The following image shows how the alerts look once available in Azure Sentinel.

Sample alerts in Azure Sentinel

URL Detonation

This is a fantastic method for generating URLs in Incidents to show how Azure Sentinel performs URL Detonation. This is the brainchild of my good friend Matt Egen.

Create a Watchlist with valid URLs that can be captured.

Watchlist for URLs

Then, create an Analytics Rule with the logic that simply displays the URLs from the Watchlist.

Create an Incident with URLs

Once the Analytics Rule kicks off, you’ll get an Incident created that contains the captured/screenshotted URL image.

Defender for Endpoint

With Defender for Endpoint enabled on a system and the Defender Connector enabled in Azure Sentinel, run the following PowerShell command:

powershell.exe -NoExit -ExecutionPolicy Bypass -WindowStyle Hidden $ErrorActionPreference= 'silentlycontinue';(New-Object System.Net.WebClient).DownloadFile('', 'C:\\test-WDATP-test\\invoice.exe');Start-Process 'C:\\test-WDATP-test\\invoice.exe'

This will generate a test incident in Azure Sentinel that can then be investigated in Defender for Endpoint.

Go investigate in Defender for Endpoint

Fake Malware File Type

In Defender for Endpoints, create a custom detection. You can see in the picture, I’ve created something extremely simple. The query simply looks for .kke files. Now, all I have to do is drop a file with any file name, but with a .kke extension on a managed device, run a full scan, and an alert is raised.

Custom Detection

With the Microsoft 365 Defender data connector enabled, the alerts flow directly into Azure Sentinel.

The Defender for Endpoint to Azure Sentinel connection

Have any other methods you use to generate test Incidents? Let me know.


[Want to discuss this further? Hit me up on Twitter or LinkedIn]

[Subscribe to the RSS feed for this blog]

[Subscribe to the Weekly Azure Sentinel Newsletter]