Configuration of IT-Security solutions matter – and sometimes a single parameter can cause big trouble

Entry: https://www.watchguard.com/wgrd-security-hub/ransomware-tracker/nailaolocker

Analysis for NailaoLocker was first unveiled by researchers from the Orange Cyberdefense CERT and Trend Micro in mid-February 2025. In addition to a technical analysis of the NailaoLocker, it also included analyses of a remote access tool (RAT) called PlugX and a modular backdoor called ShadowPad. Both of these tools have a history of preceding intrusions from Chinese-based actors. Hence, the attribution to China. Between June and October 2024, Orange Cyberdefense research revealed a campaign, dubbed Green Nailao, targeting various sectors in several countries, with a primary focus on European healthcare organizations. The attacks ultimately ended in the execution of a novel ransomware called NailaoLocker, which their analysis revealed was hastily, or poorly, written.

This campaign exploited a critical 0-day vulnerability in Check Point Security gateways, which was patched in May 2024 (CVE-2024-24919). Therefore, those affected are those who didn't patch their gateways quickly enough. Once in networks, the threat actors performed reconnaissance, persistence via PlugX and ShadowPad, data exfiltration, and ultimately, the deployment of NailaoLocker via NailaoLoader. According to the analysis, NailaoLocker is written in C++ and utilizes AES-256-CTR to encrypt files, appending the file extension ".locked" to each encrypted file. In typical ransomware fashion, a ransom note is dropped asking victims to contact them through a ProtonMail email address. As such, we have no insight into any ransom amounts. Additionally, we don't have any concrete information on specific victims beyond the information provided in the research, which indicates victims from Europe, Asia, and South America across various industry sectors.

Hey Google. What is Encrypted Client Hello? 

“Encrypted Client Hello (ECH) is a TLS protocol extension that encrypts the initial "Client Hello" message in the TLS handshake, concealing the domain name a user is trying to access from network observers, enhancing privacy and security.”

Google knows all about this because they have led the way on development of this update to the TLS 1.3 protocol. ECH has been enabled by default in Chrome browser since v177 in late 2023, and Google will go on to tell us that this extension to the standard is now supported by other Chromium based browser like Firefox and Microsoft Edge and on the server side by many of the cloud hosting providers like Cloudflare, Amazon CloudFront, and Azure. When the browser implements it and the web hosting provider supports ECH, intermediate transparent proxies are no longer going to see the web site name, which was included in the Server Name Indication (SNI). (Cloudflare has a nice technical description of SNI here. It is a necessary part of the protocol to ensure that devices can open secure connections even when multiple websites are hosted on one server.) This enhances privacy because censors and intermediaries like your internet service provider can no longer see information about websites that you are visiting which was previously seen in the SNI. 

If this enhances privacy and security, isn’t that a good thing for firewalls and security solutions? Yes, but …  one of the important use cases for modern security platforms is to enforce acceptable usage policies in work environments and schools. Organizations use firewalls to prevent people from browsing to adult content in the workplace. Schools setup their firewalls to stop children from seeing inappropriate material. Back when I was a product manager at WatchGuard for Firebox, one of the features that we were really pleased to implement in 2015  (Fireware OS v11.9.4) was SNI based content inspection for the HTTPS proxy. That meant that even if a firewall was not using TLS decryption, we could still do URL category filtering for any https encrypted websites (i.e. pretty much all of them). 

But technology advances, and In the rapidly changing tech landscape, you can’t rely on features that were impactful 10 years ago. Google in their gen AI response recognizes this has an impact and finishes with this coda:

“ECH can make it more difficult for content filtering solutions to identify and block websites based on domain names, which can be a challenge for legitimate safeguarding purposes in education.”

But there are solutions. There are options to switch the default flags in the browser. ECH will not work if encrypted DNS is blocked. But alternatively, we recommend that you fully implement TLS decryption (also sometimes called HTTPS content inspection) in your network solution to inspect all traffic since the majority of malware is hidden in encrypted traffic. In fact, in the latest quarterly WatchGuard Internet Security Report, 60% of malware arrived over an encrypted connection. Some SASE solutions (like WatchGuard FireCloud) make this even easier for remote users by including the necessary HTTPS certificate for TLS decryption in every install of the client on a desktop. 

