Domain admin and the HR share: where proof stops

I would stop before opening anything. A directory listing is metadata; opening files, copying them or searching inside the share turns a controlled test into access to 41,000 employees' salary and disciplinary records, which is special-category personal data in most jurisdictions and outside what the ROE authorizes. 'Proof' here is the account I hold, the effective permissions (share and NTFS ACL output), the directory listing showing the folder names, and a timestamped screenshot or hash manifest. I would not open Salary_Bands_2024.xlsx or the Disciplinary folder. I would record that read access exists and the apparent data categories, then stop and document. There is also an evidence-handling reason: if I copy files, I create a new copy of sensitive data on my own equipment, which may itself be a reportable incident and certainly widens the client's exposure. I would notify the deputy CIO promptly, because an HR share readable by a compromised service account is a live risk that needs containment on their side. I would record it as a critical finding: authenticated access to HR data by a domain-joined service account, reachable from the Kerberoastable account.

Domain admin is the ceiling, so the remaining questions are what I do with it and who knows. I would not use it to browse further shares, reset passwords or create accounts - each of those is a change to the environment and some are indistinguishable from an attacker's actions. I would capture the evidence of how I got there: the Kerberoast ticket, the cracking time, the unquoted service path, the account names, and the exact timestamps. Then I would call the deputy CIO on the agreed escalation number. The message is short: I have domain admin, here is the path, here is what I have not touched, and here is what you should consider doing now - reset the service account, fix the unquoted path, decide whether the Kerberoastable account's password exposure requires broader rotation, and decide whether this triggers your incident process. I would ask whether they want me to continue or stop. The ROE says no persistence; domain admin itself is not persistence, but anything I leave behind could become it. I would record the time of the call, who I spoke to and their instruction. The tester does not decide alone whether the client's environment is 'really' compromised.

Evidence would be screenshots with the system clock visible, command output, the Kerberos ticket hash, the exact commands and their timestamps, all stored in an encrypted container on the testing laptop and hashed with SHA-256 at close of day. For the HR share: permissions and listing only, never content. For domain admin: the path and the minimum artefacts needed to reproduce, with credentials redacted in the report. Chain of custody is a simple log of who accessed the evidence store, when, and where it was transferred, plus deletion of working copies at the end of the engagement with the client's written confirmation. I would also review whether my actions created log entries the client's SOC will see and might misread; a short 'activities performed' appendix prevents their team spending a week chasing my traffic. The professional point is that I must be able to prove what I did and did not do. In a domain admin scenario the tester is the most plausible suspect if something goes wrong later, and the only defence is contemporaneous, verifiable records and a clean, minimal footprint.