Android Pentesting Mindmap:

MindMap Credit : h0tPlug1n

Setup Android Pentesting Lab

1. Download any emulator.
   • Genymotion
   • NoxPlayer
   • Android Studio

Get root Shell with ADB:

$ > adb shell
generic_x86:/ $
generic_x86:/ $ exit
$ > adb root
restarting adbd as root
$ > adb shell
generic_x86:/ #

Other Method

adb -e shell
su root
cd /system/bin
chmod 06755 su

2. Proxy Configuration
   • Export burpsuite certificate
   • Configured port and interface in burp sute.
   • Setup manul proxy in android device and enter the ip and port of burp config.
   • Send Burpsuite certificate in android and install.
   • Burp configuration done.

Check packages

#  List all installed package names
adb shell pm list packages

# List all installed packages with their APK file paths
adb shell pm list packages -f

#  (Windows PowerShell) Filter the list of packages to find ones containing "camera"
adb shell pm list packages | Select-String "camera"

#  (Linux/macOS or Git Bash) Filter the list of packages for "camera"
adb shell pm list packages | grep camera

Setup Frida server

• Check architecture and download frida-server

# Check androi architecture
adb shell getprop ro.product.cpu.abi

#  Step 1: Push frida-server to Android device
adb push frida-server-x86_64 /data/local/tmp/

#  Step 2: Set executable permissions
adb shell "chmod 755 /data/local/tmp/frida-server-x86_64"

#  Step 3: Start frida-server in background
adb shell
# Inside the shell:
su
/data/local/tmp/frida-server-x86_64 > /dev/null 2>&1 &

#  Step 4: Verify frida-server is running
ps | grep frida
netstat -an | grep 27042

#  Optional: From PC, test if Frida server is responding
frida-ps -U

SSL Pinning Bypass using Frida

# Run Frida to bypass SSL pinning using a custom script
frida -U -f com.example.app -l ssl-fridascript.js

# Run Frida to bypass SSL pinning using a public script from Frida's Codeshare
frida --codeshare pcipolloni/universal-android-ssl-pinning-bypass-with-frida -f YOUR_BINARY

# Use Objection to bypass SSL pinning dynamically on the app (with Frida)
objection --gadget com.example.app explore --disable-ssl-pinning

Updates

Common Methods to Bypass SSL Pinning and Intercept Traffic

Modules and application

Name	Link
SSLUnpinning_Xposed	SSLUnpinning_Xposed
Android-SSL-TrustKiller	Android-SSL-TrustKiller
JustTrustMe	JustTrustMe

Frida and Objection

Tool	Command
Frida (SSL unpinning script via Codeshare)	frida --codeshare masbog/frida-android-unpinning-ssl -f com.example.vulnerableapp
Objection (explore app)	objection -g com.example.vulnerableapp explore

Custom CA Injection (Keystore Modification / Certificate Trust Abuse)

If the application keystore location and password are known, a custom CA certificate (e.g., Burp Suite CA) can be injected into the keystore so the app trusts intercepted HTTPS traffic.

Step	Command
Export Burp CA certificate	Export burp.crt from Burp Suite
Import certificate into BKS keystore	keytool -importcert -v -trustcacerts -file burp.crt -alias burpca -keystore keystore.bks -provider org.bouncycastle.jce.provider.BouncyCastleProvider -providerpath bcprov-ext-jdk15on-1.46.jar -storetype BKS -storepass testing
Rebuild APK	apktool b app -o modified.apk
Sign APK	apksigner sign --ks mykey.keystore --out signed.apk modified.apk

Decompile, Compile and Singn APK

