Shadow Cloud, Leaked Key, End-of-Life VPN

Rank by evidential value per unit of risk, not by how interesting the finding is.

Top of the list is 198.51.100.44, the EOL VPN appliance: in scope, externally reachable, and defensible as a finding even if you never exploit it. Confirm the build with a single benign fingerprint rather than a full scan. A VPN concentrator is exactly the device that rate-limits, fails closed, or drops all tunnels under a scan, and an outage on day one is an availability incident you cannot justify.

The GitHub key is second in value but first in handling care. The four out-of-range cloud hosts and the CNAME'd records come last: not yours to touch until the scope question is answered.

The procurement analyst's 'probably ours' is not authorization. Procurement is not the asset owner and their email will not survive an incident review. Put the question to the technical contact named in the RoE and keep working the 198.51.100.0/24 range meanwhile.

Not yet, and not as a shortcut to the VPN appliance. There are two separate problems.

Authorization first: a credential lifted from an employee's personal repository gives you access as that employee. The RoE almost certainly conditions testing on the two named test accounts or on credentials obtained through authorized methods during the engagement, not on material of uncertain provenance that someone else may already have used.

Integrity and attribution second: if a third party has used that key, your authentication produces log entries indistinguishable from an attacker's and will corrupt the client's own investigation.

The defensible sequence: confirm only what a passive check can establish (does the string match the vendor's key format), report it as a finding with the commit URL and date, and ask the client to confirm whether it is live and rotate it. If they authorize active validation, take it in writing, use it once, against one endpoint, from your testing source, and tell their SOC the timestamp in advance. Also flag the governance issue: personal-account repositories sit outside the client's organisation and will never be caught by their secret scanning.

Treat them as out of scope until the asset owner says otherwise in writing. A TLS certificate, a cached WHOIS record or an email from procurement is not proof of ownership.

For 203.0.113.16-19, the only permissible work is reading public data: reverse DNS, certificate SANs, published cloud ranges. Any banner grab or HTTP request is interaction with a host outside the agreed ranges, and the fact that a subdomain of the client's domain points there changes nothing about who operates it.

For the two CNAMEs, the label is Northwind's but the application is the provider's. Testing it tests the provider, and the client cannot grant that authorization.

Write it up as a scoping finding: the client has shadow-cloud assets, should inventory them, and must either bring them into a future engagement with provider consent or accept them as an untested exposure. Record discovery time, the passive sources used, and explicitly that you did not probe. If ownership is later confirmed in writing, treat it as a new sub-engagement with its own start date and window.