Gigabud Banking Trojan Abuses Android Work Profiles to Evade Banking App Integrity Checks — Detection and Remediation Guide

On September 9, 2026, Group-IB published a report detailing a significant evolution of the Gigabud Android banking trojan: the malware now installs a secondary application that provisions an Android work profile on the infected device and deploys a tampered banking application inside it. Because Android isolates work profile contents from the personal profile, banking apps and on-device security scanners running in the personal space can no longer enumerate or integrity-check the malicious app — effectively blinding the very anti-fraud controls financial institutions rely on.

This is a meaningful escalation in mobile malware tradecraft. Gigabud has historically relied on overlay attacks, accessibility service abuse, and screen capture to steal banking credentials across Southeast Asia, Latin America, and beyond. By moving its payload into a work profile — a feature Android designed for enterprise device management — the operators are abusing a legitimate OS trust boundary to defeat detection. For SOC teams supporting financial institutions, mobile fraud teams, and any organization whose customers transact via Android, this technique demands updated detection logic and new incident response playbooks. There is no CVE here — this is pure technique abuse of intended OS functionality, which makes it harder to patch and entirely dependent on behavioral detection and device hygiene.

Technical Analysis

What Changed in This Gigabud Variant

Per Group-IB's September 9 report, the infection chain now looks like this from a defender's perspective:

1. Initial dropper installation. The victim is lured into sideloading a malicious APK — typically via phishing SMS (smishing), fake banking update pages, or malicious ads. The dropper requests high-risk permissions: accessibility services, notification access, and often device admin.
2. Secondary app installation. The dropper installs a second application whose sole job is to provision a work profile on the device. Normally, work profile creation is the domain of EMM/MDM solutions (e.g., via DevicePolicyManager.createAndManageUser() or the ACTION_PROVISION_MANAGED_PROFILE intent used during MDM enrollment). Gigabud's helper app abuses this provisioning path without an enterprise enrollment, creating an unmanaged, attacker-controlled profile.
3. Payload isolation. Inside the work profile, the malware drops a tampered clone of a legitimate banking app. Because Android enforces strong separation between the personal and work profiles — separate app storage, separate package namespaces visible per-profile — security software and legitimate banking apps in the personal profile cannot enumerate packages installed in the work profile. Anti-tamper and repackaging-detection checks in the real banking app come up empty.
4. Fraud execution. The victim interacts with the cloned banking app (or is steered to it via phishing), and credentials, session tokens, and OTPs are harvested and exfiltrated to Gigabud C2 infrastructure.

Why This Defeats Current Controls

• Package enumeration blindness: Apps in the personal profile calling PackageManager.getInstalledPackages() receive only personal-profile packages (absent cross-profile permissions, which only a legitimate profile owner/MDM holds). On-device AV and banking SDK root/tamper checks miss the malicious clone entirely.
• Play Protect scoping gaps: Google Play Protect scanning coverage across profile boundaries has historically been inconsistent for sideloaded packages in secondary profiles.
• MDM assumptions inverted: Enterprises assume work profiles are created by their MDM. A work profile on a device that was never enrolled in any EMM is itself a high-fidelity anomaly.

Affected Platforms

• OS: Android (work profile functionality applies broadly to Android 5.0+; modern Gigabud campaigns target current Android versions)
• Targets: Customers of regional and international banks; Group-IB has tracked Gigabud activity across Thailand, Peru, and other markets, with campaign targeting expanding
• Vector: Sideloaded APKs via smishing and malicious websites — not Google Play distribution in the observed campaigns

Exploitation Status

• Confirmed in the wild: Yes — this is an observed capability in active Gigabud campaigns as documented by Group-IB, not a proof-of-concept.
• CVE: None. This is abuse of legitimate Android work profile provisioning; there is no vendor patch forthcoming. Defense is behavioral and policy-based.
• CISA KEV: Not applicable (no CVE assigned).

Detection & Response

The core detection philosophy here: an unmanaged work profile is the anomaly. Consumer devices should almost never have a work profile. Enterprise devices should only have one created by your organization's MDM. Anything else is suspect. Layer that with visibility into APK sideloading, accessibility service grants to unknown packages, and network egress to non-store APK hosting.

Sigma Rules

---
title: Sideloaded APK Download from Non-Store Source
tid: 9f2c1d4e-7a3b-4c58-b2d6-1e8f5a9c3d71
status: experimental
description: Detects HTTP/S downloads of Android APK files from sources other than official app stores, consistent with Gigabud smishing dropper delivery. Tune store domain list to your environment.
references:
  - https://thehackernews.com/2026/09/gigabud-creates-android-work-profiles.html
  - https://attack.mitre.org/techniques/T1476/
