The first search is the only true full-text search, as there are no syntactical elements to declare a specific field to be searched. This search will search all fields for the term mimikatz, and will match substrings (i.e. the search has an implied glob operation, meaning it will match wherever the string occurs). This search will search all field values that match the supplied term, including those derived from parsing operations.

The second search is identical, but introduces language elements in the form of the wildcard "glob" characters (*). As noted above, this search is identical to the first, and will include matches from all fields.

The third search limits the search to the raw event field (@rawstring), and therefore excludes matches with any additional (derived or sent) metadata fields. For this third search, the glob characters are required, and cannot be implied as in the first search. If you omit them, it will search only for the full string mimikatz, which cannot be part of a substring. You see about a 17% improvement in speed due to the fact that not all fields are being searched. For most users, this 17% improvement is not worth giving up the ability to quickly type simple term searches into the search bar, and indeed "true FTS" will have minimal detrimental effect for most use cases.

In the fourth search, the slash (/) characters introduce additional language syntax in the form of regex string delimiters. The fourth search is similar in thought to the first one, and is hence referred to as a "Free Regex" search. Though more flexible than simple glob patterns, regex processing without a field declaration searches all parsed fields including the original @rawstring, and is a far more complex operation for any search engine to perform; the extra overhead required to search all fields can be considerable. This can be seen in the Work Value of the fourth search, which is roughly 5.5 times slower than that of the fifth rawstring-specific one. Therefore, for "field-rich" sources such as Falcon Telemetry, it is essential to consider which fields you wish to include in the search when using regex, or better yet revert to glob patterns if those will suit your needs.

In the fifth search, the regex query is performed only against the @rawstring field, but not any of the parsed or declared fields. This is slower than a string search, but faster than searching every field.

Use Free Term search only for simple full strings or substrings. Performance impact will be minimal, even over long timeframes.

Always use glob (wildcard) patterns rather than regex if that will meet your needs. There is far less overhead, even when using simple regex patterns as in the searches above. In other words, the fourth and fifth regex-based searches are not examples of good search hygiene as the search parameter is just a string and could be complete.

If using a FTS in the collection portion of a larger, more complex, or saved search, consider using field restrictions even with simple terms (the 3rd and 5th examples above).

"Free Regex" searches are in general not recommended (unless the dataset you are searching against does not contain @rawstring). Running these against field-rich datasets, such as Falcon Telemetry, will be noticeably slower than field-restricted searches.