Recently chatting with a friend I realized I can recall a lot of interesting stories of how players tried to abuse a given CTF tournament to gain an extra edge over the competition. So in this informal blog post I'll try to list what I remember for both the purpose of documenting this so others can learn from history, and also due to its fun factor (or rather: fun factor after a couple of years passed and folks stopped being annoyed or down right furious at the perpetrators). Note that some of what I'll log here are just stories I've heard. Other things I might have witnessed on my own. In either case I won't be posting any details of who / when / at what CTF – that's not the purpose of this post. Rather than that I'll try to distill and present the general concept.

Update: In case you're wondering what is a security CTF: it's team hacking competition, closely related to vulnerability research and cryptanalysis. You can read more on CTFtime.org and Wikipedia. End of update.

Please treat everything I've written with a grain of salt and excuse my human memory if I mix things up. I've been playing CTFs or CTF-like events for close to 20 years now, so yeah, mix ups might happen.

Please also note that these are stories of abuse and NOT a guide on how to play CTFs. Please DON'T do the stuff described here.

Why we don't do RECON/OSINT anymore

The RECON category – nowadays called OSINT – was a bit more popular around 10 years ago, though it still does appear on some CTFs from time to time (especially that there's a renewed hype on OSINT). Tasks in this category were usually about finding a flag hidden on social media of a given fake person. So what can go wrong?

One common thing players did, was finding the flag on – let's say Facebook – and then mass reporting the profile as fake/spammy/scaming/etc. After some reports the profile usually went down and other team were not able get the flag. This would cause CTF organizers struggled to make new profiles, or they just had to take down the challenge.

Another abuse tactic used was posting fake flags (or worse: misleading "hints") on profiles of real people that pop up faster in search results. Or just creating fake profiles (though the creation date was a dead giveaway... if one noticed it). Such red herrings would have other teams running in circles and give admins a serious headache when answering questions like "why does my flag not work?!".

It got worse if overzealous CTF players started reaching out to real people with matching names and demanding to get the flag. From what I know this thankfully was a very very rare thing though.

Lesson for CTF organizers: Don't create tasks which rely on services not under reasonable organizer control. But ideally just don't make OSINT/RECON challenges – they are usually way too guessy to be fun anyway.

Just remove the flag

In case of challenges where one would get access to a shell containing a flag file (or access to a database containing the flag), a common thing I saw folks do is to try to remove the flag. This required of course incorrect permissions set by the organizers, but from time to time it did happen. The result was that other teams would not be able to find the flag, and – in case organizer's exploit stopped short from getting the flag – would cause a lot of grief and anger.

A more diabolical twist on this was to replace the flag with a fake flag.

Lesson for CTF organizers: Check permissions and make sure player's can't remove/overwrite the flag.

The score is just a number in the database

Hacking the infrastructure wasn't uncommon in the past. After all, it might be easier to just hack the scoreboard and change the number in one team's row than solve the tasks. Or mark a few more challenges as completed. There are also stories of teams burning through 0-days for certain less popular systems used to host the infrastructure.

Actually years ago it was often treated as within the spirit of the competition. And while the added points were removed, the organizers would award a given team bonus points for finding a vulnerability.

Lesson for CTF organizers: Should go without saying, but... secure your infrastructure.

Logic bugs in the scoring system

It turned out that hacking the scoreboard wasn't the only way players could get extra points. Another way was to find logical bugs in flag submission system.

There were probably multiple common logic bugs. However one that sticks out in my memory was when the submission system would first check if the team already submitted that flag (fast check in session) and if not, it would check the flag in the database (slow), award points (slow), and finally add the flag to the session (fast). Yup, that's a race condition. If one would put some strain on the system and then simultaneously submit the flag from multiple connections, there was a pretty high chance to get awarded the points multiple times.

Lesson for CTF organizers: Remember to queue flag submissions or provide other type of synchronization. Or just use off-the-shelf tested CTF scoreboard systems.

Premature challenge disclosure

Challenges on a CTF are usually released every several hours. There are two reasons to doing it. First of all, it gives teams with less people a bit more chance when competing against large teams. And secondly it's also a bit more fair for folks in other timezones. While it's not a perfect solution, it is what we have.

So yet another abused bug in a CTF dashboard was to find unreleased challenges that were hidden only behind guessable links (e.g. /challenge/1, /challenge/2, /challenge/3, ...). An enterprising player could then find the unreleased challenges, pass them to teammates, and just submit flags after challenge is released (with a delay of course to not attract attention).

ETA: Both on discord (kudos to disconnect3d) and on twitter (kudos to Caio Lüders) folks pointed out a few more typical ways challenges leak:

• Finding task subdomains via Certificate Transparency Logs / crt.sh.
• Guessing the challenge path/subdomain or string format when using a hash and doing some brute forcing.
• Or more generally, researching the organizers and checking what were they recently working on - perhaps it will pop up on the next CTF (though I personally would call this proper preparations, and not abuse).

By the way...
On 22nd Nov'24 we're running a webinar called "CVEs of SSH" – it's free, but requires sign up: https://hexarcana.ch/workshops/cves-of-ssh (Dan from HexArcana is the speaker).

Lesson for CTF organizers: Make sure closed challenges are really closed (both on the website and the actual challenge service on some guessable subdomain). Also, I'm not saying to troll players with fake challenges that will never be opened, but I'm also not saying to not do that.

Geo IP

An interesting task type popular in the past (but that quickly became repetitive) was to access the challenge website from as many geographical locations (usually countries) as possible. The link to the task would of course contain an additional parameters with the team token. In some versions of this task each team had to gather at least N locations, while in others each locations was worth a single point.

Obvious solutions included using various open proxies, VPNs, TOR, any type of ping-back mechanisms, or online services doing translations / screenshots / accessing a given link for whatever reasons. An even more obvious ones included just asking friends, family, and eventually anyone that would agree to click on the link (i.e. spamming the social media and web with the link). I do have to note that the obvious marketing benefit for the CTF having such a task was more people learning about the CTF from their friends/etc.

However there are stories of teams going a step further and hacking home routers from random IPs located in various countries. I guess that's trading in ethics and legality for CTF points.

Lesson for CTF organizers: No lesson this time.I guess there's is just no reason to bring this type of tasks back anyway.

DoSing the infrastructure

A boring and obvious one - if the scoreboard / challenges a DoSed, then no one can score more points.

I do have to note that this usually is done unwittingly by the players. Especially newer ones who don't have a full grasp of CTF meta yet and don't realize that using online brute-forcing isn't really a thing on CTFs (and rarely yields any results).

I do also remember an onsite Attack&Defense style CTF where – due to how it was structured / designed – DoSing each other machines was the only viable strategy in a later phase of the game. Players just ended up sitting on the tables and chatting with each other while waiting for the competition to end.

Lesson for CTF organizers: Account for DoSes when designing the infrastructure.

Shoulder surfing

Rarely used since it's rarely useful, but I'm going to note it here as well for completeness. On onsite CTFs the teams usually have no visual separation between each others and sometimes they sit really close. So if someone would have photographic memory (or an image acquisition tool – say... a smartphone), they could potentially just sneak a peek at the right moment to get the flag.

Another potential avenue for abuse are teams that use the same language to communicate sitting really close to each other and eavesdropping on one-another. But that's why loud music usually blasts the CTF halls (and gives players a literal headache).

I also saw once a player trying to swipe a piece of paper with configuration (user/password) details of another team on an Attack&Defense style CTF. They were caught in the act and their team got some penalty for it.

Lesson for CTF organizers: A bit more spacing between the teams might be a good choice. Or just some sort of separators/mini-walls. Neither of these solve players taking a walk to "get a redbull".

Hacking other players

This one is a bit more complex than it looks at face value. It's also strictly Attack&Defense related.

I think most folks would agree, that by default hacking other player's computers (not the team's game server, but their personal laptops) is a no go both for legal and ethical reasons. Of course there is no reason why a given A&D CTF couldn't structure the game and rules in a way where this would be allowed (and players would be forewarned to use burner laptops). But in general it's banned for obvious reasons.

