Keypoints
- Android/Xamalicious is implemented with Xamarin (.NET/C#) and hides malicious assemblies in the APK (often in /assemblies as core.dll and .dll), sometimes LZ4-compressed or embedded in BLOBs.
- Initial stage uses social engineering to request Accessibility services; once granted, the malware can observe and interact with UI to perform ad-fraud, app installs, and other actions.
- After permission is granted the app collects detailed device telemetry (DevInfo, GeoInfo, EmuInfo, RootInfo, installed packages, Accessibility status) and sends it to a C2 to determine whether to release the second-stage payload.
- All C2 communication is encrypted as JWE (RSA-OAEP + 128CBC-HS256) using RSA keys hardcoded in the DLL; the C2 responds with a JWE that can contain an AES-CBC encrypted DLL payload.
- The second-stage payload is AES-CBC encrypted with a 32-char key derived per device (deviceID + brand + model + padding), delivered inside a JWT, saved locally as “cache.bin”, and dynamically loaded via Assembly.Load to execute .NET code at runtime.
- Authors use obfuscation, custom encryption layers, and APK build techniques to evade detection and support self-updates; variants appeared on Google Play and are linked to the Cash Magnet ad-fraud family.
MITRE Techniques
- No MITRE ATT&CK techniques are explicitly referenced in the article.
Indicators of Compromise
- [Hash] sample APK hashes – 7149acb072fe3dcf4dcc6524be68bd76a9a2896e125ff2dddefb32a4357f47f6, a5de2dc4e6005e75450a0df0ea83816996092261f7dac30b5cf909bf6daaced0, and 20+ other hashes from the published table.
- [Package name] malicious app package names distributed on Google Play – com.regaliusgames.llinkgame (LetterLink), com.lakhinstudio.counteasycaloriecalculator, and multiple other package names listed in the report.
- [File name] embedded/loaded artifacts – core.dll, GoogleService.dll (assembly candidates), and cache.bin (downloaded second-stage DLL stored locally).
- [Domain/URL] network indicators and endpoints – api.myip.com (used for GeoInfo lookup), and the malware posts to “/Updater” on its C2 server (HTTP POST with JWE payloads).
Technical flow: the Xamarin APK presents a UI prompt that instructs users to enable Accessibility services; once enabled, the app collects extensive device telemetry (Android ID, model/brand, OS version, SIM/operator, ADB/Developer/Root status, list of installed packages, emulator/ADB fingerprints) and encodes this data into an encrypted JSON Web Encryption (JWE) token. The Send() routine builds the JWE using hardcoded RSA values in the decompiled DLL, posts it to the C2 “/Updater” endpoint over HTTPS, then passes the C2 response to a decrypt() function that uses the embedded RSA private key to unpack commands or payloads.
Payload delivery and unpacking: if the C2 deems the device suitable (not rooted, has SIM, not connected via ADB, matching carrier/language/location rules), it returns a JWE containing a base64-encoded URL parameter whose value is an AES-CBC encrypted DLL. The client derives a 32-character AES key unique to the device (deviceID + brand + model + padded “1”s), decrypts the URL blob to retrieve the DLL, writes it as “cache.bin”, and loads it with Assembly.Load. Some samples include assemblies directly in /assemblies (core.dll and .dll), sometimes LZ4-compressed or obfuscated; other samples require unpacking native ELF/DEX loaders to extract the .NET assemblies.
Execution and persistence: once the second-stage .NET assembly is loaded, it leverages granted Accessibility permissions to observe and interact with UI elements, enabling automated clicking, app installs, self-updates of the main APK, and arbitrary commands from C2. The multi-layer encryption (HTTPS + JWE with hardcoded RSA + per-device AES-CBC) and use of Xamarin for non‑Java assemblies complicate static detection and analysis, though the hardcoded RSA parameters permit decryption when the C2 data and keys are available during analysis.