Osquery Windows: Registry, Services, and WMI Visibility

The problem with osquery Windows coverage is not a lack of tables. It is a lack of questions precise enough to turn registry keys, services, and WMI data into decisions.

Windows spreads security truth across several stores. Installed software lives in package records and registry keys. Persistence hides in services, scheduled tasks, Run keys, and WMI subscriptions. Hardware trust comes from firmware, TPM, BitLocker, and Device Guard state. Osquery gives those stores a common SQL interface, but the interface does not decide what your fleet should look like. Your team still has to define normal, write the exception query, and assign the result.

That work is worth doing. The Verizon 2026 Data Breach Investigations Report, published in May 2026, found vulnerability exploitation caused 31 percent of breaches in its dataset. The same report found only 26 percent of critical vulnerabilities were fully remediated during 2025, with a median resolution time of 43 days. Inventory alone did not close that gap. Endpoint state has to reach an owner with enough context to act.

What can osquery Windows tables actually see?

Start with four evidence layers. Inventory tables tell you what exists. Configuration tables tell you how it starts and what controls it. Platform tables expose trust settings below the operating system. Event tables show activity that may disappear before a scheduled snapshot runs. The osquery tables guide covers the broader schema. On Windows, the useful distinction is not table count. It is whether you need current state or a record of change.

Current state is usually cheaper and easier to explain. The programs table lists software known to Windows installers. patches and windows_update_history describe update state.services shows the executable, account, start type, and current status for each service.registry exposes a constrained view into every hive. These tables answer questions such as “which service starts automatically from a user writable directory?” or “which machine has this policy value set differently from the approved baseline?”

Activity needs publishers and tighter volume control. Windows Event Log channels can populatewindows_events or purpose built tables such as powershell_events. ETW builds can add process and DNS lookup events. Those sources are useful when a process or lookup may last only seconds. They are also noisy. Schedule state first. Add events only for a written detection or investigation need.

How should you query the Windows registry with osquery?

The registry table is powerful because it requires scope. The official registry table schema exposes key, path, name, type, data, andmtime. A query without a useful key constraint is the wrong query. You are asking the agent to walk a tree that contains millions of possible values when the security question usually concerns one branch.

Run keys are the obvious starting point. This query returns machine level entries that launch when a user signs in. The doubled backslashes are JSON escaping in a query config. In the interactive shell, use single backslashes.

Do not alert because the query returns a row. Most organizations have approved Run entries. Build a baseline of names, publishers, and paths, then return only additions or changed data. If 8,000 hosts each return 12 approved entries every hour, that is 96,000 rows with no decision attached. A differential query that reports one new entry is cheaper to store and far easier to investigate.

Registry paths also make strong compliance checks because many policy values are binary. For example, query the exact policy key, return the configured data, and compare it with the approved value in your fleet manager or downstream rule. Keep the expected value beside the query in source control. A naked registry export is not evidence of compliance. Evidence needs a rule and a result.

Which Windows services deserve attention?

Services combine persistence, privilege, and executable path in one row. The official services table schema defines AUTO_START, DEMAND_START, and other start types, plus the service account and binary path. That makes it more useful than a list of service names.

Feed those rows into three checks. First, does the executable exist and have a trusted signature? Second, can a standard user write to its directory? Third, does the configured account match the privilege the service needs? A service that runs as LocalSystem from a user writable directory is urgent. A stopped vendor updater with an automatic start type is usually an operations issue. Same table, different consequence.

A practical join uses services.path to reach authenticode or file, but paths with quotes and arguments need cleaning before a direct join works. Do that normalization in a tested query or downstream transform. Do not pretend every service path is a bare executable. Windows service configuration is messy, and a query that silently drops paths creates false confidence.

Where does WMI fit in osquery Windows visibility?

WMI is a provider layer, not a magic table that answers every Windows question. Osquery ships focused WMI tables for facts such as BIOS settings, video hardware, security products, and persistence objects. Thewmi_bios_info table is deliberately small, with name and value columns. Query it to prove a firmware setting exists, then compare the result with the required platform baseline.

