Introduction

How to win CPTC! Based on howtowinccdc

None of this is official advice and is entirely based on what I've heard as a competitor or on what I've read online.

Please feel free to contribute on GitHub!

What is CPTC?

See here for an official description

The Collegiate Penetration Testing Competition (CPTC) is an event in which teams are hired to do a simulated penetration testing engagement that includes:

1. Pentesting a network
2. Doing business injects
3. Writing a report
4. Giving a presentation (if you attend finals)

Every year, a new theme is chosen along with a fictional organization that will be pentested.

If you'd like to hear about CPTC from other people, check out the blogs page!

Reporting

Before and after figuring out what you want in your report, I highly recommend looking at these public reports to get inspiration for formatting and findings.

How to Write a Good Report

This section will cover general reporting tips that will help you write an outstanding report.

I've almost entirely based this section on the BHIS Pentest Reporting course by BB King that is also available as a pay what you can course from Antisyphon Training.

General Tips

• Reporting should be done alongside the testing

  • RAYG: Report as you go.
  • This will make it easier to ensure your report is complete and that you won't forget anything when you do the report.

• It can be helpful to create a pre-written database of findings that you can use and modify during a pentest.

  • Many top firms do this to save time. It will make it easier to RAYG and will let your team refine findings over time.

• Keep a checklist as a reminder of what you need to get done in your report.

• You want to include what attacks did not work in a report.

  • That way, the company you're testing knows what you didn't test (what needs further testing) and they know what they're doing well.

• Do not say "includes but is not limited to" or similar. Make sure that your lists, especially when detailing vulns and inventory, are complete.

• Report should indicate that it is confidential (or whatever other labeling term the company uses)

Report Elements

• Include evidence of all findings

  • The evidence should make it not only easy to understand, but also hard to misunderstand.
    • The best way to do this is with screenshots.
    • Note that ambiguity is hard to avoid:
      • eg. If you type whoami to show root, that doesn't necessarily prove root, as it could only have euid of 0. Type root; id to prove that you are root.
  • Annotate screenshots with numbers, boxes, arrows (use flameshot)
    • Get a standard color used between everyone writing the report. This will make it look more professional.
    • All credentials (yes, even hashes) should be redacted.
    • Try to make sure everything in the screenshot is relevant and everything that is relevant is in the screenshot.
  • Be specific about every finding.
    • Explain exactly which resources under which permissions are vulnerable to what.
    • If you know something is true, explain how you know that it is true.
      • eg. instead of saying "this server is old", say "the http response header indicates that the server is old"

• Every finding must have a context behind it.

  • How does this finding relate to the org?

• Every finding needs to have a business impact. Will this fix require a lot of overhead? Will it cost a lot? Explain why a fix is necessary if it is.

• Reports (especially the findings) are generally read by security people.

  • Explain how problems are found so findings can be recreated.
  • This is crucial! If an org is trying to remediate the findings on their own, they have to know exactly how to check if the issues were fixed. It will also make a retest easier for you or any other testers in the future.

• For recommendations, include why they are so and who recommended them (links are preferable).

Visual Elements

• Ensure that fonts and colors are consistent. Font size in images should be similar of the font size that is used in the report.

• Preferably, screenshots will look consistent in terms of size, color, font, etc.

Tone

• In general, dismissive words like "simply", "small", "quickly" can make someone reading a report feel as if it is unimportant.

  • Reports that are more negative are less likely to get the company rehired to do a retest.
  • People may ignore any advice given when it is given with a tone that suggests the reporter feels superior to the person it is being read by.

• Do not brag. This can make the customer unhappy + prevent them from wanting to rehire you. Your skills should be proven by your report quality.

How to Generate Reports

• BHIS suggests using word as, even though it's annoying, it's the best in terms of macros + styles + sections + custom dictionary + spellcheck.

• With word you can have people work in separate documents and then Insert > Object > Text to insert other word docs into your main report doc.

• You can also use spellcheck as a way to quickly type big block of texts (shortcuts basically).