author: Security Arsenal
date: 2026/09/15
tags:
  - attack.initial_access
  - attack.t1476
logsource:
  category: proxy
detection:
  selection:
    cs-uri|endswith: '.apk'
  filter_known_stores:
    cs-host|contains:
      - 'play.google.com'
      - 'play-fe.googleapis.com'
      - 'android.clients.google.com'
      - 'samsungapps.com'
      - 'galaxystore'
  condition: selection and not filter_known_stores
falsepositives:
  - Enterprise sideloading of internal apps via MDM or staging servers (allowlist your MDM distribution hosts)
  - Developer QA devices downloading test builds
level: high
---
title: ADB Package Installation on Managed Endpoint
tid: 3b7e9a12-5d4f-4c8e-91a6-2c7b8d4e5f93
status: experimental
description: Detects Android Debug Bridge package installation activity from Windows endpoints, which may indicate malware staging, unauthorized APK sideloading to test devices, or attacker use of ADB during hands-on activity.
references:
  - https://thehackernews.com/2026/09/gigabud-creates-android-work-profiles.html
  - https://attack.mitre.org/techniques/T1059/
author: Security Arsenal
date: 2026/09/15
tags:
  - attack.execution
  - attack.t1059
logsource:
  category: process_creation
  product: windows
detection:
  selection:
    Image|endswith: '\adb.exe'
    CommandLine|contains:
      - 'install'
      - 'pm install'
      - 'shell pm install'
      - 'create-profile'
      - 'pm create-user'
  condition: selection
falsepositives:
  - Mobile development and QA teams (scope rule to exclude developer OUs/hosts)
level: medium

KQL — Microsoft Sentinel / Defender

This query hunts network egress from mobile and endpoint devices requesting APK payloads from non-store infrastructure. It runs against Defender for Endpoint network telemetry (including onboarded Android devices via MDE for Android) and can be pivoted against proxy logs ingested as CommonSecurityLog.

// Hunt: APK downloads from non-official-store sources (Gigabud dropper delivery pattern)
// Covers MDE-onboarded Android devices and proxied corporate egress
let StoreDomains = dynamic(["play.google.com","play-fe.googleapis.com","android.clients.google.com","samsungapps.com","apk-dl.com"]);
let apkMDE = DeviceNetworkEvents
    | where TimeGenerated > ago(7d)
    | where RemoteUrl endswith ".apk"
    | where not(RemoteUrl has_any (StoreDomains))
    | project TimeGenerated, DeviceName, InitiatingProcessFileName, RemoteUrl, RemoteIP, ReportId
    | extend Source = "MDE";
let apkProxy = CommonSecurityLog
    | where TimeGenerated > ago(7d)
    | where RequestURL endswith ".apk"
    | where not(RequestURL has_any (StoreDomains))
    | project TimeGenerated, SourceIP, DestinationHostName, RequestURL, RequestMethod
    | extend Source = "Proxy";
union apkMDE, apkProxy
| order by TimeGenerated desc

If you ingest Android device logs or MDM telemetry (e.g., Intune, Workspace ONE, or Android logcat forwarded to a Log Analytics custom table), hunt for the work profile creation event directly — this is the highest-fidelity signal available:

// Hunt: Work profile provisioning events on devices with NO corresponding MDM enrollment
// Requires Android DevicePolicyManager audit logs or MDM telemetry ingested into Sentinel
AndroidDeviceEvents_CL
| where TimeGenerated > ago(14d)
| where EventType_s in ("MANAGED_PROFILE_CREATED","ACTION_PROVISION_MANAGED_PROFILE","CREATE_USER")
| join kind=leftanti (
    IntuneDevices  // replace with your MDM device inventory table
    | where TimeGenerated > ago(30d)
    | project DeviceName = tostring(DeviceName_s), ManagedBy = tostring(ManagedBy_s)
) on $left.DeviceId_s == $right.DeviceName
| project TimeGenerated, DeviceId_s, EventType_s, ProvisioningApp_s, UserId_s
| order by TimeGenerated desc

A device generating a managed-profile creation event with no MDM enrollment record is, in nearly every environment, malicious. Treat it as a confirmed-compromise trigger.

Velociraptor VQL

Velociraptor does not run on Android, but it is valuable for the surrounding investigation: hunting Windows/macOS endpoints for ADB staging activity and for APK artifacts that may have been downloaded to workstations before transfer (common in targeted or help-desk-assisted compromise scenarios).

-- Hunt for ADB execution and staged APK artifacts on endpoints
-- Gigabud-style droppers and mobile malware staging often touch ADB or leave APK files in user-writable paths
SELECT Pid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE Name =~ '(?i)adb'
   OR CommandLine =~ '(?i)pm install|create-user|provision.*profile'

