Someone Else’s SIEM: A Threat Actor Abuses Another Free Trial

TL; DR Huntress discovered a threat actor was exploiting vulnerabilities (like SolarWinds Web Help Desk) and exfiltrating victim data to a free trial instance of Elastic Cloud SIEM. The actor used the SIEM for victim triage, and the infrastructure revealed details about their campaign, including disposable email services (quieresmail.com), connections to a Russian-registered temporary email network (firstmail.ltd), use of a SAFING_VPN tunnel, and a possible connection to other opportunistic attacks against Microsoft SharePoint and other software. The instance has since been taken down.

Background

In a previous blog post, Huntress observed an adversary exploiting SolarWinds Web Help Desk and exfiltrating compromised victim data to an exposed Elastic Cloud instance. Immediately, we wanted to share threat intelligence on the intrusions, but amongst that investigation, we uncovered a new rabbit hole—live threat actor infrastructure they used for their campaigns. 

We’re no strangers to adversaries abusing free trials of security software, and this time we informed Elastic and the relevant parties so the activity could be investigated and the attacker’s activities addressed

To give further time for victim outreach and notification, as well as our multi-prong coordination with law enforcement and notification to Elastic, we opted to separate the findings of SolarWinds investigation into two parts: this write-up is the teased “Part 2” of our previous blog post.

We will continue onwards from this starting point: a threat actor ran an encoded PowerShell command with a hardcoded API key and credentials to exfiltrate data into a free instance of Elastic Cloud SIEM. 

Exfil to Elastic

To set context, you may remember there was an encoded PowerShell command executed by the threat actor on the victim’s computer. This ran the Get-ComputerInfo cmdlet to uncover detailed system information and then pushes that to an attacker-controlled ElasticSearch index with a hardcoded API key.

This process exfiltrated the operating system version, hardware details, Active Directory domain info, installed patches, and the overall general metadata about this host to an Elastic instance named systeminfo. 

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. 

We notified Elastic of this abuse of their trial, and we collaborated to uncover more noteworthy insights about this adversary. As it turns out, the systeminfo index within the threat actor’s Elastic Cloud instance exposed details of not just a single victim, but multiple compromises across an entire campaign.

The deployment

The Elastic Cloud deployment was created on January 28, 2026 at 01:45 UTC under cloud account u_706752903_cloud, with deployment ID 7c00a38569a8471083b6b34e1511b9de. The instance was running Elasticsearch version 9.2.4 on GCP's us-central1 region. The deployment used default naming (“My deployment”). The Fleet agent remained online and healthy through February 7, indicating the infrastructure was actively maintained throughout the campaign.

Elastic confirmed the adversary registered their free trial account with an email address that had a unique format: what looked like eight random lowercase letters, and the  quieresmail[.]com domain.

This naming convention and domain indicate a disposable and temporary mail service. We have seen other email addresses with this quieresmail[.]com domain formatted with either a fake first name, last name, followed by four digits to represent a year, or an eight-character random string of letters like this one. We believe this is one of the disposable mail domains operated by the firstmail.ltd network, a Russian-registered temporary email service running hundreds of throwaway domains from the same infrastructure.

Figure 1: Screenshot of Firstmail website

Noting this, Elastic then shared with us that there were multiple other free trials that have been created with different disposable email addresses, but all following the same random string formatting. They indicated a few of the email addresses, and curiously, more than one of the very same random email prefixes matched the exact same subdomain that we observed used for the Cloudflare Worker pages: like one qgtxtebl.workers[.]dev as an example.

Figure 2: Screenshot of Cloudflare Workers page

While these FirstMail.ltd email addresses are randomly generated, the Cloudflare Worker Pages subdomains are configurable…but multiple instances of these matched and line up.

We believed this was very peculiar: it seemed the adversary treated the randomly generated email prefix as a key or identifier for parts of their infrastructure and campaigns. This random string was used for both their Elastic Cloud trial registration email as well as their Cloudflare Worker tooling to host their Velociraptor callbacks.