However, it still accidentally happens. Imagine the following scenario: your team captures the network traffic on your game server and spots an exploit for a given service. You don't have an exploit for that service yet, so you extract the payload to your laptop, and run it locally against a local copy of the service. And it works! Great! Now you can use it against other teams and get flags. But what's this? It was actually backdoored! And by running it against a locally deployed service you gave a shell on your personal laptop to the other team. And they unwittingly access it and start to browse around expecting to be on a game server belonging to a different team (which would be totally fine on an A&D CTF). Oops.

That's a hypothetical scenario, but not an unlikely one if the game network is misconfigured. And since the hack was done unwittingly, it's even hard to call it an abuse.

Lesson for CTF organizers: Make sure player's don't have network-level access to each other's computers – just to the game servers. This might be a bit harder to do on online CTFs.

Flag sharing

"I'll give you flag for X if you give me flag for Y". Pretty rare, but still happens. Of course one could point out that perhaps the flag for each team should be unique. However while this is achievable technically, as soon as the abusers would realize this, they would just share the exploit instead of the flag itself. That's probably one of the reasons this method of cheating detection is so uncommon.

However every organizer's nightmare is something else: a flag or exploit being shared publicly, e.g. on the CTF discord server. In case the flag was shared there's always the option to re-key (or rather "re-flag") the challenge. But if the exploit was shared the only viable solution is to invalidate the whole challenge. Thankfully I don't think I've ever seen this happening – which doesn't mean I'm not worried about it.

