Hunting Filters¶

Default hunting filters¶

This section describes the guided threat hunting filters that are currently included in Clear NDR^®. These filters give security analysts a powerful tool to quickly review the vast evidentiary data store created by Clear NDR^® to proactively identify suspicious activity, hidden threats, shadow IT, and policy violations that their automated systems might miss.

Clear NDR^® is network-based threat detection and response (NDR) system that delivers:

Response-ready and high-fidelity threat detection from machine learning, behavioral anomaly algorithms, IOC matching, heuristics, and signatures
Open interfaces for simple integration with SOAR, SIEM, XDR, EDR, IR
Support for third-party and custom threat intelligence
Explainable and transparent results with evidence
Integrated guided threat hunting

Clear NDR^® automatically detects and identifies threats by monitoring on-prem and cloud-based networks, and presents security teams with complete contextual evidence for each threat, detailed incident timelines, and more.

Proactive Threat Hunting¶

Because many organizations have found proactive threat hunting to be an important part of their defenses, Clear NDR^® includes many features designed for threat hunters. Using Clear NDR’s Hunting and Investigation interface, security analysts can hunt for specific threat types, well-publicized threats, known Declarations of Compromise^® (DoCs), anomalous activity, suspicious behaviors, and more.

The Hunting and Investigation interface provides security analysts a powerful set of query tools to easily filter through the vast data store generated by Clear NDRProbes as they monitor network activity.

Hunting and Investigation uses a drill down approach, creating composite filters to uncover interesting events captured by Clear NDR^® Probes. The analyst applies additional filter criteria based on event metadata by simply clicking on the magnifier icons next to the field value.

Clear NDR^® Hunting and Investigation module includes six primary components that help hunters with various tasks:

Guided threat hunting filter sets
Context and classification
Previously unseen communications (Stamus Sightings)
Metadata search tools
Host Insights
Automation

Introduction to Guided Threat Hunting Filter Sets¶

Because defenders often need a place to begin their hunt, the Hunting and Investigation interface gives security practitioners over 120 ready-to-use guided threat hunting filter sets, including those which can identify unknown attack surfaces created by policy violations and shadow IT.

Note

Note: we may refer to these pre-defined filter sets or guided threat hunting filter sets depending upon the context. But rest assured, both terms are describing the same thing.

A filter set is basically a hunting idea or concept – translated into criteria based on the selection, negation, and wild carding of event metadata values – which results in a filtered query of Clear NDR^® data.

As of the U42 software release, there are over 120 pre-defined filter sets, accessible from the Enriched Hunting interface and organized around 11 categories. Thus it allows to zoom in for millions of events into a few that can help reveal low hanging fruit and provide better situational awareness with a click.

Adware - provides guided hunting to identify various potentially unwanted programs operating on the network.
Anomaly - provides guided hunting filters for listing Host Insights for assets using traditional services like TLS/SSH/HTTP but using non-traditional ports.
Compliance - provides guided hunting filters for listing out hosts with unusual encryption certificate usage.
Hunt - provides guided hunting filters for broad area of hunting ideas, such as obfuscated executables, suspicious zipped files transfers, suspicious payloads, successful scans, backdoors, exploits, coinminers, cryptominers, base64 functions detected in events and similar to name a few.
Info - provides guided hunting to identify certain groups of user agents operating on the network.
MITRE - provide guided hunting to identify events for which the MITRE technique is identified.
Phishing - provides guided hunting filters for potential successful phishing attempts.
Policy - provides guided hunting filters for potential organisational policy violations such as: older or vulnerable TLS encryption, Dynamic DNS, Abused file sharing, public DNS, possible TOR traffic, clear text passwords usage and more.
Roles - provides guided hunting filters for listing and getting automatic Host Insights critical infrastructure such as domain controllers, DHCP servers, proxies, printers and more.
Services - provides guided hunting filters for different network services observed to and from assets. For example: Apache, Microsoft IIS, Nginx servers detected. HTTP(S) proxy detection and others.
Trojan - provides guided hunting filters for Trojan and PUP (Potentially Unwanted Programs) events.

The filter-sets give defenders a very powerful hunting advantage because they can be used to display specific threat activity or policy violation on the network - from a specific detection event to a new proxy, printer, domain controller, or network service in the enterprise. For example, with just a single click, a security analyst can spot a new python-based web server in the marketing department.

Detailed use cases and examples of how to use the pre defined filter sets are available in our Threat Hunting blog series.

