Wildcard Scope, Cloud Hosting and a Key Found in a Public Repository
Northwind Logistics commissioned a three-week external black-box assessment. The signed scope lists the address range 203.0.113.0/24 and the wildcard *.northwind-logistics.example. The rules of engagement forbid denial-of-service testing, social engineering against staff, and any interaction with third-party SaaS providers.
Four days into passive collection you have three items. First, certificate transparency logs reveal vpn.northwind-logistics.example and staging.northwind-logistics.example; staging resolves to 198.51.100.77, a cloud address outside the /24. Second, the company's public GitHub organisation contains a repository whose commit history holds an internal hostname, ftp-legacy.corp.northwind-logistics.example, and a hard-coded API key. Third, a job advert mentions SAP and "an ageing file-transfer platform".
The client's technical contact is on leave for another week and has not answered two scope questions. Your engagement lead wants a progress update tomorrow and asks whether you can "just try the staging box" to have something to show.
1. Decide whether staging.northwind-logistics.example may be tested, and state exactly what you do with the API key found in the GitHub repository.
Read the worked answer
The conflict. Two scope anchors disagree: the wildcard authorises the name, the /24 authorises the address space. staging resolves outside the range. Name-based scope usually does cover externally hosted assets, but only where the client controls the asset or the provider has permitted testing. The rules of engagement exclude third-party SaaS, and a shared cloud tenancy is precisely that risk: you cannot assume you are the only tenant behind 198.51.100.77.
Action. Do not test staging until you hold written authorisation that names the asset and confirms the provider's acceptable-use policy allows it. Log the question, the timestamp and who was asked, and escalate to the engagement manager and the client sponsor rather than the on-leave contact. Keep working the in-scope range meanwhile so the schedule does not stall, and state plainly in the update that you chose not to test rather than that you could not.
The API key. Do not authenticate with it anywhere. Using a credential against a system you are not authorised to test converts a finding into unauthorised access, and it is unnecessary to prove the exposure. Retain a SHA-256 hash, the repository URL and the commit ID; never paste the value into the report, tickets or chat. Recommend immediate rotation and history purge. The secret exposure is itself a valid High finding about secret management, not a licence to log in.
2. Rank your collection activities for the next 48 hours and justify the order.
Read the worked answer
Order by detection risk and by whether an activity needs the absent approver, not by how interesting the result might be.
- Finish passive sources (today). Certificate transparency, WHOIS and ASN records, DNS history, reverse-IP neighbours, passive scan datasets, the GitHub organisation, breach corpora, job adverts. Zero packets to the client, reversible, and it feeds everything later.
- Low-noise active resolution (today). Resolve the in-scope names, enumerate SANs on the TLS certificates of in-scope hosts, and fingerprint HTTP responses. Attempt a zone transfer against the authoritative nameserver once - a single AXFR is quiet and cheap, and either answers or fails cleanly.
- Service discovery on 203.0.113.0/24 (day 2, throttled). Rate-limited scan with a source IP the client's SOC already knows, daytime so it is attributable.
- Deferred. Anything against ftp-legacy.corp.northwind-logistics.example -
corp.is not matched by the wildcard - and anything against staging. Both are scope questions, and the technical contact cannot answer them.
The reasoning is that the two most valuable leads (an exposed VPN and an exposed file-transfer platform) are already visible without touching either asset, so 48 hours spent quietly mapping is worth more than an argument about a single cloud box.
3. How do you record provenance for the GitHub finding so it survives scrutiny in the report and after a retest?
Read the worked answer
Provenance answers "where did this come from, and could it have been fabricated or altered?" - record it at the moment of collection, not when writing the report.
- Capture the UTC timestamp, the full repository URL, the branch, the commit hash, the file path and the line reference. A commit hash is stronger evidence than a screenshot because it is immutable and independently checkable.
- Take a screenshot showing the commit page in a browser with the URL bar visible, and store the raw artefact (the file, not the whole repository - do not mirror third-party code you have no need for) in the encrypted evidence store with a SHA-256 checksum.
- Note which account performed the collection and by what method (unauthenticated web browse), so nobody later argues it came from authenticated access.
- Redact the key value in the report copy; keep the unredacted original only in the evidence store under the agreed retention period.
- If the repository is taken down before the report is issued, the screenshot plus hash is what remains admissible, which is why you capture the same day.
The same template applies to the certificate transparency data: source, query, timestamp, and the exported result set.