20. 12. 2025 Luca Zeni Blue Team, CTF Writeups

Infection Chain – Behind the scene

The year is almost to the end and there’s one thing that always marks this period: the end of one of our biggest and most hyped event. You probably already know what I’m talking about… but just in case you don’t (or even worse, have no idea what the most waited event of the year is) let me explain…

Every year, our teams gets together, scratches their heads, and tries to come up with a fun, challenging, and memorable CTF competition. This competition is thought for cybersecurity students who are hungry to learn, break/fix things, and compete. That event is the WPCTF, and this year we reached its 4th edition!

This year, I decided to join the team working behind the scenes to create the challenges. The idea of being on the “other side”, not as a player, but as a creator, really captivated me. It’s not an opportunity that comes around very often, and I knew it would be a great chance to learn a lot of stuff about how these events are actually built. In addition, let say that the CTF world is usually very offense-oriented, and our competition was no exception. That was exactly another reason why I wanted to contribute by creating something a bit different: a challenge with a more “defensive goal”.

The idea behind my challenge was pretty simple: give participants something “different”, out of their comfort zone and push them to experiment with a different approach. Instead of starting from an environment and trying to exploit vulnerabilities to gain control, I wanted them to move in the opposite direction. I gave them a compromised environment and asked them to trace everything back to the root cause of the compromise. In this article, I won’’’t go into the full write-up of the challenge (you can already find all the solutions here), but I want to share how the idea was born and how it took shape.

Challenge overview

The challenge description was: “Investigate a compromised workstation to identify the attack delivery, persistence, and encryption method.” Inside the workstation, participants had to find three flags: as the description hints, players had to understand how the malicious payload was delivered, how the “attacker” managed to maintain access to the machine, and finally, explore the possible ways an attacker could schedule a fake “ransomware” run.

Delivery method

Starting from the delivery method, I wanted the challenge to feel as realistic as possible. And as everyone knows, the weakest point in any security chain is usually the human factor. At the top of the list of real-world infection vectors is phishing, typically through deceptive emails containing malicious links or attachments. So that’s where my idea started: send a phishing email with a malicious attachment, and inside that attachment include a link that would trick the user into downloading additional malicious files.

On paper, this approach worked perfectly. But it also came with a couple of issues:
How do we deliver this email? And, more importantly, to whom? Letting 100 participants interact with the same mailbox at the same time was both impractical and risky, so I decided to simplify things. Instead of actually sending the phishing email, I just placed the malicious file directly in the Downloads folder. This way, players could still wonder how it got there, assume the “phished” user opened it, and follow the trail from the malicious attachment to the suspicious URL. This saved a lot of time in the challenge preparation and avoid the headache of managing a shared inbox.

Persistence

Talking about persistence there were hundreds of ways I could emulate it, some easy, some more complex. But the common idea behind any persistence mechanism is simple: it allows an attacker to maintain access to a machine no matter what. And that’s where I hit my first problem: How do I emulate persistence in a way that keeps the flag accessible, even if I know players are going to break the machine in every possible way?

Funny enough, the solution came from the problem itself. I decided to use an auto-start process, something that runs every time the user logs in. If you want to solve the challenge, you must access the machine anyway. Once you do, the flag is created by that scheduled process at login. A perfect win-win.

I’ll admit this was probably the least “realistic” flag of the three, but I couldn’t find a better way to guarantee the flag stayed in place no matter what the players do.

Scheduled Task

For the third and final flag, I needed to simulate a ready-to-run file encryption mechanism. My first idea was to write a script that would actually encrypt a few files over time as the challenge progressed. Then common sense came in: giving hundreds of people a working file encryption mechanism (even for a CTF) is probably not the smartest idea since you never really know what might happen. In addition, making the encryption dynamic would have been a mess, not only because of the implementation complexity, but also due to the risk of compromising the other flags.

So instead, I decided to fake this behavior. I created a file called NotARansomware.exe, purely as a decoy and I have to admit, it worked. A few players later told me they spent quite some time trying to understand how that file worked. Spoiler: it didn’t work at all.

In reality, that executable existed only to be referenced by a scheduled task. The flag was embedded in the description of that scheduled task. The idea was to mess with the task configuration and create something non-standard, something that could, in a real-world scenario, allow a malicious file to run at a specific time without the attacker even needing direct control of the machine.

Conclusion

In the end, what I enjoyed the most was watching how so many different people approached and solved the same challenge in completely different ways. I really appreciated all the feedback I received (even if not all were positive, but that’s part of the game). For those who are especially curious, there’s another post where I go deeper into the feedback and the improvements I’d make to the challenge.

Honestly, seeing players work through the challenge was far more exciting than creating it. Building it took a lot of time, came with plenty of problems, and involved more than a few moments of frustration. But looking back, every bit of effort was worth it and I’m very happy with how everything turned out.