In this post, I want to share a guide based on my experience preparing for and passing the Hack The Box CJCA certification.

Throughout the post, I will talk about my preparation, the importance of practicing with a clear methodology, the role documentation plays, the defensive analysis side of the certification, and some mistakes worth avoiding before and during the exam.

---

My General Opinion About the Certification

In my opinion, CJCA is a very good starting point for those who want to begin developing a more complete view of cybersecurity, because it combines two worlds that are often studied separately: Red Team and Blue Team.

From an offensive perspective, it requires you to enumerate services, identify vulnerabilities, gain access, and escalate privileges. From a defensive perspective, it involves analyzing evidence, logs, and alerts to interpret suspicious activity and justify your conclusions.

The assessment is not presented simply as a collection of isolated challenges either. Its approach is closer to a practical scenario in which you need to understand the context, distinguish relevant information from noise, and connect findings to one another.

For that reason, I believe CJCA evaluates more than technical knowledge or the use of tools. It also tests your judgment, analytical ability, and the way you communicate your findings.

---

How to Prepare for the Certification

One of the most common questions before taking CJCA is whether the Hack The Box preparation path is enough to pass the certification.

Hack The Box requires completing its preparation path and, in my opinion, it provides a very solid foundation. The content begins with fundamental concepts and gradually progresses toward practical topics such as networking, Linux, Windows, enumeration, exploitation, WordPress, tool usage, and evidence analysis.

However, completing the content should not be the only goal. The path teaches us concepts and techniques, but we are responsible for turning that knowledge into a working methodology that can be applied to different scenarios.

What do I mean by methodology?

A methodology is a structured way of approaching an environment: a series of logical steps that helps us decide what to review, which questions to ask, how to interpret the results, and what action to take next. It is not a fixed recipe or a list of commands; it is a process that we can adapt as new information becomes available.

Imagine that we encounter a web service we have never seen before. Without a methodology, we might start running tools or testing vulnerabilities at random. With a methodology, however, we know how to build an investigation path even when the technology is unfamiliar.

We could begin with questions like these:

• What technology does the service use, and which version is it running?
• What information do the headers, cookies, source code, or error messages reveal?
• Are there directories, files, endpoints, or virtual hosts that we have not identified yet?
• Does the application expose usernames, roles, or authentication mechanisms?
• Does the official documentation mention default configurations or relevant behavior?
• Are there known vulnerabilities for that version, and are their conditions actually met?

The answers generate new hypotheses and determine the next step. If we identify a version, we research its documentation and known vulnerabilities. If we find an authentication panel, we look for users, exposed credentials, or default configurations. If we discover a new directory or endpoint, we analyze its purpose and the information it reveals. This allows us to stop acting at random and start making evidence-based decisions.

The same logic applies to the rest of the environment. During exploitation, we need to confirm that a vulnerability actually applies. During post-exploitation, we need to analyze permissions, sensitive information, and opportunities to expand access. Throughout the entire process, we must document our findings and connect them to one another.

That is why I recommend complementing the path with Easy Hack The Box machines, both Linux and Windows, or with similar labs. Their value lies not only in teaching us a new technique, but also in exposing us to different services, technologies, and errors so that we can practice this logical process repeatedly. The more scenarios we solve, the more natural it becomes to formulate questions, interpret results, and adapt our next steps.

At first, the methodology may feel like a rigid checklist: scan ports, enumerate services, research technologies, validate vulnerabilities, review permissions, and document findings. With practice, it stops being a list we need to remember and becomes a natural way of investigating.

In the end, preparing for CJCA is not about memorizing commands or answers, but about learning how to investigate, correlate information, and build an organized way to solve problems.

---

Recommended Machines for Practice

The following machines can serve as a starting point for putting the concepts from the path into practice. I do not recommend them because they reproduce the exam or necessarily share its attack vectors, but because they provide accessible scenarios in which we can test our analysis process.

Linux	Windows
Lame	Return
Broker	Legacy
Cap	Blue
Keeper	Devel
Blocky	Optimum
Backdoor	Bastion
Base
Postman
Busqueda
CodePartTwo
Editorial

My recommendation is to try solving each machine on your own and keep a record of what you test. Before looking for help, review your results, research the technologies you identified, formulate new hypotheses, and make sure you have exhausted the reasonable investigation paths. The goal is to reach your actual limit, not to give up at the first obstacle.

Consulting a video, writeup, or guide after making that effort is not a bad thing. In fact, it can become one of the best ways to improve our methodology if we do it with the right objective. We should not simply look for the command that solves the machine, but identify why our process did not lead us to that point.

When comparing our approach with the solution, we can ask questions such as:

