Detection rules › Panther
Teleport SSH Auth Errors
A high volume of SSH errors could indicate a brute-force attack
MITRE ATT&CK coverage
| Tactic | Techniques |
|---|---|
| Credential Access | T1110 Brute Force |
Rule body yaml
AnalysisType: rule
Filename: teleport_auth_errors.py
RuleID: "Teleport.AuthErrors"
DisplayName: "Teleport SSH Auth Errors"
Enabled: true
LogTypes:
- Gravitational.TeleportAudit
Tags:
- SSH
- Credential Access:Brute Force
Severity: Medium
Reports:
MITRE ATT&CK:
- TA0006:T1110
Description: A high volume of SSH errors could indicate a brute-force attack
Threshold: 10
DedupPeriodMinutes: 15
Reference: https://goteleport.com/docs/management/admin/
Runbook: >
Check that the user making the failed requests legitimately tried logging in that many times.
SummaryAttributes:
- event
- code
- user
- program
- path
- return_code
- login
- server_id
- sid
Tests:
- Name: SSH Errors
ExpectedResult: true
Log:
{
"code": "T3007W",
"error": 'ssh: principal "jack" not in the set of valid principals for given certificate: ["ec2-user"]',
"event": "auth",
"success": false,
"time": "2020-08-13T18:39:42Z",
"uid": "53e474cc-db1c-45f1-a60d-b31239e20098",
"user": "panther",
}
- Name: Echo command
ExpectedResult: false
Log:
{
"argv": [],
"cgroup_id": 4294967537,
"code": "T4000I",
"ei": 15,
"event": "session.command",
"login": "root",
"namespace": "default",
"path": "/bin/echo",
"pid": 7143,
"ppid": 7115,
"program": "echo",
"return_code": 0,
"server_id": "e75992b4-9e27-456f-b1c9-7a32da83c661",
"sid": "8a3fc038-785b-43f3-8737-827b3e25fe5b",
"time": "2020-08-17T17:40:37.491Z",
"uid": "8eaf8f39-09d4-4a42-a22a-65163d2af702",
"user": "panther",
}
Detection logic
Condition
error is_not_null
event eq "auth"
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.
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 |
|---|
user |
cluster_name |