Threema knocked offline by shifting DDoS attacks, Swiss messenger says
The encrypted messaging service and its Swiss hosting partner Nine faced sustained flood attacks that changed tactics to slip past defences.
Key points
- Threema, a paid Swiss encrypted messaging app, was disrupted on Tuesday evening and Wednesday morning this week by a series of distributed denial-of-service attacks.
- The floods hit both Threema and its colocation partner Nine, and the attackers kept changing patterns to defeat mitigation.
- Business customers on Threema Work were emailed on Wednesday morning; customers running Threema On-Prem on their own servers were unaffected.
- Threema has now added upstream DDoS filtering to reduce the load on its own network.
- Attribution has not been made public, and it is unclear whether Threema was the main target or one of several.
Threema, a paid encrypted messaging service run by a Swiss company of the same name, spent much of Tuesday evening and Wednesday morning fighting off a flood of junk internet traffic. The company confirmed the outage in a Friday post-mortem, first reported by BleepingComputer.
The attacks were distributed denial-of-service floods, known as DDoS, where attackers aim huge volumes of traffic at a service until it buckles under the load. Users in Switzerland, India and China reported that messages would not send. The status page briefly showed everything as green, because a separate technical fault was stopping it from updating. Threema took the page offline until it could be fixed.
What actually happened to the service?
Around 6pm UTC on Tuesday, Threema users started seeing their apps stuck on "Connecting" instead of "Connected". The company first blamed a network outage at its colocation partner, the Swiss hosting firm Nine. About three hours later it said the network issue had been resolved.
It had not. By Wednesday the picture was clearer: Threema and Nine were both being hit with sustained DDoS traffic. In its write-up, Threema said the attackers "continually changed" tactics to get around filtering, which is why defences that normally absorb these floods quietly could not keep up this time.
"It is not entirely clear whether Threema was the primary target or whether the attacks were directed at multiple targets," the company wrote. No group has claimed responsibility, and Threema has not named a suspect. In threat intelligence terms this is an unattributed disruptive event, with no public indicators tying it to a known cluster.
Who was affected, and who wasn't?
Regular Threema users on the standard app saw delayed or failed messages during the two windows of disruption. Business customers on Threema Work got an email on Wednesday morning warning them the service was unstable.
Organisations running Threema On-Prem, the version that lives on a customer's own servers, saw no impact at all because their traffic never touched Threema's hosted network.
| Product | Impact this week |
|---|---|
| Threema (consumer app) | Delayed and failed messages Tue evening, Wed morning |
| Threema Work | Same disruption; customers notified by email |
| Threema OnPrem | No impact, runs on customer infrastructure |
Should users worry about their messages?
No. A DDoS attack is a traffic flood, not a break-in. It knocks a service offline but does not read, alter or steal the content flowing through it. Threema's end-to-end encryption, which scrambles messages so only the sender and recipient can read them, was not touched by this incident. There is no indication any message content, contact list or key material was exposed.
What users should do is straightforward: if messages are delayed during a future incident, wait rather than resending repeatedly, and check Threema's status channel for updates once the status page is trustworthy again.
What is Threema changing?
The company says it has added "specialised DDoS protection as an additional measure" that filters attack traffic upstream, before it reaches Threema's own servers. That is the standard playbook after an incident like this: push the scrubbing further out into the network so the origin infrastructure sees a cleaner pipe.
Whether that holds up against an attacker willing to keep shifting patterns is the open question. This week's floods showed that a determined operator, targeting a hosting provider as well as the application, can still cause hours of pain for a service that had previously mitigated DDoS traffic without users noticing.