Step	Command
Decompile APK	apktool d app.apk
Rebuild APK	apktool b app -o modified.apk
Create Keystore	keytool -genkeypair -v -keystore mykey.keystore -alias myalias -keyalg RSA -keysize 2048 -validity 10000
Sign APK (apksigner)	apksigner sign --ks mykey.keystore --out signed.apk modified.apk
Verify APK (apksigner)	apksigner verify signed.apk
Sign APK (jarsigner)	jarsigner -verbose -sigalg SHA256withRSA -digestalg SHA-256 -keystore mykey.keystore modified.apk myalias
Align APK	zipalign -v 4 modified.apk signed.apk
Verify Signature (jarsigner)	jarsigner -verify modified.apk

PID Cat

https://github.com/JakeWharton/pidcat/

Objection – Pasteboard / Clipboard Attack

Upon copy the sensitive data, you will get hare data pasted like credit cared numere, etc.

Tool	Command
Objection (monitor clipboard / pasteboard data)	objection --gadget com.example.vulnerableapp explore
Inside Objection shell (start clipboard monitor)	android clipboard monitor

Frida updated commands

objection -n owasp.sat.agoat start

Explanation of Flags

- -U   : Connects to a USB-connected Android device
- -f   : Specifies the package name to spawn (e.g., com.example.app)
- -l   : Loads the provided Frida script (e.g., ssl-fridascript.js)

Root Detection Bypass:

# Run Frida to bypass SSL pinning using a custom script
frida -U -f com.example.app -l ssl-fridascript.js

# Run Frida to bypass SSL pinning using a public script from Frida's Codeshare
frida --codeshare pcipolloni/universal-android-ssl-pinning-bypass-with-frida -f YOUR_BINARY

# Use Objection to bypass SSL pinning dynamically on the app (with Frida)
# This command uses Objection, a Frida-based tool, to disable SSL pinning dynamically on the app
objection --gadget com.example.app explore --disable-ssl-pinning

# Use Objection to bypass root detection on the app dynamically
# This command uses Objection to bypass root detection mechanisms and provide an interactive shell for further exploration
objection --gadget com.example.app explore --disable-root-detection

Emulator Bypass

#root and emulator bypass
frida --codeshare cubetech126/root-and-emulator-detection-bypass -f YOUR_BINARY

Useful Frida and ADB Commands

# Check if frida-server is running on the device
adb shell "ps -e | grep frida-server"

# List all installed packages with APK paths
adb shell "pm list packages -f"

# List all running applications with identifiers (name, PID, etc.)
frida-ps -Ua

# List all applications with detailed metadata
frida-ps -Uai

---

SSL Unpinning using Xposed Module (Alternative Method)

1. Clone the SSL Unpinning Xposed module:

   git clone https://github.com/ac-pm/SSLUnpinning_Xposed.git

2. Navigate to the directory:

   cd SSLUnpinning_Xposed

3. Install the APK:

   adb install mobi.acpm.sslunpinning_latest.apk

4. Open the installed app on the Android device and enable SSL unpinning.

Requires a rooted device with Xposed Framework or LSPosed installed.

---

Basics of Android

Android Manifest file

An Android Manifest file (AndroidManifest.xml) is a crucial part of any Android app. It provides essential information to the Android system, including the app's package name, components (activities, services, broadcast receivers, content providers), permissions, and hardware/software requirements.

A a comprehensive yet concise description of the Android terminologies from your image, along with examples:

---

1. Activity

• Definition: Represents a single screen with a user interface in an app.
• Example: A login screen (LoginActivity) or a home screen (HomeActivity).

---

2. Content Provider

• Definition: Manages access to a structured set of data, often shared between apps.
• Example: Contacts app provides contacts data via ContentProvider.

---

3. Content Resolver

• Definition: Acts as a client API to communicate with a ContentProvider.
• Example: Fetching contacts from the phone's ContactsProvider:

  Cursor cursor = getContentResolver().query(ContactsContract.Contacts.CONTENT_URI, null, null, null, null);

---

4. Broadcast Receiver

