Kraken ransomware emerged in August 2025 as a focused, cross-platform threat that security teams can’t treat as “just another” family in the crowded ransomware ecosystem. From the beginning, operators behind Kraken aligned their tooling and targeting around large, complex environments that run a mix of Windows servers, Linux workloads, and VMware ESXi hypervisors. As a result, they immediately positioned themselves in the “big-game hunting” tier, where each successful intrusion can cripple an entire enterprise estate in a single campaign.
Researchers now link Kraken to the remnants of the HelloKitty ransomware cartel, and that heritage shows in both their tradecraft and their victim selection. The group moves deliberately, spends time understanding each victim’s environment, and then tunes its tooling so that encryption hits fast, hard, and with as little noise as possible. At the same time, Kraken operators lean heavily on double-extortion tactics, which combine destructive encryption with large-scale data theft and public shaming.
𝗙𝗿𝗼𝗺 𝗛𝗲𝗹𝗹𝗼𝗞𝗶𝘁𝘁𝘆 𝘁𝗼 𝗞𝗿𝗮𝗸𝗲𝗻: 𝗮 𝗿𝗮𝗻𝘀𝗼𝗺𝘄𝗮𝗿𝗲 𝗰𝗮𝗿𝘁𝗲𝗹 𝗲𝘃𝗼𝗹𝘂𝘁𝗶𝗼𝗻
Security analysts now treat Kraken as an evolution of the HelloKitty operation rather than a completely fresh crew. Instead of reusing code wholesale, the operators preserve the business model and relationships while modernizing their tooling. They reuse familiar elements such as ransom note naming conventions and branding themes, and they reinforce the lineage through explicit references on their leak infrastructure. This approach helps them carry existing criminal reputation forward while projecting a “new” brand that feels more relevant to today’s victims.
Kraken runs a dedicated leak site where the group posts company names, sample data, and negotiation pressure updates. The site reinforces their HelloKitty heritage through text, structure, and references that experienced analysts recognize quickly. At the same time, it signals that Kraken plans to operate as a long-term player with a proper data-leak operation, not as a short-lived smash-and-grab crew.
The ransom note also continues this continuity theme. Kraken drops a file with a characteristic name in impacted directories and uses direct, business-like language that assumes the victim runs a sizable enterprise environment. The note typically references data theft, public release risk, and a negotiation process that runs through Tor-based infrastructure controlled by the group.
𝗠𝘂𝗹𝘁𝗶-𝘀𝘁𝗮𝗴𝗲 𝗶𝗻𝘁𝗿𝘂𝘀𝗶𝗼𝗻𝘀 𝗮𝗻𝗱 𝗦𝗠𝗕-𝗰𝗲𝗻𝘁𝗿𝗶𝗰 𝗶𝗻𝗶𝘁𝗶𝗮𝗹 𝗮𝗰𝗰𝗲𝘀𝘀
Kraken campaigns follow a multi-stage intrusion pattern that looks very familiar to defenders who track modern big-game ransomware. Operators commonly start from externally exposed assets, and many observed intrusions begin with the exploitation of vulnerable SMB services on internet-facing servers. That initial foothold gives them direct access into environments where legacy protocols, flat networks, and weak segmentation still exist.
Once they establish a beachhead, Kraken operators quickly pivot into credential theft. They harvest privileged accounts, reuse them through Remote Desktop Protocol, and then spread laterally to other systems that share trust boundaries or credentials. Because they operate with domain-level or local-admin privileges, they can deploy additional tooling with very little friction and then shape the environment in ways that favor prolonged operations.
To maintain a durable presence, the group often deploys 𝗖𝗹𝗼𝘂𝗱𝗳𝗹𝗮𝗿𝗲𝗱 tunnels and 𝗦𝗦𝗛𝗙𝗦-based mounts. Cloudflared gives them stable reverse tunnels that route traffic through Cloudflare infrastructure instead of direct attacker IP space, while SSHFS mounts provide stealthy exfiltration channels that look like normal file operations. As a result, the team can exfiltrate data over encrypted tunnels, avoid noisy direct exfiltration paths, and keep access even if perimeter rules change during the incident.
𝗘𝗻𝗰𝗿𝘆𝗽𝘁𝗶𝗼𝗻 𝗯𝗲𝗻𝗰𝗵𝗺𝗮𝗿𝗸𝗶𝗻𝗴: 𝘀𝗲𝗹𝗲𝗰𝘁𝗶𝗻𝗴 𝗳𝘂𝗹𝗹 𝘃𝘀 𝗽𝗮𝗿𝘁𝗶𝗮𝗹 𝗲𝗻𝗰𝗿𝘆𝗽𝘁𝗶𝗼𝗻
One capability that makes Kraken stand out from the average ransomware family is its use of 𝗲𝗻𝗰𝗿𝘆𝗽𝘁𝗶𝗼𝗻 𝗯𝗲𝗻𝗰𝗵𝗺𝗮𝗿𝗸𝗶𝗻𝗴. Before encrypting real data, the binary creates a temporary file containing random content, runs a timed encryption operation, and calculates how long encryption takes on that specific machine. Afterward, it deletes the temporary file and selects between full or partial encryption based on the benchmark result.
This logic matters for two reasons. First, it lets operators tailor the impact to each victim system, keeping encryption fast enough to complete but slow enough to avoid obvious resource spikes that might trigger alerts. Second, it means the same binary behaves differently on a high-end ESXi hypervisor compared to a mid-range Windows file server, which complicates static playbook-style detection. Security teams need to watch for this kind of pre-encryption behavior, not just for the final bulk encryption wave.
𝗖𝗿𝘆𝗽𝘁𝗼𝗴𝗿𝗮𝗽𝗵𝘆 𝗮𝗻𝗱 𝗰𝗼𝗺𝗺𝗮𝗻𝗱-𝗹𝗶𝗻𝗲 𝗳𝗹𝗲𝘅𝗶𝗯𝗶𝗹𝗶𝘁𝘆 𝗶𝗻 𝗪𝗶𝗻𝗱𝗼𝘄𝘀 𝗲𝗻𝘃𝗶𝗿𝗼𝗻𝗺𝗲𝗻𝘁𝘀
On Windows, Kraken relies on a mix of 𝗥𝗦𝗔-𝟰𝟬𝟵𝟲 and 𝗖𝗵𝗮𝗖𝗵𝗮𝟮𝟬 to encrypt data with modern cryptographic strength. Operators call the binary with explicit parameters that define the target path, encryption depth, and behavior on different file types. A typical syntax takes the form of a dedicated encryptor executable followed by a 32-byte key argument, path specification, and timing or throttling options.
Kraken does not simply walk the filesystem blindly. Instead, it focuses aggressively on 𝗦𝗤𝗟 𝗱𝗮𝘁𝗮𝗯𝗮𝘀𝗲𝘀, 𝗻𝗲𝘁𝘄𝗼𝗿𝗸 𝘀𝗵𝗮𝗿𝗲𝘀, and local volumes that hold business-critical data. The malware enumerates SQL Server instances, resolves database file directories, validates paths, and then encrypts the underlying data files. It scans mapped shares, intentionally ignores administrative shares such as ADMIN$ and IPC$, and encrypts user-accessible shares that impact day-to-day operations. At the same time, it avoids core system directories and program files so that systems remain bootable and usable enough to negotiate.
On local drives, Kraken runs multi-threaded workers that handle different drive types in parallel. While those workers operate, the malware also removes shadow copies, clears the recycle bin, and stops backup-related services. That combination leaves organizations with fewer native recovery options, pushes them toward offline or immutable backups, and increases the pressure to pay.
𝗘𝗟𝗙 𝗲𝗻𝗰𝗿𝘆𝗽𝘁𝗼𝗿𝘀 𝗳𝗼𝗿 𝗟𝗶𝗻𝘂𝘅 𝗮𝗻𝗱 𝗩𝗠𝘄𝗮𝗿𝗲 𝗘𝗦𝗫𝗶
Kraken’s Linux and VMware ESXi encryptors arrive as ELF binaries compiled specifically for those platforms. Operators can run them in 𝗱𝗮𝗲𝗺𝗼𝗻 𝗺𝗼𝗱𝗲, launch them through SSH, or integrate them into existing hands-on-keyboard workflows. In ESXi environments, the malware enumerates virtual machines, terminates them to unlock their virtual disk files, and then runs multi-threaded encryption over each datastore.
Because ESXi sits underneath dozens or hundreds of guest workloads, a single Kraken run on a compromised hypervisor can simultaneously impact application servers, databases, domain controllers, and line-of-business services. That blast radius makes ESXi-level defense and segmentation a critical control surface when dealing with cross-platform groups like Kraken.
On Linux file servers or application hosts, Kraken applies the same benchmark-driven logic as on Windows. It decides how aggressively to encrypt based on each host’s performance, and it focuses on business data directories instead of system binaries. After the run completes, a cleanup script removes logs, shell history, and the ransomware binary itself, which reduces artifacts available for forensics and hinders straightforward root-cause analysis.
𝗕𝗶𝗴-𝗴𝗮𝗺𝗲 𝗵𝘂𝗻𝘁𝗶𝗻𝗴, 𝗱𝗼𝘂𝗯𝗹𝗲 𝗲𝘅𝘁𝗼𝗿𝘁𝗶𝗼𝗻, 𝗮𝗻𝗱 𝗹𝗲𝗮𝗸-𝘀𝗶𝘁𝗲 𝗽𝗿𝗲𝘀𝘀𝘂𝗿𝗲
Kraken’s operators clearly focus on enterprise-class victims. Public leak-site entries and open reporting show victims in multiple regions, including North America and Europe, with sectors ranging from retail and technology to services and industrial operations. The group follows the now-standard double-extortion model: they first exfiltrate sensitive data, then encrypt production systems, and finally threaten to publish stolen data if the victim refuses to pay.
Because Kraken can hit Windows infrastructure, Linux servers, and ESXi hypervisors in the same campaign, the group can disrupt not only core IT but also virtualization stacks and database tiers in one coordinated strike. That cross-platform reach changes the risk calculation for many organizations that historically treated ESXi or Linux as “less likely ransomware targets” compared to Windows file servers.
𝗛𝗼𝘄 𝗞𝗿𝗮𝗸𝗲𝗻 𝗰𝗵𝗮𝗻𝗴𝗲𝘀 𝘆𝗼𝘂𝗿 𝗽𝗿𝗶𝗼𝗿𝗶𝘁𝗶𝗲𝘀 𝗮𝘀 𝗮 𝗱𝗲𝗳𝗲𝗻𝗱𝗲𝗿
For defenders, Kraken forces a shift away from a Windows-only ransomware mindset. Security teams must now assume that any reachable platform in the environment can become part of the same attack path. Therefore, hardening efforts need to cover:
• 𝗦𝗠𝗕 𝘀𝘂𝗿𝗳𝗮𝗰𝗲𝘀 – closing legacy SMB versions, restricting internet-exposed SMB, and monitoring for abnormal authentication patterns.
• 𝗥𝗗𝗣 𝗮𝗰𝗰𝗲𝘀𝘀 – limiting RDP to jump hosts, enforcing MFA, and watching for lateral RDP pivoting from unusual hosts.
• 𝗩𝗺𝘄𝗮𝗿𝗲 𝗘𝗦𝗫𝗶 – removing direct internet exposure for management interfaces, tightening access control, and validating backup coverage outside the hypervisor.
• 𝗞𝗲𝘆 𝗱𝗮𝘁𝗮 𝘁𝗶𝗲𝗿𝘀 – mapping where SQL databases, shared file repositories, and VM disk files truly live, and applying stronger controls and backup guarantees there.
To keep the guidance actionable, it helps to align defensive work with existing best-practice material. For example, organizations can fold Kraken-specific concerns into broader ransomware programs based on CISA’s StopRansomware guidance and SMB security best practices. At the same time, they can leverage ESXi-specific hardening and recovery guidance from VMware, national CSIRTs, and specialist vendors that focus on virtualized infrastructure.
𝗣𝗿𝗮𝗰𝘁𝗶𝗰𝗮𝗹 𝗺𝗶𝘁𝗶𝗴𝗮𝘁𝗶𝗼𝗻 𝗺𝗼𝘃𝗲𝘀 𝗮𝗴𝗮𝗶𝗻𝘀𝘁 𝗞𝗿𝗮𝗸𝗲𝗻
Security teams that want to reduce their exposure to Kraken and similar cross-platform crews can focus on a few practical moves. First, they can treat 𝗶𝗻𝘁𝗲𝗿𝗻𝗲𝘁-𝗳𝗮𝗰𝗶𝗻𝗴 𝗦𝗠𝗕 and misconfigured remote-access services as emergency-level issues. That means patching known SMB vulnerabilities, disabling deprecated protocol versions, and segmenting any remaining SMB capability so that direct exposure becomes impossible.
Second, they can clamp down on 𝗵𝗶𝗴𝗵-𝗽𝗿𝗶𝘃𝗶𝗹𝗲𝗴𝗲𝗱 𝗮𝗰𝗰𝗼𝘂𝗻𝘁𝘀, especially those with rights over ESXi, domain controllers, and central file servers. That includes enforcing MFA, using just-in-time elevation, and aggressively rotating credentials after suspected compromise.
Third, they can elevate 𝗲𝗻𝘁𝗲𝗿𝗽𝗿𝗶𝘀𝗲 𝗯𝗮𝗰𝗸𝘂𝗽 and recovery readiness from a box-ticking exercise to a tested, time-bound operation. Kraken’s behavior around shadow copies and backup services makes it clear that the group understands how organizations recover. Therefore, defenders need immutable backups, off-hypervisor restore options, and rehearsed runbooks that show exactly how long it takes to restore critical services from clean data.
Finally, they can expand 𝗱𝗲𝘁𝗲𝗰𝘁𝗶𝗼𝗻 𝗿𝘂𝗹𝗲𝘀 around Cloudflared, SSHFS, and suspicious RDP patterns. Because Kraken leans on those tools for persistence and exfiltration, defenders who monitor for “weird but legal” usage of remote tunneling and SSH-based filesystems gain early-warning opportunities before encryption fires.
𝗪𝗵𝗮𝘁 𝘆𝗼𝘂𝗿 𝘁𝗲𝗮𝗺 𝘀𝗵𝗼𝘂𝗹𝗱 𝗱𝗼 𝗻𝗼𝘄
In practical terms, security leaders can use Kraken as a forcing function. They can ask their teams direct questions:
Do we still expose SMB or ESXi management interfaces to the internet?
Do we know which systems hold our most business-critical data, and do they sit behind stronger controls?
Can we restore our core services from clean backups within a time window that the business actually finds acceptable?
If the answers remain uncertain, Kraken’s cross-platform capabilities and benchmark-driven encryption model should push those topics to the top of the security agenda. The group operates like a disciplined, technically capable successor to HelloKitty, and its focus on Windows, Linux, and VMware ESXi at the same time makes it a credible threat for any modern enterprise that relies on virtualization and mixed operating systems at scale.
𝗙𝗔𝗤s
Q: What makes Kraken different from typical Windows-only ransomware?
A: Kraken targets Windows, Linux, and VMware ESXi simultaneously, and it uses features like encryption benchmarking, Cloudflared tunnels, and SSHFS-based exfiltration to tune each attack to the victim’s environment.
Q: Why does Kraken care about SMB vulnerabilities?
A: SMB exploitation gives Kraken operators a direct path into exposed servers and lets them escalate quickly inside flat networks that still rely on legacy protocols and weak segmentation.
Q: How dangerous is Kraken for ESXi environments?
A: Kraken’s ELF encryptors can stop running virtual machines, encrypt their virtual disks, and impact dozens of dependent workloads at once, which turns a single compromised hypervisor into a multi-service outage.
Q: What data does Kraken prioritize when encrypting?
A: Kraken focuses on SQL databases, user and application file shares, and VM disk files, while avoiding system directories so that systems remain bootable enough for ransom negotiations.
Q: What should defenders prioritize to reduce Kraken risk?
A: Defenders should prioritize patching SMB, restricting RDP, hardening ESXi management interfaces, strengthening backup and recovery, and detecting unusual use of Cloudflared tunnels and SSHFS in their environment.
