The CREST CCT INF is not the kind of exam you cram for in a long weekend. It tests how you think, how you work through uncertainty, and how well you apply core infrastructure testing skills under pressure. A good study plan does two things at once: it builds technical depth, and it builds habits you can repeat on exam day. The most reliable way to prepare is to set up a safe lab, work through weekly milestones, and track what you learn every day. This 60–90 day roadmap is designed for exactly that. It gives you a structure you can follow, but it also leaves room to slow down on weak areas or move faster where you already have experience.
What this study plan is designed to do
This plan focuses on four practical goals.
- Build a safe lab environment so you can test without risk.
- Set weekly skill milestones so progress is visible and measurable.
- Practice a repeatable methodology so you do not rely on luck or memory.
- Track notes and evidence daily so you learn from every session and improve your reporting discipline.
The reason this matters is simple. Many candidates know the tools, but they do not work in a structured way. In a practical assessment, structure saves time. It stops you from missing obvious findings, repeating dead-end steps, or forgetting evidence you need later.
Before day 1: build the right lab, not the biggest lab
Your lab does not need to be huge. It needs to be stable, safe, and realistic enough to practice infrastructure testing workflows.
A solid starting lab should include:
- An attacker box such as Kali or another Linux distribution with your core tools.
- One or two Windows hosts to practice authentication, SMB, RDP, PowerShell, local privilege issues, and basic Active Directory interaction.
- A Linux host for SSH, web services, file permissions, and service enumeration.
- A small Active Directory setup if possible, even just one domain controller and one joined workstation.
- A vulnerable web application only if it supports your broader infrastructure workflow. The focus here is infrastructure, not deep app testing.
- An isolated network using host-only or NAT networking so nothing leaks into your home or work environment.
Why keep the lab small at first? Because troubleshooting broken infrastructure is not the same as exam preparation. If snapshots fail, DNS breaks every other day, or your VMs fight for memory, you will waste hours on setup instead of skill-building.
Create snapshots at known-good points. Label them clearly. For example:
- Base install complete
- Domain configured
- Target services exposed
- Post-practice reset point
Also prepare a simple note system. This can be a folder structure plus a spreadsheet. If you have a lab milestone tracker spreadsheet, use it from the start. Track:
- Date
- Lab goal
- Hosts tested
- Techniques practiced
- Key commands
- Findings
- Evidence captured
- Mistakes made
- Next action
This might feel administrative, but it trains two exam-critical skills: disciplined note-taking and proof-based reporting.
The methodology you should repeat every week
Before getting into the weekly roadmap, lock in a simple testing method. Use the same flow every time you touch a target:
- Scope – What are you allowed to test?
- Enumerate – What is there? Hosts, ports, services, users, shares, versions, trust relationships.
- Prioritise – What looks most promising based on exposure, weak configuration, or likely impact?
- Test safely – Verify issues carefully. Do not jump to noisy or destructive actions.
- Escalate or pivot – If you gain access, what can you reach next?
- Capture evidence – Screenshots, terminal output, timestamps, affected host details.
- Write the finding – What is wrong, why it matters, how you proved it, and how to fix it.
The reason to follow the same sequence every week is that good methodology reduces stress. Under exam conditions, people often know what to do but forget the order. A repeatable process prevents mental drift.
Days 1–14: Week 1 and Week 2 build your foundation
Primary goal: make your lab usable and refresh core enumeration habits.
In the first two weeks, do not chase advanced attacks. Focus on visibility. You should be able to look at a host or subnet and build a clear picture of what exists and what stands out.
Week 1 milestones
- Build or clean your lab.
- Create snapshots and a folder structure for notes and evidence.
- Practice network discovery and port scanning on every host.
- Record service banners, versions, and likely attack paths.
- Write one short mock finding based only on weak exposure or poor service configuration.
Spend time understanding scan results, not just running tools. For example, if you see SMB, RDP, LDAP, Kerberos, and WinRM on one host, that likely points to a Windows server with domain-related value. If you see anonymous FTP or NFS exports, ask what data exposure might exist. The point is to move from raw output to reasoning.
Week 2 milestones
- Practice deeper enumeration on Windows and Linux services.
- Test SMB shares, users, groups, and basic access controls.
- Review SSH, scheduled tasks, services, cron jobs, and file permissions.
- Start a personal checklist for common infrastructure checks.
- Capture evidence neatly for every meaningful result.
By the end of week 2, you should have one important habit: every action should produce a note. If you tested null sessions and they failed, write that down. Negative results matter because they stop you from repeating work and help you explain your logic later.
Days 15–28: Week 3 and Week 4 focus on access and misconfiguration
Primary goal: get comfortable identifying and validating realistic weaknesses.
This stage is about common infrastructure issues. Not exotic edge cases. Think weak credentials in lab-safe scenarios, exposed shares, poor permissions, risky service settings, and trust mistakes.
Week 3 milestones
- Practice authentication testing in a safe and limited way.
- Review password policy clues, account exposure, and reusable credentials in the lab.
- Test share access and local misconfigurations on Windows hosts.
- Identify at least three issues and write short proof notes for each.
- Time-box each host so you do not over-focus on one path.
The key lesson here is judgement. Just because you can spend two hours squeezing one weak lead does not mean you should. In the exam, you need to recognise when a path is promising and when it is wasting time.
Week 4 milestones
- Work on Linux privilege and service misconfiguration checks.
- Review sudo rights, writable paths, weak service permissions, and exposed credentials in configs.
- Practice moving from low-privilege access to local privilege escalation in a controlled way.
- Write one full finding with remediation advice.
- Review your notes for gaps in evidence quality.
Do not only record that something worked. Record why it worked. For example, instead of writing “priv esc successful,” write “service binary path was writable by low-privilege user, allowing replacement and execution as a higher-privilege account.” That level of explanation shows understanding, and it makes reporting much easier.
Days 29–42: Week 5 and Week 6 add domain and pivoting practice
Primary goal: understand relationships between systems, not just single-host weaknesses.
Infrastructure testing becomes more valuable when you can connect findings across hosts. A share on one machine may expose credentials used elsewhere. A low-privilege account may allow broad read access in the domain. A management service may expose a path to lateral movement.
Week 5 milestones
- Enumerate your Active Directory lab carefully.
- Map users, groups, hosts, shares, and administrative relationships.
- Practice identifying where credentials or tokens may provide additional access.
- Document at least one lateral movement path in plain English.
- Create a simple diagram of trust or access relationships.
If your AD lab is small, that is fine. Even a small domain can teach the habit of relationship mapping. The value is in learning to ask: “If I have access here, what does that imply elsewhere?”
Week 6 milestones
- Practice pivoting or host-to-host movement inside the lab.
- Review remote administration channels such as SMB, WinRM, RDP, or SSH where appropriate.
- Test segmentation assumptions in your lab.
- Capture evidence that shows both the initial foothold and the follow-on access.
- Write one finding that explains business impact, not just technical detail.
This is where many candidates improve fast. They stop treating findings as isolated events. A local admin issue on a workstation matters more if it leads to wider administrative reach. That is the difference between “a bug” and “an exploitable weakness with operational impact.”
Days 43–56: Week 7 and Week 8 are for speed, reporting, and consistency
Primary goal: do solid work faster, with cleaner evidence and fewer missed steps.
At this point, you should already have the basics. Now you need to sharpen execution.
Week 7 milestones
- Run a timed mini-assessment across your lab.
- Give yourself a fixed window for enumeration, validation, escalation, and note review.
- Use only your checklist and your notes, not random browsing.
- Track where time was lost.
- Refine your workflow based on that review.
The value of a timed run is that it exposes hidden weaknesses. Maybe your scanning is fine, but your notes are chaotic. Maybe you identify issues quickly, but you fail to collect proof while the session is fresh. Those are solvable problems, but only if you notice them before the exam.
Week 8 milestones
- Write two or three full findings from your timed assessment.
- Keep them concise, factual, and remediation-focused.
- Check whether each finding answers four questions: what is wrong, how was it proven, why does it matter, and how should it be fixed?
- Clean up your checklists and command notes.
- Review your spreadsheet to identify weak skill areas.
If you need targeted practice at this stage, use a focused resource such as the CREST CCT INF practice test as part of your review workflow. Use it to identify gaps, not as a replacement for hands-on lab work. Practice questions can reveal weak theory or weak judgement, but only lab time builds operational skill.
Days 57–90: the extension phase for candidates who want a full 90-day plan
If you have 90 days rather than 60, use the extra month for refinement instead of adding chaos. More content is not always better. Better execution is better.
Week 9 milestones
- Repeat a full mock assessment with different hosts or reset conditions.
- Compare performance against your week 7 run.
- Measure speed, evidence quality, and number of complete findings.
Week 10 milestones
- Focus only on your weakest category.
- Examples: Windows enumeration, Linux privilege escalation, AD mapping, or report writing.
- Build short drills around that weakness and repeat them several times.
Week 11 milestones
- Run a no-panic assessment day.
- Use your exact exam-style workflow.
- No tool-hopping, no random experimentation, no changing note format halfway through.
Week 12 milestones
- Light review only.
- Re-read your checklists, top findings, and past mistakes.
- Stabilise your environment and rest your brain before exam week.
The reason for a lighter final week is that fatigue causes sloppy mistakes. You are better off reinforcing what already works than cramming new techniques you cannot apply cleanly.
What to track every day in your notes and milestone spreadsheet
Daily tracking should be simple enough that you actually do it. A good entry can be brief, but it should always help future you.
- Today’s target – host, subnet, or scenario
- What I expected to find – your starting hypothesis
- What I actually found – factual results only
- Evidence saved – screenshot names, output files, timestamps
- What slowed me down – missing command, weak note format, confusion about service behaviour
- One improvement for next session – something practical and small
This helps because progress in exam prep is often uneven. One day you may find several issues. Another day you may mostly discover that your process is weak. Both are useful if you write them down clearly.
Common mistakes that waste study time
- Overbuilding the lab. If your environment is too complex, you become a systems administrator instead of a candidate preparing for an assessment.
- Collecting tools instead of learning workflows. A smaller set of tools used well is far more valuable.
- Skipping reporting practice. Finding an issue is only half the job. You must explain and prove it.
- Not reviewing failed attempts. Failed tests teach you where your judgement or technique needs work.
- Studying without milestones. If you cannot measure progress, it is hard to improve deliberately.
These mistakes matter because they create a false sense of preparation. Busy is not the same as ready.
How to know the plan is working
By the end of the roadmap, you should notice a few clear changes:
- You enumerate new hosts in a consistent order without overthinking it.
- You recognise common infrastructure weaknesses faster.
- You collect evidence as you go, instead of trying to rebuild it later.
- You can explain attack paths in plain language.
- You write cleaner findings with practical remediation.
If those things are improving, the plan is doing its job. The goal is not to memorise every possible trick. The goal is to become methodical, observant, and reliable under time pressure.
Final thoughts
The best CREST CCT INF lab study plan is not the most intense one. It is the one you can follow consistently for 60 to 90 days. Keep the lab safe. Keep the milestones realistic. Repeat the same testing method until it feels natural. Track your work every day, even when a session feels unproductive. That discipline is what turns practice into exam readiness. If you can build a habit of careful enumeration, sensible validation, and evidence-first note-taking, you will be preparing in the way the assessment actually rewards.