At the beginning of April, WatchGuard received a report from a customer in the hospitality business describing a new phishing campaign targeting their staff. The attack starts with the threat actor opening a reservation request with the hotel, which they then cancel by email, citing a bad review for the hotel. In the cancellation email, the attackers include a link to what they claim is the bad review, but which is actually the start of a carefully crafted malware attack that leverages living-off-the-land techniques to evade detection to install the AsyncRAT remote access trojan.

The link in the cancellation email sends the victim to a page hosted on booking[.]badrewiesguest[.]com, a domain registered the same day that the phishing emails first went out. The attacker uses CloudFlare’s bot protection services to prevent connections from automated tools and known virtual environments and mask the phishing page's actual hosting location.

The phishing page loads after the victim passes CloudFlares bot detection feature (either automatically or by manually interacting with the “Verify you are a human” dialog. The attacker’s server checks the victim’s browser User Agent header and only displays the malicious content if the victim connects from a Windows-based system. The server redirects all other connections from non-Windows systems to booking[.]badrewiesguest[.]com/win which displays a message that the page is only available for Windows users.

For Windows-based victims, the page loads what looks like a Booking.com website with a burred overlay prompting them to verify that they are a human.
 

If you disable HTML element that contains the blur and the fake CAPTCHA, you can see the actual page content. Funny enough, the actual page content behind the behind the blur is a phishing awareness article copied from Booking.com’s partner hub.

If the victim interacts with the fake CAPTCHA, the dialog updates to display instructions to the victim to use a series of Windows keyboard shortcuts. The shortcuts, if used, launch the Windows Run utility, pastes in the contents of the victim’s clipboard, and and then executes the pasted command.

Behind the scenes, the page uses a simple JavaScript function to request content from a different endpoint on the server. The function retrieves a command that it de-obfuscates and adds to a new hidden textarea element on the page before silently copying it into the victim’s clipboard.

The response from the server is a Base64-encoded command with a random obfuscation string pasted every 3 characters and appended to the end after a pipe character (“|”).
 

The JavaScript function splits the response on the pipe character to identify the random  obfuscation string and then removes all occurrences of the obfuscation string from the Base64-encoded command. The encoded command uses the Windows mshta utility to load an HTML application (HTA) that the threat actor hosts on another attacker-controlled domain.

The HTA application uses a service called ProtWare to obfuscate its HTML code, but the important piece is a bit of VisualBasic script(VBScript) code inside a script element buried in the page. The VBScript downloads two PowerShell payloads from another attacker-controlled server and executes them. Both payloads use the .mp4 file extension to hide as video files despite containing PowerShell scripts.

The first file, “a.mp4” uses a similar obfuscation technique from the very fist command in the attack chain and random-looking variable names to impede analysis. After de-obfuscating the script, the actions become clear. The script downloads a .NET compiled copy of AsyncRAT and executes it through the .NET Reflection Assembly library in PowerShell.

The second file, “b.mp4” sets up persistence on the system by downloading a Windows Batch script from the same server and saving it as “DeleteApp.url” in the windows Startup directory.

The Batch script is mildly obfuscated using string-splitting techniques. The de-obfuscated command uses PowerShell to re-download and re-execute the first “a.mp4” PowerShell script any time the Batch script runs. This means even if the victim identifies and removes the AsyncRAT trojan, the next time they restart their computer, the Batch script will re-download and execute the malware.

Most of the techniques used by the threat actor in this campaign were relatively trivial but still capable of succeeding on endpoints that lack modern Endpoint Detection and Response (EDR) protections. It can be difficult for legacy signature-based anti-malware services to identify and prevent threats that use Living off the Land techniques like PowerShell scripts and self-compiling malware like AsyncRAT. While organizations should educate their users about phishing threats to prevent their them from falling for campaigns like this one, technical controls like EDR can help fill in the gap and prevent malware like AsyncRAT from gaining a foothold.

IOCs

Phishing Domain - booking[.]badrewiesguest[.]com

a.mp4 - d208e1e874110983a74ca484f4b3e44fbfd0685215ad59b1ccc70da2a09b24c6

b.mp4 - 77dc32f3831f2634674bc8597485459dac56ab8e657363f80cb28d485efd4428

j.exe - 440c3df99e39d7adbbd231ab92b01c2e70e276703e8b5831822bba1facc7e1b9

cmd.bat - b8dfe557467bc1b3ef79065888ffff8d60088e4a4e648d80b29ffc0c1036af2f