Kalos Cybersecurity LLC
Field guide

Osquery Windows Process-to-Network Correlation

Alerts to Answers Analyst Field Guide 05 - v20

Introduction

This analyst guide uses a live Osquery join to connect a Windows network socket to the process that owns it. The exercise demonstrates how endpoint and network observations can be correlated while preserving the limits of point-in-time evidence.

Purpose and Scope

Use the query on an instructor-approved Windows 11 endpoint after Osquery is installed and validated. The result supports triage and hypothesis development; it does not by itself establish historical activity or malicious intent.

Chapter and Lab Alignment

Alignment Placement
Primary chapter alignment Chapter 6 - Introduction to Threat Hunting
Supporting chapter alignment Chapter 7 - Digital Forensics and Incident Response
Lab alignment Primary: Labs 5 and 6. Supporting: endpoint-and-network comparison exercises.
Recommended point of use Run during live triage, record the query time, and corroborate findings with historical telemetry.

Objective

Use Osquery on Windows 11 to associate an active network socket with the process that owns it.

Query from PowerShell

Run from an instructor-approved Windows lab endpoint:

& "C:\Program Files\osquery\osqueryi.exe" `
  "SELECT p.pid, p.name, p.path, s.local_address, s.local_port, s.remote_address, s.remote_port, s.protocol
   FROM process_open_sockets AS s
   JOIN processes AS p ON s.pid = p.pid
   LIMIT 20;"

The PowerShell call operator (&) runs the quoted executable path. The trailing backtick continues the command on the next line.

How the Correlation Works

process_open_sockets supplies socket data; processes supplies process identity. Both tables expose a process ID (pid). The join:

JOIN processes AS p ON s.pid = p.pid

returns socket rows only when the process is still present at query time and its PID matches a row in processes.

Selected field Meaning
p.pid Process identifier used for correlation
p.name Process name
p.path Executable path, when available
s.local_address / s.local_port Local endpoint
s.remote_address / s.remote_port Remote endpoint
s.protocol Socket protocol value

Analyst Interpretation

The result is a point-in-time observation. A short-lived process or socket may disappear between event generation and query execution, and PID reuse means a PID alone is not durable historical identity.

Ask:

  • Is the process expected on this host?
  • Is its executable path consistent with the signed/approved application?
  • Is the remote address and port expected for the process?
  • Is the connection listening, established, or transient?
  • What historical telemetry can corroborate the live result?

Validation

  1. Run the query in an elevated PowerShell session.
  2. Confirm process and socket columns appear in the same row.
  3. Select one row and verify the PID locally with Get-Process -Id <pid> while the process still exists.
  4. Record the query time because the result represents current state, not historical evidence.

Knowledge Check

  1. Why is PID the join key?
  2. Why can a live Osquery result differ a few seconds later?
  3. What does the inner join omit?
  4. What additional evidence would establish historical process/network activity?

Technical References