Malware APK

As a bug hunter, are your bug bounty reports getting rejected because you don't use a "malicious" Proof of Concept (PoC) app to exploit the vulnerabilities?

As a security engineer, do you struggle with validating bug bounty reports, performing regression testing, and conduct penetration testing?

I've got you covered - all from the comfort of your own device!

YouTube: Malware APK v5.0 - Proxy Intent Injection PoC

---

Rooting your device is not required.

For more tips and tricks check my Android Penetration Testing Cheat Sheet.

---

Built with Android Studio v2024.3.2 (64-bit) (JDK 17) and tested on Samsung Galaxy Note S20 Ultra with Android OS v13.0 (Tiramisu).

Made for educational purposes. I hope it will help!

Future plans:

• add an option to bind to a service,
• add an option to specify intent categories,
• add an option to specify null in intent extras,
• add a content encoding and decoding section,
• add a log toolbar with search, copy, scroll to top, and more,
• add a project to easily compile native .so libraries for arbitrary code execution,
• add more UI customizations.

Table of Contents

• About the App
• Usage
  • File System
  • Process
  • Enumeration
  • Intent
  • Broadcast Monitor
  • Web
  • Task Hijacking
  • Tap Hijacking
  • Accessibility Monitor
  • Notification Monitor
  • Clipboard
  • State Manager
  • Settings

About the App

Version: 5.0

APK name: Malware APK

Package name: com.kira.malware

Min. SDK: 29 (Android 10)

Target SDK: 35

Exported activities:

• com.kira.malware.activities.MainActivity
• com.kira.malware.activities.HiddenActivity

Permissions required:

• android.permission.READ_EXTERNAL_STORAGE
• android.permission.WRITE_EXTERNAL_STORAGE
• android.permission.QUERY_ALL_PACKAGES
• android.permission.INTERNET
• android.permission.SYSTEM_ALERT_WINDOW
• android.permission.BIND_ACCESSIBILITY_SERVICE
• android.permission.BIND_NOTIFICATION_LISTENER_SERVICE
• android.permission.POST_NOTIFICATIONS

URIs for internal quality assurance:

• kira://hidden
• content://com.kira.malware.TestFileProvider/files/test.txt
• content://com.kira.malware.TestSQLiteProvider
• javascript:alert(JavaScriptBridge.test())

Usage

File System

#1: Read and modify files of another app.

#2: Read world-readable shared preferences of another app.

#3: To access files of another app, modify the sharedUserId in this app's AndroidManifest.xml, then rebuild the APK - this works only if another app has the shared user ID defined.

Figure 1 - File System

Process

#1: Not all devices or root tools store the su (switch user) binary in the same location.

#2: Run CLI tools such as /system/bin/logcat or start a reverse shell with user /bin/sh or root /bin/su privileges.

Figure 2 - Running CLI Tools

Enumeration

#1: Read the manifest file of another app.

#2: List protected or exported components of another app.

#3: Request a custom permission defined by another app by declaring it in this app's AndroidManifest.xml, then rebuild the APK - this works only if the permission's protection level is not signature.

<permission
    android:name="com.someapp.dev.CUSTOM_PERMISSION"
    android:protectionLevel="normal" />
<uses-permission android:name="com.someapp.dev.CUSTOM_PERMISSION" />

#4: List system or user installed packages.

Figure 3 - Enumeration

Intent

#1: Test an intent filter of another app.

#2: Send an intent to another app to directly bypass its biometric / security.

#3: Send an intent to another app to indirectly bypass its biometric / security by triggering its push notification manager, then manually opening the received push notification.

#4: Send an intent to another app to poison its widget.

#5: Send a [pending] intent to another app multiple times to cause Denial of Service (DoS).

#6: Send a mutable pending intent to another app to extract subsequently added intent extras.

#7: Access a protected component, such as a file or SQLite content provider of another app, by exploiting the app's exported (proxy) component.

#8: Test a deep link of another app.

#9: Perform a battering ram attack on a deep link or content provider URI of another app by adding </payload> placeholder in the intent's URI.

#10: You can send an intent to HiddenActivity for inspection before sending it to another app.

#11: Test a file content provider for path traversal via ../, and for arbitrary file read / write.

#12: Test an SQLite content provider for SQL injection via projection and selection.

Projection SQLi example:

* from sqlite_master--

Selection SQLi example:

1=1) OR 2=2--

---

The following applies only to the proxy intent extras:

