Your Tools, Their Rules: Kibana Became a Hit List

There is a particular kind of irony that only exists in cybersecurity. A SIEM -- a Security Information and Event Management platform -- is purpose-built to help defenders see everything happening across their environment. Every compromised host, every anomalous process, every lateral movement attempt surfaces in the dashboard. It is, at its core, a tool for maintaining situational awareness at scale. What happens when an attacker builds one?

Not metaphorically. Literally. An attacker signed up for a free trial, provisioned a fully functional Elasticsearch deployment on Google Cloud infrastructure, and used Kibana's Discover interface to query, filter, and sort through stolen system data from compromised organizations across multiple continents -- the same way a security analyst would. They filtered out standalone workstations. They prioritized domain-joined servers. They zeroed in on organizations where multiple hosts were already compromised and where the hostnames suggested domain controllers were already within reach. They spent an estimated 249 minutes doing this work over the course of a week, logging hundreds of Kibana actions while the index grew.

The index had a name. It was called systeminfo. It held data on 216 victim hosts across 34 organizations spanning 37 time zones -- government agencies, financial services firms, higher education institutions, manufacturers, IT service providers. The attacker did not need to build custom infrastructure to understand what they had. They used a product designed for exactly this kind of analysis, available to anyone with an email address and a willingness to click through a free trial signup.

This is what researchers at Huntress uncovered in a two-part investigation published in February and March 2026 -- the first documented case of an adversary using Elastic Cloud for data exfiltration and victim triage. The campaign began with the exploitation of critical vulnerabilities in SolarWinds Web Help Desk (WHD), progressed through a layered chain of legitimate tools for persistence and command-and-control, and culminated in a centralized cloud-based victim management operation that the attacker ran until Huntress knocked on Elastic's door. The infrastructure has since been taken down following coordination between Huntress, Elastic, and law enforcement.

The technical details of how the attacker got in matter -- and this article covers them -- but the more important question is what this campaign reveals about the assumptions the security industry has been quietly making for years: that powerful tools in the right hands are protection, and powerful tools in the wrong hands are an aberration. This campaign suggests the line between the two is a lot thinner than a free trial signup form.

Initial Access: SolarWinds Web Help Desk Exploitation

The campaign traces back to the active exploitation of SolarWinds Web Help Desk, an IT service management platform that has accumulated a troubling record of critical vulnerability disclosures. Three flaws are central to this campaign: CVE-2025-40551, a critical deserialization of untrusted data vulnerability allowing unauthenticated remote code execution (discovered by Jimi Sebree of Horizon3.ai); CVE-2025-40536, a high-severity authentication bypass enabling access to restricted functionality (also discovered by Sebree); and CVE-2025-26399, a separate deserialization-based RCE flaw disclosed in September 2025. The January 2026 advisory also introduced critical authentication bypass flaws CVE-2025-40552 and CVE-2025-40554, plus a critical deserialization RCE CVE-2025-40553, all three discovered by Piotr Bazydlo of watchTowr. CVE-2025-40551 was added to CISA's Known Exploited Vulnerabilities (KEV) catalog on February 3, 2026, with Federal Civilian Executive Branch agencies ordered to apply fixes by February 6, 2026; CVE-2025-40536 followed on February 12, 2026. CVE-2025-26399 was fixed in version 12.8.7 HF1 (September 2025), while the January 2026 cluster -- CVE-2025-40551 through CVE-2025-40554 -- affects all versions through 12.8.8 HF1 and requires upgrading to version 2026.1. An organization that applied 12.8.7 HF1 at the time of CVE-2025-26399's disclosure remained fully exposed to the newer cluster until they completed the 2026.1 upgrade.

CVE-2025-26399 deserves particular attention because it is not a new class of vulnerability -- it is a third-generation patch bypass. It bypasses CVE-2024-28988, which itself bypassed CVE-2024-28986. Both predecessors were exploited in the wild after their disclosures and added to CISA's KEV catalog. CVE-2025-26399 was added to CISA's KEV catalog on March 9, 2026, with a remediation due date of March 12, 2026 for FCEB agencies -- confirming active exploitation in the wild. This lineage matters because it illustrates a compounding problem: each time a vendor patches a deserialization flaw in a Java-based application like WHD's AjaxProxy component, researchers and threat actors alike probe the new fix for bypass opportunities. The exploit chain -- specifically the technique of adding a fake URI parameter containing /ajax/ to circumvent CSRF validation -- is a textbook example of partial remediation failing to address the underlying architectural weakness. Organizations that patched for CVE-2024-28988 but did not apply the subsequent 12.8.7 HF1 hotfix remained silently vulnerable for months before active exploitation began in late 2025.

