Supercharge your queries with Azure Sentinel UEBA’s IdentityInfo table

For those that use Sentinel, hopefully you have turned on the User and Entity Behaviour Analytics, the cost is fairly negligible and it’s what drives the entity and investigation experiences in Sentinel. There are plenty of articles and blogs around to cover how to use those. I wanted to give you some really great examples of leveraging the same information to make your investigation and rules even better.

When you turn on UEBA you end up with four new tables

  • BehaviorAnalytics – this tracks things like logons or group changes, but goes beyond that and measures if the event is uncommon
  • UserAccessAnalytics – tracks users access, such as group membership but also maintains information such as when the access was first granted
  • PeerAccessAnalytics – maintains a list of a users closest peers which helps to evaluate potential blast radius
  • IdentityUserInfo – maintains a table of identity info from both on premise and cloud for users

We have access those like any other tables even when not using the entity or investigation pages. So let’s have a look at a few examples of using that data to make meaningful queries. The IdentityInfo table is a combination of Azure AD and on-premise AD data and it is a godsend – especially for those of us who still have a large on premise footprint. Previously you had to ingest a lot of this data yourself. Have a read of the Tech Community post here which has the details of this table. We essentially turn our identity data into log data, which is great for threat hunting. You just need to make sure you write your queries to account for multiple entries for users, such as using the take operator, or the arg_max operator.

Have a system that likes to respond using SIDs for users alerts instead of usernames? Here we look for lockout events, grab the SID of the account and then join to the IdentityInfo table where we get information that is actually useful to us. Remember that the IdentityInfo is a table and will have multiple entries for users, so just retrieve the latest record

let alert=
SecurityEvent
| where EventID == "4740"
| extend AccountSID = TargetSid
| project AccountSID, Activity;
IdentityInfo
| join kind=inner alert on AccountSID
| sort by TimeGenerated desc
| take 1
| project AccountName, Activity, AccountSID, AccountDisplayName, JobTitle, Phone, IsAccountEnabled, AccountUPN

Do you grant access to an admin server for your IT staff and want to audit to make sure its being used? This query will find the enabled members of the group “ADMINSERVER01 – RDP Access” then query for successful RDP logons to it. We use the rightanti join in Kusto, and the output will be users who have access, but haven’t connected in 30 days.

let users=
IdentityInfo
| where TimeGenerated > ago (7d)
| where GroupMembership has "ADMINSERVER01 - RDP Access"
| extend OnPremAccount = AccountName
| where IsAccountEnabled == true
| distinct OnPremAccount, AccountUPN, EmployeeId, IsAccountEnabled;
SecurityEvent
| where TimeGenerated > ago (30d)
| where EventID == 4624
| where LogonType == 10
| where Computer has "ADMINSERVER01"
| sort by TimeGenerated desc 
| extend OnPremAccount = trim_start(@"DOMAIN\\", Account)
| summarize arg_max (TimeGenerated, *) by OnPremAccount
| join kind=rightanti users on OnPremAccount
| project OnPremAccount, AccountUPN, IsAccountEnabled

Have an application that you use Azure AD for SSO, but access control is granted from on premise AD groups? You can do a similar join to SigninLogs data.

let users=
IdentityInfo
| where TimeGenerated > ago (7d)
| where GroupMembership has "Business App Access"
| extend UserPrincipalName = AccountUPN
| distinct UserPrincipalName, EmployeeId, IsAccountEnabled;
SigninLogs
| where TimeGenerated > ago (30d)
| where AppDisplayName contains "Business App"
| where ResultType == 0
| sort by TimeGenerated desc
| summarize arg_max(TimeGenerated, AppDisplayName) by UserPrincipalName
| join kind=rightanti users on UserPrincipalName
| project UserPrincipalName, EmployeeId, IsAccountEnabled

Again this will show you who has access but hasn’t authenticated via Azure AD in 30 days. Access reviews in Azure AD can help you with this too, but it’s a P2 feature you may not have, and it won’t be able to change on premise AD group membership.

You could query the IdentityInfo table for users with certain privileged Azure AD roles and correlate with Cloud App Security alerts to prioritize them higher.

let PrivilgedRoles = dynamic(["Global Administrator","Security Administrator","Teams Administrator", "Security Administrator"]);
let PrivilegedIdentities = 
IdentityInfo
| summarize arg_max(TimeGenerated, *) by AccountObjectId
| mv-expand AssignedRoles
| where AssignedRoles in~ (PrivilgedRoles)
| summarize AssignedRoles=make_set(AssignedRoles) by AccountObjectId, AccountSID, AccountUPN, AccountDisplayName, JobTitle, Department;
SecurityAlert
| where TimeGenerated > ago (7d)
| where ProviderName has "MCAS"
| project CompromisedEntity, AlertName, AlertSeverity
| join kind=inner PrivilegedIdentities on $left.CompromisedEntity == $right.AccountUPN
| project TimeGenerated, AccountDisplayName, AccountObjectId, AccountSID, AccountUPN, AlertSeverity, AlertName, AssignedRoles

And finally using the same logic to find users with privileged roles and detecting any Azure AD Conditional Access failures for them

let PrivilgedRoles = dynamic(["Global Administrator","Security Administrator","Teams Administrator", "Exchange Administrator"]);
let PrivilegedIdentities = 
IdentityInfo
| summarize arg_max(TimeGenerated, *) by AccountObjectId
| mv-expand AssignedRoles
| where AssignedRoles in~ (PrivilgedRoles)
| summarize AssignedRoles=make_set(AssignedRoles) by AccountObjectId, AccountSID, AccountUPN, AccountDisplayName, JobTitle, Department;
SigninLogs
| where TimeGenerated > ago (30d)
| where ResultType == 53003
| join kind=inner PrivilegedIdentities on $left.UserPrincipalName == $right.AccountUPN
| project TimeGenerated, AccountDisplayName, AccountObjectId, AccountUPN, AppDisplayName, IPAddress

Remember that once you join your IdentityInfo table to whichever other data sources, you can include fields from both in your queries – so on premise SID’s or ObjectID’s as well as items from your SigninLogs or SecurityAlert tables like alert names, or conditional access failures.

Enforce PIM compliance with Azure Sentinel and Playbooks

Azure AD Privileged Identity Management is a really fantastic tool that lets you provide governance around access to Azure AD roles and Azure resources, by providing just in time access, step up authentication, approvals and a lot of great reporting. For those with Azure AD P2 licensing, you should roll it out ASAP. There are plenty of guides on deploying PIM, so I won’t go back over those, but more focus on how we can leverage Azure Sentinel to make sure the rules are being followed in your environment.

PIM actions are logged to the AuditLogs table, you can find any operations associated by searching for PIM

AuditLogs
| summarize count() by OperationName
| where OperationName contains "PIM"

