Detecting Russian Threats to Critical Energy Infrastructure

This attack represents an escalation of the threat to critical infrastructure in the Nordics and Truesec assesses that now that Russia has crossed the threshold of conducting destructive cyberattacks on critical infrastructure, it can happen again and also in the Nordics.

It is consequently critical to find and eradicate other potential intrusions by this threat actor in environments belonging to critical infrastructure in the Nordics and the rest of Europe.

This blog is a summary of what we know about this threat actor, the tools and tactics used by them, and detection rules we have developed to assist in threat hunting and evicting them. Our aim is to assist defenders who want to protect critical infrastructure from this threat.

We are deeply indebted to the Polish CERT for their excellent report on the cyberattack on December 29. Much of what we know comes from this report.

Who is the Threat Actor 

The report released by the Polish CERT attributes the attack to the Russian threat actor known as “Ghost Blizzard” or “DragonFly”. This attack represents the first known destructive cyberattack attributed to this group, and the first destructive cyberattack on critical energy infrastructure in a NATO country by a Russian cyber warfare unit.  

The threat actor DragonFly is a cyber espionage and cyber warfare unit that is assessed to be part of Russia’s security service FSB Center 16. This group has been active since at least 2010 and appears to focus a lot of their activity on critical infrastructure sectors, including the energy, nuclear, commercial facilities, water, aviation, and critical manufacturing sectors.

Up until now DragonFly has never conducted any known destructive cyberattacks, even if they have repeatedly attempted to gain access to such networks, prepositioned backdoors, and prepared for destructive attacks.

The reason for this behavior is likely tied to the nature of cyber warfare. To conduct a successful destructive, cyberattack on a scale to impact an adversary at a critical point, usually requires extensive preparation. Artefacts from the Russian cyberattack on Ukraine on the eve of the Russian invasion of Ukraine in February 2022, shows that the operation had been prepared for at least a year ahead of the attack.

Russia’s other main cyber warfare unit, the GRU threat actor known as Seashell Blizzard or “Sandworm” has conducted repeated cyberattacks in Ukraine in support of the Russian military operations, including repeated destructive attacks on the Ukrainian energy grid. Truesec assesses that DragonFly has not participated in these attacks because their main mission has been to maintain the capacity to strike at critical infrastructure in NATO countries, should the need arise.  

That DragonFly has now been activated and conducted a destructive cyberattack against Polish critical infrastructure represents, in our assessment, a considerable escalation by Russia. Something that may have not received the attention it deserved, considering the effect this attack could potentially have had. Polish authorities claim that in a worst-case scenario,  up to 500 000 people could have been left without electricity and heating. 

Detection and Threat Hunting

Based on intelligence provided by the Polish CERT, Truesec conducted further analysis of the wiper malware used in the attack, as well as the associated malicious activities observed during the intrusion. The goal of this work was to provide additional detection mechanisms and enable effective threat hunting activities related to this campaign. 

Wipers 

The DynoWiper variant deployed against HMI systems was implemented in a specific manner, leveraging the Mersenne Twister (MT19937) pseudorandom number generator to produce random data used for overwriting files. 

A heuristic approach to identifying binaries with potential wiper‑like behavior is to look for constants associated with the Mersenne Twister algorithm in combination with Windows API calls commonly used for file enumeration and deletion. While this method is not specific to wiper malware, it can help surface suspicious binaries that merit further investigation. 

It should be noted that this approach may produce false positives, such as antivirus software or legitimate disk utility tools. Therefore, any binaries that match these heuristics should be analyzed in context to understand why such functionality exists on the system, especially if found on a system within an OT network.

import "pe"

