An EDR Alert Just Fired

An alert fired twenty minutes ago and all you have is a SHA-256, the name of one machine, and a detection string that could mean six different things. Your endpoint tool says it acted on the file. Nobody can tell you yet whether this is the start of an incident or the third false positive this week, and somebody is going to ask you inside the hour.

This page is the order to work in. Every instrument it names has its own page; what is here is the sequence, and the decisions that change which instrument you reach for next.

Easy Mode: let Backstory run this investigation and read the report it returns.

What will I know by the end?

Whether the file is worth your attention, every machine of yours that has held it or something built the same way, what landed on those machines alongside it that nothing flagged, and a written conclusion that the next analyst inherits instead of rediscovering.

Why this works

Three ideas carry the sequence. They are worth understanding rather than memorizing, because they are what let you tell a real result from a misleading one.

Hashes change for free, content does not. Recompiling, repacking or padding a file costs the adversary minutes and defeats every hash-based sweep. What survives is what the code does, which is why Step 5 finds things Step 1 cannot.

Rare, plus arrived at the same time, equals suspicious. No alert required. A file almost nothing in your fleet has, which landed on a machine within hours of something you already distrust, is the shape of tooling that evaded detection. That single idea is what Step 7 automates.

Presence is not execution. A sighting records that a file was on a machine at a path from a date. That is the correct thing to report, and it is a weaker claim than "it ran".

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

Step 1: Is this file in my environment at all?

Paste the hash into Search. This is the whole first step, and the answer arrives in a second.

The search bar takes a SHA-256, a SHA-1, or an MD5, so whatever form the alert handed you is the form you paste. See Hunting and Search.

Three outcomes, and they start three different investigations.

• A hit under My Objects. The file has been in an environment you can read. You have an exposure question, and the rest of this page is how you answer it.
• A hit only under Global Objects. Stairwell has the file, your fleet has not reported it. Read the file anyway, because the intelligence on it is worth two minutes, then go back and check that you were searching the environment the machine belongs to. See Environments.
• Nothing. The file is new to Stairwell as well as to you. Before you conclude anything, check the environment scope, and check whether the file is one Stairwell collects at all: collection is aimed at executables, scripts, and related artifacts, roughly 65 formats by default and tunable by your team, so a data file is not expected to be there. A machine with no forwarder on it also contributes nothing.

Step 2: What does the object panel tell me before I read anything else?

The header, which is the fastest read in the product. It carries the filename and hash, the verdict, your team's opinion if anyone has set one, how many YARA rules matched, whether the file is signed, and its binary image. See The Object Panel.

Four decisions live in that one screen.

• Your team already marked it Trusted or Benign. Somebody adjudicated this file before you. Open the History tab, read who decided and why, and unless something about the situation is genuinely new, you are done. This is a common outcome in a real alert queue and it is the reason opinions exist.
• The verdict is High or Very High. Treat it as real and go straight to scope. The labels often name the family, which tells you what to expect next.
• The verdict is Low, or the file reads Scan Pending. Neither of those is a clean bill of health. Low means the platform is not persuaded, and Scan Pending means it has not answered yet. Keep going.
• Rules matched. A YARA hit is evidence, not a verdict. Rules written for an attacker's favorite administration tool match your copy of that tool too. Read which rule matched, not the count. See What is a YARA rule?.

Step 3: Is it rare, and where has it been?

Read prevalence first, then sightings. Rarity is the cheapest triage signal you have, and the two prevalence figures answer different questions.

Rare in your fleet and absent everywhere else is where novel tooling has to live. Common in your fleet and absent everywhere else is software built for you, which is either your own IT team's or an intrusion that has already spread. Common in both is almost always infrastructure, and the alert is probably about a broad rule rather than a bad file.

Then open the Sightings tab and sort by first seen. Two things regularly fall out of it.

The first sighting predates the alert. Often by weeks. That changes the question from "clean this laptop" to "what happened on that date", and it is the most valuable single fact on the page, because it is the one your endpoint telemetry has already forgotten.

The filenames differ per machine. The name and path live on the sighting, not on the file, so the same object arrives as an installer in a temp directory on one host and as a system-looking binary on another. Read the names off the sightings and hand them to whoever is searching logs, rather than hunting by the one filename the alert gave you.

One asset or forty is the difference between a contained event and a spreading one, and it decides how urgently you do everything below.

Step 4: What is this file, if I still do not know?

Open the AI Triage tab. It gives you a summary, a malicious likelihood with a confidence score, a specific threat type, the indicators inside the file, 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.

The indicator list is the part to keep. Those hostnames and addresses are your infrastructure pivots, and they are what you take to Someone Reported a Suspicious Domain if the investigation turns that way.

Step 5: The hash is a dead end. Now what?

Open the Variants tab. This is the step that gets skipped, and it is the step that most often turns a dead end into an incident.

An exact hash stops matching the moment the adversary recompiles, repacks, or pads a file, which costs them minutes. Variant Discovery answers the other question, "what else looks like this", across the entire corpus: both your own private files and the global malware corpus. So one hash becomes the cluster it belongs to, ranked, with each member's own verdict, prevalence, and opinion.

Two decisions come out of the list.

• A member of the cluster already carries a Malicious opinion or a bad verdict. Your question is no longer whether this file is bad. It is how far the family got, which is Step 7.
• The cluster is a pile of common, high-prevalence files. You are usually looking at a shared library or a packer rather than a family. Sort for the rare end and start there.

