Skip to content

Glossary

WQL (WMI Query Language)

The SQL-like language WMI uses for data and event queries; event filters use it to describe the event that triggers a subscription.

WQL is the query language of WMI, a read-only subset of SQL. It comes in two main forms. Data queries read instances, for example SELECT * FROM Win32_Process. Event queries describe changes and are what an event filter stores in its Query property, with QueryLanguage set to WQL.

Event queries use two kinds of events. Intrinsic events (__InstanceCreationEvent, __InstanceModificationEvent, __InstanceDeletionEvent) report changes to instances of any class; TargetInstance is the instance concerned, and ISA restricts it to a class. When no provider reports such changes directly, WITHIN n makes WMI poll every n seconds. Extrinsic events, such as Win32_ProcessStartTrace, are raised by providers themselves. Timer events (__TimerEvent) fire on a WMI timer.

Why it matters in investigations

Reading the query tells you when a subscription fires, which you need to line up execution evidence with it. An uptime condition fires shortly after every boot, a logon session query at each sign-in, a process query when a given program starts. Queries also show intent: a filter that waits for a security tool to start, or for a removable drive, says a lot about the author.

Example

A filter that fires when a new logon session appears, polled every 15 seconds:

SELECT * FROM __InstanceCreationEvent WITHIN 15
WHERE TargetInstance ISA 'Win32_LogonSession'

An extrinsic alternative that fires when a given process starts, without polling:

SELECT * FROM Win32_ProcessStartTrace WHERE ProcessName = 'notepad.exe'

When you find either in a repository, correlate with the matching logons or process starts, and check which event consumer the filter is bound to.

WMI Parser displays each filter's WQL query next to the consumer it triggers. For the classic uptime trigger explained, read WMI event subscription persistence explained.