On February 7, 2026, Huntress SOC analyst Dipo Rodipe investigated a case of SolarWinds WHD exploitation across multiple customer environments. According to Huntress, 84 endpoints across 78 organizations within their partner base were running SolarWinds Web Help Desk at the time of the investigation. Microsoft's Defender Security Research Team independently confirmed related exploitation activity in a February 6 advisory -- though notably, Microsoft acknowledged it could not determine which specific CVE was used in the earliest observed cases, because those attacks occurred in December 2025 on machines that were vulnerable to both the older and newer CVE sets simultaneously. That ambiguity is a useful reminder that all three CVEs should be addressed together. CVE-2025-26399 was fixed in 12.8.7 HF1 in September 2025, but the full January 2026 cluster -- CVE-2025-40551, CVE-2025-40552, CVE-2025-40553, CVE-2025-40554, CVE-2025-40536, and CVE-2025-40537 -- requires upgrading to version 2026.1. Organizations that applied the earlier hotfix should not assume they are protected against the full cluster without completing the 2026.1 upgrade.

The Attack Chain: From Help Desk to Full Compromise

The attack chain followed a methodical progression. After achieving initial code execution through the WHD vulnerabilities, the threat actor used the WHD service wrapper process (wrapper.exe) to spawn java.exe, which then launched cmd.exe to silently install a remote MSI payload hosted on the Catbox file-sharing service. This payload delivered a Zoho ManageEngine RMM agent (Zoho Assist), giving the attacker persistent remote access to the compromised environment.

Once the RMM agent was active, the attacker pivoted to hands-on-keyboard activity. Using the Zoho RMM process (TOOLSIQ.EXE) as their execution context, they initiated Active Directory reconnaissance, enumerating domain-joined systems to map the network and identify high-value targets such as domain controllers. The Zoho Assist agent had been configured for unattended access and registered to a Zoho account tied to a Proton Mail address (esmahyft@proton[.]me), providing persistent remote access without requiring an interactive login session. This is a classic precursor to lateral movement.

The next step was deploying Velociraptor, an open-source digital forensics and incident response (DFIR) tool, via another silent MSI installer hosted on an attacker-controlled Supabase storage bucket. Notably, the attacker used Velociraptor version 0.73.4, a deliberately outdated build that carries CVE-2025-6264, a privilege escalation vulnerability in the Admin.Client.UpdateClientConfig artifact. The flaw, discovered by Christian Fünfhaus of Deutsche Bahn CSIRT and patched by Rapid7 on June 18, 2025, allows users with COLLECT_CLIENT permissions to trigger the artifact without the higher EXECVE permission that should be required -- enabling configuration updates that can lead to arbitrary command execution. CISA initially added CVE-2025-6264 to its KEV catalog in October 2025 but subsequently removed it after Rapid7 clarified that the vulnerability was not directly exploited in observed incidents -- attackers had already gained access before deploying the outdated Velociraptor build. Christiaan Beek, Rapid7's senior director of threat analytics, described the pattern as misuse rather than a software flaw, noting that adversaries were repurposing legitimate collection and orchestration capabilities. Regardless, the consistent choice of version 0.73.4 -- a build that predates the June 2025 patch -- is a documented fingerprint: Sophos's Counter Threat Unit first documented Velociraptor abuse in an August 2025 investigation, and Cisco Talos confirmed in October 2025 that the same version 0.73.4.0 build appeared in ransomware attacks attributed to Storm-2603. Fortra also documented the same qgtxtebl Cloudflare Worker account being used in a separate December 2025 intrusion via a WSUS RCE vulnerability -- each time deploying Velociraptor from the identical staging infrastructure. The version number is not coincidence: it is a calling card.

In addition to Velociraptor, the attacker also established persistence via a scheduled task named TPMProfiler. While legitimate Windows tasks beginning with "TPM" exist, Huntress noted this specific name has only been observed in malicious contexts across their telemetry. The TPMProfiler task was used to open an SSH backdoor via QEMU, the open-source machine emulator, which served as a secondary persistence mechanism. The earliest known instance of this component was installed on January 16, 2026, at 21:24:40 UTC -- predating the February 7 investigation date by several weeks and suggesting the campaign was well underway before Huntress began their formal analysis.

