In Part 4, we stole every document from every index, planted a rogue superuser account, created credential-independent API keys, and planted three persistence mechanisms that survive password rotations. Everything was logged. Now we answer two final questions: how much worse could it get, and how do we put everything back?

We have access through port 9200. We have code execution through port 5601. Reconnaissance is complete, CVEs have been exploited, and Kibana has been compromised. Over the past three posts, we proved that we could get in. Now we prove what happens after.

In Parts 1 and 2, every command targeted port 9200. Every exploit, every reconnaissance query, every credential test hit the Elasticsearch REST API directly. But Elasticsearch rarely operates alone. Sitting alongside it on most deployments is Kibana, the visualization and management interface, quietly serving dashboards on port 5601 with its own API surface, plugin architecture, and history of critical vulnerabilities.

This post is the result of an investigation into a case we worked on, in which we traced a loader chain that ended where we didn't expect.

In Part 1, we went from a single open port to a complete map of the target. Version, topology, indices, secrets, credentials, privilege structure — all of it documented, all of it ready to be weaponized. Reconnaissance is finished. Now we find out what breaks.

You are mid-engagement. Nmap finishes its sweep and port 9200 lights up on a host. Elasticsearch. You know it matters. You know the client's logging pipeline, search infrastructure, or analytics platform probably flow through it. But what do you actually know about this cluster? Right now, nothing. No version, no configuration, no indication of whether it is locked down or wide open.

You have almost certainly interacted with Elasticsearch today. The search bar on your company's internal wiki. The autocomplete on the e-commerce site where you ordered lunch. The log aggregation dashboard your SOC team stares at for eight hours straight. The recommendation engine that just served you this article. Elasticsearch is the invisible infrastructure behind modern search, and it processes some of the most sensitive data an organization possesses, including access logs, customer records, financial transactions, and authentication events. It knows where your users click, what they search for, and when they log in.

In June 2025, LevelBlue SpiderLabs published Tracing Blind Eagle to Proton66, in which we assessed with high confidence that Blind Eagle (also tracked as APT-C-36, APT-Q-98, TAG-144, AguilaCiega), a threat actor focused on Latin America, had moved part of its VBScript delivery infrastructure onto the Russian bulletproof hosting provider Proton66. A year later, we're still tracking this cluster closely, and the group hasn't slowed down. If anything, it has kept building.

You're browsing a legitimate small business website. Before the page loads, a familiar Cloudflare box appears: "Verify you are human." It asks you to open Terminal, paste a code, and press Enter. You've seen this before. You follow the steps. The page loads normally.

The LevelBlue Managed Threat Research team investigated a security alert in a customer environment involving a malicious ZIP file containing a Windows shortcut (.lnk) used for initial execution. When triggered, the LNK file executes a hidden PowerShell command that downloads a legitimate node.exe binary and deploys a NodeJS-based backdoor. The malware also uses the EtherHiding technique, leveraging the TON blockchain to retrieve its command-and-control (C2) address.

During a recent security alert, the LevelBlue MDR SOC successfully triaged and contained a structured, multi-stage infection chain designed to deliver the CrySome remote access trojan (RAT). The incident was subsequently analyzed in depth by LevelBlue's Threat Hunting Operations and Research (THOR) team, whose reverse engineering and malware analysis reconstructed the full infection chain and determined that initial access was achieved through a targeted spear-phishing lure masquerading as a logistics rate confirmation document, leveraging expected business workflows to trick the recipient into executing the initial payload.

Over the past two weeks, LevelBlue SpiderLabs has been tracking an active phishing campaign distributing malicious spreadsheet attachments. What initially appeared to be a limited phishing attempt quickly evolved into a widespread campaign impacting multiple organizations across various industries, including manufacturing, media, professional services, agriculture, and chemicals. The affected organizations are distributed globally, with firms identified across Europe, the Asia-Pacific region, and the Americas.

Key points

• LevelBlue has identified two distinct attack vectors associated with ValleyRAT: campaigns leveraging fake installers and campaigns initiated through malicious emails.

• The malicious email-based attack campaign analyzed in this report appears to target both Chinese and Japanese-speaking users, while the malware employs multiple anti-analysis and detection-evasion mechanisms.

