Skip to content
Epsilon Red as he appeared in comic books
Threat Research

A new ransomware enters the fray: Epsilon Red

A bare-bones ransomware offloads most of its functionality to a cache of PowerShell scripts

In the past week, Sophos analysts uncovered a new ransomware written in the Go programming language that calls itself Epsilon Red. The malware was delivered as the final executable payload in a hand-controlled attack against a US-based business in the hospitality industry in which every other early-stage component was a PowerShell script.  

Based on the cryptocurrency address provided by the attackers, it appears that at least one of their victims paid a ransom of 4.29BTC on May 15th (valued at roughly $210,000 on that date). 

While the name and the tooling were unique to this attacker, the ransom note left behind on infected computers resembles the note left behind by REvil ransomware, but adds a few minor grammatical corrections. There were no other obvious similarities between the Epsilon Red ransomware and REvil. 

It appears that an enterprise Microsoft Exchange server was the initial point of entry by the attackers into the enterprise network. It isn’t clear whether this was enabled by the ProxyLogon exploit or another vulnerability, but it seems likely that the root cause was an unpatched server. From that machine, the attackers used WMI to install other software onto machines inside the network that they could reach from the Exchange server. 

The name Epsilon Red, like many coined by ransomware threat actors, is a reference to pop culture. The character Epsilon Red was a relatively obscure adversary of some of the X-Men in the Marvel extended universe, a “super soldier” alleged to be of Russian origin, sporting four mechanical tentacles and a bad attitude. 

Laying the groundwork using PowerShell 

During the attack, the threat actors launched a series of PowerShell scripts, numbered 1.ps1 through 12.ps1 (as well as some that just were named with a single letter from the alphabet), that prepared the attacked machines for the final ransomware payload and, ultimately delivered and initiated it.  

The PowerShell orchestration was, itself, created and triggered by a PowerShell script named RED.ps1 that was executed on the target machines using WMI. The script retrieves and unpacks into the system32 folder a .7z archive file that contains the rest of the PowerShell scripts, the ransomware executable, and another executable.  

It also sets up Scheduled Tasks that run the scripts numbered 1 through 12 but skips 7 and 8, it also creates tasks for scripts named “S” and “C.”

A typical Scheduled Task command looked like: 
C:\Windows\system32\schtasks.exe /create /tn Microsoft\Windows\TASK12 /tr "powershell -file c:\windows\system32\RED\12.ps1" /sc minute /mo 2 /ru SYSTEM /f 

For example, when attackers ran the 2.ps1 script on a machine, it executed a command that deleted the Volume Shadow Copies from the computer. This is an important precursor to the attack, as these files could be used to recover some or all of the files encrypted by the attackers. 

A PowerShell script named c.ps1 appears to be a clone of an open source tool called Copy-VSS, part of a suite of penetration tester tools named Nishang. The Copy-VSS script permits an attacker to copy the SAM file, which an attacker could use to retrieve and crack passwords saved on the computer. 

Obscured…Just Enough 

The PowerShell scripts also use a rudimentary form of obfuscation in which the threat actors appear to have added in some square brackets and braces at random into the script, breaking up the lines of PowerShell script code, and then use a command that strips out those brackets. 

While this technique doesn’t have much of an effect on our ability to analyze the files after the fact, it might be just good enough to evade the detection of an anti-malware tool that’s scanning the files on the hard drive for a few minutes, which is all the attackers really need.

We were able to use the same rules the attackers set up to craft a recipe using CyberChef that strips out the extraneous characters and renders the script human-readable.

Blocked firewall ports and cleaning up tracks 

The red.ps1 script unpacks RED.7z into the %SYSTEM%\RED directory, then creates scheduled tasks that run the unpacked scripts. But then it waits one hour, and executes commands that modify the Windows Firewall rules such that the firewall blocks inbound connections on all TCP ports except the Remote Desktop Protocol’s 3389/tcp and the communications port used by a commercial tool called Remote Utilities, 5650/tcp. 

Firewall rules modified by the RED.ps1 script

Oddly, it does this by first blocking inbound traffic to ports 80 and 443, then redundantly blocks entire large ranges of ports that include 80 and 443, but also exclude the RDP and Remote Utilities ports: 1-3388, 3390-5649, and 5651-65352. 

Epsilon Red firewall rules appear in the Windows Firewall UI

Upon closer inspection, one of the first things the attackers did after gaining access to the target’s network was to download and install a copy of Remote Utilities and the Tor Browser, so this seems like a way to reassure themselves they will have an alternate foothold if the initial access point gets locked down. 

An unusual commercial remote access tool 

The commercial Remote Utilities software, used by the criminals, has several features they might find helpful.  

For one thing, they can use it for free. Anyone can submit an email address through the company’s website and receive a free license key by email that allows them to use the full capability of the product on up to 10 machines, in perpetuity. 

