LSPosed Module Fakes SIM-Binding Checks to Enable Mobile Payment Fraud
Summary
CloudSek describes an Android threat that uses LSPosed to spoof phone identity, intercept registration SMS and inject fake sent-message records, enabling attackers to bypass SIM-binding checks in Indian mobile payment apps.
Key points
- The report describes a shift from repackaged payment apps to LSPosed runtime hooks that leave the legitimate app binary and signature unchanged.
- The malicious module hooks Android SMS and telephony APIs to intercept registration tokens and return a spoofed phone number.
- Socket.IO commands can trigger fabricated SMS records in the device’s sent-message database, while stolen tokens and SMS data are forwarded to Telegram.
- The attack requires a rooted attacker-controlled device with LSPosed, as well as a victim device compromised to read, send or forward SMS messages.
- CloudSek links the module, called Digital Lutera, to a Telegram actor using the aliases Berlin and @Syntext_Erorr; it reports more than 500 login messages in one group.
- The described fraud can enable account binding and PIN resets on an attacker’s device, followed by unauthorized transfers.
- Recommended defenses include strong device-integrity checks, runtime hook detection and carrier-side verification that registration SMS messages traversed the cellular network.
Article Details
- Attack Vectors
- A malicious LSPosed module hooks Android system APIs and the payment app at runtime, leaving the app APK unmodified.
- Hooks to SmsManager.sendTextMessage intercept and block registration SMS messages, then forward their contents to Telegram.
- Hooks to getLine1Number and SubscriptionInfo.getNumber return a configured, spoofed phone number.
- The module receives Socket.IO commands from its C2 server and inserts fabricated sent-SMS records into the Android SMS database.
- A compromised victim device with SMS read/write capabilities is used as a remote SMS gateway to send registration messages from the victim's SIM.
- Trojanized APKs can intercept login and PIN-reset OTPs and forward them to the attacker.
- Defensive Notes
- Use Google Play Integrity API and require the MEETS_STRONG_INTEGRITY verdict.
- Implement runtime hook detection, including checks for known hooking-framework files and unexpected method stack traces.
- Move sensitive identity verification, SIM checks, and SMS dispatch logic into native code where practical.
- Validate registration SMS delivery with carrier-side metadata rather than trusting the device's local success callback.
- Consider push-pull verification over a secure data channel for sensitive steps.
- Scan for the reported configuration file and LSPosed module package name, and monitor unusual socket connections from system-level processes.
- Use strict SSL certificate pinning to reduce network-level man-in-the-middle risk.
Indicators of compromise
| Type | Indicator | Context |
|---|---|---|
| URL | hxxps[:]//noob-production[.]up[.]railway[.]app | C2 server to which the module connects for remote commands. |
MITRE ATT&CK
T1055 · Process InjectionThe LSPosed module injects malicious code into the system_server process and the target payment app process.T1565.001 · Stored Data ManipulationThe module inserts fabricated sent-SMS records into the Android SMS database to make blocked registration messages appear to have been sent.T1636.004The module intercepts SMS activity, including registration messages and OTPs, and forwards message contents to the attacker.
Threat Actors
@Berlin_MarketIdentified alongside @Syntext_Erorr as the target actor; the article also identifies Berlin as the actor's primary alias.@Syntext_ErorrTelegram identifier attributed by the article to the actor associated with the Digital Lutera module; the article also identifies Berlin and @Berlin_Market as names or aliases for this actor.BerlinReported primary alias of the actor identified as @Syntext_Erorr and @Berlin_Market; associated with Digital Lutera and mobile-payment fraud.
Malware
Vendors
Products
Androidthreat actors to hijack legitimate, unmodified payment applications by "gaslighting" the underlying Android operating system. Because the malicious module ( at the time of writing this blog was called ‘DigitalAxis MobileTarget App: Axis Mobile (com.axis.mobile).Google Play Protectthan the app itself, the payment app’s digital signature remains valid, effectively bypassing Google Play Protect and traditional integrity checks that previously flagged modified binaries. Play Integrity APIthis risk, financial institutions must move beyond basic root detection and implement Google’s Play Integrity API with a strict MEETS_STRONG_INTEGRITY requirement to ensure the bootloader is locked and the OS isProtectt.aiB. Target: Axis Bank & Protectt.ai Anti-Fraud SDK