The Subdomain Outside the IP Range

The hostname is a lead, not an authorisation. The scope has two parts: the domain and a specific IP range. The dev host is a subdomain of the domain but resolves outside the stated range, so the scope is ambiguous. A name containing the client's brand does not prove the client owns or controls the cloud instance. The IP belongs to a hosting provider, which may host other tenants, and active testing could affect a third party.

Before any active traffic:

• Verify passively: inspect DNS records (A, CNAME, TXT, MX), the TLS certificate issuer and SANs, HTTP response headers, WHOIS, reverse DNS, and Shodan/Censys history.
• Ask the client in writing whether it owns the cloud account and the Jenkins instance, and whether the host is in scope.
• If yes, obtain a written scope amendment that names the hostname and IP, and confirm any cloud-provider authorisation requirements.
• Until then, do not scan, log in, or exploit. Record the decision and the evidence in your daily log.

The account manager's suggestion is not authorisation. A quick look is still active testing.

Passive collection is appropriate because it does not touch the client's or the provider's systems. Collect certificate transparency history, DNS records, WHOIS, reverse DNS, Shodan/Censys banners, HTTP headers from cached sources, job postings that mention the Jenkins instance, and public code repositories that reference the hostname. Do not send packets to the host, do not request its login page, and do not attempt default credentials.

Record each item with its source URL, collection time, and a screenshot or hash where possible. Label the host as 'unverified, out of scope pending written confirmation,' not as a confirmed client asset. Keep the evidence in the engagement folder. This lets you brief the client quickly if the host is confirmed, while showing that you respected the scope boundary.

Refuse the instruction and explain the risk in concrete terms: unauthorised testing of a third-party cloud tenant can breach the statement of work, the provider's acceptable-use policy, and computer-misuse law. The fact that the hostname contains the client's name does not cure that risk.

Then take these steps:

• Send a short email to the client sponsor and the account manager restating the scope ambiguity and asking for written confirmation or a scope amendment.
• Escalate to your engagement manager and legal/compliance contact.
• Continue with in-scope work so the engagement does not stall.
• Document the request, your refusal, and the escalation in the daily log.

If the client later confirms ownership, get the amendment before touching the host. If the client cannot confirm it, leave the host out of the report except as an informational OSINT lead.