The combined power of the predefined filtersets with local organisational enrichment and knowledge also provides for a proactive approach to minimising the risk of malware and threat actors establishing a foothold.

For a complete list of the predefined filter set click here Complete List of Predefined Hunting Filter Sets

Selecting and Using the Filter Sets¶

The following screenshots illustrate the steps needed to select and use a predefined threat hunting filter set.

To take advantage of the predefined filter sets, the user should navigate to the Hunting and Investigation section on the user interface. See example below.

The Hunting and Investigation dashboard serves as the main launching point for the threat hunting tool. It includes over 50 elements of event metadata that can be viewed at a quick glance. It also allows the user to pivot and connect to the other hunting tools in the system.

From here you can select the timescale of the data in which you wish to hunt.

Next, open the Filter Sets window from the top menu bar.

With the filter set window open, select the filter you wish to apply. You may do this by searching for the filter set in the search bar at the top of the pop-up window or by scrolling until you find the filter you are looking for.

When you click on the filter in the pop-up window, the filter is applied to the data, and the criteria defined by the filter set appear in Clear NDR^® hunt dashboard’s active filters bar.

Once the filter set is applied, the security analyst may click on the magnifying glass icons beside the various data elements to further filter the data or they may click on the various data elements directly to pivot into a different view altogether. Often, the next step for the analyst is to review the various hosts identified by the filter to gain additional context. In the example below, the user has clicked on the “Hosts” item on the left hand navigation pane to pull up the listing of all hosts involved in this filtered activity.

User Defined Filters¶

Adding Filter Criteria¶

A security analyst may apply additional criteria to any of the predefined filters to advance their hunt. These criteria include IP address, specific network probe, message, not-in-message, port, method ID, ES filter, protocol, organization-specific network names, and more.

By simply clicking on the magnifier icons next to the metadata field value, a user may apply additional filter criteria to the data using various metadata fields in the events. Any field part of a filter set can further be edited and wild carded if needed.

Hunting Filers allow searching alert’s metadata in various ways such as searching for an IP address, a specific probe, a port number, a method SID, and more.

Some filters can be negated (NOT filter) and others support wildcard notation for pattern matching. See below.

Filter Type	Input	Negate	Wildcard	Description
IP	IP address	Yes	No	Filter on an IP address, source or destination
Probe	string	Yes	Yes	Filter on designated network probes
Message	string	No	No	Filter on a specific word
Not In Message	string	No	Yes	Exclude matching words from the results
Port	integer	Yes	No	Filter on a port number, source or destination
Method ID	string	Yes	No	Filter or exclude a specific method identifier
ES Filter	string	Yes	No	Filter with a custom boolean Elasticsearch filter
Protocol	string	Yes	Yes	Shortcut to access most common protocols and fields used for filtering
Network Def	string	Yes	Yes	Filter alerts from a specific organisation from Network Definitions (ex: Accounting)

IP Filter¶

The IP filter allows searching for an IP address regardless of whether this IP has been observed as the source or the destination of the communication.

Hint

The IP filter also allows typing a subnet such as IP: 10.7.0.0/24 to only get alerts from systems belonging to this subnet. This notation also applies to other IP fields such as src_ip or dest_ip

If you want to limit the results to either a source IP or a destination IP, there are multiple ways to achieve this goal. To illustrate this, let’s see how we can filter on the source IP 10.7.5.5.

Example 1¶

From the Dashboard page, locate the Organizational Information section and the card Attackers

If the desired IP is already listed in the TOP5, simply click on the “+” magnifier to add this source IP as a filter. Otherwise, click on the “3 vertical dots” in the card’s title to see the full list. Locate the desired IP and add it as a filter using the “+” magnifier.

Example 2¶

From the Events page, set an IP address filter on the desired IP such as IP: 10.7.5.5. As you will see in the results, this IP will appear as either the source or the destination of the communication. Scroll down the alerts list until you find an alert that matches your criteria (i.e. 10.7.5.5 as source IP in this example). Open the alert panel and under the block IP and basic information click on the “+” magnifier to add this source IP as a filter.

The Active Filters are now composed of the 2 filters IP: 10.7.5.5 AND src_ip: 10.7.5.5. At this point, you may decide to remove the IP filter to only have the src_ip filter depending on the search you are trying to build.

Example 3¶

Finally, another way to achieve this goal could be using ES Filters (see below for more details) by typing the expression src_ip: 10.7.5.5

ES Filters¶

