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.
Please note it's not currently possible to use a NOT operator with a wildcard.
Basic Search Syntax
We leverage ES|QL for Huntress Managed SIEM, and documentation is linked in the Huntress Portal. 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] == [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:
or by clicking the “Load logs older than {}” button at the bottom of the search results:
"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).
"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:
"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 currently building parsers for a variety of firewall devices, which is required due to the lack of a standard message format. Once those have been built, you will see the event.provider available for those messages and have fields available for searching.
Example 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"
Active Directory-related Queries
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