What happened An internet-connected coffee machine reportedly led to a significant corporate data breach after attackers used the device as an entry point into a secure network. A digital forensics investigator identified only as TR examined the incident after a client suspected a rival had infiltrated its systems. Instead of finding malware, the investigator found […]

The post Internet-Connected Coffee Machine Reportedly Led to Corporate Data Breach appeared first on CISO Whisperer.

The post Internet-Connected Coffee Machine Reportedly Led to Corporate Data Breach appeared first on Security Boulevard.

TP-Link patched a high severity flaw (CVE-2025-15517) in Archer NX routers that could let attackers bypass authentication and install malicious firmware.

TP-Link issued security updates for its Archer NX router series to fix multiple vulnerabilities, including CVE-2025-15517 (CVSS score of 8.6), a critical authentication bypass flaw. The vulnerability impacts multiple models, including NX200, NX210, NX500, and NX600. The flaw allows attackers to upload new firmware without privileges, creating a high risk of compromise if unpatched.

“A missing authentication check in the HTTP server to certain cgi endpoints allows unauthenticated access intended for authenticated users.” reads the advisory. “An attacker may perform privileged HTTP actions without authentication, including firmware upload and configuration operations.”

TP-Link also removed a hardcoded cryptographic key in Configuration Encryption Mechanism, tracked as CVE-2025-15605 (CVSS score of 8.5). The vulnerability allowed authenticated attackers to decrypt configuration files, modify them, and re-encrypt them.

“A hardcoded cryptographic key within its configuration mechanism enables decryption and re-encryption of device configuration data.” reads the advisory. “An authenticated attacker may decrypt configuration files, modify them and re-encrypt them, affecting confidentiality and integrity of device configuration data.”

Below is the list of impacted products/versions and related fixes:

The vendor urges customers to download and install the latest firmware version to address these issues.

In September 2025, the U.S. Cybersecurity and Infrastructure Security Agency (CISA) added TP-Link Archer C7(EU) and TL-WR841N flaws to its Known Exploited Vulnerabilities (KEV) catalog.

Below are the descriptions for these flaws:

• CVE-2025-9377 (CVSS score of 8.6) TP-Link Archer C7(EU) and TL-WR841N/ND(MS) OS Command Injection Vulnerability
• CVE-2023-50224 (CVSS score of 6.5) TP-Link TL-WR841N Authentication Bypass by Spoofing Vulnerability

This week, the U.S. FCC announced a ban on importing new foreign-made consumer routers, citing unacceptable cyber and national security risks. The decision, backed by Executive Branch assessments, means such devices can no longer be sold or marketed in the U.S. unless they receive special approval.

Routers will be added to the Covered List, with exceptions only for those cleared by the Department of Homeland Security or defense authorities after the Department of Homeland Security or defense authorities verify they pose no threat to communications networks.

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, Archer NX)

QNAP fixed four vulnerabilities shown at Pwn2Own 2025 that could enable code execution, data access, or system disruption.

Taiwanese vendor QNAP has addressed multiple vulnerabilities, including four SD-WAN router issues (CVE-2025-62843 to CVE-2025-62846) demonstrated at the Pwn2Own Ireland 2025 by Team DDOS. The team chained multiple bugs in QNAP devices to gain root access and earned a $100,000 reward.

The flaws could allow attackers to access sensitive data, execute code, or disrupt system operations if left unpatched.

The manufacturer addressed the four vulnerabilities in QuRouter version 2.6.3.009.

The vulnerabilities identified in QHora devices highlight how different levels of access can translate into significant security risks for an organization’s infrastructure. Below are the descriptions of the flaws:

CVE-2025-62843 involves an issue with communication channel restrictions. If an attacker gains physical access to the device, they can exploit this flaw to obtain privileges intended for other endpoints, effectively bypassing existing controls.

CVE-2025-62844 affects the local network level. In this case, an attacker with LAN access can take advantage of weak authentication mechanisms to retrieve sensitive information, exposing data that should remain protected.

More critical is CVE-2025-62846, which comes into play when an attacker gains administrative credentials. By exploiting an SQL injection vulnerability, they can execute unauthorized commands, compromising the integrity and control of the system.

Finally, CVE-2025-62845 relates to improper handling of escape and control sequences. An attacker with elevated privileges can trigger unexpected system behavior, potentially impacting stability and security.

Overall, these vulnerabilities show how a combination of physical access, network exposure, and elevated privileges can amplify risk, making timely patching and strong security practices essential.

In November 2025, the Taiwanese vendor patched seven zero-day vulnerabilities exploited at Pwn2Own Ireland 2025. The flaws affected QTS, QuTS hero, Hyper Data Protector, Malware Remover, and HBS 3 Hybrid Backup Sync.

The vulnerabilities addressed by the company were:

• CVE-2025-62847 – CVE-2025-62848 – CVE-2025-62849 in QNAP’s QTS and QuTS hero operating systems;
• CVE-2025-11837 in Malware Remover;
• CVE-2025-59389 in Hyper Data Protector;
• CVE-2025-62840 – CVE-2025-62842 in HBS 3 Hybrid Backup Sync software.

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, QNAP)

Someone tries to remote control his own DJI Romo vacuum, and ends up controlling 7,000 of them from all around the world.

The IoT is horribly insecure, but we already knew that.

Researchers observed Iran-linked actors targeting IP cameras across Israel and Gulf countries, likely to support military intelligence and battle damage assessment.

According to the Check Point Cyber Security Report 2026, cyber operations are increasingly used to support military activity and battle damage assessment (BDA). During the Israel-Iran tensions, researchers from Check Point Software Technologies observed a surge in attacks targeting IP cameras across Israel and Gulf countries, including the UAE, Qatar, Bahrain, and Kuwait, as well as Lebanon and Cyprus. The activity, attributed to Iran-linked actors, relied on VPN and VPS infrastructure to scan devices, mainly Hikvision and Dahua Technology cameras, for known vulnerabilities.

“During the ongoing conflict, we identified intensified targeting of IP cameras from two manufacturers starting on February 28, originating from infrastructure we attribute to Iranian threat actors.

The targeting extends across Israel, Qatar, Bahrain, Kuwait, the UAE, and Cyprus – countries that have also experienced significant missile activity linked to Iran. On March 1st, we additionally observed camera-targeting activity focused on specific areas in Lebanon.” states Check Point Software Technologies.”

“We also observed earlier, more targeted activity against cameras in Israel and Qatar on January 14–15. These dates surround with Iran’s temporary closure of its airspace, reportedly amid expectations of a potential U.S. strike.”

Researchers believe the goal was reconnaissance and real-time monitoring to support intelligence gathering and potential military targeting.

Threat actors targeted the following vulnerabilities in Hikvision and Dahua devices:

The experts state that Chinese manufacturers have patched all the above issues.

Researchers analyzed exploitation attempts for CVE-2021-33044 and CVE-2017-7921 linked to infrastructure attributed to Iran.

In October 2021, experts warned that proof-of-concept (PoC) exploit code was available for two authentication-bypass vulnerabilities in Dahua cameras, tracked as CVE-2021-33044 and CVE-2021-33045. A remote attacker can exploit both vulnerabilities by sending specially crafted data packets to the vulnerable cameras.

Since early 2026, scanning activity targeting IP cameras has surged across Israel and several Middle East countries, often aligning with geopolitical tensions such as protests in Iran, U.S. military visits to Israel, and fears of potential strikes.

Similar patterns appeared during the June 2025 Israel-Iran conflict, when compromised cameras were likely used for reconnaissance and battle damage assessment, including a case involving a camera near Israel’s Weizmann Institute before a missile strike.

“One of the best-known cases occurred when Iran struck Israel’s Weizmann Institute of Science with a ballistic missile and had reportedly taken control of a street camera facing the building just prior to the hit” concludes the report.

Defenders should reduce risks by removing public internet access to cameras and placing them behind VPN or zero-trust gateways. Organizations should change default passwords, enforce strong unique credentials, and keep device firmware updated. Cameras should run on isolated network segments with restricted outbound traffic. Security teams should also monitor for repeated login failures, suspicious remote access, and unusual outbound connections.

This week, the U.S. Cybersecurity and Infrastructure Security Agency (CISA) added Hikvision multiple products improper authentication vulnerability CVE-2017-7921 (CVSS score of 9.8) to its Known Exploited Vulnerabilities (KEV) catalog.

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, Iran, IP cameras)

CISA warns Honeywell CCTVs are affected by a critical auth bypass flaw (CVE-2026-1670) allowing unauthorized access or account hijacking.

The U.S. Cybersecurity and Infrastructure Security Agency (CISA) warns that Honeywell CCTVs are affected by a critical authentication bypass flaw, tracked as CVE-2026-1670 (CVSS score of 9.8), that lets attackers change the recovery email without logging in. This vulnerability enables account takeovers and unauthorized access to camera feeds by exploiting an unauthenticated API endpoint for password recovery.

“Successful exploitation of this vulnerability could lead to account takeovers and unauthorized access to camera feeds; an unauthenticated attacker may change the recovery email address, potentially leading to further network compromise.” reads the alert published by CISA.

The vulnerability was discovered by cybersecurity researcher Souvik Kandar.

The vulnerability impacts the following Honeywell CCTVs models:

• I-HIB2PI-UL 2MP IP 6.1.22.1216 (CVE-2026-1670)
• SMB NDAA MVO-3 WDR_2MP_32M_PTZ_v2.0 (CVE-2026-1670)
• PTZ WDR 2MP 32M WDR_2MP_32M_PTZ_v2.0 (CVE-2026-1670)
• 25M IPC WDR_2MP_32M_PTZ_v2.0 (CVE-2026-1670)

A critical auth bypass flaw in Honeywell CCTV models could allow attackers to take over accounts, granting unauthorized access to live feeds. Many of these cameras are used in critical infrastructure, corporate sites, and government facilities worldwide. The flaw can be exploited remotely, risking sensitive surveillance data and enabling attackers to move laterally within networks, making it a severe threat to security, privacy, and operational integrity.

CISA advises organizations to reduce risk from this Honeywell CCTV flaw by isolating control system devices from the Internet, using firewalls, and placing remote devices behind secure networks. When remote access is needed, employ updated VPNs and ensure connected devices are secure. Organizations should perform risk assessments before deploying defenses, follow ICS security best practices from cisa.gov/ics, and report suspicious activity. Users should avoid phishing and unsolicited links; no active exploitation has been reported.

The US agency is not aware of attacks exploiting this flaw in the wild.

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, CISA)

Introduction

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:

1. 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

2. 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

3. 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:

1. 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

2. 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

3. 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:

...
[HTTP]
CMPI=60
GatewayAddress=hgame33[.]com:443
GSK=FN:L?ADAFI:F?BCPGD;N>IAO9J>J@N
Port=443
SecondaryGateway=ravinads[.]com:443
SecondaryPort=443

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:

• hxxp://www.hgame33[.]com/00101010101001/morte.spc
• hxxp://hgame33[.]com/00101010101001/debug
• hxxp://www.hgame33[.]com/00101010101001/morte.x86
• hxxp://www.hgame33[.]com/00101010101001/morte.mpsl
• hxxp://www.hgame33[.]com/00101010101001/morte.arm7
• hxxp://www.hgame33[.]com/00101010101001/morte.sh4
• hxxp://hgame33[.]com/00101010101001/morte.arm
• hxxp://hgame33[.]com/00101010101001/morte.i686
• hxxp://hgame33[.]com/00101010101001/morte.arc
• hxxp://hgame33[.]com/00101010101001/morte.arm5
• hxxp://hgame33[.]com/00101010101001/morte.arm6
• hxxp://www.hgame33[.]com/00101010101001/morte.m68k
• hxxp://www.hgame33[.]com/00101010101001/morte.ppc
• hxxp://www.hgame33[.]com/00101010101001/morte.x86_64
• hxxp://hgame33[.]com/00101010101001/morte.mips

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:

1. 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

2. 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

3. 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.

Indicators of compromise

* Additional IoCs and a YARA rule for detecting Stan Ghouls activity are available to customers of our Threat Intelligence Reporting service. For more details, contact us at crimewareintel@kaspersky.com.

PDF decoys

B4FF4AA3EBA9409F9F1A5210C95DC5C3
AF9321DDB4BEF0C3CD1FF3C7C786F0E2
056B75FE0D230E6FF53AC508E0F93CCB
DB84FEBFD85F1469C28B4ED70AC6A638
649C7CACDD545E30D015EDB9FCAB3A0C
BE0C87A83267F1CE13B3F75C78EAC295
78CB3ABD00A1975BEBEDA852B2450873
51703911DC437D4E3910CE7F866C970E
FA53B0FCEF08F8FF3FFDDFEE7F1F4F1A
79D0EEAFB30AA2BD4C261A51104F6ACC
8DA8F0339D17E2466B3D73236D18B835
299A7E3D6118AD91A9B6D37F94AC685B
62AFACC37B71D564D75A58FC161900C3
047A600E3AFBF4286175BADD4D88F131
ED0CCADA1FE1E13EF78553A48260D932
C363CD87178FD660C25CDD8D978685F6
61FF22BA4C3DF7AE4A936FCFDEB020EA
B51D9EDC1DC8B6200F260589A4300009
923557554730247D37E782DB3BEA365D
60C34AD7E1F183A973FB8EE29DC454E8
0CC80A24841401529EC9C6A845609775
0CE06C962E07E63D780E5C2777A661FC

Malicious loaders

1b740b17e53c4daeed45148bfbee4f14
3f99fed688c51977b122789a094fec2e
8b0bbe7dc960f7185c330baa3d9b214c
95db93454ec1d581311c832122d21b20
646a680856f837254e6e361857458e17
8064f7ac9a5aa845ded6a1100a1d5752
d0cf8946acd3d12df1e8ae4bb34f1a6e
db796d87acb7d980264fdcf5e94757f0
e3cb4dafa1fb596e1e34e4b139be1b05
e0023eb058b0c82585a7340b6ed4cc06
0bf01810201004dcc484b3396607a483
4C4FA06BD840405FBEC34FE49D759E8D
A539A07891A339479C596BABE3060EA6
b13f7ccbedfb71b0211c14afe0815b36
f14275f8f420afd0f9a62f3992860d68
3f41091afd6256701dd70ac20c1c79fe
5c4a57e2e40049f8e8a6a74aa8085c80
7e8feb501885eff246d4cb43c468b411
8aa104e64b00b049264dc1b01412e6d9
8c63818261735ddff2fe98b3ae23bf7d

Malicious domains

mysoliq-uz[.]com
my-xb[.]com
xarid-uz[.]com
ach-uz[.]com
soliq-uz[.]com
minjust-kg[.]com
esf-kg[.]com
taxnotice-kg[.]com
notice-kg[.]com
proauditkg[.]com
kgauditcheck[.]com
servicedoc-kg[.]com
auditnotice-kg[.]com
tax-kg[.]com
rouming-uz[.]com
audit-kg[.]com
kyrgyzstanreview[.]com
salyk-notofocations[.]com

Can a remote software attack send a power wheelchair tumbling down a staircase? Sadly: the answer is “yes.” Check out our latest podcast interview with Billy Rios and Brandon Rothel of QED Secure Solutions. Billy and Brandon discuss their research into security flaws in power wheelchairs by the Japanese firm WHILL.

The post When Cybersecurity Breaks Mobility: The Hidden Risks of Software-Powered Wheelchairs appeared first on The Security Ledger with Paul F. Roberts.

Security researcher Jon “Gainsec” Gaines and YouTuber Benn Jordan discuss their examination of Flock Safety’s AI-powered license plate readers and how cost-driven design choices, outdated software, and weak security controls expose them to abuse.

The post AI Surveillance: Unmasking Flock Safety’s Insecurities appeared first on The Security Ledger with Paul F. Roberts.

Introduction

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:

Using information about the modem’s hardware, we desoldered and read the embedded multimedia memory card, which contained a complete image of its operating system. We then analyzed the image obtained.

Remote access to the modem (CVE-2024-39431)

The modem under investigation, like any modern modem, implements several protocol stacks: 2G, 3G, and LTE. Clearly, the more protocols a device supports, the more potential entry points (attack vectors) it has. Moreover, the lower in the OSI network model stack a vulnerability sits, the more severe the consequences of its exploitation can be. Therefore, we decided to analyze the data packet fragmentation mechanisms at the data link layer (RLC protocol).

We focused on this protocol because it is used to establish a secure encrypted data transmission channel between the base station and the modem, and, in particular, it is used to transmit higher-layer NAS (Non-Access Stratum) protocol data. NAS represents the functional level of the 3G/UMTS protocol stack. Located between the user equipment (UE) and core network, it is responsible for signaling between them. This means that a remote code execution (RCE) vulnerability in RLC would allow an attacker to execute their own code on the modem, bypassing all existing 3G communication protection mechanisms.

3G protocol stack

The RLC protocol uses three different transmission modes: Transparent Mode (TM), Unacknowledged Mode (UM), and Acknowledged Mode (AM). We are only interested in UM, because in this mode the 3G standard allows both the segmentation of data and the concatenation of several small higher-layer data fragments (Protocol Data Units, PDU) into a single data link layer frame. This is done to maximize channel utilization. At the RLC level, packets are referred to as Service Data Units (SDU).

Among the approximately 75,000 different functions in the firmware, we found the function for handling an incoming SDU packet. When handling a received SDU packet, its header fields are parsed. The packet itself consists of a mandatory header, optional headers, and data. The number of optional headers is not limited. The end of the optional headers is indicated by the least significant bit (E bit) being equal to 0. The algorithm processes each header field sequentially, while their E-bits equal 1. During processing, data is written to a variable located on the stack of the calling function. The stack depth is 0xB4 bytes. The size of the packet that can be parsed (i.e., the number of headers, each header being a 2-byte entry on the stack) is limited by the SDU packet size of 0x5F0 bytes.

As a result, exploitation can be achieved using just one packet in which the number of headers exceeds the stack depth (90 headers). It is important to note that this particular function lacks a stack canary, and when the stack overflows, it is possible to overwrite the return address and some non-volatile register values in this function. However, overwriting is only possible with a value ending in one in binary (i.e., a value in which the least significant bit equals 1). Notably, execution takes place on ARM in Thumb mode, so all return addresses must have the least significant bit equal to 1. Coincidence? Perhaps.

In any case, sending the very first dummy SDU packet with the appropriate number of “correct” headers caused the device to reboot. However, at that moment, we had no way to obtain information on where and why the crash occurred (although we suspect the cause was an attempt to transfer control to the address 0xAABBCCDD, taken from our packet).

Gaining persistence in the system

The first and most important observation is that we know the pointer to the newly received SDU packet is stored in register R2. Return Oriented Programming (ROP) techniques can be used to execute our own code, but first we need to make sure it is actually possible.

We utilized the available AT command handler to move the data to RAM areas. Among the available AT commands, we found a suitable function – SPSERVICETYPE.

Next, we used ROP gadgets to overwrite the address 0x8CE56218 without disrupting the subsequent operation of the incoming SDU packet handling algorithm. To achieve this, it was sufficient to return to the function from which the SDU packet handler was called, because it was invoked as a callback, meaning there is no data linkage on the stack. Given that this function only added 0x2C bytes to the stack, we needed to fit within this size.

Stack overflow in the context of the operating system

Having found a suitable ROP chain, we launched an SDU packet containing it as a payload. As a result, we saw the output 0xAABBCCDD in the AT command console for SPSERVICETYPE. Our code worked!

Next, by analogy, we input the address of the stack frame where our data was located, but it turned out not to be executable. We then faced the task of figuring out the MPU settings on the modem. Once again, using the ROP chain method, we generated code that read the MPU table, one DWORD at a time. After many iterations, we obtained the following table.

The table shows what we suspected – the code section is only mapped for execution. An attempt to change the configuration resulted in another ROP chain, but this same section was now mapped with write permissions in an unused slot in the table. Because of MPU programming features, specifically the presence of the overlap mechanism and the fact that a region with a higher ID has higher priority, we were able to write to this section.

