Mobile banking telah mengubah smartphone menjadi salah satu titik transaksi paling penting bagi Bank. Nasabah dapat login, mengecek saldo, melakukan transfer, hingga melakukan pembayaran hanya melalui satu aplikasi.

Namun ada satu bagian dari transaction environment yang tidak sepenuhnya berada di bawah kendali Bank: smartphone milik nasabah.

Pertanyaannya kemudian menjadi lebih serius ketika smartphone tersebut telah dikompromikan malware.

ToxicPanda 2.0 menunjukkan bagaimana sebuah Android banking Trojan dapat menyalahgunakan Accessibility Service, melakukan screen overlay, mencuri PIN, memonitor aplikasi finansial, hingga memperoleh kemampuan kontrol yang lebih tinggi pada perangkat korban.

Bagi Bank, ini bukan lagi sekadar persoalan malware di sisi endpoint.

ToxicPanda 2.0 adalah customer-side security problem yang pada akhirnya dapat berubah menjadi Bank-side financial risk.

Ketika Mobile Banking Berjalan di Device yang Sudah Tidak Trusted

Dalam arsitektur mobile banking, Bank biasanya memiliki beberapa lapisan pengamanan: authentication, API security, transaction monitoring, fraud detection, network security, hingga security controls pada backend.

Tetapi semua itu pada akhirnya berinteraksi dengan satu komponen yang berada di luar perimeter Bank: device nasabah.

Selama smartphone masih berada dalam kondisi trusted, mobile banking application dapat berfungsi sebagaimana mestinya.

Masalah muncul ketika attacker terlebih dahulu mengambil alih environment tempat aplikasi tersebut berjalan.

Dalam kondisi seperti ini, persoalannya bukan selalu:

“Apakah server Bank berhasil ditembus?”

Melainkan:

“Apakah mobile banking application masih berjalan di environment yang dapat dipercaya?”

Inilah celah yang membuat mobile application security semakin penting.

ToxicPanda 2.0: Ketika Malware Tidak Hanya Mencuri Credential

ToxicPanda 2.0 merupakan varian terbaru dari Android banking Trojan yang memperluas kemampuan remote control, credential theft, dan financial fraud.

Dalam analisis teknis terbaru, ToxicPanda 2.0 memiliki 167 remote commands dan memperluas target overlay-based credential theft hingga 349 banking, financial, e-wallet, dan cryptocurrency applications di 16 negara. Varian ini juga memiliki mekanisme pencurian PIN yang menargetkan lebih dari 140 aplikasi banking dan cryptocurrency.

Yang menarik bukan hanya jumlah targetnya, tetapi bagaimana malware tersebut beroperasi.

1. Abuse Android Accessibility Service

ToxicPanda 2.0 memanfaatkan Android Accessibility Service untuk membaca UI elements, melakukan remote control, dan mengotomatisasi aktivitas pada perangkat.

Artinya, attacker tidak harus melakukan serangan langsung terhadap backend Bank untuk memanipulasi aktivitas nasabah.

Malware dapat beroperasi dari dalam device dan berinteraksi dengan aplikasi yang sedang digunakan korban.

2. Mengenali Aplikasi Financial yang Terpasang

Setelah terinstal, ToxicPanda 2.0 dapat melakukan enumeration terhadap aplikasi yang terdapat di device dan mengirimkan package names serta icons ke command-and-control (C2) server.

Dari sana, attacker dapat mengidentifikasi aplikasi banking, financial, e-wallet, maupun cryptocurrency yang menjadi target.

3. Menampilkan Malicious Overlay

Ketika korban membuka aplikasi yang menjadi target, malware meminta HTML overlay dari C2 server.

Overlay tersebut dibuat menyerupai login atau transaction screen aplikasi asli sehingga korban dapat diarahkan untuk memasukkan credential, PIN, maupun informasi sensitif lainnya.

Di sinilah risiko terhadap mobile banking menjadi nyata.

Aplikasi Bank mungkin tidak mengalami modification apa pun.

