Hello, my name is Brian Pak, and I’m the CEO of Theori, an offensive cybersecurity company. These days, I spend more time on overall company management than on hacking itself. Still, whenever I have the chance, I participate in hacking competitions to keep my skills sharp. While I don’t solve challenges as frequently as I used to, I try not to lose touch with my identity as a researcher..
Recently, with the continuous rise in security incidents and breaches, the workload has been quite intense. As multiple requests often come in at the same time, I sometimes step in to provide hands-on technical support in addition to my management responsibilities. Although we have many highly skilled hackers internally, there are always moments in the field when we find ourselves short on hands.
Personally, I am deeply interested in how the rapid advancement of AI will impact cybersecurity. In particular, I place strong emphasis on how AI can be effectively leveraged to enhance security, and how AI itself should be protected.

I was first introduced to it during my freshman year of college, around 2007–2008. At the time, it was less about professional as we think of it today, and more about an opportunity to study security while testing our skills against one another, which is what drew me in. There weren’t many CTF competitions back then—if one was held every couple of months, it felt frequent.
On a regular basis, I would look for wargame challenges to study on my own. When a competition finally came around, I gave it everything I had, and once it was over, I found myself waiting eagerly for the next one. Because of that, each competition felt incredibly valuable to me. After every event, I carefully reviewed the challenges I was able to solve as well as those I couldn’t, and since this was before solutions were widely shared the way they are today, I remember spending a lot of time tracking down materials and teaching myself.

While many well-known competitions like DEF CON are team-based, the most memorable experience for me was an individual CTF. This was before the formation of Team PPP, the hacking team founded by students from Carnegie Mellon University, and it was less a formal competition than a kind of initiation or entry test.
After progressing through several stages of challenges, the final round brought participants together in an individual CTF where we competed head-to-head. Finishing first in that competition meant far more to me than simply ranking at the top. It was the moment when I first felt that “I could really do this”, and it also sparked the desire to take on bigger challenges—not alone, but as part of a team.
Looking back, that experience became the catalyst that pulled me deeper into CTFs and hacking competitions. I remember it as both the starting point of my competitive journey and a major turning point in my path as a hacker.

It varies from person to person, but like many beginners, I initially found system hacking incredibly appealing. The process of staring at a black terminal screen, inspecting memory, and using debugging tools to see firsthand how a machine operates felt almost glamorous. At that time, being good at pwnable challenges or cryptography in CTFs often led to standout results. Since there were relatively few people who could handle system hacking well, solving a single system-level challenge could be far more differentiating than solving several web problems.
Of course, this is partly a matter of personal preference and the era. But if I could go back and had only three months to study—specifically as preparation for a career or real-world work—I think my choice would be different. In that case, I would choose a web-focused curriculum.
Realistically, the number of web services today is overwhelming, and even applications that were once built natively are now increasingly implemented on top of web technologies. If I were to invest the same three months, understanding web vulnerabilities and attack techniques would be far more efficient in terms of applicability and long-term scalability. Of course, once you’re working in the field, whether it’s web or applications, you ultimately need a solid understanding of system hacking, networking, and operating systems.
However, when time is limited and the goal is to prepare for rapid entry into real-world work, web-focused learning that spans both the client side and the server side is the most practical and realistic choice.

I wanted to include challenges that connect more directly to real-world applications. Web security, in particular, is the area most closely tied to actual security incidents.
The web challenges included in this Problem Set are based on publicly disclosed CVEs as well as cases I encountered through assessments. That said, they’re not simple reproductions of existing CVEs. Instead, the focus was on embedding the underlying context into each challenge—why the vulnerability occurred in the first place and what kinds of mistakes led to it.
Even when a vulnerability has already been publicly disclosed, I believe that if you understand same mistakes keep happening and understanding the emerged patterns through solving challenge, you can internalize those lessons and use them to imagine entirely new attack scenarios. I saw these challenges as a good way to practice that kind of thinking.

