Red Team Token Reaches Beyond the Scope Boundary
During a 12-week authorized red team for a SaaS provider, your team finds Jenkins at staging.example.com without authentication. Job configurations contain a HashiCorp Vault token labeled prod-db-read. The signed rules of engagement permit testing staging.example.com, the corporate SSO, and the production web tier in read-only mode; they explicitly exclude the production application database and any data store holding customer records. The token appears valid, but you have not used it. The client's deputy CISO says by phone, "Go ahead and prove impact on the prod DB; just don't change anything." The primary security contact is unreachable for 30 minutes. The engagement has nine days left. Your teammate wants to run a Vault read to confirm. A signed scope PDF and an emergency contact list are available.
1. Can the team use the Vault token to read the production database? Explain the decision and the alternatives.
Read the worked answer
No. The token is evidence of a staging compromise, but it does not expand the authorized scope. The signed rules of engagement explicitly exclude the production application database and customer data stores. A verbal instruction from the deputy CISO, even from a client representative, does not reliably amend a written authorization that likely identifies a specific signer and scope. Using the token could read customer records, trigger production alerts, or violate contractual and legal constraints.
The safe alternative is to prove impact without touching production data. Document that the token exists, where it was found, and its label, but do not use it. If the client needs proof, propose a read-only query against a non-production replica, synthetic data, or a Vault policy review performed by the client. The team can also demonstrate that the Jenkins credential store is readable and that the token's scope appears broader than staging.
Escalate to the primary contact and the engagement manager in writing. State the finding, the requested action, and the fact that work is paused on that path pending written authorization. Preserve the Jenkins job configuration and a screenshot or hash of the token metadata without exposing the secret in chat or email.
2. How should the team document and communicate this scope boundary event?
Read the worked answer
Create a contemporaneous record: timestamp, tester identity, host and URL, Jenkins job name, token label, and the exact client instruction. Store the token itself in an encrypted secret store or redact it in reports; do not paste it into tickets or email. Hash the relevant Jenkins configuration and preserve a copy with restricted access. Record that no Vault read was performed.
Notify the primary security contact and the deputy CISO in writing, using a clear subject such as "Scope boundary reached: production Vault token found in staging." State three things: what was found, what was not done, and what decision is needed. Avoid implying that a verbal approval is sufficient. Copy the engagement manager and, if the client's legal or privacy team owns customer data, request that they join the decision.
If the client insists on production impact testing, require a written scope amendment from an authorized signer, a defined read-only query, a test window, and a data-handling plan. Until then, continue only with in-scope staging and SSO testing. This protects the client, the testers, and the evidentiary value of the finding.
3. If the client later provides written authorization, what conditions should the team require before using the token?
Read the worked answer
Require a written scope amendment that names the production database, the permitted operation, the exact test window, and the authorized signer. The amendment should require read-only access, row limits, and a prohibition on exporting customer records. Agree on a query that proves impact without returning PII: for example, a metadata query or a count against a non-sensitive table, or execution against a masked replica.
Before use, confirm legal and privacy review, notify the production database owner and SOC, and agree on logging and alert suppression boundaries. The client should provide a rollback or stop condition and a named contact who can revoke the token immediately. The team should capture the Vault audit log and its own command history, and should not store returned data outside the agreed evidence repository.
After the test, rotate the token and review why a staging Jenkins instance could reach production secrets. The finding is not just the token; it is the trust path from staging to production. Report that path, the missing authentication on Jenkins, and the secret sprawl as the primary risks.