The activity

Kibana usage telemetry revealed the operator spent significant time triaging victim data through the Discover interface across seven days. 

On January 28 alone, the day the deployment was stood up, the operator logged 164 interactions over nearly 150 minutes of active use. Activity continued in the following days: 46 interactions on January 29, 105 on January 30, then a gap before returning on February 2 as the first wave of victim data arrived. February 4 marked the most targeted activity, with 106 field lookups, 23 filters applied, and 15 search queries submitted in just under 13 minutes, which is consistent with systematic triage of high-value targets such as domain controllers and domain-joined hosts. 

Across the full campaign, there were approximately 249 minutes of active Discover usage, 449 total interactions, and evidence that at least one index was deleted on February 2, possibly an earlier collection that was purged before the current dataset was populated.

Administrative login sessions to the Elastic Cloud instance were from these IP addresses:

1. 154.26.156[.]181

2. 51.161.152[.]26

In discussions with numerous other security teams and multiple law enforcement agencies, there is a consensus that these IP addresses stemmed from a SAFING_VPN tunnel. This looks to be Safing “SPN” or “SVPN”, an option for a specialized privacy network alternative to traditional VPNs and Tor.

Notably, the 51.161.152[.]26 was also observed by Unit 42 in a ToolShell exploitation case against Microsoft SharePoint—another opportunistic attack leveraging recent zero-day or n-day vulnerabilities that readily offer code execution to the adversary.

Other telemetry from the Elastic Cloud Kibana sessions also provided a fingerprint of the operator's web browser and suspected workstation:

The systeminfo index contained approximately 216 unique victim hosts at the time of analysis.

The victim data skewed overwhelmingly toward servers (91%), with the majority running Windows Server 2019 or 2022. Among the 47 domain-joined machines, we identified 34 unique Active Directory domains representing distinct organizations. The 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 span 37 different time zones across multiple continents.

Numerous hostnames within the victim dataset pointed to continued exploitation of other high-severity vulnerabilities of late, suggesting the actor continued to perform opportunistic attacks against whatever software had a critical weakness that led to immediate compromise. Namely, there were multiple instances of suggested Gladinet CentreStack, SmarterMail or SmarterTools, Solarwinds Web Help Desk, and ToolShell intrusions against Microsoft SharePoint. This evidence continued to be corroborated by the insights shared by Black Lotus Labs, with whom we also collaborated and spoke following our initial blog post. We were pleased to connect both them and Elastic for even more joined intelligence sharing.

Among the 216 records, a cluster of four hosts stood out as potentially the operator's own test VMs. The hosts Hajbepfy, Bekpaseb, Hhbhymne, and Vdfyivhy (randomized 8-character hostnames) shared an identical fingerprint: a custom SMBIOS build string (rel-1.16.3-0-ga6ed6b70-prebuilt.dady.org), a fabricated BIOS serial of DELL 1 serial, and identical QEMU hardware profiles (Broadwell CPU, ProcessorID 078BFBFF000306D2, 4GB RAM, Realtek RTL8139C+ NIC). 

Two of the four, Hajbepfy and Bekpaseb, also had the system manufacturer set to DADY with model Dady super powerfulPC, while the other two retained default QEMU identifiers.

One noteworthy finding within the attacker-controlled Elastic instance was a saved Kibana search query, named “oooo”. The threat actor created and saved this search on February 4th, and specifically selected the columns for the victim domain, caption, timezone, and IP addresses. They filtered out standalone workstations, and specifically focused on one victim domain. Their target of interest had 6 servers already compromised with their data present in the Elastic systeminfo index, with one hostname suggesting it was a domain controller. Our investigation leads us to believe this victim organization presents itself as an “AI-powered SaaS platform.”

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 confirmed to us that this instance has been taken down.