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
Enabling/Disabling Multi-Factor Authentication
Starter Queries for User Login Activity
Starter Queries for Reviewing User Activity per Workload
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.LogonErrorKept Field Breakdown
|
Field |
Description |
|---|---|
|
itdr.UserKey |
An alternate ID for the account when a UPN is not present/available. |
|
itdr.UserId |
The User Principal Name (UPN) of the account that attempted to authenticate. |
|
client.ip |
The source IP of the authentication attempt. |
|
itdr.LogonError |
A description for why the authentication attempt failed. |
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.ObjectIdKept Field Breakdown
|
Field |
Description |
|---|---|
|
itdr.UserId |
The account that performed the action. |
|
itdr.ObjectId |
The account that was added to the Global Administrator role. |
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.ObjectIdAdditional 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.ObjectIdKept Field Breakdown
|
Field |
Description |
|---|---|
|
itdr.Operation |
The operation performed. Indicates whether MFA was added or removed from the target account. |
|
itdr.UserId |
The User Principal Name (UPN) of the account that performed the action. |
|
itdr.UserType |
The type of account that performed the action. Types are defined here. |
|
itdr.ObjectId |
The UPN of the account that was modified. |
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.WorkloadField Breakdown
|
Field |
Description |
|---|---|
|
client.ip |
Returns data related to mailbox activity. |
|
session.id |
Returns the session ID associated with a user's session. Generally encapsulates user activity over a period of time. |
|
itdr.DeviceProperties.DisplayName |
Returns a user's assigned managed device. This field will be empty if the session belongs to an unmanaged device. |
|
itdr.Item.Subject |
Returns the subject line of emails. |
|
itdr.Workload |
Returns the respective log source (e.g. AzureActiveDirectory, Exchange, SharePoint) |
|
message |
Returns a brief description of an event's action, such as accessing an email or a user logging in. |
|
itdr.Item.InternetMessageId |
Returns the respective identifier for email items, such as a sent email. |
|
itdr.Folders |
Returns the raw data of accessed inbox items. Includes InternetMessageIds, email subject lines, and timestamps. |
|
itdr.ObjectId |
Returns the object that was accessed, viewed, or modified, and its path relative in the SharePoint site. |
|
itdr.SourceFileName |
Returns the specific file that was accessed, viewed, or modified. |
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