Tetapi environment di sekeliling aplikasi sudah dimanipulasi oleh attacker.

4. PIN dan Touch Input Menjadi Target

ToxicPanda 2.0 juga memiliki workflow untuk memonitor financial applications dan melakukan PIN harvesting.

Ketika aplikasi target digunakan, malware dapat menggunakan transparent overlay untuk menangkap touch input yang diberikan korban. Konfigurasi target bahkan dapat diperbarui secara dinamis melalui command dari C2.

5. Wireless Debugging dan ADB Disalahgunakan

Salah satu perkembangan yang lebih serius adalah abuse terhadap Android Wireless Debugging.

Melalui Accessibility Service, malware dapat mengaktifkan Developer Options, mengaktifkan Wireless Debugging, mengambil pairing code, kemudian melakukan pairing dengan Android Debug Bridge (ADB).

Setelah memperoleh shell-level permission, ToxicPanda 2.0 dapat menjalankan sejumlah command dengan privilege yang lebih tinggi, termasuk memberikan permission, mengurangi pembatasan background, dan mempertahankan persistence.

Dengan kata lain, malware tidak hanya berusaha “mengintip” aplikasi.

Ia berusaha mengendalikan environment tempat aplikasi berjalan.

Mengapa Ini Menjadi Masalah Bank?

Bayangkan sebuah transaksi legitimate:

Nasabah → Smartphone → Mobile Banking App → API → Bank Backend

Dalam model keamanan tradisional, fokus utama sering berada di sisi API, backend, authentication, dan network.

Tetapi ToxicPanda menunjukkan skenario berbeda:

Attacker → Compromised Smartphone → Manipulated Environment → Mobile Banking App → Legitimate Backend

Dari perspektif backend, request tersebut masih dapat terlihat seperti request dari nasabah yang sah.

Risikonya muncul karena attacker telah memperoleh kemampuan untuk memanipulasi apa yang terjadi sebelum transaksi mencapai backend.

Ini membuat mobile application menjadi security control yang sangat penting.

Bank memang tidak dapat mengendalikan seluruh smartphone nasabah.

Namun Bank dapat mengendalikan aplikasi yang mereka distribusikan.

Dan aplikasi tersebut harus mampu mengenali ketika environment tempatnya berjalan tidak lagi trusted.

Dari Device Security ke Runtime Application Security

Pendekatan ini membawa kita pada konsep Runtime Application Self-Protection (RASP).

Berbeda dengan security control yang bekerja di perimeter atau hanya melakukan assessment sebelum aplikasi dirilis, RASP bekerja ketika aplikasi sedang berjalan.

Tujuannya adalah mendeteksi kondisi runtime yang mencurigakan dan memberikan response berdasarkan security policy yang telah ditentukan.

Untuk mobile banking, pendekatan ini menjadi relevan karena threat tidak selalu berbentuk malicious request ke server.

Threat dapat terjadi ketika:

• aplikasi berjalan pada compromised device;
• terdapat runtime manipulation;
• aplikasi dimodifikasi atau dijalankan dari sumber yang tidak trusted;
• attacker mencoba melakukan hooking atau code injection;
• terdapat screen mirroring atau screen overlay;
• terdapat malicious application yang mencoba berinteraksi dengan aplikasi;
• komunikasi aplikasi berusaha diintercept melalui Man-in-the-Middle (MiTM).

Dengan RASP, sebagian security decision dapat dilakukan di dalam application runtime itu sendiri.

Bagaimana AppProtectt Relevan terhadap Attack Techniques ToxicPanda?

Salah satu pendekatan yang dapat digunakan Bank adalah menambahkan application-layer protection melalui AppProtectt dari Protectt.ai.

AppProtectt merupakan mobile application security platform berbasis RASP dengan lebih dari 100 security features yang mencakup device security, network security, application security, anti-malware, user behavior & fraud controls, serta telematics dan management.

Yang penting, mapping terhadap ToxicPanda harus dipahami sebagai mitigasi terhadap attack techniques, bukan klaim bahwa AppProtectt secara spesifik mendeteksi seluruh varian ToxicPanda 2.0.