The company’s “Viewer” software includes the ability for a licensed user to generate a digitally signed executable installer, pre-configured with a password and other preferences embedded into the .exe. Users choose their options, which get transmitted back to the company via the application to generate a unique “One-Click package” executable the program then downloads. The threat actor can then deploy this installer, which runs unattended, and automatically synchronizes to their Remote Utilities Viewer console. 

The console also serves as a Remote Desktop client utility, as a convenience. 

Both rutserv.exe samples are digitally signed with Remote Utilities’ certificate

We found that the attackers had generated at least two of these “One-Click installer” executables, which they downloaded to several machines on the target’s network and ran. The installer was named rutserv.exe and the attackers stored it in different filesystem locations on different machines they downloaded it to.

Running down the orchestration scripts 

Initially, the malware runs the scripts numbered 9 and 12, this is followed by a 180 second delay, before then creating the tasks for 1 through 6, 10, 11, and S.ps1 and C.ps1. By default, the attackers extracted these files to a folder named RED under the %SYSTEM% path. Each of these scripts accomplishes a specific task the threat actors use to prepare the system prior to launching the ransomware. Many of these tasks involve hindering security or backup tools, but also involve disabling or killing processes that, if they were running, might prevent a complete encryption of the valuable data on the hard drive.

The RED.ps1 script executes 12 of the 14 PowerShell scripts by adding them to the Task Scheduler

It isn’t clear whether the attackers were just being thorough or if they weren’t sure they could do what they set out to do, but in several cases the scripts issue redundant commands to accomplish the same goal using slightly different methods. 

For instance, the 1.ps1 file looks for processes that contain any of the following strings in their process name, and attempts to kill them:


These strings indicate the attackers are not only trying to shut down security tools, but also database services, backup programs, office applications, email clients, QuickBooks, and even Steam, the gaming platform.  

2.ps1 deletes all the Volume Shadow Copies on the system by running a single command (vssadmin.exe delete shadows /all /quiet), while 3.ps1 disables automatic repairs that Windows might try to run upon a reboot. 

4.ps1 then attempts to delete the Volume Shadow Copies using a different method: 

wmic shadowcopy delete /nointeractive
Get-WmiObject Win32_ShadowCopy | % { $_.Delete() }
Get-WmiObject Win32_ShadowCopy | Remove-WmiObject
Get-WmiObject Win32_Shadowcopy | ForEach-Object { $_Delete(); }
Get-CimInstance Win32_ShadowCopy | Remove-CimInstance 

5.ps1 executes two commands that, between them, delete Windows Event Logs, which would hinder an investigation. 

Similarly to 1.ps1, 6.ps1 attempts to kill not processes but services, based on a list of strings that may appear in the services’ names:  


It also disables Windows defender by setting the following Windows Registry key:  

reg add “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Defender” /f /v DisableAntiSpyware /t REG_DWORD /d

9.ps1, which is executed first, attempts to invoke the Uninstaller for security software from Sophos, Trend Micro, Cylance, MalwareBytes, Sentinel One, Vipre, Webroot, and several cloud backup agents

10.ps1 then, redundantly, runs the dropped p.exe executable, which suspends the processes that contain the following strings, and clears their logs:


And 11.ps1 adds yet another layer of redundancy, executing the following commands that delete Volume Shadow Copies (again, for the third time!) as well as changing recovery options and clearing event logs in yet another way. 

‘vssadmin.exe Delete Shadows /All /Quiet’,
‘bcdedit /set {default} recoveryenabled no’,
‘wmic shadowcopy delete’,
‘wbadmin delete backup’,
‘wbadmin delete systemstatebackup -keepversions:0’,
‘bcdedit /set {default} bootstatuspolicy ignoreallfailures’,
‘bcdedit /set {default} recoveryenabled no’,
‘wevtutil.exe clear-log Application’,
‘wevtutil.exe clear-log Security’,
‘wevtutil.exe clear-log System’,
‘wbadmin delete systemstatebackup’,
‘wbadmin delete catalog -quiet’,
‘bootstatuspolicy ignoreallfailures’

This level of redundancy may be an indication that this threat actor is unsure of their own tools’ capabilities, but aren’t willing to take any chances. 

12.ps1 grants the “Everyone” group access permissions to every drive letter that might exist on the machine to  ensure as many files are encrypted as possible.

Scheduled Tasks set up by the RED.ps1 script

The red.ps1 script also deletes itself, the .7z archive, and the local copy of 7zip from the system when it runs, removing key evidence. 

In addition to the ransomware executable itself, Labs recovered and analyzed another ancillary executable that the attackers deployed on the target machines. The file, just called p.exe, appears to be a custom-compiled version of an open source tool called EventCleaner, which was created to erase or manipulate the contents of Windows event logs. The attackers used the p.exe component to clean up evidence of what they had done. 

