Scaling DFIR with Osquery in Elastic Security: A Live Query Playbook

Introduction

Traditional Digital Forensics and Incident Response (DFIR) is often bottlenecked by the "acquire first, analyze later" model. Imaging an endpoint's disk takes hours, introduces significant operational downtime, and creates massive data backlogs for analysts. In a high-velocity intrusion, this latency is a luxury defenders cannot afford.

The integration of Osquery directly into Elastic Security (via Elastic Agent and Fleet) represents a paradigm shift. It allows SOC analysts and IR teams to perform distributed, real-time forensics across thousands of endpoints instantly. Instead of pulling a disk image, you query the live state of the filesystem, process table, and kernel modules. This capability transforms every endpoint into a live sensor, drastically reducing the time-to-triage and enabling rapid containment without taking systems offline.

Technical Analysis

Affected Components & Platform

• Platform: Elastic Security (Kibana, Fleet, Elastic Agent) with Osquery integration enabled.
• Underlying Tech: Osquery (SQL-powered endpoint instrumentation).
• Infrastructure: Elastic Agent versions that bundle Osquery (typically version 7.10+ / 8.x).

Mechanism of Action

This approach leverages the Elastic Agent which bundles the Osquery core. Instead of requiring a standalone Osquery deployment, analysts utilize the Live Query capability within the Elastic Security UI or API.

• Execution Flow: Analysts write SQL-like queries targeting specific Osquery tables (e.g., processes, file, socket, crontab, startup_items). These queries are pushed via Fleet to the target agents.
• Data Retrieval: Agents execute the query against the live OS state and return the results immediately to the Elastic Security app.
• Forensic Value: This enables the reconstruction of the attack chain—identifying malicious parent-child process relationships, persistence mechanisms established in launchd or Scheduled Tasks, and file modifications in sensitive directories like /tmp or %APPDATA%.

Exploitation Status & Relevance

While this news item discusses a defensive capability (methodology) rather than a specific CVE exploit, it addresses the operational gap exploited by adversaries: ** dwell time**. Adversaries rely on the friction of traditional DFIR to maintain persistence. By adopting this methodology, defenders neutralize the time advantage of threat actors. This technique is immediately applicable to active incidents involving ransomware, eavesdropping, or unauthorized access.

Detection & Response

The following detection content is designed to complement the Osquery hunts described in the Elastic guide. These rules utilize standard EDR telemetry (equivalent to Osquery tables) to detect the suspicious behaviors that would trigger a Live DFIR investigation.

SIGMA Rules

---
title: Potential Web Shell via Suspicious Parent-Child Process
id: 3a0b1c92-d8e4-4f5a-9b1a-2c3d4e5f6a7b
status: experimental
description: Detects suspicious processes spawned by web server processes (e.g., Apache, Nginx, IIS) often indicative of web shell activity or exploitation.
references:
  - https://attack.mitre.org/techniques/T1505/003/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.execution
  - attack.t1505.003
logsource:
  category: process_creation
  product: windows
detection:
  selection:
    ParentProcessName|endswith:
      - '\w3wp.exe'
      - '\httpd.exe'
      - '\nginx.exe'
    Image|endswith:
      - '\cmd.exe'
      - '\powershell.exe'
      - '\pwsh.exe'
  condition: selection
falsepositives:
  - Legitimate administrative scripts triggered by web applications
level: high
---
title: Linux Crontab Persistence via Direct File Modification
id: 4b1c2d03-e9f5-5a6b-0c2b-3d4e5f6a7b8c
status: experimental
description: Detects modifications to system or user crontab files, a common persistence mechanism on Linux endpoints.
references:
  - https://attack.mitre.org/techniques/T1053/003/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.persistence
  - attack.t1053.003
logsource:
  category: file_event
  product: linux
detection:
  selection:
    TargetFilename|contains:
      - '/etc/crontab'
      - '/etc/cron.d/'
      - '/var/spool/cron/'
  condition: selection
falsepositives:
  - Legitimate system administration tasks
level: medium

KQL (Microsoft Sentinel / Defender)

// Hunt for processes spawned by common web servers often associated with web shells
DeviceProcessEvents  
| where Timestamp >= ago(24h)  
| where InitiatingProcessFileName in~ ('httpd', 'apache2', 'nginx', 'w3wp.exe', 'java')  
| where FileName in~ ('cmd.exe', 'powershell.exe', 'bash', 'sh', 'python', 'perl')  
| project Timestamp, DeviceName, AccountName, InitiatingProcessFileName, FileName, ProcessCommandLine, FolderPath  
| extend FullProcessChain = strcat(InitiatingProcessFileName, ' -> ', FileName)  
| order by Timestamp desc

Velociraptor VQL

-- Hunt for processes with suspicious arguments often used in lateral movement or execution
SELECT Pid, Name, Exe, CommandLine, Username
FROM pslist()
WHERE CommandLine =~ '(?i)curl.*http.*|wget.*http.*|powershell.*-enc.*|bash.*-i.*>& /dev/tcp/'
   OR Name =~ 'sh$'

Remediation Script (Bash)

#!/bin/bash
# Remediates specific suspicious persistence mechanisms identified during Osquery hunts
# This script checks and cleans common web shell paths and crontabs

LOG_FILE="/var/log/osquery_remediation.log"
echo "Starting remediation: $(date)" >> $LOG_FILE

# 1. Check for common web shell locations (example from /var/www/html)
WEB_DIR="/var/www/html"
if [ -d "$WEB_DIR" ]; then
    echo "Scanning $WEB_DIR for suspicious PHP files..." >> $LOG_FILE
    # Find PHP files modified in the last 24 hours with base64 content or common shell names
    find $WEB_DIR -name "*.php" -mtime -1 -exec grep -l "eval(base64_decode" {} \; >> $LOG_FILE 2>/dev/null
    # Note: Actual quarantine/quarantine logic should be added based on findings
fi

# 2. Check for suspicious crontab entries
for user in $(cut -f1 -d: /etc/passwd); do
    echo "Checking crontab for user $user" >> $LOG_FILE
    crontab -u $user -l 2>/dev/null | grep -E "wget.*sh|curl.*sh|bash -i" >> $LOG_FILE && echo "Suspicious crontab found for $user" >> $LOG_FILE
done

echo "Remediation script completed." >> $LOG_FILE

Remediation

Implementing this DFIR methodology requires proper configuration of the Elastic Stack. Use the following steps to ensure your environment is ready for live forensic response:

1. Update Elastic Agents: Ensure all Elastic Agents are updated to the latest version to support the newest Osquery tables and Fleet integration.
2. Enable Live Queries: In the Kibana Fleet Settings, ensure that "Live Query" is enabled and that the appropriate policies allow ad-hoc queries for your security team.
3. Validate Access Control: Assign the elastic_security_admin or appropriate custom roles to your SOC analysts to execute Live Queries, ensuring least privilege principles are maintained.
4. Create Hunt Playbooks: Pre-authorize and save critical Osquery queries (e.g., SELECT * FROM listening_ports; or SELECT * FROM file WHERE path LIKE '/tmp/%';) as "Saved Queries" in Elastic Security for rapid deployment during an incident.

Official Documentation:

• Elastic Security Labs: DFIR with Osquery
• Elastic Osquery Integration Guide

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub