What Passive Recon Turned Up
Meridian Health Scheduling commissions an external penetration test of meridian-sched.example and three public IP addresses listed in the SOW. The rules of engagement prohibit social engineering and phishing, and state that the SaaS provider hosting the patient portal is out of scope: "the cloud is out of scope, our provider handles it." Scope is further described as "the meridian-sched.example domain and the listed IPs."
Passive work returns more than expected. Certificate transparency logs show 46 subdomains, including vpn.meridian-sched.example, jenkins-ci.meridian-sched.example, staging-api.meridian-sched.example, and a wildcard certificate issued last week for a name nobody recognizes. The company's public GitHub organization contains a repository with a committed .env file holding what looks like an AWS access key and secret. A Shodan search on the company's ASN shows an unauthenticated Elasticsearch node on an IP that geolocates to a residential ISP rather than the corporate range.
1. Are the 46 subdomains in scope? Show how you resolve the ambiguity before running any active test.
Read the worked answer
Two SOW clauses conflict: "the domain" is broad, "three listed IPs" is narrow. When scope is ambiguous, default to the narrower reading and obtain written clarification - do not let your interpretation become the finding.
Resolve each name first: resolve to IP, then map to ASN and WHOIS, and bucket the results.
- Client-owned name on client-owned infrastructure: probably in scope, but confirm in writing.
- Client-owned name hosted at the SaaS provider or another third party: excluded by the "cloud is out of scope" clause, regardless of who owns the DNS record.
- Names not controlled by the client - parked pages, wildcard artifacts, or a name already taken over by a third party: never in scope.
The unrecognized wildcard name deserves attention because it may indicate a subdomain takeover in progress, which you can report without testing it.
Send the client the bucketed inventory and ask them to confirm in writing. Passive collection continues meanwhile; active testing of anything unconfirmed waits.
2. You find an AWS access key and secret in a public repository. What do you do, and what must you not do?
Read the worked answer
Do not use the key. Not to list buckets, not to "just validate it works." Testing a cloud account that is not in the SOW is unauthorized access to a third-party system, it breaches the AWS acceptable-use terms, and it can trigger provider-level incident response against your firm. It may also be a deliberate canary token placed to catch exactly this behavior.
What you do instead:
- Record the repository URL, commit hash, author, and commit date, and capture the evidence without echoing the secret into shared channels.
- Report it through the escalation path as a critical exposure. The credential's existence is the finding; whether it is live is the client's call to verify on their own account.
- Recommend rotation regardless of apparent age, plus a history purge and a secret-scanning control.
- Check whether the repository is genuinely corporate or an employee's personal namespace - that changes the recommendation, not the prohibition.
The key judgement tested: possessing a credential is not permission to use it.
3. Shodan shows an unauthenticated Elasticsearch node on a residential ISP IP within the company's ASN. How do you handle it?
Read the worked answer
Assume it is not yours to touch. An IP inside an ASN allocation can be a home lab, an employee's personal connection, a stale allocation, or a misattributed record; none of those are client systems, and querying an open Elasticsearch index is an access, not a scan.
Handling:
- Verify the ASN and prefix ownership through WHOIS/RIR data, and confirm whether that prefix is announced by the client or delegated to a residential provider.
- Do not connect to port 9200, even for a read-only index listing.
- Report it as an informational lead: what you observed, why it is not in scope, and what the client should investigate internally (whether company data lives there).
- If Shodan shows index names or document counts, quote them as observed metadata, not as data you retrieved.
The reasoning is the same as the AWS key: passive observation of a public service is reconnaissance; interacting with a system you have no authorization for is exploitation. The report still delivers value by flagging a probable shadow-IT data store.