Detection rules › Kusto
Failed sign-ins into LastPass due to MFA
'This rule will check if a sign-in failed into LastPass due to MFA. An incident can indicate the potential brute forcing of a LastPass account. The use of MFA is identified by combining the sign-in logs, this rule assumes LastPass is federated to Entra ID.'
MITRE ATT&CK coverage
| Tactic | Techniques |
|---|---|
| Initial Access | T1078 Valid Accounts, T1190 Exploit Public-Facing Application |
Rules detecting the same action
Other rules on this platform that filter on the same API call or operation.
Rule body kusto
id: 760b8467-e6cc-4006-9149-5696845c1a54
name: Failed sign-ins into LastPass due to MFA
description: |
'This rule will check if a sign-in failed into LastPass due to MFA.
An incident can indicate the potential brute forcing of a LastPass account.
The use of MFA is identified by combining the sign-in logs, this rule assumes LastPass is federated to Entra ID.'
severity: Low
status: Available
requiredDataConnectors:
- connectorId: LastPass
dataTypes:
- LastPassNativePoller_CL
- connectorId: AzureActiveDirectory
dataTypes:
- SigninLogs
queryFrequency: 1d
queryPeriod: 1d
triggerOperator: gt
triggerThreshold: 0
eventGroupingSettings:
aggregationKind: AlertPerResult
tactics:
- InitialAccess
relevantTechniques:
- T1078
- T1190
query: |
LastPassNativePoller_CL
| where Action_s == "Log in"
| join (SigninLogs | where AppDisplayName == "LastPass Enterprise") on $left.IP_Address_s == $right.IPAddress and $left.Username_s == $right.UserPrincipalName
| where ResultType in (50074, 50076)
| extend AccountCustomEntity = Username_s, IPCustomEntity = IP_Address_s
entityMappings:
- entityType: Account
fieldMappings:
- identifier: Name
columnName: AccountCustomEntity
- entityType: IP
fieldMappings:
- identifier: Address
columnName: IPCustomEntity
version: 1.0.1
kind: Scheduled
Stages and Predicates
Stage 1: source
LastPassNativePoller_CL
Stage 2: where
| where Action_s == "Log in"
Stage 3: join
| join (SigninLogs | where AppDisplayName == "LastPass Enterprise") on $left.IP_Address_s == $right.IPAddress and $left.Username_s == $right.UserPrincipalName
Stage 4: where
| where ResultType in (50074, 50076)
Stage 5: extend
| extend AccountCustomEntity = Username_s, IPCustomEntity = IP_Address_s
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 |
|---|---|---|
Action_s | eq |
|
AppDisplayName | eq |
|
ResultType | in |
|
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 |
|---|---|
AccountCustomEntity | extend |
IPCustomEntity | extend |