AN1337: Analytic 1337
Authentication failures across different accounts using a repeated or similar password via SSH or PAM stack within a short window
Analyst context for executives and security teams
This analytic is about spotting a common identity risk signal on Linux systems: multiple authentication failures against different accounts where the same or similar password appears to be used through SSH or the PAM stack in a short time window. For leaders, the value is not the analytic name itself, but whether the organization can prove it sees concentrated password-guessing activity before it becomes an access or incident-response problem.
Executive priority
Prioritize this as an identity and Linux monitoring readiness question: do critical Linux servers, remote access paths, and PAM-backed services produce usable authentication evidence, and can the SOC correlate failures across accounts quickly enough to support containment decisions? It is also useful compliance evidence for access monitoring and incident detection, but the supplied ATT&CK object does not provide impact, attribution, or active exploitation context.
Technical view
Validate collection and correlation for Linux SSH and PAM authentication failures. The key behavior is a short-window pattern of failures across different accounts where the attempted password is repeated or similar. Because no official detection logic is supplied, teams should define local thresholds, time windows, account-count criteria, and similarity handling based on normal authentication patterns and log availability.
Likely telemetry
- Linux authentication logs from SSH services
- PAM authentication failure events
- User/account identifiers involved in failed logons
- Source host or network origin where available in authentication logs
- Timestamps sufficient for short-window correlation
Detection direction
- Confirm Linux SSH and PAM failure logs are collected from in-scope systems and retained centrally.
- Correlate failed authentications across multiple different accounts within a short time window.
- Tune thresholds against normal administrative activity, misconfigured automation, scanners, and shared jump-host behavior to reduce false positives.
- Validate whether logs expose enough detail to compare repeated or similar password attempts; many environments may not log attempted password values for security reasons.
- Use source, target host, account spread, and timing to prioritize triage, since no relationship context or ATT&CK tactic is supplied.
Mitigation priorities
- Ensure SSH and PAM authentication logging is enabled and forwarded from critical Linux systems.
- Review access controls for externally reachable or high-value Linux hosts before relying on detection alone.
- Apply account lockout, rate limiting, or equivalent authentication abuse protections where operationally appropriate.
- Harden remote access paths and reduce unnecessary SSH exposure.
- Document detection coverage and response playbooks for Linux authentication-failure clusters as compliance and incident-readiness evidence.
Analyst notes and limits
This is a detection analytic object, not a technique description. Its practical value is in validating whether the SOC can observe and correlate Linux SSH/PAM authentication failures across accounts. Because relationships and official detection logic are not supplied, local engineering decisions are required for thresholds, time windows, and triage severity.
The supplied ATT&CK fields include no tactics, no relationships, and no official detection implementation. The object supports Linux, SSH, and PAM-stack authentication-failure analysis only. It does not support claims about specific adversaries, active exploitation, business impact, or guaranteed detection coverage.
Analytic 1337
Authentication failures across different accounts using a repeated or similar password via SSH or PAM stack within a short window
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 | 249baf17e7ad… |
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 AN1337Open 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.