Dispelling Ransomware Deployment Myths

Glitch effectGlitch effectGlitch effect

When a ransomware attack occurs, the focus is most often on the encryption of files. Initial access is often glossed over or simply assumed. In addition, actions taken by a threat actor, by a human making decisions (and sometimes, mistakes) are attributed to the malware itself, often seen in phrases such as, “...the ransomware embedded itself in the C:\Temp folder…”. What may not be as obvious–at least not in public reporting or media reports–are the steps in between initial access and the point of the attack where files are encrypted and ransom notes are written. For example, techniques used for data staging, data exfiltration, and the actual deployment of ransomware are often assumed or simply skipped.

Due to the breadth of our customer base, Huntress has visibility into a wide range of activity, and that allows us to focus on multiple steps in the attack chain. The breakdown of different attacker methods across all these different stages is invaluable for businesses, as it sheds more light on opportunities for prevention and detection, and helps to provide insight into appropriate responses.

While we’ve covered the former two stages in previous posts, today we’ll look more closely at how Huntress analysts have seen threat actors deploying ransomware in attacks. 


What does "ransomware deployment" actually mean? 

Before we go into the specific techniques we’ve seen, let’s first separate reality from misunderstanding when it comes to ransomware deployment.

A Google Search for “how is ransomware deployed” shows the “AI Overview” results illustrated in Figure 1.

Figure 1: AI Overview result for “how is ransomware deployed?”


While the above shows how ransomware actors operate in the very early stages of the attack, it doesn't fully capture what happens after that initial point of access, and what methods and tools they use in that phase. With over four million monitored endpoints and numerous incidents, Huntress analysts are more fully able to provide an in-depth view into this phase.

Generally speaking, there’s also a misconception generated by and shared via online media around the actions behind ransomware deployment. We see statements such as the one above, saying “the ransomware can then spread…” or other phrases that state: “the ransomware uses stolen credentials to access systems via the Remote Desktop Protocol (RDP)...” However, this simply isn’t the case at all.

In the vast majority of incidents reported by the Huntress SOC, ransomware executables may take some steps to disable recovery options or evade defenses, but the primary job of the executable is to encrypt files and deposit a ransom note; it’s usually the threat actor who is responsible for accessing systems, copying files to specific folders, and for deploying the ransomware executable itself.

Also, we want to make clear that variants that follow the “ransomware-as-a-service” (RaaS) model, such as Akira, are deployed by different affiliates, and as such, different affiliate actors may use similar or vastly different techniques. As such, for RaaS variants, it can be misleading to state something like: “Akira ransomware is deployed in this manner…” because the deployment mechanism, and the actions leading up to that point, can be vastly different depending upon the affiliate. 

The purpose of this article is to state clearly and concisely what Huntress analysts have observed across multiple ransomware incidents, including those where the Huntress agent was installed post-incident, after files were encrypted. 


On-host deployment

One ransomware deployment method involves copying the ransomware executable to the endpoint and then manually launching it. This is something Huntress SOC analysts have observed across a number of ransomware families, including ReadText34, INC, Crux, Cephalus, and Akira. In these incidents, the threat actor accesses each endpoint, usually via the Remote Desktop Protocol (RDP), and then manually copies the ransomware executable over to the endpoint before launching it via a command prompt or via PowerShell.

For example, across Akira ransomware incidents where the executable is deployed in this manner, the executable is observed being launched from the root of the C:\ProgramData folder, with various names, and almost immediately after, the following child process is observed:

powershell.exe -Command "Get-WmiObject Win32_Shadowcopy | Remove-WmiObject"

In the case of the Crux ransomware, Huntress analysts have observed the ransomware being launched from various folders, including C:\Windows and C:\Temp, and with various file names. However, commonalities across the incidents include the fact that the ransomware process first spawns an instance of the legitimate Windows service host utility, svchost.exe, with the same command line options as the parent process, and that child process then spawns the following command line:

Cmd.exe /c bcdedit /set {default} recoveryenabled No & bcdedit /set {default} bootstatuspolicy ignoreallfailures

