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.
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
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“
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.
Once the log file has been cleared the Incident will be created.
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:
AzureActivity | 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.
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 “portal.azure.com” with a valid user account, but with the wrong password 5 times or more.
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:
Have any other methods you use to generate test Incidents? Let me know.
[Subscribe to the RSS feed for this blog]
[Subscribe to the Weekly Azure Sentinel Newsletter]