Lesson for CTF organizers: I don't think there is much we can do here. But thankfully this also is unlikely to fully break a CTF (i.e. it's unlikely for anyone that would do this to have the whole set of flags).

Player limit

Some online or onsite CTFs come with a team size limit. For example: "a team cannot be more than 5 people".

This is something the a lot of CTFs had in the past, but currently the rule is almost entirely gone. The reason is pretty trivial - there is literally no way for a CTF organizer to catch each and every attempt at using additional players. If you disagree, please remember that we're dealing with hackers, who know well what e.g. a side channel is, and can be extremely creative in ways to communicate out-of-monitored-band.

So yes, abuse of this rule does happen, but the solution surprisingly is to just not have that rule in the first place.

Lesson for CTF organizers: Don't limit the team size – you can't enforce it anyway.

Stories from my readers...

I probably missed something or just never heard about it. If you let me know, I'll include it here as well - thanks!

Exploits left behind (added 2022-07-23)

I was wondering whether I should add this to the list or not, though after jvoisin (who has a pretty amazing security blog btw) mentioned it as well, I decided to add it for completeness (even though I am not convinced this is actual abuse).

From time to time there is a complex challenge, where folks might get e.g. read access to a system before they get a full code execution. In such cases a pretty common thing to do - which does go a bit against the spirit of the competition on both sides - is to look for artifacts left by other teams. Commonly this might be looking at various service logs or looking for exploit left in – as jvoisin rightfully pointed out - in the classic /tmp directory. That way finder's team would cut the solution time by half by just re-using a left behind payload or exploit.

A different variant of this is in web challenges with a service where each team can freely create accounts. If one tries credentials like asdf/asdf, qwer/qwer, xyz/xyz, aaaa/aaaa, etc, one commonly gets logged into test accounts created by other teams. And if they were sloppy, they also left behind exploits or flags.

ETA: Seems there were even some published tools for /tmp surfing - see tmpleak (thank disconnect3d for pointing this out).

I guess this has the markings of unknowingly sharing solutions. I would really like to move away from answering the question of whether or not other teams are free to use the leftover artifacts. Instead, let me propose this:

Lesson for CTF organizers: Try to separate team interactions from each other as much as possible. And perhaps require strong passwords (why do I even need to write this for CTF hackers).

