Another Vendor Flagged a File

Somebody dropped a screenshot in a channel. An aggregator shows a handful of engines calling a file malicious, one of them naming a family, and the rest saying nothing. Or a colleague's scanner flagged something yours did not. The question in the channel is "is this real", and the person asking wants an answer, not a link.

Fast answer: run AI Triage on the file. The question here is what this file is, not how far it got, so triage and the verdict answer it faster than an investigation will. If it does turn out to be bad and present in your environment, hand the hash to Backstory at that point.

What will I know by the end?

How to read Stairwell's single verdict on the file, which evidence actually settles a disagreement and which evidence only looks like it does, and how to record your team's conclusion so that nobody has this conversation again next month.

Why this works

Three ideas settle most of these arguments before you have opened a tab.

A count of engines is not a probability. Detection tools share heuristics and share false positives, so forty detections and three detections are not two points on one scale. A tally is a description of an industry, not a statement about a file.

A verdict is not frozen. Stairwell keeps the file, so it keeps re-deciding as engines, analyst opinions and triage findings change. A disagreement today may simply be a file the world has not finished understanding, and it will be re-answered without anyone remembering to go back.

Your team outranks the platform locally. An opinion your analysts record overrides the automated verdict inside your environment. So the end state of this page is not "who was right" but "what did we decide", which is a question you can actually close.

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

Step 1: Read Stairwell's verdict, and know what kind of statement it is

Open the file and read the MalEval card on the Summary tab. Stairwell gives one answer: a malicious likelihood of Low, Medium, High, or Very High, plus labels such as a malware family name. MalEval combines multiple detection engines, machine learning, and analyst opinion into that one verdict. See Verdicts.

Two readings to get right immediately.

Scan Pending is not clean. It means nothing has been computed yet. A file with no deep analysis is not being called safe.

Low is not innocent either. It means the platform is not persuaded, which is a different claim from "this is fine".

Now compare that with what you were sent. A count of engines is not a probability. Three detections out of many is not a low likelihood, and forty is not proof; it is a tally of tools with overlapping heuristics, correlated false positives, and no view of your organization. The reason Stairwell publishes one verdict rather than a scoreboard is that adjudicating vendor strings is work, not an answer, and it does not scale past the first hundred files of a shift.

Two properties of that verdict matter more than the number.

It is not frozen. Stairwell keeps the file, so it can keep re-deciding. A verdict reflects the newest engine results, the newest analyst opinions, and the newest AI Triage findings, including for a file collected years ago. A file that read as unremarkable in March and is understood in September does not need anyone to remember to go back.

Your team outranks the platform. An opinion your analysts record overrides the automated verdict inside your environment. That is Step 7, and it is the whole point of this page.

Step 2: Get the evidence instead of the tally

Open the AI Triage tab. It hands back what a senior analyst would have written about this one file: a summary, a malicious likelihood with a confidence score, a specific threat type such as a loader or a credential stealer, the indicators found inside the file, a MITRE ATT&CK mapping tied to observed behavior, and the reasoning behind all of it. See AI Triage.

Read the confidence before the likelihood. A high likelihood with low confidence is a lead to check, not a conclusion to act on, and treating those two numbers as one is how a false positive gets escalated.

This is the artifact to paste back into the channel. It says what the file is, which is the thing a detection count never says.

Step 3: Check the cheap discriminators

Four fast reads, in this order. Most disagreements resolve inside these.

Prevalence. A file present across a large share of environments that a few engines dislike is very probably popular software, and generic-signature false positives cluster exactly there: on installers, on packers, and on dual-use administration tools. A file two of your machines have and nobody else in the world does is the opposite, and the detection deserves the benefit of the doubt.

The code-signing certificate. The panel shows whether the file is signed and whether the signature verifies. A valid signature from a publisher you recognize is meaningful context, with one caveat worth remembering: in a build-system compromise the affected release is signed correctly by the real publisher. See A Vendor in Your Supply Chain Got Breached.

The YARA matches. Read which rules hit, not how many. A YARA hit is evidence, not a verdict, and a rule written for an attacker's favorite administration tool matches your copy of that tool too. See What is a YARA rule?.

The binary image. The small picture in the header shows you in about two seconds whether the file is packed. Packing is the usual cause of a heuristic detection on entirely legitimate software, since installers, archives, and anything with compressed resources produce the same even static. Packing is a reason to look closer, never a finding.

Step 4: Ask what else it resembles

