Fake Banking Rewards, Telegram Delivery and Albiriox: Anatomy of an Android Malware Campaign
During routine monitoring performed through D3Lab’s Brand Monitor service, our team detected a newly registered domain impersonating a well-known Italian banking brand. The domain was designed to look like a promotional landing page and promised users a financial reward for downloading a mobile application. At first glance, this looked like a classic brand abuse case. A closer analysis revealed something more serious: the landing page was part of a malware delivery chain distributing a malicious Android APK.
The affected brand, as well as its customers, should be considered victims of this campaign. The fraudulent infrastructure abuses the bank’s identity to gain trust, while the malicious application targets users who are convinced to install software outside official app stores. This is not a legitimate promotion, not a banking initiative, and not an official application distribution channel.
The domain observed by D3Lab was unicredit-tme[.]shop, registered on July 8, 2026. The page advertised a fake reward and invited users to download an app. Instead of redirecting to an official app store, the call-to-action led to a Telegram bot, https://t[.]me/UniCreditit_bot, where the victim was guided through the next stage of the fraud. The bot promised a reward of 100 USD for installing the application and an additional 50 USD for inviting a friend, turning the fraud into a referral-driven malware distribution mechanism.
This delivery model is effective because it combines three elements that frequently increase victim conversion: brand impersonation, a direct financial incentive, and a conversational flow through Telegram. The web page provides initial credibility, while the bot gives the attacker an interactive channel to instruct the victim, handle doubts, and push the APK installation outside the controls of official marketplaces.
Executive Summary
The campaign analyzed by D3Lab abuses a banking brand to distribute a malicious Android application. Static and dynamic analysis show that the APK is not a legitimate banking app but a dropper containing an embedded second-stage payload. The second stage is an Android banking RAT with Accessibility abuse, overlay capability, SMS interception, remote control features, and a custom TCP-based command-and-control protocol.
The second-stage payload was identified as Albiriox. This attribution is further supported by a manual comparison with a known Albiriox sample, by protocol-level similarities, and by public Telegram material associated with the Albiriox project. The sample analyzed in this campaign appears to be a customized and obfuscated build configured for an Italian-themed operation.
The main command-and-control endpoint extracted from the second stage is 179[.]43, with an auxiliary TCP channel on [.]159[.]210:5555179. The use of port [.]43[.]159[.]210:55525555 is consistent with public screenshots of the Albiriox panel, where the server is shown listening on the same port.
Delivery Chain
The infection chain starts from a newly registered domain that impersonates the banking brand and advertises a fake reward. The page contains simple promotional text and a button labelled as an app download. The user is then moved to Telegram, where the bot continues the social engineering flow and introduces the incentive scheme.
The campaign does not appear to rely on Google Play or other official stores. This is important from a defensive perspective: the user is being convinced to install an APK manually, likely after enabling installation from unknown sources. In this model, the attacker does not need to compromise the official app ecosystem. Instead, they exploit trust in the brand and the promise of money.
From a CTI perspective, the delivery infrastructure and the payload behavior should be treated as two connected layers. The domain and Telegram bot are used for acquisition and conversion. The APK then executes the malware chain locally and contacts the Albiriox command-and-control infrastructure.
APK Overview
The initial APK analyzed by D3Lab is a malicious dropper. Its visible purpose is to impersonate the banking brand, but its real function is to unpack and install a second-stage payload. The original sample has the following hash:
206fdbe992b44ebd6720c49c79a5da3bdcb48d0d799a0ff3458323caac3cc490
The embedded second stage extracted from the dropper is:
Filename: payload_stage2.apk
SHA256: 1e99972b1d84b131eb55a6b49f64871c5c0c6a1bb2a099a84313001b69dc53e8
MD5: 6aa665d2f33f03a549c14edec772cf2c
Package: io.qzwvyj.ywltn
App label: UniCredit
The second stage requests a broad set of permissions consistent with an Android banking RAT. Among the most relevant are Accessibility service binding, overlay capability, notification access, foreground services, boot persistence, battery optimization bypass, SMS reception, package querying, and media projection-related foreground service declarations.
A Self-Contained Dropper
One of the most relevant technical findings is that the second stage is not downloaded from the Internet at runtime. It is already embedded inside the original APK. The dropper stores the payload across multiple assets with misleading extensions, then reconstructs it locally.
The assets involved in the reconstruction are:
assets/6mt6g1xz/8b7l8xt.jpg
assets/6mt6g1xz/9nrxawg.enc
assets/6mt6g1xz/x97pnr.jpg
These files are concatenated, decrypted with AES-CBC, and decompressed with GZIP to obtain a valid APK. A PKCS12 keystore is also embedded and encrypted inside the original application.
This design has operational value for the attacker. The delivery infrastructure only needs to convince the victim to install the first APK. The second stage is already present, so the malware does not depend on a second external download that could fail, be blocked, or be observed by network controls.
The decryption logic is based on hardcoded material reconstructed at runtime. The dropper uses AES/CBC/PKCS5Padding and GZIP after joining the embedded blobs. The following values were recovered during analysis:
AES mode: AES/CBC/PKCS5Padding
Compression: GZIP
Embedded keystore: PKCS12
Keystore password/alias: android
Stage 2: Android Banking RAT Capabilities
The second-stage payload is the operational malware component. It registers an Accessibility service, uses overlays, communicates with the command-and-control server, and includes multiple modules for remote interaction and data collection.
The manifest exposes a suspicious combination of capabilities. The Accessibility service is exported and protected by android.permission.BIND_ACCESSIBILITY_SERVICE. The sample also includes receivers for boot persistence and SMS handling. Dynamic sandbox reports confirmed behavior consistent with foreground persistence, overlay usage, installed application discovery, WakeLock usage, and anti-uninstall behavior.
The following components are particularly relevant:
Package: io.qzwvyj.ywltn
Main activity: io.qzwvyj.ywltn.IIM0UnA3JlJ
Accessibility service: io.qzwvyj.ywltn.IpkQ4XIWSdvBG
SMS receiver: io.qzwvyj.ywltn.sms.R64CfKPrgLC4H
The malware implements live UI capture and remote control through Accessibility. It builds JSON objects from Accessibility events and UI nodes, then sends them to the C2. The same service includes methods for app launching, blank screen handling, screenshot keyword configuration, credential exfiltration, SMS analysis, and device handshake.
The credential overlay logic supports multiple types of capture flows:
switch (lowerCase) {
case "phone_pass":
case "pattern":
case "pin_4":
case "pin_6":
case "user_pass":
case "email_pass":
// configure and display the corresponding overlay flow
}
This is consistent with a banking malware designed for on-device fraud. Rather than only stealing static credentials, the malware gives the operator remote visibility and interaction with the victim’s device, allowing abuse of banking sessions, OTP interception, and manipulation of target applications.
Command and Control
The second-stage payload contains a hardcoded C2 configuration:
Main C2: 179[.]43[.]159[.]210:5555
Auxiliary TCP channel: 179[.]43[.]159[.]210:5552
Target/country marker: Италия
The communication protocol is not HTTP-based. The malware opens raw TCP sockets and exchanges JSON messages framed with a four-byte big-endian length prefix. This was confirmed both statically and dynamically. Any.run flagged the network activity as a TCP binary protocol with a 32-bit big-endian data-length prefix on a non-standard port, matching the implementation seen in the decompiled code.
The framing logic is straightforward:
ByteBuffer byteBuffer = ByteBuffer.allocate(4);
byteBuffer.order(ByteOrder.BIG_ENDIAN);
byteBuffer.putInt(payload.length);
byte[] frame = new byte[payload.length + 4];
System.arraycopy(byteBuffer.array(), 0, frame, 0, 4);
System.arraycopy(payload, 0, frame, 4, payload.length);
The same framing pattern appears in the known Albiriox sample used for comparison. In that sample, the heartbeat logic sends JSON messages such as ping and pong, also wrapped with a four-byte big-endian length prefix.
Why We Attribute This Payload to Albiriox
The initial assessment classified the payload as an Android banking RAT with strong Albiriox-like characteristics. After comparing it with a known Albiriox sample the attribution became stronger.
Manual comparison with a known Albiriox payload shows significant overlap in architecture and behavior. Both use a raw TCP JSON protocol with a 32-bit big-endian length prefix, both rely on Accessibility-based remote control, both implement VNC-like UI streaming, overlays, blank screen functionality, target app detection, and remote device controls such as Back, Home, Recent, Power and volume actions.
The known Albiriox sample contains a clear configuration class:
public class Client_Configuration {
public static final long FRAME_INTERVAL_MS = 40;
public static final int MAX_MISSED_PONGS = 7;
public static final long PING_INTERVAL_MS = 15000;
public static final String SERVER_IP = "194[.]32[.]79[.]94";
public static final int SERVER_PORT = 5555;
}
The sample used in this campaign is more heavily obfuscated, but it preserves several comparable values and concepts:
server = "179[.]43[.]159[.]210";
mainPort = 5555;
auxPort = 5552;
country = "Италия";
pingInterval = 15000L;
frameInterval = 40L;
smsLimit = 210;
Public Telegram material associated with Albiriox also supports this assessment. The Albiriox panel is shown listening on port 5555, and the interface exposes VNC controls, update screen, black screen mode, SMS status, connected clients, and remote device actions. These are the same operational primitives observed in the analyzed payload.
The malware developer’s Telegram channel also shows the evolution of Albiriox over time. In December 2025, the project was advertised as an Android remote interaction tool with VNC, AcVNC, Accessibility-based keylogging, target detection, banking and crypto overlays, blank screen mode, domain support, and an overlay constructor. In January 2026, Albiriox 1.5 introduced SMS interception, OTP analysis, configurable SMS limits, autostart request, reconnect timeout, and missed-pong settings. These features align closely with what is present in the analyzed second stage.
For this reason, D3Lab assesses the payload as a likely customized and obfuscated Albiriox build used in an Italian banking-themed campaign.
Impact on Users
For end users, this campaign should be understood as a fraud designed to obtain control over the victim’s Android device. The promise of a reward is the lure. The APK is the malware. Once installed and granted permissions, the application can abuse Accessibility services to observe and interact with the device, display overlays, capture credentials, intercept SMS messages, and support remote operator-driven activity.
Users should never install banking applications from links received through Telegram, messaging apps, SMS, social networks, or unofficial websites. Official banking applications should only be installed from trusted app stores and verified publisher accounts. Any promotion promising money in exchange for installing an APK should be treated as suspicious, especially when it requires enabling installation from unknown sources.
This campaign also highlights that brand owners are victims of these operations. Their identity is abused to make the fraud credible, while their customers are targeted through social engineering and malware.
Indicators of Compromise
The following indicators were observed during the investigation.
Domains and URLs
unicredit-tme[.]shop/
t[.]me/UniCreditit_bot
Telegram
@UniCreditit_bot
Original APK
SHA256: 206fdbe992b44ebd6720c49c79a5da3bdcb48d0d799a0ff3458323caac3cc490
Stage 2 APK
SHA256: 1e99972b1d84b131eb55a6b49f64871c5c0c6a1bb2a099a84313001b69dc53e8
MD5: 6aa665d2f33f03a549c14edec772cf2c
Package: io.qzwvyj.ywltn
Command and Control
179[.]43[.]159[.]210
Embedded assets
assets/6mt6g1xz/8b7l8xt.jpg
assets/6mt6g1xz/9nrxawg.enc
assets/6mt6g1xz/x97pnr.jpg
assets/6mt6g1xz/mgqtx38qns.png
Embedded stage-related hashes
fb43c4191c40f159167a98a4ac20bf23ae66a8ec27a919f703e953933e22a266
efc81267da3ad48cc779e9aed8f9232504ed7c85abf3958a87ba2ae68056ae23
e0fc365c042e708c8d04b5431238958586194cc4a8cbe069411a26dcfcc4e9b6
146c62f408b6d7db4c832a6b5f7bdacb1cff2c69121b9b2f7e80646c37910abd
Embedded keystore
SHA256: 4b9a95ebf5e471d11443fa2f19b75595fc1fcf6be234024cc1d4a2255068c19b
Defensive Recommendations
Organizations should monitor newly registered domains that include or resemble their brands, especially when they combine banking terminology, rewards, downloads, or mobile app language. Brand monitoring should be connected with malware analysis workflows because phishing and brand abuse frequently serve as the first stage of a broader malware campaign.
Mobile users should be warned that legitimate banks do not distribute Android APKs through Telegram bots or unofficial landing pages. Security teams should monitor for traffic to known C2 endpoints, block malicious domains and Telegram delivery links where appropriate, and investigate devices that have installed suspicious APKs with Accessibility permissions enabled.
For financial institutions and SOC teams, the key behavioral detections include Android applications requesting Accessibility services under misleading branding, unknown-source APK installation, overlay permission abuse, suspicious foreground services, SMS receiver registration, and outbound raw TCP connections to non-standard ports such as 5555.
Conclusion
This case shows how a brand abuse signal can lead to the discovery of a full Android malware campaign. A newly registered domain impersonating a banking brand was not only a phishing page, but the entry point for a Telegram-driven APK distribution flow. The APK contained a self-contained dropper and an embedded second-stage Android banking RAT identified as Albiriox.
The campaign demonstrates the convergence of social engineering, brand impersonation, Malware-as-a-Service tooling, and mobile on-device fraud. The abused banking brand and its customers are both victims: the brand is exploited to build trust, while users are targeted with a fake reward and pushed into installing malware.
D3Lab will continue monitoring the infrastructure and related indicators through its Brand Monitor and threat intelligence capabilities.
