Forum Discussion
Marc_Jacquard
Jul 16, 2021Copper Contributor
Azure Sentinel rule to identify if user has not produced any events in 60 days
I am working on a rule that uses a watchlist of elevated accounts. What I am trying to create is a rule that will tell me if one of these elevated accounts has not been used in over 60 days so we can...
- Jul 20, 2021Assuming you have just listed your userprincipalnames in your watchlist, and your on premise account is just part before the @ then these two should work. When joining you need to have a column that matches on both sides (your query and your watchlist). For signinlogs userprincipalname is fine because that's what Azure AD uses to identify people. We will just rename userprincipalname to username to match your watchlist. I added ResultType = 0 to only get successful signins, but you can remove if you want
let adminlist = (_GetWatchlist("Elevated_accounts")|project UserName);
SigninLogs
| where TimeGenerated > ago (30d)
| extend UserName = UserPrincipalName
| where UserName in (adminlist)
| where ResultType == 0
| distinct UserName
| join kind=rightanti adminlist on UserName
For SecurityEvent we want to use TargetUserName, so we will rename it when we set our variable and trim the @yourdomain.com part out
let adminlist = _GetWatchlist("Elevated_accounts")|extend TargetUserName = trim_end(@"@(.*)", UserName)|project TargetUserName;
SecurityEvent
| where TimeGenerated > ago(30d)
| where TargetUserName in (adminlist)
| distinct TargetUserName
| join kind = rightanti adminlist on TargetUserName
Try those and let me know
GaryBushey
Jul 16, 2021Bronze Contributor
Marc_Jacquard I would use the SignInLogs to determine if the user has signed in during your time frame in question. You could use the UserPrincipalName or UserDisplayName fields to compare against your Watchlist.
- Marc_JacquardJul 16, 2021Copper ContributorGary, I tried that initially, but I wanted to see any activity. Below is my current logic. I just can not seem to get the time comparison correct. No matter which log source I use, I always have people who who have been active in the last 7 days even though I know some have not been. I switch between in~ and !in~ for testing. It appears I just do not have the time comparison logic correct.
let adminlist = (_GetWatchlist("Elevated_accounts")|project UserName);
let starttime = 31d;
//let midtime = 30d;
//let endtime =10m;
SecurityEvent
| where TimeGenerated > ago(32d)
|extend Account = trim_start(@"^.*\\", Account)
| where Account in~ (adminlist)
//|where EventID == "4624"
//|where Account !endswith "$"
| summarize StartTimeUtc = min(TimeGenerated), EndTimeUtc = max(TimeGenerated) by Account, EventID
//|where EndTimeUtc - StartTimeUtc > starttime- GaryBusheyJul 17, 2021Bronze Contributor
Marc_Jacquard I would recommend at least combining the two tables if you want to get the best picture of user activity. My admin account has logged into my Azure Sentinel instance quite a bit in the last week but has not performed any activity that would show up in SecurityEvent (which shows information from the Windows machines so I am not sure that is the correct table. AzureActivity may be better)
- m_zorichJul 16, 2021Iron Contributor
Something like this should work for you. My data isn't an exact match for your formatting but you should be able to make it work in your environment. I created a test WatchList with a single column of Account, then a few rows of DOMAIN\username fields that had been active, and then some fake accounts that hadn't (fake inactive admins)
let adminlist = (_GetWatchlist("TestWatchList")|project Account);
SecurityEvent
| where TimeGenerated > ago(10d)
| where Account in (adminlist)
| distinct Account
| join kind=rightanti adminlist on AccountJoin operator - https://docs.microsoft.com/en-us/azure/data-explorer/kusto/query/joinoperator?pivots=azuredataexplorer#right-anti-join-flavor rightanti should return results from the right (your watchlist) that aren't in the left (your query for active users)
- Marc_JacquardJul 19, 2021Copper Contributor
If I use SignIn logs it seems to work fine. Then I look up the user the query said has been inactive in SecurityEvent table and it shows activity within the last 7 days.