AN1005: Analytic 1005
Repeated SSH, VPN, or RDP gateway authentication attempts from external IPs → subsequent successful logon → remote shell or lateral movement activity (e.g., scp/sftp).
Analyst context for executives and security teams
This analytic describes a high-value account access pattern: repeated external authentication attempts against remote access services, followed by a successful login and then remote shell or file-transfer activity. For leaders, the practical issue is not just failed logins; it is whether the organization can quickly distinguish routine login noise from a probable unauthorized session that may enable hands-on-keyboard activity or lateral movement on Linux-connected infrastructure.
Executive priority
Prioritize validation of remote access monitoring because SSH, VPN, and gateway logins are common business-critical entry points. The key business question is whether SOC and incident response teams can prove who logged in, from where, whether the login followed repeated failures, and what happened next. This supports incident triage, identity control assurance, audit evidence for access monitoring, and resilience planning for remote administration paths.
Technical view
For Linux-relevant environments, validate correlation across external-source authentication failures, subsequent successful logons, and post-login activity such as remote shell use or scp/sftp-style file transfer. Because the ATT&CK object provides no formal detection logic, teams should define local thresholds, time windows, trusted-source handling, and account/service context. The most useful validation is end-to-end: authentication event, source IP, user/account, asset, success after failures, session creation, and follow-on remote activity.
Likely telemetry
- Linux authentication logs for SSH and remote shell sessions
- VPN or remote access gateway authentication logs where applicable
- RDP gateway authentication logs where applicable to the monitored access path
- Source IP, geolocation or network ownership enrichment, and external/internal classification
- Successful and failed login events tied to account, host, and timestamp
Detection direction
- Correlate repeated external authentication failures with a later successful login for the same account, host, or source context.
- Tune thresholds and time windows to reduce noise from normal user mistakes, scanners, service accounts, and known administrative sources.
- Alert priority should increase when success is followed by remote shell activity, scp/sftp file transfer, or connections to additional internal systems.
- Validate that logging covers both failed and successful authentication; many environments collect failures but under-collect session and post-login evidence.
- Review blind spots around unmanaged Linux hosts, split VPN logging, NAT/shared IPs, incomplete identity mapping, and inconsistent time synchronization.
Mitigation priorities
- Ensure remote access paths require strong authentication and are limited to authorized users and sources where business requirements allow.
- Centralize and retain authentication, session, and file-transfer logs for Linux and remote access infrastructure.
- Review remote administration exposure and reduce unnecessary externally reachable services.
- Use account lockout, rate limiting, conditional access, or equivalent controls where appropriate to reduce repeated authentication attempts.
- Maintain incident response playbooks for successful login after repeated failures, including account validation, session review, host triage, and credential reset decisions.
Analyst notes and limits
This is a detection analytic object, not a technique description. The supplied ATT&CK fields identify a Linux platform and describe an authentication-to-post-login behavior pattern involving SSH, VPN, or RDP gateway access from external IPs. No tactics, relationships, mitigations, or official detection logic were provided, so the take focuses on defensive validation and telemetry requirements rather than asserting coverage or threat actor behavior.
Assessment is limited to the official description, platform field, external reference, and object metadata supplied. No relationship context, ATT&CK tactic mapping, data source list, or detection query was provided. Local architecture, remote access design, identity controls, and logging maturity are required to determine risk, alert thresholds, and investigation priority.
Analytic 1005
Repeated SSH, VPN, or RDP gateway authentication attempts from external IPs → subsequent successful logon → remote shell or lateral movement activity (e.g., scp/sftp).
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 | c611aa90033d… |
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 AN1005Open 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.