Some time ago I wrote a post named “unofficial guide to creating CTF VMs“. Since then I have been approached by random people, students I mentor and colleagues asking how to make that virtual machine vulnerable. Well, I never intended that post to reveal that. It was simply left as an exercise to the readers. Today I will lift the veil on my process for making vulnerable games.
After giving it much thought, I landed on describing my workflow instead of making a tutorial. A tutorial complete with how to make a vulnerable machine by setting up services and software would make a blueprint for others to follow and distribute. No sense in making blueprint for others to copy and distribute flooding the scene with several replica games, would it?
Anyway, after suffering from writers block for some months now, here’s the workflow I use.
My workflow
I follow my own standards when it comes to preparing games. It helps me in the creative process so I don’t go overboard. My workflow is as follows (in no way exhaustive):
- Finding out the audience and their technical level
- Research
- Get an overview of what the current threat landscape looks like
- Look at recent CTF games
- Look at what people are talking about on Twitter
- Look at what’s been presented at various conferences
- Outline the attack path from start to finish
- Implement
- Testing
- Rollout
As you can see, this workflow isn’t particularly long. Usually I spend anything from a day to a month setting up a game, depending on the complexity. Let’s look into each step in this process.
Finding out the audience and their technical level
My audience doesn’t vary much. Either they are students or people with some field experience in blue teaming (since that is what I do these days). Most often I prepare a game to demonstrate concepts and attacks in order to defend systems. Thus, my games are often somewhat short and to the point. One key goal is that a game shouldn’t take forever to solve.
My games are corporate internals, so I can’t say much about creating public ones. Except, I imagine you shouldn’t go overboard making too difficult games. Try to make the game match your own level of expertise.
Researching
Making a valid game, proving a concept or an attack takes some research. To want to make a game is just one part of the equation. To make another run-of-the-mill game is no option, at least for me. When it comes to stuffing a game I:
First I try to get up to speed on the current threat landscape. Most often I use these resources:
- IBM X-Force Threat Exchange
- AlienVault Open Threat Exchange
- CVEDetails
- Daily Information Security Podcast (“StormCast”)
Next I look at recent CTF games and writeups, mostly using these resources:
Twitter makes a massive impact in my works. I usually use Tweetdeck to get a nice overview on conversations and trends.
Then I look at what’s been presented at various conferences, I often look for talks from these conferences:
Usually, videos can be found on Youtube and from the various conference media download sections.
Outline the attack path from start to finish
With all the information gathered, I start to outline an attack path from start to finish. This serves as my main attack path. Usually I just jot it down using an text editor. I also make sure to not make long and complex attack paths. It’s a pedagogical thing, I want my students to feel they can achieve things. If they end up banging their heads into a wall, then I have failed.
Please keep in mind, even though you create a main attack path, most often there will be alternative paths to solve your game. There might be security issues you haven’t thought of. If anyone finds alternative paths in my games, well, that’s great! More on this later.
Implement
In this phase I implement the attacks from the previous phases. How I do this varies with the attacks I’ve found interesting. I usually base my implementation on the virtual image I created in this blog post. Sometimes I update it before use, sometimes I don’t. When I don’t, I usually have a plan to utilize old vulnerabilities.
This stage is kinda funky, because the attack path may be extended or changed because of the virtual machine. In this stage it would be smart to run a vulnerability scan against it. Make sure to do both perimeter and credentialed scans. These scans will provide you hints on alternative attack vectors and paths by looking at both sides. Most scanners, such as Nessus, will correlate vulnerabilities between the exterior and the internal state making a clearer picture of possible attack paths. On a side note, it doesn’t hurt to put Nmap and the various scanners in Metasploit into action either. Just take the output and Google it, running a local Searchsploit search may yield some interesting results too.
Why do I mention vulnerability scanning in the implementation phase instead of in the outlining phase? There are many reasons. One is, you can really tighten your game in this phase. Another one is, it’s just nice to get an indication of what your players might try to exploit.
Testing and rollout
Before rolling out, it’s wise to test your game to weed out nasty bugs. Bugs often creep in whether you like it or not. I simply hate to get served a game where the virtual machine is unstable, having network issues or anything else that might bug me. In my mind a game should be well prepared and stable. When any issues have been resolved, release the game to the public in whatever way you like.
Closing note
Some cool things to try out:
- Set up Syslog forwarding on your virtual machine and send logs to a SIEM system. It’s a great way to see how attacks looks from a analytics perspective when players are hitting the machine. IBM QRadar Community Edition is both free and easy to use.
- Set up a an old stock Linux or Windows VM and just hack away. Windows 2003 perhaps?
reedphish 