The QingPing Air Quality Monitor 2 is an Android-based device that not only features a touch screen with the current air quality statistics of the room, but also includes an MQTT interface that normally is used in combination with the QingPing mobile app and the Xiaomi IoT ecosystem. Changing it to report to a local MQTT server instead for integration with e.g. Home Assistant can be done in an official way that still requires creating a cloud account, or you can just do it yourself via an ADB shell and some file modifications as [ea] has done.
By default these devices do not enumerate when you connect a computer to their USB-C port, but that’s easily resolved by enabling Android’s developer mode. This involves seven taps on the Device Name line in the About section of settings. After this you can enter Developer Options to toggle on Debug Mode and Adbd Debugging, which creates the option to connect to the device via USB with ADB and open up a shell with adb shell.
From there you can shoot off the QingSnow2 app and the watchdog.sh that’s running in the background, disable IPv6 and edit /etc/host to redirect all the standard cloud server calls to a local server. Apparently there is even SSH access at this point, with root access and password rockchip. The MQTT configuration is found under /data/etc/ in settings.ini, which is used by the QingPing app, so editing redirects all that.
Of course, the device also queries a remote server for weather data for your location, so if you modify this you have to provide a proxy, which [ea] did with a simple MQTT server that’s found along with other files on the GitHub project page.
Security researcher Jon “Gainsec” Gaines and YouTuber Benn Jordan discuss their examination of Flock Safety’s AI-powered license plate readers and how cost-driven design choices, outdated software, and weak security controls expose them to abuse.
Imagine you’re cruising down the highway in your brand-new electric car. All of a sudden, the massive multimedia display fills with Doom, the iconic 3D shooter game. It completely replaces the navigation map or the controls menu, and you realize someone is playing it remotely right now. This is not a dream or an overactive imagination – we’ve demonstrated that it’s a perfectly realistic scenario in today’s world.
The internet of things now plays a significant role in the modern world. Not only are smartphones and laptops connected to the network, but also factories, cars, trains, and even airplanes. Most of the time, connectivity is provided via 3G/4G/5G mobile data networks using modems installed in these vehicles and devices. These modems are increasingly integrated into a System-on-Chip (SoC), which uses a Communication Processor (CP) and an Application Processor (AP) to perform multiple functions simultaneously. A general-purpose operating system such as Android can run on the AP, while the CP, which handles communication with the mobile network, typically runs on a dedicated OS. The interaction between the AP, CP, and RAM within the SoC at the microarchitecture level is a “black box” known only to the manufacturer – even though the security of the entire SoC depends on it.
Bypassing 3G/LTE security mechanisms is generally considered a purely academic challenge because a secure communication channel is established when a user device (User Equipment, UE) connects to a cellular base station (Evolved Node B, eNB). Even if someone can bypass its security mechanisms, discover a vulnerability in the modem, and execute their own code on it, this is unlikely to compromise the device’s business logic. This logic (for example, user applications, browser history, calls, and SMS on a smartphone) resides on the AP and is presumably not accessible from the modem.
To find out, if that is true, we conducted a security assessment of a modern SoC, Unisoc UIS7862A, which features an integrated 2G/3G/4G modem. This SoC can be found in various mobile devices by multiple vendors or, more interestingly, in the head units of modern Chinese vehicles, which are becoming increasingly common on the roads. The head unit is one of a car’s key components, and a breach of its information security poses a threat to road safety, as well as the confidentiality of user data.
During our research, we identified several critical vulnerabilities at various levels of the Unisoc UIS7862A modem’s cellular protocol stack. This article discusses a stack-based buffer overflow vulnerability in the 3G RLC protocol implementation (CVE-2024-39432). The vulnerability can be exploited to achieve remote code execution at the early stages of connection, before any protection mechanisms are activated.
Importantly, gaining the ability to execute code on the modem is only the entry point for a complete remote compromise of the entire SoC. Our subsequent efforts were focused on gaining access to the AP. We discovered several ways to do so, including leveraging a hardware vulnerability in the form of a hidden peripheral Direct Memory Access (DMA) device to perform lateral movement within the SoC. This enabled us to install our own patch into the running Android kernel and execute arbitrary code on the AP with the highest privileges. Details are provided in the relevant sections.
Acquiring the modem firmware
The modem at the center of our research was found on the circuit board of the head unit in a Chinese car.
Circuit board of the head unit
Description of the circuit board components:
Number in the board photo
Component
1
Realtek RTL8761ATV 802.11b/g/n 2.4G controller with wireless LAN (WLAN) and USB interfaces (USB 1.0/1.1/2.0 standards)
2
SPRD UMW2652 BGA WiFi chip
3
55966 TYADZ 21086 chip
4
SPRD SR3595D (Unisoc) radio frequency transceiver
5
Techpoint TP9950 video decoder
6
UNISOC UIS7862A
7
BIWIN BWSRGX32H2A-48G-X internal storage, Package200-FBGA, ROM Type – Discrete, ROM Size – LPDDR4X, 48G
8
SCY E128CYNT2ABE00 EMMC 128G/JEDEC memory card
9
SPREADTRUM UMP510G5 power controller
10
FEI.1s LE330315 USB2.0 shunt chip
11
SCT2432STER synchronous step-down DC-DC converter with internal compensation
Using information about the modem’s hardware, we desoldered and read the embedded multimedia memory card, which contained a complete image of its operating system. We then analyzed the image obtained.
Remote access to the modem (CVE-2024-39431)
The modem under investigation, like any modern modem, implements several protocol stacks: 2G, 3G, and LTE. Clearly, the more protocols a device supports, the more potential entry points (attack vectors) it has. Moreover, the lower in the OSI network model stack a vulnerability sits, the more severe the consequences of its exploitation can be. Therefore, we decided to analyze the data packet fragmentation mechanisms at the data link layer (RLC protocol).
We focused on this protocol because it is used to establish a secure encrypted data transmission channel between the base station and the modem, and, in particular, it is used to transmit higher-layer NAS (Non-Access Stratum) protocol data. NAS represents the functional level of the 3G/UMTS protocol stack. Located between the user equipment (UE) and core network, it is responsible for signaling between them. This means that a remote code execution (RCE) vulnerability in RLC would allow an attacker to execute their own code on the modem, bypassing all existing 3G communication protection mechanisms.
3G protocol stack
The RLC protocol uses three different transmission modes: Transparent Mode (TM), Unacknowledged Mode (UM), and Acknowledged Mode (AM). We are only interested in UM, because in this mode the 3G standard allows both the segmentation of data and the concatenation of several small higher-layer data fragments (Protocol Data Units, PDU) into a single data link layer frame. This is done to maximize channel utilization. At the RLC level, packets are referred to as Service Data Units (SDU).
Among the approximately 75,000 different functions in the firmware, we found the function for handling an incoming SDU packet. When handling a received SDU packet, its header fields are parsed. The packet itself consists of a mandatory header, optional headers, and data. The number of optional headers is not limited. The end of the optional headers is indicated by the least significant bit (E bit) being equal to 0. The algorithm processes each header field sequentially, while their E-bits equal 1. During processing, data is written to a variable located on the stack of the calling function. The stack depth is 0xB4 bytes. The size of the packet that can be parsed (i.e., the number of headers, each header being a 2-byte entry on the stack) is limited by the SDU packet size of 0x5F0 bytes.
As a result, exploitation can be achieved using just one packet in which the number of headers exceeds the stack depth (90 headers). It is important to note that this particular function lacks a stack canary, and when the stack overflows, it is possible to overwrite the return address and some non-volatile register values in this function. However, overwriting is only possible with a value ending in one in binary (i.e., a value in which the least significant bit equals 1). Notably, execution takes place on ARM in Thumb mode, so all return addresses must have the least significant bit equal to 1. Coincidence? Perhaps.
In any case, sending the very first dummy SDU packet with the appropriate number of “correct” headers caused the device to reboot. However, at that moment, we had no way to obtain information on where and why the crash occurred (although we suspect the cause was an attempt to transfer control to the address 0xAABBCCDD, taken from our packet).
Gaining persistence in the system
The first and most important observation is that we know the pointer to the newly received SDU packet is stored in register R2. Return Oriented Programming (ROP) techniques can be used to execute our own code, but first we need to make sure it is actually possible.
We utilized the available AT command handler to move the data to RAM areas. Among the available AT commands, we found a suitable function – SPSERVICETYPE.
Next, we used ROP gadgets to overwrite the address 0x8CE56218 without disrupting the subsequent operation of the incoming SDU packet handling algorithm. To achieve this, it was sufficient to return to the function from which the SDU packet handler was called, because it was invoked as a callback, meaning there is no data linkage on the stack. Given that this function only added 0x2C bytes to the stack, we needed to fit within this size.
Stack overflow in the context of the operating system
Having found a suitable ROP chain, we launched an SDU packet containing it as a payload. As a result, we saw the output 0xAABBCCDD in the AT command console for SPSERVICETYPE. Our code worked!
Next, by analogy, we input the address of the stack frame where our data was located, but it turned out not to be executable. We then faced the task of figuring out the MPU settings on the modem. Once again, using the ROP chain method, we generated code that read the MPU table, one DWORD at a time. After many iterations, we obtained the following table.
The table shows what we suspected – the code section is only mapped for execution. An attempt to change the configuration resulted in another ROP chain, but this same section was now mapped with write permissions in an unused slot in the table. Because of MPU programming features, specifically the presence of the overlap mechanism and the fact that a region with a higher ID has higher priority, we were able to write to this section.
All that remained was to use the pointer to our data (still stored in R2) and patch the code section that had just been unlocked for writing. The question was what exactly to patch. The simplest method was to patch the NAS protocol handler by adding our code to it. To do this, we used one of the NAS protocol commands – MM information. This allowed us to send a large amount of data at once and, in response, receive a single byte of data using the MM status command, which confirmed the patching success.
As a result, we not only successfully executed our own code on the modem side but also established full two-way communication with the modem, using the high-level NAS protocol as a means of message delivery. In this case, it was an MM Status packet with the cause field equaling 0xAA.
However, being able to execute our own code on the modem does not give us access to user data. Or does it?
The full version of the article with a detailed description of the development of an AR exploit that led to Doom being run on the head unit is available on ICS CERT website.
We all encounter IoT and home automation in some form or another, from smart speakers to automated sensors that control water pumps. These services appear simple and straightforward to us, but many devices and protocols work together under the hood to deliver them.
One of those protocols is Zigbee. Zigbee is a low-power wireless protocol (based on IEEE 802.15.4) used by many smart devices to talk to each other. It’s common in homes, but is also used in industrial environments where hundreds or thousands of sensors may coordinate to support a process.
There are many guides online about performing security assessments of Zigbee. Most focus on the Zigbee you see in home setups. They often skip the Zigbee used at industrial sites, what I call ‘non-public’ or ‘industrial’ Zigbee.
In this blog, I will take you on a journey through Zigbee assessments. I’ll explain the basics of the protocol and map the attack surface likely to be found in deployments. I’ll also walk you through two realistic attack vectors that you might see in facilities, covering the technical details and common problems that show up in assessments. Finally, I will present practical ways to address these problems.
Zigbee introduction
Protocol overview
Zigbee is a wireless communication protocol designed for low-power applications in wireless sensor networks. Based on the IEEE 802.15.4 standard, it was created for short-range and low-power communication. Zigbee supports mesh networking, meaning devices can connect through each other to extend the network range. It operates on the 2.4 GHz frequency band and is widely used in smart homes, industrial automation, energy monitoring, and many other applications.
You may be wondering why there’s a need for Zigbee when Wi-Fi is everywhere? The answer depends on the application. In most home setups, Wi-Fi works well for connecting devices. But imagine you have a battery-powered sensor that isn’t connected to your home’s electricity. If it used Wi-Fi, its battery would drain quickly – maybe in just a few days – because Wi-Fi consumes much more power. In contrast, the Zigbee protocol allows for months or even years of uninterrupted work.
Now imagine an even more extreme case. You need to place sensors in a radiation zone where humans can’t go. You drop the sensors from a helicopter and they need to operate for months without a battery replacement. In this situation, power consumption becomes the top priority. Wi-Fi wouldn’t work, but Zigbee is built exactly for this kind of scenario.
Also, Zigbee has a big advantage if the area is very large, covering thousands of square meters and requiring thousands of sensors: it supports thousands of nodes in a mesh network, while Wi-Fi is usually limited to hundreds at most.
There are lots more ins and outs, but these are the main reasons Zigbee is preferred for large-scale, low-power sensor networks.
Since both Zigbee and IEEE 802.15.4 define wireless communication, many people confuse the two. The difference between them, to put it simply, concerns the layers they support. IEEE 802.15.4 defines the physical (PHY) and media access control (MAC) layers, which basically determine how devices send and receive data over the air. Zigbee (as well as other protocols like Thread, WirelessHART, 6LoWPAN, and MiWi) builds on IEEE 802.15.4 by adding the network and application layers that define how devices form a network and communicate.
Zigbee operates in the 2.4 GHz wireless band, which it shares with Wi-Fi and Bluetooth. The Zigbee band includes 16 channels, each with a 2 MHz bandwidth and a 5 MHz gap between channels.
This shared frequency means Zigbee networks can sometimes face interference from Wi-Fi or Bluetooth devices. However, Zigbee’s low power and adaptive channel selection help minimize these conflicts.
Devices and network
There are three main types of Zigbee devices, each of which plays a different role in the network.
Zigbee coordinator
The coordinator is the brain of the Zigbee network. A Zigbee network is always started by a coordinator and can only contain one coordinator, which has the fixed address 0x0000.
It performs several key tasks:
Starts and manages the Zigbee network.
Chooses the Zigbee channel.
Assigns addresses to other devices.
Stores network information.
Chooses the PAN ID: a 2-byte identifier (for example, 0x1234) that uniquely identifies the network.
Sets the Extended PAN ID: an 8-byte value, often an ASCII name representing the network.
The coordinator can have child devices, which can be either Zigbee routers or Zigbee end devices.
Zigbee router
The router works just like a router in a traditional network: it forwards data between devices, extends the network range and can also accept child devices, which are usually Zigbee end devices.
Routers are crucial for building large mesh networks because they enable communication between distant nodes by passing data through multiple hops.
Zigbee end device
The end device, also referred to as a Zigbee endpoint, is the simplest and most power-efficient type of Zigbee device. It only communicates with its parent, either a coordinator or router, and sleeps most of the time to conserve power. Common examples include sensors, remotes, and buttons.
Zigbee end devices do not accept child devices unless they are configured as both a router and an endpoint simultaneously.
Each of these device types, also known as Zigbee nodes, has two types of address:
Short address: two bytes long, similar to an IP address in a TCP/IP network.
Extended address: eight bytes long, similar to a MAC address.
Both addresses can be used in the MAC and network layers, unlike in TCP/IP, where the MAC address is used only in Layer 2 and the IP address in Layer 3.
Zigbee setup
Zigbee has many attack surfaces, such as protocol fuzzing and low-level radio attacks. In this post, however, I’ll focus on application-level attacks. Our test setup uses two attack vectors and is intentionally small to make the concepts clear.
In our setup, a Zigbee coordinator is connected to a single device that functions as both a Zigbee endpoint and a router. The coordinator also has other interfaces (Ethernet, Bluetooth, Wi-Fi, LTE), while the endpoint has a relay attached that the coordinator can switch on or off over Zigbee. This relay can be triggered by events coming from any interface, for example, a Bluetooth command or an Ethernet message.
Our goal will be to take control of the relay and toggle its state (turn it off and on) using only the Zigbee interface. Because the other interfaces (Ethernet, Bluetooth, Wi-Fi, LTE) are out of scope, the attack must work by hijacking Zigbee communication.
For the purposes of this research, we will attempt to hijack the communication between the endpoint and the coordinator. The two attack vectors we will test are:
Spoofed packet injection: sending forged Zigbee commands made to look like they come from the coordinator to trigger the relay.
Coordinator impersonation (rejoin attack): impersonating the legitimate coordinator to trick the endpoint into joining the attacker-controlled coordinator and controlling it directly.
Spoofed packet injection
In this scenario, we assume the Zigbee network is already up and running and that both the coordinator and endpoint nodes are working normally. The coordinator has additional interfaces, such as Ethernet, and the system uses those interfaces to trigger the relay. For instance, a command comes in over Ethernet and the coordinator sends a Zigbee command to the endpoint to toggle the relay. Our goal is to toggle the relay by injecting simulated legitimate Zigbee packets, using only the Zigbee link.
Sniffing
The first step in any radio assessment is to sniff the wireless traffic so we can learn how the devices talk. For Zigbee, a common and simple tool is the nRF52840 USB dongle by Nordic Semiconductor. With the official nRF Sniffer for 802.15.4 firmware, the dongle can run in promiscuous mode to capture all 802.15.4/Zigbee traffic. Those captures can be opened in Wireshark with the appropriate dissector to inspect the frames.
How do you find the channel that’s in use?
Zigbee runs on one of the 16 channels that we mentioned earlier, so we must set the sniffer to the same channel that the network uses. One practical way to scan the channels is to change the sniffer channel manually in Wireshark and watch for Zigbee traffic. When we see traffic, we know we’ve found the right channel.
After selecting the channel, we will be able to see the communication between the endpoint and the coordinator, though it will most likely be encrypted:
In the “Info” column, we can see that Wireshark only identifies packets as Data or Command without specifying their exact type, and that’s because the traffic is encrypted.
Even when Zigbee payloads are encrypted, the network and MAC headers remain visible. That means we can usually read things like source and destination addresses, PAN ID, short and extended MAC addresses, and frame control fields. The application payload (i.e., the actual command to toggle the relay) is typically encrypted at the Zigbee network/application layer, so we won’t see it in clear text without encryption keys. Nevertheless, we can still learn enough from the headers.
Decryption
Zigbee supports several key types and encryption models. In this post, we’ll keep it simple and look at a case involving only two security-related devices: a Zigbee coordinator and a device that is both an endpoint and a router. That way, we’ll only use a network encryption model, whereas with, say, mesh networks there can be various encryption models in use.
The network encryption model is a common concept. The traffic that we sniffed earlier is typically encrypted using the network key. This key is a symmetric AES-128 key shared by all devices in a Zigbee network. It protects network-layer packets (hop-by-hop) such as routing and broadcast packets. Because every router on the path shares the network key, this encryption method is not considered end-to-end.
Depending on the specific implementation, Zigbee can use two approaches for application payloads:
Network-layer encryption (hop-by-hop): the network key encrypts the Application Support Sublayer (APS) data, the sublayer of the application layer in Zigbee. In this case, each router along the route can decrypt the APS payload. This is not end-to-end encryption, so it is not recommended for transmitting sensitive data.
Link key (end-to-end) encryption: a link key, which is also an AES-128 key, is shared between two devices (for example, the coordinator and an endpoint).
The link key provides end-to-end protection of the APS payload between the two devices.
Because the network key could allow an attacker to read and forge many types of network traffic, it must be random and protected. Exposing the key effectively compromises the entire network.
When a new device joins, the coordinator (Trust Center) delivers the network key using a Transport Key command. That transport packet must be protected by a link key so the network key is not exposed in clear text. The link key authenticates the joining device and protects the key delivery.
The image below shows the transport packet:
There are two common ways link keys are provided:
Pre-installed: the device ships with an installation code or link key already set.
Key establishment: the device runs a key-establishment protocol.
A common historical problem is the global default Trust Center link key, “ZigBeeAlliance09”. It was included in early versions of Zigbee (pre-3.0) to facilitate testing and interoperability. However, many vendors left it enabled on consumer devices, and that has caused major security issues. If an attacker knows this key, they can join devices and read or steal the network key.
Newer versions – Zigbee 3.0 and later – introduced installation codes and procedures to derive unique link keys for each device. An installation code is usually a factory-assigned secret (often encoded on the device label) that the Trust Center uses to derive a unique link key for the device in question. This helps avoid the problems caused by a single hard-coded global key.
Unfortunately, many manufacturers still ignore these best practices. During real assessments, we often encounter devices that use default or hard-coded keys.
How can these keys be obtained?
If an endpoint has already joined the network and communicates with the coordinator using the network key, there are two main options for decrypting traffic:
Guess or brute-force the network key. This is usually impractical because a properly generated network key is a random AES-128 key.
Force the device to rejoin and capture the transport key. If we can make the endpoint leave the network and then rejoin, the coordinator will send the transport key. Capturing that packet can reveal the network key, but the transport key itself is protected by the link key. Therefore, we still need the link key.
To obtain the network and link keys, many approaches can be used:
The well-known default link key, ZigBeeAlliance09. Many legacy devices still use it.
Identify the device manufacturer and search for the default keys used by that vendor. We can find the manufacturer by:
Checking the device MAC/OUI (the first three bytes of the 64-bit extended address often map to a vendor).
Physically inspecting the device (label, model, chip markings).
Extract the firmware from the coordinator or device if we have physical access and search for hard-coded keys inside the firmware images.
Once we have the relevant keys, the decryption process is straightforward:
Open the capture in Wireshark.
Go to Edit -> Preferences -> Protocols -> Zigbee.
Add the network key and any link keys in our possession.
Wireshark will then show decrypted APS payloads and higher-level Zigbee packets.
After successful decryption, packet types and readable application commands will be visible, such as Link Status or on/off cluster commands:
Choose your gadget
Now that we can read and potentially decrypt traffic, we need hardware and software to inject packets over the Zigbee link between the coordinator and the endpoint. To keep this practical and simple, I opted for cheap, widely available tools that are easy to set up.
For the hardware, I used the nRF52840 USB dongle, the same device we used for sniffing. It’s inexpensive, easy to find, and supports IEEE 802.15.4/Zigbee, so it can sniff and transmit.
The dongle runs the firmware we can use. A good firmware platform is Zephyr RTOS. Zephyr has an IEEE 802.15.4 radio API that enables the device to receive raw frames, essentially enabling sniffer mode, as well as send raw frames as seen in the snippets below.
Using this API and other components, we created a transceiver implementation written in C, compiled it to firmware, and flashed it to the dongle. The firmware can expose a simple runtime interface, such as a USB serial port, which allows us to control the radio from a laptop.
At runtime, the dongle listens on the serial port (for example, /dev/ttyACM1). Using a script, we can send it raw bytes, which the firmware will pass to the radio API and transmit to the channel. The following is an example of a tiny Python script to open the serial port:
I used the Scapy tool with the 802.15.4/Zigbee extensions to build Zigbee packets. Scapy lets us assemble packets layer-by-layer – MAC → NWK → APS → ZCL – and then convert them to raw bytes to send to the dongle. We will talk about APS and ZCL in more detail later.
Here is an example of how we can use Scapy to craft an APS layer packet:
from scapy.layers.dot15d4 import Dot15d4, Dot15d4FCS, Dot15d4Data, Dot15d4Cmd, Dot15d4Beacon, Dot15d4CmdAssocResp
from scapy.layers.zigbee import ZigbeeNWK, ZigbeeAppDataPayload, ZigbeeSecurityHeader, ZigBeeBeacon, ZigbeeAppCommandPayload
Before sending, the packet must be properly encrypted and signed so the endpoint accepts it. That means applying AES-CCM (AES-128 with MIC) using the network key (or the correct link key) and adhering to Zigbee’s rules for packet encryption and MIC calculation. This is how we implemented the encryption and MIC in Python (using a cryptographic library) after building the Scapy packet. We then sent the final bytes to the dongle.
This is how we implemented the encryption and MIC:
Crafting the packet
Now that we know how to inject packets, the next question is what to inject. To toggle the relay, we simply need to send the same type of command that the coordinator already sends. The easiest way to find that command is to sniff the traffic and read the application payload. However, when we look at captures in Wireshark, we can see many packets under ZCL marked [Malformed Packet].
A “malformed” ZCL packet usually means Wireshark could not fully interpret the packet because the application layer is non-standard or lacks details Wireshark expects. To understand why this happens, let’s look at the Zigbee application layer.
Application Support Sublayer (APS): routes messages to the correct profile, endpoint, and cluster, and provides application-level security.
Application Framework (AF): contains the application objects that implement device functionality. These objects reside on endpoints (logical addresses 1–240) and expose clusters (sets of attributes and commands).
Zigbee Cluster Library (ZCL): defines standard clusters and commands so devices can interoperate.
Zigbee Device Object (ZDO): handles device discovery and management (out of scope for this post).
To make sense of application traffic, we must introduce three concepts:
Profile: a rulebook for how devices should behave for a specific use case. Public (standard) profiles are managed by the Connectivity Standards Alliance (CSA). Vendors can also create private profiles for proprietary features.
Cluster: a set of attributes and commands for a particular function. For example, the On/Off cluster contains On and Off commands and an OnOff attribute that displays the current state.
Endpoint: a logical “port” on the device where a profile and clusters reside. A device can host multiple endpoints for different functions.
Putting all this together, in the standard home automation traffic we see APS pointing to the home automation profile, the On/Off cluster, and a destination endpoint (for example, endpoint 1). In ZCL, the byte 0x00 often means “Off”.
In many industrial setups, vendors use private profiles or custom application frameworks. That’s why Wireshark can’t decode the packets; the AF payload is custom, so the dissector doesn’t know the format.
So how do we find the right bytes to toggle the switch when the application is private? Our strategy has two phases.
Passive phase
Sniff traffic while the system is driven legitimately. For example, trigger the relay from another interface (Ethernet or Bluetooth) and capture the Zigbee packets used to toggle the relay. If we can decrypt the captures, we can extract the application payload that correlates with the on/off action.
Active phase
With the legitimate payload at hand, we can now turn to creating our own packet. There are two ways to do that. First, we need to replay or duplicate the captured application payload exactly as it is. This works if there are no freshness checks like sequence numbers. Otherwise, we have to reverse-engineer the payload and adjust any counters or fields that prevent replay. For instance, many applications include an application-level counter. If the device ignores packets with a lower application counter, we must locate and increment that counter when we craft our packet.
Another important protective measure is the frame counter inside the Zigbee security header (in the network header security fields). The frame counter prevents replay attacks; the receiver expects the frame counter to increase with each new packet, and will reject packets with a lower or repeated counter.
So, in the active phase, we must:
Sniff the traffic until the coordinator sends a valid packet to the endpoint.
Decrypt the packet, extract the counters and increase them by one.
Build a packet with the correct APS/AF fields (profile, endpoint, cluster).
Include a valid ZCL command or the vendor-specific payload that we identified in the passive phase.
Encrypt and sign the packet with the correct network or link key.
Make sure both the application counter (if used) and the Zigbee frame counter are modified so the packet is accepted.
The whole strategy for this phase will look like this:
If all of the above are handled correctly, we will be able to hijack the Zigbee communication and toggle the relay (turn it off and on) using only the Zigbee link.
Coordinator impersonation (rejoin attack)
The goal of this attack vector is to force the Zigbee endpoint to leave its original coordinator’s network and join our spoofed network so that we can take control of the device. To do this, we must achieve two things:
Force the endpoint to leave the original network.
Spoof the original coordinator and trick the node into joining our fake coordinator.
Force leaving
To better understand how to manipulate endpoint connections, let’s first describe the concept of a beacon frame. Beacon frames are periodic announcements sent by a coordinator and by routers. They advertise the presence of a network and provide join information, such as:
PAN ID and Extended PAN ID
Coordinator address
Stack/profile information
Device capacity (for example, whether the coordinator can accept child devices)
When a device wants to join, it sends a beacon request across Zigbee channels and waits for beacon replies from nearby coordinators/routers. Even if the network is not beacon-enabled for regular synchronization, beacon frames are still used during the join/discovery process, so they are mandatory when a node tries to discover networks.
Note that beacon frames exist at both the Zigbee and IEEE 802.15.4 levels. The MAC layer carries the basic beacon structure that Zigbee then extends with network-specific fields.
Now, we can force the endpoint to leave its network by abusing how Zigbee handles PAN conflicts. If a coordinator sees beacons from another coordinator using the same PAN ID and the same channel, it may trigger a PAN ID conflict resolution. When that happens, the coordinator can instruct its nodes to change PAN ID and rejoin, which causes them to leave and then attempt to join again. That rejoin window gives us an opportunity to advertise a spoofed coordinator and capture the joining node.
In the capture shown below, packet 7 is a beacon generated by our spoofed coordinator using the same PAN ID as the real network. As a result, the endpoint with the address 0xe8fa leaves the network (see packets 14–16).
Choose me
After forcing the endpoint to leave its original network by sending a fake beacon, the next step is to make the endpoint choose our spoofed coordinator. At this point, we assume we already have the necessary keys (network and link keys) and understand how the application behaves.
To impersonate the original coordinator, our spoofed coordinator must reply to any beacon request the endpoint sends. The beacon response must include the same Extended PAN ID (and other fields) that the endpoint expects. If the endpoint deems our beacon acceptable, it may attempt to join us.
I can think of two ways to make the endpoint prefer our coordinator.
Jam the real coordinator
Use a device that reduces the real coordinator’s signal at the endpoint so that it appears weaker, forcing the endpoint to prefer our beacon. This requires extra hardware.
Exploit undefined or vendor-specific behavior
Zigbee stacks sometimes behave slightly differently across vendors. One useful field in a beacon is the Update ID field. It increments when a coordinator changes network configuration.
If two coordinators advertise the same Extended PAN ID but one has a higher Update ID, some stacks will prefer the beacon with the higher Update ID. This is undefined behavior across implementations; it works on some stacks but not on others. In my experience, sometimes it works and sometimes it fails. There are lots of other similar quirks we can try during an assessment.
Even if the endpoint chooses our fake coordinator, the connection may be unstable. One main reason for that is the timing. The endpoint expects ACKs for the frames it sends to the coordinator, as well as fast responses regarding connection initiation packets. If our responder is implemented in Python on a laptop that receives packets, builds responses, and forwards them to a dongle, the round trip will be too slow. The endpoint will not receive timely ACKs or packets and will drop the connection.
In short, we’re not just faking a few packets; we’re trying to reimplement parts of Zigbee and IEEE 802.15.4 that must run quickly and reliably. This is usually too slow for production stacks when done in high-level, interpreted code.
A practical fix is to run a real Zigbee coordinator stack directly on the dongle. For example, the nRF52840 dongle can act as a coordinator if flashed with the right Nordic SDK firmware (see Nordic’s network coordinator sample). That provides the correct timing and ACK behavior needed for a stable connection.
However, that simple solution has one significant disadvantage. In industrial deployments we often run into incompatibilities. In my tests I compared beacons from the real coordinator and the Nordic coordinator firmware. Notable differences were visible in stack profile headers:
The stack profile identifies the network profile type. Common values include 0x00, which is a network-specific (private) profile, and 0x02, which is a Zigbee Pro (public) profile.
If the endpoint expects a network-specific profile (i.e., it uses a private vendor profile) and we provide Zigbee Pro, the endpoint will refuse to join. Devices that only understand private profiles will not join public-profile networks, and vice versa. In my case, I could not change the Nordic firmware to match the proprietary stack profile, so the endpoint refused to join.
Because of this discrepancy, the “flash a coordinator firmware on the dongle” fix was ineffective in that environment. This is why the standard off-the-shelf tools and firmware often fail in industrial cases, forcing us to continue working with and optimizing our custom setup instead.
Back to the roots
In our previous test setup we used a sniffer in promiscuous mode, which receives every frame on the air regardless of destination. Real Zigbee (IEEE 802.15.4) nodes do not work like that. At the MAC/802.15.4 layer, a node filters frames by PAN ID and destination address. A frame is only passed to upper layers if the PAN ID matches and the destination address is the node’s address or a broadcast address.
We can mimic that real behavior on the dongle by running Zephyr RTOS and making the dongle act as a basic 802.15.4 coordinator. In that role, we set a PAN ID and short network address on the dongle so that the radio only accepts frames that match those criteria. This is important because it allows the dongle to handle auto-ACKs and MAC-level timing: the dongle will immediately send ACKs at the MAC level.
With the dongle doing MAC-level work (sending ACKs and PAN filtering), we can implement the Zigbee logic in Python. Scapy helps a lot with packet construction: we can create our own beacons with the headers matching those of the original coordinator, which solves the incompatibility problem. However, we must still implement the higher-level Zigbee state machine in our code, including connection initiation, association, network key handling, APS/AF behavior, and application payload handling. That’s the hardest part.
There is one timing problem that we cannot solve in Python: the very first steps of initiating a connection require immediate packet responses. To handle this issue, we implemented the time-critical parts in C on the dongle firmware. For example, we can statically generate the packets for connection initiation in Python and hard-code them in the firmware. Then, using “if” statements, we can determine how to respond to each packet from the endpoint.
So, we let the dongle (C/Zephyr) handle MAC-level ACKs and the initial association handshake, but let Python build higher-level packets and instruct the dongle what to send next when dealing with the application level. This hybrid model reduces latency and maintains a stable connection. The final architecture looks like this:
Deliver the key
Here’s a quick recap of how joining works: a Zigbee endpoint broadcasts beacon requests across channels, waits for beacon responses, chooses a coordinator, and sends an association request, followed by a data request to identify its short address. The coordinator then sends a transport key packet containing the network key. If the endpoint has the correct link key, it can decrypt the transport key packet and obtain the network key, meaning it has now been authenticated. From that point on, network traffic is encrypted with the network key. The entire process looks like this:
The sticking point is the transport key packet. This packet is protected using the link key, a per-device key shared between the coordinator (Trust Center) and the joining endpoint. Before the link key can be used for encryption, it often needs to be processed (hashed/derived) according to Zigbee’s key derivation rules. Since there is no trivial Python implementation that implements this hashing algorithm, we may need to implement the algorithm ourselves.
Now that we’ve managed to obtain the hashed link key and deliver it to the endpoint, we can successfully mimic a coordinator.
The final success
If we follow the steps above, we can get the endpoint to join our spoofed coordinator. Once the endpoint joins, it will often remain associated with our coordinator, even after we power it down (until another event causes it to re-evaluate its connection). From that point on, we can interact with the device at the application layer using Python. Getting access as a coordinator allowed us to switch the relay on and off as intended, but also provided much more functionality and control over the node.
Conclusion
In conclusion, this study demonstrates why private vendor profiles in industrial environments complicate assessments: common tools and frameworks often fail, necessitating the development of custom tools and firmware. We tested a simple two-node scenario, but with multiple nodes the attack surface changes drastically and new attack vectors emerge (for example, attacks against routing protocols).
As we saw, a misconfigured Zigbee setup can lead to a complete network compromise. To improve Zigbee security, use the latest specification’s security features, such as using installation codes to derive unique link keys for each device. Also, avoid using hard-coded or default keys. Finally, it is not recommended to use the network key encryption model. Add another layer of security in addition to the network level protection by using end-to-end encryption at the application level.
On December 4, 2025, researchers published details on the critical vulnerability CVE-2025-55182, which received a CVSS score of 10.0. It has been unofficially dubbed React2Shell, as it affects React Server Components (RSC) functionality used in web applications built with the React library. RSC speeds up UI rendering by distributing tasks between the client and the server. The flaw is categorized as CWE-502 (Deserialization of Untrusted Data). It allows an attacker to execute commands, as well as read and write files in directories accessible to the web application, with the server process privileges.
Almost immediately after the exploit was published, our honeypots began registering attempts to leverage CVE-2025-55182. This post analyzes the attack patterns, the malware that threat actors are attempting to deliver to vulnerable devices, and shares recommendations for risk mitigation.
A brief technical analysis of the vulnerability
React applications are built on a component-based model. This means each part of the application or framework should operate independently and offer other components clear, simple methods for interaction. While this approach allows for flexible development and feature addition, it can require users to download large amounts of data, leading to inconsistent performance across devices. This is the challenge React Server Components were designed to address.
The vulnerability was found within the Server Actions component of RSC. To reach the vulnerable function, the attacker just needs to send a POST request to the server containing a serialized data payload for execution. Part of the functionality of the handler that allows for unsafe deserialization is illustrated below:
A comparison of the vulnerable (left) and patched (right) functions
CVE-2025-55182 on Kaspersky honeypots
As the vulnerability is rather simple to exploit, the attackers quickly added it to their arsenal. The initial exploitation attempts were registered by Kaspersky honeypots on December 5. By Monday, December 8, the number of attempts had increased significantly and continues to rise.
The number of CVE-2025-55182 attacks targeting Kaspersky honeypots, by day (download)
Attackers first probe their target to ensure it is not a honeypot: they run whoami, perform multiplication in bash, or compute MD5 or Base64 hashes of random strings to verify their code can execute on the targeted machine.
In most cases, they then attempt to download malicious files using command-line web clients like wget or curl. Additionally, some attackers deliver a PowerShell-based Windows payload that installs XMRig, a popular Monero crypto miner.
CVE-2025-55182 was quickly weaponized by numerous malware campaigns, ranging from classic Mirai/Gafgyt variants to crypto miners and the RondoDox botnet. Upon infecting a system, RondoDox wastes no time, its loader script immediately moving to eliminate competitors:
Beyond checking hardcoded paths, RondoDox also neutralizes AppArmor and SELinux security modules and employs more sophisticated methods to find and terminate processes with ELF files removed for disguise.
Only after completing these steps does the script download and execute the main payload by sequentially trying three different loaders: wget, curl, and wget from BusyBox. It also iterates through 18 different malware builds for various CPU architectures, enabling it to infect both IoT devices and standard x86_64 Linux servers.
In some attacks, instead of deploying malware, the adversary attempted to steal credentials for Git and cloud environments. A successful breach could lead to cloud infrastructure compromise, software supply chain attacks, and other severe consequences.
Risk mitigation measures
We strongly recommend updating the relevant packages by applying patches released by the developers of the corresponding modules and bundles.
Vulnerable versions of React Server Components:
Bundles and modules confirmed as using React Server Components:
next
react-router
waku
@parcel/rsc
@vitejs/plugin-rsc
rwsdk
To prevent exploitation while patches are being deployed, consider blocking all POST requests containing the following keywords in parameters or the request body:
#constructor
#__proto__
#prototype
vm#runInThisContext
vm#runInNewContext
child_process#execSync
child_process#execFileSync
child_process#spawnSync
module#_load
module#createRequire
fs#readFileSync
fs#writeFileSync
s#appendFileSync
Conclusion
Due to the ease of exploitation and the public availability of a working PoC, threat actors have rapidly adopted CVE-2025-55182. It is highly likely that attacks will continue to grow in the near term.
We recommend immediately updating React to the latest patched version, scanning vulnerable hosts for signs of malware, and changing any credentials stored on them.
• Huawei aims to accelerate Digital Africa with wider connectivity, 5G, and sustainability.
• Industrial 5G, especially in mining, can drive 5G monetization in Africa. This is supported by Huawei’s broad portfolio and ecosystem.
Huawei held its MBBS Africa in Cape Town, South Africa in November 2025. As one of the leading telecom network vendors, Huawei shared its regional vision – to drive ‘Digital Africa’ through wider connectivity, 5G, and sustainable solutions.
GlobalData’s Africa & Middle East Mobile Broadband Forecast shows that mobile data subscription has been growing steadily at high single-digit rates over the past several years and is expected to rise at a 7.2% CAGR over the next five years. While 5G adoption is increasing, the penetration rate is still low compared to other regions. Huawei highlighted its initiatives and broad capabilities to accelerate growth in Africa. These include multi-band massive MIMO for additional capacity, active antenna solutions for efficient and flexible deployments, FWA for new use cases, cost-efficient solutions for rural deployments, and various energy-saving technologies such as adaptive power backup. Several operators including Telkom SA, Safaricom Kenya, and Airtel Tanzania showcased how they are leveraging these technologies in their networks. Huawei is also transforming its engagement model with African operators, moving beyond the role of a network vendor to become to a digitalization partner by delivering innovative solutions aligned with business needs and monetization strategies.
As 5G deployment gathers pace, monetization will become critical for operators. GlobalData research estimates 5G users will account for 7.1% of all mobile users by the end of 2025 and will grow to 26.7% by 2030. However, 5G monetization remains a global challenge even in advanced markets. The challenge will be an even bigger hurdle for African operators due to slower overall adoption and the relatively lower spending power. This makes the importance of enterprise 5G as a key monetization engine. Horizontal services such as FWA, private 5G, and IoT are essential. These use cases can help enterprises address various needs such as increasing reliability and security for critical applications, agile connectivity for temporary sites (e.g., events, remote operations), SD-WAN underlay, and large-scale IoT deployments. Meanwhile, 5G-enabled industrial solutions represent an even larger opportunity. Mining and resources, one of the region’s largest sectors, can benefit from applications like autonomous drilling, remote operation/maintenance, and worker safety. Globally, 5G adoption in mining is maturing and widely adopted. GlobalData’s 5G & Private Network Deployment Tracker shows that 7% of global deployments are in the mining sector. Other major verticals are construction, tourism, and hospitality are among other major verticals in the region. There is a growing number of use cases including drones and surveillance, digital twins, and safety in construction; and mixed reality, robots, and smart facilities in tourism/hospitality.
While the opportunity for 5G-enabled industrial services is increasing solidly, the solutions are far more complicated. They span across broader ICT stacks and require IT-OT integrations. Nevertheless, this plays to Huawei’s strengths. The vendor has comprehensive portfolio from cellular and fixed networks, to cloud, server, end points, AI, and industrial capabilities. For example, autonomous drilling in mining requires private network, but also edge computing, AI/analytics, and vertical expertise. Besides, the company has wide partner ecosystem including industrial players and end-point manufacturers. And more importantly, Huawei has extensive references and experience delivering these solutions cost-effectively in other emerging markets like Asia and South America. It can showcase its other successful deployments to gain market trust and drive its brand share in the enterprise 5G space.
15% of all ransomware victims whose data was published on threat actors’ data leak sites (DLSs) were victims of Qilin.
More than 254,000 users were targeted by miners.
Ransomware
Quarterly trends and highlights
Law enforcement success
The UK’s National Crime Agency (NCA) arrested the first suspect in connection with a ransomware attack that caused disruptions at numerous European airports in September 2025. Details of the arrest have not been published as the investigation remains ongoing. According to security researcher Kevin Beaumont, the attack employed the HardBit ransomware, which he described as primitive and lacking its own data leak site.
The U.S. Department of Justice filed charges against the administrator of the LockerGoga, MegaCortex and Nefilim ransomware gangs. His attacks caused millions of dollars in damage, putting him on wanted lists for both the FBI and the European Union.
U.S. authorities seized over $2.8 million in cryptocurrency, $70,000 in cash, and a luxury vehicle from a suspect allegedly involved in distributing the Zeppelin ransomware. The criminal scheme involved data theft, file encryption, and extortion, with numerous organizations worldwide falling victim.
A coordinated international operation conducted by the FBI, Homeland Security Investigations (HSI), the U.S. Internal Revenue Service (IRS), and law enforcement agencies from several other countries successfully dismantled the infrastructure of the BlackSuit ransomware. The operation resulted in the seizure of four servers, nine domains, and $1.09 million in cryptocurrency. The objective of the operation was to destabilize the malware ecosystem and protect critical U.S. infrastructure.
Vulnerabilities and attacks
SSL VPN attacks on SonicWall
Since late July, researchers have recorded a rise in attacks by the Akira threat actor targeting SonicWall firewalls supporting SSL VPN. SonicWall has linked these incidents to the already-patched vulnerability CVE-2024-40766, which allows unauthorized users to gain access to system resources. Attackers exploited the vulnerability to steal credentials, subsequently using them to access devices, even those that had been patched. Furthermore, the attackers were able to bypass multi-factor authentication enabled on the devices. SonicWall urges customers to reset all passwords and update their SonicOS firmware.
Scattered Spider uses social engineering to breach VMware ESXi
The Scattered Spider (UNC3944) group is attacking VMware virtual environments. The attackers contact IT support posing as company employees and request to reset their Active Directory password. Once access to vCenter is obtained, the threat actors enable SSH on the ESXi servers, extract the NTDS.dit database, and, in the final phase of the attack, deploy ransomware to encrypt all virtual machines.
Exploitation of a Microsoft SharePoint vulnerability
In late July, researchers uncovered attacks on SharePoint servers that exploited the ToolShell vulnerability chain. In the course of investigating this campaign, which affected over 140 organizations globally, researchers discovered the 4L4MD4R ransomware based on Mauri870 code. The malware is written in Go and packed using the UPX compressor. It demands a ransom of 0.005 BTC.
The application of AI in ransomware development
A UK-based threat actor used Claude to create and launch a ransomware-as-a-service (RaaS) platform. The AI was responsible for writing the code, which included advanced features such as anti-EDR techniques, encryption using ChaCha20 and RSA algorithms, shadow copy deletion, and network file encryption.
Anthropic noted that the attacker was almost entirely dependent on Claude, as they lacked the necessary technical knowledge to provide technical support to their own clients. The threat actor sold the completed malware kits on the dark web for $400–$1,200.
Researchers also discovered a new ransomware strain, dubbed PromptLock, that utilizes an LLM directly during attacks. The malware is written in Go. It uses hardcoded prompts to dynamically generate Lua scripts for data theft and encryption across Windows, macOS and Linux systems. For encryption, it employs the SPECK-128 algorithm, which is rarely used by ransomware groups.
Subsequently, scientists from the NYU Tandon School of Engineering traced back the likely origins of PromptLock to their own educational project, Ransomware 3.0, which they detailed in a prior publication.
The most prolific groups
This section highlights the most prolific ransomware gangs by number of victims added to each group’s DLS. As in the previous quarter, Qilin leads by this metric. Its share grew by 1.89 percentage points (p.p.) to reach 14.96%. The Clop ransomware showed reduced activity, while the share of Akira (10.02%) slightly increased. The INC Ransom group, active since 2023, rose to third place with 8.15%.
Number of each group’s victims according to its DLS as a percentage of all groups’ victims published on all the DLSs under review during the reporting period (download)
Number of new variants
In the third quarter, Kaspersky solutions detected four new families and 2,259 new ransomware modifications, nearly one-third more than in Q2 2025 and slightly more than in Q3 2024.
Number of new ransomware modifications, Q3 2024 — Q3 2025 (download)
Number of users attacked by ransomware Trojans
During the reporting period, our solutions protected 84,903 unique users from ransomware. Ransomware activity was highest in July, while August proved to be the quietest month.
Number of unique users attacked by ransomware Trojans, Q3 2025 (download)
Attack geography
TOP 10 countries attacked by ransomware Trojans
In the third quarter, Israel had the highest share (1.42%) of attacked users. Most of the ransomware in that country was detected in August via behavioral analysis.
Country/territory*
%**
1
Israel
1.42
2
Libya
0.64
3
Rwanda
0.59
4
South Korea
0.58
5
China
0.51
6
Pakistan
0.47
7
Bangladesh
0.45
8
Iraq
0.44
9
Tajikistan
0.39
10
Ethiopia
0.36
* Excluded are countries and territories with relatively few (under 50,000) Kaspersky users.
** Unique users whose computers were attacked by ransomware Trojans as a percentage of all unique users of Kaspersky products in the country/territory.
* Unique Kaspersky users attacked by the specific ransomware Trojan family as a percentage of all unique users attacked by this type of threat.
Miners
Number of new variants
In Q3 2025, Kaspersky solutions detected 2,863 new modifications of miners.
Number of new miner modifications, Q3 2025 (download)
Number of users attacked by miners
During the third quarter, we detected attacks using miner programs on the computers of 254,414 unique Kaspersky users worldwide.
Number of unique users attacked by miners, Q3 2025 (download)
Attack geography
TOP 10 countries and territories attacked by miners
Country/territory*
%**
1
Senegal
3.52
2
Mali
1.50
3
Afghanistan
1.17
4
Algeria
0.95
5
Kazakhstan
0.93
6
Tanzania
0.92
7
Dominican Republic
0.86
8
Ethiopia
0.77
9
Portugal
0.75
10
Belarus
0.75
* Excluded are countries and territories with relatively few (under 50,000) Kaspersky users.
** Unique users whose computers were attacked by miners as a percentage of all unique users of Kaspersky products in the country/territory.
Attacks on macOS
In April, researchers at Iru (formerly Kandji) reported the discovery of a new spyware family, PasivRobber. We observed the development of this family throughout the third quarter. Its new modifications introduced additional executable modules that were absent in previous versions. Furthermore, the attackers began employing obfuscation techniques in an attempt to hinder sample detection.
In July, we reported on a cryptostealer distributed through fake extensions for the Cursor AI development environment, which is based on Visual Studio Code. At that time, the malicious JavaScript (JS) script downloaded a payload in the form of the ScreenConnect remote access utility. This utility was then used to download cryptocurrency-stealing VBS scripts onto the victim’s device. Later, researcher Michael Bocanegra reported on new fake VS Code extensions that also executed malicious JS code. This time, the code downloaded a malicious macOS payload: a Rust-based loader. This loader then delivered a backdoor to the victim’s device, presumably also aimed at cryptocurrency theft. The backdoor supported the loading of additional modules to collect data about the victim’s machine. The Rust downloader was analyzed in detail by researchers at Iru.
In September, researchers at Jamf reported the discovery of a previously unknown version of the modular backdoor ChillyHell, first described in 2023. Notably, the Trojan’s executable files were signed with a valid developer certificate at the time of discovery.
The new sample had been available on Dropbox since 2021. In addition to its backdoor functionality, it also contains a module responsible for bruteforcing passwords of existing system users.
By the end of the third quarter, researchers at Microsoft reported new versions of the XCSSET spyware, which targets developers and spreads through infected Xcode projects. These new versions incorporated additional modules for data theft and system persistence.
TOP 20 threats to macOS
Unique users* who encountered this malware as a percentage of all attacked users of Kaspersky security solutions for macOS (download)
* Data for the previous quarter may differ slightly from previously published data due to some verdicts being retrospectively revised.
The PasivRobber spyware continues to increase its activity, with its modifications occupying the top spots in the list of the most widespread macOS malware varieties. Other highly active threats include Amos Trojans, which steal passwords and cryptocurrency wallet data, and various adware. The Backdoor.OSX.Agent.l family, which took thirteenth place, represents a variation on the well-known open-source malware, Mettle.
Geography of threats to macOS
TOP 10 countries and territories by share of attacked users
Country/territory
%* Q2 2025
%* Q3 2025
Mainland China
2.50
1.70
Italy
0.74
0.85
France
1.08
0.83
Spain
0.86
0.81
Brazil
0.70
0.68
The Netherlands
0.41
0.68
Mexico
0.76
0.65
Hong Kong
0.84
0.62
United Kingdom
0.71
0.58
India
0.76
0.56
IoT threat statistics
This section presents statistics on attacks targeting Kaspersky IoT honeypots. The geographic data on attack sources is based on the IP addresses of attacking devices.
In Q3 2025, there was a slight increase in the share of devices attacking Kaspersky honeypots via the SSH protocol.
Distribution of attacked services by number of unique IP addresses of attacking devices (download)
Conversely, the share of attacks using the SSH protocol slightly decreased.
Distribution of attackers’ sessions in Kaspersky honeypots (download)
TOP 10 threats delivered to IoT devices
Share of each threat delivered to an infected device as a result of a successful attack, out of the total number of threats delivered (download)
In the third quarter, the shares of the NyaDrop and Mirai.b botnets significantly decreased in the overall volume of IoT threats. Conversely, the activity of several other members of the Mirai family, as well as the Gafgyt botnet, increased. As is typical, various Mirai variants occupy the majority of the list of the most widespread malware strains.
Attacks on IoT honeypots
Germany and the United States continue to lead in the distribution of attacks via the SSH protocol. The share of attacks originating from Panama and Iran also saw a slight increase.
Country/territory
Q2 2025
Q3 2025
Germany
24.58%
13.72%
United States
10.81%
13.57%
Panama
1.05%
7.81%
Iran
1.50%
7.04%
Seychelles
6.54%
6.69%
South Africa
2.28%
5.50%
The Netherlands
3.53%
3.94%
Vietnam
3.00%
3.52%
India
2.89%
3.47%
Russian Federation
8.45%
3.29%
The largest number of attacks via the Telnet protocol were carried out from China, as is typically the case. Devices located in India reduced their activity, whereas the share of attacks from Indonesia increased.
Country/territory
Q2 2025
Q3 2025
China
47.02%
57.10%
Indonesia
5.54%
9.48%
India
28.08%
8.66%
Russian Federation
4.85%
7.44%
Pakistan
3.58%
6.66%
Nigeria
1.66%
3.25%
Vietnam
0.55%
1.32%
Seychelles
0.58%
0.93%
Ukraine
0.51%
0.73%
Sweden
0.39%
0.72%
Attacks via web resources
The statistics in this section are based on detection verdicts by Web Anti-Virus, which protects users when suspicious objects are downloaded from malicious or infected web pages. These malicious pages are purposefully created by cybercriminals. Websites that host user-generated content, such as message boards, as well as compromised legitimate sites, can become infected.
TOP 10 countries that served as sources of web-based attacks
This section gives the geographical distribution of sources of online attacks (such as web pages redirecting to exploits, sites hosting exploits and other malware, and botnet C2 centers) blocked by Kaspersky products. One or more web-based attacks could originate from each unique host.
To determine the geographic source of web attacks, we matched the domain name with the real IP address where the domain is hosted, then identified the geographic location of that IP address (GeoIP).
In the third quarter of 2025, Kaspersky solutions blocked 389,755,481 attacks from internet resources worldwide. Web Anti-Virus was triggered by 51,886,619 unique URLs.
Countries and territories where users faced the greatest risk of online infection
To assess the risk of malware infection via the internet for users’ computers in different countries and territories, we calculated the share of Kaspersky users in each location on whose computers Web Anti-Virus was triggered during the reporting period. The resulting data provides an indication of the aggressiveness of the environment in which computers operate in different countries and territories.
This ranked list includes only attacks by malicious objects classified as Malware. Our calculations leave out Web Anti-Virus detections of potentially dangerous or unwanted programs, such as RiskTool or adware.
Country/territory*
%**
1
Panama
11.24
2
Bangladesh
8.40
3
Tajikistan
7.96
4
Venezuela
7.83
5
Serbia
7.74
6
Sri Lanka
7.57
7
North Macedonia
7.39
8
Nepal
7.23
9
Albania
7.04
10
Qatar
6.91
11
Malawi
6.90
12
Algeria
6.74
13
Egypt
6.73
14
Bosnia and Herzegovina
6.59
15
Tunisia
6.54
16
Belgium
6.51
17
Kuwait
6.49
18
Turkey
6.41
19
Belarus
6.40
20
Bulgaria
6.36
* Excluded are countries and territories with relatively few (under 10,000) Kaspersky users.
** Unique users targeted by web-based Malware attacks as a percentage of all unique users of Kaspersky products in the country/territory.
On average, over the course of the quarter, 4.88% of devices globally were subjected to at least one web-based Malware attack.
Local threats
Statistics on local infections of user computers are an important indicator. They include objects that penetrated the target computer by infecting files or removable media, or initially made their way onto the computer in non-open form. Examples of the latter are programs in complex installers and encrypted files.
Data in this section is based on analyzing statistics produced by anti-virus scans of files on the hard drive at the moment they were created or accessed, and the results of scanning removable storage media: flash drives, camera memory cards, phones, and external drives. The statistics are based on detection verdicts from the on-access scan (OAS) and on-demand scan (ODS) modules of File Anti-Virus.
In the third quarter of 2025, our File Anti-Virus recorded 21,356,075 malicious and potentially unwanted objects.
Countries and territories where users faced the highest risk of local infection
For each country and territory, we calculated the percentage of Kaspersky users on whose computers File Anti-Virus was triggered during the reporting period. This statistic reflects the level of personal computer infection in different countries and territories around the world.
Note that this ranked list includes only attacks by malicious objects classified as Malware. Our calculations leave out File Anti-Virus detections of potentially dangerous or unwanted programs, such as RiskTool or adware.
Country/territory*
%**
1
Turkmenistan
45.69
2
Yemen
33.19
3
Afghanistan
32.56
4
Tajikistan
31.06
5
Cuba
30.13
6
Uzbekistan
29.08
7
Syria
25.61
8
Bangladesh
24.69
9
China
22.77
10
Vietnam
22.63
11
Cameroon
22.53
12
Belarus
21.98
13
Tanzania
21.80
14
Niger
21.70
15
Mali
21.29
16
Iraq
20.77
17
Nicaragua
20.75
18
Algeria
20.51
19
Congo
20.50
20
Venezuela
20.48
* Excluded are countries and territories with relatively few (under 10,000) Kaspersky users.
** Unique users on whose computers local Malware threats were blocked, as a percentage of all unique users of Kaspersky products in the country/territory.
On average worldwide, local Malware threats were detected at least once on 12.36% of computers during the third quarter.
• AWS Singapore Innovation Hub shows the company’s shift from technology-led to business-driven, turning use cases into commercial applications.
• The F1 partnership showcases AI and cloud innovation, but also AWS’ capabilities with real-time data intensive analytics and insights.
AWS held an analyst day in Singapore, showcasing its Innovation Hub and the partnership with Formula 1 (F1).
AWS Innovation Hub
At the innovation hub, AWS demonstrated a diverse range of AI and cloud enabled use cases – from document analytics and loan processing for BFSI, to preventive maintenance and AI-driven surveillance in manufacturing. The facility also houses many other industry-specific use cases with additional use cases in the pipeline. This initiative reflects AWS’ ongoing shift from a technology-focused to a business-led engagement model. While technologies remain at the core, the company is deepening collaboration with enterprise leaders beyond IT, engaging directly with business executives and functional owners. Leadership, culture, and people are key enablers of successful digital transformation. The Innovation Hub serves as a platform for enterprises to explore and co-develop use cases tailored to their business needs.
Innovation labs are not new. Many other providers like global system integrators, telcos, and tech vendors, have been opening new facilities over the last few years. It is a proven way to drive adoption of emerging technologies through solution co-development, commercialization and ecosystem expansion. Besides, innovation labs can also strengthen providers’ brand share and enable them to gain deeper market knowledge such as understanding customers’ pain points. The use cases demonstrated at the AWS facility were innovative and promising, but most are somewhat comparable to use cases found in other providers’ facilities. But what differentiates AWS is its strong execution. Over 70% of the use cases have been brought into production. This is consistent with its strategy to expand focus on outcome-led engagements, and a strong proof point that the efforts are not just conceptual but outcome-driven.
AWS x F1
In the latter part of the event, there were sessions with executives at the track sites including a visit to the F1 Event Technical Center (ETC), sharing how the AWS and F1 collaboration is driving innovation and enabling various use cases for F1, teams, drivers, fans, and viewers. Since the partnership began in 2018, AWS has evolved from providing core cloud infrastructure to powering advanced AI solutions. Early deployments include leveraging over 1,000 AWS compute cores for computational fluid dynamics (CFD) projects to design race cars. Today, the partnership extends to AI applications including real-time insights, car performance, race strategy, issue resolutions/root cause analysis, fan engagement (e.g., hyper-personalization), game strategy, and safety and reliability.
Sports, as one of the most data-intensive industries in the world, offers an ideal testbed for real-time analytics. For example, an F1 car alone carries around 300 sensors, generating over one million telemetry data points per second with a total of 600TB across entire race. Similarly, a football match generates about 3.6 million data points. Furthermore, data from sports events are often highly fragmented (structured and unstructured) and need to be processed in real-time. Apart from F1, AWS is also an official technology partner in various major global sports events such as the NFL, PGA Tour, Bundesliga, NHL, and many other sports teams. While sports in APAC are not as big as in other regions such as the US and Europe, AWS collaborations with F1 and other sports organizations show its leadership in this industry. More importantly, it can also be seen as a powerful platform to demonstrate its broad capabilities and innovation in complex and data-rich environments.
Vocus has launched its business-focused MVNO brand, Vocus Mobile, aiming to disrupt the market and inject fresh competition into an already hypercompetitive landscape.
Backed by an expanded customer base from the TPG Enterprise acquisition, Vocus is well-positioned to accelerate growth with its existing client base.
Australian telecoms infrastructure provider Vocus has finally launched its own business-focused MVNO brand, Vocus Mobile. Leveraging Optus’s 4G and 5G networks the company aims to position itself as a one-stop provider for enterprise communications, offering connectivity solutions across networking, collaboration, and now mobility as it looks to stand out with a range of self-serve features to create a better user experience for its clients. Will the entrance of another MVNO challenger selling basic mobile connectivity in an already crowded market make a difference?
At launch, Vocus will offer three traditional types of mobile connectivity services, including mobile voice and data for Smartphone use, 5G data plan for broadband, and 4G backup to support business continuity when primary networks are down. Customers will be supported by its self-service mobile fleet management platform, Mobile Fleet 360, giving businesses the ability to manage their mobile fleets with near real-time dashboards, bulk activation of services, and the able to configure roaming settings, reducing the reliance on traditional support channels. Vocus’s foray into the enterprise mobile services market is not surprising following on from its acquisition of TPG Telecom’s fiber network assets and its enterprise, government, and wholesale fixed infrastructure business. It has been anticipated for many years, with the company having a long-standing wholesale agreement with Optus through its consumer and SMB brands Dodo, iPrimus, and Commander. While back in 2019, the company extended its agreement to include its various other brands to provide 5G access to support its growth strategy by expanding and growing market share in large enterprise and SMB segments.
The Australian mobile market has three mobile network operators with Telstra maintaining its superior network leadership for many years. Telstra covers 95% of the country’s population with 5G coverage and 99.7% with 4G coverage, equating to land coverage of approximately three million square kilometers, almost three times the land coverage than any of its nearest rivals. To compete against Telstra, Optus and TPG Telecom (owner of Vodafone in Australia) recently formed a network sharing agreement earlier in 2025, which extends their 5G coverage to 80.5% of the population and 4G reach to 98.4% of the Australian population with over one million square kilometers.
While the Australian enterprise telecommunications market remains in flux, with many providers struggling to achieve growth and facing revenue declines across their connectivity portfolios. The enterprise market is positioned for growth, with GlobalData expecting the business mobile market to grow 5.5% by 2029. Though service providers continue to battle it out to grow their mobile market share, with the country having three enterprise challenger brands including Aussie Broadband, Macquarie Telecom, and now Vocus all leveraging Optus’s mobile network by trying to break the incumbent’s stronghold of approximately 65% of the business mobile market. While all challengers have struggled to make a meaningful impact in the market, to date, all only offer basic mobile connectivity instead of delivering outcome-driven solutions that enterprise customers increasingly expect, such as IoT, asset tracking, and other advanced 5G innovations like network slicing.
The statistics in this report are based on detection verdicts returned by Kaspersky products unless otherwise stated. The information was provided by Kaspersky users who consented to sharing statistical data.
The quarter in numbers
In Q2 2025:
Kaspersky solutions blocked more than 471 million attacks originating from various online resources.
Web Anti-Virus detected 77 million unique links.
File Anti-Virus blocked nearly 23 million malicious and potentially unwanted objects.
There were 1,702 new ransomware modifications discovered.
Just under 86,000 users were targeted by ransomware attacks.
Of all ransomware victims whose data was published on threat actors’ data leak sites (DLS), 12% were victims of Qilin.
Almost 280,000 users were targeted by miners.
Ransomware
Quarterly trends and highlights
Law enforcement success
The alleged malicious actor behind the Black Kingdom ransomware attacks was indicted in the U.S. The Yemeni national is accused of infecting about 1,500 computers in the U.S. and other countries through vulnerabilities in Microsoft Exchange. He also stands accused of demanding a ransom of $10,000 in bitcoin, which is the amount victims saw in the ransom note. He is also alleged to be the developer of the Black Kingdom ransomware.
A Ukrainian national was extradited to the U.S. in the Nefilim case. He was arrested in Spain in June 2024 on charges of distributing ransomware and extorting victims. According to the investigation, he had been part of the Nefilim Ransomware-as-a-Service (RaaS) operation since 2021, targeting high-revenue organizations. Nefilim uses the classic double extortion scheme: cybercriminals steal the victim’s data, encrypt it, then threaten to publish it online.
Also arrested was a member of the Ryuk gang, charged with organizing initial access to victims’ networks. The accused was apprehended in Kyiv in April 2025 at the request of the FBI and extradited to the U.S. in June.
A man suspected of being involved in attacks by the DoppelPaymer gang was arrested. In a joint operation by law enforcement in the Netherlands and Moldova, the 45-year-old was arrested in May. He is accused of carrying out attacks against Dutch organizations in 2021. Authorities seized around €84,800 and several devices.
A 39-year-old Iranian national pleaded guilty to participating in RobbinHood ransomware attacks. Among the targets of the attacks, which took place from 2019 to 2024, were U.S. local government agencies, healthcare providers, and non-profit organizations.
Vulnerabilities and attacks
Mass exploitation of a vulnerability in SAP NetWeaver
In May, it was revealed that several ransomware gangs, including BianLian and RansomExx, had been exploiting CVE-2025-31324 in SAP NetWeaver software. Successful exploitation of this vulnerability allows attackers to upload malicious files without authentication, which can lead to a complete system compromise.
Attacks via the SimpleHelp remote administration tool
The DragonForce group compromised an MSP provider, attacking its clients with the help of the SimpleHelp remote administration tool. According to researchers, the attackers exploited a set of vulnerabilities (CVE-2024-57727, CVE-2024-57728, CVE-2024-57726) in the software to launch the DragonForce ransomware on victims’ hosts.
Qilin exploits vulnerabilities in Fortinet
In June, news broke that the Qilin gang (also known as Agenda) was actively exploiting critical vulnerabilities in Fortinet devices to infiltrate corporate networks. The attackers allegedly exploited the vulnerabilities CVE-2024-21762 and CVE-2024-55591 in FortiGate software, which allowed them to bypass authentication and execute malicious code remotely. After gaining access, the cybercriminals encrypted data on systems within the corporate network and demanded a ransom.
Exploitation of a Windows CLFS vulnerability
April saw the detection of attacks that leveraged CVE-2025-29824, a zero-day vulnerability in the Windows Common Log File System (CLFS) driver, a core component of the Windows OS. This vulnerability allows an attacker to elevate privileges on a compromised system. Researchers have linked these incidents to the RansomExx and Play gangs. The attackers targeted companies in North and South America, Europe, and the Middle East.
The most prolific groups
This section highlights the most prolific ransomware gangs by number of victims added to each group’s DLS during the reporting period. In the second quarter, Qilin (12.07%) proved to be the most prolific group. RansomHub, the leader of 2024 and the first quarter of 2025, seems to have gone dormant since April. Clop (10.83%) and Akira (8.53%) swapped places compared to the previous reporting period.
Number of each group’s victims according to its DLS as a percentage of all groups’ victims published on all the DLSs under review during the reporting period (download)
Number of new variants
In the second quarter, Kaspersky solutions detected three new families and 1,702 new ransomware variants. This is significantly fewer than in the previous reporting period. The decrease is linked to the renewed decline in the count of the Trojan-Ransom.Win32.Gen verdicts, following a spike last quarter.
Number of new ransomware modifications, Q2 2024 — Q2 2025 (download)
Number of users attacked by ransomware Trojans
Our solutions protected a total of 85,702 unique users from ransomware during the second quarter.
Number of unique users attacked by ransomware Trojans, Q2 2025 (download)
Geography of attacked users
TOP 10 countries and territories attacked by ransomware Trojans
Country/territory*
%**
1
Libya
0.66
2
China
0.58
3
Rwanda
0.57
4
South Korea
0.51
5
Tajikistan
0.49
6
Bangladesh
0.45
7
Iraq
0.45
8
Pakistan
0.38
9
Brazil
0.38
10
Tanzania
0.35
* Excluded are countries and territories with relatively few (under 50,000) Kaspersky users. ** Unique users whose computers were attacked by ransomware Trojans as a percentage of all unique users of Kaspersky products in the country/territory.
* Unique Kaspersky users attacked by the specific ransomware Trojan family as a percentage of all unique users attacked by this type of threat.
Miners
Number of new variants
In the second quarter of 2025, Kaspersky solutions detected 2,245 new modifications of miners.
Number of new miner modifications, Q2 2025 (download)
Number of users attacked by miners
During the second quarter, we detected attacks using miner programs on the computers of 279,630 unique Kaspersky users worldwide.
Number of unique users attacked by miners, Q2 2025 (download)
Geography of attacked users
TOP 10 countries and territories attacked by miners
Country/territory*
%**
1
Senegal
3.49
2
Panama
1.31
3
Kazakhstan
1.11
4
Ethiopia
1.02
5
Belarus
1.01
6
Mali
0.96
7
Tajikistan
0.88
8
Tanzania
0.80
9
Moldova
0.80
10
Dominican Republic
0.80
* Excluded are countries and territories with relatively few (under 50,000) Kaspersky users. ** Unique users whose computers were attacked by miners as a percentage of all unique users of Kaspersky products in the country/territory.
Attacks on macOS
Among the threats to macOS, one of the biggest discoveries of the second quarter was the PasivRobber family. This spyware consists of a huge number of modules designed to steal data from QQ, WeChat, and other messaging apps and applications that are popular mainly among Chinese users. Its distinctive feature is that the spyware modules get embedded into the target process when the device goes into sleep mode.
Closer to the middle of the quarter, several reports (1, 2, 3) emerged about attackers stepping up their activity, posing as victims’ trusted contacts on Telegram and convincing them to join a Zoom call. During or before the call, the user was persuaded to run a seemingly Zoom-related utility, but which was actually malware. The infection chain led to the download of a backdoor written in the Nim language and bash scripts that stole data from browsers.
TOP 20 threats to macOS
* Unique users who encountered this malware as a percentage of all attacked users of Kaspersky security solutions for macOS (download)
* Data for the previous quarter may differ slightly from previously published data due to some verdicts being retrospectively revised.
A new piece of spyware named PasivRobber, discovered in the second quarter, immediately became the most widespread threat, attacking more users than the fake cleaners and adware typically seen on macOS. Also among the most common threats were the password- and crypto wallet-stealing Trojan Amos and the general detection Trojan.OSX.Agent.gen, which we described in our previous report.
Geography of threats to macOS
TOP 10 countries and territories by share of attacked users
Country/territory
%* Q1 2025
%* Q2 2025
Mainland China
0.73%
2.50%
France
1.52%
1.08%
Hong Kong
1.21%
0.84%
India
0.84%
0.76%
Mexico
0.85%
0.76%
Brazil
0.66%
0.70%
Germany
0.96%
0.69%
Singapore
0.32%
0.63%
Russian Federation
0.50%
0.41%
South Korea
0.10%
0.32%
* Unique users who encountered threats to macOS as a percentage of all unique Kaspersky users in the country/territory.
IoT threat statistics
This section presents statistics on attacks targeting Kaspersky IoT honeypots. The geographic data on attack sources is based on the IP addresses of attacking devices.
In the second quarter of 2025, there was another increase in both the share of attacks using the Telnet protocol and the share of devices connecting to Kaspersky honeypots via this protocol.
Distribution of attacked services by number of unique IP addresses of attacking devices (download)
Distribution of attackers’ sessions in Kaspersky honeypots (download)
TOP 10 threats delivered to IoT devices
Share of each threat delivered to an infected device as a result of a successful attack, out of the total number of threats delivered (download)
In the second quarter, the share of the NyaDrop botnet among threats delivered to our honeypots grew significantly to 30.27%. Conversely, the number of Mirai variants on the list of most common malware decreased, as did the share of most of them. Additionally, after a spike in the first quarter, the share of BitCoinMiner miners dropped to 1.57%.
During the reporting period, the list of most common IoT threats expanded with new families. The activity of the Agent.nx backdoor (4.48%), controlled via P2P through the BitTorrent DHT distributed hash table, grew markedly. Another newcomer to the list, Prometei, is a Linux version of a Windows botnet that was first discovered in December 2020.
Attacks on IoT honeypots
Geographically speaking, the percentage of SSH attacks originating from Germany and the U.S. increased sharply.
Country/territory
Q1 2025
Q2 2025
Germany
1.60%
24.58%
United States
5.52%
10.81%
Russian Federation
9.16%
8.45%
Australia
2.75%
8.01%
Seychelles
1.32%
6.54%
Bulgaria
1.25%
3.66%
The Netherlands
0.63%
3.53%
Vietnam
2.27%
3.00%
Romania
1.34%
2.92%
India
19.16%
2.89%
The share of Telnet attacks originating from China and India remained high, with more than half of all attacks on Kaspersky honeypots coming from these two countries combined.
Country/territory
Q1 2025
Q2 2025
China
39.82%
47.02%
India
30.07%
28.08%
Indonesia
2.25%
5.54%
Russian Federation
5.14%
4.85%
Pakistan
3.99%
3.58%
Brazil
12.03%
2.35%
Nigeria
3.01%
1.66%
Germany
0.09%
1.47%
United States
0.68%
0.75%
Argentina
0.01%
0.70%
Attacks via web resources
The statistics in this section are based on detection verdicts by Web Anti-Virus, which protects users when suspicious objects are downloaded from malicious or infected web pages. Cybercriminals create malicious pages with a goal in mind. Websites that host user-generated content, such as message boards, as well as compromised legitimate sites, can become infected.
Countries that served as sources of web-based attacks: TOP 10
This section gives the geographical distribution of sources of online attacks blocked by Kaspersky products: web pages that redirect to exploits; sites that host exploits and other malware; botnet C2 centers, and the like. Any unique host could be the source of one or more web-based attacks.
To determine the geographic source of web attacks, we matched the domain name with the real IP address where the domain is hosted, then identified the geographic location of that IP address (GeoIP).
In the second quarter of 2025, Kaspersky solutions blocked 471,066,028 attacks from internet resources worldwide. Web Anti-Virus responded to 77,371,384 unique URLs.
Countries and territories where users faced the greatest risk of online infection
To assess the risk of malware infection via the internet for users’ computers in different countries and territories, we calculated the share of Kaspersky users in each location who experienced a Web Anti-Virus alert during the reporting period. The resulting data provides an indication of the aggressiveness of the environment in which computers operate in different countries and territories.
This ranked list includes only attacks by malicious objects classified as Malware. Our calculations leave out Web Anti-Virus detections of potentially dangerous or unwanted programs, such as RiskTool or adware.
Country/territory*
%**
1
Bangladesh
10.85
2
Tajikistan
10.70
3
Belarus
8.96
4
Nepal
8.45
5
Algeria
8.21
6
Moldova
8.16
7
Turkey
8.08
8
Qatar
8.07
9
Albania
8.03
10
Hungary
7.96
11
Tunisia
7.95
12
Portugal
7.93
13
Greece
7.90
14
Serbia
7.84
15
Bulgaria
7.79
16
Sri Lanka
7.72
17
Morocco
7.70
18
Georgia
7.68
19
Peru
7.63
20
North Macedonia
7.58
* Excluded are countries and territories with relatively few (under 10,000) Kaspersky users.
** Unique users targeted by Malware attacks as a percentage of all unique users of Kaspersky products in the country.
On average during the quarter, 6.36% of internet users’ computers worldwide were subjected to at least one Malware web-based attack.
Local threats
Statistics on local infections of user computers are an important indicator. They include objects that penetrated the target computer by infecting files or removable media, or initially made their way onto the computer in non-open form. Examples of the latter are programs in complex installers and encrypted files.
Data in this section is based on analyzing statistics produced by anti-virus scans of files on the hard drive at the moment they were created or accessed, and the results of scanning removable storage media. The statistics are based on detection verdicts from the On-Access Scan (OAS) and On-Demand Scan (ODS) modules of File Anti-Virus. This includes malware found directly on user computers or on connected removable media: flash drives, camera memory cards, phones, and external hard drives.
In the second quarter of 2025, our File Anti-Virus recorded 23,260,596 malicious and potentially unwanted objects.
Countries and territories where users faced the highest risk of local infection
For each country and territory, we calculated the percentage of Kaspersky users whose devices experienced a File Anti-Virus triggering at least once during the reporting period. This statistic reflects the level of personal computer infection in different countries and territories around the world.
Note that this ranked list includes only attacks by malicious objects classified as Malware. Our calculations leave out File Anti-Virus detections of potentially dangerous or unwanted programs, such as RiskTool or adware.
Country/territory*
%**
1
Turkmenistan
45.26
2
Afghanistan
34.95
3
Tajikistan
34.43
4
Yemen
31.95
5
Cuba
30.85
6
Uzbekistan
28.53
7
Syria
26.63
8
Vietnam
24.75
9
South Sudan
24.56
10
Algeria
24.21
11
Bangladesh
23.79
12
Belarus
23.67
13
Gabon
23.37
14
Niger
23.35
15
Cameroon
23.10
16
Tanzania
22.77
17
China
22.74
18
Iraq
22.47
19
Burundi
22.30
20
Congo
21.84
* Excluded are countries and territories with relatively few (under 10,000) Kaspersky users.
** Unique users on whose computers Malware local threats were blocked, as a percentage of all unique users of Kaspersky products in the country/territory.
Overall, 12.94% of user computers globally faced at least one Malware local threat during the second quarter.
The figure for Russia was 14.27%.
Modern vehicles are transforming into full-fledged digital devices that offer a multitude of features, from common smartphone-like conveniences to complex intelligent systems and services designed to keep everyone on the road safe. However, this digitalization, while aimed at improving comfort and safety, is simultaneously expanding the vehicle’s attack surface.
In simple terms, a modern vehicle is a collection of computers networked together. If a malicious actor gains remote control of a vehicle, they could be able not only steal user data but also create a dangerous situation on the road. While intentional attacks targeting a vehicle’s functional safety have not become a widespread reality yet, that does not mean the situation will not change in the foreseeable future.
The digital evolution of the automobile
The modern vehicle is a relatively recent invention. While digital systems like the electronic control unit and onboard computer began appearing in vehicles back in the 1970s, they did not become standard until the 1990s. This technological advancement led to a proliferation of narrowly specialized electronic devices, each with a specific task, such as measuring wheel speed, controlling headlight modes, or monitoring door status. As the number of sensors and controllers grew, local automotive networks based on LIN and CAN buses were introduced to synchronize and coordinate them. Fast forward about 35 years, and modern vehicle is a complex technical device with extensive remote communication capabilities that include support for 5G, V2I, V2V, Wi-Fi, Bluetooth, GPS, and RDS.
Components like the head unit and telecommunication unit are standard entry points into the vehicle’s internal infrastructure, which makes them frequent objects for security research.
From a functional and architectural standpoint, we can categorize vehicles into three groups. The lines between these categories are blurred, as many vehicles could fit into more than one, depending on their features.
Obsolete vehicles do not support remote interaction with external information systems (other than diagnostic tools) via digital channels and have a simple internal architecture. These vehicles are often retrofitted with modern head units, but those components are typically isolated within a closed information environment because they are integrated into an older architecture. This means that even if an attacker successfully compromises one of these components, they cannot pivot to other parts of the vehicle.
Legacy vehicles are a sort of transitional phase. Unlike simpler vehicles from the past, they are equipped with a telematics unit, which is primarily used for data collection rather than remote control – though two-way communication is not impossible. They also feature a head unit with more extensive functionality, which allows changing settings and controlling systems. The internal architecture of these vehicles is predominantly digital, with intelligent driver assistance systems. The numerous electronic control units are connected in an information network that either has flat structure or is only partially segmented into security domains. The stock head unit in these vehicles is often replaced with a modern unit from a third-party vendor. From a cybersecurity perspective, legacy vehicles represent the most complex problem. Serious physical consequences, including life-threatening situations, can easily result from cyberattacks on these vehicles. This was made clear 10 years ago when Charlie Miller and Chris Valasek conducted their famous remote Jeep Cherokee hack.
Modern vehicles have a fundamentally different architecture. The network of electronic control units is now divided into security domains with the help of a firewall, which is typically integrated within a central gateway. The advent of native two-way communication channels with the manufacturer’s cloud infrastructure and increased system connectivity has fundamentally altered the attack surface. However, many automakers learned from the Jeep Cherokee research. They have since refined their network architecture, segmenting it with the help of a central gateway, configuring traffic filtering, and thus isolating critical systems from the components most susceptible to attacks, such as the head unit and the telecommunication module. This has significantly complicated the task of compromising functional safety through a cyberattack.
Possible future threat landscape
Modern vehicle architectures make it difficult to execute the most dangerous attacks, such as remotely deploying airbags at high speeds. However, it is often easier to block the engine from starting, lock doors, or access confidential data, as these functions are frequently accessible through the vendor’s cloud infrastructure. These and other automotive cybersecurity challenges are prompting automakers to engage specialized teams for realistic penetration testing. The results of these vehicle security assessments, which are often publicly disclosed, highlight an emerging trend.
Despite this, cyberattacks on modern vehicles have not become commonplace yet. This is due to the lack of malware specifically designed for this purpose and the absence of viable monetization strategies. Consequently, the barrier to entry for potential attackers is high. The scalability of these attacks is also poor, which means the guaranteed return on investment is low, while the risks of getting caught are very high.
However, this situation is slowly but surely changing. As vehicles become more like gadgets built on common technologies – including Linux and Android operating systems, open-source code, and common third-party components – they become vulnerable to traditional attacks. The integration of wireless communication technologies increases the risk of unauthorized remote control. Specialized tools like software-defined radio (SDR), as well as instructions for exploiting wireless networks (Wi-Fi, GSM, LTE, and Bluetooth) are becoming widely available. These factors, along with the potential decline in the profitability of traditional targets (for example, if victims stop paying ransoms), could lead attackers to pivot toward vehicles.
Which vehicles are at risk
Will attacks on vehicles become the logical evolution of attacks on classic IT systems? While attacks on remotely accessible head units, telecommunication modules, cloud services or mobile apps for extortion or data theft are technically more realistic, they require significant investment, tool development, and risk management. Success is not guaranteed to result in a ransom payment, so individual cars remain an unattractive target for now.
The real risk lies with fleet vehicles, such as those used by taxi and carsharing services, logistics companies, and government organizations. These vehicles are often equipped with aftermarket telematics and other standardized third-party hardware that typically has a lower security posture than factory-installed systems. They are also often integrated into the vehicle’s infrastructure in a less-than-secure way. Attacks on these systems could be highly scalable and pose significant financial and reputational threats to large fleet owners.
Another category of potential targets is represented by trucks, specialized machinery, and public transit vehicles, which are also equipped with aftermarket telematics systems. Architecturally, they are similar to passenger cars, which means they have similar security vulnerabilities. The potential damage from an attack on these vehicles can be severe, with just one day of downtime for a haul truck potentially resulting in hundreds of thousands of dollars in losses.
Investing in a secure future
Improving the current situation requires investment in automotive cybersecurity at every level, from the individual user to the government regulator. The driving forces behind this are consumers’ concern for their own safety and the government’s concern for the security of its citizens and national infrastructure.
Automotive cybersecurity is already a focus for researchers, cybersecurity service providers, government regulators, and major car manufacturers. Many automotive manufacturing corporations have established their own product security or product CERT teams, implemented processes for responding to new vulnerability reports, and made penetration testing a mandatory part of the development cycle. They have also begun to leverage cyberthreat intelligence and are adopting secure development methodologies and security by design. This is a growing trend, and this approach is expected to become standard practice for most automakers 10 years from now.
Simultaneously, specialized security operations centers (SOCs) for vehicles are being established. The underlying approach is remote data collection from vehicles for subsequent analysis of cybersecurity events. In theory, this data can be used to identify cyberattacks on cars’ systems and build a database of threat information. The industry is actively moving toward deploying these centers.
John Marcus – Senior Principal Analyst, Enterprise Mobility and IoT Services.
Summary Bullets:
• Global telcos are advancing industrial IoT with AI, 5G, and eSIM to deliversector-specific and real-time solutions at global scale.
• Strategic investments continue the shift beyond basic connectivity to intelligent, global platforms supporting logistics, energy, mobility, and public safety.
Over H1 2025, major telecom providers have redoubled their push into industrial IoT, developing tailored solutions that move well beyond connectivity to address the specific needs of sectors and use cases such as transport, utilities, and facilities management. Common threads across these efforts include the integration of AI, the evolution of connectivity through 5G, eSIM, and satellite, and a growing emphasis on real-time visibility, operational efficiency, and international scalability.
One way this evolution is evident is the way telcos are turning global networks into intelligent, responsive infrastructure. Vodafone is leveraging its infrastructure for use cases like flood detection, using its Network as a Sensor technology to monitor rainfall and provide early warnings–highlighting how IoT is being adapted to address environmental risks in addition to industrial efficiency. Vodafone also recently surpassed a milestone of 200 million connected IoT devices globally, doubling its installed base over five years. It continues to push into new regions, recently expanding coverage in the Middle East via a partnership with Mobily in Saudi Arabia.
In Germany, Deutsche Telekom is developing several new applications, from its work with Swift Navigation to expand precise satellite positioning across Eastern Europe, to residential energy efficiency projects. The operator is digitalizing heating systems for public housing in partnership with Metr, using smart IoT gateways and secure cloud hosting via Open Telekom Cloud. In parallel, Deutsche Telekom and Nordic Semiconductor launched MECC, a new embedded connectivity service designed to simplify global cellular integration for connected products.
Telefónica Tech is moving IoT deeper into industrial environments through automation and AI. Its recent collaboration with Dexory aims to automate warehouse inventory tracking using AI-driven digital twins and Telefónica’s industrial IoT integration capabilities–a good example of how telcos are embedding intelligence directly into logistics operations. Meanwhile, Orange Business has taken a different angle on public safety, unveiling a smart emergency services system as part of the Software République initiative. Designed in collaboration with firefighter units, the solution combines AI, sensors, and secure communications to improve situational awareness and response coordination in crisis scenarios.
While Verizon has made several announcements this year with new solutions like Edge Transportation Exchange for V2X, Sensor Insights, and 5G Video Insights, it also expanded its Global IoT Orchestration platform, adding Singtel and Skylo for Asia-Pacific and non-terrestrial connectivity respectively. Other telcos are also investing further in global reach, as well as expanded cellular reach within territories. AT&T, for instance, is enhancing its IoT footprint through a new global eSIM solution and support for 5G RedCap. T-Mobile, working with Thales and SIMPL IoT, is integrating eSIMs into global product deployments, while also enabling managed connectivity for international devices targeting the U.S. market. In parallel, Singtel recently announced an enhanced Multi-Domestic Connectivity solution in partnership with cloud-native provider floLIVE, offering enterprises a single, secure, and scalable platform to manage global IoT deployments across more than 190 markets–also enabled by eSIM orchestration.
Three key themes are evident so far this year. First, telcos are responding to strong demand for vertical-specific solutions, although horizontal platforms still matter. Second, AI and real-time data analytics are no longer just add-ons–they are essential to deriving business value from IoT. And third, cross-border IoT is becoming more manageable thanks to advances in eSIM orchestration, global roaming partnerships, and the addition of satellite integration with cellular networks for hard-to-reach locations.
As a whole, these recent announcements demonstrate that industrial IoT remains a strategic priority for global telecom operators that already have a stake in the market. The focus is no longer just on connecting machines–it is on optimizing how those machines work in context, at scale (increasingly globally), and in near-real time.
By Antoinette Hodes, Office of the CTO, Check Point Software Technologies.
The dark web has evolved into a clandestine marketplace where illicit activities flourish under the cloak of anonymity. Due to its restricted accessibility, the dark web exhibits a decentralized structure with minimal enforcement of security controls, making it a common marketplace for malicious activities.
The Internet of Things (IoT), with the interconnected nature of its devices, and its vulnerabilities, has become an attractive target for dark web-based cyber criminals. One weak link – i.e., a compromised IoT device – can jeopardize the entire network’s security. The financial repercussions of a breached device can be extensive, not just in terms of ransom demands, but also in terms of regulatory fines, loss of reputation and the cost of remediation.
With their interconnected nature and inherent vulnerabilities, IoT devices are attractive entry points for cyber criminals. They are highly desirable targets, since they often represent a single point of vulnerability that can impact numerous victims simultaneously.
Check Point Research found a sharp increase in cyber attacks targeting IoT devices, observing a trend across all regions and sectors. Europe experiences the highest number of incidents per week: on average, nearly 70 IoT attacks per organization.
Gateways to the dark web
Based on research from PSAcertified, the average cost of a successful attack on an IoT device exceeds $330,000. Another analyst reportreveals that 34% of enterprises that fell victim to a breach via IoT devices faced higher cumulative breach costs than those who fell victim to a cyber attack on non-IoT devices; the cost of which ranged between $5 million and $10 million.
Other examples of IoT-based attacks include botnet infections, turning devices into zombies so that they can participate in distributed denial-of-service (DDoS), ransomware and propagation attacks, as well as crypto-mining and exploitation of IoT devices as proxies for the dark web.
The dark web relies on an arsenal of tools and associated services to facilitate illicit activities. Extensive research has revealed a thriving underground economy operating within the dark web. This economy is largely centered around services associated with IoT. In particular, there seems to be a huge demand for DDoS attacks that are orchestrated through IoT botnets: During the first half of 2023, Kaspersky identified over 700 advertisements for DDoS attack services across various dark web forums.
IoT devices themselves have become valuable assets in this underworld marketplace. On the dark web, the value of a compromised device is often greater than the retail price of the device itself. Upon examining one of the numerous Telegram channels used for trading dark web products and services, one can come across scam pages, tutorials covering various malicious activities, harmful configuration files with “how-to’s”, SSH crackers, and more. Essentially, a complete assortment of tools, from hacking resources to anonymization services, for the purpose of capitalizing on compromised devices can be found on the dark web. Furthermore, vast quantities of sensitive data are bought and sold there everyday.
AI’s dark capabilities
Adversarial machine learning can be used to attack, deceive and bypass machine learning systems. The combination of IoT and AI has driven dark web-originated attacks to unprecedented levels. This is what we are seeing:
Automated exploitation: AI algorithms automate the process of scanning for vulnerabilities and security flaws with subsequent exploitation methods. This opens doors to large-scale attacks with zero human interaction.
Adaptive attacks: With AI, attackers can now adjust their strategies in real-time by analyzing the responses and defenses encountered during an attack. This ability to adapt poses a significant challenge for traditional security measures in effectively detecting and mitigating IoT threats.
Behavioral analysis: AI-driven analytics enables the examination of IoT devices and user behavior, allowing for the identification of patterns, anomalies, and vulnerabilities. Malicious actors can utilize this capability to profile IoT devices, exploit their weaknesses, and evade detection from security systems.
Adversarial attacks: Adversarial attacks can be used to trick AI models and IoT devices into making incorrect or unintended decisions, potentially leading to security breaches. These attacks aim to exploit weaknesses in the system’s algorithms or vulnerabilities.
Zero-tolerance security
The convergence of IoT and AI brings numerous advantages, but it also presents fresh challenges. To enhance IoT security and device resilience while safeguarding sensitive data, across the entire IoT supply chain, organizations must implement comprehensive security measures based on zero-tolerance principles.
Factors such as data security, device security, secure communication, confidentiality, privacy, and other non-functional requirements like maintainability, reliability, usability and scalability highlight the critical need for security controls within IoT devices. Security controls should include elements like secure communication, access controls, encryption, software patches, device hardening, etc. As part of the security process, the focus should be on industry standards, such as “secure by design” and “secure by default”, along with the average number of IoT attacks per organization, as broken down by region every week.
Collaborations and alliances within the industry are critical in developing standardized IoT security practices and establishing industry-wide security standards. By integrating dedicated IoT security, organizations can enhance their overall value proposition and ensure compliance with regulatory obligations.
In today’s cyber threat landscape, numerous geographic regions demand adherence to stringent security standards; both during product sales and while responding to Request for Information and Request for Proposal solicitations. IoT manufacturers with robust, ideally on-device security capabilities can showcase a distinct advantage, setting them apart from their competitors. Furthermore, incorporating dedicated IoT security controls enables seamless, scalable and efficient operations, reducing the need for emergency software updates.
IoT security plays a crucial role in enhancing the Overall Equipment Effectiveness (a measurement of manufacturing productivity, defined as availability x performance x quality), as well as facilitating early bug detection in IoT firmware before official release. Additionally, it demonstrates a solid commitment to prevention and security measures.
By prioritizing dedicated IoT security, we actively contribute to the establishment of secure and reliable IoT ecosystems, which serve to raise awareness, educate stakeholders, foster trust and cultivate long-term customer loyalty. Ultimately, they enhance credibility and reputation in the market. Ensuring IoT device security is essential in preventing IoT devices from falling into the hands of the dark web army.
This article was originally published via the World Economic Forum and has been reprinted with permission.
For more Cyber Talk insights from Antoinette Hodes, please click here. Lastly, to receive stellar cyber insights, groundbreaking research and emerging threat analyses each week, subscribe to the CyberTalk.org newsletter.
What is a botnet? And what does it have to do with a toaster?
We’ll get to that. First, a definition:
A botnet is a group of internet-connected devices that bad actors hijack with malware. Using remote controls, bad actors can harness the power of the network to perform several types of attacks. These include distributed denial-of-service (DDoS) attacks that shut down internet services, breaking into other networks to steal data, and sending massive volumes of spam.
In a way, the metaphor of an “army of devices” leveling a cyberattack works well. With thousands or even millions of compromised devices working in concert, bad actors can do plenty of harm. As we’ll see in a moment, they’ve done their share already.
Which brings us back to that toaster.
The pop-up toaster as we know it first hit the shelves in 1926, under the brand name “Toastmaster.”[i] With a familiar springy *pop*, it has ejected toast just the way we like it for nearly a century. Given that its design was so simple and effective, it’s remained largely unchanged. Until now. Thanks to the internet and so-called “smart home” devices.
Toasters, among other things, are all getting connected. And have been for a few years now, to the point where the number of connected Internet of Things (IoT) devices reaches well into the billions worldwide — which includes smart home devices.[ii]
Businesses use IoT devices to track shipments and various aspects of their supply chain. Cities use them to manage traffic flow and monitor energy use. (Does your home have a smart electric meter?) And for people like us, we use them to play music on smart speakers, see who’s at the front door with smart doorbells, and order groceries from an LCD screen on our smart refrigerators — just to name a few ways we’ve welcomed smart home devices into our households.
In the U.S. alone, smart home devices make up a $30-plus billion marketplace per year.[iii] However, it’s still a relatively young marketplace. And with that comes several security issues.
IoT security issues and big-time botnet attacks
First and foremost, many of these devices still lack sophisticated security measures, which makes them easy pickings for cybercriminals. Why would a cybercriminal target that smart lightbulb in your living room reading lamp? Networks are only as secure as their least secure device. Thus, if a cybercriminal can compromise that smart lightbulb, it can potentially give them access to the entire home network it is on — along with all the other devices and data on it.
More commonly, though, hackers target smart home devices for another reason. They conscript them into botnets. It’s a highly automated affair. Hackers use bots to add devices to their networks. They scan the internet in search of vulnerable devices and use brute-force password attacks to take control of them.
At issue: many of these devices ship with factory usernames and passwords. Fed with that info, a hacker’s bot can have a relatively good success rate because people often leave the factory password unchanged. It’s an easy in.
Results from one real-life test show just how active these hacker bots are:
We created a fake smart home and set up a range of real consumer devices, from televisions to thermostats to smart security systems and even a smart kettle – and hooked it up to the internet.
What happened next was a deluge of attempts by cybercriminals and other unknown actors to break into our devices, at one stage, reaching 14 hacking attempts every single hour.
Put another way, that hourly rate added up to more than 12,000 unique scans and attack attempts a week.[iv] Imagine all that activity pinging your smart home devices.
Now, with a botnet in place, hackers can wage the kinds of attacks we mentioned above, particularly DDoS attacks. DDoS attacks can shut down websites, disrupt service and even choke traffic across broad swathes of the internet.
Remember the “Mirai” botnet attack of 2016, where hackers targeted a major provider of internet infrastructure?[v] It ended up crippling traffic in concentrated areas across the U.S., including the northeast, Great Lakes, south-central, and western regions. Millions of internet users were affected, people, businesses, and government workers alike.
Another more recent set of headline-makers are the December 2023 and July 2024 attacks on Amazon Web Services (AWS).[vi],[vii] AWS provides cloud computing services to millions of businesses and organizations, large and small. Those customers saw slowdowns and disruptions for three days, which in turn slowed down and disrupted the people and services that wanted to connect with them.
Also in July 2024, Microsoft likewise fell victim to a DDoS attack. It affected everything from Outlook email to Azure web services, and Microsoft Office to online games of Minecraft. They all got swept up in it.[viii]
These attacks stand out as high-profile DDoS attacks, yet smaller botnet attacks abound, ones that don’t make headlines. They can disrupt the operations of websites, public infrastructure, and businesses, not to mention the well-being of people who rely on the internet.
Botnet attacks: Security shortcomings in IoT and smart home devices
Earlier we mentioned the problem of unchanged factory usernames and passwords. These include everything from “admin123” to the product’s name. Easy to remember, and highly insecure. The practice is so common that they get posted in bulk on hacking websites, making it easy for cybercriminals to simply look up the type of device they want to attack.
Complicating security yet further is the fact that some IoT and smart home device manufacturers introduce flaws in their design, protocols, and code that make them susceptible to attacks.[ix] The thought gets yet more unsettling when you consider that some of the flaws were found in things like smart door locks.
The ease with which IoT devices can be compromised is a big problem. The solution, however, starts with manufacturers that develop IoT devices with security in mind. Everything in these devices will need to be deployed with the ability to accept security updates and embed strong security solutions from the get-go.
Until industry standards get established to ensure such basic security, a portion of securing your IoT and smart home devices falls on us, as people and consumers.
Steps for a more secure network and smart devices
As for security, you can take steps that can help keep you safer. Broadly speaking, they involve two things: protecting your devices and protecting the network they’re on. These security measures will look familiar, as they follow many of the same measures you can take to protect your computers, tablets, and phones.
Grab online protection for your smartphone.
Many smart home devices use a smartphone as a sort of remote control, not to mention as a place for gathering, storing, and sharing data. So whether you’re an Android owner or iOS owner, use online protection software on your phone to help keep it safe from compromise and attack.
Don’t use the default — Set a strong, unique password.
One issue with many IoT devices is that they often come with a default username and password. This could mean that your device and thousands of others just like it all share the same credentials, which makes it painfully easy for a hacker to gain access to them because those default usernames and passwords are often published online. When you purchase any IoT device, set a fresh password using a strong method of password creation, such as ours. Likewise, create an entirely new username for additional protection as well.
Use multi-factor authentication.
Online banks, shops, and other services commonly offer multi-factor authentication to help protect your accounts — with the typical combination of your username, password, and a security code sent to another device you own (often a mobile phone). If your IoT device supports multi-factor authentication, consider using it there too. It throws a big barrier in the way of hackers who simply try and force their way into your device with a password/username combination.
Secure your internet router too.
Another device that needs good password protection is your internet router. Make sure you use a strong and unique password as well to help prevent hackers from breaking into your home network. Also, consider changing the name of your home network so that it doesn’t personally identify you. Fun alternatives to using your name or address include everything from movie lines like “May the Wi-Fi be with you” to old sitcom references like “Central Perk.” Also check that your router is using an encryption method, like WPA2 or the newer WPA3, which keeps your signal secure.
Upgrade to a newer internet router.
Older routers might have outdated security measures, which might make them more prone to attacks. If you’re renting yours from your internet provider, contact them for an upgrade. If you’re using your own, visit a reputable news or review site such as Consumer Reports for a list of the best routers that combine speed, capacity, and security.
Update your apps and devices regularly.
In addition to fixing the odd bug or adding the occasional new feature, updates often fix security gaps. Out-of-date apps and devices might have flaws that hackers can exploit, so regular updating is a must from a security standpoint. If you can set your smart home apps and devices to receive automatic updates, that’s even better.
Set up a guest network specifically for your IoT devices.
Just as you can offer your guests secure access that’s separate from your own devices, creating an additional network on your router allows you to keep your computers and smartphones separate from IoT devices. This way, if an IoT device is compromised, a hacker will still have difficulty accessing your other devices on your primary network, the one where you connect your computers and smartphones.
Shop smart.
Read trusted reviews and look up the manufacturer’s track record online. Have their devices been compromised in the past? Do they provide regular updates for their devices to ensure ongoing security? What kind of security features do they offer? And privacy features too? Resources like Consumer Reports can provide extensive and unbiased information that can help you make a sound purchasing decision.
Don’t let botnets burn your toast
As more and more connected devices make their way into our homes, the need to ensure that they’re secure only increases. More devices mean more potential avenues of attack, and your home network is only as secure as the least secure device that’s on it.
While standards put forward by industry groups such as UL and Matter have started to take root, a good portion of keeping IoT and smart home devices secure falls on us as consumers. Taking the steps above can help prevent your connected toaster from playing its part in a botnet army attack — and it can also protect your network and your home from getting hacked.
It’s no surprise that IoT and smart home devices have raked in billions of dollars over the years. They introduce conveniences and little touches into our homes that make life more comfortable and enjoyable. However, they’re still connected devices. And like anything that’s connected, they must be protected.
Login
