Summary
- 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.
- The malicious app retains full rocket alert functionality, allowing it to appear legitimate while running malicious code in the background.
- The threat actor implemented certificate spoofing and runtime manipulation techniques to bypass Android security checks and make the application appear legitimately signed.
- Once installed, the malware monitors granted permissions and begins collecting sensitive data, including SMS messages, contacts, location data, device accounts and installed applications.
- Stolen data is staged locally and continuously transmitted to a remote command-and-control (C2) server controlled by the attackers.
- This campaign highlights how trusted emergency services can be weaponized during periods of geopolitical tension, combining social engineering with mobile espionage to exploit user trust and maximize impact.
Introduction
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.
Background and context
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.
Infection chain
Technical details
Initial analysis and delivery mechanism
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.
Timeline
Sample overview and metadata
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).
Dual-stage architecture
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.
Capabilities
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.
Obfuscation and anti-analysis
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.
Command-and-control infrastructure
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.
Infrastructure pivoting
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.
Attribution
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.
Conclusion
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.
MITRE ATT&CK
Recommendations and mitigations
The following mitigations are recommended for individuals and organizations potentially affected by this campaign:
- Install applications only from official sources. The legitimate Red Alert app is available exclusively through the Google Play Store. Users should never sideload APKs from SMS links, shortened URLs or third-party websites, regardless of how urgent the message appears.
- Verify sender identity before acting on SMS messages. The Home Front Command does not distribute application updates via SMS with shortened links. Any message urging an immediate app update through a bit.ly or similar link should be treated as suspicious.
- Review application permissions carefully. The legitimate Red Alert app only requires notification access. If an app claiming to be Red Alert requests SMS, contacts, location or overlay permissions during installation, it is almost certainly malicious.
- Audit installed applications on potentially compromised devices. Check for the package name com.red.alertx and remove it immediately. A full factory reset is recommended for confirmed infections, as the malware’s dual-stage architecture may leave residual components after a standard uninstall.
- Block known C2 infrastructure at the network level. Organizations should add ra-backup[.]com and api[.]ra-backup[.]com to DNS blocklists and firewall deny rules. The C2 endpoint hxxps://api[.]ra-backup[.]com/analytics/submit[.]php should be flagged in proxy and EDR policies.
- Revoke and rotate credentials on affected devices. Because the malware harvests SMS (including OTPs), contacts and device accounts, any accounts authenticated on a compromised device should be considered exposed. Rotate passwords and revoke active sessions for Google, email, banking and messaging accounts.
- Enable Google Play Protect and keep it active. Play Protect provides an additional layer of defense against sideloaded malicious APKs and can flag known threats before installation.
- Report suspicious SMS messages to CERT-IL and relevant national authorities to support broader threat tracking and takedown of the delivery infrastructure.