• If the value is a string equal to </target-pending-intent>:
  • the entire value will be replaced with an PendingIntent object of target intent,
  • and Intent.putParcelable() will be used.
• If the value is a string equal to </target-intent>:
  • the entire value will be replaced with an Intent object of target intent,
  • and Intent.putParcelable() will be used.
• If the value is a string containing </target-intent-uri>:
  • all matching parts will be replaced with Intent.toUri(Intent.URI_INTENT_SCHEME) of target intent.
• If the value is a string containing </target-intent-uri-unsafe>:
  • all matching parts will be replaced with Intent.toUri(Intent.URI_ALLOW_UNSAFE) of target intent.

The following applies to both the proxy intent and target intent extras, but only if they are launching com.kira.malware.activities.HiddenActivity:

• To use the file content provider read callback:
  • add an intent extra with the type string,
  • key HiddenActivity,
  • and value </file-provider-read>.
• To use the file content provider write callback:
  • add an intent extra with the type array list,
  • key HiddenActivity,
  • value </file-provider-write>,
  • and required source file.
• To use the SQLite content provider query callback:
  • add an intent extra with the type string,
  • key HiddenActivity,
  • and value </sqlite-provider-query>.
• To use the SQLite content provider query with filtering callback:
  • add an intent extra with the type array list,
  • key HiddenActivity,
  • value </sqlite-provider-query-filter>,
  • and optional projection and selection.
• To auto-close the callback activity on error:
  • add an intent extra with the type string,
  • key HiddenActivityClose,
  • and value </close-on-error>.
• To auto-close the callback activity on success:
  • add an intent extra with the type string,
  • key HiddenActivityClose,
  • and value </close-on-success>.

When testing intent injections, you will often need to specify com.kira.malware.activities.HiddenActivity as the target intent class name, and scope the file or SQLite content provider intent extra to the same target intent, as shown in the images below.

---

Figure 4 - Deep Link Fuzzing

Figure 5 - Pending Intent Injection P1

Figure 6 - Pending Intent Injection P2

Figure 7 - Intent Injection P1

Figure 8 - Intent Injection P2

Broadcast Monitor

#1: Listen for a broadcast intent from another app and extract sensitive information from the intent extras.

Figure 9 - Broadcast Monitor

Web

#1: Verify whether misconfigured asset links allow app link hijacking - this applies only to intent filters with autoVerify attribute.

#2: Hijack a deep link of another app by specifying it in this app's AndroidManifest.xml under HiddenActivity, then rebuild the APK.

<data
    android:host="hidden"
    android:scheme="kira" />

#3: Initiate a deep link callback from a website to hijack the flow of another app.

#4: Leverage existing web browser sessions to hijack the authenticated flow of another app.

#5: Hijack the OAuth flow and complete it by automating the remaining steps.

#6: All values extracted from a deep link or response body are URL-decoded and only URL-encoded when inserted into the URL query string (after ?) of another request.

Each time you launch the app, make sure to open the Web section to activate the deep link callback flow.

Figure 10 - Web

Figure 11 - Deep Link Callback

Task Hijacking

#1: Changing the task affinity at runtime is not possible.

#2: To hijack a task of another app, modify the task affinity in this app's AndroidManifest.xml under MainActivity, then rebuild the APK

Read more about the taskjacking here.

Figure 12 - Taskjacking

Tap Hijacking

#1: Test if another app can detect an overlay.

#2: Detect an overlay by checking MotionEvent.FLAG_WINDOW_IS_OBSCURED and MotionEvent.FLAG_WINDOW_IS_PARTIALLY_OBSCURED flags - this solution works only on older Android versions.

Read more about tapjacking here.

Figure 13 - Tapjacking

Accessibility Monitor

#1: Extract sensitive information from the UI of another app by abusing the accessibility service.

Read more about the solution here.

Figure 14 - Accessibility Monitor

Notification Monitor

#1: Extract sensitive information from a push notification of another app by abusing the notification service.

Figure 15 - Notification Monitor

Clipboard

#1: Set the clipboard.

#2: Dump the clipboard and look for sensitive information.

Figure 16 - Clipboard

State Manager

#1: Save and load UI states at any time.

#2: Download and share UI state files with others, and upload UI state files shared by others at any time.

Figure 17 - State Manager

Settings

#1: Additional system controls and UI customizations.

#2: Biometric unlock prompts only once at launch. Clear all tasks to enable it again.

Figure 18 - Settings