We also mentioned that there were other PowerShell scripts delivered in the .7z archive the attackers dropped on targeted machines. While we saw no evidence they were executed in the context of this attack, the scripts numbered 7, 8, and 9 serve important purposes. 7.ps1 logs off practically all open sessions on the computer; 8.ps1 is a redundant copy of the same firewall rules script included in RED.ps1.

Bare-bones ransomware 

The ransomware itself, called RED.exe, is a 64-bit Windows executable programmed in the Go language, compiled using a tool called MinGW, and packed with a modified version of the runtime packer UPX. 

The executable contains some code taken from an open source project called godirwalk, which gives it the ability to scan the hard drive on which it’s running for directory paths and compile them into a list. The ransomware then spawns a new child process that encrypts each subfolder separately, which after a short amount of time results in a lot of copies of the ransomware process running simultaneously. 

In this root cause analysis diagram, each instance of the red.exe ransomware encrypting a single folder appears as a unique process

The ransomware itself is quite small as it only really is used to perform the encryption of the files on the targeted system. It makes no network connections, and because functions like killing processes or deleting the Volume Shadow Copies have been outsourced to the PowerShell scripts, it’s really quite a simple program.  

In the sample we’ve seen, it doesn’t even contain a list of targeted file types or file extensions. In fact, it will encrypt everything inside the folders it decides to encrypt, including other executables and DLLs, which can render programs or the entire system nonfunctional, if the ransomware decides to encrypt the wrong folder path. After it encrypts each file, it appends a file suffix of “.epsilonred” to the files, and drops a ransom note in each folder.  

Strangely enough, the ransom note closely resembles the note used by REvil, a much more widely used ransomware. But where the REvil note is typically riddled with spelling and grammatical errors, the note delivered by Epsilon Red has gone through a few edits to make its text more readable to an audience of native English speakers. 

The Epsilon Red ransom note

Victims are encouraged to visit a special URL on a website operated on the normal web (epsilons[.]red) to engage with the attackers. 


Sophos endpoint products, such as Intercept X, will behaviorally detect several of the actions taken by the PowerShell scripts or the ransomware payload. The act of attempting to encrypt files is blocked by the CryptoGuard feature. As the ingress point for this attack appears to have been an Exchange server vulnerable to the ProxyLogon exploit chain, customers are urged to patch internet-facing Exchange servers as quickly as possible. Sophos endpoint products can protect Exchange servers as well as Domain Controllers or workstations.

Indicators of compromise for this threat can be found on the SophosLabs Github.


SophosLabs acknowledges the work of Anand Ajjan, Richard Cohen, Fraser Howard, Elida Leite, Mark Loman, Andrew Ludgate, Peter Mackenzie, Nirav Parekh, and Gabor Szappanos in producing a comprehensive analysis of the threat, and improving our ability to detect and block malware like Epsilon Red in the future.


Would Sophos tamper protection block these scripts from disabling the Sophos services and uninstall scripts? Also, I’m assuming the attacker would have to have admin privs in order to execute this?


Sophos tamper protection does block the scripts from disabling Sophos services and endpoint protection.


We are the manufacturer of Remote Utilities, the commercial software mentioned in the article. Just wanted to comment on some points in the article.

First, it’s not ‘unusual’ that Remote Utilities provides the MSI Configurator. For remote desktop software it is normal. Such software can be used across multiple remote devices (hundreds and thousands) where it should be deployed. It can be a local Active Directory network, different remote sites only accessible over the Internet or a mix of the two.

Also, there is nothing unusual that a free fully functional version is available. It is called a freemium model. After all a 30-day trial is also fully functional, and not just with Remote Utilities. Who said that free or trial software necessarily facilitates abuse?

We believe that you should explicitly state in the article that the output file (e.g. a one-click installer) built with our MSI Configurator and signed with our digital signature is itself benign. Unfortunately, nowhere in the article you mention that. The idea behind online MSI Configurator is that the user uploads their choices (settings) to our server which then builds and signs the output file. The user – even if they are a malware actor – has no control over this.

This applies not just to a one-click isntaller but to the rutserv.exe file itself. It comes already signed – it’s the same file as in the vanilla version (you can compare the hashes). However, reading the article one may think that the file is malicious PER SE (or made so by the malware actor who managed to keep the signature somehow). But this is not true. It is impossible to modify a file without breaking its signature.

We ask you to more clearly draw a line here. We at Remote Utilities are not responsible for abuse of our software used by thousands of legitimate business users around the globe. Any user must know that any file signed with our digital signature is SAFE. However, it may become dangerous when it is abused AND included into a malware package, but this is NOT our responsibility and we cannot do anything about that. This is the job of antivirus software to fight malicious builds and yet let legitimate software work on their customers’ computers.

Hope you understand.


Thank you for your comments. We stand by our research, but your comment also brings up interesting points about software abuse and how attackers are leveraging commercial tools to their advantage.


Leave a Reply to Jack Cancel reply

Your email address will not be published. Required fields are marked *

Subscribe to get the latest updates in your inbox.
Which categories are you interested in?
You’re now subscribed!