AN1267: Analytic 1267
Router/firewall/syslog logs showing authentication failures with unique usernames and reused credentials from same source IP
Analyst context for executives and security teams
This analytic is about spotting repeated authentication failures on routers, firewalls, or similar network devices where many different usernames are tried with the same reused credential from one source IP. For executives and security leaders, the value is that edge and network infrastructure accounts are high-leverage: weak monitoring here can delay discovery of attempts to gain administrative access to devices that protect business connectivity.
Executive priority
Prioritize this as a resilience and access-control validation item for network infrastructure. Leaders should ask whether router and firewall authentication logs are centrally collected, retained, reviewed, and usable during an incident. This also supports audit evidence for privileged access monitoring, especially where network devices are business-critical control points.
Technical view
SOC and detection teams should validate whether syslog or equivalent authentication logs from network devices include source IP, username, authentication outcome, and enough detail to identify repeated failures involving unique usernames and reused credentials from the same source IP. Because ATT&CK provides no separate detection logic here, teams need to define local thresholds, account for device-specific log formats, and test against known administrative activity.
Likely telemetry
- Router authentication failure logs
- Firewall authentication failure logs
- Network device syslog records
- Source IP address associated with failed logons
- Username attempted during authentication
Detection direction
- Correlate authentication failures from the same source IP across multiple unique usernames on network devices.
- Validate whether logs expose enough detail to infer reused credential attempts; many devices may not record credential material, so detection may rely on failure patterns rather than direct password visibility.
- Tune thresholds to avoid alerting on routine administrator mistakes, monitoring systems, vulnerability scanners, or misconfigured automation.
- Confirm coverage across all managed routers and firewalls, not only perimeter devices already sending syslog.
- Review retention and time synchronization so incident responders can reconstruct the sequence of attempts.
Mitigation priorities
- Ensure centralized logging is enabled for routers and firewalls and that authentication events are retained for investigation and compliance evidence.
- Harden administrative access to network devices with strong identity controls, restricted management access paths, and least-privilege administrator accounts.
- Review failed-login alerting procedures so repeated attempts against network infrastructure trigger timely triage.
- Maintain an inventory of network devices and confirm each device is covered by logging, access control, and incident response runbooks.
- Use local investigation to determine whether observed failures reflect benign administration, misconfiguration, or unauthorized access attempts.
Analyst notes and limits
The supplied ATT&CK object is a detection analytic for Network Devices with a concise description only. No tactics, related techniques, relationships, or official detection implementation details were supplied, so this take focuses on defensive validation and operational decision value rather than a specific ATT&CK technique mapping.
This assessment is limited to the official STIX fields, external reference, and empty relationship context provided. It does not establish active exploitation, adversary attribution, business impact, or guaranteed detection coverage. Local device types, log formats, identity architecture, and administrative workflows are required to operationalize the analytic.
Analytic 1267
Router/firewall/syslog logs showing authentication failures with unique usernames and reused credentials from same source IP
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 | 6bcd6e421aa5… |
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 AN1267Open 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.