• This report presents an example of the detection methodologies used by LevelBlue GSOC to identify ValleyRAT activity.

 

ValleyRAT Threat Intelligence

The malware ValleyRAT, which is the focus of this report, has been repeatedly observed in the wild since it was first named by Proofpoint in 2023. As its name suggests, ValleyRAT is a Remote Access Trojan (RAT) that enables threat actors to remotely control compromised systems. Previous campaigns involving ValleyRAT have also been known to employ advanced techniques such as Bring Your Own Vulnerable Driver (BYOVD).

Many reports have associated ValleyRAT-related activity with the SilverFox threat group. However, there are also skeptical views on whether all attacks leveraging ValleyRAT can be attributed to SilverFox. In an analysis of a leaked ValleyRAT builder, the researchers noted that the use of ValleyRAT alone is insufficient to establish a connection to SilverFox. Other research has also challenged the attribution of ValleyRAT to a single threat actor, arguing that the toolsets employed across campaigns vary significantly.

 

ValleyRAT Detection Trends in LevelBlue GSOC

ValleyRAT activity has also been detected by the LevelBlue GSOC. The graph below illustrates the number of ValleyRAT detections observed by the GSOC since 2025. Detection volume began to increase in May 2025 and accelerated further in 2026, reaching a pace nearly twice that was observed during the previous year. It is important to note that these figures represent only attacks that progressed to a certain stage of the attacks. When unsuccessful or incomplete intrusion attempts are also taken into consideration, the overall volume of ValleyRAT-related activity is likely to be significantly higher.

Figure 1. ValleyRAT activity that progressed or was successful as detected by LevelBlue’s GSOC from January 2025 to April 2026.

 

ValleyRAT Attack Variation

The ValleyRAT-related detections we observed can be broadly categorized into the following two attack vectors:

• Attacks initiated through fake installers

• Attacks originating from malicious emails

We observed and previously analyzed that the fake installer-based attack vector has been around since 2025. In the samples we recently analyzed, we observed that a fake installer executes a downloader, which subsequently retrieves and executes ValleyRAT as the final payload.

Figure 2. ValleyRAT fake installer attack chain.

Based on the characteristics of the campaign, the primary targets appear to be Chinese-speaking users. We observed that the fake installer user interface was presented in Chinese, and the malware actively interfered with security software commonly used in Chinese-speaking regions to evade detection.

However, this threat should not be viewed as a localized issue. We have confirmed multiple compromise cases involving overseas branches of multinational corporations, demonstrating that attackers are leveraging these regional offices as soft targets to gain access to larger corporate networks. As a result, ValleyRAT poses a significant risk to any organization with international operations, particularly those with employees, subsidiaries, or supply-chain partners in targeted regions.

The malware also incorporates a wide range of detection-evasion and anti-analysis capabilities. Notably, the attackers employed Pool Party Variant 7, a distinctive process injection technique. We provide a more detailed analysis of the fake installer-based attack vector in our blog post covering this campaign, which complements the findings presented in this report.

In contrast, we first observed malicious email-based ValleyRAT campaigns in 2026. These campaigns differ from the fake installer-based attacks in that they appear to target Japanese-speaking users. The remainder of this report focuses on a detailed analysis of this malicious email-driven attack campaign.

 

Malicious Email-Based ValleyRAT Campaign: Detailed Sample Analysis

We present a detailed analysis of a ValleyRAT attack detected by LevelBlue’s GSOC that originated from a malicious email.

Attack Flow

Figure 3. ValleyRAT malicious email attack chain.

The attack begins with a malicious email containing a URL link. When the victim accesses the link, a ZIP archive is downloaded. The archive contains both an executable (EXE) file and a DLL file. When the EXE file is launched, it loads and executes the DLL file, which contains the malicious functionality. The DLL file subsequently downloads and executes ValleyRAT, which serves as the final payload of the attack.

Malicious Email

The attack analyzed in this article begins with a malicious email. An example of a malicious email used to distribute ValleyRAT can be seen in Figure 4. The email is written in Traditional Chinese, which is commonly used in regions such as Taiwan and Hong Kong, and its content relates to personnel transfers and salary adjustments.

