Detection rules › Kusto
Claroty - Multiple failed logins by user
Detects multiple failed logins by the same user in Claroty SRA event logs. The rule looks for failed Login to SRA events, extracts the source username from the event message, and alerts when a user exceeds 5 failed logins within 5 minutes.
MITRE ATT&CK coverage
| Tactic | Techniques |
|---|---|
| Initial Access | T1133 External Remote Services, T1190 Exploit Public-Facing Application |
| Credential Access | T1110 Brute Force |
Rule body kusto
id: 4b5bb3fc-c690-4f54-9a74-016213d699b4
name: Claroty - Multiple failed logins by user
description: 'Detects multiple failed logins by the same user in Claroty SRA event logs. The rule looks for failed Login to
SRA events, extracts the source username from the event message, and alerts when a user exceeds 5 failed logins within 5
minutes.'
severity: High
status: Available
requiredDataConnectors:
- connectorId: CefAma
dataTypes:
- CommonSecurityLog
queryFrequency: 1h
queryPeriod: 1h
triggerOperator: gt
triggerThreshold: 0
tactics:
- CredentialAccess
- InitialAccess
relevantTechniques:
- T1110
- T1190
- T1133
query: |
let threshold = 5;
ClarotyEvent
| where EventType has 'Login to SRA'
| where EventType !has 'succeeded'
| extend SrcUsername = trim(' ', tostring(extract(@'User\s(.*?)\sfailed', 1, EventMessage)))
| where isnotempty(SrcUsername)
| summarize FailedLogins = count() by SrcUsername, bin(TimeGenerated, 5m)
| where FailedLogins > threshold
| extend AccountCustomEntity = SrcUsername
entityMappings:
- entityType: Account
fieldMappings:
- identifier: Name
columnName: AccountCustomEntity
alertDetailsOverride:
alertDisplayNameFormat: Claroty multiple failed logins for {{SrcUsername}}
alertDescriptionFormat: '{{FailedLogins}} failed logins for user {{SrcUsername}} exceeded the threshold in 5 minutes.'
version: 1.0.4
kind: Scheduled
Stages and Predicates
Parameters
let threshold = 5;
Stage 1: source
ClarotyEvent
Stage 2: where
| where EventType has 'Login to SRA'
Stage 3: where
| where EventType !has 'succeeded'
Stage 4: extend
| extend SrcUsername = trim(' ', tostring(extract(@'User\s(.*?)\sfailed', 1, EventMessage)))
Stage 5: where
| where isnotempty(SrcUsername)
Stage 6: summarize
| summarize FailedLogins = count() by SrcUsername, bin(TimeGenerated, 5m)
Stage 7: where
| where FailedLogins > threshold
Stage 8: extend
| extend AccountCustomEntity = SrcUsername
Exclusions
Top-level NOT(...) conjuncts: predicates this rule actively suppresses.
| Field | Kind | Excluded values |
|---|---|---|
EventType | match | succeeded |
Indicators
Each row is a field, operator, and value that the rule matches. The corpus column counts how many other rules in the catalog look for the same combination: high numbers point to widely-used, community-vetted indicators. Blank or 1 shows that the indicator is specific to this rule.
| Field | Kind | Values |
|---|---|---|
EventType | match |
|
FailedLogins | gt |
|
SrcUsername | is_not_null |
Output fields
Fields the rule emits when it matches. Chronicle authors list these in the outcome block; they appear on the detection and $risk_score drives alerting. Sentinel / Defender XDR rules build them up through project / summarize / extend stages. Sentinel maps these into alert fields via entityMappings and customDetails; Defender XDR custom detections surface them as alert fields directly.
| Field | Source |
|---|---|
FailedLogins | summarize |
SrcUsername | summarize |
AccountCustomEntity | extend |