Preface

It is important to note that while it was our first appearance in CPTC, we had quite a few advantages going in. First, our club is in possession of some very powerful servers that allowed us to build practice cyber ranges and set up previous competition infrastructure to get some solid practice on CPTC networks without even competing. Second, our school had fielded a CPTC team in the past(the year before I joined UCI), and I was in contact with the previous team captain who had already graduated. He provided us with a lot of advice on how to train the team, and some first-hand knowledge of what we could expect in the competition. Most importantly, I want to thank our mentor Ryan Krause, a Principal Security Consultant at NetSPI, another UCI alum who gave a guest lecture for our club on Penetration Testing. When we told him about CPTC, he was very excited to help our team out and provided us with a wealth of advice on training resources and how to improve in Penetration Testing.

When I first started off with CPTC, I was able to learn a lot about the competition from other people’s blogs. These blogs gave me a solid idea of the structure of the competition and a clear blueprint of how to prepare for it. I wanted to make this blog post to help others like me, who want to learn about how to get started with the competition, and to also provide a more technical overview of what you can expect.

Introduction

The Collegiate Penetration Testing Competition is an offensive security competition where students have to hack into a simulated business environment. The student teams will then document all of their findings and prepare a penetration testing report to deliver to the simulated business.

Each team will have up to 6 students in their team, with 2 alternates, and a faculty coach who will have to accompany them to the competition. The 2 alternates are there mostly for emergencies; if a main team member can’t make it to the competition, they can be replaced by the alternate.

I am the Captain of UCI’s CPTC team, along with my Co-Lead Drew Levy. Even though we started the CPTC team this year and had no prior experience with CPTC, we were able to achieve second place in the SoCal Regionals, and we were able to qualify for the global finals through the wildcard, ultimately winning the global finals!

Starting Fresh

This section is intended to provide a basic overview of the competition structure for new teams who are starting out with CPTC.

To start off, you will want to join the official CPTC discord. Here, you can talk to the organizers and fellow competitors as well as staying up to date on competition news.

There are 3 main levels to the competition structure. To participate in the competition, teams must first register by filling out a Vendor Security Assessment (VSA) form and submitting it into the cp.tc ticketing portal. You will want to keep a close eye on the discord for when they open the registration, and want to register as soon as possible to guarantee a spot in your regionals, as they will prefer whoever registers first. The VSA form is fairly simple to fill out, it is mostly Yes or No questions which will hint to you what you need to prepare on. A sample question would be “Does your organization have experience performing Penetration Testing Services for environments leveraging containerization?” basically hinting that you will see containers in the competition. At the bottom, they give you a chance to ask a question to the simulated company. they will then compile all of these questions together and release the answers to all of them before the regionals.

After you register, you will be able to compete in the regionals in person. This is a 1 day event, where you will conduct an on-site penetration test of the simulated business from 10:00 AM till 6:00 PM. Afterwards, you will have until 11:59 PM to finish and submit your penetration testing report using all the findings from the on-site test. The winners from each region will then advance to the global finals. There is also a wildcard round where the top 5 teams that did not achieve first place will also be invited to compete in the global finals.

The global finals is a 2 day event where the teams will compete in RIT. The event will feature the same business as in regionals, but with added security along with more scope (think more machines, harder to hack).

CPTC vs. HackTheBox

CPTC is easy. This is something I did not realize until I rebuilt the previous competition networks and saw how easy it was to hack into them. Going into CPTC, I had a background in HackTheBox (HTB) and Capture the Flag (CTF). If you are from a similar background, and you are at least at an intermediate level in hacking, you will find it very easy to hack into the network. Most of the vulnerabilities are very easy to identify and exploit compared to an HTB machine. I would still recommend doing HTB and CTFs to keep up your skills, but you should definitely expect it to be easier than an easy level HackTheBox machine. However, to compensate for the lack of technical difficulty, CPTC makes students think in the perspective of a real consultant. This is not about just getting to root in any way possible and printing out root.txt anymore. Instead, you are incentivized to look for as many vulnerabilities as possible without causing any disruptions to the business. In HTB, there will usually be one or two ways into the machine, but in CPTC, there might not even be a way to get a shell, but instead there could be 5 or 6 different website related vulnerabilities that you will need to find and report.

To succeed, I would say the captain should be at a level where they can do all of the Easy and Medium level machines on HTB. The other members could be at a lower level, but they should be able to at least be able to do easy level machines on their own.

