Berlin ransomware attack: when the *fake CAPTCHA* was the way in

How a puzzle became a doorway

The attack started where most people wouldn't think twice: a CAPTCHA page. You know the drill: tick the box, prove you're not a robot, move on. Except this time the CAPTCHA was the robot, and it was there to break in.

Germany's Federal Office for Information Security (BSI) traced the Berlin ransomware attack back to this simple lure ^[1]. When someone clicked what looked like a routine verification step, it deployed TerminalFix malware instead. From there, the attackers moved through Berlin's public authority systems until the Rhysida group had enough to demand payment and, when that didn't work, leak 1.4 million records on the dark web ^[1].

A Swedish website fell for the same trick, using the same technique ^[1]. So this wasn't a one-off. It was a recipe.

The 24-hour rule, and when the clock starts

Sweden's Cybersecurity Act, which implements the EU's NIS2 directive, sets clear deadlines for incident reporting ^[2]. When something significant happens, you have 24 hours to send an early warning to the supervisory authority, 72 hours for the incident notification and a month for the final report.

The detail that catches people out is the starting point. The 24 hours begin when you became aware of the incident, not when you've worked out what happened or decided it's serious enough to report ^[2]. That clock doesn't care whether it's a weekend, whether the CISO is on leave or whether you're still trying to contain it.

For a fake CAPTCHA attack like this, the question is: when did your systems first log something odd, and when did someone notice it? Those timestamps matter, because they define whether you reported in time.

What an incident timeline shows

Say your monitoring flagged an unusual process at 14:32 on a Tuesday, someone escalated it to the security team at 16:10, and the decision to treat it as a significant incident was recorded at 09:05 the next morning. If the early warning went out at 11:00 on Wednesday, you're inside the 24 hours from awareness. If it went out Thursday morning, you're not, and someone will ask why.

That's the evidence question: can you show when each step was recorded, in a way that nobody can quietly adjust afterwards?

Access logs and monitoring records answer part of it. They show what the systems saw. The harder part is showing that the records themselves haven't been edited since the event, especially when the people who could answer that question are the same people who keep the logs.

A digital witness per detection note, escalation and report gives you something concrete. Here's what it does: each time a step is recorded, you seal a fingerprint of it with WitniumChain. The record itself stays in your systems. The fingerprint is permanent. If anyone later questions the timeline, you (or an auditor, or a supervisor) can recalculate the fingerprint and check it against the sealed one. Change a single character in the log and the check fails.

What it doesn't do: it doesn't show that your response was adequate, that the report was complete or that you contained the incident properly. It just makes the timeline harder to argue about.

How it would work

1. Seal the first detection note when monitoring flags the unusual activity.
2. Seal the escalation record when the security team decides to treat it as significant.
3. Seal each report as it's sent: early warning, incident notification and final report.

Anyone you share those records with can check them against the sealed fingerprints, without having to take your word for it. Technical details are in the documentation.

The fake CAPTCHA, and why it works

The CAPTCHA trick works because it looks so normal. Everyone's used to ticking a box before a download or a login. It doesn't set off alarm bells the way a dodgy attachment might.

TerminalFix, the malware deployed in this case, isn't new either ^[1]. What's interesting is the delivery method. A fake verification page can sit on a compromised site, a phishing email or even an ad network, and people click it without thinking.

Once it's in, it does what ransomware does: encrypts files, locks systems and leaves a note demanding payment. The Berlin attack ended with 1.4 million records leaked when the ransom wasn't paid ^[1]. For the authorities involved, that's not just an IT problem. It's a public trust problem.

What this means for you

If you're responsible for cybersecurity or incident response in a sector covered by the Cybersecurity Act, three questions are worth asking now:

• Do your monitoring systems log the first detection of unusual activity, and can you show when that log was written?
• When someone escalates an incident internally, is there a timestamped record of that decision?
• If you had to prove that your early warning went out within 24 hours of awareness, could you?

The answers don't have to be complicated. A detection note with a timestamp, an escalation email and a copy of the report, each sealed when it happens, gets you most of the way there.

It's also worth testing your own users with a simulated phishing exercise that includes a fake CAPTCHA. If half your team would click it, you know where the next training session needs to focus.

What to watch

The Cybersecurity Act applies from 15 January 2026 to essential and important entities across 18 sectors ^[2]. If you're in scope, the reporting deadlines are already in force.

Rhysida and similar groups are industrialising ransomware. Fake CAPTCHAs, fake updates and other low-friction lures are part of that industrialisation. The Berlin case won't be the last.

Watch for guidance from your sectoral supervisor on what counts as a significant incident in your area, and what level of detail they expect in the early warning. The MSB (Swedish Civil Contingencies Agency) and sectoral regulators will publish more detail over the coming months.