If you have had PIM enabled for a while, you will see lot of different activities, I won’t list them all here, but you will see each time someone activates a role, when they are assigned to roles, when new roles are onboarded and so on. Most of the items will just be business as usual activity and useful for auditing but nothing we need to alert on or respond to. One big gap of PIM is that users can still be assigned roles directly, so instead of having just in time access to a role, or require an MFA challenge to activate they are permanently assigned to roles – this may not be an issue for some roles like Message Center Reader, but you definitely want to avoid it for highly privileged roles like Global Administrator, Exchange Administrator, Security Administrator and whichever else you deem high risk. This could be an admin trying to get around policy or something more sinister.

Thankfully we get an operation each time this happens, ready to to act on. We can query the AuditLogs for these events, then retrieve the information about who was added to which role, and who did it in case we want to follow up with them. For this example I added our test user to the Power Platform Administrator role outside of PIM.

AuditLogs
| where OperationName startswith "Add member to role outside of PIM"
| extend AADRoleDisplayName = tostring(TargetResources[0].displayName)
| extend AADRoleId = tostring(AdditionalDetails[0].value)
| extend AADUserAdded = tostring(TargetResources[2].displayName)
| extend AADObjectId = tostring(TargetResources[2].id)
| extend UserWhoAdded = tostring(parse_json(tostring(InitiatedBy.user)).userPrincipalName)
| project TimeGenerated, OperationName, AADRoleDisplayName, AADRoleId, AADUserAdded, AADObjectId, UserWhoAdded

If you don’t want to automatically remediate all your roles, you could put the ones you want to target into a Watchlist and complete a lookup on that first. The role names and role ids are the same for all Azure AD tenants, so you can get them here. Create a Watchlist, in this example called PrivilegedAADRoles with the names and ids of the ones you wish to monitor and remediate. Then just query on assignments to groups in your Watchlist.

Now we can include being in that Watchlist as part of the logic we will use when we write our query. Keep in mind you will still get logs for any assignments outside of PIM, we are just limiting the scope here for our remediation.

let AADRoles = (_GetWatchlist("PrivilegedAADRoles")|project AADRoleId);
AuditLogs
| where OperationName startswith "Add member to role outside of PIM"
| extend AADRoleDisplayName = tostring(TargetResources[0].displayName)
| extend AADRoleId = tostring(AdditionalDetails[0].value)
| extend AADUserAdded = tostring(TargetResources[2].displayName)
| extend AADObjectId = tostring(TargetResources[2].id)
| extend UserWhoAdded = tostring(parse_json(tostring(InitiatedBy.user)).userPrincipalName)
| where AADRoleId in (AADRoles)
| project OperationName, AADRoleDisplayName, AADRoleId, AADUserAdded, AADObjectId, UserWhoAdded

Now to address these automatically. First, let’s create our playbook that will automatically remove any users who were assigned outside of PIM. You can call it whatever makes sense for you, now much like the example here, if you want to do your secrets management in an Azure Key Vault, then assign the new logic app rights to read secrets. The service principal you use for this automation will need to be able to manage membership of Global Administrators, so will therefore need to be one itself, so make sure you keep your credentials for it safe.

We want the trigger of our playbook to be ‘When Azure Incident creation rule was triggered’. Then the first thing we are going to do is create a couple of variables, one for the role id that was changed and one for the AAD object id for the user who was added. We will map these through using entity mapping when we create our analytics rule in Sentinel – which we will circle back on and create once our playbook is built. Let’s retrieve the entities from our incident – for this example we will map RoleId to hostname and object id for the user to AADUserID.

Then we grab our AADUserId and RoleId from the entities and append them to our variables ready to re-use them.

Next we use the Key Vault connect to grab our client id, tenant id and client secret from Key Vault, then we are going to POST to the MS Graph to retrieve an access token to re-use as authorization to remove the user.

We will need to parse the JSON response to then re-use the token as authorization, the schema is

{
    "properties": {
        "access_token": {
            "type": "string"
        },
        "expires_in": {
            "type": "string"
        },
        "expires_on": {
            "type": "string"
        },
        "ext_expires_in": {
            "type": "string"
        },
        "not_before": {
            "type": "string"
        },
        "resource": {
            "type": "string"
        },
        "token_type": {
            "type": "string"
        }
    },
    "type": "object"
}

Now we have proven we have access to remove the user who was added outside of PIM, we will POST back to MS Graph using the ‘Remove directory role member’ action outlined here. As a precautionary step, we will revoke the users sessions so if they had a session open with added privileged it has now been logged out. You can also add some kind of notification here, maybe raise an incident in Service Now, or email the user telling them they have had their role removed and inform them about your PIM policies.

To round out the solution, we create our Analytics rule in Sentinel, this is one I would run as often as possible because you want to revoke that access ASAP. So if you run it every 5 minutes, looking at the last 5 minutes of data, then complete the entity mapping outlined below, to match our playbook entities.

When we get to Automated response, create a new incident automation rule that runs the playbook we just built. Then activate the analytics rule.

Now you can give it a test if you want, add someone to a role outside of PIM, within ~10 minutes (to allow the AuditLogs to stream to Azure Sentinel, then your Analytics rule to fire), they should be removed and be logged back out of Azure AD.

Monitoring OAuth Applications with Azure Sentinel

For those of us who use Azure AD as their identity provider, you are probably struggling with OAuth app sprawl. On one hand it is great that your single sign on and identity is centralized to one place, but that means a whole lot of applications to monitor. When we first started leveraging Azure AD the concept of OAuth applications was really foreign to me, and though not a perfect comparison, I used to like to think of them as the cloud equivalent of on premise AD service accounts. You create an Azure AD App / Service Principal, then you grant it access – now that access can be pretty insignificant, or extremely privileged. Much like an on premise AD service account, it could be anything from read access to one folder on a file server to a local admin on every server (hope you have your eyes on that one!).

The deeper you are in the Microsoft ecosystem, the more apps you will have appear in your tenant. Users want the Survey Monkey app for Teams? Have an app. Users want to use Trello or Miro in Teams or SharePoint, have another app. The sheer number of applications can be overwhelming. Then on top of that you have any applications you are developing in house. The permissions these applications have can be either delegated permissions or application permissions (or a combination of both), and there is a massive difference between the two. A delegated permission grant is bound by what the user accessing the app can also access. So if you have an application called ‘My Custom Application’ and you grant delegated Mail.ReadWrite permissions to it, then ‘My Custom Application’ can only access the same mail items the user who signed in can (their own mailbox, perhaps some mailboxes they have been given specific access to). Application permission means that the app can access everything under that scope, so if you grant ‘My Custom Application’ application Mail.ReadWrite permissions then the application has read & write access to every mailbox in your tenant – big difference!

Consent phishing has become a real issue, as Microsoft has posted about. Users are getting better at knowing they shouldn’t enter their username and password into untrusted sites, but instead attackers may send an email that looks like its from Microsoft or come from internal and have the user consent to an application, which will be registered in your tenant and they can then use to access the users data, start looking around, find other contacts or info and away they go. For those that have Cloud App Security, it has some great OAuth controls here and you can also configure if and how users can add apps to Azure AD with user settings and admin consent.