Sock puppet accounts (added 2022-07-23)

On twitter ocdsec reminded me of another abuse scenario, and that's acting like multiple teams, i.e. registering multiple accounts and submitting flags in all of them.

This has a couple of consequences - and the more flags a team like this gathers, the more harmful it gets. In the extreme case if a winning team does this, they can claim all the prizes (by just having their sock puppet accounts occupy the top of the leader board. Furthermore, it's highly impactful in the context of the global CTFTime.org ranking, especially that the place-related factor of the points received has a pretty steep curve. There is also the demotivational factor for other teams.

Lesson for CTF organizers: Ideally we should try to detect this form of abuse, but technically it's almost impossible. CTFs are at the end of the day a bit of an honor system.

This meme (added 2022-07-23)

I would like to sincerely apologize for not including this meme (and thank Alexander Fink and Rev for reminding me):

the FORBIDDEN ctf tactics the pros DONT want you to know! pic.twitter.com/rB7OthYK3x

— cts (@gf_256) December 16, 2019

Please give hints (added 2022-07-23)

Alexander Fink pointed out one more issue which I didn't originally include, as I didn't know which side to approach it from. But Alexander nailed it, so here it is: asking for hints.

What's acceptable on CTFs is asking the organizers if the challenge works, the flag in the system is the correct one, and whether the organizer's exploit does get the flag. It's also fine to discuss the challenge with the organizers if one thinks there's a bug. But challenges can be frustrating to the limit, and so it's really tempting to ask, or even beg for a hint. At the same time organizers of good CTFs, after checking that the challenge indeed works, usually reply with a variant of the classic "hack harder".

That said, some players are persistent enough to either annoy the organizer enough to get booted of discord, or to actually get a real hint. But since CTFs are NOT a competition in social engineering, this is of course beyond the accepted meta game. And on organizer's side it's also important to remember to share any accidentally revealed hint publicly, to level the playing field.

Lesson for CTF organizers: Don't give hint. Ever. Even if the challenge is unsolved after 90% of the CTF. And if you fail at this, immediately share the hint widely and publicly.

Buying hints (added 2022-07-31)

This one was pointed out by both Florian and j3r3mias. CTF organizers over the years experiment with various changes to the metagame in order to see what works and what doesn't. One of the ideas found on some older CTFs was the notion of buying hints. It's just what it sounds - players had the ability to pay with CTF points to buy pre-made hints to tasks they haven't solved yet. From the player perspective it was of course a bit random, since the hint might have been about something they have already moved through in the challenge. Also, if you bought too many hints, you couldn't really achieve top places any more since top teams made really sure to never, even accidentally, click on any buttons that might decrease their score.

The obvious way to cheat through this one, was to get a second team account, submit a few flags there, and buy all the hints you need without impacting your main team's score.

Needless to day that closing registration at competition start doesn't work - if one would plan this, they would just register a few extra accounts ahead of time. Also, closing registration during the competition is something we've stopped doing anyway.

Lesson for CTF organizers: Selling hints turned out to not be a good idea. Don't add this metagame to your CTFs.

Clickjacking, but with CTFs (added 2022-08-22)

A discussion with sahuang and UnblvR about a certain CTF led to this addition.

Assume there's a local CTF running on some conference / university / etc. One potential big brain no ethics move is to register an international CTF happening at the same time, and - once the local CTF starts - redirect all the challenges to the challenges of the local CTF. Why, the flag checking system could redirect flags to the local CTF's checker as well. And, by accident of course, it could be using your local CTF's account to "verify the flags". Oh, and don't forget to ask for write-ups from participants as the end (especially if you don't provide any prizes).

Lesson for CTF organizers: If you get too much traffic on a local CTF, you might want to check CTFTime for any 0-weight unknown CTFs running at the same time, and check if there is any similarity for the tasks. Given that such CTFs might turn off registration after the start, you might want to register before your event starts.

Additional discussion:
Twitter thread
Hacker News thread