AN1366: Analytic 1366
Chain of remote access tool behavior: (1) initial execution of remote-control/assist agent or GUI under user context; (2) persistence via service or autorun; (3) long-lived outbound connection/tunnel to external infrastructure; (4) interactive control signals such as shell or file-manager child processes spawned by the RAT parent.
Analyst context for executives and security teams
AN1366 describes a Windows detection analytic for spotting remote access tool behavior as a chain, not as a single event: user-context execution, persistence through a service or autorun, a long-lived outbound connection or tunnel, and interactive child activity such as shells or file-manager processes. For leaders, the value is that this pattern can represent unauthorized remote control even when any one event looks like normal support activity.
Executive priority
Prioritize this analytic where remote support tooling is common or business-critical Windows systems require tight control. The business question is not simply “do we block remote access tools?” but “can we distinguish approved support from persistent, interactive, externally connected remote control?” This supports incident triage, audit evidence for endpoint monitoring, and decisions about allowed remote administration paths.
Technical view
SOC and detection teams should validate whether Windows telemetry can correlate the full behavior chain: remote-control or assist-agent execution under a user context, persistence via service creation or autorun, sustained outbound connectivity to external infrastructure, and child processes indicating interactive control. Because no ATT&CK tactic or official detection logic is supplied, this should be treated as a detection design pattern rather than a ready-to-run rule.
Likely telemetry
- Windows process creation events, including parent-child relationships
- Service creation or modification events
- Autorun or startup persistence locations
- Network connection telemetry showing long-lived outbound sessions or tunnels
- Command shell and file-manager child process execution from remote access tool parents
Detection direction
- Correlate multiple weak signals rather than alerting on remote access tool execution alone, since legitimate helpdesk and administration tools may create similar activity.
- Baseline approved remote support agents, expected users, service names, installation paths, and network destinations.
- Prioritize alerts where user-context execution is followed by persistence and long-lived external connectivity.
- Increase severity when the remote access parent spawns interactive shell or file-management processes.
- Review blind spots in endpoint process logging, service/autorun visibility, and network session duration data.
Mitigation priorities
- Maintain an approved inventory and policy for Windows remote access and remote support tools.
- Restrict who can install or persist remote access software through service or autorun mechanisms.
- Use endpoint and network monitoring controls that preserve parent-child process context and outbound session details.
- Define incident response playbooks for unauthorized or suspicious remote-control activity, including validation of user authorization and persistence removal.
- Periodically test whether the SOC can distinguish sanctioned support sessions from unexpected persistent remote access behavior.
Analyst notes and limits
This object is a detection analytic in the enterprise ATT&CK domain for Windows. It provides a behavior chain but no official detection implementation, no tactics, and no relationship context. Local allowlists, administrative practices, and remote support workflows are essential to make this useful without excessive false positives.
The supplied ATT&CK fields do not identify specific software, adversaries, campaigns, tactics, mitigations, or active exploitation. Conclusions are limited to the described Windows behavior chain and the single MITRE external reference.
Analytic 1366
Chain of remote access tool behavior: (1) initial execution of remote-control/assist agent or GUI under user context; (2) persistence via service or autorun; (3) long-lived outbound connection/tunnel to external infrastructure; (4) interactive control signals such as shell or file-manager child processes spawned by the RAT parent.
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 | 4ddd363ddc65… |
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 AN1366Open 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.