Uncovering ArcticRAT: The Evolution from Targeted Crypto-Stealer to AI-Powered Android RAT

Executive Summary

The zLabs research team has been tracking a highly sophisticated and rapidly evolving Android Malware, ArcticRAT . What initially began as a targeted spyware operation aimed at users of 11 specific cryptocurrency apps has morphed into an enterprise grade, AI-powered, Remote Access Trojan (RAT). The malware was named ArcticRAT based on distinct package naming conventions identified in early samples, such as net.iceflow.arcticlink and net.frostlink.iceforge .

Throughout our investigation, zLabs identified 78 unique malware samples , 42 distinct dropper samples , 36 unique payloads and 21 C2 IP addresses powering the infrastructure. Across the evolution of these variants, we cataloged a total of 129 distinct commands embedded within the malware's control code.

The latest variants of ArcticRAT demonstrate a dangerous escalation in mobile threat tactics. By abandoning hardcoded attacks in favor of real-time Hidden VNC (HVNC), raw TCP command-and-control (C2), and aggressive defense evasion overlays, the malware achieves complete device takeover. Most notably, the threat actors have integrated Large Language Model (LLM) APIs directly into the malware's data exfiltration pipeline, allowing them to use AI to automatically parse and extract high-value financial intelligence from stolen SMS messages and app data. This initial integration of AI capabilities was first identified in samples analyzed around mid-July 2026.

Through our investigation, we have mapped the timeline of this campaign, tracking its deployment across multiple months as the developers rapidly iterated their codebase to expand their victim pool, as shown in Figure 1. The timeline reveals July 2026 as a critical turning point for the threat actors, in which the use of AI became prevalent, phase 1 arises.

Fig.1: Timeline of the ArcticRAT samples found in the wild. What is shown as phase 1 corresponds to the threat actor's pivot to the use of AI.

To maximize infection rates, the campaign relies on a broad social engineering net. Across the analyzed samples, the threat actors impersonated a variety of highly trusted consumer brands and utilities, including Amazon, generic file managers, TikTok, and popular crypto applications to trick users into downloading the malicious apps.

Infection Vector

The infection chain begins when a user lands on a malicious site distributed through malvertising, smishing, or third-party forums. Across the distinct dropper samples identified during our research, the primary attack vector relied on a landing page that convincingly impersonated Google Play to trick targets into downloading a malicious application ( Figure 2 ). In addition to standalone phishing infrastructure, researchers also observed payload delivery originating directly from Amazon Web Services (AWS) buckets.

Fig.2: Phishing website impersonating Google Play and distributing the ArcticRAT dropper

Technical Analysis

During our research into ArcticRAT, we identified two distinct variants of the family. Consistent with earlier iterations, the latest version abuses Android Accessibility Services to establish remote control and automate fraudulent activity. However, this update significantly expands the malware's capabilities by introducing novel C2 commands that leverage AI to parse and "clean" exfiltrated data.

Operating initially as a dropper, the malware requests VPN service privileges to null-route network communication on the victim's device, effectively blinding Google Play Protect telemetry during the staging phase. This network suppression is executed via the following decrypted code:

To secure these permissions, the dropper renders a fake installation interface ( Figure 3 ) via a WebView to deceive the user. Once the isolated network environment is established, the malware decrypts the primary payload from its internal assets folder, executes the installation via the native Android session installer, and immediately terminates the VPN connection.

Fig.3: Amazon app (dropper) UI installing the secondary payload

Network Infrastructure and C2 Communication

Note: All C2 commands, variables, and code snippets in this report are transcribed exactly as they appear in the malware's source code, including the threat actor's original typographical errors.

ArcticRAT utilizes direct TCP sockets to communicate with its C2 infrastructure. Analysis of the malware family revealed 17 distinct C2 IP addresses . Two thirds of these addresses point to Hong Kong , while 20% of them point to Germany. The rest are distributed through several other countries.

The malware relies on a robust configuration block that dictates its target IP, ports, and the victim's language settings for localized attacks, as shown in Figure 4.

Fig.4: The configuration of the ArcticRAT, showing C2 IP, port, user language, etc.

The malware establishes multi-port socket connections, segregating Command-and-Control (C2) communication channels between the compromised device and the server as can be observed on Figure 5 .

Fig.5: Commands captured during the dynamic analysis of the samples.

Once the accessibility permission is accepted on the payload app the communication starts from victims to the C2 server establishing a connection via the mainport (9999), the malware performs extensive host reconnaissance. It builds a detailed DEVINFO JSON payload containing critical system telemetry, including battery levels , screen states (e.g., SCREEN_OFF, UNLOCKED), and Wi-Fi connectivity.

To evade sandbox analysis and confirm execution on a legitimate physical device, the malware also captures the user's current wallpaper. This telemetry is then exfiltrated to the C2 server, as illustrated in Figure 6 .

Fig.6: Device information (DEVINFO) sent to the server via sockets using mainport

Analysis of samples spanning versions v6.3 through v6.5.2 demonstrates that this malware family is under active, continuous development.

Following initial reconnaissance, the malware does not execute its payloads automatically. Instead, the C2 server dynamically selects which attack routines to deploy based on the victim's host profile. To support this modular architecture, the malware utilizes specialized network ports for different attack vectors. As illustrated in Figure 5 , the source code hardcodes the main server port (mainport = 9999) alongside dedicated channels like the HVNC port (8888) and the mic streaming port (5000) to handle specific surveillance and control capabilities simultaneously.

During network traffic monitoring, the following C2 commands were captured and analyzed across the functional categories shown in the next sections.

Data Exfiltration & Surveillance

Traffic analysis revealed outbound exfiltration containing sensitive host parameters, including real-time device geolocation, active foreground activity, and screen lock status.

Media Capture & Full Remote Control

The C2 server issued the <Screen_Cast> command to initiate a real-time screen transmission feed from the compromised device. This video stream was established over a dedicated secondary socket ( sc_cast_serverPort , operating on port 5055 ).

Analysis also uncovered specialized C2 traffic dedicated to Accessibility Service remote control features. On the scren_redrport channel (port 5058 ), researchers captured specific command interactions, which are initiated after the primary channel dispatches the <Str_Red_Ser> directive:

• <layout_spped:661> : Modifies the polling rate and screen redrawing interval of the target view tree to 661ms.
• <STOP.cleanupSock> : Allows the C2 operator to terminate the socket and release system handles gracefully.

To facilitate full remote control, operators issue the <screen_runrun> directive over the dedicated HVNC port (8888), instantiating an in-memory virtual display. Leveraging Android's native MediaProjection and VirtualDisplay frameworks, the threat actor initiates headless video harvesting upon dispatching the <START_CAPTURE> control signal. Screen frames are continually exfiltrated as JPEG-encoded binaries, structured with standardized header metadata: [Header]|[Timestamp]|[JPEG Size in Bytes]|[Width]|[Height].

Device Administration & Anti-Analysis

During dynamic analysis, researchers observed the C2 server issuing the <apk_remove> directive, initiating self-uninstallation sequences designed to thwart forensic examination. Though sharing structural similarities, the distinct <DELETE> directive provides operators with the precise capability to remove explicit target package names ( packageName ) programmatically from the compromised device.

A comprehensive cataloging of all control directives identified across analyzed samples is compiled in this repository .

ArcticRAT Capabilities

Extortion Overlay: Deceptive Ransomware Module

The malware includes a fake ransomware module (screenlocker) that simulates blocking user access to infected Android devices, as shown in Figure 7 . Even though the malware does not perform actual disk or file encryption, it relies entirely on psychological pressure tactics, displaying an infinitely-looping progress bar to falsely indicate active file encryption. Note that the cryptocurrency payment addresses displayed in Figure 7 serve as example placeholders, as these addresses are updated dynamically by the threat actors during operation.

The deployment of the extortion interface follows a strict two-stage command sequence initiated by the Command-and-Control (C2) server:

• Stage 1 ( <Attack_run> ): Renders the initial overlay framework using a hardcoded default extortion template, effectively trapping the user on the lock screen.
• Stage 2 ( <Attack_costom> ): Injects dynamic content into the active overlay to customize the ransom note and evade static signature detection.

Fig.7: Ransomware overlay screen presented by the app

AI-Powered Data Analysis

Mirroring developments observed in RatHat , the most significant technical evolution in ArcticRAT lies in its leverage of Large Language Model (LLM) frameworks to streamline automated financial intelligence gathering. To bypass the operational bottleneck of manually sifting through extensive exfiltrated datasets, the operators incorporated the specialized <xAI_API> control directive.

Upon activation, the C2 server dispatches an API key to the compromised device, initiating tailored, pre-configured instructions against harvested telemetry.

The initial prompt functions as an app analyzer , compelling the LLM to inspect installed applications and filter target software pertaining to banking, cryptocurrency, or trading platforms, as illustrated in Figure 8 .

Fig.8: Hardcoded AI prompt found in the second variant for device app analysis

A second prompt processes the SMS messages harvested from the infected device. This instruction compels the model to discard promotional noise while isolating high-value financial intelligence, such as single-use authentication codes, account balance modifications, and transfer notices.

Furthermore, the instruction directs the LLM to project the target's financial standing from surrounding text patterns, serializing the final analysis into a structured JSON payload for exfiltration, as shown in Figure 9 .

Fig.9: Hardcoded AI prompt found in the second variant for SMS analysis and financial filtering

During dynamic analysis, the sample was observed integrating Large Language Model (LLM) capabilities by querying the xAI API using the grok-4.20-0309-non-reasoning model. The generated responses are cached locally in JSON format within the path /storage/emulated/0/config/AI_DATA/ .

Upon receiving the specific C2 command <Get_AI_ANA_Data> , the malware retrieves these stored JSON artifacts and exfiltrates their contents back to the Command-and-Control (C2) infrastructure via a socket connection.

Espionage, Keylogging, and HVNC

Once Accessibility Services privileges are granted, the threat actor leverages ArcticRAT as an intrusive surveillance framework. The malware dynamically traverses the target view tree and extracts credentials, authentication codes, and private communications directly from active input views. Captured intelligence is cached locally within a hidden staging environment created under the /storage/emulated/0/config/ path prior to C2 exfiltration.

To organize the exfiltrated telemetry, the malware categorizes its staging repository into dedicated folders based on data type:

• /storage/emulated/0/config/System/ : Caches keystroke logs into date-stamped JSON artifacts, capturing user authentication inputs and typed strings.
• /storage/emulated/0/config/Click_data/ : Contains touch interaction sequences, gesture recordings, and automated click parameters executed during UI manipulation.
• /storage/emulated/0/config/screenshot/ : Stores covert screen grabs gathered continuously during active surveillance operations.

As shown in Figure 10 , each operative day generates a unique JSON file containing the victim's keystrokes, stored predictably within the /config/System/ directory.

Fig.10: Keylogging data stored locally at the path /config/System/ (each date has one JSON file)

To prevent the user from interfering with these operations, ArcticRAT employs a defense evasion tactic known as a "Black Screen" overlay. When the attacker is navigating banking apps via Hidden VNC (HVNC) or auto-approving system permissions, the malware draws a completely black, un-dismissible view over the screen and drops the brightness to zero. To the victim, the device appears locked or powered off, as demonstrated in Figure 11.

Fig.11: "Screen is locked" black overlay utilized for hiding the behaviour on the device

Stealing device lock screen credentials via overlays

To harvest device access credentials, the threat actors deploy a high-fidelity screenlocker interface ( Figure 12 ) directly over the system lock display. This deceptive view intercepts user inputs to capture the victim's pattern, PIN, or password . The routine is initiated upon receipt of the dedicated C2 directive <Phsing> , which instantiates the localized overlay and logs the entered authentication factors.

Fig.12: Pattern, Pin & Password lock overlay

While the underlying XML layout of this phishing module incorporates hardcoded default strings (such as "test"), these static parameters are overridden during execution. The threat actors leverage a modular directive framework (e.g., Phsing:PATTERN:[Main_Title]:[Bottom_Title]:[Max_Attempts] ) dispatched directly from the Command-and-Control (C2) infrastructure. Upon receipt, the payload intercepts layout rendering and dynamically populates these dynamic variables into active view components, specifically targeting elements like txtLockTitlePattern and txtLockSubtitlePattern . This localized overlay injection enables operators to tailor social engineering strings to the target's regional settings in real time, eliminating the operational overhead of bundling static resource files.

Upon pattern completion or submission, the payload dispatches a robust, dual-stage exfiltration mechanism. If the primary Command-and-Control (C2) socket remains active, the intercepted authentication factors are transmitted instantly. To ensure persistence, the malware simultaneously caches the exfiltrated telemetry into a localized, hidden artifact stored under /storage/emulated/0/config/phis_info/phish_logs.txt . This offline staging repository enables operators to retroactively fetch historical logs upon dispatching the dedicated <Phsing_data-get> directive.

To mathematically confirm stolen authentication factors, the C2 server issues the <verify_credential> [password] control directive. The routine silently executes the underlying OS-level shell command locksettings verify --old [password] in the background, validating credentials directly against system security without triggering visible prompts. Upon receiving a successful execution signal, the operator dispatches the final <Phsing_off> directive.

Privilege Escalation Via Local Wireless ADB abuse

Recent iterations of ArcticRAT began abusing the native Wireless Debugging mechanism. Originally introduced in Android 11, this OS feature permits developers to execute Android Debug Bridge (ADB) operations and debug target applications wirelessly over Wi-Fi, completely bypassing the necessity for physical USB connectivity.

