Acronis Threat Research Unit (TRU) has identified a targeted campaign distributing a trojanized version of the Red Alert rocket warning Android app to Israeli users via SMS messages impersonating official Home Front Command communications.
Author: Subhajeet Singha
Acronis Threat Research Unit (TRU) has been actively monitoring malware campaigns and threat activity leveraging recent geopolitical developments across the Middle East and abusing these events to deliver malware to individuals. During our investigation, TRU identified a targeted campaign distributing a trojanized version of the Red Alert rocket warning Android app to Israeli users via SMS messages impersonating official Home Front Command communications, aimed at Israeli individuals.
The activity stood out due to its use of an emergency-themed lure, which our researchers discovered on March 1 while hunting for malicious threats, and reported by multiple Israeli citizens on social media.
The trojanized application mimics the legitimate Red Alert — Israel (צבע אדום) app used by millions of Israeli citizens to receive real-time rocket and missile alert notifications. This makes it an exceptionally effective social engineering vector; during periods of active conflict, the urgency to install or update such an application overrides the caution users might otherwise exercise, particularly when the delivery message appears to originate from the Home Front Command (פיקוד העורף).
This report provides a detailed analysis of the full infection chain, from the initial SMS delivery through dropper execution and deployment of the embedded spyware payload.
Numerous regional threat actors, ranging from hacktivist groups to nation-state-aligned operators, have been targeting individuals and organizations across national borders. Their activities have included claims of distributed denial-of-service (DDoS) attacks, attempted intrusions into critical infrastructure, and other disruptive operations. Groups such as Handala and other MOIS-affiliated actors have been particularly prominent in recent years.
Operationally, while tracking this cluster of activity, we found multiple accounts of individuals who have been claiming that they have been receiving messages with shortened links to download and install software which is primarily used as an alerting mechanism for rocket strikes.
One similar attack during 2023 which was attributed to the hacktivist group AnonGhost features some striking similarities, though the attack we’ve analyzed seems to contain a new infrastructure and code in some parts.
Our investigation began after identifying a smishing campaign targeting Israeli citizens. The campaign used SMS messages impersonating the official “Oref Alert” rocket warning service, urging recipients to install an updated version of the application due to an alleged alert malfunction. The messages, distributed from spoofed sender IDs, contained a bit.ly shortened link redirecting victims to download a trojanized APK masquerading as the legitimate Red Alert application.
The use of link-shortening services, combined with the urgency of updating an existing application associated with public safety, prompted us to analyze the malicious application, its capabilities and the infrastructure used to control the malware and exfiltrate harvested data and credentials.
App name: RedAlert.apk
Package name: com.red.alertx
SHA256 hash: 83651b0589665b112687f0858bfe2832ca317ba75e700c91ac34025ee6578b72
By examining the AndroidManifest.xml file, we found that the application requests a total of 20 permissions. Among these, six are used in ways that we consider security-sensitive due to their potential for abuse. The spyware leverages these permissions to collect and exfiltrate user data.
The combination of overlay permissions and SMS access is commonly observed in Android banking trojans and spyware campaigns, enabling attackers to exfiltrate sensitive messages such as one-time passwords (OTPs).
Initially, by analyzing the code and renaming classes and methods that contained obfuscated identifiers, we identified that the application does not only operate as spyware, but also as a loader, so we renamed the class to IPackageManagerSignatureProxyLoader, which hooks the system’s IPackageManager using a dynamic proxy. It accesses ActivityThread through reflection and replaces the original sPackageManager field with its own proxy object. This allows the app to intercept system calls such as getPackageInfo() and modify the returned data. When the system requests the app’s signature, the loader replaces it with a forged signature, allowing the malicious package (com.red.alertx) to masquerade as the legitimate application
The certificate used for spoofing is hardcoded in Base64 format. In both IPackageManagerSignatureProxyLoader and the separate FakeSignatureProvider class, the Base64 string is decoded and converted into a Signature[] object. The FakeSignatureProvider specifically targets newer Android versions by overriding methods like getApkContentsSigners() and getSigningCertificateHistory() from the SigningInfo API. This confirms that the malware supports both older and newer Android signature verification mechanisms. In addition, the loader also spoofs the installer source by forcing getInstallerPackageName() to return com.android.vending, making the app appear as if it was installed from Google Play.
The second stage of the code involves loading the original legitimate application from the assets folder. The file named umgdn is extracted and written to the app’s private directory under /data/user/0/com.red.alertx/files/. After writing the file, the loader modifies internal Android runtime fields such as mAppDir, sourceDir and publicSourceDir inside ActivityThread. This forces the Android system to execute the extracted legitimate application instead of the visible dropper package. As a result, the app continues to function normally and display real alerts, while the hidden spyware component runs silently in the background.
The initial capability of this spyware component is triggered immediately after SMS permission is granted by the user. As shown in the code snippet, the overridden onSmsPermissionGranted() method invokes a function that queries Telephony.Sms.CONTENT_URI, which provides access to the device’s entire SMS database, meaning that the malware is designed for immediate extraction of the device’s contact list.
The next feature of this malware is to access the device’s contact list immediately after the Contacts permission is granted. As observed in the overridden onContactsPermissionGranted() method, the spyware queries ContactsContract.Contacts.CONTENT_URI, which provides access to stored contact entries on the device. This confirms that the malware actively monitors permission approvals and triggers data collection routines without delay.
Further analysis indicates that the contact harvesting process is not limited to basic names. The spyware performs multiple content provider queries to extract associated phone numbers and email addresses, typically through CommonDataKinds.Phone and CommonDataKinds.Email content URIs. This allows the malware to build a structured dataset containing contact names, phone numbers, email addresses and potentially additional metadata linked to each entry.
The malware also accesses the device’s GPS / location information and uses it to decide when certain actions should run. In the Maynt() method, it retrieves the device’s current location through a helper function, which internally calls the app’s location management component. It then retrieves another set of coordinates that likely represent a predefined target area, such as a specific city or alert zone. The malware calculates the distance between the victim’s current GPS location and this target location using Android’s location API. If the device is within a configured radius, the function allows further operations to proceed. This means the spyware does not just collect location data; it actively uses the device’s GPS information to conditionally trigger behavior based on the location of the victim. 
Then, looking into the further capabilities, the malware also implements account extraction functionality using Android’s AccountManager. In the Shatters() method, the spyware dynamically resolves and invokes an internal method of the AccountManager class using Java reflection. Instead of directly calling getAccounts(), it retrieves the method name at runtime and executes it programmatically. This technique is used to obscure malicious behavior, hindering static analysis efforts. The returned result is cast to an Account[], confirming that the malware retrieves a full list of accounts registered on the device. These accounts typically include Google accounts, email accounts, messaging services and other applications integrated with the Android account system.
Another significant capability of the malware is the enumeration of all applications installed on the infected device. In the Unflush() method, the spyware retrieves the system PackageManager and requests the full list of installed applications using a metadata flag. It then iterates through each ApplicationInfo entry and constructs a structured JSON object for every application. These entries are collected into an array and transmitted to the remote server in batches of 200 applications at a time, with any remaining entries sent after the loop completes. This behavior confirms that the malware performs systematic reconnaissance of the device’s installed software, allowing the attacker to profile the victim’s digital environment, identify security tools, financial applications, messaging platforms and other high-value targets.
While analyzing, we found that the application is repeatedly obfuscated and encoded to resist static analysis and reverse engineering. Most string literals are Base64-encoded and then decrypted at runtime using a unique 32-byte XOR key for different string literals across the codebase, preventing analysts from easily extracting meaningful constants like URLs or intent actions. Additionally, method and class names have been aggressively renamed to random identifiers, and trivial wrapper functions are inserted to obscure real control flow.
The command-and-control (C2) infrastructure is hardcoded within the application and protected using layered string obfuscation. The URL is stored in Base64 format and further encrypted using a 32-byte XOR key, which is decoded at runtime and upon decryption, the endpoint resolves to hxxps://api[.]ra-backup[.]com/analytics/submit[.]php, which confirms that all the data which is harvested to the command-and-control server.
Looking into the C2 domain, it was registered through Namecheap and was created in mid-2025, making it relatively fresh infrastructure which is a common pattern with disposable C2 domains spun up for specific campaigns. The subdomain api[.]ra-backup[.]com hosts the exfiltration endpoint at /analytics/submit.php, which currently returns a 404, suggesting the C2 is either gated behind specific request headers or has been taken down.
Based on the available evidence, we assess that this campaign might be linked to Arid Viper (also known as APT-C-23). This assessment is supported by several indicators, including the use of a trojanized Android application, the focus on Israeli targets and spyware functionality consistent with capabilities previously attributed to this group.
While these indicators are not unique to Arid Viper and have been observed in other Android surveillance campaigns, the convergence of targeting patterns, tooling characteristics, and operational behavior suggests a possible connection to this threat actor.
This campaign illustrates how trusted emergency infrastructure can be exploited during periods of conflict to amplify the effectiveness of social engineering and facilitate data collection. By embedding spyware within a fully functional alert application, the operators were able to preserve user trust while covertly collecting sensitive information.
The combination of targeted distribution, spyware capabilities and multiple layers of obfuscation suggests a capable and well-resourced threat actor operating with clear objectives.
The following mitigations are recommended for individuals and organizations potentially affected by this campaign:

source