You can set an opinion from the variant detail pane without leaving the investigation, which is how you judge a cluster in one pass rather than a file at a time.

Step 6: What infrastructure does it reach for, and was it live?

Open the Embedded Data section of the object panel. It lists the hostnames and IP addresses found inside the file, and each one is an entity with its own history rather than a string. See Hostnames and IP Addresses.

Take the hostnames that are not obviously ordinary and read their resolution history.

• Was it resolving when the file was on the machine? Compare the resolution dates against the first-arrival date from Step 3. A name that was dark then and lit up afterwards, or that went dark the week the file landed, tells you where in the campaign you are standing.
• What else is parked on its addresses? Reverse the addresses. If two names answer there, the other one is probably the rest of this. If ten thousand do, it is shared hosting and the indicator is close to worthless.
• How many other files reference it? A hostname in a handful of files is a lead. A hostname in an enormous number is something the whole internet touches, and it will waste your afternoon if you treat it as a finding.

This is also what gives an incident ticket dates that your proxy and firewall logs can actually be searched against, which is usually the single most useful thing you can hand the network team.

One boundary to keep. This says where a name pointed and when. It does not say a machine of yours reached it -- there is no sensor in your network anywhere in this. Connection evidence is in your own logs; what Stairwell supplies is the list of addresses and the dates worth searching for.

Step 7: How far did it get?

Run Run-to-Ground from the hash. Right-click it anywhere, and under Workflows choose Run to ground.

It works outward from your file to its variants, finds which of your assets held any of them, and then, for each of those assets, looks at what else landed on that machine within a day either side of arrival, keeping only the rare files. What comes back are the close sightings: files that are unusual across your fleet and that showed up on the same machine at the same time as something you already distrust. That is what a file which evaded detection looks like from the outside, and it is the answer no alert was going to hand you.

Prioritize it rather than reading it end to end. Take the clusters before the individual files, because a group of unfamiliar objects inside one narrow window is usually a toolset or an installer package and is more diagnostic than any single member. If routine software keeps crowding the result, mark it Trusted and run it again; the next result is cleaner for you and for everyone after you.

A clean Run-to-Ground is a finding. It means the file arrived alone, with no co-deployed tooling and no relatives elsewhere in your fleet. Write that down, because it is what shrinks the incident.

Step 8: Run it again on what it found

If Step 7 returned components you had not seen before, each of those is a new starting hash. Run-to-Ground each of them -- right-click the hash, Workflows → Run to ground, from wherever it appears in the result.

The reason is the anchor. Each run measures its window from when that file landed on that asset, so a component that arrived two weeks before your alert opens a window two weeks earlier, on machines the first run had no reason to look at. Keep going until a pass yields nothing new.

This is what turns "a laptop got an alert on Tuesday" into an accurate first-arrival date, and it is routinely earlier than the alert suggests. Skip it and you will report the incident as starting the day your endpoint tool noticed, which is the day it noticed rather than the day it began.

Step 9: Write a rule if the family matters

Run-to-Ground works inside a 24 hour window either side of arrival. A YARA rule has no time bound at all, which is why it is the move that closes a case rather than pausing it.

If Step 5 gave you a cluster worth caring about, read across its members for what they share: an embedded hostname, an unusual mutex name, a distinctive constant, a specific combination of imports. Those are the family's fingerprint, and by the first idea above they are what survives repacking. See Writing Your First YARA Rule.

Saving the rule as active runs it across the files Stairwell already holds, so matches come back for files that arrived long before the rule existed, and it keeps matching new arrivals. If the loader landed on a laptop eight months ago and nothing flagged it, this is the step that finds it.

Not every alert earns a rule. One file you cleared does not. A family that reached three machines and recompiles between builds does.

Step 10: How do I leave this better than I found it?

The investigation is not finished when you know the answer. It is finished when the answer is somewhere the next person will find it.

1. Set an opinion with a comment. Malicious if you established it, Trusted or Benign if you cleared it. The comment is the part that matters in six months, because the value of a conclusion is mostly in the reasoning and the reasoning is what nobody can reconstruct later.
2. Put your indicators into a threat report of your own. Hashes, hostnames, and addresses you established keep matching after the ticket closes, backward across what you already hold and forward across everything that arrives next.
3. Configure a trigger so the next match reaches a human by email or webhook rather than waiting to be noticed.

Where does Backstory fit in this?

Backstory runs this sequence for you. Give it the hash and it establishes what the file is, expands across variants, runs Run-to-Ground, pulls in sightings, prevalence, resolution history, and published intelligence, and decides what to chase next based on what it has already found. It returns a report rather than a dashboard, which means it also writes the summary you were going to spend the afternoon on. See Starting an Investigation.

It recurses. When a run surfaces a new component it runs Run-to-Ground on that component too, and keeps going. That is Step 8, which takes an analyst the longest and gets abandoned the most often, and it is the main reason Backstory arrives at an earlier first-arrival date than the same alert worked by hand.

Use it when you have a starting point and not enough time, which describes most alerts. Work by hand when you already know the single question you need answered.

It does not write the threat report or the YARA rule. Steps 8 and 9 stay yours, and they are the ones that turn an afternoon's work into coverage that keeps running. It does not replace you either: it does the legwork and the correlation, and deciding what to do about a confirmed intrusion is still your call.

What should I read next?

• Is This File Anywhere Else?, for the four different questions hiding inside that one, and how to answer each.
• Another Vendor Flagged a File, when your other tooling and Stairwell disagree.
• The Object Panel, for the rest of what is on the screen you spent this page in.