Everest Ransomware Group Adopts Wake-on-LAN Tactic to Awaken and Encrypt Dormant Devices

Everest Ransomware Awakens Sleeping PCs with Wake-on-LAN to Maximize Attack Surface

HIGH
July 9, 2026
6m read
RansomwareMalwareThreat Actor

Related Entities

Threat Actors

Organizations

AttackIQ

Full Report

Executive Summary

The Everest ransomware group, a double-extortion operation active since late 2020, has integrated a clever and concerning new tactic into its attacks. According to threat emulation research by AttackIQ, the group's malware now uses Wake-on-LAN (WoL) functionality to power on dormant and sleeping endpoints across a compromised network. This allows the ransomware to encrypt a much larger number of devices than would otherwise be possible, significantly increasing the disruptive impact of an attack. This technique, while not new in concept, is rarely seen in major ransomware campaigns and demonstrates a focus on maximizing damage and pressure on the victim.

Threat Overview

The Everest group's updated malware employs a multi-stage process to ensure a comprehensive network compromise. The most notable stage is its use of Wake-on-LAN. The process is as follows:

  1. Discovery: On a compromised host, the malware parses the local Address Resolution Protocol (ARP) cache. The ARP cache contains a map of recently contacted IP addresses to their corresponding MAC (Media Access Control) addresses on the local network segment. This provides the malware with a list of potential targets, including those that are currently offline or sleeping. This is a form of T1018 - Remote System Discovery.
  2. Activation: The ransomware then broadcasts WoL 'magic packets' over the network, typically using UDP ports 7 and 9. These packets contain the MAC addresses of the discovered devices. If a device is configured to support WoL, it will power on when it receives a magic packet addressed to it.
  3. Impact: By waking up these dormant machines, the ransomware ensures they are online and accessible for the subsequent encryption phase, dramatically increasing the number of affected systems.

This novel approach turns a common power-saving feature into a security liability.

Technical Analysis

Before initiating the WoL sequence, the Everest malware performs several actions to prepare the environment and weaken defenses, showcasing a well-thought-out attack chain:

Impact Assessment

The use of Wake-on-LAN significantly increases the potential impact of an Everest ransomware attack. In many organizations, a substantial portion of workstations are powered down or in a sleep state outside of business hours. These machines would normally be safe from a ransomware attack that spreads across the network at night or on a weekend. By waking these machines up, Everest ensures they are also encrypted, leading to a much larger-scale business disruption. This can turn a partial outage into a complete shutdown, putting more pressure on the victim to pay the ransom. It forces organizations to reconsider the security implications of network features like WoL.

IOCs — Directly from Articles

No specific file hashes or C2 domains were provided in the source articles.

Cyber Observables — Hunting Hints

Security teams can hunt for this specific activity by monitoring network traffic:

Type
Port
Value
7 (UDP), 9 (UDP)
Description
These are the standard ports for Wake-on-LAN 'magic packets'. A sudden broadcast storm of traffic on these ports is highly suspicious.
Type
Network Traffic Pattern
Value
Broadcast traffic to ff:ff:ff:ff:ff:ff
Description
WoL packets are sent as broadcast frames. A spike in broadcast traffic from an unusual source could indicate this activity.
Type
Command Line Pattern
Value
arp -a
Description
The command to display the ARP cache. A malware process executing this command could be a precursor to the WoL tactic.
Type
Log Source
Value
DHCP Server Logs
Description
Correlating DHCP lease information with ARP cache data can help identify all devices on a subnet, similar to how the malware discovers targets.

Detection & Response

  • Network Traffic Monitoring: Use a network intrusion detection system (NIDS) or a SIEM to monitor for and alert on unusual spikes in UDP traffic on ports 7 and 9. This is a direct and high-fidelity indicator of this attack technique. This falls under D3-NTA: Network Traffic Analysis.
  • Behavioral Analysis on Endpoint: An EDR solution should be configured to detect the full chain of Everest's behavior: disabling Controlled Folder Access, enabling SMBv1, querying the ARP cache, and then making network connections to other devices. This sequence of events is highly indicative of a ransomware attack.
  • ARP Cache Monitoring: While difficult to do in real-time, periodic snapshots of a machine's ARP cache that show it has recently resolved a large number of hosts on the network could be a sign of reconnaissance.