The Velociraptor client communicated with attacker infrastructure hosted behind a Cloudflare Worker at auth.qgtxtebl.workers[.]dev. The qgtxtebl identifier in the subdomain is significant: this shared per-account Cloudflare identifier has been observed across multiple prior intrusions involving ToolShell exploitation and Warlock ransomware deployment. Huntress documented it in their own prior Velociraptor misuse investigations; Fortra documented the same identifier in a December 2025 WSUS-based attack; and Cisco Talos cited it in connection with confirmed Storm-2603 activity in October 2025. Each time, the staging infrastructure follows the same pattern: Velociraptor MSI from a qgtxtebl.workers.dev subdomain, followed by VS Code tunnel setup, followed by Cloudflared as a fallback egress path.

With Velociraptor running as a Windows service, the attacker executed a rapid sequence of base64-encoded PowerShell commands. These included disabling Windows Defender and Windows Firewall via registry modifications to HKLM\SOFTWARE\Policies\Microsoft\Windows Defender and the Windows Firewall service key. The attacker then downloaded a copy of the Visual Studio Code binary from Microsoft's official servers and configured it as a tunnel-based access channel, exploiting VS Code's legitimate remote development feature as a C2 path. This same VS Code tunneling technique was documented by Sophos CTU in the August 2025 incident where Velociraptor abuse was first publicly reported -- the attacker pattern has not changed materially since then. This was followed by installing Cloudflared from GitHub's official release channel, creating an additional tunnel that provided redundancy. The cumulative effect was a layered C2 architecture: Velociraptor for tasking, VS Code for interactive access, and Cloudflared as a fallback egress path -- all using software a network defender might reasonably consider benign.

C2 Failover Mechanism

The attacker also implemented a signal-based C2 migration scheme that Huntress described in their analysis. An HTTP 406 response from the operator's failover server acted as a trigger signal meaning "the worker.dev domain is burned, switch to the backup." If the endpoint returned anything other than a 406, or was unreachable, the Velociraptor configuration stayed unchanged and the agent continued communicating with the original Cloudflare Workers domain. This gave the operator the ability to dynamically rotate C2 infrastructure across their entire fleet of compromised hosts by simply toggling a single HTTP response code on the failover server.

The Elastic Cloud SIEM Abuse

Here is where this campaign diverges from conventional attack patterns. Rather than building custom exfiltration infrastructure or relying on traditional C2 data collection, the attacker signed up for an Elastic Cloud free trial and used the platform as a centralized repository for stolen victim data.

The exfiltration worked through a straightforward mechanism: an encoded PowerShell command executed on each compromised host ran the Get-ComputerInfo cmdlet to collect detailed system information -- operating system version, hardware specifications, Active Directory domain membership, installed patches, and general host metadata -- and then pushed that data directly to an attacker-controlled Elasticsearch index named systeminfo using a hardcoded API key embedded in the script.

# Attacker exfiltration pattern (simplified)
# Encoded PowerShell -> Get-ComputerInfo -> Elastic Cloud Bulk API
powershell.exe -ExecutionPolicy Unrestricted -encodedCommand [base64]
# Decoded: Collects OS version, hardware, AD domain, patches
# Pushes to Elastic Cloud index "systeminfo" via hardcoded API key

The Elastic Cloud deployment was created on January 28, 2026 at 01:45 UTC under cloud account u_706752903_cloud, with deployment ID 7c00a38569a8471083b6b34e1511b9de. It was running Elasticsearch version 9.2.4 on Google Cloud Platform's us-central1 region. In a detail that speaks to operational laziness rather than sophistication, the deployment used the default naming: "My deployment."

Huntress described the novelty of the technique in their Part 2 report: this was the first time their team had observed an adversary using Elastic Cloud for exfiltration. As Huntress stated:

While we have previously seen threat actors leveraging Velociraptor and other DFIR-focused tools for command and control, this was the first time we observed an adversary use Elastic Cloud for exfiltration. The attacker prepared their own Elastic Cloud free trial, using legitimate Elastic infrastructure, using it as a repository for stolen data across intrusions. They could then triage their victims and compromised endpoints, literally using SIEM technology.

Rather than raw data dumps into anonymous infrastructure, the attacker was actively triaging victim machines using the same tools defenders use to hunt threats.

Using Kibana to Triage Victims

The attacker did not just dump data and walk away. Telemetry from the Elastic Cloud Kibana sessions showed the operator repeatedly interacting with the environment, logging hundreds of actions while examining incoming victim data. In total, Huntress estimated the attacker spent approximately 249 minutes between January 28 and February 4, 2026, running queries through Kibana's Discover interface. They created and saved a Kibana search query named "oooo" on February 4, 2026. This saved search specifically selected columns for victim domain name, system caption, timezone, and IP addresses. Crucially, the operator filtered out standalone workstations and focused on domain-joined machines -- a deliberate triage action that indicates the attacker was looking for high-value enterprise networks, not random endpoints.

