Forensics today is no longer about collecting everything. It's about asking the right questions, in real time, across your entire environment.

This is where distributed, query-driven forensics comes in and why tools like Osquery have become foundational to modern Digital Forensics and Incident Response (DFIR). Most DFIR workflows have a hidden cost: the time lost switching between your endpoint detection and response (EDR), your security information and event management (SIEM), and your forensic tooling. Elastic Security eliminates that gap entirely, from a blocked alert to a deep-dive forensic query, without leaving the platform or losing investigative context.

Rethinking forensics in modern environments

DFIR has traditionally been treated as a post-incident activity. Evidence was collected, systems were imaged, and analysis happened after the attacker had already completed their objectives. That model assumed stability: stable hosts, predictable timelines, and the ability to pause systems for investigation.

Today, those assumptions no longer hold.

Infrastructure is dynamic, endpoints are frequently reimaged or short-lived, and attackers operate on timelines measured in minutes rather than days. Waiting to collect full forensic images isn’t just inefficient; it’s also operationally infeasible. By the time analysis begins, the system may no longer exist, or the attacker may have already moved laterally.

As a result, DFIR has evolved into a live, iterative discipline. Investigators no longer rely on full disk acquisition as a starting point. Instead, they interrogate endpoints directly, retrieving only the artifacts that matter, when they matter.

From disk imaging to distributed DFIR

This shift represents a fundamental change in how investigations are performed.

Rather than centralizing evidence and analyzing it in isolation, investigators now distribute their questions across the environment. Each endpoint becomes a source of truth that can be queried in real time. Instead of waiting hours for data collection, analysts can validate hypotheses in seconds, pivot quickly, and refine their investigation as new evidence emerges.

This model enables a far more responsive workflow. Questions lead to queries, queries lead to insights, and insights drive the next steps of the investigation.

Osquery as a forensic interface

At the center of this model is Osquery, which exposes operating system (OS) artifacts as structured tables that can be queried using SQL. Processes, network connections, file activity, registry entries, and execution artifacts become immediately accessible without the need for heavyweight collection.

This abstraction transforms the OS into a queryable forensic dataset. Instead of navigating multiple tools or collecting large volumes of raw data, investigators can focus on answering specific questions with precision.

To support this, Elastic doesn't just integrate Osquery Manager, but we also build our own Osquery extensions to cover critical forensic artifacts that aren’t natively available. We make these extensions available within Elastic Security and contribute them back to the community. This includes visibility into areas such as browser history, AmCache, and jumplists, enabling deeper insight into user activity and execution patterns directly from the endpoint. We have contributed to Osquery with YARA memory scanning and OpenHandles too.The Osquery results are automatically stored in an Elasticsearch index and can easily be mapped to the Elastic Common Schema (ECS).

Beyond individual live queries, Elastic also provides out-of-the-box Osquery curated queries designed for forensic investigations, also mapped to ECS. These queries target the forensic artifacts that matter most during an investigation, such as Prefetch files that prove execution, Shimcache entries that confirm a binary existed on disk, registry keys that expose persistence mechanisms, and scheduled tasks that reveal attacker footholds.

From alert triaging to forensic reconstruction

Alerts are often the entry point into an investigation, but in a modern security operations center (SOC), they signify active defense. Elastic Defend provides this first line of active protection. This native Elastic Endpoint Security integration operates at the kernel level for deep visibility and enforcement, consistently earning top AV-Comparatives scores. Beyond alerts, Elastic Defend provides continuous enforcement, stopping threats like ransomware, malware, and in-memory exploits, using advanced behavioral preventions. While investigations begin with a signal, damage is already mitigated.

However, once a threat is neutralized, the key critical question remains: What actually happened?

This is where investigating with Osquery becomes essential. While Elastic Defend neutralizes the threat and captures the real-time telemetry, Osquery acts as your deep-dive forensic interface. It allows you to interrogate the endpoint for specific, high-fidelity artifacts, such as execution history in the Shimcache or manual navigation in Shellbags, to reconstruct a definitive timeline with evidence that goes beyond telemetry.

Together, Elastic Defend and Osquery form a complementary system that spans the full detection and response lifecycle. One provides continuous visibility and alerting; the other delivers the forensic depth required to investigate and validate those alerts. This combination allows analysts to move easily from detection to investigation, bridging the gap between signal and understanding.

Hunts: Operationalizing forensic and threat hunting investigations

As investigations progress, many of the same questions are repeatedly asked across different incidents. Rather than rebuilding queries each time, these can be standardized into reusable hunts.

