HTB CAPE common mistakes
HTB CAPE · Understand the traps and how to avoid them.
Enumerating only with a single BloodHound collection run and treating the resulting graph as the complete picture, never validating it against manual LDAP queries, SMB share listings, or session data.
BloodHound is the most advertised tool in AD labs, so candidates run it once, get a pretty graph, and assume collection was complete. In practice collection can miss objects due to insufficient rights, quiet collection modes skip session and logged-on data, and stale edges mislead. Candidates then chase a path that does not exist or overlook a path the graph did not render.
What to do instead
Treat BloodHound as a hypothesis generator, not an answer key. After each collection, spot-check key edges (GenericAll, WriteDACL, ForceChangePassword, AdminTo, HasSession) with direct LDAP queries or native tooling, and re-run collection with session/logged-on collection enabled after every foothold change. Record which collection method and rights level produced each finding in your notes so you can distinguish confirmed from inferred paths.
Skipping the unauthenticated and low-privilege enumeration phase and jumping straight to a known exploit chain, without first mapping domain name, DC IPs, functional level, users, groups, computers, trusts, and password policy.
Training material often presents a linear walkthrough, so candidates memorize step order and skip reconnaissance. Without baseline facts such as the domain functional level, whether SMB signing is enforced, or how many domain admins exist, later decisions (which coercion technique, whether relay is viable, whether lockout is a risk) are guesswork and often fail or lock accounts.
What to do instead
Before any exploitation, build a one-page fact sheet: domain FQDN and NetBIOS name, DC hostnames and IPs, functional level, password and lockout policy, list of privileged groups and members, trusts, and hosts with signing disabled. Derive every later technique from this sheet, and update it after each new credential or host you obtain.
Obtaining a valid credential or hash and immediately attempting domain-wide spraying or broad authentication to find where it works, rather than targeting hosts where that principal has sessions or local admin rights.
The excitement of a first credential leads to indiscriminate use. Spraying a single account across many hosts triggers lockout policy, generates 4625/4771 events, and can burn the credential. Candidates also forget that a valid domain credential is not automatically local admin anywhere.
What to do instead
Before using a credential, check lockout policy and the account's group memberships, then query BloodHound or LDAP for computers where the principal has AdminTo, CanRDP, or active sessions. Authenticate only to those targets, one at a time, and prefer pass-the-hash or ticket use over repeated password logons where appropriate.
Failing to recognize when the initial foothold is a machine account or service context with constrained rights, and continuing to hunt for domain privilege escalation instead of pivoting through local privilege escalation on the compromised host.
Many AD footholds land as a low-privilege service account or a machine account (for example after a relay or certificate abuse). Candidates assume any AD credential means domain escalation is next, and waste hours on Kerberos attacks that the account cannot perform, missing local admin paths, unquoted service paths, or stored credentials on the host itself.
What to do instead
Immediately characterize the context: whoami /all, group membership, privileges, logon type, and whether the account is a machine or user account. If it is a machine account or low-priv service, prioritize local privilege escalation and credential harvesting on that host before returning to domain-level attacks.
Running Kerberoasting or AS-REP roasting and then attempting to crack every returned hash with a large wordlist on the exam host, instead of prioritizing accounts by privilege, password age, and realistic crackability.
Candidates treat cracking as a brute-force race. They spend the time budget on RC4 hashes for service accounts with long random passwords while ignoring that a single crack of a privileged service account or a Kerberoastable account with a weak password yields far more. They also forget that AES-only accounts produce harder hashes.
What to do instead
Sort roastable accounts by group membership and password last-set date, request only RC4 where possible (or note the encryption type), and crack in priority order with a targeted wordlist plus rule set. Set a hard time box per hash and move on; document uncracked hashes as findings rather than consuming the whole budget.
Discovering ACL-based rights such as GenericAll, WriteDACL, or ForceChangePassword and applying the abuse immediately without checking whether the target is a honeypot, whether the right is inherited, or whether a safer equivalent path exists.
ACL abuse is heavily emphasized in training, so candidates pattern-match an edge and execute. They miss that some rights are inherited from a parent object, that the target may be a decoy monitored account, or that the abuse requires a logon that will be detected. They also skip the reverse direction: who has rights over them.
What to do instead
For each ACL finding, record the source object, the target, the right, and whether it is inherited or explicit. Check the target's group membership and recent logon activity before touching it, prefer non-destructive abuses (ReadLAPSPassword, AddMember to a low-value group) over password resets, and always enumerate inbound rights on your own compromised principals.
Attempting lateral movement with pass-the-hash or overpass-the-hash against hosts without first confirming the authentication protocol, SMB signing status, and whether the target accepts NTLM.
Candidates learn one lateral technique and apply it everywhere. If the target enforces SMB signing, requires Kerberos, or has NTLM disabled, the attempt fails and may log noisy failures. They also confuse pass-the-hash (NTLM) with pass-the-ticket (Kerberos) and use the wrong material.
What to do instead
Before moving, check SMB signing, NTLM policy, and whether you hold an NT hash or a Kerberos ticket. Match the technique to the material: hash to NTLM-permitting hosts, ticket to Kerberos-only hosts. Test with a single low-noise command (e.g., a directory listing) before running a full remote execution tool.
Pivoting by opening a new channel to the target network from the attack host instead of routing traffic through the compromised host, losing the ability to reach internal-only segments and leaving inconsistent tooling on each hop.
Candidates treat each new subnet as directly reachable because their tooling happens to work from one host. When a segment is only reachable through an intermediate host, commands fail and they conclude the path is dead, rather than establishing a tunnel or proxy chain.
What to do instead
Maintain an explicit network map of which hosts can reach which segments, and establish a persistent pivot (SOCKS proxy, port forward, or agent) through each hop before enumerating the next segment. Verify reachability with a simple connectivity check and record the pivot chain so you can reproduce it.
Stopping at domain admin on the first domain and never enumerating or attacking forest trusts, SID history, or cross-domain group memberships to reach the forest root or a trusting domain.
Domain admin feels like the finish line, so candidates report and stop. In multi-domain or multi-forest environments the objective often requires crossing a trust, and the path frequently runs through SID history, foreign group membership, or a trust key rather than a direct attack.
What to do instead
After domain compromise, enumerate trusts in both directions, check for SID history and foreign security principals, and identify whether the trust is transitive, whether SID filtering is enabled, and whether a trust key or inter-realm ticket can be extracted. Map the cross-domain path explicitly before attempting it, and document what each hop requires.
Establishing persistence (golden ticket, DCSync-created account, scheduled task, or ACL backdoor) without verifying it survives a realistic condition such as password change, reboot, or ticket lifetime expiry, and without recording how to remove it.
Candidates add persistence as a checkbox at the end and never test it. A golden ticket forged with a stale krbtgt hash fails after a double password reset, and an ACL backdoor on a deleted object disappears. They also cannot clean up, which costs them in the reporting phase.
What to do instead
For every persistence mechanism, state the exact condition it survives and the condition that breaks it, then test at least one failure condition in the lab. Record the artifact (account name, ticket, ACL entry, task path) and the removal steps as you create it, so remediation guidance is accurate and cleanup is possible.
Writing the final report as a chronological command log rather than mapping each finding to the affected asset, the business impact, the evidence, and a specific remediation step.
Candidates replay their terminal history because it is easy and feels complete. Graders and clients need to see risk and fixability, and a command log neither demonstrates understanding nor supports remediation. It also obscures which findings are confirmed versus attempted.
What to do instead
Structure the report by finding, not by time: title, affected hosts and accounts, evidence (command output or screenshot reference), impact in business terms, and a concrete remediation with an owner and verification step. Keep a separate appendix for the attack narrative and commands so the main body stays decision-oriented.