Clear NDR^® Central Server relies on the ELK stack to allow searching alerts and their associated metadata. With Enriched Hunting, one can perform hunting activities and our software hides the complexity of ELK through the use of our interface that allows selecting desired fields and creating active filters without the need of understanding the underlying data structure nor the ELK search logic.

However, in some situations, relying on Elasticsearch Filters, or ES Filters, may come handy for advanced use cases.

Under The Hood¶

Under the hood, Clear NDR^® Central Server uses ELK to store and index the data it receives: alerts and protocol metadata. Each category of data has its own index, for example, alerts will be stored in logstash-alerts, DNS events will be stored into logstats-dns, HTTP events will be stored into logstats-http and so on.

ES Filters allows querying the logstats-alerts index to access alerts’ metadata such as source IP, destination IP, and protocol specific content such as HTTP User-Agent or Payload content for example. ES Filters queries ELK uses Apache Lucene as a query language and simply put, a search is a boolean expression composed of terms, and a term is a word or a pattern.

For example, to search for a source IP of value 10.1.2.3, one would write src_ip: 10.1.2.3. Here, src_ip is the term, followed by a colon and the searched value. The colon indicates an equality such as “src_ip is 10.1.2.3”.

As a search is a boolean expression, it is possible to use operators such as AND, OR, NOT, etc. For example, the query src_ip: 10.7.5.5 OR src_ip: 10.7.5.101 would list all alerts from either sources 10.7.5.101 and 10.7.5.5.

Important

ES Filters aren’t compatible with Hunting Policies as of U38.

Note

Kibana Query Language (KQL) was later introduced as an alternative to Apache Lucene and is currently not supported by Clear NDR^® Central Server.

Knowing the Fields to Use¶

When building a query, the first thing we need to know are the fields names available we can use. Simply put, any fields displayed in the Hunting interface can be used and to see the list of all the available fields, simply go under JSON View (Alerts tab).

{
    "flow_id":1587674205492238,
    "stream":1,
    "dest_port":443,
    "geoip":{
        "continent":{
            "code":"EU",
            "geoname_id":6255148,
            "name":"Europe",
        },
        "country_name":"Romania",
        "continent_code":"EU",
        "timezone":"Europe/Bucharest",
        "country":{
            "geoname_id":798549,
            "iso_code":"RO",
            "is_in_european_union":true,
            "name":"Romania",
        }
    },
    "@timestamp":"2021-12-08T04:31:06.157Z",
    "src_port":62227,
    "dest_ip":"-REDACTED-",
    "tls":{
        "ja3s":{
            "string":"769,49172,65281-11",
            "hash":"623de93db17d313345d7ea481e7443cf",
        },
        "fingerprint":"34:f0:60:57:ee:a1:ba:0e:cd:07:34:fb:78:90:e5:b5:4b:3f:89:dc",
        "version":"TLSv1",
    }
}

From the above snippet, we can see different field names we can use to write an ES Filter. Fields that are nested must be concatenated using a dot, for example, "tls": { "ja3s": { "string": "..." }} will be accessed with tls.ja3s.string.

Examples:

dest_port: [1024 TO 65535] will retrieve all alerts from which the destination port of the connection is between 1,024 and 65,535.
dest_port: 443 will retrieve all alerts from which the destination port is 443
geoip.country.iso_code: RO will retrieve all alerts associated to Romania
geoip.country.iso_code: R* will retrieve all alerts associated with any country having a country code starting with the letter “R” such as Romania (RO) or Russia (RU).
payload_printable: *COMCTL32* will retrieve all alerts having the substring COMCTL32 in the payload. This could be “COMCTL32”, “fooCOMCTL32”, “COMCTL32bar”, “fooCOMCTL32bar”, and so on
http.http_response_body_printable: *msdos* will retrieve alerts having the substring MSDOS in the HTTP Response Body
tls.version: tlsv1 will retrieve alerts where TLSv1 was used for SSL

Note

Pattern searches are case insensitive. Searching for geoip.country.iso_code: RO and geoip.country.iso_code: ro will lead to the same results. Fields name are however case sensitive and must be written in lowercase (SRC_IP is invalid for example, src_ip must be used)

Hint

Some of the above examples are really simple and one doesn’t necessarily need to write ES Filters because the web interface allows selecting most of those values in a single click from the alert’s panel

Attention

One of the common error when using wildcards is to have a space between the wildcard and the searched pattern such as payload_printable: * COMCTL32*. In that case, the search will literally return anything!