All that remained was to use the pointer to our data (still stored in R2) and patch the code section that had just been unlocked for writing. The question was what exactly to patch. The simplest method was to patch the NAS protocol handler by adding our code to it. To do this, we used one of the NAS protocol commands – MM information. This allowed us to send a large amount of data at once and, in response, receive a single byte of data using the MM status command, which confirmed the patching success.

As a result, we not only successfully executed our own code on the modem side but also established full two-way communication with the modem, using the high-level NAS protocol as a means of message delivery. In this case, it was an MM Status packet with the cause field equaling 0xAA.

However, being able to execute our own code on the modem does not give us access to user data. Or does it?

The full version of the article with a detailed description of the development of an AR exploit that led to Doom being run on the head unit is available on ICS CERT website.

We all encounter IoT and home automation in some form or another, from smart speakers to automated sensors that control water pumps. These services appear simple and straightforward to us, but many devices and protocols work together under the hood to deliver them.

One of those protocols is Zigbee. Zigbee is a low-power wireless protocol (based on IEEE 802.15.4) used by many smart devices to talk to each other. It’s common in homes, but is also used in industrial environments where hundreds or thousands of sensors may coordinate to support a process.

There are many guides online about performing security assessments of Zigbee. Most focus on the Zigbee you see in home setups. They often skip the Zigbee used at industrial sites, what I call ‘non-public’ or ‘industrial’ Zigbee.

In this blog, I will take you on a journey through Zigbee assessments. I’ll explain the basics of the protocol and map the attack surface likely to be found in deployments. I’ll also walk you through two realistic attack vectors that you might see in facilities, covering the technical details and common problems that show up in assessments. Finally, I will present practical ways to address these problems.

Zigbee introduction

Protocol overview

Zigbee is a wireless communication protocol designed for low-power applications in wireless sensor networks. Based on the IEEE 802.15.4 standard, it was created for short-range and low-power communication. Zigbee supports mesh networking, meaning devices can connect through each other to extend the network range. It operates on the 2.4 GHz frequency band and is widely used in smart homes, industrial automation, energy monitoring, and many other applications.

You may be wondering why there’s a need for Zigbee when Wi-Fi is everywhere? The answer depends on the application. In most home setups, Wi-Fi works well for connecting devices. But imagine you have a battery-powered sensor that isn’t connected to your home’s electricity. If it used Wi-Fi, its battery would drain quickly – maybe in just a few days – because Wi-Fi consumes much more power. In contrast, the Zigbee protocol allows for months or even years of uninterrupted work.

Now imagine an even more extreme case. You need to place sensors in a radiation zone where humans can’t go. You drop the sensors from a helicopter and they need to operate for months without a battery replacement. In this situation, power consumption becomes the top priority. Wi-Fi wouldn’t work, but Zigbee is built exactly for this kind of scenario.

Also, Zigbee has a big advantage if the area is very large, covering thousands of square meters and requiring thousands of sensors: it supports thousands of nodes in a mesh network, while Wi-Fi is usually limited to hundreds at most.

There are lots more ins and outs, but these are the main reasons Zigbee is preferred for large-scale, low-power sensor networks.

Since both Zigbee and IEEE 802.15.4 define wireless communication, many people confuse the two. The difference between them, to put it simply, concerns the layers they support. IEEE 802.15.4 defines the physical (PHY) and media access control (MAC) layers, which basically determine how devices send and receive data over the air. Zigbee (as well as other protocols like Thread, WirelessHART, 6LoWPAN, and MiWi) builds on IEEE 802.15.4 by adding the network and application layers that define how devices form a network and communicate.

Zigbee operates in the 2.4 GHz wireless band, which it shares with Wi-Fi and Bluetooth. The Zigbee band includes 16 channels, each with a 2 MHz bandwidth and a 5 MHz gap between channels.

This shared frequency means Zigbee networks can sometimes face interference from Wi-Fi or Bluetooth devices. However, Zigbee’s low power and adaptive channel selection help minimize these conflicts.

Devices and network

There are three main types of Zigbee devices, each of which plays a different role in the network.

1. Zigbee coordinator
   The coordinator is the brain of the Zigbee network. A Zigbee network is always started by a coordinator and can only contain one coordinator, which has the fixed address 0x0000.
   It performs several key tasks:
   • Starts and manages the Zigbee network.
   • Chooses the Zigbee channel.
   • Assigns addresses to other devices.
   • Stores network information.
   • Chooses the PAN ID: a 2-byte identifier (for example, 0x1234) that uniquely identifies the network.
   • Sets the Extended PAN ID: an 8-byte value, often an ASCII name representing the network.

   The coordinator can have child devices, which can be either Zigbee routers or Zigbee end devices.

2. Zigbee router
   The router works just like a router in a traditional network: it forwards data between devices, extends the network range and can also accept child devices, which are usually Zigbee end devices.
   Routers are crucial for building large mesh networks because they enable communication between distant nodes by passing data through multiple hops.
3. Zigbee end device
   The end device, also referred to as a Zigbee endpoint, is the simplest and most power-efficient type of Zigbee device. It only communicates with its parent, either a coordinator or router, and sleeps most of the time to conserve power. Common examples include sensors, remotes, and buttons.

Zigbee end devices do not accept child devices unless they are configured as both a router and an endpoint simultaneously.

Each of these device types, also known as Zigbee nodes, has two types of address:

• Short address: two bytes long, similar to an IP address in a TCP/IP network.
• Extended address: eight bytes long, similar to a MAC address.

Both addresses can be used in the MAC and network layers, unlike in TCP/IP, where the MAC address is used only in Layer 2 and the IP address in Layer 3.

Zigbee setup

Zigbee has many attack surfaces, such as protocol fuzzing and low-level radio attacks. In this post, however, I’ll focus on application-level attacks. Our test setup uses two attack vectors and is intentionally small to make the concepts clear.

In our setup, a Zigbee coordinator is connected to a single device that functions as both a Zigbee endpoint and a router. The coordinator also has other interfaces (Ethernet, Bluetooth, Wi-Fi, LTE), while the endpoint has a relay attached that the coordinator can switch on or off over Zigbee. This relay can be triggered by events coming from any interface, for example, a Bluetooth command or an Ethernet message.

Our goal will be to take control of the relay and toggle its state (turn it off and on) using only the Zigbee interface. Because the other interfaces (Ethernet, Bluetooth, Wi-Fi, LTE) are out of scope, the attack must work by hijacking Zigbee communication.

For the purposes of this research, we will attempt to hijack the communication between the endpoint and the coordinator. The two attack vectors we will test are:

1. Spoofed packet injection: sending forged Zigbee commands made to look like they come from the coordinator to trigger the relay.
2. Coordinator impersonation (rejoin attack): impersonating the legitimate coordinator to trick the endpoint into joining the attacker-controlled coordinator and controlling it directly.

Spoofed packet injection

In this scenario, we assume the Zigbee network is already up and running and that both the coordinator and endpoint nodes are working normally. The coordinator has additional interfaces, such as Ethernet, and the system uses those interfaces to trigger the relay. For instance, a command comes in over Ethernet and the coordinator sends a Zigbee command to the endpoint to toggle the relay. Our goal is to toggle the relay by injecting simulated legitimate Zigbee packets, using only the Zigbee link.

Sniffing

The first step in any radio assessment is to sniff the wireless traffic so we can learn how the devices talk. For Zigbee, a common and simple tool is the nRF52840 USB dongle by Nordic Semiconductor. With the official nRF Sniffer for 802.15.4 firmware, the dongle can run in promiscuous mode to capture all 802.15.4/Zigbee traffic. Those captures can be opened in Wireshark with the appropriate dissector to inspect the frames.

How do you find the channel that’s in use?

Zigbee runs on one of the 16 channels that we mentioned earlier, so we must set the sniffer to the same channel that the network uses. One practical way to scan the channels is to change the sniffer channel manually in Wireshark and watch for Zigbee traffic. When we see traffic, we know we’ve found the right channel.

After selecting the channel, we will be able to see the communication between the endpoint and the coordinator, though it will most likely be encrypted:

In the “Info” column, we can see that Wireshark only identifies packets as Data or Command without specifying their exact type, and that’s because the traffic is encrypted.

Even when Zigbee payloads are encrypted, the network and MAC headers remain visible. That means we can usually read things like source and destination addresses, PAN ID, short and extended MAC addresses, and frame control fields. The application payload (i.e., the actual command to toggle the relay) is typically encrypted at the Zigbee network/application layer, so we won’t see it in clear text without encryption keys. Nevertheless, we can still learn enough from the headers.

Decryption

Zigbee supports several key types and encryption models. In this post, we’ll keep it simple and look at a case involving only two security-related devices: a Zigbee coordinator and a device that is both an endpoint and a router. That way, we’ll only use a network encryption model, whereas with, say, mesh networks there can be various encryption models in use.

The network encryption model is a common concept. The traffic that we sniffed earlier is typically encrypted using the network key. This key is a symmetric AES-128 key shared by all devices in a Zigbee network. It protects network-layer packets (hop-by-hop) such as routing and broadcast packets. Because every router on the path shares the network key, this encryption method is not considered end-to-end.

Depending on the specific implementation, Zigbee can use two approaches for application payloads:

• Network-layer encryption (hop-by-hop): the network key encrypts the Application Support Sublayer (APS) data, the sublayer of the application layer in Zigbee. In this case, each router along the route can decrypt the APS payload. This is not end-to-end encryption, so it is not recommended for transmitting sensitive data.
• Link key (end-to-end) encryption: a link key, which is also an AES-128 key, is shared between two devices (for example, the coordinator and an endpoint).

The link key provides end-to-end protection of the APS payload between the two devices.

Because the network key could allow an attacker to read and forge many types of network traffic, it must be random and protected. Exposing the key effectively compromises the entire network.

When a new device joins, the coordinator (Trust Center) delivers the network key using a Transport Key command. That transport packet must be protected by a link key so the network key is not exposed in clear text. The link key authenticates the joining device and protects the key delivery.

The image below shows the transport packet:

There are two common ways link keys are provided:

• Pre-installed: the device ships with an installation code or link key already set.
• Key establishment: the device runs a key-establishment protocol.

A common historical problem is the global default Trust Center link key, “ZigBeeAlliance09”. It was included in early versions of Zigbee (pre-3.0) to facilitate testing and interoperability. However, many vendors left it enabled on consumer devices, and that has caused major security issues. If an attacker knows this key, they can join devices and read or steal the network key.

Newer versions – Zigbee 3.0 and later – introduced installation codes and procedures to derive unique link keys for each device. An installation code is usually a factory-assigned secret (often encoded on the device label) that the Trust Center uses to derive a unique link key for the device in question. This helps avoid the problems caused by a single hard-coded global key.

Unfortunately, many manufacturers still ignore these best practices. During real assessments, we often encounter devices that use default or hard-coded keys.

How can these keys be obtained?

If an endpoint has already joined the network and communicates with the coordinator using the network key, there are two main options for decrypting traffic:

1. Guess or brute-force the network key. This is usually impractical because a properly generated network key is a random AES-128 key.
2. Force the device to rejoin and capture the transport key. If we can make the endpoint leave the network and then rejoin, the coordinator will send the transport key. Capturing that packet can reveal the network key, but the transport key itself is protected by the link key. Therefore, we still need the link key.

To obtain the network and link keys, many approaches can be used:

• The well-known default link key, ZigBeeAlliance09. Many legacy devices still use it.
• Identify the device manufacturer and search for the default keys used by that vendor. We can find the manufacturer by:
  • Checking the device MAC/OUI (the first three bytes of the 64-bit extended address often map to a vendor).
  • Physically inspecting the device (label, model, chip markings).
• Extract the firmware from the coordinator or device if we have physical access and search for hard-coded keys inside the firmware images.

Once we have the relevant keys, the decryption process is straightforward:

1. Open the capture in Wireshark.
2. Go to Edit -> Preferences -> Protocols -> Zigbee.
3. Add the network key and any link keys in our possession.
4. Wireshark will then show decrypted APS payloads and higher-level Zigbee packets.

After successful decryption, packet types and readable application commands will be visible, such as Link Status or on/off cluster commands:

Choose your gadget

Now that we can read and potentially decrypt traffic, we need hardware and software to inject packets over the Zigbee link between the coordinator and the endpoint. To keep this practical and simple, I opted for cheap, widely available tools that are easy to set up.

For the hardware, I used the nRF52840 USB dongle, the same device we used for sniffing. It’s inexpensive, easy to find, and supports IEEE 802.15.4/Zigbee, so it can sniff and transmit.

The dongle runs the firmware we can use. A good firmware platform is Zephyr RTOS. Zephyr has an IEEE 802.15.4 radio API that enables the device to receive raw frames, essentially enabling sniffer mode, as well as send raw frames as seen in the snippets below.

Using this API and other components, we created a transceiver implementation written in C, compiled it to firmware, and flashed it to the dongle. The firmware can expose a simple runtime interface, such as a USB serial port, which allows us to control the radio from a laptop.

At runtime, the dongle listens on the serial port (for example, /dev/ttyACM1). Using a script, we can send it raw bytes, which the firmware will pass to the radio API and transmit to the channel. The following is an example of a tiny Python script to open the serial port:

I used the Scapy tool with the 802.15.4/Zigbee extensions to build Zigbee packets. Scapy lets us assemble packets layer-by-layer – MAC → NWK → APS → ZCL – and then convert them to raw bytes to send to the dongle. We will talk about APS and ZCL in more detail later.

Here is an example of how we can use Scapy to craft an APS layer packet:

from scapy.layers.dot15d4 import Dot15d4, Dot15d4FCS, Dot15d4Data, Dot15d4Cmd, Dot15d4Beacon, Dot15d4CmdAssocResp
from scapy.layers.zigbee import ZigbeeNWK, ZigbeeAppDataPayload, ZigbeeSecurityHeader, ZigBeeBeacon, ZigbeeAppCommandPayload

Before sending, the packet must be properly encrypted and signed so the endpoint accepts it. That means applying AES-CCM (AES-128 with MIC) using the network key (or the correct link key) and adhering to Zigbee’s rules for packet encryption and MIC calculation. This is how we implemented the encryption and MIC in Python (using a cryptographic library) after building the Scapy packet. We then sent the final bytes to the dongle.

This is how we implemented the encryption and MIC:

Crafting the packet

Now that we know how to inject packets, the next question is what to inject. To toggle the relay, we simply need to send the same type of command that the coordinator already sends. The easiest way to find that command is to sniff the traffic and read the application payload. However, when we look at captures in Wireshark, we can see many packets under ZCL marked [Malformed Packet].

A “malformed” ZCL packet usually means Wireshark could not fully interpret the packet because the application layer is non-standard or lacks details Wireshark expects. To understand why this happens, let’s look at the Zigbee application layer.

The Zigbee application layer consists of four parts:

• Application Support Sublayer (APS): routes messages to the correct profile, endpoint, and cluster, and provides application-level security.
• Application Framework (AF): contains the application objects that implement device functionality. These objects reside on endpoints (logical addresses 1–240) and expose clusters (sets of attributes and commands).
• Zigbee Cluster Library (ZCL): defines standard clusters and commands so devices can interoperate.
• Zigbee Device Object (ZDO): handles device discovery and management (out of scope for this post).

To make sense of application traffic, we must introduce three concepts:

• Profile: a rulebook for how devices should behave for a specific use case. Public (standard) profiles are managed by the Connectivity Standards Alliance (CSA). Vendors can also create private profiles for proprietary features.
• Cluster: a set of attributes and commands for a particular function. For example, the On/Off cluster contains On and Off commands and an OnOff attribute that displays the current state.
• Endpoint: a logical “port” on the device where a profile and clusters reside. A device can host multiple endpoints for different functions.

Putting all this together, in the standard home automation traffic we see APS pointing to the home automation profile, the On/Off cluster, and a destination endpoint (for example, endpoint 1). In ZCL, the byte 0x00 often means “Off”.

In many industrial setups, vendors use private profiles or custom application frameworks. That’s why Wireshark can’t decode the packets; the AF payload is custom, so the dissector doesn’t know the format.

So how do we find the right bytes to toggle the switch when the application is private? Our strategy has two phases.

1. Passive phase
   Sniff traffic while the system is driven legitimately. For example, trigger the relay from another interface (Ethernet or Bluetooth) and capture the Zigbee packets used to toggle the relay. If we can decrypt the captures, we can extract the application payload that correlates with the on/off action.
   
2. Active phase

With the legitimate payload at hand, we can now turn to creating our own packet. There are two ways to do that. First, we need to replay or duplicate the captured application payload exactly as it is. This works if there are no freshness checks like sequence numbers. Otherwise, we have to reverse-engineer the payload and adjust any counters or fields that prevent replay. For instance, many applications include an application-level counter. If the device ignores packets with a lower application counter, we must locate and increment that counter when we craft our packet.

Another important protective measure is the frame counter inside the Zigbee security header (in the network header security fields). The frame counter prevents replay attacks; the receiver expects the frame counter to increase with each new packet, and will reject packets with a lower or repeated counter.

So, in the active phase, we must:

1. Sniff the traffic until the coordinator sends a valid packet to the endpoint.
2. Decrypt the packet, extract the counters and increase them by one.
3. Build a packet with the correct APS/AF fields (profile, endpoint, cluster).
4. Include a valid ZCL command or the vendor-specific payload that we identified in the passive phase.
5. Encrypt and sign the packet with the correct network or link key.
6. Make sure both the application counter (if used) and the Zigbee frame counter are modified so the packet is accepted.

The whole strategy for this phase will look like this:

If all of the above are handled correctly, we will be able to hijack the Zigbee communication and toggle the relay (turn it off and on) using only the Zigbee link.

Coordinator impersonation (rejoin attack)

The goal of this attack vector is to force the Zigbee endpoint to leave its original coordinator’s network and join our spoofed network so that we can take control of the device. To do this, we must achieve two things:

1. Force the endpoint to leave the original network.
2. Spoof the original coordinator and trick the node into joining our fake coordinator.

Force leaving

To better understand how to manipulate endpoint connections, let’s first describe the concept of a beacon frame. Beacon frames are periodic announcements sent by a coordinator and by routers. They advertise the presence of a network and provide join information, such as:

• PAN ID and Extended PAN ID
• Coordinator address
• Stack/profile information
• Device capacity (for example, whether the coordinator can accept child devices)

When a device wants to join, it sends a beacon request across Zigbee channels and waits for beacon replies from nearby coordinators/routers. Even if the network is not beacon-enabled for regular synchronization, beacon frames are still used during the join/discovery process, so they are mandatory when a node tries to discover networks.

Note that beacon frames exist at both the Zigbee and IEEE 802.15.4 levels. The MAC layer carries the basic beacon structure that Zigbee then extends with network-specific fields.

Now, we can force the endpoint to leave its network by abusing how Zigbee handles PAN conflicts. If a coordinator sees beacons from another coordinator using the same PAN ID and the same channel, it may trigger a PAN ID conflict resolution. When that happens, the coordinator can instruct its nodes to change PAN ID and rejoin, which causes them to leave and then attempt to join again. That rejoin window gives us an opportunity to advertise a spoofed coordinator and capture the joining node.

In the capture shown below, packet 7 is a beacon generated by our spoofed coordinator using the same PAN ID as the real network. As a result, the endpoint with the address 0xe8fa leaves the network (see packets 14–16).

Choose me

After forcing the endpoint to leave its original network by sending a fake beacon, the next step is to make the endpoint choose our spoofed coordinator. At this point, we assume we already have the necessary keys (network and link keys) and understand how the application behaves.

To impersonate the original coordinator, our spoofed coordinator must reply to any beacon request the endpoint sends. The beacon response must include the same Extended PAN ID (and other fields) that the endpoint expects. If the endpoint deems our beacon acceptable, it may attempt to join us.

I can think of two ways to make the endpoint prefer our coordinator.

1. Jam the real coordinator
   Use a device that reduces the real coordinator’s signal at the endpoint so that it appears weaker, forcing the endpoint to prefer our beacon. This requires extra hardware.
