Team: Huntress SIEM 
Product: Huntress Managed SIEM
Environment: ITDR
Summary: This article provides example SIEM lookup queries you can use when investigating Huntress ITDR activity by user, IP address, and Microsoft workload. These queries are intended as starting points for investigations and may need to be adjusted depending on your environment.

Please note that Huntress SIEM is case sensitive!

In this article

• 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

• Email activity

• Generic ITDR filtering by IP

• Teams activity

• SharePoint activity

• OneDrive activity

Before you begin

Some of the example queries below use placeholders. Replace these values before running the query:

• $USER_EMAIL with the target user ID

• "$IP_ADDRESS" with the relevant value, such as a username or IP address

Failed Authentication Attempts

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

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

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:

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

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:

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

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

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:

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:

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

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:

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:

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:

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:

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:

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

Email activity

Use the following queries to review email-related activity for a specific user.

This section helps identify mail-related actions tied to a user, including sent-message activity and broader mailbox operations that may be useful during suspicious account activity reviews.

Email send activity

from logs
| where itdr.UserId == "$USER_EMAIL"
| where itdr.Operation like "*send*"
| keep itdr.ClientIPAddress, itdr.ClientIP, itdr.Operation, itdr.DeviceProperties.SessionId, itdr.AppAccessContext.AADSessionId, itdr.DeviceProperties.DisplayName, itdr.Item.Subject

General mail activity

from logs
| where itdr.UserId == "$USER_EMAIL"
| where itdr.Operation like "*Mail*"
| keep itdr.ClientIPAddress, itdr.ClientIP, itdr.Operation, itdr.DeviceProperties.SessionId, itdr.AppAccessContext.AADSessionId, itdr.DeviceProperties.DisplayName, itdr.Item.Subject

Generic ITDR filtering by IP

Use this query when you want to filter ITDR activity for a specific user and one or more source IP addresses.

This section is useful when validating whether a known source IP appears across a user’s ITDR activity, especially during account compromise or suspicious sign-in investigations. In the below example you can filter singular or multiple IP addressed separated with a comma as part of the lookup:

from logs
| where itdr.UserId == "$USER_EMAIL"
| where itdr.ClientIP in ("$IP_ADDRESS","$IP_ADDRESS") OR itdr.ClientIPAddress in ("$IP_ADDRESS","$IP_ADDRESS")
| keep itdr.ClientIPAddress, itdr.ClientIP, itdr.Operation

Teams activity

Use this query to review Microsoft Teams-related ITDR events.

This section helps identify collaboration activity in Teams, including messaging, team changes, channel actions, and file-related events tied to the investigated user. Further information on useful fields for review are found below at the bottom of this Knowledgebase:

from logs
| where event.provider == "ITDR"
| where itdr.Workload == "MicrosoftTeams"
| keep itdr.UserId, itdr.Operation, message, itdr.ObjectId, itdr.SourceFileName, itdr.UserAgent, itdr.ClientIP

SharePoint activity

Use this query to review SharePoint-related activity for a specific user.

This section is useful for reviewing document access and collaboration activity in SharePoint, including file names, operations, source objects, and user session context. Further information on useful fields for review are found below at the bottom of this Knowledgebase:

from logs
| where itdr.UserId == "$USER_EMAIL"
| where itdr.Workload == "SharePoint"
| keep itdr.ObjectId, itdr.SourceFileName, itdr.Operation, itdr.UserAgent, itdr.UserId, itdr.ClientIP, session.id

OneDrive activity

Use this query to review OneDrive-related ITDR events.

This section helps identify file access and synchronization activity in OneDrive, which can be useful when reviewing potential data access, download, or exfiltration behavior. Further information on useful fields for review are found below at the bottom of this Knowledgebase:

from logs
| where event.provider == "ITDR"
| where itdr.Workload == "OneDrive"
| keep itdr.UserId, itdr.Operation, message, itdr.ObjectId, itdr.SourceFileName, itdr.UserAgent, itdr.ClientIP

SharePoint and OneDrive useful fields

The below logged operations can be useful when narrowing SharePoint or OneDrive investigations.

• FileModified - User or system account modifies the content or properties of a document on a site.

• FileModifiedExtended - Logged when the same person continually modifies a file for an extended period of time, up to three hours.

• FileAccess - User or system account accesses a file.

• FileAccessExtended - Logged when the same person continually accesses a file for an extended period of time, up to three hours.

• FileSyncDownloadedFull - User downloaded a file to their computer from a SharePoint document library or OneDrive using the OneDrive sync app.

• FileSyncUploadedFull - User uploaded a new file or changes to a file in a SharePoint document library or OneDrive by using the OneDrive sync app.

• AnonymousLinkUsed - An anonymous user accessed a resource by using an anonymous link. The user's identity might be unknown, but other details such as the user's IP address may still be available.

• SharingLinkUsed - A link to a file was used to access the file.

• FilePreviewed - User previews files on a SharePoint or OneDrive site. These events typically occur in high volumes based on a single activity, such as viewing an image gallery.

• FileDownloaded - User downloads a document from a site.

• FileRestored - User restores a document from the recycle bin of a site.

• FileMalwareDetected - The SharePoint anti-virus engine detects malware in a file.

Teams useful fields

Similarly to SharePoint and OneDrive, logged operations can be useful when narrowing Microsoft Teams investigations.

• ChatCreated - A Teams chat was created.

• TeamCreated - A user creates a team.

• MessageDeleted - A message in a chat or channel was deleted.

• ChannelDeleted - A user deletes a channel from a team.

• TeamDeleted - A team owner deletes a team.

• DownloadedFile - User downloaded a file attached to an approval request.

• AppInstalled - An app was installed.

• MessageSent - A new message was posted to a chat or channel.

• MessageCreatedHasLink - A user sends a message containing a URL link in Teams.

Support

• Any issues with any of the query lookups, feel free to reach out to Huntress support for further advice.