rule possible_wiper_using_mersenne
{
  meta: 
    description = "Windows PE < 5MB containing MT19937 constants and wiper-like imports"
    date = "2026-02-02"
    author = "Nicklas Keijser"
    hash1 ="60c70cdcb1e998bffed2e6e7298e1ab6bb3d90df04e437486c04e77c411cae4b"
    hash2 = "835b0d87ed2d49899ab6f9479cddb8b4e03f5aeb2365c50a51f9088dcede68d5"
    hash3 = "65099f306d27c8bcdd7ba3062c012d2471812ec5e06678096394b238210f0f7c"
    hash4 = "d1389a1ff652f8ca5576f10e9fa2bf8e8398699ddfc87ddd3e26adb201242160"

  strings: 
    $const = { 65 89 07 6C }
    $twist = { DF B0 08 99 }
    $mask7f = { FF FF FF 7F }

  condition:
    pe.is_pe and
    pe.imports("kernel32.dll", "GetLogicalDrives") and
    pe.imports("kernel32.dll", "FindFirstFileW") and
    pe.imports("kernel32.dll", "DeleteFileW") and
    pe.imports("kernel32.dll", "FindNextFileW") and
    pe.imports("kernel32.dll", "SetFileAttributesW") and
    filesize < 500KB and
    ($const and $twist and $mask7f) and
    (
      pe.number_of_signatures == 0 or
      (
        pe.number_of_signatures > 0 and
        not for any i in (0 .. pe.number_of_signatures - 1) :
          (
            pe.signatures[i].issuer matches /Microsoft/i or
            pe.signatures[i].subject matches /Microsoft/i
          )
      )
    )
}

The RTU Wiper 

The destructive activities observed on RTU devices were performed by overwriting the firmware with a deliberately corrupted ELF binary. The file’s entry point consists entirely of 0xFF bytes, rendering the firmware nonfunctional and effectively disabling the device. 

This behavior can be detected by identifying ELF binaries where the entry point contains only 0xFF bytes. While this detection method is relatively simple and could be bypassed by a more sophisticated implementation, a match on this condition strongly indicates malicious intent, as such content would not be expected in a legitimate firmware image.

import "elf" 
rule ELF_entrypoint_at_least_64_FF{ 
  meta: 
    description = "ELF file with just FF at entry point" 
    date = "2026-02-02" 
    author = "Nicklas Keijser" 
  condition: 
    uint32(0) == 0x464c457f and 
    for all i in (0..63) : 
      (uint8(elf.entry_point + i) == 0xFF) 
}

This rule just looks for FF at the entry point of the ELF file; this is rather trivial to bypass but if there is a match on this behavior, it is certain that the intention is malicious.

Threat Hunting 

Prior to deploying the wiper malware, the threat actor performed multiple staging and preparation activities, primarily involving the movement and copying of files over SMB. These actions can be identified through structured threat hunting queries and, when detected, should be analysed in context to determine their purpose and origin. 

Enable Automatic Administrative Shares 

The attacker enabled automatic administrative shares to facilitate file movement and remote access. 

Command:  

“powershell.exe New-ItemProperty -Path ‘HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters’ -Name ‘AutoShareWks’ -Value 1 -PropertyType DWord -Force”

“powershell.exe New-ItemProperty -Path ‘HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters’ -Name ‘AutoShareServer’ -Value 1 -PropertyType DWord -Force”

Threat Hunting Query (User Input):

DeviceProcessEvents
| where FileName in~ ("powershell.exe","pwsh.exe")
| where ProcessCommandLine has_all (@"LanmanServer\Parameters","New-ItemProperty") and ProcessCommandLine has_any ("AutoShareServer","AutoShareWks") 

Threat Hunting Query (System Output): 

DeviceRegistryEvents 
| where ActionType == "RegistryValueSet" 
| where RegistryKey endswith @"\LanmanServer\Parameters" 
| where RegistryValueName has_any ("AutoShareWks","AutoShareServer") 
| where RegistryValueData == 1

Restart of the SMB Service:

To activate the changes made to the LanmanServer configuration, the SMB service was restarted. 

Command: 

"powershell.exe Get-Service LanmanServer|Restart-Service -Verbose -Force"

Threat Hunting Query:

DeviceProcessEvents 
| where FileName in~ ("Powershell.exe","pwsh.exe") 
| where ProcessCommandLine has_all ("LanManServer","Restart-Service")

Allow Inbound SMB Traffic on the Firewall 

The attacker added a firewall rule allowing inbound TCP traffic on port 445 (SMB), using a misleading rule name to reduce suspicion.

