The 'Red Alert' Urgent Phishing Campaign: Analysis of an Iranian-Linked Android Infostealer

Author: Yarin Leibovich

Executive Summary

On March 1, 2026, a phishing campaign targeted Israeli mobile users via SMS. The messages urged recipients to immediately update their “Red Alert” (Color Red) application, citing a critical failure in the emergency notification system. The attackers utilized SMS spoofing to impersonate ‘Oref Alert’, designed to mimic Pikud HaOref (the IDF Home Front Command).

Phishing SMS Sent By Malicious Actors

This article reveals the static analysis of a malicious android app pretending to be “Red Alert”, an Israeli open source early missile warning app. The trojanized application acts as an infostealer, utilizing wrappers, java reflection, and string obfuscation to hide its core functionality.

Once executed, it systematically exfiltrates SMS messages, contacts, location data, installed applications, and account credentials to a remote server.

Sample Information

Manifest & Permissions Analysis

Malicious app AndroidManifest.xml

Initial inspection of the AndroidManifest.xml reveals a highly suspicious used permissions. The requested permissions align directly with an infostealer objectives:

• INTERNET & RECEIVE_BOOT_COMPLETED (Persistence and communication)
• ACCESS_FINE_LOCATION (Geolocation tracking)
• READ_SMS (SMS exfiltration / OTP interception)
• READ_CONTACTS (Contact harvesting)
• QUERY_ALL_PACKAGES (Software enumeration)

Note: During the manifest analysis, a hardcoded Google Maps API key was also discovered exposed within the metadata.

Entry Point: Diffing the Trojanized Code

Early research revealed that the original ‘Red Alert’ is an open source application.
Diffing both applications showed that the malicious actor indeed copied the benign code, but added their own obfuscation on top of it.
Both applications have the same entry point, which is the MainActivity. By comparing the onCreate method of the malicious application against the official open source repository of the legitimate app, the modifications become clear.

Example 1: On the left, is the malicious onCreate method, on the right is the official apk.

Legitimate Application:

Malicious Application:

The threat actor retained the legitimate application source code to ensure the app functions normally, avoiding immediate user suspicion. However, they injected wrapper functions to hijack the execution flow and initialize the malicious payload in the background.

Obfuscation Mechanisms

The malware employs a combination of java reflection, wrapper functions, and a custom string encryption routine to hinder static analysis. For example, reflection is heavily used to invoke methods dynamically at runtime, preventing static analysis tools from easily mapping the call graph.

Example 2: Reflection of ‘Hegumens’ method

String Deobfuscation

Analysis of the smali/Java code revealed a uniform string decryption algorithm used throughout the application.

Example 3: String obfuscation using base64 + XOR

The algorithm logic is as follows:

1. Accepts a Base64 encoded string.
2. Decodes the Base64 string into a byte array.
3. Iterates through the array, performing a bitwise XOR operation against a hardcoded 32-character key using a modulo operator (i % 32).

To accelerate analysis, the following Python script can be used to emulate the malware’s decryption routine and extract the plaintext strings:

Malicious Payload: androidx.activity.yuma

By cross referencing the deobfuscated strings and the modified onCreate execution flow, the core malicious class was identified as androidx.activity.yuma.

Based on the MainActivity analysis It was discovered that the initial method executed within this class is called Encinas.

Example 4: Malicious payload entry point

Dynamic Permission Harvesting

The malware uses a function (Mobilia) to aggressively request permissions at runtime.
It iterates through an array of required permissions using ContextCompat.checkSelfPermission.

If the user denies a permission, the malware loops and continuously prompts the user until the permission is granted, a common tactic in mobile malware to force the user into accepting.

Example 5: App permission tracker

Data Collection Listeners

Once permissions are secured, the malware instantiates an object (myopes) that implements several background listeners designed to harvest specific user data.

User Information Exfiltration

The data exfiltration phase is handled by multiple dedicated Runnables that trigger external server callbacks with a 500 millisecond delay.

Each listener triggers a Cascrome method, as seen in the instance below:

Example 6: Data exfiltration Runnable

It was also found that the malware utilizes an obfuscated Enum class (crisped) for HTTP request methods. Deobfuscation of the Enum class, reveals HTTP methods:

File Upload Mechanism

The final network execution calls a heavily obfuscated method (Threaten). Reverting to smali analysis was required as JADX-GUI failed to decompile it.

The Threaten method logic executes the following:

1. Initiates an HTTP POST request using multipart/form-data to a the server hxxps://api[.]ra-backup[.]com/analytics/submit.php
2. Uploads the generated JSON/database files containing the harvested user data.
3. Parses the local file name, splitting it by the _ character to extract tracking IDs: cid (part[0]) and tid (part[1]).
4. If the malicious actor server responds with an HTTP 404 status code, the malware deletes the local file copy to clean up its tracks.

Example 7: Data exfiltration flowchart

IOC’s

Special thanks:
Huge thanks to Erez Dasa for sharing the sample used in this write-up and to Lior Dahan for his moral support.