Executive Summary

The RedAlert mobile espionage campaign represents a critical threat vector directly exploiting the heightened civilian panic surrounding the current Israel-Iran kinetic conflict. Threat actors are capitalizing on the desperate need for real-time rocket alerts by distributing a trojanized version of the official Home Front Command application through targeted SMS phishing (smishing). This delivery mechanism deliberately bypasses the Google Play Store—the sole legitimate repository for the authentic "Red Alert" app, which operates cleanly with only basic notification access. By manipulating victims into sideloading this malicious APK under the guise of an urgent wartime update, the adversaries successfully deploy a fully functional alert interface that masks an invasive surveillance engine designed to prey on a hyper-vigilant population.

Beneath the legitimate-looking exterior, the malware executes a sophisticated multi-stage infection, utilizing dynamic proxy hooks to spoof the original application's 2014 signing certificate and evade Android's system integrity checks. The core payload, heavily obfuscated within the class, aggressively polls for high-risk system permissions to intercept complete SMS inboxes, harvest contact books, and continuously track exact GPS coordinates. This gathered intelligence is systematically staged and exfiltrated to attacker-controlled infrastructure via a rapid upload loop. The combination of real-time civilian location tracking during active air raids and the ability to bypass 2FA through SMS interception transforms this campaign into a severe strategic and physical security risk, demanding immediate quarantine protocols and network-level blocking.

‍

‍

Static Analysis : Reverse Engineering

1. Package Manager Hooking (Anti-Tamper & Cloaking)

The code uses reflection to hook the IPackageManager (specifically through sPackageManager in ActivityThread).

• Signature Spoofing: It intercepts calls to getPackageInfo. If a system or security tool asks for the app's signing certificates, the code returns a hardcoded signature (decoded from the Base64 string in attachBaseContext) instead of the real one. This is used to bypass signature verification checks that might detect if the APK has been modified or tampered with.
  
  
• Installer Spoofing: In the invoke method, it intercepts getInstallerPackageName and forces it to return "com.android.vending" (the Google Play Store). This makes the app appear as if it were officially installed from the Play Store, even if it was sideloaded.

‍

SIGNATURE: Decoding Breakdown

1. The Header bytes (AQAAAr8) The first few bytes of the decoded string are instructions for the malware's DataInputStream on how to read the payload:

• 01: Indicates there is exactly 1 signature to read.
• 00 00 02 BF: This is a 4-byte integer representing the length of the certificate data (703 bytes).

2. The X.509 Certificate (wggK7MIIBo6AD...) The remaining 703 bytes constitute the actual certificate. Parsing this ASN.1/DER structure reveals the following cryptographic details:

• Subject: C=IL (Country: Israel)
• Issuer: C=IL (Country: Israel)
• Valid From: July 12, 2014 (14:50:54 GMT)
• Valid To: June 18, 2114 (14:50:54 GMT)
• Algorithm: SHA256withRSA
• Public Key: RSA 2048-bit

2. Dynamic Payload Loading (The "umgdn" Asset)

The attachBaseContext method contains a routine to extract a hidden file:

• It looks for an asset named umgdn.
• It copies this asset into the app's internal file directory (getFileStreamPath).
• It then manually updates the ApplicationInfo (specifically sourceDir and publicSourceDir) to point to this new file.

Why this is malicious: This is a technique used to load a secondary "dropped" payload (like a .dex or .so file) while making the system believe it is interacting with the original APK. By updating mAppDir and mApplicationInfo via reflection, the malware can execute code from the umgdn file while hiding it from standard inspection.

3. Heavy Use of Reflection and Proxying

The code avoids using standard Android APIs directly, opting instead for:

• Class.forName("android.app.ActivityThread")
• Proxy.newProxyInstance
• Direct manipulation of internal fields like mPM, mPackages, and sPackageManager. 

Execution Flow 

The malware's infection chain is split into three distinct stages:

