Ransomware Hit a Host

A file server started encrypting at 02:40. There is a ransom note in every directory, your endpoint tool caught something at the very end, and you have one hash for whatever it caught. Restores are somebody else's problem for the next six hours. Yours is the question that decides whether this is over: how did it get in, how long was it in, and is it still sitting on machines that have not started encrypting yet.

Encryption is the last step an operator takes. By the time it runs, the interesting work happened days or weeks earlier, and it happened quietly, with tooling nothing flagged at the time. That earlier material is what you are looking for, and the reason it is findable at all is that the files are still there to look at, whether or not anything ever alerted on them.

Say the honest part out loud first, because someone in the room will ask. Stairwell is not inline and is not a network enforcement point. It did not stop the encryption and it cannot recover a file. What it holds is the file history of that machine and of every other machine you cover, which is what you need to answer the three questions that are actually yours.

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

What will I know by the end?

What the encryptor is, what arrived on that host before it ran, which of those files is the loader or dropper, which other machines hold that same tooling or something built like it, and a scoped list of assets and dates the containment decision can be made from.

Why this works

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

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. Every step below is a way of asking that one question.

Hashes change for free, content does not. A loader is recompiled, repacked or padded between deployments, which costs the operator nothing and defeats a hash sweep completely. What survives is what the code does: an embedded hostname, an odd mutex name, a decryption constant, a specific set of imports. Variants find files that share that substance, across both your private files and the global malware corpus, and they traverse between the two. That matters here because your dropper may resemble something in the global corpus, which has its own relatives there, one of which leads back to a file on a different machine of yours that you would never have connected directly.

Time windows anchor to one machine. When a tool says "what else arrived around then", then means when the file landed on that particular asset, not when it first appeared anywhere. This is why the same search run from a different file finds different things, and it is the mechanism behind Step 4.

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 not the same claim as "it ran".

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

Step 1: Run-to-Ground the hash you already have

Right-click the encryptor's hash and choose Run to ground under Workflows. Do this before any manual browsing. It maps the incident across the enterprise while you are still reading the alert.

Run-to-Ground starts from your hash, finds its variants and then variants of those, finds which of your assets hold any of them, and for each asset reports the rare files that landed there within 24 hours either side of arrival. Those survivors are the close sightings: the co-deployed toolset, which in a ransomware case is usually the whole kit. The loader, the remote access tool, the credential utility, the archiver, and sometimes the operator's copy of a legitimate administration binary.

This is the first idea above, run across every affected machine at once instead of the one you happened to open.

If routine software crowds the output, mark it Trusted and run it again. The next incident on this fleet is faster for it.

Step 2: Turn what you have into a threat report

The step people skip, and the one that keeps working after you go home.

Put the variants and close sightings you have confirmed into your own threat report, along with the infrastructure the files referenced. A report matches backward across everything you already hold and forward across everything that arrives next, so it is a scoping tool and a standing reinfection watch at once. Add a trigger and a re-arrival reaches a human rather than waiting to be noticed.

Build it now, not at the end, and keep adding to it as the next steps turn up more.

Step 3: Work the close sightings

Read what Run-to-Ground surfaced, not only the variants. The close sightings are the files nothing flagged, which is exactly why they are the interesting part.

Treat clusters as the unit. A group of unfamiliar objects inside one narrow window is an installer or a toolset, and it is more diagnostic than any single member.

Run AI Triage on the ones you cannot identify. Two things are worth having: the family, because ransomware crews reuse their loader, their remote access tool and their archiver, which tells you what else to look for; and the hostnames and addresses inside the file, which are your pivots for Step 6.

Step 4: Run it again on everything you find

The step that changes the answer, and the one most people stop short of. Every distinct component you identify, a dropper, a lingering payload, the encryptor itself, is a new starting hash. Run-to-Ground each of them, the same way as Step 1: right-click the hash, Workflows → Run to ground.

This follows from the third idea. Each run anchors its window to when that file landed on that asset, so a payload that arrived three weeks before the encryptor opens a window three weeks earlier, on machines the first run had no reason to look at. Run that one and you may find something earlier still.

Stop after one run and you will report the intrusion as beginning the day the encryptor arrived, which is almost always wrong, and usually wrong by weeks. Keep going until a pass yields nothing new.

Seed these runs with the dropper rather than the encryptor where you can. The encryptor is frequently generated per victim, so its hash leads nowhere. The loader is reused, so it leads everywhere.

