HTB CWES common mistakes
HTB CWES · Understand the traps and how to avoid them.
Spending the first hour on directory brute-forcing with a large wordlist against every virtual host before manually walking the visible application, so the attack surface from robots.txt, sitemap.xml, JavaScript bundles, and HTML comments is discovered late or never.
Candidates equate reconnaissance with tooling output volume and start the loudest scanner first. Automated brute force returns hundreds of 301/302 and soft-404 responses that are never triaged, and the manual reading that actually reveals parameter names, API routes, and debug endpoints gets deferred until time pressure forces shortcuts.
What to do instead
Sequence recon deliberately: fetch and read robots.txt, sitemap.xml, security.txt, and the root HTML; pull endpoint strings and API base paths out of JavaScript files with a grep for fetch, axios, /api/, and URL literals; check common backup and config extensions against discovered paths; only then run directory brute force with a response-size and status-code filter to strip soft-404s. Record every discovered host, path, and parameter in a running notes file with the request that found it.
Treating a SQL injection finding as complete at the first boolean or error-based confirmation, without determining the backend DBMS, enumerating the schema, extracting credentials, and testing whether the same parameter supports stacked queries or file read/write.
The injection is reported as soon as a payload proves the flaw, because the candidate wants to bank a finding. The exploitation phase is then skipped, so the exam misses the credential reuse, the second database, or the file-write-to-webshell path that the scenario was built around.
What to do instead
After confirming injection, fingerprint the DBMS from version banners or dialect-specific syntax, enumerate databases, tables, and columns, dump the credential-bearing table, and test for stacked queries, out-of-band interaction, and file read/write where the DBMS account permits. Crack or reuse recovered hashes against the login and any exposed admin panel before moving on, and log each payload with the exact response evidence.
Submitting a reflected alert(1) as the XSS finding and never demonstrating impact, such as session theft against a real victim context, CSRF token bypass, or chained DOM clobbering that changes application logic.
alert(1) is the canonical proof from training material, so it becomes the stopping point. Candidates do not build the exploitation step because the exam scenario's victim bot, admin review queue, or stored rendering context is not connected to the payload they already have.
What to do instead
For each XSS candidate, identify the sink context (HTML, attribute, script, URL) and the delivery vector (reflected, stored, DOM). Then prove impact in the scenario's own terms: exfiltrate a cookie or token to a listener you control, perform a state-changing action as the victim, or read data the victim can see. For DOM sinks, test prototype pollution and clobbering gadgets rather than only script injection, and document the exact victim interaction required.
Decoding a JWT, noting alg is HS256, and declaring it vulnerable without testing algorithm confusion, none-algorithm acceptance, key confusion with a public key, or weak HMAC secret cracking.
The presence of a JWT is treated as the vulnerability. Candidates stop at inspection because writing a forged token requires tooling setup, and they assume the library is correctly configured without sending a single modified token to the verifier.
What to do instead
Capture a valid token, decode header and payload, and then actively test: set alg to none with an empty signature; if RS256 is used, try signing with the public key as an HMAC secret; run a wordlist against the HMAC secret offline; and mutate claims such as role, sub, and kid for injection and path traversal. Replay each forged token against a protected endpoint and record the status code and body difference.
Fuzzing a file parameter with ../../../../etc/passwd only, then abandoning the path traversal when the application normalizes or blocks that exact sequence, instead of testing encodings, absolute paths, null bytes, and wrapper prefixes.
One canonical payload is memorized and treated as the whole class. Filters commonly strip ../ once, so double encoding, mixed separators, and wrapper schemes succeed where the plain payload fails, and the candidate misclassifies the endpoint as safe.
What to do instead
Build a payload ladder per parameter: plain traversal, URL-encoded, double-encoded, backslash variants, absolute paths, and PHP or Java wrapper prefixes where the stack suggests them. Test both read and write primitives, and check whether the parameter feeds a file read, a template include, or an upload destination. Confirm with a response that contains known file content rather than a generic error.
Testing SSRF only with http://127.0.0.1 and concluding there is no SSRF when the response is generic, instead of using a collaborator listener, redirect chains, alternate IP encodings, and cloud metadata endpoints.
Blind SSRF produces no visible response, so the candidate reads the empty body as a negative result. Internal-only reachability also fails when loopback is filtered but the metadata service or an internal hostname is not.
What to do instead
Always supply an out-of-band listener URL first to prove the server makes the request, then pivot to internal targets: 127.0.0.1 variants in decimal, octal, and IPv6 forms, localhost aliases, and the cloud metadata address for the scenario's provider. Use an attacker-controlled redirect to bypass allowlists, and test non-HTTP schemes such as file and gopher where the client supports them.
Enumerating users by error message only and then stopping, rather than testing the password reset flow, remember-me tokens, MFA bypass, and session fixation that the scenario's authentication logic actually exposes.
Username enumeration is easy to confirm and feels like a complete finding, so the deeper logic flaws in reset tokens, cookie trust, and MFA state machines go untested. Candidates also avoid flows with multiple steps because they require scripted state handling.
What to do instead
Map every authentication entry point: login, registration, reset, change-password, MFA enrollment and verification, and social login callbacks. For each, test token entropy and reuse, host-header influence on reset links, response manipulation in multi-step flows, and whether MFA can be skipped by replaying the post-MFA request. Check session cookies for fixation, missing rotation on login, and weak flags.
Uploading a web shell and calling the upload vulnerability proven, without verifying execution, choosing an extension the server actually parses, or establishing a stable, non-noisy command channel for post-exploitation.
The upload succeeds with a 200 response, which is mistaken for code execution. Content-type and extension filters, upload directories outside the web root, and disabled execution in the target directory mean a stored file is often inert, and candidates then waste time re-uploading instead of diagnosing.
What to do instead
After upload, request the file directly and confirm the server executes it rather than serving it as text. Test extension variants the stack parses, magic-byte and content-type bypasses, and alternate upload directories. Once execution is confirmed, upgrade to a stable interactive channel, then perform host enumeration, credential discovery, and lateral movement before writing the report.
Chaining exploitation steps in the terminal without capturing the request and response evidence, then writing a report that describes the vulnerability but cannot be reproduced by a reviewer.
Time pressure pushes documentation to the end, and terminal scrollback is lost or overwritten by later commands. Candidates also write findings as narrative conclusions rather than as reproducible steps, so severity and impact claims are unsupported.
What to do instead
Capture evidence at the moment of discovery: save raw requests and responses, screenshots of the rendered impact, and the exact command line used. Write each finding with reproduction steps, affected endpoint and parameter, impact in business terms, and a specific remediation that names the control to change. Keep a timeline file updated as you go so the final report is assembled, not reconstructed.
Reporting a finding with a generic remediation such as 'sanitize input' or 'use parameterized queries' without naming the exact code location, the framework API to adopt, and the verification step that proves the fix.
Remediation guidance is written from memory of the vulnerability class rather than from the code actually observed, so it reads as boilerplate. Candidates also skip the retest instruction, leaving the client unable to confirm the fix closed the issue.
What to do instead
Tie each remediation to the observed sink: name the file or endpoint, the parameter, and the specific safe API or configuration for the detected stack, such as a prepared statement with bound parameters, a context-aware encoder, or an allowlist for the file path. Add a verification step describing the payload that should now fail and the expected response, and note any compensating control needed until the fix ships.