Phase 1: Initial Access and Penetration
Everest secures its initial entry through remote access vectors, compromised VPN or RDP services, or through credentials purchased directly from initial access brokers. Attackers also exploit vulnerable edge devices. Regular Attack Surface Management is crucial to identify these exposed services and internet-facing assets before threat groups can exploit them.
Phase 2: Execution and Defense Evasion
Once the primary binary is executed, it runs an immediate sequence of checks and system modifications within the first five seconds to evade detection. The malware checks for the existence of a specific single-instance mutex (such as Global\7efc73f7-fda1-42d1-a4c5-8f1670bd08a5) to prevent duplicate running processes. It queries system LCID and culture settings, terminating immediately if a Commonwealth of Independent States (CIS) language profile is detected. To resist process termination by security monitoring tools, the binary inserts a custom deny-Everyone access control entry into its own DACL. Everest then issues PowerShell commands to disable Microsoft Defender's ransomware protections using the Set-MpPreference cmdlet. Finally, the malware re-enables the legacy SMBv1 protocol via DISM, modifies firewall profiles to allow network discovery, and adjusts registry keys to enable long file paths and linked connections.
Phase 3: Network-Wide Propagation and Hostile Wakeup
With defense mechanisms weakened, the attack chain moves toward maximizing lateral coverage across the directory. The malware runs the icacls utility to grant Everyone full control permissions across all local volumes. Everest then parses the local ARP cache to enumerate active network endpoints. The malware sends Wake-on-LAN UDP magic packets across ports 7 and 9 to all discovered MAC addresses. This wakes up dormant workstations and servers, ensuring they are online and accessible for the subsequent encryption phase. The tool then queries five distinct system APIs to locate mapped network drives and active network file shares.
Phase 4: Multi-Threaded Sabotage and Backup Erasure
To prevent incident response teams from intervening, Everest spawns persistent background threads. Thread 1 closes reverse-engineering utilities, network monitors, and security analysis tools every 4 seconds. Thread 2 shuts down security services and database engines every 15 seconds, leveraging the Windows Restart Manager API to unlock occupied database files. Thread 3 terminates any process consuming more than 250 MB of memory every 2.5 seconds to disrupt sandbox analysis systems. The malware systematically targets and removes the open-source Raccine anti-ransomware utility by deleting its registry debugger associations, and shadow copies are destroyed using vssadmin and CIM commands.
Phase 5: File Encryption and Ransom Demand
Finally, the malware alters the system wallpaper and executes its encryption engine. It utilizes AES-128-CBC for files under 10 MB and intermittent chunked encryption for files over 10 MB to maximize speed. Files are appended with the .everest extension, and the ransom note (EVERESTRANSOMWARE.txt) is generated across every accessible folder.