Detection rules › Kusto
VMware ESXi - Multiple Failed Shell Login via SSH
Identifies a failed ESXi Shell login via SSH in a short TimeFrame. This could be suspicious activity especially if this alert is seen triggering many times within a short time frame which could be evidence of a brute-force attack. TriggerThreshold can be adapted.
MITRE ATT&CK coverage
| Tactic | Techniques |
|---|---|
| Credential Access | T1110 Brute Force |
Rule body kusto
id: 22d177d5-588c-4f1a-a332-2695f52079bb
name: VMware ESXi - Multiple Failed Shell Login via SSH
description: |
Identifies a failed ESXi Shell login via SSH in a short TimeFrame. This could be suspicious activity especially if this alert is seen triggering many times within a short time frame which could be evidence of a brute-force attack. TriggerThreshold can be adapted.
severity: Medium
status: Available
requiredDataConnectors:
- connectorId: SyslogAma
datatypes:
- Syslog
queryFrequency: 10m
queryPeriod: 10m
triggerOperator: gt
triggerThreshold: 0
tactics:
- CredentialAccess
relevantTechniques:
- T1110
query: |
// To Adapt to your environment
let triggerThreshold = 10;
VMwareESXi
| where SyslogMessage has "sshd"
| where SyslogMessage contains "authentication failure"
| extend SrcUsername = extract(@'\[info\]\s+\[(.*?)\]', 1, SyslogMessage)
| extend DstHostname = extract(@'\[\d+\]\s+\[(.*?)\s+on', 1, SyslogMessage)
| extend SrcIpAddr = extract(@'\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})', 1, SyslogMessage)
| summarize make_set(SrcUsername),count() by SrcIpAddr,DstHostname
| where count_ >= triggerThreshold
| extend HostCustomEntity = DstHostname
entityMappings:
- entityType: Host
fieldMappings:
- identifier: FullName
columnName: HostCustomEntity
- entityType: IP
fieldMappings:
- identifier: Address
columnName: SrcIpAddr
version: 1.0.0
kind: Scheduled
Stages and Predicates
Parameters
let triggerThreshold = 10;
Stage 1: source
VMwareESXi
Stage 2: where
| where SyslogMessage has "sshd"
Stage 3: where
| where SyslogMessage contains "authentication failure"
Stage 4: extend (3 consecutive steps)
| extend SrcUsername = extract(@'\[info\]\s+\[(.*?)\]', 1, SyslogMessage)
| extend DstHostname = extract(@'\[\d+\]\s+\[(.*?)\s+on', 1, SyslogMessage)
| extend SrcIpAddr = extract(@'\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})', 1, SyslogMessage)
Stage 5: summarize
| summarize make_set(SrcUsername),count() by SrcIpAddr,DstHostname
Stage 6: where
| where count_ >= triggerThreshold
Stage 7: extend
| extend HostCustomEntity = DstHostname
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 |
|---|---|---|
SyslogMessage | contains |
|
SyslogMessage | match |
|
count_ | ge |
|
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 |
|---|---|
DstHostname | summarize |
SrcIpAddr | summarize |
HostCustomEntity | extend |