AN0857: Analytic 0857
File reads or process executions involving insecurely stored credential files (e.g., config files with password fields) by non-root or anomalous users followed by ssh authentication attempts.
Analyst context for executives and security teams
This analytic matters because it points to a common Linux risk pattern: credentials stored insecurely in files may be read or used by an unexpected user, then followed by SSH authentication attempts. For leaders, the issue is not only the file access event; it is whether the organization can prove that sensitive credential material is not exposed to ordinary users and that suspicious use of those credentials can be investigated quickly.
Executive priority
Prioritize this as an identity and incident-readiness control check for Linux environments. Executives should ask whether teams know where credential-bearing configuration files exist, whether access is restricted, and whether SOC/IR teams can correlate file access with subsequent SSH authentication activity. This supports operational resilience, audit evidence for access control, and faster decisions when suspected credential misuse appears.
Technical view
For Linux SOC and detection teams, validate whether telemetry can correlate reads or executions involving files likely to contain credentials with SSH authentication attempts by the same user, process context, host, or time window. Because ATT&CK does not provide a formal detection implementation here, teams should define local criteria for “non-root” and “anomalous” users, credential-like file paths or fields, and SSH authentication events. Investigations should focus on whether the user normally accesses the file, whether the access was interactive or process-driven, and whether SSH attempts occurred shortly afterward.
Likely telemetry
- Linux file access/read events for sensitive or credential-bearing configuration files
- Process execution telemetry on Linux hosts
- User identity and privilege context, including root versus non-root users
- SSH authentication logs and outcomes
- Host, process, command-line, parent process, and timestamp context where available
Detection direction
- Validate that Linux endpoint or audit logging captures reads of sensitive configuration files, not only file modifications.
- Correlate credential-file access with subsequent SSH authentication attempts within a defensible time window.
- Tune baselines for administrative scripts, configuration management, backup tools, and service accounts to reduce false positives.
- Define and maintain a local inventory or pattern set for files likely to contain password fields or stored credentials.
- Watch for blind spots where file-read auditing is disabled, SSH logs are centralized inconsistently, or service account behavior is poorly documented.
Mitigation priorities
- Identify and reduce insecurely stored credentials in Linux configuration files where possible.
- Restrict file permissions so non-root or unauthorized users cannot read credential-bearing files.
- Review service account and administrative access to ensure least privilege.
- Centralize and retain Linux file access, process, and SSH authentication logs for investigation.
- Use this analytic as a validation point for credential hygiene, access control evidence, and incident response playbooks.
Analyst notes and limits
The supplied ATT&CK object is a detection analytic for Linux and provides a behavioral description but no official detection logic, tactics, relationships, or linked techniques in the supplied context. Treat this as a detection engineering requirement and control-validation prompt rather than a complete rule.
Assessment depends on local knowledge of credential file locations, normal user behavior, SSH logging quality, and endpoint audit coverage. The supplied object does not support claims about active exploitation, specific adversaries, impact, or guaranteed detection efficacy.
Analytic 0857
File reads or process executions involving insecurely stored credential files (e.g., config files with password fields) by non-root or anomalous users followed by ssh authentication attempts.
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 | 1f424f3f1664… |
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 AN0857Open 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.