Developer ToolsFree generatorPDF, Excel, Word exportManufacturing

KQL Query Generator for Failed Logon and Brute Force Detection

Most brute force and tampering activity leaves the same few Windows events behind. This generator fills in thresholds and time windows and returns six KQL queries you can paste into Microsoft Sentinel or Log Analytics.

Fill in

Lookback window

Failure threshold

Failures per source and computer before the row is returned.

Time bin for burst detection

Excluded internal scanner IP

Vulnerability scanner or monitoring host to leave out.

Privileged group name

Generated code

Download:

1. Brute force: many failures from one source

SecurityEvent
| where TimeGenerated > ago(24h)
| where EventID == 4625
| where IpAddress != "10.10.5.20"
| summarize Failures = count(), Accounts = dcount(TargetUserName), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated) by IpAddress, Computer
| where Failures >= 20
| order by Failures desc

2. Burst of failures in a short bin

SecurityEvent
| where TimeGenerated > ago(24h)
| where EventID == 4625
| summarize Failures = count() by IpAddress, TargetUserName, bin(TimeGenerated, 10m)
| where Failures >= 20
| order by TimeGenerated desc

3. Success after repeated failures

let failures = SecurityEvent
| where TimeGenerated > ago(24h)
| where EventID == 4625
| summarize Failed = count() by TargetUserName, IpAddress
| where Failed >= 20;
SecurityEvent
| where TimeGenerated > ago(24h)
| where EventID == 4624
| join kind=inner failures on TargetUserName, IpAddress
| project TimeGenerated, Computer, TargetUserName, IpAddress, LogonType, Failed

4. Audit log cleared

SecurityEvent
| where TimeGenerated > ago(24h)
| where EventID == 1102
| project TimeGenerated, Computer, SubjectUserName, SubjectDomainName

5. Member added to a privileged group

SecurityEvent
| where TimeGenerated > ago(24h)
| where EventID in (4728, 4732, 4756)
| where TargetUserName == "Domain Admins"
| project TimeGenerated, Computer, SubjectUserName, MemberName, TargetUserName

6. New service installed

Event
| where TimeGenerated > ago(24h)
| where EventLog == "System" and EventID == 7045
| project TimeGenerated, Computer, RenderedDescription

Assumes the Windows Security Events connector populates the SecurityEvent table, and that System events arrive in the Event table. Column names can differ by connector version and agent, so check the schema in your workspace and tune thresholds against a normal week before turning any query into an alert rule.

Detection tuning session

Optional session to tune these queries against your logs.

Optional. The tool and every export work without this. No spam.

How to use it

Choose a lookback window, a failure threshold per source and an excluded scanner address. Copy the queries into the Logs blade, run them against a normal week, and adjust the threshold until the output is a short list worth reading. Only then save them as scheduled analytics rules with an entity mapping for the account and host.

Run each query in the Logs blade first
Exclude known scanners and monitoring hosts
Map account and IP entities when saving rules

What each query catches

The first two find password guessing and spraying, either as a total per source or as bursts inside a time bin. The third joins failures to later successes, which is the signal that a guess worked. Queries four to six catch actions that follow a compromise: clearing logs, adding someone to a privileged group and installing a new service.

Tuning for a plant

Service accounts with stale passwords, misconfigured scanners and shared engineering logins create constant failures. Whitelist by account and source rather than raising the threshold for everything. Machines in remote plants with weak connectivity may deliver events late, so leave some slack in the window and the bin size.

Common mistakes

Alerting on every single failed logon floods the queue and teaches analysts to ignore it. Another error is skipping the table schema check, which makes a query return nothing and look like a clean result. Finally, remember that attackers using valid stolen credentials will not trigger failure based rules, so combine these with anomaly checks on logon time and location.

Frequently Asked Questions

Does this work in Splunk or Elastic?

The logic does, the syntax does not. KQL is specific to Azure Monitor, Sentinel and Defender. Use the same event IDs and thresholds and rewrite the query in SPL or EQL for those tools.

What threshold should I use?

There is no universal value. Measure a normal week, then set it above the busiest legitimate source. Twenty to fifty failures per source in a day is a typical starting range for a mid-size site.

Why use both the SecurityEvent and Event tables?

Security events such as 4625 come from the Security log connector into SecurityEvent. System log events such as 7045 are collected into the Event table when the System log is included in the data collection rule.

Can I use these as alert rules directly?

Yes after testing. Set the run frequency to match the lookback, map entities, and add a suppression window so one attacker does not generate hundreds of incidents.

If you want these detections tested against your own logs and tuned for plant behavior, Netray can help set them up with your SOC or MSSP.

Talk to an Expert Explore More Free Tools

Related Tools

Developer Tools

More Developer Tools tools

See all

Back to All Tools