One victim domain drew particular attention. The attacker's Kibana filter revealed they were focused on an organization with 6 servers already compromised, including one hostname suggesting it was a domain controller. Huntress believes this targeted organization was an AI-powered SaaS platform.

Scale of the Campaign: 216 Hosts, 34 Organizations, 37 Time Zones

The systeminfo index contained approximately 216 unique victim hosts at the time of Huntress's analysis. The data revealed a campaign of global scope:

• 91% of compromised machines were servers, with the majority running Windows Server 2019 or Windows Server 2022.
• Among the 47 domain-joined machines, Huntress identified 34 unique Active Directory domains representing distinct organizations.
• Affected sectors included government agencies, higher education institutions, financial services, religious and nonprofit organizations, global manufacturing and automotive companies, IT service providers, retail, and construction.
• Victims spanned 37 different time zones across multiple continents, pointing to an indiscriminate, opportunistic targeting approach.

Hostnames within the victim dataset also pointed to ongoing exploitation of other high-severity vulnerabilities beyond SolarWinds WHD. Huntress identified signs of compromise in systems running Gladinet CentreStack, SmarterMail/SmarterTools, and evidence of intrusions against Microsoft SharePoint installations. This suggests the actor was continuously scanning for and exploiting whatever enterprise software had a critical, immediately exploitable weakness.

Attacker OPSEC: Disposable Emails, VPN Tunnels, and Attribution

The threat actor's operational security showed a mix of deliberate tradecraft and sloppy mistakes. The Elastic Cloud trial account was registered using a disposable email address linked to the domain quieresmail.com. Huntress traced this to the Russian-registered temporary email network firstmail.ltd, which operates hundreds of throwaway email domains. Administrative logins to the SIEM instance were traced to IP addresses believed to originate from a SAFING VPN privacy network tunnel.

The attacker also reused random eight-character identifiers across their infrastructure, including both email registrations and subdomains used to host tooling on Cloudflare Worker pages. This reuse, while operationally efficient for the attacker, created a forensic fingerprint that allowed Huntress to connect different parts of the campaign infrastructure together.

Among the 216 records in the Elastic index, a cluster of four hosts stood out as likely test virtual machines operated by the attacker themselves. These hosts -- with randomized eight-character names like Hajbepfy, Bekpaseb, Hhbhymne, and Vdfyivhy -- shared an identical custom SMBIOS build string fingerprint, distinguishing them from genuine victim machines and providing additional forensic evidence about the attacker's own environment.

Huntress made no formal threat group attribution in their published report. However, Jamie Levy, senior director of adversary tactics at Huntress, told Cybersecurity Dive that the team believes the actor behind this campaign is Storm-2603. John Hammond, Huntress Principal Security Researcher, separately told CSO Online:

We believe that the actor behind this is Storm-2603, since indicators are very similar to what we saw in prior incidents which were confirmed as tied to Storm-2603. Normally these types of incidents would have led to Warlock ransomware, but in this case, it seems as if the attackers were still in reconnaissance mode since their main objectives appeared to be to collect system information from as many victims as possible.

That attribution is supported by a substantial body of independent research. The group is tracked as GOLD SALEM by Sophos (whose CTU team also confirmed the Velociraptor-to-VS Code tunnel technique to Dark Reading), as CL-CRI-1040 by Palo Alto Networks Unit 42, and has been analyzed in depth by Check Point Research, Halcyon, Trustwave SpiderLabs, and ReliaQuest, among others.

The group's tool set includes the custom AK47 C2 framework (tracked as Project AK47 by Check Point and Unit 42), which supports both HTTP and DNS-based backdoor clients. Its ransomware arsenal spans Warlock (also known as X2anylock), LockBit Black, and Babuk. Halcyon's technical analysis established that the multi-family deployment strategy was intentional from the group's earliest prototypes -- not a later adaptation -- with the goal of confusing attribution, evading detection, and accelerating impact. The group registered as a LockBit affiliate under the username wlteaml just before the LockBit infrastructure suffered a data leak in May 2025, then publicly launched the Warlock brand in June 2025. Infrastructure for the AK47 framework was established by March 2025, making this one of the more thoroughly documented threat actor timelines in recent memory across the vendor community. Microsoft assesses Storm-2603 as China-based with moderate confidence. Sophos CTU separately assesses -- with low confidence -- that GOLD SALEM is at least partially composed of Chinese individuals, citing shared TTPs with Chinese threat groups and use of drivers from Chinese security vendors Baidu Antivirus and Antiy Labs. Halcyon raised the China assessment to high confidence based on the group's early access to ToolShell zero-days shared only with known Chinese APT groups Linen Typhoon and Violet Typhoon, and compile-time artifacts that align with China Standard Time.

