A Service Account Between You and the PII Database
After compromising a developer workstation you find svc_deploy's password in cleartext in a CI config file. svc_deploy is a domain service account with local admin on JUMP-01 and a CI runner, and the DBA team's privileged sessions land on JUMP-01. The crown jewel is PROD-DB-02, a PII database on a segmented VLAN reachable only through JUMP-01. The ROE says: no exfiltration of real PII, no modification of production data, stop and notify the client if you obtain access to PII, and "demonstrate impact with the minimum necessary footprint." A GPO restricts svc_deploy to logon hours 02:00–05:00, and the client's release pipeline fails hard if that account is locked or its password changes, halting releases for the day.
1. Map a path from the workstation to PROD-DB-02 and justify each hop.
Read the worked answer
Workstation → svc_deploy → JUMP-01 → DBA session → PROD-DB-02, with the fourth hop reconsidered before it is taken.
Reasoning: Each hop must earn its risk. Using svc_deploy gets you local admin on the jump host, which is genuine privilege escalation and worth demonstrating. But svc_deploy has two hazards attached: a logon-hours restriction means a daytime logon either fails (generating 4625s) or violates policy, and a lockout halts the client's release pipeline - a denial of service the ROE forbids. The DBA session on JUMP-01 is the safer bridge to the segmented VLAN, because it is an existing authenticated context you can use from a host you already administer, without touching the fragile service account at all.
Action: Prefer harvesting the DBA's session on JUMP-01. If you must use svc_deploy, do it inside 02:00–05:00, log on once, and watch for lockout. Log every hop with timestamps and the objective it served.
2. How do you prove access to the PII database without exfiltrating anything?
Read the worked answer
Prove authorization and reachability, never contents.
Reasoning: The ROE forbids exfiltration, and a report saying "we could have read the PII" is weaker evidence than a query result showing the schema and your permissions on it. The distinction that matters to the client is between "this account can reach this data" - which is the risk - and "here is a row of a customer's record" - which is a breach of their customers and of your own ROE. Even a count query touches production, so it should be minimal and timed.
Action: From the DBA session, capture the server name and session banner, then run permission and catalog queries (current user, role memberships, sys.databases, INFORMATION_SCHEMA.TABLES, fn_my_permissions) that reveal the data is reachable without returning rows. If a row count is needed for impact, use a single aggregate during a low-load window inside a read-only transaction, and write nothing. Then stop and notify per the ROE's PII clause - that clause was written for this moment.
3. You also consider Kerberoasting svc_deploy. How does that compare with using the cleartext password you already have?
Read the worked answer
Kerberoasting is the lower-risk option and also largely redundant here.
Reasoning: Kerberoasting requests a service ticket and cracks it offline - no failed logons, no lockout, no policy violation, which sidesteps the pipeline-halt risk entirely. Its cost is time and uncertain yield, and its footprint is a 4769 event with RC4 encryption that a mature SOC may flag. But you already hold the cleartext password, so cracking it again buys nothing except a second, quieter route to the same credential - useful only if you suspected the config-file password was stale.
Action: Do not spend engagement time roasting a credential you already possess. Use the offline technique only if the cleartext fails or if you need to demonstrate the exposure of the SPN itself as a separate finding for the report. And never attempt password guessing against svc_deploy or change its password: either action risks the lockout that halts releases, which is precisely the DoS the ROE prohibits.