AN1517: Analytic 1517
User or script-based access to ~/.ssh or other directories containing private keys followed by unusual shell activity or network connections.
Analyst context for executives and security teams
This analytic matters because access to Linux private-key directories such as ~/.ssh can indicate an attempt to use existing credentials for follow-on access. For leaders, the decision value is whether the organization can see sensitive key access and quickly connect it to abnormal shell behavior or outbound network activity before an incident expands.
Executive priority
Prioritize this as an identity and incident-readiness control question for Linux estates: are private keys protected, monitored, and investigated when access is followed by unusual activity? The object does not specify a tactic or provide a ready detection, so value comes from validating telemetry coverage, key-management hygiene, and SOC procedures rather than assuming an out-of-the-box alert exists.
Technical view
For Linux systems, validate whether file access to ~/.ssh and other private-key locations can be correlated with subsequent unusual shell activity or network connections. Because no official detection logic is provided and no relationships are supplied, detection engineering should define local baselines for expected key access, administrative shell usage, automation behavior, and legitimate outbound connections.
Likely telemetry
- Linux file access or audit telemetry for ~/.ssh and other private-key directories
- Process and command execution telemetry showing shell activity after key access
- Network connection telemetry from the same host and user context
- User, service account, and script execution context
- Host timestamps sufficient to correlate file access, shell activity, and network events
Detection direction
- Confirm whether Linux endpoint logging captures private-key directory access with user and process context.
- Correlate key-directory access with unusual shell activity or network connections rather than alerting on access alone, which may be common for administrators, developers, backup tools, or automation.
- Build environment-specific allowlists or baselines for expected SSH key use, service accounts, CI/CD jobs, and management scripts.
- Review blind spots on unmanaged Linux servers, short-lived workloads, and systems without file audit or process telemetry.
- Use this analytic as a detection design prompt, not a complete rule, because the official detection field is not provided.
Mitigation priorities
- Inventory where private keys are stored on Linux systems and reduce unnecessary local key material where feasible.
- Restrict file permissions and account access to private-key directories.
- Separate and document legitimate administrative or script-based key usage so SOC teams can distinguish expected behavior from anomalies.
- Ensure incident response playbooks include validation of recent key access, related shell activity, and outbound connections.
- Retain host and network logs long enough to reconstruct the sequence of key access followed by activity.
Analyst notes and limits
The supplied ATT&CK object is a detection analytic for Linux describing access to ~/.ssh or other private-key directories followed by unusual shell or network activity. No tactic, relationship context, or official detection logic was supplied, so local baselining and telemetry validation are essential.
This take is limited to the official STIX fields and external reference provided. It does not establish adversary attribution, active exploitation, impact, or guaranteed detection coverage. Applicability outside Linux is not supported by the supplied object.
Analytic 1517
User or script-based access to ~/.ssh or other directories containing private keys followed by unusual shell activity or network connections.
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 | 03b511e2ab43… |
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 AN1517Open 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.