T1481: Web Service
Adversaries may use an existing, legitimate external Web service as a means for relaying data to/from a compromised system. Popular websites and social media, acting as a mechanism for C2, may give a significant amount of cover. This is due to the likelihood that hosts within a network are already communicating with them prior to a compromise. Using common services, such as those offered by Google or Twitter, makes it easier for adversaries to hide in expected noise. Web service providers commonly use SSL/TLS encryption, giving adversaries an added level of protection.
Use of Web services may also protect back-end C2 infrastructure from discovery through malware binary analysis, or enable operational resiliency (since this infrastructure may be dynamically changed).
Analyst context for executives and security teams
T1481 Web Service matters because mobile malware can blend command-and-control activity into traffic to legitimate, commonly used web or social media services. For leaders, the risk is not that every connection to a popular service is suspicious, but that normal-looking encrypted mobile traffic can reduce visibility, delay incident response, and make C2 infrastructure harder to identify from malware analysis alone.
Executive priority
Prioritize this as a mobile security and SOC visibility issue. Executives should ask whether Android and iOS traffic to external web services is visible enough for investigation, whether acceptable-use and mobile management policies define what services are expected, and whether incident responders can distinguish legitimate app behavior from suspicious web-service-mediated C2. This also supports audit and compliance evidence where organizations must show monitoring, mobile device governance, and response readiness for encrypted outbound communications.
Technical view
ATT&CK provides no official detection text for T1481, but the object is related to detection strategy DET0672 and has sub-techniques for Dead Drop Resolver, Bidirectional Communication, and One-Way Communication. SOC and detection teams should validate whether they can observe mobile endpoint network activity, DNS or destination metadata, TLS connection metadata where available, and app-to-service communication patterns for Android and iOS. Detection should focus on abnormal use of legitimate external web services by mobile apps, unusual timing or volume, repeated polling, unexpected services for the app or user population, and indicators that a service is being used to retrieve C2 location data or relay commands/output.
Likely telemetry
- Mobile device network connection metadata for Android and iOS
- DNS queries and resolved destinations associated with mobile devices or managed mobile apps
- Proxy, secure web gateway, firewall, or VPN logs for outbound web service access
- TLS metadata where available, such as SNI, certificate, destination, timing, and session characteristics
- Mobile endpoint or MDM/MAM inventory tying apps, devices, users, and network activity together
Detection direction
- Use DET0672 as the relationship-driven starting point, but validate locally because ATT&CK does not provide detection detail for this technique.
- Baseline expected web-service usage for managed Android and iOS apps, then alert on deviations such as unapproved apps contacting popular services in repetitive, automated, or unusual patterns.
- Account for false positives: legitimate mobile apps commonly use major web services, social platforms, cloud APIs, and TLS, so detection should combine destination context with app identity, device posture, user role, timing, and volume.
- Look specifically for sub-technique patterns: web content that points to other infrastructure for Dead Drop Resolver, two-way command/output flows for Bidirectional Communication, and command retrieval without obvious return traffic for One-Way Communication.
- Preserve enough encrypted-traffic metadata for investigation even when payload inspection is unavailable or inappropriate.
Mitigation priorities
- Define and enforce mobile app governance: approved app sources, managed app inventory, and policy controls for Android and iOS devices.
- Route managed mobile traffic through logging-capable controls such as enterprise VPN, proxy, secure web gateway, or equivalent mobile security monitoring where appropriate.
- Restrict or monitor access to external web services that are not required for business mobile workflows, while recognizing that broad blocking of popular services may be operationally disruptive.
- Strengthen incident response playbooks for mobile devices so responders can quickly collect app inventory, network history, and relevant device telemetry.
- Use threat intelligence and malware analysis findings to update monitoring for suspicious service usage, embedded web-service references, or dynamically changed C2 pointers.
Analyst notes and limits
The key defensive challenge is ambiguity: the same legitimate services employees and apps use every day can also provide cover for C2 relay, dead-drop resolution, or one-way command retrieval. Glexia would treat this as a visibility-and-correlation problem rather than a single indicator problem. The Android/SpyAgent relationship supports relevance to Android mobile spyware context, but it does not by itself prove exposure in any given environment.
The supplied ATT&CK object has no official detection text and no tactics specified. The take is therefore based on the official description, Android/iOS platforms, external reference, and supplied relationships only. Local app inventory, mobile traffic collection, privacy rules, and enterprise network architecture are required to determine actual detection coverage or risk.
Web Service
Adversaries may use an existing, legitimate external Web service as a means for relaying data to/from a compromised system. Popular websites and social media, acting as a mechanism for C2, may give a significant amount of cover. This is due to the likelihood that hosts within a network are already communicating with them prior to a compromise. Using common services, such as those offered by Google or Twitter, makes it easier for adversaries to hide in expected noise. Web service providers commonly use SSL/TLS encryption, giving adversaries an added level of protection.
Use of Web services may also protect back-end C2 infrastructure from discovery through malware binary analysis, or enable operational resiliency (since this infrastructure may be dynamically changed).
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 | T1481.001 | Dead Drop Resolver Sub-technique | Dead Drop Resolver subtechnique of this object. |
| Mobile | T1481.003 | One-Way Communication Sub-technique | One-Way Communication subtechnique of this object. |
| Mobile | T1481.002 | Bidirectional Communication Sub-technique | Bidirectional Communication subtechnique of this object. |
Groups, software, and campaigns
S1214: Android/SpyAgent
Android/SpyAgent is a variant of spyware in the MoqHao phishing campaign primarily targeting Korean and Japanese users.[1] Fake security applications were used to target Japanese users, while fake police applications were used to target Korean users. Both fake applications have common C2 commands and share the same crash report key on a cloud service.[1]
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.3 | Current bundle | ece7e1cf0aff… |
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 T1481Open 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.