Your subdomain enumeration found 43 hosts. The target's Android APK contained the AWS access key for the production S3 bucket, a staging endpoint absent from every DNS record, and the Firebase project ID for the entire user database. The APK was publicly available the entire time.
Mobile app binaries are the richest and most underused source of API intelligence in external recon. They embed compile-time secrets, staging endpoints, and cloud project IDs that are architecturally invisible to web-facing scanners. Any APK is freely downloadable from the Play Store by anyone with a Google account, with no authentication and no trace.
Web Scanners Are Architecturally Blind to Compile-Time Intelligence
Attack Surface Management tools operate on what the network serves at runtime. Mobile binaries contain what was embedded at compile time, a completely separate layer that no HTTP scanner reaches by design, regardless of how exhaustive the DNS enumeration is.
Files like strings.xml, google-services.json, and .dex bytecode travel inside every APK, available on the Play Store without authentication. CWE-798 (Use of Hard-coded Credentials) is straightforward: extracting a password from a binary is generally very simple. Most ASM platforms simply do not ingest APKs. This is not a configuration limitation; it is an architectural gap.
Zimperium data (September 2025): 50% of mobile apps contain hardcoded API secrets. 24% of Android apps and 60% of iOS apps have no reverse-engineering protection whatsoever. One third of Android apps and more than half of iOS apps leak sensitive data to third parties. Exhaustive DNS enumeration captures none of these vectors. They are two separate intelligence surfaces living in entirely distinct technical layers.
The Extraction Workflow: APK to API Intelligence in Under 30 Minutes
A structured workflow of decompile then grep extracts actionable API intelligence from any APK without executing code, without creating accounts, and without touching the target's infrastructure.
APK acquisition: APKPure, APKMirror, and gplaydl provide APKs without a Google account. Apps published after 2021 use the AAB (Android App Bundle) format natively; mirror sites convert to APK automatically, with a possible 24-48 hour lag for recent releases. For apps installed on an enrolled device, adb backup is a functional alternative. Historically signed APKs from previous versions remain available on APKMirror even after updates, enabling regression analysis across versions.
apktool d target.apk && jadx -d output/ target.apk
apktool decodes the APK to smali and res/values/strings.xml, essential for builds where obfuscation makes jadx output incomplete. jadx decompiles .dex bytecode to readable Java. In jadx-gui, Ctrl+Shift+F searches all decompiled code simultaneously, crossing resources, classes, and libraries in a single pass.
grep -r "api_key\|Authorization\|staging\|secret" output/ --include="*.java" -l
High-yield search terms: api_key, api_secret, Authorization, Bearer, password, secret, staging, internal, AWS_ACCESS_KEY, firebaseio.com, .amazonaws.com. Every returned file is a candidate for manual investigation.
MobSF (Mobile Security Framework) accepts APKs via REST API and produces a secrets report, permissions audit, and hardcoded URL inventory within minutes. It integrates directly into recon pipelines alongside subdomain enumeration and port scanning. For iOS targets, the process is analogous: unpack the IPA, run strings on the binary, and use Frida Objection for SSL pinning bypass during the dynamic phase.
The 4 High-Value Targets in Every Well-Funded App
4 artifact types produce critical findings regardless of the target's sophistication: cloud credentials in string resources, GCP project IDs in google-services.json, staging endpoints absent from DNS, and deep link handlers with insufficient authentication.
Hardcoded API keys: Pic Stitch (5 million users) contained a hardcoded AWS access key and secret key in the binary, with access to the production S3 bucket (Symantec, October 2024). NordVPN Android contained Google and Stripe keys in res/values/strings.xml (HackerOne #792850). Reddit Android exposed the Twitter API secret and key in Resources.arsc/res/values/strings.xml (HackerOne #1241116). All 3 cases involve the same file and the same extraction pattern: grep, credential, pivot.
google-services.json: Embeds firebase_url and project_id in every APK connected to Firebase. This file is generated automatically by the Firebase console and is rarely removed from the repository or the production build. The direct pivot to https://PROJECT_ID.firebaseio.com/.json without credentials is operational when security rules allow unauthenticated reads.
Deep links: KAYAK Android (HackerOne #1667998, 2022) allowed one-click account takeover via a deep link in com.kayak.android. The handler did not validate authentication state before executing the privileged action. No network scanner detects deep link handlers: they appear only in static analysis of the Android manifest (AndroidManifest.xml).
Firebase: The Misconfiguration That Scales to 100 Million Records
Every APK connected to Firebase embeds a publicly readable project identifier in google-services.json. When developers ship with security rules in test mode, the Firebase default during development that is frequently not updated before the production launch, a passive recon artifact becomes an unauthenticated data dump at scale.
curl -s "https://PROJECT_ID.firebaseio.com/.json" | head -c 500
Comparitech documented 24,000 Android apps exposing user data via Firebase misconfiguration. 31% of Firebase apps have exploitable security rules. The HospitalGown report (Appthority, 2018) found 9% of Android apps connected to Firebase leaking data: 113 GB across 2,300 servers, with more than 100 million records exposed without authentication.
In 2024, 916 Firebase sites exposed 125 million user records. The data included billing information and plaintext passwords. Extraction requires 1 HTTP request with no credentials when rules allow public reads. The project identifier is in the APK, available on the Play Store, without an account.
Why the Low-Severity Label on a Mobile Credential Finding Is Usually Wrong
Classifying credentials in APKs as low severity is precisely why the technique remains underused: teams prioritize what they perceive as critical, and compile-time credentials rarely reach the top of the queue. Security teams label mobile credential findings as informational or low severity because they evaluate the key in isolation. The real severity is the cloud privilege chain the key unlocks, which frequently reaches production infrastructure.
CloudSEK (2025): 32 hardcoded Google API keys in 22 Android apps with more than 500 million combined installs silently gained access to Gemini AI when Google expanded the keys' scope. Zero attacker action was required. The key extracted from ELSA Speak (10 million installs) provided read access to user audio files stored in GCP Storage.
The financial impact is documented: unauthorized API key use cost one solo developer $1,400 in hours. A Mexican team was charged $82,314 in 48 hours, 455 times the normal monthly spend, for access to Gemini file storage. OWASP Mobile Top 10 2024 M1 (Improper Credential Usage) is ranked #1 because severity is determined by what the credential grants access to, not by its format.
Scaling Mobile API Recon: From Manual to Automated Surface Discovery
Manual APK analysis does not scale to an entire target organization's published app portfolio. Automated tools and specialized platforms expose the same findings across all app versions without touching the target's infrastructure.
The MobSF REST API accepts APKs and IPAs programmatically, integrating directly into recon pipelines alongside subdomain and port scanning. BeVigil (CloudSEK) continuously indexes APKs from the Play Store and alerts on newly hardcoded secrets. It was the mechanism that identified 32 keys across 22 apps at scale, without manual per-file analysis.
CloudSEK research (2025) with LLM-assisted detection identified more than 4,800 secrets in Android apps versus far fewer with regex-based approaches. 42% of apps contained at least 1 secret in the LLM analysis. Classic regex has a high false-negative rate for secrets with unconventional names or partial obfuscation.
Version diffing between APK releases reveals endpoints removed from the UI but still active in the backend. The pattern is consistent: the product team removes a button in version 2.3, but the endpoint keeps responding in every subsequent version. This is the most common mechanism for forgotten staging routes and shadow APIs active in production.
Automated mobile API surface tools apply the same extraction patterns at scale, crossing APK versions to map endpoints that never appear in web scanners.
The next time a target has a mobile app, download the APK before opening a port scanner. Compile-time secrets do not rotate. They have been public since the first Play Store review passed.
Disclosure: the author is a co-founder of intel.mago.team, which implements the techniques described in this article.
Top comments (0)