Storm-2603 came to wider attention through the ToolShell exploit chain targeting Microsoft SharePoint (CVE-2025-49704, CVE-2025-49706, CVE-2025-53770, CVE-2025-53771) in mid-2025. That prior activity is directly relevant here. The Safing Privacy Network (SPN) exit node IP address 51.161.152.26 -- used to authenticate to the attacker's Elastic Cloud SIEM -- was independently flagged by Palo Alto Networks Unit 42 in July 2025 in connection with that ToolShell campaign against Microsoft SharePoint. Unit 42's Project AK47 research documents this IP in the context of CL-CRI-1040 activity -- the same cluster Unit 42 assesses with high confidence to represent Storm-2603. The shared qgtxtebl Cloudflare Worker per-account identifier reinforces this linkage: Huntress first documented it in their December 2025 Velociraptor misuse report, Fortra documented it in a December 2025 WSUS attack, and Cisco Talos cited it in October 2025 Storm-2603 ransomware attribution. Infrastructure reuse of this kind -- the same VPN exit node, the same Cloudflare account identifier, the same Velociraptor version -- provides the kind of durable forensic linkage that survives tool rotation and tradecraft variation.

Takedown and Victim Notification

Huntress deliberately staged their disclosure into two parts to allow time for multi-agency coordination. Part 1, published on February 8, 2026, covered the SolarWinds WHD exploitation mechanics. Part 2, published on March 6, 2026, detailed the Elastic Cloud SIEM abuse and the broader campaign infrastructure. Between the two publications, Huntress coordinated with Elastic, law enforcement, and Lumen Technologies' Black Lotus Labs.

Huntress confirmed in their report that they performed direct outreach and victim notification to organizations identified in the exposed data:

We have performed outreach and victim notification to organizations that we believe were indicated within the uncovered data, and we have coordinated with Elastic in a collaborative effort to further investigate and take down this threat actor infrastructure.

Elastic has since taken the malicious cloud instance offline.

What This Means for Defenders

This campaign represents an evolution of the "living off the land" approach that has dominated offensive tradecraft for years. Attackers have long abused legitimate system binaries (LOLBins) to evade endpoint detection. This case extends that philosophy into cloud infrastructure -- call it living off the cloud. The attacker used legitimate SaaS platforms at every stage: Catbox for payload hosting, Supabase for malware staging, Cloudflare Workers for C2 proxying, and Elastic Cloud for data exfiltration and victim triage. None of these services are inherently malicious, and traffic to all of them would appear normal in network logs.

The Ransomware Question: What Comes Next

This is a question the article cannot fully answer yet -- and that is exactly why it matters. Both Jamie Levy and John Hammond at Huntress noted that campaigns linked to Storm-2603 normally progress to Warlock ransomware deployment. That assessment is consistent with what other vendors have documented. ReliaQuest, in a February 2026 report, identified active Storm-2603 exploitation of a SmarterMail vulnerability (CVE-2026-23760) leading directly to Warlock staging -- a separate intrusion campaign running in parallel with the SolarWinds activity and targeting different software. That parallel exploitation pattern -- SolarWinds here, SmarterMail there, SharePoint elsewhere -- is consistent with the opportunistic, scan-and-exploit approach visible in the victim index data itself.

In this campaign, the attacker was still in the reconnaissance and victim triage phase when the infrastructure was taken offline. That means organizations in the systeminfo index who have not yet fully remediated should treat this as an active threat, not a historical one. The 216 compromised hosts represent a curated pre-attack target list. The operator filtered for domain-joined servers, identified high-priority organizations, and had visibility into patch levels on every machine -- that is not reconnaissance for its own sake, it is pre-attack preparation. The fact that Elastic took the infrastructure offline does not mean the attacker's knowledge of those environments disappeared with it.

