AN1138: Analytic 1138
Detects interactive or service logins from local accounts outside expected operational context or at anomalous times.
Analyst context for executives and security teams
This analytic matters because local Linux account logins can bypass centralized identity controls and may represent emergency administration, service misuse, policy exceptions, or unauthorized access. For leaders, the practical question is whether the organization can distinguish expected local access from abnormal interactive or service logins quickly enough to support incident response and audit evidence.
Executive priority
Prioritize this where Linux systems support critical operations, privileged administration, regulated workloads, or environments that rely on centralized identity governance. The decision value is not simply alerting on every local login; it is proving that approved operational use is documented, anomalous timing is visible, and responders can rapidly determine whether a local account login is legitimate, misconfigured, or suspicious.
Technical view
Validate visibility for interactive and service logins by local accounts on Linux systems. Because ATT&CK does not provide a specific detection query for this analytic, SOC and detection teams should define the local baseline: which accounts are permitted, which hosts allow local authentication, what service logins are expected, and what time windows are normal. Detection logic should compare login events against that expected operational context and escalate deviations for triage.
Likely telemetry
- Linux authentication logs showing successful and failed local account logins
- Interactive session records such as SSH, console, or terminal login evidence where available
- Service start or service authentication records tied to local accounts
- Host identity and asset criticality context for Linux systems
- Account inventory distinguishing local accounts from centrally managed identities
Detection direction
- Confirm Linux authentication telemetry is collected from relevant hosts and retained long enough for investigation.
- Build or validate baselines for expected local account use, including allowed accounts, hosts, services, and operating windows.
- Tune out documented administrative and service-account behavior while preserving visibility into off-hours, rare-host, or unusual-context logins.
- Review blind spots around unmanaged Linux systems, local-only logs that are not forwarded, inconsistent time synchronization, and service accounts with unclear ownership.
- Use alert triage to answer: who owns the account, why local authentication was used, whether the login was interactive or service-related, and whether the timing or host context is justified.
Mitigation priorities
- Inventory Linux local accounts and confirm business ownership and approved use cases.
- Reduce unnecessary local accounts and restrict local authentication where centralized identity or managed administration is required.
- Document approved break-glass, service, and maintenance login patterns so detection can distinguish expected use from anomalies.
- Ensure Linux authentication logs are centrally collected, time-synchronized, and available to SOC and incident response teams.
- Periodically review exceptions, especially privileged local accounts and service accounts on critical systems.
Analyst notes and limits
This object is a detection analytic for Linux focused on local account logins outside expected operational context or at anomalous times. No ATT&CK tactics, relationships, aliases, or official detection logic were supplied, so the take emphasizes validation, baselining, and telemetry readiness rather than a specific rule implementation.
The official fields do not provide a detection query, mapped tactic, related technique, data source list, or relationship context. Local environment knowledge is required to define what counts as expected operational context, anomalous timing, and acceptable local account use.
Analytic 1138
Detects interactive or service logins from local accounts outside expected operational context or at anomalous times.
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 | 349525d2c376… |
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 AN1138Open 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.