TEAM: Huntress SIEM 
PRODUCT: Huntress Managed SIEM
ENVIRONMENT: Microsoft Windows and Active Directory (AD)
SUMMARY: Starter Queries for Windows Security involving account group changes, logon and logoff activity, failed logons, user auth events, password resets, new scheduled task, new service, and event log tampering.

Huntress SIEM and Microsoft Windows logs are case sensitive. The LIKE operator ignores case, so when searching for fields where the case may vary it’s recommended to use LIKE instead of ==. Typically those fields include user.name, host.hostname, and source.host.name but may include other data sets!

Query List

• Adding/Removing Accounts from Groups
• Group Management Events
• Account Management Events
• Password Resets
• Event Log Tampering
• New Service or Scheduled Task
• Getting Started with User Authentication Events
  • Logon Activity
  • Logoff Activity
  • Failed Logons

Adding/Removing Accounts from Groups

Description

This search returns all instances of accounts being added or removed from Windows groups. These groups could be local groups or Domain groups. The search can be further filtered by specifying the name of a group or groups of interest. Examples of this are documented in the Additional Filter Options section.

Search Query

from logs |
where event.provider=="Microsoft-Windows-Security-Auditing" |
where event.code in (4728, 4732, 4746, 4751, 4756, 4761, 4729, 4733, 4747, 4752, 4757, 4762) |
keep host.hostname, event.code, winlog.event_data.MemberName, winlog.event_data.MemberSid, winlog.event_data.TargetDomainName, winlog.event_data.TargetUserName, winlog.event_data.SubjectDomainName, winlog.event_data.SubjectUserName

Additional Filter Options

Limit to Local Privileged Groups

This query adds a filter to focus on two local groups (Administrators and Remote Desktop Users). These two default groups grant extra privilege to their members with Administrators granting full admin rights and Remote Desktop Users granting the ability to logon over RDP. Both of these groups are used by threat actors to gain persistence.

from logs |
where event.provider=="Microsoft-Windows-Security-Auditing" |
where event.code in (4728, 4732, 4746, 4751, 4756, 4761, 4729, 4733, 4747, 4752, 4757, 4762) |
where winlog.event_data.TargetUserName=="Administrators" OR winlog.event_data.TargetUserName=="Remote Desktop Users" | 
keep host.hostname, event.code, winlog.event_data.MemberName, winlog.event_data.MemberSid, winlog.event_data.TargetDomainName, winlog.event_data.TargetUserName, winlog.event_data.SubjectDomainName, winlog.event_data.SubjectUserName

Limit to Domain Privileged Groups

This query adds a filter to focus on three domain groups (Enterprise Admins, Domain Admins, Account Operators). These three default groups grant extra privilege to their members with Enterprise Admins granting full admin rights to all domains in a forest, Domain Admins granting full admin rights to the local domain, and Account Operators granting rights allowing for management of domain accounts.

from logs | 
where event.provider=="Microsoft-Windows-Security-Auditing" |
where event.code in (4728, 4732, 4746, 4751, 4756, 4761, 4729, 4733, 4747, 4752, 4757, 4762) |
where winlog.event_data.TargetUserName=="Domain Admins" OR winlog.event_data.TargetUserName=="Account Operators" OR winlog.event_data.TargetUserName=="Enterprise Admins" | keep host.hostname, event.code, winlog.event_data.MemberName, winlog.event_data.MemberSid, winlog.event_data.TargetDomainName, winlog.event_data.TargetUserName, winlog.event_data.SubjectDomainName, winlog.event_data.SubjectUserName

Event Code Breakdown

Kept Field Descriptions

Group Management Events

Description

This search returns data describing the creation or deletion of Windows groups. This includes both local and Domain groups.

Search Query

from logs |
where event.provider=="Microsoft-Windows-Security-Auditing" |
where event.code in (4727, 4731, 4744, 4749, 4754, 4759, 4730, 4734, 4748, 4753, 4758, 4763) |
keep host.hostname, event.code, winlog.event_data.TargetDomainName, winlog.event_data.TargetUserName, winlog.event_data.SubjectDomainName, winlog.event_data.SubjectUserName

Event Code Breakdown