• Definition: Responds to system-wide or app-specific broadcast messages.
• Example: Receiving a broadcast when the device's battery is low:

  public class BatteryReceiver extends BroadcastReceiver {
      @Override
      public void onReceive(Context context, Intent intent) {
          // Handle the battery low broadcast
      }
  }

---

5. Intent

An Intent is a messaging object in Android used to communicate between components or trigger an action. It can either target components within the application or outside of it.

Types of Intents:

1. Explicit Intent:

   • Targets components within the application by explicitly specifying the name of the target component (e.g., activity, service, or broadcast receiver).
   • Example: Switching from one activity to another within the app:

     Intent intent = new Intent(this, SecondActivity.class);
     startActivity(intent);

2. Implicit Intent:

   • Targets components outside the application by specifying a general action. The Android system resolves the intent and finds an appropriate external app to handle the action.
   • Example: Opening a webpage in a browser:

     Intent intent = new Intent(Intent.ACTION_VIEW, Uri.parse("http://www.example.com"));
     startActivity(intent);

---

6. Intent Filter

• Definition: Declares the capabilities of a component (like an Activity) to handle specific intents.
• Example: Enabling an activity to handle share actions:

  <intent-filter>
      <action android:name="android.intent.action.SEND" />
      <category android:name="android.intent.category.DEFAULT" />
      <data android:mimeType="text/plain" />
  </intent-filter>

---

7. Intent Resolution

• Definition: The process of matching an intent with a suitable Intent Filter.
• Example: Resolving an implicit intent to open a web page in the browser.

---

8. Services

• Definition: Background tasks running without a user interface.
• Example: Playing music in the background via MediaPlayerService.

---

Indentify and exploit components

Test Area	What to Check	Command / Example	Possible Impact
Exported Activity	Unauthorized screen access	adb shell am start -n com.app/.AdminActivity	Auth bypass
Deep Link	Parameter tampering	myapp://transfer?amount=9999	Business logic abuse
Intent Extras	Trusted external input	--es role admin	Privilege escalation
Broadcast Receiver	Sensitive broadcast actions	adb shell am broadcast -a com.app.RESET	Unauthorized actions
Service	Exported service misuse	adb shell am startservice -n com.app/.SyncService	Internal function abuse
Content Provider	Data exposure	adb shell content query --uri content://app/users	Sensitive data leak
WebView Deep Link	Arbitrary URL loading	myapp://open?url=https://evil.com	Phishing/XSS
Intent Redirection	Nested intent forwarding	Passing malicious intent	Protected activity access
Manifest Review	Exported components	Search android:exported="true"	Attack surface discovery
Deep Link Discovery	URI schemes	Search <intent-filter>	Entry point discovery

