Module 2 — Reconnaissance & Information Gathering

Por

This module takes you from basic reconnaissance to advanced information-gathering techniques specifically for iOS apps and their backends. The goal: build a complete, prioritized map of the attack surface so later static/dynamic analysis and tests are targeted and efficient.

Learning objectives

By the end of this module you will be able to:

  • Gather high-value intelligence from the App Store / TestFlight / enterprise builds and extract actionable metadata.
  • Enumerate app-specific endpoints, hostnames, and related infrastructure.
  • Identify runtime and build-time artifacts (URL schemes, universal links, entitlements, backend environments).
  • Conduct certificate and TLS footprinting to find overlapping infrastructure and issuer patterns.
  • Build an evidence-backed attack surface map and prioritized test plan.

Prerequisites

  • Familiarity with Module 1 content (IPA/.app structure, Info.plist, Mach-O basics).
  • macOS or Linux workstation with basic networking tools installed.
  • A copy of the IPA or access to the app listing for which you have written authorization.
  • Isolated lab network and explicit written authorization (you have this). Always respect RoE.

Recommended tools (quick reference)

Groupings and rationale — pick what fits your workflow.

App / Binary inspection

  • unzip, plutil, security (provisioning decode), strings, otool, lipo, class-dump, class-dump-swift, swift-demangle, nm, radare2, hopper, ghidra, binaryninja

Network & infrastructure recon

  • curl, jq, dig, host, nslookup, whois, openssl s_client, nmap, masscan (use responsibly), subfinder, amass, assetfinder (passive DNS enumeration)

Certificate & TLS analysis

  • openssl, sslyze, tls-scan, certtool and web services (crt.sh) — use API/web only if allowed

Proxying & dynamic inspection (authorized testing)

  • mitmproxy, burp, charles (for capturing legitimate traffic; remember pinning caveats)

Automation & OSINT

  • jq, python scripts, go/bash recon scripts — use responsibly and avoid aggressive scanning outside scope

Documentation & reporting

  • markdown, notion/obvious-docs, spreadsheets, screenshots, pcap capture with tcpdump/wireshark

High-level recon process (phases)

  1. Passive application recon — public information, store metadata, release notes.
  2. Artifact extraction — get the IPA (or .app) and inspect Info.plist, provisioning, resources.
  3. Static endpoint discovery — strings, config files, class dumps, frameworks.
  4. Infrastructure footprinting — DNS, TLS/certificate, subdomain & IP discovery (passive first).
  5. Service & host enumeration — HTTP headers, versions, non-intrusive port discovery (within RoE).
  6. Build attack surface map — consolidate findings, identify trust boundaries & sensitive assets.
  7. Prioritize tests — rank targets by impact, exploitability, and business context.

2.1 Passive recon from public sources

Purpose: gather non-intrusive intelligence that narrows the scope and informs later testing.

Sources to check

  • App Store listing (description, privacy policy URL, support URL, release notes, links to developer website).
  • TestFlight public links & beta notes (if available).
  • Developer/company website, careers pages (may leak stack/technologies).
  • Public code repos (GitHub/Bitbucket) — sometimes developers accidentally push keys or sample code.
  • Certificate Transparency logs (crt.sh) for certs covering app domains.
  • WHOIS records for domains (team/company contact info).
  • Public bug trackers, CVE feeds, and frameworks’ vulnerability pages.

What to capture

  • Official domain names, subdomains in descriptions/support/support email domains.
  • Any mention of third-party services (Firebase, Auth0, Sentry, etc.).
  • Links to API docs or developer portals.

Practical tips

  • Save full HTML pages and screenshots.
  • Note version numbers in release notes — helps match known CVEs for older versions.

2.2 Legal & ethical note about App/Store scraping

  • Only extract public data or binary data you are explicitly authorized to fetch.
  • Do not attempt credential stuffing against store/admin portals or abuse APIs.

2.3 Binary / bundle artifact extraction (quick recap + advanced)

If you already extracted the IPA in Module 1, continue from there. If not, extract and catalog everything.

