AN0716: Analytic 0716
Initiation of remote desktop sessions via AnyDesk, TeamViewer, or Chrome Remote Desktop accompanied by unexpected user logins or system modifications
Analyst context for executives and security teams
This analytic is about spotting macOS remote desktop activity using AnyDesk, TeamViewer, or Chrome Remote Desktop when it coincides with unexpected user logins or system changes. For leaders, the practical issue is not the tool name alone—these products can be legitimate—but whether remote access is being used outside approved support workflows in a way that could affect endpoint control, investigation timelines, and business continuity.
Executive priority
Prioritize this as a validation point for remote access governance on macOS. Security leaders should ask whether the organization knows where these remote desktop tools are allowed, whether login and system-change evidence is retained, and whether the SOC can distinguish approved support activity from unexpected access. This supports incident decision-making, audit evidence around remote administration, and control prioritization for endpoint and identity monitoring.
Technical view
SOC and detection teams should validate monitoring for macOS events involving initiation of AnyDesk, TeamViewer, or Chrome Remote Desktop sessions, then correlate that activity with unexpected user logins and system modifications. Because no official detection logic is provided and no ATT&CK tactic is specified, implementation should be environment-specific: define approved remote support users, devices, time windows, and change patterns before alerting broadly.
Likely telemetry
- macOS process execution or application launch events for AnyDesk, TeamViewer, and Chrome Remote Desktop
- User login/session records on macOS endpoints
- Endpoint management or EDR records showing system modifications
- Remote access tool inventory or software installation records
- Authentication and account activity logs that help determine whether a login was expected
Detection direction
- Baseline legitimate remote support usage on macOS before treating tool execution as suspicious.
- Correlate remote desktop session initiation with unexpected user logins and nearby system modifications, as described by the analytic.
- Tune for approved help desk activity, scheduled maintenance, and known administrator accounts to reduce false positives.
- Look for blind spots where macOS endpoints lack process, login, or system-change telemetry.
- Because no official detection logic is supplied, validate detections through local data sources and documented support workflows rather than assuming coverage.
Mitigation priorities
- Maintain an approved remote access tool policy for macOS and document where AnyDesk, TeamViewer, or Chrome Remote Desktop are permitted.
- Inventory macOS systems for remote desktop software and reconcile findings against business-approved use cases.
- Restrict remote support privileges to authorized users and managed devices where feasible.
- Ensure macOS login, process, and system modification telemetry is collected and retained for investigation.
- Review incident response procedures for unexpected remote access so teams can quickly determine whether activity is authorized.
Analyst notes and limits
The supplied ATT&CK object is a detection analytic for macOS and describes remote desktop session initiation via AnyDesk, TeamViewer, or Chrome Remote Desktop accompanied by unexpected logins or system modifications. There are no supplied relationships, aliases, labels, or tactic mappings, and no official detection query is provided.
This take is limited to the official STIX fields and external reference supplied. It does not establish adversary attribution, active exploitation, impact, or guaranteed detectability. Local business context is required to determine which remote desktop sessions are expected and which system modifications are material.
Analytic 0716
Initiation of remote desktop sessions via AnyDesk, TeamViewer, or Chrome Remote Desktop accompanied by unexpected user logins or system modifications
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 | 3e8cb7b66ac0… |
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 AN0716Open 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.