Domain Admin in Four Hours and a Verbal Instruction to Keep Going

Two things are being conflated: whether more testing would be useful, and whether I am authorised to do it.

The SoW is signed by a specific contracting officer, not by the IT director, and it says testing stops when the objective is reached. A verbal instruction over the phone does not amend it. Accepting it would leave me testing 1,400 users' infrastructure with no contractual cover, and if something breaks on day three the first question will be whose authority I was acting under. So the response is polite and immediate: send an email summarising the call, state that I am pausing expansion, and ask for a written change order from the signatory covering additional days, systems and rules of engagement.

Meanwhile, there is real value to deliver inside the existing scope:

• Confirm and document the path to SQL-FIN-01, so the crown-jewel objective is evidenced rather than assumed. That is within scope and is the reason the engagement exists.
• Convert the compromise into detection content: replay the Kerberoast and the privilege-escalation steps with the SOC watching, and record what did and did not alert. Attack-path replay is usually the most actionable output a client gets.
• Do the credential-hygiene analysis that made this trivial: count service accounts with passwords older than the rotation policy, identify accounts with SPNs and weak passwords, and check for Kerberoastable accounts holding privileged group membership.
• Clean up and prepare the interim debrief.

If the change order arrives Thursday morning, the extra time can be spent on the expanded objectives with proper cover.

The share is evidence of an access-control failure; the contents are other people's personal data. The SoW line is unambiguous: record paths, counts and sizes, do not open files.

What I do:

• Capture the share's ACL and the group memberships that grant access, since that is the actual finding: which accounts can read HR data and whether those accounts are over-privileged.
• Run a directory listing only, and record the total file count, total size, the top-level folder structure and a small redacted sample of filenames.
• Not open salaries_2024_final.xlsx, not open the 'disciplinary' folder, not copy anything, not take content screenshots, not run content-indexing tools across the share.
• Not use the file to 'prove' the finding by extracting a salary figure. Access demonstrated by ACL plus listing is sufficient and is defensible.

What goes into the report:

• The finding, the affected accounts, the business impact, and the remediation: remove broad group access, use role-based access groups, enable access-based enumeration and file-level auditing.
• The path, the count and the size, with a note that filenames alone suggest personal and special-category data. That sentence matters because it triggers the client's own legal assessment.
• The detailed file listing, if produced at all, goes in a restricted appendix with limited distribution, not in the main body circulated to the board.

I would also raise with the client, in writing, whether a share containing that data was exposed to accounts it should not have been, because that question may have a regulatory answer independent of my engagement.

Cleanup has to be evidenced, not just performed, because the client now has to trust that nothing of mine remains in a domain where I held full control.

Cleanup checklist:

• Remove any accounts, computer objects, group memberships and SPNs I created; delete any GPO I linked, restoring the previous link state and order.
• Remove scheduled tasks, services, directory ACL changes and any certificates I enrolled; check AD CS for issued certificates under my test accounts.
• Revert any configuration changes to servers touched, and confirm with the system owners.
• Return or destroy any captured hashes and artifacts according to the contract, and delete tooling from client hosts rather than leaving it for convenience.

Handover evidence:

• A timeline in UTC of every privileged action, keyed to the accounts and hosts involved, so the SOC can check what it saw.
• The detection gap list from the replay exercise: which steps generated no alert, and suggested logic for each.
• The attack path as a narrative with the specific misconfigurations at each hop, plus a prioritised fix list: the stale service account password, SPN hygiene, tiered admin model, and protection for Tier 0 assets.
• A short list of things I could not verify without a retest, and a proposed retest scope.

Handover is a live conversation, not an email attachment. Walk the client's admin and SOC leads through the timeline so they can challenge it, then send the written version.