AndroidManifest.xml Vulnerable configuration and Mitigation:

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.example.vulnerableapp">

    <!-- VULNERABILITY: Outdated minSdkVersion -->
    <!-- RISK: Using a low minSdkVersion (e.g., 16) means the app could run on devices with old security mechanisms, exposing it to known vulnerabilities. -->
    <!-- SOLUTION: Set a higher minSdkVersion to exclude outdated, insecure Android versions. -->
    <uses-sdk
        android:minSdkVersion="16"  <!-- Very low API level -->
        android:targetSdkVersion="30"  <!-- Not targeting the latest SDK -->
        android:maxSdkVersion="31" />  <!-- RISK: Restricting maxSdkVersion limits future OS features. -->
    <!-- SOLUTION: Always target the latest stable SDK version. -->

    <!-- General Permissions -->
    <uses-permission android:name="android.permission.INTERNET" />
    <uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" />
    <uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" />
    <uses-permission android:name="android.permission.READ_EXTERNAL_STORAGE" />
    <uses-permission android:name="android.permission.READ_CONTACTS" />
    <uses-permission android:name="android.permission.SEND_SMS" />
    <uses-permission android:name="android.permission.RECEIVE_SMS" />
    <uses-permission android:name="android.permission.SYSTEM_ALERT_WINDOW" />
    <!-- SOLUTION: Only request permissions necessary for your app's functionality. Over-permissioning increases risk. -->

    <application
        android:allowBackup="true"  <!-- VULNERABILITY: Backup of app data can lead to sensitive data leaks -->
        android:debuggable="true"  <!-- VULNERABILITY: Enables debugging in production -->
        android:usesCleartextTraffic="true"  <!-- VULNERABILITY: Allows unencrypted communication -->
        android:icon="@mipmap/ic_launcher"
        android:label="@string/app_name"
        android:roundIcon="@mipmap/ic_launcher_round"
        android:theme="@style/AppTheme">

        <!-- Exported Activities -->
        <activity android:name=".MainActivity"
            android:exported="true">
            <intent-filter>
                <action android:name="android.intent.action.MAIN" />
                <category android:name="android.intent.category.LAUNCHER" />
            </intent-filter>
        </activity>

        <!-- VULNERABILITY: Exported sensitive activity -->
        <activity android:name=".SensitiveActivity"
            android:exported="true">
            <intent-filter>
                <action android:name="com.example.SENSITIVE_ACTION" />
            </intent-filter>
        </activity>
        <!-- SOLUTION: Use `android:exported="false"` and restrict with permissions if needed. -->

        <!-- Content Provider Vulnerabilities -->
        <provider
            android:name=".VulnerableProvider"
            android:authorities="com.example.vulnerableapp.provider"
            android:exported="true"
            android:grantUriPermissions="true" />
        <!-- VULNERABILITY: Exposes sensitive app data to unauthorized access. -->
        <!-- SOLUTION: Set `android:exported="false"` and use permissions for accessing the provider. -->

        <!-- Broadcast Receiver Vulnerabilities -->
        <receiver android:name=".GlobalBroadcastReceiver"
            android:exported="true">
            <intent-filter>
                <action android:name="android.intent.action.BOOT_COMPLETED" />
            </intent-filter>
        </receiver>
        <!-- VULNERABILITY: Allows unauthorized apps to send malicious broadcasts -->
        <!-- SOLUTION: Use `android:permission` to restrict access or set `android:exported="false"`. -->

        <!-- VULNERABILITY: Broadcast receiver for sensitive data -->
        <receiver android:name=".SensitiveBroadcastReceiver"
            android:exported="true">
            <intent-filter>
                <action android:name="com.example.SENSITIVE_BROADCAST" />
            </intent-filter>
        </receiver>
        <!-- SOLUTION: Use permissions or limit the exported status. -->

        <!-- Services Vulnerabilities -->
        <service android:name=".BackgroundService"
            android:exported="true" />
        <!-- VULNERABILITY: Allows unauthorized apps to interact with this service -->
        <!-- SOLUTION: Set `android:exported="false"` unless interaction is explicitly required. -->

        <!-- File Provider Vulnerability -->
        <provider
            android:name="androidx.core.content.FileProvider"
            android:authorities="com.example.vulnerableapp.fileprovider"
            android:exported="true"
            android:grantUriPermissions="true">
            <meta-data
                android:name="android.support.FILE_PROVIDER_PATHS"
                android:resource="@xml/file_paths" />
        </provider>
        <!-- VULNERABILITY: Exposes app files to other apps -->
        <!-- SOLUTION: Set `android:exported="false"` and restrict URI permissions. -->

        <!-- Task Hijacking Vulnerability -->
        <activity android:name=".LoginActivity"
            android:launchMode="singleTask"
            android:taskAffinity="com.example.vulnerableapp.external" />
        <!-- VULNERABILITY: External tasks can hijack user navigation -->
        <!-- SOLUTION: Use default `taskAffinity` unless explicitly required. -->

        <!-- Dangerous Permissions -->
        <uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" />
        <!-- VULNERABILITY: Sensitive data can be written to insecure external storage -->
        <!-- SOLUTION: Use `Scoped Storage` API and avoid using `WRITE_EXTERNAL_STORAGE`. -->

        <uses-permission android:name="android.permission.READ_EXTERNAL_STORAGE" />
        <!-- VULNERABILITY: Any app can read insecure external storage -->
        <!-- SOLUTION: Store sensitive data in internal storage or encrypted locations. -->

        <!-- Dangerous Service -->
        <service android:name=".UnprotectedService"
            android:exported="true">
            <intent-filter>
                <action android:name="com.example.UNSAFE_SERVICE_ACTION" />
            </intent-filter>
        </service>
        <!-- VULNERABILITY: Unauthorized apps can interact with this service -->
        <!-- SOLUTION: Use permissions or set `android:exported="false"`. -->

    </application>