2. Exploit undefined or vendor-specific behavior
   Zigbee stacks sometimes behave slightly differently across vendors. One useful field in a beacon is the Update ID field. It increments when a coordinator changes network configuration.

If two coordinators advertise the same Extended PAN ID but one has a higher Update ID, some stacks will prefer the beacon with the higher Update ID. This is undefined behavior across implementations; it works on some stacks but not on others. In my experience, sometimes it works and sometimes it fails. There are lots of other similar quirks we can try during an assessment.

Even if the endpoint chooses our fake coordinator, the connection may be unstable. One main reason for that is the timing. The endpoint expects ACKs for the frames it sends to the coordinator, as well as fast responses regarding connection initiation packets. If our responder is implemented in Python on a laptop that receives packets, builds responses, and forwards them to a dongle, the round trip will be too slow. The endpoint will not receive timely ACKs or packets and will drop the connection.

In short, we’re not just faking a few packets; we’re trying to reimplement parts of Zigbee and IEEE 802.15.4 that must run quickly and reliably. This is usually too slow for production stacks when done in high-level, interpreted code.

A practical fix is to run a real Zigbee coordinator stack directly on the dongle. For example, the nRF52840 dongle can act as a coordinator if flashed with the right Nordic SDK firmware (see Nordic’s network coordinator sample). That provides the correct timing and ACK behavior needed for a stable connection.

However, that simple solution has one significant disadvantage. In industrial deployments we often run into incompatibilities. In my tests I compared beacons from the real coordinator and the Nordic coordinator firmware. Notable differences were visible in stack profile headers:

The stack profile identifies the network profile type. Common values include 0x00, which is a network-specific (private) profile, and 0x02, which is a Zigbee Pro (public) profile.

If the endpoint expects a network-specific profile (i.e., it uses a private vendor profile) and we provide Zigbee Pro, the endpoint will refuse to join. Devices that only understand private profiles will not join public-profile networks, and vice versa. In my case, I could not change the Nordic firmware to match the proprietary stack profile, so the endpoint refused to join.

Because of this discrepancy, the “flash a coordinator firmware on the dongle” fix was ineffective in that environment. This is why the standard off-the-shelf tools and firmware often fail in industrial cases, forcing us to continue working with and optimizing our custom setup instead.

Back to the roots

In our previous test setup we used a sniffer in promiscuous mode, which receives every frame on the air regardless of destination. Real Zigbee (IEEE 802.15.4) nodes do not work like that. At the MAC/802.15.4 layer, a node filters frames by PAN ID and destination address. A frame is only passed to upper layers if the PAN ID matches and the destination address is the node’s address or a broadcast address.

We can mimic that real behavior on the dongle by running Zephyr RTOS and making the dongle act as a basic 802.15.4 coordinator. In that role, we set a PAN ID and short network address on the dongle so that the radio only accepts frames that match those criteria. This is important because it allows the dongle to handle auto-ACKs and MAC-level timing: the dongle will immediately send ACKs at the MAC level.

With the dongle doing MAC-level work (sending ACKs and PAN filtering), we can implement the Zigbee logic in Python. Scapy helps a lot with packet construction: we can create our own beacons with the headers matching those of the original coordinator, which solves the incompatibility problem. However, we must still implement the higher-level Zigbee state machine in our code, including connection initiation, association, network key handling, APS/AF behavior, and application payload handling. That’s the hardest part.

There is one timing problem that we cannot solve in Python: the very first steps of initiating a connection require immediate packet responses. To handle this issue, we implemented the time-critical parts in C on the dongle firmware. For example, we can statically generate the packets for connection initiation in Python and hard-code them in the firmware. Then, using “if” statements, we can determine how to respond to each packet from the endpoint.

So, we let the dongle (C/Zephyr) handle MAC-level ACKs and the initial association handshake, but let Python build higher-level packets and instruct the dongle what to send next when dealing with the application level. This hybrid model reduces latency and maintains a stable connection. The final architecture looks like this:

Deliver the key

Here’s a quick recap of how joining works: a Zigbee endpoint broadcasts beacon requests across channels, waits for beacon responses, chooses a coordinator, and sends an association request, followed by a data request to identify its short address. The coordinator then sends a transport key packet containing the network key. If the endpoint has the correct link key, it can decrypt the transport key packet and obtain the network key, meaning it has now been authenticated. From that point on, network traffic is encrypted with the network key. The entire process looks like this:

The sticking point is the transport key packet. This packet is protected using the link key, a per-device key shared between the coordinator (Trust Center) and the joining endpoint. Before the link key can be used for encryption, it often needs to be processed (hashed/derived) according to Zigbee’s key derivation rules. Since there is no trivial Python implementation that implements this hashing algorithm, we may need to implement the algorithm ourselves.

I implemented the required key derivation; the code is available on our GitHub.

Now that we’ve managed to obtain the hashed link key and deliver it to the endpoint, we can successfully mimic a coordinator.

The final success

If we follow the steps above, we can get the endpoint to join our spoofed coordinator. Once the endpoint joins, it will often remain associated with our coordinator, even after we power it down (until another event causes it to re-evaluate its connection). From that point on, we can interact with the device at the application layer using Python. Getting access as a coordinator allowed us to switch the relay on and off as intended, but also provided much more functionality and control over the node.

Conclusion

In conclusion, this study demonstrates why private vendor profiles in industrial environments complicate assessments: common tools and frameworks often fail, necessitating the development of custom tools and firmware. We tested a simple two-node scenario, but with multiple nodes the attack surface changes drastically and new attack vectors emerge (for example, attacks against routing protocols).

As we saw, a misconfigured Zigbee setup can lead to a complete network compromise. To improve Zigbee security, use the latest specification’s security features, such as using installation codes to derive unique link keys for each device. Also, avoid using hard-coded or default keys. Finally, it is not recommended to use the network key encryption model. Add another layer of security in addition to the network level protection by using end-to-end encryption at the application level.

On December 4, 2025, researchers published details on the critical vulnerability CVE-2025-55182, which received a CVSS score of 10.0. It has been unofficially dubbed React2Shell, as it affects React Server Components (RSC) functionality used in web applications built with the React library. RSC speeds up UI rendering by distributing tasks between the client and the server. The flaw is categorized as CWE-502 (Deserialization of Untrusted Data). It allows an attacker to execute commands, as well as read and write files in directories accessible to the web application, with the server process privileges.

Almost immediately after the exploit was published, our honeypots began registering attempts to leverage CVE-2025-55182. This post analyzes the attack patterns, the malware that threat actors are attempting to deliver to vulnerable devices, and shares recommendations for risk mitigation.

A brief technical analysis of the vulnerability

React applications are built on a component-based model. This means each part of the application or framework should operate independently and offer other components clear, simple methods for interaction. While this approach allows for flexible development and feature addition, it can require users to download large amounts of data, leading to inconsistent performance across devices. This is the challenge React Server Components were designed to address.

The vulnerability was found within the Server Actions component of RSC. To reach the vulnerable function, the attacker just needs to send a POST request to the server containing a serialized data payload for execution. Part of the functionality of the handler that allows for unsafe deserialization is illustrated below:

A comparison of the vulnerable (left) and patched (right) functions

CVE-2025-55182 on Kaspersky honeypots

As the vulnerability is rather simple to exploit, the attackers quickly added it to their arsenal. The initial exploitation attempts were registered by Kaspersky honeypots on December 5. By Monday, December 8, the number of attempts had increased significantly and continues to rise.

The number of CVE-2025-55182 attacks targeting Kaspersky honeypots, by day (download)

Attackers first probe their target to ensure it is not a honeypot: they run whoami, perform multiplication in bash, or compute MD5 or Base64 hashes of random strings to verify their code can execute on the targeted machine.

In most cases, they then attempt to download malicious files using command-line web clients like wget or curl. Additionally, some attackers deliver a PowerShell-based Windows payload that installs XMRig, a popular Monero crypto miner.

CVE-2025-55182 was quickly weaponized by numerous malware campaigns, ranging from classic Mirai/Gafgyt variants to crypto miners and the RondoDox botnet. Upon infecting a system, RondoDox wastes no time, its loader script immediately moving to eliminate competitors:

Beyond checking hardcoded paths, RondoDox also neutralizes AppArmor and SELinux security modules and employs more sophisticated methods to find and terminate processes with ELF files removed for disguise.

Only after completing these steps does the script download and execute the main payload by sequentially trying three different loaders: wget, curl, and wget from BusyBox. It also iterates through 18 different malware builds for various CPU architectures, enabling it to infect both IoT devices and standard x86_64 Linux servers.

In some attacks, instead of deploying malware, the adversary attempted to steal credentials for Git and cloud environments. A successful breach could lead to cloud infrastructure compromise, software supply chain attacks, and other severe consequences.

Risk mitigation measures

We strongly recommend updating the relevant packages by applying patches released by the developers of the corresponding modules and bundles.
Vulnerable versions of React Server Components:

• react-server-dom-webpack (19.0.0, 19.1.0, 19.1.1, 19.2.0)
• react-server-dom-parcel (19.0.0, 19.1.0, 19.1.1, 19.2.0)
• react-server-dom-turbopack (19.0.0, 19.1.0, 19.1.1, 19.2.0)

Bundles and modules confirmed as using React Server Components:

• next
• react-router
• waku
• @parcel/rsc
• @vitejs/plugin-rsc
• rwsdk

To prevent exploitation while patches are being deployed, consider blocking all POST requests containing the following keywords in parameters or the request body:

• #constructor
• #__proto__
• #prototype
• vm#runInThisContext
• vm#runInNewContext
• child_process#execSync
• child_process#execFileSync
• child_process#spawnSync
• module#_load
• module#createRequire
• fs#readFileSync
• fs#writeFileSync
• s#appendFileSync

Conclusion

Due to the ease of exploitation and the public availability of a working PoC, threat actors have rapidly adopted CVE-2025-55182. It is highly likely that attacks will continue to grow in the near term.

We recommend immediately updating React to the latest patched version, scanning vulnerable hosts for signs of malware, and changing any credentials stored on them.

Indicators of compromise