Note

Enriched Hunting provides FilterSets out of the box and some of them use ES Filters. Besides, some of them use the notation field.keyword: value. The operator “.keyword” from Elasticsearch perform search queries by explicitly stating that the field value shouldn’t be broken into tokens (e.g “New York” could match “New” or “York” otherwise)

Global Searches¶

In some situations, it can also be interesting to search for a pattern regardless of the field in which this pattern may be stored.

Note

Such a search may take a little longer as all fields need to be scanned so make sure to use specific patterns that won’t match on many things!

To search for the word “COMCTL32”, simply put “COMCTL32” in the ES Filter input without giving any field name.

Similarly, to search for a substring, use the wildcard notation, either at the beginning of the pattern or at the end of it, or both.

Finally, both fields searches and global searches can be mixed up to create more complex queries such as *Mozilla* AND NOT http.http_user_agent: *Mozilla* which will search for the substring Mozilla in any fields and will exclude all events having only a match on the HTTP User-Agent.

Specific Filters¶

Note

Any filter specified on those pages will not be carried to the other pages as they only apply on those specific pages. However, they are not removed and so when returning back the initial page, the filter will still be present.

Detection Methods¶

To scan and search the detection methods more easily, the page Detection Methods extend the default filters with the following ones.

Filter Type	Input	Negate	Wildcard	Description
Events min	integer	No	No	Filter detection methods that have at least the specified number of matches
Events max	integer	No	No	Filter detection methods that have at most the specified number of matches
Content	string	No	No	Filter detection methods having the specified substring
Not in Content	string	No	No	Exclude detection methods having the specified substring

Hint

The substring matching used in Content and Not In Content doesn’t require any special character such as a wildcard to match part of a word. For example, Content: CHA would match CHAT, Charset and so on. This is case insensitive.

Hosts vs Inventory¶

Hosts entries are categorized into two primary views in the Hosts and Inventory pages. These categories differentiate hosts based on their alert activity and overall presence in the network.

Hosts

Purpose: The Hosts view provides a focused look at hosts that have triggered alerts. This section highlights hosts that have generated security alerts or anomalies.
Visibility: Hosts appear in this view only when there is an active alert or issue associated with them. This allows security teams to prioritize attention on potentially compromised or high-risk hosts.
Use Case: Use Hosts to quickly respond to active threats, investigate alerts, and perform real-time monitoring of suspicious host activity.

Inventory

Purpose: The Inventory view serves as a complete list of all hosts observed by the system, regardless of whether they have triggered an alert.
Visibility: Every host that has been detected in the network is listed here, offering a comprehensive overview of network assets. This includes hosts that are currently idle or have not shown any unusual behavior.
Use Case: Use Inventory to gain a holistic view of all network assets, maintain an up-to-date catalog of known hosts, and track normal behavior even in the absence of alerts.

Hosts¶

To search the observed hosts in your environment more easily, the page Hosts extend the default filters with the following ones.

Filter Type	Input	Negate	Wildcard	Description
Hosts: HTTP User Agent	string	Yes	Yes	Filter hosts based on observed HTTP User Agents
Hosts: TLS JA3	string	Yes	Yes	Filter hosts based on observed JA3 fingerprints
Hosts: SSH Client Version	string	Yes	Yes	Filter hosts based on observed SSH Client version
Hosts: Username	string	Yes	Yes	Filter hosts based on observed Username
Hosts: Hostname	string	Yes	Yes	Filter hosts based on observed Hostname
Hosts: Services	string	Yes	Yes	Filter hosts based on observed Services
Hosts: Counts	integer	Yes	No	Filter hosts having at least/most the specified count of Services, Hostnames, TLS Agents, HTTP User-Agent, SSH Clients or Usernames

Hosts with services¶

Searching for all hosts that have certain services or protocols present, can be achieved on the Inventory page with the following filter from the filter drop down menu: Host filters -> Services.