Advanced artifact catalog

  • Info.plist (config, URL schemes, ATS exceptions)
  • embedded.mobileprovision (entitlements, team IDs)
  • Frameworks/ — third-party frameworks (.framework bundles)
  • PlugIns/ — app extensions (Today extensions, Share extensions)
  • Resources/ — JSON/JS config files, .car assets, .plist resources
  • Watch/ — watch extensions (may expose different endpoints)
  • dSYMs (if present) — may contain symbol info useful for debugging (rarely included in release IPAs)

Search patterns (examples)

# find files of interest
find Payload/YourApp.app -type f -iname "*.plist" -o -iname "*.json" -o -iname "*.sqlite" -o -iname "*.db"

# search for likely strings
strings Payload/YourApp.app/YourApp | egrep -i 'https?://|api|baseUrl|client_id|client_secret|token|auth|firebase|sentry|amplitude|mixpanel' | sort -u

Look in frameworks

  • Frameworks often include unstripped symbols, debug config, or script constants.
  • strings or nm on frameworks may reveal networking stacks (AFNetworking, Alamofire) or specific SDK usage.

2.4 Static endpoint & API discovery (systematic)

Goal: find all hostnames, endpoints and API versions referenced in the app bundle or binary.

Methodology (progressive, low-impact)

  1. String harvesting from binary and resource files
    • strings + greps for http, https, api, server, base, endpoint
  2. Plist/config scanning — many apps store environment switches or base URLs in plists or JSON
  3. Framework inspection — frameworks and plugins may contain endpoints used by background workers or SDKs
  4. Header/footer patterns — inspect webview content (if app contains web assets)
  5. Class/method names — class-dump may reveal methods like loginWithUsername:password: or refreshToken indicating endpoint semantics

Example commands

# strings + filter
strings Payload/YourApp.app/YourApp | egrep -i 'https?://|/api/|/v[0-9]+/|login|auth|token' | sort -u

# search resource files for JSON configs
grep -R --text -i 'baseUrl\|api_url\|environment\|endpoint' Payload/YourApp.app | sed -n '1,200p'

Pitfalls & notes

  • Some apps build URLs at runtime (concatenate host + path). Look for hostnames separately from endpoints.
  • Strings might be obfuscated or encrypted; note suspicious decoding functions for later dynamic analysis.

2.5 Infrastructure footprinting (DNS, certificates, provider mapping)

Goal: discover all related infrastructure without active intrusive scanning (passive first).

DNS & passive discovery

  • Collect hostnames found in the bundle and app store.
  • Use passive enumeration tools/services (crt.sh, passive DNS feeds, Subdomain enumeration tools) to discover related subdomains and certificates.

Certificate and TLS analysis

  • Certificates reveal SANs (Subject Alternative Names) and often list multiple related domains (e.g., api.example.com, *.example.com, dev.example.net).
  • Check issuer details and certificate transparency logs to find sibling hostnames.

Useful commands (host-level)

# basic DNS resolution
dig +short api.example.com
dig +short CNAME api.example.com

# certificate peek with openssl (passive, non-intrusive)
openssl s_client -connect api.example.com:443 -showcerts </dev/null 2>/dev/null | openssl x509 -noout -text | sed -n '1,200p'

What to look for in certs

  • SAN entries matching unexpected domains (3rd-party or testing domains)
  • Overlapping certs across environments (dev/prod using same cert issuer)
  • Short/long validity windows (possible automated provisioning, e.g., Let’s Encrypt)

Provider / third-party service mapping

  • Look for SDK names (Firebase, AWS Cognito, Auth0, Sentry, NewRelic, Crashlytics) — many leak configuration or default endpoints.
  • Check for well-known hostnames used by such services (e.g., firebaseio.com, auth0.com, amazonaws.com).

2.6 Active, low-impact checks against discovered hosts (within RoE)

Only perform these if you are authorized. These are non-destructive checks to validate service presence and basic configuration.

Allowed actions (examples)

  • curl -I or curl -v to fetch HTTP headers (no fuzzing, no brute force).
  • nmap light TCP service probe (-sV -p 443,80 --open) — ensure allowed.
  • TLS handshake/HTTP response fingerprinting.

Example safe checks

# view server headers
curl -I https://api.example.com/

