New IOCs Were Published

A vendor published a report this morning. Forty hashes, a dozen domains, a couple of addresses, and eleven pages of prose. Someone needs to know by lunchtime whether any of it has been in your environment, and the honest version of that answer has to cover more than the last thirty days.

The slow version of this task is familiar: copy the hashes into one console, the domains into another, get "no results" from tools whose memory ends before the campaign started, and report that you are not affected when what you established is that you are not affected inside the windows your tools still remember. Then do it again next week in case something arrives late, which nobody does, because it is nobody's job twice.

Easy Mode: every hash in the report that matched your environment is a seed. Let Backstory investigate it and read the report it returns. A published match is the case Backstory is best at: the file is known bad, and how far it got in your fleet is entirely unknown.

What will I know by the end?

Whether any indicator in the report has been in your environment at any point Stairwell has been collecting, which machines and on what dates, which related files the report's author never listed, and a subscription that keeps checking without anyone reopening the PDF.

Why this works

Three ideas carry this one, and the first is what makes the honest answer different from the fast one.

The sweep reaches backwards. Stairwell holds the files, so this morning's indicator list runs against what your fleet held last spring. Reporting "no results" from tools whose memory ends before the campaign started is not the same claim, and the difference is the whole reason this playbook exists.

An indicator list is a floor, not a ceiling. A report covers the samples its author could account for, and reports go to press on whatever somebody happened to collect. Adversaries recompile between campaigns, so the file in your fleet is frequently a cousin of the one in the report rather than the one in the report. That is Step 5, and skipping it is how a sweep comes back clean while the family is present.

Not all matches are the same strength. A hash link is a statement about one exact build. An address link may be a statement about shared hosting. Reading which indicator linked a match, before reading the match itself, is what keeps this from becoming an afternoon on a parking service.

If you want the instruments themselves rather than this scenario, Investigate & Hunt covers each one on its own.

Step 1: Paste the whole report into the search bar

All of it. Select the page, copy, paste, press Enter.

Stairwell reads the text and pulls out the hashes, hostnames, and addresses, including defanged forms such as hxxp:// and example[.]com, and searches for all of them at once. An eighty-indicator report becomes one paste. See Hunting and Search.

Do this before anything else, because it takes fifteen seconds and it decides how the rest of your morning goes.

Step 2: Read the tabs as four different answers

The results come back grouped by entity, and the grouping is the finding.

The first two are the pair that matters. A hash present globally and absent from your fleet is intelligence you can act on calmly. A hash present in your fleet is the one that changes your day. And a hash in neither is worth a second look at your environment scope before you write it off, since everything you search is limited to the environments you can read.

If exactly one thing matches, Stairwell opens it directly rather than showing you a list of one.

Step 3: Import the report, do not only search it

A search answers today. A threat report keeps answering.

Bring the indicators in as a report and subscribe the environments that should be covered. Stairwell then matches those indicators against the files you already hold and against everything that arrives afterward, and records which indicator linked each match. Two consequences worth having.

Backward in time. A report published this morning can tell you about a file that has been sitting on three of your servers since last spring, with the assets and the paths attached. That is the half of the answer your endpoint tooling and your proxy logs cannot give you, and it is the reason this playbook exists at all.

Forward in time. The same list keeps working next month. When the vendor publishes a second wave of indicators, you extend the report rather than starting over.

Two properties of matching to know before you read a match count. Files your team has marked Trusted or Benign are left out of the count, though they still appear in the list, so your own tooling does not inflate every report. And filenames are not treated as indicators, because a filename is something an attacker chooses precisely because it looks innocent.

Step 4: Triage the matches by what linked them

Not all matches are the same strength, and the linking indicator tells you which kind you have.

• A hash match is the strongest statement available. The exact file was here.
• A YARA rule match is close behind and often better, because it catches the family rather than the sample. It is still evidence rather than a verdict. See What is a YARA rule?.
• A hostname match means a file in your environment references that name. Read how many files reference it before you weight it.
• An address match is the weakest and the most likely to be noise, especially if the address answers for a large number of unrelated names.

Then use prevalence as a check. A match on a file present in most environments on the platform deserves a second look before it becomes an incident, because broad rules and reused indicators find popular software. A match on a file two of your machines have and nobody else does is the opposite, and it goes to the front of the queue.

Step 5: Find what the report did not list

The report's indicator list is the subset its author could account for. It is never the whole story, and this is the step that separates a sweep from an answer.

For any hash that came back present, open its Variants. Variant Discovery compares across the entire corpus, both your own private files and the global malware corpus, so what comes back is the family: the sibling builds, the repacks, the earlier versions, and the second stages, ranked, each with its own verdict and rarity. Adversaries recompile between campaigns and reports go to press on the samples someone happened to collect, which is why the file in your fleet is frequently a cousin of the one in the report rather than the one in the report.