Yes, I definitely believe that my experience with wargames and CTFs has had a lasting impact on my career. At the time, since I was still in school, solving wargames didn’t immediately lead into hands-on work. But looking back, I feel those experiences have continued to influence my work to this day.
Early wargame and CTF challenges were often closer to pure “puzzles” designed and meant to be solved. While there were challenges that helped you learn technical skills, a large portion leaned toward puzzles Some required you to infer the challenge setter’s intent, and others occasionally felt almost like riddle-based quizzes.
Around 2015, however, the landscape began to change. Challenge authors started building challenges based on real-world security incidents and vulnerabilities encountered in actual incidents. These weren’t just about highlighting that “a major incident occurred,” but about modeling what the fundamental root cause of the incident was and which vulnerability lay at its core, then turning that analysis into a challenge.
Solving these challenges required an understanding of current technology trends and modern attack techniques, and naturally, the problem-solving process itself began to mirror the way experts are expected to think in real-world environments. For that reason, I see wargames and CTFs as an extremely effective training ground for experiencing and practicing, both directly and indirectly, the skills required in real-world security work.

The challenge that stands out to me the most was one that focused on browser. It was created quite some time ago, and while browser and JavaScript engine vulnerabilities are relatively common topics in CTFs today, back then it was a field that felt unfamiliar and particularly difficult.
At the time, I drew inspiration from a vulnerability I had personally discovered and designed a new challenge around exploiting a Chrome browser JavaScript engine vulnerability. Since there had been very few browser-related challenges in CTFs up until that point, I wanted to convey the message that this was an area well worth exploring.
What I wanted to demonstrate was that browser hacking and JavaScript engine exploitation are not fundamentally different from traditional pwnable system hacking. The approaches and thought processes are closely connected, and I hoped to encourage more people to take on challenges in this space.
This challenge was created nearly ten years ago. By today’s standards, its difficulty might be considered easier by today’s standards, but at the time it was seen as highly challenging and received a very positive feedback. While browser has since become far more complex, I like to think that effort may have served as a small catalyst.

When I thought about what topic would be especially worthwhile to take on at least once right now, browsers were the first thing that came to mind. As I worked through various challenges recently, I felt that beyond simply chasing the latest vulnerabilities, there’s real value in gaining hands-on experience with understanding a browser’s internal architecture and applying that understanding to challenge solving.
The challenges selected for this Problem Set are based on bug patterns that could realistically occur in real-world browsers. They’re simplified and reconstructed as CTF-style challenges, drawing from cases I previously analyzed and found particularly interesting. Rather than being about spotting a single trick, these challenges are designed so that by calmly following the browser’s internal structure, learners can naturally reason through and solve them.
Through the process of studying browser internals and directly applying that knowledge to challenges, I hope learners move past vague fear or misconceptions and come away with a sense of, “This is actually easier than I thought.”

When I was studying around 2005 to 2007, the environment was completely different. Learning was difficult because resources and communities were scarce and mostly closed. Information circulated only among insiders, making it hard to know where to start. As a result, much of the learning involved repeating trial and error.
That process certainly led to growth, but looking back now, I feel I spent a lot of time quite inefficiently. There were many mistakes and detours that, in hindsight, didn’t really need to be repeated.
Naturally, this led me to a thought: if the next generation of security beginners is ultimately going to study the same fundamental concepts and build up more advanced knowledge and skills anyway, wouldn’t simply reducing those early trial-and-error phases significantly accelerate their overall growth? That idea stayed with me.
So when I first started Dreamhack together with meu, I wanted to contribute to creating an environment where people entering this field for the first time could learn more comfortably and with less friction. At the time, it felt less about business models or revenue and more about a sense of responsibility—that someone needed to do this work.
It was very much a mindset of “whether it makes money or not, if it’s necessary, we’ll give it a try.”

What comes to mind first is when we first launched Dreamhack. Even before the launch, people knew we were building an education platform, and expectations kept growing. At some point, that actually started to feel like pressure. I kept thinking, “What if expectations are this high, but no one actually ends up using it?”
We had imagined a service with a waiting list, but I was worried it could turn into the opposite. Because of that, we decided to be cautious and opened the beta to around 100 people. Honestly, I was nervous even about that—wondering what we’d do if we couldn’t fill those spots. Since hacking education isn’t easy to get into, the uncertainty felt even bigger.
Fortunately, the response on launch day was much stronger than we expected. The first 100 beta users quickly grew to 200, and soon after, a waiting list formed. That was when it really hit me—there are so many people in Korea who want to learn security, and there’s real demand for a platform like Dreamhack.
That’s when Dreamhack truly started to feel real. It gave me confidence that we were heading in the right direction with Theori’s first product. Even now, the mix of tension and relief I felt that day is one of the moments I remember most clearly.