• What information was available that we did not take into account?
• Which service or feature did we fail to enumerate thoroughly enough?
• Did we formulate an incorrect hypothesis or misinterpret a result?
• Was there another technique for enumerating that service that we did not know?
• Were we missing technical knowledge, or did we simply skip a step in our process?

The answers tell us what we need to reinforce. If we discover a new way to enumerate a service, we document it and add it to our notes. If we overlooked an important piece of evidence, we review why we failed to recognize it. If the problem was an unfamiliar concept, we return to study it and then try to reproduce the solution without relying on the guide. This turns the writeup from a source of answers into a feedback tool.

The Easy machine catalog on Hack The Box, both Linux and Windows, is quite broad. However, I think it is important not to move too far away from the scope of the preparation path.

For example, if the path does not go deep into Active Directory, spending a significant part of your preparation on AD environments should not be a specific priority for CJCA. That knowledge can be valuable for your overall growth, but it is better to prioritize the topics and skills that are actually within the scope of the certification first.

This is not a definitive list either. We can practice with other machines and labs as long as we do so intentionally, analyze our mistakes, and use each obstacle to strengthen our working process.

---

Key Topics Worth Reinforcing

Linux Permissions

In addition to practicing machines, I also recommend reinforcing some concepts that often appear in a practical way during preparation. One of them is understanding Linux permissions well, especially when working with files and directories.

Sometimes it is not enough to know that a file exists. We also need to understand what permissions we have over each part of the path. In Linux, permissions do not work the same way for files as they do for directories. For example, on a directory, the read permission allows you to list its contents, but the execute permission allows you to traverse it if you know the exact name of the file or subdirectory.

This is important because, in certain scenarios, you may not be able to list a directory with ls, but you may still be able to access a file if you know the full path and have the necessary permissions to traverse the previous directories.

Directory permission	What it allows
r read	Allows you to see the names inside the directory, as long as the necessary permissions to access them also exist.
w write	Allows you to create, delete, or rename files inside the directory, usually together with x.
x execute	Allows you to traverse the directory and access internal elements if you know their exact name.

That is why, during enumeration, we should not only ask ourselves “what files exist?”, but also “what paths do we know?”, “what permissions do we have on each directory?”, and “what information could we read if we find a valid path?”.

This kind of detail helps a lot when building methodology. It is not about memorizing a specific path or an isolated technique, but about understanding how the operating system reasons and how we can validate our hypotheses in an organized way. In a practical exam, that difference can be key: many times progress does not come from running more tools, but from correctly interpreting permissions, paths, users, groups, and accessible files.

The Post-Exploitation Mindset

Post-exploitation is not only about obtaining a flag. It also involves identifying which other elements of the system could be useful or relevant to the penetration test. We need to remember that we are not dealing with isolated machines, but with a simulation of a security assessment within a company.

This shift in mindset is important because it forces us to look beyond a user or root flag. Imagine gaining access to an external system during a real penetration test: you would not search for a flag. You would look for stored credentials, files containing sensitive information, system logs, or anything else that could provide access to additional services and systems. There are no flags in a real assessment; there are findings, evidence, and potential paths for expanding access.

One practical way to guide this search is to filter for file extensions commonly associated with sensitive information.

Interesting File Extensions

Extension	What it may contain
.db	SQLite databases, web application data, and users.
.sqlite / .sqlite3	Users, hashes, sessions, and tokens.
.sql	MySQL or MariaDB dumps and potential credentials.
.bak	Database and configuration file backups.
.dump	PostgreSQL or other database exports.
.mdb	Microsoft Access databases.
.kdbx	KeePass databases.
.json	API keys, tokens, and configuration data.
.env	Passwords, tokens, and other application secrets.
.yml / .yaml	Docker, service, and application configurations or credentials.
.ini / .conf	Service configurations and potential credentials.
.properties	Java application configurations and passwords.
.p12 / .pfx	Digital certificates and private keys.

Understanding what each of these extensions represents opens new possibilities during post-exploitation. This does not mean assuming that every file will be useful, but recognizing which files deserve closer examination and analyzing their contents within the context of the environment.

Automated enumeration never replaces a well-executed manual review. However, different factors may cause us to overlook a file or directory. In those cases, performing a second pass with an enumeration tool can help us validate what we have already reviewed and identify items we may have missed initially.

For this task, I recommend Credential Hunting using its clean mode: Credential Hunting on GitHub

This is a fork that I have worked on and continue to update. Its purpose is to make it easier to find interesting files that may have gone unnoticed during manual enumeration, or to perform a quick review when we need to prioritize potential sources of credentials.

Post-Exploitation With Enumeration Tools

While searching for interesting files helps us locate credentials and sensitive information, automated enumeration tools provide a different perspective: they offer a broader view of the system and can connect configurations that might appear insignificant when reviewed in isolation.

