Gigabud Banking Trojan Uses Android Work Profiles to Clone Bank Apps in Indonesia

Confirmed campaign hits Indonesian banking customers

Security firm Group-IB has documented an Android malware campaign in Indonesia that has produced confirmed account takeovers and real financial losses, according to reporting by Dark Reading summarized on dev.to. The operation combines the Gigabud banking trojan, which is associated with the GoldFactory threat group, with a cloning tool named Vwork. Its distinguishing trick is the abuse of Android's Work Profile feature — a container intended to keep corporate apps separate on a single handset — to hide duplicate banking apps from the victim and from casual inspection.

How the attack unfolds

The infection begins when a victim installs an app package from outside the official store. Group-IB reports that distribution relies on social engineering, including SMS messages, with the malware dressed up as an airline, tax, or government service application.

After installation, Gigabud requests a potent set of permissions: accessibility services, the ability to draw over other apps, and exemption from battery optimization. Once granted, it presents counterfeit banking login screens to harvest credentials, and it separately obtains the victim's screen lock code through another mechanism.

From there, the attackers' command-and-control infrastructure pushes Vwork onto the device and directs it to create a Work Profile. Vwork duplicates the victim's banking application into that profile while Gigabud relays operational commands to the clone. Group-IB also recorded cases involving modified applications impersonating legitimate banking apps.

The final stage is an account takeover hidden in plain sight. Behind a black screen overlay that blanks the display, the operator registers the cloned app with the bank as a brand-new device and then initiates transfers the user never sees or approves.

Why the Work Profile matters

Android's Work Profile is designed to isolate a corporate persona from the personal one, and that separation is exactly what the attackers exploit. The cloned banking app runs in its own container, and from the bank's perspective the enrollment looks like an ordinary new-device registration. The dev.to analysis notes that the technique succeeds where the bank does not connect the risk signals of the personal profile to the authentication of the new one — effectively turning an already-compromised phone into what the bank treats as a clean, trusted device.

Warning signs

For victims, the observable signals include permission prompts from an unfamiliar sideloaded app, an unexpected briefcase badge indicating a Work Profile, duplicated banking apps, and the screen going black while the device is in use.

For administrators, the indicators include the presence of the net.yy.vwork package, APKs from unofficial sources, rapid creation of a Work Profile, and a banking app appearing inside it. The analysis also flags new profiles and new device registrations originating from the same physical handset, alongside transfers inconsistent with the user's normal behavior.

Scope of the damage

Group-IB has confirmed banking operations on compromised devices and estimated the resulting losses. The dev.to summary is careful about precision: the 1,281 cases cited represent potentially compromised logins rather than verified unauthorized transfers, and the presence of the malware or a cloned profile alone does not prove that money moved. Severity is nonetheless rated high, because financial losses and numerous compromised devices have both been confirmed.

Why it matters

The campaign demonstrates that an enterprise mobility feature can be weaponized for consumer banking fraud. Defenders can no longer treat Work Profile creation as inherently benign administrative activity — on unmanaged personal devices it is a red flag outright. For banks, the lesson is that new-device registration is a fraud surface: enrolling a cloned app on an already-infected phone warrants additional scrutiny rather than a clean slate. The technique is also unlikely to stay narrow; the analysis suggests the same cloning approach could be repurposed against other banking and payment apps, depending on the controls each institution applies. Suggested mitigations include blocking sideloaded APKs and unauthorized accessibility services through device policy, and correlating new device registrations with transfer risk assessment on the bank side.