Everest Ransomware Uses Wake-on-LAN to Revive Dormant Hosts

A new technical analysis of an Everest ransomware encryptor reveals an uncommon tactic: before beginning encryption, the malware parses the local ARP cache and sends Wake-on-LAN magic packets to sleeping machines, maximizing the number of systems available for encryption. The sample also demonstrates heavy obfuscation and deliberately misleading cryptographic declarations designed to waste incident responders' time.

The Everest operation has been active since at least 2020, targeting victims across sectors and demanding ransoms for both decryption keys and promises not to leak stolen data.

Wake-on-LAN for Maximum Impact

The analyzed sample (hlntqyun.exe, SHA-256 1df92b...) first enumerates recently contacted hosts by parsing the ARP cache. It then transmits Wake-on-LAN magic packets over UDP ports 7 and 9 to each discovered MAC address. Any powered-off but network-connected machines on the same segment receive the wake signal.

This behavior is unusual among ransomware families. Most encrypting malware operates on whatever systems are already online during execution. Everest's approach ensures that hibernating workstations, sleeping servers, or machines in power-save mode come online before network enumeration begins.

The tactic particularly threatens environments with inconsistent power management policies. A workstation that happened to be asleep during initial ransomware deployment becomes a target once it wakes. Backup servers or file shares configured to sleep during off-hours become accessible.

Obfuscation and Misdirection

The 114 KB C# assembly uses ConfuserEx protection including anti-tamper controls, control-flow obfuscation, string encryption, and compression. More than 200 dedicated decryption methods handle runtime string resolution, significantly complicating static analysis.

The binary also engages in cryptographic misdirection. Code declares RSA-4096 and AES-256, suggesting strong encryption that might be infeasible to break. At runtime, however, the RSACryptoServiceProvider actually imports a 128-byte modulus (RSA-1024), and the AES provider receives a 16-byte key (AES-128).

This matters for incident response. Responders examining the decompiled code might conclude the encryption is unbreakable and recommend against recovery attempts. In practice, the weaker actual encryption might be more vulnerable to cryptanalytic attack, though RSA-1024 still presents significant challenges.

Pre-Encryption Sabotage

Before encrypting files, Everest conducts extensive recovery sabotage. The ransomware deletes backup-related files across all accessible drives, purges Volume Shadow Copies by resizing shadowstorage, removes System Restore points, and empties the Recycle Bin. This sequence aims to eliminate any local recovery options before the victim even realizes an attack is underway.

The malware spawns three persistent background threads early in execution. These threads continuously kill processes associated with reverse-engineering tools and network analysis software using the Windows Restart Manager API. They also disable security services, backup agents, and database services that might interfere with encryption or maintain file handles preventing access.

Mutex and geofencing checks occur before these threads spawn, suggesting the operators avoid certain regions—a common pattern among ransomware operations seeking to avoid law enforcement attention from particular countries.

Detection and Response

The ConfuserEx obfuscation requires dynamic unpacking for analysis. Static detection rules targeting declared cryptographic parameters will miss the actual runtime behavior. Behavioral detection focusing on ARP cache access followed by Wake-on-LAN packet transmission provides a more reliable indicator.

The Wake-on-LAN activity itself could serve as an early warning. Network monitoring for magic packets (UDP to ports 7 and 9 with the characteristic 6-byte header followed by 16 MAC address repetitions) from non-administrative systems should trigger investigation.

Organizations running centralized backup infrastructure should verify those systems remain isolated from general network segments. The shadow copy deletion and backup file targeting demonstrate Everest's specific focus on eliminating recovery options.

Recommended Mitigations

1. Disable Wake-on-LAN on systems where remote wake capability isn't operationally required
2. Segment backup infrastructure from general network access
3. Monitor for WoL traffic from non-administrative hosts
4. Implement application allowlisting to prevent unauthorized process termination tools
5. Maintain offline backups that ransomware cannot reach regardless of network propagation

The Everest operation continues active targeting. For organizations tracking ransomware threats, the combination of pre-encryption infrastructure sabotage, anti-analysis obfuscation, and the unusual Wake-on-LAN behavior indicates sustained development investment from the operators.