Regardless of your policy on those settings, if you have the AuditLogs from Azure AD flowing to Azure Sentinel (you can add via the Data Connectors tab) then we can also check out all the activity in there. When you or one of your Azure AD admins creates an application under Azure AD -> App Registrations then three events will trigger in Sentinel. If you create one yourself, then search the AuditLogs table for your account to see the output.

AuditLogs
| where InitiatedBy has "youraccount@yourdomain.com"
| sort by TimeGenerated desc

First an application is added, then an owner (the person who created the app) is added to the app, then a service principal is created. If we look at the ‘Add application’ log under the TargetResources field we can see the name and id of the application created

This id corresponds to the object id in the Azure AD -> App Registrations portal

We also have a service principal created, and again we check the TargetResources under ‘Add service principal’ we can see the id displayed

This second id corresponds to the object id on the Azure AD -> Enterprise Applications portal

Confused about applications vs service principals vs object ids vs application ids? I think everyone has been at some point, thankfully Microsoft have detailed the relationships here for you. By default, when an application is created, it only has delegated user.read permissions. So the application can sign users in and read their profile and that’s it, now lets add some permissions to our app –

I have added delegated Sites.ReadWrite.All and Mail.ReadWrite – remember these are delegated permissions, so now the application can sign on users, see the users profile, and have read write access to any SharePoint Sites or mailboxes that the person who signed on can. Admin consent required = no means that you don’t require a global admin to consent to this permission for it to work, however each user who signs on will be presented a consent prompt. If an admin does consent then users won’t be prompted individually. Now, here is where things get a bit weird. When you add your permissions, you will see two entries in your logs

Now, we have added Sites.ReadWrite.All, so lets make sure that is what we are seeing in the logs.

Weird? No results. So what I have found is that when you first add permissions to an app, if no one has yet consented (either a user logging on and consenting for themselves, or an admin consenting for the tenant) the permissions are stored as EntitlementId’s

Old value = 1 EntitlementId, New Value = 3 EntitlementId’s, because we went from User.Read to User.Read, Sites.ReadWrite.All and Mail.ReadWrite. For delegated permissions there is no real way to map ids to names unfortunately.

Let’s now consent to these permissions as an admin and have a look what we can see. Push the big ‘Grant admin consent’ button on your permissions page. Now we query on actions done by ourselves and we see three new entries

So we have granted the delegated permissions from above, we added the app role assignment to my user account (so if you go to Azure AD -> Enterprise Apps -> Sentinel Test, you will now be assigned to the app and can sign into it) and then finally because we are an admin in this example, we also consented to the app for the tenant. If we dig down onto the add delegated permissions grant item, now we can see –

Now we’re talking, so we are stuck with EntitlementId’s just until someone consents, which is still a pain but we can work with that. Until either a user for themselves, or an admin for everyone consents, then no one has accessed the app. Now we can have a look at what delegated permissions have been added to apps in the last week using the ‘Add delegated permission grant’ operation.

AuditLogs
| where Category == "ApplicationManagement"
| where OperationName has "Add delegated permission grant"
| extend UpdatedPermissions = tostring(parse_json(tostring(parse_json(tostring(TargetResources[0].modifiedProperties))[0].newValue))) 
| extend AppId = tostring(TargetResources[1].id)
| project TimeGenerated, UpdatedPermissions, OperationName, AppId

Now we can see the list of delegated permissions recently added to our applications. Delegated permissions are the lesser of the two, but still shouldn’t be ignored. If an attacker tricks a user into adding an application with a lot of delegated permissions they can definitely start hunting around SharePoint, or email or a lot of other places to start working their way through your environment. You may be especially concerned with any permissions granted that have .All, which means not just access to one persons info, but anything that user can access. Much like a ‘Domain User’ from on premise AD can see a lot of your domain, a member of your Azure AD tenant can see a lot of info about your tenant too. We can hunt for any updated permissions that have All in them, we can also parse out the user who added the permissions. Depending on your policies on app registration this could be end users or IT admin staff.

AuditLogs
| where Category == "ApplicationManagement"
| where OperationName has "Add delegated permission grant"
| extend UpdatedPermissions = tostring(parse_json(tostring(parse_json(tostring(TargetResources[0].modifiedProperties))[0].newValue)))
| extend User = tostring(parse_json(tostring(InitiatedBy.user)).userPrincipalName)
| where UpdatedPermissions contains "All"
| project TimeGenerated, OperationName, UpdatedPermissions, User

Let’s remove all the permissions and go back to User.Read only (or just create a new app for testing and delete the old). Now this time let’s add some extremely high permissions, application Directory.ReadWrite.All – read and write everything in Azure AD, not bound by user permission, and the same for mail with Mail.ReadWrite – read and write all mailboxes in the tenant.

Now if we query our AuditLogs, we will find the same issue occurs with application permissions, until they are consented to, they only appear as EntitlementId’s.

Good news though! For application permissions you can query the MS Graph to find the information to map what you are after. You could store that data in a custom table, or a CSV to query against. If you search your tenant for the MS Graph application (00000003-0000-0000-c000-000000000000) then click on it and grab your ObjectID – yours will be different to mine.

Then query MS Graph https://graph.microsoft.com/v1.0/serviceprincipals/yourobjectidhere?$select=appRoles you will get an output like this, these ids are the same for all tenants. Now we have the ids, plus the friendly names and even a description.

I won’t rehash adding info from MS Graph to a custom table here, myself and heaps of others have covered that. In my case I have added all my id’s, names and descriptions to a custom AADPermissions_CL custom table so we can then query it. Now we can query the audit logs and join them to our custom table of permissions and id’s to enrich out alerting, if we get any hits on this query then we know application permissions have been added to an app (but not yet consented to)

let entitlement=
AuditLogs
| where OperationName has "Update application"
| extend AppName = tostring(TargetResources[0].displayName)
| extend AppID = tostring(TargetResources[0].id)
| extend User = tostring(parse_json(tostring(InitiatedBy.user)).userPrincipalName)
| extend Ids_ = tostring(parse_json(tostring(parse_json(tostring(TargetResources[0].modifiedProperties))[0].newValue))[0].RequiredAppPermissions)
| extend EntitlementId_ = extract_all(@"([w]{8}-[w]{4}-[w]{4}-[w]{4}-[w]{12})(b|/)", dynamic([1]), Ids_)
| extend EntitlementIds = translate('["]','',tostring(EntitlementId_))
| extend idsSplit =split(EntitlementIds , ",")
| mv-expand idsSplit
| extend idsSplit_s = tostring(idsSplit);
AADPermissions_CL
| join kind=inner entitlement on $left.PermissionID_g==$right.idsSplit_s
| project TimeGenerated, AppName, AppID, PermissionID_g, PermissionName_s, PermissionDescription_s, User

If you go ahead and consent to the permissions, and recheck the AuditLogs you can see we get two hits for ‘Add app role assignment to service principal’

And if we dig on down through the JSON we can see the permission added

Now can look back and see what application permissions have been added to our apps recently