Malware URLs
hxxp://172.237.55.180/b
hxxp://172.237.55.180/c
hxxp://176.117.107.154/bot
hxxp://193.34.213.150/nuts/bolts
hxxp://193.34.213.150/nuts/x86
hxxp://23.132.164.54/bot
hxxp://31.56.27.76/n2/x86
hxxp://31.56.27.97/scripts/4thepool_miner[.]sh
hxxp://41.231.37.153/rondo[.]aqu[.]sh
hxxp://41.231.37.153/rondo[.]arc700
hxxp://41.231.37.153/rondo[.]armeb
hxxp://41.231.37.153/rondo[.]armebhf
hxxp://41.231.37.153/rondo[.]armv4l
hxxp://41.231.37.153/rondo[.]armv5l
hxxp://41.231.37.153/rondo[.]armv6l
hxxp://41.231.37.153/rondo[.]armv7l
hxxp://41.231.37.153/rondo[.]i486
hxxp://41.231.37.153/rondo[.]i586
hxxp://41.231.37.153/rondo[.]i686
hxxp://41.231.37.153/rondo[.]m68k
hxxp://41.231.37.153/rondo[.]mips
hxxp://41.231.37.153/rondo[.]mipsel
hxxp://41.231.37.153/rondo[.]powerpc
hxxp://41.231.37.153/rondo[.]powerpc-440fp
hxxp://41.231.37.153/rondo[.]sh4
hxxp://41.231.37.153/rondo[.]sparc
hxxp://41.231.37.153/rondo[.]x86_64
hxxp://51.81.104.115/nuts/bolts
hxxp://51.81.104.115/nuts/x86
hxxp://51.91.77.94:13339/termite/51.91.77.94:13337
hxxp://59.7.217.245:7070/app2
hxxp://59.7.217.245:7070/c[.]sh
hxxp://68.142.129.4:8277/download/c[.]sh
hxxp://89.144.31.18/nuts/bolts
hxxp://89.144.31.18/nuts/x86
hxxp://gfxnick.emerald.usbx[.]me/bot
hxxp://meomeoli.mooo[.]com:8820/CLoadPXP/lix.exe?pass=PXPa9682775lckbitXPRopGIXPIL
hxxps://api.hellknight[.]xyz/js
hxxps://gist.githubusercontent[.]com/demonic-agents/39e943f4de855e2aef12f34324cbf150/raw/e767e1cef1c35738689ba4df9c6f7f29a6afba1a/setup_c3pool_miner[.]sh

MD5 hashes
0450fe19cfb91660e9874c0ce7a121e0
3ba4d5e0cf0557f03ee5a97a2de56511
622f904bb82c8118da2966a957526a2b
791f123b3aaff1b92873bd4b7a969387
c6381ebf8f0349b8d47c5e623bbcef6b
e82057e481a2d07b177d9d94463a7441

IT threat evolution in Q3 2025. Mobile statistics
IT threat evolution in Q3 2025. Non-mobile statistics

Quarterly figures

In Q3 2025:

• Kaspersky solutions blocked more than 389 million attacks that originated with various online resources.
• Web Anti-Virus responded to 52 million unique links.
• File Anti-Virus blocked more than 21 million malicious and potentially unwanted objects.
• 2,200 new ransomware variants were detected.
• Nearly 85,000 users experienced ransomware attacks.
• 15% of all ransomware victims whose data was published on threat actors’ data leak sites (DLSs) were victims of Qilin.
• More than 254,000 users were targeted by miners.

Ransomware

Quarterly trends and highlights

Law enforcement success

The UK’s National Crime Agency (NCA) arrested the first suspect in connection with a ransomware attack that caused disruptions at numerous European airports in September 2025. Details of the arrest have not been published as the investigation remains ongoing. According to security researcher Kevin Beaumont, the attack employed the HardBit ransomware, which he described as primitive and lacking its own data leak site.

The U.S. Department of Justice filed charges against the administrator of the LockerGoga, MegaCortex and Nefilim ransomware gangs. His attacks caused millions of dollars in damage, putting him on wanted lists for both the FBI and the European Union.

U.S. authorities seized over $2.8 million in cryptocurrency, $70,000 in cash, and a luxury vehicle from a suspect allegedly involved in distributing the Zeppelin ransomware. The criminal scheme involved data theft, file encryption, and extortion, with numerous organizations worldwide falling victim.

A coordinated international operation conducted by the FBI, Homeland Security Investigations (HSI), the U.S. Internal Revenue Service (IRS), and law enforcement agencies from several other countries successfully dismantled the infrastructure of the BlackSuit ransomware. The operation resulted in the seizure of four servers, nine domains, and $1.09 million in cryptocurrency. The objective of the operation was to destabilize the malware ecosystem and protect critical U.S. infrastructure.

Vulnerabilities and attacks

SSL VPN attacks on SonicWall

Since late July, researchers have recorded a rise in attacks by the Akira threat actor targeting SonicWall firewalls supporting SSL VPN. SonicWall has linked these incidents to the already-patched vulnerability CVE-2024-40766, which allows unauthorized users to gain access to system resources. Attackers exploited the vulnerability to steal credentials, subsequently using them to access devices, even those that had been patched. Furthermore, the attackers were able to bypass multi-factor authentication enabled on the devices. SonicWall urges customers to reset all passwords and update their SonicOS firmware.

Scattered Spider uses social engineering to breach VMware ESXi

The Scattered Spider (UNC3944) group is attacking VMware virtual environments. The attackers contact IT support posing as company employees and request to reset their Active Directory password. Once access to vCenter is obtained, the threat actors enable SSH on the ESXi servers, extract the NTDS.dit database, and, in the final phase of the attack, deploy ransomware to encrypt all virtual machines.

Exploitation of a Microsoft SharePoint vulnerability

In late July, researchers uncovered attacks on SharePoint servers that exploited the ToolShell vulnerability chain. In the course of investigating this campaign, which affected over 140 organizations globally, researchers discovered the 4L4MD4R ransomware based on Mauri870 code. The malware is written in Go and packed using the UPX compressor. It demands a ransom of 0.005 BTC.

The application of AI in ransomware development

A UK-based threat actor used Claude to create and launch a ransomware-as-a-service (RaaS) platform. The AI was responsible for writing the code, which included advanced features such as anti-EDR techniques, encryption using ChaCha20 and RSA algorithms, shadow copy deletion, and network file encryption.

Anthropic noted that the attacker was almost entirely dependent on Claude, as they lacked the necessary technical knowledge to provide technical support to their own clients. The threat actor sold the completed malware kits on the dark web for $400–$1,200.

Researchers also discovered a new ransomware strain, dubbed PromptLock, that utilizes an LLM directly during attacks. The malware is written in Go. It uses hardcoded prompts to dynamically generate Lua scripts for data theft and encryption across Windows, macOS and Linux systems. For encryption, it employs the SPECK-128 algorithm, which is rarely used by ransomware groups.

Subsequently, scientists from the NYU Tandon School of Engineering traced back the likely origins of PromptLock to their own educational project, Ransomware 3.0, which they detailed in a prior publication.

The most prolific groups

This section highlights the most prolific ransomware gangs by number of victims added to each group’s DLS. As in the previous quarter, Qilin leads by this metric. Its share grew by 1.89 percentage points (p.p.) to reach 14.96%. The Clop ransomware showed reduced activity, while the share of Akira (10.02%) slightly increased. The INC Ransom group, active since 2023, rose to third place with 8.15%.

Number of each group’s victims according to its DLS as a percentage of all groups’ victims published on all the DLSs under review during the reporting period (download)

Number of new variants

In the third quarter, Kaspersky solutions detected four new families and 2,259 new ransomware modifications, nearly one-third more than in Q2 2025 and slightly more than in Q3 2024.

Number of new ransomware modifications, Q3 2024 — Q3 2025 (download)

Number of users attacked by ransomware Trojans

During the reporting period, our solutions protected 84,903 unique users from ransomware. Ransomware activity was highest in July, while August proved to be the quietest month.

Number of unique users attacked by ransomware Trojans, Q3 2025 (download)

Attack geography

TOP 10 countries attacked by ransomware Trojans

In the third quarter, Israel had the highest share (1.42%) of attacked users. Most of the ransomware in that country was detected in August via behavioral analysis.

* 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

* Unique Kaspersky users attacked by the specific ransomware Trojan family as a percentage of all unique users attacked by this type of threat.

Miners

Number of new variants

In Q3 2025, Kaspersky solutions detected 2,863 new modifications of miners.

Number of new miner modifications, Q3 2025 (download)

Number of users attacked by miners

During the third quarter, we detected attacks using miner programs on the computers of 254,414 unique Kaspersky users worldwide.

Number of unique users attacked by miners, Q3 2025 (download)

Attack geography

TOP 10 countries and territories attacked by miners

* Excluded are countries and territories with relatively few (under 50,000) Kaspersky users.
** Unique users whose computers were attacked by miners as a percentage of all unique users of Kaspersky products in the country/territory.

Attacks on macOS

In April, researchers at Iru (formerly Kandji) reported the discovery of a new spyware family, PasivRobber. We observed the development of this family throughout the third quarter. Its new modifications introduced additional executable modules that were absent in previous versions. Furthermore, the attackers began employing obfuscation techniques in an attempt to hinder sample detection.

In July, we reported on a cryptostealer distributed through fake extensions for the Cursor AI development environment, which is based on Visual Studio Code. At that time, the malicious JavaScript (JS) script downloaded a payload in the form of the ScreenConnect remote access utility. This utility was then used to download cryptocurrency-stealing VBS scripts onto the victim’s device. Later, researcher Michael Bocanegra reported on new fake VS Code extensions that also executed malicious JS code. This time, the code downloaded a malicious macOS payload: a Rust-based loader. This loader then delivered a backdoor to the victim’s device, presumably also aimed at cryptocurrency theft. The backdoor supported the loading of additional modules to collect data about the victim’s machine. The Rust downloader was analyzed in detail by researchers at Iru.

In September, researchers at Jamf reported the discovery of a previously unknown version of the modular backdoor ChillyHell, first described in 2023. Notably, the Trojan’s executable files were signed with a valid developer certificate at the time of discovery.

