Mobile Applications
ShadowMap continuously monitors the Google Play Store and Apple App Store for applications that mention your brand or related keywords — both legitimate apps your own teams ship and unauthorized or impersonating apps published by others. Every discovered app is pulled, statically analyzed, and surfaced here so you can confirm ownership, hunt for leaked secrets and hardcoded infrastructure in the binary, and request takedowns of fraudulent listings.
Overview
The list view is your triage queue. Each app appears as a row (or card, if you switch views) showing its store icon, title, package/bundle ID, developer, version, and badges for Alerts and Secrets found inside the binary. A metrics strip at the top breaks down total apps, how many are currently Online, the Play Store vs. App Store split, pending takedowns, and apps added in the last seven days.
Across the top are status tabs — All, Online, Genuine, Req Takedown, Completed, Reviewed — each showing a live count. New discoveries land in Online; your job is to move each one to a disposition (Genuine, Reviewed, or a takedown request). Clicking any app opens its full detail view with the static-analysis and extracted-IOC tabs.
Access
This module's data is gated on the asa.mobile-applications:read permission — the backend endpoints that load the list, detail, and counts return 403 without it, so the page renders empty. See Roles & Permissions.
How it works
Most of what makes this module useful happens before you ever see a row, and isn't visible from the UI:
Discovery is keyword-driven, not account-linked. ShadowMap searches both app stores for listings whose title, developer, or description match your brand keywords. It does not require you to connect a developer account — that's deliberate, because the apps you most need to find (impersonators, rogue builds, abandoned third-party apps using your brand) are precisely the ones that aren't in your account. This also means a third-party app that legitimately references your brand will show up here; you triage it to Reviewed rather than expecting it to be absent.
Every app's binary is statically analyzed. After discovery, ShadowMap pulls the APK (Android) or IPA (iOS) and runs a MobSF-style static analysis pass. That single pass is the source of everything in the detail view: security Alerts, hardcoded Secrets and Possible Secrets, certificate / manifest / file / permission findings, and the Extracted IOCs (domains, subdomains, URLs, IPs, trackers, fonts, Firebase URLs). Nothing in this module comes from runtime/dynamic analysis — it is what can be recovered by decompiling and parsing the shipped package.
Status is a disposition, not a workflow stage. The tab an app sits in is driven by a single
is_genuinevalue on the record (0 Reviewed, 1 Genuine, 2 Online, 3 Requested Takedown, 4 Completed). Changing status re-stamps the record immediately; the app drops out of its current tab and the counts update. There is no approval chain — an analyst action takes effect at once.Marking an app changes what's shown elsewhere. Moving an app to Genuine or Reviewed suppresses the leaked credentials found in that app's binary right away (the platform re-stamps secret suppression on the affected app rather than waiting for the next reconcile cycle). In other words, a disposition here is also a signal that quiets downstream noise — confirming an app is yours stops its embedded secrets from being treated as live exposures.
The Relevance score is computed live from your current keywords. It is not a stored field and is intentionally not filterable: because it's recalculated against the active keyword set, a saved filter on it would silently drift every time keywords change. Use it as a sort/triage hint, not as a stable attribute.
App Score is the store rating, not a risk score. The "Score" column and detail field is the app's user rating / store score as published — it describes popularity, not security. Risk lives in the Alerts, Secrets, and static-analysis findings.
Understanding the data
Status tabs
| Tab | Meaning | When to use it |
|---|---|---|
| All | Every tracked app regardless of disposition (the union of all other tabs). | A complete inventory view. |
| Online | Newly discovered apps that mention your brand/keywords and have not been classified yet. | Start your review here — this is the backlog. |
| Genuine | Apps your team has confirmed as legitimately published by your organization. | Confirm ownership; removes the app from the review queue and suppresses its embedded secrets. |
| Req Takedown | Apps for which a takedown request has been submitted. | Track in-flight removals. |
| Completed | Apps successfully removed from the store after a takedown. | Audit trail of resolved impersonations. |
| Reviewed | Apps reviewed and judged to need no further action — e.g. a third-party app that legitimately references your brand. | Close out benign references without claiming them as yours. |
"Online" means "live on the store," not "safe"
An app in the Online tab is one that is currently published and matches your brand — it is an un-triaged finding, which is why takedown requests are only offered from this state. The metrics strip flags a non-zero Online count in red for the same reason.
List columns
The table is column-customizable (toggle columns via the customizer in the page header). Available columns:
| Column | Description |
|---|---|
| Application | App icon, title, and package/bundle ID. Any matched organizations appear as tags beneath the title. Click the title to open the detail drawer. |
| Store | Play Store or App Store, shown as a colored badge. |
| Version | Current version string from the store listing. |
| Developer | Publisher / developer name as listed on the store. |
| Genre | App category from the store. |
| Alerts | Count of security alerts raised by static analysis of the binary (red badge when > 0). |
| Secrets | Count of confirmed leaked credentials / API keys found in the binary (amber badge when > 0). |
| Score | The app's store rating / score (popularity, not risk). |
| Relevance | Live keyword-relevance hint (computed per request — see How it works). |
| Tags | Custom tags applied to the app. |
| Updated | When the store listing was last updated, shown as relative time. |
Rows can be bookmarked (star icon) for a personal shortlist; the Bookmarked toggle in the filter bar then narrows the list to your starred apps.
Filtering & search
The filter bar combines several controls:
- Store pills — All Stores / Play Store / App Store. A quick segmented filter; counts in the status tabs update to reflect the active store.
- Field filters (FQP) — build structured rules over Store, Title, App ID, Developer, Status, Genre, Bookmarked, Date Added, and Last Updated. Rules combine with AND/OR. Note that Relevance is intentionally not a filterable field because it is recomputed per request.
- Bookmarked — show only apps you've starred.
- Sort — by Last Updated (default), Title, Store, Developer, or Date Added, ascending or descending. In table view you can also click sortable column headers; the dropdown in the page header is the equivalent path for card view (and for Date Added, which has no column header).
The metrics strip is also clickable: the Online and Pending Takedowns cards jump you to those tabs, and the store-distribution segments filter by store.
Detail view
Clicking an app opens its detail page. The header shows the icon, title, store badge, version, store score, developer, size, and last-updated time. Below that are four tabs:
Overview
Security-posture cards (Alerts, Secrets, Possible Secrets, Domains) plus a metadata grid: App ID, store, version, developer, genre, rating, download count, size, score, created/last-updated dates, and a link to the live store listing. The store description and any matched organizations are shown beneath.
Security Analysis
The findings recovered from the binary, split into sub-tabs (each with a count):
| Sub-tab | What it shows |
|---|---|
| Alerts | Security alerts, each with a risk rating, CVSS where available, and the paths/files where it was found. |
| Secrets | Confirmed leaked credentials and API keys, with the secret type, value, file, line number, version, and discovery date. |
| Possible Secrets | High-entropy or pattern-matched strings that look like secrets but need manual verification. |
| Certificate | The app's signing certificate — issuer, validity, and fingerprints. |
| Manifest | Parsed Android manifest / iOS equivalent — declared permissions, exported components, intent filters, and risky configuration. |
| File Analysis | Findings from files bundled inside the package — config files, embedded databases, hardcoded URLs, and sensitive data left in the binary. |
| Permissions | All requested permissions, surfacing those that are unusual for the app's stated category. |
Extracted IOCs
Indicators pulled out of the binary during analysis — useful both for attack-surface mapping and for spotting exfiltration or third-party data flows:
| Sub-tab | What it reveals |
|---|---|
| Domains | Domains referenced in code/config. Each is tagged Belongs (an asset you own) or Not Belongs (external), with a filter to view either subset and a cross-link into Domains. |
| Subdomains | Subdomains found in the app — may expose internal infrastructure. Cross-links into Subdomains. |
| URLs | Full hardcoded URLs: API endpoints, webhooks, third-party services. |
| IPs | IP addresses referenced in the app, with a cross-link into IP Addresses. |
| Trackers | Third-party analytics / tracking SDKs embedded in the app (e.g. Firebase Analytics, Mixpanel, Adjust), with category. |
| Fonts | Font assets bundled in the package. |
| Firebase URLs | Firebase database URLs found in the app, flagged for accessibility — open Firebase instances are a common data-leak source. |
Triaging extracted domains
The Belongs / Not Belongs split is the fast path: confirm that "Belongs" domains are genuinely yours, and scrutinize "Not Belongs" entries — an unexpected external domain or IP hardcoded in your own app can indicate a compromised dependency, an unsanctioned data flow, or a misattributed third-party app.
Activity
The comment and notes thread for the app — investigation notes and analyst commentary, using the shared comment component (the same comments surface as the row's comment icon). Comment templates are available to speed up routine notes.
Taking action
Actions are available from the row's "more" menu, the detail drawer, and the bulk action bar:
| Action | Effect |
|---|---|
| Mark Genuine | Confirm the app is legitimately yours. Moves it to the Genuine tab and suppresses its embedded secrets. |
| Mark Online | Return an app to the Online tab for re-review. |
| Mark Reviewed | Mark as reviewed / no action needed (e.g. a benign third-party reference). |
| Request Takedown | Open a takedown request for a fraudulent or unauthorized app. Available only from the Online state. Moves the app to Req Takedown and tracks the lifecycle to Completed. |
| Visit Store | Open the live store listing in a new tab. |
| Add Tags | Apply custom tags for your own categorization. |
| Share | Push the selection to a connected integration. |
| Export | Download the current (filtered) list, or a single app's full detail, as Excel. |
| Comment | Add investigation notes to the app record. |
Bulk operations: select multiple rows (or Select All across the current tab) to change status, request takedowns, add tags, share, or export in one operation. Status changes apply optimistically — affected rows leave the tab immediately, and roll back if the server rejects the change.
Takedowns are requests, not guarantees
"Request Takedown" submits a removal request that ShadowMap tracks through its lifecycle; actual removal depends on the app store's review. Use the Req Takedown and Completed tabs to follow status. See Takedowns.
Common questions
How are apps discovered if I never connected a developer account? Discovery is keyword-based search across the Play Store and App Store, not account integration. That's intentional — it surfaces impersonators and third-party apps that wouldn't appear in your own account. Legitimate third-party references show up too; triage those to Reviewed.
What's the difference between "Secrets" and "Possible Secrets"? Secrets are confirmed leaked credentials / API keys extracted from the binary. Possible Secrets are strings that match secret-like patterns or have high entropy but need a human to verify — treat them as a manual-review queue, not confirmed exposures.
Is the "Score" column a security risk score? No. It's the app's published store rating/score (popularity). Security risk is expressed through Alerts, Secrets, and the static-analysis findings, not the score.
Why can't I filter by Relevance? Relevance is recomputed on every request against your current brand keywords, so it isn't a stored field. A saved filter on it would silently change meaning each time keywords are updated, so it's deliberately excluded from the filter set.
What happens when I mark an app Genuine or Reviewed? It moves to that tab and drops out of your review queue, and the leaked secrets found in that app's binary are suppressed immediately — confirming the app is yours stops its embedded credentials from being counted as live exposures.
Does ShadowMap run the app (dynamic analysis)? No. All findings come from static analysis of the shipped APK/IPA — decompiling and parsing the package. There is no runtime instrumentation.
An app is on the store but not in my list — why? Discovery depends on the listing matching your brand keywords. If a relevant app is missing, the keyword set may not cover it; review your brand keywords with your account team.
Related
- Fake Applications — brand-impersonation apps flagged under Brand Monitoring; complementary to the ownership/secret triage done here.
- Web Applications — web services discovered across your domains, the web-side counterpart to this module.
- Leaked Credentials — where credentials exposed across sources (including those found in app binaries) are tracked.
- Domains, Subdomains, and IP Addresses — the asset inventories that extracted IOCs cross-link into.
- Takedowns — how takedown requests are submitted and tracked across modules.
- Attack Surface Area Overview — how ShadowMap discovers and organizes your external assets.