Storm-2603's known ransomware pattern is worth understanding precisely because it informs what a follow-on payload would look like in practice. Cisco Talos documented in October 2025 that confirmed Storm-2603 operators deployed Warlock, LockBit, and Babuk in the same engagement, encrypting both VMware ESXi virtual machines and Windows servers simultaneously. Halcyon's analysis established that this multi-family deployment was planned from the group's earliest April 2025 prototypes -- the same MSI package that drops LockBit also drops Warlock, with a built-in expiration date and deliberate attribution confusion as design goals. Ransomware deployment in Storm-2603 operations typically uses GPO-based mass distribution, meaning a single authenticated push from a domain controller can encrypt an entire organization in one operation. The Kibana-filtered victim list -- specifically tuned to domain-joined machines, filtered for servers, prioritizing organizations with multiple compromised hosts -- is precisely the kind of pre-attack asset inventory that makes GPO-based mass encryption operationally viable.

The SaaS Vendor Accountability Gap

This campaign puts a sharp question on the table that the industry has largely avoided: at what point does a SaaS vendor bear responsibility for abuse of its free-tier infrastructure? Elastic is not the first vendor whose tooling has been weaponized -- GitHub, Cloudflare, Supabase, and Catbox all played roles in this campaign. What is unusual is that the attacker used Elastic's own security intelligence platform as their central command post. A trial account, registered with a disposable email, was sufficient to provision a fully functional Elasticsearch deployment on GCP infrastructure.

The conventional response is to say vendors cannot be expected to police all misuse of their platforms. But that framing sidesteps a narrower and more answerable question: should a SIEM vendor's trial onboarding be able to detect when an account is ingesting hundreds of records of stolen system profile data from dozens of organizations across 37 time zones? That pattern is not consistent with evaluating a SIEM for legitimate use. Behavioral anomaly detection on trial accounts -- particularly for data ingestion volume, geographic diversity of source data, and data field signatures consistent with bulk system reconnaissance -- is technically feasible and represents a gap the industry should close. Elastic's response to Huntress's notification was to take the instance offline, which is the right action. The harder question is whether the detection should happen before a researcher has to knock on the door.

If You Were in the Index: What to Do Now

One question the original Huntress reporting does not fully address is: how does an organization know if it was among the 216 compromised hosts? Huntress performed direct victim notification for organizations they could identify from the exposed data, but coordination across 34 Active Directory domains spanning multiple continents and sectors is not a guarantee that every affected party was reached. Organizations running any of the vulnerable software in scope -- SolarWinds Web Help Desk, Gladinet CentreStack, SmarterMail, or Microsoft SharePoint -- should perform proactive threat hunting regardless of whether they received notification.

The Elastic Cloud index contained enough structured data per host -- domain name, system caption, IP addresses, timezone, and patch status -- that an attacker retains a coherent picture of each victim's environment even after the SIEM instance was taken offline. The practical implication is that remediation for these organizations cannot be limited to patching the initial-access vulnerability. A full incident response scope is warranted: credential rotation for all service and administrator accounts, forensic review of scheduled tasks for TPMProfiler variants, sweep for QEMU processes and unexpected SSH listeners, review of all installed RMM agents for unauthorized Zoho Assist or Velociraptor deployments, and network log review for any historical outbound connections to *.es.io, *.elastic-cloud.com, *.workers.dev, and supabase.co storage URLs from non-browser processes.

The Serial Patch Bypass Problem

The three-generation deserialization bypass chain in SolarWinds Web Help Desk raises a structural question that goes beyond this specific vendor. Java-based enterprise applications that expose serialized object handling to network-accessible endpoints have repeatedly produced this pattern: a vulnerability is disclosed, a hotfix replaces the specific gadget chain or tightens one validation layer, and researchers subsequently find that adjacent code paths or variant serialization flows bypass the new restriction. CVE-2024-28986 was exploited. CVE-2024-28988 patched it. CVE-2025-26399 bypassed that patch. The January 2026 disclosure batch -- discovered by Jimi Sebree of Horizon3.ai (CVE-2025-40536, CVE-2025-40537, CVE-2025-40551) and Piotr Bazydlo of watchTowr (CVE-2025-40552, CVE-2025-40553, CVE-2025-40554) -- produced yet another generation of flaws rooted in the same component. CVE-2025-40553, identified by watchTowr as another bypass of CVE-2025-26399, achieves unauthenticated RCE by establishing a JDBC connection to WHD's bundled PostgreSQL instance (which trusts all local connections by default, requiring no credentials) and executing arbitrary OS commands as SYSTEM -- chained with authentication bypass CVE-2025-40552. CVE-2025-40554 provides a parallel auth bypass path via Ajax-related actions. In total, six distinct CVE identifiers across three generations of patch and bypass are traceable to the same underlying architectural weakness in the AjaxProxy component.

