HTB CJCA common mistakes
HTB CJCA · Understand the traps and how to avoid them.
When asked to classify a control, candidates label it by the technology involved (e.g., calling MFA 'a technical control' and stopping there) instead of assigning all applicable categories such as preventive, detective, or compensating, and they omit the CIA triad property the control protects.
The exam presents controls in realistic scenarios where a single control spans multiple classifications, and candidates memorize single-axis definitions from introductory material, so they anchor on the first label that fits and stop analyzing.
What to do instead
For each control, run a fixed three-pass checklist: (1) when does it act relative to the event - preventive, detective, or corrective; (2) how is it implemented - administrative, technical, or physical; (3) which CIA property and asset does it protect. Practice by taking ten controls from your own environment and writing all three answers for each, including any compensating role.
Candidates compute subnet boundaries, usable host ranges, or broadcast addresses from memory during the exam and pick an answer that is off by one or two addresses, or they misjudge whether a destination is on-link versus requiring a gateway.
Subnetting is usually practiced with calculators or cheat sheets, and under time pressure candidates rush the binary math, forgetting to subtract the network and broadcast addresses or misreading a /30 or /31 prefix.
What to do instead
Drill the block-size method until it is automatic: for prefix /n, the block size in the interesting octet is 256 minus the mask value in that octet, and usable hosts equal 2^(32-n) minus 2 for prefixes up to /30. Do twenty timed problems covering /24 through /30, and for each also state whether a given destination IP is on-link and what the next hop is.
When a scenario involves a suspected compromised host, candidates jump straight to remediation steps (reimage, delete the file) before establishing what evidence to preserve and what containment boundary to set, and they treat volatile memory as something that can be collected later.
Remediation feels productive and is what most candidates do in day-to-day IT work, while formal incident response ordering is learned as a list of phase names without practice applying the ordering to volatile evidence.
What to do instead
Memorize the ordering constraint that drives every answer: preserve volatile data (memory, connections, logged-in sessions) before shutdown, contain before eradicate, and eradicate before recover. For each practice scenario, write the first three actions and justify why each precedes the next; if an option involves shutting down or deleting before capture, eliminate it.
Candidates read a log excerpt and answer based on the most visually salient line rather than correlating fields: they miss that a 4624 logon type 3 from an unusual source paired with a 4672 special-privileges assignment indicates lateral movement, or they treat a single 4625 as an attack.
Log questions reward field-level reading (event ID, logon type, account name, source IP, timestamp ordering), but candidates skim for keywords like 'failed' or 'admin' and pattern-match to a familiar attack name.
What to do instead
Adopt a fixed reading order for every log question: identify the event source and ID, extract account and source address, check logon type or status code, then look at the sequence and frequency across events. Build a one-page reference of the ten event IDs you are most likely to see (4624, 4625, 4634, 4648, 4672, 4688, 4720, 4768, 4769, 1102) with logon types and what each implies.
When asked which authentication factor or protocol property applies, candidates conflate something you know, have, and are - for example counting a knowledge-based security question as a second factor alongside a password, or treating a push notification approval as phishing-resistant.
Everyday language calls any second step 'two-factor', and vendors market push approval as strong MFA, so candidates carry that framing into questions that hinge on factor independence and resistance to real-time relay.
What to do instead
Apply two tests to every factor question: is the second factor from a different category than the first, and can it be relayed or approved by an attacker in real time? Classify security questions as knowledge (same category as a password), push and SMS as phishable, and FIDO2/passkeys bound to origin as phishing-resistant. Practice by classifying ten real authentication flows against both tests.
Candidates identify a vulnerability class correctly but then describe the wrong impact or the wrong mitigation - for example calling an IDOR a server-side injection issue, or recommending input sanitization where the actual fix is an authorization check on the object reference.
Vulnerability names are memorized as labels without the underlying trust boundary, so the candidate cannot derive impact or fix and falls back to generic advice like 'validate input' or 'use HTTPS'.
What to do instead
For each vulnerability class you study, write three lines: which trust boundary is crossed, what the attacker controls, and what the minimal correct fix is. For access-control bugs specifically, distinguish authentication (who you are) from authorization (what you may touch) and note that the fix lives server-side on every object access, not in the client.
Candidates answer risk questions by rating likelihood and impact from gut feel and skip the control-effectiveness step, so a scenario with strong existing controls gets the same rating as one with none, or they confuse inherent risk with residual risk.
Risk frameworks are learned as vocabulary (likelihood times impact) without the step that adjusts for controls, and exam scenarios bury the control state in narrative detail that candidates skim past.
What to do instead
Use an explicit four-step worksheet on every risk question: identify the asset and threat, state likelihood and impact before controls (inherent), list the controls actually described in the scenario, then state residual risk after those controls. If the question asks for a treatment, map it to avoid, mitigate, transfer, or accept and justify against the residual rating, not the inherent one.
On operating system hardening questions, candidates recommend disabling a service or feature as the universal fix without checking whether it is required for the described function, and they miss that the correct answer is often restricting who can use it or logging its use rather than removing it.
Hardening is taught as a list of things to turn off, and candidates apply the list mechanically without reading the scenario's stated business or technical requirement.
What to do instead
Before choosing a hardening action, restate the function the system must perform and who needs it. Then prefer the least disruptive effective control: restrict access and log use before disabling, and disable only when nothing in the scenario depends on the feature. Practice by taking five common services (SMB, RDP, LLMNR, WinRM, print spooler) and writing the restrict-first and disable-when options for each.
Candidates describe detection content or monitoring coverage in vague terms - 'enable logging' or 'set up alerts for suspicious activity' - instead of naming the data source, the field or event that triggers, and the false-positive condition that must be tuned.
Detection engineering is the least hands-on domain for many candidates, so they substitute intent for specifics and cannot distinguish an answer that would actually fire from one that would not.
What to do instead
Write every detection answer in a three-part sentence: data source and event, the condition on specific fields, and the expected benign cause that requires tuning. For example, alert on repeated 4625 followed by 4624 for the same account from a new source within a short window, tuned against known service accounts with stale credentials. Build five such rules from logs you can access.
Candidates treat a scenario's stated policy or regulation as background and answer from general best practice, or they assume a control satisfies a requirement because it exists rather than because it produces evidence the requirement asks for.
Compliance questions read like narrative and the governing requirement is often one clause in a long scenario, so candidates answer the technical question they find interesting instead of the governance question asked.
What to do instead
Underline the requirement, framework, or policy clause in the scenario before reading the options, then eliminate any option that does not map to that clause. Distinguish control existence from control evidence: if the question asks how to demonstrate compliance, the answer must produce an auditable artifact such as a log, ticket, or signed review, not merely a deployed tool.