Preparation

We first decided to create a CPTC team in April, halfway through our Spring quarter. From then, we designed a basic, but comprehensive training and tryouts regimen derived from Cal Poly Pomona’s cybersecurity club. Our training/tryouts lasted until the start of summer, where we finalized our team roster and began to prep the team. Over summer, we focused on maximizing our technical skills in Web Application and Active Directory exploitation. Afterwards, once our Fall Quarter started, we began to prepare for the actual competition, focusing on mock competitions and improving our report writing skills.

Creating the Team

Before I talk about how we went about creating our team, I highly recommend reading this blog post: https://nosecurity.blog/cptcGuide, as we used it as a blueprint when we first started out.

To fill out the rest of our roster, we held a short training bootcamp to teach our club members the basics of penetration testing, then held a tryouts and picked the best members from that. We took a lot of inspiration from Cal Poly Pomona’s bootcamp https://cysec.team/bootcamps/ when designing our training regimen.

A basic outline of our training can be found below:

Week 0: Intro to CPTC

Week 1: Enumeration

Week 2: Web Hacking

Week 3: Active Directory

Week 4: Privilege Escalation

Week 5/6: Tryouts

We started our CPTC training halfway through our Spring quarter, so our tryouts occurred during the end of the school year, consisting of our finals week and the first week of summer. Each week, we would provide a short lecture explaining the basics of the topic being covered, then we would switch to a live demo where we would hack into some machines that we created, with our trainees following along. We would then assign homework in the form of TryHackMe rooms which they would then complete and submit a writeup.

Since we didn’t have a lot of time for our training, we had to spread thin and try to cover the full breadth of the skills needed for CPTC while not going too in-depth. For example, in the Active Directory week, we only covered AS-REP Roasting, Kerberoasting, and Pass the Hash attacks. We would have them dip their toes in each field so they would have a basic all round understanding.

Our tryouts consisted of 3 linux web machines and 1 active directory machine that the trainees had to get root in. Here, we differed from Cal Poly Pomona’s tryouts methodology, where they had a tryouts that lasted a day where people would compete in teams in person, our tryouts lasted two weeks, and every trainee competed individually. This is because we were trying to assess different skills, while the short in person tryouts would assess trainees based on their team-working skills, ours focused on assessing trainees by their individual technical skills. Since our tryouts lasted for much longer, we could make the machines more difficult to hack into, requiring a lot of research and problem solving from our trainees. For example, we didn’t teach them anything about how to use bloodhound to elevate privileges in Active Directory, but the tryouts required them to learn about bloodhound, set it up on their own, and figure out how to use it to become Administrator on the Active Directory System. Of course, we didn’t leave the trainees out to deal with everything on their own, we had them update us on any progress they made, and gave them hints whenever they were stuck.

After they got root on all of the machines, they then had to make a small penetration test report where they would highlight the vulnerabilities they found, and how to remediate them. This report, alongside their performance in the tryouts determined who would make the team.

Online Technical Training

Once we got our team together, we had to start training more in-depth. Our trainees still only had a very basic knowledge of penetration testing, so we had to really work on our technical skills. Our online training was structured with two online meetings every week where we would work on some TryHackMe room or HackTheBox machine together, and they would have to complete modules in the HackTheBox Academy Penetration Tester path and PortSwigger Academy asynchronously to build up their skills. We were able to get cheap student discounts on HTB Academy for only $8/month.

The point of doing the machines together was to practice working together on hacking something, building team chemistry while also allowing me to assess the team and determine who was performing well and who was falling behind. Whenever I found someone fall behind, I would reach out to them privately to find out what’s going on, and encourage them to start grinding more to catch up. By the end of summer, the team had mostly completed the Penetration Testing path in HTB, and were ready for the second phase of training, where we practiced for the actual competition once school started again in the fall quarter.

In-Person CPTC training

During our in-person training, I focused on two things: mock competitions and report writing. I used the archived networks from http://cptc.rit.edu/ to build two mock networks (CPTC8 and CPTC9) for us to practice on (guide coming soon). Our team would decide on a weekend to get together and grind out the whole network together while documenting our steps, preparing for the real CPTC experience. In addition to those, I also set up numerous mini-mocks for us to practice on, including the Game of Active Directory (GOAD) which features a massive trove of active directory vulnerabilities for us to practice exploiting. While we used GOAD to practice windows exploitation, we still completed HackTheBox machines and CTFs to practice website exploitation together.