# fetch a public endpoint safely (e.g., health check)
curl -sS https://api.example.com/health | jq .

# TLS info
openssl s_client -connect api.example.com:443 -servername api.example.com </dev/null 2>/dev/null | openssl x509 -text -noout

Do NOT

  • Attempt credential stuffing, brute force, or heavy scanning unless explicitly allowed.
  • Flood the service or perform DoS-like behavior.

2.7 Identifying backend API semantics & authorization boundaries

From endpoint names, headers, and parameter patterns you can infer:

  • Authentication flows (/auth, /oauth/token, /login, /verify)
  • Resource identifiers (/users/{id}, /accounts/{account_id})
  • Versioning patterns (/v1/, /api/v2/)
  • Public vs protected endpoints (presence of WWW-Authenticate or 401 responses)

Look for header patterns

  • Authorization: Bearer <token> — indicates bearer token lifecycle
  • Set-Cookie — session cookies (less common in native apps but possible)
  • x-api-key, x-client-id — custom auth headers

Collecting sample request/response shapes

  • If you can run the app in a simulator with a proxy (mitmproxy/burp) and the app accepts your proxy cert, capture sample requests to see exact JSON shapes and headers. Document examples for each endpoint.

2.8 URL schemes, universal links & inter-app communication

Why it matters

  • Custom URL schemes and universal links expose ways the app interacts with other apps and web content; they can be sources of deep link attacks or unintended authority escalation.

Where to find

  • CFBundleURLTypes and Associated Domains in Info.plist or in entitlements (com.apple.developer.associated-domains).

Example Info.plist entries

<key>CFBundleURLTypes</key>
<array>
  <dict>
    <key>CFBundleURLSchemes</key>
    <array>
      <string>myapp</string>
    </array>
  </dict>
</array>

Testing considerations

  • Enumerate scheme handlers and test how the app validates incoming data (do not send malicious payloads outside lab).
  • For universal links, inspect the domain’s /.well-known/apple-app-site-association file (read-only HTTP GET) for configured paths.

2.9 Mapping trust boundaries & assets

Create a visual map (or a table) showing:

  • Client-side assets (app, extensions, local DBs, Keychain groups)
  • Network trust boundary (mobile client ↔ api.example.com)
  • Server-side assets (APIs, auth servers, file storage)
  • Third-party services and their role (analytics, crash reporting, auth provider)
  • Sensitive data flows (credentials → token exchange → protected resources)

Prioritization criteria

  • Impact — what sensitive data accessible if compromised? (PII, financial)
  • Exploitability — ease to reach/trigger the vulnerability (public API vs private local file)
  • Business context — which assets are high-value for the organization

2.10 Threat modeling example (simple template)

For each high-level asset produce a table:

AssetTrust BoundarySensitive DataEntry PointsImpact if CompromisedPriority
User session tokenMobile ↔ APIaccess token, refresh tokenLogin endpoint, token refreshAccount takeover, data exfiltrationHigh
Keychain itemsLocal devicestored secretsShared keychain access group misconfigLateral data accessMedium
Crash reports (Sentry)Mobile → Sentrystack traces, user IDsSDK endpointsInfo leak, user data exposureLow

2.11 Automation & scripting for recon (safe patterns)

  • Use scripts to aggregate strings, plists, domains into a CSV for tracking.
  • Example minimal pipeline (conceptual):
    1. Extract IPA
    2. Run strings and grep for urls → urls.txt
    3. For each hostname in urls.txt, run dig, whois and openssl to collect certificates → JSON
    4. Feed JSON into spreadsheet to prioritize

Avoid automated brute force or port scanning without explicit permission. Keep recon centralized and auditable (timestamps, commands used, outputs saved).

2.12 Deliverables & evidence for Module 2

Produce a Recon Report package including:

  • recon.yaml or spreadsheet with all discovered hostnames, IPs, and endpoints.
  • Screenshots and saved outputs of:
    • Info.plist findings (URL schemes, ATS exceptions)
    • embedded.mobileprovision decode (entitlements)
    • strings output with endpoints and SDK identifiers
    • Certificate details (subject, SANs) obtained via openssl or equivalent
    • Proxy capture pcap(s) if you captured traffic in an authorized environment
  • Attack surface map (diagram or table)
  • Prioritized test plan: list top 10 targets with justification