AuditLogs
| where OperationName has "Add app role assignment to service principal"
| extend UpdatedPermission = tostring(parse_json(tostring(parse_json(tostring(TargetResources[0].modifiedProperties))[1].newValue)))
| extend AppName = tostring(parse_json(tostring(parse_json(tostring(TargetResources[0].modifiedProperties))[4].newValue)))
| extend User = tostring(parse_json(tostring(InitiatedBy.user)).userPrincipalName)
| extend AppId = tostring(TargetResources[1].id)
| project TimeGenerated, OperationName, UpdatedPermission, AppName, AppId, User

At this point you could query on particular permission sets, maybe looking for where UpdatedPermission has “ReadWrite” or anything with “All”. We can combine the two to see all delegated and application permissions added to an app with the following query, we join two queries based on the id of the application

let DelegatedPermission=
AuditLogs
| where OperationName has "Add delegated permission grant"
| extend AddedDelegatedPermission = tostring(parse_json(tostring(parse_json(tostring(TargetResources[0].modifiedProperties))[0].newValue)))
| extend AppId = tostring(TargetResources[1].id)
| project TimeGenerated, AddedDelegatedPermission, AppId;
AuditLogs
| where OperationName has "Add app role assignment to service principal"
| extend AddedApplicationPermission = tostring(parse_json(tostring(parse_json(tostring(TargetResources[0].modifiedProperties))[1].newValue)))
| extend AppName = tostring(parse_json(tostring(parse_json(tostring(TargetResources[0].modifiedProperties))[4].newValue)))
| extend User = tostring(parse_json(tostring(InitiatedBy.user)).userPrincipalName)
| extend AppId = tostring(TargetResources[1].id)
| join kind=inner DelegatedPermission on AppId
| project TimeGenerated, AppName, AddedApplicationPermission, AddedDelegatedPermission, AppId

Now that we know what events we are after, we can really start hunting. Looking for an app that had application permissions added and removed quickly, within 10 minutes, maybe someone trying to cover their tracks? We can find who added and removed the permission, which permissions and calculate the time between

let PermissionAddedAlert=
AuditLogs
| where OperationName has "Add app role assignment to service principal"
| extend UserWhoAdded = tostring(parse_json(tostring(InitiatedBy.user)).userPrincipalName)
| extend PermissionAdded = tostring(parse_json(tostring(parse_json(tostring(TargetResources[0].modifiedProperties))[1].newValue)))
| extend AppId = tostring(parse_json(tostring(parse_json(tostring(TargetResources[0].modifiedProperties))[5].newValue)))
| extend TimeAdded = TimeGenerated
| project UserWhoAdded, PermissionAdded, AppId, TimeAdded;
let PermissionRemovedAlert=
AuditLogs
| where OperationName has "Remove app role assignment from service principal"
| extend UserWhoRemoved = tostring(parse_json(tostring(InitiatedBy.user)).userPrincipalName)
| extend PermissionRemoved = tostring(parse_json(tostring(parse_json(tostring(TargetResources[0].modifiedProperties))[1].oldValue)))
| extend AppId = tostring(parse_json(tostring(parse_json(tostring(TargetResources[0].modifiedProperties))[5].newValue)))
| extend TimeRemoved = TimeGenerated
| project UserWhoRemoved, PermissionRemoved, AppId, TimeRemoved;
PermissionAddedAlert
| join kind=inner PermissionRemovedAlert on AppId
| where abs(datetime_diff('minute', TimeAdded, TimeRemoved)) <=10
| extend TimeDiff = TimeAdded - TimeRemoved
| project TimeAdded, UserWhoAdded, PermissionAdded, AppId, TimeRemoved, UserWhoRemoved, PermissionRemoved, TimeDiff

Wondering how those third party apps like Survey Monkey or a thousand other random Teams apps or OAuth apps work? Very similar in terms of hunting thankfully. For a multi tenant app, you won’t have an application object (under the Azure AD -> App Registrations portal) because that app will be in the developers tenant, but you will have a service principal (Azure AD -> Enterprise Applications portal). When you or a user consents to a third party application you will still get AuditLogs entries.

AuditLogs
| where OperationName contains "Consent to application"
| extend Consent = tostring(parse_json(tostring(parse_json(tostring(TargetResources[0].modifiedProperties))[4].newValue)))
| parse Consent with * "Scope:" PermissionsConsentedto ']' *
| extend AdminConsent = tostring(parse_json(tostring(parse_json(tostring(TargetResources[0].modifiedProperties))[0].newValue)))
| extend AppDisplayName = tostring(TargetResources[0].displayName)
| extend AppType = tostring(TargetResources[0].type)
| extend AppId = tostring(TargetResources[0].id)
| project TimeGenerated, AdminConsent, AppDisplayName, AppType, AppId, PermissionsConsentedto

It will show us whether it was an admin who consented, AdminConsent = True, or a user AdminConsent = false. Both our own apps and third party apps show under ‘Consent to application’ log items.

It is important to remember that Azure Sentinel is event driven, if you only recently enabled Azure AD Audit Logs sending to Sentinel then you may have a lot of applications already consented to with a heap of permissions, similar to how those on premise service accounts creep up in privilege over time. There are a lot of great tools out there that can audit your existing posture and help you clean up. Cloud App Security can visualize all your apps, the permissions, how common they are if you are licensed for it or use PowerShell/MS Graph to run a report. Then once you are at a known place, put in place good practices to reduce risk and be alerted –

Don’t let your users register applications. Azure AD -> User Settings. Users can register applications – set to No

Configure consent settings – Azure AD -> Enterprise Applications -> Consent and permissions. Either set ‘Do not allow user consent’ or ‘Allow user consent for apps from verified publishers, for selected permissions (Recommended)’. The latter will let users consent for applications that are classified as low risk, which by default are User.Read, openid, profile and offline_access. You can add/remove to this list of pre-approve permissions.

Configure admin consent and the appropriate workflow for IT staff to review requests above the approved permissions.

Configure Azure Sentinel to fire alerts for both new applications created, permissions added to them and consent granted to applications – that will cover you for internal apps and third party apps.

Practice least privilege for your applications, like you would on premise service accounts. If an internal team or vendor asked for a service account with Domain Admin access you would hopefully question them, do the same for application access; do you really need directory.readwrite.all, or do you just need to read & write particular users or groups? Want to access an O365 mailbox via OAuth, then don’t give access to all mailboxes – limit access with a scoping policy, and the same for SharePoint.

Cloud App Security? Azure AD Identity Protection? Help!

If you are an Azure AD P2 tenant, or have E5 licensing there is a chance you have had a look at these products, the way they integrate (or don’t integrate) with each other and Azure Sentinel is sometimes a little unclear and known to change. They are meant to take the noise from your data sources like Azure AD sign in logs, or Office activity logs and make some sense of it all and direct the alerts to you, which is great. However sometimes even the alerts left over can be noisy. In Cloud App Security you can definitely tune this alerts which is helpful – for instance, you can change ‘impossible travel’ alerts to only fire on successful logons, not successful and failed. but I personally like getting as much data as I can into Sentinel and work with it in there.

