TEAM: Huntress Managed Security Information and Event Management (SIEM) 
ENVIRONMENT: Huntress Managed SIEM dashboard
SUMMARY: This guide goes over searching the Huntress SIEM Logs with some examples you can use to find specific events.

Basic Search Syntax

We leverage ES|QL for Huntress Managed SIEM, and the Elastic documentation can be found here. This documentation is not meant to be exhaustive, but is meant to provide some examples that may inspire your searches without becoming an expert in the ES|QL language.

The basic structure is as follows:

from logs | where [column_name] [operator] [value]

Let’s look specifically for Event ID 4624, which is a successful account logon:

from logs | where event.code == 4624

The default return time range is the previous hour, and you can expand that timeframe by modifying the “Time Range” field:

We will only pull in the first 100 logs returned per query, however you can load additional results through the "Load More" button at the bottom of the results table.

ESQL Logical Operators

ESQL includes a number of logical operators to help frame and structure a query. Huntress Managed SIEM includes a subset of these operators, initially based on usefulness. We'll continue to expand what operators we support over our near term roadmap.

We currently support the following operators:

FROM logs | 
WHERE winlog.event_data.TargetUserName 
LIKE "%Admin%"

FROM logs | 
WHERE event.provider 
NOT LIKE "%powershell%"

FROM logs | 
WHERE message 
LIKE "permissions%" 
AND event.provider == 
"Microsoft-Windows-Security-Auditing"

FROM logs | 
WHERE event.code != “4106” 
OR message LIKE "permission%"

FROM logs |
WHERE "192.168"
IN source.ip

FROM logs | 
WHERE event.code == 4624

FROM logs | 
WHERE event.code != 4624

FROM logs | 
WHERE event.code > 1

FROM logs | 
WHERE event.code < 2

FROM logs | 
WHERE source.ip IS NULL | 
KEEP source.ip

FROM logs | 
WHERE host.os.name IS NOT NULL | 
KEEP host.os.name

FROM logs | WHERE starts_with(event.provider, "Cloud")

FROM logs | WHERE ends_with(event.provider, "Trail")

FROM logs | WHERE event.provider == "Duo" AND cidr_match(client.ip, "216.122.236.0/24")

FROM logs | WHERE to_upper(event.provider) == "CLOUDTRAIL"

FROM logs | WHERE to_lower(event.provider) LIKE "%powershell%"

ESQL Processing Operators

Processing Operators allow users to define how the returned data is structured. Huntress Managed SIEM supports three processing operators from ESQL.

WHERE

This is the most basic of search commands. You can “chain” multiple where statements in order to do filtering with multiple criteria. Let’s take the above example, but instead of returning all the logs with John.Doe as the user, let’s “filter” for successful logons instead of just showing all the events containing his name:

from logs | where winlog.event_data.TargetUserName == "john.doe" | where event.code == 4624| keep event.code, winlog.event_data.TargetUserName, winlog.event_data.LogonType

Notice the second | where statement, which indicates we’re adding an additional field. Huntress takes these multiple where statements and combines them (similar to how you would use AND in other tools), filtering results to see just the ones that match all the criteria:

Let’s go one step further, because John Doe seems to log on a lot. Let’s find just interactive sessions, because that means they are directly logging into a machine which is more relevant for our search:

from logs | where winlog.event_data.TargetUserName == "john.doe" | where event.code == 4624 | where winlog.event_data.LogonType == "2"  | keep event.code, winlog.event_data.TargetUserName, winlog.event_data.LogonType

That’s more like it: 

STATS Processors

COUNT

Count is a command in ES|QL that allows users to get the number of instances per unique value of a field. For example, finding the number of logs per user.name. This is an excellent tool for summarizing a large volume of query results and then quickly pivoting based on the findings. The Count operator can be used as shown:

from logs | where user.name != "" | stats count() by user.name

COUNT DISTINCT

Count Distinct is a command in ES|QL that allows users to count the number of unique field values within a subset of data. For example, to find the number of unique event codes per user, you would create a query as shown:

from logs | where user.name != "" | stats count_distinct(event.code) by user.name

SUM

The SUM processor will add all values of a specific field and display the summed total of that field across all results.

from logs | where event.code == 4104 | stats sum(winlog.event_data.MessageTotal)

MIN

The MIN processor will display the lowest value from a field across a set of query result data.

