Flags are useful because they provide definite objectives for your testers. The difficulty with flags is that while your testers need to be able to identify them, you should also want to simulate a real penetration test or hack as closely as possible. By this logic, a flag should be easily identifiable but not in your face. This can be handled carefully in a number of different ways, as mentioned in the following list:
Location: You can place the file in a directory commonly associated with loot. I mean, sensitive files is a good way to go. This will teach your testers good habits while also not taxing their brain cells excessively. Examples are shown in the next section.
Filename: The name
Flag.txtis self-explanatory, but there is a thing called too little imagination.Randall FlaggorJohn D. Objectiveare examples of making things a little less obvious.Obfuscation: Hiding the flag in another form works well in substitute for time to set up a set of dummy files; for example, hiding the flag in the Exif information of a picture. A guide to this can be found in Chapter 4, Social Engineering.
Cryptography: Flawed encryption methods can be used to add an extra challenge to a CTF. For extra information, go to Chapter 5, Cryptographic Projects.
Test your flag by writing a brief and completing the challenge up until the point of needing to locate the flag. Then, grab someone nearby, hand them the brief, point them at the computer, and ask them to locate the file. Given a limited amount of knowledge about the system, they should be able to locate it based solely on the brief you gave them. If not, you need to rethink.
The following sections provide some examples and descriptions as to why they are inappropriate.
To begin with, let's show a finding that is too easy. The following screenshot shows a flag (flag.txt) in the root C:/:
There are multiple problems with the placement shown in the previous screenshot. Firstly, the flag file itself bears no resemblance to a real-world file. A flag file can provide so much more than a simple objective. Second, it's in the root C:/—where the user would first be dropped in the event of a successful shell being launched, which means that the user wouldn't need to explore the filesystem at all.
Where the first example was too obvious, this next example isn't nearly obvious enough! The following screenshot shows a flag saved as config.conf in a random hexadecimal subdirectory of the extensions folder of Firefox:
I understand the logic in obfuscating files, but this is simply time consuming and pointless. Firstly, the directory is so absurdly esoteric that without briefing that there is a Firefox extension that has sensitive data in it, a tester would not look there. Second, the file, though containing a unique string, is not obviously a flag. This will cause doubts in some cases and lead to unnecessary checking time for the test leader.
A folder of significance, such as system32, will work as a good placement with a file named to fit your scenario. The name Flag.txt simply isn't interesting. The names Finances.xls and Clients.docx, provided they fit the story you assign to your challenges, will serve well. In this case, they can be stored in My Documents without seeming forced or arbitrary.
Repeated CTFs and challenges involving Flag.txt or a simple string each time can get boring. There are other methods of creating objectives as follows:
Credentials make good targets as they represent normal penetration tests. Using these will teach the testers to check SAM files, databases, and other files that may contain credentials. There is a list of likely places in the next subsection.
Descriptions of background images can be quick ways to solve the issue. A sample question would be: Describe the desktop background of XXX.XXX.XXX.XXX.