The downside is that sending everything to Sentinel may mean a lot of alerts, even after Cloud App Security and Identity Protection have done their thing. Depending on the size your environment, it still may be overwhelming, say in a month you get 1430 alerts (using the below test data) for various identity issues.

You could just take the stance that for any of these you just sign the person out or force a password reset, that could result in a heap of false positives and frustrating users, and not treating more serious cases with more urgency.

When you connect Azure AD Identity Protection & Cloud App Security to Azure Sentinel, the alerts will show up in the SecurityAlert table with the ProviderNames of IPC and MCAS respectively. MCAS also alerts on a lot of other things, but we will focus on identity issues for now. When we look at the description for these alerts from Identity Protection, they are all kind of the same, something similar to “This risk event type considers past sign-in properties (e.g. device, location, network) to determine sign-ins with unfamiliar properties. The system stores properties of previous locations used by a user, and considers these “familiar”. The risk event is triggered when the sign-in occurs with properties not already in the list of familiar properties. The system has an initial learning period of 30 days, during which it does not flag any new detections…”, MCAS will give you a little more info but we need to really hunt ourselves.

To help us make sense of all these alerts, I thought we could get the details (IPv4 addresses and UserPrincipalName for this example) from our SecurityAlert, then replay that data through the Azure AD SigninLogs table and see if we can find some key alerts

let IPs=
SecurityAlert
| project TimeGenerated, Status, AlertName,CompromisedEntity,ExtendedProperties, ProviderName
| where TimeGenerated > ago (1h)
| where ProviderName in ('MCAS', 'IPC')
| where AlertName in ('Impossible travel activity','Multiple failed login attempts','Unfamiliar sign-in properties','Anonymous IP address','Atypical travel')
| where Status contains "New"
| extend Properties = tostring(parse_json(ExtendedProperties))
| extend UserPrincipalName = CompromisedEntity
| extend ipv4Addresses = extract_all(@"(([\d]{1,3}\.){3}[\d]{1,3})", dynamic([1]), Properties)
| extend ipv4Add = translate('["]','',tostring(ipv4Addresses))
| extend ipv4Split =split(ipv4Add , ",")
| mv-expand ipv4Split
| extend ipv4Split_s = tostring(ipv4Split);
SigninLogs
| project TimeGenerated, UserPrincipalName, IPAddress, AppDisplayName, ResultType, UserAgent, Location
| where TimeGenerated > ago(3d)
| where IPAddress !startswith "1.1.1."
| where ResultType == 0 or ResultType == 50158
| join kind=inner IPs on UserPrincipalName ,$left.IPAddress==$right.ipv4Split_s
| summarize AgentCount = count()by UserPrincipalName, UserAgent
| where AgentCount == 1

We get our SecurityAlerts over whatever period you want to look through, parse the IPs and UserPrincipalName data out, then we use the mv-expand operator to make a new row for each IP/UPN combination then look up that data to our SigninLogs table. Then to add some more intelligence, we exclude known trusted IP addresses (1.1.1.0/24 in the above example, you can whitelist these in MCAS too of course) and also only filter on successful (ResultType == 0) or successful and then sent to a third party security challenge, such as third party MFA (ResultType == 50158) events. We join on UserPrincipalName where we have a match on one of the IPs taken from the SecurityAlert event. Lastly we count the UserAgents used by each user and tell us when it is new, count == 1.

So get the alerts, grab the IP addresses and user, use that data to look for successful sign ins from non trusted networks on a user agent that is new to that user over the last 3 days. In my test environment full of fake data we go from 1430 alerts, to 11

I am not suggesting you just ignore the other 1119 alerts of course, but maybe these ones you prioritize higher or have a different response to.

Use MS Graph and Sentinel to create dynamic Watchlists

This post is a follow up to my post about enriching Sentinel via MS Graph here and in response to the community post here – how do we create dynamic Watchlists of high value groups and their members. There are a couple of ways to do this, you can either use the Azure Sentinel Logic App or the Watchlist API. For this example we will use the Logic App. Let’s start with some test users and groups, for this example our test user 1 and 2 are in privileged group 1 and test user 2 are in privileged group 2.

First let’s start by retrieving the group ids from the MS Graph, we have to do this because Azure AD group names are not unique, but the object ids are. You will need an Azure AD app registration with sufficient privilege to read the directory, directory.read.all is more than enough but depending on what other tasks your app is doing, may be too much. As always, least privilege! Grab the client id, the tenant id and secret to protect your app. How you do your secrets management is up to you, I use an Azure Key Vault because Logic Apps has a native connector to it which uses Azure AD managed identity to authenticate itself.

First create our playbook/Logic App and set the trigger to recurrence, since this job we will probably want to run every few hours or daily or whatever suits you. If you are using an Azure Key Vault, give the Logic App a managed identity under the identity tab.

Then give the managed identity for your Logic App the ability to list & read secrets on your Key Vault by adding an access policy

First we need to call the MS Graph to get the group ids of our privileged groups, we can’t use the Azure AD Logic App connector yet because that requires the object ids, and we want to do something more dynamic that will pick up new groups for us automatically. Let’s use the Key Vault connector to get our client id, tenant id and secret, and we connect using the managed identity.

Next we POST to the MS Graph to get an access token

Add the secrets from your Key Vault, your tenantid goes into the URI, then clientid and secret into the body. We want to parse the JSON response to get our token for re-use. The schema for the response is

{
    "properties": {
        "access_token": {
            "type": "string"
        },
        "expires_in": {
            "type": "string"
        },
        "expires_on": {
            "type": "string"
        },
        "ext_expires_in": {
            "type": "string"
        },
        "not_before": {
            "type": "string"
        },
        "resource": {
            "type": "string"
        },
        "token_type": {
            "type": "string"
        }
    },
    "type": "object"
}

Now we use that token to call the MS Graph to get our object ids. The Logic App HTTP action is picky about URI syntax so sometimes you just have to add your URL to a variable and input it into the HTTP action, our query will search for any groups starting with ‘Sentinel Priv’ but you could search on whatever makes sense for you.

When building these Logic Apps, testing a run and checking the outputs is often valuable to make sure everything is working, if we trigger our app now we can see the output we are expecting

{
  "@odata.context": "https://graph.microsoft.com/v1.0/$metadata#groups(displayName,id)",
  "value": [
    {
      "displayName": "Sentinel Privileged Group 1",
      "id": "54bb0603-7d02-40a1-874d-2dc26010c511"
    },
    {
      "displayName": "Sentinel Privileged Group 2",
      "id": "e5efe4a4-51e0-4ed7-96b5-9d77ffb7ab74"
    }
  ]
}

We will need to leverage the ids from this response, so parse the JSON using the following schema

{
    "properties": {
        "@@odata.context": {
            "type": "string"
        },
        "value": {
            "items": {
                "properties": {
                    "displayName": {
                        "type": "string"
                    },
                    "id": {
                        "type": "string"
                    }
                },
                "required": [
                    "displayName",
                    "id"
                ],
                "type": "object"
            },
            "type": "array"
        }
    },
    "type": "object"
}