Persistent WMI subscriptions need a set, not one query. Review wmi_event_filters,wmi_script_event_consumers, wmi_cli_event_consumers, andwmi_filter_consumer_binding together. A filter says when something runs. A consumer says what runs. The binding connects them. Looking at only one side gives an investigator half a sentence.

According to the osquery release history, version 5.23.0, released April 25, 2026, widened WMI table access to theROOT\default namespace and added the Windows process_open_handles table. Then 5.23.1 shipped on June 24 as a security fix release for heap buffer overflows in the Windowsprocesses and authenticode tables. Those are material changes from the last 12 months. Pin a tested agent version and track it through osquery_info. The visibility agent is software too.

How do you turn Windows rows into an operating workflow?

Give every scheduled query four fields outside the SQL: an owner, an expected result, an urgency rule, and a response. “List all services” has none of them. “Return new automatic services outside Program Files, owned by Endpoint Engineering, page if the path is user writable, otherwise open a review ticket” can operate.

Use three cadences. Run cheap posture checks every few hours. Run heavier software and trust inventories once or twice a day. Keep event sources continuous, but filter them at collection. If six Windows queries each consume two analyst hours a week across triage and owner lookup, that is 12 hours. At a loaded labor cost of $90 an hour, weak query design burns $1,080 each week. The SQL is free. Ambiguous output is not.

The best alerts include the current row, the expected state, the prior state, and an exact next action. Artemes AI approaches this with deep endpoint context and AI driven analysis, so a raw finding is read against the host before remediation guidance is produced. You can build the same discipline with rules and human review. What matters is that collection ends in a decision, not a dashboard.

Version the query with the response. A registry policy check should name the approved value and the command or management action that restores it. A service finding should say whether the safe response is to disable the service, change its account, repair directory permissions, or replace the binary. The query author does not need permission to make every change, but the result must reach someone who does. Otherwise the security team keeps rediscovering the same condition and calling repetition coverage.

Roll out changes through a test ring. Ten lab hosts, then one business unit, then the fleet. Compare row count, query duration, and error count at every step. A query that returns 40 rows on a clean workstation and 40,000 on a domain controller needs a platform role filter, not a larger storage budget. Keep the prior query version available long enough to compare output. A silent result change is harder to diagnose than a failed query.

What are the common Windows failure modes?

• Queries return nothing because the table needs a constraint. Read the versioned table schema before treating an empty result as proof.
• Event tables stay empty because the publisher or channel is disabled. Check the osquery flags, Windows audit policy, channel name, and agent restart.
• Service paths fail to join. Quotes, environment variables, and command arguments must be normalized before a path lookup.
• One query runs on every platform. Separate Windows schedules from macOS and Linux schedules when the table shape or source differs.

Permissions cause the hardest false negatives. Osqueryd normally runs as SYSTEM, which can read far more than an interactive shell opened by a standard user. Test scheduled queries through the daemon path you will use in production. A query proven in an elevated shell has not proven the pipeline, schedule, or logger.

Frequently asked questions

Does osquery Windows replace PowerShell?

No. PowerShell is better for one time administration and remediation. Osquery is better for repeatable, fleet wide reads that share a schema with other operating systems and produce scheduled results.

Can osquery read every registry key?

It can query all major hives subject to process permissions, but it needs a key or path constraint and it does not expose HKEY_CURRENT_USER directly. Query the matching user hive underHKEY_USERS.

Does osquery collect Windows Event Logs?

Yes, when events are enabled and the desired channels are configured. PowerShell, DNS, process, and general Windows event sources have different flags and build requirements, so verify each publisher separately.

What should a Windows pilot query first?

Start with programs, patches, services, selected registry policy keys, BitLocker state, and osquery health. Add WMI persistence and event sources after the baseline results have owners.

The takeaway

Pick ten representative Windows hosts. Write one constrained query for registry persistence, one for automatic services, and one for platform trust. Define the expected result and owner before scheduling any of them. Watch the output for a week, remove rows that never lead to action, then scale. Osquery Windows visibility is useful when every returned row answers “who needs to do what now?” Everything else is inventory you will pay to store.

For installation and fleet patterns, use the osquery installation guide, the fleet management guide, and the complete osquery handbook. For the broader prioritization problem, our older analysis of why CVSS alone cannot set priorityexplains why endpoint evidence changes a finding.