{
	"id": "d176e7fd-17a3-4656-b54f-630e7f9c9e82",
	"created_at": "2026-04-06T00:12:29.229925Z",
	"updated_at": "2026-04-10T03:21:14.79679Z",
	"deleted_at": null,
	"sha1_hash": "9ad55b68207a448474f199825cb0784c9e29cfc8",
	"title": "Operational Analysis of Communication Channels in Mobile RCS",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1128607,
	"plain_text": "Operational Analysis of Communication Channels in Mobile RCS\r\nBy Ireneusz Tarnowski\r\nPublished: 2025-12-23 · Archived: 2026-04-05 21:08:10 UTC\r\n12 min read\r\nDec 22, 2025\r\nPress enter or click to view image in full size\r\nThe analysis examines a sample of mobile malware used in highly targeted operations where the priority is not\r\ninfection scale, but persistent, long-term control over a single victim device. The code combines characteristics of\r\noperator-grade spyware — extended telemetry collection, strong environmental awareness, and cloud-based C2\r\ncommunications — with a real-time access component implemented via a Fast Reverse Proxy tunnel. The report\r\ndemonstrates how a seemingly benign application becomes a carrier for a durable command channel leveraging\r\nGoogle infrastructure and reverse tunnels, while preserving full niche deployment and OPSEC parameters.\r\nAplication\r\nThe initial infection vector makes the operation resemble the numerous ongoing mass-scale campaigns. Through\r\nsocial engineering, the adversary persuades a selected victim to download and instal a mobile application that\r\nhttps://medium.com/@ireneusz.tarnowski/operational-analysis-of-communication-channels-in-mobile-rcs-437f9aad5653\r\nPage 1 of 9\n\nimpersonates another trusted application. The downloaded APK functions as a classic dropper. A dropper is a form\r\nof malicious application whose purpose is to deliver and execute an embedded payload — typically by unpacking\r\nor decoding it once on the device. In this case, its goal is to obtain all required user permissions (by presenting\r\nscreens borrowed from the spoofed trusted application), after which it instals and launches a second application\r\n(stage two) retrieved from \\assets\\apk\\target.apk.\r\nThe installed application is, in reality, yet another dropper. Static analysis of this stage does not immediately\r\nreveal hostile capabilities, and nothing obviously malicious can be observed at first glance. At this point, the\r\nmalware retrieves from its internal resources a file with a .json extension (its entropy is 7.99, indicating strong\r\npacking or encryption; in practice, it is a container holding an encrypted DEX library later injected into the active\r\napplication). The file is encrypted with the symmetric stream cipher RC4 (KSA/PRGA). The decryption key is\r\ntrivial to locate in the disassembled code. After decryption, functions previously hidden within that library are\r\nexecuted, including:\r\n- real-time screen capture and streaming,\r\n- remote device management (VNC/RDP-style interaction through Accessibility; real-time operator control).\r\nInitially, the sample appeared to be a RAT. However, a full inspection of its functionality and operator workflow\r\nindicates that it is an advanced spyware platform — an RCS (Remote Control System).\r\nDuring analysis, a multi-layer command-and-control architecture was identified, designed to ensure persistent,\r\ncovert, and operator-driven access to the compromised device. The communication model separates signalling and\r\ntask orchestration from interactive remote access, reducing observable network traffic, and bypassing traditional\r\nbeacon-based detection mechanisms.\r\nThe remainder of the report focuses on this non-obvious communication strategy. It describes the behaviour of the\r\nC2 component, the mechanism used to initiate connections to the controlling server, and observable artefacts\r\nindicating preparation for long-term persistence on the device.\r\nPress enter or click to view image in full size\r\nFigure 1. Application configuration parameters.\r\nCommand and Control\r\nThe central component of the infrastructure is an HTTPS-accessible Command-and-Control (C2) server that\r\nfunctions as a device registry, configuration repository, and task-coordination point. The C2 is operated directly by\r\na human operator who manually initiates actions and manages access sessions for individual devices.\r\nhttps://medium.com/@ireneusz.tarnowski/operational-analysis-of-communication-channels-in-mobile-rcs-437f9aad5653\r\nPage 2 of 9\n\nCommunication between the operator and the malicious application is carried out using standard web interfaces or\r\nAPIs, making malicious traffic difficult to distinguish from ordinary HTTPS activity at the network level.\r\nOn the infected device, the BackendApi class manages all communications with the operator’s C2 server. This\r\nmodule performs, among other things:\r\n- device registration within the adversary’s panel,\r\n- heartbeat signaling,\r\n- command retrieval via polling,\r\n- transmission of single or batched events,\r\n- uploading the installed-applications list,\r\n- retrieval of system information,\r\n- transmission of identifiers and complete telemetry.\r\nThe implementation clearly includes a stable device identifier (generateStableDeviceId) based on android_id.\r\nThis method generates a persistent tracking ID that is used throughout the life of the application. At initialization,\r\nthe malware collects environmental data, including:\r\n- battery level and charging state,\r\n- type of network connection,\r\n- currently foreground applications,\r\n- full list of installed applications,\r\n- SIM card information (card presence, operator, phone number, where possible),\r\n- device memory information,\r\n- screen state,\r\n- external IP address.\r\nThis represents device profiling prior to further exploitation and deployment of remote management (RMM). This\r\nprecise victim profile is characteristic of narrow and highly selective attacks in which the adversary tailors\r\nsubsequent infection stages based on the victim’s identity. This approach avoids accidental infections and\r\nincreases the likelihood that it remains undetected.\r\nIf the attack proceeds, the adversary supplies a Fast Reverse Proxy (FRP) tunnel configuration from the C2,\r\nallowing remote access to the device. The FRP parameters (server address, port, token) are delivered dynamically\r\nat runtime and are not hard-coded in the application. The polling and heartbeat mechanisms allow the operator to\r\nregularly issue commands and collect telemetry — including the application list, battery status, network type,\r\nmemory information, SIM details and the currently active application.\r\nThe FRP tunnel, meanwhile, is only started after the malicious backend delivers its configuration. Once\r\nestablished, it enables interactive operator access to the device, while the FRP server itself resides within the\r\nattacker-controlled infrastructure, separate from both the device and the HTTPS communication channel.\r\nFCM — Firebase Cloud Messaging\r\nhttps://medium.com/@ireneusz.tarnowski/operational-analysis-of-communication-channels-in-mobile-rcs-437f9aad5653\r\nPage 3 of 9\n\nThe signalling channel is implemented using Firebase Cloud Messaging (FCM). FCM is a Google service\r\ndesigned for the asynchronous delivery of push messages to mobile applications and web clients. In legitimate\r\nscenarios, it is used to send notifications, synchronize data, or trigger application actions without maintaining a\r\ncontinuous network connection. From a technical perspective, FCM operates as a message broker: after\r\ninstallation, an application registers itself within Google’s infrastructure and receives a unique token or subscribes\r\nto a predefined topic. The application server sends messages to Google and sends them to the intended devices —\r\neven when the application is inactive or the handset is in sleep mode. A critical property of FCM is that network\r\ntraffic flows exclusively between the device and Google infrastructure, meaning that from the perspective of\r\nnetworks and security controls, the communication appears to be legitimate, system-level Android traffic.\r\nFor the FCM functionality, the configuration class (Fig. 1) contains the key parameter:\r\nprivate static final String FCM_TOPIC = “device_commands”;\r\nThis indicates that the application subscribes to a global FCM topic rather than an individual token. Every device\r\non which the application is installed joins the same logical communication channel. In practice, this allows the C2\r\noperator to send a single instruction that Google will distribute to any number of infected devices, without\r\nconnecting to them directly.\r\nGet Ireneusz Tarnowski’s stories in your inbox\r\nJoin Medium for free to get updates from this writer.\r\nRemember me for faster sign in\r\nIn this architecture, FCM is not used to transmit operational data, but to provide asynchronous control signalling.\r\nThe C2 operator sends a push to the device through the Google infrastructure, which is received in\r\nonMessageReceived(). The JSON payload is converted into an internal command identifier, followed by JSON →\r\nexecuteXYZ() mapping — directly translating the signalling message into calls targeting specific functional\r\nmodules of the malware. Each invocation not only launches an action but also activates or reconfigures\r\npersistence and supervision subsystems: FRPC initialization, client re-registration, overlay configuration,\r\nWebSocket channel activation, tunnel authentication, screen-stream setup, heartbeat, and logging. Consequently,\r\nFCM functions as a “wake+task” signalling channel, where the push does not carry the operational command\r\nitself, but instructs the device to retrieve it from the Backend API. This approach reduces power consumption,\r\nminimizes network traces, eliminates cyclic DNS/HTTP polling, and significantly increases stealth.\r\nWith this model, the C2 can issue categories of FCM-driven commands that together provide full functional\r\ncoverage of the device. Communication-layer commands (e.g., executeEnableWebSocket() or\r\nexecuteDisableWebSocket()) enable and disable the WebSocket channel and FRPC tunnel, thus controlling\r\nremote-access capability. Connectivity continuity commands (heartbeat, polling) maintain session availability\r\nwithout periodic telemetry. Instrumentation commands request permissions, restart Accessibility or\r\nMediaProjection services, or bring the application to the front. The screen-capture segment enables or disables\r\nscreen recording and manipulates overlays, allowing adversary-driven interaction. The event-logger layer provides\r\noperator-grade support — logging configuration, counter retrieval, and event flushing. Finally, status-reporting\r\nhttps://medium.com/@ireneusz.tarnowski/operational-analysis-of-communication-channels-in-mobile-rcs-437f9aad5653\r\nPage 4 of 9\n\ncommands (executePing(), updateCommandStatus()) maintain a reporting loop, giving the operator a quasi-RTT\r\nperspective.\r\nOne of the key elements is the launch of an FRP client (frpc — Fast Reverse Proxy Client), which establishes an\r\noutbound reverse-tunnel connection to an intermediary FRP server (frps — Fast Reverse Proxy Server) controlled\r\nby the operator. This tunnel enables remote, interactive access to device functions without exposing any ports on\r\nthe victim side. All communication is initiated as outbound traffic from the device, allowing the malware to\r\nbypass firewalls and NAT restrictions.\r\nThis is precisely the model observed in advanced mobile malware and commercial-grade spyware platforms,\r\nwhere push-based signalling replaces persistent TCP channels and minimizes artefacts, logs, and network-level\r\ndetection opportunities.\r\nFRP — Fast Reverse Proxy\r\nAfter receiving a remote command via FCM, the application first contacts the operator’s Backend API, which\r\nserves as the control layer and distributes the network configuration for remote-access channels. As part of this\r\nexchange, the malware retrieves the current FRP configuration profile, including the FRPS server address, ports,\r\ntunnel type, authorization keys, and any optional parameters related to the WebSocket protocol used for screen\r\nstreaming or control traffic. The FRPC client itself is not compiled into the application code. Instead, it is\r\nextracted from the application resources as an encoded binary file, then decoded, and written to disk as an\r\nexecutable. This allows it to be launched outside the lifecycle of the malware application (Fig. 2).\r\nOnce the proxy client binary is prepared, the application launches FRPC as a separate system process, ensuring\r\nthat the tunnel remains active even if Android terminates the parent malware process. This process establishes an\r\ninitial outbound connection to the FRPS server using the supplied parameters and immediately reports its\r\nauthentication status to the operator. As a result, the client is registered on the FRPS side, allowing the operator to\r\nobserve the infection as an available device identified by a unique identifier. FRPC then transitions into an idle /\r\nkeep-alive state, maintaining the control channel but refraining from establishing active reverse-proxy traffic until\r\nthe operator explicitly requests a session.\r\nPress enter or click to view image in full size\r\nhttps://medium.com/@ireneusz.tarnowski/operational-analysis-of-communication-channels-in-mobile-rcs-437f9aad5653\r\nPage 5 of 9\n\nFigure 2. Class responsible for extracting the FRPC client from the application resources.\r\nAt this stage, the device waits for a remote reverse-connection establishment, i.e., for a scenario in which the\r\nFRPS server opens an inbound port and forwards traffic down the tunnel directly to the handset. When the\r\noperator issues such an initiation, FRPC establishes a specific tunel — TCP, WebSocket, RDP-like, ADB-over-TCP, or screen-streaming — and maps it to a local port on the device. Because the tunnel effectively acts as a port\r\nrouter, the application does not need to expose explicit RAT-style logic. The operator can attach arbitrary tools that\r\noperate locally on the system, such as Accessibility-based WebDriver controls, MediaProjection for screen\r\ncapture, key overlays, or a local shell/terminal.\r\nSubsequently, the tunnel is maintained by FRP heartbeat mechanisms, which in practice means continuous link\r\npersistence without the malware performing periodic beaconing. If the channel is disrupted, the binary\r\nautonomously reconnects; if the system terminates the process, the application restarts it via a resident service.\r\nThis ultimately results in a state where the device remains fully accessible to the operator as a network-reachable\r\nasset, ready for manual, interactive control.\r\nThe established FRP tunnel constitutes the primary operational channel, used for remote sessions that include\r\nsystem interface manipulation, screen capture, application interaction, and other post-compromise activities. The\r\noperator accesses the device through the FRP infrastructure rather than directly, which further complicates the\r\nattribution and attack-topology analysis. All identified network connections are initiated exclusively from the\r\ninfected device. No listening services or direct inbound connections were observed. Communication with the\r\nGoogle infrastructure (FCM), the C2 backend, and the FRP server is conducted using widely adopted protocols\r\nand cloud services, allowing effective blending of malicious traffic into legitimate network background noise.\r\nPress enter or click to view image in full size\r\nhttps://medium.com/@ireneusz.tarnowski/operational-analysis-of-communication-channels-in-mobile-rcs-437f9aad5653\r\nPage 6 of 9\n\nFigure 3. Communication flow between FCM, FRPC, and FRPS modules.\r\nAlthough malware maintains a conventional HTTPS channel to the Backend API — used primarily for\r\nconfiguration retrieval, command acknowledgements, session parameter updates, and status reporting — this\r\nchannel does not serve as the transactional layer for remote device control. The Backend API fulfills a signalling\r\nand administrative role (control logic, telemetry, device registration), while the persistent and operational\r\nhttps://medium.com/@ireneusz.tarnowski/operational-analysis-of-communication-channels-in-mobile-rcs-437f9aad5653\r\nPage 7 of 9\n\nfunctionality is delegated to a dedicated FRPC process, launched as a separate system process and maintaining a\r\ncontinuous reverse-proxy channel.\r\nAs a result, communication is explicitly divided into three layers: FCM acting as an asynchronous wake-up\r\nmechanism, Backend API functioning as the malware’s administrative control panel, and FRP serving as the actual\r\noperational channel that materializes remote access to the device.\r\nSummary\r\nThe applied architecture — featuring separation of communication channels, the use of external cloud\r\ninfrastructure for signalling, and manually operated interactive access — clearly indicates an advanced operational\r\nmodel. Such solutions are characteristic of targeted, operator-driven activities, rather than mass-scale, fully\r\nautomated malware campaigns.\r\nNo attribution effort was undertaken for this malware. The identified campaign exhibits traits of a highly targeted\r\nand deliberately planned operation, which justifies its classification as APT-grade malware. In this case, the\r\noperator does not rely on a broad distribution but instead conducts activities requiring precise, sustained control\r\nover a single device. The use of a reverse communication model, dynamic retrieval of operational parameters, and\r\nFRP tunnelling capabilities point to an operational requirement for long-term, low-visibility access, consistent\r\nwith the tradecraft of APT groups or advanced cybercrime-as-a-service providers.\r\nAt the infrastructure level, the observed domain was active for approximately ten days, during which time it was\r\nregistered, provisioned with an SSL certificate, and subsequently decommissioned after the operational phase was\r\ncompleted. This sequence — short exposure window, enforced encrypted communications and rapid abandonment\r\nof infrastructure — aligns with a “burn-after-use” infrastructure model, commonly employed in campaigns that\r\nassume the risk of operator deanonymization. This behaviour is not typical of low-tier cybercrime operations,\r\nwhich often rely on inexpensive, long-lived domains, reused panels, or cost-constrained rotation. In this case, the\r\noperational cost and the intent to minimize forensic traces are clearly visible.\r\nThe communication vector further demonstrates that the software is not a conventional trojan but rather an access-and-surveillance mechanism. The application maintains operator control through FCM push signalling, performs\r\ntelemetry-based heartbeat operations, retrieves C2 configuration, and activates a Fast Reverse Proxy client using\r\ndynamically distributed parameters. The result is a bidirectional access channel in the user’s ecosystem, enabling\r\nexposure of local services without requiring a public IP address on the victim side.\r\nSamples are generated and modified on a per-instal basis; FRP configuration is retrieved ephemerally for each\r\nexecu The FRP, and domains and certificates exhibit a deliberately short lifespan. These characteristics prevent the\r\ncreation of traditional detection signatures and further suggest that an actor employs strong operational security\r\npractices, deliberate infrastructure rotation, and minimization of retrospectively detectable artefacts.\r\nConsequently, the analyzed code should not be considered commodity malware, but rather a tool capable of\r\nprecise device control, covert communications, and sustained operator oversight, placing it squarely within the\r\nspectrum of TTPs used by APT groups or entities offering comparable commercial capabilities.\r\nhttps://medium.com/@ireneusz.tarnowski/operational-analysis-of-communication-channels-in-mobile-rcs-437f9aad5653\r\nPage 8 of 9\n\nFrom an attribution perspective, it should be noted that the sample exhibits two distinctly different approaches to\r\ncode obfuscation, both deviating from standard practices commonly observed in mobile malware. Once the\r\nprimary application component is decrypted, the codebase remains coherent and readable: class, method, and\r\nvariable names are preserved; there is no evidence of automated obfuscation; and some modules even implement\r\nlocal file-based event logging — an uncommon feature in malware designed purely for concealment. This profile\r\nsuggests a high level of software engineering competence and development practices more typical of professional\r\nsoftware production than of malware authored solely for illicit distribution.\r\nAt the same time, a different layer of application — covering the operational “engine” and structural dependencies\r\n— is clearly obfuscated. Classes lack semantic naming, and structures rely on automatically generated field\r\nidentifiers and index-based mappings (e.g., SparseIntArray → index → value), complicating the reconstruction of\r\nthe logical flow. This divergence suggests a development process in which portions of the code may have been\r\nderived from an existing, legitimate codebase (or maintained by experienced developers), while the operational\r\ncomponents –responsible for class bindings, runtime parameters, and execution logic — were subjected to\r\nautomated obfuscation at a later stage. It cannot be ruled out that the development was conducted collaboratively\r\nand that some contributors may not have been fully aware of the operational purpose of the application.\r\nEND OF ANALYSIS — 21 December 2025 (IR3k)\r\nThe above analysis does not cover the topic exhaustively and focuses solely on selected, noteworthy functionalities\r\nof this malware. The malware itself contains numerous additional features that could be described; however, this\r\nanalysis concentrates exclusively on communication-related components. The purpose of this report is\r\neducational, illustrating alternative and advanced techniques implemented in professional-grade malware. Any\r\ninaccuracies or errors that may appear are unintentional.\r\nThis analysis has been published on the CERT Orange Polska portal at:\r\nhttps://cert.orange.pl/aktualnosci/operacyjna-analiza-kanalow-komunikacyjnych-mobilnego-rcsa/\r\nSource: https://medium.com/@ireneusz.tarnowski/operational-analysis-of-communication-channels-in-mobile-rcs-437f9aad5653\r\nhttps://medium.com/@ireneusz.tarnowski/operational-analysis-of-communication-channels-in-mobile-rcs-437f9aad5653\r\nPage 9 of 9",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://medium.com/@ireneusz.tarnowski/operational-analysis-of-communication-channels-in-mobile-rcs-437f9aad5653"
	],
	"report_names": [
		"operational-analysis-of-communication-channels-in-mobile-rcs-437f9aad5653"
	],
	"threat_actors": [],
	"ts_created_at": 1775434349,
	"ts_updated_at": 1775791274,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/9ad55b68207a448474f199825cb0784c9e29cfc8.pdf",
		"text": "https://archive.orkl.eu/9ad55b68207a448474f199825cb0784c9e29cfc8.txt",
		"img": "https://archive.orkl.eu/9ad55b68207a448474f199825cb0784c9e29cfc8.jpg"
	}
}