from logs | where event.code == 4104 | stats min(winlog.event_data.MessageTotal)

MAX

The MAX processor will display the highest value from a field across a set of query result data.

from logs | where event.code == 4104 | stats max(winlog.event_data.MessageTotal)

KEEP

Keep is a command in ES|QL that allows you to specify the columns returned in your search results. Let’s say you want to find events for a specific user. This command will allow you to return that TargetUserName field from the Event Logs in your search, as shown below:

from logs | where winlog.event_data.TargetUserName == "john.doe" | keep event.code, winlog.event_data.TargetUserName

Since Huntress already knows the Agent hostname, you don’t necessarily need to include that field in your KEEP statement, because we’ll show the host where the event was collected from.

All fields from the <EventData> tag in the XML from the Event Logs are being extracted and placed under the winlog.event_data scope. This means, depending on the EventID, you can pull a variety of fields and have them returned in your results. 

In the example below, we’re including the logon type to help identify any interactive logins that may have occurred by this particular user:

from logs | where winlog.event_data.TargetUserName == "john.doe"| keep event.code, winlog.event_data.TargetUserName, winlog.event_data.LogonType

Here we can see there was an interactive logon at 08:39 AM Eastern Time (as noted by the -04:00 at the end of the timestamp).

DROP

DROP is the opposite of KEEP and can be used to remove default field columns. This is useful for generating refined Saved and Scheduled Queries output, or in the future, refined API query results.

from logs | where event.code == 4104 | drop event.provider, message

LIMIT

This command limits the number of returned results, returning the first ___ based on your query.

from logs | where event.code == 4624 | LIMIT 10

Available Fields

Due to Event Logs providing different data based on the type, the field may vary. However, you can click on “View” for any event and see what fields are available as ECS fields as well as the raw data. This can help you determine which fields you want to have visible as well as provide you with the raw data should you need it. See below for an example:

Note: make sure for any where statements in your search that you use double-quotes for values you are searching for. This is especially important in the winlog.event_data scope, as the values are converted to strings in the ECS data that you are querying.

Syslog Events

Huntress is constantly expanding our parsed syslog sources. These sources include the most common firewalls, web filters, and appliances. Once a service parser has been built, you will see the event.provider available for those messages and the critical fields will be parsed into our ECS schema.

Example Syslog Queries

In this section, you will find example queries that are meant as a starting point for you to build your own queries. 

To show only syslog messages, you can use the following query:

from logs | where event.capability == "syslog"

Successful RDP Logins

The query below provides successful remote (RDP) logins, while keeping relevant fields and limiting results to 5:

IpAddress: the IP Address where the authentication originated

TargetUserName: the user account used in the successful login

WorkstationName: (if available) the workstation name where the RDP connection originated

from logs | where event.provider == "Microsoft-Windows-Security-Auditing" | where event.code == 4624 | where winlog.event_data.LogonType == 7 OR winlog.event_data.LogonType == 10 | where winlog.event_data.IpAddress != "-" | where winlog.event_data.IpAddress != "127.0.0.1" | where winlog.event_data.IpAddress != "0.0.0.0"
  | keep winlog.event_data.IpAddress, winlog.event_data.TargetUserName, winlog.event_data.WorkstationName
  | LIMIT 5 

User Creation

The query below provides new users created, including relevant fields:

SubjectUserName: the Username that created the account

TargetUserName: the User account that was created

TargetDomainName: the domain in which the user was created

  from logs | where event.code == 4720| keep winlog.event_data.SubjectDomainName,
  winlog.event_data.SubjectUserName, winlog.event_data.TargetUserName, winlog.event_data.TargetDomainName

Firewall-related Queries

The query below shows IP address assignments and successful logins for SSL VPN connections from SonicWall devices. This query also filters out broadcast messages that may exist, and keeps both the message and message code fields. More details on SonicWall log messages can be found in their Log Events Reference Guide (7.0.1)

from logs | where sonicwall.m == "1079" | where message != "destination for 255.255.255.255 is not allowed by access control" | keep sonicwall.m, message

The query below shows successful VPN authentication with the user that authenticated. Depending on how users authenticate with the SonicWall device, the username may be stored in a different field. Both relevant fields are kept below in this query.

from logs | where sonicwall.m == "1080" | keep sonicwall.m, message, sonicwall.note, source.ip