Variant Discovery also runs automatically for threat reports, so an imported report's results include related files nobody typed into it.

Take the interesting cluster members back to their sightings and you have the exposure answer for the family instead of for the list.

Step 6: Work the infrastructure half

The domains in the report are not a lesser class of indicator, they are a different pivot, and the report almost certainly under-lists them.

Open a hostname and read its resolution history: every address it has answered with, when each answer was first and last seen, and which are no longer active. Those historical addresses are indicators the report did not print. Then reverse each one and see what else resolved there, weighting the result by how crowded the address is, since a name parked alongside ten thousand others is shared hosting rather than a campaign.

The route back into your environment is the file list on the hostname panel, which is what makes this more than reputation lookup. See Network Intelligence, and Someone Reported a Suspicious Domain for the full sequence.

Step 7: Scope anything that was present

For every hash that was actually in your fleet, run Run-to-Ground from it.

The report tells you a file is interesting. Run-to-Ground tells you what else landed on the same machines around the same time and is rare across your fleet, which is where the parts of the campaign that nobody wrote up come from. Right-click the hash, and under Workflows choose Run to ground. You can select up to five hashes and sweep them together.

Then run it again on what it finds. Every component it surfaces is a new starting hash, and each run anchors its window to when that file landed on that machine, so a stage that arrived weeks before the indicator you started from opens a window weeks earlier. Keep going until a pass yields nothing new.

That recursion is what closes the gap between the report's timeline and yours. A published report dates the campaign from when its author saw it; your first arrival is a separate fact, and it is the one your incident record needs.

Add each new component to your own report as you go, so the coverage grows while you work rather than at the end.

What if a match is a false positive?

Published indicator lists contain mistakes. An address that turns out to be shared hosting, a hash of a legitimate installer, a hostname belonging to a vendor half your industry uses: any of them will match things in your fleet that have nothing to do with the campaign.

Step 4's ordering usually catches these, because a match linked by a weak indicator on a file that is common across your estate and first seen years before the campaign is almost always coincidence. When you have established that, silence the indicator: right-click it on the report's Summary or IOCs tab and choose Silence hash, Silence hostname, or Silence IP. That removes it from matching for the environment you choose, it takes a comment, and it can be undone. See Work With Threat Reports.

Silence the indicator, not the report. Unsubscribing costs you every other indicator in it, including the ones this campaign has not published yet.

If the indicator is wrong for everyone rather than only for you, tell [email protected], who can silence or remove it from the report itself. Send the report name, the indicator, and an example of what it matched with a sentence on why the match is wrong.

Let Backstory run it

A confirmed match to published intelligence is the clearest case for Backstory on this site. Somebody else has already done the work of establishing that the file is bad, so the only open question is how far it got in your fleet, and that is the question Backstory exists to answer.

Give it a matched hash and it establishes what the file is, expands across variants, runs Run-to-Ground, and runs Run-to-Ground again on what that surfaces, pulling in sightings, prevalence, resolution history and published intelligence as it goes. It returns a report rather than a dashboard. See Starting an Investigation.

That recursion is the part worth having here. A published report describes what its author saw, which is rarely the whole campaign and never your copy of it. Following each new component back to what arrived alongside it is how the local shape of the intrusion turns up, and it is the step an analyst working by hand abandons first.

Seed it with the matched hash. If the report gave you a domain or an address that resolved to something in your environment, those work as seeds too.

It does not write the threat report. Step 3 already imported the published one, and Step 8 is where your own goes. Backstory does the investigating, not the recording.

Step 8: Turn the morning's work into standing coverage

1. Record your conclusions. Set opinions with comments on what you triaged, in both directions. The next analyst inherits the reasoning.
2. Extend the report with what you established. The variants you confirmed, the historical addresses you found, the hostnames you judged. Your indicators then match on the same terms the vendor's did.
3. Configure a trigger so a match that arrives at 3am on a Sunday reaches somebody by email or webhook.
4. Silence precisely, never broadly. When an indicator matches legitimate software in your environment, mark that file safe or silence the indicator for that report. Do not unsubscribe from the report to make the noise stop.

What if nothing matched?

Then write that down properly, because it is a stronger statement than the one most teams get to make. Nothing in the report has been in your environment at any point Stairwell has been collecting, not merely inside a telemetry window, and the subscription keeps checking from here. That is a finding, it is defensible, and it took a morning.

Note the two caveats honestly. The answer covers the environments you can read and the machines that are actually reporting, so check the Assets screen for coverage gaps. And it covers the file types Stairwell collects, roughly 65 executable and script formats by default and tunable by your team.

What should I read next?

• An EDR Alert Just Fired, for the full sequence once one of these indicators turns out to be present.
• Someone Reported a Suspicious Domain, for the infrastructure half in depth.
• What is a threat report?, for how matching, counts, and subscriptions behave.