The malware implements a Wireless ADB pairing routine to instantiate a privileged shell session on the victim machine. A technical breakdown of the individual control directives and shell operations identified within the C2 socket handler includes:

Connection & Setup

• adb_search_pair: Initiates a Multicast DNS (mDNS) scan for the _adb-tls-pairing._tcp service. Once discovered, the malware uses Android's native NsdManager API to automatically resolve the service instance, extracting the underlying raw IP address and randomized pairing port to exfiltrate back to the C2.
• con_adb_systeam: Executes the TLS handshake to authenticate the local ADB connection. It uses the dynamic host and port resolved by the adb_search_pair scan, combined with the 6-digit pairing code manually supplied by the attacker through the C2 panel.
• stop_adb_manager: Terminates the active ADB pairing coroutines (disconnect_adb_pair) to erase the active memory footprint of the connection attempt.

Privilege & Security Manipulation

• get_adb_app_info : Opens a privileged shell to execute dumpsys lock_settings | grep 'CredentialType:'. It parses the OS-level lock configuration and returns a comprehensive JSON payload to the C2 containing the screen_lock_type (PIN/Pattern/Password), information if the device is locked or not, and the active status of both ADB and the Accessibility Service.
• enable_accessibility_services : Leverages the ADB shell to silently force-enable its own accessibility permissions.
• disable_accessibility_services : Silently disables accessibility services via shell command.

Lock Screen Subversion

• verify_credential : Silently executes the native shell command locksettings verify --old "[credential]" to mathematically confirm a stolen PIN or Pattern directly against the operating system.
• adb_clear_lock : Executes locksettings clear --old "[password]" via the shell to completely strip the victim's lock screen security.
• adb_set_password / adb_set_pin / adb_set_pattern : Executes locksettings set-[type] "[value]" via the shell, allowing the attacker to completely lock the victim out of their own device by setting a new, unknown code.

Visual Evasion

• adb_black_sc : Deploys a persistent black screen overlay (black_screen job) to visually blind the user while the attacker executes visible background operations.
• adb_black_hiden : Kills the black screen overlay (adb_stop_black job) once the malicious operations are complete, returning normal screen visibility to the victim.

Zimperium vs. ArcticRAT

As mobile trojan threats like ArcticRAT become increasingly sophisticated, conventional signature-based security layers are no longer sufficient to protect enterprise mobile endpoints. Zimperium provides comprehensive, multi-layered protection designed to disrupt every stage of the ArcticRAT execution chain.

• Advanced Malware and Dropper Detection: Both Zimperium MTD ( Mobile Threat Defense ) and zDefend ( Mobile Application Runtime Protection ) are engineered to detect both the initial low-profile dropper sample and the heavily obfuscated dynamic payloads used in this campaign. By utilizing its AI-powered on-device dynamic detection engine, Zimperium stops the infection chain before the core malicious dex payloads can be dynamically loaded into memory.
• Phishing and C2 Domain Mitigation: ArcticRAT relies heavily on spoofed domains such as the malicious websites for both initial infection and subsequent data exfiltration. Zimperium MTD's Web Content Filtering actively monitors and blocks access to these known malicious pathways. This protects users at the point of ingress by preventing the initial download, and acts as a safety net by severing communications to Command and Control (C2) servers if an infected device attempts to exfiltrate stolen assets.
• Zimperium's Mobile App Vetting (MAV) and Web Content Filtering (WCF) work together to neutralize advanced AI-powered threats like ArcticRAT by providing both continuous and proactive app vetting and real-time network defense. MAV rigorously scans applications to uncover hidden malicious behaviors, risky code and embedded Large Language Model (LLM) API integrations that applications like those associated with ArcticRAT uses to automatically parse and extract intelligence from stolen data. Meanwhile, Web Content Filtering operates directly on the device to block the spoofed domains used to distribute the malware's initial droppers. It further enforces AI governance and data security by detecting and blocking connections to C2 servers from apps and the browser on the device. This prevents malware from exfiltrating stolen SMS messages or financial data.
• Behavioral Indicators and Anti-Fraud Telemetry: This iteration of ArcticRAT aggressively abuses legitimate Android framework features, such as the Media Projection API for unauthorized screen sharing and Accessibility Services for screen scraping. Customers with zDefend protected apps can detect these fraud indicators on the device in real time. By identifying when active screen sharing or overlay injections are occurring during sensitive financial sessions, the protected app can flag behavioral anomalies instantly and prevent biometric or credential theft as it happens.

MITRE ATT&CK Techniques

To help our customers and the industry understand the impact of this malware, Zimperium has compiled the following table containing the MITRE Tactics and Techniques as reference.

Indicators of Compromise

The full list of IOCs can be found in this repository .