Filter Type	Input	Negate	Wildcard	Description
IP protocol	string	Yes	Yes	Filter all hosts based on `IP protocol` e.g. UDP/TCP
Service port	integer	Yes	Yes	Filter all hosts based on `Service port` e.g. 443
App protocol	string	Yes	Yes	Filter all hosts based on `Application protocol` e.g. smb, http, tls
Https server	string	Yes	Yes	Filter all hosts based on the name of the `HTTP server`
SSH > Server version	string	Yes	Yes	Filter all hosts based on seen `SSH server version`
TLS > Fingerprint	string	Yes	Yes	Filter all hosts based on TLS protocol `fingerprint` information e.g. 6c:9c:65:0f:f8:d3:ff:6b:3d:3e:e7:7d:b8:12:a5:03:e0:2f:09:4c
TLS > Issuer DN	string	Yes	Yes	Filter all hosts based on TLS protocol `Issuer DN information` e.g. C=US, O=Google Trust Services LLC, CN=GTS CA 1C3
TLS > Subject DN	string	Yes	Yes	Filter all hosts based on TLS protocol `Subject DN` information e.g. CN=www.google.com

Hunt for hosts that have ssh service running not on the default port 22

In the example screenshot above it is shown how to hunt for ssh service that is not running ot its default port.

In another example screenshot above it is shown how we can discover certain usernames that have shown up on hosts in the network.

Creating Filter Sets¶

The Hunting interface allows you to create your own filter sets. You can choose between creating a Global Filter Set or a Private Filter Set

Creating Global Filter Sets¶

Global filter sets are usually shared between all authorized and authenticated users on your system. To create such a filter set, you first have to apply the filters you would like to use.

Next, you should click on Save Filter Set under Actions - on the right hand-side of the Hunting interface.

Fill in the Create new Filter Set form and select the Shared checkbox.

Creating Private Filter Sets¶

Private filter sets are available only to the user, who has created them. To create such a filter set, you first have to apply the filters you would like to use.

Next, you should click on Save Filter Set under Actions - on the right hand-side of the Hunting interface.

Fill in the Create new Filter Set form and leave the Shared checkbox unselected.

Loading Filter Sets¶

If you would like to load a filter set, you have to go to any page of the Hunting interface, then click on Load Filter Set from the Actions menu.

Then, you can use the search field to look for a specific filter set within the Global, Private and Stamus Predefined Filter Sets.

Exporting Filter Sets¶

If you would like to export your Global/Private filter sets, you can do this from our Administration interface.

You have to go to Rulesets page -> Import/Export Policies/Filtersets under Actions panel on the left hand-side of the page.

Note

The import/export format is json.

Deleting Filter Sets¶

In order to delete a custom created filter set, you need to click on Load Filter Set from the Actions menu.

Note

Only Global Filter Sets and Private Filter Sets can be deleted.

To delete a filter set - you have to click on the delete icon next to its name.

Complete List of Predefined Hunting Filter Sets¶

Adware Filter Sets (1)¶

This group of filter sets provide guided hunting to identify various potentially unwanted programs operating on the network.

Potentially Unwanted Program - Potentially unwanted program (PUP) detected. Usually indicative of policy violation on the network.

Anomaly Filter Sets (6)¶

This group of filter sets provide guided hunting to identify hosts using traditional services (such as TLS, SSH, HTTP, etc) on non-traditional ports.

HTTP services not running on port 80/8080 - This filter will highlight HTTP services running on a port that is not 80 or 880, the traditional HTTP ports.

Non HTTP services running on port 80 - This filter will display non-HTTP services running on port 80, which is traditionally an HTTP port by definition.

Non SSH services running on port 22 - This filter will display non-SSH services running on port 22, which is traditionally an SSH port by definition.

Non TLS services running on port 443 - This filter will display non-TLS services running on port 443, which is traditionally a TLS port by definition.

SSH services not running on port 22 - This filter will display SSH services running on a port that is not 22, the traditional SSH port.

TLS services not running on port 443 - This filter will display TLS services running on a port that is not 443, the traditional TLS port.

Compliance Filter Sets (1)¶

This group of filter sets provide guided hunting to identify hosts with unusual encryption certificate usage operating on the network.

Not common SSL certificate issuers - This filter displays results of network traffic analysis that have TLS services using uncommon SSL certificate issuers. Can be used to rapidly identify hosts using self-signed certificates on the network.

Hunt Filter Sets (71)¶

This group of filter sets provide guided hunting a broad array of hunting ideas based on metadata associated with events. These include obfuscated executables, suspicious zipped files transfers, suspicious payloads, successful scans, backdoors, exploits, crypto miners, base64 functions detected in events, and others.

HTTP obfuscated executable as Image content - This filter set can be used to uncover malware posing as images in HTTP content. In this case, the HTTP content presents itself as an image (with a png, gif, jpeg extension, for example), but the actual downloaded or transferred file is an executable.

Phishing events - This filter identified suspicious, likely, or successful phishing communication.