Choosing just one proud moment as a CEO isn’t easy, but there are certain moments of pride that I experience repeatedly.
 When we first created Dreamhack, I often asked myself, “Can the content and platform we’re building truly evolve into meaningful learning experiences?” Compared to other educational services, Dreamhack was clearly different in both approach and direction. It wasn’t a matter of being better or worse, but rather whether this approach could genuinely help learners and serve as a meaningful way to learn. I constantly questioned this myself.
As time went on, we began to see individuals who grew significantly through Dreamhack—achieving notable results in CTF competitions and standing out in real-world.
 Of course, their own effort and talent played the biggest role, but these moments reassured us that Dreamhack’s educational approach, platform, and operational philosophy were on the right track. Encountering stories like these is when I feel the greatest sense of fulfillment and pride as a CEO.

There was a moment when the psychological burden outweighed the technical challenges—the moment we decided on Dreamhack’s business model. It was a shift toward a B2C subscription.
Dreamhack’s mission has remained unchanged since its launch: to lower the entry barriers in the field of cybersecurity and help more people access this area easily. But choosing to introduce paid subscriptions brought a lot of questions: Would this choice conflict with our goal and vision? Would it drift away from the direction we originally dreamed of? It was not an easy decision, and we debated extensively within the team, struggling to find the right balance.
Ultimately, the reason we decided to go paid was sustainability. When considering our long-term goal of lowering entry barriers and nurturing the next generation of cybersecurity professionals, we realized that if the platform itself couldn’t sustain, the vision couldn’t last either. While it might not be the ideal form in the short term, we believed that this choice was necessary to move toward our North Star in the long run.
Moreover, having a certain level of revenue allows us to take greater responsibility and reinvest in better content, challenges, and community support. In the end, we saw it as a path to reach our goals faster and further.

People often say, “Being good at competitions doesn’t mean you’re good at work.” Conversely, “Being good at work doesn’t mean you’re good at competitions.” I believe both statements are true—they can coexist.
So what does it actually mean to excel in both competitions and work? The key isn’t whether it’s a CTF or a professional task; it’s whether someone has fundamental problem-solving skills.
For example, if you repeatedly solve math problems from math workbook, you can solve similar problems almost instantly. But that doesn’t necessarily make you someone who is “good at math”—it just makes you someone who is good at solving those problems. We look for people who can understand the essence of a problem and solve it even in new situations.
The same applies to work. There’s a clear difference between someone who excels at repeating standardized procedures and someone who defines problems, explores multiple possibilities, and creates solutions.
People with strong problem-solving abilities tend to excel in both CTF competitions and real-world tasks, independently learning the necessary skills and solving problems at their core.
On the other hand, some people may appear quick and efficient in familiar environments but struggle when conditions change. This often reflects a lack of fundamental problem-solving skills.
That’s why, in our hiring process, we focus less on surface-level metrics like “how many CTFs you’ve completed” or “years of experience,” and more on how candidates approach unexpected situations during conversations or practical exercises. Do they get overwhelmed and give up when faced with unknown problems? Do they try to find a clue? Do they approach creatively?
Ultimately, the people we seek are not specialists in a specific field but problem solvers who tackle any challenge to the very end.

Cryptography tends to get similar reactions from everyone: “It’s hard,” “It’s math,” or “Do we really need this?” I felt the same way at first.
But at some point, I started finding it surprisingly enjoyable. Think about things we use every day without much thought—logins, authentication, communications. Underneath all of these, there’s cryptography at work. Once you properly understand it even just a little, you don’t just use these features—you start thinking, “Ah, this is why it’s secure.” It even makes you feel a little grateful. (laughs)
The challenges we selected this time are less about being good at calculations and more about thinking about the structure behind them. I also wanted to make sure that cryptography doesn’t feel overly intimidating for beginners.

