Web Service: Bidirectional Communication

Adversaries may use an existing, legitimate external Web service channel as a means for sending commands to and receiving output from a compromised system. Compromised systems may leverage popular websites and social media to host command and control (C2) instructions. Those infected systems can then send the output from those commands back over that Web service channel. The return traffic may occur in a variety of ways, depending on the Web service being utilized. For example, the return traffic may take the form of the compromised system posting a comment on a forum, issuing a pull request to development project, updating a document hosted on a Web service, or by sending a Tweet.

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.

ID: T1481.002
Sub-technique of:  T1481
Tactic Type: Post-Adversary Device Access
ⓘ
ⓘ
Platforms: Android, iOS
Version: 1.2
Created: 06 April 2022
Last Modified: 12 May 2026

Procedure Examples

ID Name Description
S0655 BusyGasper

BusyGasper can be controlled via IRC using freenode.net servers.[1]

S0485 Mandrake

Mandrake has used Firebase for C2.[2]

S0545 TERRACOTTA

TERRACOTTA has used Firebase for C2 communication.[3]

S9006 VajraSpy

VajraSpy has used Firebase and Google Cloud Storage to send and receive C2 communications and to send collected data.[4][5]

Mitigations

This type of attack technique cannot be easily mitigated with preventive controls since it is based on the abuse of system features.

Detection Strategy

ID Name Analytic ID Analytic Description
DET0700 Detection of Bidirectional Communication AN1816

For Android, detect Bidirectional Communication by correlating analyst-visible device/network evidence and management state; use streaming or batched telemetry only where the documented collector is deployed. Correlate Application Permission via Android Enterprise DPC / Application Vetting [DevicePolicyManager.getPermissionGrantState(); PackageManager manifest/requested-permission review]; Application State via Android Enterprise / EMM [Managed package inventory/status and package metadata]; File Creation via Application Vetting / Forensic Acquisition [Dynamic filesystem trace or acquired app-container/filesystem artifacts: Local file write between inbound retrieval]. Alert on a sequence or state change inconsistent with the device/app baseline, approved management policy, or expected user workflow; do not infer unobserved API calls, file/process activity, or payload content from management state alone.

AN1817

For iOS, detect Bidirectional Communication by correlating analyst-visible device/network evidence and management state; use streaming or batched telemetry only where the documented collector is deployed. Correlate Application Permission via Application Vetting [Code-signing entitlements and Info.plist privacy usage-description keys]; Application State via Apple MDM [InstalledApplicationList / ManagedApplicationList]; Network Traffic Content via Enterprise Secure Web Gateway / Proxy [DNS/HTTP(S) inspection or proxy transaction metadata where enterprise decryption/inspection is deployed]. Alert on a sequence or state change inconsistent with the device/app baseline, approved management policy, or expected user workflow; do not infer unobserved API calls, file/process activity, or payload content from management state alone.

References