One Civic owner purchased a cheap aftermarket head unit off Amazon, and decided to have Claude work its magic on it, like it would a smart TV. What was reportedly discovered isnβt surprising, but is worth knowing about.
Among the pre-installed bloatwareβΒor spyware, if youβre being less charitableΒβwas a voice assistant equipped with WebView, an Android system component that lets apps display content off the web. This apparently always used about a third of processing power, even while idle, which isnβt great. There were also Baidu location services, a call recorder (!), a DAB radio client that is pretty much useless in the U.S., and Adobe Acrobat, presumably so your passenger can entertain themselves with PDFs on the go.
Itβs interesting because it exposes all the insecurities in this piece of IoT software. But I think the real story is that a random person was able to do this reverse-engineering with the help of AI. Expect a lot more stories like this in the future.
Today, in most countries around the world, virtually every reasonably large city is packed with video cameras. On the one hand, the idea, of course, is to βkeep us safeβ: to monitor security in the streets, improve road safety and enforce traffic rules, and so on. But thereβs the other side of the coin β ubiquitous video surveillance creates both privacy risks and opportunities for unauthorized surveillance Weβve repeatedly posted on our blog about how to protect yourself from surveillance involving IP cameras.
Thereβs another problem, too: relying too heavily on video surveillance systems can also be dangerous. If your cameras arenβt adequately cyber-secure, attackers may be able to disable them remotely to be able to then enter physical areas supposedly protected by video surveillance without being detected. This issue is especially relevant to home and privately managed surveillance systems β large companies generally do a better job of securing their devices (although there are exceptions there as well).
Disabling or replacing a camera feed is an almost obligatory plot device in heist movies. But unfortunately, this isnβt just a screenwriterβs invention: our recent research uncovered a vulnerability that makes it possible to remotely disable IP cameras made by Intelbras β a popular camera manufacturer. Read on to learn what the problem is, and how to protect your surveillance systems; a detailed technical analysis of the vulnerability is available on our expert blog, Securelist.
When an update does more harm than good
A surveillance camera is essentially a fully-fledged mini-computer, and its firmware needs to be updated regularly. In this case, however, the vulnerability was hidden in the firmware update procedure itself.
Intelbras provides firmware update files on its official website. The firmware can be updated manually from an SD card, or over the local network via the web interface or mobile app. However, during a firmware update, the camera neither required (past tense; a patch has since been issued β see below) authentication nor validated the firmware file before starting the update. As a result, anyone connected to the same Wi-Fi network as the camera could send it an update request. When an update is initiated, the camera reboots, taking it offline for about a minute before it becomes available again. But if the requests are sent repeatedly in a loop, the camera can be kept offline indefinitely.
We investigated this vulnerability on an Intelbras iM3 C (iM3B-C) camera running firmware version v240927 β the latest available at the time of our research. The iM3 C is a smart Full-HD Wi-Fi camera designed for both home surveillance and as a baby monitor. According to Intelbras, the firmware for the iM3 C is also compatible with the iMX C, iM4 C, iM5 SC, iME 360 C, and iM7+ FC models.
Intelbras iM3 C smart Wi-Fi camera used for the investigation. Its firmware is also compatible with the iMX C, iM4 C, iM5 SC, iME 360 C, and iM7+ FC models. Source
This vulnerability has a medium severity rating. However, because of the large number of potentially affected users, the impact of successful exploitation could be significant. Intelbras Mibo Smart β Intelbrasβs app for setting up and managing these camera models β has been downloaded more than four million times, with most of its users based in Brazil and elsewhere in Latin America.
How to secure your cameras and other smart devices
First and foremost, all Intelbras owners should update their camera firmware as soon as possible β and continue to do so regularly. More generally, itβs a good idea to secure your smart-home infrastructure in advance to reduce the risk posed by other potential vulnerabilities.
One of the simplest yet most important steps is to change the default settings on both your smart devices and your home network. Be sure to replace the factory-default passwords on all smart devices and on your router β default username/password combinations such as admin/admin or root/admin provide no meaningful protection.
Protect your home Wi-Fi with a strong password; otherwise, attackers could easily gain access to your local network.
Disable WPS on your router. WPS is designed to simplify network setup and authentication: you can connect by pressing dedicated buttons on the router and respective device, or by entering an eight-digit PIN. The problem is that this PIN can be brute-forced relatively easily, allowing an attacker to recover the key to your Wi-Fi network fairly quickly.
Use a strong, unique password for every account that can be used to manage your smart devices through official apps or websites. Where possible, enable two-factor authentication (2FA); the most secure option is generally to use one-time codes generated by authenticator apps. For generating and storing passwords, as well as creating one-time codes, itβs most convenient to use aΒ password manager.
Put your IP cameras and other smart devices on a separate Wi-Fi network β isolating them from phones, laptops, tablets, NAS devices, and so on. Most modern routers can create at least two Wi-Fi networks (a primary and a guest network). Use the guest network for smart-home devices, but make sure itβs protected with a strong password. If your router supports multiple Wi-Fi networks, consider putting the cameras on a dedicated network of their own. That way, even if the cameras are compromised, attackers wonβt be able to reach your other devices.
Use Smart Home Monitor, available in Kaspersky Plus and Kaspersky Premium. This feature shows all devices connected to your home network, lets you check their security status, and alerts you if an unknown device joins your home Wi-Fi.
More camera-security and smart-device tips and stories:
Network-connected surveillance cameras are now widespread in both home and enterprise environments, so securing them is essential to safeguarding physical spaces and sensitive assets. As these devices continue to gain new features and network connectivity capabilities, vulnerabilities in their implementation can have significant security implications.
During our research, we discovered a denial-of-service vulnerability that affects Intelbras IP cameras systems. The flaw resides in a firmware update endpoint that is accessible without authentication and allows anyone with access to the local Wi-Fi network to knock cameras offline. A single request disrupts the camera for only about a minute, but sending periodic requests keeps the device offline indefinitely. We reported the issue to Intelbras, monitored the remediation process, validated the fix in the new firmware, and will now demonstrate the exploitation procedure step-by-step.
Following our notification, Intelbras patched the vulnerability and released updated firmware (R.260804) along with update instructions. A candidate ID of CAN-2026-2035970 has been assigned by MITRE following submission, pending the final CVE assignment. Additionally, the Intelbras team recently informed us that MITRE has classified the vulnerability as Medium, assigning it a score of 5.1 under the CVSS 4.0 framework. The issue discussed in this article is no longer present in the latest firmware version.
Firmware
Intelbras provides firmware files on its official website. While users can manually install these updates via an SD card, the cameras also natively support firmware upgrades over the local network via their web interface and mobile app. We obtained the firmware version v240927 for the iM3B-C (IM3 C) camera, which was the latest available version at the time of our research. According to Intelbras, the same firmware is also compatible with the iMX C, iM4 C, iM5 SC, iME 360 C, and iM7+ FC models. Below, we can view the firmware version and the camera model used as an example.
To provide context, we will explain how the cameraβs authentication mechanism works and why it is relevant to accessing the cameraβs endpoints. The main firmware component is an ARM binary named sonia, responsible for controlling the kernel drivers used by the camera hardware, authentication, and livestream recording, among other things.
How authentication works
The global.login RPC method handles authentication at the /RPC2_Login endpoint. First, the client, such as the mobile app or a custom script, sends the username and an empty password. The camera responds with an authentication challenge (a set of values to verify the password without transmitting it). This response returns a temporary session, the encryption type in the encryption field, a random value, and a realm (authentication scope). At this stage, a false response is normal and does not indicate a failed login, as the authentication process is not yet complete.
Next, the client calculates the response password from the authentication challenge. It first generates an MD5 (username:realm:original_password) hash as the base. It then calculates a second MD5 (username:random:first_md5) hash,Β where first_md5 is the result of the previous step. To complete the authentication, the client sends this final result back to /RPC2_Login in a second global.login call, passing the username, calculated password, and temporary session ID.
If the login is accepted, the camera returns true and a new, authenticated session. This session must be used for all subsequent RPC calls, including the cameraβs other endpoints, for example, the one that reboots the device or those that expose sensitive information.
Affected endpoint
The affected endpoint is the firmware upgrade route http://<ip_address>/firmwareUpgrade_service/Demo, which lacks authentication checks; furthermore, it fails to verify whether the firmware is actually valid before initiating the upgrade process. This creates a serious issue because the upgrade requires the camera to reboot, and that is precisely when the problem occurs: the camera enters reboot mode and eventually shuts down, appearing offline to the user and anyone who has the camera registered on their device.
PoC: vulnerability exploitation
Now that we have outlined how the vulnerability works, we will use a Python script on an iM3B-C camera to exploit it for demonstration purposes. The exploit contacts the cameraβs endpoint to upload firmware. Below, we can see sonia creating the endpoint responsible for the firmware upgrade.
Next, the exploit will hit the endpoint and cause the camera to reboot. Consequently, mobile phones running the Intelbras app will lose connection with the registered device. Below, we can see the camera operating normally: the green light is on and the app is showing it is available for viewing.
The camera is online
After the exploit executes, we can see the effects: the camera goes offline and loses connection to the registered devices.
The camera is offline
The exploit is quite simple: it sends an HTTP POST request with the firmware, which causes the camera to accept the request and initiate the reboot process. It does not matter whether the firmware is original; the reboot process will start regardless.
New firmware version
After we notified Intelbras about this flaw in the endpoint implementation, the company contacted the OEM vendor. As a result, a new firmware version was released that requires authentication to initiate an update through this endpoint.
Below, we can compare the new firmware, which validates cookies and session data, with the old firmware, which performed no authentication checks and proceeded directly to the update routine.
Real risk
An attacker can remotely trigger the camera firmware upgrade and reboot process without authenticating or supplying a valid firmware image. This may cause the device to go offline, which results in a denial-of-service condition preventing legitimate users from accessing live monitoring or managing the camera.
The potential impact is significant due to the number of affected users. The Intelbras Mibo Smart app, which the company provides to connect and manage the devices mentioned in this report, has over 4,000,000 downloads. Brazil represents the largest user base, followed by Paraguay, Ecuador, Colombia, Argentina, Chile, Peru, Bolivia, Uruguay, and Venezuela. As a result, exploitation of this issue affects a large number of users.
Takeaways
This is a medium-severity vulnerability that Intelbras is already aware of. The issue has been addressed in a newer firmware release (R.260804 along with update instructions), which mitigates this attack vector. Because the vulnerability directly affects the availability and normal operation of the affected cameras, it is highly recommended that users verify the firmware version currently installed on their devices and update to the latest available version as soon as possible. Keeping the firmware up to date is an essential security practice, especially for internet-connected surveillance devices, as outdated versions may remain exposed to known vulnerabilities.
Network-connected surveillance cameras are now widespread in both home and enterprise environments, so securing them is essential to safeguarding physical spaces and sensitive assets. As these devices continue to gain new features and network connectivity capabilities, vulnerabilities in their implementation can have significant security implications.
During our research, we discovered a denial-of-service vulnerability that affects Intelbras IP cameras systems. The flaw resides in a firmware update endpoint that is accessible without authentication and allows anyone with access to the local Wi-Fi network to knock cameras offline. A single request disrupts the camera for only about a minute, but sending periodic requests keeps the device offline indefinitely. We reported the issue to Intelbras, monitored the remediation process, validated the fix in the new firmware, and will now demonstrate the exploitation procedure step-by-step.
Following our notification, Intelbras patched the vulnerability and released updated firmware (R.260804) along with update instructions. A candidate ID of CAN-2026-2035970 has been assigned by MITRE following submission, pending the final CVE assignment. Additionally, the Intelbras team recently informed us that MITRE has classified the vulnerability as Medium, assigning it a score of 5.1 under the CVSS 4.0 framework. The issue discussed in this article is no longer present in the latest firmware version.
Firmware
Intelbras provides firmware files on its official website. While users can manually install these updates via an SD card, the cameras also natively support firmware upgrades over the local network via their web interface and mobile app. We obtained the firmware version v240927 for the iM3B-C camera, which was the latest available version at the time of our research. According to Intelbras, the same firmware is also compatible with the iMX C, iM4 C, iM5 SC, iME 360 C, and iM7+ FC models. Below, we can view the firmware version and the camera model used as an example.
To provide context, we will explain how the cameraβs authentication mechanism works and why it is relevant to accessing the cameraβs endpoints. The main firmware component is an ARM binary named sonia, responsible for controlling the kernel drivers used by the camera hardware, authentication, and livestream recording, among other things.
How authentication works
The global.login RPC method handles authentication at the /RPC2_Login endpoint. First, the client, such as the mobile app or a custom script, sends the username and an empty password. The camera responds with an authentication challenge (a set of values to verify the password without transmitting it). This response returns a temporary session, the encryption type in the encryption field, a random value, and a realm (authentication scope). At this stage, a false response is normal and does not indicate a failed login, as the authentication process is not yet complete.
Next, the client calculates the response password from the authentication challenge. It first generates an MD5 (username:realm:original_password) hash as the base. It then calculates a second MD5 (username:random:first_md5) hash,Β where first_md5 is the result of the previous step. To complete the authentication, the client sends this final result back to /RPC2_Login in a second global.login call, passing the username, calculated password, and temporary session ID.
If the login is accepted, the camera returns true and a new, authenticated session. This session must be used for all subsequent RPC calls, including the cameraβs other endpoints, for example, the one that reboots the device or those that expose sensitive information.
Affected endpoint
The affected endpoint is the firmware upgrade route http://<ip_address>/firmwareUpgrade_service/Demo, which lacks authentication checks; furthermore, it fails to verify whether the firmware is actually valid before initiating the upgrade process. This creates a serious issue because the upgrade requires the camera to reboot, and that is precisely when the problem occurs: the camera enters reboot mode and eventually shuts down, appearing offline to the user and anyone who has the camera registered on their device.
PoC: vulnerability exploitation
Now that we have outlined how the vulnerability works, we will use a Python script on an iM3B-C camera to exploit it for demonstration purposes. The exploit contacts the cameraβs endpoint to upload firmware. Below, we can see sonia creating the endpoint responsible for the firmware upgrade.
Next, the exploit will hit the endpoint and cause the camera to reboot. Consequently, mobile phones running the Intelbras app will lose connection with the registered device. Below, we can see the camera operating normally: the green light is on and the app is showing it is available for viewing.
The camera is online
After the exploit executes, we can see the effects: the camera goes offline and loses connection to the registered devices.
The camera is offline
The exploit is quite simple: it sends an HTTP POST request with the firmware, which causes the camera to accept the request and initiate the reboot process. It does not matter whether the firmware is original; the reboot process will start regardless.
New firmware version
After we notified Intelbras about this flaw in the endpoint implementation, the company contacted the OEM vendor. As a result, a new firmware version was released that requires authentication to initiate an update through this endpoint.
Below, we can compare the new firmware, which validates cookies and session data, with the old firmware, which performed no authentication checks and proceeded directly to the update routine.
Real risk
An attacker can remotely trigger the camera firmware upgrade and reboot process without authenticating or supplying a valid firmware image. This may cause the device to go offline, which results in a denial-of-service condition preventing legitimate users from accessing live monitoring or managing the camera.
The potential impact is significant due to the number of affected users. The Intelbras Mibo Smart app, which the company provides to connect and manage the devices mentioned in this report, has over 4,000,000 downloads. Brazil represents the largest user base, followed by Paraguay, Ecuador, Colombia, Argentina, Chile, Peru, Bolivia, Uruguay, and Venezuela. As a result, exploitation of this issue affects a large number of users.
Takeaways
This is a medium-severity vulnerability that Intelbras is already aware of. The issue has been addressed in a newer firmware release (R.260804 along with update instructions), which mitigates this attack vector. Because the vulnerability directly affects the availability and normal operation of the affected cameras, it is highly recommended that users verify the firmware version currently installed on their devices and update to the latest available version as soon as possible. Keeping the firmware up to date is an essential security practice, especially for internet-connected surveillance devices, as outdated versions may remain exposed to known vulnerabilities.
In 2026, the owner of an ordinary home router, smart TV, or TV box is a prime target for cybercriminals. These devices are readily recruited into botnets and residential proxy networks, which weβve covered before.
Criminals βsubleaseβ the infected device by letting outsiders pay to visit any website from the victimβs IP address, so it looks like the deviceβs owner is doing it. The service is in demand across all kinds of shady schemes: from ad fraud and spam campaigns to password bruteforcing and account hacking. In our previous post, we described how home routers get recruited into these proxy networks; today we take a look at an even more vulnerable, and equally ubiquitous category of devices: smart TVs and TV boxes.
These appeal to criminals for two reasons. First, unlike computers and smartphones, TVs are almost always plugged into the power and have a fast internet connection. A dark screen doesnβt mean the device is switched off. On top of that, the limited user interface and monitoring tools mean suspicious background processes can easily slip unnoticed past users.
The threat is evolving and growing more aggressive. A recent study found that once proxyware turns up on a set-top box, the risks to its owner go well beyond having their traffic siphoned off.
SuperBoxβs marketing leans heavily on the promise of providing thousands of TV channels, with no subscription or monthly fees. But out of the box, the device canβt actually do anything of the sort. To get access to pirated content, you need to install the brandβs proprietary app store.
When you launch it and install additional apps, the thousands of TV channels do appear. Meanwhile behind the scenes, with no warnings or permission prompts, the device floods external sites with unauthorized requests, and network traffic spikes sharply.
The researchers uncovered several alarming facts. First, the victim gets enrolled into as many as five botnets at once. The SuperBox runs clients for several proxyware networks simultaneously, which even try to compete with one another by blocking rival software from being installed.
But the real shock was the attacks on the internal network. The TV boxβs proxyware places no limits on what its paying clients can actually do on the network. They can reach not only external sites but also devices inside your home network.
Normally, your home router and ISP settings protect you from outside attacks. But proxyware bypasses these barriers because it operates from inside the network. During an experiment, the researchers confirmed that an attacker on the internet can easily leverage the infected set-top box to open the admin panel of a home router, such as a Linksys, which is supposed to be accessible only to its owner when connected to the home Wi-Fi network. This means hackers can try to steal data from other devices in the same household, or even encrypt home network storage (NAS).
At the same time, flaws in SuperBoxβs factory firmware let hackers remotely install and run any application with superuser privileges, and the threat is anything but hypothetical. Over three weeks of monitoring, the test set-top box was hit by more than 1300 attacks through the home proxy network. Attackers installed three different types of malware, including a module for launching DDoS attacks.
The malware uses several methods to gain a foothold in the system, and it survives reboots and power failures alike.
How to tell if your set-top box is working for hackers
If you have a cheap TV set-top box or Android TV from a little-known brand, itβs worth checking it for anomalies.
The most reliable method is to review the network traffic. Use the statistics in your routerβs control panel, but note that some budget models may lack this feature. This feature is called Traffic Analyzer on Asus routers, Traffic Usage on TP-Link, and Traffic Monitor on Keenetic. Find your TV or set-top box in the device list and check the ratio of downloaded to uploaded data. They should consume a lot of traffic to download video while sending very little. If your box is quietly pushing gigabytes of data out or staying chatty on the network even while idle, thatβs a telltale sign itβs infected.
If traffic statistics arenβt available, look for indirect signs:
The network and memory activity LEDs wonβt stop blinking even though no oneβs using the device.
The set-top boxβs casing is constantly warm or hot.
The interface lags behind the remote, and the box freezes at random moments that have nothing to do with heavy video playback.
Your other devices (computers or phones) are seeing a real drop in internet speed.
When trying to visit familiar sites over your home Wi-Fi, youβre constantly hit with a CAPTCHA β a sign your network may be compromised and flagged as a spam source.
Your ISPβs tech support calls you asking about suspicious network loads.
What to do with an infected device
The best solution is to disconnect the device from the internet and dispose of it. If you have to keep using it, follow these steps to minimize the risks:
Do a factory (hard) reset. Restore the set-top box to its original state.
Take it offline before setting up again. The first time you turn it on after a reset, skip the Wi-Fi setup step and donβt plug in the Ethernet cable.
Block app installation. Go to Android settings and disable installation of apps from unknown sources. Be sure to turn off any debugging features if enabled: USB debugging, Wireless debugging, and ADB. Menu item names may differ depending on your Android version and device manufacturer.
Isolate it on the network. Set up a guest Wi-Fi network on your router and connect the TV box to it. Enable Client Isolation in your routerβs settings, if it has it. This will stop the box from seeing other devices on your home network, which protects your computers and network storage.
Check for updates. Once the box is connected to the guest network, check for official firmware updates: manufacturers sometimes patch known vulnerabilities, though with lesser-known brands, you shouldnβt count on it.
Your most reliable safeguards
Buying cheap devices with pirate streaming features and installing software from shady sources is a surefire way to compromise your home network. Your IP address will become a source of malicious activity, which at best gets you blocked by your ISP and at worst puts you on law enforcementβs radar. Whatβs more, hackers can use the box as a launchpad to attack your home computers and NAS, which can lead to personal data theft or a ransomware attack.
The best protection is to buy devices from trusted brands and pay for legal content. And to rule out someone hijacking control of your network, make sure your routerβs admin panel and other home devices are protected with unique, strong passwords. To avoid having to remember them all, use a reliable password manager such as Kaspersky Password Manager. Additionally, the Smart Home Monitor feature included in Kaspersky PremiumΒ lets you keep all your devices fully under control.
There may be more things you donβt know about your smart home devices:
Security researchers have found a way to hack a Boeing 737 with a device no bigger than a coin. The 737 is one of the most widely used airliners in the world, so chances are youβve flown on one yourself at least once.
The attack requires installing a small device in a port thatβs accessible through a hatch on the outside of the plane. According to the researchers, this port is regularly within reach not just of maintenance crews, but of other airport and airline staff too. And installing the device takes less than 60 seconds. So letβs talk about what this mysterious little device actually is, what it can do, and whether itβs still safe to fly on a Boeing 737.
Why hacking a plane is harder than hacking a car
Most of us have gotten used to the idea that our computers and phones can be hacked. Itβs probably the most common topic on this blog. But weβve also covered attacks on less common targets: cars, robot lawnmowers, automated card shufflers, bikes, and even mattresses. In todayβs world, all of these (and many other) devices contain tiny (or not-so-tiny) computers.
Airplanes are no exception. A modern airliner is packed with computers β some of which handle critical functions: from calculating takeoff parameters to controlling the flight itself. But thereβs one key difference: airliner manufacturers, unlike the makers of most smart home gadgets, take security very seriously, which makes it far harder to reach these systems from the outside.
Maybe thatβs precisely why the idea of hacking a real plane has been tempting the most inquisitive security researchers for years. A team at the University of California San Diego and Oberlin College β the researchers who finally pulled it off β spent more than a decade wrestling with the problem. As mentioned above, the main challenge in hacking a plane is that its critical systems arenβt connected to the external internet. Because of that, studying plane-related attack vectors wasnβt seen as especially promising within the cybersecurity research community: reaching isolated systems remotely is extremely difficult, and the odds of an attacker gaining physical access were considered very low.
Two other successful projects changed that assumption for UC San Diego researchers Kirill Levchenko and Aaron Schulman: a hack of the Chevrolet Impala, and research into payment card skimmers. The car hack led their team to buy secondhand Boeing 737 computer components and build their own test rig. The skimmer research gave them the idea for a small physical device that could plug directly into the planeβs internal systems.
The port sits in the electronics bay beneath the cockpit. From outside the plane, itβs covered only by an unlocked hatch. Source
Β A βbus driverβ at the controls
On their test rig, the researchers checked what would happen if they connected to the ARINC 429 bus through this port and sent electrical signals more powerful than the ones the Boeingβs components normally exchange with one another. It turned out that doing so let them override legitimate commands with their own. From there, all that was left was building a device small enough to fit into the port theyβd found.
Step by step, the team built a device compact enough to slot into the unprotected port. The finished version set them back less than US$100, and appears to have been built largely from off-the-shelf parts: a small microcontroller, electronics for communicating with the bus, and a Wi-Fi module. That last part could potentially help the device connect to the planeβs public in-flight Wi-Fi network, giving the attacker access over the internet, and eventually letting them control the device remotely. And the whole thing takes less than a minute to install into the port.
The device the researchers built to connect to Boeing 737 systems. A coin sits next to it for scale. Source
The researchers dubbed their attack βBus Driverβ, apparently a play on words: βbusβ refers to both a passenger vehicle and the data channel that lets a systemβs components talk to each other. The attack lets someone step into that channel and swap out the commands being sent β effectively controlling the bus.
What the improvised Boeing 737 hacking device can actually do
An unprotected port, a coin-sized device, access to the bus: thatβs all and well and good, but what did the researchers actually manage to pull off? What kind of damage can this tiny implant do? As it turns out, quite a lot β potentially even fatal. By gaining the ability to tamper with the data flowing between the flight management computer and the control and display unit, the researchers found they could interfere with several critical aspects of how the plane operates.
Researchers testing Bus Driver on real Boeing 737 avionics hardware. Their attack interface is running on the MCDU screen. Source
First, the implant can alter the data used to calculate takeoff and landing parameters. For example, it can change the planeβs recorded zero-fuel weight, which throws off the calculation of the speeds needed for a safe takeoff.
The device can also manipulate the assumed temperature value pilots use to determine how much engine thrust is needed at takeoff. Feed the system the wrong numbers, and under certain conditions the plane could end up with insufficient thrust to take off safely β potentially even going off the end of the runway. Faulty calculations during landing carry similarly serious risks.
The implant can also change the route the autopilot is following. On a long flight, a deviation of just a few degrees β subtle enough to go unnoticed β could be enough to send the plane badly off course so it runs out of fuel somewhere over open ocean.
Beyond that, an attacker could use the device to steer the plane into the airspace of a country that isnβt part of its approved flight path. That kind of deviation can also have deadly consequences: the history of civil aviation has seen more than one case of a passenger plane being mistakenly shot down by the military after straying into restricted airspace.
Of course, the odds of a deviation like this slipping past both pilots and air traffic control are very low, but disasters tend to happen exactly when several human errors line up.
Once installed, the implant is nearly invisible inside the port and very hard to spot unless you know to look for it. Source
Finally, the device doesnβt just let someone change flight parameters, it lets them hide those changes from the pilots. For instance, an attacker could load a new route into the flight computer while simultaneously altering whatβs shown on the MCDU display, so the pilots keep seeing the original route.
That said, the researchers note that in most cases an attentive crew would catch the discrepancy. The correct data still shows up on other cockpit displays, and switching to manual control lets pilots disengage the autopilot and take back control of the plane.
So, should we all switch to trains?
To wrap up, Iβll try to put the longtime aerophobes (and anyone this article has just turned into one) at ease. The researchers themselves say that despite everything theyβve learned, they still fly on Boeing 737s. And to avoid causing any real-world trouble, they deliberately left out exactly which port they used in their experiments.
The researchers also reached out to Boeing back in 2020 to share their findings. Boeing took the information seriously and worked on addressing the issue.
Specifically, the researchers suggested Boeing either remove the vulnerable port or seal it with epoxy resin to physically rule out the possibility of someone plugging in an unauthorized device. There are more involved options too, like redesigning the internal busβs electrical protections so a rogue device canβt override the real signals, and adding systems that can detect this kind of attack in the first place.
Longer term, the researchers recommend that Boeing, along with other aircraft manufacturers, adopt cryptographic authentication for the messages passed between avionics components.
Whether Boeing acted on this specific advice or came up with its own fixes isnβt publicly known. When Wired reporters asked the company about it, the response was fairly vague:
βOur technical experts are confident that the layers of protection in place on the airplane, including within the system design and the operating environment, provide sufficient mitigation to significantly limit the feasibility and risk of real-world attacks.β
So no, thereβs apparently no need to swear off Boeing 737 flights just yet. That said, I happen to have a lot of respect for trains, so I wonβt try to talk you out of traveling by rail or using other ways of getting around either. Iβve actually written about train hacking on this blog before, though in that case the goal was constructive, not destructive.
Cars, lawnmowers, card shufflers, bikes, smart mattresses β itβs not even an exhaustive list of the devices that hackers have successfully tampered with. What else was hacked? Find out in our other posts:
Threat actors are already gearing up for this yearβs biggest football (soccer) event, the World Cup 2026. With millions of fans looking for ways to stream matches online, many will turn to IPTV apps to watch live TV broadcasts over the internet. Itβs no surprise, then, that cybersecurity researchers have discovered multiple campaigns over the past few months where malware was disguised as fake Android IPTV apps.
In this post, we discuss what IPTV apps are, how criminals use fake versions to spread malware, what this malware is capable of, and, most importantly, how to avoid becoming a victim.
What are IPTV apps?
IPTV stands for Internet Protocol Television. This technology delivers TV content over the internet instead of through cable, over-the-air antennas, or satellites. Naturally, the simplest and most common examples of IPTV are the official platforms of TV networks, which can include both websites and dedicated apps.
However, alongside official options, pirate IPTV services also exist. They usually lure users with free or dirt-cheap access to content that can otherwise be hard to find without expensive subscriptionsΒ β most notably broadcasts of various sporting events; football matches in particular.
As is typically the case with pirated content, these apps are blocked from official app stores, forcing users to download them from third-party sites. Consequently, the risk of using these services isnβt tied to IPTV technology itself, but rather to the fake apps and modified APK files distributed under the guise of well-known platformsΒ β both official and pirated.
Massiv banking Trojan disguised as IPTV apps
For instance, in February researchers found the Massiv banking Trojan distributed under the guise of fake IPTV apps. Even then, experts noted that this wasnβt the only malware leveraging this tacticΒ β several others were also spotted in the wild. The primary targets of these IPTV-mimicking malicious fakes have mostly been users in Portugal, Spain, France, and TΓΌrkiye.
In most cases, the discovered fake IPTV apps lacked the advertised functionality, so users didnβt get access to any content after installing the apps. Instead, the fake app would open the website of a legitimate IPTV service in a built-in browser to mimic normal functioning and avoid raising user suspicion.
Of course, the most interesting activity happened out of the userβs sight. These are some of the features the malware did have:
Displaying fake windows on top of legitimate ones: fake forms for entering bank details or signing in to official services, as shown in the screenshot below.
Activating a keylogger: recording and transmitting screen keyboard taps to the attackers.
Hijacking control of the compromised device.
The Massiv banking Trojan mimics the interface of the Portuguese government app Chave MΓ³vel Digital in a fake pop-up window, looking even more convincing than the official version from Google Play. Source
Perseus steals valuable information from usersβ notes
In March, researchers reported on a new campaign where several fake IPTV apps were used to distribute an even more advanced and feature-rich malware strain: Perseus.
Research into Perseus shows that the malware is based on the source code of an Android banking Trojan called Cerberus, which leaked nearly six years ago. Perseus comes in two different versions: Turkish and English. The English-language version is more advanced and shows clear signs of AI-driven refinement.
Perseus abuses Accessibility Services, a set of Android features originally designed to make life easier for users with severe visual impairments. Fraudsters learned long ago how to leverage this tool to steal data from Android devices β a topic weβve covered in detail across several of our posts.
An example of a malicious APK disguised as Roja Directa TV, another IPTV app. Source
By abusing Accessibility Services, Perseus gains remote control over the victimβs device. Hereβs what it can do:
Continuously capture and exfiltrate screenshots.
Send a structured map of the deviceβs UI for remote manipulation.
Mimic taps, swipes, text input, long presses, and other UI interactions.
Turn on the screen, launch apps, and block them from running.
Trigger a pitch-black screen overlay to hide its activities.
Log keystrokes.
On top of that, the English-language version of Perseus boasts another notable feature. The malware can hunt for sensitive information like passwords, recovery phrases, and financial data across an entire range of note-taking apps: Google Keep, Xiaomi Notes, Samsung Notes, ColorNote, Evernote, Microsoft OneNote, and Simple Notes.
All of these capabilities help criminals drain football fansβ money not just from various banking services, but from cryptocurrency apps as well.
How not to let cybercrooks ruin your World Cup
The World Cup is just around the corner, and millions of fans worldwide will definitely want to tune in to this yearβs premier football event. Past experience shows that cybercriminals frequently cash in on major spectacles like this. So, how can you watch theΒ matches safely?
Donβt download apps from unofficial stores.
Even when downloading an app from an official storeΒ β since malware occasionally slips through the cracks there, tooβ read the reviews carefully. Users who have been burned by fakes and malware often leave comments to warn others.
Avoid storing passwords or other sensitive information in note-taking apps. To ensure your data and finances stay secure, use a reliable password manager. By the way, Kaspersky Password ManagerΒ includes an encrypted note-taking feature, allowing you to store your valuable information safely.
You canβt even watch TV safely anymore these days! Check out other threats facing TV lovers:
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.
Quarterly figures
In Q1Β 2026:
Kaspersky products blocked more than 343 million attacks that originated with various online resources.
Web Anti-Virus responded to 50 million unique links.
File Anti-Virus blocked nearly 15 million malicious and potentially unwanted objects.
2938 new ransomware variants were detected.
More than 77,000 users experienced ransomware attacks.
14% of all ransomware victims whose data was published on threat actorsβ data leak sites (DLS) were victims of Clop.
More than 260,000 users were targeted by miners.
Ransomware
Quarterly trends and highlights
Law enforcement success
In January 2026, it was reported that the FBI had seized the domains of the RAMP cybercrime forum, a major platform used extensively by ransomware developers to advertise their RaaS programs and to recruit affiliates. There has been no official statement from the FBI, nor is it clear if RAMP servers were seized. In a post on an external website, a RAMP moderator mentioned law enforcement agencies gaining control over the forum. The takedown disrupted a key element of the RaaS ecosystem, creating ripple effects for ransomware operators, affiliates, and initial access brokers.
A man suspected of links to the Phobos group was apprehended in Poland. He was charged with the creation, acquisition, and distribution of software designed for unlawfully obtaining information, including data that facilitates unauthorized access to information stored within a computer system.
In March, a Phobos ransomware administrator pleaded guilty to the creation and distribution of the Trojan, which had been used in international attacks dating back to at least November 2020.
In March, the U.S. Department of Justice charged a man who had acted as a negotiator for ransomware groups. The company he worked for specializes in cyberincident investigations. The prosecution alleges the suspect colluded with the BlackCat threat actor to share privileged insights into the ongoing progress of negotiations. Additionally, the suspect is alleged to have had a prior direct role in BlackCat attacks, serving as an affiliate for the RaaS operation.
In a separate development this March, a U.S. court sentenced an initial access broker associated with the Yanluowang ransomware group to 81 months of imprisonment. According to the U.S. Department of Justice, the convict facilitated dozens of ransomware attacks across the United States, resulting in over $9 million in actual loss and more than $24 million in intended loss.
Vulnerabilities and attacks
The Interlock group has been heavily exploiting the CVE-2026-20131 zero-day vulnerability in Cisco Secure FMC firewall management software since at least January 26, 2026. The vulnerability enabled arbitrary Java code execution with root privileges on the affected device. This campaign demonstrates the ongoing reliance on zero-day vulnerabilities for initial access, a focus on network appliances as high-value entry points, and the rapid weaponization of new vulnerabilities within the ransomware ecosystem.
The most prolific groups
This section highlights the most prolific ransomware gangs by number of victims added to each groupβs DLS. This quarter, the Clop ransomware (14.42%) returned to the top of the rankings, displacingΒ Qilin (12.34%), which had held the leading position in the previous reporting period. Following closely is a new threat actor, The Gentlemen (9.25%). Emerging no later than July 2025, the group had already surpassed the activity levels of mainstays such as Akira (7.25%) and INC Ransom (6.13%).
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 Q1Β 2026, Kaspersky solutions detected six new ransomware families and 2938 new modifications. Volumes have returned to Q3Β 2025 levels following a surge in Q4Β 2025.
Number of new ransomware modifications, Q1 2025 β Q1 2026 (download)
Number of users attacked by ransomware Trojans
Throughout Q1, our solutions protected 77,319 unique users from ransomware. Ransomware activity was highest in March, with 35,056 unique users encountering such attacks during the month.
Number of unique users attacked by ransomware Trojans, Q1 2026 (download)
Attack geography
TOPΒ 10 countries and territories attacked by ransomware Trojans
Country/territory*
%**
1
Pakistan
0.79
2
South Korea
0.64
3
China
0.52
4
Tajikistan
0.40
5
Libya
0.38
6
Turkmenistan
0.36
7
Iraq
0.35
8
Bangladesh
0.33
9
Rwanda
0.30
10
Cameroon
0.28
* 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.
TOPΒ 10 most common families of ransomware Trojans
Name
Verdict
%*
1
(generic verdict)
Trojan-Ransom.Win32.Gen
33.90
2
(generic verdict)
Trojan-Ransom.Win32.Crypren
6.38
3
WannaCry
Trojan-Ransom.Win32.Wanna
5.87
4
(generic verdict)
Trojan-Ransom.Win32.Encoder
4.68
5
(generic verdict)
Trojan-Ransom.Win32.Agent
3.80
6
LockBit
Trojan-Ransom.Win32.Lockbit
2.80
7
(generic verdict)
Trojan-Ransom.Win32.Phny
1.99
8
(generic verdict)
Trojan-Ransom.MSIL.Agent
1.96
9
(generic verdict)
Trojan-Ransom.Python.Agent
1.93
10
(generic verdict)
Trojan-Ransom.Win32.Crypmod
1.89
* 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 Q1Β 2026, Kaspersky solutions detected 3485 new modifications of miners.
Number of new miner modifications, Q1 2026 (download)
Number of users attacked by miners
In Q1, we detected attacks using miner programs on the computers of 260,588 unique Kaspersky users worldwide.
Number of unique users attacked by miners, Q1 2026 (download)
Attack geography
TOPΒ 10 countries and territories attacked by miners
Country/territory*
%**
1
Senegal
3.19
2
Turkmenistan
3.06
3
Mali
2.63
4
Tanzania
1.62
5
Bangladesh
1.06
6
Ethiopia
0.95
7
Panama
0.88
8
Afghanistan
0.79
9
Kazakhstan
0.77
10
Bolivia
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 Q1Β 2026, Google uncovered a new cryptocurrency theft campaign. The scammers directed victims to a fraudulent video call, prompting them to execute malicious scripts under the guise of technical support fixes for connection problems.
In March, researchers with GTIG and iVerify reported the discovery of an in-the-wild exploit chain targeting both iOS and macOS devices. The exploit kit was apparently marketed on the dark web, providing threat actors with a suite of spyware capabilities alongside specialized cryptocurrency exfiltration modules. The exploit was delivered via drive-by downloads when victims visited various compromised websites. Our analysis confirmed that the toolkit included an updated version of a component previously identified in the Operation Triangulation attack chain.
Devices running macOS were similarly impacted by the high-profile supply chain attack targeting the Axios npm package, a widely used HTTP client for JavaScript. The installation of the infected package led to the deployment of a backdoor on macOS devices.
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 share of PasivRobber spyware attacks is beginning to decline, giving way to more traditional adware and Monitor-class software capable of tracking user activity. The popular Amos stealer also maintains its presence within the TOPΒ 20.
Geography of threats to macOS
TOPΒ 10 countries and territories by share of attacked users
Country/territory
%* Q4Β 2025
%* Q1Β 2026
China
1.28
1.97
France
1.18
1.07
Brazil
1.13
0.98
Mexico
0.72
0.52
Germany
0.71
0.45
The Netherlands
0.62
0.75
Hong Kong
0.49
0.53
India
0.42
0.48
Russian Federation
0.34
0.37
Thailand
0.24
0.27
* 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 Q1Β 2026, the share of devices attacking Kaspersky honeypots via the SSH protocol saw a significant increase compared to the previous reporting period.
Distribution of attacked services by number of unique IP addresses of attacking devices (download)
The distribution of attacks between Telnet and SSH maintained the ratio observed in Q4Β 2025.
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)
The primary shifts in the IoT threat distribution are linked to the activity of various Mirai botnet variants, although members of this family continue to account for the majority of the list. Furthermore, a new variant, Mirai.kl, surfaced in the rankings. We also observed a significant decline in NyaDrop botnet activity during Q1.
Attacks on IoT honeypots
The United States, the Netherlands, and Germany accounted for the highest proportions of SSH-based attacks during this period.
Country/territory
Q4Β 2025
Q1Β 2026
United States
16.10%
23.74%
The Netherlands
15.78%
17.57%
Germany
12.07%
10.34%
Panama
7.72%
6.34%
India
5.32%
6.05%
Romania
4.05%
5.82%
Australia
1.62%
4.61%
Vietnam
4.21%
3.50%
Russian Federation
3.79%
2.35%
Sweden
2.25%
2.09%
China continues to account for the largest proportion of Telnet attacks, though there was a marked increase in activity originating from Pakistan.
Country/territory
Q4Β 2025
Q1Β 2026
China
53.64%
39.54%
Pakistan
14.27%
27.31%
Russian Federation
8.20%
8.25%
Indonesia
8.58%
6.71%
India
4.85%
4.66%
Brazil
0.06%
3.30%
Argentina
0.02%
2.51%
Nigeria
1.22%
1.38%
Thailand
0.01%
0.55%
Sweden
0.54%
0.55%
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 and territories that served as sources of web-based attacks
The following statistics show the distribution by country/territory of the sources of internet attacks blocked by Kaspersky products on user computers (web pages redirecting to exploits, sites containing exploits and other malicious programs, botnet C&C centers, and so on). 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 Q1Β 2026, Kaspersky solutions blocked 343,823,407 attacks launched from internet resources worldwide. Web Anti-Virus was triggered by 49,983,611 unique URLs.
Web-based attacks by country/territory, Q1 2026 (download)
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
Venezuela
9.33
2
Hungary
8.16
3
Italy
7.58
4
Tajikistan
7.48
5
India
7.21
6
Greece
7.13
7
Portugal
7.10
8
France
7.05
9
Belgium
6.83
10
Slovakia
6.80
11
Vietnam
6.62
12
Bosnia and Herzegovina
6.57
13
Canada
6.56
14
Serbia
6.50
15
Tunisia
6.36
16
Qatar
6.01
17
Spain
5.95
18
Germany
5.95
19
Sri Lanka
5.89
20
Brazil
5.88
* 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 during the quarter, 4.73% of usersβ computers worldwide were subjected to at least one Malware web 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 and include detections of malicious programs located on user computers or removable media connected to the computers, such as flash drives, camera memory cards, phones, or external hard drives.
In Q1Β 2026, our File Anti-Virus detected 15,831,319 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 computers had the File Anti-Virus triggered 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
47.96
2
Tajikistan
31.48
3
Cuba
31.03
4
Yemen
29.59
5
Afghanistan
28.47
6
Burundi
26.93
7
Uzbekistan
24.81
8
Syria
23.08
9
Nicaragua
21.97
10
Cameroon
21.60
11
China
21.09
12
Mozambique
21.02
13
Algeria
20.64
14
Democratic Republic of the Congo
20.63
15
Bangladesh
20.44
16
Mali
20.35
17
Republic of the Congo
20.23
18
Madagascar
20.00
19
Belarus
19.78
20
Tanzania
19.52
* 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, Malware local threats were detected at least once on 11.55% of usersβ computers during Q1.
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.
Quarterly figures
In Q1Β 2026:
Kaspersky products blocked more than 343 million attacks that originated with various online resources.
Web Anti-Virus responded to 50 million unique links.
File Anti-Virus blocked nearly 15 million malicious and potentially unwanted objects.
2938 new ransomware variants were detected.
More than 77,000 users experienced ransomware attacks.
14% of all ransomware victims whose data was published on threat actorsβ data leak sites (DLS) were victims of Clop.
More than 260,000 users were targeted by miners.
Ransomware
Quarterly trends and highlights
Law enforcement success
In January 2026, it was reported that the FBI had seized the domains of the RAMP cybercrime forum, a major platform used extensively by ransomware developers to advertise their RaaS programs and to recruit affiliates. There has been no official statement from the FBI, nor is it clear if RAMP servers were seized. In a post on an external website, a RAMP moderator mentioned law enforcement agencies gaining control over the forum. The takedown disrupted a key element of the RaaS ecosystem, creating ripple effects for ransomware operators, affiliates, and initial access brokers.
A man suspected of links to the Phobos group was apprehended in Poland. He was charged with the creation, acquisition, and distribution of software designed for unlawfully obtaining information, including data that facilitates unauthorized access to information stored within a computer system.
In March, a Phobos ransomware administrator pleaded guilty to the creation and distribution of the Trojan, which had been used in international attacks dating back to at least November 2020.
In March, the U.S. Department of Justice charged a man who had acted as a negotiator for ransomware groups. The company he worked for specializes in cyberincident investigations. The prosecution alleges the suspect colluded with the BlackCat threat actor to share privileged insights into the ongoing progress of negotiations. Additionally, the suspect is alleged to have had a prior direct role in BlackCat attacks, serving as an affiliate for the RaaS operation.
In a separate development this March, a U.S. court sentenced an initial access broker associated with the Yanluowang ransomware group to 81 months of imprisonment. According to the U.S. Department of Justice, the convict facilitated dozens of ransomware attacks across the United States, resulting in over $9 million in actual loss and more than $24 million in intended loss.
Vulnerabilities and attacks
The Interlock group has been heavily exploiting the CVE-2026-20131 zero-day vulnerability in Cisco Secure FMC firewall management software since at least January 26, 2026. The vulnerability enabled arbitrary Java code execution with root privileges on the affected device. This campaign demonstrates the ongoing reliance on zero-day vulnerabilities for initial access, a focus on network appliances as high-value entry points, and the rapid weaponization of new vulnerabilities within the ransomware ecosystem.
The most prolific groups
This section highlights the most prolific ransomware gangs by number of victims added to each groupβs DLS. This quarter, the Clop ransomware (14.42%) returned to the top of the rankings, displacingΒ Qilin (12.34%), which had held the leading position in the previous reporting period. Following closely is a new threat actor, The Gentlemen (9.25%). Emerging no later than July 2025, the group had already surpassed the activity levels of mainstays such as Akira (7.25%) and INC Ransom (6.13%).
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 Q1Β 2026, Kaspersky solutions detected six new ransomware families and 2938 new modifications. Volumes have returned to Q3Β 2025 levels following a surge in Q4Β 2025.
Number of new ransomware modifications, Q1 2025 β Q1 2026 (download)
Number of users attacked by ransomware Trojans
Throughout Q1, our solutions protected 77,319 unique users from ransomware. Ransomware activity was highest in March, with 35,056 unique users encountering such attacks during the month.
Number of unique users attacked by ransomware Trojans, Q1 2026 (download)
Attack geography
TOPΒ 10 countries and territories attacked by ransomware Trojans
Country/territory*
%**
1
Pakistan
0.79
2
South Korea
0.64
3
China
0.52
4
Tajikistan
0.40
5
Libya
0.38
6
Turkmenistan
0.36
7
Iraq
0.35
8
Bangladesh
0.33
9
Rwanda
0.30
10
Cameroon
0.28
* 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.
TOPΒ 10 most common families of ransomware Trojans
Name
Verdict
%*
1
(generic verdict)
Trojan-Ransom.Win32.Gen
33.90
2
(generic verdict)
Trojan-Ransom.Win32.Crypren
6.38
3
WannaCry
Trojan-Ransom.Win32.Wanna
5.87
4
(generic verdict)
Trojan-Ransom.Win32.Encoder
4.68
5
(generic verdict)
Trojan-Ransom.Win32.Agent
3.80
6
LockBit
Trojan-Ransom.Win32.Lockbit
2.80
7
(generic verdict)
Trojan-Ransom.Win32.Phny
1.99
8
(generic verdict)
Trojan-Ransom.MSIL.Agent
1.96
9
(generic verdict)
Trojan-Ransom.Python.Agent
1.93
10
(generic verdict)
Trojan-Ransom.Win32.Crypmod
1.89
* 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 Q1Β 2026, Kaspersky solutions detected 3485 new modifications of miners.
Number of new miner modifications, Q1 2026 (download)
Number of users attacked by miners
In Q1, we detected attacks using miner programs on the computers of 260,588 unique Kaspersky users worldwide.
Number of unique users attacked by miners, Q1 2026 (download)
Attack geography
TOPΒ 10 countries and territories attacked by miners
Country/territory*
%**
1
Senegal
3.19
2
Turkmenistan
3.06
3
Mali
2.63
4
Tanzania
1.62
5
Bangladesh
1.06
6
Ethiopia
0.95
7
Panama
0.88
8
Afghanistan
0.79
9
Kazakhstan
0.77
10
Bolivia
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 Q1Β 2026, Google uncovered a new cryptocurrency theft campaign. The scammers directed victims to a fraudulent video call, prompting them to execute malicious scripts under the guise of technical support fixes for connection problems.
In March, researchers with GTIG and iVerify reported the discovery of an in-the-wild exploit chain targeting both iOS and macOS devices. The exploit kit was apparently marketed on the dark web, providing threat actors with a suite of spyware capabilities alongside specialized cryptocurrency exfiltration modules. The exploit was delivered via drive-by downloads when victims visited various compromised websites. Our analysis confirmed that the toolkit included an updated version of a component previously identified in the Operation Triangulation attack chain.
Devices running macOS were similarly impacted by the high-profile supply chain attack targeting the Axios npm package, a widely used HTTP client for JavaScript. The installation of the infected package led to the deployment of a backdoor on macOS devices.
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 share of PasivRobber spyware attacks is beginning to decline, giving way to more traditional adware and Monitor-class software capable of tracking user activity. The popular Amos stealer also maintains its presence within the TOPΒ 20.
Geography of threats to macOS
TOPΒ 10 countries and territories by share of attacked users
Country/territory
%* Q4Β 2025
%* Q1Β 2026
China
1.28
1.97
France
1.18
1.07
Brazil
1.13
0.98
Mexico
0.72
0.52
Germany
0.71
0.45
The Netherlands
0.62
0.75
Hong Kong
0.49
0.53
India
0.42
0.48
Russian Federation
0.34
0.37
Thailand
0.24
0.27
* 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 Q1Β 2026, the share of devices attacking Kaspersky honeypots via the SSH protocol saw a significant increase compared to the previous reporting period.
Distribution of attacked services by number of unique IP addresses of attacking devices (download)
The distribution of attacks between Telnet and SSH maintained the ratio observed in Q4Β 2025.
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)
The primary shifts in the IoT threat distribution are linked to the activity of various Mirai botnet variants, although members of this family continue to account for the majority of the list. Furthermore, a new variant, Mirai.kl, surfaced in the rankings. We also observed a significant decline in NyaDrop botnet activity during Q1.
Attacks on IoT honeypots
The United States, the Netherlands, and Germany accounted for the highest proportions of SSH-based attacks during this period.
Country/territory
Q4Β 2025
Q1Β 2026
United States
16.10%
23.74%
The Netherlands
15.78%
17.57%
Germany
12.07%
10.34%
Panama
7.72%
6.34%
India
5.32%
6.05%
Romania
4.05%
5.82%
Australia
1.62%
4.61%
Vietnam
4.21%
3.50%
Russian Federation
3.79%
2.35%
Sweden
2.25%
2.09%
China continues to account for the largest proportion of Telnet attacks, though there was a marked increase in activity originating from Pakistan.
Country/territory
Q4Β 2025
Q1Β 2026
China
53.64%
39.54%
Pakistan
14.27%
27.31%
Russian Federation
8.20%
8.25%
Indonesia
8.58%
6.71%
India
4.85%
4.66%
Brazil
0.06%
3.30%
Argentina
0.02%
2.51%
Nigeria
1.22%
1.38%
Thailand
0.01%
0.55%
Sweden
0.54%
0.55%
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 and territories that served as sources of web-based attacks
The following statistics show the distribution by country/territory of the sources of internet attacks blocked by Kaspersky products on user computers (web pages redirecting to exploits, sites containing exploits and other malicious programs, botnet C&C centers, and so on). 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 Q1Β 2026, Kaspersky solutions blocked 343,823,407 attacks launched from internet resources worldwide. Web Anti-Virus was triggered by 49,983,611 unique URLs.
Web-based attacks by country/territory, Q1 2026 (download)
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
Venezuela
9.33
2
Hungary
8.16
3
Italy
7.58
4
Tajikistan
7.48
5
India
7.21
6
Greece
7.13
7
Portugal
7.10
8
France
7.05
9
Belgium
6.83
10
Slovakia
6.80
11
Vietnam
6.62
12
Bosnia and Herzegovina
6.57
13
Canada
6.56
14
Serbia
6.50
15
Tunisia
6.36
16
Qatar
6.01
17
Spain
5.95
18
Germany
5.95
19
Sri Lanka
5.89
20
Brazil
5.88
* 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 during the quarter, 4.73% of usersβ computers worldwide were subjected to at least one Malware web 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 and include detections of malicious programs located on user computers or removable media connected to the computers, such as flash drives, camera memory cards, phones, or external hard drives.
In Q1Β 2026, our File Anti-Virus detected 15,831,319 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 computers had the File Anti-Virus triggered 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
47.96
2
Tajikistan
31.48
3
Cuba
31.03
4
Yemen
29.59
5
Afghanistan
28.47
6
Burundi
26.93
7
Uzbekistan
24.81
8
Syria
23.08
9
Nicaragua
21.97
10
Cameroon
21.60
11
China
21.09
12
Mozambique
21.02
13
Algeria
20.64
14
Democratic Republic of the Congo
20.63
15
Bangladesh
20.44
16
Mali
20.35
17
Republic of the Congo
20.23
18
Madagascar
20.00
19
Belarus
19.78
20
Tanzania
19.52
* 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, Malware local threats were detected at least once on 11.55% of usersβ computers during Q1.
Stan Ghouls (also known as Bloody Wolf) is an cybercriminal group that has been launching targeted attacks against organizations in Russia, Kyrgyzstan, Kazakhstan, and Uzbekistan since at least 2023. These attackers primarily have their sights set on the manufacturing, finance, and IT sectors. Their campaigns are meticulously prepared and tailored to specific victims, featuring a signature toolkit of custom Java-based malware loaders and a sprawling infrastructure with resources dedicated to specific campaigns.
We continuously track Stan Ghoulsβ activity, providing our clients with intel on their tactics, techniques, procedures, and latest campaigns. In this post, we share the results of our most recent deep dive into a campaign targeting Uzbekistan, where we identified roughly 50 victims. About 10Β devices in Russia were also hit, with a handful of others scattered across Kazakhstan, Turkey, Serbia, and Belarus (though those last three were likely just collateral damage).
During our investigation, we spotted shifts in the attackersβ infrastructure β specifically, a batch of new domains. We also uncovered evidence suggesting that Stan Ghouls may have added IoT-focused malware to their arsenal.
Technical details
Threat evolution
Stan Ghouls relies on phishing emails packed with malicious PDF attachments as their initial entry point. Historically, the groupβs weapon of choice was the remote access Trojan (RAT) STRRAT, also known as Strigoi Master. Last year, however, they switched strategies, opting to misuse legitimate software, NetSupport, to maintain control over infected machines.
Given Stan Ghoulsβ targeting of financial institutions, we believe their primary motive is financial gain. That said, their heavy use of RATs may also hint at cyberespionage.
Like any other organized cybercrime groups, Stan Ghouls frequently refreshes its infrastructure. To track their campaigns effectively, you have to continuously analyze their activity.
Initial infection vector
As weβve mentioned, Stan Ghoulsβ primary β and currently only β delivery method is spear phishing. Specifically, they favor emails loaded with malicious PDF attachments. This has been backed up by research from several of our industry peers (1, 2, 3). Interestingly, the attackers prefer to use local languages rather than opting for international mainstays like Russian or English. Below is an example of an email spotted in a previous campaign targeting users in Kyrgyzstan.
Example of a phishing email from a previous Stan Ghouls campaign
The email is written in Kyrgyz and translates to: βThe service has contacted you. Materials for review are attached. Sincerelyβ.
The attachment was a malicious PDF file titled βΠΠΎΡΡΠ°Π½ΠΎΠ²Π»Π΅Π½ΠΈΠ΅_Π Π°ΠΉΠΎΠ½Π½ΡΠΉ_ΡΡΠ΄_ΠΡΡΠΌ_3566_28-01-25_OL4_scan.pdfβ (the title, written in Russian, posed it as an order of district court).
During the most recent campaign, which primarily targeted victims in Uzbekistan, the attackers deployed spear-phishing emails written in Uzbek:
Example of a spear-phishing email from the latest campaign
The email text can be translated as follows:
[redacted] AKMALZHON IBROHIMOVICH
You will receive a court notice. Application for retrial. The case is under review by the district court. Judicial Service.
Mustaqillik Street, 147 Uraboshi Village, Quva District.
The attachment, named E-SUD_705306256_ljro_varaqasi.pdf (MD5: 7556e2f5a8f7d7531f28508f718cb83d), is a standard one-page decoy PDF:
The embedded decoy document
Notice that the attackers claim that the βcase materialsβ (which are actually the malicious loader) can only be opened using the Java Runtime Environment.
They even helpfully provide a link for the victim to download and install it from the official website.
The malicious loader
The decoy document contains identical text in both Russian and Uzbek, featuring two links that point to the malicious loader:
Uzbek link (β- Ish materiallari 09.12.2025 yβ): hxxps://mysoliq-uz[.]com/api/v2/documents/financial/Q4-2025/audited/consolidated/with-notes/financials/reports/annual/2025/tashkent/statistical-statements/
Russian link (β- ΠΠ°ΡΠ΅ΡΠΈΠ°Π»Ρ Π΄Π΅Π»Π° 09.12.2025 Π³.β): hxxps://my-xb[.]com/api/v2/documents/financial/Q4-2025/audited/consolidated/with-notes/financials/reports/annual/2025/tashkent/statistical-statements/
Both links lead to the exact same JAR file (MD5: 95db93454ec1d581311c832122d21b20).
Itβs worth noting that these attackers are constantly updating their infrastructure, registering new domains for every new campaign. In the relatively short history of this threat, weβve already mapped out over 35 domains tied to Stan Ghouls.
The malicious loader handles three main tasks:
Displaying a fake error message to trick the user into thinking the application canβt run. The message in the screenshot translates to: βThis application cannot be run in your OS. Please use another device.β
Fake error message
Checking that the number of previous RAT installation attempts is less than three. If the limit is reached, the loader terminates and throws the following error: βUrinishlar chegarasidan oshildi. Boshqa kompyuterni tekshiring.β This translates to: βAttempt limit reached. Try another computer.β
The limitCheck procedure for verifying the number of RAT download attempts
Downloading a remote management utility from a malicious domain and saving it to the victimβs machine. Stan Ghouls loaders typically contain a list of several domains and will iterate through them until they find one thatβs live.
The performanceResourceUpdate procedure for downloading the remote management utility
The loader fetches the following files, which make up the components of the NetSupport RAT: PCICHEK.DLL, client32.exe, advpack.dll, msvcr100.dll, remcmdstub.exe, ir50_qcx.dll, client32.ini, AudioCapture.dll, kbdlk41a.dll, KBDSF.DLL, tcctl32.dll, HTCTL32.DLL, kbdibm02.DLL, kbd101c.DLL, kbd106n.dll, ir50_32.dll, nskbfltr.inf, NSM.lic, pcicapi.dll, PCICL32.dll, qwave.dll. This list is hardcoded in the malicious loaderβs body. To ensure the download was successful, it checks for the presence of the client32.exe executable. If the file is found, the loader generates a NetSupport launch script (run.bat), drops it into the folder with the other files, and executes it:
The createBatAndRun procedure for creating and executing the run.bat file, which then launches the NetSupport RAT
The loader also ensures NetSupport persistence by adding it to startup using the following three methods:
It creates an autorun script named SoliqUZ_Run.bat and drops it into the Startup folder (%APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup):
The generateAutorunScript procedure for creating the batch file and placing it in the Startup folder
It adds the run.bat file to the registryβs autorun key (HKCU\Software\Microsoft\Windows\CurrentVersion\Run\malicious_key_name).
The registryStartupAdd procedure for adding the RAT launch script to the registry autorun key
It creates a scheduled task to trigger run.bat using the following command: schtasks Create /TN "[malicious_task_name]" /TR "[path_to_run.bat]" /SC ONLOGON /RL LIMITED /F /RU "[%USERNAME%]"
The installStartupTask procedure for creating a scheduled task to launch the NetSupport RAT (via run.bat)
Once the NetSupport RAT is downloaded, installed, and executed, the attackers gain total control over the victimβs machine. While we donβt have enough telemetry to say with 100% certainty what they do once theyβre in, the heavy focus on finance-related organizations suggests that the group is primarily after its victimsβ money. That said, we canβt rule out cyberespionage either.
Malicious utilities for targeting IoT infrastructure
Previous Stan Ghouls attacks targeting organizations in Kyrgyzstan, as documented by Group-IB researchers, featured a NetSupport RAT configuration file client32.ini with the MD5 hash cb9c28a4c6657ae5ea810020cb214ff0. While reports mention the Kyrgyzstan campaign kicked off in June 2025, Kaspersky solutions first flagged this exact config file on May 16, 2025. At that time, it contained the following NetSupport RAT command-and-control server info:
At the time of our January 2026 investigation, our telemetry showed that the domain specified in that config, hgame33[.]com, was also hosting the following files:
All of these files belong to the infamous IoT malware named Mirai. Since they are sitting on a server tied to the Stan Ghoulsβ campaign targeting Kyrgyzstan, we can hypothesize β with a low degree of confidence β that the group has expanded its toolkit to include IoT-based threats. However, itβs also possible it simply shared its infrastructure with other threat actors who were the ones actually wielding Mirai. This theory is backed up by the fact that the domainβs registration info was last updated on July 4, 2025, at 11:46:11 β well after Stan Ghoulsβ activity in May and June.
Attribution
We attribute this campaign to the Stan Ghouls (Bloody Wolf) group with a high degree of confidence, based on the following similarities to the attackersβ previous campaigns:
Substantial code overlaps were found within the malicious loaders. For example:
Code snippet from sample 1acd4592a4eb0c66642cc7b07213e9c9584c6140210779fbc9ebb76a90738d5e, the loader from the Group-IB report
Code snippet from sample 95db93454ec1d581311c832122d21b20, the NetSupport loader described here
Decoy documents in both campaigns look identical.
Decoy document 5d840b741d1061d51d9786f8009c37038c395c129bee608616740141f3b202bb from the campaign reported by Group-IB
Decoy document 106911ba54f7e5e609c702504e69c89a used in the campaign described here
In both current and past campaigns, the attackers utilized loaders written in Java. Given that Java has fallen out of fashion with malicious loader authors in recent years, it serves as a distinct fingerprint for Stan Ghouls.
Victims
We identified approximately 50Β victims of this campaign in Uzbekistan, alongside 10 in Russia and a handful of others in Kazakhstan, Turkey, Serbia, and Belarus (we suspect the infections in these last three countries were accidental). Nearly all phishing emails and decoy files in this campaign were written in Uzbek, which aligns with the groupβs track record of leveraging the native languages of their target countries.
Most of the victims are tied to industrial manufacturing, finance, and IT. Furthermore, we observed infection attempts on devices within government organizations, logistics companies, medical facilities, and educational institutions.
It is worth noting that over 60Β victims is quite a high headcount for a sophisticated campaign. This suggests the attackers have enough resources to maintain manual remote control over dozens of infected devices simultaneously.
Takeaways
In this post, weβve broken down the recent campaign by the Stan Ghouls group. The attackers set their sights on organizations in industrial manufacturing, IT, and finance, primarily located in Uzbekistan. However, the ripple effect also reached Russia, Kazakhstan, and a few, likely accidental, victims elsewhere.
With over 60Β targets hit, this is a remarkably high volume for a sophisticated targeted campaign. It points to the significant resources these actors are willing to pour into their operations. Interestingly, despite this, the group sticks to a familiar toolkit including the legitimate NetSupport remote management utility and their signature custom Java-based loader. The only thing they seem to keep updating is their infrastructure. For this specific campaign, they employed two new domains to house their malicious loader and one new domain dedicated to hosting NetSupport RAT files.
One curious discovery was the presence of Mirai files on a domain linked to the groupβs previous campaigns. This might suggest Stan Ghouls are branching out into IoT malware, though itβs still too early to call it with total certainty.
Weβre keeping a close watch on Stan Ghouls and will continue to keep our customers in the loop regarding the groupβs latest moves. Kaspersky products provide robust protection against this threat at every stage of the attack lifecycle.
Stan Ghouls (also known as Bloody Wolf) is an cybercriminal group that has been launching targeted attacks against organizations in Russia, Kyrgyzstan, Kazakhstan, and Uzbekistan since at least 2023. These attackers primarily have their sights set on the manufacturing, finance, and IT sectors. Their campaigns are meticulously prepared and tailored to specific victims, featuring a signature toolkit of custom Java-based malware loaders and a sprawling infrastructure with resources dedicated to specific campaigns.
We continuously track Stan Ghoulsβ activity, providing our clients with intel on their tactics, techniques, procedures, and latest campaigns. In this post, we share the results of our most recent deep dive into a campaign targeting Uzbekistan, where we identified roughly 50 victims. About 10Β devices in Russia were also hit, with a handful of others scattered across Kazakhstan, Turkey, Serbia, and Belarus (though those last three were likely just collateral damage).
During our investigation, we spotted shifts in the attackersβ infrastructure β specifically, a batch of new domains. We also uncovered evidence suggesting that Stan Ghouls may have added IoT-focused malware to their arsenal.
Technical details
Threat evolution
Stan Ghouls relies on phishing emails packed with malicious PDF attachments as their initial entry point. Historically, the groupβs weapon of choice was the remote access Trojan (RAT) STRRAT, also known as Strigoi Master. Last year, however, they switched strategies, opting to misuse legitimate software, NetSupport, to maintain control over infected machines.
Given Stan Ghoulsβ targeting of financial institutions, we believe their primary motive is financial gain. That said, their heavy use of RATs may also hint at cyberespionage.
Like any other organized cybercrime groups, Stan Ghouls frequently refreshes its infrastructure. To track their campaigns effectively, you have to continuously analyze their activity.
Initial infection vector
As weβve mentioned, Stan Ghoulsβ primary β and currently only β delivery method is spear phishing. Specifically, they favor emails loaded with malicious PDF attachments. This has been backed up by research from several of our industry peers (1, 2, 3). Interestingly, the attackers prefer to use local languages rather than opting for international mainstays like Russian or English. Below is an example of an email spotted in a previous campaign targeting users in Kyrgyzstan.
Example of a phishing email from a previous Stan Ghouls campaign
The email is written in Kyrgyz and translates to: βThe service has contacted you. Materials for review are attached. Sincerelyβ.
The attachment was a malicious PDF file titled βΠΠΎΡΡΠ°Π½ΠΎΠ²Π»Π΅Π½ΠΈΠ΅_Π Π°ΠΉΠΎΠ½Π½ΡΠΉ_ΡΡΠ΄_ΠΡΡΠΌ_3566_28-01-25_OL4_scan.pdfβ (the title, written in Russian, posed it as an order of district court).
During the most recent campaign, which primarily targeted victims in Uzbekistan, the attackers deployed spear-phishing emails written in Uzbek:
Example of a spear-phishing email from the latest campaign
The email text can be translated as follows:
[redacted] AKMALZHON IBROHIMOVICH
You will receive a court notice. Application for retrial. The case is under review by the district court. Judicial Service.
Mustaqillik Street, 147 Uraboshi Village, Quva District.
The attachment, named E-SUD_705306256_ljro_varaqasi.pdf (MD5: 7556e2f5a8f7d7531f28508f718cb83d), is a standard one-page decoy PDF:
The embedded decoy document
Notice that the attackers claim that the βcase materialsβ (which are actually the malicious loader) can only be opened using the Java Runtime Environment.
They even helpfully provide a link for the victim to download and install it from the official website.
The malicious loader
The decoy document contains identical text in both Russian and Uzbek, featuring two links that point to the malicious loader:
Uzbek link (β- Ish materiallari 09.12.2025 yβ): hxxps://mysoliq-uz[.]com/api/v2/documents/financial/Q4-2025/audited/consolidated/with-notes/financials/reports/annual/2025/tashkent/statistical-statements/
Russian link (β- ΠΠ°ΡΠ΅ΡΠΈΠ°Π»Ρ Π΄Π΅Π»Π° 09.12.2025 Π³.β): hxxps://my-xb[.]com/api/v2/documents/financial/Q4-2025/audited/consolidated/with-notes/financials/reports/annual/2025/tashkent/statistical-statements/
Both links lead to the exact same JAR file (MD5: 95db93454ec1d581311c832122d21b20).
Itβs worth noting that these attackers are constantly updating their infrastructure, registering new domains for every new campaign. In the relatively short history of this threat, weβve already mapped out over 35 domains tied to Stan Ghouls.
The malicious loader handles three main tasks:
Displaying a fake error message to trick the user into thinking the application canβt run. The message in the screenshot translates to: βThis application cannot be run in your OS. Please use another device.β
Fake error message
Checking that the number of previous RAT installation attempts is less than three. If the limit is reached, the loader terminates and throws the following error: βUrinishlar chegarasidan oshildi. Boshqa kompyuterni tekshiring.β This translates to: βAttempt limit reached. Try another computer.β
The limitCheck procedure for verifying the number of RAT download attempts
Downloading a remote management utility from a malicious domain and saving it to the victimβs machine. Stan Ghouls loaders typically contain a list of several domains and will iterate through them until they find one thatβs live.
The performanceResourceUpdate procedure for downloading the remote management utility
The loader fetches the following files, which make up the components of the NetSupport RAT: PCICHEK.DLL, client32.exe, advpack.dll, msvcr100.dll, remcmdstub.exe, ir50_qcx.dll, client32.ini, AudioCapture.dll, kbdlk41a.dll, KBDSF.DLL, tcctl32.dll, HTCTL32.DLL, kbdibm02.DLL, kbd101c.DLL, kbd106n.dll, ir50_32.dll, nskbfltr.inf, NSM.lic, pcicapi.dll, PCICL32.dll, qwave.dll. This list is hardcoded in the malicious loaderβs body. To ensure the download was successful, it checks for the presence of the client32.exe executable. If the file is found, the loader generates a NetSupport launch script (run.bat), drops it into the folder with the other files, and executes it:
The createBatAndRun procedure for creating and executing the run.bat file, which then launches the NetSupport RAT
The loader also ensures NetSupport persistence by adding it to startup using the following three methods:
It creates an autorun script named SoliqUZ_Run.bat and drops it into the Startup folder (%APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup):
The generateAutorunScript procedure for creating the batch file and placing it in the Startup folder
It adds the run.bat file to the registryβs autorun key (HKCU\Software\Microsoft\Windows\CurrentVersion\Run\malicious_key_name).
The registryStartupAdd procedure for adding the RAT launch script to the registry autorun key
It creates a scheduled task to trigger run.bat using the following command: schtasks Create /TN "[malicious_task_name]" /TR "[path_to_run.bat]" /SC ONLOGON /RL LIMITED /F /RU "[%USERNAME%]"
The installStartupTask procedure for creating a scheduled task to launch the NetSupport RAT (via run.bat)
Once the NetSupport RAT is downloaded, installed, and executed, the attackers gain total control over the victimβs machine. While we donβt have enough telemetry to say with 100% certainty what they do once theyβre in, the heavy focus on finance-related organizations suggests that the group is primarily after its victimsβ money. That said, we canβt rule out cyberespionage either.
Malicious utilities for targeting IoT infrastructure
Previous Stan Ghouls attacks targeting organizations in Kyrgyzstan, as documented by Group-IB researchers, featured a NetSupport RAT configuration file client32.ini with the MD5 hash cb9c28a4c6657ae5ea810020cb214ff0. While reports mention the Kyrgyzstan campaign kicked off in June 2025, Kaspersky solutions first flagged this exact config file on May 16, 2025. At that time, it contained the following NetSupport RAT command-and-control server info:
At the time of our January 2026 investigation, our telemetry showed that the domain specified in that config, hgame33[.]com, was also hosting the following files:
All of these files belong to the infamous IoT malware named Mirai. Since they are sitting on a server tied to the Stan Ghoulsβ campaign targeting Kyrgyzstan, we can hypothesize β with a low degree of confidence β that the group has expanded its toolkit to include IoT-based threats. However, itβs also possible it simply shared its infrastructure with other threat actors who were the ones actually wielding Mirai. This theory is backed up by the fact that the domainβs registration info was last updated on July 4, 2025, at 11:46:11 β well after Stan Ghoulsβ activity in May and June.
Attribution
We attribute this campaign to the Stan Ghouls (Bloody Wolf) group with a high degree of confidence, based on the following similarities to the attackersβ previous campaigns:
Substantial code overlaps were found within the malicious loaders. For example:
Code snippet from sample 1acd4592a4eb0c66642cc7b07213e9c9584c6140210779fbc9ebb76a90738d5e, the loader from the Group-IB report
Code snippet from sample 95db93454ec1d581311c832122d21b20, the NetSupport loader described here
Decoy documents in both campaigns look identical.
Decoy document 5d840b741d1061d51d9786f8009c37038c395c129bee608616740141f3b202bb from the campaign reported by Group-IB
Decoy document 106911ba54f7e5e609c702504e69c89a used in the campaign described here
In both current and past campaigns, the attackers utilized loaders written in Java. Given that Java has fallen out of fashion with malicious loader authors in recent years, it serves as a distinct fingerprint for Stan Ghouls.
Victims
We identified approximately 50Β victims of this campaign in Uzbekistan, alongside 10 in Russia and a handful of others in Kazakhstan, Turkey, Serbia, and Belarus (we suspect the infections in these last three countries were accidental). Nearly all phishing emails and decoy files in this campaign were written in Uzbek, which aligns with the groupβs track record of leveraging the native languages of their target countries.
Most of the victims are tied to industrial manufacturing, finance, and IT. Furthermore, we observed infection attempts on devices within government organizations, logistics companies, medical facilities, and educational institutions.
It is worth noting that over 60Β victims is quite a high headcount for a sophisticated campaign. This suggests the attackers have enough resources to maintain manual remote control over dozens of infected devices simultaneously.
Takeaways
In this post, weβve broken down the recent campaign by the Stan Ghouls group. The attackers set their sights on organizations in industrial manufacturing, IT, and finance, primarily located in Uzbekistan. However, the ripple effect also reached Russia, Kazakhstan, and a few, likely accidental, victims elsewhere.
With over 60Β targets hit, this is a remarkably high volume for a sophisticated targeted campaign. It points to the significant resources these actors are willing to pour into their operations. Interestingly, despite this, the group sticks to a familiar toolkit including the legitimate NetSupport remote management utility and their signature custom Java-based loader. The only thing they seem to keep updating is their infrastructure. For this specific campaign, they employed two new domains to house their malicious loader and one new domain dedicated to hosting NetSupport RAT files.
One curious discovery was the presence of Mirai files on a domain linked to the groupβs previous campaigns. This might suggest Stan Ghouls are branching out into IoT malware, though itβs still too early to call it with total certainty.
Weβre keeping a close watch on Stan Ghouls and will continue to keep our customers in the loop regarding the groupβs latest moves. Kaspersky products provide robust protection against this threat at every stage of the attack lifecycle.
Researchers have demonstrated remotely controlling a wheelchair over Bluetooth. CISA has issued an advisory.
CISA said the WHILL wheelchairs did not enforce authentication for Bluetooth connections, allowing an attacker who is in Bluetooth range of the targeted device to pair with it. The attacker could then control the wheelchairβs movements, override speed restrictions, and manipulate configuration profiles, all without requiring credentials or user interaction.
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.
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.
David Fletcher// My wife and I recently purchased a 2016 Ford Flex to replace an aging version of the same make and model that met an untimely fate. During the [β¦]
Login