Next we need to manually go create our Watchlist in Sentinel that we want to update. For this example we have created the PrivilegedUsersGroups watchlist using a little sample data

Finally we iterate through our groups ids we retrieved from the MS Graph, create a JSON payload and use the Add a new watchlist item Logic App, you will need to add your Sentinel workspace details in here of course.

When we run our Logic App, it should now insert the members to our watchlist, including their UPN, the group name and group id.

We can clean up the test data if we want, but now we can query on events related to those via our watchlist

let PrivilegedUsersGroups = (_GetWatchlist('PrivilegedUsersGroups') | project GroupName);
SecurityEvent
| where EventID in (4728, 4729, 4732, 4756, 4757)
| where TargetUserName in (PrivilegedUsersGroups)
| project Activity, TargetUserName

The one downside to using Watchlists in this way is that the Logic App cannot currently remove items, so when you run it each time it will add the same members again. It isn’t the end of the world though, you can just query the watchlist on its latest updated time, if your Logic App runs every four hours, then just query the last four hours of items.

_GetWatchlist('PrivilegedUsersGroups') | where LastUpdatedTimeUTC > ago (4h)

Join, lookup and union your way to unified identity in Sentinel

One of the ongoing challenges I have had when trying to detect credential compromise or other identity issues is that identities across products and environments are often not uniform. For companies who are born in the cloud, have no legacy on premise footprint maybe this is less of an issue. But those of us who have a large on premise environment still, possibly many on premise forests and domains, it becomes a headache. How do we tie together our legacy applications that love using SamAccountName as a logon identifier, or the cloud application that syncs a legacy attribute for its username, with our modern email address logon? You may even been dealing with multiple iterations of naming standards for some attributes.

Let’s take SamAccountName as an example, that is the ‘bobsmith’ part of bobsmith@yourdomain.com. By default this is synced to Azure AD as the onPremiseSamAccountName attribute, however this attribute is not exposed in the Azure AD PowerShell module and it isn’t revealed in Azure AD Sign-in logs. It is available via MS Graph, but we can’t access MS Graph when hunting in Sentinel directly. So how do we get that data into Sentinel, then make sense of it?

Enter this awesome post about enriching Sentinel with Azure AD attributes. I won’t rehash the post here, but in summary you poll Azure AD with PowerShell and send the data to a custom table to look up. Our problem is, some of the data we want isn’t available in the Azure AD PowerShell module, so we could either get the data from MS Graph and send it via the ingestion API, or in my case, we actually use the same logic that post outlines, but we run it on premise because we know the Active Directory module will surface everything we need. If we hunt through the PowerShell that makes up the solution here, instead of connecting to Azure AD like they do –

Connect-AzureAD -AadAccessToken $aadToken -AccountId $context.Account.Id -TenantId $context.tenant.id
$Users = Get-AzureADUser -All $True

We are instead going to connect to on-premise AD and choose what attributes we want to flow to Sentinel

Get-ADUser -filter {Enabled -eq $TRUE} -SearchBase 'OU=CorporateUsers,DC=YourDomain,DC=COM' -SearchScope 2 -Properties * | select UserPrincipalName, SamAccountName, EmployeeID, Country, Office, EmailAddress, WhenCreated, ProxyAddresses

Maybe we want to filter out disabled users, only search for a particular OU (and those under it) and bring back some specific fields unique to your environment. The key one in terms of identity is having SamAccountName and UserPrincipalName in the same table, using AD as our source, but maybe your application uses EmployeeID in its logs, so bring that up too. Let’s check out our UserDetails_CL table that we sent our data to-

We can see that our test users have different formats for their SamAccountName fields, maybe they lived through a few naming standards and they have different EmployeeID lengths. Now that we have the data we can use KQL to find what we need though. Let’s say we have an alert triggered when someone fails to logon more than 3 times in 5 minutes, looks like our test account has flagged that alert

Unfortunately it’s impossible to really tell who this is, if it’s threatening or where to go from here, there is a good chance this is just noise. So let’s expand our query to bring in our UserDetails_CL table full of our info from on premise AD and see who this is. We use the KQL let operator to assign results to a variable for re-use

let alert=
SecurityEvent
| where TimeGenerated > ago (5m)
| where EventID == "4771"
| summarize count()by TargetAccount
| where count_ > 3
| extend SamAccountName = TargetAccount
| project SamAccountName;
let userdetails=
UserDetails_CL
| where TimeGenerated > ago(24h)
| extend SamAccountName = SamAccountName_s
| extend EmployeeID = EmployeeID_s
| extend UserPrincipalName = UserPrincipalName_s
| project SamAccountName, EmployeeID, UserPrincipalName;
alert
| lookup kind=leftouter userdetails on SamAccountName

So first we run our alert query, then next our UserDetails_CL custom table. If you are going to keep this table up to date, and run your PowerShell nightly, then query that table for the last 24 hours of records so you get the most current data. Then finally we combine our two queries together; there are plenty of ways in KQL to aggregate data across tables – union, join, lookup. I like using lookup in this case because we are going to join on top of this query next.

Now we have a bit more information about this user, in particular their UserPrincipalName which is used in many other places, like Azure AD. We can then join our output to another query, this time looking for Azure AD logs by ‘replaying’ that UserPrincipalName forward.

let alert=
SecurityEvent
| where TimeGenerated > ago (5m)
| where EventID == "4771"
| summarize count()by TargetAccount
| where count_ > 3
| extend SamAccountName = TargetAccount
| project SamAccountName;
let userdetails=
UserDetails_CL
| where TimeGenerated > ago(24h)
| extend SamAccountName = SamAccountName_s
| extend EmployeeID = EmployeeID_s
| extend UserPrincipalName = UserPrincipalName_s
| project SamAccountName, EmployeeID, UserPrincipalName;
alert
| lookup kind=leftouter userdetails on SamAccountName
| join kind=inner 
(SigninLogs
| project TimeGenerated, UserPrincipalName, ResultType, AppDisplayName, IPAddress, Location, UserAgent) on UserPrincipalName

So we have looked up the SecurityEvent data from on-premise, flagged an account that failed to logon more than 3 times in 5 minutes, looked up their current AD details using our custom table we ingested, then joined that data to the Azure AD logs using their UserPrincipalName.

We can see the same user has connected to Exchange Online PowerShell and we get the collated identity information for the event.

You can use the same logic to bind any tables together, use third party MFA that comes in via SysLog or CEF?

