Detection rules › Kusto

Claroty - Multiple failed logins by user

Status
available
Severity
high
Time window
5m
Group by
SrcUsername
Source
github.com/Azure/Azure-Sentinel

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

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)
Threshold
gt 5

Stage 7: where

| where FailedLogins > threshold

Stage 8: extend

| extend AccountCustomEntity = SrcUsername

Exclusions

Top-level NOT(...) conjuncts: predicates this rule actively suppresses.

FieldKindExcluded values
EventTypematchsucceeded

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.

FieldKindValues
EventTypematch
  • Login to SRA transforms: term
FailedLoginsgt
  • 5 transforms: cased
SrcUsernameis_not_null
  • (no value, null check)

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.

FieldSource
FailedLoginssummarize
SrcUsernamesummarize
AccountCustomEntityextend