This iterative bypass pattern is not unique to SolarWinds. It has appeared in BIG-IP iControl REST, Confluence's OGNL injection chain, and multiple Java deserialization libraries. The underlying problem is that partial remediation -- patching the known gadget chain without addressing the architectural exposure of accepting and deserializing untrusted objects -- leaves the application in a persistently exploitable state. True remediation requires either eliminating the deserialization endpoint entirely, replacing it with a safe alternative (such as JSON with strict schema validation), or deploying a deserialization filter that allowlists only known-safe classes. Organizations that repeatedly find themselves applying hotfixes to the same underlying component should escalate the question to their vendor relationship: what is the architectural remediation plan, not just the next hotfix?

Deeper Detection: What to Actually Look For

For organizations running SolarWinds Web Help Desk, the remediation guidance is clear and urgent. Huntress recommends updating to SolarWinds WHD version 2026.1 or later, placing WHD administrative interfaces behind a VPN or firewall with no direct internet access, resetting passwords for all service accounts and administrator accounts, and reviewing WHD hosts for unauthorized remote access tools including Zoho Assist, Velociraptor, Cloudflared, and VS Code tunnels.

Beyond patching, defenders should also hunt for the specific indicators of compromise documented by Huntress: silent MSI installations spawned by the WHD service process (java.exe / wrapper.exe), encoded PowerShell execution, scheduled tasks named TPMProfiler, and unexpected outbound connections to Elastic Cloud or Cloudflare Worker domains.

On the detection engineering side, the deeper challenge is building behavioral models for legitimate-SaaS-as-egress. The following detection use cases are specifically relevant to this campaign pattern and are underrepresented in most SIEM rule libraries:

• Bulk Get-ComputerInfo execution across multiple hosts in a short window -- this cmdlet collects comprehensive system profiles and has very few legitimate automation use cases that would produce a fleet-wide burst pattern.
• Outbound HTTPS POST requests to *.es.io or *.elastic-cloud.com from server workloads, especially where the initiating process is PowerShell or a Java-based application rather than a browser or established agent. Elasticsearch's bulk ingest API has a distinctive content-type and endpoint structure.
• New scheduled tasks with names beginning "TPM" that are not present in the OS baseline -- particularly tasks that spawn QEMU processes or establish outbound SSH connections to external hosts.
• VS Code Server processes establishing outbound tunnel connections from machines where VS Code is not a sanctioned development tool -- server class machines are particularly high-signal here.
• Registry modifications to HKLM\SOFTWARE\Policies\Microsoft\Windows Defender or the Windows Firewall policy keys executed by a non-interactive process identity, especially when followed immediately by external download activity.
• Velociraptor service installations via MSI with a non-interactive spawning process -- legitimate Velociraptor deployments in managed environments are pushed by an administrator context, not by a Java process or a remote management agent subprocess.

Monitoring for unusual data egress patterns to legitimate SaaS platforms should be treated as a priority detection use case. Network-level TLS inspection that captures the server name indication (SNI) field in TLS handshakes can identify connections to cloud services by name without requiring full decryption, and can be enriched with process context from an EDR to distinguish legitimate from malicious traffic at the session level.

Key Takeaways

