INCIDENT RESPONSE
RUN EVERY ALERT TO GROUND
Run to Ground turns any alert, indicator of compromise, or file into a full incident response campaign view. It connects variants, endpoints, and timelines in one place, so you can prove blast radius, trace infection paths, and close the loop with evidence.
WHY RUNNING ALERTS TO GROUND MATTERS
BEYOND SINGLE ALERTS
Stairwell turns a single alert into linked files, hosts, users, and infrastructure so you can run every threat to ground.
UNDERSTAND BLAST RADIUS
Stairwell maps where a threat has and hasn’t been, so you know real impact from the truth of your own data.
MANUAL PIVOT FATIGUE
Automates manual pivots from EDR, SIEM, DNS, and threat feeds into one investigation view, saving your team time.
“Stairwell has accelerated our threat response and enhanced accuracy. The run to ground feature provides comprehensive visibility into related files, empowering us to respond more effectively and protect our organization with greater certainty.”
Tony Watson, CISO, Groq
WHAT IS RUN TO GROUND?
IOC TO CAMPAIGN IN ONE CLICK
- Finds files related by structure and content, not just exact hash matches
- Sees every host touched, whether the file executed or misbehaved
- Connects artifacts including linked domains, IPs, and C2
- Identifies droppers, loaders, and second-stage payloads by analyzing low-prevalence files that appear within 24 hours of each variant.
FROM FILE TO FULL SCOPE
- Identifies which devices possessed the file, even if it didn’t execute.
- Shows paths to where the file is on disk, revealing user directories and staging locations
- Finds reuse patterns and lateral movement across systems
ONE SAMPLE TO ENTIRE FAMILY
- Expand from one sample to every repacked, re-signed, and modified variant
- See how each variant spread across hosts and time
- Find connections to threat reports, YARA rules, and shared infrastructure
ENGINEERED FOR PLANET-SCALE
Built by Google and intelligence veterans. Web-scale indexing, YARA at ludicrous speed, and structured AI reasoning turn raw artifacts into instant understanding across everything you’ve ever seen.
LEARN MORE ABOUT STAIRWELL
FREQUENTLY ASKED QUESTIONS
What does it mean to run a threat to ground during an incident investigation?
Running a threat to ground means following an initial indicator all the way through to a complete understanding of the attack: when it arrived, where it spread, what devices it touched, what other tools or files were part of the same campaign, and which systems need remediation. The goal is to close the investigation with confidence rather than partial knowledge that leaves open the question of whether anything was missed.
In practice, most investigations start with a single alert or a single suspicious file and end prematurely because expanding the scope manually takes too long. Analysts pivot from hash to related hashes, check a few hosts, review some logs, and declare the incident contained based on incomplete evidence. Running a threat to ground replaces that manual process with an automated expansion: one indicator becomes every related file, every affected host, and a complete timeline of activity, giving responders the full picture they need to close the investigation with documented evidence.
How do threat hunting tools connect a single indicator into a full campaign view?
Effective threat hunting tools expand from a single indicator by identifying all files that share structural characteristics with the initial sample, mapping which hosts in the environment have encountered any of those files, and building a timeline of activity across the campaign. This expansion replaces manual pivoting, where an analyst jumps between tools checking each related indicator individually, with an automated graph that connects the dots automatically.
The quality of this expansion depends on what the tool uses to identify relationships. Hash matching only finds exact copies. Tools that examine code structure, imported functions, packer signatures, and embedded infrastructure can find variants and related tooling that hash-based matching misses entirely. This matters most when investigating sophisticated threats that routinely modify their tooling specifically to break hash-based detection. Starting from one known bad sample and expanding to the full malware family tree gives hunters a complete operational picture of the campaign.
How does Run to Ground differ from a standard EDR alert investigation?
A standard EDR alert investigation focuses on the specific event that triggered the alert: the process that ran, the file that was executed, the behavior that was flagged. Run to Ground starts from that same event but automatically expands to find every related file, every affected host, every variant, and the full infection timeline, producing campaign-level visibility from a single starting point without requiring the analyst to pivot manually through each step.
EDR platforms excel at behavioral detection and process-level telemetry, but they typically surface individual alerts rather than campaign context. An analyst investigating an EDR alert learns what happened on that one endpoint at that moment. Run to Ground asks what else belongs to this attack: which other files share code with this one, which other machines have those files, when did the first variant arrive, and what infrastructure has this malware family used. That campaign context is what transforms a point alert into a defensible incident response with clear remediation scope.
How do you trace lateral movement during a threat hunting investigation?
Tracing lateral movement requires connecting file artifacts across multiple hosts to establish a chronological path from initial compromise through each subsequent system. If the same malware variant or a structurally related variant appears on multiple endpoints, and those appearances can be ordered by timestamp, the sequence reveals how the attacker moved from system to system.
Traditional lateral movement analysis relies heavily on authentication logs and network connection records, which show that access occurred but not always what tools were used. File-level analysis adds a complementary view: when the same executable or a variant of it appears on a series of hosts in sequence, that sequence is strong evidence of deliberate lateral movement using the same tooling. Connecting file artifacts across hosts, sorted by first-seen timestamps, gives threat hunters a map of movement that complements the network and authentication story and often reveals hosts the log-based analysis missed entirely.
What is blast radius in a cybersecurity incident and how do you measure it accurately?
Blast radius refers to the full scope of systems, accounts, and data potentially affected by a security incident. Accurately measuring blast radius requires knowing which systems had the malicious files present, whether those files executed, which user contexts they ran under, and whether any related variants or associated tooling were present on other systems that might not have triggered a direct alert.
Blast radius assessments are only as accurate as the telemetry they are based on. An estimate built on EDR alerts tells you where the alerts fired; it does not tell you about systems that were touched by malware that evaded detection or by variants the EDR did not recognize. File-centric analysis expands the blast radius picture by searching for all files that are structurally related to the confirmed malware, across all enrolled endpoints, to identify potential exposure that behavior-based methods would miss. This is especially important for post-incident reporting and for determining the scope of required notifications.
How does proactive threat hunting differ from alert-driven incident response?
Alert-driven incident response waits for a detection system to fire before investigation begins. Proactive threat hunting starts with a hypothesis about how an attacker might have compromised the environment, then actively searches for evidence of that activity before any alert has fired. Hunters look for anomalies in file behavior, rare processes, unexpected network connections, or structural similarities to known malware that existing detections have not yet recognized.
Threat hunting is most effective when hunters have access to the same investigative capabilities that power incident response: file structure analysis, YARA rule matching, variant discovery, and prevalence data. Hunters operating without these tools are limited to log-based searches that only surface events the organization already knew to look for. Platforms that give hunters direct access to the full executable history of the enterprise, combined with similarity search and threat intelligence enrichment, enable hypothesis-driven hunts that find threats the detection stack has never seen.
How do you build a defensible infection timeline during incident response?
A defensible infection timeline establishes when each phase of an attack occurred using evidence that can withstand scrutiny: file timestamps, process execution records, network connection logs, and the first-seen date of malware artifacts across the environment. The timeline answers when the threat first gained access, how long they were active, which systems were involved at each stage, and when each phase of the attack occurred.
Building this timeline from file evidence rather than logs alone produces stronger documentation because files preserve information that logs may not capture, especially if log integrity was compromised during the attack. First-seen file timestamps, correlated across multiple endpoints, establish when specific tools were introduced to the environment. Connecting those timestamps to the full malware family discovered through variant analysis gives responders a chronological map of the entire campaign, which is essential for insurance claims, regulatory notifications, and internal post-mortems.