• Stage 1: The Initial Loader (Main APK) The outer shell of the APK acts primarily as a cloaking device. It utilizes reflection and hooks into the Android Package Manager (e.g., via the PmsDexHookApplication class) to spoof its signature and bypass initial tampering checks. Its primary function is to extract and execute the hidden Stage 2 asset.
  
  
• Stage 2: The Intermediate Payload (umgdn) Stored within the assets/ directory as a file named umgdn (without a file extension), this component is dynamically loaded into memory by Stage 1. By treating this raw asset as a Dalvik Executable (DEX), the malware shifts the execution path away from the statically scannable components of the initial APK.
  
  
• Stage 3: The Core Payload (DebugProbesKt.dex) Embedded within or extracted by the Stage 2 payload is the final malicious executable. Once loaded as a DEX file, this stage deploys the primary spyware/banking trojan capabilities, including establishing communication with the Command and Control (C2) infrastructure.

‍

Dynamic Analysis: Execution and Runtime Behaviour

1. Execution and User Interface (UI) Cloaking: 

During dynamic execution, the trojanized package (com.red.alertx) successfully launches and perfectly mirrors the graphical user interface (GUI) of the official Israeli Home Front Command Red Alert application. To the end user, there is absolutely no visual discrepancy in the core functionality, as the malicious app actively delivers real rocket attack alerts to maintain its disguise.

The critical behavioral divergence occurs exclusively during the initial application launch and onboarding phase. While the legitimate application restricts its prompt strictly to standard Notification access to push alerts, the malicious payload aggressively prompts the victim for high-risk system permissions (such as Contacts, SMS, and Location), masking them as necessary requirements for the app's core operations.

2. Runtime Behavior and Exfiltration Triggers:

Once executed, the malware initiates a silent background thread that continuously polls the Android OS for permission state changes. It does not wait for a complete set of permissions to be granted; the moment the user approves a single requested permission, the associated data harvesting module is dynamically triggered.

The malware was observed staging the collected intelligence (including the SMS inbox, complete contact lists, and real-time GPS coordinates) into categorized local files before initiating its exfiltration loop.

3. Network Communications and Infrastructure: 

Network traffic analysis confirms that the malware maintains aggressive, persistent communication with its Command and Control (C2) infrastructure. Once data is staged locally, a dedicated uploader thread loops, establishing rapid outbound connections to transmit the payload via HTTP POST requests to https://api[.]ra-backup[.]com/analytics/submit.php.

The following IP addresses were captured during the dynamic execution phase, representing the infrastructure facilitating the exfiltration and C2 communications:

• 44.208.242.141
• 104.21.64.137
• 172.67.137.156
• 44.200.176.254
• 216.45.58.148

Note: The presence of the 104.21.x.x and 172.67.x.x addresses indicates the threat actors are leveraging Cloudflare to proxy and shield their true backend infrastructure, while the 44.x.x.x addresses point to AWS hosting environments.

Indicator Of Compromise:

App Name: RedAlert.apk

URLs:

• https[:]//www[.]shirideitch[.]com/wp-content/uploads/2022/06/RedAlert[.]apk
• http[:]//bit[.]ly/3Ozydsn
• https[:]//bit[.]ly/2O3fHEX
• https[:]//bit[.]ly/3GfZoys
• https[:]//api[.]ra-backup[.]com/analytics/submit[.]php

Impact Assessment: Strategic & Geopolitical Context

1. Weaponization of Active Wartime Panic (The Lure):

With Iranian retaliatory ballistic missile and drone strikes actively targeting Israeli territory and US bases across the Gulf, citizens are desperate for real-time early warning systems. Masquerading as the official Israeli Home Front Command's "Red Alert" application directly exploits this life-or-death urgency, virtually guaranteeing an exceptionally high infection rate as victims bypass standard security hygiene in search of safety.

2. Kinetic Targeting and Physical Security Risks (Location Tracking):