These tools can review users, groups, permissions, processes, services, scheduled tasks, environment variables, configurations, and other elements associated with potential privilege escalation vectors in a matter of minutes. One of the best known is PEASS-ng, which includes scripts such as linpeas and winpeas to support enumeration on Linux and Windows.

You can review the project here: PEASS-ng on GitHub

Their main value is not limited to finding more information, but also lies in presenting the environment from a different perspective. For example, a tool may highlight the relationship between a service running with elevated privileges, a modifiable configuration file, and a path controlled by our user. Each element might go unnoticed on its own, but together they could reveal a privilege escalation opportunity.

This does not mean that we should run the tool and follow every result automatically. Its output should be treated as a source of hypotheses: first, we identify the findings that appear relevant; then, we validate them manually; and finally, we determine whether they actually represent an exploitable vector within the context of the system.

Practicing with PEASS-ng also helps us recognize common patterns and understand what comprehensive enumeration looks for. Over time, these patterns strengthen our manual methodology and allow us to evaluate both what the tool highlights and what it may have missed with better judgment.

---

What About the Blue Team Part?

In my case, I have to be honest: outside of the content included in the preparation path, I did not do too much additional practice focused specifically on Blue Team.

However, if you feel this is your weakest area, or if you simply want to arrive with more confidence, Hack The Box Sherlocks or similar labs can help you a lot. These types of challenges focus on evidence analysis, incident investigation, event correlation, and building conclusions from logs.

This is important because in the Blue Team section, it is not enough to see an alert and mark it as True Positive or False Positive. You also need to explain why you reached that conclusion.

For example, imagine an alert related to multiple failed login attempts. A very basic way to justify it would be:

Five failed login attempts were observed, followed by a successful login for the same user.

The problem with that explanation is that, by itself, it does not say much. It could be a user who forgot their password, a typo, or a legitimate attempt. The key is to investigate what happened before and after that successful login.

A more complete explanation would be:

Five failed login attempts were observed against a privileged account from the same IP address. Minutes later, a successful login was recorded from that same IP. After the access, reconnaissance command execution, file downloads to a temporary directory, and execution of a privilege escalation-related tool such as JuicyPotato were identified. This sequence allows us to conclude that it was not only a set of isolated failed attempts, but a possible intrusion followed by post-exploitation activity.

The difference between both examples is important. In the first one, we are only mentioning isolated events. In the second one, we are building a timeline: failed attempts, successful access, command execution, tool download, and possible privilege escalation.

That type of analysis is much more useful for a report, because it does not only explain what happened, but also why those events are related to one another and how they support the conclusion.

That is why, when practicing Blue Team, my recommendation is not to stop at the initial alert. Try to answer questions such as:

• Which user was involved?
• From which IP did the activity occur?
• Was the login successful after several failures?
• What processes were executed afterward?
• Were any files downloaded?
• Were suspicious directories such as /tmp, Temp, or Public used?
• Does the activity match reconnaissance, persistence, privilege escalation, or lateral movement?

In short, for the Blue Team section, you do not need to memorize every possible alert. What matters is learning how to investigate, build a logical line of analysis, and justify your conclusions with clear evidence.

If you want to reinforce this area through hands-on practice, the Additional Resources section includes a lab I created specifically for practicing alert analysis, log investigation, and evidence-based conclusions.

---

Mistakes You Should Avoid

After going through the preparation process and taking the exam, there are several mistakes that I think are important to mention. Some of them I made directly, while others I identified during preparation or while building the report.

The purpose of this section is not to scare you, but to help you avoid problems that can affect your performance, especially when time is limited and you need to maintain an organized workflow.

Mistake 1: Not Reading the Instructions Carefully

When you start the exam, you will receive important instructions about the scope, objectives, and the way you should approach the assessment.

One of my main mistakes was not reading them carefully enough. I assumed I already knew where to start and began investigating a path that was not the priority at that moment.

It may seem like a minor detail, but in a practical certification, time is a very valuable resource. Spending several hours on the wrong investigation path can affect the rest of the exam.

My recommendation is simple: before running a single command, read the instructions completely, identify what they are asking for, and clearly define what your first objective should be.

Mistake 2: Not Documenting From Minute One

One of the best decisions I made was documenting everything from the very beginning.

In my case, I used Obsidian as my main organization tool. The idea was to build my report while taking the exam, so that later I would already have a large part of the work done when completing the final template in SysReptor.

Every time I obtained a relevant result, I immediately added:

• The command executed.
• The result obtained.
• The corresponding evidence or screenshot.
• Important observations.
• Possible next steps.

This allowed me to keep a clear history of every action performed and avoid having to reconstruct processes hours later.

I also recommend reviewing Bruno Rocha Moura’s resource about CPTS reports: Read the CPTS report resource

