Hide Query

Show Query

#event_simpleName=ProcessRollup2
| table([#event_simpleName, #cid, @rawstring], limit=100)

Falcon LogScale has the ability to apply tags to events. In doing so, it allows LogScale to quickly and efficiently include or exclude large collections of events as you search. The application of tags to telemetry is all done for you transparently when dealing with Falcon data. The reason we're mentioning it is: one very important field, event_simpleName, is tagged in LogScale. Because of this, when you specify an event_simpleName value in your LogScale syntax, you need to put a # (hash or pound) in front of that field. That's it. We'll start the query like this in LogScale:

#event_simpleName=ProcessRollup2

The same concept applies to the field cid:

#event_simpleName=ProcessRollup2 #cid=123456789012345678901234

If you forget, or want to know what other events are tagged, you can just look in the LogScale sidebar for anything starting with #.

Hide Query

Show Query

// this query is quite advanced and not something you need to understand now
groupBy(#event_simpleName, function=fieldset())
| availableFields := rename(field)
| groupBy([#event_simpleName], function=([{sort(order=desc, availableFields) | collect([availableFields])}]))

Falcon LogScale has the ability to apply tags to events. In doing so, it allows LogScale to quickly and efficiently include or exclude large collections of events as you search. The application of tags to telemetry is all done for you transparently when dealing with Falcon data. The reason we're mentioning it is: one very important field, event_simpleName, is tagged in LogScale. Because of this, when you specify an event_simpleName value in your LogScale syntax, you need to put a # (hash or pound) in front of that field. That's it. We'll start the query like this in LogScale:

#event_simpleName=ProcessRollup2

The same concept applies to the field cid:

#event_simpleName=ProcessRollup2 #cid=123456789012345678901234

If you forget, or want to know what other events are tagged, you can just look in the LogScale sidebar for anything starting with #.

Hide Query

Show Query

#event_simpleName=ProcessRollup2
| table([#event_simpleName, #cid, @rawstring], limit=100)

Falcon LogScale has the ability to apply tags to events. In doing so, it allows LogScale to quickly and efficiently include or exclude large collections of events as you search. The application of tags to telemetry is all done for you transparently when dealing with Falcon data. The reason we're mentioning it is: one very important field, event_simpleName, is tagged in LogScale. Because of this, when you specify an event_simpleName value in your LogScale syntax, you need to put a # (hash or pound) in front of that field. That's it. We'll start the query like this in LogScale:

#event_simpleName=ProcessRollup2

The same concept applies to the field cid:

#event_simpleName=ProcessRollup2 #cid=123456789012345678901234

If you forget, or want to know what other events are tagged, you can just look in the LogScale sidebar for anything starting with #.

Hide Query

Show Query

#event_simpleName=ProcessRollup2
| table([#event_simpleName, #cid, @rawstring], limit=100)

Falcon LogScale has the ability to apply tags to events. In doing so, it allows LogScale to quickly and efficiently include or exclude large collections of events as you search. The application of tags to telemetry is all done for you transparently when dealing with Falcon data. The reason we're mentioning it is: one very important field, event_simpleName, is tagged in LogScale. Because of this, when you specify an event_simpleName value in your LogScale syntax, you need to put a # (hash or pound) in front of that field. That's it. We'll start the query like this in LogScale:

#event_simpleName=ProcessRollup2

The same concept applies to the field cid:

#event_simpleName=ProcessRollup2 #cid=123456789012345678901234

If you forget, or want to know what other events are tagged, you can just look in the LogScale sidebar for anything starting with #.

Hide Query

Show Query

#event_simpleName=ProcessRollup2
| table([#event_simpleName, #cid, @rawstring], limit=100)

Falcon LogScale has the ability to apply tags to events. In doing so, it allows LogScale to quickly and efficiently include or exclude large collections of events as you search. The application of tags to telemetry is all done for you transparently when dealing with Falcon data. The reason we're mentioning it is: one very important field, event_simpleName, is tagged in LogScale. Because of this, when you specify an event_simpleName value in your LogScale syntax, you need to put a # (hash or pound) in front of that field. That's it. We'll start the query like this in LogScale:

#event_simpleName=ProcessRollup2

The same concept applies to the field cid:

#event_simpleName=ProcessRollup2 #cid=123456789012345678901234

If you forget, or want to know what other events are tagged, you can just look in the LogScale sidebar for anything starting with #.

Hide Query

Show Query

#event_simpleName=ProcessRollup2
| table([#event_simpleName, #cid, @rawstring], limit=100)

Falcon LogScale has the ability to apply tags to events. In doing so, it allows LogScale to quickly and efficiently include or exclude large collections of events as you search. The application of tags to telemetry is all done for you transparently when dealing with Falcon data. The reason we're mentioning it is: one very important field, event_simpleName, is tagged in LogScale. Because of this, when you specify an event_simpleName value in your LogScale syntax, you need to put a # (hash or pound) in front of that field. That's it. We'll start the query like this in LogScale:

#event_simpleName=ProcessRollup2

The same concept applies to the field cid:

#event_simpleName=ProcessRollup2 #cid=123456789012345678901234

If you forget, or want to know what other events are tagged, you can just look in the LogScale sidebar for anything starting with #.

Hide Query

Show Query

#event_simpleName=ProcessRollup2
| table([#event_simpleName, #cid, @rawstring], limit=100)

Falcon LogScale has the ability to apply tags to events. In doing so, it allows LogScale to quickly and efficiently include or exclude large collections of events as you search. The application of tags to telemetry is all done for you transparently when dealing with Falcon data. The reason we're mentioning it is: one very important field, event_simpleName, is tagged in LogScale. Because of this, when you specify an event_simpleName value in your LogScale syntax, you need to put a # (hash or pound) in front of that field. That's it. We'll start the query like this in LogScale:

#event_simpleName=ProcessRollup2

The same concept applies to the field cid:

#event_simpleName=ProcessRollup2 #cid=123456789012345678901234

If you forget, or want to know what other events are tagged, you can just look in the LogScale sidebar for anything starting with #.

Hide Query

Show Query

#event_simpleName=ProcessRollup2
| table([#event_simpleName, #cid, @rawstring], limit=100)

Falcon LogScale has the ability to apply tags to events. In doing so, it allows LogScale to quickly and efficiently include or exclude large collections of events as you search. The application of tags to telemetry is all done for you transparently when dealing with Falcon data. The reason we're mentioning it is: one very important field, event_simpleName, is tagged in LogScale. Because of this, when you specify an event_simpleName value in your LogScale syntax, you need to put a # (hash or pound) in front of that field. That's it. We'll start the query like this in LogScale:

#event_simpleName=ProcessRollup2

The same concept applies to the field cid:

#event_simpleName=ProcessRollup2 #cid=123456789012345678901234

If you forget, or want to know what other events are tagged, you can just look in the LogScale sidebar for anything starting with #.

Hide Query

Show Query

#event_simpleName=ProcessRollup2
| table([#event_simpleName, #cid, @rawstring], limit=100)

Falcon LogScale has the ability to apply tags to events. In doing so, it allows LogScale to quickly and efficiently include or exclude large collections of events as you search. The application of tags to telemetry is all done for you transparently when dealing with Falcon data. The reason we're mentioning it is: one very important field, event_simpleName, is tagged in LogScale. Because of this, when you specify an event_simpleName value in your LogScale syntax, you need to put a # (hash or pound) in front of that field. That's it. We'll start the query like this in LogScale:

#event_simpleName=ProcessRollup2

The same concept applies to the field cid:

#event_simpleName=ProcessRollup2 #cid=123456789012345678901234

If you forget, or want to know what other events are tagged, you can just look in the LogScale sidebar for anything starting with #.

There are generally 3 different ways to format the output:

Note in the search above, I've added the Event Search syntax I want to translate to my search and quickly commented it out. This is optional, but makes the translation of queries you already have a little easier.

| groupBy(SHA256HashData, function=([count(aid, distinct=true, as=uniqueEndpoints), count(aid, as=totalExecutions), collect(CommandLine)]), limit=max)

Note the use of the square brackets after invoking function. This is because we want to use multiple aggregations in this groupBy. If you wanted to groupBy multiple fields, you would also use square brackets. As an example:

| groupBy([SHA256HashData, FileName], function=([count(aid, distinct=true, as=uniqueEndpoints), count(aid, as=totalExecutions), collect(CommandLine)]), limit=max)

The same principle would be applied if we wanted to collect multiple fields.

| groupBy([SHA256HashData, FileName], function=([count(aid, distinct=true, as=uniqueEndpoints), count(aid, as=totalExecutions), collect([CommandLine, UserSid])]), limit=max)

Note how:

collect(CommandLine)

Becomes:

collect([CommandLine, UserSid])

This takes a little practice, but once mastered the syntax is logical and very easy to interpret. To assist, LogScale will insert a closing parenthesis or closing square bracket when you open one.

Hide Query

Show Query

#event_simpleName=ProcessRollup2
| table([#event_simpleName, #cid, @rawstring], limit=100)

Falcon LogScale has the ability to apply tags to events. In doing so, it allows LogScale to quickly and efficiently include or exclude large collections of events as you search. The application of tags to telemetry is all done for you transparently when dealing with Falcon data. The reason we're mentioning it is: one very important field, event_simpleName, is tagged in LogScale. Because of this, when you specify an event_simpleName value in your LogScale syntax, you need to put a # (hash or pound) in front of that field. That's it. We'll start the query like this in LogScale:

#event_simpleName=ProcessRollup2

The same concept applies to the field cid:

#event_simpleName=ProcessRollup2 #cid=123456789012345678901234

If you forget, or want to know what other events are tagged, you can just look in the LogScale sidebar for anything starting with #.

Hide Query

Show Query

#event_simpleName=ProcessRollup2
| table([#event_simpleName, #cid, @rawstring], limit=100)

Falcon LogScale has the ability to apply tags to events. In doing so, it allows LogScale to quickly and efficiently include or exclude large collections of events as you search. The application of tags to telemetry is all done for you transparently when dealing with Falcon data. The reason we're mentioning it is: one very important field, event_simpleName, is tagged in LogScale. Because of this, when you specify an event_simpleName value in your LogScale syntax, you need to put a # (hash or pound) in front of that field. That's it. We'll start the query like this in LogScale:

#event_simpleName=ProcessRollup2

The same concept applies to the field cid:

#event_simpleName=ProcessRollup2 #cid=123456789012345678901234

If you forget, or want to know what other events are tagged, you can just look in the LogScale sidebar for anything starting with #.

Hide Query

Show Query

#event_simpleName!=*
| EventType=Event_ExternalApiEvent ExternalApiType=Event_DetectionSummaryEvent
| sankey(source="Tactic", target="Technique", weight=count(AgentIdString))

LogScale will only allow you to select compatible widgets. The desired visualization widget can also be specified in the query itself. As an example:

#event_simpleName!=* | EventType=Event_ExternalApiEvent ExternalApiType=Event_DetectionSummaryEvent | sankey(source=Tactic, target=Technique, weight=count(AgentIdString))

Hide Query

Show Query

#event_simpleName=ProcessRollup2
| table([#event_simpleName, #cid, @rawstring], limit=100)

Falcon LogScale has the ability to apply tags to events. In doing so, it allows LogScale to quickly and efficiently include or exclude large collections of events as you search. The application of tags to telemetry is all done for you transparently when dealing with Falcon data. The reason we're mentioning it is: one very important field, event_simpleName, is tagged in LogScale. Because of this, when you specify an event_simpleName value in your LogScale syntax, you need to put a # (hash or pound) in front of that field. That's it. We'll start the query like this in LogScale:

#event_simpleName=ProcessRollup2

The same concept applies to the field cid:

#event_simpleName=ProcessRollup2 #cid=123456789012345678901234

If you forget, or want to know what other events are tagged, you can just look in the LogScale sidebar for anything starting with #.

Hide Query

Show Query

#event_simpleName!=*
EventType=Event_ExternalApiEvent ExternalApiType=Event_DetectionSummaryEvent
| groupBy(SeverityName, limit=100)

Hide Query

Show Query

#event_simpleName=ProcessRollup2
| table([#event_simpleName, #cid, @rawstring], limit=100)

Falcon LogScale has the ability to apply tags to events. In doing so, it allows LogScale to quickly and efficiently include or exclude large collections of events as you search. The application of tags to telemetry is all done for you transparently when dealing with Falcon data. The reason we're mentioning it is: one very important field, event_simpleName, is tagged in LogScale. Because of this, when you specify an event_simpleName value in your LogScale syntax, you need to put a # (hash or pound) in front of that field. That's it. We'll start the query like this in LogScale:

#event_simpleName=ProcessRollup2

The same concept applies to the field cid:

#event_simpleName=ProcessRollup2 #cid=123456789012345678901234

If you forget, or want to know what other events are tagged, you can just look in the LogScale sidebar for anything starting with #.

Hide Query

Show Query

#event_simpleName=ProcessRollup2
| table([#event_simpleName, #cid, @rawstring], limit=100)

Falcon LogScale has the ability to apply tags to events. In doing so, it allows LogScale to quickly and efficiently include or exclude large collections of events as you search. The application of tags to telemetry is all done for you transparently when dealing with Falcon data. The reason we're mentioning it is: one very important field, event_simpleName, is tagged in LogScale. Because of this, when you specify an event_simpleName value in your LogScale syntax, you need to put a # (hash or pound) in front of that field. That's it. We'll start the query like this in LogScale:

#event_simpleName=ProcessRollup2

The same concept applies to the field cid:

#event_simpleName=ProcessRollup2 #cid=123456789012345678901234

If you forget, or want to know what other events are tagged, you can just look in the LogScale sidebar for anything starting with #.

By default, when using regular expression extractions, they are strict. Meaning if the data being searched does not match, it will be omitted. A quick example would be:

#event_simpleName=ProcessRollup2 ImageFileName=/\\(?<fileName>\w{3}\.\w{3}$)/i

Hide Query

Show Query

#event_simpleName=ProcessRollup2 ImageFileName=/\\(?<fileName>\w+\.\w+$)/i
| regex("(?<fourLetterFileName>^\w{4})\.exe", field=fileName, strict=false)
| groupBy([fileName, fourLetterFileName], limit=100)
| fourLetterFileName = *

Hide Query

Show Query

#event_simpleName=ProcessRollup2
| table([#event_simpleName, #cid, @rawstring], limit=100)

We can also use non-strict field extractions like so:

#event_simpleName=ProcessRollup2 ImageFileName=/\\(?<fileName>\w+\.\w+$)/i | regex((?<fourLetterFileName>^\w{4})\.exe, field=fileName, strict=false) | groupBy([fileName, fourLetterFileName], limit=100) | fourLetterFileName = *

The above looks for file names that contain four characters. If that does not match, that field is left blank.

Hide Query

Show Query

#event_simpleName=ProcessRollup2 ImageFileName=/\\(?<fileName>\w{3}\.\w{3}$)/i
| select([fileName, ImageFileName, @rawstring])

Falcon LogScale has the ability to apply tags to events. In doing so, it allows LogScale to quickly and efficiently include or exclude large collections of events as you search. The application of tags to telemetry is all done for you transparently when dealing with Falcon data. The reason we're mentioning it is: one very important field, event_simpleName, is tagged in LogScale. Because of this, when you specify an event_simpleName value in your LogScale syntax, you need to put a # (hash or pound) in front of that field. That's it. We'll start the query like this in LogScale:

#event_simpleName=ProcessRollup2

The same concept applies to the field cid:

#event_simpleName=ProcessRollup2 #cid=123456789012345678901234

If you forget, or want to know what other events are tagged, you can just look in the LogScale sidebar for anything starting with #.

Hide Query

Show Query

#event_simpleName=ProcessRollup2 event_platform=Win
| ImageFileName=/\\powershell(_ise)?\.exe/i
| CommandLine=/\-(?<encodedFlagUsed>e(nc|ncodedcommand|ncoded)?)\s+/i
// | UserSid="S-1-5-18"
| groupBy(encodedFlagUsed, function=[count(aid, as=executionCount)], limit=100)

Hide Query

Show Query

#event_simpleName=ProcessRollup2
| table([#event_simpleName, #cid, @rawstring], limit=100)

Note in the output above I've trimmed the command line string using format to only include the first 50 characters to make things more readable. That line is as follows:

| format(%,.50s, field=CommandLine, as=CommandLine)

And now we have a complete query! If we wanted to do some visualization, we could change our parameters a bit to look for outliers: Based on this data, the use of the flags enc and encodedCommand (with that spelling) are not common in my environment. A hunting query, scheduled alert, or Custom IOA could be beneficial.

Falcon LogScale has the ability to apply tags to events. In doing so, it allows LogScale to quickly and efficiently include or exclude large collections of events as you search. The application of tags to telemetry is all done for you transparently when dealing with Falcon data. The reason we're mentioning it is: one very important field, event_simpleName, is tagged in LogScale. Because of this, when you specify an event_simpleName value in your LogScale syntax, you need to put a # (hash or pound) in front of that field. That's it. We'll start the query like this in LogScale:

#event_simpleName=ProcessRollup2

The same concept applies to the field cid:

#event_simpleName=ProcessRollup2 #cid=123456789012345678901234

If you forget, or want to know what other events are tagged, you can just look in the LogScale sidebar for anything starting with #.

Hide Query

Show Query

#event_simpleName=ProcessRollup2
| table([#event_simpleName, #cid, @rawstring], limit=100)

Falcon LogScale has the ability to apply tags to events. In doing so, it allows LogScale to quickly and efficiently include or exclude large collections of events as you search. The application of tags to telemetry is all done for you transparently when dealing with Falcon data. The reason we're mentioning it is: one very important field, event_simpleName, is tagged in LogScale. Because of this, when you specify an event_simpleName value in your LogScale syntax, you need to put a # (hash or pound) in front of that field. That's it. We'll start the query like this in LogScale:

#event_simpleName=ProcessRollup2

The same concept applies to the field cid:

#event_simpleName=ProcessRollup2 #cid=123456789012345678901234

If you forget, or want to know what other events are tagged, you can just look in the LogScale sidebar for anything starting with #.

Calculate the average password age, in days, of Admin and Standard user accounts and then round those values to a whole number:

#event_simpleName=UserLogon | groupBy(UserIsAdmin, function=(avg(PasswordLastSet, as=avgPswdAge)), limit=100) | AvgPaswdAgeDays := now() - (avgPswdAge*1000) | AvgPaswdAgeDays := AvgPaswdAgeDays/1000/60/60/24 | format(%,.0f,field=[AvgPaswdAgeDays], as=PasswordLastSetDaysRounded)

Hide Query

Show Query

#event_simpleName=UserLogon event_platform=Win LogonType="10"
| !cidr(RemoteAddressIP4, subnet=["224.0.0.0/4", "10.0.0.0/8", "172.16.0.0/12", "192.168.0.0/16", "127.0.0.0/32", "169.254.0.0/16", "0.0.0.0/32"])
| ipLocation(RemoteAddressIP4)
| worldMap(lat=RemoteAddressIP4.lat, lon=RemoteAddressIP4.lon, magnitude=count(RemoteAddressIP4))

Set a default field value. Similar to fillnull in Event Search. If the field GrandParentBaseFilename is blank, set it to the value "Unknown."

#event_simpleName=ProcessRollup2 | default(field=GrandParentBaseFileName, value=Unknown) | select([GrandParentBaseFileName, ParentBaseFileName, ImageFileName])

Hide Query

Show Query

#event_simpleName=ProcessRollup2
| default(field=GrandParentBaseFileName, value="Unknown")
| select([GrandParentBaseFileName, ParentBaseFileName, ImageFileName])

Omit internal IP addresses when keying in on remote IP addresses.

#event_simpleName=UserLogon  | !cidr(RemoteAddressIP4, subnet=[224.0.0.0/4, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 127.0.0.1/32, 169.254.0.0/16, 0.0.0.0/32])

Take the fields UID and UserSid and make them a new field named userIdentifier.

#event_simpleName=ProcessRollup2 | concat([UID, UserSid], as=userIdentifier) | select([@timestamp, aid, userIdentifier, ImageFileName])

Hide Query

Show Query

#event_simpleName=ProcessRollup2
| table([#event_simpleName, #cid, @rawstring], limit=100)

Query a single field for multiple values using the in function.

#event_simpleName=UserLogon | in(LogonType, values=[2,10]) | select([@timestmap, UserSid, UserName, LogonType, ClientComputerName])

Similar to where in Event Search, check one field value against another. In this example, see if a username has completed more than 25 logons in a given search window:

#event_simpleName=UserLogon | groupBy(UserName, function=(count(aid, as=totalLogons)), limit=100) | test(totalLogons > 25)

Hide Query

Show Query

#event_simpleName=UserLogon
| groupBy(UserIsAdmin, function=(avg(PasswordLastSet, as=avgPswdAge)), limit=100)
| AvgPaswdAgeDays := now() - (avgPswdAge*1000)
| AvgPaswdAgeDays := AvgPaswdAgeDays/1000/60/60/24
| format("%,.2f",field=["AvgPaswdAgeDays"], as="PasswordLastSetDaysRounded")

Hide Query

Show Query

#event_simpleName=UserLogon
| in(LogonType, values=["2","10"])
| select([@timestmap, UserSid, UserName, LogonType, ClientComputerName])
| ClientComputerName = *

Hide Query

Show Query

#event_simpleName=UserLogon
| groupBy(UserName, function=(count(aid, as=totalLogons)), limit=100)
| test(totalLogons > 25)

Hide Query

Show Query

#event_simpleName=UserLogon
| !cidr(RemoteAddressIP4, subnet=["224.0.0.0/4", "10.0.0.0/8", "172.16.0.0/12", "192.168.0.0/16", "127.0.0.1/32", "169.254.0.0/16", "0.0.0.0/32"])
| select([UserName, RemoteAddressIP4, ClientComputerName, @rawstring])
| sort(RemoteAddressIP4)

Create a process lineage one-liner that includes grandparent, parent, and target processes using format:

#event_simpleName=ProcessRollup2 | default(field=GrandParentBaseFileName, value=Unknown) | format(format=%s > %s > %s, field=[GrandParentBaseFileName,  ParentBaseFileName, FileName], as=processLineage) | select([aid, TargetProcessId, processLineage])

Hide Query

Show Query

#event_simpleName=UserLogonFailed2 event_platform=Win
| SubStatus_hex := format(field=SubStatus, "0x%X")
| select([@timestamp, aid, UserName, LogonType, SubStatus, SubStatus_hex])

Note that the specified lookup table must exist under "Files." In this instance, we'll check for common ports and create a new field with their associated protocol.

#event_simpleName=NetworkListenIP4 | match(file=crowdstrike/fltr-tutorial/service-names-port-numbers.csv, field=LocalPort, include=ServiceName, ignoreCase=true, strict=false) | select([@timestamp, aid, LocalPort, ServiceName, RemoteAddressIP4])

Hide Query

Show Query

#event_simpleName=ProcessRollup2
| concat([UID, UserSid], as="userIdentifier")
| select([@timestamp, aid, userIdentifier, ImageFileName])

Hide Query

Show Query

#event_simpleName=NetworkListenIP4
| match(file="crowdstrike/fltr-tutorial/service-names-port-numbers.csv", field=LocalPort, include=ServiceName, ignoreCase=true, strict=false)
| select([@timestamp, aid, LocalPort, ServiceName, RemoteAddressIP4])
| sort(ServiceName)

Hide Query

Show Query

#event_simpleName=ProcessRollup2
| default(field=GrandParentBaseFileName, value="Unknown")
| format(format="%s > %s > %s", field=[GrandParentBaseFileName,  ParentBaseFileName, FileName], as="processLineage")
| select([aid, TargetProcessId, processLineage])

Falcon LogScale has the ability to apply tags to events. In doing so, it allows LogScale to quickly and efficiently include or exclude large collections of events as you search. The application of tags to telemetry is all done for you transparently when dealing with Falcon data. The reason we're mentioning it is: one very important field, event_simpleName, is tagged in LogScale. Because of this, when you specify an event_simpleName value in your LogScale syntax, you need to put a # (hash or pound) in front of that field. That's it. We'll start the query like this in LogScale:

#event_simpleName=ProcessRollup2

The same concept applies to the field cid:

#event_simpleName=ProcessRollup2 #cid=123456789012345678901234

If you forget, or want to know what other events are tagged, you can just look in the LogScale sidebar for anything starting with #.