-- Hunt for recently created/modified APK files in user directories
SELECT FullPath, Size, Mtime, Atime
FROM glob(globs=['C:/Users/*/Downloads/*.apk','C:/Users/*/Desktop/*.apk','/home/*/Downloads/*.apk'])
WHERE Mtime > now() - 604800
ORDER BY Mtime DESC

Remediation / Verification Script

The following Bash script uses adb to audit an Android device for unauthorized work profiles, suspicious package installations within profiles, and dangerous accessibility service grants. Run it against a device connected in debugging mode during IR, or adapt the command set for your MDM's remote-shell capability.

#!/bin/bash
# Gigabud Work Profile Audit — Android IR script (requires adb, device with USB debugging)
# Author: Security Arsenal — IR Team
# Run each check; any unmanaged work profile on a consumer device = treat as compromised.

echo "=== [1] Enumerate users/profiles on device ==="
adb shell pm list users
# EXPECTED on consumer devices: only 'UserInfo{0:...:13} running' (primary user)
# RED FLAG: any additional user/profile IDs (e.g., UserInfo{10:...:1030}) not created by corporate MDM

echo "=== [2] Identify the profile owner app (who created the work profile) ==="
adb shell dumpsys device_policy | grep -A5 -i "profile owner"
# LEGITIMATE: your MDM agent package (e.g., com.microsoft.intune, com.google.android.apps.work.clouddpc)
# RED FLAG: unknown/sideloaded package acting as profile owner

echo "=== [3] List packages installed in work profile (replace USER_ID from step 1) ==="
USER_ID=10
adb shell pm list packages --user $USER_ID
# RED FLAG: banking app clones, packages with random/obfuscated names, or sideloaded APKs

echo "=== [4] Audit enabled accessibility services (Gigabud persistence/abuse vector) ==="
adb shell settings get secure enabled_accessibility_services
# RED FLAG: any non-Google, non-OEM, non-MDM accessibility service

echo "=== [5] Audit device admin receivers ==="
adb shell dumpsys device_policy | grep -i "admin"

echo "=== [6] Check installation source of suspicious packages ==="
# For each suspect package:
# adb shell pm get-install-location
# adb shell dumpsys package <package.name> | grep -i "installerPackageName"
# RED FLAG: installerPackageName=null (sideloaded) or installer not com.android.vending / MDM agent

echo "=== [7] REMOVAL (only after evidence capture) ==="
# Remove the malicious work profile entirely (destroys all contained payloads):
# adb shell pm remove-user $USER_ID
# Then uninstall the dropper from the personal profile:
# adb shell pm uninstall --user 0 <dropper.package.name>
# Revoke accessibility/admin grants BEFORE uninstall if removal fails:
# adb shell settings put secure enabled_accessibility_services <clean-list>

echo "Audit complete. Preserve dumpsys output before remediation."

Remediation

Because this is technique abuse rather than a patchable vulnerability, remediation is layered: eradication on the device, policy hardening, and fraud-side containment.

For affected devices (IR containment):

1. Capture evidence first. Pull dumpsys device_policy, pm list users, package lists per profile, and accessibility settings before touching anything (script above).
2. Remove the malicious work profile via pm remove-user <id> — this destroys the tampered banking app and everything else in the profile in one operation.
3. Uninstall the dropper from the personal profile after revoking its accessibility and device-admin grants. If the device resists cleanup or the dropper has escalated, factory reset from a known-good state is the only reliable eradication path.
4. Treat all credentials on the device as compromised. Force password resets for banking and financial apps, revoke active sessions/tokens, and coordinate with the affected bank's fraud team for transaction review.

For financial institutions and app developers:

• Update banking app anti-tamper logic to detect the presence of any work profile on non-MDM devices (DevicePolicyManager.getProfileOwner(), UserManager.getUserProfiles()) and step-up authentication or block sessions accordingly — a consumer device with an unmanaged work profile is a strong compromise indicator.
• Do not rely solely on package enumeration for clone detection; add server-side anomaly detection on session behavior, device fingerprints, and transaction patterns.

For enterprise/MDM administrators:

• Enforce Google Play Protect and block "Install unknown apps" (INSTALL_UNKNOWN_SOURCES) on managed devices via MDM policy.
• Alert on any work profile creation event not originating from your EMM — ingest Android management audit logs into your SIEM and build the correlation shown in the KQL section.
• Educate users on smishing lures impersonating bank "security updates" — Gigabud's delivery depends entirely on social engineering the initial sideload.

Patch/advisory status: There is no vendor patch and no CVE; monitor the Group-IB report and The Hacker News coverage for updated indicators as campaigns evolve.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub