The /22 That Wasn't in the Statement of Work
Northbridge Mutual, a mid-size insurer, has contracted you for a five-day external penetration test. The statement of work lists three hostnames and two /28 blocks (198.51.100.16/28 and 203.0.113.32/28) and states: 'No testing of assets outside the defined scope. Any change requires written authorisation from the contracting officer.' On day one you run passive DNS and certificate transparency lookups and find 61 subdomains, one of which (promo.northbridgemutual.example) is a CNAME to a storage bucket name that returns NoSuchBucket. An ASN lookup shows the insurer owns 192.0.2.0/22, containing five additional /24s that are absent from the SoW; one of them hosts an internet-facing VPN concentrator. A code search finds a repository forked from the insurer's GitHub organisation containing an AWS access key and secret committed 19 days ago. The engagement ends Friday and the contracting officer is on leave until Thursday.
1. You hold four leads: the five unlisted /24s, the dangling CNAME, the leaked AWS keys, and the VPN concentrator. Rank them by urgency and state precisely what you may and may not do before Thursday.
Read the worked answer
The ranking follows two separate questions: how fast can harm occur, and what does my authorisation actually permit?
- Leaked AWS keys. Highest urgency, and the one item that needs no testing to act on. Exposure is live and the fix is client-side (rotate the key pair). Report it immediately through the contract's incident channel and the named alternate contact, not through a GitHub issue or the repo itself. You may not authenticate with the key, even read-only, even to 'check whether it still works': that is use of a credential on a system outside authorisation and likely breaches computer-misuse law as well as the SoW.
- Dangling CNAME. Passive verification only: record the CNAME chain, the HTTP response body and the timestamp. Do not register the bucket.
- VPN concentrator and the five /24s. Both are out of scope. You learnt about them from public registration data, which is fine; probing them is not, and 'it was one GET' is not a defence. Add them to the report as unscoped assets visible from the ASN, and request a written change order.
Document every step with UTC timestamps and the command or query used, so the boundary between passive observation and active testing can be demonstrated later. Send an out-of-band interim notice for the keys; do not wait for the final report.
2. A junior tester proposes claiming the dangling bucket with a harmless index.html, then handing it back to prove the takeover. Evaluate the proposal.
Read the worked answer
It should be refused, and the reasoning matters more than the refusal.
The bucket name appears in the client's DNS, but the bucket itself is a third-party cloud resource that belongs to nobody right now. Registering it is not testing the client's system; it is an action on external infrastructure with real consequences. The moment you control that name, every request for promo.northbridgemutual.example resolves to your content. Real customers could land on it, and any cookie scoped to the parent domain could be delivered to you. That is a live compromise of the client's brand path, performed without the cloud provider's permission, and it converts an observation into an incident that you caused.
What you can do instead, and what is sufficient for the report:
- Record the full CNAME chain and the provider's NoSuchBucket response, with timestamps and the requesting IP.
- Show that the bucket name is unclaimed by testing the name against the provider's own public naming rules and an unauthenticated HEAD request.
- Note the residual risk: subdomain takeover is exploitable whenever the DNS record persists and the name is free.
Remediation advice: either re-register the bucket inside a controlled account the organisation owns, or delete the CNAME entirely; also purge cached references and review other records pointing at the same provider. Offer to re-verify after the fix, in scope, at retest.
3. On Thursday the contracting officer authorises the two additional /24s and the VPN concentrator, but not the five unlisted ranges. How do you spend the remaining day and a half, and what changes about your recon method?
Read the worked answer
The authorisation is narrow, so the plan has to be built around an allow-list rather than a broad sweep of the ASN.
Method changes:
- Build an explicit target file containing only the authorised /28s, the two newly authorised /24s and the single VPN host address. Feed that list to every tool. Never point a scanner at 192.0.2.0/22 and rely on exclusion filters; one typo becomes an out-of-scope scan that you have to disclose.
- Convert the passive findings into active confirmation only where authorised: service discovery on the new ranges, TLS and HTTP fingerprinting on the VPN portal.
- Keep a scan log with start and stop times, source IP and tool version so the client can reconcile your traffic against its IDS.
Priority for the remaining time:
- The VPN concentrator, because an internet-facing remote-access appliance is the highest-value unauthorised entry point and the client has now asked for it. Focus on version identification, known-vulnerability matching, and authentication behaviour such as MFA enforcement and lockout.
- The two /24s, breadth first: exposed management interfaces, default pages, expired certificates and unauthenticated services. Depth only on anything that reaches a real service.
- Reserve the final half-day for writing, evidence packaging and a verbal debrief, because an unwritten finding is worth nothing.
Note in the report that five /24s remain untested and represent unknown risk; that sentence is often the one that gets a retest funded.