CREST CCT common mistakes
CREST CCT · Understand the traps and how to avoid them.
Writing the report's executive summary as a chronological narration of the test ("we ran Nmap, then found a login page, then tried SQL injection"), so the reader cannot see which business risks were found or how severe they are.
Candidates spend most of their preparation on tooling and treat reporting as an afterthought, dumping the engagement log into the first section. Under time pressure, narrating the process feels safer than making a risk judgement, and the candidate has not practised translating technical findings into business impact.
What to do instead
Draft the executive summary last but structure it first: three to five sentences on overall posture, a ranked list of the highest-impact findings with the business consequence of each, and a one-line recommendation. Practise rewriting a technical finding into a business-impact sentence (for example, 'an unauthenticated attacker can read every customer record' rather than 'IDOR on /api/v1/orders'). Keep all tool names, payloads and step-by-step detail in the technical sections.
Submitting findings with no reproducible evidence: a screenshot of a scanner plugin output, or a claim of exploitation with no request/response pair, affected URL, parameter, account and timestamp.
Candidates trust automated tool output as proof and copy the plugin description instead of re-testing manually. They also test without capturing traffic or note-taking discipline, so by report-writing time the exact request that triggered the issue is gone.
What to do instead
Adopt an evidence rule: a finding is only reportable when you can paste the exact HTTP request and response (or command and output) that demonstrates it, with the affected endpoint, parameter and role. Keep a running notes file per finding as you test, capturing raw traffic, and re-verify each finding once before writing it up. If you cannot reproduce it, downgrade it to an observation or drop it.
Reporting scanner output verbatim as the vulnerability list, including false positives such as generic 'SQL injection' or 'XSS' alerts on parameters that were never actually injectable, or informational headers presented as high-risk findings.
Time pressure and the desire for a long-looking report push candidates toward automated results. Many candidates have not internalised that scanners infer rather than confirm, and they lack a triage step that maps each alert to a manual verification.
What to do instead
Treat every scanner alert as a hypothesis. Build a triage table with columns for alert, manual test performed, result (confirmed / false positive / not testable), and evidence. Only confirmed items enter the findings section; false positives are discarded silently rather than listed. Include a short methodology note stating that automated results were manually validated.
Skipping or rushing scoping and rules-of-engagement checks: starting active scanning against in-scope hosts without confirming the target list, testing out-of-scope sibling domains or third-party services, or failing to record the authorisation reference before testing.
Candidates want to 'get going' and assume the target list is obvious or that adjacent assets belong to the client. Exam scenarios often include tempting adjacent hosts, and candidates who have not practised reading a scope statement carefully will treat a shared hosting IP or a subsidiary domain as fair game.
What to do instead
Before any active action, write down the authorised targets, excluded targets, permitted techniques, time windows and emergency contact, and confirm them against the provided scope. Resolve every hostname and check each IP against the exclusion list before scanning. When a discovered asset is ambiguous, log it as 'out of scope, not tested' and note it for the client rather than probing it.
Treating the methodology as a tool checklist: running the same scanner profile against every target and declaring the assessment complete, with no threat model, no manual business-logic testing, and no coverage statement of what was and was not tested.
Tool-driven habits from practice labs reward breadth over depth. Candidates memorise a command sequence and equate 'I ran all the tools' with 'I assessed the system', and they have not practised deriving tests from how the application actually works.
What to do instead
Start from an asset and trust-boundary map, then derive test cases from the application's roles, data flows and business rules (for example, can a low-privilege user approve their own request, replay a coupon, or skip a payment step). Record each test area as tested / partially tested / not tested with the reason, and include that coverage table in the report.
Overclaiming impact: labelling a self-XSS or a missing security header as 'critical', or stating 'full database compromise' after demonstrating only an error-based injection on a single column with no data extracted.
Candidates conflate a vulnerability class with its worst-case outcome and want findings to look significant. Without a consistent scoring method, severity becomes a gut feeling, and exam pressure inflates it.
What to do instead
Score each finding with an explicit method (for example CVSS plus a business-context adjustment) and state the assumptions behind the score. Separate 'demonstrated impact' from 'potential impact' in the write-up, and tie severity to what was actually proven. Calibrate by writing the one-sentence worst realistic outcome for each finding and checking whether your evidence supports it.
Losing track of state during exploitation: firing payloads without confirming the injection context, breaking the target so later tests cannot run, or leaving uploaded shells, created accounts and modified data behind at the end of the engagement.
Candidates chase a successful payload and stop thinking about reversibility. In lab environments nothing matters afterwards, so cleanup and state tracking are never practised, and the adrenaline of a working exploit crowds out bookkeeping.
What to do instead
Before each exploitation attempt, record the current state and the expected effect, and test the least destructive variant first. Keep a change log of every account, file, configuration change or data row you create, with the exact reversal step. At the end, execute the cleanup list and verify each reversal, then state in the report that cleanup was completed.
Stopping at the first confirmed vulnerability in each area instead of chaining or escalating: reporting an IDOR as an isolated finding without checking whether it enables account takeover, privilege escalation or access to other tenants.
Candidates treat findings as a checklist to be ticked off and move on to the next category. Chaining requires holding several facts in mind and reasoning about attacker workflow, which is rarely practised in single-issue lab exercises.
What to do instead
After confirming a finding, spend a fixed short block asking 'what does this unlock?'. Map each finding to the assets and privileges it touches and test the next step (for example, use the leaked token to reach an admin function, or the file read to obtain credentials). Present confirmed chains as a single narrative finding with the full attack path.
Misreading the evidence during vulnerability analysis: calling reflected input 'XSS' without checking output encoding and execution context, calling a 200 response to a crafted request 'authentication bypass' without checking whether the action actually occurred, or ignoring that the payload was blocked and the app failed closed.
Candidates pattern-match on the payload appearing in the response or on an unexpected status code, rather than verifying the security-relevant outcome. Exam time pressure rewards the first plausible interpretation, and candidates have not built the habit of asking 'did the application actually do the dangerous thing?'.
What to do instead
For every candidate finding, define in advance the observable that proves exploitation (script execution in a browser, a changed database row, a returned secret, a privileged action completed) and check that observable rather than a proxy signal. Where a control might have blocked you, test a benign control request alongside the payload and compare. Record the reasoning in the finding.
Poor client communication and professional conduct during the engagement: going silent for long periods, contacting the wrong stakeholder about a critical finding, disclosing a serious issue only in the final report, or arguing defensively when a finding is disputed.
Candidates focus entirely on technical skill and treat communication as soft skills outside the exam. They also fear being wrong, so they delay raising a suspected critical issue until it is fully proven, which is the opposite of what a client needs.
What to do instead
Agree an escalation path and check-in cadence at kickoff, and follow it: notify the agreed contact immediately for anything that could cause ongoing harm, with a clear 'what we saw, what we did, what we recommend now' structure. Keep provisional findings labelled as such. When a finding is disputed, restate the evidence and the test conditions, offer to re-test jointly, and record the disagreement and resolution in the report rather than escalating the argument.