Threat Reports

The Threat Reports page in the left navigation is where you work with the intelligence Stairwell is matching against your files: the reports available to you, which ones have matched something of yours, and what exactly matched. If you want the concept first, read What Is a Threat Report? and come back here for the working surface.

Matching is continuous and runs in both directions in time. A report loaded today is checked against the files you already collected, and it keeps checking everything that arrives afterward, without anyone reopening it.

What is on the Threat Reports page?

A list of reports, in a row layout or a grid layout, toggled from the control at the top right. Each entry carries the report's name, its source, when it was published, how many indicators it holds, and how many files in your environments it has matched.

Two other controls sit in the same bar and are easy to miss:

• Generate summary produces a document summarizing the reports matching your current filters and their impact on the environments you select. Use it when somebody needs the week's exposure in prose rather than a list.
• View summaries lists the summaries already generated, so you are not regenerating one somebody made this morning.

How do I find the report I want?

Filter, rather than scrolling. The filter bar narrows a long list to the handful that matter right now.

• Report name, a keyword against the title.
• Release range, a date window over publication.
• With matches only, which is the filter to start from during an incident, because it collapses the list to reports that have actually touched your environment.
• With IOCs only, which drops reports that carry narrative but no indicators.
• Source, the origin of the report: Stairwell's own research, a vendor, or your own team.

Combine them. "With matches only" plus a release range over the last fortnight is a reasonable standing view for a morning check.

What is in a report?

Open one and the panel has up to five tabs.

• Summary, the report's own description, its source, its publication date, and a link to the original where there is one.
• Matches [n], the files in your environments associated with this report, and the indicator that connected each one. This is the tab to read first, and the count is the number in the list.
• IOCs [n], every indicator the report carries, split by hashes, hostnames, and IP addresses. This is also where you silence a noisy indicator or add one of your own.
• Variants [n], files that resemble the report's matches. These are the files the report did not list, which is frequently where the useful part is. See Variants.
• YARA [n], the rules the report carries, when it carries any.

What counts as a match, and what does not?

A match is a file in your environment associated with one of the report's indicators: a hash, a hostname, an IP address, or a YARA rule. Three properties of that definition change how you should read a count.

Read the linking indicator, not the number. The Matches tab tells you which indicator connected each file, and the strength varies enormously. A hash link says the report is about this exact build. An IP address link may say only that your file references infrastructure that ten thousand unrelated things also use. Two matches of different kinds are not two of the same thing.

Filenames are not indicators. A report can carry filenames, and Stairwell does not match your files against them. It used to, and the practice was deliberately ended because it produced phantom matches: in the case that settled it, a report showed seven matches in a customer environment while none of the report's hashes matched anything there at all. All seven were files that shared a filename with the report, both filenames belonged to legitimate libraries the malware in question impersonated, and two of the seven were first seen years before the campaign existed. A filename is chosen by an attacker precisely because it looks innocent, so it is not evidence and it is not treated as evidence.

Your own conclusions are respected. Files your team marked Trusted or Benign are left out of the count, though they stay visible in the results list so you can see what was excluded. Known-noisy infrastructure such as content delivery networks and public resolvers is suppressed up front, so subscribing to a report about a campaign that used a popular hosting provider does not bury you in matches on that provider.

Does a report match mean I am compromised?

No. It means a file of yours is associated with something described in intelligence, which is the beginning of an investigation rather than its conclusion.

The most common benign explanation is that a campaign used a tool you also use, legitimately. The second most common is a weak indicator: shared hosting, a public resolver, a widely used library. Work the file rather than the alert: check prevalence, read the sightings for where and when it arrived, and read the automated verdict. The Alert Is a Legitimate IT Tool is the full sequence for the case that turns out to be your own software.

How do I get told about matches?

Configure a trigger with the threat report indicator match condition, and route it to email, a webhook, or the API. See Event Notifications.

Two things about report notifications specifically. A report published today can link to a file that arrived on your fleet last year, so read the sightings before treating the notification as news. And when the noise from one indicator gets in the way, silence that indicator rather than unsubscribing from the report. See Trigger Silences.

What should I read next?

• Work with Threat Reports, for uploading, creating, and editing them.
• Share Threat Reports, for getting a report into another environment.
• New IOCs Were Published, the playbook for the morning after a report lands.