AN0714: Analytic 0714
Adversary installation or use of RMM software (e.g., TeamViewer, AnyDesk, ScreenConnect) followed by outbound beaconing or remote session establishment
Analyst context for executives and security teams
This analytic is about spotting remote monitoring and management (RMM) tools on Windows when they are installed or used and then begin outbound beaconing or remote session activity. For leaders, the practical issue is control over remote access: legitimate tools such as TeamViewer, AnyDesk, and ScreenConnect can support operations, but unmanaged or unexpected use can create a serious incident response and business continuity concern.
Executive priority
Prioritize this as a remote-access governance and monitoring question. Security leaders should ask which RMM tools are approved, where they are allowed, who can initiate sessions, and whether the SOC can distinguish sanctioned support activity from unexpected installation or connection patterns. This also supports audit and compliance evidence around remote access controls and incident readiness.
Technical view
For Windows environments, validate whether endpoint, network, proxy, DNS, and remote access logs can show RMM software installation or execution followed by outbound beaconing or remote session establishment. Because the object provides no official detection logic and no tactic mapping, teams should treat this as a detection-engineering requirement rather than a ready-to-run rule. Baseline approved RMM usage, identify expected binaries, services, installation paths, network destinations, and user/admin context, then alert on deviations.
Likely telemetry
- Windows endpoint process execution and service creation events
- Software installation or application inventory records
- EDR telemetry for RMM process start and child processes
- Network connection metadata from endpoints
- DNS resolution logs for RMM-related services
Detection direction
- Build an allowlist of approved RMM products, hosts, users, and support workflows before generating high-severity alerts.
- Correlate installation or first-seen execution of RMM software with outbound beaconing or remote session establishment from the same Windows endpoint.
- Tune for legitimate IT support activity, software deployment windows, and managed service provider usage to reduce false positives.
- Look for blind spots where local endpoint telemetry is absent, outbound traffic is not logged, or RMM traffic blends into common web protocols.
- Validate that detections cover both newly installed RMM tools and previously installed tools that begin unexpected remote-session behavior.
Mitigation priorities
- Define and document approved RMM tools, owners, and authorized use cases.
- Restrict installation and execution of unapproved remote access software on Windows endpoints where feasible.
- Enforce least privilege for users and administrators who can install or operate RMM tools.
- Centralize logging for endpoint activity and outbound network connections so remote session behavior can be investigated.
- Maintain asset and software inventory evidence to support SOC triage, incident response, and compliance reviews.
Analyst notes and limits
The supplied ATT&CK object is a detection analytic, not a full technique, and it has no supplied relationships or official detection procedure. The most useful defensive interpretation is to treat it as a control-validation prompt for RMM governance, endpoint visibility, and outbound session monitoring on Windows.
Tactics are not specified, no relationship context is supplied, and MITRE provides no detection text beyond the analytic description. Local approved-tool lists, endpoint coverage, and network logging determine whether this can be implemented reliably.
Analytic 0714
Adversary installation or use of RMM software (e.g., TeamViewer, AnyDesk, ScreenConnect) followed by outbound beaconing or remote session establishment
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 | 60b440b865b3… |
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 AN0714Open 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.