1. Defensive tools are not immune to offensive abuse. This campaign demonstrates that SIEM platforms, DFIR tools like Velociraptor, and RMM software like Zoho Assist can all be weaponized when an attacker controls the infrastructure they connect to. The attacker deliberately chose Velociraptor version 0.73.4, a build carrying CVE-2025-6264. CISA initially added that CVE to its KEV catalog but subsequently removed it after Rapid7 clarified the vulnerability was not directly exploited -- attackers had already gained access before deploying Velociraptor, using it for persistence rather than initial compromise. Regardless, the consistent choice of that specific build is a meaningful fingerprint across independently documented incidents: Sophos CTU first documented version 0.73.4.0 misuse in August 2025; Cisco Talos confirmed the same version in October 2025 Storm-2603 ransomware attacks; Fortra documented it in December 2025 via a WSUS intrusion; and Huntress documented it again here in February 2026. Any Velociraptor installation not provisioned by the security team -- particularly one installed as an MSI via a Java process or RMM agent subprocess -- should be treated as a high-confidence indicator of compromise.
2. Recon at scale precedes ransomware. Both Jamie Levy (senior director, adversary tactics) and John Hammond (principal security researcher) at Huntress attributed this campaign to Storm-2603 -- also tracked as GOLD SALEM by Sophos and CL-CRI-1040 by Palo Alto Networks Unit 42 -- a threat actor with a documented history of deploying Warlock ransomware following wide-net reconnaissance. Halcyon's malware analysis confirmed the group planned multi-family ransomware deployment (Warlock, LockBit Black, Babuk in the same operation) from its earliest April 2025 prototypes. The 216-host victim index was a curated pre-attack target list, not an end goal. Organizations identified in that dataset who have not fully remediated should treat their environments as potentially pre-staged for a follow-on payload, and should scope their incident response accordingly -- not just the vulnerability that provided initial access, but the full depth of any Velociraptor, VS Code tunnel, or Cloudflared persistence that may remain.
3. Free trial abuse is a real and growing threat vector. A free trial with a disposable email address gave this attacker enterprise-grade data analytics capabilities with no financial trace and no meaningful identity verification. SaaS vendors offering trials of powerful security or data management tools should consider implementing stronger verification, behavioral monitoring, and anomaly detection during trial periods -- specifically for bulk data ingestion patterns inconsistent with product evaluation.
4. Opportunistic exploitation at scale demands proactive patching. This actor exploited whatever software had a critical weakness available: SolarWinds WHD, Gladinet CentreStack, SmarterMail, Microsoft SharePoint. ReliaQuest documented Storm-2603 actively exploiting a SmarterMail vulnerability (CVE-2026-23760) to stage Warlock ransomware as recently as February 2026 -- a parallel campaign running simultaneously with this one, using different software but the same group, the same tools, and the same post-exploitation pattern. CISA added CVE-2025-26399 to its KEV catalog on March 9, 2026, confirming active exploitation and setting a March 12, 2026 remediation deadline for federal agencies -- a reminder that this vulnerability chain is still live. The 216 compromised hosts across 34 organizations and 37 time zones confirm this is not targeted espionage but broad, automated scan-and-exploit. Timely patching of internet-facing applications -- and restricting their administrative interfaces from direct internet access -- remains the single highest-impact defensive action available.
5. Living off the cloud is the new living off the land. Every stage of this attack leveraged legitimate cloud services: Catbox, Supabase, Cloudflare Workers, and Elastic Cloud. Network defenders should not assume that traffic to well-known SaaS domains is inherently safe. Building behavioral detection for anomalous usage patterns of legitimate cloud services -- particularly bulk data pushes from server workloads to cloud analytics endpoints -- is now a necessary capability, not an optional one.
6. Hardcoded credentials in attack scripts create forensic opportunities. The attacker's decision to embed API keys and credentials directly in their PowerShell exfiltration scripts allowed Huntress to access the Elastic Cloud instance and map the entire campaign. This is the same operational mistake that has burned threat actors repeatedly. Defenders and threat intelligence teams should look for embedded credentials in recovered attack artifacts as a potential window into attacker infrastructure.
7. Bundled database trust configurations are a silent multiplier of vulnerability severity. The CVE-2025-40552 + CVE-2025-40553 exploit chain reaches unauthenticated SYSTEM-level command execution in part because SolarWinds' bundled PostgreSQL instance is configured to trust all local connections by default -- meaning no credentials are needed to authenticate to the database over the loopback interface. This is not unique to SolarWinds; many enterprise Java applications ship with bundled databases or services in maximally permissive local configurations as a convenience default. The result is that authentication bypasses which would otherwise require a second credential theft step achieve immediate RCE impact. Organizations reviewing their java-based enterprise applications should audit whether any bundled services (databases, message brokers, caches) use trust-based or credential-free local authentication, and whether those services are reachable from attacker-controlled execution contexts within the application.

The Huntress investigation, spanning both their Part 1 analysis of the SolarWinds WHD exploitation and their Part 2 analysis of the Elastic Cloud abuse, is essential reading for incident responders and threat intelligence analysts. Coverage and corroboration of this campaign was provided by Infosecurity Magazine, Computer Weekly, The Hacker News, CSO Online, Cybersecurity Dive, and Dark Reading. The broader Storm-2603 threat actor picture is documented by Palo Alto Networks Unit 42 (Project AK47), Check Point Research, Halcyon's ransomware research, Trustwave SpiderLabs, ReliaQuest, and Fortinet FortiGuard Labs. The Velociraptor abuse pattern is documented across Sophos CTU, Cisco Talos, Fortra, and Rapid7. Elastic Security Labs published detection guidance specific to this intrusion pattern. Technical research on the CVE-2025-40552/40553 pre-auth RCE chain was published by watchTowr Labs; discovery of CVE-2025-40551 and related flaws was credited to Jimi Sebree of Horizon3.ai. The malicious Elastic Cloud instance has been taken down, but the broader pattern it exposed -- an organized threat actor with ransomware infrastructure in reserve, turning our own tools against us while remaining one payload away from detonation -- is one the industry will be grappling with for a long time.