A Vendor in Your Supply Chain Got Breached

A software vendor you use published a notice this morning. Their build system was compromised, they are not sure for how long, and some number of signed releases went out with something extra in them. Your CISO wants three answers by the end of the day: did their installer ever land here, which versions, and what did it drop.

This is the hardest question in the list to answer with the tooling most teams have, and it is worth understanding why before you start. The affected build may have shipped nine months ago, so endpoint telemetry has long since rolled off. Nothing ever alerted on it, because it was signed by a publisher you trust and it behaved like the software it was. There is no alert to look back at and no detection to pivot from. What you need is the file itself, kept from whenever it arrived, along with its version metadata, its sighting history, whatever came out of it, and the ability to ask what else resembles that payload.

Easy Mode: the inventory work below has no seed to give Backstory, but the moment you have a hash for a payload inside one of those installers, hand it to Backstory and let it scope the rest.

What will I know by the end?

Which of your machines held which versions of the vendor's software and on what dates, whether the affected build was among them, what that installer contained, and whether anything resembling the payload is sitting elsewhere in your fleet under a name that has nothing to do with this vendor.

Why this works

Three ideas carry this one, and the first is the one that makes supply chain different from every other playbook here.

Authenticity is not authorization. A valid code signature proves the file is a genuine build from that publisher. In a build-system compromise the affected release is signed correctly by the real vendor, because that is the entire point of the attack. So the signature is evidence of provenance and evidence of nothing else, and signed:VALID cannot be your discriminator.

The vehicle is not the payload. The installer is what the vendor knows about and what the notice names. What matters to you is what came out of it, and once you have that, the vendor's advisory stops being the boundary of the investigation.

Hashes change for free, content does not. The payload is reused across deliveries and recompiled between them, which is why Step 5 can connect an implant in a signed update to a file that reached a different machine of yours by a completely different route.

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

Step 1: Start from the publisher, not the hash

Search for the vendor's software rather than for one indicator. A breach notice names versions and dates long before it names hashes, and sometimes it never names hashes at all.

For Windows binaries the publisher and product are in the file's own metadata, and both are searchable fields:

company:"Vendor Name"

pe.company_name.contains("Vendor Name")

That returns every file of theirs Stairwell holds for you, not only the copy currently installed. See StairQL and CEL Query Language.

Then narrow by what the notice told you. product: picks out one product from a vendor with several, and version: takes a range and understands semantic versions, so an advisory that says "builds 4.2.0 through 4.2.6" becomes a query rather than a reading exercise:

company:"Vendor Name" product:"Agent" version:4.2.0+ version:4.2.6-

Two honest limits before you trust an empty result. This metadata exists for Portable Executables, so a macOS or Linux package, an installer that carries no version resource, or a script gives you nothing to filter on; fall back to filename and path, and to hashes once the vendor publishes them. And a valid code signature is not the discriminator here. In a build-system compromise the affected release is signed correctly by the real publisher, which is the entire point of the attack, so signed:VALID tells you the file is authentic and tells you nothing about whether it is safe.

Step 2: Which versions did we have, and when?

Open each version you found and read its sightings. That table is the answer to the executive question, with dates attached.

For every machine that reported the file you get the asset, the path, the filename it used there, when it first arrived on that machine, and when it was last seen. Sort by first seen and you have the rollout of the vendor's software across your fleet as it actually happened, including on machines that were reimaged or decommissioned since, because the asset record outlives the machine.

State the finding precisely, because the distinction will be quoted back at you. A sighting records that the file was present on that machine at that path from that date. It is not a record of execution. Stairwell is not an endpoint detection product and does not sit inline; presence with dates is what it can prove, and for an installer that landed in a deployment share and was never run, presence is the honest answer. Say which one you have.

Compare last seen against the asset's last check-in before you tell anyone a version is gone.

Step 3: Is the affected build actually one of ours?

When the notice publishes hashes, do not transcribe them. Copy the whole notice, paste it into the search bar, and let Stairwell pull the hashes, hostnames, and addresses out of the text, defanged forms included. See Hunting and Search.

Read the two object tabs as two different answers. My Objects is exposure. Global Objects is context: the world has this file, you do not, which is worth knowing and is not an incident.

Then bring the notice in as a threat report rather than leaving it as a search. A report's indicators are matched against everything you already hold as well as everything that arrives afterward, so you get the retrospective answer for the file that has been on three servers since last spring, and you keep the coverage for the second wave of indicators the vendor publishes next week. A search answers once. A report keeps answering.

Step 4: What did the installer contain?

Look at the Related files section on the file's Summary tab. When Stairwell unpacks an archive or an installer, the files inside become objects in their own right, each remembering the object it came out of, and each with its own verdict, prevalence, and sightings.

This is where a supply chain investigation stops being about the vendor and starts being about the payload. Work down the children and take the one that is rare, or that carries a bad verdict, or that has no business being in a software update. A child recorded this way is credited to the machine that reported the container, so you keep the asset attribution even though no machine reported that file directly.

Run AI Triage on the child to find out what it is, and keep the indicator list it produces.

From here on, the payload is your pivot. The installer hash was only the delivery vehicle, and the vehicle is the part the vendor already knows about.

Step 5: Where else does that payload turn up?

Open Variants on the payload. This is the step that answers the question nobody else in your stack can, and the reason it works is worth walking through rather than asserting.