Kept Field Breakdown

Account Management Events

Description

This query returns results indicating the creation, modification, or deletion of an account. Modification is limited to disabling or enabling the account.

Search Query

from logs |
where event.provider=="Microsoft-Windows-Security-Auditing" |
where event.code in (4720, 4722, 4725, 4726, 4741, 4743) |
keep host.hostname, event.code, winlog.event_data.SubjectDomainName, winlog.event_data.SubjectUserName, winlog.event_data.SubjectLogonId, winlog.event_data.TargetDomainName, winlog.event_data.TargetUserName, winlog.event_data.DisplayName

Event Code Breakdown

Kept Field Breakdown

Password Resets

Description

This query returns instances where one account resets the password of another. This is uniquely different from a normal password change event which is when an account changes its own password.

Search Query

from logs | 
where event.provider=="Microsoft-Windows-Security-Auditing" | 
where event.code=="4724" | 
keep host.hostname, winlog.event_data.SubjectDomainName, winlog.event_data.SubjectUserName, winlog.event_data.SubjectLogonId, winlog.event_data.TargetDomainName, winlog.event_data.TargetUserName

Event Code Breakdown

Kept Field Breakdown

Event Log Tampering

Description

This query returns instances where the audit log was cleared or the logging service was shut down.

Search Query

from logs | 
where event.capability=="winlog" | 
where event.code in (1102, 104, 1100) | 
keep host.hostname, user.domain, user.name, user.id, event.outcome

Event Code Breakdown

Kept Field Breakdown

New Service or Scheduled Task

Warning: These queries are quite noisy in most systems due to automatic software updates. Careful testing and filtering should be used before applying these queries to a Scheduled Query to avoid low quality alerts. 

Note that it is technically impossible to use Windows logs to catch all forms of persistence, thus this section only addresses the simplest forms of persistence. Huntress EDR can catch many different forms of persistence and is the ultimate protection against this type of attack!

New Service Query

from logs | 
where event.capability=="winlog" | 
where event.code in (4697, 7045) | 
keep user.name, user.id, winlog.event_data.ServiceAccount, host.hostname, winlog.event_data.ServiceFileName, winlog.event_data.ServiceName

New Scheduled Task Query

from logs | 
where event.capability=="winlog" | 
where event.code in (4698, 4699, 4702) | 
keep user.name, user.id, host.hostname, winlog.event_data.TaskName, event.code

Note that event id 4702 is quite noisy so you may wish to remove it from your query or filter the results further. For example adding where user.name NOT LIKE "*$*" would filter out service accounts.

Event Code Breakdown

Kept Field Breakdown

User Authentication Events

There are a number of intricacies with tracking authentication activity due to the wide range of sources, so here's some useful info about event codes and logon types before you get started.

Starter Queries for User Logon Activity