Apart from curated queries, Elastic also provides curated Osquery packs aligned with common attacker tactics and techniques. These packs can be scheduled and allow analysts to quickly validate suspicious process execution, identify potential defense evasion behavior, and detect signs of lateral movement without writing queries from scratch.

In this scenario, hunts enable the investigation to expand beyond a single host. Analysts can rapidly determine whether similar execution patterns or indicators exist elsewhere in the environment, significantly accelerating the investigation process.

Scaling the investigation

Once key indicators such as domains or file hashes are identified, the investigation can be extended across the entire environment. Queries used for validation can be reused to identify similar activity on other endpoints.

This approach allows analysts to determine the scope of the incident, identify additional affected systems, and prioritize response efforts based on impact. Osquery, combined with Elastic across the environment, enables centralized query execution and fleet-wide forensics investigations.

From investigation to response

Up to this point, the focus has been on understanding what happened. Modern DFIR, however, requires the ability to act on those findings immediately.

By combining Osquery with Elastic Defend, investigators can move directly from analysis to response within the same workflow.

Once malicious execution is confirmed, the affected host can be isolated to prevent further communication and reduce the risk of lateral movement. In situations requiring deeper analysis, investigators can also collect a memory dump from the endpoint.

This memory dump can be downloaded and analyzed using external tools, such as Volatility, enabling further investigation of in-memory activity that may not be visible through traditional artifacts.

The Osquery and Elastic Defend combination allows analysts to move easily from detection to investigation to response, reducing friction and accelerating the overall DFIR process.

Detection with Osquery: From telemetry to signal

While Osquery is often used for live investigations, it also plays an important role in detection. When executed through scheduled packs, Osquery continuously collects endpoint data that can be used within Elastic Security to create SIEM detection rules. The results of these queries are indexed in logs-Osquery_manager.result*, making them searchable and usable as a detection data source.

Each query execution is identified by the action.id field. For scheduled packs, this follows a consistent naming convention: pack_{pack_name}_{query_name}. This allows analysts to reference specific queries when building detection logic, effectively turning Osquery packs into reusable detection building blocks.

This creates a natural feedback loop between investigation and detection. Queries initially used during forensic analysis can be operationalized into scheduled packs, continuously running across the environment and surfacing suspicious behavior automatically, bridging the gap between reactive investigation and proactive detection. Moreover, Osquery can be run directly from alerts, as part of investigation guides and as a response action in a detection rule.

Investigation scenario: From malicious alert to root cause

Consider a scenario where a user receives a phishing email offering a “100% discount” through a shared download link. The message appears convincing enough to prompt interaction, leading the user to download a file from the provided link.

Shortly after, Elastic Defend triggers an alert indicating that malware execution was detected and terminated. The payload is identified as Mimikatz, a well-known tool used for credential access.

At this stage, the immediate threat has been blocked, but key questions remain unanswered. How did the file reach the endpoint? Was it executed by the user? Was this an isolated event or part of a broader attack?

Detection provides the signal but not the full story.

To understand the root cause, the investigation shifts to Osquery.

The first step is to identify how the file was introduced onto the system. Since the initial vector is a phishing link, browser artifacts provide a natural starting point. We’ll use the suspicious browser history query that removes all possible false positives from the Elastic browser history table.

This query helps identify whether the user accessed a suspicious link consistent with the phishing lure.

We see that the user lab1 accessed through Edge browser a link that, in theory, contains a discount zip file to be downloaded, and we can consider these findings as new indicators of compromise (IoCs).

In order to confirm whether the file was actually downloaded and therefore, the user clicked on the previous link, we can use the file table, checking for the presence of this zip file on disk, meaning the user clicked on that previous link. We’ll use the Elastic file query that also checks the file hash of that file on VirusTotal. We can see that this discount.zip file has a malicious reputation, being in reality Mimikatz.

Next, we validate whether a file was downloaded and executed as a result of that interaction. To determine whether the file was executed, we pivot into execution artifacts, such as Shimcache UserAssist, Shellbags, and Prefetch.

Shellbags clearly shows the drill-down behavior: The user didn't just open the folder; they navigated three levels deep into the x64 directory where the Mimikatz binary usually lives.

SELECT
  path,
  datetime(accessed_time, 'unixepoch') AS access_time
FROM shellbags
WHERE path LIKE '%discount%';

The shimcache tracks every executable that has been "seen" by the OS for compatibility purposes. Even if the file was never actually run, its presence here proves it existed in that path.

SELECT
  path,
  datetime(modified_time, 'unixepoch') AS last_run_human_readable,
  modified_time AS raw_timestamp
FROM shimcache
WHERE path LIKE '%discount%'
  OR path LIKE '%mimikatz%';