In addition to mocks, we practiced a lot of report writing. First, I made the team read through the past reports from CPTC8 and CPTC9 from the CPTC report archive, and note down the vulnerabilities found, how they were reported, and their remediations to get an idea of what a vulnerability report should look like. We then took the top reports we liked and modeled a report template using them as inspiration. From there, I assigned the team members report writing homework, basically every week they had to take 5 vulnerabilities found from prior reports and create a vulnerability report for them. This allowed us to keep practicing writing reports, and as we started writing our own vulnerabilities, we found better improvements for our templates. By the end, we had about 150 pages worth of vulnerability reports written up as practice.

From our CPTC mock competitions, we realized that the machines in the past were extremely easy to exploit. For example, the Domain Controller in CPTC9 was vulnerable to common exploits such as EternalBlue and ZeroLogon, while the windows machines in CPTC8 featured administrative users with blank passwords. The web applications were no better, as they were vulnerable to basic web exploits such as common XSS or SQL injection. Furthermore, there were numerous vulnerabilities we could easily find just by exploring the websites, like a Jellyfin application that allowed users to log in as administrator just by clicking on the Jellyfin logo in the login panel. Due to our mocks going very well, we were very confident with our technical skills going into the CPTC11 regionals.

Before regionals, we were provided with some information on the regionals. CPTC 11 was to be set on a Cruise Line called “All Ports Tours” or APT for short (A joke on the commonly known Advanced Persistent Threat acronym). A few weeks before the competition, we were provided with a massive document featuring all of the VSA questions that all the registered teams asked, along with their answers. This document was a treasure trove of information, giving us hints on what to expect, and what they were looking for us to do. It even included an extremely blurry network diagram, which after a lot of analysis, we were able to pull some of the hostnames of the machines and got a rough idea of the number of machines we could expect in the regionals!

Regionals Experience

Going into regionals, our team was structured as follows: 2 people on windows, 3 people on web, and me working as the main lead, keeping track of what everyone was doing, handing out tasks to coordinate the team, and providing help wherever needed. I originally started off working on the websites, where we found a few promising vulnerabilities within the first hour, which definitely boosted our confidence. However, while we were steam rolling through the web applications, our windows team was struggling heavily, so I had to switch over to attacking the Active Directory systems that the network featured.

Unfortunately, CPTC11 did not follow suit with the previous CPTC8 and CPTC9 networks, as none of the basic exploits worked on the Active Directory systems. Due to the previous networks being so easy, our Windows team had grown complacent and did not grind Active Directory enough, so I had to help them with it. We ended up finding some informative vulnerabilities, but nothing that could give us access. We were stuck for a while, until one of our web members was able to break into an AI chat application, and found leftover knowledge that was provided to the LLM which included a user credential! We immediately tried these credentials on the domain controller and got a hit! Using this foothold, we were able to access a domain joined machine as the Administrator user and pwned a machine completely! We were also able to get access to a private SMB share on another domain-joined machine, where we learnt about a lot of shady business practices, to say the least. Along the way, we were able to find more and more valid credentials, but ultimately, we were not able to elevate our privileges to that of a Domain Administrator.

In the end, we got second in the regionals, with Cal Poly Pomona taking first place. We had a bittersweet reaction, as we didn’t win, but getting second in our first time competing was a pretty solid achievement.

Regionals → Finals

Luckily, this was not all bad, as we were still qualified for the wildcard. After Regionals, we had the mindset that we should still prepare for the finals in case we made it through the wildcard. At first, we practiced very leisurely, doing the weekly HackTheBoxes and Capture the Flag competitions together. However, once we actually qualified for the global finals, our energy was reinvigorated, and we started practicing again with newfound determination.

In order to practice for the finals, I had 3 main tasks I wanted our team to accomplish: learn AWS pentesting, practice presentations, and become more skilled at Windows.

We learnt AWS through a few mini CTF platforms, including Wiz’s IAM Challenge, http://flaws.cloud/, and http://flaws2.cloud/. We also researched and practiced using multiple tools that could help with hacking AWS, including pacu and awspx. While we did learn a lot, it was ultimately not relevant to CPTC because there was no AWS environment in the finals.