The email contains a URL link that, when clicked, leads to a ZIP archive being downloaded and initiating the infection chain. The email also encourages recipients to open the file on a computer rather than a mobile device, as the EXE and DLL files contained in the archive cannot be executed on mobile platforms.

Figure 4. ValleyRAT malicious email sample.

In addition, our OSINT investigation identified a Japanese-language email associated with the same campaign. Like the Chinese-language email, the Japanese email contains a URL link, and the domain portion of the URL is shared between the two. Furthermore, an investigation of the domain on VirusTotal revealed multiple URLs containing both Chinese-language and Japanese-language content.

Previous reports on ValleyRAT malicious email campaigns have described attacks targeting either Japanese- or Chinese-speaking users individually. While it is not possible to draw a definitive conclusion based solely on a shared domain, the available evidence suggests that the ValleyRAT malicious email campaigns targeting both Chinese- and Japanese-speaking users may have been conducted by the same threat actor.

ZIP File/EXE File

The ZIP archive downloaded through the malicious email campaign contains both an EXE file and a DLL file. Although no malicious functionality was identified within the EXE file itself, executing the EXE causes it to load a malicious DLL, thereby initiating the subsequent stages of the attack.

The sample analyzed in the following sections originates from the ZIP archive shown below. According to VirusTotal, the file is associated with the domain used in the URL link contained in the malicious email discussed in the previous section.

• SHA1 hash: 65168c8dd93b16d3b77092fb70c0fa6fba4dffcc

The figure below shows the properties of the EXE file contained in the ZIP archive. Although the file is named "【給与調整のお知らせ】.exe ", its file description is "VLC media player," and its original filename is "vlc.exe." In addition, the file hash of "【給与調整のお知らせ】.exe " matches that of a legitimate VLC media player executable. Combined with the fact that the accompanying DLL file is named "libvlc.dll," a DLL commonly used by VLC media player, we assess that the attackers are leveraging DLL sideloading as an evasion technique.

Figure 5. Malicious EXE file properties.

DLL File

The DLL file loaded by the EXE implements two primary functions:

• Establishing persistence

• Downloading and executing ValleyRAT

In addition to these primary functions, the DLL file also incorporates several code obfuscation and evasion techniques, as listed below. Notably, if any of the evasion checks fail, the malware does not proceed with its primary activities, including persistence establishment and ValleyRAT execution:

• Junk code insertion

• Memory size checks

• Sleeping duration checks

• Process count checks

• Validation of the return value of IsNativeVhdBoot()
  
  

Persistence

To establish persistence, the malware first copies the EXE and DLL files to the locations shown below.

• File1

  • Copy Source: 【給与調整のお知らせ】.exe

  • Copy Destination: C:\Users\Public\Documents\res\msword.exe

• File2

  • Copy Source: libvlc.dll

  • Copy Destination: C:\Users\Public\Documents\res\libvld.dll

Figure 6. ValleyRAT copies malicious files to two locations in an infected machine.

The paths of the original EXE and DLL files depend on the directory in which the user extracts the ZIP archive. Therefore, this copying operation is likely performed to place the files in fixed locations so that the path of the EXE file referenced in subsequent operations can be determined reliably.

The malware then establishes persistence by creating the following registry entry, which causes msword.exe to be executed automatically when the user logs on:

• Registry path: HKEY\Software\Microsoft\Windows\CurrentVersion\Run\pornhub

Figure 7. Establishing persistence by creating a registry entry that causes the automatic execution of msword.exe.

Downloading and Executing ValleyRAT

The routine used to download ValleyRAT is relatively straightforward and is implemented using standard Windows APIs provided by wininet.dll, including InternetOpenW() and InternetReadFile(). As shown in the figure below, the download URL is Base64-encoded.

Figure 8. Base64-encoded download URL.

The downloaded ValleyRAT payload is encrypted using RC4, and the encryption key is identified as "zenzensu."

Figure 9. RC4-encrypted ValleyRAT payload with an encryption key named “zenzensu”.