NOTE: The "1970" date in the raw_timestamp column is a known forensics community issue. It results from a unit mismatch: Osquery stores timestamps in Unix epoch seconds, but the UI interprets this value as milliseconds. This calculation error compresses 56 years into roughly 20 days, causing the date to display as late January 1970 instead of April 2026. For forensic accuracy, the last_run_human_readable column remains the authoritative record, as it was correctly converted using second-based logic in the SQL query to reflect the true execution timeline.

To verify whether the user manually executed it, the userassist table is perfect. It tracks GUI-based execution (files launched via Windows Explorer).

SELECT
  path,
  count,
  datetime(last_execution_time, 'unixepoch') AS last_run_human_readable
FROM userassist
WHERE path LIKE '%discount%'
  OR path LIKE '%mimikatz%';

Prefetch is the black box that proves an application was actually launched. Analyzing the prefetch, we can get a timeline of the events, identifying that the root cause was a malicious phishing email.

SELECT
  filename,
  run_count,
  datetime(last_run_time, 'unixepoch') AS last_run_utc,
  last_run_time AS raw_timestamp
FROM prefetch
WHERE (
  filename LIKE 'OLK.EXE%' OR
  filename LIKE 'MSEDGE%' OR
  filename LIKE 'MIMIKATZ%'
)
AND last_run_time BETWEEN 1775815200 AND 1775822400
ORDER BY last_run_time ASC;

The forensic evidence confirms a linear attack path when the user lab1 initiated the new Outlook client, evidenced by the simultaneous execution of OLK.EXE and its integrated web engine, MSEDGEWEBVIEW2.EXE. This was immediately followed by MSEDGE.EXE, indicating the browser was summoned to handle the phishing redirect and download. The trail turns from automated activity to manual intent where Shellbags recorded the user deliberately navigating the extracted discount folder in their Downloads directory. This window of manual interaction eventually culminated in the final execution of MIMIKATZ.EXE. The 26-minute gap between the Shellbag entry (manual folder access) and the Prefetch entry (Mimikatz execution) is forensically consistent with a human-in-the-loop (HITL) attack scenario, where the user reads the email, clicks the link, waits for the download, extracts the zip, looks around the folder (Shellbags at 11:09), and finally works up the courage (or curiosity) to double-click the .exe.

Transform forensics to investigate and respond at scale

Twenty-six minutes. That's how long it took a user to go from opening a phishing email to executing Mimikatz. And it took us less time than that to reconstruct the entire attack chain, without a disk image, without a dedicated forensic workstation, and without leaving Elastic.

That's what scalable DFIR looks like in practice: not a process change, not a platform migration, but the ability to ask the right question of the right endpoint at the right moment and to get an answer before the attacker takes their next step.

The investigation never stops. Neither should your forensics.

Forensics is now essential for large-scale investigation and response, moving beyond being a mere post-incident activity. The evolution of forensics at Elastic continues, with our next phase focusing on incorporating automation and AI. Get ready to unlock the full power of forensics by combining it with workflows and agentic AI, we'll be diving into this topic in an upcoming blog post. Stay tuned!

Get started with Elastic Security

Start your free trial of Elastic Security today and experience the benefits of Elastic Defend and Osquery. Improve your forensics skills by enhancing your threat detection capabilities and gaining deeper visibility into potential threats before they escalate.

Frequently Asked Questions

Q: How do I perform forensic investigations at scale without disk imaging? A: Elastic Security combines Osquery and Elastic Defend to enable distributed, query-driven forensics across your entire fleet. Osquery exposes OS artifacts as SQL-queryable tables, so investigators can retrieve execution history, file activity, and registry entries from thousands of endpoints in real time without collecting full disk images.

Q: How do I reconstruct an attack timeline using Osquery? A: Elastic Security's Osquery integration gives you access to execution artifacts like Prefetch, Shimcache, UserAssist, and Shellbags as queryable tables. By chaining queries across these sources you can reconstruct the full sequence of user and attacker actions, including file downloads, folder navigation, and binary execution, without a forensic workstation.

Q: How does Osquery integrate with Elastic Security for incident response? A: Elastic Security includes Osquery Manager natively, with curated forensic queries and packs mapped to ECS. Results are indexed automatically, making them searchable alongside alert data and usable as detection rule inputs. Osquery can also be run directly from alerts, investigation guides, and detection rule response actions.

Q: Can I detect threats with Osquery in addition to investigating them? A: Yes. Scheduled Osquery packs continuously collect endpoint data that Elastic Security indexes under logs-osquery_manager.result*, which can be used as a detection data source for SIEM rules. Queries developed during forensic investigations can be operationalized into scheduled packs, creating a feedback loop between reactive investigation and proactive detection.