A recent technical analysis of an Everest ransomware encryptor reveals a purpose-built, ConfuserEx-protected .NET 4.0 binary that combines heavy obfuscation, misleading cryptographic declarations, and uncommon network tactics to maximize impact and impede response.
The analyzed sample (hlntqyun.exe, SHA-256 1df92b…) is a 114 KB C# assembly compiled for .NET Framework 4.0 and protected with ConfuserEx anti-tamper, control-flow obfuscation, string encryption and compression.
Those protections force dynamic unpacking and runtime string resolution more than 200 dedicated decryption methods significantly complicating static analysis and automated detection.
Despite code that declares RSA-4096 and AES-256, Everest actually uses RSA-1024 and AES-128 at runtime: the RSACryptoServiceProvider is constructed requesting 4096 bits but immediately imports a 128-byte modulus, and the AES provider receives a 16-byte key, causing the effective key sizes to downgrade.
The ransomware derives a per-victim seed via System.Random seeded by Environment.TickCount and feeds it into Rfc2898DeriveBytes with a static salt and 1,000 iterations to produce a 16-byte AES key and IV an insecure approach for key generation that nevertheless ties encrypted content to a predictable runtime state.
Early execution performs mutex and geofencing checks that abort on CIS locales, then spawns three persistent background threads that (1) kill reverse-engineering and network-analysis tools using the Windows Restart Manager, (2) disable security, backup and database services and terminate applications holding file locks.
A dedicated anti-Raccine routine removes IFEO debugger registrations and Raccine artifacts, showing operator awareness of common defensive tooling.
AttackIQ has created and released a new assessment that emulates the Tactics, Techniques, and Procedures (TTPs) associated with the deployment of Everest ransomware to help customers validate their security controls and their ability to defend against this threat.
Everest Ransomware Attack
Before encryption, Everest conducts extensive recovery sabotage: deleting backup-related files across drives, deleting volume shadow copies (with shadowstorage resizing to force purging), removing system restore points, and emptying the Recycle Bin.
Strings are stored in encrypted form and resolved at runtime through approximately 210 dedicated methods that invoke a GZip- and Base64-based decryption routine.
It weakens defenses by disabling Controlled Folder Access, re-enabling SMBv1, enabling Network Discovery and File and Printer Sharing firewall rules, and granting the Everyone group full control over fixed drives.
To maximize scope, it assigns drive letters to unmounted volumes and writes discovered UNC paths to a programdata file for later traversal.
A notable and uncommon capability is Wake-on-LAN broadcasts: Everest parses ARP cache entries and sends WoL magic packets over UDP to wake dormant hosts before network enumeration and lateral movement.
The binary also applies DACL-based self-protection by inserting ACCESS_DENIED ACEs for the World SID on its own process security descriptor, making termination via common tools return Access Denied even under elevated contexts.
Encryption logic distinguishes small files (≤10 MB), which are fully encrypted to a .everest file and shredded, from large files that are partially encrypted across several regions to save time while rendering them unusable.
The sample drops EVERESTRANSOMWARE.txt and changes wallpaper, then initiates a delayed self-deletion sequence. The ransom note claims ~1 TB exfiltrated, but no exfiltration routines were found in this encryptor, implying theft likely occurred during earlier intrusion stages.
This analysis aligns with the RansomLook technical report and AttackIQ’s independent review; AttackIQ has released an AEV emulation to validate defenses against Everest’s TTPs.
Security teams should validate detection and prevention across the full chain from WoL-based host activation and dynamic API misuse to recovery-sabotage routines, DACL manipulation, and runtime cryptography using emulation tools such as AttackIQ’s assessment and refer to RansomLook’s CTI report for IOC and behavioral detail.
Stop Accepting SLAs Written for 2019 SOCs – Here’s the 2026 AI SLA Vendor Checklist – Download Free AI SOC SLA Guide