After the download is completed, the malware creates a suspended rundll32.exe process using CreateProcessA(). It then decrypts the ValleyRAT payload with RC4 and injects it into the memory of the suspended process using APIs such as VirtualAllocEx() and WriteProcessMemory(). Finally, the malware resumes executing the suspended process by calling ResumeThread(), allowing the attack to proceed to the next stage.

Throughout the download and execution process, the ValleyRAT payload is never written to disk. Instead, it is executed directly from memory, making the technique effectively fileless.

Figure 10. ValleyRAT creates a suspended rundll32.exe process via CreateProcessA().

Figure 11. Decryption of the ValleyRAT payload via VirtualAllocEx() and WriteProcessMemory() APIs.

Figure 12. ValleyRAT calls ResumeThread() to resume the suspended process.

Junk Code

The DLL file contains a large amount of junk code. In the Ghidra decompilation view shown below, multiple functions whose names end with "ret" are invoked. However, these functions merely returned constant numeric values and do not perform any meaningful operations. As such, they serve no practical purpose in the execution flow of the malware.

We assess that these junk code routines were inserted as an obfuscation technique to complicate analysis and hinder reverse engineering.

Figure 13. DLL file junk code inserted by threat actors for obfuscation.

Memory Size Check

We identified code that uses the GlobalMemoryStatusEx() Windows API to determine the amount of physical memory available on the infected system. If the memory size is less than or equal to 0x40000000 (1 GB), the malware does not proceed with subsequent execution.

This type of check is commonly implemented by malware as an anti-analysis technique to identify sandbox or virtualized environments, which are often configured with limited memory resources.

Figure 14. ValleyRAT uses the GlobalMemoryStatusEx() API to check the physical memory of an infected machine to determine if it’s running in a sandbox or a virtual environment.

Sleeping Duration Checks

In the code shown in Figure 15, the malware calls the GetTickCount() API both before and after invoking the Sleep() function and calculates the difference between the two return values. Because GetTickCount() returns the number of milliseconds that have elapsed since the system was started, the calculated difference corresponds to the actual duration of the Sleep() call.

If the measured duration is less than or equal to 0x1c3 (451 milliseconds), the malware does not proceed with subsequent execution. We assess that this check is intended to detect sandbox environments. Some sandbox solutions accelerate or shorten sleep intervals to speed up analysis, causing Sleep() to return earlier than requested. The malware appears to leverage this behavior as an anti-analysis technique.

Figure 15. ValleyRAT calls the GetTickCount() API and invokes the Sleep() function to determine if it’s running in a sandbox/virtual environment.

Process Count Checks

In the code shown in Figure 16, the malware uses the GetSystemInfo() Windows API to determine the number of processors available on the infected system. If the processor count is less than or equal to one, the malware does not proceed with its primary functionality. We assess that this check is also intended to detect sandbox or virtualized environments, as such environments are often configured with a minimal number of virtual processors.

Figure 16. The malware checks the number of available processors via the GetSystemInfo() API.

Validation of the Return Value of IsNativeVhdBoot()

The malware checks the return value of the IsNativeVhdBoot() Windows API. This API can be used to determine whether the operating system is running from a native VHD (Virtual Hard Disk) boot environment. We assess that this check is intended to identify specific execution environments that utilize VHD-based configurations.

Figure 17. The malware checks the return value of IsNativeVhdBoot().

 

Analyzed ValleyRAT Sample

Because ValleyRAT was executed in a fileless manner, no payload file was left on the infected system, preventing us from obtaining the sample from the Disk. However, we acquired the following sample from VirusTotal, which we believe was used in this attack.

• SHA1 hash: eca7ed7b699835fadc2c2997a2845864e02b8dfe

We assess that this sample was used in the specific attack investigated in this report, based on the following reasons:

• The RELATIONS section of the sample on VirusTotal references the URL contacted by the DLL file analyzed in this report.

• The sample can be successfully decrypted into executable shellcode using the RC4 key, "zenzensu," which is embedded in the DLL file analyzed in this report.

We now present the results of our analysis of this sample.

Donut

