Berlin's fake captcha: why proving when you knew matters as much as what you did

The breach

Sometime during the summer of 2026, someone at Berlin's senate administration for transport and environment opened a phishing email ^[1]. The email contained a fake captcha—a "prove you're not a robot" box that looked just like the real thing. Clicking it installed malware that gave the Rhysida ransomware group access to the network.

The details that matter aren't the technical ones. It's the timeline: when the breach was discovered, when it was escalated and when the authorities were told. Those are the dates that count under the rules, and they're the dates someone will ask about if things go wrong.

The captcha trick

The fake captcha is a neat piece of social engineering. Most of us click "I'm not a robot" without thinking, because that's what you do when a website asks. The box looked real, sat where you'd expect it and did exactly what it was supposed to: lower your guard.

It's like a postmark on a letter. You glance at it to check it's been through the system, but you don't study it for forgeries. That's what makes it work.

The malware didn't need to be sophisticated. It just needed someone to click.

What the Cybersecurity Act requires

Sweden's Cybersecurity Act came into force on 15 January 2026 ^[2]. It requires organisations in 18 sectors—including public administration, energy, transport and healthcare—to report significant incidents in three stages: an early warning within 24 hours of becoming aware, an incident notification within 72 hours and a final report within a month.

The 24-hour clock starts when you became aware, not when you decided it was serious or when the report was ready. It's like when you lose your bank card: the clock starts when you notice it's gone, not when it's convenient.

The Berlin case shows why that matters. If an authority can't show when it first knew about a breach, the regulator has to take its word for it. That's a problem when the timeline determines whether the rules were followed.

The evidence question

Incident response has a standard playbook: detect, contain, investigate, report and recover. The technical steps are well understood. What gets less attention is the administrative trail: the notes, the decisions and the timestamps.

When a supervisor asks why the early warning took 30 hours instead of 24, the answer comes down to timestamps. When did the first alert fire? When did someone escalate it? When was the decision made to report? Those questions all have answers, but only if the record was kept as events happened, not written up afterwards.

Logs and incident notes live in systems the same people could edit. That's fine most of the time, but it's a weakness when someone questions the timeline.

How a digital witness fits here

This is a case where a witness fits well, because the core problem is showing when each step happened.

The thing to seal is each milestone in the incident: the first detection note, the decision to escalate, the draft report and the final report as it was sent. Sealing takes a fingerprint of the record, not the record itself, so nothing leaves your systems. WitniumChain stores the fingerprint on a chain where even we can't change it ^[3].

If a supervisor later asks when you knew, you share the sealed record. They calculate the fingerprint again and check it against the one sealed at the time. If it matches, the record is exactly what was written on that day.

A witness doesn't replace your incident response plan or decide whether your response was adequate. It just shows that your timeline is the one recorded at the time, not one written to fit the deadline.

How it would work

1. At each step—first detection, escalation, draft report—you seal a fingerprint of the note or document.
2. The fingerprint goes to WitniumChain through the REST API, the SDK or the MCP server, and you get a witness ID back.
3. When someone asks, you share the record and its witness ID. Anyone can check that it hasn't changed since it was sealed.

Your system sends the fingerprint, not the content, so the incident details stay with you. To start, go to witniumchain.com. The first 2,000 witnesses a month are free ^[3].

What this means for you

If your organisation falls under the Cybersecurity Act, or NIS2 in another EU country, three questions are worth asking now:

• Do we have a record of when we first became aware of past incidents, in a form that would hold up if questioned?
• Could someone with administrator rights edit our incident notes or logs after the fact, and would we know?
• If a supervisor asked when we escalated an incident, could we show it?

The third question is the uncomfortable one, because the honest answer for many organisations is probably not.

What to watch

The Cybersecurity Act applies to essential and important entities across 18 sectors. The next reporting deadline under the act depends on when the next significant incident happens, which could be tomorrow.

Beyond Sweden, NIS2 is being implemented across the EU, with similar reporting rules. The principle is the same: the clock starts when you knew, and you need to be able to show when that was.

The details of the Berlin breach will emerge over time, but the lesson is already clear: proving when you knew matters as much as proving what you did.