The new sample had been available on Dropbox since 2021. In addition to its backdoor functionality, it also contains a module responsible for bruteforcing passwords of existing system users.

By the end of the third quarter, researchers at Microsoft reported new versions of the XCSSET spyware, which targets developers and spreads through infected Xcode projects. These new versions incorporated additional modules for data theft and system persistence.

TOP 20 threats to macOS

Unique users* who encountered this malware as a percentage of all attacked users of Kaspersky security solutions for macOS (download)

* Data for the previous quarter may differ slightly from previously published data due to some verdicts being retrospectively revised.

The PasivRobber spyware continues to increase its activity, with its modifications occupying the top spots in the list of the most widespread macOS malware varieties. Other highly active threats include Amos Trojans, which steal passwords and cryptocurrency wallet data, and various adware. The Backdoor.OSX.Agent.l family, which took thirteenth place, represents a variation on the well-known open-source malware, Mettle.

Geography of threats to macOS

TOP 10 countries and territories by share of attacked users

IoT threat statistics

This section presents statistics on attacks targeting Kaspersky IoT honeypots. The geographic data on attack sources is based on the IP addresses of attacking devices.

In Q3 2025, there was a slight increase in the share of devices attacking Kaspersky honeypots via the SSH protocol.

Distribution of attacked services by number of unique IP addresses of attacking devices (download)

Conversely, the share of attacks using the SSH protocol slightly decreased.

Distribution of attackers’ sessions in Kaspersky honeypots (download)

TOP 10 threats delivered to IoT devices

Share of each threat delivered to an infected device as a result of a successful attack, out of the total number of threats delivered (download)

In the third quarter, the shares of the NyaDrop and Mirai.b botnets significantly decreased in the overall volume of IoT threats. Conversely, the activity of several other members of the Mirai family, as well as the Gafgyt botnet, increased. As is typical, various Mirai variants occupy the majority of the list of the most widespread malware strains.

Attacks on IoT honeypots

Germany and the United States continue to lead in the distribution of attacks via the SSH protocol. The share of attacks originating from Panama and Iran also saw a slight increase.

The largest number of attacks via the Telnet protocol were carried out from China, as is typically the case. Devices located in India reduced their activity, whereas the share of attacks from Indonesia increased.

Attacks via web resources

The statistics in this section are based on detection verdicts by Web Anti-Virus, which protects users when suspicious objects are downloaded from malicious or infected web pages. These malicious pages are purposefully created by cybercriminals. Websites that host user-generated content, such as message boards, as well as compromised legitimate sites, can become infected.

TOP 10 countries that served as sources of web-based attacks

This section gives the geographical distribution of sources of online attacks (such as web pages redirecting to exploits, sites hosting exploits and other malware, and botnet C2 centers) blocked by Kaspersky products. One or more web-based attacks could originate from each unique host.

To determine the geographic source of web attacks, we matched the domain name with the real IP address where the domain is hosted, then identified the geographic location of that IP address (GeoIP).

In the third quarter of 2025, Kaspersky solutions blocked 389,755,481 attacks from internet resources worldwide. Web Anti-Virus was triggered by 51,886,619 unique URLs.

