DET0259: Remote Desktop Software Execution and Beaconing Detection
DET0259 is a detection strategy for identifying execution and beaconing associated with remote desktop software used as command-and-control. The business i...
Analyst context for executives and security teams
DET0259 is a detection strategy for identifying execution and beaconing associated with remote desktop software used as command-and-control. The business issue is not that remote support tools are inherently malicious; it is that legitimate tools such as VNC, TeamViewer, AnyDesk, ScreenConnect, LogMeIn, and AmmyyAdmin can provide interactive access that may bypass assumptions based on malware-only detection. Leaders should treat this as a control-validation question: which remote desktop tools are approved, where are they allowed, and can the SOC distinguish sanctioned support activity from unexpected execution or network beaconing?
Executive priority
Prioritize this detection area where remote administration is common or business-critical. The decision value is in reducing ambiguity during incidents: approved remote support should be documented, monitored, and defensible as audit evidence, while unapproved or unexpected remote desktop execution should trigger rapid triage. This supports business continuity by limiting uncontrolled interactive access paths across Windows, macOS, and Linux environments referenced by the related ATT&CK technique.
Technical view
This object detects ATT&CK T1219.002 Remote Desktop Software under command-and-control. MITRE does not provide an official description or detection logic for DET0259, so teams should build validation around the related technique context: execution of known remote desktop/support applications and recurring outbound communication consistent with remote access beaconing. SOC and detection engineering teams should compare endpoint process evidence with network connection patterns, approved software inventories, and administrative support workflows before escalating.
Likely telemetry
- Endpoint process execution events for remote desktop/support software names and binaries
- Software inventory or application allowlist/asset management records showing approved remote administration tools
- Network connection and proxy/firewall logs showing outbound sessions from endpoints running remote desktop software
- DNS telemetry for domains contacted by remote desktop applications where available
- Authentication, user session, or administrative activity logs that help distinguish helpdesk use from unexpected interactive access
Detection direction
- Validate whether detections cover execution plus beaconing behavior, not just file names, because legitimate remote support tools may be renamed or installed in different paths.
- Tune against known helpdesk, IT administration, and managed service activity to reduce false positives while preserving visibility into new hosts, unusual users, unusual times, or unmanaged assets.
- Use the related technique platforms—Linux, macOS, and Windows—as the scope for coverage validation; do not assume coverage where host or network telemetry is not collected.
- Maintain an approved-tool baseline. Alerts should be higher priority when the tool is not approved, appears on a sensitive system, or runs outside expected support processes.
- Correlate endpoint and network evidence. Execution without network activity, or network activity without endpoint context, may be insufficient for confident triage.
Mitigation priorities
- Define and maintain an approved remote desktop/support software policy, including allowed tools, users, systems, and business purposes.
- Inventory installed and portable remote desktop tools across supported endpoint platforms.
- Restrict unauthorized remote administration software through application control or software governance processes where feasible.
- Require monitoring and logging for approved remote support use so security teams can produce incident and compliance evidence.
- Review exceptions regularly, especially for sensitive systems and administrative workstations.
Analyst notes and limits
The supplied ATT&CK object is a detection strategy with no official description, no official detection text, no tactics, and no platforms specified on the object itself. The practical guidance is therefore derived from the explicit relationship that DET0259 detects T1219.002 Remote Desktop Software, whose related context identifies command-and-control and Linux, macOS, and Windows platforms. Treat this as a validation framework rather than a complete analytic rule.
No official DET0259 detection logic, data sources, analytic thresholds, or platform list were supplied. Local environment baselines, approved remote support tooling, logging coverage, and support workflows are required before determining alert severity or detection coverage.
Remote Desktop Software Execution and Beaconing Detection
No official description is available in the imported ATT&CK source object.
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.
Techniques used
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1219.002 | Remote Desktop Software Sub-technique | This object detects Remote Desktop Software. |
All related ATT&CK context
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 | 5bf185ecf244… |
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 DET0259Open 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.