• Tools like LaTeX can also be used if you want more granular control of your template, but can make reporting a lot slower.

  • Some clients may also specifically request a Word doc.

• Tools like PlexTrac can make reporting, especially when collaborative, much easier, but are very expensive.

  • pwndoc is a great open-source alternative that works similarly to generate a word document based on findings.
  • Ghostwriter by SpecterOps is another fantastic open-source tool that works just as well.
  • SysReporter

How to Write a Good Report for CPTC

Writing a good report for CPTC should be about the same as writing a general report.

However, Dan Borges (Scoring), has written several blogs on what he believes to be critical in a pentest, which especially motivated teams may want to know to have a slight leg up on the other competition.

Thus, the majority of this section will be based on various posts on Dan Borges' Blog

Things to Do

• Clear TOC

• Executive Summary

  • Scope
    • Include a network topology below the scope
  • Overall Risk Summary
  • Summary of major Issues
  • Brief Narrative of test
  • High level remediation advice
    • Provide short and long-term advice
  • Successful security controls
    • Optional, but shows the client they're doing some things right
  • Compliance findings and guidance
    • If there is an MOU or SLA, describe if they are met as per the environment.
  • Methodologies, approaches, risk rating systems
    • Probably makes more sense in the appendix
    • This shows that there are standards being used. PTES is good bc it's standardized
    • Include a diagram of the methodology

• Technical Findings

  • Graphical summaries of findings at the top
    • Pie chart of vulns by criticality and category
  • Include the vuln, the systems vulnerable, the impact on the company, overall risk, detailed steps to test the vuln, suggested remediation, and links that may be useful
    • Risk: low, medium, high, critical, informational
      • Use CVSS
    • Scope: Items and systems impacted.
      • Can include assets, apps, paths in an app, systems in a process, services...
    • Description: Describe the vuln fully
      • Reference known CVEs and vulns
      • It can be useful to have pre-written vuln descriptions
    • Impact: Impact on the client in this environment specifically
    • Likelihood: Chance of an attack
      • Optional
      • Include elements of cvss score, complexity of attack, if there are available tools to make the attack easy
      • This can be part of impact
    • Steps to test: How the reader can verify the vuln
      • Include screenshots and steps to prove the vuln exist and also to make it obvious how to check for the vuln
    • Remediation: How to fix the vuln
      • Provide multiple options to remediate if possible - with tradeoffs explained
    • Additional links: Info about the vuln including CVE, exploit guides, open source code, and walkthroughs from detection and remediation

• Appendix

  • Methodologies
  • Tools used (including permalinks to specific github commit)

• In a retest:

  • Include a table that shows which vulns have been remediated
  • Even if smth has been remediated, still include remediation details

Things to do if you don't wanna look bad

• Order should be: Intro -> Executive Summary (incl. Conclusion)

• Make sure finding blocks are easily formatted w/ sections

• Stay away from speculating about a vulnerability. Everything should have evidence

Pentesting

How to Pentest

There are a ton of resources for learning. My favorite is TryHackMe, which is a cyberrange that plenty of rooms that will walk you through the entire process of an exercise and has more that will challenge you to do it on your own.

• For a more complete list of resources, take a look at the one on my GitHub: adamkadaban/CTFs

If you want to get serious about pentesting, I think the Practical Ethical Hacking Course by Heath Adams is amazing. You can pay for the course on the TCM security website or can get slightly older versions for free on YouTube, and sometimes on Udemy. This course aligns with a certification called the PNPT that, in my opinion, is much better than the OSCP while being much cheaper.

How to Practice for CPTC

Of course, cyberranges like HackTheBox, TryHackMe, and VulnLab are great for general practice and will build on your skills well.

However, if you and your team want more CPTC-specific practice, the CPTC VM images are available online: http://cptc.rit.edu

As of 2023, CPTC has included Cloud with AWS or Azure/Entra in its environment. Cloudfoxable, CloudGoat, AWSGoat, AzureGoat, and GCPGoat are fantastic resources for practicing here.

OSINT

OSINT, or open-source intelligence, is the first thing that you will do to start your pentest for CPTC.