Suspicious DNS requests - This filter highlights DNS requests to suspicious or non-traditional domains.

Likely hostile domain events - This filter highlights DNS requests to likely hostile domains.

Malware family present in events - This filter highlights the events in which malware family is identified.

Exploit kit present - This filter highlights the events that use exploit kits.

Executable code present - This filter highlights the events that detect any executable code.

C2 domains detected - This filter highlights the events that C2/CnC domains detected.

Command and Control activity present (CnC) - This filter highlights the events associated with command and control activity (CnC).

Admin payload search - This filter highlights the events that include “Admin” or “Administrator” in their alert payload.

Backdoors and exploits for public facing web servers - This filter set returns a very potent information set of events that indicate either an ongoing backdoor or an exploit for public facing web servers or php based applications.

Coinminers - This filter highlights the events that are related to coin miners.

Crypto miners or Ransomware - This general wildcard filter highlights events of cryptominers or ransomware malware variants.

Current events - This filter highlights the events that trigger based on the CURRENT_EVENTS ET rules.

DNS over HTTPS - This filter returns all the events related to DNS over HTTPS usage transactions. It is important here to review providers that are highlighted. In many organizations, this may also be a policy violation.

DNS related events - This filter highlights all the events with DNS-related metadata.

DOS or Windows executable - This filter highlights all the events that are related to DOS or Windows executable HTTP transfers.

Executable related events - This filter highlights all the events related to executable files, including downloads, posts, and others. This usually provides interesting data that warrants further investigation.

Executable downloads from PowerShell - This filter highlights all the events that include executable-related transfers from PowerShell HTTP user agents.

Executable downloads from programmable software - This filter highlights all the events that include executable-related transfers from HTTP user agents that are common scripting languages.

HTTP Executable related events - This filter highlights all the events that take place via HTTP and are either posting or downloading executables.

HTTP POSTs - This filter highlights all the events that include HTTP POST requests. This type of request can hide malicious activity.

HTTP direct requests and replies to private IP - This filter highlights all the events that include HTTP requests and responses directly to an internal IP address - not a domain name. This activity may be suspicious because a domain name is typically part of the transaction when communicating with servers inside the network. While common in some development environments, it could also indicate lateral movement.

HTTP likely direct IPv6 communication - This filter highlights all the events detecting direct IPv6 communication and communication events likely using directly IPv6 HTTP hosts.

HTTP non-internal direct IP requests and replies - This filter highlights all the events that indicate HTTP requests and responses directly by IP - not using a domain name. This activity may be suspicious because a domain name is typically part of the transaction when communicating with servers outside the network (non private/internal IPs).

HTTP payloads containing admin - This filter highlights all the events that indicate HTTP payloads containing “admin”.

HTTP payloads containing root - This filter highlights all the events that indicate HTTP payloads containing “root”.

Hunting related events - This filter highlights all the events that are generated from rules with the “hunting” designation.

Hosts with more than one user - This filter highlights all the hosts that have more than one user. This typically generates a list of good candidates for investigation.

Hosts with suspicious http user agents - This filter highlights all hosts that have been seen using suspicious and non-traditional user agent strings. This typically generates a list of good candidates for investigation.

Low noise recently-created signatures - This filter returns very interesting low noise events created from signatures from 2020 onward.

Longer domain dns requests - This filter highlights all the DNS-related events with domains equal to or greater than 70 characters. The results can further be narrowed if needed by selecting or negating different TLDs from the interface. That gives a good first Hunting angle.

Low noise signature events - This filter highlights the events which have rarely triggered. These low noise alerts can sometimes hide valuable artifacts and discoveries.

Malicious filenames in payloads - This filter highlights the events whose payloads contain known malicious files or filenames.

Malware-related events - This filter highlights the malware-related events.

New executables seen - This filter highlights the events that are related to executables downloaded from new previously unseen locations.

Non common TLDs - This filter highlights the events which do NOT involve the most common top level domains. The resulting set can help focus the hunting activity related to http, dns, and uncommon events.

Non lib/open ssh clients - This filter highlights the SSH-related events that have no libssh or openssh client version.

Not common HTTP servers - This filter provides results for non Apache, Nginx, IIS HTTP servers. It would not be very usual to see some other HTTP servers on the network thus may be interesting to investigate.

One word HTTP user agents - This filter highlights one-word HTTP user agents.

Potential Bot HTTP user agents - This filter highlights user agents that may be potential bot crawlers.

