Build1 publisher2 min readPublished
Gigabud clones a banking app into an Android work profile to register a new device
The malware asks for accessibility, then has a second component build a work profile and copy the bank app into it. Group-IB says the clone registers with the bank as a new device while a black screen hides the transfer.
The Engineer · Build desk
What happened
- Commands from the attacker's server then deploy a second component, Vwork, and create an Android work profile on the handset.
- Vwork clones the banking app into that profile, and the attacker registers the clone with the bank as a new device behind a black screen overlay before transferring funds.
- Group-IB, cited in the writeup, ties the campaign to the GoldFactory group and reports the APKs spreading through social engineering such as SMS. Those SMS lures may never touch corporate email logs.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- decision Banks have to decide whether a second profile on a handset they already know counts as a new device, and the writeup's suggested control is tying registration to transfer risk scoring with step-up authentication.
- exposure Both device-side fixes named need policy enforcement, one through device policies and one through MDM, so the phones being robbed are the ones with neither.
- constraint Reconstructing this from bank records depends on identifiers that tie a profile back to a physical device, and on the bank cooperating with whoever is asking.
- precedent The writeup expects the cloning technique to be reused against other banking and payment apps, with success set by each app's and each bank's controls.
A work profile exists to keep its apps and their data apart from the personal profile. Group-IB, as summarised in a dev.to writeup, says Gigabud uses that separation to register the device with the bank from inside the profile, then runs remote control and unauthorised transfers behind a black screen [1]. The writeup names the bank-side failure plainly: risk signals from the personal profile are not carried over to the authentication of the new profile [9]. The isolation behaved as documented, and the new-device check could not see into the profile it was isolated from.
The attacker works from inside that separation. Once accessibility and the other permissions are granted, according to the writeup, the attacker remotely controls the device screen and apps and operates the banking apps inside the work profile [19], with Gigabud relaying operation commands to the clone [5].
Four user actions collect every consent the attack needs: install the sideloaded APK dressed as an airline, tax or government app, then grant accessibility, display over other apps, and exemption from battery optimisation [2][3][21]. The work profile is created after that, by command from the attacker's server [4]. The artefacts a user could notice arrive later still, and the writeup lists three: an unexpected briefcase icon, a duplicated banking app, and a black screen during the operation [11]. A briefcase icon is a strong signal on a phone that has never had an employer, assuming anyone opens the app drawer to look.
The detection guidance mixes one brittle indicator with several durable ones. It covers APKs from unofficial sources, the package name net.yy.vwork, rapid work profile creation and banking app cloning, plus the linking of new profiles and new devices from the same physical device alongside unusual transfers [12]. A package name is one string in a manifest, and I would weight profile creation followed by the cloning of a banking app well above it, because the behaviour is what the attack needs and the string is not.
The record here is a secondary summary. The writeup credits Dark Reading and Group-IB, is dated 2026-09-11, and carries the original title "Indonesia Hit by Android Banking App Cloning Campaign" [8]. Severity is rated High on confirmed financial losses and numerous compromised devices, and on the abuse of the enterprise work profile feature to isolate and evade detection in consumer banking fraud [7]. It does not give a loss figure or a device count. Several of its mitigation and telemetry items are marked by its author as inferences rather than as Group-IB findings [13][14][15], and MITRE ATT&CK's page on Device Administrator Permissions is listed among the related references [20].
What to watch
- Whether Group-IB or the affected banks publish a loss figure or a compromised-device count for the Indonesian campaign.
- Whether Google tightens the conditions under which an unmanaged app can provision a work profile on a consumer phone.
- Whether banks begin treating a second profile on a handset they already know as the same device at registration.