</manifest>

Top 20 vulnerabilities in the AndroidManifest.xml file:

1. Outdated minSdkVersion

   • Risk: Allows the app to run on older Android versions with outdated security features.
   • Solution: Use a higher minSdkVersion to enforce better security mechanisms.

2. Not Targeting the Latest targetSdkVersion

   • Risk: Misses modern Android security and privacy improvements.
   • Solution: Always target the latest stable SDK version.

3. Backup Data Exposure (android:allowBackup)

   • Risk: Allows attackers to retrieve app data through backup mechanisms.
   • Solution: Set android:allowBackup="false" unless absolutely necessary.

4. Debuggable Mode Enabled (android:debuggable)

   • Risk: Enables debugging in production, which attackers can exploit.
   • Solution: Ensure android:debuggable="false" for release builds.

5. Cleartext Traffic (android:usesCleartextTraffic)

   • Risk: Allows unencrypted HTTP communication, exposing data.
   • Solution: Set android:usesCleartextTraffic="false" and enforce HTTPS.

6. Exported Activities (android:exported="true")

   • Risk: Makes activities accessible to external apps without proper validation.
   • Solution: Set android:exported="false" unless explicitly required.

7. Exported Services

   • Risk: Unprotected services can be abused by malicious apps.
   • Solution: Set android:exported="false" for sensitive services.

8. Exported Content Providers

   • Risk: Exposes app data to unauthorized access.
   • Solution: Use android:exported="false" and restrict access with permissions.

9. Insecure External Storage Permissions

   • Risk: Sensitive data written to external storage can be accessed by other apps.
   • Solution: Store sensitive data in internal storage or encrypt it.

10. Excessive Permissions

    • Risk: Requesting unnecessary permissions increases the attack surface.
    • Solution: Minimize permissions to only those required for functionality.

11. Global Broadcast Receivers

    • Risk: Allows unauthorized apps to trigger receivers and potentially execute sensitive actions.
    • Solution: Use permissions to restrict broadcast receiver access.

12. Task Hijacking via taskAffinity

    • Risk: Poorly configured taskAffinity allows other tasks to impersonate your app's task.
    • Solution: Use default taskAffinity unless explicitly required.

13. Hardcoded Credentials in Metadata

    • Risk: API keys or secrets stored in the manifest can be extracted by attackers.
    • Solution: Store sensitive data securely (e.g., encrypted or in the backend).

14. Unprotected File Providers

    • Risk: Exposes private app files to unauthorized access.
    • Solution: Limit access to file providers with permissions and proper URI configuration.

15. Dynamic Permissions Misuse

    • Risk: Declaring permissions dynamically without proper checks can lead to privilege escalation.
    • Solution: Validate dynamically granted permissions properly.

16. Excessive Exported Activities

    • Risk: Exposing too many activities to external apps increases attack vectors.
    • Solution: Only export activities meant for external interaction.

17. Implicit Broadcasts

    • Risk: Apps can intercept sensitive implicit broadcasts and misuse them.
    • Solution: Use explicit broadcasts whenever possible.