Variant Discovery compares across the entire corpus, both your own private files and the global malware corpus, and it traverses between them. The chain runs like this:

The payload A sits in your environment, inside a signed update from a vendor you trust.
A resembles a file in the global malware corpus, because whoever built it has built things before.
That outside file has its own relatives there: earlier builds, repacks, the rest of the 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 may 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.

That matters here more than anywhere else in these playbooks. A supply chain payload is built to arrive inside a trusted vehicle, so the second machine in your fleet very likely received the same tooling by a different route entirely: a different installer, a different vendor, a different day. No shared hash and no shared filename would ever have joined those two events. The relationship the global corpus carries is what joins them.

The same step also finds the sibling builds the vendor's notice does not list. An advisory covers the releases the vendor can account for; the family is usually larger.

Step 6: Work the domains in the advisory, not just the hashes

Vendor advisories almost always list infrastructure alongside hashes, and the domains age better than the hashes do -- an adversary recompiles for free but has to keep infrastructure up while the operation runs.

For each hostname in the advisory:

Read its resolution history. Note every address it used and when. The addresses it abandoned are usually absent from the advisory and frequently still hosting the rest of the operation.
Reverse the addresses. What else lived there is often the part of the campaign nobody wrote up. Weight it by how crowded the address is: two names is a lead, ten thousand is shared hosting.
Ask which of your files reference the name. This is the exposure answer, and it works retroactively -- Stairwell extracted that hostname from your files when it collected them, long before the advisory existed. From those files, go to their sightings and you have machines and dates.

The resolution dates are also what you hand the network team, because they turn "search your proxy logs for this domain" into "search this address range across these three weeks".

See Hostnames and IP Addresses for the concepts, and Someone Reported a Suspicious Domain if you want the full domain workflow rather than this summary.

Step 7: What is the blast radius?

Run Run-to-Ground from the payload, not from the installer.

It expands across the payload's variants, finds which of your assets held any of them, and then reports the rare files that landed on those machines within a day either side. In a supply chain case that window is where the interesting material is: an implant that arrived in an update is usually followed by whatever the operator ran next, and none of it was flagged at the time either.

If the result is clean, that is a real finding. The affected build reached your fleet and nothing came of it, which is a much better sentence to put in the incident report than "we found nothing".

Run it again on what it finds. Every distinct component the first pass surfaces is a new starting hash, and each run anchors its window to when that file landed on that asset. In a supply chain case that is how you find the stage that arrived before the update did, on a machine the first run had no reason to look at. Keep going until a pass yields nothing new.

That recursion is what turns the vendor's disclosure date into your actual first-arrival date. The two are rarely the same, and yours is the one that belongs in the report.

Step 8: Write a rule for the payload

Run-to-Ground works inside a 24 hour window either side of arrival. A YARA rule has no time bound, which is what you want when the affected build may have shipped nine months ago.

Read across the payload and its variants for what they share, then write a rule on that. Saving it as active runs it across the files Stairwell already holds, so it reaches back past every window in this playbook and keeps matching whatever arrives next. See Writing Your First YARA Rule.

This is the step that covers the case the advisory cannot: the same payload delivered through a different vendor, a different installer, and a different day. A hash list from this vendor will never find that. A rule on the payload's own content will.

Let Backstory run the second half

The inventory work in Steps 1 through 3 has no seed to give it. Step 4 produces one.

Once you have the payload's hash, Backstory will expand across its variants, run Run-to-Ground, run it again on what that surfaces, and pull in sightings, prevalence, resolution history and published intelligence, returning a report rather than a dashboard. That is Steps 5 through 7 plus the recursion, which is the part most likely to be cut short by hand. See Starting an Investigation.

Seed it with the payload, never the installer. The installer is the vehicle, and by the second idea above it leads back to the vendor rather than forward to the operator.

It does not write the threat report or the rule. Those stay yours, and in this scenario they are what protects you from the next disclosure rather than this one.

Step 9: How do I record this so it holds?

Set opinions on both sides. Malicious on the affected build and on the payload. Trusted on the clean versions of the same product, so the vendor's legitimate software stops inflating every report's match count and stops paging your team for the next year.
Write your own threat report. Put the hashes you established, the payload's variants that you confirmed, and the infrastructure it referenced into a report your environments subscribe to. That is what turns this week's work into next quarter's coverage.
Hand over the asset list with dates. Which machines, which versions, first seen and last seen. That is the deliverable, and Step 2 produced it.
Configure a trigger on the report so a late arrival, or a machine that comes back from a drawer with the affected build still installed, reaches a human.

What are the limits of this answer?

Worth saying out loud, because a supply chain answer gets scrutinized.

Presence, not execution. See Step 2. Stairwell is not inline and is not a network enforcement point. It tells you what was on which machine and when.
Only what was collected. Collection covers executables, scripts, and related artifacts, roughly 65 formats by default and tunable by your team. A compromised configuration file or document is outside the default set, and a machine with no forwarder contributes nothing.
Coverage follows the fleet. A gap in your forwarder rollout is a gap in this answer, and the Assets screen is where you find out how big it is before somebody else does.

What should I read next?

Is This File Anywhere Else?, for the prevalence and sightings work in Steps 2 and 5 in more depth.
New IOCs Were Published, for the follow-up notices this vendor is going to send.
Backstory, which runs the variant expansion and Run-to-Ground of Steps 5 and 6 as part of one investigation you can start from the payload's hash.