Analysis of the ValleyRAT sample revealed that it was generated using Donut. Donut is a tool for generating PIC (Position-Independent Code). It enables the creation of .NET assemblies and shellcode that can be executed directly from memory with minimal effort.

A publicly available decryptor capable of reversing code generated by Donut has also been released. We applied this decryptor to the sample obtained from VirusTotal and successfully recovered the original file. This successful recovery is the basis for our assessment that the sample was generated using Donut.

The recovered sample has been uploaded to the URL below:

• SHA1 hash: eca7ed7b699835fadc2c2997a2845864e02b8dfe
  
  

Recovered Sample

Based on the numerous similarities between the decrypted sample and previously reported ValleyRAT samples, we assess that the recovered sample is indeed ValleyRAT.

One such similarity is shown in the figure below. The decrypted sample contains code that establishes persistence for the file GFIRestart64.exe through the Windows Run registry key. The same persistence mechanism was also observed in a ValleyRAT sample analyzed by Morphisec Threat Labs, further supporting our assessment.

Figure 18. The decrypted sample contains code that establishes persistence for GFIRestart64.exe.

 

Detection

LevelBlue’s GSOC has developed multiple detection mechanisms for identifying ValleyRAT-related activity. In this section, we present one such detection logic and explain how it can be used to detect ValleyRAT. The detection logic discussed in this article is shown below.

Figure 19. LevelBlue’s detection logic for ValleyRAT.

This query is designed to detect modules loaded by ValleyRAT. Although the query shown above is quite lengthy, the key aspect is the module names it references. These module names were obtained from leaked ValleyRAT source code.

Several ValleyRAT leak datasets are publicly available. The particular leak referenced during the development of this query contained multiple Visual Studio project files. We believe that the project names contained in these files correspond to ValleyRAT module names. Using these names as indicators, we developed the query and successfully detected multiple activities associated with ValleyRAT. To further reduce the likelihood of false positives, we also added a condition requiring the detected module to be a floating module.

Figure 20. Leaked ValleyRAT datasets.

As demonstrated by our analysis, ValleyRAT employs fileless execution techniques and encrypts its payloads, making it a challenging threat to detect. Nevertheless, LevelBlue continuously reviews and enhances its detection logic to improve its ability to identify and respond to emerging threats.

This hunting query has the potential to generate a significant number of false positives and is therefore not currently incorporated into the standard MalOp detection logic. Instead, it has been implemented as part of LevelBlue’s Proactive Hunting logic. Proactive Hunting is a threat hunting service provided through LevelBlue’s Managed Detection and Response (MDR) service. Unlike conventional EDR alerts, Proactive Hunting identifies potential threats using a separate set of hunting methodologies and detection logic. One of the key characteristics of Proactive Hunting is its ability to tolerate a higher false-positive rate. Under the Proactive Hunting operating model, only validated threats are reported to customers, while false positives are filtered out by LevelBlue analysts. As a result, even detection logic such as the query presented in this article, which may produce a relatively large number of false positives, does not create additional operational burden for customers.

 

Prevention

The following measures can help prevent attacks that originate from malicious emails:

• Raise employee awareness based on the characteristics of the attack described in this article.

• Conduct phishing and malicious email awareness training within the organization.

• Deploy email security solutions to block malicious emails before they reach end users.

• Deploy an EDR solution capable of detecting techniques such as DLL sideloading and Donut-generated shellcode.

• Utilize Proactive Hunting through LevelBlue’s MDR service.

The most straightforward mitigation measure is to raise employee awareness. Based on the findings presented in this article, organizations can share the following indicators with employees to help them identify suspicious emails:

• Emails related to business matters, such as personnel transfers or salary adjustments, are sent from free email services such as outlook[.]com, gmail[.]com, or hotmail[.]com.

• The email body contains a URL link and instructs recipients to open a ZIP file downloaded from that link on a PC.

• The ZIP file downloaded from the URL contains both an EXE file and a DLL file. The EXE file is named in Japanese and uses wording similar to the email subject or content. The use of a Japanese-language filename for an executable file is unusual and should be treated as suspicious.

• Although the EXE filename is consistent with the theme of the email, the product name embedded in the file metadata is unrelated to the purported content of the message.