18. Unencrypted Backups

    • Risk: Sensitive app data in backups can be accessed or tampered with.
    • Solution: Encrypt backup data or disable backups if unnecessary.

19. Insecure Intent Handling

    • Risk: Components receiving unvalidated intents are vulnerable to Intent spoofing attacks.
    • Solution: Validate all data passed through intents.

20. Excessive maxSdkVersion

    • Risk: Restricts compatibility with newer Android versions, breaking functionality and missing security updates.
    • Solution: Avoid using maxSdkVersion unless necessary.

---

Awesome Reference Links

Title	Link	Credit
Hail Frida: The Universal SSL Pinning Bypass for Android	Link	Author: @infosecwriteups
It's All About Android SSL Pinning Bypass and Intercepting Proxy-Unaware Applications	Link	Author: @kishorbalan
My Fav 7 Methods for Bypassing Android Root Detection	Link	Author: @kishorbalan
10 Vulnerable Android Applications for Beginners to Learn Hacking	Link	Author: Anugrah SR
Android App Pentest Workbook	Link	SecurityBoat
Mobile Pentesting AndroGoat Assessment Walkthrough	Link	Author: @infosecwriteups

Vulnerable APK

Name	APK Download Link	Credit
InjuredAndroid	Playstore Link	Creator: @B3nac
	GitHub Link	Walkthrough: YouTube
Android AppSec (Kotlin)	Playstore Link	Creator: @hpandro1337, @_RaviRamesh
	CTF Link	Walkthrough: YouTube Channel
Damn-Vulnerable-Bank	APK Download	Creator: @rewanthtammana, @akshanshjaiswl, @hkh4cks
	GitHub Link	Walkthrough: Website
InsecureShop	APK Download	Creator: Gaurang Bhatnagar
	GitHub Link	Walkthrough: Docs
AndroGoat	APK Download	Creator: @satish_patnayak
	GitHub Link	Walkthrough: Medium
Crackmes	APK Download	Creator: @muellerberndt, OWASP-MSTG
	GitHub Link	Walkthrough: GitHub
Android InsecureBank v2	APK Download	Creator: Dinesh Shetty
	GitHub Link
Oversecured Vulnerable App	GitHub Link	Creator: @oversecured
	Blog Link
DIVA Android	APK Download	Creator: @payatulabs
	Walkthrough
MSTG Hacking Playground	GitHub Link	Creator: Sven Schleier
	Java App
	Kotlin App

---

---

MOBILE PENTESTING CHECKLIST

Information Gathering

Identify the target mobile platform (iOS, Android).

• Determine the OS version and device details.

Gather information about the mobile application.

• Tools: Google Play Store, Apple App Store, Mobile Application Binary
• Command: adb pull <app_path>
• Look for app version, developer information, and permissions.

Identify the app's backend services and APIs.

• Discover endpoints, authentication mechanisms, and data flow.

Discover the app's functionality and features.

• Create a detailed app map with all functionalities.

Enumerate app permissions and security configurations.

• Tools: Mobile Device Settings, Mobile Application Permissions
• Command: Check app settings and permissions
• Identify overly permissive or unnecessary permissions.

Static Analysis

Decompile the mobile app binary.

• Tools: JADX, JADX-GUI (for Android), Hopper Disassembler (for iOS)
• Command: jadx -d <output_dir> <app_apk>
• Analyze the source code for vulnerabilities.
• Examine the manifest file for declared permissions.

Inspect hardcoded credentials and sensitive data.

• Search for API keys, passwords, or encryption keys in the code.

Identify code injection points and potential security flaws.

• Look for SQL injection, command injection, and other injection vulnerabilities.

Review the app's encryption and data storage methods.

• Tools: Apktool (for Android), Class-dump (for iOS)
• Command: apktool d <app_apk> -o <output_dir>
• Verify how data is encrypted, stored, and accessed.