Web-based attacks by country, Q3 2025 (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.

* Excluded are countries and territories with relatively few (under 10,000) Kaspersky users.
** Unique users targeted by web-based Malware attacks as a percentage of all unique users of Kaspersky products in the country/territory.
On average, over the course of the quarter, 4.88% of devices globally were subjected to at least one web-based Malware attack.

Local threats

Statistics on local infections of user computers are an important indicator. They include objects that penetrated the target computer by infecting files or removable media, or initially made their way onto the computer in non-open form. Examples of the latter are programs in complex installers and encrypted files.

Data in this section is based on analyzing statistics produced by anti-virus scans of files on the hard drive at the moment they were created or accessed, and the results of scanning removable storage media: flash drives, camera memory cards, phones, and external drives. The statistics are based on detection verdicts from the on-access scan (OAS) and on-demand scan (ODS) modules of File Anti-Virus.

In the third quarter of 2025, our File Anti-Virus recorded 21,356,075 malicious and potentially unwanted objects.

Countries and territories where users faced the highest risk of local infection

For each country and territory, we calculated the percentage of Kaspersky users on whose computers File Anti-Virus was triggered during the reporting period. This statistic reflects the level of personal computer infection in different countries and territories around the world.

Note that this ranked list includes only attacks by malicious objects classified as Malware. Our calculations leave out File Anti-Virus detections of potentially dangerous or unwanted programs, such as RiskTool or adware.

* Excluded are countries and territories with relatively few (under 10,000) Kaspersky users.
** Unique users on whose computers local Malware threats were blocked, as a percentage of all unique users of Kaspersky products in the country/territory.
On average worldwide, local Malware threats were detected at least once on 12.36% of computers during the third quarter.

Aisuru, the botnet responsible for a series of record-smashing distributed denial-of-service (DDoS) attacks this year, recently was overhauled to support a more low-key, lucrative and sustainable business: Renting hundreds of thousands of infected Internet of Things (IoT) devices to proxy services that help cybercriminals anonymize their traffic. Experts say a glut of proxies from Aisuru and other sources is fueling large-scale data harvesting efforts tied to various artificial intelligence (AI) projects, helping content scrapers evade detection by routing their traffic through residential connections that appear to be regular Internet users.

First identified in August 2024, Aisuru has spread to at least 700,000 IoT systems, such as poorly secured Internet routers and security cameras. Aisuru’s overlords have used their massive botnet to clobber targets with headline-grabbing DDoS attacks, flooding targeted hosts with blasts of junk requests from all infected systems simultaneously.

In June, Aisuru hit KrebsOnSecurity.com with a DDoS clocking at 6.3 terabits per second — the biggest attack that Google had ever mitigated at the time. In the weeks and months that followed, Aisuru’s operators demonstrated DDoS capabilities of nearly 30 terabits of data per second — well beyond the attack mitigation capabilities of most Internet destinations.

These digital sieges have been particularly disruptive this year for U.S.-based Internet service providers (ISPs), in part because Aisuru recently succeeded in taking over a large number of IoT devices in the United States. And when Aisuru launches attacks, the volume of outgoing traffic from infected systems on these ISPs is often so high that it can disrupt or degrade Internet service for adjacent (non-botted) customers of the ISPs.

“Multiple broadband access network operators have experienced significant operational impact due to outbound DDoS attacks in excess of 1.5Tb/sec launched from Aisuru botnet nodes residing on end-customer premises,” wrote Roland Dobbins, principal engineer at Netscout, in a recent executive summary on Aisuru. “Outbound/crossbound attack traffic exceeding 1Tb/sec from compromised customer premise equipment (CPE) devices has caused significant disruption to wireline and wireless broadband access networks. High-throughput attacks have caused chassis-based router line card failures.”

The incessant attacks from Aisuru have caught the attention of federal authorities in the United States and Europe (many of Aisuru’s victims are customers of ISPs and hosting providers based in Europe). Quite recently, some of the world’s largest ISPs have started informally sharing block lists identifying the rapidly shifting locations of the servers that the attackers use to control the activities of the botnet.

Experts say the Aisuru botmasters recently updated their malware so that compromised devices can more easily be rented to so-called “residential proxy” providers. These proxy services allow paying customers to route their Internet communications through someone else’s device, providing anonymity and the ability to appear as a regular Internet user in almost any major city worldwide.

From a website’s perspective, the IP traffic of a residential proxy network user appears to originate from the rented residential IP address, not from the proxy service customer. Proxy services can be used in a legitimate manner for several business purposes — such as price comparisons or sales intelligence. But they are massively abused for hiding cybercrime activity (think advertising fraud, credential stuffing) because they can make it difficult to trace malicious traffic to its original source.

And as we’ll see in a moment, this entire shadowy industry appears to be shifting its focus toward enabling aggressive content scraping activity that continuously feeds raw data into large language models (LLMs) built to support various AI projects.

‘INSANE’ GROWTH

Riley Kilmer is co-founder of spur.us, a service that tracks proxy networks. Kilmer said all of the top proxy services have grown substantially over the past six months.

“I just checked, and in the last 90 days we’ve seen 250 million unique residential proxy IPs,” Kilmer said. “That is insane. That is so high of a number, it’s unheard of. These proxies are absolutely everywhere now.”

Today, Spur says it is tracking an unprecedented spike in available proxies across all providers, including;

LUMINATI_PROXY    11,856,421
NETNUT_PROXY    10,982,458
ABCPROXY_PROXY    9,294,419
OXYLABS_PROXY     6,754,790
IPIDEA_PROXY     3,209,313
EARNFM_PROXY    2,659,913
NODEMAVEN_PROXY    2,627,851
INFATICA_PROXY    2,335,194
IPROYAL_PROXY    2,032,027
YILU_PROXY    1,549,155

Reached for comment about the apparent rapid growth in their proxy network, Oxylabs (#4 on Spur’s list) said while their proxy pool did grow recently, it did so at nowhere near the rate cited by Spur.

“We don’t systematically track other providers’ figures, and we’re not aware of any instances of 10× or 100× growth, especially when it comes to a few bigger companies that are legitimate businesses,” the company said in a written statement.

Bright Data was formerly known as Luminati Networks, the name that is currently at the top of Spur’s list of the biggest residential proxy networks. Bright Data likewise told KrebsOnSecurity that Spur’s current estimates of its proxy network are dramatically overstated and inaccurate.

“We did not actively initiate nor do we see any 10x or 100x expansion of our network, which leads me to believe that someone might be presenting these IPs as Bright Data’s in some way,” said Rony Shalit, Bright Data’s chief compliance and ethics officer. “In many cases in the past, due to us being the leading data collection proxy provider, IPs were falsely tagged as being part of our network, or while being used by other proxy providers for malicious activity.”

“Our network is only sourced from verified IP providers and a robust opt-in only residential peers, which we work hard and in complete transparency to obtain,” Shalit continued. “Every DC, ISP or SDK partner is reviewed and approved, and every residential peer must actively opt in to be part of our network.”

HK NETWORK

Even Spur acknowledges that Luminati and Oxylabs are unlike most other proxy services on their top proxy providers list, in that these providers actually adhere to “know-your-customer” policies, such as requiring video calls with all customers, and strictly blocking customers from reselling access.

Benjamin Brundage is founder of Synthient, a startup that helps companies detect proxy networks. Brundage said if there is increasing confusion around which proxy networks are the most worrisome, it’s because nearly all of these lesser-known proxy services have evolved into highly incestuous bandwidth resellers. What’s more, he said, some proxy providers do not appreciate being tracked and have been known to take aggressive steps to confuse systems that scan the Internet for residential proxy nodes.

Brundage said most proxy services today have created their own software development kit or SDK that other app developers can bundle with their code to earn revenue. These SDKs quietly modify the user’s device so that some portion of their bandwidth can be used to forward traffic from proxy service customers.

“Proxy providers have pools of constantly churning IP addresses,” he said. “These IP addresses are sourced through various means, such as bandwidth-sharing apps, botnets, Android SDKs, and more. These providers will often either directly approach resellers or offer a reseller program that allows users to resell bandwidth through their platform.”

Many SDK providers say they require full consent before allowing their software to be installed on end-user devices. Still, those opt-in agreements and consent checkboxes may be little more than a formality for cybercriminals like the Aisuru botmasters, who can earn a commission each time one of their infected devices is forced to install some SDK that enables one or more of these proxy services.

Depending on its structure, a single provider may operate hundreds of different proxy pools at a time — all maintained through other means, Brundage said.

“Often, you’ll see resellers maintaining their own proxy pool in addition to an upstream provider,” he said. “It allows them to market a proxy pool to high-value clients and offer an unlimited bandwidth plan for cheap reduce their own costs.”

Some proxy providers appear to be directly in league with botmasters. Brundage identified one proxy seller that was aggressively advertising cheap and plentiful bandwidth to content scraping companies. After scanning that provider’s pool of available proxies, Brundage said he found a one-to-one match with IP addresses he’d previously mapped to the Aisuru botnet.

Brundage says that by almost any measurement, the world’s largest residential proxy service is IPidea, a China-based proxy network. IPidea is #5 on Spur’s Top 10, and Brundage said its brands include ABCProxy (#3), Roxlabs, LunaProxy, PIA S5 Proxy, PyProxy, 922Proxy, 360Proxy, IP2World, and Cherry Proxy. Spur’s Kilmer said they also track Yilu Proxy (#10) as IPidea.

Brundage said all of these providers operate under a corporate umbrella known on the cybercrime forums as “HK Network.”

“The way it works is there’s this whole reseller ecosystem, where IPidea will be incredibly aggressive and approach all these proxy providers with the offer, ‘Hey, if you guys buy bandwidth from us, we’ll give you these amazing reseller prices,'” Brundage explained. “But they’re also very aggressive in recruiting resellers for their apps.”

A graphic depicting the relationship between proxy providers that Synthient found are white labeling IPidea proxies. Image: Synthient.com.

Those apps include a range of low-cost and “free” virtual private networking (VPN) services that indeed allow users to enjoy a free VPN, but which also turn the user’s device into a traffic relay that can be rented to cybercriminals, or else parceled out to countless other proxy networks.

“They have all this bandwidth to offload,” Brundage said of IPidea and its sister networks. “And they can do it through their own platforms, or they go get resellers to do it for them by advertising on sketchy hacker forums to reach more people.”

One of IPidea’s core brands is 922S5Proxy, which is a not-so-subtle nod to the 911S5Proxy service that was hugely popular between 2015 and 2022. In July 2022, KrebsOnSecurity published a deep dive into 911S5Proxy’s origins and apparent owners in China. Less than a week later, 911S5Proxy announced it was closing down after the company’s servers were massively hacked.

That 2022 story named Yunhe Wang from Beijing as the apparent owner and/or manager of the 911S5 proxy service. In May 2024, the U.S. Department of Justice arrested Mr Wang, alleging that his network was used to steal billions of dollars from financial institutions, credit card issuers, and federal lending programs. At the same time, the U.S. Treasury Department announced sanctions against Wang and two other Chinese nationals for operating 911S5Proxy.

The website for 922Proxy.

DATA SCRAPING FOR AI

In recent months, multiple experts who track botnet and proxy activity have shared that a great deal of content scraping which ultimately benefits AI companies is now leveraging these proxy networks to further obfuscate their aggressive data-slurping activity. That’s because by routing it through residential IP addresses, content scraping firms can make their traffic far trickier to filter out.

“It’s really difficult to block, because there’s a risk of blocking real people,” Spur’s Kilmer said of the LLM scraping activity that is fed through individual residential IP addresses, which are often shared by multiple customers at once.

Kilmer says the AI industry has brought a veneer of legitimacy to residential proxy business, which has heretofore mostly been associated with sketchy affiliate money making programs, automated abuse, and unwanted Internet traffic.

“Web crawling and scraping has always been a thing, but AI made it like a commodity, data that had to be collected,” Kilmer said. “Everybody wanted to monetize their own data pots, and how they monetize that is different across the board.”

Kilmer said many LLM-related scrapers rely on residential proxies in cases where the content provider has restricted access to their platform in some way, such as forcing interaction through an app, or keeping all content behind a login page with multi-factor authentication.

“Where the cost of data is out of reach — there is some exclusivity or reason they can’t access the data — they’ll turn to residential proxies so they look like a real person accessing that data,” Kilmer said of the content scraping efforts.

Aggressive AI crawlers increasingly are overloading community-maintained infrastructure, causing what amounts to persistent DDoS attacks on vital public resources. A report earlier this year from LibreNews found some open-source projects now see as much as 97 percent of their traffic originating from AI company bots, dramatically increasing bandwidth costs, service instability, and burdening already stretched-thin maintainers.

Cloudflare is now experimenting with tools that will allow content creators to charge a fee to AI crawlers to scrape their websites. The company’s “pay-per-crawl” feature is currently in a private beta, and it lets publishers set their own prices that bots must pay before scraping content.

On October 22, the social media and news network Reddit sued Oxylabs (PDF) and several other proxy providers, alleging that their systems enabled the mass-scraping of Reddit user content even though Reddit had taken steps to block such activity.

“Recognizing that Reddit denies scrapers like them access to its site, Defendants scrape the data from Google’s search results instead,” the lawsuit alleges. “They do so by masking their identities, hiding their locations, and disguising their web scrapers as regular people (among other techniques) to circumvent or bypass the security restrictions meant to stop them.”

Denas Grybauskas, chief governance and strategy officer at Oxylabs, said the company was shocked and disappointed by the lawsuit.

“Reddit has made no attempt to speak with us directly or communicate any potential concerns,” Grybauskas said in a written statement. “Oxylabs has always been and will continue to be a pioneer and an industry leader in public data collection, and it will not hesitate to defend itself against these allegations. Oxylabs’ position is that no company should claim ownership of public data that does not belong to them. It is possible that it is just an attempt to sell the same public data at an inflated price.”

As big and powerful as Aisuru may be, it is hardly the only botnet that is contributing to the overall broad availability of residential proxies. For example, on June 5 the FBI’s Internet Crime Complaint Center warned that an IoT malware threat dubbed BADBOX 2.0 had compromised millions of smart-TV boxes, digital projectors, vehicle infotainment units, picture frames, and other IoT devices.

In July, Google filed a lawsuit in New York federal court against the Badbox botnet’s alleged perpetrators. Google said the Badbox 2.0 botnet “compromised more than 10 million uncertified devices running Android’s open-source software, which lacks Google’s security protections. Cybercriminals infected these devices with pre-installed malware and exploited them to conduct large-scale ad fraud and other digital crimes.”

A FAMILIAR DOMAIN NAME

Brundage said the Aisuru botmasters have their own SDK, and for some reason part of its code tells many newly-infected systems to query the domain name fuckbriankrebs[.]com. This may be little more than an elaborate “screw you” to this site’s author: One of the botnet’s alleged partners goes by the handle “Forky,” and was identified in June by KrebsOnSecurity as a young man from Sao Paulo, Brazil.

Brundage noted that only systems infected with Aisuru’s Android SDK will be forced to resolve the domain. Initially, there was some discussion about whether the domain might have some utility as a “kill switch” capable of disrupting the botnet’s operations, although Brundage and others interviewed for this story say that is unlikely.

A tiny sample of the traffic after a DNS server was enabled on the newly registered domain fuckbriankrebs dot com. Each unique IP address requested its own unique subdomain. Image: Seralys.

For one thing, they said, if the domain was somehow critical to the operation of the botnet, why was it still unregistered and actively for-sale? Why indeed, we asked. Happily, the domain name was deftly snatched up last week by Philippe Caturegli, “chief hacking officer” for the security intelligence company Seralys.

Caturegli enabled a passive DNS server on that domain and within a few hours received more than 700,000 requests for unique subdomains on fuckbriankrebs[.]com.

But even with that visibility into Aisuru, it is difficult to use this domain check-in feature to measure its true size, Brundage said. After all, he said, the systems that are phoning home to the domain are only a small portion of the overall botnet.

“The bots are hardcoded to just spam lookups on the subdomains,” he said. “So anytime an infection occurs or it runs in the background, it will do one of those DNS queries.”

Caturegli briefly configured all subdomains on fuckbriankrebs dot com to display this ASCII art image to visiting systems today.

The domain fuckbriankrebs[.]com has a storied history. On its initial launch in 2009, it was used to spread malicious software by the Cutwail spam botnet. In 2011, the domain was involved in a notable DDoS against this website from a botnet powered by Russkill (a.k.a. “Dirt Jumper”).

Domaintools.com finds that in 2015, fuckbriankrebs[.]com was registered to an email address attributed to David “Abdilo” Crees, a 27-year-old Australian man sentenced in May 2025 to time served for cybercrime convictions related to the Lizard Squad hacking group.

Update, Nov. 1, 2025, 10:25 a.m. ET: An earlier version of this story erroneously cited Spur’s proxy numbers from earlier this year; Spur said those numbers conflated residential proxies — which are rotating and attached to real end-user devices — with “ISP proxies” located at AT&T. ISP proxies, Spur said, involve tricking an ISP into routing a large number of IP addresses that are resold as far more static datacenter proxies.