Earlier this week, the Threema secure messaging service — a platform relied upon by enterprises, journalists, government bodies, and privacy-sensitive users precisely because of its security posture — was hit by multiple large-scale distributed denial-of-service (DDoS) attacks that severely disrupted communications. This is not a nuisance event. When an attacker can degrade a communications channel that organizations use as their trusted channel — including for incident coordination — they gain leverage that goes well beyond bandwidth exhaustion. During an active IR engagement, losing your out-of-band communications platform is a force multiplier for the adversary.
Defenders need to treat this as a prompt to answer two questions immediately: (1) Can we detect a DDoS onset within minutes rather than learning about it from user complaints? (2) Do we have a rehearsed playbook and upstream mitigations that work when the target is our own critical infrastructure? This post walks through the attack mechanics, detection content your SOC can deploy today, and concrete hardening steps.
Technical Analysis
What happened
Per reporting from BleepingComputer, Threema's infrastructure was targeted by multiple coordinated DDoS attacks that caused severe service disruption. The attacks did not compromise the platform's end-to-end encryption or message content — DDoS is an availability attack, not a confidentiality breach — but the effect on users was functionally similar to an outage: messages could not be sent or received reliably.
How DDoS attacks against messaging infrastructure typically work
Messaging platforms present a concentrated, high-value attack surface: centralized (or federated) connection brokers, WebSocket/TLS termination endpoints, API gateways, and push-notification relays. A typical multi-vector campaign against such infrastructure combines:
- Volumetric floods (L3/L4): UDP amplification (DNS, NTP, CLDAP, memcached reflection), SYN floods, and ACK floods aimed at saturating transit bandwidth or state tables on border devices and load balancers.
- Protocol-state exhaustion (L4): SYN floods and slow-connection attacks (Slowloris-style) that exhaust connection tracking tables on firewalls, TLS terminators, and reverse proxies long before link bandwidth is consumed.
- Application-layer floods (L7): HTTP/HTTPS request floods against login, message-relay, or API endpoints, often from rotating residential-proxy botnets to defeat simple IP reputation blocking. These are low-and-slow enough to blend with legitimate traffic and are the hardest to mitigate without behavioral controls.
Defenders should note the operational pattern in recent DDoS campaigns: attacks frequently arrive in waves, with short probing bursts followed by sustained multi-vector floods, and are often timed to coincide with geopolitical events or used as smoke screens for parallel intrusion activity. Treat any DDoS against your organization as a possible diversion — raise detection sensitivity on authentication, EDR, and lateral-movement analytics for the duration of the event.
Exploitation status
No CVE applies here; this is an operational attack campaign, not a software vulnerability. The attack technique maps to MITRE ATT&CK T1498 (Network Denial of Service) and T1499 (Endpoint Denial of Service). There is no vendor patch — defense is architectural, procedural, and contractual (upstream scrubbing, anycast distribution, rate limiting, and runbooks).
Detection & Response
The single biggest DDoS failure mode I see in SOCs is detection-by-complaint. Your telemetry should alert on onset signatures before users do. The detections below focus on the highest-signal, lowest-noise indicators: connection-state anomalies and volumetric deltas against baseline.
Sigma Rules
Rate-based detection is inherently limited in Sigma — these rules are designed to fire on the patterns that SIEM correlation and aggregation pipelines can key on. Deploy them against firewall, netflow, and web-server log sources, and pair with a threshold/aggregation layer (e.g., Sentinel scheduled analytics with bin() counts) to avoid per-event noise.
---
title: High Volume of Denied Connections to Public-Facing Service (Possible DDoS)
id: 3f7a1c92-8b4e-4d21-9c6a-2e8f5b0d1a47
status: experimental
description: Detects a surge of denied/dropped inbound connections toward public-facing services consistent with a volumetric or protocol-state DDoS attack against messaging or web infrastructure. Intended for aggregation-based deployment (count by destination over time window).
references:
- https://attack.mitre.org/techniques/T1498/
- https://www.bleepingcomputer.com/news/security/large-scale-ddos-attacks-disrupted-threema-secure-messaging-service/
author: Security Arsenal
date: 2026/01/15
tags:
- attack.impact
- attack.t1498
logsource:
category: firewall
detection:
selection:
action:
- denied
- dropped
- blocked
dst_port:
- 443
- 5222
- 5223
- 8443
condition: selection
falsepositives:
- Legitimate scanning activity at low volume (aggregate over time window and threshold)
- Misconfigured clients retrying connections
level: medium
---
title: Web Server Request Flood to Authentication or API Endpoints (L7 DDoS)
id: 9d2e5b18-4c7f-4a93-b8e1-6f0c3d9a2b55
status: experimental
description: Detects HTTP request floods against authentication, message-relay, or API endpoints indicative of application-layer DDoS. Deploy with aggregation (requests per source or per destination URI per minute) to distinguish attack traffic from load spikes.
references:
- https://attack.mitre.org/techniques/T1499/
- https://www.bleepingcomputer.com/news/security/large-scale-ddos-attacks-disrupted-threema-secure-messaging-service/
author: Security Arsenal
date: 2026/01/15
tags:
- attack.impact
- attack.t1499
logsource:
category: webserver
detection:
selection:
c-uri|contains:
- '/login'
- '/auth'
- '/api/'
- '/v1/'
- '/v2/'
- '/send'
- '/relay'
condition: selection
falsepositives:
- Legitimate peak-hour traffic (threshold on count per source IP per minute)
- Load balancer health checks (exclude known probe user agents)
level: medium
---
title: Excessive Half-Open TCP Connections (SYN Flood Indicator)
id: 6a1f8d34-2b9c-4e57-a3d8-7c4b0e6f2a91
status: experimental
description: Detects an abnormal accumulation of TCP connections in SYN-received state on a server, a hallmark of SYN flood attacks designed to exhaust connection state tables. Based on host-level netstat/TCP state telemetry.
references:
- https://attack.mitre.org/techniques/T1498/
author: Security Arsenal
date: 2026/01/15
tags:
- attack.impact
- attack.t1498
logsource:
category: network_connection
product: linux
detection:
selection:
ConnectionState:
- 'SYN_RECV'
- 'SYN_RECEIVED'
condition: selection
falsepositives:
- Burst of legitimate inbound connections during service restart (aggregate and threshold)
level: high
KQL (Microsoft Sentinel / Defender)
This hunt query works against firewall telemetry ingested via CEF/Syslog (CommonSecurityLog) and surfaces both volumetric spikes and top-talkers. The 3x-baseline approach is deliberate — it fires on genuine onset anomalies rather than absolute thresholds that either flood the queue or miss slow ramps.
// DDoS onset detection: denied connection spike vs. trailing baseline + top source ASNs/IPs
let window = 5m;
let baselinePeriod = 24h;
let baseline = CommonSecurityLog
| where TimeGenerated > ago(baselinePeriod) and TimeGenerated < ago(window)
| where DeviceAction in~ ("denied", "dropped", "blocked", "deny")
| summarize BaselineAvg = count() / (baselinePeriod / window);
CommonSecurityLog
| where TimeGenerated > ago(window)
| where DeviceAction in~ ("denied", "dropped", "blocked", "deny")
| summarize CurrentCount = count(),
UniqueSources = dcount(SourceIP),
TopSources = make_set(SourceIP, 20),
DestPorts = make_set(DestinationPort, 10)
by DestinationIP
| extend BaselineAvg = toscalar(baseline)
| where CurrentCount > 3 * BaselineAvg and UniqueSources > 100
| project DestinationIP, CurrentCount, BaselineAvg, UniqueSources, TopSources, DestPorts
| sort by CurrentCount desc;
// Companion hunt: L7 request flood per source against API/auth paths
Syslog
| where TimeGenerated > ago(15m)
| where SyslogMessage has_any ("/login", "/auth", "/api/", "/send", "/relay")
| parse SyslogMessage with * " " SrcIP " " *
| summarize Requests = count(), URIs = dcount(SyslogMessage) by SrcIP, bin(TimeGenerated, 1m)
| where Requests > 300
| sort by Requests desc;
Velociraptor VQL
For servers you control (web front ends, API gateways, relay hosts), this artifact surfaces connection-state exhaustion directly at the endpoint — the fastest ground-truth confirmation that a SYN flood or slow-connection attack is in progress versus an upstream link-saturation problem.
-- Hunt for TCP connection-state anomalies consistent with DDoS (SYN flood / connection exhaustion)
SELECT Pid,
Name AS Process,
Laddr.IP AS LocalIP,
Laddr.Port AS LocalPort,
Raddr.IP AS RemoteIP,
Raddr.Port AS RemotePort,
Status AS TcpState
FROM netstat()
WHERE Status =~ 'SYN_RECV|SYN_RECEIVED|TIME_WAIT|CLOSE_WAIT'
GROUP BY TcpState
ORDER BY TcpState
-- Companion: count connections per remote IP to spot top flooders on the host
SELECT Raddr.IP AS RemoteIP,
count(group=Raddr.IP) AS ConnCount,
Status AS TcpState
FROM netstat()
WHERE Laddr.Port in (443, 5222, 5223, 8443)
GROUP BY RemoteIP, TcpState
ORDER BY ConnCount DESC
LIMIT 50
Hardening Script
For self-hosted Linux front ends (reverse proxies, API gateways, chat/XMPP brokers), the following enables kernel-level SYN flood resilience, applies conservative rate limiting, and tightens connection tracking. Test in staging — overly aggressive conntrack limits can break legitimate high-connection workloads.
#!/bin/bash
# DDoS resilience hardening for Linux public-facing services
# Run as root. Tested targets: Ubuntu 22.04/24.04, RHEL 9 derivatives.
set -euo pipefail
echo "[+] Enabling TCP SYN cookies and tightening backlog..."
sysctl -w net.ipv4.tcp_syncookies=1
sysctl -w net.ipv4.tcp_max_syn_backlog=8192
sysctl -w net.ipv4.tcp_synack_retries=2
sysctl -w net.ipv4.tcp_syn_retries=2
echo "[+] Raising connection tracking capacity and shortening stale timeouts..."
sysctl -w net.netfilter.nf_conntrack_max=1048576
sysctl -w net.netfilter.nf_conntrack_tcp_timeout_syn_recv=20
sysctl -w net.netfilter.nf_conntrack_tcp_timeout_time_wait=15
echo "[+] Dropping bogus TCP flag combinations and ICMP redirects..."
sysctl -w net.ipv4.conf.all.rp_filter=1
sysctl -w net.ipv4.conf.all.accept_redirects=0
sysctl -w net.ipv4.icmp_echo_ignore_broadcasts=1
# Persist across reboot
cat > /etc/sysctl.d/99-ddos-hardening.conf <<'EOF'
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_syn_backlog = 8192
net.ipv4.tcp_synack_retries = 2
net.ipv4.tcp_syn_retries = 2
net.netfilter.nf_conntrack_max = 1048576
net.netfilter.nf_conntrack_tcp_timeout_syn_recv = 20
net.netfilter.nf_conntrack_tcp_timeout_time_wait = 15
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.icmp_echo_ignore_broadcasts = 1
EOF
echo "[+] Applying nftables rate limiting on 443 (per-source new-connection cap)..."
nft add table inet ddos_protect 2>/dev/null || true
nft add chain inet ddos_protect input '{ type filter hook input priority 0; policy accept; }'
nft add rule inet ddos_protect input tcp dport 443 ct state new limit rate over 100/second burst 200 packets drop
echo "[+] Verification snapshot:"
sysctl net.ipv4.tcp_syncookies net.ipv4.tcp_max_syn_backlog net.netfilter.nf_conntrack_max
nft list table inet ddos_protect
ss -s
echo "[+] Done. Monitor conntrack usage: watch -n5 'cat /proc/sys/net/netfilter/nf_conntrack_count'"
Remediation
There is no patch for DDoS — remediation is layered mitigation and readiness. Prioritize in this order:
- Upstream absorption first. Contractual scrubbing (Cloudflare, Akamai, Arbor/AED, or your ISP's DDoS mitigation service) is the only effective answer to true volumetric floods. If your link is saturated, nothing on-prem will save you. Verify your scrubbing SLA, activation procedure, and whether mitigation is always-on or on-demand — and test the failover path before you need it.
- Architectural distribution. Anycast-advertised front ends, geographically distributed TLS termination, and CDN-fronted API endpoints prevent single-point saturation. Messaging-style services should separate connection brokers from backend logic so brokers can scale horizontally behind the scrubbing layer.
- Rate limiting at every tier. Per-source and per-ASN connection/request caps at the edge (CDN/WAF), the load balancer, and the application. Protect authentication and message-relay endpoints specifically — they are the most common L7 targets because they are the most expensive per request.
- Harden state tables. Apply the kernel and conntrack tuning above to front-end hosts, load balancers, and firewalls. SYN-cookie support should be verified on your commercial border devices as well — many appliances ship with it disabled.
- Rehearse the runbook. Your DDoS playbook must cover: detection thresholds, scrubbing activation contacts and credentials, BGP/FLOWspec advertisement procedures, internal comms, and a public status-page template. Time-to-mitigate is the metric that matters; measure it in exercises.
- Protect your out-of-band comms. The Threema incident is the object lesson: if your IR coordination channel is a third-party service, it can be taken down — by attackers or as collateral damage. Maintain at least two independent out-of-band channels (e.g., a self-hosted platform plus an alternate provider), and ensure your IR retainer contacts, phone trees, and runbooks do not live inside the channel that might go down.
- Watch for the diversion. During any DDoS against your organization, elevate alerting on identity events (impossible travel, MFA fatigue, new device enrollment), EDR high-severity detections, and east-west traffic. DDoS as a smoke screen for intrusion or data exfiltration is a documented pattern.
If your organization depends on Threema or a similar secure messenger for operational or IR communications, validate your fallback channels this week — not during your next incident.
Related Resources
Security Arsenal Healthcare Cybersecurity AlertMonitor Platform Book a SOC Assessment healthcare Intel Hub
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.