Scope Boundary at the Second NIC
During a five-day internal penetration test for Northwind Logistics, the rules of engagement (RoE) authorize 10.10.10.0/24 only, 08:00–18:00 UTC, with an explicit no-pivoting clause: 'Do not access systems outside the listed ranges without prior written approval.' On day two you compromise WS-042 and find a second NIC with a route to 172.16.5.0/24. An ARP scan shows 40 live hosts, including PROD-SQL01 and a domain controller for a second forest. Your client contact is unreachable until tomorrow and the engagement ends Friday; you have 14 testing hours left. You already have local admin on WS-042 via PrintNightmare and a Kerberoastable service account hash for the in-scope domain, which you have not yet cracked. The sponsor's stated goal is 'Domain Admin before the red team.' The SOC flagged one of your earlier scans but took no action.
1. What do you do about the discovered 172.16.5.0/24 network, and why?
Read the worked answer
The RoE is the contract; the sponsor's objective does not amend it.
- Stop. The ARP scan already sent frames to 172.16.5.0/24. I would not send TCP/UDP or authenticate there again, and I would record exactly what left WS-042 (ARP only) with timestamps.
- Preserve. Screenshot
ip addr,ip route, the ARP table, and the no-pivoting clause. Export terminal logs. - Notify in writing. Email the sponsor and contact that a second network is reachable, that I have not enumerated it, and request a written scope change naming ranges, allowed techniques, testing window, and emergency contact.
- Continue in scope. Crack the Kerberoastable hash offline, enumerate CORP.LOCAL from WS-042, and pursue the in-scope path.
Reasoning: 172.16.5.0/24 may be production or another tenant. Unauthorized access risks outage, data breach, and contract breach. 'Get DA' is an objective, not authorization. If approval arrives, I would update the test plan and only then scan. If not, the finding is 'network segregation weakness' with evidence limited to the route and ARP discovery.
2. You have local admin on WS-042 and a Kerberoastable service account hash. How do you use them without violating the RoE?
Read the worked answer
Use the hash only against in-scope CORP.LOCAL resources. Request the TGS, crack it offline on my own infrastructure, and authenticate only to systems named in the RoE or reachable within 10.10.10.0/24. I would check BloodHound for ACL paths, avoid password spraying, and use the account for targeted ACL abuse rather than broad login attempts. I would not test the credentials on 172.16.5.0/24, the VPN, or any external service, because credential reuse is still access. Every use gets logged with source host, time, target, and result. The fact that WS-042 has a second NIC does not make the second network in scope; the host is a tool inside scope, not a scope expansion.
3. The sponsor says 'just take a quick look at PROD-SQL01, it's fine.' How do you respond?
Read the worked answer
A verbal 'it's fine' is not authorization. I would explain that PROD-SQL01 is outside 10.10.10.0/24, and even a quick look can create logs, touch production data, or cause an outage. I would ask for an email or ticket from the authorized signer that names the host, allowed actions, time window, and emergency contact. If it arrives, I update the RoE and test plan before connecting. If it does not, I decline and document the request, the refusal, and the reasoning. I can offer passive validation instead, such as reviewing a packet capture or configuration the client provides, but I would not send traffic to the host.