Punycode domains present in DNS, TLS or HTTP - This filter highlights the events that have punycode names present in DNS, TLS, HTTP requests.

Recent malware or trojan - This filter highlights the malware- or trojan- related events.

Remote Administration Console OpenLocalMachine - This filter highlights the events that are related to remote administration console being accessed.

Remote Administration Registry HKEY_CLASSES_ROOT - This filter highlights the events that are related to remote administration registry being accessed.

Root payload search - This filter highlights the events containing “root” in the payloads.

Severity 1 events - This filter highlights the events classified as “Severity 1” by one of the rulesets.

Shell content http transfer - This filter highlights the events that identify HTTP shell files or script transfer.

Shorter domain DNS requests - This filter highlights the DNS-related events associated with shorter domain name lengths - 10 characters and below. The results may further be filtered if needed by selecting or negating specific TLDs from the interface.

Stamus flowbits metadata tags - This filter highlights the events flagged with any stamus flowbit(s).

Stamus critical lateral SMB, DCERPC - This filter highlights SMB critical changes events - deletion/additions/changes/resets/configurations/installations.

Stamus lateral SMB, DCERPC - This filter highlights SMB informational events.

Successful HTTP Scans - This filter highlights successful HTTP scans, potentially revealing the use of default passwords and credential logging.

Successful trojan/downloaders HTTP requests - This filter highlights the events containing trojan or downloader HTTP requests.

Suspicious HTTP User Agents - 1 - This filter highlights events that are using HTTP application layer protocol but with an user agent that includes specific characters not common to user agents.

Suspicious HTTP User Agents -2 -This filter highlights events that are using HTTP application layer protocol but with an user agent that is not common - aka not mozilla/firefox/opera/edge/wget and similar.

Suspicious filenames in payloads - This filer highlights events that identify suspicious filenames that are commonly used in malware. These may include variations of powershell/zip/post/get requests/cached browser data and many more.

TLS payloads containing root or admin - This filter highlights the events identifying “root” or “admin” in the TLS payload.

Trojan related events - This filter highlights the trojan-related events.

Unusual in length http user agents - This filter highlights the events containing HTTP user agents which contain fewer than 55 characters.

Windows binary executable - This filter highlights the events that identify transfers or downloads of Windows binary dll, com or bat files.

Zipped files in transfer - This filter highlights the HTTP-related events that identify zipped file name transfers.

Base64 decoding functions in payloads - This filter highlights the events that contain base64 decoding functions.

Base64 encoding functions - This filter highlights the events that contain base64 encoding functions.

Exploit signatures for encoded strings - This filter highlights the exploit signature-based events that have encoded execution strings values in the payload.

Hunting signatures for encoded strings - This filter highlights the hunting signature-based events that contain encoded strings values in the payloads.

Possible encoded shellcode strings - This filter highlights the events that have encoded shellcode string values in the payload.

URL Shortener services - This filter highlights events that are related to online URL shortening services.

Web client encoded values - This filter highlights the events that have encoded values in the client side HTTP URLs or payload.

Web server encoded values - This filter highlights the events that have encoded values in the server side HTTP URLs or payload.

Info Filter Sets (6)¶

This group of filter sets provide guided hunting to identify user agents operating on the network.

Curl HTTP User Agents - This informational filter highlights the HTTP-based events that contain Curl HTTP User Agents.

Java HTTP User Agents - This informational filter highlights the HTTP-based events that contain Curl Java User Agents.

Perl HTTP User Agents - This informational filter highlights the HTTP-based events that contain Perl HTTP User Agents.

Python HTTP User Agents - This informational filter highlights the HTTP-based events that contain Python HTTP User Agents.

Shockwave Flash HTTP User Agents - This informational filter highlights the HTTP-based events that contain Shockwave Flash HTTP User Agents.

Wget HTTP User Agents - This informational filter highlights the HTTP-based events that contain Wget HTTP User Agents.

MITRE Filter Sets (7)¶

This group of filter sets provide guided hunting to identify events for which the MITRE technique is identified.

Technique - Data Encrypted for Impact - This filter highlights the events for which the MITRE technique is identified as “Data Encrypted for Impact.”

Technique - Data Obfuscation - This filter highlights the events for which the MITRE technique is identified as “Data Obfuscation.”

Technique - Develop Capabilities - This filter highlights the events for which the MITRE technique is identified as “Develop Capabilities.”

Technique - Encrypted Channel - This filter highlights the events for which the MITRE technique is identified as “Encrypted Channel.”

Technique - Exfiltration Over C2 Channel - This filter highlights the DS events for which the MITRE technique is identified as “Exfiltration Over C2 Channel.”

Technique - Phishing - This filter highlights the events for which the MITRE technique is identified as “Phishing.”

Technique - Resource Hijacking - This filter highlights the events for which the MITRE technique is identified as “Resource Hijacking”

Phishing Filter Sets (2)¶

This group of filter sets provide guided hunting to identify potential successful phishing attempts taking place on the network.

HTTP status code 200 detection - This filter highlights successful (status code 200) HTTP related events that may be identified with possible attempts of phishing and policy violations.

Phishing general detection - This filter highlights events that contain the keyword “phishing,” identifying all activity that may be considered possible phishing attempts.

Policy Filter Sets (17)¶

This group of filter sets provide guided hunting to identify potential organizational policy violations such as the use of older or vulnerable TLS encryption, Dynamic DNS, TOR traffic, clear text passwords and more operating on the network.

Abused file sharing hosting - This filter highlights the use of commonly abused file sharing services and providers.

CVE Detection - 2020 onward - This filter highlights events associated with more recently identified vulnerabilities (CVE issued from 2020 onward).

CVE global detection - This filter highlights events associated with publicly-identified vulnerabilities (CVE issued).

Clear text password - 1 - This filter highlights events associated with clear text passwords.

Clear text password - 2 - This filter highlights events associated with unencrypted passwords.

Dynamic DNS requests - 1 - This filter highlights Dynamic DNS events usage (group 1).

Dynamic DNS requests - 2 - This filter highlights Dynamic DNS events usage (group 2).

External IP checking - This filter highlights events associated with IP check or lookup.

FTP application used - This filter highlights hosts having deployed FTP applications and usage.

FTP clear text alerts and sightings - This filter highlights FTP events.

FTP network services - This filter highlights hosts with deployed network service of FTP as a service to other hosts.

Old TLS versions - This filter highlights events that identify the use of TLS encryption versions prior to version 1.2.

Outdated software - This filter highlights outdated or old software that should be upgraded or patched.

Possible TOR traffic - This filter highlights TOR traffic-specific events that may constitute an organizational policy violation.

Public DNS queries - This filter highlights queries to public DNS infrastructure.

SMTP clear text events - This filter highlights clear text SMTP events.

Vulnerable software - This filter highlights known-vulnerable software that should be upgraded or patched.

Roles Filter Sets (4)¶

This group of filter sets provide guided hunting to identify hosts functioning in critical roles, such as domain controllers, DHCP servers, proxies, printers, and more on the network.

Detected printers and printer services - This filter highlights printers and printer services detected in the network.

Detected DHCP servers and services - This filter highlights DHCP servers and services detected in the network.

Detected Domain Controllers and DC services - This filter highlights domain controllers and DC services detected in the network.

Detected HTTP(S) Proxies and HTTP(S) proxy services - This filter highlights HTTP(S) Proxies and HTTP(S) proxy services detected in the network.

Services Filter Sets (7)¶

This group of filter sets provide guided hunting to identify specific network services observed in communications between network assets. These include Apache, Microsoft IIS, Nginx servers, HTTP(S) proxies, and others operating on the network.

Apache HTTP servers - This filter highlights Apache HTTP servers found in the network.

COMODO issued certificates - This filter highlights COMODO-issued certificates in use in the network.

Let’s Encrypt issued certificates - This filter highlights Lets Encrypt-issued certificates used in the network.

Microsoft IIS HTTP servers - This filter highlights Microsoft IIS HTTP servers found on the network.

Nginx HTTP servers - This filter highlights Nginx HTTP servers found on the network.

HTTP proxies in the environment - This filter highlights non-signature events that identify HTTP proxies operating in the network.

HTTPS proxies in the environment - This filter highlights non-signature events that identify HTTPS proxies operating in the network.

Trojan Filter Sets (1)¶

PUP resulting in Trojan activity - This filterset highlights events related Trojan related activity in related to potentially unwanted programs.

After the Initial Hunt¶

The guided hunting filters are designed to help an analyst identify unwanted activity or potentially dangerous threats on their organization’s network. Locating the suspicious activity is just the first step.

Once a potential threat has been identified, the user may apply other automations and escalations that can help streamline an organization’s threat detection. To learn more about what to do after the hunt, read our article on automation and escalation with the Stamus Enriched Hunting interface. The article may be found here.