T1639: Exfiltration Over Alternative Protocol
Adversaries may steal data by exfiltrating it over a different protocol than that of the existing command and control channel. The data may also be sent to an alternate network location from the main command and control server.
Alternate protocols include FTP, SMTP, HTTP/S, DNS, SMB, or any other network protocol not being used as the main command and control channel. Different protocol channels could also include Web services such as cloud storage. Adversaries may opt to also encrypt and/or obfuscate these alternate channels.
Analyst context for executives and security teams
Exfiltration Over Alternative Protocol matters because mobile data theft may not use the same network path as the attacker’s command-and-control channel. For Android and iOS environments, this means a device or app could appear to have one suspicious control channel while stolen data leaves through another protocol or destination, including common services such as HTTP/S, DNS, FTP, SMTP, SMB, or cloud storage. The business risk is missed evidence: if mobile monitoring only focuses on known C2 traffic, incident responders may underestimate what data left the environment.
Executive priority
Treat this as a mobile data-loss and incident-scope problem. Security leaders should ask whether mobile network telemetry, mobile device management evidence, and cloud/service access logs are sufficient to prove or disprove data exfiltration over non-primary channels. This is especially relevant for audit and incident decision-making because the official ATT&CK entry does not provide a detection method; coverage depends on local logging, network visibility, and the ability to correlate mobile app behavior with outbound destinations and protocols.
Technical view
For SOC, detection engineering, and IR teams, validate coverage across Android and iOS for outbound traffic that differs from an observed or suspected C2 channel. The technique includes alternate protocols and alternate network locations, with possible encryption or obfuscation. Detection content should not assume that exfiltration uses the same host, protocol, or service as command and control. Relationship context includes DET0698, a detection strategy for this technique, and sub-technique T1639.001 for unencrypted non-C2 protocols. TianySpy is listed by ATT&CK as software using this technique, providing a relationship-driven example for threat-informed validation without implying current exposure.
Likely telemetry
- Mobile network connection metadata from Android and iOS devices
- DNS query and response logs associated with mobile devices or mobile apps
- HTTP/S proxy, gateway, or secure web gateway logs where available
- Mobile device management or enterprise mobility management inventory and compliance data
- Cloud storage or web service access logs when mobile access is permitted
Detection direction
- Confirm whether mobile monitoring can distinguish primary C2-like activity from separate outbound protocols or destinations used for data transfer.
- Tune for unusual protocol use, uncommon destinations, or unexpected cloud/web service access from mobile devices and apps, while accounting for legitimate mobile app behavior and business-approved services.
- Use the T1639.001 relationship to specifically validate visibility into unencrypted non-C2 protocols, where content or metadata may be easier to inspect if collection is lawful and approved.
- Avoid single-protocol assumptions: encrypted or obfuscated alternate channels may reduce content visibility, so detection may need to rely on metadata, destination reputation, volume, timing, and device/app context.
- Use the TianySpy relationship as ATT&CK context for test planning or intelligence mapping, not as proof of current activity in the environment.
Mitigation priorities
- Prioritize mobile egress visibility: know which protocols and cloud/web services mobile devices are allowed to use and where logs are retained.
- Restrict or monitor unnecessary outbound protocols from managed mobile devices where business operations allow.
- Strengthen mobile device and app governance so risky or unauthorized apps are identified before they can create unmanaged exfiltration paths.
- Correlate mobile network telemetry with identity, cloud service, and device management logs to support incident scoping and compliance evidence.
- Prepare IR playbooks to investigate alternate exfiltration routes separately from command-and-control infrastructure.
Analyst notes and limits
ATT&CK lists this as a mobile technique for Android and iOS. The description is broad and protocol-agnostic, which makes local architecture decisive: the important question is not whether one tool claims coverage, but whether defenders can reconstruct mobile outbound behavior across protocols and destinations. Relationship context adds a detection strategy reference, a more specific unencrypted sub-technique, and TianySpy as software that uses the behavior.
The supplied ATT&CK object has no official detection text and no tactics specified. Details such as specific logs, thresholds, allowed protocols, cloud services, and false-positive baselines must be determined from the local mobile, network, identity, and cloud environment. No claim is made here about active exploitation, attribution, or existing detection coverage.
Exfiltration Over Alternative Protocol
Adversaries may steal data by exfiltrating it over a different protocol than that of the existing command and control channel. The data may also be sent to an alternate network location from the main command and control server.
Alternate protocols include FTP, SMTP, HTTP/S, DNS, SMB, or any other network protocol not being used as the main command and control channel. Different protocol channels could also include Web services such as cloud storage. Adversaries may opt to also encrypt and/or obfuscate these alternate channels.
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.
Related techniques
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 |
|---|---|---|---|
| Mobile | T1639.001 | Exfiltration Over Unencrypted Non-C2 Protocol Sub-technique | Exfiltration Over Unencrypted Non-C2 Protocol subtechnique of this object. |
Groups, software, and campaigns
S1056: TianySpy
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.1 | Current bundle | 4148e4ade42e… |
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]
NIST Mobile Threat Catalogue APP-30Open source URL
-
[2]
mitre-attack T1639Open 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.