You crack a service-account password from a captured hash. What's the highest-value next step to demonstrate risk?
Short answer
The point is impact: a reused or over-privileged service credential that unlocks domain admin or critical systems is the finding that matters, so test for reuse and map the privilege and lateral-movement path. Cracking every other hash first is busywork that delays the real story. Changing the service-account password is destructive, breaks production, and tips off defenders. Emailing a live credential in plaintext is itself an exposure and bad operational security.
A single cracked credential is only interesting because of what it unlocks. A senior tester thinks in terms of attack paths: how does this one secret turn into control of something the business actually cares about?
Why testing for reuse and mapping privileges is correct
Service accounts are a classic weak link. They are frequently over-privileged, set with non-expiring passwords, reused across many hosts, and sometimes members of high-privilege groups. The highest-value next step is to test the credential against high-value systems and enumerate its rights — group memberships, where it can authenticate, what it can read or run. If it grants access to a domain controller, a database, or a jump host, you have turned one hash into a demonstrated path to critical compromise. That is the lateral movement / privilege-escalation narrative that drives remediation.
Why the other options are wrong
- Crack every other hash first. Mass-cracking is busywork. You already hold a working credential; chasing more hashes delays proving the impact that matters and burns engagement time.
- Change the service-account password. This is destructive — it can break the production services that depend on that account, causing an outage. It also tips off defenders and alters the environment, which is outside the brief.
- Email the password in plaintext. Transmitting a live, working credential over plaintext email is itself a new exposure. Recovered secrets must move over an encrypted channel, with handling and deletion agreed in advance.
What an interviewer is probing
They want path-based thinking and operational discipline. The strong answer chains the credential toward business impact while avoiding destructive or noisy actions. Bonus signal: mentioning least-privilege and credential hygiene as the root-cause fix, not just the single account you happened to crack.
Likely follow-ups
- How do service accounts typically enable lateral movement in an AD environment?
- What makes a service account 'over-privileged' and why is that common?
- How would you transmit recovered credentials to the client securely?