Mitigation

  • Disable Wake-on-LAN: The most direct mitigation is to disable WoL in the BIOS/UEFI settings of endpoints and in the network adapter properties within the operating system, especially for devices in sensitive network segments. If WoL is a business requirement, its use should be restricted to specific administrative subnets.
  • Network Segmentation: Proper network segmentation can limit the effectiveness of this attack. By placing devices in separate VLANs, a broadcast WoL packet sent in one segment will not reach devices in another, containing the spread. This is a practical application of D3-BDI: Broadcast Domain Isolation.
  • Control Egress Traffic: While this attack focuses on internal movement, Everest is a double-extortion group. Strict egress filtering and monitoring for large data transfers to unknown destinations can help prevent the data theft portion of the attack.
  • Disable SMBv1: SMBv1 is a deprecated and insecure protocol. It should be disabled across the entire environment. The fact that Everest enables it shows that attackers still see it as a viable pathway for lateral movement.

Timeline of Events

1
July 9, 2026
This article was published

MITRE ATT&CK Mitigations

Segmenting networks into smaller broadcast domains (VLANs) will prevent WoL packets from reaching devices outside of the compromised segment.

Mapped D3FEND Techniques:

Disable Wake-on-LAN in the BIOS/UEFI and OS of endpoints if it is not a business requirement.

Mapped D3FEND Techniques:

Filter broadcast traffic at network boundaries to prevent techniques like this from propagating across the enterprise.

Mapped D3FEND Techniques:

D3FEND Defensive Countermeasures

The most effective technical countermeasure to Everest's Wake-on-LAN tactic is Broadcast Domain Isolation, commonly implemented via VLANs. WoL magic packets are broadcast traffic, meaning they are sent to all devices within the same Layer 2 network segment but are stopped by routers at the boundary of the segment. By segmenting the network into smaller VLANs (e.g., one for each department, or even more granularly), you can contain the WoL broadcast. If a machine in the marketing VLAN is compromised, the WoL packets sent by the Everest malware will only wake up other machines within that same marketing VLAN. It will not be able to wake up machines in the finance, engineering, or executive VLANs. This dramatically limits the blast radius of the attack, preventing it from becoming a full-blown enterprise-wide disaster and turning it into a more manageable, contained incident.

A direct and simple mitigation is to harden endpoints by disabling the Wake-on-LAN feature if it is not explicitly required for business operations. This can typically be done in two places: in the system's BIOS/UEFI firmware, and within the network adapter's properties in the Windows Device Manager. By disabling this feature, the endpoint's network card will no longer listen for magic packets when the machine is in a low-power state. This completely neutralizes the novel aspect of Everest's attack. While this may not be feasible for organizations that rely on WoL for remote administration or patch management, it should be the default configuration for all other systems. A GPO or endpoint management tool can be used to enforce this configuration across the fleet, ensuring that this attack vector is closed at scale.

Sources & References

Article Author

Jason Gomes

Jason Gomes

• Cybersecurity Practitioner

Cybersecurity professional with over 10 years of specialized experience in security operations, threat intelligence, incident response, and security automation. Expertise spans SOAR/XSOAR orchestration, threat intelligence platforms, SIEM/UEBA analytics, and building cyber fusion centers. Background includes technical enablement, solution architecture for enterprise and government clients, and implementing security automation workflows across IR, TIP, and SOC use cases.

Threat Intelligence & AnalysisSecurity Orchestration (SOAR/XSOAR)Incident Response & Digital ForensicsSecurity Operations Center (SOC)SIEM & Security AnalyticsCyber Fusion & Threat SharingSecurity Automation & IntegrationManaged Detection & Response (MDR)

Tags

RansomwareEverestWake-on-LANMalwareTTP

📢 Share This Article

Help others stay informed about cybersecurity threats

🎯 MITRE ATT&CK Mapped

Every tactic, technique, and sub-technique used in this threat has been identified and mapped to the MITRE ATT&CK framework for consistent, actionable threat language.

🧠 Enriched & Analyzed

Observables and indicators of compromise (IOCs) have been extracted and cataloged. Risk has been assessed and correlated with known threat actors and historical campaigns.

🛡️ Actionable Guidance

Detection rules, incident response steps, and D3FEND-aligned mitigation strategies are included so your team can act on this intelligence immediately.

🔗 STIX Visualizer

Structured threat data is packaged as a STIX 2.1 bundle and can be visualized as an interactive graph — relationships between actors, malware, techniques, and indicators.

Sigma Generator

Sigma detection rules are derived from the threat techniques in this article and can be converted for deployment across any major SIEM or EDR platform.