CTF Field Guide
“Knowing is not enough; we must apply. Willing is not enough; we must do.” – Johann Wolfgang von Goethe
We’re glad you’re here. We need more people like you.
If you’re going to make a living in defense, you have to think like the offense.
So, learn to win at Capture The Flag (CTF). These competitions distill major disciplines of professional computer security work into short, objectively measurable exercises. The focus areas that CTF competitions tend to measure are vulnerability discovery, exploit creation, toolkit creation, and operational tradecraft.
Whether you want to succeed at CTF, or as a computer security professional, you’ll need to become an expert in at least one of these disciplines. Ideally in all of them.
That’s why we wrote this book.
In these chapters, you’ll find everything you need to win your next CTF competition:
- Walkthroughs and details on past CTF challenges
- Guidance to help you design and create your own toolkits
- Case studies of attacker behavior, both in the real world and in past CTF competitions
To make your lives easier, we’ve supplemented each lesson with the Internet’s best supporting reference materials. These come from some of the best minds in the computer security field. Looking ahead, we hope you’ll collaborate to keep this book evolving with the industry.
We’ve tried to structure this so you can learn as quickly as you want, but if you have questions along the way, contact us. We’ll direct your question to the most relevant expert. If there’s enough demand, we may even schedule an online lecture.
Now, to work.
-The Trail of Bits Team
Computer security represents a challenge to education due to its interdisciplinary nature. Topics in computer security are drawn from areas ranging from theoretical aspects of computer science to applied aspects of information technology management. This makes it difficult to encapsulate the spirit of what constitutes a computer security professional.
One approximation for this measure has emerged: the ‘capture the flag’ competition. Attack-oriented CTF competitions try to distill the essence of many aspects of professional computer security work into a single short exercise that is objectively measurable. The focus areas that CTF competitions tend to measure are vulnerability discovery, exploit creation, toolkit creation, and operational tradecraft.
A modern computer security professional should be an expert in at least one of these areas and ideally in all of them. Success in CTF competitions demands that participants be an expert in at least one and ideally all of these areas. Therefore, preparing for and competing in CTF represents a way to efficiently merge discrete disciplines in computer science into a focus on computer security.
Find a CTF
If you ever wanted to start running, you were probably encouraged to sign up to a 5k to keep focused on a goal. The same principle applies here: pick a CTF in the near future that you want to compete in and come up with a practice schedule. Here are some CTFs that we can recommend:
Visit CTF Time and the CapCTF calendar for a more complete list of CTFs occuring every week of the year.
How is a Wargame different?
Wargames are similar to a CTF but are always ongoing. Typically, they are organized into levels that get progressively harder as you solve more of them. Wargames are an excellent way to practice for CTF! Here are some of our favorites:
What about CCDC?
There are some defense-only competitions that disguise themselves as CTF competitions, mainly the Collegiate Cyber Defense Challenge (CCDC) and its regional variations, and our opinion is that you should avoid them. They are unrealistic exercises in frustration and will teach you little about security or anything else. They are incredibly fun to play as a Red Team though!
[Editor’s note: this is an older article written for pentest.cryptocity.net and that we are in the process of updating.]
These are my views on information security careers based on the experience I’ve had and your mileage may vary. The information below will be most appropriate if you live in New York City, you’re interested in application security, pentesting, or reversing, and you are early on in your career in information security.
- Learn from a Book
- Learn from a Course
- Meet People
- Friends of the Guide
As far as I can tell, there are five major employers in the infosec industry (not counting academia).
- The Government
- Non-Tech Fortune 500s (mostly finance)
- Big Tech Vendors (mostly West coast)
- Big Consulting (mostly non-technical)
- Small Consulting (mostly awesome)
The industry you work in will determine the major problems you have to solve. For example, the emphasis in finance is to reduce risk at the lowest cost to the business (opportunities for large-scale automation). On the other hand, consulting often means selling people on the idea that X is actually a vulnerability and researching to find new ones.
I primarily split up infosec jobs into internal network security, product security, and consulting. I further break down these classes of jobs into the following roles:
- Application Security (code audits/app assessments)
- Attacker (offensive)
- Incident Handler
- Network Security Engineer
- Penetration Tester
- Reverse Engineer
- Security Architect
The roles above each require a different, highly specialized body of knowledge. This website is a great resource for application security and penetration testing, but you should find other resources if you are interested in a different role.
Learn from a Book
Fortunately, there are dozens of good books written about each topic inside information security. Dino Dai Zovi and Tom Ptacek both have excellent reading lists. We recommend looking at:
If you’re not sure what you’re looking for, then you should browse the selection offered byO’Reilly. They are probably the most consistent and high-quality book publisher in this industry.
Don’t forget that reading the book alone won’t give you any additional skills beyond the conversational. You need to practice or create something based on what you read to really gain value and understanding from it.
Learn from a Course
If you’re looking for something more hands-on and directed, there are lots of university courses about information security available online. I listed some of the best ones that have course materials available below (ordered by institution name). The RPI course is the most similar to this one and Hovav gets points for the best academic reading list, but every course on this list is fantastic.
[Ed. note: Table to be added/updated later.]
The easiest shortcut to finding a university with a dedicated security program is to look through the NSA Centers of Academic Excellence (NSA-COE) institution list. This certification has become watered down as more universities have obtained it and it might help to focus your search on those that have obtained the newer COE-CO certification. Remember, certifications are only a guideline. You should look into the actual programs at each university instead of basing your decision on a certification alone.
Once in university, take classes that force you to write code in large volumes to solve hard problems. IMHO the courses that focus on mainly theoretical or simulated problems provide limited value. Ask upper level students for recommendations if you can’t identify the CS courses with programming from the CS courses done entirely on paper. The other way to frame this is to go to school for software development rather than computer science.
Capture the Flag
If you want to acquire and maintain technical skills and you want to do it fast, then you should play in a CTF or jump into a wargame. The one thing to note is that many of these challenges attach themselves to conferences (of all sizes), and by playing in them you will likely miss the entire rest of the conference. Try not to over do it, since conferences are useful in their own way (see the rest of the career guide).
There are some defense-only competitions that disguise themselves as normal CTF competitions, mainly the Collegiate Cyber Defense Challenge (CCDC) and its regional variations, and my opinion is that you should avoid them. They are exercises in system administration and frustration and will teach you little about security or anything else. They are incredibly fun to play as a Red Team though.
In any role, the majority of your time will be spent communicating with others, primarily through email and meetings and less by phone and IM. The role/employer you have will determine whether you speak more with internal infosec teams, non-security technologists, or business users. For example, expect to communicate more with external technologists if you do network security for a financial firm.
Tips for communicating well in a large organization:
- Learn to write clear, concise, and professional email.
- Learn to get things done and stay organized. Do not drop the ball.
- Learn the business that your company or client is in. If you can speak in terms of the business, your arguments a) to not do things b) to fix things and c) to do things that involve time and money will be much more persuasive.
- Learn how your company or client works, ie. key individuals, processes, or other motivators that factor into what gets things done.
If you are still attending a university, as with CS courses, take humanities courses that force you to write.
Find and go to your local CitySec, an informal meetup without presentations that occurs once monthly in most cities. At Trail of Bits, we attend our local NYSEC.
ISSA and ISC2 focus on policy, compliance and other issues that will be of uncertain use for a new student in this field. Similarly, InfraGard mainly focuses on non-technical law enforcement-related issues. OWASP is one of the industry’s worst examples of vendor capture and is less about technology and more about sales.
If you’ve never been to an infosec conference before, use the google calendar below to find a low-cost local one and go. There have been students of mine who think that attending a conference will be some kind of test and put off going to one for as long as possible. I promise I won’t pop out of the bushes with a final exam and publish your scores afterward.
If you go to a conference, don’t obsess over attending a talk during every time slot. The talks are just bait to lure all the smart hackers to one location for a weekend: you should meet the other attendees! If a particular talk was interesting and useful then you can and should talk to the speaker. This post by Shawn Moyer at the Defcon Speaker’s Corner has more on this subject.
If you’re working somewhere and are having trouble justifying conference attendance to your company, the Infosec Leaders blog has some helpful advice.
This industry requires specialized knowledge and skills and studying for a certification exam will not help you gain them. In fact, in many cases, it can be harmful because the time you spend studying for a test will distract you from doing anything else in this guide.
That said, there are inexpensive and vendor-neutral certifications that you can reasonably obtain with your current level of experience to help set apart your resume, like the Network+and Security+ or even a NOP, but I would worry about certifications the least in your job search or professional development.
In general, the two best reasons to get certifications are:
- If you are being paid to get certified, through paid training and exams or sometimes through an automatic pay raise after you get the certification (common in the government).
- If your company or your client is forcing you to get certified. This is usually to help with a sales pitch, ie. “You should hire us because all of our staff are XYZ certified!”
In general, it is far more productive to spend time playing in a CTF, then using your final standing as proof that you’re capable.
- Reddit and Hacker News threads about this post
- Security Advice
- Thoughts on Certifications
- General Tech Advice
Auditing Source Code
This module is about getting familiar with vulnerabilities that manifest in applications that compile to native code. An accurate and complete understanding of an application written in a compiled language cannot be achieved without learning about how the compiler transforms source to machine code and how processors execute that code. An easy way to gain experience with these transforms is by reverse engineering compiled variants of your own code or of projects with source code available. At the end of this module you will be able to identify vulnerabilities in compiled languages like C and C++.
Vulnerabilities are commonly identified in large software packages due to their use of third-party software libraries. Common examples include libraries like libxml, libpng, libpoppler, and libfreetype that parse complicated file formats and protocols. Each of these libraries have historically been prone to software flaws that make the applications using them vulnerable to attack. It doesn’t help that most software packages fail to update these libraries when new versions come out, making it significant easier to find known vulnerabilities to apply in these cases.
In order to practice your skills, we recommend going through the process of identifying as many vulnerabilities as you can in an intentionally vulnerable toy application and then moving on to a real application and doing the same.
The Newspaper application is a small server written in C that allows authenticated users to read and write articles to a remote file system. Newspaper is written in such a way that it is vulnerable to many different attacks. You should be capable of identifying at least 10 bugs or potential vulnerabilities in this code.
Wireshark, however, is an industry standard network protocol analyzer that has been under continuous development since 1998. Vulnerabilities in this code base are much fewer and far between than in the Newspaper app however many still exist. Take a look at the wireshark security page, find the name of a protocol dissector and see if you can independently discover the vulnerability without looking at the details. Dissectors are located in /epan/dissectors/ folder.
When auditing, it is helpful to use a tool design to profile and navigate the codebase. Below are two tools, Source Navigator and Understand, designed to help analysts get familiar with code quickly by collecting and displaying information about data relationships, API usage, design patterns and control flow. An example of a useful diffing tool is also listed below. One example of a free, open source code auditing tool is the Clang Static Analyzer, which can help you track down programming errors in common APIs and vulnerable programming patterns.
Make sure you’re intimately familiar with the internals of the languages you target for analysis. Vulnerabilities are found by auditors who are more familiar with the language and the codebase than the programmers that originally developed it. In some cases, this level of understanding can be achieved simply by paying attaching to optional compiler warnings or through the use of third-party analysis tools that help track down common programming errors. Computer security is tantamount to computer mastery. Without a rigorous understanding of your targets you can never hope to defeat them.
You’ve made it all the way down to the native layer, this is what software is after you pull off all the covers. The flavor of native code we’re going to focus on today is 32-bit Intel x86. Intel processors have been a powerful force in personal computing since the 80’s and currently predominate desktop and server market. Understanding this instruction set will give you some insight into how the programs you use every day operate as well as provide a reference point for when you encounter other instruction sets like ARM, MIPS, PowerPC and SPARC.
This module is about becoming familiar with the native layer and developing strategies for understanding, analyzing and interpreting native code. By the end of this module you should be capable of performing a “reverse compilation” — going from assembly fragments to statements in higher level languages — and, in the process, deriving meaning and programmer intent.
Learning x86 can appear daunting at first and requires some dedicated study to master. We recommend reading Chapter 3 of “Computer Systems: A Programmer’s Perspective” to learn how C programs get compiled into machine code. Once you you have some basic, working knowledge of this process then keep a handy reference guide around like the x86 Assembly Guide from the University of Virginia. We’ve found this video series from Quinn Liu to be a quick and painless introduction too.
The following programs are both “binary bombs.” Reverse engineer the following linux programs to identify the series of inputs that will “defuse” the bomb. Each successive level of the bomb focuses on a different aspect of native code. For example, in the lab from CMU you will encounter different data structures (linked lists, trees) as well as how control flow structures (switches, loops) manifest in native code. While reversing these programs you may find it useful to keep track of your progress by transforming what you see into C or another high level language.
You should aim to solve at least eight stages between the two labs. The CMU bomb lab has a secret phase and the RPI bomb lab has a phase that involves memory corruption, can you find and solve them?
The two essential tools for working with native code are the debugger and the disassembler. We recommend you become familiar with the industry standard disassembler: IDA Pro. IDA will divide code into discrete chunks corresponding to the functions defined in the program’s source code. Each function is then further subdivided into “basic blocks” defined by instructions that alter control flow. This makes it easy to identify loops, conditionals, and other control flow constructs at a glance.
Debuggers allow you to interact with and examine the state of running code by setting breakpoints and examining memory and register contents. You may find this useful as a sanity check if you are not seeing the results you expect your input to produce but be alert, some programs employ anti-debugger techniques and can modify program behavior in the presence of a debugger. The GNU Debugger (gdb) is the standard debugger for most linux systems. gdb can be acquired through the package manager in your chosen linux distribution.
Many good resources exist for learning x86 assembly and the various tricks employed in capture the flag exercises. In addition to the resources above, the x86 Wikibook and the AMD instruction set manual are more complete reference guides you may want to refer to (we find the AMD manual can be less daunting than the corresponding manual from Intel).
Some of the tools used for reverse engineering can be as complicated as assembly language itself. Cheatsheets that list out common commands and use cases can be helpful.
Finally, many capture the flag challenges will make use of anti-debugging and anti-disassembly techniques to hide or obfuscate the goal. Several of these techniques are employed by the bomb labs but you may want a more complete reference.
Auditing Web Applications
Welcome to the web hacking module. This module is about getting familiar with vulnerabilities commonly found in web applications. At the end of this module you will be able to identify common vulnerabilities in web based applications using a variety of testing methodologies and source level auditing. The lecture material will give you all the tools you need to successfully audit the workshop material.
In order to practice your skills, we recommend going through the process of finding and exploiting vulnerabilities in the Damn Vulnerable Web App (DVWA) and the Siberia Exploit Kit. DVWA is a collection of vulnerable test cases implemented in PHP and serves as an easy introduction to the many things that can go wrong in web applications. The Siberia Exploit Kit is a “crimeware pack” used by criminals to perform massive compromises. It includes a package of browser exploits and a command and control panel intended to manage compromised hosts. Siberia contains several pre- and post-authentication vulnerabilities that allow an attacker to gain administrative access to the panel, then take over the server on which it is hosted.
Download and run the OWASP Broken Web Apps virtual machine in VMware to start this workshop. BWA includes many web applications many for security testing, including DVWA. Once you have mastered DVWA, feel free to move on to other vulnerable web applications! Try auditing Siberia’s source code to find the vulnerabilities, paying attention to sources of input in PHP.
Burp Suite is a local HTTP proxy intended for security testing. Burp Suite is made for web penetration testers and simplifies many common tasks in a point-and-click GUI. The features available in the free version are more than enough to complete this and many other web security challenges.
Many simple testing methods and common web application flaws are available in the walkthrough. Ensure that you understand the fundementals of HTTP, HTML, and PHP to do well on this section.
Exploiting Binaries 1
Binary exploitation is the process of subverting a compiled application such that it violates some trust boundary in a way that is advantageous to you, the attacker. In this module we are going to focus on memory corruption. By abusing vulnerabilities that corrupt memory in software we can often rewrite critical application state information in a way that allows us to elevate privileges inside the context of a particular application (like a remote desktop server) or perform arbitrary computation by hijacking control flow and running code of our choosing.
If you’re trying to find bugs in compiled C programs, it’s important to know what you’re looking for. Start with identifying where the data you send to the program is used. If your data is stored in a buffer, take note of the sizes of them. Programming in C without errors is very difficult and the CERT C Coding Standard catalogues many of the ways that errors can come about. Paying attention to commonly misused APIs can be a quick path to success.
Once a vulnerability is identified it should be used to compromise the integrity of the program, however, there are a variety of ways to achieve this goal. For programs such as web servers, obtaining the information from another user may be the end goal. In others, changing your permissions may be helpful, for example changing the permissions of a local user to the administrator.
The first lecture, Memory Corruption 101, provides background and step-by-step explanation of exploiting an overflow on Windows. The second lecture, Memory Corruption 102, covers more advanced topics, including web browser exploitation. Both of these lectures use Windows-specific examples but the techniques and process are applicable across operating systems that use the x86 instruction set. Remember that the names of functions and sometimes the calling conventions will be different when you are working with UNIX/Linux binaries.
We recommend using GDB to debug the challenges in this module since all of them are compiled for 32-bit Linux, however, GDB is intended for debugging source code, not stripped binaries without symbols and debugging information. Projects such as gdbinit, peda, andvoltron are attempts at making gdb more useful for debugging when source code is not available. We recommend making a
.gdbinit file in your home directory with at least the following commands:
set disassembly-flavor intel
set follow-fork-mode child
In order to run these challenges, you’ll need to setup an Ubuntu 14.04 (32-bit) virtual machine. We recommend using VMware Player, since it’s free and well supported. When you have it running, open a terminal and install
socat with command
sudo apt-get install socat.
There are three challenges in this workshop, each contained within this folder when you clone this repository in git. The ultimate goal of each challenge is to manipulate the executable into reading the flag to you. For each challenge, try to translate the disassembly into C code. After making an attempt, you can verify your guess by checking the actual C source provided. Then, try to exploit it to read you the flag.
Make sure the flag is in the same directory as the
easy program. Once you execute
easy it will listen for instructions on port
Similar to easy, make sure the flag and
host.sh are in the same directory as
social program. Once you execute
social it will listen for instructions on port
Exploiting Binaries 2
In this module, we continue to examine the ways that native applications can be exploited and focus on using return-oriented programming (ROP) to achieve that goal. ROP is the process of stitching together existing executable fragments of code ending in a return instruction. By creating chains of addresses of these ‘gadgets’ one can write new programs without introducing any new code.
Keep in mind that you will need to be flexible in identifying methods to exploit programs. Sometimes it’s necessary to abuse a vulnerability multiple times in the course of an exploit. At times, you may only want to use a ROP bridge to make your shellcode executable and, at others, you may want to use a payload written entirely in ROP. Occasionally, the layout of memory makes unorthodox methods of exploitation favorable. For example, have you considered manufacturing an uncontrolled format string vulnerability using ROP?
The lectures this week will discuss return oriented programming (ROP) and code reuse to bypass protections that disallow the execution of attacker-provided data. These lectures go into much greater detail on exploitation and build upon some of what was discussed last week.
Similar to the previous lesson, there are two executable files located in this folder when you clone the repository. Exploits for each of these programs will require the use of return-oriented programming to read the flags. This week, there is no access to source code provided. You will need to reverse engineer the binaries to discovery the vulnerabilities and the techniques required to exploit them. Use the same Ubuntu 14.04 (32-bit) virtual machine as the previous lesson.
bc program. It will listen on port
host.sh in the same directory as the
space program. It will listen on port
host.sh in the same directory as the
rop_mixer program. It will listen on port
Refer to the tools from last week. If you haven’t already, you should become familiar with the
binutils suite for *NIX. Tools like
nm are frequently helpful. Use your package manager and the manpages to install and read about their use.
Several tools exist to aid specifically in the creation of exploits that reuse code. They are more specialized than a standard disassembler because they look for executable snippets of code suitable as ROP gadgets (between instructions, in .rodata, etc).
This module follows up on the previous auditing web applications module. In this module we will focus on exploiting those vulnerabilities. By the end of this module you should be comfortable identifying and exploiting the OWASP Top 10.
We covered the basics in the previous section on web security, so now we can dive into some more capable tools to achieve greater effects in this module. Learn to master Burp Suite and the Chrome Developer tools to gain a greater understanding of the applications you interact with. BeEF is an example of an XSS proxy and it will pay off to look through its source code and learn how it works.
You have been tasked with auditing Gruyere, a small, cheesy web application. Gruyere is available through and hosted by Google. It includes exercises for exploiting many classes of web-specific vulnerabilities including XSS, SQL injection, CSRF, directory traversal and more. For each challenge you can find hints, exploits and methods to patch the vulnerable code.
SQL Map and BeEF are powerful tools and very fun to play around with but ultimately not needed for the exercise. If you insist on playing with BeEF on, then please try not to hook other users auditing the application.
Welcome to the module on toolkit creation. A toolkit is a set of utilities that enable you and your team to achieve operational goals in the most efficient manner possible. Your toolkit is a force multiplier that will enable you to minimize the time you spend developing exploits during the game and maximize the return on your development time.
A good toolkit is well rounded and easy to use. You should incorporate software that allows members of your team to communicate effectively, work collaboratively, automate common tasks and provide situational awareness of the game as it plays out.
Create three lists. Populate the first list with the functionality your ideal toolkit would provide. Populate the second list with software that can provide that functionality. Use the third list to rank in order of importance functionality that is inadequately supported by the software from list two. Begin developing software that fills in the gaps of your ideal toolkit.
Some functionality you should not neglect:
- Management of exploitation, key aggregation and submission.
- Stealthy and secure payloads or persistence methods.
- Secure communication and collaboration.
- Network/Host situational awareness.
Studies in Tradecraft
Operational tradecraft is generally cultivated with a specific goal in mind. While playing competitive wargames you will most likely be focused on evading detection and not putting elements of your toolkit (infrastructure, exploits) at risk of inadvertent exposure.
Evaluate the operational tradecraft displayed during the following campaigns. Each design decision employed in these tools and campaigns has an operational philosophy behind it.
Some things to think about while evaluating tradecraft:
- Why did the actor chose to perform/implement X action/capability?
- Were any mistakes made? Was a decision flawed or shortsighted in some way?
- Was an action/capability anomalus? Does it fit with the rest of the operational philosophy?
- What was the actor most interested in protecting? (ex: Tools, Identities, Employers etc.)
- What can be learned from each campaign from an attackers standpoint? Defenders standpoint?
These are few public examples, groups, or organizations that discuss their own tradecraft. The AMA’s below provide a rare glimpse into how extraordinarily talented groups operate.
This book was built on a lot of hard work, most of which happened elsewhere. Without permission to republish from these folks, this book would still be in development. They have our gratitude and admiration.
So, reader, when you’ve completed a few CTFs, and you’re ready for more, reach out to this list. They like to support ambition, and they just might know someone who needs some talent.
If you’re interested in taking a course like this one for credit, check out NYU Poly. They offer concentrations in cybersecurity and we collaborate with them frequently through their Hacker in Residence program.
If you want to make a contribution, simply commit your new markdown to the
master branch and we’ll take it from there. Gitbook has a fantastic editor available to help preview your changes. We’re always looking for new or refined content, so please send us your suggestions!
The CTF Field Guide is built with Gitbook, a command line tool for building books with Git and Markdown. You can use Gitbook to output the CTF Field Guide as a PDF, an eBook or a single, printable HTML page. Make sure you have NodeJS and
npm on your operating system, then install Gitbook and a few of its plugins:
npm install gitbook gitbook-plugin-ga gitbook-pdf ebook-convert -g
With Gitbook installed, you can run any of these commands from within the book directory:
- Generate an interactive, static website:
gitbook build ./myrepo
- Generate a single page website:
gitbook build ./myrepo -f page.
- Generate a PDF:
gitbook pdf ./myrepo. Requires gitbook-pdf.
- Generate an eBook:
gitbook ebook ./myrepo. Requires ebook-convert.
More information and the complete book can be found at: