Norway ’s shared government infrastructure suffered a third DDoS attack, disrupting digital services but showing no signs of data compromise.

Norway ‘s shared digital government infrastructure has been hit by another distributed denial-of-service (DDoS) attack that disrupted services used by citizens, businesses and public agencies. The incident began at 03:38 CEST on Monday, August 24, and targeted infrastructure operated by the Norwegian Digitalisation Agency, Digdir, together with its service provider Vivicta.

The timing matters because this isn’t an isolated event. Digdir says it’s the third DDoS attack against its services in a short period, following incidents in June and on August 3.

“The Norwegian Directorate for Digitalisation (Digdir) has been subjected to a denial of service attack (DDoS attack) that has been ongoing since 03:38 on the night of Monday, August 24.” reads the statement published by Digdir Agency. “This is the third time in a short time that this type of attack has been directed at Digdir’s solutions. Digdir is working closely with our subcontractor Vivicta. NSM and the Norwegian Data Protection Authority have also been notified of the case.”

That status update refers to the test environment, but the underlying attack also affected production services. Digdir reported that several shared services became completely unavailable for short periods, while others remained accessible but suffered connection failures, slow responses and longer-than-usual login times.

Digdir operates several pieces of Norway’s shared public-sector infrastructure. Among them are ID-porten, MinID, Maskinporten, eFormidling, eInnsyn, the Contact and Reservation Register, Ansattporten and other services used by government agencies and external applications.

That makes an attack on Digdir more significant than an ordinary website outage. When a shared authentication service goes down, the disruption can propagate to services that aren’t themselves under attack.

That’s exactly what happened. Altinn, Norway’s central platform for communication between citizens, businesses and government, was also affected, while other public services relying on ID-porten experienced login problems. Earlier attacks this summer produced similar effects, including disruption to access to Helsenorge, NAV and Skatteetaten.

The technical distinction is important: the attackers didn’t need to break into every downstream service. They could create disruption simply by overwhelming a shared dependency.

And that’s often the uncomfortable reality of modern public infrastructure. The weakest point isn’t necessarily the service citizens see on their screens. It can be the common authentication, messaging or data-exchange layer underneath it.

Digdir has stressed that the incident is about availability, not evidence of a successful intrusion. The agency also says it has found no indication that personal data was exposed. Digdir has notified Norway’s National Security Authority, NSM, and the Data Protection Authority, Datatilsynet, as part of its response.

“There are no indications that the attack has led to a security breach or that personal data has been compromised, says Director Frode Danielsen at Digdir.” continues the statement.

That distinction deserves attention because cyberattack doesn’t automatically mean “data theft”. In this case, the confirmed impact is service disruption, while there is currently no evidence that attackers compromised Digdir’s systems or accessed personal information.

The operational consequences are still serious. Public-sector users may see failed connections, slow responses or authentication problems even though the underlying applications themselves haven’t been compromised.

The June incident already demonstrated how much disruption a DDoS attack against Digdir’s infrastructure can cause. That attack targeted ID-porten through Vivicta’s network infrastructure and temporarily affected services including ID-porten, MinID, Maskinporten, eInnsyn and eFormidling.

Another attack followed on August 3. Digdir restored normal operations the following day, but the agency said the incident had again affected several shared services and that it would review the event together with Vivicta and other partners.

Now there’s a third incident. That repetition is more interesting from a defensive perspective than the raw duration of any single outage.

Digdir and Vivicta are clearly able to mitigate the attacks and restore services. The harder question is whether repeated attacks against the same shared infrastructure can keep generating enough operational friction to become a recurring problem for the wider public sector.

This is where DDoS stops being just a bandwidth problem. A sufficiently persistent campaign can force defenders to keep changing traffic controls, filtering rules and protection measures, while legitimate users continue to depend on the same infrastructure.

Digdir’s own status updates show that dynamic clearly. On August 24, the agency first reported improvement, then said several solutions were completely down, followed by further stabilization efforts.

There is currently no official attribution for the attacks. Norwegian media have raised the possibility of Russian involvement, but that remains speculation rather than an established finding.

That distinction matters. A DDoS campaign can be politically motivated, financially motivated, conducted for disruption or simply intended to demonstrate capability. Without technical evidence and an official attribution process, assigning responsibility to a particular state or group would be premature.

What is established is the target and the effect. The attacks repeatedly hit infrastructure that sits underneath a large number of Norwegian digital public services.

That’s enough to make the incidents strategically relevant without adding an attribution story that the evidence doesn’t yet support.

The Norwegian case is also a useful reminder that cybersecurity isn’t limited to confidentiality and integrity. Availability is a security property too, particularly when the affected systems provide national digital services.

A compromised database is an obvious security incident. An authentication service that repeatedly becomes unavailable can create a different kind of problem: citizens can’t access services, businesses can’t complete procedures and government agencies may struggle to perform routine operations.

Digdir says its services have largely stabilized, although some disruptions remain. As of the latest incident updates, ID-porten still had limitations, eSignering remained unavailable because of those ID-porten restrictions, and some users were still reporting connection problems or increased response times with Maskinporten.

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, newsletter)

Large DDoS attacks disrupted Threema, causing severe communication outages. Threema On-Prem users were unaffected by the attacks.

Threema suffered multiple large-scale DDoS attacks that disrupted its secure messaging service and caused severe communication issues. Organizations using Threema On-Prem were not affected, as their deployments run on their own infrastructure.

Threema is a Swiss paid secure messaging service, similar to WhatsApp or Signal, focused heavily on privacy and security.

“If the attack originates simultaneously from multiple (and potentially changing) sources, it is referred to as a “Distributed Denial of Service” (DDoS) attack. This makes the attack significantly more difficult to defend against because it is not possible to simply block a single source.” reads the report. “Because sophisticated attackers constantly change their methods, sources, and attack patterns during an attack, a cat-and-mouse game ensues, with both sides continuously reacting to the other’s most recent action.”

Users began reporting Threema outages on Tuesday evening. The company initially blamed a network issue at its colocation provider, but later confirmed it was facing a series of DDoS attacks. The attacks caused intermittent disruptions into Wednesday, with users in several countries still reporting problems even after Threema’s status page showed the service as operational.

The company said a series of large-scale DDoS attacks also targeted its colocation partner, Nine. Attack patterns kept changing, making mitigation difficult. The service was unavailable for about four hours Tuesday evening, followed by intermittent outages Wednesday morning. Normal operations were restored at 12:23 p.m. CEST.

“It is not entirely clear whether Threema was the primary target or whether the attacks were directed at multiple targets. In any case, they continued over an extended period and their patterns were constantly adapted, making them difficult to defend against.” continues the report. “As a result of these attacks, Threema was unavailable on Tuesday between 7:30 p.m. and 11:30 p.m. CEST. The page providing information on the current system status was initially not updated due to a technical issue unrelated to the attack. We therefore temporarily took it offline until the problem was resolved.”

Threema communicated the service disruptions progressively through social media, while Threema Work customers received updates by email. To strengthen its defenses, Threema deployed additional upstream DDoS protection on August 14, filtering malicious traffic before it reached its infrastructure.

The company also plans to improve its status page with an incident history and RSS feed, giving users and administrators another way to receive independent service updates.

“We will also expand the status page in the coming days. The update will include an incident history and an RSS feed that interested users and Threema Work administrators can subscribe to in order to receive system updates through an independent channel.” concludes the report. “We apologize for any inconvenience caused and appreciate your understanding.”

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, DDoS)

“Business customers using Threema Work were informed via email on Wednesday morning about the unstable service conditions, and account managers provided information on the current situation in response to inquiries.”

To avoid similar incidents, the Swiss company has implemented “specialized DDoS protection as an additional measure” to filter attack traffic upstream and reduce the load on its infrastructure.

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, newsletter)

Kimwolf v7: The Android TV Botnet That Now Hides Its Traffic Behind Chrome Fingerprints and Ethereum

Palo Alto Networks Unit 42 discovered Kimwolf v7 on February 3, 2026, while hunting threats following public disclosures of the botnet’s earlier activity.

The new version substantially upgrades the DDoS capabilities and command infrastructure of a botnet that has been targeting Android TV boxes since August 2025, while its Linux counterpart AISURU has been active since mid-2024. The operators’ core objective hasn’t changed, build a large-scale DDoS platform, but the methods for sustaining it and hiding its traffic have become considerably more sophisticated.

“This version upgrades its distributed denial-of-service (DDoS) attack capabilities and the resilience of its command-and-control (C2) infrastructure. Kimwolf primarily affects Android TV boxes and set-top boxes.

Kimwolf v7 adds an HTTP/2-based DDoS flood that constructs complete browser fingerprints. This makes attack traffic more difficult to distinguish from legitimate browsing.” reads the report by Palo Alto Networks.

“The threat’s binary includes five hard-coded public Ethereum-based endpoints for resolving Ethereum Name Service (ENS) domains. ENS is a blockchain-based naming system used to obtain C2 addresses.”

The nghttp2 library powers the HTTP/2 flood and constructs headers that mirror legitimate Chrome browser behavior at the protocol level, making rate-limiting and fingerprint-based DDoS mitigation significantly harder.

On top of that, the botnet uses Ethereum’s naming service to resolve its command server address, querying five legitimate public blockchain RPC endpoints shuffled randomly before each attempt, which means blocking any individual endpoint does almost nothing.

“Kimwolf also carries a hard-coded Tor .onion hidden service as a backup and a local proxy architecture for flexible routing between clearnet and Tor.” continues the report. “The malware developers added this function to directly respond to C2 server takedown efforts in December 2025.”

The three-tier structure, Ethereum ENS, then Tor hidden service, then local proxy on 127.0.0.1:23075, is a direct operational response to two takedowns the botnet suffered in December 2025. The local proxy routes all C2 traffic through the same local address regardless of whether it’s going to the clearnet or Tor, which means the proxy component can be updated independently without redeploying the main bot binary. Unit 42 also identified what it assesses with moderate confidence to be an operator-controlled RPC facade at eth.rpcuniverse.com, based on its single-tenant hosting, registration timing, and exclusive presence in Kimwolf samples.

Kimwolf spreads by abusing residential proxy services to reach Android TV boxes that ship with Android Debug Bridge enabled on port 5555. Once tunneled into a local network through a proxy endpoint, attackers can install the malware without any authentication. The botnet masks itself as “netd_service” to blend in with legitimate Android system processes, and Unit 42 found eight APK packages distributed between October and December 2025 that masquerade as a system service called SystemService, probing for root access before executing a bundled kernel payload.

Version 7 also strips out all scanning, exploitation, and brute-force functionality from the main binary — the operators have separated the propagation pipeline from the DDoS core. External loaders now handle initial access, while the Kimwolf binary handles attacks and acts as a relay. The attack method count was consolidated from 43 text-named commands in earlier versions to 15 numbered methods covering layers 3 through 7, including the new HTTP/2 flood, a high-performance UDP flood with ARM NEON SIMD acceleration optimized for the processors in Android TV boxes, and a TLS/HTTPS flood. Unit 42 clustered C2 infrastructure across 22 IP addresses in Saint Petersburg, Russia, all sharing the same SSH host key between December 2025 and February 2026.

The defensive guidance from Unit 42 is straightforward: treat Android TV boxes as untrusted devices and segment them from enterprise networks. Disabling ADB or restricting it to USB-only access removes the primary way this botnet gets onto devices. For detection, watch for outbound HTTPS connections to Ethereum RPC endpoints from devices that normally have no business touching blockchain services, Tor circuit activity or SOCKS5 proxy traffic from TV boxes, connections to localhost port 23075, and any Android consumer device running a process named “netd_service.”

“Kimwolf v7 is a focused evolution of an already large-scale botnet. The HTTP/2 flood with Chrome browser fingerprinting complicates application-layer DDoS mitigation, as attack traffic now mirrors legitimate browser behavior at the protocol and header level.” concludes the report. “The three-tier C2 system (Ethereum ENS, Tor .onion, local proxy) indicates that the operators are investing in infrastructure built to withstand takedown operations.”

In March, the U.S. DoJ disrupted command-and-control infrastructure used by several IoT botnets, including AISURU, Kimwolf, JackSkid, and Mossad. The operation involved authorities from Canada and Germany, along with major tech companies, to target botnet operators and weaken their global cybercrime activities.

The AISURU/Kimwolf botnet was linked to a record-breaking DDoS attack that peaked at 31.4 Tbps and lasted just 35 seconds. Cloudflare said the November 2025 incident was part of a surge in hyper-volumetric HTTP DDoS attacks observed in late 2025, all automatically detected and mitigated.

Kimwolf is a newly discovered Android botnet linked to the Aisuru botnet that has infected over 1.8 million devices and issued more than 1.7 billion DDoS attack commands, according to XLab.

The Kimwol Android botnet primarily targets TV boxes, compiled using the NDK and equipped with DDoS, proxy forwarding, reverse shell, and file management functions. It encrypts sensitive data with a simple Stack XOR, uses DNS over TLS to hide communication, and authenticates C2 commands with elliptic curve digital signatures. Recent versions even incorporate EtherHiding to resist takedowns via blockchain domains.

Kimwolf follows a naming pattern of “niggabox + v[number]”; versions v4 and v5 have been tracked. By taking over one C2 domain, researchers observed around 2.7 million IPs interacting over three days, indicating a likely infection scale exceeding 1.8 million devices. Its infrastructure spans multiple C2s, global time zones, and versions, making it hard to estimate the total number of infections.

The botnet borrows the code from the Aisuru family, however, operators redesigned it to evade detection. Its primary function is traffic proxying, though it can execute massive DDoS attacks, as seen in a three-day period issuing 1.7 billion commands between November 19 and 22.

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, Kimwolf v7)