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 the official overview for a full description.

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

1. Pentesting a network
2. Completing business injects
3. Writing a report
4. Delivering a presentation (at 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 deciding what to include in your report, it is worth reviewing these public reports for inspiration on formatting and findings.

How to Write a Good Report

This section covers general reporting tips for writing an outstanding report.

The majority of this section is based on the BHIS Pentest Reporting course by BB King, 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 helps ensure completeness and prevents details from being forgotten.

• 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.

• Include attacks that did not succeed in the report.

  • This lets the company know what was not tested (and may need further testing) as well as where their defenses are effective.

• 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 be easy to understand and difficult to misinterpret.
    • The best way to do this is with screenshots.
    • Note that ambiguity can be difficult to avoid:
      • e.g., running whoami to demonstrate root access does not necessarily prove full root privileges, as the process may only have an euid of 0. Running root; id provides stronger evidence.
  • Annotate screenshots with numbers, boxes, and arrows (tools like Flameshot work well).
    • Standardize annotation colors across all report contributors for a consistent, professional appearance.
    • 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 and to what.
    • If you assert something is true, explain how you verified it.
      • e.g., instead of "this server is old," write "the HTTP response header indicates that the server is running an outdated version."

• 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 typically read by security professionals.

  • Explain how problems were identified so that findings can be reproduced.
  • This is essential. If an organization is attempting to remediate findings independently, they need to know exactly how to verify whether the issues have been resolved. It also simplifies any future retests.

• For recommendations, include the rationale and cite 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

• Dismissive words like "simply," "small," or "quickly" can make the reader feel the issue is unimportant.

  • Reports with an overly negative tone are less likely to result in the firm being rehired for a retest.
  • Readers may disregard advice delivered with a tone that suggests the author feels superior.

• Do not brag. This can make the client uncomfortable and reduce the likelihood of being rehired. Let the report quality speak for itself.

How to Generate Reports

• BHIS recommends using Microsoft Word. Despite its drawbacks, it offers the best support for macros, styles, sections, custom dictionaries, and spellcheck.

• With Word, multiple authors can work in separate documents and then use Insert > Object > Text to merge them into the main report.

• Word's autocorrect can also be configured to expand shorthand into full text blocks, speeding up report writing.

• 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 strong open-source alternative that generates Word documents from findings.
  • Ghostwriter by SpecterOps is another well-regarded open-source option.
  • 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 blog posts on what he considers critical in a pentest report. Motivated teams may find these useful for gaining an edge over the 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 demonstrates that the engagement follows established standards. PTES is a good choice as it is well-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 something has been remediated, still include the remediation details

Common Mistakes to Avoid

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

• Ensure finding blocks are clearly formatted with distinct sections

• Avoid speculating about a vulnerability. Every claim should be backed by evidence.

Pentesting

How to Pentest

There are a ton of resources for learning. My favorite is TryHackMe, a cyberrange with plenty of rooms that will walk you through the entire process of an exercise and 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 brute-force enumeration of websites may result in a warning or potential disqualification.

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, 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

To centralize knowledge about the competition and highlight contributions from competitors and volunteers, below is a collection of blog posts from previous competitions.