Huntress analysts recently caught several incidents early on in the ransomware deployment phase of the attack. In these incidents, an Akira ransomware affiliate was using compromised credentials for MSP remote monitoring and management (RMM) instances in an attempt to deploy the ransomware. The Huntress SOC became aware of this threat actor methodology when pre-ransomware activity/TTPs were identified on several customer infrastructures under the same partner.

In these incidents, however, the threat actor or group started deploying the Akira ransomware executable on a limited number of endpoints by logging in, copying the malware to the endpoint, and launching it manually. This allowed the Huntress SOC to detect and quickly respond to the execution, or to install antivirus software detecting the execution of the ransomware, isolating all involved endpoints. 


Deploying over the network

Another means for deploying ransomware involves copying the ransomware executable to a single “nexus” endpoint, and then launching the ransomware process “over the network,” often via UNC paths.

An example of ransomware that has been observed being deployed in this manner is SafePay. Prior to deploying the ransomware, a threat actor will often exfiltrate data and enumerate the network, obtaining a list of accessible endpoints. Then, when they’re ready to deploy the ransomware, you’ll see a number of processes similar to the following, launched in rapid succession:

regsvr32.exe  /n /i:"-pass=[REDACTED] -enc=3 -uac -path=\\[REDACTED\C$\ " C:\locker.dll

The target UNC path (redacted in the above example) will change, and the target share (C$ in the above example) will often change, as well. 

Akira ransomware has been observed being deployed via UNC paths. Different affiliates may use different methods for deploying the ransomware, which will include a command line option for deploying it against remotely accessible shares.


Use of PSExec/GoGo.exe

A hybrid approach that can be used to deploy ransomware executables over UNC paths is the use of the freely available Microsoft utility, PSExec. This tool, and its variants, allow an actor with the appropriate privileges to copy executables over to remotely accessible systems and launch them with given parameters. 

Huntress analysts recently observed an incident where the threat actor used a custom tool named ps_bulk.exe, renamed to GoGo.exe, to push a PLAY ransomware executable out to other endpoints within the network, using command lines similar to the following:

C:\Users\Public\Music\GoGo.exe  -i ip.dll -f xxx.exe -m p -u [REDACTED] -p [REDACTED] -t 224

When launched, the command line would spawn multiple PsExec64.exe processes; Figure 2 illustrates the GoGo.exe process tree.

Figure 2: GoGo.exe Process Tree


Deploying via the Active Directory server

Huntress recently published a blog post describing how the Obscura ransomware was placed on a domain controller, in the NETLOGON share, and launched on individual endpoints through the use of Scheduled Tasks. 

This technique, and similar ones, are not new. This Secureworks blog post from 2016 references an incident from the end of 2015 where a ransomware executable was placed on a domain controller, and intended as a distraction. Thanks to the likely intentional misspelling of the domain name, the ransomware was not actually launched on any endpoints, but instead drew defenders’ attention away from the threat actor’s true intentions. 


Phases of the attack lifecycle

When we break down and compartmentalize the attack lifecycle, it helps reduce complexity and makes breaches easier to understand and address. Ransomware threat actors, in particular, include a number of consistent steps in their attacks, going from initial access to recon and endpoint enumeration, maybe privilege escalation (if needed), to data staging and exfiltration, and then finally, ransomware deployment. Delving deeply into each of these steps helps to pull back the veil of mystery and wrap our arms–and our heads–around these activities. From this, we can develop cyber resiliency.

In order to counter ransomware threats, organizations first need to develop an accurate asset inventory of physical and virtual endpoints, as well as applications. Then, they should engage in attack surface reduction. This includes considering what needs to be publicly accessible, how protections should be in place, and what should be removed from public access.

Next, businesses should fully deploy monitoring and detection capabilities, such as EDR and SIEM. Not doing so means that a threat actor can gain access to an unmanaged endpoint, perform all of their preparatory activities without tripping any alarms, and then finally deploy ransomware across the infrastructure, without ever being detected.




Share

Sign Up for Huntress Updates

Get insider access to Huntress tradecraft, killer events, and the freshest blog updates.

By submitting this form, you accept our Terms of Service & Privacy Policy
Oops! Something went wrong while submitting the form.
Huntress at work