The HTB Certified Defensive Security Analyst (HTB CDSA) is not a theory-heavy exam you can pass by memorizing terms alone. It tests whether you can work through realistic defensive and investigative tasks under pressure. That means your study plan should match the way the exam thinks. Instead of asking, “What definitions do I need?” ask, “What kind of evidence will I have to read, connect, and act on?” This guide breaks the main domains into practical study targets, shows what to memorize versus what to practice hands-on, and gives you a sensible review order before practice tests.
What the HTB CDSA is really testing
At a high level, the exam measures whether you can investigate, analyze, and respond across common defensive security scenarios. You are expected to enumerate systems, inspect logs and artifacts, understand attacker behavior, spot weak points in networks and web apps, and work through Active Directory and wireless issues. Some newer study paths also touch AI-related security ideas, especially around misuse, exposure, and validation.
The key point is this: the exam is built around judgment. You need to know what to look at first, what matters, and what can be ignored. Many candidates fail not because they know nothing, but because they cannot turn scattered clues into a clear next step.
So when reviewing domains, focus on three layers:
- Recognition: Can you identify what you are looking at?
- Interpretation: Can you explain why it matters?
- Action: Can you choose the next useful step?
Core knowledge areas you should expect to study
The exact presentation may vary by learning path, but most CDSA preparation revolves around a set of recurring skill areas.
- Methodology and investigation flow
- Host and network enumeration
- Defensive analysis and log review
- Web application testing and exploitation basics
- Active Directory and Windows security
- Wi-Fi security and wireless attack paths
- AI security concepts and misuse cases
- Reporting, evidence handling, and prioritization
You should not treat these as isolated boxes. In practice, they overlap. For example, web exploitation may lead to credential exposure, which may lead to Active Directory abuse, which then creates artifacts you need to detect in logs.
Methodology: the domain that holds everything together
If you are weak in methodology, every technical domain becomes harder. A strong candidate follows a repeatable process instead of jumping randomly between tools.
Study how to:
- Scope the target and understand what is in bounds
- Enumerate first before attempting assumptions
- Record evidence so findings are traceable
- Form hypotheses based on artifacts, not guesses
- Validate findings with a second source when possible
- Prioritize high-value systems and indicators
Why this matters: defensive work is often messy. Logs are incomplete. Service banners are misleading. A tool may return too much noise. Good methodology keeps you from wasting time. For example, if you see multiple open services on a host, a structured analyst checks the easiest and most informative ones first, such as HTTP, SMB, LDAP, or RDP, depending on the context.
This is mostly a scenario-based topic. You can memorize the stages of a workflow, but you only improve by using the workflow repeatedly.
Enumeration: one of the highest-value practical skills
Enumeration is the foundation of almost every CDSA-style challenge. If you miss a service, a subdomain, a share, or a user list, your later analysis may collapse.
You should be comfortable enumerating:
- Ports and services on Linux and Windows targets
- HTTP content, directories, headers, cookies, and technologies
- SMB shares, permissions, and accessible files
- LDAP and Kerberos clues in domain environments
- DNS records, subdomains, and naming patterns
- Usernames, groups, and trust relationships where relevant
The reason enumeration matters so much is simple: analysts often fail because they stop at the first visible clue. Real targets contain layered evidence. A web page may leak employee names. Those names may map to domain users. An SMB share may hold configuration files. Those files may expose internal hostnames or credentials.
This is heavily scenario-based, though some command syntax and common service behaviors do need memorization.
Defensive analysis: logs, artifacts, and attacker behavior
This is the heart of the “defensive analyst” role. You need to read system and network evidence and decide what happened.
Study these areas closely:
- Windows event logs and the meaning of common event patterns
- Authentication events, failed logons, privilege use, account changes
- Web logs, status codes, user agents, suspicious requests
- Process execution artifacts and parent-child relationships
- Scheduled tasks, services, and persistence indicators
- Basic network traffic interpretation from captures or summaries
Do not just memorize event IDs without context. That is a common mistake. For example, knowing that an account was added to a privileged group matters more if you can also explain when it happened, from where, and what happened next. A useful analyst connects the chain.
This domain has both memorization and scenario-based parts. You should memorize common log sources, common event meanings, and basic attacker techniques. But your real score depends on interpretation. Can you spot a brute-force pattern? Can you tell whether a suspicious PowerShell command is likely reconnaissance, execution, or persistence?
Web exploitation: enough offense to think defensively
CDSA candidates do not need to become full-time web exploit developers, but they do need enough web security skill to recognize common vulnerabilities, verify impact, and understand what evidence they leave behind.
Focus on:
- Authentication flaws and session handling issues
- SQL injection basics and input validation failures
- File upload issues and path traversal
- Command injection and unsafe server-side execution
- Access control weaknesses such as IDOR-style issues
- Common web misconfigurations and exposed admin panels
The “why” here is practical. Defensive analysts often need to confirm whether suspicious web activity was harmless scanning or a successful exploit path. If you do not understand the attack, you will misread the logs. For example, repeated odd GET requests may just be broad scanning, but a well-formed POST request to a vulnerable endpoint may deserve immediate attention.
This domain is mostly scenario-based. Memorize common vulnerability categories and payload patterns, but spend more time tracing request-to-impact-to-log-artifact.
Active Directory: often the hardest domain for beginners
Many candidates struggle here because Active Directory combines networking, authentication, permissions, and Windows internals. You do not need to know everything, but you do need a working map of how AD abuse happens.
Study these topics in a practical way:
- Users, groups, computers, and domain structure
- Kerberos basics and ticket-related abuse concepts
- SMB, LDAP, WinRM, and RDP as common access paths
- Privilege escalation routes through misconfigurations
- Share permissions and file exposure
- Common lateral movement clues
Why this domain matters: many real intrusions become far more serious once a domain account is compromised. A weakly protected service account, exposed script, or misconfigured share can turn a small foothold into broad access.
For study purposes, separate this domain into two parts. First, memorize the architecture: what AD components do and how they relate. Second, practice chains: enumerate users, find exposure, test permissions, and interpret authentication evidence. Without that second part, the first part stays abstract.
Wi-Fi security: smaller domain, easy points if reviewed properly
Wireless topics are often less broad than AD or web, which makes them a good area to secure with focused revision.
Review:
- Wi-Fi authentication types and their differences
- WEP, WPA, WPA2, WPA3 at a practical level
- Handshake capture concepts
- Evil twin and rogue AP ideas
- Weak passphrase risk and credential exposure
- Common wireless indicators in assessments
This is one of the more memorization-friendly domains, but you should still understand how attacks unfold. For example, a weak pre-shared key is not just “bad” in theory. It matters because offline cracking may become possible after a valid capture.
AI security: what to review without overcomplicating it
AI security can sound vague, so keep it grounded. You are not expected to become a machine learning researcher. You should understand where AI systems create security risk and how those risks appear in assessments.
Focus on:
- Prompt injection concepts
- Data leakage through AI workflows
- Unsafe plugin or tool integrations
- Excessive trust in model output
- Access control around AI features and APIs
- Validation and monitoring needs
Why this matters: AI-enabled features often sit inside normal apps and inherit the same old security problems, plus a few new ones. If an internal chatbot can expose sensitive documents because of weak retrieval controls, that is still a security failure you need to reason through.
This domain is a mix, but lean toward conceptual understanding rather than deep exploitation.
How to separate memorization topics from scenario-based topics
A smart study plan does not treat all domains the same. Some topics require recall. Others require decision-making.
Mainly memorization topics:
- Common protocol purposes
- Important event IDs and log sources
- Wi-Fi standards and authentication differences
- Basic AD terminology
- Common web vulnerability categories
Mainly scenario-based topics:
- Enumeration workflow
- Log interpretation
- Pivoting from one clue to another
- Prioritizing findings
- Building attack or incident timelines
- Determining exploitability or impact
A good rule: if the topic answers “what is this?” it is often memorization. If it answers “what should I do next?” it is scenario-based.
Topic-by-topic study advice that actually works
- For methodology: write your own checklist and use it in every lab. This builds consistency.
- For enumeration: repeat the same service types across different targets until the first five steps become automatic.
- For defensive analysis: practice explaining findings out loud. If you cannot explain why a log entry matters, you do not know it well enough.
- For web: trace one vulnerability from request to execution to artifact. That teaches both offense and detection.
- For AD: draw small attack chains on paper. Example: leaked username list to password spray to share access to privilege escalation clue.
- For Wi-Fi: make a one-page comparison sheet of wireless protocols, attack preconditions, and likely outcomes.
- For AI security: collect a few realistic abuse stories and identify the control failure in each one.
Recommended review order before practice tests
Do not review in random order. Start with the domains that support everything else.
- Methodology
- Enumeration
- Defensive analysis and logs
- Web exploitation basics
- Active Directory
- Wi-Fi
- AI security
- Final mixed review and timed scenarios
This order works because methodology and enumeration affect every other domain. If those are weak, you will struggle even in topics you “know.” AD is placed after web and logs because it becomes easier once you are already comfortable following evidence and access paths.
How to convert each domain into practice sessions
Each study domain should turn into a short, repeatable practice block. That prevents passive review.
- Methodology session: take one target and document your workflow from first contact to prioritized findings.
- Enumeration session: pick two services only, such as SMB and HTTP, and enumerate them deeply instead of broadly.
- Defensive analysis session: review sample logs and build a timeline of suspicious activity.
- Web session: identify one flaw, confirm the effect, then state what evidence defenders would see.
- AD session: enumerate a domain environment and map possible privilege paths without rushing to exploitation.
- Wi-Fi session: compare attack preconditions for each security standard and explain detection opportunities.
- AI security session: analyze one AI feature and list its trust boundaries, input risks, and data exposure risks.
If you want a score-based checkpoint after review, use a focused practice resource such as this HTB CDSA practice test. Use it after domain review, not before. The goal is to measure retention and weak spots, not to replace hands-on study.
How to track weak areas without guessing
After each lab, scenario, or practice test, log mistakes in three columns:
- Knowledge gap: you did not know the concept
- Recognition gap: you knew it but failed to spot it
- Process gap: you spotted it but chose the wrong next step
This matters because each weakness needs a different fix. A knowledge gap needs notes and review. A recognition gap needs more examples. A process gap needs repeated scenario practice.
For example, if you forgot what a protocol does, that is a knowledge gap. If you missed that SMB access could reveal useful files, that is a recognition gap. If you found the files but failed to follow the credential clue they contained, that is a process gap.
Mini FAQ
Which domains matter most?
Methodology, enumeration, defensive analysis, and AD usually give the biggest return. They show up across many scenarios and support the rest of the exam.
Should I memorize every event ID and attack type?
No. Memorize the high-value and frequently seen ones, then focus on context. The exam rewards interpretation more than raw recall.
Is web exploitation a major part of defensive prep?
Yes, because defensive analysts need to understand how attacks work to recognize successful exploitation and assess impact correctly.
How do I know if AD is my weak area?
If domain-based scenarios feel slow, confusing, or full of dead ends, AD is probably weak. This often shows up as trouble linking usernames, shares, authentication, and privilege relationships.
When should I start practice tests?
After one full review cycle and several hands-on sessions per major domain. Practice tests are best used to validate readiness, not to teach fundamentals from scratch.
Final takeaway
The best way to prepare for the HTB CDSA is to think like a working analyst, not a student cramming facts. Learn the common technologies. Memorize the items that save time. But spend most of your effort on scenario-based work: enumeration, interpretation, pivoting, and evidence-driven decisions. If you can move from clue to clue with a clear method, the domains start to connect, and the exam becomes much more manageable.
