Is This File Anywhere Else?
Four different questions hide inside that one. How to answer each with prevalence, sightings, variants, and Run-to-Ground, and what each answer changes.
You have a file. It came out of an alert, or a colleague sent it to you, or you tripped over it while looking at something else. The question you need answered is the oldest one in security and the one normal tooling is worst at: is this anywhere else.
Four different questions hide inside that sentence, and they have four different answers. Asking the wrong one is how an investigation ends early.
| The question you mean | What answers it |
|---|---|
| Is this exact file on other machines of mine, now or ever? | Sightings and local prevalence |
| Does anyone outside my organization have it? | Global prevalence, and the Global Objects tab |
| Is anything like it anywhere, here or outside? | Variants |
| What else arrived with it? | Run-to-Ground |
What will I know by the end?
All four answers for one file, in the order that makes each one cheap, and what each of them changes about whether the file is worth more of your time.
Step 1: Read both prevalence figures together
Open the file and read prevalence before anything else on the panel. Stairwell reports it from two directions: locally, meaning the share of your own assets that have seen the file, and globally, meaning how widely it appears across the environments Stairwell observes.
Neither number means much alone. The pair is diagnostic.
| Local | Global | What you are usually looking at |
|---|---|---|
| Rare | Absent | Bespoke tooling. Either your own build or something written for you, and this is where targeted attacks have to live |
| Common | Absent | Software built for your organization. Your own IT team's, or an intrusion that already spread |
| Rare | Common | Commodity. Widely known software or widely distributed malware that has reached a couple of your machines |
| Common | Common | Infrastructure. Operating system components, agents, browsers |
Two honest limits, because prevalence is the most over-read signal in the product. Rare does not mean malicious: a freshly compiled internal tool and a developer's test binary are both rare and both fine. Common does not mean safe: widely deployed software is exactly what an attacker wants to compromise or impersonate. Prevalence tells you where to spend attention, not what a file is. That is what a verdict is for.
Step 2: Get the exact answer from sightings
Prevalence is the summary. The Sightings tab is the detail, and the detail is what you put in a ticket.
For every machine that has reported the file you get the asset, the path, the filename it used there, the origin, when it first arrived on that machine, and when it was last seen. Three habits make this step pay.
Sort by first seen. The earliest sighting is your patient-zero candidate, and it is frequently much earlier than whatever brought you here. That date reframes the whole investigation.
Read the filenames, do not search by them. The name and the path live on the sighting rather than on the file, because the same bytes are called different things in different places. That is why a hunt written against a filename goes quiet while the file itself is untouched. Search the file, then take the names off its sightings to your other tools.
Count carefully. A file's sighting count is not its asset count. One machine can produce several sightings of the same file at different paths and times, so the two numbers are shown separately.
Two more things this tab gives you that are easy to miss. A sighting marks a file that arrived as a web download, and it names the parent object when the file was unpacked out of something else, which is often how you find the dropper rather than only the payload. And files that arrived by upload rather than from a machine belong to an environment with no path or filename to record, because no machine reported them.
Before you tell anyone the file is gone, compare its last seen against the asset's last check-in. One says when the machine last had something to report, the other says when it last spoke.
Step 3: Ask whether the world has it
Switch to the Global Objects tab. It answers a question your own environment cannot: does Stairwell know this file at all.
This is the cheapest sanity check available on an unknown binary. Present globally and rare locally usually means commodity software or commodity malware, and there may already be a verdict, labels, and threat report matches attached that you get for free. Absent globally and present locally is the combination that deserves your afternoon.
Step 4: Stop asking about bytes
Here is where the question changes, and it is the most important step on this page.
Everything above asks about the exact file. An exact hash stops matching the moment somebody recompiles, repacks, or pads it, which costs an adversary minutes and costs you the lead. So "is this anywhere else" asked about bytes has a much smaller answer than the same question asked about the thing the bytes implement.
Open the Variants tab. Variant Discovery finds the files that resemble this one and ranks them by how confidently they belong together, and it looks across the entire corpus: both your own private files and the global malware corpus.
That second half is not a bigger haystack. It is what lets two of your own files be connected through the outside world, and the chain is worth walking through once:
- A file A sits in your environment.
- A resembles a file in the global malware corpus.
- That outside file has its own relatives there: earlier builds, repacks, the rest of its family.
- One of those relatives leads back to a distant file B, on a different machine inside your own environment.
Compare A and B directly and they do not resemble each other closely enough to connect. Searching only your own files would never have linked them. The global corpus is the bridge between two of your own files, which is why the honest answer to "is this anywhere else in my fleet" often requires looking outside your fleet.
Read the list by sorting it. It sorts by Similarity, Prevalence, Maliciousness, and First seen. The rare members with a bad verdict are where to start; the common ones are usually shared libraries and packers. If any member already carries an opinion your team recorded, that judgment is on the row, and it frequently settles the file in front of you in seconds.
One thing to know about when this runs. Variant Discovery runs automatically for threat reports and Backstory investigations, and on demand when you ask for it here or through the API. It is a lens you point at a file, not a field stamped on every file at collection time.
Step 5: Take the cluster back to sightings
This is the step that completes the answer, and almost nobody does it unprompted.
You now have a cluster rather than a file. Go through the members that matter and read their sightings too. The result is the set of assets that saw any member of the family, which is the real fleet answer, and it is routinely larger than the set that saw the one file you started with. That difference is the scope of the incident.
If you have a list rather than a handful, query it instead of clicking. hash:[aaa,bbb,ccc] sweeps a set of hashes, oac:5+ narrows to objects held by five or more of your assets, and the CEL equivalents are asset.count and asset.global_count. See StairQL, CEL Query Language, and Example Queries.
Step 6: Ask what came with it
The last of the four questions. Run Run-to-Ground from the file: right-click the hash and choose Run to ground under Workflows.
It expands across the file's variants, finds which of your assets held any of them, and reports what else landed on those machines within a day either side of arrival, keeping only the rare files. Those survivors are the ones that never triggered anything, which is exactly why they are still there.
A clean result is a finding. The file arrived alone, nothing rare came with it, and no relatives are sitting elsewhere in your fleet. Write it down; that sentence is what closes an incident rather than extending it.
If it is not clean, this page has done its job and hands over. Each new component Run-to-Ground surfaces is itself a starting hash worth running, because each run anchors its window to when that file landed on that machine, and the timeline walks backwards on every pass. When the family turns out to matter, a YARA rule written on what its members share is the only instrument here with no time bound at all. Both of those, in order, are on An EDR Alert Just Fired.
That is the difference between this page and that one. This page answers a question about a file. That page works an incident.
What do I do with all this?
You have gone from one file to a scope, and the two facts to act on are the earliest date and the widest set of machines. The date tells your responders when to start looking in their own tooling. The set of machines tells them where.
Then record the conclusion. Set an opinion with a comment, in whichever direction you landed, so that the next person to ask "is this file anywhere else" starts from your answer. On a cluster you can judge from the variant detail pane without leaving the investigation, and judging a family in one pass is nearly always right, since members that resemble each other usually deserve the same call.
What should I read next?
- Prevalence, for the two figures in Step 1 and how they are read together.
- Variants and Sightings, for why these two lenses are used together in almost every investigation.
- A Vendor in Your Supply Chain Got Breached, for the case where Step 4 is the only step that could have found the second machine.
Updated 4 days ago