AN0196: Analytic 0196
Detects rsync or scp inbound from other hosts that then aggregate content into /Users/Shared or /private/tmp, often involving compressed files or scripts.
Analyst context for executives and security teams
This analytic is about spotting macOS hosts that receive files from other systems using rsync or scp and then stage or aggregate that content in shared or temporary locations such as /Users/Shared or /private/tmp. For leaders, the value is not the tool names alone—rsync and scp can be legitimate—but whether the organization can distinguish approved file movement from unusual inbound aggregation that may matter during an investigation.
Executive priority
Prioritize this as a macOS visibility and incident-readiness question: can the SOC prove which hosts are receiving files, from where, under which user context, and into high-abuse staging paths? This supports faster triage, audit evidence for endpoint monitoring, and control decisions around administrative file transfer practices. Because no tactic or relationship context is supplied, treat it as a detection-validation item rather than a standalone risk conclusion.
Technical view
Validate monitoring for macOS activity where rsync or scp receives inbound content from other hosts and writes into /Users/Shared or /private/tmp, especially when the resulting content includes compressed files or scripts. Detection engineering should account for legitimate administration, software deployment, backups, and developer workflows that may use these utilities. Since ATT&CK provides no official detection logic for this analytic, local baselining and environment-specific allowlisting are required.
Likely telemetry
- macOS process execution telemetry for rsync and scp
- Command-line arguments showing source hosts, destination paths, and transfer options
- File creation or modification events under /Users/Shared and /private/tmp
- Network connection telemetry associated with inbound file transfer sessions
- User, parent process, and host context for the receiving macOS endpoint
Detection direction
- Confirm that macOS endpoint telemetry captures command line, parent process, user, and destination path for rsync and scp activity.
- Tune for inbound transfers that write to /Users/Shared or /private/tmp rather than alerting on all rsync or scp usage.
- Correlate transfer activity with file creation events involving compressed files or scripts in the same destination paths.
- Baseline known administrative, backup, deployment, and developer workflows to reduce false positives.
- Review blind spots where command-line logging, file-event collection, or network visibility is absent on macOS endpoints.
Mitigation priorities
- Document approved macOS file-transfer workflows and expected staging directories.
- Restrict or monitor unnecessary use of shared and temporary directories for operational file aggregation where feasible.
- Ensure endpoint logging policies collect process, command-line, file, and network evidence needed for this analytic.
- Use access control and administrative process governance to limit who can perform inbound transfers to sensitive macOS systems.
- Incorporate this scenario into SOC validation or tabletop exercises for macOS incident response readiness.
Analyst notes and limits
The supplied ATT&CK object is a detection analytic, AN0196, for macOS. It describes rsync or scp inbound from other hosts aggregating content into /Users/Shared or /private/tmp, often involving compressed files or scripts. No tactics, official detection logic, aliases, labels, or relationship context were supplied.
This take is limited to the official STIX fields, external reference, and absence of relationships provided. It does not establish maliciousness, active exploitation, attribution, impact, or detection coverage. Local environment baselines are necessary because rsync, scp, shared directories, temporary directories, compressed files, and scripts can all be legitimate in normal operations.
Analytic 0196
Detects rsync or scp inbound from other hosts that then aggregate content into /Users/Shared or /private/tmp, often involving compressed files or scripts.
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 | 481e239fdc52… |
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 AN0196Open 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.