A request was made recently about how to prevent an unauthorized and elevated user account from getting access to Azure Sentinel. Essentially, the scenario is this:
- An environment was compromised.
- A compromised user account had elevated access.
- The compromised user account shut down monitoring (Azure Sentinel) so as not to be detected.
I’m still working the full process out completely from a best practices perspective, but here’s one method of using an Azure Monitor Alert as a backup notification method when someone unauthorized does something in Azure Sentinel.
This is yet another case of using the tools you have (and knowing they exist) and keeping it simple.
Setting up the Azure Monitor Alert
In the Azure portal, got to Azure Monitor, then to the Alerts blade, then click to start creation of a New Alert Rule.
On the main Alert Rule creation screen, choose Log Analytics Workspaces as the resource to alert against. And, choose the Log Analytics workspace to use.
IMPORTANT: Consider this. Because we’re creating a backup alerting process, you will also want to create a backup (secondary) Log Analytics workspace and a second Diagnostic Setting for the Azure Activity log. You don’t want to rely on the same Log Analytics workspace assigned to Azure Sentinel in the event the compromised user account does something extra nasty to cover their tracks, such as wiping out the Azure Sentinel Log Analytics workspace. This extra workspace will cost extra (not including in the Azure Sentinel costs – of which the Azure Activity Connector is free anyway), so keep that in mind. But, for security monitoring and alerting purposes, it’s probably worth the cost if this is an actual concern of your organization.
Next, configure the Signal Logic. For our purposes, choose Custom log search.
Next, on the signal logic configuration screen, enter a custom query. You can use the following query that allows you to generate a whitelist of users who should be authorized to perform actions in Azure Sentinel. If it finds a user account not in the whitelist, it will issue an alert. Note that it is querying against the AzureActivity table, looking for successful Administrative operations for SecurityInsights.
//Create a whitelist of users who should be able to access Azure Sentinel, then check to see if unauthorized users have performed activities.
//Replace the users in the variable for AuthorizedUser with authorized accounts. Authorized account format is gleaned from AzureActivity/Caller
let List = datatable(AuthorizedUser: string)["user1@domain.com", "user2@domain.com", "user3@domain.com"];
let timeframe = 1d;
AzureActivity
| where OperationNameValue has "MICROSOFT.SECURITYINSIGHTS"
| where ActivityStatusValue == "Success"
| where CategoryValue == "Administrative"
| join kind= leftanti (
List
| project Caller = tolower(AuthorizedUser)
)
on Caller
| extend AccountCustomEntity = Caller
| extend IPCustomEntity = CallerIpAddress
