The Adjacent /24: Scope Creep on Day 3 of a 5-Day External Test

No. Two independent controls block it.

Scope. The SOW's asset list enumerates 10.20.0.0/24. The phrase 'owned by Client' does not self-expand to an adjacent range; reverse DNS is a naming convention, not an authorization. The hosts may belong to a subsidiary, a managed-service provider, or a separate legal entity. Testing a subsidiary's systems can breach that entity's own agreements and, depending on jurisdiction, computer-misuse law.

Activity type. Default-credential testing is authentication, not reconnaissance. It is active testing and falls squarely under the MSA prohibition.

Next two hours:

1. Stop all traffic to 10.21.0.0/24 and note the exact time.
2. Preserve what you already have: timestamp, your source IP, the single GET, its response headers and body hash, and the discovery method.
3. Email the primary contact and the backup contact together, cc your engagement manager, requesting written authorization and naming the exact range and host.
4. Continue in-scope work on 10.20.0.0/24 so day 4 is not lost.
5. If no written answer arrives by the end of day 4, deliver the report covering the contracted range plus an out-of-scope observation describing the exposure without exploitation.

Structure and content:

• Subject line naming the engagement ID and the decision needed, e.g. 'Scope authorization required - 10.21.0.0/24 (response needed by Thu 12:00)'.
• Facts only: 'During in-scope reconnaissance of 10.20.0.0/24 I observed 10.21.0.0/24 in the same ASN with reverse DNS entries under client-retail.net. One unauthenticated GET to https:/// returned a Jenkins 2.401.3 login page. I have not attempted authentication and have stopped all traffic to that range.'
• The precise ask: written confirmation that the range is owned or controlled by Client, that Client is authorized to permit testing, the exact hosts or CIDR approved, and the name and title of the approving signatory.
• The constraint: 'I cannot test this range under the current SOW; without written approval it will be reported as an unverified observation.'
• A deadline tied to the engagement end, not to the compliance ticket.

Avoid: speculation that the range 'must be ours'; any exploit detail that reads as a teaser; and pressure language about the insurance renewal. Do not send it only to the travelling contact - the backup and your engagement manager must be on the thread so silence is documented.

Not sufficient on its own, for four reasons.

1. Authority. A phone reply does not establish that the sender is an authorized signatory under the MSA. Reply asking them to confirm from their corporate address, or have the signatory named in the SOW do so. A one-line email from the correct account, referencing the range, is usually enough; a chat message is not.

2. Ownership versus authorization. Even if the IPs are the client's, Jenkins may be vendor-managed or hosted. Ask who operates the host and whether a third party's consent is needed. 'Our range' and 'our authority to authorize testing' are different statements.

3. Scope artifact. Update the scope section of the engagement record - an email thread appended to the SOW is fine - naming the CIDR, the approving person, the date and time, and any excluded hosts. Never rely on memory of a call.

4. Risk acknowledgement. Note in the record that the Jenkins may be production build infrastructure and that authentication attempts could lock accounts or trigger alerts; agree a testing window and a stop condition. Then proceed, and reference the authorization in the report's scope section so the reader knows exactly what was and was not approved.