To be honest, what I envy the most is that Dreamhack exists. If a platform like this had been around when I was first studying, it would have made things so much easier.
Back then, there wasn’t even an environment where challenges were gathered in one place. Challenges weren’t systematically managed, older content often disappeared, and there was no way to revisit them anytime. It was common for someone running a personal site to suddenly close it due to being busy or facing cost issues. So if you thought, “I’ll try this challenge later,” there was a good chance you’d never get the chance to solve it again.
I always studied under a sense of uncertainty because I never knew when materials might vanish. Study resources were scattered everywhere, so I had to organize and collect them myself.
Now, there is an environment like Dreamhack, where challenges and resources are gathered in one place and consistently maintained. I think having the opportunity to study on Dreamhack is a huge advantage for today’s hackers. It’s an era where they can grow faster, and in that sense, I also feel a bit envious.

We’ve reached a point where discussing the future of hacking without mentioning AI is impossible. One thing is clear: the future of cybersecurity and hacking will inevitably be intertwined with AI. In the Dreamhack community, people are already asking, “AI can solve high-difficulty wargame challenges—what’s the point of this?” This is more than just a fun discussion; it’s something we continuously explore internally.
At Theori, we are also leveraging AI to automatically detect vulnerabilities, suggest patches, and automate security processes. AI hacker Xint is evolving to understand applications from an attacker’s perspective, going beyond merely listing vulnerabilities to autonomously identifying multi-step attack scenarios and business logic issues. The problem-solving mindset trained in wargames is being applied directly to real-world service security.
In some areas, AI is growing much faster than humans, while in others, human judgment is still essential. However, technology is advancing so rapidly that making definitive predictions about hacking five or ten years from now is risky. Honestly, even predicting next month is challenging.
Still, looking at the relatively near future—1 to 2 years—the key point is clear: how effectively one leverages AI to amplify their own capabilities will become an increasingly critical factor in cybersecurity. A common misconception arises here: “If AI can solve everything, do I even need to know it?”
Of course, AI can handle many standardized challenges or vulnerabilities. But anyone who has tried using AI for real-world or highly complex problems knows this: simply telling AI “do this” rarely produces expected result. Often, it may seem plausible, but the results can stray from the true essence of the challenge.
In the end, to use AI effectively, someone must provide sufficient context, verify results, and recalibrate direction. And that role is still very much a human responsibility. At this stage, what makes the difference is fundamental knowledge and understanding of the problem. What you know determines how well you can leverage AI.
It’s not about “AI can solve this, so I don’t need to,” but rather “I need to understand more deeply to use AI better.” At least with the current generation of AI, the saying “you see as much as you know” still holds true.
Today, AI may seem on par with humans by quickly solving relatively easy problems. But the challenge is how far we can extend AI to tackle problems that were once solvable only by a few humans—or even problems no one could solve. Until we reach that stage, the era will belong to those who combine solid fundamentals with AI to achieve the most powerful results.

This year alone, there have been numerous security incidents, both big and small. The role of white-hat hackers and security professionals—often mentioned as “promising careers for the next five years”—is now not just talked about but genuinely recognized in the market. Awareness is clearly shifting across companies and society as a whole.
In the field, there’s a strong desire to find skilled professionals, yet truly capable individuals are rare. The demand is already high and is unlikely to decrease anytime soon; in fact, it’s likely to grow even more. For that reason, I believe this is an excellent time to enter the cybersecurity field and build expertise. Of course, being a top expert right now would be ideal, but even if you’re not, there’s plenty of room for growth in the future.
However, there is one clear point to be careful about: AI. AI is already transforming many aspects of the field, and the pace of change is accelerating daily. Simply having extensive hacking knowledge may soon no longer be enough to remain competitive.
If you are just starting out, that may be manageable, but if your goal is to become an expert in the coming years, the ability to effectively leverage AI, as well as experience thinking about AI security itself, will be essential. Studying the traditional way while ignoring AI could actually make the path much harder. Don’t see AI only as a competitor—embrace it as a tool and a colleague to work with. Build strong fundamentals while continuously exploring how AI can help amplify your capabilities.
We are at the very beginning of this transformation. Those who take advantage of this moment will create a significant difference in their cybersecurity careers.