1. Compromised Device → Device Integrity Validation

ToxicPanda beroperasi dari compromised Android device.

AppProtectt memiliki controls untuk mendeteksi kondisi seperti Jailbreak/Root, insecure configuration, simulator/emulator, dan virtual device. AppProtectt juga menyediakan compromised-device detection sebagai bagian dari in-app protection.

Ini memberikan Bank kemampuan tambahan untuk mengevaluasi apakah mobile banking application sedang berjalan pada environment yang berisiko.

2. Overlay Attack → Screen Overlay Mitigation

ToxicPanda menggunakan malicious overlay untuk meniru interface aplikasi financial dan mencuri informasi dari korban.

AppProtectt menyediakan Screen Overlay Mitigation, termasuk Anti-Screen Mirroring dan Screenshot Protection. Platform ini juga memiliki App Spoofing dan Tapjacking Protection.

Security control seperti ini relevan untuk mengurangi risiko manipulasi visual dan interaction layer pada mobile application.

3. Runtime Manipulation → Anti-Hooking & Anti-Code Injection

ToxicPanda memiliki kemampuan remote control dan melakukan berbagai bentuk manipulasi pada device.

Pada application layer, AppProtectt menyediakan Anti-Debugging & Code Injection Prevention, Runtime Manipulation Detection, serta blocking terhadap hooking frameworks seperti Frida.

Ini penting karena attacker yang berhasil menjalankan instrumentation atau hooking terhadap aplikasi dapat berusaha memanipulasi application logic saat runtime.

4. Malicious / Side-loaded Application → Application Integrity

ToxicPanda sendiri didistribusikan sebagai malware/dropper dan menggunakan mekanisme tertentu untuk memasang payload pada device korban.

AppProtectt menyediakan Tampered App & Runtime Manipulation Detection, Installation Source Validation, APK Locking, Runtime Integrity Checks, dan Side-Loaded App Detection.

Controls tersebut membantu Bank memperkuat application integrity dan mengidentifikasi kondisi aplikasi atau environment yang tidak sesuai dengan security policy.

5. Credential Interception → Malware & Screen Protection

ToxicPanda memanfaatkan overlay, Accessibility Service, dan touch capture untuk memperoleh informasi sensitif dari korban.

AppProtectt memiliki sejumlah controls yang relevan terhadap skenario ini, termasuk Anti-Screen Mirroring, Screen Overlay Mitigation, App Spoofing & Tapjacking Protection, serta Unsecured Keyboard & Key-Logger App Prevention.

Namun, sekali lagi, controls tersebut sebaiknya dipandang sebagai bagian dari defense-in-depth, bukan sebagai satu mekanisme tunggal yang menjamin seluruh credential theft dapat dihentikan.

Yang Harus Bank Persiapkan

ToxicPanda 2.0 memberikan satu pelajaran penting: mobile banking security tidak dapat berhenti di backend.

Bank membutuhkan security architecture yang memperlakukan mobile application sebagai bagian dari security perimeter.

Setidaknya terdapat beberapa lapisan yang perlu dipertimbangkan:

01 — Device Risk Detection

Identifikasi compromised, rooted, jailbroken, emulated, atau otherwise risky devices sebelum aplikasi memberikan akses terhadap aktivitas sensitif.

02 — Application Integrity

Pastikan aplikasi yang berjalan tidak mengalami tampering, modification, repackaging, atau runtime manipulation.

03 — Runtime Protection

Gunakan RASP untuk mendeteksi kondisi berisiko ketika aplikasi sedang aktif, termasuk hooking, debugging, code injection, dan manipulation.

04 — Interaction Protection

Lindungi authentication dan transaction interface dari screen overlay, screen mirroring, spoofing, tapjacking, dan bentuk manipulasi UI lainnya.

05 — Network Protection

Perkuat communication channel dengan controls seperti SSL Pinning, MiTM protection, dan detection terhadap unsecured network environment. AppProtectt menyediakan controls pada area tersebut.

