AN1283: Analytic 1283
Detection of default account usage such as Guest or Administrator performing interactive or remote logons on systems outside of installation or maintenance windows.
Analyst context for executives and security teams
This analytic matters because default Windows accounts such as Guest or Administrator can become high-risk paths into systems when they are used interactively or remotely outside approved installation or maintenance activity. For leaders, the value is not simply spotting a logon; it is validating whether privileged or legacy default-account access is governed, time-bound, and explainable.
Executive priority
Treat this as an identity governance and incident-readiness check for Windows environments. Security leaders should ask whether default accounts are disabled or tightly controlled where possible, whether maintenance windows are documented, and whether SOC teams can distinguish approved administrative activity from unexpected interactive or remote logons. This can support audit evidence around privileged access controls and reduce ambiguity during incident triage.
Technical view
For SOC and detection teams, validate monitoring for Windows logon activity involving default accounts such as Guest or Administrator, especially interactive and remote logons occurring outside known installation or maintenance windows. Because the ATT&CK object provides no formal detection logic and no tactic mapping, teams should implement environment-specific baselines and exceptions rather than assuming a universal rule will be accurate.
Likely telemetry
- Windows authentication and logon event records
- Account name and account type fields for default accounts such as Guest or Administrator
- Logon type or equivalent evidence distinguishing interactive and remote logons
- Host identity and system role context
- Timestamp correlation with approved installation or maintenance windows
Detection direction
- Confirm that Windows logon telemetry is collected from systems where default account use would be material.
- Tune alerts around default-account interactive or remote logons outside approved maintenance windows.
- Maintain an allowlist or calendar-based exception process for legitimate installation and maintenance activity.
- Investigate whether Guest or Administrator usage is expected on each host class rather than treating all events equally.
- Watch for blind spots where local account activity, remote access paths, or older Windows systems are not centrally logged.
Mitigation priorities
- Inventory where Windows default accounts exist and whether they are enabled.
- Disable default accounts where business operations do not require them.
- Where default accounts must remain available, restrict interactive and remote logon rights and document approved use cases.
- Define and enforce maintenance windows for installation and administrative activity.
- Ensure privileged access processes capture who authorized default-account use and why.
Analyst notes and limits
The supplied object is a detection analytic for Windows default account usage, specifically Guest or Administrator performing interactive or remote logons outside installation or maintenance windows. No relationship context, tactic mapping, or official detection logic was supplied, so local account policy, maintenance process, and logging architecture are essential to operationalize it.
This take is limited to the official STIX fields and external reference supplied. It does not establish active exploitation, adversary attribution, guaranteed detection coverage, or applicability beyond Windows. Detection quality depends on local telemetry collection, account naming practices, and reliable maintenance-window data.
Analytic 1283
Detection of default account usage such as Guest or Administrator performing interactive or remote logons on systems outside of installation or maintenance windows.
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 | dbbe0aa79a17… |
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 AN1283Open 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.