1. Cryptography:

   • Look for use of encryption algorithms and verify implementation correctness.
   • Check for hardcoded keys, weak encryption methods, or use of insecure cryptographic algorithms.

2. Code Obfuscation:

   • Check for obfuscation techniques used to hide code.
   • Verify that obfuscation does not hide malicious code.

3. API Usage:

   • Verify absence of insecure or vulnerable APIs.
   • Look for APIs allowing unauthorized access or data leakage.

4. Hardcoded Sensitive Information:

   • Look for insecure storage of sensitive data.
   • Check for hardcoded database queries, passwords, keys, or URLs.

5. External Libraries:

   • Verify absence of insecure or vulnerable third-party libraries.

6. Integrity Checks:

   • Look for integrity checks to prevent tampering with code.

7. Native Code:

   • If present, verify secure compilation of native code.

8. Web View Related Checks:

   • setJavaScriptEnabled(): Ensure proper validation of input data to prevent injection of malicious JavaScript code.
   • setAllowFileAccess(): Validate input data to prevent unauthorized access/modification of local files.
   • addJavascriptInterface(): Validate input data to prevent execution of arbitrary Java code.
   • runtime.exec(): Prevent injection of malicious input data to avoid execution of arbitrary shell commands.

9. Root Detection Implementation Details:

   • Verify implementation details of root detection mechanisms.

10. SSL Pinning Implementation Details:

• Review implementation details of SSL pinning to ensure secure communication.

Dynamic Analysis

Install and run the app on a mobile device or emulator.

• Tools: Android Emulator (for Android), Xcode Simulator (for iOS)
• Observe app behavior in a controlled environment.

Intercept and manipulate network traffic.

• Tools: Burp Suite, Charles Proxy, Wireshark
• Analyze API calls, data transmission, and encryption.
• Test for insecure data storage and transmission.

Test for authentication and session management vulnerabilities.

• Attempt session fixation, session hijacking, or token manipulation.

Execute runtime analysis for code behavior.

• Tools: Frida, Cycript, LLDB (for iOS)
• Command: Use Frida scripts for dynamic analysis
• Test for code manipulation, function hooking, and runtime attacks.

Authentication and Authorization

Test for weak authentication mechanisms.

• Try common credentials, default passwords, or weak password policies.
• Check for credential stuffing attacks.

Attempt brute force attacks on login screens.

• Tools: Hydra, Burp Suite, OWASP ZAP
• Command: hydra -l <username> -P <password_file> <target>
• Test for account lockouts, CAPTCHA bypass, or rate limiting issues.

Verify session management security.

• Test for session fixation, session timeout, and session ID randomness.
• Check for secure token storage and transmission.

Test for privilege escalation vulnerabilities.

• Check role-based access control (RBAC) and permissions.

Check for insecure direct object references.

• Test for unauthorized data access through object manipulation.

Data Validation and Security

Test for input validation vulnerabilities.

• Try SQL injection, command injection, and XSS attacks.
• Check for input validation on all user inputs.

Verify encryption of sensitive data.

• Check encryption algorithms and key management.
• Test for data leakage through logs or memory.

Look for insecure data transmission.

• Inspect SSL/TLS configurations and certificate validation.
• Test for SSL pinning bypass.

Test for secure file handling.

• Check file I/O operations, file permissions, and storage.

Verify the use of secure coding practices.

• Check for OWASP Mobile Top 10 vulnerabilities.

Runtime Manipulation

Use runtime analysis tools to modify app behavior.

• Inject code, intercept API calls, and manipulate data.

Test for API vulnerabilities.

• Check for API rate limiting, input validation, and authentication.

Attempt to execute malicious code on the device.

• Test for privilege escalation, root/jailbreak detection bypass, and malware installation.

Test for reverse engineering and tampering detection.

• Check for code obfuscation, anti-debugging, and app integrity checks.

Reporting

Document findings, vulnerabilities, and their impact.

• Create a detailed report with evidence and screenshots.