AN0135: Analytic 0135
Detects removal of Remote Login or Screen Sharing logs in Unified Logging, deletion of `com.apple.UTun`, or suspicious Terminal use of `rm`, `sudo pfctl -F all` to clear network state/config history.
Analyst context for executives and security teams
AN0135 is a macOS-focused detection analytic for signs that someone may be trying to erase or reset evidence related to remote access, screen sharing, network tunneling, or firewall/network state. For leaders, the practical issue is not the specific commands alone; it is whether the organization can still reconstruct what happened on a Mac endpoint after suspicious administrative or terminal activity.
Executive priority
Prioritize this analytic where macOS systems are used by administrators, developers, executives, or other high-value users. It supports incident response readiness and audit evidence by testing whether endpoint logging, Unified Logging visibility, and command/process telemetry survive attempts to remove traces of Remote Login, Screen Sharing, UTun activity, or network configuration history.
Technical view
SOC and detection teams should validate macOS telemetry for removal of Remote Login or Screen Sharing logs in Unified Logging, deletion of `com.apple.UTun`, and suspicious Terminal-driven use of `rm` or `sudo pfctl -F all`. Because no ATT&CK detection logic or tactic mapping is supplied, teams should treat AN0135 as a validation target rather than a complete rule: confirm which events are collected, how deletion/reset activity appears, and what normal administrative maintenance looks like in the local environment.
Likely telemetry
- macOS Unified Logging records related to Remote Login and Screen Sharing
- Endpoint process execution telemetry for Terminal, rm, sudo, and pfctl
- File deletion or filesystem activity involving com.apple.UTun
- macOS firewall or packet filter state/configuration change evidence
- Endpoint security agent alerts or audit records for privileged command execution
Detection direction
- Test whether log removal or deletion attempts are visible before and after local cleanup activity.
- Tune for context: legitimate administrators may use rm, sudo, or pfctl, so correlate with user role, host criticality, time of activity, and change records.
- Look for combinations of evidence removal and privileged network-state clearing rather than relying on a single command string.
- Identify blind spots on Macs without reliable process telemetry, Unified Logging collection, or centralized endpoint retention.
- Use this analytic as macOS-specific coverage validation; no Windows, Linux, cloud, or identity platform coverage is supported by the supplied object.
Mitigation priorities
- Ensure macOS endpoint logging and process telemetry are centrally collected with retention appropriate for incident response.
- Restrict and monitor privileged administrative access on macOS systems, especially where Terminal and sudo use is allowed.
- Define approved administrative procedures for firewall/network state resets so suspicious deviations can be reviewed.
- Protect log sources and endpoint telemetry from local tampering where feasible.
- Include this behavior in incident response playbooks for macOS evidence preservation and triage.
Analyst notes and limits
The supplied object is a detection analytic, not a technique or campaign. It is limited to macOS and has no supplied tactic mapping, relationship context, or official detection query. The strongest defensive use is to validate whether the organization can observe potential evidence removal and network-state clearing on macOS endpoints.
No official detection logic, relationships, aliases, labels, or tactic context were provided. This take does not infer adversary use, active exploitation, attribution, impact, or guaranteed detection coverage. Local baseline and telemetry testing are required.
Analytic 0135
Detects removal of Remote Login or Screen Sharing logs in Unified Logging, deletion of `com.apple.UTun`, or suspicious Terminal use of `rm`, `sudo pfctl -F all` to clear network state/config history.
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 | 0fa086096305… |
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 AN0135Open 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.