let MFA = Syslog_CL
| extend MFAOutcome  = extract("outcome=(.*?) duser", 1, SyslogMessage_s)
| extend SamAccountName = extract("duser=(.*?) cs2", 1, SyslogMessage_s)
| extend MFAMethod = extract("cs2=(.*?) cs3", 1, SyslogMessage_s)
| extend MFAApplication = extract("cs3=(.*?) ca", 1, SyslogMessage_s)
| extend MFAIPaddr = extract("src=(([0-9]{1,3})\\.([0-9]{1,3})\\.([0-9]{1,3})\\.(([0-9]{1,3})))",1,SyslogMessage_s) 
| extend MFATime = TimeGenerated
| where MFAOutcome == "FAILURE"
| project MFATime, SamAccountName, MFAOutcome, MFAMethod, MFAApplication, MFAIPaddr;
let UserInfo = 
UserDetails_CL
| extend UserPrincipalName = UserPrincipalName_s
| extend SamAccountName = SamAccountName_s;
MFA
| lookup kind=leftouter UserInfo on SamAccountName
| project MFATime, MFAOutcome, MFAMethod, MFAIPaddr, SamAccountName_s, UserPrincipalName
| join kind=inner 
(SigninLogs
| where ResultType == "50158"
| project TimeGenerated, UserPrincipalName, ResultType, AppDisplayName, IPAddress, Location, UserAgent) on UserPrincipalName
| where MFATime between ((TimeGenerated-timespan(10min)).. (TimeGenerated+timespan(10min))) and IPAddress != MFAIPaddr

In this example the third party MFA uses SamAccountName as an identifier and the logs come into a Syslog table. We parse out the relevant details – MFA outcome (pass/fail), SamAccountName, MFA method (push, phone call, text etc), IP address and time, then find only MFA failures. We lookup our SamAccountNames in our UserDetails_CL table to get the UserPrincipalNames. Finally we query Azure AD for any logon events that have triggered a MFA request (ResultType = 50158). Then we add additional logic where we are only interested in events MFA and logon events within 20 minutes of each and where the IP address that logged onto Azure AD is different to the MFA IP address, which could suggest an account has been compromised but the owner of the account denied the MFA prompt from a different location.

Using Sentinel to automatically respond to identity alerts

Revoking a users sessions in Azure AD is a fantastic way to automatically respond to identity alerts like impossible travel or unfamiliar sign in properties, it becomes an even stronger response the greater your MFA coverage is, and the more apps you use Azure AD for authentication. However automating that response for legitimate actions, like where a user is using a VPN or has a new device, can lead you down a cycle where their sessions are revoked, they sign back in, trigger an alert again, have their sessions revoked and so on.

We can use a Logic App and a custom table to put some intelligence behind this and effectively whitelist a user for a given period. You could possibly achieve the same result using a Sentinel watchlist, but it is currently difficult to remove users from watchlists, though I suspect that functionality will come soon. For this example we have called the table RevokedUsers_CL

First, lets choose a Sentinel analytics rule to trigger this on. For this example we will use impossible travel, you can write your queries and do your entity mapping to suit your environment, but a straight forward example is below

SecurityAlert
| where AlertName == 'Impossible travel activity'
| where Status contains "New"
| parse Entities with * 'AadUserId": "' aadid_ '",' *
| extend ep_ = parse_json(ExtendedProperties)
| project aadid_, CompromisedEntity

Then we map our Account to AADUserID and Name to aadid_ and CompromisedEntity respectively

Now we can build our Logic App to automatically revoke the sessions for users that are flagged for impossible travel. We create a new app and set the trigger as ‘When Azure Sentinel incident creation rule was triggered’ then we want to get our entities that we mapped earlier, and create a couple of variables for use later.

Then we take the entities from the incident and append them to our variables, because each hit on our analytics rule will trigger a separate alert and incident, these will only ever be a single user.

Now we are going to run a query against our custom table to see if the user exists and has had their sessions revoked recently.

RevokedUsers_CL
| where TimeGenerated > ago(3d)
| where AADUserID_g =~ "@{variables('AADUserID')}"
| extend UserPrincipalName = UserPrincipalName_s
| extend AADUserID = AADUserID_g
| project TimeGenerated, UserPrincipalName, AADUserID

For this example we will look through at the last 3 days of logs in our custom table, and just tidy the columns up a bit using the extend operator. If the persons Azure AD Object ID appears in that result, we know they have had their session revoked in the last 3 days and will leave them alone, if it comes back empty then we will revoke their sessions. You could make it 24 hours or a week or whatever suits your environment.

Next we parse the response from Sentinel, because we will need to run a condition over it in the next step

We add a condition to our Logic App to check if the response is empty by checking the length of the result

length(body('Parse_JSON_response')?['value'])

If it equals 0 then the user hasn’t had their sessions revoked in the last 3 days (because they weren’t found in our query) so we will perform the true action, if there is a response then we perform the false action.

So for true, we get their details from Azure AD, refresh their tokens (using an account with sufficient permissions), then we compose a small JSON payload to send back into our custom table to keep it up to date and send it using the Log Analytics Data Collector. We can also send the user an email saying ‘Hi, we noticed strange activity so we have logged you out’ and add a comment to the Sentinel incident, those steps are obviously optional. If the result is false and they have already been logged out in the last 3 days (because our query returned data), we just add a comment to our incident saying ‘this user has already been logged out recently’.

The last step is to create an automation rule that will run this Logic App for us automatically when an incident is created. Edit the analytics rule and selected the automated response option.

Add a new incident automation

Give your automation rule a name and then select the Logic App you just created

Now when your analytics rule fires, they will be automatically logged out of Azure AD and their details put into your rolling whitelist.

Enrich hunting with data from MS Graph and Azure AD

This post was an idea that came about from a post on the Sentinel tech community here, from a contributor that asked how can we match a query with group membership data from Azure AD. The AuditLogs table will show changes to Azure AD groups, but that isn’t especially useful, we need to make sure our query is matched against a current list of users whenever the alert fires.

There a few ways I can think of to achieve this, but the one I like is to use a Logic App to query Azure AD every so often, then take the data and ingest it into a custom log, for this example lets use HighRiskUsers_CL as the custom log.

Let’s build our Logic App – if you want to use the Azure AD connector then you will need an account with a role to read group memberships (Global Reader would suffice), if you want to poll the MS Graph directly then you will need a Azure AD App Registration will equivalent MS Graph access (directory.read.all would do it but may be too much depending on your stance).

I find with Logic Apps there are a thousand ways to do everything, for this I have just configured a test array with my known high risk AAD Group ID’s, you could obviously look up the MS Graph based on name and fill this array in dynamically of course, but for this example we will just list them. Set your recurrence to however often you want to update the table

Then we are going to use a couple of for each loops to iterate through each group and its members to build a small JSON payload to then send to Sentinel using the Azure Log Analytics Data Collector

The first time you write to a new table it can take up to 20 minutes, but once done you will see your table filled in with the data taken from Azure AD.

Now when you write your hunting queries you can join between your query and members of your groups. The custom table we have created is log data so just make sure you query it with the same time frame that it is updated on, so if you update it daily, use the last 24 hours of logs. Here you can see with a test query looking for a 50158 ResultType