Note: Windows does not log these events by default. The Huntress agent will automatically set this policy to the correct level, provided you don’t have a competing system setting policy (see https://support.huntress.io/hc/en-us/articles/51811065416851-Finding-the-Source-of-Windows-Logging-Audit-Policy-Configuration)

Description

These queries return all instances of user accounts that have logged on in the time frame specified. 

from logs | 
where event.capability==”winlog” | 
where event.code in (4624, 4648) 

Additional Filter Options

Filter Logons by Organization

For this you’ll want to search in the org scope by clicking SIEM (icon on the far left) > SIEM Dashboard > at the top left where it says “Account” or “Organization” click to select the org you want to view (should say “Account: __” if in account scope or “Organization:__” if you’re in the org scope). The KEEP operator ensures the user name and endpoint name are displayed.

from logs | 
where event.capability==”winlog” | 
where event.code in (4624, 4648) | 
keep user.name, host.hostname

Filter Logons by User

This query shows all logons by a user you specify, simply replace $username with the logon name of the user you’re looking for (leave the * in as wildcards). Additionally, this query displays the name of the endpoint the user logged into, and the type of logon performed. 

from logs | 
where event.capability==”winlog” | 
where event.code in (4624, 4648) | 
where user.name LIKE “*$username*” | 
keep host.hostname, logon.type

Count all Unique Users

Useful for seeing all users who have logged in and a total number of logons, typically done in the agent scope such as a DC.

from logs | 
where event.capability==”winlog” | 
where event.code in (4624, 4648) | 
stats count() by user.name

Show all Endpoints a User Logged on

Similar to the two queries above, this variation shows all endpoints that a specific user has logged into and the type of logon performed. This is best done in the org or account scope to ensure you capture all endpoint activity. Just replace $username with the user’s logon name (leave the * in as wildcards).

from logs | 
where event.capability==”winlog” | 
where event.code in (4624, 4648) | 
where user.name LIKE “*$username*” | 
stats count() by host.hostname

View Remote Endpoint Name (remote logon)

This query shows all remote logons and displays the name of the user who logged in, the name of the remote endpoint, and the IP address of the remote endpoint.

from logs | 
where event.capability==”winlog” | 
where event.code in (4624, 4648) | 
where logon.type in (3, 10) | 
keep user.name, source.host.name, source.ip

Starter Queries for User Logoff Activity

Description

These queries return all logged(*) instances of user accounts that have logged off in the time frame specified. The search can be further filtered to specific endpoint names, user names, or logon types (see logon types for more info). 

(*)Note that there are several cases in which Windows will not display logoff events including:

• Logon types 3, 4, and 5 do not generate logoff events 
• Logon type 2 and 10: if the user closes the RDP window, puts their endpoint to sleep, locks their endpoint, hasn’t signed out yet, or force restarts the endpoint before signing out.
• If fast startup is enabled and the user shuts their endpoint down.
• If the endpoint has a “logoff after idle time” policy or a screensaver that locks the endpoint, a logoff event code won’t be generated.
• If the endpoint shuts down abruptly, encounters a blue screen, or is shut down using the power button (while the user is logged in).
• If event logs Audit Policy is not set up to store logoff events. Note the Huntress agent will automatically set this policy to the correct level, provided you don’t have a competing system setting policy (see https://support.huntress.io/hc/en-us/articles/51811065416851-Finding-the-Source-of-Windows-Logging-Audit-Policy-Configuration)

Search Query

from logs | 
where event.capability==”winlog” | 
where event.code in (4647, 4634, 4779) | 
keep target.user.name

Starter Queries for Failed Logons

Description

When looking for intrusion events you may want to look at all failed logons. This query will show all(*) failed logons, the user names, the endpoint names, and the type of logon.

(*)Note that there are several cases in which Windows will not display failed logon events including:

• If a user tries to logon via RDP to a server with Network Level Authentication (NLA) enabled, the remote machine requires valid credentials before the RDP session can start. Thus 4625 won’t be logged at the endpoint where logon was attempted.
• If the logon service is hit with a highly malformed string or invalid protocol request, LSASS may fail to process the request as an authentication attempt.
• If event logs Audit Policy is not set up to store failed logon events. Note the Huntress agent will automatically set this policy to the correct level, provided you don’t have a competing system setting policy (see https://support.huntress.io/hc/en-us/articles/51811065416851-Finding-the-Source-of-Windows-Logging-Audit-Policy-Configuration)

Search Query

from logs | 
where event.capability==”winlog” | 
where event.code==4625 | 
keep user.name, host.hostname, logon.type

Additional Filter Options

For all of these additional queries you may want to search in the org or account scope first, and then drill into specific machines. To search in the org or account scope click SIEM (far left) > SIEM Dashboard > now at the top left where it currently says “Account” or “Organization” select the org or account you want to view.

Endpoints with Failed Logons

This query shows a list of machines with failed logons. 

from logs | 
where event.capability==”winlog” | 
where event.code==4625 | 
stats count() by host.hostname

Users with Failed Logons

This query shows a list of users with failed logons. 

from logs | 
where event.capability==”winlog” | 
where event.code==4625 | 
stats count() by user.name

IP of Failed Remote Logons

This query shows all the IP addresses associated with failed logons. Query views all IP addresses, user names, the endpoint the user attempted to logon to (host.hostname), and name of the endpoint the user attempted to logon from (source.host.name).

from logs | 
where event.capability==”winlog” | 
where event.code==4625 | 
where logon.type in (3, 10) | 
keep source.ip, user.name, host.hostname, source.host.name