Gigabud and the cloned banking app: what a new Android campaign in Indonesia means for banks

On 9 September 2026, Group-IB published research on Vwork, a companion tool installed after the Gigabud Android banking trojan to clone banking apps. Group-IB attributes the campaign to the GoldFactory group.¹ Indonesia is among the targeted markets, and the one with detailed figures in the report. Between February and July 2026, the researchers observed about 1,469 compromised devices and 1,281 potentially compromised logins in Indonesia, with estimated losses of roughly USD 960,000. Around a dozen Indonesian banks, state-owned and private, were targeted.¹²

Measured against Indonesia's overall scam losses, the amount is small. The technique is what matters.

How the attack works

1. The lure. Victims are pushed, through phishing sites, messaging apps and social media, to install a fake app posing as a government service, the tax authority or an airline, from outside the Play Store.
2. The permissions. Gigabud asks for Accessibility access, the ability to draw over other apps, and an exemption from battery optimisation. It then sends the list of installed apps to its operators.
3. The credentials. Fake login screens capture banking credentials. Invisible overlays capture the phone's lock-screen code.
4. The clone. Gigabud installs Vwork, a modified version of an open-source tool, which creates an Android work profile and clones the victim's banking app into it.
5. The theft. Operators control the phone live through Accessibility and make transfers from the cloned app, while a black screen hides what is happening from the victim.¹²

Why the work profile matters

Android keeps apps in a work profile separate from the personal profile. Group-IB's point is that attackers use this to split the evidence from the crime: malware checks run where the malware is, while the fraudulent transactions happen in a profile that looks clean. This breaks the link between malware alerts and fraud. In Group-IB's words, fraudulent transactions "may bypass monitoring and result in unauthorized cash-out."¹

For a bank, the uncomfortable implication is that "we scan for malicious apps inside our app" is not the same as "we know the session is safe." A control can be working exactly as designed and still miss the fraud.

Questions worth asking of your current controls

• Does a cloned install look like a new device to you? If the cloned app registers as a fresh installation, device binding and first-seen checks are some of the most useful signals you have. If binding silently carries over, that signal is gone.
• Do you see Accessibility and overlay abuse at the moment of a transfer? Group-IB recommends blocking transactions from devices where an unrecognised app holds active Accessibility access.¹ That only works if the signal reaches the decision in time.
• Do you look at the shape of the session? Live remote operation leaves traces in timing and in the order of actions. Group-IB also recommends monitoring for unusual timing and action sequences, alongside signature-based detection.¹
• Is the login tied to a trusted device? Credentials captured by an overlay are only half the attack if they can't be used from an unfamiliar installation without stepping up.