Introducing the SOCSimulator Query Tab: Practice KQL in Your Browser

Introducing the SOCSimulator Query tab, a KQL editor that runs against the logs of the operation you have open. It runs in your browser, needs nothing to set up, and the tables it exposes use the same names and columns you will meet at work.

Until now, a SOCSimulator operation gave you the evidence and left you to read it. The Query tab lets you interrogate it. It is the closest thing to a production log workspace you can practice in without owning one, with an incident already loaded and a question already waiting.

The Query tab gives you:

Real schemas. Tables use the names and columns analysts work with in real SOC tooling: SecurityEvent and SigninLogs for events and sign-ins, DeviceProcessEvents and DeviceNetworkEvents for endpoint activity, plus CommonSecurityLog, DnsEvents and Syslog. A query you write here reads the way it would at work.

Real incidents. Every operation is an investigation with consistent hosts, accounts, addresses and a timeline. You are not querying random rows; you are following an intrusion across them.

No setup. The engine runs in your browser. There is no workspace to provision, no data to ingest and nothing to pay a cloud provider for.

Honest limits. It is our own query engine. It covers the operators that triage depends on, and it tells you when you step outside them. More on that below.

What is in the tab

Open any operation with log data and switch to the Query tab. The editor sits next to a schema browser that groups the tables by SOCSimulator product (SIEM, endpoint, firewall) and lists every column, so you never guess a name.

• 20 starter queries give you a first move. Each one is offered only when the operation has data it can match, so you never click a starter and get zero rows.
• Time controls let you pick a window (last hour, last 24 hours, last 7 days, all time) or set an explicit range, the same discipline a real table with months of data demands.
• Multiple query tabs let you park one hypothesis while you test another.
• A results table shows the rows and columns each query returns.

A starter is a good place to see the style. This is the opening move of a brute-force triage:

SecurityEvent
| where EventID == 4625
| summarize FailedAttempts = count() by IpAddress, Account
| sort by FailedAttempts desc
| take 10

It answers which source addresses failed the most logons, against which accounts. In an operation, the answer is a specific address you then follow into the next table.

The same question, in a different operation

An incident on a Windows server and an incident on a Linux host do not produce the same telemetry, and the Query tab does not pretend they do. Tables appear only when the operation has rows for them: a Linux-only operation has no SecurityEvent, and a Windows-only operation has no Syslog.

Ask both operations the same question, "who has been failing to log in?", and the query changes with the evidence.

In a Windows operation, the answer is a column:

SecurityEvent
| where EventID == 4625
| summarize Failures = count() by Account, IpAddress
| sort by Failures desc
| take 25

In a Linux operation, the answer is inside the log line, so you search the message:

Syslog
| where SyslogMessage contains "Failed password"
| summarize Failures = count() by Computer, ProcessName
| sort by Failures desc
| take 25

Same intent, two schemas. That difference is the skill, and it is the one a cheat sheet cannot teach.

Then follow the suspicious host into the endpoint tables. Parent and child process pairs by frequency make a rare pair stand out:

DeviceProcessEvents
| summarize Spawns = count() by InitiatingProcessFileName, FileName
| sort by Spawns desc
| take 25

An Office application spawning a shell or script host sits at the bottom of that list, not the top. If you want each operator explained one at a time, start with our Kusto Query Language tutorial.

What it costs

The console is free. Pro adds the parts that only pay off across sessions.

We put the line at persistence on purpose. KQL is a skill most SOC job listings ask for, and the basics should not sit behind a wall.

What it does not do

The Query tab runs on our own engine, and you should know where the edges are before you rely on it.

• It runs on our own engine, in your browser. It supports the operators and functions that cover most triage work, not the whole language.¹
• When you use a function it does not support, the console names the function and suggests ones it does, instead of returning nothing.
• It queries the operation's data, not your production environment. It is a place to build the habit, not a replacement for the consoles you use at work.
• Confirm edge-case behavior against the official KQL documentation before you ship a detection rule you drafted here.

Getting started

Open an operation with log data, switch to the Query tab, and run take 10 on the first table in the schema browser before you write anything else. Read the real values, form a hypothesis from the alert, then build the query one pipe at a time.

New to the language? Read the KQL tutorial first. Working toward a role? See what SOC analysts open first at each tier to find where KQL sits in the day. Pair the tab with the SIEM practice operations and you have what a production workspace would give you, minus the setup: data, a question, and a prompt.

Footnotes

¹ Tables are populated from each operation's data and follow the operation's operating systems and sources, so the set of tables you see differs from operation to operation. Some columns that exist in the real schemas are not populated here when the operation's source has no equivalent field.