This involves doing passive reconnaissance of the company that you've been hired to pentest.

• Note that doing brute-force enumeration of websites may get your team a warning and/or potentially disqualified.

All information about the company is produced by the CPTC world team and is slowly published online as the competition gets closer. This means your team should be constantly reviewing previous discoveries and looking for more.

• In past years, teams have recorded their OSINT with Maltego, which can make things easier to keep track of and can also help with describing OSINT in a report.

I have a (partially redacted) set of slides on OSINT basics that covers tools and techniques that may be useful to you: UFSIT OSINT Slides

Injects

CPTC injects involve interactions that could occur during an engagement.

For example:

• Tell the company what pentesting standard you are using
• Respond to an email asking about relevant compliance standards
• Explain to the client how to make passwords better
• Weigh in on if the client should incorporate MFA
• Make a social engineering phone call (This happened!)
• Make a phishing site for harvesting credentials
• Send phishing mail via an exe or maldoc
• Create a network diagram
• Leak secrets from an LLM

It is also possible to have injects that involve physical attacks like that of lockpicking.

When doing an inject, make sure to remain in character and be professional.

You should be responding just as an actual pentesting firm would.

• If you are asked to disclose info about other clients/competitors or are asked to do something immoral (I'm unaware if these have ever been actual injects), you should decline and explain why.

If you do not know the answer to something, do not pretend that you do and try your best to answer properly.

• In the same vein, take accountability for something if you made a mistake.

Educational Events

This section seems to primarily be scored in the final round and essentially involves scoring a team's ability to be responsible when pentesting.

• Note that it is still possible to get deducted points for incidents in regional events

When pentesting for CPTC, you can't treat the network like any random HackTheBox. This means no changing a user's password, no brute-forcing, no exfiltrating sensitive data, etc.

Here are some things that have been scored (as negative points) in the past:

• Running dangerous exploits without knowing what they do
• Brute-forcing accounts and causing account lockout
• Sending an inappropriate phishing email
• Overloading ICS or other systems to cause a denial of service
• Pasting sensitive info into websites like ChatGPT (even static ones like cyberchef)

Some things to keep in mind:

• If you make a mistake, own up to it ASAP.
• When you are told about a mistake, make sure to react appropriately and professionally.

It seems that if you respond appropriately to a mistake, you can earn back up to 95% of the points you would have lost.

Presentations

The CPTC presentations occur only in the final round and involves a team presenting a set of slides as well as the pentest report to the board. These presentations are 10 minutes and all members are required to speak.

Example Presentations

Global CPTC has a few years of examples of presentations made by the final teams: globalcptc/report_examples

There are also several videos of these presentations on their YouTube channel

These are excellent places to look if you want to get an idea of what the best teams do.

How to Make a Good Presentation for CPTC

This section is primarily based on this post by Dan Borges, but also includes some comments from myself.

• Remember that your presentation should always be appropriate for the person you are speaking to. Some people want a technical presentation and others want one that discusses business risks.

• The primary goal should be to highlight overall risk

  • Make sure to mention what steps can be taken to remediate any vulnerabilities found.
  • The more specific your advice is, the better. Make sure that all recommendations apply to the company you are pentesting and show the true impact in a way that is easy to understand.

• Dress appropriately for the audience.

• "Keep eye contact"

• Talk about issues in the retest as well as things that have been remediated successfully by the company.

• Most of the presentation should be about the key findings and suggested remediations

My Views on Presentations

The following are things that most winning teams seem to include in their presentations:

• Intro of the team
• Very short description of methodology + some blurb about being holistic
• Summary of vulnerabilities found as well as of how many vulnerabilities were remediated
• Discussion of key findings
• Compliance violations and recommendations (don't go overboard here)
• Short and Long-Term recommendations for remediating vulnerabilities
• A summary of all points at the end of the presentation
• Leave around 2 minutes for questions at the end
• Cite parts of the pentest (H.2 for 2nd High vuln) in the presentation)

Blogs

In order to centralize knowledge about the competition and to promote competitors and volunteers, this will serve as a record of blogposts from previous competitions