The scenario in the assessment, or the interview, is deliberately thin: you're on a workstation, you have a low-privilege domain account from a phishing simulation, and the question is just "what next." A nervous candidate's answer is almost always a tool name. Mimikatz. Pass the hash. Something they read about and remember sounding advanced. It falls apart in the next thirty seconds, because the interviewer's follow-up is always "pass the hash using what credentials," and there aren't any yet. Naming a technique isn't a plan. It's a guess dressed up as one, and assessors can tell the difference immediately.
The actual first move with a fresh low-priv foothold is never an attack. It's enumeration, specifically enumeration of what that one account can already see without touching anything that would generate a single suspicious event. A standard domain user, with zero elevated rights, can query a surprising amount: group memberships, which OUs exist, which accounts have Service Principal Names registered against them, and, if you pull it with something like BloodHound, the actual ACLs sitting on objects across the domain. None of that requires exploiting anything. It requires knowing that a regular authenticated user is allowed to ask.
That enumeration step turns up real paths that a tool-name answer skips straight past. Kerberoasting is the clearest example: any authenticated domain user can request a Kerberos service ticket (a TGS) for any account with an SPN registered, no special privilege required, and that ticket is encrypted with a hash derived from the service account's password. Pull it, take it offline, and crack it at your own pace with no domain controller in the loop and nothing else touched. If that service account turns out to be over-privileged, which happens constantly because service accounts get created once and never revisited, you've gone from "low-priv user" to "administrative account" without a single exploit, purely by asking the domain a question it was always going to answer.
ACL abuse is the other path enumeration surfaces that a memorized tool name never does. Delegated rights like GenericAll, GenericWrite, or WriteDacl over another object get granted for a legitimate reason at some point, a help desk team that needed to reset passwords, a service that needed to manage group membership, and then nobody ever revokes them once the original reason stops applying. Those rights sit there, invisible unless you specifically pull the ACLs and look, and they hand you a completely mundane-looking path to compromise a more privileged object without needing a single credential you don't already have.
What actually separates a strong answer from a weak one in that scenario isn't which specific technique gets named first. It's whether the reasoning starts from "what can this exact account already see" or from "what's the most impressive-sounding thing I remember." The first path is systematic and repeatable against an environment you've never touched before. The second is a guess that happens to be right occasionally and falls apart the moment someone asks a follow-up question, in an interview or in a real assessment where guessing wrong burns time you don't get back.
That enumeration-first discipline, and the Kerberoasting and ACL-abuse paths it actually surfaces, is what Codelivly's Red Team Book Bundle: L1, L2, Malware Dev, Psychology walks through as a full operator track rather than a list of tool names to memorize. The free Active Directory Attacks and Exploitation Fundamentals learning paths on codelivly.com cover the same ground hands-on if you want to test the reasoning before you commit to the bundle.
Top comments (0)