AN1270: Analytic 1270
Burst of failed login attempts across VM instances using leaked credential pairs from single IP in public cloud environments
Analyst context for executives and security teams
AN1270 describes a cloud-focused detection analytic for spotting bursts of failed login attempts across virtual machine instances from a single IP address using leaked credential pairs. For leaders, the practical issue is not just failed logins; it is whether the organization can quickly recognize credential-stuffing style activity against IaaS workloads before it becomes unauthorized access, service disruption, or an incident-response escalation.
Executive priority
Treat this as a control-validation item for cloud security, identity readiness, and SOC visibility. Executives should ask whether failed authentication telemetry from IaaS-hosted VM instances is centrally collected, correlated across instances, and retained well enough to support incident decisions and audit evidence. Priority is highest where public cloud VMs expose remote access paths and where credential hygiene or leaked-credential monitoring is a known risk area.
Technical view
SOC and detection teams should validate whether they can correlate failed login events across multiple VM instances by source IP and time window in IaaS environments. Because ATT&CK does not provide an official detection implementation for this analytic, local tuning is required: define what constitutes a burst, account for legitimate administrative failures, and distinguish single-host brute-force noise from cross-instance activity. IR teams should ensure alerts preserve source IP, targeted VM identities, usernames or credential identifiers where available, timestamps, and cloud account/project/subscription context.
Likely telemetry
- IaaS VM operating system authentication logs showing failed login attempts
- Cloud provider activity or audit logs that identify VM instance, account/project/subscription, and network source context
- Remote access service logs where applicable, such as SSH or RDP authentication failures
- Network security telemetry showing repeated inbound connection attempts from the same public IP to multiple VM instances
- Central SIEM or log analytics data capable of correlating failed authentication across instances over time
Detection direction
- Validate cross-instance correlation, not only per-host failed-login thresholds.
- Tune burst thresholds and time windows to the organization’s normal administrative patterns.
- Include source IP aggregation while accounting for shared egress, VPN, jump hosts, scanners, and managed service provider access that may create false positives.
- Prioritize alerts where the same source IP attempts multiple credential pairs or targets multiple public-facing VM instances.
- Confirm logging coverage for all relevant IaaS VM fleets; unmanaged, ephemeral, or newly deployed instances are common blind spots.
Mitigation priorities
- Centralize and retain failed authentication logs from IaaS VM instances before relying on this analytic.
- Reduce public exposure of VM login services where possible and require controlled administrative access paths.
- Strengthen identity controls for VM access, including least privilege and strong authentication where supported by the environment.
- Use credential hygiene processes to reduce risk from leaked credential pairs, including rotation and removal of stale accounts.
- Prepare IR playbooks for suspected credential attack activity, including source IP review, targeted account review, and validation of any successful logins following the failure burst.
Analyst notes and limits
This object is a detection analytic, not a technique or campaign. The supplied ATT&CK fields identify the platform as IaaS and describe failed login bursts across VM instances from a single IP using leaked credential pairs. No tactics, relationships, aliases, labels, or official detection logic were supplied, so this take focuses on defensive validation and operational readiness rather than attribution or specific implementation.
The official detection field is not provided and no relationship context is supplied. Thresholds, event schemas, supported log sources, and false-positive patterns must be determined from the local cloud and VM environment. This summary does not assert active exploitation, attacker identity, or existing detection coverage.
Analytic 1270
Burst of failed login attempts across VM instances using leaked credential pairs from single IP in public cloud environments
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 | 6db8dc403ba1… |
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 AN1270Open 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.