The Pivot That Left the Scope Document
On day 6 of a 10-day internal test, the tester holds a SYSTEM session on app-01 (10.0.5.14) and pivots to 10.0.9.31 using harvested service credentials. The authorisation letter names only 10.0.5.0/24 plus two named hosts; 10.0.9.0/24 appears nowhere. The pivot exposes an SMB share containing payroll_2024.xlsx and svc-notes.txt, which appears to hold domain administrator credentials in plaintext. On the daily call the client's IT director says: "You're doing great - if you can get in there, go for it, we'll sort out the paperwork later." Separately, an earlier scan of 10.0.5.0/24 touched 10.0.5.200, which the asset register later identified as a vendor-managed cardiac telemetry gateway. The final report is due to the client's risk committee, and the client has a regulatory obligation to report certain security incidents.
1. What do you do immediately about 10.0.9.31 and the IT director's verbal approval?
Read the worked answer
Stop, contain, escalate - in that order.
Stop. Cease enumeration on 10.0.9.31, do not authenticate with the discovered domain administrator credentials, and do not open payroll_2024.xlsx. Each of those acts on an out-of-scope host increases exposure - of payroll data, of the client's directory, and of the tester. Note what was already observed and how, because the fact that a share with plaintext DA credentials is reachable from an in-scope host is itself a significant, reportable finding.
Contain. Close any session or route that crosses into 10.0.9.0/24 so an automated job cannot wander further overnight. Confirm with jobs -l and sessions -l that nothing is still running against that segment.
Escalate in writing. Verbal approval from an IT director is not authorisation. The tester cannot verify that this person is the signatory on the letter, and "we'll sort out the paperwork later" is the phrase that ends up in a regulator's file. Send the engagement manager a written summary: what was accessed, when, what was observed, and a request for a written scope amendment signed by the original authorising party. If the amendment comes back in writing and names 10.0.9.31, testing can resume under the amended rules; if not, the finding is reported as an observation with no exploitation evidence.
Record the timeline of the verbal request and your response - protect the firm and the client equally.
2. How do you handle the payroll data and the telemetry gateway?
Read the worked answer
Both are data-handling and safety problems rather than exploitation problems, and both are handled by doing as little as possible and documenting precisely.
Payroll file. Never copy, open, or exfiltrate it - proof of impact does not require content. Record the share path, filename, permissions, and timestamp observed, and stop there. Filenames and access rights are enough to write the finding. If content was displayed incidentally during enumeration, note that in the log and notify the client's primary contact, because the client may have a regulatory reporting obligation triggered by unauthorised access to payroll data - that decision is theirs, but it must be made with information.
Cardiac telemetry gateway. This is the more serious of the two. A vendor-managed medical device touching patient safety is almost certainly excluded from scope by omission, and many are fragile enough that a version scan alone can cause a fault. Stop all scanning and any NSE scripts aimed at 10.0.5.200, confirm no jobs remain, notify the primary contact and the asset owner the same day, and document the exact probes that reached it with timestamps. Do not retest it, do not attempt to enumerate further, and do not treat its presence as a curiosity - an unregistered device on a scanned range is a finding the client needs, but it must be delivered as an observation, not an exploited host.
In both cases the principle is the same: minimise the footprint, maximise the record, and let the client make the risk decision with the facts.
3. How should this appear in the risk committee report, and what would you refuse to do before submission?
Read the worked answer
The report has to be accurate about what was and was not done, because it may be read by a regulator and it will certainly be read by the client's lawyers if anything goes wrong.
Report it as observations, not exploits. Write up: (a) an out-of-scope host reachable from an in-scope foothold, with plaintext privileged credentials on a share - high severity, high confidence, no exploitation performed; (b) an unregistered medical device on the scanned range - flagged as an asset-management and scope gap with a note that scanning ceased on identification; (c) the process finding that scope documentation did not match the reachable attack surface. Include the probe list and timestamps for 10.0.5.200 so the client can assess any device anomaly itself.
Include the authorisation trail. State that testing on 10.0.9.0/24 was halted pending written authorisation, and what followed. Do not editorialise about the IT director; state facts and dates.
What I would refuse. Removing the medical device incident to keep the report tidy. Removing the credential exposure because it was outside scope. Softening the severity because the client will find it uncomfortable. Re-running the scan against 10.0.5.200 after being asked to "just confirm it's fine". And submitting any finding whose supporting evidence I cannot show to the client on request - the report is worth exactly as much as the artefacts behind it.