In the context of an active, multi-front war, the malware’s continuous GPS tracking functionality transcends standard digital surveillance. The real-time geolocation of thousands of infected devices provides adversaries—with crowdsourced, actionable intelligence. This data can be weaponized to map civilian shelter locations, track the mass movement of displaced populations, or identify the concentration and deployment of IDF reservists, potentially optimizing the targeting of incoming missile barrages.

3. Strategic Intelligence Gathering (Data Exfiltration):

The aggressive exfiltration of the device’s AccountManager, complete contact lists, and SMS inbox allows state-sponsored threat actors to rapidly map the social graphs of the infected population. This mass data harvesting enables the identification of high-value targets (HVTs)—such as military personnel, government officials, or defense contractors—for secondary exploitation. Furthermore, intercepting SMS communications in real-time allows adversaries to bypass 2FA on critical infrastructure networks or conduct highly targeted psychological warfare (e.g., sending demoralizing or deceptive SMS messages during infrastructure blackouts).

4. Erosion of Emergency Response Integrity:

By successfully hijacking the branding and functionality of a critical life-saving application, this campaign executes a devastating form of information warfare. If the civilian population learns that emergency alert applications are heavily trojanized, public trust in official government broadcast channels will collapse. Citizens may hesitate to install legitimate Home Front Command updates or begin ignoring authentic sirens, directly increasing the risk of civilian casualties during ongoing air raids.

Remediation and Mitigation Strategies

To contain the threat posed by the com.red.alertx spyware campaign and prevent further data exfiltration, organizations and affected individuals must implement immediate tactical remediation and long-term strategic defenses.

1. Immediate Device-Level Remediation

Given the malware’s comprehensive data-harvesting capabilities, relying solely on standard application uninstallation is insufficient.

• Device Quarantine & Disconnection: Immediately isolate suspected compromised devices from all corporate networks, Wi-Fi, and cellular data to sever exfiltration loop to the C2 servers.
• Revocation of Administrator Rights: Navigate to Settings > Security > Device Administrators and revoke any administrative privileges granted to the trojanized "RedAlert" application.
• Factory Reset (Recommended): Due to the malware's ability to extract deep system data and potentially drop secondary payloads, a complete factory reset of the infected device is the only guaranteed method to eradicate the threat. Devices should not be restored from a backup created after the initial infection date.

2. Network & Infrastructure Defenses

Network administrators must immediately block all communication attempts to the threat actor's infrastructure.

• DNS and URL Blocking: Sinkhole or block all outbound DNS requests and HTTP/HTTPS traffic to the primary C2 domain:
  
  • api.ra-backup[.]com
• IP Blocklisting: Implement strict egress filtering at the perimeter firewall and Secure Web Gateway (SWG) for the following identified C2 IP addresses. Note that several of these utilize Cloudflare and AWS routing to mask the true backend infrastructure:
  
  • 216.45.58[.]148
• Traffic Analysis: Hunt for anomalous HTTP POST traffic occurring at rigid intervals, which is highly indicative of the payload's automated staging and upload loop.

3. Proactive Security Posture & Policy Enforcement

To prevent future infections stemming from wartime social engineering and smishing lures:

• Mobile Device Management (MDM) Enforcement: Configure MDM policies to strictly prohibit the installation of applications from "Unknown Sources" (sideloading). Restrict application downloads exclusively to the managed Google Play Store.
• App Permission Auditing: Utilize MDM solutions to actively audit and flag devices running applications with high-risk permission combinations—specifically the simultaneous requesting of READ_SMS, READ_CONTACTS, ACCESS_FINE_LOCATION, and SYSTEM_ALERT_WINDOW.
• Security Awareness Training: Rapidly deploy internal communications warning personnel about the specific threat of threat actors weaponizing the Israel-Iran conflict via SMS phishing. Emphasize that official government emergency applications will never request access to SMS inboxes or full contact lists.

References

• *Intelligence source and information reliability - Wikipedia
• ^#Traffic Light Protocol - Wikipedia