AN1284: Analytic 1284
Monitoring for SSH logins from default accounts such as 'root', especially when login is via password and not key-based authentication.
Analyst context for executives and security teams
This analytic focuses on a high-value Linux access pattern: SSH logins to default accounts such as root, especially when password-based rather than key-based. For leaders, the practical issue is not just “someone logged in,” but whether privileged remote access is being used in a way that bypasses expected identity controls, weakens accountability, and increases incident response urgency.
Executive priority
Prioritize this as an identity and operational resilience control point for Linux environments. Root SSH access can concentrate risk because it may reduce user-level attribution and can provide immediate administrative capability. Security leaders should ask whether password-based SSH for default accounts is allowed, where exceptions exist, whether those exceptions are documented, and whether SOC teams can prove they receive and review the relevant login evidence.
Technical view
For SOC, detection engineering, and IR teams, validate monitoring for SSH authentication events on Linux systems, with emphasis on successful logins to default accounts such as root and whether authentication used password versus key-based methods. Because no ATT&CK detection logic or relationship context is supplied, implementation should be environment-specific: establish expected administrative access patterns, identify systems where direct root SSH is legitimate or prohibited, and tune alerts around success events, password authentication, source context, and exception lists.
Likely telemetry
- Linux SSH authentication logs showing successful and failed login attempts
- Username/account fields, especially root or other default administrative accounts
- Authentication method indicators where available, such as password versus public key
- Source IP address, hostname, or network location for SSH sessions
- Timestamp and target host information for administrative access review
Detection direction
- Confirm that Linux SSH authentication logs are collected centrally and retained long enough for investigation and audit evidence.
- Create or validate detections for successful SSH logins to root or other default accounts, with higher attention when password authentication is used.
- Tune for approved administrative workflows to reduce false positives, such as known management hosts or documented break-glass procedures.
- Review blind spots where local logs are not forwarded, authentication method is not parsed, or asset inventory does not identify Linux SSH exposure.
- Use this analytic as a control validation question: can the SOC distinguish direct root password logins from normal key-based administrative access?
Mitigation priorities
- Restrict or disable direct SSH login to default privileged accounts where business operations allow.
- Prefer named administrative accounts with accountable privilege elevation over shared default account access.
- Reduce or eliminate password-based SSH authentication for privileged accounts in favor of stronger approved authentication methods.
- Document and monitor exceptions, including break-glass access paths.
- Ensure Linux SSH logging, central collection, and retention support incident response and compliance review.
Analyst notes and limits
The supplied object is a detection analytic for Linux focused on monitoring SSH logins from default accounts such as root, especially password-based logins. No tactics, ATT&CK relationships, or official detection logic were provided, so this take emphasizes defensive validation, telemetry readiness, and control governance rather than a specific ATT&CK technique mapping.
This assessment is limited to the official STIX fields, external reference, and stated description. There is no supplied relationship context, no official detection query, and no evidence of active exploitation, attribution, impact, or coverage. Local SSH configuration, identity model, logging quality, and administrative practices are required to determine priority and detection fidelity.
Analytic 1284
Monitoring for SSH logins from default accounts such as 'root', especially when login is via password and not key-based authentication.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.0 | Current bundle | e3a6ac576e54… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack AN1284Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.