Build an architecture map for shadow APIs and orphaned services by reconciling what is externally reachable, internally routed, deployed and owned. DNS, certificates, gateways, versions, ingress rules, cloud inventories, client code and telemetry each reveal a different part of the surface. The penetration test should validate the resulting map and prioritize unknown assets without scanning unrelated infrastructure.
Define the architecture question before testing
Define “shadow” as deployed outside the approved inventory and “orphaned” as reachable without accountable ownership or lifecycle. Map external and authorized internal perspectives separately. One hostname may hide many routed services, while one service may be reachable through several hosts, gateways or versions.
Write the expected security invariant and the prohibited outcome in language that engineering, security and operations interpret the same way. Name the identity, trust transition, protected asset and authoritative state. That statement becomes the basis for scope, evidence and retesting.
Build the minimum evidence pack
- A current component and trust-boundary diagram for the environment under test.
- Identity, credential, network and data-flow details relevant to the decision.
- Representative accounts, workloads and synthetic records with known ownership.
- Logs or traces that follow the action through every material control point.
- Explicit safety limits, stop conditions, owners and restoration steps.
Collect approved domains and address ranges, DNS zones, certificate logs, gateway exports, ingress and load-balancer inventories, API catalogs, cloud tags, service registries, mobile and web client endpoints, deployment records and recent access logs. Preserve source and timestamp for each observation.
Reconcile DNS, certificates and edge routes
DNS and certificates reveal historic and alternate names, while edge configuration shows which names still route traffic.
- Enumerate approved zones and certificate names.
- Resolve aliases and identify stale records.
- Compare gateway hosts, paths and upstream targets.
- Check regional, partner and legacy domains.
- Verify retired names no longer reach active services.
Record hostname, resolution, certificate, HTTP behaviour and owner. Do not probe domains outside the approved organization scope.
Compare deployment inventory with the API catalog
Services can remain deployed after documentation or ownership disappears. Conversely, catalog entries can describe assets that are no longer real.
- Match workloads and functions to catalog entries.
- Identify untagged or ambiguously named services.
- Compare deployed versions with supported versions.
- Trace load balancer and ingress targets to workloads.
- Check test and migration stacks exposed from production networks.
Classify discrepancies as reachable shadow, internal shadow, orphan, stale catalog or explained exception. Uncertainty should remain visible.
Mine clients and telemetry for observed endpoints
Web bundles, mobile apps, SDKs and access logs show endpoints used in practice, including paths missed by architecture diagrams.
- Extract hosts and base paths from approved client artifacts.
- Review gateway and load-balancer logs for unmatched routes.
- Identify low-volume but still active versions.
- Compare error telemetry and traces with the inventory.
- Check scheduled jobs and webhooks for service destinations.
Treat strings as leads until reachability is confirmed. Protect tokens, customer data and sensitive query values during analysis.
Validate identity and control parity
Unknown assets matter because they may use old authentication, weaker authorization, missing rate limits or absent monitoring.
- Compare issuer, audience and token validation with current APIs.
- Test representative object authorization using controlled accounts.
- Check CORS, headers, methods and debug exposure.
- Compare gateway, WAF and rate-limit coverage.
- Verify logs reach the supported monitoring pipeline.
Use minimum-impact requests and canary identities. Tie each control gap to the route and upstream service actually responsible.
Resolve ownership and lifecycle
A technically secure service can still be dangerous when nobody owns patching, incidents, data retention or retirement.
- Identify code repository, deployer and operational team.
- Confirm business purpose and data classification.
- Check last deployment and last legitimate use.
- Verify dependency and secret rotation responsibility.
- Find an approved shutdown or exception decision.
Do not assign ownership by guess. Record evidence and escalation owner until a team accepts accountability.
Test retirement rather than hiding
Removing documentation or DNS does not retire a service if gateways, direct addresses, jobs or clients still reach it.
- Verify routes and upstream targets are disabled.
- Confirm credentials and signing keys are revoked.
- Check client versions no longer call the service.
- Remove or archive data under retention policy.
- Monitor for attempted use after shutdown.
Closure requires both unreachable service and observed absence of required traffic. Preserve rollback criteria for business-critical surprises.
Execute as controlled hypotheses
- Establish the legitimate baseline and capture authoritative state.
- Change one trust variable—identity, route, scope, object, time or environment.
- Observe the decision at each layer rather than relying only on the response.
- Stop at the minimum proof that demonstrates or rejects the hypothesis.
- Restore test state and record residual uncertainty or blocked coverage.
Begin with passive and configuration evidence, then validate only organization-owned, authorized targets. Use conservative discovery rates, exclude third-party shared infrastructure and coordinate with operations. Unknown ownership is not permission for aggressive testing.
Report the architectural consequence
Deliver a deduplicated service graph, not a flat URL dump. Show hosts, paths, versions, upstream workloads, owners, identity controls, data sensitivity and observed traffic. Rank remediation by exposure, privilege, data and ownership uncertainty.
Separate observed evidence from inference. State prerequisites, repeatability, blast radius and the shared component responsible for the decision. When multiple findings have one architectural cause, keep the individual proofs but group the remediation around the common control.
Required closure evidence
- The original proof no longer succeeds.
- A legitimate workflow still succeeds under the intended identity and route.
- Alternate consumers of the same pattern enforce the same invariant.
- Telemetry records both allowed and denied decisions with useful context.
- The architecture record and threat assumptions reflect the new control.
Remediate at the durable control point
Establish authoritative service registration at deployment, require ownership and lifecycle metadata, continuously reconcile DNS, certificates, gateways and cloud inventory, block unregistered public routes, standardize identity policy and make retirement revoke routes, credentials and data intentionally.
Retest the invariant, not just the payload
Verify the discovered route is either governed and secured or fully retired. Re-run inventory reconciliation, test alternate names and direct routes, and confirm monitoring detects attempted use. Sample sibling assets created by the same deployment path.
Use the NIST Technical Guide to Information Security Testing and Assessment for assessment planning and evidence discipline, and the OWASP Web Security Testing Guide for relevant application techniques. Adapt both to the system-specific trust decision described here.
The architecture decision
Treat attack-surface mapping as reconciliation between control planes, runtime evidence and ownership—not one scanner result. A trustworthy map makes every reachable API explainable, governed and testable, while unknowns trigger containment and accountable resolution.
Ask WIMD to map and validate hidden API exposure across DNS, gateways, deployments, clients, telemetry and ownership.