let Alert=
SigninLogs
| where UserPrincipalName contains "username"
| where ResultType == "50158"
| take 1;
let HighRiskUser=
HighRiskUsers_CL
| where TimeGenerated > ago(24h)
| extend UserPrincipalName = UserPrincipalName_s
| project TimeGenerated, UserPrincipalName, AADObjectID_g
;
Alert
| join kind=inner HighRiskUser on UserPrincipalName
| project TimeGenerated, ResultType, UserPrincipalName

And we see an alert for a user that was in the HighRiskUsers_CL that has been populated for us

You could also do this is via a Sentinel watchlist, but the Logic App doesn’t currently allow entries to be removed

Azure AD, Duo and Azure Sentinel

When I started first using Sentinel, one of the first use cases was tracking potentially compromised accounts, given the number of tools available from Microsoft in the identity security space – Azure AD, Azure AD Identity Protection and Cloud App Security to name a few, I would guess this is pretty common. Early on I realised that there was a lot of noise in all these alerts, bought on by the combination of people working from more locations than ever, use of private VPN’s increasing and people connecting on lots of devices; mobiles, tablets, laptops, home computers etc.

If you use non-Microsoft MFA, such as Duo, Okta or Ping (or other), then you would know from experience that Azure AD handles MFA for those products differently than its own. Instead of requiring MFA in Azure AD Conditional Access, it requires a custom control be satisfied during sign on. In terms of looking for genuine compromise within the noise, it makes it harder using these products because all sign on events are seen as only requiring single factor authentication in the eyes of Azure AD, even though a MFA challenge has been successful.

While not perfect, we know that if a user completed a MFA prompt during a sign in, then there is a good chance it is legitimate, though of course a users phone could be compromised or a person socially engineered to accept the prompt.

In the case of Duo, to try make sense of all the noise first we need to ingest the Duo authentication log into Sentinel. Duo provide a log sync agent hosted on their GitHub here, you can send this to a custom table or the CommonSecurityLog in CEF format using the log forwarder. There is also a community written Azure Function in the Azure Sentinel GitHub here, though I haven’t tested it. Once you have the logs in there, you will need to write a parser to take the information you care about

MFALogs_CL
| extend MFAOutcome  = extract("outcome=(.*?) duser", 1, SyslogMessage_s)
| extend UserPrincipalName = extract("duser=(.*?) cs2", 1, SyslogMessage_s)
| extend MFAMethod = extract("cs2=(.*?) cs3", 1, SyslogMessage_s)
| extend MFAApplication = extract("cs3=(.*?) ca", 1, SyslogMessage_s)
| extend MFAIPaddr = extract("src=(([0-9]{1,3})\\.([0-9]{1,3})\\.([0-9]{1,3})\\.(([0-9]{1,3})))",1,SyslogMessage_s) 

So from our logs we are going to extract the outcome (success or failure), the username returned from the MFA platform, what method was used (push, phone call, security key etc), which application was accessed (in this case Azure AD via the above custom control) and the IP Address the MFA challenge response came from. That will leave you with an easy set of data to work from and match to Azure AD log events (some details removed from the screenshots).

So now we have our data from our MFA provider, how do we make sense of an impossible travel action for example and see if it’s noise or not? We can do that via the KQL join operator, which lets us run multiple queries and then join them on matching column.

MFALogs_CL
| extend MFAOutcome  = extract("outcome=(.*?) duser", 1, SyslogMessage_s)
| extend UserPrincipalName = extract("duser=(.*?) cs2", 1, SyslogMessage_s)
| extend MFAMethod = extract("cs2=(.*?) cs3", 1, SyslogMessage_s)
| extend MFAApplication = extract("cs3=(.*?) ca", 1, SyslogMessage_s)
| extend MFAIPaddr = extract("src=(([0-9]{1,3})\\.([0-9]{1,3})\\.([0-9]{1,3})\\.(([0-9]{1,3})))",1,SyslogMessage_s) 
| extend MFATime = TimeGenerated
| project MFATime, UserPrincipalName, MFAOutcome, MFAMethod, MFAApplication, MFAIPaddr
| where UserPrincipalName == "username@domain.com"
| sort by MFATime desc
| join kind=inner (SigninLogs
| extend SigninTime = TimeGenerated
| where UserPrincipalName == "username@domain.com"
| project SigninTime, ResultType, AppDisplayName, IPAddress, Location, UserAgent
| sort by SigninTime desc) on $left.MFAIPaddr == $right.IPAddress
| where MFATime between ((SigninTime-timespan(10min)).. (SigninTime+timespan(10min)))

So our query looks at our custom MFA log and parses out the details needed to then join to an Azure AD sign in event. We join the two queries together based on a match on IP Address, then look for any events that occur within 20 minutes (mostly to account for log delay, you could tighten this up if you wanted to suit you environment). You are left with the events that meet that criteria –

So when you get an impossible travel alert, you could use Azure Sentinel entity mapping to retrieve the userprincipalname then feed it back into this hunting query to get you some valuable info about MFA events associated, or just jump into the logs and run this manually. Often mobile devices won’t be on the same network as the logon event, so it isn’t perfect, but helpful guidance to decide the importance of the alert.

If you wanted to do more proactive hunting you could leverage the same query but look for ‘successful’ sign ins to Azure AD followed by a MFA failure. When you use non Microsoft MFA, a user will sign on using their credentials and then a ResultType of 50158 is triggered, which means ‘external security challenge not yet satisfied’, so we could hunt for logons with that ResultType and a MFA failure in the same 20 minute period. This time though, we don’t want to join based on IP Address. If a user signs into Azure AD then fails MFA from the same IP address, chances are they just can’t find their phone, so this time we join on UserPrincipalName

MFALogs_CL
| extend MFAOutcome  = extract("outcome=(.*?) duser", 1, SyslogMessage_s)
| extend UserPrincipalName = extract("duser=(.*?) cs2", 1, SyslogMessage_s)
| extend MFAMethod = extract("cs2=(.*?) cs3", 1, SyslogMessage_s)
| extend MFAApplication = extract("cs3=(.*?) ca", 1, SyslogMessage_s)
| extend MFAIPaddr = extract("src=(([0-9]{1,3})\\.([0-9]{1,3})\\.([0-9]{1,3})\\.(([0-9]{1,3})))",1,SyslogMessage_s) 
| extend MFATime = TimeGenerated
| project MFATime, UserPrincipalName, MFAOutcome, MFAMethod, MFAApplication, MFAIPaddr
| where MFAOutcome == "FAILURE"
| sort by MFATime desc
| join kind=inner (SigninLogs
| extend SigninTime = TimeGenerated
| where ResultType == "50158"
| project SigninTime, UserPrincipalName, ResultType, AppDisplayName, IPAddress, Location, UserAgent
| sort by SigninTime desc) on UserPrincipalName
| where MFATime between ((SigninTime-timespan(10min)).. (SigninTime+timespan(10min)))

This will then output any events where a user has triggered a 50158 event (correct username and password but then stopped by a custom control), then a MFA failure within 20 minutes. The IP address could still match here, but if it doesn’t then it is probably worth resetting their password & revoking their sessions until you can contact them.