To practice presentations, I had our super artistic member, Alex, whip up a really nice Presentation template for us to use. He went through all of the published presentations from CPTC10, along with the winners from the past few years, taking notes on every presentation, extracting the best elements from all of them to create our template. In this template, we wrote about our “best guess” of what vulnerabilities we thought we would see in the finals to minimize our work during the competition. I then assigned everyone to certain slides and had them all come up with a script and practice that script in their free time.

A basic outline of our slides is as follows:

1. Introduction: Introduces the team members and lays out the agenda.
2. Executive Summary: Talks about the number of vulnerabilities we found in the systems. Focus on keeping it very high level, and quantifying everything (put lots of numbers)
3. Business Impact: Explains how the identified vulnerabilities could affect the organization from a business perspective. We evaluated impact using the CIA triad, highlighting the most severe risks to confidentiality, integrity, and availability. Because CPTC11 modeled a cruise tour company, vulnerabilities affecting shipboard applications could have significant operational consequences. For example, exploitation of a critical system could disrupt ship operations, compromise passenger or crew data, or cause service outages, directly impacting safety, revenue, and the company’s reputation.
4. Objectives: Explains the “goals” that we had for the penetration test. This basically says that we looked for vulnerabilities, identified their impacts, and provided steps to reproduce and recommendations for how to patch the vulnerabiltiies
5. Scope: Talks about which machines of the network we attacked.
6. Strengths/Recommendations: Talks about what was secure, what wasn’t and what they should generally focus on to improve the security posture.

To strengthen our Windows expertise, I had the Windows team work through more advanced Hack The Box machines and complete a full clear of GOAD, following the entire walkthrough from start to finish. In addition, they developed custom Python tooling to streamline Windows penetration testing. This included building a wrapper around NetExec to automate vulnerability scanning, ADCS exploitation, Password spraying, and common Active Directory attack techniques such as ASREPRoasting and Kerberoasting.

In addition to all of this, we continued our weekly CTF competitions and HackTheBox machines.

Global Finals

We arrived at Rochester on Thursday morning to get settled in, as the organizers meet with the competitors in the hotel lounge in the evening. They provided us ID cards, some CPTC merch, and have us sign some documents attesting that we have read the rules of the competition.

As a last-minute surprise, they also provided us with Claude API tokens with a massive spending and rate limit (about $1000 of tokens per competitor, allowing us to run 12+ agents simultaneously)!!

There are quite a few pros and cons to a major change like this. At first, we were disheartened by this, as we thought that the introduction of powerful AI Agents could turn the competition into a vibe-hacking competition, removing the skill based aspect of the competition. However, this had given us a chance to use industry-standard agentic tooling for free, which was a massive opportunity. In those few days, I learnt a lot about agentic orchestration and workflows that I would have never been able to because of the massive cost of Claude API tokens. In the end, Claude was not able to really ruin the competition, as it wasn’t really able to find any new vulnerabilities (for us). In retrospect, I am very grateful for this learning opportunity, and I’m happy that there wasn’t any sizeable impact on the competition’s integrity.

Day 1

Going into the actual competition on Friday, we expected an AWS environment, along with some network segmentation. To our surprise, neither of these was there. Instead, the network consisted of the same machines as regionals, with major changes to functionality, making them harder to hack into, while creating brand new attack vectors in the process. For the first day, we elected not to use Claude and conduct our penetration test as we normally would.

During regionals, we found a Jellyfin application. We were able to get into the application easily using default credentials, but we didn’t know how to exploit the application and get a shell. Predicting that this app will show up again, one of our web members, Eddie, researched Jellyfin exploitation and discovered JellyPwn, a malicious plugin that can achieve RCE. This work paid off, as the same application reappeared in the finals network, and he was able to get a shell on this machine immediately.

This was a massive boost to our team morale. Soon after this, we found another app from regionals, a temperature control application with a hidden debug command that had command injection. They “tried” to patch out this injection vector by blocking certain characters like ; and whitespace, but we were able to bypass these mitigations by using the | operator, and the ${IFS} bash shell variable instead of whitespace to get another easy shell.

The next application was a room console, which had an exposed Traefik dashboard. During regionals, this had an admin endpoint, where they implemented their own version of basic HTTP auth, which conducted the authentication in Client Side, thus was easily bypassed. This time, they used actual HTTP auth, but leaked the hash. We vaguely remembered the password from regionals, but not entirely, and unfortunately, could not crack this hash on the first day.

