TEAM: Huntress SIEM 
PRODUCT: Huntress Managed SIEM
ENVIRONMENT: ITDR
SUMMARY: Starter Queries for Azure Active Directory

Please note that Huntress SIEM is case sensitive!

Query List

Failed Authentication Attempts

Global Admin Role Assignments

Enabling/Disabling Multi-Factor Authentication

Starter Queries for User Login Activity

Starter Queries for Reviewing User Activity per Workload

A Typical Investigation

Failed Authentication Attempts

Description

This search returns authentication failures against Azure Active Directory accounts and systems. Additional filters can be applied to limit results to specific failure reasons.

Search Query

from logs
| where event.provider=="ITDR"
| where itdr.Operation=="UserLoginFailed"
| keep itdr.UserKey, itdr.UserId, client.ip, itdr.LogonError

Additional Filters

The additional "where" clause restricts the reason for failure to conditional access failures.

from logs
| where event.provider=="ITDR"
| where itdr.Operation=="UserLoginFailed"
| where itdr.ErrorNumber=="50131" OR itdr.ErrorNumber=="53003" OR itdr.ErrorNumber=="530032"
| keep itdr.UserKey, itdr.UserId, client.ip, itdr.LogonError

Kept Field Breakdown

Global Admin Role Assignments

Description

This search returns results showing an Azure account being added to the Global Administrator role. This role grants admin permissions across the entire tenant and all services hosted within. Instances where this occurs as part of normal, background activity are excluded.

Search Query

from logs
| where event.provider=="ITDR"
| where itdr.Operation=="Add member to role."
| where itdr.ModifiedProperties LIKE "%Global Administrator%"
| where itdr.UserType!="4"
| keep itdr.UserId, itdr.ObjectId

Kept Field Breakdown

Enabling/Disabling Multi-Factor Authentication

Description

This search returns changes made to an account’s multi-factor authentication state. This is frequently done by system processes as part of account onboarding and off-boarding. Any instances of non-system accounts performing this activity

Search Query

from logs
| where event.provider=="ITDR"
| where itdr.Operation=="Enable Strong Authentication." OR itdr.Operation=="Disable Strong Authentication."
| keep itdr.Operation, itdr.UserId, itdr.UserType, itdr.ObjectId

Additional Filter Options

Removes instances where the account performing the action is a system account.

from logs
| where event.provider=="ITDR"
| where itdr.Operation=="Enable Strong Authentication." OR itdr.Operation=="Disable Strong Authentication."
| where itdr.UserType!=”4”
| keep itdr.Operation, itdr.UserId, itdr.UserType, itdr.ObjectId

Kept Field Breakdown

Starter Queries for User Login Activity

Description

Search for identity activity based on IP, just replace $IP_ADDRESS with the IP address in question. 

Search Query

from logs
| where client.ip=="$IP_ADDRESS"
| keep itdr.Operation

Search for a specific user's activity, just replace $USER_EMAIL with the email address of the user in question. It's suggested to use the operator LIKE instead of the equivalency operator == in case the user's email is capitalized, Huntress SIEM is case sensitive while Huntress ITDR tends to convert everything to lowercase.

Search Query

from logs | 
where itdr.UserId LIKE "$USER_EMAIL" |
keep itdr.Operation, client.ip, source.ip

Now you can easily combine these like this example, which searches for all login activity coming from 1.1.1.1. We use "keep" here to show the UserId column to differentiate between users, and to show the itdr.DeviceProperties field for additional information:

Search Query

from logs | 
where client.ip=="1.1.1.1" |
where itdr.Operation=="UserLoginFailed" OR itdr.Operation=="UserLoggedIn" |
keep itdr.UserId, itdr.DeviceProperties

Starter Queries for Reviewing User Activity per Workload

Description

Before we get started, note that the structure of queries can be mixed and matched to suit your investigation's needs. I'm providing some common examples of queries to provide working examples we use during everyday investigations. Don't be afraid to get creative!

Let's keep the session.id of login, Mail, or SharePoint sessions so that we can review actions taken during a user's session:

Search Query

from logs
| where itdr.UserId == "$USER_EMAIL"
| where client.ip ("$IP_ADDRESS") OR source.ip ("$IP_ADDRESS")
| keep client.ip, source.ip, itdr.Operation, session.id, itdr.DeviceProperties.DisplayName, itdr.Workload

Field Breakdown

A Typical Investigation will begin by asking a question like: "I need to find out what a user performed after they logged in", to which the following three queries can get you started in answering our previously posed question.
 

Let's pivot to searching through specific workflows with a session ID to highlight activity from one of three options: AzureActiveDirectory, Exchange, and SharePoint.

AzureActiveDirectory will store user activity (e.g. login events, account actions).

Exchange will return mailbox-related events (e.g. subject lines, internetmessageids, bind/sync operations).

SharePoint will return SharePoint related events (e.g. files accessed, file actions, administrative actions).

You can search through user login events by including AzureActiveDirectory in the itdr.Workload field:

Search Query

from logs
| where session.id like "*$SESSION_ID*"
| where itdr.Workload == "AzureActiveDirectory"
| keep client.ip, source.ip, itdr.Operation, itdr.DeviceProperties.DisplayName, message

# Replace session.id with "itdr.UserId like "$USER_EMAIL" if you'd like to search on a per user basis.
# Replace session.id with "itdr.UserId like "$USER_EMAIL_DOMAIN" if you'd like to search for all users in the domain.

You can search through Mail events by including Exchange in the itdr.Workload field:

Search Query

from logs
| where session.id like "*$SESSION_ID*"
| where itdr.Workload == "Exchange"
| keep client.ip, source.ip, itdr.Operation, itdr.Item.Subject, itdr.Item.InternetMessageId, message, itdr.Folders, itdr.Item.InternetMessageId

# Replace session.id with "itdr.UserId like "$USER_EMAIL" if you'd like to search on a per user basis.
# Replace session.id with "itdr.UserId like "$USER_EMAIL_DOMAIN" if you'd like to search for all users in the domain.

You can search through SharePoint events by including SharePoint in the itdr.Workload field:

Search Query

from logs
| where session.id like "*$SESSION_ID*"
| where itdr.Workload == "SharePoint"
| keep client.ip, source.ip, itdr.UserId, message, itdr.ObjectId, itdr.SourceFileName

# Replace session.id with "itdr.UserId like "$USER_EMAIL" if you'd like to search on a per user basis.
# Replace session.id with "itdr.UserId like "$USER_EMAIL_DOMAIN" if you'd like to search for all users in the domain.

You can use the COUNT(*) BY operator to aggregate results to review all user activity in a single pane:

Search Query

from logs
| where itdr.UserId == "$USER_EMAIL"
| COUNT(*) BY client.ip, source.ip, itdr.Operation, itdr.ClientIPAddress, session.id