AN1240: Analytic 1240
Account created via CLI using 'username' command or REST API. Detectable through AAA logging or CLI history telemetry.
Analyst context for executives and security teams
This analytic matters because new account creation on network devices can change who has administrative access to critical infrastructure. For executives and security leaders, the practical question is whether the organization can prove when network device accounts are created, by whom, and through which management path, especially when access changes affect operational resilience and auditability.
Executive priority
Prioritize this as an access governance and operational resilience validation for network devices. Leaders should ask whether AAA logging and CLI history are consistently enabled, retained, monitored, and reviewable for account creation activity. This supports incident decision-making, privileged access oversight, and compliance evidence around administrative account lifecycle controls.
Technical view
The supplied analytic describes detection of accounts created via CLI using the 'username' command or through a REST API on network devices. SOC and detection teams should validate that network device AAA logs and CLI history telemetry are collected, normalized, and searchable for account creation events. Because no ATT&CK tactic, relationship context, or official detection logic is supplied, teams should treat this as a telemetry and control validation analytic rather than a complete detection rule.
Likely telemetry
- Network device AAA logging records
- Network device CLI history
- Network device management/API activity logs where available
- Administrative account change records from network devices
- Time, source, and operator context associated with network device management sessions
Detection direction
- Confirm which network devices generate AAA logs for account creation activity and whether those logs are centrally collected.
- Validate that CLI history captures relevant administrative commands, including account creation using the 'username' command, where supported.
- Assess whether REST API-based account creation is logged with enough detail to distinguish legitimate provisioning from unexpected changes.
- Tune detections against approved change windows, authorized administrators, and expected automation to reduce false positives.
- Identify blind spots where devices lack AAA logging, CLI history retention, REST API audit detail, or centralized log forwarding.
Mitigation priorities
- Ensure administrative account creation on network devices follows an approved change process.
- Enable and retain AAA logging and CLI history telemetry on supported network devices.
- Centralize network device administrative logs for SOC review and incident response use.
- Regularly review network device local accounts and reconcile them against authorized access records.
- Restrict and monitor administrative management paths, including CLI and REST API access, according to organizational policy.
Analyst notes and limits
This object is a detection analytic, not a technique entry. The available ATT&CK content is narrow but useful: it identifies account creation on network devices via CLI or REST API and names AAA logging and CLI history as relevant evidence sources. Local device models, logging configuration, account management procedures, and change-control context will determine detection quality.
No official detection logic, tactics, related techniques, groups, software, or mitigations were supplied. This take does not infer active exploitation, adversary attribution, business impact, or guaranteed detection coverage. Environment-specific validation is required.
Analytic 1240
Account created via CLI using 'username' command or REST API. Detectable through AAA logging or CLI history telemetry.
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 | ed7c49eb98d9… |
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 AN1240Open 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.