Open the Variants tab, because the fastest way to settle an argument about one file is to look at the family it belongs to.

Variant Discovery finds the files that resemble this one across the entire corpus, both your own private files and the global malware corpus, ranked, each carrying its own verdict, rarity, and any opinion your team has recorded. Two clean outcomes:

• The cluster is full of files already judged Malicious. The disagreement is over. You are looking at a member of a known family, whatever the tally said.
• The cluster is a set of benign builds of one product. Also over, in the other direction. The detection found a family, and the family is a legitimate application's release history.

Keep one distinction straight while you are here. A verdict answers whether a file is malicious. Variant Discovery answers what a file resembles. They are separate systems answering different questions, so a file can have a confident verdict and no interesting variants, or a pile of variants and no verdict at all.

Step 5: Look at what it points at

Cheap, and frequently decisive. The Embedded Data section of the object panel lists the hostnames and addresses inside the file, each with a resolution history behind it. See Hostnames and IP Addresses.

What you are looking for is a mismatch between the file's story and its infrastructure. A vendor tool that reaches for its own vendor's domain, resolving steadily for years, is consistent. A file claiming to be that tool while carrying a hostname registered four months ago and answering from one address is not, and that single observation settles more of these than the verdict does.

The crowding check applies here too. A hostname referenced by an enormous number of files across the corpus is something everyone touches and tells you nothing. One referenced by a handful is worth the next ten minutes.

Step 6: Check whether it went anywhere

Evidence about behavior beats evidence about bytes, and the cheapest behavioral evidence you have is where the file has been.

Read the sightings: which machines, what it was called there, when it first arrived. Then run Run-to-Ground if the file is still in question. A file whose relatives landed on the same machine, in the same hour, as rare tooling nothing else flagged is not a false positive regardless of what any tally said. A file that has been on four hundred laptops for three years, arriving through your software deployment path, is your own software.

Step 7: Decide, and record it

Set an opinion from the control at the top of the object panel. This is the step people skip because the file is now settled in their own head, and skipping it is what makes the same file get triaged again next quarter by somebody slower.

• Trusted or Benign when you have cleared it. That makes the verdict safe for readers of your environment, stops the notifications it was generating, and takes it out of threat report match counts, which is how a legitimate tool stops inflating every report's numbers.
• Malicious when you established it and nothing else did. That reaches everything downstream: the verdict, the alerting, and every list the file appears on.
• Grayware for the honest middle, which is where most of these end up: not malicious, but unwanted or risky in your context, such as a dual-use administration tool your policy prohibits.
• Vulnerable sits on a separate axis. It records that a file carries a known security weakness rather than a judgment about intent, which is what you want for patching and hygiene work.

Write the comment. Six months from now the value of this decision is entirely in the reasoning, and the reasoning is the part nobody can reconstruct. Check that the environment named in the form is the one you mean before you submit.

Your call also travels. It shows up next to that file everywhere it appears, including inside somebody else's variant list, so a colleague arriving from a different direction sees your conclusion rather than repeating your work. And a trigger can fire when an opinion changes, which is how a team of more than one person stays in sync about what has been decided.

Whose call wins, if Stairwell's researchers disagree with me?

Yours, inside your environment.

Stairwell's own research can set an opinion that applies as the default everywhere. Your environment's opinion overrides that default, and only within your environment. If Stairwell's researchers call a dual-use tool Grayware and your policy prohibits it on your fleet, you mark it Malicious, your team sees Malicious, nobody else's view changes, and the global assessment is not weakened by your local decision.

The History tab records every change: who set which value, when, in which environment, and what it was before. That is the audit trail, and it is what makes an opinion defensible rather than merely convenient.

What are the honest limits here?

• Stairwell is not inline and is not a network enforcement point. Nothing on this page blocks a file. It tells you what the file is so you can act in the tools that do.
• Detonation is partial. There is some behavioral analysis available, in beta, and Stairwell is not a full sandbox. Read it as an addition to the static evidence rather than a complete behavioral profile.
• The platform cannot know your authorization context. No analysis of a file can tell you that your copy of a remote administration tool was deployed on purpose by your help desk. Only your organization knows that, which is precisely the gap an opinion exists to fill.

What should I read next?

• Verdicts, for how the single verdict is formed and what changes it.
• What is an opinion?, for why your team's call outranks everything else and what it changes downstream.
• Is This File Anywhere Else?, for the prevalence and sightings work in Steps 3 and 5 in more depth.