06 — Backend & Fraud Detection Tetap Diperlukan

RASP bukan pengganti API security, authentication, transaction monitoring, fraud detection, atau backend security.

Justru sebaliknya.

Application runtime protection harus menjadi salah satu layer dalam defense-in-depth architecture.

Jika application dapat memberikan telemetry mengenai device dan runtime environment, informasi tersebut juga dapat menjadi input tambahan bagi security dan fraud teams untuk menentukan apakah sebuah session perlu dilanjutkan, diperingatkan, dicatat, atau diblokir.

AppProtectt sendiri menyediakan Live Threat Dashboard, ML-enabled automated threat alerts, serta flexible response berupa Block, Warn, atau Log.

Bukan Tentang Mengontrol Smartphone Nasabah

Pada akhirnya, Bank memang tidak dapat sepenuhnya mengontrol smartphone nasabah.

Tetapi Bank dapat mengontrol bagaimana mobile banking application bereaksi ketika environment tersebut tidak lagi trusted.

Inilah pergeseran penting dalam mobile application security.

Security tidak lagi hanya bertanya:

“Apakah user sudah authenticated?”

Tetapi juga:

“Apakah application sedang berjalan dalam kondisi yang masih layak dipercaya?”

Karena user yang legitimate dapat menggunakan device yang sudah compromised.

Dan transaction yang legitimate dapat dilakukan melalui application yang berjalan di environment yang telah dimanipulasi attacker.

ToxicPanda 2.0 memperlihatkan bahwa boundary antara device compromise dan financial fraud semakin tipis.

Bagi Bank, responsnya bukan sekadar menambahkan security tool baru.

Yang lebih penting adalah memastikan setiap layer—device, application, network, authentication, API, backend, hingga fraud detection—dapat saling melengkapi.

Key Takeaways

1. Mobile banking application adalah bagian dari security perimeter Bank.
Walaupun smartphone nasabah berada di luar kontrol langsung Bank, application yang berjalan di dalamnya tetap dapat diperkuat.

2. ToxicPanda 2.0 menyerang environment, bukan hanya credential.
Accessibility abuse, overlay, PIN harvesting, runtime control, dan Wireless Debugging menunjukkan bagaimana attacker dapat memanipulasi device dari sisi client.

3. RASP memberikan visibility dan protection pada runtime layer.
Bank dapat menambahkan security controls yang bekerja ketika application sedang digunakan, bukan hanya sebelum application dirilis.

4. AppProtectt dapat menjadi salah satu application security layer.
Capabilities seperti compromised-device detection, anti-hooking, anti-tampering, screen overlay mitigation, app spoofing protection, dan runtime integrity checks relevan terhadap sejumlah attack techniques yang digunakan oleh ToxicPanda 2.0.

5. Tidak ada single security control yang cukup.
RASP harus berjalan bersama authentication, API security, backend protection, transaction monitoring, fraud detection, dan security monitoring lainnya.

Saat Mobile Banking Menjadi Target, Application Harus Mampu Membela Dirinya Sendiri

ToxicPanda 2.0 menunjukkan bahwa attacker tidak selalu perlu menembus infrastructure Bank untuk menciptakan financial risk.

Mereka dapat memulai dari device nasabah, menguasai environment, kemudian memanfaatkan legitimate mobile banking application untuk mencapai tujuan mereka.

Karena itu, pertanyaan bagi Bank bukan lagi sekadar:

“Bagaimana kita mengamankan mobile banking application?”

Tetapi:

“Bagaimana mobile banking application dapat tetap mempertahankan security posture ketika device tempatnya berjalan sudah tidak trusted?”

Itulah ruang yang ingin dijawab oleh Runtime Application Self-Protection (RASP).

Jika Anda ingin memahami bagaimana AppProtectt dapat diterapkan sebagai additional security layer untuk mobile banking dan financial applications, hubungi Dymar Jaya Indonesia untuk mendiskusikan kebutuhan dan security architecture yang sesuai dengan environment Anda.