Threat Intelligence: How Indicator Alerts Work

UTMStack v12 checks your events against threat intelligence lists from ThreatWinds and raises an alert when an event involves a known malicious IP address, domain or host name. This page explains what is checked, when a match becomes an alert, how to switch matching and sharing on or off, and exactly what your server sends to ThreatWinds.

ThreatWinds is the threat intelligence service that UTMStack uses for its feeds, its Threat Intelligence screens and its default AI provider.

How matching works

The event processor (the part of UTMStack that parses events and runs rules) downloads three lists from ThreatWinds: malicious IP addresses, domains and host names. Each list comes in three levels, Level 1 to Level 3; the higher the level, the more serious the indicator. If a value is on several levels, the highest level counts.

The lists are kept on your server and checked there. Your events are not sent anywhere for this check.

• The event processor downloads the lists when it starts, and again when they are 12 hours old or empty. It checks this every minute.

• Before downloading, it tests the connection for 10 seconds. If ThreatWinds cannot be reached, it skips that update and tries again later.

What is checked

Every event, from every data source and every tenant, is checked after it has been parsed. UTMStack looks at six fields of the standard event:

A data source only takes part if its pipeline fills in these fields.

These values are never checked:

• Loopback, private and unspecified IP addresses (for example 127.0.0.1, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 and IPv6 unique-local addresses).

• The name localhost and names ending in .local.

A value matches only when it is exactly the same text as the list entry. Letter case counts, and a sub-domain does not match a listed parent domain: if example.org is listed, www.example.org does not match.

When a match is ignored

UTMStack skips an event whose outcome field actionResult is denied, blocked or failed, for example a firewall that refused the connection. Every other event is checked, including events that have no outcome.

The alerts it raises

Each matching value raises its own alert, so one event can raise up to six alerts.

Repeats are dropped for 7 days: a new alert is not stored when an alert with the same name, the same adversary and target addresses, host names and domains, and the same data source was raised in the last 7 days. These alerts are not grouped into echoes.

Indicator alerts appear on Threat Management > Alerts like any other alert. Tagging rules apply to them, so you can close a known false positive with a tagging rule on, for example, Alert name and Adversary IP. See Tagging Rules and False Positives.

Good to know:

• Indicator matching is not a correlation rule. It does not appear on Configure > Alerting Rules, and the rule flood guard does not switch it off.

• The Test function for rules does not run threat intelligence, so it never shows indicator alerts.

Turn matching and sharing on or off

Go to Configure > Settings > ThreatWinds Integration. The page is shown only to the instance operator (an administrator of the default tenant). It has two switches:

• Both switches apply to the whole server, for every tenant.

• To change them you need the Administrator role in the default tenant.

• Upgrades keep the values you set.

What is sent to ThreatWinds

Everything except the list download goes through the UTMStack update server (cm.utmstack.com), which forwards it to ThreatWinds with your server's registration.

What Contribute incidents sends

While Contribute incidents is on, every 5 minutes UTMStack:

1. Reads every incident with the status Open or In review, in every tenant on the server.

2. Reads the alerts linked to each incident, and the events stored on those alerts.

3. From the origin and target side of each event, takes the values that ThreatWinds can store as indicators, such as IP addresses, ports, host names, domains, URLs, file names and paths, file hashes, email addresses and subjects, user names, MAC addresses, processes and certificate or SSH fingerprints.

4. Sends them to ThreatWinds together with the links between them.

Network access and registration

• To download the lists, the server needs outbound HTTPS (port 443) to apis.threatwinds.com.

• The Threat Intelligence screens and Contribute incidents need outbound HTTPS to cm.utmstack.com, and a server that registered itself there during installation. Without the registration, the screens show Threat Intelligence isn't configured.

• On a server without internet access no lists are downloaded, so no indicator alerts are raised.

See Network Ports and Firewall.

Who can use threat intelligence

Investigate an indicator alert

1. 1

   See which value matched

   Open the alert on Threat Management > Alerts. The Description names the value and its level, for example "The IP '203.0.113.45' was found in ThreatWinds intelligence feeds (Level 3)." The Parties tab shows it on the Adversary card; the other side of the event is on the Source / target card.

2. 2

   Check the direction

   Decide which way the traffic went:

   • Your system reached out to the listed value (for example a workstation connecting to a listed domain): the more serious case. The machine may be infected or a user may have opened a malicious link.

   • The listed value reached your system (for example a scanner probing your firewall): common on internet-facing devices, and usually blocked. Check that the event's outcome was not a success.

3. 3

   Read the event

   On the Events tab, expand the event and read its fields and original log line: which data source logged it, which port, which user, which action. Click View all related logs for the other events behind the alert.

4. 4

   Learn about the indicator

   Go to Threat Intelligence > Indicators, set the lookup type to the kind of value (for example ip), paste it and press Enter. Its details show the reputation, the tags, when ThreatWinds last saw it and what it is linked to.

5. 5

   Decide

   • Real contact with a malicious host: open an incident, contain the machine and follow Alert Triage Workflow.

   • Blocked probe or known harmless match: complete the alert. If such matches keep coming, add a tagging rule on Alert name and the specific Adversary IP or Adversary domain that adds False positive. See Tagging Rules and False Positives.

Troubleshooting