2.13 Labs — step-by-step exercises (authorized lab)

All labs assume you have explicit permission and are running inside an isolated lab.

Lab A — Passive App Store Recon

  1. Open the App Store listing and save the HTML (File → Save Page As) or use curl to fetch the public page.
  2. Capture: developer name, support URL, privacy policy, screenshots, version history.
  3. Note any URLs shown (support URL, developer website) and save them.

Deliverable: PDF of saved App Store page + brief notes.

Lab B — Artifact harvest and endpoint extraction

  1. Extract IPA: unzip AppName.ipa -d App_extracted cd App_extracted/Payload/YourApp.app
  2. Harvest strings: mkdir ../recon && strings YourApp | egrep -i 'https?://|api|token|auth|client_id|client_secret' | sort -u > ../recon/strings_endpoints.txt
  3. Inspect Info.plist: plutil -p Info.plist > ../recon/info_plist.txt
  4. Decode provisioning profile: security cms -D -i embedded.mobileprovision > ../recon/provision.plist plutil -p ../recon/provision.plist > ../recon/provision_readable.txt
  5. Produce recon/hosts.txt with unique hostnames from strings_endpoints.txt.

Deliverable: recon/ folder with strings_endpoints.txt, info_plist.txt, provision_readable.txt, hosts.txt.

Lab C — Passive TLS & DNS footprinting

For each hostname in recon/hosts.txt:

  1. DNS resolution: dig +short api.example.com >> recon/dns_results.txt
  2. TLS certificate summary: openssl s_client -connect api.example.com:443 -servername api.example.com </dev/null 2>/dev/null | openssl x509 -noout -text | sed -n '1,120p' >> recon/certs_summary.txt
  3. WHOIS: whois example.com >> recon/whois_example.com.txt

Deliverable: recon/dns_results.txt, recon/certs_summary.txt, recon/whois_*.txt.

Lab D — Lightweight service validation (authorized & within scope)

For top-priority hosts, run non-intrusive checks:

curl -I https://api.example.com/
curl -sS https://api.example.com/swagger.json | jq .   # if swagger exists and is public

Document HTTP headers and any public API docs found.

Deliverable: recon/host_checks/ with .http files containing header responses.

2.14 Common pitfalls & how to avoid them

  • Assuming endpoints found in strings are current. They may be legacy or test endpoints — validate with safe HTTP checks.
  • Confusing third-party SDK hostnames with app-owned hosts. Map provider hosts separately.
  • Aggressive enumeration without permission. Passive recon first; ask for permission for active scans.
  • Missing dynamically generated hosts. Some apps compute hostnames at runtime; note decoding/concat functions for later dynamic analysis.

2.15 Developer recommendations (what to tell devs)

  • Do not ship staging/dev endpoints in production builds. If unavoidable, gate them behind developer flags that are stripped in production.
  • Minimize hardcoded secrets (client secrets, API keys) in the bundle — use ephemeral tokens from secure backend.
  • Use distinct certificates and infrastructure for dev/test vs prod to avoid accidental leakage.
  • Document universal links and URL schemes and validate inbound parameters.

2.16 Checklist (quick one-page)

  • Save App Store / TestFlight metadata and screenshots.
  • Extract IPA and catalog resources & frameworks.
  • Pull Info.plist and embedded.mobileprovision, save output.
  • Harvest strings for hostnames and endpoints.
  • Enumerate third-party SDKs and map provider hosts.
  • Passive DNS & cert enumeration for discovered hosts.
  • Produce attack surface map & prioritize targets.
  • Prepare evidence package and prioritized test plan.

Next steps (how Module 2 feeds into later modules)

  • Use the prioritized host & endpoint list to craft static analysis targets in Module 3 and dynamic tests in Module 4 (proxying, runtime checks).
  • Use certificate and domain findings to inform MitM / pinning tests (Module 7) and backend authorization tests (Module 15).
  • Document any anomalies (e.g., public swagger docs, dev endpoints) as high priority for follow-up.