Security awareness training and the deployment of email security solutions are also effective countermeasures against malicious email–based attacks.

In addition, characteristics such as DLL sideloading and Donut-generated shellcode are generally not suitable for end-user awareness programs. However, EDR solutions that monitor and record endpoint activity can detect these behaviors and provide visibility into such attacks.

LevelBlue’s MDR solution includes detection logic designed to identify ValleyRAT-related activity. Organizations seeking enhanced protection against threats such as ValleyRAT may wish to consider this service.

 

Remediation

If a system is infected with ValleyRAT, we recommend taking the following actions. However, these are general remediation recommendations. Depending on the circumstances, such as when a forensic investigation is planned, it may be preferable to preserve the current state of the system by isolating it from the network without performing additional remediation activities. Organizations should therefore carefully consider their incident response objectives before proceeding.

• Isolate the affected system from the network.

• Perform a clean reinstallation of the operating system on the affected system.

In addition, ValleyRAT is a remote access trojan (RAT), which means that attackers may be able to remotely control an infected system. Therefore, organizations should review EDR and other available security logs to determine what actions were performed by the attacker and implement appropriate remediation measures based on those findings.

 

Conclusion

LevelBlue’s GSOC continuously detects ValleyRAT activity, which can be broadly categorized into two main patterns. This blog primarily focused on the malicious email-based attack pattern.

Through our analysis of the samples, we found that ValleyRAT incorporates multiple anti-analysis and evasion techniques, making it a non-trivial threat to detect using simple approaches. We also discussed the possibility that a single threat actor operating ValleyRAT may be targeting both Chinese-speaking users and users in Japan.

Finally, we introduced one detection approach that leverages module names as a key indicator for identifying ValleyRAT-related activity. LevelBlue’s GSOC will continue to monitor ValleyRAT-related campaigns and provide updates as new findings emerge.

 

IOCs

Remote access trojans (RATs) are legacy threats that continue to evolve alongside an expanding and ever-changing threat landscape. Following our recently published articles about novel and notable RATs, including KarstoRAT, the latest version of ClickFix, and ClickFix’s macOS variant, we analyzed QuimaRAT, a novel Java-based RAT that targets Windows, Linux, and macOS environments and is currently being sold on the dark web as a subscription-based RAT platform.

In Norse mythology, Loki, the god of mischief, has powerful and deceptive transformation abilities. True to its namesake, the malware LokiBot has appeared in numerous variants and payload formats since its discovery more than a decade ago. In this blog, we take a closer look at a multi-stage LokiBot sample from a recent campaign.

Identified through macOS endpoint monitoring, the CL-CRI-1089 cluster, delivered under the publicly reported Operation FlutterBridge campaign, demonstrates a deliberate misuse of the Flutter framework for macOS malware delivery. Rather than re-documenting the campaign itself, this report treats the recovered FlutterShell artifacts as a technical detection case study.

Executive Summary: Bypassing Boundaries in Enterprise AI Infrastructure

The massive global adoption of artificial intelligence (AI) and large language models (LLMs) has fundamentally rewritten the enterprise threat landscape. Modern high-compute bare metal clusters, cloud nodes, and developer workstations now routinely host dense data science stacks running frameworks such as TensorRT LLM, PyTorch, and deep CUDA execution layers. To process complex matrix calculations efficiently, low-privilege user mode tasks require direct pipelines straight to the underlying graphics acceleration hardware.

We recently observed a multi-stage macOS intrusion campaign conducted by the North Korean state-sponsored threat group Sapphire Sleet (also tracked as BlueNoroff/UNC1069).

Artificial intelligence (AI) is changing the shape of the application attack surface. A traditional application assessment usually starts with familiar questions, such as:

Since April 2026, LevelBlue SpiderLabs’ Cyber Threat Intelligence team has tracked a series of public zero-day disclosures targeting Microsoft Windows, attributed to an anonymous actor operating under the names Chaotic Eclipse and Nightmare Eclipse. The activity spans multiple areas of the Windows security model, including recent disclosures such as GreenPlasma, MiniPlasma, and YellowKey.