AN0517: Analytic 0517
Monitor scp, rsync, curl, sftp, or ftp processes initiating transfers to internal systems combined with file creation events in unusual directories. Correlate transfer activity with subsequent execution of those binaries.
Analyst context for executives and security teams
This analytic matters because it looks for a common Linux pattern: files transferred into internal systems with tools such as scp, rsync, curl, sftp, or ftp, created in unusual directories, and then executed. For leaders, the value is not the transfer tool itself—many are legitimate—but whether the organization can distinguish normal administration from suspicious staging and execution on Linux hosts.
Executive priority
Prioritize this as a validation point for Linux monitoring, SOC triage quality, and incident response readiness. Executives should ask whether internal file-transfer activity, file creation in nonstandard locations, and subsequent execution can be correlated quickly enough to support containment decisions and audit evidence. This is especially relevant where Linux systems support critical applications, administrative automation, or regulated workloads.
Technical view
For SOC and detection teams, validate collection and correlation across Linux process activity, transfer-tool execution, file creation paths, and later execution of the transferred file. The analytic is platform-scoped to Linux and has no supplied ATT&CK tactic or relationship context, so implementation should be behavior-led rather than mapped to a specific campaign or technique chain. Tune around known administrative workflows such as backups, software deployment, CI/CD, and configuration management while preserving visibility into unusual write-and-execute paths.
Likely telemetry
- Linux process creation events with command line and parent process context
- Execution of scp, rsync, curl, sftp, or ftp processes
- Network connection metadata showing transfers to internal systems
- File creation events, including path, filename, owner, permissions, and timestamp
- Subsequent process execution events for newly created files
Detection direction
- Confirm telemetry can correlate transfer process, destination, file creation, and later execution on the same Linux host within a defensible time window.
- Baseline normal administrative transfer locations and expected service accounts to identify unusual directories without generating excessive noise.
- Tune exceptions for approved deployment, backup, patching, and automation workflows, but require enough context to avoid broad allowlisting of transfer tools.
- Prioritize alerts where transferred files are created in temporary, user-writable, or otherwise nonstandard directories and then executed.
- Validate that file creation and execution telemetry is retained long enough for incident reconstruction, not just real-time alerting.
Mitigation priorities
- Establish approved Linux software-transfer and deployment paths, owners, and service accounts.
- Restrict write and execute permissions in directories that should not host runnable binaries where operationally feasible.
- Apply least privilege to accounts that can transfer files to internal Linux systems.
- Use network and host controls to limit unnecessary file-transfer paths between internal systems.
- Document expected administrative transfer workflows so SOC teams can tune detections and provide compliance-ready evidence.
Analyst notes and limits
This Glexia take is based only on the supplied MITRE analytic AN0517. The key defensive value is correlation: transfer activity alone is often normal, while transfer plus unusual file creation plus execution is more decision-useful for triage.
No official detection logic, tactic mapping, related techniques, procedures, adversary context, or mitigation relationships were supplied. Local baselines are required to define “unusual directories,” expected internal transfer paths, and acceptable administrative activity.
Analytic 0517
Monitor scp, rsync, curl, sftp, or ftp processes initiating transfers to internal systems combined with file creation events in unusual directories. Correlate transfer activity with subsequent execution of those binaries.
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 | 63418f5fa154… |
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 AN0517Open 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.