Command: 

“powershell.exe New-NetFirewallRule -Name ‘Microsoft Update’ -DisplayName ‘Microsoft Update’ -Protocol TCP -LocalPort 445 -Action Allow” 

Threat Hunting Query: 

DeviceProcessEvents 
| join kind=leftouter (DeviceInfo| where DeviceType == "Server" | where OSPlatform contains "Windows"| distinct AadDeviceId, OSPlatform) on $left.DeviceId==$right.AadDeviceId 
| where FileName in~ ("powershell.exe","pwsh.exe") 
| where ProcessCommandLine has_all ("New-NetFirewallRule","Microsoft Update","-LocalPort 445","-Action Allow") 
| where OSPlatform contains "windows"

Exfiltration Data via HTTP

Data exfiltration was performed using PowerShell’s Invoke-RestMethod cmdlet to upload files to a remote endpoint using HTTP POST requests.

Command:

Invoke-RestMethod -Uri -Method Post -InFile

Threat Hunting Query: 

DeviceNetworkEvents
| where InitiatingProcessCommandLine has_all ("Invoke-RestMethod","Post","InFile")

Conclusion and Recommendations 

The detection mechanisms presented in this report are primarily behavior‑based, focusing on identifying suspicious patterns and activities rather than relying on static indicators alone. This approach is well‑suited for detecting destructive malware and preparatory activities where tooling, payloads, or infrastructure may change across intrusions. 

It is important to emphasize that any alert or hit generated by these YARA rules or threat hunting queries must be investigated in context. While the behaviors described are highly indicative of malicious intent when observed together or in sensitive environments, certain legitimate tools, such as antivirus software, backup solutions, or disk utilities, may exhibit overlapping characteristics. Understanding the role of the affected system, the originating process, and the surrounding activity is therefore essential. 

Based on validation and testing performed by Truesec, the expected rate of false positives for these detections is very low, estimated at less than 1 in 100,000 executions. This makes the provided rules and queries well‑suited for proactive threat hunting, particularly in OT and critical infrastructure environments, where such behaviors are uncommon and should be treated with heightened scrutiny. 

Recommendations 

Truesec recommends the following actions: 

• Deploy the provided YARA rules and hunting queries in monitoring and threat hunting workflows, with prioritization on OT‑adjacent systems, HMI platforms, and infrastructure servers 

• Investigate all hits thoroughly, correlating results with system role, change history, user activity, and other telemetry before drawing conclusions 

• Baseline normal behavior for PowerShell, SMB, and firmware update activities within the environment to further reduce the risk of misinterpretation 

• Treat detections related to wiper‑like behavior as high severity, as these activities are rarely benign and often indicate imminent or ongoing destructive actions 

• Continuously refine and adapt detections as new intelligence becomes available, particularly in relation to evolving wiper techniques and pre‑positioning activities 

• By applying these detections in combination with contextual analysis and operational awareness, organizations can significantly improve their ability to identify and disrupt destructive attacks at an early stage. 

If you have any further questions regarding detection, threat hunting queries or threat to critical infrastructure please contact Truesec for further discussions.  

Annex: TTPs Used by Threat Actor 

Below is an amalgamation of what we know of TTP used by the “DragonFly” threat actor. A main source of information is again the report by the Polish CERT, supported by other sources.  

Sources 

1. https://cert.pl/uploads/docs/CERT_Polska_Energy_Sector_Incident_Report_2025.pdf
2. https://www.sophos.com/en-us/research/resurgent-iron-liberty-targeting-energy-sector
3. https://docs.broadcom.com/doc/dragonfly_threat_against_western_energy_suppliers
4. https://vblocalhost.com/uploads/VB2021-Slowik.pdf
5. https://www.cisa.gov/news-events/cybersecurity-advisories/aa20-296a#revisions
6. https://www.cisa.gov/news-events/alerts/2018/03/15/russian-government-cyber-activity-targeting-energy-and-other-critical-infrastructure-sectors
7. https://docs.broadcom.com/doc/dragonfly_threat_against_western_energy_suppliers