Step 5: Write a YARA rule from what the variants share

Recursion still lives inside 24 hour windows. A YARA rule does not, which is why it ends the case.

Read across everything the recursion produced and find what the variants have in common. Those shared pieces are the family's fingerprint, and by the second idea above they are what survives repacking. See Writing Your First YARA Rule and YARA Rule Best Practices.

Saving the rule as active is what produces the answer. Stairwell runs it across the files it already holds, so matches come back for files that arrived long before the rule existed, and it keeps matching new arrivals. Stairwell calls this Warpspeed.

No time window applies. Not 24 hours, not 90 days. If the loader landed on a laptop eight months ago and nothing ever flagged it, a rule written this morning finds it this morning. Run-to-Ground and manual search are both anchored to a moment; a rule is anchored to content.

Put the rule in the threat report alongside the hashes. Reports carry rules as indicators, and a rule keeps earning long after a hash list has gone stale.

Step 6: Work the infrastructure

Take the hostnames and addresses from Step 3 and look them up. See Network Intelligence.

Read the resolution history, because where a name pointed during the intrusion is a different fact from where it points now, and the historical answer is what your logs need to be searched against. Then find the other files in your environment referencing the same infrastructure, which regularly surfaces a stage nobody had connected yet.

If the domain is where you started rather than the file, Someone Reported a Suspicious Domain is that direction written out.

When to stop and search by hand

Run-to-Ground tells you which machines to care about. It does not tell you what was happening on them before its window opens, and until you have a rule you cannot ask that question by content. So when a run hands you an asset worth caring about, search that asset directly and widen:

asset:FILESRV-04 envfs:7d+ !wk

Files first seen on that host in the last week, excluding well-known files. Then 30 days, then 90, sorted by rarity. See StairQL and Hunting and Search.

Reach for this when the recursion runs dry but the dates still look too recent to be true, when you need to know what a machine looked like before the incident, or when you want to check the instrument's answer against the raw record. Knowing how to ask by hand is what keeps the fast path honest.

Let Backstory run it

Backstory does almost all of the above, and a ransomware case is close to its best use: you have a starting point, the work is broad, and you are short of time.

Give it a 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 from what it has already found. It returns a report rather than a dashboard. 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 4, which takes an analyst the longest and gets abandoned the most often, and it is the main reason Backstory reaches an earlier and more accurate start date than the same investigation worked by hand.

Seed it with the dropper rather than the encryptor. Seeds are a hash, a hostname, or an IPv4 address, so seed it with one of those rather than with the affected machine.

It does not write the threat report or the YARA rule. Those two stay yours, and they are what convert an investigation into standing coverage. It does not make the containment call either. Whether to isolate the other eleven machines tonight is yours, and it should be.

How do I state the scope?

Assemble the answer as assets and dates, and be precise about what kind of claim each line is.

For each file you established as part of the intrusion, its sightings give you the asset, the path, the filename used on that host, and when it was first and last seen there. That is your affected-machine list, and the earliest first-seen across the set is your best evidence for when the intrusion began.

By the fourth idea above, say which lines are presence and which are execution. For an encryptor whose output you are looking at, execution is not in doubt and your evidence is the encrypted files, not the sighting. For the loader on a machine that has encrypted nothing, presence is what you have, and presence is what to report.

Filenames differ per machine, because the name and path live on the sighting rather than the file. Read the names off the sightings and hand that set to whoever is searching logs.

How do I leave this better than I found it?

1. Set opinions with comments on the encryptor, the dropper, and every variant you confirmed. The comment is what makes the record useful in six months.
2. Keep the threat report and the rule current as later work turns up more.
3. Mark the routine software Trusted that crowded your Run-to-Ground results.

What are the limits of this answer?

• Presence, not execution. See above.
• No prevention. Stairwell is not inline, is not a network enforcement point, and has some detonation without being a full sandbox.
• Only what was collected. Roughly 65 executable and script formats by default, tunable by your team. The ransom note is a text file and probably is not collected, which does not matter, because the note is not the evidence you need.
• Coverage follows the fleet. A machine with no forwarder contributes nothing, which does the most damage exactly where scope matters most.

What should I read next?

• Run-to-Ground, the instrument Steps 1 and 4 are built on.
• Variants, for why the loader is findable when its hash is not.
• Write It Up, for turning Step 2 into something the team can act on.
• An EDR Alert Just Fired, the shorter version of this loop for a single unexplained file.