T1663: Remote Access Software
Adversaries may use legitimate remote access software, such as `VNC`, `TeamViewer`, `AirDroid`, `AirMirror`, etc., to establish an interactive command and control channel to target mobile devices.
Remote access applications may be installed and used post-compromise as an alternate communication channel for redundant access or as a way to establish an interactive remote session with the target device. They may also be used as a component of malware to establish a reverse connection to an adversary-controlled system or service. Installation of remote access tools may also include persistence.
Analyst context for executives and security teams
Remote Access Software (T1663) matters because legitimate mobile remote-control tools can become an attacker’s interactive access path after a device is compromised. For executives and security leaders, the risk is not simply that an app exists; it is that approved or tolerated tools such as VNC, TeamViewer, AirDroid, or AirMirror can blur the line between business support activity and adversary command-and-control on Android or iOS devices.
Executive priority
Prioritize this where mobile devices have access to sensitive business applications, identity workflows, banking or payment functions, operational communications, or executive accounts. Leaders should ask whether the organization can distinguish authorized mobile support from unauthorized remote sessions, whether MDM/EMM policy limits risky remote-access behavior, and whether user guidance is documented as compliance evidence. This technique is especially relevant to mobile incident response readiness because remote access may provide redundant access, interactive control, and possible persistence after compromise.
Technical view
ATT&CK does not provide official detection text for T1663, but the object is related to DET0624, Detection of Remote Access Software. SOC and mobile security teams should validate visibility for Android and iOS app inventory, installation events, permissions, remote-session indicators, and network connections associated with known remote-access applications. IR teams should treat unexpected remote-access software on a mobile device as context for possible command-and-control or persistence, while still separating legitimate helpdesk or user-installed tools from suspicious post-compromise use. Relationship context notes that Android software Escobar and BRATA use this technique, so Android monitoring should be checked carefully where those software references are in scope for threat intelligence.
Likely telemetry
- MDM/EMM device inventory and application inventory for Android and iOS
- Mobile app installation, removal, and version records
- Policy compliance status from enterprise mobility management controls
- Mobile device permission and configuration state where available
- Network connection metadata or secure web gateway/VPN logs showing connections to remote-access services
Detection direction
- Build or validate detections aligned to DET0624 for presence and use of remote-access software on mobile devices.
- Tune for authorized support workflows so detections compare app presence and remote-session activity against approved users, devices, support windows, and business justification.
- Prioritize unknown, newly installed, unmanaged, or policy-disallowed remote-access tools, especially when observed after another compromise indicator.
- Look for redundancy patterns: multiple remote-control tools, unexpected reverse connections, or remote-access apps appearing alongside other suspicious mobile behavior.
- Account for blind spots where personal/BYOD devices, unmanaged iOS devices, limited mobile telemetry, or incomplete app inventory prevent confident detection.
Mitigation priorities
- Use Enterprise Policy (M1012) through MDM/EMM to define which remote-access applications are allowed, blocked, or restricted on mobile devices.
- Apply User Guidance (M1011) so users understand when remote support is legitimate and when installing or granting permissions to remote-access apps is risky.
- Document approved mobile support processes, including authorization, session logging expectations, and device eligibility.
- Review exceptions regularly, especially for privileged users and devices with access to sensitive applications or identity workflows.
- During incidents, remove unauthorized remote-access tools and validate whether persistence or alternate communication channels remain.
Analyst notes and limits
The supplied ATT&CK object covers Android and iOS and describes use of legitimate remote access software for interactive command-and-control, redundant access, reverse connections, and possible persistence. ATT&CK relationship context links the technique to DET0624, mitigations M1011 and M1012, and Android software Escobar and BRATA. Because tactics are not specified and official detection text is not provided, detection engineering should start from local mobile telemetry and policy baselines rather than assuming ATT&CK-defined analytics are sufficient.
This take is limited to the supplied ATT&CK fields and relationships. It does not establish active exploitation, customer exposure, attribution, or guaranteed detection coverage. The related software examples support Android relevance, but they do not by themselves prove activity in any environment. Local MDM/EMM coverage, BYOD scope, app allowlisting policy, and network logging determine practical detectability.
Remote Access Software
Adversaries may use legitimate remote access software, such as `VNC`, `TeamViewer`, `AirDroid`, `AirMirror`, etc., to establish an interactive command and control channel to target mobile devices.
Remote access applications may be installed and used post-compromise as an alternate communication channel for redundant access or as a way to establish an interactive remote session with the target device. They may also be used as a component of malware to establish a reverse connection to an adversary-controlled system or service. Installation of remote access tools may also include persistence.
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.
Groups, software, and campaigns
S1094: BRATA
BRATA (Brazilian Remote Access Tool, Android), is an evolving Android malware strain, detected in late 2018 and again in late 2021. Originating in Brazil, BRATA was later also found in the UK, Poland, Italy, Spain, and USA, where it is believed to have targeted financial institutions such as banks. There are currently three known variants of BRATA.[1][2][3]
S1092: Escobar
All related ATT&CK context
Mitigation direction
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 | 278a12976d0f… |
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 T1663Open 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.