Although it is focused on CPTS, many of the documentation, structure, and evidence presentation principles also apply to CJCA. It can serve as an excellent reference to understand how to present findings in a clear, organized, and professional way.

Mistake 3: Relying Too Much on Memory

After several hours of exam time, multiple hosts, commands, credentials, events, and findings, it is very easy to forget important details.

What seems obvious when you find it can be difficult to remember when writing the report. That is why I do not recommend depending on memory.

To avoid this, I organized my notes in Obsidian by creating one folder for each machine or exam section. There, I saved the relevant information as I found it.

For example:

• Users.
• Passwords.
• IP addresses.
• Flags.
• Important files.
• Interesting locations.
• Credentials.
• Relevant commands.
• Quick notes about possible investigation paths.

This allowed me to centralize the important information and have it available when I needed it, without depending on remembering every detail at the end.

Mistake 4: Not Giving the Report the Importance It Deserves

If there is one thing I would like to emphasize about this certification, it is the importance of the report.

It is easy to fall into the idea that finding the flags is the most important thing, but the report is the real evidence of all the work performed during the exam.

Think of the report as the way you are going to demonstrate your findings. It is not enough to reach the final result; you also need to explain how you got there.

During the exam, I tried to ask myself these questions:

How would I explain this step to someone else?

What would an evaluator need to see in order to understand how I got here?

A flag by itself means very little if there is no logical line explaining the process. What truly adds value is demonstrating how you investigated, what decisions you made, what evidence you found, and why you reached a specific conclusion.

If you find relevant information, gain access to a system, or identify suspicious activity, you must be able to explain what you did, what you observed, and how that evidence supports your finding.

That is why I recommend thinking about the report from the first minute of the exam, and not only when it is time to write it. The better documented your process is, the easier it will be to build a clear and solid narrative.

Mistake 5: Not Taking Enough Screenshots

One of the recommendations I received in the exam feedback was to take more screenshots.

During the exam, I felt that I had enough evidence, but when writing the report, I realized that in some parts the narrative felt incomplete. I knew how I had reached certain findings, but I was missing screenshots to better demonstrate the process.

Because of that, I had to go back and collect additional evidence from points that I had not documented as well as I thought.

My recommendation is simple: document every relevant step. If you are unsure whether a screenshot is worth taking, it probably is.

It is better to have more evidence than you need than to discover at the end that you are missing an important screenshot to explain how you reached a finding.

---

Additional Resources

Additional Resource to Practice Blue Team

For those who want to practice this part with an approach closer to defensive analysis, I created a specific resource called CJCA: Blue Team Lab to Practice Alert Triage.

The lab is called Aurelius Blue Alert Lab and is designed to practice alert triage in Elastic/Kibana from a safe, synthetic, analysis-oriented environment. The scenario simulates Aurelius Labs, a fictional company where the analyst’s objective is to review a set of alerts, investigate the related logs, and classify them as True Positive or False Positive using concrete evidence.

The main idea is simple: events are loaded into Elastic, alerts are reviewed in Kibana, the associated logs are investigated, and each classification is justified based on what was observed.

You can review the lab here: CJCA: Blue Team Lab to Practice Alert Triage

---

Additional Resource to Practice Reporting

I created a resource focused specifically on how to report with a CJCA-oriented style. In this material, I explain the main parts a report should include, how to organize evidence, how to write findings clearly, and how to present the analysis without limiting yourself to only pasting commands or screenshots.

The resource also includes a practical example, which can serve as a reference to understand how to transform the information collected during practice into a more organized and useful report.

The idea is not to memorize a template, but to get used to documenting with intention: explaining what was done, what was found, why it matters, and how each conclusion was reached.

You can review the resource here: Guide to Creating a CJCA-Style Report

---

Conclusion

Overall, I consider CJCA to be a very interesting certification for those who want to develop practical skills and have a first experience with scenarios closer to a real environment.

What I liked the most about the certification is that it is not limited only to exploiting machines or finding flags. It also requires analyzing information, connecting evidence, justifying conclusions, and documenting findings clearly.

If I had to summarize what I learned during this experience, I would highlight several important points:

• Build your own methodology.
• Practice beyond the preparation path.
• Learn how to investigate and ask better questions.
• Document from the first minute.
• Do not underestimate the importance of the report.
• Think like an investigator, not just like someone looking for a flag.

In the end, CJCA does not only evaluate technical knowledge. It also tests the way you approach a problem, how you interpret the available information, how you connect different findings, and how you communicate your results.

My final recommendation is to prepare for the certification calmly, practice with intention, and give documentation a lot of importance. The more organized your process is during preparation and the exam, the easier it will be to build a solid report and truly demonstrate the work you performed.