Another application was a ship navigation application. During regionals, we decided to stay away from this application, as a mistake could cause a serious business impact. I guess that a lot of other teams did the same, so for the finals, they put this application in a test environment and let us run wild. This application had a massive amount of vulnerabilities, notable ones including a Keycloak server with default credentials, arbitrary file write, and local file inclusion, which could be chained with the file writing to gain RCE on the application.

The final web application that we attacked in the first day was a Penny AI chat, which had leaked its system prompt. We spent a lot of time prompting this application, and were able to get some documents that had a few credentials, but after spraying the passwords found, we didn’t get anywhere. After the competition, we learnt that the AI had a tool call which was vulnerable to SQL Injection. It also had a Mongo Express server, which we tried to brute force to no avail.

While we got quite a few vulnerabilities in websites, Windows land was an absolute nightmare. The Windows system was completely hardened. No exploits worked. We were able to gain access as a service account whose credentials we remembered from the regionals; however, we were not able to pivot from this user at all. We attempted to password spray all the credentials we remembered from regionals to no avail. The first day was completely miserable.

In Day 1, we got 3 shells on websites, and practically nothing of importance on Windows. By the end of the first day, we were informed that, like us, almost every team elected to not use Claude AI. In order to incentivize us to use it, we were told that there would be a special injection the next day, where we would send in 1 member to team up with 3 other people to work in a mini-hackathon, where they would develop some Agentic Orchestration workflows to streamline our penetration testing process.

After hearing this news, I had the team study up and practice with agentic orchestration that night. We built numerous agents to hack into websites and active directory systems, and planned to use them the next day to find all the missed vulnerabilities.

Day 2

On day 2, I had to make a decision on who to send for the hackathon. After seeing the situation on Windows, I guessed that the only way to move forward was by finding leaked Active Directory credentials in a web app. Putting all this together, I decided to send our Windows member to do the hackathon so that we could focus all of our efforts on the web application. In contrast, many of the other teams sent their web members to the hackathon to focus more on Active Directory. In retrospect, my decision to focus solely on websites was definitely the correct choice, as we later learnt that there was no vulnerability planted in the Active Directory systems. A lot of the other teams lost a critical member for a large amount of time, while we operated the same as we normally would on the web application side, which I believe was a critical factor in our success.

Now that we had fully embraced Agentic tooling, we were able to crack the hash that was found previously in the Traefik dashboard. We knew the general form of the password from the regional event, but forgot the actual password. We gave the Claude agent what we knew so far, and let it try generating variations of the base password, and to our elation, it was able to actually generate the correct mutation and found the password! We immediately rushed into the admin panel and found a diagnostic endpoint, which allowed us to write to any file on the system. While this was a Docker container, the host filesystem was mounted into the system, so we were able to plant an SSH key into the host and gain root access into the machine!

Moving on, our next application was a chat application where guests could talk to each other. This had two main vulnerabilities, as it used websockets to initiate chat actions, but did not utilize any authentication, so we could just create our own websocket commands to gain access to any user chats. It is also used https://github.com/wkhtmltopdf/wkhtmltopdfto generate PDF reports of chat histories, which is vulnerable to LFI.

Halfway through day 2, we had found almost every web vulnerability, but still no Active Directory credentials, which was very worrying to me. I had tried to use the Agentic Orchestration Tooling that I developed the previous night, but to my dismay, it couldn’t find anything either. My fears worsened when our neighboring team started to blast rock music..

To say the least, we were quite miserable, thinking that the neighboring team was celebrating after gaining access to the Active Directory systems, thinking that they were going to win. By the end of day 2, we were thoroughly disheartened and didn’t imagine that we could win. Our only hope was that we found enough web vulnerabilities to balance out our lack of findings in Windows.

We got back to our hotel room by 6:00 PM, and the report-writing grind began. Our report was due by 11:59 PM, and due to a lack of foresight, we didn’t start the report during the competition, which was an absolutely terrible decision. Due to a lot of issues with Microsoft Word, which is a horrible application to use when editing large documents, our progress was hampered significantly. We finished the report by 11:30 PM, but due to a lot of glitches in Word, we had to spend a lot of time fixing issues on a very non-responsive application with a deadline looming over us. To say the least, we hate Word. We were able to finish in the nick of time, submitting at 11:55 PM. While we did finish, our report still had some glitches caused by Word, including some tables being warped, and some random empty pages. By the end, I was very disappointed in the final product and didn’t think we stood any chance at winning the competition.

The next day, we gave our presentations and discovered that we won the competition.

Closing Thoughts